Overview of the Strobe Performance Profile for IMS/ESA

The Strobe Performance Profile for an IMS region contains all the reports described in the Using-the-Strobe-Application-Performance-Measurement-System. If you are measuring a CICS/DBCTL region, your Strobe Performance Profile also contains the CICS Performance Supplement, described in Strobe-for-CICS.

The Profiles for measurements of BMPs and DLBs do not contain the Transaction Summary and the Transaction Usage by Control Section, as these regions are not transaction oriented.

Strobe for IMS adds IMS-specific information to the standard Strobe Performance Profile by identifying modules and transactions, and by tailoring the Attribution of CPU Execution and Attribution of CPU Wait Time reports, as described below.

Region identifiers

Strobe for IMS identifies the measured region type with the following three-character abbreviations in the Measurement Session Data report:

The SUBSYSTEM field also shows the Local Storage Option (LSO) for the region, which controls the placement of DL/I modules, control blocks, and buffers in your IMS system. The identified LSO options are

Module and transaction identification in an IMS DB/DC environment

The following subsections describe how Strobe identifies modules and transactions in an IMS DB/DC environment.

Load Module Identification

Strobe for IMS assigns activity and wait within IMS system modules to two pseudo-sections within the pseudo-module .SYSTEM, namely .IMS for activity in load modules beginning with DFS or DBF, and .IRLM for activity in load modules beginning with DXR. The true module name appears as a procedure within .IMS or .IRLM. Strobe for IMS also provides function descriptors for the IMS system modules.

To obtain detailed reporting by offset within an IMS system module, specify its name with the DETAIL parameter when you create the Strobe Performance Profile. For a detailed explanation of reporting options, refer to the Using-Strobe-to-measure-online-applications-and-batch-programs.

Transaction identification for IMS dependent regions

Strobe identifies CPU activity and wait in IMS regions that execute DL/I applications by using transaction names and routing codes defined to the IMSGEN through the TRANSACT and RTCODE macros.

Transaction identification for IMS system regions

Strobe for IMS uses a Strobe-generated pseudo-transaction name to identify activity and wait in IMS system tasks in the control and DL/I regions. Strobe for IMS dynamically creates a pseudo-transaction name based upon the following:

• Function of the IMS task
• Active IMS system module within the task.

The pseudo-transaction is composed of two elements, separated by a slash (/):

1. A three-character IMS task functional identifier
2. Characters four through seven from the name of the active IMS system module.

The task identifier implies the nature of the service the task provides to the IMS Control or DL/I region. Because many IMS modules may participate in the execution of a given IMS task, there is a wide variety of IMS pseudo-transactions.

Common three-character functional identifiers for the IMS tasks that appear in pseudo-transaction names created by Strobe for IMS are:

Module and transaction identification in a CICS/DBCTL environment

Strobe for CICS identifies all CICS system and application modules.

For CICS/DBCTL transactions, Strobe describes observed DBCTL thread activity by using the four-character CICS transaction code associated with the DL/I application.

Other Pseudo-Names

If Strobe or Strobe for IMS cannot identify an active IMS or MVS module, Strobe assigns activity related to the module to a pseudo-section name chosen according to the virtual storage location of the activity within the measured address space. For more information on pseudo-names, refer to the Using-the-Strobe-Application-Performance-Measurement-System.

The DL/I Request CPU Time and Wait reports

DL/I system service modules are executing or waiting whenever an application program has issued a DL/I service request. Similarly, in a CICS environment, the DBCTL Resource Manager Interface and DL/I system service modules are executing or waiting whenever an application program within a CICS transaction has issued a DL/I service request.

The Strobe DL/I Request reports allow the application programmer and the database administrator to use the Strobe Performance Profile reports to identify not only the DL/I service call, but also the components of the DL/I parameter list. This parameter list contains data from the application program and supplies information about the call.

DL/I CPU and Wait Summary reports

The DL/I CPU and Wait Summary reports identify the total CPU or wait time by the transaction, module, section, and PSB name that initiated the DL/I activity.

The DL/I CPU Summary report summarizes all observed DL/I processing by transaction, module, section, and PSB name.

The DL/I Wait Summary report summarizes all observed DL/I wait by transaction, module, section, and PSB name.

In both reports, columns provide the following information:

• Transaction identifies a transaction.
• Module identifies a module that issued the DL/I call.
• Section identifies a control section that issued the DL/I call.
• PSB identifies the Program Specification Block (PSB).
• Execution count identifies how many times the DL/I call executed.
• Average Service Time identifies the average service time, in seconds, for the DL/I call. Service time represents the time the transaction is being processed or awaiting processing within the region.
• Solo CPU or Wait Time Percent reports the percentage of time spent executing or waiting on the given DL/I request, without any concurrent I/O activity.
• Total CPU or Wait Time Percent reports the percentage of time spent executing or waiting on the given DL/I request, with or without any concurrent I/O activity.
• Histogram for CPU or Wait Time Percent graphically displays the percentage of time spent executing or waiting on the given DL/I request. Solo time is indicated by the asterisk (*). The remaining overlapped time is indicated by the plus-sign (+).
• The last line presents total solo and total time for the transaction, module, section, and PSB.

When DL/I application programs are not active, Strobe assigns CPU and wait time to IMS system modules. For example, IMS system modules DFSPCC20 and DFSISI00 support region initialization and termination. Since no application programs can be active during these procedures, Strobe assigns the CPU and wait activity to the IMS system module that invoked DFSPCC20 or DFSISI00.

The following figure shows a sample DL/I CPU Summary report. Sample DL/I Wait Summary Report shows a sample DL/I Wait Summary report.

Sample DL/I CPU Summary Report

Sample DL/I Wait Summary Report

CPU Usage and Wait by DL/I Request

The CPU Usage and Wait by DL/I Request reports show the IMS activity that can be directly attributed to a DL/I call statement within a transaction, module, section, and PSB name.

The CPU Usage by DL/I Request report presents a detailed listing of all identified DL/I activity by DL/I call statement.

The Wait by DL/I Request report presents a detailed listing of all identified DL/I wait by DL/I call statement.

The first four lines identify the transaction, module, section, and PSB name where the DL/I requests reside. In the Call Parameters section, each DL/I request has one or more lines containing the following:

• Reference Number refers to one or more DL/I request detail lines in the bottom half of the report.
• PCB Type identifies the Program Communication Block (PCB) being used as either I/O, DATABASE (DB), or ALTERNATE (ALT).
• PCB Name or Label identifies the PCB referenced in the DL/I service request.
• Resource Name identifies an IMS resource used to execute the DL/I function. For DATABASE PCBs, the resource is the Data Base Description (DBD) name. For ALTERNATE PCBs the resource is MODIFY (for a modifiable alternate PCB), the fixed destination name (for a non-modifiable alternate PCB), or blank (for I/O PCBs).
• DL/I Func identifies the DL/I service being requested.
• SSA Data (Segment Search Argument Data) names the database segments to process, and defines the selection criteria DL/I uses for the call. The SSA consists of the segment name, optionally followed by a command code, field name specification, relational operator, and a question mark to indicate the presence of variable data. Note that the SSA context does not show extraneous null command codes and shows the SSA only up to the first key field value, represented by ????.

The Function Activity section of the report provides one or more detail lines for each of the DL/I requests shown in the Call Parameters section. Each detail line consists of the following:

• Line No. identifies the DL/I request source line number within the application program.
• Procedure Name identifies the DL/I request within the application program.
• Request Location identifies, by hexadecimal offset, the DL/I request location within the application program.
• Reference Number refers to a specific DL/I request in the upper half of the report.
• Execution count identifies how many times the DL/I call executed.
• Average Service Time identifies the average service time, in seconds, for the transaction. Service time represents the time the transaction is being processed or awaiting processing within the region.
• Solo CPU Wait Time Percent reports the percentage of time spent executing or waiting on the given DL/I request, without any concurrent I/O activity.
• Total CPU or Wait Time Percent reports the percentage of time spent executing or waiting on the given DL/I request, with or without any concurrent I/O activity. For wait time, the time includes page retrieval.
• Histogram for CPU or Wait Time Percent displays the percentage of time spent executing or waiting on the given DL/I request. Solo time is indicated by the asterisk (*). The remaining overlapped time is indicated by the plus-sign (+).
• The last line gives total solo and total time for the transaction, module, section, and PSB name.
  Sample CPU Usage by DL/I Request Report
  
  Sample Wait by DL/I Request Report
  
  

The Attribution of CPU Execution Time Report for IMS environments

The Attribution of CPU Execution Time reports identify which system service routines were invoked by a specific module. These reports also indicate the location in the calling module that invoked the system service routine. Refer to these reports to identify the DL/I service calls causing activity in a system service routine.

Header lines

The report header identifies the invoked routine and shows the following:

• Its pseudo-module, module, and control section name (when available)
• Function descriptor for either the control section or the module.

Detail lines

For each IMS service routine in which Strobe for IMS identifies CPU activity, the report identifies the transaction that invoked the module by the following:

• Transaction name
• Module and control section name
• Return address (the offset of the DL/I service call within the module or control section)
• Line number and procedure name for indexed IMS applications
• Solo and total CPU time spent on behalf of the invoking transaction.

VIA section

If the invoking transaction has not directly called the service routine, the VIA section displays an intermediate routine called by the invoking site. The report shows the module name, the control section, and the function descriptor of the control section or module invoking the module.

Total line

The total line shows the total time attributed to the modules and transactions that invoked the IMS service routines. It may be less than the time shown in the Program Usage by Procedure or Most Intensively Executed Procedures reports because Strobe cannot always identify the invoker of a service routine.

The following figure shows sample Attribution of CPU Execution Time reports for modules DFSDLA00 and DFSDLR00. This example is discussed in Attribution of CPU Wait Time.

Sample Attribution of CPU Execution Time Report

The Attribution of CPU Wait Time Report for IMS environments

The Attribution of CPU Wait Time reports identify which system service routines were invoked by a specific module. These reports also indicate the location in the calling module that invoked the system service routine. Refer to these reports to identify DL/I service calls causing wait in IMS system service routines.

Header lines

The report header identifies the invoked routine, showing the following:

• Its pseudo-module, module, and control section name (when available)
• Function descriptor for either the control section or the module.

Detail lines

For each IMS service routine in which Strobe for IMS identifies CPU activity, the report identifies the transaction that invoked the module by the following:

• Transaction name
• Module and control section name
• Return address (the offset, within the module or control section, of the DL/I service call)
• For indexed IMS applications, the line number and procedure name
• Solo and total CPU time spent on behalf of the invoker.

VIA section

If the invoking transaction has not directly called the service routine, the VIA section displays an intermediate routine called by the invoking site. The report shows the module name, the control section, and the function descriptor of the control section or module invoking the module.

If the invoked module controls file access activities, the report shows, instead of the control section name, the data definition name of the data set currently serviced by the invoked module. In the example shown in Sample Attribution of CPU Wait Time Report, STRIDLON is a data definition name of a data set against which I/O is currently taking place.

Total line

The total line shows the total time attributed to the modules and transactions that invoked the IMS service routines. It may be less than the time shown in the Wait Time by Module report because Strobe cannot always identify an invoker of a service routine.

In this example (See the following figure), control section DFSKBDP0 of module DFSKBDP0 shows wait resulting from DL/I requests by module STRIL140. This example is discussed in Attribution of CPU Wait Time.

Sample Attribution of CPU Wait Time Report

IMS Preloaded Modules Report: #IPL

The IMS parameter PRLD= is a performance option that can be specified for an IMS region. The PRLD= parameter specifies a two-character suffix for the member DFSMPLxx in IMS.PROCLIB. DFSMPLxx is where the preloaded modules names are listed. The effect of DFSMPLxx is to reduce repetition of I/O for program loads. The region address space retains the modules loaded via the DFSMPLxx list.

The DFSMPLxx member of the IMS PROCLIB data set can be used to make resident in an IMS region z/OS, IMS, or user-written program modules that are not automatically preloaded into the IMS control region. Making some modules resident can improve throughput and response time for transactions frequently referenced. Additional detail on the use of the DFSMPLxx parameter can be found in the IBM IMS System Definition manual.

The Strobe#IPL report provides an indication of the usage of modules listed in the DFSMPLxx member during the measurement period. The #IPL reports can be used to determine if modules in the DFSMPLxx were used during measurement. The #IPL report can assist in balancing region performance and memory overhead used in making modules resident that were included from DFSMPLxx.

Ordinarily, preloading modules is advantageous only for MPPs and for message-driven Fast Path regions, and only when the preloaded modules are reentrant.

The Strobe #IPL report is generated if the PRLD= option is found in the IMS JCL and the matching DFSMPLxx suffix is found in IMS.PROCLIB.

Detail lines

For each Module listed in the IMS Preloaded Modules report as shown in Sample IMS Preloaded Modules Report - #IPL, Strobe identifies the following:

• MODULE is the module name.
• ACTIVITY indicates whether the module was accessed during the measurement.
• PRELOAD LIST indicates whether the module was preloaded during the measurement.
• SIZE is the decimal size of the load module.
• RMODE is the module's residency mode.
• AMODE is the module's addressing mode.
• DDNAME is the ddname from where the module was loaded.
• CONCAT# is the concatenation number relative to the ddname. For example, the third data set name in the STEPLIB concatenation would be CONCAT# = 2.
• LINK-EDIT ATTRIBUTES are the module link attributes.

The attributes displayed in the detail lines can be used against the recommendations in the IBM IMS System Definition manual section: DFSMPLxx member of the IMS PROCLIB data set.

Sample IMS Preloaded Modules Report - #IPL

#IPL Formatted IMS PreLoad List

The Formatted IMS Preload List (Sample Formatted IMS Preloaded List - #IPL) can be used to cut and paste directly to a member in IMS.PROCLIB prefixed with DFSMPL. The new member list can be used as a preload list member in the IMS JCL via the PRLD= parameter.

The name list follows the format described in the IBM IMS System Definition manual section: DFSMPLxx member of the IMS PROCLIB data set:

• Module name followed by a comma + space indicates more module names follow on next record.
• Module name followed by a space indicates last list member.

Strobe provides the module attributes following the space after the module name. The module attributes are treated as comments.

Sample Formatted IMS Preloaded List - #IPL

Transaction Profile Utilization Report Summary - #TRS

The Transaction Profile Utilization Report Summary - #TRS shows transaction counts and transaction times, ordered by transaction and IMS region, for all regions in the same IMS control region during the measurement period. If more than one region is being measured concurrently, only one region needs to specify transaction profiling. The transaction profiling report will be a duplicate for each measurement during the same measurement period under the same IMS control region.

IMS transactions are assigned to a class. IMS regions are assigned classes. The same class can be assigned to multiple regions. IMS assigns transactions to eligible regions. Transaction profiling reports provide transaction statistics for all regions under an IMS control region. If a transaction class is assigned across multiple regions, transaction profiling will show transaction timing for all regions the transaction executed in. If concurrent Strobe measurements were run to capture statistics where the region the transaction executes on was not isolated, transaction profiling may replace running more than the one concurrent measurement.

The #TRS report provides the ability to examine average transaction times across regions. The report groups transactions by region in the measured subsystem, and provides a quick performance comparison. Unexpected averages are easily identified. If greater granularity is required, the Transaction Utilization Report (#TUR) provides additional timings for DL/I activity grouped by transaction within region.

The #TRS report (Sample Transaction Utilization Report Summary - #TRS) displays average DL/I activity times in seconds for all transactions within a region and provides the following information:

• TRANSACTION NAME is the transaction name.
• REGION NAME is the region in which the transaction executed.
• TRANSACTION COUNT is the total number of times the transaction executed in the region.
• AVERAGE EXECUTION TIME is the time from start of the transaction to the end of the transaction minus the zIIP time totaled by transaction. The total time for the transaction is then divided by transaction count.
• AVERAGE DATA BASE IO TIME is the total database IO time for the transaction divided by transaction count.
• AVERAGE LOCK TIME is total database lock time for the transaction divided by transaction count.
• AVERAGE zIIP TIME is the total zIIP time for the transaction divided by transaction count.

The #TRS report displays activity time, in seconds. Times displayed as >9.999 indicate the maximum field value has been exceeded.

Sample Transaction Utilization Report Summary - #TRS

Transaction Utilization Report: #TUR

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 #TUR report provides transaction counts, module name, PSB name, transaction abend counts, and DL/I call activity. The max, min, and average is provided for execution, database IO, lock, and zIIP times. Execution time is the time from start of the transaction to the end of the transaction minus the zIIP time.

The #TUR report (Sample Transaction Utilization Report - #TUR) provides additional capability to resolve concerns for the region timing differences or other related questions by providing detailed transaction/region data.

For each transaction in the associated region the #TUR report provides the following measurements by region:

• TRANSACTION is the transaction name.
• MODULE is the module that issued the DL/I call.
• PSB is the PSB name for the transaction.
• REGION NAME is the region where the transaction executed.
• TRANSACTION COUNT is the total number of times the transaction executed.
• TRANSACTION ABENDS is the number of transaction abends.
• EXECUTION MAX TIME is the highest transaction execution time.
• EXECUTION AVG TIME is the total execution time divided by the number of transactions.
• EXECUTION MIN TIME is the lowest transaction execution time.
• DATA BASE IO MAX TIME is the highest transaction database IO time.
• DATA BASE IO AVG TIME is the total database IO time divided by the number of transactions.
• DATA BASE IO MIN TIME is lowest transaction database IO time.
• LOCK MAX TIME is the highest transaction lock time.
• LOCK AVG TIME is the sum of the data base lock time divided by the number of transactions.
• LOCK MIN TIME is lowest transaction lock time.
• zIIP MAX TIME is the highest transaction zIIP time.
• zIIP AVG TIME is the sum of the zIIP time divided by the number of transactions.
• zIIP MIN TIME is lowest transaction zIIP time.
• FUNCTION COUNTS identify the number of DL/I calls per transaction.

The #TUR report displays activity time, in seconds. Times displayed as >9.999 or counts displayed as >99,999,999 indicate the max field value has been exceeded.

Sample Transaction Utilization Report - #TUR