Valediction

This is my last issue as Editor of Resurrection. I have had a most enjoyable time helping the Society to become established and chronicling the events and activities of the first 18 years, and it is with mixed feelings that I now relinquish this responsibility. I take great pride in the editorial quality of Resurrection over the first 42 issues, but I feel it is now time for someone else to take the publication forward.

I would like to take this opportunity to thank our contributors down the years; without the whole-hearted collaboration of all of them, including many of the most distinguished members of our profession, Resurrection would not have become the institution that it is.

I wish my successor all the best, and hope he or she gets as much fun out of the job as I have done!

Note by the Chairman

The first issue of Resurrection was published in May 1990 and contained reports on the foundation of the CCS and its inaugural meetings in the previous year, as well as articles on restoration working parties.

Every year since then two and sometimes three issues have appeared. The first and all subsequent issues have been edited by Nicholas Enticknap. Sadly for the CCS, this is the last to be edited by him who, after 42 issues and 18 years, has decided to stand down. In his own words, he has had a good innings.

If I may use words taken from a flurry of email tributes received from members of the CCS Committee, we owe him a great debt for so much skilled, professional, and selfless support given for so long. 42 issues all to the same standard is no mean achievement - and is indeed possibly unique in the context of a learned society journal. After 18 years - almost a generation - Nicholas will be a hard act to follow. Needless to say, the Committee is working hard to find a successor, and we are confident that issue 43 will appear in due time, on time.

Thanks you, Nicholas!

John Harper FBCS

John Harper was elected an Honorary Fellow of the British Computer Society just after we went to press with Resurrection issue 41. The following is an extract from the citation prepared in support of his nomination by Roger Johnson and David Hartley, immediate past and present chairmen of the CCS.

John Harper spent most his career with ICL working on a wide range of machines, starting in the early 1960s with the ICT 1500 and Powers Samas PCC and continuing with ICL 1900 and 2900 machines until he retired in the mid 1990s. During his career John qualified by evening study for membership of the BCS and IEEE including becoming a CEng.

With his retirement John began the major task of rebuilding a British “Bombe”. The original machines were developed during World War II at Bletchley Park from an idea of Alan Turing to find the wheel settings used by the German Enigma machine.

John started in 1995 with some drawings which had been declassified and gradually developed a full set of plans from which to begin to rebuild the Bombe. John built up a team of fellow enthusiasts whom he has led throughout the more than 10 years of the project. In the early days he was able to obtain help from engineers who had worked at Bletchley Park or at BTM who supplied many of the original components.

John has raised many thousands of pounds in sponsorship, in cash and kind, to enable the work to be completed. The project has been part of the BCS Computer Conservation Society’s programme throughout and the BCS is the owner of the Bombe!

The culmination of John’s project was the switch on by the Duke of Kent in July 2007. The Bombe is a testimony to the many thousands who worked at Bletchley Park throughout the war - not just the famous few but also the many thousands (mainly Wrens) who just went home when the war was over and carried on with their lives. However, this project would never have been started without John’s enthusiasm and it is a tribute to his persistence that after 10 years the work is complete. The reconstruction is now on permanent public display at Bletchley Park.

We strongly commend John Harper for the award of an Honorary Fellowship.

News Round-Up

The Bombe Rebuild team has completed a major update of its Web site, which can now be seen at https://www.bombe.org.uk/. This is the first significant update for five years, and provides a great deal of new information.

-101010101-

Manchester University has embarked on a project called ‘Digital60’, to celebrate the diamond jubilee of the first running of the first program on the ‘Baby’ computer. Events and activities include a ‘Baby’ programming competition, which anyone can enter. Details can be found at curation.cs.manchester.ac.uk/digital60/www.digital60.org/.

-101010101-

BCS Members who have registered for online members’ access can include the Computer Conservation Society in their preference settings. To set these up first login as a member on the BCS Web site, then on the Welcome page go to the box ‘Manage your membership’. Select the page for ‘Specialist Groups’ and tick the box for Computer Conservation Society, and also select the page ‘Manage my email subscriptions’ and tick the box for Computer Conservation Society.

-101010101-

The Science Museum Library is now fully open for business on its new site at Wroughton near Swindon. This is relevant to the CCS because the ICL Archive is now housed there and therefore accessible, instead of being stuck away and out of sight in Blythe House. “Facilities for readers are first class, and the staff is eager and helpful”, reports Hamish Carmichael. A visit to Wroughton must be by appointment, and there is some necessary procedure and paperwork; details from Hamish.

-101010101-

At Kensington there is a compact display of a typical small punched card office of the 1920s. The equipment comprises a UAKP, a Sorter and a Tabulator, all 45- column and dating from about 1925. The UAKP and Sorter are operational; the Tabulator needs some more tender care to get it going. Any member with an elephantine memory who could give any hints on maintenance and lubrication is asked to contact Rob Skitmore at the Science Museum.

-101010101-

-101010101-

-101010101-

Society Activity

Pegasus Working Party

Len Hewitt and Peter Holland

The Society’s Pegasus as it was nearly half a century ago in its original installation at Skandia in Stockholm in 1959. Photo supplied by Skandia historian Per-Ola Eriksson.

It has not been possible to run Pegasus during the last six months owing to trouble with the cooling system. Following an abortive attempt to fix this, there was a delay caused by a fire which damaged the external 3-phase power supply; then, using a temporary power supply, a further attempt to cure the trouble was made in February. Unfortunately, when it came to testing the work, the machine failed to start properly and this was finally traced to the incorrect connection of the external supply. Pegasus was then run to test the cooling system and it was still found to be inadequate. It was finally decided that a new compressor should be obtained and fitted and we are now waiting for this to be done.

Contact Len Hewitt at .

This is how computers arrived in 1959! Another picture from Per-Ola Eriksson shows our Pegasus outside the Skandia site in Stockholm awaiting installation. An account of some of the hazards that could occur during installation of a Pegasus can be found on page 12.

CCS Website

Alan Thomson

The CCS Web site has moved to a new address. It now has news items and more details about forthcoming events. I suggest you add www.computerconservationsociety.org to your list of favourites, and have a look at it every month. It currently carries a news item on the latest London seminar, on the BBC Micro and its legacy. Distinguished speakers described how the project really came about, and the significance of its legacy for today. The event received favourable publicity from the BBC and elsewhere.

Contact Alan Thomson at

Bombe Rebuild Project

John Harper

Now that our machine is complete and working, the nature of our Project has changed considerably. We run the machine on a regular basis with ample material available from the Bletchley Park archive to rerun. We hope over time to discover how the Bombes were used, with numerous special features or techniques applied.

The relay adjustment to 104 sense relays, as reported last issue, is now complete. There have been a few very minor problems to fix as we went along but these were easily overcome. From what we can tell this low level of incident is about the same level as was experienced on the WW2 machines and is therefore to be expected.

As a joint exercise with Bletchley Park we have now produced covers for two Typex machines, our Checking Machine and a genuine 3-wheel Enigma. These are now all out on display. The acrylic parts were made commercially to our specification but all the rest was made by our team. The photo below shows the Typex machine that we have modified to act as an Enigma in its new cover. The cover ‘rolls’ back to allow access. The covers are lockable but easily opened when we are in attendance and wish to use them. The equipment can be operated with the covers open with no need to move anything else.

Our latest activity is to add stage flood lighting to the rear of the Bombe. As I write, the equipment has all arrived and the Bletchley Park electrician will be fitting this shortly.

Recently a lady who worked from 1943 to the end of the war as a civilian in the Hut 6 Decode Room has visited us to explain how she found the full Enigma settings after the Bombe and Checking machine had reported a good stop. After almost 65 years her memory is incredible. She remembers exact detail of what she did. It is possible that we have now identified a variant of a Typex machine not previously known at Bletchley Park. No doubt I will have more to report on this subject in our next issue.

Our video describing the whole process of Intercepts by ‘Y’ stations through to Ultra has only made slight progress recently because we have been concentrating on the display cabinets and lighting. As they are now complete, we can put more effort into the filming.

I am pleased to report that our Web site has now been updated having taken much longer than it should have done. Our Web site is at www.bombe.org.uk/.

Software Conservation Working Party

Dave Holdsworth

After the BBC jamboree at the Science Museum, I got the offer of the source text of BBC Basic on BBC floppy discs. There is hope that it can be preserved as a historical document. A proof of concept emulation of the BBC Domesday system will be released soon.

I would like volunteers who remember the BBC Domesday (and perhaps some who don′t) to do a bit of beta-testing. Please email any offers to .

Mathematician and Nurse to a Pegasus

Peter Barnes

The author provides a personal recollection of the start of computing at the de Havilland Aircraft Company in Hatfield, at a time when there were 17 active aircraft manufacturers and almost as many computer vendors.

In the 1950s Sir Geoffrey de Havilland was still alive and well. He had designed his first aircraft in WW1 and his company, the de Havilland Aircraft Co Ltd, was prominent in both military and civil aviation. The famous WW2 wooden wonder, the Mosquito, was still operational and the Vampire and Venom jets were front line fighters. The company’s pride was the Comet, the first jet airliner, acclaimed throughout the world as the ultimate in luxury travel. This had beaten into service developments of turbo prop aircraft and, even better, the American jets. Elsewhere the three “V” bombers were at the prototype stage.

At this time there were at least 17 companies with aircraft in current service. English Electric was developing the supersonic Lightning fighter and there were top secret designs for air-to-air missile systems and aircraft even faster than the Lightning. Perhaps top secret is too strong a term, for on a visit to the “factory local” most details could be found simply by listening! All this was happening without any electronic stored computers in any of the companies.

But there were problems at de Havilland. Sir Geoffrey’s own son had died when piloting the experimental dH108, which broke up while attempting to exceed the speed of sound. And two passenger-carrying Comets had disappeared in mysterious circumstances. The full extent of metal fatigue was not understood. Was there a “sound barrier”?

Most aircraft manufacturers did the “milk round” of universities in the spring term. You just put your name on a list for interview. Aircraft companies were popular because with the Cold War still in progress they could offer exemption from National Service. With a mathematics degree from Manchester University and a postgraduate course in aeronautics at the City & Guilds College (part of Imperial College), I was able to obtain an interview at de Havilland, and was offered a job. This was in 1954: the company was still feeling the effects of the Comet crashes and it only took on two graduates that year, both mathematicians!

First computer steps

My first months at de Havilland were spent getting my hands dirty - calibrating the low speed wind tunnel next to a water tank where a Comet was being tested to destruction for metal fatigue. Then out of the blue I was asked if I would like to work with computers. The logic was that I had a maths degree and had studied supersonics so, just add computing and I could be useful to the engineers who would do the real work.

My tutor was the late Peter Hunt, who was soon to move to Ferranti and later went to Leasco. He had attended the 1953 computer course at Cambridge and had programmed the Elliott Nicholas computer to calculate flutter coefficients for the Comet 2. I wrote simple programs for the NPL Pilot Ace and Nicholas. There was no chance of actually running either and with Peter I learnt to desk check programs! Then the real thing! I was told to invert a two by two matrix and run the program on the Elliott 401, then at Rothamsted Research station. With no tape comparison machinery we punched two tapes and held them together to check them.

It was at this stage that Peter left to join Ferranti. Meanwhile de Havilland had won a contract to calculate the flutter coefficients of potential wing shapes on the ill fated TSR2. This was a top secret project. I was given the relevant equations and told I could use the Deuce computer at RAE Farnborough. Deuce was in its day a fast machine, provided one mastered optimum programming and its four-address code. I learnt to work with punched cards, and to work in floating binary and convert answers in that form in my head! As a visitor to the RAE I was low down the program testing queue, so working through the night was usual.

It was now early 1956, and de Havilland was seriously thinking of having its own machine. Aided by my year’s computer experience it was time to work out the “whats” and “hows”.

What?

As well as 17 aircraft manufacturers, there were almost as many computer suppliers. Some actually had working machines, others only “design concepts”.

The factors we considered were more practical than financial (Pegasus cost around £40,000). Calculation speed and the availability of standard library routines were important, as was the availability of a service bureau machine to be used before delivery of one’s own. Delivery dates were all “around 9 months”. As Professor Hartree noted all had a “Hartree Constant”, which was the unchanging reply to any question of “When?” at any time.

Finally we chose the Pegasus but at the last minute there was a hitch. I was summoned to the Chief Aerodynamicist’s office. He had been telephone by the titled owner of our neighbouring aircraft manufacturer. They were considering buying an “X” computer. Why weren’t we? Fortunately he was a practical engineer and a distinguished Fellow of City & Guilds and I just happened to be wearing my C&G tie! “X” was a theoretical design, which is why we had passed it over.

Having been so involved in flutter problems I had neglected to look for other potential problems to run on the machine. There was not much printed literature available so I wrote a description of the computer and outlined what it was good at. Almost everyone in a department who had seemed content with slide rule bashing suddenly wanted more and more calculations. The exception was the Stress Office, which seemed suspicious of anything to do with computing, a factor which persisted throughout my time at de Havilland.

How to run it?

With plenty of potential work the next question was to supply programmers and machine time, which called for recruitment and use of Ferranti’s service bureau. de Havilland decided to form a Mathematical Services Department with myself as head and a Chief Mathematician as deputy, a Chief Programmer and five other programmers, a computer librarian to look after program tapes, two data preparation girls and, eventually, our own engineer. At the beginning we did not plan for computer operators: users and programmers would run their own programs. We recruited most of the first programmers from new graduates. We developed our own aptitude tests and used the company training school for the tests and interviews. Later we needed operators and we again developed aptitude tests and recruited from internal staff.

I was allowed the privilege of digging the first sod on the site of the new machine block, which was soon finished and awaited its precious occupant. The digital machine was to be at one end with an analogue computer at the other. There were no special arrangements for air conditioning; the one concession was to have cork floors to avoid the engineer getting electric shocks! The Chief Mathematician and I had our own offices, with one for visiting users. There was a library, a data preparation room and a general programming office. Between the digital and analogue machines was a shared engineers’ room.

Delivery

After the expected nine months and at least two applications of the “Hartree Constant” the pre-delivery procedure started. I went to the factory at West Gorton where Pegasus number 9 awaited our tests. We had prepared a test program, which produced known results in a known time and hopefully in the process checked all the machine’s logic and mechanical parts. It took several days to get the machine to work at all, but when it finally did it passed the test. The next stage was to transport it to Hatfield.

By now it was August 1957. On a Saturday morning a crane and a delivery truck arrived. The drum, the very heart of the machine, was first off. It was packed in a large heavy box, suspended on four wires. Snap! One broke and there was the drum some 10 foot up swinging wildly. It was not a happy delivery! It was at least two weeks before the machine finally worked. Then a loud shriek announced that a read head had touched the drum surface. Luckily the drum was large enough to have space for spare tracks but it took several days and much fiddling to repair.

What was delivered

Pegasus number 9 was a standard Mark 1. The drum had 5120 42-bit words, 39 bits for the programmer and numbers and three check digit bits.

The clock speed was 333 kHz, which provided an add time of 0.3 milliseconds, multiplication of 2.0 ms, division of 5.4 ms and an average drum access of 9 ms. Unlike some contemporary machines Pegasus had software based floating-point operations using a 30-bit mantissa and 9-bit exponent: a floating-point addition took some 18 ms. There were 444 plug-in packages, over 1200 valves and nickel delay line working storage. Input was by 5-hole paper tape readers working at 200 characters per second (cps). Output was by a single paper tape punch at 25 cps then hand fed to a reader working at 7.5 cps.

An important consideration in choosing Pegasus had been its Programming Library, a free service provided by Ferranti. All users were encouraged to contribute programs to this Library. Of particular importance to us was the Pegasus Matrix Interpretive Scheme. This allowed programs to specify a single matrix operation whilst taking care of all the floating point and logical problems. A primitive autocode system was also available but its consumption of machine time had to be balanced against any saving in programming effort.

Programs and data had to be fed into the computer. Our input or data preparation machines comprised two teleprinter/punches, machines which both printed tape and had a keyboard to punch tape. We also had a tape comparison machine. This was seldom used, as our data preparation staff proved so fast and accurate that punching two tapes and comparing them was not worth the time and effort. Against the then standard punched card rate of 7000 key depressions an hour, our staff achieved 14,000!

With these hardware and programming tools we now had to produce useful results!

Maintenance and reliability

Pegasus was supposed to be reliable and easy to maintain. You had spare packages, changed three in a given sequence each day, and replaced valves before they began to fail. Each morning the engineer ran his test programs reducing the voltage by 10% to show up faulty circuits before they failed in service. Our main work on flutter calculations took around three hours to run. The mean time between breakdowns was less than three hours! No re-starts were possible; the machine had no space.

Christmas 1957 was cold and after a long switch-off over the holiday Pegasus rebelled. The drum took over 12 hours to reach its required speed! We rapidly concluded that switching off was worse than leaving the machine on. Valves cost over £3.50 each, and even new ones sometimes failed on their first switch- on. So we abandoned package changing and then morning maintenance. It took some nine months before we finally reached 100% uptime, defined as the ratio of useful time to switched-on time. Meanwhile we faced some human engineering problems.

Engineering Support

At first it seemed easy. Ferranti supplied an on site engineer for one shift, five days a week. But as usage increased to two shifts, then three shifts, the expense increased rapidly, and as reliability increased a site engineer had little to do and our Ferranti engineer became unsettled, as he felt out of the manufacturer’s promotion race. We therefore recruited our own engineer and paid him to be on call. This led to other problems; we found his “on call” number to be that of his local! What to do?

A frequent visitor to our now vacant engineering room was the chief works electrician. Known to all he was often seen being driven away in Sir Geoffrey’s modest chauffeur-driven Morris 8 on Sir Geoffrey’s personal business! He volunteered to be our “wireman” if some one else knew the electronic logic. Our Chief Programmer volunteered and he and I hurried to West Gorton and spent two weeks learning how Pegasus was supposed to work. I must admit that in this time I learnt only how to run my fingers along a row of packages until the machine failed! This combination kept Pegasus going for some time until more formal arrangements were made with qualified electronic engineers from our analogue computers.

I must mention the mechanical parts. Paper tape readers proved sensitive to colour tape. Quite why I never found out but some minor adjustments had to be made to get them to read, say, red rather than white tape. Likewise the tape punch proved sensitive - a problem solved by keeping the tapes moist with a small saucer of water in the storage bin!

Having Fun

The arrival of the first computer had attracted much attention throughout the factory. People wanted to see the machine and also wanted to work with it, as programmer, operator or in data preparation. Top priority were airline customers as our sales staff were keen to show how advanced our company was in aircraft design. At Christmas we put on a carol service, putting out the lights to show the flashing bulbs, and by connecting a speaker to a timing package we could play tunes. The hand keys provided a keyboard!

As a young department, average age below 26, we were somewhat thirsty and acquired a Flowers Bitter Dragon, which held in its claw a red tube with a bubble which when warmed rose to the top. We placed this on top of Pegasus and from time to time a bubble rose up. I convinced unsuspecting visitors that each bubble represented a round off digit from its calculations!

Our youthful activities had unexpected advantages. They attracted more and more potential users who saw the advantages that computers could offer, and more people wanted to join the Department as well.

Security

I cannot recall taking any special security measures. The whole organisation worked in a security conscious manner anyway, as most projects were either commercially or nationally secret. As a fire precaution we kept master program tapes and carry forward pay data in the company’s master safe, which was within our office block. There were however two security leaks and both concerned the payroll.

First, one of our programmers read an input tape in advance of a payroll run when annual pay rises were expected, and soon all our computer staff knew their rises! He was severely reprimanded. Second we had recruited a young operator who had served a prison sentence (our Staff Department were keen to recruit such a person to meet their “disadvantaged persons” quota). I agreed provided that he passed our tests and that they accepted his integrity. A bright person, he easily passed our tests and was a good, keen operator, willing to work odd shifts. Eventually we found out why he liked night work. He observed the cash movements before the works pay day and supplied details to his ex- prison friends who were planning a major raid on the company safe!

Maturity

It is difficulty to say when our department reached maturity, but using my personal life as an indicator I got engaged just after we took delivery of Pegasus and married a year later, in August 1958, so that was when I had the confidence to take a honeymoon! By then reliability was such that we were working three shifts, and machine time had to be prioritised between testing new jobs and running production work.

The job of computer librarian had become one of the most important in the factory. Fortunately we had recruited a more mature person. Brenda was all of 35! She rejoiced in being called “Auntie” by all. Unless you were a full Board Director any attempt to beg machine time for your project was useless. You accepted your allocation with grace!

What we did

From a starting point of flutter calculations (vibrations which could lead to metal fatigue) we progressed into design, particularly into an area of lofting. Lofting is a term going back to sailing days when the full size drawing of a sail was drawn out in the loft above the workshop. Pegasus was used to “draw” the aerofoil shapes adjacent to the fuselage onto other outboard aerofoils. The mathematics were complicated but solved by our Chief Mathematician. We took this idea further and designed the entire tail structure of the Trident airliner on the computer and set these into machine tool instructions to make a wind tunnel model. This work suited Pegasus as it involved little input and output.

Our Sales Department was most interested in using the machine and we developed programs to project aircraft performance over given routes. This again suited Pegasus. The basic data about an aircraft could be input on a paper tape loop. The calculations on what the aircraft had to do were held within the machine and the route data held on another loop on the second input drive. Thus the machine could be set to run for many routes without exceeding the internal storage and with little operator intervention.

Our sister company de Havilland Propellers made use of the machine for calculations in the design of guided missiles, including the air-to-air Side Streak and the ground-to-ground Blue Streak.

Not quite so successful were our attempts to analyse flight test data. This was produced on streams of paper or wires, which then needed to be punched into paper tape for entry into the computer, a time consuming task. Output was often required in graphical form, and we could not connect Pegasus directly to a graph plotter.

Our Aerodynamics Director was keen to expand computer usage across the factory and he persuaded (ordered) me to undertake the company payroll. This was theoretically impossible given that we had no magnetic tape or line printer! We finally implemented this in 1959, writing our own program and running a weekly payroll for some 3000 staff.

Summary

Some lessons we learnt:

• to use outside help when we lacked knowledge; we organised with Hatfield College (now the University of Hertfordshire) some of the first courses of numerical analysis

• to write our own aptitude tests for programmers and operators and recruit internally where possible

• to document our programs and run a tight library

• to teach potential users the pros and cons of using Pegasus

• to use internal resources for engineering support

• to prioritise machine usage within the limitations of our machine

• and above all the importance of having the support of a management which put technical matters before politics!

By 1959 my own work was mostly outside the Aerodynamics Department. I had become involved in machine tool control, stock control and production control. I remember making a simple calculation at the time: Boeing, our main competitor, had about 10 times our computing power. Our near neighbour which had favoured an unproven machine had produced a fine aircraft which was too heavy to be commercially successful, but had no computing power to reduce its weight.

The Comet Mark 4 made the first commercial jet transatlantic flight in 1958 but Boeing’s rival 707 soon ruled the skies. New and larger computers were now available, and by 1961 de Havilland had an IBM 1401 and an English Electric KDP10 on order. Pegasus was still working then. I believe it had served its owners well; what a bargain for around £40,000! Or was it really too little and too late? Would the use of computers have helped us to avoid the problems of metal fatigue and of airframe break-up when exceeding the sound barrier? We will never know! But I suggest most of the lessons we learnt then still apply.

Editor’s note: Peter Barnes, a member of the Committee of the Society, was Head of Mathematical Services at the de Havilland Aircraft Company Ltd from 1954 to 1961. He can be contacted at .

Scapa - a System for Post Colonial Agriculture

Colin Leakey

In the fifties and sixties, agricultural development projects in underdeveloped countries sometimes went disastrously wrong. Scapa was a computer system conceived to banish such problems to the past.

My story starts as post colonial development initiatives to upgrade tropical agricultural production to resemble Northern norms more closely were failing to achieve the desired results. Well-known scandals of ill-spent money included the Groundnut Scheme in Tanganyika (now Tanzania) and the Gambia Egg scheme.

Could computers help to avoid these problems? By the mid 1960s computed solutions to linear programs were aiding the formulation of fertilisers and animal feeds. Desktop electronic calculators such as the Olivetti Programma 101 were being used with programs written in Basic to make analysis of experiments more rapid and simple for agricultural scientists such as myself.

Enter Graham Tottle. Graham had five years experience as a colonial administrator in pre-independence Uganda in the late 1950s, in Kigezi District where a large scale resettlement project had been implemented. He returned to Britain in 1962, and joined English Electric’s then embryonic Systems Programming Division.

His intention was to bring his new skills to the benefit of Uganda and other emerging newly independent countries. He saw that the application of computers to the management of smallholder schemes could improve the smallholders’ lot as well as that of Governments, and provide management with a tool for traceability of produce to particular farms as a key factor in quality control.

It was this vision that became the driving force behind the Scapa project. Graham, by now with ICL, wrote a paper for the British Computer Society in 1969 suggesting that some of the problems of agricultural development projects going disastrously wrong might be averted by the carefully conceived introduction of information and communications technology.

Meanwhile Professor Gordon Black of the University of Manchester Institute of Science and Technology (Umist) had been appointed consultant to ICL. Charlie Portman of ICL Research explored with Gordon in 1975 ways in which ICL might support Umist courses in computer science. A direct line of contact between Gordon Black and Graham Tottle arose from this. Gordon suggested that Umist should explore whether ICL might provide financial and machine support for the development of software to meet major objectives in the Third World agricultural development.

Birth of Scapa

A crucial meeting was arranged shortly thereafter, on 11 December 1976, and this marks the outline matching of the perceived agricultural requirements to the formulation of the required sorts of software needed to address them. This meeting was attended from Umist by Gordon Black, John Triance, John McCormack and D Coleman. It marks the birth of Scapa. The name, coined by Professor Black at this meeting, stands for System for Computerised Agricultural Planning and Action.

Initially it was the administrative procedures used in the 1950s Resettlement Schemes in Kigezi which provided the thought model. At the meeting several of Graham Tottle’s initial planning papers were reviewed and a general outline of what needed to be programmed was agreed.

Another old Uganda hand, Tom Ellis, was able to write a blow-by-blow account of what was required to produce a coffee crop during a typical year’s activities of a smallholder coffee farmer, ie what is needed to be done, by whom, with what resource and in what order. Tom identified 28 different steps.

This was the first and also a model Action List. Over following years a large number of Action Lists were prepared following close discussion between Scapa folk and those who knew about agricultural operations in minute detail. It soon became obvious that the Action List approach to managing agricultural operations was a huge improvement over the much looser descriptions in traditional bulletins.

Subject Working Papers were prepared in plain language by various authors setting out what Scapa was intended to do and how it would do it.

Six purposes of Scapa were clearly defined:

1. To aid in monitoring progress
2. To aid in monitoring costs
3. To provide a definitive up-to-date statement of the state of design and implementation of the project
4. To provide the basis for (developing) user documentation
5. To provide full supporting documentation on completion of the project
6. To provide the basis of information on which enhancements and further developments could be planned.

Implementation

Umist, under the direction of John Triance in close discussion with Graham Tottle, played the major role in the definition of the system design, which was published on 12 August 1977 as a core working paper.

Essentially two quite different kinds of data are needed in the initial planning stage.

The first sets of data are of the things that need doing, and physical inputs for them, sequentially over time, that had historically been conventionally described in agricultural advisory pamphlets known as Extension Bulletins. These were expressed on a unit area basis, such as seeds or numbers of plants or units or fertilisers in lbs per acre or kgs per hectare. These would form the basis of Master Action Lists for the crop production in question.

The second kind of data concerns land and labour resources. These resources needed to be set out at three hierarchical levels, called Plot, Farm and Nucleus levels. This resource information would need to be entered by survey and enquiry and would be relatively fixed. These data sets would be Profiles.

Once the initial data was captured then a third set of data could be derived by using a computer to match the Action Lists to the actual areas of Plots upon which the crop in question with that set of actions was to be grown. These would form Farm Plans, where Farms could embrace one or more Plots.

During the succeeding production phase there would be periodic (normally monthly) exchanges of information to and from the farms. The farmer would be reminded about what events should occur during the coming month, and would report back on what had actually occurred or failed to occur during the previous month. These reports would be on computer prepared forms: deliveries and collections would be handled manually, and transported by bus or whatever, to allow the data to be entered in the computer.

The beauty of the system was that the monthly plan requisites and the returns could be analysed and aggregated and exception reports generated, which would serve the function not only of monitoring but allowing problems to be timely attended to by the Government staff supporting the farmers. Where problems were recognised such as unusual rainfall or failed deliveries of inputs, revisions could be made to the plans.

John Triance was designated chief of program implementation, which was to involve the new ideas of Jackson Structured Design. That in turn would facilitate distributed effort with different programmers working semi- independently (at home) on parts of the software using common codes and protocols so that they could be cobbled together in the overall package. That was a revolutionary idea in the harnessing of many person-hours to the creation of a large package.

Umist recognised there would have to be qualified agriculturalists on board who could stand as surrogates for those in the projected user environments, and ask awkward questions while there was time enough for them to be addressed. That became my role: I started working with ICL as an agricultural consultant in 1977.

Expansion of scope

ICL was already well positioned in many other ex-colonial territories, such as the West Indies, Malaysia and Singapore, where the pattern and norms of rural development were very different from those in east and south-east Africa.

Tom Ellis and Graham Tottle had spoken to Norman Speller, the Director of ICL dealing with the bidding for large defence contracts, who had sent papers on to ICL’s office in Kuala Lumpur and other south-east and east Asian countries for comment. The Malaysian Ministry of Agriculture already owned a large ICL mainframe and the Rubber Industry Smallholders’ Development Authority, Risda, was currently using it to develop a database of 60,000 smallholder accounts with the assistance of ICL’s staff.

The local ICL Manager in Kuala Lumpur took Norman Speller to visit the Director General of Risda, Mohammed Nor. The possibility of using Scapa to make operational use of the database information already being assembled was immediately obvious to Dr Nor.

Graham Tottle held initial and then detailed investigations and discussions in Kenya, and with Tom Ellis and Chris Bartlett of Reading University and shortly afterwards with myself in Malaysia with Risda, to see how the requirements of the various institutions on the ground could map onto and be supported by the proposed Scapa facilities. In both Kenya and Malaysia the situation was promising. The Kenya Coffee Co-operative organisation and the Rubber Industry Smallholder Development Authority were both very substantial institutions with large numbers of smallholder clients, or in modern jargon stakeholders. Coffee in Kenya, rubber in Malaysia and also banana exports in the Windward Islands all depended to substantial extents upon smallholder production as well as on larger estate operations.

Risda had 600,000 rubber smallholder records, averaging about 10 separate files per farm, needing to be serviced. It had already intended to acquire its own ICL mainframe to become independent of the need to use that of the Ministry of Agriculture, and was implementing the setting up of a large relational database from which useful spreadsheet tabulations for management’s use could easily be prepared instead of compiling these by hand from the large number of files containing what were known as “pink forms” held on each smallholder.

There was also positive feedback from discussion in the Windward Islands, but no detailed feasibility study report was prepared.

Obtaining funding

It was now time, after the two initial feasibility studies, to report to ICL on the outcome of the Kenya and Risda visits, and then to send papers to the Overseas Development Administration (ODA) for a meeting which it was hoped would open up funding support for writing Release 1 of the software.

After clearance within ICL, a meeting was called by Peter Stutley of ODA with himself and George Gwyer for ODA and Graham Tottle and myself for Scapa. I recall this as a warm and positive meeting with Stutley and Gwyer both firmly on-message, even enthusiastic, which is rare for civil servants. Graham was elated. The one hurdle was that a committee of “expert” advisors to Government, called Escor, would need to give their formal approval. Stutley and Gwyer were to present Scapa and the supporting papers to the next scheduled meeting of Escor and clearly expected to gain agreement.

No Government funding support for university research programmes is however won without competition. It transpired that Umist was going head to head with Oxford to take from the pot, and in the event Oxford’s Food Supply Analysis Group was funded in preference to Scapa. This was a very dark day in the life of Scapa. As Graham wryly put it of the Oxford people by way of partial explanation “The Group had impeccable credentials, came from an impeccable University, spoke the same language and had no sordid commercial connections”.

ICL top brass were saddened but not put off. By this time the Scapa proposal document had excited a good deal of interest within the company and Scapa was seen as having a useful contribution to make to maintaining and enhancing ICL’s image with some major customers. If the Scapa software could not be written in a university environment with Government support it was still worth doing and would have to be done another way.

Bill Talbot, Graham Tottle’s immediate boss, took swift action and set up a budget with the support of Doug Comish, Director of ICL’s International Division. The competition for another pot of money was now between support for the Middle Eastern Oil tycoons and support for Scapa to be developed collaboratively in association with Risda and ICL’s Malaysian team and using ICL’s own programmers. Scapa this time happily won.

Developing the software

As a result of the Malaysia feasibility study undertaken by Graham Tottle and myself, Mohammed Nor was keen to go ahead with a pilot project as soon as possible. He had not appreciated that what the feasibility study was testing was not the Scapa software itself, which did not yet exist, but the matching of the ideas of inputs and outputs and the logistics of handling raw data that would be programmed if the feasibility study came up positive.

The Kenya Coffee Marketing Board, following the study by Graham Tottle, Tom Ellis and Chris Bartlett, was quite interested but not in such a hurry.

It was now necessary, if severe disappointment and loss of face in Malaysia was to be avoided, that the actual software be produced as soon as possible.

Discussions between ICL and Umist in 1977 had been productive, and what was agreed had been written into the Scapa Proposal, the most important early document.

It was agreed here that the programs that comprised the overall system would have standard formats for their specification, based on those of IBM since these were part of the common understanding of the programming fraternity. The programming would be from JSP structure diagrams and coded in a high level language which would probably be Cobol.

All files would comply with standard file definitions which could be tailored for any particular user to correspond to their own chosen definitions. Numeric input would include a check digit in order to try to expose and throw out finger and other data entry errors.

After the decision that ICL should produce the software itself, new opportunities arose for taking the innovative route of programming by home workers and for this to hasten the completion of the software.

ICL had a core of trained programmers who had left day by day employment at West Gorton and wanted interesting work at home which could be combined with household work. Each programmer was supplied with a terminal linked to a mainframe via an acoustic coupler. The home programmers would phone in to Gorton, hear the connecting signal, place their phones’ earpieces directly into a slot on the terminal and key in a password. Thus they were able to type their program work directly into the George 3 operating system of the main computer. At this date, around 1979, this was revolutionary stuff.

Because of the way that the system had been structured, each of the remote programmers worked on their own module in the standard Cobol with which they were familiar.

Graham provided the specifications and the management backup, ensured the logistics worked and organised periodic face to face review meetings, many of which I, as an external, attended which kept me interested and feeling involved despite my lack of programming skills.

Jyoti Paul took the Profiles system: Pauline Dagnell the Action Lists: Margaret Anders the Plan subsystem: and Barbara Smethurst the Progress Review system. Carol Sencicle took the crucial roles of quality assurance (verification and validation issues) and of integration of the subsystems into the main system. George Braybrooke was hired to look after secretarial and logistic matters, and to see to the compiling from the input Cobol into ICL’s own compiler code using carefully-costed time on the in-house 1900 mainframe.

Not all the facilities discussed could be implemented in the first release of Scapa.

For example, David Wright of the University of Sussex was concerned over privacy of smallholder data, big-brotherism and hacking. He and his colleagues in Sussex wanted encryption of all personal data. Since large amounts of personal data is regularly and necessarily handled in manual systems the idea of Scapa profile data needing to be encrypted was suggested as “smacking of woolly headed idealism” by some within ICL.

Roger Barnes of the University of the West Indies and in support of possible implementation of Scapa in support of banana growers in the Windward Islands was interested in expert systems combined with profiles as diagnostics for land capability classification and of possible problems, risks, successes or failures. This, also one of my main foci of interest, was never fully implemented.

Once the work on the software was complete, some interesting simulations were carried out in Cheshire and Greater Manchester in various homes and farmhouses, including the home of CCS Committee member Chris Burton, where his daughter Isobel played the role of a smallholder farmer. After relatively minor debugging as a result, the project was ready to move to the field in Malaysia.

The Risda pilot project was completed with the first release of the system software and judged to have been successful in Kedah Province. Of 200 farms and farmers involved, 196 were still actively supported and participating at the end of the 18 month trial period. During this time further work was done to expand the facilities and subsystems and Scapa release 2 was taken and installed in Kuala Lumpur. It came to support not only rubber replanting but a large number of subsidiary cropping and livestock enterprises which without Scapa logistic support might never have developed.

Sales drive

Following the decision that ICL would itself take on the programming of the Scapa system, the management of the project took a new turn and was put under the control of International Division in Fulham. The primary emphasis was now on developing a marketable product. Henceforward Scapa would have to be fitted into the overall international marketing strategy as a software system that could be marketed in conjunction with hardware sales where any aspect of agricultural support might be among reasons to buy ICL computers.

I now assisted Graham Tottle on visits to many countries to talk about Scapa but more importantly for us jointly to probe and get to understand the existence of problems which Scapa might potentially help to solve and explain how this might be done. Many of these explorations were extremely interesting.

In Bulgaria a forward looking senior planner in the Silistra Province of the north east of the country, near the Black Sea and just to the south of the Danube, had persuaded the higher echelons of Government, then still rather rigidly old style communist with a command economy, that it might be advantageous to explore ways to overcome the regular difficulties and inefficiencies of the large “Agrocomplekts”. Mr Yantchev had authority to explore “Western” possibilities for this one province.

Graham Tottle had made a preliminary visit and then invited me to join him for an intensive 10 day study. We had to be shown all the problems and with Mr Yantchev to talk through the ways in which Scapa could help. This could have been very beneficial to both parties in a country where ICL was already well known and had machines in place.

However the whole Scapa project was suddenly axed when a Bulgarian team was about to come over to the UK to help carry the work forward. The axing followed a Cocom edict, as helping agriculture and the provision of further ICL computers and software might also have shown the way to improve military efficiency. This was deeply depressing.

In what was still Southern Rhodesia and about to become Zimbabwe, the Lancaster House Agreement provided for opportunities for some settler farmers to leave willingly and sell out honourably so that some large farm units could be used for resettlement of returning “freedom fighters”. The thoughts of Progressives of course proved over-optimistic in the event, but here was an apparent opportunity to plan the logistics and support of resettlement using Scapa as the principal management tool.

We met some still optimistic white agriculturalists and planners and had some good interactions with Shona farmers who were already experiencing resettlement and the problems that were emerging. But it was not to be. Too much in the Lancaster House agreement was mirage rather than reality.

In the Philippines where a Scapa supported smallholder tobacco project might have emerged, the land area that would have been used for tobacco farming now lies beneath the lava flows from the catastrophically erupted Mount Pinatubo.

Other countries where our explorations to explore potential markets for Scapa took place were Zambia, Malawi, Uganda, Indonesia, Egypt, Hungary, China, Sri Lanka, Ghana and the Windward Islands.

Potential there certainly was. The field pilot project in Malaysia had proved a success, but ICL had made a commercial decision to sell Scapa for £20,000 per user and it could only run on ICL mainframes. By now the revolution towards microcomputers was well advanced and ICL, shortly to merge with Fujitsu, was determined not to enter that arena. The plug was pulled.

Graham Tottle was allowed to retire from ICL with Scapa as a dowry to see what could be done using PCs. John Triance meanwhile set up Micro Focus, and this was crucial in enabling the main ideas of Scapa to be scaled down for use on PCs under the name Scampa. But that is another story.

Acknowledgment

The author would like to thank Graham and Alison Tottle for so much hospitality and friendship as well as encouraging participation of a non-computer-buff in such an interesting project; also Chris Burton and his daughter Isobel; also members of the Faculty of Technology in Lincoln University for sustaining an interest in computation. Chris and Graham both read and commented on parts of the text, and I thank the Editor for the excellent compression of a much lengthier original text, but nobody other than the author should be blamed for any errors, commissions or omissions in the article as published.

Editor’s note: Contact Dr Leakey at .

CCS Web Site Information

The Society has its own Web site, which is now located at www.computerconservationsociety.org. It contains news items and details of forthcoming events and also electronic copies of all past issues of Resurrection, in both HTML and PDF formats, which can be downloaded for printing. We also have an FTP site at ftp.cs.man.ac.uk/pub/CCS-Archive, where there is other material for downloading including simulators for historic machines. Please note that this latter URL is case-sensitive.

Elliott Computers

Simon Lavington

This article by the leading historian of Elliott computers provides a brief but comprehensive overview of the various strands of computing associated with the name Elliott from the first digital project in 1946 to the closing of the Borehamwood factory in 2003.

In 1957 the Elliott-Automation company was formed from Elliott Brothers (London) Ltd, which itself had its origins in the Elliott Instrument Company founded in 1804. One way or another, Elliott had been involved in the design of analogue computers since about 1916 and of digital computers since about 1946. In 1961 Elliott supplied half of the 84 digital computers delivered to UK customers in that year, according to the contemporary publication Computer Survey.

Yet by 1968 Elliott-Automation had effectively disappeared in a flurry of takeovers, leaving little apparent trace of the technical excellence that had once characterised the name Elliott. That this technical excellence managed to flourish at all in postwar austerity Britain was due to the inspiration of two men: John Coales and Leon Bagrit.

In 1946 the much-reduced Elliott company was trading at a loss from its factory at Lewisham, where the number of employees had shrunk from about 4000 to under 1000. Nevertheless, partly due to the company’s long-standing provision of analogue computers for naval fire control, the Admiralty decided to set up an Elliott Research Laboratory in a redundant fuse factory at Borehamwood, tasked with developing an innovative ship-borne anti-aircraft gunnery predictor that the Admiralty termed the Medium Range fire-control system, MRS5.

In addition to requiring the development of an advanced target-tracking radar, the contract stipulated that the MRS5 project was to be digital. In 1946 this was a scarcely credible decision because all military control equipment up to that point had been analogue. Indeed, analogue techniques were to dominate defence electronics well into the 1960s. Nonetheless, the MRS5 contract called for an online, real time digital computer to control the target-following radar.

John Coales, who had led the Admiralty’s wartime radar research effort, was the first Director of the Borehamwood Labs. He tackled the MRS5 challenge with the infectious enthusiasm of a first class academic who has just been awarded a large research grant. Starting with just 45 staff in October 1946, Coales’ team of scientists and engineers had climbed to 400 by 1952.

An inspecting officer reported to the Admiralty in December 1948 that Borehamwood “have a highly competent, immensely keen team of scientists and engineers on the job, and are investigating new techniques and methods in a large number of fields. If we can be but patient I personally believe that something quite startlingly good will eventually be produced by this group. It is of more than passing interest that visitors from the US Navy and US industry have been more impressed by the work going on at Elliotts than at anywhere else in this country.”

The real time computer upon which Coales’ team worked was called the Elliott 152. It had a multiply time of 60 microseconds and first ran a program in 1950. For comparison, the American Whirlwind real-time computer first ran a program in 1951 and had a multiplication time that varied between 36 and 44 microseconds.

Alas, Coales’ enthusiasm did not succeed in making a profit for Elliott in the market place. That task fell to Leon Bagrit, very much a self-made entrepreneur, who became a Board member of Elliott in 1947. Bagrit reorganised the company, took out manufacturing licences for American equipment such as fluid flow regulators, and began an energetic pursuit of his dream of industrial automation. He was knighted in 1962, was invited to give the 1964 BBC Reith Lectures, and became known in the Press as Mr Automation.

By 1952 the company was making a profit, Coales had left for Cambridge University, and Bagrit had started negotiations with the National Research Development Corporation (NRDC) for a contract to produce a small, reliable digital computer that would complement the much larger Ferranti Mark I machine, the first production version of which had been delivered to Manchester University in February 1951.

The NRDC/Elliott 401 computer was exhibited at the Physical Society Exhibition in London in April 1953, where it caused quite a stir because, up to that point, all Borehamwood’s work had been classified and most people were unaware that the Elliott company had any interest in digital computers.

By 1953, Andrew St Johnston had become the Manager of Elliott’s Computing Division at Borehamwood. He took some pride in explaining that Borehamwood was the only UK group that had been designing computers without the direct help of a university or government establishment.

Tables 1 (above) and 2 (facing page) summarise the Elliott analogue and digital computers produced by the Borehamwood Labs. Technical details of the digital machines will be found on the CCS web pages at www.ourcomputerheritage.org/wp/ and in a number of past Resurrection articles written by the pioneers themselves, particularly the article by Laurence Clarke on pages 15-22 of Resurrection issue 41.

Of the earliest Elliott machines, few artefacts remain. The 401 has, fortunately, survived and is currently being restored by a CCS working group. An Elliott 803 is alive and well at the National Computing Museum at Bletchley Park. Several working 900 series machines survive, mostly in private hands.

By way of further explanation of Table 2, the Elliott 152 employed an anticipation-pulse electrostatic RAM based on the original Williams Tube patent but operating at three times the speed of the Manchester implementation of CRT memory. The 152’s plug-in units were based on printed circuits on glass plates, with plated-through holes, deposited resistors, semiconductor diodes and sub-miniature pentodes. This cutting-edge technology unfortunately became a bleeding edge: the 152’s reliability left much to be desired and the MRS5 contract was eventually curtailed by the Admiralty.

The Elliott 153, installed at Irton Moor, Scarborough in August 1954, was employed for Direction Finding (D/F) under a joint GCHQ/Admiralty initiative. The purpose of the 153 was to get the best ‘fix’ as quickly as possible from a group of incoming D/F estimates, transmitted by teleprinter from several distant listening stations world-wide. It is said that the 153 was often required to compute 10 new fixes each hour, the results necessarily being required urgently. Fortunately, the reliability of the 153 proved up to the challenge.

The Nicholas computer, which first ran a program in December 1952, was the first truly general-purpose digital computer to emerge from the Borehamwood Labs. It was the first to employ nickel magnetostrictive delay line memory, of 4 Kbyte capacity in this case. Nicholas gave valuable service to the Borehamwood Theory Division for six years.

The joint GCHQ/Elliott 311 project, afterwards known as Oedipus, was a special- purpose cryptanalytical machine of particular relevance to super-enciphered intercepts. Oedipus contained a semiconductor read-only associative (ie content- addressable) memory of 4K words.

Turning to non-classified machines, the 800 series computers, based on transistor circuits and ferrite cores, marked Elliott’s entry into the non-defence digital process control arena, where the company quickly established a lead.

Seventeen 803 machines were exported to America between 1960 and 1963, where they were applied to on-line industrial process control - sometimes via the Panellit company under the badge of Panellit 609 computers. In the UK, a notable first for an Elliott 803 in 1960 was the UK Atomic Energy Authority (UKAEA)’s Calder Hall atomic station project at Windscale (Sellafield). The 803 provided a 24/7 logging and alarm-scanning system for the prototype Magnox gas-cooled reactor, for what became the world’s first industrial scale nuclear power station.

Shortly after this in the same year, an Elliott 803 was installed at Samuel Fox & Co Ltd (later known as British Steel Corporation, Special Steels Division) in Sheffield for an online billet cutting application. A contemporary Elliott- Automation press release stated that this was “the first application of an electronic digital computer to an actual steel process anywhere in the world and the first such application to any industrial process in the United Kingdom”.

On the software side Borehamwood, like many other manufacturers in the 1950s, was (to modern eyes) rather slow off the mark. This was partly due to the small size of Elliott’s Computing Division at Borehamwood which, in 1952-53, numbered only 22 people.

The strain on this group was relieved in 1956 when Elliott entered into a marketing arrangement with the National Cash Register Company, whereby NCR supplied the 405 computer to commercial data processing customers and provided relevant applications programming and software support. This was mutually beneficial since, in the mid-1950s, NCR had itself been slow to respond to the challenge of electronic stored-program digital computers.

In 1959 Dina St Johnston left Borehamwood to found Vaughan Programming Services, the UK’s first software house. Vaughan was instrumental in writing several of the early Elliott 803 process control applications and for the next five years, 92% of Vaughan’s work involved Elliott computers.

Back at Borehamwood, software development gained momentum in the early 1960s, especially in the field of high-level languages. A small team led by Tony Hoare produced the first commercial implementation of an Algol compiler - for the 803 - in 1962.

With the advent of the 900 series computers, Elliott began to make a substantial impact in defence applications where compact, robust digital computers were starting to displace analogue hardware for military applications on land, sea and in the air.

By the end of the 1960s, Elliott’s aerospace activity had largely moved to its Rochester factory. Innovative aerospace R&D grew rapidly at Rochester, with products such as head-up displays making an international impact. By this time GEC had taken over this activity, though the name Elliott continued as a trading name until 1988. Today, BAE Systems, the effective inheritor of the Elliott, GEC and Marconi marques, carries on the tradition of electronic innovation inspired, at least in part, by the early leadership of John Coales at Borehamwood.

But what of Borehamwood as a centre for computer design? Elliott-Automation merged with English Electric in 1967, most of the two merged companies then being taken over by GEC in 1968. The exception was the commercial data processing side of English Electric, which by then included the mainstream computer activities of Leo, Marconi and Elliott-Automation; these all went, along with ICT, to form ICL in 1968.

For a further 20 years, Borehamwood continued the manufacture of small and medium computers under the GEC label, for applications such as telecommunications, control and defence. However, success in the market place was relatively modest compared with the defence-related success of GEC/Marconi in Rochester and elsewhere. GEC/Marconi finally withdrew its presence from the Borehamwood site in 2003.

Editor’s note: This article is based on a talk given by the author to the Society at the London Science Museum in February 2007. Readers who would like to know more will be delighted to learn that Professor Lavington is currently hard at work completing the definitive book on Elliott computers. He can be contacted at .

Letters to the Editor

Dear Mr Enticknap,

I have been meaning to write to you for some time but was prompted by Graham Phillips′s article in issue 40 of Resurrection reference the Elliott 803B computer.

I joined Elliott Computers in 1961 and took over the responsibility for the power system of the 803B from Norman Muchmore. Your correspondent′s memory is correct. The nickel-cadmium battery was made by the French company Saft (which was still in this business a few years ago) and was originally intended for the Canadian air force. There was an external 24V power supply which supplied the working power and the computer could carry on for about 30 minutes after a mains failure which was essential for a process control machine.

There is an interesting anecdote about the batteries. Nickel-cadmium batteries are very sensitive to the voltage level when being float charged and can suffer from thermal run-away. Unfortunately, because the cells were isolated within plastic cases which melted at high temperatures, short-circuits could be created between cells within the battery.

On one occasion when a battery was being re-charged external to the computer this happened. The first approach was to disconnect the battery from the charger but this had no effect. By this time the electrolyte was boiling furiously and creating a loud whistle by exiting through the cell safety vents. The only solution was to go around the entire battery removing the connecting links until the whistling stopped. Since I was responsible for anything to do with batteries I had to do the necessary disconnecting. In retrospect it was probably a very dangerous thing to do.

I went on to design the entire power system for the 503 computer. This machine ran from an internal 24V DC phase-controlled thyristor power supply. No batteries were ever fitted although the possibility was there. The machine did have the ability to shutdown in a controlled order if the mains failed but this was done by a limited amount of capacitive energy storage with forewarning systems to the logic and memory.

While writing there are a couple of things worth noting from my earlier days with Leo. I joined towards the end of the Leo II design and worked for Robert Ferguson who was responsible for the power and peripheral equipment.

One of my first tasks was to install (not commission as this was done by Steve Farrow) the Leo II/3 at Stewarts and Lloyds in Corby (which was still a steel making centre). This is apparently recognised as the world′s first third party business computer.

Readers may remember that the Leo II used the Ferranti drum store on some machines which ran from a 150Hz power supply. The usual approach to this was to provide a separate rotary motor alternator with step-up gears or pulleys. Robert decided to use a device called a tripling transformer, which was well known in the welding industry presumably because 150Hz AC makes better welds than 50Hz AC. It consisted of a standard three-phase transformer which was over-driven to provide a high level of third harmonic distortion which could be extracted by opening the corner of the secondary delta winding. This system was very sensitive to voltage levels but fortunately because the valve anode power supplies were derived from a stabilised motor-alternator set we were able to use this and obtain a stable output voltage.

Another story from the Leo II days was a design defect in the relay and contactor control logic cabinet (made by Lancashire Dynamo) known as the “Xmas Tree Effect”. It was recognised in the early days of valve computers that switching the valve heaters on and off was highly stressful and a major cause of failure, so it was decided to turn the heaters on and off gradually by applying the heater voltage from a motor driven variable transformer over a period of two minutes.

Bletchley overcame this problem on the original Colossus by leaving it switched on all the time. Since the rebuilt one currently on display at Bletchley has to be switched on and off frequently they have had to adopt the same slow switch-on method as the Leo II.

Each logic chassis was provided with a mains fuse with a neon indicator to show when the fuse was blown. These fuses were rated at the normal heater current running level to provide the maximum protection, but were not capable of surviving the full inrush current surge taken by a cold valve heater, with the consequence that a number of the fuses would blow and a quantity of the neon indicators would light up along the centre rack making the machine look like a Xmas tree. I never managed to solve this in my time with Leo but I understand that Robert Ferguson did manage to cure the logic fault later on.

Malcolm Burchall

by email from mab@uwclub.net

20 September 2007

BCS@50 in pictures

The successful BCS@50 event, celebrating the Silver Jubilee of our parent body, took place in July last year, with the first day being held at Bletchley Park and the second and third at the BCS headquarters in London. The event celebrated the early history of computing in the UK, so naturally CCS members were prominent both on the platforms and in the audiences. CCS Committee member Chris Burton recorded the action for posterity, and we show a small sample of his photographs here.

Day 1: 12 July 2007 at Bletchley Park

Much of the attention on this day was focussed on the Society’s two pioneering rebuild projects, with both machines on display. Tony Sale (left) is captured describing how Colossus outputs data...

... while John Harper (right) described how his team reconstructed the Bombe.

Day 3: 14 July 2007 at BCS Southampton Street

Among the delegates discussing events so far during a coffee break are Dan Hayton (far left), Conway Berners-Lee (centre, facing camera), then CCS Chairman Roger Johnson (with coffee cup, facing right), and Len Hewitt (in white shirt).

CCS Committee members involved in the presentations on the final day included Tilly Blyth of the London Science Museum, who chaired the session titled “Computers as marketable products and the public”...

...and CCS Treasurer Dan Hayton, who provided a lighter touch with his presentation on Computers in Film.

Forthcoming Events

Every Tuesday at 1200 and 1400 Demonstrations of the replica Small-Scale Experimental Machine at Manchester Museum of Science and Industry.

Every day Guided tours and exhibitions at Bletchley Park, price £10.00, or £8.00 for children and concessions. Exhibition of wartime code-breaking equipment and procedures, including the replica Bombe and replica Colossus, plus 60 minute tours of the wartime buildings. Go to www.bletchleypark.org.uk to check details of times and special events.

15 May 2008 CCS AGM, followed by London seminar on Programming and Software at Elliotts. Speakers Sir Tony Hoare and Jeff Hillmore.

21 October 2008 NWG seminar on “Computing Before Computers”. Speaker Jane Wess.

18 November 2008 NWG seminar on “Elliott’s Contribution to Computers”. Speaker Laurence Clarke.

20 January 2009 NWG seminar on “Some Cafs Applications”. Speakers Hamish Carmichael and Martin Wright.

17 February 2009 NWG seminar on “Computers in Telephony”. Speakers David Parsons and Nigel Linge.

Details are subject to change. Members wishing to attend any meeting are advised to check the events page on the Society Web site at www.computerconservationsociety.org for final details which will be published in advance of each event. Details will also be published on the BCS Web site (in the BCS events calendar) and in the Events Diary columns of Computing and Computer Weekly. London meetings take place in the Director’s Suite of the Science Museum, starting at 1430. North West Group meetings take place in the Conference room at the Manchester Museum of Science and Industry, starting usually at 1730; tea is served from 1700.

Queries about London meetings should be addressed to Roger Johnson at , or by post to Roger at Birkbeck College, Malet Street, London WC1E 7HX. Queries about Manchester meetings should go to William Gunn at .

Committee of the Society

[The printed version carries contact details of committee members]

Chairman  Dr David Hartley FBCS CEng
Vice-Chairman  Tony Sale Hon FBCS
Secretary, Chairman DEC Working Party and WebMaster  Kevin Murrell
Treasurer  Dan Hayton
Science Museum representative Tilly Blyth
TNA representative  David Glover
Bletchley Park volunteers representative  Pete Chilvers
Chairman, Elliott 803 Working Party  John Sinclair
Chairman, Elliott 401 Working Party  Arthur Rowles
Chairman, Pegasus Working Party  Len Hewitt MBCS
Chairman, Bombe Rebuild Project  John Harper Hon FBCS CEng MIEE
Chairman, Software Conservation  Dr Dave Holdsworth CEng Hon FBCS
Digital Archivist & Chairman, Our Computer Heritage Working Party   Professor Simon Lavington FBCS FIEE CEng
Editor, Resurrection  Nicholas Enticknap
Web Site Editor Alan Thomson
Archivist  Hamish Carmichael FBCS
London Meetings Secretary  Dr Roger Johnson FBCS
Chairman, North West Group  Tom Hinchliffe
Dr David Anderson
Peter Barnes FBCS
Chris Burton CEng FIEE FBCS
Dr Martin Campbell-Kelly
George Davis CEng Hon FBCS
Peter Holland
Dr Doron Swade CEng FBCS

Point of Contact

Readers who have general queries to put to the Society should address them to the Secretary: contact details are given elsewhere.

Members who move house should notify Kevin Murrell of their new address to ensure that they continue to receive copies of Resurrection. Those who are also members of the BCS should note that the CCS membership is different from the BCS list and is therefore maintained separately.

Aims and objectives

The Computer Conservation Society (CCS) is a co-operative venture between the British Computer Society, the Science Museum of London and the Museum of Science and Industry in Manchester.

The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society (BCS). It thus is covered by the Royal Charter and charitable status of the BCS.

The aims of the CCS are to

• Promote the conservation of historic computers and to identify existing computers which may need to be archived in the future
• Develop awareness of the importance of historic computers
• Encourage research on historic computers and their impact on society

Membership is open to anyone interested in computer conservation and the history of computing.

The CCS is funded and supported by voluntary subscriptions from members, a grant from the BCS, fees from corporate membership, donations, and by the free use of Science Museum facilities. Some charges may be made for publications and attendance at seminars and conferences.

There are a number of active Working Parties on specific computer restorations and early computer technologies and software. Younger people are especially encouraged to take part in order to achieve skills transfer.