Not every control-flow decision is IF or CASE on a field value. Some decisions gate entire records through processing pipelines: should this row enter the sort extract, continue into report totaling, or stop here. Easytrieve SELECT—in sort and report contexts—is that gate. A single keyword SELECT in a SORT BEFORE procedure marks the current input record for inclusion in sorted output; omit SELECT and the record drops from the sort file even if IF logic ran. REPORT-INPUT SELECT performs analogous gating for report processing after PRINT selection. This is different from SQL SELECT, which is a full relational clause after JOB INPUT SQL. Control-flow thinking maps pipeline stages: read, screen with IF, SELECT to include, downstream SORT or REPORT consumes only flagged records. STOP after SELECT cancels inclusion. Duplicate SELECT on one record still produces one row. Beginners confuse SQL and sort SELECT and wonder why extracts are empty—BEFORE proc ran IF but never SELECT. This page teaches pipeline diagrams, inclusion versus exclusion patterns, combining IF with SELECT, REPORT-INPUT flow, and contrast with field-level branching on CASE and IF pages.
Batch programs chain stages: input, optional prescreen, transform, sort, report. SELECT operates at stage boundaries as yes-no continue switch for current record. IF evaluates business rules; SELECT commits record to next stage when rules pass. Think of SELECT as opening a turnstile—IF checks ticket, SELECT rotates gate. Without SELECT turnstile stays closed regardless of IF calculations elsewhere.
| Context | Control flow role | Typical location |
|---|---|---|
| SORT BEFORE proc | Include record in sort output file | SORT activity BEFORE procedure |
| REPORT-INPUT proc | Pass record into report processing | After PRINT selection path |
| SQL JOB INPUT SQL | Relational row source—not one-word flag | First JOB statement after JOB INPUT SQL |
| File SQL definition | Database row fetch model | SQL FILE in Library |
SORT INPUT WITH BEFORE-SCREEN-PROC pattern: every input record enters BEFORE procedure; valid records hit SELECT; invalid records EXIT or fall through without SELECT. Downstream SORT sees subset. Control flow splits early—downstream JOB INPUT on sort work file processes only selected population. Empty output file often means zero SELECT executions—trace BEFORE with counts before blaming sort keys.
12345678SORT INPUT USING (DEPT, EMP-NO) BEFORE SCREEN-PROC SCREEN-PROC. PROC IF DEPT EQ 'SALES' AND STATUS EQ 'A' SELECT END-IF END-PROC
Common structure: IF complex condition, SELECT, END-IF. IF alone never includes record in sort output. Nested IF may SELECT on one branch only—control flow tree ends in SELECT leaf for inclusion paths. ELSE branch intentionally omits SELECT to exclude. Multiple IF paths may SELECT same record—still one output row per input pass.
SELECT sets inclusion; STOP in same procedure pass may cancel processing before sort commits row. Broadcom documents SELECT followed by STOP as not selected—order matters inside procedure. Error handlers: IF FATAL, STOP without SELECT drops bad record from extract while ending procedure pass cleanly. Test STOP paths in BEFORE proc so production rejects do not accidentally SELECT then STOP inconsistently across releases.
PRINT selects detail lines for printing; REPORT-INPUT SELECT further gates which selected data continues into report writer internal processing—totals, breaks, spooling paths. Omit REPORT-INPUT and defaults apply per product rules. When REPORT-INPUT exists, unselected records bypass continued report processing even if PRINT fired—control-flow mismatch shows as missing totals for printed lines. Align PRINT, REPORT-INPUT, and business IF logic in one specification table.
CASE routes execution within record processing—assign rates, messages, PERFORM paths. SELECT routes record to next pipeline stage. Same record may CASE on type for calculations then SELECT for sort inclusion if type in allowed set. Layer decisions: field logic first, pipeline gate last in BEFORE proc.
JOB INPUT SQL with full SELECT clause defines cursor-like input stream from database—control enters JOB with rows from query, not sequential file READ. One SELECT per JOB activity rule applies. Flow diagram source is DBMS not disk file. Do not mix sort one-word SELECT grammar into SQL clause or vice versa—compile errors or wrong semantics.
SELECT is putting a green sticker on a paper that says this one may go to the next room. IF checks if the paper is good; SELECT is the sticker that lets it through the door. No sticker means the paper stays out even if you wrote notes on it. Sort and report rooms only accept papers with stickers.
1. Sort SELECT in a BEFORE procedure:
2. If BEFORE procedure never SELECTs:
3. SELECT then STOP in same procedure:
4. REPORT-INPUT SELECT controls:
5. SQL SELECT differs from sort SELECT because: