Wir sprechen täglich mit Kunden über die Herausforderungen, die mit der Verwaltung von hohem Volumen verbunden sind Großrechner Umgebungen, in denen Effizienz und Kostenkontrolle oberste Priorität haben, und wir wissen, dass Kapazitätsfragen nicht immer nur auf hohe Kosten abzielen Arbeitslast Volumen. Es geht um zu viel Arbeitslast, die sich im selben Fenster auf derselben Ressource konzentriert.
Ressourcenkonflikte entstehen, wenn:
- Zu viele Batch-Aufträge getroffen GP CPU gleichzeitig
- um dieselben begrenzten Ressourcen konkurriert wird
- Verursacht Verzögerungen, Service-Level-Agreements verpasst und überschneidet sich online
JOPAZ gleicht die Waage aus, indem es das Schwere neu verteilt COBOL Batch-Workloads auf effizientere Engines verlagern, wodurch das Verhalten dieser Spitzen geändert wird, ohne die Anwendungen zu berühren.
Was ändert sich: Ausführungspfad, CPU-Verhalten und LaufzeitumgebungJVM)
Was nicht geht: COBOL-Quellcode, Daten, Planungsframework und Ausgaben
Unten betrachten wir, wie drei große Unternehmen aus verschiedenen Branchen unglaubliche CPU-Einsparungen erzielten und gleichzeitig ihre Contention-Probleme dauerhaft lösten.
1. Mitglieder-Service-Organisation: Bewältigung des R4HA-Spitzenbedarfs
Für eine große nordamerikanische Mitgliedsorganisation, die Automobil-, Reise- und Finanzdienstleistungen anbietet, war die Schaffung von Vorhersehbarkeit eine Top-Priorität. Ihre Stapelverarbeitung die Kosten des Rolling 4-Hour Average (R4HA) in die Höhe treiben, was einen dringenden Bedarf an besserer Arbeitslastverteilung schafft.
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 zu Java-Bytecode
- Dieser Code wurde dann auf der Unix System Services JVM ausgeführt
Dies ermöglichte ihnen, IBM zu nutzen ZIIP auslagern. Engines, die den Spitzen-GP-Druck durch Umverteilung der Ausführung reduzieren
Das Setup:
- COBOL Db2 Umwelt
- Die Ergebnisse wurden auch mit einer sequenziellen Datei getestet
Die Ergebnisse:
Die Auswirkung war unmittelbar und erheblich:
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
- Am ursprünglichen Quellcode mussten keinerlei Änderungen vorgenommen werden

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 Unternehmen für Zahlungstechnologie jährlich Milliarden von Transaktionen ab. Im Gegensatz zu den anderen Beispielen handelte es sich hierbei um ein reines VSAM eine Umgebung ohne herkömmliche Datenbanken, in der außergewöhnlich große und komplexe Anwendungen zum Einsatz kamen.
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, Modernisierung muss nicht zwangsläufig eine riskante, jahrelange Migration in die Cloud bedeuten. Die Herausforderung besteht nicht darin, ob COBOL funktioniert. Es geht vielmehr darum, ob eine kleine Anzahl von Aufträgen in kritischen Zeitfenstern einen unverhältnismäßig hohen Druck verursacht. Anstatt ihre Workloads zu ändern – sie neu zu schreiben, neu zu planen oder zu entfernen –, gewinnen Unternehmen fast ihre gesamte COBOL-CPU-Auslastung im Batch-Betrieb zurück, indem sie den Ausführungsort ändern.
Ob Sie mit Db2, VSAM, Adabas… oder sequenzielle Dateien: Die Ergebnisse zeigen durchweg eine CPU-Entlastung von über 801 TP18T und oft sogar bis zu 971 TP18T, während Ihre bewährte Geschäftslogik dabei unverändert bleibt.