Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
Robert S. Hansel (RSH) wrote: >Restricting access to the RACF database is essential, but it isn't enough to >save you if the database is not allocated as unmovable. DFSMSdss' data >management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores >dataset profiles and can perform functions such as compress on any dataset. This is a serious gaping black hole which you can plug with this RACF FACILITY Class profile STGADMIN.ADR.. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
Todd, Restricting access to the RACF database is essential, but it isn't enough to save you if the database is not allocated as unmovable. DFSMSdss' data management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores dataset profiles and can perform functions such as compress on any dataset. 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 -Original Message- Date:Tue, 23 May 2017 18:36:52 + From:"Burrell, Todd" Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
Someone else pointed out that xxxSTOP works for the RACF STC, where xxx is the subsystem identifier specified in IEFSSNxx. In a larger shop, severely limiting access to *any* resource is problematic. If the installation needs 24x7 support, someone has to hold the key, and that someone has to be available to put it in the lock. I agree that too much access is a dangerous thing, but too little can be crippling as well. . . 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 Radoslaw Skorupka Sent: Tuesday, May 23, 2017 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is @STOP). It also can be started again as well. The only cost is "address space unavailable" issue. Of course *properly protected* RACF db cannot be moved or deleted, due to lack of authorities. No one should have even READ to this profile. BTW: VSAM dataset can be read very early - see IODF file. Is it pure VSAM access method? Who cares! R.Skorupka (sent from mobile) BTW -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is @STOP). It also can be started again as well. The only cost is "address space unavailable" issue. Of course *properly protected* RACF db cannot be moved or deleted, due to lack of authorities. No one should have even READ to this profile. BTW: VSAM dataset can be read very early - see IODF file. Is it pure VSAM access method? Who cares! R.Skorupka (sent from mobile) BTW -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
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? -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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? -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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? . . 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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Tue, 23 May 2017 12:27:10 -0400, Tony Harminc (t...@harminc.net) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in ): On 22 May 2017 at 12:57, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: [snip] How does ACF2, based on VSAM, meet this requirement of early availability? The same way it would if ACF2 used BDAM or QSAM or... VSAM is not like VTAM or TCP/IP or z/OS UNIX filesystems. There is no "VSAM address space" to be initialized at some point in the IPL.* VSAM is almost entirely a collection of subroutines, just like the older access methods. * These days there are all sorts of "helper" address spaces around - VLF, LLA, CATALOG, ... and I suppose one of those may need to be active in order to allocate and open a VSAM dataset. But just to do the I/O, I don't think so. The CATALOG address space needs to be active just to open a VSAM cluster. But CATALOG starts very early on in the IPL because it is needed to access all and any of the pagespaces. This is because a pagespace is a VSAM cluster too. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On 22 May 2017 at 12:57, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > ... In any case, a SAF product has to be available extremely early in > IPL, ... > > > How does ACF2, based on VSAM, meet this requirement of early availability? > The same way it would if ACF2 used BDAM or QSAM or... VSAM is not like VTAM or TCP/IP or z/OS UNIX filesystems. There is no "VSAM address space" to be initialized at some point in the IPL.* VSAM is almost entirely a collection of subroutines, just like the older access methods. * These days there are all sorts of "helper" address spaces around - VLF, LLA, CATALOG, ... and I suppose one of those may need to be active in order to allocate and open a VSAM dataset. But just to do the I/O, I don't think so. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Tue, 23 May 2017 07:30:02 -0500, John McKown wrote: >On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson >wrote: > >> Brief war story. Long before "z/OS", someone accidentally deleted (!!!) >> the primary RACF data base. It was not enqueued on as previously noted. >> > >Been there. Done that. Beat up the programmer. > One also gets a similar pleasing effect if you run an IRRUT200 step with DD SYSUT1 pointing to the RACF Database. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
John McKown wrote: >>Long before "z/OS", someone accidentally deleted (!!!) the primary RACF data >>base. >> Could not have done that with VSAM. ;-) >Been there. Done that. Beat up the programmer. I hope he survived your cruel beating, because if he did the same error on the BACKUP RACF DB, then you can beat him up AGAIN... 8-P ;-D .. is it already Friday? Groete / Greetings Elardus Engelbrecht Gazillion years ago a colleague deleted a UCAT while initializing a volser. Great messy drama... He got that our moving office trophy as a prize for the "best error" made in a while... ;-D -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 23 May, 2017 0:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF Database (was: Sample JCL for file transfer using > NJE/TCPIP) > > 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. > I did exactly the same, several decades ago, with the JES2 Checkpoint. Now JES2 allocates (and therefor enqueues) the checkpoint for already some decades. Why can't RACF? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson wrote: > 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. ;-) > Been there. Done that. Beat up the programmer. > . > . > 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 > -- Windows. A funny name for a operating system that doesn't let you see anything. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Mon, 22 May 2017 09:21:48 -0400, Robert S. Hansel (RSH) wrote: > >... then immediately closes them. > Why? Does it also FREE then? Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
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 cha
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Monday, May 22, 2017 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
VSAM, for all its complex capabilities, seems to operate 'simply' at a very basic level of the OS. Think of SMF running very early in IPL. ICF catalogs are VSAM. I'm not sure it was always thus, but it seems now to have little trouble functioning within a minute or two of IPL LOAD. As Walt Farrell said, even if RACF could be rewritten for VSAM, what's the ROI? . . 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 David W Noon Sent: Monday, May 22, 2017 10:11 AM 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 10:57:26 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in <507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>): > On 2017-05-22, at 10:01, Jesse 1 Robinson wrote: >> ... Nonetheless ACF2, based on VSAM, was well established ... >> >> ... In any case, a SAF product has to be available extremely early in IPL, >> ... >> > How does ACF2, based on VSAM, meet this requirement of early availability? ACF2 is supposed to start before JES2/JES3. It is configured as a subsystem and its PARM field includes the name of the job entry subsystem to start (i.e. ACF2 starts JES). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in <507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>): On 2017-05-22, at 10:01, Jesse 1 Robinson wrote: ... Nonetheless ACF2, based on VSAM, was well established ... ... In any case, a SAF product has to be available extremely early in IPL, ... How does ACF2, based on VSAM, meet this requirement of early availability? ACF2 is supposed to start before JES2/JES3. It is configured as a subsystem and its PARM field includes the name of the job entry subsystem to start (i.e. ACF2 starts JES). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On 2017-05-22, at 10:01, Jesse 1 Robinson wrote: > ... Nonetheless ACF2, based on VSAM, was well established ... > > ... In any case, a SAF product has to be available extremely early in IPL, > ... > How does ACF2, based on VSAM, meet this requirement of early availability? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
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 > -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 > -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
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. 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 Upcoming RSH RACF Training - WebEx - RACF Audit & Compliance Roadmap - SEPT 11-15, 2017 - RACF Level I Administration - DEC 5-8, 2017 - RACF Level II Administration - NOV 13-17, 2017 - RACF Level III Admin, Audit, & Compliance - OCT 2-6, 2017 - RACF - Securing z/OS UNIX - OCT 23-27, 2017 -Original Message- Date:Sun, 21 May 2017 14:19:39 -0500 From:Paul Gilmartin Subject: Re: Sample JCL for file transfer using NJE/TCPIP 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. Why not VSAM? Performance? Antiquity? It feels as if RACF has a built-in DB engine. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
