Zur Kooperation zwischen dem

NIZEWT (UdSSR) und Robotron (DDR) bei der Entwicklung der ESER- Betriebssysteme

- ein historischer und technologischer Rückblick [1]

Artikel zum 3. Symposium IDDR

Abstract: Nach einem Rückblick auf den Wirtschaftsfaktor „ESER-EDVA“ wird ein außerordentliches Software- Entwicklungsprojekt beschrieben – die zweiseitige Entwicklung aller Hauptspeicher- residenten Betriebssysteme des ESER zwischen NIZEWT und Robotron. Ausgehend von Fakten zur strategischen Rolle der ESER- Systemfamilie in der Informatik des RGW-Wirtschaftsraumes werden die Hauptinhalte der Entwicklungsarbeit bei ESER- Betriebssystemen skizziert, dabei auch eine Übersicht zu den Produkt- Äquivalenten der ESER- und IBM- Betriebssysteme gegeben, sowie Hauptelemente der SW- Entwicklungs-Technologie und die gängige Projekttechnologie bei der Kooperation umrissen.

Nachfolgend erfolgen Kurz-Betrachtungen zu Aspekten des EDVA- Systemüberganges nach 1990 in den neuen Bundesländern und in der UdSSR/Russland unter Nutzung des „System Know-hows“ der Entwickler für „Professional IT- Services“, die von der hohen Kompetenz der ESER- Entwickler zeugen.

1.    Einleitende Bemerkungen

• Zum Autor des Beitrages :

o 1981 bis 1990 Direktor des ESER- Entwicklungszentrums Karl-Marx-Stadt (Fachgebiet Geräte „E2“), dessen Vorgänger bereits 1957 als „VEB Elektronische Rechenmaschinen Karl Marx-Stadt“  (ELREMA) gegründet wurde.

o 1980 bis 1990 „Chefkonstrukteur der DDR im  ESER“. Im Rahmen der Arbeit des „Rates der Chefkonstrukteure“ der MRK Rechentechnik auch international für die DDR – Belange dieser Erzeugnislinie verantwortlich.

o 1990 bis 1991 Vorstand „Entwicklung und Technologie“ der ASCOTA-AG, u.a. weiter verantwortlich für die Geschäftsbereiche des Entwicklungszentrums.

o 1992 bis 2007 tätig im Projektgeschäft von „Siemens Business Services..“ in Osteuropa

• In verschiedenen Vorträgen vorangegangener DDR-Informatik- Symposien wurden Informationen zu den ESER- EDVA der DDR vordergründig im nationalen Umfeld dargestellt. Ohne die Betrachtung und Bewertung der Beziehungen UdSSR- DDR sind aber viele innere Aspekte und historische Zusammenhänge der DDR Geschichte „rund um die Rechentechnik“ nicht schlüssig darstellbar.

• Das ESER- System war wohl das erfolgreichste internationale Projekt der wissen-schaftlich- technischen Zusammenarbeit im RGW. Es liegt daher nahe, dieses Projekt in seiner Spezifik und Komplexität gesondert, detaillierter und in den vielfältigen Zusammenhängen der Beziehungen zur UdSSR und den dort abgelaufenen Prozessen umfassend zu betrachten (siehe[2].). Im Rahmen des aktuellen Symposiums bietet es sich an, die Geschichte der Schaffung der ESER- Betriebssysteme als relativ selbständigen Teil davon zu betrachten.

• Der Vortrag konzentriert sich auf die ESER- Mainframe-Linie. Auch die ESER- PC (bis EC 1835 ) begannen ihren erfolgreichen, aber kurzen Weg bei „E2“ in Chemnitz. Bei Softwareentwicklung bestehen aber hier keine berichtenswerten Besonderheiten, besonders nicht zur UdSSR- Kooperation.

1.1.        Zum Wirtschaftfaktor ESER- EDVA

Einleitend soll hier zunächst kurz der enge Zusammenhang der DDR-Arbeiten an der ESER- Mainframe- (EDVA)-Linie und der Arbeiten an den ESER- Betriebssystemen umrissen werden:

• Die Produktlinie ESER- EDVA war wichtigstes Spezialisierungsobjekt der DDR- Rechnerindustrie im RGW und ein Geschäft mit hohen Gewinnmargen. ROBOTRON entwickelte 5 Mainframe- Modelle in den Architektur-Niveaus ESER- Reihe I bis Reihe III und produzierte 1587 Stck. ESER-EDVA[3] bzw. –Zentraleinheiten, die zum überwiegenden Teil exportiert wurden. (siehe #TabelleEDVA) Das war von der Zahl etwa 10% des Gesamtaufkommens der MRK- Staaten bei Zentraleinheiten, der Performance- Anteil lag deutlich höher.

• ROBOTRON leistete für die Entwicklung der ESER- Betriebssysteme über 40% der eingesetzten Manpower[4], insgesamt wurden ca. 6.000 Mannjahre Leistungen erbracht  und ca. 6 Mio. "Lines of code“ (ESER- Programmbefehle) incl. Dokumentation  erarbeitet. Ihre Finanzierung erfolgte als Umlage auf den Geräte- Preis.

• Zwischen der hohen technischen Qualität und absoluten(!) Systemkompatibilität der DDR- Produkte mit den ESER- Operationsprinzipien einerseits und dem Entwicklungsanteil der DDR an den ESER- Betriebssystemen andererseits bestand eine totale wechselseitige Abhängigkeit: ohne Betriebssystementwicklung keine Hardware-Systemkompatibilität und ohne System-Kompatibilität (und höchster Qualität) kein Export -Erfolg. Nur die Einheit der Arbeiten an der Hardware der Zentraleinheiten und den Betriebssystemen sicherte der DDR ihre profitable Position und der UdSSR einen unverzichtbaren Entwicklungs-Partner und Lieferanten eines wichtigen Teiles ihres EDVA- Parks.  

• alle DDR-Anwendungen von ESER- EDVA auf OS-ES Niveau (1989 ca. 350 Anlagen) wurden mit DDR- Betriebssystemen betrieben. Alle rund 1300 DDR-Exportanlagen wurden an den Anwender mit einem ESER- Betriebssystem ausgeliefert[5], das zwischen UdSSR und DDR auf Vertragsbasis entwickelt wurde.

1.2.  Das historische Umfeld –

Abbildung : Zeitrahmen der ESER- Kooperation und Epochen der Staatsmacht

Zunächst ein kurzer historischer Rückblick zum damaligen „strategischen Umfeld“:

• 1957 wurde in der DDR zwecks Konzentration der Kräfte im IT/DV- Sektor der DDR der wissenschaftliche Industriebetrieb „ELREMA“ gegründet.

• Nach der Kuba-Krise 1962 lebten die Länder des RGW im tiefsten Winter des kalten Krieges und des Handelsembargos. Im RGW ging es um schnellstmögliche Verringerung des Technologie- und Anwendungs- Rückstandes der IT/DV gegenüber den westlichen Staaten.

• In der UdSSR waren mehrere bedeutende Architektur- Schulen und Entwicklungs- Institute in einem höchst uneffektiven, inkompatiblen Parallelismus verfangen. Das Niveau der Anwendungs- Software war besorgniserregend. In der Plankommission, AdW und einigen Ministerien der UdSSR wurde intensiv nach Vereinheitlichung der DV-Architektur und deren Betriebssoftware gesucht.

• Anfang der 60ger änderte sich in der UdSSR auch das Klima in Wissenschaft und Technik und die allgegenwärtigen Traumata der Folgen des Stalinismus vernarbten langsam. Im mittleren Management der IT- Bereiche kam eine neue Generation Spezialisten zum Einsatz, eine kompetente internationale Zusammenarbeit begann.

• In der DDR wurde nach dem System „Robotron 300“ (analog IBM/1400) verstärkt am Konzept „Robotron 400“ (analog IBM/360) gearbeitet. Einige wenige sowjetische Kollegen kannten diese Arbeiten. 

• 1968: Die UdSSR- Regierung entscheidet über die Nutzung von IBM/360 als ESER-Vorbildsystem im Lande. Das „Vorbild“ („Analog“, „Prototyp“) war eine zukunftssichere, mit hoher Autorität behaftete Architektur, die als quasi- Industriestandard (Amdahl, CDC, Siemens, Fujitsu...) außerdem eine Fülle von Anwendungs- Lösungen  und Peripherie verfügbar machte[6]. Diese Entscheidung bewährte sich 20 Jahre.

• das Abkommen zur Mehrseitigen Regierungskommission Rechentechnik (MRK) sammelte (Dezember 1968) auch die Kräfte der IT- Branche der europäischen sozialistischen Länder unter einem Dach. Diese Bündelung auf eine Architektur überwand auch im RGW das sich anbahnende Architektur- Chaos.

• Sowohl die Amtszeit Chruschtschows, als auch die DDR-Zentrale unter W. Ulbricht (bis 1971) [7], gaben einen starken Impulse zum Anstieg der IT/DV- Investitionen und verwandter Basistechnologien. Dieser Start vermittelte dem ESER bis Mitte der 80-ger Jahre im volkswirtschaftlichen Rahmen ausreichende Impulse für eine gute bis zufriedenstellende Unterstützung bei der Schaffung neuer Technologieplattformen und der breiten Einführung der EDVA. Das erforderliche Technologieniveau war zur damaligen Zeit noch relativ niedrig (SSI, MSI –Schaltkreise, MLLP, Maschinentakt mit HS-Zyklus 1,35 µs), der technologische Abstand zum Prototyp betrug nur wenige Jahre.

• Bereits die ersten Entwicklungs-Ergebnisse unterstrichen die erfolgreiche praktische Umsetzbarkeit der /360-System-Entscheidungen. Die DDR brachte 1973/74 mit EC 1040 das zunächst längere Zeit leistungsfähigste Serien- Modell auf den Markt. In der UdSSR lief die stabile Serienproduktion mehrerer Modelle an. Das ESER erlebte in im Verlaufe eines Jahrzehnt- dann schon mit /370- vergleichsweise eine Blütezeit.   

• Ab ca. 1984/85 verstärkten sich die Entwicklungs-Schwierigkeiten in der UdSSR und DDR infolge der Auswirkungen verfehlter Wirtschafts- und Sozialpolitik und der enormen Belastungen aus dem Wettrüsten massiv! In beiden Ländern waren die politische Führung und das wirtschaftliche Umfeld nicht mehr in der Lage, die nötige Unterstützung im Technologie- und Investitionsbereich aller Zweige der Wirtschaft zum Erhalt eines minimalen Tempos zu finanzieren und Kooperationen zu organisieren.

• Trotz der in der zweiten Hälfte der 80ger Jahre zunehmenden politischen Differenzen zwischen den Reform- Plänen (!) der UdSSR- Führung und dem Konservatismus der DDR-Oberen, und trotz der bekannten DDR-Aktivitäten zur„32-Bit-Architektur“, blieb das wirtschaftliche Gewicht der ESER- EDVA in den Beziehungen UdSSR-DDR auf hohem Niveau erhalten. DDR- Qualität, nachhaltige „ESER- Systempolitik“ und das massive Beharrungsvermögen des "UdSSR-Hochsee-Liners ESER- EDVA"(ca. 10.000 EDVA im Einsatz)  trugen weiterhin Früchte.

Unter den umrissenen Rahmenbedingungen realisierten viele leistungsfähige Teams in Forschung , Entwicklung und Produktion Außerordentliches!

Wichtigstes letztlich tragendes Ergebniss zum ESER-Ende 1990 waren

• eine Vielzahl von TOP- Fachleuten im Mainframe- und PC- Bereich und

• ein hervorragend vorbereiteter EDVA -Markt!

2.       Historischer und technologischer Rückblick auf ein außerordentliches Software- Entwicklungsprojekt

2.1.  Zur ESER- Architektur und dem Betriebssystemkonzept

CISC- Rechner (Complex Instruction Set Computer) waren bis weit in die 80ger Jahre wegen der technischen Realisierungsbedingungen international typisch. Die Befehlsstruktur musste wegen extremer Bit- Kosten speicheroptimal sein, eine starke technische Modularität mit Parallelabläufen war für Großrechner zwingend und komplexe Maschinenbefehle benötigten hohen Logik- und Technikaufwand.

Die IBM/360 - Architektur war sowohl im Ankündigungsjahr 1964 als auch zum Start- Zeitpunkt der ESER- Arbeiten 1968 eine höchst innovative und weitreichende „360 Grad“- Universal-Konzeption und für die Belange der geplanten „REIHE“ des ESER ein ideales System-Design. Sie zeichnete sich durch folgende Haupt-Aspekte aus [8],:

• Orientierung auf Geschäftsdatenverarbeitung, Vorbereitung auf Dialog- Datenverarbeitung und Fernverarbeitung.

• Implementierung umfangreicher neuer Möglichkeiten der Systemorganisation, wie max. unabhängige E/A – und Peripherie-Subsysteme

• leistungsfähige Speicherverwaltung unterschiedlichster Speichermedien in mehreren Hierarchie- Ebenen; „Großer“ Adressraum , anfangs begrenzt auf 24 Bit (16 M Byte)

• universelle Logikstruktur für verschiedene Programmarten, Betriebsmodi bzw. Steuer-programm- Konfigurationen durch ein leistungsfähiges Interruptsystem, Speicherschutz- Mechanismen, geschützte Supervisor- Programm- Verwaltung u.a.,

• 6 Befehlsklassen mit einem sehr breiten Spektrum von leistungsfähigen und flexiblen Befehls- und Datenformaten , Einsatz von 32 Bit- Universalregistern mit 24 Bit Adressfeld.

• erstmalige Einführung des 8-Bit Byte und der 32-Bit Word- Struktur (incl. 32- oder 64-Bit Gleitkommaworte) mit hexadezimaler Basis.

Abbildung Befehlsformate IBM/  360/370 und Abstract der legendären Ankündigung der /360-"Architecture"

Die echte Auf- und Abwärtskompatibilität auf Bit- Niveau der Maschinensprache, hinweg über eine Familie von 6 Modellen und einer Performance- Spanne Faktor 50 (!) war eine Sensation. Allein das machte das /360-Konzept zum idealen ESER-Prototyp (Vorbild). Seine Entwicklung zum weltweiten Industriestandard gab auch den RGW- Ländern in der EDV-Politik Sicherheit und Kontinuität und sorgte für einen weitgehend einheitlichen Mainframe-Markt incl. Peripherie.

Der Grundsatz der gesamten ESER- Arbeiten bestand in einer „Prototyp“- nahen Systementwicklung. Als technische und technologische Herausforderung stand im ESER vorrangig die Implementierung des Systemkonzeptes und der Operations-Prinzipien der IBM/360 bzw. /370 Architektur durch einem eigenen Logikentwurf und deren technischer Realisierung mit RGW- Schaltkreisen/Material gemäß dem UdSSR- Standard GOST 25122-82 „Basiskonstruktionen der technischer Mittel des ESER (TM ESER)“.

Zu einigen Aspekten der Architektur der Betriebssysteme:

• Wesentliche Schlüsseltechniken heutiger Betriebssysteme wurden durch die  IBM / ESER- Betriebssystemkonzepte erstmalig realisiert.

• Die Komplexität der IBM/ESER-  Betriebssysteme bildet sich, was deren Architektur betrifft, in einem Schichtenmodell ab. Eine bestimmte Schicht ist jeweils zuständig für die Verwaltung einer Betriebsmittel-Klasse, sie benutzt andere Schichten (Aufrufe) und ordnet sich in eine funktionale Hierarchie ein (siehe Abbildung).

• Die universellen Eigenschaften der Logikstruktur - ausgebautes Interruptsystem, leistungsfähige hardware- basierte Schutzmechanismen und Sicherheits-Features, indizierte Adressierung mit virtueller Adressverwaltung zwischen logischer und physischer Adresse-  ermöglichten über ca. 20 Jahre die permanente Erweiterung der Betriebsmodi und Programmfunktionalität, Nutzung moderner Speicher, Entwicklung von Fernverarbeitungs- und Dialogsystemen, Mehrprozessorkomplexen  u.a..

• Es war wichtig, sowohl die Stapelverarbeitung von Programmen, als auch den Betrieb vieler Nutzer durch „Teilnehmerbetrieb“ und Time sharing der Ressourcen effektiv zu gestalten. Umfangreiche Fernverarbeitungssysteme, wie etwa Bildschirmsysteme (EC 7920) mit lokalen und fernaufgestellten Steuereinheiten und vielen (unintelligenten) Terminals und auch alle „Stapel- Tasks“ nutzten gemeinsam alle Ressourcen der zentralen EDVA.

• Die Zuverlässigkeit der Datenverarbeitung (Sicherung der Verfügbarkeit  und Schutz vor Datenverlust) und die Informationssicherheit (Schutz vor unbefugtem Zugriff oder Angriffen) spielten eine außerordentliche Rolle. Die IBM/ ESER- Architektur und Software war gängigen Kleinrechnersystemen stark überlegen.

2.2.  Hauptinhalte der Zusammenarbeit UdSSR-DDR bei ESER-Betriebssystemen [9]

DDR- Softwarespezialisten hatten bereits im Vorfeld der Gründung der MRK gegenüber UdSSR- Fachleuten die Eigenschaften der /360- Architektur überzeugend darstellen können. Ab Gründung der MRK (12/1968) erfolgten alle ESER- Betriebssystem- Arbeiten in der DDR in enger Zusammenarbeit mit der UdSSR, ab ca.1973 dann arbeitsteilig auf kommerzieller Basis mittels paritätischer Lizenzverträge. Ein einheitliches Betriebssystem war die Voraussetzung der geplanten DDR-Exporte in die UdSSR und für die UdSSR ergab sich die dringende Lösung ihres Manpower- Problems.

Zunächst zum Inhalt:

Unter Federführung zweiseitiger Spezialistengruppen UdSSR/ DDR wurden Konzeptionen (Systemkonzepte) für einzelne Entwicklungsetappen der Betriebssysteme des ESER- Systems (ESER I, ESER II, ESER III) erarbeitet, deren Inhalte wurden durch den zuständigen mehrseitigen Spezialistenrat №1 bzw. dessen ständige Arbeitsgruppe OC- EC „Operationssysteme“ (später “Sektion“) des RCK ESER beschlossen und in den internationalen „Entwicklungsplan“ (ESER- Chiffre) aufgenommen. Entwickler der Operationssysteme[10] waren die UdSSR /DDR.

  Den Arbeitsinhalt der einzelnen Entwicklungsabschnitte der Betriebssysteme bestimmten:

• die relevanten ESER- Operationsprinzipien gem. /360 oder /370 ( Reihe I bis Reihe III ) ,

• die aktuellen Software- Produkte des Vorbildes, bezogen auf analoges Funktions- und Technikniveau

• die nationalen Interessen der UdSSR und DDR, abgeleitet von den  technischen Parametern ihrer Hauptmodelle und den Forderungen der   Haupt-Anwender.

Die nachfolgende Tabelle (TabelleEDVA) zeigt aus DDR- Sicht die Komplexität der langjährigen Entwicklung der ESER- Operationsprinzipien und der Dynamik der Betriebssystem- Entwicklung. Relevant dafür war neben den Operationsprinzipien der aktuellen „REIHE“ die Entwicklung der Hauptspeicherkapazität, speziell der DDR- und UdSSR- Modelle, sowie der Plattenspeicher- Technologie und DFV- Komplexe.

Mit den technologischen Entwicklungen ergaben sich Möglichkeiten und Erfordernisse, immer leistungsfähigere Steuerprogramm-Konfigurationen zu unterstützen und umfangreiche weitere Softwarekomponenten (Datenfernverarbeitung, Teilnehmerbetrieb, Sprachen und Compiler, Dienst- und Serviceprogramme u.a. ) bereitzustellen.

Tabelle „Grobübersicht ESER-EDVA der DDR“
Modell	Befehlszahl	HS-Ausbau	Haupt-Betriebssysteme
EC 1040 1974-1980	143 Befehle (ESER I)	1 MByte (256KByte pro Schrank)	DOS EC ; OC- EC/MFT, OC- EC/MVT
EC 1055 1979-1984	173 Befehle (ESER II) + 2 Emulationsbefehle+ 37 MaMo- Befehle	2 MByte  (1MByte/ Schrank)	OC-6.1. (SVS) /EC
EC 1055M 1983-1986	182 Befehle (ESER II- erweitert ) (37 MaMo- Befehle)	4 MByte (max.2 Schränke )	OC-6.1.(SVS) /EC SVM /EC
EC 1056 1985-1989	182 Befehle (ESER II-erweitert) + interne SVM Mikroprogramm- Makros	4 MByte (max. 1 Schrank)	OC- 7.1./EC mit SVS 7.1./EC,SVM 3.0./EC BPS 7.1./EC
EC 1057 Auch als Doppel-prozessor-Model 1989-1990	203 Befehle (ESER III);	16 MByte (mit Coprozessor/ 2 Schränken)	OC -7.2. EC mit SVS- 7.2./ EC, SVM- 3.5 /EC, BPS 7.2./EC MVS.2(SP)/EC (ab 1989)

Deutlich war diese Entwicklung am Beispiel der Zahl der im Multiprogrammbetrieb verwalteten Tasks (MFT oder MVT) durch Nutzung der virtuellen Adressverwaltung und der Aufgabensteuerung ( Job/Task- Control) zu beobachten, sowie später der Zahl der durch eine Steuerprogrammkonfiguration verwalteten virtuellen Adressräume, d.h. SVS (Single Virtual Storage) oder im ESER sehr viel später die aufwendige MVS – (Multiple Virtual Storage)- Verwaltung mehrerer virtueller Adressräume.

Eine besondere Bedeutung erlangte in den 80ger Jahren auch das Konzept der virtuellen Maschine (SVM). Die Spezifik des SVM bestand in der Weiterentwicklung der Virtualisierung einzelner Mittel des Rechners (Hauptspeicher, Peripheriegeräte...) hin zur Virtualisierung einer ganzen EDVA. SVM gestattete die Einrichtung und Verwaltung von mehreren virtuellen Maschinen und die parallele und völlig unabhängige Arbeit mehrerer Nutzer auf einer Anlage. Der autorisierte Nutzer musste dafür jeweils ein ESER-Betriebssystem oder ein system-unabhängiges Dienstprogramm nutzen. Insbesondere im Entwicklungsbetrieb durch mehrere Test- und Diagnosesysteme oder bei der Arbeit mit stark vertraulichen Inhalten verschiedener Nutzer ergab sich eine hohe Informations-Sicherheit. Ab dem OC 7.1./EC wurden in der UdSSR- DDR- Kooperation mehrere SVM- bezogene Teilsysteme bearbeitet, die Systeme BPS 7.1./EC.und SVM 3. /EC im SVS 7.1./EC. Obwohl SVS und BPS vorrangig für den Stapelbetrieb konzipiert waren, arbeitete das sowjetische „Basisbetriebssystem“ BPS ausschließlich unter einer virtuellen Maschine.

Beginnend mit OC 7 /EC (1983) war eine gewisse Trennung der Produktpolitik zwischen der UdSSR- Linie des OC 7 und in den DDR-Kunden-Versionen nicht vermeidbar[11]. Die UdSSR- Partner erarbeiteten eine Originalstruktur des OC 7.1. /EC ohne ausländisches Vorbild. Auf der UdSSR- Seite begann eine teilweise Abwendung von IBM- Vorbild- Lösungen. Die in der DDR zur Auslieferung gekommenen Systeme OC 7.1/ EC und nachfolgend OC 7.2./ EC sind in den entsprechenden Artikeln der DDR-Entwickler genau beschrieben.[12] Spezifische Eigenschaften, die das SVM bietet (hochgradige Nutzertrennung, Informationsschutz u.a. für wichtige Großanwender in der UdSSR) waren dominant dafür, dass das OC 7.2./EC spezifisch strukturiert wurde. Bei der breiten Masse der DDR- Anwender blieben die IBM- nahen Konzepten weiterhin favorisiert und Robotron machte Kundenberatung für OC 7.2./EC mit SVM.

Die zunehmende SVM-Dominanz in der Systempolitik des NIZEWT und im Hauptexportland UdSSR war auch der Hauptgrund der Ausstattung der EC 1056 mit einem leistungsfähigen mikroprogrammresidenten Satz von SVM- Makros, die die SVM- Performance bis zu 50% erhöhen konnten.

2.3.  Aufgabenstellung und Technologie der ESER- Kooperation und des Projektmanagement

Die ESER- Betriebssystem- Arbeiten in der DDR nach Gründung der MRK (12/1968) erfolgten, wie bereits ausgeführt, arbeitsteilig mit der UdSSR auf kommerzieller Basis mittels zweiseitiger Lizenzverträge. Das jährliche vertragliche Volumen betrug im Höhepunkt der Arbeiten ca. 600 Mannjahre, jede Seite erbrachte strikt 50% der Leistung  und übergab diese dem Partner als Lizenz. Die Finanzierung war also ein 0- Summen- Clearing, beide Seiten wurden Eigentümer des Gesamtsystems.  

Die Methodik der inhaltlichen Definition der Entwicklungsabschnitte basierte auf einer ausführlichen Analyse entsprechender Unterlagen zur Strategie der IBM und anderen IBM- Publikationen. Da die ESER- Entwicklung mit ca. 4 Jahren Versatz zum Vorbildsystem startete und im Verlaufe der Arbeiten etwa 8 Jahre Abstand hinnehmen musste, bestand die Erarbeitung der „Aufgabenstellung“ für die nächste Etappe des ESER- Betriebssystems vorrangig in der sorgfältigen Analyse der Produktpolitik und  von Publikationen der „Prototyp- Firma“. Es wurden auch deren Original- Produkte analysiert bzw. ausgewertet, denn sowohl die UdSSR, als auch die DDR konnten für bestimmte Unternehmen (z.B. für die Zentralverwaltung für Statistik oder das Kombinat Datenverarbeitung) auch gemäß Exportbestimmungen der USA- Regierung  Original- EDVA  importieren[13]. Die Auswertung der mitgelieferten Unterlagen war dann auch unseren ESER- Spezialisten möglich. Auch aktuelle Maschinenzeit für Testarbeiten für ESER- Betriebssysteme stand so zur Verfügung.

Ziel der Arbeiten war die Entwicklung vertriebsfähiger ESER- Betriebssysteme gemäß dem damals international gültigen Stand des Software- Urheberrechtsschutzes. Die Prototyp- nahe Systementwicklung erforderte keine umfangreichen eigenen konzeptionellen und systemtechnischen Vorlaufarbeiten in der mehrseitigen oder zweiseitigen Kooperation, wohl aber gute Systemkenntnisse und umfangreiche „handwerkliche Arbeit“. Schließlich mussten die Anwender sich darauf verlassen können, dass sie kurzfristig zu jeglichen Funktionsabweichungen eine Lösung erhielten (batches, Umgehungslösungen,.) sowie längerfristig das Problem grundsätzlich behoben wurde (Ausgaben, Versionen) .  

Am Start der Kooperation wurden die Prinzipien der Entwicklungstechnologie definiert und später laufend ergänzt. Folgende Haupt-Elemente waren relevant:

• Erstellung eines Ausgangssystems *)

• Erarbeitung des Quellcodes des Ausgangssystems (für vertiefte Analysen)

• Definition aller Moduln und ihrer Schnittstellen (Makronamen, Aufrufe, andere Software- Schlüssel-Elemente)

• Grundsätze der Anpassung der Moduln an die ESER- Forderungen: Analyse und Änderung von Befehlsfolgen nach fixierten Kriterien, Anpassung der Programmlogik bei Erhalt der Makros, Calls usw., ESER- Kommentare, Anpassung an das E/A- Gerätespektrum, Erarbeitung von Dokumentation u.a.. Makros, Aufrufe und andere Schnittstellen behielten Original-Namen;

• Methodik der Zusammenstellung von Zwischenständen und Integrationstests

• Methodik der Fehlerbehandlung und des Entwicklungsabschlusses des jeweiligen Vertragsteiles**)

• Fehlerdienst und Nachbetreuung

  • *) Das Vorbildmaterial waren kompilierte ,d.h. kundenkonkrete ablauffähige Programmsysteme. Zur Gewinnung des Quellcode der Ausgangssysteme war jeweils eine programmunterstützte Re-Assemblierung erforderlich, die durch dialogorientierte Bearbeitung des Prototyp- Produktes erfolgte. Das war eine Schlüsseltechnologie, ohne deren Existenz am Start der Zusammenarbeit das ESER wahrscheinlich so nicht bestehen würde  [14]

  • die Entwicklung eines vertriebsfähigen ESER-Betriebssystems (BS) implizierte die Sicherheit des Lieferanten, dem Anwender eine vertretbare Zusicherung geben zu können, dass durch  „Fremdcode“ oder die Existenz von Registriernummern oder Kennzeichnungen ( etwa  Vorstufen heutiger Trojaner oder Systemnummern ) kein Informationsabfluss vorbereitet wird oder andere Sicherheitsaspekte berührt werden.

  • die Bereitstellung eines vertriebsfähigen BS implizierte auch die Sicherheit des Lieferanten, dem Anwender  im Falle einer Funktionsabweichung Support zu leisten, angemessener Zeit und in einem adäquatem Maße nach Bedeutung des Ereignisses;

  • **) Das ESER- Betriebssystem musste zum Original kompatibel sein und wurde daher zunächst auf Prototyp- EDVA getestet und korrigiert. Funktionsabweichungen derart getesteter Systeme auf einer ESER- EDVA zeigten mit höchster Wahrscheinlichkeit dann auf Logikfehler des Entwurfs der ESER-ZE.

Zu Beginn einer neuen Entwicklungsetappe erfolgte die genaue Auswahl eines Prototyp- Produktes, dessen Einzelkomponenten (d.h. einzelne Funktionsbereiche wurden ggfls. zeitlich vertagt) und die Definition des Rahmenzeitplanes der Entwicklung bestimmter Teilsysteme, sowie der Arbeitsteilung. Es wurde sowohl arbeitsteilig nach Funktionsmoduln gearbeitet, aber später auch Versions- bezogen. Daher bestand keine durchgängige Spezialisierung der Seiten auf bestimmte typische Moduln, jedoch mehr Flexibilität in der operativen Arbeit.

UdSSR- und DDR- Beauftragte und die Softwareteams beider Seiten erarbeiteten zur Vorbereitung des nachfolgenden Vertragsabschnittes detaillierte Aufgabenstellungen mit Funktions-Beschreibung einzelner Moduln, Terminen, Schnittstellen und Zwischenetappen. In späteren Jahren wurden so auch vom Prototyp abweichende  Systemkonzeptionen (z.B. BPS der UdSSR) erarbeitet und vertraglich vereinbart.

2.4.  Zum Projektmanagement und Arbeitsklima

Die Entwicklungsarbeiten wurden, gemäß heutiger Terminologie, durch ein paritätisch besetztes Projektboard („Entwicklungsleiter“) mit 3-4 Meetings im Jahr geführt. Für einzelne Themengebiete bestanden Teilprojekte mit Teilprojektleitungen, deren Verantwortliche i.d.R. jeweils die Leiter ganzer Bereiche, Abteilungen oder Gruppen waren. Diese verantworteten die Entwicklungsarbeiten ihrer Seite und berichteten im Vertragsrahmen an das Projektboard. Vertrags- Abschlüsse oder Grundsatzfragen zum Vertrag wurden auf Ebene der Direktoren der Betriebe (NIZEWT/ Robotron-E2) geregelt. Differenzen auf Ebene der Direktoren bestanden sehr selten.

Während der jahrelangen fruchtbaren Kooperation entstanden viele persönliche Kontakte. Kameradschaftliches Miteinander und gegenseitige Unterstützung waren die Regel. Es gab nicht wenige persönliche Freundschaften zwischen den Mitarbeitern. Trotz bestimmter Regelungen der Sicherheitsdoktrin der UdSSR entstanden zu keiner Zeit Spannungen, „persönlich“ und „dienstlich“ waren zwei paar Stiefel. Die übergroße Mehrzahl der DDR- Mitarbeiter war froh und motiviert, in einem derartigen Team zu arbeiten.

Ein Detail: Übergaben der Zwischenstände/ Endergebnisse erfolgten auf ½ Zoll Magnetband–Cartridge, später auch auf 14“ Plattenstapeln. Das war in der grenzüberschreitenden Kooperation der einzig praktikable Weg für die umfangreichen Softwarekomponenten und Systeme, die oftmals mehrere MByte groß waren. Anfangs wurden aus Vertragsgründen zusätzlich noch Papierausdrucke übergeben. Dafür mussten ganze Zugabteile mit Papier beladen werden. Der technische Aufwand derartiger Übergaben, aber auch die Einschränkungen in der Kommunikation mit dem Partner sind heute nicht mehr vorstellbar. Auch nicht die KGB Restriktionen. Anfang der 80ger Jahre wurden Sonder- Genehmigungen für online- Verbindungen erteilt. Bei der Kooperation Robotron/ NIZEWT wurden erstmals im UdSSR- DDR- Datenverkehr 1,2 Kbit/s Wahlleitungen/Modems eingesetzt, die teilweise nächtelang in Betrieb waren. Eine spürbare Erleichterung vor allem der operativen Kommunikation trat ein.

3.       ESER- und IBM  Produkt-Äquivalente der Hauptbetriebssysteme

Dieser Aspekt der Kooperation kann im Rahmen dieses Vortrages wohl am besten durch die Graphik „Grobübersicht ESER-OS und Prototyp- Bezüge“ umrissen werden. Details im Bereich SVM siehe auch [15] .

Zur Frage, in welcher Weise seitens der ESER- Software-Entwickler „nach“- gedacht wurde, sind oben bereits Ausführungen erfolgt. HIer noch einige ergänzende Fakten. In einem heute typischen Software- Projekt- Ablauf sind i.d.R. die folgenden Stufen zu durchlaufen

Gemäß der fixierten ESER- Entwicklungstechnologie wurden alle Programmier- und Dokumentationsarbeiten etwa ab der Stufe „Feinentwurf“ in hohem Maße eigenständig erbracht, mit definiertem eigenem Code-Anteil, mittels eigener ESER- EDVA und eigener technologischer Software. Eine abweichende Entwicklungs- Technologie wurde ab ca. 1987 bei den MVS- Arbeiten mit / 370  Architektur eingeführt. Sie betraf vor allem den Grad des Eigenanteiles an Code. 

Das erfolgreiche Projektmanagement nutzte Managementsysteme (Projektplanung u.a.), die heute üblichen Verfahren sehr ähnlich waren. Infolge der heute primitiv zu nennenden Kommunikations- und technischen Bedingungen (z.B. kaum Telefonate, „Textverarbeitung“ mit EDVA u.a.) des Zusammenwirkens über Grenzen war die Leitung (V.: Leonid Raikow/ Walter Münch) eine besonders anspruchsvolle  Leistung. Der Abstimmungs- und Integrationsaufwand zwischen den Entwicklungspartnern war nur durch strikte Disziplin, Einhaltung der technologischen Vorgaben und hohe Kompetenz beherrschbar.

Der „Programm-Start“ ab dem „Feinentwurf“ erforderte hohen Aufwand zur Einarbeitung in die Logikwelt des Prototyp-Produktes plus Aufwand zur Anpassung an eigene Gerätekomplexe und deren Unterstützung und Diagnose, wie E/A- Geräte, Displaysysteme, Fernverarbeitungsgeräte, Mehrrechner-Kopplungen u.a.. Alle diese Aspekte, sowie der Erhalt der Fähigkeit, im Falle der Notwendigkeit die ESER-Entwicklung vollständig eigenständig weiterführen zu können , erforderten  eine vollständige inhaltliche Beherrschung des Produktes . Diese Notwendigkeit ergab sich auch für den Fehlerfall (!) beim Anwender.

Zusammenfassend ist festzustellen, dass die Prototyp-Orientierung überhaupt erst die praktizierte Form der ESER- Arbeitsteilung ermöglichte. Sie erhöhte die Sicherheit von Systementscheidungen und logischen Teillösungen außerordentlich und senkte den Konzeptions- und Entwicklungsaufwand stark. Richtig ist aber auch, dass der für eine wirtschaftlich und technologisch stabile Entwicklung der Produktlinie erforderliche und auch erreichte Grad der unbedingten logischen Beherrschung aller Programm- Elemente (incl. Bearbeitung von Funktionsabweichungen, Fehlern und Umgehungslösungen) einen hohen personellen Aufwand erforderten und durch ein großes Team von ESER- Entwicklern bei E2 zweifellos gut beherrscht wurde.

4.      Systemübergänge 1990 in Ostdeutschland und Russland/GUS

Die politischen und damit einhergehenden wirtschaftlichen „Paradigmenwechsel“ des Gesellschaftssystems vollzogen sich in Ostdeutschland und in der ehem. Sowjetunion etwa zur gleichen Zeit, aber wie bekannt unter extrem unterschiedlichen Rahmen-Bedingungen. In beiden Ländern waren 1990 die ESER- EDVA die dominierende Basis der Informations- und Datenverarbeitung in Behörden und Verwaltung, Finanzwirtschaft, Verkehr und allen anderen lebenswichtigen Bereichen des Landes. In der DDR waren 1990 ca. 350 EDVA Anlagen im Einsatz. In der UdSSR waren im Jahre 1990 noch ca. 10.000 ESER- EDVA im Einsatz.

Die mit dem Wechsel verbundene Erneuerung der Informations- und Datenverarbeitung war in Ostdeutschland dominiert von einer Eingliederung in das bestehende Wirtschafts-, Verwaltungs- und Rechtssystem der BRD in extrem kurzen Übergangsphasen. In der UdSSR erfolgte der „Wechsel“ bekanntermaßen in einem mehrjährigen Prozess bei offenen Landes-Grenzen und freier Valutawirtschaft und einem widersprüchlichen nationalen Kräfteringen.

4.1.        Wenige Aspekte des DV- Systemüberganges in den neuen Bundesländern

Neuinvestment oder Austausch von ESER- EDVA war dank der IBM- Kompatibilität des ESER beinahe ein Selbstläufer. IBM oder Siemens (Siemens trotz nicht kompatibler Plattensektoren) „erhielten“ in den Regionen Ostdeutschlands jeweils ihren Marktanteil für Ersatzinvestitionen im Regierungs- und Verwaltungssektor, sowie bei Banken. Jeder Leiter brachte „sein System“ mit. Der Wandel bei privaten Unternehmen bestimmte sich vielfach durch wirtschaftlichere Client-Server- Systeme mit INTEL- bzw. IBM/PC-Architektur. Diese neuen Mainframe- und PC- Architekturen waren den zahlreichen guten IT/DV-Fachleuten der neuen Länder aus ihrer DDR-Tätigkeit bestens bekannt,

Die beiden bereits genannten Key- Player des deutschen IT/DV – Marktes engagierten sich in den neuen Ländern in deutlich unterschiedlicher Weise.

 Siemens praktizierte die Übernahme von Kennern des Ostmarktes und baute damit Vertriebsstrukturen auf. Und es erfolgte eine Verlagerung von IT-Auslaufprodukten nach Ostdeutschland, eine Art Arbeitsbeschaffung und Vorstufe des aktuellen Produktions- Outsourcings.

IBM Deutschland orientierte neben dem zielstrebigen Aufbau eines Vertriebsnetzes (ausschließlich für die BRD!) bereits auf den Aufbau ihrer „Professional IT-Services“ und verfolgte zielstrebig die Einbindung der besten Robotron- Systementwickler in diese Strukturen. Durch Gründung der „IT Solutions and Services GmbH“ (zunächst als Joint Venture, später als 100%-ge Tochter, heute „ITSAS“) fanden 1990 zunächst 220 der erfahrensten ESER- Entwickler in Chemnitz eine Perspektive. Weitere IBM-Aktivitäten erfolgten bei Robotron Vertrieb Berlin und Leipzig. Heute hat die ITSAS- GmbH[16]  10 Standorte in der BRD und ca. 1200 Mitarbeiter. Im „Global Services Verbund“ der IBM leisten die relativ wenigen noch aktiven ehemaligen Mitarbeiter hochwertige IT-Beratung und –Umsetzung.

Die konsequente Orientierung des Teams von E2 auf die ESER- Architektur erfährt so in Chemnitz eine nachhaltige erfolgreiche Weiterführung der professionellen Tätigkeit vieler Menschen.. Auch vielen anderen Firmen in Sachsen, Thüringen und Brandenburg half das gute ESER- Know –How ihrer Gründer und Mitarbeiter in der Startphase.

4.2.        Kurz zum Systemübergang nach 1990  in Russland

Mit dem Zerfall der UdSSR mussten ESER- Produktion und -Services 1990/91 eingestellt werden. Wartung und Modernisierung der Maschinen (neue Plattensysteme!)  wurden extrem schwierig. Bis 1999 blieben dennoch ca. 5000 ESER- EDVA vorrangig deshalb im Einsatz, weil deren Anwender-Programmsysteme lebenswichtig waren.

In den neugegründeten „MBO“- Firmen „Restart“ und „EC-Leasing“ realisierten NIZEWT- Mitarbeiter „Professional Services“, die äußerst schnelle Migration der Anwender- Software der ESER- Nutzer auf modernere IBM- Plattformen , ohne großen Aufwand, kompatibel ist kompatibel! Ein größerer Teil der Mitarbeiter des NIZEWT ist auch heute noch mit „IT Solutions und Services“ für die große Zahl der ehemaligen ESER-Anwender im Staats- und Regierungsapparat und in Staatsbetrieben tätig, die bis heute als IBM-Anwender (!) vertrauliche Anwendungssysteme, Daten-Netze und Hochleistungsrechner-Komplexe nutzen. Diese wurden teilweise selbst entwickelt und werden mit höchster Kompetenz und Vertraulichkeit im IT-Service betreut, wie auch Rechnerkomplexe und Spezialsysteme -Derivate aus den ESER- Betriebssystemen.

5.      Résumé

• Das ESER war integriert in das Feld der Systemkonfrontation zwischen Ost und West.

• Unter den umrissenen Rahmenbedingungen der ESER- Jahre realisierten viele leistungsfähige Teams in Forschung und Entwicklung in der DDR und UdSSR Außerordentliches! Das ESER erlebte ca. ab 1975 bis 1985 eine Blütezeit.

• Es ist uns nicht bekannt, dass die Firma IBM nach 1990 juristische Schritte zu Schutzrechtsfragen eingeleitet hätte, weder in Russland, noch in Ostdeutschland. Es gab dazu offenbar weder Interesse, noch existierte eine Rechts- Basis.  

• Das „System-Wissen“ und die Arbeitsmethoden der ESER- Entwickler und Service- Spezialisten waren 1990 durchaus vergleichbar mit Teams aus der BRD.

• Es ist höchst erfreulich, dass auf der Basis von exzellentem Wissen, hervorragendem Können aus der Praxis und hoher Motivation viele mit dem ESER aufgewachsene ehemalige Kollegen noch heute einen stabilen Arbeitsplatz ausfüllen bzw. bis zu ihrer Pensionierung keine Arbeitsplatzsorgen hatten, viele davon als selbständige Unternehmer oder leitende Mitarbeiter größerer Firmen. Das gibt mir auch eine nachträgliche Bestätigung der umfangreichen Aktivitäten und des hohen persönlichen Einsatzes zum Erhalt der ESER- Mainframe- Linie bis 1990 in Chemnitz.