Back on 1984 there were very few tools for managing systems. As a result, most of us in the field wrote our own. We needed usage reports, backup procedures, monitoring, and clean-up tools. One thing that everyone needed then was an inactive terminal killer program. Resources were very limited. If a system had only 15 ports and 20 people needed access (a fairly common situation), then it was unfair of someone to be connected to a port while they took a coffee break. At the same time, security considerations made an untended terminal a worrisome feature.
When I required such a tool I went looking to see what others had written. I was disappointed by all that I looked at. Invariably they were written in DCL, an interpreted script language. What this means is that every time the system reads a statement it has to pause while it translates it into machine language. This is not a very desirable way to write an application, especially one that will be run frequently on a system. It is slow, cumbersome, and easy to break into. One such program, called WatchDog, appeared to be popular. However, the fact that it was written in DCL and not in a high-level language placed it on my reject list. Also, the way it went about determining if a terminal was inactive or not was to measure about a half-dozen different metrics, slowing it even more.
On thinking it over, I decided that such a program had to be written in Assembler. Assembler is as close to the language that machines can understand directly as a human can get. It is then compiled (translated to machine language) when developed and, so the resulting file is about as fast as one can get. In fact, it is several orders of magnitude faster to execute than anything written in a script language. Secondly, I did not want the program to waste time by measuring anything that was not needed to make the determination of whether a terminal was idle or not. Seeing as, no matter what it is doing, a process has to pass through the CPU in order to actually do it, it made sense to me that all I needed to measure was accumulated CPU time.
I set up a number of tests to actually measure how much time was spent in the CPU when a process was idle and compared that to how much time was required to process a carriage return. I came up with a number of .02 seconds as a reasonable threshold, and then doubled it to make sure. So, as long as a terminal consumed less than .04 seconds of CPU time within five minutes, it was idle. The program was intended to cycle once every five minutes and issue a warning at the 25 minute mark and, again, right before the process was terminated. I wrote the code, keeping it as simple and compact as I could.
It worked like a charm. It never logged anyone out while they were actually working and when that half-hour was up, that was it. No exceptions. The program itself required about .2 seconds of CPU time to execute on a system with 200 terminals. WatchDog, in contrast, required almost a full minute to execute on a similarly-sized system, a requirement that was far too expensive in terms of system resources. You want your monitoring and management programs to be as unobtrusive as possible.
Every year system managers contributed the tools they had developed to a users' community that put the programs on tape to be distributed to anyone interested. I was certain that my program would generate interest because it was so much more efficient than WatchDog and its relatives. What I hadn't counted on was that though system managers, as a rule, could read and program in DCL (most of them badly), very few could read and work with Assembler. My program might have been hundreds of times faster than anything in DCL, but, if they couldn't tinker with it, they weren't interested.
WatchDog hung around for years. It became even more complex, and slower, with each iterative. And, then, someone owned it. Now if you wanted it, you had to pay for it. The company that claimed ownership developed a suite of tools to assist in managing systems. Most of them were hopelessly inefficient at first but, given a choice between something that was free and something you had to pay for, most high tech managers opted to pay. I can't swear that WatchDog was Computer Associates' first successful product, but, it was there at the beginning of that corporation's existence. Computer Associates now makes a huge range of highly sophisticated (and much more efficient) products for IT management. Their revenue was $4.4 billion in fiscal year 2011.
Could I have parlayed my program into a similar-sized business? Could I have sold it for a nice profit? I'll never know. Maybe that did happen in a parallel universe, but, in this universe, better doesn't always mean success.
No comments:
Post a Comment