Hmm. The CxO's admin going on extended vacation could explain a lot of bizarre corporate policies.
Gorilla tape. Exchanged DIY tips this week with one our IBM reps. We have both used this (maybe western US?) product to postpone replacing our respective over-the-hill refrigerators. Think duct tape with a more interesting name. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Saturday, July 21, 2018 11:21 AM To: [email protected] Subject: (External):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
