CICS Performance Tuning
Depending on I/O intensity, file tuning can improve CICS transaction response time and throughput more than any other aspect of tuning.
Defining VSAM Strings
To properly define VSAM strings, it's necessary to understand what they are and how they're used. A VSAM string is a logical entity representing a request for VSAM services involving data set positioning, and is akin in concept to a UCB. More than one string to a data set may be necessary. Here are some examples:
- A VSAM request via an AIX* (alternate index) needs two strings.
- A non-update request such as a READ or BROWSE only requires one string.
- A REWRITE involving an upgrade data set that's through the base data set requires one string for the base data set and a string for each member of the upgrade set.
- An ESDS that's both updated and read may experience better throughput by allocating a string for reading and a string for writing.
Many other factors affect the number of required strings. See the CICS Performance Guide for a more thorough discussion.
Another consideration regarding LSR is two types of strings are involved: file strings and pool strings. File strings are set in individual file definitions, and pool strings are defined for up to the eight pools that are possible with LSR. Use file strings to set an upper limit on the strings a file can take from a particular LSR pool; it isn't possible to set aside a specific group of strings for a particular file within a pool. Consider placing the file in its own LSR pool or a pool shared with a select group of other files.
Monitor the wait on strings at both the file and LSR level to determine where more strings may be needed. You shouldn't set strings excessively high, because they do take storage, but the objective is to get as much concurrent I/O as possible.
Utilizing Storage-Controller Cache
Setting up, tuning and configuring storage controller cache isn't an aspect of CICS tuning, but I want to discuss the topic because I've been involved in many tuning situations where exploiting storage-controller cache has improved CICS performance. Putting data in processor storage is ideal because it eliminates IOSQ, PEND, DISC and CONN time, but storage-controller cache complements this solution because there isn't enough real storage for the data processed. Storage-controller cache eliminates DISC and part of PEND time, but these times - especially DISC - are the largest part of I/O response time, and their reduction can have a favorable effect on IOSQ. An I/O request satisfied by data in storage-controller cache is a "hit." An I/O request satisfied only by data that resides on DASD is called a "miss."
RMF Spreadsheet Reporter is a workstation-based, no-charge product that takes RMF mainframe performance data and creates spreadsheet tabular and graphical reports. RMF Spreadsheet Reporter provides information on storage controller performance and hit/miss ratios of many I/O operations. It identifies places where an inexpensive storage controller memory upgrade can have close to the impact of a processor upgrade.
In the next article in this series I'll examine tuning activities that address real storage and virtual storage.
comments powered by