Auch wenn die IBM ihre DBMS-Strategie inzwischen voll auf DB2 ausrichtet ist IMS aus der täglichen DV-Praxis kaum wegzudenken. Denn viele Anwender können oder wollen nicht auf das neue Paradepferd des Marktführers umsatteln. An diese Benutzergruppe wendet sich Karl Vollmer* mit seinen Tips für das IMS-Tuning.
Moderne Großcomputer verfügen vielfach über mehr als eine CPU. Um daraus einen Vorteil für den Gesamtdurchsatz der Maschine zu ziehen, muß man versuchen, parallel mit mehreren CPUs zu arbeiten. Genau dies wird im MVS mit dem "Task"-Konzept getan. Dabei handelt es sich um Programmteile, die unabhängig voneinander parallel arbeiten können. Die einzelnen Tasks werden nach Beendigung wieder mit dem MVS-Dispatcher synchronisiert.
Fehlerhaftes Handling bremst Performance-Gewinn
Eine ähnliche Philosophie wird nun auch im IMS angewandt, nur daß man hier nicht von Tasks, sondern von "ITasks" spricht. An der Grundidee ändert sich dabei nichts; auch im IMS wird im Interesse einer guten Antwortzeit versucht, Programme gleichzeitig abzuarbeiten.
Ein entscheidender Schritt wurde beim Umstieg von IMS 1.2 auf IMS 1.3 vollzogen, denn dabei konnte die Anzahl der Tasks von vier auf mehr als elf erhöht werden. Diese IMS-Tasks zerfallen in eine Vielzahl von "ITasks" . Den daraus resultierenden Performance-Gewinn kann man nun leicht gefährden durch einen fehlerhaften Einsatz des "Scheduler
ITasks ". Diese IMS-Funktion ist nicht nur für die Zuordnung von Kontrollblöcken und für die Auswahl und Verarbeitung von Nachrichten zuständig, sondern sie ordnet auch Anwendungsprogrammen IMS-Ressourcen zu und löst Konflikte auf, die die IMS-Performance beeinflussen können.
Das Vermeiden von Konflikten um dem Scheduler die Arbeit zu erleichtern und das System zu tunen, erfordert eine sorgfältige Planung und tieferes Verständnis dafür, wie die "Scheduler ITask" arbeitet.
Die Hauptaufgabe dieses SW-Systems besteht darin, zwischen dem Verarbeitungsprogramm einer abgearbeiteten Nachricht und der betreffenden Komponente des nachfolgenden Programms einen Übergang herzustellen. Wird ein Programm beendet, so benachrichtigt die "Message Processing Region" die IMS-Control-ITask. Die "Scheduler ITask" durchsucht sodann die SMBs (Scheduler Message Blocks) nach in der Warteschlange befindlichen Nachrichten; ferner ermittelt sie die für die Ausführung der jeweiligen Transaktion erforderlichen Betriebsmittel und untersucht möglicherweise Konflikte um diese
Betriebsmittel.
Um die Entscheidungen zu verstehen, die das System trifft, muß man sich vergegenwärtigen, daß die Prioritäten für die Betriebsmittel einer Transaktion bereits bei der IMS-Systemgenerierung festzulegen sind. Zunächst werden mit Hilfe des Schlüsselwortes MSGTYPE aus dem TRANSACT-Makro Transaktionsklassen definiert. Zur Startzeit der "Regions" werden die Klassen in der Reihenfolge ihrer Priorität den "Regions" zugeordnet.
Dazu ein Beispiel: Der "Message Region" A wurden die Klassen 1, 3 und 4 zugeordnet, der "Message Region" B die Klassen 2, 3 und 5. Da der Scheduling-Algorithmus die an erster Stelle aufgeführten Klassen jeweils als diejenigen mit der höchsten Priorität behandelt, könnten in dem hier gewählten Beispiel die Nachrichten der Klasse 3 in jeder der beiden "Regions" vorrangig ablaufen.
Message-Scheduling greift stets auf solche Prioritäten zurück. Zu beachten ist jedoch, daß diese Prioritäten nicht der einzige Faktor sind, der sich auf das Scheduling auswirkt. An weiteren Faktoren seien konkret genannt: Der "Processing Limit Count", der "Scheduling Type" und der "Parallel Limit Value".
Einen erheblichen Einfluß auf das Message-Scheduling hat zudem die "Scheduler Subsequence"-Warteschlange. Es ist mithin eine sehr, sehr vielschichtige Basis, von der aus "Scheduler ITask" zu prüfen hat, ob eine ausgewählte Nachricht für die Verarbeitung bereit ist.
Es gibt eine Reihe von Gründen, warum IMS eine Transaktion nicht zur Verarbeitung freigibt. Zu ihnen gehört, daß das geladene und aktive Transaktionsprogramm gerade mit der Abarbeitung eines anderen Transaktionstyps befaßt ist. Hat nämlich der Systemprogrammierer im Makro APPLCTN für diesen "Program Specification Block" (PSB) SCHDTYP-SERIAL definiert, so kann die Verarbeitung nicht angestoßen werden, weil das Anwendungsprogramm in diesem Falle stets nur einen Transaktionstyp verarbeiten kann. Als Resultat kommt es zu einer Verzögerung, "Scheduling Program Conflict" genannt.
Der Programmierer vermeidet jedoch eine solche Situation, wenn er von vornherein SCHDTYP-PARALLEL spezifiziert. Dann nämlich kann das Anwendungsprogramm mehr als einen Transaktionstyp verarbeiten. Programmkonflikte der beschriebenen Art sind in IMS-Umgebungen nicht eben häufig; und die meisten von ihnen lassen sich durch das "Parallel-Scheduling" lösen. Aber einige Nachteile dieses Verfahrens sind unübersehbar.
Sollten nämlich die nunmehr parallel geschalteten Transaktionen dasselbe Segment aktualisieren wollen, könnte es durch "Program Isolation Enqueues" (PI-Enqueues) wiederum zu Verzögerungen kommen - diesmal nur "weiter hinten" im Transaktionsfluß. Dabei schlagen die durch PI-Enqueues ausgelösten Verzögerungen besonders stark durch, indem sie die gesamte "Region" lahmlegen. Sie sollten daher unbedingt vermieden werden.
Konfliktsituationen haben vielfältige Ursachen
Häufiger als Programmkonflikte sind Konflikte um Datenbanken (Data Base Conflicts). Diese Bezeichnung ist insoweit unglücklich, als auch viele Störungen im Pool-Bereich (Pool Space Failures) darunterfallen. Doch wie dem auch sei: Derartige Konflikte entstehen immer dann, wenn zur Verarbeitung benötigte Betriebsmittel nicht bereitstehen; und die Ursachen liegen nicht nur in Datenbank-Konkurrenzsituationen oder Pool-Störungen, sondern auch in Problemen, die bei PI-Enqueues, Prioritäten oder Programmen auftreten.
Zwei Arten von Platzproblemen sind zu unterscheiden, nämlich die im PSB- und die im DMB-Pool (Data Management Block). Um Störungen vom PSB-Typ und die damit verbundenen Konflikte zu reduzieren, sollte der Systemprogrammierer den PSB-Pool erweitern. Jedoch: Fällt diese Erweiterung so groß aus, daß sich sämtliche Konflikte vermeiden lassen, wird der Adreßraum für den normalen Transaktionsfluß knapp. An dieser Stelle sei vermerkt, daß sich die Kosten einer Störung vom PSB-Typ in I/0s auf die ACB-Bibliothek (Access Method Control Block) erschöpfen und damit zumeist billiger sind als Speicherplatz.
DMB-Störungen verursachen erheblichen Overhead
Anders verhält es sich mit den Störungen vom DMB-Typ, die um jeden Preis vermieden werden sollten. Denn sie bringen nicht nur ACB-I/0s mit sich, sondern auch ganz erheblichen Overhead. Dieser entsteht bei dem Bestreben, Speicherplatz verfügbar zu machen, indem "closed" oder lange nicht mehr benutzte DMBs aus dem Pool entfernt werden ("last recently used"). Sobald einer dieser DMBs wieder benötigt wird, muß er zunächst neu eröffnet werden, bevor er geladen werden kann. Mit anderen Worten: Um einen DMB in den Speicher zu bringen oder aus ihm zu entfernen, muß jedesmal eine Datenbank eröffnet beziehungsweise geschlossen werden.
Tritt ein datenbankbezogener Konflikt ein, so muß "Scheduler ITask" darüber befinden, welche Transaktion als nächste zur Verarbeitung freigegeben werden soll. Hierzu wird die betreffende Option geprüft, die im Schlüsselwort SCHD des Makros TRANSACT durch die Zahlen 1 bis 4 spezifiziert ist. In Fällen, in denen die Optionen SCHD=1 und SCHD=2 heißen, kommt es dann häufig zu einem neuerlichen Problem, dem "Priority Cutoff"-Konflikt.
Transaktionsmatrix hilft bei Problembeseitigung
Denn die Default-Option SCHD=1 läßt nur Transaktionen, die derselben oder einer gleichwertigen Prioritätsstufe und derselben Klasse angehören, zur Verarbeitung zu; SCHD=2 aber bedeutet, daß nur Transaktionen mit höherer Priorität in der ausgewählten Klasse zur Verarbeitung freigegeben werden dürfen. Das Arbeiten mit beiden Optionen hat seinen Sinn in Systemumgebungen, in denen klar zwischen vitalen und trivialen IMS-Workloads unterschieden wird.
Die Optionen SCHD=3 und SCHD=4 dagegen bringen erheblich geringere Einschränkungen mit sich. Sie erlauben nämlich, daß in der ausgewählten Klasse jede Transaktion angestoßen wird beziehungsweise daß ein Wechsel in die nächste Klasse zur Transaktion mit der höchsten Priorität möglich ist. Keine dieser beiden Optionen verursacht Priority-Cutoff-Konflikte; und beide sind gut zum Einsatz in Umgebungen geeignet, in denen zahlreiche Transaktionen von etwa derselben betrieblichen Bedeutung ablaufen.
Sobald ein Programmierer sich darüber im klaren ist, wie oft eine Transaktion verarbeitet werden darf, legt er den PROCLIM (Processing Limit Count") fest, um sicherzustellen, daß das Anwendungsprogramm nur für die vorgegebene Anzahl von Transaktionen in der abhänigen "Region" verbleibt. Ist der PROCLIM-Maximalwert erreicht, so werden keine weiteren Transaktionen des betreffenden Typs mehr für die Verarbeitung freigegeben, bevor nicht das Programm erneut in die abhängige "Region" geladen worden ist. Die "Region" steht sonst für andere Transaktionen zur Verfügung.
Das Fazit: Ein Zuordnungsalgorithmus zu Klassen und Prioritäten ist nur dann wirklich erfolgreich planbar, wenn absehbare Konflikte identifiziert und vorweggenommen werden. Dazu sollte der Benutzer eine Transaktionsmatrix anlegen. Sie ermöglicht ihm das Aufspüren potentieller Problembereiche und ein präsentives Gegensteuern im Wege der Auswahl von Kriterien für die "Message Class"-Typen.
Wichtige Faktoren, die es zu beachten gilt, sind die benötigten Programme und Datenbanken, ihre Bedeutung für den Endbenutzer, aber auch die in Spitzenzeiten übliche Transaktionsrate. Und natürlich müssen die erforderlichen Betriebsmittel zur Verfügung stehen.
* Karl Vollmer ist bei der Candle GmbH, München, für IMS im Technischen Support zuständig.