Re: Odd CALLPRC behavior when using RPG indicator with RTNVAL

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