In the immortal words of ol' Doc Hitzfelder, "The fastest I/O is the one you don't do." In tribute to this rule the mainframe has a rich history of I/O avoidance all the way from local shared resources (LSR) to control unit cache. CICS brings to the party several memory buffering techniques in the form of data tables, known as CICS managed data tables (CMDT).
CMDT's are perhaps the simplest and easiest to maintain type of CICS data tables. To define a file as a CMDT you simply change its TYPE definition parameter to "CICS." Depending on the size of the dataset you may also need to use the MAXNUMREC parameter to specify the number of records to be loaded into storage. After that CICS loads the records into memory and even ensures any updates to the dataset are propagated to disk.
Finding the right fit for CMDT and datasets
According to the CICS performance guide, you get the biggest benefit from datasets that are read or browsed rather than those that are frequently updated. You can identify these files by either looking at the file's operations flags (e.g., readable, browsable, addable) or CICS statistics. The CICS statistics will be able to tell you if the file is mostly read even if the file definition allows updates.
 |
|
|
|
|
Any datasets you are sharing with RLS are immediately ineligible even if they're updated only once every payday.
|
|
|
|
|
|
|
|
|
|
Another qualification is dataset size. Naturally you will derive the most benefit from small datasets whose records can be held entirely in memory. Larger datasets may also see some benefits depending on the application's reference pattern. If records are randomly read from disparate areas of the file the odds decrease that a needed record is in memory, and CICS will spend most of its time swapping records in and out of the table.
Finally, there is one last big "gotcha" on file selection. A file cannot be defined as a table and use record level sharing (RLS). So, any datasets you are sharing with RLS are immediately ineligible even if they're updated only once every payday.
CMDT's are not free as you have to consider the amount of storage they occupy. CICS throttles memory usage with the MAXNUMREC parameter which specifies the maximum number of records in the data table. If you don't provide a value CICS will attempt to load the entire dataset into memory up to the 16M -- 1 record limit.
CICS allocates CMDT's in extended storage left over after CICS gets its extended dynamic storage areas (EDSA's). Therefore, if you plan to keep a boatload of data in storage you may need to adjust your EDSA size downward. Also remember that CICS does not allocate all the DSA memory when it initializes. Therefore, if you make CMDT storage too big there may be a chance CICS will start happily but run into problems if it can't allocate a new DSA segment later in the day.
Useful CMDT file control statistics
Implementing a CMDT just means changing the file's definition. There are no changes to the base dataset required, nor any application code to change. You will know the file is a CMDT when you see message DFHFC0941 (data table load completed) in CSSL. You may also see message DFHFC0935 (SHAREOPTIONS of source data allow for inconsistencies between table and source) in CICS' job log, but that should not be any worry if the file is read only to all the regions in the CICSPlex.
Unfortunately, we just began using CMDT's so I don't have any hard performance data to describe how ineffably wonderful they are. However, the CICS performance guide says applications can save up to 70% of file control CPU.
In the absence of performance data I can tell you about some useful file control statistics:
| A17DTRDS |
The number of data table reads and browses as opposed to those hitting the source dataset |
| A17DTRNF |
Records read from source dataset. If the file is small enough to fit into storage this will simply be the number of records. |
| 17DTAVR |
Records added from WRITE requests |
| A17DTARJ |
Written records CICS tried to add but couldn't because the table was full |
| A17DTSHI |
Record number high-water mark |
| A17ALT |
Total storage allocated |
| A17UST |
Total storage used |
The first few data elements can tell how much benefit you're getting from the CMDT. They will also tell you how much write activity there is on the file and how well the CMDT avoids I/O. The last two are probably the most important for monitoring CMDT storage usage just in case it starts encroaching into DSA.
Limited I/O avoidance provided
CMDT's offer a good, if somewhat limited facility for I/O avoidance. They're not good for frequently updated or large datasets. However, they do seem especially well suited for small datasets containing referential data. The key advantages are they are easily set up without any changes to the source dataset or any programming changes to the application. This means CMDT's may provide large rewards for datasets with a good fit.
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.
