You use the online DML RELOCATE to relocate data records and tables specifically within a realm during live operation. As far as possible, relocation takes place to free space at the beginning of the realm. Free space on pages which are not completely full is also utilized. As a result of relocation free space occurs in the back area of the realm. A RELOCATE DML always refers to a user realm which, like the corresponding DBTT realms, too, must be attached in update mode in the DBH.
Depending on the variant of RELOCATE, records and tables are relocated which contain pages which are not completely filled or whole data pages containing parts of multipage tables.
The following are not relocated:
Completely filled pages if they contain FPA entries or DBTT entries
DBTT anchor pages
CALC pages
Anchor records of SYSTEM sets (anchor records contain information which is comparable to DBTT pages).
Relocation procedure
Relocation is implemented as follows:
A suitable data page is searched for from the end of the realm. For the records and tables of such a page or for the whole page free space into which the records and tables can be relocated individually is searched for from the beginning of the realm.
Clustered data which is flagged with corresponding SSL declarations is, as far as possible, also stored again on one and the same page (retention of clusters).
If pages of a distributable list are to be relocated to another realm, the free pages required are searched for in the target realm (TARGET-REALM).
You specify the number of pages which are as far as possible to be emptied by relocation using a RELOCATE DML by means of the statements of the UDS online utility (PAGES-PER-DML parameter of the SDF statement SET-RELOCATE-PARAMETERS, see section “Defining the properties of a RELOCATE DML (SET-RELOCATE-PARAMETERS)”).
If conflicts with other transactions occur when the relocation takes place, you must reckon on the RELOCATE DML aborting prematurely in order to reduce the hindrance for parallel application to a minimum. Relocations which have already been executed in the transaction are generally retained in the new status.
Relocation progress data
In each session section the DBH maintains internal progress data concerning the pages at the end of the source realm which have already been emptied by means of relocation (source level) and concerning the pages which have already been filled at the beginning of the target realm (target level), thus enabling relocation to be continued in multiple consecutive online utility runs without any great effort.
The source and target levels are provided as variables (variable RELOC_ORIGIN for source level and variable RELOC_DESTINATION for target level) in order to inform the UDS online utility and contain the block numbers of the relevant database pages at which there will be continued in the event of further relocations.
Initializing the source and target levels
In general the first relocation transaction of a sequence of relocation transactions results in the initialization of the source level on the last page which is not empty at the end of the realm and of the target level on the first page at the beginning of the realm - in other words initially ACTKEY0. After a successful RELOCATE DML has been processed, the position is set to the pages on which a subsequent RELOCATE DML continues its work. These values are provided as the source and target levels in the UDS online utility.
The progress data for a relocation is not stored in the database for later session sections. It is lost when the realm concerned is detached. After the realm has been attached, progress data from previous session sections is therefore no longer available. The next relocation transaction can only be performed if the source and target levels are reinitialized.
After the UDS online utility has been restarted, it is possible to continue a relocation specifically in a session section which has not been interrupted. In this case you use the INITIALIZE parameter of the SDF statement SET-RELOCATE-PARAMETERS to control initialization of the source and target levels:
INITIALIZE=* ANY
As the UDS online utility may not have recognized that the progress data has been lost, INITIALIZE=* ANY enables the relocation transaction to be executed in such a manner that any progress data which still exists can still be used, otherwise initialization takes place.INITIALIZE=*NO
INITIALIZE=*NO enables initialization to be explicitly prevented if the realm was detached and then re-attached after the last relocation transaction. It cannot be excluded that changes which mean that it no longer makes sense to continue relocation were made to the realm between the times when it was detached and then re-attached.INITIALIZE=*YES
It is, however, also possible to use INITIALIZE=*YES to start initialization of the relocation again. In this case the levels are initialized as described above. This initialization becomes effective in the first corresponding transaction. All subsequent transactions of a UDS online utility are executed with INITIALIZE=*ANY. Whether these transactions are executed in one or more consecutive procedure sequences (SDF statement REPEAT-PROCEDURE) is irrelevant.
Initialization of source and target levels also implicitly leads to the DML FPASCAN being executed with *REUSE. But it does no harm to call FPASCAN explicitly. The DML FPASCAN places the page from which the records and tables which are to be stored will be searched for at the beginning of the realm or on the target level so that parallel storage operations caused by the application program through the DMLs MODIFY and STORE are not stored behind the source level of the relocation. A description of FPASCAN is provided in the section “DML FPASCAN - Defining the search mode for the free place search”.
End of relocation
A sequence of relocation transactions where the source realm is identical to the target realm is ended internally when the source level is lower than the target level. This is reported to the UDS online utility and results in no further relocation transactions being executed in this realm as these have nothing more to do and repeatedly report the same information on the source and target levels.
Filling level to which pages are to be relocated
When relocation takes place, whether the data contained on the page can be relocated can generally only be decided after the data page has been read. The SKIP-ABOVE-FILLING parameter of the SDF statement SET-RELOCATE-PARAMETERS enables you to exclude pages which exceed a particular percentage filling level from relocation (see section “Defining the properties of a RELOCATE DML (SET-RELOCATE-PARAMETERS)”). The default value 100 includes all relocatable pages. A lower value allows you, for instance, to restrict relocation to pages which are not very full. The DBH also uses a specification of under 100 to exclude pages from relocation on the basis of the free place administration data. This optimization consequently enables you to prevent unnecessary reading of data pages.
Behavior in the event of locked source pages
The CLASH-HANDLING parameter of the SDF statement SET-RELOCATE-PARAMETERS permits you to control how the DBH should behave when it encounters a locked source page (see section “Defining the properties of a RELOCATE DML (SET- RELOCATE-PARAMETERS)”). With the default value BREAK-DML the DML is aborted and the relocations which have already taken place are retained. The controller in the UDS online utility can react to this situation and repeat the next relocation request after a particular wait time. However, SKIP-PAGE also provides the option of skipping a locked page. WAIT-FOR-TRANSACTION provides the option to wait until the locked page is released by the locking transaction.