VSAM Files
Learn Virtual Storage Access Method (VSAM) at a conceptual level — KSDS, ESDS, and RRDS — and why VSAM matters for fast, indexed data access.
Introduction
You have now seen sequential datasets, built for ordered, start-to-finish processing, and partitioned datasets, built for organizing named members. Neither is well suited to a very common real-world need: quickly finding one specific record among millions, by a key, without reading everything before it. That is exactly the problem VSAM was built to solve, and it underpins a huge amount of mainframe application data, including data accessed through CICS transactions, which you will study later in this course.
What is VSAM?
VSAM stands for Virtual Storage Access Method. It is not a single dataset type but a family of access methods and dataset structures, all built around enabling fast, flexible access to records — including direct/random access — rather than only sequential, start-to-finish access. VSAM datasets are managed through their own catalog structure and are defined and manipulated with a utility called IDCAMS, which you will see referenced constantly in real-world JCL once you reach that part of the course.
VSAM is a family of mainframe dataset structures built for fast, often indexed, access to records — letting a program jump directly to the record it needs, rather than only reading sequentially from the start.
Why VSAM Exists
Recall the limitation from the sequential datasets lesson: finding one specific record requires reading everything before it, in order. That is completely impractical for applications that need to look up individual records quickly and unpredictably — for example, a bank teller application pulling up one customer's account by account number out of millions of accounts. VSAM solves this by maintaining index structures (for key-based types) or supporting other efficient access patterns, so a program can go essentially straight to the record it needs.
KSDS: Key-Sequenced Data Set
A KSDS (Key-Sequenced Data Set) is the most commonly used VSAM type. Every record has a defined key field, and VSAM automatically maintains an index on that key, so records can be retrieved directly by key value, in addition to being readable sequentially in key order. This is conceptually similar to an indexed table in a relational database, and it is exactly the kind of structure that supports fast account or customer lookups.
//DEFKSDS EXEC PGM=IDCAMS//SYSPRINT DD SYSOUT=*//SYSIN DD * DEFINE CLUSTER (NAME(STUDENT1.ACCOUNTS.KSDS) - INDEXED - KEYS(10 0) - RECORDSIZE(200 200) - VOLUMES(USER01) - TRACKS(10 5) )/*Click Run to see what this code prints.
ESDS: Entry-Sequenced Data Set
An ESDS (Entry-Sequenced Data Set) stores records in the order they were written (their entry order), similar in spirit to a sequential dataset, but records can also be accessed directly using a relative byte address (RBA) that VSAM assigns to each record when it is written. New records are always added at the end, and existing records generally are not deleted or reordered. ESDS is well suited to append-only logs and audit trails where write order matters and lookups can be done via a previously recorded address.
RRDS: Relative Record Data Set
An RRDS (Relative Record Data Set) stores fixed-size "slots," each identified by a relative record number (essentially, its position — slot 1, slot 2, slot 3, and so on). A program can go directly to a specific slot by number, which makes RRDS extremely fast for applications that naturally work with numbered positions, such as looking up a record by a sequential ticket or seat number.
| VSAM Type | Access Pattern | Typical Use |
|---|---|---|
| KSDS | Direct access by key, or sequential in key order | Customer/account master files, anything looked up by a business key |
| ESDS | Sequential by entry order, or direct via relative byte address (RBA) | Append-only logs, audit trails |
| RRDS | Direct access by relative record number (slot number) | Fixed-slot lookups, such as numbered positions or tickets |
Choosing Between Them
- Need to find records by a meaningful business key (account number, customer ID)? Use KSDS.
- Need an append-only, order-preserving log, with lookups only via a previously known address? Consider ESDS.
- Need fast access purely by numbered position, with no meaningful business key? Consider RRDS.
- Need simple, ordered, start-to-finish processing with no random lookups at all? You likely do not need VSAM — a plain sequential dataset (from two lessons ago) may be the simpler, appropriate choice.
VSAM in the Bigger Picture
VSAM, and KSDS in particular, is foundational to a large share of real-time mainframe application data. When you study CICS later in this course, you will see that many CICS transactions read and update VSAM files directly as their data store, which is exactly why fast, key-based access matters so much: an online transaction needs its data now, not after scanning a million records.
Common Mistakes
- Reaching for VSAM by default even when a simple sequential dataset would do the job — VSAM adds real complexity that should be justified by an actual need for direct/random access.
- Confusing KSDS, ESDS, and RRDS — each is suited to a distinctly different access pattern, and picking the wrong one leads to awkward, inefficient application design.
- Forgetting that VSAM datasets are defined and managed differently from non-VSAM datasets, typically through IDCAMS rather than the simpler dataset utilities used for sequential or PDS datasets.
- Assuming VSAM is a single dataset "type" rather than a family of related structures (KSDS, ESDS, RRDS) with different behavior.
Best Practices
- Choose the VSAM type based on the actual access pattern your application needs, not habit — KSDS for key lookups, ESDS for append-only logs, RRDS for slot-number access.
- Plan key definitions (position and length) carefully for a KSDS — changing them later is far more disruptive than getting them right at design time.
- Understand that VSAM datasets underlie much of the real-time data behind CICS transactions, so VSAM concepts will resurface when you study CICS.
- Use IDCAMS documentation and shop standards when defining VSAM clusters — parameters like key length, record size, and space allocation all affect performance.
Frequently Asked Questions
Virtual Storage Access Method. It is a family of mainframe dataset structures and access methods built for fast, often indexed, access to records, rather than only sequential, start-to-finish access.
KSDS (Key-Sequenced Data Set) is generally the most widely used VSAM type, since it supports fast direct lookup by a meaningful business key, such as an account or customer number.
No. VSAM is a dataset structure and access method built into z/OS itself, while DB2 (covered later in this course) is a full relational database management system. In practice, DB2 itself relies on lower-level storage services, and many applications use VSAM directly for simpler, high-performance indexed data needs.
When your processing is genuinely simple, ordered, start-to-finish work with no need for direct/random lookups — a plain sequential dataset is simpler to define and manage, and is the more appropriate choice in that case.
Key Takeaways
- VSAM (Virtual Storage Access Method) is a family of dataset structures built for fast, often indexed, record access.
- KSDS (Key-Sequenced Data Set) supports direct lookup by a defined key, and is the most commonly used VSAM type.
- ESDS (Entry-Sequenced Data Set) preserves write order and supports access via relative byte address, suiting append-only logs.
- RRDS (Relative Record Data Set) supports direct access by relative record (slot) number.
- VSAM datasets, especially KSDS, underlie much of the real-time data accessed by CICS transactions, a topic covered later in this course.
Summary
VSAM fills the gap that sequential and partitioned datasets cannot: fast, flexible, often indexed access to individual records, which is essential for the kind of real-time lookups mainframe applications perform constantly. With sequential, partitioned, and VSAM datasets now covered, you understand the major ways data is organized on the mainframe. In the final lesson of this batch, you will look at dataset naming conventions — the dotted-qualifier scheme, like PROD.PAYROLL.DATA, and the naming standards real shops use to keep enormous numbers of datasets organized and understandable.