Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Globaler Sekundärer Speicherbereich (GSSB)

GSSBs sind ebenso wie LSSBs Hintergrundspeicher. Der GSSB unterscheidet sich vom LSSB durch seine Funktion, Lebensdauer und Verwendung. Der GSSB ermöglicht die Übergabe von Daten von einem Vorgang zu einem anderen. Die Datenübergabe ist bei UTM-S-Anwendungen auch über ein Anwendungsende hinaus möglich, d.h., die Daten stehen beim erneuten Start der Anwendung zur Verfügung.

Ein GSSB kann z.B. zur Datenübergabe zwischen Dialog- und Asynchron-Vorgängen verwendet werden, wenn Sie keine Service-gesteuerten Queues einsetzen, siehe "Nachrichten an Service-gesteuerte Queues".

Der GSSB steht allen Vorgängen offen. Daher müssen Sie für eine eindeutige Namensvergabe in allen Teilprogrammen der Anwendung sorgen. Von einem SPUT, SGET oder SREL-Aufruf bis zum Ende einer Transaktion ist ein GSSB für einen Vorgang reserviert. Damit werden Mehrfachzugriffe verhindert. Ein Aufruf aus einem anderen Vorgang auf den reservierten GSSB wartet, bis dieser wieder frei ist. openUTM sperrt jeweils den GSSB vom Zugriffszeitpunkt bis zum Ende einer Transaktion (siehe auch Abschnitt „Verhalten bei gesperrten Speicherbereichen (TLS, ULS und GSSB)").
Die maximale Wartezeit lässt sich bei der Generierung festlegen (KDCDEF-Anweisung MAX, Operand RESWAIT, Wert time1). Mit dem UNLK-Aufruf können Sie einen GSSB explizit entsperren, d.h. vorzeitig für einen eventuell wartenden Vorgang freigeben, sofern der GSSB nur gelesen wurde.

Ein GSSB (und auch sein Name) wird durch einen SPUT-Aufruf erzeugt.
Der Inhalt eines GSSB bleibt solange erhalten, bis er in einem Teilprogramm mit dem SREL-Aufruf freigegeben wird. Seine Lebensdauer ist nicht begrenzt. Auch nach einer Betriebsunterbrechung wird er für die UTM-Anwendung wieder bereitgestellt, wenn bei einer stand-alone-Anwendung die gleiche Datei KDCFILE wie vorher benutzt wird oder wenn die Benutzerdaten mit dem Tool KDCUPD in eine neue KDCFILE übertragen wurden.

Ein Teilprogramm kann sich mit dem KDCADMI-Aufruf KC_GET_OBJECT (Objekttyp: KC_GSSB) über die Namen aller existierenden GSSBs informieren.

Die maximale Anzahl der GSSBs, die erzeugt werden können, wird beim Generieren der Anwendung festgelegt (MAX-Anweisung, Operand GSSBS, siehe auch openUTM-Handbuch „Anwendungen generieren“).

Unix-, Linux- und Windows-Systeme
In UTM-Cluster-Anwendungen werden GSSBs Cluster-weit unterstützt. D.h. sie werden im Cluster-Pagepool gespeichert und stehen somit für alle Benutzer in allen Knoten-Anwendungen zur Verfügung. Dadurch haben alle Knoten-Anwendungen dieselbe Sicht auf die Daten des Speicherbereichs, siehe auch „Speicherort von Benutzerdaten“ (Die KDCS-Speicherbereiche bei openUTM).

Der Inhalt eines GSSB bleibt solange erhalten, bis er in einem Teilprogramm mit dem SREL-Aufruf freigegeben wird. Seine Lebensdauer ist nicht begrenzt. Auch nach einer Betriebsunterbrechung wird er für die UTM-Anwendung wieder bereitgestellt, wenn bei einer UTM-Cluster-Anwendung der gleiche Cluster-Pagepool wie vorher benutzt wird oder wenn die Benutzerdaten mit dem Tool KDCUPD in eine neue KDCFILE bzw. den neuen Cluster-Pagepool übertragen wurden.