Dynamic activation

When a supply unit is installed, activation is prepared for the next system run. For subsystems, apart from the activation of the message and syntax files, only the static subsystem catalog is updated. The dynamic subsystem catalog of the current system is not changed.

With the “dynamic activation” function, a newly installed supply unit (of the corresponding installation units) can be made available already in the current system, i.e. with no interruption. Dynamic activation includes:

• Activation of the syntax files in the current system

• Activation of the message files in the current system

• Activation of the POSIX files in the current system. The POSIX commands needed to directly register the activated unit in the POSIX system using the /START-POSIX-INSTALLATION command are generated in the activation procedure.

• Starting the subsystem from the subsystem catalog of the installation unit (this point is not executed in case of “non-subsystems”)

Dynamic activation can be carried out for every supply unit (or installation unit), which has the attribute “activable”. The choice of the supply units (or installation units) to be activated is determined either from the opened standard SCIs, or from an opened delivery from the last installation process.

Definition of activability

Supply units and installation units have the attribute “activable” or “not activable”, entered in SCI with “Activable=Yes” or “Activable=No”, and shown with the corresponding information output (see example of supply unit on "Supply unit " or installation unit on "Installation unit (IU) ").

A supply unit is activable if it contains at least one activable installation unit.

Activability of an installation unit

When attributes are assigned, first of all the distinction is made for installation units between subsystems and non-subsystems.

“Non-subsystems” are in any case classified as “activable”.

Subsystems are divided into 5 levels with respect to their activability. The Activation level is entered in SCI as an additional attribute (information output in the field “Level”):

Level 1:	the subsystem is activable
Level 2:	the subsystem is activable but the creation-time subsystem attribute is changed
Level 3:	the subsystem is only activable under certain conditions
Level 41:	the subsystem has dependencies to other subsystems, but is activable
Level 42:	the subsystem has dependencies to other subsystems and is only activable under certain conditions

The assignment of the activation level depends on the subsystem attributes defined by the subsystem catalog:

• In Level 1 the subsystem attributes permit dynamic activation:

  creation-time version-exchange version-coexistence state-change-cmds subsystem-hold

  = = = = =

  at-creation-request / at-subsystem-call allowed / forbidden allowed / forbidden allowed allowed

  In the section FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS of the catalog definitions there are no subsystem entries.

  In the section REFERENCED SUBSYSTEMS of the catalog definitions, there are no further subsystem entries except for CP.

• In Level 2 the subsystem attributes permit dynamic activation, if attributes are changed in advance:

  creation-time	=	at-dssm-load / before-dssm-load / before-system-ready / after-system-ready / mandatory-at-startup
  version-exchange	=	allowed / forbidden
  version-coexistence	=	allowed / forbidden
  state-change-cmds	=	allowed
  subsystem-hold	=	allowed

  In the section FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS of the catalog definitions,

  there are no subsystem entries.

  In the section REFERENCED SUBSYSTEMS of the catalog definitions, there are no

  subsystem entries except for CP.

• In

  Level 3 the following subsystem attribute prevents a subsystem included in the

  selection from being started or stopped:

  state-change-cmds      =   forbidden

• In Level 41 the subsystem attributes permit dynamic activation:

  creation-time version-exchange version-coexistence state-change-cmds subsystem-hold

  = = = = =

  at-creation-request / at-subsystem-call allowed / forbidden allowed / forbidden allowed allowed

  There are subsystem entries in the section FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS or in the section REFERENCED SUBSYSTEMS of the catalog definitions.

In Level 42 the subsystem attributes permit dynamic activation, if attributes are changed in advance:

creation-time	=	at-dssm-load / before-dssm-load / before-system-ready / after-system-ready / mandatory-at-startup
version-exchange	=	allowed / forbidden
version-coexistence	=	allowed / forbidden
state-change-cmds	=	allowed
subsystem-hold	=	allowed

There are subsystem entries in the section FUNCTIONAL DEPENDENCE WITH SUBSYSTEMS or in the section REFERENCED SUBSYSTEMS of the catalog definitions.

Dynamic activation is performed through the IMON function “Edit: activate” or the statement ACTIVATE-UNITS. It is divided into two phases:

> >	Preparation of the dynamic activation Actual execution

Preparation of dynamic activation

Choice of supply units or installation units to be activated

First the supply units or installation units to be dynamically activated are selected. The choice is made in menu mode using the IMON function “Edit: Activate”, in SDF mode directly with the statement ACTIVATE-UNITS. The choice can be made in the following ways:

• The user states the objects to be activated explicitly with the operand UNIT-NAME or marks them directly in the work area.

• The user only has the activable objects displayed (in the operand UNIT-NAME=*BY-DIALOG or in menu mode View:Supply-Units and Activable=2 (Yes) in the Supply Units dialog box. He then selects the desired objects directly in the work area. The amount of activable objects can be further limited by the following selection criteria:

  • Choice of one or more deliveries (package name and customer ID are shown in the operand SELECT=*SOLIS2-DELIVERY(...) or in the dialog box Supply Unit View)

  • Choice of the objects of the most recently executed installation (corresponds to the preset value: Operand SELECT=*LAST-INSTALLED or Last Installation=1 (Yes) in the dialog box Supply Unit View)

  If a selection includes multiple occurrences of an installation unit, the unit will be activated once only. If there are several versions of the same installation unit, only the highest version will be activated.

After the selection has been made, IMON identifies the method of dynamic activation. There are three ways:

• A new subsystem is activated.

• The correction version of a subsystem is activated.

• The version of the subsystem to be activated replaces an existing subsystem.

IMON then generates the following two files.

• Log file $SYSSAG.<prefix>.<time-stamp>.RP that contains all DSSM commands (STOP-, REMOVE-, ADD- and START-SUBSYSTEM) for the subsystems that can be activated

• Activation procedure $SYSSAG.<prefix>.<time-stamp>.DA that contains all necessary commands and statements for dynamic activation of the selected objects

The default prefix is the string IMONACU (see also "Important activation files" (Error handling and activation restart )).

Once the two files have been generated, IMON interrupts the preparation phase with a prompt. The user can check the log file and then respond to the prompt with answer “1” or “2” to either abort or continue the activation process.

Response	Effect
1	Aborts the activation process. Log file and activation procedure are deleted.
2	Resumes the activation process (see also "Actual activation"). Depending on the call option selected, the activation procedure is started automatically or the activation process is terminated normally so that the activation procedure can be started manually at a later time.

Structure of the log file

The log file is divided into two parts.

• Part 1 lists all supply units or installation units selected for activation and, if necessary, any errors or warnings that occurred during their processing.

• Part 2 contains all DSSM commands to activate the subsystems for which no error was reported in the first part. This information is listed in columns.

Column	Meaning and possible values
1	Subsystem type; possible values SS: Subsystem selected via the supply unit or installation unit SS-DEP: Subsystem to which there is a dependency SS-DEL: Subsystem to be removed (i.e. deletion from the subsystem catalog or, if necessary, deactivation of associated syntax files)
2	Name of the subsystem
3	Version of the subsystem
4	DSSM command (abbreviated name) that is to be executed for the subsystem (possible values: STOP, REMOVE, ADD, START)
5 - 8	Identification of the installation unit that contains the relevant subsystem

Structure of the activation procedure

The activation procedure breaks down into individual processing steps that support a restart/recovery mechanism in the event of an error (see section "Error handling and activation restart"). The following processing steps are possible.

1. Releasing an installation unit lock

   This activation step groups all UNLOCK-PRODUCT-VERSION commands for the selected installation units or the installation units in the selected supply units.

2. Creating a subsystem catalog

   This activation step groups all SSCM statements that are needed to create the catalogs for all relevant subsystems.

3. Stopping the subsystem to be deleted

   This activation step groups all STOP-SUBSYSTEM commands that are needed to stop the subsystems that are to be deleted (if there are installation items of the type SSC).

4. Deactivating the syntax files of the subsystem to be deleted

   This activation step groups all MODIFY-SDF-PARAMETERS commands that are needed to deactivate the syntax files of subsystems to be deleted (if there are installation items of the type SDF).

5. Stopping a subsystem

   This activation step groups all STOP-SUBSYSTEM commands for the subsystems resulting from the selection.

   To check whether the subsystems have been stopped, IMON generates a call of the internal WAIT-SUBSYSTEM-STATUS function for each of the subsystems. These calls are terminated without error if all subsystems have the NOT CREATED status. If one of the subsystems has a different status, the call fails and the activation process is interrupted.

   Note

   The subsystems to be stopped are divided into two subgroups.

   • The subsystems in the selection that are divided further into subsystems of level 4 and subsystems of levels 1 and 2.

   • Subsystems that have dependencies to the selected subsystems. These subsystems must be stopped before the selected subsystems are stopped.

6. Deleting a subsystem

   This activation step groups all REMOVE-SUBSYSTEM commands for the subsystems resulting from the selection.

7. Activating a message file

   This activation step groups all MODIFY-MSG-FILE-ASSIGNMENT commands for all message files included in the selection.

8. Activating a syntax file

   This activation step groups all MODIFY-SDF-PARAMETERS commands for all syntax files included in the selection.

9. Adding a new subsystem catalog

   This activation step groups all ADD-SUBSYSTEM commands for the subsystem catalogs created in activation step 2.

   In order to check whether the subsystem catalogs have been added, IMON generates a call of the internal WAIT-SUBSYSTEM-STATUS function for each of the subsystems.

   These calls are terminated without error if all subsystems have the NOT CREATED status. If one of the subsystems has a different status, the call fails and the activation process is interrupted.

10. Starting a subsystem

    This activation step groups all START-SUBSYSTEM commands for the subsystems resulting from the selection.

    In order to check whether the subsystem catalogs have been started, IMON generates a call of the internal WAIT-SUBSYSTEM-STATUS function for each of the subsystems.

    These calls are terminated without error if all subsystems have the NOT CREATED status. If one of the subsystems has a different status, the call fails and the activation process is interrupted.

    Note

    The subsystems to be stopped are divided into two subgroups.

    • The subsystems in the selection that are divided further into subsystems of level 4 and subsystems of levels 1 and 2.

    • Subsystems that have dependencies to the selected subsystems. These subsystems must be stopped before the selected subsystems are stopped.

11. Performing POSIX processing
    This activation step groups all POSIX processing processes for all installation items of type *PS / *NP included in the selection.

12. Resetting subsystem attributes for subsystems of level 2

    This activation step groups all MODIFY-SUBSYSTEM-PARAMETER commands for the subsystems classified with level 2.

13. Restoring the status of a subsystem stopped due to dependencies

    This activation step groups all START-SUBSYSTEM commands for the subsystems that were stopped due to existing dependencies (see activation step 5).

Actual activation

The actual activation takes place when the generated activation procedure is run. The activation procedure cannot be started unless the user resumes the preparation phase interrupted by IMON after checking the log file by choosing response “2”. IMON deletes the generated files if the user selects response “1”.

As default, the procedure is run automatically. The procedure can also optionally be started manually with the command ENTER-PROCEDURE (operand START=*BY-USER in the statement ACTIVATE-UNITS or Start = 2 (By user) in the dialog box Activation parameters).

Refer to the section "Error handling and activation restart" for information on handling errors that may occur during the course of the activation procedure.