Exercise 2: Reversing Parameter Order in the CALL Without Changing BALCHECK — Possible Solution ==================================================================== WHAT MATCHING IS ACTUALLY BASED ON, PER THIS CHAPTER This chapter's own finding-box states the real rule directly: caller and subprogram parameters are matched by real position and count, not by name. The first item in CALL ... USING binds to the first item in PROCEDURE DIVISION USING, the second binds to the second, and so on - regardless of what either side calls its own field. WHAT THE COLLEAGUE'S REVERSED CALL ACTUALLY DOES CALL "BALCHECK" USING WS-VALID-FLAG WS-BALANCE now lists WS-VALID-FLAG first and WS-BALANCE second - the opposite order from this chapter's own original example. Since BALCHECK's own LINKAGE SECTION and PROCEDURE DIVISION USING were left completely unchanged, its first declared parameter is still LS-BALANCE and its second is still LS-VALID-FLAG. WHY THIS IS A GENUINE MISMATCH, NOT JUST CONFUSING NAMES Because matching is purely positional, LS-BALANCE (declared as a 9-digit signed numeric field, PIC S9(7)V99) is now bound to whatever real storage WS-VALID-FLAG actually occupies - a single-character field, PIC X(1). Under this chapter's own real BY REFERENCE default, BALCHECK genuinely treats that shared storage as if it held a full signed numeric field, even though the caller only ever declared one real byte there. Symmetrically, LS-VALID-FLAG is now bound to WS-BALANCE's own real storage, so BALCHECK treats a full 9-digit numeric field's storage as if it were a single character. WHAT THIS GENUINELY RISKS IN PRACTICE Any real read or write BALCHECK performs against LS-BALANCE is now operating against storage that was never actually declared to be that large or that shape in the calling program - a real, dangerous mismatch between what the subprogram believes it's working with and what real storage is actually there. Writing into LS-VALID-FLAG, in turn, would genuinely only touch the very first byte of what the calling program understands to be its full WS-BALANCE field, silently corrupting part of a real stored balance rather than updating a one-character flag as intended. ANSWER: Because caller and subprogram parameters are matched purely by real position, reversing the order in the CALL statement without also reversing BALCHECK's own LINKAGE SECTION and PROCEDURE DIVISION USING causes a genuine size and type mismatch: LS-BALANCE (a 9-digit signed numeric field) ends up bound to WS-VALID-FLAG's real one-byte storage, and LS-VALID-FLAG (a one-character field) ends up bound to WS-BALANCE's real 9-digit numeric storage. Under BY REFERENCE, this means BALCHECK would be reading and writing against storage that doesn't genuinely match what it believes it's working with - risking reading garbage values, writing past the real boundary of the smaller field, or silently corrupting part of the caller's actual balance data. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly applies the chapter's own positional-matching rule to identify the specific real mismatch (size/type, not just semantics), and explains the genuine practical risk (corrupted or garbage data) that follows from BY REFERENCE sharing storage between fields of different real declared sizes.