Serialization

The DEFRAG command serializes access to the VTOC. The DEFRAG command releases this serialization before it generates the ending statistics provided by message ADR213I. Therefore, the information in message ADR213I may not reflect the state of the volume at the completion of DFSMSdss processing because another job may allocate or delete data sets on the processed volume between the time the serialization is released and the ending statistics are obtained. The serialization scheme is described in z/OS DFSMSdfp Storage Administration.

The DEFRAG command does a RESERVE on the VTOC to serialize access to the VTOC. The DEFRAG command also serializes access to each data set before relocating the extent of a data set. The enqueue scheme used by the DEFRAG function ensures integrity on a single processor but does not ensure integrity for data sets on DASD shared between processors. This is due to the use of an ENQ scope of SYSTEM for the SYSDSN resource name. To ensure the integrity of data sets on a shared DASD, you must do one of the following:

Vary the volume offline from all processors except the one on which DEFRAG runs. After the DEFRAG function finishes, you can vary the volume back online for the other processors.
In either a JES2 or a JES3 environment, you can use multisystem GRS (or equivalent function) to convert the scope of all enqueues with a resource name of SYSDSN from SYSTEM to SYSTEMS by placing SYSDSN in the GRS SYSTEM INCLusion resource name list (RNL). This allows all systems in the GRS ring to be made aware of all SYSDSN enqueues. The default GRS System Inclusion RNL includes SYSDSN. However, ensure that this has not been changed on your system before using the DEFRAG command on a volume shared between two or more processors.
Note: GRS must not be used to convert the scope of any of DEFRAG function’s SYSTEMS enqueues (including SYSVSAM) to SYSTEM by placing the resource names in the GRS RNL. GRS may, however, be used to convert DEFRAG function’s RESERVE on SYSVTOC to a simple enqueue with a scope of SYSTEMS by including it in the GRS "RESERVE CONVERSION RNL". If you choose not to do this, you can avoid doing two global serializations on the volume’s VTOC by placing SYSVTOC in the GRS Systems Exclusion RNL, thus changing RESERVE’s global enqueue to a local enqueue. For the restrictions that apply to enqueues and dequeues, see z/OS MVS Planning: Global Resource Serialization. The DYNALLOC serialization mechanism of DFSMSdss does not solve all cross-system serialization problems. GRS (Global Resource Serialization) is recommended with shared DASD.
If you are running on a system using JES2 and are not using multisystem GRS (or equivalent function), you can use DEFRAG function’s BY filtering to specifically include or exclude data sets from processing. Both creation date and last-referenced date criteria are needed to ensure that only those data sets that are not in use are selected for DEFRAG function processing. For example, if you choose to defragment a volume with typical TSO or batch data sets, you could select only those data sets that were created and referenced at least twenty-four hours previously, using a selection age of two days. Two days should be a minimum selection age because of the level of precision of the creation date.
In the following example, data set A.B.C is created two minutes before the DEFRAG function begins.
```
TIME OF DAY     ACTION
     2359         Create data set A.B.C
      .
      .
     0001         Begin DEFRAG BY(LIST(CREDT LE *,-1)).  Data set A.B.C is selected
                  because it has now been one day since creation
```
Because there is a date change between the two actions, A.B.C is selected for the DEFRAG operation.
Using a two-day delay enforces a convention that more than twenty-four hours must pass before a data set is eligible for DEFRAG. In an environment with TSO and batch data sets, the probability that one of these data sets will be open more than twenty-four hours is low. The following example uses a two-day delay to cause DEFRAG processing only for those data sets on volume SHARE3 that were created and referenced more than twenty-four hours previously and that are not temporary data sets.
```
DEFRAG BY(LIST((CREDT LE *,-2),(REFDT LE *,-2))) -
       EXCLUDE(LIST(SYS8*.T*.**)) DYNAM(SHARE3)
```
The two-day criterion is probably sufficient for TSO and batch type data sets. However, if there are applications that use the volumes being defragmented, consider setting the delay time to the maximum time that the application would have a data set open.
If you are running on a system using JES3 with MDS enabled and are not using multisystem GRS (or equivalent function), you can use the DEFRAG command DYNALLOC keyword to provide serialization for data sets on shared DASD.
Note: Not all data sets allocated within a JES3 environment are known to the global. The use of the DYNALLOC keyword does not provide cross-system serialization for these data sets.
- Allocation of existing (old) data sets whose names appear in the RESDSN and DYNALDSN lists are not protected by the DYNALLOC serialization mechanism of DFSMSdss. DEFRAG processing for these data sets can be prevented by placing their names (or filters for the names) in the EXCLUDE LIST for the DEFRAG command.
- New data sets created with nonspecific allocation (no volume serial supplied) are not protected by the DYNALLOC serialization mechanism of DFSMSdss. However, you can use BY filtering with the DEFRAG command to specifically include or exclude data sets from processing. In the following example, the DEFRAG function processes only those data sets on volume SHARE3 that were created more than two days before.
```
DEFRAG BY(LIST(CREDT,LT,*,-2)) DYNALLOC DYNAM(SHARE3)
```
  You can also use the EXCLUDE parameter to avoid processing data sets that were created by long-running programs or subsystems more than twenty-four hours previously but that are still allocated. In the following example, if the newly created data sets are temporary, the DEFRAG operation processes only those data sets on volume SHARE3 that were created more than two days before and are not temporary data sets.
```
DEFRAG BY(LIST(CREDT,LT,*,-2)) -
       EXCLUDE(LIST(SYS8*.T*.**)) DYNALLOC DYNAM(SHARE3)
```

You can ensure successful DEFRAG processing of volumes having a significant number of free or allocated extents by specifying appropriate SIZE and REGION parameters in the EXEC statement. If you receive a message that the region size is not large enough, specify a larger region size in the EXEC or JOB statement and rerun your job.

Note: During DEFRAG processing, a data set VTOC entry with the unique name “SYS1.DFDSS.DEFRAG.xxxxxxxx.volser.DUMMY” is allocated on the volume being defragmented. This data set is not cataloged but is automatically deleted after a successful run. If a job is canceled or abnormally ends, this data set remains on the volume. After the restart, DADSM functions might fail with message IEC602. To correct this problem or to delete the “SYS1.DFDSS.DEFRAG.xxxxxxxx.volser.DUMMY” entry, rerun the DEFRAG function on the volume.