For every transaction run on your system you can also see, among other things, CICS Monitoring Facility (CMF) performance records are very comprehensive and detailed. The transactions can show how much CPU it consumed under each TCB, how long it used the network along with the amount and type of file I/O's.
Of course there's some bad news. First, because there's one record for each transaction, you often have to wade through millions of them to find the one you want. Second, they're written in an odd format that is difficult to navigate, especially in higher level languages. The easy answer is to buy a product to break down and analyze the records.
However, not all of us have that option given the software budgets we have to live with. That's where DFH$MOLS comes in.
IBM distributes DFH$MOLS with CICS and documents its usage in the Operations and Utility guide. A quick look at the manual will show you that DFH$MOLS has two functions; PRINT and UNLOAD. Along with these functions, there are other keywords and commands you can use to include or exclude the records based on things like CICS APPLID, transaction ID, date and time.
My favorite function is UNLOAD. Unloading CMF records changes them from an unseemly mess into a flat record format easily read and reported on by any high-level language or a reporting system like SAS. The layout of a standard record is documented in DFHSAMP member DFHMNPDA.
However, you have to be a little careful about translating the fields in DFHMNPDA into your own programs. First, be careful to note the length and type of each field. Second, most of the fields you'll be interested in, for example CPU, are in eight byte "clock" fields. A clock field is actually two four byte fields stuck together. The first four bytes is a count of sixteenths of a microsecond, so you have to multiply it by 16 before you use it. The second four bytes is a 24 bit counter of the number of times an interval was added to t...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
he first four bytes. My best advice is to consult the CICS performance guide if you have any questions about a field's length, format and meaning.
Of course, DFH$MOLS can't unload CMF records on its own. One of the reasons CMF data is difficult to use is it is self-defining. Each CMF record begins with a list of "connectors" followed by the data fields. Each connecter has a number identifying its corresponding data field along with the offset of that data in the data field group. DFH$MOLS ties the connectors and the fields together by referencing a CMF dictionary record. The dictionary record lists each field's number, name and format. So, to process each record, DFH$MOLS gets the field ID out of the connector and looks it up in a saved dictionary record. From the dictionary entry DFH$MOLS knows all about the field and how to print or move it into an unloaded record.
The contents of CMF records and the dictionary record are heavily dependent on the Monitoring Control Table (MCT) of the CICS they came from. CICS spits out a dictionary record every time it comes up. Alas, sometimes the interval of CMF records you want to look at doesn't contain a dictionary record, which is why IBM supplies utility DFHMNDUP. DFHMNDUP will produce one CMF dictionary record using as input a CICS name, system ID and MCT suffix. Because CMF dictionary records are so important, at our shop we use DFHMNDUP to generate a dataset containing just dictionary records for all our regions. Then we put this dataset at the front of the concatenation of SMF files we want to run through DFH$MOLS.
As useful as DFH$MOLS is, there are still some things that need changing. Happily, IBM ships the source in DFHSAMP. Thus, by looking through the source and finding the right spot you can make changes for a friendlier utility.
Some suggestions would be:
- The ability to specify generic APPLID's
- The ability to select which fields to unload
- To include fields besides the defaults DFH$MOLS knows about.
DFH$MOLS is far from perfect. Its control language is rudimentary and the record selection statements don't allow you to specify generic resources. It also tends to be unforgiving of mistakes and will ABEND after writing a terse message to the console. But, with a little set up and maybe a little customization, it can be a cheap way to delve into the rich, dense information provided by CMF performance records.
About the author: Robert Crawford has been a CICS systems programmer for 24 years.
