For the record, my comments on UADS vs. TSO segment have nothing to do with DR. We mirror all DASD from production to recovery site, so everything in production is available in DR. My point about querying a TSO segment is this: when defining a userid with TSO segment, only the first of multiple proclibs or account numbers are stored in the TSO segment itself. Any others are defined in classes TSOPROC or ACCTNUM. While all proclibs and account numbers are displayed via the ACCOUNT LIST command, with TSO segment you have to do multiple queries.
In a previous shop, developers had multiple account numbers in order to track their work by project. Not so much here, but many folks have multiple proclibs for various purposes. Just last week I had to use my 'dataset free' emergency proc in order to logon in the face of an unavailable dataset. I happen to have a TSO segment myself because I need CONSOLE (TSOAUTH), but only a few sysprogs have that requirement. As for 'conversion' to TSO segment, we have a long-established security management tool consisting of programs--many in COBOL!--that allow a handful of security admins to manage hundreds of users and thousands of datasets across a dozen LPARs. This tool is complex and installation-specific in a way that only in-house developed software can be. There's a fenced-off section in the local boot hill reserved for tombstones with inscriptions like this: 'Here lies Tony the Axe. Hired to kill off the security tool. Long live the tool.' . . . 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 Elardus Engelbrecht > Sent: Monday, February 1, 2016 08:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: UADS (was Re: [Bulk] Re: COBOL v5) > > John Eells wrote: > > >I hadn't really thought about (or researched) the display capabilities of > >RACF. > An RFE couldn't hurt if you find them lacking. > > I don't think there is any problem with the display capabilities. Actually, > you > use a RACF command or utility (RACF panels for example) to ask RACF > questions about the fields you're interested in. > > > >Once one's TSO/E administrative routines have been converted to use the > >TSO segment, though, I think another good use of UADS is for recovery, > >including DR. It's the only way to log on when you have no security > >database, at least when RACF is the absent DB in question. I'd want to > >have "some number" of sysprog user IDs to be in UADS for recovery > >purposes. (And an appropriate MPF exit, for RACF!) > > Very true in all aspects. > > > >As SA restore is a serial activity and batch restore is not, minimizing > >recovery > time would seem to call for a small number of UADS-defined IDs to speed > overall restore time if your security DB happens not to share a volume with > some other data sets required to IPL and log on. But what do I know? > > Agreed. Just have a small UADS and test that out by RVARY inactive both your > RACF DBs. Preferably on a sandbox. ;-) > > If you setup your RACF properly, you should have no trouble recovering it. > Just > have your primary and backup RACF DB on separate volsers, make daily > backup with IRRUT200, do your DRP several times in a year, unload your RACF > DB using IRRDBU00, optionally run DBSYNC to generate commands to recreate > your RACF DB, etc. > > I repeat - Just keep your RACF DBs on separate volsers, not on a IPL volser. > > > Skip Robinson wrote: > > >> Ah, UADS. A prime example of archaic mechanism. Defensible technically? > Probably not, although a security administrator who needs to know which > account numbers or which proclibs a user is authorized to use might tell a > different story. > > That is for fallback purposes. These days it is probably very seldom used. > > But you should have documented your UADS+Proclibs and what ids are there > somewhere available during a DRP. > > > >With UADS, a simple list command tells the story. > > Yup, using ACCOUNT utility. There are CBT utilities available to help you with > that. > > > >With TSOE segment, it's a data mining operation. > > No. It is easy, just a LISTUSER <id> TSO. If you don't have access, ask for > access > to class FIELD, profile USER.TSO.* or ask for output from a fresh IRRDBU00 + > ICETOOL job. > > > >This difference alone has inhibited conversion in some shops. > > How so? What conversion? Can you give examples? > > > I may have missed something, but I did not fully followed the original COBOL > v5 thread and all these spawned threads. > > 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
