Monitoring DBCTL--transaction level data

Monitoring data for DBCTL is passed to CICS® and IMS™ components. (See Figure 48.) See the CICS Operations and Utilities Guide for help on switching monitoring on, and on printing and formatting the data.

This section covers:

DBCTL monitoring data returned to CICS

Monitoring data at the transaction level is passed back to CICS by DBCTL whenever a TERM request occurs, either explicitly, or implicitly at the end of task termination. The data is appended to the CICS monitoring facility performance record of the issuing task. The data returned is as follows:

Note:
The elapsed CPUTIME field was introduced by IMS APAR PL83370. The CPUTIME represents the time spent in the DRA Thread TCB from the time the PSB is scheduled, to the time the PSB is terminated. CICS always terminates the PSB at the end of the Unit of work (UOW). The CPUTIME does not include any time spent in the DBCTL region.

Obtaining DBCTL monitoring data sent to CICS

DBCTL supplies CICS with monitoring data, which is then output to the CICS monitoring domain in the following cases:

To obtain the monitoring data that DBCTL returns to CICS, code two additional event monitoring points (EMPs) in your CICS monitoring control table (MCT). DBCTL EMPs can be found in CICSTS31.CICS.SDFHSAMP member DFH$MCTD.

For programming information on EMPs, and the format of monitoring records, see the CICS Customization Guide.

When you have obtained the monitoring data, you can use monitoring tools such as the CICS monitoring facility and the Service Level Reporter (SLR) with the data supplied to tune your CICS-DBCTL environment. See the CICS Customization Guide for programming information on using the CICS monitoring facility.

Service Level Reporter (SLR)

Service Level Reporter (SLR) is an IBM® database and reporting program that collects and analyzes data from CICS and other IBM systems and products. SLR collects CICS data from CICS monitoring records and from a subset of CICS statistics on the SMF log data set. It then analyzes the data, summarizes the results, and stores the data in the SLR database.

The DBCTL data in the CICS monitoring records is output as one 256-byte block, and is written by the EMP DBCTL.2, as defined in CICSTS31.CICS.SDFHSAMP member DFH$MCTD. The DSECT for this 256-byte block of data is mapped by the DFSDSTA macro in the IMS GENLIBs. The SLR tables CICSTRANSLOG and CICSTRANSNUM contain the fields in this block.

During SLR installation, you must specify whether you want DBCTL data. For guidance on the format of this data, see the description of the DFSDSTA macro in the appropriate IMS Customization Guide. For information on SLR data in CICS and IMS, see the IMS System Administration Guide or the IMS Administration Guide: System. For help on using SLR, including examples of SLR reports and how to make use of them, see the Service Level Reporter General Information manual.

Note:
There is a follow-on product to SLR, called Performance Reporter for MVS™, which has DB2® as a prerequisite. This product includes the functions that are carried out by SLR. Performance Reporter for MVS CICS Performance Feature Guide and Reference, SH19-6820, describes the way this product works with CICS.

IMS monitor reports with DBCTL

This section summarizes DBCTL-related data in IMS monitor reports. (This information also applies if your CICS system is connected to an IMS DM/TM system to obtain DBCTL support.)

IMS monitor reports that apply to DBCTL

Note:
In a DBCTL environment, interpret the terms "program" and "transaction" in these reports as "PSB" and "PSB scheduling", respectively.

IMS monitor reports that apply partially to DBCTL

Note:
In a DBCTL environment, interpret the term "region" in these reports as the representation of a CICS thread or a BMP region in DBCTL, but beware that a DBCTL region may represent different CICS threads or BMP regions during a monitor run.

IMS monitor reports that do not apply to DBCTL

The following reports, related to transaction management and communication, do not apply to DBCTL, and either do not appear, or are shown as headings without any data:

Data contained in relevant IMS monitor reports

This section tells you what kind of data you can find in the IMS monitor reports that apply to DBCTL.

General wait time events

All threads built for a CICS system have the same job name as that CICS system. They are shown in the jobnames for regions in the "General reports".

General reports

The "general reports" include the "Regions and jobname" report and the "Region summary report".

Regions and jobname report

Within a trace interval, a thread can be assigned to multiple CICS systems but it can only be assigned to one CICS at any one time. So, depending on the number of CICS systems connected to DBCTL, the regions and jobname report can show:

Any monitor report for a region is a summary for all connected CICS systems that a thread has served during the trace interval. For example, the elapsed time of schedule end to first call means the sum of this elapsed time for all CICS systems that a thread has been assigned to during the trace interval.

Depending on the workload of a CICS system, a trace interval may be a relatively short period of time, and thread switching between depending regions may not occur very often. However, the more the workload fluctuates, the more frequently threads are likely to be assigned amongst connected CICS systems.

Region summary report

A region summary report can show:

Program summary

DBCTL does not process any messages. For the purpose of using the DC monitor report, it counts each PSB schedule as one message dequeued. Because DBCTL is not the transaction manager, it has to assume a one-to-one relation between a CICS transaction and a PSB schedule. This is shown in program summary, where the number of transactions dequeued is the same as the number of scheduled requests. "Per transaction" means requests per schedule, and "elapsed time per transaction" means elapsed time per schedule.

Run profile

In run profile, the number of messages dequeued means the number of scheduled PSBs and transactions per second means PSB schedules per second.

Transaction queuing report

This report can include a list of "transactions" for DBCTL. Each transaction name is an 8-byte transaction ID specified by CICS on the schedule request. A transaction ID from CICS comprises of a 4-byte CICS transaction name, plus a 4-byte CICS identifier. If CICS does not specify a transaction ID, DBCTL takes the CICS region ID, obtained at connection time. In this report, for DBCTL, the transaction "number dequeued" means number of PSB schedules. The "on queue when scheduled" in this report is always zero because the IMS message queues do not apply to DBCTL.

For examples of IMS monitor reports and detailed guidance on interpreting their contents, see the IMS Utilities Reference: Database manual manual.

Using the IMS monitor

DBCTL enables CICS users who do not have an IMS/VS DB/DC or IMS/DM/TM system to use the IMS monitor online. The IMS monitor is the main tool provided by IMS for monitoring. It collects data from the system while it is running. It formats and records significant events during execution, and is useful in tuning constrained systems.

Monitoring data is written to a separate data set or tape defined by the IMSMON DD statement in the DBCTL JCL. To define this data set or tape and to run the IMS monitor with DBCTL, add an IMSMON DD statement to your DBCTL JCL. For further guidance on doing so, see the IMS System Definition Reference manual manual or IMS Installation Volume 2: System Definition and Tailoring.

To allocate an IMSMON data set, use the IEFBR14 utility to allocate a data set without any DCB parameters; for example:

//ALLOC     EXEC PGM IEFBR14
//IMSMON DD DISP=(NEW,CATLG),UNIT=3380,VOL=SER=xxxxxx,SPACE=(CYL,(5,5))

You can start and stop the IMS monitor dynamically using the /TRACE command with the MON keyword. For example:

/TRACE SET ON MON ALL

gives you all the activity that the monitor collects. For guidance on using the /TRACE command and its keywords more selectively, see the IMS Operator’s Reference manual.

The IMS monitor has two phases:

The data collected by the monitor (also known as DFSMNTR0) is organized and printed by the IMS monitor report print program, DFSUTR20. See the IMS Utilities Reference: Database manual manual for guidance on using the IMS monitor report print utility, DFSUTR20, and for information on using the IMS monitor to identify constraints.

DBCTL data returned to IMS log

In addition to the information returned to the monitor, as described in IMS monitor reports with DBCTL, IMS writes some monitoring information to the log records. This information is always recorded; you do not have to request it. IMS appends the following information to the X'08' log records during scheduling.

IMS appends the following information to the X'07' log records at PSB termination:

Program isolation trace

For full function DL/I databases, you can use the program isolation (PI) trace to get records that indicate queueing activity taking place for program isolation. The PI trace records are written to the IMS log. You can then print them using the IMS file select and formatting utility. See the IMS System Administration Guide for further guidance on using PI trace.

DL/I trace

For full function databases, you can use DL/I trace with DBCTL by enabling the DL/I trace table in the DFSVSMxx member or by issuing the /TRACE command, as described in Controlling tracing of DBCTL events. Using the /TRACE command enables you to turn DL/I trace on and off while the system is running. Output is to the IMS log as type X'67FA' records. See the IMS Diagnosis Guide and Reference manual manual for guidance on using DL/I trace for diagnosis, the IMS Operator’s Reference manual for guidance on the commands needed to invoke it, and the IMS Utilities Reference: Database manual manual for guidance on printing its output.

Using the IMS log statistics utilities

You can use the following IMS log statistics utilities to process the information from the IMS log. See DBCTL data returned to IMS log for a list of the data returned to the IMS log.

See the IMS Utilities Reference: Database manual manual for guidance on using these utilities.

Trace facilities

CICS trace facilities are intended primarily as debugging tools. However, because they record all requests for CICS, you can use them to analyze the performance of individual transactions. See Problem determination for DBCTL for information on trace entries produced in a DBCTL environment. See the CICS Problem Determination Guide for information about specifying CICS trace parameters.

CICS auxiliary trace facility

The CICS auxiliary trace facility enables you to record trace entries on a separate data set to be analyzed later. Trace entries are time-stamped and they can provide very detailed information for analyzing constraints or other problems that may occur while CICS is running. For examples of CICS auxiliary trace output, see Trace entries produced by CICS.

However, consider carefully how often you need to use CICS auxiliary trace because it generates a large volume of entries, which means that there may be a considerable overhead if you run it all the time. Also, you may find it difficult to make effective use of too large a volume of such data. See the CICS Performance Guide for information on using auxiliary trace as a performance tool.

Additional performance tools

The following are additional performance tools that you may want to consider using with DBCTL if you already have them or are considering adding them to your system.

Generalized trace facility (GTF)

If you use the IRLM as your locking manager, you can use the generalized trace facility (GTF) to provide a trace of its activity. It traces request handler request completions, the PTB input/output buffers, and statistical data relevant to the IRLM. You can print the records GTF produces offline. Output is collected in a data set specified by its user in the GTF job. For guidance on using GTF, which you may find of use in debugging, see the IMS Diagnosis Guide and Reference manual manual.

MVS/ESA Resource Measurement Facility (RMF)

The MVS/ESA Resource Measurement Facility (RMF™) is a measurement tool designed to meet the needs of performance management in the large systems environment that MVS/ESA supports. Its primary purpose is to reduce the amount of system programmer time and expertise required to identify and to diagnose system tuning problems. It is designed to monitor selected areas of system activity and present the data collected in the form of SMF records and/or formatted reports. Display reports are also available for some system activities. For more details, see the CICS Performance Guide, and the Resource Measurement Facility User’s Guide.

Related concepts
Statistics, monitoring, and performance for DBCTL
Data available for a CICS-DBCTL system
Tuning a CICS-DBCTL system
[[ Contents Previous Page | Next Page Index ]]