Mainframe batch reports are full of codes that mean nothing to business readers. Status S, department 417, plan code X7—the raw values are correct for machines but useless on a printed listing without translation. Easytrieve LOOKUP is the everyday pattern for that translation: load a reference table once, search it by key thousands of times per run, and print human-readable text beside each code. Tutorial indexes name the topic LOOKUP because developers describe the work as looking up a key, even though Broadcom 11.6 Language Reference documents SEARCH as the executable statement. This page focuses on practical lookup scenarios beginners encounter: department and status decodes, zip-to-city examples, class code tables, error handling when keys are missing, instream versus external maintenance, SCREEN inquiry lookups, and decision criteria for TABLE lookup versus SQL FILE. You will learn not just syntax but when lookup belongs in your design and how operations teams maintain the reference data your SEARCH statements depend on.
LOOKUP is not a fourth-generation mystery feature—it is disciplined reference-data design. You separate codes on transaction files from descriptions on table files. Transaction FILE definitions stay lean; TABLE definitions hold the decode dictionary. Activity logic bridges them with SEARCH. That separation lets operations update department names in a maintenance file without touching payroll extraction logic, as long as department numbers on input remain stable. Instream tables trade that flexibility for compile-time simplicity: ten status codes embedded in source are perfect until someone adds an eleventh code and requires a recompile.
1234567891011121314151617DEFINE DEPT-DESC W 25 A FILE DEPTLKP TABLE INSTREAM ARG 1 3 N DESC 5 25 A 100 FINANCE 200 LEGAL 417 DATA CENTER OPS 903 OPERATIONS ENDTABLE JOB INPUT EMPFILE SEARCH DEPTLKP WITH EMP-DEPT GIVING DEPT-DESC IF NOT DEPTLKP DEPT-DESC = '** INVALID DEPT **' END-IF PRINT EMPLIST
EMP-DEPT on the input file carries numeric department. SEARCH copies the matching DESC into DEPT-DESC for LINE printing. The visible asterisk default makes invalid codes obvious on the listing—better than a blank column that hides data quality problems until an auditor asks questions.
Broadcom JOB Activities documentation includes a zip decode example. Geographic reference tables often use numeric ARG for zip and alphanumeric DESC for city or post office name. Keys must sort numerically ascending—zip 02108 before 10001. Leading zeros in alphanumeric ARG definitions require consistent padding in both table maintenance and input fields or searches fail on otherwise valid zips.
1234567891011121314DEFINE POST-OFFICE W 20 A FILE ZIPTABLE TABLE 5000 ARG 1 5 N DESC 7 20 A JOB INPUT PERSNL IF STATE = 'DC' 'IL' SEARCH ZIPTABLE WITH ZIP GIVING POST-OFFICE IF NOT ZIPTABLE POST-OFFICE = 'BAD ZIP CODE' END-IF PRINT STATERPT END-IF
Conditional JOB logic limits lookup to states where zip decode matters for the report. FILE TABLE 5000 reserves space for five thousand zip rows loaded from an external maintenance dataset at JOB initiation—typical when postal reference data is too large for INSTREAM but still manageable in memory.
12345678PROGRAM NAME CLASSDEMO MOVE '1012' TO CLASS-CODE SEARCH CLASSES WITH CLASS-CODE GIVING CLASS-NAME IF CLASSES DISPLAY CLASS-NAME ELSE DISPLAY 'CLASS NOT FOUND' END-IF
PROGRAM activities support quick lookup tests before embedding SEARCH in production JOB logic. DISPLAY writes to SYSPRINT so developers verify table content without running full batch JCL. Replace DISPLAY with PRINT or file WRITE in production; gate diagnostic DISPLAY behind a debug W flag if you keep it for troubleshooting.
| Strategy | Effect | When to use |
|---|---|---|
| Default literal in GIVING field | Report shows visible placeholder | Operators must see bad codes on standard listing |
| GOTO JOB skip record | Record excluded from output | Invalid code makes entire row untrustworthy |
| PRINT exception report | Bad keys collected separately | Audit team reconciles reference data monthly |
| Increment error counter | Summary TITLE shows total failures | Management wants volume metrics not row detail |
Choose INSTREAM when codes are few, change rarely, and shipping them inside the program object is acceptable. Choose external FILE TABLE when operations maintains reference data as a sequential dataset—department reorganizations, new product lines, expanded zip lists. External tables need sorted maintenance jobs upstream of Easytrieve. Document the dataset name in run books and version control the generator JCL that rebuilds ARG/DESC files after spreadsheet edits.
Online inquiry programs SEARCH tables in BEFORE-SCREEN or AFTER-SCREEN procedures. Operator enters customer type code; AFTER-SCREEN SEARCHes TYPE-TAB and MOVEs description to an output-only screen field before redisplay. Same SEARCH syntax as batch; presence test still required. Pseudo-conversational CICS deployments may SEARCH on each resumed task—keep tables INSTREAM or small external to avoid reloading large reference files every transaction unless INITIATION loads them once per screen open.
One input code may drive a chain: SEARCH region table for region name, then SEARCH state table within region for tax description. Each step needs its own IF test. Avoid assuming first lookup success implies second will succeed—use independent error handling per table. When chains grow beyond three tables, evaluate whether a single denormalized maintenance file or SQL join simplifies maintenance.
TABLE LOOKUP keeps reference data inside Easytrieve memory with binary search speed and no Db2 plan bind. SQL FILE reaches shared tables with SQL verbs—better when HR maintains departments in Db2 and twelve applications need the same names. Hybrid programs are common: INSTREAM status decode for ten batch codes plus occasional SQL FILE read for employee master details. Document which codes live where so new developers do not duplicate tables in Db2 and Easytrieve divergently.
LOOKUP is asking a helper book what a secret code means. You whisper the code number; the helper finds the page and tells you the real words. If the code is not in the book, you say unknown instead of guessing. SEARCH is how you ask; the TABLE is the helper book you filled in during Library time.
1. In Easytrieve 11.6, the executable lookup statement is:
2. A TABLE file returns descriptions through which field role?
3. Best pattern when lookup fails:
4. INSTREAM lookup tables are ideal when:
5. External TABLE max-entries prevents: