When an employee leaves the company deleting log-in credentials is not enough

The other day while working an issue at a customer site I noticed and happened to mention that there were two sets of application processes running, one set running under some generic name like Production.SysAdmin and one set, which had been running for over 3 years, under a person’s name, call him Fred.SysAdmin. It turns out that Fred had left the company a while back. I am not saying that Fred had any malicious intent but it occurred to me that a “best practices” that is always mentioned is to terminate Fred’s log-in credentials immediately when he leaves the company, perhaps right before you tell him he is leaving the company. But I never heard any best practice about terminating any processes that Fred had started. Given the length of time between reboots of VOS systems I am sure that this scenario is not unique. I suggest that, besides terminating their log-in credentials when someone leaves the company, any process running under that person’s name or executing a program module created by that person be evaluated then scheduled for termination and if deemed necessary restarted by a current employee. Likewise the batch queue should be reviewed and any requests in the person’s name should be evaluated, canceled and, if deemed necessary, resubmitted by an existing employee.

list_batch_requests -all -long Request: 59 User: Fred.SysAdmin Time queued: 10-08-11 05:00:02 edt Deferred until: 10-08-12 05:00:00 edt Attributes: waiting, not privileged, cannot restart Process priority: 5 Queue priority: 4 Process name: test Command: test.cm Output path: %system#m16_mas>SysAdmin>Fred>test.out Home dir: %system#m16_mas>SysAdmin>Fred Notify users: Fred.* on %system#*

You can use the command

analyze_system -request_line (string match fred (byte 3Bx) who) -quit

to identify processes running under Fred’s name.

T he following command macro can be used to find any executing program modules created by Fred regardless of what name the process is running under. The macro creates a list of all executing program modules then does a display_file_status to determine who created the program module file and a display_program_module to determine who bound the program module. Any program module created or bound by someone with a name matching the input string is displayed along with the processes executing that program module. It also creates a report in the current directory named wr_&NAME&.(date).out, where &NAME& is the argument given to the macro.  All names are translated to lower case. If no name is given it displays information on every executing program module and the report is named wr.(date).out.