Is a CICS transaction waiting?
Consider the following points:
- CICS(R) could be under stress
- This could indicate that the maximum number of tasks allowed (MAXTASK)
has been reached, or a short on storage (SOS) condition exists. Check the
console log for messages that might explain this (for example, SOS messages),
or see the CICS Problem Determination Guide.
- The transaction could be waiting for another resource
- For example, this could be file I/O. You can use CEMT INQ TASK to see
what the task is waiting for. If the resource type is MQSERIES your transaction
is waiting on WebSphere MQ (either in an MQGET WAIT or a task switch). Otherwise
see the CICS Problem Determination Guide to determine the reason
for the wait.
- The transaction could be waiting for WebSphere MQ for z/OS
- This could be normal, for example, if your program is a server program
that waits for messages to arrive on a queue. Otherwise it might be the result
of a transaction abend, for example (see Messages do not appear when expected). If this
is the case, the abend is reported in the CSMT log.
- The transaction could be waiting for a remote message
- If you are using distributed queuing, the program might be waiting for
a message that has not yet been delivered from a remote system (for further
information, refer to Problems with missing messages when using distributed queuing).
If you suspect that your program has issued an MQI call that did not involve
an MQGET WAIT (that is, it is in a task switch), and control has
not returned from WebSphere MQ, take an SVC dump of both the CICS region, and
the WebSphere MQ subsystem before cancelling the CICS transaction. Refer to Is WebSphere MQ for z/OS waiting? for
information about waits. Refer to WebSphere MQ dumps (specifically Figure 2) for information about obtaining a dump.
If the problem persists, refer to Finding solutions to similar problems and Working with IBM(R) to solve your problem for
information on reporting the problem to IBM(R).