The SMBP Story

The Shell Mex & B. P. Story

An autobiographical account of my time working on LEO computers

by Chris Reynolds

 

Why Shell Mex and BP?

“How much did you say??!!!”

I was working in my office at the Cooper Technical Bureau in Berkhamsted in 1965, and Chantal, the young librarian, had just given in her notice and was going to work at the Shell Mex and BP Computer Centre in Berkhamsted at over £1000 a year. She had the equivalent of 3 A levels and I had a Ph.D. and she was going to earn more than I did, which was about £950 a year.

I was furious. I was employed as an Information Scientist and my job involved ensuring that the top management of this international organization was aware of any research and development news from the overseas branches. I had suggested I should learn about the possibility of using computers to help and had just been told I was being paid too much to transfer to the computer department. When I got home I picked up the local paper and saw an advert “Wanted punch girls to systems analysts.”

At the interview I explained that I wanted to learn about computers in order to use them to help management, and as I had no experience they offered me a job starting as a programmer at £1000 a year, and if I was any good I would transfer to systems analysis after six months.

My First Week working with computers

At the beginning of December 1965 I turned up at the computer centre at Hemel Hempstead and the first hour was pretty routine – getting the paperwork sorted out with the Personel Department. There was then a pause while they tried to find my new boss  - an apology – there was a problem and that would have to wait and I was asked to help out on the clerical floor.

The problem was at the weekend the company had updated its main customer contract files. The first computer job every day was to take the delivery notes relating to goods supplied the previous day and process them on the computer to generate invoices.  When the work started on Monday morning the computer started rejecting many of the sales because the customer to whom the goods had been sold did not exist.

What had happened was over the weekend Shell Mex and BP had reorganized its sales teams and the whole customer contracts file had been printed out on about a million records cards. To do this time had been purchased on almost every Leo III computer in the UK and my boss was one of the people who had been working over the weekend to supervise the printing process. The problem was that some customer records (I think about 10,000) had somehow got lost and I was just one of the people roped in to search through the old customer record cards for the missing customers. A new customer record form was created with the old customer details on and once this had been added to the customer contracts magnetic tape the sale could be processed.

In fact the computer program had worked “correctly.” The change in way the company worked meant that salesmen were organized by area rather than by product, and each salesman had submitted forms relating to all the customers that he was responsible for. The problem was that companies like British Rail had not been considered. All orders were placed by their offices in Swindon or Derby – but deliveries could be made to any railway station in the country. Large numbers of salesmen had not realized (or had not been told) that under the new arrangement they need to treat all railway stations that accepted deliveries as potential customers. At the systems level another mistake was that no checks had been made to check that there was a new salesman reference for all customers who had been recently been accepting regular deliveries.

There a long term effect of this crisis. The new cards needed a National Grid Number in anticipation of possible vehicle routing at later date, but this information was not on the old record card.  To get the new customer ecord accepted a number had to be supplied. This meant that when, about a year later, a vehicle routing program was written it was found that a considerable number of grid reference were wrong by a hundred miles or more!

Learning to Program in CLEO

Once the crisis had been resolved a small group of new intake, mainly school leavers, were given an introduction to the computer – starting with a visit to the large air-condition computer room (normally off-bounds) which contained two Leo III computers – and impressive rows of large magnetic tape decks, printers and paper tape readers. My group were the first new intake to be taught CLEO (Clear Language for Expressing Orders), a high level language designed for commercial applications which combined features of early COBOL and Algol. Previously virtually all programming in the company had been written in Intercode, a symbolic assembly language which was only one step up from machine code.

Our task was to write a program which recorded the results of cricket matches and calculated averages. The program was written on coding sheets which were then sent to the data preparation department to be punched onto paper tape, and there were delays of several hours before you got back a computer listing. However the course went well and by the beginning of January 1966 we were all allocated work to do on the programming floor.

The Retail Market Reporting Suite

I was one of a number of new programmers who were asked to write a suite of programs designed to produce monthly reports on sales to garages up and down the country. My job was to write the program which created and updated the master customer sales file that held the sales records and targets while the others were allocated to use the master sales file to produce monthly and annual sales reports.

The master sales file consisted of 5 reels of magnetic tape (one for each sales region). It was to be updated once a month and the inputs were the Dealer Site Record (mentioned by Bill Foster in the Spring 2018 Leo Computers Society Newsletter) and a tape containing the relevant monthly sales. The output was a new copy of the master file again on 5 reels of magnetic tape. For each dealer there was a header record, with information from the Dealer site record, at least one record for sales of petrol and diesel (separate records where the dealer sold more than on brand of petrol) and records for lubricating oils, etc.  For each product sold there was a sales target, but the master update program was not directly concerned with the setting of these targets.

As soon as I got the systems specification I spotted a problem. The specification clearly stated what should happen – but my first days with the company were clear evidence that things didn’t always go as planned. “What happens if we get a sales record for a customer which does not have a Dealer Site Record?” I asked. It can’t happen I was told because there is a record of every garage in the country whether they are customer or not. I wasn’t happy about this so I added a series of traps to catch problems which I was told couldn’t happen. As it turned out I was right. When the first test  run with live data was carried out my program generated about 30,000 sets of customer sales and also spewed out perhaps 500 reports of sales to garages which “did not exist!”  It was a case of the messy real world doing something the systems analyst had not anticipated. For example a small car repair shop, which didn’t normally sell our products, had a customer in for servicing who wanted the engine filled with one of our oils. What happened. The repair shop phoned our nearest depot and places an order – and to allow the order to be billed the depot allocates a customer number. The local salesman, who is responsible for keeping the Dealer Site Record up to date, was not involved so the relevant magnetic tape was not updated.

Developing a Support Package

After a couple of months I was finding the process of writing and testing programs boring – and one of the problems was the delay in completing a coding sheet and getting the results back from the computer. I needed something to keep my mind busy and because I was interested in making sure programs worked correctly I started work on a diagnostic support package which could be used to interrogate the master dealer sales file and to report on what changed. This not only proved to be a valuable testing tools but also gave me the opportunity to try out areas of the CLEO programming language which I had not used before. In addition I was quite happy to help other programmers track down problems with their programs and I soon became an unofficial expect in using the CLEO language.

The First Live Run of the Supporting Suite

The first live run of the Retail Marketing Suite was a major exercise. Targets were set month by month and were based on the previous month by month sales. The first full run with live data was in March or April 1966 and meant running the program month by month for the whole of 1965, then running a year end program (not my responsibility) to generate the seasonally adjusted targets for 1966. The next stage was to run the program for January to March 1966 and then run a number of different programs that printed out salesmen copies of the sales for their customers, and higher level summary reports for more senior management.  Much of this would be dominated by the time loading, reading and writing magnetic tapes, and finally printing large numbers of reports. The complete test run was planned to take up to 4 days of Leo 326 time. It was expected that some problems would emerge and once corrected the first operational run would repeat the process a month later.

The programming team waited, wondering how many faults the sales staff would find and the process revealed two faults in my program. If a garage brought one particular brand of lubricating oil the amount recorded as being purchased was obviously too high – and the error was due to an incorrect use of “OR” in a single “IF” statement. In addition Head Office pointed out that the total sales relating to sales under one heading were 17% above what the actual sales were known to be. This turn out to be a fault which affected the minority of garages which sold more than on brand of motor fuel. Neither of these faults could have been detected using the very limited trial data that had been supplied and were trivially simple to correct, so the following month the suite went live.

However, because I was very interested in reducing program errors I was very worried by the result. The first run had sent out reports to a large number of sales staff in the organization, who had been asked to check the documents’ accuracy. These two errors should both have generated a large number of reports – but each was only reported once. It was clear to me that at least 95% of the sales staff involved has accepted as correct printouts which contained errors.

Developing a Self-documenting Program

My next major task addressed a long standing problem connected with reporting sales. The original sales program was designed in such a way that if goods were sold someone was expected to pay for them. While most sales were a routine matter of supplying the goods and sending out an invoice there were some special cases. For accounting purposes these extra sales could even include a depot selling off redundant equipment for cash. Each day details of all the sales would be added to tapes which contained details of all the sales for the current month. Each department then commissioned the computer department to produce summary sales reports – and this include the reporting program I had been working on.

So what was the catch. The example which highlighted the need for change involved central heating oil. The industrial market had an arrangement which arranged a tax-free perk for their customer’s senior managers of say 30% (I don’t remember the actual sum) off the cost of central heating fuel. This was agreed by the domestic market that supplied central heating fuel and everything seemed to work well. The monthly reports for the industrial market covered all sales organized by their salesmen and showed the 30% discount. The domestic market reports were based on all sales of domestic products and also showed the 30% discount. OK there was double reporting but no-one was too worried until it was found that the two discount totals were not the same – and the customers were actually getting a double discount of 60%.  It turned out that there were other cases where a salesman sold products normally sold by a different division the sales were either double reported or never reported at all.

A systems analyst came to have a discussion with me before drawing up the specification and I warned of very severe difficulties in testing if the program was written in the “normal way” (which would be now considered bad programming by today’s programmers who have access to far more sophisticated tool and program libraries). The resulting program broke completely new ground within the company. The result was a table-driven program, written in Intercode, which started by testing that the tables were lpgically consistent. If no problems were found there was an option use the tables to generate and print out the program’s own specification as it had been implemented. The logic testing and print section of the code was then “deleted” using machine code (to save computer memory), the current sales tape(s) were read and each sale was allocated with a company division for reporting purposes. This approach meant that once the process was started any system updates could be made by writing amendments of the current computer produced specification which could then be directly compared with the revised specification generated by the updated version of the program.

[One point needs clarification here. Because the Leo326 computers were batch machines using magnetic tape as storage the tables had to be set up as constants in the program. On a more modern system with direct access storage the tables would have been separate data base files maintained using data base software.]

Some other Problems

The above examples all describe programming problems where I was directly involved – but I was very interested in any matters that could lead to programs that did not work as the sales force expected.

Some of the problems were due to the fact that senior managers often had little understanding of how computers worked. At one stage a request came down that for certain reports the infinity symbol should be used where appropriate. When it was pointed out that the printers did not have an infinity sign the request came back that we should use an “8” on its side – as clearly the requester had no idea how the printers worked.

Ignorance at this level worked in both directions. One day a salesman who had health problems came to Hemel Hempstead to see if he might be retrained as a programmer. At lunch he was surrounded with a group of young programmers (probably all recruited directly after leaving school) asking him questions about his job as a salesman – and it was very clear that most programmers had very little idea of what salesmen in a large organization did. (I was lucky as I was brought up “under the counter” in a retail shop, and remember the salesmen coming into the shop trying to get my father to stock the products they were selling.)

There were other incidents where things went wrong because the system specification failed to allow for some real world complication. For instance a friend of mine was a jobbing builder and he complained that for several years Shell Mex and B P had sent a monthly statement saying they owe him £26 – but they refused to give him the money. The situation arose because in his work he used liquid propane gas, which was supplied in cylinders.  He started with a regular contract and normally collected new cylinders of gas from the depot. However when he was working as a subcontractor on a major contract it might be more convenient to get a full cylinder from the main contractor’s store and pay cash.  After a year of so he decided to end his contract with Shell Mex & BP and returned more empty cylinders than he had brought from the depot. The computer programs had not anticipated any customer returning more cylinders than they had purchased and the £26 was excess deposit money. As there was no mechanism to pay the money the computer could have ended up sending out “We owe you …” monthly statements indefinitely, infuriating the former customer who wanted his money back.

By this time I was developing a deep understanding of why computer systems might fail to produce a satisfactory service, and these thoughts were very relevant to what happened later.

Time for a Move to Systems?

When I joined Shell Mex & BP the general plan was that I should move to systems once I had learnt how to program. Time was slipping by and I was still programming. I made it clear that I would like to know about the move but nothing happened – and I am sure the reason was that the standard of my programming was such the programming department didn’t want to lose me.  I let them know that if I was not moved I would be looking for a new employer and at the end of 1966 I moved to systems

The Sales Contracts Program

My new task related to the move to a new generation of computers at Hemel Hempstead. The biggest and most complex program running on the LEO 326s was the one that used sales contract information to price the goods that had been delivered. My job was to look at the current system and identify problem areas so that work could start on the move once it was known which new generation computer had been chosen. The most significant change was that the customer master file would be held on direct access storage, rather than magnetic tape and it might also be possible for the appropriate sales staff to access it via computer terminals. It was also extremely likely that the new computer would not be able to run programs written in Intercode – which suggested that significant reprogramming would be needed.

My investigation involved looking in detail in four areas relating to the current system. These were the program code itself, the associated systems documentation, the clerical handbook and random samples of actual customer contracts as held on the existing system.

The existing program was entirely written in Intercode and was so big that the LEO operating system had been modified to allow the program to expand. It had already reached the stage where further amendments were difficult because of the lack of space. The program was a tangled network of conditional clauses and was poorly commented, so it was virtually impossible to find out how a particular contract was processed by following through the code step by step. Despite the pressure on the program size I found at least two areas of code which could never be executed. This highlighted a problem. When code had been added to a program to service a special contract or sales promotion there was no simple way of removing the code when it was no longer needed. Another problem related to pricing tables, etc., which were coded into the program but which, if direct access storage was available would be better held a file in the new computer’s data base.

The systems documentation turned out not to be up to date and its limitations were not investigated in detail. However it was clear that it would be difficult from the tangled code and the poor documentation to simply rewrite the application in a different programming language.

The clerical handbook was full of special codes to identify different contract types, and I gathered it took months for a new clerk to become proficient. Because of the problems of tracing pathways through the program’s tangled code it was hard to verify that the handbook accurately reflected what the program did.

The existing customer records consisted of a fixed section containing the address and various codes and a variable length table which contained the contract information as coded. For instance special allowance code “29” might refer to the pricing of deliveries of fuel oil to a power station by coastal tanker. The customer contract records were printed out on about a million cards and when a request for a contract change came through the clerk would mark the change on the existing car and prepare an update form for the computer. When the new card came back from the computer it was checked against the old annotated card – and if correct the old card was discarded. To get a “random” sample of customer contract records I simply collected the old cards – as each discarded card represented a customer who was actively buying and whose contract had changed – so I could compare the before and after contract. I would then use the clerical handbook to relate the change to the variables used in the program. Where there was any ambiguity I would discuss the contract with the clerk responsible.

Back to First principles

Analyzing the problem was one thing – and coming up with a possible solution was something different. The computing scene was changing very fast. I now believe that no-one had successfully moved such a large and complicated commercial program, written in assembler code from a magnetic tape based batch system to a computer with significant direct access storage and where programs would normally be written in a high level language.

The problem of moving from a magnetic tape system to a direct access system was conceptually reasonably straight forward, as the data records could be identical – and it was the mode of accessing them that changed. The problem of interfacing a user, rather than a computer professional, was an unexplored field.

As far as using some terminals was concerned there were no available guidelines in 1967. From the beginning of computing revolution teletypes had been used as operator terminals, and during the 1960s there had been some work on military and other real time control systems (often veiled in secrecy) which involved specially designed keyboards or control panels. There was no published guidelines and very few of the papers being published in the Computer Journal even touched the subject of how to interface humans with computers. For instance in 1966 the paper  A Simple Program for use in the “Conversational Mode” described a test package that suggested that interacting via terminals might be useful. The following year Maurice Wilkes of Cambridge University published a paper called The design of multiple access computer systems which was really concerned with the software and hardware support problems. In 1969 there was a paper describing a system which allowed programmers to amend and compile programs from terminals – but the resulting compilation listings would be printed offline.

The first paper in the Computer Journal to describe the use of computer terminals in a commercial context described an aid to inputting and correcting data was published in 1969. This was the same year that the first commercial “glass teletypes” became available – providing a scrolling text screen typically 80 characters wide and about 25 lines high. By 1970 everyone started showing an interest. Xerox Parc (whose research to the invention of the computer mouse and windows software) was founded in 1970, as was HUSAT (Human Science and Advanced Technology Centre) in the UK. The first big international Conference on man-computer interaction was held at Teddington the same year. The first significant book on the subject, James Martin’s Design of Man-Computer Dialogues was not published until 1973 and was clearly concerned with the design of forms to help people input data to predefined computer programs.

So it is obvious that in thinking about how to interface sales staff with sales contracts on the proposed new system I had to go back to first principals as there was no significant earlier work for me to follow. The fact that I had spent virtually all my life in the pre-computer age, had learnt about constructing and using mathematical models doing a Ph.D. in theoretical organic chemistry, and worked for several years in a complex manual management information system clearly influenced how I looked at the task. The reason I was first attracted to computer was contact with the ideas of Vannevar Bush in his 1946 article As we may think (although I don’t think I read the original paper till a couple of years later). Vannevar had written how technology was advancing and introduced the idea of “memex” - which we might now see as a powerful computer where people pooled knowledge to be held in a vast encyclopedia of knowledge – in effect predicting something like today’s Wikipedia. My year spent programming had taught me a lot about why computer systems failed and the limitation in the way programs were designed and written. The fact that I had also designed and implemented a self-documenting table based program was also relevant.

What should the new system do?

At the time my first brief was to survey the existing system, and identify possible problem areas – and I didn’t specifically set out with a preferred solution. I didn’t record my ideas step by step and so the following is, in part, a reconstruction of how my ideas developed, with the advantage of hindsight based on the factors

Because of my experience in working in a management information system dealing with matters which could, in the long term, affect the company’s profitability, I took a global view in which the sales contracts system was an essential part of the company’s activities. The market place was part of the complex real world where things were always changing and so the contracts system had to be able to change . Nearly all of the problems I had seen with the existing computer systems were due either to misunderstandings or errors in the initial definition of requirements, or later modifications due to changes in what was required. Any solution must reduce such problems – and must also make them far easier to spot if mistakes are made.

Zooming in – the job of the sales staff is to negotiate contracts and make sales in a complex market where things are always happening in ways that are difficult to predict. Before computers there were clerical staff who had, in precise detail, accurately priced the goods sold. This worked because the sales staff, working in a complex real world, used the same contracts language as the clerical staff, and if there was a problem the clerical staff could always explain to the sale staff how any particular contract had been worked out. In my eyes the problem with the existing computer system was that the language used to describe contracts by the sales staff was a thousand miles away from the instruction language used by the computer. As a result, errors were easy to make and hard to detect, changes in the complex real world requirements were hard to make and time consuming, and the sales staff had very little understanding of how the computer program worked. If the resulting prices looked reasonable they were likely to be assumed to be correct. One possible solution was surely to produce a contracts program which understood the sales staff’s contract language, and which, if asked, could show them step by step how the calculations were carried out. (if this seems an impossible dream, remember that this was 1967 and there was no one to tell me I was “attempting the impossible” …)

Zooming in further there was the problem of the terminal. A teletype would print on a continuous roll of paper and any communications from the computer would appear line by line and scroll up and the drop down at the back. No more than perhaps a dozen lines would be visible at any one time so communications would need to be brief. (Later I also started considering the capacity of the human brain’s short term memory – but my experience in manual information systems would have suggested that any such human-computer communication system should have a comparatively narrow bandwidth.)

Zooming in still further I had to remember that while the new computer was promised to be faster and have more memory the existing system had quickly run out of spare capacity. I had no figures to work with so it would be sensible to start with the idea that the new program should be no bigger or slower than the existing LEO 326 program, and the individual customer records should be no bigger.

A Possible Solution Emerges

One of my tasks involved sampling customer contract records – unscrambling all the coding – and rewriting them in a more easy to understand form. All contract statements referred to a specific customer and a specific start date and my notes would have looked something like this:

·        Product Type - Petrol; Standard contract – Small Garage

·        Product – Antifreeze; Promotion – Summer purchase; Discount 25%

·        Product – Fuel Oil; Delivery – Coastal Tanker; Quantity >= 10,000 tons; Discount 3.7 %

I would then discuss my analysis with the sales clerk responsible for that customer contract to see if my analysis was correct. The reaction I got was “That’s much easier to understand than the coded forms we currently have to fill in.” I decided to look at what this would entail if each line of every contract was replaced by tagged fields – using data compression techniques to save space. The effect was surprising – the average length of a customer record would actually get smaller compared with the existing Leo-based system and it should not be too difficult to write a program to reformat the existing customer master file.

In addition all the standard contracts and pricing tables could be held in exactly the same format. This meant that all contract terms could be represented in the same way. The pricing program could now be considered as a very large indexed table containing over a million contract lines. When a sale was made the program would extract the lines that matched the customer, the product, the date, the quantity, and any other relevant variables and produce a tailored “mini-program” individually tailored to that particular sale. This mini-program would then be processed by an interpreter program to generate the price.

This table-driven approach had many advantages. The mini-programs could be displayed using the sales staff’s own language and would almost certainly be less than the dozen lines. So the relevant contract terms could easily be printed on a teletype, allowing the system to tell the sales staff the contract rules used to calculate any price on request.  As a result a draft proposal (which has not survived) was written suggesting the use of tagged field in this way.

What happened next

I prepared a short report on how my ideas might be implemented as a new sales contracts program and was asked to report back on the advantages of the approach. I was then told that the idea was really research and the new program would be specified and written in the same general way as the existing one, only using a high level language instead of a symbolic assembly language like Intercode. I was to go back to the drawing board and think again. As far as I was concerned I had come up with an interesting proposal which was not acceptable and that was that. By this time there were other systems analysts working alongside me, and one of them, Johnny Johnson I think his name was, was very interested in my ideas and I understand that some aspects of my suggestions were incorporated in the new system under the name of “Variants.”

At about the same time that my proposals were rejected in their original form a contract was signed and the new computer system was to be provided by Univac. The bid by English Electric Leo, who provided the Leo 326 computers, was rejected and the company had know that I had been restless about the delay in being moved from programming to systems analysis. Within weeks I got an offer to join them – and my reminiscences will continue in the next episode.

A Retrospective Assessment of the Contracts Program

In retrospect I had three problems in trying to “sell” my proposals to my employer.

The first related to the fact that the whole area was breaking on new ground (See Back to First Principles, above). This meant that there was no agreed vocabulary for describing the novel ideas. It is clear that if I had come up with similar proposals fifteen or twenty years later I could have sold my idea as an Interactive Object Oriented Expert System with a Human-friendly interface working on a Structured Knowledge Base of something over a million Production Rules – a description which used most of the key buzz words going around the industry at the time.

Another problem was that by the 1960s “everyone knew” that computers were mysterious black boxes controlled by very clever people and ordinary mortals, such as salesmen, could never understand how they worked. The argument that the way to overcome the problem was to design flexible systems which understood their human users was almost universally rejected as “impossible”.

Perhaps the biggest problem can best be described in terms of Complexity Theory (a discipline in its infancy in the 1960s) and formal Computer Science theory (about which I knew virtually nothing at the time).  My approach had to consider a system which sales staff working in a complex market place interacted with a computer system which helped them to use contracts to price sales. The existing Leo -based contracts program worked on the idea that the was a large pile of sales contracts and the program, and its data files should handle all the contracts rules in the pile of documents. My boss had clearly been expecting me to come up with a similar solution.

The difference between the two approaches is very significant because it highlights the difference between a complex system where unpredictable change may be expected, and a complicated but predictable system. In my suggestion contracts, pricing tables, etc., are reduced to a series of simple rules such as the three examples given earlier. These are held in a large structured data base of rules, and for each transactions a small number of relevant rules are selected to produce what is, in effect a simple individually tailored program for the particular transaction and simple enough for the sales staff to understand. If a new requirement comes along due to changes in the market new rules can be dynamically added by the sales staff without there being any chance of disrupting the existing arrangements.

The conventional programming approach effectively tried to combine all the rules into one vast pre-defined algorithm – which ended up producing a very complicated network of “IF … ELSE …” statements. The problem of specifying such an algorithm an expensive and complicated task with many opportunities for errors and misunderstandings. When real world changes mean that different types of contracts are needed, modifying the algorithm is neither a trivial or a quick task.