On 21-Jan-2014 12:09 -0800, Gary Thompson wrote:
I am looking at changing a local program used for FTP.

Are optional parameters possible in CLLE ?

There is support for omissible parameters. Not so much so, AFaIK, for optional parameters. Lacking a means to determine the number of arguments passed, limits the capability of the CLLE executable to support optional parameters. I am not aware of a CEE API to retrieve the argument count; i.e. to give an equivalent to the %PARMS BIF of the RPG, as alluded by Ken. The CEETSTA is not helpful, because without first knowing how many arguments were actually passed, one can not know which parameters can be safely tested; no more accurate than testing for *NULL, I infer. I am not convinced that even the ability to address the parameter list is of help, although the number of arguments should be included in the data [at least if the caller provides OpDesc Operational Descriptor data for each argument, which I believe CL CALL and CALLPRC do, but probably not invocations by *CMD although those will call with every argument coded as a PARM()]; I am unable to test because v5r3 has no *PTR support in the CL:

For some reference:

The idea is existing programs calling this changed program
will not pass the new parameter and will not need changing.

What might be best [and safest] is to create a new additional program. And then eventually [or optionally; though likely best to reduce redundant code] change the old version of that same program to properly invoke the new program with the additional parameter, and\or eventually change all of the old invokers to invoke to the new program. If only or additionally changing all old invokers to refer to the new program, at some point when all changes are presumed to be complete, then the old program can be deleted; any programs depending on that since-deleted program will be very conspicuous. Note that there is INCLUDE support for the CL, which can assist to prevent multiple copies of otherwise identical source:
_Include CL Source_ (INCLUDE)

FWiW: The scenario would be clearer with the sharing of the CRTxxx along with both the PGM PARM() and parameter declarations for the existing invoked program, and sharing of source for the CALL PARM() and\or CALLPRC PARM() and command PARM() used by the invokers [¿presumably all invokers are coded /the same/ presently? be that via specific CALLxxx and\or *CMD object(s), yet any command-line invokers are somewhat unpredictable]. Depending on what those are currently, then of some additional interest might be the definitions of those parameters [beyond just type\len], with regard to the known constraints on the actual passed values; i.e. as self-imposed by the invokers and as imposed [validated] by the invoked program. My point... It's very easy for anyone to offer advice based solely on their interpretations of what is the scenario. But that advice can range from very inappropriate to very worthwhile, if\when put into effect. Yet the advice should tend toward being worthwhile whenever sufficient information is offered, such that the number of [often unstated] assumptions by the commenter should be limited by the specifics\knowns of the scenario.... if only because tests to mimic can be composed and run.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].