Re: CallPrc issue with 3i 0 parm

[Bruce Vining <bvining@xxxxxxxxxxxxxxx>]

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.