Great point on accountability. Thanks. Suresh
On Thu, Jan 30, 2014 at 7:37 PM, Skip Robinson <jo.skip.robin...@sce.com>wrote: > 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 > jo.skip.robin...@sce.com > > > > From: Elardus Engelbrecht <elardus.engelbre...@sita.co.za> > To: IBM-MAIN@LISTSERV.UA.EDU, > Date: 01/29/2014 10:30 PM > Subject: Accountability (was: multiple TSO Sessions (try this)) > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *SureshNc* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
