Requests that were interrupted during processing (INTERRUPTED state) can be continued using the HSMS statement RESTART-REQUESTS. They do not have to be restarted from the very beginning. A distinction has to be made between the following two cases:
The request was interrupted before being passed to ARCHIVE for processing. In this case, the request can be continued.
The request was interrupted while being processed by ARCHIVE. In this case, the request cannot be continued by means of RESTART-REQUESTS unless checkpoints for this request have been written to the ARCHIVE checkpoint file.
With the HSMS statements for BS2000 files (BACKUP-FILES, ARCHIVE-FILES,...) as well as with the HSMS statement BACKUP-NODE-FILES, the writing of checkpoints is initiated by specifying WRITE-CHECKPOINTS=*YES for the OPERATION-CONTROL operand or WRITE-CHECKPOINTS=*STD if *YES is the default value for the archive concerned.
The requests cannot be continued unless the current operating mode is the same as at the time they were accepted by HSMS (either SIMULATION or OPERATION mode).
In certain coincidental conditions, HSMS generates more than one ARCHIVE run under the one request.
If the request is interrupted and restarted using RESTART-REQUESTS, only the ARCHIVE run started last is restarted, then the request is terminated. The report of the request will contain an error message to this effect.
When requests for node files are restarted, the appropriate UNIX file systems must be mounted, as otherwise, considerable wait times may occur before the UNIX file systems are active again.
Backup requests with Concurrent Copy which use SHC-OSD mirroring functions can be placed in the INTERRUPTED status if problems occur during processing. In this case they can be updated.
All other backup requests with Concurrent Copy are placed in the COMPLETED-WITH-ERRORS status when errors occur and not in the INTERRUPTED status. They can therefore not be updated.
In SM environments, requests with INTERRUPTED status are not linked to the processing host. The restart can therefore be issued from any of the SM pubset sharers irrespective of which host the request was originally generated on. However a request can only be restarted with the same HSMS version with which it was being processed before the interruption.
Normally a restart can only be issued for requests that were interrupted because of a device fault or volume error.
A restart for requests that were interrupted at any given place in execution because of a system crash cannot generally be performed successfully.
In an inhomogeneous shared SM-environment, as soon as at least one of the system has HSMS V12.0 installed, it is recommended to restart requests within the same configuration as it was started originally: processing system (master or backup server) during restart should have the same version of HSMS as when request was started initially.
Note that restarting requests concerning extended S1 level is only possible within HSMS V12.0. Moreover, such requests interrupted in lower HSMS versions even cannot be started with HSMS V12.0.