S322 — CPU time limit exceeded

What happened

The step is ended by the system with S322. It may have been running a long time, and its output may be very large or stopped growing.

IEF450I BILLJOB1 STEP050 - ABEND=S322 U0000 REASON=00000000
        TIME=02.41.17

What it means

Every job and step has a CPU time limit. When the CPU time used — not the elapsed time — reaches the limit, z/OS ends the work with S322.

The limit comes from the TIME parameter. On the JOB statement it caps the whole job; on the EXEC statement it caps one step. A step gets the smaller of its own TIME and the job time still left. If TIME is not coded, the job class default set by your site in JES2 applies. TIME=1440 or TIME=NOLIMIT removes the limit. Sites can also adjust limits through installation exits, so check local standards.

Typical causes

• A program loop: a PERFORM UNTIL whose condition never becomes true, or an end-of-file flag that is never set.
• Legitimately higher volume — more input records than the limit allowed for.
• A worse Db2 access path after statistics or a rebind, so each record costs far more CPU.
• Duplicated or wrong input, such as the same file concatenated twice.
• A TIME value or job class too small for the work, often after a job was copied or moved.

Symptoms

CPU time climbs steadily until the limit. A loop often shows no new output, or output growing endlessly with repeated records. Compare with S522, which is wait time exceeded with no CPU use, and S222, which is a cancel by an operator or automation.

Where to look

• JESMSGLG and JESYSMSG: the abend, and step statistics showing CPU time used.
• JESJCL: TIME on the JOB and EXEC, and the job CLASS.
• Scheduler history or SMF-based reports: CPU and record counts for previous runs.
• Program output and DISPLAYs: the last record processed, and whether it was moving.
• Db2 accounting or RMF data if the step uses Db2 or the system was busy.

How to diagnose

1. Check which limit was hit: job TIME, step TIME or class default.
2. Compare CPU used and input volume with previous good runs.
3. If the volume grew in proportion to CPU, the limit is simply too low.
4. If CPU per record jumped, look for an access path or code change.
5. If output stopped or repeated, look for a loop at the last record processed.
6. Check recent changes to the program, input files and Db2 statistics.

How to fix

Raising TIME is the fix only when the job did more legitimate work and CPU per record is normal. Then raise the step TIME, or move the job to a suitable class, through change control. It is not the fix for a loop, a bad access path or duplicated input — those need the code, the Db2 package or the data corrected. Before rerunning, check whether the step updated files or tables; restart from a Checkpoint / restart record if the program supports it, or restore and Rerun from the top.

How to prevent

• Set step TIME from measured CPU use plus headroom, not 1440 by default.
• Track CPU and record counts per run and alert on sudden changes.
• Code loops with a clear exit and a maximum-iteration safety check where sensible.
• Review access paths after RUNSTATS or rebinds on critical jobs.

Production considerations

Interview question

A job abends S322. Do you increase TIME?