ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

How does MOVE work (down to the bit level)?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • How does MOVE work (down to the bit level)?

    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 -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.

  • #2
    Originally posted by Jerry G View Post
    So, what exactly happens — especially with the rightmost byte — when moving numeric values to character fields?.
    Oops. "... — when moving character values to numeric fields?"

    Comment


    • #3
      You probably need Barbara to give you a definitive answer but why do you need to know? As I said before - talk to Arcad. If their tool is not making the conversion correctly then tell them and get it fixed. You're not the only folks using JDE so I'm surprised that this hasn't been an issue for other shops.

      Of course you could always write a small subproc that uses the MOVE under the covers (so you don't have to look at it) that does the equivalent for you.

      Comment


      • Jerry G
        Jerry G commented
        Editing a comment
        Thanks, JonBoy. I had, in fact, asked ARCAD about this, To their credit, Transformer _can_ create an "*ALPHTONUM" warning to bring this situation to a programmer's attention. But about intercepting negative values (}/J/.../R), they wrote "We don’t choose to generate a complex instruction to manage this, because, in 99% (or 99,9 %) of the usage of moving ALPHA to NUMERIC field, there is no need of managing the possibility of negative value."
        I'm not sure "99.9%" is quite accurate ;-) ... but it's a fair point, and I suppose they have to draw the line somewhere!

    • #4
      When moving numeric values to character fields, the character field gets the zoned decimal version of the value. If the source numeric field is packed, say -12345, it's hex value is x'12345D (or it could be x'12345B' if the value was set in some weird way). In either case, the standard zoned version of that is x'F1F2F3F4D5', so the target character field would get x'F1F2F3F4D5' = '1234N'.

      If the conversion tool is converting MOVE from character to numeric using %DEC, then indeed, it won't work if the character field has a zoned value. %DEC doesn't understand values like say '1234N'; it only understands "real" numeric strings like '-12345'.

      Comment


      • Jerry G
        Jerry G commented
        Editing a comment
        Thanks, Barbara. I experimented and confirmed this myself, and also (FWIW to any other readers, and as you may be implying) that whether the source is PACKED or ZONED makes no difference in %EDITC's output.
        Can I submit an RFE to have %DEC pick up on these negative zones ... rather than RNX0105? ;-)
    Working...
    X