Way back in the early days, computers had vacuum tubes. In the Emory Chemistry Department, we had one: An LGP 30 that I nicknamed, "Guppy."

The LGP-30 (Librascope General Purpose) made by Royal McBee had a rotating magnetic drum memory with 256 words, flexowriter typewriter for input and output, optical paper tape reader, and paper tape punch. Internally it used diodes and small vacuum tubes.

Weighing 740 pounds, Guppy was prone to heat stroke and usually crashed after a few minutes or at most a few hours, but almost always before completing the single task at hand. You could often hear chants, pleas and other bizarre rituals coming from Guppy's den. This was apparently intended to persuade Guppy to stay up just a few minutes more. Alas Guppy had converted some of his users from scientists into practitioners of witchcraft, not me of course. I remained an objective rational chemist. I did discover, however, that reading a mystery story out loud in Guppy's presence often delayed crashes. This was not mere superstition. I think Guppy wanted to find out "Who Done It."

My next computer (still in the Chemistry Department) was much more stable. It had transistors instead of vacuum tubes and 8K (no that's not a typo it's actually a "K") of real magnetic core. This sophisticated gem could go a whole day, or sometimes more, without crashing.

Transistors could also be problematic though. I learned this after beginning work for EUCC, pronounced "yuck," as the Assistant Director for Systems Support. We began having what seemed at first to be unrelated problems: corrupt data files with "arbitrary" bytes randomly inserted in the file; user programs crashing with operation exceptions, but rerunning without error; and rare operation exceptions at different places in system code. The latter brought down the whole system and produced dumps, clearly indicating the invalid machine code operation.

Since we had the source code to the operating system, we could tell that the code which should have been executing was valid. After analysis, these crashes could also be explained by an inserted byte. Well, it turned out that the inserted byte was always the same value as a byte 64 bits earlier. The good news was that there was only one 64 bit bus (the memory bus) on this Univac Series 90 computer. An occasionally misfiring transistor was causing the bus logic to erroneously interpret that new data had already been loaded onto it and proceeded to load that data one byte further on. Once identified as a hardware problem, the Univac engineer who designed the memory subsystem was able to trap the problem on an oscilloscope as it was occurring. Great fun! Of course, identifying the problems in the then corrupt file system and correcting them later was not so much fun.

The early internet was also full of learning opportunities. I recall with horror the first major Internet born attack, "The Robert Morris Internet Worm," in the late '80s. The worm relied on bugs in the UNIX sendmail program. Arnold Robbins (coauthor of Gnu awk, and author of several O'Reilley "Nutshell" books after leaving Emory) was not fond of sendmail (is anyone?) and had configured our sendmail "his" way. This non-standard implementation was not vulnerable to the attack, so we were OK. Of course, we were still susceptible to the psychological effects of the attack.

My background in chemistry had made me one of the major users of CPU cycles at Emory. I hated to see an idle CPU second. When I learned that the MVS System Resource Manager (SRM) was sophisticated enough to define a class of programs that would only use resources when there was NO other demand, I set about convincing our CIO that we could run some well-behaved physics jobs on our administrative machines with only very trivial impact on "production." These "sponge jobs," as they came to be known, would soak up all available CPU and our MVS production systems would run at 100%. This was sometimes a problem when we did our annual performance analysis review. We would send several weeks of data to the IBM performance center for analysis. New people working at this center were usually unaware of our sponge and I would get calls from them telling me that they had figured out our "problem." There was no idle CPU in two whole weeks of data. They were really disappointed when their discovery did not result in new hardware purchases. They usually were very interested in our configuration and provided a good sounding board for our approach.

There certainly has been a lot of change since the dawn of computing. I have been privileged to see some of it, however I believe that the pace of change is only accelerating. The good old days are not nearly as exciting as what's to come.

- Susan Ament, Applications Integrator, OIT Architecture