Funktionen

Wie globale Unternehmen die Mainframe-Kapazitätskrise lösen: Drei Praxisbeispiele 

Große Unternehmen erzielen bis zu 97 Prozent CPU-Einsparungen bei Batch-COBOL-Workloads - ganz ohne Änderungen am Source Code. Erfahren Sie, wie führende Organisationen Lastspitzen beherrschen, Kapazitäten zurückgewinnen und Ressourcenengpässe durch nahtlose Workload-Verteilung lösen.

Wir sprechen täglich mit Kunden über die Herausforderungen beim Betrieb hochvolumiger Mainframe-Umgebungen, in denen Effizienz und Kostenkontrolle oberste Priorität haben. Dabei wissen wir: Kapazitätsprobleme entstehen nicht immer nur durch ein hohes Workload-Volumen. Häufig liegt die Herausforderung darin, dass zu viele Workloads im selben Zeitfenster auf dieselben Ressourcen zugreifen. 

Ressourcenkonflikte entstehen, wenn: 

  • Zu viele Batch-Jobs beanspruchen gleichzeitig die GP-CPU
  • um dieselben begrenzten Ressourcen konkurriert wird 
  • Dies führt zu Verzögerungen, SLA-Verletzungen und Überschneidungen mit Online-Workloads 

JOPAZ sorgt für ein neues Gleichgewicht, indem es ressourcenintensive COBOL-Batch-Workloads auf effizientere Engines umverteilt und so das Verhalten dieser Spitzenlasten verändert, ohne die Anwendungen zu verändern. 

Was ändert sich: Ausführungspfad, CPU-Verhalten und Laufzeitumgebung (JVM) 

Was nicht: COBOL-Quellcode, Daten, Planungsframework und Ausgaben 

Im Folgenden zeigen wir, wie drei große Unternehmen aus unterschiedlichen Branchen enorme CPU-Einsparungen erzielt und ihre Ressourcenkonflikte dauerhaft gelöst haben.. 

Join 15,000+ other mainframe users receiving expert advice and industry news in their inboxes.

1. Mitgliederservice-Organisation: Den R4HA- Peak meistern 

Für eine bedeutende nordamerikanische Mitgliederorganisation, die Dienstleistungen in den Bereichen Automobil, Reisen und Finanzen anbietet, hatte die Schaffung von Planbarkeit höchste Priorität. Die Batch-Verarbeitung trieb die Kosten für den Rolling 4-Hour Average (R4HA) in die Höhe und machte eine bessere Verteilung der Workloads dringend erforderlich. 

Die Strategie:

Das Unternehmen wandte sich an JOPAZ, um die eigentliche Ursache für die Konflikte bei der Arbeitslast zu beheben. 

  • Sie kompilierten COBOL Batch-Quellcode in Java-Bytecode 
  • Dieser Code wurde dann auf der Unix System Services JVM ausgeführt 

Dies ermöglichte ihnen, IBM zIIP-Engines zu nutzen und den Spitzen-GP-Druck durch Umverteilung der Ausführung zu reduzieren 

Das Setup: 

  • COBOL Db2-Umgebung  
  • Die Ergebnisse wurden auch mit einer sequenziellen Datei getestet 

Die Ergebnisse:

Die Auswirkung war unmittelbar und beträchtlich: 

Ohne JOPAZ 

  • 47,96 Sekunden CPU-Zeit 

Mit JOPAZ 

  • 2,47 Sekunden CPU-Zeit (Reduzierung um 95 Prozent) 
  • 94.8 Prozent: COBOL-CPU-Einsparungen pro Batch 
  • Wiederverwendete MSS für neue Arbeitslasten 
  • Es waren keine Änderungen am ursprünglichen Quellcode erforderlich 

2. Energieversorger im Einzelhandel: Investitionen in Effizienz

Ein führender nordamerikanischer Energieversorger mit einer großen Db2-Präsenz benötigte eine strategischere Nutzung seiner vorhandenen Verarbeitungsressourcen.

Die Strategie:

Ähnlich wie im ersten Fall wandte sich der Kunde an JOPAZ, um seine Batch-COBOL-Prozesse für die Ausführung auf seiner zIIP-Engine vorzubereiten. In diesem Fall stand der zIIP-Engine nur begrenzte Kapazität für die Nutzung durch JOPAZ zur Verfügung, sodass nach den erfolgreichen ersten Ergebnissen eine zweite zIIP-Engine hinzugefügt wurde.

Das Setup:

  • COBOL Db2-Umgebung
  • Wir haben drei Stapelverarbeitungsprozesse verwendet. Jeder dieser Stapelverarbeitungsprozesse hatte COBOL-Programme, die auf Db2 zugegriffen haben, und jeder Prozess hatte mehrere Schritte.

Die Ergebnisse:

Ohne JOPAZ

  • 2:26,27 Minuten CPU-Zeit
  • 14:10 Uhr

Mit JOPAZ – Einzel-zIIP-Engine

  • 14,4 Sekunden CPU-Zeit (Reduzierung um 90 Prozent)
  • 5:44 Minuten Spielzeit (Rückgang um 60 Prozent)
  • 76 Prozent – COBOL-CPU-Einsparungen bei Batch-Verarbeitung

Mit JOPAZ – 2 zIIP-Prozessoren

  • 6,97 Sekunden CPU-Zeit (Reduzierung um 95 Prozent)
  • 8:40 Minuten (Rückgang um 39 Prozent)
  • 96,71 TP18T – COBOL-CPU-Einsparungen pro Batch

Die anfänglichen Tests waren so vielversprechend, dass der Kunde sofort dedizierte Ressourcen beauftragte, um das Projekt bis zur Fertigstellung voranzutreiben. Am wichtigsten ist, dass dies ohne Änderungen am Code oder an der Geschäftslogik erreicht wurde.


3. Zahlungsabwicklungstechnologie: Bewältigung von Komplexität und VSAM

In Südamerika wickelt ein führendes Zahlungsdienstleistungsunternehmen jährlich Milliarden von Transaktionen ab. Im Gegensatz zu den anderen Beispielen handelte es sich hier um eine reine VSAM-Umgebung ohne traditionelle Datenbanken, die aussergewöhnlich grosse und komplexe Anwendungen aufwies.

Die Strategie:

Da sich in ihrem Rack bereits vier ungenutzte zIIP-Prozessoren befanden, sah das Unternehmen in JOPAZ die perfekte Möglichkeit, GP-Kapazität zurückzugewinnen. Sie begannen damit, ein komplexes Programm mit 54.000 Zeilen neu zu kompilieren. Mit den Worten unseres Kunden: „Wenn JOPAZ diese Anwendung bewältigen kann, kann es alles bewältigen.“

Das Setup:

  • 35% des gesamten Arbeitsaufkommens entfällt auf COBOL-Batch-Verfahren
  • Reine VSAM-Umgebung ohne traditionelle Datenbanken
  • 4 ungenutzte zIIP-Prozessoren verfügbar

Die Ergebnisse:

  • 97%: Reduzierung der COBOL-CPU-Auslastung bei Batch-Verarbeitungen
  • Maximierte den Mainframe-ROI, indem mehr Kapazität aus dem bestehenden Platz herausgeholt wurde
  • Der Geschäftsbetrieb wurde wie gewohnt ohne Unterbrechung aufrechterhalten

Das Endergebnis

Wie unsere Kunden bestätigen können, muss Modernisierung nicht bedeuten, dass eine riskante, jahrelange Migration in die Cloud durchgeführt wird. Die Herausforderung besteht nicht darin, ob COBOL funktioniert. Es geht darum, ob eine geringe Anzahl von Jobs während kritischer Zeitfenster unverhältnismäßigen Druck verursacht. Anstatt ihre Workloads zu ändern – umzuschreiben, neu zu planen oder zu entfernen – holen Unternehmen fast ihren gesamten Batch-COBOL-CPU-Bedarf zurück, indem sie ändern, wo diese ausgeführt werden.

Ganz gleich, ob Sie mit DB2, VSAM, Adabas oder sequenziellen Dateien arbeiten – die Ergebnisse zeigen durchweg eine CPU-Einsparung von über 80%, oft sogar bis zu 97%, und das bei vollständiger Beibehaltung Ihrer bewährten Geschäftslogik.