Origins of TPF: IBM’s Unknown Operating System

To really understand the origins and development of the system we now call TPF we must take a trip back in time to circa 1940. We will visit a main ticket office of American Airlines in Little Rock, Arkansas, a growing company with growing ambitions. Here the basic control of flight reservation was a large card index around which eight or so clerks would sort through the index cards for the flight being requested. They each knew the number of seats for the type of aircraft being used and by counting tally marks on the flight card they could tell if any seats were left and give you your ‘yes’ or ‘no’ over the telephone. If your reservation was being made through another office it might take 2 1/2 to 3 hours to reach the revolving card index via a teletypewriter network and some clerical personnel. In some of the medium sized offices it was necessary to use binoculars to view critical information posted on large availability status boards in the agents area. The absence of a red tag indicated that at least one seat was available on that flight. If more than one seat was needed a phone call to the back room might give you the availability which was again kept on three-by-five index cards according to flight number.

By 1955 some automation had begun to creep into larger offices and American’s first automatic equipment, the Magnetronic Reservisor, provided remote controls so that the agents could search a memory drum and determine whether or not seats were available. Now within a few seconds agents could check availabilities but the posting of the passengers name, telephone number and other information created a terrific paperwork headache. It was still necessary to record the passenger data on the ever present three-by-five cards and a constant river of paper still wound its way on conveyor belts to find its place in the back room.

For every agent on the telephone another was required in the back to do the housekeeping. It was a system and it worked but as it grew adding another clerk no longer was the answer and American’s management was constantly aware of the need for a complete change in the concept to handle an ever increasing volume of flights and passengers. New solutions were found but never a total system capable of keeping pace with the service that was gobbling up transportation time and reducing days to hours and hours to minutes.

If ever there was a problem crying out for a computer solution it was this one but it took one of those strange quirks of fate to get the whole thing off the ground (no pun intended). The story goes that American Airlines’ then President, Cyrus Rowlett ‘C.R.’ Smith, a giant in North American commercial aviation history, had the occasion to be seated next to an IBM Sales and Marketing Representative called, coincidentally, Blair Smith. It is not clear whether the two were actually on an airplane at the time but it makes the story somewhat better if we assume they were… Anyway the two fell into conversation after learning of the matching surnames and common interest brought the talk round to some way of solving American’s problems. C.R. Smith outlined the airline’s needs and Blair Smith went his way promising to follow the matter up. It was a mere 30 days later that IBM responded to American with a proposal to make a study of the airline’s problems and it was 1957 by the time the direction was firmed up and formal agreements reached.

American Airlines appointed technical and functional representatives to work with an IBM staff of 75 and the SABER (Semi Automatic Business Environment Research) project was born. In March of 1959 the initial program was proposed and one AA executive commented years later “It was the best damn research and development effort on the part of any company I’ve ever seen.” It was much more than a survey of one company’s or even an industry’s needs; it was an entirely new concept which, it is said, spawned IBM’s 360 computer systems.

The SABER name was later changed to the name more familiar to us today: SABRE. The system was actually implemented in 1962 and reportedly cost $30 million. Initially the hardware it ran on was an IBM 7090 processor, a second generation computer using disk files and specialized terminals developed for the airline reservation function. Also developed during this project were some innovations in communications technology, namely the concepts of line concentration and of medium and low speed data sets. Also the use of a front-end-processor, development and improvement of large capacity rotating storage media (disk drives), fast direct access techniques for data stored on disk drives and the techniques of writing relocatable and reentrant code. Most of these technical points will be discussed in the later posts but it should already be clear that the need for a fast computer system for the specific problems that faced the airline industry also contributed to the development of many of the features we take for granted in our computers today.

Two other systems which built on the experience gained in the SABER project were also developed in conjunction with IBM. One was the Deltamatic system for Delta Airlines using IBM 7074 processors when it was implemented and the other was Panamac, developed with Pan-American Airlines using IBM 7080 processors. Both of these systems were implemented in 1963 and the only fundamental differences were in their respective sizes. This was important because since much of the system code at the time had to be hardware specific this meant that although the systems were based on the same design there were some significant differences in the code within them.

In 1964 IBM made two important announcements. One, which is probably more widely regarded as important, was the introduction of the System/360 (S/360) line of computers and the other was the start of the development of PARS (Programmed Airline Reservation System). Based on their experiences with the three airline systems and the development of the S/360 concepts IBM endeavoured to design and develop a separate operating system which could function on any of the S/360 machines from the Model 40 to the Model 75. This operating system would be similar to the systems developed for the airlines but would separate the ‘application’ processing (booking seats, availability etc) from the ‘system’ functions like accessing the database and restarting the system. By 1968 IBM had developed PARS and released it as a product. At this stage there was still no separation of function between Applications and Systems software but now a general package was available to all the other airlines to use on whatever type of IBM S/360 machine they chose (so long as it was Model 40 – Model 75!?).

It was not until 1969 that IBM managed to pry apart the previously interwoven systems and applications portions of the PARS system. The Applications portion of the new package was christened APPS and the Systems portion became ACP (Airline Control Program) the forerunner of TPF. In keeping with the somewhat mysterious and arcane numbering schemes prevalent at IBM this first release of the ACP product was called Version 4 (?). Various other intermediate releases were brought out by IBM until the last numbered release of ACP, version 9.2.1, in February 1979. In December 1979 IBM changed the name of the product to ACP/TPF, TPF standing for Transaction Processing Facility (IBM Program Product number 5748-T11) and quickly began to eradicate the initials ‘ACP’ from all documentation.

This marked another turning point for the software, now it was IBM’s ‘official’ belief that applications other than the airlines could and would benefit from its use. To be fair it was probably more like the recognition that many other businesses were actually using ACP/TPF than a conscious decision on IBM’s part to market it that way. Already such companies as American Express, New York City Police, AVIS, GMAC, Federal Express, Western Bank Corporation, Bank of America and several consumer lending companies were ACP/TPF customers alongside the major airlines of the world. For a long time internal politics at IBM had prevented TPF from emerging as a possible ‘general purpose’ transaction processing option so as not to adversely affect IMS as the flagship product. In future posts we will explore some of the unique features that made ACP/TPF the fastest operating system on the planet for decades.