Re: Weird CPF2116 error in a CL program

[CRPence <CRPbottle@xxxxxxxxx>]

  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?