GSSBs are background storage areas just like LSSBs. The GSSB differs from the LSSB in its function, lifetime and application. The GSSB permits the transfer of data from one service to another. Data transfer is also possible after the end of an application run in UTM-S applications, i.e. data remains available to the application after restart.
You can, for example, use a GSSP to transfer data between dialog and asynchronous services if you do not use service-controlled queues (see "Messages to service-controlled queues").
It is open to all services. You must therefore define an unambiguous name in all the program units of an application. A GSSB is reserved for a service from an SPUT, SGET or SREL call until the end of the transaction. This prevents multiple accesses. A call from another service to the reserved GSSB waits until this is free again. openUTM locks the GSSB from the time of access to the end of a transaction (see also the section "Action with locked storage areas (TLS, ULS and GSSB)").
You define the maximum wait period at generation time (KDCDEF statement MAX, operand RESWAIT, value time1). The UNLK call explicitly unlocks a GSSB, i.e. releases it prematurely for a waiting service, provided that the GSSB has only been read.
You call SPUT to create a GSSB (and its name).
The contents of a GSSB are maintained until it is released in a program unit by means of the SREL call. Its life is not limited. It is thus again made available to a UTM application after an interruption of operation provided that, in the case of a standalone application, the same KDCFILE is used as before the interruption or if the user data has been transferred to a new KDCFILE using the KDCUPD tool.
In a program unit, you can use the KDCADMI call KC_GET_OBJECT (object type: KC_GSSB) to ascertain the names of all currently existing GSSBs.
You define the maximum number of GSSBs which can be generated when you generate the application (MAX statement, operand GSSBS=, see also the openUTM manual “Generating Applications”).
Unix, Linux and Windows systems
In UTM cluster applications, GSSBs are supported throughout the cluster. I.e. they are stored in the cluster page pool and are therefore available for all users in all node applications. This means that all the node applications have the same view of the data in the storage area, see also “Storage location for user data” (KDCS storage areas in openUTM).
The contents of a GSSB are maintained until it is released in a program unit by means of the SREL call. Its life is not limited. It is thus again made available to a UTM application after an interruption of operation provided that, in the case of a UTM cluster application, the same cluster page pool is used as before the interruption or if the user data has been transferred to the new cluster page pool using the KDCUPD tool.