Error handling in DSSM

DSSM task error

1. DSSM terminates abnormally during the first step of startup if, for example, subsystems are activated that were defined with the attribute *BEFORE-DSSM-LOAD or *AT-DSSM-LOAD. An error code is sent to the startup task.
   Normally, startup is aborted. However, under certain circumstances it may be continued without DSSM initialization (depending on how startup is implemented).

   For information on the startup steps see "MODIFY-SUBSYSTEM-ATTRIBUTES" or the manual “Introductory Guide to Systems Support” [14].

2. DSSM terminates abnormally during the second step of startup if, for example, subsystems are activated that were defined with the attribute *MANDATORY-AT-STARTUP or *BEFORE-SYSTEM-READY or while the data structures of a subsystem with the attribute *AFTER-SYSTEM-READY are being updated. If DSSM attempted to activate one of these subsystems, its status is changed to LOCKED.

   A return code is sent to the startup task when a subsystem with *MANDATORY-AT-STARTUP is put in the LOCKED status. Whether or not startup is aborted depends on how startup is implemented.

3. DSSM terminates abnormally during shutdown if the subsystem which is to be deactivated is in the LOCKED status.
   The shutdown of other subsystems continues normally.

4. Other causes that lead to abnormal DSSM termination:
   DSSM analyzes the situation, restores the integrity of its internal tables and makes the following decisions, depending on where the error occurred:

   The error occurs during ...	Reaction
   CREATE/DELETE/RESUME/HOLD	Subsystem LOCKED (with error message)
   the swapping of subsystem versions	The faulty routine is called again; if it again results in the error,
   with interrupted availability	the version concerned are placed in the LOCKED status,
   without interrupted availability	both subsystem versions are placed in the LOCKED status.
   ADD-/MODIFY-SUBSYSTEM-PARAMETER, REMOVE-SUBSYSTEM	The statement is aborted; parts of the catalog may already have been changed.
   restoration of the holder task	Restoration is aborted.
   SHOW-SUBSYSTEM-INFO, SAVE-CATALOG	The request is terminated abnormally.

   After restoring the integrity of the tables, DSSM resumes its work with the requests waiting in the DSSM bourse.

Holder task error

If problems occur in the holder task or it is terminated abnormally, DSSM analyzes the situation, automatically initiates the restart of the holder task and makes the following decisions:

The problem occurs ...	Reaction to the holder task error when
	RESTART-REQUIRED=*YES	RESTART-REQUIRED=*NO
when normal demands are being made on the subsystem
Activation	Subsystem LOCKED	Subsystem LOCKED
INIT routine	INIT routine called	Subsystem LOCKED
CLOSE-CTRL routine	Subsystem CREATED	Subsystem LOCKED
STOPCOM routine	INIT routine called	Subsystem LOCKED
DEINIT routine	Deinitialization continued	Subsystem LOCKED
Deactivation	Subsystem LOCKED	Subsystem LOCKED
Subsystem session (work task)	INIT routine called	Subsystem LOCKED
when swapping subsystem versions and interrupting availability
Activation of V2	Subsystem V2 LOCKED and swap aborted	Subsystem V2 LOCKED and swap aborted
STOPCOM routine of V1	Subsystem V1 LOCKED and INIT routine for V2 called	Subsystem V1 LOCKED and INIT routine for V2 called
INIT routine of V2	INIT routine of V2 called and DEINIT routine of V1 continued	Subsystem V2 LOCKED and DEINIT routine of V1 continued
Deactivation of V1	Subsystem V1 LOCKED	Subsystem V1 LOCKED
DEINIT routine of V1	Subsystem V1 LOCKED	Subsystem V1 LOCKED
when swapping subsystem versions without interrupting availability
Activation of V2	Subsystem V2 LOCKED and swap aborted	Subsystem V2 LOCKED and swap aborted
CLOSE-CTRL routine of V1	Swap aborted (subsystem V1 CREATED)	Subsystem V1 LOCKED and unloading of V1
INIT routine of V2	INIT routine of V2 called and DEINIT routine of V1 continued	Subsystem V2 LOCKED and swap aborted
STOPCOM routine of V1	Subsystem V1 LOCKED	Subsystem V1 LOCKED
DEINIT routine of V1	Subsystem V1 LOCKED	Subsystem V1 LOCKED
Deactivation of V1	Subsystem V1 LOCKED	Subsystem V1 LOCKED

Error log SERSLOG

DSSM writes an entry in the SERSLOG error log whenever

• a system call is faulty,

• inconsistent data is detected in the internal subsystem catalog or

• the DSSM task terminates abnormally (in this case, the SERSLOG entry contains a message describing the current situation).

The entry may consist of up to three parts:

1. the parameter list of the faulty system call or the inconsistent data (in 2K units),

2. the return code (if it is not already included in the parameter list) and

3. the address of the faulty routine and the address of the routine that called the faulty routine. This entry is useful for diagnostic purposes because DSSM uses its own central SERSLOG call.