I worked (and still do) at the University of Kent. We had an early ICL 2960 from 1976-1986. For the early part of that time I was a part time programmer, part-time postgrad; I was charged with a lot of bug reporting. We ran VME/K (it was only a 2960, about 0.29 MIPS with 2MB of memory, 8 x EDS100s, 2 tape drives, 1 SMAC (of course), 1 SAC, 1 DFC, 1 GPC, 1 CLC. And a card reader and printer. It wasn't big enough for VME/B.

VME/K was a minority system (European Space Agency used it). We had a lot of reliability problems, with the 13 week rolking MTBF of the system being about 20 hours. This was partly hardware, but mostly software (e.g. a failed page read due to a defective sector in the swap area would cause a complete crash (FSER) even if only in a user process). I helped to implement an alternate high level scheduler with hooks we found in the VME/K code.

In 1979/80 ICL were due to take us to SV 14, a partial rewrite with less functionality than SV 13! So we looked at alternatives (by this time I was a lecturer in computer science, 50% seconded to 'computer service') and we had heard about EMAS!

I was living on campus at the time, and was asked to look after Peter Stephens when he came down to try out EMAS (that was one of the main reasons I was chosen - I was there!). I remember taking him out to dinner in Canterbury after a pretty successful session. I was then deputed to 'look after' EMAS while we ran benchmarks, etc. We changed over to EMAS properly in December 1979.

I carried on looking after EMAS until close of service in 1986; the rolling MTBF went up 10-fold to 2000 hours; the software was very reliable, and was able to recover from obscure hardware faults such as the DFC freezing (it did this by detecting the freeze, resetting the DFC and reloading its microcode, while queueing all disc transfers). It was also able to report nascent memory faults down to the board *and chip* level, to nip faults in the bud. It benchmarked at 50% more throughput than VME/K.

In 1983 we acquired a second SMAC, OCP and some EDS200s, as well as two more tape drives. EMAS was capable of symmetric multiprocessing, but we had problems with 2960-specific documentation on how to program the inter-CPU stuff, and I eventually resolved this problem (caused by ICL not be able to find the stuff). I reverse engineered the microcode (from fiche listings) and generated a programming spec which I then applied to the operating system. I also found a hardware design flaw in the OCP scheduler, where a particular illegal descriptor would halt the microcode. I wrote a microcode patch to generate a new contingency instead.

We ran the system until 1986, when it was replaced by a VAXCluster. This was a (then) standard 10 year replacement cycle, and new 2900 hardware was too expensive (the 1983 stuff came free; it was part of the system used for the 1980 Census, and had been lying in a government warehouse in Southall until we got it).

I got lots of trips to Edinburgh and got to know a lot of people, particularly Peter Stephens and John Henshall; after John started at ERCC I always stayed with him when in Edinburgh. That's a whole story in itself!

Yes, the 2900 was smart hardware but I guess rather over-engineered to be very competitive. Wonderful internal diagnostic information available; I remember once that EMAS told us that fuse number 3 had blown in the LP; our ICL engineer didn't believe us and said there was no such fuse. We told him to check his manuals, and he shamefacedly came back and opend a small panel he'd never noticed before!

I also helped to convert EMAS-3 onto IBM XA architecture, travelling from Canterbury to Greenford two or three times a week, carrying a mag tape or two. The system worked fine after some initial problems with the VM/XA IPL simulation, which I had to program round (see the first level XA bootstrap code). We never did get our IBM, so that was that for me.

(See also http://pink-mouse-productions.com/icl/bob.htm )