Hans Dahlin
email: hans.dahlin@helaxmedical.com

Sune Karlsson
email: sune.karlsson@mbox305.swipnet.se

Bengt Olsen
email: bengt.olsen@compnet.se

Triple Helix Collaboration for eCare in the 1970s

Keywords: computers, software, user interface, radiation therapy, cancer, clinical physiology, Triple Helix 1, eCare 2, cluster, CART, treatment planning, scintigraphy, pattern recognition, decision support

The Elema project at

The Emergence of Data Processing in Uppsala

The need for computers in the field of natural sciences was seen early by several heads of institutions, who made numerous requests to the Swedish Government for funding from the mid-50s. It was not until Werner Schneider, associate professor of Physics, engaged himself by presenting proposals and taking numerous personal contacts, that the Swedish Government decided to finance one computer at each Swedish university, starting with Uppsala University in 1965. The Uppsala Data Centre (UDAC) was formed and became the focal point for supporting computer activities at universities and within the public sector.

During this era, computer technology became increasingly open for decentralized support, and the Swedish state formed the Swedish Planning and Rationalization Institute of Health and Social Services (SPRI). An early and important SPRI project was 4005, with the purpose to create a normative, basic system for data processing within the health sector. Patient administration routines were to be combined with software systems for Bacteriological and Clinical Chemical Laboratories and stored in separate hierarchical databanks. W. Schneider argued for an expanded concept, the Multi-Satellite System (MMS), in which the central and regional mainframes would coordinate administrative systems and databases (Fig. 1). The mainframes would then interact with decentralized computers, with the main task to process and store data of local character, e.g. data from the signal processing of clinical and laboratory computers. Eleven application areas within the hospital were judged to be candidates for computerization.

A Collaboration Project Emerges

The MMS philosophy aroused the interest of the management of Siemens Medical Engineering Group in Erlangen, Germany. An internal conference was organized at Siemens, and W. Schneider was met with a hugely positive response. The idea of a collaboration project between UDAC, Siemens and the University Hospital in Uppsala, Sweden (UAS) emerged.

The initial enthusiasm at Siemens was followed by a battle for computer equipment. It soon became clear, that the project required a well-equipped process computer with A/D and D/A converters, digital I/O channels, relay control and graphic display in addition to the usual peripherals such as line printers, punch card readers and tape drives. This was rare and expensive equipment. The project's first process computer, a Siemens 305, included 28 pcs 19 inch racks with a footprint of about 80 sqm, at a price in 1970 of almost 3 million Swedish kronor (SEK).

Börje Rudewald, CEO of the Swedish Siemens-owned company Elema-Schönander AB (ES), understood, that an Uppsala-based project could only be realized if the responsibility and cost were managed fully by ES. A staff of six people was recruited and lead by Sune Karlsson, who reported directly to the CEO. UDAC recruited two computational physicists, Bengt Olsen, at the time an associate professor at Chalmers University in Gothenburg, Sweden, and Hans Dahlin, master student in computational physics at Uppsala University.

Karlsson and Olsen were given joint responsibility for project management and Dahlin´s task was to enhance activities within the field of radiotherapy. Over time, approximately 40 people plus several students became involved in the project.

Activity Areas

In January 1969, UAS received a formal proposal from ES and UDAC offering to place personnel and computer resources at the disposal of the hospital for a period of two years in order to develop medical-technical data routines. The work in this connection would be conducted at the Department of Clinical Physiology, the Radiation Physics Department and the Radiotherapy Clinics under the leadership of the respective professors.

The proposal was accepted and the development project (Elema project) was launched. The project activities were mainly to coincide with the following requests: electrocardiography, cardiac catheterization, radiotherapy, scintigraphy, library programs, software systems, experiments and education [START_REF] Olsen | Presentation of a Development Project[END_REF].

The process computer (Siemens 305) was installed -with considerable delay in November 1970, which meant, that for almost two years the project´s focus was to practice and train participants, and to concentrate the development activities to the UDAC computer CDC 3600, in order to prepare program blocks and subroutine libraries for all areas of the project. These preparatory activities proved to be significant for the success of the project, since it laid a solid framework for the whole Elema project.

In the Elema project's initial phase, various image processing algorithms for scintigrams were developed and tested with computer simulated phantoms. After the computer installation and connection to a scintigraph, SCINTIMAT2, increasing clinical reality could gradually be introduced.

The national gynaecological health screening program at the beginning of the 1970s at UAS, led by Dr. Inge Hesselius and Dr. Björn Stenkvist, was desperately searching for digital technology to analyse the cell samples, and experience from the scintigraphy project could be used for the purpose. This new project under the lead of Ewert Bengtsson was welcomed as an add-on to the Elema project. Siemens designed an interface so that a microscope, CLASSIMAT donated by Ernst Leitz GmbH, could be controlled by the process computer [START_REF] Bengtsson | A System for Recording Pictures of Microscopic Objects using a Moving Stage Photometer and a Mini Computer[END_REF].

Methodologies to optically distinguish cancer cells from normal cells were prepared. The new project was successful and initiated new fields of activity in image processing and pattern recognition [START_REF] Noguchi | Low Resolution Inspection System of Gynecological Cell Specimens[END_REF].

These activities resulted in a "world patent" in 1975 based on a method for automatic focusing of optical instruments, widely used without permission of the inventors. Today, most cameras and many other optical instruments use the patented method.

The company IMTEC was later formed to commercialize automatic cell analysis. Unfortunately, the microscope was ahead of its time and never became cost effective, so activities were closed at the end of the 1980s, although further contacts for manufacture and research were pursued. The National Institutes of Health (NIH) engaged three scientists in the Uppsala project and ,subsequently, the current Centre for Image Analysis (CBA) was founded under the professorship of Ewert Bengtsson, who formerly completed his thesis work in the Elema project.

The Scintigraphy project, led by Hans Lundqvist, resulted in developments in the area of Positron Emission Tomography (PET), which led to the development of a commercial PET camera by an Uppsala company Scanditronix AB later acquired by General Electric.

ECG and Cardiac Catheterization

In the general health screening X71 within Gävleborg county in Sweden, approximately 5 000 twelve-channel ECG exams on men of ages 40+ were recorded in analogue fixed format on a Siemens ECG magnetic tape recorder. Minnesota code was used for ECG characterization and refined progressively during the experiment.

Not all activities within the Elema project were equally successful. Although an ECG interpretation package was developed and abandoned due to a marketing decision, Siemens transferred the responsibility for the world market of Electrocardiography and Cardiac Catheterization to ES in 1977.

ES introduced its first computer supported cardiac catheterization lab in 1975. About 150 systems were sold during the next 11 years and a total of approximately 3000 cardiac catheterization units were sold by the year 2003. The total sales amounted to several billion SEK.

Between 1988 and 2002 about 5500 ECG devices with integrated interpretation of resting ECG were sold. The software was based on criteria and programs by Peter W Macfarlane University of Glasgow and adapted with experience from the Elema project.

Experiments and Software Systems

Experimental research work was also very important for the project. About 50 university students made various thesis contributions and UDAC's development of an interactive LISP led by Erik Sandewall, prof. of Artificial Intelligence (AI), provided important results. Various attempts were also made with AI to gather useful knowledge about ECG interpretation from clinicians. Siemens Interactive Compiler SIC, which was developed in collaboration between UDAC and Siemens, was an attempt to replace a Desk calculator via a simplified FORTRAN compiler.

International Eyes on the Elema project

The Working Group on Radiotherapy was inspired by the conference report of the Second International Conference on Computers in Radiotherapy (ICCR) in Paris in 1968. Groups that developed software in the field were contacted and asked to contribute knowledge and software. The Elema project was presented at the third conference in Glasgow in 1970 [START_REF] Dahlin | Programs for 3D organ-and body contour description to be used for corrections of inhomogeneity and optimization[END_REF][START_REF] Cederlund | A program for optimization of the combined dose from applicators and external treatment machines[END_REF] and made such a positive impression on the program committee, that they decided to hold the next I C C R meeting, U72, in Uppsala, Sweden, in 1972. A huge effort to engage all participants in preconference work gave the conference a unique atmosphere of collaboration.

At U72 the results of the Radiotherapy development of the Elema project, implemented in clinical routines at the Hospital, were presented to the delegates [START_REF] Olsen | Presentation of a Development Project[END_REF], [START_REF] Dahlin | Computer applications at a radiotherapy department[END_REF]. The new inventions of interactive dose-planning, using a unique Rho-Theta table (Fig. 2) and automatic radiation control, were recognized as the most outstanding innovation in radiotherapy in the world.

Radiotherapy Field Development

The Elema project had a vital role as a catalyst for worldwide research and product development in the radiotherapy field regarding dose-planning, image handling and quality assurance from the early 1970s to late 1990s [START_REF] Olsen | Användning av en processdatamaskin inom radioterapin vid Uppsala Akademiska sjukhus[END_REF][START_REF] Dahlin | A computer Network for Computerized Radiotherapy[END_REF][START_REF] Dahlin | Integrated use of computers in radiotherapy as a part of a computer network[END_REF][START_REF] Olsen | Classification of Systems for Computerized Treatment Planning[END_REF][START_REF] Olsen | The Problem of Integrity and Confidentiality[END_REF][START_REF] Cederlund | Medical computer network a prerequisite for faster progress in computerized radiation therapy[END_REF][START_REF] Dahlin | Nu datoriseras onkologin[END_REF].

Commercial Cooperation and Market Penetration

The results presented in the project report in 1972 encouraged the radiology and radiotherapy divisions at Siemens UBMed to establish a close cooperation with Uppsala University and its Data Centre, UDAC. The long term development program was to focus on commercializing of the results from the radiotherapy part of the Elema project.

The Division for Medical Computer Physics, led by Hans Dahlin, was established at UDAC to cooperate with Siemens. The office for the new division was located at the oncology department at UAS in order to incorporate the knowledge of the daily routine and its personnel into the development work.

The project was named SIDOS-U (Siemens Dose Planning System version Uppsala) and was successfully in operation for almost ten years. The resulting products for so-called external and gynaecological radiotherapy became an international success for Siemens, who sold more than 500 individual systems worldwide with a total value exceeding 2 billion SEK.

A strong relation between the US company Digital Equipment (DEC) and UDAC was established towards the end of the Elema project and became extremely effective in transferring the results from the Elema project into small computer systems for hospital laboratories. The cooperation with DEC also had a major impact on Siemens decision to exchange their own lab computers to DEC computers for applications in the biomedical field. In the 1980s and 1990s Siemens became DEC´s largest customer for medical computer applications.

A popular movement to close down all nuclear power stations, due to the risk of radiation damage to nature and mankind, spread after the accident at Three Mile Island, USA, in 1979. These circumstances also had a strong negative effect on the use of radiation in the healthcare sector.

After the announcement of new, more effective cytostatic drugs for cancer treatments by the end of the 1970s, the industry's interest for radiotherapy technology faded.

By the end of the 1970s, UDAC and its special division for medical computer physics had developed unique knowledge and an international network on how computer technology and software development could be used for safe and accurate radiation therapy in cancer care. This led to a spin-off project using the 305 computer at UAS for the development of a dose-planning system for the Gammaknife product.

The project was led by the special division at UDAC as a cooperation between the Institute for Physical Biology and professor Börje Larsson, the Neurosurgical department at Karolinska Hospital and professor Lars Leksell, and the Radiophysics department at Radiumhemmet in Stockholm and professor Rune Walstam. The first software implementation was carried out at the Gammaknife unit at Radiumhemmet in 1975 [START_REF] Dahlin | Destruction of small intracranial Tumours with 60 Co Gamma radiation[END_REF], which later led to the commercialization of the results by Scanditronix AB and later by Elekta AB at the beginning of 1980s. Elekta is today a world leading company in radiation oncology with over 4000 employees.

Changing View on Radiotherapy -the CART Development

A workshop on Computers in Radiotherapy was organized at the Nordic Radiology Congress in Åbo, Finland 1981, where Hans Dahlin presented a challenging paper on how computers and intelligent software development could make radiation therapy an important complementary discipline to the cytostatic drug treatments.

The same year a group of Nordic physicists and doctors came together in Uppsala to discuss requirements and recommendations for computer aided radiotherapy. The meeting resulted in a two year pre-study project and was financed by Nordforsk and the Nordic Industrial Fund. The group consisted of clinical experts (physicists and doctors) from Sweden, Finland, Denmark and Norway. H. Dahlin at UDAC became the operational manager of the project together with Jan Törnqvist who represented Nordforsk.

The resulting work, User requirement on CT based computer dose-planning systems, was presented in 1984 and pointed out necessities and possibilities to make radiation therapy both safe and accurate in a future perspective [START_REF] Dahlin | User Requirements on CT-based computed dose planning systems in radiation therapy[END_REF].

The pre-study project encouraged Nordic oncology clinics, cancer research institutes and Nordic medical companies to join and establish a new non competing project to develop technology and software.

In 1985 the Nordic Computer Aided Radiotherapy project (CART) was launched and comprised of members from the Nordic Industries, research institutes and oncology clinics [START_REF] Lamm | CART, A Nordic Challange in Medical Computing[END_REF]. Half of the total budget of 30 MSEK came from the Nordic Industrial Fund, and the other half came from the Nordic Industries, mainly as equipment for the developing sites (the Demonstrators).

Demonstrators were set up: one in Uppsala, Sweden, with focus on Image Handling and Man-machine Communication, one in Tampere, Finland, with focus on 3D treatment modelling, one in Rejkavik, Island, with focus on Oncological Databases, and one in Oslo, Norway, with focus on Simulators and CT imaging. The CART program became known internationally and was referred to as the "Nordic Wonder", which resulted in a collaboration with the Radiophysics Department at the University of Chapel Hill in North Carolina.

In 1998 an international seminar on The accomplishment and future directions of the Scandinavian Program CART (sponsored by National Cancer Institute, as part of the World Congress on Medical Physics and Biomedical Engineering in San Antonio) gave a broad international understanding of the CART mission [START_REF] Westerlund | The Scandinavian program CART, Joint U.S.-Scandinavian symposium on Future Directions of computer-aided radiotherapy[END_REF]. This encouraged many companies to develop new products based on the CART results with the purpose of improving the integration and use of clinical and technical information from early diagnoses in order to follow up individual patients in cancer care.

Radiotherapy in cancer care today involves precision and treatment quality and so improves the quality of life for today's cancer patients. The Elema project and the resulting activities in the 1970s and 1980s contributed much to this success, thanks to the structured and targeted cooperation between research, industry and clinical activities. Similar project collaboration today in other areas of cancer care, such as tumour diagnostics, screening and drug use would benefit more patients in the early stages of their disease and increase the quality of life for those patients where cure is not possible. This is particularly important in less developed countries, where today more than half of all cancer cases and deaths due to cancer occur.

• Knowledge and experience from the Elema project was applied immediately in the clinical operations at UAS. Siemens 305 was used even a few years after 1972, until it was replaced by more compact and yet more powerful computers.

• Early on a DEC PDP11 was installed in Clinical Physiology for continued cardiac catheterization and ECG development. • The radiation therapy segment was further developed and expanded worldwide through a 10-year collaboration with Siemens. • Imaging became an academic institution under the leadership of a former project member. • Spin-off companies influenced by the project were started.

• ES introduced early microprocessor control and complete computerized products to the market.

The Elema project was characterized by freedom with responsibility, by nonbureaucratic allocation of resources from forward-thinking leaders, by a dedicated staff under flexible working conditions.

Conclusions

Some important elements remain from the experience of the Elema project. Today's projects that support organizations, such as Vinnova in Sweden and similar organizations in other Nordic countries, should possibly revise their definition of project conditions. This may provide the opportunity to regain an international front position regarding skills in the Nordic countries and strengthen long-term economic and enterprise development. Nordic cooperation could be based on the following:

• Principals should only specify general conditions and allow freedom for project leaders to develop an innovative and creative environment for project participants. • The main goals must be clear and the results evaluated by decision makers with knowledge and emotional ability to cope with future assessment and with understanding of how the desired results could be achieved. The budget should provide space for spinoff effects. • Allow projects a start-up phase where tools and aid for the work ahead could be created. • Install the development tools, e.g. computers, as close to the clinical environment as possible in order to take advantage of a direct contact with the staff and the environment to which the project relates.

• Make sure that management actively supports the project. Give the medical staff that are directly and indirectly "affected" by the project a commitment under their own responsibility. Organize project meetings at times when all involved can participate. • Use a development method based on interactive and incremental development.

Collaborate tightly with cross functional teams. This encourages rapid and flexible response to requested changes, using tight iterations throughout the development cycle. This method has come to be called agile development in 2001. • Conduct early international "state of the art" research, to map out unknowns and alternatives. • Allow the students and project workers involved in specific project issues an adequate remuneration and adequate access to common resources. • Ensure that the participating clinics receive a refund for the work done by accessing produced results and products under economically favorable terms.

Fig. 1 .

 1 Fig. 1. The Multi-Satellite System (MMS) was a concept for a nationwide data system. CCI: central computer installation, RCI: regional computer installation, LCI: local computer installation, T: terminal, DAT: data acquisition terminal.

Fig. 2 .

 2 Fig. 2. The original man-machine radiotherapy interface with the Rho-Theta unit.

Fig. 3 .

 3 Fig. 3. The Computer Aided Radiotherapy (CART) Project

Triple Helix was a successful partnership concept between academia, industry and government.

eCare means here: support and improvements in medical care using computers and communication technologies.


Jens Bache
email: jens@bache.dk

The VP project (1981-83): Dematerializing Millions of Danish Bond Certificates

Keywords: Central securities depository (CSD), stock exchange, securities, systems development, large project management

A chronicle of the systems development project that created VP, the world's first dematerialized securities depository -a piece of financial infrastructure that later has become a model for many financial markets all over the world. The project used ground-breaking strategies in choice of systems development methodologies and use of standard software. Rapid implementation using prototyping ensured timely user feed-back. Project management based on very visible milestones ensured that the project was on target -both in terms of time, budget and user satisfaction.

The Problem

In the 1970s many financial markets suffered under increasing volumes of securities and increasing trading volumes. The paper handling of bonds and their interest coupons resulted in very high costs:

• Issuing of certificates • Safekeeping • Asset servicing: cutting coupons, counting (and recounting), redemptions (drawings) and the resulting payments. The deliveries and payments resulting from securities trading were the main problems. Trading volumes resulted in large delays, and the volume of unsettled trades had reached a level where The Danish Central Bank and major participants regarded it as a systemic risk: something had to be done. High level discussions went on for years and years. These were difficult discussions, because many competitive issues were buried in the design of the solution.

In 1980 -after more than a decade of discussions and negotiations -legislation was approved by the Danish Parliament: As the first country in the world Denmark would abolish paper securities. A private organization, Vaerdipapircentralen (VP), should be created. VP's main functions should be:

• to register all exchange traded bonds • to register ownership (and other rights, e.g. pledge) to those bonds • to settle trades in bonds (delivery and payments) and • to make other payments in connection with the lifecycle of the bonds (interest and redemption payments).

The legislation had effect from July 1 st 1980. And then the process of building the organization 2 Prelud

The VP Utopia

Quite often large IT development projects fail. And we knew from beginning that project risk must be at our focus as the main problem. Project size and project complexity was our main concerns. But many other risk factors were present: New organization, complex and competitive user environment, supervisory authorities etc.

We knew from our initial investigations, that buying an application was not an option. We would have to develop the solution.

Out of our planning discussions grew our VP Utopia:

• Keep the project size down by using existing infrastructure (PBS money transfer system for interest and redemption payments -the Central Bank clearing system for delivery versus payment for all professional trades)

Milestone management of the VP project

Milestone 0, March 1981: The Starting Point

The preliminary plan (and prototype) from the planning secretariat divided the application development into 4 projects with well defined interfaces between the projects:

• Communications

• Conversion

• Daily clearing and settlement

• Asset servicing (interest payments and redemptions).

Even the 4 projects were too large to be manageable, so each project had to be divided into smaller projects: 160 in total. By November 1980 the key persons, data manager and database manager and all project managers had been hired. After initial training in VP development strategies they had to revise and refine the plan and hire their own staff. This second wave started working on February 1 st 1980 and -after training -helped produce the Milestone 0: The plan for a two year development, with project charters and visible operational goals for every three months.

The plan was presented to the user organization in a number of seminars. For every milestone the plan focused on:

• The visible results from VP to the users • The visible results from the users to VP (very little initially -more and more as the process progressed). Later we also made a milestone plan listing the deliveries from the VP board and from the supervisory authorities. And both parties accepted their part of the overall plan.

Milestone 1, July 1981: The first small Results: Test Conversions

The conversion strategy was based on the fact that most bonds were already in the systems. The issuers had all information about exiting documents, and the custodian banks had information about the documents in their custody.

The first milestone was a relatively easy one, but it was important to show all 29 data centers that the process had started. Nobody had expected to hear from us until 1983. The participants had to send all their information on bonds to VP in a specified format. VP would then validate the information:

• Technical validation • Were all holdings valid from the issuer's point of view?

•

Were there duplications, where two banks said that they had the same document (synchronization problems). The first test conversion also gave us vital live information for our modelling of the VP database structure.

This process of test conversions was repeated for every milestone, gradually reducing the number of errors, so that the final conversion had more than a 99.9 % success rate. Only very few conversions had to be handled manually.

The second -and most important -result was that the milestone plan was approved by the participants. Not without discussion: The traditionalists claimed: "You can't make the plan before you know all the details". Finally everybody agreed to the plan (probably because everybody believed VP to be late).

Finally the third wave of EDP-professionals had arrived, been trained and started working. By now VP was up to 75 % capacity. The new VP building had been finished, everybody had moved to the new offices, and two of the three IBM computers had been installed.

Milestone 2, September 1981: A First Implemented Prototype of all Major Functions

Milestone 2 was the first serious test for the new organization's ability to produce acceptable results. All major teams and groups in VP had deliveries to this milestone:

• A comprehensive description of user requirements • Business policies: criteria for validation and updates.

• Physical layouts of the main databases as well as data flow diagrams and minispecs for functions in the DFDs.

The milestone results were presented in a series of seminars for user organizations and their data centers, and after one month we had received 180 proposals and change requests.

One of the important roles in creating documentation standards and coordinating between project groups was the data manager. He was responsible for the data dictionary, which proved to be an indispensable tool for ensuring quality of data and data definitions. The data dictionary was the source for program documentation as well as user documentation.

The milestone 2 results were impressive since it was the first major demonstration that the new organization (with an average employment of 6 months) could work as a team.

Milestone 3, December 1981: A Revised Prototype of all Major Functions

Milestone 3 contained more or less the same main functions as Milestone 2, but it contained more than one hundred changes to business policies and database definitions. We were careful to respond quickly to all proposals and change requests. This was a major test to our development and documentation strategies. VP proved able to respond to the users as well direct and control the process. For some organizations this was a wakeup call: The train was moving and the milestone plan should be taken seriously. Other organizations gave the project high priority and saw a potential competitive advantage in being ready from day one. They would not accept any delays.

Internally everybody was extremely busy with their own detailed parts. Therefore the main challenge was to focus on quality control and coordination. We had to focus everybody's attention and commitment to the total result.

As part of Milestone 3 VP presented the detailed plans for the rest of the project: Final date for the conversion: January 24 th , 1983 for the pilot conversion and April 5 th , 1983 for the total conversion and full scale operations.

Milestone 4, March 1982: All Functions Frozen

At milestone 4 VP changed pace to a more conservative implementation strategy. From this point on only obvious mistakes, errors and inconsistencies were corrected. This change of pace happened for two reasons: firstly to give all the data centers a chance to do their part of the development against a known, stable background, and secondly because we had entered a period where all users were to sign legal contracts with VP.

The project groups began tuning the system in order to estimate the necessary production capacity. A full user manual was presented, and end user training could begin.

The presentation to the data centers showed that several of them could need extra time. We decided against this: both external and internal morale was dependent on the fact that the milestones were to be taken seriously. A minor delay would postpone the entire project at least one year! From this point it was clear that a single user organization would not be allowed to change the project's objectives or schedule.

Milestone 5, July 1982: All Functions Implemented and Tested

Milestone 5 presented a tuned production environment to be used for systems testing. Users were presented with plan and procedures for the testing. The first phase of testing (October) was recommended but not mandatory. The second phase (until December 15 th , 1982) was mandatory. Minimum requirements per functions were defined for all users, and users that had not fulfilled the test requirement would only be allowed to participate in the VP system through a standard VP terminal. This interface to VP was defined as a "Plan B" for users that were delayed in their internal development. The VP terminal also served as an important interface in the initial systems testing.

Milestone 6, September 1982: Fully Implemented Communications Network

The full communications system was implemented only one month before systems testing started. This might seem a bit implemented (Systems Network Interconnect). VP was one of the first organizations worldwide to implement this functionality.

An important definition phase followed: each user should specify the type of output he wanted: printed output, edited and non-edited output or CICS-print via the online system. Only after this had been specified could the testing begin. In total VP had to handle 23.000 output/address combinations. This was only possible because of a standard spooling system.

Internally a special test coordination group was established with detailed procedures in order to handle effective problem and change management and prioritizing as well as quick and effective communication with the users.

Milestone 7, November 1982: Full Scale User Testing

The general public was informed about the proposed change through all major newspaper and National Broadcasting TV.

Internally all major functions had been tested since Milestone 4. By Milestone 7 the entire VP system was approved for external testing as described above.

During external testing 681 problems were registered (and all were solved except 50 uncritical problems).

The test plan had measurable criteria for the acceptance of the 29 data center systems. 10 out of the 29 data centers had more than five outstanding problems at the end of testing. These data centers were granted until January 14 th , 1983 to correct the problems.

Milestone 8, January 1983: Conversion and Pilot Operations for a limited Bond Volume

On January 4 th The VP board evaluated the results and status from the testing phase and approved to start actual production on January 24 th , 1983.

During the weekend of January 8 th and 9 th 600.000 investor accounts were converted to the new system.

Two weeks later 1.5 million bonds with a nominal value of 24 Billion DKK were converted to the VP system. Only 3.000 bonds were rejected and had to go through manual control. During the first two weeks of pilot operations ten errors were reported and corrected immediately. During the rest of the pilot operation no errors were found. We are talking about hundreds of thousands of lines of code! Half of the problems related to the same part of the system -a part that was considered too large and too complicated. That part was quickly redesigned.

Milestone 9, April 1983: Conversion of 46 Million Bonds and Full Scale Operations

During the Easter holidays in 1983 the main conversion took place: 46 million certificates with a nominal value of 600 Billion DKK were converted into the VP database and registered on 1.045.000 investor accounts. VP could finally go into full scale production -on time and within budget. A 200 man-year project, involving 100 people, had come to an end.

The first months of operations were -as one might expect -a challenge. This was mainly because of changes in the financial markets. Market volumes were booming all over Europe, and the VP system was loaded way over the estimated capacity. The VP system proved rather robust, but delays were inevitable. Our neighbouring markets in Sweden and Norway were on the brink of catastrophe. This is the main reason that the VP system was later exported to Norway, and Sweden decided to copy the system (at far greater cost).

There was a problem in the business definitions: Banks had unlimited cash lines with The Central Bank, but brokers had limits on their cash available for settlement. We were told that the brokers (knowing their actual trades) would always have the cash in place in time for settlement (3 days after trade day). Actual operations told a different story since it was more expensive to fund a buffer on his credit line than to solve the problem when it occurred. This introduced a manual procedure in the operations (known as amber light/green light procedures) and it took a considerable while until the procedure could be automated.

Lessons learned

Prototyping and implementation strategy

One could argue that leading edge technology and new application areas should call for a conservative implementation strategy. I would say application development and prototyping approach is especially useful in such circumstances. Such a strategy will give early warning of potential problems and ensure that vital systems components are tested early.

The problem through the 1980s and most of the 1990s is that every new generation of computer professionals came out of school or university well trained in sequential (waterfall) development models. The same goes for many of the development tools that were sold during these decades.

In our case the communications architecture was implemented rather late, but we accepted this as a fact of life. IBM was unable to deliver this solution earlier. We had to define a national communications address standard for the entire country -a standard that was approved by IBM. After a while IBM reported a problem: We needed a country code if one of the computers in the network (e.g. IBM's own mainframe) had to address a computer in another country. This only to illustrate that everybody -including IBM -was in a learning mode.

IT tools wherever possible: the VP Utopia

The VP Utopia and the aggressive use of standard software wherever possible can hardly be considered breaking news today. It is more or less what everybody is proposing. Our methods for analysis, data modelling and design greatly helped us in minimizing systems complexity.

We considered the VP Utopia a huge success at the time and gave presentations on the NordData conferences in 1984 and 1985 and a full day seminar on the NordData 1986 conference in Stockholm.

Milestone Management

The approach with very visible milestones proved to be an extremely powerful tool in managing the entire process with so many conflicting interests.

The total priority was sky high, and nobody wanted to be the one that delayed the entire project. In the end even the authorities came under the pressure of the milestones that they had initially accepted!

Operation under Peak Volume

The market volumes in 1983 were mentioned above. But the VP system had removed a lot of paper from the stock exchange settlement. Therefore -over the first few years of operations -the total volumes went far beyond what would have been possible in the paper based settlement system.

A Flexible System can do More

A flexible system inspires the users: The VP system could with a single transaction do delivery (of traded securities) against payment (in Central Bank money). The very same transaction can provide liquidity against the movement of collateral for that same liquidity. So the VP system was used to remove a lot of the liquidity risk from the Danish financial sector.

The VP systems design proved robust and flexible: New types of securities could easily be added. Equities were introduced in 1986. Later VP was able to add a high speed link to Euroclear in order to handle the settlement of cross border trades. In 1985-86 the system was modified and exported to Norway as described by Jan Hellstrøm on HiNC3 [START_REF]HiNC3, IFIP AICT[END_REF]

Zero-defect Systems Development

There is no such thing as zero-defect development. But the systems development strategies and tools chosen brought the VP system very close to this ideal goal. The legislation stated that if anything went wrong, the VP system would have to pay. I never saw a single claim under this rule during my many years as managing director of VP (until 1999)!

  The main reasoning behind the VP Utopia can be seen in the book by VPs head of systems development: H. Dines Hansen: Up & Running[START_REF] Hansen | Up & Running -A case study of successful systems development[END_REF].

• Keep the size down by using standard software wherever possible: o A central data dictionary to control all documentation o A DBMS to control all databases o A programming language that supported our modular approach o A terminal development system o A text editor to create user documentation based on extracts from the data dictionary o A standard communications system o A library system for all programs o An automated production management system • Small project groups with systematic coordination and quality control mechanisms • Rapid implementation strategy based on a prototyping strategy • Development methodology, based on structured analysis, data modelling, structured design and programming • Heavy training of all persons (we used Yourdon inc. to do this part, not because we believed them to have "a magic bullet", but because they tended to agree with us in most matters). • High user acceptance through strong interaction during the development period.


Helge Grimstad
email: heg@g-hit.dk

IT & Communications in SAS

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.

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.

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.

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".

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...

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.

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 late1960 to solve the problem. RAMAC was connected to SPAS and later on to a new system called ZEBRA.

Load Control & 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.

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".

Airline

SAS

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

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.

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.

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 IBM1410 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.

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 realtime, 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!

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 TELCON1. 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 in1985. Actually it turned out to be approximately 20,000 terminals. TELCON1 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 TELCON2 (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!

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 seconds (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.

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 in1982.

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.

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!

-New Challenges and Solutions

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.

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 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 t introduction the vast maj Web began

Ap

In 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 .

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

Fig. 4 .

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

Fig

  Fig. 5. A

cente Fig. 1. T ASCO I -F

	e Collaboratio on 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
	Telegr ram Centers we ere created ear rlier on and con nnected in a w worldwide netw work. Oslo and later Gothenburg.
	SAS and Sw common ne SAS or Swi utilizing eac 5 SA A plan to in wissair had mad etwork. Each c issair. Telegram de an agreemen centre was man m lines were e ers, both partie The interconnecti February 19 ee systems SPA nt, which made naged and ope xpensive, so th s saved money ion of SPAS, RA 965 AS, ZEBRA, R e their Telegram erated by one he airlines had y. AMAC, and Zeb RAMAC and t m Centers part of the compan to be creative ra the semi-autom of a SASCO 1 was assigned 300 Agent Sets / Key Sets operating in 21 cities in 14 nies, countries and 4,000 teletype machines around the world.The computer was also e. By matic programmed to monitor all SAS flight arrivals and flight departures. This information was notably transmitted to Copenhagen Airport. SAS still supplies ch others' ntegrate the thre airports with Arrival and Departure times.
	Telegram C Center on an IB BM 1410 "du ual system" for r Reservation	and Load Con ntrol
	was now re ealized. The w whole thing w was put into s ervice in Febr ruary 1965 in n the
	presence of f IBM CEO Th homas Watson,	whose father h had started IBM M, SAS CEO K Karl
	Nilsson and d Mrs. Helle V Virkner, wife o of Prime Mini ister J.O.Krag. . She pressed d the
	button that s started the new w era.
	The syste em was installe ed on the 2'nd	floor of Copen nhagen Airport	(now Termina al 2),
	and named	"SASCO 1". I It had been pro ogrammed to do o the same as th the ZEBRA cou uld -
	and a whole e lot more, incl luding automat tic balance calc culation, load c control (weight t and
	balance), pa ayroll and othe er administrativ ve tasks. The I IBM 1410 mac chine was runn ning
	virtually ar round the clo	ck, and traffi ic schedules w were not load ded -as with	the


Tor Olav Steine
email: tos@alfatroll.com

The Norwegian State Railway System GTL (1976)

Keywords: computer, minicomputer, Norsk Data, administrative system, transaction processing, data network, database

In 1976 the Norwegian State Railway System (NSB) planned a new system to keep track of all its freight cars. Among the duties were these: arranging trains at the shifting station in Alnabru outside Oslo, following (tracking) the trains as they moved along the tracks inside Norway, optimization of car maintenance and statistics. The system could save millions of Norwegian Crowns by better utilization of the car pool. It was named GTL for Gods Transport Ledelse (there is no Divine link; "Gods" simply means cargo in Norwegian). Norsk Data won the contract in competition with USbased mainframe vendors and, against all odds, delivered a system on time that "never failed" for the many years it was in operation.

1

The Background

We are back in time to the early childhood of computing as we know it these days. There were no personal computers -they were either shared or used by one user at the time. Users might either punch cards in separate card punching rooms and thereafter read these into the computer for processing, or share one computer through a multiuser facility called time-sharing. In the first case, the output was ready either later in the day or the day after, while time sharing allowed several users access to the computer simultaneously. On-line computing was expensive and not common. Yet, in the early 1970s minicomputers had arrived with time-sharing systems (TS systems for short) that allowed users to interact directly with software for on-line editing of code, with subsequent compiling and testing of the same. It was, however, not common for users to have access to screens with graphic displays -it was all pure text. For non-computer people one could now make systems where the end users had direct access to central databases, and even update and modify these. But most large mainframe computers had operating systems that were optimized for batch processing (large quantities of data in, large quantities of data and printouts out).

Hence, one was forced to develop "operating systems within the operating system" -or teleprocessing monitors (TP monitors for short) to allow a large number of users to have online or simultaneous access to a large, shared database.

TP monitors differed from time-sharing systems in that they were running specially developed software systems, tailored to what the users were allowed to do, while TS systems might allow skilled users to do whatever the available software let them have access to, including developing their own solutions.

TP monitors also had another important property: Systems sharing a common database might fail and cause damage to the central database, thereby corrupting the data. Therefore, one must have a solution allowing the user to reconstruct the database into a non-corrupted state. This solution was called "Rollback/Recovery", and it could either work for all users combined or work for only a single user and his/her session with the online computer system.

Norsk Data regarded itself mainly as a vendor to technical and scientific organizations. In 1974 the company had 140 employees, and a revenue of 38 million Norwegian Kroner (ca. 5 million USD), growing to 211 employees and 81 million Crowns in 1976.

In 1976 the Norwegian State Railway System (NSB) distributed its request for bids for a new system to keep track of all its freight cars. Norsk Data possessed a few basic technologies for use in the desired solution, but far from all. Norsk Data had never delivered any similar system. The competitors, however, were skilled in this game and could provide references in large numbers. This was the situation when the request for bids arrived to deliver the GTL system.

2

The Bidding Process

The request for bids called for an on-line system with many functions. Among the duties were: arranging trains at the shifting station in Alnabru outside Oslo, following (tracking) the trains as they moved along the tracks inside Norway, and optimization of car maintenance. The system might save millions of Norwegian Crowns by providing better utilization of the car pool and was named GTL for Gods Transport Ledelse (there is no Divine link, "Gods" simply means cargo in Norwegian).

The system required a Transaction Processing (TP) monitor capable of handling 150 terminals and heavy online traffic with a 24/7 operational capability. If not delivered on time, daily penalty fees were due. ND's competitors were all US-based mainframe vendors, with systems like CICS in the bag already (IBM). Yet Honeywell Bull was the fiercest competitor, with its TDS TP Monitor (later TP8), IDS database, and a firm vendor relationship to Norwegian public institutions.

ND had already delivered a network (ARPANET style, named Nordnet) where all terminals were connected, and the only link between the GTL system and the terminals would be via a single pair of wires and a network protocol. Dave Walden made the basics for the network while he worked for ND during 1970-71. Dave Walden was one of the original developers of the ARPANET, and his implementation on ND machines proved to be highly reliable and efficient.

The Oslo-based research institute, Sentralinstituttet (SI -later to become SINTEF) already in 1971 made the world's first minicomputer with full virtual memory, and in 1974 they made one of the first CODASYL database management systems for minicomputers, SIBAS.

Almost in parallel ND hired Bo Lewendal, a young Swedish developer, and he made one of the first time-sharing systems for minicomputers, Nord TSS. Starting in 1974, ND combined most of these components into its next generation of computers and operating system: Nord-10 with the Sintran III operating system. This system was capable of doing real-time, time-sharing, batch and virtual memory -all at the same time.

The Challenge

ND knew that a single minicomputer would be unable to deliver the required capacity. The TP system would have to split the job between four Nord-10 machines, each handling specific tasks. The machines would have to serve as individual backup for each other, and the Nordnet was used for inter-CPU communication even here. The database management component of the freight car system was the SIBAS system (just developed by SINTEF in Oslo) -a traditional CODASYL DBMS, first implemented on a Nord-1 and performing incredibly slowly in the beginning. The project was one of the largest software projects in Norway to date, with an estimated 35 man-years for the software alone. 150 TTY (Teletype) terminals in an ARPANETstyle network were to have 24/7 operational access to the common database through a number of application programs -with "no errors", and a considerable transaction volume.

The main competitors were IBM and Honeywell Bull. Both had the skills, the hardware equipment, and the software solutions to deliver the solution. They were both huge organizations compared to Norsk Data, and with their mainframe computers they operated in a different league altogether.

The only asset ND had was its successful delivery of the networking system, and the fact that the other competitors also needed to interface to it. That required some detailed expertise.

The competitors had well-proven TP monitors: CICS (IBM) and TDS (Honeywell Bull) and databases: IMS (IBM) and IDS (HB).

ND had Nord-10 minicomputers with the Sintran III operating system, capable of simultaneous real-time and time-sharing with a maximum of 32 terminals per CPU. ND did not have a TP monitor and only posessed a newly developed DMBS system, SIBAS.

In short: ND had no previous experience with on-line administrative projects of this order of magnitude.

4

The Solutions

When bidding for such an awesome contract, one really had to review one's inventory. The following is a reconstruction of the components that were vital for putting together a viable solution.

Bo Lewendal, as previously stated, was working alone during the summer of 1971, developing Norsk Data's first TS system, based upon a Nord-1. Bo had fresh background from a similar project from California. It subsequently lead to Norsk Data winning a large contract with deliveries of a large number of Nord-10 machines to CERN both for administrative use and for the controlling the SPS ring (SPS: Super Proton Synchrotron), which was CERN's largest particle accelerator at the time.

SI had also experimented with virtual memory on a Nord-1 computer already in 1971, and this became the first minicomputer with virtual memory worldwide!

In 1974 Norsk Data launched its first really smooth time-sharing system, based upon the new Nord-10 computer and the Sintran III virtual memory operating system. Sintran III allowed a moderate number of time-sharing users to have simultaneous

Anderson Consulting

NSB hired a skilled project leader from Anderson Consulting as their project leader.

Norsk Data

Norsk Data appointed Harald Eide as its general project leader, with Dag Spilde being responsible for the TP-monitor and networking. Lars Lind was appointed responsible for application program development, while Peter Bonne designed the database.

Computas

Norsk Data hired Computas, a subsidiary of Det norske Veritas, for the networking and TP monitor part. The author worked there at the time.

ADB System Logikk (ASL)

ASL was hired as developers of the application part. In order to let the application development start immediately, one decided to use timesharing for the application development, in a simulated TPS environment.

Thus, the TPS development could take place undisturbed in the background, and application development and database testing could take place in parallel.

Syste

T

As previ

Two pai CPU interfa and the rem split the da literally mov real life.

T

In softw allowed a c with as man

The soft single CPU, During normal operation on a full hardware configuration, the GTL system's network CPU contained the Network & Front End module, the next CPU contained the Application Control part, and the remaining two CPUs contained one SIBAS DBMS system each. For communication between the CPUs, a mini version of the previously mentioned Nordnet was used.

Program Module Structure

The main challenge was, as it always is in large project, to maintain simplicity and order. In a message-based system, this even includes the messaging structure.

For each of the modules in the system, a message/state diagram was used for maintaining the simplicity, the so-called state-vector principle:

Any arriving message was handed over to a specific program element for treatment. Selection was done via a message/state vector. Modules would always be in a defined state, such as, e.g., "in normal session with a user in the network, synchronized checkpoint is going on". Upon receipt of a message, a state vector identified which piece of code to invoke at the receipt of this particular message type while in the particular state. The resulting code was extremely compact and easy to maintain.

All aspects of the software solutions were subject to thorough code inspections, where the author had to describe his/her solution to the scrutiny of critical fellow project participants.

In hindsight, the combination of state vectors and code inspections were the vital reason for the success of this project.

Message Structure

The effect of the state-vector principle was that most of the complexity resided in the message system, while the software itself was very simple and "if-then-else-less".

Here is an example of the message sequences for "Make a synchronized checkpoint"

In order to leave control with the user developers, TPS initiated so-called "Special Applications" at distinct points during the operation. Such Special Applications were either Global, i.e. common for all users, or Local, i.e. meant for a specific user session only.

The user organization decided, what should happen when these defined incidents occurred, by modifying the content of the standard Special Applications.

The System Builder

TPS and its components were not trivial, yet it managed to hide a large amount of complexity for the users, the application programmers, and the operators of the system, once it went into operation.

The final element in this strategy was to make a system builder, which reduced complexity for the personnel that already had many problems to solve and had no need for new problems to deal with.

The developer called the system builder "The Queen of the Night", since heavy batch processing capacity was required once it started.

Actually, there was a complete version (as seen below), and a short-cut version, which skipped some of the more timeconsuming parts, when they were not needed.

The outp and the tota command o

Epi

The

Acknowledgements

Many thanks to Dave Walden, Bo Lewendal, Dag Spilde, Lars Lind, Peter Bonne, Harald Eide, Per Ivar Danielsen, and Stig Nyberg, for their valuable contributions and inputs.