When HiRDB terminates (including abnormal termination), all lists are deleted, rendering a search using one of the lists impossible. If a list is needed, it must be re-created with the ASSIGN LIST statement.

HiRDB parallel server configuration

1. When a unit terminates, all lists in that unit are deleted.
2. When a server terminates, all lists in that server are deleted.

When the base table of a list is recovered to the most recent synchronization point, that list can be used as is. However, if the base table is not recovered to the most recent synchronization point (for example, if it is recovered to the status when a backup was made), the base table might no longer match the list, and the list must be re-created with the ASSIGN LIST statement.

When an RDAREA storing the base table of a list is re-initialized, you must do one of the following:

• Re-create the list with the ASSIGN LIST statement.
• Delete the list with the DROP LIST statement.

When any of the following processing is performed on the base table of a list, the retrieval results for the list become invalid, and the list must be re-created with the ASSIGN LIST statement:

• Table reorganization
• Data loading into the table in the creation mode
• Execution of the PURGE TABLE statement

The following commands cannot be used for a list or list RDAREA:

• Database load utility
• Database reorganization utility
• Database copy utility
• Database recovery utility
• Database condition analysis utility (only physical analysis of an RDAREA is possible)

To reduce overhead during list creation and deletion, HiRDB maintains list management information in the memory of a dictionary server. Consequently, list management information is lost when the dictionary server or the unit in which the dictionary server is located is terminated. When this occurs, all lists that have been created become invalid and must be re-created with the ASSIGN LIST statement.

Once the dictionary server is restarted and until the transactions that use lists of other users that were being executed before the dictionary server was terminated have been completely recovered, processes that use the lists might cause the KFPA11998-E error message, list operation not completed, to be output.

List information can be checked by executing the pdlistls command. The following information is displayed:

• List name
• List owner
• Name of the list's base table
• Owner of the list's base table
• pd_max_list_users value (maximum number of list owners)
• pd_max_list_count value (maximum number of lists that can be created by one user)

Exercise caution if the RDAREA being accessed is to be changed when a replica RDAREA has been defined for an RDAREA that contains a base table of a list. If the RDAREA being accessed is changed with the current database switch command (pddbchg command) or with the PDDBACCS operand in the client environment definition or UAP environment definition, the search results are invalid except in the following cases:

• The RDAREA being accessed when the list is searched matches the RDAREA that was accessed when the list was created.
• The RDAREA being accessed when the list is searched is duplicated from the data in the RDAREA that was accessed when the list was created.

Use one of the following methods to search such a list:

• Use the RDAREA that was accessed when the list was created.
• Use an RDAREA that is duplicated from the data in the RDAREA that was accessed when the list was created.
• Re-create the list in the current RDAREA being accessed.

For details about the inner replica facility, see the HiRDB Version 9 Staticizer Option Description and User's Guide.

As explained in (1) above, lists are deleted when HiRDB terminates. Deletion (and initialization) processing on these lists is performed during HiRDB startup, which means that the more lists that are created, the longer it takes for HiRDB to start. For this reason, we recommend that you consider changing the time at which lists are initialized in the following cases:

• When you wish to minimize HiRDB startup time
• When you wish to minimize system switchover time (using user server hot standby or the rapid system switchover facility)

The list initialization time can be changed as follows with the pd_list_initialize_timing operand:

• Initialize lists when the ASSIGN LIST statement is executed (DEFER specification).
• Initialize lists when the standby HiRDB is started (STANDBY specification).

(a) Initializing lists when the ASSIGN LIST statement is executed

With this specification, lists are initialized when the ASSIGN LIST statement is executed, rather than when HiRDB starts. This, of course, adds to the initialization overhead when an ASSIGN LIST statement is executed. To minimize the initialization processing overhead, set the list RDAREA size and maximum number of lists so that they are as small as possible. To accommodate creation of a large number of lists, create additional list RDAREAs. This enables you to distribute the initialization processing overhead when the ASSIGN LIST statement is executed.

(b) Initializing lists when the standby HiRDB is started (rapid system switchover facility only)

With this specification, lists are initialized when the standby HiRDB starts. Lists are not initialized when the system is switched over. Lists are not initialized when the ASSIGN LIST statement is executed after the system has been switched over either. Because of this, increase the list RDAREA size and maximum number of lists to reduce the number of list RDAREAs that are created. However, you must first perform the preparatory work explained below.

Preparatory work

You will need lists on both the running system and the standby system. Create them on each of the local disks. You can use either one of the following methods:

Copy the lists created on the running HiRDB to the standby HiRDB

1. Copy all HiRDB file system areas that contain list RDAREAs on the running HiRDB onto the local disk on the standby system.
2. Link so that all HiRDB file names defined in the list RDAREAs point to the HiRDB files system areas that were created in step 1.

Use the re-initialization function of the database structure modification utility (pdmod command)

1. Use the pdstop command to terminate the HiRDB on the running system normally.
2. Use the pdfmkfs command to create HiRDB file system areas for creating list RDAREAs. Create the same number of list RDAREAs with the same settings as those on the running system.
3. Link so that all HiRDB file names defined in the list RDAREAs point to the HiRDB files system areas created in step 2.
4. Use the pdstart command to start the HiRDB on the standby system normally. Because the HiRDB file system areas on the standby HiRDB contain no HiRDB files at this time, the list RDAREAs are opened and placed in error shutdown status.
5. Use the pdmod command to re-initialize all list RDAREAs. When doing so, specify only the names of the RDAREAs that are being initialized.
6. Use the pdrels command to release all list RDAREAs from shutdown status.
7. Use the pdstop command to terminate the standby HiRDB normally.

If you have created separate list RDAREAs on the local disks of the running system and the standby system described in subsection (9)(b), and if you are not performing the re-initialization described in (9), use the following procedure to change the configuration of the RDAREAs:

1. Change the configuration of list RDAREAs on the running system.
2. Use the pdstop command to normally terminate the HiRDB on the running system.
3. Copy all HiRDB file system areas that store the list RDAREAs from the running HiRDB system to the local disk in the standby system.
4. Set links in such a way that all HiRDB file names defined in the list RDAREAs point to the HiRDB file system areas created in step 3.