Re: Strange behavior when calling subprocedure from CL.

Hi Terry,

It has to do with differences in the way RPG and CL interpreted the ILE spec. ILE CL and ILE C both pass 1 character return values as binary integers. They use C's widening rules, etc. However, when the return values are 2 bytes or larger they are passed as character strings.

ILE RPG and COBOL, however, always pass them as character strings (which, somewhere under the covers, uses a pointer and that's where your error comes from.)

RPG has EXTPROC keywords for the prototype that change this behavior. If you specify EXTPROC(*CL:'MYPROCNAME') or EXTPROC(*CWIDEN:'MYPROCNAME') RPG will change it's passing convention to match that of C or CL, and that will solve the problem. However, if you do this, you need to recompile and rebind any existing RPG code that calls the service program so that they, too, will use the new parameter passing method.

If changing the callers to use EXTPROC is too big of a hassle (For me, it has been for several service programs -- I don't want to change 2500 calling routines!) there's a workaround on the CL side of things.

Just declare the return value as being two characters instead of one:

DCL VAR(&TEMP) TYPE(*CHAR) LEN(2)
DCL VAR(&RTNVAL) TYPE(*CHAR) LEN(1)

CALLPRC PRC(MYPROC) RTNVAL(&TEMP)
CHGVAR VAR(&RTNVAL) VALUE(%SST(&TEMP 1 1))

Because character variables that have a length of 2 (or higher) are passed as character strings in CL (just like RPG) the preceding code will not cause the pointer error. Even though the RPG program returns only 1 char, the CL program receives two, making them compatible. You then use %SST to ignore the 2nd character, since it serves no purpose (other than making the calling convention compatible.)

Again, you don't have to use this workaround if you use EXTPROC(*CL:'MYPROC') on the RPG side. EXTPROC(*CL is, IMHO, more elegant because the "next guy" will find it easier to read and understand and can go to the manual to see what it does. But in a situation where you can't change the RPG side without breaking compatibility, using the 2-char CL rtnval approach makes things work properly without changing the RPG end of things.


Terry Anderson wrote:

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