DevOps Beginner

JIL Introduction — AutoSys Job Information Language Explained

Q: What is JIL in AutoSys?

JIL stands for Job Information Language. It is the scripting language used to define, modify, and delete jobs and other objects in AutoSys. You write JIL scripts as plain text files and submit them to AutoSys using the `jil` command.

Q: How do I run a JIL script in AutoSys?

Redirect your JIL file into the jil command: `jil < myjobs.jil`. For a specific AutoSys instance, use `jil -S INSTANCE_NAME < myjobs.jil`. For a dry-run syntax check, use `jil -syntax_check < myjobs.jil`.

Q: What is the difference between insert_job and update_job in JIL?

insert_job creates a brand new job definition. update_job modifies an existing job — you only need to specify the attributes you want to change; all other attributes remain as they were.

Q: How do I see the JIL definition of an existing AutoSys job?

Use `autorep -J jobname -q`. The -q flag outputs the job definition in JIL format, which you can redirect to a file to back up or use as a template.

Q: Is JIL case-sensitive?

JIL keywords (like insert_job, job_type, machine) are case-insensitive. However, job names and machine names are case-sensitive. A job named 'Daily_Report' and 'daily_report' are treated as two different jobs.

Q: Is there a way to undo a delete_box?

No, there is no undo command in JIL. The only recovery is to re-import job definitions from a prior backup. That's why backing up with `autorep -q` before any delete operation is critical for production environments.

📅 March 19, 2026 ⏱ 3 min read 🎯 Beginner

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

📍 Part of: AutoSys → Topic 6 of 30

JIL is the scripting language used to define jobs in AutoSys.

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

In this tutorial, you'll learn

JIL is the scripting language used to define jobs in AutoSys.

JIL (Job Information Language) is the scripting language for defining and managing all AutoSys objects — jobs, machines, calendars, and more
The two ways to submit JIL are interactive mode (jil prompt) and script mode (jil < file.jil) — always use script mode in production
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

thecodeforge.io

JIL Submit Flow

Jil Introduction Syntax

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

⚡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

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

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

Common errors when running `jil < file.jil` and how to fix them

JIL syntax error: unexpected attribute→Check for missing colon after subcommand (e.g., insert_job: jobname). Run jil -syntax_check < file.jil to pin exact line and error message.

Job already exists→Use update_job instead of insert_job. Or delete the existing job first. Use autorep -J jobname -q to verify existence.

Machine not found→Verify machine name is registered via autorep -M machinename. Insert machine definition first if missing.

Invalid job type→Job type must be CMD, BOX, or FILE_WATCHER. Check for typos, e.g., 'commmand' instead of 'command'.

Job imported but never runs→Check date_conditions and start_times. Verify the job is not on hold. Use autorep -J jobname to see status and next scheduled time.

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

1234567891011121314151617

# 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 syntax rules

JIL follows strict but simple syntax rules:

Every job definition begins with a subcommand (insert_job, update_job, etc.) followed by a colon and the job name
After the subcommand line, attribute statements follow — one per line (or multiple separated by spaces)
The next subcommand begins a new job definition
Comments start with / ... /
Attribute values containing spaces must be enclosed in double quotes
JIL is case-insensitive for keywords but case-sensitive for job names and machine names

jil_syntax_rules.jil · BASH

123456789101112131415161718192021222324

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

Mental Model

Think of JIL as filling out a form

Each subcommand starts a new form, attributes are the fields, and the processor is the data entry clerk.

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

1234567891011121314

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

12345678910

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

12345678910111213141516171819

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

🗂 JIL Subcommand Comparison

Understand what each subcommand does and whether it affects child jobs.

JIL Subcommand	What it does	Affects child jobs?
insert_job	Creates a new job definition	N/A
update_job	Modifies an existing job (partial update)	No
delete_job	Removes a job definition	No — box becomes empty
delete_box	Removes a box AND all its children	Yes — all inner jobs deleted
override_job	One-time change for next run only	No
insert_machine	Registers a new agent machine	N/A

🎯 Key Takeaways

JIL (Job Information Language) is the scripting language for defining and managing all AutoSys objects — jobs, machines, calendars, and more
The two ways to submit JIL are interactive mode (jil prompt) and script mode (jil < file.jil) — always use script mode in production
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
Use autorep -J jobname -q to dump the JIL definition of any existing job — essential for backups and templates
Always run jil -syntax_check before importing to production — it catches 95% of syntax errors
Back up job definitions with autorep -q before any bulk change; restore them with the same syntax

⚠ Common Mistakes to Avoid

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

QWhat is JIL in AutoSys and how is it used?JuniorReveal
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.).
QWhat is the difference between delete_job and delete_box in JIL?Mid-levelReveal
delete_job removes a single job definition from the Event Server. If applied to a box job, it removes only the box container; all child jobs inside the box remain in the database as standalone jobs. delete_box removes the box AND recursively deletes every job inside it. This is a powerful and dangerous command because there is no confirmation prompt. Always use delete_job on a box if you want to preserve the child jobs, and back up definitions with autorep -q before using delete_box.
QWhat is the difference between insert_job and update_job?JuniorReveal
insert_job creates a new job definition. It requires all mandatory attributes (job_type, command, machine, owner). If the job already exists, the JIL processor returns an error. update_job modifies an existing job. You only need to specify the attributes you want to change; all other attributes remain unchanged. update_job is idempotent for the attributes you set. Use autorep -J jobname -q to see the current definition before updating.
QHow do you view the JIL definition of an existing AutoSys job?JuniorReveal
Use the autorep command with the -q (query) flag: autorep -J jobname -q. This outputs the job definition in JIL format to stdout. You can redirect to a file to back up or edit: autorep -J jobname -q > job.jil. For a box, use a wildcard to get all children: autorep -J boxname% -q > box_backup.jil. The -q output is valid JIL and can be re-imported directly.
QHow do you import a JIL script file into AutoSys?JuniorReveal
Import a JIL script by redirecting the file into the jil command: jil < /path/to/script.jil. For a specific AutoSys instance, use the -S flag: jil -S INSTANCE_NAME < script.jil. Before importing, validate the syntax with jil -syntax_check < script.jil to catch errors without risking data. On success, the processor outputs confirmation lines like / AutoSys/JIL: Successfully inserted job: jobname / with the number of jobs processed and errors.
QWhat should you do if you accidentally run delete_box on the wrong box?Mid-levelReveal
First, stay calm. There is no undo command in JIL. The only recovery path is to re-import from a prior backup. If you had previously run autorep -J boxname% -q > backup.jil, you can restore all jobs and the box with jil < backup.jil. If no backup exists, you'll need to manually recreate every job — which is why backing up before any delete operation is non-negotiable in production.

Frequently Asked Questions

What is JIL in AutoSys?

JIL stands for Job Information Language. It is the scripting language used to define, modify, and delete jobs and other objects in AutoSys. You write JIL scripts as plain text files and submit them to AutoSys using the jil command.

How do I run a JIL script in AutoSys?

Redirect your JIL file into the jil command: jil < myjobs.jil. For a specific AutoSys instance, use jil -S INSTANCE_NAME < myjobs.jil. For a dry-run syntax check, use jil -syntax_check < myjobs.jil.

What is the difference between insert_job and update_job in JIL?

insert_job creates a brand new job definition. update_job modifies an existing job — you only need to specify the attributes you want to change; all other attributes remain as they were.

How do I see the JIL definition of an existing AutoSys job?

Use autorep -J jobname -q. The -q flag outputs the job definition in JIL format, which you can redirect to a file to back up or use as a template.

Is JIL case-sensitive?

JIL keywords (like insert_job, job_type, machine) are case-insensitive. However, job names and machine names are case-sensitive. A job named 'Daily_Report' and 'daily_report' are treated as two different jobs.

Is there a way to undo a delete_box?

No, there is no undo command in JIL. The only recovery is to re-import job definitions from a prior backup. That's why backing up with autorep -q before any delete operation is critical for production environments.

🔥

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