Between my junior and senior years in high school, Detroit Catholic Central decided the $2000/year it was paying for timesharing was too much. Instead, for the 1973-74 school year, they rented a single IBM 026 keypunch and had us run jobs on a batch system, a Control Data 3300.
Why a CDC 3300, an obscure small mainframe? The school computer instructor had a large family and couldn't make ends meet on a parochial school salary. (This fellow, John Aral Church, was also the math department chairperson, as well as former schoolmate of my father.) So, he took on jobs teaching COBOL at Control Data Institute in Southfield, MI, and programming for Blue Cross/Blue Shield. Control Data Institute generously allowed Catholic Central to use its facilities in the evenings for $35/hour, a price which surely must have been below market value.
Control Data Institute until recently had had a CDC 6600, which was one of the most powerful computers at that time. The machine had recently been removed and returned to headquarters in Minneapolis. This left a lot of spare room in the computer room at the Institute, but they still had a 3300, which was, I believe, a 24-bit word-oriented machine. I confess that, as with my experiences with the Honeywell 1640, I was largely disinterested in the details of the hardware.
However, with this machine, I had a greater motivation to learn at least the basics of operating the hardware. Switching from a timesharing system to a punchcard-oriented batch system was a step backward for most computing students, especially since that year the school introduced a second computer course. But for me, the switch to a different computing platform was a good opportunity. Because our teacher had so little free time, he relied upon the enthusiasts amoung the students to take the student's card decks to Control Data Institute and actually run the jobs.
Every Friday afternoon, several of us would drive to the Institute with the card decks. At first, Chris Murphy, Greg Bellamy and one or two others did most of the work. Eventually, they lost interest and I wound up running the jobs myself alone.
It was quite a thrill. The machine room was huge, and even without the 6600, there was still plenty of equipment. We had the machine room all to ourselves. One sympathetic employee would wait until we arrived so that he could let us into the secure room. After that, we were completely on our own. If we had problems, there was no one we could call upon for help.
The equipment was a 3300 with something like 16K words. I understood that it had previously had 32K words, but some of the memory had been carted off in a budget-saving measure. Still, the 16K words (or whatever) took a big chunk of floorspace. There were four seven-track 607 tape drives, rather high-end vacuum-column drives left over from the 6600. There were a couple of 854 disk drives, a pretty fast 405 card reader, and a 501 line printer (fast, but poor legibility).
Most dramatically, there was a large operator's console which looked as if it came from a science fiction movie. The console had an IBM Selectric typewriter, a bunch of "sense switches" and "jump switches" (toggle switches that could be read in real time under program control), and the weirdest numeric display I ever saw.
The numeric display consisted of several octal digits implemented by Nixie tubes. (I believe that it could be programmed to display the current program counter or other values, but I never used it much or knew much about its purpose.) Each octal digit was formed by eight wires inside glass tubes stacked one behind another, each twisted into the shape of a digit 0-7. When the digit 3 was to be displayed, for instance, a current would be sent through the tube shaped like a 3.
At the time, I thought that the wires were heating up and glowing, kind of like the wires inside a toaster. However, MSU engineer Tim Childs tells me that the nixie tubes used neon gas and actually consumed little power. At any rate, the appearance of a number like 050714 had a 3-D appearance, because the low-valued digits like 0 and 1 were closer to (or was it farther from?) the viewer than the high-valued digits like 7. (A former CDC field engineer tells me that most 3300 consoles did not have the Nixie tubes; they actually came out on the CDC 3500. So, this must have been a non-standard installation. See also Todd Marshall's notes below.)
The system booted from disk, but class assignments used only cards and print. The "hackers" amoung us received instruction from Church on how to use mag tape, which wasn't too hard on that system. The school bought a few half-inch tapes for us to play with. We knew that each mag tape had to have a load point. (A load point is a reflective strip that tells the tape drive where the data on the tape begins.) We didn't know whether tapes came from the factory with load points installed, and oddly, neither did the Hackett salesman who sold us the tapes. We unrolled about 25 feet of tape, found no load point, and called the salesman. He gave us a pack of load points, and we installed one 25 feet down the tape. Shortly afterward, we found the factory-installed load point--35 feet down the tape. A little knowledge can be a bad thing.
The FORTRAN version on the 3300 was not very inspiring. The implementation of COBOL was pretty decent, though. For that reason, but more especially because COBOL was not taught in school, COBOL became the "hacker's" language on the 3300, much as BASIC and TEACH had been the cool languages on the Honeywell. Few of us tried to do disk I/O from FORTRAN. The RAT, FET, and ALLOCATE control cards needed just to open a file were too intimidating. However, I believe that COBOL made it easier to do disk I/O. I taught myself COBOL from the CDC 3300 COBOL Training Manual, and I believe that Bellamy did the same before he lost interest. I wrote a class schedule conflict resolving program--can't remember whether it was in FORTRAN or COBOL--but it was never used in production by the school.
If you tried to boot the system with the line printer offline, it would halt. Bellamy had figured out a way of reassigning the line printer logical device to the Selectric on the console, which allowed him to use the system semi-interactively as well as bypass printer problems. I regret that I didn't pay attention to the technique. One evening when I was there alone, I accidentally turned off the 501 printer while trying to eject paper to tear off the printout of a batch job. I immediately turned the printer on again, blowing a fuse. From that point, I was hosed. I couldn't run jobs anymore and had to leave for the evening--most frustrating.
For the average student who didn't visit the Institute in person, being able to run just one batch job a week was terribly unfair. The "hackers" amoung us had a tremendous advantage, because we could easily run five batch jobs of our own on our once-a-week visits.
In March 2007, Todd Marshall from Plantersville, TX emailed me this:
I too was an operator of a CDC 3300 at Caterpillar Research Technical Center in Mossville, Il. The operating system was MASTER (Multiple Access Shared Time Executive Routine).
The console display was "not" nixie tubes. Each digit was a frosted glass screen and the numbers were rear projected onto the screen by turning on a light that shined through a film with the number on it. As I recall, the displays were in octal. They showed the program counter in a 5 digit center display and I believe instruction to the left and address to the right. In separate displays.
The computer had a speaker which you could turn up and "listen" to the program running. As an operator this was a nice feature because I could hear when the computer went into a hard loop and I needed to abort the program. At Christmas time we programmed loops that made the speaker play Christmas carols
A unique feature was the "indirect" bit in its memory. If this bit was turned on, rather than reading the contents of memory, it took them as an address and went there. Thus, it was an extremely fast method of indirect addressing.
In May 2009, Keith Little emailed me this:
Your computer history area is fun reading (https://www.msu.edu/~mrr/mycomp/compfram.htm
<https://www.msu.edu/%7Emrr/mycomp/compfram.htm>).
Ah, the good ol' days...
I took Computer Technology classes at Control Data Institute here in St. Louis
from 1975 to 1976 (11 months, 4 hrs/day, mon-fri!). As part of that
training, we worked on the 3300 machine; adding new features & peripherals,
doing Preventative Maintenance, troubleshooting problems, implementing Field
Change Orders, etc. What a monster that machine was! It was cooled
by 40 degree air, and I'd freeze my fingers off working on it some times.
Attached are some photos (from their brochures). Our machine had 854 disk
drives, which were only 8MB each! Also, ours ran the Mass Storage
Operating System (MSOS) instead.
Here are the images sent by Keith. Click on a thumbnail to see the original image.
Note: You may have troubles with these images, since MSU seems to now require HTTPS connections for some reason and
browsers often don't like a mixture of HTTP and HTTPS.