With the result that neither of the assistant directors was qualified for the new position!
Also, all "supervisors" were turned into "managers".
Getting used to a new director, and vice-versa, can be a trying experience. In this case we saw an extreme example when the Sigma suffered a hardware failure shortly after the new director arrived. It took unusually long to repair, and when one of the engineers decided being in all night was enough, he decided to go home to get some sleep (while other engineers continued diagnostic efforts). The director indicated this was not acceptable, and after a few more words, the engineer quit on the spot.
Wikipedia has an entry for Control Data Corporation here. CDC was one of the earliest pioneers of computer-aided instruction systems, called PLATO, which has a Wikipedia entry here. Some folks are working to preserve operable PLATO systems, see https://cyber1.org which involves running NOS on top of a Cyber emulator (courtesy of Tom Hunter, below). A PLATO history blog is here. UW was not involved in PLATO but it's an interesting subject to look back on, especially running it today on emulated hardware.
A fellow named Tom Hunter developed a Cyber emulator which he hoped to sell to the few remaining Cyber sites as an alternative to keeping their old mainframes running. A more recent check showed it's available at no cost under a GNU license. His web site is at http://www.control-data.info and it includes emulated-console screenshots and a good collection of photos.
Some folks in Germany have a collection of running CDC equipment, see https://cray-cyber.org.
It is also curious to note that a requirement of UW's RFP was two computers with identical instruction sets, yet the two CDC systems were not identical. The 730 had the optional "compare/move unit" that implemented instructions mostly used by Cobol programs such as decimal arithmetic. This was not an option on the 760, which would emulate these instructions faster than the 730 could execute them in hardware.
The Sigma 7 and CDC 6000 series were engineered and announced within less than a year of each other. Yet after a 10-year run with the Sigma, we purchased a system that was a direct descendant of the 6600, namely the Cyber 760. Though we gained a lot in several areas like speed and reliability, in some aspects we didn't (octal, 1960s architecture).
Many people consider the Cray-1 to be the first true "supercomputer." However, CDC (for whom Seymour Cray worked at the time) freely used that term in their advertising of the CDC 6000 series, for example in an ad in September 1967's CACM.
The CDC engineers all impressed me with their knowledge not only of the hardware, but even of the operating system. CDC was definitely dedicated to helping the customer. Frequently, parts needed to be shuttled up from Denver or Fort Collins; the Laramie and Fort Collins engineers would arrange a meet at Virginia Dale, about halfway, and hand over the part(s). This continued until one of them was accosted by the shotgun-wielding proprietor/resident who thought this was a homeless bum parked for the night; from then on, meets were done at the nearby rest area.
Along with the Cybers and peripherals was a 500k-word chunk of core memory called Extended Core Storage, ECS. This was used partly by programs as extra storage, and partly by NOS to coordinate operations between the two mainframes. It also indicated, distressingly quickly and loudly, when a fault occurred in the chilled water loop.
Cybers came with their own unique terminology, historically different from the rest of the industry. The Central Processor was the CP, not the CPU. The Peripheral Processors were PPs, small 12-bit processors grafted into the system to handle I/O (the CP did not have any I/O instructions). Central Memory was CM, 60 bits per word. Most confusing, some terms were variable depending on context. Sometimes a "byte" was 12 bits, sometimes 8, sometimes 6. A "record" had a different meaning to NOS than to the Cyber Record Manager (CRM).
When the county moved into the new hospital around 1976(?), they quite literally abandoned the old building. It was originally built in 1917, with new wings in 1937 and 1957. It sat empty for over a year until the University acquired it, at which time they found that many of the pipes had frozen and cracked. The fix in some areas was to hang new copper pipe on the walls, which was done without any circulation for the hot water. As a result, parts of the building took 10 minutes of full-blast running before hot water showed up. And in the summer, when the steam heat is shut off, there is no hot water (except in the operator break room, fed by an independent heater that was installed to supply a film processor for the FR80/A).
One thing I missed in the Ivinson Building was the smell of rain. In the Bio Sci building, we were in the basement and hence had no windows. But the central air conditioning system would draw in outside air and distribute it all over, and when we got a summer rain shower the distinctive smell would tell you that it was raining outside. Ivinson has terrible heat (many rooms are plumbed "in series" with consequent fighting over who controls the manual valve) and outside of the machine room, no cooling.
This isn't even computing, but one day UW decided to mount bird houses around campus, and somebody in BioSci was to build them. He took them outside to varnish, presumably to avoid bothering people with the fumes. But he did this right next to the building air intake and thus subjected *everybody in the building* to the fumes.
We obtained a set of bit-twiddling routines written in assembly-language (COMPASS) and hand-optimized for Cybers such as the 760, which had parallel functional units. These were general-purpose routines, and I felt that for specific purposes such as packing/unpacking 8-bit bytes the performance could be better. Using these routines as a starting point, I wrote some COMPASS routines that were more specialized and spent a few weeks, off and on, timing and optimizing them on the 760. As a result, I believe the new routines were about twice as fast as the general-purpose ones. Once I was satisfied that I could not do any better, a second test was made by slapping together some Fortran code and giving the compiler a chance to do its best optimization; this took about 20 minutes to write, mostly to type in all the lines of shifts/ands/ors and to compute the constants. It was a complete surprise to find that the Fortran results were 3 times faster than my best COMPASS! I asked for a machine language listing, and once I figured out what the heck the compiler was doing, I could only grin and mumble "son of a bitch!" That was around 1982 or 1983, and I don't believe I have written any significant assembly language since. CDC's Fortran compilers were way ahead of anything I'd even heard of in terms of optimization; only in 1994 can I say that Digital's are at about the same level.
In 1982 I bought a Mazda RX-7 and after a while noticed the odometer sitting at 3777 and thought "Hey, it's about to turn over to 4000." Obviously I had Cyber on the brain. Brad Thomas tells me of a friend who added up a bank deposit slip, but the teller came up with a different total; after they each came up with their own answer 3 times in a row, the friend suddenly realized he'd added it up in octal.
There was a strange instruction on Cybers called the Population Count instruction. It returned the number of "1" bits in the argument. It was rumored that this instruction was added to Cybers by the designer, Seymour Cray, at the request of the National Security Agency (NSA). There is some validity to this rumor, but it may never be proven. It was found to be handy, however, in the Versatec rasterization software. In order to see if a scan line is all white (all zero bits) it would seem a simple matter to just compare each word with zero. But since Cybers also had negative zero (all bits on), and since Fortran would indicate positive zero equal to negative zero, this test would fail. The "NSA" instruction was used instead and gave accurate results.
The Cybers had interesting consoles that would stroke-draw characters on two logical screens; older systems had used two separate CRTs. Since they were not raster scanned, they would flicker badly if you displayed lots of text but otherwise were very readable and extremely nice to use because they constantly showed you what was going on, in real time. On the other hand, the keyboards were terrible. The digits were in the usual position at the top but went 0 through 9 instead of 1 through 0. The CR key was in the lower left, where Shift usually is. Since they were based on CDC's Display Code, there was upper case only and no shift was needed. In the upper right were two blank keys, called "left blank" and "right blank." What they did was context-dependent, and can be compared to programmable function keys, like the "keypad" on Digital's VT-series terminals. The keyboards were also a pain because they had "zero key rollover" meaning you had to completely release one key before depressing the next; most keyboards allow at least one key to remain down while the next is pressed. So you had to develop an exaggerated sort of typing style or lose keystrokes. There was also no tactile or audible feedback from the keys. One nice thing, since the consoles were driven by one of the PPs, they would usually continue to function even if everything else was locked up.
Depending on what went wrong, operators would sometimes get a flashing message "PP HUNG" or "HUNG PP" and the distinction was significant. A few female operators did not appreciate being asked how their PP was hung.
There were a few visual "toys" for the consoles such as one that flew Snoopy as the Red Baron across the screens. Another would pop up two eyes that looked each way, then one blinked. This reportedly startled an operator at CDC when somebody scheduled it to run on its own during graveyard shift. At UCLA, day shift operators pulled a similar stunt on the lone graveyard operator by placing huge fake eyeballs, teeth, and a rolled-up tongue inside one of their IBM printers. When the printer ran out of paper, it automatically opened up, the teeth and eyes dropped into view, and the tongue unrolled on the floor.
As with the Sigma, much of the development and upgrade programming of the operating system had to be done at odd hours of the day. Before releasing a new version of the system, the sysprogs would spend weeks at the consoles, between 03:00 and 06:00 or so, testing modifications and generally trying to avoid screwups. Staying awake was sometimes a problem and we'd generally get a little weird. Because there were two systems and consoles, two of us could work at the same time without interfering very much. Brad Thomas and I would sometimes recite Monty Python sketches at each other, much to the annoyance of Teri Oursler who could not stand Monty Python.
Cybers were genuine mainframes in every sense. Including power requirements. Building reliable power supplies for such high power was not easy at the time, and CDC took an elegantly brutish approach. First, using 3-phase power and full-wave rectifying it can greatly reduce the filtering requirements because the ripple is at 6 times line frequency and thus much easier to filter. Also, the raw ripple doesn't even go down to zero volts and back like single-phase rectified AC. Second, one can reduce the filtering requirements as well as transformer sizes by using 400-Hz power instead of 60-Hz. Such power is often used in aircraft and some military applications, so components were available. Including the three 400-cycle motor-generators we had to install in the basement (one per mainframe and one spare). This now meant you could build 100-ampere power supplies with basically three components (transformer, bridge rectifier, filter capacitor). Crude compared to switching power supplies that came along later, but there was no question of reliability with 3 simple parts.
To supply the power, the power company had to put in a new pad-mounted 13kV transformer. When we put in the second chiller, they had to bring in a second transformer.
A direct consequence of consuming so much power was the need for large cooling systems, of which we eventually installed two. Both Cybers, and the ECS unit, were cooled by looping chilled water through the mainframe (or a condenser external to the mainframe). The IBM 308x systems that came along later were similarly cooled. At other times all equipment was air cooled.
To obtain lower-case characters, and other special characters, CDC invented "6/12 ASCII" (or "6/12 display code") in which they coded some characters as 6-bit entities, others as 12 bit; not all their software understood 6/12, and the two sets were marginally incompatible. The user address space was 128K words, and the memory was not paged or what most anybody would call virtual. The systems did not have any interrupts per se, but did have a Central Processor and up to 12 Peripheral Processors that themselves were 12-bit I/O processors. The 760 was about a 10-12 MIP system. Though fast and quite an improvement, it seems that in 1978 Cybers were already dead-end machines. CDC did endeavor to catch up with the industry, but more on that later.
I note with some sadness that the idea of 6/12 "ASCII" has been re-invented by the computing industry, which now addresses multiple character sets such as Chinese and Japanese, by using multiple bytes per character (UTF-8, Unicode, and so on).
In order to help programmers use 6/12 ASCII or do other special functions during output, CDC decided to allow embedding certain "control codes" within text, as long as you did it at the beginning of a CM word. Typically these codes began with a colon (character code 00). So, for example, if you had the misfortune to want to print or display a line of text that began with a colon, you usually ended up with output that you didn't expect.
As part of the Sigma-to-Cyber transition, I wrote several utilities to read Sigma labeled tapes, which were not at all ANSI standard labeled format. This had to include conversion of character data from EBCDIC to Display Code as well as binary data to Cyber 170 formats. This is one of the areas where lots of bit-twiddling had to be done. In the Sigma era it was common for system programmers to know a lot about internal data structures, and Xerox had documented them fairly well. So had CDC, but those days seem to be gone now; Digital won't even document the format of their MAIL.MAI file.
As a comparison to today's typical disk storage, on the Cybers we would dump and reload the entire file system each week to defragment it. It took about 3-4 hours for the whole process. This also gave us great confidence in our backup procedures! We did the same thing back on CP-V, and it took about the same amount of time though the storage was around 10% that of the Cybers. On VMS we almost couldn't dump/reload *one* disk, but I partly blame this on gross inefficiencies in DEC's BACKUP utility.
NOS had an interesting concept called the "dayfile." This was basically a log of all the commands a job/session executed, along with whatever other information the programs/compilers/utilities felt like including. It was time stamped, which helped a lot. Each job or session had its own dayfile, and in the case of a batch job would print at the end; this was nice because a multi-step job's output would not be cluttered with the commands. NOS also kept a system dayfile which was a merged chronological copy of all the user dayfiles (messages *could* be written exclusively to one or the other, though many went to both) and this was a help in tracking pests. A separate accounting dayfile was kept as well.
The accounting dayfile was processed by locally-written Fortran programs, and demonstrated a subtle programming oversight that had consequences long after they were written. The accounting dayfiles were processed and resulted in files we decided to name something like "ssddd" where "ss" was the system id (76 for the 760, 73 for the 730, and 83 for the 835/840) and "ddd" was the Julian day of the year. I can't remember if the year was in there also. The programs were written in late spring or summer, and ran fine until January 1 of the next year. At that time, the Julian-day code encoded the date as " 1" which meant it tried to create a file, for example, "76 1" which was illegal because of the embedded blanks in the file name. The cure was simple: change the FORMAT specifier from I3 to I3.3. But it certainly surprised us.
NOS showed its heritage by supporting an older control language called Kronos Control Language (KCL), which the manuals always claimed would go away some day. Imagine our surprise when it actually did!
Benchmark: In November of 1983 we upgraded the dial-in modem pool from 300 baud to 1200 baud. In February of 1987 the pool was upgraded to 2400 baud.
Random story: One of our operators was reading our operators guide called the Cybible, and found part of a paragraph he knew was not correct, and proceeded to completely obliterate it with a black felt tip marker. Then, on further reflection, he realized it *was* correct and circled the black section and labeled it "OK".
In a desperate/bold (take your pick) move to upgrade service at no cost, we entered a limited partnership with CDC to help them develop CDCnet, their initial ethernet venture. We donated two programmers who went to work for CDC in Minneapolis for one year. In exchange, we received several pieces of hardware called Device Interfaces (DIs). Some interfaced the mainframes to an ethernet cable, and others were terminal servers. Because there was no campus network yet, the terminal servers went straight into the existing Gandalf PACX. The two employees wrote a couple of Terminal Interface Programs (TIPs) and were also responsible for an additional year of maintenance on the TIPs after returning to Laramie. During some of the CDCnet development, UW would upgrade NOS every week or two; this is known in the trade as "hectic" and was a challenge to streamline the process of building new deadstart tapes from a raw release. In all, the effort fell flat because we didn't spend much more time with CDC hardware, and didn't have any real network yet. This was around 1984-1986.
We all got a chuckle out of the cornerstone of the building as it relates to computing. When the building was demolished, this cornerstone was saved and made part of a "memorial":
DEDICATED IN THE NAME OF HUMANITY TO THE RELIEF OF SUFFERING JUNE 7, 1916
To protect the computing equipment, a Halon fire extinguisher system was installed (a smaller system had also been installed in the old Bio Sci center). This was a large system with two big tanks in the basement, and plumbing in both the ceiling and floor to discharge the Halon. It also shut down the air handlers as well as the power for the Cybers. This system discharged twice. The first was a test mandated by our insurance company, which was carefully monitored. I was there to observe it, and can testify that a Halon discharge is pretty exciting to watch. When it was done, we walked into the room to check for damage (none). Halon, being a dense gas, will lower your voice which is the opposite of helium. After maybe ten minutes I started feeling a little light-headed and decided to leave the room. The second discharge was a malfunction and surprised lots of people. There had been a power failure; when the power came back on the Halon simply decided to discharge with no warning (there's supposed to be a warning period first, confirmed by the intentional test). Two workers from Physical Plant were in the basement at the time and when the Halon tanks discharged and started jumping around in their restraining straps, the two decided to leave quickly. Our on-site Digital engineer was in the computer room, and ran out as fast as he could because he'd heard horror stories about the evils of Halon poisoning (all false, but he didn't want to hear about that). Later the same morning he still refused to go into the room, knowing there were deadly gasses; he then tried to light a cigarette in the hallway, but it wouldn't light because there was enough Halon in the hall to prevent it; we kidded him about his fear of Halon.
The NOS file system was unique. There were Permanent Files that stuck around on disk from job to job. Distinctly separate were Local Files that belonged just to a particular job. So, to compile a program, you had to GET the file (copy from permanent to local), compile it (the object code would be a local file), and run it (it was implicitly linked in CM). If the program generated a result file, the job had to SAVE the local file (copy to permanent storage). This was nice because a job that aborted did not typically mess up permanent files; it had to complete to get to the SAVE statements, depending on how it was written. The files that you had to GET and SAVE were called Indirect Access files. This did not work well for very large files, such as databases. So there were also Direct Access files which a job could ATTACH and RETURN, allowing update in-place. Whether to make a file indirect or direct would depend on usage and size, a decision left up to the programmer. We saw huge indirect files and trivial direct files.
The files themselves obviously held data, but there were two levels of "markers" that could be used as separators. The first level was called EOR (End Of Record), a very unfortunate use of the word "record" that does not match common usage (or even usage by the Cyber Record Manager). The second was EOF (End Of File), again an unfortunate use of the word "file" and definitely not the end of the file. The absolute very end of a file was called EOI (End Of Information). A file could contain any number of EORs and/or EOFs in any sequence, though most applications used EORs, and sparingly at that. One might compare these with magnetic tape, with EORs analogous to interblock gaps, EOFs to tape marks, and EOI to the end of meaningful data. EOR/EOF/EOI also had meaning on card decks, with oddball multipunches such as 6/7/8/9 for EOI.
One of the larger mistakes we made was picking a default character coding for labeled tapes. On the Sigma, the only real choice was EBCDIC. CP-V only grudgingly supported ANSI labels, and only very late in life. Having EBCDIC on the brain, we set NOS to use EBCDIC by default. When it came time to migrate to VMS, all the user mag tapes were unlabeled as far as VMS could tell, which made the transition a bit harder.
Shortly before shutting down the Sigma, I re-assembled all of the operating system modules and routed the listings to tape. Years later, when we acquired the FR80/A microfilmer, I copied these to 48X microfiche.
Before the Sigma was retired, a final save of all disk files was made to tape, to help out users who might have *thought* they transferred everything they would need but were wrong, and those users who simply weren't aware a change was being made (I refered to these as faculty on sabbatical on Pluto). We also dumped to tape the contents of all the user-owned removable disk packs.
I never did understand this, but we did announce that all disk files would be saved on tape for later restoration, while we did *not* state that we were going to dump the private packs to tape. Perhaps there was worry about accessing user "private" information. It seemed to me to do little good to save private packs and tell nobody we did so. In one case a user mentioned to me that he had spent quite a bit of time re-creating such data (that he had not saved prior to the Sigma's death), and was quite irate when I told him we had that data on tape.
A small curiosity is that the CDC line printers were 136 columns. The rest of the industry had settled on 132 columns, no doubt a number chosen by IBM that everybody else except CDC chose to copy. I don't know why CDC used 136 but it probably dates way back to their earliest systems.
When we moved out of the Biological Sciences building, the science library expanded into what used to be the machine room, and inherited our old vault. They placed valuable volumes in it, those that required limited circulation, and other items. One day somebody locked the door and nobody there remembered the combination. They called over to us, hoping we might have a record of it, but we couldn't help them. I understand they had to call a locksmith to open it up. Shortly after that we "re-acquired" the vault, to be used as offsite storage for backup tapes, and the library vacated it. About two weeks later I stumbled across a piece of paper with the old combination on it.
One day I received a call from the administrative application programmers, explaining that they had found an apparent bug in CDC's Cobol compiler. One of them had written a program to correct a previous problem that caused a field in some records in a database to get negated. This new program was a one-time fixer-upper, and it read each record, correcting the field if needed, and then wrote it to a new file. It was a very simple program but the records would have the field trashed rather than re-negated. Perhaps because I never really learned Cobol, I looked up many of the statements in the manual to be sure I understood them. The key statement looked like: <if needed> MULTIPLY FIELDX BY NEG1 where NEG1 was defined as a constant, valued -1. The full syntax, though, is: MULTIPLY a BY b YIELDING c and if you omit the YIELDING, the result replaces "b". So after the first multiply, NEG1 was replaced. I pointed this out to the programmers, who thanked me.
One of the system programmers didn't show up for work one morning. After lunch the manager called to see if he was OK, and was told that he was fine but that he decided to quit. This was the only time I've ever seen an employee give negative four hours notice.
One of our managers, who started as a programmer about the same time I did, was very worried about protecting a 9-track tape. We had the convention that operators would never write-enable a tape unless the console said to (based on the user request), but if the tape had a circular red sticker on it, then never put in the write ring no matter what. This person placed red stickers all over the back of the tape, intentionally blocking the slot for the write ring. But as far as the tape drive was concerned, this was equivalent to a write ring because the mechanical sensor could not detect the slot! Luckily for him, NOS would object if a user requested a tape for read-only access but detected a write ring (or if the tape was to be written on but no ring was present), so NOS complained about the situation and thus brought the folly to our attention.
Each Cyber had a control panel for environmental control, called the TMPC (Temperature/Monitor/Power Controller?). It had lights that showed most possible errors, such as chassis 3 high temp, chassis 1 low temp, dew point alarm, dew point shutdown, power faults, and so on. Each of these conditions matched a bit in the CP's status/control register. Depending on the severity of a condition, it might be a warning, or an error that triggered a system shutdown. On this panel there was a push button marked "lamp test", and well above the button (due to the design of the panel) a small yellow sticker warning that the button is to be pressed during maintenance periods only. The reason for this is that it tested the lamps by simulating every error condition the panel could handle! In the process, the central processor would see every register bit come on, panic, and shut down. Twice, the operators pressed this button and unwittingly shut down the 760. In addition, after both of these events, the operations manager did it while teaching people how to handle surprises in the air conditioning system.
Once I was looking over the source code for a local utility called SUPER and found one line with an incomprehensible comment. The programmer who had written it had left. After some head scratching, my manager finally figured out it had been typed blindly, with the right hand shifted one column to the right on the keyboard. So we were able to "decipher" it.
As we had done in the Sigma era, the University assisted Albany County in counting election ballots. These were supposed to be standard punched cards but in one election our card reader promptly shredded every one it was fed. It was determined that they had been stored in a very damp environment which caused them to swell in thickness and the card reader's throat plate would not let them pass. The solution was to temporarily mis-adjust the card reader to allow the thick cards through. I'd like to think the county was also advised regarding proper storage.
I'm pretty certain that the main driving force for the FR80/A, outside of our own director, was a certain professor in Physics who was quite influential and had a way of getting juicy research grants. Aside from being involved in the initial talks, he was almost the only person who ever used 24X color microfiche. And, strangely enough, the director had insisted that 24X color microfiche should be our top priority with 2-hour turnaround max. This meant leaving 35mm slides for the evening shift. But 99.9% of all work done was 35mm slides.
We did do a few movies, the most notable being an animated display of data from an atmospheric survey satellite. I fiddled around with the Mandelbrot Set which was all the rage at that time.
The FR80/A was quite unique. The CPU was a "home built" (by Triple-I) version of a DEC PDP-15 with extra instructions for controlling the electron beam circuitry. It could do either vector or raster, natively. That is, in vector mode, it actually drew vectors. In raster mode, it actually scanned raster lines while varying the intensity. The main CRT, called the Photographic Light Source (PLS), was a very expensive but precise white-phosphor tube which was focused using a small 60X microscope. III put the color filters into the cameras, behind the lens at the rear conjugate so that imperfections in the filters would smear and thus not influence the final product. Jack Bennet gave me a nice long story about how they designed their own lenses, purchased a 12-year supply of one "melt" of glass, and always had that particular lens made from that particular melt. "Our honorable competition goes out and buys off-the-shelf Nikon lenses," he said. I later looked at our cameras and noted three of the four had Nikons (to be fair, two of these were high-quality enlarger lenses and one was built by Nikon specifically for COM use). Apparently the story only applied to their "big" cameras, as III was primarily in the typesetting business. The console monitor was a large but simple X/Y monochrome display with a long persistence phosphor, which was slaved to the PLS circuitry. Thus, whatever the PLS was doing the monitor would show as well (at one intensity level), and by disabling the PLS the monitor would be used for displaying text or other graphics without exposing film; like the Cyber consoles, it would flicker badly if you displayed too much text. Input and hardcopy output was via a Teletype model 43.
Over the years we ate up several of the FR80/A disk drives, possibly due to our high altitude (7200 feet). We also blew out many of the 20-kV power supplies, and a distressing number of PLSs. This made us glad for the service contract, though it still cost a lot of money. I was never very impressed with the quality of their software, though they did fix most of the bugs I reported.
What I can't remember at this moment is how many CPUs the various Cybers had. I believe the 730 had a single CPU, and that the 840 had two CPUs. I'm not sure if the 835 had two.
When the 835 arrived, the 730 was first removed and stored. Later it was hauled up our cumbersome loading ramp by a tow truck's winch. One set of 730 wheels fell into an expansion joint and needed quite a tug to proceed; but the tow truck operator had not set the parking brake, and the truck and 730 both rolled DOWN the ramp. The truck, being at an angle, struck the retaining wall and stopped. At that instant, the 730 struck the brick wall at the base of the loading area and the sideways jerk from the tow cable caused it to fall over onto the concrete. One of the CDC engineers was almost crushed in the mishap. The 730 was declared a total loss; at that point it was CDC's property, so arguments over whose fault it was went on between CDC, the tow truck, and the moving company that had hired the tow truck. Only then did I realize the serial number of this system was 911. Somebody, I believe it was Dave Haas, took some pictures. I scanned the proof sheet at 200 DPI (here) and at 300 DPI (here).
Before we received the 840, I was sent off to CDC to be certain that our boot tape (called the deadstart tape) would actually work on the 840. We didn't want any surprises. CDC had an interesting demo system which could become an 840, 850, or 860 at the flip of two toggle switches. The story I heard was that these three systems were basically the same hardware, just different microcode. The 840 microcode had lots of no-ops embedded, the 850 had fewer, and the 860 had none. To keep a "pirate" site from running stolen 860 microcode on an 840, a few of the address bus bits were swapped around between the three models. So, to upgrade an 840, one had to make a small hardware change (move some of the wire-wrapped lines) as well as obtain new microcode. So, it was easy to make a demo system that could become any of the three models. (There may have been a bit more than this when upgrading, like tuning and "auditing" critical timing paths).
One day we tried to spin down one of the model 844 disk drives but it wouldn't! The heads refused to retract, and the spindle motor would not shut down unless the heads were retracted. The engineers scratched their heads. If they simply shut down the power, it is *supposed* to retract the heads, but depending on what was wrong, it might not. Throughout my career I've heard vendors claim "our disk drive will retract the heads if power is removed" yet I've seen examples where a failure was blamed on power loss. So, rather than risking a head crash, they looked over the logic diagrams and even called CDC in Minneapolis to get a consensus on which of the many circuit breakers to trip first in order to ensure a head retraction (possibly manually), before powering off the drive for repair. It worked fine, and I was again impressed with CDC's efforts to give the customer good service.
We experimented with NOS/VE to see if that was the path of the future for UW. We found it a disappointment. The command language was cumbersome, though consistently so. The performance was not good, and the software was not "all there" and suffered from the usual reliability problems of new products. We ended up shutting down NOS/VE without ever releasing it to our users.
One interesting thing about NOS/VE was that any executable was automatically shared, as long as it was part of a library. In contrast, on VMS to make an image shared, the system manager must run the INSTALL utility.
A technical problem with the 835 and 840 was the fact that they had an instruction pipeline which prevented self-modifying code from executing correctly. Older compilers, and some assembly code, used this dangerous technique as a normal method, not knowing that future systems would render this invalid. If this was suspected to be causing incorrect results, it was easy to turn off for comparison on a per-job basis, by the user (at the expense of increased run time). I heard of similar problems on the Xerox Sigma 9, which also had an instruction prefetch.
At some point in NOS' lifetime, CDC hired a consultant to see what they could do to make it more user-friendly. One of the most visible changes centered around the variety of "illegal" messages such as "illegal control statement"; the word "illegal" was changed everywhere to "incorrect."
One way CDC made a living was to compete in the IBM peripherals market, mainly disk drives. When IBM developed Winchester technology, CDC quickly went to work reverse-engineering it to come out with their own models. Each time this happened in the past, they also did the engineering to make new drives work on their own mainframes, seemingly as a side-effect since the market was so much smaller. A key issue of the Winchester drives is that the heads are not withdrawn for a spin-up or spin-down, they land on the surface. To make this work, IBM had come up with an extremely thin film surface lubricant, which CDC could not quickly perfect or copy. By the time they did bring the disk drives to market, IBM had already slashed their own prices and CDC could barely compete, if at all. To the CDC Cyber customers, these disk drives were known as the model 885 and had two 600-megabyte spindles per unit. We had two 885s, or 4 spindles. Apparently the lube caused some more problems. If the drives sat spinning on one cylinder for too long, the lube would "squash" out from under the head and form small ridges on either side. If you then did seeks back and forth across this, the heads would wobble, like water skiing across the boat's wake. In some cases this caused head crashes. The short-term fix was to modify the operating system to occasionally do random seeks on idle disks. The long-term solution was to incorporate this into the controlware. I believe many modern disks do this, though not necessarily for the same reason.
The initial RPM had 4 megabytes of memory, which proved to be inadequate, and it was upgraded to 8 megabytes. The only user who exceeded this with any frequency was a UW artist, in which case she simply re-ran her programs with slightly different parameters. When the new plotter was acquired, Versatec accepted the old unit for inclusion in their in-house museum because they didn't have any examples of units that old. The 7424 was released to users in late 1986.
Due to a lack of adequate maintenance, the plotter's quality steadily declined. On a few occasions we even hired Versatec to come in and improve it, which they couldn't. As the quality went down, users stopped using it. Then, management said "look, nobody is using it, so we can just shut it down and stop offering that service."
There was a joke memo circulated around the CDC fraternity which we often quoted by simply saying "see figure 1". I believe it may have originated within Digital Equipment Corporation (see https://www.dourish.com/goodies/see-figure-1.html), CDC and IBM both adapted it to their terminology and letterheads as did AT&T and probably others.
One day the Cyber 760 started acting strangely. Subsystems hanging or aborting, programs behaving strangely. NOS was moderately unique in that it allowed running most hardware diagnostics under NOS, not just standalone. After firing up some of these programs, it was discovered that there was a hardware fault in one of the floating-point instructions, at which point we immediately took the system down for repair. After that, we fired up these diagnostics for a few seconds every hour or so, using a scheduling package from CDC's engineering group. That package was annoying because if you set the system time back even 1 second, it would conclude that almost 24 hours had elapsed and fired off a day's worth of jobs!
It also pointed out the frequently-tried futility of setting non-interactive priorities lower than interactive. Problem is, if there is enough interactive usage, a "hard" prioritization scheme will completely lock out the lower-priority usage. One day I looked at the 730 and noticed that there were dozens of the quick hardware diagnostic jobs, all of which had made zero progress because their default CP priority was below that of interactive users. We tried this on CP-V, NOS, and later VMS, each time with the result that it wasn't a good idea.
Have you ever seen an "aperture card?" This is a standard-sized computer punched card that has about a one-inch hole in the middle, into which is glued a piece of microfilm. This allowed filing documents/blueprints on cards, which could be sorted/collated based on the usual punched holes, or placed in a microfilm viewer and/or reproduced. One day somebody from the Air Force base in Cheyenne called, wondering if we could read the cards (of course this meant the punched data, not the images). This was a new one on us, so we suggested they bring some over and we'd try. The logic in a CDC 405 card reader did not like the hole in the middle, as it set off the "end of card" photodetectors. Our resident CDC engineer, Ken Aksamit, tried several quick logic changes to make the reader accept the cards (hey kids, try that on your PC!) but it wasn't a simple task. In the end we gave up, but it was an interesting experiment.
After we abandoned CDC, as the years went by, CDC was clearly in financial difficulty. They would occasionally sell off their successful and profitable divisions (CDC Credit Corporation and the magnetic peripherals division are examples) in order to shore up the "core business" which was mainframes, in an era when mainframes were thought to be on the way out. Eventually CDC folded, and the last vestiges of the computer business became Control Data Systems which basically is a value-added reseller of other's workstations. It was also sad to see Digital Equipment Corporation doing some of the same tricks (e.g. selling off their disk drive division in Colorado Springs to Quantum, 1994) before disappearing.
A few references: