The CICS monitoring facility (CMF) keeps detailed performance information for every transaction. Yet despite containing enough data to make DASD (direct-attached storage device) guys cry -- I've seen it happen -- sometimes it's not enough. For application-specific tuning or debugging you need more details and CMF event monitoring points (EMPs) come in handy.
EMPs allow user-written code (system or application) to insert data into CMF records. There are three types of fields available:
- Counters to keep track of how often something happens
- Clocks to measure elapsed and CPU time
- Free-form text field (CMF treats this user data as one long text field, but multiple EMPs may insert data at different offsets).
The monitoring control table
You prepare CICS for the additional monitoring data in the monitoring control table (MCT). If you do not code EMPs into the MCT, the monitor commands will get INVREQ errors and the data will not be inserted.
To configure an EMP, the DFHMCT macro must specify TYPE=EVENT and CLASS=PERFORM. The ID parameter denotes the monitoring point identification to be used in the EXEC CICS MONITOR command that will provide the data. The ID may be a number between one through 199 (200 through 255 are reserved for IBM products) or a compound name of entry.n, where entry is a string and n a number. This allows for multiple uses of the number while uniquely identifying the event.
Following these is the PERFORM parameter, which describes the event and what to do when it happens. The parameter's options include an action followed by a number that identifies the clock or counter. The actions for clocks include SCLOCK (start clock) and PCLOCK (stop clock). Some counter actions are ADDCNT (add n to a counter) or NACNT (logically AND a counter). The text field uses the MOVE action specifying the length of data along with the offset for the data in the CMF text field. There are many other actions documented in the CICS Resource Definition Guide, so take a look and find the one most useful to you.
By way of example:
DFHMCT TYPE=EMP,CLASS=PERFORM,ID=1,PERFORM=(MOVE(0,16))
Defines an EMP to insert 16 bytes of data at offset 0 into the CMF record user field.
DFHMCT TYPE=EMP,CLASS=PERFORM,ID=2,PERFORM=(SCLOCK(1))
DFHMCT TYPE=EMP,CLASS=PERFORM,ID=3,PERFORM=(PCLOCK(1))
DFHMCT TYPE=EMP,CLASS=PERFORM,ID=4,PERFORM=(ADDCNT(1,1))
Finally, there are CLOCK, COUNT and FIELD parameters that allow you to assign informal names for the data items through the CMF data dictionary (optional).
The monitor commands
Defining the events to the MCT is easy but you must still add instrumentation to the program to populate the EMP data through the EXEC CICS MONITOR command. The MONITOR command follows this format:
EXEC CICS MONITOR POINT(p)
The POINT parameter identifies the EMP as defined in the MCT. If you used an entry name in the MCT, include the ENTRYNAME parameter as well. The other operands use depends on the event type.
For the text field, DATA1 points to the data while DATA2 contains its length. I'm not aware of any restrictions to the data's format or contents and therefore assume DATA1 could point to binary or packed data. If the EMP is a counter whose EMP entry lists a variable instead of a constant, DATA1 or DATA2 contain the value to be added.
Some MONITOR commands that go with the sample MCT above include:
EXEC CICS MONITOR POINT(1) DATA1('Hello Dolly') DATA2(11)
Puts the string "Hello dolly" at offset zero into the CMF record text field
The following pair of commands starts and stops clock 1. These strategically placed commands could keep track of a table search elapsed time:
EXEC CICS MONITOR POINT(2)
EXEC CICS MONITOR POINT(3)
EXEC CICS MONITOR POINT(4)
EMP monitoring gimmes
There are a couple of other products that are already instrumented to provide information through the EMPs:
- IMS' DBCTL interface has several EMPs, including counters for the number and type of DL/1 calls (e.g., GU or REPL). In addition, there is a clock that measures time spent in the DBCTL interface.
- TCP/IP has boatloads of counters and clocks. The counters keep track of the number and type of TCP calls while the clocks say how long a transaction might have waited for a READ.
 |
|
|
|
|
EMPs provide a low overhead and easy-to-use instrumentation platform.
|
|
|
|
|
|
|
|
|
|
EMPs provide a low overhead and easy-to-use instrumentation platform. The data is available with the insertion of a couple of commands and a change to a system table. In addition, EMPs don't necessarily have to be removed from a program when it goes into production. Instead the application programmer can leave the MONITOR commands in place, and if the production MCT isn't coded for them, the data won't be collected. Then, if it later becomes necessary to get the performance data, the systems programmer can change the MCT, bounce the region and start collecting the data.
Once again, CICS shows itself to be an advanced, analysis-friendly system.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
Did you find this helpful? Write to Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
