In KSDS, ESDS, and RRDS, VSAM stores logical records. Each record has a length, and within a control interval VSAM uses record descriptor fields (RDFs) and a control interval descriptor field (CIDF) to track where each record is and where free space begins. A Linear Data Set (LDS) has none of that. There is no record structure: no RDFs, no CIDF, no keys, no slots. The LDS is just a contiguous range of bytes. This page explains what "no record structure" means for LDS and how it differs from the other VSAM types.
In a KSDS, ESDS, or RRDS, the data component is organized in control intervals (CIs). Each CI contains logical records (or, in RRDS, slot entries). For each record, VSAM stores a record descriptor field (RDF) that describes the record length and possibly other control information. At the end of the CI there is a control interval descriptor field (CIDF) that points to the free space and helps VSAM manage the CI. So when you READ a record, VSAM uses the RDFs to find the record boundaries and return the correct bytes. When you WRITE or REWRITE, VSAM updates the RDFs and possibly the CIDF. The record is the unit of operation.
In an LDS, VSAM does not store records at all. The data component is not divided into records from VSAM's perspective. There are no RDFs and no CIDF. The dataset is a single contiguous extent of bytes. When a product (e.g. Db2) or an application uses an LDS, it is responsible for deciding what those bytes mean: it might treat them as 4 KB pages, or as a custom layout. VSAM just moves bytes between DASD and the buffer when asked; it does not interpret the content. So "no record structure" means: no record boundaries maintained by VSAM, no key, no RBA-to-record mapping by VSAM, no RRN. The consumer of the LDS defines whatever structure it needs on top of the byte stream.
| Aspect | KSDS, ESDS, RRDS | LDS |
|---|---|---|
| Records | Yes; logical records in CIs | No; byte stream only |
| RDFs / CIDF | Yes; VSAM manages record boundaries | No; no record boundaries |
| Keys | KSDS has key; ESDS/RRDS have RBA or RRN | No keys |
| Free space | KSDS/RRDS have free space in CIs | N/A |
| RECORDSIZE in DEFINE | Required for KSDS, ESDS, RRDS | Not used |
LDS is intended for uses where the consumer wants full control over the layout. Db2, for example, manages its own page format, buffer pool, and recovery; it does not need VSAM to impose a record layout. VSAM RLS uses LDS for shared cache structures where the format is defined by the RLS component. If VSAM added record structure to LDS, it would conflict with these product-defined layouts. So LDS is deliberately "dumb" storage: raw bytes, no interpretation. That makes it flexible for system and product use.
If you are writing an application that uses VSAM, you will almost always use KSDS, ESDS, or RRDS—where you OPEN the file, READ/WRITE/REWRITE/DELETE records, and let VSAM manage record boundaries. You do not normally open an LDS and read "records" from it; there are no records. Products that use LDS have their own APIs (e.g. Db2 buffer pool and page I/O). So as a VSAM tutorial topic, "no record structure" is mainly important so you understand that LDS is different and why it exists—not so you program against it directly in the same way as KSDS or ESDS.
The other VSAM types are like a notebook with lines: each line is a record, and the system knows where each line starts and ends. An LDS is like one long blank strip of paper with no lines. Nobody has drawn the lines; you (or a special program) have to know where to read and write. So "no record structure" means the strip has no built-in divisions—just bytes.
1. Does VSAM store records in an LDS?
2. What does RECORDSIZE mean for an LDS?