Re: RPG-III to -IV conversion rehash worries - Part II

[Buck <kc2hiz@xxxxxxxxx>]

> You ready?  I wasn't!  Using 'PQRST':
>       MOVE      'PQRST'       NUMBER            5 0
>       MOVE      number        NUMBER@           5
>       DUMP
> gives:
>   NUMBER             PACKED(5,0)       78923.        '78923F'X
>   NUMBER@            CHAR(5)           '78923'       'F7F8F9F2F3'X
>
> Hmmm.

In EBCDIC, all the letters have a valid numeric character portion.  MOVE 
strips off the character portion of the character, and uses the numeric 
portion to convert to numeric.  That's what MOVE is supposed to do.  The 
last character of the 'from ' field is checked for a 'D' character 
portion.  If it is a 'D', the resulting number is treated as a negative, 
otherwise it is positive.

In the documentation, the 'zone' is the character portion, and the 
'digit' is the numeric portion.  The zone is the leftmost 4 bits, and 
the digit is the rightmost 4.

The letter A has zone C, digit 1 (x'C1')
The letter S has zone E, digit 2 (x'E2')
The letter J has zone D, digit 1 (x'D1')

Anything with a valid decimal digit in the second half of the hex 
representation will MOVE to a valid number.  Try '/', (x'61') to see 
what I mean.

If you want to force a decimal data error, you have to use a character 
which hasn't got a valid decimal digit in the digit punch.  Something 
like $ or #, perhaps.

The V5R3 RPG reference has a very old image (apparently scanned) that 
has an example of moving character to numeric. 
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/books_web/c0925085704.htm#HDRZZMOVE

Appendix B has a copy of the EBCDIC collating sequence: 
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/books_web/c0925085770.htm#HDREBCASC 

  --buck