Re: optional parm in CLLE

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.