Editorial

Nicholas Enticknap, Editor

The battle for Bletchley Park continues. Since the last issue of Resurrection the Bletchley Park Trust has suffered two reverses: applications for funding from the Millennium Commission and from lottery proceeds have both been turned down.

But all is by no means lost. The problems the Trust have been facing have been widely publicised in both the specialist and national media, and this appears to be having its effect in the corridors of power. Officers of the Trust were summoned to the House of Commons by the Heritage Secretary, Virginia Bottomley, in March, and she asked them to put in a second application for Millennium Commission funding.

In the meantime, there is already a good deal to see at Bletchley Park, with 14 different museums up and running. They include a computer museum, which is being run with the assistance of the CCS. Many readers will also be interested in the replica Colossus and in the latest replica project, the Turing Bombe.

Readers who would like to see the progress so far may be interested in the Open Day being run for members of the CCS and of the British Computer Society on 3 May: details can be found in the News Round-up section.

Meanwhile the Society's London-based conservation activities are gathering momentum again. The Pegasus, Elliott 401 and Elliott 803 are all now installed in Blythe House, Kensington, in specially prepared rooms. Security arrangements at this building, which is shared by three museums, are strict, but once access details have been sorted out the Working Parties should be able to resume the activities that were curtailed by the closure of the Old Canteen building at the Science Museum. There are plans also to prepare a room for the display of personal computers and related software.

Our feature material in this issue relates to three different early British computers. John Gosden has written a piece on his experiences developing software for Leo Computers. Maurice Richardson tells of some of the early commercial applications of the Zebra. Arthur Humphreys contributes an insight into the management discussions that led to the development of the ICT 1900 series.

News Round-Up

The Society has been much in the news recently. Most prominently so when Heritage Secretary Virginia Bottomley asked members of the Bletchley Park Trust, including our Vice-Chairman Tony Sale, to meet her at the House of Commons on 3 March and asked them to resubmit their application for funding from the Millennium Commission. This was featured on the BBC 6 o'clock news that evening.

-101010101-

The rejection of the first application to the Millennium Commission was reported on the front page of the 21 February issue of Computer Weekly. Inside, the paper carried an editorial arguing that "The Government needs to rethink its response". Perhaps the Government listened: certainly the publicity can have done no harm.

-101010101-

Three days earlier, the Times carried a feature on the Small-Scale Experimental Machine project being masterminded by Chris Burton at Manchester University...

-101010101-

...and then on 28 February, the Daily Mail published an article on the activities of the Bletchley Park Trust and its efforts to gain funding.

-101010101-

One fund-raising initiative that readers should be aware of is the Open Day being held on Saturday 3 May (time and pricing details are in Forthcoming Events). This is for members of the CCS and of the British Computer Society, and their families and friends. All admission charges will go to the Bletchley Park restoration funds. More details over the page...

-101010101-

The Open Day will feature a programme of lectures in the ballroom of the mansion. These will include an introduction to Bletchley Park by CCS Chairman Brian Oakley, a presentation on the Turing Bombe rebuild project by John Harper, and a lecture on the breaking of the Fish codes and the use of Heath Robinson and Colossus, by Tony Sale. There will also be a guided tour of the grounds and the Cryptography Trail. Members can also visit any of the museums on the site, including the Computer Museum and the Radar and Electronics Museum. A buffet lunch is available at £5.00 per head if you book in advance: contact Brian or Marion Oakley on 0181 393 4096.

-101010101-

The Meetings Sub-Committee is currently working on an autumn programme of London meetings relating to the history of UK software. There will be three meetings, all at the Science Museum: an afternoon lecture on 16 October titled "From freelance programmers to F1 Group PLC", by Steve Shirley; an afternoon seminar on 6 November on the "History of the UK Software Industry", featuring Alan Benjamin, Barney Gibbens, Sir John Hoskyns, Philip Hughes and Bryan Mills; and another afternoon seminar on 4 December on the "History of the National Computing Centre", which is being coordinated by John Aris. Queries on all of these should be made to George Davis on 0181 681 7784.

-101010101-

Planning of a London meetings programme for spring 1998 is also in its early stages, under the leadership of John Southall, to whom queries should be addressed on 0118 984 2259. This programme will concentrate on computer communications.

-101010101-

The North West Group is also well advanced in its planning for the autumn and spring. Details of the autumn meetings can be found in the Forthcoming Events section. Two further meetings are planned: one in January 1998 on a date to be decided, which will focus on process control, and another on 24 May 1998 when Doron Swade of the Science Museum will speak on "Computing in Russia". Both meetings will start at 1730 hours in the Conference room of the Manchester Museum of Science and Industry: refreshments will be available from 1700 hours. Queries should be made to William Gunn on 01663 764997.

-101010101-

We regret to report the death of Ernest "Len" Lenaerts, a key figure in the development of Leo I, at the age of 86. We publish a tribute to him, written with the aid of former colleagues David Caminer, John Pinkerton and Maurice Wilkes, on page 23. Readers can find out more about the part EH Lenaerts played in the Leo story in Peter Bird's book "Leo: The First Business Computer" and in Caminer et al's "User-Driven Innovation". There is also a reference in Maurice Wilkes' "Memoirs of a Computer Pioneer".

-101010101-

The Annual General Meeting of the Society will be held in the Director's Suite of the Science Museum on 29 May 1997, starting at 1715 hours.

-101010101-

What Might Have Been

Maurice Richardson

The "story of missed opportunity" is the author's description of the Zebra computer. He explains why he thinks it was one of the best designs of its time, and describes some of the problems encountered when it was first put to use for commercial data processing.

I am a great enthusiast for Zebra: it taught me a lot. It was such a simple machine, and it helped me with computers for ever more.

I joined STC in 1960 as a non-mathematician, but found myself immediately in a mathematical environment. I went on a programming course and two bearded gentlemen, Jimmy Ord-Smith and Tom Goodwin, lectured to me. I was told in my first couple of lectures that a computer word could hold a number in the range - l to +1, but as I wasn't a mathematician floating point didn't mean anything to me then. I also had a very interesting but to me totally obscure explanation of how a bright student had helped to reduce the number of instructions required for what we now call the boot operation from four to three to two. That was my introduction to the machine.

Fortunately I recovered from my shock and learned to love the Zebra. I became involved with one of the earliest attempts to get Zebra (by then the second generation, called Stantec) into the commercial field.

We got it into Hornsey Borough Council by a great stroke of luck. It was fertile soil because the Treasurer, E C Lay, was enthusiastic about electronics and computers; he was indeed a member of the BCS.

I've called this article "What might have been", because I think Zebra is a story of missed opportunity. Zebra was a great computer, and I think it could have done a lot more. It was relatively cheap at £ 25,000 to £ 30,000, so it was within the ability of a single council to buy it.The other machines of the time, such as Leo II, cost very much more, so councils had to band together to buy one, as some did.

What advantages and disadvantages did Zebra have as a commercial computer? The store of 8K 33-bit words was large for its day, and the 312 microsecond instruction time was quite good. Its programming was very close in concept to modern microprogramming, which made programming rather difficult in Normal Code (NC - Zebra's Assembler). Simple Code (an autocode with floating point facilities) was available for one-off jobs, but at Hornsey we had to use NC to make the programs efficient.

In a far-sighted move ahead of its time, Alex d'Agapayeff developed the first attempt at a high-level commercial language for Zebra called SEAL (Standard Electronic Accounting Language).

Zebra in its original form had the disadvantage of requiring six instructions to read each row of holes on 5-track paper tape. On the other hand, it was extremely reliable. This is borne out by the fact that Zebra appears to have been the last of the first generation computers ever to be in service.

Many "last days" of the early computers have been accompanied by well publicised switching-off ceremonies. One day I read in Computing and Computer Weekly a snippet reporting that Bruce Banks Sails near Southampton had only just switched off its Zebra. It had been designing sails for ships all those years. The enthusiast who ran it kept it going by buying a couple of more or less complete Zebras and using them for replacement parts. He avoided the dreadful problem with the drum by never switching it off. He kept it going until January 1981, later than any other first generation valve computer is known to have worked commercially.

The transistor model gave us some advantages. We had 7-track paper tape and a single instruction could input or output a character (using the same 6-bit ISO code as Ferranti). It had a more convenient operator's console, with cold cathode displays replacing the CRT. Some later machines had ferrite core.

In an innovative aid to efficient operation, E C Lay, the Treasurer, wrote a binary input program which allowed us to write our programs in Normal Code, enter them into the machine and then punch them out in binary. For operation the whole drum was cleared except for two tracks, one for the Short Input Program and the other for E C Lay's binary input program. His first attempt had 35 instructions, but he was badgered mercilessly by his assistant Derrick Eacott and me until he got it down to 32 words, which would fit on one track. It read object programs at 200 characters per second and stored them on the drum at this speed.

The configuration at Hornsey consisted of a Creed punch and verifier, two paper tape readers, the usual central processor, the console with Creed 75 teleprinter, two punches and a Creed 1000 serial matrix printer, which was a lovely gadget. It was driven hydraulically - there were pipes filled with oil, and it had a habit of spraying oil all over the place, but by and large it worked.

I'm told that the reason it worked is that STC did not like the idea of having Creed's valve circuitry in an otherwise solid-state environment, so they designed and built a transistorised driver for it. I was told years afterwards by a Creed man that it was actually the only Creed 1000 that worked properly, because of STC's electronics.

Subsequently ITT (parent of STC and Creed) decided that there was no future in this serial matrix technology, and told Creed to drop it. So the first serial matrix printer in the world was abandoned!

Hornsey also had a rather clever Creed paper tape store to give a measure of quick access to records. The tapes were spliced together and were quite big, but the program punched record numbers on the tape so they could get to a particular record quickly and print it out.

The first system we designed was payroll - everybody started with payroll in those days. We were helped by the large storage of the Zebra drum, so we could get a large program on there as well as the timesheet information. Our systems used as few characters as possible - we used neither item separators nor fixed fields as in punched cards. We punched an indicator letter followed by the data, so typically tapes were quite short for each employee.

That data went on to the drum and was sorted by the machine. The result was then run against a master file on paper tape and a new paper tape master file was output, with the timesheets printed on the printer - rather like a magnetic tape system in slow motion.

The inaugural live payroll run in 1963 will always live in my memory. It was an evening of high excitement. The computer and programs behaved well, but some mechanical tab stops broke on the printer, so we had to make a few handwritten corrections on some of the payslips.

Unfortunately the Hornsey machine was built at a time when the STC factory at Newport was disaffected because it was being closed down - STC was transferring the division to Southgate and Enfield. The machine was full of wiring errors. We didn't know that at the time - we just knew that we had problems with it.

Various engineers said, "What you need is a really good earth so dig a hole down to the water table, put a big copper plate in and that will solve it".

So council workmen were brought in, to take up the flagstones in the courtyard of the town hall. They dug down and down till they disappeared from view. Still they kept digging. The town hall staff would come out at lunchtime and call out, "Have you found water yet, Joe?" or "Have you reached Australia yet?". We never did find the water table, but they finally buried the plate. It didn't help!

Then a shining knight came charging in. His name was Vince Fisher, and he was an engineer from the message switching division at Southgate. He was not a diplomat, but he was a very good engineer. He dived into the machine and the more faults he found the worse his language became. But when he'd finished the machine worked extremely well.

We went on trying to sell machines to other people, mainly councils but also bus companies for analysing conductors' waybills and route takings. We gave a demo to the Hants & Dorset Bus Company whose traffic manager, named Morrison, I knew to be more forward-looking than his peers.

Then came Black Monday - 24 June 1963. Only a fortnight earlier I was in Lancashire talking to Preston and Blackburn Councils. We were trying to sell them a system, we had Hornsey rooting for us and there was every chance that we would be able to make a success of it.

But on that fateful 24th June the ITT people effectively sacked us and that was the end of the road. They did allow the Spar project to go on for a while - that was using the Zebra to produce paper tapes for a Lansing-Bagnall fork lift truck which went round the Spar warehouse getting the right goods off the shelves. That project continued for a while, but basically 24 June 1963 spelled the end of Zebra.

Editor's note: this is an edited version of the talk given by the author to the Society at the Science Museum on 11 October 1995.

The Prehistory of the 1900 Series

Arthur Humphreys

The decision to develop the 1900 series was the consequence of many earlier management decisions dating back to the end of the Second World War. The author disentangles the many intertwining threads of this decision-making fabric, revealing in the process that the decision to produce a compatible range of machines came before ICT management was aware of IBM's development of System/360.

The end of the war presented the British Tabulating Machine Company (BTM) with the opportunity to review the future of its arrangement with IBM. The Christmas of 1945 provided a chance to meet Thomas J Watson, and a delegation from BTM - Vic Stammers, Cecil Mead, Albert Cranfield and HarryWaters - sailed to New York on a very slow boat. They were entertained on Christmas Day at Mr Watson's home and he actually served his guests with a glass of sherry!

There had always been arguments between the companies on the issue of royalties, and this Christmas meeting did not resolve them, but it did set a programme whereby BTM would manufacture more of IBM's products and so ease the outpouring of dollars, as encouraged by the Labour Government. There was also set in hand an audit of the royalties paid during the war, IBM alleging that it had been underpaid.

These arguments and many visits to IBM by BTM technical staff continued over the next four years: during them there were many discussions regarding the implications of the Computer.

In October 1949 BTM Chairman Ralegh Philpotts, Vic Stammers and a lawyer set out for New York with a determination to settle if possible all of the problems then existing in the relations between the two companies. The result of this visit was that Mr (later Sir Ralegh) Philpotts, in a private meeting with Mr Watson at IBM Headquarters in New York, agreed to end the Licensing Agreement between IBM and BTM, which had originally been signed by Dr Hollerith in 1907.

An interesting fact about the Agreement was that it contained no termination clause and could only be ended by mutual consent. Sir Ralegh died shortly after October 1949, so his final business decision was one he did not live either to enjoy or to regret.

The new Chairman was Sir Cecil Weir who was delightful, able and inspirational, and later a key figure in the company's expanding future. He had been Chairman - I think - or at least a member of the Allied Control Commission in Germany following the end of the War.

At a briefing meeting soon after Sir Cecil's appointment as Chairman, the then Acting Chairman - one WG Dunstall (an importer of ostrich feathers) - explained to Sir Cecil that the Agreement with IBM had been ended, but in any event the benefits it had brought to BTM were of marginal advantage - access to all IBM's patents and know-how together with the opportunity to buy any IBM product at IBM's cost plus 10% - and certainly in his view were not worth the royalty payable, which was 25% of BTM's revenue. Someone, however, pointed out that there was a further advantage not mentioned. "Oh!", said Dunstall, "What was that?". It was that BTM did not have IBM as a competitor.

And so BTM was on its own. And as it happened about the sametime - October 1949 - Powers-Samas, BTM's only competitor inpunch\-ed cards, terminated its licensing agreements with Remington Rand and so was also on its own, but as a fully owned subsidiary of Vickers.

In 1954 BTM made specific arrangements with GEC jointly to develop the 1301 computer, which GEC would manufacture and BTM would sell. (In 1961 these arrangements were changed: GEC ducked out of the development of the 1301 but remained responsible for its manufacture.)

In June 1958 the merger of BTM and Powers-Samas was announced. The new Company, ICT, was launched in 1959 with Sir Cecil Weir as Chairman and Cecil Mead as Managing Director.

At the outset ICT operated essentially as a punched card tabulating machine company with electronic connections. BTM had been successful with its range of electronic multipliers and calculators, and Powers with its Electronic Multiplying Punch - the EMP - but its two main products, the Samastronic Tabulator and the Programme Controlled Computer (PCC) were not successful. This lack of success caused many problems for the new company.

Cecil Mead then formulated a strategy of consolidating all British computer companies or interests into ICT. In the autumn of 1959 ICT first sought to make a specific arrangement with Ferranti, but Ferranti chose not to accept the recommendations of the joint working party which both companies had set up, and so the eventual partnership was delayed until 1963.

In 1960-61 talks between English Electric and ICT took place, English Electric postulating that perhaps ICT's sales force could secure more orders for the KDF9 than they could. These talks were overtaken by a proposal from RCA, with whom English Electric had a very long-standing technical agreement, that a three-way arrangement should be made to tackle the European market for computers.

RCA had developed a strategy of heavy investment in the computer business, judging rightly that it was of more significance than colour television. RCA had introduced in the US the 501 and 301 models in a compatible range, to be followed at the top by the 601 and at the bottom by the 201. English Electric was marketing the 501 as the KDP 10.

The possibilities for such collaboration seemed to ICT to be worth taking seriously, but English Electric did not think so at that time and so ended the three-way discussions. However, ICT entered into a technical agreement with RCA, as did the Bull Company in France. ICT also purchased RCA 301 computers and marketed them as the ICT 1500. The technical agreement with RCA provided scope for collaboration in developments and in product plans for the future.

In 1961-63 there were many talks with the Bull Company to examine possibilities for collaboration in a sort of Computer Common Market. These talks collapsed when Bull, having decided on a strategy of growth irrespective of profitability, found this did not work, almost went bust, and was acquired by General Electric of America. ICT was also courted by GE.

In 1962 three significant events occurred:

1. ICT acquired the computer interests of EMI and the 1100 and 2400 products, as well as customers and a bright but small team of hardware, software and sales staff.

2. An agreement was concluded with Univac to purchase and sell the 1004 in ICT's markets (I will refer to this again a little later on).

3. ICT at last launched the 1301 and introduced it to the market.

Now ICT's Product Planning Group had the formidable task of formulating product plans and seeking to specify products taking account of the views and work in hand of EMI and RCA engineers, product planners and plans, as well as the views of its own technical and sales staff.

About mid-March 1963 I was told to visit the Ferranti Packard Company in Canada to look at the FP6000, to take appropriate colleagues with me, and to make the necessary arrangements with Peter Hall. Peter had been the key

figure in persuading Ferranti to merge its Computer Division into ICT by using imaginative and determined pressure, and as a result serious talks had been underway since January. Accordingly I set out with my colleagues "Echo" Organ, the head of ICT's Engineering and Manufacturing Group, and Tom Shepherd from Product Planning, together with Peter Hall and Hugh Devonald.

The presentation of the FP6000 by Ferranti Packard staff was expertly done, and Echo, Tom and I were very impressed with the specification. During the several days of our stay we became very impressed also by the possibilities of expansion into a compatible range. While Echo returned home, Tom and I went to see RCA in Cherry Hill and were brought up to date with their plans and problems. That was on Good Friday.

Tom and I then returned to the UK to meet Cecil Mead on Easter Monday. I recommended the adoption of the FP6000 and the dropping of our own developments. Cecil Mead said, "If that's what you think, let's do it". This turned out to be a £ 2 billion decision!

Work and collaboration continued from that time alongside the negotiations for the sale by Ferranti to ICT of its Computer Division. This deal was presented to ICT's shareholders at an EGM in September 1963. It seemed there were no questions until a 16 year old with a helmet in his hand and, I think, 10 shares, said to the Chairman, "You have clearly paid too much for the business, so when are you going to resign?".

The shareholders did approve the deal. So for the rest of 1963 and into 1964 ICT, now strengthened with Ferranti computer staff, proceeded with the development of the 1900 range and with putting it into manufacture.

In early April 1964 Basil de Ferranti, Peter Hall and I were in the States for talks with RCA, Univac and others. Peter and I were invited by RCA to attend a presentation put on by IBM specially for RCA as one of its important customers. Peter and I introduced ourselves to the IBM staff and listened to what was revealed - it was the 360.

We then adjourned with RCA's top management and product planning staff to review the situation. It was 7 April 1964 - the day the 360 was publicly launched. RCA decided that the announcement of the 360 did not adversely affect its plans, while we recognised we were committed to the 1900 and could not change anyway!

Thereafter the rest of the summer presented a formidable challenge to the company and particularly its sales force. In the face of IBM's promises of all the goodies of the 360, we were not in a position formally to launch the 1900.

The press unkindly but accurately pointed out that ICT was seeking to sell all of the following machines - 1301, 1500, 1100, 2400, 1004, Orion and Atlas - and described it as the largest ragbag of incompatible computers it was possible to imagine.

But then in September 1964, in conjunction with a Business Efficiency Exhibition, we launched the 1900 Series in style. We had 1902 and 1904 models at the exhibition for customers to see and touch. The launch announcement was special: it was made simultaneously throughout ICT's market, and involved members of the Board as well as senior executives in sales and engineering. The script of the presentation was written by Tony Jay, who had with Donald Baverstock, Alasdair Milne and others presented the Tonight programme on TV for many years. TV techniques were used in the presentations, which Tony Jay produced.

The launch was an immediate success. Orders were secured for the new line of products on a scale entirely new to the company. The severe problem of introducing into manufacture a brand new range of products for delivery a year hence, which might have been expected to create a substantial shortfall of revenue and profit, was avoided because of the success of the 1004: this was in itself profitable and required no investment in inventory.

So at last, having fought our way through the conflicts of product plans and products, the company had a single range of compatible computer systems to sell.

A historical perspective shows that the company had to do the same thing all over again between 1968 and 1974, having acquired English Electric Computers Ltd and become ICL. A new set of issues arose this time: bits and bytes, and whether or not to be compatible with IBM. There was also the promise of a golden rod by the Government, which wished us to face up to the white heat of technological revolution, and strongly urged the 1968 merger. But we never received the orders promised: the golden rod gave more pain than cash.

Editor's note: this article is based on the scene-setting talk by the author to the Society at the start of the ICT/ICL 1900 seminar on 30 May 1996.

Mathematics and Software at Leo Computers

John Gosden

The author joined Leo Computers in 1953, and worked there for seven years. During that time he was responsible for a wide range of software developments covering mathematical and commercial applications as well as the emerging systems software. This article describes the problems he tackled and the experiences he gained in what has proved to be the most enjoyable job of his life.

I started on mathematical applications reporting to Leo Fantl. This was a courageous decision by Lyons, as I came down from Cambridge with just a pass degree in mathematics. Nevertheless they hired me, on three months probation.

Before I arrived, many of the guiding principles and fundamental procedures (including those inherited from the Cambridge Edsac) were developed and in place on Leo I. They included many subroutines and standard procedures for using card readers in addition to the conventional paper tape. As for the processor, every channel was fully buffered and there were hardware assisted facilities for conversion between binary and both decimal and sterling numbers. This made life very much easier for commercial applications.

Leo Computers had already established clear program design principles and standard methods of documentation and annotation of flow-charts. I still use them today.

For programming and system design there were six major principles:

• all runs were divided into batches so that when things went wrong they could be restarted from intermediate places;

• all clerical/accounting/commercial programs included reconciliation and control totals so that errors could be signalled and corrected;

• there was careful desk checking - after you had flow-charted something, a colleague checked your flowchart;

• after you had coded a program somebody checked your coding;

• until your work was signed off, your program did not get punched, (we programmers didn't do the punching - that was considered a waste of our talent);

• then we had to produce the expected test results before the program actually ran the test.

Those procedures had all been developed before I arrived, and were strictly followed. It was that disciplined environment which made it very easy to move people from one task to another, and resulted in low error rates in program development and running jobs. Much specialized work had been done: for example Fantl had done very careful analysis on rounding errors for integers. This was necessary for PAYE tables and actuarial tables to ensure that the results were "absolutely accurate", ie. the same as a desk calculator using conventional rounding would produce. Also for most customers we had to adjust results so that percentages added up to 100. We tried and usually succeeded in converting our users. But it was many years before we began to see annotations such as "numbers do not add up to 100 because of rounding".

Before I arrived Lyons had already been running "scientific" applications: range tables, meteorology, crystallography, and actuarial tables. My first job was to produce matrix inversions for aircraft design calculations. We had a matrix inversion routine from Cambridge, but it operated entirely within memory, and so could only handle matrices up to size 8x8. It also used paper tape rather thanpunched cards.

We needed to work with matrices that were quite large. We ended up with my redesign being able to deal with matrices as large as 32 x 32, because it only needed to hold one row in memory. For example on a N x N matrix we proceeded by using each of the N rows as a pivot. Each pivot involved passing the whole N x N intermediate matrix from cards to cards.

Another problem was floating point, which was programmed and thus exasperatingly slow. I tried to find ways of making it faster, but it was hard to improve the Cambridge routines. Then Fantl found a reference to an obscure document in Computer Abstracts, written by Professors Samuelson and Bauer of Munich, which explained how to do "significant digit floating point". We got a copy, in German, and Fantl translated it.

It turned out that this procedure, as a side-effect, reduced the time needed for floating point on Leo I by about a factor of two. This process does not "normalize" or "rescale" the result of each operation. The other advantage was that as intermediate results were printed while the calculations proceeded, you could see the number of significant digits reducing and the errors creeping in from the right hand side.

With matrix inversions you perform the same operation on every element of each row. The Lyons background of thorough checks inspired me with the idea of putting a row total on every row of the matrix. Then as you calculate each pivot row, you perform the same elementary matrix operations on each part of the row and perform the same operations on the total. The result should still add up afterwards. So I had developed a bullet proof reconciliation for the arithmetic inside the machine, which meant that we could actually use intermediate restarts on this application as well.

I first tried a 3 x 3 matrix and the results were the same as my hand calculations. Handley Page then provided me with an 8 x 8 matrix to work on, and I got different results from those produced from the same matrix by the National Physical Laboratory (NPL). I spent a week at a desk calculator trying to figure out where I had gone wrong.

At the end of the week I suddenly remembered that if you multiply a matrix by its inverse you get a diagonal matrix. That is a very simple test, which took me less than half an hour to do. I was right and NPL was wrong. I called up Wilkinson, the senior person at NPL, and he told me that NPL selected their pivots manually, and shuffled the rows and columns manually by operator intervention. I did mine automatically... I was not in love with NPL for quite a long time.

Then Handley Page wanted Leo to do more general matrix calculations, and I got the job of putting that together too. So I used the significant digit routines that I had built, and added both row and column sums to the matrices. I added them negatively so that if you added up any column or any row it should come to zero.

To see how this works consider the addition of two matrices. If you add the one on top of the other the total of the result is equal to the sum of the totals of each matrix. If you do matrix multiplication and leave out one row and one column, you'll find that it will generate algebraically and independently the row and column sums. So you have a perfect way of reconciling the calculations as you go along.

I have never seen this done anywhere else. It was a fairly low overhead and it certainly did pull up any arbitrary or miscellaneous errors that the machine might make. At the end of a calculation we would print out all the values and also the running reconciliation totals, which should be zero. Our first run took about eight hours of computer time, and the eight decimal significant digits in the mantissa at the beginning slowly went down to about five. When we looked at the zeros for the row and column discrepancies, they had built up to one or two digits.

While debugging, I made a big mistake which cost us four hours of computer time. David Caminer threatened to fire me and I've remembered it ever since.

On the Monday when the customer came in to see his results David sat behind his desk with the answer we had produced. David took the initiative right away and said "Well, what's your test answer?". David insisted on the client coming up with his version of it first, and then had the cheek to congratulate him on getting it right!

Although the customer had assured me that the first pattern of calculations was what they wanted each time, the next time he came back he had a different pattern. As a result I invented a matrix manipulation language. I don't know where I got that idea from - I can't find any predecessors - but it was fairly simple to do. So we had a matrix manipulation language we could use for all algebraic matrix and vector operations. It was in use for many years afterwards for tasks such as crystallography, flutter characteristics, and eigen vectors. It generated a great deal of money for the company over time.

I did all this work in the first 14 months at Leo. I don't know how. Then I moved into commercial applications, though I was still responsible for dealing with the subroutines that came from Cambridge and whatever maintenance was necessary on the software of Leo I.

During this period my notes tell me that I was involved in over 20 office applications. With most of them I was writing proposals and specifications, and with a few I was responsible for the implementation. In this period I had an intensive, and sometimes frustrating, education in writing. It seemed to me that we, or at least I, rewrote and revised (repeatedly) every document. Even in the final copy it seemed to me that David could open it up and run a finger down any page and find a fault that I'd made.

During that year I also had a very rapid course in business procedures. I seemed to be assigned something different each time, including the famous Teashops job. That was very interesting because it was the first time, other than working for my supervisor Fantl, that I was a (junior) member of a team of programmers.

At the end we calculated a set of statistics. The idea was to list the results of all the teashops on one page and print out the best and the worst performer in each group, and then summarise them by group and print out the best and worst group. David Caminer recently told me that this was an attempt to get managers to manage by exception. It failed, just as it does today.

I was working on calculations that ranged in scale from hundredths of a penny per bun to pounds. Because of the short word length of Leo I, we had to round everything off. One of the things I did was an analysis to show how large the rounding error was likely to be. All halves rounded up, which I calculated to be worth about £5 a day. It worried me but was trivial to the cost accountants - another eye opener.

Another interesting job I was responsible for was the railways distancing application. British Railways was obliged to publish 7000 x 7000 distances, which staff were calculating by hand in a back office in Euston, and they were falling further and further behind. Although I was responsible for the application I think everybody came up with helpful suggestions to speed the process.

The program probably ran several million times over. I think I once calculated that each instruction of the inside loop (kernel) was worth about a week's computer time. The job filled up all the extra time of computer time over 18 months, which was available because Leo had recently adopted 24 hour operation. So it produced a nice healthy income.

We computed the distances going one way and coming back, and because the "distance to" equalled the "distance from", we had a reconciliation. David, or Leo Fantl, insisted that a key aspect of the design must be to break the work into reconcilable blocks. As I recall, there were over 5000 blocks, and to run a block would take the operator about 20 minutes.

Everything we ran included clerical and counting checks. I still put checks in programs today that my colleagues don't think are worth while. They often turn out to be useful in debugging and in identifying operating errors.

Meanwhile I had responsibility for the supporting software for Leo I, and took over the same role for the emerging Leo II in mid-1955. I had very little need to do much for Leo II. Most of the basic design work had been done.

The main work was design for new peripherals. The new alphanumeric printer was straightforward, and for the drum facilities I stole heavily from everything Manchester was doing. I regarded them as the leaders on drums at that time. My main recollection of magnetic tape is dealing with the write errors. The good design from Leo I and Leo II that I inherited, particularly in the fully buffered input and output channels, made everything very simple and straightforward.

When we come to Leo III design, I was the main customer that John Pinkerton had to interface with. I represented the programmers and software people. I recall a lecture given by Stanley Gill after he had returned from a spell in America. It was at Cambridge and he talked about multiprogramming. He outlined the basic idea, which we used as our model. I started work on trying to lay out a master routine and deciding what interrupts and other controls we would need.

My major objectives for Leo III were:

• first to find a good way to handle decimal and sterling values while not losing too much speed;

• second to find ways to reduce the time and resources needed to sort large volumes of data on tape, because that had been a major limitation on earlier computers;

• third to use microcoding to overcome complex and cpu-intensive functions;

• and fourth to find a way of doing multiprogramming that did not generate too much overhead, and also protected separate programs from each other.

We used microcoding to exploit what we wanted to do, and it was a big help. The engineers built a breadboard machine to test out their circuits, and allowed us to use it part time to test our microcode.

At this time I was unhappy about the difficulties of using binary machines for clerical work, especially the need to convert both input and output, and the need to match Cobol facilities to handle digits and characters individually. However I was even more unhappy with the way decimal machines could not handle sterling.

As a result I conceived and designed the "mixed radix register" scheme to allow mixed radix arithmetic. This register in the arithmetic unit could specify a separate radix for each digit position. For example, in sterling, the pence were represented by one digit with a radix of 12 and shillings by two digits with radices 10 and 2. As I recall, it used one extra register, and for a typical "add" instruction just a few extra steps in the microcode. Thus it had little speed penalty. It was really a very simple scheme to implement. Fantl recently recalled it as "fiendishly cunning".

A big handicap in making applications viable in terms of elapsed time and cost was the overhead of sorting large volumes of data. Several special "merge" instructions were created to reduce the cpu load for sorting. This was supplemented by the use of automatic buffering for input and output that was continued from the Leo I and II designs. This is a good example of having to integrate data design, input/output hardware and system software.

This also influenced the design of the Master Control, because at that time the main use of multiprogramming was seen to be one main application (typically cpu- limited) running in parallel with tape sorting and printing which exploited the use of input/output buffers. Thus we wanted the sort routines to use very little cpu time. The microcoded merge instructions proved very successful and powerful in this respect.

I don't remember much about the details of the implementation: I think I designed the microcode language and register structure, but only outlined the design of the Master Control and Cleo, which were then taken over by Ernest Roberts supported by a staff that later included people who joined the company at the end of 1960. At that stage I emigrated to the USA where I also worked on a big operating system so my memory is not clear on the details.

The three key years of design and initial testing of Leo III began in 1958. In that year I sketched the functions and design of the Master Control, laid out the micro instructions and outlined the bulk of the instruction code (except for the complex functions such as tape merge). This included the design for mixed radix working.

In 1959 Roberts and a few others were assigned to the Leo III project. The staff (which grew to about 16) refined the designs. The first draft of the Cleo specifications was produced, and we began the microcode testing on the breadboard computer.

In 1960 I, or Roberts and his staff, produced the first draft design for the Master Control and Utilities. Caminer reports that in the next five years some 140 staff years were devoted to this system software. This was far more than we anticipated.

Looking back over my time at Leo Computers I can say that I never had such a good time, worked with such interesting people or had such a fun job. I loved the style and discipline of work enormously, and it improved my writing immeasurably, particularly when I went to work for a life insurance company.

I am amazed, thinking back, to realise how very few software errors occurred. We used to run tests, with a lot of preparation, and get one, two or maybe three bugs: many programs went through, not the first time, but fairly cleanly compared to what I see nowadays. I regretted afterwards that we were not in an environment that encouraged us to make time to publish. When I moved to the States my boss was very publicity-oriented, and I ended up producing four or five papers or publications every year. Nevertheless I am forever grateful to Leo: I had a wonderful time.

Editor's note: this article is an edited version of the talk given by the author to the Society as part of the Leo seminar on 18 May 1995.

Obituary: Ernest Lenaerts

One of the principal figures in the development of the Leo computer, Ernest Lenaerts, has died at the age of 86. Those who worked with him feel, as John Pinkerton puts it, that "the part played by Lenaerts in the early days of computer pioneering is not as well known as it deserves to be". Another former colleague, David Caminer, points out that he had the distinction of being the first person devoted full time to computers by any office organisation, private or public, in this country.

EH Lenaerts, generally known to his colleagues as Len, joined the Lyons management accounting office before the War. His inclination was, however, towards technical activities and on joining the RAF he took every opportunity to develop his technical knowledge and skills. Maurice Wilkes recalls Lenaerts telling him that after the War he was interested in a proposal for acoin- operated machine that would deliver diathermically heated sausages, sizzling hot, to the customer.

His technical inclinations were recognised when he was assigned by Lyons in late 1947 to help the Cambridge University team working on Edsac. He spent a year there during which, in the words of Maurice Wilkes, "He made a real contribution to the project and was well-prepared to assume a responsible role when his period of attachment was over... I remember him as quiet, thoughtful, and obviously able."

When Lenaerts returned to Lyons to work on the Leo I project he worked with John Pinkerton, who had been recruited to take charge of the engineering side of the project.

Dr Pinkerton summarises Lenaerts' contribution as follows: "The design of Leo I drew heavily on his detailed understanding of the logic of Edsac. In the testing phase he developed a flair for fault finding and repair. Many original features were designed by him for Leo I to make both these processes easier and quicker, notably the store monitor showing the actual pulse patterns in all parts of the delay tube store.

"But his skill was not limited to fault-finding or repair; he also proposed ways to modify the Leo control circuits for multiplication and division so as to perform the necessary conversions from and to the decimal and sterling notations using single instructions."

Lenaerts continued working with John Pinkerton at successively Lyons, Leo Computers and English Electric until he took early retirement after the merger with ICT in 1968.

Obituary: Gordon Scarrott

Gordon Scarrott, who died last October at the age of 80, was a distinguished computer engineer who was best known for his part in the development of two pioneering ICL projects, the Distributed Array Processor (DAP) and the Content Addressable File Store (CAFS).

The DAP was undoubtedly a technical success - it can be considered the forerunner of today's massively parallel systems - but it never made much money for ICL, and was eventually sold to a small start-up company. CAFS, on the other hand, achieved sales as a stand-alone product from its formal launch in 1979 before it became an integral part of ICL's mainframe systems in 1983. The system, which was unique, won many awards including the the Queen's Award for Industry for Technology in 1985.

But DAP and CAFS were just two of many innovative computing projects that occupied his inventive mind from his arrival in the computer industry at Ferranti in 1953 till his retirement in 1981. In addition, Scarrott was an incisive theoretical thinker, and developed his own theory of information engineering which he promoted forcefully via many presentations and published papers during his retirement years.

Members of the Society were privileged to hear these views - "my favourite heresies", as he put it - at a talk he gave to the Society in London in March 1995. The talk was repeated in Manchester last year, though as Scarrott himself was ill at the time his paper was read by Charlie Portman. Readers who were unable to be present on either occasion can find an edited version, split into two parts with the assistance of Gordon himself, in Resurrection issues 12 and 13.

CCS Secretary Hamish Carmichael, a former colleague of Gordon, pays the following tribute. "People who had the privilege of working with or for Gordon will always remember the staunch nature of his support, and the unswerving way he protected projects which he deemed important against opposition from people with more conventional minds. `Loyalty downwards', he would say, `must always be given, but loyalty upwards has to be earned'. The team he forged in ICL's Research and Advanced Development Centre knew him as a stimulating manager, always full of encouragement, modest about his own ideas but ever receptive to the suggestions of others, and gave him in full measure the loyalty he earned as a leader and the love he inspired as a friend."

Society Activity

Elliott 803 Working Party

John Sinclair, Chairman

The Elliott 803 that was formerly in the Science Museum has finally been installed in its new home at Blythe House, next to the Elliott 401. After the appropriate security clearance has been obtained, our next task is to have holes cut in the false floor to allow the installation of underfloor cables.

Work has been continuing on the Society's other Elliott 803, which was presented to us by Andrew St Johnston in May 1994 and is housed in the Bletchley Park museums complex. We have been working on it virtually every fortnight since then, and were able to celebrate the reaching of a major milestone in early March of this year when the machine ran its store test programs correctly - for the first time in well over 15 years!

The reason why it took us so long to reach this point was that both of the core store boxes proved to be faulty, and had to be replaced, a very time-consuming task in itself. Then we had to eliminate all the other hardware faults.

The machine is now working well, and is proving a major attraction to visitors to Bletchley Park. On one occasion we switched it on, and it immediately started playing a music program which had been loaded into the core store a fortnight before - a reminder of how things used to be before the advent of modern volatile solid-state memories!

Small-Scale Experimental Machine

Chris Burton

The Working Party almost achieved its target of getting the machine physically completed by Christmas 1996. A very few chassis remain to be made. The team meets regularly each Tuesday to work on the system, as well as on ad hoc extra days. The various subsections of the equipment have been made to work as far as possible in isolation, and we have begun to integrate the whole together. A number of unexpected aspects of the design are emerging as we make progress, indicating the historical value of the project. The aim is to have the whole machine working by the end of 1997.

As expected, the Cathode Ray Tube stores remain the most difficult and unpredictable areas to commission, and we are pleased to have had Professors Dai Edwards and Tom Kilburn advising us on details. The Feasibility Rig which was made to evaluate the technology at the beginning of the project has now been interfaced to a PC so that we can quickly write and read the CRT store for testing. This sort of technique will probably be used as a long-term maintenance tool on the full machine.

During March there was considerable media interest, with interviews about the project on television, on radio and in the press. We also featured prominently on two University Open Days during Science Week.

FTP, Web and E-mail Addresses

The Society now has its own World Wide Web (WWW) site: it is located at http://www.cs.man.ac.uk/CCS/. This is in addition to the FTP site at ftp.cs.man.ac.uk/pub/CCS-Archive. The pages of information at our Web site include information about the SSEM rebuild project as well as selected papers from Resurrection. Full access to the FTP archive is also available for downloading files, including the current and all past issues of Resurrection and simulators for historic machines.

Many readers will also be interested in WWW sites run by other bodies concerned with the history of information technology. The Universal Resource Locators for a few of these organisations are as follows:

Bletchley Park (contains information on Colossus)
http://www.cranfield.ac.uk/CCC/BPark/

Manchester University (for its early computers)
http://www.cs.man.ac.uk/mark1/

Science Museum
http://www.nmsi.ac.uk/

National Archive for the History of Computing
http://www.man.ac.uk/Science_Engineering/CHSTM/nahc.htm

The Virtual Museum of Computing (a rich source of links to other computer history resources)
http://www.comlab.ox.ac.uk/archive/other/museums/computing.html

Readers of Resurrection who wish to contact committee members via electronic mail may do so using the following addresses.

[Addresses will be found on the printed version]

Forthcoming Events

20-21 April 1997, and fortnightly thereafter Guided tours and exhibition at Bletchley Park, price £3.00, or £2.00 for concessions
Exhibition of wartime code-breaking equipment and procedures, including the replica Colossus, plus 90 minute tours of the wartime buildings

3 May 1997 Bletchley Park Open Day, 1030-1530 hrs
for CCS and BCS members, families and friends
lectures and guided tours: admission charge £3.00 for adults, £2.50 for children

29 May 1997 London meeting, 1715 hrs
"Acorn Computers and the BBC micro" by Hermann Hauser

30 September 1997 North West Group meeting, 1700 hrs
"Unicom - Unilever's Pioneering Word Processing System" by Peter Hall

4 November 1997 North West Group meeting
"The Development of Computer Graphics" by R Hubble

The London meeting will take place at the Director's Suite at the Science Museum. The North West Group September meeting will take place in the Conference room at the Manchester Museum of Science and Industry, and the November meeting in the Manchester University Computer Department Lecture Theatre.

Queries about London meetings should be addressed to George Davis on 0181 681 7784, and about Manchester meetings to William Gunn on 01663 764997.

Committee of the Society

[The printed version carries contact details of committee members]

Chairman   Brian Oakley CBE FBCS
Vice-Chairman   Tony Sale FBCS
Secretary   Hamish Carmichael FBCS
Treasurer   Dan Hayton
Science Museum representative   Doron Swade CEng MBCS
Chairman, Elliott 803 Working Party   John Sinclair
Chairman, Elliott 401 and Pegasus Working Parties   Chris Burton CEng FIEE FBCS
Chairman, S100 bus Working Party   Robin Shirley
Chairman, North West Group:   Professor Frank Sumner FBCS
Meetings Secretary   George Davis CEng FBCS
Editor, Resurrection   Nicholas Enticknap
Archivist   Harold Gearing FBCS

Dr Martin Campbell-Kelly
Professor Sandy Douglas CBE FBCS
Dr Roger Johnson FBCS
Dr Adrian Johnstone CEng MIEE MBCS
Graham Morris FBCS
John Southall FBCS
Ewart Willey FBCS

Aims and objectives

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

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
• Develop awareness of the importance of historic computers
• Encourage research on historic computers

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.

The corporate members who are supporting the Society are Bull HN Information Systems, Digital Equipment, ICL, Unisys and Vaughan Systems.