Besonders die großen VSE-Anwender stehen derzeit vor der entscheidenden Frage nach ihrer künftigen Betriebssystemstrategie. Zwar fürchten viele von ihnen den Aufwand bei einer Umstellung auf MVS oder MVS/XA, doch könnte ein Beharren auf dem einmal eingeschlagenen VSE-Pfad sehr leicht in eine Sackgasse führen. Tips für die Entscheidung VSE versus MVS gibt Falk Brauckmann*.

Die Beibehaltung der Betriebssystembasis VM/VSE auch für einen mittelfristigen Zeitraum ist bei vielen nur mit großen Anstrengungen bei Systemoptimierungen sowie mit Einschränkungen bei neuen Anwendungen und Mengenzuwächsen möglich. Durch die 16-MB-Restriktion im virtuellen Adreßraum einerseits sowie den hohen Integrationsgrad der Anwendungen und der verbundenen Programme andererseits besteht nur ein sehr geringer Spielraum für Kapazitätserweiterungen.

Auch die Anzahl der gesamt adressierbaren E/A-Einheiten von 254 stellt kurz- bis mittelfristig eine Wachstumsgrenze dar, die zwar durch SNA-Einführung (Adressierung nicht mehr vom Terminal, sondern von Steuereinheiten) hinausgezögert werden kann, aber nur zulasten zusätzlicher Anforderungen an den virtuellen Adreßraum geht.

Komplexe Anwendungen stoßen an Grenzen

Die Alternative bei diesen Problemen heißt MVS-Umstellung: Nach einschlägigen Erfahrungen können mit MVS/XA folgende wichtige Vorteile erwartet werden:

- wesentlich bessere Durchsatzraten (um 10 bis 15 Prozent);

- hohe zukünftige Ausbaufähigkeit ohne Umstellaufwand bei den Anwendungen;

- Entlastung der peripheren Geräte durch Chanel-Subsystem (20 bis 30 Prozent);

- Adreßraum (real und virtuell) bis 2 GB (Faktor 128 gegenüber DOS/ VSE bei maximaler Ausbaustufe);

- verbessertes Multiprocessing.

Das Betriebssystem MVS/XA ist technisch so ausgelegt, daß es auf Jahre hin weiter ausbaufähig ist. Das bedeutet, daß die Hardware bei Bedarf weiter aufgerüstet werden kann, ohne Umstellungsaufwand der bereits entwickelten beziehungsweise im Einsatz befindlichen DV-Anwendungen.

Für VSE hingegen gibt es eine Reihe von Entwicklungsgrenzen. So werden im wesentlichen nicht unterstützt: virtueller Speicher größer als 16 MB, mehr als 254 E/A-Einheiten CPU s 3083,3081,3084, 3033,3032 Peripherie 3880-11, 3880-13, 3850 MSS, 3800-3 sowie Software wie RACF oder JES II/III.

Bei dem VSE-Betriebssystem müssen sich die Benutzer und Betriebssystemroutinen den vorhandenen virtuellen Adreßraum (maximal 16 MB und 12 Partitions) teilen. Größeren und komplexeren Anwendungen mit vielen Dateien (zum Beispiel große Tabellen) im Programm oder mit hoher Datenblockung sind dadurch Grenzen gesetzt. Außerdem sind die Multiprogrammierungs-Möglichkeiten eingeengt, da die Zahl der parallelen Arbeiten nicht durch die bereitgestellten externen Betriebsmittel sondern bereits durch den einfachen virtuellen Speicher begrenzt werden. Der Aufbau des virtuellen Speichers zeigt, daß bis zu maximal 32 "interaktive Partitions" in einer der VSE-Partitions angesiedelt sind. Als Terminal-Control-Programm läuft in der gleichen Partition außerdem CICS/VS.

Dem Trend zu preis-/leistungsgünstigen großen Hauptspeichern entsprechen im VSE nicht die Möglichkeiten, diesen zur Erhöhung des Durchsatzes effektiv einzusetzen:

- Den wichtigsten Engpaß stellt die "VSE-Multiprogramming-Steuerung" dar, das heißt die Partition-Prioritäts-Vergabe ohne Berücksichtigung der Auslastung wichtiger Systemressourcen (zum Beispiel Realspeicher). Einem höheren Multiprogramming-Level bei gleichzeitigen CICS-Online-Anwendungen sind dabei enge Grenzen gesetzt.

- Wesentliche Steuerinformationen für die Ausführung von Jobs sind im VSE auf einem Plattenspeicherbereich untergebracht. Diese Datei wird im Multiprogramming stark frequentiert und stellt einen Engpaß dar.

- Häufig benutzte Übergangsroutinen (zum Beispiel OPEN, CLOSE, EOJ) werden in die Shared Virtual Area (SVA) geladen. Bei Aufruf müssen diese Routinen dann aber in den Übergangsbereich (Transient Area) des Supervisors übertragen werden. Nicht reentrant geschriebene Systemroutinen müssen weiterhin bei Bedarf von der CIL (Core Image Library) geladen werden.

Ein wesentlicher Gesichtspunkt für die Leistung eines Systems mit virtuellem Speicher ist die Art und Weise, wie der Seitenwechsel ausgeführt wird. Bei VSE beträgt die Seitengröße 2 KB, bei VM 4 KB. Diese Größe wurde gewählt, um kleinere Hauptspeicher besser nutzen zu können. Der gesamte virtuelle Speicher ist im Verhältnis 1: 1 auf dem Seitenspeicher abgebildet. Dies bedeutet, daß jede Seite ihren fest zugeordneten Platz auf dem Seitenspeicher hat. Die Effektivität des Verfahrens beschränkt sich auf niedrige Pagingraten. Damit können im VSE hohe Anforderungen an den Hauptspeicher (zum Beispiel bei Spitzenbelastungen) nicht kurzfristig befriedigt werden.

Bei einem höheren Multiprogramming-Level kann die Forderung nach weitgehend automatischer Anpassung an wechselnde Arbeitslast bei optimaler Nutzung aller Ressouren mit den VSE-Mitteln allenfalls ganz grob erfüllt werden. Die Betriebsmittelvergabe geschieht nämlich in Abhängigkeit vom Wettbewerb um die CPU-Steuerung; statisches Dispatching als auch dynamisches Dispatching berücksichtigen die Partitions-Priorität oder die CPU-Intensität der Jobs, nicht aber die Gesamtauslastung des Systems.

Bei der Platzverwaltung auf DASD-Speichern muß im VSE fehleranfällige Platzdisposition betrieben werden, bei der man die genauen Spuradressen einer Platte anzugeben hat (Ausnahme: VSAM). Auch zum Wiederauffinden einer Datei müssen die Informationen manuell festgehalten werden.

Unter VSE/Advanced Functions im /37 Mode kann der virtuelle Adreßraum auf 40 MB erweitert werden. Da die 16-MB-Grenze die wichtigste Limitierung der weiteren DV-Entwicklung bei vielen VSE-Anwendern darstellt, wäre diese Betriebssystemversion die erste prüfenswerte Alternative. Zu berücksichtigen ist dabei allerdings, daß die Hardware-Konsequenzen dieser Alternative sehr kostenintensiv werden können.

Aufstockung nur für wenige User interessant

Durch eine Kombination aus Hardware-Design sowie Programming-Support hat VSE einen virtuellen Adreßraum von 16 MB im ECPS: VSE- oder VM-Mode oder 40 MB im /370-Mode.

Die Aufstockung des virtuellen Speichers über die 16-MB-Grenze hinaus ist allerdings nur für Anwender interessant, die VSE-Native fahren, also nicht unter VM sowie nur für Prozessoren bis 4381 einsetzbar. Und das sind leider die wenigsten VSE-Anwender.

Als erste Alternative zu VSE bietet sich MVS/370, entsprechend MVS/ SP, an. Dieses Betriebssystem ist seit Anfang der 70er Jahre im Einsatz. Gegenüber VSE ergeben sich wesentliche Verbesserungen, besonders im Durchsatz, beim Multiprogramming, im realen Adreßraum (bei 32 MB), im Paging, in der Betriebsmittelsteuerung sowie durch Mikrocodebenutzung.

Für IBM-Anwender ist MVS/370 aus diesen Gründen eine Betriebssystemalternative für die nächsten Jahre. Durch die weiterhin vorhandenen Restriktionen in der Adressierung im virtuellen Adreßraum (16 MB) stellt sich allerdings die Frage, ob es sich hierbei nicht auch um eine Übergangslösung handelt, die mittelfristig eine erneute Umstellung auf MVS/XA erfordert. Die wesentlichen Grenzen der IBM-System-/370Architektur wie 16 Ein-/Ausgabe-Kanäle pro Prozessor, 16 MB Realspeicher (32 MB mit Einschränkungen) sowie 16 MB Adreßraum des virtuellen Speichers werden nur von MVS/XA überwunden.

Wachstumsforderungen auch künftig befriedigen

Durch die Erweiterung der Adressierung auf 31 Bit besteht jetzt die Möglichkeit, bis zu 2 Gigabyte Zentralspeicher zu adressieren, bis zu 256 Kanäle anzuknüpfen sowie bis zu 65 536 E-/A-Einheiten anzuschließen. Für IBM-Großsysteme ab 3083 aufwärts ist die Basis geschaffen worden, bei den Anwendungen laufende Wachstumsforderungen auch zukünftig befriedigen zu können.

Im MVS steht jedem Benutzer ein Adreßraum von zirka 8 MB virtuellem Speicher je Benutzerprogramm (Batchjob oder TSO-Teilnehmer oder Online-Kontrollprogramm oder Online-Message Region) zur Verfügung, beim MVS/XA sogar 2000 MB. Theoretisch läßt MVS 9999 Adreßräume zu, die praktische Begrenzung ist abhängig von der Größe des zur Verfügung stehenden Realspeichers sowie der Leistungsfähigkeit der verwendeten Zentraleinheiten und der entsprechenden Peripherie.

Die Leistung von IBM-Rechnern läßt sich durch Ersetzen häufig verwendeter Instruktionsfolgen durch Mikrocode erhöhen. In dem IBM-System 308X und 4381 gibt es nur Mikrocode zur Erhöhung der MVS-Leistung, nicht für den VSE-Modus.

Die MVS-Designer haben insbesondere dem Trend zu preis-/leistungsgünstigeren großen Hauptspeichern von Anfang an Rechnung getragen. Der Hauptspeicher ist in diesem Betriebssystem zum primären Performance-Faktor geworden:

- Alle nicht residenten SVC-Routinen befinden sich in der Pageable Link Pack Area (PLPA). Es existieren keine Transient Areas.

- Job-/Step-bezogene Informationen werden in der Scheduled Work Area (SWA) verwaltet. Damit läßt sich ein wesentlich höherer Parallelitäts-Grad erreichen.

- Nur MVS unterstützt die neue Speichermöglichkeit VIO (Virtual Input/Output) für die Haltung von Dateien im virtuellen Speicher.

Page-Operationen werden parallelisiert

Durch die Seitengrößen von 4 KB wird im MVS die Anzahl der Seitenwechsel-Operationen vermindert. Bestimmte Systembereiche haben eigene Page-Dateien. Daneben sind mehrere Benutzer-Page-Dateien möglich. Diese Aufteilung nach funktionellen Gesichtspunkten ermöglicht eine durchgreifende Parallelisierung der Page-Operationen. Da keine 1: 1-Abbildung des virtuellen Speichers erfolgt, wird der externe Speicher so verwaltet, daß Such- und Umdrehungswartezeiten minimiert werden. Zweifellos ist bei großen Hauptspeichern ab 2 MB das MVS-Paging-Verfahren günstiger. Weitere MVS-spezifische Eigenschaften, die als Abgrenzung zu VSE dienen können:

- Betriebsmittelsteuerung SRM zur optimierenden Systemführung,

- automatisches Sichern und Reorganisieren von Platten mit HSM,

- MVS-Dateikatalog mit GDGs,

- interaktive Debug-Compiler zur Anwendungsentwicklung,

- Mehrprozessorsysteme mit automatischem Lastausgleich,

- Mehrrechnersysteme mit JESIII-Jobeingabe-Subsystemen,

- Dateizugriffs-Kontrollsystem RACF,

- Job-Control-Sprache mit Step-Resultat-Steuerung, Prüfpunkt-/Wiederanlaufeinrichtung.

Über die allgemeinen und MVS/ SP-Eigenschaften hinaus zeichnet sich MVS/XA durch folgende Highlights aus:

- Virtual Storage Constraint Relief (VSCR) im Bereich unterhalb 16 MB wird durch das Auslagern von Teilen des Betriebssystems in den Adreßraum oberhalb der 16-MB-Grenze erreicht. Der im unteren 16-MB-Bereich dadurch freiwerdende virtuelle Speicher vergrößert den Raum für SQA, CSA oder den Anwenderbereich.

- Der von 16 MB auf 2 GB erweiterte Adreßraum kann von den Anwendungen genutzt werden, die dafür neu programmiert worden sind oder die mit einem Compiler übersetzt wurden, der die XA-Möglichkeiten voll nutzt. Assembler-Programme müßten mit dem H-Assembler umgewandelt werden. Abzuraten ist dagegen von der Umwandlung mit dem Cobol-2-Compiler, da hierbei geschützte Cobol-Worte nicht kompatibel sind und erheblichen Umstellungsaufwand verursachen würden.

- Durch die Vergrößerung des Benutzerbereichs unterhalb der 16-MB-Grenze werden bei CICS/VSAM-Installationen 2,2 MB freigemacht, die den Anschluß von weiteren 870 Terminals und eine Erhöhung der Transaktionsrate um 14,5 Transaktionen pro Sekunde gestatten (IBM-interne Messungen).

- Durch die Einführung neuer Algorithmen bei langen Warteschlangen wurde der "Large System Effect" reduziert.

- MVS/XA gestattet die direkte Übertragung von E-/A-Dateien aus allen Teilen des Realspeichers, wodurch zusätzliche Seitenumlagerungen entfallen.

- Mittels der Einrichtung "Dynamic Path Reconnect" bei IBM 3880/3380 kann das Reconnect von der E-/A-Einheit an jeden freien Kanalpfad erfolgen. Bei vier parallelen Pfaden, die alle zu 50 Prozent ausgelastet sind, erhöht sich die Wahrscheinlichkeit für ein erfolgreiches Reconnect bei XA auf 93,75 Prozent. Bei Messungen konnte dadurch eine Verringerung der Geräte-Antwortzeit um 30 Prozent bei gleicher Kanalbelastung festgestellt werden. Kanäle unter MVS/XA lassen sich daher mit einer Belastung von 40 bis 50 Prozent betreiben.

- Außerdem kann die Zahl der Kanäle insgesamt (sofern erforderlich) mehr erhöht werden, zum Beispiel 24 Kanäle beim System 3083 B/H.

- Die bimodale Betriebsweise gestattet die bestehenden /370-Programme mit 24-Bit-Modus unverändert weiterzuverwenden und parallel dazu neue Module mit 32-Bit-Adressierung zu erstellen und auch mit bestehenden Programmen zu verbinden.

- Durch MVS/XA werden 13 Prozent aller ungeplanten IPLs vermieden, die aufgrund von Softwarefehlern entstanden sind und damit die Verfügbarkeit verbessern.

- Verbesserte Kapazitätsplanung mit RMF-Messungen über E-/A-, Kanal-, Warteschlangen, Antwortzeit-Aktivitäten.

Berücksichtigt man das zur Zeit geltende MVS-"Sonderangebot" der IBM (Einsparmöglichkeiten für VSE-Anwender mit dem sogenannten XAMO-Paket zirka 740 000 Mark) und den jetzt noch geringeren Umstellungsaufwand als später in ein paar Jahren, so ist der Übergang zu MVS/XA auch aus wirtschaftlichen Aspekten heraus zu empfehlen. Eine

kostengünstigere MVS-Migration erscheint zukünftig nicht mehr möglich.

Mit Wirkung vom 17. Juni 1986 hat die IBM Deutschland GmbH folgendes Marketingprogramm angekündigt: Das MVS/XA Migration Offering (XAMO) wird für Kundenstandorte gewährt, wo bisher weder MVS/370 noch MVS/XA in Produktion ist. Ziel dieses Angebots ist es, die direkte Migration zu MVS/XA sehr attraktiv zu machen und darüber hinaus den Einsatz von MVS/XA in mehreren Betriebsstätten zu fördern.

Das XAMO bietet MVS/XA-Erstbenutzern für das Betriebssystem und die wesentlichen zugehörigen Programmprodukte folgende Vorteile:

- Für die ersten acht Monate entfallen die monatlichen Gebühren für örtliche Programmunterstützung. In diesem Zeitraum ist die Standardtestzeit der Programmprodukte enthalten.

- Die einmaligen Anfangsgebühren für die Programmprodukte werden erst zu Beginn des neunten Monats in Rechnung gestellt.

- Für die anschließenden 12 Monate (9. bis 20. Monat) werden nur 50 Prozent der dann gültigen monatlichen Lizenzgebühren in Rechnung gestellt.

Die vollen monatlichen Lizenzgebühren für die ausgewählten XAMO-Lizenzprogramme werden ab dem 21. Monat nach dem Beginn der MVS/XA-Testperiode berechnet.

Für folgende Lizenzprogramme ist das XAMO gültig: MVS/SP-JES2 und JES3, MVS/XA Data Facility Product Version 2, Resource Measurement Facility (RMF), TSO/E (XA), SMP/E, ISPF Version 2, ISPF/PDF Version 2, ACF/VTAM Version 3 (XA), ACF/SSP Version 3, CICS/OS/ VS, ASM H Version 2, IMS/VS Version 1 mit Features, VS Cobol II Compiler und Library, VM/XA Systems Facility.

Dieses Programm zeigt, daß für Nicht-MVS-Kunden die direkte Migration zu MVS/XA die strategische Richtung ist. Es soll diese Anwender ermutigen, direkt auf MVS/XA zu migrieren. XAMO ist ein für IBM sehr ungewöhnliches Sonderangebot, das die Einstiegskosten für die ersten 20 Monate entscheidend reduziert. Die maximale Einsparung für den Kunden kann bis zu 740 000 Mark betragen.

Der Schritt von DOS/VSE nach MVS/XA darf jedoch nicht unterschätzt werden, da beim Einsatz dieses Betriebssystems ein zusätzlicher Systemaufwand entsteht. Insbesondere ist im Schulungszeitraum die Nichtverfügbarkeit der Mitarbeiter zu beachten. Generell stellt das Betriebssystem MVS/XA höhere Anforderungen sowohl qualitativer als auch quantitiver Art an die Systemprogrammierung.

Den MVS-Vorteilen stehen außerdem die Nachteile der relativ hohen Umstellungskosten, des MVS-Ausbildungsaufwandes für die gesamte DV-Mannschaft sowie größerer Hauptspeicher für MVS/XA gegenüber.

Ein weiteres Argument für die Umstellung ist dagegen, daß die von IBM verfolgte Strategie primär in Richtung des weiteren Ausbaus des Betriebssystems MVS/XA geht. Das bedeutet, daß an dem Betriebssystem MVS/XA hinsichtlich der DV-Technik und dem Bedienungskomfort auch zukünftig weitere Verbesserungen vorgenommen werden.

Demgegenüber steht das Betriebssystem DOS/VSE, das mittelfristig sicherlich noch gut unterstützt wird aber DV-technisch nicht mehr weiter ausgebaut wird. Für den Kunden bedeutet dies, daß unter dem Betriebssystem MVS/XA auch zukünftig der DV-technologische Wandel nutzbar ist. Beim Betriebssystem DOS/VSE ist dies sehr fraglich, da das Produkt mittelfristig sicherlich eingefroren wird.

Neben den technologischen Aspekten sollten noch wirtschaftliche Aspekte berücksichtigt werden Dies gilt besonders für den heute noch geringen Umstellungsaufwand als zum Beispiel in zwei bis drei Jahren wegen der zur Zeit günstigen Angebote und Zugeständnisse der IBM. Je länger jedoch die vorliegende Problematik zeitlich verschoben wird, um so größer ist nachher der Umstellungsaufwand, da die Zahl der umzustellenden Programme immer größer wird.

*Falk Brauckmann ist Geschäftsführer der Gedos/Unisoftware GmbH, Meerbusch.