Tuning ist keineswegs immer Hardwaresache. So wird oft übersehen, daß die Datenhaltung mit VTAM einen Engpaß im Leistungsverhalten eines Netzwerks darstellen kann. Udo Pfeiffer zeigt auf, daß VTAM über eine ganze Reihe von Funktionen zur Systemoptimierung verfügt.
Vor zehn Jahren ging man alle Leistungsprobleme von Zentralrechnersystemen mit der Analyse der direkten Speicherzugriffe (DASD) an. Das geschah häufig ohne handfeste Grundlagen und brachte deshalb auch kaum positive Ergebnisse. Die Einführung von Leistungsmonitoren für das Betriebssystem, die imstande waren, die tatsächlichen Engpässe bei der Durchflußleistung zu ermitteln, schuf eine völlig neue Dimension der Leistungsplanung.
Ähnliches gilt für die Leistung von Netzwerken. Leitungen und Vorprozessoren sind nicht die einzigen Engpässe in Rechnernetzen. VTAM selbst besitzt zahlreiche Mechanismen zur Systemoptimierung. Ungeeignete Optimierungsparameter oder Standardwerte können künstliche und unnötige Einschränkungen der Netzwerkleistung verursachen.
Ein gut durchdachtes und vernünftig durchgeführtes Tuning kann Antwortzeiten verkürzen, interne Systemverarbeitungszeiten verringern sowie Durchsatz und Leistungsverhalten des Gesamtsystems deutlich verbessern.
VTAM-Datenhaltung ist ein Task mit hoher Priorität, der die Zentraleinheit oft stark beansprucht, viel Speicherplatz belegt und hohe I/O-Leistung erfordert. Dennoch bleibt VTAM häufig die "unbekannte Größe", eine "Blackbox", deren Einfluß auf das Leistungsverhalten nur selten richtig erkannt wird.
Als Komponente des Gesamtsystems hat VTAM in den 16 Jahren seit der Einführung keineswegs an Bedeutung verloren, sondern sogar in immer stärkerem Maße Einfluß gewonnen. Heute gilt das Kommunikationskonzept allgemein als -entscheidender Faktor eines Rechnersystems, und der Kern eines SNA-Netzwerks ist nun einmal VTAM.
Das Datenverwaltungssystem steuert alle Sessions uns ist verantwortlich für deren Einrichtung und Abschluß, außerdem für Error Recovery, Ausfallbenachrichtigung, Routing, Konfiguration und Betrieb des Netzwerks. Praktisch jede Anwendung nutzt heute die Dienste von VTAM - von der Kommunikation mit den Terminalbenutzern bis zum systemübergreifenden Datenverkehr unter CICS und IMS oder bis zur Unterstützung dezentraler Datenbanken unter DB2.
Auch mit der Einführung von PU Type 2.1 und "Advanced Peer to Peer Networking" hat sich daran nichts geändert. VTAM bleibt durch den Betrieb mit IBMs Network Control Program (NCP) als kombinierte PU T2.1 gegenwärtig. Dies wird auch in Zukunft so bleiben. Durch die steigende Zahl von Online-Systemen und Vernetzungen sowie durch die Einführung der SAA (System Anwendungs-Architektur) mit ihrer Förderung der Gemeinschaftsverarbeitung wird der Einfluß von Netzwerken - und damit von VTAM - unvermindert wachsen.
Das Ziel von Tuning und Performance-Optimierung ist eine ausgewogene Lastverteilung. Richtige Optimierung von VTAM stellt ausgeglichene Verhältnisse bei Speicherplatz-Verbrauch, Rechenleistung und Kanalnutzung her. Dabei erwarten die Benutzer auch bei der Übertragung großer Datenmengen kurze Antwortzeiten. Es muß a so entschieden werden, welche Rechenleistung, wieviel Speicherplatz und welche Kanalnutzung erforderlich sind, um ein angemessenes Leistungsniveau zu erreichen und einzuhalten.
Mit dem größtmöglichen Zentralrechner, den schnellsten und leistungsfähigsten DFV-Steuereinheiten und modernsten Glasfaser-Übertragungsleitungen lassen sich natürlich die Antwortzeiten verkürzen. Dies wäre aber sicherlich keine sinnvolle Leistungsplanung. Denn meist sind zu lange Antwortzeiten das Ergebnis schlecht definierter Start-Options in VTAM oder nicht richtig gewählter Größen der Windows für die Virtual Routes.
Mit einer Optimierung nach Faustregeln oder mit Standardwerten ist einfach kein optimales Leistungsverhalten zu erzielen. Jedes VTAM-System ist anders und erfordert deshalb spezielle Optimierung, wenn ausgewogene Leistung erreicht werden soll. Mit einmaligem Tuning ist es meist auch nicht getan. Eine neue Anwendung oder die Modifikation einer bestehenden Anwendung kann Veränderungen der Sessions oder I/O-Buffer notwendig machen. Neue Workloads oder Neukonfigurationen des Netzwerks erfordern erneutes Tuning, das heißt, die Optimierung bleibt ein dynamischer Prozeß.
VTAM-Speicherparameter können tiefgreifenden Einfluß auf die Systemleistung haben. Zuordnung zu großer Bufferpools raubt Speicherplatz nicht nur für VTAM, sondern auch allen anderen Arbeitsprozessen auf dem Zentralrechner. Einige Bufferpools belegen realen Speicher und können, nachdem sie einmal zugeordnet sind, nicht wieder freigegeben werden. Wenn sämtliche anfänglich zugewiesenen Buffer in Gebrauch sind, muß der Buffer-Vorrat erweitert werden.
Ein zu großer Erweiterungswert bedeutet , Verzögerungen bei der Bereitstellung zusammenhängender Pages; wenn der Wert zu klein ist, zieht dies wiederholte Erweiterung und danach vorzeitige Freigabe mit nur kurz darauffolgender Neubereitstellung nach sich. Diese Art der Überlastung ("Thrashing" genannt) kann schwerwiegenden Einfluß auf VTAM und alle Arbeitsprozesse haben.
Ein expandierender oder ungünstiger noch - ein im Slowdown befindlicher Bufferpool ist auch ein Stauanzeiger für alle Virtual Routes, die VTAM benutzen. Eine Leistungsstrategie sollte Mechanismen beinhalten, die vor Überlastung, zu vielen Erweiterungen und Verlangsamung warnen.
Die Aufzeichnung von Speicherinformationen in regelmäßigen Abständen liefert einen nützlichen Überblick über die Speichernutzung während des Betriebstages; bei Abruf über Tage und Wochen helfen diese Informationen bei der Wachstumsplanung und zeigen sich ändernde Leistungsprofile auf.
Die Definition von Virtual Routes ist ein weiteres Beispiel eines potentiellen Engpasses in der Netzwerk-Leistung durch nicht angemessene Parameterwahl. Der zur Verfügung stehende Auswahlmechanismus kann bestimmte Routes bevorzugen und damit auch überlasten, während andere nahezu unbenutzt bleiben. Kritische Routes können inaktiv sein, ohne daß das Personal im Rechenzentrum dies überhaupt merkt.
Die Synchronisation der Virtual Routes ist der wichtigste Steuerungsmechanismus für den Datenfluß im Netzwerk. Die Wahl ungeeigneter Windows kann die Netzwerk-Leistung stark beeinträchtigen und die Antwortzeiten deutlich verschlechtern. Die vorgegebenen Standardwerte sind nahezu immer ungeeignet. Im Extremfall können die Werte für die Größe des Windows häufige und unnötige Wartezeiten auf die Synchronisationsantwort verursachen, wodurch die Virtual Routes zu lange blockiert werden.
Leitungs- und NCP-Statistiken würden geringe Nutzung anzeigen und den Eindruck vermitteln, daß alles in Ordnung sei. Das Ergebnis sind aber längere Antwortzeiten bei den (verärgerten) Endbenutzern. Eine weitere Auswirkung kleiner Windows ist die große Zahl von Synchronisationsantworten.
Diese werden bevorzugt übertragen, nicht in den normalen Kanalverkehr eingebunden und führen zu zahlreichen Anforderungsunterbrechungen (Attention Interrupts) im Zentralrechner.
Das alles beansprucht Betriebsmittel, die anderweitig nutzbringend verwendet werden könnten. Im anderen Extrem können unnötig große Windows zu überfüllten Leitungen und DFV-Steuereinheiten mit ähnlich katastrophalen Folgen führen.
Die Lösung liegt auch hier in der Erfassung, Überwachung und Analyse der Virtual-Route-Daten. Wenn Routes häufig belegt oder blockiert sind, stellt sich die Frage, ob ein Stau auf der Leitung oder in der DFV-Steuereinheit vorliegt. Oder handelt es sich um einen künstlich hervorgerufenen Route-Engpaß wegen ungeeigneter maximaler Window-Größe, wobei eigentlich viel mehr Kapazität vorhanden wäre? Anhand der Informationen zu Spitzenzeiten und im zeitlichen Verlauf können die Größen der Virtual Route-Windows vernünftig gewählt werden.
Eine Tuning-Statistik ist bereits eingebaut
Eine weitere Quelle nützlicher Optimierungsdaten ist die Tuning-Statistik von VTAM selbst. Diese kann beim Hoch, fahren von VTAM oder durch ein Konsolkommando aktiviert werden und wird entweder in das System-Messungs-Feature von MVS (SMF) oder an die Konsole ausgegeben. Tnstats werden für die an Kanäle angeschlossenen Geräte von VTAM, für DFV-Steuereinheiten, Kanalverbindungen und lokale Cluster-Steuereinheiten erfaßt. Diese Daten zeigen die Leistung der Kanalprogramme von VTAM.
Dazu ist aber nicht nur ein Benutzerprogramm zum Lesen der SMF-Datensätze, sondern auch Kenntnis der Kanalprogrammierungstechniken von VTAM erforderlich. VTAM versucht, die Anzahl der I/O-Anforderungen auf allen SNA-Kanälen so gering wie möglich zu halten. Dieser Prozeß ist als "Coattailing" bekannt.
VTAM benutzt folgenden Algorithmus, um abgehenden Datenverkehr zu verzögern, bis bestimmte Ereignisse stattfinden: Ein Parameter "DELAY" bewirkt Warten auf die Zeitüberschreitung der Kanalverzögerung, bevor I/O in der Warteschlange des Kanals bereitgestellt wird. Eine ausreichende Datenmenge zum Füllen der Read Buffer auf der Empfangsseite erreicht, daß der Kanal zugeordnet wird. Eine Warteschlange (gleich 3/4 der Pfad-Informationseinheit (PIU) im letzten DELAY-Intervall) signalisiert ebenfalls einen Schreibvorgang (Grenzwert für die Tiefe der Warteschlange).
Diese Vorgehensweise ist sinnvoll, weil sie die Anzahl der I/O-Unterbrechungen reduziert. Bei Kanalverbindungen wird die Anzahl der Anforderungsunterbrechungen verringert. Weniger Unterbrechungen wiederum verkürzen die internen Systemverarbeitungszeiten, was den Durchsatz des Gesamtsystems verbessert. Tnstats zeichnet Informationen über die Channel Program Counts, Attention Interrupts, Queue Depth Counts und Buffer-voll-Zustände auf.
Eine Methode zur Erfassung, Aufzeichnung und Analyse dieser Daten erlaubt es dem Systemprogrammierer, Parameter zu wählen, welche die Leistung von VTAM steigern, den Durchsatz zu erhöhen und den Einfluß auf andere Arbeitsprozesse verringern.
Ein Grund, warum nur wenige VTAM-Systeme optimal arbeiten, liegt in den generellen Schwierigkeit, effizientes VTAM-Tuning Oberhaupt durchzuführen. Die Feststellung der Tuning-Erfordernisse, Erfassung der Daten, ihre Analyse und das Verständnis für ihre Bedeutung stellen ein wesentliches Problem dar, besonders weil es bisher an passenden Hilfsmitteln mangelte. Deshalb ist ein System zur Auswertung der Leistungsdaten und als Hilfe beim Tuning notwendig.
Bis dato ging es um die Erfassung der VTAM-Buffer- und -Statistikdaten. Nach der Erfassung stellt sich dann die Aufgabe, die Daten aus Protokollen und der System-Management-Routine (SMF) herauszuziehen, sie zu untersuchen und die Informationen zueinander in Beziehung zu bringen. Auf diese Weise lassen sich zwar wertvolle Optimierungsdaten sammeln, nachteilig ist jedoch, daß wenige Rechenzentren die Zeit und Erfahrung haben, die notwendigen Dienstprogramme zu schreiben.
Ein weiteres Problem liegt darin, daß die Informationen nur bereits Geschehenes zeigen. VTAM-Leistung verlangt heute schnellere Analyse. Ein Performance-Monitor für VTAM sollte Funktionen beinhalten, die vor potentiellen oder drohenden Problemen warnen, bevor sie kritisch werden. Die Antwortzeit ist der objektive Leistungsmaßstab. Die Anteile von Rechner und Netzwerk sollten bei der Antwortzeit erkennbar sein, und das Personal des Rechenzentrums sollte gewarnt werden, wenn die Antwortzeiten den vereinbarten Service Level oder Standardzeiten zu überschreiten drohen.
Der Monitor muß Einrichtungen enthalten, um alle Komponenten zu durchleuchten, weiche die Leistung beeinflussen können. Dazu gehören der VTAM-Speicher, Virtual Routes, Kanalnutzung und die VTAM-Anwendungen selbst.
Nur ein Online-System, das die VTAM-Umgebung aktiv analysiert, kann diesen Anforderungen genügen, und es sollte sich in die Leistungsstrategie des Gesamtsystems einfügen. Eine integrierte Lösung für das Performance-Management gewährleistet einen konstant guten Service Level und konsolidiert die in Wechselbeziehung stehenden Elemente Netzwerk, Betriebssystem und Subsysteme. Mit den richtigen Werkzeugen kann eine sichere Entscheidungsgrundlage für die effektive Leistungsplanung und -überwachung etabliert werden.