There was a time when I promoted (at least) two userids for system support folks. SLED DASD was far less reliable than today's virtual arrays, It was a dreadfully monotonous occurrence for a DASD failure to hang up a system or an entire shared complex. A TSO user could easily get hung up trying to untangle the mess. A unencumbered second userid could sometimes be used to dig into the rubble for search and rescue. Modern DASD as well as robust RAS improvements have made that scenario increasingly rare. With multi-plex logon now SOP, I no longer maintain multiple userids.
Note also that 'accountability' is in no way compromised by multiplicity as long as each userid has one and only one owner. The state has no problem with a person owning multiple vehicles, while the practice of a vehicle being owned jointly by lots of people would cause havoc in the insurance marketplace. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: Elardus Engelbrecht <[email protected]> To: [email protected], Date: 01/29/2014 10:30 PM Subject: Accountability (was: multiple TSO Sessions (try this)) Sent by: IBM Mainframe Discussion List <[email protected]> Ted MacNEIL wrote: >Unique mapping of userid to person is a valid issue. >You must be accountable for what you do. >Sharing of ids negates that. Indeed. As an unpopular RACF guy, I have a battle just about this. :-) Subsequent audit trails proved my and your point. It is not about 'I must win', but about common sense and logic. >Multiple ids must still be assigned to single people for the same accountability reasons. Indeed. As Ted always said: Auditors recommend, management enforce. >I'm just not sold on multiple ids in a non-ISV environment. But, my first response is "WHY?" not "NO!". Some of my colleagues have more than one TSO id as well some third party product ids managed by RACF. There are many reasons why, but some reasons I can share with you: 1. Work done on that 3th party product, may only be done with that id. Think separation of duties. 2. Testing of Telnet sessions for example using another id or doing long running commands while doing work using another id. 3. For some users I stripped Group Special rights and have them assign FACILITY(IRR.<whatever>) for delegating password management. Give me a good reason and I will play along. Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
