Analyzing the Reports for an MPR Region

The Measurement Session Data report (See the following figure) describes the environment during a measurement session. When Strobe measures a job step executing in an IMS region, the SUBSYSTEM field shows the region type, the version of IMS, and the Local Storage Option (LSO). In this example, the region identifier “MPR” shows that this is a message processing region.

Because both the DLISAS and IMS control regions can own the database datasets, start concurrent measurement sessions in both the IMS control and DLISAS regions to obtain a complete picture of your DASD performance for a dependent region.

Measurement Session Data Report for MPR Regions

Choosing Between the Execution and Wait Reports

When there is intensive database I/O activity or when the dependent region is waiting for work, wait time for a typical IMS application program is relatively high. Nonetheless, execution time may still offer opportunities for improvement, even if it is much smaller than the wait time. To reduce CPU consumption, first determine what is using CPU time by examining the Program Section Usage Summary and the Transaction reports. If most of the time is consumed by application programs, then analyze the Strobe Performance Profile as described in Using-the-Strobe-Application-Performance-Measurement-System. If most of the CPU time is consumed by system service modules, decide on your primary focus. If your focus is on IMS services for DL/I application programs, then analyze the DL/I CPU Summary and CPU Usage by DL/I Request reports. If the focus is on other system service routines, analyze the Attribution of CPU Execution Time reports.

If you want to analyze the wait time, first examine the Wait Time by Module report. If most of the wait time is consumed by system service routines, decide on your primary focus. If your focus is on IMS services for DL/I application programs, then analyze the DL/I Wait Summary and Wait by DL/I Request reports. If your focus is on other system service routines, analyze the Attribution of CPU Execution Time reports.

The Program Section Usage Summary report (See the following figure) shows the activity of each program module and subsystem that was active during the measurement session.

In this example, a high percentage of the CPU time was spent executing IMS system service modules. To reduce CPU usage by IMS services for DL/I application programs, analyze the DL/I CPU Summary and CPU Usage by DL/I Request reports.

Program Section Usage Summary Report for MPR Regions

Identifying CPU Usage in an MPR Region

The DL/I CPU Summary report (See the following figure) identifies the total CPU time by the transaction, module, section, and PSB name that initiated the request for IMS DL/I services.

In this example, more than 56% of the CPU time was spent executing PSB STRIC110 of module STRIC110 and transaction STRID110. The CPU Usage by DL/I Request report for PSB STRIC110 of module STRIC110 and transaction STRID110 will provide detail information for all DL/I requests.

DL/I CPU Summary Report for MPR Regions

The CPU Usage by DL/I Request report provides detail information for each DL/I call and its parameter list within a transaction, module, section, and PSB.

The CPU Usage by DL/I Request report for transaction STRID110, module STRIC110, section STRIC110, and PSB STRIC110 shows that more than 43% of the CPU time for PSB STRIC110 was spent executing a Get Unique (GU) function call at program statement line number 118593, hexadecimal location +235C, reference number 2. If you look at the detail line for reference number 2, you will see that the PCB Type shows a database (DB) retrieval using PCB LON0001 and DBD STRIDLON to retrieve the CUSTROOT and LOANSEGM segments within the STRIDLON database.

CPU Usage by DL/I Request Report for MPR Regions

In this example, Strobe created an index map file for module STRIC110 and used it when creating the Strobe Performance Profile to include the line number and procedure name.

Examine the specified module logic, DL/I call, and its parameter list for the most efficient way to access the database. For example, when you refer to multiple SSAs in one call, include all the SSAs in the path to the segment. Omitting an SSA forces IMS to generate it during the execution of the call.

The following compiler output (See the following figure) shows the DL/I call within the application program that was referenced in the CPU Usage by DL/I Request.

Compiler Output for Module STRIC110

Identifying Wait Time in an MPR Region

The Wait Time by Module report shows all programs and subsystem service routines that were found to be in the wait state. If you specified the WAITLOC parameter when creating the StrobePerformance Profile, then the OFFSET column shows the location of any wait within each module.

In this example, more than 57% of the wait time was spent waiting for work in SVC 239, which is invoked by the IMS internal subsystem interface module DFSISI00. This is typical for MPR regions. No application programs show wait in this module, but the IMS system service modules show wait time that can be assigned to database I/O activity or DL/I call services. To investigate wait time attributed to IMS services for DL/I calls within your application programs, analyze the DL/I Wait Summary and Wait by DL/I Request reports.

Wait Time by Module Report for MPR Regions

The DL/I Wait Summary report (DL/I Wait Summary Report for MPR Regions) identifies the total wait time by transaction, module, section, and PSB name that initiated the request for IMS DL/I services.

In this example, more than 8% of the wait time was spent waiting in PSB STRIC130 of module STRIC130 and transaction STRID130. The Wait by DL/I Request report for PSB STRIC130 of module STRIC130 and transaction STRID130 provides detail information on all DL/I requests.

DL/I Wait Summary Report for MPR Regions

The Wait by DL/I Request report provides detail information for each DL/I call and its parameter list within a transaction, module, section, and PSB.

The Wait by DL/I Request report for transaction STRID130, module STRIC130, and PSB STRIC130 shows that more than 7% of the time waiting in PSB STRIC130 was for a Get Unique (GU) function call at program location hexadecimal +1E0C, and the reference number is 2. If you look at the detail line for reference number 2, you will see that the PCB Type shows a database (DB) retrieval using PCB CUSPCB and DBD STRIDCUS to retrieve an entry from the CUSTROOT’s CHCKSEGM segment within the STRIDCUS database.

Examine the DL/I call, its parameter list, and the database hierarchy to determine the most efficient way to access the database to eliminate data structure conflicts. For example, you could create a secondary index so that the application program can access a particular segment by a field that is not the segment’s key.

Wait by DL/I Request Report for MPR Regions

Identifying CPU Usage by Transaction in an MPR Region

Transaction reports show activity in the following three ways:

• By transaction identifier or Fast Path routing code
• Within each transaction, by module and control section
• By transaction across regions.

The Transaction Summary report shows the distribution of CPU time among transactions that were active during the measurement session. It also shows the number of times a transaction was executed during the measurement session, as well as the average service time of the transaction. For a list of items to consider when interpreting this information, see .

In this example, transaction STRID110 was executed over 1,000 times and used over 90% of the CPU time consumed by the application program. The Transaction Usage by Control Section report for STRID110 provides a detailed breakdown of this activity.

Transaction Summary Report for MPR Regions

The Transaction Usage by Control Section report shows, for each transaction that was active during the measurement session, the CPU time spent in each control section within each active module. The Transaction Usage by Control Section report for transaction STRID110 shows that most of the CPU time was used by the pseudo-module .IMS, with modules DFSDLA00 and DFSDLR00, each accounting for more than 11% of the CPU time. The Attribution of CPU Execution Time reports for these modules provide information about the transactions that invoked these system routines.

Transaction Usage by Control Section Report for MPR Regions

The Transaction Utilization Report Summary - #TRS (Sample Transaction Utilization Report Summary - #TRS) displays transaction counts and transaction times, ordered by transaction and IMS region, for all regions within the measured IMS subsystem. This report provides the ability to examine average transaction times across regions, grouping transactions by region in a measured subsystem, and provides a quick performance comparison. Unexpected averages are easily identified as displayed in Transaction PART, Region IMSDMR09. If greater granularity is required, the Transaction Utilization Report provides additional timings for DL/I activity grouped by transaction within region.

Sample Transaction Utilization Report Summary - #TRS

The Transaction Utilization Report - #TUR details the IMS activity, attributed to DL/I call statements, for transactions within a region. For each transaction by region the report provides transaction counts, module name, PSB name, transaction abend counts, and DL/I call activity. The max, min, and average are provided for execution, database IO, lock, and zIIP times. The #TUR report provides additional capability to resolve concerns for the region timing differences or other related questions by providing detailed transaction/region data. Refer to DL/I activity for transaction PART within region IMSDMR09.

Sample Transaction Utilization Report - #TUR

Analyzing Service Time and Transaction Counts

This section describes the considerations for interpreting the service time and transaction count information that may appear on the Transaction Summary report.

General Considerations

The following considerations apply to both the measuring of service time and the collection of transaction counts:

• Strobe does not collect service times and transaction counts in IFP regions.
• Strobe does not collect service times and transaction counts until sampling has begun.

Considerations for Service Time

For IMS regions, service time is the elapsed time between the end of the successful Get Unique to the IOPCB and the end of the last DL/I call. Therefore, the “Scheduling End to First Call” entry on the IMS monitor “Programs by Region” report is not included as service time. Also, the elapsed time from the end of the last call to the program return for that transaction is not included as service time.

Strobe stops collecting service time for a transaction when the measurement session ends. If a transaction has not issued another Get Unique to IOPCB when the measurement session ends, the reported service time for the transaction may be less than the actual service time for that occurrence of the transaction.

Strobe reports service time rounded to the nearest hundredth of a second. However, the IMS Monitor reports service time in units of .000001 seconds. For comparison of Strobe values with IMS Monitor Programs by Region report values, the Strobe value should be comparable to Elapsed Execution Time - Mean value.

Considerations for Transaction Counts

If a transaction is already in process when sampling begins (that is, the Get Unique to IOPCB has already occurred), the transaction is not included in transaction counts and service times.

Attribution of CPU Execution Time

The Attribution reports for modules DFSDLA00 and DFSDLR00 (Attribution of CPU Execution Time Reports for MPR Regions) show that execution is concentrated in one or two DL/I calls. Examine these routines and determine what they do within the IMS system and whether they are being called efficiently. For a description of this report, see The Attribution of CPU Execution Time Report for IMS Environments.

To investigate CPU time attributed to these modules from the DL/I calls within the application program, analyze the DL/I CPU Summary and CPU Usage by DL/I Request reports.

Attribution of CPU Execution Time Reports for MPR Regions

Attribution of CPU Wait Time

The Attribution of CPU Wait Time report for pseudo-module .IMS (Attribution of CPU Wait Time Report for MPR Regions) shows that in transaction STRID130, the DL/I service call at +1E0C is responsible for more than 6% of the total wait time. To investigate wait time attributed to this module from the DL/I call within the application program, analyze the DL/I Wait Summary and Wait by DL/I Request reports.

Attribution of CPU Wait Time Report for MPR Regions