By definition, suspend time in CICS Transaction Server for z/OS (CICS TS) is the total elapsed time for which the user task was suspended by the dispatcher. This wait time includes the time waiting for the first dispatch, various types of I/O operation, different kinds of resources, redispatch, and any delay incurred because of limits due to CICS parameters like TCLASS and MXT.
CICS provides a breakdown of the transaction suspend (wait) times into separate data fields. You can use these to perform accurate calculations on the various kinds of wait times, for example the total I/O wait time.

Occasionally, the total task suspend time is greater than the sum of the component suspend times. This unaccounted time is identified as ‘uncaptured wait time’ or ‘other Wait Time’. The reason for uncaptured wait time, is CICS does not have a monitoring field – (bucket) for every possible type of suspend. With the dedicated effort of CICS development team, things that can cause ‘uncaptured wait time’ are decreasing. Here are two examples of ‘uncaptured wait time’ that used to be seen a lot in the past, but have been addressed in CICS TS V5:

  • When a connected region is having some sort of slowdown problem, for example the region is at MAXTASK , tasks in the local region often wait in an ALLOCATE type wait, waiting to allocate a session to the connected region. The time spent in an ALLOCATE wait used to have no separate monitoring bucket. Starting from CICS TS V5.1, a new field called TCALWTT is added to the monitoring area that records the time waiting for multiregion operation (MRO) , LU6.1, or LU6.2 session allocation. Therefore, the ALLOCATE wait time is no longer uncaptured.
  • Another example is related to file activities. If a task spent a lot of time waiting on file string or exclusive control of a control interval (CI), you would probably see a high total suspend time but no particular component suspend time stand out. This was because string waits and exclusive control conflicts did not have their own monitoring slot. Again, this is no longer true ever since the release of CICS TS V5. FCVSWTT and FCXCWTT were added to monitor the VSAM string wait and exclusive control wait respectively.

The ‘uncaptured wait time’ is shrinking, but there are still some suspend types without a separate bucket. DISPATCH OPEN_DEL suspend is an example of one of these. DISPATCH OPEN_DEL is related to the processing that is done when CICS is stealing TCBs. If your task is waiting on a resource name of OPEN_DEL, the dispatcher is detaching an unsuitable TCB (stealing) so that it can allocate a new one, and the task is waiting for the old TCB to end so that the dispatcher can attach a new TCB of the required type. Fortunately, TCB stealing is a very rare activity. Actually, in CICS TS V5, the uncaptured wait time in general ought to be a very little portion of the suspend time.

I hope this information gives you a better understanding of the uncaptured wait time in CICS!

2 comments on"Ever wonder why CICS total suspend time is greater than the sum of the component suspend times?"

  1. Great to see the CICS development Lab pushing the envelope. I would like to see a new function to make it simpler and more economical (CPU usage) for our customers to get this SMF data and perform near real time analysis with them! Great job!

Join The Discussion

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.