Ah, thanks - this gives the full explanation - #2 is not done when the
user has no *ALLOBJ on his own. #3 will be the thing that is found, when
a private *EXCLUDE is set on the object for that user. The group's
*ALLOBJ is never checked.
Am I reading that right? It seems to be what the article said.
On 1/2/2013 2:15 PM, Graap, Kenneth wrote:
This information may be relevant to this discussion:
Authority Checking Rules
When a user attempts to perform an operation on an object, the system
verifies that the user has adequate authority for the operation. The
system first checks authority to the library or directory path that
contains the object. If the authority to the library or directory
path is adequate, the system checks authority to the object itself.
In the case of database files, authority checking is done at the time
the file is opened, not when each individual operation to the file is performed.
During the authority-checking process, when any authority is found (even if
it is not adequate for the requested operation) authority checking stops and
access is granted or denied. The adopted authority function is the exception
to this rule.
Adopted authority can override any specific (and inadequate) authority
The system verifies a user's authority to an object in the following order:
1. Object's authority - fast path
2. User's *ALLOBJ special authority
3. User's specific authority to the object
4. User's authority on the authorization list securing the object
5. Groups' *ALLOBJ special authority
6. Groups' authority to the object
7. Groups' authority on the authorization list securing the object
8. Public authority specified for the object or for the authorization list securing the object
9. Program owner's authority, if adopted authority is used
Note: Authority from one or more of the user's groups may be accumulated to find sufficient authority for the object being accessed.
Reply or Forwarded mail from: Kenneth E Graap