VSAM caching: data and index buffering

When people say "caching" on distributed platforms, they often mean a named product like a Redis server or a browser cache. On z/OS, VSAM does not expose a simple key-value cache you configure with a single switch. Instead, VSAM keeps copies of pieces of your dataset—control intervals from the data component and control intervals from the index component—in memory inside a local buffer pool associated with your open instance of the cluster. Think of it as "keep the pages you are working on on your desk instead of walking to the filing cabinet every time." The filing cabinet is disk; your desk is central storage; VSAM decides which desk pages to keep based on buffer counts, access patterns, and internal replacement policies. This page explains that model for beginners, separates data buffering from index buffering, relates them to common tuning knobs you may already have seen (BUFND, BUFNI, STRNO), and sets expectations about what VSAM does not promise (for example, cross-address-space shared caching of the same VSAM buffers).

Why buffering feels like caching

A cache is any mechanism that stores a redundant copy of data closer to the consumer so a repeat reference is cheaper than the original source. VSAM's local buffer pool fits that definition. The first read of a control interval may pull it from disk into a buffer. If your program reads another record in the same CI, or walks the index CI again, VSAM may find the CI still resident and avoid a physical I/O. That is a cache hit in everyday language. The important nuance is locality: sequential access often reuses a small number of buffers in rotation, while random access jumps around the dataset and may churn through many distinct CIs. Random workloads therefore need either more buffers (if the working set still fits) or they will pay more I/O because the replacement policy must free slots for new CIs. Index random access amplifies the effect because keyed lookup reads index CIs along a B-tree path before it reads the data CI.

Data caching: the data component in buffers

For a KSDS, the data component stores your logical records inside control intervals. When your program issues a READ, VSAM determines which CI contains the record, ensures a buffer holds that CI, and returns data from the buffer to your buffer or DCB area. For WRITE or REWRITE, VSAM may read the CI first (unless already in a buffer), apply the change in the buffer, and later externalize it to disk. BUFND on the DD AMP parameter is the classic way to raise the number of buffers VSAM uses for the data component for that allocation. More buffers mean more CIs can remain resident concurrently. Beginners sometimes assume VSAM reads "one record" from disk each time; in reality VSAM reads an entire CI (unless spanning records split across CIs), so buffering is inherently block-oriented. That is why CI size tuning interacts with buffering: larger CIs move more bytes per I/O but also consume more buffer space per slot.

For an ESDS, there is no separate index component in the same sense as a KSDS, so data buffering dominates. For an RRDS, data buffering still applies; relative record addressing resolves to a CI. Linear data sets used by Db2 are a different consumer pattern: Db2 manages page movement into its own pools, while VSAM still honors the underlying I/O contract. The beginner takeaway is unchanged: the data component benefits from enough BUFND to cover the CIs your access pattern touches within a short window of time.

Index caching: the index component in buffers

A KSDS index is also stored as VSAM control intervals—organized as sequence set and index set levels. Each keyed READ walks from high-level index down to the sequence set entry that points to the data CI. Those walks touch index CIs. BUFNI controls how many index buffers VSAM keeps for that open instance. If BUFNI is too low relative to the depth and breadth of your random keyed access, VSAM may read and discard the same index CIs repeatedly. That looks like poor cache hit rate in performance reports: high I/O count against the index component name in SMF or vendor traces even when the data component I/O seems moderate. Increasing BUFNI is not free; each buffer consumes real storage until the dataset is closed. That is why storage administrators care about aggregate BUFNI across many concurrently open VSAM files in CICS or batch.

Inserts and CI splits stress both sides: the data CI must be updated, and index entries must be adjusted. Split-heavy files therefore need a balanced plan for BUFND and BUFNI, not only one side. If you tune only data buffers after seeing high EXCP counts on the data component, you might miss that index buffers are the bottleneck.

Local buffer pool versus global concepts

VSAM's primary buffering model for application access is local to the VSAM control block structure (ACB) for that open cluster in that address space (or the equivalent in your environment). It is not a single z/OS-wide shared VSAM cache of arbitrary dataset pages across all jobs. Cross-system record sharing (RLS) introduces additional protocols for coherency and coupling facility structures in configurations that use them; that is a separate tutorial. Beginners should first master the local picture: your DD or dynamic allocation attributes, your BUFND and BUFNI, your STRNO, and your program's pattern of access. Global performance still matters—LPAR memory pressure can cause paging of your buffers—but the first knob you reason about is still per-open tuning.

STRNO and overlapped I/O

STRNO specifies the number of concurrent I/O strings VSAM may schedule for the cluster. When STRNO is greater than one and the workload has independent operations that can overlap (for example, prefetch-like behavior or certain sequential pipelines), VSAM can exploit multiple strings. STRNO is not a buffer count; it is a concurrency limit. If you raise STRNO without enough buffers, you may not see benefit because each string still needs buffer slots to hold CIs in flight. Think of STRNO as how many delivery trucks can leave the warehouse at once; BUFND and BUFNI are how many loading bays exist. Trucks without bays wait.

How sequential and random patterns feel different

Sequential access reads the next record in collating order for the chosen mode. VSAM can advance through a CI linearly, then move to the next CI in the same CA, often reusing buffers in a predictable rotation. That pattern is friendly to modest BUFND because the working set per moment is small. Random access jumps by key or by address; the working set is the set of distinct CIs touched over your measurement interval. If your application touches ten percent of a billion-record file's CIs uniformly, no practical buffer count will hold the whole file; tuning shifts toward sensible CI sizes, free space, and reducing accidental full scans. Index random access adds another dimension because the B-tree depth determines how many index CIs each lookup touches. Beginners should map their application to one of three coarse buckets: mostly sequential, mostly random by key, or mixed. The bucket drives whether you emphasize BUFND, BUFNI, or both.

BUFSP and the bigger picture

BUFSP reserves additional buffer space beyond what BUFND and BUFNI imply in some configurations. It is easy to treat BUFSP as a magic "make it faster" field; in reality it changes how much storage VSAM can use for buffers in aggregate for that allocation. If you set BUFSP without understanding current BUFND and BUFNI, you may duplicate intent or starve other jobs. Use BUFSP when your storage tuning guide or measurement shows a specific need, not as a default.

Layers you may hear about in performance class

Beginners should not try to tune every layer at once. Start with SMF or your monitor to see which dataset and which component (data versus index) dominate EXCP or response time, then adjust BUFND, BUFNI, and STRNO in measured steps. Document each change; VSAM tuning is easy to second-guess later if nobody wrote down the before and after.

Example: DD keywords beginners recognize

The following JCL fragment is illustrative only; your site standards and z/OS level may require additional parameters or prohibit some combinations. Always consult the current IBM JCL Reference for AMP subparameters.

1
2
//VSIN   DD DSN=PROD.CUSTOMER.KSDS.DATA,DISP=SHR,
//         AMP=('BUFND=8','BUFNI=4','STRNO=2')

Here BUFND reserves eight buffers for data CIs, BUFNI reserves four for index CIs, and STRNO allows two concurrent strings. Whether these numbers are good depends entirely on CI size, record length, concurrency, and real storage. The pedagogical point is that all three appear together in real tuning discussions.

Practice exercises

1. Draw a keyed READ for a KSDS as a list of steps from "issue READ" through "return record," annotating where an index CI read and a data CI read occur.
2. For one batch job at your site, locate the VSAM DD and write down BUFND, BUFNI, STRNO, and BUFSP if present. Identify whether the program is sequential or random from documentation or JCL SORT steps.
3. Explain in one paragraph why raising BUFND alone might not reduce EXCP if index reads dominate.
4. Compare VSAM local buffering to Db2 buffer pools conceptually—what owns replacement, and what stores logical rows versus CIs?

Explain like I'm five

VSAM keeps a small pile of book pages on your desk so you do not run to the shelf every time you turn a page. Data pages are the story paragraphs. Index pages are the table of contents that tells you which chapter to open. If your desk is tiny, you keep shuffling pages back to the shelf and they take longer to get again. If your desk is big enough for the chapters you keep flipping between, reading feels fast. STRNO is how many hands can fetch pages at the same time; if only one hand is allowed, even a big desk might wait.

Test your knowledge