Fast/Reload differences with FLOD/FILELOAD: Difference between revisions
m (add FLOD and FILELOAD command processing) |
m (→FLOD and FILELOAD command processing: link repair) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 70: | Line 70: | ||
==FLOD and FILELOAD command processing== | ==FLOD and FILELOAD command processing== | ||
If the <var class="product">Fast/Reload|Fast/Reload FLOD Compiler</var> is authorized, the <var>FLOD</var> and <var>FILELOAD</var> commands work exactly like the usual <var>[[FLOD command|FLOD]]</var> and <var>[[FILELOAD command|FILELOAD]]</var> commands, except that they invoke the <var class="product">Fast/Reload FLOD Compiler</var> rather than the standard | If the <var class="product">[[Fast/Reload|Fast/Reload FLOD Compiler]]</var> is authorized, the <var>FLOD</var> and <var>FILELOAD</var> commands work exactly like the usual <var>[[FLOD command|FLOD]]</var> and <var>[[FILELOAD command|FILELOAD]]</var> commands, except that they invoke the <var class="product">Fast/Reload FLOD Compiler</var> rather than the standard | ||
<var class="product">Model 204</var> command processing. | <var class="product">Model 204</var> command processing. | ||
Latest revision as of 17:42, 9 May 2017
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.
FLOD and FILELOAD command processing
If the Fast/Reload FLOD Compiler is authorized, the FLOD and FILELOAD commands work exactly like the usual FLOD and FILELOAD commands, except that they invoke the Fast/Reload FLOD Compiler rather than the standard Model 204 command processing.
If a Fast/Reload FLOD Compiler site wants to use the standard Model 204 FLOD or FILELOAD command processing (most likely for diagnosing a problem with the Fast/Reload FLOD Compiler), the site can use the FLODX or the FILELOADX command. The FLODX and the FILELOADX commands have syntax identical to the FLOD and FILELOAD commands, respectively.
See File Load utility: FLOD and FILELOAD commands for more information about the FLOD and FILELOAD commands.
Note: While the Fast/Reload FLOD Compiler FLOD and FILELOAD commands do not support all the statements supported by the standard FLOD and FILELOAD commands, if such an unsupported statement is detected, the Fast/Reload FLOD Compiler automatically "hands off" the request to the standard FLOD or FILELOAD command. This handing off is done by saving the FLOD or FILELOAD program in a temporary procedure, the number of which is controlled by the FRELPREV parameter.