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
On Wed, 2 Oct 2019 at 16:10, retired mainframer <retired-mainfra...@q.com> wrote: > When the 3.4 list was requested, was a volser specified on the panel? > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > Behalf Of Sean Gleann > > Sent: Wednesday, October 02, 2019 12:45 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Tracing RACF? > > > > Answering 'retired mainframer's questions (and I'll probably be joining > you > > within the next year) > > > > *What is the status of the SETROPTS PROTECTALL option?* > > A 'SETROPTS LIST' shows: 'PROTECT-ALL OPTION IS NOT IN EFFECT'. I > > tried switching that with 'setropts protectall(warning)', but the sheer > > volume of output that is generated swamps everything else. > > *Is there any data set profile that covers the dataset?* > > No - filenames 'TEST' and 'TEST1' (the ones I have been using for > > this) are not specifically identified anywhere in RACF > > *Is there a global access checking table entry that covers the dataset?* > > Not sure exactly what this means, so I don't know how to check. But > > see previous answer > > *Does the non-admin user have the OPERATIONS attribute?* > > No. > > *Is there a DASDVOL profile that covers the non-SMS volume in question?* > > Yes - the DBSYNC output shows 'redefine dasdvol v* uacc(none)', > > followed by 'permit v* class(dasdvol) reset' (and 'v*' covers the volids > > involved). After that, there are no specific permissions defined > > *And what command is the non-admin user issuing to perform the delete?* > > Just a simple 'D' against the file in an ISPF 3.4 list. > > > > Regards > > Sean > > > > > > > > > > On Tue, 1 Oct 2019 at 16:32, retired mainframer < > retired-mainfra...@q.com> > > wrote: > > > > > And what command is the non-admin user issuing to perform the delete? > > > > > > > -----Original Message----- > > > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > > > Behalf Of retired mainframer > > > > Sent: Tuesday, October 01, 2019 5:37 AM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Re: Tracing RACF? > > > > > > > > What is the status of the SETROPTS PROTECTALL option? > > > > > > > > Is there any data set profile that covers the dataset? > > > > > > > > Is there a global access checking table entry that covers the > dataset? > > > > > > > > Does the non-admin user have the OPERATIONS attribute? > > > > > > > > Is there a DASDVOL profile that covers the non-SMS volume in > question? > > > > > > > > > -----Original Message----- > > > > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > > > > Behalf Of Sean Gleann > > > > > Sent: Tuesday, October 01, 2019 3:10 AM > > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > Subject: Re: Tracing RACF? > > > > > > > > > > Joao: yes, I have tried that, but it really doesn't give the > > > information > > > > > that I want - I can see the monitored user creating and deleting > file, > > > but > > > > > I don't see anything about the RACF profiles that were used. > > > > > > > > > > Having said that, I have managed to move things along. > > > > > The situation I now have is that an 'ordinary' user of my > system(s) - > > > as > > > > > opposed to an 'administrator' user (there are three of us at this > > > site) - > > > > > cannot update the MCAT, so creating files that do not have the > user's > > > id as > > > > > the first qualifier is now impossible. > > > > > 'Administrators', on the other hand, can create and delete files at > > > will. > > > > > All of which is OK as far as I'm concerned. > > > > > > > > > > But (there's always a 'but'...) > > > > > If an admin user creates a file named 'TEST' (for instance), the > file > > > is > > > > > not covered by my SMS rules, and so it gets placed on one of the 5 > > > > > non-SMS-controlled disks that my PARMLIB(VATLSTxx) member > identifies as > > > > > being mounted 'PRIVATE'. I'd rather that didn't happen, but we're > > > talking > > > > > about an 'admin'-type user here, and they're supposed to know what > > > they're > > > > > doing, so things are OK up to this point. > > > > > But now it appears that a non-admin user can delete the file, but > not > > > > > uncatalog it. The file disappears from the selected disk's VTOC, > but > > > the > > > > > MCAT entry remains since the user is not allowed to update the > MCAT. If > > > > > this is allowed to continue I'll end up with an MCAT full of orphan > > > entries. > > > > > > > > > > As I say, I've managed to move things along a bit, so my original > query > > > > > about 'Tracing RACF' is no longer an issue. > > > > > Right now, I'm trying to improve my system's security so that > users can > > > > > create/delete their own files, but cannot do that to anyone else's, > > > nor to > > > > > files that are not covered by SMS. > > > > > > > > > ---------------------------------------------------------------------- > > > > 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 > > ---------------------------------------------------------------------- > 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
