VSAM BUFNI (Index Buffers)

BUFNI is the count of index buffers VSAM allocates when your job opens a KSDS. Each index buffer holds exactly one index control interval—the same structural unit described in the index component and sequence set tutorials, only now considered as a cached copy in memory rather than as a image on disk. When an application issues a READ by key, VSAM walks the B-tree style index from the highest level down to the sequence set entry that identifies the data CI, then reads the data CI itself. Every index level miss in the buffer pool becomes a physical index read; therefore keyed workloads that previously looked "CPU bound" sometimes collapse into simple index buffer starvation once someone traces the I/O. BUFNI is the knob that trades memory for fewer index EXCPs. This page explains BUFNI in isolation: how it differs from BUFND, how index depth and concurrency shape sensible values, and how to combine LISTCAT intuition with measurement instead of folklore.

Keyed Lookup Walkthrough

Picture a medium-sized KSDS. A keyed read might touch one index CI at the top level, another at the next level, then a sequence set CI, then finally the data CI. In the worst case none of those CIs are in the pool, producing four index-related reads before the data read. If BUFNI is large enough that all touched index CIs remain resident across a burst of similar keys that share branches, later reads skip some of those I/Os entirely. If BUFNI is tiny, the pool thrashes and each read redoes the same index path from disk. That qualitative story is more important than memorizing a single magic integer for BUFNI because the correct integer scales with index CI size, number of levels, and number of concurrent tasks.

BUFNI vs BUFND: Division of Labor

BUFND stages data CIs; BUFNI stages index CIs. Random OLTP workloads that jump across key space still traverse the index on almost every call, so BUFNI often moves to the foreground in tuning discussions even though the bytes per index CI may be smaller than data CIs. Sequential jobs that march forward in key order still use the index, but once the sequence set entry for the current CA is hot, BUFNI pressure relaxes relative to BUFND pressure. When you see performance guides recommending "BUFNI about equal to index levels" for random access, they are summarizing this idea in a compact rule; your file may need more than that rule if tasks compete or if the index is wide due to key design.

Depth and Concurrency

Example AMP Block

1
2
//CUSTDD   DD   DSN=PROD.CUSTOMER.KSDS,DISP=SHR,
//            AMP=('BUFND=12','BUFNI=8','STRNO=3')

Here BUFNI=8 is explicitly higher than a minimal two-or-three buffer guess because the workload is assumed to be random reads with multiple strings. The numbers are not a recommendation to paste into production; they illustrate how operators encode intent in JCL comments nearby (which this tutorial omits for brevity but you should not omit in real change packages).

Alternate Indexes and Paths

When applications use alternate indexes and paths, index buffer pressure can involve more than the base cluster's primary index. Debugging performance may require looking at which ACB opened which path and whether separate DD statements supply different AMP values. Beginners should not assume one BUFNI applies magically to every path in a complex application unless the architecture truly opens a single shared DD.

Practical Steps

1. Identify whether the slow job is KSDS and keyed.
2. Estimate index levels after representative load (LISTCAT / tooling).
3. Try BUFNI at least equal to levels, then increase while monitoring index I/O.
4. Re-evaluate when keys or CI sizes change, because depth may shift silently after reorganization.

Duplicate Keys and Wide Indexes

NONUNIQUEKEY clusters can grow wider index entries at the sequence set because multiple data records share the same key value and VSAM must disambiguate them. That width increases the chance that a single index CI fills sooner and splits, which in turn changes which sibling CIs a random read touches. BUFNI that was ample for a unique-key file might become marginal after a bulk load of duplicates unless you revisit both index CI sizing and buffer counts. Always retest BUFNI after application changes that introduce duplicate key patterns, not only after hardware changes.

Finally, remember that index buffers compete with data buffers for the same address space budget. Raising BUFNI without monitoring total footprint can crowd out BUFND and accidentally hurt sequential phases that share the job step. Balance is iterative, not one-dimensional.

Explain Like I'm Five

The index is the table of contents in the back of a choose-your-own-adventure book. BUFNI is how many table-of-contents pages you can keep on your desk. If you can keep every page you need open at once, you find the next story page quickly. If you can keep only one table-of-contents page open, you keep running back to the shelf.

Test Your Knowledge