When you define a VSAM cluster, you choose one of four types: KSDS, ESDS, RRDS, or LDS. That choice is fixed; you cannot change it later without defining a new cluster and copying data. So selecting the right type up front matters. This page walks through the main decision factors: the purpose of the file, how you access records (key, RBA, or RRN), whether you need inserts and deletes, alternate indexes, and other attributes like compression and space extension. The goal is to give you a clear process for choosing KSDS, ESDS, RRDS, or LDS.
The purpose of the file often dictates the type. A customer master file that is updated by key (customer ID) and read in key order is a KSDS. A transaction log that is only appended and read from the beginning (or by saved RBA) is an ESDS. A table where each row is identified by position (e.g. slot 1 through 1000) is an RRDS. A byte stream used by Db2 or another product is an LDS. So the first question is: what is this file for? Master data with key lookup → KSDS. Log or append-only stream → ESDS. Position-based table → RRDS. System or product storage → LDS.
| Purpose | Type | Reason |
|---|---|---|
| Master file, lookup by key | KSDS | Key-based read/update/delete; key-ordered sequential |
| Log, audit trail, event stream | ESDS | Append only; write order preserved; RBA or sequential |
| Position-based table (e.g. by slot) | RRDS | Direct access by RRN; insert/delete with REUSE |
| Db2, system, or product storage | LDS | Byte stream; no record structure; product-managed |
How do you identify a record? If you identify it by a key field (e.g. customer number, order ID), you need KSDS. Only KSDS has a primary key and an index that maps keys to records. If you identify it by its position when it was written (e.g. "the 1000th record") or by a stored byte offset (RBA), ESDS supports that: sequential read in entry order or READ by RBA. If you identify it by a slot number (RRN 1, 2, 3, …), RRDS is built for that. LDS has no record identity; the application or product uses byte offsets. So: key → KSDS; RBA or write-order position → ESDS; RRN → RRDS; byte stream → LDS.
| Factor | Choose | Note |
|---|---|---|
| Access by key (e.g. customer ID) | KSDS | Only KSDS has a primary key and index |
| Access by byte offset (RBA) | ESDS | ESDS and KSDS support RBA; ESDS has no key |
| Access by slot number (RRN) | RRDS | RRN 1, 2, 3, … |
| Sequential in key order | KSDS | Records stored in key order |
| Sequential in write order | ESDS | Entry sequence |
Do you need to insert new records in the middle of the file (e.g. in key order) or only at the end? KSDS supports insert in key order: VSAM finds the correct control interval, uses free space, and splits if necessary. ESDS does not support insert in the middle; new records are always appended. RRDS supports insert into a slot (or, in VRRDS, new RRNs). For delete: KSDS allows physical delete; the space can be reused. ESDS has no physical delete; you use logical delete (flag or separate list). RRDS allows delete and with REUSE the slot can be reused. So if your application must add and remove records by key or by slot, KSDS or RRDS is required; if you only append and never delete physically, ESDS is sufficient.
| Need | Type | Note |
|---|---|---|
| Insert in key order, delete by key | KSDS | Free space and splits; physical delete |
| Append only; no insert in middle | ESDS | No physical delete; logical delete only |
| Insert/delete by slot; reuse slots | RRDS | REUSE frees slot for new WRITE |
An alternate index (AIX) lets you access a base cluster by a different key. For example, the base cluster might be keyed by customer ID, and you define an AIX keyed by last name so you can look up by name. Alternate indexes are supported only for KSDS. If you need multiple key views (primary key plus one or more alternate keys), you must use KSDS and define the base cluster and one or more AIX paths. ESDS and RRDS have no key, so there is no alternate key to index. If you need key-like access on an ESDS, the application must maintain its own index (e.g. a separate KSDS that maps "alternate key" to RBA).
KSDS and ESDS support fixed-length or variable-length records. RRDS traditionally uses fixed-length slots (fixed RRDS); variable-length RRDS (VRRDS) allows variable-length records with an index that maps RRN to record. LDS has no record structure. If your records are all the same length and you address by slot, fixed RRDS is simple. If record length varies and you need key access, KSDS with RECORDSIZE(average maximum) is the choice. If records vary and you only append, ESDS supports variable length.
VSAM supports compression (e.g. via IDCAMS or SMS data class) so that data is stored in compressed form on DASD. Compression is typically applied at the CI level. Whether compression is available and how it affects performance depends on your system and storage configuration. Extension refers to secondary space allocation: when the primary space is full, VSAM extends the dataset by the secondary amount. This is specified in DEFINE CLUSTER (e.g. CYLINDERS(10 5) for 10 primary, 5 secondary). All four types can be extended; the decision is how much primary and secondary to allocate based on expected growth. These factors do not usually determine the type (KSDS vs ESDS vs RRDS) but affect how you define the cluster once the type is chosen.
Start with: Do I need to find or update records by a key? If yes → KSDS. If no, ask: Do I only append and read by RBA or sequentially in write order? If yes → ESDS. If no, ask: Do I identify records by slot number (RRN) and need insert/delete by slot? If yes → RRDS. If the file is for a product like Db2 or a system component that expects a byte stream → LDS. For most application files, the choice is KSDS (key-based) or ESDS (append-only, RBA/sequential). RRDS is chosen when the natural identifier is position. LDS is chosen by products and system code, not typically by application programs.
Picking a VSAM type is like picking a kind of box. If you need to find things by a label (like a name), you need the labeled filing cabinet (KSDS). If you only add new pages at the end of a diary and look up by page number, that's the diary (ESDS). If you have a row of mailboxes and you care about "box 5" or "box 10," that's the mailbox row (RRDS). And if a special machine needs a long tape with no folders or boxes, that's LDS. You pick the box that matches how you want to find and add things.
1. You need to look up records by account number and sometimes insert new accounts. Which type?
2. Alternate indexes (AIX) are available for which type?
3. Your application identifies each record by a slot number 1 to 365 (e.g. day of year). Best type?