Indexed files are the keyed heart of mainframe data: one employee number opens one personnel record, one account ID opens balances and status, one policy key opens coverage rows. In Easytrieve you declare them FILE MASTER INDEXED with UPDATE when maintenance is allowed. The access method underneath on z/OS is VSAM KSDS, but the Easytrieve abstraction is keyed READ and browse GET—not the COBOL ceremony of alternate indexes in every shop. Beginners confuse indexed with sequential when both use FB record formats; the difference is READ by key versus only forward GET through arrival order. This page teaches INDEXED FILE declaration, aligning DEFINE keys with IDCAMS, random READ for lookup, GET for key-ordered browse, duplicate key behavior, POINT positioning, HOLD for update, and the canonical transaction-plus-master job pattern. Study this after VSAM overview and before RRDS relative files.
1234567FILE EMPLOYEE INDEXED UPDATE FB(300 1800) DEFINE EMPLOYEE EMP-KEY 9 1 * primary key — must match KSDS define EMP-NAME A 20 10 DEPT-CODE A 4 30 SALARY P 9.2 34
INDEXED tells Easytrieve to use keyed access services. UPDATE permits WRITE and DELETE on existing records when JCL disposition allows. Omit UPDATE for inquiry-only programs. FB lengths must match the VSAM record size. Non-mainframe platforms may use INDEXED for native indexed files; field and key rules follow that platform's FILE chapter.
The primary key position, length, and data type in DEFINE must match the KSDS definition your storage team created with IDCAMS DEFINE CLUSTER. If KSDS key is 9 bytes numeric at offset 0 but DEFINE places a 5-byte key at offset 10, READ appears to work intermittently while returning wrong records or not-found for valid keys. Pack versus zoned display for numeric keys must match upstream COBOL copybooks. When alternate indexes exist in the organization, Easytrieve primary key READ uses the base key unless release-specific alternate key support is documented.
| Check item | Where to verify | If wrong |
|---|---|---|
| Key length | IDCAMS LISTCAT KEYS | READ not-found for valid keys |
| Key offset | Copybook or DEFINE MAP | Wrong record in buffer |
| Data type P vs A | Upstream COBOL PIC | Leading zeros mismatch |
| Duplicate option | KSDS define | DUPLICATE vs not-found confusion |
READ file-name retrieves the record identified by the current key value in the key field—often after MOVE transaction key to master key field. Use STATUS to capture FILE-STATUS. Test IF NOT file-name or documented not-found constant before using name or salary fields. READ is how secondary master lookup runs while JOB INPUT drives sequential transactions.
1234567891011121314151617FILE TRANSACT SEQUENTIAL FB(80 27920) FILE EMPLOYEE INDEXED FB(300 1800) DEFINE TRANSACT T-EMP-NO 9 1 DEFINE EMPLOYEE EMP-KEY 9 1 EMP-NAME A 20 10 JOB INPUT TRANSACT MOVE T-EMP-NO TO EMP-KEY READ EMPLOYEE STATUS IF NOT EMPLOYEE PUT ERRFILE EXIT END-IF PRINT EMP-NAME
GET on INDEXED files walks records in key sequence—useful for full master scans, control-break reports sorted by key, or update-every-record jobs. JOB INPUT on INDEXED with UPDATE may combine automatic GET HOLD in batch so the held record can be rewritten. Test EOF at end of cluster browse. GET is not a substitute for READ when you need one specific key from a transaction-driven loop unless you POINT first.
POINT establishes position in an indexed or sequential file for subsequent GET operations. Broadcom restricts combining POINT with GET PRIOR in certain orders—read POINT documentation before mixing direction changes. START procedures in JOB activities sometimes POINT to a starting key for partial file processing. Wrong positioning causes skipped records or repeated rows in reports.
FILE UPDATE plus batch GET may hold records for in-place rewrite. HOLD on GET explicitly requests hold; NOHOLD overrides default hold when UPDATE is on. CICS online: NOHOLD default, HOLD blocks browse GET—use READ to update. Salary change jobs READ or GET HOLD, MOVE new values, WRITE or equivalent update verb per release. Deleting keyed records requires UPDATE and DELETE authority on FILE and JCL.
When IDCAMS defined KSDS with duplicates, multiple records share one key value. READ may return the first duplicate; GENERIC or DUPLICATE handling per release retrieves next duplicate under same key. Condition constant DUPLICATE signals duplicate-key situations in browse. Design reports to process all duplicates when business rules require—not only the first match.
Canonical pattern: sequential transaction file automatic input, indexed master secondary READ. Inverse pattern: JOB INPUT indexed master for full walk, PUT sequential extract. Avoid READ inside tight loops without need—batch shops optimize with table LOAD or SORT join when masters fit memory; INDEXED READ per row is still the clearest beginner pattern.
STATUS on READ sets FILE-STATUS for explicit branching. Not-found is normal for optional lookups—write to error file rather than abending. Duplicate, invalid key length, and authority errors need operations playbooks. LOG not-found counts in FINISH for reconciliation with transaction control totals.
An indexed file is a library where every book has a call number on the spine. READ is asking the librarian for the book with one exact call number—they hand you that book. GET is walking along the shelves in call-number order reading each book one by one. The call number must be written exactly the way the library catalog expects or you get "not found." UPDATE means you are allowed to cross out words in a book and write new ones; without it you may only read.
1. INDEXED on FILE designates:
2. Random retrieval by key value uses:
3. Key field in DEFINE must:
4. UPDATE on INDEXED FILE is needed to:
5. GET on INDEXED file without key typically: