Activate subsystem
Component: | DSSM |
Functional area: | Subsystem management |
Domain: | SYSTEM-MANAGEMENT |
Privileges: | OPERATING |
Routing code: | R |
Function
This command enables systems support staff to activate any required subsystem.
The following information from the dynamic subsystem catalog is used for activating the subsystem:
information on subsystem loading and linking;
information on the initialization/deinitialization and termination of job relations;
information on call points, ancillary components and operational dependencies (see the appropriate SSCM statements in the “Subsystem Management” manual [49]).
The command is rejected if
the subsystem is not found in the dynamic subsystem catalog
another version of the subsystem already exists and the coexistence is not allowed (see the VERSION-PARALLELISM operand)
subsystems on which the subsystem to be activated depends are not loaded
a required file (e.g. message file, library) cannot be found.
A corresponding message informs the systems support staff as to the acceptance or rejection of the command. By means of the RESET=*YES operand, initialization can be forced for those subsystems that are in the process of being deactivated. Any number of START-SUBSYSTEM commands can be issued under a privileged user ID of system’s support, in various tasks unless this is prohibited by the parameters specified during definition of the subsystem.
Depending on how the subsystem is defined (SSCM statement SET-/MODIFY-SUBSYSTEM-ATTRIBUTES, SUBSYSTEM-LOAD-MODE operand), it can be activated in various different ways:
SUBSYSTEM-LOAD-MODE = *STD
The BLS is called in STD run mode and loads the subsystem as an object module.SUBSYSTEM-LOAD-MODE = *ADVANCED
The BLS is called in ADVANCED run mode and loads the subsystem as a link and load module (LLM).SUBSYSTEM-LOAD-MODE = *ANY
The BLS is called in STD run mode and loads the subsystem as an object module. If an error occurs while the subsystem is being loaded, the BLS is called again, this time in ADVANCED run mode, and the subsystem is loaded as a link and load module (LLM). If the first call to the BLS fails, a BLS error message is output on the console.
Format
START-SUBSYSTEM | ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Operands
SUBSYSTEM-NAME = <structured-name 1..8>
Name of the subsystem to be activated.
VERSION = *STD / <product-version mandatory-man-corr> / <product-version without-man-corr> / *HIGHEST
Specifies the version.
If a version is specified, the format specified here must be identical to the format used when the subsystem was defined (release and correction status mandatory or not allowed; see also "SDF syntax representation").
VERSION = *STD
If several versions exist for the specified subsystem, and neither a version nor *STD is explicitly specified, the subsystem that was declared with the start attribute CREATION-TIME=*AT-SUBSYSTEM-CALL (see the SSCM statement SET-SUBSYSTEM-ATTRIBUTES in the “Subsystem Management” manual [49]) is loaded. If this condition is not met, the lowest version for this subsystem that is stored in the static subsystem catalog is selected.
Exception
If a version of a subsystem is to be activated automatically with the first SVC call, then this version is taken as the standard version.
VERSION = *HIGHEST
Selects the highest version of the subsystem entered in the static subsystem catalog.
SUBSYSTEM-PARAMETER = *NONE / <c-string 1..254>
Specifies whether special parameters which can be interpreted only by the specified subsystem may be processed.
RESET =
Determines the behavior and urgency of command processing.
RESET = *NO
If the subsystem concerned is in the process of being deactivated, the command is rejected until this blocking operation has terminated.
RESET = *YES
The command is accepted regardless of an ongoing deactivation operation and the subsystem or components of it are initialized (see also Notes).
The version parameter is mandatory for this operand.
SYNCHRONOUS =
Permits a choice between synchronous and asynchronous processing.
SYNCHRONOUS = *NO
The command is to be processed asynchronously, i.e. there is no need to wait for it to execute. Once the syntax of the command has been checked, the calling task is sent message ESM0216. No error messages relating to the execution of the command are output.
SYNCHRONOUS = *YES
The system waits for execution of the command.
Accompanying error messages are output.
In the event of a version change, this specification applies only to the new version. Deactivation of the other, “old” version always runs asynchronously.
VERSION-PARALLELISM =
Specifies whether different versions of the same subsystem can be active at the same time.
VERSION-PARALLELISM = *NONE
The coexistence of different versions of subsystems - irrespective of what is specified in the definition - is not to be allowed. If the status of any version is not NOT-CREATED, the activation will be rejected.
VERSION-PARALLELISM = *EXCHANGE-MODE(...)
Two versions of a subsystem may coexist temporarily. Activation is permitted if neither or only one of the subsystem versions is in the “CREATED” state. If two versions are already in this state, implicit deactivation is initiated for the last version started.
If a subsystem version is in the LOCKED state, DSSM handles it as NOT-CREATED.
The command with this operand is rejected if
the version to be replaced is defined with HOLD=*NO but without a CLOSE-CTRL routine
the command MODIFY-SUBSYSTEM-PARAMETER CHANGE-STATE=*NO was used for the version to be replaced
RESET=*NO is specified at the same time
- the version is not in the CREATED, NOT CREATED or LOCKED state.
SUBSYSTEM-PARAMETER = *NONE / <c-string 1..254>
Specifies whether special parameters that can only be evaluated by the specified subsystem version are processed.
VERSION-PARALLELISM = *COEXISTENCE-MODE
Permits unrestricted coexistence of two or more versions of the same subsystem, provided that this was permitted for all versions involved in the SSCM statement SET-SUBSYSTEM-ATTRIBUTES.
MONJV = *NONE / <filename 1..54 without-gen-vers>
Specifies the name of a monitoring job variable. The monitor job variable indicates whether the subsystem is active, halted, interrupted or locked. The specified job variable only becomes the monitoring job variable if the subsystem is not yet started. The monitor job variable can have the following contents:
Byte | Length | Contents | Values |
|---|---|---|---|
1 | 3 | Status | $R (running) / |
4 | 1 | Reserved | 0 |
5 | 4 | TSN | ???? (four question marks) |
9 | 4 | Home Catid | |
13 | 4 | Reserved | |
17 | 1 | Type | J / P / S |
18 | 53 | Reserved | |
71 | 3 | Session number | |
74 | 8 | Name of the subsystem | |
82 | 7 | Version of the subsystem | |
89 | 15 | Condition of the subsystem | for $R: created |
104 | 24 | Unused | |
128 | 127 | Reserved for subsystem users |
Return codes
(SC2) | SC1 | Maincode | Meaning |
|---|---|---|---|
0 | CMD0001 | No error | |
1 | 0 | CMD0001 | No action necessary; subsystem already active |
1 | ESM0414 | Syntax error: invalid version specified | |
32 | ESM0224 | Command not processed | |
32 | ESM0228 | Command terminated abnormally |
Notes
Subsystems generally have manifold relations (dependency relations, loading relations) to other subsystems.
In order to ensure the performance of the individual subsystem, these relations must be taken into account. DSSM attempts to avoid potential conflicts that might arise from the user’s requests and therefore rejects corresponding commands. Actions such as the installation of missing subsystems or unloading dependent subsystems are not performed.If, however, the user also generates complex subsystems using the CHECK-REFERENCE=*NO statement (see the SSCM statement SET-SUBSYSTEM-ATTRIBUTES), DSSM executes the requested functions despite possible conflicts: The START-SUBSYSTEM command loads the specified subsystem, even if a subsystem with which there are defined relations has not yet been completely loaded.
In order to ensure a high degree of parallelism and data integrity, time-consuming administrative jobs are not executed under the control of the calling task but are transferred to a DSSM task.
As a rule only the check of the requested function is performed synchronously (i.e. in conjunction with a wait state for the calling task). However, DSSM performs the actual processing asynchronously and independently of the calling task.After the STOP-SUBSYSTEM command, START-SUBSYSTEM is rejected if DSSM has not yet been able to complete the “load subsystem” action. However, if the RESET=*YES operand is specified, the systems support staff can force an unconditional loading of the subsystem. There is no wait for the completed processing of a STOP-SUBSYSTEM command.
In this case, the initialization routine is activated. The subsystem in question, which is notified of the RESET, can specify the scope of this routine itself (complete initialization, partial initialization, no initialization).
ExceptionIf the subsystem in question is in the “IN-DELETE” status but has already been deinitialized, processing of “unload subsystem” is not aborted despite RESET=YES. The START-SUBSYSTEM command is rejected if the subsystem has reached the status “NOT-CREATED” and all resources have been released.
If two versions of a subsystem are to be exchanged, the following points must be observed with regard to the use of the RESET=*YES parameter:
If version A is in the IN-DELETE state and version B in the CREATED state, RESET=*YES can be specified for A only if coexistence was permitted for both versions at the definition (SSCM).
If both versions are in the IN-DELETE state, RESET=*YES can be specified for one of them if the version involved was defined with RESET=*ALLOWED, VERSION-EXCHANGE=*ALLOWED.
Restart (i.e. calling the INIT routine for subsystems defined with RESTART-REQUIRED=*YES) is not possible, since this may lead to illegal coexistence.