The purpose of dynamic subsystem management (DSSM) is to reduce the complexity of BS2000 operation by dividing the operating system into functional units (subsystems).
DSSM supports the following as subsystems:
software products (if expressly designated as DSSM-compatible, see Tables 1 and 2 as of "Overview of important DSSM-compatible products in the BS2000 basic configuration"),
system exit routines and
shared products.
In addition, system administration can make customized TU programs and system exit routines DSSM-compatible and activate them as subsystems.
DSSM functions distinguish between privileged subsystems (TPR subsystems), which are part of BS2000, and nonprivileged (or unprivileged) subsystems (TU subsystems), such as user programs.
DSSM also distinguishes between subsystems that are loaded in system address space and those that are loaded in user address space. TPR subsystems are always loaded in system address space, whereas TU subsystems can be loaded either in system address space or in user address space.
The SSCM subsystem enables flexible and user-friendly management of the static subsystem catalog (SSMCAT).
The SSD object
The SSD object is an ISAM file with a key length of 11 bytes. It contains the definition(s) of one or more subsystems (but not the definitions of different versions of one and the same subsystem).
Each of these definitions contains attributes, call entries, references and dependencies of the relevant subsystem, as well as information on disjunctive subsystems and the holder task.
The SSD object itself cannot be loaded. Before it can be activated, it must be linked into a static subsystem catalog using the SSCM statement ADD-CATALOG-ENTRY.