CRTAUTL. This command should have PUBLIC *EXCLUDE. You will need to have authority to this command or *allobj authority
Secure the AUTL (CHGOBJOWN to QSECOFR, PUBLIC *EXCLUDE).
Set security on system objects using the desired AUTL.
Add User Accounts to the AUTL (WRKAUTL and Option 2 to change/add/delete). Using Group profiles is my recommendation whenever possible.
I can’t think of any reason why CRTAUTL should be restricted as *PUBLIC *EXCLUDE.
Certainly, *PUBLIC *EXCLUDE is a likely authority to assign as a user entry on an *AUTL. There seems to be no reason ever to grant higher than *PUBLIC *USE on any *AUTL. If higher authority is given to *PUBLIC, then there’s probably no point in using the *AUTL for whatever is being done.
Note that objects that are added to the *AUTL should usually also have *PUBLIC *AUTL assigned in order to direct authority to the *AUTL.
An Authority List (*AUTL) object is a way of assigning authorities for a list of objects to a list of users. The “lists” may contain just a single object or user. Authorities are set against /each/ user for /all/ objects on the list.
One user might have *USE authority while a different user could have *CHANGE. The authority for a user is associated with <b>every</b> object on the list. I.e., you can’t use an *AUTL to give a particular user *USE authority to one object and *CHANGE authority to a different object.
*AUTLs are not the solution for everything. They can provide an administrator with a single interface point for potentially many users and objects. <b>A given object can appear on only one *AUTL.</b>
The list of users will often consist mostly of group profiles. The list of objects will often consist of objects from within a particular application. Users can appear on many *AUTLs.
Often, a single *AUTL might be created for a given application. However, you might create a couple *AUTLs for each application; you might see a reason to put particular users on one *AUTL with *CHANGE authority and *USE on a second *AUTL that lists a few other objects.
By listing group profiles, you effectively are granting members of the groups the authorities that are on the *AUTL. (You can list a particular user on the same list that the user’s group is on. The individual’s entry will be checked first. In this way, you can restrict an individual or elevate an individual while maintaining general group authority.
Listing a few groups lets you control all of the members with minimal effort. When a new user is added to the group, all authorities of the group become effective for that user. There’s no need to to put the user on any of the *AUTLs nor to assign authority object by object.
You can create *AUTLs, create a few profiles, place the profiles on the list with authorities and add objects to the list. As long as the profiles are not in use (no one logs on with them here are no members), the *AUTLs would have no effect. This gives you a way to phase object-level authority into a site that currently isn’t controlled. Whatever authorities are in place for users and objects will still be in place in addition to whatever is assigned on the new *AUTLs.