Exercise 3: Why WS-FILE-STATUS = "00" Doesn't Last Forever in a Priming-Read Loop — Possible Solution
====================================================================

WHAT "00" GENUINELY MEANS AT ANY GIVEN MOMENT
This chapter's own real status-code table states that "00" means the
most recent file operation was genuinely successful - in the context
of a real READ statement, that a real record was actually retrieved.
It's a report on the outcome of the single most recent operation, not
a permanent, ongoing description of the file's own state.

WHY A PRIMING-READ LOOP KEEPS ISSUING NEW READ STATEMENTS
This chapter's own priming-read pattern issues a real READ before the
loop starts, and then another real READ at the end of every single
pass through the loop body. Each of those is a genuinely separate,
distinct operation, and WS-FILE-STATUS is overwritten fresh after each
one - it reflects only the very latest READ, not some cumulative
record of every read that came before it.

WHY "00" GENUINELY CAN'T HOLD FOREVER IN A LOOP THAT KEEPS READING
A real sequential file, per this chapter's own material, holds a
genuinely finite number of contiguous records. Since the priming-read
loop keeps issuing new READ statements for as long as WS-EOF-FLAG
isn't "Y," it will eventually attempt to read past the real, actual
last record in the file - at which point that specific READ can no
longer succeed the way every prior one did.

WHAT REAL VALUE EVENTUALLY REPLACES "00"
This chapter's own status-code table states directly that "10" is the
real code for end of file being reached - "the real code behind every
AT END trigger." Once a READ genuinely goes past the last record,
WS-FILE-STATUS is set to "10" instead of "00," and that same READ's
own AT END phrase fires, moving "Y" into WS-EOF-FLAG so the loop's own
condition finally becomes true on its next check.

ANSWER: WS-FILE-STATUS being "00" only reports the outcome of the
single most recent file operation, not a lasting or permanent state -
and because a priming-read loop keeps issuing brand-new READ
statements for as long as the loop runs, each one overwrites
WS-FILE-STATUS fresh. Since a real sequential file holds a genuinely
finite number of records, the loop will eventually attempt to read
past the actual last one, and that specific READ can no longer
succeed. At that point WS-FILE-STATUS is set to "10" - this chapter's
own real code for end of file - and that same READ's AT END phrase
fires, which is exactly what eventually sets WS-EOF-FLAG to "Y" and
lets the loop's own condition become true.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains that a status code reflects only the most
recent operation rather than a lasting state, ties the eventual change
directly to the file's own genuinely finite length, and names the
specific real status value ("10") that replaces "00," connecting it
back to the AT END mechanism covered earlier in the same chapter.