Choosing Tools for Detailed Monitoring | An Introduction to IMS: Your Complete Guide to IBMs Information Management System

Many of the monitoring tools you can use to collect detailed data are also used for general diagnostics. The principal tool provided by IMS for collecting and analyzing data is the IMS Monitor, which allows you to monitor online subsystems. For a standalone IMS DB batch system driven by an SLDS, use the DB Monitor. The DB Monitor can be active during the entire execution of an IMS batch job, or you can stop and restart it from the system console.

You can also use the IMS Performance Analyzer, program isolation and lock traces, and the external trace facility.

IMS Monitor

The IMS Monitor collects data while the online IMS subsystem is running. It gathers information for all dispatch events and places it, in the form of IMS Monitor records, in a sequential data set. Use the IMSMON DD statement in the IMS control region JCL to specify the IMS Monitor data set. IMS adds data to this data set when you activate the IMS Monitor using the /TRACE command. The IMS MTO can start and stop the IMS Monitor to obtain snapshots of the system at any time. However, the IMS Monitor adds to system overhead and generates considerable amounts of data.

Controlling IMS Monitor Output

Plan to run the IMS Monitor for short intervals and to control its operation carefully. Shorter intervals also prevent the overall averaging of statistics, so that problems within the system can be more readily identified. The IMS Monitor's output can be constrained by:

Type of activity monitored
Database or partition or area
Dependent region
Time interval

IMS Monitor Output Data Sets

The IMS Monitor output can be either a tape or a DASD data set. Using DASD eliminates the need to have a tape drive allocated to the online system. If you want to use the IMS Monitor frequently, you might find that permanently allocated space for a DASD data set is convenient. One technique is to code DISP=SHR on the IMSMON DD statement so that the reports can be generated as each IMS Monitor run completes.

You must coordinate the report generation with the operator because each activation of the IMS Monitor writes over existing data. Although this overwriting does not occur for tape data sets, new volumes must be mounted. The volume is rewound, and a mount request is issued each time you start the IMS Monitor.

Recommendations:

Do not catalog IMS Monitor data sets. The IMS Monitor can produce multiple output volumes while IMS is running if the data sets are not cataloged.
If you want IMS to dynamically allocate the IMS Monitor data set, do not include the IMSMON DD statement in the IMS control region JCL.
Allow IMS to dynamically allocate IMS Monitor tape data sets. A tape drive is not permanently reserved for the control region for dynamically allocated data sets.

Selecting Monitor Traces

After you establish monitoring requirements, you might be able to restrict the scope of the IMS Monitor activity. Restricting the scope has the advantage of reducing the impact of the IMS Monitor on system throughput. However, you should not compromise the collection of useful data.

You can control what specific types of events are traced by using specific keywords on the /trACE command. For example, you can monitor line activity, scheduling and termination events, activity between application programs and message queues, activity between application programs and databases, or all activity.

Obtaining IMS Monitor Reports

You can obtain reports based on the IMS Monitor's output by using the IMS Performance Analyzer for z/OS or the IMS Monitor Report Print utility (DFSUTR20). For information about the IMS Performance Analyzer for z/OS, see "Using the IMS Performance Analyzer for z/OS" on page 413.

The IMS Monitor Report Print utility summarizes and formats the raw data produced by IMS and presents the information in a series of reports. You can suppress the reports pertaining to DL/I calls and tabulated frequency distributions.

The duration of the monitored events is determined by the entries for start and stop of the IMS Monitor. You cannot select a different time period for reporting, because many of the timed events are not captured continuouslyonly when the IMS Monitor is started and stopped. For this reason, you should ensure that the IMS Monitor is stopped before taking any action to stop the IMS control region.

//DFSSTAT Reports

The //DFSSTAT reports give you the number of database and data communications calls issued by an application program and describe the buffering activity. These reports are described in IMS Version 9: Utilities Reference: System.

z/OS Generalized Trace Facility

You can use the z/OS generalized trace facility (GTF) to record a wide range of system-level events. The trace activity is controlled from the z/OS system console using the MODIFY command. Output is spooled to a sequential data set that is used by a generalized formatting utility. You can write exit routines that are called by the formatting utility to edit the trace records and present the data as desired.

For more information about the z/OS generalized trace facility, see z/OS V1R4.0 MVS Diagnosis: Tools and Service Aids.

z/OS Component Trace (CTRACE) Service

IRLM 2.1 uses the z/OS component trace (CTRACE) service to trace IRLM activity. Because the trace output is in z/OS CTRACE format, you can use IPCS CTRACE format, merge, and locate routines to process the buffer data.

Use the z/OS trACE CT command to start, stop, or modify an IRLM diagnostic trace. This command can be entered only from the z/OS master console. Entering the commands requires an appropriate level of z/OS authority. IRLM does not support all the options available on the command. You can also start the IRLM tracing by placing TRACE=YES in the IRLM procedure.

Related Reading: For information on the TRACE CT command for IRLM, see IMS Version 9: Command Reference. For complete information on the command, see z/OS MVS System Commands.

Obtaining Program Isolation and Lock Traces

In an IMS DB/DC or DBCTL environment, you can detect contention for a database segment by examining the output produced by the Program Isolation Trace Report utility (DFSPIRP0). To get the source data for the utility, issue the /trACE SET ON PI OPTION ALL command. To stop gathering source data, issue the /TRACE SET OFF PI command. A control statement for the utility can select a start or stop time relative to a specified date.

Tracing the program isolation function can create additional log records. These records contain the enqueue or dequeue requests issued by the program isolation function between sync points as a result of database updates, checkpoints, and message handling events.

The Program Isolation Trace Report utility reports only those events that require wait time. The report identifies the data management block (DMB) name, database control block (DCB) number, the relative byte address (RBA), the program specification block (PSB) name, and the transaction code. The utility sorts all activity by RBA number (shown as ID in the report). The report lists elapsed times for enqueues that required a wait during the trace interval, and totals the number of enqueues for each ID, DCB, and DMB. The requesting PSB or transaction is considered the holding PSB or transaction of the next enqueue waiting for the same segment. A sample report is shown in Figure 24-1 on page 417. In this report, no elapsed wait time is recorded for Fast Path.

Figure 24-1. Sample Program Isolation Trace Report

                  P R O G R A M I S O L A T I O N T R A C E R E P O R T             PAGE 1  DATE: 08/10/04  TIME: 16:36 TO 16:37  DCB *** REQUESTING *** ELAPSED    **** HOLDING *** ID TOTAL DCB TOTAL DMB       TOTAL  DMB NAME NUM ID  TRAN AND  PSB NAMES   TIME      TIME    TRAN AND PSB NAMES ENQ'S ENQ'S ENQ'S TABLEDBQ 1 0022D020  DE1Q     PROGDE1Q   16:36:54  0:00.061   DE2Q    PROGDE2Q                                                                                   1            003BE00C DE2Q     PROGDE2Q    16:36:51  0:00.027   DE1Q    PROGDE1Q                                                                                   1            007D901C DE2Q     PROGDE2Q    16:36:34  0:00.036   DE1Q    PROGDE1Q                                                                                   1            008EF014 DE2Q     PROGDE2Q    16:36:49  0:00.038   DE1Q    PROGDE1Q                                                                                   1            0090401C DE1Q     PROGDE1Q    16:36:50  0:00.072   DE2Q    PROGDE2Q                                                                                    1            00A06010 DE2Q     PROGDE2Q    16:36:38  0:00.046   DE1Q    PROGDE1Q                                                                                    1            00A1401C DE1Q     PROGDE1Q    16:36:50  0:00.008   DE2Q    PROGDE2Q                                                                                    1    7    7 TABLEDBR 1 002A901C DE2R     PROGDE2R    16:36:40  0:00.034   DE1R    PROGDE1R                                                                                    1            0045801C DE2R     PROGDE2R    16:36:41  0:00.043   DE1R    PROGDE1R                                                                                     1            0072F024 DE1R     PROGDE1R    16:36:30  0:00.053   DE2R    PROGDE2R

Related Reading: For details about how to run the Program Isolation Trace Report utility, see IMS Version 9: Utilities Reference: Database and Transaction Manager.

You can use the File Select and Formatting Print utility to select and print trace table and PI entries in the log records in the following ways:

Specify an OPTION statement with the PRINT parameter and COND=E and EXITR=DFSERA40 keyword parameters. The output is a report containing the program isolation (PI) trace records formatted in sequential order.

Related Reading: For an example of this report and an explanation of the headings, see IMS Version 9: Utilities Reference: System.

Select only the log records that contain the trace using the IMS Trace Table Record Format and Print module (DFSERA60), which is an exit routine that receives type X'67FA' log records from the File Select and Formatting Print utility and formats the records on the SYSPRINT data set.
Specify an OPTION statement with the PRINT parameter and COND=E and EXITR=DFSERA60 keyword parameters. The output is a report containing the PI trace entries, the DL/I trace entries, and the lock trace entries formatted to show these entries in sequential order. For an explanation of the headings, see an assembly listing of the macro IDLIVSAM TRACENT.

You can use an output report from the IMS Trace Table Record Format and Print module to find out more information:

The level of control (LEV) column shows read only, share, exclusive control, and single update activity.
The return code (RC) column shows return codes from DFSFXC10 or the IRLM. You can determine whether the caller had to wait for the requested resource, or if the transaction caused a deadlock situation.
The PST post code (PC) column shows the cause of the wait. If the entry is X'60', a deadlock occurred.

You can reduce the number of records examined by specifying an additional OPTION statement to the File Select and Formatting Print utility so that only records confirming deadlock are printed.

IMS automatically resolves deadlock situations by using dynamic backout. But the detection of deadlocks is important so that you can modify your application design to prevent future deadlocks.

The advantage of the Program Isolation Record Report is that it shows where contention for a particular segment or range of segments occurs. The report also shows which transactions are competing within a database. It also shows high wait times that might explain a delay in response time. One way to handle the segment contention might be to change the database design to separate some of the fields into an additional segment type.

IMS Trace Facility

You can use the IMS trace facility to write IMS trace tables internally or to an external trace data set. IMS can write this external trace data set to either DASD or tape:

DASD data sets can be allocated by JCL or can be dynamically allocated.
Tape data sets must be dynamically allocated.

You can also write the trace tables to the OLDS, but this could adversely affect OLDS performance. The external trace data sets are independent of the OLDS, so you can write trace tables to the external trace data sets even if the OLDS is unavailable.

To display the status of traces, use the /DISPLAY TRACE command. This command can be used to determine the status of the IMS traces in effect and the status of any external trace data sets in use.