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.
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. |
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.
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
- Write down the identifier used by every direct-read path: key value, RBA, or RRN.
- Identify the dominant access pattern: direct, sequential, skip-sequential, or append.
- Confirm whether records are fixed length, variable length, or potentially spanned.
- List required insert, update, length-change, and delete operations.
- Decide whether another field needs an alternate access path.
- Check language and subsystem support for the selected organization.
- 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.
No comments:
Post a Comment