Deciding on monitoring activities and techniques in a DBCTL environment
To develop a master plan for monitoring and analyzing performance, you should determine whether dynamic, daily, or detailed monitoring suites your needs best and develop a plan accordingly.
When you develop a master plan for monitoring and analyzing performance, you should establish:
- A master schedule of monitoring activity
Coordinate monitoring with operations procedures to allow feedback of online events to be incorporated into instructions for daily or detailed data gathering.
- Which tools are to be used for monitoring
The tools used for data gathering should provide for dynamic monitoring, a daily collection of statistics, and more detailed monitoring.
- The kinds of analysis to be performed
Document what data is to be extracted from the monitoring output, identifying the source and usage of the data. Although the formatted reports provided by the monitoring tools help organize the volume of data, you should probably design worksheets to assist in data extraction and reduction.
- A list of the personnel that are to be included in any review
of the findings
The results and conclusions from analyzing monitor data should be made known to the user liaison group and to system performance specialists.
- A strategy for implementing changes to the DBCTL environment design,
and to the CCTL system design, resulting from tuning recommendations
Coordinate this change implementation strategy with your installation's standards for testing and standards for frequency of production environment changes. Change management is described in Modifying the system design.
Plan for three broad levels of monitoring activity:
- Dynamic
Observe the system's operation continuously to discover any serious short-term deviation from performance objectives.
This topic refers to IMS functions and general concepts related to dynamic monitoring. If the CCTL has similar functions (for example DISPLAY commands), they should also be used.
The output from the /DISPLAY or QUERY command is suitable for this level of monitoring, together with end-user feedback. One use of the Resource Measurement Facility (RMF) II is to collect information about processor, channel, and I/O device utilization.
The MTO is an important source of information about the behavior of the online IMS system. An important part of MTO feedback is the set of conditions during an IMS Monitor run. This information can help establish the validity of the monitor data.
With the status information that can be obtained using the /DISPLAY or QUERY command, you can arrange to get a processing status during online execution. The status can include the pool levels and active regions. At prearranged milestones in the production cycle—such as before scheduling a message or BMP region, at shutdown of part of the network, or at peak loading—the transaction processing status and measures of system resource levels can be recorded.
- Daily
Measure and record key system parameters daily. Record both the daily average and the peak period (usually one hour) average. Compare against major performance objectives and look for adverse trends.
The IMS system log can be used as input to offline processing to produce statistics on a daily or regular basis. The 07 and 08 log records contain the UOR data.
- Detailed
Periodically collect detailed statistics on system operation for performance analysis against system-oriented objectives and workload profiles.
Data at this level is much more voluminous. It typically contains sequences of events and tabulations. The timings reported are at a detailed level.
At this level of monitoring, special trace tools such as the IMS Monitor and Generalized Trace Facility (GTF) are useful. They collect a detailed sample of the online processing and distinguish between activity in CCTL threads, buffer pool usage, and system data set I/O.
Related reading:- For information on using the IMS Monitor, see IMS Version 15.2 Operations and Automation.
- For information on how monitoring and tools are used to detect performance problems, see Identifying and correcting performance problems.
System for Generalized Performance Analysis Reporting (GPAR), program number 5798-CPR, is designed as a base for reporting programs (IBM® or user-written). It helps summarize sequential activity traces like the IMS system log, IMS Monitor tapes, and GTF traces. It also contains facilities to print user-tailored graphs from any performance data log or non-VSAM sequential data set. GPAR is a prerequisite for ASAP II, VTAMPARS, and GTFPARS.