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


  1.  Home
  2. MIDRANGE-L
  3. October 2009

RE: CallPrc issue with 3i 0 parm

Hey Bruce,

An old co-worker of mine and I wrote a program to generate a file encapsulated service program over a file, and it works pretty slick for what I need done. I'm a really big fan of file (and business logic) encapsulation. While it's not always easy to get others into the idea, once I've sold the concept it tends to be a blessing over and over. So I'm glad to see there's a product out there for it.

It's rare that I ever deal with CL database access, and while I now have the 1-byte RTNVAL and PARM issues dealt with, if there's more, well I guess I have more learning to do. ;)

-Kurt

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

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.





As an Amazon Associate we earn from qualifying purchases.

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