A Linear Data Set (LDS) is the only VSAM type that is byte-addressable. Instead of records, keys, or slots, an LDS is a contiguous range of bytes on DASD. You (or a product like Db2) read and write at a specific byte offset or in fixed-size units such as 4 KB pages. VSAM does not interpret the content—it does not break the data into records or maintain an index. This page explains what byte-addressable storage means for LDS, how it differs from record-oriented VSAM types, and when it is used.
Byte-addressable means that the smallest unit of addressing is the byte. You specify a starting position (an offset from the beginning of the dataset) and a length, and the access method reads or writes that range of bytes. There are no "records" from VSAM's point of view: no record descriptor fields (RDFs), no control interval descriptor field (CIDF), no keys. The dataset is one long sequence of bytes. In practice, the application or the product that uses the LDS (e.g. Db2) often divides the space into pages (e.g. 4 KB) and manages its own structures within those pages. So "byte-addressable" means VSAM exposes the storage as a byte stream; how the bytes are organized is up to the consumer.
In a KSDS you address a record by its key. In an ESDS you address a record by its RBA (relative byte address), but the RBA points to a record that VSAM has stored with RDFs and optional control information. In an RRDS you address a record by its RRN (slot number). In all three, VSAM knows about record boundaries: it stores records, manages free space (where applicable), and uses control intervals with a defined layout. In an LDS there are no record boundaries. The dataset is allocated as a number of bytes (e.g. so many cylinders or tracks), and the content is just bytes. So LDS is the only type where "addressability" is purely by byte offset, not by key, RBA-to-record, or RRN.
| Type | Addressing | Unit of access |
|---|---|---|
| KSDS | By key | Record (key + data) |
| ESDS | By RBA (byte offset to record) | Record |
| RRDS | By RRN (slot number) | Record (slot) |
| LDS | By byte offset (address) | Byte range (e.g. page) |
Application programs rarely use LDS directly. Most use KSDS or ESDS, where the program reads and writes logical records. LDS is used by system components and products that need a raw storage extent. Db2 uses LDS for certain tablespace types: the LDS is the backing storage, and Db2 manages pages, buffers, and recovery. VSAM Record Level Sharing (RLS) uses LDS for the shared cache and related structures. Other z/OS components may use LDS for data-in-virtual or similar purposes. So when we say LDS is byte-addressable, we mean the interface to that storage is at the byte (or page) level, and the product that uses it is responsible for the logical layout.
In IDCAMS you define an LDS with the LINEAR organization. You do not specify RECORDSIZE or KEYS. Allocation is typically by CYLINDERS or TRACKS. Example:
12345DEFINE CLUSTER ( - NAME(USERID.MY.LDS) - LINEAR - CYLINDERS(5 2)) - DATA (NAME(USERID.MY.LDS.DATA))
The cluster has only a data component; there is no index. The size is in allocation units (cylinders, tracks), not in records. Once defined, the LDS is a fixed-size byte range; the application or product reads and writes at byte offsets within that range.
Imagine a very long tape with no labels and no dividers. You can say "read from spot 1000 to spot 2000" and get those bytes. That tape is byte-addressable: you say where to start and how much. The other VSAM types are like filing cabinets or diaries where you ask for "the record with this key" or "the 5th record." LDS is just "the bytes at this address."
1. Which VSAM type is byte-addressable?
2. In an LDS, what does VSAM interpret?