Re: V7R1 CL compile failing for CPYTOIMPF when specifying Targetrelease *PRV

On 27-Dec-2013 12:43 -0800, Steinmetz, Paul wrote:

<<SNIP>> IBM's workaround is to copy the V7R1 version of CPYTOIMPF
to the QSYSV6R1M0, replacing the current version. This has been
completed, CPYTOIMPF target release *PRV compiles are now working.

"The CRTCLPGM is working correctly. The 7.1 PTF to add the ORDERBY
parameter updated the CPYTOIMPF command definition (*CMD) object in
library QSYS. When compiling a CL source member using the CRTCLPGM
command and specifying (or defaulting to) TGTRLS(*CURRENT), the *CMD
in library QSYS is used. However, when running CRTCLPGM with
TGTRLS(*PRV) or TGTRLS(V6R1M0), CRTCLPGM will look first in library
QSYSV6R1M0 to see if this in an IBM command that was shipped with IBM
i 6.1 or an IBM licensed program that runs on IBM 6.1. The idea is to
verify that the customer is not using function that does not exist on
the 6.1 system that the CL is being compiled to run on. The CL
compiler has no way to know if the target 6.1 system has the 6.1 PTF
loaded that added the ORDERBY parameter to CPYTOIMPF. If the program
were allowed to compile and the CL program was taken to a 6.1 system
where the CPYTOIMPF command did not have an ORDERBY parameter, the CL
program would fail at runtime with CPF0001 for the CPYTOIMPF along
with a diagnostic message that the ORDERBY parameter is not valid for
CPYTOIMPF.

There is a work around if the customer knows that the 6.1 system
where the CL program will be restored has the 6.1 PTF applied that
added the ORDERBY parameter.
1) Rename the existing CPYTOIMPF command in QSYSV6R1M0 just in case
it is needed later:
RNMOBJ OBJ(QSYSV6R1M0/CPYTOIMPF) OBJTYPE(*CMD) NEWOBJ(CPYTOIMPF2)
2) Copy the CPYTOIMPF command in library QSYS to library QSYSV6R1M0:
CRTDUPOBJ CPYTOIMPF FROMLIB(QSYS) OBJTYPE(*CMD) TOLIB(QSYSV6R1M0)

Once this is done, any parameters valid for CPYTOIMPF command in 7.1
will be allowed when the command is used in CL source compiled for
TGTRLS(V6R1M0). It will be up to the customer to not use any other
parameters which will not be supported on their 6.1 system. "

The more appropriate *general circumvention* for the noted condition with _any command_ [e.g. msg CPD0043 diagnosed on a Create CL Program (CRTCLPGM) [Create Bound CL Program (CRTBNDCL) or Create CL Module (CRTCLMOD)] to a previous Target Release (TGTRLS), due to a new parameter keyword added to a command via PTF on the prior release and available to the same command on the newer release], is to restore a copy of the PTFed previous-release command into the QSYSprev-release library on the system with the newer-release. With that implementation of the circumvention, there is no concern for accidental usage of "any other parameters which will not be supported on their 6.1 system" because the command *is* the command from their v6r1m0 system. If the newer release had other new parameters or new supported special values on existing parameters, then the chance that a previous-release compile /incorrectly/ allows the compile to succeed, is the problem to avoid; but a problem exposed by having /incorrectly/ used the newer-release command, duplicated into the previous-release library, instead of using the prior-release command, restored into the previous-release library.

AFaIK there is no legitimate reason other than the extra cost, for the IBM development to avoid making an actual PTF available to the *PRV CL compiler library of the newer release(s) for any command that gets PTFed into a prior release. Such a PTF could be omitted from all cumulative PTF packages, found by its symptom, and loaded\applied as corrective for anyone who wants... thus avoiding multiple installations performing the same /circumvention/ for the issue, and instead each installation applying the same PTF as corrective. Delivered as a PTF, also avoids ownership and authority issues which are easily overlooked by users implementing such incompletely-described circumventions; i.e. a CHGOBJOWN and possibly desirable RVKOBJAUT and GRTOBJAUT REFOBJ() actions, are conspicuously absent in the quoted reply. Delivered as a PTF, those offering support could recommend the application of a PTF which allows them simultaneously to avoid offering poorly-described and poorly-thought-out circumventions that must include a description of why their circumvention is possibly problematic if\when implemented.