Die Möglichkeit, Abläufe im Rechenzentrum zu automatisieren, ist an die Fragen gebunden: in welchen Bereichen, bei welchen Funktionen und mit welchen Mitteln? Die Anforderungen an die einzusetzenden Software-Tools müssen einer klaren Definition unterliegen, alle absehbaren Aspekte berücksichtigen und genaue sowie verständliche Entscheidungskriterien beinhalten. Karl-Heinz Masser, Leiter Systemtechnik der ICR in Neustadt an der Weinstraße, faßt seine Erfahrungen bei der Automatisierung im Rechenzentrum zusammen.

Die Situation ist geprägt durch steigende Kosten, eine Erhöhung der Mengengerüste und vor allem einem immer krasser auftretenden Mangel an qualifiziertem Personal. Weitere Gründe sind unter anderem Forderungen nach mehr Rechnerleistung und größeren Speicherkapazitäten durch ständiges Anwachsen der Daten und Informationen, eine schnellere Verfügbarkeit der Anwendungen und höhere Qualitätsanforderungen bei immer komplexer werdenden Abläufen. Parallel dazu steigt die Anzahl der Anwendungen, die zu Lasten der Mitarbeiter-Ressourcen bei Anwendungsentwicklern gehen.

Darüber hinaus werden mehr Operatoren gebraucht, weil die Arbeitszeiten im Rechenzentrum bei vielen Unternehmen dem Drei-Schichtbetrieb entgegengehen. Außerdem sind zusätzliche Systemprogrammierer und Anwendungsentwickler erforderlich, um den Endanwenderservice zu erhöhen. Letztlich steigt das Mengengerüst durch die Zahl der Meldungen, zumal das wachsende Netz und die hinzugeschalteten Subsysteme den Hauptrechner belasten. Die steigende und existentielle Abhängigkeiten der Unternehmen von der Datenverarbeitung nimmt zu.

Schließlich ergibt sich eine Erhöhung der Risiken für die Verfügbarkeit. Das heißt, die Verfügbarkeit wird schlechter und der Service-Grad sinkt. Um diesen Problemen vorzubeugen ist eine Unterstützung durch automatische Funktionen im Rechenzentrum zu empfehlen.

Die Frage, die DV/Org.-Leiter, Organisatoren, System- und Anwendungsprogrammierer sowie das Management interessiert, lautet: was kann man durch die Automatisierung erreichen?

Die Ziele der Automation im Netzwerk- und System-Management sind bei der ICR mit vier Punkten festgeschrieben:

1. Entlastung des RZ-Personals von manuellen Routineaufgaben,

2. Sicherstellung des Change-Managements,

3. Steigerung des Servicegrads und

4. die Positionierung für weiteres Wachstum.

Die Automatisierungsmöglichkeiten waren auf zwei Ebenen durchführbar, wobei die eine als operative Ebene bezeichnet wurde und folgende Bereiche umfaßte:

þBatch-Management wie Job-Scheduling,

þOnline-Management wie Überwachung und Steuerung der Monitore für Cics, IMS,

Complete oder IDMS,

þNetzwerk-Management,

þSystem-Management, das hohe Anforderungen an die Organisation stellt,

þEnvironment-Management, wie zum Beispiel betriebliche Überwachung wie Energie, Klima

und Betriebsmittel.

Beim Netzwerk-Management ist das automatische Recovery von Netzwerken wichtig, da es wesentlich die Verfügbarkeit und den Netzeinstieg für Endbenutzer erhöht. Besonders bei großen Firmen mit vielen Endbenutzern, die zudem über mehrere unterschiedliche Subsysteme verteilt sein können, muß automatisiert werden. Zu klären ist dabei: wer darf ins Netz rein und wer darf von der Sicherheit her was machen?

Das System-Management erfordert eine Automation der Subsysteme bei IPL, IML, Start Up, Shut Down, MVS oder JES, weil durch die Existenz von teilweise bis zu 60 Konsolen das Operating überfordert ist. Eine Reduzierung auf zwei bis drei Konsolen ist angebracht.

Ferner gehört zum System-Management, daß Operator-Steuerungswerkzeuge geschaffen werden müssen, weil durch die Mitarbeiter-Fluktuationen, durch Personalengpässe, durch immer neue Mitarbeiter (auch Anfänger) ein reduzierter und nicht vorhandener Wissensstand auftreten kann. Das heißt, die Bediener-Oberfläche für den Operator muß verändert werden. Also weg von den echten Meldungen und echten Kommandos und hin zur Menüführung. Das sind die Automatisierungsmöglichkeiten im operativen Bereich.

Die zweite Ebene ist administrativer und planerischer Natur. Die wesentlichen Punkte dabei sind:

þPerformance-Management durch Performance-Automaten, die Online-Engpässe

automatisch beheben, zum Beispiel durch Verlagerung auf ein zweites Subsystem um

dadurch Jobs von der CPU her zu stoppen, also ein echtes Performance-Management,

um die Performance kritischer Anwendungen zu gewährleisten;

þService-Management, das heißt Festlegung der Antwortzeit-Verhalten;

þProblem-Management;

þChange-Management;

þSecurity-Management, das heißt das Legitimatisieren und Administrieren der Benutzer;

þKonfigurations-Management;

þInstallations-Management;

Beim Konfigurations-Management gilt die besondere Aufmerksamkeit der Datenbank-Topologie, in der alle DV-Daten eines Unternehmens gespeichert werden. Von hier aus werden wiederum Tabellen, Netzwerke, Monitortabellen und Subsysteme wie Cics, IMS etc. automatisch generiert - ohne Eingriff des Systemprogrammierers!

Was muß ein Tool Ieisten, um allen Anforderungen und Situationen gerecht zu werden?

Eine Voraussetzung, die nicht unterlassen werden sollte, ist alle Betroffenen, auch die Operatoren, in das Automations-Projekt mit einzubeziehen. Die Operatoren sind deshalb wichtig, weil sich in großen Firmen durch die RZ-Automation Kapazitäten im Operating freisetzen lassen. Das bedeutet Personalabbau von Operatoren beziehungsweise Umbesetzung oder Umschulung. Daß Operatoren in der Automationsgruppe mitarbeiten sollen, ist auch wichtig weil sie am besten wissen, welche Meldungen kommen und wie man darauf reagieren muß. Für die Entwicklung komplexer Automaten sind hingegen die Systemprogrammierer verantwortlich.

Eine der wesentlichsten Anforderungen an ein leistungsfähiges Tool ist, die einfache Implementierung und die schnelle Einarbeitung der DV-Mitarbeiter zu gewährleisten. Außerdem ist die Forderung nach einer höheren Programmiersprache unerläßlich. Diese Sprache muß eine Sprache der vierten Generation sein, um schnell und effizient entwickeln zu können, und sie soll synchrone und asynchrone Prozesse beinhalten. Mit der asynchronen Prozeßbildung kann diese Nachrichtenflut im Gegensatz zur synchronen aufgeteilt werden, ohne das es zu Meldungsstaus führt.

Kriterium: Problem-/

Change-Management

Besondere Beachtung verdienen die Datenbankfunktionen. Wesentlich ist eine Schnittstelle zu Datenbanken, für Verfügbarkeiten, für Auswertungen und für die Konfigurations-Datei. Ein weiteres Kriterium ist das integrierte Problem-/Change-Management, das in das Automationsumfeld eingebunden sein muß, das heißt, wenn ein Problem auftritt, muß automatisch ein Fehlersatz geschrieben werden.

Ferner muß das einzusetzende Produkt über ein ganzheitliches Konzept verfügen, das heißt Integration aller Teilbereiche sowie Möglichkeiten zur schnellen Modifikation bei Änderungen. Dazu gehören auch Dokumentations-Einrichtungen.

Um eine zukunftssichere Lösung zu erhalten, fällt der Wartung und Weiterentwicklung eine wichtige Aufgabe zu. Der Aufwand dafür darf nur gering sein, was durch eine einheitliche Programmiersprache begünstigt wird.

Die Automation muß einen reibungslosen und automatischen Wiederanlauf gewährleisten. Fortschrittliche Recovery/Restart-Verfahren sind deshalb unumgänglich.

Bei den Automation-Tools haben sich die eingesetzten Programmiersprachen ständig weiterentwickelt. Assembler wurde für JES-Exits und MVS-Exits benutzt. Danach war Clisten ein erster Schritt für NCCF und TSO. PL/1 und C folgten als höhere Programmiersprachen, die auch für die Automation geeignet waren. Rexx kommt aus dem VM und ist eine SAA-Sprache, die unsere Anforderungen zum großen Teil erfüllt hat. NCL, die Programmiersprache von Cincom, erhielt bei uns den Zuschlag, weil die Automation einfacher zu programmieren und zusätzlich ein Gesamtkonzpet vorhanden ist. Wenn wir mit NCL den gesamten Net/Master automatisieren wollen, haben wir es nur mit einer einzigen Programmiersprache zu tun und das war für uns sehr entscheidend.

Einen Schritt nach vorne bedeutet das neue Modul ESF (Expert System Foundation). Das heißt, daß mit diesem Tool der Wirkungsbereich auf die regelbasierte Automation erweitert wird. Die Handhabung erfolgt durch Menüs, so daß Operatoren und Netzwerk-Manager ihr Wissen über Systemprobleme und Systemereignisse in Form von Regeln speichern können. Wiederholt sich danach ein Problem, bereinigt ESF die Situation. Während früher der Operator programmieren mußte, arbeitet jetzt der Automat das Problem ab. Mit ESF können 80 bis 90 Prozent automatisiert werden.

Worin unterscheiden sich jetzt die zur Zeit angebotenen Tools? Alle Module, wie Session-Management, Datenbank, Netzwerk-Management, File-Transfer, regelbasierte Automation oder Systemautomation sind im Net/Master voll integriert, verfügen über eine einheitliche Oberfläche und eine durchgängige Programmiersprache. Die Implementierung ist sehr einfach und transparent.

Dem stehen andere, konkurrierende Produkte gegenüber, bei denen wohl Teile wie Problem-/Change-Management als Komplex integriert, aber Insellösungen weiterhin beherrschend sind. Das heißt unter anderem, daß die Oberflächen unterschiedlich sind. Diese Lösungen basieren entweder auf Netview oder auf eigenen Produkten wie zum Beispiel Candle. Insgesamt bieten sie nicht so viele Automations-Möglichkeiten wie Net/Master. Die Richtigkeit unserer Entscheidung hat sich sowohl im eigenen Rechenzentrum, als auch bei Automationsprojekten unserer Kunden voll bestätigt.