Martin Kline wrote:
Your confusion is due to an unfortunate use of the word "resource" in
two wholly-different contexts.
On the contrary, I am not confused at all. Clearly, users should be
prevented from deleting datasets they shouldn't delete. However, who's to
say Joe user shouldn't delete dataset JOE.yyy.zzz? Is it a requirement of
the job?
Likewise, who's to say Joe user shouldn't allocate 100Gb of virtual memory
to load a table? Is it a requirement of the job?
Should the approach be to protect all datasets, and require every user to
get authorization before accessing them? Won't this interfere with their
ability to do their jobs?
What about memory? Shouldn't excessive memory requests be restricted, and
require authorization as well? Would that interfere with the ability of
users to do their jobs? Is it any worse than setting up dataset protection?
You're getting waaay off track here...
The OP (Steve Grimes) wishes to provide some of his users with access to
Zeke. Apparently, that is how they do their jobs. The fear from the
system programmers at his shop is that, because RACF has been
emasculated, these users would get too much authority if logged on to
TSO. Specifically, he was told, "... there is no way for us to limit
what the user can do if we let them into TSO." So he began contemplating
ways to limit their access and posted to the list.
What Steve was told is untrue. Establishing ACCESS=RESTRICTED for a user
(or group of users) ensures they cannot break things no matter how lax
the existing rules are. These users will require specific authorization
to any RACF-protected "resources".
ACCESS=RESTRICTED does not stop JOE from deleting JOE.yyy.zzz. Not sure
where you got that impression. This feature in no way changes the
behavior of generic vs discrete profile profile processing. Rather, it
simply treats UACC as NONE in all cases.
I've set this up here for an outside consultant and I recommend it highly!
--
.-----------------------------------------------------------------.
| Edward E. Jaffe | |
| Mgr, Research & Development | [EMAIL PROTECTED] |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
'-----------------------------------------------------------------'
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
