DFSMShsm delays migration for any non-SMS-managed data sets that have been processed by the JES3 setup function. By delaying their migration, DFSMShsm ensures that non-SMS-managed data sets are not migrated between the time that they are processed by JES3 setup and the time that the job is actually run.

DFSMShsm controls migration prevention of non-SMS-managed data sets that have been processed by the JES3 setup function by accepting the defaults for the MCVTJ3D byte. The defaults also apply to the period of time that a recalled data set is prevented from migrating.

The DFSMShsm default for this byte is X'03', which means that migration is prevented for the remainder of the processing day plus three more days. Through the delayed migration DFSMShsm ensures the data integrity of non-SMS-managed data sets in a JES3 environment. Without the migration delay, the small possibility exists of a data integrity problem.

There can be a data integrity problem only if the following sequence of events has occurred:

1. On a system not using a global resource serialization (GRS) function for the SYSDSN resource, job 1 goes through JES3 setup referring to a particular nonmigrated data set.
2. The subject data set is migrated before job 1 runs and before job 2 goes through JES3 setup.

   The minimum age to be eligible for migration in this nonglobal resource serialization environment is one complete day plus the remainder of the day on which the JES3 setup has occurred. Most jobs run before the data set has aged enough to be selected by automatic volume migration. Instances of the subject data set migrating before job 1 runs are most likely caused by command migration.

3. Job 2 goes through JES3 setup and also refers to the subject data set, but now the subject data set is in the migrated state. As a result, DFSMShsm returns a list of volumes to JES3 that is different from the list provided for job 1.
4. JES3 performs its data set reservation function but sees this single data set as two different data sets, because the combinations of data set name and volume serial numbers are different.
5. Jobs 1 and 2 run on different CPUs concurrently. An update is lost when the subject data set is accessed in the following sequence:
   1. Read for update from one CPU.
   2. Read for update from the other CPU.
   3. Write the first update from one CPU.
   4. Write the second update (over the top of the first update) from the other CPU.

   The preceding is known as a read, read, write, write sequence.

There can be times that you do not want DFSMShsm to prevent migration. For example, users who are severely constrained on DASD space can benefit from preventing or shortening the duration of the migration-prevention activity. Without the migration-prevention activity, users who know that particular groups of data sets do not need to be accessed in the immediate future are able to command migrate those groups of data sets.

Another possible benefit in not having migration-prevention activity could be in performance. A significant amount of I/O to the MCDS is related to migration prevention activity; without migration prevention, the system would be free of those I/O tasks.

PATCH .MCVT.+14A X'00' VERIFY(.MCVT.+14A X'03') /*no JES3 migration prevention*/

PATCH .MCVT.+14A X'01' VERIFY(.MCVT.+14A X'03') /*delay migration for 1 day*/