Request-time control is concerned with how a request created by a user task is forwarded to an HSMS server task. In request-time control – apart from the forwarding of a request from one task to another – the following conditions, for example, must be taken into account:
Serial processing of requests that were issued for the same archive:
some requests require exclusive access to the specified archive.Serial processing of requests which write to the same save file of an archive:
as this concerns the same volumes, serial processing is mandatory here.Optimization, e.g. tape handling via collector requests.
Parameters for a tape processing time which control access to the tape (storage level S2).
There are requests which do not need to be processed serially. These are requests for the restoration and recall of files, as well as requests which create a save file on S1. Such requests are processed completely in parallel if they restore or recall no files from S2 or from the same SFID of the same magnetic tape cartridge. The first free HSMS server task receives the request and processes it.
Requests which affect backups, version backups or node backups can only continue the last save file of the archive concerned or create a new save file, as the sequence of the save files (SFIDs) and save versions (SVIDs) must be guaranteed. When an attempt is made to continue a save file other than the last one, a new save file is created. Such requests are processed serially. When a server task accepts the request of an archive to be processed serially, it receives all requests which concern this archive. The server task calls ARCHIVE for all these requests. ARCHIVE ensures that they are processed serially.
Requests which concern the other archive types are processed as follows:
in parallel if they write to different save files
serially if they write to the same save file.
If a server task accepts the request of such a “serial SFID” archive, the server task locks the relevant output save file. All other requests affecting the same archive and the same save file are processed by the same server task, which ensures the correct serial processing.
The number of output save files that can be processed in parallel is physically limited to eight different save files per archive.
If a server task accepts several requests, it can create a collector request in order to optimize the tape processing (see section "Collector requests").
The following tables show the type of processing for every possible request combination issued for the same archive:
| BCF | RSF/RLE | ARF | BFV | MGF | RMF | CSF/MSF | RVB | |
| BCF | parallel | parallel | not relevant | not relevant | not relevant | not relevant | parallel | not relevant |
| RSF/RLE | parallel | parallel | parallel | parallel | parallel | parallel | parallel | |
| ARF | parallel | not relevant | not relevant | not relevant | parallel | not relevant | ||
| BFV | serial (1) | not relevant | not relevant | not relevant | serial (2) | |||
| MGF | parallel | parallel | parallel | not relevant | ||||
| RMF | parallel | parallel | not relevant | |||||
| CSF/MSF | parallel | not relevant | ||||||
| RVB | serial (2) |
BCF | BACKUP-FILES |
RSF | RESTORE-FILES |
RLE | RESTORE-LIBRARY-ELEMENTS |
BFV | BACKUP-FILE-VERSIONS |
ARF | ARCHIVE-FILES |
MGF | MIGRATE-FILES |
RMF | RECALL-MIGRATED-FILES |
CSF | COPY-SAVE-FILE |
MSF | MOVE-SAVE-FILES |
RVB | REORGANIZE-VERSION-BACKUP |
(1) | With a BACKUP-FILE-VERSIONS statement the sequence of the versions of file must be guaranteed. Therefore parallel processing is not possible. |
(2) | During reorganization process perform of other write requests is prohibited. Therefore parallel processing is not possible. |
BCF | RSF / RLE | ARF | BFV | MGF | RMF | CSF/MSF | RVB | |
BCF | serial (1) | parallel | not relevant | not relevant | not relevant | not relevant | serial (3) | not relevant |
RSF / RLE | parallel | parallel | parallel | parallel | parallel | parallel | parallel | |
ARF | via SFID (2) | not relevant | not relevant | not relevant | via SFID (2) | not relevant | ||
| BFV | serial (4) | not relevant | not relevant | not relevant | serial (5) | |||
MGF | via SFID (2) | parallel | via SFID (2) | not relevant | ||||
RMF | parallel | parallel | not relevant | |||||
CSF / MSF | via SFID (2) | not relevant | ||||||
| RVB | serial (5) |
BCF | BACKUP-FILES |
RSF | RESTORE-FILES |
RLE | RESTORE-LIBRARY-ELEMENTS |
BFV | BACKUP-FILE-VERSIONS |
ARF | ARCHIVE-FILES |
MGF | MIGRATE-FILES |
RMF | RECALL-MIGRATED-FILES |
CSF | COPY-SAVE-FILE |
MSF | MOVE-SAVE-FILES |
RVB | REORGANIZE-VERSION-BACKUP |
(1) | With a backup or node backup the sequence of the SFIDs and SVIDs must be guaranteed for partial backups. Therefore parallel processing is not possible. |
(2) | Requests which affect the same save file are processed serially. Requests which affect different save files are processed in parallel. Nevertheless, requests issued at the same moment can be taken by one HSMS server task and in this case they will be processed serially even if the target save files are different. |
(3) | With a COPY-SAVE-FILE statement for a backup archive or node backup archive, the sequence of the SFIDs and SVIDs must be guaranteed. Therefore parallel processing is not possible. |
(4) | With a BACKUP-FILE-VERSIONS statement the sequence of the versions of file must be guaranteed. Therefore parallel processing is not possible. |
(5) | During reorganization process performing of other write requests is prohibited to guarantee the consistency of the directory. Therefore parallel processing is not possible. |
BNF | RNF | ANF | CNF/MSF | |
BNF | serial (1) | parallel | not relevant | serial (3) |
RNF | parallel | parallel | parallel | |
ANF | via SFID (2) | via SFID (2) | ||
CNF/MSF | via SFID (2) |
BNF | BACKUP-NODE-FILES |
RNF | RESTORE-NODE-FILES |
ANF | ARCHIVE-NODE-FILES |
CNF | COPY-NODE-SAVE-FILE |
MSF | MOVE-SAVE-FILES |
(1) | With a backup or node backup the sequence of the SFIDs and SVIDs must be guaranteed for partial backups. Therefore parallel processing is not possible. |
(2) | Requests which affect the same save file are processed serially. Requests which affect different save files are processed in parallel. Nevertheless, requests issued at the same moment can be taken by one HSMS server task and in this case they will be processed serially even if the target save files are different. |
(3) | With a COPY-NODE-FILE statement for a backup archive or node backup archive, the sequence of the SFIDs and SVIDs must be guaranteed. Therefore parallel processing is not possible. |
In a COPY-SAVE-FILE request two archives are involved; sequencing takes place in accordance with the target archive. The source archive’s directory remains open during execution of the copy request and can, during this time, block other requests (for example restore or backup requests) for the same archive.
Warning
Under certain circumstances, requests to be processed in parallel can lead to unexpected results. You should therefore pay particular attention to the following:
A restore request for files which are currently being processed by a backup request can either restore the previous status of the files from the preceding backup, or their current status from the backup that is currently running.
After an SM pubset is imported or the HSMS subsystem is started, it may be the case that when previously accepted requests are reactivated the original order of job acceptance is not taken into consideration.
The parallel processing of requests – mainly during the restore – allows different server tasks to use the same save file. Due to the reservation of the volumes, however, the requests are actually processed serially.
If save files are rescued with the MODIFY-ARCHIVE statement, exclusive access to the archive directory is necessary. Such a rescue operation is therefore rejected if other requests are accessing the archive. By the same token, execution of requests is suspended as long as an archive is being rescued.