×
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 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. ..."
As an Amazon Associate we earn from qualifying purchases.
	
 
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.