Junior 5 min · March 19, 2026

AutoSys Box Jobs — Child date_conditions Override Timing

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Box RUNNING for 4 hours while children stayed INACTIVE.

Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Drawn from code that ran under real load.

✓ Production

production tested

May 23, 2026

last updated

1,554

articles · all by Naren

● Production Incident 🔎 Debug Guide ⚙ Triage Commands

⚡Quick Answer

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

Box Job Hierarchy

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

/* Box starts at 10 PM 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 for Job 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.

io/thecodeforge/autosys/nested_boxes.jilBASH

/* Parent box — the overall EOD run */
insert_job: master_eod_box
job_type: BOX
date_conditions: 1
days_of_week: mon-fri
start_times: "21:00"

/* Child box 1 — ETL processing */
insert_job: etl_box
job_type: BOX
box_name: master_eod_box       /* inside master box */

/* Child box 2 — reporting (runs after ETL) */
insert_job: reporting_box
job_type: BOX
box_name: master_eod_box
condition: success(etl_box)    /* waits for ETL box to complete */

/* Jobs inside etl_box */
insert_job: etl_extract
job_type: CMD
box_name: etl_box
command: /scripts/extract.sh
machine: etl01
owner: batch

The topmost parent box is called Super Box

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.

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

# 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

# Check if an inner job is on hold or on ice
autostatus -J job_b

# Check if 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

// 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

Output

JOB: BOX_PAYMENT_PIPELINE

STATUS: RUNNING

CHILDREN: JOB_VALIDATE_ORDER (SUCCESS), JOB_CHARGE_CARD (RUNNING)

Production Trap:

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.

NestedTerminationRules.ymlYAML

// io.thecodeforge — devops tutorial
// Termination inheritance trap

- name: OUTER_BOX
  type: BOX
  box_termination: force_children   # kills everything on abort
  
  - name: INNER_BOX
    type: BOX
    box_termination: terminate_only_box  # overridden! won't matter
    
    - name: JOB_CRITICAL_WRITE
      type: c
      command: /app/write_to_db.sh
      condition: s(INNER_BOX)

// When OUTER_BOX aborts:
// INNER_BOX stops (force_children wins)
// JOB_CRITICAL_WRITE gets killed mid-write
// No cleanup possible
// autorep -j OUTER_BOX -d | grep 'Termination'

Output

Termination Method: force_children

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

// 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.

Box RUNNING, children INACTIVE−

Immediate action

Check child's own start_times and conditions

Commands

autorep -J child_name -d | grep -E 'start_times|condition'

autostatus -J child_name

Fix now

Remove child's start_times if box controls timing. Ensure child's condition dependencies are met (check upstream job status). Remove ON_HOLD if set.

Box never starts — INACTIVE after scheduled time+

Box stuck RUNNING — never completes+

Box FAILED but need it to continue despite child failure+

Nested box — parent box RUNNING but child box INACTIVE+

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

Key takeaways

BOX jobs are containers

they don't execute commands, they control when child jobs can start.

A box enters SUCCESS only when ALL inner jobs have succeeded; it enters FAILURE if any inner job fails.

You can nest boxes inside boxes to build hierarchical batch workflows.

Child jobs inside a box should generally not have their own start_times

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.

FAQ · 6 QUESTIONS

Frequently Asked Questions

What is a BOX job in AutoSys?

When does a BOX job move to SUCCESS?

My BOX job is RUNNING but inner jobs aren't starting — why?

What is a Super Box in AutoSys?

Should child jobs inside a box have their own start_times?

What's the difference between ON_HOLD and ON_ICE for a box?

COMPLETE GUIDE

The Complete AutoSys Workload Automation Guide for Engineers →

JIL syntax, sendevent, autorep, box jobs, file watchers, scheduling, HA, security, cloud workload automation, and 22 interview questions — the definitive AutoSys reference for production engineers.

Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Drawn from code that ran under real load.

✓ Verified

production tested

May 23, 2026

last updated

1,554

articles · all by Naren

🔥

That's AutoSys. Mark it forged?

5 min read · try the examples if you haven't