S122: Cancelled by the operator, with a dump

What it means

An operator ends a running job with the CANCEL command. If the command includes the DUMP option, as in CANCEL PAYRUN01,DUMP, the step ends with system completion code 122. Without that option it ends with S222. TSO users cancelled with CANCEL U=userid,DUMP get the same code.

Operators rarely cancel a job that is behaving normally, so the reason for the cancel often lies in the program. The usual triggers are a job that seems to be looping, a job holding data sets or other resources that other work is waiting for, or a job still running after it should have finished, such as past the end of the batch window.

The dump is the useful part. If the step had a SYSUDUMP, SYSABEND or SYSMDUMP DD statement, the dump shows what the program was doing at the moment it was cancelled.

Common causes

• The job looked like it was looping, using CPU without making progress, so the operator cancelled it with a dump to see where.
• The job held a data set, an enqueue or a tape drive that other jobs or an online system were waiting for.
• The job ran past its expected end time or into the online day, and an operator or the scheduler stopped it.
• Automation software cancelled it under a rule, such as a limit on run time.
• The job was stuck waiting for something that wasn't going to arrive, such as a tape mount or a data set held by another job, and an operator cleared it.

How to find the problem

1. Confirm it was a cancel. IEF450I shows ABEND=S122, and SYSLOG or OPERLOG shows a CANCEL command for the job, followed by IEE301I jobname CANCEL COMMAND ACCEPTED.
2. Note the time of the command and where it came from, then ask operations why the job was cancelled.
3. Read the job log just before the cancel. A message such as IEF099I (job waiting for data sets), or a long gap in the job's own progress messages, shows what state it was in.
4. If a dump was taken, find the PSW and the active load module in it. For a loop, the PSW will be inside the loop, so match its offset to the compiler listing to find the statement.
5. Compare the step's CPU and elapsed time with earlier runs, from SMF or your scheduler's history, to see whether this run was out of line.

How to fix it

• If the job was looping, fix the loop. Common sources are a missing end-of-file test, a PERFORM UNTIL whose condition never becomes true, and a read that never moves to the next record.
• If it held resources others needed, change when it runs or how it allocates its data sets. For example, use DISP=SHR instead of DISP=OLD for data sets the step only reads.
• If it was slow but working, tune it, or tell operations and the scheduling team how long it really takes so it isn't cancelled again.
• Rerun or restart the step once you know the cause. A cancelled step may have left output data sets half written, so check them or restart from the step that creates them.

What it looks like

CANCEL PAYRUN01,DUMP
IEE301I PAYRUN01 CANCEL COMMAND ACCEPTED
IEF450I PAYRUN01 STEP030 - ABEND=S122 U0000 REASON=00000000
$HASP395 PAYRUN01 ENDED - ABEND=S122

Last reviewed 2026-10-12 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS, CICS or Db2 release.