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.

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 9 System Definition.

HiRDB parallel server configuration

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

Do not modify the HiRDB server configuration 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 might fail):

• All system log files
• All synchronization point dump files
• All unit status files
• All server status files

When HiRDB is terminated forcibly or abnormally, the types of global buffer manipulation listed in the following table are not available.

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

Global buffer manipulation	Normal or planned termination	Forced or abnormal termination
Addition of global buffer (addition of pdbuffer operand)	Y	NA
Deletion of global buffer (deletion of pdbuffer operand)	Y	NA
Modification of global buffer (modification of pdbuffer operand)	Y	NA

Y: Available

NA: Not available

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

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

Condition	Normal or planned termination	Forced or abnormal termination
Whether global buffer allocated to a RDAREA that was added during HiRDB operation is inherited.	Not inherited	Inherited

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of status file manipulation listed in the following table are not available.

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

Status file manipulation	Normal termination	Planned, forced, or abnormal termination
Addition of status file	Y	Y
Deletion of status file	Y	NA
Modification of status file	Y	NA
Initialization of status file	Y	NA

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.

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of synchronization point dump file manipulation listed in the following table 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 manipulation	Normal termination	Planned, forced, or abnormal termination
Addition of synchronization point dump file	Y	NA
Deletion of synchronization point dump file	Y	NA
Modification of synchronization point dump file	Y	NA
Initialization of synchronization point dump file	Y	NA

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.

When planned termination, forced termination, or abnormal termination of HiRDB occurs, the types of system log file manipulation listed in the following table are not available.

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

System log file manipulation	Normal termination	Planned, forced, or abnormal termination
Addition of system log file	Y	Y
Deletion of system log file	Y	NA
Modification of system log file	Y	NA
Initialization of system log file	Y	Y#

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):

• The last system log file used during the previous HiRDB session
• Any system log file that is overwrite disabled

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.

Whether 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 the following table.

Table 1-14 Current system log file swapping conditions

Specification of pd_log_rerun_swap operand	Normal or planned termination	Forced or abnormal termination
pd_log_rerun_swap=Y	Y	Y
pd_log_rerun_swap=N	Y	NA
pd_log_rerun_swap operand omitted	Y	NA

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:

• An error occurred in the current file in effect during the previous termination
• Unload was executed during HiRDB termination (pdlogunld or pdlogchg command was executed)

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.

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 might be moved farther back in time to another valid synchronization point. The following figure shows an example of moving back the system log input start point.

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

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.

If HiRDB is terminated forcibly (by the pdstop -f command), a HiRDB unit might 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. However, such a process is restarted the next time the pdstart command is entered (the database is recovered from the system log).