FLOD command: Difference between revisions

From m204wiki
Jump to navigation Jump to search
(Automatically generated page update)
m (add link to Fast/Reload)
 
(14 intermediate revisions by 2 users not shown)
Line 6: Line 6:
<dd>Starts a File Load (multistep) program
<dd>Starts a File Load (multistep) program
</dl>
</dl>
==Syntax==
==Syntax==
<p class="syntax">FLOD <i>k</i>, <i>n</i>, <i>m</i>
<p class="syntax">FLOD <span class="term">k</span>, <span class="term">n</span>, <span class="term">m</span>
</p>
</p>
   
   
<b>Where:</b>
Where:
<table>  
<table>  
<tr>
<tr>
<th>k</th>
<th>k</th>
<td> specifies the maximum number of records to be loaded into the <var class="product">Model&nbsp;204</var> file.</td>
<td>The maximum number of records to be loaded into the <var class="product">Model&nbsp;204</var> file.</td>
</tr>
</tr>
   
   
<tr>
<tr>
<th>n</th>
<th>n</th>
<td> specifies the maximum number of times the statements in the File Load program are to be executed.</td>
<td>The maximum number of times the statements in the File Load program are to be executed.</td>
</tr>
</tr>
   
   
<tr>
<tr>
<th>m</th>
<th>m</th>
<td> specifies the number of input records to skip before starting the load process.</td>
<td>The number of input records to skip before starting the load process.</td></tr>
</tr>
</table>
</table>
===Syntax notes===
===Syntax notes===
<p>FLOD must be issued in file context (that is, the current default must be a file, not a group).</p>
<p>
<p>FLOD cannot be issued from within a procedure.</p>
<var>FLOD</var> must be issued in file context (that is, the current default must be a file, not a group).</p>
<p>
<var>FLOD</var> cannot be issued from within a procedure.</p>
<p>Example </p>
<p>Example </p>
<p class="code">OPEN PEOPLE
<p class="code">OPEN PEOPLE
Line 41: Line 43:
END  
END  
</p>
</p>
==Usage notes==
==Usage notes==
<p>The FLOD command invokes the File Load (FLOD) utility. Use this command when performing a multistep File Load procedure. The FILELOAD command invokes a single-step File Load procedure.</p>
<p>
<p>FLOD signals the start of a File Load program that consists of special statements that load data from a sequential file into a <var class="product">Model&nbsp;204</var> file.</p>
The <var>FLOD</var> command ordinarily invokes the File Load (FLOD) utility. Use this command when performing a multistep File Load procedure. The <var>[[FILELOAD command|FILELOAD]]</var> command ordinarily invokes a single-step File Load procedure. </p>
<p class="note"><b>Note:</b> For a site that is authorized for <var class="product">[[Fast/Reload]]</var>, the <var>FLOD</var> and <var>FILELOAD</var> commands are syntactically unchanged but invoke <var class="product">Fast/Reload</var>, which compiles and executes the <var>FLOD</var> and <var>FILELOAD</var> programs.</p>
<p>
<var>FLOD</var> signals the start of a File Load program that consists of special statements that load data from a sequential file into a <var class="product">Model&nbsp;204</var> file.</p>
 
====File Load phases====
====File Load phases====
<p>The first phase of the multistep File Load is the execution of the File Load program, which formats and loads the data into Table B (and Table X) of the <var class="product">Model&nbsp;204</var> file. The first phase also generates the deferred updates for the <var class="product">Model&nbsp;204</var> file index (Tables C and D) and places these deferred updates in the deferred update data set or data sets. The second phase of the multistep File Load consists of sorting each of the deferred update data sets generated in the first phase and the FRV deferred update data set, if one is generated, and then applying the sorted deferred index updates to Tables C and D.</p>
<p>
The first phase of the multistep File Load is the execution of the File Load program, which formats and loads the data into Table B (and Table X) of the <var class="product">Model&nbsp;204</var> file. The first phase also generates the deferred updates for the <var class="product">Model&nbsp;204</var> file index (Tables C and D) and places these deferred updates in the deferred update data set or data sets. The second phase of the multistep File Load consists of sorting each of the deferred update data sets generated in the first phase and the <var>FRV</var> deferred update data set, if one is generated, and then applying the sorted deferred index updates to Tables C and D.</p>
 
====Job steps====
====Job steps====
<p>The first phase of the multistep File Load is performed in one job step; the second phase can involve many separate job steps. Each deferred update data set generated during the first phase of the File Load, and the FRV deferred update data set if one is present, adds two job steps to the File Load process. Each deferred update data set must be processed in the following separate job steps: </p>
<p>
The first phase of the multistep File Load is performed in one job step; the second phase can involve many separate job steps. Each deferred update data set generated during the first phase of the File Load, and the <var>FRV</var> deferred update data set if one is present, adds two job steps to the File Load process. Each deferred update data set must be processed in the following separate job steps: </p>
<ul>  
<ul>  
<li>
<li>One job step executes a sort program (such as IBM sort) to sort the deferred update data set into an order that allows efficient processing in the next job step.</li>
<p>One job step executes a sort program (such as IBM sort) to sort the deferred update data set into an order that allows efficient processing in the next job step.</p>
</li>
   
   
<li>
<li>The next job step executes the BATCH204 load module to process the sorted deferred index information and to update Tables C and D using the Z command.</li>
<p>The next job step executes the BATCH204 load module to process the sorted deferred index information and to update Tables C and D using the Z command.</p>
</ul>
</li>
<p>
</ul>
The number of job steps in the entire File Load process depends on the attributes of the fields being updated and the number of deferred update data sets specified in the JCL or on the <var>OPEN</var> command issued immediately before the <var>FLOD</var> command.</p>
<p>The number of job steps in the entire File Load process depends on the attributes of the fields being updated and the number of deferred update data sets specified in the JCL or on the OPEN command issued immediately before the FLOD command.</p>
 
====Deferred update data sets====
====Deferred update data sets====
<p>The TAPEI data set contains the data to be loaded into the <var class="product">Model&nbsp;204</var> file by the File Load program. The File Load program automatically defers updates to the index and writes the updates to the deferred update data set or data sets. It might be necessary to provide a fixed-length deferred update data set, a variable-length deferred update data set, or both. For information on deferred update data sets, refer to the <var>Model&nbsp;204 File Manager's Guide.</var></p>
<p>
<p>The default file name of the fixed-length deferred update data set during the first phase is TAPE2. Only hashed index updates (KEY and NUMERIC RANGE fields) can be written to the fixed-length deferred update data set.     </p>
The TAPEI data set contains the data to be loaded into the <var class="product">Model&nbsp;204</var> file by the File Load program. The File Load program automatically defers updates to the index and writes the updates to the deferred update data set or data sets. It might be necessary to provide a fixed-length deferred update data set, a variable-length deferred update data set, or both. For information on deferred update data sets, see [[Deferred update feature#Types of deferred update data sets|Types of deferred update data sets]].</p>
<p>The default file name of the variable-length deferred update data set during the first phase is TAPE3. Either hashed index updates (KEY and NUMERIC RANGE fields) or Ordered Index updates (ORDERED fields) can be written to the variable-length deferred update data set. If ORDERED fields are updated by the File Load program, there must be a variable-length deferred update data set supplied in the JCL or EXEC of the first-phase step.</p>
<p>
<p>The default file names of TAPE2 and TAPE3 can be overridden by specifying the appropriate file name or names on the OPEN command issued before the FLOD command.   </p>
The default file name of the fixed-length deferred update data set during the first phase is TAPE2. Only hashed index updates (<var>KEY</var> and <var>NUMERIC RANGE</var> fields) can be written to the fixed-length deferred update data set.</p>
<p>Each deferred update data set must be sorted, then processed by <var class="product">Model&nbsp;204</var> using the Z command. Input to the Z command comes from the data set associated with the SORT5 DD statement, FILEDEF, or DLBL. If any FRV fields were updated during the first phase of the file load, the Z command that processes the hashed index updates places fixed-length FRV deferred updates in the data set associated with the TAPE5 DD statement, FILEDEF, or DLBL. If all the index updates, both hashed and ordered, have been deferred to the variable-length data set, then the Z command that processes the variable-length data set also produces the FRV deferred update data set. Otherwise, the Z command that processes the fixed-length deferred update data set produces the FRV deferred update data set.   </p>
<p>
<p>The following discussion explains the consequences of specifying different combinations of deferred update data sets: </p>
The default file name of the variable-length deferred update data set during the first phase is TAPE3. Either hashed index updates (<var>KEY</var> and <var>NUMERIC RANGE</var> fields) or Ordered Index updates (<var>ORDERED</var> fields) can be written to the variable-length deferred update data set. If <var>ORDERED</var> fields are updated by the File Load program, there must be a variable-length deferred update data set supplied in the JCL or EXEC of the first-phase step.</p>
<p>
The default file names of <code>TAPE2</code> and <code>TAPE3</code> can be overridden by specifying the appropriate file name or names on the <var>OPEN</var> command issued before the <var>FLOD</var> command. </p>
<p><b>Z command</b></p>
<p>
Each deferred update data set must be sorted, then processed by <var class="product">Model&nbsp;204</var> using the <var>Z</var> command. Input to the <var>Z</var> command comes from the data set associated with the SORT5 DD statement, FILEDEF, or DLBL. If any <var>FRV</var> fields were updated during the first phase of the file load, the <var>Z</var> command that processes the hashed index updates places fixed-length <var>FRV</var> deferred updates in the data set associated with the TAPE5 DD statement, FILEDEF, or DLBL.</p>
<p>
If all the index updates, both hashed and ordered, have been deferred to the variable-length data set, then the <var>Z</var> command that processes the variable-length data set also produces the <var>FRV</var> deferred update data set. Otherwise, the <var>Z</var> command that processes the fixed-length deferred update data set produces the <var>FRV</var> deferred update data set.</p>
<p>
<b>Combinations of deferred update data sets</b></p>
<p>
The following discussion explains the consequences of specifying different combinations of deferred update data sets: </p>
<ul>  
<ul>  
<li>
<li><var>FLOD</var> with two deferred update data sets &mdash; Defer hashed index (<var>KEY</var> and <var>NUMERIC RANGE</var>) and Ordered Index updates separately. In the JCL or EXEC for the FLOD run, TAPE2 is specified with a fixed-length record format, and TAPE3 is specified with a variable-length record format. Updates to the hashed index are written to TAPE2 and updates to the Ordered Index are written to TAPE3.</li>
<p>FLOD with two deferred update data sets - Defer hashed index (KEY and NUMERIC RANGE) and Ordered Index updates separately. In the JCL or EXEC for the FLOD run, TAPE2 is specified with a fixed-length record format, and TAPE3 is specified with a variable-length record format. Updates to the hashed index are written to TAPE2 and updates to the Ordered Index are written to TAPE3.</p>
</li>
   
   
<li>
<li><var>FLOD</var> with one variable-length deferred update data set &mdash; Defer hashed index and Ordered Index updates to the same data set. In the JCL or EXEC for the FLOD run, only TAPE3 is specified with a variable-length record format. TAPE2 should not be specified.</li>
<p>FLOD with one variable-length deferred update data set - Defer hashed index and Ordered Index updates to the same data set. In the JCL or EXEC for the FLOD run, only TAPE3 is specified with a variable-length record format. TAPE2 should not be specified.</p>
</li>
   
   
<li>
<li><var>FLOD</var> with one fixed length deferred update data set &mdash; Defer only hashed index updates. No Ordered Index fields can be updated. In the JCL or EXEC for the <var>FLOD</var> run, only TAPE2 is specified with a fixed-length record format. Do not specify TAPE3. If an Ordered Index field is updated, an error message is issued and the <var>FLOD</var> program is ended.
<p>FLOD with one fixed length deferred update data set - Defer only hashed index updates. No Ordered Index fields can be updated. In the JCL or EXEC for the FLOD run, only TAPE2 is specified with a fixed-length record format. Do not specify TAPE3. If an Ordered Index field is updated, an error message is issued and the FLOD program is ended.</p>
<p>
<p>The default names TAPE2 or TAPE3 can be overridden by the OPEN command. </p>
The default names TAPE2 or TAPE3 can be overridden by the <var>OPEN</var> command. </p></li>
    </li>
</ul>
</ul>
<p>
<p>The FLOD command, File Load utility, deferred update data sets, Z command, FLOD statements, and the input data set requirements are discussed in detail in the <var>Model&nbsp;204 File Manager's Guide.</var></p>
For more information, see the file management topics in [[File Load utility: FLOD and FILELOAD commands]], [[Deferred update feature|deferred update feature]], and the [[Z command]].</p>
 
====FLOD exit feature====
====FLOD exit feature====
<p>The <var class="product">Model&nbsp;204</var> FLOD exit feature allows for modification of the record image on which the FLOD (or FILELOAD) command acts. With the FLOD exit feature you can create a COBOL or Assembler program to modify the image records. The FLOD exit feature enables the use of multiple input files for FLOD processing. The exit is modeled on SORT exits, similar to the E15 sort exit. The FLOD exit feature is documented in the <var>Model&nbsp;204 File Manager's Guide.</var></p>
<p>
The <var class="product">Model&nbsp;204</var> <var>FLOD</var> exit feature allows for modification of the record image on which the <var>FLOD</var> (or <var>FILELOAD</var>) command acts. With the <var>FLOD</var> exit feature you can create a COBOL or Assembler program to modify the image records. The <var>FLOD</var> exit feature enables the use of multiple input files for <var>FLOD</var> processing. The exit is modeled on SORT exits, similar to the E15 sort exit. See [[FLOD exits]] for details.</p>
 
====Update units====
====Update units====
<p>When it processes FLOD, <var class="product">Model&nbsp;204</var> ends any update unit in progress and begins a non-backoutable update unit. For more information about <var class="product">Model&nbsp;204</var> update units, see the <var class="book">Model&nbsp;204 File Manager's Guide</var>.</p>
<p>
When it processes <var>FLOD</var>, <var class="product">Model&nbsp;204</var> ends any update unit in progress and begins a non-backoutable update unit. For more information about <var class="product">Model&nbsp;204</var> update units, see [[File integrity and recovery#Update units and transactions|Update units and transactions]].</p>
 
[[Category: File manager commands]]
[[Category: File manager commands]]
[[Category:Commands]]
[[Category:Commands]]

Latest revision as of 18:19, 9 May 2017

Summary

Privileges
File manager (as User 0 only)
Function
Starts a File Load (multistep) program

Syntax

FLOD k, n, m

Where:

k The maximum number of records to be loaded into the Model 204 file.
n The maximum number of times the statements in the File Load program are to be executed.
m The number of input records to skip before starting the load process.

Syntax notes

FLOD must be issued in file context (that is, the current default must be a file, not a group).

FLOD cannot be issued from within a procedure.

Example

OPEN PEOPLE DEFINE FIELD SOC.SEC.NO. WITH KEY BINARY DEFINE FIELD NAME WITH KEY FLOD 5000,5000,0 G SOC.SEC.NO.=1,9,X'8000' NAME=10,14 END

Usage notes

The FLOD command ordinarily invokes the File Load (FLOD) utility. Use this command when performing a multistep File Load procedure. The FILELOAD command ordinarily invokes a single-step File Load procedure.

Note: For a site that is authorized for Fast/Reload, the FLOD and FILELOAD commands are syntactically unchanged but invoke Fast/Reload, which compiles and executes the FLOD and FILELOAD programs.

FLOD signals the start of a File Load program that consists of special statements that load data from a sequential file into a Model 204 file.

File Load phases

The first phase of the multistep File Load is the execution of the File Load program, which formats and loads the data into Table B (and Table X) of the Model 204 file. The first phase also generates the deferred updates for the Model 204 file index (Tables C and D) and places these deferred updates in the deferred update data set or data sets. The second phase of the multistep File Load consists of sorting each of the deferred update data sets generated in the first phase and the FRV deferred update data set, if one is generated, and then applying the sorted deferred index updates to Tables C and D.

Job steps

The first phase of the multistep File Load is performed in one job step; the second phase can involve many separate job steps. Each deferred update data set generated during the first phase of the File Load, and the FRV deferred update data set if one is present, adds two job steps to the File Load process. Each deferred update data set must be processed in the following separate job steps:

  • One job step executes a sort program (such as IBM sort) to sort the deferred update data set into an order that allows efficient processing in the next job step.
  • The next job step executes the BATCH204 load module to process the sorted deferred index information and to update Tables C and D using the Z command.

The number of job steps in the entire File Load process depends on the attributes of the fields being updated and the number of deferred update data sets specified in the JCL or on the OPEN command issued immediately before the FLOD command.

Deferred update data sets

The TAPEI data set contains the data to be loaded into the Model 204 file by the File Load program. The File Load program automatically defers updates to the index and writes the updates to the deferred update data set or data sets. It might be necessary to provide a fixed-length deferred update data set, a variable-length deferred update data set, or both. For information on deferred update data sets, see Types of deferred update data sets.

The default file name of the fixed-length deferred update data set during the first phase is TAPE2. Only hashed index updates (KEY and NUMERIC RANGE fields) can be written to the fixed-length deferred update data set.

The default file name of the variable-length deferred update data set during the first phase is TAPE3. Either hashed index updates (KEY and NUMERIC RANGE fields) or Ordered Index updates (ORDERED fields) can be written to the variable-length deferred update data set. If ORDERED fields are updated by the File Load program, there must be a variable-length deferred update data set supplied in the JCL or EXEC of the first-phase step.

The default file names of TAPE2 and TAPE3 can be overridden by specifying the appropriate file name or names on the OPEN command issued before the FLOD command.

Z command

Each deferred update data set must be sorted, then processed by Model 204 using the Z command. Input to the Z command comes from the data set associated with the SORT5 DD statement, FILEDEF, or DLBL. If any FRV fields were updated during the first phase of the file load, the Z command that processes the hashed index updates places fixed-length FRV deferred updates in the data set associated with the TAPE5 DD statement, FILEDEF, or DLBL.

If all the index updates, both hashed and ordered, have been deferred to the variable-length data set, then the Z command that processes the variable-length data set also produces the FRV deferred update data set. Otherwise, the Z command that processes the fixed-length deferred update data set produces the FRV deferred update data set.

Combinations of deferred update data sets

The following discussion explains the consequences of specifying different combinations of deferred update data sets:

  • FLOD with two deferred update data sets — Defer hashed index (KEY and NUMERIC RANGE) and Ordered Index updates separately. In the JCL or EXEC for the FLOD run, TAPE2 is specified with a fixed-length record format, and TAPE3 is specified with a variable-length record format. Updates to the hashed index are written to TAPE2 and updates to the Ordered Index are written to TAPE3.
  • FLOD with one variable-length deferred update data set — Defer hashed index and Ordered Index updates to the same data set. In the JCL or EXEC for the FLOD run, only TAPE3 is specified with a variable-length record format. TAPE2 should not be specified.
  • FLOD with one fixed length deferred update data set — Defer only hashed index updates. No Ordered Index fields can be updated. In the JCL or EXEC for the FLOD run, only TAPE2 is specified with a fixed-length record format. Do not specify TAPE3. If an Ordered Index field is updated, an error message is issued and the FLOD program is ended.

    The default names TAPE2 or TAPE3 can be overridden by the OPEN command.

For more information, see the file management topics in File Load utility: FLOD and FILELOAD commands, deferred update feature, and the Z command.

FLOD exit feature

The Model 204 FLOD exit feature allows for modification of the record image on which the FLOD (or FILELOAD) command acts. With the FLOD exit feature you can create a COBOL or Assembler program to modify the image records. The FLOD exit feature enables the use of multiple input files for FLOD processing. The exit is modeled on SORT exits, similar to the E15 sort exit. See FLOD exits for details.

Update units

When it processes FLOD, Model 204 ends any update unit in progress and begins a non-backoutable update unit. For more information about Model 204 update units, see Update units and transactions.