DevOps Intermediate

JIL Attributes Complete Reference — Every Key AutoSys Job Attribute

📅 March 19, 2026 ⏱ 3 min read 🎯 Intermediate

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

📍 Part of: AutoSys → Topic 8 of 30

Complete reference for AutoSys JIL job attributes: scheduling, dependencies, notifications, retry, output, and machine attributes.

⚙️ Intermediate — basic DevOps knowledge assumed

In this tutorial, you'll learn

Complete reference for AutoSys JIL job attributes: scheduling, dependencies, notifications, retry, output, and machine attributes.

Always set std_out_file and std_err_file on every CMD job — they are your primary debugging tools
date_conditions: 1 must be set for start_times to take effect — without it, time-based scheduling is disabled
n_retrys: 3 means 3 retries after initial failure — the job runs up to 4 times total

thecodeforge.io

JIL Attribute Groups

Jil Attributes Complete Reference

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

⚡Quick Answer

JIL attributes define identity, schedule, dependencies, error handling, output, and resource control
Common trap: date_conditions defaults to 0 — start_times are ignored without it
n_retrys is retries after initial failure; total attempts = n_retrys + 1
Always set std_err_file — without it, error output vanishes into /dev/null
box_terminator kills the parent box on failure — use only for critical kill switches

🚨 START HERE

AutoSys Quick Debug Cheat Sheet

Immediate commands and fixes for common job failures

🟡

Job is in ACTIVATED but should have started

Immediate ActionCheck job definition with autorep -j job_name -q

Commands

autorep -j JOBNAME -q

sendevent -E FORCE_START -J JOBNAME

Fix NowSet date_conditions: 1 in JIL and re-insert job

🟡

Job fails with exit code 1, no log

Immediate ActionLook for std_err_file in job definition

Commands

autorep -q -j JOBNAME | grep std_err

cat /logs/autosys/JOBNAME.err (if exists)

Fix NowAdd std_err_file to the job JIL and re-run

🟡

Job runs infinitely, no term_run_time set

Immediate ActionKill the job from terminal

Commands

sendevent -E KILLJOB -J JOBNAME

autorep -j JOBNAME -w 20 (wait 20 secs for status)

Fix NowAdd term_run_time: 60 to prevent future hangs

🟡

Job reports success but downstream jobs don't start

Immediate ActionCheck condition on downstream job

Commands

autorep -j DOWNSTREAM_JOB -q | grep condition

autorep -j JOBNAME -w 0 (check exit code)

Fix NowUpdate downstream condition to match the exit code (s() vs f() vs d())

Production Incident

The Midnight Silence — Job Never Starts Despite Correct Condition

A downstream job that should have run at 2 AM stays ACTIVATED all night, blocking the entire batch chain. The condition looks perfect — but the job won't budge.

SymptomJob remains in ACTIVATED or WAITING status past its scheduled start time. Upstream job completed successfully. No errors in event log.

AssumptionThe engineer assumed setting start_times alone makes the job run at that time. date_conditions was omitted from the JIL definition.

Root causedate_conditions defaults to 0. Without date_conditions: 1, AutoSys ignores all time-based scheduling attributes (start_times, days_of_week, run_calendar). The job only starts when a condition triggers it, but since the condition was always true, the job never leaves WAITING.

FixAdd date_conditions: 1 to the JIL definition and re-insert the job. The job will now honour the start_times.

Key Lesson

Always explicitly set date_conditions: 1 when using start_times, days_of_week, or run_calendar.Never assume defaults — AutoSys documentation states date_conditions defaults to 0.Use autorep -j job_name -q to verify the effective attribute values before troubleshooting.

Production Debug Guide

Symptom → Action

Job stays in ACTIVATED status past start time→Check date_conditions is 1. Verify condition evaluation with autorep -j jobname -q | grep condition. Ensure start_times is not empty.

Job fails with EXIT CODE 1 but no visible error→Verify std_err_file is set. Check the file content. If missing, add std_err_file and re-run. Look at the system event log for exit_code reason.

Job runs but produces no output→Check std_out_file path permissions. Use > prefix for append mode if file exists. Verify the command inside the job actually writes to stdout.

Job runs forever and blocks box→Check term_run_time is set. If not, add a reasonable limit (e.g., 60 min). Use sendevent -E KILLJOB -J jobname to terminate hanging job.

A JIL job definition can contain dozens of attribute statements, each controlling a different aspect of how the job behaves. You don't need to memorise all of them, but you do need to know the commonly used ones by heart and know where to find the rest.

This article covers every attribute you'll encounter in production AutoSys environments, grouped by what they control. Each attribute includes its purpose, valid values, and a note on when it matters.

Identity attributes

These attributes define the basic identity of the job. They are the first things AutoSys reads when processing a job definition. Without a name, type, owner, and machine, the job cannot exist. The permission attribute controls visibility and who can modify or run the job — a practical concern in shared environments where multiple teams manage the same scheduler.

identity_attributes.jil · BASH

123456

insert_job: my_job_name          /* unique name in this AutoSys instance */
job_type: CMD                     /* CMD, BOX, or FW */
description: "What this job does" /* free text, shows in WCC */
owner: batchuser                  /* OS user the command runs as */
machine: prod-server-01           /* agent machine where job executes */
permission: gx,ge,wx,we,mx,me     /* who can view/edit/run this job */

📊 Production Insight

Machine attribute is critical — if the agent is down, all jobs pointing to it fail.

Use global machine groups for failover; a single machine is a single point of failure.

Permission mistakes are silent: someone can 'reuse' your job name and overwrite it.

🎯 Key Takeaway

Identity attributes are mandatory and immutable during job execution.

Never reuse a job name — AutoSys treats it as an update, not a new job.

Set permission tightly: gx,ge,wx,we,mx,me is a safe starting point.

When to use which job_type

IfJob runs a shell command or script

→

UseUse job_type: CMD

IfJob groups other jobs with dependencies

→

UseUse job_type: BOX

IfJob runs when a file appears

→

UseUse job_type: FW (File Watcher)

Scheduling attributes

These attributes control when the job runs. The most common mistake is forgetting date_conditions: 1 — without it, start_times, days_of_week, run_calendar are all ignored. The run_window attribute restricts when the job may run (useful for overnight batch windows). Timezone is often overlooked but critical when your agents are in different timezones than your control server.

scheduling_attributes.jil · BASH

12345678

/* Enable time-based scheduling (must be 1 for start_times to apply) */
date_conditions: 1

/* Days of week: all, mon-fri, or specific days like mon,wed,fri */
days_of_week: mon-fri

/* Time(s) to start — multiple times separated by comma */
start_times: "02:00

⚠ date_conditions: 0 is the default — it disables all time scheduling

If you omit date_conditions entirely, AutoSys assumes 0. Your start_times, days_of_week, run_calendar, exclude_calendar, run_window, and timezone attributes are silently ignored. The job will only run when triggered by a condition or manually. Always explicitly include date_conditions: 1 when you intend time-based scheduling.

📊 Production Insight

The most common production incident in AutoSys is a job that never starts because date_conditions was not set.

Multiple start_times separated by commas — each one generates a separate run in the job's history.

run_window does not prevent start — it prevents the job from continuing if it runs past the window end.

🎯 Key Takeaway

date_conditions: 1 is the master switch for time-based scheduling.

Without it, time attributes are decorative — they have no effect.

Always double-check date_conditions when debugging a job that won't start.

Scheduling configuration decision tree

IfJob needs time-based scheduling

→

UseSet date_conditions: 1 and choose start_times, days_of_week, or run_calendar

IfJob runs only on condition (other job success)

→

UseSet date_conditions: 0 (or omit) and use condition attribute

IfJob must not run outside business hours

→

UseSet run_window to restrict active period

Dependency and condition attributes

These attributes define what must be true before this job can start. Conditions use built-in functions: success(job), failure(job), done(job), notrunning(job). Multiple conditions can be combined with AND and OR. The box_name attribute links the job to a parent box — the box must be RUNNING for the job to start. Job_load and max_run_alarm provide load and runtime monitoring.

dependency_attributes.jil · BASH

12345678910111213141516

/* Start condition — use success(), failure(), done(), notrunning() */
condition: success(upstream_job)

/* Multiple conditions — AND is implied between them */
condition: success(job_a) AND success(job_b)

/* OR condition */
condition: success(job_a) OR success(job_b)

/* Box membership */
box_name: parent_box_name         /* links this job into a box */

/* Priority — higher number = higher priority when resources are constrained */
job_load: 10                      /* how much machine capacity this job uses */
max_run_alarm: 60                 /* alert if running longer than 60 minutes */
min_run_alarm: 5                  /* alert if completed faster than 5 minutes */

🔥Condition functions — what they check

success(job) = status is SUCCESS after most recent start. failure(job) = status is FAILURE. done(job) = status is SUCCESS or FAILURE (finished). notrunning(job) = job is not currently running (any final state qualifies). Use done() when you want to proceed regardless of outcome.

📊 Production Insight

Conditions are case-sensitive regarding job names — mismatch causes job to wait forever.

AND has higher precedence than OR: use parentheses to group, e.g., (A OR B) AND C.

Avoid complex nested conditions; they are hard to debug when a job doesn't start.

🎯 Key Takeaway

Keep conditions simple — one or two dependencies per job.

Use box jobs to group related dependencies instead of writing complex conditions.

Always test conditions with autorep -j jobname -q to see the effective value.

Condition function selection

IfJob must succeed to proceed

→

UseUse success(upstream_job)

IfProceed regardless of upstream outcome

→

UseUse done(upstream_job)

IfProceed only if upstream failed (e.g., cleanup)

→

UseUse failure(upstream_job)

Output and logging attributes

Always set these. Debugging any AutoSys job failure without log files is extremely painful. The std_out_file captures standard output, and std_err_file captures standard error. If std_err_file is not set, error messages are lost. Use the > prefix to append instead of overwrite. You can also redirect to syslog using the \$AUTOUSER variable.

output_attributes.jil · BASH

1234567891011

/* Standard output file path */
std_out_file: /logs/autosys/my_job.out

/* Standard error file path */
std_err_file: /logs/autosys/my_job.err

/* Append to existing log instead of overwrite */
std_out_file: >/logs/autosys/my_job.out     /* > prefix means append */

/* Send output to syslog */
std_out_file: \$AUTOUSER/out/syslog.txt

⚠ Always define std_err_file on every CMD job

When a job fails and you're debugging at 2 AM, the first thing you look at is the error log. If std_err_file isn't set, error output goes nowhere. Make it a standard to always include both std_out_file and std_err_file in every CMD job definition.

📊 Production Insight

Without std_err_file, error output is directed to AutoSys's own log — hard to find.

Use consistent naming: /logs/autosys/<jobname>.out and .err.

Append mode prevents losing old logs when a job runs multiple times.

🎯 Key Takeaway

Every CMD job needs std_out_file and std_err_file.

Without them, you're flying blind when failures happen.

Set them in every job template — it's a non-negotiable production standard.

Failure handling and retry attributes

These attributes control what happens when a job doesn't succeed on its first attempt. The n_retrys attribute is often misunderstood — it's the number of retries after the initial failure, so a job with n_retrys: 3 runs up to 4 times total. term_run_time is your safety net against hung jobs; without it, a stuck job can block an entire chain indefinitely. alarm_if_fail sends a WCC alert on final failure. box_terminator and job_terminator let you cascade failures.

retry_attributes.jil · BASH

12345678910111213141516171819

/* Number of automatic retries before declaring FAILURE */
n_retrys: 3

/* Raise an alarm if job fails */
alarm_if_fail: 1

/* Maximum runtime in minutes before AutoSys terminates the job */
term_run_time: 90

/* Mark this job as a 'box terminator' — if it fails, fail the whole box */
box_terminator: 1

/* Mark this job as a 'job terminator' — if it fails, the job itself terminates */
job_terminator: 1

/* Send notification email on failure */
notification: mail
notification_emailaddress: oncall-team@company.com
notification_msg: "Job %s failed on machine %m at %t"

🔥How n_retrys interacts with job state

When a job with n_retrys: 2 fails, AutoSys sets status to RESTART and retries. If all retries fail, the job goes to FAILURE. You can see the retry count in autorep output. Note: retries are not instantaneous; there is a configurable retry interval (default 0, meaning immediate).

📊 Production Insight

A job with n_retrys: 3 may run 4 times, each consuming resources — set carefully.

Without term_run_time, a job that deadlocks will hold downstream jobs forever.

box_terminator kills all remaining jobs in the box — use it only for critical failures.

🎯 Key Takeaway

n_retrys counts retries after initial failure — total attempts = n_retrys + 1.

alarm_if_fail: 0 is default — you won't get alert on failure unless you set it.

Always set term_run_time to prevent runaway jobs from blocking the pipeline.

Retry and termination setup

IfJob is flaky (network, resource contention)

→

UseSet n_retrys: 2-3 and alarm_if_fail: 1

IfJob is critical — must not hold up the box

→

UseSet box_terminator: 1 so the whole box fails fast

IfJob might hang (e.g., large file transfer)

→

UseSet term_run_time to a reasonable timeout (e.g., 120 min)

Job lifecycle attributes: insert_job, update_job, delete_job

This isn't a JIL attribute but a JIL command that defines how jobs are created and modified. insert_job creates a new job; using the same job name again with insert_job updates the existing job (not an error). update_job changes attributes on an existing job without affecting the schedule. delete_job removes the job definition. One-time overrides can be applied with job_name.start_times etc. in a separate JIL file.

lifecycle_jil.jil · BASH

12345678910111213141516

/* Insert a new job (or update if exists) */
insert_job: daily_backup
job_type: CMD
command: /scripts/backup.sh
machine: prod-db-01
owner: dbadmin

/* Update an existing job's machine */
update_job: daily_backup
machine: prod-db-02

/* Delete a job */
delete_job: daily_backup

/* One-time override for a specific run */
daily_backup.start_times: "03:00"

Mental Model

JIL is declarative, not procedural

Think of JIL as a configuration file — each insert_job defines the desired state of a job.

The same job can be inserted multiple times; each call adds or updates attributes.
delete_job removes the job entirely — there is no undo.
One-time overrides are temporary and reset after the job runs.
Always use update_job for changes; re-inserting is for adding new jobs.

📊 Production Insight

Mistaking insert_job for update_job is harmless — but missing delete_job can leave orphan jobs.

One-time overrides are powerful but easy to forget; they disappear after the run.

Use version control on your JIL files to track changes over time.

🎯 Key Takeaway

insert_job creates or updates; update_job is for attribute changes only.

One-time overrides reset after job execution — not persistent.

Always maintain a backup of current JIL definitions in source control.

Calendars and global variables

AutoSys allows the use of named calendars to define complex schedules. A calendar is a JIL object that defines a set of dates (e.g., month-end, holidays). Jobs can reference calendars via run_calendar and exclude_calendar attributes. Global variables are defined using \$VAR syntax and can be shared across jobs. They are resolved at runtime by the agent.

calendar_and_global.jil · BASH

1234567891011121314151617

/* Calendar definition */
insert_calendar: eom_calendar
description: "End of month business days"
weekdays: mon-fri
condition: day_of_week = MON,TUE,WED,THU,FRI AND day_of_month = LAST

/* Job referencing calendar */
insert_job: month_end_report
job_type: CMD
command: /scripts/report.sh
machine: prod-app-01
run_calendar: eom_calendar
exclude_calendar: holidays
start_times: "23:00"

/* Using global variable in command */
command: /scripts/process.sh \$HOME dir://data

🔥Global variables are resolved on the agent machine

Global variables like \$AUTOUSER are set by the AutoSys agent at job execution time. They refer to the agent's local environment, not the control server's. Use them for paths that vary across machines.

📊 Production Insight

Calendar definitions are shared — changing one calendar can affect hundreds of jobs.

Exclude_calendar is silent: if the exclude calendar is missing, no exclusion occurs.

Global variables in command strings are not validated; a typo produces a failed command.

🎯 Key Takeaway

Calendars centralise scheduling logic — one change affects all referencing jobs.

exclude_calendar removes dates from run_calendar — useful for holidays.

Test calendar logic with autorep -c calendar_name to verify expected dates.

🗂 Core JIL Attribute Quick Reference

Required vs optional, defaults and when to use

Attribute	What it controls	Required?	Default if omitted
job_type	CMD, BOX, or FW	Yes	None — must specify
machine	Which agent runs the job	Yes (CMD/FW)	None
owner	OS user to run as	Yes	None
date_conditions	Enable time-based scheduling	No	0 (disabled)
start_times	When to start	If date_conditions=1	None
condition	Dependency on other jobs	No	None (no dependency)
n_retrys	Automatic retry count	No	0 (no retries)
alarm_if_fail	Alert on failure	No	0 (no alert)
term_run_time	Kill after N minutes	No	None (no limit)
std_out_file	Stdout log path	No	None (stdout discarded)
std_err_file	Stderr log path	No	None (stderr discarded)
run_calendar	Named calendar for scheduling	No	None (no calendar)
exclude_calendar	Exclude dates from run_calendar	No	None (no exclusion)
box_name	Parent box	No	None (not in box)
box_terminator	Kill whole box on failure	No	0 (no)
notification	Email notification method	No	None

🎯 Key Takeaways

Always set std_out_file and std_err_file on every CMD job — they are your primary debugging tools
date_conditions: 1 must be set for start_times to take effect — without it, time-based scheduling is disabled
n_retrys: 3 means 3 retries after initial failure — the job runs up to 4 times total
term_run_time terminates a hung job after N minutes — critical for preventing downstream job pile-ups
Permissions matter in shared environments — use permission attribute to control access
Calendars centralise scheduling — one change affects all jobs referencing that calendar
Use box_terminator sparingly — only for jobs whose failure invalidates the entire box

⚠ Common Mistakes to Avoid

✕Not setting std_out_file and std_err_file

Symptom

When a job fails, you have no logs to inspect. Error output goes to AutoSys's internal log, which is hard to access.

Fix

Add std_out_file and std_err_file to every CMD job. Use consistent paths like /logs/autosys/jobname.out and .err.

✕Setting date_conditions: 0 and expecting start_times to work

Symptom

Job never starts at the intended time because start_times is ignored when date_conditions is 0.

Fix

Always set date_conditions: 1 when using start_times, days_of_week, or run_calendar.

✕Forgetting that n_retrys: 3 means 3 retries after initial failure

Symptom

Job runs up to 4 times total. If each run takes 30 minutes, the job runs for 2 hours before failing.

Fix

Understand the counting: n_retrys counts retries after the first failure. Total attempts = n_retrys + 1.

✕Not setting term_run_time

Symptom

A hung job runs forever, blocking downstream jobs and causing SLA misses.

Fix

Add term_run_time to every job that could hang. A value of 120 minutes is a reasonable default for most batch jobs.

✕Setting alarm_if_fail: 0 (default) and expecting alerts

Symptom

Job fails at 3 AM but no one is notified. The failure is discovered hours later by a downstream impact.

Fix

Set alarm_if_fail: 1 for all critical jobs. Optionally configure notification email or SNMP trap.

✕Using box_terminator on a non-critical job

Symptom

A minor job fails, and the entire box terminates, killing other jobs unnecessarily.

Fix

Only set box_terminator: 1 for jobs that are truly critical to the box's success. Use job_terminator for self-termination.

Interview Questions on This Topic

QWhat does the date_conditions attribute do in AutoSys JIL?JuniorReveal
date_conditions is a master switch that controls whether time-based scheduling attributes (start_times, days_of_week, run_calendar, exclude_calendar, run_window, timezone) are effective. If set to 0 or omitted (defaults to 0), the job ignores all time scheduling and only runs when triggered by a condition or manual start. Must be set to 1 to enable time-based scheduling.
QWhat is the difference between n_retrys and restarting a job manually?Mid-levelReveal
n_retrys is automatic retries performed by AutoSys without human intervention. The job is retried up to the specified count after an initial failure. Restarting a job manually (via sendevent -E FORCE_START) bypasses retry logic and resets the attempt count. n_retrys applies only to the original run; manual restarts do not count toward the retry limit.
QWhat attributes control failure notifications in AutoSys?SeniorReveal
alarm_if_fail: 1 enables WCC alarm on failure. For email notification, set notification: mail along with notification_emailaddress and optionally notification_msg for custom message. The notification_message can include placeholders: %s for job name, %m for machine, %t for time. Also, max_run_alarm and min_run_alarm can send alerts for run time thresholds.
QWhat does term_run_time do and why is it important?JuniorReveal
term_run_time specifies the maximum runtime in minutes after which AutoSys terminates the job (sends KILLJOB). It's critical to prevent hung jobs from blocking downstream jobs indefinitely. Without it, a job that deadlocks or waits forever can hold up the entire batch chain, causing missed SLAs.
QIf a job has n_retrys: 3 and fails every time, how many times does it actually run?JuniorReveal
4 times. The initial run counts as attempt 1, and n_retrys: 3 means 3 automatic retries after the initial failure. Total attempts = 1 (initial) + n_retrys = 4. After the 4th failure, the job goes to FAILURE status.
QExplain the difference between box_terminator and job_terminator.SeniorReveal
box_terminator: 1 causes the entire parent box to terminate if this job fails. All other jobs inside the box are killed. job_terminator: 1 causes only this job to terminate after failure (no retries). Use box_terminator for critical jobs whose failure makes the box's results invalid; use job_terminator to stop further automatic retries on a job that should not retry.

Frequently Asked Questions

What is date_conditions in AutoSys?

date_conditions controls whether time-based scheduling (start_times, days_of_week, run_calendar) is active for a job. Set to 1 to enable time-based scheduling; set to 0 to disable it. If date_conditions is 0, the job only runs when triggered by a condition (another job's success/failure) or manually.

How does n_retrys work in AutoSys?

n_retrys specifies how many times AutoSys automatically retries a failed job before declaring it a final FAILURE. If n_retrys is 3 and the job fails, AutoSys retries 3 times for a total of 4 attempts. After all retries are exhausted, the job moves to FAILURE status.

What happens if term_run_time is not set?

Without term_run_time, a job that hangs or runs indefinitely will continue forever. This can block all downstream jobs waiting on it. Always set a reasonable term_run_time to ensure hung jobs are terminated automatically.

What is the box_terminator attribute in AutoSys?

box_terminator: 1 marks a job as the 'kill switch' for its parent box. If this job fails, the entire box (and all remaining jobs in it) is terminated immediately, rather than waiting for other jobs to complete or fail.

How do I send email notifications from AutoSys?

Set alarm_if_fail: 1 and configure notification attributes: set notification: mail and notification_emailaddress: your-team@company.com. You can also customise the notification message with the notification_msg attribute, which supports placeholders like %s (job name), %m (machine), %t (time).

What is the difference between run_window and start_times?

start_times defines specific times when the job can start. run_window defines a time range during which the job is allowed to run. If a job starts at a start_time but runs past the run_window end, AutoSys terminates it. run_window is useful for batch windows (e.g., overnight only).

Can I use both date_conditions and condition together?

Yes. When both are present, the job starts only when the time conditions are satisfied AND the condition dependencies are met. This is common for jobs that run at a specific time but wait for upstream tasks to finish.

🔥

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