Exercise 1: Why a Random READ Uses INVALID KEY, Not AT END — Possible Solution
====================================================================

WHAT AT END GENUINELY MEANS IN A SEQUENTIAL CONTEXT
Fundamentals' own Chapter 8 established that AT END fires when a real
sequential READ passes the last actual record in the file - it's a
genuine statement about position within an ordered sequence of
records being read one after another, front to back. The whole real
concept only makes sense when there's a meaningful "next" record to
have run out of.

WHY A RANDOM READ HAS NO REAL "NEXT RECORD" TO RUN OUT OF
This chapter's own real material explains that ACCESS MODE RANDOM
locates a single, specific record directly by its own real key, with
no need to read anything that comes before it. A random READ isn't
walking through a sequence at all - it's asking one direct, isolated
question: "does a record with this real key exist?" There's no
concept of having "passed the last record," because the operation was
never moving through the file in the first place.

WHAT INVALID KEY GENUINELY REPORTS INSTEAD
This chapter's own CUSTOMER-FILE example shows INVALID KEY firing
specifically when the requested key - CUST-ID, in that example -
doesn't correspond to any real record actually stored in the file.
That's a fundamentally different real question from "did I read past
the end": it's "does this specific key genuinely exist," answerable
in a single lookup regardless of where in the file that record would
have physically sat.

WHY THIS DISTINCTION IS GENUINELY NECESSARY, NOT JUST A NAMING CHOICE
If COBOL tried to reuse AT END for a random READ, it would be
borrowing language from a real concept (position within a traversed
sequence) that simply doesn't apply here. INVALID KEY is the correct,
distinct real condition because a failed random lookup is a
categorically different kind of failure than reaching the physical
end of a file - one is about a missing key, the other is about
position genuinely running out.

ANSWER: A random READ against CUSTOMER-FILE uses INVALID KEY rather
than AT END because ACCESS MODE RANDOM locates a single record
directly by its real key, with no traversal through a sequence of
records at all - there's no "next record" to run out of, since the
operation never moves through the file in the first place. AT END
genuinely only makes sense for a sequential read that's stepping
through records in order and can meaningfully pass the last one.
INVALID KEY instead reports a fundamentally different, direct real
condition: whether a record with the requested key exists at all,
answerable in one isolated lookup regardless of that record's own
position in the file.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the structural reason the two conditions
serve genuinely different purposes (traversal-based end-of-sequence
vs. a direct existence check), rather than treating INVALID KEY as
simply a renamed version of AT END.