Exercise 2: An Unknown Customer vs. an Unrecognized Transaction Code — Possible Solution
====================================================================

WHAT HAPPENS TO A TRANSACTION WITH NO MATCHING CUSTOMER
This chapter's own real TXNBATCH program wraps its customer lookup in
SEARCH ALL WS-CUSTOMER-ENTRY, with a real AT END clause: DISPLAY
"UNKNOWN CUSTOMER: " TXN-CUSTOMER-ID. If TXN-CUSTOMER-ID genuinely
doesn't match any WS-CUST-ID in the table, the whole real WHEN branch
- covering the BALCHECK call, the EVALUATE on TXN-CODE, the arithmetic,
and the STRING/DISPLAY reporting - is never reached at all. The
program simply displays the "UNKNOWN CUSTOMER" message and moves on
to read the next transaction record. No balance is touched, no counts
are incremented, and WS-GRAND-TOTAL is left completely unchanged for
that record.

WHAT HAPPENS TO A TRANSACTION WITH AN UNRECOGNIZED CODE
This is a genuinely different situation - the customer lookup does
succeed here, since TXN-CUSTOMER-ID does match a real entry in the
table. Once inside the matched WHEN branch, BALCHECK is still called
and WS-VALID-FLAG is still set based on whether TXN-AMOUNT is
negative. If WS-VALID-FLAG comes back "Y," the program reaches this
chapter's own real EVALUATE TXN-CODE statement. If TXN-CODE is
genuinely neither "D" nor "W," the real WHEN OTHER branch fires:
DISPLAY "UNKNOWN TRANSACTION CODE: " TXN-CODE. Critically, none of the
three named WHEN branches ("D," "W," or OTHER) fall through to each
other - only the one matching branch executes, so the real ADD/SUBTRACT
arithmetic that would normally apply the transaction never runs for an
unrecognized code either.

THE GENUINE COMMON GROUND BETWEEN BOTH CASES
In both situations, the real effect is the same at a high level: the
specific transaction record is effectively skipped rather than
applied, and the program continues on to the next real READ. But this
chapter's own material shows the two cases are structurally different
- an unknown customer never reaches BALCHECK or EVALUATE at all,
because SEARCH ALL's own AT END phrase intercepts it earlier, while
an unrecognized transaction code is caught later, only after a real,
successful customer match and a real, successful balance validation.

ANSWER: A transaction whose TXN-CUSTOMER-ID doesn't match any real
customer in WS-CUSTOMER-TABLE is caught immediately by SEARCH ALL's
own AT END clause - the program displays "UNKNOWN CUSTOMER" and moves
straight to the next record, never reaching BALCHECK, EVALUATE, or any
arithmetic at all. A transaction with a genuinely unrecognized
TXN-CODE, by contrast, does pass the customer lookup and the BALCHECK
validation successfully, but is caught later by EVALUATE's own real
WHEN OTHER branch, which displays "UNKNOWN TRANSACTION CODE" instead
of applying any real ADD or SUBTRACT to the customer's balance. Both
transactions end up effectively skipped, but at two structurally
different points in the program - one intercepted before the customer
is even confirmed to exist, the other intercepted only after the
customer and amount have both already been validated.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly traces both real failure paths through the program's
own actual control flow (SEARCH ALL's AT END vs. EVALUATE's WHEN
OTHER), identifies exactly where each one intercepts processing, and
distinguishes the two rather than treating them as identical outcomes.