Dealing with loops on z/OS
Loops can occur in different areas of a z/OSĀ® system. Use this topic to help determine where a loop is occurring.
The following topics describe the various types of loop that you might encounter, and suggest some responses.
Is a batch application looping?
If you suspect that a batch or TSO application is looping, use the console to issue the z/OS command DISPLAY JOBS,A (for a batch application) or DISPLAY TS,A (for a TSO application). Note the CT values from the data displayed, and repeat the command.
If any task shows a significant increase in the CT value, it might be that the task is looping. You could also use SDSF DA, which shows you the percentage of processor that each address space is using.
Is a batch job producing a large amount of output?
An example of this behavior might be an application that browses a queue and prints the messages. If the browse operation has been started with BROWSE FIRST, and subsequent calls have not been reset to BROWSE NEXT, the application browses, and prints the first message on the queue repeatedly.
We can use SDSF DA to look at the output of running jobs if you suspect that it might be causing a problem.
Does a CICS region show heavy processor activity?
It might be that a CICSĀ® application is looping, or that the CICS region itself is in a loop. You might see AICA abends if a transaction goes into a tight (unyielding) loop.
If you suspect that CICS, or a CICS application is looping, see the CICS Problem Determination Guide.
Does an IMS region show heavy processor activity?
It might be that an IMS application is looping. If you suspect this behavior, see IMS Diagnosis Guide and Reference l.
Is the queue manager showing heavy processor activity?
Try to enter an MQSC DISPLAY command from the console. If you get no response, it is possible that the queue manager is looping. Follow the procedure shown in Has our application or IBM MQ for z/OS stopped processing work? to display information about the processor time being used by the queue manager. If this command indicates that the queue manager is in a loop, take a memory dump, cancel the queue manager and restart.
If the problem persists, see Searching the IBM database for similar problems, and solutions and Contacting IBM Software Support for information about reporting the problem to IBM.
Is a queue, page set, or Coupling Facility structure filling up unexpectedly?
If so, it might indicate that an application is looping, and putting messages on to a queue. (It might be a batch, CICS, or TSO application.)
- Identifying a looping application
-
In a busy system, it might be difficult to identify which application is causing the problem. If you keep a cross-reference of applications to queues, terminate any programs or transactions that might be putting messages on to the queue. Investigate these programs or transactions before using them again. (The most likely culprits are new, or changed applications; check your change log to identify them.)
Try issuing a DISPLAY QSTATUS command on the queue. This command returns information about the queue that might help to identify which application is looping.
- Incorrect triggering definitions
- It might be that a getting application has not been triggered because of incorrect object definitions, for example, the queue might be set to NOTRIGGER.
- Distributed queuing
- Using distributed queuing, a symptom of this problem might be a message in the receiving system indicating that MQPUT calls to the dead-letter queue are failing. This problem might be caused because the dead-letter queue has also filled up. The dead-letter queue message header (dead-letter header structure) contains a reason or feedback code explaining why the message might not be put on to the target queue. See MQDLH - Dead-letter header for information about the dead-letter header structure.
- Allocation of queues to page sets
- If a particular page set frequently fills up, there might be a problem with the allocation of queues to page sets. See IBM MQ for z/OS performance constraints for more information.
- Shared queues
- Is the Coupling Facility structure full? The z/OS command DISPLAY CF displays information about Coupling Facility storage including the total amount, the total in use, and the total free control and non-control storage. The RMF Coupling Facility Usage Summary Report provides a more permanent copy of this information.
Are a task, and IBM MQ for z/OS, showing heavy processor activity?
In this case, a task might be looping on MQI calls (for example, browsing the same message repeatedly).