Fast/Reload differences with FLOD/FILELOAD
In general, every effort was made to maintain compatibility between Fast/Reload and standard Model 204 FLOD and FILELOAD. In some specific instances, however, it was determined that compatibility was undesirable. These instances are described in this page.
Extension records in hash key files
When Model 204 determines that an extension record must be started while loading data into a hash key file, it starts the extension record on a random page. Fast/Reload, when operating using full track I/O, on the other hand, tries to start the extension record on the next page. This is because the full track feature requires that pages be written in ascending order. This has a side benefit that when retrieving the extension record, head movement and caching characteristics are likely to be improved.
If you want Fast/Reload to use the standard Model 204 extension record allocation, specify the DKONLY option in the FLOD program.
Adding data to non-empty unordered files
When loading data into unordered files that have had reusable space created because of record or field deletions, Model 204 ordinarily tries to put data in the reusable areas before appending data after the last record in the file. Fast/Reload attempts to add data after the last record in the file. This ensures that records are allocated in ascending order allowing full track I/O to be used for the loaded Table B pages.
If you want Fast/Reload to use the standard Model 204 record allocation for unordered files, specify the DKONLY option in the FLOD program.
Ordered Index layout when field codes change
Data in the Ordered Index is maintained in field code order. A field code is an internal, numeric (between 0 and 4095) representation of a field name. It is possible that a field code might change between a UAI and LAI. Since UAI simply loads the data in the order in which it was unloaded, this can produce a slightly different layout of the non-leaf nodes in the Ordered Index. The effect on FLOD/FILELOAD or Online performance is likely to be unmeasurable.
To minimize the chances of field code changes:
- Explicitly define fields in the same order they were defined in the original database file.
- Use the same value of ATRPG in the new database file as used in the old.
Ordered Index layout if mixing generated and unloaded index data
If the old database file had Ordered Index data unloaded via UAI OINDEX or
UAI INVISIBLE, and new Ordered Index fields are defined in the new database file,
the layout of non-leaf nodes is slightly different than if the Ordered Index data had all been regenerated and resorted via FLOD.
This is because the Ordered
Index data is loaded in a new step in the FLOD process called the "FLOD" step, before the Z step.
Thus the Ordered Index data is loaded in a different order than if all the data had been sorted and the loaded in the Z step. The effect on FLOD/FILELOAD or Online performance is likely to be unmeasurable.
Table B space allocation
As stated in the BAVail statement description, setting OPTION BAVAIL to a non-negative number causes a change in the way space is reserved on Table B pages.
- Fast/Reload guarantees (if full track I/O is in use) that BAVAIL bytes are unused on each Table B page.
- If full track I/O is in use, and the file is not SORTED (FILEORG X'01'),
Fast/Reload allows records to be started with less than
BRESERVE + BAVAILbytes available on the page, as long as the entire record fits on the page.
See the BAVAIL statement description for a complete discussion and some examples.