Home > LEO Computers > LEOPEDIA > Other Memoirs, Reminiscences > John Daines: Reminiscence
 

John Daines: Reminiscence

LEO was the first computer to be used for business purposes. This meant a change in the priorities of computer design. The first change was that it was used for data processing. It spent relatively little time actually calculating and a lot of time reading paper tape, printing and reading and writing magnetic tape. The role of the Master Routine was to manage the computer efficiently and attempt to keep everything going full time. This is what multi-programming is about.

The second priority was for reliability. Lyons would receive telephone orders every evening and these orders had to be on the lorries by the following morning. The business came to depend on a working computer. Computers did break down, and every installation had on site engineers so that the moment a breakdown occurred the engineers were in the machine room within minutes. Spares were kept on site, ready in case of need.

Software, especially the Master Routine, also had to be reliable. Releases were strictly controlled. A new release would incorporate many changes. It had to be tested by the team in dedicated slots of machine time. It was beta tested by using it on the service machine in Hartree House and then released to customers. The customer would run his own tests before installing it. If a bug occurred the customer would revert to a previous version. Upwards and backwards compatibility was essential. A bug would cause a paper dump to be sent to the team by courier and a patch would be issued. A new version of the Master Routine was not allowed. If a patch did not work it could be removed. The danger of a patch was that while curing one bug it might inadvertently create a new one.

Reliability required strict discipline in the creation of the Master Routine. Machine time was expensive, requiring dedicated use of the machine. Testing took place overnight so one was only allowed one test a day. I have a feeling that several changes were assembled into one Master Routine, so a trivial mistake in the code in the heart of the operating system could mean that no one in the team got a test that night. Accordingly, code had to be checked by the programmer and rechecked by another member of the team. The emphasis was on getting the code to work first time, with testing being quality control. Of course, this was not always achieved.

Code had to be intelligible to other members of the team. Being written in machine code, it had to be commented and written in such a way that other members of the team could understand it. At the same time, we were under pressure to write economic code and were told that every word saved would save the customer £5 of RAM. Virtual store was not even dreamed of. Understandable code therefore meant that it had to be understood by another member of the time. As the members of the Master team were probably selected from those who performed best in the aptitude test it might have been difficult for someone from outside the team to understand it.

Some programming practices would be frowned on today. The manual specified the effect of an instruction for straightforward use and we would sometimes wonder what would happen if we went outside the specification. One example would be what would happen if one used a decimal add on a hexadecimal number. In such a case a member of the team would ring the designer of the microcode. He would get out the flowcharts of the instruction and tell us, so we were programming to the microcode rather than the specification. Another quirk was that a switch might be implemented by overwriting the next instruction by an unconditional jump, something that would be prevented by modern hardware. It worked because LEO III had no instruction cache.

There was no written manual. Programming standards were passed on by word of mouth to each new entrant to the team. Disagreements were resolved by the team leader. We worked as a close knit team with about a dozen members. It included men and women and the only thing that mattered was technical competence. We were all in the same room and could talk to anyone at any time. Each person in the team could work on any part of the Master routine and, importantly, maintain it.

There were good things about the way we did things and questionable things, but it taught me the discipline needed of a systems programmer. This stayed with me all my working life: take care when writing the code and do your best to get it right before testing. I took the same ethos with me when I later worked on 2900 VME. Good programming is about discipline.

I had some fun working on LEO. I remember being given the boring task of writing a test program for the printer. In response I created a program to print out the value of pi to as many decimal places as I wanted. After evaluation of the next ten digits it would print out the value so far. Pi is evaluated through an infinite series so the task is not as difficult as it may seem.

One thing I am particularly proud of is a creating new version of the bootstrap. The bootstrap consisted of reading in a sequence of code and obeying it and this code would load the Master Routine. Unfortunately the paper tape reader read 7-bit characters because it was intended for reading ASCII, and so the only instructions available were those which those in which the top bit was zero. These would culminate in an unpack instruction which converted the rest of the paper tape to binary. The bootstrap was in existence when I joined, but then a customer – Dunlop, LEO III/3 - bought a computer which used cards and had no paper tape reader. The bootstrap was over 80 characters long and would not fit on a card. The customer would not have been happy to buy a tape reader simply for loading the Master Routine! I was given the task of compressing the bootstrap into 80 characters. This I achieved, probably using an obscure instruction sequence.

One day a consultant expressed dissatisfaction with the handling of magnetic tapes. A tape would be loaded on to the tape deck and an operator would inform the computer of the label on the tape. Any direct operator interaction is by its nature error prone and the consultant was prepared to pay for an experiment in hide and seek, whereby the computer would read the label. I was given the task of extending the tape handling of the Master Routine to do this. As there was no machine time available for it in Hartree House, I spent a few weeks in Birmingham making the modification, using machine time provided by the consultant. At the end of the exercise I produced a 17 page typewritten specification of the ‘Controlling Master Routine’. It states how it would identify each tape, assign it to the correct program and unload it when it was finished with.

My memories of LEO are interspersed with other memories from that time. Working hours were from 9 to 5 five days a week with no overtime. We always had lunch in an Indian restaurant just round the corner and could wander around Whiteleys department store in the time remaining. The winter of 1962-3 was cold and the snow lay on the ground for six weeks. I was there for the last London smog when, standing at the traffic lights, I could not see the light on the other side of the road and the foul air meant that I went straight home after work and never went out until the next morning. The Cuban missile crisis took place in 1962 during the introductory programming course. At first I lived in London in Fulham Palace Road and I would spend Saturdays wandering the streets of the City exploring the many beautiful Wren churches. We could buy excellent seats at Covent Garden for £2 courtesy of the Lyons social club. I was sent a credit card through the post unrequested and without a credit check. After six months I moved back to my parents in Camberley and commuted in my first car: a Ford Anglia with the raked back rear window in which I could career downhill at sixty-five miles per hour on the Staines bypass and park on a side street near Hartree House.

The world was changing. It was an exciting time to be young, independent and at the forefront of technological innovation, but I do not think I realised it at the time. 

Date : 2020

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

John Daines: Reminiscence

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