Event Monitoring Points

CICS® monitoring data is collected at system-defined event monitoring points (EMPs) in the CICS code. Although you cannot relocate these monitoring points, you can choose which classes of monitoring data that you want to be collected. Programming information about CICS monitoring can be found in the CICS Application Programming Reference and the CICS Customization Guide.

If you want to gather more performance class data than is provided at the system-defined event monitoring points, you can code additional EMPs in your application programs, from within task-related user exits, or from global user exits. At these points you can add or change up to 16384 bytes of user data within each performance record. Up to this maximum of 16384 bytes you can have, for each ENTRYNAME qualifier, any combination of the following data:
  • Between 0 and 256 counters
  • Between 0 and 256 clocks
  • A single 8196-byte character string

You could use these additional EMPs to count the number of times a certain event occurs, or to time the interval between two events. If the performance class was active when a transaction was started, but was not active when a user EMP was issued, the operations defined in that user EMP would still run on that transaction's monitoring area. The DELIVER option would result 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 was not active when a transaction was started, the user EMP would have no effect.

User EMPs can use the EXEC CICS MONITOR command. For programming information about this command, see the CICS Application Programming Reference.

Additional EMPs are defined in some IBM® licensed products, such as IMS™ DBCTL. From the CICS point of view, these are like any other user-defined EMP. EMPs in user applications and in IBM licensed products are defined by a decimal number. The numbers 1 through 199 are available for EMPs in user application, and the numbers from 200 through 255 are for use in IBM licensed products. In addition, the numbers can be qualified with an entry name so that you can use each number more than once. For example, PROGA.1, PROGB.1 and PROGC.1, identify three different EMPs because they have different entry names.

For each user-defined EMP there must be a corresponding monitoring control table (MCT) entry, which has the same entry name and identification number as the EMP that it describes.

You do not have to assign entry names and numbers to system-defined EMPs, and you do not have to code MCT entries for them.

Here are some ideas about how you might make use of user fields provided using the CICS monitoring facility:
  • If you want to time how long it takes to do a table lookup routine within an application, code an EMP with, say, ID=50 just before the table lookup routine and an EMP with ID=51 just after the routine. The system programmer codes a TYPE=EMP operand in the MCT for ID=50 to start user clock 1. You also code a TYPE=EMP operand for ID=51 to stop user clock 1. The application then runs. When EMP 50 is processed, user clock 1 is started. When EMP 51 is processed, user clock 1 is stopped.
  • One user field could be used to accumulate an installation accounting unit. For example, you might count different amounts for different types of transaction. Or, in a browsing application, you might count 1 unit for each record scanned and not selected, and 3 units for each record selected.

    You can also treat the fullword count fields as 32-bit flag fields to indicate special situations, for example, out-of-line situations in the applications, operator errors, and so on. The CICS monitoring facility includes facilities to turn individual bits or groups of bits on or off in these count fields.

  • The performance clocks can be used for accumulating the time taken for some sort of I/O operation. This is usually any waiting time for the transaction to regain control after the requested operation has completed. Because periods are counted as well, you can get the average time waiting for the I/O operation as well as the total waiting time. If you want to highlight an unusually long individual case, set a flag on in a user count as explained in the previous item.
  • One use of the performance character string is for systems in which one transaction ID is used for widely differing functions. The application can enter a subsidiary ID into the string to indicate which particular variant of the transaction applies in each case.

    Some users have a single transaction ID so that all user input is routed through a common prologue program for security checking or some other purpose, for example. In this case, it is very easy to record the subtransaction identifier in this prologue. (However, it is equally possible to route transactions with different identifiers to the same program, in which case this technique is not necessary.)