JIL One-Time Job Overrides in AutoSys — Temporary Job Changes

Sometimes you need to run a job differently for just one execution — a different start time, a different machine, a different command argument — without changing the permanent job definition. That's what one-time overrides are for.

This is a genuinely useful feature that many AutoSys users don't know about. Instead of updating the job, running it, then updating it back, you use override_job to specify the temporary change and it applies only to the next run.

How override_job works

override_job creates a temporary set of attribute changes that apply to the next execution of a job, then expire automatically after that run. The permanent job definition is unchanged. The override is stored in AutoSys's Event Server as a separate record keyed by job name. It's conceptually like a sticky note — attached until the job runs once, then discarded.

You can override any attribute that is normally set with insert_job or update_job: start_times, condition, machine, command, owner, etc. Multiple attributes can be overridden in one override_job statement by listing them each on a new line after the override_job: directive.

/* Normal definition: runs at 02:00 daily */
/* override_job: run it at 03:30 just this once */
override_job: daily_report
start_times: "03:30"

/* Override: run on a different machine for next run only */
override_job: etl_extract
machine: etl-server-backup

/* Override: temporarily skip a condition for next run */
override_job: generate_summary
condition:      /* empty condition = no condition for this run */

Viewing active overrides

You can see what overrides are currently active using autorep. This is important to check when a job behaves unexpectedly — it might have an active override you didn't know about. The -d (detail) flag shows overrides separately from base values, while -q (JIL query) shows the full effective JIL including any overrides merged in.

# See all attributes of a job including any active overrides
autorep -J daily_report -d

# The -d flag shows 'override' values separately from base values
# Look for lines marked with [OVERRIDE] in the output

# Check the JIL including overrides
autorep -J daily_report -q

When to use overrides vs permanent updates

Cancelling an active override

There is no direct 'cancel override' command. To remove an active override, you have two options:

1. Run update_job on the same attributes that were overridden. update_job will overwrite the override value and reset the attribute to its new permanent value. The override record is then removed.
2. Run override_job again with the original permanent values. This creates a new override that cancels the effect of the previous one. After the next run, both overrides are consumed.

Option 1 is cleaner and recommended. Option 2 can lead to a chain of overrides that becomes hard to track.

You cannot simply delete an override record via JIL — it's not a separate object. It's attached to the job until the job runs or is updated.

# Option 1: Use update_job to replace the overridden attribute permanently
update_job: daily_report
start_times: "02:00"

# This will also remove the active override for start_times
# After this, the job will use 02:00 permanently.

# Option 2: Override with the original value (if you want to keep the permanent as-is)
override_job: daily_report
start_times: "02:00"
# Now the override matches the permanent — both are 02:00.
# After next run, override expires and permanent value is still 02:00.

Best practices and common pitfalls

Centralise override documentation — every override should be logged in a shared channel or incident tracker. This prevents the 'mysterious behaviour' scenario.

Set a TTL reminder: if you set an override more than a day before the job runs, set a calendar reminder to verify it's still needed.

Avoid overriding condition unless you fully understand the dependency chain. An empty condition can cause a job to run out of order and break downstream processes.

Use a script to list all active overrides across your environment periodically (autorep -J ALL -d | grep OVERRIDE). This catches forgotten overrides before they cause issues.

# List all jobs with active overrides
autorep -J ALL -d | grep -B5 "OVERRIDE" | grep "Job Name" | awk '{print $NF}'

Frequently Asked Questions