Re: CLLE optional parameters?

Simon

My confusion about mentioning the CALL command is, this is in the context of creating commands, not using the CALL command at all. There is no explicit CALL when executing a command - the PARM command here is different from the PARM parameter of a CALL or PGM command. Right? No big deal, just thought something slipped in.

I like having these other tests that don't require the monkeying around with MONMSG and RCVMSG RMV(*YES) or equivalent.

Vern

Simon Coulter wrote:

On 15/04/2009, at 12:47 AM, Vern Hamberg wrote:

Now if anyone knows another way to avoid having to pass all parameters
to a RTV* command - as IBM's work - let me know - other than monitoring
for MCH3601.

In CL you are stuck with the MONMSG MCH3601 method but in CLLE you can use the CEETSTA to check for existence and skip if not present.

The documentation for this parameter of the PARM statement
for commands says -

"A CL variable name must be specified (on the CALL command) to receive
the value."

Not sure why it says "...the CALL command..."

Because the CALL command builds a parameter list from those specified. You can't specify an omitted or NULL value--help text expressly states that the *N placeholder won't work (although the help is wrong about not being able to pass a NULL value to a program**)--on the CALL command.

but not to worry - it is
assuming you have to pass all of the RTNVAL parameters, if specified.
But the IBM commands don't behave that way, and checking MCH3601 takes
care of it - until I find a better way.

On 540 with pointer support you can probably use the _NPMPARMLISTADDR built-in to check the number of parameters passed but since the Command Analyser will pass a *NULL pointer for unspecified return values the count will indicate all parameters were passed so you'll still have to check if you actually got a usable parameter.

David might be interested in that method for his optional parameter. In his situation he will not have anything passed so the count should reflect the actual number of parameters. CL gets operational descriptors passed so any of these methods should work reliably.

**The help text was accurate when it was written (S/38 days) because the available user languages did not support pointers so no NULL values could be passed.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------