S522: Wait time limit exceeded

What it means

z/OS watches for work that has stopped moving. If every task in a job step is waiting, and the wait goes on longer than the limit your installation sets, the system decides the step is stuck and ends it with system completion code 522. The limit for batch jobs is the JWT value in the SMFPRMxx parmlib member. Sites can set separate values for TSO users and for started tasks.

The wait has to be continuous. A step that wakes up now and then to do some work starts the clock again. So an S522 in batch means the program stopped and waited for something that never happened. In TSO it nearly always means the session was left idle, at the READY prompt or on an ISPF panel, for longer than the limit.

S322 ends a step that used too much processor time. S522 ends one that used none for too long.

Common causes

• A TSO user left the session idle past the site's limit. This is the most common S522, and no program is at fault.
• A batch program issued a WTOR, a console message that waits for an operator reply, and nobody answered in time.
• The program was waiting for something another job held, such as a data set it allocated dynamically or a resource serialized with ENQ.
• The program was waiting for an event that never came, such as a subtask that ended without signalling, or a partner program over TCP/IP or MQ that never replied.

How to find the problem

1. Check whether it was TSO or batch. For TSO, the IEF450I message carries your user ID, and the cause is almost always idle time.
2. For batch, subtract your site's wait limit from the abend time. That is roughly when the wait began. Look at the job log and the system log at that moment for the last thing the step did.
3. If the job is waiting again on a rerun, ask operations to look before it times out. The operator command D GRS,C shows ENQ contention, and D R,L lists outstanding replies.
4. Check the CPU time in the step end message (IEF032I). A tiny CPU figure after a long elapsed time confirms the step spent its life waiting.

How to fix it

• For TSO, log on again. If the idle limit gets in the way of real work, ask your systems team about it. Don't run a script to keep the session busy unless your site allows it.
• For a WTOR, tell operations the job will ask a question and what to answer, or change the program so it doesn't need a reply.
• For a resource wait, schedule the job so it doesn't run alongside the job that holds the resource, or add that dependency in your scheduler.
• For a program designed to wait, such as a listener or server, code TIME=1440 or TIME=NOLIMIT on its EXEC statement. That switches off the wait limit for the step. It also switches off the CPU limit, so keep it for programs that are meant to run that way.
• Fix any program that waits for an event that can't happen, such as a post from a subtask that has already ended.

What it looks like

*07 INVS01A INVSYNC1 PARTNER FILE NOT READY. REPLY RETRY OR END
IEF450I INVSYNC1 STEP020 - ABEND=S522 U0000 REASON=00000000
IEF032I STEP/STEP020 /STOP 2026285.0347
        CPU:     0 HR  00 MIN  00.41 SEC    SRB:     0 HR  00 MIN  00.01 SEC

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.