RE: optional parm in CLLE -- MIDRANGE-L

I haven't seen a mention of the use of MONMSG to check for these parameters.
I never considered this before, but I just tested this (at least on 7.1 here), and this method gets an Ugh, but If you really HAD to...

I just did this:
CHGVAR &VALUE3 &PARAMETER3
MONMSG MCH3601 EXEC(DO)
SNDPGMMSG MSG( 'Did not receive 3 parameters') TOPGMQ(*EXT)
ENDDO
ENDPGM

Worked at least.

Alan Cassidy

At Caledonia Financial Services
acassidy@xxxxxxxxxxxxxx
954-693-0000 ext. 3433 - Direct phone
786-380-9236 - Mobile phone

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, January 24, 2014 3:46 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: optional parm in CLLE

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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------