Exercise 2: Why a Shared OO Class Beats Duplication or Two Separate CALLs — Possible Solution ==================================================================== WHY DUPLICATING THE VALIDATION LOGIC IN BOTH PROGRAMS IS GENUINELY RISKY If the real balance-validation logic were simply retyped separately inside both TXNBATCH2 and the new CICS transaction, the two copies would have no real connection to each other at all. This chapter's own Chapter 2 material already established the real danger of exactly this pattern with copybooks: if the validation rule ever needed to change - say, a new minimum-balance threshold - both real copies would need to be found and updated separately, and missing one would leave the two programs silently enforcing genuinely different rules. WHY REUSING FUNDAMENTALS' OWN BALCHECK VIA TWO SEPARATE CALLS IS BETTER, BUT STILL LIMITED Calling the same real BALCHECK subprogram from both TXNBATCH2 and the CICS transaction, via two separate CALL "BALCHECK" USING ... statements, would genuinely solve the duplication problem - Chapter 9's own real material already established that a subprogram is one single compiled unit any number of callers can share. This is a real, valid option, and would work correctly here. WHAT THE SHARED OO CLASS METHOD GENUINELY ADDS ON TOP OF THAT This chapter's own Step 9 uses INVOKE VALIDATOR-OBJ "IS-VALID-BALANCE" from both real programs against the same underlying class, CUSTOMER-VALIDATOR, introduced in Chapter 8. Functionally, for this one specific validation check, a class method invoked via INVOKE and a subprogram invoked via CALL genuinely accomplish the same real sharing goal - one piece of logic, reused rather than duplicated. Chapter 8's own real value beyond that specific point is that a class can hold multiple related real methods and real inheritance relationships together as one coherent unit - useful specifically because this modernization is deliberately built around gradually introducing OO structure (per Chapter 8's own material) as more validation logic is added over time, not because INVOKE is structurally superior to CALL for this one single check in isolation. WHY THE HONEST ANSWER IS "BOTH SHARING APPROACHES SOLVE THE DUPLICATION PROBLEM" The real core problem - the same logic needing to exist and be maintained in only one place - is solved by either CALL to a shared subprogram or INVOKE against a shared class method. The genuine reason this capstone specifically chose the OO class version is to demonstrate Chapter 8's own real material in a concrete, worked context, and because a class provides a more natural real home for validation logic that may grow to include several related, coordinated checks over time as the modernization effort continues. ANSWER: Duplicating the validation logic separately in both programs is genuinely risky because any future rule change would require finding and updating both real copies, with a real chance of missing one and leaving the two programs enforcing different rules - exactly the danger Chapter 2 already established for copybooks. Reusing Fundamentals' own BALCHECK via two separate CALL statements would genuinely solve that duplication problem just as well, since a subprogram is one shared compiled unit any number of callers can invoke. The shared OO class in Step 9 accomplishes the same real sharing goal through INVOKE instead of CALL, with its added real value being that a class can naturally hold multiple related validation methods together as this modernization effort grows - not because INVOKE is inherently better than CALL for this one specific check. WHY THIS WORKS AS AN ANSWER ------------------------------ This gives an honest, balanced comparison rather than overstating OO's necessity for this one check, correctly identifying duplication as the real problem both CALL-based and INVOKE-based sharing solve, while naming the genuine, distinct value a class adds for a growing set of related validations.