I wholeheartedly agree with Joel's recommendation for having a backup copy of the RACF database readily available for recovery. I just want to add that it is crucial to use RACF utilities to create the backup and to allocate it with the proper characteristics. The preferred utility to use to create the backup is IRRUT200 which momentarily serializes the database, thereby preventing updates, while it copies the database. IRRUT400 can also be used, but it locks the database which you then have to unlock. The backup should be allocated as one extent, contiguous, and non-movable and, if using IRRUT200, with the exact same size as the source.
As determine by one of our RACF surveys and as found in our numerous RACF reviews, many organizations are not using RACF utilities to back up their databases and risk having a corrupted backup. If you are interested, the survey "RACF Database Backup" can be found on the RACF Center webpage of our website at the following URL. For those unfamiliar with our website, you'll find lots of other useful RACF information there as well. http://www.rshconsulting.com/racfres.htm Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel http://twitter.com/RSH_RACF www.rshconsulting.com ---------------------------------------------------------------------------- Upcoming RSH RACF Training - RACF Audit & Compliance Roadmap - APR 11-15, 2016 - RACF Level I Administration - MAY 17-20, 2016 - RACF Level II Administration -MAY 3-5, 2016 - RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016 - Securing z/OS UNIX - WebEx - JUL 25-29, 2016 ---------------------------------------------------------------------------- -----Original Message----- Date: Sun, 14 Feb 2016 15:53:07 -0600 From: "Joel C. Ewing" <jcew...@acm.org> Subject: Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) But the only way to "fix"an unusable RACF database is to have a fairly recent backup copy of the RACF data base that can be restored. I would contend that is easier, and possibly safer, to do this from a fully functional "one-drive" tech support emergency z/OS system accessing production drives than to do it from a UADS-defined TSO user on a crippled production system without RACF or with a known-damaged database -- and there are so many other unanticipated problems such an emergency system can address that it doesn't make sense to be without one. If the only problem that can be solved by having a UADS-defined TSO user can be better addressed by a "must have" alternative, why persist with any UADS-defined TSO users once the alternative is available? Joel C. Ewing On 02/14/2016 01:04 PM, Skip Robinson wrote: > This problem occurs so seldom that I never thought of automating a response. > As of R12 or so, we now have AUTORxx, which can reply to WTORs very early in > the IPL. Not sure who here would have to approve such a change. The chances > of mischief being perpetrated are minimal, but it does open a very small > window for a clever miscreant. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > jo.skip.robin...@att.net > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Ed Jaffe >> Sent: Sunday, February 14, 2016 07:37 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5) >> >> On 2/13/2016 8:04 PM, Skip Robinson wrote: >>> This opinion is based on (thankfully) limited experience. If you are >>> forced to IPL without a usable RACF data base, you are totally >>> scr*wed. During IPL, operator will be prompted to allow even READ >>> access to *every* data set opened by *every* task except for a tiny >>> handful like JES that bypass integrity. By the time you get to the >>> point of actually logging on to TSO, operator's fingers will be >>> bleeding profusely. If at any time during this process, you are >>> god-forbid required to start over, yet more finger tips will have to >>> sacrificed. >> We solved this with an MPF exit that would always reply 'Y' to each of those >> prompts (except for the first few IIRC). >> >> -- >> Edward E Jaffe >> Phoenix Software International, Inc >> 831 Parkview Drive North >> El Segundo, CA 90245 >> http://www.phoenixsoftware.com/ -- 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