aeg-telefunken tr 440: software und software-entwicklung

DOI 10.1007/s00450-008-0046-4

R E G U L Ä R E B E I T R Ä G E

Informatik Forsch. Entw. (2008) 22: 237–266

AEG-Telefunken TR 440:Software und Software-Entwicklung

Hans-Jurgen Siegert

Eingegangen: 4 Februar 2008 / Angenommen: 20 Juni 2008 / Online veroffentlicht: 15 August 2008© Springer-Verlag 2008

Zusammenfassung Zusammen mit drei weiteren Artikeln,die den Ubergang vom Batch- zum Timesharing-Betrieb,das Unternehmen und die Hardware des TR440 beschrei-ben, gibt dieser Text einen Ruckblick auf Entwicklungund Realisierung des deutschen Großrechners TR440 beiAEG-Telefunken und den Nachfolgefirmen. Dieser Teildes Ruckblicks beschaftigt sich mit der Software und derSoftware-Entwicklung fur den TR440, insbesondere in denJahren 1965 bis 1974. Es werden technische Highlightsder Software behandelt und Einblicke in die Software-Entwicklung selbst gegeben, insbesondere auch Hinter-grundinformationen zu Einflussen, Verantwortungen undEntscheidungen. Der Artikel beginnt mit dem TR4, demVorganger des TR440, und endet mit den Aktivitaten fureinen TR440-Nachfolger.

Schlusselworter TR440 · Telefunken · Konstanz ·Software · Software-Management · History

Abstract Together with three other publications this paperis covering the development of the TR440, a large scalecomputer developed and manufactured by the German com-pany AEG-Telefunken and its successor companies. Eachpaper presents a different view. This paper describes tech-nical highlights of the TR440 software. The emphasis is onthe years 1965 to 1974. In addition we show how softwaredevelopment was managed, who was responsible for variousparts, and how and why certain decisions were made. Someanecdotes, recently sent to me by people engaged in the

H.-J. Siegert (�)Institut fur Informatik, Technische Universitat Munchen,Boltzmannstr. 3,85748 Garching, Deutschlande-mail: [email protected]

software development process, recall this time vividly. Thepaper starts with the TR4, the predecessor of the TR440,and ends with the efforts to define a TR440 successor. AnEnglish version of this paper is to be published in the IEEEAnnals of the History of Computing.

Keywords TR440 computer · Telefunken ·German computer industry · Software ·Software management · History

CR subject classification K.1 · K.2 · K.6 · D.2 · D.3 · D.4 ·D.2.9

1 Vorbemerkungen

Dieser Artikel beschaftigt sich mit der Software und derSoftware-Entwicklung fur den Rechner TR440 sowie kurzmit dessen Vorganger, dem TR4, und einem geplantenNachfolger, dem TR550. Schwerpunkt sind die Jahre 1965bis 1974. Dieser Text gibt zusammen mit drei weiteren Ar-tikeln [44, 45, 82] einen Ruckblick auf die Entwicklung desdeutschen Großrechners TR440 bei AEG-Telefunken undden Nachfolgefirmen.

Telefunken wurde 1903 in Berlin gegrundet und 1941von AEG ubernommen. AEG und Telefunken fusionier-ten 1967 zur neuen Firma ,,AEG Telefunken“ [68, 77]. DerGroßrechneranteil von AEG-Telefunken ging am 1.1.1972in die Telefunken Computer (TC) uber, eine gemeinsameTochter von AEG-Telefunken und Nixdorf AG. TC wurdeam 18.4.1974 an Siemens verkauft und firmierte als Com-puter Gesellschaft Konstanz (CGK). Bei der nachfolgen-den Beschreibung der Großrechnerentwicklung in Konstanzwird, wenn ohne Bedeutung, manchmal nicht zwischenAEG-Telefunken und TC unterschieden.

1 3

238 Siegert

Der Artikel basiert auf den Erinnerungen von Zeitzeu-gen, insbesondere des Autors, und schriftlichem Material,vorwiegend kundenorientierten Schriften, die noch im Be-sitz des Leibniz-Rechenzentrums der Bayerischen Akade-mie der Wissenschaften oder einiger ehemaliger Mitarbeitervon AEG-Telefunken waren. Leider gab es das Firmenar-chiv mit den internen Dokumenten nicht mehr.

Die gesammelten und zitierten Dokumente sind weitest-gehend in die Bibliothek des Deutschen Museums in Mun-chen aufgenommen worden.

2 Der Telefunken-Rechner TR4

Im Jahr 1956 fasste der Vorstand von Telefunken den Be-schluss, in das Gebiet der elektronischen Vermittlungs-systeme einzusteigen [44]. Mit einer kleinen Mannschaftwurde in Backnang die Entwicklung eines großen, volltransistorisierten Universalrechners, dem TR4, begonnen.Der Begriff Universalrechner bezeichnet einen allgemeineinsetzbaren Rechner (Mainframe) im Gegensatz zu dedi-zierten Rechnern, wie beispielsweise Prozessrechner.

Die erste TR4-Anlage ging 1962 an die Universitat Ham-burg. Kunden außerhalb der Universitaten waren insbeson-dere die Bundesanstalt fur Flugsicherung (ab 1965) unddas Finanzministerium Nordrhein-Westfalen. Die Einsatz-gebiete des Rechners bei den technisch-wissenschaftlichenEinrichtungen und den genannten behordlichen Einrichtun-gen hatten pragenden Einfluss auf die Software des TR4 unddes TR440.

In den 60er-Jahren, also zur Zeit des TR4, war die Sta-pelverarbeitung die typische Betriebsform. Ein Strom vonStapeln wurde sequentiell abgearbeitet. Der Benutzer hattenormalerweise keinen Zugang zum Rechenzentrum und ins-besondere nach Abgabe seines Auftrags im Rechenzen-trum auf Grund der Eigenschaften der Betriebssoftwareauch keine Moglichkeit mehr, in den Programmablauf ein-zugreifen. Programmiert wurde normalerweise in Assemb-ler. Das Rechenzentrum bzw. der Anwender erwartete vomRechnerhersteller lediglich eine Ablaufsteuerung fur denStapelbetrieb, einen mehr oder weniger komfortablen As-sembler und ganz wenige, vorwiegend mathematische Bi-bliotheksprogramme. Ein besonderer Komfort waren Un-terprogramme zum Zugriff auf Gerate. Die vom Herstellergelieferte Software war also klein. Generell wurden sowohlvon den Herstellern als auch von den Kunden die Bedeu-tung und die Moglichkeiten der Software unterschatzt, dasich damals noch jeder seine Anwenderprogramme selbst,,zusammenbastelte“.

Ein typisches Beispiel: Noch im Februar 1963 wurdenin einem Merkblatt des ,,Recheninstituts der TechnischenHochschule Stuttgart“ die zukunftigen Benutzer der neuenTR4-Anlage (geplante Aufstellung Juni 1964) ausfuhrlich

uber die Hardware-Eigenschaften informiert, aber zur Soft-ware wurde lediglich ausgefuhrt:

»5.) ProgrammbibliothekALGOL-60-Ubersetzer (bereits erprobt und gut bewahrt)ca. 30 Programme uber elementare Funktionenca. 30 Programme zur Matrizenrechnungca. 15 Programme verschiedener Artca. 20 Programme fur Organisation und Prufung.«

Ein anderes Beispiel: In einem zwolfseitigen Faltblatt derTelefunken AG von 1962 (Großrechenanlage TR4 Kurzbe-schreibung) wurde nur etwa eine Drittelseite der Softwareunter der Uberschrift ,,Programmierungshilfen“ gewidmet:

»Neben dem ausfuhrlichen Handbuch . . . liefert Tele-funken ein umfassendes System von wirkungsvollen,aufeinander abgestimmten Dienstprogrammen, Stan-dardprogrammen fur die Magnetbandarbeit und Su-perprogrammen. Die Dienstprogramme enthalten au-ßer Prufprogrammen fur Rechner, Externgerate undProgrammprufung Organisationsprogramme zur Ein/-Ausgabe von Programmen 80-stelliger Lochkarten,5- bis 8-Kanal-Lochstreifen sowie das Verkehrspro-gramm fur die Kontrollschreibmaschine. Zu unserenStandardprogrammen fur die Magnetbandarbeit zah-len automatisierte Datenein- und ausgabe, Sortier- undMischprogramme sowie ein symbolisches Adressie-rungssystem als Koordinationsprogramm. An Super-programmen liegen das Verteilerprogramm zur au-tomatischen Organisation der Parallelarbeit mehrererProblemprogramme und ein generierender Formel-ubersetzer fur ALGOL 60 vor. Außer ALGOL 60stehen der Wissenschaft und Forschung Programme furmathematische Verfahren, die sich von den elemen-taren Funktionen uber Matrizenrechnung, Polynom-berechnungen, Differentialgleichungen erster Ordnungund Fourier-Analyse und -Synthese bis zur Autokorre-lation der Statistik erstrecken in zahlreichen Variatio-nen als Programmierungshilfen zur Verfugung.«

In Backnang gab es dementsprechend nur eine kleine Soft-ware-Gruppe unter der Leitung von Frau Gudrun Beyer undHerrn Url. Ein besonderer Schwerpunkt war die Koordinie-rung der Parallelarbeit [78] zwischen Rechnerkern und EA-Geraten durch ein so genanntes Verteilerprogramm, das imRechner fest verdrahtet war. Es waren maximal 8 Prozessemoglich, die jeweils einer Prioritat fest zugeordnet waren. DieMoglichkeit, das Verteilerprogramm auf ein einfaches Moni-torsystem (Betriebssystem) auszubauen, wurde gesehen.Manfred Evers erinnert sich (2007):

»Angefangen habe ich bei Telefunken 1963 und habedas Verteilerprogramm des TR4 von Dr. Url unddas Kontrollschreibmaschinenprogramm von Frau Dr.

1 3

Der TR 440 von AEG-Telefunken: Software und Software-Entwicklung 239

G. Beyer ubernommen und zunachst, das erinnereich noch genau, nur ,,Bahnhof“ verstanden. Dann ka-men die vielen Nachte im Pruffeld, um den Verteilerreif fur den Festspeicher zu machen und anschließendder rote Kopf, wenn doch noch ein Fehler drin war,und die Frauen in der Fertigung neu fadeln mussten.Meine Kopfwasche beim Kunden bekam ich auch bald:Ich wurde zu Gierse [Leiter des Rechenzentrums desFinanzministeriums von Nordrhein-Westfalen] nachDusseldorf zitiert und durfte seinen etwa 20 Magnet-bandgeraten bei der Bewaltigung der NRW-Kraftfahr-zeugsteuer zuschauen, bis alles stillstand! ,,So, HerrEvers, jetzt sind Sie dran“ wortwortlich, eingebrannt inmeinem ,,Festspeicher“. Mein lieber Verteiler hatte nureinen einzigen Interrupt verschlabbert, den ich dannkunstlerisch/kunstlich erzeugen musste, wahrend dieanderen zum Mittagessen gingen. Es gibt Dinge, dievergisst man nicht!«

Telefunken grundete 1959 im Werk Konstanz ein neuesFachgebiet ,,Informationstechnik“, siehe [44]. Deshalbwurde ab 1963 die Entwicklung und Fertigung des TR4nach Konstanz verlegt.

Die Leitung der TR4-Software-Entwicklung in Konstanzubernahm bis 1966 Wolfgang Frielinghaus. Dieser trat am1.4.1962 bei Telefunken GmbH in Backnang ein und arbei-tete an der Software-Entwicklung fur den TR4 mit. Dannubernahm er im Dezember 1963 die Leitung der gesamtenTR4-Software-Entwicklung, einer Gruppe von etwa 15 Mit-arbeitern. Ab 1966 arbeitete er bei dem Entwurf der TR440-Grundsoftware mit und war ab 1.1.1967 verantwortlich furdie Programmiersystem- und Compiler-Entwicklung furden TR440 [10]. Im Zeugnis fur W. Frielinghaus wurde be-sonders darauf hingewiesen, dass er den TR4-FORTRAN-Compiler innerhalb eines Jahres konzipierte und realisierte.W. Frielinghaus bemerkte 2007 dazu:

»Eine weitere große Pleite bahnte sich an, weil der THDarmstadt ein TR4 mit einem FORTRAN-Compilerzugesagt war. Der Auftrag war an eine Universitat ver-geben worden. Ein Jahr vor Auslieferung habe ich dendaran arbeitenden Assistenten eingeladen, sein Projektvorzustellen. Alles was existierte waren zwei Notizzet-tel mit vagen Ideen. Die Dissertation war dazwischengekommen. Ich habe den Vertrag sofort gekundigt, in 4Monaten einen FORTRAN-Compiler geschrieben undanschließend ausgetestet. Meine Mitarbeiter haben dieganze Ein/Ausgabe, die mathematische Bibliothek undden Source-Dump programmiert. Die interne Listen-verwaltung war voll dynamisiert und der Syntaxfehler-bericht war benutzerfreundlich.«

Die TR4-Software-Entwicklungsgruppe leitete ab 1966 bis1974 G. Schlenstedt. Dann wurde die Pflege und Weiterent-

wicklung der TR4-Software eingestellt und G. Schlenstedtwechselte zur AEG. Zur TR4-Software gehorten neben derSystemsoftware auch die Bibliotheksprogramme und an-wendungsorientierte Software wie Grafik, Plotten, Sortierenund Mischen, Netzplantechnik oder numerische Werkzeug-maschinensteuerung (EXAPT).

3 TR4-Grundsoftware von der TH Munchen

Manche Eigenentwicklungen der TR4-Software durch Tele-funken waren nicht erfolgreich. Der Telefunken-Assemblerverlor an Bedeutung, da die Anwenderprogramme, ab-gesehen von Spezialfallen, leichter mit dem von der THMunchen entwickelten ALGOL-60-Ubersetzer realisiertwerden konnten. Ebenfalls an der TH Munchen (in Ver-bindung mit dem Leibniz-Rechenzentrum der BayerischenAkademie der Wissenschaften) wurde 1963/64 von Ger-hard Seegmuller, Ferdinand Peischl, Wolfram Urich undHans-Rudiger Wiehle [83] ein Betriebssystem fur den TR4entwickelt. Dieses baute auf dem TR4-Verteilerprogrammauf. Die Systemphilosophie stammte weitgehend vonH.R. Wiehle. F. Peischl realisierte den Assembler undH.R. Wiehle den Systemanderungsoperator. G. Seegmullerentwarf die technische Struktur des Betriebssystems undprogrammierte es in 1964. Hier sei angemerkt, dass derBegriff Betriebssystem wohl Anfang der 60er Jahre, viel-leicht sogar in der oben genannten Gruppe, gebildet wurde.G. Seegmuller schrieb 2007 an H.-J. Siegert: »Mir ist beimSchreiben dieser Zeilen [einer E-Mail an Siegert] auch klargeworden, dass wir den Begriff ,,Betriebssystem“ schon abetwa Ende 1961 oder Anfang 1962 verwendet haben mussenund nicht, wie ich beim letzten Briefwechsel mit Ihnen ver-mutet habe, erst 1963 oder 1964!«

Dieses Betriebssystem des TR4 war technisch weltweitfuhrend, wurde aber, wie viele andere europaische Lei-stungen, in der internationalen Community praktisch nichtwahrgenommen. Das TR4-Betriebssystem war ein Stapel-betriebssystem mit einem Hauptstrom von Programmen.Daneben konnten weitere Programme ablaufen, insbeson-dere Dienstprogramme fur den Operateur. Damit war auchMultiprogramming realisiert. Allerdings bedingten die Ei-genschaften der Hardware, dass das Betriebssystem und alleProgramme ungeschutzt im Speicher lagen.

Die Konzeption des Betriebssystem ging uber die da-maligen Hardware-Moglichkeiten hinaus. Einige wichtigeKonzepte sollen nachfolgend genannt werden.

Es wurde der Begriff Operator eingefuhrt. Operatorenwaren unter dem Betriebssystem ablauffahige Programme.Sie arbeiteten (quasi)parallel und durften konzeptionell nurdie ihnen zugewiesenen Speicher und Gerate verandern.Operatoren wurden damals von den Verantwortlichen mitden Befehlen der Maschine verglichen und bedurften da-

1 3

240 Siegert

her ihrer Ansicht nach ebenfalls einer (komplexen) Ablauf-steuerung durch einen Superautomat (Betriebssystem).

Auch die organisatorischen Aufgaben des Betriebssys-tems sollten als Operator und nicht wie sonst ublich als Be-standteil des Systemkerns realisiert werden. »Das Heraus-losen aller Steuerungsaufgaben aus dem System – von denwenigen abgesehen, die der Nachfolgerfunktion verbleiben– und ihre Gliederung in operative Einheiten von normierterForm, ermoglichen ein viel hoheres Maß an Allgemeinheitund Flexibilitat als bei Monitorsystemen herkommlichenAufbaus.« Dieser Gedankengang fuhrt zum heutigen Kon-zept der Systemprozesse.

Das Hinzunehmen und Entfernen von Operatoren ge-horte zu den Grundaufgaben des Superautomaten. Es gabOperatorenketten mit Datenubernahme vom Vorganger undDatenweitergabe an den Nachfolger. Die Operatorenreihen-folge war durch eine Steuerliste definiert, die auch durchOperatoren verandert werden konnte. Ein Operator konntealso je nach Ergebnis seiner Arbeit unterschiedliche Folge-operatoren festlegen. Eine Anwendung war beispielsweise,dass bei einem Fehler in einem ALGOL-Programm diesesden Post-Mortem-Operator als seinen Nachfolger eintragenkonnte. Ein Operator konnte auch die Ablaufregie wahrneh-men, wenn er sich stets als Nachfolger des Folgeoperators indie Steuerliste eintrug, wobei es allerdings immer moglichwar, dass doch noch weitere Operatoren vorher eingescho-ben wurden, da alle Operatoren die Steuerliste verandernkonnten. Falls die Steuerliste leer wurde, wurde ein Sys-temfortsetzungsalgorithmus gestartet, der von außen (einemGerat) Daten einlas bis eine Steueranweisung kam. Die Ent-wickler sahen dies als konzeptionell vergleichbar mit derAusfuhrung des nachsten Befehls im Rechner an.

Operatoren konnten einen Fehlereingang beim Systemanmelden: »Jeder moderne Rechenautomat lasst es zu, dassein Programm gewisse bei seiner Ausfuhrung aufgetre-tene Fehler selbst behandelt«. Operatoren konnten Maschi-nenressourcen jederzeit anfordern und freigeben. Das Be-triebssystem fuhrte Buch uber zugeteilte und vorhandeneRessourcen und uberwachte die Nutzung der zugeteiltenKomponenten, soweit das bei der TR4-Architektur moglichwar.

Der oben zitierte Artikel schloß mit dem Hinweis: »EinSystem der beschriebenen Art wird derzeit im Rechenzen-trum der Bayerischen Akademie der Wissenschaften fur dieTelefunken-Rechenanlage TR4 programmiert.« In den Lite-raturverweisen finden sich u.a. Artikel uber das Atlas-Be-triebssystem, den Monitor fur die IBM 7090/7094, die dyna-mische Speicherzuteilung und uber ,,Concurrent Programs“.

Dieses Betriebssystem wurde, wie bereits erwahnt, dasStandard-Betriebssystem des TR4. Es wurde von Telefun-ken ubernommen und in Konstanz weiterentwickelt, insbe-sondere von Mitte 1966 bis Mitte 1967 zu einem Platten-betriebssystem. Gisela Hoffmann mit zwei Programmierern

von AEG Telefunken, Gerd Sapper und zwei sehr erfahreneMitarbeiter der Universitat Hamburg schrieben das neuePlatten-Betriebssystem [60]. Ebenfalls in der Gruppe vonG. Schlenstedt erfolgten auch andere Erweiterungen, ins-besonder langfristige Datenhaltung, Stapelfernverarbeitungund gekoppelte TR4-Systeme.

Neben dem TR4-Betriebssystem wurde von G. Seegmul-ler auch der ALGOL-60-Compiler fur den TR4 entworfenund realisiert. Hierbei wurden bereits die spater geschil-derten, sehr innovativen Testhilfen und der quellbezogenePost-Mortem-Dump und realisiert [63]. G. Seegmuller erin-nert sich (2007): »Die Idee einer solchen Funktion ging aufeine Unmutsaußerung von H.R. Wiehle im Fruhjahr oderSommer 1962 aufgrund von Erfahrungen mit dem ALGOL-Betrieb im Perm-Rechenzentrum zuruck. F. Peischl und ichgingen danach im 2. Stock an die Tafel und entwarfen die(nahe liegende) Realisierung des Mechanismus (,,Nibblingfrom the Stack“) in einem Tag.«

4 Vom TR4 zum TR440

Ab etwa 1962/63 wurden Arbeiten zu einem Nachfolgerdes TR4 begonnen, fur den es verschiedene Bezeichnun-gen gab, z.B. TR14, TR44, TR400, TR*. Schlussendlichwurde die Bezeichnung TR440 festgelegt. Die Diskussio-nen zur Festlegung einer Architektur beleuchtet eine No-tiz von 1963, in der Fritz Rudolf Guntsch von einem Ge-sprach (vermutlich mit F.L. Bauer und G. Seegmuller) zumTR4-Nachfolger anlasslich der Abnahme der TR4-Anlagein Munchen berichtet:

• Der TR4-Befehlscode wird als unausgewogen betrachtet.Der Nachfolger sollte einen kleineren und viel systemati-scheren (compilerfreundlicheren) Befehlscode erhalten.

• Die Zeit, wo TR4 mit TR440 programmvertraglich seinmusse, sei endgultig vorbei (da Ubersetzung moglich).Es lohne daher nicht, neue Erkenntnisse uber Rechner-strukturen und Befehlscodes zu ignorieren.

Anmerkung: F.R. Guntsch war Leiter des Fachgebiets,,Elektronische Rechenanlagen“ bei Telefunken in Kon-stanz. Er hatte in seiner Dissertation 1957 den virtuellenSpeicher eingefuhrt, als einen auf der Ebene der Maschi-nensprache direkt adressierbaren Adressraum, der tech-nisch durch die Speicherhierarchie aus Primar- und Se-kundarspeicher realisiert wird, mit bedarfsgesteuertem au-tomatischem Austausch von Speichersegmenten zwischenPrimar- und Sekundarspeicher (Paging). Weiteres zur Per-son in [44, 84].

Neue Hardware- und Software-Strukturen entstandenzu dieser Zeit insbesondere durch erste Uberlegungen furden Ubergang vom Einbenutzer-Stapelbearbeitungs-Systemzum Mehrbenutzer-Timesharing-System:

1 3


• 1961 wurde die Rechnerfamilie IBM System/360 ent-worfen und in 1964 wurden die ersten Rechner dieserFamilie angekundigt [58].

• 1961 machte das MIT (Massachusetts Institute of Tech-nology) erste Experimente mit CTSS (Compatible Time-Sharing System) auf der DEC PDP-1 und der IBM 709[5, 20].

• 1962 entstand fur die DEC PDP-1 das weltweit ersteTimesharing-System.

• 1962 realisierte Ferranti das Paging bei der Atlas [27].• 1964 wurde das Dartmouth Time-Sharing System vorge-

stellt, entwickelt von John Kemeny und Tom Kurz fureine GE-265.

• 1965 wurde Multics auf der Fall Joint Computer Confe-rence beschrieben.

Der Vorstand war bezuglich des TR440 sehr unentschlos-sen. So wurde beispielsweise am 19.10.1964 ein Entwick-lungsstopp fur den TR400 angeordnet. Die Versuche, denVorstand zur Freigabe zu bewegen, illustriert ein Brief vonEike Jessen (er wurde 1964 von F.R. Guntsch nach Konstanzin das Fachgebiet ,,Elektronische Rechenanlagen“ als Leiterder Entwicklung geholt) und Heinz Voigt (er war Architektder TR4- und TR440-Zentraleinheit und Projektleiter fur dieHardware-Entwicklung) vom 4.11.1964 an den Bereichs-vorstand [41]. Darin wurde ausgefuhrt, dass Herr Voigt einneues Konzept fur den TR400 entwickelt habe. Er wollediesen jetzt aus integrierten Halbleiterbauelementen herstel-len. Es erschiene moglich, ihn noch vor der HannoveranerMesse 1967 fertigzustellen und 1 bis 2 weitere Rechner in1967 auszuliefern. Ab 1968 konnten 8 Stuck jahrlich ausge-liefert werden.

Typisch fur die damalige Zeit war, dass im Brief keineBemerkungen zur Software gemacht wurden. Diese er-scheint lediglich in der Schatzung des Personalaufwands inMannjahren (MJ) in der Entwicklung (siehe Tabelle 1). ZurProgrammierung zahlte auch die Software fur Hardware-Test und -Wartung, moglicherweise auch noch die Mikro-programmierung. Hinzu kamen insgesamt 8 MJ fur dieProgrammbibliotheken, deren Erstellung dem Vertrieb zu-geordnet war.

Weiter schrieben E. Jessen und H. Voigt: »Der gegendas Projekt TR400 zu Recht immer wieder erhobene Ein-wand, dass die Programmierung wahrscheinlich nicht in-nerhalb der notwendigen Zeit fertiggestellt ist, erscheintmir durch Ausdehnung der Projekt-Laufzeit auf 2,5 Jahre

1965 1966 1967 1968 1969 1970 Summe

Hardware-Entwicklung (E) 25 25 20 15 6 4 95Hardware-Ein/Ausgabe (EA) 10 15 15 10 5 2 57Allgemein (Kst) 5 10 10 5 2 1 33Programmierung (P) 20 25 25 10 7 3 90Summe 60 75 70 40 20 10 275

Tabelle 1 Aufwandsschatzungin Mannjahren nach [41]

bis zum Prototyp und durch die schnelle Beendigung un-serer TR4- und TR10-Aktivitat weniger bedrohlich. Dieim vorstehenden Personalplan enthaltenen Ansatze der Pro-grammierung sind nach meiner Meinung durchaus realisier-bar und durften mit Sicherheit die Entwicklung eines gu-ten Software-Sortiments erlauben (gesamte Programmier-leistung fur den TR400 sind 90 MJ gegenuber ca 110 MJfur alle bisher geleisteten oder noch abzusehenden Program-mierungsarbeiten fur den TR4).«

Es sollte sich zeigen, dass – aus den verschiedenstenGrunden – die Aufwendungen fur die Software etwa um denFaktor 10 und die Entwicklungszeiten mindestens um denFaktor 2 hoher waren. Außerdem war nicht berucksichtigt,dass der Test der Software weitgehend erst nach Fertigstel-lung der Hardware moglich war, es also eine Sequentialisie-rung gab und Verschiebungen der Hardware-Termine unmit-telbar zu Verschiebungen der Software-Endtermine fuhrenmussten.

Die endgultige Freigabe der Entwicklung erfolgte erst,als bei einer Ausschreibung der DFG fur das Deutsche Re-chenzentrum in Darmstadt der TR440 den Zuschlag bekam.Jetzt war eine erfolgreiche TR440-Entwicklung plotzlicheine Prestigesache, sowohl fur AEG-Telefunken als auch furdie DFG.

5 Betriebssystem BS1

H.R. Wiehle, auf den das Konzept des TR4-Betriebssystemszuruckging, kam 1964 zu AEG-Telefunken und ubernahmdie Leitung der Betriebssystementwicklung fur den TR440.Die Programmiersystem- und Compilerentwicklung leiteteW. Frielinghaus.

H.R. Wiehle hatte sehr weit reichende und auch sehrgrundsatzliche Vorstellungen von einem Betriebssystem,das eine außerst komplexe und moglichst uneingeschrankteInteraktion mit vielen Benutzern gleichzeitig erlaubensollte. Naturlich waren dazu die heute typischen Grund-bausteine eines Mehrprozessbetriebssystems zu entwickeln,wie Verwaltung der Ressourcen, Betriebsmittel- und Auf-tragsplanung, langfristige Datenhaltung oder Schutzmecha-nismen. Das Problem war, dass es damals keine Vorbilderfur einen solchen Betrieb gab, allenfalls Ideen oder fruhe ex-perimentelle Teilrealisierungen. Dies bedeutete auch, dassdie potentiellen Anwender, auch an den Hochschulen, miteinem solchen Gesprachsbetrieb keine Erfahrung hatten, ja

1 3

242 Siegert

teilweise selbst die notwendigen technischen Begriffe wederwortlich noch inhaltlich kannten. Ein Beispiel: Mitarbeitervon AEG-Telefunken, insbesondere H.R. Wiehle, wurdenuber Jahre hinweg immer wieder gebeten, doch den BegriffProzess zu erklaren. Die Situation wurde noch dadurch er-schwert, dass Neuland betreten wurde und so laufend neuetechnische Sachverhalte beschrieben werden mussten. DieEntwickler in Konstanz bemuhten sich, stets deutsche Be-zeichnungen einzufuhren.

Es ist klar, dass hier Konflikte vorprogrammiert waren:Ganz extreme Betriebssystemvisionen einerseits, dann dafurunzureichende und zu teure Hardware sowie bezuglichTragfahigkeit des Konzepts und Overhead des Systems imspateren Betrieb sehr skeptische Benutzer andererseits.

Das von H.R. Wiehle und seinen Mitarbeitern (u.a.Herbert Meißner, Rubin) entwickelte Timesharing-Betriebs-system war das so genannte BS1. Zwei zentrale Konzeptewaren der Auftragsbegriff und die Nutzenfunktion. Eineausfuhrliche Beschreibung findet sich in [81], fruhe Be-schreibungen bei [42, 51, 80], deshalb werden wichtige Ei-genschaften des BS1 nachfolgend nur kurz skizziert.

Das Betriebssystem war modular aufgebaut und hatteeine Prozess-Struktur gemaß Abb. 1.

Es verwaltete laufend eine große Zahl von Programm-laufen (Prozesse). Ein Prozess konnte im Ruhezustand sein,weil er beispielsweise Eingabe von einem Benutzer, der denProzess betrieb, an einem Gerat erwartete und dieser Be-nutzer seinen Arbeitsplatz vorubergehend verlassen hatte.

Abb. 1 Blockstruktur des BS1

Die Betriebsplanung arbeitete intern mit Nutzenfunktionenund die Steuerung maximierte den Nutzen. H.R. Wiehle[80] sagte in einem internen Vortrag vor Mitarbeitern desVertriebs zu den Betriebszielen: »Nach einer verbreitetenAuffassung ist es ganz klar, das Betriebsziel ist die Ausla-stung der Werke des Rechners. Es ist aber fur einen Rechnerder Art TR440 eine ganz irrige Auffassung, dass dies einprimares Betriebsziel sein konnte.«

Eine Nutzenfunktion gab in einer stark vereinfachtenBetrachtung an, welchen ,,Nutzen“ die Beendigung seinesAuftrags zu einer bestimmten Zeit fur den Benutzer hatte.Ein Beispiel zeigt Abb. 2. Die Nutzenfunktion wurde im Be-triebssystem aus externen Angaben des Benutzers und desRechenzentrums generiert, beispielsweise aus der Wichtig-keit des Benutzers und dem Betriebsmittelbedarf. Bei ge-nauerer Betrachtung einer ausschliesslichen Steuerung desSystems durch Nutzenfunktionen ergaben sich Fragen, z.B.:Wie ist eine Nutzenfunktion fur Dialogauftrage festzulegen,oder wie ist eine Nutzenfunktion dynamisch anzupassen,damit bestimmte Betriebsziele erreicht werden, beispiels-weise eine Balance zwischen Stapel- und Dialogauftragen?Bei der Optimierung des Nutzens war es ausdrucklich er-laubt und sinnvoll, dass das Betriebssystem die Bearbeitungeines Auftrags ablehnte. H.R. Wiehle 1967: »Ich will Ihnendamit nur soviel sagen: Wenn wir heute die Nutzenfunktionbetrachten und manche Leute sagen, das ist ja wahnsinnigkompliziert, dann kann ich auf der anderen Seite nur sa-gen, es ist doch ganz einfach im Vergleich zu dem, was

1 3


Abb. 2 Beispiel fur eine einfache Nutzenfunktion

man eigentlich an Bewertungen braucht. Ich meine, das istetwas, was in den nachsten Jahren unweigerlich in hohemMaße auf uns zukommt.« Diese Art der Auftragssteuerungsetzte sich jedoch nicht durch. Heutige Auftragssteuerungensind immer noch außerst primitiv gegenuber den damals ent-wickelten Vorstellungen.

Im BS1 gab es virtuelle Adressierung, aber keinen dy-namischen Seitenwechsel. Es gab zu dieser Zeit internatio-nal noch Skepsis gegenuber diesem Konzept: »Also virtualstorage is appealing in concept, it has yet to be provenentirely satisfactory in practice [59].« Bei BS1 wurden da-her gesamte Datenbereiche (so genannte Gebiete) zwischenArbeits- und Hintergrundspeicher verlagert. Gebiete wur-den im Adressraum und auf Hintergrundspeicher zusam-menhangend gespeichert. Damit war es moglich, mit einemeinzigen Transportbefehl ein Gebiet zu verlagern. Ein Ge-biet enthielt beispielsweise die Befehle eines Programms,ein anderes die Daten. Dieses Konzept war wahrscheinlichaus Performanzgrunden sinnvoll, es bot aber keine Losungfur Programme, die zu groß fur den Arbeitsspeicher waren.Ob und wie weit dieser Gesichtspunkt in die Entwurfsent-scheidung einging, ist unbekannt.

Beim Vielfachzugriff (Multikonsolbetrieb) sollten vielePersonen von geeigneten Arbeitsplatzen aus einen unmit-telbaren Zugriff zur Rechnerleistung haben. Dabei solltensie jederzeit ein Gesprach mit einem in dem TR440 ab-laufenden, gesprachsfahigen Programm fuhren konnen. Inein solches Gesprach sollten ohne Einschrankungen weitereGesprache mit anderen Programmen eingeschoben werdenkonnen. Ein strenges Wechselgesprach, bei dem zudem dasProgramm die Initiative hatte, wurde als zu einschrankendangesehen.

Aus dieser kurzen Ausfuhrung erkennt man die ambi-tionierten Ziele, die weit uber den damaligen Stand derTechnik hinausgingen und die aus heutiger Sicht sicher-lich ein extremes Risiko fur die Firma darstellten. So istes heute nachvollziehbar, dass nicht nur die potenziellenKunden skeptisch waren, sondern auch eine Kluft zwischen

Tabelle 2 Ausschnitt aus Organigramm von GR/E mit Stand Juni1968

GR Großrechner F.R. GuntschGR/E Entwicklung E. JessenGR/E1 Systeme,Gerate H. VoigtGR/E7 Programmierung TR440 H.R. Wiehle

GR/E71 Planung und Koordinierung H.-J. SiegertGR/E72 Betriebssysteme RubinGR/E73 EA-Vermittler RosnerGR/E74 Datenhaltung LeebGR/E75 Konsolvermittler M. Eversund TR4-AmulatorGR/E76 Abwickler Pohlmann

GR/E8 Programmiersysteme W. FriehlinghausGR/E81 Assembler R. DurchholzGR/E82 FORTRAN W. FroehlichGR/E83 ALGOL H. ZimaGR/E84 COBOL BrandmarkerGR/E85 EA-Prozeduren, Sortierung MuhlbachGR/E86 Unterprogrammbibliothek SchaferGR/E87 Programmierhilfen P. Namneck

GR/E9 Programmierung TR4 G. Schlenstedt

Entwicklungs- und Vertriebspersonal bestand. Verscharftwurde die Lage durch einen gravierenden Personalmangelbei der Entwicklung. H.R. Wiehle [80] sagte 1967 ein-leitend zu Vortragen fur den Vertrieb: »Die starke Bean-spruchung der Programmentwicklung (Labor E44) verbieteteine besondere Vorbereitung dieser Vortrage, die folglich alsVortrage aus der Werkstatt anzusehen sind. Es kann auchnicht Sache der Entwicklung sein, sich auf eine ,,Benutzer“-gerichtete Darstellung, wie sie vertrieblich wunschenswertsein mag, einzulassen. Die Sehweise des Vertriebs muss undkann doch nur in vertriebseigenen Beschreibungen ihrenAusdruck finden. Dennoch hoffen wir, dass unsere Vortrageals Erganzung unserer internen Schriften einen nutzlichenInput fur den Vertrieb darstellen und dazu beitragen wer-den, dass uberlastete Entwickler nicht mehr zu vertriebli-chen Hilfestellungen herangezogen werden.«

Organisatorisch war die Software-Entwicklung bei derTR440-Entwicklung unter E. Jessen eingegliedert (Ta-belle 2). Es zeigte sich, dass diese Organisation den Bedurf-nissen, der Bedeutung und der Entwicklung der Softwarenicht gerecht wurde. Daher wurde sehr bald die Software-Entwicklung in eine eigene, zu GR/E gleichrangige Ab-teilung GR/P ausgelagert. Ich komme hierauf in einemspateren Kapitel noch zu sprechen.


Helmut Kohler kam 1967 von IBM zu AEG-Telefunkenund ubernahm von Egbert Ulbrich die Leitung des Vertriebs(Abteilung GR/V). Er wollte und sollte den Verkauf desTR440 steigern, insbesondere auch durch Erschließung deskommerziellen Markts. Zum Einstieg in diesen Markt er-

1 3

244 Siegert

schien eine kleinere und damit preisgunstigere Version desTR440 notwendig, insbesondere sollte, da teuer, die Großedes Arbeitsspeichers reduziert werden. Als Ziel wurde eineGroße von 32 KWorte zu je 52 Bit fur die Anlage vorgege-ben. Als Einstieg sollten sogar 16 KWorte ausreichend sein.Dies lag außerhalb der Moglichkeiten des BS1 und war nurmit einem einfachen, mehr oder weniger konventionellenStapelbetriebssystem zu erreichen.

H. Kohler holte, um ein solches Betriebssystem zu er-stellen, 1968 Jurgen Esch, der gerade bei Handler promo-viert hatte und Rechenzentrumsleiter an der TU Hannoverwar, nach Konstanz. Die ,,Gruppe Esch“ war organisatorischGR/P unterstellt. Alle Mitarbeiter der Gruppe (etwa 10)wurden von J. Esch mit nach Konstanz gebracht, insbeson-dere Albert Noltemeier, Manfred Romermann und HerbertStuhlmann. Lothar Krause brachte seine profunden Kennt-nisse uber die TR4 vom Rechenzentrum der UniversitatHamburg mit. Gunther Stiege stieß erst spater von Sie-mens dazu. So ist es verstandlich, dass die ,,Gruppe Esch“eine eingeschworene Gemeinschaft bildete und bis zu ei-nem gewissen Grad ein Eigenleben fuhrte. Sie war in Kon-stanz leider auch ortlich getrennt von der ubrigen Software-Entwicklung untergebracht.

Das von dieser Gruppe zu konzipierende und zu realisie-rende kommerziell-administrativ orientierte Betriebssystemwurde BS2 genannt. Das Programmiersystem fur BS1 mitden Compilern sollte mit nur geringen Anpassungen auchauf BS2 laufen. Die erste Ausbaustufe des BS2 erlaubte Sta-pelverarbeitung mit einem Vordergrund- und einem Hinter-grundprogramm [3, 67]. Die Stapel wurden im Hintergrundabgearbeitet. Im Vordergrund liefen Systemverwaltungspro-gramme, beispielsweise Spooling. Zur Steuerung der An-lage durch den Operateur war ein Operateurteil im BS2vorhanden, der sich ebenfalls um den Rechnerkern bewarbund hochste Prioritat hatte.

Das Betriebssystem belegte einen festen Anfangsbereichdes Arbeitsspeichers. Dieser Anfangsbereich enthielt einenFestteil (BSF) des Betriebssystems und einen variablen Teil(BSV) fur bei Bedarf zuladbare Systemteile und Puffer. Dervariable Teil wurde in Achtelkacheln (128 Worte) verwal-tet. Uber die statische Dimensionierung von BSF und BSVließ sich das BS 2 an unterschiedliche Ausbaustufen des Ar-beitsspeichers anpassen. Der Rest des Arbeitsspeichers (P-Bereich) wurde in Kacheln (Frames) von je 1024 Worten ver-waltet und konnte Programmen zugeteilt werden. Es gab einVorder- und ein Hintergrundprogramm. Einem Programmwurde beim Start der anfangs benotigte Arbeitsspeicher zu-gewiesen. Sowohl das Vorder- als auch das Hintergrundpro-gramm konnten Speicher nachfordernoder wieder freigeben.Ein Hintergrundprogrammkonnte den ganzen P-Bereich be-legen. Fur das Vordergrundprogrammgab es eine festgelegteobere Grenze seines Arbeitsspeichers. Es gab also virtuelleAdressierung, aber keinen dynamischen Seitenwechsel (Pa-

ging). Ressourcenkonflikte wurden dadurch vermieden, dassder maximale Bedarf eines Programms an Arbeitsspeicherbekannt war und dass das Vordergrundprogrammkeinen Zu-gang zu Systemdateien erhielt.

Ein einfaches Dateimanagement war auf die Bedurfnisseder hoheren Sprachen, insbesondere FORTRAN, abgestellt.Je Benutzerprogramm konnten maximal 8 Dateien verwen-det werden. Diese mussten alle auf Kommandoebene vordem Start des Programms spezifiziert werden. Sie wurdendann vor dem Programmlauf geoffnet. Auf logischer Da-teiebene wurden Satze, auf physischer Ebene Blocke verar-beitet. Blocke wurden direkt zwischen dem Adressraum desBenutzers und dem Gerat ubertragen.

Die erste Stufe des BS2 (Mehrprogrammbetrieb mit2 Programmen) war im Fruhjahr 1970 lauffahig [75].Fur die zweite Ausbaustufe waren Stapelverarbeitung imMehrprogrammbetrieb mit bis zu 8 Programmen und Sta-pelfernverarbeitung geplant. Daneben sollten erheblicheLeistungserweiterungen des Betriebssystems realisiert wer-den, wie beispielsweise indexsequentielle Zugriffsmetho-den bei Dateien, dynamische Listenverwaltung mit zeitlichveranderlicher und dem aktuellen Bedarf angepasster Langevon Listen, gemeinsam benutzbarer Code, praemptive undprioritatengesteuerte Auftragsbearbeitungsstrategien, dyna-mische Betriebsmittelverwaltung, also Anforderungen undFreigaben von Betriebsmittel auch wahrend eines Pro-grammlaufs. Die Auftrage sollten in 4 Warteschlangeneingetragen werden: Express, Spezial, EA-intensiv, rechen-intensiv. Die Express-Auftrage sollten unbedingten Vorranghaben, aus den ubrigen Auftragen sollte eine Auswahl be-arbeitet werden, so dass eine moglichst gute Auslastungder Anlage erreicht wurde. Bis zum Fruhjahr 1971 warenwesentliche Elemente dieses Konzepts realisiert, aber dieendgultige Fertigstellung und die Abnahme des Systemsstanden noch aus.

Um zeitlich vorzugreifen: Spatestens Anfang 1971 wurdevon H.J. Siegert die Weiterfuhrung des BS2 deutlich inFrage gestellt. Grunde waren u.a. dass der Einstieg in daskommerzielle Geschaft ausgeblieben war, dass durch dasvorgesehene Multiprogramming und andere Funktionser-weiterungen das BS2 sich notwendigerweise sehr stark inRichtung BS3 (Abschn. 9) entwickelte, dass das erfolgrei-che BS3 bereits verfugbar war und ebenfalls einen akzep-tablen Ressourcenbedarf hatte, dass im ProgrammiersystemDoppelarbeiten fur BS2 und BS3 notwendig waren und lastbut not least dass der finanzielle Spielraum der Firma im-mer enger wurde. Nach langen, intensiven Uberlegungen,Untersuchungen und Gesprachen konnte Kurt Scheidhauer,Leiter der Entwicklung, von dem Vorgehen uberzeugt wer-den. Mit seiner Ruckendeckung und Unterstutzung wurdendie Arbeiten am BS2 im April 1971 eingestellt [75], bevordie zweite Ausbaustufe fertiggestellt werden konnte. Auchdie erste Ausbaustufe des BS2 wurde nie an Kunden ausge-

1 3


liefert. Nach der Einstellung des Projekts verließen J. Eschund seine Gruppe geschlossen AEG-Telefunken und gingenfast alle zur GMD (Gesellschaft fur Mathematik und Daten-verarbeitung) nach Sankt Augustin bei Bonn.

7 Personelle und organisatorische Umbruche

Im Zusammenhang mit BS1 wurde bereits geschildert, dassdie Ambitionen bei der Software-Entwicklung zu hoch,die Zeitplane zu knapp und das Personal zu gering wa-ren. Hinzu kam die Skepsis der potenziellen Kunden. Auchbei der Hardware- und Gerateentwicklung traten massivetechnische Probleme und als Folge dann große Termin-verschiebungen auf. Dieses Bundel von Problemen fuhrtenaheliegenderweise zu personellen und organisatorischenUmbruchen.

Wie bereits erwahnt kam 1967 H. Kohler als Vertriebs-chef (GR/V) zu AEG-Telefunken. Er trennte Anfang 1968die Software-Entwicklung von der Hardware-Entwicklung.Dies war eine wichtige und innovative Maßnahme, da dieBedurfnisse und Kulturen in der Hard- und Software-Ent-wicklung sehr unterschiedlich waren und auch heute nochsind. Ab da gab es die Abteilung GR/E, die jetzt nur noch furdie Hardware zustandig war, und die Abteilung GR/P, in derdie Software-Entwicklung (Programmierung) zusammenge-fasst wurde. Die Leitung von GR/P ubernahm in Personal-union ebenfalls H. Kohler.

Am 1.9.1968 wurde H.R. Wiehle durch Klaus Bouninin der Leitung der Grundsoftware-Entwicklung (GR/P1)abgelost. H.R. Wiehle wurde als Verbindungsmann zurGruppe, die das Betriebssystem-Munchen (BSM [33, 39,49]) im Leibniz-Rechenzentrum Munchen entwickelte, ab-geordnet. Im Oktober 1971 verließ H.R. Wiehle AEG-Telefunken. In der Folgezeit gelang es aber auch K. Bouninnicht, das Vertrauen der Kunden, der Interessenten und derDFG in das BS1 wieder zu gewinnen, da deren Skepsis zutief saß.

1969 wurde H. Kohler Leiter des Fachgebiets Großrech-ner (GR). Am 20.5.1969 ubernahm Hans-Jurgen Siegert dieAbteilung Programmentwicklung Großrechner (GR/P) vonH. Kohler. H.J. Siegert war am 15.8.1967 als Systembera-ter zum Vertrieb gekommen, hatte dann zusammen mit W.Hanefeld eine erste beschreibende Vertriebsschrift fur exis-tierende Implementierungen der TR440-Software erstellt(die ,,goldene Bibel“), half bei der Planung des BS1 mit,wurde dann am 1.4.1968 Leiter des neu geschaffenen La-bors fur Planung und Koordination bei H.R. Wiehle undspater K. Bounin. Zur Abteilung GR/P gehorten zu die-ser Zeit die TR4-Software, die TR440-Software ohne diereine Anwendungssoftware, die Laborgruppe Systembera-tung sowie die Software-Aktivitaten fur Nachfolgesystemedes TR440.

8 Doppel-TR4-System

Der Rechner fur das Deutsche Rechenzentrum wurde imHerbst 1966 durch die DFG bestellt und sollte nach Vertragzum 1. Juli 1968 ausgeliefert werden. Spatestens Anfang1968 war jedoch klar, dass das zugesagte System nicht ter-mingerecht an das Deutsche Rechenzentrum lieferbar war[32]. Es war auch vollig aussichtslos, rechtzeitig Vorversio-nen des BS1 einsetzbar zu machen. Als Notlosung wurdedas Doppel-TR4-System, spottisch auch ,,doppelschlafrigeTR4“ genannt, geboren.

Bei diesem System [1] liefen auf dem TR440 zwei TR4-Betriebssysteme mit aller zugehorigen TR4-Software. Dieswar grundsatzlich moglich, da der TR440 einen TR4-Modushatte, in dem die TR4-Befehle ausgefuhrt werden konnten.Die Ressourcen des TR440, beispielsweise der Arbeitsspei-cher, waren aufgeteilt auf die beiden TR4-Systeme. EinProgramm, Amulator genannt, bildete die Hardware zweierTR4 auf einen TR440 ab und regelte die Benutzung deszentralen Rechners durch die beiden TR4. Man wurde einsolches Programm heute als Hypervisor oder Virtuellen-Maschinen-Monitor bezeichnen und sagen, dass es auf demTR440 zwei virtuelle Maschinen jeweils mit der Hardware-Schnittstelle eines TR4 gab.

Die Software wurde ab Februar 1968 von 6 Personenunter der Projektleitung von M. Evers entwickelt, der dies-bezuglich H. Kohler direkt unterstellt war. Gisela Hoff-mann arbeitete von Anfang an mit und wurde ab Oktober1968 Laborleiterin fur die Entwicklung des Doppel-TR4-Systems. Sie erbrachte wesentliche Entwicklungsleistungenund verantwortete spater auch die Auslieferung und Be-treuung. Sie war damals die erste Frau und die jungstePerson, die bei uns ein Labor leitete. Die Konzeptphasedauerte vier Wochen, Codierung und Test je weitere vierWochen [36]. Ein ausgedehnter Belastungstest fand in derzweiten Halfte 1968 statt. Ende 1968 erfolgte die Ausliefe-rung, der sich ein dreimonatiger Probebetrieb anschloss. DieSoftware-Entwicklung dauerte langer als geplant, da bei derHardware-Entwicklung des TR440 Nachentwicklungen beiden Anpasswerken der Peripherie notwendig wurden.

Im Februar 1969, mit etwa 8 Monaten Verspatung,wurde der TR440 mit Doppel-TR4-System am DeutschenRechenzentrum offiziell in Betrieb genommen. Die Ab-nahme erfolgte Ende 1969 [75]. Eine solche Losung warnur auf Grund der hohen Qualifikation und Kompetenz derSoftware-Entwickler in Konstanz moglich.

9 Die Geburt des Betriebssystems BS3

Die Entwicklung des BS1 lief parallel zur Entwicklung desProgrammiersystems und der Compiler. Zum Test der Com-piler war eine Testumgebung, also einige Grundfunktionen

1 3

246 Siegert

eines Betriebssystems und eines Datenmanagements, not-wendig. Das BS1 war jedoch noch nicht so weit entwickelt,dass es schon als Testumgebung dienen konnte. Auf derSuche nach Losungen stießen W. Frielinghaus und seineGruppe, insbesondere durch Hinweise von W. Froehlich,auf den Wartungsverteiler, der von Jochen Schilling in derHardware-Entwicklung in Anlehnung an den TR4-Verteilerentwickelt und zur Steuerung des Ablaufs von Testprogram-men fur die Hardware eingesetzt wurde. Dieser Wartungs-verteiler wurde erweitert und diente dann als Testumgebungfur die Compilerentwicklung.

Im Herbst 1969 war beim BS1 die Codierung einer erstenAusbaustufe abgeschlossen [75]. Das System war jedochvon den Zielen noch weit entfernt, so enthielt es nur einenAbwickler, also noch kein Multiprogramming. Die langsa-men Fortschritte von BS1 gaben im Hinblick auf die naherruckenden Liefertermine (u.a. im Juni 1970 fur das Rechen-zentrum der Ruhr-Universitat Bochum unter der Leitungvon Hartmut Ehlich) Anlass zu großer Sorge. Besonders kri-tisch war aber, dass es weiterhin ein extremes Misstrauen inder Firma, bei Kunden und bei der DFG gegenuber einzel-nen Personen und insbesondere gegenuber BS1-Konzeptenund BS1-Fertigstellungsterminen gab. Aussicht auf einenErfolg der Firma bestand, zumindest nach Meinung vonH.J. Siegert, nur bei einem ,,Befreiungsschlag“. Innerhalbganz weniger Tage und ohne Außenstehende zu informie-ren, trafen K. Scheidhauer und H.J. Siegert Anfang Oktober1969 die einsame Entscheidung, das BS1 einzustellen undauf eine vollig neue Entwicklung, das so genannte BS3,unter der Leitung von W. Frielinghaus zu setzen, der des-halb zu diesem Zeitpunkt die Verantwortung fur die Compi-lerentwicklung an Alexander Hoyer abgab. Ausgangspunktfur das BS3 war die oben genannte Testumgebung fur dieCompiler. Der Systemkern des BS3 entstand aus dem War-tungsverteiler und wurde zunachst von J. Schilling und sei-ner Gruppe, insbesondere Werner Schwarzmann und Lo-thar Stolze, in Absprache mit der BS3-Gruppe realisiert. Abetwa 1972 ging die Verantwortung fur den Systemkern vollauf die BS3-Laborgruppe uber.

W. Frielinghaus schrieb am 21.6.2007: »Wir hatten dasganze Programmiersystem so realisiert, dass wir die BS1-Interfaces aufgerufen haben. Zum Testen habe ich unse-ren Leuten einen Hilfsabwickler geschrieben, der seinerseitsden Wartungsverteiler als Systemkern aufrief. Darum wa-ren wir als Programmiersystem zum BS2 nicht kompatibel.Aber andererseits war es deshalb leicht, daraus den spaterenAbwickler fur das BS3 zu machen.«

Ebenfalls innerhalb weniger Tage wurde auch die Labor-gruppe (GR/P1), die das BS1 entwickelte, aufgelost und ineine neue Laborgruppe, deren Auftrag die Entwicklung desBS3 war, uberfuhrt. Dieser ,,Wechsel der Pferde im Galopp“war eine hochst riskante Entscheidung. Ein Fehlschlag hattedas Ende der Großrechnerentwicklung bedeutet. Die Ent-

scheidung war eine große Uberraschung fur die Kunden,wurde aber glucklicherweise von allen begrußt und das BS3wurde ein Erfolg. Es wurde bei allen TR440-Installationenals Teilnehmersystem TNS440 eingesetzt. Die Erstauslie-ferung des dialogfahigen BS3 war an das RechenzentrumBochum im Juni 1970. Die Rolle einer DFG-Abnahmekom-mission bei der Software-Entwicklung und ihre Bedeutungfur den Erfolg wird in einem getrennten Kapitel beleuchtet.

Alexander Giedke, Mitglied der DFG-Abnahmekommis-sion, schreibt dazu [32]: »Es ist kein Wunder, dass die Ab-kehr vom BS1 viele der Beteiligten uberraschte. War dochauf einer am 31.8.1969 veranstalteten Benutzertagung nochnichts von dieser Wende erkennbar gewesen. . . . Auf ei-nem Hearing der DFG zu TR440 am 7. November in Kon-stanz wurde eine erste Stufe des BS3 (Batch mit 2 Ab-wicklern) vorgefuhrt und Telefunken gab zu erkennen, dassdas BS1 nicht weiter verfolgt worden war. Das Hearingstellte nicht nur eine umfassende Bestandsaufnahme dar,es fuhrte auch zu Eingestandnissen der Firma Telefunkengegenuber den Benutzern und Forderern. Mit dem angebo-tenen Betriebssystem BS3 lag ein endgultiges und prakti-kables Software-Konzept vor. . . . Das Hearing brachte imGrunde die Entscheidung fur die Fortfuhrung der Arbeitenam TR440-Projekt.«

J. Schilling erinnerte sich [61]: »Ab etwa 1965 wurdemit der Entwicklung des sehr viel leistungsfahigeren Nach-folgerechners TR440 begonnen. Ab 1968 war ich selberals Laborgruppen-Leiter fur die Entwicklung der Test-und Wartungs-Software verantwortlich, daraus entwickeltesich fur mich (zuerst geheim, dann offiziell) die Auf-gabe, den Systemkern fur das TR440-Betriebssystem zuprogrammieren.«

G. Sapper, Mitarbeiter des Leibniz-Rechenzentrums inMunchen, notierte sich am 7. Oktober 1969: » . . . am Mitt-woch, 8. Oktober 1969, 9.30 Uhr befasst sich eine Gruppevon Programmierern aus den Abteilungen GR/P1, GR/P2,GR/P3, GR/EV11 . . . damit, das WBS (Wartungsverteiler-Betriebs-System; vormals als Wartungsverteiler und HIWIbzw. PHIWI, das heißt (Platten-) Hilfsabwickler, bezeich-net) bis zum 1. Januar 1970 an TR440-Kunden ausliefe-rungsfertig zu machen. . . . Zum 1. Juli 1970 soll eine furKonsole-Verkehr erweiterte Version dieses Systems ausge-liefert werden. Die Besetzung der genannten Programmie-rergruppe mit außergewohnlich qualifizierten Kraften lasstdiese Termine realistisch erscheinen. . . . Noch in der selbenWoche konnte ich von Herrn Frielinghaus Schnittstellendo-kumentationen und Listen bekommen.«

Durch die oben erwahnte Umsetzung der Mitarbeiter vonder Laborgruppe BS1 in die neue Laborgruppe BS3 konntendas Know-How und die Erfahrungen zu Konzepten, Losun-gen und Problemen aus der BS1-Entwicklung unmittelbarauf das BS3 ubertragen werden. Teilweise war auch eine di-rekte Ubernahme von Programmteilen, wie beispielsweise

1 3


der Software fur den Satellitenrechner TR86S, moglich.Alle Mitarbeiter waren außerst kompetent, sie hatten eingroßes Ziel vor Augen und verfolgten dies mit ungeheu-rem Engagement. Drei Sachverhalte beleuchten die Situa-tion: Die Mitarbeiter machten erhebliche Uberstunden; eswar moglich zu jeder Tages- und Nachtzeit in das Buro zukommen oder dieses zu verlassen; es wurden Gesprache mitdem Betriebsrat gefuhrt, um die strenge Einhaltung einerelfstundigen Pause zwischen zwei Arbeitstagen zumindestzu lockern.

Ab April 1971 wurde Franz Stetter verantwortlicher La-borgruppenleiter BS3 und W. Frielinghaus ubernahm zu die-sem Zeitpunkt die Projektleitung fur die Software des Nach-folgerechners zum TR440 (Arbeitstitel TR550) im Rahmeneiner kleinen Matrixorganisation innerhalb GR/P. Das Pen-dant war die Projektleitung fur die TR440 Software, wahr-genommen durch Joachim Feldmann.


Wie bereits erwahnt, war 1969 das BS3 mit Stapelbetriebfur zwei parallele Programme verfugbar. Es entwickelte sichuber mehrere Maintenance-Versionen, von MV1 bis MV18,schnell in Richtung eines komfortablen Teilnehmersystemsmit mehreren Prozessoren, mit Datenfernverarbeitung undmit Rechnerkopplung.

Das BS3 verwandte ebenfalls den Begriff Operator, indem gleichen Sinne wie beim TR4-Betriebssystem undbeim BS1. Operatoren waren Programme, die in der Umge-bung eines Abwicklers ablaufen konnten und entsprechendeRegeln beachteten. Operatoren konnten beispielsweiseUbersetzer, Montierer, Kommando-Entschlussler oder vomAnwender geschriebene und ubersetzte Programme sein.Das BS3 (Stand etwa 1970 [4, 52, 54, 70, 75]) stellte 7 Ab-wickler (ABW) fur Operatoren bereit. Ein Abwickler wareine dynamisch zuteilbare Ressource des Betriebssystems.Ein Abwickler stellte die betriebssystemorientierte Ablauf-umgebung eines Benutzerprogramms, genauer eines Opera-tors, bereit und war aus der Sicht des Betriebssystems einProzess (Akteur). Die Abwickler arbeiteten im Abwickler-modus des TR440. Die wichtigsten Aufgaben der Abwick-ler waren: Verwaltung und Start von Operatorlaufen (OL),Vermittlung von Dienstleistungen des Betriebssystems furOperatorlaufe, Bereitstellung der Daten- und Dateidienste.Innerhalb des Abwicklers fand keine Parallelarbeit der Ope-ratoren statt, jedoch wurde eine Operatorenkette (zeitlicheSequenz von Operatoren) verwaltet und durch Dienste un-terstutzt. Jeder Operator konnte neue Operatoren in dieseKette einfugen. In einer spateren Ausbaustufe war auch eineVerschachtelung von Operatorlaufen moglich, d.h. ein Ope-rator konnte einen anderen Operator starten und auf dessenEnde warten. Das Betriebssystem, genauer die Kontroll-

funktion, konnte einem Abwickler den Auftrag geben, einenOperator zu verdrangen. Dadurch wurde der Abwickler furandere Operatoren frei.

Neben den Abwicklern gab es noch Systemakteure undVermittlerprozesse. Beides waren Systemprozesse und rea-lisierten Systemdienste, bei denen Wartezustande auftre-ten konnten. Die Systemakteure waren: Warteschleifenpro-zess WSL, Trommelvermittler TRV, Plattenvermittler PLV,Notschleife NSL und Operateurvermittler OPV. (Anmer-kung: TRV und PLV wurden von W. Schwarzmann in derGruppe J. Schilling entwickelt.) Die Systemakteure lie-fen im Systemmodus ab, da sie direkt auf die Hardwarezugriffen. Die wichtigsten Aufgaben der Vermittlerpro-zesse waren die Verwaltung der langsamen EA-Gerate unddie Ausfuhrung von Transportauftragen fur diese Gerate.Beispiele fur weitere Vermittlerprozesse waren Drucker-vermittler DRV oder Kartenleservermittler KLV. Auch derSatellitenrechner TR86S war aus der Sicht des TR440ein Gerat und wurde vom Satellitenvermittler SAV be-dient. Die Trennung der Ein/Ausgabe von den Anwen-derprogrammen war also damals schon (weit vor IBM)realisiert. Auch logische Gerateadressen waren noch keineSelbstverstandlichkeit.

Das BS3 hatte somit eine auch heute noch sehr moderneSystemarchitektur. Es war kein monolithisches, sondernein prozessorientiertes Betriebssystem. Da viele Teile desBetriebssystems als Prozesse organisiert waren, war derSystemkern klein und verwaltete lediglich den Arbeitsspei-cher, die Prozessoren, die Gerate und die Transportkanale(Kanalwerke) zu den Geraten. Die Verwaltung beinhal-tete nur die hardware-orientierte Gerateverwaltung, alsoBelegung und Freigabe eines Gerats durch Prozesse so-wie die Ausfuhrung von Transportauftragen von und zumGerat. Der Systemkern stellte so fur die Systemakteureund die Prozesse eine abstrakte Hardware-Schnittstellebereit und befreite diese somit von speziellen Hardware-Abhangigkeiten. Ein Konzept, das damals neu war, aberheute fundamental fur moderne Betriebssysteme gewordenist. Die Blockstruktur aus dem Jahr 1970 zeigt Abb. 3 [54].

Das BS3 unterstutzte virtuelle Adressierung, hatte aberwie BS1 zunachst keinen dynamischen Seitenwechsel.Stattdessen wurden wie im BS1 ganze Gebiete zwischenArbeits- und Hintergrundspeicher verlagert. Es gab ge-trennte Gebiete u.a. fur die Befehle eines Programms, furdie Konstanten und fur die Variablen. Gebiete wurde manheute als Segmente bezeichnen. Durch Wahl eines Gebietsals Transporteinheit sollte die Transportzeit minimiert wer-den. Eine weitere Reduzierung der Transportzeit erfolgtedadurch, dass versucht wurde, die Verlagerung mit einemeinzigen Transportbefehl durchzufuhren. Hierzu musste einGebiet kompakt auf Hintergrundspeicher abgelegt werden.Im virtuellen Adressraum lag ein Gebiet ebenfalls zusam-menhangend, nicht jedoch im realen Arbeitsspeicher. Dies

1 3

248 Siegert

Abb. 3 Blockstruktur des BS3

war moglich, da die Transportbefehle dort gestreutes Lesenoder Schreiben erlaubten.

Das Betriebssystem kannte zwei Arten von Benutzer-auftragen, die Abschnitte (auch Stapelauftrage) und die Ge-sprache (auch Dialogauftrage).

Die Kontrollfunktion (KFK) steuerte den Ablauf derAuftrage bzw. der Prozesse. Sie war Teil des Betriebssys-tems, aber als Prozess realisiert. Basis der Steuerung wareine strategische (logische) Verplanung der Betriebsmit-tel auf einer hohen Ebene, beispielsweise wurde nur dieSumme der benotigten Festplattenblocke fur einen Ope-ratorlauf vor dessen Start eingeplant, nicht aber welcheBlocke bei Bedarf dann zugewiesen werden. Verantwortlichfur die KFK war H. Meißner, der auch schon fur die KFKdes BS1 verantwortlich war. Verplant wurden neben denklassischen hardware-orientierten Komponenten auch dieSoftware-Komponenten, wie Abwickler- oder Vermittler-Prozesse. Die Kontrollfunktion des BS3 verwandte keineNutzenfunktion, sondern klassische Algorithmen. Fur Sta-pelauftrage beispielsweise Prioritatensteuerung; Entzug vonRessourcen durch Verdrangung von Prozessen beim Ein-treffen wichtigerer Abschnitte; moglichst gute Auslastungder Rechnerkerne; moglichst hohe Nutzung des Arbeits-speichers fur Operatoren, d.h. es sollte moglichst we-nig Verschnitt geben und es sollten moglichst viel rele-vante Daten im Sinne des ,,Working Set“ vorhanden sein.Fur Dialogauftragewurde ein Zeitscheibenverfahren unterBerucksichtigung langfristiger Wartezustande verwendet.Es waren akzeptable Kompromisse zu finden bei dem klas-

sischen Problem, dass sowohl hohe Reaktionsfahigkeit alsauch hohe Auslastung gewunscht wurden, diese beidenZiele aber im Widerspruch zu einander stehen. Zu der da-maligen Zeit wurde die Situation noch dadurch verscharft,dass die Geldgeber bei den Rechenzentren auf extrem hoheAuslastungen drangten und Nachfolgebeschaffungen davonabhangig machten, aber andererseits die gewunschte Pro-duktivitat der Nutzer eine sehr gute Reaktionsfahigkeit desSystems erforderte.

Im Dialogbetrieb konnten bis zu 48 Konsolen (Termi-nals) gleichzeitig bedient werden, in spateren Versionensehr viel mehr. Der Benutzer konnte uber ein Terminal inden Ablauf seiner Programme eingreifen und ein Wechsel-gesprach mit diesen fuhren. Voraussetzung hierfur war, dassdie Programme gesprachsfahig waren. Genaueres hierzu inAbschn. 12.

Der Plattenspeicher war in vier Bereiche aufgeteilt, de-ren Grenzen in das Betriebssystem fest einkompiliert waren.Drei dieser Bereiche waren zweckgebunden fur Gebiete, furdie langfristige Datenhaltung und fur das Dokumentations-system TELDOK. Der vierte Bereich war frei verfugbar.Der Plattenspeicher war in logische Blocke von der Großeeiner Seite unterteilt. In jedem Bereich begann die Numme-rierung bei Null. Die einem Objekt zugewiesenen Blockewaren nicht zwingend konsekutiv.

Mehrere Dateien wurden verwaltungsmaßig in einer Da-tenbasis zusammengefasst. Es gab drei Arten von Daten-basen: Die offentliche Datenbasis, die Standard-Datenbasenund die Datenbasis fur die langfristige Datenhaltung.

1 3


Die offentliche Datenbasis wurde beim Systemauf-bau erstellt und enthielt die systemeigene permanenteBibliothek. Sie umfasste u.a. die Ubersetzer der Pro-grammsprachen und samtliche sonstigen Dienstleistungs-programme des Programmiersystems, die Montageobjektealler Bibliotheksunterprogramme und die Makrobibliothek.Auf diese Daten konnte von allen Benutzern, naturlichnur lesend, zugegriffen werden. Eine Standarddatenba-sis wurde zu Beginn eines Auftrags (Gesprach oder Ab-schnitt) erstellt. Sie enthielt die temporare Bibliothekdieses Auftrags, also die von den Ubersetzern erzeug-ten Montageobjekte, Ruckverfolgungslisten, die Opera-torkorperbeschreibungen startfahiger Operatoren und tem-porare Dateien des Benutzers. Weitere private Datenba-sen konnte man zusatzlich kreieren; diese wurden wie dieStandarddatenbasis am Ende der Bearbeitung des Auftragsaufgegeben.

Im Betriebssystem wurde eine langfristige Datenhaltung(LFD) realisiert. Langfristig gehaltene Daten wurden vomBS3 verwaltet und gesichert. Verantwortlich fur die LFDund die Datenverwaltung war L. Stolze, der als Laborlei-ter von der Gruppe Schilling zur BS3-Gruppe kam. DieLFD ermoglichte dem Benutzer die Haltung von priva-ten permanenten Dateien auf dem Plattenspeicher, also vonDateien, die nicht nur ein Gesprach oder einen Abschnittuberdauerten, sondern unabhangig vom Vorhandensein desBetriebssystems bestanden. Aus diesem Grund musste zujeder langfristig gehaltenen Datei auch deren Kontext (Be-schreibung) bzw. deren Verwaltungsinformation auf derPlatte abgelegt werden. Das Inhaltsverzeichnis war nachBenutzerkennzeichen geordnet. Das Benutzerkennzeichenliess sich daher als Name eines Unterordners fur alle Da-teien eines Benutzers oder auch als Name einer benutzerei-genen permanenten Datenbasis interpretieren. Dies brachteden Vorteil, dass keine Verwechslungen zwischen gleichna-migen Dateien verschiedener Benutzer entstehen konnten.Außerdem war es dadurch moglich, nur berechtigte Benut-zer zuzulassen und eine Prufung auf maximale Dateianzahlund maximalen Plattenspeicherbedarf fur einzelne Benut-zer durchzufuhren. Neben den privaten Dateien gab es auchGemeinschaftsdateien in der LFD. Fur den Zugriff auf Ge-meinschaftsdateien wurde eine automatische Koordinierungvorgenommen (Leser-Schreiber-Problem), derart, dass ent-weder nur ein Benutzer mit schreibenden Zugriff auf dieDatei zugelassen wurde oder dass beliebig viele Benutzergleichzeitig lesen konnten. Lese- und Schreibpassworterdienten zur Sicherung der Dateien gegen unerwunschtenFremdzugriff.

Die Kommunikation zwischen Prozessen erfolgte ubereinen gemeinsamen Bereich des Arbeitsspeichers, dem sogenannten Depot. Dieses hatte eine Große von 1 KWorte.Der vordere Teil des Depots war formatfrei, der hintere Teildes Depots war in Elemente von 5 Ganzworten Lange un-

terteilt. Dieser Teil war das Teildepot. Der Zugriff auf denvorderen Teil des Depots musste synchronisiert werden, da-her konnte ein Prozess eine Sperre setzen. Bei der Depotver-waltung musste, wie bekannt, auf Verklemmungen geachtetwerden und darauf, dass der Operateur in jeder Situationnoch eingreifen konnte.

Das Betriebssystem stellte seine Dienste uber etwa 35Systemaufrufe (SSR-Befehle) bereit. Einen Ausschnitt zeigtTabelle 3.

Wie erwahnt, waren die Dienste fur den Zugriff auf Da-teien im Abwickler und nicht im Betriebssystemkern. Dierealisierten Dateitypen im BS3 waren sequentieller Zugriff(SEQ), Zugriff uber Satznummern (RAN) und Zugriff uberSatzmarken (RAM).

Einen Eindruck der schnellen zeitlichen Entwicklung desBS3 gibt die folgende Auswahl einiger markanter Eck-punkte [76]:

• MV9 (4/71): Zentrales (Fehler-)Protokoll, Verringerungdes Arbeitsspeicherbedarfs des Systems.

• MV10 (8/71): Tageskonserven bei der langfristigen Da-tenhaltung (LFD).

• MV11 (2/72): Weitere Reduktion des Arbeitsspeicher-bedarfs durch Segmentierung des BS-Kerns, durch Ge-meinschaftsgebiete und durch Codesharing bei denUbersetzern und Anwendungen, zentrale Pufferverwal-tung, multiplexende Vermittler fur Gerate eines Typs,dynamische Hintergrund- und Arbeitsspeicherplanung,dynamische Prioritatsvergabe, Betrieb von Wechselplat-ten, Anschluss mehrerer TR86S parallel oder in Kaskade,

Tabelle 3 Einige SSR-Befehle

Adreßteil BedeutungSymbol

A Abmelden eines EA-GeratesB Bringen der relativen MaschinenzeitBP Bringen der relativen ProzeßzeitC Fortsetzen eines pausierten ProzessesD Bringen des DatumsE Erneuern gesperrter StartauftrageF Fortsetzen eines Prozesses im NormalmodusFA Fortsetzen eines Prozesses im AbwicklermodusG Depot (Gemeinschaftsspeicher)-ZugriffHLT Dynamisches Ende eines ProgrammlaufesI Informieren uber eigene Programm-NummerJ Informieren uber den Status eines Fremd-ProzessesK KurzpauseKA Kurzpause mit Abfrage AnrufL Loschen gesperrter StartauftrageM Auftrag an Operateur mit anschl. EingabeN Ausgabe eines Textes an den OperateurNS Notschleifenstart und SSR N0 Abbruch eines FremdprozessesP Anmelden eines GeratesPL Auftrag an PlattenvermittlerQ Prozeß in Zustand Pause setzen

1 3

250 Siegert

grafisches Sichtgerat SIG100 mit Grafiksoftware, Kata-loge fur alle Datenbasen.

• MV12 (6/72): TR440-Doppelprozessorsystem [66], Re-start und Rerun, Verbesserung der Terminalreaktionszei-ten, Verbesserung der LFD, Hintergrund-Modul-Verwal-tung, 96 Terminals, Massenspeicher, zeilenorientiertesSichtgerat SIG50.

• MV13 (12/72): Erweiterung Rerun und Restart, 10 Ab-wickler, Benutzerstapel auf Wechselplatten, Datensta-tion DAS 3200, Plotter am TR86S, Papierperipherie amTR86S, Bearbeitung von IBM-Bandern, verbesserte Sys-temgenerierung.

• MV13N (6/73): Rechnerkopplung TR86S zu TR86S ubergemietete Postleitungen (48 Kbaud).

• MV14 (10/73): Satzweises Konservieren und Restaurie-ren bei der LFD, TR86S-Restart bei Gesprachen, dy-namischer Seitenaustausch (demand paging) intern imAbwickler, Planung mit Betriebsmittelnachforderungen,Dateien mit sequentiellem Zugriff großer 2 Gigaworte,verbesserte Systemgenerierung, Segmentierung des Ab-wicklers, Operatorlaufverschachtelungen bis zur Tiefe 8,Systemkern installationsunabhangig.

• MV15 (6/74): Retten verdrangter Auftrage uber System-neustart, 22 Prozesse, Dateityp RAS (wahlfreier Zugriffmit Satzschlusseln), zeilenorientiertes Sichtgerat SIG51,Erweiterungen der Systemgenerierung und der System-fehlerdiagnose.

• MV16 (12/74): Dateien mit wahlfreiem Zugriff großer2 Gigaworte, Benutzerrestart, WechselplattenspeicherTyp WSP430, WSP-Verwaltungsdienste fur Operateur,Wahlverkehr bei Terminals, ISO-Standard fur Magnet-bander, mehrere Dateien auf einem Magnetband, Dateienuber mehrere Magnetbander.

Diese Aufstellung zeigt, dass wichtige Entwicklungenin Richtung kleinerer Ressourcenbedarf, hohere Zuver-lassigkeit, automatisierte Systemgenerierung, Anschlussneuer auf den Markt kommender Gerate und Vernetzunggingen. Wichtig waren auch strukturelle Anderungen im Be-triebssystemkonzept, um einerseits neue Funktionen oderhohere Leistung zu erhalten und um andererseits die Wei-terentwicklung und Pflege zu erleichtern. Besonders seiauf die Erweiterung des BS3 zu einem Mehrprozessor-Mehrprozess-Teilnehmersystem hingewiesen. Dieses wurdeMitte 1972 an das Leibniz-Rechenzentrum in Munchenausgeliefert.

11 Satellitensystem, Dialogperipherieund Rechnerkopplung

Eine wichtige und wegweisende Entscheidung schon zu Be-ginn der TR440-Entwicklung war, die zeichenorientierten

Gerate nicht direkt an den TR440 anzuschließen, sondernan einen Satellitenrechner, den TR86S. Der TR86S warein mittlerer (Prozess-)Rechner TR86 mit spezieller Soft-ware. Im Grundausbau war ein TR86S an den TR440 ubereinen schnellen Kanal gekoppelt. An den TR86S warenzunachst Fernschreiber und alphanumerische Sichtgerate imRollmodus (Fernschreibmodus) angeschlossen, spater auchSichtgerate im Schreibtafelmodus und interaktive grafischeSichtgerate (Vektorgrafik) mit Rollkugelsteuerung. Nebendieser so genannten Dialogperipherie, konnten auch Papier-peripheriegerate direkt an den TR86S oder Datenstationenmit Kartenleser, Drucker und Bedienkonsole uber Stand-oder Wahlleitungen angeschlossen werden.

Damit war damals schon der erste wichtige Schritt zurDezentralisierung gemacht worden, namlich der Zugangzum Rechner vor Ort beim Benutzer.

Spater (etwa 1972) war es moglich, an den TR440 mehrereSatellitenrechner und an jeden Satellitenrechner wieder meh-rere Satellitenrechner anzuschließen Die Satellitensoftwarewar so konzipiert, dass sie unabhangig von der Stelle war, ander der TR86S innerhalb der Kaskade verwendet wurde. DieSatellitenrechner konnten auch uber gemietete Postleitungengekoppelt werden, ab 1973 uber (damals schnelle) 48-Kbit/s-Leitungen. Damit war es moglich, auch Satellitenrechner mitden Sichtgeraten dezentral beim Benutzer aufzustellen. In ei-nem nachsten Entwicklungsschritt wurden auch TR440 oderFremdrechner uber einen TR86S angekoppelt. Damit warenwesentliche Voraussetzungen fur eine dezentrale Datenver-arbeitung und fur eine Vernetzung von Systemen geschaffenworden. Beides waren fundamentale Technologien, die wei-terentwickelt wurden und heute eine zentrale Rolle bei derInformationsverarbeitungspielen.

Nach dieser groben Beschreibung des Satelliten-systems aus Anwendersicht, nun einige technischeHighlights [25, 26].

Das Satellitensystem bestand aus dem Satellitenver-mittler (SAV) im TR440 und dem Betriebssystem imTR86S. Letzteres wurde auch KonsolverteilerprogrammKVP oder Satellitenprogramm SAP genannt. Die Konzep-tion und Realisierung der Software (SAV und SAP) fur dasSatellitensystem erfolgte in einer Laborgruppe von GR/Punter der Leitung von M. Evers. Ziele bei der Entwicklungdes Satellitensystems waren:

• Entlastung des TR440 von den vielen Unterbrechungen,die bei zeichenweiser Ein- und Ausgabe zu den Dialog-geraten entstehen,

• Entlastung des TR440 von der Abwicklung vielfaltigsterProtokolle bei der Ansteuerung der Dialog- und Papier-peripherie, bei der Datenfernubertragung und bei derRechnerkopplung,

• Entlastung des TR440 von der Umcodierung von Zeichen-satzen, die spezifisch fur die angeschlossenen Gerate sind,

1 3


• Realisierung aller Vorgange mit harten Realzeitforderun-gen im TR86S,

• Gerateunabhangigkeit der Schnittstelle zwischen TR440und TR86S bzw. den dort angeschlossenen Geraten.

Die den verschiedenen Geratetypen zugeordneten Vermitt-ler im TR86S sammelten Eingaben zeichenweise oder zei-lenweise zu Blocken auf, die zu großeren Blocken aggre-giert an den TR440 weitergeschickt wurden. Umgekehrt er-hielt das SAP vom TR440 in geratespezifische Einheitengegliederte Blocke, die je nach Adressierung an nachgeord-nete Satellitenrechner oder zerlegt an die jeweiligen Ver-mittler der angeschlossenen Peripheriegerate weitergegebenwurden. Dadurch wurde die Zahl der Unterbrechungen beimTR440 auf einen Bruchteil der ursprunglichen reduziert.

Das Satellitensystem kannte die TR440-Kommandosausschnittsweise, deshalb konnte es beispielsweise Ein-gaben außerhalb eines Abschnitts oder eines Gesprachsverwerfen, Ausgaben durch die Eingabe eines Abbruch-Kommandos beenden, bei interaktiver Grafik die Eingabe-zeichen an der vom Benutzerprogramm vorgegebenen Stelleprotokollieren oder den Abschluss der Eingabe einer Zei-chenfolge erkennen und diese an den SAV weitergeben.

Fur die Eingabe bestanden harte Echtzeitanforderungen,fur die Ausgabe aber nicht. Trotzdem sollten die Protokoll-verzogerungen aus der Sicht der Benutzer im Bereich vonetwa 100 ms liegen. Um die Echtzeitforderungen erfullenzu konnen, war die Satellitensoftware arbeitsspeicherresi-dent und es wurde eine Prioritatensteuerung sowie eine Zer-legung von Auftragen in Teilauftrage verwendet. Hierzuwurde, wie auch heute bei Echtzeitsystemen ublich, das ge-samte Echtzeitsystem in Moduln zerlegt. Damit wurde eineAufgabe oder ein Dienst durch den Ablauf einer Folge vonModuln, also einer Folge von Teilschritten, erbracht. JederTeilschritt konnte innerhalb einer fur alle Moduln gleichenZeitschranke erledigt werden. Diese Zeitschranke und damitdie Granularitat der Modularisierung wurde so festgelegt,dass die gewunschten Reaktionszeiten erreicht wurden.

Ein Modul konnte nur durch Unterbrechungen von Ge-raten kurzzeitig den Rechnerkern verlieren, erhielt ihn aberdann sofort wieder. Abgesehen von diesem Fall wurdenModuln nicht unterbrochen und gaben am Ende der Teil-aufgabe freiwillig den Rechnerkern ab. Es lag also einenichtpraemptive Rechnerkernvergabestrategie vor.

Wahrend ein Modul arbeitete, erzeugte er im Allgemei-nen weitere Auftrage. Außerdem konnten in dieser Zeitdurch Unterbrechung weitere Teilleistungsforderungen ent-stehen. Auf Grund einer Unterbrechung wurde genau eineTeilleistung erbracht, wahrend die moglicherweise dar-aus resultierenden weiteren Teilleistungen in Form vonAuftragen registriert wurden. Jedes Mal wenn ein Moduleine Teilleistung auf Grund eines Auftrags (nicht auf Grundeiner Unterbrechung) erbracht hatte, fand eine Uberprufung

der gesamten Auftragssituation statt und es wurde ent-schieden, welchem Modul der Rechnerkern zuzuteilen war.Dabei war die Prioritat des Moduls maßgebend, es sei dennein Modul geriet in einen Engpass, d.h. er konnte einen Auf-trag nicht absetzen.

Durch die Konstruktion der Satellitensoftware wurdenEngpasse und Verklemmungen vermieden. Die den Geratenzugeordneten Moduln wurden durch Unterbrechungen beiEingabe von Zeichen angesprochen. Die innere Kommu-nikation zwischen den Moduln erfolget uber deponierteAuftrage in modulspezifischen Warteschlangen. Die Zutei-lung des Rechnerkerns erfolgte nach Prioritaten. Ausgabe-moduln hatten niederere Prioritat als die Eingabemoduln.Die Ausgabe zu den Geraten wurde nicht vom TR440 spon-tan geschickt, sondern vom TR86S beim Satellitenvermittlerangefordert, dadurch konnte bei der Ausgabe kein Engpassentstehen. Weiterhin sollte so konfiguriert werden, dass diein Richtung TR440 abgehende Datenleitung eines TR86Seine großere Ubertragungskapazitat hatte als die Summeder an diesen TR86S angeschlossenen Datenquellen (Gerateund andere TR86S), damit eingabeseitig moglichst kein Da-tenstau entstehen wurde.

Im TR440 war der Satellitenvermittler der gemeinsameKommunikationspartner aller Programmlaufe, die mit ei-nem am TR86S angeschlossenen Gerat kommunizierten.Der SAV nahm im Kernspeicher oder auf dem Hinter-grundspeicher gepufferte Ausgaben entgegen und ubergabsie in Teilstucken nach Aufforderung an das Satellitenpro-gramm. In der Gegenrichtung nahm der SatellitenvermittlerEingabeinformation von dem Satellitenprogramm entgegen;unvollstandige Eingabeinformation pufferte er auf Hinter-grundspeicher, vollstandige Eingabeinformation wurde anden betroffenen Programmlauf weitergeleitet.

Ein weiteres Regulativ im Falle der Uberlastung durchdie nichtsteuerbaren Eingaben, war die angepasste Dros-selung der Ausgabe an die TR86S-Peripherie. Außerdemkonnte ein TR86S in einer Kaskade beim ubergeordnetenTR86S bzw. TR440 die Ubernahme von Information fureinen nachfolgenden TR86S sperren. Da an den Dialog-geraten ein strenges Wechselgesprach herrschte, wurdedurch die Drosselung der Ausgabe auch die Eingabe desBenutzers verzogert. Diese Losung wurde einem Quittungs-spiel zwischen Eingabegerat und TR86S vorgezogen, da soweniger Unterbrechungen entstanden.

Die Bedeutung der dezentralen Datenverarbeitung unddes Rechnerverbundes war den Verantwortlichen schonfruhzeitig klar. Auch von Kundenseite wurden solcheWunsche an Telefunken-Computer herangetragen. SchonAnfang der 70-er Jahre, also bald nach dem ersten Zusam-menschluss von Rechnern zum ARPA-Netz, begannen inder Software-Entwicklung intensive Untersuchungen undPlanungen zum Rechnerverbund in all seinen Facetten.Auch noch aus heutiger Sicht zentrale Vorstellungen und

1 3

252 Siegert

konkrete Entwicklungsschritte sind beispielsweise bereitsAnfang 1973 in einem internen Dokument [64] niederge-legt. So wurde dort angefuhrt, dass eine langere Zeitspannebis zur Ablosung (Standzeit) der TR440-Rechner durcheinen Last- oder Funktionsverbund erreichbar sei, wenn derSpitzenbedarf uber das Netz abgedeckt oder die Vorteile desTR440-Time-Sharingsystems mit der hohen Rechenleistunganderer Rechner gekoppelt werden konnte. Ende 1973 infor-mierten sich beispielsweise M. Evers und H.-J. Siegert vorOrt in den USA uber aktuelle und zukunftige Entwicklun-gen bei Rechnernetzen.

In einem Firmenprospekt von 1972 [73] war zu lesen:»Ein weiterer Beweis fur die offene und benutzerfreundli-che Konzeption ist die Adaptionsfahigkeit des Systems anRechner anderer Hersteller. Der Dialog zwischen Compu-tern beginnt Wirklichkeit zu werden.«

12 Programmiersystem und Compiler

Das Programmiersystem [62, 72] war eine Schicht zwi-schen Betriebssystem und Standard- bzw. Anwenderpro-grammen. Standardprogramme waren beispielsweise dieCompiler. Das Programmiersystem setzte sich aus vielen,in ihren Leistungen aufeinander abgestimmten Program-men zusammen, die in der offentlichen Datenbasis desSystems lagen. Die Programme lagen entweder als Ope-ratoren (lauffahige Programme) oder als Montageobjektevor. Montageobjekte waren relativ adressiert (Relativcode,Montagecode) und konnten noch Außenbezuge enthalten.Sie wurden an die zu erzeugenden Operatoren ,,mon-tiert“. Beispiele fur Teile des Programmiersystems warender Montierer (Binder), der Lader fur Programme, derKommandoentschlußler (eine ,,Shell“), die Testhilfen, dieDumpoperatoren oder auch die als Montageobjekte vorlie-genden E/A-Aufbereitungsprogramme zur Abbildung derE/A-Schnittstellen von Sprachen auf die Dateidienste desBetriebssystems.

Das Programmiersystem und die Compiler wurden ineiner Laborgruppe entwickelt, deren Leitung zunachstW. Frielinghaus hatte, dann ab 1969 A. Hoyer. 1972hatte A. Hoyer einen schweren Autounfall und seine La-borgruppe wurde am 1.8.1972 von Eberhard Schmolzubernommen. E. Schmolz kam im Spatsommer 1968 vomAEG Forschungsinstitut Ulm nach Konstanz zur COBOL-Entwicklung. Am 1.4.1973 wurde die Laborgruppe in zweiLaborgruppen aufgespalten: Compiler und Programmiersys-tem. Verantwortlich fur die Compiler war E. Schmolz, furdas Programmiersystem Norbert Linn.

Ein Auftrag an das System bestand aus der eigentlichenInformation, die von der Rechenanlage zu verarbeiten war(Quellen, Daten), und Angaben daruber, in welcher Formdas geschehen sollte (Steuerinformation). Die Steuerung er-

folgt durch Kommandos, die der Entschlussler auswerteteund ausfuhrte. Designer der Kommandosprache war PeterNamneck. Kommandos wurden mit einem Fluchtsymboleingeleitet. Ihre Syntax war einheitlich, unabhangig vomEingabemedium und unabhangig davon, ob es ein Stapel-auftrag war oder ein Gesprach. Dies war zu dieser Zeitnicht selbstverstandlich. Auch in anderen Aspekten ging dieKommandosprache damals weit in die Zukunft und hatte Ei-genschaften, die auch heute noch wichtige Merkmale furShells sind:

• Gleiche syntaktische Grundstruktur aller Kommandos,unabhangig von der Anwendung,z.B. �UEBERSETZE,SPRACHE= . . .

• Anfangs- und Ende-Kommandos fur Abschnitte (Stape-lauftrage) und Gesprache (Dialogauftrage) gehorchtenden gleichen Regeln wie andere Kommandos.

• Die Parameter (Spezifikationen) eines Kommandos wa-ren benannt. Ein Parameter hatte die Form<Spezifikationsname>=<Spezifikationswert>.Kommandonamen und Spezifikationsnamen konnten ab-gekurzt werden, solange Eindeutigkeit bestand. Die Pa-rameter waren zusatzlich noch positionsabhangig defi-niert. Wurde die Positionsreihenfolge eingehalten, dannkonnte auf die Angabe des Spezifikationsnamens ver-zichtet werden. Es gab obligate und optionale Parameter.So mussten z.B. zum UEBERSETZE-Kommando immerdie Quelle sowie die Sprache angegeben werden, also�UEB.,Q.=TEXTDATEI,SPR.=ALG60 . . .

• Spezifikationsnamen waren als Variablennamen im Kom-mandoentschlussler anzusehen, denen Werte zugewiesenwerden konnten. Wollte ein Benutzer etwa eine Reihevon ALGOL-Programmen nacheinander ubersetzen, sokonnte er deklarieren:�∗SPRACHE(UEBERSETZE)=ALG60Er musste sich dann in den folgenden UEBERSETZE-Kommandos die Sprache nicht mehr angeben.

• Der Entschlussler hatte ein benutzerspezifisches Ge-dachtnis, das ausgehend von einer allgemeinen Grund-einstellung durch den Benutzer verandert werden konnte.Das Gedachtnis galt auf jeden Fall wahrend eines Stapel-auftrags oder eines Gesprachs eines Benutzers. Es konnteaber am Ende eines Auftrags exportiert und zu Beginn ei-nes Auftrags importiert werden, damit lebte es uber eineAuftragsbearbeitung des Benutzers hinaus.

• Es konnten Kommandoprozeduren mit formalen Parame-tern aber auch (neue) Kommandos fur (neue) Programmedes Benutzers definiert werden.

• Kommandofolgen waren dynamisch veranderbar. Wurdedas Kommando FEHLERHALT gegeben, dann wurdeder Auftrag bei Auftreten eines Fehlers bei der Aus-fuhrung von Programmen abgebrochen. Das KommandoSPRINGE wertete eine Bedingung aus auftragsspezifi-

1 3


schen Variablen aus und sprang gegebenenfallsauf ein beliebiges nachfolgendes Kommando derKommandofolge.

Peter Jager [38] machte im Internet folgende Bemerkungzur TR440-Kommandosprache: »Noch bestanden dieseSoftware-Produkte aus Stapeln von hunderten und tau-senden von Lochkarten oder Kuchenteller großen Ma-gnetbandern. Aber bereits die Berechnung einer riesigenMenge von Kennzahlen fur gedruckte Taschenbucher undDatensammlungen versetzten die Fachwelt in Erstaunen.Die EDV-Technik entwickelte sich bereits in einem Tempo,das selbst unter heutigen Verhaltnissen nur als atembe-raubend bezeichnet werden kann. Plattenturme von derGroße einer großen Tiefkuhltruhe zeigten bereits, wo derWeg hinfuhrt. Fur meine damalige Sicht, war die benutzteTelefunken-Anlage TR440 eine der fortschrittlichsten Tech-nologien uberhaupt. Die Kommandosprache war beein-druckend einfach und trotzdem absolut zuverlassig. DieSteuersprache (Job Control Language JCL), die dann fur dieIBM erlernt werden musste, war dagegen weit von Benut-zerfreundlichkeit entfernt.«

Uber den TR440 der Universitat Osnabruck wurde 1986in der Computerwoche [15] berichtet:

»Unser Rechenzentrum betreibt seit dem 1.9.1977einen TR440. Nach gegenwartiger Planung wird die-ser noch bis Mitte des Jahres 1988 betrieben werden.. . . Der Betreiber eines TR440 im Jahre 1986 sieht sich– obwohl rings umher dieser Rechner außer Betriebgenommen wurde und der TR440 nunmehr fast exo-tischen Charakter bekommen hat – in der glucklichenLage, bezuglich der Softwareausstattung von den zahl-reichen Arbeitsergebnissen der Lieferfirma und diver-ser ehemaliger TR440-Betreiber profitieren zu konnen.Die ,,Blutezeit“ des TR440 war gekennzeichnet von ei-ner sehr guten fachlichen Zusammenarbeit zwischenLieferfirma und Betreibern sowie von einem regenSoftwareaustausch der TR440-Rechenzentren unter-einander, wobei insbesondere auch leistungsfahigeSoftware aus auslandischen Institutionen von eini-gen Rechenzentren auf dem TR440 implementiert undan die anderen TR440-Rechenzentren weitergegebenwurde. . . . Ein wesentlicher Grund jedoch, dass wirkeineswegs betrubt sind, den TR440 auch noch heuteund sogar noch etwa zwei Jahre zu betreiben, war dieexzellente Benutzerschnittstelle. Das BetriebssystemBS3 und der Komfort der Kommandosprache – sowohlbezuglich der Moglichkeiten als auch hinsichtlich derzugrunde liegenden Konzeption – waren ihrer Zeit weitvoraus. Was heute von einigen Anbietern als moderneund zukunftsweisende Benutzerschnittstelle angeprie-sen wird, war fur den TR440-Benutzer ,,ein alter Hut“.Hinsichtlich des – gerade fur ein Hochschulrechenzen-

trum so wichtigen – Aspektes ,,Komfort der Benut-zerschnittstelle“ war der TR440 ein großer Fortschrittgegenuber fast allen Großrechnern, die ihn ersetzt ha-ben. Ein ausgemusterter TR440 ist inzwischen an dieNikolaus-Kopernikus-Universitat in Thorn/Polen ge-liefert worden, der zweite wird folgen, so dass amTR440 nicht nur Generationen deutscher Studentenund Wissenschaftler ausgebildet worden sind, sondernauch demnachst Generationen polnischer Studentenund Wissenschaftler.«

Zur Zeit der TR440-Entwicklung war die Software noch,,gebundelt“ also kein von der Maschine getrennt verkauf-tes Produkt mit eigenem Preis. Erst 1969 fuhrte IBM ein,,Unbundling“ der Software ein: »IBM adopts a new mar-keting policy that charges separately for most systemsengineering activities, future computer programs, and cu-stomer education courses [37]«. Zudem war es auch dieRegel, dass sich die Anwender, insbesondere im natur-wissenschaftlichen und technischen Bereich, ihre Anwen-dungsprogramme selbst realisierten. Dies waren die beidenHauptgrunde dafur, dass es bei dem TR440, den Kun-denwunschen entsprechend, Ubersetzer fur sehr viele ver-schiedene Programmiersprachen gab: Den sehr komforta-blen Telefunken-Assembler (TAS), ALGOL60, BCPL (Ba-sic Combined Programming Language), FORTRAN, Basic,COBOL, PL/1, RPG II (Report Program Generator, eineproblemorientierte, formatgebundene Sprache fur kommer-zielle und organisationsbezogene Programmierung aus derIBM-Welt) und GPSS V (General Purpose Simulation Lan-guage). Die Sprachumfange orientierten sich an denen an-derer Hersteller (wegen Kompatibilitat der Quellprogrammeder Anwender) und naturlich an Normen. Die Firma arbei-tete intensiv an internationalen Normen mit. Die genanntenCompiler wurden in GR/P entwickelt, außer dem PL/1-Compiler und dem BCPL-Compiler. Diese beiden Compilerwerden in getrennten Kapiteln behandelt.

Es war moglich, Prozeduren aus anderen Sprachen an-zuschließen; besonders fortschrittlich und wichtig waren je-doch die umfangreichen Testhilfen. Beides ist auch heutenoch nicht in dem Umfange verfugbar wie damals An-fang der 70er-Jahre beim TR440. Der Anschluss der ineiner anderen Sprache geschriebenen Prozeduren (Fremd-prozeduren) erfolgte bei der Montage [62]. Die Abb. 4zeigt die Moglichkeiten zum Anschluss von Fremdproze-duren auf. Fur den Anschluss von Prozeduren in Assemb-ler an hohere Sprachen waren seitens der Compiler keinebesonderen Maßnahmen erforderlich. Der Verfasser einerTAS-Prozedur hatte nur die Konventionen einzuhalten, nachdenen ein bestimmter Compiler seine Montageobjekte er-zeugte. Ebenso waren beim Aufruf von Prozeduren hohererSprachen aus einem TAS-Programm heraus die Konventio-nen der jeweiligen Sprache zu berucksichtigen. Bei dem

1 3

254 Siegert

Abb. 4 Aufruf von Fremdprozeduren in hoheren Sprachen

Aufruf von Fremdprozeduren aus einer hoheren Sprachegab es Einschrankungen aufgrund der unterschiedlichenAusdrucksfahigkeit der Sprachen, beispielsweise bei denParametertypen. Fur den Benutzer unsichtbare Zwischen-prozeduren (Stubs in moderner Terminologie) passten dieDatenstrukturen, die Datendarstellungen und die Regeln furden Prozeduraufruf an die unterschiedlichen Sprachen an.Teilweise wurden auch Spracherweiterungen durchgefuhrt,z.B. benannte Common-Bereiche in ALGOL 60 fur denAnschluss von FORTRAN-Prozeduren. Ein verschachtel-ter Aufruf von Prozeduren in verschiedenen Sprachen warmoglich.

Alle Testhilfen bezogen sich auf die Quellebene, d.h. derBenutzer erhielt oder gab die Informationen bezogen auf dieSprache und die Symbole, die er in seinem Programm ver-wendet hatte. Er musste also keinerlei maschinenorientierteKenntnisse haben. Wichtige Testhilfen waren [48, 62]:

• Zur Ubersetzungszeit wurde versucht, nach Fehlern wie-der aufzusetzen, so dass der Benutzer bei einem Laufmoglichst alle syntaktischen oder semantischen Fehlererfuhr. Der Benutzer konnte auch den Ausdruck ver-schiedener Listen verlangen, beispielsweise einer Refe-renzliste, d.h. welche Variablen in welcher Quellzeilevorkamen.

• Es konnten dynamische Kontrollen einkompiliert wer-den, beispielsweise Prufung der Einhaltung von Index-grenzen, der Vertraglichkeit aktueller und formaler Para-meter, der Laufparameter von Laufanweisungen uvm.

• Beim Programmablauf erfolgte im Fehlerfall eine quell-sprachenbezogene Fehlermeldung mit Angabe der Feh-lerursache und ein quellsprachenbezogener Dump. Der

Ruckverfolger gab bei einem Dump die Aufrufver-schachtelung aus, auch bei Prozeduren aus verschiede-nen Sprachen. Dabei wurden auch die Aufrufstellen derProzeduren (die Quellzeilen oder die Anweisungen in-nerhalb einer Quellzeile) angegeben.

• Ein quellsprachenbezogener Dump konnte auch an be-liebig vielen Stellen des Programms durch eine entspre-chende Anweisung mit Parametern ausgelost werden.Dabei gaben die Parameter an, was protokolliert werdensollte. Nach dem Dump wurde das Programm fortgesetzt.

• Der Programmablauf konnte Anweisung fur Anweisungauf Ebene der Quellsprache uberwacht werden (trace).

• In der Quelle konnten TRACE-Punkte definiert werden,an diesen Stellen wurde dann der Programmzustand aufQuellebene protokolliert. Damit das Protokoll klein undubersichtlich blieb, konnten Details des Protokolls defi-niert werden, beispielsweise welche Variablen protokol-liert werden sollten. Die Protokollierung konnte auch nurintern im Rechner gespeichert und erst im Fehlerfall oderauf Verlangen des Benutzers dann ausschnittsweise abge-rufen werden (Backtrace).

• Beim Dialogbetrieb spielten Kontrollereignisse eine her-ausragende Rolle. Im Ubersetze-Kommando konnte Ge-sprachsfahigkeit des compilierten Programms verlangtwerden und man konnte den Nummern von QuellzeilenKontrollereignisse zuordnen. Kontrollereignisse konntenaktiv oder passiv sein. Im Starte-Kommando wurde de-finiert, welche Kontrollereignisse am Anfang aktiv sind.Wurde ein aktives Kontrollereignis erreicht, dann wurdeder Operatorlauf angehalten und der Name des Kon-trollereignisses auf der Konsole gemeldet. Der Benut-zer konnte dann Variable (mit ihrem Namen und ihrenWerten auf Quellebene) abfragen oder setzen. Er konnteKontrollereignisse aktivieren oder passivieren. Auch dasAn-/Abschalten einprogrammierter Testhilfen oder dasBeenden des Programmlaufs war moglich.

• Im Dialogbetrieb war es zusatzlich moglich, einen Pro-grammlauf jederzeit anzuhalten und abzubrechen oderspater wieder fortzusetzen. Beim Halt konnte der Benut-zer einen Dialog mit dem Abwickler oder dem Operator-lauf fuhren. So konnte er beispielsweise neue Komman-dos eingeben, die vorrangig ausgefuhrt wurden, oder aufdie gerade genannten Testhilfen zuruckgreifen.

Die selbstgeschriebenen Compiler verfolgten ein gemeinsa-mes Architekturkonzept mit einer gemeinsamen Zwischen-sprache, beeinflusst auch von Donald Knuth und von ,,Com-piler-Compilern“ sowie ,,Compiler Writing Systems“. Furdie TR440-Compiler blieb es konkret jedoch nur beim ge-meinsamen Architekturkonzept mit ahnlichen Zwischenco-des, da die Compiler zu verschiedenen Zeiten entwickeltund auch im Hinblick auf Benchmarks unterschiedlich op-timiert wurden. Ein gemeinsamer Zwischencode fur alle

1 3


Compiler (eine universelle Zwischensprache), ein zweistu-figes Optimierungskonzept auf der Ebene des gemeinsa-men Zwischencodes (sprach- und maschinenbezogen) undeine gemeinsame Codegenerierung fur ,,alle Sprachen“ wur-den aber fur das geplante TR440-Nachfolgesystem komplettspezifiziert.

13 BCPL als Systemimplementierungssprache

Bereits ab 1969 erschien es uns wichtig und von derLaufzeit her vertretbar, die Compiler nicht mehr in As-sembler, sondern in hoheren Sprachen zu schreiben. Mit-arbeiter der Compiler-Gruppe befassten sich intensiv mitdiesem Thema und auch mit entsprechenden Aktivitatenin den USA. Es fanden eine Reihe von Untersuchungenstatt, u.a. auch im Hinblick auf eigene Sprachdefinitionenund Compilerimplementierungen fur diesen Zweck. DieEntscheidung fiel dann zu Gunsten einer Ubernahme desBCPL-Compilers von M. Richards. Sein BCPL-Compilerwurde 1970 ubernommen, auf TR440 portiert und erwei-tert [55]. Martin Richards konnte fur diese Arbeiten zeit-weise als Berater gewonnen werden. Maßgebenden Ein-fluss auf diese weitsichtige und richtige Entscheidung hatteA. Hoyer. BCPL wurde zunachst nur intern als Systempro-grammiersprache eingesetzt. Erst mit der Maintenancever-sion MV13N im Juni 1973 wurde der BCPL-Compiler auchoffiziell an Kunden ausgeliefert.

Die Sprachen CPL (Combined Programming Language,1963), BCPL (Basic CPL, 1967), B (1969) und C (1971)[53] gehoren zu einer Sprachfamilie und stellen Weiter-entwicklungen dar. CPL wurde an den englischen Univer-sitaten Cambridge und London entwickelt. Die Sprachewar von ALGOL beeinflusst. Die vereinfachte Sprachver-sion (BCPL) wurde von Martin Richards wahrend seinesForschungsaufenthalts am MIT entwickelt und ein Compi-ler dazu implementiert. Der BCPL-Compiler war selbst inBCPL geschrieben. BCPL wurde in eine Zwischensprache,den OCODE, ubersetzt. Zur Portierung musste ein Codege-nerator geschrieben werden, der den OCODE in die Maschi-nensprache transformierte.

Mit den Kunden gab es hitzige Diskussionen, ob esuberhaupt akzeptabel ware, Systemsoftware in hoherenSprachen zu schreiben. Die Kunden befurchteten zu großenLeistungsverlust und zu hohen Speicherbedarf. Es gab ja zudieser Zeit weltweit noch keine kommerziellen Systeme, de-ren Grundsoftware in hoheren Sprachen geschrieben war,so dass keine Erfahrungen dazu vorlagen. In der Software-Entwicklung wurde trotz der Skepsis beim Kunden zugigdie Verwendung von BCPL als Systemprogrammiersprache,auch beim Betriebssystem, forciert. Hierdurch wurden er-hebliche Vorteile erwartet, die im Laufe der Entwicklungauch bestatigt wurden. Damals eine Pionierleistung, ist die

Verwendung hoherer Systemprogrammiersprachen heuteselbstverstandlich. Anmerkung: Spater, nach Grundungder CGK, wurde von ehemaligen TR440-Entwicklern beiSiemens ebenfalls BCPL fur Erweiterungen des BS2000eingesetzt.

14 Neue Wege beim PL/1-Compiler

Beim PL/1-Compiler wurden von der Software-Entwick-lung weitere wichtige Schritte in die Zukunft begonnen oderfortgefuhrt. Wie im Abschn. 12 bereits erwahnt, wurde derPL/1-Ubersetzer nicht von der TR440-Software-Entwick-lung realisiert, sondern im Mai 1973 zugekauft und umdie Testhilfen und andere TR440-spezifische Funktionenerweitert.

Gekauft wurde der Quellcode des PL/1-Compilers mitallen Rechten fur etwa 600 TDM vom MIT (Massachu-setts Institute of Technology) in den USA. Dort war imRahmen des MULTICS-Projekts (ein 1969 gestartetes JointVenture von MIT, General Electric und Bell Labs) einPL/1-Compiler entwickelt worden, der Anfang 1973 auf ei-ner GE-645 fertig wurde. Der PL/1-Compiler war selbstin PL/1 geschrieben. Er wurde durch einen ,,Bootstrap-Vorgang“ auf TR440 portiert. Nach sorgfaltigen Vorbe-reitungen wurde im Mai 1973 eine dreiwochige Evaluie-rung des PL/1-Compilers und des geplanten ,,Bootstrap-Vorgangs“ vor Ort am MIT von E. Schmolz und HannoKrainer durchgefuhrt.

Fur den ,,Bootstrap“ wurde der Quellcode des Com-pilers, selbst sehr umfangreiche PL/1-Programme, auf ei-ner Maschine mit PL/1 (IBM 370) bei IBM in Boblingen(bei Stuttgart) in eine Zwischenform ubersetzt, diese wurdeper Magnetband moglichst schnell nach Konstanz gebracht.E. Schmolz (2007) erinnert sich:

»Das Ergebnis einer Nacht fullte zwei bis drei Ma-gnetbander. Mindestens 10 Mal haben wir folgendenTransporttrick angewandt: Schmolz Senior (mein Va-ter) wohnte in Stuttgart-Vaihingen, fuhr (mit Vollmachtausgestattet) um 6 Uhr ins IBM Rechenzentrum, holtedie Magnetbander, fuhr zum Bahnhof und gab sie demZugbegleiter des ,,Bahnexpress Stuttgart-Konstanz“. InKonstanz holten wir gegen 9 Uhr die Bander am Bahn-hof ab und schon konnten wir das Ergebnis der IBM-RZ-Nacht bei uns verarbeiten.«

Die Zwischenform auf Magnetband wurde dann in ei-nem nachsten Schritt am TR440 in eine ablauffahigeForm ubersetzt. Nach Durchfuhrung aller Transforma-tionen konnte der originare PL/1 Compiler selbst aufTR440 ubersetzt und damit bereitgestellt werden. Auf die-ser Basis erfolgte dann die spatere Weiterentwicklung desCompilers.

1 3

256 Siegert

Dieser Kauf war in mehrfacher Hinsicht bemerkenswert.Zum Ersten ist deutlich, dass die Software-Entwicklung inKonstanz die internationale Szene kannte und nicht abge-schlossen arbeitete. Zum Zweiten zeigt es das Kostenbe-wusstsein, denn der Kauf wurde sehr bewusst durchgefuhrt,da er billiger und zeitlich gunstiger war als eine Eigenent-wicklung. Zum Dritten hatte die Software-Entwicklung inKonstanz mit dem eingeschlagenen neuen Weg bereits Er-fahrung, namlich mit Software, die portiert werden mussteund mit Software, die in hoheren Sprachen geschrieben warund nicht mehr, wie damals ublich, in Assembler. Zum Vier-ten war es ein mutiger Schritt, der in dieser Zeit in Deutsch-land noch kein Vorbild hatte. Die technischen Risiken warendurchaus betrachtlich, wie sich wahrend des ,,Bootstraps“zeigte. Obwohl fur IBM damals die PL/1-Entwicklung einezentrale Bedeutung hatte und dementsprechend ihre PL/1-Compiler sehr gut waren, war der Betriebsmittelbedarf furdie ,,Bootstrap-Ubersetzungen“ so groß, dass diese Laufeim Entwicklungsrechenzentrum der IBM in Boblingen nurnachts und mittels Zusammenschalten mehrerer Großrech-ner zu bewaltigen waren.

Der Erfolg des PL/1-Projekts lasst sich auch daran mes-sen, dass die Siemens AG im Jahre 1975 den PL/1-Compilerdes TR440 auf die Systemfamilie 7.700 portierte.

15 Anwendungssoftware

In den 60er- und den 70er-Jahren wurde die Software oftnoch kostenlos mit der Hardware, die allein einen Verkaufs-preis hatte, ausgeliefert (bundling). Dies galt bei AEG-Tele-funken bzw. spater bei Telefunken-Computer nicht nur furdie Systemsoftware, sondern auch fur die dort entwickelteAnwendungssoftware.

Das Portfolio an Anwendungssoftware war primar durchdie Bedurfnisse der Kunden der Hochschulrechenzentrengepragt. Diese Bedurfnisse reichten von Verwaltungs- undPlanungsaufgaben bis hin zu juristischen Fachinformations-systemen. In geringerem Maße war das Portfolio durchkommerzielle bzw. behordliche Kunden bestimmt.

Ein Teil der Anwendungssoftware wurde bereits fur denTR4 und spater auch fur den TR440 unter der Leitungvon G. Schlenstedt entwickelt. Kommerziell orientierte An-wendungssoftware fur den TR440 wurde in einer Labor-gruppe des Vertriebs unter der Leitung von Neumann inBonn erstellt. Diese Laborgruppe wurde im Juni 1974 ausdem Vertrieb gelost und der Abteilung Softwareentwick-lung (GR/P, auch GR/EP) zugeordnet. Gleichzeitig zog dieGruppe nach Konstanz um. Durch die Konzentration derSoftware-Entwicklung in Konstanz sollten Synergien ausge-nutzt und die Qualitat der Software verbessert werden. DieLaborgruppe Anwendungen (GR/P3) in Konstanz wurdevon Knoth geleitet.

Um einen Eindruck zur Breite der Anwendungen zu be-kommen, diene der folgende kurze Uberblick [71, 79].

Es gab eine umfangreiche mathematische Programmbi-bliothek. Sie enthielt unter anderem elementare und spezi-elle Funktionen, Integrations- und Approximationsverfah-ren sowie Hilfsprogramme fur lineare Algebra. Fur Plotterund interaktive grafische Sichtgerate gab es die entsprechen-den Prozeduren. Programme zum Sortieren und zu Anwen-dungen der mathematischen Statistik rundeten dieses Seg-ment ab.

Als Basis fur wichtige nichtnumerische Anwendungenwurde ein Datenbank-System (DBS) entwickelt. Dies botDateiverwaltungs- und Organisationsdienste fur große Da-tenbanken. Die Datenstrukturen wurden in COBOL spezi-fiziert, die Daten langfristig im Rechner gehalten. Zugriffewaren insbesondere sequentiell, index-sequentiell und wahl-frei uber Satznummern. Es war moglich, einem indexse-quentiell gespeicherten Datensatz mehrere Indizes zuzuord-nen. Satze, die in irgendeiner Beziehung zu einander stan-den, konnten verkettet werden. In das DBS war ein Kom-pressionsprogramm integriert, das Folgen von Nullen oderLeerzeichen kompakt speicherte. Es gab allerdings keineAbfragesprache. Die Vorstellung war wahrscheinlich, dassimmer spezielle Anwendungen mit solchen Leistungen aufDBS aufsetzen wurden.

TELDOK, das Telefunken-Dokumentationssystem, setz-te auf DBS auf. Es erlaubte die rasche und gezielte Er-mittlung abgespeicherter Informationen (Texte) als Antwortauf bestimmte Anfragen. Voraussetzung hierzu war, dassdie Informationen durch bestimmte Suchbegriffe (Deskrip-toren) fur die Wiederauffindung gekennzeichnet waren. DieFestlegung der Suchbegriffe konnte frei oder an bestimmte,in einem Thesaurus/Worterbuch fest vorgegebene Begriffegebunden sein. Jedem Dokument und jedem Suchbegriffwurde vom System her intern eine eindeutige Nummer zu-gewiesen. TELDOK arbeitete mit den folgenden Dateien:Thesaurus, Dokumentenindex (nach den Namen der Do-kumente geordnet), invertierter Index (nach den Suchbe-griffen der Dokumente geordnet), Kurzreferate der Doku-mente und die Dokumententexte. Die Kommandos zur Su-che bestanden aus einer gewichteten logischen Verknupfungvon Deskriptoren. Die Suche innerhalb gefundener Doku-mente konnte verfeinert werden. DBS und TELDOK wur-den vom Bundesministerium fur Forschung und Technolo-gie zusammen mit vergeichbaren Produkten anderer Firmengefordert [13]: GOLEM, SESAM, PRISMA von Siemenssowie ADABAS von Software AG.

Um in Unternehmen die Planung von Aktivitaten, diefur die Erreichung der Unternehmensziele erforderlich wa-ren, unterstutzen zu konnen, wurden Fuhrungssysteme ent-wickelt, die im Unterschied zu reinen Auskunftssystemeneine aktive Datenbank voraussetzten. Die einmal in der Da-tenbank gespeicherten Informationen sollten ja nicht nur

1 3


abgefragt, sondern auf Grund neu eintreffender Informatio-nen mindestens ebenso haufig verandert werden.

PSS, ein System fur die Produktionsplanung und -steue-rung, setzte ebenfalls auf DBS auf. In diesem Fall war dieDatenbank aber nicht statisch, sondern wurde auf Grund neueintreffender Informationen haufig verandert. Das Systembestand aus folgenden Teilen: PSS-STP Stucklistenprozes-sor, PSS-APL Arbeitsplanprozessor, PSS-BEDA Bedarfs-ermittlung, PSS-MAWI Materialwirtschaft und PSS-KAPKapazitatsplanung.

Das Programm BKN berechnete Netzplane mit Termi-nen, Kosten und Betriebsmittelbedarfen. Es basierte aufVorgangsknotennetzen, war in FORTRAN geschrieben undauf die Planung großer Netze mit etwa 10.000 Knoten aus-gelegt. BKN wurde auch firmenintern zur Terminplanungbei der Hardware-Entwicklung eingesetzt.

Das Programm PLANIT (Programming LANguage forInteractive Teaching) war ein allgemeines System fur dencomputer-gestutzten Unterricht. Es enthielt alle notwendi-gen Komponenten von der Autorensprache uber das Lehr-programm bis zur statistischen Auswertung der Antwortender Schuler. PLANIT basierte auf einer Entwicklung derFirma ,,System Development Corporation“ (SDC) in denUSA und war damals bereits auf Rechner der Firmen IBMund Siemens ubertragen worden. Fur den TR440 entstandeine erste Version 1973.

Schlussendlich sei noch das Programm EXAPT erwahnt,das zur Programmierung numerisch gesteuerter Werk-zeugmaschinen (Bohren, Drehen, Frasen) diente und aufder Sprache EXAPT beruhte, einer Sprache, die sich inDeutschland fur diese Anwendungen durchgesetzt hatte.Das Programm verarbeitete neben den geometrischen auchtechnologische Daten.

16 Interne Rechenzentren

Ein grosses Problem fur die Software-Entwicklung wardie Bereitstellung von Rechenzeit auf einem TR440. Diesestand weder fruhzeitig, noch in ausreichendem Umfang,noch zunachst auf genugend stabilen Rechnern zurVerfugung.

Der TR440-Rechner 2 stand ab Dezember 1968 im Pruf-feld bereit. Neben den Software-Tests wurden darauf auchnoch Hardware-Nachentwicklungen und Hardware-Testsgefahren. Dies war eine unzumutbare Situation fur die Soft-ware und fuhrte zu gravierenden Terminverzogerungen.

Eine deutliche Verbesserung trat mit den Rechnern 4 (abJuni 1970), 8 (ab Juni 1971) und 12 (ab November 1971)ein. Diese wurden im AEG-Telefunken-Rechenzentrumin Konstanz aufgestellt und von diesem betrieben. DieSoftware-Entwickler waren mit dem Betrieb jedoch sehrunzufrieden, da einerseits Instabilitaten der Rechner durch

haufige Hardware-Anderungen auftraten und andererseitseine Konkurrenz um Rechenzeit vorlag, da das Rechen-zentrum alle Kunden befriedigen musste und es keinePrioritaten fur die Software-Entwicklung gab. So erhiel-ten beispielsweise die Software-Entwickler oft nicht diegeplanten Rechenzeiten oder erhielten zu oft nur in denAbend- und Nachtstunden liegende Rechenzeiten. Diesepermanenten Konflikte zwischen Software-Entwicklungund Rechenzentrum hatten gravierende Auswirkungen aufdie Software-Termine.

Mit der Grundung der TC kam der TR440-Anteil desAEG-Telefunken-Rechenzentrums als Entwicklungsrechen-zentrum zur Software-Entwicklung. Am 1.5.1972 erfolgtedie organisatorische Eingliederung als Laborgruppe GR/P4.Hier wurde schnell ein sehr umfassender und profes-sioneller Betrieb des Rechenzentrums unter der Leitungvon Dietrich Wagner erreicht. D. Wagner trat im Ok-tober 1967 als Programmierer in das AEG-Telefunken-Rechenzentrum in Konstanz ein und ubernahm dort imJuli 1969 die Leitung der Betriebsgruppen. Durch die or-ganisatorische Eingliederung in die Software-Entwicklungkonnten die Prioritaten bei der Rechenzeitzuteilung sach-gerecht festgelegt und alle Konflikte auf direktem Wegegelost werden. Dadurch und durch die spatere umfang-reiche Ausstattung war endlich eine angemessene Ver-sorgung der Software-Entwicklung mit Rechenleistungerreicht.

Das Entwicklungsrechenzentrum bestand aus 5 (Teil-)Rechenzentren (RZ1 bis RZ5). Leiter der Betriebsgruppenfur diese Rechenzentren war Jurgen Keppler. Ein Organi-gramm findet sich in Tabelle 4. In den Rechenzentren RZ1bis RZ3 stand je ein TR440 mit sehr umfangreicher Pe-ripherie, entsprechend der Angebotspalette. Das RZ4 warein TR86-Rechenzentrum. Hier standen funf Satellitenrech-ner TR86S mit der zugehorigen, ebenfalls sehr umfangrei-chen Peripherie. Das Vertriebsrechenzentrum in Konstanzmit dem TR440 Nummer 33 wurde am 1.2.1974 als RZ5 beiGR/P eingegliedert.

RZ1 bis RZ4 dienten der Software-Entwicklung. Tags-uber wurden an Entwickler Blockzeiten vergeben. Abendsund in der Nacht wurde in mehreren Schichten ein Stapel-betrieb durch Operateure gefahren. Dementsprechend gab esim Rechenzentrum (GR/P4) mit Stand 30.7.1974 rund 30Operateure (1972 wurden etwa 65 Operateure ubernommen)und etwa gleich viele sonstige Mitarbeiter. Die Auftrags-vorbereitung stellte die Auftrage fur die Nacht zusammen.Im RZ5 war immer die ausgelieferte, stabile Systemversioninstalliert. Es wurde Rechenzeit fur Kunden und alle TC-Abteilungen bereitgestellt, insbesondere fur den Vertrieb, furVorfuhrungen und Messen, fur Belastungs-, Abnahme- undBenchmarktests. Hochste Prioritat hatten Kundenarbeiten.Die Software-Entwickler erhielten nur Rechenzeit, wenn dieAnlage nicht ausgelastet war. D. Wagner erinnert sich (2007):

1 3

258 Siegert

P Entwicklungsprogrammierung Dr. SiegertP11 Projektleitung Software TR440 und TR86S FeldmannP12 Projektleitung Software TC500 FrielinghausP2 Integration und Qualitatskontrolle Muhlbach

P21 Interne Schulung SchuttP22 Qualitatskontrolle FroehlichP23 Integration und Abnahme M. HofmannP24 Analysen und Messungen MersmannP25 Testhilfe Dr. Schafer

P3 Anwendungssysteme Dr. KnothP31 Anwendungssysteme 1 GutingerP32 Anwendungssysteme 2 RostP33 Anwendungssysteme 3 SchulzP34 Anwendungssysteme 4 Benz

P4 Rechenzentrum WagnerP41 Betriebsgruppen J. KepplerP410 RechnerVerwaltung J. KepplerP411 Rechenzentrum 1 WesthagenP412 Rechenzentrum 2 Westhagen (komm.)P413 Rechenzentrum 3 BochertP414 Rechenzentrum 4 PinggeraP415 Rechenzentrum 5 BochertP42 Service MollerP43 Planung und Einrichtung JacimowitschP44 Programmberatung und Operateurschulung Niepelt

P5 Betriebssystem I Dr. StetterP51 Technologie und Koordination H. MeyerP52 Kontrollfunktion Dr. ThurnerP53 Allg. Systemdienste 1 Dr. LuhmannP54 Abwickler Dr. BurkhardtP55 Datenhaltung 1 EngelhardtP56 Datenhaltung 2 Dr. HoehneP57 Allg. Systemdienste 2 Stadie

P6 Compiler SchmolzP61 Compiler 1 N.N.P62 Compiler 2 MangoldP63 Compiler 3 Schmolz (komm.)P64 Compiler 4 Dr. KrainerP65 Compiler 5 PszollaP66 Compiler 6 U. RichterP67 Compiler 7 Indefrey

P7 Satellitensystem und Betriebssystem II EversP71 GerateVerwaltung SchichlerP72 Systemkern SchallenmullerP73 Speicherverwaltung HeinzP74 Hintergrundspeicher BremkeP75 Dialoggerate Dr. MensgerP76 Datenubertragung Dr. P. Meyer

P8 Programmiersystem LinnP81 Programmiersystem 1 Frl. GebhardtP82 Programmiersystem 2 Dr. KasparP83 Programmiersystem 3 KuhlmeyP84 Programmiersystem 4 E. SchmidtP85 Programmiersystem 5 BlattP86 Programmiersystem 6 Dr. KaabP87 Programmiersystem 7 Dr. Braess

Tabelle 4 Organigramm GR/PStand 1.6.1974

»Es gab riesige Lochkartenstapel; jeden Tag wurde uber eineTonne Papier bedruckt; es gab ein riesiges Materiallager mitPalettenregalplatzen; das Materiallager war klimatisiert, da-mit sich das Papier in den Schnelldruckern spater nicht elek-trostatisch auflud oder verklebte.«

Im Oktober 1973 wurde der TR440-Rechner 4 durchden Rechner 27 ersetzt. Damit standen neben einem Mo-noprozessor nun zwei TR440-Doppelprozessorsysteme imRechenzentrum. Die TR440-Rechner waren teilweise direktgekoppelt, teilweise uber TR86S-Systeme.

1 3


Das Rechenzentrum in der Abteilung Software-Entwick-lung war das damals großte TR440-Rechenzentrum und injeder Hinsicht sehr fortschrittlich. Zwei Beispiele mogendas verdeutlichen:

• Zur Messe CeBIT 1974(?) in Hannover wurde eine Rech-nerkopplung nach Konstanz (ca 600 km) geschaltet undDatenfernverarbeitung demonstriert.

• Es wurde ein grosses, sicheres Datenarchiv realisiert. Einzentraler Teil war ein riesiger Paternoster-Archivschrankfur Magnetbander, der zusammen mit einer einschlagigenFirma fur uns entwickelt wurde. Auf einer Tastaturwurde die Nummer eines Magnetbandes eingegeben,dann kam dieses Magnetband zur Entnahme an. Spaterverkaufte diese Firma solche Schranke auch an andereRechenzentren.

D. Wagner verließ die Computer Gesellschaft Konstanz zum1. Februar 1975. Sein Nachfolger wurde J. Keppler.

17 Projektmanagement und Organisation

Mit dem Aufkommen immer leistungsfahigerer Hardwarestiegen auch die Anspruche an die Software. Diese wurdeimmer umfangreicher und ihre Erstellung erforderte im-mer großere Ressourcen, insbesondere immer großere Ent-wicklungsteams. Viele Software-Projekte scheiterten, an-dere wurden nur mit Terminverschiebungen von vielen Mo-naten und enormen Kostensteigerungen fertiggestellt. Einin [6] zitiertes Beispiel ist das IBM-Betriebssystem OS/360– ein stapelverarbeitendes Mehrprogrammbetriebssystem –aus der zweiten Halfte der 60er-Jahre.

Ende der 60er-Jahre wurden die Probleme bei der Ent-wicklung großer Software-Systeme immer drangender. EineDiskussion und Bestandsaufnahme erfolgte 1968 auf derberuhmten Garmischer Konferenz, bei der auch der Begriff,,Software-Engineering“ gepragt wurde. Die Großrechner-entwicklung von AEG-Telefunken war durch H. Kohler undH.R. Wiehle vertreten.

Die typischen Probleme traten naturgemaß auch beider Software-Entwicklung fur den TR440 auf; es han-delte sich ja um ein sehr großes und in Neuland vorsto-ßendes Software-Projekt. Einige dieser Probleme wurdenin den vorangehenden, technisch orientierten Teilen die-ses Artikels bereits angesprochen. In diesem Abschnittliegt nun der Schwerpunkt der Beschreibung voll auf demProjektmanagement.

Ende der 60er-Jahre war noch nicht bekannt bzw. er-probt, wie große Software-Projekte gefuhrt werden sollten.H.-J. Siegert erinnerte sich (2007):

»Bei der weltweiten Diskussion eines geeigneten Pro-jektmanagements fur Software gab es zwei Lager:

Das erste Lager hielt ein Projektmanagement fur tod-lich fur jedes Projekt. Stattdessen sollten einige wenigehochqualifizierte Personen beauftragt werden, das Pro-dukt zu entwickeln. Sie sollten unbehelligt von Mana-gern bleiben, ohne Vorschriften arbeiten, vollig freieArbeitszeit haben und selbstverstandlich auch nie nachdem Stand des Projektes gefragt werden. Nach ei-nigen Jahren prasentiert dann das Team ein fertigesund hervorragendes Produkt. Diese Meinung wurdedurch die damalige Erfahrung uber erfolgreiche Pro-jekte gestutzt.Das zweite Lager vertrat die Meinung, dass ein Softwa-re-Projektmanagement sinnvoll sei, genau so wie in an-deren Ingenieur-Disziplinen. Hierzu lagen aber keinebelastbaren Erfahrungen vor, auch sprach die Liste dergroßen gescheiterten Software-Projekte eher dagegen.Welche spezifischen Eigenschaften ein Projektmanage-ment fur Software im Gegensatz zum etablierten Pro-jektmanagement in anderen Disziplinen haben sollte,war zudem noch Gegenstand von Forschungen.«

Aufgrund der Situation bei der Entwicklung der TR440-Software war es jedoch fur H.-J. Siegert klar, dass ein Pro-jektmanagement entwickelt und eingefuhrt werden musste,um erfolgreich zu sein. Sobald der enorme Druck auf dieEntwickler nach den ersten Auslieferungen des Teilnehmer-betriebssystems etwas nachgelassen hatte, wurde dieses Zielin Angriff genommen. K. Scheidhauer unterstutzte das Vor-haben aus vollem Herzen, wahrend der unmittelbare Vor-gesetzte, H. Kohler, die berechtigte Frage stellte, ob mansich das jetzt leisten konne. Immerhin stand die Software-Entwicklung noch immer unter starkem Termindruck unddas Vorhaben erforderte erhebliche Personalressourcen.

Es war klar, dass das Projektmanagement nicht ohneHilfe und Erfahrung von außen entwickelt werden konnte. InDeutschland gab es diese nicht, wohl aber in den USA. Dortmussten Software-Firmen, die an das Militar liefern wollten,umfangreiche Methoden, Verfahren und Kontrollen bei derSoftware-Entwicklung einsetzen. Diese waren so aufwendig,dass der dadurch bedingte Overhead bei der Entwicklung vonSoftware nur im militarischen Bereich finanzierbar war. Eine1 : 1-Ubernahme solcher Verfahren in den kommerziellenBereich war also nicht moglich, jedoch hatten einige FirmenAnpassungen fur Software-Entwicklungen im kommerziel-len Bereich vorgenommen. Die Nutzung dieses Wissens waralso fur uns sinnvoll.

K. Scheidhauer stellte im Herbst 1969 den Kontaktzur Firma CSC (Computer Sciences Corporation) in ElSegundo, Kalifornien her. CSC hatte auch ein Buro inDeutschland. Nach technischen Gesprachen und Gesprachenmit potentiellen Mitarbeitern in El Segundo wurden 1970drei Mitarbeiter (Christopher Earnest, Robert E. Trainer,R.W. Walsh jr.) von CSC USA fur mehrere Monate nach

1 3

260 Siegert

Deutschland abgeordnet, um als ,,full time job“ mit uns ge-meinsam ein Software-Projektmanagement zu entwickeln.Weitere Mitarbeite von CSC arbeiteten kurzfristig fur spe-zielle Fragestellungen mit, u.a. Joel Erdwin und SheldonSidrane. Um das Projekt zu steuern, fanden regelmaßigeSitzungen mit den CSC-Mitarbeitern, dem Abteilungsleitervon GR/P und seinen Laborgruppenleitern statt. Dabei wur-den die große Linie, aber auch alle Details (bis auf die Ebeneder Formulierungen) des zukunftigen Projektmanagementsdiskutiert und festgelegt. So entstand ein maßgeschneider-tes Projektmanagement fur die Software-Entwicklung [2].Durch die Einbeziehung aller Mitarbeiter der Software-Entwicklung mit großeren Leitungsaufgaben waren dieKenntnisse uber das Projektmanagement breit gestreut undes konnte eine Akzeptanz ohne große Verwerfungen erreichtwerden. Das Regelwerk fur das Projektmanagement wurdeim Juni 1970 fertiggestellt. Die neuen Verfahren wurden abda Schritt um Schritt eingefuhrt. Sie waren teilweise auchmit organisatorischen Anderungen verbunden. Es gab beiden Rechnerherstellern in Deutschland und wahrscheinlichauch in Europa zu dieser Zeit und auch noch Jahre spaternichts Vergeichbares.

Fur den Erfolg der Software-Entwicklung waren nichtnur die technische Qualitat, sondern auch das Vertrauen derKunden und der Geschaftsleitung essentiell. Hierzu wareninsbesondere die nachfolgenden Merkmale des Projektma-nagements entscheidend.

Merkmal Dokumentation: Die Dokumentation war genauso wie der Entwurf oder die Programmierung ein gleichran-giger Bestandteil der Entwicklung. Neben der technischenBeschreibung enthielt die Dokumentation auch alle anderenprojektbezogenen Aussagen, wie beispielsweise Projektge-nehmigungen oder Qualitats- und Fortschrittsberichte. Dasvorher ubliche Verfahren, das Design nur stichwortartig aufSchmierzetteln oder in den Kopfen zu halten, war nun nichtmehr erlaubt. Die gesamte Projektdokumentation war so ge-kennzeichnet und strukturiert, dass die Projektordner bei al-len gleich sein konnten. Allerdings war der Verteiler bei deneinzelnen Beitragen unterschiedlich. Die Moglichkeit einerzentral gehaltenen, papierlosen Dokumentation im Rech-ner gab es zu dieser Zeit leider noch nicht. Damit warevieles erheblich einfacher und effizienter geworden. H.-J. Siegert erinnert sich, dass er zu Anfang oft von Mit-arbeitern gefragt wurde, ob nun dokumentiert oder ter-mingerecht ausgeliefert werden solle. Leider war die Ant-wort dann fast immer, rechtzeitig zu liefern und spater zudokumentieren.

Merkmal Qualitatssicherung: Die Dokumente, welcheja in jeder Phase der Software-Entwicklung entstanden,waren auch Arbeitsgrundlage fur andere Teams, da sieFestlegungen zu Schnittstellen enthielten. Es war wich-tig, solche Schnittstellen eindeutig zu beschreiben und ge-gen willkurliche Anderungen abzusichern. Analoges galt

fur Programm-Komponenten. Auch diese waren Arbeits-grundlage von anderen, beispielsweise beim Test teilin-tegrierter Komponenten. Die Grundidee war nun nachFertigstellung eines Dokuments fur eine Entwicklungs-phase oder nach Fertigstellung einer Software-Komponentemit vorher definierter Leistung, diese durch die Qua-litatssicherung abzunehmen und danach Anderungen durchden Entwickler nur nach dokumentierten Fehlermeldun-gen oder nach genehmigten Anderungsantragen zuzulas-sen. Die Qualitatssicherung war organisatorisch unabhangigvon den einzelnen Entwicklern. Auch das Durchfuhrenvon Integrations- und Abnahmetests war in der Verant-wortung der Qualitatssicherung. Fur die Qualitatssicherungwurde eine neue Laborgruppe unter der Leitung von KurtMuhlbach aufgebaut.

Merkmal Anderungskontrolle: Anderungen an abgenom-menen Dokumenten oder Software-Komponenten warennur auf Grund von Fehlermeldungen oder nach Geneh-migung eines Anderungswunsches moglich. Zur Entschei-dung traf sich der so genannte Anderungskontrollausschusseinmal in der Woche. Mitglieder waren der Abteilungs-und die Laborgruppenleiter der Software-Entwicklung so-wie Vertreter des Vertriebs und der Systemberatung, wobeiKlaus Auerbach als Leiter der Systemberatung besonde-res Gewicht hatte. Die Anderungsantrage und die Ent-scheidung daruber wurden dokumentiert. Damit wußte je-der genau, welche Anderungswunsche bestanden und wiedaruber entschieden wurde. Sehr wichtig war, dass jederAnderungswunsche stellen konnte. Damit gab es ein trans-parentes Verfahren fur Vertrieb und Kunden, dessen Bedeu-tung nicht uberschatzt werden kann.

Merkmal Fehlermanagement: Die Fehlermeldungen wur-den registriert und ihre Behebung verfolgt. Fehlermel-dungen konnten zu Anderungsantragen fuhren. Da Fehlerauch komponentenspezifisch erfasst wurden, konnten sieauch als Fruhwarnsystem dienen, das zeigte, ob eine Kom-ponente schlecht entworfen und/oder schlecht realisiertwurde.

Merkmal Fortschrittsberichte: Die neuen Fortschrittsbe-richte losten die bisherigen Entwicklungsberichte ab. DerHauptunterschied war, dass bestimmte Aspekte jetzt immerim Bericht vorhanden sein mussten. Einige Aspekte ka-men auch neu hinzu. Beispielsweise waren fur jedes Projektauf jeder Ebene Meilensteine definiert. Die Meilenstein-trendanalyse zeigte grafisch Terminverschiebungen auf. DaMeilensteine inhaltlich ohne die Qualitatssicherung nichtumdefiniert werden konnten, war die Meilensteintrendana-lyse von hochstem erzieherischem Wert. Sie zeigte auchfruhzeitig Probleme auf, so dass das Management gegen-steuern konnte. Ein reales, wenn auch etwas extremes Bei-spiel aus der TR440-Entwicklung zeigt Abb. 5. Anmerkung:Auch eine waagrechte Linie in der Trendanalyse, also keineTerminverschiebung, konnte ein Alarmsignal sein, da der

1 3


Abb. 5 EineMeilensteintrendanalyse

Termin moglicherweise ohne Neuplanung einfach beibehal-ten wurde.

Die Organisation der Software-Entwicklung GR/P mitStand 1.6.1974 zeigt das Organigramm in Tabelle 4. Die Or-ganisation spiegelt die volle Implementierung des Projekt-managements wider. Man erkennt auch eine kleine Matrix-struktur: Es gab einen Projektleiter fur TR440 (J. Feldmann)und einen fur den TR550 (W. Frielinghaus).

Mitte 1974 waren in der Abteilung GR/P rund 300Mitarbeiter [65], davon 62 Mitarbeiter im Rechenzen-trum. Von diesen waren wiederum 30 Operateure. Un-ter den Mitarbeitern waren etwa 217 Programmierer, 9Laborgruppen- bzw. Projektleiter und 13 Sekretarinnen. Vonden 217 Programmierern waren 43 promoviert, 92 hattenein Universitatsdiplom, 33 waren Fachhochschulingenieure,17 hatten ein abgebrochenes naturwissenschaftliches Stu-dium, 32 hatten eine sonstige Ausbildung. Von den Uni-versitatsabsolventen hatten uber 90% eine mathematische,natur- oder ingenieurwissenschaftliche Ausbildung. DasMitarbeitersoll war 313 Personen. Bei dieser Gelegenheitist es wichtig, anzumerken, dass ab etwa 1970/71 die finan-ziellen Probleme von AEG-Telefunken permanent wurden.Dies bedeutete ab diesem Zeitpunkt bis zur Ubernahme

durch die Siemens AG auch einen stetigen Personalabbaumit Entlassungen, wobei neue Planzahlen oft fast monatlichausgegeben wurden. Daneben war naturlich mit der Fertig-stellung der TR440-Software ein Ubergang von Mitarbei-tern von TR440-Projekten zum Nachfolgerechner (TR550)im Gange. Diese Mitarbeiter verblieben aber aufgrund derMatrixstruktur in der alten Laborgruppe. So entwickeltebeispielsweise die Laborgruppe ,,Compiler“ alle Compiler,sowohl fur den TR440 als auch fur den Nachfolger. DieLaborgruppen waren also bewusst technologie- und nichtprojektorientiert.

18 DFG-Abnahmegruppe und STARG

Nach Abschluss des Kaufvertrags fur einen TR440 furdas Deutsche Rechenzentrum (DRZ) wurde im Fruhjahr1967 von der Deutschen Forschungsgemeinschaft (DFG)eine Abnahmegruppe (kurz DFG-Abnahmegruppe) unterder Leitung von Dieter Haupt, Professor und Rechenzen-trumsleiter der RWTH Aachen und Vorsitzender der DFG-Rechnerkommission, gebildet. Mitglieder waren 7 Com-puterspezialisten des Deutschen Rechenzentrums und der

1 3

262 Siegert

RWTH Aachen. Das Ziel der Gruppe war die Mitverfol-gung der Entwicklung des TR440 und die Vorbereitungder Ubernahme durch das DRZ. Jedoch nahm die Gruppebald direkten Einfluss auf die Konzeption und Entwick-lung, insbesondere der Betriebssysteme. Sie spielte so einewichtige Rolle bei der Großrechner-Entwicklung von AEG-Telefunken in Konstanz, insbesondere bei der Software-Entwicklung.

Nachdem die vorangegangenen Kapitel durch die Sichtder Mitarbeiter bei AEG-Telefunken gepragt waren, sollnun dieses Kapitel ganz bewusst eine Sicht von außenwiedergeben. Der Text orientiert sich daher sehr stark andem Entwurf eines internen Berichts von Alexander Giedke[32], der die TR440-Entwicklung aus der Sicht der DFG-Abnahmegruppe beschreibt. Nicht mit Quellangaben verse-hene Zitate stammen aus diesem Entwurf.

»Im Juni 1967 setzte sich die Abnahmegruppe zusammenmit Mitgliedern des Apparateausschusses mit dem von Te-lefunken erarbeiteten Konzept auseinander. Dabei bereitetenbereits die von Telefunken neu gepragten Begriffe, mit de-nen die Eigenschaften und die Funktionen des TR440 be-schrieben wurden, Schwierigkeiten. Beispielsweise blieb derals ,,schlechthin fundamental“ bezeichnete Begriff ,,Prozess“unklar. Da diese neuen Begriffspragungen in den vorhande-nen Unterlagen nicht definiert waren, war es fur jeden einhartes Brot, sich mit dem neuen System vertraut machen zumussen.«

Die Abnahmegruppe sah Probleme beim ,,Overhead“ desBS1 und weitere Schwachen in der Konzeption. »Telefun-ken schatzte 1% Overhead, aber die erste Ausbaustufe desBetriebssystems nahm bereits 35 bis 50 der 128 KWorte desKernspeichers in Beschlag. Problematisch erwies sich auchdie Notwendigkeit der Verdrangung bereits erledigter Pro-gramminhalte aus dem Kernspeicher. . . . Es war nicht mog-lich, eine solche Verdrangung durch Eingriffe eines Opera-teurs zu erreichen; sie musste ,,automatisch“ erfolgen. Dasallerdings war kaum so zu verwirklichen, dass den vielenmoglichen Betriebszustanden angemessen Rechnung getra-gen wurde. Kein Wunder, dass vollig unklar war, wie einsinnvoller Betriebsablauf erreicht werden sollte. . . . Mansuchte zusammen mit Telefunken nach anderen Betriebs-konzepten, bei denen u.a. die Nutzenfunktion durch eineeinfache Steuerung nach Programmprioritaten ersetzt wer-den sollte. . . . Der Speicherbedarf fur das Betriebssystemerschien der Abnahmegruppe so hoch, dass ein Betrieb derAnlage mit Vielfachprogrammierung auch in einem redu-zierten Betriebssystem in Frage gestellt werden musste.«

»Ende 1967/Anfang 1968 konnte zu den vertraglich ver-einbarten Terminen keine Maschinenzeit fur Testrechnun-gen bereitgestellt werden. Verbindliche Unterlagen fehl-ten nach wie vor. Lediglich interne, zum Teil vertraulicheund handschriftlich verfasste Papiere standen der Abnahme-gruppe als Arbeitsunterlagen zur Verfugung.«

»Anfang 1968 war klar, dass das zugesagte System nichtzum 1. Juli 1968 lieferbar war.«

»Das BS1 in einer Vorstufe BS07 sollte bis Ende 1968ausgeliefert werden, war aber Mitte 1968 immer noch nichtfertig und wurde von der Abnahmegruppe nach wie vor ne-gativ beurteilt.«

»Fruhestens nach dem 10. Juli 1968 waren zum erstenMal Zeiten fur Programmtests auf der einzigen TR440-Ma-schine, die auch nach Darmstadt geliefert werden sollte, ver-fugbar. Am 9. Dezember 1968 beginnen die Ubernahmetestsfur das Doppel-TR4-System.«

»Der Entwicklungsstand des BS1 bereitete nach wie vorSorgen. Tests im Herbst 1969 zeigten keineswegs die er-warteten Fortschritte. Die Entwicklung war noch nicht abge-schlossen und ein Abschluss in den nachsten Monaten auchnicht zu erwarten.«

»Es ist kein Wunder, dass die Abkehr vom BS1 viele derBeteiligten uberraschte. War doch auf einer am 31.8.1969veranstalteten Benutzertagung noch nichts von dieser Wendeerkennbar gewesen. . . . Am 7. November 1969 war einHearing (DFG, BMBF, Benutzer, Interessenten) in Kon-stanz zu TR440. Hier gab Telefunken zu erkennen, dassdas BS1 nicht weiter verfolgt worden war. Es erfolgteeine Vorfuhrung des BS3, erste Stufe, Batch, mit2 Abwicklern.«

Die Abnahmegruppe nahm mit Erleichterung die Beendi-gung des BS1 und den Ubergang zu BS3 auf, denn sie warder Auffassung, das BS3 wirklich einsetzen zu konnen:

»Mit dem BS3 lag nun ein endgultiges und prak-tikables SW-Konzept vor. Das Hearing brachte imGrunde die Entscheidung uber die Fortfuhrung desTR440 Projekts. Es wurden Kontrollpunkte fur dieSW-Entwicklung definiert. Diese Checkpoints wurdeninhaltlich und terminlich in der Folgezeit im Wesentli-chen erfullt.«

Wie aus den vorangehenden Ausfuhrungen erschließbar,war die Bedeutung der DFG-Abnahmegruppe also durchfolgende Hauptpunkte gegeben:

• Die Gruppe war sehr viel in Konstanz anwesend undhatte direkten Kontakt mit den Mitarbeitern. Sie war so-mit ein kritischer Gesprachspartner mit Insider-Wissen,der die Entwicklung hinterfragte und kritisierte, aberauch Vorschlage fur die Realisierung machte. Hier-durch mussten die Entwickler ihre Konzepte beschreibenund ,,verteidigen“ sowie schon bei der Konzeption aufmogliche Schwachstellen achten. Dies erforderte zwarvon allen Beteiligten Geduld und zusatzlichen Aufwand,war aber insgesamt doch hilfreich.

• Durch den vorherigen Punkt, aber auch durch das Zu-sammenstellen und Ausfuhren von Abnahmetests war dieGruppe eine Art externe Qualitatssicherung.

1 3


• Die Gruppe reprasentierte die Sicht der damaligen Kun-den und Geldgeber. Sie artikulierte und ubermittelte auchKundenwunsche.

• Die Gruppe hatte eine wichtige Aufgabe bei der Erzeu-gung und Festigung des Kundenvertrauens in die Ent-wicklungen in Konstanz.

A. Giedke [32] fasste zusammen: »Der Erfahrungsgewinnauf dem Software-Gebiet durfte fur Telefunken betrachtlichund wesentlich gewesen sein. Der Weg war allerdingsschmerzhaft, vor allem der Entwicklungsweg der Betriebs-systeme, der in einem langwierigen Reifeprozess von an-wendungsfremden zu praxisnahen Losungen fuhrte. Zwei-fellos hat hier der Erfahrungsaustausch zwischen der Firmaund der Abnahmegruppe der DFG wesentlich zum Erfolgbeigetragen, da die firmenunabhangige Abnahmegruppenicht nur als Kontrollinstanz, sondern auch als kritischerBerater fungierte.«

Neben der Abnahmegruppe der DFG bestand ab 1970auch eine Arbeitsgruppe bei der Ruhr-Universitat Bochumunter der Leitung von Hartmut Ehlich, Professor an derRuhr-Universitat Bochum und Rechenzentrumsleiter. DieseGruppe bereitete die Installation des TR440 in Bochumvor und hatte ebenfalls sehr enge Kontakte zur Software-Entwicklung. Ihr Wirken hat erheblich dazu beigetragen,dass der Rechner in Bochum sehr schnell zufriedenstellendlief [85].

Last but not least ist als externe Gruppe die STARGals Vereinigung der TR440-Benutzer zu nennen. Sie dientebeispielsweise als Koordinationsforum der TR440-Re-chenzentren und TR440-Benutzer, als Sammelstelle furWunsche an die TR440-Software, als ,,Feuerwehr“ beiProblemen und zur Beurteilung von Anderungswunschenaus Benutzersicht. Auf den regelmaßigen Tagungen wurdenauch die umfangreichen und vielfaltigen Eigenentwicklun-gen der STARG-Mitglieder vorgestellt.

19 Die Schlussphase der Großrechnerentwicklung

Fur ein erfolgreiches Großrechnergeschaft mit dem TR440war es unbedingt notwendig, den Kunden auch die Wegein die Zukunft aufzuzeigen. AEG-Telefunken bildete alsobereits 1969/1970 eine Projektgruppe, die sich mit einemNachfolgerechner zum TR440 (Arbeitstitel hier TR550) be-schaftigte. Organisatorisch war dazu eine kleine Matrix-struktur vorgesehen: Die fachliche Verantwortung lag beiden Laborgruppen, also beispielsweise fur alle Betriebs-systeme bei der Laborgruppe Betriebssysteme. Quer dazugab es projektbezogene Koordinationen durch die Projekt-manager fur TR440 und TR550 in der Hardware- und inder Software-Abteilung, sowie durch Bildung von ad-hoc-Arbeitsgruppen fur ein bestimmtes Thema.

Es wurden verschiedene Vorgehensweisen untersuchtund teilweise auch langere Zeit verfolgt. Parallel dazufanden Kooperationsgesprache mit anderen europaischenund außereuropaischen Rechnerherstellern statt. Genaue-res hierzu in dem Artikel zum Unternehmen [44]. Hin-tergrund dieser Gesprache war einerseits die Erkenntnis,dass aus Kapitalmangel die Großrechnerentwicklung vonAEG-Telefunken allein wohl keine Zukunft haben konnte,und andererseits das Drangen der damaligen Bundesregie-rung zu kooperieren, moglichst mit einem europaischenPartner.

Am 18.7.1974 wurden die Großrechner-Entwicklung inKonstanz und die Belegleser-Aktivitaten bei AEG-Tele-funken von Siemens als Tochterfirma ,,Computer Gesell-schaft Konstanz“ (CGK) ubernommen. Vor der Ubernahmewurde das Personal auf eine von Siemens gewunschteAnzahl reduziert. Aufgrund des Engagements von Sie-mens bei UNIDATA war fur die Großrechnerentwick-lung bei CGK kein Platz mehr. Folgerichtig wurden alleArbeiten an einem TR440-Nachfolgesystem eingestellt.Die Software-Entwicklung reduzierte sich auf die un-bedingt notwendige Pflege, um die verkauften TR440-Systeme moglichst lange beim Kunden halten und nochvorhandene Restbestande verkaufen zu konnen. Uberhauptkam dieser Zusammenschluss nur auf Druck der dama-ligen Bundesregierung zustande und die Firma Siemensselbst hatte weder ein Interesse daran [40], noch warsie darauf vorbereitet, noch wusste das zustandige Mana-gement, was es mit den Software-Entwicklern anfangensollte.

Gesprache uber zukunftige Beschaftigungen fur die Soft-ware-Entwickler fanden auf allen Ebenen statt, insbesonderauch auf Abteilungs-, Laborgruppen- und Laborebene. DieSoftware-Entwicklungsgruppen bei Siemens in Munchenwaren jedoch nicht bereit, großere Entwicklungspakete ab-zugeben. Ob die technische Uberlegenheit der Konstan-zer Entwicklung dabei zusatzlich hinderlich war, ist nichtbekannt.Konsequenzen waren:

• Viele Mitarbeiter der Software-Entwicklung verließendie CGK, u.a. Anfang 1975 H.-J. Siegert, der einenRuf auf ein Informatik-Ordinariat an der TU Munchenannahm. Sein Nachfolger wurde W. Frielinghaus. Die-ser wechselte spater in eine leitende Position zu Sie-mens nach Munchen. Sein Nachfolger in der Leitung derSoftware-Entwicklung wurde dann K. Auerbach.

• Etwa neunzig Software-Entwickler wurden einzeln oderin kleinen Gruppen zu Software-Labors bei Siemensin Munchen abgeordnet. Sie fuhren mit einem Busam Wochenanfang von Konstanz nach Munchen (da-mals noch 4 bis 5 Stunden Fahrt) und am Wochenendezuruck. Zu nennen sind hier u.a. J. Feldmann, H. Meiß-

1 3

264 Siegert

ner und E. Schmolz. Diese Mitarbeiter dienten sich beiSiemens wieder hoch und kamen vielfach in leitendePositionen.

• In Konstanz verblieb eine kleine Gruppe von Software-Entwicklern. Diese kummerten sich um die Pflege derTR440-Software und fuhrten Auftragsentwicklungen furSiemens durch, insbesondere in den Bereichen Daten-fernverarbeitung und Migrationshilfen fur den Ubergangvom TR440 auf das Siemens-Produktspektrum. Der Pro-duktschwerpunkt in Konstanz wurden aber die großenBeleglesemaschinen.

Die Siemens AG hat es also nicht verstanden, die hohe,in Konstanz konzentrierte Software-Kompetenz optimal zunutzen. Fur Deutschland jedoch hatte das bei der TR440-Software-Entwicklung angesammelte Wissen und die Wei-tergabe in Universitaten, Fachhochschulen und Industrie furden Aufbau der Informatik große Bedeutung. So steht be-reits im Schlussbericht der Telefunken-Computer GmbH zurForderung der TR440-Entwicklung im Rahmen des 2. DV-Programms der Bundesregierung [75]: »Fur das TR440 Pro-jekt standen anfangs nur wenige erfahrene Mitarbeiter zurVerfugung. Dies lag vor allem daran, dass der Entwick-lungszweig EDV, insbesondere in Europa, noch sehr jungwar, und dass es damals so gut wie keine Ausbildung aufdem Gebiet der Informatik gab.« und weiter: »Neben die-sem primaren Ergebnis der Aufgabenstellung, dem Groß-rechensystem TNS 440, war als indirektes Ergebnis dastechnische und wissenschaftliche Wissen zu nennen, dasauf dem komplexen Gebiet der elektronischen Datenverar-beitung und des Managements großer Projekte erworbenwurde. Dieses Wissen war uber intensiv betriebene Ausbil-dung weitergegeben worden.«

Danksagung Mein besonderer Dank geht an Christopher Earnest,Manfred Evers, Joachim Feldmann, Wolfgang Frielinghaus, Wolf-gang Froehlich, Alexander Giedke, Fritz-Rudolf Guntsch, Heinz-GerdHegering, Gisela Hoffmann, Eike Jessen, Jurgen Keppler, Dieter Mi-chel, Albert Noltemeier, Gerd Sapper, Kurt Scheidhauer, EberhardSchmolz, Gerhard Seegmuller, Franz Stetter, Gunther Stiege, HanniStolze, Heinz Voigt, Dietrich Wagner, Hans-Rudiger Wiehle. Sie ha-ben mir in unterschiedlichster Weise beim Schreiben dieses Artikelsgeholfen, angefangen von der Bereitstellung von Unterlagen bis zumintensiven Korrekturlesen von Teilen. Außerdem wurde ich mit An-ekdoten und vielen wichtigen Hinweisen versorgt. H.R. Wiehle hatsehr genau die Ausfuhrungen zum TR4-Betriebssystem und zum BS1gelesen und wir hatten einige Stunden intensiver und interessanterDiskussionen. Dafur ein herzliches Dankeschon.

Ein herzliches Dankeschon geht auch an die Herren WolfgangFußl and Hartmut Petzold vom Deutschen Museum Munchen furihr starkes Interesse, TR440-Dokumente der Fachwelt zuganglichzu machen. Die Bibliothek des Deutschen Museums hat TR440-Dokumente, die ich hatte oder bekam, ubernommen; darunter viele,die in diesem Artikel zitiert werden. Zu nennen ist hier insbesonderedie umfangreiche Schriftensammlung des Leibniz-Rechenzentrumsin Munchen (LRZ), deren Ubergabe an das Deutsche Museumdurch H.-G. Hegering und A. Lapple ermoglicht und unterstutztwurde.

Eine große Freude fur mich war es, dass uber diese Arbeit nach sovielen Jahren wieder Kontakte zu fruheren Kollegen und Mitarbeiternentstanden.

Literatur

1. AEG-Telefunken (1968) Bedienungshandbuch Doppel-TR4-System auf TR440 – Amulator-Erlauterungen und Verteilerpro-gramm. AEG-Telefunken, Beschreibung Nr. N3/GR 70, Septem-ber 1968

2. AEG-Telefunken (1970) Software Development Project File(Software Projektmanagement). Internes Dokument, 23. Juni1970

3. AEG-Telefunken (1970) TR440 Betriebssystem BS2 (erste Aus-baustufe) – Einfuhrung. Schrift DBS182/0470

4. AEG-Telefunken (1970) Unterlagensammlung TR440 Betriebs-system-Kern. Interne Schrift N31.B1.11, Juli 1970

5. Bellec J (2006) Information Technology Industry Time Line.http://perso.orange.fr/jeanbellec/information_technology_1.htmbis ...information_technology_5.htm

6. Campbell-Kelly M, Aspray W (1996) Computer: A History of theInformation Machine. Basic Books

7. Coffman EG jr, Denning PJ (1973) Operating Systems Theory.Prentice-Hall

8. Computer Gesellschaft Konstanz (1975) Die Kopplung vonFremdsystemen an das Rechensystem TR440 uber KOMSYS.Best.Nr. 440.B9.07, Ausgabe 0975, September 1975

9. Computer Gesellschaft Konstanz (1975) Teilnehmer-Rechensys-tem Kurzbeschreibung. Best.Nr. 440.B0.04, Ausgabe 0375, Marz1975

10. Computer Gesellschaft Konstanz (1976) Zeugnis fur WolfgangFrielinghaus

11. Computer Woche (1976) Computer Gesellschaft Konstanz:Siemens-vertraglich. Computer Woche 16

12. Computer Woche (1977) TR 445 DP und Cyber 7276 im Ver-bund – Großrechnerkoppelung zwischen Universitaten. ComputerWoche 17

13. Computer Woche (1978) Software-Subventionen noch ansteigendMDT 1978 auf dem Bonner Fordergipfel. Computer Woche 5

14. Computer Woche (1982) Umstellungshilfe mit BMFT-Forderung– Ausmusterung der TR440 erleichtert. Computer Woche 11

15. Computer Woche (1986) DV-Oldies: Antiquitat oder leistungsge-rechtes System. Computer Woche 35

16. Computer Woche (1987) Nixdorf zwischen MDT und IBM Einedeutsche Erfolgsstory – vom Einmannbetrieb zum internationalenSuper-Systemhaus (Teil 2). Computer Woche 46

17. Denning PJ (1968) The Working Set Model for Program Behav-ior. Commun ACM 11(5):323–333

18. Denning PJ (1970) Virtual Memory. ACM Comput Surv2(3):153–190

19. Denning PJ (1971) Third Generation Computer Systems. ACMComput Surv 3(4):175–216

20. Dennis JB (1964) A Multiuser Computation Facility for Educa-tion and Research. Commun ACM 7(9)

21. Dennis JB, Van Horn EC (1966) Programming Semantics forMultiprogrammed Computations. Commun ACM 9(3):143–155

22. Dijkstra EW (1968) The Structure of the THE-MultiprogrammingSystem. Commun ACM 11(5):341–346

23. Engelhardt R, Evers M, Schallenmuller B, Stetter F (1975) Rech-nerverbund beim TR440. Elektron Rechenanl 17(1)

24. Engelhardt R, Huber J, Luhmann S (1972) Datenhaltung imTeilnehmer-Betriebssystem TNS 440. Telefunken Computer,Beitrage 11

25. Evers M (1972) Datenfernverarbeitung im Teilnehmersystem desTR440. Telefunken Computer, Vortrag, Best. Nr. N31.B9.01

1 3


26. Evers M, Hoheisel W (1970) Das Satellitensystem des Telefunken-Rechensystems TR440. Datenverarbeitung 3, Beihefte der Tech-nischen Mitteilungen AEG-Telefunken Berlin, S 122–124

27. Ferranti (1962) Die Atlas Rechenanlage. Ferranti Ltd.; Falt-blatt No. 1 in einer Reihe von Skizzen unserer Rechenanlagen-systeme

28. Fischer H, Namneck P, Stolze L (1979) Datensicherheit auf Groß-rechnern. Elektron Rechenanl 21(6)

29. Forster H, Gruber H, Klawitter G, Thurner H (1972) Planung undVerwaltung von Betriebsmitteln im Teilnehmer-BetriebssystemTNS 440. Telefunken Computer, Beitrage 9

30. Fotheringham J (1961) Dynamic storage allocation in the ATLAScomputer, including an automatic use of a backing store. Com-mun ACM 4(10):435–436

31. Gebhardt B (1973) Interaktives Arbeiten am Terminal. Telefun-ken Computer, Beitrage 10

32. Giedke A (1974) Die Entwicklung des TR440. unveroffentlichterEntwurf

33. Goos G, Jurgens J, Lagally K (1972) The Operating System BSMViewed as a Community of Parallel Processes. Technischer Be-richt 7208, Technische Universitat Munchen, Fak. Mathematik

34. Hoare CAR (1971) Towards a Theory of Parallel Programming.In: International Seminar on Operating Systems Techniques.Belfast

35. Hoare CAR (1974) Monitors: An Operating System StructuringConcept. Commun ACM 17(10):549–557

36. Hoffmann G (1969) Das Doppel-TR4-System. Vortrag, hand-schriftlich, unveroffentlicht

37. IBM (2001) IBM Highlights, 1885–1969. IBM Dokument1406HA02, December 2001

38. Jager P (2006) Peter Jager, zur Person. http://www.jaegers-home.de/person.htm

39. Jammel A, Stiegler H (1977) Managers versus Monitors. In:Gilrichst B (Hrsg.) Information Processing 77. North-Holland,S 827–830

40. Janisch H (1988) 30 Jahre Siemens-Datenverarbeitung – Ge-schichte des Bereichs Datenverarbeitung 1954–1984. SiemensAG, Munchen

41. Jessen E (1964) Stellungnahme zum EntwicklungsvorhabenTR400. AEG-Telefunken, interner Brief uber Herrn Guntsch anHerrn Peltz u.a., 4 Nov 1964

42. Jessen E (1968) Das Betriebssystem des Rechners TR440. In:Handler W (Hrsg) Teilnehmer-Rechensysteme. Oldenbourg Ver-lag, S 114–123

43. Jessen E (1971) Das TR440-Großrechensystem an deutschenHochschulen. AEG-Telefunken, Presseinformation, 11. Novem-ber 1971

44. Jessen E, Michel D, Siegert H-J, Voigt H (2008) AEG-TelefunkenTR 440: Unternehmensstrategie, Markterfolg und Nachfolger. In-formatik Forsch Entw 22(4)

45. Jessen E, Michel D, Voigt H (2008) AEG-Telefunken TR 440:Struktur und Technologie. Informatik Forsch Entw 22(4)

46. Jessen E, Ulbrich E (1968) TR440 als Teilnehmersystem. In: Da-tenverarbeitung mit Mehrfachzugriffssystemen. Haus der Tech-nik, Essen

47. Kilburn T et al. (1962) One-level storage system. IRE TransEC11(2):223–235

48. Krainer H (1972) Testmoglichkeiten im Teilnehmer-Rechensys-tem TR440. Telefunken Computer, Beitrage 10

49. Lagally K (1975) Das Projekt Betriebssystem BSM. TechnischerBericht 7509, Technische Universitat Munchen, Institut fur Infor-matik

50. Morrison JE (1973) User Program Performance in Virtual StorageSystems. IBM Syst J 12(3):216–237

51. Namneck P, Siegert H-J, Wiehle HR (1968) TR440 Grund-programme 1 – Einfuhrung. AEG-Telefunken, Großrechner,Oktober

52. Niesporek H (1972) Die AEG-TELEFUNKEN Datenverarbei-tungsanlage TR440. http://members.dokom.net/w.kloke/tr440.txt

53. O’Reilly (2004) History of Programming Languages.http://www.oreilly.com/pub/a/oreilly/news/languageposter_0504.html

54. Piper J, Meißner H, Stetter F, Heinz M (1970) Das Teilnehmer-Betriebssystem BS3. Datenverarbeitung 3, Beihefte der Techni-schen Mitteilungen AEG-Telefunken Berlin, S 115–122

55. Pszolla H, Eberhardt F (1972) BCPL, eine Sprache zumSchreiben von Compilern. Beitrage 1, Telefunken ComputerKonstanz

56. Radius K (1968) Probleme der Entwicklung von Großrechenan-lagen. Vortrag vom 3. Juli 1968 bei der Arbeitsgemeinschaft furForschung des Landes NRW, AEG-Telefunken DVO 060. Okto-ber 1968

57. Ritchie DM, Thompson KL (1974) The Unix Timesharing Sys-tem. Commun ACM 17(7):365–375

58. Rosen S (1969) Electronic Computers: A Historical Survey. ACMComput Surv 1(1):7–36

59. Rosin RF (1969) Supervisory and Monitor Systems. ACM Com-put Surv 1(1):37–54

60. Sapper GR (2004) Telefunken TR4.http://www.qsl.net/dj4kw/index.htm

61. Schilling J (2004) Digitalrechner-Geschichte: TR4 – Ein paar Ge-danken zur Rechner-Historie in Deutschland.http://www.dj1xk.de/tr4.htm oder http://www.pc-profiler.ch/geschichte.htm

62. Schmidt E, Linn N, Schwald A, Krainer H (1970) Zum Pro-grammiersystem des Telefunken-Rechensystems TR440. Daten-verarbeitung 3, Beihefte der Technischen Mitteilungen AEG-Telefunken Berlin, S 124–131

63. Seegmuller G (1962) Some Remarks on the Computer asa Source Language Machine. In: Proceedings IFIP Congress 62,North-Holland, S 524–525

64. Siegert H-J (1973) Rechnerverbundnetz. Telefunken Computer,Software Entwicklungsdokumente, 29. Juni 1973

65. Siegert H-J (1974) Stand der Software-Entwicklungen – Vor-tragsnotizen zu Kooperationsgesprachen mit der Siemens AG.TC-internes Dokument, 30. Juli 1974

66. Stadie G (1970) Der TR440 mit zwei Rechnerkernen und Mas-senkernspeicher. Datenverarbeitung 3, Beihefte der TechnischenMitteilungen AEG-Telefunken Berlin, S 132–133

67. Stiege G (1970) Zum Betriebssystem BS2. Datenverarbeitung 3,Beihefte der Technischen Mitteilungen AEG-Telefunken Berlin,S 112–115

68. Strunk P (2002) Die AEG – Aufstieg und Niedergang einer In-dustrielegende. Nicolaische Verlagsbuchhandlung Berlin, Berlin(Sonderausgabe)

69. Sudkurier (1973) Telefunken Computer und Unidata nahern sichan. Sudkurier, 12. Dezember 1973

70. Sydow F von (1970) Die TR-440-Staffel – vom mittleren Rechen-system bis zum dialogfahigen Teilnehmer-Rechensystem. Daten-verarbeitung 3, Beihefte der Technischen Mitteilungen AEG-Telefunken Berlin, S 101–104

71. Telefunken Computer (1972) Beispiele zur problemorientier-ten Software des Teilnehmer-Rechensystems TR440. Beitrage 7,440.ZZ.50.07, Dezember 1972

72. Telefunken Computer (1972) Programmiersystem – Einfuhrung.VS1, Best.Nr. N31.B0.02

73. Telefunken Computer (1972) Telefunken Computer – Logik setztsich durch. Firmenprospekt

74. Telefunken Computer (1972) Time-Sharing Computing-System –Introduction. VS1, Best.Nr. N31.B0.04 E

75. Telefunken Computer (1973) Vielfachzugriffssystem TR440,Schlußbericht. II. Datenverarbeitungsprogramm der Bundesregie-rung, Teilprogramm 4, Dezember 1973

1 3

266 Siegert

76. Telefunken Computer (1974) Leistungserweiterung des TR440-Systems durch MV8 bis MV16. Interner Brief von VS33, 19.September 1974

77. Thiele E (Hrgs.) (2003) Telefunken nach 100 Jahren – Das Erbeeiner deutschen Weltmarke 2 Aufl. Nicolaische Verlagsbuchhand-lung Berlin, Berlin

78. Ulbrich E (1963) Struktur und Arbeitsweise der Telefunken-Digitalrechenanlage TR4. IEEE Trans Electronic Comput

79. Voltz H (1970) Anwendungssysteme fur den TR440. Daten-verarbeitung 3, Beihefte der Technischen Mitteilungen AEG-Telefunken Berlin, S 136–140

80. Wiehle HR (1967) Vortrage der Grundprogrammentwicklung(E44) fur den Vertrieb uber die Grundprogrammierung desTR440. Telefunken, interne Mitschrift

81. Wiehle HR (2006) Operating Systems at AEG-Telefunken. Pio-neering Software in the 1960s in Germany, The Netherlands, andBelgium; Amsterdam. To be published

82. Wiehle HR (2008) Rechnerbetrieb aus Benutzersicht: Auf demWeg zu den großen dialogfahigen Timesharing-Systemen. Infor-matik Forsch Entw 22(4)

83. Wiehle HR, Seegmuller G, Urich W, Peischl F (1964) Ein Be-triebssystem fur schnelle Rechenautomaten. Elektron Rechenanl6(3):119–125

84. Wulf W et al. (2002) Curriculum Vitae Prof. Dr.-Ing. Fritz-RudolfGuntsch. Medieninformation Nr. 8, Pressestelle TU Berlin

85. Zoller H (2002) RUB trauert um Professor Hartmut Ehlich.http://www.ruhr-uni-bochum.de/pressemitteilungen-2001/msg00402.html

1 3

aeg-telefunken tr 440: software und software-entwicklung

Documents