OS/ EC Betriebssysteme  für EDVA des ESER

Gliederung

OS/ EC Betriebssysteme

Grundsätzliche Bemerkungen

Relationen zwischen Geräten (Prozessoren - und Modelltechnik) und dem Betriebssystem OS/ES

Einige Merkmale der Betriebssysteme OS/ES

Einige Bemerkungen zu den unterschiedlichen OS/ES-Betriebssystemen:

Anmerkung zu DOS/ES-Betriebssystemen

 

Grundsätzliche Bemerkungen

Neben der technologischen Qualität der Hardware-Entwicklung und -Produktion war die Qualität und Leistungsfähigkeit der OS-ES (auf russisch "OC-EC")- Betriebssysteme, an denen die DDR Seite ca. 50% Entwicklungsanteil bestritt, das entscheidende Kriterium des Erfolges der EDVA- Haupterzeugnislinie. Die Entwicklungspolitik bei Betriebssystemen für ESER- EDVA, beginnend bei ELREMA mit R 300 /R 400 und weiterführend bis 1990 bei E 2 mit dem Konzept der EC 1150 war von folgenden Grundsätzen geprägt:

  • Das Software- Entwicklungsprodukt hat eine 100% begleitende Rolle für die bei Robotron produzierte und vertriebene Technik zu spielen. Funktionalitäten der Gerätetechnik mussten mit schutzrechtsfreien SW- Produkten nutzbar sein;
  • ESER- Anlagen und Betriebssysteme sind typische Multiprogramm-Stapelverarbeitungs-Maschinen, sie haben höchsten Sicherheitsanforderungen und Qualitätsmaßstäben zu genügen!
  • Anforderungen an das Echtzeitverhalten besitzen im Kern des Systems einen niedrigeren Stellenwert; Besonderheiten an online- Qualitäten werden auf der nachfolgenden Prozessorebene ( z.B. DFV- Prozessoren ) abgedeckt; die starke Strukturierung der Hardware sorgt für Selbständigkeit vieler zeitkritischer Prozesse , wie Plattensteuerung usw.
  • Die Rolle der ESER- EDVA als Haupterzeugnislinie im Export in die UdSSR , aber ebenso in die anderen RGW- Länder ( vorrangig CSSR, UVR, VRP) muss von einem kompetenten und professionell anerkannten Entwicklungsbeitrag in der Betriebssystem- Produktnomenklatur des ESER abgesichert werden
  • ESER- Betriebssysteme der DDR sind Gegenstand enger zweiseitiger Kooperation mit dem Hauptentwickler und Hauptbedarfsträger UdSSR .
  • Die Operationsprinzipien des Prototyps sind kompromisslos zu implementieren, wichtige Schnittstellen zur Software- Anwendungslösung (wie Formate, Makros, E/A- Rufe,  u.a. ) sind davon besonders betroffen; die im RGW praktizierten Schutzrechts- und Lizenzregelungen für Betriebssysteme und analoge SW- Produkte sind ohne Abstriche einzuhalten. Dokumentation und Distributions- Datenträger sind frei von Schutzrechten Dritter
 ESER- Betriebssysteme der DDR sind auf Referenzanlagen des VEB Maschinelles Rechnen u.a. bzgl. Ablauffähigkeit zu testen. In Umsetzung dieser Grundsätze war im FG Geräte E 2 ( nachfolgend WTZ /BWK ) ein sehr leistungsfähiges Team von Betriebssystem- Spezialisten mit einem Mitarbeiterpotential von ca. 120-140 E2- Mitarbeitern tätig. Für die außerordentliche langjährige Kompetenz stehen Namen wie Walter Münch, Karl-Heinz Männel, Sylvia Lampenscherf, Achim Schröder, Klaus Menschel, Bernd Wetzel, Klaus Heinecke, Hans Mitschke  und viele andere. Weiterhin war ein leistungsfähiges Team im ehem. FG E 4 des ZFT Dresden in Kooperation mit E 2 auf bestimmte Komponenten der Betriebssysteme spezialisiert,  vorrangig im Bereich der Programmiersprachen und der DFV- Zugriffsmethoden. Die inhaltliche Verantwortung oblag hier viele Jahre solchen Spezialisten wie Dieter Müller, Dietmar Schier u.a. E 2  vertrat während der gesamten Arbeit der MRK RT
  • die ESER- Betriebssysteme in einschlägigen mehrseitigen Spezialistenräten bzw. später Spezialisten- Sektionen des RCK ESER und- 
  •  war VERTRAGSPARTNER des NIZEWT /UdSSR für paritätische kommerzielle Entwicklungen.
 
         
Zum VERTRAGSPARTNER  NIZEWT

In einer langjährigen sehr produktiven und wirtschaftlich vorteilhaften Vertrags-Entwicklung zu allen (in der UdSSR nicht geheimen ) OS-( d.h. Hauptspeicher-) orientierten Betriebssystemen des ESER mit dem Team des NIZEWT Moskau und der NIZEWT-Außenstelle des Rechnerwerkes Minsk (anfangs auch zum DOC- EC)  wurden wesentliche Ergebnisse erzielt. Das jährlich vereinbarte Vertragsvolumen betrug in den 80er Jahren jeweils ca. 140 Mannjahre, Verträge waren annähernd paritätisch strukturiert.

Die Partnerschaft begann Ende 1968/Anfang 1969 mit speziellen Konsultationen auf Ebene der verantwortlichen Software- Manager von ELREMA- und dem NIZEWT -Verantwortlichen Prof. Schura- Bura. Nachdem dessen Vorgänger Ramejew eine IBM- Analog-Orientierung als ESER- Architektur klar ablehnte und selbst Diskussionen darüber sehr destruktive verliefen, konnten die DDR- Spezialisten ihren Gast Prof. Schura- Bura schnell durch praktische Vorführungen, damals in Berlin, von der Möglichkeit eines Re-Assembly überzeugen. Das war der Durchbruch und der ideologische Start einer langjährigen fruchtbaren Zusammenarbeit .

Die partnerschaftliche Entwicklungstechnologie war nach Anlauf-Problemen äußerst effektiv abgestimmt und kann aus heutiger Sicht als ein exzellentes Beispiel einer modernen Projektorganisation im Softwarebereich (mit vielen Out-sourcing-typi­schem Inhalten) gelten. Grundlage der inhaltlichen Konzepte bildeten die bekannten Strategien und Produkte der Prototyp- Firma, sodass sich die Zusammenarbeit nur zum kleineren Teil  mit aufwendiger konzeptioneller Arbeit befasste. Die DDR war auf diesem Wege auch bestens zu Anwendungs-Tendenzen des ESER in der UdSSR informiert und konnte rechtzeitig mit bestimmten Funktionen der Betriebssysteme reagieren. Die weitgehend reibungslose Organisation einer solch umfangreichen Zusammenarbeit ist aus aktueller Sicht beachtlich. Heute existieren schnelle Datenleitungen, FTPS- Server , effektive Sicherheitsmechanismen auf DFV- Leitungen usw. In den 70er und 80er Jahren nutzten die Spezialisten vorrangig den Dokumentenaustausch auf Druckerausdrucken und etwas später den  Datenträgertransport mit ½ Zoll Cartridges. Dabei mussten Robotron- Spezialisten diese "Transporte" als Kurier durchführen, wobei der Transport selbst mit einer Spezialgenehmigung von UdSSR-Sicherheitskreisen "abgesichert" wurde. 
Anfang der 80ger Jahre wurden einige 1,2 Kbit/s Wahlleitungen eingesetzt.  Die Robotron/ NIZEWT - Teams waren im internationalen Dateitransfer UdSSR/DDR die ersten, die umfangreiche Datentransfers per Wahlleitung/ Modem durchführten, nach umfangreichen Anstrengungen, dieses Verfahren UdSSR-seitig genehmigt zu erhalten. Diese Transfers liefen oft die ganze Nacht. Als Jahre später ein LfA - Team auf der Leipziger Frühjahrsmesse eine 5- Minuten Datenkopplung Leipzig-Moskau demonstrierten und eine hohe staatliche Auszeichnung erhielten, rief das bei den E2- Entwicklern nur ein "müdes Lächeln" hervor.


Die Zusammenarbeit mit den NIZEWT- Spezialisten verlief auch auf persönlicher Ebene sehr kollegial-freundschaftlich. Eine besondere Rolle spielte die fachlich souveräne  und charakterlich ausgeglichen Art von Leonid Raikow, dem langjährigen Chef der Betriebssystementwicklung des NIZEWT. Unser OS- Entwicklungsleiter Walter Münch und er verstanden es, immer einen Weg zu finden, gemeinsam akzeptable Ziele zu fixieren und zu erreichen.Viele Details finden sich auch im einschlägigen Artikel Betriebssysteme desESER im UdSSR-Ueberblick des Generalkonstrukteurs Victor Prschijalkowskij.
Die Entwicklungspartner hatten gleiche kommerzielle Rechte an den Endprodukten, obwohl das Thema der Preisgestaltung für Betriebssysteme in der MRK von Län-dern, wie UVR, CSSR, VRP (erfolgreich) unterlaufen wurde und der Wert der Be­triebssysteme über Geräteverkäufe refinanziert werden musste.


Relationen zwischen Geräten (Prozessoren - und Modelltechnik) und dem Betriebssystem OS/ES

Dem Leser dieses Materials wird beim Studium der Beschreibung der Modelle der ESER-EDVA wieder bewusst, mit welchem enormen Tempo der techno­logische Fortschritt und die Effekte der globalen Arbeitsteilung das Wachstum der Systemressourcen einerseits und deren schritthaltende Verwertung für neue Anwendungseigenschaften der Technik andererseits in historisch kurzer Zeit beeinflusst hat. Dieser dialektische Spiral-Effekt aus dem Wechselspiel zwischen Angebot, Preisreduzierung und  Entstehen neuartiger Anwendungsgebiete und Technologien infolge wirtschaftlicher Verwertbarkeit ist am Beispiel des massenweisen Einsatzes von 4 Generationen Personalcomputern, der Existenz von leistungsfähigen UNIX- Servern usw. für viele jüngere Menschen heute eine Selbstverständlichkeit. Der Rückblick auf 3 Jahrzehnte Technik- Geschichte am Beispiel der Relationen zwischen Geräten (Prozessoren - und Modelltechnik) und dem Betriebssystem der EDVA zeigt deutlich, wie diese Technologie-Preisspirale die Schwerpunkte das Inge­nieurwesens im oberen Leistungsspektrum setzte in einem stetigen Optimierungsprozess zwischen Marktanforderungen, wirtschaftlich Vertretbarem, technolo­gisch Machbarem und konzeptionell hoher Zielstellung-abgeleitet aus einem aktu­ellen Über­blick zu den Tendenzen beim Prototyp-System. Dabei entstanden Lösungen, die sich deutlich vom Massenmarkt und von typischen universellen Mikroprozessor-Archi­tekturen unterscheiden. Sie vermittelt uns auch ein Verständnis, warum in der heutigen Zeit mainframe-typische SERVER noch immer viele Vorteile bieten und in der Praxis großer IT- Systeme ihren Platz haben und warum es nicht sinnvoll ist, Mainframe- Architekturen  mit den Maßstäben von Windows- Servern zu betrachten.

Die Geschichte der EDVA-Betriebssystem-Entwicklungen kann man aus dieser Sicht  zusammenfassend wie folgt kommentieren:
  • das Architekturkonzept des Systems/ 360 hat in den 60er Jahren unter den damals vorhandenen technologischen Möglichkeiten (sie unterschieden sich damals in den USA durchaus noch nicht sehr gravierend von denen im “Ostblock“) erfolgreich das Ziel umgesetzt, durch aufwendige Verarbeitungsstrukturen, Formate und modulare Hardware- Komplexe mit hoher eigener Leistungsfähigkeit Rechner höchster Leistungsfähigkeit zu realisieren. Die nachfolgende Weiterentwicklungen in den Konzepten / 370 bis / 390  folgten diesen Tendenzen, bei Beachtung deren Auf­wärtskompatibilität. Diese Entwicklung führte zu Funktionalitäten, die heute noch aktuell in Hochleistungsservern benötigt werden.
  • Die Geschichte des OC–EC folgte bis 1990 diesen Tendenzen sehr zeitnahe. 
  • Bei der Bewertung der Ergebnisse der Arbeiten an den Betriebssystemen des ESER-wie überhaupt der hier beschriebenen Ergebnisse-ist es besonders hilfreich nachzuvollziehen, dass Preise und Aufwand für Hauptspeicherbits und Plattenspeicher- Bytes im Zeitalter /360 extrem hoch waren. Hardwareaufwand für die informationsverarbeitende Register und Busstruktur und Programm-steuerungen waren sehr teuer, insbesondere weil die große Verarbeitungsbreite und kompli­zierte Befehlsstruktur das Ziel hatten, Hochleistungsrechner mit den verfügbaren Mitteln zu schaffen.  Die  Entwickler kämpften daher um jedes Byte im Programmcode, um jeden Speicherplatz bei Daten und um jeden TTL- MSI- Baustein.
  •  Obwohl Hardwareaufwand und jeder Speicherplatz teuer waren, benötigte die Industrie und Wirtschaft sehr hohe Verarbeitungsleistung. Hohe Anwenderforderungen wurden vorrangig durch wissenschaftlich–technische Berechnungen mit an­spruchsvollen Algorithmen ergänzt. Größere Flexibilität bei Multijob-Verarbeitung wurde schnell zu gefragter Funktionalität, der Schutz der wertvollen Daten, bedingt durch unzureichende Zuverlässigkeit der Hardware und Vertraulichkeit der Daten, wurde zunehmend aktueller. Hauptspeicher-orientierte Betriebssysteme der oberen Leistungsklasse mussten einen großen Funktionsumfang beim Multiprogrammbetrieb und bei der Zahl der Job-Ströme verwalten
  • Nicht nur die Verwaltung einer konstanten Zahl (MFT) oder einer flexiblen Zahl (MVT) von Aufgaben im Hauptspeicher ist in dieser Phase wichtig, sondern auch die Nutzung des Plattenspeicher-Adressraumes als virtueller Teil des Haupt-spei­chers. Dabei bestehen Forderungen, einen virtuellen Speicherraum (SVS) oder mehrere virtuelle Räume (MVS) zu verwalten, jeder Bereich gut geschützt gegen Fehler, Datenverluste, Fremdzugriffe für viele Jobströme parallel.       
  • In der Phase / 370 entwickeln sich daher vor allem leistungsfähige Schutz- und Optimierungsmechanismen.
  • Hohe Zuverlässigkeit, hohe Anforderungen an Sicherheit und Flexibilität der Nutzung der teuren Ressource EDVA erfordern enorme Aufwendungen bei Hard­ware und vor allem im Betriebssystem. Die Anforderungen im Bereich der Daten­fernverarbeitung steigen sprunghaft, was die Fähigkeit erfordert, hohe Transaktionsraten parallel zum Multitask- und Multijob- Regime  zu bewältigen.
  • Trotz bedeutsamer schrittweiser Fortschritte der Technologie ist eine EDVA immer eine aufwendige Investition und sie muss sehr effektiv betreibbar sein. Stichworte wie Teilnehmerunterstuetzung (TSO), Maschinenfehlerbehandlung, Kanalfehler­Behandlung, Endzustandüberwachung, dynamischer Testmonitor sind nur ein kleiner Ausschnitte der Technischen Forderungen an ein BS
Permanente Höchstforderungen an EDVA führten Anfang der 90er Jahre weltweit dazu, ihre außerordentliche Funktionalität bzgl. hochgradiger Security- und Daten-sicherheits-/ Datenintegritäts-Eigenschaften und Transaktionsperformance als zentrale und dezentrale SERVER in Rechnerhierachien einzusetzen. Die Softwarespezialisten der EDVA- Linie von Robotron konnten durch intensivste Ar­beit mit modernen Technologien und im ständigen Vergleich mit den Ergebnissen der Prototypfirma ein hohes Niveau erreichen. Ihr Wissen und Können ist auch nach 15 Jahren am Markt der IT-Systemintegration und bei Software- Projekten stark gefragt.

 
Einige Merkmale der Betriebssysteme OS/ES

Ein Operationssystem OS/ES des ESER bearbeitetete in den 70er und 80er Jahren Nutzer- Programme, die in einer problemorientierten Programmiersprache (PL1, FOR­TRAN, COBOL, RPG, ALGOL u.a.) oder auf Assemblerniveau geschrieben sind. Damit das OS diese Programme abarbeiten kann, ist eine genaue Definition der dafür ein­zusetzenden Ressourcen und Parameter durch eine Jobsteuersprache erforderlich. Das Betriebssystem nimmt die dadurch definierten  Aufträge (Job) entgegen und teilt sie in ausführbare Aufgaben (Task: Eine Aufgabe ist die kleinste Einheit , die ein Betriebssystem verwaltet.) Das Betriebssystem nimmt bei Vorliegen mehrerer Aufträge eine möglichst  bedarfsgerechte Verteilung der Aufträge und deren Aufgaben auf die Einzel- Ressourcen des Gesamtsystems vor und optimiert die Auslastung des Gesamtsystems. Dabei nutzt es die Eigenschaft der Hardware- Komplexe, relativ komplexe Befehlsstrukturen selbständig zu bearbeiten. Da eine EDVA in der Regel für die Bearbeitung einer Vielzahl von Aufträgen konzipiert ist, ist es Aufgabe des Systems, im Multiprogrammbetrieb die Tasks verschiedener Jobs so zu verteilen und zu verwalten, dass eine optimale und störungsfreie Bear­beitung entsteht, wobei die Systemtasks des Betriebssystems selbst einen Overhead darstellen, die einen erheblichen Anteil der Systemressourcen quasi als Blindlast binden. Die Geschwindigkeit und Sicherheit , mit der ein derartiger Multiprogrammbetrieb er­folgt, ist Ausdruck der Qualität und Effektivität eines Betriebssystems. Ein Betriebssystem des ESER ( typisch für EC 1040 bis EC 1057 ) besteht aus
Bei einer Steuerprogrammkonfigurationen SVS , die z.B. typisch für den Betrieb der EC 1055 ist, existiert ein virtueller Adressraum von max. 16 MByte Größe , der teilweise im Hauptspeicher, teilweise in einem Direktzugriffsspeicher liegt und auch alle Steuerprogramme enthält. Die Existenz eines realen 4 MByte–Hauptspeicher ist lo­gisch nicht mehr relevant, wohl aber sehr effektivitätsbestimmend.  Eine Besonderheit der BS- Entwicklungen seit Beginn war die Forderung, bei großer Funktionsvielfalt des Systems dieses übersichtlich, erweiterungsfähig und änderungsfreundlich zu halten. Daher war es modular aufgebaut und gestattete, in systematischer Weise durch neue Ausgaben und Versionen den Funktionsumfang kontinuierlich und dem Arbeitsvermögen aller Beteiligten gemäß anzureichern und an  neuen Systemeigenschaften der Gerätetechnik anzupassen. Im Verlaufe der Entwick­lung entstanden daher eine Vielzahl von Ausgaben und Modifikationen, welche nicht alle für die Anwendung in der DDR bestimmt waren und deren Hauptziel aus Sicht des DDR- Teiles des RCK ESER und der führenden Software- Spezialisten im Erhalt der Einheitlichkeit der System-Entwicklung mit der UdSSR bestand.  Nachfolgend ein kurzer , unvollständiger Überblick der bereitgestellten Systeme::
- OC- 6.0 EC ( MFT, MVT)
 
-OC- 6.1 EC ( SVS )
- OC -6.2 EC ( MVT )
 
-OC -7 EC mit SVS 7.0, SVM 3.0 und BPS 7.0
- 
OS –7.1. EC mit SVS 7.1. , SVM 3.1 und BPS 7.1.
- OS –7.2. EC mit SVS 7.2. , SVM 3.5. und BPS 7.2.
- 
OS –MVS-SP .EC

Der Umfang
des Betriebssystems OS–7.2/EC mit SVS 7.2/EC , SVM 3.5/EC und BPS 7.2/EC betrug ca. 27 Mio Anweisungen. 

Einige Bemerkungen zu den unterschiedlichen OS/ES-Betriebssystemen:

Zum SVM :
Das „System virtueller Maschinen“  (SVM) besitzt von seinem Konzept her besondere Steuermechanismen zur effektiven Verwaltung mehrerer virtueller Maschinen auf einer physischen EDVA. Es ist damit effektiv besonders für dialogorientierte Arbeit geeignet und sichert die weitgehende Isolation einzelner Anwender-Domänen gegeneinander. Auf verschiedenen virtuellen Maschinen sind auch verschiedene Betriebssysteme ablauffähig, sodass z.B. günstige Bedingungen für Entwicklungs-zwecke bestehen
Die massive Linie der SVM-Entwicklung im OC. 7 EC war insbesondere durch den Fakt bedingt, dass ein Anwender oftmals auf einer EDVA verschiedene Aufgaben-Komplexe abarbeiten musste - z.B. Produktion mit ggf. unterschiedlichen Betriebssystemen und parallel Anwendungsvorbereitung/Entwicklung neuer Pakete. Wichtiger aber war, dass es sich im Verlaufe der Entwicklungs-Zusammenarbeit mit der UdSSR herausstellte, dass man das sog. BOS ( die triviale Bezeichnung bedeutet  „Basisbetriebssystem“) in wichtigen Anwenderbereichen und in sensiblen Ministerien des „publik Sektor“ der UdSSR stark favorisierte. Dieses System war eine weitgehende Eigenkonzeption der UdSSR. Es lief nur auf virtuellen Maschinen, sodass immer ein SVM für den BOS- Betrieb benötigt wurde. Für die DDR-Seite entstanden oftmals Widersprüche im Kapazitätseinsatz, die mit Kompromissen verbunden waren, da in der DDR das BOS (BPS) nicht ausgeliefert wurde. Der o.g. Umstand zum UdSSR- Einsatz des BPS war auch der Hauptgrund, warum so­wohl in der EC 1056, als auch der EC 1057 massive hardwareorientierte SVM- Unter­stützung implementiert wurde.


Zum MVS.SP/EC (oder MVS–ES Ausgabe2):
Die langjährigen Arbeiten an der Linie OC 6/ OC 7 waren zwangsläufig mit Zusatzaufwand wegen verschiedenem „Kompatibilitäts- Ballast“ und für  andere Ei­genschaften verbunden. Damit war ein solch anspruchsvolles Produkt , wie ein modernes MVS, nur mit großen Kompromissen schnell und modern aus dem OC 7–EC weiterzuentwickeln. Daher entschieden sich 1988 die Teams der DDR- Softwareentwicklung nach Konsultationen mit dem NIZEWT, die „Seile“ zum OC 7.2. weit­gehend zu kappen und ein neues modernes Produkt zu bearbeiten. OC 7.2-EC und OS 2–MVS EC wurden zu Parallel- Linien. Dafür wurden auch Veränderungen in der Entwicklungstechnologie entschieden. Dieser Schritt kann als einer der markantesten Entwicklungsetappen der ESER- Betriebssysteme gesehen werden. 1987 wurde zusammen mit der öffentlichen Vorstellung der EC 1057 auch dieses neue Produkt vorgestellt [1]) und fand großes Interesse vieler fortgeschrittener Anwender. Auch in der UdSSR fand das MVS–ES ab 1988 eine starke Verbreitung.  Im Zuge der „Öffnung“ des russischen Marktes ca. 1992 im Ergebnis der Einführung des konvertierbaren Rubels und den Wegfall bestimmter Embargo-Restriktionen wurde seitens der Firma IBM in Russland das IBM Betriebssystem / MVS 3.8 in breitem Maße zunächst als „upgrade“ angeboten.  ESER- Anwender waren darauf bestens vorbereitet und erhielten es zu  einmaligen  Sonderkonditionen. Später hat IBM bzw. ihre Vertriebspartner, allen voran Nachfolge- Unternehmen des NIZEWT, die imaktuellen Vertrieb befindlichen Systeme mit Erfolg verkauft.
Anmerkung zu DOS/ES-Betriebssystemen
Plattenspeicher-orientierte (residente) BS waren in der Startphase des ESER ein Standard, der die knappen HS- Ressourcen weitgehend für Anwendungen frei hielt. Ab EC 1040 wurden jedoh OS.EC – also Hauptspeicher-orientierte BS- zu den Hauptsystemen. Eine ausführliche Darstellung zu DOS ist unter>> http://robotron.foerderverein-tsd.de/331/robotron331a.pdf zu finden. .

[1]  siehe Artikel B. Wetzel:  „MVS –ES Ausgabe 2“ ;  RD, Heft 3/1987
Dr. H.‑G. Jungnickel