Interpreting Strobe Performance Profile for Batch Regions

CA-IDMS Central Version and local mode batch regions are characterized by high amounts of wait time because these jobs tend to be I/O-intensive, with nearly all of the I/O resulting from CA-IDMS DB DML commands issued by an application program. Strobe for Advantage CA-IDMS assigns the majority of this wait time to IDMSINTB, the CA-IDMS Batch Interface module, and provides a more detailed breakdown by DML command. Strobe identifies, by program name, control section name, offset within the program, and, if available, DML sequence number, each DML command responsible for causing wait.

This topic provides three Performance Profile reports generated for a batch job running CA-IDMS. The report data applies to CA-IDMS releases 10.2 and later.

Measurement Session Data Report

The Measurement Session Data report (See the following figure) describes the environment during a measurement session. The low execution time percent in this example is typical of Central Version batch mode because all CA-IDMS database activity is performed by the CA-IDMS-CV address space. In the SUBSYSTEM field, the name IDMS is followed by its release number, which is followed by a three-character code indicating whether the address space is running Central Version batch (code CVB) or local mode (code LOC). If no characters appear, Strobe measured an online region.

Measurement Session Data Report

Wait Time by Module

The Wait Time by Module report for Batch Regions (See the following figure) shows the sites of wait time. In this CA-IDMS-CV batch address space, almost all of the wait time is shown in the pseudo-module .IDMS as attributed to the control section IDMSINTB, the CA-IDMS Batch Interface. This wait time represents the time incurred by the CV region to service the database request.

Wait Time by Module Report for Batch Regions

Attribution of CPU Wait Time Report

The Attribution of CPU Wait Time report (Attribution of CPU Wait Time Report) identifies the sites of invocation of system routines. When wait time is attributed to the CA-IDMS Batch Interface IDMSINTB invokers, the report header displays the invoking routine, showing:

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

Each report detail line identifies an invoker of the batch wait and includes:

Module and control section name
DML command return offset
DML sequence number, if the program was compiled with the DEBUG DML compiler option
Page wait and total wait time caused by the invoker.

Attribution of CPU Wait Time Report

In this example, control section IDMSB757 in module IDMSB757 accounts for 92.37% of the wait time incurred by the CA-IDMS batch interface. Two areas within this control section are of particular interest: the call statement at offset 00A956, DML sequence number 15, accounts for 53.52% of the wait time; and the call statement at offset 00A666, DML sequence number 12, accounts for 26.40% of the wait time.

The offset or DML sequence number can be compared with the compiler listing to determine the line of code that is causing the wait. The sample code shown in the following figure shows DML sequence number 15, at offset 00A956. This offset falls between offsets 00A940 and 00A9B6 in the code, and it is actually the offset to which CA-IDMS returns control within the group of instructions generated by the COBOL compiler when it compiled the CALL verb. Therefore, when you compare the Attribution report to your listing, examine the group of statements indicated by the DML sequence number rather than the exact offset listed.

CA-IDMS/COBOL Code Showing the DML Sequence Numbers

In this case, the statement is a record retrieval from an indexed or sorted set. The amount of wait time indicates that the set’s structure should be investigated. Also determine the number of concurrent access attempts.

Attribution of CPU Execution Time Report

The Attribution of CPU Execution Time report (See the following figure) identifies the sites of invocation of system routines. When execution time is attributed to the CA-IDMS Batch Interface IDMSDBMS invokers, the report header displays the invoking routine, showing:

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

Each report detail line identifies an invoker causing CPU execution time and includes:

Module and control section name
DML command return offset
DML sequence number, if the program was compiled with the DEBUG DML compiler option
Execution time and total execution time caused by the invoker.

Attribution of CPU Execution Time Report

In this example, control section E2ANDLEL in module E2ANDLEL accounts for 8.24% of the execution time incurred by the CA-IDMS batch interface. The call statement at offset 0013FA, DML sequence number 24, accounted for the largest amount of execution time for the control section execution time using 2.15%.

Using Database Analysis Utilities with Strobe

To help identify the source of performance problems, you can combine information from the Strobe Performance Profile and your database utilities. As shown in the previous example, if the problem lies in record retrieval, then your database utilities can give you the average set length and the number of levels in your index. You can derive other helpful information by issuing the CA-IDMS command ACCEPT STATISTICS before your job has completed processing.

Sorted Sets

If the set is sorted, with many members chained off each set owner, and access by sort key is random, you can decrease the amount of search time by:

Adding a set from the member record that contains an index to the member specifying the same symbolic key
Transforming the set from a sorted set into an indexed set
Reducing the number of members per owner.

Indexed Sets

If the set is indexed, then the index may be fragmented or unbalanced, or there may be collisions between batch and online users who need to update the index. To determine whether several users are trying to access the index concurrently, submit simultaneous Strobe measurement sessions for both the batch program and the CV region. Then examine the overlap between the Performance Profiles to determine how many transactions are trying to access the index files or whether your database areas are on the same physical units as your database journals and log files.

In these cases, you can:

Rebuild the index as sorted so that it is more evenly balanced
Ensure that all applications updating the index lock and release the specific records they need (COMMIT frequently) to allow other users concurrent access to other records
Check usage modes to ensure that all users browsing the index are not holding update locks
Ensure that your batch job issues frequent COMMIT statements that release any locked records
Consider duplicating index information so that online users can browse an updated index without conflicting with the operation of the batch job, and then limit the online access so that it becomes complementary.

CALC or VIA

If your sets are stored using a CALC key or VIA a set owner, database performance can degrade when the assigned database area becomes heavily populated (database statistics will show a high number of CALC and VIA overflows). In this case, unload the database, enlarge the database areas, and reload the database.

Database Buffering

If database statistics show a narrow ratio between pages-read and pages-requested, there may be insufficient database buffer pages or conflicting utilization of buffer pools. You can find this information by issuing the CA-IDMS command ACCEPT STATISTICS before your job has completed processing.