Performance class data

Performance class data is detailed transaction-level information, such as the processor and elapsed time for a transaction, or the time spent waiting for I/O. CICS® writes at least one performance monitoring record for each transaction.

Performance class data provides detailed, resource-level data that can be used for accounting, performance analysis, and capacity planning. This data contains information relating to individual task resource usage, and is completed for each task when the task terminates.

This information can be used periodically to calculate the charges applicable to different tasks. If you want to set up algorithms to charge users for resources that they use, you could use this class of data collection to update the charging information in your organization's accounting programs.

You can enable performance class monitoring by coding MNPER=ON (together with MN=ON) as a system initialization parameter. Alternatively, you can use the monitoring facility transaction CEMN, or the EXEC CICS SET MONITOR command, to enable performance class monitoring dynamically.

CICS monitoring performance class data is collected at system-defined event monitoring points (EMPs) in the CICS code. You can choose which classes of monitoring data you want to be collected. 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.

At these points, you can add or change up to 16384 bytes of user data in each performance record. Up to this maximum of 16384 bytes you can have, for each ENTRYNAME qualifier, any combination of the following:
  • 0 - 256 counters
  • 0 - 256 clocks
  • A single 8192-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 execute on that transaction's monitoring area. The DELIVER option would result in a loss of data, 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 MONITOR.

Additional EMPs are provided in some IBM® licensed programs, such as DBCTL. From the CICS perspective, 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 from 200 through 255 are for use in IBM program products. The numbers can be qualified with an entryname, 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 that has the same identification number and entry name 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.

The following ideas show how you can use the CICS and user fields provided with the CICS monitoring facility:
  • To time how long it takes to do a table lookup routine in an application, code an EMP with, for example, 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 executes. When EMP 50 is processed, user clock 1 is started. When EMP 51 is processed, the clock 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 one unit for each record scanned and not selected, and three 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 or operator errors. CICS includes facilities to turn individual bits or groups of bits on or off in these counts.

  • The performance clocks can be used for accumulating the time taken for I/O, DL/I scheduling, and other processes. It usually includes any waiting for the transaction to regain control after the requested operation has completed. The periods are counted as well as added, so you can get both the total and the average time waiting for I/O. To highlight an unusually long individual case, set a flag on in a user count, as explained earlier.
  • 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.

    For example, some users have a single transaction ID so that all user input is routed through a common prologue program for security checking. In this situation, it is easy to record the subtransaction identifier during 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.)

For more information about event monitoring points, see User event monitoring points - DFHMCT TYPE=EMP.