Die dritte Schicht wird mannlos gefahren:

Höhere RZ-Auslastung durch Automatisierung

19.05.1989

Das Schlagwort RZ-Automatisierung verheißt die Entlastung des Operators und vor allem eine bessere Rechner-Auslastung. Ein noch weiter gestecktes Ziel ist die Einführung einer dritten, unbeaufsichtigten Schicht. Doch vor die Erfüllung solcher Automations-Wünsche setzte der komplexe RZ-Betrieb die Mühe und den Schweiß einer umfassenden Planung. Udo Pfeiffer* gibt einen Überblick.

Die Automatisierung erfolgt in mehreren Stufen über einen längeren Zeitraum. Grundsätzlich hilft es, wenn alle direkt betroffenen Mitarbeiter von Anfang an in den Prozeß eingebunden werden. Dadurch sind die Beteiligten während aller Phasen der Automation auf dem gleichen Informationsstand.

Eine wesentliche Rolle spielt der Funktionsumfang des Automationstools. Entsprechende Schnittstellen wie für Job-Planung, Performance- und Change-Management müssen vorhanden sein. Nicht zuletzt ist eine umfassende Automation nur möglich, wenn der entsprechenden Software außer herkömmlichen Konsolmeldungen zusätzliche Indikatoren zur Verfügung stehen.

Das Schlagwort "Unattended Operation" faßt den Wunsch zusammen, die Konsol-Operatoren und eine unbeaufsichtigte dritte Schicht einzuführen. Das Ziel der Automation ist, durch Unterdrücken oder Umrouten weniger Meldungen an der Masterkonsole seltene komplexe Abläufe zu erhalten, (zum Beispiel Spinloop) zu automatisieren oder das Starten und Beenden von Subsystemen zu bestimmten Zeiten zu veranlassen. Für diesen Zweck muß die Software in der Lage sein, alle Konsolbefehle automatisch und zeitabhängig abzusetzen, Meldungen nach Kennung, Inhalt und Struktur auszuwählen oder Meldungen zu unterdrücken, zu verändern, zu kopieren und umzuleiten. Das geschieht meistens in der ersten Phase der Automation, verantwortlich dafür ist hauptsächlich der Bereich RZ-Betrieb.

Die gängigen Prozeduren sollten bereits als Muster zur Verfügung stehen, so daß nur kleine Modifikationen notwendig sind, um ohne großen Aufwand schnell zum Ziel zu kommen. Erstellen neuer Prozeduren per ISPF-Dialog statt auf Befehlsebene erleichtert wesentlich die Handhabung. Simulation der Meldungen und Befehle, sprich der realen Umgebung ermöglicht das Austesten umfangreicher Prozeduren und eine reibungslose Übernahme in die Produktion.

Dazu gehört auch, anhand des existenten Syslog Hinweise einzuholen, wann und wie oft welche Ereignisse vorkommen. Solche Aussagen ermöglichen, hinsichtlich der Meldungen, Befehle und Zeiten einen guten Einstieg in die Automation. Eine aktuelle Statistik sollte den Anwender jederzeit über den laufenden Stand informieren.

Der Sicherheit gilt besondere Aufmerksamkeit

In diesem Zusammenhang spricht man auch von Remote-Steuerung. Die bisherige Hardware-Systemkonsole wird durch einen PC und die entsprechende Software ersetzt. Dadurch kommt der Anwender in die Lage, IML, IPL, oder Konfigurations-Befehle automatisch zu von ihm selbst bestimmten Zeiten oder gar von zu Hause aus durchzuführen. Alle genannten Möglichkeiten - auch der Zugriff auf VTAM und TSO - können durch diesen Remote-PC erfolgen. Auf dieselbe Weise werden SAD-Werte grafisch dargestellt oder ein Logging der HW-Systemkonsolaktivitäten vorgenommen.

Auch der Remote-Alert gehört zum Thema "Unattended Operation". Abhängig von den technischen Einrichtungen erfolgt im Problemfall ein akustischer Hinweis. Eine weitere Forderung in diesem Bereich ist die Möglichkeit, mehrere Rechner lokal oder remote von einem Bildschirm aus zu überwachen.

Leider wird häufig der Sicherheitsaspekt vernachlässigt. Der Zugriff auf ein Automationstool ermöglicht nämlich auch den Zugriff auf nahezu alle System-Ressourcen. Daher muß festgehalten werden, wer zu welchem Zeitpunkt Prozeduren verändert, löscht, hinzufügt, inaktiviert oder aktiviert. Darüber hinaus sind in vielen Fällen automatisierte Funktionen für den Anwender nicht mehr sichtbar. Die Transparenz der Abläufe im Rechenzentrum muß durch ein entsprechendes Logging gewährleistet sein.

Was die Verfügbarkeit betrifft, so wird sie durch Startup-Prozeduren erreicht, die zu festgelegten Zeiten oder abhängig von bestimmten Ereignissen alle Aktivitäten vom IML bis zur Aktivierung des TSO durchführen, oder im umgekehrten Fall per Prozedur den sogenannten Shutdown-Prozeß einleiten.

Noch wichtiger ist allerdings die Möglichkeit, rechtzeitig Probleme zu erkennen und automatisch die richtigen Recovery-Maßnahmen einzuleiten. In diesem Fall reichen herkömmliche Konsolmeldungen nicht aus. Zusätzliche Informationen von System-Monitoren - die auf Performance-Probleme oder Systemveränderungen hinweisen - sind notwendige Indikatoren, um mittels Automation de Verfügbarkeit entscheidend zu verbessern.

Service Garantie durch solche Service-Level-Definitionen sind Vereinbarungen, die einem bestimmten Workload - sprich Benutzerkreis, - einen bestimmten Service garantieren. Vereinbarungen über den zu erwartenden Leistungsgrad sind die Voraussetzung, um Performance-Probleme zu erkennen. Ohne Schwellwerte ist es nahezu unmöglich, das laufende System zu beurteilen.

Automation bezüglich Performance-Management setzt voraus, daß Schwellwerte definiert und automatisch kontrolliert werden können. Nur so ist es möglich, umgehend zu reagieren, wenn zum Beispiel die TSO-Antwortzeit überschritten wird oder Ressourcen überlastet sind.

Eine umfassende Automation ist nicht von herkömmlichen Meldungen, dem Erkennen von Operatorbefehlen oder zeitgesteuerten Aktivitäten her möglich. Nicht jedes Ereignis erzeugt eine Meldung.

Hinsichtlich der Verfügbarkeit ist es wichtig zu wissen, ob zu einem bestimmten Zeitpunkt bestimmte Adreßräume aktiv sind oder nicht ob Abweichungen von der gewünschten HW/SW-Konfiguration vorliegen.

Die Kontrolle der Service-Level-Definitionen setzt voraus, umgehend einen Hinweis zu bekommen, sobald die Antwortzeiten einen definierten Schwellwert überschreiten, wenn Adreßräume länger laufen als üblich, wenn Adreßräume mehr Ressourcen verbrauchen als gewünscht. Um automatisch den aktuellen Workload zu kontrollieren, ist es erforderlich, die entsprechenden Schwellwerte abzufragen.

Es gibt eine Menge wichtiger Informationen, die an der Masterkonsole normalerweise nicht zur Verfügung stehen. Dasselbe gilt für den Befehlsumfang. Herkömmliche MVS- oder sonstige Subsystem-Befehle reichen nicht aus. Schnittstellen zu anderen Monitoren müssen vorhanden sein.

Man unterscheidet Basis-Automation wie Message-Filtering oder den Einsatz zeitabhängiger Prozeduren, kennt darüber hinaus aber auch Möglichkeiten hinsichtlich Performance-Management. Oft sind viele Informationen notwendig, bevor eine Aktion eingeleitet wird.

Die Qualität der Automation ist entscheidend abhängig von Art und Menge der Informationen, die zur Verfügung stehen. Aus diesem Grund passen die Möglichkeiten eines Expertensystems ideal zu den Anforderungen an die RZ-Automatisierung.

Die RZ-Automation begann mit dem Erkennen von Meldungen und dem Einleiten einer Aktion. Heute sind wir bereits einen großen Schritt weiter.

Udo Pfeiffer ist Technical Coordinator der Candle GmbH, München.