Loops

When a loop is suspected, there are various actions that can be taken.

CPU usage
Usually a loop can be readily found by displaying CPU usage. It is necessary to have some idea of "normal" CPU usage for the suspected address space, for comparison purposes. In general, any address space that uses an unusually high amount of CPU should be suspected.
Paging rates
The paging rates can be monitored to check for any abnormally high rates. Normal usage is again needed for comparison purposes.
Loop recording
The 3090 and 308X CPUs have a hardware facility to record up to 490 PSWs. This facility is activated from the hardware console and can be used to trace a loop. The output is dumped when an SVC or stand-alone dump is taken This information can be helpful when you debug a loop problem. For more information about this facility, consult the documentation for your particular CPU.
Dumps
Usually when a loop is encountered, there is not much that can be done to recover the situation. Usually, a dump must be taken and the system restarted. Dumps can be taken in any of the following ways:
z/OS® DUMP command
If the CPU has several processors, z/OS commands might still be working. If so, then, requesting a dump of the looping address space might be sufficient to obtain a dump.
Restart dump
If the CPU has only a single processor, then a restart dump can be taken.
Stand-alone dump
If neither of the previous dumping methods is appropriate, then a stand-alone dump can be taken. Normally, this option is the last choice as the entire system is taken down, and an IPL is required to recover.

With a multi-processor CPU a loop can appear as degraded performance. For example, if the CPU has four processors and one is processing the loop, this leaves three CPUs for normal processing. This reduction in processing power normally causes some performance degradation. Any users that are associated with the looping address space are normally hung.

Before you contact the IBM® Support Center, try to have the following information available:
  • Looping modules. Try to determine the modules that are involved in the loop by using Failing module.
  • Maintenance level of the modules. Gather this information from SMP/E.
  • Messages. Look for any messages on the console that might have triggered the loop. If one message is being repeatedly issued, include it in the description of the loop.
  • Trace output. Have the output from any traces taken available, together with any information gained from the trace.
  • Dump
  • Console log

Have the following items available in case further diagnosis is required.

VTAM® internal trace: If the VIT is active, this can give some insight into the problem. If the loop causes entries to be written to the VIT, then the trace table is likely to wrap before the operators have determined that VTAM is in a loop. However, if the loop does not cause trace entries to be written, the VIT can be invaluable in determining the event that initiated the loop.