Start/Performance & Kosten
z/OS Performance- und Kosten-Analyse
Wir messen aus Ihren Betriebsdaten, wo Last entsteht, wo sie kostenwirksam wird und was sich ohne Durchsatzverlust begrenzen lässt — und sagen dazu, was es kostet, wenn Sie es tun.
Ausgangslage
Kapazität ist gemessen. Kosten sind gerechnet. Das ist nicht dasselbe.
Die meisten z/OS-Betriebe wissen sehr genau, wie ausgelastet ihre Maschinen sind. Deutlich seltener ist bekannt, welcher Anteil dieser Auslastung überhaupt in die Rechnung eingeht — und welcher Workload zufällig zur falschen Zeit läuft.
Beim klassischen Sub-Capacity-Modell wird der höchste 4-Stunden-Durchschnitt eines Monats abgerechnet. Alles, was außerhalb dieses Fensters passiert, ist betrieblich relevant, aber kostenneutral. Genau diese Unterscheidung ist der Kern unserer Analyse.
Untersuchungsfelder
Was wir uns ansehen
Sechs Felder, die in fast jeder Umgebung Potenzial oder Risiko enthalten.
Capping & Kapazitätsgrenzen
Kapazitätsgrenzen je Partition, Gruppenlimits, Verteilung über die Gewichte, Anteil der Capping-Phasen, Wirkung von Soft- gegenüber Hard-Capping.
WLM-Policy und Zielerreichung
Zielerreichung je Serviceklasse, Ausführungsgeschwindigkeit, Antwortzeitverteilung, Nutzung der Prioritätsstufen, Homogenität des Workloads in den Klassen.
Verursacher auf Job-Ebene
Ranglisten je Stunde und Intervall, Laufzeit gegen CPU-Zeit, Ein-/Ausgabeprofile — bis zu dem einen Job, der ein Capping auslöst.
Spezialprozessoren
Ausnutzung der Spezialprozessoren, Überlauf auf Standardprozessoren, Sicht je Serviceklasse — die Grundlage für die Frage, ob zusätzliche Kapazität wirtschaftlich ist.
Dispatching und Hypervisor
Verteilung und Parken der logischen Prozessoren, Betriebssystem- gegen Partitionsauslastung, Erfassungsgrad, Hypervisor-Overhead, Konsistenz der Gewichte.
Batch-Fenster und Scheduling
Wann läuft was, und wie viel davon liegt im kostenrelevanten Fenster? Häufig der wirksamste Hebel, weil er ohne technische Änderung auskommt.
Auswertung
Über 250 Analysen — und eine Bewertung dazu
Wir arbeiten mit einem eigenen Auswertungswerkzeug. Es läuft nicht im laufenden System mit, sondern liest bereits geschriebene Betriebsdaten, verdichtet sie und stellt daraus Zeitreihen bereit, die sich über Wochen und Monate vergleichen lassen.
Ebene für Ebene auflösbar
Von der Maschine über die Partition und die Serviceklasse bis zum einzelnen Job oder zur einzelnen Transaktion — ohne den Zeitraum neu einstellen zu müssen.
Erklärt statt nur gezeigt
Unter jeder Auswertung steht, was sie zeigt und worauf zu achten ist. Damit bleibt nachvollziehbar, was ein Wert bedeutet, wenn man ihn nicht täglich sieht.
Wiederkehrende Berichte
Beliebige Auswertungen lassen sich bündeln und zeitgesteuert als PDF erzeugen — für die Wirkungskontrolle nach einer Umstellung.
Was Sie am Ende in der Hand halten
- Bewertete Ergebnisstrecke — jede Auswertung mit fachlicher Einordnung, nicht nur das Bild
- Konkrete Grenzwertvorschläge für Kapazitätsgrenzen, Gruppenlimits und Gewichte
- Benannte Trade-offs — welcher Workload wann verzögert würde und unter welcher Voraussetzung das vertretbar ist
- Stufenplan zur Umsetzung statt einer einzelnen großen Umstellung
- WLM-Befunde: zu schwache oder unerreichbare Ziele, ungenutzte Prioritätsstufen, inhomogene Serviceklassen
- Ergebnis-Workshop mit Grundlagenteil, damit alle Beteiligten dieselbe Sprache sprechen
Subsystem-Analyse
CICS, DB2 und MQ — die Ebene, auf der die Zeit tatsächlich verbraucht wird
Die Partitionssicht sagt Ihnen, wann Last entsteht und was sie kostet. Warum sie entsteht, entscheidet sich meist eine Ebene tiefer: im Transaktionsmonitor, in der Datenbank und in der Nachrichtenkopplung. Wir werten diese Ebenen mit derselben Zeitachse aus wie die Systemdaten — deshalb lassen sich Befunde nebeneinanderlegen statt nacheinander zu interpretieren. Ausgeführt sind unten CICS, DB2 und MQ; nach demselben Muster werten wir auch IMS und WebSphere Application Server aus.
Transaktionsmonitor
CICS-Analyse und Tuning
Die Antwortzeit einer Transaktion zerfällt in zwei Anteile: die Zeit, in der die Task dem Monitor zugeteilt war, und die Zeit, in der sie gewartet hat. Interessant ist die Differenz innerhalb des ersten Anteils — zugeteilt, aber ohne Prozessorzeit. Genau dort trifft CICS-Tuning auf Betriebssystem-Tuning: gecappte Partition, Seiteneinlagerung, verdrängender Adressraum.
Deshalb gilt die Reihenfolge, die IBM im Performance Guide seit Jahren unverändert formuliert: erst Platten, Netz und das gesamte Betriebssystem, danach die einzelne Region. Wer die MaxTask-Grenze anhebt, während die Partition gecappt wird, verschiebt die Warteschlange nur nach innen.
- Warteprofil je TransaktionDatei- und Speicherzugriffe, Journal, Regionskopplung, Terminal und Sockets, Syncpoint, Sperren — benannte Ursachen statt einer Sammelposition „übrige Wartezeit".
- Verzögerung bis zur ersten Zuteilunggetrennt nach MaxTask-Grenze und Transaktionsklasse. Damit ist Queueing vor dem ersten Dispatch sichtbar, ohne auf Regionsstatistiken angewiesen zu sein.
- Haupt-TCB als SättigungsmaßVerhältnis von Prozessorzeit zu Zuteilungszeit, dazu die offenen TCB-Pools und die Wartezeiten auf einen freien TCB.
- Threadsafe-BewertungModuswechsel zwischen den TCBs sind der klassische Overhead-Treiber. In einer IBM-Messreihe stieg der Durchsatz nach der Umstellung von 218 auf 337 Transaktionen je Sekunde.
- „Datenbank langsam" oder „kein Thread frei"?Die Wartezeit auf einen Datenbank-Thread wird getrennt ausgewiesen. Das sind zwei völlig verschiedene Befunde mit zwei völlig verschiedenen Maßnahmen.
- Programmebene statt nur TransaktionscodeAufrufhäufigkeit, Prozessorzeit je Aufruf, Ladezeiten und Speicher-Höchststände — bevor eine Region in die Speicherenge läuft.
- Antwortzeit gegen das WLM-Zielim selben Bild. Beantwortet direkt, ob ein CICS-Problem in Wahrheit ein Policy-Problem ist.
Datenbank
DB2-Analyse und Tuning
Ein erheblicher Teil der Zeit einer Datenbanktransaktion wird außerhalb des Datenbankcodes verbracht: beim Warten auf eine Zuteilung, auf einen Protokollschreibvorgang, auf eine Seite, die eigentlich noch im Puffer sein sollte, oder auf eine Antwort aus der Koppelfazilität. Diese Anteile sind mit SQL-Tuning grundsätzlich nicht erreichbar.
Dafür haben sie Hebelwirkung: SQL-Tuning verbessert eine Anweisung, Systemtuning wirkt auf alles, was durch das Subsystem läuft. Umgekehrt gilt dasselbe — eine einzelne Fehleinstellung auf Systemebene degradiert jede Transaktion gleichzeitig.
- Pufferpools richtig gelesenDie Trefferquote allein ist wertlos. 96 % Trefferquote können immer noch tausende Lesezugriffe je Sekunde bedeuten — erst zusammen mit der Leserate wird die Quote bewertbar.
- Vorauslesen und Schwellwerteabgeschaltetes Prefetch und erreichte Pufferpool-Schwellen sind stille Prozessorkostentreiber, die in keiner Antwortzeit auffallen.
- ProtokollierungWartezeiten auf Ausgabepuffer zeigen unmittelbar eine zu klein gewählte Pufferung; Lesevorgänge aus dem Archiv deuten auf Rücksetzprobleme.
- SperrenDeadlocks, Zeitüberschreitungen und Sperreskalationen im Tagesprofil — und die Suspension-Quote als Frühindikator, der lange vor den ersten Timeouts steigt.
- ThreadsBelegungsgrad gegen die konfigurierten Grenzen und das Queueing beim Erreichen. Das ist das Gegenstück zur MaxTask-Grenze in CICS.
- Kennzahlen, die null sein müssenFehlschläge in den internen Pools und Thread-Queueing. Jede Abweichung von null ist ein konkreter Parameterauftrag, keine Interpretationsfrage.
- Data SharingSynchrone Zugriffe auf die Koppelfazilität belegen den Prozessor für die volle Dauer des Umlaufs. Servicezeit ist dort unmittelbar Prozessorkosten, nicht nur Antwortzeit — Kohärenzverkehr und Nachlesequote gehören deshalb in jede Kostenbetrachtung.
- SpezialprozessorenWelcher Anteil der Datenbanklast läuft heute verlagert, und was bremst die Verlagerung aus.
Nachrichtenkopplung
MQ-Analyse und Tuning
MQ ist selten der Verursacher und fast immer der Ort, an dem ein Problem zuerst sichtbar wird. Eine Warteschlange, die wächst, meldet zuverlässig, dass irgendwo dahinter weniger verarbeitet wird als vorne ankommt — sie sagt nur nicht, wo. Genau deshalb werten wir MQ auf derselben Zeitachse aus wie Partition, Transaktionsmonitor und Datenbank: Erst nebeneinander wird aus einer steigenden Füllhöhe ein benannter Engpass.
Der zweite Grund ist Kosten. Persistente Nachrichten erzwingen Protokollschreibvorgänge, jede Zustellung kostet Prozessorzeit in mehreren Adressräumen gleichzeitig — im Warteschlangenmanager, im Kanalinitiator und in der aufrufenden Anwendung. In der Verrechnung taucht dieser Anteil oft nur teilweise auf. Wir weisen ihn vollständig aus.
- Pufferpools mit denselben Maßstäben wie bei DB2Trefferquote nur zusammen mit der Leserate. Entscheidend sind die Schwellwerte: erreichte Schreibschwellen und Notfallschwellen gehören in die Bewertung, nicht in eine Fußnote.
- Kennzahlen, die null sein müssenSynchrone Schreibvorgänge, Speicherengpässe im Pufferpool und erreichte kritische Schwellen. Jede Abweichung von null ist ein konkreter Parameterauftrag — dieselbe Logik wie in der Datenbank.
- Protokollierung als eigentlicher DurchsatzdeckelWartezeiten auf einen freien Protokollpuffer wirken flächig auf jeden Schreiber gleichzeitig. Lesevorgänge aus dem Archiv statt aus Puffer oder aktivem Protokoll verlängern Rücksetzvorgänge um Größenordnungen.
- Füllhöhe im Tagesprofil statt als MomentwertEin Höchststand sagt wenig. Wie lange eine Warteschlange über welchem Band lag und wie schnell sie sich wieder leerte, sagt alles über die Verarbeitungsreserve.
- Zugänge gegen Abgänge je WarteschlangeDie Bilanz aus Einstellen und Abholen zeigt unmittelbar, ob die Verbraucherseite mitkommt — und ob zusätzliche Instanzen überhaupt helfen würden oder nur die Sperren verschieben.
- VerbraucherkapazitätWie viele Abholer tatsächlich aktiv waren, wie gleichmäßig sie sich die Arbeit geteilt haben und ob die Verarbeitung an der Warteschlange oder an der Anwendung dahinter hängt.
- Indexierte WarteschlangenEin gezieltes Abholen über Nachrichten- oder Korrelationskennung ohne passenden Index führt zu einer Suche über die gesamte Warteschlange. Die Prozessorkosten wachsen dann mit der Füllhöhe — der teuerste stille Befund in MQ.
- Zwei Zählwerke gegeneinanderDie Statistik des Warteschlangenmanagers und die Abrechnungssätze der Anwendungen müssen zusammenpassen. Tun sie das nicht, arbeitet Last am Erfassungsbereich vorbei — und fehlt später in jeder Verrechnung.
Auswertungsumfang
Über 250 fertige Auswertungen — und der Grund, warum es so viele sind
Eine einzelne Kennzahl beweist selten etwas. Belastbar wird ein Befund erst, wenn er sich aus mehreren Richtungen bestätigen lässt: aus der Kapazitätssicht, aus der Arbeitslastsicht, aus dem Subsystem und aus der Abrechnung. Genau dafür halten wir einen durchgerechneten Bestand an Auswertungen vor — nicht als Katalog zum Durchblättern, sondern als Werkzeugkasten, aus dem für Ihre Fragestellung die passenden gezogen werden.
Kapazität und Abrechnung
Der größte Block. Vier-Stunden-Durchschnitt gegen die vereinbarten Grenzen, Gruppenbetrachtung über mehrere Partitionen, Gewichte und Garantien, sämtliche Capping-Arten nebeneinander, Erfassungsgrad und der nicht zurechenbare Anteil.
Partition und Prozessoren
Auslastung nach Prozessortyp, geteilte gegen dedizierte Kerne, das Verhältnis logischer zu physischer Kapazität, HiperDispatch mit den drei Stufen und dem Parken — die Ebene, auf der jede WLM-Entscheidung ihre Obergrenze findet.
Arbeitslast und WLM
Serviceklassen gegen ihre Ziele über die Zeit, Zielerreichung und Verzögerungsursachen, Verbrauch je Klasse und Periode, Dispatch-Einordnung — und die Gegenprobe, ob ein Ziel überhaupt erreichbar ist.
Spezialprozessoren
Verlagerte Last, ausgelaufener Anteil auf den Standardprozessoren und die Frage, ob zusätzliche Kapazität sich rechnet. Getrennt ausgewiesen, weil hier bares Geld liegt.
Jobs, Batch und Ranglisten
Verbrauch und Laufzeit je Job und gestarteter Aufgabe, Zerlegung der Laufzeit in Rechnen und Warten, das Nachtfenster mit seinen Treibern, Sortierlast — und Ranglisten nach jeder Größe, die sich verrechnen lässt.
CICS, DB2, IMS, MQ und WebSphere
Antwortzeit- und Warteprofile in den Transaktionsmonitoren, Pufferpools, Protokollierung, Sperren und Abrechnungssätze der Datenbank, Warteschlangen, Zugänge gegen Abgänge und Verbraucherkapazität in der Nachrichtenkopplung, dazu die Java-Laufzeitumgebung.
Tailored Fit Pricing
Ein eigener Block, weil sich unter diesem Modell die Fragen ändern: nicht mehr der Monatshöchstwert, sondern der Verbrauch über das Jahr, die Basislinie und die Frage, welcher Anteil überhaupt in die Bemessung eingeht.
Applikationssicht und Datengüte
Verbrauch nach fachlichen Applikationen statt nach technischen Adressräumen, Spitzenbeitrag und What-if-Rechnung — dazu Prüfungen der Datengrundlage selbst: Lücken im Messintervall, verschobene Zeitstempel, unvollständige Sätze. Ein Befund ist nur so gut wie die Daten darunter.
Sie bekommen nicht 250 Bilder, sondern die Handvoll, die Ihre Frage beantwortet — nachvollziehbar hergeleitet, mit dem Weg dorthin dokumentiert. Der Rest steht bereit, falls die Antwort eine neue Frage aufwirft.
Preismodelle
Ihr Vertragsmodell bestimmt, welche Optimierung überhaupt wirkt
Wir bilden in der Analyse ab, wonach Sie tatsächlich abrechnen — sonst rechnet man an der Realität vorbei.
Sub-Capacity / R4HA
Abgerechnet wird der höchste 4-Stunden-Durchschnitt je Partition und Produkt im Monat. Hebel: Peak-Verschiebung, Capping, Gewichte.
Tailored Fit Pricing
Bei der Software Consumption Solution zählt der tatsächliche Verbrauch über das Jahr. Der wirtschaftlich entscheidende Moment ist die Baseline-Verhandlung — Optimierung gehört davor, nicht danach.
Full Capacity
Bei der Enterprise Capacity Solution entfällt die Reporting-Pflicht; der Hebel verschiebt sich von der Peak-Steuerung auf Kapazitätsdimensionierung und Workload-Platzierung.
Wir sind kein Lizenzhändler und verhandeln keine Verträge. Wir liefern die Messgrundlage, mit der Sie oder Ihr Lizenzpartner verhandeln können.
Häufige Fragen
Fragen zur Performance- und Kosten-Analyse
Welche Daten brauchen Sie von uns?
Die Betriebsdaten, die Ihr System ohnehin schreibt, über einen zusammenhängenden Zeitraum von idealerweise zwei Monaten, dazu die aktive WLM-Servicedefinition. Welche Bestandteile im Einzelnen nötig sind, hängt von der Fragestellung ab und wird im Erstgespräch konkret festgelegt. Die Aufbereitung erfordert weder einen Agenten noch eine Installation im laufenden System.
Müssen Daten Ihr Haus verlassen?
Nein. Das Auswertungswerkzeug kann vollständig in Ihrem Rechenzentrum betrieben werden. Alternativ arbeiten wir mit einem anonymisierten Auszug. Was für Ihre Umgebung praktikabel ist, klären wir vorab und halten es schriftlich fest.
Wie lange dauert eine Analyse?
Der Aufwand hängt von Umfang und Zahl der Partitionen ab. Die Datensammlung läuft beim Kunden über die vereinbarte Beobachtungsperiode; Auswertung, Bewertung und Aufbereitung erfolgen anschließend und münden in einen Ergebnis-Workshop. Einen belastbaren Rahmen nennen wir nach dem Erstgespräch.
Wie viel lässt sich einsparen?
Das können wir seriös erst nach Sicht der Daten sagen — und wir nennen bewusst keine pauschalen Prozentwerte. Entscheidend ist das Verhältnis von Durchschnitts- zu Spitzenlast in Ihrer Umgebung und ob Ihre Peaks in verschiebbaren Zeitfenstern liegen. Beides ist aus Ihren Daten direkt messbar.
Machen Sie auch CICS-, DB2-, IMS-, MQ- und WebSphere-Tuning?
Auf Systemebene ja. Bei CICS zerlegen wir die Antwortzeit in ihre Bestandteile und benennen die Wartearten, prüfen Queueing vor der ersten Zuteilung, die Auslastung des Haupt-TCB und die Wirkung einer Threadsafe-Umstellung. Bei DB2 sehen wir uns Pufferpools, Vorauslesen, Protokollierung, Sperrverhalten, Threads, Speicher und — im Data Sharing — die Zugriffe auf die Koppelfazilität an. Nicht dazu gehören SQL-Tuning, Zugriffspfade und Indexdesign; das bleibt bei Ihrer Datenbankentwicklung. Bei MQ betrachten wir Pufferpools und ihre Schwellwerte, die Protokollierung, die Füllhöhe der Warteschlangen im Tagesverlauf, die Bilanz aus Zugängen und Abgängen sowie die Verbraucherkapazität. Für IMS und den WebSphere Application Server gilt dasselbe Vorgehen: Antwortzeit in ihre Anteile zerlegen, Wartearten benennen, Regions- beziehungsweise Laufzeitgrenzen gegen den tatsächlichen Bedarf halten. Wir sagen Ihnen aber, wo die Systemsicht an die Anwendungssicht anschließt.
Unsere Warteschlangen laufen voll — ist das ein MQ-Problem?
Meistens nicht. Eine wachsende Warteschlange ist zuerst eine Aussage über die Seite, die abholt: Es wird weniger verarbeitet als eingestellt. Wir prüfen deshalb in dieser Reihenfolge, ob überhaupt und von wie vielen Instanzen abgeholt wurde, ob das Abholen unnötig teuer ist — ein gezielter Zugriff über Nachrichten- oder Korrelationskennung ohne passenden Index sucht die gesamte Warteschlange ab, die Prozessorkosten wachsen dann mit der Füllhöhe — und erst danach, ob an den Einstellungen des Warteschlangenmanagers etwas fehlt. Die Antwort liegt regelmäßig in der Anwendung dahinter, nicht in MQ.
Ersetzt das unser Monitoring?
Nein. Monitoring beantwortet „was passiert gerade". Wir beantworten „was ist über Wochen hinweg strukturell passiert, was hat es gekostet und was folgt daraus". Beides ergänzt sich.
Wie sieht Ihre Kurve aus?
Schicken Sie uns Ihre Fragestellung — wir sagen Ihnen, welche Daten sie beantworten und wie wir vorgehen würden.