BUFND stands for the number of data buffers the VSAM access method uses for the data component of your cluster when a job or address space opens that cluster. Each buffer is exactly one data control interval wide, so the memory footprint contributed by data buffering is approximately BUFND multiplied by the data CI size in bytes. That simple multiplication is why storage administrators pay attention when application teams request "just double the buffers" without doubling the region: the product grows linearly with BUFND and can squeeze other virtual storage consumers in the same address space. Beginners should treat BUFND as the primary knob for sequential throughput tuning on the data side, while remembering that index traversal for a KSDS is governed separately by BUFNI. This page focuses on BUFND alone: what it does, how it interacts with STRNO, where you code it, and how to reason about values without copying decades-old numbers that may not fit your CI size or your hardware cache behavior.
When your program or utility issues OPEN against a VSAM cluster, the access method builds internal structures and allocates buffers according to the attributes supplied by JCL AMP, by the ACB if you are in assembler or a language that fills equivalent fields, or by defaults when you specify nothing. Defaults exist to keep small programs running without deep tuning, but they are conservative about memory. A batch sort or report that reads millions of KSDS records sequentially will typically issue many fewer physical I/Os if BUFND is large enough that an entire control area of data CIs can be staged before the application consumes them, because the channel subsystem and disk cache can deliver long chains of blocks per disconnect. The same job with BUFND too small revisits the same tracks repeatedly as buffers are reused under LRU-style replacement, which shows up as higher EXCP counts in familiar monitors.
STRNO declares how many independent sequential strings VSAM should support on the same open instance—think of multiple browse cursors or concurrent sequential readers in specialized patterns. Strings compete for the same buffer pool, so IBM documents minimum BUFND values as a function of STRNO so that VSAM can honor concurrent positioning without running out of staging areas. If you raise STRNO for a complex program but forget BUFND, OPEN may fail or VSAM may raise a warning depending on release and options. The STRNO tutorial page in this site expands the string concept; here you only need the dependency mindset: BUFND is not chosen in isolation.
12//INVSAM DD DSN=USERID.MASTER.KSDS,DISP=SHR, // AMP=('BUFND=30','BUFNI=6','STRNO=2')
AMP accepts multiple subparameters; your site may prefer the parenthesized comma style without quotes for numeric pairs. BUFND=30 here asks for thirty data CI buffers. Whether thirty is wise depends on CISZ: thirty times 8192 bytes is a quarter megabyte just for data buffers, before BUFNI and program storage. Always multiply before approving in constrained regions.
| Pattern | BUFND focus | Watch out |
|---|---|---|
| Full-file sequential batch | Often set to at least the number of data CIs in one control area (CA) plus one, or higher if memory allows, so each CA can be staged with fewer channel programs. | Region size must hold BUFND times CISZ plus index buffers and program working storage. |
| Keyed random read mostly | Moderate values (for example a handful to a few dozen) often suffice because each call touches few data CIs; focus may shift to BUFNI. | Hot keys that hit the same CI still benefit from a few extra data buffers for reuse. |
| Skip-sequential | Between sequential and random; test both BUFND and BUFNI because access jumps force index repositions. | Buffer pool churn can reduce effective caching when the job alternates patterns. |
DEFINE CLUSTER BUFFERSPACE (or BUFSP in define grammar) influences cataloged minimum buffer space and CI sizing at define time. BUFND is a runtime count of buffers at open. A well-defined cluster with thoughtful BUFFERSPACE can still perform poorly if every job opens it with BUFND=2. Conversely, enormous BUFND cannot fix a pathological CI size or a random workload that jumps across the file so much that no buffer reuse occurs. Tuning is layered: define-time attributes set the playing field; open-time BUFND and BUFNI decide how aggressively each player uses the field.
When clusters use extended format or larger CI sizes for compression-friendly layouts, each BUFND slot consumes more bytes than older 4 KB designs. Capacity planners should multiply BUFND by the current CISZ after any REPRO to a new cluster with different geometry; a job that survived BUFND=40 on 4 KB CIs may not fit the same region after migration to 32 KB CIs without lowering BUFND or raising REGION. The arithmetic is mundane but failure modes are dramatic when REGION=0M jobs abend during OPEN after a silent CISZ change elsewhere in the project.
BUFND is how many pages of the storybook you keep open on your desk at the same time. If you keep thirty pages open, you can read ahead very fast. If you keep only two pages open, you spend a lot of time walking back to the shelf to fetch the next page.
1. Each BUFND buffer holds how much data?
2. BUFND is most commonly coded in which place?
3. For heavy sequential reads, BUFND should generally be: