Troubleshooting data for waits or loops

CICS® MustGather for waits or loops

A wait or hang occurs for different reasons. For example, the region might be at the MXT limit, so no new tasks can be attached. Or the region might wait for an ECB to be posted. A loop is the repeated execution of some code.

If you suspect that the problem is due to another IBM® product or subsystem like MVS™ system logger, Db2®, VSAM, or RLS, see the MustGather document for that particular component. Otherwise, gather the following diagnostic information before contacting the CICS support team to troubleshoot your wait or loop problems.

Required data:
  1. The CICS internal trace that is included in the MVS system dump when tracing is active. Ensure that the internal trace table size is big enough to contain sufficient data for diagnosis; for example, you can use a table size of 20480K. When possible, turn on level 1 tracing for all CICS components. For more information, see Using trace for CICS problem determination on z/OS®.
  2. An MVS system dump of the CICS region that is taken as soon as you notice the hang or wait. For more information, see Using dumps for CICS problem determination on z/OS. Use the following MVS command followed by the reply to capture the dump:
    DUMP COMM=(dumpname)
R yy,JOBNAME=(cicsjob),
SDATA=(ALLNUC,PSA,SQA,CSA,LPA,TRT,LSQA,RGN)

    where:

    dumpname
    Specifies the name you want to give the dump.
    yy
    Specifies the reply identifier.
    cicsjob
    Specifies the job name of your CICS region.
  3. The CPU utilization for the CICS region. To display the active CICS job, enter S.DA when you use SDSF under TSO. Enter PF11 to display the percent of CPU time that is used on behalf of this address space during the most recent interval measured.
Optional data:
  1. The CICS message log that contains the last message created by CICS and the time the message was created.
  2. If you can reproduce the problem, consider using the CICS auxiliary trace or the GTF Trace with the MVS system dump. The MVS system dump alone is unlikely to show anything about system activity in the period that leads up to the wait because the trace table probably wraps before you have a chance to respond. For more information, see Using trace for CICS problem determination on z/OS.