Easytrieve CASE Control Flow

Decision Tables and CASE Structure

Business analysts often document rules as tables: when STATUS is 1 do X, when 2 do Y. CASE transcodes table rows into WHEN clauses. Each row becomes WHEN literal or range plus statements. OTHERWISE catches table default row. Reviewers compare CASE source to specification row by row—easier than hunting ELSE-IF scattered with duplicated field tests. Overlapping ranges cause first-match priority—document order when ranges touch at boundaries.

1
2
3
4
5
6
7
8
9
10
CASE DEPT-CODE
  WHEN 'PAY'
     PERFORM PAYROLL-ROUTING
  WHEN 'HR'
     PERFORM HR-ROUTING
  WHEN 'IT'
     PERFORM IT-ROUTING
  OTHERWISE
     PERFORM DEFAULT-ROUTING
END-CASE

WHEN Ranges and Control Flow

WHEN 0 THRU 4 assigns one path for inclusive range 0,1,2,3,4. Adjacent tiers use WHEN 5 THRU 9 without gap if 4 and 5 both covered—gap values fall through to OTHERWISE or skip block entirely. Boundary testing: values exactly on THRU endpoints must match spec. Numeric zoned fields compare as numeric; alphanumeric codes compare as character—type mismatch causes wrong branch silently.

CASE Versus IF-ELSE Control Flow

Two outcomes: IF suffices. Three to five related outcomes on same field: CASE often clearer. Ten plus outcomes: CASE strongly preferred. IF chains mixing different fields belong as nested IF or separate CASE blocks per driver field—not one CASE on field A with tests on field B inside WHEN bodies without restructuring. PERFORM per branch keeps CASE bodies thin; heavy logic in WHEN obscures dispatch table.

Fall-Through After END-CASE

Execution after END-CASE continues sequentially regardless of which WHEN ran—CASE does not exit activity unless STOP, GOTO, or EXIT inside branch. Set output fields in each WHEN so downstream logic has consistent state. OTHERWISE should set error flag or default values when spec requires—avoid empty OTHERWISE that leaves prior iteration values in working storage.

Nested CASE Control Flow

Outer CASE on REGION, inner CASE on PRODUCT within each regional WHEN—tree of decisions. Nesting depth hurts readability beyond two levels; consider two-dimensional lookup table with PERFORM instead. Inner CASE must END-CASE before outer END-CASE. IF wraps CASE when precondition gates entire dispatch—IF RECORD-VALID EQ Y then CASE TYPE ...

CASE With PERFORM and Loops

DO WHILE loop body may CASE on line-type field per iteration—control flows per record type within batch stream. Avoid CASE inside tight inner loop on unchanged field—compute once before loop. Report BEFORE-LINE CASE on break-level field changes detail formatting path without GOTO spaghetti.

Testing CASE Control Paths

1. One test job per WHEN value including boundaries of THRU ranges.
2. OTHERWISE path with value outside all ranges.
3. Gap values if OTHERWISE omitted—confirm intentional fall-through.
4. Character versus numeric type alignment on CASE field.
5. First-match order when ranges could overlap.

Common CASE Control Mistakes

• Missing END-CASE merging control into next statement block.
• Duplicate ranges—first WHEN hides second silently.
• OTHERWISE omitted when spec requires default handling.
• Testing wrong field—CASE on status but IF still checks old code elsewhere.
• Heavy duplicate code in each WHEN instead of PERFORM.

Explain It Like I'm Five

CASE is a mail sorter for one letter slot. You look at the zip code on the letter and put it in the right bin—WHEN zip is 100 THRU 199 goes here, WHEN 200 THRU 299 goes there. OTHERWISE is the junk drawer for letters that do not match any bin. You handle one letter at a time and only one bin wins.

Exercises

1. Convert four-branch ELSE-IF on STATUS to CASE with OTHERWISE.
2. Build decision table for years-of-service tiers as WHEN THRU ranges.
3. Identify boundary values to test for WHEN 10 THRU 19.
4. Refactor WHEN bodies to PERFORM one proc per branch.
5. Design nested CASE versus flat CASE for region and product.