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.