Easytrieve Sequential Search Versus TABLE Lookup

Two Different Meanings of Sequential

Mainframe beginners confuse two ideas. Sequential file processing reads a transaction file from beginning to end once—every employee record in payroll, every order in sales. That is correct Easytrieve design for JOB INPUT. Sequential search for lookup re-scans a reference file from the beginning for each transaction row hunting one code. That is almost always wrong when TABLE plus SEARCH exists. This page focuses on the second meaning and contrasts it with sanctioned TABLE lookup.

What Easytrieve SEARCH Actually Does

SEARCH never walks row 1, row 2, row 3 until match. After TABLE load, keys reside in memory in ascending ARG order and binary search partitions the key space. Sequential scan would examine up to n rows per lookup; binary search examines at most log₂(n). No Language Reference option switches TABLE SEARCH to linear mode for small tables or unsorted data—unsorted data is a data defect, not a cue to fall back to sequential search inside SEARCH.

The Improvised Sequential Lookup Anti-Pattern

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
JOB INPUT PAYROLL
  PERFORM DEPT-LOOKUP
  PRINT PAYRPT
 
DEPT-LOOKUP. PROC
  MOVE 1 TO FOUND-FLAG
  GET REFDEPT
  DO WHILE NOT EOF REFDEPT AND FOUND-FLAG = 0
     IF REF-DEPT = EMP-DEPT
        MOVE REF-NAME TO DEPT-NAME
        MOVE 1 TO FOUND-FLAG
     ELSE
        GET REFDEPT
     END-IF
  END-DO
  IF FOUND-FLAG = 0
     DEPT-NAME = 'NOT FOUND'
  END-IF
END-PROC

This PROC reads REFDEPT from the start for every payroll row. After processing employee 50,000, the job has executed millions of GET and compare operations. REFDEPT file position resets each PERFORM, so no benefit accumulates across employees. CPU and elapsed time grow with product of input count and reference count. TABLE load once plus SEARCH per employee reduces reference access to in-memory binary comparisons.

Performance Mathematics

Real runs average fewer than worst-case sequential comparisons if keys appear early in reference file, but worst-case planning drives batch capacity. Operations schedules assume peak files.

When Sequential File Reading Is Correct

• JOB INPUT on primary transaction FILE—process every record once.
• Building an external TABLE maintenance file from source systems—one pass transform.
• SORT activity reading unsorted input to produce sorted output.
• Audit programs listing entire reference file for human review—not per-row lookup.

None of these are lookup by key on every input row. They are linear workflows where each reference row is consumed at most once per pass by design.

One-Time Sequential Load Versus Per-Row Scan

External FILE TABLE reads maintenance data sequentially at JOB initiation—that single sequential pass is required and efficient. Data lands in memory; subsequent SEARCH calls use binary search. Confusing initiation load with per-record sequential scan is a common beginner mistake when reading Table Processing chapter diagrams.

Migrating From GET Loop to TABLE

1. Extract reference file layout; define ARG and DESC matching key and description columns.
2. Sort maintenance file ascending by ARG; remove duplicates.
3. Replace FILE REFDEPT with FILE REFDEPT TABLE max-entries in Library.
4. Remove PERFORM lookup PROC; add SEARCH REFDEPT WITH key GIVING result.
5. Replace FOUND-FLAG logic with IF REFDEPT / IF NOT REFDEPT.
6. Parallel test: compare descriptions for sample input file before cutover.

1
2
3
4
5
6
7
8
9
10
FILE REFDEPT TABLE 500
  ARG   1  3 N
  DESC  5 25 A
 
JOB INPUT PAYROLL
  SEARCH REFDEPT WITH EMP-DEPT GIVING DEPT-NAME
  IF NOT REFDEPT
     DEPT-NAME = 'NOT FOUND'
  END-IF
  PRINT PAYRPT

When Sequential Patterns Persist Legitimately

Some legacy programs search variable-length text files or non-tabular reference extracts TABLE cannot model. ACCESS or SQL may fit better than forcing TABLE. If reference data is genuinely unsortable or keys are not fixed layout, sequential scan might remain—but that is a data modeling problem, not a reason to avoid sorting decodable code tables. Document exceptions rather than treating GET loops as default style.

Sequential Search on Unsorted Data

Teams sometimes ask whether unsorted reference files force sequential search. Easytrieve answer: sort the file and use TABLE. Binary search requires order; sequential GET loops tolerate disorder but punish CPU. A one-time SORT in maintenance JCL is cheaper than millions of extra comparisons nightly. If sort is impossible because keys are not comparable, redesign reference extract—not the search algorithm inside Easytrieve.

Teaching Reviewers What to Flag

• GET on reference file inside JOB loop or per-record PERFORM.
• WHILE NOT EOF scanning until match flag set.
• REWIND or repeated OPEN on reference file each record.
• Reference file DD opened without TABLE parameter but used only for decode.

Explain It Like I'm Five

Sequential search is reading every page of a book from the beginning until you find your word. Binary TABLE search is opening the book in the middle because words are in order. Easytrieve wants the ordered book trick. Reading every page for every question is slow homework nobody should do five million times per night.

Exercises

1. Estimate worst-case compares for GET loop versus SEARCH on given input and table sizes.
2. Rewrite sample DEPT-LOOKUP PROC as FILE TABLE plus SEARCH.
3. List three legitimate sequential file uses unrelated to per-row decode.
4. Explain one-time TABLE load versus per-row reference GET to a new teammate.
5. Audit a legacy program for reference GET inside JOB input loop.