Utility Statements › FASTLOAD › Usage

Usage

How to submit the FASTLOAD statement

You submit the FASTLOAD statement only through the batch command facility. You must run the batch command facility in local mode.

When to use the FASTLOAD utility

Use the FASTLOAD utility to load a non-SQL-defined database for the first time.

When not to use the FASTLOAD utility

To reload a non-SQL-defined database that has been unloaded, use RELOAD.

To load an SQL-defined database, use LOAD.

Note: FASTLOAD cannot process mixed page groups and will issue an error message if mixed page groups are encountered. If your subschema binds to multiple page groups, you must select a subset of areas to process that are all in the same page group. You must use multiple invocations of the utility to process different page groups.

Before running FASTLOAD

To use the FASTLOAD utility, follow these guidelines:

1. Write a format program to prepare input data and create a subschema that describes the records and sets to be loaded.
2. Link edit the format program with IDMSDBLU and IDMS.
3. Execute the format program.
4. Execute the FASTLOAD utility to complete the loading process.

The format program

The format program builds record and set ownership descriptors for each record to be loaded. These descriptors are used when loading the records.

The subschema

The subschema must:

• Include all records being loaded and all sets in which the records participate
• Allow the areas being loaded, and all areas with set connections to those areas, to be readied in exclusive update mode

Run FASTLOAD all at once or in steps

The processing initiated by the FASTLOAD utility has six steps, which you can run one at a time or as a single process. Each step generates output for use by the next step. Three of the steps are sorts to prepare the data for use by the next step. You can use your own sorting program or direct the FASTLOAD utility to sort the data during processing. If you run the steps as a single process, sorting is performed automatically.

When to run FASTLOAD in steps

The most common reason to use the FASTLOAD utility in steps is to cut the work into pieces, each piece requiring less time to run than the whole process.

You may also decide to use the FASTLOAD utility in steps to use your own sorting programs between the steps, or you can run the sort steps on a different machine than that holding the database.

Restarting IDMSDBL2, IDMSDBL3 or IDMSDBL4

If a problem arises while running IDMSDBL2 or IDMSDBL3, do not simply fix the cause of the problem and rerun the step. In addition to fixing the cause of the problem, you must do one of the following:

• Reinitialize the database and begin again at the IDMSDBL2 step
• If you backed up the database before running the step, you can run the step again, using the backup

These steps change the database, and if a problem arises, you need to undo the changes before running a step over again.

If a correctable abend occurs while running IDMSDBL4 (for example, a time-out abend), you can restart the fastload operation at the IDMSDBL4 step after unlocking the areas involved. Because the IDMSDBL4 step modifies existing records, when it is restarted it will simply modify the same records in the same way.

SORTEXIT and FROM/STEP

When using the FROM and STEP options with the SORTEXIT option, each pair of SORTn and DBLx steps are considered to be one step. If either half of the SORTn/DBLx is specified on a FROM or STEP option, processing will start with the SORTn step and the DBLx step will also be executed. For example:

• FROM IDMSDBL3 will start with step SORT3 and will continue to the end.
• STEP SORT3 will run steps SORT3 and IDMSDBL3.

SORTEXIT/REUSE WORKFILE restart considerations

Since SORTEXIT combines each SORTn step with the DBLx step that follows it, if a failure occurs in the DBLx step, a restart (if a restart is possible) must begin with the sort step and the input to the step will be resorted. Non-SORTEXIT mode will take longer to run but can be restarted after the sort in this case. Therefore, if restart time is more critical than normal runtime, do not run the utility as a sortexit.

If the REUSE WORKFILE option is used with SORTEXIT, some input workfiles will be used as output files in the same step. Therefore, if these two options are used together and a failure occurs, the utility must be restarted from the beginning.

Workfile Considerations for restarting a failed FASTLOAD

If the FASTLOAD command fails, depending on the reason for failure, restart the command at the failing step using the "FROM step-name" syntax. You can restart a step only if the input files to that step are intact and valid.

To prepare for a possible restart when running a one-step FASTLOAD, the Intermediate work files should have a disposition that preserves the data set in the event of an abend, for example, "DISP=(NEW,CATLG,CATLG)."

To restart FASTLOAD at a particular step, the input files to that step must have a disposition to specify that the files already exist, for example, "DISP=OLD."

To determine which files were input to a given step, refer to the "Intermediate Work File" tables under "JCL Considerations." Partially created output files should be deleted before restarting the job, and the original disposition should be used in the restart job, for example, "DISP=(NEW,CATLG,CATLG)."

The SYSPCH file contains sort parameter information for sort steps. It is an output file to IDMSDBLn steps, but is not read unless restarting or running in step mode. So during a normal run, the SYSPCH file should be treated as a normal output file, for example, "DISP=(NEW,CATLG,CATLG)." However, restarting is not as straightforward. If the previous job failed in an IDMSDBLx step, the SYSPCH file was an output file and should be deleted before restarting. But if the failure occurred in a SORTx step, the contents of the SYSPCH file should contain the same values that were input to the SORTx step. In this case, the SYSPCH file should be preserved and defined as a SYS001 input file to the restart step.

When the SORTEXIT option is used, the SORTx and IDMSDBLx steps are combined. If a failure occurs in this mode, the SYSPCH file should normally be preserved and used as a SYS001 input file to the restart. However, there is a small window at the end of an IDMSDBLx step where the SYSPCH file is opened for output and new SORT parameters are written. If the job fails at this point, the entire SORTx/IDMSDBLx step must be restarted, but the SYSPCH file will not be valid as a SYS001 input file. In this case, the sort parameters must be recreated by hand or the job must be restarted at an earlier IDMSDBLx step if possible. One way to avoid this situation is to run in step mode when running SORTEXIT mode.

The RELDCTL data set is always an input file to the first step of a FASTLOAD whether being restarted or not.

The steps of FASTLOAD

The FASTLOAD utility consists of the following steps which you can run separately or as a single operation:

Each step has input and output

Note: This table describes the input and output files as if FASTLOAD were executing without the SORTEXIT and REUSE options. For the effect of these parameters, see "JCL Considerations" later in this chapter.

Sort output after each step

If you run the FASTLOAD utility a step at a time, you must sort the contents of the intermediate work files. You can use your own sort program or direct the FASTLOAD utility to perform the sorts for you. If you use your own sort program, do not execute the FASTLOAD utility sort steps.

You can use the sort parameters in SYSPCH from the format programs IDMSDBL2 and IDMSDBL3 as the starting point for coding your sort parameters.

Sort the intermediate work files as follows:

The format program

Functions

The format program must perform the following functions for each record to be loaded:

• Builds a record occurrence descriptor
• Builds one owner descriptor for each set in which the record is an automatic member
• Builds one owner descriptor for each set in which the record is a manual member if the record is to be connected to the set at load time
• Calls IDMSDBLU, passing the record occurrence descriptor as the first argument and the owner descriptors as the remaining arguments

Output

IDMSDBLU uses the information provided by the format program to create an output file for use as input by the FASTLOAD utility.

The format program specifies the subschema, SEGMENT, and DMCL

As part of preparation for FASTLOAD operations, the format program calls IDMSDBLU. On the FIRST CALL ONLY, the subschema, segment name, and the DMCL name must be identified for use by IDMSDBLU.

For example,

01  PARMLIST-1.
    02  SUBSCHEMA-NAME  PIC X(8)  VALUE 'EMPSS01'.
    02  SEGMENT-NAME    PIC X(8)  VALUE 'EMPDEMO'.
    02  DMCL-NAME       PIC X(8)  VALUE 'EMPDMCL'.

CALL 'IDMSDBLU' USING PARMLIST-1.

The subschema, segment name, and DMCL must exist and be accessible at the time that the format program passes their names to IDMSDBLU, and when they are to be used by the FASTLOAD utility.

Record descriptors

Record occurrence descriptors built by the format program must be aligned on a doubleword and must contain the following fields:

After the last record is passed to IDMSDBLU, it is necessary to call IDMSDBLU one final time. This call must have the RECORD descriptor with the record ID field set to a -1 as its parameter.

Owner descriptors

Owner descriptors built by the format program must be aligned on a fullword and must contain the following fields: