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
