Home > LEO Computers > LEOPEDIA > Oral & Narrative Histories > Alan King: Interview
 

Alan King: Interview

 Home > LEO Computers > LEOPEDIA > Oral & Narrative Histories > Alan King: Interview
 


Interviewee: Alan King DOB: August 1936, died 2017
Interviewer: Tony Morgan
Date of Interview: 16.08.2011
Role in Lyons: Systems Research Office, then Lyons Computer Services
Joined Lyons: Autumn 1959

Abstract: Alan studied Classics at Oxford and on graduating was taken on by J Lyons & Co. in their Systems Research Office. A career working on a number of the Lyons LEO application followed by a senior role in Lyons Systems Services, formed to develop and service computer applications first on LEO machines and later when Lyons replaced LEO with IBM computers. Acting Chief Executive Institute of Administrative Management.

(Recording to be added.)
Copyright: Alan King and LEO Computers Society.
Restrictions: None known.

Date : 16th August 2011

Transcript :

Alan King: The LEO Oral History Interviews
Interview date: 16th August, 2011

Tony Morgan This interview of Alan King has been recorded by The LEO Computers Society as part of an Oral History Project to document the earliest use of electronic computers in business applications.  Note that any opinions expressed are those of the interviewee and not of the Society.  Copyright of this interview in recorded form and in the transcript remains with The LEO Computers Society, at 2011.  

Tony Morgan Hello, Alan. It's great to meet you at last for the first of what we hope are going to be a series of interviews with people involved in the early days of LEO 1 computers. So to start at the beginning. When and where were you born? 
Alan King I was born August 1936 in Ashton-under-Lyne, was adopted at a very early age and grew up in Barnet.
TM Where were you educated and what did you study?
AK I was educated five minutes across the road at the local primary school. As an indication of the time, I was living next door to a gas treatment station. This site eventually became part of the Blood Transfusion Service. I went from primary school to a local grammar school, Queen Elizabeth's Barnet, and then to Oxford University where I studied Classics. That was Greek and Latin, language and literature, classical history and philosophy.
TM Had you heard of LEO by the time you left school?
AK I had not heard of LEO or computers until I left university in Summer 1959.
TM What did you do when you left university and how did you come to join Lyons?
AK I hadn't looked for a job on the assumption that I'd be doing National Service, but it was being phased out by then, and, given my poor eyesight, I was put on a reserve list. So I found myself having to look for a job and applied to J. Lyons, amongst a number of other organisations, as trainee commodity buyer. Milk, sugar, cheese, that sort of thing. They wrote back and said that they'd filled all of those vacancies but had jobs as O & M 2 Officers working with computers. I remember writing back and saying that I'd only got O level maths and no physics qualification and got a response back that said 
'Dear, Mr. King, you obviously don't know the first thing about computers. You'd better come for an interview'. 
So I went for an interview and an aptitude test. Computers were not mentioned overmuch. We argued about Freudian psychology for nearly an hour. But at the end of which, the Personnel Director said 'Yes, I think we'll take a chance on you. Would you like to start next month at seven hundred pounds a year?'. And conscious of being expected by my father and fiancée to work and earn money, I said 'Yes' and started in Autumn '59.
TM What were your early experiences at Lyons?
AK I was part of the department called Systems Research which had grown out of John Simmons clerical empire as a result of the established use of latest management techniques, because Lyons were pioneers in things like Work Study, Operations Research and Microfilming as tools for the lowest cost processing of the information. It was a business which made a quarter of an old penny profit on a cup of tea and a bun. So it was obviously very important that the high volume of information was processed as efficiently as possible. 
Systems Research had been set up to handle the major development of in-house applications when LEO Computers was created as a separate sub-co. There were a dozen or so staff with mixed academic backgrounds. I remember there were a couple of colleagues who had tried to make a living as barristers but hadn't been able to establish sufficient clientele, a guy who'd got an agricultural degree from Reading University, a couple of mathematicians and me as a classicist.
TM Were LEO I and LEO II/1 3 operational then?
AK Both LEO I and II/1 were operational and I remember Peter Wood as the Operations Manager, Norman Beasley, who became the Operations Manager for the Lyons LEO III 4 installation and number of other people.
TM What systems and applications were you involved with?
AK There were no new LEO I jobs being developed, just maintenance, so my work was new applications for LEO II and preliminary planning for the Master Plan and LEO III.
TM What applications were you involved with?
AK For the last two or three years before it was taken out of operational use I was personally responsible for maintenance of LEO I and II/1 applications that were still operational. L1 and L11 - Payroll, L2 - Teashops Orders and L5 - Bakery Rounds. L14 and L17 - Teashops and Corner Houses Payrolls, for example. So while I was far from the first LEO I programmer, which accolade would go to Derek Hemy or Mary Blood, I was very definitely and unarguably the last.
TM What do you remember about the early systems analysis and development procedures?
AK There are a number aspects of the LEO I systems and workload which I found fascinating even though I hadn't been involved in their development four or five years earlier.  Applications had been justified because they enabled the management to plan and operate more efficiently, and they weren't just about cost cutting from the reduction of clerical staff numbers. Applications like Teashops Orders and Bakery Rounds were about running the business more efficiently. And that certainly applied to the bureau work that Lyons had built up on LEO I and was the prime reason why they went into the manufacture of computers through LEO Computers as a sub-co. This was things like the design criteria for the Comet (the world’s first jet air-liner, calculating the tax tables after the annual Budget, working out the shortest, most economic route for transport by rail between any two British Rail Stations, and the calculation of some sort of ballistic information where the computer room had to be cleared except for people with Official Secrets Act clearance.
The second thing I remember was the hardware and software facilities that had been developed to optimise what could be achieved with just a 2K 5 memory. David Caminer6 and his people had had to invent from scratch because it was the first business computer. Concepts like Initial Bootstrap, Subroutines, Relative Addresses, Negative Check Totals on card input, Verification of paper tape input. So despite these program techniques that made the best of the 2K memory, applications like a payroll still had to be split into separate runs of interlinked, subsidiary programs, reading punched card files and paper tape linked between them. So for example a payroll would involve runs for vetting the data, calculating gross pay, calculating net pay, printing payslips, printing accounts, doing a cash dissection, tax year end and doing schedules of starters and leavers. It would take several hours for the entire business operation to be completed.
Other memories. The main weakness operationally was still in data input. A couple or three examples spring to mind:
The occasion where, although the system had been operational for four or five years, there was one run when somebody who was on holiday and had then been reported sick, had their service terminated. This blew the program because it was the first time in which that combination of data had been submitted and obviously it hadn't been tested at the time that the system was designed and there was a program error.
And then there was another occasion where one of the staff busy putting money and payslips into envelopes came up to the Supervisor and said, 'Please sir, could I have another envelope because I can't get all the money into this one'. Subsequent investigation showed that there was a weakness in the program which LEO I connoisseurs will recognise revolves around the separation bit between half compartments and full compartments. And the bit had been, well I forget whether it was picked up accidentally or had been dropped and this had caused the machine to miscalculate gross pay and net pay.
And then there was the example where an external system called Cows and Goats was run each year at the time of the Dairy Show at Olympia. The output of the cows and goats, in terms of milk, was taken away and analysed and the results were fed back into a program which calculated who was giving the best yield and the prize heifer that was supposed to win showed up down the bottom of the list and was about to be taken away to be slaughtered, when it was found that there had been a data prep error, I think involving putting the decimal point in the wrong place or missing it completely.
Still more memories. Of course you could be there many hours of an evening time finding out why an operational run had gone wrong. One consolation was that you were allowed to go upstairs to the Directors' Dining Room and get an evening meal, cooked by trainee chefs at two o'clock in the morning.
And the other thing that I found fascinating was that access to the machine to run tests involved the operators going off for a cup of tea and a bun to the Staff Restaurant and they let you have the machine for half an hour, and if, for example, you then found yourself in a continuous loop you could single step through the sequence of operations the machine was obeying and see that the Exit Subroutine instruction was going back to the Set Subroutine Up. And you were then able to use the buttons on the control console to put the correct pattern of noughts and ones in to go back to the correct location and then use a button called Stack in Store, so you corrected the machine online as it were. Highly discouraged but operationally very useful and great fun.
The Systems Research Department was PURE CAMINER in the way that it worked. So you talked to management and staff to ascertain key functions for the proposed application rather than just computerising their existing operation. You then designed the program suite of interlinked card files and data and results before you'd pick up a coding pen. 
When you'd finished the coding, it would be desk checked by a colleague before a program card deck was produced. A very important example: there was no space for luxury and each sequence of instructions involved with, say calculating gross pay, had to be done in the minimum number of instructions in order to fit the required logic into the 2K  memory together with the data. Equally you had to time how long it would take the machine to process each card of input, because if it took longer to process a card than the card read cycle, then every other read cycle the card reader would not be feeding information into the machine and the running time of that particular application would be doubled. We made extensive use of subroutines e.g. for processing card input or printer output; and they had been honed to near perfection by previous programmers. Nevertheless, a shout of triumph would very occasionally resound through the office when clever use of the machine's sometimes peculiar logic enabled one more order to be deleted. The bigger memory, faster clock rate and micro-progamming logic embodied in LEO III took away this particular challenge and pleasure of course. 
Anyway, when all of this had been worked out with colleagues we would do comprehensive test data runs and then beta testing with live data. And then, only then, systems manual, operating instructions, user training and a periodic review.
TM Were you present when LEO I and LEO II/1 were switched off.
AK No I wasn't. But I do remember shortly after both machines had been decommissioned, we had yet another move in the Cadby Hall 7 complex of the Systems Research Department. We had filing cabinets of coding, user manuals and information which would now be very worth having. It all went across the yard to the Cadby Hall incinerator to fire up the heating system. Some systems manuals are known to have survived and be in my care or that of former colleagues. I do actually have one sheet of subroutine coding from P1, which went operational in November 1951, which is an interesting archive and it really needs to be kept somewhere.
TM In the LEO III era, what was your involvement with LEO III/7 and LEO III/46?
AK My major role after two or three years in Systems Research was as a Project Leader for the Tea Division team and then Corporate Systems Development Manager. The LEO III computer work was based on concepts that had been learnt from LEO I and LEO II experience and incorporated the realisation of the John Simmons Master Plan which involved a pro forma suite of programs adapted for each of the J. Lyons Group operating divisions.
TM The Autolector 8 and the Xeronic 9 printer were important to the Lyons operation. What was your involvement there?
AK Something else that we came up with and I was personally a leader in, was the concept of a turnround document whereby, for example, with a Tea Sales Order system, you printed through the Xeronic printer an order form for the salesman to take into the shop the next week and on the order form you printed the products that that customer normally took and the quantity, and other products that the customer didn't take at the moment, but his pattern of trade would indicate that it would be worthwhile for him to add, and thirdly, products which were subject to some sort of special sales offer. Three for the price of two. So therefore the order form was not just, when he filled it in and sent it back, a means of data capture. It was also a means of marketing the product and increasing the business throughput. Anyway the Xeronic forms were filled in using a bar marking system and sent back and fed into the machine through the Autolector.
One of the things that I was personally involved in was the development of this concept in conjunction with my colleagues in LEO Computers, coming up with subroutines for the Master Routine that would enable these two peripherals to be handled. The Autolector took the place of an earlier manually-fed device, the Lector, which produced paper tape for input to the data vet logic. A colleague, Edward Averill, and I used to visit Minerva Road to contribute to the design of the machine but it proved to be far too slow and unreliable for operational business use.
One of the problems we had with handling the two devices was that the Autolector was a bar mark reader, and if you were asking somebody to enter the bar mark for a quantity between one and nine, you could have got the software to assign a mark in the four boxes labelled one, two, four or eight, but then that meant if they wanted to mark seven they had to mark three of the bar mark boxes, so we eventually settled for one, two, four and seven as the value of the four boxes, which meant that all numbers between one and nine could be entered with two marks. We also with the Autolector realised that if an incoming form back from the business was malprocessed in some way, you could get the machine to print a query form which could go to a small data input team who would clarify what the pattern of marks was if the business person hadn't entered them properly and feed that back without having to refeed the original document. The selection form that had been printed from the Autolector input run would automatically match up the correct reading with the document that had been queried.
Again, with the Xeronic printer we had some difficult problems to solve. It was controlled by a magnetic tape as an offline device and one of the features of the Xeronic printer was that it had a sixteen blank formats you could call upon and it would print the form outline together with the variable information for each particular output document. But because of the design of the Xeronic printer, while you were printing document number 'n', you had to tell it which blank background it would need to print document number 'n+1', and that involved some quite sophisticated programming. Subroutines that could be incorporated in the application program and the correct instructions to the Xeronic printer would be edited to the magnetic tape.
Of course the famous aspect of the Xeronic printer was the fire, where one evening, the operator running the Xeronic printer dozed off and the output paper didn't wind onto the drum properly and concertinaed back and touched the hot heating grid9 and caught fire, The entire Xeronic printer went up in flames. We know it reached a temperature approaching a thousand Centigrade because some of the components had that as their melting point and III/7 was entirely covered in soot and had to be stripped down and cleaned by LEO Computers and rebuilt. Fortunately we were able, with prearranged backup run arrangements we had with the Post Office, to go to Charles House, the other side of Olympia, and use their LEO IIIs to keep the vital work going. But it was a fraught time, not least because the evening when the fire happened, was the day before the Lyons Group Annual General Meeting was being held in the City and there was considerable concern amongst the senior management that not only would the share price be adversely affected if the news got out, but some of the Lyons ongoing business would be seriously affected and not be able to continue.
TM What was the future of computing in Lyons?
AK Lyons Computer Services had been formed in order to manage the development of computer usage across the group in circumstances where instead of a big paternalistic group in the nineteen twenties and nineteen thirties, the different operations of Lyons; Ice Cream, Tea, Bakery, Catering and Hotels were forming into semi-autonomous operating companies. There were increasing calls for each operating company to be able to develop and manage its own computing usage. So Lyons Computer Services was set up as a separate company with a board of directors composed of representatives from each of the main operating divisions and a technical team, which I headed. We had a top computing usage guy from each operating company and we met regularly in order to discuss the priorities of developments. There were four of us who effectively ran Lyons Computer Services. The Managing Director was a guy who had a career in the Bakery Division, called George Stevens. There was me as the top development man, Norman Beasley as the top operations man and Dennis Toombs as the top communications guy.
TM How did Lyons Computer Services work out?
AK Lyons Computer Services proved to be a reasonably successful holding arrangement but ultimately changes in management structures and the availability of small, powerful computers and remote terminals linked by a comms line into a main frame meant that the Master Plan never saw full implementation. The Hotels, for example, started using PDP8's for room booking. Other operating companies started using process control machinery and had their own clerical control systems linked in with the manufacturing and distribution processing. 
There was also, I remember, the occasional failure, the best known of which was ARDOC which stood for Alpine Refrigeration Deliveries Operations Control, a joint subsidiary of Lyons and Nestlé that distributed Lyons ice cream and Findus frozen foods. The Lyons part of it involved balancing product storage in difficult circumstances, because of the characteristics of the ice cream trade, with the changes in volume between a hot summer heat wave and a cold winter blizzard. It meant that you had to make a lot of stock over the winter and store it for some months and then hope that you could distribute it around the sixty odd distribution depots in a pattern that minimised stock outs and failures to meet customer demand. 
ARDOC was set up to produce daily transport schedules for factories to distribution depots and distribution between the distribution depots using stock figures and information about the available transport facilities: what vans of what capacity. Unfortunately fork lift trucks had been entered as one category of transport that was available and so a distribution manager was not particularly impressed when on one occasion the system said that a pallet of ice cream needed to be moved from Yorkshire to Lancashire and the vehicle to be used was a fork lift truck over the M62 motorway. And not for that specific reason but for other difficulties in route planning ARDOC never saw the light of operation. 
But the main reason was that, as I've said, the operating companies started developing their own systems and their own computer departments. Eventually the time to consider replacing the LEO III machines came and both Lyons and Allied Lyons and IBM are another story. 
TM Did you have any other LEO involvement?
AK There was an informal User Group for organisations with a LEO III installed which met with senior LEO Computers staff from time to time at the Bonnington Hotel in Southampton Row to discuss priorities for enhancing the range's hardware and software facilities. I had the privilege to chair the Group.
TM Well, thank you Alan. You asked if I knew a good hostelry for a beer and a sandwich. Let's go to the Case is Altered. It was good enough for the Wrens during the war who ran the Bombes and Colossus at RAF Eastcote when it was an outpost of Bletchley Park.


This interview with Alan KIng has been recorded by The LEO Computers Society and the Society would like to thank Alan very much for his time and his reminiscences. The interview and the transcript will form part of an Oral History project which will document the early use of electronic computers in business and other applications, but particularly in business.  I repeat that any opinions expressed are those of the interviewee, that is Alan King, and not of the Society. The copyright of this interview in recorded form and in transcript remains the property of The LEO Computers Society, 2011.  
© 2011, Leo Computers Society

Footnotes
1 LEO – Lyons Electronic Office. The world’s first business computer. Developed by J. Lyons & Co. Ltd., a major caterer and food manufacturer, with the addition of binary to decimal and sterling conversion/reconversion and buffered input and output channels, from EDSAC (Electronic Delay Automatic Storage Calculator) designed by Cambridge University. They both had mercury delay line storage for their main store.  LEO occupied a room 10m x 60m.
2 O & M - Organisation & Methods.
3 LEO I & LEO II/1.  -The original and only LEO is now known as LEO I.  LEO II/I was the first of a planned series of more advanced computers with a store four times faster than the original machine.  It was established in the room next to LEO I and occupied about 15% more space.
 4 LEO III – This was the final development of the LEO series with parallel computing and magnetic core storage.  there were three models: the basic LEO III, the LEO 326 with a store refresh time of 2.6 microseconds, and the LEO 360 with a 6.0 microsecond refresh time.  The control program was called the Master Routine.
5 2K – Two thousand words, the equivalent of eight thousand characters.
6 David Caminer was the lead designer of LEO applications
7 Cadby Hall – the Headquarters and main factory of Lyons in the Hammersmith Road in London.
8 Autolector – an on-line reader for hand-marked documents designed and manufactured by Parnell and interfaced  by LEO computers Ltd and used on LEO III.
9 Xeronic printer – an off-line high speed printer, manufactured by the Xerox company, driven by a magnetic tape written on LEO III.
The Xeronic printer projected the form outline and data characters onto a light-sensitive surface of a drum.  This created an electrostatic charge on the surface representing the required printing  A toner powder was passed over the surface and picked up by the electrostatic charge.  The drum was next rolled onto the computer stationery which picked up the toner powder.  The toner next had to be fixed and this was achieved by melting it under a very hot grill.  All this process was carried out sequentially as the paper moved rapidly through the machine.  If a paper jam occurred, as Alan describes, the operator was supposed to grab two handles on the back of the grill and remove it immediately.  This did not happen on the occasion Alan describes – a mega disaster.



This exhibit has a reference ID of CH53369. Please quote this reference ID in any communication with the Centre for Computing History.

Copyright
The video above may be subject to copyright of the original author and is present only on this website for non-profit educational purposes only. If you are the original copyright owner and wish to have the media removed from this website please contact us using the relevant contact email address listed on our contact page.

 

 

 

 




Click on the Images
For Detail






Help support the museum by buying from the museum shop

View all items

Founding Sponsors
redgate Google ARM Real VNC Microsoft Research
Heritage Lottery Funded
Heritage Lottery Fund
Accredited Museum