On 01/30/2016 01:05 PM, Ed Gould wrote: > On Jan 30, 2016, at 11:11 AM, 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. > > Skip: > > I disagree with your "defensibility technically" statement. > we have at least two groups that do the RACF definitions and while > they are so so technically they cannot seem to do the job correctly > and add to the measure adding alias's in the mastercats cannot be > trusted to do so reliably. I don't know how many times I have > rewritten(multiple times) rexx and clist and JCL they simply screw it > up sometimes. > I had to rein in the catastrophe that they managed to do. > The UADS is simply far more easy to do than the RACF definition(s). > They regularly screw that up as well and I have had to redo both. Is > this a technical issue (a little) is it a personnel issue yes > , but without firing people there is no easy solution. I get a > JR sysprog to do any TSO adds (or changes) to UADS and it gets done > correctly all the time (although admittedly the change can be tricky > at times) > > Ed > > ... > We migrated to MVS (and RACF) from DOS/VSE around 1985 and had the advantage of not having to deal with pre-existing MVS application data set names or pre-existing security conventions (since DOS/VSE essentially had no security at the time). I spent several months coming up with ways based on our existing application and production batch and end-user group relationships to implement standards for MVS data set names, TSO PROC and account standards, and a RACF hierarchical group structure that allowed all the "usual" permissions to be granted via generic profiles to groups and connects to RACF groups.
It quickly became apparent (before MVS went into production) that the only way to prevent inconsistencies in user and application area setup was to automate the daily creation/deletion of users and occasional creation/deletion of application areas, so that all the standard RACF group relationships, connects, catalog aliases, etc would be setup at the same time to essentially eliminate the possibility of omitting a step or accidentally violating installation conventions. This was initially done with CLISTs, later converted to REXX EXECs when that option became available. Only the Technical Support RACF Administrators supporting the Corporate RACF Security Administrators had a need for detailed knowledge of the underlying RACF structures and installation conventions. When UADS could be replaced by RACF TSO segments, it was only a matter of reworking the EXECs used by the day-to-day Corporate RACF administrators for routine user maintenance and a mass conversion to TSO Segments, not a matter of retraining, because those individuals had never used the TSO ACCOUNT command directly. When TSO account number and PROC authorizations to users are consistently done by RACF group connects, then RACF can also easily list those authorized to a specific account or logon PROC by listing connects to a related RACF group, which eliminates one of the mentioned issues with switching from UADS to RACF TSO Segments. Frankly I always found the syntax of the UADS ACCOUNT command to be very ugly by comparison to RACF command syntax and was glad to eliminate the need for its use. My perspective is colored by working in an environment where any change to RACF group structures, or allowed high-level DS qualifiers, or access to non-application data sets were strictly under Technical Services control, either directly or indirectly via EXECs written by Tech Services for use by Corporate RACF Administrators, and the detailed procedures to be followed by Corporate RACF Administrators was also written by Technical Services RACF support. Based on our experience, I find it difficult to conceive of how one could set up installation conventions for security, TSO or otherwise, and expect to consistently follow those conventions without the aid of installation-developed tools like our EXECs -- there are just too many separate interrelated actions involved with common tasks like user creation to expect a person to do them repeatedly and reliably by hand. -- 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
