I've been researching the Use adopted authority program attribute, and
I'm finding it to be a bit convoluted. I know that USEADPAUT(*YES)
allows a program to retain adopted authority from a previous program in
a job's call stack -- if the previous calling program is created with
the User profile attribute as USRPRF(*OWNER).

What's strange to me is that the program create/compile commands have
USRPRF as an explicit parameter, but that USEADPAUT is controlled in a
more roundabout way. A program can be changed via CHGPGM to USEADPAUT
*YES or *NO, but it's not on compile commands. For programs to be
created with USEADPAUT set to *NO the system value QUSEADPAUT has to be
set a certain way:

A diagnostic message is signaled to indicate that the program is created
with USEADPAUT(*NO) if all of the following are true:

* An authorization list is specified for the QUSEADPAUT system
* The user does not have authority to the authorization list
mentioned above.
* There are no other errors when the program or service program is

If the user has authority to the authorization list, the program or
service program is created with USEADPAUT(*YES).

QUSEADPAUT is shipped with a value of *NONE, so all programs compile
with USEADPAUT set to *YES by default. This is a problem for us because
our third party software's menu system adopts authority for the menu and
product owner. The menu system controls licensing of the package, so we
don't have access to the code, and we're afraid to change it (and we're
not under support). I'm preparing to change the QUSEADPAUT value to
*NONE to a authorization list that forces production programs to compile
as USEADPAUT *NO. We'll also end up performing a mass change to *NO on
all the non-menu production programs.

Because it seems kind of difficult to force this value for the default,
and because our DEV, TEST, and PROD code are all on the same server
partition I'm a bit worried. Has anyone else had to mess with this
system value or change it on the bulk of their programs? We've made it
through tons of audits and SOX stuff, but this parameter never comes up
with the auditors. No one's thought to put it on their checklist, I


James P. Damato
Sr. Manager - System Administration
Dollar General Corporation

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].