Resurrection Home | Previous issue | Next issue | View Original Cover |
Computer
RESURRECTION
The Bulletin of the Computer Conservation Society
ISSN 0958 - 7403
Number 29 |
Winter 2002 |
Top | Previous | Next |
Kevin Murrell has been appointed Chairman of the DEC Working Party, in succession to Adrian Johnstone. Kevin's first report in this capacity appears on page 7 of this issue. He first came into contact with DEC via a PDP-8 at university, where he says "I discovered that I could program it without breaking into a sweat!". Until recently he worked in the Health Service, where DEC systems running Mumps were commonplace. In between, he worked for Business Computers Ltd as a machine code programmer and an operating system designer. He has put this experience to good use in an article on the BCL Molecular 18 minicomputer, which starts on page 15.
-101010101-
Chris Burton is having difficulty finding time between his many other Society activities for converting the electronic form of Resurrection into Microsoft Word format for storage on the Society's archive ftp site. Would anyone like to take on this task? It involves taking a file in \LaTeX\ format and converting to the more commonly used Word format so as to present the material in as near as possible the same appearance as the printed version of Resurrection. Chris does this manually because a robust and comprehensive automatic process does not appear to be available. Hints and tips will be provided. Contact Chris Burton at <cpb at envex dot demon dot co dot uk>.
-101010101-
Chris reports he has "acquired" an Atlas Ampex TM2 magnetic tape deck, which was at one time part of the Atlas Computer Laboratory system at Harwell, and has since been preserved at Liverpool University. The word "acquired" does no justice to the labour involved: the product is over 6' 6" high and weighs around 350 lbs! Chris plans to interface this leviathan to a PC, then read a tape which he believes may contain the Atlas supervisor source code. If any reader knows of any technical documents describing this tape drive, please contact Chris Burton at <cpb at envex dot demon dot co dot uk>.
Meantime, Chris and his team continue demonstrating the SSEM replica at Manchester every Tuesday (see Forthcoming Events for details). Work is currently proceeding on building a special equipment rack to test cathode ray tubes.
-101010101-
Guided tours round the Bletchley Park site, with its exhibition of wartime code-breaking equipment, also continue, and are now run on weekday afternoons as well as every weekend. Admission prices for these tours are £6.00, or £5.00 for children, pensioners and others entitled to the concessionary rate.
-101010101-
The Society's special event at Bletchley Park on 10 September was voted a great success by all who attended, and that was over 100 people. John Harper and his team described their Bombe Rebuild project, and followed that by demonstrations of the electromechanical monster.
-101010101-
It is with great sadness that we report that two members of the Bombe Rebuild team, Frank Cooper and Norman Hedges, died suddenly immediately after this event. Both were aged 81.
-101010101-
Frank Cooper died on 12 September of a heart attack. Frank was a keen supporter of the CCS, and right up to the end he was machining items for the Turing Bombe rebuild project on his own Myford ML7 lathe. His son John reports that he made more than 1300 parts for the Bombe with his lathe. Frank's professional life was spent with Ferranti, ICT and Cossor. He was deeply involved in early magnetic drum development at Ferranti, one of the first successful uses in the computer industry.
-101010101-
Norman Hedges died suddenly on 14 September, just two days after Frank, and four days after he attended the Society's Bombe Rebuild seminar at Bletchley Park. He had been directly involved with the most complex British Bombe built: it was so large that it could not be realistically moved and therefore was the only machine to carry out real cypher breaking outside a government establishment. Norman was subsequently deeply involved in the Bombe rebuild as an advisor. In between, he enjoyed a long career in ICT and ICL.
-101010101-
We regret also to report the death of Ed Hersom on 17 August at the age of 81. Ed was the last survivor of the design team for Elliott's Nicholas computer, and he contributed an article describing this project to issue 27 of Resurrection earlier this year. After spending 20 years with Elliotts he moved in 1967 to the Numerical Optimisation Centre at Hatfield Polytechnic, where he stayed till his retirement in 1981.
-101010101-
Another who is no longer with us is Allan Bromley, the authority on Babbage's calculating engine designs, who also died in August. His work will be well known to readers of Doron Swade's book "The Cogwheel Brain". Doron regards him as "the pioneering interpretor of Babbage's calculating engine designs", and it was following a suggestion of Allan's that Doron led the team that built Difference Engine number 2. Allan Bromley, who was based in Australia at the University of Sydney's Department of Computer Science, was a Fellow of the Science Museum.
-101010101-
Many thanks to those readers who responded to our request for help on page 22 of the last issue.
-101010101-
Top | Previous | Next |
Bombe Rebuild Project
John Harper
We were away in North America at the time when Resurrection 28 'went to bed' so no report was produced during the summer. Thus there is a great deal to report this time.
As planned we now have all mechanical parts that should move doing so under DC power. We consider this a 'half way' milestone and a major achievement in its own right. However, we do not expect to take another six years completing our Rebuild. If things go as well as they have done in the past we expect to take less than half of this time.
Most of this mechanical assembly took place as planned over a period of less than 10 days in April. It was most gratifying to see very large numbers of subassemblies arrive at Bletchley Park and quickly be fitted. Virtually everything fitted in place as intended and we were very soon able to apply power and get everything moving. What made this rapid assembly possible was the quality of work and attention paid by team members to their work. I would like publicly to thank all those who made this possible.
Our Web site at <www.jharper.demon.co.uk/bombe1.htm>, recently updated, provides more details of what has been achieved.
In our last report I mentioned that the Rebuild Team would be present in the Bombe Hut at Bletchley Park on the weekend of 20-21 April. This went off very well and we were able to demonstrate more of the Bombe working than we had expected.
Since then we have given a number of talks and demonstrations, the most recent being on Tuesday 10 September when the CCS visited Bletchley Park. From all accounts, it would appear that visitors enjoyed the day.
Work has continued since April but as before not very visibly. Our first complete cableform has now been permanently fitted. The rest are all cut to length and laced up to shape. These will now be fitted as they are terminated and this will now continue until we have the whole 60 or so completed and fitted. We now have our first drum virtually complete. This was in great demand by the WRNS who had operated the Bombes during WWII at their annual Enigma Reunion, which took place on 22 September. The drums were the items that they had most to do with when operating the Bombes and they all seemed very pleased to be able to handle one again after nearly 60 years. We will soon be making our next batch of 25 drums. Many of the parts required for this have already been completed.
If things were normal I should have been ending this report on a joyful note but sadly, I have to report that we have lost three of our advisors and supporters since our last report. John Smith, who had worked on the Bombes and visited BP and the Outstation many times during WWII, died just before we completed our major assembly operation. He had been advising us only days before this and was looking forward to seeing everything turning. John had advised us right from the beginning of the Project. He was one of those who convinced us that a Rebuild was feasible.
More recently, both Frank Cooper and Norman Hedges have died suddenly. More is said about these two fine gentlemen in the News Round-Up section in this issue.
DEC Working Party
Kevin Murrell
The 11/34 from AWE Blacknest continues to run smoothly, despite being moved a couple of times, and is in use at Bletchley Park each Saturday. We have recently been in touch with Blacknest and we should soon receive the Vax system that replaced the 11!
We have an 11/73 running Unix, and connected to the museum intranet. Despite a serious attack from a visiting group of Linux experts, it remained secure and impervious to their probing!
Next to the 11/73 is an 11/53 running Micro RSX: it continues to run each weekend without fault.
We have a Pro 350 up and running Venix. I would rather it ran RT11, or P/OS if all else fails. Has anyone got the discs?
Big news on the 11 front is the decision to get the 11/70 out of storage and up and running. This is a very sophisticated machine badged by Digital as a DecSystem 570 - meaning smarter cabinets and blue/white front panel. The machine was originally used by Shell and ran RSX. It runs an application called Scratchbook - a document management package with an early form of hyperlinking between pages.
The DecMate II and III+ are working well and running OS/8 and WPS respectively. We are adding a RX02 pair to the 8E and expect to have OS/8 running on this 8 shortly.
The rack Classic 8 is still awaiting attention. The processor is working, but the DecTape drives still need work. We are moving my desktop Classic 8 to the museum over Christmas.
Last but not least our MicroVax II and later Vax machines carry on without fuss, and not causing a problem to anyone, and the Alpha machine just behaves as if it is on a higher plane to the machines around it!
Software Conservation Working Party
Dave Holdsworth
We are working to make a CD of ICL George 3 available. I have successfully run a prototype version on a friend's PC with a set up very different from my own: that run included a general restore in which the mag tapes were modelled on the CD. This package is likely to be useful initially only to people who already know the operating system, but we plan to add some electronic documentation for new recruits. We may put the code on our Web site, but there is about 400MB of material. I still need to expunge from it material private to British Steel.
I attended the Leo reunion on 20 September, an experience I found both interesting and disappointing. It begins to look as if we have the engineer's set of Leo III software, not the end user version. The Leo Society has preserved a mountain of paper documentation, which lives at Manchester University, but there are still certain key items of information missing, whereas many other things are said over and over again.
I would love someone to point me to Web pages explaining how the Bombe actually worked in cracking cyphers. It would be a splendid adjunct to the Bombe Rebuild material.
Top | Previous | Next |
David Caminer
In the first part of this article, published in the last issue of Resurrection, the author traced the progress of Leo from conception to the running of the first business application. Here he completes the story, recounting the development of second and third generation versions, and the gradual full exploitation of the capabilities of the computer. He concludes by discussing some of the lessons to be learnt from the project. |
The Bakery valuations job was the first business application carried out on Leo. On completion 50 years ago, the system delivered the results every week and in good time for years afterward.
Two years after this world-first business application, the full-scale Leo business machine was completed. The Leo team had by then developed an input-output system of its own.
It was a system with three input channels and two output channels all working concurrently with the computer's calculating operations. Magnetic tape had been discarded for the time being: the input transports were punched card readers and electronically sensed paper tape readers, while the output was to a line printer and a card punch. Data was read into buffer stores so as to be ready immediately it was wanted by the calculating unit in the main frame. Similarly, results were flashed out to the output buffers ready for printing or punching.
It was all like a three ring circus, except that there were many more than three things happening at once.
It was an enormous triumph for John Pinkerton and his team that the full system was completed to schedule and worked sufficiently reliably to be entrusted almost at once with a time-critical, externally visible job. His team, in modern terms, was still laughably small.
The completion of Leo I was the second major step in the Computer Revolution.
It had been intended from the outset that the first full-scale integrated application would be payroll. The payroll system that emerged led the world for many years.
It operated on the lines of one employee having his pay calculated while the data for the next employee was being read in from three separate channels and the payslip for the previous employee was being printed.
In the calculating phase everything down to updating the state of the employee's loan account was included. Tax was deducted with special provision for holidays. If the extent of deductions meant that the take-home pay would have sunk below a set level, then only statutory deductions would be taken. To reduce the time for making up pay packets, net pay was rounded off to half crowns and the positive or negative balances carried forward to next week.
This contrasted with the scene several years later in the States where, generally, only part of the job was done.
At the beginning of 1954, after a searching period of parallel running, 1700 Cadby Hall Bakery employees received their pay packets with their pay slips prepared by Leo. From then on the payroll job ran regularly in one form or another as long as Lyons was in business.
Systems re-engineering and outsourcing
The payroll application built closely on what had been done before while taking advantage of the new opportunities offered by the computer. But it came as no surprise that some applications had to be radically changed if the full advantage of the computer was to be obtained.
The first example of systems re-engineering in the Computer Revolution concerned the office work connected with the distribution of goods nightly to each of 200 or so high street teashops. There were hundreds of items, and as freshness was a matter of pride to the company there was little scope for keeping stocks in store.
There was a manageress in every shop. Under the existing system she filled in 10 or more multi-item order forms every day. Analysis showed that if all those entries had to be key-punched the job could not be done in time for packing to take place the same night.
The solution was to have each manageress set up a standard order for each item for each day of the week, and only send in alterations for those items that she wished to modify. A call centre was set up staffed by operators with headsets and card punches. They phoned each shop at a set time and the alterations were punched into cards. It was a quasi-online job, going as far as the technology of 1954 permitted.
A particular advantage of the system re-engineering was that the manageress had to spend much less time at her desk. She could spend her saved time looking after her customers. The manageresses were a formidable set of women and it was a matter of great satisfaction when they expressed their appreciation of the change.
Leo also introduced the concept of outsourcing, though the term hadn't been invented then. The first application of business outsourcing was the provision of a service for the payroll of the Ford Motor Company in 1955. Leo analysts produced a job specification that was approved by the local management. The Leo staff then produced the programs, training Ford staff to be able to make changes when these became necessary.
After trials, the programs were put into effect. The clock card data was brought by courier across London at a due time and the Leo organisation returned the completed pay data in the same way. Traffic congestion was less daunting then!
Previously, engineering and actuarial organisations had had their work done in this way, many of them on Leo. But this was the first time that a business firm had offloaded a routine, time-sensitive body of work. It was a very brave decision by a senior administrator, who put his reputation at stake.
Leo II and Leo III
To provide cover for the payroll and other Lyons jobs, a second Leo was eventually produced, and Leo II replicas were installed on the premises of a number of forward looking office organisations. These included the steelworks at Corby, Imperial Tobacco in Bristol, the Ford Motor Company Spares Depot at Aveley and the Social Security ministry in Newcastle.
By this time Leo Computers was running what amounted to a high-powered consultancy and software house as well as a computer line and a service bureau.
From all this experience came Leo III. John Pinkerton set out to give the consultancy staff what they wanted in terms of facilities and performance. At the same time he embodied the rapid technological advances that had occurred.
There were no longer thousands of fallible valves. Germanium transistors, silicon crystals and ferrite cores were the materials with which he worked. The machine was very much faster, the fast store was very much bigger and there was back-up storage on magnetic tape and drums. There was much less heat to get rid of. The whole ensemble was altogether more reliable.
And there were new features. The most important was that more than one program could operate at the same time. The feature was known as multiprogramming or timesharing. Several quite unconnected programs could run concurrently under the control of the operating system.
The system as a whole was particularly attuned to online working and the first steps in that direction were taken. All in all, the Leo III system that started work in 1961 was reckoned to be at least three years ahead of the IBM 360, in terms of facilities provided.
In 1964, the year that the IBM 360 was announced, the Post Office, already a large-scale Leo user, awarded the biggest computer order ever placed in Europe. It was for a network of Leo 326 systems right round the country, handling telephone billing, National Savings and Premium Bonds as well as applications for other government departments. Later they were used to introduce the Giro. In its day the telephone invoicing operation was the biggest computer billing job in the world.
Announcing the order, the Postmaster-General of the day, Tony Benn, expressed satisfaction that a British company had been capable of "standing up to and beating on its own merits" the competition from overseas.
Lessons to be learnt
So that is an outline of how the Computer Revolution was set in motion by a teashops company. This story raises questions, such as "Why, if Leo was so much in the forefront of the Computer Revolution when it started, did it not retain that lead?" "Why did the United Kingdom become a second-class nation in IT, a follower rather than a leader?" "How do we get into the front rank again?".
These are potent questions that have been asked not only about business computers, but also about other inventions that have emerged in this country and then been swallowed up in the exploitation stages. That's true of Leo's counterpart in the Industrial Revolution, the railway. We are a long way behind even there now.
In Leo's case it was a mixture of internal weaknesses and external forces that led to the decline. We should examine these to try to prevent the same errors from afflicting us again.
I suppose one prime weakness was that Leo had a sugar daddy in J Lyons. It is comforting to be freed of financial worries while history is being made, but it is more than likely that worries will catch up with you later. A good many dot com companies have recently found that out.
The worries caught up with Leo just when John Pinkerton had produced what was another world-beating machine. There had been no difficulty in finding the funds while the operation was still small scale and when Lyons itself was doing well and increasing its profits year by year. But times had changed. Lyons was needing all the funds that it could muster for its core businesses. The scale of the diversification had gone too far.
Accordingly, when the time came to launch Leo III, it was not attended by the fanfare of trumpets that might have been expected.
Emphasis was placed on two bureau systems, one in London and the other in Johannesburg. Further sales were to be obtained by confidential whispers to existing customers, and to users of the bureau services and to such large-scale businesses that presented themselves as word got around. Just think of IBM following that strategy for the introduction of the 360 range, three years later!
Lyons instead chose to reduce its exposure to the computer business by forming a partnership with a leading electrical machinery manufacturer, English Electric. It was not a suitable combination for fostering the Computer Revolution.
Indeed I know of no computer merger anywhere where there has been added value from the merger of competing forces of engineers, marketers and programmers. It is like two civilisations trying to come together. The merger of Leo and English Electric wasn't as bloody as the coming together of the Incas and the conquistadors, but sometimes it seemed just as unpleasant.... for both parties.
When the time came for a new range, English Electric went across the Atlantic to its partner, RCA, better known for its colour televisions. That signalled the end of the development of the Leo marque, though installations continued to operate very successfully for several years afterwards.
Looking back, it is tempting to beat our breasts. Our vision was blinkered. We were too occupied with making work whatever we were occupied with. We took too much satisfaction in working on a shoestring. We were too often arrogant about always knowing best. We had no idea of the rapid rate of technological advance.
What of the external forces? The first of these was the size of the market. From first to last, Britain was Leo's market. There were sales in the old dominions and behind the Iron Curtain but none at all, not even a service job, in Western Europe or the Americas.
Everything was too small-scale compared with the vast United States domestic market. Western Europe as a whole would have produced a comparable market, but there was never any likelihood of that happening.
Then there was the failure of the UK governments over the period to play a truly constructive part.
The financial assistance that they felt able to give was pathetic compared with what was happening in the States. Over the early period, IBM was given more in development contracts by the US Defense Department than the total amount spent on development by all the fragmented British companies together. Other US companies profited in the same way.
In Britain, such little help as was given went toward scientific computing. Murray Laver, the senior civil servant who later became responsible for guiding government computerisation, commented candidly: "In Britain generally we were slow to realise that the computer market for commercial work would outgrow and greatly exceed the market for science and engineering". Too slow, unhappily.
Finally there was a national malaise that made the going hard for Leo. On our coast-to-coast tour of the United States in 1958 to see where best practice had reached, John Pinkerton and I were bowled over by the difference in attitude to innovation.
At home we were still fighting to convince big business that computers were the gateway to the future. In the States we found highly expensive machines being installed in quantity.
The American psyche had taken off. With only one exception, none of the installations we saw in action was as venturesome or as integrated as what we had left behind on Leo I.
We were often mystified as to how the costs of the big IBM and Univac systems had been justified. But the Americans had sensed that this was the way forward and were anxious to take their place in the front. There was scarcely a breath of this at home.
Charles Babbage, the grandfather of automatic computing, had encountered the same syndrome a century before. He said: "Propose to an Englishman any principle or any instrument, however admirable, and you will observe that the whole effect of the English mind is directed to finding some difficulty, defect or improbability in it. "If you speak to him of a machine for peeling potatoes, he will pronounce it impossible. If you peel potatoes with it before his eyes, he will declare it useless because it cannot slice pineapples.
"Expose the same principle or show the same machine to an American and you'll observe that the whole effort of his mind is to find some new application of the principle, some new use of the machine."
I can only add that we have to recognise that syndrome and eradicate it. Otherwise, we will never regain the place in the forefront of the Computer Revolution that our pioneers won for us. Let us start from here.
Editor's note: this article is an edited version of the second part of the second Pinkerton Lecture, given by the author at the conference "Business Computing: the Second 50 Years" on 5 November 2001. David Caminer was Systems and Programming Manager of the Leo project from 1949. He can be contacted at <david at caminer dot fsnet dot co dot uk>.
SimulatorsSimulators for a variety of historic computers, including Edsac, Elliott 903, Pegasus, the Manchester University Small-Scale Experimental Machine and Zebra, can be found at our FTP site. Access details are on page 17. |
Top | Previous | Next |
Kevin Murrell
The BCL Molecular 18 minicomputer was introduced in 1970. This British-built system had a specialised multi-user operating system, and a 64KWord machine would happily support 20 users. All programming was in machine code, without even the help of an assembler. The machine found a niche in distribution companies throughout the UK because of its sophisticated sales order processing software. Molecular 18s remained in use for nearly 30 years: the last production machine was switched off in 1999. |
Business Computers Ltd (BCL) was formed in the early 1960s and initially produced hard-wired controllers for calculating odds in bookmakers. By 1966 the company was producing programmable stock control and invoicing systems.
BCL produced the Molecular 18 Mk1 in 1970. This was a 17-bit minicomputer wholly designed and produced in the UK. The '18' in the name referred to bit 18 - the parity bit. The Molly, as it was generally known, had two accumulators, a carry flag, and a greater-than flag. The seven most significant bits in an instruction word specified the processor operation code plus flags such as zero page and indirect addressing, leaving 10 bits for addressing. One could therefore directly address 1Kwords in the local partition.
Early machines were supplied with 32K core store and a disc drive with an exchangeable disc pack.
At first each installation ran a bespoke single user application employing a simple monitor program for common I/O routines. If the customer ordered two terminals, the application routines would be copied and modified to run at two different absolute core addresses.
The first recognisable operating system, LOS (Leicester Operating System), was produced in 1974 when a customer ordered three VDUs - it was decided that producing three copies of each application was not feasible! LOS was entirely core resident and occupied the first 12K, leaving as many 2K partitions as were needed up to 64K. Each terminal and printer was allocated a particular partition.
Application programmers called OS subroutines for all disc operations, terminal I/O, and commonly used routines such as Add-Double-Word and Multiply-Double-Word. The inline parameters for these calls were relative addresses within the task partition. The OS would then resolve these addresses based on the partition start address.
The system supported only cooperative multi-tasking, there being no hardware support for anything else. With the exception of a locked file fetch, all subroutine calls to the OS would generally first return to the task scheduler. Processor intensive applications would therefore be liberally sprinkled with Suspend calls to avoid hogging the machine.
Applications were written on pre-ruled coding sheets with each sheet containing 77 octal words. Generally we wrote in a pseudo assembly code, and inserted addresses as we hand assembled the code at a terminal.
Generally a shout would go up when one tested a program - it was very bad form to try a quick test without warning people and having the machine fall over. We all became adept at diagnosing a crashed system using the front panel, and could often set the program counter to force the system back into the OS scheduler! However, if the errant program had written all over the OS then nothing but booting would work. If your were particularly unlucky, you would also need to toggle the primary bootstrap back in using the front panel.
Customer support was all telephone based, so it helped if the customer understood octal! We all knew the bootstrap so well it was possible to spend five minutes on the phone talking a customer through entering the code at the front panel without referring to notes.
The initial range of peripherals included single line LED displays with a keyboard, paper tape punch and readers, and IBM golfball printers. One early printer supported two paper tractor feeds with a single print head, used for simultaneous printing of both invoices and packing notes.
By the late 1970s the range had stabilised, and the Mk4 became a popular and reliable machine supplied with standard dumb terminals and printers and one or two CDC Hawk disc drives. A two drive system had a total capacity of 10MWords. The Mk4 was the last machine to support core memory: later versions used static semiconductor memory and battery backup.
Apart from the inclusion of multiple logical shifts and rotates (introduced in the Mk 3), the instruction set did not change throughout the life of the machine. Memory reference instructions took 2.4 microseconds in 1970 and still took the same time in 1999.
The last generally available machine was the Distributor. A smart new chassis was produced which included a CDC Lark drive and, in order to support a larger partition size of 4K and more users, bank switching of the top 32K was introduced. Plans were made for a multiprocessor machine that sadly were never realised.
Severe Year 2000 issues in both the Operating System and the application programs, and the lack of funds and expertise to correct these problems, meant that all the machines still in use were retired in 1999.
The Computer Museum at Bletchley Park has a Mark V machine currently under restoration. I am working on an emulator for the Molecular, and luckily have machine-readable copies of the operating system and of one application suite.
Editor's Note: Readers can find more information about the Molecular 18 at <www.ps8computing.co.uk/Molly/molecular.htm>. The author can be contacted at <kevin at ps8 dot co dot uk>.
Top | Previous | Next |
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.
Top | Previous | Next |
Ann Moffatt
More and more Pegasus users are emerging from retirement to recount stories of their misspent youth! This article describes how Kodak UK stretched the computational capability of early 1960s computer technology to its limits before being told by its US parent company to concentrate on invoicing! |
I joined Kodak in April 1959, starting in the Quality Control group based in Headstone Lane, Harrow.
Initially, we used punched cards and purpose-built plugboard systems to prepare data for our statistical analyses. The calculations for these were done by hand, supported by slide rule and log tables. Most calculations were standard correlation and regression analyses.
In July I was sent on a programming course at Ferranti to learn how to program Pegasus. As a 19 year-old, I was overwhelmed by the beauty of Ferranti's Portland Place facility. The computer room on the first floor had beautifully painted pictures on the panelled ceilings and a highly polished, sprung floor as it had been used as a ballroom.
I had been told by my boss at Kodak that, as the two week course cost £100, I had to get value from it and develop a program to calculate a Chi Squared Analysis.
Our trainers included Bill Payne, George Felton and Conway Berners Lee. The trainers/programmers spent their time in rooms at the top of the house which had been servant quarters. They were of quite different quality from the opulence of the computer room, with low ceilings and tiny windows. This area was known to all as The Zoo!
I loved programming from day one. Living with my parents, I worked through the night trying to write the Chi Squared program, much to my mother's concern.
On the Friday at the end of the first week we were all to get a turn on the computer to run our test programs. These programs calculated, for example, the amount of grass seed needed to make a lawn with flower beds in it, or how long it would take to fill a bath with taps delivering a specified volume of water but for which the plug was leaking, giving water loss at the other end. One very complex exercise was to calculate the date of Easter up to the year 2000.
Programs were punched onto paper tape. It was obvious to all from the size of my roll of paper tape that my Chi Squared Analysis program was many times larger than everyone else's. Bill Payne took me to one side to find out where I'd 'gone wrong'.
Probably because I was by far the youngest on the course, and a pretty young girl with the then very fashionable huge full skirts over starched petticoats, I think Bill took pity on me. I had obviously misunderstood how to write my test program. I explained to Bill that my boss expected value from the course, and showed him my program. He was horrified. It was {\em huge}, and very complex. Bill pointed out that the program wouldn't work because it needed a routine we hadn't learned yet. I started to cry, so Bill quickly wrote the extra code needed and tacked it on the end of my program.
Everyone else's program worked, maybe not getting the correct result but at least getting to the end. Mine took ages and looked as if it had got into a loop. I worked on it all the weekend and was certain that my code was correct, so it must have been Bill's bit that was wrong. On Monday I confronted him and he laughed.
Later in the week we learned the code Bill had written for me, and I was then sure he had been wrong. I added the newly learned code to my program, and on the last day of the course when we had another go on the computer I insisted on running my program again. Because it was so large, I had to wait until the other students had run theirs. They each ran in about a minute, and were all correct. Mine ran for half an hour and I was threatened with having to take it off (Pegasus time then cost £50 an hour). I cried again and the program was allowed to run to the end. It was correct, and my Chi Squared program joined the other statistical programs in the Ferranti Library.
Back at Kodak, I was transferred into the Operations Research group in August 1959. The group comprised John Croston as Manager, Derek Trigg, Barbara Bubb, Helen Kleineke and myself.
Most of our work focussed on the optimisation of the production process and on accurately estimating product sales. The product estimates were then exploded into the components needed to make those products. To do this we had to get accurate information on those components. We started with the components from Finishing Department such as boxes, labels, and the amount of film or paper in a product. Surprisingly, the information we needed was not written down, and there were many opinions that had to be rationalised before component data could be recorded in what we called a 'recipe' (it would now be known as a data file, or part of a database).
Estimation was Derek's area. He worked on exponential smoothing, trying to find an optimum value for $\alpha$, the multiplying factor that would give optimum estimates. To that time there had been about four sets of estimates: Sales estimates; Management estimates; Finishing Department estimates; and the workers' estimates of what they thought they could produce. Additionally, there were no real statistics on wastage, certainly none on wastage of different components. It was a real culture shock when the workers found that the computer could tell them how many of each product to make to meet sales targets, and how much of each component was needed to produce the products. The concept of producing an optimum ordering quantity for each component and an optimum production quantity to meet market needs while minimising wastage was introduced by the computer.
We then moved backwards through the manufacturing process. Next we calculated how much film of each type to coat with emulsion and how much emulsion to make, again optimising ordering quantities for raw materials like chemicals and film base.
Products with faults could also be analysed to optimise final usage. One such computer program produced a diagram of how to cut coated rolls of X-Ray film with known faults (usually static marks caused in the coating department) so the resultant product was fault-free and brought maximum return. In the past, faulty X-Ray film had often ended up as dental X-Ray because it was the smallest sheet and did not require the really high quality needed in larger sheets for, say, chest X-Rays. However, larger sheets produced more profit and Dental X-Ray was more costly to pack.
There was also consideration to be given about capability of 'slit and chop' machines that slit the 42 inch coated roll to final widths and chopped to final sheet sizes. (Not all coated film was 42 inch width: it could vary from 40 inches to 49 inches.) Also, whenever the 'slit and chop' setting on the machine was changed there would be downtime, again impacting on costs and productivity. There was a complex hierarchy of slit/chop changes, some being easier if coming before or after others. The program took these into consideration when developing the plan.
Roll film, from 35mm professional movie to box brownie film, could also be slit and chopped differently according to faults detected. There was a joke that if all else failed it could always be cut down to 8mm fogged leader film! When 70mm professional movie was manufactured for a short time, it proved very difficult to produce enough long, wide lengths to meet market needs.
It is amazing to me now just how much we did on Pegasus. All code was machine code and most of the work was done with 'recipes' on paper tape. It was bliss when magnetic tape appeared!
From this initial beginning we went on to more sophisticated Operations Research techniques, including Linear Programming and the application of PERT to the production process. We were really pushing the limits of Pegasus and as soon as the Ferranti Mercury became available we moved to that, still renting time on the Shell St Mary Axe machine, the Oxford University Mercury, and later, the London University Mercury. The joy of Mercury was that code could be written in Mercury Autocode!
We had a brief skirmish with Orion but felt it did not suit our largely complex mathematical programming. When the Ferranti Atlas was being developed in 1963 I was sent to Manchester to work with the Ferranti engineers.
We rented time on the London University Atlas and decided to buy a 10\% share of that computer to continue our scientific work (Kodak had by then bought an EMI Emidec for commercial work). We wrote to Kodak in the USA to get permission to buy into the London Atlas. At that time the UK Kodak was well ahead of the USA in the application of Operations Research. We were told that Kodak was going to standardise on IBM 360.
We asked to see the specs of the IBM 360, and quickly concluded that we could not do our work on that machine. We had difficulty in deciding what could be done on the 360, so wrote to USA Kodak to ask. We were told the 360 would do invoicing! We had a typing department in the UK that did invoicing!
At that stage, 1964, Kodak developed Computer Departments, and future work focussed on the commercial application of computing.
Editor's note: The author's name was Ann Hill when she started working for Kodak: she became Ann Leach in 1961. She now lives in Australia, and can be contacted at <annm at exocat dot com dot au>.
Top | Previous | Next |
Dear Editor,
Since the end of the Second World War, a total of 10 different computers have been manufactured in Wales, but the product of one of these companies has only recently come to light. Wilcox Computers was based at Rackery Lane in Llay near Wrexham from about 1978 to 1989 (it changed its name to Saga Wilcox in 1984).
The company was founded by Norman Wilcox and they manufactured small business computers based on the Zilog Z-80 microprocessor. The operating system was designed by the Wilcox company to provide those functions that they considered a small business would need. The software packages, again designed in-house, included a purchase and sales ledger, stock control, invoicing and payroll applications. They had 75 customers by 1979 and received investment from the Welsh Development Agency.
Do any readers remember using a Wilcox system, or is anyone aware of the existence of some Wilcox hardware? If so, I would be grateful if you would contact me by email at <richard.davies at nmgw dot ac dot uk>, or on 02920 573576.
Thank you very much.
Yours sincerely,
Richard Davies
Curator of Modern and Contemporary Industry
National Museums & Galleries of Wales
Heol Crochendy
Parc Nantgarw CF15 7QT.
19 August 2002
Editorial contact detailsReaders wishing to contact the Editor may do so by email to |
Top | Previous | Next |
Every Tuesday at 1200 and 1400 Demonstrations of the replica Small-Scale Experimental Machine at Manchester Museum of Science and Industry
Weekday afternoons and every weekend Guided tours and exhibition at
Bletchley Park, price £6.00, or £5.00 for children and
concessions
Exhibition of wartime code-breaking equipment and procedures,
including the replica Colossus, plus 60 minute tours of the wartime
buildings
17 December 2002, afternoon London meeting titled "Early Statistical
Computing"
Speaker Gavin Ross
21 January 2003 NWG meeting titled "From Operating Systems to Windows"
Speaker Brian Warboys
20 February 2003, 1615 hours London meeting titled "The Ferranti/ICT
Orion Computer"
Speaker Chris Burton
The London meetings will take place in the Director's Suite of the Science Museum. The North West Group meetings will 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>.
Top | Previous | Next |
[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 Kevin Murrell
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
Eric Jukes
Dr Roger Johnson FBCS
Graham Morris FBCS
Dr Adrian Johnstone CEng MIEE MBCS
Brian Oakley CBE FBCS
John Southall FBCS
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.
Top | Previous |
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
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.
|