I think we're on the same page here, though maybe front and back. Security administration is complicated, but it should be doable by 'admin types'. You should not need a sysprog for day-to-day security. One of my biggest objections to typical non-z/OS architecture is the requirement for fully trained and authorized 'sysadmins' to manage security definitions that are not just mundane--a business problem of squandering resources--but totally outside the appropriate limits of system build and support. Security admins should report up to a manager at the corporate level outside of IT. The way to accomplish this goal is not to certify security admins in the intricacies of RACF (with or without UADS), but to provide tools that simplify the process of managing user and (particularly) data entities. It should be the admin's job to verify that a certain user is allowed to access a particular system with permission to some resources but not to others. The tools should enable the admin to implement that access without knowing RACF or UADS keywords. If she knows that much, then make her a sysprog and hire another admin.
If a shop has properly implemented this sort of management structure, then security tools are absolutely crucial to the wellbeing of security administration. This makes migrating to a new security product or variation--e.g. TSOE segment--problematic because the tools have to completely rewritten before the first production user can be migrated. This is not easy or cheap for older, larger shops. Nor can it be done on the sly without hoopla. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Ed Gould > Sent: Saturday, January 30, 2016 11:06 AM > To: [email protected] > Subject: [Bulk] Re: [Bulk] Re: COBOL v5 > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
