DevOps Beginner

JIL insert_job, update_job, and delete_job — Managing AutoSys Jobs

Q: Can you use insert_job to update an existing AutoSys job?

No. insert_job will fail if a job with that name already exists. Use update_job to modify an existing job.

Q: Does update_job require all attributes?

No. update_job is a partial update — you only specify the attributes you want to change. All other attributes keep their current values.

Q: What is the difference between delete_job and delete_box?

delete_job removes a single job. When used on a box, it removes only the box — the inner jobs become standalone. delete_box removes the box AND all inner jobs in one operation.

Q: How do I recover a deleted AutoSys job?

If you took a backup with `autorep -J jobname -q > backup.jil` before deleting, you can re-insert it with `jil < backup.jil`. Without a backup, the job definition is gone.

Q: Can I rename an AutoSys job?

Not directly. AutoSys doesn't have a rename command. To rename a job, export the definition with autorep -q, modify the job name in the JIL file, insert the new version with insert_job, then delete the old one with delete_job.

Q: What happens if I forget a colon in a JIL attribute line?

The JIL parser will likely fail to parse the line, and the entire batch will abort with a syntax error. Always use the syntax `attribute: value` exactly.

Q: Can I run JIL commands directly on the command line without a file?

Yes, you can pipe JIL commands directly to the jil command, e.g., `echo "delete_job: oldjob" | jil`. But it's safer to use a file for multi-line batches.

📅 March 19, 2026 ⏱ 3 min read 🎯 Beginner

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 9 of 30

Learn how to create, modify, and delete AutoSys jobs using JIL subcommands: insert_job, update_job, delete_job, and delete_box.

🧑‍💻 Beginner-friendly — no prior DevOps experience needed

In this tutorial, you'll learn

Learn how to create, modify, and delete AutoSys jobs using JIL subcommands: insert_job, update_job, delete_job, and delete_box.

insert_job creates new jobs; update_job modifies existing ones (partial update only); delete_job removes a single job
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
Always back up job definitions with autorep -J jobname -q > backup.jil before making changes

thecodeforge.io

JIL CRUD Subcommands

Jil Insert Update Delete Job

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

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

🚨 START HERE

Quick Debug Cheat Sheet: JIL Subcommands

Three commands that will save your ass when JIL breaks

🟡

insert_job fails — I don't know why

Immediate ActionLook 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 NowAdd missing attribute and re-run the JIL file.

🟡

update_job not applying

Immediate ActionCheck 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 NowWait for job to complete, then re-run update. Or kill the job first.

🟡

delete_box deleted everything I didn't mean to

Immediate ActionDO 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 NowRestore from backup or rebuild using autorep -q output from other system.

Production Incident

The Quiet Box Deletion That Killed a Payroll Batch

A junior admin ran delete_box on what they thought was a single job. They lost 47 child jobs, and the payroll pipeline stayed down for two days.

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

Assumptiondelete_box behaves like delete_job when applied to a box name — it removes only the container.

Root causedelete_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.

FixRestored 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 Guide

Symptom → Action for the three most common JIL failures

insert_job fails with 'Job already exists'→Run autorep -J jobname to confirm. Use update_job instead. Never try to delete and re-insert — you'll lose history.

update_job seems to have no effect→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.

delete_job or delete_box fails with 'Job not found'→Misspelled name? Use autorep -J %keyword% to search. Remember: case-sensitive. Also check global vs local instance.

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.jil · BASH

12345678910111213

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.

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.jil · BASH

1234567891011

/* 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.jil · BASH

12345678910

/* 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.jil · BASH

123456789

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

Mental model: JIL is like a REST API patch call

Think of insert_job as POST, update_job as PATCH, delete_job as DELETE. delete_box is like a cascading DELETE.

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.sh · BASH

1234567891011121314151617181920212223242526

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

🗂 JIL Subcommand Comparison

insert_job, update_job, delete_job, delete_box — what they do and when to use them

Subcommand	Creates?	Modifies?	Full replacement?	Deletes?
insert_job	Yes — new only	No — fails if exists	N/A	No
update_job	No — fails if not exists	Yes — partial update	No — only changed attrs	No
delete_job	No	No	No	Job only
delete_box	No	No	No	Box + all children

🎯 Key Takeaways

insert_job creates new jobs; update_job modifies existing ones (partial update only); delete_job removes a single job
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
Always back up job definitions with autorep -J jobname -q > backup.jil before making changes
update_job only requires the attributes you want to change — omitted attributes keep their current values
Never trust the 'success' message from JIL — always verify with autorep -q after every operation
Automate JIL operations with scripts that check job existence before choosing insert vs update

⚠ Common Mistakes to Avoid

✕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 Questions on This Topic

QWhat is the difference between insert_job and update_job?JuniorReveal
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.
QIf you want to delete a box but keep its inner jobs, which command do you use?Mid-levelReveal
Use delete_job on the box name. That removes only the box container; child jobs become standalone. delete_box removes the box AND all child jobs.
QHow do you back up an AutoSys job definition before modifying it?JuniorReveal
Run autorep -J jobname -q > backup.jil. This exports the complete JIL definition. You can later re-insert it with jil < backup.jil.
QCan you use update_job on a job that doesn't exist yet?JuniorReveal
No. update_job requires the job to already exist. If the job doesn't exist, use insert_job first. You can check existence with autorep -q and branch accordingly.
QWhat happens to history when you delete an AutoSys job?Mid-levelReveal
Once a job is deleted, all its run history is removed from the Event Server. The only way to recover is from a backup taken with autorep -q before deletion. Always back up before deleting.
QHow do you handle a situation where an update_job doesn't seem to apply?SeniorReveal
First, check if the job is currently running (autorep -d). Running jobs ignore updates until the next scheduled start. If the job is not running, verify you spelled the attribute correctly, and remember that update_job only changes attributes you explicitly include — it doesn't clear omitted ones.

Frequently Asked Questions

Can you use insert_job to update an existing AutoSys job?

No. insert_job will fail if a job with that name already exists. Use update_job to modify an existing job.

Does update_job require all attributes?

No. update_job is a partial update — you only specify the attributes you want to change. All other attributes keep their current values.

What is the difference between delete_job and delete_box?

delete_job removes a single job. When used on a box, it removes only the box — the inner jobs become standalone. delete_box removes the box AND all inner jobs in one operation.

How do I recover a deleted AutoSys job?

If you took a backup with autorep -J jobname -q > backup.jil before deleting, you can re-insert it with jil < backup.jil. Without a backup, the job definition is gone.

Can I rename an AutoSys job?

Not directly. AutoSys doesn't have a rename command. To rename a job, export the definition with autorep -q, modify the job name in the JIL file, insert the new version with insert_job, then delete the old one with delete_job.

What happens if I forget a colon in a JIL attribute line?

The JIL parser will likely fail to parse the line, and the entire batch will abort with a syntax error. Always use the syntax attribute: value exactly.

Can I run JIL commands directly on the command line without a file?

Yes, you can pipe JIL commands directly to the jil command, e.g., echo "delete_job: oldjob" | jil. But it's safer to use a file for multi-line batches.

🔥

Naren Founder & Author

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.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged