JAL: add category

2016-02-19T01:30:39Z

add category

New page

==Overview==
All <var class="product">Fast/Reload</var> programs must begin with a [[File Load utility: FLOD and FILELOAD commands|FILELOAD or FLOD command]] and end
with an <var>END</var> statement.
All statements between the <var>FILELOAD</var> or <var>FLOD</var> and the <var>END</var>
are converted into machine code by the <var class="product">Fast/Reload</var> compiler or are used to
set environmental parameters by the <var class="product">Fast/Reload</var> compiler.
An example of a very simple <var class="product">Fast/Reload</var> program is:
FILELOAD -1,-1,0,1000000,10000,10000,,68
G
DUMMY=1,0,X'8000'
FIELD1=1,10
END


<var class="product">Fast/Reload</var> supports all the [[File Load utility: FLOD and FILELOAD commands#Syntax of File Load statements|statements supported by FLOD and FILELOAD]] except
the following:
<ul>
<li>The <var>L</var> statement.
<li>The <var>ENDL</var> statement.
<li>The <var>F</var> statement.
<li>The <var>ENDF</var> statement.
<li>The <var>UP</var> statement.
<li>The <var>DOWN</var> statement.
<li>The <var>DELETE</var> statement.
</ul>
In addition, the X'4000' mode bit used to delete a field occurrence or occurrences is
not currently supported.
Finally, <var>FLOD</var> exits are not currently supported.

If you have <var>FILELOAD</var> or <var>FLOD</var> programs that contain statements not supported by
<var class="product">Fast/Reload</var>, you can still run the programs with the same load module you use
for <var class="product">Fast/Reload</var> programs.
The <var>[[FLOD and FLODX command|FLODX]]</var> and <var>[[FILELOAD and FILELOADX command|FILELOADX]]<var> commands invoke the
original <var class="product">Model 204</var> <var>FLOD</var> and <var>FILELOAD</var> programs instead of <var class="product">Fast/Reload</var>.

<var class="product">Fast/Reload</var> attempts to copy the <var>FLOD/FILELOAD</var> program
to the temporary procedure indicated by the <var>FRELPREV</var> system parameter
(which defaults to -1).
If <var class="product">Fast/Reload</var> determines that the <var>FLOD</var> or <var>FILELOAD</var> program
cannot be processed by <var class="product">Fast/Reload</var> but can be processed by standard <var>FLOD</var> or <var>FILELOAD</var>,
the <var>FRELPREV</var> temporary procedure is opened for input, and the program is passed to
standard <var>FLOD</var> or <var>FILELOAD</var> to be read again.

For more information on both supported and unsupported
statements, see [[:Category:File_management]].
In addition to the standard statement set, <var class="product">Fast/Reload</var> supports the extra statements
described in the following subsections: [[#opts|The OPTIONS statement]]
and [[#laistmt|The LAI statement]].

Note: Each statement must begin in column one, since a blank in column one of a FLOD statement indicates the "read-and-load-a-field" statement. 

==The OPTIONS statement==
This statement can appear anywhere inside a <var class="product">Fast/Reload</var> program and is used to set
environmental parameters that affect the way the load will be performed.
The <var>OPTIONS</var> statement can be abbreviated to its first three or more characters.
For example, the following are all valid <var>OPTIONS</var> statements:
OPTIONS TAPEI FOOFOO
OPTION TAPEI FOOFOO
OPTI TAPEI FOOFOO
OPT TAPEI FOOFOO
Multiple parameters can be set via the <var>OPTIONS</var> statement.
They are described in the following subsections.
The minimum required abbreviation for each is indicated in uppercase.

===ANYorder===
This option only has an effect when data is being loaded into a hash
or sort key file.
When data is being loaded into one of these files,
performance will generally be good if the data is being loaded in
hash or sort key order.
If the data being loaded is not in this order,
load performance could be disastrously affected.
<var class="product">Fast/Reload</var> normally does not continue in such a case.
The <var>ANYORDER</var> option overrides this behavior and lets the file load continue.

In general, it is better to determine the reason records
are out of order and to correct the problem, than to use the <var>ANYORDER</var>
option to ignore it.

If you are using <var>[[#The LAI statement|LAI]]</var>, the ordering can be done by the <var>HASH</var> or <var>SORT</var>
option of the
<var>[[Fast/Unload Extraction Language (FUEL)#UNLOAD ALL INFORMATION or UAI|UAI]]</var>
statement in <var class="product">Fast/Unload</var>.

Otherwise, to obtain the full track I/O benefits of <var class="product">Fast/Reload</var>,
you should ensure that your input records are in the correct order.
You must sort the TAPEI dataset in order by the <var>SORT</var> key, or by the
hash code of the <var>HASH</var> key.
This can be achieved using the M204HASH utility, as described in [[Hash key files]].

===BAVail [page_type] size===
This option has the following two beneficial effects:
<ol>
<li>If <var class="term">size</var> (default -1) is non-negative (and the file is not <var>SORTED</var>), the
use of the <var>[[BRESERVE parameter|BRESERVE]]</var> (= bres) parameter is changed during the file load.
A record will start within <code>remain <= size + bres</code> bytes at the end of the page if and only if the record fits in its entirety on that page. That is, the total record size is less than or equal to <var class="term">remain</var>.
This ensures that no base record is split with <var>BRESERVE</var> bytes or fewer in the base
record, while using more available space on a Table B page than the default algorithm.

<li>If <var class="term">size</var> is greater than zero, <var class="product">Fast/Reload</var>
ensures, during the file load, that at least <var class="term">size</var> bytes are unused on a Table B page.
This provides for some record growth by subsequent updates, for example, during an Online run,
without shifting fields to an extension record.
</ol>
<var>BAVAIL</var> is ignored if <var class="product">Fast/Reload</var> is not operating using full track I/O.
A base record is the first part of a Table B record, as opposed to
the subsequent parts of a Table B record, which are called extension records.

====Parameters====
<ul>
<li><var class="term">size</var> is -1 (the default) or a non-negative number. The smallest value of <var class="term">size</var>
for any <var>BAVAIL</var> option is -1. The largest value is
6130 minus the length of all preallocated fields,
minus 3 if <var>FILEORG</var> is <var>SORTED</var>, minus 1 if <var>FILEORG</var> is <var>HASHED</var>, minus 4 if
<var>FILEORG</var> is <var>UNORDERED</var>. </li>

<li><var class="term">page_type</var> can be any of the following:
<table class="thJustBold">
<tr><th>ALL</th>
<td>This applies to all Table B pages. If <var class="term">size</var> is non-negative,
then <var class="product">Fast/Reload</var> guarantees that every table B page contains at least <var class="term">size</var> unused bytes.</td></tr>

<tr><th>BASE</th>
<td>This applies to any page that
contains one or more base records. If <var class="term">size</var> is non-negative, then <var class="product">Fast/Reload</var> guarantees that any page with a base record contains
at least <var class="term">size</var> unused bytes.</td></tr>

<tr><th>EXT</th>
<td>This applies to any page that contains an extension record. If <var class="term">size</var> is non-negative, then <var class="product">Fast/Reload</var> guarantees
that any page with an extension record contains at least <var class="term">size</var> unused bytes.</td></tr>
</table>

If <var class="term">page_type</var> is omitted, <var class="term">size</var> applies to all Table B pages.</li>
</ul>

====Usage====
Multiple <code>OPTIONS BAVAIL</code> specifications will override the value(s) previously specified.
For example:
OPTIONS BAVAIL 100 BAVAIL BASE 150

will set aside 150 bytes on each page with a Table B base record, and 100 bytes
on all other Table B pages, but
<nowiki>OPTIONS BAVAIL BASE 150 BAVAIL 100
</nowiki>
will set aside 100 bytes on all Table B pages.

The default <var>BAVAIL</var> for each page type is -1.
If the value of all of them is
-1, <var class="product">Fast/Reload</var> does not specifically reserve any Table B space, but uses the normal
<var class="product">Model 204</var> space algorithm determined by <var>BRESERVE</var>, ensuring that a record does not
start within the last <var>BRESERVE</var> bytes of a page.

If the file being loaded is not a <var>SORTED</var> file (<var>[[FILEORG parameter|FILEORG]]</var> X'01'),
a non-negative setting for any page type
will modify the effect of the <var>BRESERVE</var> parameter for all Table B pages.
Let <code>BA</code> be the maximum of all <var>BAVAIL</var> values; if
it is non-negative, then if an entire Table B record is
less than <var>BRESERVE</var> bytes long, it can be stored within the last <code>BA
+ BRESERVE</code> bytes on the page, but otherwise a Table B record is not
started in that area.

Therefore, you may want to set a temporary value for <var>BRESERVE</var> during the
file load which differs from the value used during online updating.
For example:
<nowiki>OPEN FILE mumble
RESET BRESERVE 300
FILELOAD -1,-1,0,1000000,1000000
OPTIONS BAVAIL 400
LAI
END
RESET BRESERVE 800
</nowiki>
Note: The correct values for <var>BRESERVE</var> and <var>BAVAIL</var> are file-specific, and depend
on characteristics such as record sizes, the cost to your applications of
extension records, the importance of conserving Table B space, and updating
characteristics.
Like any tuning exercise, this requires analysis and experimentation.
The numbers in the above example could be wrong for your file, in fact, you may
do better with an online <var>BRESERVE</var> that is smaller than the file load <var>BRESERVE</var>,
and <var>BAVAIL</var> may be smaller than both, larger than both, or in between.


====Examples====
In the following examples:
<ul>
<li>The file is a simple <var>ENTRY ORDER</var> file (<var>FILEORG</var> X'00').
<li>There are no preallocated fields.
<li>Each page contains 6140 usable bytes.
(A page has 6144 bytes prior to the trailer, but there are 2 bytes used
to determine the number of records on a page, and 2 used for the amount of unused space.)

<li><code>Dataln</code> means the total length of data in
a record, <code>basln</code> means the space used for a base record,
and <code>extln</code> means the space used for an extension record.

<li>Each base record or extension record requires a 2-byte page locator, and
contains a 3-byte area which is zero or has the record number of a
subsequent extension record.
So, for example, if a record is completely stored in a base record,
<code>basln = dataln + 5</code>.

<li>Each example illustrates a case starting with a base record on an empty page.

<li>The resulting space allocation shows each page as the letter "P" and a
page number, followed by extension and/or base records
and free space enclosed in square brackets.
For example, the following shows two records stored on one page:
<nowiki>Rec0 dataln=100
Rec1 dataln=300
P0 [Rec0 basln=105] [Rec1 basln=305]
[free=5730]
</nowiki>

<li>Extension records are shown with the base record ID followed by a period and
extension number. For example, this
shows one record stored on three pages:
<nowiki>Rec0 dataln=12570
P0 [Rec0 basln=6140]
P1 [Rec0.1 extln=6140]
P2 [Rec0.2 extln=305] [free=5835]
</nowiki>

<li>Results are shown for different values for <var>BAVAIL</var>.
With the default value of <code>BAVAIL=-1</code>, <var class="product">Fast/Reload</var> uses the standard
<var class="product">Model 204</var> algorithm for allocating Table B space during a file load.
This standard algorithm is always used when <var class="product">Fast/Reload</var> is not using full track I/O.
</ul>

<ol>
<li>The following example shows that <code>BAVAIL=0</code> can be used for maximum packing on a
page, and <code>BAVAIL>0</code> can be used to ensure free space on a page; each of them
ensure a base record is not split in the first <var>BRESERVE</var> bytes:
Rec0 dataln = 6000
Rec1 dataln = 130
BRESERVE = 300

Using BAVAIL = -1:
P0 [Rec0 basln=6005] [free=135]
P1 [Rec1 basln=135] [free=6005]

Using BAVAIL = 0:
P0 [Rec0 basln=6005] [Rec1 basln=135]

Using BAVAIL = 135:
P0 [Rec0 basln=6005] [free=135]
P1 [Rec1 basln=135] [free=6005]
</li>

<li>The following example shows that without <var>BAVAIL</var>, you cannot
guarantee free space on a page:
<nowiki>Rec0 dataln=130
Rec1 dataln=6000 (60 100-byte fields)
BRESERVE = 300

Using BAVAIL = -1:
P0 [Rec0 basln=135] [Rec1 basln=6005]

Using BAVAIL = 0:
P0 [Rec0 basln=135] [Rec1 basln=6005]

Using BAVAIL = 135:
P0 [Rec0 basln=135] [Rec1 basln=5805] [free=200]
P1 [Rec1.1 extln=205] [free=5935]
</nowiki></li>

<li>The following example shows tighter packing and fewer extension
records:
<nowiki>Rec0 dataln=6000 (60 100-byte fields)
Rec1 dataln=100
Rec2 dataln=6100 (61 100-byte fields)
Rec3 dataln=100
Rec4 dataln=6000 (60 100-byte fields)
BRESERVE = 200

Using BAVAIL = -1:
P0 [Rec0 basln=6005] [free=135]
P1 [Rec1 basln=105] [Rec2 basln=6005] [free=30]
P2 [Rec2.1 extln=105] [Rec3 basln=105]
[Rec4 basln=5905] [free=25]
P3 [Rec4.1 extln=105] [free=6035]

Using BAVAIL = 0:
P0 [Rec0 basln=6005] [Rec1 basln=105] [free=30]
P1 [Rec2 basln=6105] [free=35]
P2 [Rec3 extln=105] [Rec4 basln=6005] [free=30]
</nowiki></li>

<li>The following example shows use of <var>BAVAIL</var> that
increases the extension records at file load time, but by leaving
space on all pages,
records can grow without producing extension
records which are stored on pages "far away" from the base page:
<nowiki>Rec0 .. Rec5 dataln=4000 (40 100-byte fields)
BRESERVE = 300

Using BAVAIL = -1:
P0 [Rec0 basln=4005] [Rec1 basln=2105]
[free=30]
P1 [Rec1.1 extln=1905] [Rec2 basln=4005]
[free=230]
P2 [Rec3 basln=4005] [Rec4 basln=2105]
[free=30]
P3 [Rec4.1 extln=1905] [Rec5 basln=4005]
[free=230]

Using BAVAIL = 300:
P0 [Rec0 basln=4005] [Rec1 basln=1805]
[free=330]
P1 [Rec1.1 extln=2205] [Rec2 basln=3605]
[free=330]
P2 [Rec2.1 extln=405] [Rec3 basln=4005]
[Rec4 basln=1405] [free=325]
P3 [Rec4.1 extln=2605] [Rec5 basln=3205]
[free=330]
P4 [Rec5.1 extln=805] [free=5335]
</nowiki></li>
</ol>

===DKOnly===
In many cases, <var class="product">Fast/Reload</var> bypasses the <var class="product">Model 204</var> disk buffer
monitor for Table B pages and instead uses its own full track buffers
for output.
This can, in certain instances, result in data being
loaded into different Table B pages than standard <var>FLOD</var> or <var>FILELOAD</var> would use.
An example of this is non-empty reuse record number files.
You can force <var class="product">Fast/Reload</var> to use the <var class="product">Model 204</var> disk buffer
monitor by specifying the <var>DKONLY</var> option.
This option can result in
a significant increase in the real and CPU time required to perform a file load.

===ERRCont===
This parameter lets you complete a reload despite errors that would
normally cause a <code>MSIR.0316</code> user restart.
This can be useful, for example, in a case where you know you have some
input data that will cause an error, but you
want to use a reload for reformatting purposes despite the problematic fields.

If you specify <var>ERRCONT</var> to "continue on error" a <var class="product">Fast/Reload</var> program, you probably
need to increase the <var class="product">Model 204</var> <var>ERMX</var> parameter setting to prevent a session
termination because of excessive errors.
Note: Using <var>ERRCONT</var> may place your data at risk, so use this parameter only in cases
where you know your data and have taken due precautions and backups beforehand.


The following <var>FILELOAD</var> code uses the <var>ERRCONT</var> parameter:
<nowiki>FILELOAD -1,-1,0,1000000,10000,10000,10000,50
OPTIONS ERRCONT
LAI
END
</nowiki>

===FTOnly===
In many cases, <var class="product">Fast/Reload</var> bypasses the <var class="product">Model 204</var> disk buffer
monitor for Table B pages and instead uses its own full track buffers for output.
In certain cases, though, <var class="product">Fast/Reload</var> will automatically drop back to
using the <var class="product">Model 204</var> disk buffer monitor.
When it does this, a file load
might take considerably longer than expected.
If you do not wish <var class="product">Fast/Reload</var>
to perform this automatic dropback, simply specify the <var>FTONLY</var> option.
<var>FTONLY</var> will result in the file load being terminated when an automatic dropback would
ordinarily be done.

===NObuff n_out_buffs===
<var>NOBUFF</var> must be followed by a number indicating the number of full track
output buffers <var class="product">Fast/Reload</var> is to use.
When <var class="product">Fast/Reload</var> is bypassing the <var class="product">Model 204</var> disk buffer monitor and performing
full track I/O to Table B, it uses a certain number of full track buffers.
These buffers must each be large enough to hold the data that will fit on a single
track of the disk devices containing the database file.
This means that the buffers
will each be 43,288 bytes long if you are using 3380s, 49,472 bytes long if you are
using 3390s, and 49,472 bytes long if you are using both.

Ordinarily <var class="product">Fast/Reload</var> uses three full track output buffers.
This is probably sufficient for most purposes.
On rare occasions, it might be possible to
get some speed improvements by using more than three output buffers.
In these cases, simply specify the <var>NOBUFF</var> option followed by a number greater than 3. 

<var>NOBUFF</var> must always be greater than or equal to 3. 

===NXBuff n_tableX_buffs===
<var>NXBUFF</var> must be followed by a number indicating the number of full track
Table X buffers <var class="product">Fast/Reload</var> is to use.

<var>NXBUFF</var> must always be greater than or equal to 3. 

===NOVAlidate===
<var>NOVALIDATE</var> indicates that no buffer pointer validation is to be performed.
For example, in the following statement, buffer pointer validation would make
sure that the input record was at least 107 bytes long:
<nowiki>FIELDA=99,9
</nowiki>
Without buffer pointer validation, the above statement would simply load data
off the end of the input buffer, which would result in <code>FIELDA</code> being loaded with
garbage, or perhaps in certain cases, would result in an addressing exception
because the area past the end of the buffer is not allocated.
Buffer pointer validation is probably more important with index register based
references to the input buffer, because these types of references are more likely
to have bad values in the index register and so go outside the current input buffer:
<nowiki>FIELDC=4|1,20
</nowiki>

With buffer pointer validation, if a buffer reference is determined to be invalid,
an error message is issued indicating the input record number as well as the invalid
buffer offset and length, as in the following example:
<nowiki>MSIR.0892: Input error: input record number: 1, start position/length: 99/9
</nowiki>

Standard <var>FILELOAD</var> started performing buffer pointer validation in <var class="product">Model 204</var> V5R1.

While buffer pointer validation is probably a good idea, it does have a slight
performance cost.
If there appears to be little chance of a buffer pointer error in a <var>FILELOAD</var>
program, and performance is at an absolute premium, you can use the <var>NOVALIDATE</var>
option to eliminate the cost of the buffer pointer validity checks.

Since <var>LAI</var> programs have no explicit buffer references, the <var>NOVALIDATE</var> option has
no effect on <var>LAI</var> programs.

===STAtc stats_intvl===
<var>STATC</var> must be followed by a number indicating the number of database file records that
<var class="product">Fast/Reload</var> will create before updating <var class="product">Model 204</var> statistics.
To speed up processing, <var class="product">Fast/Reload</var> does not ordinarily update <var class="product">Model 204</var> statistics
(since last, system, etc.) until the end of a file load.

If you want these statistics to be updated more frequently, you can specify a <var>STATC</var> value.
If you specify <code>OPTION STATC 10</code>, <var class="product">Model 204</var> statistics are updated for every
10th record created in the database file.
<code>OPTION STATC 0</code> and <code>OPTION STATC 1</code> are equivalent. 

===TAPei ddname===
<var>TAPEI</var> must be followed by string indicating the DDNAME to be used instead of <code>TAPEI</code>
for the input sequential file containing the data to be loaded.
For example if you wish to load data from DDNAME <code>HOMER</code>, simply specify <code>OPTION TAPEI HOMER</code>.
This allows more than one input stream to be used to load data in a single BATCH204 or Online run.

==The LAI statement==
The <var>LAI</var> statement allows data created with the <var class="product">Fast/Unload</var>
<var>[[Fast/Unload Extraction Language (FUEL)#UNLOAD ALL INFORMATION or UAI|UAI]]</var> (<var>Unload All Information</var>) statement to be loaded into a database file.
<var>LAI</var> stands for Load All Information and has several optional parameters.

===Syntax===
LAI [DElfield] [FAMsplit] [NEWfgid] [NOfdef]
[NOIndex] [NOProcs]

where the parameters can be abbreviated with only the part shown in
uppercase, and where:
<table class="thJustBold">
<tr><th>DElfield</th>
<td>Means that if a field that is not defined in the target file is found in the input dataset, that is, was unloaded by <var>UAI</var>, that field should simply be deleted.
If this parameter is not specified, the presence of an undefined field would terminate the <var>LAI</var>with an error. This statement provides an efficient way of deleting fields during a reorg.
Note: This parameter has no effect if the <var>NOFDEF</var> parameter is notalso specified. This is because if <var>NOFDEF</var> is not specified, any unloaded field will be automatically defined in the target file. </td></tr>

<tr><th>FAMsplit</th>
<td>Means that if any two names (two fields, a field and an alias, or two aliases) were part of a single <var class="product">Sir2000 Field Migration Facility</var> family in the unloaded file but are
now either separate fields or part of separate <var class="product">Sir2000 Field Migration Facility</var> families, the values should be loaded into each field or family. Effectively, this "splits" the original family into multiple components.
If <var>FAMSPLIT</var> is not specified, an attempt to do such a split causes the <var>FLOD</var> or <var>FILELOAD</var> to be terminated.

The most likely use of this parameter is to convert a file that is being controlled by <var class="product">Sir2000 Field Migration Facility</var> into one that is not, but where any fields or aliases that were in
the original file could still be referred to with SOUL programs. This might be useful for sending a non-<var class="product">Sir2000 Field Migration Facility</var> version of a file to a site
that does not have <var class="product">Sir2000 Field Migration Facility</var>. Since <var class="product">Sir2000 Field Migration Facility</var> makes sure that related fields and aliases automatically
stay in synch, it is generally not a good idea to update the non-<var class="product">Sir2000 Field Migration Facility</var> version of the file. 

See the "File Reorganizations" chapter in the
<var class="book">[[Media:SirfieldNew.pdf|Sir2000 Field Migration Facility Reference Manual]]</var>
for considerations about preserving SIRFIELD information using <var class="product">Fast/Reorg</var>.</td></tr>

<tr><th>NEWfgid</th>
<td>Means that fieldgroup IDs from the TAPEI input file are not copied to created fieldgroups, but rather that fieldgroup IDs within each record are created starting with 1.</td></tr>

<tr><th>NOfdef</th>
<td>Means that field definitions unloaded by <var>UAI</var> are not to be used to automatically define a field if it does not exist in the new file.
If this parameter is not specified, all fields that have not been explicitly
defined in the new database file but were defined in the old database file (unloaded with <var>UAI</var>) will be
defined with exactly the same attributes that they had in the old database file.</td></tr>

<tr><th>NOIndex</th>
<td>Means that Ordered Index data unloaded by UAI is not to be loaded by <var>LAI</var>. When this optionis used, visible Ordered Index data will be regenerated and sorted by <var>LAI</var>
and invisible Ordered Index data will be lost. This parameter has no effect if the <var>OINDEX</var> parameter was not specified on the <var>UAI</var> command for the unload.</td></tr>

<tr><th>NOProcs</th>
<td>Means that any procedures and procedure aliases unloaded by <var>UAI</var> are not to be loaded by <var>LAI</var>. Procedure and alias records in the input dataset will be skipped.
For more information about loading procedures, see [[Fast/Reload procedure handling]].</td></tr>
</table>

<var class="product">Fast/Reload</var> programs using <var>LAI</var> are quite simple.
For example, the following is a valid Fast/Reload program:
FILELOAD -1,-1,0,1000000
LAI
END


Note: The <var>LAI</var> statement has this limitation:
it must be the only statement that appears in a <var class="product">Fast/Reload</var> program other
than the <var>OPTION</var> statement.


===LAI compared to FILELOAD/FLOD===
When using <var>LAI</var>, some of the parameters on the <var>FILELOAD</var> or <var>FLOD</var> statementhavea slightly
different meaning than when doing a standard <var>FLOD</var>.
These parameters are:
<ul>
<li>Parameter 1

This parameter has the same meaning as in standard FILELOAD/FLOD.
That is, this is the
maximum number of records that will be loaded into the database file. </li>

<li>Parameter 2

This parameter is ignored when doing an <var>LAI</var>. </li>

<li>Parameter 3

In standard FILELOAD/FLOD programs this indicates the number of physical
input records in TAPEI to be skipped.
When doing an <var>LAI</var>, this indicates the number of unloaded
Table B records to be skipped. 

This parameter, along with parameter 1, lets you split
a reload into pieces.
For example, the following statements
load the first million records unloaded via UAI, then the next million records
and finally the remaining records. 
<nowiki>FILELOAD 1000000,-1,0,100000,100000
LAI
END
FILELOAD 1000000,-1,1000000,100000,100000
LAI
END
FILELOAD -1,-1,2000000,100000,100000
LAI
END
</nowiki> </li>
</ul>
All other parameters for the <var>FILELOAD</var> statement have the same meaning as when
doing a non-<var>LAI</var> <var>FILELOAD</var>.

===Using LAI with UAI===
<var>LAI</var> is closely related to the UAI statement in <var class="product">Fast/Unload</var>.
Ordinarily, the interaction between these two is quite simple.
However, in cases where sorting of the data unloaded by <var class="product">Fast/Unload</var> is
desired and/or if the data is being loaded into a hash or sort key
file, the interaction can become more complex.

When loading data into a hash or sort key file with the <var>LAI</var> statement, the data must have been
unloaded with a <var>UAI</var> statement that specified the <var>HASH</var> or <var>SORT</var> parameter
and specified the new file's hash or sort key as the first key on the <var>UAI</var> statement.
If this is not the case, the <var>LAI</var> will not load any data.
If the <var>UAI</var> statement
is coded correctly, the data unloaded by <var>UAI</var> will be in the order that the data
will eventually be in the database file being loaded.
In these cases, <var class="product">Fast/Reload</var>
will never have to make more than one pass through Table B and will actually be
able to use full track I/O to write the Table B pages if the data is being
loaded into an empty hash or sort key file.

If the <var>UAI</var> statement is coded incorrectly, however, the unloaded data will be
in an order different from that which the data will loaded into the destination database file.
The impact of this on performance could be disastrous.
Consequently, <var class="product">Fast/Reload</var> will not ordinarily continue in the case when
data is detected out of order.
You can override this behavior with the
<var>ANYORDER</var> option, but at least in the case of reorganizations, it is generally
faster to unload the data again with the correct parameters rather than
trying to load the data in incorrect order.

The types of errors on the
<var>UAI</var> statement that can cause data to be in incorrect order are:
<ul>
<li>Specifying <var>SORT</var> on the <var>UAI</var> and then attempting to load the data
into a hash key file.</li>

<li>Specifying <var>HASH</var> on the <var>UAI</var> and then attempting to load the data
into a sort key file.</li>

<li>Specifying a <var>BSIZE</var> on the <code>UAI HASH</code> statement different from the <var>BSIZE</var>
in the hashed file being loaded.
</ul>

<blockquote class="note">
Note: If you are loading the data into a sorted file, there are several
cases of the <code>UAI SORT</code> statement that render the sort key unusable.
See [[Fast/Unload Extraction Language (FUEL)#UAI SORT or HASH and field unload order|UAI SORT or HASH and field unload order]]. 

If you are loading the data into a non-hash key, non-sort key
file, there is nothing wrong with loading data unloaded with a <var>UAI</var> command
that had a <var>SORT</var> or <var>HASH</var> key specified.
In fact, if you want to maintain
good locality for data with similar values for a particular field without
incurring the overhead of maintaining a sort key file, you
can specify that field as a sort key on a <var>UAI</var> and simply load the data into a non-sort key file. 
</blockquote>

==Loading null data==
Standard <var class="product">Model 204</var> <var>FLOD</var> and <var>FILELOAD</var> do not allow null data (stringdata with
a length of 0) to be loaded into the database file.
That is, if after stripping blanks and zeros the resulting
field has length zero, no data will be loaded into the database file.
This is the case, even if you are trying to load null data that had been
dumped using the <var class="product">SOUL</var> <var>[[PAI statement|PAI]]</var> statement.
Thus, it is extremely difficult
if not impossible to reorganize a database file containing null data
using <var>FLOD</var> or <var>FILELOAD</var>.

<var class="product">Fast/Reload</var> allows you to do this in a couple of ways:
<ul>
<li>Any null data unloaded via <var class="product">Fast/Unload</var>'s <var>UAI</var> statement will be loaded
as null data by <var class="product">Fast/Reload</var>'s <var>LAI</var> statement. </li>

<li>The <code>X'0001'</code> mode bit lets you load null data as a
zero length string into the database file. </li>
</ul>

For example, the following
<var>FILELOAD</var> program will load null data dumped via the <var>PAI</var> statement back into the new database file as null data:
<nowiki>FILELOAD -1,-1,0,1000000,10000,10000,,68
I 3
#1
G
=4,5,*
I 1
#2
=3,6|1,=
I 1,,,1|1
=2
#3
I 2,1,2,-7,-1|1
D 5,0|1=8|1,0|2,X'0801'
=1
#4
PROC.ID=1,0,X'8000'
END
</nowiki>
The key part of the above example is the X'0001' mode
bit on the <code>D</code> statement.
Note also, that for <var>PAI</var> type
reloads, it is generally a good idea to turn off blanks stripping.
This is controlled by the X'0800' mode bit on the <code>D</code> statement.

==See also==
{{Template:Fast/Reload topic list}}

[[Category:Fast/Reload]]

Fast/Reload statements - Revision history

Mlarocca at 14:45, 16 December 2016

JAL: link repair

Admin: 1 revision: from Stage

JAL: add category

← Older revision		Revision as of 14:45, 16 December 2016
Line 499:		Line 499:

	===LAI compared to FILELOAD/FLOD===		===LAI compared to FILELOAD/FLOD===
	When using <var>LAI</var>, some of the parameters on the <var>FILELOAD</var> or <var>FLOD</var> ~~statementhavea~~ slightly		When using <var>LAI</var>, some of the parameters on the <var>FILELOAD</var> or <var>FLOD</var> statement have a slightly
	different meaning than when doing a standard <var>FLOD</var>.		different meaning than when doing a standard <var>FLOD</var>.
	These parameters are:		These parameters are:

← Older revision		Revision as of 23:32, 1 September 2016
Line 31:		Line 31:
	<var class="product">Fast/Reload</var>, you can still run the programs with the same load module you use		<var class="product">Fast/Reload</var>, you can still run the programs with the same load module you use
	for <var class="product">Fast/Reload</var> programs.		for <var class="product">Fast/Reload</var> programs.
	The <var>[[FLOD and FLODX command\|FLODX]]</var> and <var>[[FILELOAD and FILELOADX command\|FILELOADX]]<var> commands invoke the		The <var>[[FLOD and FLODX command\|FLODX]]</var> and <var>[[FILELOAD and FILELOADX command\|FILELOADX]]</var> commands invoke the
	original <var class="product">Model 204</var> <var>FLOD</var> and <var>FILELOAD</var> programs instead of <var class="product">Fast/Reload</var>.		original <var class="product">Model 204</var> <var>FLOD</var> and <var>FILELOAD</var> programs instead of <var class="product">Fast/Reload</var>.

Line 43:		Line 43:

	For more information on both supported and unsupported		For more information on both supported and unsupported
	statements, see [[:Category:~~File_management~~]].		statements, see [[:Category:File loading and reorganization]].
	In addition to the standard statement set, <var class="product">Fast/Reload</var> supports the extra statements		In addition to the standard statement set, <var class="product">Fast/Reload</var> supports the extra statements
	described in the following subsections: [[#opts\|The OPTIONS statement]]		described in the following subsections: [[#opts\|The OPTIONS statement]]

← Older revision	Revision as of 01:41, 19 February 2016
(No difference)