× 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 18 Apr 2013 14:58, Stone, Joel wrote:
Thanks Vern. But I made the length 502 and still see the same error -
CPD0162 "Parameters do not match those in program SET_ENVR in *LIBL".

On v5r4

That is because the problem being diagnosed by CPD0162 has nothing to do with the attributes specified for the declaration of that parameter's variable. The error is very specifically about the CMD and its CPP having a mismatch in the number of PARM; i.e. the number of arguments passed by the compiled CMD object SET_ENVR [presumed to be in *LIBL] does not match the number of parameters declared for the compiled program object SET_ENVR in *LIBL.

Believe it or not, there is not enough information available from the CLP for the Command Analyzer invocation to even inquire of the parameters. After the number of parameters is validated, there is nothing about the actual parameters declared in the CLP that will be validated before the CA attempts to pass control to that CLP as CPP.

Is it possible to NOT use some parms when using a command in CL?
Like RTVMBRD: I only want to code the parms that I want to retrieve
(instead of listing all parms).

Works just fine. Fix the mismatch between the CPP and the CMD, and that specific error CPD0162 will be resolved. Then your command should be able to invoke the CPP with none, all, or any combination of the inout\RNTVAL(*YES) parameters having a CL variable unspecified or specified.

Further comments inline below.

Vernon Hamberg on Thursday, April 18, 2013 4:53 PM wrote:

Your first parameter has to be defined with length 502 - because
the varying puts the length in the first 2 bytes.

If you are current enough, you can set up another 502-long
parameter - I forget, but either *BASED or *DEFINED variables can't
be declared over parameters.

It need not be /another/ parameter, just a redefinition of the storage for the parameter &text [after correction to include all 502 bytes]. The /current enough/ refers to the availability of the STG() parameter on the DCL, since v5r4.

Then do an *INT2 *DEFINED over the first 2 positions and a 500
*CHAR starting at position 3.

Correct. The first parameter can have the first two bytes redefined using STG(*DEFINED) to represent the *INT2 as specified by the PARM VARY(*YES *INT2) in the command-source, and the remaining 500 bytes redefined as STG(*DEFINED) for *CHAR LEN(500).

FWiW I showed such a declaration of the 502-byte *CHAR in the following link, with two means to access that passed length within the CPP using the variable &VCLEN. One means is available only since v5r4, using the STG(*DEFINED). And that is left commented, thus showing the form that is available since many releases prior, although a later comment in the given source explains how the CHGVAR to set &VCLEN is redundant if the STG(*DEFINED) no longer remains within comments.

http://archive.midrange.com/midrange-l/201304/msg00831.html
"...
pgm parm(&vc500inp) /* CPP for PARM500 command */
dcl &vc500inp *char 502 /* this is an *input-only* parameter */
dcl &vclen *int 2 /* stg(*defined) defvar(&vc500inp 1) */
dcl &chlen *char 3
dcl &dclen *dec 3
dcl &text *char 500 /* local copy of the "500-char" field */
chgvar &vclen %bin(&vc500inp 1 2) /* already set if defined stg */
..."

Although that message describes /input-only/ as the basis for the example, I clarify in my next reply of that message thread, that an output capable field can be used, *if* the necessary care is taken to avoid corrupting the storage of the program that is the invoker of the command.
http://archive.midrange.com/midrange-l/201304/msg00901.html

Further comments inline below.

On 4/18/2013 4:47 PM, Stone, Joel wrote:
I am attempting to build a CL command (w/o ILE) with OPTIONAL
parms.

Note: I now have 4 parms on both the command and the CPP, but
still get CPD0162 error "Parameters do not match those in program
SET_ENVR in *LIBL."

As noted in a separate reply, that message begs for the validation of the "Number of Parameters" in the DSPPGM *LIBL/SET_ENVR, as compared to the number of parameters that are shown in the prompted SET_ENVR that is coded in the failing program; i.e. verify that the actual compiled objects that are presumed and verified to be getting invoked, are in fact the desired objects versus being previous iterations of either of the CMD or CPP for which the number of declared parameters might mismatch... just as the error suggests is the situation.
http://archive.midrange.com/midrange-l/201304/msg00977.html

The IBM manual seems to show a simple MIN(0) MAX(1) on the PARM
statement is all that is required.

PARM KWD(DBLIB) TYPE(*CHAR) LEN(10) RTNVAL(*YES) +
MIN(0) MAX(1) PROMPT('database lib: _CMISDB')

It is pretty much that simple. But realize that optional /positional/ parameters must be specified positionally. Or, the parameter must be specified with its Keyword.

However if I use the command and skip some parms, I receive the
error shown below.

set_envr &EMADDR1

According to the source snippet below, that is the first\positional parameter; i.e. Kwd=TEXT. Thus that request is the equivalent of:
*LIBL/SET_ENVR TEXT(&EMADDR1)

No positional parameters are skipped with that invocation, but all parameters following the first are omitted.

The command-source below however, does not explicitly specify MIN(0) MAX(1) like the source snippet from above, so the former is subject to changed defaults. That is unlikely ever to be an issue, but worth noting, because a reviewer of the source can not see the explicit definition, and so they must infer the intention of the unspecified MIN(0) as defaulting to effect an /optional/ parameter. Best to explicitly specify MIN(0) to make that intention conspicuous.

Further comments inline below.

Is there a trick to using OPTIONAL parms in a CMD and CL pgm? Or
must they always match up?

CMD PROMPT('Set Envr Names')
PARM KWD(TEXT) TYPE(*CHAR) VARY(*YES *INT2) +
RTNVAL(*YES) PROMPT('TEXT')
PARM KWD(DBLIB) TYPE(*CHAR) LEN(10) +
RTNVAL(*YES)PROMPT('database lib: _CMISDB')
PARM KWD(DATALIB) TYPE(*CHAR) LEN(10) +
RTNVAL(*YES) PROMPT('work lib: _DATALIB')
PARM KWD(FORCED2T) TYPE(*CHAR) LEN(1) +
RTNVAL(*YES) PROMPT('force DEMO to TEST? +
Y or blank')

SetEnvr CLP pgm:

PGM parm(&text &dblib &datalib &forceD2T)
dcl &text *char len(500)
dcl &dblib *char len(10)
dcl &datalib *char len(10)
dcl &forceD2T *char len(1)
<<SNIP>>



The PARM command-source statements must correspond one-to-one with the CL variable elements on the PARM specification on the PGM CL-program-source statement. While the order of presentation for prompting can be modified with the second element of the PROMPT() parameter for a PARM, the relative position of the declarations in both the CMD-source and the CL-PGM-source remain correlated one-to-one. Thus, in source, they must "always match up".

Once the issue diagnosing the mismatch between parameters for the *CMD and the *PGM object has been resolved, the above command source is very likely to create a *CMD that functions as expected for /optional/ parameter specifications; i.e. such that any of the following should be functional invocations, given no other errors prevent the requests:

set_envr dblib(&c10)
set_envr datalib(&c10)
set_envr forced2t(&c1)
set_envr () &c10 /* datalib positionally 2nd */
set_envr /* all parms passed as *NULL; no work by CPP to be done */


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.