?? 24x7 ?? Die Komplexität der Abläufe am Mainframe

Online-Betrieb VormittagMittag Systemnahe Software (z/OS, JES3, VTAM, TCP/IP, TSO) Nachmittag DB/2, MQ channels, div. ORA Gateways Viele CICSe Einige IMSe „Nicht störende“ Batchjobs Im Idealfall sollte der Online-Betrieb über 24 Stunden möglich sein. Während des Online Betriebs laufen folgende Komponenten auf dem System. Applikationen RZ Infrastruktur

Batch-Betrieb AbendMitternacht Systemnahe Software (z/OS, JES3, VTAM, TCP/IP, TSO) Frühmorgens DB/2, MQ channels, div. ORA Gateways „Störender“ Batch „Nicht störende“ Batchjobs Ohne „störende“ Batchjobs, (dazu bräuchte es einen Applikations- Redesign), gäbe es keine fehlende Verfügbarkeit von CICSen und IMSen. RZ Infrastruktur

Der zeitliche Übergang NachmittagAbendMorgen MitternachtFrühmorgen Systemnahe Software (z/OS, JES3, VTAM, TCP/IP, TSO) DB/2, MQ channels, div. ORA Gateways Viele CICSe Einige IMSe „Nicht störende“ Batchjobs Einige IMSe Viele CICSe Einzelne CICSe (einige sogar nur teilweise) und auch teilweise bestimmte Teile des IMS (REGIONSTOP/START) sind zu unterschiedlichen Zeiten unverfügbar. Wer kann nun wann online arbeiten? Applikationen RZ Infrastruktur

Einige Details Viele CICSe Einige IMSe Viele CICSe CICS Stoppzeitpunkt Fester Zeitpunkt Triggert Batchbeginn CICS Startzeitpunkt Variabler Zeitpunkt Getriggert durch Batchende Zeitliche Steuerung durch OPC/ESA, starke Abhängigkeit zum Batchverlauf (d.h. evtl. Unterschiede bei Ultimo etc.)

Durchschnitt und Streuung 18:30 Südafrika 20:00 Österreich, Belgien, Italien Part 1 20:15 Frankfurt 21:00 Schweiz 21:30 Spanien, Portugal, Niederlande, Schweden 22:00 Berlin 22:15 Italien Part 2 22:30 Frankreich 00:00 Belgien, Krefeld, KSL Landshut, Motorad Berlin Obige Tabelle ist ein Auszug und betrifft nur CICS.

Die Startzeiten Die ersten CICSe kommen bereits um ca. 01:00 Uhr wieder, die meisten um 04:30 Uhr bis 05:30 Uhr. Einige fallen nur eine halbe Stunde aus Einige fehlen ganze 8 Stunden (Schweiz) Sollzeitpunkt für Start: Teilweise 05:00 Uhr, andere: 07:00 Uhr Wenige Starts sind zeitgesteuert. Die meisten Starts sind batchabhängig

Was geschieht dazwischen? Viele CICSe Einige IMSe Viele CICSe CICS Stoppzeitpunkt Fester Zeitpunkt Triggert Batchbeginn CICS Startzeitpunkt Variabler Zeitpunkt Getriggert durch Batchende CICS: VSAM-Sicherungen, Image Copies der Datenbanken IMS: Warenbestände, Lieferlisten, Massenupdates, Auswertungen

IMS Datenbanken Ähnlich wie beim CICS: DB Stopp Trigger aus dem OPC, zeitgesteuert DB Start Trigger nach Ende des Batchablaufs Stopp/Start jedoch Projektbezogen 19:00 Uhr Stopp RP, ZF, ZX, LR, MS1900, IM1900 ZZ1900, DA1900 etc. Abhängigkeiten zum jeweiligen CICS und umgekehrt. Relation DB – TRAN – PROJEKT im OSIS

Japan NachmittagAbendMorgen MitternachtFrühmorgen DB StoppDB Start Gleiche Vorgehensweise, nur zeitverschoben. Batch Beginn ist Mittags (MEZ). Japan Batchfenster im CICS, IMS

Problematik: Wartungsfenster NachmittagAbendMorgen MitternachtFrühmorgen Systemnahe Software DB/2, MQ channels, div. ORA Gateways „Nicht störende“ Batchjobs Einige IMSe Viele CICSe Applikationen RZ Infrastruktur WARTUNGWARTUNG WARTUNGWARTUNG RZ Infrastruktur Wartung triff alle Nutzer des physischen Rechners. Wartung der Systemnahen Software (Betriebssystem-Updates etc.) triff mindestens alle Nutzer des logischen Rechners.

SYSPLEX NachmittagAbendMorgen MitternachtFrühmorgen z/OS PLEX (Insb. TCP/IP DDVIPA) DB/2 PLEX, MQ PLEX-fähig, ORA PLEX-fähig CICS Plexe IMS Plexe Batchjobs Applikationen Applikationen, SYSPLEX-fähig RZ Infrastruktur Die Wartung einzelner Komponenten ist möglich ohne die Gesamtverfügbarkeit zu verringern. Vorraussetzung: Ausreichende Leistungsreserven für die Lastübernahme sowie geeignetes Applikationsdesign. WARTUNGWARTUNG

FAZIT Durch die Migration von anderen Standorten wie Japan und USA wird die Definition ONLINE (unter Tags)  BATCH (in der Nacht) weiter aufgeweicht. Folglich wird es immer schwieriger in der gegebenen Systemlandschaft ein Wartungsfenster zu finden mit dem alle „leben können“. De Fakto ist zwar IVZ1 derzeit 24x7 verfügbar für „Online und Batch“ Verarbeitung. Es ergeben sich aber auf Grund der Komplexität der Systeme und festen Affinitäten von CICSEN zu bestimmten Rechnen große Probleme im Falle von Wartungs-Arbeiten am Wochenende oder auch bei ungeplanten Ausfällen Redundanz der Systeme und Auflösung der festen Affinitäten kann hier Abhilfe schaffen. Hierzu ist die Einführung von sysplexfähigen Subsystemen (DB2, IMS, MQS, CICS) und vor allem sysplexfähigen Applikationen erforderlich.