When security is on, the user's Current SQLID must either be the owner of the object, or have specific privileges in the location where the object resides. You can grant privileges to a Primary AuthID, a GroupID or a SecondaryID. An AuthID can be granted an authority, which is a pre-defined set of privileges.
Authorities are suggestive of different levels of responsibility. These responsibilities might or might not suit your needs. See the SQL GRANT command in the SQL Reference for detailed information.
Privileges (and authorities) can be granted at the location level (SYSADM or SYSCTRL), database level (DBADM, DBCTRL or DBMAINT), or by table or column within a table. AuthIDs must be granted privileges within each location they are authorized to use. Privileges in one location do not carry over to another location.
To assign privileges to a given AuthID in two or more locations, set up groups, then assign privileges to each GroupID for one location. The groups that represent the locations for which the user is to be allowed privileges are then assigned to the user's AuthID.
To allow a user to have unlimited privileges throughout the system (all locations), grant super user privileges to the user's Primary AuthID.
Only a super user can create locations, drop locations, edit (update) system tables, and assign super user status to another user. Super user privileges can be assigned in SQLWizard or by editing the USERTYPE column in the user's record in the SYSXDB.SYSACFUSERS table.
Users cannot grant privileges to themselves and cannot revoke privileges from themselves. Likewise, GRANT and REVOKE commands have no effect on users whose AuthIDs (or SecondaryIDs or GroupIDs) are the same as the AuthID portion of an object's name.