An interesting thing about VMSECURE and HOLD-ing a userid is the userid's minidisks are no longer backed up unless your doing fullpack backups.
-------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, December 29, 2005 3:10 PM To: [email protected] Subject: Re: Poicies Regarding Old Userids Taking care of a person who terminates is not the problem. It is those who simply quit using VM or are transferred to other jobs that do not require the use of VM. I plan on putting ids of terminating users on HOLD (VM:Secure removes the id from the directory but keeps a copy of the directory entry and preserves the resources and permissions) instead of NOLOGing them. And there are userids that have not been identified with any one individual or group. I am more interested in the milestones being used - when to HOLD an id and when to delete it because of lack of use, how long to keep a backup or archive of the user's data. The mechanism for protecting maintenance ids, disk and filespace owners, etc. is already developed. It is just a matter of when to use the hammer. For example, if I set an arbitrary interval of 90 days before holding an idle id and 270 days, including the 90 days of idleness, before deleting, and ran the process today, there would be about 800 ids that would be hit - 590 deleted immediately and the rest held. Our InfoSec people are going to set some rules as soon as they figure out that VM is not covered by their current policy manual. I want to try to come up with something a little more reasonable than what they do to the MVS folks and have it in place before they audit us. -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, December 29, 2005 11:47 AM To: [email protected] Subject: Re: Poicies Regarding Old Userids > Over the past 2 years, I have been coping with a user > directory that has been largely neglected. I have cleaned out > over 12000 userids, some having been dormant for many years. > I want to implement an automated system of suspending unused > ids and subsequently deleting them. Is there anything > resembling an industry standard for removal of dormant ids > from a directory? What guidelines do others follow? Depends a lot on the industry you're in. One guideline that I've found at several employers was: 1) Userid is NOLOGed on day person officially responsible for it leaves company, or immediately upon notification by competent authority (in case of unfriendly termination). 2) 30 days after NOLOG date, minidisks/SFS are archived for 2 year period and deleted from CP directory. The 2 year part varied from employer to employer (some had longer times due to statutory regs, some had as little as 6 months). We use a variation of the above here. -- db
