Search keys in ISPF (VSAM browse)

Searching a VSAM file sounds trivial until you distinguish string search from key search. String search answers, "Where does this sequence of bytes appear?" Key search answers, "Position me at the record whose primary key equals or is nearest to this business value." Only the second form leverages the KSDS index and completes quickly on large files. ISPF's classic FIND command is oriented toward text panels and sequential windows; it does not replace a keyed POINT operation. Vendor products and modern dialogs wrap VSAM services so operators can type an account number and land on the correct row. This page compares patterns, highlights duplicate-key pitfalls, shows sample command lines, and gives exercises so beginners build muscle memory without hammering production CPUs.

Primary key versus generic text

The primary key lives at a fixed offset inside each logical record for a KSDS. If you search for the ASCII digits 12345 with FIND but the key is packed decimal X'0123456C', you will not match even though the business meaning is the same. Keyed locate dialogs convert your typed value to the storage format before calling VSAM. Always align with the copybook: PIC 9(09) COMP fields require binary conversion; PIC X keys require left justify and padding rules your template encodes.

Command cheat sheet mindset

Worked style: keyed locate versus FIND

Imagine a loan KSDS keyed by packed 11-digit account. A keyed locate dialog accepts 00000012345, packs it, and positions the session. A naive FIND 12345 might match an unrelated text field in the narrative area. The keyed approach is both faster and semantically correct. Document the dialog field widths so operators do not drop leading zeros.

1
2
3
4
# Illustrative (syntax varies by product):
LOC 00000012345          -> keyed POINT using template PACK11
FIND 00000012345         -> byte scan; may miss packed representation
RFIND                    -> continue scan from cursor (string mode)

Duplicate keys and tie-breakers

When multiple rows share a primary key, VSAM orders them per the cluster definition. A locate lands on the first eligible duplicate. Walking the chain uses the same semantics as READ NEXT in a program: watch for end-of-chain when secondary keys inside the payload differ. Templates should expose those secondary fields so humans know which duplicate they edit.

ESDS and RRDS search notes

ESDS

Without an index, keyed jump is really RBA-based or sequential. Many tools expose "go to RBA" for specialists. Generic FIND still applies for byte patterns but remains sequential.

RRDS

Locate by relative record number when the tool supports slot addressing. Empty slots may confuse FIND if blanks match your pattern; filter empty rows first.

Performance and politeness

• Avoid RFIND through millions of rows during peak online windows.
• Split giant extracts into batch jobs when the goal is audit, not eyeball search.
• Prefer narrow templates so each GET moves less data across the session.

Relating to COBOL START

COBOL START with KEY IS EQUAL or KEY IS GREATER OR EQUAL mirrors keyed locate. When you teach developers and operators together, map the phrases: GTEQ in VSAM equals "first key at or after my value." EQUAL fails if no row matches; GTEQ positions at the next higher key when exact match is absent. Operators who understand that vocabulary debug faster with application teams.

Practical exercises

1. Build a tiny KSDS with three duplicate keys; practice locate then walk duplicates with vendor scroll commands.
2. Compare elapsed time between keyed locate and FIND across a sandbox file with at least 100,000 rows.
3. Translate one business key from display to packed hex by hand, then verify with a browse hex line.

Explain like I'm five

Think of a keyed search as the librarian using the card catalog to open the right drawer immediately. Think of FIND as walking down every aisle looking for a sticker on any book. If the library is small, walking is fine. If the library is huge, you want the card catalog (the index) every time.

Test your knowledge