DLI

Unless your task is waiting on resource type DLI, with resource name IWAIT, it can be difficult to gather online evidence that the task is waiting for a DL/I-related resource. However, you might suspect this from your knowledge of the transaction.

The waiting task might be in a local CICS region or in a remote CICS region, but the possible causes of DL/I waits are the same in either case.

These are the potential reasons why a task might be waiting:

Tasks might be contending for PSB scheduling.
There might be no DL thread available.
The task might have issued a termination call while some other task was doing PSB scheduling.
There might be insufficient storage in the PSB pool.
There might be insufficient storage in the DMB pool.
Tasks might be contending for PCBs, when concurrent use is not allowed.

To find which of these is the reason for the wait, you need to analyze the dump taken while the task was in a wait state. First format the dump to give you the XM and dispatcher summaries and the DL/I information. Determine the ECB for the wait from the dispatcher summary. Then determine the address of the IMS module that issued the wait. This address is located in register 14 of the IMS save area passed to the IWAIT routine in DFHDLR.

If you can reproduce the wait with tracing active, you can use the trace, with a dump, to find the same information.

Investigating DL/I waits using dump and trace

The technique described in this section enables you to find which DL/I resource your task is waiting on. You need to select some appropriate tracing options and then reproduce the problem. You probably need to re-create the conditions that existed when the problem first appeared, for example in your production system when the transaction throughput has reached a certain level. This is because the problem is more likely to occur when competition between tasks for resources becomes significant.

Use the transaction CETR to select level-1 trace points for component FC (file control) for special tracing. For guidance about using the CETR transaction, see "Using traces in problem determination" in your CICS Problem Determination Guide. Make sure that no other special trace points have been defined. Next, use CETR to select special tracing for a task that you know is affected by the problem. Direct trace output to the auxiliary trace destination only (to minimize overhead), and set the master system trace flag off to prevent any standard task tracing.

Start tracing, and keep invoking the task that experiences the problem until it enters a wait state. Now stop tracing, and force a CICS system dump using CEMT PERFORM SNAP. If the task is waiting for the same DL/I resource as when you first observed the problem, you should have all the evidence you need to find the cause. You can do all the rest of the investigation offline.