S322 time limit exceeded

S322 means the job step used more CPU time than the installation allows. The system cancels it to protect shared resources.

What it means

• Every job class has a CPU time limit (the TIME parameter); S322 fires when a step exceeds it.
• It signals either a genuine runaway loop or a limit set too low for the workload.

Common causes

• Infinite or near-infinite loop in the program (most common).
• TIME parameter on the JOB or EXEC card set too low for the data volume.
• Algorithmic blowup: nested loops over a much larger file than tested.
• Waiting on a resource while burning CPU (rare; usually shows as low CPU instead).

How to diagnose

• Check the job log for S322 and note which step and program failed.
• Look at CPU seconds used vs the TIME limit on the JOB card.
• Review the program for loops whose exit condition may never trigger with production data.
• Compare CPU time against previous successful runs — a sudden jump points to code or data change.

How to fix it

• Fix the loop: ensure every loop has a reachable exit condition.
• If the program is correct but slow, raise TIME on the EXEC card (with operations approval).
• For large volumes, consider splitting the work or tuning the algorithm.

Example: Raise the step time limit (JCL)

TIME=(,30) allows 30 minutes of CPU for the step.

Interview tip

• Q: How would you troubleshoot a S322 time limit exceeded in production?
• A: I would first check whether it is a runaway loop by reviewing the code path, then compare CPU usage with prior runs; if the program is sound, I would request a higher TIME limit.

Prevention checklist

• Set realistic TIME limits per step.
• Load-test with production-scale volumes before go-live.
• Monitor CPU trends per job so growth is caught early.