Help

 

IMS Application Performance Analysis

To analyze the performance of an IMS application, determine whether user code or IMS task wait is consuming the most CPU:

  • Examine the Program CPU Use report to see whether .USER consumes the most CPU. If so, see the suggestions for examining source code in the general application performance analysis topic. (For an IMS Message Processing Region, use the Transaction CPU Use report to determine and examine the function-specific transactions that used the most CPU.)

  • If .SYSTEM consumes significant CPU, expand it to see more detail. If you see significant CPU use in .IMS, examine DL/I calls. If you do not, see other suggestions in the general application performance analysis topic.

Unless the Measurement Statistics in the Measurement Session Data report show all of the time in CPU or all of the time in wait (all = 99%), both areas may provide IMS performance improvement opportunities. In an IMS Message Processing Region environment, small changes can have significant total resource consumption implications, because the savings can be multiplied by the number of times per day a transaction executes. So for high volume transactions, you will want to examine smaller resource consumers.

Examining DL/I Calls

If the Activity by DL/I Request shows significant activity in individual DL/I calls, examine the application code to minimize unnecessary calls, make sure call patterns are appropriate, and ensure that calls are efficient as possible.

If there is significant CPU use by the DL/I database modules, DFSDLxxx, the IMS DB or DC monitor, IMS call trace, check the Attribution of CPU Execution Time report for IMS calling patterns. Doing so will often reveal calls that you can eliminate, such as re-reading the same segment many times, or always doing a retrieve before an insert even though the segment usually does not exist.

A high percentage of CPU use by IMS modules does not necessarily indicate a problem. If the main purpose of the job or transaction is to retrieve many IMS segments and do little processing against those segments, then IMS will be doing most of the work and use most of the CPU.

Examining IMS Task Wait

Examine the Resource Demand Distribution report:

  • If the IMS task shows the value CPU in the Resource column, look at the Wait Time by Module report.

  • If you see high wait within IMS system services, look at the Activity by DL/I Request report to determine which DL/I calls caused wait.

  • Look at the Attribution of CPU Wait Time report to determine which DL/I request invoked which IMS system, or was a cause of wait within an IMS system.

High amounts of wait to a user SVC is often the IMS SVC. In an IMS Message Processing Region, module DFSRRC10 (the MPP Region Controller) is linked in with module DFSRRC00 (the IMS Region Controller). The IMS Region Controller is a parent task which is waiting for the daughter task (DFSPCC20) to abend or terminate. While it is waiting, there may be much useful work going on in the daughter task.

In an IMS Batch environment, module DFSKBDP0, the IMS Batch Dispatcher, can also show a high amount of wait which is really happening while other work is being accomplished. Use the Activity by DL/I Request report to determine where within the application wait was invoked.

If the Resource Demand Distribution report shows high wait to STEPLIB, examine the Wait Time by Module report to see if the BLDL, Load, and Link SVCs are used. To reduce their CPU use, try using IMS preload, virtual fetch, LLA, OEM, module management software, and the IMS BLDL list. You can also reduce load time by ensuring that the libraries most often accessed occur first in concatenations for the STEPLIB and other file DSN lists. While these considerations are most important in an IMS Message Processing Region, they can also apply to some IMS Batch and BMP jobs.