Once again, in the sole interests of exposition and full disclosure, my ripostes are interspersed.
. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <[email protected]> wrote on 06/03/2005 17:37:44: > On Fri, Jun 03, 2005 at 03:00:01PM -0700, Skip Robinson (JO.Skip. > [EMAIL PROTECTED]) wrote: > > None of this is beyond the realm of comprehension or manipulation, but you > > have to build a business case for converting. > > Here's my business case: > (1) Don't have to keep two things in sync (UADS, RACF). I'm a passionate advocate of not having to sync up data in multiple places: the clock ticks away toward the moment when time and space skew out of whack. But it appears that *nothing* in UADS and RACF require synchronizing once the userids are defined. Other than the userid itself, there seem to be *no* intersecting attributes. > (2) Easier to hand it all off to the security department. Here's the major rub. Our security department has spent the past few decades managing UADS. Not managing it directly, mind you, but with tools and utilities that we spawned over time in the face of the gawd awful complexity of the various commands required. It's *change* that would be difficult to 'hand off'. > (3) Ever need to update a UADS entry for a logged on user who doesn't > want to log off right now? Coffee breaks. Bathroom breaks. Catching up on email. How else would we ever get around to the important stuff? > (4) Ever need to compress and/or expand UADS? Unless you like to > live on the edge (doesn't usually bother me, YMMV), this requires > stand-alone time. Hmmm. Sounds like a task you assign to the tush-pain who's begging for a peg or two notch-down in the group pecking order. Maybe it's senioritis (and I don't mean the lovable springtime hormonal kind), but I don't remember ever having to do that. > (5) Is UADS really shareable? Not sure if this question is technical, philosophical, or a suggestion for a twisted-geek Oprah show. I think the answer is Yes on technical grounds, based on our experience sharing UADS within a sysplex. Other nuances are left as an exercise for the reader. > (6) Since in a security-system-down scenario, having workable emergency > ids in UADS is critical, I prefer to limit exposure to having UADS > messed up by eliminating updates to it. I suppose that even-once-in-my-entire-career having suffered this scenario, I might get worked up. But outside of B-movie horror shows, it seems more like twisted fantasy than a line item in a Disaster Recovery plan. > (7) Aren't there TSO features which can't be utilized at all by > UADS-defined users? Yes, but the only one that has motivated us to create some RACF TSO segments is the TSOE OPERATOR command, which is *extraordinarily* useful for (mostly batch) Rexx execs that perform some very nifty automation. We have done that for a few sysprog userids. After counting them all, I still have a finger or two left on the enumerator hand. If IBM really wanted to make life easier on customers, they could simply remove this silly restriction. > > That said, I have to admit that I've worked mostly in small shops where > I was the lead systems programmer *and* the de-facto security officer. > And I generally set up clists & ISPF dialogs for userid maintenance, so > whether it's me or a security department doing it, the nitty gritty > details are well hidden. (Who can remember all the picayune little > steps to do to create a new userid?) > Ditto, ditto, and ditto. But once all those clists and dialogs are established and in use--and don't forget our menagerie of COBOL programs--change is complicated in proportion to the sophistication of the detail-hiding mechanisms. If I could wave a hand and transform UADS into TSO segments, it would have been done long ago. But I'm reluctant to wave a hand only to pull back a bloody stump. A tough sell for workers comp. > > /Leonard ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
