Airline Reservation Systems

AIRLINE
RESERVATION
SYSTEMS
By:
David J. Wardell
July, 1991

Airline Reservation Systems Page 2
July 5, 1991 ©1991 by: David J. Wardell
Reproduction Prohibited
NOTICE
This document is proprietary and confidential. It may not be copied or reproduced either
photographically, photomechanically, or electronically. It may also not be quoted or
referenced in other documents, presentations, studies, papers, or symposia without
express, prior, written consent.
David J. Wardell
Digitally signed by David J. Wardell
DN: cn=David J. Wardell, o=Technical
Reality, ou, email=david@wardell.org,
c=US
Date: 2011.03.18 15:30:33 -04'00'

AIRLINE RESERVATION SYSTEMS
A REPORT & OVERVIEW
BY:
DAVID J. WARDELL
Airline computerized reservation systems (CRS) are the primary form of travel agency
computerization in the world. These systems manage the millions of reservation requests
and cancellations, fare, and reservation pricing requests1 that are initiated by travel
agencies using these systems—not to mention the thousands of database changes that
occur daily. The CRS function as extremely powerful and valuable distribution and
marketing tools for their airline owners. Today's travel agency competitive environment
is largely defined and controlled by airline CRS.
This report describes:
 Airline reservation and distribution systems
 CRS processing and communication concepts
 Relationships between CRS and other industry components
 CRS and airline competitive strategies, as these pertain to reservation technology
 Non-reservation systems that interconnect with airline CRS
 Profiles of the major international airline CRS
1
Pricing in this sense refers to the application of fares, as contained in a fare database and as
specified by a rule database to specific itineraries as reserved by a traveler. Thus a travel agent will
make a reservation and price the itinerary—yielding a total fare, or price, for all segments within
the passenger's itinerary, when considered as a whole.
This is significant as airline reservations are frequently flight or itinerary-specific. For example,
fares between destinations A and B maybe lower if the passenger travels round-trip, if a certain
flight is used that the airlines desires to promote, or if flights with intermediate stops (as opposed
to non-stop flights) are used.
Fare databases are used to quote rates based upon passenger inquiries, but only a complete
itinerary price is used to issue a ticket and is guaranteed to the traveler.

Airline distribution has been greatly shaped by deregulation and the rise of travel
agency computerization. Critical to understanding how travel distribution is managed
is an appreciation of the influence computerization exerts over travel agency
reservation and purchasing practices.
The role of automation in this area must not be underrated, as automation provides the
vehicle for airlines to effectively enfranchise dealerships among the travel agency
community2
.
These dealerships play an important role in broader carrier distribution strategies.
Computers are routinely cited as representing significant competitive barriers to domestic
U.S. and international carriers operating within the U.S. (as well as in other areas), when
in reality market leverage is gained through much more subtle and effective means.
The marketing relationships described here are supported by automation within the travel
agency community, based upon the conditions existing in the U.S. market. Although not
directly applicable to many areas of the world, these U.S. experiences are indicative of
what other markets may expect as regulation is relaxed and competition increases. As
U.S. carriers expand beyond their national boundaries, both as to routes and agency
distribution, other countries make expect U.S. style distribution practices to be introduced
and competition to become more aggressive.
A HISTORY OF TRAVEL AUTOMATION
The fundamentals of airline reservation handling have not changed substantively for
decades. From the first basic, no-frills scheduled air service between Amsterdam and
London, inaugurated May 17, 1920 by KLM - Royal Dutch Airlines3
using a leased De
Havilland DH164
, passengers have required reservations and reservation record
management of some type.
Objectives of a Reservation Process
The systemization of commercial air travel in the 1920s and 1930s introduced the same
basic trip components that are used today:
2
Dealerships as understood herein are distributors that represent the primary interests of a
single principal or small group of principals (vendors) to the overall detriment of
other vendors. The dealership may or may not effectively meet the needs of its
customers, depending upon the precise nature of its business practices.
Dealerships are typically thought of as automobile distributors or appliance stores.
Travel dealerships are looser and are rarely, if ever, identified as such publicly. The
airline vendor's relationship with its dealers allows significant benefits to accrue to the
enfranchising principal, regardless of how the relationship is described.
3
KLM is the world's oldest airline still operating under its own name, and the Amsterdam - London
route is the world's oldest air route.
4
Aviation “firsts” are always subjects of considerable discussion. While some airlines put their
beginnings prior to 1920, they carried mail, and not passengers. May 17, 1920 is used by most
sources as the beginning of scheduled, passenger transportation.

 Scheduled services that potentially navigate a number of intermediate stops,
where a passenger may desire to travel only a portion of the aircraft's complete
route.
 Fares5
that apply to each portion of the passenger routing.
 Documentation, in the form of tickets which certify payment has been made and a
traveler has a right to transportation on a specific flight schedule between a
specific origin and destination.
 The necessity of managing reservations and cancellations, so that passengers may
rely upon the airline’s ability to accommodate them on their desired flights.
Commercial aviation and retail travel services revolve around the public’s desire for
certainty of accommodation on airline flights, and therefore, the necessity of pre-
reserving and preissuing airline tickets6
. Some air services, such as no reservation air
shuttles, eliminate the need for pre-planning (all travelers are accommodated) and the
need for complex ticketing (a single or very simple fare structure is used). Ingeneral,
however, the role of airline tickets are ticket issuance has not changed in 70 years.
Early Reservation Management
Prior to the electronic age, reservations were managed manually using record books and
manifests, reservation cards, and other printed media. Many simple reservation
requirements are still (1990) met in this way7
.
5
Fares are charges that apply for passengers between a specific origin and destination point, using
a specific class of service and a particular routing, as determined by the carrier.
In earlier times, fares were tied to distances traveled more closely than they are today. Now,
promotional and yield management considerations make it very difficult to project or establish
fares based upon distance alone. Outside the U.S., airlines often operate in regulated
environments, where prices are fixed by international agreements or government decision, rather
than by competition.
This occasionally results in considerable consternation on the part of travelers and consumer
groups, as these fare and pricing inequities are difficult to justify when examined outside the
larger airline pricing context.
Two of the world’s busiest air routes - London to Paris, and New York to Washington, DC- are both
around 220 miles. An unrestricted London-Paris ticket as of this writing (Fall, 1990) is £88 ($172),
whether the customer flies British Airways or Air France, whereas the price of a New York
Washington shuttle ticket is $129 (The Economist, 1989).
6
Some travel agencies perform a financial function, in that they organize payments on behalf of
business travel purchasers and issue consolidated statements and invoices for tickets purchased.
This can also be a credit or cash management function, if the travel agency does not require either
payment on delivery or payment through a charge card with ticket issuance.
In either case, this is a minor part of any value-added by the travel agency to its business travel
customers.
7
Although “hard-copy” reservations management is more common in the hotel industry, many
substantive airline operations, operate in a primarily manual mode. These often use CRS inventory
displays for communicating sales made to a central facility, where the actual database resides in

After the Second World War, air travel and airlines expanded rapidly.The “jet age”
arrived in 19588
, and with it more passengers and larger aircraft, as air travel quickly
replaced train and bus as the main form of mass public conveyance. As airline schedule
planning became increasingly complex, reservation management systems reached
unwieldy proportions.
Reservations were typicallyrecorded on cards, each card corresponding to a trip between
specific city-pairs. Cards were then organized bydeparture date and stored in tubs that
were rotated among various reservation agents as necessary. Reservation requests from
outlying offices were either telephoned to a central facility or transmitted via
teletypewriter9
and processed manually upon receipt. Reservations could only be made
30 days in advance of flight departure.
In the early 1950s, when the idea of electronic reservation systems first became practical,
it took approximately 2 hours to completely process an average reservation transaction10
.
By the early 1960s, this time had been shortened to 45 minutes—still in a mostly manual
mode.
Early Computerization
During these same years, electronic, digital, computers were entering what is termed the
“second generation” of modern computational devices. Whereas the “first generation”
relied upon vacuum tubes and a number of competing mass storage systems,11
“second
generation” devices used the much more flexible and reliable transistor and magnetic
core memory almost exclusively.
manual form. This is one illustration of the absolute necessity of CRS as distribution tools, if not
inventory management tools.
8
BOAC (later consolidated with British Airways) began transatlantic service from New York to
London October 4, 1958. National Airlines (later purchased by Pan American World Airways)
began domestic U.S. service from New York to Miami December 10, 1958.
9
Telegraphy has a long history in the travel industry and is still an integral part of data
communications for many suppliers (as discussed later in this chapter). The term telegraphy
describes a telecommunication system whereby graphic symbols (using a small character set of
letters, numerals, and a few special control characters) are transmitted using a signal code that
describes each character so transmitted individually.
Frequently the 5-bit Baudot encoding system (from which the term “baud” is derived) is used,
particularly in print-based teletypewriter machines. Data processing (non-print media) telegraphy
can use any number of encoding systems, the essential quality being representation of discrete
characters by specific codes without intermediate states or gradation.
Teletype is the trademark of the Teletype Corporation for their teletypewriter devices.
10
(Software Magazine, 1989)
11
These included electrostatic storage, which was insufficiently reliable for most applications;
mercury delay line storage, a very slow (on the order of 500ms, or about 50 times greater than
1990-era storage media) system used only by UNIVAC; magnetic drum storage, widely used but
also slow; and magnetic core, the most successful process for both commercial and scientific
applications.

In the early 1960s, work commenced on “third generation” digital computers. This era,
usually described as lasting between 1964 and 1975, is characterized by the introduction
of integrated circuits12 13
, but which also produced operating systems, machine
instructions, and methods of data and memory management that were sophisticated
enough to form the basis for many of the large-scale commercial computers used today.
Thus, it is not uncommon to find large, important programs and systems that are rooted
in this era.
Development of “PARS”
This is the period when commercial data processing technology matured to a point where
large-scale airline reservation systems were practical. The early airline reservation system
projects were managed by IBM14
and UNIVAC15
, with the most successful projects
developed in connection with IBM. There were several initial development projects
pursued by competing airlines, including United Airlines, Eastern Airlines, Trans World
Airlines and SABRE,16
developed in conjunction with American Airlines.
American invested what was, for the time, the tremendous sum of $40 million which
“would have bought the airline four Boeing 707s at a time when the entire fleet consisted
of fewer than 25 aircraft”.17
SABRE development began in 1958 and required four years of planning and two years of
programming. The system was introduced in 1964, using a modified IBM 7094, a second-
generation system. The essential SABRE operating system was proprietary to American
at this time.
In 1964 IBM also introduced the System 360, which represented an almost complete
departure from many machine design concepts employed by IBM prior to that time.
System 360 architecture was the most successful computer design up to that time, and
among the most successful of any to date. Although the 360 did not use integrated
circuits in many of the key areas usually associated with third-generation systems, its
design has much more in common with third than second-generation devices.
Understanding the basic premises of the 360, which was supplanted by System 370 in the
early 1970s, is important to appreciating many of the strengths and limitations of PARS-
12
During these years, LSI or Large-Scale Integration devices were produced. These are similar to
the VLSI or Very Large-Scale Integration devices (broadly defined as a device containing more than
10,000 transistors on a single circuit) used in today’s circuits, but on a less sophisticated level.
13
It is interesting to note that integrated circuitry, although pioneered in the late 1950s and
commercially available as early as 1961, was helped immeasurably on the road to wide acceptance
and practicality by the early U.S. space program.
14
International Business Machines, then, as today, manufacturers of the most successful, highly
reliable, commercial data processing devices and operating systems.
15
Now merged with Burroughs to form Unisys.
16
Semi-Automated Business Research Environment
17
(Software Magazine, op. cit.)

type CRS. System 370 architecture is still (1990) central to IBM’s mainframe commercial
processor line.
American faced serious implementation
problems with the early SABRE system, among
them capacity limitations. Shortly after the
introduction of System 360, American
implemented a machine that provided supportive
processing functions to SABRE, but did not
migrate to the newer and much more powerful
and efficient System 360 environment.
In 1968 American reached an agreement with
Eastern Airlines that allowed American to modify
and implement Eastern’s Programmed Airline
Reservation System (PARS) on its System 360.
PARS18
was another IBM project, working along
different lines from American’s SABRE effort, and
built on behalf of Eastern. Other airlines had
launched similar, but unsuccessful, reservation
system development projects19
. These
eventually adopted the basic PARS system, and
modified it to meet their own needs.
PARS concepts, designs, and features still form the primitive foundation of most airline
reservation processing and management systems today. An international variant of the
PARS system, IPARS, followed the initial PARS project.
PARS was designed to run on IBM’s latest 1960s vintage commercial processors, System
360, and used a variety of existing and proprietary tools and software systems. Since its
introduction, IBM has assumed a leadership role in developing, enhancing, and
upgrading airline systems, supportive programs, protocols, and the hardware on which
they run.
System 360/370 architecture assured PARS’ usable life in the 1990s. As IBM upgraded its
commercial mainframe processor line, newer, faster, more powerful machines replaced
older systems in existing PARS installations. This was made practical because upward
compatibility was an important feature of the System 360 concept. Even though many
essentials of the PARS environment remained fundamentally unchanged over the years,
18
Eastern PARS is distinct from the proprietary airline CRS developed and market by TWA, and
which is now part of Worldspan, in partnership with Northwest Airlines and Delta Airlines.
Although the platform used by TWA developed from IBM/Eastern PARS, the CRS is a distinct
product with its own pedigree.
19
Trans World Airlines (TWA) has a similar development project with Burroughs, and United
Airlines worked with Univac (both Burroughs and Univac are now part of Unisys). Although
Univac did finally implement a somewhat successful reservation system, which was used into the
1980s by airlines such as Northwest Orient, the initial United Airlines effort was abandoned.
Key Aspects of System 360 Architecture
 Large, complex instruction set intended to build
many capabilities into the basic design of the
machine, thereby limiting, to a degree, the need for
many complicated programming steps.
 Employed instructions embedded in
microprogramming, stored in ROM components,
allowing application portability across a number of
machines using the 360 instruction set but
employing a range of circuit designs and speeds.
 First large-scale commercial use of emulation,
whereby applications not directly employing the
System 360 instruction set could be run by
simulating conditions on the hardware for which
they were designed.
 Introduction of memory cache to aid overall machine
speed. Successful introduction of large-scale virtual
memory operating systems and applications,
permitting time-sharing among a very large group of
simultaneous sessions.

hardware advances have allowed PARS to continue meeting the needs of ever expanding
CRS networks.
What Is PARS?
Rather than a monolithic program set or product, PARS is the essential foundation and
conceptual basis for airline systems. Because these concepts were replicated in later
modifications and revisions of the original PARS, there is great similarity among all PARS
systems, particularly the major U.S. CRS. This applies to operational practices, operator
formats, system capabilities and limitations, and ongoing enhancements. There has been
significant cross-sharing of PARS functionality because of IBM’s role as developer and
maintainer of the software tools that comprise much of the PARS environment.
Although this text speaks of “PARS and IPARS systems”, it does so in a generic sense, as
frequently there is little or no real difference in the software of one PARS-based system as
opposed to another. Where there are functional or architectural distinctions, these are
clearly identified. In reality, however, all major U.S. CRS have operated as independent
systems since the late 1960s.
Inventory vs. Passenger Systems
The initial airline automation efforts, including PARS, were inventory systems, and not
passenger systems. Based upon the management priorities defined in the late 1950s,
gaining centralized inventory control was the most important priority. These early
transaction systems processed reservation requests against declining inventory
allotments, but lacked even the relatively simple passenger record, service request and
file access capabilities of later PARS-type systems. The extensive schedule information
for offline (non-host) airlines was also lacking.
More extensive databases were partially visualized, but were only incorporated into later
PARS software releases after the initial inventory systems had been operative for some
time. These were also implemented in varying degree of sophistication, depending upon
the airline and system in question. There is more commonality between the schedule,
reservation, and booking modules of various PARS-type systems than there is in other
databases and functions.
Communication Limitations
Early airline systems lacked the sophisticated communications capabilities that are taken
for granted today. Large public data networks, sophisticated data transfer protocols, and
standardized interfaces were unknown. System planners operated in an environment
where even long distance telephone calls were relatively rare and expensive.20
20
The era where long distance telephone communication was routine really did not arrive until the
1970s. Although nationwide direct dial service had existed for many years previously, line
conditions were poor and rates high by today’s standards. The public generally limited long
distance telephone conversations to unusual circumstances. Although reliance upon the telephone
was more common in business, written correspondence still played a more prominent role in the
conduct of long distance business than is true today.
The extensive commoditization of telephone communications was brought about by the gradual
deregulation of long distance services, and subsequent lowering of rates, beginning in the early

This necessitated low-cost, reliable, easily implementable and maintainable
communications methods to support information exchange between airline host systems.
Because of their role as product distribution tools, not just inventory systems, airline
computers in particular rely upon data communications to exchange information rapidly
and effectively. This is because interline21
reservations and ticketing have been
fundamental to world travel for many years. An airline’s biggest “customers” are other
airlines’ internal reservation centers and computers, who make reservations for
passengers as both as a pure convenience to their customers and as a source of
passengers that may transfer or “connect” from these airlines.
Communication between airline systems is necessary because the operator of one
system needs the ability to update the inventory and create reservations in another
system that operates independently of the one the operator is using. The system
functions as a computerized work environment and productivity tool for the operator. If
inventory sales and updates in “offline” systems can be accomplished electronically the
reservation process is much faster. The alternative is for the CRS operator to use the
te1ephone, which always increases the time required to make a passenger’s reservation
many times.22
The passenger also wants reliable schedule, availability, and reservation information as
quickly as possible. Particularly in the U.S., travelers are accustomed to “instant” results
and are dissatisfied if lengthy delays are introduced. Electronic messaging, together with
airline database practices, makes virtually instant reservation confirmations practical.
Early airline communications used teletypewriter-based messages that could operate
reliably at low transmission speeds, using existing, inexpensive, communication circuits.
These communications operated in a network-based mode, thus eliminating the need for
1980s, and the introduction of more advanced telecommunication technology, such as facsimile
machines (FAX) in the mid 1980s.
21
Interline refers to tickets (or ticket-related transactions such as reservations) issued by one
airline on beha1f of another. This is done because airline schedules often require coordination with
other carriers in order to fulfill customer needs. Thus, a traveler flying from Portland, Oregon to
London, UK must change planes at some intermediate city because there is no direct service.
The traveler’s itinerary might involve United Airlines between Portland and Seattle, Washington,
then British Airways from Seattle, non-stop to London. Only a single airline ticket would be issued
that would contain two valid flight coupons—one for the United flight and another for British
Airways. The traveler would also probably pay a single price, which would be divided between the
two airlines based upon formulas agreed to by the airlines involved. The passenger’s reservation
and ticket could be issued by either United Airlines or British Airways, because of the interline
agreements in place between them.
The overall effect is to simplify the transaction for the traveler and any travel agent that would
issue the ticket on behalf of the airlines involved.
22
Telephoning is very common in the travel industry, as some airlines do not make reliable
inventory information available to “offline” systems; others are not automated at all. Telephone
calls for reservations routinely take several minutes at best, and can take much longer, if the
reservation center called is busy or telephone communications are unreliable. This contrasts with
electronic inventory sale messages which the operator completes in a few seconds.

dedicated circuits between each reservation system. Airline messaging systems are
described later in this report under the heading Connectivity.
These basic communication formats and practices are another legacy from the early days
of airline computerization and still serve much of the industry today, albeit in an
enhanced and upgraded form23
. While the original interline communication methods are
practical, they are neither flexible nor particularly efficient and have been extensively
replaced by modern communication technology.
It is interesting to note that considerable work had been done on developing more
efficient data communication methods during the same years airline systems were
developing, particularly to support military projects24
. For various reasons this technology
was not incorporated into the early airline system projects25
.
Software Development in the 1960s
It is difficult for many people, regardless of their familiarity with computers and
programming, to appreciate many of the constraints large-scale developers operated
under in the 1960s. Today, most commercial programmers are avid PC enthusiasts and
are accustomed to working “online” both at home and professionally. Using a CRT that
directly accesses a computer workspace, they write program “code” or instructions
electronically in a disk file, “compile” their programs (produce a set of machine
commands ready for execution by a computer based upon the “source code” or
instructions created by the programmer) online, and test them as each portion of the
program is completed.
Sometimes emulation programs are available that permit PCs or other small systems to
behave like large commercial mainframes, so that programmers can experiment in an
environment much like that where their final work will reside26
. Modern programming has
23
These are detailed in the publication: Reservations Interline Message Procedures -- Passenger
(ARIMP), current edition, Montreal: International Air Transport Association.
24
Univac played a large role in this development.
25
Partly this was doubtless because a comparatively “low-tech” approach to meeting the
communications needs of the embryonic worldwide airline systems industry, where all phases of
communications technology were underdeveloped and not completely reliable, was deemed more
appropriate.
It is also partly true that the right applications and designs were simply not made available to the
right airline system designers at the right time.
26
There are numerous other programmer tools that make the production of machine instructions
easier and more reliable. Most rely upon close interaction with a processor of some type, so that
the programmer gains real experience as the work progresses.
An illustration is Microsoft’s excellent PC-based Quick-BASIC programming environment. Here
programmers use an online screen editor to create their code, assisted by online help files and
self-editing features that identify potential errors as they are made. Programs, parts of programs,
or even individual steps can be tested at will through an emulation feature that avoids the
“compile” step and demonstrates what the final product will actually do on the host computer.

come to depend upon interaction with a processor and “debugging” or error-correction
almost at will.
It was not uncommon for programmers in the 1960s to never actually see the computer
they worked on--indeed, programmers working exclusively on software of similar vintage
are sometimes similarly disadvantaged. Instructions were written on pre-printed forms
and transferred to punch cards by clerks specially trained for that task. Those cards were
then “loaded” into the computer in batches and the program was run. Debugging was
always necessary, but the programmer could not depend upon constant interaction with
the processor, because the input, load, and run functions were much more complicated
and time-consuming.
Hardware in the 1960s was limited and expensive. Computer time was valuable and also
expensive, so much so that skilled programmers often spent considerable time trying to
reduce the number of steps their programs required. Modern programmers have much
greater and less expensive machine resources available to them, which eliminates the
need for such precision27
.
Computer Languages
Computer languages are sets of symbols, instructions, and statements used by
programmers to control the operation of a computer and its peripheral devices. In its
basest sense, computers “understand” only binary code - series of Os and 1s, or “on”
and “off” conditions. While it would be possible to construct programs using binary code,
it is so difficult that it is almost never done. Other “languages” are used that can then be
translated or “compiled” into instructions that the computer can execute.
Assembly Language is a term loosely used to describe symbolic instructions that a
programmer uses to direct specific, predetermined responses from the computer. The
programmer does not work directly with binary code, using instead alphabetical or other
symbols that equate directly to binary instructions28
. Since assembly language directly
controls individual actions or series of actions that the computer performs, it is specific to
each machine where it is used. In other words, an IBM System 370 uses a different
variation of assembly language than does an IBM PS/2. Many early programs were
written using forms of assembly language, and this form of programming is still used
where programmers must optimize the responses of the machine for which the program
is developed.
Most airline system and application programmers use a form of assembly language,
which accounts for much of their development and maintenance. IBM is introducing
enhancements to the programs used by airlines that, once implemented, will allow more
flexible development tools to be used.
27
To illustrate, the first computer the author, used was an IBM 360/20 that had 48k of magnetic
core memory and very few peripheral devices. Contrast this with today’s PC which is routinely
equipped with at least 640k of semiconductor memory, a CRT, and numerous peripherals.
28
Sometimes, depending upon the type of assembly language used, a program called an
assembler is used to translate certain parts of the program into a form suitable for the computer.

So-called “higher-level languages” approximate human communication and are
compiled into object programs that can be executed by computers. Whereas an assembly
language programmer exercises significant control over each action the machine
performs, a high level language programmer focuses on the result desired and relies
upon the compiler to control individual machine instructions. While this obviously results
in greatly increased programmer productivity, a given program can and often does result
in very inefficient object code that does not optimize machine resources or capabilities.
Transaction Processing
At the time PARS was developed there were several successful “high-level”
programming languages in use29
. Online transaction processing systems, similar to those
required by airlines, had also been built or planned by this time. The architects of PARS
were able to build on this body of experience, while tailoring a system to meet the
specific needs of the airline planners that also participated in the project.
IBM’s Airline Control Program (ACP)was the first transaction processing tool applied
PARS-type airline systems, beginning in1965. The Transaction Processing Facility (TPF)
was part of ACP, but developed more specialized applications and was used more
independently as time progresses.
In 1984 IBM positioned TPF as a strategic product that would serve a different specific
market segments together with MVS and VM, IBM’s state-of-the-art operating systems.
IBM modified TPF by introducing numerous extensions that dramatically increased its
power and attractiveness to users30
. TPF now runs in native mode31
on IBM 3090
machines, the system used by the majority of current generation airline systems,
meaning that a host operating system is no longer required.
An early problem with TPF, indicative of the era when it was developed, was that only a
uniprocessor32
could be used.
This was corrected with releases subsequent to the 1984 announcement. An equally
important enhancement was TPF support for compiled source code, whereas previous1y
TPF programmers used assembly language.
29
Fortran (1958), Cobol (1960), and Algol (1960) are examples of several that are still used (with
ongoing revisions and refinements) today.
30
This, in part, accounts for American’s decision to migrate to a “pure” TPF environment—a
project undertaken with significant expense and risk. SABRE’s access to product enhancements
and IBM support is thereby significantly enhanced. Further, the programming upgrades introduced
into TPF promise to make it a much more productive environment. These advantages were not
available to hybrid systems.
31
Native Mode usually refers to a computer operating environment that is specific to a particular
type of machine, within which applications can be run without the need for interpreters or
specialized operating environments that are foreign to the machine in question.
32
Uniprocessing means that instructions are executed by the processor sequentially, as opposed
to multiprocessing, where several processors function in parallel, executing coordinated
instructions.

Although TPF enhancements were successfully embraced by many airlines, some
airlines, including American, continued to use a highly optimized form of ACP for years.
American converted to TPF from a hybrid ACP/TPF environment completely in 1991. This
is very significant, as it allowed American to operate directly on hardware and software
that are part of IBM’s product mainstream, thereby reducing American’s long-term
software maintenance expense and giving it a much more direct path to the latest
technology33
.
Current Airline Automation
Some idea of the complexity that current airline reservation systems have achieved can
be gleaned from the accompanying description of TWA’s PARS system34
.
By comparison, SABRE, the largest system in used by travel agents today, currently
operates its Passenger Service System, one of five major divisions of SABRE, on 6 IBM
3090/200 series machines and 224 IBM 380 disk drives. Each drive has approximately
1,320 mb, giving the system a total storage capacity of 296 gb per volume. Current
memory is 726 gb.
SABRE has announced figures of over 1,800 transactions processed per second during
exceptional peak periods, and anticipates 2,200 or more in the future.
33
Although American’s implementation of mainstream technology is a significant and correct
strategic step, it is debatable whether the new environment provides as much high-volume
transaction processing flexibility and capability as did American’s hybrid ACP/TPF system
While a detailed discussion of this question is beyond the scope of this text, it is well to remember
that American’s decision was a strategic move, undertaken for reasons apart from pure transaction
processing capability.
34
Per Vijay Kumar (Kumar, 1990). Vijay Kumar is an assistant professor of computer science at the
University of Missouri—Kansas City. His research areas are distributed systems, object oriented
and expert database systems. Copyright Association for Systems Management 1990, used by
permission. This material is based upon (Gilford & Spector, 1984) and (Buckley, 1989).
TWA PARS Snapshot
 TWA’s system has about 50,000 communication terminals in the field worldwide. The size of the database is about 850 gb (two to
the thirtieth power; significant storage for its day) and is stored on 340 of 3380s DADS. It is fully duplicated for performance and
availability reasons. About 8% of 850 gb are occupied by passenger records.
 A typical daily workload is about 20 million transactions. The peak performance rate is about 800 TPS.
 The average rate is 552 TPS with a response time of 1.5 second.
 Reliability of these systems is also an important parameter. A partial database recovery (recovery from transaction or system
program failure) takes about two minutes. A cold start (total failure or starting system from scratch)takes about eight hours. In
1972, TWA lost about $2 million and in 1976 about $250,000 due to system unavailability. However, the airline has improved its
software reliability and did not have a major system outage for the last two years.
 Initially, it had a 9083 CPR that ran on a 3083 uniprocessors. Since then, it has gone to multiprocessors (3390), four of which are
dedicated to on-line processing. TWA can accommodate up to eight processors that might give it adequate power to reach 1,000
TPS

Airline systems share the same goals as other high-performance transaction processing
environments:
1. Reliability. As illustrated, downtime can significantly affect revenue and costs.
2. Responsiveness. User productivity degrades rapidly with decreasing response
times. In the highly competitive CRS area, small variances can result in a lasting
competitive disadvantage.
3. Price/Performance. An optimal environment must be in p1ace at an acceptab1e
cost, both to the CRS and the user. This is a major challenge as CRS continue to
develop and user appetites for new and more extensive applications increase.
4. Enhancements. The CRS environment must be sufficiently adaptable to allow
creation of the functionality users require. This has been difficult using old-style
ACP/TPF systems, but will change as more standardizes and sophisticated
operating environments are created.
5. Process and System Integration. The most effective development path for the CRS
will be to effectively integrate local, distributed systems and microcomputer
based workstations into the CRS environment. This is an extraordinarily difficult
task to do effectively, given pricing limitations35
and the restrictive nature of CRS
communications, architecture, and databases.
Transaction Processing Fundamentals
Today all airline systems operate as online transaction processing systems36
. A
transaction system allows operators to initiate queries and requests for specific
applications, view the results of these applications in real-time, act upon the results of
this process, initiate follow-on transactions that are determined by the results, and update
files or records based upon information resident with the user rather than within the
system. These events are driven by a series of independent interactions between the user
and the system, known as transactions.
Transaction-based systems differ from other conventional computer applications (here
applied specifically to airline systems which are among the largest and most complex
transaction systems):
 Transactions Discrete and Independent. While the information contained within
one transaction may affect other transactions (perhaps because they use a
common database where updates initiated by one transaction may be passed to a
subsequent transaction), one transaction is usually not dependent upon another,
nor connected with another as to time.
35
Most CRS highly subsidize user (travel agency in the main) hardware and software. Rea1 CRS
revenue is obtained through transaction fees charged to vendors. There is a complex relationship
management challenge facing not only the CRS but others who would use the CRS as a value-
added network. This is a fundamental premise that is usually overlooked by would-be CRS
application developers.
36
By far the majority of transaction-based systems produced today, regardless, of application, are
online systems.

Batch-oriented systems, by contrast, manipulate data elements as a group. There
may be extensive data dependencies in such systems, and omissions of some
elements would require the entire application to be rerun.
 Databases Updated and Queried as Needed. The transaction system works using
information stored in a database and the results of online data entry are usually
recorded in a database.
 Geographic Separation. Transaction systems function without regard to where
their users are located (as long as the requisite communication services are in
place) Users working on the same system may be separated by thousands of
miles.
 Concurrent Sessions. Because transaction systems usually must support many
(sometimes thousands) of users, they emphasize performance and throughput37
.
Since many system users may require access to the same databases
simultaneously, transaction systems must support user sessions38
running
concurrently, while maintaining performance and the integrity of individual data
elements.
 Queries and Requests for Applications Responded to Real-time39
. Thus the
timeliness of data supporting an online system become critical, as old data cannot
be used to make reliable decisions. Data must also be synchronized within the
system, so that databases are consistent for all users and transactions initiated or
updated by one user available to other users and do not conflict with updates
made by other users.
 Limited Functionality. Airline CRS attach functions to the database query and
update portions of the online system. These functions act upon data retrieved
online from the CRS, or input online at the user’s site, and produce specific
responses, such as calculated prices for traveler itineraries, printed itineraries, or
tickets. Online transaction systems offer few functions to their users, as compared
to the range of functions that could be designed for the system, and these have
limited, specific purposes.
 Data Accessibility. Most required CRS data are available continuously while the
system is operating40
and can be accessed at random. This contrasts with batch
37
Essentially meaning the time a transaction takes from its initiation to completion—including
manual and computerized steps and processes.
38
In this sense, an individual user’s interaction with the system in order to accomplish a specific
purpose (such as make a reservation for a passenger) is termed a session. A session might include
dozens of transactions and database queries, all of which would come together in the completed
passenger’s reservation.
39
A real-time application delivers a response during the time that the application is physically
running on the computer, so that the process can receive interaction from the user and be directed
accordingly. In airline reservation applications, for instance, requesting flight availability is an
interactive, real time application because the user determines specific parameters and modifiers
that are used to deliver “correct” flights, making the decisions as to what modifiers to use while
interacting with the system.
40
There are CRS databases that are used for internal MIS or other purposes not essential to system
operation. These may not have continuous availability.

oriented systems where data necessary for one application may not be available
unless that application is running, and where offline storage (such as on magnetic
tape),and sequential data access is required.
 Event-Driven. Transaction systems must undergo regular maintenance, as must all
complex systems. CRS also have scheduled database updates, as for schedule
changes among other purposes. The CRS will also schedule certain applications
affecting many transactions to be executed at specific times. This helps shift
system load to “off hours”41
.
Most transaction-related processing, however, begins when users initiate
transactions by entering or retrieving data and not based upon any particular
schedule. It is impossible to predict when specific transaction-based functions will
be required or from where on the network they will originate. This necessitates
complex capacity planning and continuous availability of basic system functions at
all times when the system is operative.
 Point-of-Entry Editing. Online transaction systems reject incorrectly formatted
instructions or data blocks as these data are entered and return an error message
to the users real-time, so that a correction can be made and the entry reattempted.
This must be done because interaction with the user is essential to the online
transaction system’s successful operation, and only “good” data can be used for
this purpose.
 Transaction Size. Most batch or single application computer systems take several
minutes to execute all but the simplest applications. Many larger programs can
take hours or days to complete. The real-time, event-driven nature of the
transaction system requires responses within seconds42
. This means that systems
must be designed and programmed for optimal speed43
and transactions are kept
small to achieve the best responsiveness. CRS reservations, for example, are
compilations of many individual transactions, each executed individually but
which, together, complete the traveler’s desired reservation.
 Data Integrity. Each part of the CRS database, particularly passenger reservation
records, must be current at all times and reflect the best possible condition of the
data44
; no delayed updates are acceptable. This is necessary because the random
nature of transaction systems makes it impossible to assume that any available
41
A good example is the electronic filing of passenger reservations that have been coded to be
ticketed on a certain date. This typically occurs overnight, when system usage is at a minimum.
42
1.5 seconds is the standard for most responses using SABRE. In other words, a user receives a
response to any entry made within this time. The sole exception is the complex “best fare” pricing
program, designed to locate the lowest air fare for a particular itinerary, which can take
approximately 5 seconds.
Users are very conscious of system responsiveness and routinely complain if even a few seconds
are added to familiar response times.
43
This is part of the reason assembly language programming, which is intrinsically faster than
many (not all) high-level compiled object programs, is used extensively in airline CRS.
44
This means that there may be inaccuracies in the database, but these must not be planned or
intentional. The system cannot assume that some inaccuracy or old data is tolerable.

record or data element will not be the next required by some user on the system.45
This applies only to CRS data that are used for transaction processing.
Understanding TPF
TPF is a proprietary development and processing environment specifically designed to
facilitate entry and processing of a large number of simultaneous transactions from
multiple network terminals, where extensive database queries must be managed against
large quantities of data and where overall responsiveness is a critical factor. A transaction
is defined as a single entry, or a series of entries that are assembled in an electronic work
area and completed at one time and that, in turn, initiate other actions within the system.
Industry experts define airline transaction systems as high-performance, in that they
typically process in excess of 500 transactions per second, with an efficiency rate of one
second response time over approximately 95% of transactions processed.
TPF is based upon a variant of assembly language. The entire work environment is so
unique that programmers skilled in its application and management are called “TPF
Programmers” and are among the highest paid professionals in that aspect of the data
processing industry.
Online transaction systems are becoming more common ways to access and update
databases. As these applications grow in size and complexity, more powerful and fully-
featured development environments and tools, such as TPF, become important. TPF
development is very expensive and demanding, causing many potential users (who are
not already committed to installations partly dependent upon TPF, as are the major CRS,
or who simply cannot use a less powerful transaction processing facility) to explore more
affordable alternatives.
It is important to define TPF’s role as a transaction management, rather than a database
system. TPF controls terminalbased queries and responses, and disk access, while other
programs are developed or purchased and integrated to handle true database functions.
1960s era software development defined database management as strings of commands
directed at multiple files (as opposed to the hierarchical or relationship-based structures).
These older techniques are decidedly less flexible than is today’s database technology,
but are efficient to access and store in an online environment while requiring relatively
little (per transaction) machine overhead.
Because TPF, and the airline systems that use it, are reflections of this environment, they
are not especially powerful, based upon today’s standards, as transaction processing
tools. Effective airline systems rely upon other applications, independent of TPF, to
support the database functions required of online systems.46
45
CRS do contain “non-essential” data that do not fit this definition. For instance, there are text-
based reference pages in every PARS-type CRS that contain general information of definite value
to system users but not essential to, or directly involved with, transaction creation or update.
46
“The Bank of America plans to use TPF as the basis for a high-volume transaction processor
front-end using IMS as the back-end system, and is also planning to enhance the power and
capability of TPF.”

Role of PARS Today
All this contributes to the characteristics that still shape PARS-based systems. The legacy
and limitations of PARS-type systems have been very frustrating to CRS suppliers and
users. Agents appreciate the basic commonality
between PARS-type environments, that makes it
fairly easy to learn a new system once one has
been mastered, but do not appreciate the cryptic
formats it uses (characteristic of 1960s-era
systems). Suppliers like the high-reliability that has
been achieved through constant refinement and
diligent maintenance of their PARS environments,
but, with agents, are dismayed at the difficulty (and
expense) of introducing modern functionality.
Many people believe that PARS systems are
nothing more than antiquated 1960s technology
and must ultimately be replaced by current
technology. Several years ago this was a common
theme particularly among misinformed government
regulators who criticized airline software
development and management practices as not
being in the public interest.
“… a good example would be the April 6, 1982 issue of The Travel Agent, which
reported then CAB47
Chairman Marvin Cohen as having ‘scored one point with
travel agents’ by telling a Washington, D.C. ARTA48
meeting that airline computer
reservation systems should be criticized for being unable to track complex fare
changes under deregulation.
(Kumar, 1990). Note: IMS or Information Management System is an IBM database support
product.)
In this same article, the author expresses the opinion, “In its present form, however, it (TPF) does
not offer a solution to transaction processing problems.” It is correct that TPF does not offer a
comprehensive solution to the range of difficulties associated with transaction processing, and its
longevity (at least in present forms) may be questioned, but the large, high-volume, successful TPF
operations in place today are sufficient testimony of its value as a transaction processing tool.
47
The Civil Aeronautics Board, a U.S. federal governmental airline regulatory body dissolved as
part of the Airline Deregulation Act of 1978. Many of its functions are now assumed by the
Department of Transportation; others by the Justice Department.
48
The Association of Retail Travel Agents, an industry group that limits its membership to
businesses actively involved with the sale of travel to the public at a retail level.
PARS Characteristics
 Careful, intricate design, where many programs
and applications work in concert to produce
desired results.
 Relatively inflexible structure that must
incorporate modernized versions of very old
programs with new applications to meet today’s
business needs.
 An ACP/TPF basis that is intrinsically expensive
and difficult to maintain, and very challenging to
update and that does not always have the latest
technology tools available to it.
 Non-standard communication protocols and
interfaces that are unique to the airline industry,
are character rather than data-oriented, and are
not efficient when used to support modern
applications.

“Mr. Cohen expressed numerous errors of fact. One was:
‘If an agent seeks one display of the lowest prices of all airlines (flying)
between Washington and New York, he or she will fail’, which drew light
applause.
“In reality, I believe all major systems did an acceptable job of providing this
information …”
“His remarks also included a statement that the software used by United and
American is 20 or more years old and that it would take as long as two years to
“reprogram the computers”49
.
“The technology to place remote computer terminals in almost every travel
agency location did not exist 20 or even 10 years ago50
.
“No major airline today uses operating systems from 1961. Some of the basic
formats and functions have been in use for a long time, but they are continually
revised and updated. This is the nature of any complex data processing system.
Programs for the major systems will not be re-written now or over the next two
years. The systems will update and modify their current procedures, but will not
start over.”51
All airline CRS use the most modern communications, storage, processor, and related
technology available. PARS-based systems preserve the remnants of their beginnings,
but each CRS has developed along different lines and operates and is maintained
independently. Today’s CRS often struggle with significant expense and effort to free
themselves of their inbred limitations, but each works with programs that are
comparatively modern and bear the mark of their own unique development histories.
HISTORY OF TRAVEL AGENCY AUTOMATION
In the mid 1970s, prior to initial travel agency automation, ticket preparation and
distribution were usually performed more cost-effectively by travel agencies than by
carriers directly. Estimated average airline ticket office reservation processing costs were
49
In the same talk, Cohen stated:
“The technical capabilities of today’s computerized systems reflects the old regulated
industry and they (the airlines/CRS) must adjust to the new, competitive regime.”
What, at the time, was mistaken for technological limitations was really an unavoidable
consequence of deregulation. This is so because the most challenging CRS consequence of
deregulation is database maintenance, which is hampered by significant, nontechnological,
limitations. There have been significant pricing and fare-search tools developed for the major CRS,
but the fundamental database problem remains and has not changed significantly, although the
trave1 agent’s and the public’s ability to deal with the problem have improved greatly.
50
This is because the transaction load experienced by today’s CRS, based upon their broad travel
agency user bases, could not be accommodated by systems of that vintage.
51
Excerpted from a four-part series, The Right Decision for the Right Reason (Wardell, 1982),
published in The Travel Agent. Copyright 1982 by David J. Wardell. All rights reserved.

approximately 16.2%, whereas agency commissions were only 7%. Overall distribution
costs could be reduced if a carrier’s agency volume increased, particularly regarding
largely point-to-point business air tickets.52
Agency commissions during the regulated years were set by industry agreement,
whereas today carriers determine compensation levels independently. General practice,
with some exceptions, has held base commissions to 10% of net air ticket value (the total
price less the 8% federal transportation tax), for an effective commission cost of 9.2% to
the carrier53
. At a 7% commission level, when the 8% tax was also in effect, the effective
rate was 6.44%.
Airlines regarded travel agency distribution as cost-effective, without any fixed overhead
costs, and, because travel agencies are found everywhere, a more efficient method of
ticket distribution than was opening their own ticket sales offices.
Other strong incentives were present to direct more sales to agencies, among them the
need to control steadily increasing costs which a regulated environment did not permit to
be fully borne by the traveler. Distribution (or agency) costs can be influenced directly,
unlike fuel, as an example, where costs increased dramatically during these years and
over which a carrier has little direct control. The airline industry also expanded greatly
during these years and needed a broad, relatively economical distribution system.
CRS as Travel Agent Productivity Tools
As manual processing methods do not permit great expansion of most agency
transaction volumes, automation was made available as a tool to raise booking and
document preparation productivity. The almost concurrent development of CRS and so-
called “back room” (agency accounting systems)automation made large regional
agencies and nationa1 chains a reality. A1though large agency networks existed before,
mega-agencies with sales counted in the 10s and 100s of millions are impossible without
automation, specifically CRS.
Value of Tools to the Agency
The primary reason the CRS suppliers are also interested in travel agency accounting
automation relates to the overall effect such automation has upon agency operation and
competitiveness. Because tools are so critical, particularly concerning large agencies, the
vendors perceive significant opportunities to control agent loyalty through access to
these tools. Where the vendor can provide comprehensive automation to the agency,
front and back room, the value chain is strengthened regarding total services provided by
the carrier as is the agency’s overall commitment.
52
This is costs refers specifically to airline City Ticket Offices (CTOs), which are storefront
1ocations handling ticket sales much as a retail travel agency does. Airport processing costs were
somewhat less. Ticket-by-mail programs, never universally adopted by airlines, have consistently
represented the most cost-effective distribution mechanism, but cannot meet the needs of high-
volume business accounts and are also unattractive as some risk must be assumed where tickets
are sent through the mail.
53
The federal transportation tax is currently 10%, making the airline’s effective commission rate
9%.

Sophisticated tools are very expensive for a large agency, making conversions from one
CRS to another much more difficult because of outright costs and retraining expense,
were a conversion attempted. The vendor assumes that agencies receiving full
automation support from a single source (accounting and CRS) are more committed,
financially and practically, to the vendor than is an agency with partial recourse to an
independent supplier.
This has caused most of the CRS suppliers to experiment (some less successfully than
others) with supplying agency accounting system products. The aggressiveness with
which the CRS vendors have pursued backroom agency automation as part of overall
distribution strategies has largely decimated certain segments of the independent
accounting system market.
Teleticketing
As early as 1960, some major airlines began installing teleticketing machines in select
travel agencies. This service was based upon standards implemented by the ATC54
. Any
airline could transmit tickets electronically to any travel teleticket machine by adhering to
these standards. Many, but not all, airlines offered the service.
The machines were modified teletypewriters that were accessed by the airline’s
reservation center using normal telephone circuits. Once accessed, the machine could
print a ticket, using special stock, in between one and three minutes. The most common
(and for many years the only) supplier of teleticketing machines was RCA55
. Agents
purchased the machines and provided the telephone circuit necessary to operate it.
Agencies received teleticket machines under the sponsorship of a major airline, which
took responsibility for ordering and installation of the machine, periodic maintenance56
,
and informing other airlines of the telephone number necessary to access the agency’s
machine57
. Agencies were initially offered the machines based upon their sales volume,
but the practice later became so popular that the smallest agencies used teleticketing.
Travel agencies paid small fees, of between 50¢ and $1.00 (there were several fee
adjustments over the years) for each ticket issued.
The travel agency benefitted because laboriously writing tickets by hand (with not
infrequent errors) could be reduced and because the airline issuing the ticket computed
the price and assumed responsibility for its accuracy. The airline benefitted because
54
Air Traffic Conference of America. An airline industry cartel that set standards (both commercial
and technological) for relationships between airlines and travel agencies, and policed these
relationships.
55
Radio Corporation of America, a pioneer in the electronics industry; merged with General
Electric in 1986.
56
Which was minimal because the teletypewriter machines used by RCA were extremely rugged
and reliable; later machines from other suppliers had more problems.
57
Airlines sponsoring teleticket machines varied based upon the carriers represented in various
markets. Where one airline was stronger than others it usually took responsibility for installing the
machines in select agencies.

agency ticketing errors were reduced and productivity improved, which was important for
reasons just explained.
Teleticketing enjoyed widespread usage until well into the 1980s (past the beginning of
the CRS era). Widespread agency computerization eventually rendered the machines
obsolete, but many were still in place as late as 1985, although new installations had
ceased.
Teleticketing was popular because it was the only semiautomated productivity tool
available to most travel agencies. It was not without problems:
1. Ticket issuance was not instantaneous. The earliest teletickets were composed
using teletypewriter terminals designed for the purpose and transmitted once all
relevant data had been input. Agents usually tried to give an airline 24 hours to
complete this process, as even a “rush” same-day request could take hours.
2. The more technologically sophisticated airlines eventually began transmitting
teletickets directly from their computers but, as pricing software in particular was
not fully developed, manual composition was still frequently necessary.
3. As travel agency ticketing volumes increased, the burden of issuing tickets
centrally became unacceptable for the airlines.
4. While, overall, the teleticketing process was very reliable technologically, there
were frequent mechanical problems, sometimes caused by using 9-part forms
(necessary because airline tickets require this many copies) in the teletypewriter
machines, resulting in misalignments and retransmissions.
5. Not all airlines offered teleticketing services. This was particularly inconvenient
where foreign airlines and frequently complex pricing and itineraries, were
involved.
Airline Reservations in the Travel Agency
It was clear to agents and airlines that substantive agency productivity gains could only
be achieved by making the same general type of automation used by airlines for
reservations available to travel agencies. Initial projects were launched to explore
technological and commercial options through industry trade groups. All these failed
because of government regulatory difficulties, impractical business propositions, or poor
technological vision.
Many airlines made reservation systems available to select agencies, chosen either
because of their value and importance to the airline or simply as test sites, with the first
systems installed by American Airlines in 1968. Trans World Airlines and United Airlines
installed their own systems beginning in 197258
. These early systems were very limited
functionally, as they displayed availability only for the host airline and were more airline
reservation systems than travel agency CRS.
What is a CRS?
Several large airlines have created CRS entities that make reservation and related
function systems available to travel agents. These are specialized online transaction
58
The Trans World Airlines and United Airlines reservation system experiments were discontinued
in 1973, while American Airlines continued to maintain equipment in some large agencies.

processing systems and databases that are specially designed to meet the needs of travel
agents. A CRS provides:
 Airline and AMTRAK (rail) schedules59
.
 Availability for transportation carriers that have agreed to pay booking fees (the
CRS’ primary revenue source) for reservations made through the CRS.
 Fares for services (air and rail) maintained in the CRS Storage of user and
customer-specific databases.
 Communication facilities necessary to support interline reservations and special
service messages (such as seating and meal requests) that users may initiate on
behalf of travelers whose reservations are made through the CRS.
 Storage of traveler reservation files (PNRs) Applications, such as ticketing and
itinerary issuance, that produce printed documentation based upon reservation
files and other CRS data.
These services are adapted for travel agency needs. While the airline’s own reservation
and ticket office operations require similar functions, they are not the same. For instance,
there are very strict rules (federally mandated) specifying how the CRS may display flight
availability, in order to give all airlines participating in the CRS equal access to potential
customers, based upon the merits of their flights (departure, arrival, and elapsed time,
stopovers, and origin and destination airports). An airline is under no such limitations for
its own reservation system and will display availability and schedules for its own flights
to the exclusion of competing services.
Thus the airline’s own reservation system is a different application, even if it shares
computer resources with a travel agency CRS. The early attempts at travel agency
automation preceded the development of the CRS60
and were simply terminals for the
airline’s system.
The First Travel Agency CRS
By 1975 the last of the “industry” system projects, this time an effort called MAARS61
, a
switching system that would allow agency users to be connected directly to it and
conduct sessions in individual airline reservation systems, as desired by the operator,
59
AMTRAK schedules, availability, reservations, and ticketing are offered by the major U.S. CRS.
There are projects underway to make similar services available for European rail services and
ferries, but none has thus far been finalized.
According to John Desmond (Desmond, 1989), Writing in Software Magazine and quoting Max
Hopper, Senior Vice President for information systems at American Airlines:
“The effort to include the trains and ferries of Europe into the reservation systems is a
massive, continuing project. But it is essential to compete in Europe, because so much
travel in that market uses multiple modes. He (Hopper) indicated the situation is analogous
to the 1960s in the U.S., when airline transfers prolonged the minimum two hours
necessary to make a reservation.”
60
Indeed, the concept of a travel agency CRS was not well-defined at that time.
61
Multi-Access Airline Reservation System. Multi-access is discussed in more detail in the
connectivity section of this chapter.

was over unsuccessfully. A multi-access system called MARS62
was eventually brought to
market by ITT, with significant help from Eastern Airlines and a number of smaller
carriers. It was never operationally or commercially successful and eventually folded after
Eastern withdrew marketing support to pursue its own sales for its own CRS product,
SODA63
, later SystemOne.
Figure 1: Relative CRS Market Share
American Airlines and United Airlines began aggressively marketing SABRE and Apollo,
their respective CRS, at this time. Their stated intentions were to invest in travel agency
automation to the extent necessary to establish automated distribution networks
nationally. Both corporations allocated millions of dollars to the project. TWA also
actively marketed PARS at this time, but more on a regional basis.
These three systems were sophisticated travel agency-oriented reservation tools, for the
time, and were free of many limitations that faced earlier efforts. A number of other
airlines, among them Western Airlines (now merged with Delta Airlines), Allegheny
Airlines (now US Air) and Alaska Airlines, offered reservation products to selected
agencies within their primary markets. These were far less sophisticated than SABRE,
Apollo, or PARS and were quickly eclipsed by the superior products.
Demand for CRS automation far outstripped the suppliers’ ability to install and support
the systems, so the largest agencies were selected to receive systems first. Smaller
62
Multi-Access Reservation System.
63
SystemOne Direct Access.

agencies were frequently unable to automate for months after their larger competitors64
.
Once in p1ace, however, the CRS allowed agencies of all sizes and descriptions to achieve
massive productivity gains and support sales volumes previously unreachable.
For example, using today’s CRS environment, good reservations agent productivity in a
commercial (as opposed to leisure) sales environment is $1 million in air sales annually.
Without a CRS, an agent would find it difficult to maintain commercial agent productivity
much in excess of $250,000 annual air sales.
Later CRS Developments
CRS quickly proved itself as a good business and, more importantly, a distribution tool of
unparalleled effectiveness in the travel industry. This motivated Eastern Airlines to market
SODA (SystemOne) beginning in 1981 and Delta Airlines to market Datas II in 1983. Both
vendors started late in the CRS game and found it difficult to build market share,
particularly among the larger business travel agencies that are the most valuable
distributors.
Eastern and Delta did create credible products and were able to protect their own primary
markets from competing CRS to a large degree (the importance of this is discussed later).
Delta merged its system with PARS in 1989, while SystemOne continued to be marketed
independently into the 1990s.
Figure 2: CRS Market Share Trends
64
It is interesting to note that some of the first CRS installed nationally were placed in commercial
accounts (corporations with large travel volumes and in-house travel arrangers), rather than in
travel agencies. This was also true for many of the first teleticket machines.

Aggressive marketing and product sophistication allowed SABRE and Apollo, in that
order, to establish the largest market share of any U.S. CRS, followed by PARS as a
distant third. SystemOne and Datas II, when introduced, took market share from each of
the earlier three, with a slightly greater percentage coming from PARS. SystemOne
exceeded PARS in number of installed CRTs by 1987, although not in booking volume,
due to the somewhat larger average size of PARS agencies. PARS installed base
recovered rapidly, due to ongoing operational and business problems at SystemOne.
CRS Bias
After travel agency automation became an accepted business tool, the CRS recognized
that manipulating screen displays results in incremental bookings, for one carrier at the
expense of another, depending upon how the screen display is influenced. Between 70%
and 90% of airline flights booked by a travel agent are reserved from the first CRS
availability screen displayed, assuming the agent’s initial availability request was
accurate, with 50% of flights being booked from the first line of the first screen. In a
competitive industry, where product differentiation is often tenuous, some CRS e1ected
to actively influence agent flight selection based solely upon screen management.
So-called screen bias in the Apollo and SABRE was well-documented, while PARS and
SODA were less overt and DATAS II used its unbiased nature as a point of competitive
differentiation.
Extensive user and consumer pressure eventually lead to the introduction of federa1 CRS
standards that eliminated the most overt forms of screen bias. Some experts believe that
displays can still be manipulated,65
but certainly to a much lesser degree than in the past.
Bias is discussed in greater detail on page 40 of this report.
BASIC CRS OPERATION
The following sections illustrate basic CRS operation by following a typical transaction
from beginning to end. The SABRE system was chosen for these illustrations; however
the similarities between PARS-type systems will make the examples applicable to most
other CRS. The examples also assume that a travel agency, and not a corporate travel
manager or airline reservation center, is using the system, and that the most current
hardware and software releases are available.
Sign-On
Most travel agencies do not “power-down” their CRS equipment overnight. Restarting
the LAN, once an installation is completely shut down, can be difficult and requires some
expertise. Most suppliers also believe that normal hardware “wear and tear” is reduced if
restarts are minimized66
. No CRS start-up procedure is usually needed.
65
One way this is said to be done is through manipulation of display algorithms and flight times.
66
This fact is clearly demonstrable in medium and largersized computer installations. A complete
power-down for many large computer centers would create problems of near disaster proportions.
The effect is far less clear with small systems. In the authors opinion, regular power-downs of
small computers is not harmful and probably prolongs equipment life for two main reasons: (1)

The agent’s first step is to LOGON to the system. This is a two-step process which
involves a unique operator identification code and a password. While this is the most
obvious level of security, there are others.
Each CRS user location is assigned a unique identification code, termed a pseudo-city
(PCC) because it is not a true “city” code, as far as an airline is concerned. A CRS city
code is a unique identifier that is assigned to each airport location the carrier serves. A
pseudo-city, therefore, identified a physical location that is not an airport.
A PCC is a 4-character alpha-numeric string67
. Normally only a single PCC would be
assigned to each agency location, but some installations requiring special services, such
as multiple communication circuits, may have several. The PCC allows the CRS to route
reservations (PNRs) to electronic files, known as queues that belong to the location. The
PCC also identifies reservations made by agents working at the location so that agents
from other PCCs cannot access the same PNRs, unless that access has specifically been
authorized by the agencies involved and the CRS.
This process is known as cross-access or bridging, depending upon the CRS. There is
normally a monthly charge for each crossaccess privilege open.
Each reservation created or modified by an agent is marked by the PCC of that office. If a
reservation was created by one agency and later transferred to another, as customers
occasionally request, the “ownership” of the PNR follows the last agency to modify the
reservation.
Security
Travel agencies are concerned about security. They believe that their PNRs should not be
accessible to agents they do not authorize. There is considerable evidence to support the
claim that even non-malicious “snooping” can create financial or perhaps worse,
customer relations problems for an agency. An unscrupulous competitor might try to
solicit new customers based upon information gained from examining PNRs, for
example. While CRS security is a real travel agency problem, its actual effects are
probably overstated.
The CRS have developed security procedures, such as those outlined above, which are
sufficient to prevent most forms of unauthorized access. Similar measures are in place at
the sophisticated CRS, although these vary considerably in their composition and
effectiveness. In most CRS travel agents cannot view:
Small computer mechanical devices, such as hard disk drives in particular, are far less robust than
those designed for larger systems and suffer due to extended wear; (2) Office (and home) power
conditions are not nearly as well conditioned as are large data centers, which makes office
systems much more vulnerable to power surges and other anomalies if they are left running
unattended for long periods.
67
SABRE uses 4-character PCCs; other CRS use three.

 Reservations created by another travel agency using the same CRS, where no
cross-access is authorized.
 Reservations created by another travel agency using another CRS
 Reservations created by the host airline’s own general reservations center-
although some CRS do allow agents to access these reservations.
For obvious reasons, airline reservation centers, ticket offices, and CRS support staffs can
access any reservation created by any travel agency.
Transaction Synchronization
Once initial SIGN-ON is complete, the agent is working in what is known as an AAA68
or
Agent Assembly Area. “Agent” in this sense refers to any CRS operator as an “agent”.
The AAA is a short-term electronic file where the elements of the PNR, the passenger’s
actual reservation, will be “assembled.” This is a key concept in CRS operation. Each
agent, when signed-on to the CRS properly, has several AAAs available for use. The
agent can toggle between them at will, and have reservations in various stages of
completion in each -all functioning totally independently. The agent cannot move
reservations or information between the available AAAs.
All work that a CRS “agent” does in a session is completed only in the AAA until a
specific CRS “event” is invoked. This means that the agent can reserve flights, seats,
special meals, and enter all other required parts of the PNR prior to permanently
modifying the CRS’ major databases. In other words, the work the agent does is
temporary—it exists only within the AAA until it is made permanent.
The agent does this by ending the transaction, that is, closing the AAA and updating the
databases that will be affected by work previously done in the AAA. Each CRS has an End
Transact (ET) button or command string (as in SABRE) for this purpose. Nothing done in
the AAA is permanent until the “ET” event takes place.
This CRS process is both a valuable feature and a significant inconvenience. In fact,
however, the CRS could not operate effectively without it. One ongoing challenge for all
online transaction systems is transaction synchronization. The temporary nature of CRS
work helps to address this challenge.
Reservations that the agent desires to modify must be retrieved into the AAA. As with
new reservations, no change made to the reservation is permanent until ET. If another
agent, perhaps from the airline or from another authorized travel agency location,
displays the same reservation and begins to modify it, a conflict must result- which one is
working with the “real” reservation? This conflict can also be programmatic from within
the CRS. If an agent is modifying a reservation while an SSR message is sent from an off-
line carrier or while a schedule change comes through, that agent is no longer working
with the latest version of the reservation—any changes made might be irrelevant, based
upon the new information.
The CRS resolves this conflict by saying that the first agent (or internal CRS process) to
remove a PNR where potential conflicts exist by ET has created the latest version of the
reservation.
68
Termed “The Triple A.”

Other agents working with the same reservation can continue to make changes in their
AAA, but the CRS inhibits ET by sending the “simultaneous changes” response.
SIMULT CHANGES TO PNR69
Once this condition is created, nothing agents can do will allow the system to accept their
changes, because these were made on a version of the PNR other than the “latest.” If a
great deal of work has been done, this can be a frustrating experience. The agent must
invoke another CRS command, “Ignore” (I). This clears the AAA and allows the agent to
retrieve the reservation and begin the process over again.
All changes or reservations made in the AAA when “I” is invoked are “ignored”.
Reservations and seats return to inventory, and nothing is stored from that session in any
CRS database. This applies only to host seats and inventory. When working in the AAA
on the host carrier’s flights, desired inventory is pulled on a provisional basis. The host’s
availability listings are reduced by the number and nature of services reserved in the
agent’s AAA. Thus, if there was 1 seat left on AA flight 1 for a certain date, 0 seats would
be shown as available once a reservation for 1 person had been started in an agent’s
AAA. If a reservation in progress is “ignored”, 1 seat is returned to inventory.
If an agent is forced to “ignore” prior to completing the transaction, there is a possibility
that the same services (flights or perhaps individual seat assignments) may not be
available when, the process is attempted again. This does not apply to “offline” inventory
and seat assignments, as the CRS does not send sell messages to other systems until ET-
unless certain forms of direct access are used (explained later).
On the other hand, “ignore” can be valuable. If a traveler requests cancellation of a flight
so that alternate reservations may be made, the exact services desired frequently are not
available and the traveler decides to “stick with what they have”. Since all AAA changes
are provisional, the agents only has to “ignore the transaction” to return the PNR to its
last state.
Manipulating the AAA
The AAA may be displayed by the agent at will. In SABRE this is done by using the *A
command, where * is the “display” character and “A” the delimiter for “all”, meaning all
data in the AAA. If the command is invoked without a reservation in progress occupying
the AAA, the response “NO PNR IN AAA” is generated. Agents may also display parts of
the data in the AAA, such as “name,” “itinerary,” “passenger data," and so on, by using
the appropriate code. These commands are used because lengthy itineraries may be too
large to display on one CRS screen, and the ability to segment parts of the AAA for
display as necessary makes the transaction easier to manage.
Other parts of the PNR are not normally displayed and must be specifically requested.
Once a PNR is changed after its initial creation, a “history” file is added that contains a
complete listing of all changes made to the reservation, in descending chronological
69
“Simultaneous changes to PNR.”

order. The agent uses “history” where there are questions as to why a reservation was
modified or who authorized the modification70
by invoking *H.
Once the AAA is occupied by a reservation in progress, that reservation must be ended
by ET or I if it is a new reservation or if changes of any type are made to an existing
reservation. If the agent tries to display another existing reservation before this is done
the response “FINISH OR IGN PNR” is generated. If no changes have been made to an
existing reservation, that PNR is automatically “ignored” when a subsequent request to
display an existing PNR is initiated.
Text Reference
Once logon is complete, SABRE displays one or more brief informational messages that
may be of use to agents. These are usually changed daily, but may be changed at will.
Their purpose is to bring information to the operator’s immediate attention that might
otherwise be overlooked, such as a major air traffic system or weather delay, a labor
dispute that will disrupt air service, or particularly in the age of deregulation, the
bankruptcy or cessation of operation of an air carrier.
These specialized text messages are related to the CRS’ general or Direct Reference
System (DRS), which may be invoked by the agent at will, even while transactions are in
progress in the AAA. The DRS is a very simple text-based file system, which is used to
store information that is supportive of CRS operation but that does not require frequent
updates, such as availability or flight information (scheduled arrivals), which changes
constantly. Some typical DRS examples include:
 Marketing messages from airlines, hotels, car rental companies, and others that
participate in the CRS and pay a fee for the privilege of including information on
selling their products through the CRS. Information about the products may also
be included.
 Immigration and visa information.
 Ground transportation from major airports to the cities they serve.
 Local weather conditions71
.
 Information on shows found on Broadway, in London, Atlantic City, Las Vegas, or
Reno.
 Information on the correct operation of the CRS itself.
DRS “pages” are displayed by referencing their location within the filing system by
means of a unique character string. The CRS then copies text from that “page” to the
screen originating the request. Data in the AAA are not affected. This is done so that
agents may break their work flows to answer customer questions or obtain information
70
Passengers may be unhappy if reservations during peak periods of demand are canceled, for
instance. A complete “history” file makes it possible for the agent to inform the passenger of the
date, time, and individual who authorized the change, thus relieving the airline or other CRS user
from responsibility for unsatisfactory reservation changes.
71
These displays are updated frequently—usually several times daily. Some CRS have weather
information systems that operate independently from DRS.

required to complete a transaction in progress, then return to that transaction without
losing continuity with whatever work was underway.
Help System
DRS is not the only way a modern, sophisticated CRS, such as SABRE, has to make
information on its correct operation available to users. A text-based “help system” is
often available for operator reference.
FOX, SABRE’s help system, is illustrative. FOX is not context-sensitive, in that it cannot
reference work in progress in the AAA and suggest commands or procedures based upon
the transaction presently before the operator. Individual FOX text “pages” must be
referenced directly by the agent.
FOX differs from ordinary DRS in that more complex commands, employing keywords,
are used to locate desired pages. The agent builds strings of related words so that
searching for the desired page is greatly reduced. Once an initial FOX page is retrieved,
the agent is directed to additional references containing more detail.
Reservation Process Flow
The CRS agent begins work on a transaction by requesting availability of flights, based
upon the traveler’s particular needs. Usually air availability is requested prior to cars and
hotels, with the air itinerary forming a shell around which added services may be
deve1oped, a1though a PNR need not necessarily contain air reservations.
Cars and hotels are the other large availability systems within the CRS. They operate
separately from the air availability system, although many of the same principles are
employed.
In any major CRS, the ratio of car reservations to air reservations is very low, and the
ratio of hotel to air reservations still lower. This is partly because the availability and
reservation environments offered by the CRS for hotels and cars are very limited and
imperfect, but it is too simplistic to ascribe limited CRS use in these areas to functionality
alone. The simple fact is that travel agents, the primary users of CRS, do not routinely
make (or even offer) hotel reservations to their customers- CRS-based or otherwise. This
is a selling deficiency and predates the introduction of CRS in travel agencies.
The basic SABRE availability screen is displayed by forming a command string beginning
with the 1 delimiter, followed by the date of travel, cities for which availability is
requested and a desired departure time:
120JANJFKLAX7A
The CRS responds with an availability screen that is organized based upon algorithms
and display criteria unique to that CRS, and that are designed to display schedules that
will be more desirable to the passenger first. Thus non-stop flights are shown before
flights with stops, and direct flights (non-stop or otherwise) before connections where
p1ane changes are involved. Schedules with the least (scheduled) elapsed travel time are
also shown first. The availability display also indicates what type of aircraft is used for
each flight and a numeric grading, based upon U.S. Federal Department of Transportation
data on flight timeliness. The number of stops made by individual flights, if any, is also
shown.

In the accompanying illustration, American Airlines flights (the “host”) show 9 seats as
available for each class of service offered on the flight. If less than 9 seats are shown,
then that number represents the exact number of seats allotted by the airline to that class
on a specific flight. Offline flights show either 4 seats (the maximum number that can be
sold under the “sell/no-sell” conventions used by the CRS)72
, or 0 seats, if availability has
been closed for that flight and date by the airline in question.
If no flights meeting the traveler’s requirements are displayed on the first availability
screen, the agent may request numerous subsequent screens until the optimal flight is
located, based upon the CRS’ internal availability logic, these screens are offered in
generally descending order of flight desirability.
The several classes of service are indicated by letters accompanying the number of seats
available in that class. An individual airline determines what classes will be displayed for
each flight. These “classes” are mostly for inventory control purposes, in order that the
airline may allocate a given number of seats for discount or promotional fares. There are
usually only two physical classes of service on an aircraft - first class and coach class;73
all
other discounts sit in the coach cabin. Some flights add a third “business class” to
specific flights, which represents a differentiated physical service on the flight and
normally is not open to discounts or promotions74
.
Agents access inventory in what we have described generally as an online, real-time
environment. Under such conditions, when seats are reserved, inventory is decremented
and the same space cannot be sold to another system user unless a cancellation ensues.
Airline inventory is defined as seats available to be sold on any particular flight segment,
as determined by the actual number of seats on-board the aircraft together with inventory
management adjustments - upward or downward—that compensate for anticipated
conditions such as necessary overbookings due to no-show experience on the route.
When reservations are requested for the CRS supplier or user host, inventory is
instantaneously decreased by the required number of seats.
Off-line carriers, those with their own inventory systems that are not part of the CRS host,
operate in a sell/no-sell environment. The CRS user may “sell” typically up to four offline
seats in any one transaction. The “sale” is recorded in the agent’s AAA until an ET is
initiated. A sell message is then transmitted to the computer system where the inventory
72
More than 4 seats could be “requested.” This means that the agent could initiate the transaction
and wait for a teletype writer message from the airline in question to verify that the number of
seats required had been reserved. In such cases, reservation confirmation is not automatic.
73
Outside the U.S., coach class is referred to as economy class.
74
Business Class is a compromise between first class and coach or economy class. It lacks the full
set of in-flight amenities found in first class, but is still a grade above coach. It is intended to
appear to business travelers where budgets may not tolerate first class fares, but where a
comparatively modest fare differential for business class may be acceptable.
Business class seating is very popular on international flights, where long distances make the extra
amenities attractive.

Airline Reservation Systems

Recommended

Recommended

More Related Content

Similar to Airline Reservation Systems

Similar to Airline Reservation Systems (19)

More from Dustin Pytko

More from Dustin Pytko (20)

Recently uploaded

Recently uploaded (20)

Airline Reservation Systems