Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

24.04.1992 - 

Operatorlose Nachtschicht eingeführt

Automatisierte Job-Steuerung und CPU-Überwachung gekoppeltDie Hardware

24.04.1992

Mainframe-Umgebung: IBM 9121-260,

Hauptspeicherkapazität:

128 MB,

I/O: 16 Kanäle,

Leistung: 17 MIPS,

Plattenspeicher: 50 GB

(steht unmittelbar vor einer Erweiterung),

Massenspeicher: Hitachi-Kassetten 7480, vier Stationen mit sogenannten Autoloadern (ein Lift, der zwölf Kassetten pro Station aufnehmen kann),

Drucker: 3800 Endlos-Drucker (zum Jahreswechsel wird auf Einzelblatt umgestellt).

*Peter Braunstein ist akademisch geprüfter Versicherungskaufmann und Leiter des Rechenzentrums bei der Anglo-Elementar-Versicherug in Wien.

Eine operatorlose Nachtschicht hat die Wiener Allianz-Tochtergesellschaft Anglo-Elementar-Versicherung eingeführt. CPU-Überwachung und Job-Ablaufsteuerung wurden dabei miteinander verzahnt, so berichtet Peter Braunstein*. Trotz gestiegenen Verarbeitungsaufkommens lasse sich das RZ heute, drei Jahre nach Einführung der Automationslösung, mit einem vergleichsweise geringen Aufwand betreiben.

Unser RZ gehört von der Ausstattung her zwar zur Familie der Groß-DV, ist aber eher als kleiner Betrieb mit geringer Personalausstattung und einem bescheidenen Maschinenpark zu bezeichnen. Im Rechenzentrum selbst sind acht Mitarbeiter beschäftigt: je drei Personen im Operating und in der Arbeitsvorbereitung, ein Mitarbeiter in der Arbeitsnachbereitung und der RZ-Leiter. Zwei Mitarbeiter sind mit der Job-Steuerung, dem gesamten Scheduling, beschäftigt.

Unser RZ existiert bereits seit 1962. Damals wurde eine Tabelliermaschine betrieben. Später, in den 70er Jahren, gingen wir zur Lochkartenverarbeitung über. Die ersten Bildschirme wurden 1974/75 installiert. Die DV-Abteilung besteht heute aus 37 Mitarbeitern. Diese sind in drei Gruppen unterteilt:

- die Entwicklungsgruppe beschäftigt sich mit Neuentwicklungen;

- die Betreuungsgruppe besteht aus einer Teilgruppe, die Standardprodukte betreut, und dem Benutzerservice als Ansprechpartner für das gesamte Unternehmen;

- zur Produktionsgruppe zählen das Rechenzentrum, die Systemprogrammierung und eine separate Hardwarebetreuung, die aber vor allem die PCWelt betrifft.

Anfangs wurde bei uns im Zwei-Schicht-Betrieb mit einer Früh- und einer Abendschicht gearbeitet. Die Frühschicht dauerte von 6 bis 14 Uhr, die sogenannte Nachmittagsschicht von 14 bis 22 Uhr. Nachts wurde die Maschine abgeschaltet, um am nächsten Morgen wieder hochgefahren zu werden. In Zeiten einer besonders großen Nachfrage nach Maschinenkapazität fielen diese Leerzeiten schmerzlich ins Gewicht.

Wir standen vor der Entscheidung, entweder eine dritte Schicht einzuführen oder mit der Automation zu beginnen. Im Jahre 1987 entschieden wir uns für den zweiten Weg. Zunächst gingen wir das Risiko ein, die Maschine unbewacht durchlaufen zu lassen. Dafür wurden unkritische Unternehmensdaten ausgewählt. So wurden nachts Statistiken durchgeführt und nicht termingebundene Aufgaben bewältigt. Diese Jobs wurden abends einfach in die Queue gestellt. Am nächsten Morgen ließ sich dann feststellen, ob sie durchgelaufen waren oder nicht.

Obwohl man anfangs befriedigt feststellte, daß weder die Klimaanlage noch die Maschine selbst Probleme verursachten, wuchs die Notwendigkeit, die Nacht auch für die Abwicklung "sensiblerer" Programme zu nutzen. Das führte zu dem Wunsch nach vollständiger Automatisierung. Der Beschluß, eine entsprechende vollautomatischen Lösung für die Nacht zu suchen, wurde Ende 1987- gefaßt. Das ganze nächste Jahr sollte dazu genutzt werden, den Markt hinsichtlich einer kompletten Lösung zur Automation zu prüfen.

Geduld war erforderlich, weil zu dem Zeitpunkt noch kein Unternehmen alle Anforderungen die an eine solche Komplettlösung gestellt werden, beispielhaft erfüllt hatte. Zwar waren Teilautomatisierungen bekannt - Job-Scheduling zum Beispiel - allerdings jeweils mit Personalanwesenheit. Die gesamte Abgrenzung und Bewertung der Produkte blieb daher Aufgabe des RZs.

Für die Suche hatten wir aus reichend Zeit veranschlagt - ein Umstand, der sich heute bezahlt macht. Dabei stellte sich heraus, daß im Hause zwei große Anwendungsbereiche abgedeckt werden mußten. Einerseits war die Steuerung der Produktion zu organisieren. Dabei war zu klären, wann und unter welchen Bedingungen ein Job abläuft und welche Abhängigkeiten zwischen den Jobs bestehen. Zum anderen war die CPU-Überwachung zu berücksichtigen. Relevant wurden zum Beispiel die Fragen, welche Commands abgesetzt werden müssen oder auf welche Meldungen in welcher Weise zu reagieren ist.

Da es zu dem Zeitpunkt kein Produkt gab, das beide Bereiche abdeckte, ging die Marktbeobachtung in zwei Richtungen, wobei auch auf die Schnittstellen zwischen beiden Produkten zu achten war. Im Bereich der Job-Ablaufsteuerung ging es darum, mit einer sehr kleinen Mannschaft, der Arbeitsvorbereitung, auszukommen. Damals waren das nur zwei Personen. Sie mußten darüber hinaus den weiteren Betrieb betreuen, während die Implementierung des zu erprobenden Werkzeugs durchgeführt werden sollte.

Einige Produkte schieden allein deswegen aus, weil ein großes Projektteam während einer langen Projektdauer gebunden gewesen wäre. Wir hatten uns auf die Tools zu beschränken die sukzessive ausbaufähig waren. Implementierte Teillösungen mußten unabhängig ausbaufähig sein, das heißt, immer wenn die Bedingungen für das Programm erfüllt waren, mußte es starten. Das gleiche hatte nach und nach für alle weiteren Programme zu gelten.

Ende 1988 ließ man eine Testinstallation der Software Control-M von Boole & Babbage durchführen. Bemerkenswert war für uns nach erfolgter Installation, Schulung und Erklärung die Tatsache, daß ein Mitarbeiter des Softwareanbieters in der Lage war, ad hoc ein beliebig gewähltes Programm aus der Produktion der Anglo-Elementar-Versicherung automatisch - nach Vorgabe der Bedingungen und der erforderlichen Aktionen - starten zu lassen. Diese erste Lösung war korrekt implementiert und ist gelaufen - und das war genau das, was das Rechenzentrum haben wollte. Nach zweitägiger Einarbeitung war die Mannschaft in der Lage, das Produkt zu benutzen. Typische Bedingungen für die Durchführung eines bestimmten Jobs sind datumabhängige Ereignisse unter Berücksichtigung selbstdefinierter Kalender. Während unsere Versicherung mit vier selbstdefinierten Kalendern auskommt, gibt es durchaus Anwender die aufgrund der Vielzahl von Programmen auch 100 verschiedene Kalender selbst definieren. Die Verwaltung ist allerdings oft einfach. Zumeist muß nur ein Kalender verwaltet werden, alle anderen können dann automatisch nachgeführt werden. Bei der Anglo-Elementar-Versicherung laufen etwa 1000 Produktionsprogramme, vorwiegend in PL/1 geschrieben, von denen 100 bis 250 täglich in Betrieb sind. Weitere Anwendungen werden wöchentlich, monatlich, quartalsweise oder nur jährlich aktiviert.

Heute kann unser Ziel, die Einführung eines operatorlosen Betriebs zur Nachtzeit auch bei kritischen Jobs, als erreicht gelten. Dazu war neben einer ausgefeilten Job-Ablaufsteuerung eine mit ihr verzahnte CPU-Überwachung nötig, die aus Meldungen und Ereignissen einen Call generieren konnte, einen sogenannten Dial-out.

Das konnte nur eine Firma anbieten. Bei einer Entwicklung mit Pioniercharakter, die zusammen mit der österreichischen Firma Schöller durchgeführt wurde, haben wir festgestellt daß jedes CPU-Überwachungs-Tool, das ein Command absetzen kann - und im Prinzip müssen das alle können -, auch in der Lage ist, ein Dial-out zu generieren.

Ein solches Überwachungs-Tool muß über den sogenannten WTO-Buffer (WTO - write to operator, Teil des MVS) zugreifen. Da alle Systeme, sowohl MVS selbst als auch alle Subsysteme, über diesen WTO-Buffer schreiben (zum Beispiel CICS, TPX Session Manager, TSO, JES) kann jedes Tool diesen Buffer für ein eigenes Eingreifen nutzen.

Genau an dieser Stelle setzt das CPU-Überwachtungs-Tool ein. Es scannt die Meldung und sieht nach, ob eine definierte Meldung vorliegt, auf die zu reagieren ist. Mögliche Reaktionen sind die Ausgabe der Meldung in doppelter Helligkeit, die Umlenkung der Ausgabe oder eine automatische Antwort. Nachfolgend wird dann eine VTAM-Adresse aktiviert, die über das MCP ein Modem aktiviert, das dann wiederum eine Telefonnummer anwählt. So funktioniert dann der Call nach außen - das kann an und für sich jedes Produkt. Alles was nach dem Aktivierungs-Command stattfindet, ist nicht mehr produktabhängig.

Unser Job-Ablaufsystem ist gleichfalls in der Lage, eine Meldung abzusetzen und in diesen WTO-Buffer zu "stellen". Diese kann durch das Überwachungswerkzeug ausgelesen werden mit der entsprechenden Möglichkeit, darauf zu reagieren. Somit ist eine Schnittstelle vorhanden.

Unser Job-Ablaufsystem setzt ein Programm - hier Job A genannt - ab. Das Programm hat zwei mögliche Ausgänge: Ist der Job o.k., wird automatisch die Steuerung durch das System auf den Folge-Job ausgelegt. Im Falle "not o.k." steht ein Recovery-Job zur Verfügung, der die Datenbanken wieder zurückstellt, Ersatzdateien für Folge-Jobs erstellt etc. Geht dieser Job auch in Ordnung, dann folgt der nächste, der die normale Produktion fortsetzt.

Gibt es für das Recovery kein o.k., so ist eine Situation entstanden, die einen manuellen Eingriff erfordert. Jetzt muß das Job-Ablaufsystem eine Meldung in den WTO-Buffer stellen, auf die die CPU-Überwachung zugreift und eine bestimmte Adresse im Netz aktiviert, worauf wiederum ein Dial-out veranlaßt wird.

Das Dial-out selbst sieht so aus, daß an dem Rechner ein Modem hängt, von dem aus über eine normale Telefonleitung eine Nummer gewählt wird. Die Nummer aktiviert einen Pager, den der Bereitschaftsdienst trägt.

Dort weiß man dann zwar daß etwas passiert ist, aber noch nicht, was. Die Retour-Strecke ist die sogenannte Dial-in-Strecke: Der Mitarbeiter in Bereitschaft hat zu Hause einen PC stehen und außerdem ein Modem installiert - angeschlossen an ein Telefon. Er aktiviert ein Programm, das den Wählvorgang im Modem auslöst. Auf der Gegenseite steht ein empfangendes Modem, es kommt zu einem Shake-hands zwischen den beiden kommunizierenden Modems.

Das empfangende Modem hängt aber nicht an einem Remote-Netz, sondern über einen Converter an der lokalen 3274 im LAN. Es bestehen also selbst dann, wenn das Netz abstürzt noch Chancen, sich ins System einzuloggen. Dieses Modem identifiziert den Anrufer, unterbricht die Leitung und startet die Recall-Einrichtung, die den Mitarbeiter von sich aus anruft.

Dieses Verfahren des Remote-Operating ist übrigens eine gute Sicherung gegen unbefugten Eingriff und belastet den Mitarbeiter nicht mit Telefonkosten. Das Modem des Mitarbeiters hebt ab und dieser hat jetzt alles auf seinem PC laufen, was er auch im Rechenzentrum auf seinem Terminal hat - via Terminal-Emulation.

Sämtliche notwendigen Host-Sessions, für die er inhouse Berechtigung hat, stehen ihm zur Verfügung. Er kann das Problem somit lokalisieren und handhaben oder irgendwelche Ersatzaktionen starten. So ein Eingreifen kommt höchstens alle zwei bis drei Wochen vor. Meistens sind solche Noteingriffe unkritisch. Selten muß der Bereitschaftsdienst das Rechenzentrum aufsuchen, um das aufgetretene Problem zu lösen.

Normalerweise sind die gewöhnlichen Programme um 23 Uhr fertig. Kann ein Programm diese Deadline nicht einhalten, so wird der Bereitschaftsdienst aktiviert, denn die gesamte Automatisierung könnte sich ja "aufgehängt" haben. Auch hier kann sich der Mitarbeiter wiederum einwählen und nachsehen, was los ist. (Meistens hat sich nur eine Überzeit bei einem Programm ergeben.)

Nur in der Anfangsphase der Implementierung kam es vor, daß ein Programm abstürzte, unvorhergesehene Zustände herbeiführte und Bedingungen schuf, die die Folge-Jobs blockierten. Das hier geschilderte Grundsystem der gesamten Automationsphilosophie wird in vielerlei Hinsicht imitiert - etwa für die automatische Alarmierung via Wählmodem bei Stromausfall, Defekten in der Klimaanlage oder bei Wasserschäden.

Weil wir die Hände wieder freier haben, können wir uns produktiv neuen Aufgaben widmen. So soll jetzt mehr für einen optimalen Ausdruck gesorgt werden Geplant ist der AFP-Druck und eine mit Hilfe von Control-D automatisierte Druckersteuerung.