In BS2000, both global subsystems that are valid throughout the system and local subsystems can be grouped together to form a local subsystem configuration and administered task-local in a local subsystem catalog. Whenever reference is made in the following to subsystems, configuration and catalog, what is meant is always the global subsystems valid throughout the system, and their configuration and catalog. Local subsystems, their configuration and catalog are always identified by the word “local”.
Subsystem
Within the context of dynamic subsystem management (DSSM), a subsystem is a unit that executes a function and that can be loaded, started and terminated automatically and independently, taking into account dependency relations to other subsystems.
A subsystem may consist of a number of subsystem components.
Each subsystem is identified uniquely to DSSM by its name and version number. A subsystem is defined for DSSM by specifying its components and attributes.
The attributes of a subsystem provide information on:
identification (name and version)
access privileges
loading and processing mechanisms
environment and dependency relations
required address spaces
call-up preferences
existing call entries
The relations between different subsystems are marked by
address space separations
link relations
functional dependencies
holder task sharing
Subsystem components
The term “subsystem components” is used to denote the subsystem module (program module) and the ancillary components, known as “subsystem satellites”.
The subsystem module is a component that is absolutely essential for installing the subsystem. A subsystem may be composed of a number of different modules.
Satellites for subsystems include REP files, NOREF files, message files, syntax files and information files; these files must be declared during installation and will be required to activate the subsystem.
Subsystem call entries
The subsystem call entry is the visible point of entry through which the subsystem is accessible to user tasks.
A call entry is characterized by its name, type, scope and lifetime. A subsystem may have a number of call entries with different attributes. They are administered by DSSM.
Subsystem configuration
A subsystem configuration is the set of all subsystems that are to be available in a session. Since only one subsystem configuration can be operated in the system at a given time, this configuration must contain all the subsystems that have to be available in the system at the same time.
A subsystem configuration is defined by its subsystems and their components and attributes.
A subsystem (or subsystem version) may be compatible within a given subsystem configuration and in a certain combination, i.e. the subsystem can run in the system with certain other subsystems. A subsystem may be optional or mandatory, i.e. the subsystem configuration may or may not run without this subsystem.
When the system is in operation, a given subsystem configuration may be in one of two states:
Load state:
the subsystems of the configuration are currently active, i.e. can actually be used;Declaration state:
the subsystems or subsystem versions of the configuration are defined in the subsystem catalog, i.e. could be activated.
Several different load states can be derived from a declaration state.
Subsystem catalog
Static subsystem catalog management (SSCM) generates a static subsystem catalog (SSMCAT) in which the subsystem configuration is defined.
This subsystem catalog is loaded by dynamic subsystem management (DSSM) when the system is started up. Once loaded, the static subsystem catalog becomes a dynamic subsystem catalog.
During the session the subsystem catalog can be managed by means of the DSSM commands ADD-SUBSYSTEM, MODIFY-SUBSYSTEM-PARAMETER and REMOVE-SUBSYSTEM.
Both SSCM and DSSM use the data structure of the static subsystem catalog.
The subsystem catalog can contain up to 1000 subsystems with maximum totals of
16,000 call entries, 16,000 functional dependencies and 200 address space restrictions.