CICS® supports access to the following types of data set:
VSAM data sets are held on direct access storage devices (DASD) auxiliary storage. VSAM divides its data set storage into control areas (CA), which are further divided into control intervals (CI). Control intervals are the unit of data transmission between virtual and auxiliary storage. Each one is of fixed size and, in general, contains a number of records. A KSDS or ESDS can have records that extend over more than one control interval. These are called spanned records.
A key-sequenced data set has each of its records identified by a key. (The key of each record is simply a field in a predefined position within the record.) Each key must be unique in the data set.
When the data set is initially loaded with data, or when new records are added, the logical order of the records depends on the collating sequence of the key field. This also fixes the order in which you retrieve records when you browse through the data set.
To find the physical location of a record in a KSDS, VSAM creates and maintains an index. This relates the key of each record to the record’s relative location in the data set. When you add or delete records, this index is updated accordingly.
With releases of DFSMS/MVS 1.4 and later, a data set can be greater than 4GB in size if it is defined as extended format and extended addressability in the storage class. CICS supports, in both RL and non-RLS mode, KSDS data sets that are defined with these extended attributes.
An entry-sequenced data set is one in which each record is identified by its relative byte address (RBA).
Records are held in an ESDS in the order in which they were first loaded into the data set. New records added to an ESDS always go after the last record in the data set. You may not delete records or alter their lengths. After a record has been stored in an ESDS, its RBA remains constant. When browsing, records are retrieved in the order in which they were added to the data set.
With releases of DFSMS/MVS 1.5 and later, a data set can be greater
than 4 GB in size if it is defined as extended format and extended
addressability in the storage class. However, CICS does not support
ESDS data sets that are defined with these extended attributes. Attempts
to open data sets defined with the extended attribute fail with error
message DFHFC0966, codes 8504, 0008, and 0068 for non-RLS
access and message DFHFC0905 for RLS access.
A relative record data set has records that are identified by their relative record number (RRN). The first record in the data set is RRN 1, the second is RRN 2, and so on.
Records in an RRDS can be fixed or variable length records, and the way in which VSAM handles the data depends on whether the data set is a fixed or variable RRDS. A fixed RRDS has fixed-length slots predefined to VSAM, into which records are stored. The length of a record on a fixed RRDS is always equal to the size of the slot. VSAM locates records in a fixed RRDS by multiplying the slot size by the RRN (which you supply on the file control request), to calculate the byte offset from the start of the data set.
A variable RRDS, on the other hand, can accept records of any length up to the maximum for the data set. In a variable RRDS VSAM locates the records by means of an index.
A fixed RRDS generally offers better performance. A variable RRDS offers greater function.
With releases of DFSMS/MVS 1.5 and later, a data set can be greater
than 4 GB in size if it is defined as extended format and extended
addressability in the storage class. CICS supports access
to extended RRDS or VRRDS datasets if you use an RRN that can be specified
in a four-byte RRN field to access the records that reside beyond
the 4 GB boundary.
An empty data set is a data set that has not yet had any records written to it. VSAM imposes several restrictions on an empty data set that is opened in non-RLS access mode. However, CICS hides all these restrictions from you, allowing you to use an empty data set in the same way as a data set that contains data, regardless of the access mode.
Sometimes you want to access the same set of records in different ways. For example, you may have records in a personnel data set that have as their key an employee number. No matter how many Smiths you have, each of them has a unique employee number. Think of this as the primary key.
If you were producing a telephone directory from the data set, you would want to list people by name rather than by employee number. You can identify records in a data set with a secondary (alternate) key instead of the primary key described above. So the primary key is the employee number, and the employee name is the alternate key. Alternate keys are just like the primary key in a KSDS--fields of fixed length and fixed position within the record. You can have any number of alternate keys per base file and, unlike the primary or base key, alternate keys need not be unique.
To continue the personnel example, the employee’s department code might be defined as a further alternate key.
VSAM allows KSDS and ESDS (but not RRDS) data sets to have alternate keys. When the data set is created, one secondary or alternate index is built for each alternate key in the record and is related to the primary or base key. To access records using an alternate key, you must define a further VSAM object, an alternate index path. The path then behaves as if it were a KSDS in which records are accessed using the alternate key.
When you update a record by way of a path, the corresponding alternate index is updated to reflect the change. However, if you update the record directly by way of the base, or by a different path, the alternate index is only updated if it has been defined to VSAM (when created) to belong to the upgrade set of the base data set. For most applications, you probably want your alternate index to be in the upgrade set.
A CICS application program disregards whether the file it is accessing is a path or the base. In a running CICS system, access to a single base data set can be made by way of the base and by any of the paths defined to it, if each access route is defined in the file control table (FCT).
It is also possible for a CICS application program to access a file that has been directly defined as an alternate index rather than a path. This results in index data being returned to the application program rather than file data. This operation is not supported for files opened in record-level sharing (RLS) mode.
Record-level sharing (RLS) is a VSAM function, provided by DFSMS Version 1 Release 3 and later releases, that enables VSAM data to be shared, with full update capability, between many applications running in many CICS regions.
With RLS, CICS regions that share VSAM data sets can reside in one or more MVS™ images within an MVS parallel sysplex. RLS also provides some benefits when data sets are being shared between CICS regions and batch jobs.
If you open a file in RLS mode, locking takes place at the record level instead of the Control-Interval level, thus reducing the risk of deadlocks.
CICS supports record-level sharing (RLS) access to the following types of VSAM data set:
Most types of data set are eligible to participate in VSAM record level sharing and most CICS applications can benefit from this mode of access. However, there are some limitations that could affect some applications. The following types of file, data set, or method of access are not supported in RLS mode: