Activation and restart

Activation of a subsystem is controlled by the attributes that were defined in the subsystem catalog using the SSCM statement SET-SUBSYSTEM-ATTRIBUTES.

Activation is performed

• automatically during the first DSSM call in the startup routine if CREATION-TIME= *BEFORE-DSSM-LOAD or *AT-DSSM-LOAD was defined; activation must have been successfully completed (*BEFORE-DSSM-LOAD means that the subsystem had already been loaded before DSSM was first called by the startup routine. After DSSM is called, this subsystem will be managed like any other. Version exchange or version coexistence with another version defined with CREATION-TIME=*AT-DSSM-LOAD is permitted. It is the responsibility of systems support to ensure that one version of the subsystem is available at all times.)

• automatically during the second DSSM call in the startup routine if CREATION-TIME= *MANDATORY-AT-STARTUP was defined; in this case, activation must have been successfully completed.

• automatically during the second DSSM call in the startup routine if CREATION-TIME=*BEFORE-SYSTEM-READY was defined (synchronous).

• automatically after the second return to the startup routine if CREATION-TIME=*AFTER-SYSTEM-READY was defined (asynchronous).

• explicitly by means of the START-SUBSYSTEM command.

• explicitly as a local subsystem by means of the START-LOCAL-SUBSYSTEM command.

• explicitly when the $ESMCRE interface is called.

• implicitly after the first SVC call for a subsystem which was defined with CREATION-TIME=*AT-SUBSYSTEM-CALL(ON-ACTION=*STD or *ANY)
  or implicitly after the first ISL call for a subsystem that was defined with CREATION-TIME=*AT-SUBSYSTEM-CALL(ON-ACTION=*ISL-CALL or *ANY).

With reference to the start point for subsystems see also the SSCM statement SET-SUBSYSTEM-ATTRIBUTES.

In the same way as the other files required for DSSM initialization (e.g. SSMCAT) and the files required for activation of subsystems linked to startup, the program or object module library (OML) and the DSSM REP and NOREF files must have been created on the home pubset under the TSOS user ID, and must be available at startup.
Subsystems which are linked to startup are those whose activation points (creation points) are specified by the following values:

• *BEFORE-SYSTEM-READY

• *AFTER-SYSTEM-READY

• *BEFORE-DSSM-LOAD

• *AT-DSSM-LOAD

• *MANDATORY-AT-STARTUP

An indispensable precondition for activation is that the subsystem name is known, i.e. declared in the global or local subsystem catalog.

Activation takes place in the following steps:

1. The job is checked, in particular the dependencies on other subsystems (synchronous).

   If a subsystem has components which were declared with the attribute *INSTALLED and installed using IMON, DSSM calls IMON-GPN during the checking phase in order to find out the path names of the files.

   Depending on the availability of IMON-GPN and on the status of the installed installation unit (see the INSTALLATION-UNIT operand), DSSM acts as follows:

   • if the installation unit exists and a file name can be linked to the specified logical ID:

     DSSM will use this file name as long as the subsystem is active (until STOP-SUBSYSTEM) or until another file name is defined by means of the MODIFY-SUBSYSTEM-PARAMETER command.

   • In the following situations, DSSM accesses the DEFAULT-NAME defined in the catalog, if there is one:

     • IMON-GPN is not available

     • the INSTALLATION-UNIT does not exist in the IMON-GPN data

     • the INSTALLATION-UNIT exists in the IMON-GPN data but has no connection to a logical name (LOGICAL-ID)

   The message ESM0665 explains what is happening:

   ESM0665  'DEFAULT-NAME' USED FOR FILES OF SUBSYSTEM '(&00)'

   • The INSTALLATION-UNIT exists in the IMON-GPN data with a few appropriate path names but the queried logical name does not exist. DSSM now assumes that the file does not exist. Two cases are to be discriminated:

     • Subsystems that were defined with the *AT-DSSM-LOAD or *MANDATORY-AT-STARTUP attribute:
       During startup, a query that must be answered is issued to the operator
       terminal. The operator can now either specify a new, valid name for the file concerned (information file, module library or REP file with the REP-FILE-MANDATORY=*YES attribute) or stop the subsystem activation.

     • Subsystems that were defined with the *AT-CREATION-REQUEST, *AFTER-SYSTEM-READY or *BEFORE-SYSTEM-READY attribute:
       If one of the files (module library, information file or REP file with the REP-FILE-MANDATORY=*YES attribute) is missing, the subsystem is not activated and this is indicated with a message. If the message file or REP file (with the REP-FILE-MANDATORY=*NO attribute) is missing, the subsystem is activated but a warning is still output.

2. The subsystem is loaded in a holder task (asynchronous)
   Loading of the subsystem code is initiated by the holder task.
   In addition it makes its local address space (user address space) available for the subsystems that were defined with MEMORY-CLASS=*LOCAL-
   PRIVILEGED/*LOCAL-UNPRIVILEGED. The loading of subsystems with MEMORY-CLASS=*SYSTEM-GLOBAL is also initiated by the holder task; however, they are not loaded into the holder task’s user address space but into the shareable system address space.

   When TU subsystems are activated with MEMORY-CLASS=*BY-SLICE, the shareable program area is loaded into the shareable system address space, and the nonshareable program area and/or data area into the user address space of the holder task.

   If a task establishes a connection to a subsystem of this type, only the data area that has already been loaded in the user address space of the holder task is copied to the same address in the private user address spaces of the connected tasks. This means that address-related references between the program area and data area are always possible. Performance is considerably enhanced by this method of address space distribution because no access is made to the program library or object module library when a task is connected to the subsystem, and external references do not have to be resolved.

   If a subsystem was defined with MEMORY-CLASS=*BY-SLICE and is started for the first time, DSSM informs the BLSSERV subsystem that the copy of the data area in the private user address space can be accessed with the VSVI1 macro.
   The VSVI1 macro informs the user about entries in the DBL tables. See the manual “BLSSERV” [4] for details on the macro.

   The holder task can also be used as the work task.

3. For TPR subsystems only: subsystem activation is started in the holder task if an INIT routine has been defined (asynchronous).

4. After completion of activation, the subsystem is opened for connections of authorized users (asynchronous).

Restarting a subsystem (RESUME-SUBSYSTEM) after a HOLD-SUBSYSTEM consists of steps 1, 3 and 4.
In step 1 it is not necessary to call IMON-GPN.

If the activation or restart of a subsystem is initiated explicitly via the START-SUBSYSTEM or RESUME-SUBSYSTEM command, the synchronous processing mode can be selected instead of the asynchronous mode.