Which VSAM Data Set Should You Use? KSDS, ESDS, RRDS, LDS

A customer master addressed by account number points to KSDS. A work queue consumed in arrival order points to ESDS. A table addressed by slot number points to RRDS. Choose the VSAM organization from the way the program identifies and changes records—not from a blanket rule that one type is faster.

Start with the record identifier: key, entry order, relative record number, or byte address.

Quick VSAM selection table

Requirement	Likely choice	Reason
Retrieve and update by a unique field such as account number	KSDS	Primary-key index supports direct and key-sequential access.
Append records and process them in arrival order	ESDS	Records remain in entry sequence; new records go at the end.
Address fixed-length records by stable numeric slot	Fixed RRDS	The RRN identifies a preassigned fixed-length slot.
Address variable-length records by a relative record number	VRRDS	RRN access is retained while record lengths can vary.
Application or product needs a byte-addressable object with DIV	LDS	LDS has no VSAM record-level structure.

Spelling check: ESDS means entry-sequenced data set. “EDS” is not a VSAM organization.

Choose KSDS for a business key

Use a key-sequenced data set when a field inside each record uniquely identifies it. Employee number, policy number, and part number are typical primary keys. VSAM maintains an index and stores the logical sequence by the collating value of that key.

KSDS supports direct lookup by key, sequential retrieval in key order, and skip-sequential processing. Records can be inserted, updated, and deleted. If inserts are frequent, define free space and review control-interval and control-area splits rather than assuming the initial allocation will remain suitable.

Good KSDS fit

• An online CICS inquiry retrieves one customer by account number.
• A batch job starts at a supplied key and reads the next range of records.
• The application must delete records or insert new keys between existing keys.
• A supported alternate-index path is required for a second lookup field.

The COBOL indexed-file guide shows ORGANIZATION IS INDEXED, RECORD KEY, and keyed READ statements.

Choose ESDS for entry order and append processing

An entry-sequenced data set keeps records in the order in which they were written. New records are added after the last record. Sequential processing is its natural pattern, and direct access can use a relative byte address when the application has retained that address.

ESDS suits append-heavy histories, journals, or staging data where arrival order matters more than a primary-key sequence. Existing records can be updated without changing their length. VSAM does not physically delete an ESDS record; applications commonly mark a record inactive.

Avoid ESDS when

• The application needs routine direct lookup by a business key and no suitable supported path is available.
• Existing records must grow or shrink in place.
• Physical deletion and reuse behavior is a central requirement.

Choose fixed RRDS for stable numbered slots

A fixed relative-record data set assigns a fixed-length slot to each relative record number. If the program can derive RRN 125 directly, VSAM can locate that slot without searching a business-key index. Empty slots are permitted and can later receive records.

Fixed RRDS works well for dense or predictably bounded numeric identifiers such as terminal number, branch slot, or day-of-year position. It is a poor match when the highest possible RRN is very large but only a few values will be populated, because space is organized around fixed slots.

Fixed RRDS checks

• Every record must have the defined fixed length.
• The application supplies or derives the RRN.
• A deleted slot can be reused.
• Alternate indexes and spanned records are not available.

Choose VRRDS for variable records addressed by RRN

A variable-length RRDS keeps the relative record number as the record identifier but permits varying record lengths up to the defined maximum. Unlike a fixed RRDS, VSAM uses an index to locate VRRDS records.

Choose VRRDS only when the application genuinely owns stable relative record numbers and also needs variable-length content. If the identifier is a meaningful field already stored in each record, KSDS is usually the clearer application model.

Choose LDS for byte-addressable storage

A linear data set presents a byte-addressable string rather than normal VSAM records. It has no embedded record-level control information and can be used through data-in-virtual or window services. IBM system functions and products such as Db2 use LDS heavily; ordinary COBOL record-file processing rarely does.

LDS is not a faster substitute for every VSAM file. Choosing it moves record structure and access responsibility to the application or product that owns the data format.

Do you need an alternate index?

An alternate index can provide another access path for a KSDS and, in supported environments, a standard ESDS. The alternate key can be unique or nonunique. It also adds a cataloged index object and an upgrade or maintenance decision.

Do not choose KSDS solely because an alternate index sounds convenient. Confirm that the language, access method, and runtime environment support the path you plan to use. IBM Enterprise COBOL documentation, for example, notes restrictions for alternate-index access to ESDS. Extended-addressing ESDS also has its own limitations.

Five application scenarios

Scenario	Choice	Decision point
CICS policy master retrieved by policy number and browsed in policy order	KSDS	Unique embedded business key and mixed direct/sequential access
Daily event feed appended and later scanned in arrival order	ESDS	Append-only entry sequence
Fixed 200-byte branch record addressed by branch number 1–9999	Fixed RRDS	Stable, bounded numeric slot and fixed length
Variable rule text addressed by an application-assigned rule number	VRRDS	Stable RRN with varying record size
Db2-managed byte-addressable storage object	LDS	Owning product uses byte access rather than VSAM record calls

COBOL organization mapping

VSAM type	COBOL organization	Typical identifier
KSDS	ORGANIZATION IS INDEXED	RECORD KEY
ESDS	ORGANIZATION IS SEQUENTIAL	Entry sequence; RBA access is outside ordinary sequential COBOL use
RRDS or VRRDS	ORGANIZATION IS RELATIVE	RELATIVE KEY
LDS	Not a normal COBOL record organization	Byte offset managed by the owning interface

After choosing the organization, use the VSAM DEFINE CLUSTER guide for working KSDS, ESDS, and RRDS allocation examples. The IDCAMS command guide covers DEFINE, REPRO, LISTCAT, and DELETE.

Allocation choices come after organization

Record size, control-interval size, free space, share options, reuse, spanned-record needs, extended format, and SMS classes still matter. They tune or constrain the chosen organization; they do not replace the primary decision about how the application addresses records.

For insert-heavy KSDS processing, review the VSAM control-interval guide. The broader VSAM concepts article explains clusters, data and index components, control intervals, and control areas.

Common selection mistakes

• Writing “EDS” when the intended organization is ESDS.
• Choosing KSDS when the program never uses a key.
• Using ESDS when records must be physically deleted or lengthened in place.
• Using fixed RRDS for a sparse, unbounded numeric key space.
• Confusing fixed RRDS with variable-length RRDS.
• Selecting LDS for ordinary COBOL record processing.
• Assuming one type is always fastest without measuring the actual access pattern.
• Ignoring alternate-index support and maintenance restrictions.

VSAM selection checklist

1. Write down the identifier used by every direct-read path: key value, RBA, or RRN.
2. Identify the dominant access pattern: direct, sequential, skip-sequential, or append.
3. Confirm whether records are fixed length, variable length, or potentially spanned.
4. List required insert, update, length-change, and delete operations.
5. Decide whether another field needs an alternate access path.
6. Check language and subsystem support for the selected organization.
7. Then choose CI size, free space, SMS attributes, and allocation values.

Use the separate VSAM data-set characteristics table when you need a field-by-field comparison rather than a selection flow. The VSAM interview questions provide practice after the design rules are clear.

Official IBM references

• IBM: Selection of VSAM data-set types
• IBM: Summary of ESDS, KSDS, RRDS, VRRDS, and LDS
• IBM: Enterprise COBOL VSAM files
• IBM: Key-sequenced data sets
• IBM: Entry-sequenced data sets

Choosing a VSAM data set FAQ

Which VSAM data set should I use for keyed lookup?

Use a KSDS when each record has a unique primary key and the application needs direct keyed access, key-sequence browsing, or both. An alternate index can provide another lookup path when its restrictions are acceptable.

What is the difference between RRDS and VRRDS?

A fixed RRDS uses preassigned fixed-length slots addressed by relative record number. A VRRDS also uses a relative record number, but its records can vary in length and VSAM maintains an index for them.

Can I delete a record from an ESDS?

VSAM does not physically delete an ESDS record. An application can mark a record inactive and may reuse that space only under the applicable same-length rules. New ESDS records are added at the end.

Is EDS a VSAM data set type?

No. The correct acronym is ESDS, meaning entry-sequenced data set. The other common VSAM types are KSDS, fixed or variable RRDS, and LDS.

Make the first decision from the record identifier: business key means KSDS, entry order means ESDS, relative number means RRDS or VRRDS, and byte addressing means LDS.

VSAM Data Set Types: KSDS, ESDS, RRDS, VRRDS, and LDS

A batch program needs to retrieve a customer by account key, a log reader needs records in load order, and a relative file needs direct access to slot 250. Those are three different access patterns, and they point to different VSAM organizations. This reference compares the structural characteristics of the five VSAM data set types—KSDS, ESDS, fixed-length RRDS, VRRDS, and LDS—so you can see exactly how records are ordered, addressed, inserted, deleted, and stored.

VSAM data set types compared by key, entry sequence, relative record number, or byte access.

VSAM data set types at a glance

VSAM concepts begin with a simple distinction: an organization defines how data is arranged and how an application identifies it. A KSDS uses a key and an index. An ESDS uses entry sequence and a relative byte address (RBA). An RRDS uses a relative record number (RRN). An LDS exposes byte-addressable storage rather than application records.

This page is a characteristics reference, not a workload recommendation page. If your question is which organization fits a particular application, use the separate VSAM data set selection guide after comparing the mechanics here.

VSAM organization comparison table

Characteristic	KSDS	ESDS	Fixed RRDS	VRRDS	LDS
Logical order	Ascending prime-key sequence	Order in which records are loaded	RRN sequence	RRN sequence	No record order
Direct identifier	Prime key or RBA	RBA	RRN	RRN	Byte offset through data-in-virtual services
Components	Data plus prime index	Data only	Data only	Data plus index	Data only
Alternate index	Permitted	Permitted by VSAM, with language/product restrictions	Not permitted	Not permitted	Not permitted
Identifier stability	Key stable; RBA can change	RBA remains stable	RRN remains stable	RRN remains stable	Not record-addressed
Insertion	In key sequence; free space can accommodate growth	Append at the logical end	Into an empty numbered slot	At an unused RRN; free space supports variable lengths	Managed as byte-addressable pages
Deletion and reuse	Released space becomes reusable	Deletion does not create general reusable free space; a same-length record can replace the deleted record	Deleted slot can be reused	Released space becomes reusable	No record-level delete operation
Record length	Fixed or variable	Fixed or variable	Fixed	Variable	No VSAM record structure
Spanned records	Allowed	Allowed	Not allowed	Not allowed	Not applicable
Extended format	Supported	Supported	Supported	Supported	Supported

KSDS characteristics

A key-sequenced data set stores records in the collating sequence of a unique prime key. Its separate prime-index component maps keys to data control intervals, which makes keyed direct access possible while preserving logical key order for sequential processing. Applications can also address records by RBA, but that RBA is not a permanent identifier: control interval and control area splits can move a record.

KSDS supports fixed- or variable-length records, record insertion in key sequence, deletion, and reusable free space. It also permits alternate indexes for access through additional keys. These features explain the extra index component and the additional maintenance compared with a data-only organization.

ESDS characteristics

An entry-sequenced data set keeps records in arrival order. New records are appended to the logical end, and an RBA identifies the byte position of an existing record. Because records are not reorganized by a key index, the RBA remains stable. Sequential reading follows load order.

ESDS supports fixed- or variable-length records and can have an alternate index at the VSAM level. Its update rules are stricter than KSDS rules: a record cannot grow in place, and normal deletion does not turn arbitrary space into reusable free space. A deleted record location can be reused by a replacement of the same length. Those constraints make ESDS behavior distinct from merely calling it “a file without a key.”

Fixed-length RRDS characteristics

A fixed-length relative record data set divides storage into equal-length slots. The RRN identifies a slot, so record 250 is reached by relative number rather than by scanning 249 earlier records. Empty slots can exist, and deleting a record makes that numbered slot available for reuse without changing the RRNs of other records.

Because every slot has the same size, a fixed RRDS does not need an index component. It does not support alternate indexes or spanned records. In COBOL terms, this organization aligns with relative file organization when fixed record length and stable relative numbers fit the application contract.

VRRDS characteristics

A variable-length RRDS also addresses records by RRN, but an index maps those relative numbers to variable-length records in the data component. That index is the key structural difference from fixed RRDS. Records can vary in length, and available free space can be reused after records are deleted or shortened.

VRRDS retains stable RRNs, does not permit alternate indexes, and does not allow records to span control intervals. It is therefore not simply a fixed RRDS with a larger maximum record size; its indexed layout supports the variable-length mapping.

LDS characteristics

A linear data set contains a continuous string of bytes with no VSAM-defined record boundaries. Programs use data-in-virtual (DIV) services and window services to map and access its pages. Record-level concepts such as prime keys, RRNs, alternate indexes, deletion, and spanning do not apply.

LDS is also excluded from VSAM record-level sharing. Treat it as a byte-addressable storage object, not as another record organization with an unusual access key.

Data and index components

The word cluster refers to the VSAM object defined in the catalog. KSDS and VRRDS require both data and index components. KSDS uses its index for the prime-key structure; VRRDS uses an index to map RRNs to variable-length records. ESDS, fixed RRDS, and LDS have only a data component unless another separately defined structure is involved.

This distinction matters during definition, backup, recovery, and space analysis. It also prevents a common mistake: assuming every organization with direct access must have an index component.

RBA, RRN, and key stability

A key, RBA, and RRN are not interchangeable names for a record address. A KSDS prime key is a logical identifier, while its RBA can change as VSAM reorganizes space. An ESDS RBA is stable because records retain their byte position. An RRDS RRN identifies a logical slot or indexed relative number and remains stable for that record location.

Practical rule: store or exchange only the identifier guaranteed by the organization and application design. Do not persist a KSDS RBA as though it were a permanent business key.

Alternate indexes and language limits

At the VSAM level, alternate indexes can be defined over KSDS and ESDS clusters, but not over either RRDS type or LDS. The programming environment can impose a narrower rule. For example, IBM Enterprise COBOL documents alternate-index support for KSDS but not for ESDS. Always check both the access-method capability and the language or transaction manager interface.

Spanned records and extended format

KSDS and ESDS records may be spanned, allowing one logical record to cross control interval boundaries when the cluster is defined accordingly. Fixed RRDS and VRRDS do not support spanning, and the concept is not applicable to LDS because LDS has no record boundaries.

All five organizations can be defined as extended-format VSAM data sets when the applicable system and storage requirements are met. Extended format enables facilities such as data striping and, for eligible KSDS data components, compression. “Extended format supported” does not mean every extended-format feature applies identically to every organization.

How DEFINE CLUSTER identifies each type

IDCAMS uses organization attributes in the cluster definition. The following skeleton shows the identifying keyword, not a complete production definition:

/* KSDS */  DEFINE CLUSTER (NAME(...) INDEXED ...)
/* ESDS */  DEFINE CLUSTER (NAME(...) NONINDEXED ...)
/* RRDS */  DEFINE CLUSTER (NAME(...) NUMBERED RECORDSIZE(80 80) ...)
/* VRRDS */ DEFINE CLUSTER (NAME(...) NUMBERED RECORDSIZE(80 400) ...)
/* LDS */   DEFINE CLUSTER (NAME(...) LINEAR ...)

For NUMBERED, equal average and maximum record sizes describe fixed RRDS; unequal values describe VRRDS. The exact space, sharing, buffer, key, and data class parameters depend on the workload and installation standards. See the full DEFINE CLUSTER guide and the related IDCAMS command reference for working examples.

Common VSAM comparison mistakes

• Calling every direct identifier a key: ESDS uses an RBA, RRDS uses an RRN, and LDS is byte-addressable.
• Treating ESDS deletion like KSDS deletion: ESDS does not provide the same general free-space reuse behavior.
• Combining fixed RRDS and VRRDS: both use RRNs, but only VRRDS has an index component and variable record lengths.
• Assuming an RBA is always stable: it is stable for ESDS but can change for a KSDS record.
• Equating VSAM support with language support: alternate-index restrictions can differ between VSAM itself and a language such as COBOL.

Official IBM references

• Summary of VSAM data set types
• VSAM data set organizations
• Selection of VSAM data set types
• Enterprise COBOL support for VSAM files
• Extended-format VSAM data sets
• IDCAMS DEFINE CLUSTER
• Fixed-length RRDS
• Creating a linear data set

VSAM data set types FAQ

Which VSAM data set types have an index component?

KSDS and VRRDS have index components. A KSDS index supports prime-key access; a VRRDS index maps RRNs to variable-length records. ESDS, fixed RRDS, and LDS are data-only organizations.

Is an ESDS RBA stable?

Yes. An ESDS record keeps its RBA because records remain in entry sequence. A KSDS RBA can change after splits or reorganization, so the prime key is the safer logical identifier.

What is the difference between RRDS and VRRDS?

Fixed RRDS uses equal-length slots and has no index component. VRRDS supports variable-length records and uses an index to map each RRN to its record. Both provide direct access by RRN.

Which VSAM types allow spanned records?

KSDS and ESDS allow spanned records when defined for them. Fixed RRDS and VRRDS do not, while spanning is not applicable to LDS because it has no VSAM record structure.

Use the matrix as a definition check. When reviewing a design or an IDCAMS definition, start with the identifier the application owns: prime key, RBA, RRN, or byte offset. Then verify component structure, record length, insertion and deletion rules, spanning, and required language support. That sequence turns the five acronyms into concrete storage behaviors and helps catch an organization mismatch before data is loaded.