In September 1986, Michigan State University acquired a Digital Equipment Corporation VAX 8650. This, along with the purchase of an IBM 3090 around the same time, was the death knell of computing on Control Data mainframes at MSU. Our 8650 was in operation until some time around 1993, when it was replaced for about a year by a VAXStation 4000/60.
As with everything else in life, politics played a role in the decision to get a VAX. Most of the campus was glad to be on a safe, standard computer from mighty IBM. Years of limited software choices on the CDC machines had created a groundswell of ill will toward anything that wasn't "standard", and IBM was as standard as you could get. But scientists on campus, especially the influential high energy physicists, preferred VAXes. And IBM's VM/CMS was not well-suited to instructional computing. (In particular, the minidisk-based file system was awful.) Furthermore, IBM mainframes did not have the hardware and software to accomodate all our networks.
Thus, it was decided to purchase a VAX in addition to the mainframe that "everyone" seemed to want. At the time, DEC had two equally powerful top-of-the-line VAXes: the UNIBUS-based 8650, which was just a souped-up version of the older 8600, and the 8800 (and its single-CPU version, the 8700). The VAX 8800 was based on the new BI bus, and very few peripherals were available for it. Because we wanted a wide range of connectivity options, we went with the older, slower UNIBUS machine. This was a fortunate decision, because the BI bus never really caught on.
My small group was given the job of managing the 8650. I delegated some of the work to Jerry McAllister, and to a lesser extent, two students named Lester Bautista and Ron Ferguson. I tended to do much of the system management myself, partly because I enjoyed it.
My first task--even prior to the delivery of the machine--was to attend a DECUS (Digital Equipment Corporation User Society) meeting to come up to speed on VMS. I had had no exposure to VMS, so there was a lot to learn. Back then, DECUS meetings were huge, ultra-busy affairs. There were typically 5000-6000 participants for a week, with a schedule that had about 16 simultaneous tracks throughout the day. There weren't many places in the U.S. that could handle a convention that big. Since I attended both Spring and Fall DECUS meetings for several years, I probably wound up seeing most of the major convention sites in the U.S. during the late 1980's.
The 8650 was rated by DEC at 6 VUPs (VAX Units of Performance). By definition, the original VAX 11/780 was 1 VUP. Since the well-known SPECmark 89 and SPEC92 benchmarks were also based on the 780, this means that the 8650 should have had SPECmarks around 6. (I can't remember verifying this.) We had a floating point accelerator (FP8650??). The 32 megabytes of memory in our machine turned out to be more than enough.
The 8650 was, I believe, the last VAX ever made with PDP-11 compatibility mode. By the time we got into the VAX business, PDP-11 compatibility mode was rarely used. In fact, I don't know whether we ever used it. It's possible that TECO used 11 compatibility mode, but I ran TECO only once or twice to satisfy my curiousity. (TECO was a powerful but very abstruse text editor.) I once heard a DECUS speaker claim that the 8650 was the fastest PDP-11 ever made; I wonder if that's still true.
The table below summarizes the configuration of our 8650. The performance of our machine with so many UNIBUS peripherals can be imagined when you realize that the UNIBUS is a considerably slower bus than the IBM PC/AT ISA bus!
| Part | Comments |
|---|---|
| 865CD-PA main system | VAX 8650 with 32 MB of memory. |
| FP86-AA floating point | Floating point accelerator. |
| LetterWriter 100 | I can't recall the exact model name or number of this beast, but this was a dot matrix terminal similar to the earlier DECwriters. It served as the operator console, connected to a special-purpose serial port named "OPA0:" in the back of the 8650. The LetterWriter jammed frequently and was a pain. However, it was useful to have a paper trail (literally) of all system events. We typically printed on the back side of huge listings from the IBM mainframe. The listings, as I recall, had information about file backups. I don't know why they were printed in the first place. |
| DENUA Ethernet | Ethernet board. This was a pretty slow board. I believe that someone in Physics told me that this Ethernet board benchmarked at 170 KBps, slower even than a MicroVAX II. It was reliable, though. |
| DMF32-M printer / serial | 1 printer port, 1 synchronous port, and 8 asynchronous serial ports, only 2 of which had modem control. |
| KMS11-BD serial controller | Rarely-seen 8-port microcoded X.25 controller. We used this to hook to our campus X.25 network, which operated over broadband cables that had been lain across campus for cable TV and central electronic building heating/cooling control. |
| HSC50-AA disk/tape controller | Hierarchical Storage Controller, an
intelligent disk and tape controller. Based on a
single-chip PDP-11, the HSC used twin 256KB mini tape
cartridges for mass storage. The HSC's operating system
allowed you to access these as random-access devices.
These must have been among the slowest mass storage
devices ever, but they were reliable. One eccentricity was that the HSC50 would not boot unless a terminal (in our case, a DEC VT220) was plugged into its console serial port. |
| SC008-AC Star coupler | This unintelligent device (I don't think it even required power) hooked up the various devices on the cluster's CI (Computer Interconnect) bus. This was a 40 Mbit/second bus that hooked together computers and storage controllers. In our case, having a CI-based cluster was overkill, as we had only the 8650, the HSC50, and later, the VAX 750 in our cluster. |
| Console subsystem | The VAX 8650 had a built-in PDP-11 that ran its own operating system. This PDP-11 booted first, from the internal 10 MB removable RL02 disk cartridge. It then controlled the booting of the VAX. Upgrades to VMS typically also required modifications to the files on the RL02. The RL02's, and the console subsystem in general, were amazingly reliable. |
| RA-81 disk | 456MB disk drive. This physically large drive (14-inch platters, in a heavy enclosure maybe 10" x 16" x 36") was very common at DEC sites, but the drive was unreliable. I can't remember how many we wound up with, as we acquired RA81's in about 4 stages: the initial purchase, a subsequent purchase (?), the arrival of the Fermi ACP machine, and the arrival of parts from the Computer Science 8600. Most of the RA81's lived in three-high cabinets; there was one 4-high cabinet. |
| Emulex SM834-1 disk | We purchased a fast and reliable Control Data SMD disk, complete with a controller that made it look like an RA-series disk. This was probably a bad investment, because although the drive worked well, we never got any more CDC drives to fill the rest of the 4-high cabinet. |
| TA78 (?) tape drive | We had two 150 inch/sec vacuum-column tape drives. One was a master; the other, a slave. I'm not sure of the model numbers; I think one was a TA78 and the other a TU78, but from my point of view, they were identical. These units were unreliable. When we stopped paying for hardware maintenance, both drives promptly and permanently became unusable. These drives connected to the HSC. |
| TU81-AA tape drive | This lower performance horizonal-mount drive was inherited from the Computer Science 8600. In marked contrast to the higher-performance TA81, the TU81 was completely reliable. It came with its own UNIBUS tape controller, whose part number I have forgotten. |
| TK50 cartridge tape | TK50's were DEC-proprietary cartridge tapes that measured about 5" x 5" x 1". The cartridges were expensive--about $35--but quite reliable. Our TK50 drive came, of course, with its own UNIBUS controller. I seem to recall that a TK50 could hold about 95MB. I actually bought a few blank TK50's, but over time I accumulated so many spare TK50's from software distributions that I couldn't give them all away. |
| UDA50 | Low-performance UNIBUS-based disk controller for RA disks. These were installed years after the original purchase, when we inherited them and some RA81's from Computer Science's 8600. |
| Dilog SU726A SCSI controller | With increasing use of disk space and decreasing Computer Lab enthusiasm for the VAX, it was decided to economize and purchase SCSI disk rather than more expensive DEC-style MSCP (? not sure that's the right term; anyway, RA-style) disk. We bought a UNIBUS SCSI controller capable of controlling only disks, unfortunately. |
| CDC/Seagate Wren 6 disks | The first SCSI drives to use the CMD controller were a pair of CDC Wren 6 600 MB drives. These worked flawlessly, though performance through the UNIBUS SCSI controller was slower than a low-end IDE drive on a bottom-of-the-line PC. |
| Seagate SCSI Elite disk | This 2GB top-of-the-line drive was added later. I was apparently one of the first customers of this new drive; delivery took months. I bought a 5-year extended warranty. The drive died after about 3 years. When I called the dealer, no one answered the phone despite repeated calls over a period of 1-2 months. Eventually, the phone was disconnected. I guess they went out of business; so much for the 5-year warranty. |
| WangDAT tape | The 4mm DAT drive was purchased to take over backup duty when we lost use of the TA81 1/2" tape drives. The WangDAT drive broke once or twice, but it did see pretty heavy use. |
| CMD CDU-710/TM SCSI controller | When we got the DAT tape drive, we needed a separate SCSI controller for it because the Dilog unit could not control tapes. The need for a second controller was disappointing at first, but from a reliability point of view, this may have been fortunate. |
The 8650 was the first machine on which I was really a system manager.