AutoSys ON_ICE vs ON_HOLD — Why Release Timing Skips Jobs

ON_HOLD and ON_ICE are the two ways to suspend a job in AutoSys. They're often confused because both stop a job from running — but their release behaviour is completely different, and choosing the wrong one in a production recovery scenario can cause jobs to either run unexpectedly or not run until the next day. Get this distinction right.

ON_HOLD — suspend and resume at current conditions

When a job is ON_HOLD, it is frozen in its current state. If you put a job on hold while its starting conditions were already met, releasing it (OFF_HOLD) will cause it to start immediately — the conditions are still true.

# Put a job on hold
sendevent -E JOB_ON_HOLD -J daily_report

# Release from hold — starts immediately if conditions are met
sendevent -E JOB_OFF_HOLD -J daily_report

# Put an entire BOX on hold (and all inner jobs)
sendevent -E JOB_ON_HOLD -J eod_processing_box

# Check if a job is on hold
autorep -J daily_report   # shows OH status

ON_ICE — suspend and wait for next condition cycle

When a job is ON_ICE, it's more deeply suspended. When you release it (OFF_ICE), the job does NOT start immediately — it waits for its conditions to become true in the next scheduling cycle.

For a job with start_times: '02:00', releasing it from ON_ICE at 3 AM means it won't run until the next scheduled 2 AM — it waits for the condition to reoccur, not to re-evaluate it as currently true.

# Put a job on ice
sendevent -E JOB_ON_ICE -J weekly_reconcile

# Release from ice — waits for conditions to reoccur (next cycle)
sendevent -E JOB_OFF_ICE -J weekly_reconcile

# Check if a job is on ice
autorep -J weekly_reconcile   # shows OI status

Which to use when

The decision is simple once you understand the release behaviour:

Use ON_HOLD when: You want to delay a job temporarily and start it manually when ready. Maintenance windows. Jobs you want to run manually at a specific moment after releasing.

Use ON_ICE when: You want to skip a job for the current scheduling period and have it resume at its next normal scheduled time. Disabling a job for a few days without permanently modifying its definition. Safe suspension when you're not sure when you'll release it.

# Scenario 1: Emergency maintenance, want to run job manually when done
# Use ON_HOLD — releases will start immediately when ready
sendevent -E JOB_ON_HOLD -J daily_settlement
# ... do maintenance ...
sendevent -E JOB_OFF_HOLD -J daily_settlement   # starts now

# Scenario 2: Job has a bug being fixed, skip today's run
# Use ON_ICE — releases will wait for tomorrow's scheduled run
sendevent -E JOB_ON_ICE -J daily_settlement
# ... fix deployed by end of day ...
sendevent -E JOB_OFF_ICE -J daily_settlement   # runs tomorrow at 02:00 as normal

How ON_HOLD and ON_ICE affect dependencies

Both statuses affect downstream jobs that depend on the held/frozen job.

When a job is ON_HOLD, it cannot reach SUCCESS or FAILURE, so any downstream jobs that wait for it (via conditions) will remain in a pending state. Releasing from ON_HOLD will start the job, and once it completes, the downstream jobs will then run.

When a job is ON_ICE, same effect — it cannot complete, so dependents wait forever until the job is taken off ice and eventually runs.

The difference: if you put a job ON_HOLD and it already satisfied its own conditions, it will run immediately on release — downstream jobs start soon. If you put it ON_ICE, the job still needs to wait for its next condition cycle, so downstream jobs stay waiting longer.

# Job B depends on Job A
autorep -J Job_B   # Shows status: WAITING (because Job A is ON_HOLD or ON_ICE)

# If Job A is ON_HOLD and you release it:
sendevent -E JOB_OFF_HOLD -J Job_A
# Job A runs now -> succeeds -> Job B starts

# If Job A is ON_ICE and you release it:
sendevent -E JOB_OFF_ICE -J Job_A
# Job A waits until next scheduled time -> only then runs -> Job B waits even longer

Debugging jobs that won't start — hold/ice troubleshooting

When a job doesn't start and you suspect a hold or ice status, follow these steps:

1. Run autorep -J jobname and look for ST column — OH or OI indicates the job is held/iced.
2. Check the status of any parent box: autorep -J boxname — if the box is OH/OI, inner jobs are blocked even if they look normal.
3. Review sendevent history to see who set the hold/ice: check autorep logs or event trail.
4. If a box is held and you release it, inner jobs might start immediately based on their own conditions — be cautious.

To clear a hold: sendevent -E JOB_OFF_HOLD -J jobname To clear ice: sendevent -E JOB_OFF_ICE -J jobname

# Check job status
autorep -J daily_report
# Output: ... ST: OH ... -> ON_HOLD

# Check box status (inner jobs may be blocked)
autorep -J batch_box

# Check event history (if available)
autorep -J daily_report -w -r

# Force a job ON_HOLD if it's ON_ICE? Not possible directly; must clear ice first.
sendevent -E JOB_OFF_ICE -J daily_report
# Then optionally set hold: sendevent -E JOB_ON_HOLD -J daily_report