In the OP there were two profiles mentioned: PROD.** to which USR1 had ALTER PROD.BACKUP to which USR1 does not yet have ALTER access.
The simple way to think about these kinds of problems is that RACF always chooses the most secure situation. Since PROD.BACKUP is a more specific profile for the dataset in question, RACF will use that profile to determine the access. Since USR1 does not have ALTER access under this profile, RACF will not grant it. RACF will NOT grant access because USR1 has access in a "superior" profile. The PROD.** profile is not "superior" to PROD.BACKUP - there's no such relationship. If it worked the opposite way, whenever you created PROD.BACKUP you'd have to review everyone with ALTER access to PROD.** and specifically exclude them from ALTER access to PROD.BACKUP if you didn't want them to update it - in other words you'd have to take a positive action to prevent update. In RACF's method, you have to take a positive action to _allow_ update, otherwise the dataset is protected. RACF's method is therefore more secure. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 Dan McLaughlin wrote: > It has it by being allowed at the superior level, if the original rule was > alter for PROD.*.** > Jacky Bright's OP: >I hav defined generic profile 'PROD.**' and USR1 has ALTER access to > this profile > Later I defined dataset proiled named 'PROD.BACKUP' and provided OPR1 > and OPR2 users READ access. ---------------------------------------------------------------------- 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
