Using:
edtobjaut commandName *CMD
Add the user id and *exclude for rights
Phil
============
Depending on the command restricted it could affect this users ability to run programs that use that command.
Phil
================================================
The note that excluding the user might affect programs that contain the command is important. However, you can indeed assign authority of *EXCLUDE for a user to a *CMD object. ...Unless, of course, the user has a special authority such as *ALLOBJ or *SPLCTL that overrides the exclusion.
It's not the best way to do things by any means -- it should only be intended as a short-term, stop-gap measure. There should be no reason to restrict users from command objects because they shouldn't have rights to any objects that the commands might operate upon.
Tom
Last Wiki Answer Submitted: October 23, 2009 1:38 am by philpl1jb44,070 pts.
All Answer Wiki Contributors: philpl1jb44,070 pts.
If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
Object level authority is a perfectly acceptable way to control access to commands. Do you let programmers on your systems have access to PWRDWNSYS or ENDTCPSVR or ENDHOSTSRV commands? We only give programmers read rights to data in their job sphere but they have *JOBCTL so they can use a number of “dangerous” commands if authorized to them.
You can indeed exclude programmers from PWRDWNSYS, etc., by object authority. It just isn’t very effective against competent developers. It’s temporary for as long as a developer allows it to be effective. Do you also ensure that developers cannot create message files for production apps? If not, then object authority is probably insufficient. A message file can defeat it. Plenty of other possibilities exist. (Many!)
Now, object authority is still a good idea. It is an excellent assistance for mistake avoidance. For developers, though, a combination of policy and trust is where the effort should be placed.
Object level authority is a perfectly acceptable way to control access to commands. Do you let programmers on your systems have access to PWRDWNSYS or ENDTCPSVR or ENDHOSTSRV commands? We only give programmers read rights to data in their job sphere but they have *JOBCTL so they can use a number of “dangerous” commands if authorized to them.
You can indeed exclude programmers from PWRDWNSYS, etc., by object authority. It just isn’t very effective against competent developers. It’s temporary for as long as a developer allows it to be effective. Do you also ensure that developers cannot create message files for production apps? If not, then object authority is probably insufficient. A message file can defeat it. Plenty of other possibilities exist. (Many!)
Now, object authority is still a good idea. It is an excellent assistance for mistake avoidance. For developers, though, a combination of policy and trust is where the effort should be placed.
Tom