HSMS supports both the implicit and explicit recovery of requests.
Implicit recovery
During an implicit recovery, the system attempts to rescue the request file. The requests undergo the following operations:
Implicit recovery of requests is carried out at the beginning of an HSMS session.
In an SF environment, implicit recovery occurs each time the subsystem is generated. All of the requests located in the global HSMS request file are processed.
Requests with status COMPLETED are deleted based on the value of KEEP-REQUESTS. The value of KEEP-REQUESTS can be changed with the command MODIFY-HSMS-PARAMETERS. By default the value is *YES (40 days).
In an SM environment, implicit recovery occurs each time the SM pubset is started up, i.e. during import of the pubsets or generation of the subsystems if it was possible to access the SM pubset. For implicit recovery, the inhibit mechanism is taken into account: a thirdparty host cannot update any request that is inhibited by another host. This means that the implicit recovery of an SM pubset is just a “host-local” recovery.
Explicit recovery
Within the framework of the HIPLEX concept (see section "HIPLEX and HSMS"), HSMS supports an explicit mechanism for the extended recovery of requests. This mechanism is, however, only available for environments with SM pubsets. HSMS can use the explicit recovery to respond to host crashes and host reconfigurations within
SM pubsets.
An explicit recovery accesses requests that are inhibited by another host. This remote host is usually no longer in the SM pubset configuration. The cause may be a normal export or a system crash. It is possible that the request file still contains requests that are inhibited by the remote host.
Explicit recovery is only available to the HSMS administrator on the master sharer of the SM pubset. The HSMS administrator initiates it based on an SM pubset and a host name if he feels this is necessary. A standard reason may be that the remote host cannot recover the SM pubset configuration within a reasonable time.
For an explicit recovery, the system checks whether the host to be recovered is an active sharer of the SM pubset. If it is, the recovery is rejected. For an exclusive SM pubset, this is achieved by excluding the host itself from the recovery process. In the case of shared SM pubsets, this is achieved by calling the MSCF monitoring task which continuously monitors all the active sharers of all shared SM pubsets. If the connection to the monitoring task fails, the recovery is again rejected.
Monitoring can be suppressed with the FORCE operand of the RECOVER-REQUESTS statement. This can be useful when the host to be recovered is still active, but shows no HSMS activities for the specified SM pubset.
Generally speaking, we do not recommend forcing the recovery of a sharer because it
eliminates processing inhibits
may start certain requests twice
may result in inconsistencies in the archive directory.
The recovery normalizes every request inhibited by a host. The inhibit is cancelled and the request is changed depending on its status, in the same way as during implicit recovery:
Requests with status ACCEPTED are reactivated on the local host and a new inhibit is set.
Requests with Concurrent Copy and which have the status ACCEPTED and do not use SHC-OSD mirroring functions are assigned status CANCELLED.
Requests with status STARTED are assigned status INTERRUPTED.
Requests with status STARTED which could not be restarted are assigned status COMPLETED.
After recovery, the unlocked requests can be accessed by any sharer. Requests with status INTERRUPTED can be restarted by any sharer. Requests with status INTERRUPTED, COMPLETED or CANCELLED can be deleted by any sharer.
If two hosts crash – e.g. master and a slave – an explicit recovery on the new master host can be requested for each host. The recovery sequence is irrelevant to the result.