VSAM Tutorial and Tuning
by Jaqui Lynch
Boston College
Introduction
As VSAM has become a more integral part of the CICS and MVS environments, understanding VSAM and knowing how to tune the subsystem has become more important. This paper provides a brief introduction to VSAM and its file formats and then addresses areas such as file allocation, freespace, cisizes, replicate and imbed, shr options, shared resources, Batch LSR, Hiperbatch, buffer space, CI and CA splits, some miscellaneous options and a tuning methodology. Although the major focus of this paper is VSAM Tuning, the introduction is provided to ensure a common base of knowledge.
VSAM is a high performance access method used to organise data and to maintain information about that data in an index or library called a catalog. There are two major parts to VSAM - a) Catalog management where the catalog maintains information about dasd space and datasets, and b) Record management where VSAM datasets are broken into three types - RRDS, ESDS and KSDS. The prime difference between the different types is the method of storing and retrieving the records.
When you request information from or supply information to VSAM data management, the unit of information transferred is a logical record. VSAM uses a form of blocking called a control interval to contain records and control information. When a record is retrieved, the entire control interval is read into a VSAM I/O buffer in virtual storage. Then the desired record is transferred to a buffer or workarea for the program to use. If the next record to be read is in the same CI then another physical read is not necessary as the record will be in the buffer. CIs are further blocked into control areas that vary in size from 1 track to 1 cylinder.
The following is a list of the types of data that are referred to in VSAM terminology:
Data Portion
This is the portion of the dataset that contains the actual data for the file along with some control information called RDFs and CIDFs.
Index Portion
This is the portion of the dataset that contains the prime keys used to access the data records and the pointer to the associated sequence set CI.
Sequence Set
This is the part of the index that actually points to the CA and CI that contains the record being retrieved. When looking at Index levels, this level is not included in the count provided.
Cluster
The cluster is a combination of the index, sequence set and data portions of the dataset. Whenever a file is allocated to a program to be accessed, it is normally the cluster that is allocated. This gives the program access to everything simultaneously.
Dataspace
Pre ICF catalog systems used dataspaces to manage VSAM files. Basically an area of disk space was reserved for VSAM files and all the VTOC recorded was that a dataspace resided there. With ICF catalogs, this facility was removed and each dataset was an entity in its own right, with information recorded about it in the VTOC, VVDS and the catalog.
Catalog
The catalog contains the names of all datasets in the system, both VSAM and nonVSAM. It is used to access files by merely using their name. The master catalog also contains pointers to all user catalogs and alias names.
Alternate Indexes
An AIX is a file that allows you to access a VSAM dataset by alternate keys to those usually used - i.e. Surname instead of social security number. Alternate keys do not have to be unique, whereas primary keys do. It is basically a KSDS that contains the alternate key and the primary keys associated with it, and is used to determine the primary key to search the base file under.
Path
A path is a file that allows you to access a file by alternate index - it provides the association between the AIX and the base cluster.
Upgrade Set
The upgrade set is the list of all AIXes that VSAM must maintain for a specific base cluster, so that whenever data in the base cluster is updated, the AIX files are also updated.
As stated earlier, VSAM datasets come in three types - KSDS, ESDS and RRDS. Records in a KSDS are stored in key sequence with each key being unique and records being inserted in collating sequence by key. Records can be accessed by key or RBA, and records can be inserted or deleted. A KSDS can also use spanned records and can have an AIX. The index for a KSDS has multiple levels, the lowest of which is the sequence set. Each level contains pointers to the next lowest level until the sequence set. There is one sequence set per CA. It gives the location of data CIS and consists of the highest key in the CI plus a pointer to the CI. Records in an ESDS are stored in the order they are entered and are accessed by RBA. The RBA of a record cannot change but records can be added to the end of the file. Thus records cannot be deleted or inserted without recreating the dataset. IT is possible to use spanned records and to create AIXes for these files. The ESDS consists of a data portion and a sequence set. Records in an RRDS are stored in relative record number order and are accessed directly by RRN. Records are stored in fixed lebgth slots and a hashing algorithm is used to determine the RRN for a record, based on its key. Deleted record slots can be reused, but you cannot have AIXes or spanned records.
With that brief introduction to VSAM, this paper will now move on to discuss defining VSAM files for performance and tuning files currently set up. To a certain extent this requires a choice of tradeoffs - performance versus DASD space, and program performance versus resource (CPU, storage...) usage. There is also a considerable investment in resources required, both human and machine time. Tuning should be an ongoing process with a pre-defined methodology, not just a fix for deteriorating performance.
The basic methodology used for tuning is:
a) Setting objectives
b) Monitoring current performance
c) Implementing changes
d) Reviewing the impact of the changes
e) Interpreting and documenting
Before embarking on a VSAM Tuning exercise it pays to make sure that MVS is reasonably well tuned. There is no point in tuning one file when MVS and CICS are themselves constrained or poorly tuned. Remember it pays to take a top down approach and to change the simple and often obvious things first. The 20/80 rule is well worth remembering.
File Allocation
Use of Cylinders
Whenever possible use cylinders for data. This allows the use of multitrack channel programs, which require fewer excps, and assists with CA preformat. If allocation is done in cylinders, then the CAsize is always 1 cylinder, and this helps any CI splits go faster as the heads are positioned over that cylinder.
Use of cylinders has the following benefits:
The major disadvantage of allocating in cylinders is that CA splits will take longer. However, be aware that usage of a small data CIsize and a large CAsize can cause an oversized index CIsize, and the reverse can cause an underutilized index CI.
Extents
To avoid DASD fragmentation and seek activity, it is important to keep the number of extents to a minimum, preferably one. This is particularly important for the index. If there are a lot of splits it is important to reorganize the files to reduce the seek activity as logical and physical order will no longer be the same. It is also important that any extent request can be allocated in 5 or fewer extents, otherwise the define will fail or strange errors will occur later. It is important to remember that VSAM will allow you to have 123 extents per file, so this is something that must be monitored.
Keyranges
If there is a large on-line environment it may be advisable to define data across volumes depending on Keyranges. This puts ranges of keys and the data on certain packs. Be certain that backups and restores are synchronized though.
Freespace
Freespace is specified as Freespace(a b), where a is the percentage of freespace in each CI and b is the percent of free CIs in each CA. Use of freespace reduces CI/CA splits if used properly. Insufficient or excessive freespace can degrade performance and overutilize DASD. If there is insufficient freespace, then CI/CA splits will degrade sequential processing as the dataset will not be stored in physical sequence. An excessive amount will cause DASD space to be wasted due to the reduction of the effective blocking factor of the data. Also, extra I/O will be required to transfer partially filled CIs in sequential processing.
When allocating freespace ensure that the record size plus the length of RDFs and CIDFs is taken into account. If there is an even distribution of inserts then it is best to specify the majority as CI freespace and a little CA freespace. If it is uneven then a little CI freespace and a lot of CA freespace.
CI Sizes
Small data cisizes reduce wasted data transfers as VSAM always reads a CI. If processing is random or dynamic, a large CI is hopelessly inefficient and, for on-line, is very bad for response. For files primarily accessed by CICS, the best data CIsizes are 2k or 4k. When using a large CISZ , I/O operations are reduced if multiples of 4096 are used. Also note that on CKD, CIs are stored as physical records with inter record gaps, which should be taken into account when estimating response times. For direct access on-line files, a CISZ such as 2k or 4k should be used, and for sequential/mixed access a larger CISZ should be used.
Care should be taken that the CISZ chosen won't result in lots of unused space due to record length - If the CISZ is 2048 and the record length is 700 then only 1400 bytes can be used for data, 10 for CIDFs and RDFs, and the last 598 bytes will be wasted. A CIDF is 4 bytes and there is one per CI, and an RDF is 3 bytes. For fixed length there are 2 RDFs per CI, and for variable, the worst case is 1 RDF per record.
Do not allow the index CISZ to default if LSR pools are being used, or if the keys for the index have a bad compression ratio (front or rear). For LSR pools ensure that the Index CIs are not going into the same pools as the data. Keep in mind that large a CISZ and a large CASZ will require fewer index records.
Replicate and Imbed
Without replicate and imbed, data CAs and CIs can be stored in different places on the disk from the index. This means that several I/Os are required for each access.
With Imbed and noreplicate, each data CA has its sequence set record at the front of the CA. If the CASZ is 1 cylinder then the sequence set is maintained on the 1st track of the cylinder. If the CASZ is less than 1 cylinder then one track is added to the CASZ. Thus, it costs 1 track per CA as the sequence set is written around the track as often as possible. Rotational delay is reduced as the r/w arm is placed above the sequence set and data. However, index updates cause an overhead as each copy of the sequence set has to be updated. Sequential processing benefits immensely from Imbed.
With replicate and noimbed, all data CAs and indexes are separate. Each higher level index is written as often as possible on a track. This option uses a lot of extra space and also requires extra I/O for index updates. If using this option the index should be allocated in cylinders and imbed should also be used. Better value can be obtained from the judicious choice of buffers. Since sequential processing only uses the sequence set, then replicate is of no value for sequential processing.
In general, imbed alone should be used, and then only for active datasets that are allocated in cylinders and are bigger than 20 or so cylinders. The general recommendation is that Replicate should rarely be used and then only with Imbed. Replicate and Imbed should not be used with SCD or cache as it will waste space on the SCD or in the cache.
Shroptions
Shroptions are not only an integrity parameter, but also a performance one. Normally shr(1,3) is used for files and (2,3) for AIXs and files that have AIXs or need to be shared. Shr(3) is an option that leaves integrity up to the coders, and shr(4) is a performance killer.
With shr(4) limitations are placed on the files in an attempt to help: jobs can't add to the end of the file(no appends, new extents or new CAs), there can be no CAsplits, the CI containing the high-key RBA can't split and enqs and deqs must be issued to maintain integrity. The file also can't take advantage of VSAM readahead or buffers, as the buffers for the data and sequence set are always refreshed if the file is opened for direct processing.
Shared Resources
Until ESA, shared resources were only available in certain applications such as CICS, now there are also the options of Hiperbatch and Batch LSR. Local Shared Resources allows for the concurrent use by multiple VSAM datasets of control blocks and buffers, thus reducing the total Virtual Storage required and the number of I/Os. A bufferpool is built and buffers are allocated to datasets as required. Virtual storage is reduced because one pool of channel programs, I/O control blocks and buffers is shared among all VSAM datasets. This can help reduce paging, if the processor is storage constrained.
LSR does not always result in less I/O. Datasets with the same CISZ can share the same bufferpool. The buffer will always be checked for each I/O request before getting a CI from DASD (Buffer lookaside). If the index and data cisizes are not isolated, then data will be forever forcing out the index buffers and I/O will be done anyway. It is also important that pool sizes are set to actual CIsizes for the files. VSAM will use any buffer pool that equals the CI size or, failing that, any that are larger. This can cause wasted space. If the LSR pool is big enough then Imbed and Replicate should be avoided as they can slow down the rewriting of the index records if a CI or CA split occurs.
LSR is designed to support multiple medium to low activity datasets with the same pool of buffers. Don't mix extremely volatile files into pools with other files as the buffers will be refreshed too often. Sequential processing doesn't perform as well, because sequential readahead is not permitted. VSAM readahead is only available for a KSDS if it is NSR, as LSR will only read one CI at a time. The first browser benefits the most, as he gets all spare data buffers until he finishes. High browse activity CICS files should be NSR so they can use VSAM readahead. Transactions that do "get for update" without ending browse should also use NSR, as lockouts will occur if LSR is used.
While allocation of buffers increases the probability that an I/O request for a CI will be found, excessive allocation will increase the requirements for Virtual Storage and CPU Utilization to manage the buffer pools. (An LRU algorithm is used to manage the buffers.) Careful monitoring of CICS statistics (buffer waits, etc) is needed to avoid this.
Buffer Space
There are three places that bufferspace can be coded - on the JCL AMP=, in the program's ACB and in the define. That is also the order in which they are searched. Coding on the JCL gives far more flexibility as it is easier to change. Use the Bufni and Bufnd options rather than Bufsp. When Bufsp is used, the way the buffers are allocated depends on options specified at open time. Remember to increase region size if using buffering or your programs will abend.
Use of excessive buffers can result in paging if the processor is real storage constrained, and may negate the effects of VSAM readahead. It can also increase CPU utilization due to the overhead of managing the buffers. As each bufferpool begins on a page boundary that sufficient buffers be allocated to fill a page (4096k) in MVS.
Be careful using buffers in CICS as VSAM tries to use all buffers before reusing any. With too many buffers, page faults may occur which kills CICS response. It is better to allow a few buffer waits (these lock out 1 user) as a page fault locks out the whole region.
With Bufni, the first buffer is assigned to the sequence set, but it can be overwritten by other index records.
Some basic calculations:
CI and CA Splits
When a CI is full there is no room for a new record that is to be inserted, a CI split is performed. Half of the CI is left behind and the other half is moved to a never-before-used CI in the same CA. RDFs and CIDFs are also taken care of. This operation will take place in buffers if they are available, but physical I/O is still required. If a CA or the sequence set fills up, a CA split is caused. The sequence set will cause this to happen even if the CA is almost empty. If the file is allocated in cylinders then the CA splits will be reading and writing a cylinder at a time. A CA split does not reorganize the CIs so they will be in a different logical and physical sequence.
A CI split causes I/O to the index, sequence set (read), old CI, new CI and a sequence set update. A CA split causes at least 5 I/Os - each CI in the new CA is formatted, the sequence set is created, the index set is updated and half the CIs are moved one at a time. Each CI requires 1 I/O. The catalog is also updated and allocation processing takes place. On top of this any AIX's in the upgrade set will be updated.
In order, from best to worst, the scenarios are: no CI or CA splits, CI splits, CA splits, CA splits that require secondary extents (needs I/O to the catalogue, Vtoc and VVDS).
ESA Related Topics - Hiperbatch, Batch LSR, CAS and CICS/ESA
Catalog Management
There are several major changes that affect VSAM performance in the ESA environment. The internal structure of the BCS and VVDS change so that SMS can be implemented and temporary VSAM datasets can now be used. One item that can have a very negative impact on performance is the use of multi-level aliases (up to 4 levels). Modifying this parameter once it has been set up can result in down-time and performance problems while datasets are redistributed.
The In-Storage catalog mechanism within the Catalog Address Space is now optional and can be activated and deactivated via the modify command. Selected records can now also be cached into a catalog data space cache instead of ISC.
Hiperbatch and Batch LSR
Batch LSR and Hiperbatch are implemented via apar OY24097 and provide a performance boost for direct or random processing. Batch LSR enables the implementation of VSAM LSR to any application. It requires that the BLSR subsystem be defined and that JCL be modified. If Hiperspace buffers are used then it is recommended that the job be made nonswappable, as the buffers are ESO (expanded storage only) and are not backed by DASD, so the Hiperspace would be lost if the job was swapped out.
Hiperbatch permits the retention and sharing in ESO Hiperspaces of QSAM and VSAM files. There are two types of Hiperbatch Hiperspaces - retained and nonretained, each one having its own method of population and deactivation. Hiperbatch is only available for QSAM sequential and VSAM NSR sequential processing and datasets are made eligible for processing using either DLF or RACF 1.9. Hiperbatch should not be used for files that will be updated by more than one CICS or by CICS and Batch at the same time, as integrity cannot be ensured.
CICS
It is now possible to have multiple LSR pools and can dedicate specific pools to indexes. Wherever possible, 4k CIsizes should be used as there is now a Hiperspace LSR buffer which is addressed in 4K units. This buffer is defined in the FCT and is a fixed area of expanded storage set aside to page LSR buffers so that they don't page to disk. This is extremely useful for datasets with a high locality of reference and high read activity. Shr(4) files should still use NSR.
CICS Data tables allow loading the contents of a VSAM file into storage and accessing it there. This is only effective for files accessed via full key direct reads. Entry Q500334 in IBMINFO discusses the fact that the pathlength to satisfy fullkey reads is reduced to 1/5 that of LSR buffers when using data tables. For LSR it is about 5.5K, and for Data Tables it is 1K. Hiperspace is expected to also be about 1K.
Miscellaneous Options and Parameters
Erase
Overwrites the dataset with binary zeroes when it is deleted. It increases the time required for a delete and should only be used where absolute security is needed.
Mass Inserts
This is the most efficient mode to use, and causes VSAM to be in sequential mode when inserting many records into a KSDS. The physical write of a record is delayed until the CI is filled and freespace is maintained. Also splits occur at the point of insertion rather than the middle of the CI, and subsequent splits are avoided as only free CIs are used if sequential mode continues.
Alternate Indexes
Eliminate the use of AIXs with frequently updated base clusters. Whenever the base is updated, all the indexes need modification and this causes I/O - at least 2 extra I/O operations per AIX whenever a key is added, deleted or changed in the base. At least keep the number of AIXs to a minimum. It is also important to note that AIXs that are opened via the path will not be implicitly verified by DFP.
Enqs
When a gethold of any form is performed, be aware that VSAM enqs on the CI, and thus the whole CI is unavailable to others the whole time the enq is valid. It pays to issue enqs as late as possible and deqs as early as possible.
Writecheck
Adds a full rotation per I/O, as a device does a full rotation and rereads each previously written record. This is no longer a default as current technology is far superior to the 2314s it was initially designed to work on.
Speed/Recovery
Recovery causes each CA to be preformatted before use with "end-of-file" records. This CA preformat allows the reload to restart at the point of failure. Speed reduces I/O by eliminating this CA preformat. This option only applies to the initial load of the file, as VSAM always processes in recovery mode after loading. A significant performance boost is gained at load time by changing from the default of recovery to speed for the data component.
Seed Records
Don't initialize files with a high values record as this has been shown to cause many splits. A low values record is better.
Monitoring
If a file is open to CICS, the information on the file in the catalog is not updated until the file is closed. If CICS fails, then the information is not updated and will be incorrect until the file is reloaded. This is important to keep in mind when monitoring VSAM files as it is important to know whether the catalog statistics being reviewed are valid, or not. The following details some of the fields in the Listcat to monitor and some simple calculations that can be used. It is also possible to calculate an I/O factor for a file to monitor changes - this is done by doing a Listcat before CICS or the job runs and another straight after and performing the following calculations: Using the before and after listings, subtract the before value from the after value for records retrieved, records deleted, and records updated, and add the differences together to get an activity total - also subtract the before excps from the after excps. Now divide the excps by the activity total to get the I/O factor. The I/O factor should be less than 1.
Fields to Watch
Summary
With the advent of DFP and on-line applications, VSAM has become an integral part of the operating system. Judicious use of certain parameters can cause a major variation in performance seen and can lead to dramatic improvements in response time. Specific areas that give major benefits include controlling CA and CI sizes, controlling extents, use of imbed, correct use of freespace, correct buffering and use of shared resources, use of speed instead of recovery and avoiding splits. The most important lesson to learn is that the defaults may not be what is desired, and that VSAM files need to be monitored carefully.
References
GG22-1295 VSAM Performance Guidelines
GC28-1059 Batch LSR
GG66-3176 Comparisons of DTR and LSR
Xephon VSAM Yearbook 1989
Practical VSAM for Today's Programmers - Janossy and Guzik
CMG Australia paper (1989) on VSAM Tuning by Jaqui Lynch
Various Apars from IBM
OY07931 VSAM LSR CPU reductions
Q500334 Discussion on Datatables path lengths
OY28155 Hiperbatch Monitor
OY24097 Implements Batch LSR
Compiled and edited by Jaqui Lynch
Last revised June 5, 1995