The UNIVAC 90 / 60:


The first full-scale computer that I had the opportunity to work with was the UNIVAC 90/60 located at Edinboro State College in the late 1970’s and early 1980’s.  This was a third-generation mainframe computer whose processor architecture and instruction set was based on the IBM 360.  Unlike the “clone” and “plug compatible” systems that were made later by Amdahl and others, the I/O architecture was different enough that IBM operating systems wouldn’t run on the UNIVAC and user programs needed to be re-compiled.


Unfortunately, there is currently very little information on the web about these machines.  I have been thus far unable to locate even a representative photograph of ANY 90/60, let alone a photograph of the actual system I was able to use.


Even Wikipedia has little to say about the UNIVAC 90/60.  The article accessed on 7/21/2007 is reproduced here in its entirety:


UNIVAC 90/60

From Wikipedia, the free encyclopedia[1]


The Univac 90/60 series computer was a mainframe class computer manufactured by Sperry Corporation as a competitor to the IBM System 360 series of mainframe computers. The 90/60 used the same instruction set as the 360, although the machines themselves were not compatible with each other; programs written for one would have to be recompiled for the other, as at the time they were developed, the concept of an operating system being portable separately from the computer system it ran on was unheard of.


The 90/60 was originally developed by RCA Corporation as the Spectra series of computers. After RCA decided to get out of the computer business due to stunning losses, it sold most of its computer and peripheral lines to Sperry; a few were sold to Singer corporation.


The 90/60 series was an enhanced work alike to the 360, as it included special features which were not available on IBM hardware until later in the System 370 series, including virtual memory, demand paging of applications, and good support for terminal-based users (IBM's offerings on mainframes have always provided weak support for interactive computing).


The operating systems which ran on the 90/60 included RCA's TSOS operating system and Sperry's own VS/9 operating system. The 90/60 was superseded by the UNIVAC 90/70 (a work alike for IBM's System 370 and the UNIVAC 90/80.



See also

List of UNIVAC products


There are several personal web-pages that mention the UNIVAC 90/60, at least in passing.  One of the better articles was written by Kenneth R. Koehler, who evidently is another admirer of the system.  Koehler writes[2]:


“If you'll pardon the poor quality of the photo, here is one of the finest mainframe systems I have ever had the privilege to work on: the RCA Spectra 70/7, using VMOS (the Virtual Memory Operating System). The Spectra 70 non-privileged instruction set was essentially identical to that of the IBM System 370. In addition to virtual memory address translation through content addressable memory (CAM), the Spectra 70/7 provided four privilege levels (P1 through P4) for user and supervisor states. VMOS was the virtual offspring of RCA's TSOS (Time Sharing Operating System), and featured a separate virtual address space for each task in addition to a shared address space for the kernel functions, a least-recently-used page replacement policy and task scheduling algorithms based on time-to-next-I/O. VMOS also included one of the most powerful editors I have ever used: EDT. Programming languages available on this system included Fortran (both batch and interactive), Cobol, PL/1, Algol, Lisp, Snobol and of course assembly language.”


Somewhat later in the same article, Koehler writes:


“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 BCTR instruction (used in calling subroutines), and the addresses involved were fine. The BCTR 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 BCTR 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 BCTR 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.”


My own impression is similar to Mr. Koehler’s in that the UNIVAC 90/60 was one of the better thought-out systems that was available in the 1970’s and 1980’s.  Frankly, I was spoiled by the VS/9 operating system.  The command language was intuitive, there was excellent online help, and (unusual for the time) there was online documentation and even an online training program called LESTER that would teach you how to use the system.