It was explained in 13.13.1 Examples (in the case of boundary value specification), 13.13.2 Examples (in the case of storage condition specification), and 13.13.3 Examples (matrix partitioning) that data that has been unloaded is loaded by executing the database load utility (pdload) for each RDAREA after a split operation and registration. This operation allows parallel execution of the database load utility (pdload) on multiple RDAREAs for data loading, thereby minimizing the impact of job stoppage. This operation also provides an advantage, in that the lock set during execution of the database load utility (pdload) is limited to the RDAREAs into which the data is to be loaded, and jobs that access other RDAREAs are not affected.

However, there are also disadvantages. Because the user must determine accurately the RDAREAs into which data is to be re-registered, the operation is prone to mistakes. Also, the database load utility (pdload) must be executed multiple times when it is necessary to register data into multiple RDAREAs.

For this reason, if it is possible to allocate sufficient job stoppage time and to halt access to the tables that are to be split or combined for the duration of the stoppage, we recommend that you load data with the database load utility (pdload) on a table-by-table basis, and not on an RDAREA-by-RDAREA basis.