Exercise 3: Why Wrapping Existing COBOL Is Genuinely Often Preferred Over a Full Rewrite — Possible Solution
====================================================================

WHAT THE REAL SCALE ESTABLISHED IN FUNDAMENTALS CHAPTER 1 ACTUALLY IS
Fundamentals' own Chapter 1 established real, striking figures: an
estimated 200 billion lines of COBOL still in existence, running 80%
of all business programs, with COBOL still processing 95% of the time
a card was swiped as recently as verified. This chapter's own opening
paragraph reuses those same real figures directly to frame just how
much genuinely existing, working code is out there.

WHY REWRITING CODE AT THAT REAL SCALE IS GENUINELY IMPRACTICAL
A rewrite effort has to reproduce every real business rule, edge case,
and quirk the original system has accumulated - often over decades -
correctly, before it can safely replace what's already running. At
the real scale Fundamentals Chapter 1 established, attempting that
for entire systems built from millions of real, individually-tested
lines is a genuinely enormous undertaking, with a real risk of
introducing new bugs into logic that has already been proven correct
by decades of real production use.

WHAT WRAPPING GENUINELY PRESERVES THAT A REWRITE WOULD RISK
This chapter's own material proposes wrapping existing, working COBOL
behind a modern interface - reusing Chapter 4's own embedded SQL or
Chapter 7's own CICS transaction as the real, already-covered
mechanisms that make this possible. This approach genuinely leaves
the proven internal logic completely untouched, modernizing only what
sits at the edges - how the system is reached or presented - without
touching the real, already-working code underneath that already
correctly implements decades of accumulated business rules.

WHY THIS IS A GENUINELY MORE PRACTICAL RISK TRADE-OFF
Wrapping isolates the real risk of introducing new bugs to just the
new interface layer being added, while the proven, already-correct
internal logic keeps running exactly as it always has. A full rewrite,
by contrast, puts every single piece of that decades-old, proven logic
back at genuine risk of being reimplemented incorrectly, all at once,
across a real system large enough that Fundamentals Chapter 1's own
figures make the scope of that risk vividly clear.

ANSWER: Wrapping existing COBOL behind a modern interface is often
genuinely preferred over a full rewrite because, at the real scale
Fundamentals Chapter 1 established - roughly 200 billion lines running
80% of business programs - fully reimplementing that much
already-proven, decades-tested business logic correctly would be a
genuinely enormous undertaking with real risk of introducing new bugs
into code that already works. Wrapping, using mechanisms like Chapter
4's embedded SQL or Chapter 7's CICS transactions, modernizes only
what's visible at the edges while leaving the real, proven internal
logic completely untouched - confining the real risk of new bugs to
the new interface layer rather than the entire, already-working
system underneath it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly connects the real scale figures from Fundamentals
Chapter 1 to the specific practical risk a full rewrite would carry,
and explains concretely what wrapping preserves that a rewrite would
put at risk, rather than treating "wrapping is preferred" as an
unexplained rule of thumb.