Exercise 1: Moving "COBOL" into PIC X(3) and Why Numeric MOVE Differs — Possible Solution
====================================================================

This chapter's own real alignment table gives two genuinely different
rules depending on whether the destination field is alphanumeric or
numeric, and applying each one separately explains both halves of this
exercise.

WHAT HAPPENS MOVING "COBOL" INTO PIC X(3)
This chapter states that alphanumeric fields are left-justified, with
extra characters on the right being truncated when the destination is
shorter than the source. "COBOL" is 5 characters long; PIC X(3) only
holds 3. Left-justifying "COBOL" and truncating from the right leaves
only the first 3 characters: "COB". The final two characters, "OL",
are simply discarded.

WHY A NUMERIC MOVE WOULD BEHAVE DIFFERENTLY FOR A SIMILAR LENGTH
MISMATCH
This chapter states plainly that numeric fields are not left- or
right-justified the way text is - they're aligned on the implied
decimal point instead, with padding or truncation happening at
whichever end is actually needed. If a numeric value were too long for
its destination field, the truncation would happen based on which
digits fall outside the destination's own real digit positions relative
to that decimal point - potentially trimming digits from the left
(the most significant, integer-side digits) rather than automatically
trimming from the right the way the alphanumeric example above did.

WHY THE TWO RULES ARE GENUINELY DIFFERENT, NOT JUST DIFFERENT EXAMPLES
The alphanumeric case discards characters based purely on position
counted from the left edge of the string. The numeric case instead
discards digits based on their real significance relative to the
decimal point - which specific end (leftmost integer digits or
rightmost decimal digits) gets trimmed depends on where the actual
mismatch falls relative to that point, not simply on raw left-to-right
character position the way text handling works.

WHY THIS MATTERS
This chapter's own warn-box makes exactly this point directly:
assuming numeric truncation works "like text, just trimming from
wherever text would" is a real, common source of confusion, since the
decimal-point-based alignment can trim from the left end of a number
in situations where trimming text always happens on the right.

ANSWER: Moving "COBOL" into a PIC X(3) field produces "COB" - the value
is left-justified and the two extra characters on the right ("OL") are
truncated, per this chapter's own real alphanumeric alignment rule. A
numeric MOVE with a similar length mismatch would behave differently
because numeric fields align on the implied decimal point rather than
being left- or right-justified like text - truncation happens based on
digit significance relative to that decimal point, which can mean
losing digits from the left (integer) side rather than automatically
trimming from the right the way the alphanumeric example does.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly applies the chapter's own alphanumeric truncation rule
to compute the specific real result, and explains the structurally
different real reason numeric truncation can behave oppositely,
grounded in decimal-point alignment rather than raw character position.