Senior 3 min · March 19, 2026

AutoSys delete_box — One Command Wiped 47 Payroll Jobs

Using delete_box instead of delete_job made 47 payroll jobs vanish.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
⚡Quick Answer
  • insert_job creates new job definitions. Fails if the job already exists.
  • update_job modifies only the attributes you specify — partial update, not replacement.
  • delete_job removes a single job. delete_box removes the box plus all child jobs.
  • Each command uses JIL syntax; a typo or missing required attribute stops the entire batch.
  • Production insight: delete_box is the most dangerous — it silently wipes entire job trees.
  • Biggest mistake: assuming update_job is a full rewrite — it's not, and omitted attributes stay unchanged.
Plain-English First

insert_job is like hiring a new employee and filling out their paperwork. update_job is like updating their job description without rehiring them. delete_job is like terminating that employee and removing their record.

Managing jobs in AutoSys means mastering three JIL subcommands: insert_job to create, update_job to modify, and delete_job to remove. These are the bread-and-butter operations you'll perform every week as an AutoSys administrator or developer. You'll see them in every single batch pipeline. And you'll screw them up at least once.

insert_job — creating a new job

insert_job creates a brand-new job definition in the AutoSys Event Server. The job name must be unique within the instance. All required attributes (job_type, machine for CMD jobs, owner) must be included. You cannot insert_job if a job with that name already exists — use update_job instead.

insert_job.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
insert_job: daily_reconcile
job_type: CMD
command: /opt/scripts/reconcile.sh
machine: finance-server-01
owner: finuser
date_conditions: 1
days_of_week: mon-fri
start_times: "05:00"
std_out_file: /logs/autosys/daily_reconcile.out
std_err_file: /logs/autosys/daily_reconcile.err
alarm_if_fail: 1
n_retrys: 1
description: "Morning reconciliation run before market open"
Output
/* AutoSys/JIL: Successfully inserted job: daily_reconcile */
Required attributes differ by job type
CMD jobs need machine, owner, command. Box jobs need no command or machine. File Watcher jobs need watch_file and watch_interval. Always check the job type before writing the JIL.
Production Insight
A missing required attribute causes the entire JIL batch to abort, not just that job.
Always validate with autorep -J newjob -q after insertion — a silent failure (like a typo in machine name) can leave the job orphaned.
Rule: never run insert_job in production without dry-running on a test instance first.
Key Takeaway
insert_job = brand new, must be unique.
Missing attributes abort the whole batch.
Always verify insertion with autorep -q.
JIL CRUD Subcommands JIL CRUD Subcommands. insert · update · delete · insert_job · Creates new job · Fails if job exists · All required attrs needed · Use for new definitionsTHECODEFORGE.IOJIL CRUD Subcommandsinsert · update · delete insert_jobCreates new jobFails if job existsAll required attrs neededUse for new definitions update_jobModifies existing jobFails if not existsPartial update onlyOmitted attrs unchanged delete_job / delete_boxRemoves job definitiondelete_box removes children tooBack up first!History also removedTHECODEFORGE.IO
thecodeforge.io
JIL CRUD Subcommands
Jil Insert Update Delete Job

update_job — modifying an existing job

update_job modifies an existing job definition. You only need to include the attributes you want to change — everything else stays as it was. This is a partial update, not a full replacement.

update_job.jilBASH
1
2
3
4
5
6
7
8
9
10
11
/* Change only the start time — everything else unchanged */
update_job: daily_reconcile
start_times: "04:30"

/* Add a condition to an existing job */
update_job: generate_report
condition: success(daily_reconcile)

/* Change the machine a job runs on */
update_job: daily_reconcile
machine: finance-server-02
Output
/* AutoSys/JIL: Successfully updated job: daily_reconcile */
update_job takes effect immediately for future runs
If the job is currently RUNNING, the update applies to the next run. If the job is scheduled and not yet running, the update applies to the current scheduled run.
Production Insight
You cannot clear an attribute by omitting it in update_job. To remove a value, you must explicitly set it to empty (e.g., start_times: "").
In production, forgetting this leads to stale conditions that never get cleared.
Rule: if you want to revert to defaults, use insert_job with a new name or explicitly reset every attribute.
Key Takeaway
update_job is partial — only what you specify changes.
You cannot remove an attribute by omission.
To clear, set it to empty string or 0.

delete_job and delete_box

delete_job removes a single job. delete_box removes a box and ALL jobs inside it. Always back up definitions before deleting.

delete_jobs.jilBASH
1
2
3
4
5
6
7
8
9
10
/* Delete a single job */
delete_job: old_report_job

/* Delete a box AND all inner jobs */
delete_box: legacy_eod_box

/* SAFER: backup first, then delete */
# autorep -J old_report_job -q > /tmp/old_report_job_backup.jil
# Then review the backup, then:
delete_job: old_report_job
Output
/* AutoSys/JIL: Successfully deleted job: old_report_job */
/* AutoSys/JIL: Successfully deleted box: legacy_eod_box (5 jobs removed) */
Always backup before delete
Run autorep -J jobname -q > backup.jil before any delete operation. Once a job is deleted from the Event Server, the history is also gone.
Production Insight
Delete operations are irreversible without a backup. History is permanently lost.
delete_box is the most dangerous command in AutoSys — it recursively removes every job inside.
Rule: never run delete_box without a manager's approval and a verified backup of ALL child jobs.
Key Takeaway
delete_job removes one job. delete_box removes everything inside.
Backup always before delete.
If you only want to remove the box container, use delete_job on the box name.

Common pitfalls when using JIL subcommands

Even experienced AutoSys admins make mistakes with these commands. The most common: confusing insert and update, forgetting that update is partial, running delete_box when you meant delete_job, and not backing up before deletion. Also: JIL syntax is finicky about whitespace. A missing colon after the subcommand attribute name will cause a parse error.

pitfall_examples.jilBASH
1
2
3
4
5
6
7
8
9
/* WRONG: missing colon after job name */
update_job daily_reconcile

/* WRONG: using insert_job on an existing job */
insert_job: daily_reconcile

/* WRONG: trying to remove start_times by omitting it */
update_job: daily_reconcile
/* Oops — start_times not mentioned, so it stays at 05:00 */
Output
/* ERROR: parse error — missing colon
ERROR: job daily_reconcile already exists — use update_job
(No error update_job silently does nothing for start_times) */
Mental model: JIL is like a REST API patch call
  • POST (insert_job) fails if resource exists.
  • PATCH (update_job) only changes included fields.
  • DELETE (delete_job) removes one resource.
  • Cascading DELETE (delete_box) removes a collection and all its children.
Production Insight
The number one production failure from JIL: someone runs a script that uses insert_job when it should be update_job, and the whole script aborts on the first existing job.
Second: forgetting that update_job cannot clear attributes — leads to stuck conditions.
Rule: always use conditional logic in scripts: check if job exists first, then branch.
Key Takeaway
insert ≠ update. update ≠ replacement.
delete_box is a nuke — handle with care.
Use autorep -q to inspect before any operation.

Automating job lifecycle management with scripts

In production, you'll rarely run JIL commands one by one. Instead, you'll build scripts that generate JIL files dynamically and pipe them to the jil command. A common pattern: loop over a list of jobs, check existence, then choose insert or update. Another: after a code deployment, you update batch schedules en masse by generating JIL from a template.

automate_jil.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
# Example: deploy new job or update existing
JOB_NAME="daily_reconcile"
JIL_FILE="/tmp/${JOB_NAME}.jil"

# Check if job exists
autorep -J "$JOB_NAME" -q > /dev/null 2>&1
if [ $? -eq 0 ]; then
  echo "Job exists — using update_job"
  cat > "$JIL_FILE" <<EOF
update_job: $JOB_NAME
start_times: "06:00"
EOF
else
  echo "Job does not exist — using insert_job"
  cat > "$JIL_FILE" <<EOF
insert_job: $JOB_NAME
job_type: CMD
command: /scripts/run.sh
machine: prod-server
owner: batuser
start_times: "06:00"
EOF
fi

jil < "$JIL_FILE"
Output
Job exists — using update_job
/* AutoSys/JIL: Successfully updated job: daily_reconcile */
Always wrap JIL operations in idempotent scripts
Your script should produce the same end state whether run once or twice. Use the existence check pattern above.
Production Insight
Automation scripts that fail silently are the worst: they skip jobs, leave half-updated definitions, and cause mysterious pipeline failures later.
Always log every JIL operation to a file with a timestamp. Capture both success and error output.
Rule: never pipe JIL directly without capturing the return code of jil and checking autorep afterwards.
Key Takeaway
Automate JIL with existence checks — insert vs update branching.
Always log and verify after automated JIL runs.
Idempotency: running the script twice should not break the system.
● Production incidentPOST-MORTEMseverity: high

The Quiet Box Deletion That Killed a Payroll Batch

Symptom
After running a JIL script to clean up old jobs, the entire month-end batch disappeared. No error surfaced immediately — the box just vanished along with its children.
Assumption
delete_box behaves like delete_job when applied to a box name — it removes only the container.
Root cause
delete_box is not delete_job. It removes the box definition AND recursively deletes every job inside it. The admin used delete_box instead of delete_job on a box that contained 47 critical payroll jobs.
Fix
Restored jobs from autorep -q backups (which luckily existed). Re-inserted 47 jobs via a JIL batch. Changed access controls to prevent delete_box on production boxes without a second approval.
Key lesson
  • Never use delete_box without a full autorep -q backup of the entire box tree.
  • Always run autorep -J boxname -q | grep job_name first to see what you're about to delete.
  • Consider renaming delete_box to something less lethal in your runbook — or just ban it in production.
Production debug guideSymptom → Action for the three most common JIL failures3 entries
Symptom · 01
insert_job fails with 'Job already exists'
→
Fix
Run autorep -J jobname to confirm. Use update_job instead. Never try to delete and re-insert — you'll lose history.
Symptom · 02
update_job seems to have no effect
→
Fix
Check if the job is currently running via autorep -J jobname -d. Running jobs ignore updates until next scheduled start. Also verify you spelled the attribute correctly.
Symptom · 03
delete_job or delete_box fails with 'Job not found'
→
Fix
Misspelled name? Use autorep -J %keyword% to search. Remember: case-sensitive. Also check global vs local instance.
★ Quick Debug Cheat Sheet: JIL SubcommandsThree commands that will save your ass when JIL breaks
insert_job fails — I don't know why−
Immediate action
Look for missing required attributes (job_type, machine, owner).
Commands
autorep -J jobname -q | grep -i 'job_type|machine|owner'
jil < backup.jil (if backup exists) to compare working syntax.
Fix now
Add missing attribute and re-run the JIL file.
update_job not applying+
Immediate action
Check if job is running or held.
Commands
autorep -J jobname -d | head -5
sendevent -E FORCE_STARTJOB -J jobname (if you want to clear a running state)
Fix now
Wait for job to complete, then re-run update. Or kill the job first.
delete_box deleted everything I didn't mean to+
Immediate action
DO NOT PANIC. Check backups.
Commands
ls -la /path/to/backups/*.jil 2>/dev/null || echo 'no backup found'
autorep -J boxname -q (if box still partially exists) to reconstruct.
Fix now
Restore from backup or rebuild using autorep -q output from other system.
JIL Subcommand Comparison
SubcommandCreates?Modifies?Full replacement?Deletes?
insert_jobYes — new onlyNo — fails if existsN/ANo
update_jobNo — fails if not existsYes — partial updateNo — only changed attrsNo
delete_jobNoNoNoJob only
delete_boxNoNoNoBox + all children

Key takeaways

1
insert_job creates new jobs; update_job modifies existing ones (partial update only); delete_job removes a single job
2
delete_box removes a box AND all its child jobs
use delete_job on the box name to remove only the box while keeping children
3
Always back up job definitions with autorep -J jobname -q > backup.jil before making changes
4
update_job only requires the attributes you want to change
omitted attributes keep their current values
5
Never trust the 'success' message from JIL
always verify with autorep -q after every operation
6
Automate JIL operations with scripts that check job existence before choosing insert vs update

Common mistakes to avoid

5 patterns
×

Using insert_job on an existing job

Symptom
JIL batch aborts with 'job already exists' error. Subsequent jobs in the file are not processed.
Fix
Use update_job instead. Or check existence first with autorep -q and branch in your script.
×

Using delete_box when you only want to remove the box container

Symptom
All child jobs disappear — no warning, no confirmation. Pipeline breaks.
Fix
Use delete_job on the box name. That removes only the box; child jobs become standalone.
×

Not backing up job definitions before delete operations

Symptom
After deletion, the job definition and history are gone. Recovery requires manual reconstruction.
Fix
Run autorep -J jobname -q > backup.jil before any delete. Store backups in version control.
×

Forgetting that update_job is partial — can't clear an attribute by omitting it

Symptom
An attribute you wanted to remove (e.g., condition) persists because you didn't explicitly set it to empty.
Fix
Explicitly set the attribute to empty or 0: e.g., condition: "" or start_times: "".
×

Assuming JIL syntax errors are obvious

Symptom
JIL runs without error, but the job is not created/updated as expected. Example: missing colon after attribute name silently parsed as wrong attribute.
Fix
Always verify with autorep -J jobname -q after every JIL operation. Never trust the 'success' output alone.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR
What is the difference between insert_job and update_job?
Q02SENIOR
If you want to delete a box but keep its inner jobs, which command do yo...
Q03JUNIOR
How do you back up an AutoSys job definition before modifying it?
Q04JUNIOR
Can you use update_job on a job that doesn't exist yet?
Q05SENIOR
What happens to history when you delete an AutoSys job?
Q06SENIOR
How do you handle a situation where an update_job doesn't seem to apply?
Q01 of 06JUNIOR

What is the difference between insert_job and update_job?

ANSWER
insert_job creates a new job definition and fails if the job already exists. update_job modifies an existing job and fails if it does not exist. update_job is a partial update — only the attributes you specify are changed; omitted attributes keep their current values.
FAQ · 7 QUESTIONS

Frequently Asked Questions

01
Can you use insert_job to update an existing AutoSys job?
02
Does update_job require all attributes?
03
What is the difference between delete_job and delete_box?
04
How do I recover a deleted AutoSys job?
05
Can I rename an AutoSys job?
06
What happens if I forget a colon in a JIL attribute line?
07
Can I run JIL commands directly on the command line without a file?
Related Next Steps
→Introduction to AutoSysUnderstand the core concepts behind AutoSys job scheduling before diving into JIL commands.→AutoSys Job Dependencies and Conditions — Controlling Job ChainsSee how conditions work with update_job to build complex job chains in production.→AutoSys sendevent Command — Complete ReferenceControl job states programmatically — useful when JIL updates don't take effect on running jobs.
🔥

That's AutoSys. Mark it forged?

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

←
Previous
JIL Attributes Complete Reference
9 / 30 · AutoSys
Next
Box Jobs and Nested Boxes in AutoSys
→