BOX job = container for grouping child jobs — runs no command itself, controls when children can start (box must be RUNNING first)
Key components: box_name (child attribute linking to parent), condition (dependency between child jobs), nested boxes (boxes inside boxes)
Performance: Box status updates are O(number_of_children) — deep nesting (>5 levels) can slow Event Processor
Production trap: Child job has date_conditions: 1 with start_times inside box — waits for box AND specific time, may never run if box starts after that time
Biggest mistake: Box shows RUNNING but children not starting — child has unmet condition, ON_HOLD, or machine offline; not an error, just unmet prerequisite
✦ Definition~90s read
What is Box Jobs and Nested Boxes in AutoSys?
AutoSys Box jobs are logical containers that group jobs for coordinated execution, but their timing behavior is frequently misunderstood. A Box job itself doesn't execute code — it manages the start conditions of its child jobs. When you nest boxes (boxes inside boxes), the outer box's status reflects only whether it's active or terminated, not whether its children have actually started.
★
A BOX job in AutoSys is like a project folder on your computer.
The critical rule: a child job's date_conditions (like start_times or run_calendar) are evaluated relative to the box's start time, not the system clock. This means a child with a start_times of '08:00' inside a box that starts at 09:00 won't trigger until 09:00 + 8 hours — a common source of 'box is running but jobs aren't starting' bugs.
In practice, nested boxes create a hierarchy where each inner box inherits the outer box's start time as its own 'box start' for child condition evaluation. This stacking effect can delay job execution by hours or days if you're not tracking the full chain.
The box status indicator (RUNNING, SUCCESS, TERMINATED) is a lie in the sense that a RUNNING box may have zero active children — it simply means the box itself hasn't finished its lifecycle. Tools like AutoSys r11 and CA Workload Automation AE exhibit this behavior identically; the only reliable debugging method is to inspect autorep -j <jobname> -q for each child's condition and date_conditions fields.
Termination rules for nested boxes are equally treacherous. If an outer box is forced to TERMINATED status (via sendevent -e FORCE_STARTJOB or job failure with term_run_time), all inner boxes and their children are immediately killed — regardless of their individual status.
However, if an inner box completes (SUCCESS) while the outer box remains RUNNING, the inner box's children are already dead and won't restart. This asymmetry causes 'orphaned' jobs that appear in the database but never execute. The golden rule: never nest boxes unless you explicitly need cascading termination; for simple sequencing, use condition dependencies on sibling jobs instead.
Plain-English First
A BOX job in AutoSys is like a project folder on your computer. The folder itself doesn't do any work — it just contains files (child jobs). When you open the folder (start the box), the files inside become available. When all files are complete (all inner jobs succeed), the folder is done. You can even put folders inside folders.
BOX jobs are central to well-organised AutoSys environments. Without boxes, you'd have hundreds of independent jobs with no logical grouping, no shared scheduling, and no way to see the end-to-end status of a business process at a glance. With boxes, you can group related jobs, control their collective schedule, and see in seconds whether your end-of-day run succeeded.
But boxes are dangerous when misused. A child job with its own start_times inside a box may never run because the box starts after that time window. A box shows RUNNING but no children start — operators assume the jobs are broken, but the condition is unmet. And a Super Box (top-level box) can mask failures: if a child box fails, the parent box fails, but you lose visibility of which specific job caused the failure.
By the end you'll know exactly how boxes control child jobs, when boxes succeed or fail, how to nest boxes, and the specific debug steps when inner jobs won't start.
How Nested Box Jobs Actually Control Timing
A nested box job is a box job that contains other box jobs as children. The core mechanic: a parent box's date_conditions override the timing of all child boxes and their jobs, regardless of each child's individual date_conditions setting. This means if the parent box has date_conditions = y, the entire subtree waits for the parent's start time before any child can run — even if a child box has date_conditions = n. The override is absolute, not advisory.
In practice, this creates a strict hierarchical timing model. When a parent box starts, all its children become eligible to run based on their own conditions (job dependencies, box term conditions), but the parent's start time gates the entire tree. If a child box also has date_conditions = y, its own start time is ignored until the parent fires. This is not a bug — it's by design. AutoSys evaluates date_conditions top-down: parent wins, period.
Use nested boxes when you need a coordinated batch window across multiple job groups — for example, an overnight processing window that must not start before 2:00 AM. The parent box enforces the window; child boxes handle intra-group dependencies. Without this override, each child box could start independently, breaking the batch boundary. In production, this is the difference between a controlled pipeline and jobs bleeding into the wrong shift.
⚠ Silent Override Trap
Setting date_conditions = n on a child box does NOT bypass the parent's timing — it only means the child won't add its own start time constraint.
📊 Production Insight
A team set date_conditions = n on child boxes expecting them to run immediately after parent start, but parent had date_conditions = y with a 3 AM start — all children waited until 3 AM, causing a 2-hour idle gap.
Symptom: jobs show 'Inactive' or 'On Ice' status despite all dependencies met, because the parent's start time hasn't arrived.
Rule: Always set date_conditions on the outermost box only; inner boxes should rely on job dependencies and box term conditions, not date conditions.
🎯 Key Takeaway
Parent date_conditions unconditionally override all child date_conditions — there is no opt-out.
Nested boxes enforce batch windows; they do not add parallelism — children still run sequentially if dependencies dictate.
Use box term conditions (e.g., 'success(parent)') to control child flow, not date_conditions on inner boxes.
thecodeforge.io
Autosys Box Jobs Nested Boxes
How BOX jobs control child job execution
The box controls three things for its child jobs: 1. When they can start: Child jobs can only start when the box is in RUNNING state 2. The execution environment: All child jobs inherit the box's scheduling context 3. Collective status: The box reports SUCCESS only when ALL child jobs succeed
A child job's own conditions (start_times, conditions) still apply within the box. If Job B has condition: success(Job A), it still waits for Job A even though the box is running.
io/thecodeforge/autosys/box_control.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/* Box starts at 10PM on weeknights */
insert_job: eod_box
job_type: BOX
date_conditions: 1
days_of_week: mon-fri
start_times: "22:00"
alarm_if_fail: 1
/* Job A: starts as soon as box is RUNNING */
insert_job: job_a
job_type: CMD
box_name: eod_box
command: /scripts/step_a.sh
machine: server01
owner: batch
/* Job B: waits forJob A, but still inside the box */
insert_job: job_b
job_type: CMD
box_name: eod_box
command: /scripts/step_b.sh
machine: server01
owner: batch
condition: success(job_a)
📊 Production Insight
A box in RUNNING status does NOT mean children are running. It means the box's conditions (time, dependencies) are satisfied, so children are eligible to start.
Children still need their own conditions (dependencies, start_times, machine availability, not ON_HOLD) to be met before they actually start.
Rule: When debugging 'box running, children not starting', first check the children's individual conditions, not the box.
🎯 Key Takeaway
BOX jobs are containers — they don't execute commands, they control when child jobs can start.
A box succeeds only when ALL inner jobs succeed; it fails if any inner job fails.
Rule: Child jobs inside a box should generally not have their own start_times — let the box control timing.
Nested boxes — boxes inside boxes
You can place a BOX job inside another BOX job. This creates a hierarchy that lets you organise complex batch flows into logical sub-processes.
In a nested setup, the parent box must be RUNNING before the child box can start. The child box must be RUNNING before its own child jobs can start. The parent box succeeds only when ALL child boxes (and their contents) have succeeded.
In AutoSys terminology, the highest-level BOX that contains all other boxes and jobs is sometimes called the Super Box. It's the single point of control for an entire batch workflow.
📊 Production Insight
Nested boxes add debugging complexity. A failure deep in the hierarchy causes the parent box to fail, but autorep only shows the top-level failure.
To find the root cause, run autorep -J master_box% -s FA to find failed jobs and traverse down.
Rule: Limit nesting depth to 3-4 levels. Deeper nesting makes it harder to trace failures and increases Event Processor load.
🎯 Key Takeaway
You can nest boxes inside boxes to build hierarchical batch workflows.
Parent box must be RUNNING before child box can start; child box must be RUNNING before its children.
Rule: The Super Box (top-level) gives you single-point visibility, but debugging failures requires drilling down each level.
thecodeforge.io
Autosys Box Jobs Nested Boxes
Debugging: box is running but inner jobs aren't starting
This is one of the most common issues you'll encounter. The box is in RUNNING state, but the jobs inside it stay INACTIVE or never start.
Most common causes: 1. The child job's own starting conditions aren't met (check condition attribute) 2. The child job has date_conditions: 1 with a start_times set — it's waiting for that specific time even though the box is running 3. The child job is ON_HOLD or ON_ICE 4. The child job's machine is offline (PEND_MACH) 5. The box_name attribute on the child job has a typo
io/thecodeforge/autosys/debug_box.shBASH
1
2
3
4
5
6
7
8
9
10
11
# Check status of box and all inner jobs
autorep -J eod_box -s
# Check a specific inner job's attributes
autorep -J job_b -d
# Checkif an inner job is on hold or on ice
autostatus -J job_b
# Checkif the machine for an inner job is active
autorep -M server01
📊 Production Insight
The most overlooked cause: child job has date_conditions: 1 and start_times that are later than the box start time. The box runs, but the child waits for the clock.
Another common cause: child job has a condition: success(other_job) where other_job is not in the box and never runs.
Rule: When box RUNNING and children INACTIVE, the problem is NEVER the box. Check children conditions, start_times, ON_HOLD, and machine status.
🎯 Key Takeaway
Box running but inner jobs not starting? Check child's own conditions: start_times, condition dependencies, ON_HOLD, machine offline.
Use autorep -J job -d to see child's full attributes. Look for date_conditions: 1 and start_times.
Rule: Generally, child jobs inside a box should not have their own start_times — let the box control timing.
Why Your Box Job Status Lies to You
Every junior engineer has stared at a BOX job showing SUCCESS while the downstream pipeline blew up. Here's the dirty secret: a BOX job's status reflects its own exit code, not the state of its children. A box with zero jobs inside exits 0. A box with 50 failed jobs that all get 'ignore_exit_code' still exits 0. That status is a polite fiction.
What actually matters is the box's internal state machine. When a BOX starts, it evaluates child dependencies, spawns allowed jobs, and waits. It doesn't crash just because a child fails — unless the child's failure code propagates. The box only truly fails when it can't schedule or when a condition like 'max_run_alarm' fires.
You want truth? Stop reading the box's status. Read the parent job's log or query the box's children via autorep -j BOX_NAME -w. If the box shows RUNNING but kids are idle, you've got a dependency chain issue, not a failing box. The box status is LinkedIn profile — always polished. The children are the work logs.
DetectBoxReality.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// io.thecodeforge — devops tutorial
// Don't trust the box status — query its guts
- name: BOX_PAYMENT_PIPELINE
type: BOX
box_termination: force_children # kills kids on box ABORT
max_run_alarm: 1200 # 20 min, then alarm
ignore_exit_code: [0]
term_run_time: 1800
- name: JOB_VALIDATE_ORDER
type: c
box: BOX_PAYMENT_PIPELINE
command: /app/validate_order.sh
condition: s(BOX_PAYMENT_PIPELINE)
- name: JOB_CHARGE_CARD
type: c
box: BOX_PAYMENT_PIPELINE
command: /app/charge_card.sh
condition: s(JOB_VALIDATE_ORDER)
# Query box status + its running children
# autorep -j BOX_PAYMENT_PIPELINE -w | head -5
Never trust a box's SUCCESS status for upstream dependencies. If your downstream job conditions on s(BOX), you'll trigger on a lie. Always condition on the last real job inside the box.
🎯 Key Takeaway
A box job's status is a facade. Always query the box's children directly via autorep to see real pipeline health.
Nested Box Termination Rules That Will Burn You
You built a three-level deep nested box. The outer box crashes. You assume everything stops. Wrong. Autosys has three termination modes: 'force_children', 'terminate_only_box', and the default — nothing at all.
Without explicit box_termination, when the outer box fails, it just marks itself FAILED. Its children keep running like they're independent contractors who didn't get the memo. Your database gets charged twice because JOB_CHARGE_CARD kept executing inside a dead box.
Always set 'box_termination: force_children' on your outer boxes. This kills all running children when the box aborts. The tradeoff: you can't recover partial work. If that's a problem, use 'terminate_only_box' and handle cleanup in a downstream job.
Another gotcha: nested boxes inherit termination rules from their parent unless they explicitly override. If your inner box has 'box_termination: terminate_only_box' but the outer box forces termination, the outer wins. Test this in a lab. I've seen production databases corrupted because an inner box's termination setting got overridden by an outer box's default.
Child Termination Policy: KILL running children on box abend
🔥Senior Shortcut:
Test nested termination in non-prod with 'autorep -j BOX_NAME -d | grep -i term'. If you see 'default', that's the silent killer. Always set box_termination explicitly on every box level.
🎯 Key Takeaway
If you don't set box_termination, child jobs run forever even after the parent box fails. Always set force_children on boxes handling irreversible work.
The Global Condition Trap in Nested Boxes
You think a condition like 's(BOX_A)' waits for BOX_A to complete? It waits for BOX_A to start. Autosys global conditions ('s', 'e', 'o') evaluate against the last known status of the referenced job. A box that started 3 days ago and is still RUNNING will satisfy 's(BOX_A)' immediately. That's not a bug — it's how the scheduler works.
Now nest that. You have a job inside a box with condition 's(BOX_OUTER)'. BOX_OUTER starts, condition met, job fires. But BOX_OUTER's children might not have run yet. You just triggered work outside the box's logical dependency chain. Welcome to race conditions.
Fix: never use global conditions to reference boxes you control. Use 'send'/'recv' events or condition on the specific child job. 's(JOB_VALIDATE_ORDER)' is concrete. 's(BOX_ORDER)' is guesswork.
If you absolutely must condition on a box completing, use 'e(BOX_NAME)' — which triggers on the box's end status. Even that can bite you: 'e' fires on any termination, including failure. Pair it with status filter: 'e(BOX_NAME, SUCCESS)'.
GlobalConditionTrap.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// io.thecodeforge — devops tutorial
// Bad: starts when box starts, not when work completes
- name: JOB_EXTERNAL_CLEANUP
type: c
condition: s(BOX_PAYMENT_PIPELINE) // fires IMMEDIATELY on box start
command: /app/clean_temp_files.sh
// Good: only fires after CHARGE_CARD succeeds
- name: JOB_CLEANUP_V2
type: c
condition: s(JOB_CHARGE_CARD) // fires after specific child
command: /app/clean_temp_files.sh
// Alternative: wait for box end with status
- name: JOB_CLEANUP_V3
type: c
condition: e(BOX_PAYMENT_PIPELINE, SUCCESS) // wait for box success terminal status
command: /app/clean_temp_files.sh
// autorep -j JOB_EXTERNAL_CLEANUP -w | awk '/Condition/{print}'
Output
Condition: s(BOX_PAYMENT_PIPELINE)
Last Status: SUCCESS
Last Start: 2024-03-15 09:30:00
Note: This condition met when BOX started at 09:29:58, not when it completed at 09:35:12
⚠ Production Trap:
A box's 's()' condition is satisfied at box start, not box completion. Use 'e(BOX_NAME, SUCCESS)' for true completion dependency. Test with autorep -j JOB_NAME -w | grep Condition to see what fired it.
🎯 Key Takeaway
Never condition on 's(BOX)'. Always condition on a specific child job or use 'e(BOX, SUCCESS)' if you must wait for box completion.
● Production incidentPOST-MORTEMseverity: high
The Box That Ran at Midnight but Inside It Stayed Dead
Symptom
Box started successfully at 18:00 (6pm). autorep showed box status RUNNING. Child jobs showed INACTIVE (IN), not STARTING. No errors in logs. Operator assumed the box was misconfigured or the Event Processor was stuck. They restarted the Event Processor, rebooted the agent machine, checked disk space, all without success.
Assumption
The operator assumed that when a box is RUNNING, all child jobs would start immediately or follow their own condition dependencies. They didn't know that a child job with date_conditions: 1 and start_times: "22:00" would wait until 10pm regardless of the box's state. They also didn't know how to check a child job's attributes with autorep -J child -d.
Root cause
The child job was defined with date_conditions: 1 and start_times: "22:00". The ETL box started at 18:00. The child job was waiting for its own start time (22:00) to be reached, not just the box's RUNNING status. The box's start condition and the child's start condition were both required. The operator never checked the child's JIL definition. Five hours later at 22:00, the child jobs started and succeeded, but the operator had already wasted 2 hours of troubleshooting time.
Fix
1. Removed date_conditions: 1 and start_times from all child jobs inside the box. The box's schedule should control overall timing.
2. For jobs that genuinely need to start at a specific time within a larger window, documented the behaviour in team runbook.
3. Added a pre-flight check script: autorep -J child -d | grep -E 'start_times|date_conditions' to flag child jobs with their own schedules.
4. Added a monitoring alert: if box RUNNING > 10 minutes and no children STARTING, check child job conditions and start_times.
Key lesson
Child jobs inherit the box's RUNNING status, but they still have their own conditions (start_times, dependencies). Both must be satisfied.
Always check child job attributes with autorep -J job -d when they don't start. Look for date_conditions: 1 and start_times.
Generally, child jobs inside a box should not have their own start_times. Let the box control timing.
When a box is RUNNING but children are INACTIVE, the problem is not the box — it's the children's prerequisites.
Production debug guideSymptom → Action mapping for common box failures in production AutoSys environments.5 entries
Symptom · 01
Box RUNNING but children not starting — all INACTIVE
→
Fix
Check if child jobs have their own start_times: autorep -J child -d | grep start_times. Also check box condition: child may have condition: success(other_job) that not met yet. Check child ON_HOLD/ON_ICE status: autostatus -J child.
Symptom · 02
Box FAILED but some children succeeded — expected partial failure
→
Fix
Box fails as soon as ANY child job fails. Remaining children (including boxes) stop. Check autorep -J % -d inside box to find which child failed first. Use sendevent -E CHANGE_STATUS -J box -s FAILURE to mark box as failed? Actually, box fails automatically when child fails. To keep box running despite child failure, use ignore_failure: 1 on the child (use sparingly).
Symptom · 03
Nested box shows SUCCESS but jobs inside child box failed
→
Fix
Impossible — if a child box's inner job fails, the child box fails, and the parent box fails. Verify with autorep -J child_box -d. If child box SUCCESS but inner jobs FAIL, your condition logic may be wrong; the child box may have condition: success(inner_job) that is not evaluated because failed inner job didn't run.
Symptom · 04
Box never starts — stays INACTIVE after scheduled time
→
Fix
Check if box has date_conditions: 1 and start_times correctly set. Check if box has condition: success(other_box) that is not met. Check if box is ON_HOLD/ON_ICE. Check if run calendar is active: autorep -C calendar_name.
Symptom · 05
Box stays RUNNING forever — never completes
→
Fix
One or more child jobs are stuck in RUNNING. Check autorep -J % -s RU for jobs inside box. The stuck job may have hung (infinite loop, waiting for I/O, deadlock). Use term_run_time to kill hung jobs automatically.
★ AutoSys Box Debug Cheat SheetFast diagnostics for box issues in production AutoSys environments.
Child box may have its own dependency not yet met. Ensure child box's box_name points to parent box. Remove own start_times if not needed.
AutoSys Box Job Statuses
BOX Job State
What It Means
Can Inner Jobs Run?
How Box Enters This State
RUNNING
Box is active, scheduling conditions are met
Yes — if their own conditions are also met
Start time reached, dependencies satisfied
SUCCESS
All inner jobs and child boxes succeeded
No — box has completed
All children SUCCESS
FAILURE
At least one inner job or child box failed
No — remaining jobs don't start
Any child FAILURE
INACTIVE
Box hasn't been triggered yet (default state)
No
Initial state; never started
ON_HOLD
Box manually placed on hold
No — box won't start even if conditions met
Manual: ON_HOLD
ON_ICE
Box suspended (like ON_HOLD but more aggressive)
No — box won't start
Manual: ON_ICE
TERMINATED
Box was killed while running (manual or term_run_time)
No — child jobs also terminated
Manual KILLJOB or term_run_time exceeded
⚙ Quick Reference
6 commands from this guide
File
Command / Code
Purpose
iothecodeforgeautosysbox_control.jil
/* Box starts at 10 PM on weeknights */
How BOX jobs control child job execution
iothecodeforgeautosysnested_boxes.jil
/* Parent box — the overall EOD run */
Nested boxes
iothecodeforgeautosysdebug_box.sh
autorep -J eod_box -s
Debugging
DetectBoxReality.yml
- name: BOX_PAYMENT_PIPELINE
Why Your Box Job Status Lies to You
NestedTerminationRules.yml
- name: OUTER_BOX
Nested Box Termination Rules That Will Burn You
GlobalConditionTrap.yml
- name: JOB_EXTERNAL_CLEANUP
The Global Condition Trap in Nested Boxes
Key takeaways
1
BOX jobs are containers
they don't execute commands, they control when child jobs can start.
2
A box enters SUCCESS only when ALL inner jobs have succeeded; it enters FAILURE if any inner job fails.
3
You can nest boxes inside boxes to build hierarchical batch workflows.
4
Child jobs inside a box should generally not have their own start_times
let the box control timing.
5
When a box is RUNNING but children are INACTIVE, the problem is the children's conditions, not the box.
Common mistakes to avoid
5 patterns
×
Setting date_conditions: 1 and start_times on a child job inside a box
Symptom
Box starts at 6pm, but child jobs don't start until 10pm (or never if box starts after the time window). Operator sees box RUNNING and assumes children should run immediately.
Fix
Remove date_conditions and start_times from child jobs inside boxes. The box's schedule controls timing. If a child must start at a specific time, create a separate box for that timeframe.
×
Putting a machine attribute on a BOX job
Symptom
No immediate failure, but BOX job's machine attribute is ignored. Operator may think box runs on a specific machine and be confused when it doesn't.
Fix
BOX jobs never execute commands, so machine attribute is meaningless. Remove it to avoid confusion. Only child jobs need machine attributes.
×
Not setting a condition on the second-to-last job in a chain, causing jobs to run in parallel unexpectedly
Symptom
Inside a box, Job A, Job B, and Job C are independent. Operator expects A → B → C, but all run in parallel because no conditions are set.
Fix
Add condition: success(previous_job) to each job to enforce ordering. If parallel execution is desired, no condition needed, but be explicit in comments.
×
Confusing box state with child job state
Symptom
Operator sees box RUNNING and assumes children are also RUNNING. They don't check child status and miss that a child failed or is ON_HOLD.
Fix
Always check child status separately: autorep -J box_name% to list all children with their statuses. Never assume children are RUNNING just because box is.
×
Nesting boxes too deeply (>5 levels)
Symptom
Event Processor performance degrades. autorep queries for box status take minutes. Debugging failures requires traversing 5 levels of nesting.
Fix
Limit nesting depth to 3-4 levels. Break complex workflows into separate top-level boxes connected by conditions instead of deep nesting. Each level adds Event Server query overhead.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01JUNIOR
What is a BOX job in AutoSys and what does it do?
Q02JUNIOR
When is a BOX job in SUCCESS state?
Q03SENIOR
If a BOX job is RUNNING but its child jobs aren't starting, what would y...
Q04SENIOR
What is a Super Box in AutoSys?
Q05JUNIOR
Can a BOX job contain another BOX job?
Q01 of 05JUNIOR
What is a BOX job in AutoSys and what does it do?
ANSWER
A BOX job is a container for grouping other jobs (commands, files, other boxes). It doesn't execute any command itself. It controls when child jobs can run — children can only start when the box is in RUNNING state. The box's own start conditions (time, dependencies) determine when it becomes RUNNING. The box succeeds only when all its child jobs have succeeded. If any child fails, the box fails immediately. Boxes are used to organise complex batch workflows into logical groups.
Q02 of 05JUNIOR
When is a BOX job in SUCCESS state?
ANSWER
A BOX job reaches SUCCESS only when ALL of its immediate child jobs have completed successfully (status SUCCESS). This includes child jobs that are themselves boxes. If any child job fails, the box immediately transitions to FAILURE and the remaining child jobs (including those not yet started) will not run. Note that a box with no children (empty) will never transition to SUCCESS; it would stay RUNNING forever.
Q03 of 05SENIOR
If a BOX job is RUNNING but its child jobs aren't starting, what would you check?
ANSWER
I would check the child jobs' individual conditions, not the box. Steps: (1) Run autorep -J child -d to see child's attributes — look for date_conditions: 1 with start_times (time-based waiting). (2) Check child's condition dependencies — is it waiting for another job that hasn't succeeded? (3) Check if child is ON_HOLD or ON_ICE with autostatus -J child. (4) Check child's machine status with autorep -M machine_name — is the agent down (PEND_MACH)? (5) Check box_name attribute spelling on child job. The box's RUNNING status only makes children eligible — their own conditions must also be satisfied.
Q04 of 05SENIOR
What is a Super Box in AutoSys?
ANSWER
Super Box is informal terminology (not an official AutoSys attribute) for the highest-level BOX job that contains all other boxes and jobs for a given batch workflow. It provides a single point of control and visibility: start the Super Box to run the entire workflow; monitor its status to know overall success/failure. However, a Super Box failure shows only that something failed — you still need to drill down into child boxes to find the root cause. In production environments, the Super Box is often scheduled with start_times and days_of_week to trigger daily batch runs.
Q05 of 05JUNIOR
Can a BOX job contain another BOX job?
ANSWER
Yes, you can nest boxes inside boxes. This creates hierarchical batch workflows. The parent box must be RUNNING before the child box can start. The child box must be RUNNING before its own child jobs can start. The parent box only succeeds when ALL child boxes (and their contents) have succeeded. Limitations: Nesting beyond 5 levels can cause Event Processor performance issues. Also, debugging failures requires traversing each nesting level to find the failed job.
01
What is a BOX job in AutoSys and what does it do?
JUNIOR
02
When is a BOX job in SUCCESS state?
JUNIOR
03
If a BOX job is RUNNING but its child jobs aren't starting, what would you check?
SENIOR
04
What is a Super Box in AutoSys?
SENIOR
05
Can a BOX job contain another BOX job?
JUNIOR
FAQ · 6 QUESTIONS
Frequently Asked Questions
01
What is a BOX job in AutoSys?
A BOX job is a container for other jobs. It doesn't execute any command itself — it groups jobs together and controls when they can run. Child jobs inside a box can only start when the box is in RUNNING state.
Was this helpful?
02
When does a BOX job move to SUCCESS?
A BOX job moves to SUCCESS only when ALL of its inner jobs have completed successfully. If any inner job fails, the box moves to FAILURE and remaining un-started inner jobs will not run.
Was this helpful?
03
My BOX job is RUNNING but inner jobs aren't starting — why?
Common causes: the inner job has date_conditions: 1 and is waiting for a specific start_times; the inner job has a condition that isn't met yet; the inner job is ON_HOLD or ON_ICE; the inner job's machine is offline; or the box_name attribute has a typo.
Was this helpful?
04
What is a Super Box in AutoSys?
Super Box is informal terminology for the highest-level BOX job that contains all other boxes and jobs for a given batch workflow. It provides a single point of control and visibility for the entire process.
Was this helpful?
05
Should child jobs inside a box have their own start_times?
Generally no. When a job is inside a box, the box controls the overall timing. Setting start_times on a child job means it will wait until that specific time even if the box is already running, which often causes confusion. Child jobs inside boxes typically rely on conditions (success of previous jobs) rather than clock times.
Was this helpful?
06
What's the difference between ON_HOLD and ON_ICE for a box?
Both prevent the box from starting. ON_HOLD is a temporary hold — the box can be released with sendevent -E RELEASE. ON_ICE is more permanent — the box is ignored as if it doesn't exist; dependencies that reference this box treat it as not satisfied. Use ON_ICE for boxes you want to disable entirely. Use ON_HOLD for pausing while keeping dependencies active.