*Dipl.-Math. Jürgen Kehr leitet das Referat Systemprogrammierung bei der Elektrizitäts-Aktiengesellschaft Mitteldeutschland (EAM) in Kassel.

Produkte für Netzwerk- und Betriebssystem-Automation, wie sie IBM mit Netview oder Systems Center mit Net/Master anbieten, mögen für Anwender großer MVS-Installationen interessant sein - für kleine und mittlere MVS-User sind sie nach Einschätzung von Jürgen Kehr" eine Zumutung. Sein Einwand: Wer will schon zusätzlich Personal einstellen, um das Rechenzentrum zu automatisieren?

In diesem Artikel geht es um kleine und mittlere MVS-Rechenzentren. Sie sind zum einen dadurch gekennzeichnet, daß sie das IBM-Betriebssystem MVS für überwiegend kommerzielle Anwendungen nutzen. Für unsere Betrachtungen ist es ziemlich unerheblich, ob es sich um die Versionen MVS/ESA, MVS/XA oder das veraltete MVS/370 handelt.

Zum anderen dreht es sich um die Rechenzentren, die Rechner in der Größe zwischen vier und 40 MIPS benutzen. In Frage kommen also IBM-Maschinen der Modellreihen 4381 oder 3090 bis etwa Modell 200S sowie deren Nachfolger 9021/9121 und natürlich die vergleichbare Hardware anderer Hersteller.

Wenn ich hier die Größe der Rechner über die MIPS-Leistung angebe, dann ist mir die Fragwürdigkeit dieses Indikators, der von IBM auch manchmal verächtlich mit "meaningless indicator of processor speed" bezeichnet wird wohl bewußt. Doch ich will ja nur eine ungefähre Abgrenzung zu den "ganz Großen" vornehmen.

Wodurch zeichnen sich nun diese Installationen besonders aus? Um diese Frage zu beantworten, macht es Sinn, einmal zu untersuchen, wie solche Rechenzentren entstanden sind beziehungsweise wie sie sich zu dem entwickelt haben, was sie heute sind.

Für viele dieser Installationen war entweder ein Zuviel an Optimismus oder an Pessimismus die Triebfeder der Entwicklung - Optimismus in bezug auf das Gesamtunternehmen, wo vielleicht erwartet wurde, daß die Umsatzzuwächse ebenso groß seien wie die Zuwachsraten der DV-Kosten. Das Rechenzentrum wäre natürlich in kurzer Zeit in den Kreis der "ganz Großen" befördert worden.

War man zu pessimistisch, so fehlte das Vertrauen in die gesicherte Weiterentwicklung von Betriebssystemen wie VSE oder von Großrechnerprogrammen der IBM-Mitbewerber wie Unisys, Bull oder Siemens. Gerade die Entwicklung des Betriebssystems VSE hat ja wieder einmal deutlich gezeigt, daß Totgesagte länger leben.

Die Personalsituation in den genannten Rechenzentren ist in der Regel gespannt. Oftmals sind es Mannschaften mit weniger als zehn Mitarbeitern (Operating, Arbeitsvorbereitung, Systemprogrammierung), die den vollen Umfang der MVS-System- und systemnahen Software zu steuern, zu überwachen und am Laufen zu halten haben. Dies sind in der Regel mindestens 35 Softwarepakete von IBM.

Hinzu kommen oft noch 20 und mehr Produkte anderer Hersteller. Diese Zahl erhöht sich nochmals, wenn man einzelne Komponenten eines großen Pakets als einzelne Produkte zählt - ein Verfahren, das bei Software dieser Größenordnung durchaus angemessen wäre. Nicht immer sind es Anforderungen wie der "24-Stunden-Betrieb" oder eine 100prozentige Verfügbarkeit, die an solche Installationen gestellt werden. Aber natürlich bleiben auch diese Installationen nicht von der Forderung nach längeren Verfügbarkeitszeiten von Online-Systemen verschont. Somit ist auch in solchen Rechenzentren der Boden für "RZ-Automation" bereitet.

Es war wohl Mitte der 80er Jahre, als eine fieberähnliche "Erkrankung" so ziemlich alle MVS-Rechenzentren befiel. Eines der Symptome war die mehr oder minder berechtigte Aufregung darüber, daß ein geschwätziges Betriebssystem zusammen mit etlichen Subsystemen einen Operator mit stündlich Tausenden von Konsolmeldungen unterschiedlicher Wichtigkeit völlig überforderte.

Der Ruf nach Automation wurde wach. Es ging nicht mehr darum, etwas an der Entstehung all dieser Meldungen und Nachrichten zu verändern, sondern man hielt Ausschau nach Programmen, die diese Meldungen verarbeiten sollten. Zu diesem Zeitpunkt kam es zur "Entdeckung" der Subsystem-Interfaces oder kurz SSI, einer Betriebssystem-Schnittstelle, mit deren Hilfe Konsolmeldungen von Programmen bearbeitet werden können. Meldungen ließen sich damit lesen und interpretieren, entsprechende Maßnahmen konnten eingeleitet werden.

Für andere Bereiche der RZ-Automation, etwa die SNA-Netzwerke, gab es so etwas ähnliches schon länger. So ist es nicht verwunderlich, daß gerade die ersten Softwareprodukte zur Automation von dieser Seite her an die Rechenzentren herangetragen wurden. Zwei Produkte seien hier beispielhaft erwähnt, nämlich System Centers Net/Master und IBMs Netview.

Bei allen Unterschieden auch Gemeinsamkeiten

Bei allen Unterschieden zwischen diesen beiden Produkten - Net/Master bietet mehr als NetView - gibt es doch auch Gemeinsamkeiten. Sie integrieren eine Reihe von Moduln, die die verschiedenen Aufgaben im Rahmen von RZ-Automation, zum Beispiel Netzwerk- oder Betriebssystemautomation adressieren. Diese Systeme waren jedoch schon von Beginn an für die ganz Großen designed. Die kleinen und mittleren MVS-Installationen, von denen hier die Rede ist, stehen vor wahren "Softwaregebirgen".

Die ohnehin kleinen RZ-Mannschaften müssen nun völlig neue Methoden, 4GL-Sprachen und Verfahren lernen, um diese Software effektiv nutzen zu können. Und dies hat natürlich ohne Personalaufstockung zu geschehen, denn schließlich soll ja gerade die Automation die lang angestrebte Entlastung im Personalbereich bringen. Diese Problematik haben die Softwareanbieter schnell gesehen. Der Anwender war nicht an Tools, sondern an Lösungen für Automationsprogramme interessiert.

Der Weg zu diesen Lösungen schien aus Sicht der Anbieter vorgezeichnet: Die vorhandenen (eigenen) Tools und Sprachen wurden genommen, um damit Lösungen zu basteln Angebote wie die Pakete ANO/ACO bei Netview oder ESF bei Net/Master sind Ergebnis dieser Entwicklung. Doch das Ei des Kolumbus war nicht gefunden, denn natürlich mußten und müssen die Installationen, die derartige Lösungen implementieren wollen, erst einmal die Basissoftware miteinkaufen und installieren - und so ganz als Black-box läßt sich dies auch nicht betreiben.

Schon früh zeigte sich, daß die notwendigen Softwareprodukte gerade bei diesen kleinen und mittleren Installationen leicht in das Gesamtumfeld zu integrieren sein mußten. Diese Forderung resultierte besonders daraus, daß es dieselben Personen waren, die etwa mit Netzwerkautomation oder Systemautomation beschäftigt waren. Insellösungen waren also von vornherein ausgeschlossen.

Es ist auch eine "äußere" Integration vonnöten

Dies haben einige Softwareanbieter bald erkannt: So wurde etwa bei Net/Master eine integrierte 4GL-Sprache, die NCC, geschaffen. Damit gibt es hier eine "innere" Integration. Doch dies reicht leider nicht aus, denn eine solche Software vermag allein wohl niemals alle Aufgaben der RZ-Automation zu lösen.

Somit ist auch eine "äußere" Integration vonnöten, daß heißt, es muß einfach möglich sein, diese Software mit anderen vorhandenen Produkten zu integrieren, und es muß einheitliche Benutzeroberflächen geben. Die Installationen und Wartungsverfahren haben standardisiert zu sein (heute unterbieten sich die Softwarehersteller in den Zeitangaben über die Dauer einer Installation). Die in den Produkten hinterlegten Informationen müssen leicht untereinander ausgetauscht werden können.

Hier eröffnet sich noch ein sehr breites Betätigungsfeld für die Software-Entwickler, denn ein Blick hinter die Fassaden zeigt deutlich, daß noch vieles im argen liegt. Doch es sind auch positive Tendenzen erkennbar. Ein Beispiel ist etwa die SQL-Einbindung im neuesten Release von Net/Master.

Ausweg in mitunter fragwürdige Eigenentwicklungen

Doch gerade dieses Produkt hat auch Nachteile (speziell eben für die "Kleinen"): Da gibt es eine Magnetplattensteuerung aus dem Hause IBM vom Typ 3990, Modell 3. IBM selbst muß zugeben, daß die Steuerung und Überwachung dieser Maschine, die mit einem leistungsfähigen Write-Cache ausgestattet ist, recht diffizil ist.

Nun wäre für die Net/Master-Installation eigentlich das Handwerkszeug (die Tools) vorhanden, hier Lösungen zu schaffen. Doch der Hersteller entwickelt (eindeutig im Hinblick auf Großkunden) eine "ganz große" Lösung, das heißt, einen kompletten Hardwaremonitor. Das ist sicher adäquat für Installationen, in denen solche Systeme zu Dutzenden und vielleicht auch noch in unterschiedlichen Typen verschiedener Hersteller betrieben werden. Für die kleinen Installationen bleibt hier aber nur der Ausweg in mitunter fragwürdige Eigenentwicklungen.

Es ist einige Jahre her, da verfolgte IBM eine Idee, die sich mit der Preisgestaltung von Softwareprodukten unter anderem im MVS-Umfeld befaßte, wovon natürlich auch die Automations-Tools nicht verschont blieben: die Prozessor-Gruppen-Aufteilung. Das bedeutet, der Preis einer Software richtet sich danach, wie groß der Prozessor ist, auf dem diese Software läuft. Offizielle Begründung für diese neue Preisgestaltung war, daß es gerade gegenüber den "Kleinen" wohl ungerecht sei, hier das gleiche zu verlangen wie von den "Großen".

Sicherlich ist dieser Ansatz grundsätzlich richtig, aber dieses CPU-Pricing ist aus drei Gründen nicht unproblematisch:

1. Die "Kleinen" werden nicht genügend entlastet. Zwischen zwei IBM-Maschinen liegt der Preisfaktor 20, bei der Software dagegen (hier das IBM-Paket OPC/ESA) nur der Faktor 4,6 - bei einem Nicht-IBM-Programm (ProTerm) sogar nur 2,5.

2. Die fälligen Software-Upgrade-Gebühren verhalten sich recht sprunghaft und liegen gerade im unteren Bereich im Vergleich zur Hardware sehr hoch. Ein Zahlenbeispiel: Bei einer Hochrüstung von einer IBM 4381 auf eine IBM 9121-210 (Preis etwa 1,7 Millionen Mark) können in einer MVS-Umgebung durchaus Upgrade-Kosten von nochmals über 900 000 Mark hinzukommen - eine bittere Pille für das DV-Management.

3. Die Upgrade-Gebühren sind "global", das heißt, es ist uninteressant, aus welchem Grund eine Hochrüstung erfolgt (viel leicht soll ein neues Datenbanksystem implementiert werden). Die Upgrade-Gebühren sind aber für alle Produkte, so auch zum Beispiel für die RZ-Automations-Tools fällig, unabhängig davon, ob sich in diesem Bereich irgendetwas ändert. Entscheidend ist nur die CPU-Größe.

Gerechtere Berechnungsgrundlagen für Software

Es bleibt hier zu hoffen, daß angesichts von Tendenzen wie Zentralisierung, Outsourcing und Downsizing neue, gerechtere Berechnungsgrundlagen für Software gefunden werden, denn diese Tendenzen werden sich über kurz oder lang auch in den Auftragsbüchern der Softwarehersteller bemerkbar machen.

Doch zurück zum Kernthema RZ-Automation. Hier gibt es zum Glück immer wieder Softwareanbieter, die auch die Belange der kleinen MVS-Installationen berücksichtigen. Sie bieten Lösungen an, die sowohl in sich als auch gegenüber dem vorhandenen Systemumfeld integriert beziehungsweise integrierbar sind.

Diese Lösungen lassen sich von kleinen RZ-Mannschaften installieren und implementieren und sind auch von ihrer Bedienbarkeit her "einfach" im besten Sinne.

An dieser Stelle ist zu allererst das Berliner Softwarehaus Beta Systems zu nennen. Mit seinen Produkten Beta77 zur Standardisierung von Batch-Abläufen, Beta92 zur Kontrolle und Archivierung von Job-Output und Beta93 zur Listenverteilung liefert es Systeme, die den genannten Anforderungen gerecht werden. Dabei bleibt die Möglichkeit, diese Produkte auch dann voll zu nutzen, wenn die DV-Umgebung sich vielleicht doch einmal zu einer großen Installation emporschwingt, nicht ausgeschlossen.

Als weitere Beispiele sind Produkte wie Sequels Proterm zu nennen, das in Deutschland von der Frankfurter Emerald Software GmbH vertrieben wird. Auch Abend-Aid und File-Aid von der Düsseldorfer Compuware GmbH gehören zu den attraktiven Produkten für mittlere MVS-Anwender. File-Aid erlaubt, moderne Online-Systeme, die von ihrem Design her nur interaktiv betreibbar sind auch (wieder) aus dem nächtlichen automatischen Stapelbetrieb heraus zu bedienen - dies ist nahezu ein Muß für die konsequente Einführung einer RZ-Automation.

Solche Softwarepakete, die sich entweder mit dem beschäftigen, was im Rechenzentrum schief gegangen ist, oder dem Bedienpersonal beim umständlichen Daten-Management helfen, können die Produktivität im Rechenzentrum erheblich steigern. Sie setzen Kapazitäten frei, die sich dann für andere Automationsaufgaben nutzen lassen. Diese Liste könnte sicher noch um etliche Softwareprodukte erweiteret werden, doch bleibt bei vielen dieser positiven Beispiele der Wermutstropfen des erwähnten "CPU-Pricings".

Es ist zu wünschen, daß sich die Anbieter von Software zur RZ-Automation an die kleinen und mittleren Installationen erinnern und sich deren Belange mehr annehmen, statt sich vorrangig DV-Großprojekten wie Galileo oder Amadeus zu widmen.

Ein Blick in die vorhandenen Lizenzverträge sollte hier das Gedächtnis der Softwareanbieter auffrischen, denn die wurden oftmals hauptsächlich mit den "Kleinen" geschlossen.