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.
I suspect performance may have also been behind the choice of not ever
using VSAM for the RACF database. VSAM can usually behave pretty well
these days if you can throw enough memory at it for buffers, but in the
old days memory was much less plentiful, and with limited memory your
performance controls with VSAM were at times annoyingly limited -- there
are even scenarios where adding more buffers to VSAM actually degrades
performance because VSAM makes poor choices (like pre-reading many CIs
that will never be needed) from assumptions about future application
behavior that are of necessity based on ignorance of the application's
internal design. Having RACF in total control surely provided
opportunities for intelligent buffer usage and caching of data that
would have been impossible with VSAM in the picture.
Joel C. Ewing
On 05/22/2017 11:01 AM, Jesse 1 Robinson wrote:
> 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
> robin...@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Monday, May 22, 2017 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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) <
> r.han...@rshconsulting.com> 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
>>
>
> Maranatha! <><
> John McKown
>
--
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
