The process is looping

If no deadlock exists between threads and the process appears to be hanging but is consuming CPU time, look at the work the threads are doing. To do this, take a console-initiated dump (SVC dump).

Follow these steps to take a console-initiated dump:

Use the operating system commands (D OMVS,A=ALL) or SDSF (DA = Display Active) to locate the ASID of interest.
Use the DUMP command to take a console-initiated dump both for hangs and for loops:
```
DUMP COMM=(Dump for problem 12345) 
R xx,ASID=(53,d),DSPNAME=('OMVS '.*),CONT
R yy,SDATA=(GRSQ,LSQA,RGN,SUM,SWA,TRT,LPA,NUC,SQA)
```
Prefix all commands on the SDSF panels with a forward slash (/). The console responds to the DUMP command with a message requesting additional operands, and provides you with a 2-digit reply ID. You supply the additional operands using the R (reply) command, specifying the reply ID (shown as xx or yy in the previous example). You can use multiple replies for the operands by specifying the CONT operand, as in the previous example.

You can select the process to dump using the z/OS® job name instead of the ASID:

R xx,JOBNAME=SSHD9,CONT

When the console dump has been generated, you can view the Systrace in IPCS to identify threads that are looping. You can do this in IPCS as follows:

ip systrace asid(x'007d') time(gmt)

This command formats out the system trace entries for all threads that are in address space 0x7d. The time(gmt) option converts the TOD clock entries, which are in the system trace, to a human readable form.

From the output produced, you can determine which are the looping threads by identifying patterns of repeated CLCK and EXT1005 interrupt trace entries, and subsequent redispatch DSP entries. You can identify the instruction address range of the loop from the PSWs (Program Status Words) that are traced in these entries.

You can also analyze z/OS console (SVC) dumps using the system dump viewer provided in the SDK, see Dump viewer.