For testing authorized code, it helps to have a userid with minimal privileges.
________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Tom Brennan <[email protected]> Sent: Friday, July 14, 2023 10:56 AM To: [email protected] Subject: Re: Userid schemes I had 3 id's on each system, but all had the same sysprog capability. Mainly it was to avoid the embarrassment of having to go to another sysprog to fix my #1 id after I messed it up testing or changing something. But they also came in handy for testing things like enqueues and multiple tasks. For DR testing we tried 3 new role-based id's to be used for OS, CICS, and DB2 recovery, but that plan kept failing due to lack of authority over time. The main sysprogs for each always kept their own access up-to-date, so we ended up using a 'stub' DR id with SPECIAL access that could change passwords and use their personal ids. That worked fine and the stub userid access was handled by an off-mainframe security system. The whole idea of course, was for anyone with the printed instructions to be able to do the DR recovery - no sysprogs needed. Turns out almost every test we needed a sysprog anyway, but at least we had that goal. > At one point some of us had two userids. SYSPROG1 ... for sysprog stuff, > and a personal ID. > When anyone moved on they just reallocated SYSPROG1 to a new user, and all > the accesses continued to work. > If you use a personal ID, you had to connect it to a lot of groups to get > the access, and remove the retiree from the same groups. > Role based userids are much better and less work > > Colin ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
