Unplanned loops can be divided into those that can be detected by CICS, and those that cannot. Below is IBM’s diagram showing the different types of loops.
Unplanned loops | ___________________|_____________________ | | Detectable by CICS Not detectable by CICS | | ________|________ | | | | Tight loops Non-yielding loops Yielding loops
Loops That CICS Can Detect
CICS can detect some looping tasks by comparing the length of time the tasks have been running with the runaway time interval. If a task runs for longer than the interval specified, CICS regards it as “runaway” and causes it to abend with an abend code of AICA.
A default runaway time interval is set with the ICVR parameter in the System Initialization Table (SIT). The default value, if unspecified, is 5 seconds. Transactions defined with PCT definitions containing RUNAWAY=SYSTEM use this system default value. The RUNAWAY parameter in the PCT definition can be set to an alternative value for that transaction.
Tight loops and non-yielding loops are both characterized by the fact that the looping task can never be suspended within the limits of the loop. This makes them detectable by CICS, which compares the time they have been running continually with the runaway time interval.
A tight loop is one involving a single program, where the same instructions are executed repeatedly and control is never returned to CICS.
A non-yielding loop is also contained in a single program, but it differs from a tight loop in that control is returned temporarily from the program to CICS. However, the CICS routines that are invoked are ones that do not cause the program to become suspended, so the runaway timer is not reset.
The CICS commands that normally do not cause tasks to become suspended include (but are not restricted to) ASKTIME, DEQ, ENQ, ENTER TRACENUM, FREEMAIN, HANDLE, RELEASE, and TRACE ON/OFF. Whether a command allows the runaway timer to be reset might also depend on other factors. For instance, a FREEMAIN might reset the runaway timer if the storage lock is held. A READ normally causes the program to become suspended, resetting the runaway timer, but it might not reset the timer if the desired record is already in a VSAM buffer. A complete list of such anomalies is not documented in CICS manuals.
The transaction dump resulting from an AICA abend should be sufficient to find the instruction executing at the time of abend, which would certainly be contained within the loop.
Loops That CICS Cannot Detect
In most cases, CICS requests that are contained in the looping code cause the timer to be reset. If the looping code contains a request that does cause the timer to be reset, CICS cannot detect that it is looping. Such loops are referred to as yielding loops.Yielding loops typically involve a number of programs. The programs might be linked to and returned from, or control might be transferred from one program to another in the loop. A yielding loop can also be confined to just one program, in which case it must contain at least one wait-enabling CICS command.
A yielding loop can only be detected by circumstantial evidence such as excessive run time, user complaint, or excessive use of processor. If detected in time, such tasks can be purged using CEMT. If left running too long, some CICS resources may be depleted, resulting in CICS being nonresponsive. In this case, the looping transaction is being suspended, so it will never be abended with an AICA, but CICS lacks the resources to allow new transactions to be started to purge the transaction.
Canceling CICS with a dump should result in a region dump that can be viewed with IPCS to determine what transactions were active at the time. Reviewing the storage associated with active transactions may give clues as to which program was looping and why.
Much of the information in this posting came directly from the CICS Problem Determination Guide. Information regarding the ICVR parameter can be found in the CICS System Definition Guide. The rest is personal experience and observations.