MODULE 9 · INDEXED FILES AND SORT · 2/8

Random READ by key

12 min30 XPExercise

A random read fetches one record by its key. The pattern is always the same: put the key you want into the RECORD KEY field, then READ.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PARTLKUP.
       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT PART-FILE ASSIGN TO PARTMAST
               ORGANIZATION IS INDEXED
               ACCESS MODE IS RANDOM
               RECORD KEY IS PART-NO
               FILE STATUS IS WS-FS.
       DATA DIVISION.
       FILE SECTION.
       FD PART-FILE.
       01 PART-REC.
          05 PART-NO      PIC X(4).
          05 PART-DESC    PIC X(12).
       WORKING-STORAGE SECTION.
       01 WS-FS           PIC XX.
          88 FS-OK        VALUE "00".
       01 WS-WANTED       PIC X(4).
       PROCEDURE DIVISION.
           OPEN OUTPUT PART-FILE
           MOVE "A100BOLT M8" TO PART-REC
           WRITE PART-REC
           CLOSE PART-FILE

           OPEN INPUT PART-FILE
           IF NOT FS-OK
               DISPLAY "OPEN FAILED, STATUS " WS-FS
               STOP RUN
           END-IF
           MOVE "A100" TO WS-WANTED
           PERFORM FIND-PART
           MOVE "Z999" TO WS-WANTED
           PERFORM FIND-PART
           CLOSE PART-FILE
           STOP RUN.

       FIND-PART.
           MOVE WS-WANTED TO PART-NO
           READ PART-FILE
               INVALID KEY
                   DISPLAY WS-WANTED " NOT ON FILE, STATUS " WS-FS
               NOT INVALID KEY
                   DISPLAY WS-WANTED " IS " PART-DESC
           END-READ.

Output:

A100 IS BOLT M8
Z999 NOT ON FILE, STATUS 23

(The first half of the program just creates a one-record file so the example runs on its own. In real jobs the master already exists.)

The pieces

ACCESS MODE IS RANDOM means every READ is by key. There is no "next record" in this mode.
INVALID KEY runs when the read fails because of the key, here status 23, record not found. NOT INVALID KEY runs on success. Close the statement with END-READ so the scope is unambiguous inside a paragraph.
Keep the requested key in your own field (WS-WANTED). After a failed READ the contents of the record area are not guaranteed, so don't report the error from PART-NO.
OPEN INPUT is enough to read. You need OPEN I-O only when you will also change the file, which comes two lessons from now.

Why not just scan the file?

A sequential scan to find one key reads, on average, half the file. A KSDS read goes through the index, a small tree of key ranges, and touches a handful of blocks whatever the file size. That is why online transactions (CICS) and batch "lookup" steps are built on keyed reads while full-file processing stays sequential.

On the job

A classic batch design is a sequential transaction file driving random reads against an indexed master: for each order, read the customer by key; for each claim, read the policy. When the transactions are sorted in key order, VSAM's buffers make those "random" reads almost as fast as a sequential pass.

Your task

The branch system sends account numbers to look up against the account master, a VSAM KSDS.

DD ACCTMAST — indexed, key ACCT-ID, 35-byte records:

Field	PIC	Notes
`ACCT-ID`	`X(6)`	record key
`ACCT-NAME`	`X(20)`
`ACCT-BAL`	`9(7)V99`	balance

Input (stdin): one account number per line, ending with END.

For each request:

found → display ACCT-ID, a space, ACCT-NAME, a space, and the balance edited with Z,ZZZ,ZZ9.99
not found → nnnnnn NOT FOUND (STATUS 23), using the real FILE STATUS

Finish with LOOKUPS: nnn FOUND: nnn (both PIC 9(3)).

300100 GRACE HOPPER             1,250.00
999999 NOT FOUND (STATUS 23)
LOOKUPS: 002 FOUND: 001

← Indexed files and VSAM Loading a KSDS with WRITE →

Run your program to see its output here. The first visible test's input and datasets are used.

Submit to grade your program against every test.