Exercise 3: The Genuine Structural Difference Between COPY and CALL — Possible Solution ==================================================================== WHAT COPY GENUINELY DOES TO THE COMPILED PROGRAM This chapter's own finding-box states this directly: COPY performs a real compile-time textual substitution. The copybook's own text is logically merged directly into the including program's own source before that program is compiled - once compiled, the resulting program contains the copybook's own content baked directly into its own single compiled unit, with no distinction remaining between "the program's own code" and "the copied-in code." WHY A COPYBOOK CHANGE GENUINELY REQUIRES RECOMPILING EVERY INCLUDER Because the copybook's own text becomes a permanent, baked-in part of each including program's own compiled output at the moment of compilation, an already-compiled program has no ongoing real connection back to the copybook file at all - it simply contains whatever that file held at the time it was last compiled. Updating the copybook afterward changes nothing about programs already compiled; each one has to be recompiled specifically so the compiler substitutes in the copybook's own new content and produces a fresh, updated compiled version. WHAT CALL GENUINELY DOES INSTEAD, PER FUNDAMENTALS Fundamentals' own Chapter 9 material, referenced directly in this chapter, establishes that CALL invokes a real, separately compiled program at runtime - the calling program and the called subprogram remain two genuinely distinct compiled units, linked together only when the program actually runs, not merged into one another at compile time the way a copybook is. WHY A SUBPROGRAM CHANGE GENUINELY DOESN'T REQUIRE RECOMPILING THE CALLER Since the calling program never had the subprogram's own internal code substituted into its own compiled output in the first place, the calling program's own compiled form has nothing of the subprogram's internals baked into it at all - only the real CALL statement itself, naming the subprogram and its parameter list. As long as the subprogram's own real PROCEDURE DIVISION USING signature (the number, order, and type of its parameters) stays the same, recompiling only the subprogram itself and swapping in its newly compiled version is genuinely sufficient - the calling program's own already-compiled form doesn't need to change at all. ANSWER: COPY merges a copybook's own real text directly into an including program's own compiled output at compile time, so an already-compiled program has no ongoing connection to the copybook file afterward - any copybook change requires every including program to be recompiled so the new content is substituted in fresh. CALL, by contrast, links to a genuinely separate, independently compiled subprogram only at runtime, per Fundamentals' own Chapter 9 - the calling program's own compiled form never contains the subprogram's internal code at all, only a reference to it via the CALL statement itself. This is why updating a called subprogram's own internal logic, as long as its real parameter signature doesn't change, only requires recompiling that subprogram - the calling program's own already- compiled form remains valid and doesn't need rebuilding. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly identifies the structural root cause (text merged in at compile time vs. a genuine runtime link between separate compiled units) behind the different recompilation requirements, rather than simply restating that the two behave differently.