Im ersten Teil unserer Blog-Reihe zur Mainframe-Optimierung haben wir gezeigt, vor welchen Herausforderungen Unternehmen im z/OS-Betrieb stehen: Mainframes sind hochverfügbare Großrechnersysteme für die parallele Verarbeitung sehr großer Daten- und Transaktionsmengen – leistungsstark, aber auch sehr komplex. Hohe Lizenzkosten, alternde IT-Belegschaften und ständige Workload-Änderungen bedeuten, dass sich Unternehmen Ineffizienz nicht leisten können.
In diesem Beitrag wollen wir uns der Problematik des richtigen LPAR-Managements widmen.
Eine Herausforderung, die häufig entsteht, wenn belastbare Informationen, präzise Berechnungen und eine kontinuierliche Kontrolle fehlen. Genau hier setzen wir an und zeigen, woran sich erfolgreiches LPAR-Management in der Praxis des z/OS-Betriebs erkennen lässt.
Mainframe-Optimierung durch eindeutige Informationen
In unseren Performanceanalysen ist eine der zentralen Fragen, wie die z/OS-LPAR vom PR/SM versorgt wird. Einer der Hauptgründe für Ressourcenengpässe ist eine mangelhafte Versorgung des z/OS mit Prozessor-Ressourcen. Stimmen LPAR-Gewichte nicht, so kommt man schnell in die Situation, dass völlig unnötigerweise der WLM einzelne Service Classes bremsen muss. Im schlimmsten Falle handelt es sich dabei um geschäftskritische Workload. CICS- oder IMS-Transaktionen werden nicht mehr ordentlich bedient, im Db2 kommt es zu Timeouts.
Planerisch gibt es Tools, die einem das Leben für die Kalkulation der LPAR-weights erleichtern. Wir kennen auch Unternehmen, die dafür das zPCR und das LPAR-Design-Tool benutzen. Viele Kunden machen sich sehr viel Arbeit und rechnen auch selbst mit Excel-Tabellen. Diese Vorarbeit ist wichtig – entscheidend ist jedoch die Frage, wie sich der Erfolg oder Misserfolg dieser Berechnungen im laufenden Betrieb bewerten lässt.
Wie erkennt man in der Praxis, ob eine LPAR vom PR/SM mangelernährt wird? Und wie lässt sich ein solcher Engpass feststellen, bevor daraus Probleme für die z/OS-Performance entstehen?
LPAR vs. MVS Busy: Identifikation und richtige Schlussfolgerung
Die Antwort auf diese Frage liefert z/INSIGHT mit dem Report LPAR vs. MVS Busy: Er zeigt, wie der tatsächliche CPU-Bedarf einer z/OS-LPAR im Verhältnis zur CPU-Versorgung durch PR/SM steht.
In der Beispielansicht sind zwei Kurven zu sehen, die hintereinander liegen. Die blaue Kurve (hinter der grünen) zeigt den „Hunger“ der z/OS nach CPU-Ressourcen an, wogegen die grüne anzeigt, wie das PR/SM die LPAR mit CPU versorgt. Im Idealfall liegen beide Kurven sehr dicht beieinander (“Hunger” nach CPU = Versorgung durch das PR/SM) – der Bedarf der LPAR wird also nahezu vollständig gedeckt. Wenn man beide Werte dividiert, bekommt man eine Ratio (grüne Linie). Sie sollte möglichst größer 95% sein, am besten bei 100%.
Im gezeigten Beispiel kam es am 3. März 2026 zu einem Mangel. Wir zoomen in die Abbildung herein – mit den praktischen Schiebereglern rechts und unten ist das sehr einfach (siehe rote Pfeile):
Die Ursache des Engpasses ist damit noch nicht abschließend geklärt. Auf jeden Fall kommt es zu einer Mangelernährung des z/OS und der WLM muss jetzt bremsen. Wir wissen genau, der Kunde hier ist von uns gut eingestellt und nur zeitunkritische Dinge werden getroffen. Die problematische Zeit ist damit leicht identifiziert, mit der eine tiefergehende Analyse nun starten kann. Das alles hat mit z/INSIGHT nur wenige Sekunden gedauert. z/INSIGHT unterstützt damit ein datenbasiertes LPAR-Management, indem kritische Zeiträume schnell identifiziert und gezielt für die weitere Performanceanalyse eingegrenzt werden können.
z/OS optimieren: Mit den richtigen Kennzahlen zu mehr Performance und Kostentransparenz
Was haben wir hier gelernt: Für eine stabile z/OS-Performance reicht es nicht, nur einzelne Zeitpunkte stichprobenweise zu berechnen, um CPU-Mangelerscheinungen im z/OS-Betrieb zu identifizieren. Es braucht in jedem Fall ein graphisches Tool, das Abweichungen zwischen CPU-Bedarf und tatsächlicher Versorgung sichtbar macht. Reine Zahlenkolonnen liefern dafür oft nicht die nötige Transparenz.
Wie geht man jetzt weiter vor in so einer Situation? Ein Mangel an CPU geht sicherlich nicht spurlos am z/OS vorüber. Wer wird jetzt eingebremst, um den Mangel auszugleichen? Sind CICS, IMS, DDF oder Websphere betroffen?
Wir werden uns in der Folge genau mit diesen Fragen beschäftigen.
Stay tuned: Im nächsten Beitrag unserer Reihe zur Mainframe-Optimierung zeigen wir, wie sich betroffene Workloads im z/OS-Betrieb genauer analysieren lassen.