Pagepool

Im Pagepool werden Benutzerdaten gespeichert, die während des Anwendungslaufs entstehen. Das sind:

• LSSBs, GSSBs, TLS- und ULS-Blöcke

• Message Queues, d.h. Asynchron-Nachrichten (auch zeitgesteuerte) für Clients, Asynchron-Vorgänge und Service-gesteuerte Queues, unter anderem auch die Dead Letter Queue

• zwischengespeicherte Sätze der Benutzer-Protokolldatei (USLOG)

• Vorgangsdaten (KB-Programmbereich, letzte Dialog-Nachricht etc.)

• Dialog-Nachrichten, die als Folge der TAC-Klassen- bzw. Prioritätensteuerung nach Eingabe zwischengespeichert werden.

• Ausgabe-Nachrichten an Clients

Für UTM-Cluster-Anwendungen auf Unix-, Linux- oder Windows-Systemen gelten einige Besonderheiten, siehe Abschnitt "Hinweise zur Generierung einer UTM-Cluster-Anwendung".

Die laufende UTM-Anwendung greift auf den Pagepool über den UTM-Cache zu, siehe KDCDEF-Generierung, Anweisung MAX, Operand CACHESIZE im Abschnitt "MAX - UTM-Anwendungsparameter definieren".

Die Größe des Pagepools (Anzahl der UTM-Seiten) legen Sie in der KDCDEF-Generierung in der MAX-Anweisung fest:

MAX...,PGPOOL=( number, warnlevel1, warnlevel2 )

number	Größe des Pagepools in Anzahl UTM-Seiten
warnlevel1	Die erste Warnung wird ausgegeben, wenn die hier angegebene Belegung des Pagepools in Prozent erreicht ist.
warnlevel2	Die zweite Warnung wird ausgegeben, wenn die hier angegebene Belegung des Pagepools in Prozent erreicht ist.

Die aktuelle Belegung des Pagepools kann per Administration abgefragt werden, z.B. per Kommando KDCINF PAGEPOOL (siehe openUTM-Handbuch „Anwendungen administrieren“) oder per WinAdmin bzw. WebAdmin.

Eine andere Möglichkeit, sich genauer über die Art der im Pagepool gespeicherten Daten zu informieren, bietet das Tool KDCUPD. Dabei kann für jedes Objekt der Anwendung, z.B. für jeden Benutzer, die Anzahl der belegten Seiten angezeigt werden. Weitere Informationen dazu finden Sie im Abschnitt "Das Tool KDCUPD - KDCFILE aktualisieren".

Abschätzen der benötigten Größe des Pagepools

Die einmal festgelegte Größe des Pagepools kann bei laufender Anwendung nicht verändert werden. Es ist daher erforderlich, bereits beim Entwurf einer UTM-Anwendung die benötigte Pagepool-Größe im Betrieb abzuschätzen. Eine Änderung ist nur nach Beendigung der Anwendung möglich. Dazu generieren Sie mit dem Generierungstool KDCDEF die KDCFILE neu, wobei anschließend bestehende Benutzerdaten mit dem Tool KDCUPD aus der alten in die neue KDCFILE übernommen werden können. Weitere Informationen dazu finden Sie im Abschnitt "Das Tool KDCUPD - KDCFILE aktualisieren".

Um die Größe des Pagepools abschätzen zu können, muss man das Verhalten der Teilprogramme untersuchen und feststellen, welche Datenbereiche im Pagepool abgelegt werden und wie groß diese sind. Dabei ist zu beachten:

• Der Pagepool ist in UTM-Seiten unterteilt:
  Eine UTM-Seite ist entweder 2KB, 4KB oder 8KB groß, abhängig vom Wert des Parameters BLKSIZE= in der MAX-Anweisung.

• Für die Datenbereiche GSSB, LSSB, TLS und ULS gilt:
  Jeder einzelne dieser Datenbereiche beginnt auf einer neuen UTM-Seite. Von jeder UTM-Seite stehen dem Anwender 1994 Byte (bei 2KB-UTM-Seiten), 4042 Byte (bei 4KB-UTM-Seiten) oder 8138 Byte (bei 8KB-UTM-Seiten) für Benutzerdaten zur Verfügung. Den Rest belegt openUTM.

  openUTM bietet die Möglichkeit, die Benutzerdaten dieser Bereiche zu komprimieren, siehe Parameter DATA-COMPRESSION der MAX-Anweisung. Dies kann die Anzahl der benötigen UTM-Seiten reduzieren.

• Für Asynchron-Nachrichten gilt:
  Jede Nachricht beginnt auf einer neuen UTM-Seite. Auf der ersten UTM-Seite einer Nachricht sind mindestens 1914 Byte (bei 2KB-UTM-Seiten), 3962 Byte (bei 4KB-UTM-Seiten) oder 8058 Byte (bei 8KB-UTM-Seiten) für Anwenderdaten nutzbar. Auf jeder Folgeseite, die die Nachricht belegt, sind mindestens 2030 Byte (bei 2KB-UTM-Seiten), 4078 Byte (bei 4KB-UTM-Seiten) oder 8174 Byte (bei 8KB-UTM-Seiten) für Anwenderdaten nutzbar.

  Es ist möglich, dass in Folgeversionen von openUTM pro UTM-Seite weniger Platz für Anwenderdaten zur Verfügung steht. Sie sollten deshalb bei der Programmierung die angegebenen Maximalwerte nicht voll ausschöpfen.

• Wird ein bereits existierender Bereich geändert, dann legt openUTM den neuen Bereich bis zum Ende der Transaktion an einer anderen Stelle im Pagepool ab. Somit existiert der Bereich kurzzeitig zweimal.

  

  Bild 4: Doppelte Führung von geänderten Bereichen im Pagepool

Berücksichtigen Sie auch das Aufkommen an FPUT- und LPUT-Nachrichten. Wählen Sie daher den Pagepool nicht zu klein.

Warnungen vor einem Pagepool-Überlauf

Bei laufender Anwendung muss verhindert werden, dass der Pagepool ganz voll wird, da er auch zur Sicherung der Dialog-Nachrichten benötigt wird. Zu diesem Zweck ergreift openUTM folgende Schutzmaßnahmen:

• Es gibt zwei Warnstufen (Prozentwerte) für die Belegung des Pagepools, die per Generierung einstellbar sind. Werden diese Stufen über- bzw. unterschritten, erzeugt openUTM die Meldung K040 bzw. K041, auf die eine MSGTAC-Routine des Anwenders reagieren kann.

• Lokale Asynchron-Nachrichten sowie LPUT-Aufrufe zum Schreiben von Sätzen in die USLOG-Datei werden zurückgewiesen, wenn die Belegung des Pagepools Warnstufe 2 erreicht hat.

• Asynchron-Nachrichten von einer Partner-Anwendung über LU6.1 bzw. OSI TP werden abgelehnt, wenn die Belegung des Pagepools Warnstufe 2 erreicht hat. Die Verbindung wird abgebaut. Bei Kommunikation über OSI TP wird in beiden Anwendungen jeweils die Meldung K119 OSI-TP error information mit dem Insert DIA3=21 ausgegeben. Abhängig vom Wert in MAX CONRTIME wird zyklisch versucht, die Asynchron-Nachricht erneut an die Partner-Anwendung zu schicken.

• Ein von einem Terminal oder einer TS-Anwendung erteilter Asynchron-Auftrag wird mit der Meldung K101 abgelehnt, wenn die Belegung des Pagepools Warnstufe 2 erreicht hat.