9.3.3 Designing status files

This section describes the design considerations for status files.

Organization of this subsection
(1) Design considerations
(2) Design for improved reliability
(3) Defining the status files
(4) Single operation of status files
(5) Notes on status file errors (important)

(1) Design considerations

  1. Create the primary and secondary files on separate disks in order to avoid errors on both files.
  2. To prevent abnormal termination of HiRDB as a result of a shortage of status file space, create several spare files whose size is greater than the estimated value. When a status file becomes full, file swapping occurs in order to use a spare file. If the size of the spare file is the same as the full status file, a space shortage also occurs on the spare file, resulting abnormal termination of HiRDB. For example, if you create six sets of status files, we recommend that you make the file size for two of the sets larger than the other sets.
  3. Unit status files are required for each server machine.
  4. Server status files are required for all servers except for the system manager.
  5. Make sure that the primary and secondary files have the same record length and the same number of records.
  6. You can create 1-7 sets of unit status files per unit.
  7. You can create 1-7 sets of server status files per server.

(2) Design for improved reliability

  1. Provide at least three sets of status files (dual files x 3 = 6 files) and place them in such a manner that corruption of all status files by disk errors is unlikely.
  2. To prevent abnormal termination of HiRDB resulting from a space shortage, we recommend that you set the size of a status file to at least 1.2 times the estimated value.
  3. A status file contains information that will be needed in order to restore the system status during HiRDB restart processing. If an error occurs in such a file and no spare file is available, the system status cannot be restored. Therefore, make sure that spare files are always available as a safeguard in the event of errors on the current files.
(a) Recommended configuration

In order to provide a safety margin until a disk becomes operational after it has been recovered from a disk failure, we recommend that you provide six sets of status files on four sets of disks (dual files x 6 = 12 files) and place them as shown in the following figure. If an error occurs on the normal system during single operation, HiRDB cannot be restarted; therefore, we recommend that you do not apply single operation to status files (specify stop in pd_syssts_singleoperation and pd_sts_singleoperation).

The following figure shows an example of placing six sets of status files on four sets of disks.

Figure 9-7 Example of placing six sets of status files on four sets of disks

[Figure]

Explanation:
With this arrangement, if an error occurs on a disk and then another error occurs on another disk, the remaining two disks still contain intact primary and secondary files, and HiRDB can continue operation using the status files on the error-free disks as the current files. For example, if an error occurs on disk A and then an error occurs on disk B, HiRDB continues operation using as the current files the primary and secondary status files on disks C and D (sts-3a and sts-3b). In this status, if another error occurs on one of the current files, HiRDB terminates abnormally; however, because one of the current files is normal, HiRDB can be restarted after one of the disks is recovered from its error.

(3) Defining the status files

The pd_syssts_file_name_1 to pd_syssts_file_name_7 and the pd_sts_file_name_1 to pd_sts_file_name_7 operands are used to define the correspondence between the status files created by the pdstsinit command and the logical files.

The pd_syssts_file_name_1 to pd_syssts_file_name_7 operands are for unit status files, and the pd_sts_file_name_1 to pd_sts_file_name_7 operands are for server status files.

If the names of imaginary logical files or status files are defined in the pd_syssts_file_name_2 to pd_syssts_file_name_7 operands or in the pd_sts_file_name_2 to pd_sts_file_name_7 operands, status files can be added during HiRDB operation. In this case, the following operands must be specified.

Unit status files

pd_syssts_initial_error
pd_syssts_last_active_file

Server status files

pd_sts_initial_error
pd_sts_last_active_file

(4) Single operation of status files

If an error occurs on one of the current files while there is no available spare file, continuing operation using only the normal file (either the primary or secondary file) is called status-file single operation. When status files are placed in the single operation mode, the KFPS01044-I message is displayed.

If an error occurs on the current file in the single operation mode, HiRDB can no longer be restarted. Therefore, status-file single operation is not recommended. Increase the number of status file sets to avoid a situation where no spare file is available.

As opposed to status-file single operation, continuing operation using both status files (normal processing mode) is called status-file double operation.

(a) Advantages and disadvantages of status-file single operation
Advantages
Processing can continue even if an error occurs on one of the current files while no spare file is available. This reduces the adverse consequences of HiRDB shutdown resulting from a status file error.
Disadvantages
If an error occurs on the normal file during single operation or HiRDB terminates abnormally while the status file is updated, the contents of the current file are lost, disabling HiRDB restart.
(b) Specification method

To use unit status-file single operation, specify pd_syssts_singleoperation = continue in the unit control information definition file. To use server status-file single operation, specify pd_sts_singleoperation = continue in the server definition. Make sure that pd_syssts_singleoperation and pd_sts_singleoperation have the same value.

The following are guidelines on when to use status-file single operation.

(c) Notes about using single operation

The following table outlines HiRDB operations and HiRDB administrator actions that depend on whether single operation is used. For details about how to handle status file errors, see the HiRDB Version 9 System Operation Guide.

Table 9-6 HiRDB operation and HiRDB administrator's action that depend on whether single operation is used

ConditionStatus-file single operation
(pd_syssts_singleoperation or pd_sts_singleoperation operand value)
Used (continue specified)Not used (omitted or stop specified)
There are spare filesError occurred in the current fileHiRDB operation:
Swaps status files.
HiRDB administrator's action:
Handle the error in the applicable status file.
Error occurred on both current files simultaneouslyHiRDB operation:
Terminates abnormally. HiRDB cannot be restarted.
HiRDB administrator's action:
See Handling of status file errors in the HiRDB Version 9 System Operation Guide.
There is no spare fileError occurred in one of the current filesHiRDB operation:
Resumes processing using single operation.
HiRDB administrator's action:
Create spare files immediately and return HiRDB to the double operation mode.
HiRDB operation:
Terminates abnormally.
HiRDB administrator's action:
Create spare files, and then restart HiRDB.
Error occurred on both current files simultaneouslyHiRDB operation:
Terminates abnormally. HiRDB cannot be restarted.
HiRDB administrator's action:
See Handling of status file errors in the HiRDB Version 9 System Operation Guide.
Error occurred in the normal file during single operationHiRDB operation:
Terminates abnormally. HiRDB cannot be restarted.
HiRDB administrator's action:
See Handling of status file errors in the HiRDB Version 9 System Operation Guide.
--
Legend:
--: Not applicable

(5) Notes on status file errors (important)