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 http://www.mcpressonline.com/mc?14@1.SETjcsjLb34.1@.6aecda48 ============================================ 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'. Tom

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 http://www.mcpressonline.com/mc?14@1.SETjcsjLb34.1@.6aecda48 ============================================ 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'. Tom