Dieses Kapitel enthält Leitlinien für die Einrichtung von Natural in einer CICS-Umgebung.
Folgende Themen werden behandelt:
Der Roll Server ist vielseitig und skalierbar, wenn er zum Speichern und Wiederherstellen von Natural-Sitzungsdaten über eine Bildschirm-E/A verwendet wird. Sein Einsatz ist in einer CICSPlex- oder Parallel Sysplex-Umgebung unerlässlich, er kann aber auch mit einzelnen CICS-Regionen verwendet werden. Eine große Anzahl gleichzeitig ausgeführter Natural-Sitzungen kann vom Roll Server problemlos bewältigt werden, kann aber bei Verwendung von Roll Facilities zu Ressourcenkonflikten führen.
Da sich ein Roll Server auf ein bestimmtes Subsystem bezieht, können Natural-Installationen in verschiedenen CICS-Regionen denselben Roll Server nutzen, sofern sie dieselbe Subsystemkennung verwenden. Wenn die Terminalkennungen in CICS-Regionen mit Natural-Installationen, die sich denselben Roll Server teilen, in diesen Regionen nicht eindeutig sind, müssen Sie den NTCICSP-Parameter UNITID=ON verwenden, um sicherzustellen, dass eine eindeutige Sitzungskennung erstellt werden kann, oder separate Roll Server für jede CICS-Region mit unterschiedlichen Subsystemkennungen verwenden.
In einer nicht-parallelen Sysplex-Umgebung kann der Roll Server ohne Roll File arbeiten und nur den speicherinternen Local Roll Buffer (LRB) verwenden, der in einem oberhalb der Speichergrenze zugewiesenen z/OS-Speicherobjekt enthalten ist. In diesem Fall sollte der LRB mindestens so viele Slots haben wie die maximale Anzahl der gleichzeitig ausgeführten Natural-Sitzungen. Die Slotgröße sollte mindestens so groß sein, dass ein durchschnittlich komprimierter Natural Thread darin Platz findet. Wenn "Reserve"-Slots verfügbar sind, belegen Threads, die nicht in einen einzigen LRB-Slot passen, zusätzliche Slots.
Wenn Natural for zIIP installiert ist, plant der Roll Server die Thread-Komprimierung für die Ausführung auf einem zIIP.
Weitere Informationen finden Sie unter Natural Roll Server-Funktionen in der Operations-Dokumentation.
Um den Aufwand für die Einrichtung und Pflege eines Roll Servers für Natural-Installationen und CICS-Regionen mit einer geringeren Anzahl gleichzeitig laufender Natural-Sitzungen zu vermeiden, kann eine der unterstützten Roll Facilities wie unten beschrieben verwendet werden.
Dieser Abschnitt enthält Informationen, die Ihnen bei der Auswahl
der zu verwendenden Roll Facility helfen. Um eine Roll Facility für eine
Thread-Gruppe zu spezifizieren, können Sie den Parameter
PRIMERF des Makros NCMTGD verwenden.
Für Natural-Installationen und CICS-Regionen mit einer großen Anzahl gleichzeitig ausgeführter Natural-Sitzungen wird die Verwendung einer Roll Facility nicht empfohlen; in diesem Fall wird die Verwendung des Roll Servers dringend angeraten.
Dieser Abschnitt behandelt die folgenden Themen:
Wenn der CICS-Hauptzwischenspeicher als Roll Facility angegeben
ist (NCMTGD-Parameter PRIMERF=MAIN), ist beim
Aus-/Einspeicherungsvorgang keine VSAM-E/A-Aktivität oder Kommunikation mit
einem Zwischenspeicherserver erforderlich; daher ist die Verwendung von
PRIMERF=MAIN schneller als PRIMERF=AUX. Aufgrund der
Menge des verwendeten Hauptspeichers kann eine gewisse Optimierung erforderlich
sein.
Der Hauptzwischenspeicher wird in einem 64-Bit-Speicher (oberhalb
der Speichergrenze) zugewiesen, der durch den
CICS-Systeminitialisierungsparameter TSMAINLIMIT und den
z/OS-Parameter MEMLIMIT gesteuert wird. Die
auszulagernden Thread-Daten werden in Abschnitte (Chunks) mit einer maximalen
Größe von 32 KB aufgeteilt.
Wenn Sie jedoch zusätzlich zu PRIMERF=MAIN mit dem
Makro NTCICSP den Parameter MEMOBJR=ON
(Standardeinstellung) angeben, werden die auszuspeichernden Thread-Daten in
einem einzigen Vorgang als zusammenhängendes Speicherstück in den gemeinsamen
DSA-Speicher (GSDSA) oberhalb der Grenze kopiert.
Wenn die Natural CICS-Schnittstelle einen Hilfszwischenspeicher
als Roll Facility verwendet (NCMTGD-Parameter
PRIMERF=AUX), muss die Größe des Kontrollintervalls für die
verwendete Datei mindestens 4 KB betragen. Wenn kein Hilfszwischenspeicher
verfügbar ist, wird stattdessen der Hauptzwischenspeicher verwendet.
Wenn Sie VSAM Roll Files verwenden (NCMTGD-Parameter
PRIMERF=VSAM) und die definierten VSAM Roll Files während einer
CICS-Sitzung voll werden oder nicht mehr nutzbar sind, verwendet die Natural
CICS-Schnittstelle einen Hilfszwischenspeicher.
Die Anzahl der VSAM-Pufferspeicher, die durch den CICS-Systeminitialisierungsparameter TS definiert ist, sollte auf einen angemessenen Wert erhöht werden, um die Anzahl der physischen E/A-Operationen zu verringern. Die CICS-Statistiken sollten auf Engpässe in diesem Bereich überprüft werden.
Um die Anzahl der E/A-Operationen und den für die Durchführung des
Aus-/Einspeicherungsvorgangs erforderlichen CPU-Mehrverbrauch zu minimieren,
sollten Sie die höchstmögliche Kontrollintervallgröße von 32 KB angeben, wenn
Sie VSAM-Dateien oder den Hilfszwischenspeicher als Auslagerungsmöglichkeit
(Roll Facility) verwenden (PRIMERF=VSAM bzw.
PRIMERF=AUX).
Gründe für eine Kontrollintervallgröße von weniger als 32 KB können die bessere Ausnutzung von Festplattenspuren oder die Verwendung von virtuellem Speicher für die VSAM-Pufferspeicher 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.
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.
