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