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
