Identifying the loop

To identify loops in user programs, you can look in the transaction dump or you can use the trace table.

• To identify a loop by using the transaction dump, use the following steps:
  1. Find the program status word (PSW), and see whether it points into your program.
     This is likely to be the case if you have a tight loop, and it should lead you to an instruction within the loop.
  2. Use the module index at the end of the formatted dump to find the module name of the next instruction.
     If the instruction address is not in your code, it is less useful for locating the loop. However, try to identify the module that contains the instruction, because it is probably the one that was called during the execution of a CICS® request made within the loop. If the PSW address is not contained in one of these areas, another program was probably executing on behalf of CICS when the runaway task timer expired.

     Note: It is possible that the loop is in a module owned by CICS or another product, and your program is not responsible for it. If the loop is in CICS code, contact the IBM® Support Center.
  3. If the PSW points to a module outside your application program, find the address of the return point in your program from the contents of register 14 in the appropriate register save area.
     The return address will lie within the loop, if the loop is not confined to system code.
  4. When you have located a point within the loop, work through the source code and try to find the limits of the loop.
• To identify a loop by using the trace table, use the following steps:
  1. Go to the last entry in the internal trace table, and work backwards until you get to an entry for point ID AP 1942.
     The trace entry should have been made when recovery was entered after the transaction abended AICA.
  2. Make a note of the task number, so you can check that any other trace entries you read relate to the same abended task.
  3. Look at the entries preceding AP 1942. In particular, look for trace entries with the point ID AP 00E1.
     These entries should have been made either just before the loop was entered (for a tight loop), or within the loop itself (for a non-yielding loop). Entries with a point ID of AP 00E1 are made on entry to the EXEC interface program (DFHEIP) whenever your program issues an EXEC CICS command, and again on exit from the EXEC interface program. Field B gives you the value of EIBFN, which identifies the specific command that was issued.
  4. When you have identified the value of EIBFN, use the function code list in Function codes of EXEC CICS commands to identify the command that was issued.
  5. For trace entries made on exit from DFHEIP, field A gives you the response code from the request. Look carefully at any response codes - they could provide the clue to the loop.
     Has the program been designed to deal with every possible response from DFHEIP? Could the response code you see explain the loop?
  If you see a repeating pattern of trace points for AP 00E1, you have a non-yielding loop. If you can match the repeating pattern to statements in the source code for your program, you have identified the limits of the loop.

  If you see no repeating pattern of trace points for AP 00E1, it is likely that you have a tight loop. The last entry for AP 00E1 (if there is one) should have been made from a point just before the program entered the loop. You might be able to recognize the point in the program where the request was made, by matching trace entries with the source code of the program.