Data is king! Big data analysts aren't alone in making this proclamation; we IT pros can drink the Kool-Aid too. In fact, we often depend on the data trail to pin down causes and find solutions for our peskiest problems. However, it's easy to forget raw data tells only part of the story — and the conclusions we draw from the information may have unforeseen repercussions.
This story of data's reach and limitations dates back to the late 1980s, when our department worked with users in a software development environment. Our users were a mixed group of very talented and intelligent developers, along with those who didn't log in very often, such as salespeople.
I was one of the system administrators, as well as a systems programmer. For our platform, we used Digital Equipment's VAX/VMS, and most users had computer terminals in their offices that tied into a multi-user system. The admins asked users to log out at the end of the day, and most — but not all — complied. This became a problem when we had to reboot the system.
Although we requested they log off, we knew some users' projects would be compromised if they lost their command history upon a system reboot. Still others simply needed or wanted to stay logged in, which we could also abide. But then you had a segment of users who forgot to log off or weren't running anything relevant, unnecessarily tying up system resources. That last group also made it difficult for the admins to determine how our after-hours system reboot affected the users overall.
A solution to the rescue
To minimize this conflict, I worked on a convenient solution that happened to be a rather fun project. I'd found free software that would kill idle user processes, and with the program code, I could customize the software to be a little more intelligent.
I modified it to check for terminal I/O activity and to determine if a user was running a program. I didn't want to risk killing any practical user processes, such as a file-editor session that might cause a user to lose changes to a file that had not been saved. Therefore, if a user ran any program or was in a text editor, the program would leave them alone.
Our goal was to minimize user logins at the end of the day, not to get rid of them entirely; we didn't want to antagonize anyone either. Therefore, I was determined to make the job killer easy to circumvent. If someone was dead-set on staying logged into the system by running a program, that was fine. But I've seen users go to great lengths to circumvent this kind of tool — for example, by creating a completely useless and continual subprocess loop that would prevent their session from ever going idle, in direct opposition to the goal of freeing up system resources.
Sign up for Computerworld eNewsletters.