×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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:
callprc ('_NPMPARMLISTADDR') RTNVAL(&PARMLSTADR)
For some reference:
http://archive.midrange.com/rpg400-l/200612/msg00017.html
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:
<
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/include.htm>
_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.
midrange.com
