Handling independent-software-vendor data in the data set VTOC entry

The 4-byte area beginning at offset X'4E' of the data set VTOC entry is defined as reserved with DFP releases prior to DFP Version 3. Starting with DFP Version 3, this field has been assigned meanings. Some customer accounts, however, have placed data into the field at offset X'4E', sometimes through ISV software. If altered data set VTOC entries are allowed to be interpreted by DFP Version 3 definitions, unpredictable results can occur.

Before installing DFP Version 3 on systems with altered data set VTOC entries, customers usually prevent problems on the user (level-0) volumes by clearing the field at offset X'4E'. Migrated and backed up data sets, however, must be handled differently. The following paragraphs tell how the DFSMShsm functions of migration and recall can be manipulated to handle the altered data set VTOC entries. The information can also be applied to the DFSMShsm functions of incremental backup and recovery, which are processed in a similar fashion.

When running in a DFP Version 2 environment, the unmodified code assumes that the data set VTOC entries have not been altered. If the fields at offset X'4E' have been altered but later cleared on the user volumes, the user should supply DFSMShsm with the cutover date when the fields were cleared. Then, when DFSMShsm recalls data sets, those data sets migrated before the cutover date will have the field at offset X'4E' automatically cleared by DFSMShsm. In cases where the customer has a temporary need to preserve the data at offset X'4E', a PATCH command can be used to turn on a bit that allows customers to recall the data set without the field being cleared. If this patch is used, it should be used in addition to setting the previously mentioned cutover date.

When running in a DFP Version 3 environment, the option to retain the altered field at offset X'4E' of the data set VTOC entry does not exist, but the option to specify a cutover date does. If the fields at offset X'4E' have been altered but later cleared on the user volumes, the user should supply DFSMShsm with the cutover date when the fields were cleared. DFSMShsm then ignores the values at offset X'4E' in the data sets migrated before the cutover date and will clear that field during DFSMShsm recalls of those same data sets. DFSMShsm uses the values in the field at offset X'4E' during the recall of data sets migrated on or after the cutover date.

The field that contains the cutover date is in the MCVT control block at offset X'444'. This field is shipped containing the date of January 1, 1970. In the following example, the PATCH command is used to set the cutover date to July 4, 1989:

PATCH .MCVT.+444 X'0089185F' VERIFY(.MCVT.+444 X'0070001F')

If you are running with DFP Version 2 on January 1, 1990 and you need to have the values in the altered DSCBs returned during recalls, then you need to set on the bit at offset X'431' of the MCVT. You also need to set the cutover date at offset X'444' of the MCVT. In the following example, two patches are applied. The first patch allows the data in the altered data set entries to be returned to the user during recalls. The second patch sets a cutover date of May 1, 1990, a date when the user expects to have all the altered data cleaned out of the data set VTOC entries.

PATCH .MCVT.+431 BITS(.....1..)


PATCH .MCVT.+444 X'0090121F' VERIFY(.MCVT.+444 X'0070001F')