Mid-level 3 min · March 19, 2026

AutoSys JIL delete_box — Irreversible Pipeline Delete

The 'nightly_reporting' box vanished after delete_box.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
⚡Quick Answer
  • JIL (Job Information Language) is the declarative language for defining, modifying, and deleting AutoSys jobs
  • Subcommands: insert_job, update_job, delete_job, delete_box, and more
  • Attributes: job_type, command, machine, condition, start_times, etc.
  • Script mode (jil < file.jil) is production-grade; interactive mode is for testing only
  • Performance insight: JIL processing is near-instantaneous – bottleneck is network latency to the Event Server
  • Production insight: One wrong delete_box command can wipe out an entire job chain with no undo
  • Biggest mistake: Assuming JIL is case-insensitive for job names – they ARE case-sensitive
Plain-English First

JIL is like filling out a form for each job you want AutoSys to manage. The form has specific fields: what's the job's name, what command should it run, which machine should run it, when should it run, and what should happen if it fails. JIL is the language that fills out that form.

If you want to define, modify, or delete jobs in AutoSys, you use JIL — Job Information Language. It's not a general-purpose programming language, it's a declarative configuration language specifically designed for describing AutoSys jobs.

JIL is the foundation of everything in AutoSys. Whether you use the Web UI or the command line, everything ultimately becomes JIL under the hood. Learning to write JIL directly is faster, more powerful, and version-controllable. Every serious AutoSys professional works in JIL.

How to run JIL — two methods

There are two ways to submit JIL to AutoSys:

Interactive mode: Type jil at the command line to open the JIL prompt, then enter your definitions line by line, then type exit. Good for quick edits or testing.

Script mode: Write your JIL in a text file (by convention with a .jil extension), then redirect it into the jil command. This is how all production job definitions should be managed — text files that can be stored in version control.

jil_usage.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Method 1: Interactive mode
jil
# JIL> insert_job: my_test_job
# JIL> job_type: CMD
# JIL> command: echo hello
# JIL> machine: server01
# JIL> owner: batchuser
# JIL> exit

# Method 2: Script file (recommended for production)
jil < /opt/jil_scripts/my_jobs.jil

# Method 3: Script with specific AutoSys instance
jil -S ACE < /opt/jil_scripts/my_jobs.jil

# Syntax check without actually loading (dry run)
jil -syntax_check < /opt/jil_scripts/my_jobs.jil
Output
/* AutoSys/JIL: Successfully inserted job: my_test_job */
/* AutoSys/JIL: 1 job(s) processed, 0 error(s) */
Always use script files for production job definitions
Interactive mode is convenient for quick tests but terrible for auditing. If you define a production job interactively and something goes wrong, there's no record of exactly what you typed. Use text files stored in Git — every change is tracked, every rollback is possible.
Production Insight
Using interactive mode for production changes creates an audit gap — no record of what was typed.
Always script-mode JIL files stored in version control.
The first thing a senior engineer does after a job failure is check the JIL file, not the WCC screen.
Key Takeaway
Script mode is the only production-safe way to manage JIL.
Interactive mode is for prototyping only.
Rule: if it's not in a .jil file, it didn't happen.
Which method to use?
IfQuick test or one-off command
→
UseInteractive mode (jil prompt)
IfPermanent job definition or change
→
UseScript mode (jil < file.jil)
IfBulk import of multiple jobs
→
UseScript mode with a single .jil file
IfSyntax validation before deployment
→
UseScript mode with -syntax_check flag
JIL Submit Flow JIL Submit Flow. From .jil file to Event Server · Write JIL file · job attributes in plain text · pipe file into jil processor · JIL processor parses · validates syntax and attributes THECODEFORGE.IOJIL Submit FlowFrom .jil file to Event Server Write JIL filejob attributes in plain text jil < myjobs.jilpipe file into jil processor JIL processor parsesvalidates syntax and attributes Stored in Event Serverjob definition persisted to DB Event Processor picks upjob is now schedulableTHECODEFORGE.IO
thecodeforge.io
JIL Submit Flow
Jil Introduction Syntax

JIL syntax rules

JIL follows strict but simple syntax rules:

  1. Every job definition begins with a subcommand (insert_job, update_job, etc.) followed by a colon and the job name
  2. After the subcommand line, attribute statements follow — one per line (or multiple separated by spaces)
  3. The next subcommand begins a new job definition
  4. Comments start with / ... /
  5. Attribute values containing spaces must be enclosed in double quotes
  6. JIL is case-insensitive for keywords but case-sensitive for job names and machine names
jil_syntax_rules.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
/* This is a JIL comment — ignored by the processor */

/* ── Job 1: simple command job ── */
insert_job: extract_sales_data       /* subcommand: job name */
job_type: CMD                         /* attribute: job type */
command: "/opt/scripts/extract.sh -d 2026-03-19"  /* space in value needs quotes */
machine: etl-server-01
owner: batchuser
date_conditions: 1
days_of_week: all
start_times: "01:00"
std_out_file: /logs/autosys/extract_sales_data.out
std_err_file: /logs/autosys/extract_sales_data.err
alarm_if_fail: 1
description: "Extracts previous day sales data from OLTP to staging"

/* ── Job 2: depends on Job 1 ── */
insert_job: transform_sales_data
job_type: CMD
command: /opt/scripts/transform.sh
machine: etl-server-01
owner: batchuser
condition: success(extract_sales_data)  /* starts only when Job 1 succeeds */
alarm_if_fail: 1
Output
/* AutoSys/JIL: Successfully inserted job: extract_sales_data */
/* AutoSys/JIL: Successfully inserted job: transform_sales_data */
/* AutoSys/JIL: 2 job(s) processed, 0 error(s) */
Think of JIL as filling out a form
  • insert_job: creates a blank form
  • update_job: edits an existing form's fields
  • delete_job: shreds the form
  • delete_box: shreds the folder and all forms inside
  • override_job: sticks a Post-it note on the form for the next run only
Production Insight
Forgetting quotes around commands with spaces causes silent failures — the command gets truncated.
Case mismatch in job names creates duplicate definitions that are invisible until one completes.
Rule: always quote every value that could contain a space.
Key Takeaway
JIL syntax is simple but unforgiving.
Quotes and case sensitivity are the top two gotchas.
Rule: quote any value with spaces; job names are case-sensitive.

JIL subcommands reference

JIL subcommands tell the processor what action to take. The most commonly used ones are:

  • insert_job — creates a new job definition
  • update_job — modifies an existing job definition (only changes specified attributes)
  • delete_job — removes a job from the Event Server
  • delete_box — removes a box job AND all jobs inside it
  • override_job — creates a one-time override for a specific job run
  • insert_machine — registers a new agent machine
  • update_machine — modifies a machine definition
  • delete_machine — removes a machine definition

For most day-to-day work, you'll primarily use insert_job, update_job, and delete_job.

jil_subcommands.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
/* Update an existing job — only changed attributes needed */
update_job: extract_sales_data
start_times: "00:30"          /* moved from 01:00 to 00:30 */

/* Delete a single job */
delete_job: old_legacy_report

/* Delete a box AND all its child jobs */
delete_box: legacy_eod_box

/* Register a new machine/agent */
insert_machine: new-server-02
max_load: 100
factor: 1.00
Output
/* AutoSys/JIL: Successfully updated job: extract_sales_data */
/* AutoSys/JIL: Successfully deleted job: old_legacy_report */
/* AutoSys/JIL: Successfully deleted box: legacy_eod_box (3 inner jobs deleted) */
/* AutoSys/JIL: Successfully inserted machine: new-server-02 */
delete_box deletes child jobs too — be careful
When you use delete_box, all jobs inside the box are deleted from the Event Server along with the box itself. If you want to remove only the box but keep the child jobs as standalone jobs, use delete_job on the box name instead.
Production Insight
delete_box is the most dangerous command in JIL — it silently deletes all child jobs with no confirmation.
One mistyped box name can wipe out months of job definitions.
Rule: always backup with autorep -q before running delete_box.
Key Takeaway
Use delete_box only when you intend to remove the entire job tree.
For box removal only, use delete_job.
Rule: when in doubt, backup first.
Which subcommand should you use?
IfCreating a new job
→
Useinsert_job
IfModifying an existing job's attribute
→
Useupdate_job
IfRemoving a single job permanently
→
Usedelete_job
IfRemoving a box and all its children
→
Usedelete_box
IfRemoving only the box, keeping children
→
Usedelete_job on box name
IfTemporary one-time change
→
Useoverride_job

Viewing the JIL definition of an existing job

One of the most useful things you can do in AutoSys is dump the JIL definition of any existing job. This is how you see exactly what attributes are set, copy a job as a template, or audit what's changed.

view_jil.shBASH
1
2
3
4
5
6
7
8
9
10
# Dump the JIL definition of a specific job
autorep -J extract_sales_data -q

# Dump all jobs in a box
autorep -J eod_processing_box% -q

# Dump all jobs matching a pattern and save to file
autorep -J etl_% -q > /tmp/etl_jobs_backup.jil

# This is also how you back up job definitions before making changes
Output
/* ---- extract_sales_data ---- */
insert_job: extract_sales_data job_type: c
command: /opt/scripts/extract.sh -d 2026-03-19
machine: etl-server-01
owner: batchuser
date_conditions: 1
days_of_week: all
start_times: "01:00"
alarm_if_fail: 1
Production Insight
autorep -q is the single most important debugging command.
When a job fails unexpectedly, dump its JIL to see if someone changed an attribute without telling you.
Rule: always run autorep -q before modifying a job.
Key Takeaway
Viewing JIL definitions is the first step in any job audit.
Always back up before changes.
Rule: autorep -q is your safety net.

JIL best practices for production

Treat JIL files as code: use version control, code reviews, and CI checks.

  • Store each job in its own .jil file, or logically grouped files per box.
  • Use descriptive job names that include the system and purpose (e.g., etl_sales_extract).
  • Always set alarm_if_fail: 1 so failures trigger alerts.
  • Set max_run_alarm to detect hung jobs (in minutes).
  • Use termination methods like kill_job for graceful shutdown.
  • Document dependencies using comments in JIL.
  • Avoid hardcoding paths; use global variables ($VAR) when possible.
  • Validate syntax before every import with jil -syntax_check < file.jil.
production_job_example.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* ──────────────────────────────────────────────
   etl_sales_daily.jil — Production job definition
   Version 2.1 | Last modified: 2026-04-20
   ────────────────────────────────────────────── */

insert_job: etl_sales_daily
job_type: CMD
command: "/opt/scripts/etl/run_sales_pipeline.sh -env prod"
machine: batch-prod-01
owner: batchadmin
date_conditions: 1
days_of_week: mon,tue,wed,thu,fri
start_times: "03:00"
max_run_alarm: 120
alarm_if_fail: 1
std_out_file: /logs/autosys/etl_sales_daily.out
std_err_file: /logs/autosys/etl_sales_daily.err
condition: success(etl_refresh_dimensions)
description: "ETL pipeline for daily sales data — exports to staging for analytics"
Output
/* AutoSys/JIL: Successfully inserted job: etl_sales_daily */
/* AutoSys/JIL: 1 job(s) processed, 0 error(s) */
Treat JIL like infrastructure code
Review every JIL change in a pull request, run a syntax check in CI, and store all .jil files in the same repo as your application code. This discipline reduces on-call incidents by an order of magnitude.
Production Insight
Unmonitored jobs silently queue up and cause backpressure.
Missing alarm_if_fail means a job failure goes unnoticed until a downstream job fails.
Rule: every production job must have alarm_if_fail: 1 and a reasonable max_run_alarm.
Key Takeaway
Production JIL needs the same rigor as application code.
Alarms, version control, and clear naming prevent most on-call fires.
Rule: write JIL like it's going to fail — because it will.
Setting alarms based on criticality
IfJob is business-critical (revenue, compliance)
→
Usealarm_if_fail: 1, max_run_alarm: 30
IfJob is important but not urgent (reports)
→
Usealarm_if_fail: 1, max_run_alarm: 60
IfJob is informational (log archival)
→
Usealarm_if_fail: 0, max_run_alarm: 0
● Production incidentPOST-MORTEMseverity: high

Accidental deletion of entire batch pipeline using delete_box

Symptom
All jobs in the 'nightly_reporting' box disappeared after a scheduled maintenance window. Downstream jobs began failing with 'waiting for predecessor' status, and the batch team was paged at 3 AM.
Assumption
The engineer assumed that delete_box removes only the container box, leaving child jobs untouched. This is the intuitive expectation for anyone coming from databases or file systems where deleting a folder asks for confirmation about children.
Root cause
delete_box is a recursive command that removes the box AND all jobs within it from the Event Server. There is no 'Are you sure?' prompt — the deletion is immediate and irreversible without a backup.
Fix
Restored from a backup taken earlier in the day using autorep -q output. The engineer had, fortunately, run autorep -J nightly_reporting% -q > backup.jil before starting maintenance. Re-imported jil < backup.jil to restore all jobs and the box. No data was permanently lost, but the batch run was delayed by 45 minutes.
Key lesson
  • Always back up job definitions with autorep -q before any delete operation.
  • Use delete_job instead of delete_box when you intend to remove only the box container.
  • Implement a manual confirmation step in automation scripts before delete_box runs.
  • Document the destructive nature of delete_box in your team's runbook.
Production debug guideCommon errors when running `jil < file.jil` and how to fix them5 entries
Symptom · 01
JIL syntax error: unexpected attribute
→
Fix
Check for missing colon after subcommand (e.g., insert_job: jobname). Run jil -syntax_check < file.jil to pin exact line and error message.
Symptom · 02
Job already exists
→
Fix
Use update_job instead of insert_job. Or delete the existing job first. Use autorep -J jobname -q to verify existence.
Symptom · 03
Machine not found
→
Fix
Verify machine name is registered via autorep -M machinename. Insert machine definition first if missing.
Symptom · 04
Invalid job type
→
Fix
Job type must be CMD, BOX, or FILE_WATCHER. Check for typos, e.g., 'commmand' instead of 'command'.
Symptom · 05
Job imported but never runs
→
Fix
Check date_conditions and start_times. Verify the job is not on hold. Use autorep -J jobname to see status and next scheduled time.
★ Quick JIL Debug Cheat SheetFast commands to diagnose and fix JIL issues without reading manuals.
Syntax error during import−
Immediate action
Run dry-run syntax check
Commands
jil -syntax_check < /path/to/file.jil
head -n [line_number] /path/to/file.jil | tail -5
Fix now
Correct the syntax on the identified line, then re-run the import.
Job not found after update+
Immediate action
Verify job exists with autorep
Commands
autorep -J jobname -q
Check case mismatch: job names are case-sensitive
Fix now
Use the exact job name as shown in autorep output, with correct casing.
Attributes not taking effect+
Immediate action
Check if job was defined with same attribute earlier
Commands
autorep -J jobname -q | grep ^attribute_name
Compare the current value with the intended value
Fix now
Use update_job to override the attribute. Ensure no conflicting override_job exists from prior runs.
Box job deletion fails because it's not empty+
Immediate action
List contents of the box
Commands
autorep -J boxname% -q
Decide whether to move or delete child jobs first
Fix now
Use delete_job on boxname to remove box while keeping children, or move children out before delete_box.
JIL Subcommand Comparison
JIL SubcommandWhat it doesAffects child jobs?
insert_jobCreates a new job definitionN/A
update_jobModifies an existing job (partial update)No
delete_jobRemoves a job definitionNo — box becomes empty
delete_boxRemoves a box AND all its childrenYes — all inner jobs deleted
override_jobOne-time change for next run onlyNo
insert_machineRegisters a new agent machineN/A

Key takeaways

1
JIL (Job Information Language) is the scripting language for defining and managing all AutoSys objects
jobs, machines, calendars, and more
2
The two ways to submit JIL are interactive mode (jil prompt) and script mode (jil < file.jil)
always use script mode in production
3
delete_box removes a box AND all its child jobs; delete_job on a box removes only the box and leaves child jobs as standalone
4
Use autorep -J jobname -q to dump the JIL definition of any existing job
essential for backups and templates
5
Always run jil -syntax_check before importing to production
it catches 95% of syntax errors
6
Back up job definitions with autorep -q before any bulk change; restore them with the same syntax

Common mistakes to avoid

5 patterns
×

Using delete_box instead of delete_job to remove a box

Symptom
All child jobs disappear from the Event Server. Downstream dependent jobs fail with 'waiting for predecessor' or simply vanish from schedules.
Fix
Use delete_job: boxname instead of delete_box. This removes only the box container; child jobs become standalone and can be reassigned or deleted individually.
×

Not quoting attribute values that contain spaces

Symptom
JIL import succeeds but the command runs only the first token. For example, command: /opt/scripts/run report.sh becomes command: /opt/scripts/run with report.sh passed as an extra argument, causing the job to fail with 'command not found'.
Fix
Always enclose the entire command in double quotes: command: "/opt/scripts/run report.sh". Same for other attributes like description, start_times, and std_out_file paths.
×

Using interactive JIL mode for production changes

Symptom
No audit trail of what was changed. When a job starts failing three months later, there is no way to trace back who typed what. Rollback is impossible.
Fix
Always write JIL changes in a script file (.jil) and import via jil < file.jil. Store files in Git. Use jil -syntax_check to validate before importing.
×

Not backing up job definitions before making bulk changes

Symptom
A bulk update or deletion goes wrong and the original definitions are lost. Manual reconstruction is error-prone and time-consuming.
Fix
Before any change, run autorep -J jobname -q > backup_$(date +%Y%m%d).jil. For boxes, use autorep -J boxname% -q > backup_box.jil to capture all children.
×

Assuming job names are case-insensitive

Symptom
Two jobs with names 'Daily_Report' and 'daily_report' exist. One runs at the correct time, the other runs unexpectedly or never triggers. Conditions referencing 'Daily_Report' might not match the job with different casing.
Fix
Standardize job naming conventions (e.g., all uppercase or all lowercase). Use consistent casing in JIL scripts and in job references in conditions. Always verify with autorep -J exactCaseName -q.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR
What is JIL in AutoSys and how is it used?
Q02SENIOR
What is the difference between delete_job and delete_box in JIL?
Q03JUNIOR
What is the difference between insert_job and update_job?
Q04JUNIOR
How do you view the JIL definition of an existing AutoSys job?
Q05JUNIOR
How do you import a JIL script file into AutoSys?
Q06SENIOR
What should you do if you accidentally run delete_box on the wrong box?
Q01 of 06JUNIOR

What is JIL in AutoSys and how is it used?

ANSWER
JIL (Job Information Language) is the declarative language used to define, modify, and delete jobs and other AutoSys objects. It is used by writing JIL statements in a text file and submitting them via the jil command. For example, jil < myjobs.jil imports the definitions. JIL can also be used interactively by typing jil at the command line, opening a prompt where statements are entered line by line. The language consists of subcommands (insert_job, update_job, etc.) and attributes (job_type, command, machine, etc.).
FAQ · 6 QUESTIONS

Frequently Asked Questions

01
What is JIL in AutoSys?
02
How do I run a JIL script in AutoSys?
03
What is the difference between insert_job and update_job in JIL?
04
How do I see the JIL definition of an existing AutoSys job?
05
Is JIL case-sensitive?
06
Is there a way to undo a delete_box?
Related Next Steps
→JIL insert_job, update_job, and delete_job — Managing AutoSys JobsMaster the three core JIL subcommands used in 90% of daily AutoSys work.→JIL Attributes Complete Reference — Every Key AutoSys Job AttributeComplete reference of every JIL attribute from job_type to alarm_if_fail.→AutoSys Job Dependencies and Conditions — Controlling Job ChainsLearn how to chain jobs with conditions, success/failure logic, and dependencies.→JIL One-Time Job Overrides in AutoSys — Temporary Job ChangesUse override_job to make temporary JIL changes without altering the permanent definition.
🔥

That's AutoSys. Mark it forged?

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

←
Previous
AutoSys vs Cron vs Control-M
6 / 30 · AutoSys
Next
JIL Job Types: CMD, BOX and File Watcher
→