Re: CallPrc issue with 3i 0 parm -- MIDRANGE-L

Kurt,

If you're developing new and, based on your parameter names, it deals with
CL access to database (method, number of keys, record locking) you may want
to take a quick look at http://www.powercl.com/ and
http://www.powercl.com/clf/clfcommands/readrcdclf (note that this is a
product I market so this is also a vendor plug).

The ReadRcdCLF command has keywords such as TYPE, KEYLIST, and RCDLCK (among
quite a few others). Following your ReadMethod parameter, TYPE can be a
variable or a constant such as *NXT, PRV, *FIRST, *LAST, *KEY, *SAME, etc.
KEYLIST is also quite flexible and, assuming you have other parameters than
those shown -- such as the key values, provides correct formatting of CL
data variables to database field definitions. A problem you will most likely
run into as you try to format various CL key arguments to match database
expectations (much like the problem of formatting ReadMethod to match RPG
expectations).

If you are attempting to create *general purpose* database access for CL by
way of RPG procedures then problems such as 3i 0 to 5i 0 are only the
beginning of your "learning experience" (insert smiley face here). I've been
there and know...

Bruce Vining

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

Thanks for the response, Bruce.

I'll consider that closure. ;) Since I'm developing new, I'll likely
change the ReadMethod parameter to 5i0 for CL compatibility. I just need to
tell myself, "It's only one extra byte, it'll be ok."

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bruce Vining
Sent: Friday, October 16, 2009 11:09 AM
To: Midrange Systems Technical Discussion
Subject: Re: CallPrc issue with 3i 0 parm

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.

--
Regards,
Bruce
www.brucevining.com
www.powercl.com
--
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.

--
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.