FLOD command

Summary

Privileges

File manager (as User 0 only)

Function

Starts a File Load (multistep) program

Syntax

FLOD k, n, m

Where:

k	specifies the maximum number of records to be loaded into the Model 204 file.
n	specifies the maximum number of times the statements in the File Load program are to be executed.
m	specifies 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 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.

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, refer to the Rocket Model 204 File Manager's Guide.

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.

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.

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 on the File Load utility: FLOD and FILELOAD commands, deferred update data sets, 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.