IBMs zIIP für Mainframe erklärt

  Als Anschluss zu Phil Graingers Beitrag über zIIP-Offload dachte ich, es lohne sich, ein paar Minuten darauf einzugehen, die Eigenschaften von Code zu betrachten, der auf einem zIIP laufen kann, sowie Code, der minimale Leistungsverluste erleiden könnte, wenn er auf einen zIIP statt auf einen Allzweckprozessor (GP) umgeschrieben wird. IBM führte 2006 den zIIP (System Z Integrated Information Processor) ein. IBM lizenziert zIIP-Hardware für einen Bruchteil der entsprechenden GP-Gebühren. Wichtiger für Sie ist, dass zIIP-Prozessoren nicht in der Softwaregebühr berücksichtigt werden, sodass Sie durch die Verlagerung der Arbeitslast von GPs auf zIIPs erhebliche Einsparungen erzielen können. Außerdem laufen zIIP-Prozessoren "mit voller Geschwindigkeit", sodass Sie tatsächlich mehr Verarbeitung in kürzerer Zeit erledigen können, wenn Ihre GPs keine Vollkapazitätsmodelle sind. Warum also nicht einfach jeden GP durch einen zIIP ersetzen und so Kosten für Hardware und Software sparen? Erstens hat IBM eine Einschränkung für die zIIP-Nutzung eingeführt. Ursprünglich durfte es in einem CEC nicht mehr als ein zIIP pro GP geben, aber einige Modelle erlauben heute zwei zIIPs pro GP. Zweitens setzt IBMs Lizenzvereinbarung Beschränkungen für die Art des Codes, der auf einem zIIP ausgeführt werden darf; der Code muss in einer z/OS-Enklave unter der Kontrolle eines SRB (Service Request Block) laufen. Die Verwendung einer Enklave bedeutet, dass die Arbeit über den z/OS Workload Manager (WLM) ausgeliefert wird. Code, der aus der Enklave ausgeführt wird, kann von einem gemeinsamen Satz von WLM-Kontrollen und -Richtlinien verarbeitet werden, da der Code eine gemeinsame Charakteristik hat. Die Planung eines SRB anstelle eines Task Control Block (TCB) impliziert weitere Einschränkungen; die relevanteste davon ist, dass kein SVC (außer ABEND) ausgegeben werden kann, was die Nutzung vieler z/OS-Dienste, die häufig von Anwendungsprogrammen aufgerufen werden, verhindert. Dies wurde fälschlicherweise als "man kann keine I/O auf einem zIIP machen" verstanden, was nicht stimmt. Es stimmt jedoch, dass QSAM und BSAM, die viele Anwendungsprogramme für sequentielle Datei-I/O verwenden, nicht aus SRB-Code aufgerufen werden können, weil sie SVCs ausgeben. Der Vollständigkeit halber sollten wir "zAAP auf zIIP" erwähnen, wobei IBM Prozesse, die zAAP-berechtigt sind, in Umgebungen ohne zAAPs erlaubt. Sehr wenig Legacy-Code passt in dieses Profil, aber wir sehen immer mehr Db2-Installationen, die Legacy-COBOL-Anwendungen in Java konvertieren, weil Programmierer leichter zu finden sind als solche mit COBOL-Fähigkeiten. Ein Nebeneffekt dieses Schrittes ist, dass Legacy-Anwendungen nach dem Umschreiben in Java zIIP-fähig werden. Warum also aktivieren Ihre Mainframe-Anbieter zIIP nicht den gesamten Code in all ihren Produkten? Die Antwort führt zurück auf die zweite oben genannte Einschränkung – um zIIP-berechtigt zu sein, muss Code unter einem SRB laufen und kann daher viele z/OS-Dienste nicht aufrufen. Der Großteil des bestehenden Produktcodes wurde für den Betrieb im TCB-Modus geschrieben. Historisch wurde SRB-Moduscode nur dort verwendet, wo er als kosteneffiziente Methode für Cross-Memory-Verarbeitung galt. Schauen wir uns ein hypothetisches Stück Code (Teil eines Softwareprodukts) an, das heute unter einem TCB läuft und keine SVC-Aufrufe macht. Um den Code zIIP zulässig zu machen, müssen wir bei jeder Ausführung des Codes Folgendes tun:

1. Richte das SRB im Speicher so ein, dass es auf den auszuführenden Code verweist.
2. Geben Sie das IEAMSCHED-Makro aus, um das SRB für die Ausführung zu planen.
3. Der ursprünglich ausführende TCB-Code muss warten, bis der SRB-Code ausgeführt wird.
4. Wenn der SRB-Code abgeschlossen ist, muss er dem TCB-Code das Fortsetzen signalisieren, bevor er beendet wird.

Alternativ könnten wir das SRB einmal starten und dann den SRB-Code in einer Schleife einschalten und warten, anstatt jedes Mal einen neuen SRB zu planen, wenn die Funktion ausgeführt werden soll. Der Aufwand beim Wechsel vom TCB- in den SRB-Modus und zurück verursacht CPU-Kosten. Anbieter wägen die Vorteile ab, Code zIIP wahlfähig zu machen, mit den CPU-Kosten herauszufinden, um zu bestimmen, welcher Code für die Nutzer am effizientesten ist. Hersteller sollten, wo möglich, zIIP-Zulassungsfähig machen. Sie sollten sich auf CPU-intensive Programme konzentrieren, die keine z/OS-Serviceaufrufe enthalten, die nicht von einem SRB aus durchgeführt werden können, und wenig I/O benötigen. Die Programme müssen oft genug ausgeführt werden, damit die CPU-Einsparungen für Ihre GPs erheblich sind. Es wäre zwar schön, wenn wir den gesamten Code in jedem Ihrer z/OS-Softwareprodukte auf zIIP statt auf GPs ausführen könnten, aber das ist unrealistisch. Eine letzte Sache ist, dass die Lizenz, die es Drittanbietern erlaubt, ihren Code zIIP-fähig zu machen, ausdrücklich die Nutzung der Lizenz verhindert, um ANDEREN Code auf einem zIIP zu aktivieren. Ein Anbieter kann also zIIP-fähigen Code, den er geschrieben hat, aber kein Tool schreiben, um den Code eines Kunden zIIP-fähig zu machen. Ich hoffe, die Informationen in diesem Artikel liefern Ihnen die Informationen, die Sie benötigen, um die zIIP-Ausnutzung mit Ihren Anbietern zu besprechen.  

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.