Kommunikationsnetze nehmen eine zentrale Rolle der inner- und außerbetrieblichen Kommunikation der meisten Unternehmen ein. Ausfälle, Leistung und Beherrschbarkeit des Netzes beeinflussen unmittelbar die Produktivität des Unternehmens.

Die Message-Analyse im Netview-Umfeld kennt vier verschiedene Nachrichtentypen:

- WTO - Write to Operator,

- WTOR - Write to Operator with Reply,

- solicited Messages (erwartete Nachrichten) und

- unsolicited Messages (unerwartete Nachrichten).

Jeder Nachrichtentyp löst in der Regel andere Aktionen aus. Aus diesem Grunde orientiert sich die Automation mit Netview und REXX an klaren Konzepten für die Steuerung der Nachrichten durch Vergabe von Routing-Codes. Mit Hilfe dieser vordefinierten Codes werden die Nachrichten an die entsprechenden Konsolen im TP-Leitstand des Rechenzentrums weitergeleitet, zum Beispiel auf die MVS-Konsole MCS, DB2-Konsole oder die Netview-Konsole. Hierbei ist darauf zu achten, daß im TP-Leitstand möglichst wenige Konsolen abgebildet werden. Die TP-Leitstandkonzeption ist ein spezielles, sehr umfangreiches Thema. Es soll hier nur am Rande erwähnt werden.

Die Definition der Routing-Codes, also die Zuordnung der Routing-Codes zur entsprechenden Konsole, erfolgt in einer Bibliothek des Betriebssystemes, zum Beispiel im MVS das Member "Consolxx" in der MVS-Parmlib. Die Zuordnung kann jedoch auch dynamisch durch Operatoreingriffe, beispielsweise durch den MVS-Befehl VARY 81D, CONSOLE, ROUT = (5, 6), erfolgen.

Im Umfeld von MVS und Netview stehen für die Nachrichtenanalyse beziehungsweise Nachrichtenverarbeitung Dienstprogramme zur Verfügung. Besondere Bedeutung kommt dem "MPF" (Message Processing Facility) zu. MPF dient zur Filterung, Analyse, Unterdrückung und Weiterverarbeitung von Nachrichten.

Die Nachrichten kommen vom Betriebssystem oder von einem Subsystem. Mit MPF können die Nachrichten, die an der Bedienerkonsole angezeigt werden, um zirka 70 Prozent reduziert werden. MPF ist somit primär ein Nachrichtenfilter. Alle Nachrichten, auch die von MPF unterdrückten, werden in einen Log-File, zum Beispiel den MVS-Syslog, eingetragen, wenn der Eintrag nicht durch einen Exit verhindert wird.

Um die Nachrichtenanalyse zu vereinfachen, hat IBM das Dienstprogramm Syslog-Message-Analyseprogramm für die maschinelle Nachrichtenanalyse der Log-Files entwickelt. Damit sollten Nachrichtenanalyse und Automation im Netview-Umfeld erfolgen.

Besonders auf die Analyse der Nachrichten-Frequenz-Intervalle muß viel Wert gelegt werden. Auch hierfür bietet IBM ein Dienstprogramm, nämlich Traffic-Analysis, an. Die MPF-Funktionen sind Standard-MVS-Betriebssystem-Funktionen für:

- die Bestimmung von Anzeigenattributen (zum Beispiel Farbintensität am Bildschirm),

- Unterdrückung von Nachrichten und

- Weiterleitung von Nachrichten an Netview über das Subsystem-Interface (SSI).

Basierend auf MPF und einer sorgfältigen Nachrichtenanalyse kann mit der Entwicklung der Netview-REXX-Prozeduren begonnen werden. Der Aufruf der jeweiligen Prozeduren wird von

Netview gesteuert, ebenso wie die laufenden Prozeduren sowie das gesamte MVS-Umfeld. Netview kann also auch von einer Konsole aus die direkte Verbindung zu MVS aufbauen. Der MVS-Befehl wird von Netview an das Betriebssystem weitergeleitet, weil sich das Tool wie eine Betriebssystem-Konsole verhalten kann. Somit steuert kann . Somit steuert eine Netview-Master-Konsole das gesamte Umfeld von Betriebssystem, Monitor, Datenbank und Netzwerk.

Die auf Basis der Nachrichtenanalyse erstellten REXX-Prozeduren (Automaten zur Realisierung des operatorlosen Betriebes) können also von MVS-Konsolen, Netview-Konsolen oder eventuell sogar ohne physikalische Konsole durch eine Auto-Task, die im Hintergrund läuft und keinen Operator-Eingriff erfordert, gestartet beziehungsweise überwacht werden. Die manuell oder automatisch gestarteten Netview-REXX-Prozeduren kommunizieren mit allen Subsystemen, etwa mit DB2, VTAM, CICS, IMS DC, RACF, JES etc.

Auch die Übertragung von REXX-Prozeduren auf andere Rechner, zum Beispiel im MVS-JES3-Mehrrechnerverbund vom Global-Rechner auf den Local-Rechner, die über NCP oder CTC (Kanäle) verbunden sind, ist möglich. Im JES3-Mehrrechnerverbund sollte jedoch die Automation stets auf dem Global-Rechner laufen. Im praktischen Betrieb mit JES3 zeigt Netview noch Schwächen.

Konzepte für Realisation der internen Automaten

Netview selbst besteht aus zwei Hauptspeicher-Routinen:

- Netview-Subsystem-Address-Space und

- Netview-Application-Address-Space.

Der Netview-Subsystem-Address-Space beinhaltet das Netview-Subsystem-Interface sowie die Message- und Command-Buffers. Diese Komponente Netview-SSI erhält die Nachrichten und Steueranweisungen vom MVS-Subsystem-Interface. Die ankommenden Nachrichten und Commands werden dann in den Netview-Command-Buffers des Netview-Subsystem-Adress-Space gespeichert. Von hier werden die Nachrichten an den Netview-Application-Address-Space, auch Netview-Master-Region genannt, weitergeleitet. Je nach der auszuführenden Funktion übernimmt jetzt eine der vielen Netview-Tasks des Netview-Application-Adress-Space die Kontrolle und ruft den gewünschten Systemdienst, zum

Beispiel REXX-Prozeduren, Fehlerroutine etc., auf Die gerufene Funktion kann nunmehr unter der Kontrolle der sogenannten Netview-Main-Task (NMT) anlaufen.

Ich darf daran erinnern, daß es sich bei dieser Art von Automation um interne Automation handelt. Bild 4 zeigt die Netview-Tasks des Netview-Application-Adress-Space für die interne Automation.

Die dargestellten Tasks sollen in dieser Ausarbeitung nicht im Detail vorgestellt werden. Die Texthinweise in der Grafik deuten die elementarsten Aufgaben der jeweiligen Task an. Von besonderer Bedeutung ist die Task "SSIR" (Subsystem-Interface-Router). Diese Task stellt indirekt die Verbindung zwischen Netview und dem Subsystem-Interface des Betriebssystemes her.

Mittels der genannten Netview-Tasks kann also die interne Automation realisiert werden. Bild 5 zeigt die Stufen zur internen Automation.

Externe RZ-Automation mit dem IBM-Tool ISCF

ISCF ist ein IBM-Produkt zur externen Automation verschiedener Systemfunktionen. ISCF automatisiert primär Funktionen wie :

- Warm-IPL,

- IPL,

- TOD (set or change time-of-day-clock) und

- Subsystem-Initialisierung als Grenzfall zwischen interner und externer Automation.

ISCF unterstützt die IBM-Betriebssysteme TPF, VM und MVS sowie die Systeme 4341, 4381, 308X, 309X. ISCF kann die nachfolgenden Funktionen jedoch nicht automatisieren:

- Target-System Power on,

- Target-System Power off und

- Press IML-Load-Key.

Das oben genannte Produkt ergänzt die Netview-Automatisierungsmöglichkeiten hauptsächlich durch "Start-up-Funktionen". Das kontrollierende und das kontrollierte System, zum Beispiel IBM 3090, werden via IBM/PC oder PS/2 verbunden. ISCF-PC läuft unter PC-DOS. Teile der ISCF-Funktionen laufen jedoch auch im Zielsystem unter VTAM und Netview. Zum Betrieb für die externe Automation mit ISCF werden die in Abbildung 6 dargestellten Komponenten benötigt.

Bild 7 zeigt eine Beispielkonfiguration, die mit Netview und ISCF automatisiert werden kann. Auf der linken Seite der Grafik sind die zu installieren den IBM-Produkte aufgeführt. Auf der rechten Seite wurden die nötigen Systemdefinitionen, also die logische Konfiguration und Parameter für die Kommunikation zwischen den Systemen, dargestellt.

Das ISCF-PC-Umfeld verhält sich in einer SNA-Konfiguration wie ein PU-Typ 2 mit einer LU (PC oder PS/2). Unter VTAM arbeitet ISCF wie eine normale VTAM-Applikation.

Die Installation von ISCF auf dem Mainframe kann einfach realisiert werden. Die Reihenfolge für die Installation ist:

- load ISCF on DASD,

- link-edit into Netview-Lib.,

- define a Command to Netview,

- define a Task to Netview,

- define ACB (ISCF als VTAM-Application),

- install Sample-Clist, zum Beispiel für automatisches IPL oder für automatisches IML.

Alle Verbindungen zum Target- und zum Focal-Point-System (Master System) sind Terminalemulationen, die durch einen Screen-Handler, der die Funktionen zum Erkennen von Messages, Löschen des Screens, zur Entgegennahme von Kommandos und deren Weiterleitung, Bereitstellung von Statusmeldungen über Interfaces, zum Beispiel Emulator. Card-Interface etc. bereitstellt, im PC ausgeführt werden. Verschiedene Konsoltypen haben verschiedene Screen-Handler.

Die Installation von ISCF-PC ist einfach

Auch die Installation von ISCF-PC ist denkbar einfach. Die Ablaufreihenfolge ist:

- Installation der Emula-Emulationskarten,

- Konfigurierung des Typen 2,

- Installation von Netview-PC (für NON-SNA-Device-Integration und Netview-Host-Kommunikation),

- Definition des ISCF-PC-Definition-File" und

- Aufbau der physikalischen Koax-Verbindungen.

In dem ISCF-Definition-File werden unter anderem folgende Parameter bestimmt:

- Set password,

- Define ports,

- Allocate buffers,

- Assign active ports,

- Enable ports und

- Power-on the ISCF-port.

Steuerung kann vom Wohnzimmer aus erfolgen

Der ISCF-Dataflow wird im Netview-Umfeld mit Kommands gesteuert, beispielsweise mit SENDISCF TEST S POWERON. SENDISCF ist der Command, TEST der ISCF-Task-Name, den Netview kennt, S ist die Port-ID und POWERON die gewünschte ISCF-Systemfunktion. Als weiteres Beispiel kann IPL CP1 400 dienen: Mit dieser ISCF-Anweisung ist es möglich, im Rahmen der externen Automation unter Netview via ISCF das IPL für den Prozessor 1 mit der IPL-Adress 400 (Adresse der Platte beim Host mit dem IPL-Programm) durchzuführen beziehungsweise zu starten. Diese Funktion kann zum Beispiel auch ein Operator mit einem PC von zu Hause starten.

Somit verlegt ISCF mit Netview Steuerung und Überwachung aller Systemfunktionen, etwa einer MVS/ESA-Konfiguration mit allen Subsystemen, in das Wohnzimmer des Operators. Eine Betriebsart die hauptsächlich an Abenden und Wochenenden genutzt werden sollte beziehungsweise wird. Via ISCF können aber nicht nur Betriebssystem-Funktionen in das Wohnzimmer verlagert werden. Auch komplexe SNA-Netze steuert dieses IBM-Produkt. Ein Beispiel für die Aktivierung einer VTAM-LU: VARY NET, ACT, ID = LU. VTAM schickt eine Meldung über den erfolgreichen Session-Start der LU im SNA-Netz, zum Beispiel EANO451 TEST SESSION NOW OPEN WITH LU TESTPC.

Um den vollen Funktionsumfang und sämtliche Einsatzmöglichkeiten sowie die interne Ablauflogik, beispielsweise die Kommunikation von ISCF mit Netview und VTAM oder MVS/ESA, zu verstehen, sind detailierte IBM-Systemkenntnisse erforderlich.

IBM sollte meiner Meinung nach für ISCF eine komfortablere Bedieneroberfläche schaffen. Die Bedeutung der ISCF-Funktionen zusammen mit Netview schätze ich sehr hoch ein.

Projekttips für die individuelle Automation

Bild 8 zeigt zwei ISCF-Oberflächen "ISCF-General-Function-Selection" und ISCF-Programm-Load-Function" unter einem ISCF-Screen-Handler.

Planen Sie die Durchführung Ihrer individuellen CNM-Projekte in Phasen und involvieren Sie unbedingt rechtzeitig Operating beziehungsweise AV.

Das Automatisierungskonzept sollte, falls es auf den hier behandelten Produkten basiert, SAA-konform, das heißt systemübergreifend, portierbar und durchgängig sein. Nur so sichern Sie langfristig Ihre Investitionen.

Vor der Realisierung des TP-Leitstandkonzeptes sollte die nachfolgende Vorgehensweise (Grobleitfaden) eingehalten werden:

- Problemerkennung,

- Definition der Projektziele,

- Auswahl geeigneter Mitarbeiter, Tools, Methoden und Controlling-Konzepte,

- Planung und Durchführung der Ausbildung für die involvierten Mitarbeiter,

- Definition des Tätigkeitsumfeldes (Stellenbeschreibung) im TP-Leitstand,

- Projektrealisierung basierend auf einem TP-orientierten Engineering-Modell,

- permanenter Soll-Ist-Vergleich und

- Test, Produktion, Dokumentation und eventuell Modifikation.

Die Projektschritte können nur dann eingehalten werden, wenn die Analyse der vorhandenen Informationsquellen gründlich vorbereitet beziehungsweise durchgeführt wurde.

Verwenden Sie deshalb unbedingt die bereits mit Netview, ISCF, MVS etc. mitgelieferten IBM-Tools, wie zum Beispiel:

- vorhandenes Netview-Clist-Konvertierungsprogramm für die Umsetzung von Clist in REXX,

- Clist- beziehungsweise REXX-Starter-Set und

- Beispielprozeduren, die mit Netview ausgeliefert werden.

Für den praktischen Betrieb empfehle ich des weiteren mindestens zwei Netviews pro Host (ein Automatisierungs-Netview und ein CNM-Netview). Das Automatisierungs-Netview läuft mit einer höheren Priorität und steuert die Betriebssystemorientierten Systemfunktionen. Das CNM-Netview hat eine niedrigere Priorität, es sorgt für die reine Netzautomation und führt alle CNM-Funktionen durch. Die Bedienerkonsolen sollten zu einer zentralen Systemsteuerung zusammengeführt werden. Dies kann im Netview mit einem speziellen Unterprogramm (TAF Terminal-Access-Facility) problemlos organisiert beziehungsweise realisiert werden.

Keine Realisierung ohne Methodik

Für jede Automatisierungsfunktion muß unbedingt eine Backup-Lösung verfügbar sein. Des weiteren müssen alle Netview-REXX-Prozeduren und sonstigen Automationsprozesse dynamisch veränderbar beziehungsweise deaktivierbar sein. Laut einer ptm-internen Netview-CNM-Studie sollten die folgenden Zeiten für die Realisierung der Projekte als Richtwert dienen:

- Definition der vorhaben zwei bis vier Monate,

- Auswahl des Engineering-Modelles einen Monat,

- Installation und Implementierung einen Monat,

- Ausarbeitung des MPF-Konzeptes zwei Monate,

- TP-Leitstandkonzeption (SAA-konform) zwei Monate,

- Entwicklung der Prozeduren inklusive einer zukunftsorientierten Clist-Methodik zwei bis drei Monate und

- Einführung des operatorlosen Betriebes inklusive Training aller Mitarbeiter und Dokumentation zwei bis drei Monate.

Selbstverständlich können die Wert je nach Umfang beziehungsweise Komplexität des jeweiligen Systemumfeldes abweichen. Vor einer planlosen Realisierung ohne Methodik möchte ich jedoch ausdrücklich warnen.

Durch Netview wird Operating reduziert

Anwender von Netview, REXX und ISCF können bei professioneller Vorgehensweise die Operatoreingriffe im MVS-Umfeld um zirka 98 Prozent reduzieren.

Die permanente Überwachung der hochsensiblen Anwendungen, also zeit- und ereignisgesteuertes, automatisiertes Reagieren, kann mit wenigen Ausnahmen problemlos dem IBM-Produkt Netview anvertraut werden. Die Gesamtkontrolle über alle Wiederanlaufverfahren sollten jedoch einer Hyperprozedur auf Basis von künstlicher Intelligenz und

hochqualifizierten Mitarbeitern im TP-Leitstand gemeinsam übertragen werden.

Meiner Meinung nach werden CNM-Produkte bereits in naher Zukunft überwiegend auf Basis von künstlicher Intelligenz eingesetzt.

Auch in diesem Umfeld bietet IBM bereits zwei Produktgruppen, und zwar die Hochsprache der 5. Generation und SAA-konforme Systemdienste, an. Die bestehenden REXX-Automatisierungsprozesse werden wohl bereits in wenigen Jahren veraltet sein. Effiziente Ereignissteuerung muß nach den Erkenntnissen der modernen Organisationsforschung nämlich auf einer DBMS-Basis aufbauen. Dies ist bei Netview bis heute nicht der Fall. Aber ich bin überzeugt, daß der Marktführer im Rahmen von SAA die entsprechenden Voraussetzungen noch schaffen wird.

Einsatz von Netview auf MVS-Repository-Basis

"Architekturen leben", dies hat IBM in letzter Zeit oft genug bewiesen. Im Rahmen des SAA-Kommunikations-Layers wird Big Blue meiner Meinung nach bereits in einem Jahr das CNM-Umfeld auf Repository-Basis vorstellen. Der MVS-Repository-Manager soll in der Endausbaustufe auch alle Status-Informationen bezüglich Netzwerk, Betriebssystem und Monitorumfeld verwalten. Das MVS-Repository basiert auf DB2-Tabellen. Netview basiert jedoch noch auf VSAM-Datenbeständen.

DB2, Netview und MVS-Repository-Manager sind SAA-konforme Produkte. Zwischen den diesen Produkten besteht bis heute noch eine Unverträglichkeit auf der Datenbasis. Die Entwicklung bei den MVS-Subsystemen bleibt im Rahmen von SAA deshalb weiterhin in Bewegung. Die bereits getätigten Investitionen im Netview-Umfeld betrachte ich nach dem bisherigen Stand der Dinge trotzdem als gesichert. Der Portierungsaufwand für die bereits vorhandenen SAA-konformen Automatisierungsprozesse hält sich in Grenzen. Den Aufwand für die Migration der Netview-Automaten auf Basis des MVS-Repository-Managers mit DB2 kann man heute noch nicht absehen. Bleibt die Frage nach der SAA-Konformität der MVS-Anwender, die keinen DB2-Einsatz geplant haben. Wahrscheinlich soll die REXX-Nachfolgeprozedur für die Durchgängigkeit von DB2 zu Nicht-DB2 sorgen.

Thema noch jahrelang aktuell

Ich darf betonen, daß es sich hierbei um meine persönliche Einschätzung und nicht um eine Ankündigung der IBM handelt. Unter besonderer Berücksichtigung aller Punkte sowie der UNIX-Entwicklungstrends und des Netzwerk-Managements im ISO-OSI-Umfeld wird das Thema "System-Automation mit IBMs Netview" noch jahrelang hochaktuell sein. Besonders der Repository-Ansatz sowie der Einsatz von künstlicher Intelligenz im Umfeld rationaler Datenbanken bei der Netzwerkautomation sollte bei strategischen DV-Entscheidungen rechtzeitig berücksichtigt werden.

*Walter Melchhardt ist geschäftsführender Gesellschafter der ptm-GmbH, EDV-Systemforschung, angewandte Informatik und EDV-Training in Starnberg