Is a CICS transaction waiting?

Consider the following points:

CICS 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. We 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 to solve your problem for information on reporting the problem to IBM.