> But those functions improperly deprecate group IDs, Do you mean that they deprecated sharing a userid among a group, or that they deprecate associating a resource with a groupid rather than with a userid. If the latter, what are they smoking?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Saturday, July 21, 2018 2:21 PM To: [email protected] Subject: Re: OA55889 for TSO/E in z/OS 2.3 On Sat, 21 Jul 2018 18:02:23 +0000, Jesse 1 Robinson wrote: > >I concur that an 'email id' should follow an individual throughout one's >corporate life. But when someone moves from Applications to Operations to >Systems to Security, who on earth believes that a single TSO userid should be >permanently attached to that person like Gorilla tape? ... > A user should have a single ID for all such purposes, including email, with a rules data base governing capabilities. HR and Security want it that way, if only so that when an employee leaves the company all that person's access can be cancelled in one operation. Those groups grudgingly accept the constraints of the current environment. But those functions improperly deprecate group IDs, so when a key employee is on vacation a service becomes unavailable. Again, this could be solved with rules, but I've suffered the requirement that every resource be associated with a specific employee -- when that employee is unavailable there's no tech support. -- gil ---------------------------------------------------------------------- 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
