So it turns out that the number of folks here with ALTER access to RACF data sets is way smaller than I expected. There are however several userids with UPDATE access; they seem to be mostly in the 'security management' department. Do the standard RACF utilities require UPDATE for housekeeping?
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Tuesday, May 23, 2017 12:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database It should go without saying that ALTER (and even READ) access to the RACF database data set should be restricted to those that really need direct access to the database data set itself. Ordinary users and even RACF administrators should have NONE access to the RACF database data set. I would have been one with ALTER authority. I always preferred, whenever not too difficult, to put in place additional barriers that would require a positive, deliberate act before a single mistake could cause a disastrous consequence, not just assume that those with the authority to create a disaster will never commit an error -- like submitting a defrag for a drive and then realizing by harsh empirical evidence it had a critical active data set like a RACF database that lacked an enqueue. In our case, decades ago, it was an automated system job that ran in the middle of the night that conditionally decided what drives to defrag based on fragmentation index. Ran for months without incident until the night the fragmentation index threshold was reached on the drive with the RACF database, and the console filled up with red RACF I/O failures! Didn't take long to deduce what had happened -- we had to restore the database using our one-drive MVS system, and took steps to reduce odds it could ever happen again. Joel C. Ewing On 05/23/2017 01:36 PM, Burrell, Todd wrote: > Wouldn't a simpler solution to protecting the RACF database simply be to give > pretty much no one ALTER access to it? I know that at most shops only one > or two folks had ALTER or UPDATE to the actual file and that seems like the > best course of action to avoid accidental deletion? > And we backed up the RACF DB 4 times a day as well - just in case. > > Todd Burrell | Sr. Mainframe Systems Administrator > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jesse 1 Robinson > Sent: Tuesday, May 23, 2017 2:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF Database (was: Sample JCL for file transfer using > NJE/TCPIP) > > I have not tried this, but IBM supplies a RACF started task whose purpose is > to issue RACF commands via a console. As supplied, the RACF STC has no DDs, > but I suppose you could add one for the primary and maybe even alternate RACF > data base(s) with DISP=SHR. The hard part of coding such a task has already > been done. Stopping it seems to require FORCE ARM, but you wouldn't stop it > very often anyway. > > --------------------------------------------------------- > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jesse 1 Robinson > Sent: Tuesday, May 23, 2017 11:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: RACF Database (was: Sample JCL for file > transfer using NJE/TCPIP) > > I've been expecting someone with actual experience in this area to jump in. I > don't think you can get away with 'wait forever' logic. Eventually you'll get > S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST > libraries, seems to be very busy doing something, accumulating both CPU time > and EXCP count. Maybe there's something on CBT? > > <snip> > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Monday, May 22, 2017 4:58 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: RACF Database (was: Sample JCL for file > transfer using NJE/TCPIP) > > On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote: > >> RECFM PSU may prevent moving the database, but it doesn't block >> deletion. After realizing this somewhat-essential data set wasn't >> protected by an enqueue, we picked an installation started task that >> was normally running all the time (but which could be shut down if >> need be), and added an unreferenced DD for the RACF database with >> DISP=SHR to reduce the odds of both accidental deletion and movement. >> > Suppose one wanted to craft a started task expressly for that purpose, using > minimum resource. Would it suffice to WAIT on an ECB that you never POSTed? > Would this annoy WLM? Is there a better way? Should it intercept a STOP > command and WTOR with an Abort/Retry/Ignore prompt? What's the OS Classic > analogue of SIGINT? > > -- gil > > > ... -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
