Loops

A loop is the repeated execution of some code. If you have not planned the loop, or if you have designed it into your application but for some reason it fails to terminate, you get a set of symptoms that vary depending on what the code is doing. In some cases, a loop may at first be diagnosed as a wait or a performance problem, because the looping task competes for system resources with other tasks that are not involved in the loop.

The following are some characteristic symptoms of loops:
  • The ‘system busy’ symbol is permanently displayed in the operator information area of a display unit, or stays displayed for long periods.
  • The transaction abends with abend code AICA.
  • CPU usage is very high, perhaps approaching 100%, yet some tasks stay suspended or ready, but not running, for a long time.

    You can check what the CPU usage is for any MVS job by using the DISPLAY ACTIVE command at the MVS console to display the active users.

  • There is reduced activity at terminals, or possibly no activity at all.
  • One or more CICS® regions appear to be stalled, or to be continuing only slowly.
  • No CICS messages are written to any destination, when they are expected.
  • No new tasks can be started.
  • Existing tasks remain suspended.
  • The CEMT transaction cannot be used.
  • Repetitive output obtained. Try looking in these areas:
    • Terminals, and the system console.
    • Temporary storage queues. You can use CEBR to browse them online.
    • Data files and CICS journals.
    • Trace tables, but remember that some loops are intentional—some CICS system tasks use them, for example, to see if there is any work to be done.
  • Excessive demand for storage. If the loop contains a GETMAIN request, storage is acquired each time this point in the loop is passed, as long as sufficient storage to satisfy the request remains available. If storage is not also freed in the loop, CICS eventually goes short on storage (SOS) in one of the DSAs. You then get a message reporting that CICS is under stress in one of these areas.

    One further effect is that tasks issuing unconditional GETMAIN requests are suspended more often as the loop continues and storage is progressively used up. Tasks making storage requests do not need to be in the loop to be affected in this way.

  • Statistics show a large number of automatically initiated tasks.
  • Large numbers of file accesses are shown for an individual task.

Some loops can be made to give some sort of repetitive output. Waits and performance problems never give repetitive output. If the loop produces no output, a repeating pattern can sometimes be obtained by using trace. A procedure for doing this is described in Dealing with loops.

If you are able to use the CEMT transaction, try issuing CEMT INQ TASK repeatedly. If the same transaction is shown to be running each time, this is a further indication that the task is looping. However, note that the CEMT transaction is always running when you use it to inquire on tasks.

If different transactions are seen to be running, this could still indicate a loop, but one that involves more than just a single transaction.

If you are unable to use the CEMT transaction, it may be because a task is looping and not allowing CICS to regain control. A procedure for investigating this type of situation is described in What to do if CICS has stalled.

Consider the evidence you have so far. Does it indicate a loop? If so, turn to Dealing with loops, where there are procedures for defining the limits of the loop.