Re: Parameter passing CL to RPGLE

On 06-Oct-2016 17:25 -0500, CRPence wrote:

On 06-Oct-2016 16:24 -0500, Peter Dow wrote:

[…] I tried […]

DCL &PTRPARMS TYPE(*PTR) ADDRESS(&PARMS)
CALL OB0050AN (&RC &CALLER &PTRPARMS)

which gave OB0050AN a non-null ptrPARMS, but it doesn't seem to be
pointing to &PARMS -- it shows all * for the values instead of the
values I put in &PARMS. […]

The following output, I presume?

EVAL @PARMS
OB0050PR OF @PARMS =
....5...10...15...20...25
1 '**********

That seems to be an issue with the debugger and/or how the compiler
handled the EXTNAME; i.e. the passed data is there, because an
actual line of code that examines [or copies] the data, will /see/
what is the data at that address from the invoker.

Try the following modified EVAL request, which would be to request
the same data, but in hex format for 111 bytes:

EVAL @PARMS:X 111
CPF8E28 - Variable not available to display.

In the RPG, add a standalone variable to match the CHAR(111) of caller; the PI and DS unchanged here:

d OB0050AN pi
d @RETURNCODE 2A
d @CALLER 10A
d ptrPARMS *
d @PARMS e DS extname(OB0050PR)
d based(ptrPARMS)
* Add the following standalone variable _for testing_
d c111 s 111A
/free
c111 = @PARMS ;

Then in debug, instead of asking for the value of @PARMS, ask for the value of C111; the following output [VALUE() to what I initialized the variable (&PARMS) in the CLP] proves the pointer is set properly, to the automatic storage of the invoker, *despite the debugger* being unable to show that data [for whatever reason] via the variable named @PARMS:

EVAL c111
C111 =
....5...10...15...20...25...30.
1 'Thirty some bytes of data here.

p.s. while this example shows the code is functional, again, the expected prototype is not a pointer passed by reference, but the typed-char(111) passed by reference. Better to code a LIKEDS like Charles suggested.