Reservations under UNIX - You're Kidding
by Bruce Taylor

ACP/TPF came into existence because airlines needed automated reservations systems at a time when state of the art computer technology was not capable of providing such a thing. The trials and tribulations of those pioneers who created the first systems in the late 1960's are well recorded and were recently paid respect at the 25th anniversary meeting of the ACP/TPF User Group in New Orleans.

With all due respect to the non-airline TPF users, who now account for 50% of the user community, the business demands of airline reservations created TPF and drove its development over the majority of the past 25 years. The success of IBMB PARS system, in combination with the failure of other manufacturer efforts of the time, provided a committed global user base ensuring continuity which has proven unassailable for over 2 decades. It ensured predominance for IBM and TPF in this market segment. Univac, come Burroughs, come Unisys, did later make inroads into this market with the USAS product, but never did succeed in removing IBM from its entrenched position.

TPF is all about high volume, real-time transaction processing; it is the major airlines which explore the outer limits of those performance capabilities. All airlines need to do reservations, but not all airlines have the volumes to demand or financially justify a PARS-type solution. A PARS (or USAS) solution is an expensive business to set up, an expensive business to run and an even more expensive business to change or enhance. All airlines would like to have exclusive, in-house control of their own inventory, their own travel agents, their own yield management process and their own market intelligence; only a fraction of the airlines (the "big" guys) could afford the technology to do so. To justify it, one had to have several million passengers a year: how many million depended on when you asked the question and which consultant you asked it of. Nevertheless, in this context there are a lot more "little" guys than there are "big" guys; probably 10 times as many.

So, what did the little guys do? They:

• Struggled on with manual procedures.
  
• Bought a PARS or USAS type system anyway, either based on optimism about future revenue growth, or based on considerations of (national) prestige.
  
• Went hosting in a big guy system.
  
• Went hosting in a neutral, third party system.
  

Were they happy? Did they have control? Could they get at what they wanted when they wanted it? I leave those questions for the readers to answer. PARS and USAS are wonderful accumulations of man-millennia of collective effort and they serve the purposes of those who can afford them superbly. Those who could not afford them, or who could not sustain the effort of maintaining and enhancing them, were at a competitive disadvantage.

A lot has happened in the IT technology since ACP/TPF came into existence over 25 years ago. Most of what has happened has been at least 90% hype and at most 100% substance. However, in my view the exponential development of cheap desktop computing power over the recent past has changed the basic parameters of our industry. The mainframe is far from dead but it will never again be the exclusive solution to all automation problems and equally not the only reservations solution. This, combined with the growing popularity and rapidly increasing sophistication of distributed, client-server architectures, led us late in 1991 to join with a Swiss group who were proposing to develop a new generation reservations system: ReserVision - The Swiss group. DTP, who set up a separate company which owns the product, were already owners or part owners of a variety of companies developing and distributing specialized hardware and software products in the travel industry, primarily in the PC/Workstation arena. The ReserVision product had two vital prerequisites for its development:

• Knowledge of and detailed experience with the structure, components, tools and capabilities of interconnected LAN's with UNIX and PC-DOS workstations and servers. This came from DTP.
• Intimate knowledge of and detailed experience with the functional and technical requirements of airline reservations systems, both internally and externally, and their relationships to GDS's/ CRS's. This came from Hyperion.

As basic technical premises for the construction of the system we had:

• as little programming as possible
• all software components to be industry standard
• no proprietary hardware or software platforms
• exclusively SQL databases
• nothing in the system which was not readily available and supported worldwide
• built to last through the anticipated development frenzy of the standard hardware and software component suppliers

As basic business premises for the construction of the system we had:

• the initial marketplace is to be restricted to airlines up to approximately 1 million bearded passengers per year until the performance characteristics of the system are proven
• an order of magnitude less cost to purchase "all-in" than an entry-level mainframe TPF/USAS system
• designed to run your airline network, and your airline network only, including "captive" travel agents (i.e. only: your schedules, your availability, your inventory, your tickets, your fares, your frequent flyers, etc.)
• anything not involving your own airline network facilities exclusively requires interaction with a GDS or CRS host
• connection to a GDS or CRS host must not require any technical work on their part beyond the provision of the communications port and access to the information necessary to determine how ReserVision has to behave towards that system

Having beavered away for two years in Zurich with a small team (small in numbers, but unique in terms of tie combination of functional and technical expertise which needed to be applied to the problem), the first beta-test release of the product went to the first beta-test customer in September of 1993.

Looking back on the past two years we see that the workstation and client-server technologies have continued to develop at an ever increasing pace. This gives me every confidence that the platforms we have chosen are here to stay and that our system will mature and spread. The big guys of the reservations world can only drool over what ReserVision can do for the end users and the speed with which new function can be created. This has nothing to do with UNIX or PC-DOS and everything to do with the standard packages and SQL relational databases in the hearts (N.B. explicitly plural) of the system. Performance is a different issue: "the proof of the pudding is in the eating"...

Bruce Taylor, Managing Director
Hyperion - Amsterdam (Netherlands EEC)
Tel. 31-20-647-6161
FAX. 31-20-647-4256