SREL Delete secondary storage area

You use the SREL (storage release) call to delete a secondary storage area. A secondary storage area can be

• the global secondary storage area (GSSB

• the local secondary storage area (LSSB)

Blocks of a ULS (user-specific long-term storage) cannot be deleted using SREL, since their names are specified when the application is generated. If you want to delete the contents of a ULS block, you have to overwrite the block with length zero.

Unix, Linux and Windows systems
In UTM cluster applications, a GSSB is valid throughout the cluster. Its deletion with SREL therefore also applies throughout the cluster.

Setting the 1st parameter (KDCS parameter area)

The table below shows the various options and the necessary entries in the KDCS parameter area.

Function of the call	Entries in the KDCS parameter area
	KCOP	KCOM	KCRN
Delete LSSB	"SREL"	"LB"	Name of the LSSB
Delete GSSB	"SREL"	"GB"	Name of the GSSB

Setting the parameters
Field name in the KDCS parameter area	Contents
KCOP	"SREL"
KCOM	"LB"/"GB"
KCRN	Name of the area

KDCS call
1st parameter	2nd parameter
KDCS parameter area	—

C/C++ macro call
Macro names	Parameters
KDCS_SRELGB / KDCS_SRELLB	(kcrn)

openUTM return information
Field name in the KB return are	Contents
KCRCCC	Return code
KCRCDC	Internal return code

For the SREL call you make the following entries in the KDCS parameter area:

KCOP

In the KCOP field, the SREL operation code.

KCOM

In the KCOM field

• LB to delete an LSSB, or

• GB to delete a GSSB

KCRN

In the KCRN field, the name of the LSSB/GSSB to be deleted

You specify the following for the KDCS call:

1st parameter

The address of the KDCS parameter area.

Macro names

The use of C/C++ calls is described in detail in the section "C/C++ macro interface".

openUTM returns:

KCRCCC

in the KCRCCC field: the KDCS return code.

KCRCDC

in the KCRCDC field: the internal return code of openUTM (see the openUTM manual ”Messages, Debugging and Diagnostics”).

KDCS return codes in the KCRCCC field for the SREL call

The following codes can be analyzed in the program:

000	Operation carried out.
14Z	No area exists with the name specified in KCRN.
40Z	System cannot perform the operation (generation error or system error, deadlock, timeout), see KCRCDC.
42Z	Entry in KCOM is invalid.
44Z	Name in KCRN invalid (if it consists solely of blanks or binary zero).

An additional error code can be found in the dump:

71Z	INIT missing in this program.

Features of the SREL call

• openUTM does not execute SREL until the end of the current transaction.

• SREL is not executed

• • for service interrupt via PEND ER/FR, or

  • if there is a subsequent PEND RS or RSET call.

• An SREL call locks the area called until the end of the transaction or UNLK or until the next rollback operation. In other words, openUTM rejects subsequent SGET calls to this area with the return code 14Z. However, if an SREL call is followed by an SPUT call with the same area name, this area (LSSB or GSSB) is set up anew.

  The lock continues to apply after the end of a processing/dialog step when the program unit run is terminated or interrupted with:

• • PEND KP and PGWT KP

  • PEND PA/PR with a task change due to TAC class control

  • PEND PA/PR or PGWT PR with waiting for a DGET message

  If this area is a GSSB, then other services cannot access this GSSB either with SGET or with SPUT until the end of the transaction. The section "Action with locked storageareas (TLS, ULS and GSSB)" describes how openUTM reacts in this case

• At the end of a service (PEND FI/FC) or service interrupt (PEND ER/FR, possibly also PEND RS), openUTM automatically deletes all LSSBs. SREL calls to LSSBs are therefore superfluous in transactions which terminate services.

• Unix, Linux and Windows systems
  In UTM cluster applications, an SREL call deletes a GSSB throughout the entire cluster, i.e. as soon as the SREL call takes effect, the GSSB can no longer be read in any of the node applications.

The following table describes the effect of the call sequences SREL ... RSET and SREL ... PEND on GSSBs and LSSBs.

Call		Effect on GSSB	Effect on LSSB
SREL		deletes and locks (operation remains resettable)	deletes (operation remains resettable)
...	RSET PEND RS PGWT RB	resets and unlocks	resets
...	PEND KP PGWT KP	leaves the operation resettable	leaves the operation resettable
...	PEND RE PEND SP PGWT CM	deletes and unlocks (operation not resettable)	deletes (operation not resettable)
...	PEND FI PEND FC		deletes all LSSBs
...	PEND ER PEND FR	resets and unlocks	deletes all LSSBs
...	PEND PA/PR1 PGWT PR1	lock remains, operation resettable	lock remains, operation resettable

¹ With a task change due to TAC class control or with waiting for a DGET message