Re: Accountability (was: multiple TSO Sessions (try this))
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
Re: Accountability (was: multiple TSO Sessions (try this))
Great point on accountability. Thanks. Suresh On Thu, Jan 30, 2014 at 7:37 PM, Skip Robinson jo.skip.robin...@sce.comwrote: 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
Re: Accountability (was: multiple TSO Sessions (try this))
Every single TSO user in my shop is assigned two ID's. No one has ever asked for a third, but many people only use one of their assigned ID's. We have never had an auditor ask us why we do this. I don't know what productivity is gained by our applications programmers who use both, but I know we systems guys sometimes need to reply to a console message from one session to free up another session. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, January 30, 2014 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Accountability (was: multiple TSO Sessions (try this)) 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accountability (was: multiple TSO Sessions (try this))
On 30 Jan 2014 09:55:32 -0800, in bit.listserv.ibm-main you wrote: Every single TSO user in my shop is assigned two ID's. No one has ever asked for a third, but many people only use one of their assigned ID's. We have never had an auditor ask us why we do this. I don't know what productivity is gained by our applications programmers who use both, but I know we systems guys sometimes need to reply to a console message from one session to free up another session. I had a systems programmer-id plus an applications id so that I could test to make sure that an applications programmer had all the appropriate access and only that access. I can see two or more ids for applications programmers to they can properly test their applications from a user point of view. Clark Morris Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, January 30, 2014 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Accountability (was: multiple TSO Sessions (try this)) 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accountability (was: multiple TSO Sessions (try this))
On Thu, 30 Jan 2014 14:35:19 -0400, Clark Morris wrote: On 30 Jan 2014 09:55:32 -0800, in bit.listserv.ibm-main you wrote: Every single TSO user in my shop is assigned two ID's. No one has ever asked for a third, but many people only use one of their assigned ID's. We have never had an auditor ask us why we do this. I don't know what productivity is gained by our applications programmers who use both, but I know we systems guys sometimes need to reply to a console message from one session to free up another session. Unix System Services can meet much of this need. I'm usually able to cancel my (hung) TSO session from a USS session with kill -9. I had a systems programmer-id plus an applications id so that I could test to make sure that an applications programmer had all the appropriate access and only that access. I can see two or more ids for applications programmers to they can properly test their applications from a user point of view. When my systems programmer is trying to reproduce a problem I report from JCL I supply, he (prudently) runs on his non-privileged ID. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
