Indexed & Relative File Organization

COBOL Intermediate/Advanced

Chapter 1 · Indexed & Relative File Organization

Fundamentals' own Chapter 8 covered one real file shape: sequential, read front to back, record after record. Real production COBOL constantly needs something faster — jumping directly to one specific customer, one specific order — without reading everything that comes before it. Two more real organizations make that possible.

Three Real File Organizations, Compared

Organization	How a Record Is Genuinely Located
SEQUENTIAL	Contiguous, read one after another — Fundamentals' own real shape
INDEXED	Located by a real key value via a genuine index — not by position at all
RELATIVE	Located by its own real ordinal position — record 10 genuinely has key 10

Indexed Files: Real Key-Based Lookup

A real indexed file — implemented in practice by technologies like ISAM and VSAM — carries one or more genuine indexes letting records be found directly by key, and sorted on them. Every real record needs a unique RECORD KEY; a real, separate ALTERNATE RECORD KEY can also be declared, and — unlike the primary key — it doesn't have to be unique, as long as WITH DUPLICATES is stated:

SELECT CUSTOMER-FILE ASSIGN TO "CUSTMSTR.DAT"
    ORGANIZATION IS INDEXED
    ACCESS MODE IS DYNAMIC
    RECORD KEY IS CUST-ID
    ALTERNATE RECORD KEY IS CUST-NAME WITH DUPLICATES
    FILE STATUS IS WS-FILE-STATUS.

FD  CUSTOMER-FILE.
01  CUSTOMER-RECORD.
    05 CUST-ID       PIC 9(6).
    05 CUST-NAME     PIC X(30).
    05 CUST-BALANCE  PIC S9(7)V99.

Relative Files: The Real Position Is the Key

A real relative file works differently again — there's no separate key field stored in each record at all. A record's own ordinal position in the file genuinely is its key, tracked in a real RELATIVE KEY field:

SELECT ORDER-FILE ASSIGN TO "ORDERS.DAT"
    ORGANIZATION IS RELATIVE
    ACCESS MODE IS RANDOM
    RELATIVE KEY IS WS-ORDER-NUM
    FILE STATUS IS WS-FILE-STATUS.

A Real, Easy-to-Miss Consequence Because position genuinely is the key, writing a real record with relative key 5 before records 1 through 4 exist can require the file system to create empty placeholder records to fill that gap — a real structural quirk indexed files simply don't have, since an indexed file's own key values never need to be contiguous.

ACCESS MODE: SEQUENTIAL, RANDOM & DYNAMIC

Mode	What It Genuinely Allows
SEQUENTIAL	Records read in real key/positional order, one after another — Fundamentals' own only real option
RANDOM	Any single record located directly by its real key, with no need to read what comes before it
DYNAMIC	Both at once — real sequential reads and real direct-by-key reads, freely mixed in the same program

A real random read against an indexed or relative file uses INVALID KEY in place of Fundamentals' own AT END, since there's no "end of file" concept for a single direct lookup — only whether that specific real key was found:

MOVE 100234 TO CUST-ID.
READ CUSTOMER-FILE
    INVALID KEY
        DISPLAY "CUSTOMER NOT FOUND"
    NOT INVALID KEY
        DISPLAY "FOUND: " CUST-NAME
END-READ.

START: Positioning for a Sequential Read

START is a real statement unique to indexed and relative files, in real sequential or dynamic access — it positions the file at a specific real key so a subsequent sequential READ NEXT begins from exactly that point, rather than from the very beginning:

MOVE 100000 TO CUST-ID.
START CUSTOMER-FILE KEY IS NOT LESS THAN CUST-ID
    INVALID KEY DISPLAY "NO RECORDS FOUND FROM THIS POINT"
END-START.

READ CUSTOMER-FILE NEXT RECORD
    AT END DISPLAY "END OF FILE"
END-READ.

Real relational operators beyond EQUAL TO — GREATER THAN, NOT LESS THAN, GREATER THAN OR EQUAL TO — let START position at the first record satisfying a real range condition, not just an exact match. Leaving out the KEY phrase entirely defaults to a real EQUAL TO the file's own prime record key.

REWRITE & DELETE: Genuinely New Verbs

Fundamentals' own WRITE only ever adds a record. Two further real verbs, valid only against a file opened I-O, work on records that already exist:

MOVE 100234 TO CUST-ID.
READ CUSTOMER-FILE
    INVALID KEY DISPLAY "NOT FOUND"
END-READ.

ADD 500.00 TO CUST-BALANCE.

REWRITE CUSTOMER-RECORD
    INVALID KEY DISPLAY "REWRITE FAILED"
END-REWRITE.

DELETE CUSTOMER-FILE
    INVALID KEY DISPLAY "DELETE FAILED"
END-DELETE.

REWRITE Replaces; It Doesn't Add REWRITE genuinely replaces an existing real record in place — it's not supported at all for a line-sequential file, and it always requires a file already opened I-O, never OUTPUT. DELETE is equally real-and-specific: valid only against indexed and relative files, freeing that key's own real storage for later reuse.

Hands-On Exercises

Exercise 1

Using this chapter's own real material, explain in your own words why a random READ against CUSTOMER-FILE uses INVALID KEY rather than Fundamentals' own AT END, and why "end of file" genuinely isn't a meaningful concept for that specific kind of read.

📄 View solution

Exercise 2

Using this chapter's own real material, explain in your own words why writing a relative-file record with RELATIVE KEY 5, before any record with key 1 through 4 exists, can genuinely require the file system to create empty placeholder records — and why an indexed file's own RECORD KEY has no equivalent requirement.

📄 View solution

Exercise 3

Using this chapter's own real REWRITE example, explain in your own words why the file must genuinely be opened I-O rather than OUTPUT for that statement to work, and why attempting a REWRITE before a successful READ of the same real record would genuinely fail.

📄 View solution

Chapter 1 Quick Reference

ORGANIZATION IS INDEXED — real key-based lookup (ISAM/VSAM in practice); RECORD KEY unique, ALTERNATE RECORD KEY ... WITH DUPLICATES optional and non-unique
ORGANIZATION IS RELATIVE — real ordinal position doubles as the key (RELATIVE KEY); writing ahead of existing records can force real empty placeholders
ACCESS MODE SEQUENTIAL/RANDOM/DYNAMIC — real front-to-back reading, real direct-by-key lookup, or both freely mixed
INVALID KEY — the real random-access equivalent of AT END
START — positions for a sequential read from a specific real key; real relational operators beyond EQUAL TO
REWRITE — replaces an existing real record (I-O mode only); DELETE — removes one (indexed/relative only, I-O mode only)