The Cyber Era

Almost immediately, the new director made several changes. One of the more significant was the re-structuring of the two assistant director positions into a single position.

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.

The new director started a lengthy and complex project to define computing requirements, issue and evaluate an RFP, and select a "winner". One of the requirements was two separate systems for redundancy, with identical instruction sets for compatibility. One system was to be "slow and small," relatively speaking, and the other "fast and big". This would allow large-scale computing, without spending the money for two expensive systems. Several million dollars (6?) was made available by the state legislature. Eventually, around mid-1978, the decision was made to purchase a Cyber 730 and a Cyber 760 from Control Data Corporation (actually the bid was for a model 173 and 175 respectively, but CDC changed the model numbers between bid and delivery).

Wikipedia has an entry for Control Data Corporation here. CDC was one of the earliest pioneers of computer-aided instruction systems, called PLATO, which also has a Wikipedia entry here. Some folks are working to preserve operable PLATO systems, see http://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 has developed a Cyber simulator which he hopes to sell to the few remaining Cyber sites as an alternative to keeping their old mainframes running. His web site is at http://members.iinet.net.au/~tom-hunter and it includes simulated-console screenshots and a good collection of photos.

Some folks in Germany have a collection of running CDC equipment, see http://www.cray-cyber.org.

It is also curious to note that a requirement of the 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.

In the past, UW had hired in-house maintenance engineers to save the cost of vendor-contracted maintenance. With the Cybers, this policy was reversed and CDC supplied Laramie-resident engineers, with a UW-donated office in the Ivinson building. For some time there were three on-site engineers though it should be noted that CDC had a few other small maintenance contracts in the region, and the Laramie crew sometimes covered for the engineers in Fort Collins where CSU also had Cybers (even a Cyber 205 supercomputer for a few years). CDC cut this back to two engineers, and eventually just one when it became clear UW would not continue to be a CDC customer.

The CDC engineers all impressed me with their knowledge not only of the hardware, but even of the operating system software. 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.

The Cybers were interesting systems in that they were even then "throwback" systems. They used 60-bit words, octal arithmetic, one's-complement arithmetic (which meant there as a negative zero as well as a positive zero, and they were sometimes not equal to each other), non-hierarchical file systems with seven-character file names, and used character coding unique to CDC (not BCD, not ASCII, and not EBCDIC, it was called "display code"). The fact that the Cyber 170 architecture used a word length that was not a power of two caused a few problems when programming at the bit level, and dealing with the 8-bit bytes that everybody else used (e.g. the AMS systems and offline plotters) made for an interesting challenge.

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).

At the same time we were searching for new computers, it was felt that new facilities were needed. Though the center had moved into the new Bio Sci building less than 10 years before, there were two problems. The first was that the staff had grown, with even more personnel expected; so there was inadequate office space to house the employees. Secondly, the computer room was not quite big enough to house both the Cybers and the Sigma/1401, which would be needed during the transition period. No money was available to build a new building, and the only available space was in the former county hospital, already University property and known as the Ivinsion building. A large section was remodeled, with much of the work being done on the basement to turn it into a large computer room. This work was done in early/mid 1979. In many respects the "new" facilities were a let-down. The building was much older (one wing dates to 1917), did not have central air, and the machine room was separate from the store room, with a ramp to gain access to the raised floor. There were a few strange problems running communications lines under Ivinson avenue, which was under city control and the city had long before given exclusive access to utility companies; UW could not run its own cables through its own conduits between its own buildings!

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 take 10 minutes of full-blast running before hot water shows 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 miss in the Ivinson Building is 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 suck 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.

OK, 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. Must have been a PhD.

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 mods 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 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 this writing (early 1995) everything is air cooled except the air handlers themselves.

To obtain lower-case characters, and other special characters, CDC invented "6/12 ASCII" 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 great sadness that the terrible idea of 6/12 "ASCII" has been re-invented by the computing industry, which is now attempting to address multiple character sets such as Chinese and Japanese, by using multiple bytes per character. Sigh.

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. Today we almost can't dump/reload *one* disk on VMS, but I partly blame this on gross inefficiencies in the 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 likely will cause big problems on January 1 2000. 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. I'm sure a few programs will fail (globally) on 1/1/2000 (an interesting Web page on this topic is http://www.year2000.com/.

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 one release, 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 they were 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 get a chuckle out of the cornerstone of the original building, still in place (ed: the Ivinson Building was demolished in 2011), as it relates to computing:

									 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 before the "ozone hole" problems were known. 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 so far. The first was a test mandated by our insurance company, which was carefully monitored. I was here 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; 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 chided him quite well over that!

The NOS file system was quite 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.

The Cyber 730 was installed by September 1979. The 760 was installed in February/March of 1980, and the Sigma 7 was finally retired from service on June 1. The Sigma and 1401 were used as trade-ins on the CDC equipment; CDC disposed of the 1401 via the landfill, and the Sigma was sold by CDC to a dealer specializing in used Xerox equipment. The former computer center offices were quickly taken over by Duplicating, and the machine room was taken over by the Science Library.

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 usually refer 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.

The change to CDC presented performance and reliability upgrades that were simply startling, especially to old-time Sigma programmers. One thing that CDC definitely did right was build hardware. Most of their equipment bordered on being masterpieces of both mechanical and electronic engineering. The tape drives were much faster, and the jump from 800 bpi to 6250 bpi was outstanding. After a few years, one of the CDC model 580 line printers was upgraded with a 96-character train (late 1984). The card readers were fast. The CPUs were fast. It was a real eye-opening experience, dulled only by the extreme workload of converting software or just raw concepts from the ancient systems to the Cybers, and the annoyance of working within new constraints that weren't there before. But the increase in computing was over an order of magnitude.

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.

Communications equipment was changed during this time. Most lines to the Sigma's front-end were leased lines with dedicated modems on each end. With the Cybers, a Gandalf PACX unit was installed in front of CDC's front-ends (Network Processing Units) which allowed users to easily select which computer to connect to (Sigma, Cybers, AMSs) and to select the desired baud rate as well.

Because there was no direct interface available to connect the Versatec plotter to a Cyber, a tape drive and controller were purchased and the plotter was run as an offline device via 9-track 1600 bpi tapes.

During this time, an alliance was formed between the University and the seven community colleges throughout the state, called the Wyoming Higher Education Computer Network (WHECN). The basic idea was that the University would act as a central maintenance point for college hardware. At that time, both UW and the colleges used Microdata minicomputers for administrative computing; the colleges used Harris minis for academic computing, but would have access to UW's Cybers. If a college computer failed, UW engineers would first consult via phone to attempt a resolution. Failing that, a "hot spare" system would be loaded into a van and driven to the college; if the engineer could not quickly fix the college's system it would be swapped, and the broken system taken back to UW for repair.

As noted, the Cybers used an antiquated architecture. CDC was way behind the industry which had long before adopted hexadecimal twos-complement arithmetic, ASCII character coding, much larger address spaces, and hierarchical file storage. In an attempt to catch up, CDC designed a completely new Cyber 180 architecture that included the ability to imitate the older Cyber 170 architecture. This included a new operating system called NOS/VE (NOS Virtual Environment). Unfortunately these were still large mainframe systems in a world going to smaller packages, and NOS/VE was a poor performer initially and not a very friendly system at that. It would be interesting to see what would have happened if CDC had at least ported a true Unix (AT&T or Berkeley) to the 180s instead of writing their own operating system from scratch.

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. However, 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 the 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 -4 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.

Around 1983 a color microfilm system was acquired, a model FR80/A from Information International Incorporated (III, pronounced "triple-I"). This was a very capable system, but finicky. We purchased it with the ability to do 24X and 42X color microfiche, 42X and 48X B&W microfiche, 35mm and 16mm movies (B&W or color), and 35mm slides (B&W or color). It was fed via 9-track tapes. Initially we did our own color film processing right in the building, but this was later retired and a smaller processor was installed in Photo Services in Knight Hall. Around 1992 the FR80/A was replaced with a LaserGraphics system to do just slides.

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" version of a PDP-15 with extra instructions for controlling the electron beam logic. It could do either vector or raster, "native". 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. It was focused using a small 60X microscope. III put the color filters into the cameras, behind the lens at the "rear conjugate" so that any 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 they had Nikons! 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 the high altitude. 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.

Some time around mid-1984 the Cyber 730 was replaced with a Cyber 835. The 835 was a member of the new 180-series architecture, which featured 64-bit words, hexadecimal, ASCII, and virtual addressing; it was a contemporary machine. The 180 architecture also allowed running in 170-architecture mode. Not by emulation, which would be slow, but by actually *being* a 170-series implementation as well as a 180. In other words it was "bilingual". This allowed a site to acquire a system and to run their old software in 170 mode, and run/develop/test new applications in 180 mode under the new operating system called NOS/VE (NOS, Virtual Environment). Unfortunately the 835 was serial number 1 and suffered intermittent failures that CDC could never fix. They eventually offered a reasonable upgrade path to a newer Cyber 840, which replaced the 835.

What I can't remember at this moment is how many CPUs the various cybers had. I do believe the 730 had a single CPU, and that the 840 had two CPUs. 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 almost got squashed 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.

The 760/730 combination was run in a mode called MultiMainFrame (MMF). This was roughly analogous to Digital's VMScluster concept and allowed a common file system. The 835 and 840 did not support this, and so the systems were split and maintained separately, though most of the work was in fact common to both. Moving files between the two systems then became a problem for some users, and one common method was to use the output queues because the queue management system did know about the "other" computer and how to efficiently move files from one to the other.

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 invented 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.

By early 1986, it was decided that the old off-line black&white Versatec needed to be replaced. Though it was hoped UW could obtain a color plotter, funding only allowed the replacement to be another off-line black&white Versatec plotter. The main improvements were 400dpi instead of 100dpi, and 24-inch paper instead of 20-inch. The new plotter, a model 7424, also initially had much better quality and contrast. It was driven by an RPM 850 rasterizer that allowed the rasterization to be offloaded from the host.

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 so 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."

One of the problems UW had with the Sigma was the bad experience of buying a computer from a company, watching that company get "swallowed" by a corporate giant even before delivery, and later seeing the remains of that computer company tossed aside and acquired by another company. This left a poor impression of buying a "non-name-brand" computer, and when it finally was time to replace the Sigma, there seemed a big push to buy a "real" computer, a big-name computer, from a company that wouldn't disappear or suffer a merger like that of SDS/XDS. Though that new computer would be purchased from Control Data Corporation, certainly a large and stable name in the industry, it was humorous to note that more Sigma 7s (just the 7s, not including all the other Sigma models) were sold than all the systems CDC ever sold. In the long run, it is interesting to observe that CDC suffered and basically closed down, showing that the urge to go with a big stable company did not work out anyway.

By late 1985 UW had connected to Bitnet, thus joining the outside world via e-mail and IBM-style file transfers. This indirectly gave us access to Arpanet, the predecessor of the Internet.

At the end of 1985 the Cyber's 7-track tape drive was removed from service, and most of the keypunches had also been removed. The Cyber card punch was supposed to be dropped in late 1986 but the inability of several Campus offices to switch to new applications on other platforms repeatedly delayed this. The punch was eventually dropped from the maintenance contract but remained connected until the Cybers were removed.

There was a joke memo circulated around the CDC fraternity which we often quoted by simply saying "see figure 1". I believe it actually originated within Digital Equipment Corporation, and CDC and IBM both adapted it to their terminology and letterheads.

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.

By now, it was becoming clear that CDC was a losing proposition. In a last gasp to stay in business, CDC published this ad to prove to everybody they knew what they were doing. Unfortunately, this phoney ad seemed to be closer to most people's perceptions. They were failing to maintain their user base, and had long been lagging behind the rest of the industry in many respects. The Cyber 180 series was a good attempt at playing catch-up but this was blunted by the non-acceptance of NOS/VE.

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's 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) and one wonders if DEC will recover, after watching CDC.

Around mid-1984 the division director resigned, and we once again went through the steps to find a new director. As happened the previous time, the new director would end up making significant changes. This time the Cybers would be removed, and newer, drastically different hardware would be installed to provide central academic computing.

Next: IBM makes an entrance