Adding to the dynamic subsystem catalog
System administration can extend the current dynamic subsystem configuration during a session (ADD-SUBSYSTEM command). The catalog for the new subsystem configuration must be generated using SSCM, and the following points must be noted:
If required, the new catalog can be larger that the old one (i.e. it may also include all the subsystems from the old catalog), or it may be created as a “delta” catalog, containing only the new subsystem definitions.
The “old” subsystem catalog, which was used during startup, will not automatically be updated. At the next startup it is possible
to use the “new” catalog, or
to use instead a catalog which has been completely recreated and which, for example, does not contain the versions of subsystems which are no longer being used, and in which the required changes have been made to attributes (such as CREATION-TIME).
ASSIGN-HOLDER-TASK statement
This statement must not be specified for old and new subsystems.
Example
Subsystems in the old catalog:
Subsystems in the new catalog:A, B, C
A, B, C, D and EThen the following is allowed:
//ASSIGN-HOLDER-TASK TYPE=SHARED-HOLDER(BY-SUBSYSTEMS=(A,B)) //ASSIGN-HOLDER-TASK TYPE=SHARED-HOLDER(BY-SUBSYSTEMS=(D,E))
and the following is not allowed:
//ASSIGN-HOLDER-TASK TYPE=SHARED-HOLDER(BY-SUBSYSTEMS=(A,B,E))
SET-SUBSYSTEM-ATTRIBUTES statement
The CREATION-TIME operand for a new subsystem must be compatible with any versions of the subsystem which already exist in the old subsystem configuration.
Example
If version 1 of subsystem X in the old catalog is declared with CREATION-TIME=*AT-SUBSYSTEM-CALL, then version 2 of subsystem X in the new catalog must have CREATION-TIME=*AT-CREATION-REQUEST.
If CREATION-TIME=*BEFORE-SYSTEM-READY or *AFTER-SYSTEM-READY has been specified for a new subsystem, the subsystem will not be created because the SYSTEM READY point in time (i.e. system initialization) will not occur. A corresponding message will be issued.
New subsystems which are being added and have the attribute MEMORY-CLASS=*LOCAL-PRIVILEGED (class 5 memory) must not alter the width of the system or user address space strip, nor the location of the old subsystems within this strip.
No relations may be declared from the old to the new subsystems (REFERENCED-SUBSYSTEM and RELATED-SUBSYSTEM operands).
Example
Subsystems in the old catalog:
Subsystems in the new catalog:A, B, C
A, B, C, D and EX --> Y means that X requires Y in order to resolve external calls.
Then:
A --> D
D --> E
D --> B,Cnot allowed
is allowed
is allowed.SEPARATE-ADDRESS-SPACE statement
New and old subsystems may be disjunctive, i.e. their addresses may overlap.
Example
Subsystems in the old catalog:
Subsystems in the new catalog:A, B, C
A, B, C, D and EX --> Y means that X is disjunctive to Y.
Then:
A --> D
D --> E
D --> B,Cis allowed
is allowed
is allowed.
Changing subsystem attributes during a session
The MODIFY-SUBSYSTEM-PARAMETER command can be used to change subsystem attributes during a session, without the user having to shut down the subsystem configuration or add a new version of the subsystem. Changes in the configuration can be saved for the next startup by means of the SAVE-SUBSYSTEM-CATALOG command.
These possibilities are helpful especially in the following situations:
In order to stop a subsystem, all the connected tasks must have cleared their links. If the subsystem was not defined with the attribute FORCED-STATE-CHANGE=*ALLOWED, there is no way of accelerating the deactivation of the subsystem. Should certain considerations make it necessary to do so, however, it is now possible to change the attribute dynamically by means of the MODIFY-SUBSYSTEM-PARAMETER command.
If memory pool contention occurs because, for example, two subsystems are located at the same address and the task can use only one of the two, the addresses of the subsystems can be changed to avoid memory pool contention by means of the MODIFY-SUBSYSTEM-PARAMETER command.