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.
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-typischem
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 mußten 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 demonstierten und eine hohe staatliche Auszeichnung erhielten, rief das bei den E2- Entwicklern nur ein "müdes Lächeln" hervor.
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 Betriebssysteme ü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 (siehe.
Fehler! Verweisquelle konnte
nicht gefunden werden.) wieder bewusst, mit welchem enormen Tempo
der technologische 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 Ingenieurwesens im oberen Leistungsspektrum setzte in
einem stetigen Optimierungsprozess zwischen Marktanforderungen, wirtschaftlich
Vertretbarem, technologisch Machbarem und konzeptionell hoher
Zielstellung-abgeleitet aus einem aktuellen Überblick zu den Tendenzen beim
Prototyp-System. Dabei entstanden Lösungen, die sich deutlich vom Massenmarkt
und von typischen universellen Mikroprozessor-Architekturen 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
Aufwä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 komplizierte
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 anspruchsvollen
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 Vertrau-lichkeit 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-speichers.
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 Hardware und vor
allem im Betriebssystem. Die Anforderungen im Bereich der Datenfernverarbeitung
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, KanalfehlerBehandlung,
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 Arbeit 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- Porgramme, die in einer problemorientierten
Programmiersprache (PL1, FORTRAN, COBOL, RPG, ALGOLu.a.) oder auf
Assemblerniveau geschrieben sind. Damit das OS diese Programme abarbeiten kann,
ist eine genaue Definition der dafür einzusetzenden 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 Bearbeitung 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 erfolgt, ist Ausdruck der Qualität und
Effektivität eines Betriebssystems.
Ein Betriebssystem des ESER ( typisch für
EC 1040 bis EC 1057 ) besteht aus
-
Steuerprogrammen
( Jobverwaltung, Datenverwaltung, Aufgabenverwaltung , Diagnosemittel ) und
-
Verarbeitungsprogrammen
( Serviceprogramme,Sprachübersetzer ,u.a. )
-
Betriebssysteme
können bei der Systemgenerierung prinzipiell für vier
Steuerprogrammkonfigurationen generiert
werden:
-
System
mit einem virtuellen Adressraum (SVS)
-
System
mit mehreren virtuellen Adressräumen (MVS)
-
Multiprogrammbetrieb
mit einer festen Anzahl von Jobs ( MFT)
-
Multiprogrammbetrieb
mit einer variablen Anzahl von Jobs (
MVT)
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 logisch 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 ände-rungsfreundlich zu halten. Daher war
es modular aufgebaut und gestattete, in systematischer Weise durch neue
Ausgaben und Versionen den Funktionsumfang konti-nuierlich und dem
Arbeitsvermögen aller Beteiligten gemäß anzureichern und an neuen Systemeigenschaften der Gerätetechnik
anzupassen. Im Verlaufe der Entwicklung 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 Minsiterien des „public sector“ 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 sowohl in der EC 1056, als auch der
EC 1057 massive hardwareorientierte SVM- Unterstü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 Eigenschaften
verbunden. Damit war ein solch anspruchsvolles Produkt , wie ein modernes MVS,
nur mit großen Kompromissen schnell und modern aus dem OC 7–EC
weiterzuentwicklen. Daher entschieden sich 1988 die Teams der DDR- Soft-wareentwicklung
nach Konsultationen mit dem NIZEWT, die „Seile“ zum OC 7.2. weitgehend 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 Betriebssytem / 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. .