News Round-Up

The Preservation Policy Working Group is searching for suitable partners to host and manage its Auditing Archival Collections project. The long-term aim is to produce a comprehensive database of early computing artefacts. The Working Group has been talking to several interested parties, including the National Archive for the History of Computing and the Public Records Office. One result is that Jeffrey Darlington has been recruited to the Committee as the PRO representative.

-101010101-

Working Group Chairman Simon Lavington would like to know of a major ICL 1900 installation in the Government service, active in the mid-1970s, where there is likely to be a major requirement for long-term preservation of records. This could lead to a potential case study and pilot exercise, which would help to define how the Society would collaborate with other organisations.

-101010101-

The Bombe Rebuild Project team achieved a major milestone in April when it demonstrated the machine with all rotating or moving parts working under DC power for the first time.

-101010101-

An ICL Series 39 Level 80 mainframe is now in the care of the Museum of Science and Industry at Manchester.

-101010101-

Max Burnet, Secretary of the Australian Computer Museum Society, organised a display at the Australian Financial Markets Association show in March featuring a computational item from each of the last 10 decades. The exhibits ranged from a 1900 slide rule to a 1991 Sun Sparc 2 workstation, and included punched card equipment, items from mainframes and minicomputers and several PCs. The display was presented under the auspices of Max's company Burnet Antique Computer Knowhow (BACK).

-101010101-

Our offer of a concessionary rate on the IEEE Annals of the History of Computing has been enthusiastically received: 62 CCS members had signed up as at the end of March.

-101010101-

Leo and the Computer Revolution: part one

David Caminer

The Computer Revolution is analogous to the Industrial Revolution that started 200 years before. The Industrial Revolution changed the whole mode of production and transportation. Workers no longer made objects by hand, they tended machines, and the machines were driven not by human muscle but by steam.

In the Computer Revolution the changes have been different but potentially they are as sweeping. Computers have altered the way in which information is accessed and made available. The links between person and person and organisation and organisation have been radically changed.

I like to think that, at the time of its first regular, ongoing productive, business job, Leo was at the same stage as that reached in the Industrial Revolution by George Stephenson's Locomotive.

A decade before Locomotive started its regular haul from the West Durham coal field to the estuary at Stockton in 1824, Richard Trevithick had demonstrated that a steam locomotive could indeed work. His engine ran on a tramway from the steelworks at Merthyr to the national canal network. It pulled a load of 20 tons faster than a horse could manage.

Trevithick's problem, though, was that the load cracked the rails - a topical complaint with which we can all sympathise! So, though he had proved the principle, he couldn't claim to have produced a regular, on-going service. George Stephenson went that one decisive step further and translated the principle into a service that became part of the economy of north-east England.

Joe Lyons

That is what Leo accomplished in 1951. From its inception in November of that year, the Bakery Valuations job made a regular contribution to the management accounts of J Lyons \& Co for several years.

Joe Lyons, as the company was familiarly known 50 to 60 years ago, was founded in 1894 to cater for large gatherings. The company went on to build a chain of teashops, which became the favourite watering holes of shopworkers and clerks for their lunches, and provided a comfortable place for housewives to have a cup of tea after shopping.

Then, advanced baking machinery was installed at the Cadby Hall estate in West Kensington. To make the powerful equipment fully economic, it was necessary to produce a bigger output than that required by the catering activities alone. Within a few years every corner shop in the country was stocking Lyons packeted goods.

Expansion brought its own problem in its wake. It was one thing to expand production and to organise nationwide distribution. It was another to control all the movements of goods and to keep account of the thousands and thousands of small transactions.

So the ruling family decided to bring in some new blood. It was all a question of adding and multiplying, they argued. So they went to where the best adders and multipliers could be found, and recruited a senior wrangler from Cambridge University. His name was John Simmons.

John Simmons became a key figure in the Computer Revolution. When he arrived at Lyons in 1923, there was still a Dickensian atmosphere, with clerks standing at tall mahogany desks. If they wanted a rest, they perched on tall stools.

Simmons transformed this situation. From the outset he saw it as his job to provide management with information upon which they could take sound forward-looking decisions. He moved Lyons from a position where the offices were just bean counting, as they still are in many places to this day, to one where they guided all levels of management on positive action to improve the bottom line.

Lyons became a leader in the field of office mechanisation. One key step along the way was the establishment of a back room function that became known as Systems Research, and later Organisation and Methods. Its function was to look at all office activity from the viewpoint of its contribution to business needs.

When more advanced office machinery became available, the Systems Research responsibility was not merely to speed up what was being done already. Its job was to examine whether the business needs could now be met in new ways, yielding more help to management along the way.

I had the good fortune to be Manager of Systems Research when the idea of building a computer of our own came along.

Eniac

Before this time, during the last war, Leo's transatlantic ancestor, Eniac, had been built to meet the needs of the US army. This had its own mini-army of women mathematicians carrying out endless calculations to construct ballistic tables for all manner of projectiles in all manner of circumstances.

Eniac was not ready in time to make a contribution to the war effort, but it did prove that an electronic computer could deliver productive results.

It had a basic weakness. It was wired up to perform only one program. True, it could be rewired to run other programs, but there was no question of being able to switch quickly from one program to another.

To rectify this shortcoming, what became known as the von Neumann architecture was devised. It was too late for Eniac but it lit a beacon which stimulated computer development every where.

The coming together of Lyons and Eniac took place in 1947, when two senior executives of the Lyons offices visited the United States on a fact-finding mission. Europe had been cut off from the United States for almost 10 years, and Lyons was anxious not to be left behind in the field of business methods. The leader of the Lyons party was Raymond Thompson, another Cambridge mathematician.

In the event, the party never actually saw Eniac. They had an appointment to see it but it was cancelled. With its thousands of radio valves and high heat dissipation, it is little wonder that Eniac was down from time to time.

However, Thompson and his colleague, Oliver Standingford, did learn that two Cambridge, England academics had spent time at the site and were well equipped to advise Lyons if the company wanted to go further with the idea of obtaining a computer of its own. They were Professor Douglas Hartree and Dr Maurice Wilkes.

The report of the tour and of the subsequent visit to Cambridge was presented to Simmons. It contained a remarkably perceptive account of how a computer might be used for ordinary office work, and included a firm recommendation that the company should acquire one.

Several possibilities were seen. One was to buy a machine from America. Another was to encourage British office machine manufacturers to build one. Another was to persuade the UK government to take a hand. A fourth possibility was to ask Cambridge to build a business version of its own Edsac computer. Finally there was the proposition that Lyons should build a system of its own, drawing on assistance from Cambridge.

For one reason or another, all the options but the last were discarded as impractical.

Genesis of Leo

The Lyons Board decided to proceed with the building of a computer so long as and as soon as Edsac could be demonstrated performing a live job.

Lyons offered to donate \pounds 3000 and the services of a technician for a year to Cambridge University if Wilkes would make his work available as a model. The offer was accepted and no one could have been more generous in his help and advice than Maurice Wilkes over the ensuing period.

At that time, Lyons had no electronic personnel at all. So, anticipating that Edsac would pass its test, an immediate step was to recruit a chief engineer. The young man appointed was John Pinkerton, in whose memory an annual IEE lecture is now given (this article is based on the second of these lectures).

Pinkerton was a Cambridge physicist by training. In the war he had worked as a boffin in TRE, the Government research establishment, specialising in air defence. Maurice Wilkes, asked to vet this applicant, answered that he knew him well and that he was just the man for the job.

And so Pinkerton proved to be. When the aged Company Secretary asked him, "Do you think you can build this machine, young man?", he paused for a moment, then replied, "Yes, I think I can, but it might not be very reliable".

He had rapidly absorbed the fact that an essential characteristic of business work was that it had to be done to time. In most scientific calculations of the period, delay of a day or two was not a disaster. Business work did not allow that latitude.

In parallel with Pinkerton's appointment, my own department began preparing for the utilisation of a computer for the Lyons business. In due course this work was moved out of Systems Research to form a unit of its own. Programming techniques were developed. Applications were planned.

That was our format. Pinkerton was responsible for designing and building the equipment and I was responsible for putting it to productive work as soon as it was ready.

There were two main engineering tasks now. One was to build an engineered version of Edsac to serve as the base. The other was to attach ancillary electronics to cope with the special requirements of business work.

At the heart of the difference between scientific computing and office work is the volume of input and output. In scientific work there is generally an enormous amount of calculating, most of it repetitive. This is based on very little data and produces only a small output of results.

In business work, on the other hand, the calculations are simple but the amount of data and results is enormous. So, unless provision were made to feed the data into the machine quickly and get the results away quickly, the benefit of the high calculation speed would be squandered.

Our initial idea was to use magnetic tape, even though this was still in its infancy. A leading firm of electrical engineers was enlisted to bring a magnetic tape ancillary system into being. Unfortunately, their approach was too ambitious and the scheme never reached a fully working state.

On the other hand Pinkerton was well on the way to delivering his part of the system in good order and to time. He commented wryly afterward that "The philosophy we had was that we would not change anything if we didn't understand why it was done the way it was. So, to start with, since we didn't understand very well why it was done the way it was, we didn't make very many changes at all."

This is an overmodest resume of what Pinkerton and his tiny team achieved, but it conveys the spirit of the operation. Like Wilkes, Pinkerton was not trying to cross new thresholds in physics but to get a system into working order as soon as possible.

First business application

It was on Pinkerton's equipment alone that the first business application was carried out. It incorporated only minor additions to the Edsac facilities but a great deal had been done to raise the level of reliability.

The application we prepared for this basic system was simple, compared with the integrated applications that we were working toward. But it was still testing in that it would be an integral part of the company's management accounting system. It would have to be completed to time each week if it were to serve that purpose.

The application was based on two management techniques that Simmons had introduced over the years.

The first was the internal market. Lyons was made up of several different trading divisions or units. Each had its own cost centre or profit centre. When they transferred goods to each other a charge was raised just as if the goods had gone outside.

The second technique was standard costing. There was a standard price for everything. There was a standard price for materials received from outside suppliers and every product was costed. There was a standard factory prime cost at which goods were transferred from the factories to the distribution centres. There were standard selling prices for each item for each of the different channels of sale.

In the Bakery Valuations job the total quantity for each item for each type of transaction for the week was calculated at the appropriate standard prices. The resultant amounts were then passed to the Statistical Office where they were compared with the actual costs incurred and turnover achieved.

For example, the aggregated standard labour costs for a Bakery could be compared with the wages actually paid. If the actual cost exceeded the standard cost then it indicated that too many staff might be being employed to produce the output achieved or that the grading might be too high for the work required......or, of course, the sales price might be too low.

The whole objective was to enable management at all levels to take action without having to go searching for needles in the haystack of the Lyons Profit and Loss accounts. So many companies, even now, don't know where their profits are draining away.

On completion almost exactly 50 years ago, the program delivered the results week by week in good time.

I must stress that even though this job was carried out as early as November 1951, it was in no sense an experiment. We knew when the equipment was due to be ready for use and it was our remit to have a job ready to run on it. We had innumerable test programs to try out different aspects of the system, but we instinctively knew that only live programs and live data could really give the equipment and our programming techniques the examination that they needed.

We had no doubt that our programs and hardware together would pass that examination. It is hard to convey our sense of confidence at that time. We saw it as no great achievement to pass the test. We simply didn't entertain the possibility of failure.

That is how it turned out. On completion 50 years ago, the system delivered the results every week and in good time for years afterward.

Editor's note: this article is an edited version of the first part of the second Pinkerton Lecture, given by the author at the conference "Business Computing: the Second 50 Years" on 5 November 2001. Part two will be published in the next issue. David Caminer was Systems and Programming Manager of the Leo project from 1949.

First steps in computing at the Prudential

Ewart Willey

The Prudential's entry into data processing came as a result of Government legislation in 1911, when Lloyd George introduced the Approved Societies Act. This was a health insurance scheme for the working classes, and he asked the Industrial Branch insurance companies to take on the task of running it. The Prudential was the largest of these companies.

The Prudential actuary, Joseph Burn, recognised this as a unique chance to create a wholly new system based on the use of punched card equipment invented by Herman Hollerith, whose products were by then being marketed in Europe. Burn was convinced that punched cards were the way ahead.

The competing American company of James Powers then entered the European market in 1913, and it was their equipment which the Prudential ultimately chose to use. Nobody knows why. Historian Martin Campbell-Kelly, who has provided me with the foregoing information, suggests that the Prudential may have felt the Powers tabulation facilities were better than those of Hollerith.

The order was for 40 punches, seven tabulators and seven sorters, which were installed in 1915. This was believed to be the largest order for punched card equipment yet placed.

Burns recognised the risks involved in being completely dependent on an American manufacturer, so in 1919 the Prudential acquired the British manufacturing and selling rights for the Powers products, and in 1920 set up a factory in Croydon to make them. This operation eventually achieved a half share in the punched card market in British territories, before the Prudential sold its interest in Powers in 1945. The Prudential used Powers equipment itself for over 40 years into the electronic data processing (EDP) age.

At the beginning of this era in the 1950s, the largest mechanised systems in the Prudential were those for the Industrial life branch and the Ordinary life branch.

The Industrial life branch held nearly 30 million policies. The details of each were held on 65-column interstage cards (meaning that each card could hold 130 characters), which could be interpreted (meaning that selected data could be printed across the top of the card).

It was a control by exception system: the agent who collected the premiums each week or lunar month reported only non-payment of premiums plus any policy changes. Virtually all telephone queries to Chief Office could be dealt with in a couple of minutes by reference to this card file. At that time no computer system could approach this level of response.

The situation in the Ordinary Branch was somewhat different. There were 1,240,000 policies, which were much more complex than those in the Industrial Branch. So were the processing requirements.

Ordinary Branch policy records were held on three different media:

• 45-column Powers punched cards (for valuation purposes);

• Adrema plates holding all major information (for printing the policies, reference, printing renewal notices and so on);

• handwritten or typed registers (for older policies not yet transferred to the Adrema system).

In 1954 a Mechanisation Research Department was set up to investigate possible applications of EDP in the company. Two decisions were made:

1. to obtain experience by implementing a payroll system for Chief Office staff;

2. to address the needs of the Ordinary Branch first, because of the obsolescence of the 45-column card equipment and the inflexibility of the Adrema system.

To implement these decisions the Prudential decided to double the size of Mechanisation Research from two people to four. The two additions were Miss Marion Tribe and myself, in my case apparently because I had radar experience during the war. When I was offered this move I consulted my wife, telling her there was a risk involved as it was by no means certain that computers had a future!

Payroll system

When we joined the department a Powers PCC had already been ordered for the payroll system, and planning for the payroll had started. We took this over.

The PCC had the following features:

• punched card input and output;

• maximum program size of 160 instructions, implemented as rivets on four program boards;

• drum capacity of 160 words;

• no manual, no training courses;

• cost of £25,000.

One of the important decisions was the choice of rivetting machine - we did not get one free with the PCC.

About this time I joined the British Computer Society and started going to the Programming Study Group. Chats with the Chairman elicited the advice that a first EDP implementation should be one that was of maximum benefit to the user and of maximum simplicity to implement. This was not payroll!

However we had enthusiastic support and help from the head of the Salaries Department and were able to provide him with a system that did save his department some work.

Several points of interest strike me.

First, payroll runs to a very strict time schedule. The PCC was a valve machine dependent on punched card input, and it was very unreliable. Meeting the deadlines proved a nightmare, and we had to get a second machine for backup.

Second, we employed our own engineers, as was the practice with the existing punched card equipment. They included clerical staff who had been radio and radar engineers during the war.

Third, the programming depended on the extensive use of general purpose subroutines. Marion Tribe was a genius at this.

Finally, we often found that we could not remember why we had made decisions, so we started documenting them. Then a member of the Treasury whom we had met at BCS meetings visited us and, on being proudly shown our documentation, asked what would happen if it was destroyed by a fire. So we arranged a remote store!

As an example of life in those days I recall attending a conference at the IEE on computer problems. A speaker from one of the atomic energy establishments said they had had major problems in preventing program cards getting mixed up with data input and output cards. The meeting woke up and grabbed their notebooks! The solution was to have cards of a different colour for each function.

The PCC payroll ran until 1961, when it was transferred to an IBM 650. In all we acquired four PCCs, using them on various projects. They were all disposed of in October 1971.

Ordinary Branch system

To address the needs of the Ordinary Branch (OB), an implementation committee was set up in 1956, comprising: a Chairman from Mechanisation Research; an actuary; an underwriter; an Accounts Department representative; a Punched Card Department representative; and two Mechanisation Research staff (one as secretary). It thus covered every aspect of OB work. The seniority of the members was such that they were not divorced from the work of their departments: this was a very important decision.

By 1959 an integrated system had been drafted, and action commenced. This involved setting up implementation departments. Then there was the choice of a machine, a major exercise. Mechanisation Research had been addressing this concurrently with the committee's activities. We had to address such questions as the viability of magnetic tape, then a new fangled medium.

During this period I attended two Automatic Programming Conferences in Brighton. They convinced me that the use of a high level commercial language was vital to the success of the project, and this conviction was strengthened when I visited my now great friend Bert Neff at Metropolitan Life in New York. They had created an in-house high level language to implement a system similar to our OB project after finding the pioneering language available inadequate.

My colleagues agreed with my view, and a programming language became a major factor in the machine selection criteria. Incidentally, Cobol did not yet exist, and in any event its early implementations would have been inadequate for our needs.

The final contenders for the contract were Honeywell with the Fact language, and Ferranti with the Orion computer and the Nebula language.

We chose Ferranti. So we were to have a British machine, the son of Atlas, with an excellent operating system providing multiprogramming, and a number of other imaginative and valuable facilities. It was a great loss for the British computer industry that Orion did not have a son of its own.

We ordered the Orion in 1960; subsequently we also ordered a second one. We then set up two implementation departments: OB Systems Design, and OB Programming.

The systems department was staffed by personnel from the OB departments and included the relevant members of the implementation committee. It was under the charge of an actuary. So the system specification was wholly the responsibility of the users - another very important decision.

On the programming side our existing resources were inadequate, and a team had to be created. Some came from existing clerical staff and included graduates. The rest were new recruits, mainly school leavers with A level maths.

Both departments were divided into teams with specific areas of responsibility. The whole was under the control of a member of senior management. He held weekly progress meetings which were attended by systems planning, programming and operations (an operations department had by then been set up). Ferranti also attended when necessary.

My concern was the programming side. When we started with Ferranti, the Nebula language was in its very early stages. In conception it was very advanced, including for example variable length records and differentiation between logical and physical data structures.

In the light of the criticality of the language to the project we did two things which proved vital. First, when a program was written it was sent to Ferranti's compiler team for them to check that it was OK and that Nebula could handle it.

Second, we set up a Nebula Implementation Committee with members from the Ferranti team and ourselves, which met monthly. In this way we achieved what was virtually a bespoke language. (The minutes of this committee are now in the Science Museum library: unfortunately, there are no minutes for the final meeting.)

Other concerns arose from the fact that the Orion was a tape machine (discs were not yet with us). The system was based on a daily cycle, and we had a very long main file. So optimising the speed of programs was of vital importance, and much attention had to be given to program system design and to program size. Another factor was the length of compilation time, which was hours rather than minutes.

On the hardware side, Ferranti found problems with the first version of Orion. They modified the design, and our machine, an Orion 2, was not delivered until September 1964, four years after we placed the order. The second Orion was installed in April 1966.

In parallel with the systems design and programming, a massive conversion exercise took place to allow the details of the 1.25 million policies to be input to Orion. This involved collating data from the media mentioned earlier - the 45-column cards, Adrema prints and typed and handwritten documents - so that a punching document could be produced. The data was then to be punched on to 80-column cards for input to Orion.

The 45-column card file was the only one of the sources that encompassed all of the OB policies. It therefore had to be our starting point. There was an immediate problem: our 45-column tabulators were over 30 years old and incapable of printing the massive number of punching documents required.

Fortunately IBM, now the supplier of equipment for some of our other DP projects, undertook to modify a reproducer so that it would reproduce the data from a 45-column round hole card into an 80-column rectangular hole card. The 80-column card could then be printed onto a punching document of acceptable form by an IBM tabulator.

In order not to interfere with day to day working, the whole of the 45-column card file was duplicated between the end of one working week and the beginning of the next. Six 45-column reproducers were used. Work started at 5 pm on the Friday and continued non-stop through to 4 am on the Monday.

The Adrema plates had then to be printed on the specially designed punching documents. For operational reasons these plates were held in a different order from the cards, so the cards had to be sorted into Adrema order before tabulation. As the Adrema plates did not cover the whole of the portfolio, the punching documents were then passed to a specially created clerical department for completion of the remaining policies from the written and typed records. This department was staffed by pensioners and existing staff with OB expertise.

Another system was set up to provide input in respect of subsequent changes to these policies and for new business.

The punching documents for the 1.25 million policies and the policy changes had to be converted into punched cards. This required setting up a large card punching department. Staff had to be recruited and trained. After the first few arrived we learnt that the IBM card punches, which were coming from the USA, were going to be held up by a lengthy strike in the London docks. Another sign of the times!

As the cards were produced they were stored in large disused coal cellars in Chief Office which had been cleaned, whitewashed and fitted with racking.

Orion eventually arrived in September 1964. After machine acceptance tests and then exhaustive program testing with test data that covered every contingency the systems designers could think of, the policy and updating cards were input. A snag emerged: owing to the length of time between the start of the conversion and the delivery of Orion, the policy updating program did not allow for a sufficient number of alterations to a policy. Fortunately we could correct this immediately without causing any delay or impact.

After this we had a period of parallel running of the old and new systems before Orion took over.

Later, once it became technically feasible, we added a magnetic tape link to the Inter-Bank Computer Bureau to handle the payment of premiums by direct debit, and also a link to an IBM payroll system to deal with the commission payments to the Field Staff.

The Orion OB system ran until it was transferred to an IBM 370/158 in 1975, when the system was reprogrammed in Cobol. Both Orions were disposed of in December 1975.

Editor's note: This article is based on a talk given by the author to the Society at the Science Museum on 2 October 2001.

Two Early Pegasus Computers in Use

Godfrey N Lance

My first employment after I left King's College London in 1952 was in the design department of Hawker Aircraft Ltd. There we were designing the P1127 Hunter fighter aircraft under the direction of Sir Sydney Camm.

In the mathematics department to which I belonged, there was a team of six girls who used Marchant, Facit and Brunsviga calculators to perform flutter and other calculations needed to ensure that the planes flew safely. This work was tedious and very slow, partly because all calculations had to be done twice to ensure that they were 100\% accurate.

Sir Sydney was therefore persuaded that one of the new Pegasus 'high speed' computers from Ferranti would be an excellent investment. This was duly purchased and I quickly learned to program it at Portland Place under the excellent tutorage of Peter Hunt, George Felton and Derek Milledge.

In 1955 I left Hawkers. Later, I went to the Mathematics Department at the University of Southampton. I was influential in persuading them to choose and install a Pegasus in about 1957, and the Vice-Chancellor asked me to be the first Director of the Computing Laboratory. I was still a visiting consultant for Hawkers and so I continued to have occasional use of the Pegasus there.

Southampton selected a Pegasus rather than the English Electric Deuce, which was the main rival, because the former was much easier to program and therefore more suitable for a University environment, as the computer was intended for the use of undergraduates as well as for research work.

I was ably supported in the Lab by Drs John Willis and John P Cleave. One of our main responsibilities was to give programming courses and generally to help users with their programming problems.

The first course was considered rather special and I invited Peter Hunt to give the opening address, on condition that he never mentioned Pegasus by name because it was not a sales talk. In fact I bet him he could not get through the lecture without doing so: I lost the bet.

There were 12 people on this first course and they ranged from a sixth form school boy through someone from the Southern Gas Board to our Professor of Botany WT (Bill) Williams.

Everyone on the course was told they would do best if they had a project in mind and related what we said to their project. This concept worked well and everyone produced a program which worked. The student wanted to calculate a book of log tables - just for the hell of it! - the Gas lady wanted to perform wages calculations and Bill Williams wanted to do advanced statistics.

My wife decided she wanted to attend Peter's talk so as to learn what all the excitement was about (my life revolved around the new 'toy'). To this day she remembers Peter's opening sentences. "There are two sorts of computers, analogue and digital. We are studying the digital sort." Note that he did not say Pegasus is digital!! My wife forgets everything else!

The Southampton Pegasus was used for many interesting problems, including the following three.

Peter Morice, our Professor of Civil Engineering, was also a consultant for Ove Arup, the civil engineering firm which designed and supervised the building of the Sydney opera house. Peter did all the structural calculations for the complicated roof, which has since become world famous. However he failed adequately to consider the way in which the final configuration would be formed. Consequently there were considerable difficulties during the actual construction process.

A research student, Keith Howell, who was a nuclear physicist from Cardiff University, wanted to compute quantities called Wigner symbols, and this involved him in writing programs which would perform multi length integer arithmetic. The programs were very time consuming so he had to perform the production runs during the third shift at night, and he brought a camp bed with him. He was the only person I know who regularly used the "Hoot on Stop" (77) Pegasus order: the noise woke him at the end of a long run so he could reset the parameters for another run.

Bill Williams and I developed a lifelong association and between us we produced over 100 papers on the subject of numerical classification (or taxonomy) which was a generalisation of our early "Association Analysis" (see Nature (1958) v 182, p1755). The task was to simplify large quantities of botanical data by grouping or classifying it. Over the years we applied the technique in many disciplines other than botany as well, including earthquakes in New Zealand and neurosis among telephone operators.

A fascinating botanical study was of the Norfolk Broads. In this we recorded every plant species in each plot of land and then grouped the plots. A strange phenomenon appeared: it seemed that the Broads were influenced by ecclesiastical considerations because the classification highlighted the Norfolk parish boundaries. We claimed that Pegasus was heavenly inspired.

However Dr. Joyce Lambert brought us down to earth by pointing out that what had really happened was that each parish treated its land differently - some fertilised, some flooded, some drained and so on - and it was this that influenced which plants grew. This was a big disappointment - our explanation was much more entertaining!

Editor's note: Readers interested in further details of these applications are invited to contact Dr Lance at <lancegn at acr dot net dot au>.

CCS Web Site Information

The Society has its own World Wide Web (WWW) site: it is located at <www.bcs.org.uk/sg/ccs/>. This is in addition to the FTP site at <ftp.cs.man.ac.uk/pub/CCS-Archive> (please note that this latter URL is case-sensitive). The Web site includes information about the SSEM project as well as selected papers from Resurrection. Readers can download files, including issues of Resurrection and simulators for historic machines.

Letters to the Editor

Dear Editor,

When Bill Elliott was at the Borehamwood Laboratory of Elliott Brothers (London) Ltd he was trained by John Coales to write up new work, as I was. Hence on setting up the Ferranti London Laboratory in 1954 he enouraged staff to write Technical Reports. In 1994 Harold Gearing as CCS Archivist retrieved from Bill's office 20 of these reports.

Conway Berners-Lee possesses another (at present loaned to me). It is very interesting, being the original design by John Bennett for what became the Perseus data processing system.

But these do not comprise the complete series: there are gaps. No others have been found in the Ferranti Archive in Manchester, and none have been found from later years after the Laboratory moved to Bracknell.

Do readers of Resurrection have any hiding in their lofts or elsewhere? Ther are easy enough to identify. The early ones were in grey card covers plainly labelled, with a transparent window through which the subject-title shows. At first they were quarto size; later ones may have been foolscap or A4.

I would be grateful if anyone who finds one could telephone me on 01 452 813 072.

With many thanks,

Hugh McGregor Ross
Simmondley
Painswick,
Stroud
Glos GL6 6XA.
6 April 2002

Help Wanted

Tim Clyde has an old Victor Vicky non-IBM compatible computer from the 1980s. Its keyboard has worn out, and he therefore cannot access some potentially valuable 5.25" floppies. Any suggestions?

-101010101-

Ron Chisnall writes "I have two Marchant electric rotary calculators, neither of which now work! I bought these circa 1964 for the company I then worked for, and subsequently rescued them from the tip. I would like to restore at least one of them. The world used to be full of maintenance engineers who regularly fixed these and similar machines. They all carried service manuals. So far I have failed to find either engineers or manuals."

CCS Collection Policy

The Committee of the Society has formulated a policy statement concerning procedures for dealing with computers of historical interest that come to the Society's attention. This is published in full below.

1. The Society has no Collection of its own, and no premises in which to house one. There is no intention to change this.

2. When the Society hears of historic equipment which is becoming available for conservation, it will attempt to find a suitable home for it in one of the following major collections:

   • The Bletchley Park Museum Trust

   • The Science Museum, South Kensington

   • The Museum of Science and Industry, Manchester

3. The Society will also alert other collections to the availability of surplus equipment, where the major collections are unable to offer to house it, if it fits the appropriate area of interest. Members who know of such collections are asked to ensure that the Secretary is aware of their location and subject matter.

Forthcoming Events

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

Every weekend Guided tours and exhibition at Bletchley Park, price \pounds 3.00, or \pounds 2.00 for concessions
Exhibition of wartime code-breaking equipment and procedures, including the replica Colossus, plus 90 minute tours of the wartime buildings

10 September 2002 Talk on the Bombe Rebuild at Bletchley Park, with demonstration and tour

24 September 2002 NWG meeting titled "From Valves to VLSI"
Speaker John Vernon

22 October 2002 NWG meeting titled "Computer Mapping Techniques"
Speaker Dr J Barr

19 November 2002 NWG meeting titled "Early Use of Computers in the Cheshire Building Society"
Speaker John Williams

21 January 2003 NWG meeting titled "From Operating Systems to Windows"
Speaker Brian Warboys

North West Group meetings take place in the Conference room at the Manchester Museum of Science and Industry, Liverpool Road, Manchester, starting at 1730; tea is served from 1700.

Queries about London meetings should be addressed to George Davis on 020 8681 7784, and about Manchester meetings to William Gunn on 01663 764997 or at <william.gunn at ntlworld dot com>.

Committee of the Society

[The printed version carries contact details of committee members]

Chairman  Ernest Morris FBCS
Vice-Chairman  Tony Sale Hon FBCS
Secretary  Hamish Carmichael FBCS
Treasurer  Dan Hayton
Science Museum representative  Doron Swade CEng MBCS
Public Records Office representative  Jeffrey Darlington
Museum of Science & Industry in Manchester representative  Jenny Wetton

Chairman, Elliott 803 Working Party  John Sinclair
Chairman, Elliott 401 Working Party  Chris Burton CEng FIEE FBCS
Chairman, Pegasus Working Party  Len Hewitt MBCS
Chairman, DEC Working Party  Dr Adrian Johnstone CEng MIEE, MBCS
Chairman, S100 bus Working Party  Robin Shirley
Chairman, Turing Bombe Working Party  John Harper CEng MIEE MBCS
Chairman, Mil-DAP Working Party  Brian M Russell CEng MIEE
Chairman, Software Conservation Working Party  Dr Dave Holdsworth CEng Hon FBCS
Chairman, Preservation Policy Working Group  Professor Simon Lavington FBCS FIEE CEng
Chairman, North West Group  Tom Hinchliffe
Meetings Secretary  George Davis CEng Hon FBCS
Editor, Resurrection  Nicholas Enticknap

Dr Martin Campbell-Kelly
Professor Sandy Douglas CBE FBCS
Harold Gearing Hon FBCS
Dr Roger Johnson FBCS
Eric Jukes
Graham Morris FBCS
Brian Oakley CBE FBCS
John Southall FBCS

Point of Contact

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

Members who move house should notify Hamish Carmichael 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 so needs to be 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 a grant from the BCS, fees from corporate membership, donations, and by the free use of Science Museum facilities. Membership is free but 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.