Access to the commands isn’t important. For example, ADDAUTLE can only make a difference if the user has authority to change the authorization list (the *AUTL). If authority isn’t granted to change the *AUTL, then the user can run the command as many times and as often as desired, but nothing will happen.

The command isn’t sensitive at all. However, the *AUTLs can be very sensitive. Don’t grant anything more than *USE to the *AUTL, and then ADDAUTLE can’t be used to change it. Why would you grant *CHANGE authority to an *AUTL and then remove access to a command that does the changing?

Similarly, CHGDTA isn’t important; but authority to the files that might be updated with the command is important. If authority to the files allows users to update them, then users can update the files without using CHGDTA. A user might use Excel to update the file — restricting CHGDTA won’t even slow the user down.

If the ability to change an object is important to control, then don’t grant to the authority to change it.

However, if you have some unusual reason to block commands, use the GRTOBJAUT command to grant *EXCLUDE authority for *PUBLIC. This is an example for ADDAUTLE:

GRTOBJAUT OBJ( ADDAUTLE )
          OBJTYPE( *CMD )
          USER( *PUBLIC )
          AUT( *EXCLUDE )

As long as a user isn’t granted explicit authority and can’t use group authority and doesn’t have *ALLOBJ special authority and can’t use adopted authority and can’t use perhaps a couple other methods, that will stop use of ADDAUTLE for your users.

Tom

The see who has access to the green screen (command line) you should display all of your user profiles to an outfile and write a query off of it. The field name is ‘UPLTCP’ (Limited Capability). Users that have this set to ‘NO have access to the green screen (command line) and can attempt to run these sensitive commands you are referring to.

(Limited Capability)

But be aware that limiting capability does not restrict a user from executing a command.

It only limits which commands may by executed through a telnet or similar device session. For example, it doesn’t stop the user from running the same command through a Windows command line with RMTCMD. There are many more ways to run commands than just on a telnet command line.

BTW, my characterization of *CHANGE authority for an *AUTL was probably misleading. The way that I wrote it would easily be confused with the object authority for objects on the list. The authority to ‘change’ an *AUTL is granted through the List Management attribute for that user. On the ADDAUTLE command itself, it would be the *AUTLMGT authority.

Tom

Some of the system commands are considered to be powerful like, {*USRPRF,*AUTHLR, CHGSYSLIBL, CHGSYSVAL, etc}.
1. Now that you have mentioned limiting capability does not restrict a user from executing a command. If so how can we restrict the access to these commands?
2. Is there way to list all users with the access to these commands? Or does it require individually verifying all users?