Im ersten Teil dieser Artikelserie werden IBMs Telekommunikations-Strategie im Rahmen von SAA vorgestellt und Gründe für die Automatisierungstechniken mit Netview, RESS und ISCF vorgestellt. Im zweiten Teil der Serie folgt die Einführung in Nachrichtenanalyse, konzeptionelles Design von Netview-Automaten und Realisierung der externen Automation mit ISCF.

Empirische Untersuchungen haben bewiesen, daß der Einsatz hochentwickelter DV-Systeme und Tools als Wettbewerbsfaktor zur Realisierung innovativer Marktchancen gesehen werden sollten. Firmenspezifischen RZ-Automatisierungsvorhaben kommt eine besondere Bedeutung zu. IBM hat im Rahmen von SAA drei strategische Produkte zur entsprechenden systemübergreifenden RZ-Automation vorgestellt. Walter Melchhardt stellt in dieser dreiteiligen Artikelserie Aufbau, Arbeitsweise und Funktionsumfang der IBM-Produkte Netview, REXX und ISCF vor.

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 Güte der Serviceleistungen, die durch das Kommunikationsnetz realisiert werden, bestimmen entscheidend Netzwerk-Management-Tools und ein gut organisiertes TP-Leitstand-Umfeld. Empirische Untersuchungen führten zur Erkenntnis, daß es eine begrenzte Anzahl von Faktoren ist, die Unternehmen flexibler, innovativer und damit erfolgreicher machen .

Zu den wichtigsten Erfolgsfaktoren zählen klar definierte Ziel-Kontroll-Systeme, eine strategieorientierte Organisation und der Einsatz marktnaher Informations- und Kommunikationssysteme. Der effiziente Einsatz hochentwickelter DV-Systeme und Tools sollte von der Unternehmensleitung beziehungsweise den DV-Führungskräften vorwiegend als Wettbewerbsfaktor zur Realisierung innovativer Marktchancen gesehen werden. Hierbei ist jedoch Vorsicht geboten:

"Be aware that when endusers and system-engineers develop computer based information systems they can repeat all the mistakes made in traditional MIS-development."

Diesem Mangel kann und muß durch die rechtzeitige Ausbildung der betroffenen Führungskräfte und DV-Mitarbeiter begegnet werden. Die Grundlage für die firmenspezifischen Automatisierungsvorhaben schaffen hochqualifizierte, gut motivierte Mitarbeiter, geeignete Tools, praxiserprobte Engineering-Modelle sowie das Engagement der Unternehmensleitung. Ein straffes Projekt-Management ist bei der Realisierung von Automatisierungsprojekten unerläßlich. Die RZ-Automation (einschließlich "Netview-" oder "Netmaster" von System Center) sollte als integraler Bestandteil einer strategieorientierten DV-Organisation verstanden werden.

IBM hat in den letzten Jahren mehr als 50 neue und erweiterte Produkte der Telekommunikation angekündigt. Primär haben die oben genannten Produkte zum Ziel, daß Telekommunikations-Anwender ihre homogenen und heterogenen Netzwerke einfacher, sicherer und effektiver betreiben beziehungsweise verwalten können. IBMs Angebot für wachsende Anforderungen der Telekommunikations-Anwender orientiert sich in letzter Zeit verstärkt an der vereinfachten Einführung der herstellerübergreifenden Konnektivität auf der Basis internationaler Normen und der Entwicklung erweiterter Netz-Management-Produkte im Umfeld des Netzwerk-Management-Tools Netview.

Die Produkte der herstellerübergreifenden Konnektivität schließen zwei Komponenten ein, die den Vorteil von Open Systems Interconnection (OSI) nutzen. Die Kommunikation über höhere OSI-Protokolle wurde für Anwendungen in einer SAA-Umgebung (System-Anwendungs-Architektur) verfügbar gemacht. Die zwei neuen Programme für die Systeme der IBM-Familie /370 sind:

- OSI-Communication Subsystem (ermöglicht, daß IBM-Systeme mit Systemen anderer Hersteller in heterogenen Netzen kommunizieren) und

- OSI-File-Service (lizenziertes Programm zur Erzeugung, Übertragung und Verwaltung von Dateien in heterogenen Netzen).

Neben den oben genannten Produkten wurde kürzlich ein neues Programm angekündigt, das die TCP/IP-Protokolle (Transmission Control Protocol/Internet Protocol) unter den IBM-Betriebssystemen MVS/ 370, MVS/XA und MVS/ESA unterstützt.

Zusätzlich zu den bereits erwähnten Neuentwicklungen wurde eine erweiterte Version (V.3) von IBM-Netview vorgestellt. Dieses Programm dient zur zentralen Überwachung Kontrolle, Steuerung und Automation von heterogenen Netzen.

Die Telekommunikations- und Netzwerk-Management-Strategie der IBM orientiert sich auch im Netview-Umfeld an internationalen Standards (OSI). SNA-Netview-Architekturen beziehungsweise offene Systeme für Lösungen mit unterschiedlichen Herstellern.

IBM hat erkannt, daß es für die Anwender und Kunden grundsätzlich zwei Wege gibt, Netz-Management-Systeme zu entwickeln beziehungsweise einzusetzen:

- Benutzung von De-facto-Industriestandards (zum Beispiel Netview von IBM) oder

- Implementierung von OSI-Protokollen beziehungsweise OSI-konformen Produkten.

In dieser Ausarbeitung soll dem Leser der erste Ansatz vorgestellt werden. Im Vordergrund stehen unter anderem der Funktionsumfang der erweiterten Netview-Produktfamilie, Vollautomation von heterogenen Netzen mit REXX (Restructured Extended Executor) und ISCF (Inter System Control Facility) unter Netview sowie praktische Hinweise und Projekttips für die Realisierung des SAA-konformen TP-Leitstandes im Rechenzentrum. Aber auch ein Exkurs in die strategische Bedeutung des MVS-RepositoryManagers (eventuell zukünftiges Herzstück aller Netzwerk-Management-Funktionen) wird geboten.

Gründe für die SAA-konforme RZ-Automation

Eine automatisierte SAA-konforme Konsolbedienung mit Netview wird aus mehreren Gründen angestrebt. Beispiele hierfür sind unter anderem Überwachungsprobleme bei komplexen Cross-Domain-Netzen, der Einsatz zahlreicher DC-Systeme wie zum Beispiel CICS oder IMS/DC und permanente Bedienerüberlastung. Auch Probleme bei der Bewältigung der Nachrichtenflut an der Master-Konsole, Personalmangel, finanzielle Aspekte und die Komplexität einzelner Subsysteme wie zum Beispiel VTAM, DB2 und JES3 fallen hier relevant ins Gewicht.

Das permanente Wachstum des jeweiligen Systemumfeldes zwingt ebenfalls zur automatisierten Konsolbedienung im TP-Leitstand des Rechenzentrums.

Dieses Wachstum ergibt sich aus der Möglichkeit der Konfiguration logischer Rechner, der Tendenz, pro Online-Anwendung einen Monitor einzusetzen, automatisiertem Speicher-Management DFSMS mit ACS-Routinen, Einsatz von durchschnittlich 40 Fremdprodukten zur Systemoptimierung, Implementierung mehrerer DB/DC-Systeme für Test- und Produktionsumgebungen und aus dem steigenden Einsatz von Systemen zur "Remote-Fehlerdiagnose" im Netz. Die Aufzählung könnte beliebig fortgesetzt werden. Die Automatisierung von RZ- und Netzfunktionen tut also mit Sicherheit not. Welche Systemfunktionen unter anderem automatisiert werden sollten, zeigt Bild 1.

Die SAA-konforme Automation von Jobs, Subsystemen, Betriebssystemen, Netzwerken, Anwendungen und Hardwarefunktionen basiert auf der Prozedursprache "REXX". Prozeduren, die damit entwickelt wurden, können laut IBM als SAA-konform bezeichnet werden. Die problemlose Portierung von REXX-Prozeduren (zum Beispiel vom PC auf einen Großrechner vom Typ IBM 3090 mit MVS/ESA) wird im Rahmen von SAA gewährleistet.

Meiner Meinung nach sollten jedoch die REXX-Automaten (Prozeduren zur Systemautomation, die mit REXX geschrieben wurden) stets auf dem eigentlichen Zielsystem entwickelt werden.

Wirklich problemlose Portierungen über mehrere Architekturen hinweg sind - auch im Rahmen von SAA - heute noch nicht die Regel. Die von IBM zur Verfügung gestellten Möglichkeiten der systemübergreifenden RZ-Automation sollten dennoch nicht unterschätzt werden. Mit Netview-Host, Netview-PC, Netview-Distribution-Manager und REXX können bereits heute mehr als 95 Prozent aller Systemfunktionen im MVS-Umfeld automatisiert werden. Auch bei der Portierungsmöglichkeit von Automaten zur Systemautomation

haben die Mitarbeiter in den Labors der IBM fortschrittliche Lösungen im Rahmen der SAA-Kommunikations-Dienste und SAA-Systemdienste konzipiert beziehungsweise realisiert.

Organisationsforschung und angewandte Informatik kennen zwei Arten der Systemautomation: Interne und externe Automation.

Bei der internen Automation laufen alle Funktionen (Prozeduren, Anwendungen auf Basis der Künstlichen Intelligenz, etc. unter Kontrolle des Betriebssystems. Ein Beispiel hierfür ist die Automation von Datenbanken wie zum Beispiel DB2 oder Monitorsystemen wie CICS IMS/DC und TSO/E.

Bei der externen Automation erfolgt die Bereitstellung der Steuerungsfunktionen über einen externen Rechner. Externe Techniken kommen immer dann zur Anwendung, wenn die internen Prozesse nicht aktiv sind (zum Beispiel externe IPL-Funktion zur Aktivierung des Betriebssystemes). Externe Techniken sind alle, bei denen Eingriffe in die Systemkonsole notwendig sind, weil von innen auf keine Masterkonsole zugegriffen werden kann. Zirka 90 Prozent der Automation werden durch interne Prozesse (zum Beispiel auf Basis von REXX unter Netview oder auf Basis von NCL unter Netmaster und so weiter) abgedeckt. Die restlichen zehn Prozent decken externe Prozesse (zum Beispiel mit dem IBM-Produkt "ISCF") ab. Die Automation der externen Funktionen stellt an die betroffenen DV-Mitarbeiter und Projektleiter enorm hohe Anforderungen.

Ich empfehle hierzu die enge Zusammenarbeit mit dem jeweiligen Hersteller. Die oben genannten Automatisierungstechniken basieren auf der sogenannten Ereignisverarbeitung. Sie basiert im Rahmen von SAA, Netview und REXX primär auf der Basis von Systemnachrichten. Abhängig von der jeweiligen Nachricht, löst Netview geeignete Aktionen, gesteuert über REXX-Prozeduren, aus. Diese Aktionen führen im positiven Falle zum gewünschten Systemverhalten. Es kann nur dann hergeleitet werden, wenn der Lebenszyklus des zu automatisierenden Umfeldes bekannt ist. Des weiteren bedarf es einer sorgfältigen System und Nachrichtenanalyse. Der normale Lebenszyklus eines DV-Systemes (zum Beispiel IBM 3090) stellt sich wie folgt dar:

1. Power on / Hardware

2. System-Start / Software

3. Betrieb /Hardware und Software

4. System-Stop / Hardware

5. Power off / Hardware

Der oben genannte Lebenszyklus kann mit der neuen Netview-Version (3) zusammen mit ISCF und REXX problemlos automatisiert werden. Bild 2 zeigt die Grundgedanken zur Ereignisverarbeitung mit Netview.

Als Schnittstelle zwischen REXX-Prozedur und Betriebssystem fungiert jeweils ein Subsystem-Interface (SSI). Es gibt somit zwei SSIs. Ein SSI gehört zum Betriebssystem (hier MVS). Das andere Subsystem-Interfase läuft unter Netview.

Ablauflogik bedingt Projektphasen

Die anfallenden Nachrichten werden zunächst anhand einer Nachrichtentabelle analysiert. In Form von Regeln läßt sich feststellen, welche Funktion diese Nachricht auslösen soll (zum Beispiel wird unterdrückt, wird an eine REXX-Prozedur übergeben,

sofort der Operator informiert etc.).

Soll basierend auf der jeweiligen Nachricht ein SAA-konformer Automat (REXX-Prozedur unter Netview) aufgerufen werden, kommuniziert das SSI des Betriebssystems mit dem SSI des Netview und tauscht Befehle beziehungsweise Daten aus. Das SSI des Netview ruft die zugehörige Netview-Task auf. Unter Steuerung der jeweiligen Task wird nun die entsprechende REXX-Prozedur aufgerufen.

Bild 3 zeigt diesen Sachverhalt in vereinfachter Form.

Bedingt durch die oben genannte Ablauflogik sollte die Automation mit Netview meiner Meinung nach in folgenden Projektphasen durchgeführt werden:

1. Systemanalyse durchführen,

2. Nachrichten analysieren,

3. Routing-Konzept für die Nachrichten erstellen,

4. Konzept zur optimalen Weiterleitung der Nachrichten an die Automatisierungsfunktion ausarbeiten,

5. Ausarbeitung von Bibliothekskonzepten,

6. Entwicklung der REXX Prozeduren unter Netview sowie

7. Test, Betrieb und Dokumentation beziehungsweise Modifikation.

Die Projektphasen sollten unbedingt auf einem TP-Engineering-Modell basieren. "Ohne Methodik ist jedes Automatisierungsprojekt mit Sicherheit zum Scheitern verurteilt."

(wird fortgesetzt)

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