Exactly. The CLP was incorrectly coded, for having failed to satisfy
its assumption. The assumption is that the unspecified DATA() parameter
will not impact the results of the request. The assumption fails due to
the dependency in the command, which prevents DATA(*YES) from being used
with anything other than OBJTYPE(*ALL) or OBJTYPE(*FILE). Another
assumption the CLP makes is that the CRTDUPOBJ to use is from *LIBL
versus from *SYSTEM [or QSYS, or ? *NLVLIBL? ].
To verify CHGCMDDFT was used, issue the following requests:
- DSPOBJD *LIBL/CRTDUPOBJ *CMD *FULL OUTPUT(*PRINT)
- DSPOBJD *LIBL/CRTDUPOBJ *CMD *SERVICE OUTPUT(*PRINT)
One of those requests will show CMDDFT [I think that is the value] in
a field of the spooled [or displayed if OUTPUT(*)] output, indicating
the command default(s) were changed on their system.
To circumvent, have them issue CHGCMDDFT *LIBL/CRTDUPOBJ 'DATA(*NO)',
then perform the install again.
If the customized command *LIBL/CRTDUPOBJ had been in library CUSTOM,
which had been placed ahead of QSYS while the CLP was running, then had
the CLP been coded to use *SYSTEM or QSYS instead of defaulting to
*LIBL, then that could have avoided the error... but the issue would
remain if the modified command was the one shipped in QSYS.
James Lampert wrote:
In one of our installer CL programs, we have a customer who is
getting a CPF2116, where we've never seen such a message anywhere
else. The statement where it appears to be occurring is of the form:
CRTDUPOBJ FOO FROMLIB(&BARLIBNAME) OBJTYPE(*DTAARA) TOLIB(QTEMP)
(CPF2116 is "DATA(*YES) specified and *ALL or *FILE not in OBJTYPE
We've never seen anything like this before.
Is it possible that this end user has changed the default on
CRTDUPOBJ to DATA(*YES), and that this would affect an
already-compiled CL program?
Or is there something else that could cause this to happen?