Exercise 1: The Raw Stored Digits for 4210.5 in a PIC 9(5)V9(1) Field — Possible Solution ==================================================================== PIC 9(5)V9(1) describes a field with 5 digits before the implied decimal point and 1 digit after it - 6 real digit positions total. WORKING OUT THE STORED DIGITS The value 4210.5 splits into an integer part (4210) and a decimal part (.5). The integer part needs to fill all 5 of the "9(5)" positions, so it's padded with a leading zero: 04210. The decimal part needs to fill the single "9(1)" position after the V: 5. Concatenating these two pieces together, in order, gives the real stored digit sequence: 04210 + 5 = 042105 This is exactly 6 digits, matching the field's own total real digit count (5 + 1 = 6). WHY NO DECIMAL POINT APPEARS AMONG THESE DIGITS This chapter's own real material explains directly why: the V in a PICTURE clause only indicates where the decimal point belongs when the value is interpreted or displayed - it does not itself occupy any real, physical storage space. COBOL simply doesn't store a decimal point character as part of the field's own raw digits at all; it stores only the digits themselves, and separately "remembers," via the field's own PICTURE clause definition, that the boundary between the integer and decimal portions falls after the 5th digit. WHY THIS DOESN'T AFFECT HOW THE VALUE IS ACTUALLY USED This chapter's own real warning is specific: while the raw stored digits never contain a decimal point, this doesn't cause any real problem for using the value correctly. COBOL applies the implied decimal position automatically whenever the field is used in arithmetic or displayed - the value still behaves, functionally, as 4210.5. The only real place this becomes visible is if someone looks directly at the field's own raw underlying storage, where they would see 042105 with no decimal point anywhere in it. ANSWER: A field defined as PIC 9(5)V9(1) holding the value 4210.5 would store the raw digit sequence 042105 - the integer part (4210) padded to 5 digits as 04210, followed by the single decimal digit (5), concatenated together with no separator. A decimal point never appears among these stored digits because, per this chapter's own real material, the V only marks where the decimal point belongs when the value is interpreted or displayed - it does not itself occupy any real storage space, so only the actual digits are physically stored. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly works through the real digit-padding and concatenation process to produce the exact stored value, and explains the underlying reason (V marks position without occupying storage) rather than simply asserting that no decimal point is stored.