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
✦ Definition~90s read
What is JIL Attributes Complete Reference?
AutoSys JIL (Job Information Language) is the declarative configuration language for CA Workload Automation AE (AutoSys). It defines every aspect of a job—its identity, schedule, dependencies, failure handling, and logging—in a flat, key-value format.
★
JIL attributes are like the settings panel for each AutoSys job.
The JIL attribute reference is the canonical map of every possible setting you can apply to a job definition. Without it, you're flying blind: one misconfigured date_conditions default can silently stall an entire production workflow, as this article's title warns.
The reference exists because AutoSys jobs are state machines; each attribute controls a transition, and defaults (like date_conditions: 1 when you expect 0) are the most common source of jobs that never run.
In practice, the JIL reference is your single source of truth when debugging why a job didn't start, why it restarted 47 times, or why logs went to /dev/null. It covers identity attributes (job_name, owner, machine), scheduling attributes (start_times, run_calendar, date_conditions), dependency conditions (condition: success(jobA)), output/logging (std_out_file, std_err_file), and retry logic (max_retry, term_run_time).
Alternatives like the AutoSys GUI or autorep output are useful for inspection, but they hide defaults and don't let you edit. The JIL reference is what you use to write, audit, or fix a job definition file—especially when a job stalls because date_conditions defaulted to 1 (enabled) on a box job that only runs on condition, not on a calendar.
Where this fits: it's the companion to the jil command-line tool and the autosys_secure database. If you're managing 500+ jobs across multiple environments, you don't memorize every attribute—you keep this reference open. When NOT to use it: for real-time monitoring or ad-hoc job kicks, use sendevent or the GUI.
But for any job that's misbehaving, the first step is always to dump its JIL definition and compare it against this reference. The article's focus on date_conditions default stalling jobs is a concrete example of why understanding defaults—not just the attributes you explicitly set—is critical.
One wrong default can cascade into a missed SLA, and this reference is your checklist to prevent that.
Plain-English First
JIL attributes are like the settings panel for each AutoSys job. Some settings control timing (when to run), some control location (where to run), some control behaviour on failure (retry, alert, stop). This article is your reference guide for all of them.
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.
Why JIL Attribute Reference Is Your Job's Lifeline
JIL (Job Information Language) is AutoSys's declarative job definition format. The date_conditions attribute is a boolean flag that, when set to 1, tells AutoSys to evaluate start times, start days, and run calendars before launching a job. Without it, those scheduling fields are ignored entirely — the job runs only on manual trigger or box dependency. This is the core mechanic: date_conditions acts as the master switch for time-based scheduling.
In practice, setting date_conditions: 1 without also defining at least one of start_times, start_days, or run_calendar causes the job to stall indefinitely. AutoSys sees the flag but has no time constraint to satisfy, so it waits forever. The job enters an ACTIVE state but never dispatches. This is a common misconfiguration: teams flip the flag expecting a job to run 'immediately' but instead create a zombie process that consumes a job slot without progressing.
Use date_conditions only when you need precise temporal control — nightly batch windows, end-of-quarter reports, or maintenance windows. For event-driven or dependency-only workflows, leave it at 0 to avoid accidental stalls. The real-world cost is not just a missed run; it's a cascading failure when downstream jobs depend on a stalled upstream job, creating a silent DAG freeze that ops teams chase for hours.
The Silent Stall Trap
Setting date_conditions:1 without start_times or run_calendar is the #1 cause of jobs that appear active but never run — no error, no alert.
Production Insight
A financial reconciliation job stalled for 8 hours because date_conditions was set to 1 but start_times was accidentally omitted after a JIL copy-paste.
Symptom: job in ACTIVE state, no execution, downstream batch queue completely blocked, no alarms triggered because the job wasn't in FAILURE.
Rule: always validate that date_conditions:1 is paired with at least one time-based attribute — add a pre-deploy JIL linter check.
Key Takeaway
date_conditions is a gate, not a trigger — without a time attribute, the gate never opens.
A job with date_conditions:1 but no start_times will stall silently, not fail.
Always pair date_conditions with start_times, start_days, or run_calendar — never set it alone.
thecodeforge.io
JIL Attribute Groups
Jil Attributes Complete Reference
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.jilBASH
1
2
3
4
5
6
insert_job: my_job_name /* unique name in thisAutoSys 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.jilBASH
1
2
3
4
5
6
7
8
/* Enable time-based scheduling (must be 1for 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.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* Start condition — use success(), failure(), done(), notrunning() */
condition: success(upstream_job)
/* Multiple conditions — AND is implied between them */
condition: success(job_a) ANDsuccess(job_b)
/* OR condition */
condition: success(job_a) ORsuccess(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.jilBASH
1
2
3
4
5
6
7
8
9
10
11
/* 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.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* 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
/* Markthis job as a 'box terminator' — if it fails, fail the whole box */
box_terminator: 1
/* Markthis 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)
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.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* Insert a newjob (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"
JIL is declarative, not procedural
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.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/* Calendar definition */
insert_calendar: eom_calendar
description: "End of month business days"
weekdays: mon-fri
condition: day_of_week = MON,TUE,WED,THU,FRIAND 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.
Most engineers treat JIL attributes like static config. That's fine until you need to promote a job from dev to prod without touching the definition. Hardcoded paths, credentials, and environment-specific values will burn you during a Sev1. Autosys gives you variable injection through %%VAR%% substitution and Global Variables. Use them.
The trick is understanding evaluation order. Autosys resolves variables at job submission time, not definition time. This means you can override a Global Variable at the box level and have every child job inherit it without redefining each one. It's inheritance without the ceremony.
If you're not using variable injection for your database connection strings, log paths, and server names, you're copy-pasting disaster. One missed update across fifty jobs and your pager goes off at 3 AM. Every JIL definition you write should ask: 'What value here is going to change when this moves to the next environment?' That value becomes a variable.
RuntimeVariableInjection.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// io.thecodeforge — devops tutorial
// Global variable defined in Autosys database
// Environment: prod-database-host
define_global_variable:
DB_HOST_PROD: "db-prod-01.acme.internal"
// Job uses variable via %%VAR%% syntax
insert_job: data_export_payments
job_type: c
command: "/opt/scripts/export.sh --host %%DB_HOST_PROD%% --schema payments"
machine: etl-server-01
condition: s(schema_migration_done)
owner: svc_etl
// Override at box level forDR site
define_global_variable:
DB_HOST_DR: "db-dr-01.acme.internal"
insert_job: box_dr_failover
job_type: box
condition: s(health_check_failed)
profile: DR_PROFILE // sets DB_HOST_PROD to %%DB_HOST_DR%%
Output
Autosys resolves %%DB_HOST_PROD%% at submit time.
In normal flow: command becomes '/opt/scripts/export.sh --host db-prod-01.acme.internal --schema payments'.
In DR flow (via profile override): command becomes '/opt/scripts/export.sh --host db-dr-01.acme.internal --schema payments'.
Zero job definition changes required.
Production Trap:
Variables inside command attributes are NOT re-evaluated if the Global Variable changes while the job is queued. The resolved value is locked at submission time. If you change a password variable mid-run, existing queued jobs still use the old value. Plan your maintenance windows accordingly.
Key Takeaway
Every value that changes between environments should be a %%VAR%%, not a hardcoded string. Variables are resolved at submit time — not definition time — so treat any mid-run Global Variable change as a ticking bomb.
Job Profiling: The Pattern You Ignore Until Disaster Strikes
You've got fifty jobs hitting the same database at midnight. One of them has a memory leak. Which one? Without job profiling via the 'profile' attribute, you're guessing. Profiles let you attach environment-specific settings — paths, variables, resource limits — to jobs at scale. One profile, applied to a hundred jobs, changed in one place.
The real power comes from combining profiles with boxes. Set a profile at the box level. Every child job inherits it. When you need to reroute all jobs in that box to a DR environment, you change one profile attribute. Not fifty job definitions. Not a late-night grep and sed session that misses three.
Profiles also handle runtime context: JOBPATH for executable search order, shell overrides, and environment variable defaults. If you've ever SSH'd into a server at 2 AM wondering why your Python script can't find a module that's definitely installed, you already know why JOBPATH matters. Profile it once, forget it — until the next audit.
JobProfiling.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// io.thecodeforge — devops tutorial
// Base profile for all ETL jobs
define_profile: etl_base
profile_type: c
jobpath: "/opt/etl/scripts:/usr/local/bin:/usr/bin"
profile_env_vars:
PYTHONPATH: "/opt/etl/lib"
LOG_LEVEL: "INFO"
// DR-specific override profile
define_profile: etl_dr
profile_type: c
profile_env_vars:
DB_HOST: "db-dr-01.acme.internal"
LOG_LEVEL: "DEBUG"
// Apply profile at box level — all children inherit
insert_job: box_nightly_etl
job_type: box
profile: etl_base
// Child job inherits etl_base, overrides with etl_dr if condition met
insert_job: etl_payments
job_type: c
command: "python3 payments_loader.py"
machine: etl-server-01
box_name: box_nightly_etl
profile: etl_dr
condition: s(site_dr_active)
Output
Normal operation: etl_payments uses etl_base profile — DB_HOST undefined (defaults to config file), LOG_LEVEL=INFO.
DR active: etl_payments uses etl_dr profile — DB_HOST=db-dr-01.acme.internal, LOG_LEVEL=DEBUG.
Box-level profile still applies JOBPATH. DR override only changes env vars. No redefines needed.
Senior Shortcut:
Always define a 'base' profile with JOBPATH and PYTHONPATH before writing a single job. Then create environment-specific profiles that only override what changes. This makes audit trails obvious — one glance at the profile tells you exactly what runtime context the job expects.
Key Takeaway
Profiles separate runtime configuration from job logic. Set one profile per job type per environment. Override at the box level for mass changes. Never hardcode paths or env vars in a job definition again.
Mastering HTML Attributes
HTML attributes define the behavior and appearance of elements in a web interface, just as JIL attributes control job orchestration in Autosys. Mastering both means understanding how to set values, apply conditions, and avoid conflicts. For JIL, the attribute syntax is strict: every attribute: value pair must follow exact naming conventions. Misspelling max_run_alarm as max_run_alarm silently fails, leaving your job unmonitored. Attributes also cascade through job types: a Box job's run_calendar applies to all child jobs unless overridden. Production engineers often confuse term_run_time (max wall-clock time) with max_exit_success (exit codes). The critical skill is reading attribute documentation like you'd read HTML spec: check data types, default values, and mutual exclusivity rules. For example, alarm_if_fail: y and max_exit_success: 1 cannot coexist—the alarm overrides the exit code check. Always validate attribute pairs in UAT before prod push.
JIL_Mastering_Attributes.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// io.thecodeforge — devops tutorial
// MasterHTML-style attributes in JIL
insert_job: my_job
job_type: c
command: echo "Check attribute order"
machine: prod_srv01
description: "Attributes cascade like HTML style rules"
owner: ops@company.com
permission: gx,wx
max_exit_success: 1 # Only exit code 1 = success
alarm_if_fail: n # Overrides max_exit_success
run_calendar: biz_days
term_run_time: "30:00"
max_run_alarm: 0 # 0 = no alarm (common mistake)
watch_file: "/tmp/trigger.txt"
send_notification: y
notification_email: alerts@company.com
timezone: America/New_York
Using max_exit_success with alarm_if_fail: y creates contradictory logic - the alarm fires even on 'success' exit codes, flooding your pager.
Key Takeaway
Always test attribute combinations in a sandbox; conflicting pairs like alarm/exit_success are the top cause of silent job failures in prod.
What You’ll Learn & Key Highlights
After this reference, you will confidently define every JIL attribute without referencing legacy docs. You’ll learn the difference between condition (dependency on sibling jobs) and watch_file (file-based trigger), and how max_exit_success versus term_run_time govern job success. You’ll master delete_job attributes for safe cleanup (preventing orphan jobs), and understand calendar overrides across time zones. Key highlights: always set max_run_alarm to a nonzero value to catch runaway processes; owner and permission attributes are your first line of RBAC defense; failure_exit_code + max_retry combo is stronger than plain alarm_if_fail. Global variable injection via $$SITE_VAR avoids hardcoded paths. The most overlooked attribute is watch_directory—it prevents file-polling storms. Production engineers who internalize these patterns reduce incident response time by 40%. Avoid the common pitfall of treating insert_job like a one-time script—it’s a declarative contract that must be version-controlled.
// set_job: data_sync inserted. Condition triggers on sibling start. Global vars injected at runtime.
Pattern Insight:
Combining failure_exit_code with max_retry gives fine-grained control: retry only on specific non-zero exits, not blanket retries.
Key Takeaway
Master these 12 attributes—condition, watch_file, failure_exit_code, max_retry, calendar, permission, max_run_alarm—to eliminate 90% of JIL-related incidents.
● Production incidentPOST-MORTEMseverity: high
The Midnight Silence — Job Never Starts Despite Correct Condition
Symptom
Job remains in ACTIVATED or WAITING status past its scheduled start time. Upstream job completed successfully. No errors in event log.
Assumption
The engineer assumed setting start_times alone makes the job run at that time. date_conditions was omitted from the JIL definition.
Root cause
date_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.
Fix
Add 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 guideSymptom → Action4 entries
Symptom · 01
Job stays in ACTIVATED status past start time
→
Fix
Check date_conditions is 1. Verify condition evaluation with autorep -j jobname -q | grep condition. Ensure start_times is not empty.
Symptom · 02
Job fails with EXIT CODE 1 but no visible error
→
Fix
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.
Symptom · 03
Job runs but produces no output
→
Fix
Check std_out_file path permissions. Use > prefix for append mode if file exists. Verify the command inside the job actually writes to stdout.
Symptom · 04
Job runs forever and blocks box
→
Fix
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.
★ AutoSys Quick Debug Cheat SheetImmediate commands and fixes for common job failures
Job is in ACTIVATED but should have started−
Immediate action
Check job definition with autorep -j job_name -q
Commands
autorep -j JOBNAME -q
sendevent -E FORCE_START -J JOBNAME
Fix now
Set date_conditions: 1 in JIL and re-insert job
Job fails with exit code 1, no log+
Immediate action
Look for std_err_file in job definition
Commands
autorep -q -j JOBNAME | grep std_err
cat /logs/autosys/JOBNAME.err (if exists)
Fix now
Add std_err_file to the job JIL and re-run
Job runs infinitely, no term_run_time set+
Immediate action
Kill the job from terminal
Commands
sendevent -E KILLJOB -J JOBNAME
autorep -j JOBNAME -w 20 (wait 20 secs for status)
Fix now
Add term_run_time: 60 to prevent future hangs
Job reports success but downstream jobs don't start+
Immediate action
Check condition on downstream job
Commands
autorep -j DOWNSTREAM_JOB -q | grep condition
autorep -j JOBNAME -w 0 (check exit code)
Fix now
Update downstream condition to match the exit code (s() vs f() vs d())
Core JIL Attribute Quick Reference
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
1
Always set std_out_file and std_err_file on every CMD job
they are your primary debugging tools
2
date_conditions
1 must be set for start_times to take effect — without it, time-based scheduling is disabled
3
n_retrys
3 means 3 retries after initial failure — the job runs up to 4 times total
4
term_run_time terminates a hung job after N minutes
critical for preventing downstream job pile-ups
5
Permissions matter in shared environments
use permission attribute to control access
6
Calendars centralise scheduling
one change affects all jobs referencing that calendar
7
Use box_terminator sparingly
only for jobs whose failure invalidates the entire box
Common mistakes to avoid
6 patterns
×
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 PREP · PRACTICE MODE
Interview Questions on This Topic
Q01JUNIOR
What does the date_conditions attribute do in AutoSys JIL?
Q02SENIOR
What is the difference between n_retrys and restarting a job manually?
Q03SENIOR
What attributes control failure notifications in AutoSys?
Q04JUNIOR
What does term_run_time do and why is it important?
Q05JUNIOR
If a job has n_retrys: 3 and fails every time, how many times does it ac...
Q06SENIOR
Explain the difference between box_terminator and job_terminator.
Q01 of 06JUNIOR
What does the date_conditions attribute do in AutoSys JIL?
ANSWER
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.
Q02 of 06SENIOR
What is the difference between n_retrys and restarting a job manually?
ANSWER
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.
Q03 of 06SENIOR
What attributes control failure notifications in AutoSys?
ANSWER
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.
Q04 of 06JUNIOR
What does term_run_time do and why is it important?
ANSWER
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.
Q05 of 06JUNIOR
If a job has n_retrys: 3 and fails every time, how many times does it actually run?
ANSWER
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.
Q06 of 06SENIOR
Explain the difference between box_terminator and job_terminator.
ANSWER
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.
01
What does the date_conditions attribute do in AutoSys JIL?
JUNIOR
02
What is the difference between n_retrys and restarting a job manually?
SENIOR
03
What attributes control failure notifications in AutoSys?
SENIOR
04
What does term_run_time do and why is it important?
JUNIOR
05
If a job has n_retrys: 3 and fails every time, how many times does it actually run?
JUNIOR
06
Explain the difference between box_terminator and job_terminator.
SENIOR
FAQ · 7 QUESTIONS
Frequently Asked Questions
01
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.
Was this helpful?
02
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.
Was this helpful?
03
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.
Was this helpful?
04
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.
Was this helpful?
05
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).
Was this helpful?
06
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).
Was this helpful?
07
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.