MONMSG MCH3601 at the first touch of each RTNVAL parameter.

----- Original Message -----
The fix is so easy - but what is that fix??

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Friday, April 12, 2013 5:03 PM
To: Midrange Systems Technical Discussion
Subject: Re: CL command creation

Mark

I think this is a little turned around. Or at least I'm a little confused by your description in the last paragraph.

If you don't provide a program parameter for a return value PARM, there's nothing that will trigger the MCH3601. Of course, the CPP would fail for other reasons, I imagine - and would be pretty useless, anyhow.

I think the issue is when the caller does not provide that parameter.

I've seen commands with upwards of 40 return values, and all of them had to be specified - sheesh! The fix is so easy!

Regards and the end of the day to you!
Vern

----- Original Message -----
John:

The CPD0172 should never occur when a command invokes the command
processing program (CPP), unless the CPP does not define the same number
of parameters as the command definition defines. =-O

The command processor always passes exactly the number of parameters
defined in the command definition to the CPP, regardless of whether or
not any of them are defined as "optional" parameters. It was done this
way so that you could write your CPP in CLP, where the CRTCLPGM OPM CL
compiler does not allow for a variable number of parameters to be passed
to the CL program.

When dealing with a parameter that returns a value, RTNVAL(*YES), you
must deal with the possible MCH3601, if no variable is provided for that
return value, in your CPP, as Carel mentioned.

Hope that helps,

Mark S. Waterbury

On 4/12/2013 5:31 PM, John Yeung wrote:
On Fri, Apr 12, 2013 at 5:17 PM, Carel <coteijgeler@xxxxxxxxx> wrote:
IIRC the old technique in CLP was to globally monitor for MCH3601
without doing nothing or put that MONMSG on each CMD variable in the CLP

Not passing a PARM is not passing a pointer, which MCH3601 tells you.
I believe the program has to be of type CLLE, not CLP. At least up to
V5R4, a plain CLP will not even run with an unpassed parameter. (The
job attempting to call the CLP gets CPD0172: "Parameters passed on
CALL do not match those required.")

John


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.