× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, Kurt

The problem you are running into is that RPG defines a 3i 0 field as a
1-byte integer value and CL only supports 2-byte and 4-byte integer values.

Your first attempt is passing a *Dec 15 5 (by default) which is
x'000000000200000F', your second attempt a 2-byte integer value of x'0002',
and your third a *Dec 3 0 which is x'002F'. In all three cases RPG is only
looking at the first byte (as it's only expecting one byte) and sees the
leading x'00'. x'00' represents 0 in an integer variable.

One work around (there are many) is to shift the 2-byte integer value in the
CL program by one byte. This can be done by multiplying the value by 256 as
in:

Pgm
Dcl Var(&ReadMethod) Type(*Int) Len(2) Value(2)
ChgVar Var(&ReadMethod) Value(&ReadMethod * 256)
EndPgm

This will change ReadMethod from x'0002' to x'0200'. RPG will see x'02' and
treat it as the integer value of 2.

Taking this approach you should make very sure you document clearly what
(and why) you are doing this! Better, but I assume not an option, is to
change the RPG prototype.

Bruce

On Fri, Oct 16, 2009 at 10:15 AM, Kurt Anderson <
kurt.anderson@xxxxxxxxxxxxxx> wrote:

Ok, I have to bite the bullet and ask the list. I'm having a problem
passing a CL variable into a 3i0 RPGLE parameter.

Procedure prototype:
D $ReadSettingP PR 10i 0 ExtProc( *CL: '$READSETTINGP')
D ReadMethod 3i 0 Const
D NumberOfKeys 3p 0 Const
D LockRec n Const


The ReadMethod in the RPG procedure is constantly receiving a value of 0,
and I'm trying to pass in a value of 2.

I've tried:
CALLPRC PRC($READSETTINGP) PARM((2) +

DCL VAR(&READE) TYPE(*INT) LEN(2) Value(2)
CALLPRC PRC($READSETTINGP) PARM((&READE) +

DCL VAR(&READE) TYPE(*DEC) LEN(3 0) Value(2)
CALLPRC PRC($READSETTINGP) PARM((&READE) +

I also found an article that suggested doing the following, but as far as I
can tell the PARM keyword for CALLPRC does not allow built in functions.
DCL VAR(&READE_INZ) TYPE(*DEc) LEN(3 0) VALUE(2)
DCL VAR(&READE) TYPE(*CHAR) LEN(4)
CHGVAR VAR(%BIN(&READE)) VALUE(&READE_INZ)
CALLPRC PRC($READSETTINGP) PARM(%BIN(&READE) +


Does anyone have any ideas? Most of what I find about CLLE to RPGLE issues
is in regard to RTNVAL.

I have ExtProc on the procedure above as me trying anything to get this to
work. And some archive posts made it seem like I needed it anytime a
procedure is dealing with a 1-byte value, however the help says: "Use *CL if
your program uses return values with data types that CL handles differently
from RPG." So I'm guessing it's use here is unneeded.

Thanks a lot,

Kurt Anderson
Sr. Programmer/Analyst
CustomCall Data Systems
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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.