Index CISZ is a largely neglected VSAM KSDS tuning area. Often, the VSAM default algorithms determine the index CISZ associated with the KSDS cluster. The default index VSAM selects is generally acceptable, especially after the change to the selection criteria in z/OS Version 1 Release 3. Tuning the index CISZ is an important issue because of:
- The number of index levels associated with the file
- The need to avoid key compression problems.
This article reviews the selection of index CISZ and includes an overview of the index record structure in the CI.
There are two types of index CIs:
- The lowest level index called the Sequence Set Index (SSI)
- The second and higher levels within a file, called the Index Set (IS).
There’s one SSI for every data CA in the file. This index record requires sufficient space to accommodate the compressed high key of every data CI in the data CA. If there are 180 CIs/CA, then the SSI must be sufficiently large to accommodate 180 high keys plus the control information.
The second level IS record contains compressed high keys from each of the SSI records in its scope. Once the IS record is full, another IS record at the same level is created. The KSDS index structure requires that there be one high-level index record for each file. So whenever the second record at the same level is created, then a higher-level index record is created to become the high-level index record. The Relative Byte Address (RBA) of this index record is maintained in the VSAM catalog and is printed out in the index portion of a LISTCAT. An SSI can be the high-level index record for properly defined small files that are one cylinder or less in size. Figure 1 provides a general layout of an index record and the control information for a compressed key.
The index CI contains control information in the first 24 bytes and has a seven-byte VSAM RDF/CIDF at the end. So you lose 31 bytes out of every index CI for control data. The compressed keys and associated key control information have to fit in the remaining space. Each key is compressed from the front and back. The front key compression is easy because it’s a matter of setting up a root key and then every key after that one gets the duplicate digits truncated. Equal value characters are truncated from the front of the key. Back key compression is a little harder to visualize but it’s simply the truncation of non-significant bytes from the end of the key. When regenerating the key, simply copy the eliminated characters from the root key to the front portion of the compressed key and fill out the end of the remaining bytes with X’FF’ to complete the length of the key. This X’FF’ filler indicates that you could add a new key with a higher value than the highest key you previously loaded into the CA but lower than the next key in the next CA. In some cases, the VSAM compression algorithm can compress a key to zero bytes.