In 1953, a chance meeting between an American Airlines executive and an International Business Machines executive led to an agreement to develop IBM's Semi-Automated Business Research Environment, or SABRE. After the expenditure of $40 million, the system went online in 1960. This date should really be more familiar to students of computer history than it is, because you could say that is when the computerized database transaction and online transaction processing were born. SABRE did not use a relational database and its transactions would perhaps not conform strictly to today's definition of atomic, consistent, isolatable, durable transactions, but it was the incubator in which those concepts were first nurtured.
The SABRE database had one record type, and it was called the passenger name record (PNR). Existing computerized airline reservation systems still use PNRs today. All passengers in a PNR must be travelling on the same itinerary, but the number of passengers can vary, and the number of flight segments in the itinerary can also vary. When SABRE came into existence, it used an identifier called the record locator to identify a booking. The locator is a base-34 encoded physical disk block number specifying where the PNR could be found. (To avoid confusion between the digits zero and one and the letters O and I, zero and one aren't used in PNR locators -- just 2 through 9 and A through Z.)
You might assume that record locators are globally unique, but they are not. If you have a booking which involves more than one operating carrier (an interline or codeshare booking), each additional carrier has a shadow PNR which is a copy of the PNR in the system through which the booking was made. The shadow PNRs will have record locators which are different from the original PNR. When carriers send messages regarding bookings among themselves, they specify an IATA carrier code along with each record locator to say which carrier's locator they are using.
Many of the messages (specifically, all of the booking messages) which carriers send one another are still in AIRIMP format today. But AIRIMP is not an adaptable format. It has two elements which have been used to expand the information you can send: the Special Service Request(SSR) and Other Service Indicator (OSI). The SSR element was originally introduced to indicate that a passenger needed a special service, such as a vegetarian meal, or a wheelchair. The service being requested is specified with a four-character code, such as VGML or WCHR. As time went on, SSR codes were added for passport information, ticket numbers, group booking information, and so forth. SSR formats are designed to be meaningful to the computer systems which transmit and send them, but OSIs are (almost) completely free-form elements typed in by humans and intended to be read by humans.
Despite these escape mechanisms in AIRIMP, it became clear that AIRIMP would not serve for the messages which are exchanged during the booking process prior to the final establishment of the reservation. There's no easy way in AIRIMP to ask, "Do you have four seats available for Boston to New York on next Tuesday afternoon? Where in the cabin are those seats located?" So airlines began using a United Nations standard called Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT) which came into existence in 1989. EDIFACT has a formal grammar and a mechanism for users to create specialized dialects. The airlines created a dialect called Passenger Data Interchange Standard (PADIS) for messages relating to flight availability and seat map information. PADIS can also be used to complete a booking by embedding an AIRIMP booking message in an PADIS message!
AIRIMP messages are guaranteed by the carrier (typically ARINC or SITA) to be delivered to eh recipient (to the extent that we can guarantee anything in this world). But, as used by the airlines, EDIFACT messages come in pairs: every request is expected to trigger a response. So EDIFACT messages don't require as strong a guarantee of delivery as AIRIMP messages, and the airlines don't have to pay quite as much per character to have ARINC and SITA deliver them.
The airlines invented another dialect of EDIFACT called IATCI (pronounced eye-atch-ee), for Inter-Airline Through Check-In, in 1991, to save passengers the hassle of having to check in separately at each connection in an interline itinerary. I don't know why they didn't simply invent new PADIS messages.
Remember paper tickets? Ticket processing was gradually transferred to computers independently of the processing of reservations, and it was very strongly driven by the manual processes that airlines had used to process paper tickets. When an agent issued a paper ticket, the front page of the booklet went back to the validating carrier (as indicated by the three-digit prefix of the ticket number) along with a payment from the agent. The second page was retained by the agency for their records. The flight coupons would meander back to the validating carrier as well, as the passenger travelled the ticketed itinerary. In the case of interline tickets, the operating carrier would receive a settlement payment when it returned a flight coupon to the validating carrier. Needless to say, there was a lot of labor involved in shuffling paper tickets around from one place to another. The airlines formed a company, Airlines Reporting Corporation, just to handle the movement of flight coupons as they were lifted from passengers' ticket booklets to be returned to the validating carrier and reconcile the settlement payments.
The paper ticket continued to be the definitive documentation of fare payment up until electronic tickets were introduced in 1995. At that time, some tickets were "issued" solely as electronic records in the validating carrier's computer. In the beginning, they were not as flexible as paper tickets, because there was no mechanism for one carrier to ticket another carrier's flight electronically. To change your travel plans to a different carrier, you first had to get the validating carrier to issue a paper ticket (known in the industry in this situation as a flight interruption manifest), and then take it to the carrier whose flight you wanted to use. But with the increasing use of e-tickets, the airlines invented new PADIS messages which could allow the transfer of coupon control from one carrier to another.
PADIS messages aren't guaranteed to be delivered, but they are required to be acknowledged. To protect against mixups when a coupon control request or acknowledgement message went astray or was dropped in transit, a carrier surrendering control always assumes that the transfer was successful, but a carrier requesting control never assumes it has control until it receives an acknowledgement of its request (or has sent an acknowledgement of another carrier's request). This means that a coupon can end up in limbo -- a problem with immediately obvious consequences which can be fixed by manual intervention -- but two carriers never get control of the same coupon at once (which can result in a passenger getting two trips for the price of one, in the worst case).
Are you wondering when you last dealt with SITA, the ninth company on the list I gave you two months ago? No one has tried guessing the answer (though, separately, Peter Samson has promised to send me a postcard from QPX as soon as he gets there). SITA came up with the idea of installing airport computers which could connect with a wide variety of carrier computer systems, so that one gate could be used by different agents for flights operated and ground handled by more than one carrier, making it unnecessary to install proprietary equipment for each carrier which planned to use the gate (or to change out equipment when the gate was leased by a new carrier). SITA dubbed this equipment Common Use Terminal Equipment (that's right, CUTE, though more recently, it has been renamed Common Use Passenger Processing System.) And in the last couple of years, CUTE/CUPPS systems have also been used for those check-in kiosks where you can get your boarding pass without the assistance of an agent. Almost all kiosks and check-in agent systems are owned and operated by SITA at this point.
Happy New Year! The weather dumped a blizzard on us earlier this week, but fortunately we did not need to go anywhere and our power did not fail. I have updated my model railroad page, reflecting the occurrence of my inaugural operating session.
Best wishes to all!