Exercise 3: Why EXEC CICS and EXEC SQL Can Sit Side by Side in the Same Program — Possible Solution ==================================================================== WHAT CHAPTER 4 ALREADY ESTABLISHED ABOUT EXEC SQL Chapter 4's own real finding-box explains that a genuine precompiler runs before the real COBOL compiler ever sees the source, parsing every EXEC SQL block and replacing it with ordinary host-language statements - ultimately real CALL statements - that invoke a database code library. By the time the actual COBOL compiler processes the program, no EXEC SQL syntax remains in it at all; only standard COBOL does. WHAT THIS CHAPTER ESTABLISHES ABOUT EXEC CICS BEING THE SAME REAL STYLE This chapter's own material states directly that real CICS commands sit inside COBOL source "exactly like Chapter 4's own embedded SQL" - EXEC CICS/END-EXEC, processed by a genuine translator before the real COBOL compiler ever sees the source. The mechanism is structurally the same real two-stage process: a specialized preprocessor handles the EXEC CICS syntax and replaces it with ordinary COBOL before real compilation happens, just as the SQL precompiler does for EXEC SQL. WHY BOTH GENUINELY CAN COEXIST IN ONE PROGRAM Because each kind of EXEC block is handled by its own separate real preprocessing stage - one for SQL, one for CICS - and each is fully resolved into ordinary COBOL before the actual COBOL compiler ever runs, the final compiled program never contains any EXEC SQL or EXEC CICS syntax at all. From the real COBOL compiler's own perspective, by the time it receives the source, everything is already standard COBOL, regardless of how many different kinds of EXEC blocks originally appeared in the program or in what order. WHY THIS ISN'T A COINCIDENCE OR A SPECIAL CASE This chapter's own worked example - a RECEIVE MAP, followed by an embedded SQL lookup, followed by a SEND MAP - relies on precisely this real layering: the CICS preprocessor resolves the CICS-specific parts, the SQL precompiler resolves the SQL-specific parts, and only after both have finished their own real transformation does the actual COBOL compiler ever see the resulting, fully standard COBOL source. Neither preprocessor needs to know anything about the other's own work for this to succeed. ANSWER: EXEC CICS and EXEC SQL can sit side by side because each is handled by its own separate real precompiler stage that runs before the actual COBOL compiler ever sees the source - exactly the same real two-stage mechanism Chapter 4 already established for embedded SQL, applied here a second time for CICS commands. Both kinds of EXEC block are fully resolved into ordinary, standard COBOL before real compilation happens, so the compiler itself never encounters SQL or CICS syntax directly, regardless of how many different EXEC blocks a program originally contained or in what order they appeared. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly connects EXEC CICS's own real precompiler mechanism back to Chapter 4's already-established EXEC SQL mechanism, explaining why the shared two-stage pattern (specialized preprocessing, then ordinary COBOL compilation) is exactly what allows both to coexist in one program.