The Student Computer Operator

After Eastview Seondary School in Barrie acquired its GE-115 computer in the summer of 1969, it also acquired an operational problem. Unlike today's computers, this computer did not run itself. 

The computer processed individual submissions, one at a time. A student learning to program would prepare their card deck on one of the two IBM 026 manual card punch machines, wrap an elastic band around the deck and add it to the stack of jobs to be run in the metal rack just outside the computer room door. Then, the computer operator had to take that job, put it into the card reader, and process it through the GE-115. Then, the operator would take the resulting printouts and wrap it around the card deck, add an elastic band (we must have gone through a ton of elastic bands!) and return the completed job to the rack. Then, the learner would then have the opportunity to read through their printout, try to figure out what went wrong, fix the problem and re-submit.

The turnaround time for this process was at best 10 or 15 minutes, but often would extend to an hour or two. Modern programming languages often have an integrated development environment which tells your about syntax errors as soon as you type them. It's quite a different experience to have to wait two hours because you typed the letter O instead of a zero and had to resubmit.

The operational problem is this: who is going to be the computer operator? Many high schools addressed this by creating a student operator group. These students were selected based on their reliability and ability to problem solve. Often, they would work for a one hour shift, or perhaps longer. Sometimes, you could get release from some classes in order to work the computer room. At the end of my tenure, there were days were I spent the entire day in the computer room, training and assisting other student operators.

A friend of mine told me about his experience being a computer operator. What he remembered after all this time was that he remembered a sense of pride of accomplishment from doing this work. He remembered that there was a serious responsibility that surrounded this job. In turn, this responsibility helped form his own confidence and work ethic. During this conversation, I noticed that he mentioned nothing about the computer, and did not know what kind of computer it was, but he remembered the responsibility of the job. His career path did not take him into the computer industry, so it makes sense that the brand of the computer would not be so significant to him.

I remember firing up the computer first thing in the morning. The room would be dark and cold, as there was a significant amount of air conditioning specific to the computer room (I would guess that it was in the range of 10 tons of air conditioning). You would first turn on the lights. The room was quiet.

The first button you would push was the AC ON on the CPU panel. You had to wait for a few seconds after pushing this button, as you would hear the various fans and relays firing up. This also provided the baseline AC power to all of the peripheral systems .. card reader, printer, disk system. Once this sound stabilized, then you would push the DC ON button. This provided power to the logic circuits and put the CPU into a ready state. 

Next, it was time to fire up the peripheral devices. All of them started with a single power button. Normally, I would start the card reader next, the mark sense card reader, the printer and finally each of the two disk drives. At this point, I can't remember if we left the removable disks on the spindles overnight, or if we had to load the disks into the drives each morning. The removable disks unscrewed from the spindle using a plastic cover, and then a bottom seal was placed on the disk to prevent dust or other contamination from settling on the disk surface.

The disk operating system manual at the National Museum of Science and Technology contained a procedure, including pictures, of how to clean the disk surfaces using alcohol. I don't recall ever doing this with a disk, as every time you touch the recording surface, you risk damaging it. The information was very precious, the disks were fragile, and this was best left alone!

Once everything was powered up, it was time to get the computer running. This computer had no internal clock, so it did not "know" the date or time when it was powered up. The operator had to commandeer a keypunch to create a single punch card. The punch card contained a call to the program INT and it had one parameter .. the date. So a typical card would look like ".INT711003" which was 1971 October 3. This was long before Y2K, so all dates were recorded with a two digit year. Y2K had not even been considered at this point. Memory was so precious that the trade off between a four digit year and a less flexible two digit year swung heavily in favour of the the two digit space saver.

So, the brand new INT card for today was added to the boot deck. The boot deck had three cards. The first was the bootstrap loader, the second was the new INT card, and I believe that last card was a call to the program SYS. I am not entirely sure what the SYS program did, other than perhaps confirm that the disk on drive 0 was a "system disk". A system disk had the BIOS (basic IO system) stored in cylinder 0 and also had a program file which contained all of the programs for the larger tasks that needed to be handled (compilers, file manipulation, sorts and other user programs). I believe that INT and SYS were part of the BIOS and did not need the program file in order to execute. I could be wrong about that.

So, the operator then put the boot deck into the card reader and pressed READY on the reader console. Then, the operator would push the three magic buttons to get things started: CLEAR, LOAD and START. CLEAR was used to reset the operating logic to stop anything that was running and set the instruction counter to 0, meaning that the next instruction to be executed was the instruction in memory location 0. LOAD signalled that the first card in the card reader was in hexadecimal. It represented a program that would loaded into memory location 0. Pressing START caused the CPU to read the boot card into location 0 and then execute the boot program.

The boot program would then load the BIOS from the system disk and turn control to the operating system. GE used the terms COS, TOS and DOS to distinguish between the Card Operating System, the Tape Operating System and the DOS Operating System. We used DOS, but the machine would run on anything, including creating your own standalone system. 

Now, the operator would be ready to begin running batches. Usually, we could only run one job at a time. If you stacked two jobs together, then there would be no page separator between the two printouts, so you would have to break out the scissors to cut the two listings apart! Years later, when I worked in London, I created an operating system command called .JOB. The primary purpose of the JOB card was to move the printer to a new page for the new job!!

There was an art to loading the cards into the card reader. Sometimes, static electricity would cause cards to stick together and misfeed. To help prevent this, every job was fanned prior to loading. You would grab the deck on the left side and then ran your right hand along the edge of the deck, causing the cards to briefly separate and then settle back together again. Then you would put them down flat on a flat plate on top of the card reader. If this plate was in your kitchen, you might call it a chopping board. Put this chopping board had a lip on the left side. You would set the cards upright on the plate and then lift the top right corner of the deck with the palm of your hand, again separating the cards and allowing them to drop back on to plate. Then you would push the cards left against the lip. Now you had a nice, static free, aligned deck of cards. You would then place the cards in the hopper and put the plastic weight on top of the cards. Then, you were ready to go! 

As one was developing the skills to handle card decks like this, there were the inevitable disasters. The worst was dropping a portion of the deck. Often, we would have no idea what the original sequence of the cards was, and we would have to find the student programmer and apologize profusely!!

The other problem we had with multiple jobs is that sometimes, the students programs would be reading cards and they would not detect the end of the input deck. The student program would run and would merrily consumer all the jobs that were stacked after that. Then, the operator would have to pull apart the decks and rerun the subsequent jobs.

When one of these programs ate cards without stopping, it created a secondary problem. When you made a program, you would have to run the program through a compiler (let's use COBOL as an example). So the COBOL compiler would read your program, check for errors, and if it was ok, then it would create an object file (machine code version of the program). In order to execute this brand new program, you had to insert it into the program file in the system disk using the command API (Assembled Program Insert). Then your could run the program using the command PRL (Program Load). But after it was all done, it had to be deleted from the program file using the command SDS (System Disk Strip). Otherwise, the program file would fill up and you wouldn't be able to add any more new programs. 

So, when an errant program continued to read cards, it would read the SDS commands at the end of the job, and the program would never get deleted from the program file. Every once in a while, we had to get a list of the programs in the program file and then delete the user programs that didn't belong there. I can't remember the command we used to get the list of programs.

Another situation that would happen sometimes is that a program would be in a loop and had to be stopped. This was a judgment call, because sometimes programs just needed a few minutes to run. The computer executed at most 100 machine instructions per second, as compared to the billions of instructions per second that we expect now. So a minute was a long time for some calculations!!

We used a 5 minute rule for the programs. So after 5 minutes, if the program was still "running", we would hit the CLEAR button, and then then the START button. This would reload DOS and get things back on track. Sometimes, this did not work, and you needed to load the boot deck and press CLEAR, LOAD, START. The first procedure was much more convenient and worth the try.

I remember a couple of times when a student program would cause the printer to start a new page (which was normal when starting your program), but then accidentally, start a new page before every line of output. As soon as you saw this happening, you hit CLEAR, otherwise you would go through boxes of paper in no time.

The printer, of course, had to be fed with paper..The paper was in boxes, fan folded with perforated holes on each side of the page. The perforated holes were designed to fit two belt tractors on each side of the page which would pull the paper through the printer. A print line was typically 132 to 136 characters long, depending on the printer. Sometimes, the paper would jam. Then you would take the printer offline, which would pause the program running, while you opened up the top and bottom tractors and re-threaded the paper properly. Sometimes, you needed to adjust the width of the tractors a bit to get exactly the right amount of tension. Too loose and there would be wrinkles in the paper and the hammer strikes (like a typewriter) might tear the paper. Too tight and the paper would wander off the tractor and the paper would stop feeding. There was a manual slip clutch on each tractor that allowed you to release, adjust and re-tighten. Sometimes, when a box of paper was empty, the new box of paper was made to exactly the same size as the previous box and you would spend 15 minutes trying to get the printer to behave properly. 

I should mention that printers have always been a problem. Even today, the printer is one of the biggest sources of irritation. Today, you only need to print something once in a while. Back then, that was the only way to get results out.

So there were lots of challenges to being a computer operator. One aspect that was very subtle was that student were always lobbying to have their programs run first. If you were in computer class, you really wanted to get as many runs in as you could while you were in the classroom adjacent to the keypunch room. Sometimes, we placed a priority on getting those jobs run. It all depended on the the teacher's priorities.

I learned a lot about computers and about people during those many hours in the computer room. At the end of the day, I had to take a bus home, so often I was not present for the shutdown, which was the reverse sequence of the start up process. When the final AC went off, there was once again an eerie quiet that seemed out of place in such a busy room.