Define attributes and entry points of subsystem
Function
This statement enables all the attributes and entry points for a subsystem to be set.
The way in which the definition of a new subsystem will be compiled depends on what statement preceded the definition:
After a START-CATALOG-CREATION statement, the subsystem can be integrated into the catalog.
After a START-SSD-CREATION statement, the subsystem can be integrated into the SSD object.
However, it is not permissible to set up different versions of the same subsystem in the same SSD object.
Subsystems defined with the operand MEMORY-CLASS=*SYSTEM-GLOBAL ..., SUBSYSTEM-ACCESS=*SYSTEM are privileged subsystems.
When setting up the definition, the following points should be noted:
The name and version of the subsystem must not already be present in the subsystem catalog.
Two different versions of one and the same subsystem cannot be defined in the same SSD object.
The subsystem name CP is reserved for DSSM and must not be specified.
The names of the entry points must not be present in duplicate.
The name of the subsystem which is being defined must not be included in the list of subsystems to which there are address or dependency relations.
Within this list, a subsystem name must not appear more than once.
SET-SUBSYSTEM-ATTRIBUTES is rejected if none of the following statements were executed beforehand:
START-SSD-CREATION
START-CATALOG-CREATION
START-CATALOG-MODIFICATION
Note on syntax
The special data type <symbol>, which is described in detail in the “BLSSERV” manual [4], can also be used for the names of the entry points in the following operands (in the format, the data type is specified as <name>):
LINK-ENTRY
DEINIT-ROUTINE
DYNAMIC-CHECK-ENTRY
INTERFACE-VERSION
INIT-ROUTINE
SUBSYSTEM-ENTRIES
CLOSE-CTRL-ROUTINE
STOPCOM-ROUTINE
Format
SET-SUBSYSTEM-ATTRIBUTES | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Operands
SUBSYSTEM-NAME = <structured-name 1..8>(...)
Specifies the name and version of the subsystem which is to be defined.
VERSION = <c-string 3..8> / <text 3..8>
The version of the subsystem must be specified in the format “[V][n]n.m[ann]”. The text elements have the following meanings:
nn = Main version (numeric)
m = Revision version (numeric)
ann = Update status (a=letter, release status; nn=numeric, correction status)
INSTALLATION-UNIT =
Defines the name of the installed software unit. A value other than *NONE must be specified for all subsystems installed with IMON, and likewise if the value
*INSTALLED(LOGICAL-ID=...) was defined for the operand SUBSYSTEM-LIBRARY, REP-FILE, SUBSYSTEM-INFO-FILE, MESSAGE-FILE or SYNTAX-FILE.
The syntax rules described in the “IMON“ manual [18] must be observed when defining the name.
INSTALLATION-UNIT = *NONE
Default setting: no name is assigned. This default setting is not allowed for any subsystems installed with IMON.
INSTALLATION-UNIT = *STD
The name specified via the SUBSYSTEM-NAME operand is used as the name of the installed software unit.
INSTALLATION-UNIT = <text 1..30>
Name of the installed software unit.
INSTALLATION-USERID =
Defines a user ID under which the relevant DSSM task expects the subsystem satellites (REP file, object module library, message file, syntax file and subsystem information file) if these files have not yet been assigned to a user ID, i.e. the file name was specified without a user ID.
INSTALLATION-USERID = *NONE
Default value: the files will not be expected under a specific user ID.
INSTALLATION-USERID = *DEFAULT-USERID
The files are expected under the default system ID (prefix “$.”) or under the user ID of the calling task if the subsystem is a local subsystem.
INSTALLATION-USERID = <name 1..8>
User ID under which the subsystem satellites are to be expected.
If this statement applies to an SSD object, the files will only actually be expected under the user ID specified here if no user ID was specified in the ADD-CATALOG-ENTRY statement (inclusion of subsystem definitions from the SSD object in the catalog). The ID specified in ADD-CATALOG-ENTRY takes precedence.
COPYRIGHT =
Specifies whether or not a copyright notice is to be displayed when the subsystem is started and, if so, which one.
COPYRIGHT = *NONE
Default value: no copyright notice is to be output.
COPYRIGHT = <c-string 1..54>(...)
Text of the copyright notice which is to be output together with the creation date when the subsystem is started.
YEAR = *YEAR-1990 / <c-string 4..4>
Number of the year which is to appear in the statement as the creation date. This is not subjected to a semantic check.
LIBRARY =
Specifies the name of the program or object module library (OML) from which the object code for the subsystem is to be loaded when it is activated.
LIBRARY = *STD
Default value: when the subsystem is started, the object code will automatically be loaded from the library SYSLNK.<subsysname>.<subsysvers#>. This library is stored under the user ID under which the holder task is running. For local subsystems this is the user ID of the caller, and for global subsystems it is TSOS. “<subsysvers#>” is a three-character value consisting of the elements “mmm” (for the operand SUBSYSTEM-NAME=...(VERSION=...)).
LIBRARY = *CPLINK
The subsystem which is to be defined is linked to the BS2000 control program (CP) and must have been loaded before DSSM was activated. This operand may only be used in conjunction with the operand CREATION-TIME=*BEFORE-DSSM-LOAD.
LIBRARY = *INSTALLED(...)
The library name must be determined by calling IMON (administration of installation paths). If one of the subsystem satellites is referenced with a logical ID, logical IDs must be specified for all satellites belonging to the subsystem. If a logical ID is assigned, a value other than *NONE must be assigned for the INSTALLATION-UNIT operand.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logical ID of the program library or object module library.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
New library name if IMON-GPN is not available or if the logical name is unknown.
LIBRARY = <filename 1..54 without-gen-vers>
Fully qualified file name of the object module library from which the object code for the subsystem is to be loaded.
SUBSYSTEM-LOAD-MODE =
Specifies the load mode of the subsystem (via the BLS-DSSM interface $PBBND1).
SUBSYSTEM-LOAD-MODE = *ANY
Default value: the BLS (Binder-Loader-Starter system) is called up in STD run mode and loads the subsystem as an object module. If an error occurs during loading, BLS will be called a second time. The call takes place in ADVANCED run mode, and the subsystem is loaded as a link and load module (LLM).
Support for this operand value is provided only for the sake of compatibility.
SUBSYSTEM-LOAD-MODE = *STD
The BLS is called up in STD run mode and loads the subsystem as an object module.
SUBSYSTEM-LOAD-MODE = *ADVANCED
The BLS is called up in ADVANCED run mode and loads the subsystem as a link and load module (LLM).
REP-FILE =
Specifies whether or not system REPs are required for the subsystem which is being defined, and identifies the file in which they are stored. These correction statements are used during activation of the subsystem, and are applied solely to the modules stored and loaded in the object module library, not to other subsystems or the BS2000 control program. A REP file can also be specified for modules of a nonprivileged subsystem.
REP-FILE must not be specified together with LIBRARY=*CPLINK.
REP-FILE = *STD
Unless another file is specified, system REPs are loaded from the REP file with the nameSYSREP.<subsysname>.<subsysvers#>. This REP file is stored under the user ID under which the holder task is running. For local subsystems this is the user ID of the caller, and for global subsystems it is TSOS.
“<subsysvers#>” is a three-character value consisting of the elements “mmm” specified for the operand SUBSYSTEM-NAME=...(VERSION=...).
REP-FILE = *NO
No REP files are to be processed for the subsystem.
REP-FILE = *INSTALLED(...)
The name of the REP file must be determined by calling IMON-GPN (administration of installation paths). If one of the subsystem satellites is referenced with a logical ID, logical IDs must be specified for all satellites belonging to this subsystem. If a logical ID is assigned, a value other than *NONE must be assigned for the INSTALLATION-UNIT operand.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logical ID of the REP file.
DEFAULT-NAME =
Name of the REP file if IMON-GPN is not available or if the logical ID is unknown.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
A new name is assigned.
DEFAULT-NAME = *NONE
No new name is assigned.
REP-FILE = <filename 1..54 without-gen-vers>
Fully qualified name of the REP file from which the correction statements are to be read.
REP-FILE-MANDATORY =
Specifies whether or not a REP file declared via the REP-FILE operand is to be processed when loading the subsystem.
REP-FILE-MANDATORY = *NO
Default value: the use of a REP file is not mandatory, i.e. neither the REP file nor its entries are to be checked when the subsystem is activated. Even if the REP file can‘t be accessed or if individual correction statements are invalid, the subsystem will still be started.
REP-FILE-MANDATORY = *YES
If any of the following errors occurs during processing of the REP file, any attempt to load the subsystem will be terminated:
the REP file is not cataloged, or it cannot be read
checking of the correction statements reveals an error
the name of a correction statement is invalid
DMS reports an error during access to the NOREF file (this file is used during loading of a subsystem to prevent invalid system REPs from being logged at the operator terminal)
MESSAGE-FILE =
Specifies whether there is a subsystem-specific message file which is to be automatically activated when the subsystem is loaded. For subsystems which are defined with the creation time AT-DSSM-LOAD, a dependency relation to the MIP subsystem must be specified in the RELATED-SUBSYSTEMS operand.
MESSAGE-FILE = *NO
Default value: no message file is to be activated. This value is mandatory for all subsystems which are defined with the creation time BEFORE-DSSM-LOAD (see also the CREATION-TIME operand), as it is not possible to activate a message file as early as this.
MESSAGE-FILE = *INSTALLED(...)
The name of the message file must be determined by calling IMON-GPN (administration of installation paths).
If one of the subsystem satellites is referenced with a logical ID, logical IDs must be specified for all satellites belonging to the subsystem. If a logical ID is assigned, a value other than *NONE must be assigned for the INSTALLATION-UNIT operand.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logical ID of the message file.
DEFAULT-NAME =
Name of the message file if IMON-GPN is not available or if the logical ID is unknown.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
A new name is assigned.
DEFAULT-NAME = *NONE
No new name is assigned.
MESSAGE-FILE = <filename 1..54 without-gen-vers>
Fully qualified name of the message file. This will be automatically activated when the subsystem is loaded (START-SUBSYSTEM command) and automatically deactivated when it is unloaded (STOP-SUBSYSTEM).
SUBSYSTEM-INFO-FILE =
Specifies whether or not a subsystem information file (SSINFO) is available. This file contains subsystem-specific data (subsystem satellites and configuration data) which cannot be processed centrally by DSSM.
SUBSYSTEM-INFO-FILE = *NO
Default value: no information file is available for the subsystem.
SUBSYSTEM-INFO-FILE = *INSTALLED(...)
The name of the information file must be determined by calling IMON-GPN (administration of installation paths).
If one of the subsystem satellites is referenced with a logical ID, logical IDs must be specified for all satellites belonging to this subsystem. If a logical ID is assigned, a value other than *NONE must be assigned for the INSTALLATION-UNIT operand.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logical ID of the information file.
DEFAULT-NAME =
Name of the information file if IMON-GPN is not available or if the logical ID is unknown.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
A new name is assigned.
DEFAULT-NAME = *NONE
A new name is assigned.
SUBSYSTEM-INFO-FILE = <filename 1..54 without-gen-vers>
Fully qualified name of the information file. This name is automatically passed to the activation and deactivation routines (INIT-/DEINIT-/STOPCOM-/CLOSE-CTRL-ROUTINE operands) when they are called.
SYNTAX-FILE =
Specifies whether the subsystem has linked to it a syntax file which will be activated automatically when the subsystem is loaded. For subsystems which are defined with the start attribute MANDATORY-AT-STARTUP, a dependency relation to the SDF subsystem must be declared in the RELATED-SUBSYSTEMS operand.
SYNTAX-FILE = *NO
Default value: no syntax file is to be activated. This value is mandatory for all subsystems which are defined with the start time BEFORE-DSSM-LOAD or AT-DSSM-LOAD (see also the CREATION-TIME operand), as it is not possible to activate a syntax file as early as this.
SYNTAX-FILE = *INSTALLED(...)
The name of the syntax file must be determined by calling IMON-GPN (administration of installation paths).
If one of the subsystem satellites is referenced with a logical ID, logical IDs must be specified for all satellites belonging to this subsystem. If a logical ID is assigned, a value other than *NONE must be assigned for the INSTALLATION-UNIT operand.
LOGICAL-ID = <filename 1..30 without-catid-userid-gen-vers>
Logical ID of the syntax file.
DEFAULT-NAME =
Name of the syntax file if IMON-GPN is not available or if the logical ID is unknown.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
A new name is assigned.
DEFAULT-NAME = *NONE
No new name is assigned.
SYNTAX-FILE = <filename 1..54 without-gen-vers>
Fully qualified name of the syntax file which is to be automatically activated when the subsystem is loaded.
DYNAMIC-CHECK-ENTRY =
Specifies whether a dynamic identity check is to be carried out on the subsystem. For this purpose, an entry point must be specified, at which both the subsystem name (eight characters) and also the version number (four or seven characters) must be located. DSSM checks whether the identification specified in the definition agrees with the subsystem which is loaded.
DYNAMIC-CHECK-ENTRY = *STD
By default, the entry point specified in the LINK-ENTRY operand will be applied in carrying out the identity check.
DYNAMIC-CHECK-ENTRY = *NO
No check is to be carried out. However, this value of the operand must not be used for any subsystems which are loaded before DSSM is activated (CREATION-TIME=*BEFORE-DSSM-LOAD).
DYNAMIC-CHECK-ENTRY = <text 1..8 without-sep>
Name of the entry point which is to be used in applying the identity check.
CREATION-TIME =
Specifies the point in time at which activation of the subsystem (CREATE routine) is initiated.
There are two separate phases during system initialization when DSSM takes over the control of system initialization after it has been called by the startup routine:
Phase 1: | The DSSM code is loaded, the DSSM task is generated and started. |
Phase 2: | Following a second call, all those subsystems are loaded which have been defined with the start attributes MANDATORY-AT-STARTUP, BEFORE-SYSTEM-READY and AFTER-SYSTEM-READY. |
If different versions of a subsystem are to be defined, it is only possible to specify the start attributes, for use in phases 1 and 2 of system initialization, for one of these versions.
CREATION-TIME = *AT-CREATION-REQUEST
Default value: the subsystem must be explicitly loaded by means of the START-SUBSYSTEM command.
CREATION-TIME = *AT-SUBSYSTEM-CALL(...)
The subsystem is to be automatically loaded when the first SVC or ISL call is made. This operand value is reserved for subsystems which are called via SVC or ISL.
If two or more versions of a subsystem are defined with this operand value, VERSION-COEXISTENCE=*ALLOWED must be specified for all of these versions and FUNCTION-NUMBER and FUNCTION-VERSION must be specified for their SVC or ISL entry points, which were declared with CONNECTION-ACCESS with a value other than *SIH.
At least one of the specified subsystems must have been declared with SUBSYSTEM-ENTRIES ..., MODE=*SVC/*ISL (corresponding to the value of the ON-ACTION operand).
ON-ACTION =
Determines what initiates automatic loading of the subsystem.
ON-ACTION = *STD
Default setting: loading begins when any SVC entry point belonging to the subsystem is called.
ON-ACTION = *ISL-CALL
Loading begins when any ISL entry point belonging to the subsystem is called.
ON-ACTION = *ANY
Loading begins when any SVC or ISL entry point belonging to the subsystem is called.
CREATION-TIME = *AT-DSSM-LOAD
The subsystem is to be loaded during system initialization (phase 1) under the control of the DSSM task.
The subsystem must be a privileged one, and may only have address or dependency relations to subsystems which are also defined with this start attribute or with the start attribute BEFORE-DSSM-LOAD.
The files for this subsystem must be held on the home pubset under the TSOS user ID, because at the time of startup the user catalog is not accessible and IMPORT-PUBSET processing has not been completed.
Specification of a syntax file is not permitted for these subsystems.
CREATION-TIME = *BEFORE-DSSM-LOAD
The subsystem is to be loaded during system initialization (phase 1), but not under the control of the DSSM task.
Such subsystems are linked to the control program, and do not need to be synchronized with the DSSM task when activated. However, after the subsystem is loaded it again runs under the control of DSSM and can, from the user’s point of view, be controlled in the same way as other subsystems.
No address or dependency relations are possible to subsystems which are defined with any other start attribute. Nor is it permissible to link in a message or syntax file. All job entries (SUBSYSTEM-ENTRIES operand) must be declared, because DSSM creates the (privileged) connection to these job entries. Responsibility for ensuring that at least one version of this subsystem is available at any given time (e.g. PLAM) rests entirely with the subsystem developer.
The name of the link context for these subsystems must be unique because DSSM must also honor an unload request even if DSSM has not loaded the subsystem code. An entry point (operand DYNAMIC-CHECK-ENTRY) must have been specified.
CREATION-TIME = *BEFORE-SYSTEM-READY
The subsystem is to be loaded during system initialization (phase 2). Activation is initiated synchronously; not until loading is complete (or a load error occurs) does control return to the startup routine, which can then report “SYSTEM READY”.
The subsystem must be privileged, and may only have address or dependency relations to subsystems defined with the same attribute or with the start attribute BEFORE-DSSM-LOAD, AT-DSSM-LOAD or MANDATORY-AT-STARTUP. The files for this subsystem must be cataloged on the home pubset.
If a nonprivileged subsystem is declared with this operand value, it is automatically given the value *AFTER-SYSTEM-READY. SSCM issues a message.
CREATION-TIME = *MANDATORY-AT-STARTUP
The subsystem must be loaded during system initialization (phase 2). Activation is initiated synchronously - as in the case of BEFORE-SYSTEM-READY. By contrast with the latter however, loading of the subsystem must in this case be completed successfully. Otherwise a message is passed to the startup routine reporting that a mandatory subsystem could not be loaded. In this case, the startup routine will decide whether processing should continue or be terminated.
The subsystem must be privileged, and may only have address or dependency relations to subsystems defined with the same attribute or with the start attribute BEFORE-DSSM-LOAD or AT-DSSM-LOAD. The files for this subsystem must be cataloged on the home pubset.
CREATION-TIME = *AFTER-SYSTEM-READY
The loading of this subsystem is to be initiated during system initialization (phase 2). Execution of this routine is not synchronized with the startup routine, which can report “SYSTEM READY” before subsystem loading is complete.
The subsystem may only have address or dependency relations to subsystems defined with the same attribute or with the start attribute BEFORE-DSSM-LOAD, AT-DSSM-LOAD, MANDATORY-AT-STARTUP or BEFORE-SYSTEM-READY. The files for this subsystem must be cataloged on the home pubset.
INIT-ROUTINE =
Specifies whether there is an initialization routine for the subsystem which must be performed when it is started or resumed. In this case, the name of an entry point must be known, and DSSM will delegate initialization to the holder task of the subsystem concerned. It is strongly recommended that an entry point be defined for all subsystems which have the start attribute BEFORE-DSSM-LOAD. During loading of the subsystem (i.e. when the initialization routine is carried out), the subsystem is then informed that DSSM can assume control over the opening and closing of relations.
An INIT routine must be declared with RESTART-REQUIRED=*YES.
INIT-ROUTINE = *NO
Default value: no initialization routine is run.
INIT-ROUTINE = <text 1..8 without-sep>
Name of the entry point to the initialization routine.
In the holder task, control is passed to the initialization routine, so that the subsystem can initialize itself. To permit this, it is passed:
the name and version of the subsystem, as defined in SSCMCAT
the name of the SSINFO file, if one was specified in the SUBSYSTEM-INFO-FILE operand
the address of the entry point specified during loading and linking (LINK-ENTRY operand)
the link context name used by the dynamic binder loader
the name of the memory pool (for subsystems in class 5 or class 6 memory), in order that the subsystem can refer to its own selectable units/load units during dynamic loading
the name of the message file
the address of the SUBSYSTEM-PARAMETER operand, if a string has been specified in the START-SUBSYSTEM command
At the end of initialization, a return message is expected from the subsystem, indicating whether initialization was successful and whether the holder task is to be used as a work task (as specified in the ASSIGN-HOLDER-TASK statement). Depending on what is reported here, the task will from then on be controlled by DSSM or by the subsystem.
CLOSE-CTRL-ROUTINE =
Specifies whether a special routine is to be run for the subsystem if it is suspended or deactivated.
If a subsystem is deactivated (by a STOP-SUBSYSTEM or HOLD-SUBSYSTEM command), DSSM passes control to this routine at the identified entry point in the holder task, or (for *DYNAMIC) this is reported via a bourse or FITC link (as determined by return messages during initialization).
The parameters passed are the same ones as are passed for the INIT-ROUTINE operand. Branching to this routine ensures that a connection to the subsystem still exists.
If a CLOSE-CTRL routine exists, it is possible to change versions without interrupting the BS2000 session. At any given point in time, there is exactly one valid version (either the old version is still available, or the new version has already become available). Without a CLOSE-CTRL routine, changing versions always entails interrupting the connection so that the STOPCOM routine of the old version and the INIT routine of the new version can execute (see also "Swapping subsystem versions").
CLOSE-CTRL-ROUTINE = *NO
Default value: the subsystem designates no routine which is to be run when the subsystem is deactivated or suspended.
CLOSE-CTRL-ROUTINE = *DYNAMIC
This routine is called up via the bourse or FITC. The subsystem passes the required parameters to the CLOSE-CTRL routine dynamically at the end of the INIT routine, and DSSM is informed of the identity of the bourse or FITC port.
In order for the CLOSE-CTRL routine to run, an INIT routine (INIT-ROUTINE operand) and a STOPCOM routine (operand STOPCOM-ROUTINE=*NO/*DYNAMIC) must have been specified.
The holder task of the subsystem must be a work task when the CLOSE-CTRL routine is called (ASSIGN-HOLDER-TASK statement).
CLOSE-CTRL-ROUTINE = <text 1..8 without-sep>
Name of the entry point of the relevant subsystem routine.
STOPCOM-ROUTINE =
Specifies whether the subsystem incorporates a routine which can carry out active termination of tasks.
If a subsystem is deactivated (by a STOP-SUBSYSTEM or HOLD-SUBSYSTEM), then DSSM passes control to this routine at the identified entry point in the holder task, or (for *DYNAMIC) this is reported via a bourse or FITC link (as determined by return messages during initialization).
The parameters which are passed are the same as for the INIT-ROUTINE operand. Branching to this routine ensures that calling tasks will no longer be connected to the subsystem. Tasks which still have outstanding call relations to the subsystem are unaffected by this.
If CLOSE-CTRL-ROUTINE=*DYNAMIC is declared, the operand STOPCOM-ROUTINE=*NO/*DYNAMIC must be specified.
STOPCOM-ROUTINE = *NO
Default value: the subsystem concerned incorporates no such routine.
STOPCOM-ROUTINE = *DYNAMIC
This routine is called via the bourse or FITC. The subsystem passes the required parameters to the STOPCOM routine dynamically at the end of the CLOSE-CTRL routine or (if none exists) at the end of the INIT routine. DSSM is informed of the identity of the bourse or FITC port.
A prerequisite for the use of the STOPCOM routine is than an INIT routine has been specified (INIT-ROUTINE operand). When the STOPCOM routine is called, the holder task for the subsystem must be used as a work task (ASSIGN-HOLDER-TASK statement).
STOPCOM-ROUTINE = <text 1..8 without-sep>
Name of the entry point to the subsystem routine concerned.
DEINIT-ROUTINE =
Specifies whether the subsystem incorporates a routine which can carry out deinitialization of the subsystem. This deinitialization routine causes the resources which were requested by the subsystem (memory, files, devices) to be returned.
If a subsystem is deactivated (by a STOP-SUBSYSTEM or HOLD-SUBSYSTEM command), then DSSM passes control to this routine at the identified entry point in the holder task, or (for *DYNAMIC) this is reported via a bourse or FITC link (as determined by return messages during initialization).
If a subsystem is defined with an INIT routine and a CLOSE-CTRL routine, a DEINIT routine - with the same operand value as the CLOSE-CRTL routine - must be specified.
The parameters which are passed are the same as for the INIT-ROUTINE operand. Branching to this routine ensures that calling tasks will no longer be connected to the subsystem and all existing call relations to the subsystem are deleted.
DEINIT-ROUTINE = *NO
Default value: the subsystem concerned does not incorporate a deinitialization routine to request the release of resources.
DEINIT-ROUTINE = *DYNAMIC
The routine is called via the bourse or FITC.The subsystem passes the required parameters to the DEINIT routine dynamically at the end of the STOPCOM routine or, if none exists, at the end of the CLOSE-CTRL routine or, if neither a STOPCOM nor a CLOSE-CTRL routine is incorporated, at the end of the INIT routine. DSSM is informed of the identity of the bourse or FITC port.
A prerequisite for the use of the DEINIT routine is than an INIT routine has been specified (INIT-ROUTINE operand). When the DEINIT routine is called, the holder task for the subsystem must be used as a work task (ASSIGN-HOLDER-TASK statement).
DEINIT-ROUTINE = <text 1..8 without-sep>
Name of the entry point to the subsystem routine concerned.
STOP-AT-SHUTDOWN =
Specifies whether the subsystem is to be unloaded automatically at shutdown after the user tasks have terminated.
STOP-AT-SHUTDOWN = *NO
Default value: the subsystem will not be unloaded automatically.
This parameter should not be specified for subsystems which have address relations to other subsystems which are defined with STOP-AT-SHUTDOWN=*YES.
STOP-AT-SHUTDOWN = *YES
The subsystem will be unloaded automatically at shutdown.
This specification will be ignored if no STOPCOM, DEINIT or CLOSE-CRTL routine is specified.
INTERFACE-VERSION =
Identifies the entry point via which DSSM can access the interface version which is to be used for calling the INIT, DEINIT, STOPCOM or CLOSE-CTRL routine.
This operand is mandatory for subsystems for which an entry point was specified (INIT, CLOSE-CTRL, STOPCOM, DEINIT routine).
INTERFACE-VERSION = *NO
Default value: the subsystem does not call a INIT, DEINIT, STOPCOM or CLOSE-CTRL routine.
INTERFACE-VERSION = <text 1..8 without-sep>
Name of the entry point. The entry point points to the standard header where the interface version is stored. The standard header is generated by calling the macro $ESMINT(I) with MF=I/L. This operand is mandatory for subsystems for which an INIT, DEINIT, STOPCOM or CLOSE-CTRL routine was defined.
SUBSYSTEM-HOLD =
Specifies whether the subsystem which is loaded may be suspended or unloaded.
SUBSYSTEM-HOLD = *ALLOWED
Default value: the subsystem which is loaded may be suspended and unloaded. The commands HOLD-SUBSYSTEM and STOP-SUBSYSTEM are permissible for this subsystem.
SUBSYSTEM-HOLD = *FORBIDDEN
The commands HOLD-SUBSYSTEM and STOP-SUBSYSTEM must not be used for this subsystem; it will only be unloaded at shutdown - as specified by the STOP-AT-SHUTDOWN operand.
Unloading the subsystem by replacing it with another subsystem entails no interruption.
STATE-CHANGE-CMDS =
Specifies whether or not the DSSM commands for controlling the subsystem (START-SUBSYSTEM, STOP-SUBSYSTEM, HOLD-SUBSYSTEM and RESUME-SUBSYSTEM) may be used during a session.
If a change is made from one version of a subsystem to another, the value specified for STATE-CHANGE-CMDS for the version being replaced is ignored.
STATE-CHANGE-CMDS = *ALLOWED
Default value: the commands may be used from the operator terminal and under the privileged user ID (the user ID which has the SUBSYSTEM-MANAGEMENT system privilege).
STATE-CHANGE-CMDS = *FORBIDDEN
The commands must not be used - neither from the operator terminal nor under the privileged user ID.
STATE-CHANGE-CMDS = *BY-ADMINISTRATOR-ONLY
The commands may only be used under the privileged user ID; the commands are not available to the operator at the operator terminal.
FORCED-STATE-CHANGE =
Specifies whether use of the operand FORCED=*YES is permitted within the commands STOP-SUBSYSTEM and HOLD-SUBSYSTEM. This function can be used to force the unconditional deactivation of the subsystem.
FORCED-STATE-CHANGE = *FORBIDDEN
Default value: it is not possible to force deactivation of the subsystem. DSSM will reject any use of the FORCED operand in the commands concerned, and will issue a corresponding error message.
FORCED-STATE-CHANGE = *ALLOWED
The operand FORCED=*YES may be used for this subsystem.
This operand value must not be used in conjunction with SUBSYSTEM-HOLD=*FORBIDDEN.
RESET =
Specifies whether the operand RESET=*YES is permitted within the commands START-SUBSYSTEM and RESUME-SUBSYSTEM. This function can be used to force the unconditional loading or resumption of the subsystem, even if the state of the subsystem is currently IN-DELETE or IN-HOLD.
RESET = *FORBIDDEN
Default value: it is not possible to force the activation of the subsystem. DSSM will reject the use of the RESET operand in the commands concerned, and will issue a corresponding error message.
RESET = *ALLOWED
The operand RESET=*YES may be used for this subsystem.
This operand value must not be specified together with SUBSYSTEM-HOLD=*FORBIDDEN.
RESTART-REQUIRED =
Specifies whether the initialization routine for the subsystem is to be executed if the holder task terminates abnormally.
RESTART-REQUIRED = *NO
Default value: the initialization routine is not used to restart the subsystem.
RESTART-REQUIRED = *YES
If the holder task terminates abnormally, the initialization routine should be used. Provision must have been made in the INIT-ROUTINE operand for executing this routine.
VERSION-COEXISTENCE =
Specifies whether more than one version of the same subsystem may be active simultaneously.
VERSION-COEXISTENCE = *FORBIDDEN
Default value: the current version of the subsystem cannot coexist with another version of the same subsystem.
VERSION-COEXISTENCE = *ALLOWED
The current version of the subsystem can coexist with another version of the same subsystem (coexistence mode).
In the definition of the job entry point (SUBSYSTEM-ENTRIES operand), indirect links via system exit routines must not have been specified. If different versions of the same subsystem are loaded and the same job entry point is defined for these, the link which is implemented is always to the highest loaded version of the subsystem.
If coexistent subsystems access coexistent syntax files, the latter must have been declared in the SSD object and cannot be administered by SDF.
However, where the links are via SVC and ISL, it is possible to select a version using the operands FUNCTION-NUMBER and FUNCTION-VERSION.
VERSION-EXCHANGE =
Specifies whether a subsystem may be loaded in exchange mode. Exchange mode allows the temporary coexistence of two versions of the same subsystem. If version B of a subsystem is loaded whilst version A of the subsystem is already active, all new callers will be connected to version B. Jobs which are connected to version A will still be processed. When all the jobs which use version A have been processed, this will automatically be terminated.
In the definition it should be noted that the “old” version which is being replaced must not be dependent on the “new” version which replaces it.
VERSION-EXCHANGE = *FORBIDDEN
Default value: the current version of the subsystem must not be replaced.
VERSION-EXCHANGE = *ALLOWED
Exchange mode, which allows the temporary coexistence of two subsystems, is permitted for the current subsystem version.
SUBSYSTEM-ENTRIES =
Specifies the entry points (job entries) which are linked to the subsystem. Up to 100 entry points can be declared. If more than 100 entry points are desired for a subsystem, the additional ones can be defined by means of the statement MODIFY-SUBSYSTEM-ATTRIBUTES (for a subsystem in the catalog) or the statement ADD-SUBSYSTEM-ENTRIES (for a subsystem in an SSD object).
SUBSYSTEM-ENTRIES = *NONE
Default value: no new job entries are to be declared.
SUBSYSTEM-ENTRIES = list-poss(100): <text 1..8>
Declares the names of the entry points for a maximum of 100 job entries; the type of each of these must be defined in the substructures.
MODE =
Defines the type of a job entry point which is defined for the subsystem.
MODE = *LINK
Default value: the job entry point cannot be accessed by indirect linkage, but only by using a CONNECT relation through an external linkage editor symbol.
In the case of different versions of the same subsystem which use the same external linkage editor symbol, DSSM automatically sets up the link to the highest loaded version of the subsystem.
MODE = *ISL(...)
The job entry is effected by indirect linkage via System Procedure Linkage (for privileged subsystems only). If the specification includes in addition a function and version number for the ISL entry point, the combination of entry point name, function and version numbers must not match any other combination for the various other subsystems in the catalog or the various versions of the same subsystem (if VERSION-COEXISTENCE=*ALLOWED is specified).
For different subsystems, if the job entry point is to be accessed by the same ISL entry point, they must be uniquely identified by specifying the function and version numbers.In the case of different versions of the same subsystem which use the same ISL entry point, then - if the function and version numbers are not specified - DSSM will automatically set up a connection to the highest loaded version of the subsystem.
In the case of different versions of the same subsystem which use the same ISL entry point and for which the function and version numbers are not equal to *NONE, the version to which the connection is set up will be selected in accordance with the function and version numbers stored in the standard header of the caller’s parameter list.
The value *ALL for the CONNECTION-ACCESS operand is not permissible for ISL entry points.
FUNCTION-NUMBER =
Specifies whether a particular function and version number of the ISL entry point is to be addressed, as the same ISL entry point can be used by different functions.
FUNCTION-NUMBER = *NONE
Default value: no particular function or version number is to be addressed.
FUNCTION-NUMBER = <integer 0..255>(...)
Number of the ISL entry point. The version must be nominated in the substructure which follows.
FUNCTION-VERSION = <integer 1..255>
Version of the specified ISL function number.
MODE = *SVC(...)
Job entry is to be effected by an indirect connection using a supervisor call (SVC).
If the specification includes in addition a function and version number for the SVC entry point, the combination of entry point name, function and version numbers must not match any other combination for the various other subsystems in the catalog or the various versions of the same subsystem (if VERSION-COEXISTENCE=*ALLOWED is specified).
For different subsystems, if the job entry point is to be accessed by the same SVC, they must be uniquely identified by specifying the function and version numbers.
In the case of different versions of the same subsystem which use the same SVC, then - if the function and version numbers are not specified - DSSM will automatically set up a connection to the highest loaded version of the subsystem.
In the case of different versions of the same subsystem which use the same SVC and for which the function and version numbers are not equal to *NONE, the version to which the connection is set up will be selected in accordance with the function and version numbers stored in the standard header of the caller’s parameter list.
If this operand value is specified, it is better to set the operand CONNECTION-ACCESS to the value *SYSTEM, instead of to *ALL.
NUMBER = <integer 0..255>
Number of the SVC via which job entry is to be effected. No SVC number greater than 191 may be used in conjunction with CONNECTION-ACCESS=*ALL.
CALL-BY-SYSTEM-EXIT =
Defines whether the specified SVC number may be called from within system exit routines.
CALL-BY-SYSTEM-EXIT = *ALLOWED
Default value: system exit routines are permitted to call the specified SVC number.
CALL-BY-SYSTEM-EXIT = *FORBIDDEN
System exit routines are not permitted to call the specified SVC number.
FUNCTION-NUMBER =
Specifies whether a particular function and version number of the SVC entry point is to be addressed, as the same SVC entry point can be used by different functions.
FUNCTION-NUMBER = *NONE
Default value: no particular function or version number is to be addressed.
FUNCTION-NUMBER = <integer 0..255>(...)
Number of an SVC entry point. The version must be nominated in the substructure which follows.
FUNCTION-VERSION = <integer 1..255>
Version of the specified SVC function number.
MODE = SYSTEM-EXIT(...)
Job entry is to be effected by an indirect connection using system exit routines.
This operand must not be used in conjunction with CONNECTION-ACCESS=*ALL.
NUMBER = <integer 0..127>
Number of the system exit routine.
CONNECTION-ACCESS =
Specifies the access authorization (privileges) required by the subsystem.
CONNECTION-ACCESS = *ALL
Default value: privileged and nonprivileged program runs may access the subsystem.This operand value must not be used in conjunction with MODE=*SYSTEM-EXIT/*ISL/*SVC (with an SVC number greater than 191).
CONNECTION-ACCESS = *SYSTEM
Only privileged program runs may access the subsystem.
CONNECTION-ACCESS = *SIH
Only tasks running in the SIH processor state may access the subsystem.
The subsystem called also runs in the SIH processor state, i.e. it is uninterruptible.
This operand value is permissible only for subsystems for which the entry point is defined via:
System Procedure Linkage (MODE=*ISL(FUNCTION-NUMBER=*NONE))
CONNECTION-SCOPE=*OPTIMAL
MEMORY-CLASS=*SYSTEM-GLOBAL(SUBSYSTEM-ACCESS=*SYSTEM)
CONNECTION-SCOPE =
Identifies the event which will call up the automatic cleardown of the connection to the specified subsystem job entry.
CONNECTION-SCOPE = *TASK
Default value: the connection will be cleared when the task terminates.
CONNECTION-SCOPE = *PROGRAM
The connection will be cleared when the program terminates, or before.
Only CONNECTION-SCOPE=*PROGRAM may be specified in conjunction with MEMORY-CLASS=*LOCAL-UNPRIVILEGED.
This operand value is recommended for subsystems which were declared with SUBSYSTEM-ACCESS=*LOW/*HIGH or MEMORY-CLASS=*BY-SLICE.
CONNECTION-SCOPE = *FREE
DSSM is not to carry out any checking of the connections to the job entry point. The connection will not be automatically cleared - unless explicitly requested. To avoid problems or possible errors when the subsystem is being unloaded, the connections must be managed by the subsystem itself.
CONNECTION-SCOPE = *CALL
On return from this job entry point, DSSM will automatically clear the connections.
This operand value is only available with subsystems for which the job entry is defined by means of System Procedure Linkage (ISL) or supervisor calls (SVC).
CONNECTION-SCOPE = *OPTIMAL
The subsystem is deactivated or suspended when there are no further tasks with a connection to this entry point.
A routine with an entry point defined with *OPTIMAL must be terminated with RETURN.If an entry point of a subsystem is defined with CONNECTION-SCOPE=*OPTIMAL, all of its entry points should be defined in the subsystem catalog with MODE!=*LINK. While a subsystem is deactivated or suspended, no call of the subsystem with CONNECTION-SCOPE=*OPTIMAL is accepted.
FIRST-CONNECTION =
Determines whether or not first connection of the task to the specified job entry point in the subsystem is allowed. At least one job entry point of a subsystem must be defined with FIRST-CONNECTION=*ALLOWED.
FIRST-CONNECTION = *ALLOWED
Default value: first connection to the specified job entry point is allowed.
FIRST-CONNECTION = *FORBIDDEN
Connection to the specified job entry point via SVC or ISL is not allowed if the task has not yet been connected to another job entry point belonging to the subsystem.
It is not permitted to specify this operand value for job entry points that have been defined with MODE=*LINK/*SYSTEM-EXIT or CONNECTION-ACCESS=*SIH.
SUBSYSTEM-ENTRIES = *BY-PROGRAM(...)
The entry points of the specified subsystem are supplied dynamically from the BLS name list at load time instead of statically from the catalog. A prerequisite for this functionality is the use of BLSSERV as of version 2.1, that supports using Extended External Names (EEN names) as entry points for DSSM subsystems.
The value cannot be specified together with the SUBSYSTEM-ACCESS=*SYSTEM operand.
The MODE, CONNECTION-ACCESS and FIRST-CONNECTION operands are supplied with the default values if the entry points are defined with this value.
CONNECTION-SCOPE = *TASK / *PROGRAM
The connection is shut down at task or program termination.
MEMORY-CLASS =
Specifies the subsystem-specific address space in which the subsystem is to be loaded. System administration can use this operand to define the address space valid for the subsystem concerned so as to meet the special requirements of the installation.
MEMORY-CLASS = *SYSTEM-GLOBAL(...)
Default value: the subsystem will be loaded in class 3 or class 4 memory. Resident CSECTs will be given class 3 memory, all others will be given pageable class 4 memory.
SUBSYSTEM-ACCESS =
Identifies the access authorization (privileges) and location of the requested memory.
SUBSYSTEM-ACCESS = *LOW
Default value: nonprivileged address space below the 16-Mbyte boundary is allocated.
SUBSYSTEM-ACCESS = *SYSTEM
Subsystems declared with this operand value are privileged subsystems to which privileged address space above the 16-Mbyte boundary is allocated.
This operand value is mandatory for subsystems whose entry point is declared via SVC (MODE=*SVC) or for which an INIT, STOPCOM, DEINIT or CLOSE-CTRL routine is declared. It is not permitted with CONNECTION-ACCESS=*ALL and MODE=*LINK. The value cannot be specified together with an entry point that was specified together with CONNECTION-ACCESS=*ALL or MODE=*LINK.
The value cannot be specified together with the SUBSYSTEM-ENTRIES=*BY-PROGRAM operand.
SUBSYSTEM-ACCESS = *HIGH
Nonprivileged address space up to 2 Gbytes is allocated.
MEMORY-CLASS = *LOCAL-PRIVILEGED(...)
The subsystem is given a memory pool in nonprivileged class 5 memory, located below the 16-Mbyte boundary.
This specification is suitable for nonprivileged subsystems which demand a relatively large amount of address space (approx. 1 Mbyte) and have to be set up below the 16-Mbyte boundary. These subsystems are loaded in memory pools at the same address, in order to manage the use of the limited address space below 16 Mbytes.
Although such subsystems are loaded in parallel in the same address space, they cannot be used simultaneously by the same task (see also the SEPARATE-ADDRESS-SPACE statement).
The subsystem must not contain any resident CSECTs, as otherwise a later attempt to activate it will be aborted.
SIZE = <integer 1..32767>
Size of the required address space (in 4Kbyte pages) for the memory pool in class 5 memory. This value should be set at least high enough to ensure that the subsystem and any selectable units/load units which it may load dynamically can be loaded in their entirety. The upper limit is generation-specific.
MEMORY-CLASS = *LOCAL-UNPRIVILEGED(...)
The subsystem is given a memory pool in nonprivileged class 6 memory. This specification is reserved for subsystems which can be executed like a program.
In keeping with this, their access authorization (privileges) must be defined with the value *ALL in the CONNECTION-ACCESS operand.
This operand value must not be specified together with an entry point which was defined with CONNECTION-ACCESS=*SYSTEM.
The subsystem must not contain any resident CSECTs, as otherwise a later attempt to activate it will be aborted.
If this operand value is specified, only CONNECTION-SCOPE=*PROGRAM is permissible for clearing the connection to the specified subsystem entry point.
SIZE = <integer 1..32767>
Size of the required address space (in 4Kbyte pages) for the memory pool in class 6 memory. This value should be set at least high enough to ensure that the subsystem and any selectable units/load units which it may load dynamically can be loaded in their entirety. The upper limit is generation-specific.
SUBSYSTEM-ACCESS =
Identifies the location of the requested memory space.
SUBSYSTEM-ACCESS = *LOW
Default value: nonprivileged address space below the 16-Mbyte boundary is allocated.Because this specification is suitable for subsystems which can be executed like programs, it is advisable additionally to specify CONNECTION-SCOPE=*PROGRAM.
SUBSYSTEM-ACCESS = *HIGH
Nonprivileged address space up to 2 Gbytes is allocated.
Because this specification is suitable for subsystems which can be executed like programs, it is advisable additionally to specify CONNECTION-SCOPE=*PROGRAM.
START-ADDRESS =
Defines the start address in class 6 memory.
START-ADDRESS = *ANY
Default value: the location of the subsystem in class 6 memory will be determined by DSSM.
START-ADDRESS = <x-string 7..8>
Start address in the segment raster at which the subsystem’s start address is to be located. The value specified must be an 8-character hexadecimal constant which is a multiple of X'100000'.
MEMORY-CLASS = *BY-SLICE(...)
The specified subsystem is a nonprivileged subsystem and consists of an LLM, which in turn consists of a shareable code (program area) and a non-shareable code (data area). The program area is loaded into the shareable address space (this corresponds to MEMORY-CLASS=*SYSTEM-GLOBAL). The data area is loaded into the user address space of the holder task and is copied into the private user address spaces of the connected tasks at the same address.
The following values must be specified together with MEMORY-CLASS=*BY-SLICE: SUBSYSTEM-LOAD-MODE=*ADVANCED and CONNECTION-ACCESS=*ALL.
The value can only be specified together with the MODE=*LINK and CONNECTION-SCOPE=*TASK or *PROGRAM operands.
SIZE = <integer 1.32767>
Specifies the size of the requested memory space for the data area in 4K pages. The value chosen here must be sufficiently large to allow the subsystem and, if appropriate, selectable units/load units dynamically loaded by the subsystem to be loaded in full. The upper limit is dependent on generation.
LINK-ENTRY = <text 1..8 without-sep>(...)
Defines the name of the object module/ENTRY/CSECT required for loading (for the operand in the call of the $PBBND1 macro to the dynamic binder loader DBL). The subsystem must be completely loaded by this ENTRY (if necessary, using autolink).
AUTOLINK =
Controls invocation of the autolink function during linking and loading.
The linkage editor’s autolink function permits the automatic insertion of modules which are not explicitly inserted by appropriate statements. The main purpose of this function is to save users of higher-level programming languages from having to make explicit statements to insert individually the numerous modules of the runtime system which are required. Further details of the autolink function will be found in the “BLSSERV” manual [4].
The autolink function can also be implicitly circumvented if the first external reference encountered during linkage editing of the object module which is to be loaded points to a prelinked module. The advantage of this approach is that the paging behavior when the subsystem is later executed can be optimized at this preliminary stage (during linkage editing). In addition, errors during linkage editing can be avoided in this way.
AUTOLINK = *FORBIDDEN /*ALLOWED
Default value: the autolink function will be suppressed or allowed.
REFERENCED-SUBSYSTEM =
Specifies whether there is a list of subsystems to which there are address relations, and which is to be used for resolving external references
REFERENCED-SUBSYSTEM = *NONE
Default value: the subsystem which is being defined has no external references.
REFERENCED-SUBSYSTEM = list-poss(15): <structured-name 1..8>
The system which is being defined has external references to a maximum of 15 other subsystems; these subsystems must be used in resolving the external references. If any of the subsystems nominated here is missing at the time of activation or deactivation (and if a check of the external references has also been requested by the operand CHECK-REFERENCE=*YES), the action will be aborted.
It is also possible to address the BS2000 control program via these external references - using the name CP. In the substructure which follows, it is possible to specify either exactly one version, or a range of versions within which all versions are to be referred to.
If a version range list is used to limit the version of the CP subsystem, DSSM checks the compatibility of the current CP version against the versions in the range list. The subsystem will only be loaded if it is a compatible version.
The following restrictions should be noted when specifying subsystems to which there are address relations:
No address relations may be declared to subsystems which have the attribute MEMORY-CLASS=*LOCAL-PRIVILEGED/*LOCAL-UNPRIVILEGED/*BY-SLICE.
Subsystems which have the attribute STOP-AT-SHUTDOWN=*NO may have address relations only to other subsystems which also have this attribute.
If the attribute SUBSYSTEM-ACCESS=*SYSTEM is specified for the subsystem being defined, subsystems defined with SUBSYSTEM-ACCESS=*LOW or SUBSYSTEM-ACCESS=*HIGH must not be addressed.
As a rule, a nonprivileged subsystem must not have any address relations to the control program (CP).
If a reference is made to a subsystem which has at least one version that may be operated in coexistence or exchange mode, a unique version must be specified.
Any address relations must be defined in accordance with the start attributes (CREATION-TIME operand); i.e. a subsystem may only have relations to other subsystems if these are started at the same time or earlier.
UNRESOLVED-EXTERNALS =
Defines how the load procedure is to behave if there are unresolved external references.
UNRESOLVED-EXTERNALS = *FORBIDDEN
Default value: if unresolved external references occur, the load procedure will be terminated.
UNRESOLVED-EXTERNALS = *ALLOWED
The load procedure will be continued, unresolved external references will be given the value X'FFFFFFFF'.
CHECK-REFERENCE =
Defines whether or not the subsystems specified in the REFERENCED-SUBSYSTEM operand are to be checked in respect of their status and availability.
CHECK-REFERENCE = *YES
Default value: the referenced subsystems will be checked. If any of them is missing, DSSM will abandon the activation or unloading of the subsystem.
CHECK-REFERENCE = *NO
DSSM is not to carry out any check. However, even if the user generates complex subsystems with this statement, DSSM will still perform the requested functions in spite of the risk of conflicts:
the START-SUBSYSTEM command will load the specified subsystem, even if there is a subsystem to which it has defined relations and which is not yet fully loaded;
the commands RESUME-SUBSYSTEM, STOP-SUBSYSTEM and HOLD-SUBSYSTEM will be executed by DSSM without any checks being made on relations and dependencies.
RELATED-SUBSYSTEM =
Defines whether or not there is a list of subsystems for which there are dependency relations.
RELATED-SUBSYSTEM = *NONE
Default value: there are no dependency relations for the subsystem which is being defined.
RELATED-SUBSYSTEM = list-poss(100): <structured-name 1..8>
The subsystem which is being defined has dependency relations to up to 100 other subsystems, without which the subsystem currently being defined cannot function.
It is also permissible to define dependency relations to the BS2000 control program (CP). The rules and restrictions which apply when doing so are analogous to those for address relations, where they are described in more detail (REFERENCED-SUBSYSTEM operand).
A dependency relation always points to a single version of a subsystem. In the substructure which follows, it is possible to specify either exactly one version, or a range of versions within which all versions are to be referred to.
The following general restrictions should be noted when specifying dependent subsystems:
- The relation which is defined must not contain closed loops. A loop arises if subsystem A is dependent on B, B is dependent on C and this is in turn dependent on A.
If the subsystem which is being defined has been given the attribute MEMORY-CLASS=*SYSTEM-GLOBAL, it is not permissible to address any subsystems defined with MEMORY-CLASS=*LOCAL-PRIVILEGED or *LOCAL-UNPRIVILEGED.
For subsystems which have the attribute SUBSYSTEM-ACCESS=*SYSTEM, no dependency relations may be defined to subsystems to which SUBSYSTEM-ACCESS=*LOW or SUBSYSTEM-ACCESS=*HIGH or MEMORY-CLASS=*BY-SLICE applies.
- The dependency relations must be defined to correspond to the start attributes (CREATION-TIME operand); i.e. a subsystem may only be dependent on subsystems which are started at the same time or earlier.
LOWEST-VERSION =
Specifies the lowest value (lowest version) in the subsystem version range list.
LOWEST-VERSION = *LOWEST-EXISTING
The lowest version in the catalog is to be addressed.
LOWEST-VERSION = <c-string 3..8> / <text 3..8>
Version of the subsystem which is to be used as the lower limit of the range of versions.
HIGHEST-VERSION =
Specifies the upper value (highest version) in the subsystem version range list.
HIGHEST-VERSION = *HIGHEST-EXISTING
The highest version in the catalog is to be addressed.
HIGHEST-VERSION = <c-string 3..8> / <text 3..8>
Version of the subsystem which is to be used as the upper limit of the range of versions.