REORG (Parallel BACKUP) › REORG › Parallel Data Reorganization › Restrictions for Parallel Data Load and Parallel Index Update

Restrictions for Parallel Data Load and Parallel Index Update

The following are restrictions for parallel data load and parallel index update:

• This option is available only for a single area in a database at one time (MULTUSE=NO).
• The option is not available for clustered areas.
• The option is not available for areas containing a direct key table.
• The area may not contain variable length records.
• The option is not available for databases where any area in the database is not loaded in the URI format.
• The option is not available for areas without the index loaded or after an index has been initialized.
• The option requires current hardware supporting a full 2G data space (an error message indicates if not available).
• If using the LOADONLY option, we recommend you be extremely cautious in the specification and use of this function. Data rows could be lost if control statements are poorly defined, or due to poor data set handling, because of course it is not possible for CA Datacom/DB to edit the goals you desire to obtain by using the function. CA Datacom/DB can only edit the specific control statements that you provide.
• If using the LOADONLY option, backup format input cannot have been changed since the backup. Extract format input can have deleted rows only, not any additions or key value updates.

  Note: It is not possible to input new data into this utility that is not currently in the loaded index, or to have different key values than those that are in the currently loaded index. These factors cannot be edited.

• The area must be large enough to contain the input data and additional empty space, to allow the number of input files to each have a group of tracks reserved.
• This option is intended for single table areas or multiple table areas when all tables share one single native sequence key ID. However, it performs correctly with multiple tables and any (or all) not sharing a single native sequence key ID.
• The index update presumes a validly loaded index that is pointing to the data as it was at the time of the backup. It does not build an index, nor does it validate that the index matches the data. It can only know, for example, that URI 82 was in block 12 and is now in block 43, meaning that every index entry with URI 82 needs to have its block changed from 12 to 43.
• The internal URI (Unique Row Identifier) is not reassigned during the parallel reorganization. The URI has a maximum size of 4G. Beyond that value, no further additions to the data area are allowed, until the area is backed up and loaded with the standard LOAD function, which reassigns URI numbers starting with one. For large tables with many additions, this means that an occasional full BACKUP/LOAD is required.
• If the format is EXTRACT, then the table must have the native sequence key set to UNIQUE, or the native sequence key must be the same as the Master Key, and the Master Key must be set to allow no duplicate Master Keys. In addition, the rows cannot be defined as having variable lengths.