> I've got an odd problem that I can't quite pin down, and I haven't been
> able to find any info in the archives or the manuals.

Hmm.. that's a bit frustrating, since I *KNOW* I learned about this
problem on one of the Midrange.com lists (probably RPG400-L) but my
searches of the archives did not help me, either.


> I've got a CLLE program that does a CALLPRC like this:
>    callprc prc(rpglePrc) parms(&char10 &char20) rtnvar(&char1)

Well, you've put "parms" instead of "parm" and "rtnvar" instead of
"rtnval" but I'll assume that this is a mistake in your post to the
mailing list, and is not the problem in your original code.

So, moving on to what I think the problem is...

There's an incompatibility with return values when a CALLPRC calls an RPG
procedure... the incompatibility only manifests itself when the return
value is 1-byte long.   So,if you return a "1N" "1A", etc, you'll have the
problem that you're describing.

>      if doStuff(piChar10 piChar20) = 'ITSOK';
> p rpglePrc       b

Here, again, I'm going to ignore the fact that you missed a colon between
the two parameters to "doStuff" and you ended your procedure with a "B"
for "begin" instead of an "E" for "end" since I have a feeling that you
just made these mistakes in this post, and not in your "real" program..

So, on to the solution to the 1-byte compatibility issue...

If you want to fix it on the RPG side, and you have a relatively recent
release of the ILE RPG compiler, you can use ExtProc(*CL) to work around
the problem.  For example, observe the following code:

D rpglePrc        PR              N   extproc(*CL: 'RPGLEPRC')
D   piChar10                    10A
D   piChar20                    20A

P rpglePrc        b                   export
D rpglePrc        pi              N
D   piChar10                    10A
D   piChar20                    20A
         if doStuff(piChar10: piChar20) = 'ITSOK';
              return *off;
              return *On;
P                 E

The "ExtProc(*CL: 'RPGLEPRC')" on the prototype will force the compiler to
generate a procedure that's compatible with CL.   Note also that I've
spelled out the procedure name in ALL CAPS.  Procedure names in ExtProc
are case-sensitive, and unless you put the procedure name in quotes in the
CALLPRC statement, CALLPRC will also translate it to all caps.

If you don't want to change it on the RPG side, or if you've got an older
release where the EXTPROC(*CL) hasn't been introduced yet, you can also
fix the problem in the CL program simply by declaring your variable as
*CHAR 2 and using that, like this:

         DCL VAR(&CHAR1) TYPE(*CHAR) LEN(1)
         DCL VAR(&CHAR2) TYPE(*CHAR) LEN(2)
         DCL VAR(&CHAR10) TYPE(*CHAR) LEN(10)
         DCL VAR(&CHAR20) TYPE(*CHAR) LEN(10)

         CALLPRC PRC(rpglePrc) parm(&char10 &char20) rtnval(&char2)
         chgvar var(&char1) value(%sst(&char2 1 1))

(The RPG procedure is using your original code which returns 1N -- no
changes have to be made on the RPG side to use this workaround)

Since CALLPRC is now using a 2A return value, it doesn't trigger the

Hope that helps...

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].