Reservation System History in SAS CPH OCT89/OAS
1958
The first step into automation was taken that year.
SAS purchased an Availability System from Standard Electric Lorenz, which was ‘programmed’ by means of input from a large Master console keyboard.
The user terminal s were also of the push-button type, where an agent by inserting a selected metal-plate into the key-set, and by using the push-buttons to indicate month and date, and one button to indicate selected column and two buttons to indicate selected rows, could get information from the system if the selected flight on the selected segment was open for sale or not. The metal-plate was covered by a piece of paper, where in each row the Flight number and the stations flown were indicated.
The key-set reply was in the form of two lamps above each column, one GREEN and one RED. GREEN was ok to sell up to a maximum of 4 seats, RED was an indication, that the segment in question was fully-booked, and RED/GREEN was an indication, that there were a few number of seats available, and that a ‘NEED’ message was required
If a sale was acceptable, then the agent send a teletype message to Central Space Control indicating flight number, date, segment, number of seats sold, and specified the name of the passenger and other relevant information. If it was a ‘NEED’ message, then the Central Space Control had to reply by yes or no on teletype to the requestor.
Inventory was maintained by band on large Al-size cards, one card for each flight/day in the control period.
No reservation input was possible, the system was for information only
1961
That year SAS introduced a RAMAC 305 from IBM, which was programmable, and the Reservation System was programmed by SAS. The memory in the system consisted of a few working registers and a magnetic drum, on which the program statements were stored, and where a number of working tracks could be used. Each of the 20 program tracks on the drum contained 10 statements, which could be read into a register one statement at a time. It was possible to jump from one program step to another program step on another track be means of directing the jump through an external wiring-panel.
Storage of data was on a magnetic disk consisting of 25 magnetic plates where data was accessed by means of one ‘ARM’ which could be moved on command from disc-plate to disc-plate.
The system accepted input in form of Punch-Cards, which was automatica1ly produced on basis of the above mentioned Teletype Messages with information about seats sold by a particular agent. The Teletype Messages were punched on paper tape, which then were fed into an IBM 047 cardpunch machine for production of a punch-card. The punch-cards were then manually fed into the RAMAC system, where the flight inventory was updated. The System was online only for input from special terminal s at Space Control, where inquiries concerning status of the booking situation could be given, and where updates through the Master Keyboard on the Availability System were given.
The capacity of the System was in the neighborhood of 1500 cards per hour.
The same old push-button key-set were still in use.
The punch-cards were after use on the RAMAC system stored in a file cabinet, and used to produce name lists on the flights at request from Space Control.
1965
The follow-on System to the RAMAC 305, an IBM 1410 dual system, for Reservations as well as Load Control, was introduced. The system was programmed in Autocoder, and was a leap forward in technology, and for the first time it was possible from the same old Key-sets to book directly on the System, followed by a Teletype Message as before, but now fed directly into the system, where the Names were updated to the System automatically
The time lack between the booking of the seat from the keyset and later update of the Names, forced Central Space Control to frequently compare number of Names to number of seats sold.
Central memory consisted of 64 Kbytes, of which the operating system occupied approx 15 Kb. The major part of the reservation system was resident in memory and additional program modules could be added in 3 separate working areas.
Storage of DATA was performed on disk, where we now had one ‘ARM’ fixed per plate, and that reduced access time considerably. At this time we also introduced dual storage of safety reasons for the first time.
1967
On 08NOV that year, SAS ordered the follow-on System, based on UNIVAC 494. Three systems were ordered, one for Reservations, one for Load Control and one as fall-back.
The operating system was standard UNIVAC, but in order to introduce online processing, we had to have a Transaction Monitor System (TCS) developed. This was designed by SAS with assistance from a US-Consultancy firm, and developed by UNIVAC
Storage was now back again to DRUMS, where three different types were introduced. One type rather small in capacity with an access time in 4.5 msec, a medium size with an access time of 17.5 msec and the large size with access time about 35 msec.
We started development with the intention to convert the old system functions to the new technology, with very little additional functionality, in principle still an inventory system.
The system was finally introduced in JAN69, and was by SAS intended to be used for online as well as all batch applications in SAS. The intention was to utilize the surplus capacity during evenings, nights and weekends for this production.
The first system developed and implemented was the Batch Accounting System (ACS) for the entire company.
1974
The 494 RES-system was in this year enhanced with full-PNR capability by introducing VDU Screens as replacement for the old keysets. Replacement of key sets by VDU’s was performed over the next 3-4 years.
1975
In that year automatic Ticketing was developed and introduced.
1976
In this year SAS introduced an own developed Passenger Accounting System (PAS).
UNIVAC then, to our surprise, de-committed the 494 equipment-line in favor of the 1100 equipment-line. The 1100 equipment line was different from 494, so SAS was forced to start looking for a replacement to 494.
The decision by UNIVAC was bad for SAS but understandable seen from UNIVAC business point of view, as the 1100 line had proved more acceptable to the industry than the 494, even if the 1100 line in the beginning was intended for scientific use only.
1977
SAS decided to continue with UNIVAC on the 1100 line of equipment, but intended to have UNIVAC to develop the new reservation system based on requirements from the user community. SAS together with Lufthansa, North West Airlines and a few other smaller Airlines, developed a set of requirements based on which the USAS*systems should be developed
SAS had during the 3 year development period, data personnel stationed in Minneapolis participating in and monitoring this development
The system was moved to CPH late 1979 for final SAS enhancements and acceptance test and implemented in March 1980
The system has since been maintained and further developed by UNIVAC in Minneapolis, but no new versions of USAS, except one for USASTKT, have ever been introduced in the SAS environment.
The reason for this was caused by OUT being the first to introduce the standard USAS*Systems. During the intense acceptance test period in CPH, all errors found was corrected by SAS and UNIVAC on site, and the error report was then forwarded to Minneapolis for inclusion into the standard system. We corrected several thousands errors but the majority of errors was rejected by Minneapolis, they said they could not reproduce the error on their own system. Therefore the difference between OUT version and their version grew to such proportions, that we didn’t dare to start all over again with the standard system.
During the following years, where the demand for compute power grew and grew, it created problems on several occasions for SAS. Every time we were on the brink of inadequate compute power, we had to use unorthodox methods to survive. The hardware plans in UNISYS were late and not always in time, and this has added to the determination to look for a replacement.
