Db2 uses VSAM Linear Data Sets (LDS) as the underlying storage for certain tablespace types on z/OS. An LDS is byte-addressable and has no record structure, which matches what Db2 needs: Db2 manages its own page layout, buffer pool, and recovery, and does not want VSAM to impose records or keys. This page explains why Db2 uses LDS, how it fits into Db2 storage architecture, and what it means for someone learning both VSAM and Db2.
Db2 stores table data in tablespaces. A tablespace is a logical container that maps to one or more physical datasets. On z/OS, Db2 can use VSAM LDS for that physical storage. Db2 divides the LDS into fixed-size pages (e.g. 4 KB or 8 KB). It maintains a buffer pool in memory, reads pages from the LDS by byte offset, and writes pages back when they are modified. All of this is at the page level—Db2 does not use VSAM records. So the dataset must be byte-addressable and without record structure. LDS is exactly that: a contiguous byte range. Db2 can read page N by computing the byte offset (N × page size) and issuing a read for that range. No key, no RBA-to-record, no RRN. That is why Db2 uses LDS (or an equivalent such as SMS-managed LDS-style storage) rather than KSDS or ESDS.
Db2 is responsible for the content of the LDS. It formats pages with page headers, slot directories, and row data. It handles space management within the tablespace, recovery (e.g. log-based), and concurrency control. VSAM is only the I/O layer: it moves bytes between the LDS on DASD and the buffer that Db2 provides. So when we say "LDS is used by Db2," we mean Db2 owns the logical layout; VSAM provides the physical storage and the read/write interface at the byte level.
Typically, Db2 creates and manages the LDS (or the equivalent dataset) when you define a tablespace that uses LDS storage. You do not usually run IDCAMS yourself to create the LDS for a Db2 tablespace; Db2 or the storage administrator does that as part of Db2 object definition. The LDS is then cataloged and associated with the tablespace. From the application perspective, you use SQL and Db2 APIs; you do not open the LDS directly. So as a VSAM learner, the important point is that LDS exists in part to support this kind of product use—raw storage for a product that manages its own layout.
VSAM is an access method: it organizes and retrieves data on DASD. Db2 is a database manager: it provides SQL, transactions, and a relational model. Db2 can sit on top of VSAM (using LDS for tablespace storage). The application talks to Db2; Db2 talks to VSAM (or the equivalent I/O layer) for physical I/O. So you do not choose "VSAM or Db2" for the same layer. You choose Db2 when you need a database; Db2 may then use VSAM LDS under the covers. You choose VSAM directly (KSDS, ESDS, RRDS) when you need a file with key or position-based access without a full database.
Db2 is like a librarian that needs a big empty shelf (the LDS). The librarian decides how to put books (pages) on the shelf and where each one goes. The shelf does not have labels or dividers—it is just space. Db2 uses the LDS as that shelf; VSAM is the one that actually fetches or puts back the right chunk of the shelf when Db2 asks for it.
1. Why does Db2 use LDS for tablespaces?