First off, I take back my comment about the chronology of RACF and VSAM. I had no business making that assertion. I got into this biz in the late 70s. At that time there was plenty of VSAM around, although it was viewed by many sysprogs skeptically and unsuitable to hold the family jewels. Nonetheless ACF2, based on VSAM, was well established by then. I can't speak for ASM1. (OK, it's a long way from Friday.)
I don't think it matters much what DSCB attributes are assigned to the RACF database. RACF will open and process it only one way. I've seen PSU recommended to prevent inadvertent relocation. I've also seen DSORG DA or RECFM U recommended to prevent curiosity browsing. RACF is oblivious to these external labels. In any case, a SAF product has to be available extremely early in IPL, so a complex data base would probably not work. Whatever else you say about DSORG DA, it can be managed with very little 'outside' help. . . 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 John McKown Sent: Monday, May 22, 2017 8:03 AM To: [email protected] Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < [email protected]> wrote: > Gil, > > The RACF database is BDAM (Basic Direct Access Method) and has, to my > knowledge, always been so since it was first released in 1976. The > index records are stored in the database with the profile (data) > records, so it is completely self-contained. I know of no other > product using this structure. > > Live databases should be allocated as PSU. Unmovable prevents the > database from being moved while in use. RACF is weird. It opens its > databases at IPL and then immediately closes them. RACF uses direct > disk address I/O to read and update its databases thereafter. If > databases are not allocated as U, a data management utility, seeing > they are not "open", might compress or move the databases, unaware they are > in use - with disastrous results. > I've always hated this about some DSNs. RACF is one. CA-1 use of the TMC & Audit are another. What would be better, IMO, would be either a way to allocate the DSNs to the *MASTER* address space (ASID 1) with DISP=SHR or do a "directed ENQ" to *MASTER* to do a SYSDSN shared ENQ on the RACF database DSNs. I like this latter because it would make it easier to change the RVARY command to update the directed ENQs. > > Live databases should be copied/backed up using the IRRUT200 utility. > This utility freezes update activity to the database before making a > copy. The offline copy can be copied using IEBGENER or the like, or it can be > FTPed. > I haven't tried FTPing a RACF database, but I suspect you would want > to do so using BIN. It is generally best to pre-allocate the disk > dataset to which the database it is to be copied, and it must have > exactly the same UNIT, SPACE, and DCB characteristics as the source > database, including CONTIG. The copy needn't be PSU unless you plan to > RVARY SWITCH to it so that it becomes live. > > Regards, Bob > > Robert S. Hansel *** Celebrating 30 years working with RACF *** > Lead RACF Specialist > RSH Consulting, Inc. > 617-969-8211 > www.linkedin.com/in/roberthansel > http://twitter.com/RSH_RACF > www.rshconsulting.com > -- Advertising is a valuable economic factor because it is the cheapest way of selling goods, particularly if the goods are worthless. -- Sinclair Lewis Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
