Re: Odd CALLPRC behavior when using RPG indicator with RTNVAL

Hi David,

No, ExtProc(*CL:'name') is designed to solve the problem where you can't return a 1A or 1N variable from an RPG subprocedure to CL's CALLPRC. That's all ExtProc(*CL) does is fix that one error.

The problem with ExtProc(*CL) is that it breaks backward compatibility. If you have an RPG subprocedure without ExtProc(*CL) that's being called from lots of places (existing RPG programs) then adding ExtProc(*CL) will force you to recompile/rebind all of those existing callers, because it changes the way parameters are passed (and doesn't even signal a signature violation!)

The workaround of using a RTNVAL that's *CHAR 2 (instead of *LGL or *CHAR 1) is really only useful because it gets around the problem without forcing all of the existing callers to be recompiled/rebound.

I'm not familiar with the problem you describe of getting x'00F0' instead of x'F040'. I can only guess that it's widening the return variable to a 2-byte value instead of a 1-byte value, but I can't think of any logical reason to do that... Never used IBM i 6.1, myself. Reporting it to IBM is the right thing to do, IMHO.


David Gibbs wrote:

Roger Harman wrote:

Just curious as I've never used it but isn't the ExtProc(*CL) on the RPG
prototype supposed to deal with returning indicator variables to CL? I
thought that was to get around the issue of having to return 2 bytes.

I've never used the extproc(*cl) option ... but was under the impression that it was used to describe a CL procedure called from RPG, not a RPG procedure called from CL.

I could be wrong, of course.

david