Exercise 1: Why COBOL's Compiler Has No Built-In Understanding of SQL — Possible Solution
====================================================================

WHAT THIS CHAPTER'S OWN FINDING-BOX STATES DIRECTLY
This chapter's own finding-box makes the real mechanism explicit: a
genuine precompiler runs before the real COBOL compiler ever sees the
source at all. It's this separate precompiler, not the COBOL compiler
itself, that actually understands and processes EXEC SQL blocks.

WHAT THE PRECOMPILER GENUINELY DOES TO AN EXEC SQL BLOCK
The precompiler parses each real EXEC SQL...END-EXEC block and
replaces it with real, ordinary host-language statements that call
into a database code library. This chapter's own material states
directly that embedded SQL genuinely resolves down to Chapter 9's own
real CALL mechanism underneath - by the time the actual COBOL compiler
receives the source, the EXEC SQL block has already been transformed
into something that looks like completely ordinary COBOL code the
compiler already knows how to handle.

WHY THE COBOL COMPILER ITSELF GENUINELY NEVER SEES SQL AT ALL
Because the precompiler's own real output is what actually gets fed
into the COBOL compiler - not the original source containing EXEC SQL
- the COBOL compiler is never presented with SQL syntax it would need
special knowledge to process. From the compiler's own perspective,
every program it compiles is written entirely in standard COBOL,
including real CALL statements the precompiler generated to replace
what were originally EXEC SQL blocks.

WHY THIS TWO-STAGE PROCESS IS GENUINELY NECESSARY
If the COBOL compiler itself needed to understand SQL directly, every
COBOL compiler in existence would need SQL-processing logic built in,
and that logic would need updating any time SQL syntax changed. By
separating the two concerns - a real precompiler that understands SQL
and transforms it, and a real COBOL compiler that only ever sees
standard COBOL - the two systems can be developed, maintained, and
updated independently of one another.

ANSWER: The real COBOL compiler has no built-in understanding of SQL
because a genuinely separate precompiler runs first, parsing every
EXEC SQL block in the source and replacing it with ordinary host-
language statements - ultimately real CALL statements, per Chapter
9's own material - that invoke a database code library. By the time
the actual COBOL compiler processes the source, every EXEC SQL block
has already been transformed into standard COBOL syntax the compiler
already knows how to handle, so the compiler itself is never
confronted with real SQL syntax at any point in the process.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly traces the two-stage real process (precompiler
transformation, then ordinary COBOL compilation) explicitly stated in
this chapter's own finding-box, rather than treating embedded SQL as a
native COBOL language feature.