Passing a Binary Field to an RPGLE Program using CALL

I need to pass a 9 digit Binary field (4 bytes in length) to an RPGLE program from a non-RPG program. Following shows how I coded in RPGLE. * Parameter Fields d pmbid ds d mbid 9b 0 .. .. c *entry plist c parm pmbid .. .. When the Binary value is passed as the above parameter, the program doesn't convert it to the correct value. I debugged the programs and found that the binary values sent by the calling program is converted to a different value by RPGLE. For your info. following are the values sent by non-RPG and received by RPGLE. Sent Received by RPGLE 000000065 000000006 000000075 000000007 000001136 000000275 000001198 000000281 000001240 000000292 However, When I define this as either Packed or Zoned in both programs (Calling & Called) it works fine. Please provide a solution as I must use passing field in Binary. Thanks & Regards!

Answer Wiki

Thanks. We'll let you know when a new response is added.

I don’t believe the problem is related to 9b0 vs 10i 0. I suspect there’s a mismatch between the caller and the called program. (though seeing the caller’s code would certainly help)

If we take the calling value of 000000065 as a hex value where there’s really a leading 0 nibble (not shown) and a trailing 0 nibble (not shown) we get x’0000000650′ which, when displayed in the caller, would be decimal 6 (essentially ignoring the x’50’ traling byte).

If we take the calling value of 000001136 as a hex value where there’s really a leading 0 (not shown) and a trailing 0 (not shown) we get x’0000011360′ which, when displayed in the caller, would be decimal 275 (again ignoring the 5th byte of x’60’).

Repeat the experiment with a caller value of x’0000001240′ and you get decimal 292.

Based on this I suspect the caller is not directly passing a 4-byte integer/binary value. I am however making a ton of guesses here. I’m guessing that the “input” is hex where you’re not sure what decimal value is actually being used, and the output decimal. It’s darn hard to be off by a nibble, but could be done easily enough when documenting values in a note when you don’t know the actual values being used.

Then again, I could be way off. But I find the consistency in calculating the perceived result in the called program as an interesting coincidence.

Bruce Vining


Go to MCPress and read Bob Cozzi article about binary fields.

It may be as simple as changing the spec from 9B to 10I 0


I assume you’re trying to use the ‘B’inary data type because you aren’t allowed to change the RPG program. (If you can change the RPG, there is no reason to use that data type since there are no decimal positions. Decimal positions would be the only reason to use it at all. It should be avoided.)

However, the first thing that comes to mind is a COBOL program that isn’t properly synchronizing its data structures. It has a BINARY field in a data structure, and the structure isn’t synchronized, so the positioning is off.

What language is calling the RPG? How is the field defined in that program? Any data structure should be shown.

Also, note that your *ENTRY PARM item doesn’t reference the ‘B’ data item directly — it points to a data structure which is a ‘character’ data item. Since we don’t know what is being addressed in the calling program, we can’t tell what you should expect to see in variable ‘mbid’.


Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • RolandT
    I'm not sure, but I think that you need to define the RPG field as 4B. Binary fields can only be numeric and don't support number of decimals, so you don't need to specify zero decimals.
    0 pointsBadges:
  • Splat
    RolandT, in my experience I've found it neccesary to define a 4 position binary field as 9B 0
    9,635 pointsBadges:
  • DwightRoberts
    9b0 is a 4-byte value. Each byte is 8 bits represented by 2 hex characters 00 thru FF therefore:
    X'00000000' = 0
    X'00000001'  = 1
    X'000E72BD' = 946877 
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: