Home DevOps JIL Introduction — AutoSys Job Information Language Explained

JIL Introduction — AutoSys Job Information Language Explained

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 (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
✦ Plain-English analogy ✦ Real code with output ✦ Interview questions
⚡ Quick Answer
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.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 definitionsInteractive 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.

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

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

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

  • 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

⚠ Common Mistakes to Avoid

  • Using delete_box when you only meant to delete the box but keep the child jobs — use delete_job on the box name for that
  • Forgetting to quote attribute values that contain spaces — command: /opt/scripts/run report.sh will fail without quotes
  • Using interactive JIL mode for production changes — always use script files in version control
  • Not backing up existing job definitions with autorep -q before making bulk changes
  • Case sensitivity gotcha: JIL keywords are case-insensitive but job names and machine names ARE case-sensitive

Interview Questions on This Topic

  • QWhat is JIL in AutoSys and how is it used?
  • QWhat is the difference between delete_job and delete_box in JIL?
  • QWhat is the difference between insert_job and update_job?
  • QHow do you view the JIL definition of an existing AutoSys job?
  • QHow do you import a JIL script file into AutoSys?

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 &lt; myjobs.jil. For a specific AutoSys instance, use jil -S INSTANCE_NAME &lt; myjobs.jil. For a dry-run syntax check, use jil -syntax_check &lt; 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.

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

← PreviousAutoSys vs Cron vs Control-MNext →JIL Job Types: CMD, BOX and File Watcher
Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged