This case demonstrates the advantage of using authorization lists.
The ARWKR01 file in library CUSTLIB is secured by the ARLST1
authorization list. Figure 1 and Figure 2 show
the authorities:
User AMESJ, who is not a member of a group profile, needs *CHANGE
authority to the ARWRK01 file. These are the authority-checking steps:
Flowchart 1, step 1.
Flowchart 2, steps 1 and 2. The ARWRK01 file is secured by an authorization
list.
Flowchart 1, step 2.
Flowchart 3, steps 1 and 2. Object to check = CUSTLIB/ARWRK01 *FILE.
Flowchart 3, step 3.
Flowchart 4, step 1. AMESJ does not own the ARWRK01 file. Return to Flowchart
2 with no authority found.
Flowchart 3, step 4.
Flowchart 5, steps 1 and 3. Public authority is not sufficient. Return
to Flowchart 3 with no authority found.
Flowchart 3, steps 5, 7, and 9. Object to check = ARLST1 *AUTL.
Flowchart 3, step 3.
Flowchart 4, step 1. AMESJ does not own the ARLST1 authorization list.
Return to Flowchart 3 with no authority found.
Flowchart 3, steps 4 and 5.
Flowchart 3, step 6. Authorized. AMESJ has
*CHANGE authority to the ARLST1 authorization list.
Analysis:
This example demonstrates
that authorization lists can make authorities easy to manage and provide good
performance. This is particularly true if objects secured by the authorization
list do not have any private authorities.
If AMESJ were a member of
a group profile, it will add additional steps to this example, but it will
not add an additional search of private authorities, as long as no private
authorities are defined for the ARWRK01 file. Performance problems are most
likely to occur when private authorities, authorization lists, and group profiles
are combined, as in Case 11: Combining authorization methods.