Modify subsystem attributes
Function
This statement can be used to change any of the attributes and entry points which were defined in the SET-SUBSYSTEM-ATTRIBUTES statement.
When a definition is modified, the following points must be noted:
the subsystem - identified by its name and version - must be present in the catalog which is currently open
any attempt to add a job entry or relation which already exists will be rejected
it is impermissible to attempt to modify or delete a job entry or relation which has not yet been defined
the mode of a job entry may only be changed if all the parameters are specified; the default values *UNCHANGED will be rejected
the memory class for a subsystem may only be changed if all the parameters are specified; the default values *UNCHANGED will be rejected
MODIFY-SUBSYSTEM-ATTRIBUTES is rejected if none of the following statements have been executed beforehand:
START-CATALOG-CREATION
START-CATALOG-MODIFICATION
Note on syntax
A special data type <symbol>, which is fully described 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
ADD-SUBS-ENTRIES
CLOSE-CTRL-ROUTINE
MODIFY-SUBS-ENTRIES
STOPCOM-ROUTINE
REMOVE-SUBS-ENTRIES
Format
MODIFY-SUBSYSTEM-ATTRIBUTES | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Operands
In each case, the default value *UNCHANGED means that the value set in the SET-SUBSYSTEM-ATTRIBUTES statement is to remain valid.
If the type of job entry point declared (MODE operand) or the subsystem-specific address space (MEMORY operand) is changed, all the suboperands of MODE or MEMORY must be assigned a value explicitly, i.e. the operand value *UNCHANGED (default value) will be rejected.
SUBSYSTEM-NAME = <structured-name 1..8>(...)
Specifies the name and version of the subsystem whose attributes are to be changed.
VERSION = <c-string> / <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 operands SUBSYSTEM-LIBRARY, REP-FILE, SUBSYSTEM-INFO-FILE, MESSAGE-FILE and SYNTAX-FILE.
The syntax rules described in the “IMON“ manual [18] must be observed when defining the name.
INSTALLATION-UNIT = *NONE
No name is assigned. This entry is not allowed for any subsystems installed with IMON.
INSTALLATION-UNIT = *STD
The name specified with the SUBSYSTEM-NAME operand is used as the new name of the installed software unit.
INSTALLATION-UNIT = <text 1..30>
New name of the installed software unit.
INSTALLATION-USERID =
Specifies 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 they have not yet been assigned to a user ID, in other words if the file name was specified without a user ID.
INSTALLATION-USERID = *NONE
The files will not be expected under a specific user ID.
INSTALLATION-USERID = *DEFAULT-USERID
The files will be expected under the default user ID (prefix “$.”) or, if the subsystem is a local subsystem, under the user ID of the calling task.
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 the 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
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 copyright notice as the creation date. This is not subjected to a semantic check.
LIBRARY =
Specifies a new name for 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
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” specified 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 be used only in conjunction with the operand CREATION-TIME=*BEFORE-DSSM-LOAD.
LIBRARY = *INSTALLED(...)
The library name 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 program library or object module library.
DEFAULT-NAME = <filename 1..54 without-gen-vers>
Library name if IMON-GPN is not available or if the logical ID 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 = *STD
The BLS (Binder-Loader-Starter system) 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 (CP). 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
By default, system REPs are loaded from the file SYSREP.<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” 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
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 cannot 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, the 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-SUBSYSTEM operand.
MESSAGE-FILE = *NO
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 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 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
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-/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 REFERENCED-SUBSYSTEM operand.
SYNTAX-FILE = *NO
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
The entry point specified in the LINK-ENTRY operand is to 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. This task reserves class 5 memory, reads in the subsystem catalog, and starts After these subsystems have been loaded, control of system initialization returns to the startup routine. |
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
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 or *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.
It is not permissible to link in a syntax file 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 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 the subsystem code has not been loaded. An entry point (DYNAMIC-CHECK-ENTRY operand) 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 assigned 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 have been declared, 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.
INIT-ROUTINE = *NO
No initialization routine is to be performed.
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 the version of the subsystem, as defined in SSMCAT
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 (DBL)
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 has been 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 the subsystem incorporates a routine for controlling its suspension/deactivation.
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
The subsystem incorporates no routine that controls the deactivation or suspension of the subsystem.
CLOSE-CTRL-ROUTINE = *DYNAMIC
This routine is called up via the bourse or FITC port. 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.
STOPCOM-ROUTINE = *NO
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
The subsystem concerned does not incorporate a deinitialization routine to request the release of resources; this is done by DSSM itself.
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
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. In this case, SSCM issues a message.
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.
INTERFACE-VERSION = *NO
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 has been specified.
SUBSYSTEM-HOLD =
Specifies whether the subsystem which is loaded may be suspended or unloaded.
SUBSYSTEM-HOLD = *ALLOWED
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 changeover 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
The commands may be used from the operator terminal and under the privileged user ID (the user ID which has the SUBSYSTEM-MANAGEMENT system privileges).
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.
If a subsystem is deactivated (with a STOP-SUBSYSTEM or HOLD-SUBSYSTEM command), DSSM passes control to this routine at the specified entry point in the holder task, or (if *DYNAMIC was specified) 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 calling tasks will no longer be connected to the subsystem. Tasks which are still in a call relation to the subsystem remain unaffected by this.
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
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
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
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 at a time.
VERSION-COEXISTENCE = *FORBIDDEN
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
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.
ADD-SUBS-ENTRIES / MODIFY-SUBS-ENTRIES =
Indicates whether new job entries are to be defined (ADD), or the attributes of existing job entries are to be changed (MODIFY).
ADD-SUBS-ENTRIES / MODIFY-SUBS-ENTRIES = *NONE
Default value: new job entries are not to be added, nor are the attributes of existing job entries to be modified.
ADD-SUBS-ENTRIES / MODIFY-SUBS-ENTRIES = list-poss(100): <text 1..8>
Either declares names of entry points for a maximum of 100 new job entries for the subsystem (for each of which the type must be defined in the substructures (ADD), or modifies job entry points which have already been defined (MODIFY).
MODE =
Defines the type of a job entry point which is defined for the subsystem.
If the type of the entry point declared is modified, all the suboperands of MODE must be assigned a value explicitly; i.e. the operand value *UNCHANGED (default value for MODIFY-SUBS-ENTRIES) will be rejected.
MODE = *LINK
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.
It is not permissible to enter a value of *ALL for the CONNECTION-ACCESS operand in reference to 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 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.
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
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
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
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
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 point 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 must be defined in the subsystem catalog with MODE!=*LINK.
While a subsystem is being 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
First connection to the specified job entry point is allowed.
This value is the default setting for the ADD-SUBS-ENTRIES statement.
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.
MODIFY-SUBS-ENTRIES = *NONE / list-poss(100): <text 1..8> / *BY-PROGRAM(...)
The values *NONE and list-poss(100): <text 1..8> are described at the ADD-SUBS-ENTRIES operand.
MODIFY-SUBS-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 EEN names as entry points for DSSM subsystems.
The statement is rejected if the subsystem was not previously also defined with *BY-PROGRAM with the SET-SUBSYSTEM-ATTRIBUTES statement. MODIFY-SUBS-ENTRIES is used for changing the connection settings.
If *BY-PROGRAM is used, the ADD-SUBS-ENTRIES and REMOVE-SUBS-ENTRIES operands must be specified with *NONE.
CONNECTION-SCOPE = *TASK / *PROGRAM
The connection is shut down at task or program termination.
REMOVE-SUBS-ENTRIES =
Defines whether or not existing job entries which have been defined for the subsystem are to be deleted.
REMOVE-SUBS-ENTRIES = *NONE
Default value: none of the job entries is to be deleted.
REMOVE-SUBS-ENTRIES = list-poss(100): <text 1..8>
Names of the job entries (up to 100) which are no longer to apply to the subsystem.
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.
If the subsystem-specific address space is modified, each of the suboperands of MEMORY must be assigned a value explicitly (the operand value *UNCHANGED (default value) will be rejected).
MEMORY-CLASS = *SYSTEM-GLOBAL(...)
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 the location of the requested memory.
SUBSYSTEM-ACCESS = *LOW
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 in combination with CONNECTION-ACCESS=*ALL and MODE=*LINK.
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
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
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.
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 loaded in its entirety 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 can 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 = *ALLOWED
The autolink function is allowed.
AUTOLINK = *FORBIDDEN
The autolink function is suppressed.
ADD-REFER-SUBS / MODIFY-REFER-SUBS =
Specifies whether to set up a list containing subsystems to which there are address relations, for use in resolving external references (ADD), or if there already exists a list which is to be modified (MODIFY).
ADD-REFER-SUBS / MODIFY-REFER-SUBS = *NONE
Default value: no list is to be set up, nor is an existing list to be modified.
ADD-REFER-SUBS / MODIFY-REFER-SUBS = list-poss(15):<structured-name 1..8>
There are external references to be specified (ADD) or modified (MODIFY).
External references can be nominated for 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.
- If the attribute SUBSYSTEM-ACCESS=*SYSTEM is specified for the subsystem which is being defined, no subsystem may be addressed if it is defined with SUBSYSTEM-ACCESS=*LOW or SUBSYSTEM-ACCESS=*HIGH.
- Subsystems which have the attribute STOP-AT-SHUTDOWN=*YES may have address relations only to other subsystems which also have this attribute.
- 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 have relations to other subsystems only if these were 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.
MODIFY-REFER-SUBS =
See the description of ADD-REFER-SUBS.
REMOVE-REFER-SUBS =
Indicates whether or not existing external references to other subsystems are to be deleted.
REMOVE-REFER-SUBS = *NONE
Default value: none of the existing external references to other subsystems is to be deleted.
REMOVE-REFER-SUBS = list-poss(15): <structured-name 1..8>
Names of a maximum of 15 external references which are to be made invalid.
UNRESOLVED-EXTERNALS =
Defines how the load procedure is to behave if there are unresolved external references.
UNRESOLVED-EXTERNALS = *FORBIDDEN
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
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.
Even if the user generates complex subsystems with this statement, DSSM will still execute the requested functions despite the risk of conflicts:
The START-SUBSYSTEM command loads the specified subsystem even if a subsystem to which defined relations exist has not yet been fully loaded.
DSSM executes the RESUME-SUBSYSTEM, STOP-SUBSYSTEM and HOLD-SUBSYSTEM commands without performing any check on relations or dependencies.
ADD-RELATED-SUBS / MODIFY-RELATED-SUBS =
Specifies whether a list of subsystems for which dependency relations exist are to be created (ADD) or an existing list of dependent subsystems is to be modified (MODIFY).
ADD-RELATED-SUBS / MODIFY-RELATED-SUBS = *NONE
Default value: no dependency relations are to be defined or modified for the subsystem.
ADD-RELATED-SUBS / MODIFY-RELATED-SUBS = list-poss(100):<structured-name 1..8>
Dependency relations are to be defined (ADD) or modified (MODIFY) for 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 (see the ADD-REFER-SUBS 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, then 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.
MODIFY-RELATED-SUBS =
See the description of ADD-RELATED-SUBS.
REMOVE-RELATED-SUBS =
Specifies whether existing dependency relations to other subsystems are to be deleted.
REMOVE-RELATED-SUBS = *NONE
Default value: none of the existing dependency relations to other subsystems is to be deleted.
REMOVE-RELATED-SUBS = list-poss(100): <structured-name 1..8>
Names of a maximum of 100 subsystems to which all dependency relations are to be removed.