RZ-Automatisierung bei der Kasseler Wintershall AG

Der Operator soll zum Systemingenieur werden

01.12.1989

Automatisches Operating ist mehr als nur Zukunftsmusik. Dabei geht es langfristig nicht nur um den operatorlosen RZ-Betrieb, sondern auch um eine Umorientierung der Operatoren zu Systemingenieuren. Die Unternehmen, die erfolgreich RZ-Automation realisiert haben, sind jedoch laut Fred Grimm* noch an einer Hand abzuzählen.

Die Wintershall AG hat vor gut zwei Jahren unter meiner Verantwortung die RZ-Automatisierung mit der Auswahl der dazu notwendigen Software-Tools eingeleitet. Heute läßt sich zusammenfassen, daß in Kassel nach Realisierung der ersten Modernisierungs-Stufe die Nachrichtenflut an das Operting eingedämmt, der Batchbetrieb automatisiert und der Dialogbetrieb teil-automatisiert ist. Darüber hinaus wurde eine Alarmierung eingeführt und der Durchsatz der Großrechner und die Ablaufsicherheit erhöht. Unter dem Strich hat die Wintershall AG auch noch eine Personal- und Kosten-Einsparung zu verzeichnen.

130 Mitarbeiter im Bereich Informatik

Der Bereich lnformatik beschäftigt in unserer Zentrale rund 130 Mitarbeiter. Hinzu kommen zwölf dezentrale DV-Zentren firmeneigener und verwandter Unternehmen. Das DV-System-Management beteut mit 55 Mitarbeitern Aufgaben wie Beschaffung und Abrechnung, Hardware-Planung, Kommunikations-Software mit Netz-Design und -Steuerung, Produktion mit Datenerfassung und Operating im RZ sowie Betriebssystem- und Anwender-Service.

Unsere Hardware-Konfiguration ist komplex und umfangreich. In Kassel stehen unter anderem eine IBM 3084 QX mit 29 MIPS Leistung und ein 22-MIPS-Rechner von Comparex fünf Doppel-Kassetten-Lautwerke 6380, zwei Front-end-Rechner IBM 3725 und ein Matrixumschaltsystem. Unser TP-Netz mit neun Subareas ist an das Netz unserer Konzernmutter BASF angeschlossen. Die rund 1000 Bildschirme und Drucker und etwa 700 PCs - davon ein Drittel mit Hostanschluß - sind lokal beziehungsweise remote mit den Rechnern verbunden.

Zu den strategischen Software-Produkten zählen als Betriebssystem MVS/XA, DB2 als Datenbank sowie Netmaster und Sysmaster als Netzwerk- und

System-Managementsystem. Die Liste der Tools und Subsysteme umfaßt Produkte wie ACF/VTAM, CICS, TSO/ISPF, Roscoe, DL/1. JES2, RACF (Datenschutz), HS5000 (Produktionsplanungs- und steuerungssystem), MICS und SAS (Systemüberwachung), QMF und DMS.

Warum wurde überhaupt RZ-Automation aus der Sicht des Managements notwendig? Der sehr umfangreiche lst-Zustand ergab in unserem zentralen Rechenzentrum, daß im Monat rund 30 000 Batch-Jobes, 5 Millionen Transaktionen, davon zwei Drittel in CICS, 700 000 Druckseiten, 7000 Kassetten-Mounts und 650 000 Konsolmeldungen anfallen.

Bei einer Hardware-Verfügungbarkeit von mehr als 99,8 Prozent und einer Verfügbarkeit der Software von 98,5 Prozent werden rund 12 000 Dateien gepflegt und 1400 Datenbanken gespeichert. Betrachtet man einmal allein die 650 000 Konsolmeldungen pro Monat, so ist dies ein Größenordung, die das Operating stark belasten.

Vom Rechenzentrum werden bei steigender Nachrichtenflut immer höhere Verfügbarkeiten gefordert. Die Qualitätsanforderungen selber steigen. Besser, schneller und komfortable heißt die Devise. Die Abläufe werden immer komplexer und mit 1500 Jobs am Tag komm man an die Leistungsfähigkeiten der Rechner und des Operatings. Vor Automationsbeginn fuhren wir drei Schichten (Montag 6 Uhr bis Samstag 6 Uhr) in einem RZ mit zwei Hosts. Für die Bedienung im Maschinensaal mit Konsole, Drucker und Kassetten, TP-Operating und Monitoring sind 13 Mitarbeiter im Einsatz.

Heute gehen die Trends im Rechenzentrum in Richtung auf

- steigende Nachrichtenmengen

- höhere Verfügbarkeit von Anwendungen

- höhere Qualitätsanforderungen bei komplexen Abläufen

- nachlassende Schichtbereitschaft vor allem am Wochenende

- Mangel an qualifïziertem Personal

Automatisierung der RZ einzig gangbarer Weg

Um diesen Anforderungen genügen zu können, schien uns die Automatisierung des Rechenzentrums der einzig gangbare Weg. Die Schritte, dies zu realisieren, waren: Systemautomation, Netzwerkautomation und Alarmierung. Davon erwarteten wir eine

Entlastung des RZ-Personals und den Wegfall von Routinetätigkeiten.

Schon länger sind wir daher dabei, in unserem Rechenzentrum Vorgänge wie Abbrüche, Abstimmung, Datensicherung Jobsteuerung, Fehlerbereinigung, DFÜ und Mounts zu standardisieren oder zu automatisieren. In den letzen beiden Jahren haben wir diese Bemühungen intensiviert. Mit folgenden Maßnahmen haben wir unsere Automation vorbereitet:

- Normierung der Vorlauf- und Steuerkarten, wobei die Verantwortung beim Anwender liegt.

- Ein einheitliches Verfahren für die Datenfernübertragung auf die auch die Hardware abgestimmt ist.

- Fehler- und Wiederholzeiten-Analyse

- Automatischer Restart/Recovery (DBRC)

- Ablösung Belegleser

- Einsatz eines Jobplanungs und -steuerungssystems (HS 5000)

- Automatische Abstimmung auf der Basis des IBM-Guides der BASF

--- Einsatz von Kompressions-Software (Compress-DMS)

--- automatische Kassettenzuführung

--- Kassetten-/Bandverwaltung (CA1)

Die Ziele der Automatisierung waren: Zuerst die Nachrichtenflut zu reduzieren und dann eine operatorlose Nachtschicht einzuführen. Daher haben wir im Herbst 1487

begonnen, die bei anderen Unternehmen vorhandenen Lösungen oder Ansätze zu prüfen, um so personalaufwendige Eigenentwicklungen nach Möglichkeit zu vermeiden. Es hat sich jedoch gezeigt, daß ein eigenes Entwicklungsengagement nicht zu umgehen war.

So schien uns etwa die Betriebsbeobachtung mit Apowas von der Apollo GmbH veraltet zu sein. Außerdem hätten wir, wie wir bei der Prüfung einer entsprechenden Installation feststellten, zusätzlich die Netview und Netmaster-Software von Cincom einsetzen müssen. Der Netview Einsatz bedeutete die Beherrschung von Programmiersprachen wie C-List, REXX und ASS. Dies konnten und wollten wir dem Operating, das ja einen wesentlichen Bestandteil der RZ-Automation realisiert, nicht zumuten. Zwar gaben sachliche Gründe den Ausschlag, doch bei unserer Entscheidung für eine Eigenentwicklung mit unter Einsatz von Netmaster spielte es auch eine Rolle, daß wird das Cincom-Produkt bereits kannten.

Zwei K.o.-Kriterien bei der Auswahl

Ich hatte bei der Auswahl noch zwei K.o.-Kriterien gesetzt: Ich wollte eine mächtige aber einfach zu handhabende Sprache, die das qualifizierte Konsol-Operating schnell in die Lage versetzt, damit zu arbeiten. Außerdem sollte neben dem MVS-Operating auch das ganze Netzwerkoperating und das Installation-Management mit abdeckt werden.

Der bisherige Aufwand der Projektgruppe läßt sich anhand von Zahlen darstellen: Auf die Systemprogrammierung entfielen rund 300 Manntage, die Basis-System- und Netzwerk-Programmierung benötigte rund 150 Manntage, auf Netzwerksteuerung entfielen 100 sowie auf Produktion und Operating nochmals 75 Manntage. Die Arbeit verteilte sich auf sieben Mitarbeiter aus verschiedenen Bereichen unserer DV-Abteilung. Davon waren drei Projektmitglieder für die Programmierung zuständig, einer davon im Vollzeit.

Die insgesamt 625 Manntage hätten wir jedoch wesentlich reduzieren können, wenn unser Lieferant mit einem regelbasierten Modul etwas früher auf den Markt gekommen wäre. Gerade hier haben wir einen sehr großen Teil unserer Aktivitäten (Erstellung Basissystem) investieren müssen.

Die Ausgaben für unsere Automatisierung belaufen sich auf ein Investitionsvolumen vom 270 000 Mark, Einmalkosten von 106 000 Mark und jährlichen Kosten von 70 000 Mark. Bei den Investitionen sind die Preise für Kompressions-Software und automatische Kassettenschächte eingerechnet, ohne die eine mannlose Nachtschicht nicht zu realisieren gewesen wäre. Diesen Aufwendungen stehen nach unseren Berechnungen Einsparungen von jährlich 208000 Mark netto gegenüber .

Seit Februar 1989 ist "scharf geschaltet", das heißt, die operatorlose Nachtschicht ist voll in Produktion. 98 Prozent aller Meldungen sind heute behandelt und der automatischen Behandlung zugeführt. Im Operating haben wir eine Einsparung von vier Mitarbeitern erzielt. Wir haben insgesamt, wenn wir den Zeitraum von Beginn der RZ-Automation betrachten, von 18 Operatoren, die wir inklusive Arbeitsvorbereitung hatten, auf sechs reduzieren können, wobei wir die zwölf freigesetzen Mitarbeiter nicht entlassen mußten, sondern anderweitig einsetzen konnten.

Doch damit ist unser Ehrgeiz noch nicht befriedigt. Nach der Schaffung eines Basissystems für die Meldungsbehandlung und Automation zur Abschaffung der Nachtschicht und EntIastung des Personals nehmen wir die Stufen zwei und drei unserer Automation in Angriff:

Stufe 2:

- Ausdehnung des operatorlosen Betriebs durch Vorverlegung dieser Schicht von

halbelf am Abend auf acht Uhr.

- Einführung von Managementsoftware für die Druckausgabe

- Einbeziehung von Klimas automatisches Power off/on

- Automatisches IML/IPL und Startup von Subsystemen um Zeit zu gewinnen

Stufe 3:

- Einbeziehung von Werks- und Abteilungsrechnern

- Roboter-Einsatz für die Kassettenzuführung

- Schrittweise Umorientierung des Berufsbildes der Systemoperatoren in Richtung

Systemingenieur.

Langfristig wird sich, so haben wir erkannt, das Berufsbilder Operators ändern müssen. Gefragt ist in Zukunft nicht mehr der Bediener, sondern der Systemingenieur.

Unsere Mitarbeiter müssen in die Lage versetzt werden, mit all den technischen Möglichkeiten umzugehen, die ein automatisiertes Rechenzentrum verlangt . +

*Fred Grimm ist Abteilungsleiter DV-Systemmanagement bei der Wintershall AG in Kassel.