AutoSys Job Types — CMD, BOX, and File Watcher Explained
- AutoSys has three native job types: CMD (runs a command), BOX (container that controls child jobs), and FW File Watcher (watches for file arrival)
- BOX jobs don't execute commands — they group jobs together and their status reflects the aggregate outcome of all inner jobs
- Child jobs are linked to a BOX with the box_name attribute; without it they run independently
Every job in AutoSys has a job_type attribute that determines its fundamental behaviour. There are only three native job types, and understanding what each one does — and more importantly when to use each — is essential for building effective AutoSys workflows.
In practice, most AutoSys environments are built from a combination of all three types working together: BOX jobs contain CMD jobs, and File Watcher jobs trigger other jobs when files arrive.
CMD — the command job
CMD (or just 'c' in JIL shorthand) is the most common job type. It executes a command, script, or program on a specified machine.
The job runs as the specified owner user on the machine. Whatever exit code the command returns determines the job status: exit code 0 means SUCCESS, any non-zero exit code means FAILURE.
CMD jobs are used for: - Shell scripts - Python or Perl scripts - Java programs invoked from command line - Database scripts called via sqlplus, psql, or similar - Any executable that can be called from a command line
/* ── Simple shell script job ── */ insert_job: run_etl_extract job_type: CMD command: /opt/scripts/etl/extract_data.sh machine: etl-server-01 owner: etluser date_conditions: 1 days_of_week: all start_times: "23:00" std_out_file: /logs/autosys/run_etl_extract.out std_err_file: /logs/autosys/run_etl_extract.err alarm_if_fail: 1 n_retrys: 1 term_run_time: 120 /* ── Python script job with arguments ── */ insert_job: generate_risk_report job_type: CMD command: "/usr/bin/python3 /opt/reports/risk_report.py --date $(date +%Y%m%d)" machine: report-server-01 owner: reportuser condition: success(run_etl_extract) alarm_if_fail: 1
/* CMD job exits non-zero → status becomes FAILURE → alarm fires */
BOX — the container job
A BOX job is a container that holds other jobs (including other BOX jobs). The BOX itself doesn't execute any command — it controls when the jobs inside it can start.
Key BOX behaviour to internalise: - Jobs inside a box will only run if the box is in RUNNING state - The box enters RUNNING state when its own start conditions are met - The box moves to SUCCESS only when ALL inner jobs have succeeded - The box moves to FAILURE if any inner job fails - If you put a box inside another box, the parent box must be RUNNING for the inner box to run
BOX jobs are how you group related batch processes together. A typical end-of-day processing flow might have one parent box containing several child boxes, each of which contains the actual CMD jobs.
/* ── Parent BOX: controls when the whole flow runs ── */ insert_job: eod_processing_box job_type: BOX date_conditions: 1 days_of_week: mon-fri /* business days only */ start_times: "22:00" alarm_if_fail: 1 description: "End-of-day batch processing — runs all ETL and reports" /* ── CMD jobs INSIDE the box ── */ insert_job: eod_extract job_type: CMD box_name: eod_processing_box /* this links it to the parent box */ command: /opt/scripts/eod_extract.sh machine: etl-server-01 owner: batchuser insert_job: eod_transform job_type: CMD box_name: eod_processing_box command: /opt/scripts/eod_transform.sh machine: etl-server-01 owner: batchuser condition: success(eod_extract) /* waits for extract to succeed */ insert_job: eod_load job_type: CMD box_name: eod_processing_box command: /opt/scripts/eod_load.sh machine: etl-server-01 owner: batchuser condition: success(eod_transform)
22:00 — eod_processing_box starts (RUNNING)
22:00 — eod_extract starts immediately (no condition)
22:08 — eod_extract succeeds → eod_transform starts
22:25 — eod_transform succeeds → eod_load starts
22:40 — eod_load succeeds → box moves to SUCCESS */
File Watcher — the event-driven trigger
A File Watcher job does exactly what the name says: it watches for a file on a machine. When the file appears (and optionally reaches a minimum size, indicating it's finished being written), the File Watcher job completes with SUCCESS, which then triggers dependent CMD jobs.
File Watcher jobs are essential in integration scenarios where an upstream system drops a file that downstream processing depends on. Instead of scheduling the downstream job at a fixed time and hoping the file is there, you let the File Watcher trigger it the moment the file actually arrives.
Key File Watcher attributes: - watch_file — the full path and filename to watch for (supports wildcards) - watch_interval — how often to check (in seconds, default 60) - min_file_size — minimum file size in bytes before declaring success - watch_file_min_size — same as above, alternate attribute name
/* ── File Watcher: wait for upstream file ── */ insert_job: watch_for_trades_file job_type: FW /* FW = File Watcher */ watch_file: /data/inbound/trades_*.csv watch_interval: 30 /* check every 30 seconds */ min_file_size: 1024 /* must be at least 1 KB */ machine: data-landing-server owner: batchuser date_conditions: 1 days_of_week: mon-fri run_window: "08:00 - 20:00" /* only watch during business hours */ alarm_if_fail: 1 description: "Watches for daily trades file from upstream system" /* ── CMD job that runs after file arrives ── */ insert_job: process_trades_file job_type: CMD command: /opt/scripts/process_trades.sh machine: processing-server-01 owner: batchuser condition: success(watch_for_trades_file) /* triggers when file found */ alarm_if_fail: 1
09:47:32 — watch_for_trades_file: SUCCESS
09:47:33 — process_trades_file: starting (condition met) */
| Job Type | JIL code | Does it execute a command? | Best used for |
|---|---|---|---|
| CMD | CMD or c | Yes — runs the command attribute | Shell scripts, programs, database calls |
| BOX | BOX or b | No — container only | Grouping related jobs, controlling batch flow timing |
| File Watcher | FW or f | No — watches for file | Event-driven triggers based on file arrival |
🎯 Key Takeaways
- AutoSys has three native job types: CMD (runs a command), BOX (container that controls child jobs), and FW File Watcher (watches for file arrival)
- BOX jobs don't execute commands — they group jobs together and their status reflects the aggregate outcome of all inner jobs
- Child jobs are linked to a BOX with the box_name attribute; without it they run independently
- File Watcher jobs are the right pattern for event-driven integration scenarios where processing should start when a file arrives, not at a fixed time
⚠ Common Mistakes to Avoid
- ✕Adding a machine attribute to a BOX job — BOX jobs don't execute commands so they don't need a machine; adding one is harmless but misleading
- ✕Not setting min_file_size on File Watcher jobs — an upstream system might create an empty file before writing content, triggering the watcher prematurely
- ✕Forgetting to set box_name on child CMD jobs — without this attribute, the job won't be inside the box and won't be controlled by it
- ✕Expecting a File Watcher job to re-trigger multiple times in one day — by default it succeeds once and stays in SUCCESS; it won't re-fire until the next scheduling cycle
Interview Questions on This Topic
- QWhat are the three job types in AutoSys?
- QWhat is a BOX job in AutoSys and what does it do?
- QWhat is a File Watcher job and when would you use one?
- QIf a BOX job is in RUNNING state but inner CMD jobs aren't starting, what would you check?
- QWhat attribute links a CMD job to its parent BOX job?
Frequently Asked Questions
What are the three types of jobs in AutoSys?
The three job types are: CMD (command job — executes a command or script), BOX (container job — groups other jobs and controls their scheduling), and FW (File Watcher — watches for a file to appear and triggers dependent jobs when it does).
Does a BOX job need a machine attribute?
No. BOX jobs don't execute any command, so they don't need a machine. Only CMD and File Watcher jobs need a machine specified.
What happens to inner jobs if a BOX job fails?
If a BOX job fails (because one of its inner jobs failed), the remaining inner jobs that haven't started yet will not start. The box stays in FAILURE state. You need to fix the underlying issue and then restart or force-start the box.
How does a File Watcher job know the file has finished being written?
The min_file_size attribute is your safeguard. The File Watcher won't declare SUCCESS until the file is at least the specified size in bytes. Set this to larger than an empty or incomplete file would be to avoid premature triggering.
Can a BOX job contain other BOX jobs?
Yes. You can nest boxes inside boxes to create hierarchical batch workflows. The outer box controls the overall schedule, inner boxes group related jobs, and CMD jobs do the actual work. This nesting can go multiple levels deep.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.