OK, it's time to speak up on behalf of us mossback Luddites who are still mired in UADS. The reasons for not converting to modern methods may be BUSINESS rather than technology oriented. I don't doubt that any number of mechanisms exist to turn a particular SYS1.UADS into (say) RACF TSO segments. That takes care of Day 1 of the New Era. How about Day 2, Day 200, etc. In other words, how do you manage RACF defined userids?
- Create new - Modify existing - Query - Delete For both Create and Modify, you have several 'attributes' to deal with: - Account numbers - Logon procs - Authority to submit jobs, force a tape mount under TSO, or use the TSO OPER command For Query, you have the problem of displaying all of the above 'attributes' of a userid in a succinct and intelligible manner. As much as we all like to dis UADS, all of this information lives in one spot: the userid entry. In a single LIST command, you can see everything at a glance. With RACF TSO segments, this stuff lives all over the map. Relatively little resides in the segment itself; most is expressed as PERMIT authority to profiles in a menagerie of classes, some of which are mercifully obvious (TSOAUTH TSOPROC), while others force you to memorize (ACCTNUM). None of this is beyond the realm of comprehension or manipulation, but you have to build a business case for converting. 'Modern' doesn't fly very far in persuading *other* people to spend time and money on a project. For example, we currently have an elaborate process to manage userids across multiple platforms. To switch from UADS to RACF segments, that process would have to be modified extensively. (The line between 'elaborate' and 'labyrinthine' is fuzzy.) What's the motivation? Who foots the bill for conversion and training? In a previous shop, each application programmer had lots of account numbers to track time spent on various projects. With UADS, we could see at a glance which projects (account numbers) a userid was authorized for. That simple query in the world of TSO segments is a programming exercise. None of this is a hard case for sticking with UADS. Just an observation that failure to convert is not necessarily silly or Neanderthal. . . . 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/02/2005 18:19:11: > Oh my gosh, I thought we were the last company to convert from UADS to > external security (TSS last year). It's mystifying why anyone would > "outvote" you on this count. We were years and years overdue but we're > certainly not looking back. > > I've done several of these conversions, each with the popular 3 ESMs, all > but the last were easy, transparent, and gradually phased in. > > My sympathies, <snip> ---------------------------------------------------------------------- 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
