Exercise 1: Why WS-VALID-FLAG Ends Up Holding the Subprogram's Result — Possible Solution ==================================================================== WHAT BY REFERENCE ACTUALLY MEANS, PER THIS CHAPTER This chapter's own real parameter-passing table states BY REFERENCE directly: the called program's item occupies the exact same real storage as the caller's own item. Since no keyword is written at all in CALL "BALCHECK" USING WS-BALANCE WS-VALID-FLAG, BY REFERENCE is the real default that applies automatically to both parameters. WHAT "SAME STORAGE" GENUINELY MEANS FOR LS-VALID-FLAG Because LS-VALID-FLAG (inside BALCHECK) and WS-VALID-FLAG (in the calling program) share that same real storage location under BY REFERENCE, they aren't two separate copies of a value that happen to look related - they are, for the real duration of the CALL, two different names genuinely pointing at the identical piece of memory. WHY THE SUBPROGRAM ONLY EVER TOUCHES LS-VALID-FLAG BY NAME BALCHECK's own PROCEDURE DIVISION code, per this chapter's example, writes MOVE "N" TO LS-VALID-FLAG or MOVE "Y" TO LS-VALID-FLAG - it never mentions WS-VALID-FLAG at all, since BALCHECK genuinely has no knowledge of what the calling program happens to call its own fields. This chapter's own finding-box states this directly: names don't have to match between caller and subprogram, only real position and count. WHY THE CHANGE IS STILL VISIBLE BACK IN THE CALLING PROGRAM Since MOVE "Y" TO LS-VALID-FLAG is genuinely writing into the exact same real storage that WS-VALID-FLAG also refers to (via BY REFERENCE), that write is visible from either name. Once control returns to the calling program after GOBACK, checking WS-VALID-FLAG reads from that same real storage location BALCHECK just wrote into - so the result appears correctly, even though the calling program's own code never directly assigned anything to it itself. ANSWER: WS-VALID-FLAG ends up holding "Y" or "N" because BY REFERENCE is the real default parameter-passing mode whenever no keyword is specified, and BY REFERENCE means the calling program's item and the subprogram's item genuinely occupy the exact same real storage for the duration of the call. BALCHECK's own code only ever refers to that storage by its own local name, LS-VALID-FLAG, since positional matching (not name matching) is what connects the two programs - but because LS-VALID-FLAG and WS-VALID-FLAG are, under BY REFERENCE, two different names for the identical real storage location, a MOVE into one is genuinely visible through the other once control returns to the calling program. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly traces the real mechanism (shared storage under BY REFERENCE, positional rather than name-based matching) rather than treating the result as automatic or unexplained, and connects the explanation directly back to this chapter's own stated definitions.