On 02/01/2016 10:27 AM, 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. > > 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!) > > 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? > > 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. With UADS, a simple list command tells the story. >> With TSOE >> segment, it's a data mining operation. This difference alone has >> inhibited >> conversion in some shops. > <snip> > We kept one SysProg RACF Admin userid defined via UADS for years, just in case. Never needed it to resolve RACF failure. We actually did lose the RACF database once (an error on our part) , but by that time we had a one-drive MVS system always available, and it made much more sense to use that to restore/rebuild the RACF database. At that point it became clear that having a one-drive system available for recovery made worrying about having a TSO user defined in UADS redundant.
The structure of RACF is such that there is no efficient way in general to display all users/groups permitted to use a specific TSO ACCT# or TSO logon PROC, because permits are recorded with individual user and group profiles and all user and group profiles would have to be examined to determine the answer. But if installation standards have a group naming convention for a permit-group associated with each specific Acct# and a permit-group associated with each specific TSO Logon Proc, and only those permit-groups are granted permits, and TSO users are only granted permission via connects to those standard groups, then it becomes trivial to list all permitted users to an acct or proc by just examining the connected users for the associated permit-group profile; and to deduce all accts/procs a specific user has by examining the group connects of the user for groups with the special acct/proc permit-group names. So while RACF does not provide direct support for easily displaying this information in real time, it is possible for an installation to use RACF in ways which make it easy to deduce that information by other means. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
