Re: Weird CPF2116 error in a CL program

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.

Regards, Chuck

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
list.")

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?