Job ends with 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 Job ends with 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.