Note the typewriter on the console: it was the only print output device we had! Our 1620 had only 20000 digits of core storage; we did not have the storage expansion cabinet behind the console in the picture. The 1620 was a decimal computer and could not add like more modern computers: it looked up answers in a table. Each storage location contained a four bit Binary Coded Decimal (BCD) number, a flag bit and a check bit. We could only program in Fortran or SPS (Symbolic Programming System, the native assembler), which I did not have a chance to learn before we upgraded to a different computer. In addition to writing our own programs, we had a series of decks of punched cards, which when printed out, displayed various pictures. It took almost an hour and a half to print a poster of Alfred E. Newman on the typewriter.
Here is a closer view of the 1620 control panel:
This sort of control panel was a standard feature on all computers of the mainframe era. It enabled instruction-by-instruction control and a direct view into the physical memory of the system as it ran, and was used for software as well as hardware troubleshooting purposes.
At this point our only method of data storage was punched cards:
Blanks were loaded into the hopper on the top right side of the IBM Model 29 Keypunch:
and the cards moved from right to left as the data was keyed in at the keyboard. As each card was finished, it was added to the output stack on the left. The small window in the upper middle allowed a view of the "program card", which was a punched card wrapped around a small rotating drum which described tab positions, etc. The chad box (below the "desk") held the punches, which made great, if dangerous, confetti. It was possible to duplicate individual cards as well as punch new cards or additional columns in cards that were already partially punched. In addition, when cards were punched on the card punch attached to the computer, they did not have printing across the top to indicate what was punched on them. These cards could be fed into the keypunch and "interpreted": their contents would be read column by column and the corresponding character printed above each column. When a card jammed in the punch, you often had to use a card saw to remove the torn bits of card from the punch mechanism. When interpreting a large deck, this happened more often than was enjoyable.
Of course, it was extremely easy to drop a deck of cards, so we punched on each card a sequence number which allowed sorting the cards to restore their order. For this we used an IBM Model 83 Card Sorter:
In addition to taking care of dropped decks, the sorter was used to sort large sets of cards, one column at a time, in order to put them in order by name or address, etc. It was not unusual to spend an entire night sorting thousands of cards on tens of columns in order to prepare them for input into the computer program which would process them. We stored our cards in special cabinets whose drawers were removable, and held a couple of thousand cards each.
The year after I met the 1620, we upgraded to an IBM 1130:
This machine was a true binary computer. We started with 4K 16-bit words of storage, and when we upgraded to 8K, it was all the memory you would ever need: now you had enough memory to use overlays! This meant breaking up your Fortran program into sections, only two of which would ever need to be in memory simultaneously, but it meant your programs were only limited in size by your creativity. We also programmed in RPG (Report Program Generator) and APL (A Programming Language). The console now had a Selectric typewriter, but we also got an IBM 1403 printer:
Now it only took minutes to print out a picture of Alfred. The 1403 was a chain printer, which means that a rotating loop of chain with characters on it spun past a row of hammers, and each hammer hit at precisely the correct time to print the correct character in the correct place on the line. It was loud and when it jammed it was a mess. And you could print out meaningless files which would play a song. We also had a 1442 card reader/punch:
and an Optical Character Reader (OCR). The 1130 had a disk drive, accommodating a half megabyte disk cartridge. I recall our only head crash: we extracted the cartridge and opened the access hole (where the heads entered the cartridge) and metal shavings fell out. Talk about a sinking feeling. This machine also taught me about violence and computers. At one point it developed an intermittent problem of arbitrarily powering down by itself. When it did this near the end of a program run in excess of two hours, I lost my temper and gave it a swift kick: and it powered back on! Turns out there was a loose screw lying on a voltage regulator, and the shock was knocking the screw on and off of the contacts. But on the whole it was a very reliable machine. In addition to a couple of card punches and a sorter, with the 1130 we were able to run a large high school's attendance and registration systems.
And now we get to the big leagues: the IBM 360/25:
This is the machine on which I learned assembly language, on which I implemented my first operating system and on which I wrote my first microprogram: a shift instruction which was designed to shift the bits in a 32-bit word in a circle, but whose first version shifted the entire contents of RAM! It ran the Disk Operating System (DOS/360) when we weren't playing with it, and it had a big red panic button on it (I suppose to turn it off if it caught fire, although none of us ever had the occasion or the courage to try it). Ours had 32K bytes of storage, but I don't remember the peripheral complement, with the exception of the IBM 2560 Multi-Function Card Machine (MFCM). The MFCM gave a whole new meaning to the word mulch. I wish I still had my copy of the System 360 Functional Description Manual. This document described the internal architecture of the 360, which lives on in many descendant systems, and the document itself was a marvelous example of good technical writing.
The pictures above are courtesy the IBM Corporate Archives, which grants free use for educational purposes. My thanks to IBM for helping me to share these memories.
Note the thermometer next to the console; it was vitally important for the operator to monitor the temperature of the computer room to prevent hardware failures due to extreme temperatures.
This photo shows several of the peripherals used on the Spectra, including tape drives and a 70/243 2000 line/minute Whisper Printer. The small typewriter-like gadget is a 70/97 system console, through which the operator communicated with VMOS for purposes of job control and coordinating the use of peripherals by individual users and by the system as a whole. The operator's duties included system startup and shutdown, mounting and unmounting of tapes at the request of batch jobs or interactive users, and distribution of printouts.
It is interesting to note that this system had no disks (although some were added at a later date). All permanent storage was on either tape or punched cards, and backing store for the virtual memory was on a fixed-head rotating drum. Tape files were accessed using SAM (Sequential Access Method); disk-based systems also supported ISAM (Indexed Sequential), PAM (Primitive, page-oriented) and EAM (Evanescent, used for uncataloged temporary files and later, backing store).
Of course we students had no direct access to the Spectra; that came later when I went to work for Sperry Univac. Student access was either through the submission of decks of punched cards, or online via terminals like the Model 33 Teletype (TTY):
This was a noisy device which communicated with the mainframe at the incredible rate of 10 characters per second! The device on the left was a paper tape reader/punch, with which I thankfully had little to do. As primitive as this sounds, interactive access via TTYs was a huge improvement over the batch submission of programs punched on cards.
Here is the first CRT terminal I ever met. Note the acoustic coupler next to it: dial-up communications with the mainframe was accomplished by dialing the number of the answering modem and placing the phone handset in the coupler. The terminal emulated a TTY when used in this way. I have no recollection of the purpose of the box on top, but vaguely recall that this unit was capable of playing Pong, so it may well be a primitive microcomputer.
This series of pictures was taken in 1976.
only held 100 MB and required controllers twice that size to do the job that a single chip does on a motherboard in today's PCs.
On my first day at a 90/60 customer site there was a SRED waiting for me. The 90/60 was Sperry's version of the 70/7; it ran VS/9, which was Sperry's version of VMOS; and a SRED was a System Resident Emergency Dump, which occurred whenever VS/9 had a panic attack. Those days it sometimes happened every few hours. Things would be running along nicely and suddenly everything would stop and a small message would appear at the bottom of the U100 console saying "Mount SRED Tape". The operator would mount an empty tape and (on a system with 512 KB of RAM) the system would dump the contents of the registers and real memory on about half of a 2400 foot reel. After rebooting, this would be processed into a two inch thick listing and laid on my desk. In order to analyze the dump you had to do virtual memory translation by hand, using the translation tables to convert virtual addresses into real addresses, whose contents you could then locate in the SRED listing. That was REAL debugging - no sissy IDEs with built-in symbolic debuggers!
The 90/60 CPU was a fascinating piece of architecture. From the system programmers point of view it was almost identical to its predecessor. But from the viewpoint of the microcode, there were actually two independent processors which ran asynchronously: one to staticize instructions and the other to manipulate operands. This architecture was the source of one of the highlights of my computing career. One day a programmer at the customer site showed me a program dump of a COBOL program. The program had gotten a paging error, which are normally caused by a bad virtual address. But in this case, the error occurred (at the machine language level) on a BALR instruction (used in calling subroutines), and the addresses involved were fine. The BALR instruction happened to be at the end of a virtual page, and by adding innocuous instructions to the program, we were able to move the BALR from its position at the end of the page and the error disappeared.
I asked the Customer Engineer on site to run diagnostic software to check the CPU, but the software did not run in virtual mode and therefore could not find the problem. So I wrote a small program which I keyed in manually using the CPU console switches. The program included a few virtual memory translation table entries and the code to put the CPU in virtual mode and loop on a BALR instruction at the end of a page. This enabled the C. E. to see the erroneous paging faults and we eventually tracked the problem to a bug in the microcode which affected the synchronization between the two internal processors. It was very cool to be able to track a problem like that all of the way to its source, and the fix we sent in to the designers was issued as a field change order for all 90/60s a few months later.
I've been thus far unable to locate a picture of a 90/60, but here is the 90/60's bigger brother, the 90/80:
This photo of a 90/80 control panel was taken in Sperry's headquarters in Bluebell, PA. While the 90/70 was merely a speeded up version of the 90/60 (which in reality was a slightly crippled 90/70!), the 90/80 used a wholly different internal design while maintaining complete compatibility with the 90/60; user programs would run interchangeably without recompilation.
Online access to the mainframe was typically through the Uniscope 200 terminal. Normally connected via multidrop networks, the U200 used a synchronous communications protocol in which the mainframe's communications controller (a Multi-Channel Communications Controller, or MCC, on the 90/60) polled each terminal in turn for data to be sent. The U200's only capabilities were cursor positioning, blinking, reverse video and protected fields, all accomplished using embedded escape sequences which had to be coded in the user program by hand. Here are the Uniscope 100 and 200:
After a few years on the 90 Series virtual systems, I was asked to do systems work on the 1100 Series computers (shown here with a U100 console):
Like all mainframe computers, they sat on a raised floor, required extensive power and air conditioning, and were probably inferior to the computer on which you are reading this web page in all respects except size and cost, which ran from below a million to many millions of dollars!
The 1100s were not byte-addressable; memory was organized into 36 bit words, and you could access characters in a word by quarters (for ASCII) or sixths (for Fieldata). The 1100 Series supported symmetric multiprocessing, and the problem of synchronization was solved by a simple and elegant instruction called the Test and Set. To lock an object for exclusive use by a single process, you would Test and Set the semaphore associated with the object. The instruction tested the value of the semaphore and then set its value in a single machine cycle; if the value was tested as zero, you now had exclusive use of the object and could proceed. If it had tested as nonzero, someone else had already locked it and you had to wait.
Another thing I recall about the 1100s was using FLIT to analyze panic dumps, which were the 1100 equivalent of SREDs. FLIT stood for Fault Location by Interpretive Testing, and enabled the analyst to load the panic dump into memory and actually run the dumped system as a virtual machine. You could not only find problems but test fixes, and it could refer to symbols in the OS, making it the first symbolic debugger I ever met. The real memory 1100 was simpler to debug than the virtual systems anyway, but FLIT was icing on the cake!
There seems to be almost no pictoral evidence of the old Sperry mainframes on the web. If you have found this page interesting, and know where I can obtain public domain pictures of any of the following hardware, I would be most appreciative!
With an ImageWriter printer and the Macintosh Developer's Kit, it cost me around $4700. It was cool, but it was slow, and software installs were a gripe: a system upgrade required 14 diskettes, and Microsoft Office required 30! Each one fed to the diskette drive, one at a time:
Since then I have had several more Macs. Then I moved to Linux, building my own PCs on which to run it (and eventually building my own distro from source), and I've never looked back... until now!
I would like to take this opportunity to thank some of the people who were responsible for much of my computer science education over the years: David Bach, who introduced me to the 1620 and taught me Fortran; John Kern, who mentored me through the 1130 years, who let me write software for the school and who helped me to get my first professional programming job; Ed Krall, in whose office I spent half of my undergraduate career (or so it seems) and Mike May, who gave me the freedom to learn while giving me some of the toughest conversion and programming assignments I have ever had. And to the late Dan Michaels, who was first a system administrator to grovel to, later a colleague, and always one of the most capable fellows it has been my pleasure to know.
I would also like to thank the many folks I worked with at Sperry, but most especially Todd Studebaker and the late, great Errol Morrison, who gave me the freedom to learn and explore while I was fixing problems, and Gene Terrell, who taught me just about everything I know about hardware. Thanks also to Jim Cairns, Jeff Clark and Pierre Cloutier, who helped with some of the pictures you see above.
Finally, I would like to remember those I've worked with who have passed on, gone but not to be forgotten. At Sperry: Cordy Arterburn, Bob Faust (who could sell an icebox to an Inuit), Larry Holst, Errol Morrison (project manager extraordinaire), Larry Rogers and Al Stencavidge. And my dear friend Joel Pugh, IT manager at the now-defunct Thriftway Food and Drug. Joel was that rarest of IT managers, one who was well-liked by everyone he worked with. Perhaps it was because he would do anything for a friend, and always just wanted to get it right.
©2015, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.
Please send comments or suggestions to the author.