Managing Program Adopt on Multiple Partitions

Issue:

In MDCMS, a command override is set up on a CL program to run as *OWNER of the program instead of the *USER. This parameter is set correctly as the program promoted through all the environments on the DEV LPAR, but it is not set on the target LPARS.

How MDCMS handles *OWNER

In MDCMS, the sending partition checks if QALWOBJRST allows *ALL or *ALWPGMADP.  If it doesn't, then the adopted authority is stripped for the temporary copy of the program before being sent. That’s because MDCMS assumes that the target partition will have the same restriction.

The sending system

The program is sent with *OWNER, meaning that *ALL is the property on the sending system. So, this part is fine.

The install on the target

For security reasons, if the sent program has *OWNER, but it's replacing a program with *USER, then MDCMS automatically strips off the adopted authority to keep a developer from gaining enhanced rights without an auditable command definition.

Resolution:

Create a new attribute, such as CLPOWN, that has a Post-Compile (P) command defined that performs a CHGPGM, instead of setting *OWNER on the compile command itself. Define the attribute and attribute command on each system where adopted-authority programs need to be deployed.  This ensures the authority is properly set, even for programs that didn't have it before, and it is clearly marked in audit reports.

You may also want to require approval for RFPs that are using adopted authority in order to require approval at each level. This would alert project managers that programs with elevated authority are being introduced into the system.