CICS monitoring collects data about the performance of all user- and CICS-supplied transactions during online processing for later offline analysis. The records produced by CICS® monitoring are of the MVS™ System Management Facility (SMF) type 110, and are written to an SMF data set.
Monitoring data is useful both for performance tuning and for charging your users for the resources they use.
The types, or "classes", of monitoring data that you can request CICS to collect are as follows:
You can choose which classes of monitoring data you want to be collected. How to do this is described in Controlling CICS monitoring.
CICS monitoring performance class data is collected at system-defined event-monitoring points (EMPs) in the CICS code. You cannot relocate these monitoring points, but you can create additional ones, at which you can gather user-defined performance data. You define user event monitoring points by coding DFHMCT TYPE=EMP macros
If you want to gather more performance class data than is provided at the system-defined EMPs, you can invoke user-defined EMPs in your application programs . You could use these additional EMPs to count the number of times a certain event occurs, or to time the interval between two events, for example. If the performance class was active when a transaction was started, but is not active when a user EMP is invoked, the operations defined in that user EMP are still executed on that transaction’s monitoring area. However, the DELIVER option results in a loss of data at this point, because the generated performance record cannot be output while the performance class is not active. If the performance class is not active when a transaction is started, invoking the user EMP has no effect.
To invoke user EMPs in your application programs, you use the EXEC CICS MONITOR command. For programming information about this command, see the CICS Application Programming Reference manual.
Additional EMPs are provided in some IBM® program products, such as IMS™ DBCTL. From a CICS point of view, these are like any other user-defined EMP. EMPs in user applications and in IBM program products are identified by a decimal number. The numbers 1 through 199 are available for EMPs in user applications, and the numbers 200 through 255 are for use in IBM program products. The numbers can be qualified with an entry name, so that you can use each number more than once. For example, ‘ENTRYA.4’, ‘ENTRYB.4’, and ‘4’ identify three different EMPs. Furthermore, any counts, clocks, or byte-strings updated at one of them are different objects from those updated at any of the others. If you do not specify an entry name, CICS assumes the default of USER.
For each EMP that you invoke in an application program, there must be a corresponding monitoring control table (MCT) definition, with the same entry name and identification number as the EMP that it describes. (The following sections refer to the combination of entry name and identification number as an empid.)
If you want to record the same type of data for different transactions, you can invoke the same empids in several application programs. This causes similar fields in the corresponding transaction performance records to be updated.
You do not have to assign empids to system-defined EMPs, and you do not have to code MCT entries for them.
It is not always possible to collect performance class data in the way that you would like for specific user tasks because of the way the applications are designed. It may be that you want to see performance data for individual transactions within an application, but these may not be identifiable by CICS. For example, there is a commonly-used type of design that is based on a single transaction that, when invoked, displays a menu screen from which the user can choose a specific application. It is then possible to run all the elements of the application under the common menu transaction ID. This is very effective from the application users point of view, because they do not have to use a large number transaction IDs to run an application. However, this is not helpful from a performance monitoring point of view, because all the data is identified with a single transaction ID, and using standard CICS performance class data, it is not possible to distinguish the various elements of a large application. Having completed a long and possibly complex transaction selected from the menu, on returning to the menu the user could select an entirely different application that then runs under the same menu transaction ID. Thus, the use of menu transactions and similar design techniques can make it difficult to monitor the performance of individual parts (or tasks) of an application.
You could also have the opposite of the menu transaction, where an application runs under many different transaction IDs, and you want some means of identifying or relating all these apparently disparate items of work to the same application. Another factor to consider when trying to collect data in the way the you want is the effect of invoking an EMP. Each time you invoke an EMP with an EXEC CICS MONITOR command, all the performance data collected by the system EMPs, and the data collected by the user EMPs, is cleared from the transaction's monitoring area. This makes it difficult for application designers using ordinary user-defined EMPs to control the gathering of performance class data.
To exercise greater control over the identification and collection of performance data, you can use the application naming event monitoring points that are generated for you automatically when you specify APPLNAME=YES in the DFHMCT TYPE=INITIAL macro. There are two APPLNAME EMPs generated when you assemble an MCT with APPLNAME=YES, DFHAPPL.1 and DFHAPPL.2, which perform the following default operations when invoked:
Unlike EMPs that you define explicitly with your own empids, data moved by invoking the APPLNAME EMPs is not reset by CICS, but you can set different values by invoking the APPLNAME EMPs again.
Figure 89 shows an assembler example of how to move a CICS transaction ID to the transaction monitoring area.
DFHEISTG DSECT
EMPDATA1 DS F Data area for DATA1 address
*
*
* Constants for DATA2 (null value) and ENTRYNAME
*
EMPDATA2 DC F'0'
APPLNAME DC CL8'DFHAPPL'
*
LA Rn,tranid Set addr of tranid
ST Rn,EMPDATA1 Store tranid for EMP
EXEC CICS MONITOR POINT(1) ENTRYNAME(APPLNAME) C
DATA1(EMPDATA1) DATA2(EMPDATA2) NOHANDLE
This example shows 4 bytes of user data, typically the transaction ID, being moved using the DFHAPPL.1 EMP. The data starts at offset 0, and the data length defaults to the length specified in the application naming EMP in the MCT. In this example, CICS monitoring domain uses the default length defined in the MCT, because DATA2 is defined as a null value. For the DFHAPPL EMPs, CICS monitoring domain requires you to specify both DATA1 and DATA2.
Figure 90 shows a COBOL example of how to move a predefined application name and a transaction identifier to the transaction monitoring area. This example uses both EMP 1 and EMP 2 of the DFHAPPL EMPs, moving 4 bytes and 8 bytes respectively, which are the default lengths defined in the MCT.
IDENTIFICATION DIVISION.
PROGRAM-ID. APPLNAME.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 APPLICATION-NAME-PTR POINTER.
77 MENU-APPLICATION-NAME PIC X(4) VALUE 'MENU'.
77 PAYROLL-APPLICATION-NAME PIC X(8) VALUE 'PAYROLL '.
77 DFHAPPL-NAME PIC X(8) VALUE 'DFHAPPL '.
77 DFHAPPL-DATA2 PIC S9(8) COMP VALUE +0.
77 BLANKS PIC X VALUE SPACE.
*
LINKAGE SECTION.
77 LS-APPLICATION-NAME PIC X(8).
*
PROCEDURE DIVISION.
* Get storage for DFHAPPL data and set address
EXEC CICS GETMAIN FLENGTH(LENGTH OF LS-APPLICATION-NAME)
SET(APPLICATION-NAME-PTR) INITIMG(BLANKS)
END-EXEC.
SET ADDRESS OF LS-APPLICATION-NAME TO APPLICATION-NAME-PTR.
MOVE PAYROLL-APPLICATION-NAME TO LS-APPLICATION-NAME.
* Invoke DFHAPPL EMP 2 to add the application name
EXEC CICS MONITOR ENTRYNAME(DFHAPPL-NAME) POINT(2)
DATA1(APPLICATION-NAME-PTR) DATA2(DFHAPPL-DATA2)
NOHANDLE
END-EXEC.
* Re-use application data area for transaction ID
MOVE MENU-APPLICATION-NAME TO LS-APPLICATION-NAME.
* Invoke DFHAPPL EMP 1 to add the transaction ID
EXEC CICS MONITOR ENTRYNAME(DFHAPPL-NAME) POINT(1)
DATA1(APPLICATION-NAME-PTR) DATA2(DFHAPPL-DATA2)
NOHANDLE
END-EXEC.
SET ADDRESS OF LS-APPLICATION-NAME TO NULL.
EXEC CICS FREEMAIN DATAPOINTER(APPLICATION-NAME-PTR)
NOHANDLE
END-EXEC.
EXEC CICS RETURN END-EXEC.
You use the monitoring control table (MCT):
Full details of the DFHMCT macros are provided in the CICS Resource Definition Guide, and you should refer to that book when reading the following sections.
There must be a DFHMCT TYPE=EMP macro definition for every user-coded EMP. This macro has an ID operand, whose value must be made up of the ENTRYNAME and POINT values specified on the EXEC CICS MONITOR command. The PERFORM operand of the DFHMCT TYPE=EMP macro tells CICS which user count fields, user clocks, and character values to expect at the identified user EMP, and what operations to perform on them.
Note that, in a single run of CICS, the format of all performance records is identical, and that the length of records increases relative to the number of data fields in the user EMPs defined in the MCT.
The maximum amount of user data that can be added to performance records is 16384 bytes. The user data is divided into user areas. Each user area is defined by coding an entry name qualifier on the ID operand of the DFHMCT TYPE=EMP macro. If you code the same entry name when defining multiple EMPs, all the EMPs operate on fields in the same user area. Correspondingly, by coding different entry names you can append multiple user areas to the monitoring records. Provided that the overall maximum of 16384 bytes is not exceeded, each user area can contain:
Each user area is uniquely referenced by its entry name. For example:
DFHMCT TYPE=EMP,ID=ENTRYA.1,PERFORM=...
DFHMCT TYPE=EMP,ID=ENTRYA.2,PERFORM=...
DFHMCT TYPE=EMP,ID=ENTRYB.1,PERFORM=...
DFHMCT TYPE=EMP,ID=ENTRYB.2,PERFORM=...
DFHMCT TYPE=EMP,ID=1,PERFORM=...
In the above examples, in addition to the system-defined performance fields, three user areas, ‘ENTRYA’, ‘ENTRYB’, and ‘USER’, are defined (if no entry name is specified, the default is ‘USER’). If the application codes an EMP invocation with ENTRYNAME(ENTRYA), only the ENTRYA user area is operated on. The only operation that spans all user areas is DELIVER, which operates across the whole monitoring area.
The DFHMCT TYPE=RECORD macro allows you to exclude specific
system-defined performance data from a CICS run. (Each
performance monitoring record is approximately 1848
bytes
long, without taking into account any user data that may be added, or any
excluded fields.)
Each field of the performance data that is gathered at the system-defined EMPs belongs to a group of fields that has a group identifier. Each performance data field also has its own numeric identifier that is unique within the group identifier. For example, the transaction sequence number field in a performance record belongs to the group DFHTASK, and has the numeric identifier ‘031’. Using these identifiers, you can exclude specific fields or groups of fields, and reduce the size of the performance records.
The examples below show some EXEC CICS MONITOR commands with the MCT entries that must be coded for them.
EXEC CICS MONITOR command | MCT entry |
---|---|
|
|
Example 1 shows a user clock being started by an application that is identified as PROG3. This is the eleventh EMP in this application. To prevent confusion with the eleventh EMP in another application, this EMP is uniquely identified by the empid PROG3.11. The clock that is being started is the first clock in a string, and has the identifier CLOCKA.
EXEC CICS MONITOR command | MCT entry |
---|---|
|
|
Example 2 shows the same user clock (CLOCKA) being stopped. Although this is the same clock being stopped by the same application as in example 1, it is being stopped from a different EMP. The EMP is uniquely identified by the empid PROG3.12.
EXEC CICS MONITOR command | MCT entry |
---|---|
|
|
Example 3 shows 32 bytes of user data being updated in the character string reserved for that purpose. The updated data starts at offset 0, and the data is not more than 32 bytes in length.
The following MCT entries make use of the two event-monitoring points in the performance class used by the CICS-DBCTL interface modules:
DFHMCT TYPE=EMP,ID=(DBCTL.1),CLASS=PERFORM,PERFORM=(MOVE(0,256)), *
FIELD=(1,RMIDATA)
DFHMCT TYPE=EMP,ID=(DBCTL.2),CLASS=PERFORM,PERFORM=(DELIVER)
These MCT entries are coded in the sample copy book DFH$MCTD.
The DBCTL data recorded by these event monitoring points can be mapped using the IMS macro DFSDSTA DSECT=YES, which is available in the IMS genlibs.
For more information about monitoring in DBCTL, refer to the CICS IMS Database Control Guide.
Exception class data is information on exceptional conditions suffered by a transaction. This data highlights possible problems in system operation. There is one exception record for each exception condition. Exception records are produced after each of the following conditions encountered by a transaction has been resolved:
An exception record is created each time any of the resources covered by exception class monitoring becomes constrained by system bottlenecks. If performance data is also being recorded, it keeps a count of the number of exception records generated for each task. The exception records can be linked to the performance data by the transaction identifier in both records.
This data is intended to help you identify constraints that affect the performance of your transaction. The information is written to a SMF data set as soon as the task that was originally constrained has been released.
You can enable exception-class monitoring by coding MNEXC=ON (together with MN=ON) as a system initialization parameter. Alternatively you can use, the CEMT, or EXEC CICS, SET MONITOR command to enable exception-class monitoring dynamically.
Transaction resource data is collected at transaction termination for each resource specified in the MCT on TYPE=INITIAL macro by specifying one or both FILE and TSQUEUE parameters. CICS writes one record for each transaction that is being monitored, provided the transaction has accessed the type of resource specified in the MCT. The file information collected in this class provides a detailed breakdown, by file name up to a maximum of 64 files, of the file information contained in the DFHFILE performance data group. The temporary storage queue information collected in this class provides a detailed breakdown, by temporary storage queue name up to a maximum of 32 temporary storage queues, of the temporary storage queue information contained in the DFHTEMP performance data group.
You can enable transaction resource monitoring by coding MNRES=ON (together with MN=ON) as a system initialization parameter. Alternatively you can use, the CEMT, or EXEC CICS, SET MONITOR command to enable transaction resource monitoring dynamically.
The various CICS monitoring class records are not written to SMF in the same way.
Performance data records are written to a performance record buffer, which is defined and controlled by CICS, as the records are produced. The performance records are passed to SMF for processing when the buffer is full, when the performance class of monitoring is switched off, and when CICS itself quiesces. When monitoring itself is deactivated or when there is an immediate shutdown of CICS, the performance records are not written to SMF and the data is lost.
Transaction resource data records are written to a transaction resource record buffer, which is defined and controlled by CICS, as the records are produced. The transaction resource records are passed to SMF for processing when the buffer is full; when the transaction resource class of monitoring is switched off; and when CICS itself quiesces. When monitoring itself is deactivated or when there is an immediate shutdown of CICS, the transaction resource records are not written to SMF and the data is lost.
Exception records are passed directly to SMF when the exception condition completes. Each exception record describes one exception condition. You can link performance records with their associated exception records by matching the value of the TRANNUM field in each type of record; each contains the same transaction number.
When CICS is initialized, you switch the monitoring facility on by specifying the system initialization parameter MN=ON. MN=OFF is the default setting. You can select the classes of monitoring data you want to be collected using the MNPER, MNRES, and MNEXC system initialization parameters. You can request the collection of performance class data, transaction resource class data, exception class data, or all three. The class settings can be changed whether monitoring itself is ON or OFF. For information about system initialization parameters, see the CICS System Definition Guide.
When CICS is running, you can control the monitoring facility dynamically. Just as at CICS initialization, you can switch monitoring on or off, and you can change the classes of monitoring data that are being collected. There are two ways of doing this:
If you activate a class of monitoring data while CICS is running, the data for that class becomes available only for transactions that are started thereafter. You cannot change the classes of monitoring data collected for a transaction after it has started. It is often preferable, particularly for long-running transactions, to start all classes of monitoring data at CICS initialization.
[[ Contents Previous Page | Next Page Index ]]