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