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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
