Hi Sean, You forgot to include "GENERIC" on the ADDSD Command (unless you REALLY want to create a Discrete Dataset Profile.)
RACF's behaviour is correct. You can create a GROUP which has the appropriate access to 'ABC.DEF'. You can CONNECT users to this GROUP (so that these users have access to 'ABC.DEF') Regards, David On 2019-10-30 11:51, Sean Gleann wrote: > I started this thread back in September, and got a lot of useful advice > from responders for which a heartfelt 'Thank You'. > > Now I'm at the point of putting that advice in to action and I'm afraid > I've hit an apparent problem (in my eyes, at least). > I'm also using a RedBook "ABCs of z/OS System Programming Volume 6" > (SG24-6986), page 51ff as a source of guidance. > Per that book, the first thing I need to do to protect a specific file is > to use an 'ADDSD' command to define the file name. > If I try to ADDSD 'ABC.DEF' UACC(NONE), I get "ICH09006I USER OR GROUP > ABC NOT DEFINED TO RACF" > Well - that's right. High-level qualifier 'ABC' is not a user-id, nor is it > group name and it is not intended to be, either. > 'ABC' is used to identify files that are used by multiple groups of users - > there is no single 'owner' as such. > > By implication, I've got to create a user (or group) named ABC in order to > proceed. > Extending that implication, I've got to create users (or groups) for every > single HLQ currently in use on my system(s). > > That can't be right, surely. I've got to be missing something somewhere. > Can anyone shine a light on this, please? > Regards > Sean > > On Mon, 7 Oct 2019 at 13:53, Sean Gleann <sean.gle...@gmail.com> wrote: > >> "...The fact that SMS data sets must be catalogued..." was the missing bit >> for me. >> I've never before worked in a position where I was allowed to use non-SMS >> datasets, so the possibilities involved with such things was something I'd >> never even begun to consider. >> >> When this particular situation was 'discovered', my main worry was that >> all my SYS1... type datasets were equally at risk. I've since shown that >> not to be the case, but it's not due to RACF or SMS rules. All those >> datasets are on disks that are attached from VM in R/O mode. To alter >> anything in them requires the 'owning' VM to be started up, and - at this >> site - *that* requires management sanction. >> >> Thank you for all your help in this. As you've highlighted, I'm going to >> have to switch PROTECTALL on and then handle all the screams of dismay from >> developers. >> >> >> Regards >> >> Sean >> >> On Thu, 3 Oct 2019 at 15:30, retired mainframer <retired-mainfra...@q.com> >> wrote: >> >>> To recap: >>> PROTECTALL is off. >>> No RACF profile protects the DSN in question. >>> The MCAT is protected by a profile. >>> An admin creates the non-SMS dataset TEST which gets catalogued in the >>> MCAT. >>> A non-admin deletes the dataset which results in an orphan catalog >>> entry. >>> You are surprised. >>> >>> Why? >>> The data set is completely unprotected. The fact that it is on a >>> non-SMS volume or catalogued in the MCAT makes very little difference. >>> Under these conditions, ANY USER IS AUTHORIZED to edit the contents or >>> delete the dataset. There are probably other actions available. The user >>> may even be able to rename the data set to XTEST which would result in it >>> being no longer catalogued in addition to the orphan entry. The user may >>> be able to rename the data set to DSN that gets catalogued in a UCAT which >>> would result in two catalog entries (a correct UCAT and an orphan MCAT). >>> If the admin had specified a STORCLAS when creating the dataset, it >>> would have been placed on an SMS volume. I don't think anything would have >>> changed (except possibly for the rename). >>> If the admin had used a DSN that meets your ACS qualifications but is >>> still not protected by a profile, the previous paragraph would still apply >>> If the admin had used a DSN that is catalogued in a UCAT but is still >>> not protected by a profile, the data set is still completely unprotected >>> but now you will not be left with an orphan catalog entry. >>> If the admin had specified KEEP instead of CATLG, the dataset would >>> still be unprotected but there would not be an MCAT entry to be orphaned. >>> >>> The catalog structure has nothing to do with data set protection. The >>> fact that SMS data sets must be catalogued would prevent your non-admin >>> from creating TEST in the first place but once it is created the barn door >>> is wide open. >>> >>> The fact that PROTECTALL is off and you have many unprotected data sets >>> is a major security hole. Any unprotected data set is just a problem >>> waiting to bite you. >>> >>>> -----Original Message----- >>>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >>>> Behalf Of Sean Gleann >>>> Sent: Thursday, October 03, 2019 5:17 AM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: Tracing RACF? >>>> >>>> You mean, did I actually specify a volser on the "Data Set List Utility" >>>> panel? >>>> In all cases up to now, the answer is 'No'. >>>> But your query prompted a couple of experiments, all to no avail I'm >>> afraid. >>>> If I do specify the volser as well as the dsn, the only difference is >>> that >>>> the 'delete confirmation' panel that opens up has an extra option in it. >>>> Instead of just "Set data set delete confirmation off", I also get >>>> "Uncatalog data set upon deletion" - which is already selected with a >>> '/'. >>>> If I allow the deletion to go ahead with that selection, the only >>>> difference is that I don't get to see a RACF violation on the MCAT. The >>>> file still gets removed from the volume, leaving the orphaned MCAT entry >>>> behind, just as before - but now I don't know about the uncatalog >>> failure. >>>> Regards >>>> Sean >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
