By: Larry Walker, May 2023; Context: Sperry Knowledge Systems Center.
Because of its success in the global airline reservation systems market, in the early 1970s Univac established the International Research & Development Center in London. At that time Univac had ⅓ of the global airline reservation market while IBM had the remaining ⅔. In the US, Univac had United, Northwest, and Eastern. Globally, Univac had SAS, BEA, Lufthansa, AirFrance, Iberia, Trans Australia, and Air India.
Each of these client projects had been done independently, so Univac thought it would be good to gather manpower from each of these projects and build the best high volume transaction processing operating system ever. Ed Mack who had pioneered online reservations at Eastern Airlines headed up the new development center. His right hand man was Brian O’heron, a well-known troubleshooter for large scale projects. Ed was a genius software designer while Brian was a hard nosed project manager.
The other attraction was the idea that locating a major software development center in the UK would give Univac access to a significant pool of strong software programmers. This combination of imported Univac talent and domestic UK talent provided a substantial foundation for software development.
Larry Walker was invited to join this group after the United Airlines project was terminated. Larry, Judy, and their 4 kids arrived in London in August of 1975. Initially, they stayed in the Royal Lancaster Hotel, a small hotel near the IRDC location which was two blocks from the Paddington Railroad Station. On weekends, they would take trains west of London looking for more permanent living accommodations.
The third weekend, they landed in Henley-on-Thames, and fell in love with it from the moment they left the train. Eight blocks further on, the came across a house they liked – and – ended up buying.
Henley is a small picturesque village of 15,000 people nestled on the Thames River in the midst of the Green Belt which Henry VIII established in about the year 1500 – and – the green belt is still honored to this day. Its main point is that the towns and villages that lie within it are not able to acquire more land from the farms surrounding them.
The IRDC was a very disciplined software development group. Implementation was done in a high level language, just slightly higher level than Assembly Language. Larry was brought in as a Supervisor, so never did hands on-coding at the IRDC.
Early on, the IRDC established a rule that programmers could only develop code in 250 instruction chunks. Each chunk would then be integrated into the existing system, followed by first a unit test to determine that the chunk did what it was supposed to do; then by a system test to ensure that the new chunk had not interfered with proper system operations.
When this rule was first introduced, they found that it could take as long as 3 days to perform the 3 steps: integration, unit test, and system test. Some years later when they introduced the finished operating system to its first client, they were able to perform those 3 steps 24 times in a 24-hour day – at the client site!
This operating system, the Real Time Operating System, RTOS, was committed to high volume transaction processing. From the beginning, the goal was to achieve 110,000 transactions per hour. To ensure meeting this goal, Ed Mack introduced the concept of ‘performance budgeting’. Performance budgeting was based on a well-defined standard transaction which was judged to be typical of every airline reservation system.
The number of instructions needed to perform this standard transaction had to meet the goal of 110,000 transactions per hour. Each portion of the transaction processing path was then given a budget that it had to meet. If one programmer could not meet his/her target, he/she had to negotiate with the other programmers to find relief.
Ed introduced an interesting concept to guide the overall performance. He defined the idea that instructions fell into one of three possible categories: gold, silver, or bronze. Gold instructions occurred in those portions of the system that were involved multiple times with any given transaction – the Switcher between activities was a major one of these. At Eastern Airlines, Ed had coded the switcher to take place with 24 instructions. Larry knew that the United Airlines switcher would take a minimum of 1,000 instructions – and in case of multiprocessing contests to get control, it could take immeasurably longer! No wonder they had performance issues at United.
One day at the IRDC, John Grogan went running in to see Ed Mack, very excited. “Ed,” he said, “I just got the switcher down to 23 instructions!” Ed was totally intrigued. “Show me,” he replied. John mapped the instructions on a black board while Ed studied what he had done. Finally, Ed asked, “What would you do if “x” occurred?”
John was momentarily stumped, but then he jumped up to the board, erased a couple of instructions and added a couple of more. “I hadn’t thought of that case,” he said, “but with these changes it is covered.”
Ed looked it over then said, “Yes, it is covered. Good job. But – you have added one more instruction, making it 24!” John had to agree.
Silver instructions were those that would occur once per transaction. They needed some attention but were not as critical as the gold instuctions. Bronze instructions were simply those that may not even occur in each transaction. These could basically be ignored – they would have little performance impact.
Once RTOS was complete enough to run volume tests, it hit 110,000 transactions/hour – meeting the committed goal. At that time in the history of software, performance was often a challenge, so the IRDC did very well in this regard.
Both Ed and Brian left the IRDC before the RTOS was finished, going to England’s ICL computer company which was struggling to find a place in the global computer industry.
Their departure left Larry in a position to primarily replace Ed and the lead designer and Brian as the project manager. Both these positions were a challenge – but, the project went to completion, meeting its performance goals and being successfully installed at two major clients: the national phone company of Spain and the internal domestic airline in Japan.
The IRDC (by then the London Development Center) people were ecstatic.
Then tragedy! The VP of the Roseville Software Development Group wrote a 3-page memo. It state that it was expensive for Univac to support two operating systems – and – within 3 years, his Exec 8 could match the performance of RTOS – an out and out impossibility! He was responsible for the vast majority of Univac customers, so his feeble memo won out, and RTOS was canceled!
Reflection
Later we found out that the entire computer industry was looking for a leading edge candidate to handle high volume communications and networking. RTOS was excellent and could readily have filled this role, but the London Center was never par of any of those meetings.