Change subsystem state from LOCKED to NOT-CREATED
Component: | DSSM |
Functional area: | Subsystem management |
Domain: | SYSTEM-MANAGEMENT |
Privileges: | SUBSYSTEM-MANAGEMENT |
Function
This command enables systems support to switch a locked subsystem (a subsystem in the LOCKED state) back to a state which has been declared but not activated (NOT-CREATED state). This unlocks the subsystem for the current session. Up to DSSM V3.5, once a subsystem had been locked it remained unavailable until shutdown. Thus, UNLOCK-SUBSYSTEM supports interrupt-free BS2000 operation.
A subsystem can be switched to the locked state by its INIT, DEINIT, STOPCOM or CLOSE-CTRL routines. These routines either directly request DSSM to lock the subsystem or they generate a memory dump and initiate a holder task restart which can then not be performed correctly (RESTART-REQUIRED=*NO or - with *YES - maximum permitted number of attempts exceeded).
If subsystem locking occurs during the activation phase (INIT routine), it will not subsequently be possible to run UNLOCK-SUBSYSTEM and the subsystem will remain unavailable until shutdown and the ensuing restart.
Note that not all subsystems can easily be unlocked and that a subsystem restart is not achievable in all cases. For information see the "Notes".
Format
UNLOCK-SUBSYSTEM |
SUBSYSTEM-NAME = <structured-name 1..8> ,VERSION = <product-version mandatory-man-corr> / <product-version without-man-corr> |
Operands
SUBSYSTEM-NAME = <structured-name 1..8>
Subsystem name.
VERSION = <product-version mandatory-man-corr> / <product-version without-man-corr>
Version of the above-named subsystem. 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).
Return codes
(SC2) | SC1 | Maincode | Meaning |
|---|---|---|---|
0 | CMD0001 | No errors | |
1 | ESM0414 | Syntax error: invalid version specified | |
32 | ESM0228 | Command abnormally terminated | |
64 | ESM0224 | Command not processed |
Notes
The subsystem being unlocked must be in the LOCKED state.
There are restrictions on the use of the UNLOCK-SUBSYSTEM command:
Some subsystems cannot be regularly terminated and restarted during a session. Execution of the STOP- and HOLD-SUBSYSTEM commands must be allowed for the subsystem which is being unlocked, which means that the subsystem must not have been defined with the attribute SUBSYSTEM-HOLD=*FORBIDDEN (see also the restrictions on the STOP-SUBSYSTEM command).
Owing to interdependencies with other subsystems, the UNLOCK-SUBSYSTEM command may result in inconsistencies in the subsystem catalog.
To prevent this from happening, all subsystems associated with the subsystem which is being unlocked must be deactivated (STOP-SUBSYSTEM command) and then restarted (START-SUBSYSTEM command) together with the unlocked subsystem.Even if the subsystem can be restarted from any state and all interdependencies with other subsystems - if any - have been allowed for (see above), after execution of the UNLOCK-SUBSYSTEM command there is no guarantee that the subsystem will be active after the next START-SUBSYSTEM command. This restriction particularly applies if there are any problems or situations for which the subsystem itself is responsible.