Online reorder of data should not write gigabytes on p-log

Stop or make optional the writing of records moved by online reorder to the protection log. do this to reduce the critical recovery time (restore and regenerate).

When you do an online reorder of an Adabas file in a given descriptor sequence the records of the file are moved between data storage blocks. The moved records are written in the protection area of WORK (ADARUN LP parameter) and on the protection log - first the compressed record with its old data storage RABN and then the compressed record againwith its new data storage RABN.
For autorestart (after nucleus crash) this information is undeniably needed to repair the database - so it must be in the WORK protection area.

But its presence in the protection log is less obvious.
The protection log keeps this so that the regenerate utility can re-do the moves that the original nucleus did. This is important because the updates to the records have data storage RABN pointers - and ifa record was not moved by regenerate as it wasin the original session any update to the record that happened after it was moved would contain a wrong RABN.

The regenerate utility is able to be restarted - meaning you can run it again and again with the same protection log without having to restore the database. This is to avoid costly extra down time during database recovery if one of your regenerate jobs for some reason did not complete successfully. This then means the regenerate is able to handle the situation that the RABN is wrong - if the record is not found in the p-log record DSRABN the nucleus servicing the regenerate will try to find the recordusing its ISN and the address converter.

The size of the protection log increases tremendously by online reorder of data. If you reorder a file that has 2Gb of data storage records overnight the protection log of that night will be 4Gb bigger than usual.

All this said - my suggestion is to either stop or make optional the writing of reorder records to the protection log for the following reasons:
- The online reorder causes a tremendous increase in the size of the protection log - making the critical recovery process very much longer.The critical recovery process is nota goodtime to do low-priority tasks like re-doing the reordering.
- The extra I/Os caused by wrong DSRABN in the update records of the protection log during regenerateis of much less significance than the extratime needed tore-do the reordering.