Working with Leo III Computers at SMBP, 1965-1967

What happened when I worked on the LEO III computers at Shell Mex & B. P., Hemel Hempstead, between 1965 and 1967 laid the foundations for the CODIL research project and it is worth examining what happened in detail, both in connection with CODIL, but also as an opportunity to put on record what computing was like at the time in a major commercial data processing centre.

The detailed account is below the fold – but please feel free to make comments or ask questions.

My First Few Days in Computing

My move to the company was almost accidental. I was working as an information scientist (no computers in those days) at the Cooper Technical Bureau, Berkhamstead. I had seen Vannevar Bush's article “As we may think” and asked for a transfer to the company's computer department as I saw it as the future in information work. They decided that as I had a Ph.D. they could not afford to employ me in the computer department. A few days later a junior colleague (without a university degree) gave in their notice to take the post of librarian, at a higher salary than I was getting, at the new computer centre a few miles away. That night I saw, and replied to, an advert for “Punch Girls to Systems Analysts” in the local weekly newspaper.

My first day working at Shell Mex & B.P. (SMBP) was chaos – and an important lesson. The computers used magnetic tape for storage and all customer records were held on printed cards (perhaps a million of them). Over the previous weekend the company changed its internal reporting structure. This meant reprinting every customer reference card, and to make this possible virtually every LEO III in existence was used for a massive print job. At eight o'clock on Monday morning the dozens of punch girls started to punch up, on paper tape, the information on the delivery notes that had arrived in the post. Shortly afterwards the printers were busy – printing out reports on sales to customers who “did not exist”. Shortly after I arrived at nine o'clock there was a call for every available hand to the customer records – and I spent the first few days helping to find the old record cards and manually transferring the information they contained to coding sheets, to be used in updating the mater magnetic tapes.

I gathered that about 30,000 customer records were lost including most of the railway stations which happened to be delivery sites but where the bills were paid centrally. The problem was because (1) many salesmen had not understood how to fill in forms used in the reorganisation, (2) the failure of those in charge of the operation to anticipate such errors, and (3) a failure at the systems level to check whether a customer was, or was not, an active delivery site before it was deleted.

The next week there was a programming course in the CLEO (Clear Language for Expressing Orders). CLEO was specially designed for the LEO computers and was (as I later learn) a combination of features from COBOL and Algol. The group I was in was the first at SMBP to learn CLEO as their first language – as up to this point nearly all programs had been written in Intercode, the symbolic assembly language that I later learnt. Learning a high level language first proved a significant advantage and it was not long before I was looked upon as the CLEO guru.

Reporting Sales to Garages

My first programming job was with a small team who were to write the programs needed to produce the monthly sales reports for garages selling Shell, BP, and/or National Benzole petrol. I was given the master update program – and for those not familiar with computing over 45 years ago it is worth saying a little about how it worked.

The master file contained a number of records for each customer. There were three types of records – a header record containing details of the customer, a petrol sales record, and an other oil products record. If I remember correctly each of these records could double up if more than one brand (Shell, B,P, and National Benzole) were involved. The total number of records on the master tape were about 100,000, split up over 5 magnetic tapes for five geographical regions.

Each month the sales accounting suite of programs would produce a magnetic tape of sales to garages in customer number order. There was a separate magnetic tape of descriptions of all the petrol filling stations in the country, also in customer number order. In addition there were 5 input tapes (one for each sales region) containing sales to date and targets, and 5 new output tapes containing the updated sales, together with any new/changed information from the tape containing the descriptions. As the targets were based on the previous year's sales the first live run involved running 12 months from the previous year and then several months of the current year, followed by printing out the sales reports. – which required about 100 hours of computer time.

Once I had produced a monthly summary tape a number of other programs (written by other members of the team), produced a variety of monthly and when appropriate annual sales reports for individual salesmen and head office.

When I was writing the program I noticed several possible holes in the specification and was assured by the systems analyst responsible that we would never get sales to customers who were not recorded on the garage site records. I added a check just in case and in the first small scale run with live data my program produced about 1000 error messages. However the first real test was the big run needed to set up the tapes and generate a year's worth of targets. The aim was to circulate the sales reports to the staff that would have to use them and ask them to check for any errors. I was well aware that the test data we had used to debug the various programs was pretty limited and I was expecting a large number of problems to be reported.

In fact only two fault reports came in. One came from an individual salesman and related to the incorrect reporting of sales of lubricating oils to one customer in one particular month. The other came from head office to say they they did not believe that sales of one particular product were 17% above the expected level. In both cases my coding errors were easy to identify and quickly corrected – except that the 100 hundred hour set up run had to be repeated.

The big lesson, as far as I was concerned, was that while there were only two reports the nature of the program bugs meant that several hundred people had been sent incorrect sales summaries and had failed to notice any errors. I have always wondered how many other faults had been missed,

In fact I found the whole process of programming rather dull. You worked out what coding needed to be changes, and any additional trial data needed to test the changes. This was all written on coding sheets which were sent to the data prep room where a bevy of women punched the code onto paper tape. This would then join a queue for the computer, and it would be several hours before you knew whether your changes had worked. To pass the time I found out as much as I could about the CLEO language and became an unofficial expert in it. I also learnt Intercode and designed and implemented an audit package for the sales reporting suite to help debugging runs when dealing with live data.

The Sales Reconciliation Program

My final program was designed to solve a major problem with the way sales were reported throughout the company. Details of everything that was sold was recorded and input into the sales suite of programs and at the end of a month a master sales tape was produced to send out monthly statement for the customers. In addition each management team extracted the data they wanted for their monthly reports. The problem was that different teams extracted data using different criteria. One team might decide it wanted a report on a particular product group while another asked for reports of all sales by its salesmen. This led to misunderstandings. For instance there had been a problem with who was responsible for a discount for the sales of domestic heating oil for the directors of companies which were major buyers of industrial products. There was also the question of whether the sales of aviation fuel for hovercraft should be considered part of the aviation or the marine markets.

The specification for the program arrived assuming it would be written as a spaghetti-like mass of logic statements (which was common at the time). I pointed out that it would be almost impossible to produce a bug-free program because of the problems of generating appropriate test data. I suggested an alternative table driven approach which was accepted. It was important that the tables were correct so I divided the program into two parts – one did the “real” work of reading the magnetic tapes, updating the records so that they all contained a special sales category code, and reporting any rogue sales which did not conform to the accounting rules laid down by Head Office. The second part of the program was initially loaded into the magnetic tape buffer areas so it could later be overwritten when its job was done.

An aside is appropriate here. Because we were working on magnetic tapes, with no direct access storage devices, all “low volume” data had to be held within the program, on a machine with limited memory, and where using the magnetic tape drives efficiently was important.

The idea was to minimise the possibility of programming errors. When the program was loaded it took data embedded in the code, and restructured it into about half a dozen tables. While doing this it checked the tables for logical consistency and also (optionally) printed out the “program specification” at the application level. Once the table pre-processing had been completed the computer memory for the pre-processing code was reallocated as the magnetic tape buffers and processing the live data tapes could begin. This approach meant that when the specification changed the systems analyst responsible could mark the changes he required on the listing – and then check the result after the programmer had modified the program tape. As far as I can gather no-one else at the data centre had written a program which verified its own “code” in this way, and printed out the specification it was actually working to!

What Should I do Next?

I had joined SMBP wanting to move towards systems analysis, and I started to agitate for such a move. My interests was in help people to handle real world data – and as far as I was concerned the computer was just a tool. They were in the process of re-organising the programming teams and there was a mix-up which annoyed me. As a result I approached English ElectricLeo Marconi (EELM) about a post that was advertised and they said there was a non-poaching agreement and they would only consider me if I told my employer – which I did. The problem was that I was seen as an excellent programmer who could really dig deep into the system. [Well you had to do something to avoid the tedium of routine programming was how I saw it.] They clearly wanted me to stay and offered me a immediate transfer to work for the former chief programmer – who was to be in charge of the operating system requirement of the new system that they were planning to install a year of so in the future. I was horrified with a move closer to the machine and made it clear that I was not interested in going that way, Within days they moved me to look at how the current pricing programs handled contracts, etc., in anticipation of a move to the the use of significant direct access storage (perhaps as much as half a gigabyte!!!) and online terminals.

The Sales Contract Study

In one sense I was thrown into the deep end. I had little more than a year's experience of programming, and no systems analysis training. The sales accounting programs run on the Leo III computers at SMBP were probably the most complex in the UK (and possibly the world) at the time. I had no experience of driving a computer from even a very simple terminal – but neither did any of my immediate colleagues. But perhaps my naivety meant that I had the advantage that I didn't know what was generally believed to be difficult and so approached the task with an open mind.

On the positive side I had worked proving high level exception reporting in a complex manual management information system and had been brought up in a commercial environment so knew more than many of my colleagues as to how the retail market worked.

Much of my study involved information from three sources.

1. The manuals – both the systems manuals and the operational manual for the staff which were involved in running the system. I soon found these contained many gaps and inconsistencies.
2. The program listing. The program was so big that it was difficult to run it in the maximum available computer configuration – and it was very difficult to relate the code to the specifications due to the need to write very compact code. Despite this there were island of dead code – that could never be reached – or which could lead to incorrect results if entered.
3. The staff responsible for maintaining the customer contract files, including access to effectively random sample contract listings. It was clear that the staff were having difficulties with the current system.

At the high level I quickly came to the conclusion that it was virtually impossible to define a single conventional system specification which covered the whole of the company business, in a way that had the management in control, and which could respond quickly to changing markets. The current system might have been a monumental effort to construct, and may well have been cost effective, but it left a hell of a lot to be desired. Perhaps because of my training in theoretical chemistry I took it for granted that if one model didn't work well you simply look for a more appropriate model. In retrospect I am certain that my manager never expected me to take this approach and was planning “more of the same” only on a bigger scale.

At a more down to earth level I sampled the work of several of the contract clerks by collecting the discarded printed customer records after they had been updated, the change having been written on the old record sheet. I then tried to reconcile what was on the cards with the manuals and raised any queries with the clerk concerned about the reasons for the change. I developed a simple notation for my working notes and the clerks commented on how much easier it was to understand my notes than it was to read the existing customer record cards.

I simply put the two ideas together. What was needed was an contracts writing language which the sales staff could understand which would be directly interpretable on the computer. This needed to be done quickly and efficiently (I was thinking how it might be programmed on a Leo III). So I drafted an outline proposal – of which I unfortunately have no record. However the underlying philosophy related back to the self-documenting table look-up program I have been working on a few months earlier, and can be represented in the following thought experiment.

• Think of a global array which contains one column for each variable that might be need to included in any sales contract line – whether it be for an individual customer or a group of customers, or for an individual product or group of products. Then fill the array with all the contract lines – leaving irrelevant columns empty.
• The result is an sparse array – as most variables only apply to a few specific areas of the business – so compress the array by tagging the values with the name of their variables and discard the empty entries. The result (if any numeric code compression is expanded) ended up looking like the notation the clerks had said they liked.
• Now distribute the compressed lines in the data base. Contract lines which apply to a single customer will go on that customer record. Contract lines which apply to many customers will be held on a file holding shared contracts. Contract lines which related to single products or groups of products would be handled in a similar way, and there might be a few lines which applied to all sales.
• The pricing program would in effect play two roles. When details of the sale of a particular product to a particular customer came in it would do a look up in the indexed data base for the relevant contract lines. It would then interpret the contract lines it found as it it was program code to generate the price to be charged. This is not as strange as it seems because contracts, price lists, etc. are in fact rules to identify the factors to be considered when selling,

From the point of view of the sales staff the computer would hold the contract information in a way that they could both understand and update on a computer terminal. In addition they could ask the system to, for instance, show what contract lines would be used to price a particular sale on a particular date. If a particular sales promotion required a different contract the sales staff simply wrote the new contract lines on the relevant part of the data base and only needed help from the systems team if they needed a new “variable” to describe what they were doing. Basically I was putting the sales management in control.

From the point of view of the systems and programmers they were no longer concerned with how individual contracts were structured. Where the contract could be described in terms of existing “variables” its structure was in the data base – and the responsibility of the sales staff. Once the basic interpreter mechanism had been constructed there would be little left to do. The need for virtually all the “if ... then ... else ...” type logical statements relating to the contracts that had formed the bulk of the old programs were no longer necessary, and there was no need for the associated documentation – because the information could be obtained at any time by interrogating the data base. This would also greatly reduce the size of the programs, the data compression (compared with fixed format records) would mean the data base would probably be smaller, and it turned out that the number of “variables” needed was remarkably small. This should make the technical support aspects of the application much cheaper.

So What Happened Next?

My first report simply defined the program structure I was proposing, without highlighting the supposed advantages and I was surprised to get a negative reaction from my boss. Part of the problem was that I had absolutely no idea I was suggesting anything out of the ordinary. Before entering the computer world I had worked providing information for management (admittedly in a very different field) and the approach I suggested to improve the way information was transferred both ways between management and a computer seemed very natural to me.

So I went away and drafted a second report which highlighted the advantages – and was firmly told that my proposals were research – we have a real job to do. My reaction was simply, you can't win them all, and that might have been the end of the matter.

At about this time SMBP made the decision to replace their Leo III computers with Univac Systems, and I decided to join EELM, who had lost out on the contract. However one of my SMBP colleagues liked my ideas and while I worked out my notice we had some detailed discussions about some aspects of the approach could be modified to look “conventional.” I believe that after I left this was accepted and was at the heart of the “Variants” approach used by BP for their sales contract programs some 10 years later. (Unfortunately I don't have sufficient information as to how the BP approach works to know how far my proposals influenced the design.)

I started working for EELM in 1967, weeks before they moved offices from Victoria to Computer House, near Euston, to work with George Stern on assessing future computer requirements for large computer systems – with my unacceptable proposals (I thought) left firmly behind at SMBP. Of course it didn't work out that way, and the details will form a section of a later “chapter” but by early 1968 the DORIS (Data ORriented Information System) was born (later to be renamed CODIL – Context Dependent Information Language) and hardware patents were being taken out. I was told very firmly to keep all aspects of the study confidential (even within EELM – where I was still working in the same open planned room as salesmen) and of course I was to do nothing to alert SMBP that computer pioneers such as David Caminer and John Pinkerton thought that there might be significant commercial potential in my proposals.

There are two follow up points worth mentioning.

• SMBP renegotiated their Leo III contract to shorten the period that they would be using them – and then faced significant delays in implementing their Univac system – which meant keeping the Leo IIIs longer than planned. When ICL was formed the salesman at the next desk to me moved out and emptied a draw of their filing cabinet into my waste paper basket. On top of the pile was the SMBP invitation to tender. I had a good read – and it was obvious to me , with my knowledge of the Leo system,  that the specification had seriously under-estimated some of the figures relating to the likely size of the customer data base!
• On of the problems I had with my proposals boils down to terminology. Had I come up with a similar design 20 years later I would have been able to say I was proposing and object oriented expert system, with a user-friendly control language, which was designed to process a distributed set of about one million production rules in the systems knowledge base.