The time-honored technique is to pass the number of parameters in the first parameter.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Briggs, Trevor (TBriggs2)
Sent: Monday, January 27, 2014 7:29 AM
To: midrange-l@xxxxxxxxxxxx
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?


Trevor Briggs
Lincare, Inc.
(727) 431-1246
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Friday, January 24, 2014 7:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: optional parm in CLLE

On 1/24/2014 8:29 AM, Alan Cassidy wrote:

I just did this:
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


Related ...

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page