Re: PRDLIB option of *CMDLIB for CHGCMD and CRTCMD

For CMDLIB/MYCMD *CMD I would expect the circumvention to be CHGCMD CMDLIB/MYCMD PRDLIB(MYCMD). For a SFWPKGLIB/THESFWPKG *CMD I would expect that the product library had already been established.

Regardless, ADDLIBLE does not equate with the PRDLIB() function. For either the First Product Library name or Second Product Library name, I would expect a more appropriate workaround would be to invoke the Change Library List (QLICHGLL) API to set the desired product library after first having extracted the current values so that they can be reset to their previous values after having been changed; i.e. mimic what the PRDLIB() actually effects, to avoid breaking nested product invocations. Anyhow...

The intent for the "product library" support is of course to enable the /product/ to identify its own library; primarily for its program objects. Thus if the product was created to enable alternate versions in alternate libraries such that the software package library could be installed as a separate library [using the same command name across those version libraries to activate the product], then one should expect that the install exit processing would effect the request to CHGCMD PRDLIB(&InstallLib). In that manner invoking *LIBL/THESFWPKG invokes the default installed version of the software package for the system, SFWPKGV20/THESFWPKG invokes the alternate installed V2.0 version of the software package; where the installation into SFWPKGV20 library already had effected CHGCMD SFWPKGV20/THESFWPKG PRDLIB(SFWPKGV20).

Regardless if that new special value existed, the software or install should, or the user would be required instead, to change the command to make the product library specific to each *CMD. That is, it would not become the default on CRTCMD, so products would still be getting created and thus delivered with their commands having PRDLIB(*NOCHG). With that and the fact that such a change if so desired is either a one-off kind of thing [or implemented as part of appropriate system change management specific to that system], then it would not seem to me to be all that worthwhile to submit as a change request.

FWiW: When requesting any function with regard to special values, be sure always to be clear, to explicitly explain the intent for its resolution [from special value into its intended literal value]; whether that should occur for run-time versus create\change. For instance, although it is understood that the invocation of the command would effect that the resolved *CMDLIB value would become the product library when the command was invoked, the request that the function "would make whatever library the command was in" would need to clarified. Would that be "... when the command was created\changed" or "... when the command was invoked"? Do not trust that those reviewing your suggestion will infer what is your intent. Define _when_ the special value is to be resolved to its actual value.

Regards, Chuck