Exercise 3: Why the CICS Wrapper Is a Direct Application of "Wrap Rather Than Rewrite," Not a Shortcut — Possible Solution ==================================================================== WHAT CHAPTER 9 GENUINELY RECOMMENDED, AND WHY Chapter 9's own material states the real recommendation directly: wrapping existing, working COBOL behind a modern interface is genuinely often preferred over a full rewrite, because reproducing decades of proven business logic correctly from scratch carries real, substantial risk, at the real scale Fundamentals Chapter 1 already established for COBOL systems generally. The genuine goal is modernizing what's visible at the edges while leaving proven internal logic untouched. WHAT STEP 8 ACTUALLY DOES, PIECE BY PIECE This capstone's own Step 8 introduces a new CICS transaction that reuses the exact same CUSTREC copybook (Step 2) and reads from the exact same real indexed CUSTOMER-FILE (Step 3) that TXNBATCH2's own batch processing already depends on. Nothing about TXNBATCH2's own internal batch logic - the sorting, the validation, the balance updates - is touched, rewritten, or duplicated by this new transaction at all. The CICS program's own real job is limited to reading the existing data and presenting it live to a teller. WHY THIS IS GENUINELY THE SAME PATTERN CHAPTER 9 DESCRIBED, NOT A DIFFERENT ONE Chapter 9's own material named exactly this shape of solution - reusing "Chapter 4's own embedded SQL or Chapter 7's own CICS transaction, for instance" as the real mechanisms that make wrapping possible. Step 8 does precisely that: it adds a new, small real interface (a CICS transaction) around already-proven, already-working components (the shared copybook and the indexed file) without altering or reimplementing any of the real business logic that already correctly processes transactions and maintains balances. WHY THIS ISN'T MERELY A CONVENIENT SHORTCUT A shortcut would imply skipping real, necessary work at the cost of quality or correctness. Here, the opposite is true: by leaving TXNBATCH2's own proven logic completely alone and building only a new, narrowly-scoped read-oriented interface around it, this capstone avoids the real risk Chapter 9 specifically warned a full rewrite would introduce - the chance of incorrectly reimplementing logic that already works. Choosing not to touch working code, when the alternative carries genuine risk, is the deliberate, well-reasoned choice Chapter 9 recommended, not an easier path taken to avoid effort. ANSWER: Step 8 is a direct, genuine application of Chapter 9's own "wrap rather than rewrite" recommendation because it builds a new CICS transaction entirely around already-proven components - the shared CUSTREC copybook and the real indexed CUSTOMER-FILE - without touching, duplicating, or reimplementing any of TXNBATCH2's own existing batch logic at all. This matches exactly the kind of solution Chapter 9 named directly, using a CICS transaction as the real mechanism for exposing existing, working data through a new interface. It isn't a shortcut because deliberately avoiding a rewrite of proven logic, specifically to avoid the real risk of reimplementing it incorrectly, is precisely the reasoned trade-off Chapter 9's own material recommended in the first place. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly traces Step 8's own real implementation details back to Chapter 9's own specific recommendation and its own named mechanisms, and explains why deliberately leaving working code untouched reflects sound judgment rather than an easier, lower-effort path.