The Sigma Era

Around 1968 plans were made to replace the Philco with a newer, modern system. Some of the money would eventually come from an NSF grant, and some came from proceeds from the football team's recent Sugar Bowl loss (even though UW lost, a sizable chunk of money was brought home just for appearing). After the usual searches it was finally decided to acquire a Sigma 7 computer from Scientific Data Systems (SDS), a successful company in Santa Monica, California. The initial order was for a Sigma 5 using the non- legislative UW funding. It was installed in the basement of the new Physical Sciences building, a temporary situation until the Biological Sciences building could be completed. The 5 was operating by the end of summer, 1969. The grand opening and release to general UW service was December 2 1969. Operations were completely shut down for 8 days over Christmas.

A nice overall history of SDS is on Wikipedia, here.

After the Philco left the BioSci computer room, there were many floor tiles with holes that presented a hazard to people walking across the floor. After a while one of the operators got fed up with this, and traded these "holey" tiles with solid ones from under the unit record equipment such as the burster and card sorter. In the process he found a dead frog about 5 inches long, dried and petrified solid, that must have escaped from the biology stock room next door, or a lab upstairs. We had a bit of fun with it, like pointing it at users and saying "Behave, or *this* will happen to you!" Last I saw, somebody had put it in the mail box for the graveyard shift operator; he apparently didn't have a sense of humor.

My own involvement with SDS began in the Fall of 1967 as a junior in high school. The Los Angeles City school board was offering several extra-curricular classes like basket weaving on Tuesday evenings, guitar lessons on Wednesday evenings, and computer programming courses on Saturdays. I looked at the list and noticed that a company called Scientific Data Systems was in nearby Santa Monica, and checked that the bus system could take care of the transportation; I didn't have a car yet. The classes were about computers in general, and Fortran in particular. We started out on the SDS 945 (batch-only, no disks, boot from tape), with a quick run once on the large and impressive SDS 9300. The operating system on the 945 was called Monarch (a sort of play on words, because the term "monitor" was in use and only later replaced by "operating system"). The very first Sigma-7, called the "7A", was in the same room though we only got to look at it. The 7A had been hand-wire-wrapped while the rest were done by Gardner-Denver machines. It also had doors with the hinges on the "wrong" side compared to production Sigmas, and this allegedly confused engineers who had been trained on normal systems then had to service the 7A. After a while we moved from the main building to a training facility and continued on a flakey SDS 925.

One project my father gave me was to come up with a complete payment schedule for his 20-year mortgage on our house. The program came up with numbers that matched the payments he was making, but didn't come up with the proper interval. Scrapping and re-writing it, the results were the same. To prove his point, Dad grabbed the actual mortgage contract and then discovered it was, in fact, a 30-year contract and not 20!

At the same time, I used to wander over to nearby UCLA and run a few jobs on their open-shop IBM 1130, and wander the hallways and admire the big IBM 360s. They moved their 360/75 to the new math building, and in the process upgraded it to a 360/91 (a truly awesome mainframe). Though IBM promised this would be done quickly, it apparently took several weeks or more to work out all the problems caused by the move and upgrade. Off in some out-of-the-way room, away from viewing, was a Sigma-7 that was being used on some new experimental network called ARPAnet, the predecessor of the Internet.

The Sigma 7 was even a "cover girl," gracing the cover of the September 1967 CACM.

Somewhere around this timeframe, I remember seeing a poster in the lobby of SDS' building in Santa Monica, stating that in 1967 (?) there were only two computer companies that had made a profit: IBM and SDS.

Our instructor was an SDS employee named Neal T. Fahrer, who was working on their product called "Manage". This was a simple database and report generator. I remember finding out, years later, that if certain types of failures occurred in Manage (Sort?) jobs, a temporary work file would not get deleted correctly. The work file was named $@NTFAHRER.

At that time batch jobs were the norm, and timesharing was under development by SDS. Part of an operator's performance was based on their ability to get lots of jobs through their system (implying they responded quickly to tape mount requests, kept the printer loaded with paper, and so on). We heard, however, that the operators discovered that they could improve their rating by placing a stack of JOB cards in the card reader and pressing the START button.

When I decided to attend UW I wrote, asking what kind of computing equipment they had, and was quite pleased to hear they had a Sigma 5 and planned an upgrade to a Sigma 7!

One of the things I did on my own was learn Sigma 7 assembly language, and wrote a few stand-alone utilities such as card-to-printer. I would hand-assemble these, then punch them on a keypunch in binary using the multipunch key. This was extremely tedious and showed that I had a warped sense of "fun".

By the time the Sigma 5 arrived, SDS had merged with the Xerox corporation, first becoming "Scientific Data Systems, a Xerox Company" in mid-1969, then Xerox Data Systems (XDS). Later they would be called simply Xerox (data systems division). This was initially viewed as a promising merger. Xerox had no shortage of cash to invest in technology, and one of the outcomes was one of the world's first laser printers, the Xerox 1200. SDS had just moved from scattered facilities throughout Santa Monica to a new integrated facility in El Segundo (which included a "dummy" building that hid a working oil well). In a few years they would re-engineer the Sigma series into the Xerox 500 series. Some say the sale was just in time, since SDS was already in trouble. It was said that Max Palevsky "sold a dead horse before it hit the ground." Reportedly due to poor management, the computer division fared poorly and Xerox bailed out of the computer business in 1975/1976. This was remarkable because Xerox had brilliant people at PARC (Palo Alto Research Center) who did things like invent the personal computer, mouse, word processor, laser printer, and if memory serves, ethernet. And Xerox didn't know what to do with PARC's ideas.

Honeywell purchased the rights to the last Xerox operating system, CP-V, and ported it to Honeywell hardware (calling it CP-6). They also continued software and hardware support for existing Sigma sites.

Even though the Sigmas were no longer in production (nor their successors), there was supposedly a significant demand for new Sigma 9s. After Xerox quit and sold out, employees of Honeywell claimed they had received several offers of "if you build one, we will buy it." Negotiations with Xerox were started to purchase manufacturing rights for the Sigma 9, but nothing ever came of it.

Another rumor was that Xerox mis-managed the division based on faulty reports generated by Xerox Cobol programs running on Sigmas, where the Cobol compiler had generated bad code due to a bug. This is most likely an urban myth.

When Xerox first acquired SDS and changed the name to XDS, they put up billboards with the SDS logo but with the first "S" crossed out by a big "X" that looked like it had been hand-painted with a large brush. This confused many people, partly because they didn't know who SDS was, and partly because at the time "SDS" also stood for Students for a Democratic Society, a radical student group.

In mid-1970 UW received an NSF grant to upgrade the Sigma 5 to a Sigma 7. It would be installed in the newly-completed computer center in the basement of the Biological Sciences building, allowing some overlap of operation with the Sigma 5, minimizing service outages.

The Sigmas were interesting in that their hardware architecture was very similar to the IBM 360 series, while the software had a strong resemblance to offerings from Digital Equipment Corporation (including a machine-language debugger named Delta, with nearly identical syntax). Though they could address memory at the byte level, their scientific orientation was reflected in the strong tendency to deal with 32-bit words. EBCDIC character coding was used. The floating-point format was identical to IBM 360s for positive numbers, though for negative numbers IBM simply used a sign bit while Sigmas would complement the entire word (or doubleword for double precision). This allowed a single comparison instruction to compare two integers, or two floating point numbers, while the 360 needed separate instructions depending on operand type. The maximum physical memory was 128k words (512k bytes), and this was also the maximum virtual address on the Sigma 7. The Sigma 9 would allow up to 4 megawords of physical memory but still a maximum virtual address of 128k, quite the reverse situation of later systems such as Digital's VAX. Not anticipating memory trends or programming demands probably helped hasten the decline of the Sigma series and may have contributed to Xerox's failure to stay in the computer business. It should also be noted that when the Sigma 9 was introduced it was not possible to hook up 4 megawords without exceeding maximum cable lengths. This amused some, but showed that Xerox did at least anticipate that memory sizes would continue to shrink. The Sigma 7 had few instructions that were quicker than one microsecond; memory cycle time was about 850 nanoseconds. On one occasion, a counter was attached to the instruction-fetch circuitry and directly indicated between 200,000 and 500,000 instructions per second depending on the types of programs being run.

The operating systems went through a series of transformations. UW first ran the Batch Processing Monitor (BPM). BPM begat BTM (Batch/Timesharing Monitor), which begat UTS (Universal Timesharing Monitor). Finally, Xerox released CP-V (Control Program V). Each was a significant improvement compared the the predecessor, though a large amount of tampering by their marketing department was evident in the frequent renaming.

The Sort utility was originally written in a single-stream batch environment and had a habit of starting an I/O operation and spinning in the CPU waiting for it to complete. When SDS allowed multiple batch jobs, and later added timesharing, this turned out to be a dumb thing and Sort was modified to relinquish control if it had nothing better to do. This is important to remember because NetScape has done the same thing (as of 1996) with NetScape Navigator, which chews up CPU time looping while waiting for network packets. 25+ years later. Sheesh.

As with the Philco, UW opted for in-house maintenance for both hardware and software, and sent several employees away for training in the operating system and hardware support. In general this worked out quite well considering Laramie's remoteness, and reliability levels of the time. Occasionally a vendor had to be called in to repair a particular hardware fault on a time-and-materials basis.

One peculiar problem with UW's Sigma-7 was extremely intermittent, and persisted for over five years before it was tracked down and repaired. On rare occasions, the Fortran compiler and/or the assembler (Metasymbol) would start spewing nonsensical error messages, claiming things like syntax errors at column 17,852 of a comment. This came and went, sometimes lasting minutes, sometimes nearly an hour. Then things would be fine for months. Finally, one Monday morning at about 01:00 it hit again, and I immediately booted the CPU diagnostic called "AUTO". It showed an error in the INT (Interpret) instruction, so I called in Bob Lewis. He showed up, groggy but capable, and spent some time tracking down a single logic gate unique to INT that was outputting "true" and "false" voltages that were lower than proper, and were in the undefined region for the circuits. Thus, it would output a "true" but the following gate would sometimes judge this to be a "false" depending on how it felt that second. Bob replaced the card, and the problem went away. Fortran and Metasymbol made extensive use of INT, whereas most other code didn't, which is why only those products seemed to be bothered by this intermittent hardware fault.

Another cost-saving move was building a custom interface between the Sigma and a pair of old IBM 1403 line printers, and the re-use of the Philco's newer card reader as well as its Calcomp plotter. A card punch was briefly added, but was unreliable and almost immediately removed from service.

One day the system developed a problem with the interrupt chassis. Bob Lewis opened it up and proceeded to rake the wood handle of a hammer across the backs of rows of cards. (He asked some of us to stand around and shield this from view of the users, who might not understand why a ball-peen hammer was being used as a computer repair tool). This shook loose years of dust which blew out the top of the chassis. On one row, the diagnostic program belched. He then began tapping the cards one at a time until the program belched again, and replaced that card. Fixed!

This doesn't deal with central computing, but shows how things used to be fixable. A friend was working on his degree in Electrical Engineering and built a prototype system of some sort, run by a Motorola MC6800 chip. But the chip didn't work. Curious, he un-soldered the top and looked at it with a microscope, discovering that the factory had swapped the power leads (judging by the trail the gold wires had left when they vaporized upon application of power). He took the chip to the college's wire bonding machine and repaired it, tested it, and soldered the cover back on. Try that with your Pentium.

The IBM 709 began life as a model 704 at MIT's Lincoln Laboratory and was later upgraded to a model 709. MIT apparently ran it for quite some time, well past the time where it had any resale or trade-in value. As the story was told to me, they eventually needed to dump it to regain the floor space, and could not find a buyer. When they finally offered it for free (buyer picks it up), UW's division director got interested. Not to actually run a vacuum-tube behemoth, but because IBM peripherals were legendarily reliable. He sent Bob Lewis out to Boston around Easter of either 1966 or 1967 to pick it up (as well as attend some classes), and Bob drove the 709 in a large U-Haul back to Wyoming. It was stored in the basement of a warehouse at 156 E. Lyons, now Rocky Mountain Steel and Salvage a.k.a. Ryan's Place. Some of the tape drives were moved on-campus where attempts were made to interface them with the Sigma, but this failed.

I understand that UW's Division of Physical Plant wasn't really happy with all the floor space the 709 was taking up in the warehouse, and would make a roughly annual visit with our director. "Can we get rid of that old computer?" they would ask, and get the reply "Oh no, that's all good valuable stuff down there," and the visitors would say "Well, we thought it would be worth asking" and shuffle sadly away. After our director left, they came back and asked the usual question to the interim director who replied "Let us pick through it and you can throw the rest away." I like to claim they said "Well, we thought it would be worth asking... What?!" As a result the 709 met its final fate, but not before I grabbed the front panel and a few other interesting bits.

A side-effect of keeping costs low was that both Sigma printers had a 48-character print chain. This meant users could only print upper-case alphabetics, digits, and a few punctuation marks, excluding those most commonly used by the operating system (exclamation mark, colon, and semicolon). Even the 1401's printer had the same chain, for compatibility. Eventually, two solutions were used. A small offline tape-drive/printer was used which had a 96-character print drum. Also, small administrative minicomputers were purchased, and as a side-effect one of them was used as another off-line printer for the Sigma, with a 96-character printer.

When the Sigma was retired, the offline printer (which had been broken for some time anyway) was sold as scrap. I purchased it for $20 and took it apart, saving a few bits here and there. The 96-character print drum, which weighed 35 pounds, eventually became what I call either the "world's most dangerous desk lamp" or "...heaviest...". The other drum (it came with a 48-character drum which we replaced) became the second heaviest desk lamp, and was presented to Bob Lewis when he retired.

To help with card handling and printing, a small IBM 1401 (4k characters of storage) was purchased along with a 7-track tape drive, a card reader/punch, and a printer. Simple programs to do tape-to-punch and so forth were written in-house in assembly language, using SPS (Symbolic Programming System) which was a two-pass assembler consisting of a large card deck. Curiously, due to the service contract on the IBM, UW had access to most IBM software. As a result, the IBM Scientific Subroutine Package (SSP) was acquired and installed on the Sigma 7.

This included the now-infamous random number generator RANDU, which is the subject of particularly strong scorn in Knuth's Seminumerical Algorithms, page 104: "...its very name RANDU is enough to bring dismay into the eyes and stomachs of many computer scientists!"

To use the SPS assembler on the 1401, you had to first insert your source program between the two halves of the SPS deck, and boot from the card reader. The first half was the first pass, which would then read in the source deck and build an in-memory symbol table. It then read in the second half of SPS, and you had to place the source deck back in the hopper to be read a second time. During the second pass it would punch the bootable binary deck as the final result. The source-deck juggling was made easy because SPS would route the cards to a second hopper.

To assist in all the offline processing, to/from the 1401 as well as the offline printers, several customizations were made to the operating system to make these devices appear as though they were directly connected to the Sigma.

Disk storage was initially provided on the Sigmas by what SDS called a Rapid Access Data (RAD) which was a curious cross between a drum and a disk (unofficially nick-named a "drisk"). The 512 heads were fixed like a drum but the rotating surfaces were two disks, providing 4 recording surfaces. Capacity was a mere 3 megabytes but access was very quick. One special RAD was a high-speed swapping unit that used 4 heads in parallel, similar to what is currently called striping except within a single drive (SDS called this "banding"), and had a capacity of just over 5 megabytes. The resulting data rate of 2.5 megabytes per second allowed quick swapping of processes. Soon after, removable disk drives were added which were manufactured by Control Data Corporation. Eventually there were six spindles that provided 25 megabytes apiece. Towards the end of the Sigma's life a Telefile disk (using a Calcomp drive) was added (1977).

These CDC disk drives pre-dated the perfection of the voice-coil actuator and were hydraulically actuated. A broken hose would lead to a messy repair situation. I believe these were the CDC model 841.

Head alignment required standing over the disk drive with a hex wrench, while watching an oscilloscope. This was directly over the air discharge and caused dirt to get wedged under Bob Lewis' contact lenses, and also forced the contacts to rotate. His opthamologist was initially puzzled by the circular scratches on his cornea. Once the problem was realized, precautions were taken when working on these drives!

Telefile was an interesting company. Not only did they make Sigma-compatible peripherals (after all, Xerox was out of the business by that time), they even re-implemented the Sigma architecture using newer technology and sold a few systems. Their success, and the eventual fate of Telefile, are unknown.

Around mid-1977 a Versatec 2000A electrostatic plotter was released to our users. Since Versatec was a Xerox-owned company, they had decided to build a Sigma interface along with several others, despite Xerox's withdrawal from the computer marketplace. This may have been because the interface had already been designed when Xerox bailed out, and/or they felt there were enough Sigmas still running whose owners would buy the plotter/interface. The 2000A was a 100-dpi plotter that could accept bitmap graphics as well as text. A software rasterizer was adapted for the Sigma based mostly on code supplied by Versatec. The paper was 20 inches wide, with 18.55 inches writable.

Wind power was a big topic during the oil crisis of the 1970s and the Engineering college installed a test machine at the UW farm. It was heavily instrumented, and from time to time a 9-track tape would be brought to the Sigma for processing, including a long plot of wind speed, direction, power, and so on. Once they brought in a tape and were very anxious to get it processed as quickly as possible. I hung around and watched the plot come out, noticing that all the data seemed to stop before the end of the plot. The user showed this to me, and explained "right there is where the blades fell off the turbine!"

At some later point in the Sigma's life, it was realized we needed more overall computing power, but had a large investment in Sigma software and expertise. In a bold attempt to address this demand, a project was undertaken to build cheap Sigmas by buying Interdata 8/32 minicomputers, and writing new microcode and making minimal hardware changes. The result would have been cheap Sigmas, to be scattered around campus. The plan was to let the small units perform tasks such as running small Basic programs, but to offload to the real Sigma those tasks needing comparatively heavy-duty computing. In other words UW was attempting to invent distributed computing. The project was canceled when the new director took over in 1977. By that time the test CPU had only been modified to perform a few Sigma instructions correctly.

One of the more comprehensive hardware diagnostic programs was called the System EXerciser, or just SEX for short. It had the interesting habit of finding peripherals by itself and figuring out what they were, and then exercising them. On one occasion we were running SEX and only included a few devices in the configuration deck. Nevertheless, it went out and found the CDC removable disk drives that we hadn't protected, and it proceeded to exercise them by writing test patterns all over the file system. Following that, a condom was rubber-banded to the deck as a safety reminder. SEX also liked to exercise the communication equipment. If a user in the timesharing lab pressed the Return key on any of the teletypes, it would respond with the program name and version, namely SEX B00, which startled some users.

Vanderbilt University had modified the BASIC subsystem and implemented one of the first automated teaching systems, calling it TEACH. We picked up the idea and did the same thing. Using a script, TEACH would help a student write and debug a specific BASIC program, and test it for correct results. The Computer Science department used this for several years. As is usual for this sort of idea, writing new scripts was not easy.

Xerox was my first experience with a company that didn't want to bother fixing an obvious bug. I had found some sort of problem with the rewind function that directly contradicted documentation and common sense. Xerox's response was that they would "correct" the documentation. It wasn't the last such experience.

The administrative programmers had written or adapted a package the BUdget RePorting System, or BURPS for short. Bob Masson went to a conference of some sort on University administrative computing and discussed BURPS, and lamented that our UTS system was crashing around once every day or two. This surprised many of the other attendees who wondered how we had gotten the crash rate so low.

For a while, Xerox released a weekly field software support tape (FSST) that contained patches and unsupported tools. One of these "tools" was a program called Super Star Trek which Xerox's management quickly squelched; that single tape was often copied and re-distributed among Sigma sites. Another tool was SCOMPARE (Source COMPAREer), very similar to VMS' DIFFERENCES command. It was written in very poor Basic, and sometimes produced nonsense output such as a range of lines of negative length. At this time, the head of the Graduate School could not understand why there were so many languages; you could do *anything* in Basic, and any Basic programmer could understand anybody else's Basic programs. I gave him SCOMPARE and asked him to fix the problems it had. A few weeks later he admitted that it actually was possible to write a Basic program that another programmer could not understand. I ended up re-inventing SCOMPARE from first principles, using assembly language. The new SCOMPARE not only worked correctly, it ran 35 times faster. It was re-written in Fortran for the Cybers, and eventually retired from official service when VMS came along with its own DIFFERENCES utility. I still use it from time to time because of a "window" capability that DIFF doesn't have (compares only within a range of columns).

After a while the weekly tapes came out every other week, and finally once a month. Later Xerox bailed out entirely.

At first, management felt it was useful to lock the Sigma's front panel when there was no operator around, i.e at night. I never quite understood why, and joked about how somebody might break into the building, smash into the computer center, barge into the machine room, and place the Sigma into "Idle." Locking the panel meant disabling all switches except the Interrupt, Power, and Sense switches. All other controls would be locked in their normal position (not their actual position). One afternoon we were running with memory in its non-interleaved mode due to an unresolved hardware glitch. When the key was inserted and rotated to "Lock", the interleaving was turned back on, with results similar to placing memory in a large blender set on "puree". One of the results of this accident was that the practice of locking the panel ceased.

We really got tired of the typical manual central handling of creating and deleting accounts, and it was decided around 1972 to write a local utility called SUPER (SUPERvisor) to distribute the responsibility. The colleges would be given a block of disk space and time, and would then divide that among their departments. The departments would then divide this among their units (I think we used the term "account" for this), who would then create "users" and divide their space/time. Sub-trees could either be given a specific amount, or could be part of a common "pool" of space and/or time. An upper-level person could reallocate as needed. All this without involving computer center personnel except when an entire college ran out, which was often. The problem was, the college (and lower) allocations became politically charged, and a college that seldom used all their allocation each month wasn't about to give any of it up, but was willing to loan it out to a "poor" college (the time used was zeroed each month, as were loans). Attempts to redistribute the college allocations to match actual usage usually failed.

At this time, one "user" usually corresponded to one "task." For example, if a student needed to do computing for two different courses, she would have two different accounts. These would frequently be deleted at the end of the semester by the departmental super user, but that was up to them. SUPER had the ability to create a block of logins to simplify an instructor's needs at the beginning of a semester.

Disk space limitations were only enforced at login, to allow a user to momentarily use a large amount for a particular job. Occasionally this created problems because it did allow a runaway program to fill a disk.

SUPER discovered a subtle bug in the keyed file system. If you fiddled with the size of a record, and caused it to split across and into new blocks, under some circumstances different segments of the record would map into the same disk sector and bytes. So you could then alter some part of the record, and the changes would be mirrored in a different segment of the same record. This was probably the most involved bug I have ever tracked down. My supervisor had obtained XDS' flow charts for the file system; I tracked things through the source code; a disk file integrity checker and formatted dumper was written (CP-V would check the integrity of the overall file system, but not the *contents* of each individual file); a "ghost" job was started that checked SUPER's file every few minutes in order to catch the problem just as soon as it happened. I eventually tracked it down, but around that time we also moved the file from a keyed file to a random file and wrote our own routines to manage it (this definitely helped performance of the file, but I can't remember if the intent was also to bypass the bug). The bug and fix, which was about a one-liner, were passed on to XDS who incorporated it in the next release.

To provide users with good turnaround, despite the Sigma being a closed- shop system, an open shop was established by placing a 400 CPM reader in the user area. A second IBM 1403 printer was hooked up, with paper sent through a hole cut in the wall to the machine room. In general this worked very well and provided most users with immediate turnaround. Small open-shop batch jobs were given high priority. Sometimes users would attempt to submit jobs when we didn't want them to, such as during a crisis while we tried to resolve a problem. Many users ignored a sign placed in the card reader that said "Do Not Use" until one of the operators designed a large sign that included a very good picture of a Smith & Wesson .44 magnum handgun.

A fun quirk of Xerox Fortran was hidden in the ability to use an ASSIGNed GO TO without a list of possible targets. Standard Fortran allowed this:

        ASSIGN n TO identifier
						...
						GO TO identifier, (n1,n2,n3,...,nn)
				

but Xerox implemented this by compiling the ASSIGN to simply store a Branch instruction to the appropriate label in the identifier. Thus the GO TO did not need a list of possible targets in order to work. You could simply write GO TO JAIL, for example. However, if you did, the compiler would say "Warning: Go directly to Jail. Do not pass GO. Do not collect $200." and then claim (falsely) to delete the statement. This no doubt caused its author a good giggle, and probably caused management a dose of high blood pressure. The author of this cute code did a good job of hiding it, too. I searched the source code for words like JAIL but could not find the text of the message. I finally did a text dump of the executable for the compiler, found the text, computed the actual address, and cross-referenced that back to the source via a load map (any of you kids out there following this? :-). The text had been encoded as a string of hexadecimal-valued numeric bytes, with the nearby commentary mumbling something innocuous in compiler-ese. The code to detect GO TO JAIL and emit the message was actually in a completely separate module, again obfuscated with misleading comments.

Xerox' Fortran compiler seemed way ahead of its time in terms of features that would become standard much later. Many features didn't even make it into the Fortran 77 standard, but may be in Fortran 90, such as multiple statements per line (which CDC did have but used different syntax and semantics). The people who wrote the manuals had a good sense of humor. There was a GLOBAL statement, similar to labeled common, and examples included GLOBAL WARFARE,VANLINES. There was also COMMON GHIA (but you had to know the popular car called the Karmen Ghia). Some manuals include references to a fictional Stephen Potter who was invented at Harvard as a student. Another cute entry was explaining that DATA was intended to give symbolic names to constants, such as DATA PI /3.14159/. Thus you could simply write PI in the program; it was also handy should the value of pi ever change (and the manual did use the greek symbol for pi, not the variable PI when it made this statement; prophetic since some physicists are proposing regions of the universe may exist where pi may in fact have different values).

The object language created by the compilers and assemblers was apparently relatively advanced even by 1999 standards. Donn Terry commented on this in a GCC discussion, see http://gcc.gnu.org/ml/gcc/1999-02n/msg01257.html.

In some ways, though, the Fortran run-time library was a bit shabby. It was a shared library, which was good, but each time a new release came out, users had to re-link because routines would move around. This was tiresome, and made worse by the lack of any identification that would warn a user of a mismatch. So some programs would run for a while before they stumbled across a change and then blow up. Finally, Xerox implemented a branch vector and announced users would not have to re-link after this new version. They had written some nice-looking tools internally to find all the entry points and tie them in to the vector. Problem was, it worked based on a naming convention that had not been rigidly followed. So some double-precision constants were attacked by the vector program, with the result that the double-precision hyperbolic math routines failed because instead of (say) dividing an argument by pi/4 the divisor was a pair of branch instructions! Most embarrasingly, the new library would fail its own verification procedure if installed shared. So Xerox had not even tested this new version with its own test procedure before shipping (it worked fine unshared). Customers crawled all over Xerox for this blunder, including me. They re-released the library, which once again required all users to re-link, followed once again by the promise "you won't have to relink again." They had ignored a suggestion I came up with that would have allowed a re-release without requiring relinking. Another act of stupidity was that unused locations in the vector (reserved for future use, good thinking), as well as retired locations in the future, contained a branch instruction to itself. So if you ran an old load module that called a retired routine, the program would get stuck in a loop instead of aborting! Gee, I remember burning out a core-diode module doing that (see elsewhere). This is another lesson many vendors have failed to learn: Test the product, using the release media itself, before shipping.

The Fortran compiler and the Metasymbol assembler were both very slow. They had been written in a macro language called POP (Programmed OPerator, or something like that) that generated pseudo-code which was then interpreted at compile time. My best guess is that this was either an attempt to keep the memory requirements down (at the expense of speed), or SDS actually used this as a dirty trick to port over the SDS 9300 compiler and assembler, while only making adjustments to generate proper output. In any case a new assembler came out many years later that was MUCH faster (and not written in POP), and a new Fortran 77 compiler came out but we didn't get a chance to use it very much. (The new assembler was called AP, for Assembler Program, which was so unimaginative I can only think a manager came up with the name after rejecting suggestions from the programmers!).

Our operations manager, John Sapp, was a retired career Marine. While he was friendly and likable, his military training would sneak out on occasion. John changed the combination of the on-site vault from time to time, and then handed out the new combination to those who needed it (operators of course, and system programmers because we'd come in at strange hours to do work; operations was not yet a 24-hour function). He would change the combo, then lock an operator in the vault and try to open it. If he failed, the operator would "time out" and open the door from the inside, thus avoiding an accidental lockout. One day another operator and I were watching him do this, and we both saw the card in his hand with the new combination, and proceeded to write it down. Even though we both were supposed to get the new combo anyway, John was so upset with *how* we obtained it that he brushed us out of the area and changed it again!

A curious special project we took on was to solve a problem the Geology department had. In seismic studies at the time, the field recording equipment would write data non-stop onto 9-track tape, without any interblock gap. Like most operating systems, CP-V was brain-dead about this possibility and could not read any block over 32K bytes even though the hardware was perfectly capable. Since a "block" on these tapes might be up to 20 megabytes, and the Sigma had 512K bytes max memory, you would have to be careful about buffering, and because of the OS limitations, you'd have to use a standalone program to read the input tape and write to tape as fixed-length blocks (writing to disk was another possibility but tape was easier). The trick was that the input would go into a large circular buffer (made circular by building a "loop" in the I/O command string), and the output had to write from this buffer; the latter would be slightly slower due to the interblock gaps (but as long as you kept up, the tape drive wouldn't stop the capstan, sort of what was later "invented" as streaming) so the buffer had to be large enough that in the worst case the circular buffer wouldn't "catch up with its tail". This also just about precluded any error recovery. I actually wrote such a program as a test, out of curiosity. The output tape was the 7-track drive because it was on a separate channel and could operate concurrently with the 9-track input drive. Since we couldn't afford standalone operation for this purpose, a small Microdata 1600 was purchased along with two tape drives. One was 25 IPS and the other 37.5 IPS. It was programmed to read the large blocks on the slow drive and write to the fast drive. As long as some minimum output block size was used, the tail-catching problem didn't happen. However, there was still no effective error handling on either tape. This wasn't usually a problem. In order to make this work we had to invent an atomic instruction that could not be interrupted, to interrogate the tape drive status and branch on some condition. This was microcoded and burned into a PROM and installed in the system.

We experienced many nightmares, many of which no doubt have hit other sites. One evening an operator mounted a removable disk pack on one of the CDC spindles and spun up the disk, and mounted it at the console so the user could access it. Several disk errors started showing up on the console teletype, so the operator dismounted the pack and moved it to another spindle to see if that would help. The same errors persisted. So the pack was dismounted and set aside for examination in the morning. Later, another pack was mounted on the first spindle, and then later moved to a third spindle. You guessed it, all the shuffling around had propagated a head crash from the first pack/spindle. In the end I think there were three crashed packs, and all the heads in three different spindles had to be replaced. The operator was very embarrassed!

Not long after the Sigma 7 had been installed, I was looking at the assembly listings for the Control Card Interpreter (CCI) and noticed an interesting undocumented command in the family of link commands. I was curious to try it out but was cautious enough to test it late at night rather than in the middle of the day. Shortly after midnight I came in and ran a deck with the mysterious command. How disheartening it was to see the system hang! Further prodding showed that the code was incorrect and I had coerced it into the fastest possible single-instruction loop: a branch to location zero, plus an index register that happened to contain the address of the branch instruction. What to do? I called the system manager and sheepishly explained what had happened. Timesharing wasn't completely dead but almost; since the loop was in privileged code I could not abort the job even from the operator console. The control panel was locked and only the manager and one of the assistant directors had a key. It was decided it could wait until the morning. When the manager came in and unlocked the panel and requested an operator recovery (sense switch 3 up, idle, system reset, run) he was a bit surprised that nothing sensible seemed to happen. After a few other attempts he decided to do a full reboot, which also failed. The engineers came in and found that one of the core/diode modules had failed, apparently due to the heavy pounding on one location since midnight. The head engineer, Phil Foddrell, referred to me as "the kid who burned up the branch instruction."

When the Sigma's memory was upgraded to 128K words, it arrived very late in the afternoon and was delivered to the loading dock of the Physical Sciences building. It either wouldn't fit the freight elevator, or nobody could be found with a key, or something; in any case, the memory would have to sit in the hallway overnight. The director was concerned about this and insisted that the campus police post a guard. As the story goes, the officer wasn't too impressed with the assignment, so a quick mental calculation showed the cabinets cost 1/5 their weight in gold (this may have been before the Feds "let go" of gold prices, in which case gold was $32/ounce at the time). This *did* impress the officer who suddenly showed great interest in protecting the equipment.

Marketing forces can be interesting. Not too many years after we got our Sigma 7, Xerox came out with a new and improved version. Most of the optional Sigma 7 features were standard, the system was faster, and it even cost less. Rather than selling a Sigma 8 at a lower price than a Sigma 7, which might have pissed off Sigma 7 owners, they decided to call this a Sigma 6, indicating that the number referred to dollars, and not performance levels.

The original card reader on the Sigma 5 was made by Soroban, and was alleged by other sites to be excellent. It used vacuum to help pick and move the cards, along with a perforated belt. Vanderbilt University had several. In fact it *was* a very nice, high speed, low cost card reader. Until it came to its first n-100-hour rebuild which was performed on schedule per the maintenance manual. From that point on it was simply terrible. We finally gave up on it and used a small Uptime reader until the large unit could be appropriated from the Philco. The Soroban was put in storage with the IBM 709 and eventually sent to the landfill.

The Sigma-5 arrived with an NCR drum type line printer which never did a good job of firing the print hammers at the right time. It was nick-named the "wavy line generator".

One of the last RAD units we purchased was a used unit from Bucknell University. After getting it hooked up and spinning, I attempted to distribute part of the file system onto it. CP-V allowed placing the directory structure separately from the actual file data; we put the former on the faster RADs and the latter on the larger/slower CDC spindles. Almost immediately the data showed signs of corruption and we had to hastily back it out and reload all user files from backup tapes. Diagnostics showed no problems, of course. I added it back to the system as a "do nothing" disk for further testing (note that changing the configuration required building a new boot tape and rebooting, and possibly dumping/reloading the entire file base) and got an indication that the problem was random data corruption but it took time. Finally we used the diagnostic tool to write a test pattern, verified it, then took the controller offline and write-protected every track. A week later the controller was put back on line, and the test pattern verification failed. Even when write-protected, the RAD would change the data! The disk was pretty much abandoned at that point. Later, Bob Lewis speculated that one of the wires in the diode addressing matrix for the heads had a long unterminated wire, possibly from a former repair involving switching from a bad track to a spare one. This long wire might have acted as an antenna, picking up stray signals and coupling them to the heads even though the electronics were write-disabled. In any case the "Bucknell" RAD was a complete lemon.

The Sigma 5's room, the Bio Sci machine room, and later the Ivinsion Building's, were powered with the aid of a large GE motor/generator (MG). This was just a large motor, large generator, and a big flywheel. It would filter out spikes and such, and would generate decent power for several seconds during the short outages Laramie gets in the summertime from lightning. However, it always displayed a major shortcoming that I never convinced anybody to deal with. When it finally did cut out, it would simply disconnect the field winding. Stray magnetism would cause it to continue generating some power, but at reduced voltage and frequency, such as 50 volts instead of 208. Sometimes this caused problems with the equipment which was expecting normal voltage or nothing. A good example of this was the Xerox 7212 high-speed swapping RAD (see discussion of RADs elsewhere). The RADs had a large number of fixed heads that flew above the surface like most disks, but for landing and takeoff the entire head-mounting bulkhead was raised and lowered using air pressure from a compressor. The spindle motor had friction brakes de-actuated by solenoids. Once, the power went out and the MG did its fun with the power, which wasn't quite enough to run the compressor, but was enough to hold the brakes in the unlocked position! If this kept up, a massive head crash might have occurred. Bob Lewis tried beating on the brake housing with his flashlight (power was still out and it was dark) to release the brakes to no avail. Finally he jogged over to the main circuit breaker panel and tripped the main breaker for the Sigma, and the RAD stopped spinning with a nice "klunk" as the brakes engaged.

One argument for not putting a contactor on the output was that the more contacts you put in the path from source to destination, the less reliable the power distribution became.

The MG was also cute with clocks. Since it used an induction motor, the shafts spun at slightly less than 3600 rpm. As a result, the power was very slightly less than 60 Hz, and if you plugged an electric clock into an MG-supplied outlet, it would run unacceptably slow.

Another way we saved money was by making some of our own hardware for the Sigma itself. An almost-mandatory option was the "memory map" which allowed mapping physical pages to virtual pages. Without it you could not run any operating system except perhaps BPM which meant batch only. So everybody bought Sigma 7s with the map option. Except us. Stan Brown pointed out that the map cards were the same as the register cards, and were very simple. So we actually made our own cards, plugged them in, and thus made our own memory map.

Sigma circuit cards were rather small, about 3x3 inches or so. They had designations such as FT17 (two alphabetic followed by two numeric). As a result of UW's work to build map cards and printer interfaces there was a catalog of these cards lying about, in which I noticed one card designated the "ZX12 Kluge". I never found out what this was, but suspect it may have been a card extender for debugging. The quality of many cards was atrocious, with bad-looking solder joints being the most common problem. With maybe a hundred thousand total soldered or wrapped connections in a system, it was amazing they ran at all.

The Sigma 5 wasn't designed to allow memory mapping, but enough people had them, a company (Telefile?) eventually marketed a memory-map retro-fit.

The division had a moderate set of shop equipment, as well as lots of space for shop type work. This was partly the nature of computing centers in the early 1970s, and amplified by both the do-it-yourself attitude (for example the home-built printer interfaces), and because the director was a hands-on tinkerer. There was a photo shop for printed circuit work, a PC board etcher, drill press, lathe, horizontal milling machine, and lots of smaller equipment. The main work room was originally labeled "IBM 709" on floor plans which makes me wonder if the 709 had been used as justification for all the floor space even though it never left the warehouse. A semi-automatic wire wrap machine was built. The director built a very large camera, mostly out of aluminum plate and irrigation pipe. With this camera he was able to shoot printed circuit boards for an instructional do-it-yourself PDP-8 built from TTL logic chips. This PDP-8 was used for many years in the computer science department's hardware course, and was sold to other institutions for the same purpose.

There was a small company that attempted to develop a better operating system for Sigmas. This OS was called GEM. Allegedly it originally came from the name of the paper clip company when somebody decided it had to have a name, and was staring at a box of clips at the time. Later they came up with "Generalized Environmental Monitor." My recollection is that it was rather Unix-like, and very likely was a better system than CP-V. In order to develop GEM, the company would wander around scrounging time from Universities in trade for future rights to run GEM once it was ready to be marketed. We participated in this effort. Unfortunately a completely new system would not run the existing applications or compilers, and they didn't have the resources to re-write them all (or even one). Instead they came up with the "BPM simulator" that simulated BPM under GEM, and you then ran the compilers and resulting code under the simulator. By this time performance was back down to that of CP-V, so there wasn't much point. We ended up declining the privilege of running GEM once they tried to start marketing it. The group was based in Utah, and probably folded soon after. One of their big selling points was reliability; they told of one Sigma that had a memory power supply burn up, and after the engineers ran off with the smoked supply, the Sigma was powered back up, GEM detected the new configuration, and allowed the developer to continue with a loss of just one keystroke. I believe this was as much luck as design.

One evening Steve Booth decided to write a program that would broadcast a message to all logged-in GEM users. This was pretty easy, and for fun he sent a message that included a control-D which would hang up the dial-in teletypes of the day. This worked well. Except it hung up *his* teletype and when he tried to log back in, the process was still running and would immediately disconnect him, or anybody else who tried to log in. The developers were trying to get work done from Utah, so they logged in and repeatedly hit control-X when the broadcast message started coming out (easy to do at 110 baud), and managed to assemble, link, and install a modified kernel that ignored broadcast message requests. Without having to reboot.

The Sigma series included a rudimentary sound capability. Connected to a spare lamp driver was a small loudspeaker. Via a master-mode instruction this speaker could be turned on (about a 1000 Hz tone), or off, or toggled (clicked). With timed loops you could generate almost any tone but the timbre was that of a rough triangle wave. A few programs floated around to play tunes, including one impressive attempt at doing a Bach fugue with one "voice." But these were all standalone programs that could only be run after shutting down CP-V. I made a player that would run with CP-V up, but it had to disable all interrupts to work, not a very nice thing to do with the users except for very short tunes! The same programs were adapted to run on a small Texas Instruments TI 960, whose only input medium was a teletype or a very nice/fast paper tape reader.

Shutting down CP-V was referred to as "quiescing" the system. When finally shut down, some versions would proceed to play random music on the speaker (picking tones and durations by walking down memory). It also would type "that's all, folks!" on the console teletype (a model 35), complete with Porky Pig type stuttering by embedding unprintable characters in the early portions of the message.

There was a program that would compute complex musical wave shapes and play them, but it required a D/A converter that was extremely costly. I tried to get around this by an elaborate trick that failed. My idea was to run timed loops in various sections of memory, and "read" the high-order bits of the program counter from the front panel. Several lamps were saved as they naturally burned out, were broken open, and wires affixed. The plan was to run these wires (now connected directly to the lamp drivers) to optical isolators for safety (of the Sigma, not me!), and run the buffered output to a single-chip D/A converter. The problem was, the addresses ranged all over the various banks of memory, each of which had different timings. I had to give up, except that I did solder in a jack on the existing speaker leads and was able to record a few tunes directly to tape with no background noise, instead of dangling a microphone over the speaker.

DANGER -- Long multi-part story follows -- Around 1969, my friend Steve Booth was working for SDS as a summer employee. Aside from his assigned duties, he had the typical urge to find a way to get into master mode from a slave-mode program. We'd later call this sort of fun "hacking". He and a co-worker found a way, but had no luck convincing the OS group that it would work, or to fix it. So they tested it, filled all of memory with the text IAMADUCK, and started the printer dumping memory. That did catch the OS group's attention, and they promptly plugged the hole.

Many years later an improvement was made to the error logger. When certain types of file system errors were found, they would be put in the error log. But some types of errors would get repeated thousands of times, causing a huge error log. To cope, XDS created an in-memory table containing the disk addresses associated with the last 6 such errors. If an attempt was made to log an error with one of these addresses, it was discarded. If the address wasn't in the table, then it would get logged, the table shifted by one entry, and the new address stuffed in. The table was initially all zero, which it turns out was a very common "bad" disk address, so many meaningful log entries were erroneously tossed. To rectify *this* they needed to initialize the table with true junk (or use pointers which was too much work) and pre-initialized it with 3 instances of IAMADUCK.

As mentioned, we modified some software for printing on the IBM 1401 via tape. In the cases of the Fortran and Cobol run-time libraries this was done by re-routing I/O in certain cases to a blocking routine that then double-buffered to tape. So, from one release to the next, we had to re-integrate our mods with XDS' source code. But for Cobol, fixes were released via the weekly software support tapes that only included binary, not source. My solution was to dis-assemble the new XDS code, compare it with the last code from known source, and iteratively change the source code until I got matching binary. In other words, the new source code was reverse engineered. This was "easy" since the source was assembly language. Once this was done, I could then re-integrate the local mods for offline printing. One evening I sent the latest dis-assembly output to the printer and walked over to it, to watch and wait. Here it came. But the columns were slightly off. Many of the addresses were in the Job Information Table (JIT). And most telling of all, I watched three instances of IAMADUCK roll by.

What? Pressing STOP on the printer, I dug through the stack and saw from the banner page that this was not my listing, but that of a high school student who was using the Sigma (his father was the dean of the college of arts and sciences). Checking a few things more, I could piece together what was going on. Some time before, he obtained a copy of the main module of CP-V. It had a nasty habit of defaulting new files to RD:ALL, meaning they were readable by anybody. This was a bad default which we changed, but the OS build procedures didn't like to pay attention to the customer's defaults. Normally I would build a new version and explicitly set the files to RD:NONE but this kid must have caught it just at the right instant, or got a copy I had left unprotected. He didn't have enough disk space to hold it, so there must be a copy on tape. Oh, and somewhere along the way he wrote his own disassembler that was similar to mine (XDS didn't provide one). Going back through the printed operator console logs, I found the tape number, and verified that the contents included many "interesting" things. I placed the banner page plus one line of output in the output bin with "Here's your output, from your old friend Jim K" written on the banner page. He and a friend had been doing the disassembly at night to avoid getting caught. About the time they came in to pick up their output and saw the writing, I walked out to the user area with the tape and asked them if there was anything they wanted off it before I erased it. They were obviously disappointed, and asked if I could preserve the last 3 files on the tape. I checked and found that this included the OS debugger, and saved the last 2 files for them.

So they were caught, in part, because of the IAMADUCK trick years earlier.

My office partner was taking a welding class in the art department, and decided to weld up a primitive duck for me from scrap steel.

Years later I bumped into this kid, now a freshman at some college back east (MIT? Harvard?), who I didn't even recognize. He reminded me of the evening I dashed their plans. He then told me they had a second backup tape of CP-V that I missed. Damn kids.

SDS/Xerox had a penchant for using animal names in some of their software. The disk allocation process was called ALLOCAT, and slept most of the time, and was called the sleeping alley cat. The Remote Batch/BATch scheduler was called RBBAT or "rabbit". They also used FROG (FROnt-end Ghost), MOOSE, DUCK, and others that I can't remember.

Over the years we've flip-flopped on the issue of handling holidays. Obviously the Philco was out of action if there was no operator because it was a closed shop, batch only. With the Sigma we tried "unattended service" which meant timesharing and batch but no tape mounts or printing, with the understanding that if the system crashed, the users were out of luck until after the holiday. Sure enough, one user called one of the system programmers on Thanksgiving, pleading with him to go in and reboot because CP-V had crashed. He did, but as a result we switched to shutting down entirely for holidays so this would not happen again. Some time later, perhaps with the Cybers, we again went to unattended service.

At one of the CP-V user group (EXCHANGE) meetings, I heard about a Sigma that had a peculiar problem with one of the instructions, Move Byte String (MBS). Sometimes it wouldn't work. Also, power-cycling the machine would usually toggle it from not-working to working, or the other way around. After much work, Xerox' final solution was to give up, leaving the customer with a small bootable card deck that would test MBS and tell the operator whether it was working. The operator was to run this deck before each boot of CP-V; if it failed, he/she was to power cycle the system and try again.

A cute quirk of CP-V was that it always liked to log disk errors, then figure out what happened and handle it. This certainly seems the right thing to do. Except that in those days, the idea of "flawing" a disk track or sector, and re-vectoring it, was somewhat new. When a flaw mark was read, it was logged as an error, then the new location was used. This caused many un-interesting error log entries. But one day the error log itself fell on a flawed track. It opened the error log to log the error, and got an error. After a while the log filled up the disk which created other forms of havoc. Sadly, in the middle of all this, we had a memory parity error the engineers really wanted to look at.

My friend Steve Booth worked one summer at SDS on converting the Snobol compiler for Sigmas. The first step was to read the tape obtained from somewhere but none of their Sigmas would read it without errors. Finally, Steve's supervisor took him into a secret room with an IBM 360/20 that allegedly did the company payroll, that SDS of course didn't want customers to see. The tape read fine, and was re-written on a tape that the Sigmas could read. That done, he spent the summer writing assembler macros and converting core code from 360 assembler to Sigma assembler. He didn't quite get it done before the summer was up. Not realizing that Snobol was incomplete, XDS released it. I obtained a copy and found it did not compile or run correctly. With Steve's help (he was attending Whittier college and had not yet moved to Wyoming) I was able to get Snobol working, and even improved the performance and implemented external functions per the language specification. We later used Snobol to read the IBM Scientific Subroutine Package and split the source into individual files, one file per routine.

Some time later, another University released a smaller Snobol that could barely be run in timesharing mode. They called it "an almost complete subset" which I always felt was a bad example of constructing a phrase.

The tape drives were, I believe, designed and built by SDS/XDS. They had a very convenient hub called "Pop-On-Pop-Off" or "POPO" hubs. With these, you simply placed the tape over the hub and pressed, and mechanical levers in the hub would cause parts of the hub to expand and grip the reel. To dismount a tape you would just pull it off. This was convenient but is a good example of a bad design. The operators would press tapes on, pressing the flanges of the tape against the drive. This caused edge damage, where the tape wasn't wound exactly flat. Some part of a reel of tape was always sticking up a fraction, as the tape wandered over the width of the reel during a rewind. The edge damage would then cause the tape to be unreadable in that spot. Likewise, when operators pulled off a reel, they would grab the reel front and back, squeeze, and pull. I got in the habit of pressing tapes on by pushing the tape's core only, and pulling tapes off by pulling only on the outer flange (in one case pulling the flange off the tape!). In this, I was a minority of one.

Several security issues came and went. There was a bug in the debugger that allowed users to get into master mode if they constructed a chain of EXU instructions. One patch that came along caused CP-V to zero out pages of memory before handing them to user jobs; we had come up with the same idea some time before XDS got around to it. I don't remember how they stopped disk scavenging, but it was possible to do so in the early releases (I know, a friend tried it successfully) and not in the later ones. I'd like to say "We were so naive about security back then" but I won't, because a) it's really a sappy thing to say, b) the industry is probably even worse about security now than "back then."

Operators and users sometimes didn't get along. On one occasion a user tapped on the window, indicating her wish that the operator come out and pick up her deck right now. The operator said something impolite, in the isolated safety of the machine room, and walked over to the door and opened it to get the deck. The user then simply said "I can read lips" and the operator turned bright red.

Another operator changed colors when she had to, um, re-adjust an undergarment. She walked around behind the Sigma cabinets where no user could see, and performed the task. Later, the night watchman came through and reminded her that the closed-circuit security cameras in fact could see that area quite well.

Towards the end of the Sigma era we attempted to install the latest version of CP-V, namely E00. We had extensive modifications for the front-end unit that had to be integrated, and many others for accounting and other purposes. So it took a significant effort to bring up each new release of CP-V. We completely skipped D00. When it came time to actually put E00 in production, things seemed to be going well for the first few hours until it was discovered that some types of tape errors would cause a crash. I tracked down that problem and had a fix in record time, but there was one other problem (can't remember, it may have still been a tape error) that we couldn't live with and couldn't quickly fix. So we backed out to version C01 and started talking with Honeywell (by then our new vendor) to get things fixed. At this point the new director had already started the process of acquiring new computers and wasn't interested in spending time on the old one, and ordered us to stop work on E00 and remain at C01 for the remainder of the Sigma's lifetime. This was a huge disappointment. We had spent so much time getting E00 ready, and were looking forward to new features and capabilities such as a real command language like JCL/DCL. Just to be a pest, and to get *some* of the new features, we would continue to "back stitch" a few E00 goodies like the new editor into C01.

I worked to resolve a strange problem with the design of the SDS 7-track tape drive. The CPU had a watchdog timer that ensured the CPU would not hang. If the CPU did not issue an instruction fetch for more than a few microseconds, the watchdog would trigger a trap condition. We started getting these once in a while, and I noticed they always were accompanied by tape write errors on the 7-track drive. Checking the tape, there was at least one spot where the oxide had been completely worn away, leaving transparent mylar. I threw together a program that wrote several records, rewound, and repeated as necessary. On maintenance time this was run against a tape which had a clear spot scraped into it, and it frequently caused a watchdog timer runout. However, it took a long time to reboot CP-V each time so I then wrote a standalone version which was able to trigger a timer runout every few seconds. With this, Bob Lewis and crew were able to find there was a design blunder in the controller. The drive would do a read-after-write to check integrity, but it did not check the data content, just parity (it had a whopping 4-byte buffer, far smaller than the gap between write and read heads). The write logic would blindly grab data and write, until all bytes were written. The read logic was responsible for signalling end-of-operation (EOP) when it detected the end of the data block. But with clear tape the read logic would detect end of block, based on time with no data, and signal EOP before the write logic had finished writing the block. For the remainder of the write time, the drive would hold the memory request line high, which completely locked one bank of memory from other access, e.g. by the CPU. If the CPU needed to execute an instruction from that bank, it would hang and trip the watchdog timer. Xerox had no solution to this except to increase the timeout period (or dump the 7-track drive, which we could not do). The watchdog timeout was increased many times over the years, for various problems such as this.

SDS/Xerox, somewhen, built a box they called "Adam" which was a hardware debugging aid and monitor for Sigma CPUs. One outcome I remember was their use of Adam to figure out why the program linker (they called it the "loader") was so slow in some cases. For example, if you wrote a program that had to deal directly with operating system data structures, it had to be loaded with the system's symbol table. Being huge, this caused the loading process to take 5 or 10 minutes. Adam showed them where the hot spots were in the loader's code, and they made improvements that greatly reduced load time. I always thought that in this case, the problem was so obvious they could have simply started a load, and repeatedly moved the run/idle switch to idle, and written down the program counter a dozen or so times and gotten a completely good indication of the "hot spots" in the code. Oh Well. At conferences, people liked to introduce the developer as "Adam's Father."

One evening Bob Lewis got a phone call from a distraught operator. It seems the card reader was making noises like a machine gun! Over the phone, Bob could hear an occasional "bangbangbang." After instructing the operator to power it off, an investigation showed that some wires had drooped in front of the floodlamp (the light source for the photodetectors) and melted, shorting some wires which caused line voltage to be fed to the diode decoding matrix. The diodes were exploding in groups.

From time to time, the cost of doing computing would raise the idea of not having our own computers, but just having remote card readers and printers connected to the State's system in Cheyenne. I'm certain that some of the people who suggested this were just trying to save money, but also wonder if other forces were at work such as a desire to use IBM software instead of the "Brand-X" stuff we had, or even politics in order to give the Cheyenne facility more equipment and importance. This issue came up several times, but has died out now that computing is much less expensive.

The home-built interface for the IBM 1403 printers was a bit flakey. Just swinging open the card cage would crash CP-V due to excessive interrupts overflowing the system stack. Sometimes just pressing the printer's STOP button would do the same thing.

CP-V was the only operating system I know of where advanced file access methods were integrated into the OS, practically at the next layer up from the disk driver. Keyed files were integral to CP-V, and it re-used the same code for user access and for organizing/accessing the file directories themselves. This was analogous to single key ISAM, with the key ranging from 1 to 32 bytes in length, and the key being stored completely separately from the record data. A pyramid structure was used, the depth depending mostly on the number of records. Again, this was part of CP-V and not some thought-after add-on like RMS (VMS), CRM (NOS), or the almost completely absent methods of Unix. In fact, even sequential files were stored as keyed files; the record number was the key which allowed very fast "sequential" positioning. Only much later did Xerox come out with a true sequential file, for performance reasons.

This led to an interesting phenomenon with labeled tapes (not ANSI labeled, but CP-V labeled tapes). You could randomly read records of a keyed file on tape, just like those on disk. CP-V kept track of the last record's key, and positioned the tape forward or backward as needed. This was complicated by the 9-track drive's habit of storing the data backwards on a reverse read; even worse, the 7-track drive could not read in reverse so it was simulated by a backspace-read-backspace sequence. I had a program that would analyze load modules (today's .exe files), accessing the various segments in a logical order that was random as far as the keys went. It was most impressive to watch it work on a load module stored on 7-track tape!

One project I started on was to write a Sigma 7 simulator that ran on our Sigma. Sounds stupid, but I wanted to be able to run and test privileged code without actually running it, and to be able to debug it with carefully crafted breakpoints and checks. I don't remember if I started on this before or after somebody else contributed a Sigma 9 simulator to the user library, but I never did finish mine (and I think the Sigma 9 simulator required a Sigma 9; in any case I did not want to simulate a 9 anyway). But it was quite nice when I at least got the very basic instruction set completed to the point where it would run the Xerox CPU diagnostic called "AUTO", and I believe it also ran the interrupt diagnostic "INT". This also led me to realize many things about how instructions were executed, that was not documented in the manuals. For example, if a Load Word instruction pointed to a word that could not be accessed, you'd get an exception (Illegal Trap, in Sigma-ese). But if it was indirectly addressed, and the pointer could be accessed but the resulting effective virtual address could not, the relevant bits of the condition code would already have been cleared in preparation for setting per the operand. Would this make a difference in a simulated operating system? Might. (I may have gotten the details of this example wrong, but it shows the sort of things that can go on in the hardware outside of the manuals).

Speaking of simulators, one of the projects I worked on (with two other students) as a computer science student was a simulated operating system for a simulated computer, as part of our Operating Systems course. After we turned in our assignment, we decided to "buy" a faster line printer, and discovered our operating system would crash. This was not pointed out to the instructor until after final grades were turned in.

The file save/reload utilities of most systems work at the sector level. But here, they worked at the record level! Remember that maintaining an ISAM file gets really ugly if you insert many records in "random" order and/or rewrite records with different lengths than original. By dumping/reloading at the record level you not only defragment a file at the sector level, you defragment the file *internally* as well. Sort of like using the CONVERT utility on VMS. This was practical because the file system was at a low, well-integrated level, and because there simply was no clear sector-oriented access method for the utilities to use. The supplied utilities were, however, quite slow. Another University (I think) wrote their own utilities that were much faster, by inventing multi-threading before it became a 90s buzzword. These new utilities (FSAVE/FLOAD, for Fast Save and Fast Load) quickly became the standard ones.

Some users would try to program a sort by simply writing output records to a keyed file, using the sort key as the record key, then read the file sequentially. This worked, but was exponentially awful. One person even used this as the core of a sort method that itself was even worse. I re-wrote it using the system sort routines and cut it from 30-60 minutes down to about 10 seconds.

Several years after the Sigmas came out, Xerox started using a newer memory module. Systems were then referred to as being either "old memory" or "new memory." Can you see what's coming? After a few more years yet another style was used, and the terminology "old" and "new" no longer had any unambiguous meaning. Sort of like the guy who always wrote "current version" on any new listing he got, adding it to the pile. This is another example of something the industry refuses to get right, decent naming of new products. Like C and C++ (what's next? C++++?), HTML+, FutureBus, Advanced Tape Subsystem,...they leave no clear room for the *next* version.

The refusal to plan for the future is also seen within C, which blithely uses terms like "int", "short int", and "long int" without any consistent definition. And why should a machine have only three sizes? (Witness Digital's Alpha chip). Why do some systems equate "short" with 16 bits, and others with 32 bits?

One quiet evening and/or weekend the operator was sitting at the desk reading a book but was distracted by a user waving at him/her through the window. This was followed by more waving and pointing; the operator eventually decided to look where the user was indicating and saw that heavy smoke was billowing out of the Sigma. This of course led to a rapid power-off of the system. The incident was drawn up in a cartoon by Rich Travsky with a caption "... Two words? One word! ... Starts with ... Sounds like ..."

Telecommunications

Initially, the Sigmas were accessed using Teletype model 33s either via a direct hook-up or via dial-in modems. A Remote Batch Terminal (card reader and line printer) was installed at one corner of campus. As time went by, video terminals appeared and could utilize (if not demand) higher data rates. This eventually led to the in-house development of a communications front-end processor to remove the character-by-character nature of the Sigma's normal communications controller. The front-end was made from a Microdata 1600/30, a custom interface, a custom operating system (including a few specially-coded instructions added to the microcode), and extensive modifications to the Sigma's operating system. It was built in 1974/1975 and placed into service in 1976.

The teletype model 33, also known as the ASR33 (Automatic Send/Receive), was a fairly reliable mechanical unit. There is more on Wikipedia at http://en.wikipedia.org/wiki/ASR33 including links to other articles, and videos of one in operation.

While we were developing our front-end communications equipment, one person was working away with an oscilloscope and debugging the interface to the Sigma. The card was sticking out on an extender. Once, while leaning over the card to move the scope probe, his metal tie tack crossed a few pins and CP-V promptly crashed with an interrupt stack overflow. After that it was standard practice for him to remove his tie, or at least the tack!

Our front-end had two interrupts into the Sigma: one for I/O from the Sigma to the front-end, and one for the other direction. After careful consideration I specified the priorities for these, which was then implemented in hardware. After a week or so of actual operation, CP-V crashed and the dump revealed it was in my front-end code. Some head-scratching later, it dawned on me that the priorities would have to be reversed, which was easily done. One of the many times Murphy's Law struck.

In late 1975, a remote batch terminal was installed to allow UW users to access a CDC-6400 at Colorado State University. This afforded considerably more computing "horsepower" but only for batch jobs.

Some time around 1975 or 1976 several minicomputers were purchased to augment administrative data processing. The systems were Microdata 1600s, running an operating system called "Reality". These used a query language dubbed "English" (they even trademarked "English" and gleefully pointed out that you could talk to their system in English). Later the operating system would be ported by its developer onto other systems including PCs; this is the Pick operating system. These were fairly successful though the Sigma still did the heavy processing. The systems were dubbed "AMS" which apparently stood for Administrative Minicomputer Systems, though it was commonly thought to stand for Atsa-My-System. The AMSs would span the Sigma era and continue well into the Cyber era, until an IBM system was acquired to take over most of the administrative needs.

The Sigma-7 (and IBM 1401) were officially retired at 7:30 PM on Friday, May 30, 1980. They were left powered-up for a while just in case some crisis arose, but none did.

During the 10 years UW ran Sigmas, lots of interesting things happened. There were power failures, air conditioning failures, even floods when the toilets in the Psychology department's sleep lab (upstairs) overflowed. There were fires when power supplies overloaded. High school students introduced the staff to the perils of serious hacking. On one evening a serious windstorm caused power lines entering Laramie to swing together, repeatedly shorting out the entire town.

I recently (early 1996) ran across another Sigma-era person, Keith Calkins, who helped Andrews University run a Sigma 9 until November 1994! He has a bit of a description at http://www.andrews.edu/~calkins for those interested.

Although UW's Sigma 7 was repeatedly upgraded with more memory and disk storage, and with 9-track tape drives mostly replacing the 7-track units, the 10-year run seems, in retrospect, too long. Some sort of significant upgrade (e.g. to a Sigma 9) should have occurred much sooner, but the failure of Xerox to remain a viable force in the computer industry probably compounded the problem, and meant any replacement would have to be something completely different. At the same time, computing by the late 1970s was no longer a pioneering effort of research and in-house development but instead had become an off-the-shelf commodity. These changes are said to have caused the director to leave UW, to join the faculty of another University to continue hardware development. When this happened around 1976/1977, the new director began the complex task of finding a replacement system, apparently at the urging and with the full support of much of the University. The resulting changes were profound and included more than just the hardware and software.

---

Late News: On March 31, 1999, I received email from Lee Courtney (leec@slip.net) indicating the last known running Sigmas were shut down. I was actually rather surprised that any were still running! Here's his email:

Hi all,

Last night I received Email indicating that what is probably the last operating Xerox Data Systems Sigma systems are being powered down today and scrapped Friday. These were 2 dual processor Sigma 9s located at Robert Plan Corporation, who acquired them via (the now defunct?) Warner Computer Systems.

The SDS/XDS Sigma series played significant roles in the development of computing technologies such as the ARPANET, timesharing, real-time computing, computer use in the liberal arts, and the space program. The corporate history of SDS/XDS is also very interesting and especially poignant given the later personal computing fumbles by Xerox.

As a high school sophomore I first used an XDS Sigma 7 running BPM at the University of Texas at Arlington in 1972 and it helped launch my computing career. Many university students were introduced to computing via the Sigma family and although I never used it, users of the CP-V timesharing system still sing its praises.

I have been attempting to gather as much information, ephemera, software as possible for an XDS/Sigma web page and (more importantly) for archiving at the Computer Museum History Center (http://www.computerhistory.org). If you should have, or know of, ANY information, documentation, history, software, hardware, etc. or have pointers to persons who worked with Scientific Data Systems/Xerox Data Systems systems (SDS, Sigma, and 560) please contact me.

He also wrote --

Per Dennis German, who was until last November the system manager for the systems, Robert Plan (RPC) acquired the Sigma's and what was left of the timesharing/outsourcing customer base from Warner Computer Services as a 'debt' repayment. So it sounds like RPC was never interested in the Sigmas as a going concern, Warner has gone out of business as far as I can tell...

				> I wonder if they shut them down because they weren't Y2K compliant?  Has
				> anyone examined this question?  Just curious, especially with Keith's
				> laptop Sigma emulator.
				

My impression was that Y2K was not really part of the disposal equation with RPC and they viewed them as a nuisance more than a resource. I know George Plue and Keith investigated making CP-V(?) Y2K safe, but sounds like they didn't have, or couldn't find, any takers.

BTW your web page got me started on the Sigma quest - reminded me a lot of my days using the Sigma 7 at UTexas at Arlington.

The good news out of all of this is that Keith and George are interested in seeing a significant portion of their Sigma equipment at the Computer History Center so that will be a very good thing.

And April 20, 2004 he wrote again. A working (workable?) Sigma-5 has been donated to the Computer History Museum, see http://www.computerhistory.org/publications/core/4.1. And Lee has a new email address, which in spam-resistant form is courtney at computerhistory dot org. Thanks, Lee!

Next: The Cyber Era