RE: Strange behavior when calling subprocedure from CL. -- MIDRANGE-L

*BYVAL is not the right answer.

It would be if the OP was using VALUE instead of CONST.

The problem is the differences between RPG 1 byte variables and CL 1 byte variables. Look in the
archives for more info, but you need to use EXTPROC(*CL).

EXTPROC(*CL:name)
Specifies an external procedure that is written in ILE CL, or an RPG
procedure to be called by ILE CL. Use *CL if your program uses return
values or parameters passed by value with data types that CL handles
differently from RPG. For example, use *CL when prototyping an RPG
procedure that is to be called by a CL procedure when the return value is
1A.

HTH,
Charles

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, December 04, 2007 10:52 AM
To: Midrange Systems Technical Discussion
Subject: Re: Strange behavior when calling subprocedure from CL.

Which are you running in debug: The CL, or the RPG? Or,
where are you
seeing the error; CL or RPG?

Something probably totally tangential, and I'm no expert on
the CL to RPG
ILE stuff, is perhaps changing
CALLPRC PRC(EXISTS) PARM((&BUDBAKNAME) (&OBJTYPE) +
(&OBJLIB)) RTNVAL(&VALID)
to
CALLPRC PRC(EXISTS) +
PARM((&BUDBAKNAME *BYVAL) (&OBJTYPE *BYVAL) +
(&OBJLIB *BYVAL)) +
RTNVAL(&VALID)
Since your RPG uses CONST.

Now, I fail to see how you'd get an error in the RPG based on
this. &VALID
is not passed IN.
Therefore, if your RPG does something like
ReturnVar= IbmAPI(POBJECT:POBJECTILIB,POBJECTTYPE);
return ReturnVar;
Then I do not see how the manipulation of ReturnVar would be
affected by
whether or not it is called by CL.

Zooming around again. If you want to suspect the black
helicopters of CL
then you could always try changing the size of ReturnVar and
&valid from
1A to 2A. I think I've heard something in a beer soaked brain cell
somewhere about 1A being a problem child going from CL to RPG.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

"Terry Anderson" <terrya@xxxxxxxxxxxx>
Sent by: midrange-l-bounces+rob=dekko.com@xxxxxxxxxxxx
12/04/2007 10:29 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

To
<midrange-l@xxxxxxxxxxxx>
cc

Subject
Strange behavior when calling subprocedure from CL.

Greetings List,
I have a subprocedure that I have been using since 2002 and it works
flawlessly when called from an RPG program. When I call it from a CL
program, it give me the "Pointer not set for location
referenced" error.
Usually this happens when I forget to pass a parm or the parm being
passed is not the same size or data type as defined in the prototype.
However, when I run the program in debug I find that the
error is not on
the variables being passed in, but on the variable being returned. The
return variable in the CL and the variable being returned by the
subprocedure are both one position character fields.

Has anyone ever seen this before? The fields in the prototype are
defined as CONST. Do I need to define the variables passed by the CL
differently to account for this? We are running V5R4.

The prototype is listed below along with the call from the CL.
&BUDBAKNAME is a field in file VCMBUDCPYF. It is defined as 10A.

D EXISTS PR 1
D POBJECT 10 CONST
D POBJECTTYPE 10 CONST
D POBJECTILIB 10 CONST OPTIONS(*NOPASS)

PGM PARM(&VCMLIB)

DCL VAR(&VCMLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&OBJLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&OBJTYPE) TYPE(*CHAR) LEN(10)
DCL VAR(&VALID) TYPE(*CHAR) LEN(1)
DCLF FILE(VCMBUDCPYF)

CHGVAR VAR(&OBJLIB) VALUE(&VCMLIB)

LOOP: RCVF
MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDCLPGM))

CHGVAR VAR(&OBJTYPE) VALUE('*FILE ')
CALLPRC PRC(EXISTS) PARM((&BUDBAKNAME) (&OBJTYPE) +
(&OBJLIB)) RTNVAL(&VALID)

Thanks,

Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975

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

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.