Investigating loops that are not detected by CICS

You probably suspect that you have a loop through circumstantial evidence, and CICS® has failed to detect it. You might, for example, see some sort of repetitive output, or statistics might show an excessive number of I/O operations or requests for storage. These types of symptom can indicate that you have a yielding loop.

About this task

The nature of the symptoms might indicate which transaction is involved, but you probably need to use trace to define the limits of the loop. Use auxiliary trace to capture the trace entries, to ensure that the entire loop is captured in the trace data. If you use internal trace, there is a danger that wraparound will prevent you from seeing the whole loop.

Procedure

  1. Use the CETR transaction to set up the following tracing options.
    You can use the transaction dynamically, on the running CICS system. For guidance about using the CETR transaction, see Using CICS trace.
    1. Select level-1 special tracing for every component. You need to capture as much trace information for the task as possible, because you do not yet know what functions are involved in the loop.
    2. Set all standard tracing off, by setting the main system trace flag off.
    3. Select special tracing for just the task containing the loop.
    4. Set the auxiliary tracing status to STARTED, and the auxiliary switch status to ALL.
      As CETR allows you to control trace dynamically, you do not need to start tracing until the task is running and the symptoms of looping appear.
    These steps ensure that you get all level-1 trace points traced for just the task you suspect of looping, the trace entries being sent to the auxiliary trace destination.
  2. When you have captured the trace data, you need to purge the looping task from the system.
    1. Use the CEMT INQ TASK command to find the number of the task.
    2. Purge the task using either the CEMT SET TASK PURGE or the CEMT SET TASK FORCEPURGE command.
      Note: The use of FORCEPURGE is, in general, not recommended, because it can cause unpredictable system problems. For example, it causes task storage areas to be released, including I/O areas, without notifying any components that might be accessing them. If the FORCEPURGEd task was waiting for input, such an area might be written to after it is released. The storage might even be in use by another task when the input occurs.
    This causes the transaction to abend, and to produce a transaction dump of the task storage areas.
  3. In addition to the auxiliary trace data and the transaction dump, get the source listings of all the programs in the transaction.

Results

The trace data and the program listings should enable you to identify the limits of the loop. You need the transaction dump to examine the user storage for the program. The data you find there could provide the evidence you need to explain why the loop occurred.