VSAM supports four dataset types: KSDS, ESDS, RRDS, and LDS. Each type organizes and addresses data differently. Choosing the right one affects whether you can access by key or by position, whether you can insert and delete, and how much structure VSAM imposes. This page compares all four side-by-side so you can see how they differ in components, addressability, insert and delete behavior, and typical use. The goal is to give you a clear picture before you define a cluster or design an application.
When you define a VSAM cluster with IDCAMS, you choose an organization: INDEXED (KSDS), NONINDEXED (ESDS), NUMBERED (RRDS), or LINEAR (LDS). That choice is fixed for the life of the dataset. You cannot turn an ESDS into a KSDS or add a key to an RRDS later. So understanding the differences up front helps you avoid the wrong type. A side-by-side comparison highlights what each type offers: KSDS gives you key-based access and key order; ESDS gives you write order and RBA; RRDS gives you slot-based access; LDS gives you a raw byte stream for products like Db2.
The table below summarizes the main attributes of each type. "Addressability" means how you identify a record (or, for LDS, a region of bytes). "Insert" and "Delete" describe whether the type supports adding records in the middle and removing records physically.
| Aspect | KSDS | ESDS | RRDS | LDS |
|---|---|---|---|---|
| Full name | Key-Sequenced Data Set | Entry-Sequenced Data Set | Relative Record Data Set | Linear Data Set |
| Components | Data + index (sequence set, index set) | Data only | Data only (fixed RRDS); data + index (VRRDS) | Data only; no CI record structure |
| Record order | Ascending key order | Order written (entry sequence) | By slot (RRN 1, 2, 3, …) | N/A (no records) |
| Addressability | Primary key (unique) | Relative byte address (RBA) | Relative record number (RRN) | Byte offset (page/sector) |
| Insert | Yes; in key order; may trigger CI/CA split | Append only at end | Yes; into slot or new RRN (VRRDS) | N/A; application writes bytes |
| Delete | Yes; physical delete; space can be reused | No physical delete; logical delete only | Yes; slot freed (REUSE) | N/A |
| Update in place | Yes (REWRITE) | Yes (REWRITE at same RBA) | Yes (REWRITE in same slot) | Application-managed |
| Record length | Fixed or variable | Fixed or variable | Fixed (fixed RRDS); variable (VRRDS) | No record structure |
| Typical use | Master files, lookups by key, key-ordered batch | Logs, audit trails, append-only streams | Position-based files, fixed-length slots | Db2, system storage, byte streams |
Sequential access means reading (or writing) in a fixed order: for KSDS that order is key order; for ESDS it is entry order; for RRDS it is RRN order. Random access means going directly to one record (or byte range) without reading from the start. Dynamic access means mixing sequential and random in the same open file. The following table shows which modes each type supports.
| Type | Sequential | Random | Dynamic |
|---|---|---|---|
| KSDS | Yes (key order) | Yes (by key) | Yes |
| ESDS | Yes (entry order) | By RBA only | Yes |
| RRDS | Yes (RRN order) | By RRN | Yes |
| LDS | Byte stream | By byte offset | Application-defined |
KSDS is the only type with two components: data and index. The data component holds records in ascending key order. The index component (sequence set plus index set) maps key values to control intervals in the data, so a READ by key requires only a few index lookups and one data CI read. The primary key must be unique. You can insert a new record (VSAM places it in key order, using free space or triggering a split), update in place with REWRITE, and delete (the space can be reused). Record length can be fixed or variable. KSDS is the usual choice when you need to find records by a key field (e.g. customer ID, account number) or when you need key-ordered sequential processing.
ESDS has only a data component. Records are stored in the order they were written (entry sequence). There is no key and no index. You address a record by its relative byte address (RBA)—the byte offset from the start of the file. New records are always appended at the end; you cannot insert in the middle. There is no physical delete; if you need to "remove" a record you use a logical delete (e.g. a flag byte or a separate delete list). You can update a record in place with REWRITE at the same RBA. ESDS supports fixed- or variable-length records. It is often used for logs, audit trails, and any data where write order must be preserved and key-based lookup is not required.
RRDS is organized by slot. Each slot has a relative record number (RRN): 1, 2, 3, and so on. In a fixed-length RRDS, each slot has a fixed size; a slot is either empty or holds one record. You read, write, rewrite, or delete by specifying the RRN. With REUSE, when you delete a record the slot is freed and can be reused by a later WRITE at that RRN. Variable-length RRDS (VRRDS) allows variable-length records; an index component maintains the mapping from RRN to record. RRDS is useful when the application naturally thinks in "slot numbers" (e.g. day of year, position in a table) and when all records are the same length (fixed RRDS) or you need variable length with RRN semantics (VRRDS).
LDS (Linear Data Set) does not have a record structure. VSAM treats the dataset as a contiguous byte stream. There are no keys, no RBA in the record sense, and no RRN. The application (or a product like Db2) interprets the contents. Access is typically in units such as 4 KB pages. LDS is used for Db2 tablespaces, VSAM Record Level Sharing (RLS), and other system or product-defined layouts. Most application programs use KSDS or ESDS; LDS is important to know for integration and for understanding how some system components use VSAM.
Because LDS has no control interval record layout, VSAM does not add RDFs, CIDF, or free space in the same way as for KSDS, ESDS, or RRDS. The dataset is just a range of bytes on DASD. Products that use LDS (e.g. Db2) manage their own page layout, locking, and recovery. So when you compare the four types, LDS sits apart: it is VSAM-managed storage without VSAM record semantics.
The organization is specified in DEFINE CLUSTER. For KSDS you use INDEXED and KEYS(length offset); for ESDS you use NONINDEXED and omit KEYS; for RRDS you use NUMBERED and specify the record size (and REUSE if you want slot reuse); for LDS you use LINEAR. Example fragments:
1234567891011* KSDS DEFINE CLUSTER (NAME(...) INDEXED RECORDSIZE(80 80) KEYS(10 0) ...) * ESDS DEFINE CLUSTER (NAME(...) NONINDEXED RECORDSIZE(100 200) ...) * RRDS (fixed-length, REUSE) DEFINE CLUSTER (NAME(...) NUMBERED RECORDSIZE(80 80) REUSE ...) * LDS DEFINE CLUSTER (NAME(...) LINEAR ...)
RECORDSIZE is required for KSDS, ESDS, and RRDS (average and maximum for variable-length). For LDS there is no record structure, so RECORDSIZE is not used in the same way; allocation is typically by CYLINDERS or TRACKS.
Imagine four kinds of boxes. KSDS is like a filing cabinet where every folder has a label (the key); the cabinet keeps folders in label order and you can add or remove folders. ESDS is like a diary: you only write at the end, and you can look up a page by its page number (RBA). RRDS is like a row of mailboxes: each box has a number (RRN), and you can put something in box 5, take it out, or replace it. LDS is like one long tape: there are no folders or boxes, just bytes; only special programs (like Db2) know how to use it.
1. Which VSAM type has both a data component and an index component?
2. Which type allows only append (no insert in the middle)?
3. You need to look up a record by customer number. Which type is best?