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.
- 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.
- 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.)