Re: Parameter passing CL to RPGLE

Peter be aware that when you pass a parm greater than 32 characters through
a CL, this parm get garbage when it is receive in the RPG programm the best
way to send a parm greater than 32 in a CLLE is declaring one extra parm
after the long length parm which length is equal 1 and pass this parm as
empty, besides CLLE has a var definition type *PTR for pointer.



On Fri, Oct 7, 2016 at 5:48 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 07-Oct-2016 15:32 -0500, Peter Dow wrote:

On 10/7/2016 1:01 PM, CRPence wrote:

You can effect nearly identical to what TEMPLATE provides, using
BASED, as shown here. Note that the QUALIFIED keyword is *not*
required to be specified; although unqualified references will be
problematic if the basing pointer is not set correctly; oddly, I
do not get a MCH3601 on v6r1

See **Note** at bottom of my message for correction for the above claim.

[but I do on v5r3, and msg CPF8E17

when EVAL @MODE {<ed> with the debugger}] when the basing pointer
is initialized to *NULL as shown, and instead get INCORROUT UNPRED
(UR) results -- but the code shown here sets the pointer to the
address of the by-reference-pointer *immediately* upon entry:

d ptrToData s * inz(*NULL)
d @PARMS e DS extname(OB0050PR)
d based(ptrToData)

d OB0050AN pi
d @RETURNCODE 2A
d @CALLER 10A
d PARMS likeds(@PARMS)

/free
ptrToData = %addr(PARMS) ;

// The following, if un-commented, are function equivalents:
// if parms.@mode = 'B' ;
// if @MODE = 'B' ;

Thus, for the same reason those two predicates are the /same/, the
SQL can be written as shown here, thus avoiding a qualified name
that would prevent the pre-compiler from functioning as desired:

UPDATE myTable SET myColumn = :@MODE WHERE ...

Interesting that the compiler doesn't complain about the unqualified
name.

There is no requirement to use qualified names in the mainline code,
because the QUALIFIED keyword was not specified on the @PARMS DS. Thus
essentially, the programmer has made a contract with the RPG run-time, that
the program[mer] will ensure the basing address will be properly set for
that DS.

If the pointer were set to some valid data but not the *ENTRY

parameter, which field would the compiler use when the field
reference is unqualified?

The qualified references are assuredly accessing the data for the field,
as defined by `*entry->the_field`. That is how they are known to the
run-time. So, no worries about them; seems that is already understood, but
stated for other readers of the archives.

However the unqualified references to those [sub]fields of @PARMS would
access the data defined by `ptrToData->the_field`. Such a reference would
offer-up\present whatever data was at the corresponding offset of
`the_field` within the DS, to the offset within the memory as defined by
the starting\base address of the basing pointer `ptrToData`. These
unqualified field references merely provide a window onto whatever storage
is addressed by the basing pointer; thus outside of the control of RPG
run-time, and the onus on the programmer to set that address
appropriately. So there really is just *one field* defining the storage
and data-type for each of the subfields, but two possible basing pointers;
either the *entry address [which is always used for the qualified
references, as assured by the compiler for the run-time], or the ptrToData
address [which is used for the unqualified references, for which the
programmer needs to establish\set an appropriate address].

And that is why I was shocked, that on v6r1, when the basing pointer was
not set [having been left initialized to *NULL, thus the effect should have
been a x2401 exception; i.e. mch3601] when making the unqualified
reference, the result was an unpredictable reference [but at least v5r3
exhibited the expected mch3601].
**Note** **Note** However I since went back and checked, to find that I
had been mistaken; of my own stupidity, both for expecting to see the
English text "pointer not set" whilst I was working on a *non-English*
system, and a monitor suppressing the error. *Oops* I mistakenly thought
I had seen a message for the failing EVAL in the joblog, but it was in
fact, the expected MCH3601 -- I know, I know, if I review the *spooled*
joblog, not the active joblog! Anyhow, I had coded a monitor in my program
to ignore the pointer-not-set condition because that had allowed me to test
both variations [pass-by-reference of a pointer or pass-by-reference of the
typed-data] in just one program, by having the CL make the two distinct
invocations successively.

--
Regards, Chuck


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.