COBOLintermediate
Tables and OCCURS Clause
Understand how COBOL implements arrays via OCCURS and how INDEXED BY drives efficient table access.
COBOL's array equivalent is the table, declared with an OCCURS clause on a group or elementary item. This topic matters in interviews because tables are everywhere in real mainframe code — rate tables, lookup tables loaded from a file at program start, multi-occurrence detail records — and misunderstanding indexing versus subscripting is a common source of both bugs and inefficient code.
A COBOL table is a wall of labeled pigeonholes fixed in place at compile time — INDEXED BY gives you a fast pointer finger that jumps straight to a slot instead of counting from the first pigeonhole every time.
Key Concepts
1
A basic table is declared as 05 TABLE-ITEM OCCURS 50 TIMES PIC X(10), creating 50 contiguous instances referenced by a subscript, TABLE-ITEM(5). COBOL also supports INDEXED BY, which creates a special index data item optimized for table addressing — indices are stored as binary displacement values and are generally faster than plain numeric subscripts, especially inside PERFORM VARYING loops that walk the table.
05 TABLE-ITEM OCCURS 50 TIMES PIC X(10)TABLE-ITEM(5)
2
OCCURS DEPENDING ON creates a variable-length table, where the actual number of occurrences is driven by another data item's value at runtime — critical for records where the number of detail lines varies, like a variable number of line items on an order record. This introduces subtlety: the DEPENDING ON field must be set correctly before the table area is referenced, or you risk reading/writing beyond the populated portion.
3
Multi-dimensional tables are built by nesting OCCURS clauses in subordinate group items, and are walked using nested PERFORM VARYING ... AFTER loops. A frequent interview question is to explain the difference between SEARCH (linear) and SEARCH ALL (binary, requires the table to be sorted and have an ASCENDING/DESCENDING KEY clause) for locating a value in a table efficiently.