A linear data set (LDS) is the VSAM organization optimized for byte addressability instead of keyed logical records. If a KSDS is a filing cabinet with labeled folders and an index card drawer, an LDS is a long roll of paper measured by inch marks. Subsystems such as Db2 for z/OS and parts of the VSAM Record Level Sharing infrastructure consume that roll in fixed page sizes they define themselves. Application programmers rarely "use LDS" the way they use a KSDS in COBOL; instead they use SQL or subsystem APIs, and the LDS is the durable place bytes land after commits and checkpointing. This page consolidates practical usage themes for beginners: what LDS is for, how it differs from other VSAM types, why Db2 maps pages onto it, how RLS fits into the story at a high level, and the operational mistakes that get people paged.
VSAM exposes an addressable range of bytes for an LDS. Offsets are meaningful to the consumer. Db2 interprets offsets as page boundaries internally. From VSAM's perspective, a read or write still happens in CI-sized chunks at the physical level, but the application-level abstraction is not "read by key" like KSDS. That separation is why KEYS and FREESPACE percentages do not appear in the same mental checklist for LDS as they do for keyed clusters. When you monitor performance, you think in consumer units (Db2 pages read, index probes) and translate downward to EXCP against the underlying dataset names.
| Topic | KSDS mental model | LDS mental model |
|---|---|---|
| Record model | Logical records with keys in data CIs; index component for keyed access | Byte stream; consumer defines meaning of offsets |
| Typical beginner tools | IDCAMS REPRO, COBOL VSAM, CICS file control | Subsystem utilities; not a generic scratch pad for QSAM-style records |
| Tuning mindset | CI size, FREESPACE, splits, BUFND/BUFNI | Consumer buffer pools (for example Db2) and physical placement; not VSAM key tuning |
Even though LDS is not keyed, it still occupies volumes, participates in SMS triplet assignment, and appears in LISTCAT. Space exhaustion still matters: when an LDS cannot extend, the consumer subsystem surfaces errors translated into messages you must research in the Db2 or VSAM message manual as appropriate. SMS storage class still influences which pools you land in; management class still influences lifecycle automation. The difference is that your application DBA or systems programmer—not your COBOL program—usually owns the DEFINE or ALTER pattern for these objects.
When a Db2 page read fails due to a physical problem, you may see Db2 messages referencing dataset names that LISTCAT shows as VSAM linear. The triage path joins Db2 diagnostic data, RMF device exceptions, and storage hardware reports. Beginners contribute by capturing timestamps, correlation IDs, dataset names, and LPAR cleanly—not by running VERIFY against a dataset they do not understand. The VERIFY command is powerful for VSAM integrity questions but must be used with change control when a subsystem owns the dataset.
Even though Db2 hides keys from you, the underlying LDS still grows in extents like other disk objects. A table space that extends hundreds of times across many volumes can still stress catalog entries, increase recovery copy time, and complicate volume free-space planning. Db2 administrators therefore talk about DSSIZE, PIECESIZE, partition counts, and PBG versus PBR—not because those words are VSAM keywords, but because they influence how many underlying objects exist and how large each one becomes. When you hear "we need to REORG this table space," part of the motivation is often to consolidate fragmented growth patterns so the VSAM objects underneath are easier to manage and faster to back up, even if end-user SQL does not change at all.
Striping and SMS data class choices can spread an LDS across multiple volumes for bandwidth. That is invisible to SQL but visible to storage dashboards. If your career path touches performance, learn how to read the mapping from Db2 object to dataset to volume set so you can participate in joint reviews with storage when a subsystem is I/O bound. The vocabulary crosses teams: VSAM people say CI and CA; Db2 people say page and partition; storage people say extent and rank. The LDS is the shared ground truth object all three names attach to.
Actual DEFINE syntax depends on z/OS level and whether SMS fills in parameters. Treat the fragment below as shape, not a copy-paste production job.
1234DEFINE CLUSTER (NAME(EXAMPLE.LDS.DATA) - LINEAR - CYL(10 5) - VOLUMES(VOL001))
Notice LINEAR instead of INDEXED. There is no KEYS clause. The consumer subsystem decides internal layout on top of the allocated byte range.
Read VSAM datasets in Db2 for the SQL-to-disk story. Read byte-addressable storage for the definitional foundation. Read LDS used by VSAM RLS when you specialize in online record sharing. Together they explain why "VSAM" remains in job titles even when half the company writes SQL all day.
A KSDS is a comic book with page numbers and a sticky note index telling you which page has Batman. An LDS is a long scroll where someone drew their own little boxes every few inches. Db2 is the artist who decides box size and what each box means. If you cut the scroll with scissors without telling the artist, the next reader sees half a picture of Batman's boot and thinks the story broke—which it did.
1. An LDS is best described as:
2. Why should beginners avoid manual IDCAMS REPRO into an active Db2 table space LDS?
3. Which VSAM parameter is least relevant to tuning a Db2-backed LDS from the application SQL layer?