STRNO is the AMP and ACB parameter that tells VSAM how many sequential strings to allocate when a dataset is opened. A string, in this specialized VSAM sense, is not a character string in COBOL; it is the access method's internal scaffolding for a sequential position through the file, including enough state to support READ NEXT, READ PREVIOUS, and repositioning after START in languages that expose those operations. When only one part of your program walks the file at a time, STRNO=1 is the natural mental model and often matches defaults. When two independent parts of the same program—or two cooperating modules in the same address space—need to keep separate cursors into the same VSAM cluster without closing and reopening the file between them, you raise STRNO so VSAM can track multiple positions concurrently. That power is not free: each string participates in buffer scheduling, which is why IBM couples STRNO with minimum BUFND guidance. This page explains STRNO in beginner-friendly language, ties it to BUFND and BUFNI pages, and warns about the symptoms of under-provisioning.
Imagine a long scroll instead of a paginated book. One bookmark tracks where the summary reader paused; another bookmark tracks where the detail auditor paused. STRNO is how many bookmarks VSAM agrees to maintain simultaneously on that scroll. If you only paid for one bookmark but two readers need independent positions, someone loses their place. STRNO is how you pay for extra bookmarks at open time rather than improvising illegal sharing of a single bookmark behind the access method's back.
In batch COBOL with native VSAM, you might never set STRNO explicitly because your access pattern is a single sequential READ loop. In more advanced patterns—certain database-like layers, or programs that interleave two browse passes—your runtime may require STRNO>1. CICS file control often abstracts strings differently; when you are in CICS, follow CICS documentation for browse and file sharing instead of assuming raw JCL AMP from batch tutorials applies unchanged. The important beginner lesson is to recognize the word STRNO when it appears in dumps, traces, or performance guides so you know the conversation is about concurrent sequential contexts, not about textual data.
VSAM must keep per-string control information and must be able to read ahead or behind along each string's path without constantly colliding with the other strings' buffer replacements. That is why raising STRNO without raising BUFND is a classic mistake during optimization attempts. The BUFND page already mentioned this dependency; here the emphasis is reversed: whenever you increase STRNO, schedule a buffer review in the same change window. Likewise, if a vendor document says "set STRNO=4 for this utility pattern," treat the vendor's BUFND recommendation as mandatory reading, not optional commentary.
| Scenario | STRNO | Buffer note |
|---|---|---|
| Single sequential pass | Often STRNO=1 is enough; simplest default thinking. | BUFND sized for sequential throughput as in the BUFND page. |
| Program opens one file but issues two independent browse cursors | STRNO at least 2 so VSAM tracks two sequential contexts. | BUFND must satisfy documented minima vs STRNO; verify in IBM manual. |
| High parallelism inside one address space | Larger STRNO; watch memory and VSAM limits. | BUFNI may also rise if each string hammers different index branches. |
12//MULTVS DD DSN=USERID.LOG.KSDS,DISP=SHR, // AMP=('STRNO=4','BUFND=24','BUFNI=6')
The numbers illustrate coupling: four strings with twenty-four data buffers leaves headroom beyond naive four-plus-one arithmetic because sequential prefetch benefits from extra staging. Always replace this example with values validated for your CI sizes and manual minima.
Picture a reconciliation program that walks the VSAM file forward for debits while simultaneously walking another string backward for credits on the same open instance to avoid sorting into a temp dataset. Each walk needs its own STRNO slot so VSAM can remember separate RBAs and sequential states. If the developer coded STRNO=1 because the tutorial JCL said so, the second walk corrupts the first walk's position or fails outright depending on language checks. The fix is not cleverer COBOL; it is raising STRNO and BUFND together, then rerunning with the same production keys to prove stability. This scenario is rare in hello-world samples but common enough in maintenance shops that recognizing it saves weeks of debugger time.
Assembler programmers see STRNO surface in ACB macros; high-level language users see it indirectly through runtime generation of DD AMP. Either way, the abstraction is the same: purchase enough string slots up front so the access method never has to guess how many independent sequential stories you are telling on one dataset handle.
STRNO is how many fingers you can keep on different spots in a line of toy cars without moving the other fingers. If you only have one finger but two friends want to point at different cars, you need more fingers—or in VSAM terms, a higher STRNO.
1. STRNO primarily controls what?
2. Raising STRNO without adjusting buffers may:
3. STRNO is typically coded on: