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 */
midrange.com
