Initial startup of HSMS

The initial startup of HSMS is carried out as a normal startup of an HSMS session except that usually the control and request files are missing or are still available from a previous HSMS version. The normal startup processing, however, takes this into account.

At the start of each HSMS session, the system checks for all control and request files in the following order:

1. First the central control file is checked and read into internal tables.

   • If no central control file is available, a new one is created. It already contains presettings which are then used for the start.

   • If the central control file is available and contains definitions dating from an earlier HSMS version, the definitions are recognized and automatically adjusted. Downgrading to a lower version is not supported!

   • If the central control file contains invalid records or is inconsistent, the start is aborted. Additionally, error messages are output to the operator terminal.

2. The central request file is then checked.

   • If the central request file is not available, a new empty request file is created.

   • If the central request file is available and contains data records that date from an earlier HSMS version, the start is aborted with errors. The request file cannot be adjusted and must therefore be deleted before the startup processing is restarted.

3. Next the local control file and the local request file of each accessible SM pubset are checked. First the local request file is checked and written to internal tables.

   • If no local control file is available for a specific SM pubset environment, a new one is created. This file already contains presettings which are used to start the SM pubset environment.

   • If a local control file is available and contains definitions that date from an earlier HSMS version, the definitions are recognized and automatically adjusted.

   • If a local control file contains invalid records or is inconsistent, the local start is aborted and the SM pubset environment is skipped. The start continues with the next SM pubset environment.

   • If an SM pubset under HSMS control cannot be accessed during startup of the HSMS session, it is skipped. It is started, however, when the SM pubset is imported to the host. There the same start is carried out (with checking and reading of the local request file).

Once the HSMS start is completed, the global HSMS parameter is adjusted to the requirements of the respective system by means of the HSMS statement:

//MODIFY-HSMS-PARAMETERS VALID-PERIOD=*PERMANENT,...

The presettings after the initial startup of HSMS are described at the end of the HSMS statement MODIFY-HSMS-PARAMETERS in “HSMS Vol. 2” [1].

The SM pubset-specific parameters can be changed with the following HSMS statement:

//MODIFY-SM-PUBSET-PARAMETERS

The presettings for the control file of an SM pubset are described in “HSMS Vol. 2” [1] under the HSMS statement MODIFY-SM-PUBSET-PARAMETERS.

Subsequent step-by-step transition is then possible from the SIMULATION operating mode in which action statements are only simulated, i.e. undesired data manipulation is prevented, to the normal OPERATION mode. In this mode, archives can be created and pubsets placed under HSMS management.

After initial startup of HSMS, only the default pubset of the SYSHSMS user ID is under HSMS management. It is allocated to storage level S0.
For all other pubsets, the default values which are listed in "HSMS Vol. 2” [1] for the HSMS statement MODIFY-PUBSET-PARAMETERS apply.
Integration of the SF pubset in HSMS management is described in section "Managing SF pubsets".
In the section "Processing SM pubsets" you will find a description of how SM pubsets are placed under HSMS management.