Re: Parameter passing CL to RPGLE

On 06-Oct-2016 15:58 -0500, Peter Dow wrote:

On 10/6/2016 1:52 PM, CRPence wrote:

On 06-Oct-2016 15:41 -0500, Peter Dow wrote:

On a v5r4 system I have a CLLE program with

DCL &RC *CHAR 2
DCL &CALLER *CHAR 10
DCL &PARMS *CHAR 111
CALL PGM(OB0050AN) PARM(&RC &CALLER &PARMS)

And an SQLRPGLE program that has

d OB0050AN pi
d @RETURNCODE 2a
d @CALLER 10a
d ptrPARMS *

d @PARMS e ds extname(OB0050PR) based(ptrPARMS)

When I debug the SQLRPGLE program, I can see the values passed for
@RETURNCODE and @CALLER, but for ptrPARMS it shows SPP:*NULL.

Hmm. I would think there would also be a MCH3601 exposed, somehow,
to reveal\indicate why the value is presented as *NULL; what does
EVAL ptrPARMS:X show?

Yes, as soon as the code tried to reference a subfield of @PARMS, it
got an MCH3601. As does eval ptrPARMS:x in debug.

What am I missing?

The interface does not match to the CALL. The CL would either
need to pass the address of (&PARMS) [i.e. CHGVAR (&cl_ptrPARMS)
(%addr(&PARMS)) and then CALL … PARM(&RC &CALLER &cl_ptrPARMS)], or
the RPG would need to change to type of ptrPARMS to be 111A [and
probably best also renamed to something like data_ofPARMS].

I was under the impression that parameters are passed by reference,
i.e. a pointer is passed. Is that not the case?

Yes. A pointer to the data, the data as defined-by the declared type and length, is passed to the invoked program.

Or I cannot reference any given parameter's pointer by defining the
parameter as a pointer?

That by-reference pointer, the "parameter's pointer" is essentially an implicit basing pointer for the variable declared as the parameter on the interface. If specifying a pointer data-type for that parameter were understood implicitly to be the by-reference pointer, then try to imagine how could a pointer ever be passed by reference; the /answer/ is that it would not be possible, as that would mean the pointer was in effect, passed by-value.