1.7.2 Notes on planned termination, forced termination, and abnormal termination

The points discussed below must be taken into consideration when HiRDB planned termination, forced termination, or abnormal termination has occurred.

Organization of this subsection
(1) The HiRDB version must not be changed
(2) Only part of the HiRDB system definition can be modified
(3) The server configuration cannot be modified (applicable to HiRDB/Parallel Server only)
(4) Addition, deletion, and modification of global buffers
(5) Global buffer allocated to an RDAREA that was added during HiRDB operation
(6) Status files cannot be deleted, modified, or initialized
(7) Synchronization point dump files cannot be added, deleted, modified, or initialized
(8) System log files cannot be deleted or modified
(9) Swapping the current system log files
(10) Input error in the system log file during restart
(11) Notes on restart after planned termination
(12) Forced termination may result in abnormal termination of unit

(1) The HiRDB version must not be changed

The HiRDB version must not be changed when planned termination, forced termination, or abnormal termination of HiRDB has occurred. If the version is changed, HiRDB restart will fail. HiRDB must be terminated normally before the HiRDB version can be changed.

(2) Only part of the HiRDB system definition can be modified

When planned termination, forced termination, or abnormal termination of HiRDB has occurred, some of the HiRDB system definition operands cannot be modified. For details on the operands that cannot be modified, see the manual HiRDB Version 8 System Definition.

HiRDB/Parallel Server
If any unit terminates abnormally during a normal or planned termination, the HiRDB system definitions should not be modified before the next startup. If they are modified, HiRDB startup will probably fail; even if HiRDB startup is successful, HiRDB will not operate normally.

(3) The server configuration cannot be modified (applicable to HiRDB/Parallel Server only)

The HiRDB server configuration should not be modified when planned termination, forced termination, or abnormal termination of HiRDB has occurred. The pdstart and pdunit operands cannot be modified in the system common definition before the restart. If they are modified, HiRDB restart will fail.

HiRDB must be terminated normally before the HiRDB server configuration can be modified. In such a case, the following files must be reinitialized (otherwise, HiRDB startup may fail):

(4) Addition, deletion, and modification of global buffers

When HiRDB is terminated forcibly or abnormally, the types of global buffer manipulation listed in Table 1-9 are not available.

Table 1-9 Unavailable global buffer manipulations when HiRDB is terminated forcibly or abnormally

Global buffer manipulationNormal or planned terminationForced or abnormal termination
Addition of global buffer
(addition of pdbuffer operand)
YNA
Deletion of global buffer
(deletion of pdbuffer operand)
YNA
Modification of global buffer
(modification of pdbuffer operand)
YNA

Y: Available

[NA]: Not available

(5) Global buffer allocated to an RDAREA that was added during HiRDB operation

In the case of a global buffer allocated to an RDAREA that was added during HiRDB operation, whether or not it is inherited at the next startup is determined by the termination mode, as shown in Table 1-10.

Table 1-10 Inheritance of global buffer allocated to RDAREA that was added during HiRDB operation

ConditionNormal or planned terminationForced or abnormal termination
Whether or not global buffer allocated to a RDAREA that was added during HiRDB operation is inherited.Not inheritedInherited

(6) Status files cannot be deleted, modified, or initialized

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of status file manipulations listed in Table 1-11 are not available.

Table 1-11 Unavailable status file manipulations in the event of planned, forced, or abnormal termination

Status file manipulationNormal terminationPlanned, forced, or abnormal termination
Addition of status fileYY
Deletion of status fileYNA
Modification of status fileYNA
Initialization of status fileYNA

Y: Available

[NA]: Not available (if executed, restart fails)

After planned, forced, or abnormal termination
The following operands can be added:
  • pd_syssts_file_name_1 to pd_syssts_file_name_7
  • pd_sts_file_name_1 to pd_sts_file_name_7
These operands cannot be deleted or modified. If deleted or modified, restart of the corresponding unit fails.

(7) Synchronization point dump files cannot be added, deleted, modified, or initialized

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of synchronization point dump file manipulations listed in Table 1-12 are not available.

Table 1-12 Unavailable synchronization point dump file manipulations in the event of planned, forced, or abnormal termination

Synchronization point dump file manipulationNormal terminationPlanned, forced, or abnormal termination
Addition of synchronization point dump fileYNA
Deletion of synchronization point dump fileYNA
Modification of synchronization point dump fileYNA
Initialization of synchronization point dump fileYNA

Y: Available

NA: Not available (if executed, restart fails)

After planned, forced, or abnormal termination
The following operands cannot be added, deleted, or modified:
  • pdlogadfg -d spd
  • pdlogadpf -d spd
If these operands are added, deleted, or modified by mistake, restart of the corresponding unit fails.
A synchronization point dump file that was added during the previous HiRDB session will be inherited after a HiRDB restart.

(8) System log files cannot be deleted or modified

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of system log file manipulations listed in Table 1-13 are not available.

Table 1-13 Unavailable system log file manipulations in the event of planned, forced, or abnormal termination

System log file manipulationNormal terminationPlanned, forced, or abnormal termination
Addition of system log fileYY
Deletion of system log fileYNA
Modification of system log fileYNA
Initialization of system log fileYY*

Y: Available.

NA: Not available (if executed, restart fails)

* The system log files listed below must not be initialized; if they are initialized by mistake, restart of the corresponding unit fails (or, in the event restart is successful, the database contents will be corrupted):

After planned, forced, or abnormal termination
The following operands can be added:
  • pdlogadfg -d sys
  • pdlogadpf -d sys
These operands cannot be deleted or modified; if they are deleted or modified, restart of the corresponding unit fails.

(9) Swapping the current system log files

Whether or not swapping of the current system log file occurs during a HiRDB restart depends on the specification of the pd_log_rerun_swap operand, as shown in Table 1-14.

Table 1-14 Current system log file swapping conditions

Specification of pd_log_rerun_swap operandNormal or planned terminationForced or abnormal termination
pd_log_rerun_swap=YYY
pd_log_rerun_swap=NYNA
pd_log_rerun_swap operand omittedYNA

Y: System log file swapping is performed when HiRDB is restarted. The current file in effect during the previous termination is swapped out, and a new current file is allocated.

NA: System log file swapping is not performed when HiRDB is restarted. The current file in effect during the previous termination is retained as the current file. However, the current system log file is swapped out at the HiRDB restart in the following cases:

(10) Input error in the system log file during restart

At a HiRDB restart, HiRDB uses the last synchronization point validated during the previous session as the system log input start point. It recovers the database and transactions by reading sequentially all applicable system log files. If at least one system log file was lost due to an error (if dual system log files are used and both versions A and B were lost), restart fails; or, even if restart is successful, the database becomes invalid.

If unload log files have been acquired for those lost system log files, the database can be recovered by the database recovery utility using the backup copy and the unload log files.

If no unload log file is available, system log information cannot be used for database recovery. In such a case, either the database must be restored to the point where the last backup was made and then the same applications must be re-executed, or the database must be re-created.

(11) Notes on restart after planned termination

At a HiRDB restart, HiRDB uses the last synchronization point validated during the previous session as the system log input start point. If an error occurs in the last valid synchronization point dump file or status file, the system log input start point may be moved farther back in time to another valid synchronization point. Figure 1-1 shows an example of moving back the system log input start point.

Figure 1-1 Example of moving back the system log input point

[Figure]

Explanation
If planned termination is executed between the system log input start point determined in this manner and the latest system log file, the following must be noted.
  • If a HiRDB system definition is modified after a planned termination and prior to restart, the restart will fail. In such a case, restart will fail even if the HiRDB system definitions are restored later to their status before the planned termination.
In such a case, normal startup of the unit must be executed forcibly, and then the database recovery utility (pdrstr) must be executed to recover the database from its backup copy and unload log files.

(12) Forced termination may result in abnormal termination of unit

If HiRDB is terminated forcibly (by the pdstop -f command), a HiRDB unit may terminate abnormally with abort code Polkcrt. This is because a process in critical status was terminated during forced termination processing. However, this event can be ignored, because it does not cause any operational problems. Even a process in critical status terminates immediately during forced termination processing, resulting in this event. However, such a process is restarted the next time the pdstart command is entered (the database is recovered from the system log).