Exercise 3: Rewriting EVALUATE as IF/ELSE IF, and EVALUATE's Real Advantage — Possible Solution
====================================================================

THE REWRITTEN IF/ELSE IF VERSION
This chapter's own EVALUATE example tests WS-ACCOUNT-STATUS against
"A" and "C", with a catch-all for anything else. The equivalent using
only IF/ELSE IF:

IF WS-ACCOUNT-STATUS = "A"
    DISPLAY "ACTIVE"
ELSE
    IF WS-ACCOUNT-STATUS = "C"
        DISPLAY "CLOSED"
    ELSE
        DISPLAY "UNKNOWN STATUS"
    END-IF
END-IF.

This produces exactly the same real behavior as the original EVALUATE
statement for these two specific status codes.

WHY THIS VERSION ALREADY LOOKS MORE CUMBERSOME
Even with just two real cases, the IF/ELSE IF version requires nesting
one IF statement inside the ELSE branch of another, with a
correspondingly nested END-IF to close each one. The EVALUATE version,
by contrast, lists each case as a flat, parallel WHEN clause with no
nesting at all - a structural difference that's already noticeable
even at this small scale.

THE REAL ADVANTAGE ONCE MORE STATUS CODES ARE ADDED
This chapter's own material shows EVALUATE handling any number of WHEN
clauses as a flat, parallel list, with WHEN OTHER as a single, clearly-
labeled catch-all. Extending the EVALUATE version to a third or fourth
status code means simply adding one more WHEN clause at the same level
as the others - no restructuring required.

Extending the IF/ELSE IF version the same way means nesting yet another
IF inside the previous ELSE branch, adding one more level of
indentation and one more END-IF to track for every additional status
code. By a fourth or fifth case, the IF/ELSE IF version would be
several levels deep, genuinely harder to read at a glance, and easier
to make a real structural mistake in (a misplaced or missing END-IF
becoming much more likely as the nesting grows).

WHY THIS GENUINE STRUCTURAL DIFFERENCE MATTERS
EVALUATE's flat structure scales cleanly regardless of how many real
cases are added, while the IF/ELSE IF chain's nesting depth grows with
every additional case - a real, practical readability and maintenance
cost that becomes more serious the more status codes a real program
actually needs to handle.

ANSWER: The IF/ELSE IF equivalent nests one IF inside the previous
ELSE branch for each additional case, requiring a matching END-IF at
every level. EVALUATE's own real advantage becomes clear once a third
or fourth status code needs handling: extending EVALUATE just means
adding one more flat, parallel WHEN clause, while extending the
IF/ELSE IF chain means adding another level of nesting and another
END-IF - genuinely harder to read and more error-prone as the number
of real cases grows, since EVALUATE's structure stays flat no matter
how many WHEN clauses it holds.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly produces the equivalent nested IF/ELSE IF structure
using real COBOL syntax, and identifies the specific structural
advantage (flat vs. increasingly nested) that becomes more pronounced
as more cases are added, rather than only comparing the two-case
example shown in the chapter.