Hi Sean, This may not help with your current issue, but a couple thoughts come to mind. Take a look at protectall. With protectall active, if there's no RACF profile to cover TEST1, the system won't allow it to be created at all. Another thing to check is this, do you have discrete profiles being built for these oddball datasets at creation time? It's called ADSP - AUTOMATIC DATASET PROTECTION and can be defined for a user or group of users. If this is set on, RACF will automatically build these profiles. It doesn't explain why they're being cataloged and removed from the master catalog, though.
A way of checking a specific RACF profile is through the LD command. TSO LD DA(your.master.cat) GEN AU will tell you which generic profile is protecting the MCAT. Is it possible there's also a discrete profile covering the MCAT? Rex -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Sean Gleann Sent: Wednesday, September 25, 2019 6:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Tracing RACF? Following a set of somewhat distressing events here, I discovered - the hard way - that our master catalog was poorly protected, and so I now have to fix it. The situation is that all users of the my system can create, read, write, update, delete files that are cataloged in the MasterCat. The original intention was that each user-id is defined in the MCat as an alias that points to one of several User Catalogs, depending on the user's 'department' within the company. That way, user id 'X1' creates 'X1.TEST', and it gets cataloged in a UCAT. So far, so good. Now I've found that if 'X1' creates file 'TEST1', it gets cataloged in the MCAT. In order to prevent this, I've used existing information to act as a model for permit 'MASTERV.CATALOG' generic id(X1) access(read) and specified that. Now, if user X1 tries to create 'X1.TEST', the result is a RACF authorisation failure. Again, so far, so good Taking the test a bit further though, I've now found that user X1 is allowed to delete file 'TEST1' from the MCat! My conclusion so far is that X1 must be getting the required access rights from another user id/group/etc, but I can't see anything apposite in any examination I do of the RACF rules (I use output from the DBSYNC Rexx procedure for this). So... Can anyone spot my error and suggest a different 'permit' command, please? Alternatively, I looked at the idea of tracing RACF activity on behalf of a specific user with SET TRACE(USERID(X1)) - but I can't see where generated output goes to nor how to interrogate it. I *have* seen mention of using GTF for this purpose, along with IPCS, but my experience with both those tools is so limited that I didn't look much further in those references - skipped on past them, looking for other possibilities but not finding any. Any help gratefully appreciated Sean ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
