Exercise 2: An Uninitialized WITH POINTER — Possible Solution
====================================================================

WHAT THE POINTER PHRASE IS SUPPOSED TO CONTROL
This chapter's own warn-box explains that a real POINTER field
controls exactly where in the receiving field STRING starts writing.
The genuine, intended use is to initialize that pointer to 1 before
STRING ever runs, so writing genuinely begins at the very first
position of the receiving field.

WHAT ACTUALLY HAPPENS WITHOUT THAT INITIALIZATION
COBOL working-storage fields don't automatically start out empty or
zero unless a real VALUE clause says so, or the field is explicitly
set beforehand. If WS-POS is declared with no VALUE clause and never
given a real starting value before the STRING statement runs, it
holds whatever value happens to already be sitting in that storage
location - which could be leftover data from an earlier part of the
same program, or simply an unpredictable value with no real
connection to "the beginning of the field" at all.

WHY STRING GENUINELY STARTS WRITING FROM THAT LEFTOVER VALUE
This chapter's own material states directly that STRING uses whatever
value the pointer field actually holds as the real position to begin
writing - it doesn't check whether that value looks sensible, and it
doesn't default to 1 on its own. So if WS-POS happens to hold, say,
15, STRING genuinely starts overwriting the receiving field starting
at position 15, silently destroying whatever real content was
previously sitting in positions 15 onward, rather than building the
field cleanly from its own start.

WHY THIS IS A REAL, SILENT BUG RATHER THAN SOMETHING COBOL CATCHES
COBOL has no way of knowing that the programmer actually intended
WS-POS to mean "the beginning of the field." A leftover, unexpected
value in WS-POS is, as far as the compiler and runtime are concerned,
a completely valid pointer value - just not the one the programmer
meant. Nothing about this situation triggers a compile-time warning
or a runtime error; the program runs to completion, and the STRING
statement genuinely executes without failing. The only visible sign of
the bug is that the receiving field's real content turns out wrong,
which could go unnoticed for a long time in a real report or output
that isn't checked character-by-character.

ANSWER: Without initializing WS-POS to 1 beforehand, it holds whatever
value happened to already be in that storage location - possibly
leftover data from earlier in the program - and STRING genuinely uses
that leftover value as the real starting position for writing, with no
default fallback to the beginning of the field. This means STRING can
silently start overwriting the receiving field partway through instead
of from its start, corrupting whatever content was previously there
from that position onward. This is a real, silent bug rather than
something COBOL catches on its own, because an uninitialized pointer
value is still a technically valid one as far as the compiler and
runtime are concerned - the program runs and completes normally, with
the only visible sign being wrong output that could easily go
unnoticed.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly traces the concrete mechanism (an uninitialized field
holding an arbitrary leftover value, treated as valid by STRING) rather
than just restating that initialization is "required," and explains
specifically why the resulting failure produces no error at all.