OK. These days it is ulikely that the MOVE itself will have an instruction generated which will cause an abend.
Using the subsequent result for calculation is a different thing.
Here is your number (S9(3)).
The right-most half byte of each byte is the "Numeric" nybble - and should always contain a hexadecimal 0-9. If it does not, any calculation with it will cause an abend (S0C7).
The left-most half-byte of the right-most byte is the "Sign" nybble - and should always contain a hexadecimal A-F. If it does not, any calculation with it will cause an abend (S0C7).
The remaining left-most half-byte are the "Zone" nybbles. As these are simply discarded when a Numeric (PIC 9 field with not COMP*) is "packed" for some calculation, they may contain any value and have no affect at all on the processing.
In your example there can not possibly in any circumstance be a S0C7. You should check, since you have a four-byte alpha-numeric and a three-byte numeric, which byte gets truncated.
Code: Select all
X'F1F2'
X'F1C2'
X'F1E2'
X'C1F2'
X'91F2'
X'F1C2'
X'C1C2'
X'F112'
X'F1FF'
MOVE PIC XX TO PIC S99.
You should be able to explain for each X'hhhh' example what the outcome will be - the value, or S0C7, from what I have described and from reading the Language Reference and Programmer's Guide where necessary.