Personally I don't consider it remotely good practice. I always test for NUMERIC, REDEFINES as PIC 9(x) (USAGE DISPLAY) and MOVE the PIC 9(x).
I believe that back in the mists of time it was not possible to move PIC X(x) to a "computational" field.
None of what you have done will cause a S0C7, although your results may not be what you expect (as you didn't expect it to work). Try using the PIC 9(2) in a calculation of some type - it will work. However, change the value of your 88 to ".." and try, you'll get the S0C7.
Why do you have NUMPROC(MIG) as a compile option? It is intended as a migration-support option, although nothing stops you using it, but you should be aware of what it does.
Joined: 06 Jun 2008 Posts: 8418 Location: Dubuque, Iowa, USA
Could you please guess
Nope. When it comes to the compiler, I either know or find out -- I don't guess.
If you are surprised to find that PIC X variables can be moved to PIC 9 variables, the surprise is only because you don't pay attention to this forum. The issue comes up at least once every other month.
An S0C7 ABEND occurs when dealing with invalid numeric data. Since COBOL usually packs USAGE DISPLAY data before computing with it, that means any character in the collating sequence that has the values 0 through 9 in the rightmost 4 bits of the byte will convert to a numeric since the zone bits (the leftmost 4 bits) will be stripped off during the conversion to packed decimal. The S0C7 indicates that something other than 0 through 9 was found in the rightmost 4 bits of at least one byte.
In other words, your "surprise" results are usual and expected for the data you presented.