I'm working on converting older code with LOTS of MOVE statements to free-format. I've read the description of the MOVE op code in the RPG reference, but I'm left with some questions about exactly how this op code moves bits, particularly between character fields and negative numeric fields.

In discussing character-to-numeric MOVEs, the RPG Reference always uses a character string with "N" (X'D5') as the last character. Apparently in such a MOVE, the entire byte is moved, and the "D" in the Zone portion of the numeric field makes the number negative. The other characters seem to have the low-order bits moved to the target field, with a X'F" forced into the high-order bits. (A character "H" [X'C8'] becomes "8" [X'F8'].) In the manual, then, character "PH4SN" becomes

In another thread (referenced below), Barbara Morris contributed and made the comment "D and F aren't equivalent. B and D are equivalent (negative) and A, C, E and F are equivalent (positive)."

Now, since "A"-"I" are represented by X'C1'-X'C9', "J"-"R" are represented by X'D1'-X'D9', and "S"-"Z" are represented by X'E2'-X'E9', and zone values of "C" and "E" are positive, does that mean that character strings ending in "A" through "I" and "S" through "Z" convert to positive numbers, while character strings ending in "J" through "R" convert to negative numbers?! This seems unlikely, but would seem to be the conclusion if my logic is correct.

Therefore, perhaps my premise is incorrect, that the entire rightmost byte is moved. So, what exactly happens — especially with the rightmost byte — when moving numeric values to character fields?

The free-format code generated by our conversion tool makes use of %DEC and %EDITC BIFs and manipulation of fields as character string using %SUBST. We've had problems with negative packed numbers (with the rightmost bit containing X'D0'-X'D9') "confusing" %DEC when the negative number is converted to character and the last character becomes "}"/"J"?.../"R". ( I asked about that in this post: %EDITC with Negative numbers. This is where I saw Barbara Morris's comment.

In discussing character-to-numeric MOVEs, the RPG Reference always uses a character string with "N" (X'D5') as the last character. Apparently in such a MOVE, the entire byte is moved, and the "D" in the Zone portion of the numeric field makes the number negative. The other characters seem to have the low-order bits moved to the target field, with a X'F" forced into the high-order bits. (A character "H" [X'C8'] becomes "8" [X'F8'].) In the manual, then, character "PH4SN" becomes

**-**78425.In another thread (referenced below), Barbara Morris contributed and made the comment "D and F aren't equivalent. B and D are equivalent (negative) and A, C, E and F are equivalent (positive)."

Now, since "A"-"I" are represented by X'C1'-X'C9', "J"-"R" are represented by X'D1'-X'D9', and "S"-"Z" are represented by X'E2'-X'E9', and zone values of "C" and "E" are positive, does that mean that character strings ending in "A" through "I" and "S" through "Z" convert to positive numbers, while character strings ending in "J" through "R" convert to negative numbers?! This seems unlikely, but would seem to be the conclusion if my logic is correct.

Therefore, perhaps my premise is incorrect, that the entire rightmost byte is moved. So, what exactly happens — especially with the rightmost byte — when moving numeric values to character fields?

The free-format code generated by our conversion tool makes use of %DEC and %EDITC BIFs and manipulation of fields as character string using %SUBST. We've had problems with negative packed numbers (with the rightmost bit containing X'D0'-X'D9') "confusing" %DEC when the negative number is converted to character and the last character becomes "}"/"J"?.../"R". ( I asked about that in this post: %EDITC with Negative numbers. This is where I saw Barbara Morris's comment.

## Comment