Is the problem caused by a loop?
A loop exists when a section of code runs repeatedly. If the loop is not planned, or the loop is designed into an application but cannot terminate, the symptoms vary depending on what the code does. Loops can appear similar to a wait or a performance problem because the looping task competes for system resources with other tasks that are not involved in the loop.
- CPU usage is very high, perhaps approaching 100%, yet some tasks spend a long time suspended or ready, but not running. See CICS has stalled during a run for more information about checking CPU usage.
- There is less activity at terminals, or possibly no activity at all.
- One or more CICS® regions appear to be stalled or running only slowly.
- CICS is not writing messages to any destination when you expect them.
- You might obtain repetitive output. Try looking in one of these
areas:
- Terminals
- Temporary storage queues (use CEBR to browse these online)
- Data files and CICS journals.
- A task demands excessive storage. If the loop contains an EXEC CICS GETMAIN SHARED request, CICS acquires storage each time the task passes this point in the loop, as long as enough storage to satisfy the request remains available. If the task does not also release storage with an EXEC CICS FREEMAIN in the loop, CICS eventually becomes short on storage (SOS). You then receive a message reporting that CICS is under stress. If no GETMAIN SHARED storage exists, CICS raises a condition on the offending program.
- Statistics show many initiated tasks.
- Statistics show many file accesses for an individual task.
You might be able to distinguish a loop from a wait or a performance problem by making the loop produce repetitive output. Waits and performance problems never give repetitive output. If the loop produces no output, trace might show a repeating pattern. If you have enough information to classify the problem as a loop, you need to define the limits of the loop. See Dealing with loops for further advice.