Re: Odd CALLPRC behavior when using RPG indicator with RTNVAL

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

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