S222: Cancelled, without a dump

What it means

S222 isn't a program error. It's the code z/OS gives a step that was stopped by a cancel request without the DUMP option. With DUMP, the same cancel produces S122.

There are several ways to cancel a running job. An operator can enter CANCEL jobname at a console, or use the JES2 $C command. Anyone with the authority can use the C action in SDSF, which is how most developers cancel their own jobs. Job schedulers and automation products issue the same commands under their rules. A TSO session cancelled with CANCEL U=userid also ends with S222.

Because the cancel comes from outside the job, the job log rarely says why. The system log shows where the command came from.

Common causes

• Someone cancelled it on purpose, often the person who submitted it, because it was submitted by mistake, had the wrong parameters or was taking too long.
• An operator cancelled it because it seemed to be looping or was using a lot of CPU.
• It held a data set or another resource that other work, often an online system, was waiting for.
• A scheduler or automation rule cancelled it after a time limit, or because it was still running when a protected window began.
• It was waiting for something, such as a data set held by another job or a tape mount, and an operator cleared it.
• For TSO, an administrator or the help desk cancelled the session, for example to free a user ID that was stuck.

How to find the problem

1. Confirm the code in IEF450I or in the $HASP395 line at the end of the job's JESMSGLG.
2. Search SYSLOG or OPERLOG at the time of the abend for a CANCEL or $C command against the job. The log entry shows where the command came from.
3. Read the job log just before the cancel. IEF099I (job waiting for data sets), or a long gap in the job's own progress messages, shows what it was doing.
4. If no person issued the command, check your scheduler's and automation product's logs for a rule that acts on this job.
5. Compare the step's CPU and elapsed time with earlier runs. A job that normally takes 5 minutes and was cancelled after 50 was probably looping or waiting.

How to fix it

• If the cancel was deliberate, fix whatever prompted it and resubmit.
• If the job was looping, find the loop. A dump helps, so add a SYSUDUMP DD statement and ask operations to cancel with DUMP next time, which gives an S122.
• If it held resources others needed, change when it runs or how it allocates data sets, such as DISP=SHR for data sets the step only reads.
• If automation cancelled it, update the rule with the job's real run time.
• Before rerunning, check the output data sets from the cancelled step. They may be partly written, so delete them or restart from the step that creates them.

What it looks like

CANCEL GLPOST03
IEE301I GLPOST03 CANCEL COMMAND ACCEPTED
IEF450I GLPOST03 STEP020 - ABEND=S222 U0000 REASON=00000000
$HASP395 GLPOST03 ENDED - ABEND=S222

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.