UTM-Speicherbereiche

openUTM bietet Teilprogrammen zum Schreiben und Lesen von Benutzerdaten verschiedene Speicherbereiche. Durch diese Speicherbereiche wird eine klare Trennung von Programm- und Datenbereichen gewährleistet und die Reentrant-Fähigkeit der Programme sichergestellt. Außerdem ermöglichen die Bereiche einen hochperformanten und transaktionsgesicherten Austausch von Informationen zwischen Programmen und sorgen für effektiven Arbeitsspeichereinsatz. Einige Speicherbereiche sind speziell für statistische Zwecke und für die Protokollierung konzipiert.

Service-gesteuerte Queues können in diesem Sinne ebenfalls als UTM-Speicherbereiche betrachtet werden. Da Service-gesteuerte Queues speziell für das Message Queuing konzipiert sind, werden sie gesondert im Kapitel „Message Queuing" ab "Service-gesteuerte Queues" beschrieben.

Primärspeicherbereiche

Dies sind Speicherbereiche, die den Teilprogrammen im Arbeitsspeicher zur Verfügung stehen:

• Kommunikationsbereich (KB)

  openUTM legt den KB an, wenn ein neuer Service gestartet wird. Sein Inhalt wird dem jeweils aktuell ausgeführten Teilprogramm übergeben. Im KB stellt openUTM den Teilprogrammen aktuelle Informationen zur Verfügung. Der KB dient außerdem zum Informationsaustausch zwischen den Teilprogrammen eines Services. Er kann in seiner Größe den zu übergebenden Daten angepasst werden. Der KB unterliegt der Transaktionssicherung und bleibt solange erhalten, bis der Service abgeschlossen ist.

• Standardprimärer Arbeitsbereich (SPAB)

  openUTM ordnet jedem Teilprogramm standardmäßig einen SPAB zu. Er steht dem Teilprogramm vom Programmstart bis zum Programmende (PEND-Aufruf) zur Verfügung. In diesem Bereich können deshalb keine Daten über das Ende eines Teilprogrammlaufs hinaus aufbewahrt oder weitergegeben werden. Der SPAB kann für den Parameterbereich genutzt werden, in dem das Teilprogramm bei KDCS-Aufrufen die Parameter bereitstellt. Außerdem lässt sich der SPAB z.B. zur Pufferung von Nachrichten verwenden. Da der SPAB nur als Teilprogramm-spezifischer Arbeitsbereich dient, ist er nicht in die Transaktionssicherung einbezogen und wird von einem RSET-Aufruf nicht zurückgesetzt. Ein Vorteil des SPABs gegenüber anderen Programmspeichern (z.B. Stacks) ist die Tatsache, dass der SPAB im UTM-Dump ausgegeben wird.

• Weitere Datenbereiche (AREAs)

  Ein Teilprogramm kann weitere Bereiche zur Speicherung von Daten verwenden. Diese Bereiche werden bei der Generierung mit der KDCDEF-Anweisung AREA vereinbart und müssen vom Anwender selbst verwaltet werden, sie unterliegen nicht der Transaktionssicherung. Die Struktur dieser Bereiche ist von openUTM nicht vorgegeben, sondern frei definierbar.

Sekundärspeicherbereiche

Diese Speicherbereiche werden von openUTM auf Hintergrund-Speicher realisiert und unterliegen der Transaktionssicherung. Sie werden mit speziellen KDCS-Aufrufen geschrieben und gelesen:

• Lokaler Sekundärspeicherbereich (LSSB)

  Der LSSB ist ein Service-spezifischer Hintergrundspeicher, der zur Weitergabe von Daten zwischen Teilprogrammen innerhalb eines Services dient. Während openUTM den Kommunikationsbereich jedem Teilprogramm automatisch zur Verfügung stellt und danach sichert, wird auf den LSSB nur bei Bedarf zugegriffen. Er eignet sich deshalb besonders für Daten, auf die nur lesend zugegriffen wird, oder wenn zwischen Schreiben und Lesen der Daten mehrere Teilprogramme liegen, in denen die Daten nicht benötigt werden. Der LSSB bleibt solange erhalten, bis er explizit freigegeben wird oder der Service abgeschlossen ist.

• Globaler Sekundärspeicherbereich (GSSB)

  Der GSSB ist ein Hintergrundspeicher, der die beliebige Übergabe von Daten zwischen Services einer UTM-Anwendung ermöglicht. Er bleibt, falls er nicht explizit freigegeben wird, auch über das Anwendungsende hinaus erhalten.

  In UTM-Cluster-Anwendungen sind GSSBs Cluster-weit nutzbar, alle Knoten-Anwendungen haben dieselbe Sicht auf die Daten eines GSSB.

• Terminal-spezifischer Langzeitspeicher (TLS)

  Der TLS ist einem Anschlusspunkt (LTERM-, LPAP- oder OSI-LPAP-Partner) zugeordnet und dient zur Aufnahme von Informationen, die unabhängig von der Dauer eines Services und der Betriebszeit der Anwendung zur Verfügung stehen sollen. Er kann z.B. verwendet werden, um eine Statistik für einen LTERM-Partner zu erstellen.

  In UTM-Cluster-Anwendungen werden TLS nur Knoten-lokal unterstützt.

• User-spezifischer Langzeitspeicher (ULS)

  Jeder Benutzerkennung kann bei der Konfigurierung ein ULS zugewiesen werden. Er dient zur Aufnahme von Informationen, die unabhängig von der Lebensdauer der Vorgänge und der Betriebszeit der Anwendung zur Verfügung stehen sollen. Er kann z.B. verwendet werden, um Statistiken für jede Benutzerkennung zu führen.

  Ein ULS wird auch einer Session (LU6.1) und einer Association (OSI TP) zugeordnet.

  In UTM-Cluster-Anwendungen sind ULS Cluster-weit nutzbar, alle Knoten-Anwendungen haben dieselbe Sicht auf die Daten eines ULS.

Benutzer-Protokolldatei (User-Logging-Datei USLOG)

Die Benutzer-Protokolldatei ist eine von openUTM verwaltete Protokolldatei, in die mit dem KDCS-Aufruf LPUT Benutzer-spezifische Informationen geschrieben werden können. Sie ist als Datei-Generationsgruppe realisiert (siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen“). In der Benutzer-Protokolldatei lassen sich beispielsweise versuchte Zugriffsschutzverletzungen protokollieren.

In UTM-Cluster-Anwendungen hat jede Knoten-Anwendung ihre eigene Benutzer-Protokolldatei.

Die Benutzer-Protokolldatei unterliegt der Transaktionssicherung und ist daher nicht für eine allgemeine Protokollfunktion geeignet, da beim Rücksetzen einer Transaktion die LPUT-Informationen verworfen werden.

 

Übersicht: UTM-Speicherbereiche

Kurzname	Bereichstyp	Lebensdauer	Funktion	Transaktions- sicherung
KB	Kommunikationsbereich	Start des Service bis Ende des Service	Zugriff auf aktuelle, von openUTM bereitgestellte Information; Datenaustausch zwischen Teilprogrammen eines Service	ja
SPAB	Standard Primärer Arbeitsbereich	Start des Teilprogramms bis Ende des Teilprogramms	Parameterübergabe bei KDCS-Aufrufen; Nachrichtenpuffer	nein
AREA	Per Generierung vereinbarter weiterer Speicherbereich	Dauer der Anwendung	Aufnahme von anwendungsglobalen Daten, die vorzugsweise nur gelesen werden; In UTM-Cluster-Anwendungen sind AREAs nur Knoten-lokal.	nein
LSSB	Lokaler Sekundärer Arbeitsbereich	vom ersten Schreibaufruf bis zur expliziten Freigabe oder bis Service-Ende	Datenaustausch zwischen Teilprogrammen eines Service	ja
GSSB	Globaler Sekundärer Arbeitsbereich	vom ersten Schreibaufruf bis zur expliziten Freigabe oder bis zum Löschen der Anwendungsinformation	Austausch von Daten über Service-Grenzen hinweg	ja
ULS	User-spezifischer Langzeitspeicher	Generierung bis Änderung der Generierung	z.B. Statistiken spezifisch für bestimmte Benutzerkennungen, Sessions oder Associations	ja
TLS	Terminal-spezifischer Langzeitspeicher	Generierung bis Änderung der Generierung	Statistiken spezifisch für bestimmte Anschlusspunkte (LTERMs, LPAPs, OSI-LPAPs)	ja
USLOG	Benutzer-Protokolldatei (User-Logging)	individuell festlegbar	Protokollierung	ja