ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Proper RPGLE definition for Binary 4 API parameters?

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

  • Proper RPGLE definition for Binary 4 API parameters?

    Many IBM API's have numeric parameters, that the documentation usually says they are type Binary, length 4 bytes.

    What is the proper RPGLE numeric definition for these? In different API usage examples I have seen over the internet, I have seen int(10), uns(10), and bindec(9) all used

    I'd like to know once and for all what the proper definition is.

  • #2
    A good question.
    Personally I would prefer using uns(10) unless it is specified that the returned value
    can be negative. Then int(10) should be used.
    And definitely not bindec !!!

    This article explains why not to use bindec.
    http://ibmsystemsmag.com/ibmi/developer/rpg/binary-integer/

    Regards

    Peder

    Comment


    • #3
      Technically, the matching definition for the API definition of "BINARY 4" is INT(10).

      Interesting idea to define it as UNS(10) when you know it can/should never be negative. That does seem like a good idea, especially for input parameters, since passing a negative number would get an RPG exception on the call rather than a later exception from the API.

      Comment


      • #4
        Thank you both. I will stick to using int(10) and uns(10)

        Using uns(10) might prevent passing an invalid negative number, but it might allow you to pass a number that's too large instead. Though that's probably less likely than passing a negative number

        Comment


        • #5
          Vectorspace, good point about passing a too-large number. Even though it may be less likely than passing a negative number, a too-large number would appear as a negative number to the API. I guess most (all?) APIs would give an error for a negative number if the parameter only makes sense when it's non-negative, but somehow for me, the idea of passing a too-large unsigned number that will be interpreted as a negative number just seems wrong.

          With this new idea that you suggested, I no longer think it's a good idea to use UNS if the API says "Binary". Now, I would only use UNS for the rare cases where the API doc says "Unsigned binary".

          Also, using UNS for a "binary" parameter violates my rule, which I had temporarily forgotten (*blush with shame*): "Never lie to the compiler".

          Comment

          Working...
          X