HSMS requires a number of work files for operation. The control file and the request file are of primary importance for HSMS operation. They are created during installation. The other files are temporary files which serve as output or scratch files.
As of HSMS V7.0 the files are neutral created in NK format (using BLOCK-CONTROL-INFO=*WITHIN-DATA-4K-BLOCK and BUFFER-LENGTH=*STD(SIZE=4)).
The maximum size of the HSMS work files is restricted to 32 GB. If this size is exceeded, for example, as a result of user intervention, then HSMS is no longer able to open or process the work file.
Control files
All parameters defined for HSMS operation are stored in control files. That is why control files are so important to HSMS operation.
A central control file manages the global HSMS parameters, all the definitions for the SF pubset environment (archives and pubsets) and the definitions for the workstations. There is only one central control file. It is created under the SYSHSMS user ID and the default catalog ID. The name of the central control file is:
HSM.1.CONTROL.FILE
In addition to the central control file, a local control file is also created for each SM pubset under HSMS control. This file is created under the SYSHSMS user ID on the control volume set of the SM pubset. It contains the global HSMS parameters specific to, and the archives defined in, the SM pubset environment.
The name of the local control file for an SM pubset is:
HSM.1.SM.CONTROL.FILE
The control files are created as ISAM files with USER-ACCESS=*OWNER-ONLY without password protection.
The control files are checked at the start of each HSMS session. All the definitions contained in the control files are read into internal tables. Because the control files are upwardly compatible, old data records are automatically recognized and updated.
You must make a copy of a control file before an upgrade if you wish to retain the option of reverting back to your present version. For details on the compatibility of control files, see section "Compatibility of HSMS definitions in different HSMS environments".
A new central control file is created if no such file is found when an HSMS session is started. It already contains presettings. These presettings are listed in “HSMS Vol. 2” [1] at the end of the HSMS statement MODIFY-HSMS-PARAMETERS.
During an HSMS session, the global HSMS parameters are modified with the following statement:
//MODIFY-HSMS-PARAMETERS VALID-PERIOD=*PERMANENT,...
The control file of an SM pubset is created during the declaration of the SM pubset with the CREATE-SM-PUBSET-PARAMETERS statement.
A new control file is created for an SM pubset if none is found at the start of an HSMS session or when a pubset is imported. It already contains presettings. These presettings are listed in “HSMS Vol. 2” [1] at the end of the MODIFY-SM-PUBSET-PARAMETERS statement.
The parameters of a specific SM pubset can be changed during an HSMS session with the aid of the MODIFY-SM-PUBSET-PARAMETERS statement.
The central HSMS control file also contains the parameter definitions of the pubsets and workstations managed by HSMS.
When HSMS is started, a check is made to determine whether remote workstations are entered in the control file. As HSMS-SV is normally no longer available in HSMS V9.0B and higher, these workstations are skipped and HSMS startup is continued. The remote workstations are not deleted from the control file.
Request file
The requests generated by HSMS as a result of action statements or DMS access to migrated files are all entered in the request file of the SF or SM pubset environment for which they were issued.
The central request file (requests for an SF environment) is created under the SYSHSMS user ID and under the default catalog ID. The name of the request file is:
HSM.2.REQUEST.FILE
In an SM pubset environment, a request file is created for each SM pubset under the SYSHSMS user ID and under the catalog ID of that SM pubset. The name of the request file for an SM pubset is:
HSM.2.SM.REQUEST.FILE
Request files created with earlier HSMS versions are not compatible. The central request file is checked when an HSMS session is started. If an incompatible request file is detected, the start is aborted. For details on the compatibility of request files, see section "Compatibility of HSMS definitions in different HSMS environments".
The request files for SM pubsets are checked at the start of an HSMS session (for the accessible environments) or for import processing. If an incompatible request file is detected, the start of that specific environment fails.
If a task detects that no request file is present, a new request file is automatically created. It is created empty as an ISAM (old) file with USER-ACCESS=*OWNER-ONLY without password protection.
This file is interrogated for the (re)start of asynchronous requests. Request management is handled by means of the HSMS statements SHOW-REQUESTS, RESTART-REQUESTS and DELETE-REQUESTS.
Files used in action statement processing
The result file with the name:
HSM.A.<user-id><date><time>.RESULT
contains the result of the ARCHIVE run initiated for the processing of an HSMS action statement. For data transfer, the result file is created under the caller’s user ID; otherwise it is created under the SYSHSMS user ID and the default catalog ID of the environment to which the request refers (default catalog ID or SM pubset ID).
The result file is created as an ISAM file with USER-ACCESS=*OWNER-ONLY without password protection. The <user-id> in the file name is the ID of the user who issued the request.
The disk storage space required for the result file depends on the number of objects processed as one record per object is written to the result file.
ARCHIVE needs the result file in order to restart using the RESTART-REQUESTS statement. It is deleted after normal termination or when a DELETE-REQUESTS statement is issued.
For requests in an SF environment, the result file with the following name is created for requests for a shared pubset imported in slave mode which are processed on the master:
HSM.A.<user-id><date><time>.<sysid>.RESULT
<sysid> the system ID of the system issuing the request in the shared public volume sets.
For requests in an SM environment, a result file with the following name is created in the SM pubset:
HSM.A.<user-id><date><time>.<rq-name>.RESULT
<rq-name> is the request name that was allocated by the user. Since the request name may only be up to 8 characters long, the suffix “RESULT” can be abbreviated so that the file name length complies with the DMS conventions. Only the first three characters of the suffix “RESULT” are guaranteed.
The report file with the name
HSM.B.<user-id><date><time>.REPORT
contains, among other things, the result of the evaluation of the ARCHIVE result file by HSMS. Just like the result file, it is created under the SYSHSMS user ID and under the catalog ID of the environment to which the request refers (default catalog ID or
SM pubset ID).
The report file is created as non-shareable without password protection. The report file is deleted after creation of the print file.
The disk storage space required for the report file depends on the number of objects processed as one record per object is written to the report file.
In an SF environment, a report file with the following name is created on the shared pubset (or on one of the shared pubsets) for requests for a shared pubset imported in slave mode which are processed on the master:
HSM.B.<user-id><date><time>.<sysid>.REPORT
<sysid> the system ID of the system issuing the request in the shared public volume sets.
For requests in an SM environment, a report file with the following name is created in the SM pubset:
HSM.A.<user-id><date><time>.<rq-name>.REPORT
<rq-name> is the request name that was allocated by the user. Since the request name may only be up to 8 characters long, the suffix “REPORT” can be abbreviated so that the file name length complies with the DMS conventions. Only the first three characters of the suffix “REPORT” are guaranteed.
The print file with the name
HSM.C.<user-id><date><time>.PRINT
contains the edited result of evaluation of the report file for those users for whom output of the report on the printer has been defined. It is created under the caller’s user ID (or, for requests from the HSMS administrator, under SYSHSMS) and deleted after printing.
For requests in an SM environment, a print file with the following name is created in the SM pubset:
HSM.A.<user-id><date><time>.<rq-name>.PRINT
<rq-name> is the request name that was allocated by the user. Since the request name may only be up to 8 characters long, the suffix “PRINT” can be abbreviated so that the file name length complies with the DMS conventions. Only the first three characters of the suffix “PRINT” are guaranteed.
Files used for directory modification
The result file with the name
HSM.E.<user-id><date><time>.RESULT
contains the result of the ARCHIVE run initiated for the modification of the archive directory. The result file is created under the caller’s user ID (or, for requests from the HSMS administrator, under SYSHSMS). The result file is deleted after evaluation by HSMS for the generation of a report file.
The report file with the name
HSM.F.<user-id><date><time>.REPORT
contains the result of the evaluation of the ARCHIVE result file by HSMS. Just like the result file, it is created under the caller’s user ID (or, for requests from the HSMS administrator, under SYSHSMS).
The report file is deleted after editing and output to the system file SYSLST.
The disk storage space required for the report file depends on the number of objects processed as one record per object is written to the report file.
Temporary files
When a migrated file is recalled, a scratch file with the name
HSM.D.<user-id><date><time>.<version><cfid>
is created temporarily under the SYSHSMS user ID and is then deleted after processing.
When the HSMS statement RESTORE-LIBRARY-ELEMENTS is processed, a temporary file with the name
HSM.P.<user-id><date><time>.PLAM
is created temporarily under the SYSHSMS user ID and is then deleted after processing.
For log file creation for the BS2000 backup monitor, a temporary file with the following name might be created:
$SYSHSMS.HSM.C.SYSHSMS.<date_time>
This temporary file is only created if the following criteria are met:
Expansion of the user log was necessary (user log is written into the existing file)
Subsystem CONV2PDF is not available or an error occurred (see also section "Central request monitoring on the SE server")
This file is deleted, once the $SYSHSMS.HSM.C.SYSHSMS.<date_time>.PDF PDF log file has been created.
Work files for backup using the Concurrent Copy function
By default, two temporary work files with the following names are created during backup using the Concurrent Copy function:
S.DCH.<sysid>.<CC.session-id>.DATA
S.DCH.<sysid>.<CC.session-id>.META
If a name was defined with the WORK-FILE-NAME operand of the HSMS statement BACKUP-FILES, only a work file which is assigned the specified name is created.
ARCHIVE.ASN file for serialization of parallel runs
A new work file with the name $TSOS.ARCHIVE.ASN file is introduced from HSMS V12.0A02.
The ARCHIVE.ASN file guarantees a unique SFID for the save files created on shared S1 storage level or shared SF public disk by several HSMS save tasks running simultaneously in SF environments on different systems.
The ARCHIVE.ASN is created under the userid TSOS on the corresponding output shared SF or S1-SM pubset during the first HSMS save run. The work file stores the last generated ARCHIVE Sequence Number (ASN) from the last save run on the shared pubset.
The ARCHIVE.ASN file is created with a read password and the system administrators can delete it (DELETE-FILE ..., IGNORE-PROTECTION=*READ-PASSWORD), in case the pubset is no longer used for storing save files.