Migrating an existing database to a new, encrypted one necessitates some downtime of Adabas while new copies of the database container datasets are created or brought up to date. Simple migration methods cause downtime proportional to the size of the database, which can be substantial. More complex migration methods shorten the downtime, making it proportional to the amount of update processing in the database during the migration. This section describes four methods, in the order of decreasing downtime and increasing complexity.
Method 1 is the simplest: you shut down Adabas, save the database and restore it into the new, encrypted container datasets. This is a good approach for databases that are small or that can be taken offline at the right moment for the duration it takes to save and restore them.
To perform Method 1, follow these steps:
Run ADAFRM ASSOFRM, DATAFRM and so on, specifying the database container datasets with new (temporary) names, DISP=(NEW,CATLG) and the encryption key label (DSKEYLBL parameter). Alternatively, the key label can be derived from the RACF profile or the SMS policy for each dataset.
Shut down Adabas on the existing database and wait for the final ADARES PLCOPY job to finish.
Run ADASAV SAVE to save the database (offline).
Run ADASAV RESTORE to restore the saved database into the new, encrypted container datasets.
Delete (or rename) the old database container datasets and rename the new container datasets to the old names.
Restart Adabas on the new, encrypted database with the original dataset names.
See sample job MIG030 in the AEZvrs.JOBS library.
With this method, Adabas is down between steps 2 and 6. The main contributors to the downtime are:
Step 2 – ADARES PLCOPY
Step 3 – ADASAV SAVE (database)
Step 4 – ADASAV RESTORE (database)
The preceding section described Method 1, which takes the database down while it is being saved and restored. This section describes Method 2, which reduces the duration of downtime by performing the save online, while Adabas stays active.
Method 2 creates the new instance of the database while the old one is still active. One way to keep them apart is to continue using the regular Adabas SVC for the database in the old container datasets and to use another, temporary SVC for the database in the new datasets while they are brought up to date.
Note:
Method 2 becomes more complicated if the database gets updated by
utilities (ADAINV, ADALOD, ADAORD, ADARES BACKOUT/REGENERATE, ADASAV
RESTORE/RESTONL) after the online database save operation at the start of the
migration procedure.
To perform Method 2, follow these steps:
Run ADAFRM ASSOFRM, DATAFRM and so on, specifying the database container datasets with new (temporary) names, DISP=(NEW,CATLG) and the encryption key label (DSKEYLBL parameter). Alternatively, the key label can be derived from the RACF profile or the SMS policy for each dataset.
Run ADASAV SAVE to save the database (online).
Shut down Adabas on the existing database and wait for the final ADARES PLCOPY job to finish.
Run ADASAV RESTONL to restore the saved database into the new, encrypted container datasets.
Provide the sequential PLOG dataset written by the PLCOPY execution triggered in step 3. If a PLOG switch occurred during the online save in step 2, provide to the restore operation all sequential PLOG datasets spanning the online save (from the SYN1 to the SYN2 checkpoint).
Run ADARES REGENERATE on the new datasets to regenerate the last updates to the database from the end of the online save until its shutdown (between steps 2 and 3).
Provide the sequential PLOG (or PLOGs) from the SYN2 checkpoint till the session end. There should be only a few updates, so it may be simplest to run this REGENERATE with MODE=SINGLE.
Run ADADBS RESETPPT to reset the PPT of the database in the new datasets before they are renamed. This step is optional. It prevents a warning message in step 8 when Adabas restarts on the renamed datasets.
Delete (or rename) the old database container datasets and rename the new container datasets to the old names.
Restart Adabas on the new, encrypted database with the original dataset names.
See sample job MIG040 in the AEZvrs.JOBS library.
With this method, Adabas is down between steps 3 and 8. The main contributors to the downtime are:
Step 3 – ADARES PLCOPY
Step 4 – ADASAV RESTONL (database)
With Method 1 and Method 2 (described in the preceding sections), the downtime of the database is proportional to its size.
Method 3 (described in this section) reduces the downtime with additional steps for regenerating updates, such that the duration of the downtime becomes proportional to the amount of update processing during the migration process.
Method 3 creates the new instance of the database while the old one is still active. One way to keep them apart is to continue using the regular Adabas SVC for the database in the old container datasets and to use another, temporary SVC for the database in the new datasets while they are brought up to date.
Note:
Method 3 becomes more complicated if the database gets updated by
utilities (ADAINV, ADALOD, ADAORD, ADARES BACKOUT/REGENERATE, ADASAV
RESTORE/RESTONL) after the online database save operation at the start of the
migration procedure.
To perform Method 3, follow these steps:
Run ADAFRM ASSOFRM, DATAFRM and so on, specifying the database container datasets with new (temporary) names, DISP=(NEW,CATLG) and the encryption key label (DSKEYLBL parameter).
Alternatively, the key label can be derived from the RACF profile or the SMS policy for each dataset.
Run ADASAV SAVE to save the database (online).
Run ADADBS OPERCOM FEOFPL to force a PLOG switch.
Wait for the associated ADARES PLCOPY job to finish.
Run ADASAV RESTONL to restore the saved database into the new, encrypted container datasets.
Provide the sequential PLOG dataset written by the PLCOPY execution triggered in step 3. If a PLOG switch occurred during the online save in step 2, provide to the restore operation all sequential PLOG datasets spanning the online save (from the SYN1 to the SYN2 checkpoint).
Start a second Adabas nucleus on the new database container datasets (using another, temporary Adabas SVC).
This nucleus will be used only temporarily and does not need PLOGs. It may be set to UTIONLY=YES.
Shut down Adabas on the existing database container datasets and wait for the final ADARES PLCOPY job to finish.
Run ADARES REGENERATE against the nucleus on the new database container datasets to regenerate the updates to the database from the end of the online save until its shutdown (between steps 2 and 6).
Shut down the second Adabas nucleus on the new database container datasets.
Run ADADBS RESETPPT to reset the PPT of the database in the new datasets before they are renamed.
This step is optional. It prevents a warning message in step 11 when Adabas restarts on the renamed datasets.
Delete (or rename) the old database container datasets and rename the new container datasets to the old names.
Restart Adabas on the new, encrypted database with the original dataset names.
See sample job MIG050 in the AEZvrs.JOBS library.
With this method, Adabas is down between steps 6 and 11. The main contributors to the downtime are:
Step 6 – ADARES PLCOPY
Step 7 – ADARES REGENERATE (database) for all updates between steps 3 and 6, which includes the time needed for the ADASAV RESTONL (database)
With Method 3 (described in the previous section), the database is down while all the updates made after the end of the online save are regenerated. Method 4 (described in this section) can reduce this downtime further by keeping the database active while the updates made during the database restore operation are being regenerated. Thereafter, the database is shut down to regenerate the final updates from the end of the database restore.
Method 4 creates the new instance of the database while the old one is still active. One way to keep them apart is to continue using the regular Adabas SVC for the database in the old container datasets and to use another, temporary SVC for the database in the new datasets while they are brought up to date.
Note:
Method 4 becomes more complicated if the database gets updated by
utilities (ADAINV, ADALOD, ADAORD, ADARES BACKOUT/REGENERATE, ADASAV
RESTORE/RESTONL) after the online database save operation at the start of the
migration procedure.
To perform Method 4, follow these steps:
Run ADAFRM ASSOFRM, DATAFRM and so on, specifying the database container datasets with new (temporary) names, DISP=(NEW,CATLG) and the encryption key label (DSKEYLBL parameter).
Alternatively, the key label can be derived from the RACF profile or the SMS policy for each dataset.
Run ADASAV SAVE to save the database (online).
Run ADADBS OPERCOM FEOFPL to force a PLOG switch.
Wait for the associated ADARES PLCOPY job to finish.
Run ADASAV RESTONL to restore the saved database into the new, encrypted container datasets.
Provide the sequential PLOG dataset written by the PLCOPY execution triggered in step 3. If a PLOG switch occurred during the online save in step 2, provide to the restore operation all sequential PLOG datasets spanning the online save (from the SYN1 to the SYN2 checkpoint).
Start a second Adabas nucleus on the new database container datasets (using another, temporary Adabas SVC).
This nucleus will be used only temporarily and does not need PLOGs. It may be set to UTIONLY=YES.
Run ADADBS OPERCOM FEOFPL to force another PLOG switch.
Wait for the associated ADARES PLCOPY job to finish.
Run ADARES REGENERATE with NOAUTOBACKOUT against the nucleus on the new database container datasets to regenerate the updates to the database from the end of the online save until the second PLOG switch (between steps 2 and 6).
Provide all sequential PLOG datasets from the one containing the SYN2 checkpoint (end of step 2) to the last one created so far (in step 6).
Shut down Adabas on the existing database container datasets and wait for the final ADARES PLCOPY job to finish.
Run ADARES REGENERATE (without NOAUTOBACKOUT!) against the nucleus on the new database container datasets to regenerate the updates to the database from the end of the PLOG switch forced in step 6 until its shutdown (i.e., between steps 6 and 8).
Provide the sequential PLOG dataset(s) following the last PLOG in the previous REGENERATE (in step 7).
Shut down the second Adabas nucleus on the new database container datasets.
Run ADADBS RESETPPT to reset the PPT of the database in the new datasets before they are renamed.
This step is optional. It prevents a warning message in step 13 when Adabas restarts on the renamed datasets.
Delete (or rename) the old database container datasets and rename the new container datasets to the old names.
Restart Adabas on the new, encrypted database with the original dataset names.
See sample job MIG060 in the AEZvrs.JOBS library.
With this method, Adabas is down between steps 8 and 13. The main contributors to the downtime are:
Step 8 – ADARES PLCOPY
Step 9 – ADARES REGENERATE (database) for all updates between steps 6 and 8, which includes only the time needed for the first REGENERATE (database)
If the final ADARES REGENERATE (in step 9) still keeps Adabas down longer than desired, it is possible to repeat steps 6 and 7 (FEOFPL and REGENERATE) until the duration of the final REGENERATE after the shutdown of Adabas is short enough.