Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see REORG PLUS for DB2 13.1.

Allocating dynamic data sets

When dynamic allocation is active, REORG PLUS calculates the optimal size and number of data sets and allocates them for you. REORG PLUS can also delete the work files.

Dynamic allocation has the following benefits:

  • It reduces or eliminates the need to specify DD statements for these files in your JCL.
  • You spend less time performing analysis to set up optimized JCL for REORG PLUS jobs.
  • You do not need to modify the JCL for the REORG PLUS job as Db2 objects change size or structure over time.

Related topics

Using

You activate data set allocation through command syntax or installation option defaults.

Important

When REORG PLUS invokes DSNUTILB, you must enable dynamic allocation for the required data sets. You can use some of the options described in this topic to control the dynamic allocation of these data sets. However, DSNUTILB handles the allocation, so the allocation process is different from that described in this topic.

REORG PLUS performs duplicate data set checking at data set allocation time. In a two-phase reorganization, dynamic allocation occurs at the beginning of the UNLOAD phase. In a single-phase reorganization, dynamic allocation occurs at the beginning of the REORG phase.

You can specify any of the following files to be dynamically allocated:

  • Unload data files (SYSREC)
  • Index work files (SYSUT1)
  • Sort work files (SORTWK)
  • Archive files, or discard files for DSNUTILB jobs (SYSARC)
  • LOAD control statement data sets for DSNUTILB jobs (SYSPUNCH)
  • Full copy data sets (BCPY, BCPZ, BRCY, and BRCZ)
  • Incremental copy data sets (BICY, BICZ, BIRY, and BIRZ)

For information about allocating a particular data set type, see REORG-PLUS-DD-statements.

Enabling dynamic allocation in REORG PLUS

To enable and use dynamic data set allocation quickly and simply, specify ACTIVE YES on your REORG PLUS command or in your installation options for each DDTYPE to dynamically allocate.

For more options that you can use with dynamic allocation, see Dynamic-allocation-options-for-REORG-PLUS.

Using dynamic allocation in a worklist environment

When running in a worklist environment, the utility ignores the ACTIVE option in your installation options module. The utility dynamically allocates your data sets only if the invoking product (DASD MANAGER PLUS, CATALOG MANAGER, or CHANGE MANAGER) supplies the ACTIVE YES syntax. 

Generating data set names in REORG PLUS

You can use the data set name pattern (DSNPAT) option to specify a pattern to generate a unique data set name. For some files, you can use a generation data group (GDG) name as the data set name.

Names created with DSNPAT

You can use the DSNPAT installation or command option to specify text and variable data for building data set names. If you cannot construct a data set name that meets your organization’s standards by using the text and the supplied variables, you can use the exit point supplied by the utility to create your own variables for use with DSNPAT. Sample exits written in assembler, COBOL, C, and LE C are described in REORG-PLUS-user-exits and are provided in the HLQ.LLQSAMP library. (HLQ is the high-level qualifier specified during installation, and LLQ is the low-level qualifier or prefix set during installation.)

The pattern that you specify in your DSNPAT option must allow REORG PLUS to generate unique data set names. For multiple SYSUT1 files, you must include the &DDNAME variable to generate unique names. For copy data sets, you might need to include additional variables, such as &VCAT, &DATEJ, or &TIME4, to generate unique names across multiple reorganizations. If REORG PLUS encounters non-unique data set names, it terminates the job.

GDG names

You can use names for your dynamically allocated full and incremental copy data sets and for your SYSARC and SYSPUNCH files. Each DDTYPE must have a different GDG base.

GDG name format

The GDG format that you use to construct data set names is the same as the format that you use in JCL to allocate data sets through DD statements: you append the generation number in parentheses. The open parenthesis tells REORG PLUS that the pattern is a GDG name. The generation number must be an integer from 1 through 255.

An example of a GDG name is &TS.(+1). If you are using a substitution variable as the last variable before the open parenthesis, you must include a period before the open parenthesis.

GDG base

REORG PLUS has the following requirements for the number of GDG bases that you specify:

  • Each DDTYPE must have a different GDG base.
  • For copy data sets, each partition must have a different GDG base if you specify COPYLVL PART on the REORG command.

If the base does not exist, REORG PLUS creates it for you, using everything in the pattern up to the open parenthesis as the base name.

When defining the base, REORG PLUS uses the values of the following options:

  • The GDGLIMIT installation or command option allows you to specify the number of generations to keep.
  • If the GDGLIMIT value is exceeded, the GDGEMPTY option tells the system to uncatalog either all preexisting generations of this data set or only the oldest generation.
  • The GDGSCRATCH installation option tells the system whether to delete the entry that was just uncataloged from the volume’s table of contents (VTOC). If the entry is deleted, the space on the volume becomes available to other users.

For more information, see the installation option descriptions in REORG-PLUS-installation-options. 

Specifying ddname prefixes

If you specify more than one ddname prefix for dynamic allocation, the prefix for each ddname must be different enough for the product to differentiate one prefix from another.

To be different enough, if these prefixes are different only because one prefix has additional trailing bytes, then these trailing bytes must contain at least one non-numeric byte. For example, the first set of prefixes that follow is sufficiently different, but the second set is not:

  • Acceptable set:

    BMCRD
    BMCRDWK

  • Not acceptable set:

    BMCRD
    BMCRD11

The prefixes that you specify must allow the utility to add the data set number (or partition number in the case of copy data sets) and still result in a valid ddname of eight characters. If the generated name would result in a ddname of less than eight characters, the utility pads the data set or partition number with leading zeros. The following table shows an example of how the prefixes that you specify resolve to the generated ddnames.

Prefix specified for SYSUT1 data sets

Number of data sets

Generated ddnames

SYSOUT1

9

SYSOUT1...SYSOUT9

SYSOUT1

10

None (invalid length)

WORK

10

WORK0001...WORK0010

Deleting dynamically allocated data sets

To delete dynamically allocated data sets, specify DELETEFILES YES on your REORG command. You can also specify this preference with the DELFILES installation option.

After the job completes successfully, REORG PLUS automatically deletes the work files that it dynamically allocated and those allocated in your JCL. If you do not specify DELETEFILES YES, you must manually delete the dynamically allocated work files when your reorganization completes successfully. DELETEFILES YES does not apply to image copy data sets that REORG PLUS dynamically allocates.

The SYSPRINT from your REORG PLUS job contains a report of the dynamically allocated work files. When you need to manually delete work files, you can use this report to determine which files to delete.

Dynamically allocating different properties for larger and smaller data sets

You can use the THRESHLD option and associated dynamic allocation options to tell the utility to use different properties for larger and smaller data sets. Data set allocations that exceed the threshold value then use the values for the second parameter of applicable dynamic allocation options.

Example

Use the following options to tell the utility to send data sets greater than 720 MB to tape device TAPE1, and smaller data sets to DASD device SYSDA:

UNIT(SYSDA,TAPE1)
THRESHLD 720000

(BMC.DB2.SPE2401)Dynamic allocation for SYSCOPY data sets is based on the results of analysis of the target table space or index space object high-used RBA (HURBA) catalog value and any modifications to a PBG object that can set the HURBA value to zero forces the primary and secondary estimated allocation sizes to be based on DSSIZE instead of HURBA value might cause undesirable results when switching SYSCOPY device type properties based on the THRESHLD value. For more information, see the THRESHLD option description.

Using SMS ACS routines to influence dynamic allocation

If your SMS automatic class selection (ACS) routines use the UNIT parameter to influence data set allocation, you can use the SMSUNIT option in the utility to affect that use.

The value of the SMSUNIT option affects the UNIT value as follows:

  • When you specify SMSUNIT YES, the utility passes the UNIT option to SMS allocation in addition to passing the SMS class options and other normally passed options.
  • When you specify SMSUNIT NO, the utility does not pass the UNIT option. 

Reaching the MAXTAPE limit during dynamic allocation

When UNIT and THRESHLD specifications require that the utility dynamically allocate tape units, allocation occurs in the following priority order:

  1. The utility attempts to allocate the greatest number of tape units required that will optimize multitasking.

  2. If this number of tape units exceeds the MAXTAPE value, the utility decreases the multitasking level until the number of tape units required is less than or equal to the MAXTAPE value.

    This action might result in the utility dynamically allocating a single SYSUT1 data set, rather than one data set for each non-data-sorting index (thus decreasing multitasking).

  3. If the minimum number of tape units required exceeds the MAXTAPE value, the utility issues a message and terminates.

The value that you specify for the MAXTAPE option includes the units that are required for full and incremental copies, including copies, and unload data sets for potential new partition-by-growth (PBG) partitions as indicated by the MAXNEWPARTS specification. Also, if Work and Archive data sets are directed to tape, MAXTAPES must include them.

When calculating MAXTAPE value for partition-by-growth (PBG) table spaces, the number of data sets is considered not only for the active partitions, but also the potential new partitions specified by MAXNEWPARTS value in syntax or options module.

Changing dynamic allocation options on restart in REORG PLUS

Before restarting a job, you might need to change the options that affect dynamic data set allocation. For example, if specifying an invalid UNIT or overly restrictive MAXTAPE value causes the job to terminate, you need to change the relevant option before restarting the job.

The following restrictions apply to changes that you make to dynamic allocation options before restarting a job:

  • You cannot change the value for the ACTIVE option on any restart.
  • Changing any option on restart such that it results in different ddnames or a different number of DDs than the original option can produce an error. If you need to change the number of SYSREC and SYSUT1 work files, resubmit the job with a parameter of NEW.
  • To change the value of other dynamic data set allocation options, specify RESTART(PHASE).

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*