2.44 pdlogchg (Change status of log file)

Organization of this section
(1) Function
(2) Executor
(3) Format
(4) Options
(5) Rules
(6) Notes

(1) Function

The pdlogchg command forcibly places a specified file group in unload completed status or extraction by HiRDB Datareplicator completed status. The status of the current file group cannot be changed.

(2) Executor

HiRDB administrator

(3) Format

(a) HiRDB/Single Server

pdlogchg {-d sys [-s server-name] -g file-group-name [-R]
         |-z log-point-information-filename}

(b) HiRDB/Parallel Server

pdlogchg {-d sys -s server-name [-u unit-identifier] -g file-group-name [-R]
         |-z log-point-information-filename [-x host-name]}

(4) Options

(a) -d sys

Specifies that the status of a system log file is to be changed.

(b) -s server-name ~<identifier> ((1-8))

Specifies the name of the server corresponding to the file group.

(c) -u unit-identifier ~<identifier> ((4 characters))

When the standby-less system switchover (effects distributed) facility is used, specifies the unit identifier of the host that contains the disk on which the system log file whose status is to be changed was created.

When the applicable server and system manager are running, the -u option is ignored, if specified.

Specifying the -u option results in an error if any of the following is true:

The following table describes whether or not the -u option is required:

Server statusHost containing the disk where file is createdSpecification of -u option
ActiveHost containing the running back-end serverOptional
InactiveHost containing the primary back-end server
Other hostMandatory
(d) -g file-group-name ~<identifier> ((1-8))

Specifies the name of the file group whose status is to be changed.

(e) -z log-point-information-filename ~<pathname>

Specifies that the status change is to be applied only to file groups older than the log point recorded in the specified log point information file.

One of the following files must be specified as the log point information file:

(f) -x host-name ~<identifier> ((1-32))

Specifies the name of the host of the server to which the log file group whose status is to be changed belongs.

When this option is omitted, the host where the command is entered is assumed.

(g) -R

Specifies that a file group is to be forcibly changed from extracting status to extraction completed status when HiRDB Datareplicator linkage is being executed. When this option is specified, only the extraction status is changed from extracting to extraction completed.

(5) Rules

  1. The pdlogchg command can be executed under the following conditions:
    • If pd_log_unload_check=N is specified in the system definitions, HiRDB is running, and the file group to be operated upon is open, the command cannot be executed without the -R option.
    • In all other cases, the command can be executed regardless of whether or not HiRDB is running (except when HiRDB is booting or terminating).
  2. The pdlogchg command must be executed at the server machine containing the single server or the server machine where the system manager is located.

(6) Notes

  1. The following are the pdlogchg command's return codes:
    0: Normal termination
    4: Abnormal termination
    8: Abnormal termination (such as an invalid option or rsh error)
    12: Abnormal termination (when retry was executed from a standby system in a configuration in which IP addresses are not inherited)
  2. The pdlogchg command must not be executed during HiRDB startup processing. HiRDB startup processing begins when the KFPS01800-I message is output and ends when the KFPS05210-I message is output. If the command is executed during that time, the system log file may not become effective in HiRDB. To make the system log file effective in such a case, its file group must be closed with the pdlogcls command after HiRDB startup processing is completed, then the file group must be opened with the pdlogopen command.
  3. Because the pdlogchg command references the HiRDB system definition file, it may be impossible to change the file status if the information in the HiRDB system definition file for the active HiRDB that collected the system log does not match the information in the HiRDB system definition file referenced by the pdlogchg command.
  4. Processing may terminate normally even if the pdlogchg command results in an error.
    Whether or not the processing has terminated normally can be determined by checking the termination code (whether or not it is 0) or by checking the status (whether or not the status has changed) with the pdlogls command.
  5. The results of the pdlogchg command can be checked by the following methods:
    • HiRDB is active
      By executing the pdlogls command.
    • HiRDB is inactive
      By checking the return code set by the command, by checking any error messages, or by executing the pdlogls command.
  6. A command execution error will result if the pdlogchg command is executed when HiRDB is not running and HiRDB is started before the execution of the command terminates. If this problem occurs, re-execute the pdlogchg command by checking the HiRDB operation status.
  7. If pd_log_unload_check=N is specified on a server, the command cannot be executed without the -R option if the server has been individually terminated by issuing the pdstop -s command.
  8. If pd_log_rpl_no_standby_file_opr=stop is specified in the system common definition for HiRDB Datareplicator linkage, the -R option is executed in order to forcibly change the status of the file group when data linkage is stopped due to occurrence of an error that satisfies the following three conditions:
    • HiRDB was terminated forcibly because all system log files have been placed in extracting status.
    • The definition cannot be changed for HiRDB operational reasons.
    • An error was generated by the HiRDB Datareplicator and the HiRDB.
    Datareplicator cannot be activated. In such a case, the pdlogchg command with the -R option specified should be executed for all system log files to change the status from extracting to extraction completed. In this case, data may not be applicable to the target database, resulting in inconsistency between the extracted and target databases because some of the update information for the extracted database is lost. To avoid this, you need to re-create the target database before restarting the data linkage. For details about re-creating a database, see the HiRDB Datareplicator Version 8 Description, User's Guide and Operator's Guide.