IT and Communications in SAS

Abstract

In 1946, when Scandinavian Airlines System, SAS was founded, there were no electronic computers. All tasks were done by industrious hands and brains. They did a good job, but the increasing number of airplanes and passengers forced SAS to look for electronic computers. SAS Data was founded when SAS acquired its first computer in 1958. Over 3 years SAS Data implemented 3 electronic systems and added 2 new terminals (Agentset and Keyset) to the existing teletype writers. The existing Telegram Center and the three electronic systems SPAS, RAMAC and ZEBRA were interconnected, and a system was built that could do Space Control, Reservation, Booking, Check-in and Load control. Traffic information systems, based on teletypewriters at all gates and in most departments at the airport and many other systems to improve the efficiency, were developed and implemented in the following years. Key aspects of these developments up to year 2000 are described. Most of the systems and applications built and implemented by SAS Data were made to increase efficiency and reduce the human factor. They would never have been implemented if analysis did not reveal a profit, and they helped SAS to be an Airline people wanted to use. SAS would probably not have existed today without these early and groundbreaking ICT solutions.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The present paper is based on material written by members of SAS Data Senior Klub (SDSK).

SDSK is an association for retired or elderly Danish employees of the SAS Data/Scandinavian IT Group or whatever the former Scandinavian Airlines IT company has been called over the years. SDSK has a working group that strives to preserve old equipment, documents, and anything else that can describe the activities of SAS Data, and also describe how Scandinavian Airlines System has used IT through the ages.

A number of SDSK members have compiled parts of the early SAS Data history, based on recollections from former SAS Data employees. I have picked out the most important parts, describing how SAS’s IT environment was created and grew to become one of the major data centers in Europe. This paper is thus solely built on knowledge from the people, who formed the Scandinavian IT company SAS Data. See also [1–4].

2 Before EDP

SAS was founded by the three national Scandinavian airline companies in 1946. At that time there was no need for Electronic Data Processing (EDP) as such and no dedicated systems available. Instead the airlines all over the world communicated with each other and airports by means of teletype readers/writers and electronic transfer of telegrams. The booking office in SAS communicated mainly in this way with sales offices around the world. All departments in SAS had to modernize and expand in line with the growth of SAS. But for the booking office there was a limit.

3 SAS Data, 1958–2004

The company started as a project organization when Scandinavian Airlines System (SAS) acquired its first computer in 1958. After 45 years as a leader in its class SAS Data was acquired by CSC and became “CSC Airline Solutions”.

4 The First Electronic Systems

Up to the late 50s the 12 SAS booking offices all over the world sent their bookings to the central booking center in Copenhagen for manual processing, but the booking center – with a skilled staff - was not able to control the many reservations. This meant poor control of what was sold and what was not sold, and it caused chaos around certain flights, for example if too many seats were sold. This was very expensive for SAS. The idea of getting help from EDP, Electronic Data Processing, was born. They had heard of a company in Stuttgart…

4.1 Space Availability - Standard Electric Lorenz “SPAS”

SAS decided to acquire an “electronic brain”, and this marvel became Europe’s first electronic reservation system. It was also the first real-time system in SAS. It was called “SPAS”, Space Availability System, and was built by Standard Electric Lorenz. “SPAS”, a special purpose computer, worked by means of 8,000 transistors and could immediately tell the local booking terminal “Agent Set”, if there was space available on a flight or not. So far there was only a single terminal type in SAS. Now there was suddenly one more, Standard Electric Lorenz “Agent Set”. It was used in sales offices and travel agencies worldwide. In the beginning you could only get to know, if there was availability for the desired aircraft. Later you could reserve seats on the plane, but such an operation should always be confirmed to SPAS with a telegram from the Booking office.

Thus we had taken a significant step forward, and we could now make use of the seat capacity of the aircrafts more efficiently. All this happened in 1958.

4.2 Space Availability Control - IBM 305 “RAMAC”

SPAS did not solve all problems. There was still no automatic control of the number of seats available on an airplane, and it could cause some flights to depart with empty seats, although other offices might have sold them. A space control system on an IBM 305 “RAMAC” was implemented in late 1960 to solve the problem. RAMAC was connected to SPAS and later on to a new system called ZEBRA.

4.3 Load Control and Check-in – STANTEC “ZEBRA”

For the purpose of load control (weight and balance control) a British built and tube based STANTEC computer nicknamed ZEBRA became operational in 1961. Before the ZEBRA came along, we were following a certain procedure for each flight:

“Shortly before departure check-in closed, the “manifestation-function” was in a hurry to summarize the number of passengers, divided into men, women, children and infants, and the baggage count and weight including any hand luggage. All were of course counted per class and destinations on the route. The figures were then quickly passed on to the traffic officer, who was responsible for calculating aircraft weight and balance conditions, which were subsequently documented on a “load sheet”. All documents for the aircraft were put into a “Log Bag” and a traffic employee brought the “Log Bag” to the aircraft, on a bike if necessary. The traffic employee addressed the captain in the cockpit, where the information was reviewed, and the captain signed. Then the flight was ready to go - unless they in the last minute had to take some late passengers into account and add a “last minute changes” (LMC) on the load sheet”.

ZEBRA now took care of all these tasks and produced a ‘Load Sheet’. “Check-in” of passengers and their luggage was performed from refurbished desks in the departure hall. This introduced another new terminal, which was called a “Key Set”. The terminal resembled an Agent Set and functioned in much the same way. The answer given by the “Key Set” was one or more coloured lamps - green for OK, red for rejected (no available seats) and yellow with a few numbered lamps lit, indicating standby and standby number.

4.4 Coordination of Systems

The three new systems, SPAS, RAMAC and ZEBRA, were interconnected and also connected to the Telegram Center. All telegrams that were previously sent to the manned booking office were now sent to “SPAS”. The three machines handled “Space Control”, “Reservation”, “Check-In” and “Load Control” (Fig. 1).

4.5 Airline Collaboration

SAS Telegram Centers were created earlier on and connected in a worldwide network. SAS and Swissair had made an agreement, which made their Telegram Centers part of a common network. Each centre was managed and operated by one of the companies, SAS or Swissair. Telegram lines were expensive, so the airlines had to be creative. By utilizing each others’ centers, both parties saved money.

Fig. 1.

The interconnection of SPAS, RAMAC, and Zebra

5 SASCO I - February 1965

A plan to integrate the three systems SPAS, ZEBRA, RAMAC and the semi-automatic Telegram Center on an IBM 1410 “dual system” for Reservation and Load Control was now realized. The whole thing was put into service in February 1965 in the presence of IBM CEO Thomas Watson, whose father had started IBM, SAS CEO Karl Nilsson and Mrs. Helle Virkner, wife of Prime Minister J.O. Krag. She pressed the button that started the new era.

The system was installed on the 2’nd floor of Copenhagen Airport (now Terminal 2), and named “SASCO 1”. It had been programmed to do the same as the ZEBRA could - and a whole lot more, including automatic balance calculation, load control (weight and balance), payroll and other administrative tasks. The IBM 1410 machine was running virtually around the clock, and traffic schedules were not loaded - as with the ZEBRA - in the computer every morning, but only twice a year. Moreover, the 1410 machine could operate airports other than Copenhagen, first Stockholm followed by Oslo and later Gothenburg.

SASCO 1 was assigned 300 Agent Sets/Key Sets operating in 21 cities in 14 countries and 4,000 teletype machines around the world. The computer was also programmed to monitor all SAS flight arrivals and flight departures. This information was notably transmitted to Copenhagen Airport. SAS still supplies airports with Arrival and Departure times.

6 Farewell to the Telegram Centre

The Telegram Centre handled 25,000 telegrams on papertape a day. Thus it had the position as the largest privately owned Telegram Centre in Europe.

40 operators took care of dispatching telegrams through the teletype equipment. They worked around the clock. 80 % of the telegrams were traffic ticket bookings, 15 % were of an operational nature (for example reports of aircraft arrival & departure all over the world), and 5 % traffic were of an administrative nature.

7 More Electronic Computers Added

7.1 Message Switching Computer - MESCO

As traffic was at its peak in the mid-60s, the Telegram Center in Copenhagen handled approx. 25,000 telegrams a day. The manual handling had its natural limits, and efforts were deployed to make the expedition of telegrams computer based, which happened from 1967 to 1969.

The first Message Switching Computer (MESCO) was implemented in Stockholm in 1967, Copenhagen followed in 1968, while Oslo was implemented lastly. All three systems were based on UNIVAC 418 computers. The transmission from telex machines and Agent Sets were still on the old teletype lines, but the transmission rate had increased to 100 baud in most places. The 3 MESCO centers were associated with 2400 baud data lines. MESCO were also able to handle traffic via dial-up telex connections, as opposed to the teletype printers connected to a dedicated line. SAS were the first in the world to introduce such systems. We simply switched all terminals throughout the SAS system into MESCO and DASCO, resulting in significant savings and provision of very fast and efficient communication.

MESCO meant a farewell to the Telegram Center after 24 years of service, but not to the people who had worked there. Their experience and knowledge was needed in the wake of this development.

7.2 Data Switching Computer – DASCO

While MESCO systems only took care of telegram traffic, the Agent Set traffic shifted to a Data Switching Computer (DASCO). DASCO computers were installed in Copenhagen, Stockholm and Oslo, and served as front-ends to the application computers SASCO II (UNIVAC 494), discussed in the next chapter.

DASCO computers were connected to teletype lines for input/output to the various applications that were introduced in the SASCO complex. Examples of applications are booking, check-in, weight and balance, cargo and spare parts. DASCO and MESCO were both based on UNIVAC 418 computers. MESCO served as a switch for store and forward messages (telegrams) which do not need so fast transfer. DASCO took care of enquiry/response traffic which needs faster transfer.

8 SASCO 2 - Univac 494

IBM had promised SAS, that the 1410 could be extended to a capacity twice as large as the one we needed in 1965. At the end of the day, IBM had to admit that they could not deliver this extension. SAS Data began to look for a replacement. In 1968 SAS implemented Univac 494 computers as application computers. Existing reservations, check-in and load control applications on the IBM 1410 system were converted to these new Univac computers, and the number of applications rose sharply in a short time. The converted applications became operational in January 1969. At that time SAS Data had about 100 employees.

9 Transition to VDU and Printer

Teletypes, telex machines and Key Sets/Agent Sets were no longer sufficient to meet the requirements of the new applications. Emphasis was therefore placed on VDUs and small smart printers. Ericsson’s ALFASKOP 3100 was chosen as the VDU to be used. The migration took 3–4 years, although many teletype machines lived a lot longer, especially in the small sites. The first order given to STANSAAB in November 1972 was for 633 ALFASKOP 3100 VDU’s.

The transition to VDU’s also led to transition to a new interface (V24), synchronous data transmission, a poll/select system, an 8-bit code ASCII (7 data bits + 1 parity bit), and a communication protocol that could do somewhat more than just transmit data. The 7 bits gave a greater variety of characters that could be transferred. Parity bits made it possible for the receiving system to detect errors in the transmission of characters. The protocol contained more security. By means of a block check character (BCC) the receiving system could detect errors in the transmission of a whole block of characters.

From now on the user could perform all tasks from the same terminal, and receive all written messages on a printer. To get VDU’s and printers to interact with applications, which were initially placed on the Univac equipment, there was a need for a high-level protocol. ALFASKOP 3100 supported the original Univac UTS protocol, which was Univac systems standard protocol for synchronous terminals. SAS had some additional safety requirements to the protocol, which were not met by the standard version of UTS. Together with Data Saab some changes were made, including that messages sent to the printers were not removed from the system, before the printer had confirmed that the messages were actually printed on the printer. An USM key another of the changes. The addressing of the terminals was changed as well. The newly designed protocol was called SASALFA.

With all these pieces in place, SAS was fully ready to step into the computerized real-time, online world. Now the acquisition of terminals and application development really got started. More than 60 applications to manage and control all the elements in the SAS product were implemented in the following years (departure & arrival handling, operational control, flight performance, cargo and more).

The ALFASKOP terminal was supported by Westinghouse abroad, PC’s were introduced with plug-in cards that emulated a SASALFA terminal and in the end an IWS (Intelligent Workstation) with a software based SASALFA client became “The SAS Workstation” and the standard way to access SAS applications. The workstations were controlled and updated regularly and remotely by SAS Data. That was a step in the right direction!

10 TELCON 1

It was not long before there was a natural need to replace the Univac 418 based communication system with a new system. The choice fell on a system provided by Collins Communications in Canada and was baptized TELCON 1. SAS acquired a Collins system with capacity of 2500 terminals. The number of terminals exploded after the VDU’s arrival. A forecast in 1977 indicated that we would grow from 3400 terminals in 1977 to 10300 in 1985. Actually it turned out to be approximately 20,000 terminals. TELCON 1 replaced MESCO and DASCO and the Univac 418’s.

Before the system really came into operation, the entire capacity of 2500 terminals was exhausted, which meant a general moratorium on taking new terminals in operation. SAS simply had a stop of 2 years, before TELCON 2 (system described below) was implemented, and we could install more terminals again. In TELCON operations a Line Access Switch (LAS) and advanced DATASCOPES from the American company, Atlantic Research, were installed. A great tool! It enabled us to monitor all lines out of Copenhagen, and analyze line problems. Everything could be done from the keyboard of LAS!

11 IBM Back in the Fold

In 1973/1974 SAS acquired IBM mainframes, which could take care of new areas requested by SAS, mainly requirements for capacity beyond what the current systems could support. The IBM 360/370 mainframes were introduced, and two parallel development and operating environments (UNISYS and IBM) were established in SAS Data. Eventually there grew a desire to run real-time, online applications on IBM mainframes as well as on UNISYS. An IMS system was implemented, and an interface to enable SASALFA terminals to communicate with the system developed. Mapping from SASALFA’s 7-bit ASCII character set to IBM’s 8-bit EBCDIC went fairly well, as long as the applications on IMS were written specifically for SASALFA.

There was also a need to get IBM and UNISYS to talk directly together (application integration), and hence we in SAS Data developed an “Intercollegiate Computer protocol” (IC) which made this possible. It turned out to be beneficial in many other cases in the future.

12 Quality Assurance

With regard to service level, this was a topic SAS Data took very seriously. Constant monitoring of systems, applications and utilities, networks and terminals gave information on response times, irregularities, capacity shortages and much more. Statistics were made on request.

With the surge in the number of real-time online terminals and the number of applications, SAS was increasingly dependent on IT systems, which were reliable and had a reasonable level of service. SAS Data began in the late 1970s slowly to look at some new disciplines of IT, e.g. capacity planning, evaluation of service level, response time and availability. IBM mainframes were the computers we used for our data processing in this period and the Statistical Analysis System (SAS) the “program language” being used. Access to our systems log files was obtained and tools were created.

After just one season the following objectives were defined:

• Office hours are 6–19 local time. CPH seven days a week (we were of course an airline).

• For any path through the high-level network, the “down time” during office hours shall at maximum be 10 minutes a month, and 45 minutes a month around the clock.

• Response times for 90 % of the transactions shall be less than 4 s (this included all applications, “mainframe”, “high level” networks and “low level” networks).

No distinction was made between the lengths of the different months. No distinction between who caused the fault. There was no such thing as planned or unplanned - all stops were counted. The quality function grew and gave systems, applications, networks and terminals a reasonable service level. Through constant monitoring and reports, eventually also warnings, the responsible leader of a function could ascertain that problems were solved (upgrade, repair etc.). It should be mentioned, that the data collected were later used for accounting of the use of the systems.

13 1973–1990 (Summary)

We had “no-break” power installed to ensure high availability, and most systems were dual systems with mirrored drums (FASTRANDS) and/or discs.

In 1975 one of the first special printers was introduced, Ticket Printers. They were printers of the type DI-AN 8100. The arrival of the Ticket Printers improved Sales Offices services very much.

In 1977 TELCON 1 was replaced by TELCON 2 a Univac system based on Sperry 3760 and Sperry DCP40 processors. When the system was at its height it had 8 nodes and could support almost 6000 terminals online. The nodes replaced the PDP 11’s of TELCON 1 in Copenhagen, Oslo and Stockholm, but the Collins system continued to run the MESCO application until 1984, when MESCO was transferred to an IBM mainframe as an IMS application.

TELCON 2 was completed with a fairly large number of nodes located in Copenhagen, Oslo and Stockholm. The cost of maintenance of hardware (Univac), software licenses and power was getting quite large.

TELCON 3 was implemented in 1981 with DCP40 dual communication nodes from Unisys. It comprised a Unisys mainframe front-end, an IBM mainframe front-end and a terminal concentrator in each of the cities CPH, OSL and STO. The network followed the rules in Sperry’s Distributed Communications Architecture (DCA), which to some extent followed the ISO model for Open Systems Interconnection (OSI). The protocol used on the trunk connections were UDLC (very similar to HDLC).

A node could support up to 128 SASALFA lines and up to 3000 SASALFA terminals. If an online DCP40 failed, the node would switch to the standby DCP40. Such a shift took just a few seconds. Then the lines were restarted, and it could take up to a minute, depending on the number of lines on the node. Based on that, we always set a DCP from online to idle for 1 minute in our statistics.

SAS Data Services became a division in SAS in 1982. One can say today that SAS Data, from the day when electronic data processing made its entry into the company, grew to become one of the major data centers in Europe. A center which managed constantly to be at the forefront of its challenges and development of data services in aviation.

14 External System Integration

In the eighties there was a flurry of development and establishment of links between the SAS systems and the systems of other airlines.

Within the IATA framework it was agreed how a “Host to Host” (HTH) protocol should work, and EDIFACT was the current format standard. In addition, SITA’s global network was already connected to almost all airlines and other aviation affiliated companies such as travel agents and cargo agents. Many different “Host to Host” connections were developed through these years. Some were “non standard”, but most were based on the IATA “Host to Host” protocol, and most of them were also based on EDIFACT. The most notable is probably the following:

SAS Reservation System “RES” was linked to at least 12 foreign reservation systems.

• Format: EDIFACT

• Protocol: HTH.

There were two types of connections:

• “Direct Access”, which was only able to respond to so-called “One Shot” transactions.

• “Higher Connectivity”, which allowed a terminal to maintain a session with a series of related transactions. This was used when booking and purchasing/printing a ticket. It was an option in the HTH protocol, you could select or not.

SAS Passenger Check-In system “PCI” was linked to more than 26 foreign “PCI” systems. It made it possible for SAS and each of the partners to check in passengers and issue Boarding Passes in each other’s PCI systems for tickets they had sold through each other’s RES systems.

• Format: EDIFACT

• Protocol: HTH.

• This concept was named “Inter Airline Through Check-In” (IATCI).

It was convenient for a customer to book all flights with his or her local company, although several different companies were involved. Further, the local company had a better opportunity to plan the trip according to customer requirements. The local company might even issue Boarding Passes for all flights arriving at their destination, and incidentally have luggage checked “all the way”. You had only to worry about it, when you arrived at your destination. The integrated airlines lost nothing due to this integration. On the contrary! They sold more tickets! And the customers loved it!

15 1990 – New Challenges and Solutions

15.1 Bernstein Project

We had grown to become a well-oiled machine, where we almost took it for granted, that everything ran perfectly. Unexpected snags causing disruptions in production happened, but they were rare. However, it took not too many years before we had to find new solutions.

Some Personal Computers (PC’s) began to appear here and there. They were linked together in local area networks (LAN’s), and this happened, as in many other organizations, completely out of our control or influence. These LAN’s were provided with plug-in cards in a server, that made the LAN look like normal SASALFA control units and terminals, seen from our side, and we were then polling all these imaginary control units. For one thing such a solution is expensive and bad seen from a communications point of view. Another more serious aspect was that we could no longer guarantee service levels or monitor terminals, because we no longer had any control over what was happening in the LAN’s.

Our communications architects started a project to investigate the communications field in this context. The goal was to try to come up with some better and smarter solutions. We called the project “Bernstein” after the great conductor, because we imagined the result would be directing our solutions in a reasonable direction. The Bernstein report was completed in February 1991, and the recommendation was in short, that we should remove the polling portion of the SASALFA protocol together with the plug-in card and indeed the whole TELCON 3 network. We should instead implement a SASALFA client on IWS’s that could communicate with host applications via some new communication computers.

15.2 Synthesizer Project

We then started another project, called Synthesizer, which should transform the overall thoughts of the Bernstein project into reality. In the beginning we had a notion, that new communication computers should be distributed and placed in the local networks (which occurred more and more), and that we should use a NETBIOS protocol. We decided to switch to TCP/IP (turned out to be a good idea). After the change there was no good explanation why communication computers were distributed around the countryside, so they were placed centrally.

With these changes we removed all SASALFA communication layers up to OSI layer 7, the application level. This layer is quite different and much more complicated than the rest, because of the large number of applications that had been developed over time. We developed the IWS client and server communications ourselves, and all the rest was standard components on the market. We had planned to name the product during development, but before we were finished, the name Synthesizer had become so ingrained, that it was impossible to change it. Redundancy in the system was obtained by configuring each client with 2 servers, which the client could connect to. If the primary was down, the client could hook up to the secondary.

When the solution was ready for implementation, we had already established a Router, and therefore we started the migration to the new system immediately. There was some pressure to have clients migrated because the new system was very cheap, both in acquisition and in operation, while the existing DCP nodes cost several million dollars each, and were relatively expensive in operation. We saved cash every time we took a DCP node out of service, and we never needed to make a “fallback” to a DCP node.

The old ALFASKOPES were quite popular, so there were quite a few who did not want to switch to the IWS which had a price tag on it. The migration to get on Synthesizer took some time. We therefore started a second development, based on a PC plug-in card from EICON. Here we developed a system that could support the old SASALFA lines, with polling and whatever else was needed. The new system polled the old SASALFA control units, thus supporting the ALFASKOPES. Extinguishing the DCP nodes were then no longer dependent on the ALFASKOPES being migrated to IWS’s. The last thing we did was to move the support for all other protocols still in use in TELCON 3 (e.g. Telex), to a PC as an integral part of the Synthesizer. Thus we were finally able to phase out TELCON 3, and cash in huge savings.

15.3 TCP/IP

When we turned Synthesizer around to run on TCP/IP, we were not quite aware of, what we had done. The Internet had not yet fully impacted the IT world, but we had actually taken our specific airline SAS protocol, and moved it over to run on the Internet and on Intranet’s. If we were not the first to do such a thing (to run an airline specific protocol on Inter-/Intranet), we at least were among the frontrunners!

To monitor the Synthesizer we developed SNMP-based monitoring, which ran integrated into HP Open View. We had our own official MIB number (“Management Information Base” number 169 - a low number - here we were early out too) from the IANA (Internet Assigned Numbers Authority) so we could co-exist with other vendors’ SNMP monitoring on the same platform. Of course provided, that the other suppliers also respected the Internet standard for MIB’s.

On the whole we tried to prepare ourselves as best we could for the TCP/IP revolution. In terms of IP addresses we believed that we would not be able to get an A address, and a B address would not be sufficient. At that point in time we were divided into three stand-alone IT companies, SAS Data Denmark, SAS Data Sweden and SAS Data Norway. A simple solution was found: each company applied for a B address, and we were thus awarded 3 B addresses. It irks us though, that we forgot to reserve the domain name SAS.com before the SAS Institute took it. Apart from that we had everything else in place and had established our own Intranet. We were now ready to connect to the Internet of course with the necessary security structures in place. The introduction of the latest Router technology in the early 1990s came over time to carry the vast majority of Mega network traffic, and an elongated settlement period for Mega Web began from that time.

16 Appreciation

In 1994 Scandinavian Airlines Data, in competition with 100 of the largest private and public companies in the Nordic region, were elected to be “The Nordic region’s best and most effective computer operating center” by the independent COMPASS analysis organization. At that time we had a production unit, based on the latest hardware and software offerings. Our technology platform consisted of UNISYS, IBM, TANDEM UNIX, AS/400, PC’s and LAN’s. More than 30,000 IWS’s and 400 LAN’s at 700 locations worldwide were connected to our router based computer network. TCP/IP was used for communication.

“SAS Data” is still a sound company, even now 10 years after it was sold to CSC. The same people and machines and all the collaborations that were created in the original SAS Data, are still in operation under the name “CSC Airline Solutions” with SAS as the largest customer. It speaks for itself.

17 In Remembrance of Booking and Telegram Centre

This paper started with the Booking Office (now called Reservation - RES), and the Telegram Centre (now called MESCO - an application on IMS). Two very important applications in our system. A final glance at them:

17.1 SAS Reservation System ResAid (Usually Called RES)

ResAid had optimum functionality for SAS, as it was tailored to the SAS organization and SAS market. ResAid was eventually phased out for economic/strategic reasons. SAS now uses Amadeus for its reservations. Figure 2 shows the main developments of RES from 1969 to 2013. Some of the abbreviations are:

• PAS: Passenger Accounting System (Unisys).

• PAH: Passenger Aircraft Handling (an IBM application that replaced the Unisys based Load Control application).

• PCI: Passenger Check In (Unisys).

• CAM: CSC Availability Manager, a Windows application which on one side is integrated with Amadeus and on the SAS side is integrated with ODRMS (UNIX).

Fig. 2.

Developments of RES 1969–2013

Figure 3 shows how the yearly peak-day load from 1970 to 2004 increased from less than 100.000 (estimated) to many millions per peak-day. When traffic was at its peak in the mid 60s, the Telegram Center in Copenhagen handled approx. 25,000 telegrams a day, mainly reservations.

Fig. 3.

The bar chart shows the number of Peak-day transactions handled from 1970 to 2004.

17.2 MESCO - Grand Old IT-Standard

We are now at the time of writing in year 2014. Communication has been transformed to modern times, using the Internet or SAS internal intranet with Internet protocols (TCP/IP), with Smartphones, IWS’s and more. Many things have changed, but there is one thing that has been there all along, still alive and kicking, and it’s oddly enough - telegrams! Figure 4 shows the annual number of messages handled by the MESCO center from 1995 to 2009.

Fig. 4.

The number of messages handled per year by the MESCO-3 center

Telex and Teletype machines are outdated. The protocols in the lower levels, layer 1–6 of the ISO OSI model, have changed. So even though the “old” environment for a telegram has disappeared, the telegram (OSI Layer 7) is still going strong. Many a young IT geek has with condescension heard, that we in aviation are still running with telegrams, until he or she quietly begins to understand, what it is we are talking about – with a standard that is prevalent throughout the world, still used, integrated in systems in millions of places, and can be used without computers if needed.

The addressing and “free text” format were defined by ATA (Air Traffic Association) founded in the Hague in 1919 - the year of the world’s first international, scheduled services. The formats defined for applications using the MESCO standards were defined by IATA (International Air Transport Association) sometime in the 1950’s. All standards are still in use today.

18 42 Years Later…

In the year 2000, when many thought that the end of the IT world was near, the SAS communication network looked - in a somewhat simplified version - like Fig. 5 below.

Fig. 5.

A simplified version of the SAS communication network year 2000