Re: optional parm in CLLE

Reminds me of a joke" How many programmers does it take to replace a
light bulb? None. It works for me.

The correct answer is "None. It's a hardware problem."

ba-dum-ba. I'll be here all afternoon folks.

I need a weekend.




On Fri, Jan 24, 2014 at 1:27 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 24-Jan-2014 05:29 -0800, Alan Cassidy wrote:

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.

Reminds me of a joke" How many programmers does it take to replace a
light bulb? None. It works for me.

In the scenario, what /works/ for you might not hold true for anyone
else. First, because just like discussed in my prior reply, the details
of the means to compile and invoke are unstated, and because...

The documentation is clear enough... and that is, that results are
*unpredictable* with regard to the lack of specification of parameters
for a CLLE; i.e. optional parameters. There are provisions for omitting
parameters using the special value *OMIT. I can compose a CALLPRC
which will not pass a third argument, such that in the above scenario,
the called CLLE will not receive the MCH3601; i.e. the CLLE will
incorrectly have inferred it did "receive 3 parameters" when in fact it
did not.

Besides, wherein that monitor for the MCH3601 is a valid test for an
omitted parameter [such as in a CPP for a *CMD, or an *OMIT argument],
using the CL pointer support instead, you can just ask if the address of
the &PARAMETER3 is *NULL, saving the trouble of a monitor and the
exception.

http://archive.midrange.com/midrange-l/201304/msg00703.html
http://archive.midrange.com/rpg400-l/200806/msg00387.html
<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/passp.htm>
"... When calling an ILE program or procedure, the operating system does
not check the number of parameters that are passed on the call. In
addition, the space where the operating system stores the parameters is
not reinitialized between program or procedure calls. Calling a program
or procedure that expects n parameters with n-1 parameters makes the
system use whatever is in the parameter space to access the nth
parameter. The results of this action are very unpredictable. This also
applies to programs or procedures written in other ILE languages that
call CL programs or procedures or are called by CL programs or
procedures. ..."

--
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.