Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Management of the dynamic subsystem catalog

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 E

    Then 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 E

    X --> Y means that X requires Y in order to resolve external calls.

    Then:

    A --> D
    D --> E
    D --> B,C

    not 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 E

    X --> Y means that X is disjunctive to Y.

    Then:

    A --> D
    D --> E
    D --> B,C

    is 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.