VSAM LDS Used by VSAM RLS

VSAM Record Level Sharing (RLS) allows multiple address spaces to share the same VSAM dataset with record-level locking and a shared cache. RLS uses Linear Data Sets (LDS) for some of its internal storage. The LDS provides byte-addressable space without record structure, so RLS can lay out its cache and control structures in the format it needs. This page explains why RLS uses LDS and what that means for someone learning VSAM.

What Is VSAM RLS?

In traditional VSAM, each address space that opens a cluster has its own buffers. If two CICS regions open the same KSDS, each has its own copy of the data in memory, and coordination (if any) is at the file level (e.g. ENQ). Record Level Sharing (RLS) changes that: multiple address spaces share access to the same VSAM dataset with record-level locking. A shared cache holds control intervals (or pages) so that one physical copy can serve many openers. A lock manager ensures that when one region updates a record, others see consistent data or wait for the lock. RLS is used when many regions (e.g. CICS, batch, IMS) need to read and update the same VSAM data with proper concurrency.

Why RLS Uses LDS

RLS needs to store internal data: information about the shared cache, lock state, or other control structures. That data does not fit the "record" model of KSDS or ESDS—it is a product-defined layout. So RLS uses LDS (or equivalent byte-addressable storage) for these structures. The LDS is a raw byte range; RLS decides what goes at each offset. That is the same pattern as Db2 using LDS for tablespaces: the product needs raw storage and defines its own format. So "LDS used by VSAM RLS" means RLS is one of the consumers of LDS for which "no record structure" is the right fit.

What You Need to Know as a Developer

As an application developer you typically do not create or open the LDS that RLS uses. You define your VSAM cluster (e.g. KSDS) and then configure it for RLS (e.g. in CICS file definition or in JCL). When your program opens the cluster, it is opened under RLS; the RLS infrastructure uses LDS internally for its cache and related structures. Your program still reads and writes records to the cluster as usual; the LDS is behind the scenes. So the takeaway is: LDS is part of the RLS implementation, and RLS is the feature that lets many regions share the same VSAM dataset with record-level locking. Knowing that RLS uses LDS helps you understand why LDS exists and who uses it—not necessarily how to program it directly.

Key Takeaways

  • VSAM Record Level Sharing (RLS) allows multiple address spaces to share a VSAM dataset with record-level locking and a shared cache.
  • RLS uses LDS for internal structures (e.g. shared cache) because LDS is byte-addressable and has no record structure; RLS defines the layout.
  • Application programs open the VSAM cluster (KSDS, etc.) under RLS; they do not open the RLS LDS directly.

Explain Like I'm Five

RLS is like a shared whiteboard that many people can use at once, with a rule that only one person can write in one box at a time. The whiteboard needs a special kind of storage (the LDS) where the system keeps track of what is on the board and who is using which box. That storage is just a long strip of space—no pre-drawn boxes—so the system can use it its own way.

Test Your Knowledge

Test Your Knowledge

1. What does RLS use LDS for?

  • Storing application records
  • Internal structures such as shared cache
  • Primary key index
  • Alternate index
Published
Updated
Read time4 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: IBM z/OS 2.5 documentationSources: IBM DFSMS Access Method Services, z/OS VSAM documentationApplies to: z/OS 2.5