Payroll prints department 903; readers expect OPERATIONS, not a naked integer. State codes, product classes, tax brackets, and error messages appear millions of times in batch reporting—translating codes to text is table work. Easytrieve tables are in-memory reference files: you declare FILE name TABLE with ARG and DESC field layouts, supply rows instream in source or from an external sequential dataset at JOB start, then call SEARCH table WITH key GIVING result wherever JOB, PROGRAM, or SCREEN activities need decode. Broadcom 11.6 documents TABLE as a FILE parameter, not a standalone TABLE verb—tutorial indexes still name the topic TABLE because that is how shops describe the pattern. This overview maps the tables chapter: definition versus searching, binary search prerequisites, INSTREAM versus external maintenance, memory limits, comparison with LOOKUP statement tutorials, SQL ACCESS for large relational masters, and OCCURS arrays for programmer-controlled indexing. Beginners leaving this page should know when a table fits, where definitions live, and which follow-on tutorials drill into syntax details.
Without tables you hard-code IF chains or perform disk READ on a small master for every transaction line—readable for five codes, unmaintainable for five hundred. Tables centralize reference data: one definition, many SEARCH calls, O(log n) lookup per row when ARG is sorted. Report LINE statements print GIVING fields after successful SEARCH. File maintenance jobs validate codes with IF NOT table presence tests. Screen activities decode dropdown values before DISPLAY. The pattern is decode, not transactional update—tables are read-only for the run after load.
| Component | Role |
|---|---|
| FILE ... TABLE | Declares searchable reference file in Library |
| ARG field | Search key layout in each table row |
| DESC field | Value returned on match via GIVING |
| INSTREAM / external data | Row content loaded at compile or JOB initiation |
| ENDTABLE | Terminates instream row section |
| SEARCH | Runtime lookup WITH key GIVING result |
1234567891011121314151617FILE PAYROLL FB(80) DEPT 1 3 N AMOUNT 10 5 P 2 FILE DEPTTAB TABLE INSTREAM ARG 1 3 N DESC 5 20 A 901 HUMAN RESOURCES 902 FINANCE 903 OPERATIONS ENDTABLE JOB INPUT PAYROLL SEARCH DEPTTAB WITH DEPT GIVING WS-DEPT-NAME IF NOT DEPTTAB WS-DEPT-NAME = 'UNKNOWN' END-IF PRINT RPT1
DEPTTAB loads at compile from instream rows. Each payroll GET triggers SEARCH. IF NOT DEPTTAB handles invalid department codes without aborting the run. WS-DEPT-NAME feeds report LINE or procedures. This is the archetype every table tutorial variant extends—external files, multiple tables, longer ARG/DESC, max-table-entries sizing.
| Page | Focus |
|---|---|
| Table definition | FILE TABLE syntax, INSTREAM, external, ENDTABLE, limits |
| Table searching | SEARCH WITH GIVING, presence tests, error paths |
| LOOKUP / statements/table | Statement-level reference and SQL comparison |
| Binary search | Why ARG order matters algorithmically |
| Table performance | Memory, row counts, when not to use TABLE |
INSTREAM tables ship inside the load module—ideal for static codes that change only when developers recompile. Operations edits require source change and promote through compile pipelines. External tables read a sequential reference file at JOB initiation—operations refreshes data without recompile when layout is stable. Specify max-table-entries on external FILE declarations to reserve memory and catch overflow when row count grows past capacity. Both require ascending ARG and no duplicates at load time.
| Mechanism | Best for | Avoid when |
|---|---|---|
| FILE TABLE + SEARCH | Small static code lists in batch | Millions of keys or frequent relational joins |
| INDEXED FILE READ | Volatile master with one key per READ | Tiny static list where TABLE memory is cheaper than disk I/O |
| SQL ACCESS | Large relational reference | Ten-row code table needing zero DB overhead |
| OCCURS + loop | Custom indexing logic | Standard decode—reinventing binary search |
JOB INPUT loops issue SEARCH per detail record—most common pattern. PROGRAM activities decode parameters or shared working storage before calling other logic. SCREEN activities translate codes before terminal DISPLAY. Tables are not opened with GET—the runtime loaded them at initiation. Presence test IF table-file after SEARCH is mandatory when business rules require valid codes; skipping it prints blank or stale GIVING buffers on miss.
Entire table resides in memory for the execution pass. Hundreds or thousands of rows are typical; tens of thousands may be acceptable on generous regions. Millions of keys belong in database or indexed master files, not TABLE. Instream tables slightly increase object size; external tables add one sequential read at startup—usually negligible versus main file GET volume. Multiple tables in one program are normal—SEARCH each independently per key domain.
| Mistake | Consequence |
|---|---|
| Unsorted instream ARG keys | Wrong SEARCH matches or misses |
| Expecting TABLE statement keyword | Compile errors—use FILE TABLE |
| No IF NOT table after SEARCH | Silent bad descriptions on miss |
| Duplicate ARG rows | Undefined binary search behavior |
| Oversized reference in TABLE | Region abend or overflow |
A table is a poster on the wall with two columns: secret codes and real words. Before work starts, the computer memorizes the poster. When a payroll line says code 903, the computer looks at the poster and finds OPERATIONS. The poster must be in order from smallest code to biggest, and each code appears once. SEARCH is asking the poster a question; IF NOT table means the code was not on the poster so you pick a backup answer like UNKNOWN.
1. In Easytrieve 11.6, TABLE is documented as:
2. SEARCH uses which table field for matching?
3. Table ARG values must be:
4. INSTREAM tables are loaded:
5. When reference data is large and relational, prefer: