The time-honored technique is to pass the number of parameters in the first parameter.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Briggs, Trevor (TBriggs2)
Sent: Monday, January 27, 2014 7:29 AM
Subject: RE: optional parm in CLLE
I have used a similar function in the past (using the "optional"
parameter name in the CHGVAR FROM rather than the TO variable), and I
was unaware of the fact that false positives could occur. I suppose if
there were a limited number of acceptable values for the parameter that
you could check against then the chances of "accidentally" finding ones
of these in a "phantom" parameter would be negligible. But in cases
where the parameter values could be a large number of values it seems
from this thread that IBM gives us NO 100% reliable way of determining
the number of parameters passed to a CL program. Is that so?
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Friday, January 24, 2014 7:31 PM
Subject: Re: optional parm in CLLE
On 1/24/2014 8:29 AM, Alan Cassidy wrote:
I just did this:
MONMSG MCH3601 EXEC(DO)
SNDPGMMSG MSG( 'Did not receive 3 parameters') TOPGMQ(*EXT)
Worked at least.
I just want to make sure that it's clear that this technique should
absolutely never be used.
It often seems to work in testing, but it's almost guaranteed to give a
false positive at some point, indicating that a parameter was passed
when it wasn't.
What's especially bad about this technique is that if your program
modifies a parameter that was not actually passed, you can cause bizarre
and unpredictable errors that might show up long after your program has