Dieses Kapitel enthält Leitlinien für die Einrichtung von Natural in einer CICS-Umgebung.
Folgende Themen werden behandelt:
Die folgenden umgebungsspezifischen Aspekte sollten beachtet werden:
Wenn Sie Natural in einer CICSplex-Umgebung ausführen, müssen Sie den Natural Roll Server verwenden.
Wenn Sie Natural jedoch lokal in einer einzelnen CICS-Region ausführen, haben Sie mehrere Möglichkeiten.
Eine Möglichkeit ist die Verwendung des Natural Roll Server. Der Vorteil gegenüber der Verwendung der CICS Roll Facilities ist, dass der Natural Roll Server asynchron zur CICS-Region läuft und mehr Roll Buffers in seinem Datenraum bereitstellen kann.
Dieser Abschnitt behandelt die folgenden Themen:
Es wird dringend empfohlen, sowohl Roll Facilities als auch VSAM- und Hilfszwischenspeicher, mit der größtmöglichen Kontrollintervallgröße von 32 KB zu definieren. Dies minimiert die Anzahl der Ein-/Ausgabe-Operationen und den CPU-Overhead, der für die Durchführung der Verschiebungsvorgänge (Rolling) erforderlich ist.
Gründe für eine Kontrollintervallgröße von weniger als 32 KB können die bessere Ausnutzung von Plattenspuren oder die Verwendung von virtuellem Speicher für die VSAM Buffer sein.
Bei gleicher CISIZE/Datensatzgröße verursacht der Zwischenspeicher weniger CPU-Overhead als VSAM Roll Files:
Um n Datensätze in den Zwischenspeicher
zu schreiben, müssen Sie n +1 CICS-Anfragen stellen
(d. h. 1 für DELETQ und n für
PUTQ), während Sie für VSAM Roll Files aufgrund der
VSAM-Transaktionslogik 2 n Anfragen stellen müssen:
n mal (READ für UPDATE
plus REWRITE).
Bei VSAM-Update-Anforderungen wird immer eine physische Ein-/Ausgabe durchgeführt, während bei Zwischenspeichersätzen (AUX) Pufferspeicherung erfolgt, so dass sich in vielen Fällen die zu lesenden Sätze noch in den Pufferspeichern befinden.
Der CICS-Zwischenspeicher kann jedoch zu einem Engpass werden, wenn er auch von anderen Anwendungen genutzt wird.
Durch VSAM Roll Files für Natural kann dieser Engpass überwunden werden (wenn auch auf Kosten von zusätzlichem VSAM-Pufferspeicherplatz), insbesondere wenn E/A-Konflikte vermieden werden können. VSAM Roll Files mit optimaler/maximaler CISIZE/Datensatzgröße sind besonders effizient, wenn diese Datensatzgröße für die CICS-Zwischenspeicher aufgrund anderer Erfordernisse nicht angegeben werden kann.
CICS-Zwischenspeicher sollte immer dann verwendet werden, wenn er für Natural genutzt werden kann. Wenn der CICS-Zwischenspeicher auch von anderen Anwendungen genutzt wird, sollten Sie prüfen, ob die Natural-Performance bei Verwendung von VSAM Roll Files besser ist.
Wenn Natural mit CICS-Zwischenspeicher nicht schlechter abschneidet, sollten Sie den CICS-Zwischenspeicher als Roll Facility wählen und den "eingesparten" VSAM Roll File-Pufferspeicherplatz für weitere TS-Puffer oder für einen zusätzlichen Thread verwenden.
Die primäre Roll Facility ist VSAM RRDS. Der Standardtyp für die temporäre Speicherung ist AUXILIARY.
Wenn Sie VSAM Roll Files verwenden, verwendet die Natural CICS-Schnittstelle den Zwischenspeicher (AUX), wenn alle Roll Files während einer CICS-Sitzung voll oder unbenutzbar werden.
Wenn Sie jedoch keine Roll Files verwenden wollen oder die Roll Files nicht korrekt installiert sind, verwendet Natural unter CICS Zwischenspeicher (AUX) für alle Aus-/Einspeicherungsvorgänge (Rolling). Wenn der Zwischenspeicher (AUX) als Roll File verwendet wird, muss die Größe des Kontrollintervalls für diese Datei mindestens 4 KB betragen. Wenn der temporäre Hilfsspeicher nicht verfügbar ist, wird stattdessen der Hauptzwischenspeicher verwendet.
Die Anzahl der durch den CICS-SIT-Parameter
TS definierten VSAM-Puffer sollte auf einen angemessenen
Wert erhöht werden, um die Anzahl der physischen Ein-/Ausgabe-Operationen zu
verringern. Die CICS-Statistiken sollten auf Engpässe in diesem Bereich
überprüft werden.
Bei der Verwendung des CICS-Hauptzwischenspeichers als Roll Facility wird beim Aus-/Einspeicherungsvorgang keine Ein-/Ausgabe durchgeführt, aber aufgrund der großen Mengen an Hauptspeicher, die verwendet werden, sind möglicherweise Optimierungsmaßnahmen wegen des erhöhten Seitenadressierungsbedarfs (Paging) erforderlich.
VSAM Roll Files sollten für die normale CICS VSAM File-Optimierung
in Betracht gezogen werden, z.B. BUFNO- und
STRNO-Parameter in der FCT. Die
CICS-Shutdown-Statistiken sollten auf Engpässe in diesem Bereich überprüft
werden.
Da die Roll Files als eine Art Page Dataset für Natural dienen, sollte alles vermieden werden, was das Natural-Aus-/Einspeichern verlangsamt, da es Journaling und Logging gibt. Dynamic Transaction Backout (DTB) und Forward Recovery für Roll Files sind nutzlos und verursachen nur Overhead.
Aus Performance-Gründen sollten die VSAM Roll Files in demselben CICS-System definiert werden, in dem auch die Natural-Anwendungen laufen. Das MRO Function Shipping sollte nicht aufgerufen werden. CICS Local Shared Resources (LSR) können verwendet werden, wenn genügend Puffer vorhanden sind.
Es wird empfohlen, einen separaten LSR-Pool für Natural Roll
Files zu definieren, wobei die Anzahl der Strings (STRNO) größer
sein sollte als die Anzahl der Threads. Auch die Anzahl der Puffer sollte
größer sein als die Anzahl der Threads. Eine größere Anzahl von Puffern erhöht
die Look-Aside-Trefferquote.
Dieser Abschnitt behandelt die folgenden Themen:
Shared-Storage-Threads werden bei der Initialisierung des Natural-CICS-Systems vorab zugewiesen. Das bedeutet, dass der von diesen Threads belegte Speicher dem Natural-CICS-System vorbehalten ist, unabhängig davon, ob es aktive Sitzungen gibt oder nicht. GETMAINed-Threads hingegen existieren nur, solange die CICS-Task aktiv ist.
Bei Shared-Storage-Threads (TYPE=SHR) verwendet
Natural unter CICS immer den Speicher, der bei der Initialisierung von Natural
vorab zugewiesen wurde. Daher ist die Größe des von Natural-Threads verwendeten
Speichers leicht vorhersehbar. Bei GETMAINed-Threads (TYPE=GETM)
hängt der tatsächlich verwendete Speicherplatz jedoch von der Anzahl der gerade
aktiven Natural-Sitzungen ab.
Obwohl Natural selbst keinen Steuerungsmechanismus für die
maximale Anzahl von GETMAINed-Threads hat, kann dies durch die Gruppierung der
Natural-Transaktionscodes in einer TRANCLASS gesteuert werden.
Wenn ein Transaktionscode zu einer solchen Klasse gehört, kann die maximale
Anzahl der parallelen Tasks durch den Parameter
MAXACTIVE in der TRANCLASS-Definition
geregelt werden.
Wenn eine Natural-Sitzung ihren gemeinsam genutzten Speicher-Thread freigibt, werden die Sitzungsdaten in dem Thread in unkomprimiertem Format aufbewahrt, es sei denn, eine andere Sitzung muss diesen bestimmten Thread verwenden. In diesem Fall ist die neue Sitzung für die Speicherung der Daten der alten Sitzung verantwortlich.
Ein solcher Vorgang wird als verzögertes Aus-/Einspeichern (Deferred Rolling) bezeichnet. Er ermöglicht es Ihnen, ein Aus-/Einspeichern vollständig zu vermeiden, vorausgesetzt, die Anzahl der verfügbaren Threads ist größer oder gleich der Anzahl der nebenläufig aktiven Natural-Sitzungen.
Umgekehrt speichern Sitzungen, die GETMAINed-Threads verwenden,
ihre Daten immer vor der FREEMAIN-Operation bei
Beendigung der CICS-Task, was unabhängig von der Anzahl der nebenläufig aktiven
Natural-Sitzungen zu einem Roll-Overhead führt.
In Umgebungen mit hohem Natural-Transaktionsaufkommen gibt es praktisch keinen Unterschied zwischen dem Sichern von Sitzungsdaten über die "sofortige" oder die "verzögerte" Aus-/Einspeichern-Methode.
In stark ausgelasteten Natural-Umgebungen mit einem hohen Verhältnis von Natural-Sitzungen zu Programmspeicher-Threads entsteht ein höherer Aus-/Einspeichern-Aufwand, da diese Threads von mehreren Natural-Sitzungen gemeinsam genutzt werden. Ein potenzielles Problem in dieser Situation ist die Thread-Konkurrenz (Thread Contention), die durch Natural-Tasks mit lange laufenden Adabas-Anfragen verursacht wird, d. h. mit vielen Adabas-Aufrufen.
Um zu verhindern, dass solche Tasks einen Thread zu lange
blockieren, kann man sie durch entsprechende Einstellung des
Natural-Profilparameters DBROLL dazu
zwingen, ihren Thread freizugeben.
Bei GETMAINed-Threads kommt es jedoch nie zu Konflikten zwischen
zwei oder mehreren Natural-Sitzungen, da ein TYPE=GETM-Thread
ausschließlich zu der Natural-Sitzung gehört, der er zugeordnet wurde.
TYPE=GETM-Threads können daher als
"Einweg-Ressourcen" betrachtet werden, die nie gemeinsam genutzt
werden, während TYPE=SHR-Threads als
"Mehrweg-Ressourcen" betrachtet werden können, die gemeinsam
genutzt werden können.
Das wichtigste Funktionsmerkmal von CICS/TS ist die Transaktionsisolierung, d. h. der Speicher einer Task kann vor anderen Tasks geschützt werden.
Um diese Möglichkeit bei Natural zu nutzen, sollten
TYPE=GETM-Threads verwendet werden, da diese Threads der
Transaktionsisolierung unterliegen, während dies bei
TYPE=SHR-Threads ("shared") nicht der Fall ist.
Außerdem entsteht bei TYPE=SHR-Threads mit CICS/TS zusätzlicher
CICS-Overhead.
Während der Thread-Auswahlalgorithmus für
TYPE=GETM-Threads sehr einfach ist (wenn eine Natural-Task
gestartet wird, wird über CICS GETMAIN ein Thread
zugewiesen), ist er für TYPE=SHR-Threads komplizierter: Die
Umgebung der Natural-Threads wird vom umgebungsabhängigen Nukleus verwaltet
(Warteschlangenbildung und Lastausgleich), während CICS nichts über
Natural-Threads weiss. Im Gegensatz zu TYPE=GETM-Threads, bei
denen CICS den Thread spätestens am Ende der Task freigeben würde, muss bei
TYPE=SHR-Threads Natural die Threads ihren Sitzungen
zuordnen/freigeben. Zu diesem Zweck führt Natural eine Liste von Thread Control
Blocks (TCBs).
Obwohl Natural immer einen Exit aktiv hält, um im Falle einer
abnormalen Task-Beendigung Sitzungsressourcen freigeben zu können, die CICS
unbekannt sind (z. B. TYPE=SHR-Threads), können Situationen
auftreten, in denen eine Natural-Task beendet wird, ohne dass ihr Thread in der
zugehörigen TCB als frei markiert wird, beispielsweise wenn eine
EXEC CICS ABEND CANCEL-Anforderung in einem von
Natural aufgerufenen Nicht-Natural-Programm ausgegeben wurde oder wenn
Natural-Sitzungen durch KILL-Transaktionen eines
Performance-Monitors geleert wurden (Flushing).
Um Probleme mit versehentlich belegt gebliebenen Threads zu vermeiden, prüft Natural unter CICS in seinem Thread-Auswahlalgorithmus immer, ob die mit einem belegten Thread verknüpfte CICS-Task noch vorhanden ist. Wenn dies nicht der Fall ist, wird der Thread freigegeben.
Bei CICS-Versionen vor CICS/TS erfolgte diese Prüfung auf aktive CICS-Tasks durch Kontrollblocksprünge, d. h. Natural prüfte auf eine aktive Task, indem es die Konsistenz der Kontrollblöcke EISTG, TCA und TQE der Task prüfte. Bei CICS/TS ist der Speicher einer anderen Task aufgrund der Transaktionsisolierung möglicherweise überhaupt nicht zugänglich.
Um diese Funktion in CICS/TS zu erfüllen, gibt der
umgebungsabhängige Nukleus eine EXEC CICS INQUIRE STORAGE
TASK()-Anforderung für jeden Thread aus, der in der
Thread-Auswahlroutine als belegt identifiziert wurde. Das bedeutet, dass es
einige CICS-Anforderungen gegeben haben kann, bevor die Task schließlich für
Thread-Ressourcen in die Warteschlange gestellt wird. Dasselbe CICS-Kommando
wird auch für die Serialisierung von Natural-Sitzungen verwendet (z. B.
verzögertes Aus-/Einspeichern (Deferred Rolling) von
TYPE=SHR-Threads).
Sowohl TYPE=SHR- als auch
TYPE=GETM-Threads haben ihre Vor- und Nachteile. Bei CICS/TS sind
TYPE=GETM-Threads jedoch zu bevorzugen, und zwar aufgrund
folgender Aspekte:
Unterstützung der Transaktionsisolierung,
mehr CICS-ähnliche Optimierungsmöglichkeiten,
schlechtere Performance der TYPE=SHR-Threads.
Die CICS-SIT-Parameter AMXT und
CMXT sollten verwendet werden, um die Anzahl der
nebenläufigen Natural-Tasks zu kontrollieren.
Die angegebene Anzahl sollte größer sein als die Anzahl der Threads.
Es sollte auch in Betracht gezogen werden, für asynchrone Natural-Tasks und für
Natural Advanced Facilities Spool-Tasks eine eigene Transaktionsklasse mit
einem geeigneten CMXT-Parameter anzugeben, um zu
verhindern, dass "normale" Natural-Terminal-Tasks durch zu viele
solcher "Hintergrund"-Tasks, die Threads belegen, abgemeldet
werden. Für diese Transaktionen können spezielle Thread-Gruppen definiert
werden.
CICS-Dumps für Natural-Transaktionen sollten unterdrückt werden, es
sei denn, sie werden von Mitarbeitern der Software AG zu Debugging-Zwecken
angefordert. Natural selbst erzeugt Dumps (über EXEC CICS
DUMP) bei Nicht-Programmprüfungsabbrüchen und auch bei
Programmprüfungen, wenn der Natural-Session-Parameter
DU auf
ON gesetzt ist. Wenn kein Natural-Dump erzeugt wird, ist ein
CICS-Dump überflüssig und verursacht nur zusätzlichen Overhead (insbesondere
bei der Erstellung eines System/Region-Dumps, da das gesamte CICS-System
angehalten wird, bis der Snap-Dump abgeschlossen ist).
Der CICS-Trace ist für die Problemanalyse unerlässlich, obwohl er Mehraufwand für das System bedeutet. Auch CICS-Performance-Monitoring-Tools und Accounting Packages verursachen einen System-Overhead von bis zu 30 Prozent und mehr. Einige Packages schalten intern den CICS-Trace ein und fangen ihn dann ab. Sie sollten sich dieses potenziellen System-Mehraufwands bewusst sein. Denken Sie auch daran, dass die Natural CICS-Schnittstelle die Anwendungsprogrammierschnittstelle der CICS-Kommandoebene verwendet: Anfragen auf CICS-Kommandoebene erzeugen viel mehr Trace-Einträge (abgesehen von sonstigem Overhead) als Anfragen auf CICS-Makroebene.
Natural selbst optimiert seine Datenströme mit Hilfe von RA (Repeat to Address) und anderen Techniken wie Screen Imaging usw. Wenn andere Line Zeilenkompromierungssysteme installiert sind, sollten die Natural-Transaktionen von der Verarbeitung durch diese Systeme ausgeschlossen werden, da dies zu einem Mehraufwand führen würde, der keinen Nutzen bringt.
Bei der Wiederaufnahme einer Sitzung sind konversationelle Natural-Tasks an ihren ursprünglichen Thread gebunden, was bedeutet, dass eine konversationelle Task auf diesen Thread warten muss, wenn er gerade nicht verfügbar ist. Pseudokonversationelle Natural-Tasks hingegen sind flexibel und können in jeden verfügbaren Thread verschoben werden.
Mit anderen Worten: Der "klassische" Vorteil von konversationellen Tasks - weniger Ein-/Ausgaben für das Speichern/Wiederherstellen von Daten gegenüber Bildschirm-E/A-Operationen - gilt für Natural aufgrund seiner Thread-Technik nicht.
Da eine Natural-Task in CICS auf den Abschluss eines Adabas-Aufrufs wartet, sollte die versorgende Adabas-Region/Partition immer eine höhere Priorität haben als die CICS-Region/Partition, um die Wartezeit zu minimieren.
CICS-Monitoring-Produkte können Funktionen zum Löschen von CICS-Tasks bieten, wobei alle von der Anwendung gesetzten Exits für abnormale Beendigung umgangen werden.
 |
Warnung: Solche Funktionen sollten nicht zum Abbrechen von Natural-Tasks verwendet werden, da Natural möglicherweise nicht in der Lage ist, die von ihm belegten Ressourcen zu bereinigen, und, schlimmer noch, das Natural-CICS-System in einem inkonsistenten Zustand verbleiben kann, je nachdem, womit diese Task beschäftigt war. |
Um Natural-Sitzungen abzubrechen, sollten Sie stattdessen die Funktionen Cancel Session oder Flush Session des Dienstprogramms SYSTP verwenden. Siehe Debugger und Dienstprogramme (Utilities)-Dokumentation.
