The OPERATION-CONTROL operand serves to control request processing. Some of its values are preset by the archive definition (except for data transfer). It is, however, possible to modify these presettings with the action statement which generates the request.
PARALLEL-RUNS
Number of ARCHIVE subtasks for a save request running in parallel. This enables save times to be considerably reduced, especially for system save runs, as HSMS saves the files of different user IDs to different tape devices.
If preprocessing/postprocessing is activated (PRE-POST-PROCESSING operand) in the case of operations involving the BACKUP-NODE-FILES and RESTORE-NODE-FILES statements, the ARCHIVE subtasks await the results of the preprocessing action before they commence data exchange with the workstation. However, this results in degraded performance.
If multiplexing operation is not active (see section "Multiplexing operation"), there must be one tape device per task when writing to or reading from S2 in order to accelerate processing (for the conditions see the section "Parallel and serial processing in ARCHIVE" as well as in the “ARCHIVE” manual [2] ).
If multiplexing operation is active, the system calculates the number of ARCHIVE subtasks. The number of tape devices is taken from the user specification (see section "Multiplexing operation").
Two tape devices per task must be available when save files are duplicated from S2 to S2 or automatically to a shadow archive.
When save files are written to Net-Storage, a corresponding number of Net-Storage volumes must be specified. This specification depends on the number of save tasks running simultaneously.
Each time a save file is read (restored, recalled, duplicated), no more ARCHIVE subtasks can be executed than were used during writing to this save file.
If during reading of a save file fewer parallel runs are used than when writing to this save file, the tapes may be rewound to the beginning-of-tape marker.
WRITE-CHECKPOINTS
This operand determines whether checkpoints are to be written to the ARCHIVE checkpoint file during processing by ARCHIVE in order to provide for a restart following an interrupt (INTERRUPTED state); see section "Restarting requests".
OPERATOR-INTERACTION
This operand regulates how messages which require an operator response are to be handled. If the messages are not to be output to the console, HSMS performs default handling (see the description of the PARAM statement in the “ARCHIVE” manual [2]).
REQUEST-NAME
The REQUEST-NAME operand serves to assign a request a symbolic name. This name can then be used in the HSMS statements listed below to refer to the request. HSMS internally expands the name to include the caller’s user ID and a time stamp. This means that the name does not have to be unique. The HSMS statements for request management may refer to various requests using the same name.
The request name can be thought of as the HSMS job name. It is used as the job name for ARCHIVE subtasks.
If the user does not define any name, the requests are assigned default names formed by an invariable short code plus the task sequence number (TSN) of the user task.
Action statement | Standard name of the request |
ARCHIVE-FILES | ARF#yyyy |
ARCHIVE-NODE-FILES | ANF#yyyy |
BACKUP-FILES | BCF#yyyy |
BACKUP-FILE-VERSIONS | BFV#yyyy |
BACKUP-NODE-FILES | BNF#yyyy |
COPY-EXPORT-SAVE-FILE | CES#yyyy |
COPY-NODE-SAVE-FILE | CNF#yyyy |
COPY-SAVE-FILE | CSF#yyyy |
EXPORT-FILES | EXF#yyyy |
IMPORT-FILES | IMF#yyyy |
MIGRATE-FILES | MGF#yyyy |
MOVE-SAVE-FILES | MSF#yyyy |
RECALL-MIGRATED-FILES | RMF#yyyy |
REPAIR-CATALOG-BY-RESTORE | RCR#yyyy |
| REORGANIZE-VERSION-BACKUP | RVB#yyyy |
REPLACE-SAVE-FILE-BY-RESTORE | RFR#yyyy |
RESTORE-FILES | RSF#yyyy |
RESTORE-LIBRARY-ELEMENTS | RLE#yyyy |
RESTORE-NODE-FILES | RNF#yyyy |
UPDATE-EXPORT-SAVE-FILE | UES#yyyy |
REQUEST-DESCRIPTOR
Request submitters can use this operand to specify a text of their choice to describe the request in more detail. This text is output at the system console when the request is started. It can be viewed using the HSMS statement SHOW-REQUESTS.
The REQUEST-DESCRIPTOR operand is a simple way for job submitters to send system administrators information about a request. The system administrator can then take suitable measures for special requests.
However, it is not possible to reference these operands as selection criteria in subsequent statements, for example in the HSMS statement DELETE-REQUESTS, RESTART-REQUESTS or SHOW-REQUESTS.
EXPRESS-REQUEST
The HSMS administrator can start requests as express requests which can be controlled independently of the requests of nonprivileged users.
Express requests are reactivated during the tape session control defined especially for them. The tape session controls for express requests are separate from the normal tape session controls for write/read requests. All urgent requests should therefore be started as express requests and tape session controls should be defined for express requests that are called earlier or more frequently than the normal tape session controls.
Moreover, express requests are accorded a higher processing priority than normal requests issued for the same archive (see section "Assigning priorities for request processing").
WAIT-FOR-COMPLETION
Users can determine whether they wish to wait until HSMS has processed the entered statement in the background or whether they can make the next entry immediately (see section "Asynchronous and synchronous processing").