Explain File Handling: SEQUENTIAL vs INDEXED Organization in IBM Mainframes

3 / 60

COBOLintermediate

File Handling: SEQUENTIAL vs INDEXED Organization

Distinguish sequential and indexed file organizations in COBOL and know which I/O verbs and access modes apply to each.

A COBOL program's file organisation decides how records can be reached, and it is declared in the ENVIRONMENT DIVISION.

Sequential access is reading a novel page by page; indexed random access is looking up a specific topic in the back index of a textbook and flipping straight to page 342 without touching pages 1 through 341.

Key Concepts

    SELECT CUST-FILE ASSIGN TO CUSTFILE
        ORGANIZATION IS INDEXED
        ACCESS MODE IS DYNAMIC
        RECORD KEY IS CUST-ID
        FILE STATUS IS WS-STATUS.

SEQUENTIAL: records in physical order, start to finish. OPEN, READ, WRITE, CLOSE. There is no way to jump to a particular record.

OPENREADWRITECLOSE

That suits batch work that touches everything: a daily transaction extract, a full-file report, a monthly statement run. Reading ten million records in order is efficient — it is reading them out of order that is not possible.

INDEXED (a VSAM KSDS): reach a record by key. The file carries an index, so a key lookup goes almost straight to the record.

Three access modes.

    SEQUENTIAL   read in key order, start to finish
    RANDOM       jump directly to a key; no reading forward
    DYNAMIC      both, within one OPEN

DYNAMIC is the one worth understanding, because it enables the common pattern: position at a key, then read forward from there.

    MOVE 'C5000' TO CUST-ID
    START CUST-FILE KEY IS >= CUST-ID
    PERFORM UNTIL EOF
        READ CUST-FILE NEXT RECORD
    END-PERFORM

"Every customer from C5000 onwards" needs a direct jump and then sequential reading. RANDOM alone cannot read forward; SEQUENTIAL alone cannot jump.

The standard interview question. "You need one customer record out of ten million — what do you choose?"

INDEXED with RANDOM access. A sequential scan reads on average five million records to find one; the index resolves it in a handful of reads regardless of file size.

The follow-up is worth being ready for: if the program needs every record, sequential is faster than indexed, because indexed access follows the index for each record instead of streaming the file.

Always declare FILE STATUS. Without it, an I/O failure raises no error you can act on and the program continues on bad assumptions.

    00  successful
    10  end of file
    23  record not found
    35  file not found -- usually a missing DD statement in the JCL

Checking that two-character field after every operation is what separates a program that fails clearly from one that produces wrong output quietly.

What the interviewer is probing.1. "When would you choose indexed over sequential?" Probing: the fit. Stalls: "Indexed is better." Moves up: when you need direct access by key or updates in place; sequential is faster and simpler when you process every record in order.

2. "What must you check after every file operation?" Probing: the discipline. Stalls: "Nothing." Moves up: the FILE STATUS field — relying on the runtime to abend means a missing record reads as a crash rather than a handled condition.

3. "What does FILE STATUS 35 mean?" Probing: practical knowledge. Stalls: "An error." *Moves up:* the file was not found on an OPEN — usually a JCL DD statement problem rather than a program problem.

4. "Why is a dynamic access mode useful?" Probing: the capability. Stalls: "Flexibility." Moves up: it lets one program both READ by key and READ NEXT sequentially, which is how you position to a key then walk forward.