System is not abending while executing the below code.
IF WS-VAL > 0
END-ID
System is abending with S0C7 when we have below values in the variable.
WS-VAL='V__________.'
Could some one clarify below questions?
1. Why system is not abending when we have alphanumeric values in the variable?
2. Why system abends when we have special characters in the variable?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
That's probably because WS-VAR is packed by the compiler and a "CP" instruction is issued against the packed value.
In a PACK, CL10'2222211AA' is packed into an intermediate compiler field as PL5'222221111' and you probably ask WHY?
PACK instructions discard the zone-nibble (except for the last byte, where the byte is flip flopped). The letter 'A' is a X'C1', so the sign-byte is equal to either X'1C' or X'1F' (after a possible OR-immediate).
Check your compiler option as it might equal NUMPROC(NOPFD), which is the default.
However, if it's NUMPROC(PFD), then the compiler may NOT pack WS-VAR and issue a "CLC" against the data with the result of the compare being not greater than zero, in order word, not true.
If after a PACK, if any 4-Bit Nibble exceeds X'9'/B'1001' (except for the sign-nibble), then a S0C7 is raised when a decimal instruction is issued against it.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Nagendran wrote:
05 WS-VAL PIC 9(011).
WS-VAL = '2222211AA'
System is not abending while executing the below code.
IF WS-VAL > 0
END-ID
Firstly, you have an 11-byte field, but only 9 bytes of data you are showing. Do you have leading blanks, or trailing blanks? Or did you leave a little bit out when you posted? Doesn't matter. Blank or A in you last character, then.
Quote:
System is abending with S0C7 when we have below values in the variable.
WS-VAL='V__________.'
This time you have 12 characters at my count. OK, so last character is underscore or period.
1. When testing against zero, WS-VAL is "packed". This involves tossing away all the "zones" (the left-most half byte - nibble - of each byte) apart from the right-most byte, which instead of being a "zone" is the "sign" for the field, so this swaps places with the right nibble of the rightmost byte to complete the packed field.
Since all your individual values have numerics in the number nibble, the pack instruction will form a valid number, subject to the sign being valid.
You are not receiving an S0C7, so we can deduce that you have NUMPROC(NOPFD) if you have a space as the final character or you end up with a "valid" sign anyway if you have "A" as the final character.
2. Now, with either a period or an underscore (4B or 6D) with NUMPROC(PFD) you would get an S0C7, as neither 4 nor 6 are valid signs. With NUMPROC(NOPFD) you'd get your sign fixed, but still get an S0C7 because all the other 6D's would give you a "D" in the number nibble, which isn't valid.
We already know you have NUMPROC(NOPFD) (or possibly NUMPROC(MIG) and code you are not showing us) so you'd be abending for the non-numerics in the number, not the numerics in the sign.
If you change your compile option to NUMPROC(PFD) you can get your first example to S0C7 if it has trailing spaces.
Basically, not a good idea to put non-numeric data in a numeric field. To me, it is better if it S0C7's, otherwise there is some weird value entering the system which you have just made "valid".