Birger Møller-Pedersen
email: birger@ifi.uio.no

Scandinavian Contributions to Object-Oriented Modeling Languages

Keywords: Languages, modeling, programming

The history of Scandinavian contributions to modeling languages is interesting in many respects. The most interesting part of the history is that some of mechanisms were conceived very early, years before modeling became mainstream. It is well-known that object-orientation started with SIMULA in 1967, but it is less known that SIMULA formed the basis for a modeling language already in 1973, and that the Ericsson AXE software structure (1976) was one of the foundations (via SDL) for composite structures in UML2. It is also interesting that there has been a development towards making mechanisms less particular: while early modeling languages had special structuring mechanisms, UML2 now cover this by composite classes. In addition, early modeling languages were executable, in fact they were combined modelingand programming languages. After a period where modeling was just for the purpose of analysis and design, the trend is now towards executable models, i.e. almost going back to the original Scandinavian approach.

Introduction

This paper tells part of the story of the Scandinavian contribution to modeling languages. We restrict ourselves to the contribution to the de facto standard language for modeling, UML in its current version UML2 [START_REF]OMG: UML: Unified Modeling Language 2[END_REF]. Instead of just making a chronological account of what happened when and who were involved, the story is told with emphasis on language mechanisms, and the paper is organized correspondingly.

For the account of when things happened, we have decided to do it based upon published material, although we are aware that activity often started earlier, see Fig 1.

Object-Orientation

Object-orientation as part of UML has a straightforward history. The main sources are the Booch [START_REF] Booch | Object-Oriented Analysis and Design with Applications[END_REF] and OMT [START_REF] Rumbaugh | Object-Oriented Modeling and Design[END_REF] methods, and these are in turn based upon the concepts of object-oriented programming originating with SIMULA. Booch and OMT were not the first methods for object-oriented modeling, but they directly influenced UML. The OOSE method [START_REF] Jacobson | Object-oriented software engineering: a use case driven approach[END_REF] contributed with Use Cases. SIMULA was developed by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Centre, Oslo, in the 1960s [START_REF] Dahl | SIMULA 67 Common Base Language[END_REF][START_REF] Dahl | SIMULA-a Language for Programming and Description of Discrete Event Systems[END_REF]. A comprehensive history may be found in [START_REF] Dahl | The Development of the SIMULA Languages[END_REF] and in [START_REF] Krogdahl | The Birth of Simula[END_REF].

SIMULA I was a simulation language. It was realized that the concepts in could be applied to programming in general, and the result was the general-purpose language SIMULA 67 -later on just called SIMULA. The SIMULA I language report of 1965 opens with these sentences:

The two main objectives of the SIMULA language are: o To provide a language for a precise and standardized description of a wide class of phenomena, belonging to what we may call "discrete event systems". o To provide a programming language for an easy generation of simulation programs for "discrete event systems".

Thus, SIMULA was considered as a language both for system description and for programming.

It turned out that many users of SIMULA seemed to get more understanding of their problem domain by developing a description than from the actual simulation results. The modeling approach of SIMULA was therefore refined in DELTA [START_REF] Holbaek-Hanssen | System Description and the DELTA Language[END_REF], a pure description language ('description language' was the term for 'modeling language' at that time).

DELTA supported the description of true concurrent objects and used predicates to express state changes and continuous changes over time. DELTA had a goal similar to that of the object-oriented analysis and design (OOA/OOD) methodologies (e.g. Coad and Yourdon [START_REF] Coad | Object-Oriented Analysis[END_REF]) that appeared subsequently in the mid-80s, followed by OMT and Booch.

After the initial ideas of SIMULA, there were two different developments of object-oriented programming: the 'modeling approach' and the 'programming approach'. The main difference between these is on the understanding of objects, classes and subclasses. The modeling approach regards objects as models of phenomena from the application domain, classes as models of domain concepts and subclasses as models of special concepts. SIMULA defined the modeling approach. The programming approach puts emphasis on subclassing as a language mechanism for reuse of code. A subclass does not have to define a subtype of the type of the superclass, and the subclass is free to redefine properties of the superclass. Objectoriented methods in the 1980s followed the modeling approach.

The approach to language design used for BETA 1 [11] was highly influenced by the SIMULA tradition. BETA should be a combined modeling and programming language. The first account of BETA is [START_REF] Kristensen | Abstraction Mechanisms in the BETA Programming Language[END_REF]. The history is described in [START_REF] Kristensen | The When, Why and Why Not of the BETA Programming Language[END_REF].

It was realized already with SIMULA that the class/subclass mechanism was useful for representing concepts including specialization, but there was no formulation of a conceptual framework for object-oriented programming. For BETA it was therefore necessary do develop such a conceptual framework. [START_REF] Madsen | What Object-Oriented Programming May Be-and What It Does Not Have to Be[END_REF] provides a definition of object-oriented programming with a modeling approach.

It was from the beginning decided that BETA should support for full concurrency. As will be seen below, this early Scandinavian work on object-orientation had similarities with the AXE software structure in that it supported concurrent, active and communicating objects.

The primary goal of the OMT++ [START_REF] Aalto | Object-Oriented Development of Interactive Systems with OMT++[END_REF], OMT+ [START_REF] Kruusela | Object oriented development of embedded systems with the octopus method[END_REF], and Octopus [START_REF] Awad | Object-Oriented Technology for Real-Time Systems: A Practical Approach Using OMT and Fusion[END_REF] efforts by Nokia Research Center was improved methods for embedded systems, and not new language mechanisms.

Structuring Mechanisms

Blocks and Block Structure

In the telecom industry, specifying systems as a set of interconnected blocks was common practice already in the seventies as reported in [START_REF] Jacobson | Language Support for Changeable Large Real Time Systems[END_REF]. SDL was one of the first standardized notations for specification with support for such structuring mechanisms [START_REF] Rockström | SDL-CCITT Specification and Description Language[END_REF].

AXE Blocks. In 1976 the paper [START_REF] Hemdal | AXE 10 -Software Structure and Features[END_REF] 2 in Ericsson Review presented for the first time the software structure of the AXE system. This was a result of some years of applying software technology to the area of switching, and in line with most similar efforts, it was based upon non-synchronized communication (by means of signals) between processes. The new thing was the organization of the software in terms of blocks with well-defined interfaces.

The experience with the AXE system brought into development the SDL'76 and SDL'80 by Ivar Jacobson, Nils Lennmarker, and Anders Rockström3 . SDL used blocks with possible substructures of blocks and concurrent, non-synchronized processes with behavior defined in terms of state machines and with well-defined interfaces in terms of signals.

SDL'84 and SDL'88 saw the formalization of both the communication part and the data modeling part [START_REF] Haff | Use of VDM within CCITT[END_REF] [START_REF] Belina | The CCITT Specification and Description Language SDL[END_REF]. The reason was that different tools then would have the same interpretation, and that SDL could be used not only for documentation, but also for making executable specifications.

While block structure in AXE and SDL was a direct specification of what an execution consists of in terms of instances (composition), block structure in programming languages means pure nesting of definitions. Early programming languages had procedures/functions nested within procedures/functions. SIMULA introduced nesting of classes. From being a purely technical mechanism, nesting ended up being conceived as a means (in [START_REF] Madsen | Object-Oriented Programming in the BETA Programming Language[END_REF] coined localization) for describing concepts that depend on an enclosing object.

Nesting in terms of inner classes has made it into main object-oriented programming languages and into UML2.

Object-oriented SDL (OSDL/ SDL'92) was proposed in 1987 [START_REF] Møller-Pedersen | Rationale and Tutorial on OSDL: An Object-Oriented Extension of SDL[END_REF] 4 ; in 1992 these concepts became part of the language [24] 5 . Object-oriented SDL introduced block types and process types, and gates as connection points for communication links between blocks and processes. In addition, specialization (subtyping) was defined for block and process types. For block structuring, the implication was that block subtypes would inherit the internal block structure of the super block type.

OOSE 1992. From the AXE software structure OOSE had blocks with internal structure, and each block had an own behavior in terms of a state machine.

ADL/ROOM. Work on Architecture Description Languages (ADLs) began in the early nineties. This area has produced a number of modeling languages. In 1994, ROOM [START_REF] Selic | Real-Time Object-Oriented Modeling[END_REF] combined statecharts and structuring mechanisms like those of SDL (by capsules, ports and connectors).

Subsystems. When UML16 was adopted in 1997, none of these structuring mechanisms had become part of the language. It had no notion of block (AXE/SDL/OOSE) or capsule (ROOM); an object could only have behavior in terms of methods and not a main behavior as an active object (process).

UML1 had, however, the notion of Subsystem, being a mixture of a Classifier and a Package. As a package, it could contain (among other things) a State Machine, but this was nothing like the behavior of a block. In addition, there are no communication links between subsystems. The paper [START_REF] Övergaard | Interacting Subsystems in UML[END_REF] gives a description of subsystems.

ADLs had Components as the parts of a structure. For some reason Components in UML1 was not a mechanism for structuring systems, but more a mechanism for deployment. This has, however, been changed in UML2.

Composite Classes

When OMG in 1999 embarked upon making the second version of UML (UML2), a group of telecom users (Alcatel, Ericsson, and Motorola) of SDL handed in joint requirements [27]. Structuring of large, complex systems was one of the main requirements. 7SDL had block diagrams with the only purpose of specifying the architecture of systems ( [START_REF] Fischer | Structural and Behavioral Decomposition in Object Oriented Models[END_REF] and [START_REF] Braek | Frameworks by Means of Virtual Types-Exemplified by SDL[END_REF]). In contrast to this, UML1 had class diagrams with classes and relations between classes. Although composition was one of these relations, this could not be used for the structuring of systems, with the implication that UML users had to use packages and subsystems for this purpose, see [START_REF] Garlan | Modeling of Architectures with UML[END_REF].

The 1992 version of SDL supported object orientation by block types and process types, and corresponding subtypes. These types would correspond to classes in UML (when it arrived in 1997), so the obvious requirement for UML2 was that classes should be able to have an internal structures.

ROOM capsules had much of the same properties as SDL'92 blocks. In 1999 the ROOM concepts became parts of a UML profile UML-RT [START_REF] Selic | Using UML for Modeling Complex Real-Time Systems[END_REF]. Fortunately the UML2 saw the SDL2'92 and ROOM concepts as structuring concepts within UML proper and not in a profile. As pointed out in [START_REF] Rumpe | UML+ROOM as a Standard ADL?[END_REF], the way in which UML-RT combined UML with ROOM was not the way to do it; they advocated what more or less became the reality: that structuring mechanisms became integrated with class models.

The discussions described above lead to the notion of composite structures and in turn, these were used to define composite classes and collaborations. A composite structure consists of parts (sets of objects of a given type) connected by connectors. Connectors either connect parts directly or connect ports on parts. The composite structures of collaborations also form the contexts for Interactions, so these parts are well integrated in UML2. This is illustrated in [START_REF] Haugen | Structural Modeling with UML 2.0[END_REF].

The following citation from [START_REF] Selic | UML 2: A Model-driven Development Tool[END_REF] is summing up structuring mechanisms of UML2:

The basis for this set of features comes from long-term experience with various architectural description languages, such as UML-RT, ACME, and SDL. These languages are characterized by a relatively simple set of graph-like concepts: basic structural nodes called parts that may have one or more interaction points called ports and that are interconnected by communication channels called connectors.

A detailed correspondence between SDL and UML2 is described in [START_REF] Møller-Pedersen | From SDL to UML2 -from an ITU Specification Language to an OMG Modeling Language[END_REF].

Languages with support for modeling of architectures typically have language mechanisms designed especially for this purpose. One may easily imagine that the same thing could have happened when introducing this in UML2, i.e. making up a new language mechanism just for this purpose. Fortunately, both SDL and ROOM had been there before. In UML2, therefore, it was recognized that the composite structures, which were needed in order to model architectures, could be seen as a special case of composition of classes. This implied that composite structure became an inherent property of objects, and by being defined for classes, inheritance also applied to structure: inheritance implied inheritance of parts, ports and connectors.

Object Behavior

Mainstream object-oriented languages have most of the original concepts from SIMULA: classes and objects, subclasses, virtual methods, polymorphism, etc. An exception is the SIMULA notion of an active object with its own action sequence (in addition to behavior in terms of methods). Strangely enough, many other programming languages had not adopted this.

In SIMULA, it was regarded as obvious that objects had their own behavior, in addition to behavior associated with methods. Objects were not just intended for the modeling of data entities, but also for processes with their own behaviors.

The AXE design had similarly function blocks with their own behavior (in terms of a state machine), the same with processes in SDL'76. OOSE did not carry this over from AXE and SDL.

UML1 did not have a separate object behavior, although it had the notion of active objects. Booch and OMT followed the trend in programming languages to do this by means of a special method.

UML2 introduced a so-called ClassifierBehavior, so that classes may have a behavior. This extension comes from SDL, ROOM, and UML-RT, and it links back to the original AXE and SDL idea of processes as the main kind of objects.

Although state machines were part of AXE, this was not the only source of inspiration for state machines in SDL'76. The use of state machines was common in telecom and process control systems. UML1 had state machines, but they were for some reason intended for the specification of the behavior of collaborations, and not for the objects taking part in the collaborations, at least according to the semantics specification of UML1. The state machines of UML1 comes from [START_REF] Harel | Executable Object Modeling with Statecharts[END_REF], where objects and state machines were combined. In 1987, Harel introduced structuring mechanisms for state machines, hierarchical statecharts, with composite states containing states and transitions.

SDL-2000 adopted the hierarchical state machines of statecharts, extending them with entry/exit points [START_REF] Møller-Pedersen | Scalable and Object Oriented SDL State(chart)s[END_REF], a kind of interface for composite states, so that states could be entered/exited without having to know to the details of the composite states. Entry/exit points for states are supported by UML2.

Use Cases

The story behind Use Cases is easy to track down. The first paper on Use Cases is from OOPSLA'87 [START_REF] Jacobson | Object Oriented Development within an Industrial Environment[END_REF], and this paper in turn points to two sources of inspiration: the way functions (we would call it services today) were described as part of the AXE development within Ericsson, and the IFIP'86 paper [START_REF] Nygaard | Program Development as a Social Activity[END_REF], where the notions of task and roles in system development were introduced. Use Cases also rest on the shoulders of both the Norwegian and Swedish approaches to participatory design.

Use Cases are sometimes criticized for leading to functional decomposition of systems instead of the object-oriented decomposition based upon objects. However, use cases were conceived in a setting where the system design was made by means of blocks, so use cases were the means by which it was possible to describe properties of the system independently of how it should be structured in terms of blocks.

Use Cases have been a success independent of UML and they are not really dependent on being tightly integrated with the rest of the UML.

Collaborations

Collaborations have two Scandinavian contributions: role modeling and realizations of use cases.

The role modeling method, OORAM8 [START_REF] Reenskaug | Working with Objects: The OOram Software Engineering Method[END_REF] is a method that emphasizes objects and the collaborations of objects playing different roles. It is covered in the survey [START_REF] Wirfs-Brock | Surveying Current Research in Object-Oriented Design[END_REF], and it has been demonstrated at OOPSLA conferences since 1986. Collaborations in UML1 were based upon presentations of the method to the OMG.

Realization of use cases by means of collaboration was presented at the UML conference in 1999 [START_REF] Övergaard | A Formal Approach to Collaborations in the Unified Modeling Language[END_REF]. Collaborations were not part of OOSE, however, one of the co-authors on the book on OOSE contributed to the realization of use case by means of collaborations.

Collaborations were revised (in light of composite structures) as part of UML2, in a way that supports OORAM better than the Collaborations of UML1.

Interactions (Sequence Diagrams)

When SDL was standardized for the first time in 1976, the telecom field (including AXE) also used proprietary variations of sequence diagrams (called Message Sequence Charts -MSC). The 1988 SDL User Guidelines had a short section on message sequence charts as an auxiliary diagram that could be used in combination with SDL.

A paper [START_REF] Grabowski | Putting Extended Sequence Charts to Practice[END_REF] triggered the first standardization of Message Sequence Charts (MSC) in 1992 9 . MSC-2000 [START_REF]ITU: Message Sequence Charts (MSC)[END_REF] refined earlier structuring mechanisms such as MSC references and inline expressions.

UML1 selected a somewhat different dialect similar to, but not identical to MSC-92, as the foundation of sequence diagrams, and did not support reuse and hierarchy.

The approach in [START_REF] Haugen | From MSC-2000 to UML 2.0 -The Future of Sequence Diagrams[END_REF] formed the basis for Interactions in UML2 10 , and the two dialects have reached more or less the same expressiveness, see [START_REF] Haugen | Comparing UML 2.0 Interactions and MSC-2000[END_REF].

Conclusion: Executable Models or Unified Modeling and Programming

It all started out with a combined modeling and programming language (SIMULA), with software structuring (AXE) tightly integrated with a programming language, and a modeling language with an execution semantics (SDL). Although one of the main strengths of object-orientation is that it provides a unified approach to modeling and programming, modeling languages developed independently of object-oriented programming languages, and drifted away from execution and became languages in support for analysis and design. Recently we have witnessed the need for executable models, not just for special domain specific languages, but for modeling in general, and this has called for initiatives like Executable UML [START_REF]OMG: Semantics of a Foundational Subset for Executable UML Models[END_REF]. One may say that this is just a return to how it was in the beginning, but the difference is that executable models may still just translate to implementations in existing programming languages, yielding both a model and a program artifact. If development environments for modeling languages for executable models will not be able to match development environments for programming languages, then users still have to cope with both a modeling language and a programming language, and based upon experience the code artifact will be the dominant. Really returning to the original approach would imply going for a combined modeling -and programming language, see [START_REF] Madsen | A Unified Approach to Modeling and Programming[END_REF] for an account of that. Class models and state machine models will obviously be part of such a combined language, with e.g. interaction models for the specification of execution semantics, while other parts of modeling languages are obviously just intended as support for analysis methods, as with Use Cases.

Fig. 1 .

 1 Fig. 1. Contributions to UML2.

The BETA-project started as a research project (Bent Bruun Kristensen, Ole Lehrmann Madsen, Birger Møller-Pedersen, and Kristen Nygaard). The main implementation effort was done as part of the Nordic Mjølner project.

The reason for one author on this paper is probably that Hemdahl was the key person behind this, although many persons were involved in this undertaking.

Work on SDL started already in 1968, when CCITT decided to find out what to do about telecom and software technology. Telecom operators were the driving forces (e.g. the Swedish Televerket, Gösta Lindberg (CTO)). Anders Rockström joined this effort in 1974.

Started as part of the Mjølner project (Dag Belsnes, Hans Petter Dahle, Birger Møller-Pedersen), where the idea was to develop a new language. After discussions, especially between EB Technology and the Swedish partners (where Anders Rockström and Ferenc Belina were involved), it was decided to go for an extension of SDL.

[START_REF] Dahl | SIMULA 67 Common Base Language[END_REF] The standardization work of OSDL was done as part of the Norwegian SISU-project, where Øystein Haugen and Rolf Braek joined, and as part of the EU-projects SPECS and FORTE, where Ove Faergemand and Anders Olsen from TeleDanmark joined. Anders Ek was a key person involved from Telelogic.

UML1.1, the first version of UML with Scandinavian contribution. The Swedish company Objectory, founded on the OOSE method in 1987, was acquired by Rational in 1995 and contributed with Use Cases and predefined method stereotypes. UML versions up to 1.5 -Karin Palmkvist and Gunnar Övergård contributed to Use Cases, Interactions, Collaborations, and Subsystems.

[START_REF] Dahl | The Development of the SIMULA Languages[END_REF] Scandinavian contributors to UML2: Øystein Haugen and Birger Møller-Pedersen (at that time with Ericsson).

Based upon a former role modeling method[START_REF] Madsen | A Unified Approach to Modeling and Programming[END_REF]. Trygve Reenskaug was member of the UML Core Team, and part of small group that made the first proposal for UML1.1.

A key contributor at the time and subsequently (until his untimely death in 2002) was Ekkart Rudolph of Siemens, Munich.

Øystein Haugen (at that time with Ericsson) was leading this work for UML2.

Acknowledgments. Thanks to Anders Rockström, Rick Reed, Pär Emanuelsson, and Anders Olsen for providing valuable input, and to Stein Krogdahl for careful reading and commenting.


Johan Gribbe
email: johan.gribbe@abe.kth.se

Controlling the Battlefield: Computing and Operational Command in the Swedish Armed Forces, 1966-1989

Keywords: Cold war, main frame computer, military technology, security

In the late 1960s, the Swedish Defence Staff initiated the development of a computerized command and control system that was later to be known as the LEO-system. From the mid-1970s to 1989, more than two hundred million SEK were spent on the project, which involved private computer consultants and with military staff officers acting as project leaders and customers. In the end, however, only the intelligence application was introduced and put into operational use in the Swedish intelligence service during the 1990s. This paper will tell the story of the LEO-system and outline some of the reasons behind its failure. It is based on a witness seminar held at the Swedish Armed Forces Headquarters in Stockholm on January 15, 2008.

Introduction

In the late 1960s, the Swedish Defence Staff initiated the development of a computerized command and control system that was later to be known as the LEOsystem. The decision followed a reorganization of the national command structure and the system was intended to help central and regional military headquarters conduct wartime operations. Each headquarter was to have one LEO terminal system, with a number of workstations, containing information about all aspects of the battlefield. Information about friendly and enemy forces, fuel and ammunition supplies, were to be stored in a central database and a secure messaging system was to provide fast and reliable communications. Additional applications were developed to handle computations and simulations of transports and mobilization times. From the mid-1970s to 1989, more than two hundred million SEK were spent on the project, which involved private computer consultants and with military staff officers acting as project leaders and customers. In the end, however, only the intelligence application was introduced and put into operational use in the Swedish intelligence service during the 1990s. This paper will tell the story of the LEO-system and outline some of the reasons behind its failure. One problem, that many insiders point out, was the considerable passive resistance which the system encountered from both end users and senior commanders when new computer technology was to be introduced in old organizational structures. The critical problem in this case was security. To develop an integrated and computerized command system meant that highly classified information about war plans, communications and intelligence was concentrated in a single computer system, which run counter to the fundamental military principle that an officer should know no more than absolutely necessary to execute the task assigned to him. Measures developed to control access, and to guarantee electronic security, provided little assurance to critics within the officers corps.

Other problems concerned the core technology involved. During more than twenty years of development, the LEO-system survived several different generations of computers, from the mainframes of the early 1970s to the personal computers of the late 1980s, with the basic system architecture intact. How did these technology shifts affect system development? Or put differently: How come the project was not cancelled but rather re-equipped with new computer hardware despite the apparent problems? Finally, it could be argued that the reason behind its failure was cultural and related to the grand ambitions of the system. In fact, there are many similarities between the LEO command system and the management information systems (MIS) developed in the private sector during the second half of the 1960s. The similarities concern both the basic technology and the overall function of the system, and the reasons behind the failures of LEO and other MIS-systems are probably similar [START_REF] Haig | Inventing Information Systems: The Systems Men and the Computer[END_REF].

Some parts of the LEO command system are still in use within the Swedish military intelligence (MUST) and all written documentation about the system and its development is classified. Instead, this paper is based on oral accounts given at a witness seminar held at the Swedish Armed Forces Headquarters in Stockholm on 15 January 2008 [START_REF] Gribbe | LEO: Databehandling och operativ ledning inom försvaret, 1972-89: Transkript av ett vittnesseminarium vid Högkvarteret i Stockholm den 15 januari 2008[END_REF].

Project Initiation and Early Tests

In 1966, the command structure of the Swedish Armed Forces was reorganized. Sweden was organized in so called military areas. The general in command of a military area commanded the army divisions stationed in the region, the regional naval command and the regional air defence sector. The commander answered directly to the Supreme Commander. Each area was named according to the geographical area it covered. After the 1966 command reform, there were eight military areas, from the Upper Norrland Military Area (Övre Norrlands militärområde) in the north to the Eastern Military Area (Östra militärområdet), covering Stockholm and most parts of Södermanland and Uppland to the Southern Military Area [START_REF] Cars | Svensk försvarspolitik under efterkrigstiden[END_REF]. In connection to this reorganization of regional command, the Supreme Commander ordered an investigation of a possible computerization of the military command structure. In terms of ideas, the project had close connections to the Management Information Systems (MIS) that were introduced at this time in many large private corporations. For a discussion on Management Information Systems in private industry, see Gustav Sjöblom's contribution to this volume [START_REF] Sjöblom | The Totally Integrated Management Information System in 1960s Sweden[END_REF].

Work on the new project was formally initiated in 1969-70. As the new system was intended as an integrated operational command, control and communications system for all three service branches, overall systems responsibility was given to the head of the Operations section within the Defence Staff (Försvarsstabens Sektion III). This department was responsible for warplanning. Military officers from deparments within the Operations section acted as "buyers", specifying the functionality of the system, working in team with the computer specialists in charge of applications development. Meanwhile, personnel from the Data processing department of the Defence Staff (Försvarsstabens ADB-avdelning) and computer consultants from private companies were to handle systems development. A military officer, colonel Torbjörn Ottosson, was put in charge of applications development. In 1970, the project was formally named LEO after a headquarters command excercise with the same name. This division of labour between military officers, acting as customers of the applications and subsystems developed for their particular area of responsibility, and the computer specialists in charge of software development -with no project manager in charge of the project -was later to be a subject of much debate and criticism.

Technologically, the LEO systems architecture was closely linked to the large mainframe computers that appeared in the mid and late 1960s. Each headquarter was to have one terminal system, with a number of workstations connected to it, containing information about all aspects of the battlefield. Information about friendly and enemy forces, fuel and ammunition supplies, was to be stored in a central database and a secure communications system, the LEO Message Control System (LEO:MCS) was to provide fast and reliable communications. Information about military forces, their level of preparedness, their fighting values and losses was handled in an application called LEO:SK. Another important area in which computer power could support decision making was transport planning, handled in an application called LEO Transport Planning (LEO:TP) that contained maps and information about roads and railroads and their capacity. Using the transport planning application, military commanders could calculate alternate routes or the consequenses of the enemy knocking out a bridge or a railroad junction. The intelligence application, called LEO:UND, was essentially a mirror image twin of these applications, intended to store the same information about the enemy, his supplies and his fighting capacity.

Computer Procurement

A major user of mainframe computers in the military organization was the the National Service Administration in need of computing and storage capacity to process information about the tens of thousands of young men who did their compulsary military service each year. The computing division of the service administration in Kristianstad had aquired a Burroughs B2500 mainframe computer that was used to test an early version of LEO. A particular advantage of the Burroughs mainframe system was that it already contained a powerful data base handler colled FORTE. After an initial period of testing, formal technical and operational specifications of the LEO computers were issued in 1977-78. While most of the software development hade been handled by personnel of the computer department (ADB-avdelningen), or external consultants tied to it, the procurement of systems hardware was handled by the Swedish Agency for Public Management (Statskontoret) in cooperation with the Swedish Defence Material Administration (Försvarets materielverk, FMV). In the end, four competing companies/systems remained: Norsk Data/Nord-series, Datasaab/Censor 932, DEC/VAX-11 and minicomputer from Burroughs. In November 1979, Norsk Data was chosen as the supplier and three of its Nord 100 computers were ordered to be used with Alfaskop data terminals.

At the same time the first problems started to appear. By the late 1970s, the LEOproject had already dragged on for almost a decade without an operational system even being close to completion. Several technical problems had come to light. A major problem was still limitations in computer graphics and presentation technology and in addition, the security of information stored in the system started to be a concern. It was clear that the LEO-system, while functioning at exercises, could not live up to previous expectations. Gert Schyborger, then project manager at the Defence Staff, recalls two opposing sides at this time. On the one hand, those who considered the problems to be causes of delay, not reasons to discontinue the entire project. According to them, the project should be allowed to continue with the hopes of a technological fix along the way. On the other hand, those who considered the whole idea of a central computerized system for operational command to be premature and who thought that it should be abandoned right away. The dispute ended in what could be labelled an organizational compromise. The position as project leader was separated from the position as chief of the operations section within the Defence Staff, and a special project manager was appointed. The task of implementing the LEO-system on a smaller scale, while awaiting new technological developments, was assigned to colonel Orvar Lundberg in 1981. The fundamental issues, however, were not resolved and the project was to become a source of conflict throughout the 1980s.

This internal debate on the future of the system coincided with shifts on several important positions within the military high command. Throughout the project supreme commander general Stig Synnergren had been a keen supporter, but he was replaced in 1978 by the more sceptical army general Lennart Ljung. The most important shift, however, took place at the position as head of the Defence Staff where vice admiral Bror Stefenson succeeded Bengt Schuback in 1981. Stefenson, like a number of other high-ranking officers, believed LEO to be a waste of both time and money and openly declared to the new project manager Orvar Lundberg that "he did not believe in automated computer processing and that there should be no new system". By this time, however, the decision to build the system was firmly anchored in decisions within both the military high command and the government. Stefenson did not have the authority to discontinue the project, but he did control the funds and during the course of the 1980s, Lundberg saw his project increasingly stripped of economic resurces and manpower. Behind the resistance from Stefenson and other senior officers, however, lay deeper concerns than just the short term financial aspects of the project. Which would be the wider consequences of introducing computer technology in the military command structure?

Security Problems and the End of the Project

On the one hand, the idea of commanding the armed forces through an integrated and centralized computer system -with the supreme commander and his staff in the center -seemed almost congenial with the hierarchic nature of the military command structure. If properly used, computer technology could be a means of strengthening and consolidating the traditional military chain of command. On the other hand, however, the system architecture violated other equally important military principles in a way that was not obvious when the system was first conceived. To develop a computerized command system meant that highly classified information about war plans, mobilization schemes, communications and intelligence was gathered in a single computer system, something which ran counter to the fundamental rule of military security that an officer should know no more than absolutely necessary to execute the task assigned to him. What would, for example, prevent a military officer from tapping the system and handing over classified information to the enemy? And how could orders issued within the system be authenticated? Wouldn't it be possible for lower level commanders in wartime to issue orders that were either outside their area of responsibility or, in worst case, deliberately false and misleading?

These weaknesses could not easily be corrected without changing the overall systems architecture. Measures developed to control access, and to guarantee the security of classified information stored in the system, provided little assurance to the critics within the organization and these problems were probably an important reason behind the considerably passive reaction the project encountered among influential senior commanders. Another problem subject to much debate at this time was that of electronic security. In the late 1970s, it was discovered that computers, and monitors in particular, emitted relatively strong electronic signals that could be picked up and used to tap the system of secret information. The resulting measures to secure the system caused the cost of systems hardware to increase threefold, while the cost of communications and installation increased almost by a factor of ten, causing a severe strain on the already limited project budget and resulted in further delays. This increase in the cost of communications resulted in large part from the addition of a fiber optic communications network, a new and unproven technology at that time.

Despite the security problems, the dramatic cost increases and the lacking support from senior military commanders, the project dragged on during the first half of the 1980s under the leadership of Orvar Lundberg. Development work was allowed to continue, the many internal computer programmers and external consultants tied to the project were paid, and several new applications were added to the system. A limited test version of the system called LEO-80 was installed at the military headquarters in Stockholm, beginning in 1981. However, despite a formal decision in 1984 to implement the system, no additional funds were made available to buy new hardware and more computers that could meet the new security standards.

This situation continued until 1987 when the most outspoken critic of the project, vice admiral Bror Stefenson, finally retired and was replaced by general Torsten Engberg as head of the Defence Staff. Engberg had a more sympathetic attitude towards the project in general and decided that the by now largely dormant LEOsystem should be refurbished with new hardware and put into operational use. The annual budget assigned to LEO was doubled to thirty million SEK and to mark the shift the new name LEO-85 was decided. At the same time, the project management was renewed when commander Lars-Erik Hoff, who had served under Engberg at the navy staff, replaced Orvar Lundberg as project manager. Hoff faced a fundamentally different situation than his predecessor both in terms of funding and support, and a period of rapid expansion ensued. After less than two years, in 1989, all regional headquarters had been equipped and the system was declared operational.

In the end, however, this proved to be only a temporary success. In 1994, work on a replacement system called ORION was initiated. Originally, ORION like LEO was intended to be a secure wartime communication system for military operational command, capable of handling both open, secret and top secret information, but this goal was never achieved. During the 1990s, the system, as used by central and regional headquarters, had gradually evolved into a system for the handling of intelligence. In 1999, development work on all ORION applications but the intelligence subsystem was discontinued, almost thirty years after the LEO project was initiated. This latter part of the system is still in use within the Swedish military intelligence organization.

Acknowledgments. I am grateful to Handelsbankens forskningsstiftelser for supporting the research for this paper. I am also grateful to my colleagues within the project, "Precursors of the IT Nation: Computer Use and Control in Swedish Society, 1955-1985" for comments on earlier versions of the paper.


Jacob Palme
email: jpalme@dsv.su.se

Before the Internet: Early Experiences of Computer Mediated Communication

Keywords: Bulletin board systems (BBS), computer conferencing, computer mediated communication (CMC), forum software, personal protection legislation, privacy legislation

In the 1970s, some people believed in using computers for making almost any information available to anyone and for supporting information exchange and discussions regardless of geographical distances. These ideas were, at that time, novel and revolutionary. Some people regarded these ideas as dangerous; for example, the Swedish Data Inspection Board (Datainspektionen) forbade people from storing email messages for longer than one month as well as from discussing political and religious issues using computerized forum systems. Although people tried hard to implement systems and had some limited success, the ideas became successful with the public usage of the internet in the 1990s. Many had hoped to realize this much earlier.

Introduction

Some people feel threatened by computers; others feel computers enhance their opportunities. I have been using these machines since 1963 and have been working in the area of Computer Mediated Communication (CMC) since 1975. This paper attempts to summarize my own early experiences and attempts to use computers as an aid for human communication.

Public View of Computers in the 1970s

The public attitude to the effects of computers on society in Sweden in the 1970s was that computers would: 1. Impoverish work tasks, causing more repetitive work and diminishing the capability of employees to influence their work situation and improve their skills.

In addition, computers or unskilled labor would replace skilled professionals such as typesetters. 2. Become tools of the government as well as large companies and organizations to control people to an unprecedented degree. 3. Become unavoidable entity to maintain industrial competitiveness, despite the two aforementioned serious drawbacks, because if we do not use computers we will be outcompeted by other countries [START_REF] Palme | A Personal History of CMC[END_REF]. It is not surprising that people had this view of computers in the 1970s. At the time, computers were so expensive that only the government and large organizations, not ordinary people, could afford to use them as tools.

A Few People Had a Different View

However, a few people worked with computers and recognized the potential for something vastly different. For example, Torgny Tholerus [START_REF] Tholerus | The General Public Democratic Information System, Datalogilaboratoriet[END_REF] wrote a paper titled "Computers for Everyone" (Swedish title "Allmänhetens informationssystem"), which proposed that computers could be used as tools for a new kind of free speechwhere anyone was able to have their say in ways which enabled everyone to listen.

I myself, Jacob Palme [START_REF] Palme | The General Public Information System[END_REF], wrote a paper titled "The General Public Information System" proposing people should use computers to handle textual messages, where anyone could write what they wanted and everyone could access the information and comment on it. I also wrote an article for the newspaper, Dagens Nyheter, in 1975 [START_REF] Palme | Lägg nationalencyklopedin på data [Put the National Encyclopedia on a Computer Medium[END_REF] proposing that the new Swedish National Encyclopedia should be published on computer networks, available to everyone, instead of as a set of printed volumes.

Murray Turoff said that computers were like books of white paper, where anyone could write on the pages and everyone could read what other people had written. In 1978, Murray Turoff and Roxanne Hiltz wrote a book [START_REF] Turoff | The Network Nation[END_REF] titled "The Network Nation," which describes much of what the internet has become today. On two occasions in the late 1970s, Tomas Ohlin invited Murray Turoff and Roxanne Hiltz to Stockholm, to present their ideas to a group of people including myself, Ohlin, and Tholerus. Turoff's talk was pivotal in stimulating our work in this area.

In 1971, Tomas Ohlin wrote an article for the Svenska Dagbladet newspaper [START_REF] Ohlin | Local Democracy in Telecommunications Age[END_REF] proposing home terminals so that people would have better access to government documents and be able to take part in computerized citizens' panels to enhance democracy. Between 1978 and 1981, Tomas Ohlin was the secretary of several government committees (e.g., the information technology committee, Informationsteknologiutredningen, and the commission on new media) which, among other things, proposed that simple, low-cost home terminals could provide access to databases of linked pages, and that consumer information should be available through the same terminals [START_REF] Ohlin | the Commission on New Information Technology[END_REF].

What we all had in common was that we regarded computers as tools for making all information available to everyone. We thought that people could use computers to give more information to more people and allow more people to make their ideas available to others. This was contrary to the then public view of computers as tools used by the government and large companies to watch over and control ordinary people. None of us expected that it would take more than ten years before our expectations would become reality.

Today, many ideas of Ohlin, Palme, and Tholerus came to realization everywhere, with the internet providing the basis of the free exchange of ideas and knowledge, where anyone can put forth whatever they want, and where everyone can read what others have written. Nevertheless, in the 1970s, we were a kind of underground movement trying to advance our ideas in the rather unwilling public opinion of the time.

In the mid-1970s, Ohlin was working at a government agency for research funding. Together with a small group of partners, Ohlin started the Telecommunications and Regional Development (Terese) project in Sweden that included studies of pioneering communication software. This project, carried out through social trials of computer conferencing in the north of Sweden 1976-77, used the then unknown Planet narrowband communication system, with fifty writing terminals equipped with acoustic modems. They applied the system to applications concerning transport, education, and health services, among others.

Development of the KOM System

A small number of people, mainly researchers at DSV, KTH-NADA, and FOA (the Defense Research Establishment of Sweden), also used Planet. All were fascinated by its potential. At that time, the Swedish government decided that FOA should divide into parts at different locations around Sweden. This decision made it possible for me to get FOA to finance the development of a new, more powerful forum system [START_REF] Palme | History of the KOM Computer Conferencing System[END_REF].

Our system became rather popular; at its peak in 1987, it had thousands of users. Although small compared to the internet of today, it was the largest of its kind in Sweden at that time. We also connected to the internet in 1982, the cost partially funded by Skandinaviska Enskilda Banken. This internet connection was restricted to email and mailing lists, and did not constitute full internet connectivity.

We conducted a number of studies on the effects of this kind of software [START_REF] Palme | Experience with the Use of the COM Computerized Conferencing System[END_REF]. From the results, we were able to conclude, among other things, that people agree more often than they disagree in online discussions, that online discussions increase the communication between people organizationally or geographically, and that this increase is especially noticeable with regard to younger people, non-management, and those without higher education. Older people, management, and those with higher education already seemed to have access to cross-organizational and cross-location communication through travel, before using computerized communication. We also found that computerized communication increased the equality between different people with regard to them expressing their opinion, compared to previous communication methods.

In 1982, we distributed the system, installing it on three computers at QZ (the Stockholm University computing center, at that time, including FOA), at DSV, and at KTH-NADA with the exchange of messages between the systems. For many years, the system was a major tool for internal communication within DSV. Today, DSV uses First Class for this purpose.

Our first attempt at starting this system met with disaster; the Swedish Data Inspection Board [10], a government agency for the control of computer usage, had forbidden the use of our system. According to the Data Inspection Board, our system allowed people to store "free text" in which they could write "anything they wanted," while the Data Act, according to their interpretation, forbids storing information in computers except for certain specified fields with explicit limitations on what could be stored in them! The principals at FOA did not dare appeal this decision to the Swedish government, although such an appeal would have been an interesting test of whether freedom of speech through computers was legal or illegal. Instead, the principals at FOA and the Data Inspection Board negotiated an agreement that prohibited us from writing any messages on subjects designated as sensitive information, according to the Swedish Data Act, such as political and religious opinions, among others! We were also obliged to delete all personal emails after thirty days and all discussion messages after three years!

We finally received permission, started the system again, and promptly disobeyed the rules, discussing such sensitive political issues as whether or not one should allow nuclear power. I also archived all public discussions for more than three years, contrary to the instructions from the Swedish Data Inspection Board, posting a selection of them on the internet [START_REF] Palme | Det var en gång för länge sedan: Diskussioner ur KOM-systemet vid QZ, Sveriges första BBS: Dokument ur den svenska datorhistorien[END_REF] for anyone to view even today. I am still waiting for the Data Inspection Board to prosecute me for this breach of the agreement.

A Threat to Personal Privacy

Case 1: "The credit card company notes that Mr. X and his wife are registered for a double room at a hotel in London. At the same time, his wife uses her credit card to pay her hairdresser in Sweden." This is a typical example of the arguments given by people about the threat of computers to personal privacy.

Case 2: An American computer company decided to add to their internal email system a facility that lets the sender check if and when someone reads an email. This caused an uproar among employees who felt that such a facility was an invasion of their personal privacy.

Case 3:

In 1979, we introduced the KOM forum system, which gave users many opportunities to check on each other. A KOM user could see to which forums another user subscribed, when that user last visited a particular forum, when a user read a personal message, and so forth. In spite of such opportunities, very few complained that this was an invasion of privacy. Why? We did add a facility that enabled KOM users to say that other users should not see their personal information. However, almost no user employed this facility to protect their personal privacy. Why not, if there is such a large risk with regard to intrusion of personal privacy using computers?

Case 4: Nevertheless, there was a conflict in one case. The director of studies at a university department started a mandatory forum for information to teachers. After some weeks, he made a printout of the KOM page showing the teachers that had not participated regularly in this forum and he put a copy into all their actual mailboxes. His admonition on this copy "You are all obliged to participate in this Forum!" caused uproar among the teachers.

In trying to analyze these cases, my conclusion is as follows: When people complain about "a threat to personal privacy," their real objection is actually against the use of computers to try to control them. The reason so few KOM users (Case 3 above) complained was that they designed KOM mainly to be under the control of each user. According to KOM users, KOM enabled them to control their usage. They could choose to which forums to subscribe, when to go to a forum, in which order to read news, as well as what to read and what to disregard. Due to this design, they did not feel that KOM was trying to control them.

People thought their personal privacy was threatened when they felt that large companies and organizations "spied on them" and used this information to gain power over them. Since KOM was not (usually, Case 4 as an exception) used in this way, people did not feel that KOM threatened their personal privacy, although KOM did allow users to see much personal information about other KOM users. This is very important, because if we believe that the problem regards a threat to personal privacy, we may try to resolve it with methods that make the problem worse and not better. By understanding that the real issue is about control and power, we can solve the real problem through the design of software that does not impoverish the user and by making it difficult for large organizations to use the computer to control people.

What Were People Really Afraid of?

This fear had made me think about how computer systems should be designed so humans make decisions, not computers [START_REF] Palme | Can Computers Decide What Is Right and Wrong[END_REF].

In other cases, the Swedish Data Inspection Board has tried to forbid an author from writing a book with personal information in it. The author appealed this decision to the government, which wisely said that freedom of speech is more important than the Data Act. The board then prosecuted a person who used the internet to criticize practices of Swedish banks. The lower court found the person guilty, but not guilty in the highest court of appeal.

The Data Inspection Board will probably not prosecute me for violating their rules, because they could be somewhat ashamed of their history of trying to prevent freedom of speech on the internet. They have attempted to do this a number of times, but the courts most often declared their decisions illegal on appeal. Apparently, those appeal decisions were based on a better understanding of the democratic principles protected by the Swedish constitution than the Data Inspection Board's understanding of the same principles.

In 1982, I asked a friend of mine, Olle Wästberg, who was a member of the Swedish Parliament at the time, to submit a private member's bill specifying that freedom of speech should override the Swedish Data Act. The parliament rejected the bill without any specific reason! Our computer system for information exchange attracted a great many users, but it received mixed reactions from the media. Some journalists wrote positive articles about the opportunities, others wrote scandal articles, selecting the most ridiculous texts written by any of our thousands of users and presenting them to discredit our system. At that time, my belief was that the media were afraid of losing their monopoly in providing information to a large number of people.

Other organizations made several attempts during the 1980s to develop similar systems, some met with partial success, others not. Notable failures were the Teleguide system in Sweden and the Prestel system in the U.K. However, a notable success was the Minitel system in France. Minitel was the only system that existed before 1990 that is comparable to the internet today. Why did Minitel succeed, when others did not? The main reason is that Minitel allowed any information provider to put whatever they wanted on the Minitel network. Just like the internet of today, the competition between information providers generated many services where some failed while others were very successful, was the reason for the success of Minitel and the internet.

Conclusions

•

The success of human society is based on the flexibility of humans and their willingness to adapt their activities to different circumstances.

•

Humans are most happy and productive when they can influence their living environment and contribute to solving problems together.

•

Laws and regulation are a form of communication between humans. They are in reality only guidelines, people have to adapt to varying circumstances and interpret and apply the rules with understanding and human compassion. If everyone had to adhere 100 percent to all laws and regulations, human societies would no longer function.

•

Laws and regulations written on paper usually present no problem. However, if the laws and regulations are programmed onto computers so computers control what is allowed and not allowed, serious problems will often occur. In the best case, people will only be unhappy and unproductive; in the worst case, a major catastrophe could occur.

•

The design of computer software must allow flexibility and human choice. Humans should interpret laws and regulations, not machines.

•

Making software more complex so that it includes more specific handling of special circumstances will often only make it worse. Instead of complex software, it should be flexible and open-ended.

•

There is a human tendency when designing software to include "proper procedure" and "experience how things should be done." This tendency can easily produce unusable or unsuitable software. • A possible exception to the above occurs when we need to enforce security rules to overcome human weaknesses.


Yngvar Lundh
email: yngvar@ifi.uio.no

Norwegian Computer Technology: Founding a New Industry

Keywords: Computer, display, hardware, light pen, magnetic core, memory, reliability, transistor

Norway had a successful computer industry. A small group of young research engineers who saw a new era and started "from scratch" founded it. They were able to harness and exploit the rapid development by a basic technical research project.

Introduction

In the early 1960s, a small group of enthusiastic young engineers developed some basic computer technologies. They built their own basic knowledge and created digital circuits, devices and systems, based on technical literature and academic visits to the United States. They made no contact with similar projects. In the late 1960s, members of the group initiated and had the quintessential knowledge in Norsk Data, Informasjonskontroll (ND) and a new division of Kongsberg Våpenfabrikk. These were successful industrial enterprises; ND became large indeed. This is my account on the way the fostering of the technology and the enthusiasm occurred.

Study

As a student of electrical engineering at the Norwegian Technical University -NTH -I was looking forward to my final thesis term in 1956. I had come across a book about the "Mark1"-effort at Harvard and other "electronic brains." I asked docent Jens Balchen whether he might be interested in giving me a topic in that area. Balchen had made an impression by his open mind and his singlehanded development of the analog computer "Diana." I had invited him to tell us about it in our radio club, where I spent my spare time with fellow students rebuilding the ham radio station that had been nonexistent since the war.

After a while I was told that nobody at NTH had the knowledge to suggest a topic for study of electronic brains. However, Balchen's friend research engineer Karl Holberg of the Norwegian Defense Research Establishment -NDRE -at Kjeller, proposed a topic. They invited me to do my thesis work there and to investigate an idea, proposed in a journal. That method could multiply, add and divide numbers represented by frequencies of pulse trains. I called it "Siffer frekvens systemet" [START_REF] Lundh | Digital Techniques for Small Computations[END_REF]. Programmable computers were very costly indeed, and cheaper means of computing might be useful in automatic control, signal processing etc. I subsequently worked for NDRE until 1984.

Solid State Devices?

In that investigation, I built a set of modules to be interconnected and used for experiments. The modules were binary dividing chains and counters, all implemented by vacuum tubes. During that term and for the next couple of years I did much reading about circuits and devices that might be usable for digital systems. I became concerned by reports of the limited lifetime of vacuum tubes and the ensuing unreliability of systems.

One fellow student's diploma work had been to investigate if a small, much heralded, component, called transistor, might be useful for hearing aids. His professor brought him a sample from an American laboratory. The student had sadly concluded: No. However, transistor radios came on the market. Solid-state components became a promising possibility for replacing tubes in the future. Many practical factors made that choice a long-term one. Between various assignments at NDRE after my graduation, I was able to do a fair amount of reading about solid-state devices. I was especially intrigued by magnetic devices also. Could we possibly use them for implementing logic functions?

I tried to obtain answers to some more or less wild questions and ideas by the assistance of graduate students. Both professors Balchen and Westin at NTH and Tangen at the University of Oslo (UiO) accepted some of my ideas for topics of thesis work for their students, some of them quite brilliant. I served as their advisor and they did their studies as members of our research group at Kjeller. All of us gradually became captivated by the possibilities we saw in digital technology.

From the United States

I saw reports about "mathematics machines" such as BESK, DASK and NUSSE, but -rightly or wrongly -I decided to seek solutions that were more promising. I was warned by prominent research committee members that such machines, now in development elsewhere, would have adequate capacity for the foreseeable mathematics market, hence precluding need for Norwegian effort in that area. I decided to spend some time in the United States, where computer technology now apparently was actively being developed and exploited. From august 1958 through 1959 I worked at MIT in the famous Servomechanisms Laboratory, first as "guest" living on a fellowship awarded by the Norwegian research council, later employed by MIT as manager of a project to develop a "pulsed analog" computer. Besides auditing classes in signal theory and automata, I spent much of my time in the special lab established around a computer called TX-0.

As a computer, the TX-0 was somewhat odd as it was built for a special purpose. It was, however, a truly programmable computer; it had a good directly driven CRT display, and -most important -its circuits were all transistorized. Moreover, it was available! I could sign up for time and then use it solely for my own purposes. That was rather different from MIT's main computer center. It featured a monstrous IBMmachine occupying its special wing of the building, with users delivering stacks of punched cards through a window and receiving thick printouts.

Part of the time I went around the back of the "little" TX-0, studying circuit details using an oscilloscope. Additionally, I learnt how to program it, meticulously punching machine code on to paper tape. My proud top success was when the Boston Globe published a story about my program that enabled people to play Tic-tac-toe with the computer, using a "light-pen" that could paint on its display screen. Well, machine code -someone developed a program to translate "mnemonic" three-letter codes, a precursor to assembly code, making the bits of the machine code much easier to remember.

All of this made me entertain ideas that we must develop such machines back home, only much better ones. Karl Holberg, who stopped by the lab on one of his visits in the US, supported the idea heartily. I was even more dedicated after visiting a conference in Boston, where Kenneth Olsen displayed a "programmed data processor" -PDP-1 -a computer to become quite important later, the incipient "minicomputer." Olsen, who told me his parents had come from Fredrikstad, Norway, had started Digital Equipment Corporation after finishing his central role at designing the TX-0 and much else at MIT's Lincoln Lab. We had DEC's logic modules at the TX-0 lab.

Building a Development Team

Back at Kjeller in 1960, I was first disappointed to learn that finding resources for developing a computer would take time. However, something else came up. Someone had theorized on ideas that digital techniques could possibly enhance signals buried in noise. This idea could develop into an important project; someone would be happy to finance a digital signal processor if one could build it. I was lucky to be able to propose one. Money became available and there was a need to see results soon. An intense development program began. It resulted in a machine consisting of four large cabinets full of transistorized digital circuits. It worked as planned, processing signals. The only thing it could do was that process, but it did perform it in real time, which was beyond what known programmable computers could do at the time.

To deliver that machine quickly, we had to employ some new engineers. We soon became a group of young engineers. Two of them, fresh after completing their thesis work in digital electronics were Lars Monrad Krohn and Per Bjørge. A period of intensive development began. We viewed some issues very seriously and they were probably decisive for our success.

Transistors!

Without doubt, transistors would be the active components! Some were now commercially available, but critical characteristics varied greatly. We needed hundreds of transistors. Circuits were carefully designed using classification of each component type to make the circuit perform to specifications even in the most unfavorable combination of values. We called it a worst-case design. We designed and implemented a few building blocks on printed circuit boards. Typical modules were a "flip flop" and an "inverter." We could implement any digital logic using the modules. Great care ensured standardized compatibility; each module carefully documented with practical rules for interconnection. Extensive work went into the mechanical design of racks, "drawers," guides for cards, and interconnection plugs. It is fair to say that Monrad-Krohn was an essential force in that design process. He spared no effort to meet requirements to ensure reliable performance and he inspired the entire group with his overwhelming energy and his uncompromising determination. Bjørge was an eminent designer of circuits meeting worst-case requirements. A pioneering spirit was growing. "Printed circuits" was something we had heard of, but never seen. Numerous considerations aiming for reliability went into combined effort of the little team of engineers fresh out of university (Fig. 1). The complete machine, named "Lydia," was put to work in March 1962.

Our development must have made impression. It now became possible to think of a general purpose, programmable computer, a dream not forgotten since my return from MIT. Holberg, now leader of a large project, foresaw the need for a machine to handle experiment data and assigned Siffergruppen, now an honorable name, to build one.

Fig. 2. SAM.

The goal of the new project "build a computer as fast as possible" was unusually vague. However, reflecting on our ambitious attitudes prevailing at that time, "mathematics machines" were exotic news items. The project was named SAM, for simulator of automatic machinery. The same team, augmented by a couple of new candidates who had just completed their theses and became associated members of the group developed it. SAM, a fast programmable computer for that time, was developed and built. It was used for experiments at NDRE until 1973. Since then, it has been an exhibit at the Technical Museum in Oslo.

Transistors then on the market were much better than those we had used in Lydia, but way too expensive. We estimated need for more than one thousand. However, I had noted a tendency of extreme price falls happening to new components that became winners in the market. Hence, we carefully studied ambitious market launches of very fast transistors. The advent of the planar process had made possible competing production of equivalent transistors. Semiconductor companies now recognized that "second sourcing" of components was now a necessity in the market rather than something to avoid. These were two factors of unquestionable importance for the use of semiconductors in computer circuits from the early 1960s. Gambling on a dramatic drop in prices, I bought samples of some promising transistors. Prices were exorbitant, so I could only buy three samples for testing and circuit design. We were lucky to pick winners in that race. A few months later when we needed a great number of those transistors, prices had fallen even more than expected. The speed of our new logic circuits had increased several hundred times over those of Lydia. We retained the mechanical standards of cards and interconnection.

In a process over several months, the overall design of the computer was defined in detail. It ended up with features that turned out to point ahead while some were dead ends. I had kept my belief in magnetic components. For the main computer memory, I meant to see a future for thoroidal magnetic cores. Reportedly, they were promising and some companies began to offer them commercially. A study-process made us end up buying from Philips a complete matrix of 64x64x25 bits. Olav Landsverk was responsible for careful design of driving and sensing circuits, including error detection logic. That became the main memory of SAM and it worked fine. I became intrigued by a possible design of an associative memory, using multi-aperture magnetic cores, and soon, we started the circuit design for it. SAM's instruction set contained commands for the associative functions. I found out later in the design work that some clever commands using the ordinary memory would outperform the associative ones. So, we abandoned the idea of associative memory -fortunately. The concept of index memory emerged during those months. We purchased some "very fast" experimental memory modules using thin magnetic film deposited on glass rods for it. Suitable drive circuits were designed, and they worked. I believe the experience of that effort was more valuable than the resulting improvement of computing power. We pursued a number of ideas during some quite creative and busy months.

From my experience with the TX-0, I was convinced of the value of a display screen for which a pen light made interactive. We did not see computer screens for many years to come, of course. I had found a rather special device, called the Charactron Shaped Beam Tube. It projected character symbols on the screen by a form of electron optics. Purpose was to make the display faster and more responsive in interaction. The Charactron was large, it required very special drive circuits indeed, and was expensive. Moreover, it was sensitive of the earth's magnetic field and had to be completely shielded in a "mu-metal" casing. A new member in our group, Knut Korsvold, made the entire design. He met a design challenge of unusual complexity, and succeeded. The display worked reliably. A little device called light pen also comprised some tricky problems. Bugge Asperheim developed a working light pen connected to the display.

The complete machine was developed, built and was working by mid-1964. Later some further additions were made to it. In August 1964, we presented several papers about SAM the NordSAM conference in Stockholm [START_REF] Holberg | Regnemaskinen SAM[END_REF].

Confirming Experience

During the same period, when SAM was under development, we received another challenge. The telecom administrations of Sweden, Denmark and Norway had decided they wanted to begin experiments with satellite communications. They needed a system to steer a large antenna for experiments. Ground stations for that purpose had been built in some other countries. They were computer controlled, but that made them too expensive for the Scandinavians' budgets. I was asked for a suggestion, and luckily was able to come up with a proposal that the telesatellite committee accepted. Using the well-proven Lydia type modules, we built a special purpose machine that could predict the pointing coordinates of the antenna. Jan Garwick, astronomer and head of NDRE's mathematics section, helped me with the mathematics of approximation of the predicted ephemeris data of satellite orbits, by second-degree polynomials. The machine used the principles of "Siffer frekvens systemet" that I had investigated in my thesis.

The electronics filled four large cabinets of card modules. The machine, "Rasmus," was installed July 1964 at the antenna station at Råö in Bohuslän. Einar Evensen of NDRE developed the powerful servo system that converted the analog output signals from Rasmus into physical pointing angles of the large antenna. The 25-meter disk was a radio telescope built for astronomy. It became available to the telesatellite committee for telecommunication experiments, and now enabled the telecom administrations to demonstrate, for the first time, direct transmission of TVsignals from California to Scandinavia. Again, a special purpose computer had become the solution in real time control.

Software

Various bits and their combinations defined the instruction set of SAM. Commands had three letter "mnemonic" names. We recognized the need for an assembly program. Martin Vånar doing his thesis work in our group was inspired by Jan Garwick's ideas of program structures. Vånar wrote a great assembler called Samba. (Garwick's group became a source of some powerful software innovations, but that was later). Monrad-Krohn now came back from a sabbatical year at MIT, full of new ideas and enthusiasm, especially about programming. Thinking that Samba was too complicated, he quickly wrote an assembly program called Asem. It became the dominant software tool for programming SAM. The ideas of operating system programs did not really occur to us until a little later.

We learned many lessons during these years. First, we began to understand the workings of computers. We saw that it was possible to make them. We learned how to use them, how to do things, and what not to do. From the end of 1964, Monrad-Krohn headed Siffergruppen, when I had to leave for another assignment. The group went on growing and developed newer and better machines. SAM-2 was developed for some real time applications. Growing knowledge was valuable. Integrated circuits had now become a reality. Features of SAM indicated what was good, and what was less valuable. We built experience.

Some new young engineers and students joined from time to time. Rolf Skår was one of them. As a period of industrialization began, several members of the group left, to join the new organizations. In 1967, time had come to go out and industrialize this know-how. Three members of Siffergruppen, Lars Monrad-Krohn, Per Bjørge, and Rolf Skår, took the initiative to found a new company, later called Norsk Data -ND. Martin Vånar founded a consulting company -Industrikontroll. Kongsberg Våpenfabrikk -KV -employed Olav Landsverk and others. Several books were written about that period [START_REF] Wicken | Norsk datahistorie. Prizewinning essay[END_REF].

A computer for field artillery was the next great opportunity that came up. It ultimately became a great success for KV. In a short time, commercial ideas and marketing realities had pervaded the group. Technical arguments between the two emerging industrialists ND and KV appeared belligerent. The atmosphere smelled hostile. Probably the competition was a useful stimulus, though, viewed in retrospect.

Both launched their series of "minicomputers" -in competition. As for myself, I wished them success, but after careful consideration, I decided to stay with NDRE and attend to some other opportunities. Each of the companies achieved significant success. ND became large and for a while, it was the largest corporation in Norway, measured by stock value [START_REF] Heradstveit | Eventyret Norsk Data: En bit av fremtiden[END_REF].

Trust and Success

Our success was partly due to the "state of the art" in that period. We were able to make early use of some unique devices as they became available, hence getting a good start on the international scene. Most important was the rapid development of semiconductor components and circuits. Our results were ready for commercial exploit when minicomputers were making computing affordable for many new applications. There was a large and rapidly growing market.

Even with that, the success had not happened, were it not for the ability of those young engineers. They designed intricate computer electronics with enthusiasm and certain knowledge. It could be done, and it should be! Some of the design details of those early experimental circuits were quite difficult ones. Resources were small, creativity was great, previous experience was nil. We were reading about many types of difficulty leading into trouble elsewhere. That gave us respect for potential dangers. We were thus motivated for careful design, trying to think of everything that could possibly go wrong. Specifications, limits and tolerances became household words. Throughout our little organization, everyone was conscious of the great potential of this wonderful new digital technology. We had promised that we could do it. We all thought that it was always up to us, only to ourselves, to succeed.

A significant reason for the success was trust. Karl Holberg gave us the permission to go ahead and develop SAM. It can best be called basic technical research. He shared my vision that digital techniques were to become important. He invented a possible application in a quite different large project, set aside a sum of money and assigned Siffergruppen to the task. In his own joking language, he said he stole the resources. Had we not succeeded in demonstrating unique performance and promising technology, that joke might have turned rather sour. He never told us what to do, but trusted us to do what we had promised. The enthusiasm and responsibility felt by every member were most valuable results of that trust. Young people were stimulated to take responsibility and do what they were good at doing. Self-confidence carried over into the industry it spawned, and continued to grow.

Fig. 1 .

 1 Fig. 1. "Siffergruppen" and the "Lydia" digital signal processor. From left: Per Bugge-Asperheim, Svein Strøm, Per Klevan, Lars Monrad-Krohn, Per Bjørge, Asbjørn Horn, Olav Landsverk, Yngvar Lundh (Ove Raffelsen not present).