A basic description of how the VSAM file system works, including design and maintenance of your VSAM datasets.
Text of Basic VSAM
1. VSAM: The Course guide By Dan O'Dea Updated for zOS April 28, 2003
2. 2 VSAM: Virtual Storage Access Method What Is It and What Do I Need to Know About It? The Basic Structure of VSAM VSAM has four types of files: ESDS, Entry Sequenced DataSets, replace sequential files; RRDS, Relative Record DataSets, replace direct access files; KSDS, Key Sequence DataSets, replace ISAM indexed files; LDS, Linear DataSets, designed to be a replacement for partitioned files (PDSes) and are the file types used for DB2 databases. We'll talk about each of these in turn. The LDS is covered first because the DB2 organization takes precedence. The LDS The LDS is similar to an ESDS processed at the CI level. VSAM treats an LDS as unformatted blocks in 4K CIs. A cluster component is defined over the single data component to provide a common structure for file access. VSAM does not support record-level access for an LDS. If record-level processing is attempted, an error results. COBOL does not support LDSes. These access modes apply to LDSes: CI access is the only access allowed. The CI can be addressed by RBA or sequentially. VSAM treats all bytes in the CI as data bytes. The application is solely responsible for managing the data; Sequential processing can be forward or backward; Direct processing can be used if the relative byte address (RBA) for a specific CI is known. VSAM can return the RBA of a CI when the record is initially written to the file. Alternate indexes cannot be built over an LDS. All bytes of a CI are considered data. When the CI is retrieved, the application is free to handle the data as it sees fit. From VSAM's point of view, the CI is simply rewritten back where it was in the file. An LDS can be used as a reusable work file.
3. 3 The ESDS The ESDS is almost the same as a sequential access file, with the addition of alternate index support providing keyed access to sequential data records. A VSAM ESDS requires more overhead than a QSAM file, but requires less time to perform an I/O. If I/O time is not an issue, there is no need to pay for the extra CPU overhead. An ESDS is a single data component containing data records. A cluster component is defined over the data component to provide a common structure for file access. These are the capabilities and limitations of an ESDS: Sequential processing, either forward or backward; Direct processing via a relative byte address (RBA). VSAM can be asked to return the RBA of a record when it is first written; Direct processing by key using an alternate index. The records can be retrieved either directly with the key, or sequentially in alternate key order. Alternate indexes (AIXes) can be built over the VSAM ESDS, allowing all the expected capabilities of using keyed access. Up to 255 AIXes can be built over a single ESDS. These indexes can be either unique or non-unique. COBOL does not formally support the alternate index. However, if you force access to the ESDS using its AIX, COBOL treats the file as if it were a KSDS. The file cannot then be read in its normal sequential order by the program. The following update capabilities and limitations are features of the ESDS: Existing records can be updated and rewritten back to their original position as long as the record length has not changed; New records are written at the end of the file. New records cannot be inserted among existing records; Records cannot be physically deleted. To reclaim space from logically deleted records, the file must be reloaded. Free space in an ESDS has no meaning, because records cannot be deleted or change in length. It is ignored by AMS when defining the file. ESDS files can be defined as reusable work files. For more information on reusability, see The Complete Source Book for VSAM File Structures cited in the bibliography.
4. 4 The RRDS The RRDS is almost the same as a BDAM file. Like the ESDS, the RRDS is not in common use for several reasons. In addition to the lack of familiarity with RRDSes, there is the question of resource use. While a VSAM RRDS requires more overhead than a BDAM file, it requires less time to perform an I/O. If I/O time is not a consideration, there is no need to pay for the extra CPU overhead. In addition, a BDAM file takes less disk space than an RRDS. An RRDS with a fixed record length has a single data component containing the data records. A cluster component is defined over the data component to provide a common structure for file access. Records are referenced using a logical numbering scheme. An RRDS with a variable record length looks just like a KSDS, with a data and index component. In a variable-length RRDS, records are prefixed by a VSAM- created record number. When you look at a catalog listing, the record length is four bytes greater than you expect. The number field is not accessible by a programmer, but a record may be referenced by its record number. An RRDS is usually accessed directly, using the record number. It can also be read in relative record number sequence. VSAM returns the record number with any access if requested. Alternate indexes cannot be built over an RRDS. The following update capabilities and limitations are features of the RRDS: Existing records can be updated and rewritten back to their original position. The record length can be changed if the file was defined with a variable record size; New records can be written to any record slot not currently holding a record; Records can be deleted. For a fixed-length RRDS, VSAM rewrites the slot with binary 0s. For a variable-length RRDS, VSAM deletes the record as if the file were a KSDS. Free space in a fixed-length RRDS has no meaning. In a variable-length RRDS, free space functions as it does in a KSDS. RRDS files can be used as reusable work files.
5. 5 The KSDS A KSDS has two components: a data component containing the data records, and an index component. The index component is built and maintained by VSAM to provide random access to the data component. A cluster component is defined over the data and index components to provide a common structure for file access. Below are the capabilities and limitations of a KSDS: Direct processing by key, using the normal index or an alternate index; Sequential processing, either forward or backward, in key order; Direct processing via an RBA. VSAM can return the RBA of a record when the record is first written. Alternate indexes (AIXes) can be built over the KSDS, allowing all the normal capabilities of using keyed access. Up to 255 AIXes can be built over a single KSDS. These indexes can be either unique or non-unique. The following types of update processing can occur with a KSDS: Existing records can be updated and replaced in their original position. The length of the existing record can be changed as long as it's not larger than the files maximum record length. When a record is made shorter, records to the right are shifted left to reclaim the free space created by the changed record length. When a record is made longer, records to the right are shifted right. If there's not enough free space to the right a CI split, and possibly a CA (control area) split, occurs. CI and CA splits are discussed later; New records can be written anywhere in the file, with the key determining where the record goes. When records are inserted between existing records and there's not enough free space, CI and maybe CA splits occur to fit the new record. If records are being inserted at the end of a file, free space is reserved as records are added (a "resume load"); Records can be physically deleted, causing free space to be reclaimed by shifting records to fill the gap(s) in the CI. If a CI is totally emptied by delete requests, VSAM marks the CI as "free." It can then be used as a candidate for future CI splits. KSDS files can be used as reusable work files.
6. 6 VSAM Record Blocking Concepts VSAM uses a double blocking system. First, user data records are collected into appropriately sized logical blocks called Control Intervals (CI). The CIs are then broken down to physical blocks. These physical blocks are always a multiple of 512 bytes. For example, a file with 200-byte records could be put into a VSAM file with a CI size of 2,048 bytes, using about 97% of the data space. The data is then written as a single block of 2,048 bytes. The process works in reverse during a read. VSAM handles all blocking and deblocking of records, totally hidden from the user program. In the appendices, I have included a list of allowable CI sizes, their physical record sizes, and other information on how VSAM stores data on 3390 DASD. The user should pick a CI size matching the data record size and application processing needs. VSAM selects the correct physical record size to maxim