- VSAM structures
- VSAM commands
- Performance tuning
- JCL Buffers
- LSR Buffers
- System Buffers
- VSAM parameters
- IAM, a VSAM alternative
- VSAM Recovery
- VSAM RLS, DFSMStvs
There are 4 types of VSAM Dataset, each of these is explained below.
The KSDS is one of the most popular types of VSAM dataset. It consists of at least three components, a CLUSTER definition, which is just a catalog
entry, a DATA component and an INDEX component. It may also have alternate indexes, which are themselves three component KSDS files, and are connected
to the base component by a PATH. The way this lot fits together is illustrated below.
The KSDS is versatile, because it can be read sequentially through the data component, or individual records can be accessed directly through the
index. The way the index works is illustrated below. Data records consist of a primary index, which has to be unique, and data. Records are grouped
together into Control Intervals (CI), which is essentially the blocksize, then into Control Areas (CA). The space in the control interval will include a 3 byte Record Descriptor Field for every record, and one 4 byte Control Interval Descriptor Field. You specify your CI size when you allocate the file, but the CA size is picked by the system.
KSDS records are inserted into a file based on the value of their index key. Records are stored with the lowest key value in the lowest address. When VSAM adds a record to a KSDS file, it must move records around to keep them in index order. To facilitate this, free space is maintained within each CI and most inserts can happen by shuffling records within the CI. If the CI is full, then it is split in half, using the free space that is allocated within a CA. If the CA itself is full, then the CA is split in half, with the higher index records added at the end of the file. This is the origin of the terms CI and CA splits. Generally speaking, the data movement required to perform a CI split, and especially a CA split, has a worse performance impact than the actual presence of splits.
More detail, especially for performance tuning a KSDS can be found in the VSAM tuning Guide
An ESDS is a straightforward sequential dataset. It has a catalog CLUSTER entry and a DATA component, but nothing else. Records are always inserted at the end of the file, and cannot be physically deleted without rewriting the whole file. However records can be logically deleted, and then replaced by another record, as long as that record is the same size as the original. Records can also updated in place, as long as their size remains the same.
An ESDS can have an alternate index, which can be used to locate individual records by their RBA.
The LDS has no fixed internal record information, that is determined by the application. It is used for DB2 databases and SMS control files, among others. It has a CLUSTER and DATA components. If you look at a LDS with LISTCAT, the file will always appear to be empty, as it has no VSAM control information.
The RRDS is included for completeness, but it is rarely used. It is a Direct Access dataset, with the data split up into fixed length slots and is difficult to extend. You can't replace individual records, as the file is not keyed. This means that you cannot load data into the file with the REPLACE option, you have to specify REUSE, which empties the file out first.
It is hard to believe now, in the days of multiple terabye databases, but for many years z/OS file sizes were restricted to a maximum of 4GB. This 4GB limit was a serious restriction for VSAM files and quite a problem when it was reached. Extended Format (VSAM EF) files fixed this issue by adding an extra 32 control bytes to each data block. The main restriction is that VSAM-EF files must be DFSMS managed.
This is an enhancement to VSAM Record Level Sharing (RLS). RLS allowed batch jobs to read VSAM files while online CICS had the files open. This may be adequate for some applications, but other applications require that many tasks can concurrently update a VSAM file, while completely preserving data integrity.
Transactional VSAM Services became available with OS/390 V2.10, and allows VSAM data set sharing between batch and online systems, and between two or more batch jobs. It does this by logging and using two-phase commit and backout protocols at file level. Transactional VSAM uses the Automatic Restart Manager (ARM), so in the case of a system failure, VSAM services will be restarted on another system by ARM.