Natural CICS Performance-Überlegungen

#### Search Results

Search

# Natural CICS Performance-Überlegungen

Dieses Kapitel enthält Leitlinien für die Einrichtung von Natural in einer CICS-Umgebung.

Folgende Themen werden behandelt:

- Wahl zwischen Roll Server und Roll Facilities

- Auswahl der Roll Facility

- Shared Storage Threads im Vergleich zu GETMAINed Threads

- CICS-Parameter-Einstellungen

- Zeilenkompromierungssysteme (Line Compression)

- Pseudokonversationelle im Vergleich zu konversationellen Transaktionen

- Natural und Adabas

- CICS-Monitoring-Produkte

## Wahl zwischen Roll Server und Roll Facilities

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.

## Auswahl der Roll Facility

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:

- Verwendung von CICS-Hauptzwischenspeicher

- Verwendung von CICS-Hilfszwischenspeicher

- Kontrollintervall für VSAM Roll Files und Hilfszwischenspeicher

- VSAM Roll Files im Vergleich zu CICS-Zwischenspeicher

- Verwendung von VSAM RRDS Roll Files

### Verwendung von CICS-Hauptzwischenspeicher

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.

### Verwendung von CICS-Hilfszwischenspeicher

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.

### Kontrollintervall für VSAM Roll Files und Hilfszwischenspeicher

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.

### VSAM Roll Files im Vergleich zu CICS-Zwischenspeicher

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.

### Verwendung von VSAM RRDS Roll Files

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.

#### In MRO-Umgebungen

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.

#### Separater LSR-Pool für Natural

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.

## Shared Storage Threads im Vergleich zu GETMAINed Threads

Dieser Abschnitt behandelt die folgenden Themen:

- Speichernutzung

- Kontrolle über die Speichernutzung

- Aus-/Einspeichern - Rolling

- Überlegungen zu CICS/TS

- Schlussbemerkung

### Speichernutzung

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.

### Kontrolle über die Speichernutzung

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.

### Aus-/Einspeichern - Rolling

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.

### Überlegungen zu CICS/TS

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).

### Schlussbemerkung

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.

## CICS-Parameter-Einstellungen

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 vom Support 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.

## Zeilenkompromierungssysteme (Line Compression)

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.

## Pseudokonversationelle im Vergleich zu konversationellen Transaktionen

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.

## Natural und Adabas

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

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.

### On this page

- Wahl zwischen Roll Server und Roll Facilities
- Auswahl der Roll Facility
- Shared Storage Threads im Vergleich zu GETMAINed Threads
- CICS-Parameter-Einstellungen
- Zeilenkompromierungssysteme (Line Compression)
- Pseudokonversationelle im Vergleich zu konversationellen Transaktionen
- Natural und Adabas
- CICS-Monitoring-Produkte