|
Hello, > 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. Anyways... > 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'; [SNIP] > 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 /free if doStuff(piChar10: piChar20) = 'ITSOK'; return *off; else; return *On; endif; /end-free 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 incompatibility. Hope that helps...
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.