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:

- Umgebungsspezifische Aspekte

- 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

## Umgebungsspezifische Aspekte

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.

## Auswahl der Roll Facility

Dieser Abschnitt behandelt die folgenden Themen:

- Kontrollintervall

- VSAM Roll Files im Vergleich zu CICS-Zwischenspeicher

- Verwendung von CICS-Hilfszwischenspeicher

- Verwendung von CICS-Hauptzwischenspeicher

- Verwendung von VSAM RRDS Roll Files

### Kontrollintervall

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.

### 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 CICS-Hilfszwischenspeicher

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.

### Verwendung von CICS-Hauptzwischenspeicher

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.

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

## 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

- Umgebungsspezifische Aspekte
- 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