On 22-Jan-2014 04:46 -0800, rob@xxxxxxxxx wrote:
Ken Sims on 01/21/2014 04:26 PM wrote:
On Tue, 21 Jan 2014 20:09:15 Gary Thompson wrote:
I am looking at changing a local program used for FTP.
Are optional parameters possible in CLLE ?
The idea is existing programs calling this changed program will
not pass the new parameter and will not need changing.
Note that all of the responses about trying to use the parameter
and monitoring for an invalid/null pointer are NOT correct for not
passing a pointer at all (unless CLLE does something under the
covers for checking the number of parameters passed versus the
field being accessed).
If a pointer is not passed (valid or null), then there could be a
valid pointer in the memory location where that pointer would be if
it had been passed.
You need the equivalent of the RPGLE %PARMS BIF. I suspect that
you will need to use one of the CEE APIs to do that, but I don't
know. I have many RPGLE programs that can handle varying numbers
of parameters, but I've never done that in CLLE.
Seemed to work just fine in debug. You want to give a sample of how
this could happen?
Not only does debug cause differences in how initialization occurs
for a program, but prior invocations made also may play a role in how a
later invocation functions [or fails], due to the possibility of
re-utilized but not re-initialized storage by the OS LIC AI
[Activation\Invocation] feature.
An inference that the invocation /seems to function/ may be found
eventually [with varied testing] to be instead, an invocation that
merely /mostly functions/; perhaps even most undesirably, functions
incorrectly unpredictably instead of only ever failing with an exception
condition. Examples have been given in the past, whereby a prior
invocation made with N+x [x>=0] parameters causes a later invocation
with N-y [y>=1] parameters to /see/ that an argument was specified for
the Nth parameter even though the invoker incorrectly invoked with fewer
than the required N parameters. That is, although the Nth argument was
neither specified nor explicitly omitted, the invoked code can not
distinguish the lack of an argument from an actual argument having been
specified; thus GIGO. In that case, old callers either must be updated
to specify *OMIT for the new parameter, or the invoked code must devise
some means to distinguish old callers [that will be improperly invoking
without either *OMIT or explicitly *NULL], so the modified invoked code
knows when to avoid /looking/ at the parameter that corresponds to the
unspecified argument.
So, a specific example could show that the /unpredictable/ nature is
indeed at least somewhat predictable. But intuitively, if the results
are truly unpredictable, then even such an example might just function
well, without the negative condition being manifest. That would surely
confound an attempt to describe why the situation must be avoided.
Thus, just a reference to the docs should suffice.? As has already been
posted [by Gary]; though via a different link to the same topic:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/passp.htm>
"... When calling an ILE program or procedure, the operating system does
not check the number of parameters that are passed on the call. In
addition, the space where the operating system stores the parameters is
not reinitialized between program or procedure calls. Calling a program
or procedure that expects n parameters with n-1 parameters makes the
system use whatever is in the parameter space to access the nth
parameter. The results of this action are very unpredictable. This also
applies to programs or procedures written in other ILE languages that
call CL programs or procedures or are called by CL programs or
procedures. ..."
The discussion of the OP scenario may be somewhat moot however,
unless the characteristics of the old\existing callers [that are
intended to remain unchanged] is clarified, and the characteristics of
the old\existing called executable object and the intended replacement
are clarified; possibly even including details of the existing
parameters\declarations and known input values and possibly even
known-to-be never-input values from the callers, to be able to provide
better ideas on how to allow those existing invokers to remain unchanged
while allowing the changed [or newly CLLE] invoked code to avoid
improper assumptions for which the effect may be either a failure with
an exception or incorrect output.
midrange.com
