|
Like to see your
advert somewhere on the Alternative TPF Hompage
site ?
Disclaimer: The
Alternative TPF Homepage is not responsible for the content of external sites
| |
Origins and Development of TPF
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 cap`ble 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, 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 names 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 chapters 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,
develnped 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 becaure 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 endeavored
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 and
the details of their contents are listed in Appendix 1, 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
(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 (with the exception of Aeroflot, the
world's largest, although even they may become TPF users before
long, 'glasnost' strikes again...).
It will soon become clear as we explore the development of
TPF that an extraordinary amount of cooperation has taken place
between both the users of the software, amongst themselves, and
the users in concert with IBM. We have already seen how the
three pioneering systems at American Airlines, Pan-Am and Delta
were the product of a close working relationship with IBM and
this relationship has continued throughout the lifetime of TPF up
to the present day. Pan-Am, with its financial problems, has
dropped from the forefront of TPF development but American and
Delta remain, along with some other airlines, notably United (or
rather its computing off-shoot COVIA Corp) and Eastern (or rather
its computing off-shoot System One). In fact the habit of
cutting the computer division free as a separate company will be
visited again as we approach the present day in our historical
survey.
Many people who have only been introduced to computers after
the advent of the Personal Computer will probably have little
appreciation for the industry as it was when those first
PARS-like systems were created. Computer engineers were still
struggling with operating system code that was too closely
associated with the hardware that it was running on to be easily
moved to different machines. The quest for a solution to this
problem was one of the driving forces behind the System 360
concept. For the first time software that operated on one
machine in the 'family' would work, largely unmodified, on any
other machine in the same 'family'. The effect of this simple
standardization on the industry is hard to over emphasize. With
experienced computer engineers now free to spend their time
developing better systems rather than trying to rewrite the
existing ones to work on the latest machines progress was much
more rapid.
However, even today, there is a place for system code that
is sympathetic to the hardware and is able to take advantage of
every design feature for improved performance. Modern software
companies, particularly in the highly competitive PC marketplace,
employ experts on each type of computer that they want their
software to run on. These experts are charged with rewriting
certain routines that interface with the hardware to 'fit' the
actual target machine and obtain every last ounce of performance
benefit at the expense of portability of the code.
This was the situation in the early days (or rather
years...) of ACP/TPF. IBM supplied the source for the operating
system to its customers, which probably goes back to those days
when ACP was just a part of the PARS system that included the
applications that would need to be customized for the user's
requirements. Nowadays the idea that an operating system from
IBM would arrive, in its shrink wrap, with libraries of source
code included would have many an MVS programmer rolling up his
sleeves. This had two major effects on the development of the
product as a whole. First it helped maintain the close working
relationship between the users and IBM, since these users were
doing a splendid job of correcting the many mistakes to be found
in the early releases of the software. Second it had the negative
effect of encouraging customization to a degree which meant that
it would be highly unlikely that IBM would ever be able to ship
the system without the source in the future.
Another problem that would have faced IBM if they had
shipped ACP/TPF OCO (Object Code Only) would have been support in
the event of system problems. It is hard to imagine an airline,
dependent on its 24 hour reservation system for its very
existence, waiting for the local IBM System Engineer to resolve a
problem that has caused their system to crater at peak time on a
Monday morning. In fact the availability of the source has
proved mutually beneficial as I mentioned before and it has
certainly made the job of an ACP/TPF systems programmer one of
the more interesting to be had in the mainframe world.
The close observance of the characteristics of the hardware
that I mentioned earlier dogged ACP/TPF for more than 20 years.
Only with the announcement of TPF V2 R4 did IBM solidly declare
that TPF was a strategic operating system in their portfolio and
that since it was now able to use the XA Common I/O technique
support for new hardware from IBM would always be available in
TPF at the same time as in other mainline operating environments.
This announcement brought to an end more than two decades of the
leading TPF users having to often write their own software to
handle new devices that they wished to put on their systems to
cope with the explosive growth they were experiencing as the
world discovered air travel.
If you scan through the catalogue of highlights listed in
Appendix 2 for the releases of ACP/TPF throughout its history you
will see a number of RPQ numbers. The term 'RPQ' belongs to IBM
and stands for Request Price Quotation. What it actually means is
that a feature has been added, often at the request of one or two
customers. This technique was common in the TPF world. In fact
it even reached the stage of having a special set of model
numbers for the IBM mainframes that included a whole host of
special hardware features created for the TPF environment.
As you can see this reliance on an empathy between hardware
and software was not ideal for the TPF customer. It meant that it
was hard to choose another hardware vendor other than IBM since
it was not clear whether the other vendors could offer the
special add-ons for the TPF peculiarities, or that they would
want to. It also became so much of a nuisance to IBM that they
eventually scrapped the idea of differentiating between the
higher performance machines built for the TPF user and the
standard mainframes intended for the vast majority of its
customers. Nowadays it is more unusual to see RPQ applied to a
modification necessary for TPF only as IBM has made these
modifications part of the standard product. It is still IBM
practice, I believe, to use an RPQ for a hardware modification
necessary to support some of its own new software for example.
In its lifetime ACP/TPF has flirted with almost any
technology that promised better performance. For a time the IBM
fixed head disks, 2305s, were supported but other advances, both
in hardware and software have made these devices an unnecessary
complication to an already complex system. Intelligent DASD
controllers having fast memory to provide caching have also been
in use for some time. Unfortunately, for a long time the type of
buffering used for TPF was incompatible with other operating
systems meaning DASD could not be shared in a single string
between TPF and anything else.
Having said up to now that ACP/TPF craved anything that
would give it more performance perhaps one of the most
interesting software developments during this time was that of
the Hypervisor. The situation faced by most of the airlines,
particularly those in N. America that did not already fly to many
other parts of the world at that time, was that they needed the
biggest, fastest machine that IBM could provide for the
transaction load during the day but often found that off-peak
traffic was only using a fraction of that expensive hardware. So
the idea of the Hypervisor was born, a software package that
would sit above the ACP system in the box and allow coexistence
within the machine with OS/VS. The constraints on the package
were severe, it must not impact ACP more than 5% and it had to
ensure that it had no effect on the system's overall reliability.
It also had to be totally invisible to ACP and to the other
system, OS/VS, and all applications running under these two
systems.
This was achieved by using the interrupt handlers in ACP.
These contain logic capable of recognizing whether any interrupt
belonged to ACP or not; so it was relatively easy to modify these
to process OS/VS interrupts.
OS/VS2 (MVS) is the only other system, other than a test ACP
system, that the Hypervisor was designed to host. This simplifies
the job of providing this 'virtual machine'. Anything more
complicated than that would have produced something akin to VM,
which would have been too much of an overhead. The guest system
runs in problem mode, that is to say in user mode as opposed to
system or supervisor mode. If guest code (OS/VS) is in control of
the processor when an interrupt occurs the native system (ACP
with the Hypervisor) gets control but the reverse is not true.
If the guest system is not in control but receives an interrupt
the interrupt is queued until the guest once again gets control
from the hypervisor. Even privileged instructions from the OS/VS
guest are simulated by the hypervisor to prevent the guest from
obtaining control over the system and excluding ACP. It also has
the effect of preventing any problems to ACP reliability from
faults in the OS/VS system but did degrade the perceived
performance of OS/VS. In 1973 this software was introduced and
with the release of the XA version of TPF, V2 R4, it was dropped.
The next major event in the history of ACP/TPF we are going
to visit was known as the JADE project (Joint Airlines
DEvelopment) which produced as a result the first ACP/TPF systems
to operate with multiple mainframe machines linked together and
sharing the same database. This was another example of the close
working relationship between IBM and the major users of ACP.
|
