The CICS Management Facility (CMF) is a wonderful and wicked thing. What's wonderful is that CICS is so deeply instrumented as to account for nearly every microsecond of a transaction's life. The problem is all these accounting buckets (most of which end up being zero) combine to form millions of long records that clog up the System Management Facility (SMF) data sets. CICS Transaction Server 3.2 tries to lighten the load with CMF record compression.
As you may remember, there are three basic pieces to the CMF records that CICS writes to SMF. The first two are the SMF header and SMF product sections. Following that is the CICS data section, of which there are several subtypes. When compression is on, CICS uses operating system compression and expansion services (CSRCESRV) to reduce the size of performance (subtype 1) data sections. The SMF header and product sessions remain their original size. Compression does not apply to other subtypes such as statistics or journal records.
The idea is to save CPU and direct-access storage device (DASD) for SMF. However, logic dictates that there must be a processor penalty both when CICS compresses the record and on the reporting end that reverses the process.
Enabling CMF record compression at CICS initialization is as easy as coding COMPRESS=YES on the monitoring control table (MCT) INITIAL macro. You can also enable compression dynamically with CEMT or the new monitoring control transaction, CEMN.
To test this out, I ran a couple of scripts executing roughly 79K transactions each. CMF compression was off for the first test. Then I dynamically enabled compression and ran the script again.
From this unscientific trial I found that the transactions running with compression experienced a small 1 to 2% CPU reduction. I'm not ready to declare victory, however, as the small percentage can probably be attributed to noise. I was also too lazy to look for where the extra CPU might have been consumed.
The following table demonstrates the space savings.
| Not Compressed | Compressed | Percent Difference |
| Transactions | 79,270 | 79,908 | |
| CMF Records | 21,123 | 6,164 | 29.18% |
| Transactions per Record | 4 | 13 | 345.60% |
| Bytes | 666,081,218 | 38,913,254 | 5.84% |
| Bytes per transaction | 8,403 | 487 | 5.89% |
As you can see, compression reduced the number of records by over two-thirds and the byte count even more. When comparing compressed and uncompressed record lengths, I discovered the reduced records came in many different sizes, while 99% of the uncompressed records were the same length. To me, this indicates that CICS tends to fill the CMF buffer up to nearly 32K bytes before writing it to SMF. Then, if compression is enabled, CICS calls the compression services and writes the record to SMF. Batching up the compression requests would be the preferred method because it reduces the number of calls to the compression service and may get better results by processing contiguous records.
Not every CICS performance reporting tool is ready to deal with compressed records, so you will have to check with your vendor. Also note that depending on your implementation, compressed and uncompressed records may appear in the same SMF stream. Fortunately, you can tell the difference by checking field SMFMNCRL (compressed record length) to ascertain the record's status. An uncompressed record's SMFMNCRL is zero.
The good news is the CICS/TS 3.2 version of IBM's sample CMF program DFH$MOLS now sports an EXPAND command, which tells the utility to -- of all things -- expand compressed records. Unfortunately, I don't think there's a combination EXPAND and UNLOAD function, so if you depend on DFH$MOLS to create unloaded CMF records, you will have to run them through the utility twice.
Since our shop's current tool doesn't support compression, I had to run all the above records through DFH$MOLS. The utility processed all 27,287 records with 3.79 CPU seconds and 48 seconds elapsed time, which isn't too bad.
From this little test it looks like CMF compression is a good deal. It greatly reduces the volume of CICS SMF data and may even save a little online CPU. However, I will reserve judgment until I see how compression works through the entire SMF writing, collecting and processing cycle. If you support your own reporting tool, my advice would be to look at DFH$MOL's source. It's relatively easy to find and duplicate the logic that detects and expands compressed records.
A word of warning on previous CICS statistics column
In my May 2009 CICS statistics column on new statistics for CICS TS 3.2, I mentioned the modifications to storage manager statistics (DFHSMSDS) but failed to note that the statistics ID (STID) changed from 2 to 14. This is actually a good thing, because it makes it easier to collect statistic records from different CICS releases in the same stream. The bad thing is, if you're not prepared for the new STID, you may not notice until you're fully converted to 3.2 and all the STID 2 storage manager statistics go away. Sorry about that.
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.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
