Brief war story. Long before "z/OS", someone accidentally deleted (!!!) the primary RACF data base. It was not enqueued on as previously noted. Data was intact and the system hummed along, but there was no 'SYS1.RACF' in the catalog. Using backup listings, we figured out the exact location on the volume where the data set lived. Then we reallocated it using ABSTR to rebuild the VTOC entry and did a DEF NVSAM to rebuild the catalog entry. Some further cleanup action followed, but basically there was never an outage.
Could not have done that with VSAM. ;-) . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Walt Farrell Sent: Monday, May 22, 2017 7:09 AM To: [email protected] Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin <[email protected]> wrote: >On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote: >> >>>RACF (I'm less sure) is VSAM. >> >>No, it is PSU (PS and Unmovable). Other attributes are mandated by IBM. >> >"Unmovable" would seem to imply uncopyable; the copy would have to go >in a different place. But there must be some provision for backing it >up, and little point in trying to move it to another system with such as FTP. "Unmovable" is recommended to ensure that other tools don't move an active copy of the RACF database to a different location on the DASD volume, since they cannot tell that it's OPEN and in use. There is nothing actually location-sensitive within the database, except that it must be one contiguous allocation. > >Why not VSAM? Performance? Antiquity? It feels as if RACF has a >built-in DB engine. The RACF database format and processing pre-dates VSAM, or was possibly being developed concurrently. (I've forgotten the exact details.) I did look, many years ago, at what would be required to switch RACF to using VSAM, and it would have required significant redesign, redevelopment, and testing. Also, given the way that RACF initializes, and the fact that the database is accessed directly and concurrently from all address spaces on the system as well as from multiple systems, it was not clear that using VSAM would even be feasible. Yes, RACF has a kind of non-relational DB engine built in. We also considered at one point whether it might be possible to switch to using DB2, but we didn't want to limit RACF's usage to those customers willing to license DB2, too. (And, of course, if we did switch there's the redesign, redevelop, test expense to consider, too.) There were also migration and compatibility considerations, of course. If you have several systems sharing one RACF database it would not be appropriate to require all of them to have to upgrade to new RACF (or z/OS) releases simultaneously so they could all switch to VSAM- or DB2-based databases. And allowing a mixture of old-style databases and new-style databases would be extremely complex. We did that once when we changed the RACF DB from using a 1K blocksize to using a 4K blocksize, and it was complex. But switching to an entirely different mechanism like VSAM or DB2 would be even more of an undertaking. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
