11-Nov-2007: My Early Computer Years
Today I was pulling documents from old file folders and came across a mortgage amortization table. That
brought back memories of my earliest days in the computer field. When I voluntarily "retired" from teaching, in 1982, I was given
six months' salary and a refund of my pension contributions. I had planned to use it to finance training in the
about-to-take-off computer field and that is what I did. I eventually landed a very junior position in the federal Department of Energy, Mines, and Resources
(today called Natural Resources Canada). I
was a computer operator, which might sound exciting, but all that the job entailed was changing tapes on the tape drives,
feeding cards through card readers, looking after printer output, cleaning equipment, and whatever other job needed to be taken care
of by the bottom of the food chain.
It was a long time ago—in the early 1980's—when computer rooms housed a few huge mainframes, cooled by one-inch water pipes in an
air conditioned room, peripheral equipment scattered about, and a warehouse-size room filled with clothes-washer sized disk drives. A staff of
approximately 100 people were directly related to the daily operations and support of the systems, with another 80 or so in program development.
Fortunately, being a government department, the computers
were shut down weekends and during statutory holidays. Saturday afternoons were reserved for testing.
Working in the computer room, two staff members looked after the tape library where about 30,000 reel to reel tapes, containing data, programs, and backups, were stored. There
were always two console operators during the day, and one on each the evening and overnight shifts. The console operators determined which jobs
the computer should run, actively managing the job queues, sort of like air traffic control, but on a much smaller—and less stressful—scale.
There were shift managers, and at least two or maybe four, junior operators, during the day and evening, and one or two on the midnight shift.
And, they were all kept busy, except for the hours between 2:00 am
and 7:00 am when all the big batch jobs had finished running. I used that time to sleep, though that was against regulations.
Though there were "dumb terminals" linked to the mainframes by short-haul modems, most of the users of the systems preferred to work
with punch cards. They would bring their decks of cards to the job submission window where a junior operator would take them and queue them
up for a card reader. The actual execution of the job might not take place until late in the evening or early morning. The next day the
user would return to pick up his card deck and a paper listing of the results of the run. As a service to clients of the system, there were half a dozen
remote terminals scattered within a few blocks of the computer room, where operators would collect card decks and tapes, ship them to the central
computer room to be executed, and then return them next day to the users.
By the way, all the users of the systems were scientists who wrote their own computer code. For many, the only copy of the data they depended on was
punched on cards—which they were, understandably, very possessive of. Their computer programs would sort through data and produce pages of
statistics. Or, perhaps they would create graphs of the data, sketched out by computer-driven pens on scrolls of paper.
Administrative programs were rare. No one, at that time, had figured out how to apply these huge ungainly machines to the tasks of managing employees,
offices, and communications. Our users mainly employed BASIC or FORTRAN as their programming languages. COBOL was used by our program development
sector as they struggled to produce the first genuinely useable programs for administration. Mostly they mined rigidly-structured data bases and used
the data to print forms and labels that could be stuck to envelops for mailing.
That was the environment I began in. It was hierarchically structured. Different unions represented different employee groups. Every step of every
job was regulated. There was no room for improvisation. As an example, one job the huge line printers ran once a week or so
required paper that was perforated both vertically and horizontally. Unless the printer feeding tractors were exactly aligned, the paper would
split along its vertical axis, ruining the print job. One evening I grew tired of trying to find the sweet spot that would permit the job to run to completion without
tearing the paper in half; I had discovered, by experimentation, that if I left the back cover of the printer open, the paper was much less likely to split. It
meant a lot more noise in the computer room, which already sounded like a factory, but it meant I could stop wasting time on the finicky tractors and get
on with other work. A more-senior operator returned from break and indignantly demanded to know why the printer cover was lifted. I told her my reason.
She cursed and immediately stopped the print job (which was nearly finished). She then spent almost two hours adjusting the tractor feeders before she
got them in exactly the right position so that the ten minute print job could complete. I ran into that sort of situation fairly often. Something wasn't working
the way the operator instructions said it should, so I'd find a way to make it work. I was not very popular with other operators who started to regard me as something of
a maverick. Ironically, it was a little more than a year before I was writing operator instruction manuals and insisting that they follow them to the letter.
Which brings me to the mortgage amortization table. Though entry level operators at that time were required to have command of two computer languages, none
of the other operators I worked with seemed interested in writing code. During quiet times in the computer room, when I wasn't sleeping, I would write little programs
for amusement. The shift managers noticed, and one asked me one day if I could write a program that would print out amortization tables for variable interest
and term lengths, as he was thinking of buying a house and wanted to be able to compare mortgage options. The next shift he was stunned when I presented him with the program
and showed him how it worked. He was delighted with it, but thought that something that complicated would take me weeks to write. After all, they
had an entire department of programmers who were very highly skilled and trained who needed months to prepare a program; and a systems support team of nearly a
dozen people who were constantly
tinkering with the systems to keep them working.
In later years I would find out just how much bad thinking and incompetence were lurking in the ranks of the programmers and systems folk (and, yes, I will tell tales),
but to me, what was a simple programming task, caused a small sensation in the operations world. Within a few months a temporary position opened up
in the user support section (another dozen or so employees) and I won the position because of my demonstrated programming ability. The job was to man a front desk
where users would telephone, or drop by, with questions about their computer programs—and I was supposed to answer them. I had no background at all
in FORTRAN, which was the language most of them used, but, within a month I had stopped forwarding FORTRAN questions to a specialist and took care
of them myself. I spent the majority of my time debugging code, which often landed on my desk as a six-inch stack of paper printout, and with no more clue than: it doesn't work.
Users always denied having made any recent changes to the code which they claimed had run successfully for months or years. I got pretty good
at tracking my way quickly through the spaghetti they called code to find an absurd line that couldn't possible have ever worked. When I'd point it out to them, they
would sheepishly admit that, yes, they had made that one small change, but didn't think it would affect the entire program.
Another aspect of my job was to research requests for credit. If a user's job failed because of a fault in the system or an operator's mistake, the computer time
charges would be credited back to the user's account. I had to find the reason the job had failed. I could reject requests out of hand, but any where I thought the user had a case,
or if I was in doubt, I would forward to the head of systems support for further analysis. The request would then go through many hands until it arrived
back on my desk with an "approved" or "disapproved" note on it. I'd contact the user and take the heat if it was a rejected request. (A copy of the approved request
was sent to the financial folks for them to deal with.) The problem I had immediately
with this system was the amount of paper-work involved. The original form was in triplicate and had to be filled in by hand. I would keep a copy when I forwarded the
other copies, but, no one previously in my position had bothered to keep track of the copies they retained. They were all shoved into a drawer helter-skelter and
never looked at again. Even if one had to, the chances of finding a copy of a specific request were almost nil, as the drawer had several years' worth of slips in it.
Now that bothered me. Why were we filling out forms by hand and tracing things by paper, wasting paper that was not useful to anyone (not to mention
all the sheets of carbon paper), when we had these massive mainframes at our disposal? It offended me. And, so I wrote an online system for recording and tracking
credit requests. All I had to do was bring up the program when I got a request and fill in the blanks. The program kept track of who was supposed to review
the request and would nag them (once a day) until the specialist checked it off, or wrote in their comments. I could check a request's progress at any time (which helped when
irate users would call), and when it received final approval a note was automatically sent to the people who managed the funny-money so that the user's account could be credited. Not a single scrap of paper was
required and the turn-around time for credit requests was reduced from weeks to a couple of days—or even faster if all the specialists who had to sign off were
on the ball. The program worked flawlessly for years without requiring code tweaks—just like any program should.
There are a few lessons in this entry. One, of course, is to always keep your eyes and ears open for opportunities in the workplace to show off your skills. Always go
a step beyond what is required. Another: the point is to make things work for the employer, not to hide behind badly-written procedures and use them as an excuse
for failure. Yes, the operator who wasted two hours to do something by the book, instead of letting a job complete that was nearly done even if the fix was non-standard,
was technically correct. Technical failures don't make your employer money: results do. Note, I am not advocating anarchy in the work place. The procedures are there
for a reason.
And, finally, I am attempting to demonstrate how the major revolution in computing began. It was thousands of people just like me who, coming from non-scientific
backgrounds and appreciating what
computers were capable of, started asking new questions and finding solutions within the technology that existed. People, even today, assume that I
must have been good in math to accomplish
all that I did. Actually, I am terrible at math. What I am good at is asking stupid questions, like the one about using triplicate paper forms when all this technology
was available.
I'm done with all that. The high technology world evolved too quickly for me in the end, but it was one hell of a ride for the twenty-two years I was in it.
More to come...