When a processor crashes, the availability of critical applications can be guaranteed by relocation to another processor. An essential factor of relocating an application to a second processor is that all data required by the application on the substitute processor must be made available.
Determining all the data that is required for the switchover (= switchover unit) is often problematical because the application data is distributed over different pubsets with different availability and performance characteristics. In certain circumstances, it may also have to be provided from various storage levels as well (e.g. migrated files, restoration of files damaged as a result of a processor crash). For this reason, the metadata must also be made available on the substitute processor. As explained above, the metadata (at least that required by HSMS) has to be searched for in various storage locations.
The concept of system-managed pubsets (SM pubsets) represents a considerable help in forming the switchover unit. An SM pubset can be regarded as a closed container for interrelated data.
This "closedness" is basically made possible by the following configuration characteristics:
An SM pubset contains all the associated metadata, in particular that required by HSMS.
An SM pubset supports volumes with different formats and performance, reliability and usage attributes; each "volume set" subunit contains a set of volumes with identical attributes.
If an S1 storage level is to be supported for the migration, it is implemented as a volume set within an SM pubset.
For storage level S2, a description is stored of the tape pool with which it isimplemented.
Essential to the practicability of the concept of an SM pubset as a self-contained, closed switchover unit is also that it can support volume sets with different attributes. Different demands may be made on the attributes of volumes of data within an application, e.g. they must be particularly reliable or access performance must be especially efficient. Only when there is attribute flexibility within a pubset can the use of several (homogeneous) pubsets with different physical compositions be avoided.
After switching an SM pubset over to a substitute processor, all the data required to operate the pubset is available (because of its self-contained, closed nature). Not only can applications be restarted, but also HSMS jobs can be resumed.
After the HSMS administrator has entered the HSMS statement RECOVER-REQUESTS, all jobs that were issued on the crashed processor are integrated in local jobs. If a SHOW-REQUESTS statement is then started, information is output about the status of the jobs at the time of the processor crash. Jobs that had not been started on the crashed processor can be processed on the substitute processor. Jobs that were actually running at the time of the crash and were interrupted, can be restarted on the substitute processor.