Re: Compiler file access oddity: CRTBNDRPG vs. CRTCLPGM

On 29-Jan-2015 12:30 -0600, David Gibbs wrote:

I've run into a very odd situation.

I have a command that uses our change control system (Implementer,
obviously) to help perform compiles.

The command has the product library set... so, when the command
runs, the product library is between the system portion of the
library list and the user portion.

The commands product library is set to, obviously, our product
library.

Because I am actually developing our product (using our product),
there are files in the product library that i don't have direct
access to (only the product owner profile has access to the files,
most programs adopt the product owner authority).

So here's the problem ... when I run the command to invoke
CRTBNDRPG, the compiler appears to ignore the product library on the
library list and access the files that are further down the library
list.

When I run the same command to invoke CRTCLPGM, the compiler does
*NOT* ignore the product library and gives me errors because I don't
have authority to the files it's finding in the product library.

Could it be that CRTBNDRPG is ignoring any objects that it doesn't
have authority to and CRTCLPGM is not ignoring those objects?

Does this make sense?

Because the CRTCL* commands for the CL compiler are part of the base OS residing in QSYS, those commands do not have a PRDLIB() attribute. However because the CRT*RPG* commands for the RPG compiler are part of an LPP and the compiler code resides in a library other than QSYS, those command have a PRDLIB() attribute; e.g. PRDLIB(QDEVTOOLS).

The effect is normal because the Product Library (PRDLIB) of the command being invoked replaces the PRD library [rather than adding another library to the PRD portion of the User Library List]. Knowing that is the key to [figuring out how to go about] coding the resolution.