Bruce Black wrote:
I didn't exepress it clearly. DASDVOL is *sometimes* checked for
dataset access. For sure it is checked when deleting datasets.
Do the following test:
1. Try to delete dataset, to which you have access less than ALTER -
you'll get ICH408I.
2. Now give your user ACC(ALTER) to profile protecting the volser.
Delete will be succesful.
Of course case 1. won't give you ICH408I with DASDVOL class, only
DATASET profile will be mentioned.
However in case 2 you can define DASDVOL profile with access NONE and
WARNING mode. Now you'll get ICH408I with the warning.
I stand corrected.
I realized I was doing a IDCAMS DELETE, which checks for authority to
uncatalog the dataset. If it fails, it doesn't even try to scratch it.
I tried a IEHPROGM scratch and it does work as you say, if the user does
not have authority to scratch the dataset, it checks for DASDVOL authority.
But most datasets are cataloged these days, so the ability to scratch a
dataset without authority to the dataset doesn't uncatalog the dataset,
so it is rather useless.
Anyway, this is the opposite of what started this thread. If the user
has ALTER to the dataset, then he can scratch it, regardless of DASDVOL
authority. So DASDVOL is still useless for making a volume read-only.
Bruce,
Again, misunderstanding. NO!
I said (or wanted to say) something different:
At most READ to every DATASET profile covering the datasets on the
volume, *plus* less than ALTER to relevant DASDVOL profile.
In other words, it is not enough to have READ or less to dataset
profiles. Not enough in terms of readonly access.
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
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
