Input queuing and scheduling/termination in DB/DC and DCCTL environments
Another set of performance problems is brought about by failure to achieve the performance objectives. The problem might be observed by input queue buildup caused by either increased workload or application program scheduling delays.
Dynamic monitoring
This topic explains how to obtain dynamic monitoring information for IMS™ input queuing, IMS region occupancy, IMS scheduling, and sync point processing.
- IMS input queuing
- Input queue time is not available. However, using the IMS /DISPLAY command with the QUEUE parameter, you can monitor the sizes of the input queues. You can also use the ACTIVE parameter to track performance and detect bottlenecks in scheduling and in the region occupancy area.
- IMS region occupancy
- Not available in any dynamic report. The IMS command /DISPLAY ACTIVE is used to monitor region usage.
- IMS scheduling
- The PSB and DMB Pools should already be tuned, as recommended
in Initializing z/OS and IMS parameters for tuning.
If all regions are busy, start any necessary additional regions. If
some regions are idle, modify classes or PARLIM if one transaction
is overloading a region.
Related reading: For more information, see Avoiding contention for IMS resources (excluding buffer pools).
- Sync point processing
- The occurrences of problems caused by waiting for synchronization points cannot be isolated dynamically.
Daily monitoring
This topic explains how to obtain daily monitoring information for transaction response times, response time breakdown, region occupancy, program scheduling, and sync point processing at program termination.
- Transaction response times
- Extract total (internal) response times for selected transactions
that can be used as indicators of system performance.
Related reading: For more information on sources of response time data, see Establishing performance objectives.
- Response time breakdown
- For similar transactions, extract response time breakdown (input queue, switch queue, processing, output queue) from IMS PA or DFSILTA0.
- Region occupancy
- You can obtain indications of the relative use of the dependent regions in a DB/DC environment by using the IMS PA Resource Availability Reports. Also, you can directly use the summary of region occupancy percentages given in the IMS Monitor Region Summary report.
- Program scheduling
- If the response-time breakdown data indicates large and variable
input queue times, check the Region Occupancy figures. If all message
regions have high occupancy, then another message region might be
required. Alternatively, it might be possible to reduce occupancy
by reducing program load or program execution times. If some or all
of the IMS message regions are
not busy, analysis of IMS PA
Transaction Transit reports by transaction and class probably shows
that one transaction or class is more critically hit than others.
In this case, you should review the designation of classes and the
allocation of classes to regions. PROCLIM and PARLIM should be reviewed
also.
Related reading: For information on scheduling options, see Choosing IMS options for performance.
Programs executing as wait-for-input never show 100% occupancy even when they are in the region 100% of the time. Zero occupancy might be cause to review operator procedures, with instructions to manage the number of message regions based upon display of the queues.
The IMS PA Transaction Transit reports Graphic Summary is useful to analyze input queuing time by time of input across the entire measurement period. This can be used to discover if high input queue times result from a transient peak in transaction volumes or from a more sustained phenomenon. DFSILTA0 can be used for the same purpose, although its output is numeric rather than graphic.
- Sync point processing at program termination
- If you are using IMS PA to provide response-time breakdown data, a high program switch queue time can indicate that delays are occurring because of a wait-for-synchronization point completion. This occurs if MODE=MULT is used. Check the IMS PA CPU Usage report for multiple transactions of that type being dequeued per program schedule. As a general rule, use MODE=SNGL to avoid any delays of this type.
Detailed monitoring
You should examine detailed monitoring information for scheduling and sync point processing.
- Scheduling
- The IMS Monitor generates reports on PSB and DMB I/O counts and elapsed times. GTFPARS Job Summary and Detail Trace reports for the IMS control region can also be used for detailed investigation of these I/O events. However, scheduling problems are more often related to region availability and message class, PROCLIM, and region class assignments. These are described in Avoiding contention for IMS resources (excluding buffer pools).
- Sync point processing
- Delays caused by waiting for a synchronization point do not normally require detailed investigation.