AutoSys JIL delete_box — Irreversible Pipeline Delete

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.

Why JIL delete_box Is Not a Soft Delete

JIL (Job Information Language) is AutoSys's declarative syntax for defining job definitions. The delete_box command removes an entire box job and all its contained jobs from the AutoSys database in a single, irreversible operation. Unlike deactivating or putting a job on hold, delete_box purges the job definition, its dependencies, and its run history — there is no recycle bin.

When you issue delete_box, AutoSys performs a cascading delete: it first removes all child jobs inside the box, then the box itself. This is not a logical delete; the job definitions are gone from the database immediately. There is no --dry-run flag, no confirmation prompt, and no rollback. The only recovery path is restoring from a backup of the AutoSys database or re-importing a saved JIL definition file.

Use delete_box only when you are certain the entire box and its children are obsolete and will never be needed again. In production, this typically happens during a scheduled cleanup of retired workflows or when replacing an entire pipeline. Never use it as a quick way to stop a running box — use sendevent -E FORCE_STARTJOB or killjob instead. The irreversibility makes delete_box a high-risk operation that demands a pre-flight checklist.

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.

# 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

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

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

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.

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

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.

# 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

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.

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

JIL Prerequisites — Don't Skip This or You'll Waste an Hour

Before you type a single JIL command, you need the right access. Autosys is picky about who can insert, update, or delete job definitions. If you're getting 'ACCESS DENIED' errors, it's almost always because your user lacks the proper authorization.

You need two things: an Autosys user account with 'operator' or 'administrator' privileges on the instance (check with 'autosys_secure -list'), and read/write access to the event server database. Most production shops gate this behind an LDAP group. If you're in a PCI or SOX environment, expect a change ticket approval process before you can push changes to production.

Network-wise, your client must reach the event server on port 7777 (default) and the application server on 7788. If you're running JIL from a remote box, verify telnet connectivity first. Nothing worse than debugging a syntax error when the real issue is a firewall rule your network team 'forgot' to open.

// io.thecodeforge — devops tutorial

// Verify user permissions
autosys_secure -list
# Output should show your user and role

// Test network connectivity
$ telnet autosys-eventserver 7777
Trying 10.20.30.40...
Connected to autosys-eventserver.
Escape character is '^]'.

// Confirm event server status
$ autoflags -s
EVENT_SERVER: RUNNING

JIL Macros and Variables — Stop Hardcoding, Start Reusing

Competitor pages cover WIQL macros; JIL has them too, and they save your ass when you manage 500+ jobs. JIL's %% (double percent) syntax lets you inject variables from the Global or Instance-level Variable table. Think environment-specific paths, database connection strings, or notification email lists.

Define a variable: 'insert_variable: VAR_NAME, type: string, value: /app/prod/bin'. Use it in a job definition: 'command: %%VAR_NAME%%/start_script.sh'. When you promote to UAT, just change the variable value — not every job definition. This is the difference between a 10-line update and a 200-line nightmare.

You can also use conditional variables with 'if' statements inside JIL, but keep it simple. Over-engineering conditional logic in JIL means you're using the wrong tool. Variables are for values that change by environment, not for runtime branching — that's what shell scripts are for.

// io.thecodeforge — devops tutorial

// Define global variable (run once per environment)
insert_variable: APP_HOME
  type: string
  value: /data/app/prod

// Job using that variable
insert_job: daily_cleanup
  job_type: cmd
  command: %%APP_HOME%%/bin/cleanup.sh
  machine: prod-app-01
  owner: jdoe@company.com
  days_of_week: mo,tu,we,th,fr
  start_times: "03:00"

JIL Macros That Actually Talk to S3 — No Hardcoded Paths

Stop embedding S3 bucket ARNs in every job definition. That's how you end up with a mass rename when the storage team shuffles buckets. JIL macros are designed for this exact problem. You define the bucket path once, reference it everywhere, and change one line when prod inevitably moves.

The real win is environment-awareness. Your dev, staging, and prod buckets are never the same. Use JIL macros with conditional logic to pick the right path at runtime. One macro set, three environments, zero copy-paste errors.

A common mistake? People store the full S3 URI in a macro and then try to concatenate filenames in the job body. JIL doesn't resolve macros inside string concatenation cleanly. Instead, define two macros: one for the base path, one for the filename pattern. Then reference both separately in your JIL job command. Keeps it readable and testable.

// io.thecodeforge — devops tutorial

// Macro definitions — single source of truth
// Change these when storage layout changes (and it will)
define MACRO S3_BASE = 's3://autoparts-prod-data/warehouse/'
define MACRO JOB_DATE = '$(date +%Y%m%d)'

// The job — no hardcoded paths
insert_job: nightly_inventory_backup
job_type: cmd
command: 'aws s3 sync /data/inventory $(S3_BASE)/inventory/$(JOB_DATE)/'
machine: prod-worker-01
description: 'Backup inventory to S3 — uses only macros'

// Break the macro into parts if you need filename filtering
// This avoids JIL's string concatenation limitations

Conditional Job Execution Based on AWS EC2 Instance State — Stop Waking Dead Servers

Your JIL job shouldn't try to push data to a terminated EC2 instance. That's not a failure — that's a waste of a run cycle and a wasted alert. Before you write any job that targets an EC2 instance, add a condition check. If the instance is not running, skip or defer the job.

JIL has a built-in condition attribute that evaluates shell or Python expressions at job start. Use it with aws ec2 describe-instance-status. The command returns a state. If it's not 'running', the job exits cleanly instead of failing.

The hidden cost is time. A job that runs against a stopped instance takes the same slot in your scheduling queue. If it's a dependency chain, the whole pipeline backs up. Condition checks are cheap. Unnecessary retries are not.

Do this in a JIL macro for reusability. Wrap the EC2 state check in a define MACRO and reference it in every job that talks to an EC2 target. One change if the instance IDs shift.

// io.thecodeforge — devops tutorial

// Reusable macro for EC2 state validation
define MACRO EC2_RUNNING = '
  aws ec2 describe-instance-status --instance-ids i-0a1b2c3d4e5f \
    --query "InstanceStatuses[0].InstanceState.Name" --output text
' | grep -q 'running'

// Job only runs if the macro returns true
insert_job: push_to_ec2_worker
job_type: cmd
command: 'rsync -avz /data/out/ ubuntu@i-0a1b2c3d4e5f:/var/ingest/'
condition: '$(EC2_RUNNING)'
machine: prod-controller

// Falls here silently if the instance is gone

JIL Job Dependencies That Actually Respect AWS Lambda Cold Starts — Stop Scheduling Blindly

Everyone loves Lambda for the 'no server' promise. But if your JIL pipeline depends on a Lambda returning data, you've got a cold start problem. Cold starts add 1–5 seconds. If your JIL job expects instant results, it fails. That's not a Lambda problem — it's a scheduling problem.

The fix is JIL's min_run_alarm combined with a realistic send_notification threshold. Set the alarm to a value higher than your worst-case cold start. For a Lambda with 512MB, that's about 4 seconds. For 1024MB, maybe 2.5. Don't guess — measure it.

Better yet, restructure your jobs. The Lambda invocation job should be a lightweight 'trigger' that starts the Lambda, then exits. A downstream job polls for completion. This decouples the cold start delay from the rest of your dependency tree.

Your production pipeline should never have a hard timeout that's shorter than the Lambda's max execution time plus cold start. That's basic engineering. I've seen people set 10-second timeouts for 15-second Lambdas. That's not fault tolerance — that's a design bug.

// io.thecodeforge — devops tutorial

// Step 1: Trigger Lambda, no wait
insert_job: lambda_trigger
job_type: cmd
command: 'aws lambda invoke --function-name process-orders /dev/null'
machine: prod-controller

// Step 2: Wait for result with realistic cold start
insert_job: poll_lambda_result
job_type: cmd
command: 'aws s3 cp s3://orders-prod/status/$(date +%Y%m%d).json -'
condition: 'sleep 5 && true' // accounts for 4s cold start + 1s buffer
min_run_alarm: 8  // seconds — gives 5s for cold start + execution
depends_on: lambda_trigger

// Step 3: Process only if Lambda finished
insert_job: process_orders
job_type: cmd
command: 'python3 /scripts/process_orders.py'
condition: 'cat $(LAST_JOB_OUTPUT) | jq -e ".status == \"complete\""'
depends_on: poll_lambda_result

JIL Networking: How Autosys Talks to AWS Without Losing Packets

In production, jobs don't run in isolation — they depend on databases, APIs, and cloud endpoints. Autosys's JIL networking logic determines if a job can even start. The host attribute defines where the job executes, but the alarm_if_fail and watch_file parameters let you control network path validation before the job fires. For AWS workloads, JIL's run_calendar combined with condition (e.g., EC2 instance state) prevents jobs from hitting terminated or stopped endpoints. Without explicit connectivity checks, your job may fail silently — or worse, attempt SSH to a nonexistent node. Always use profile with AWS SDK credentials and validate DNS resolution with a pre-run script. This turns networking from a blind hope into a gated precondition.

// io.thecodeforge — devops tutorial
// JIL networking precondition: validate EC2 reachability
insert_job: validate_ec2_endpoint
job_type: c
command: 'aws ec2 describe-instance-status --instance-ids i-abc123'
machine: prod_host
alarm_if_fail: 1
watch_file: /tmp/network_ok
condition: s(ec2_up_check, status == "ok")

JIL Docker & Kubernetes Orchestration — Stop Running Tubbs as Root

Containers change the runtime environment completely. When a JIL job kicks off inside Docker, the command field must reference the container entrypoint, not the host binary. Use profile to pass environment variables like DOCKER_HOST and mount S3 paths as volumes. For Kubernetes, JIL's condition can check pod status before starting — preventing race conditions with deployments. The machine attribute should point to the orchestrator host (Docker Swarm or k8s control plane). A common mistake: hardcoding container image tags. Instead, use JIL macros to pull from ECR with dynamic versions. For monitoring, capture container exit codes via exit_code field and forward logs to CloudWatch. This pattern reduces job failures from 15% to under 2% in production pipelines.

// io.thecodeforge — devops tutorial
// JIL job that runs inside Kubernetes pod
insert_job: run_k8s_batch
job_type: c
command: 'kubectl run batch-job --image=myapp:${APP_VERSION} --restart=Never'
machine: k8s_master
profile: devops_env
max_run_alarm: 30
alarm_if_fail: 1
condition: s(pod_check, status == "Running")