Utility Statements › REORG › Usage › Work Files

Work Files

The REORG process requires many work files. These files can be dynamically created and allocated for you by the REORG utility, or you can manually assume these responsibilities. This section discusses considerations associated with the creation and use of work files.

Work files and the n WAYS parameter

The number of work files required by REORG can grow exponentially as the value in the DIVIDE PROCESSING n WAYS parameter is increased. Therefore, you should exercise care in choosing this parameter.

For example, a REORG that specifies DIVIDE PROCESSING 2 WAYS usually results in 2 unload slices, 2 reload slices, and 4 SYS002 work files. If 3 WAYS were specified, this usually results in 3 unload slices, 3 reload slices, and 9 SYS002 work files. A similar expansion exists for each RELOAD phase.

REBUILD phases use fewer work files, but the number of index work files generated by RELOAD1 increases with the number of reload slices.

Reducing the number of work files

There are two ways to reduce the number of work files needed by the REORG utility other than reducing the n-WAYS parameter. You can direct REORG to:

• Reuse work files, which allows work files that are no longer needed to be reused for other purposes during later phases of processing
• Execute as a sort exit, which eliminates the use of sorted output files

It is recommended that both of these options be used to reduce the number of work files, and the amount of disk space needed.

Work file creation

REORG can create work files dynamically or you can manually create them prior to beginning the unload and/or reload phases of REORG execution. Regardless of how the files are created, it is a good idea to halt execution after setup to determine what work files are needed by examining the report produced by REORG.

If using dynamic work file creation, you must specify the attributes of the work files using one or more CREATE DSMODEL statements. REORG creates the files either as directed by the CREATE WORKFILE clause or at the time they are first accessed. Dynamically created work files, other than DBKEYS files, are deleted automatically during the cleanup phase.

If you want to use REORG's size estimates to create a file, code a DSMODEL without a primary SPACE allocation. You can code a SPACE parameter with just a unit type (TRK, CYL, or blksize) and no value for primary allocation.

You must code a primary space allocation value or delay creating work files until estimates are available. This means, for example, that you cannot direct REORG to create RELOAD work files during the setup phase unless the DSMODEL contains a primary allocation value.

If you code a zero primary space allocation value and a non-zero secondary value, the secondary value is replaced by a value derived from the estimated primary value.

Note: For more information, see Considerations for running REORG on VSE.

Work file allocation

REORG can allocate work files dynamically or you can reference them manually by including an appropriate DD statement in the REORG job's JCL and in the JCL included in the RORGJCL file if automatic job submission is used.

If using dynamic work file allocation, you must specify the data set names of the work files using one or more CREATE DSMODEL statements. REORG allocates the files as they are needed. If a DD card for a given work file is included in the execution JCL, it is used, and that file is not dynamically allocated.

If not using dynamic work file allocation, you must include a DD statement for every work file in every REORG job and in the RORGJCL file.

Work file deletion

By default during the cleanup phase, REORG deletes all work files created during the current operation other than DBKEYS files. It deletes only those files for which a matching data set model was specified either at setup or when the file was created. If a matching model is detected, REORG attempts to dynamically allocate the file thereby determining its data set name which may be derived from the model or overridden by a DD statement in the JCL. Regardless of how the data set name is determined, if the file is created during the execution of a REORG statement, it will be deleted during the cleanup phase of the operation unless the file is subsequently overridden with a different data set name in some later job. You can determine which files cleanup will delete by examining the work file summary sections of the REORG Status Report.

Should it be necessary to restart a REORG operation from the beginning, you should first execute a REORG statement that specifies CLEANUP to delete any work files created by the interrupted operation. If you do not do this, none of the work files created during the first operation execution will be deleted by REORG even if they are reused during the second execution.

If REORG is restarted without first cleaning up the old work files, you can still direct REORG to delete them using one of the following methods:

• You can allow REORG to reuse the old files and then after REORG has ended normally, run a REORG CLEANUP job with the DELETEALL option. This option directs REORG to delete all work files, other than DBKEYS files, whether they were created by the most recent REORG operation or not
• You can delete the old work files during the setup phase of the restarted run. Specify DELETE OLD WORKFILES during setup and REORG checks for and deletes any files it finds that match the file names it plans to use. This includes DBKEYS files. This approach is preferable when the old files may be too small to be reused.

  Note: For more information, see Considerations for running REORG on VSE.

Using DSMODELs with REORG

Data set models (DSMODELs) are used to specify a set of attributes for data sets. REORG can use DSMODELs to specify the attributes for its work files, thereby eliminating the need for coding DD statements for every work file used by the utility.

The REORG utility checks for the presence of DSMODELs during the setup phase. If they are present, REORG saves the model information in the control file for later use. This saved information is used by subsequent tasks and by other jobs. No additional DSMODEL statements need to be specified in any submitted or subsequent job.

When REORG creates a work file, either because a CREATE WORKFILE clause has been specified or because a file does not exist at the time it is accessed, REORG uses the saved model information unless another CREATE DSMODEL statement has been specified in the same session as the one in which the file is being created. If another CREATE DSMODEL statement has been specified, it overrides the previously saved information. REORG updates the control file with the new information and uses it to create the work file.

To use a data set model's attributes for a given work file, the model's name must match the file's DDNAME according to the rules discussed in the CREATE DSMODEL statement. The REORG utility uses the following DDNAME prefixes:

• WU—Unload/Reload work files
• WI—Index REBUILD work files
• WS—Sort output work files
• WD—DBKEYS work files

Each prefix is followed by a generated number. To use a model for a work file, the model name must match the file's DDNAME. If more than one DSMODEL matches that of a work file, the one that most closely matches is used. For information about how to specify model names that match character strings such as a DDNAME, see CREATE DSMODEL.

For the REORG utility to dynamically allocate a work file, its matching model must minimally specify a DSN attribute so that the name of the data set can be determined. Symbolic parameters in the DSN value can be used to generate different names for each work file.

For the REORG utility to create a work file, the DSMODEL must also include information to identify where to create the file, the space to allocate, and a block size to use.

When specifying a DSMODEL for a DBKEYS file, the BLKSIZE must be a multiple of 16. All other work files are variable length. The BLKSIZE for these files must be four bytes larger than the largest work record.

If a block size is not coded or BLKSIZE 0 is coded in the DSMODEL for a REORG file, REORG chooses one based on the device type. If the device type can not be determined, a 3390 will be assumed. Normally, 1/2 track blocking is used for a 3390 device.

Sizing work files

The simplest way to size work files is to let REORG do it for you. REORG automatically estimates the size of all files after making a pass of the database and gathering statistics. This occurs by default when the data is unloaded. While this does not require an extra pass of the data, the estimates that are generated can only be used for allocating RELOAD work files because the UNLOAD files have already been created and used.

To use REORG-generated estimates for allocating UNLOAD work files, use the ESTIMATE WORKFILE SIZES option. This directs REORG to make a preliminary pass of the data without opening or writing to any work files. The generated file estimates are stored in the control file and can be used to allocate both UNLOAD and RELOAD work files when the REORG operation is resumed.

For REORG to more accurately estimate the size of overflow files, it may be necessary to specify an OVERFLOW PERCENT parameter. REORG assumes that 10% of the records to be stored in the database will overflow. If this assumption is not valid for a particular database, you may need to specify a different overflow percent value so that REORG can generate better estimates for the size of overflow files.

While REORG attempts to accurately estimate the size needed for work files, it may not always be able to do so. In certain cases, it may be necessary to manually estimate the size needed for one or more work files.

Estimating the size needed for work files is difficult for two reasons: many classes of files contain different types of records, and the number of records written to each file within a class varies depending on how REORG chooses to divide the page ranges into slices. Consequently, there are no simple formulas that can be used to estimate work file sizes. There are however, some techniques that can be used to facilitate file sizing and allocation.

In planning for a reorganization, do one or more trial runs to determine the actual file sizes needed for a given n-WAY value. This can be done during a non-critical time against a copy of the source database. This is the easiest way to obtain accurate size estimates. If it is impractical to do a trial reorganization on a full copy of the database, do it on a reasonably-sized sample that is representative of the original and then scale up the work file sizes proportionately. Be sure that the sample database is large enough relative to the n-WAY parameter so that the slicing algorithm does not reduce the number of slices due to their small size. Size estimates determined using a sample database will not be as accurate as those determined using a full copy of the database and so should be increased to account for this.

The following is a list of additional techniques that may prove helpful in allocating work files under z/OS:

• Specify a relatively modest primary allocation and a large secondary allocation. This allows the file to extend to handle large amounts of information without wasting unneeded space.
• Use IBM's Storage Management Subsystem (SMS) to determine where files are to be allocated rather than trying to manually place files on specific volumes. SMS can automatically spread the files across volumes wherever there is available space. Use the DATACLAS and STORCLAS options to allow files to extend across multiple volumes.
• If SMS is not available, allow the files to be allocated across multiple volumes by specifying multiple volume serial numbers. There must be enough space across all listed volumes to satisfy the space needs of all of the work files. The order of the entries in the list is not important.
• Consider using extended format data sets for large work files. Although this adds 32 bytes of overhead to each block, extended format data sets can have more extents across more volumes than a basic format data set.

Under z/VSE it is recommended to not specify a primary space value, and let REORG calculate one. If this value is not large enough, or will not fit on the specified volume, a DLBL and EXTENT for the individual file should be manually coded to override the generated label.

Work file restrictions

You cannot use tape or virtual tape for work files.

Note: For more information about the types of work files used by the REORG utility, see the Classes of work files in REORG Processing Details.