General Page
This document highlights how DFSMShsm deletes migrated data sets in the cloud and how to clean up orphaned cloud objects.
How does DFSMShsm delete migrated data sets in the cloud?
DFSMShsm determines how migrated data sets in the cloud are deleted based on whether the retained MCA support is being utilized or not, i.e. what is specified in the clouddays parameter of the SETSYS MIGRATIONCLEANUPDAYS(recalldays statdays reconnectdays clouddays) command.
If retained MCA support not being utilized (i.e. SETSYS MIGRATIONCLEANUPDAYS(recalldays statdays reconnectdays 0) is specified) DFSMShsm deletes the old migration copy during the re-migration of the data set (ie, after the data set has been recalled and subsequently migrated). This deletion occurs in one of two modes:
- SYNCHRONOUS: The old migration copy of a data set is deleted before the re-migration of the data set proceeds (e.g. during space management, MIGRATE SG command, or MIGRATE DSN command processing). This is the default.
- ASYNCHRONOUS: The deletion of the old migration copy of a data set is started concurrently, but independently of the re-migration of the data set. This reduces the time it takes to migrate data sets to the cloud.
To instruct DFSMShsm to delete old migration copies from cloud asynchorously, use the below patch:
PATCH .MGCB.+113 BITS(...1....)
This feature can be disabled using the below patch:
PATCH .MGCB.+113 BITS(...0....)
Note: The MIGRATE DSN(dsname) command should not delete old copies from cloud asynchronously because MIGRATE DSN command is single threaded.
If retained MCA support is being utilized (i.e. SETSYS MIGRATIONCLEANUPDAYS(recalldays statdays reconnectdays clouddays) command, where clouddays is set to a value greater than 0):
- The clouddays parameter indicates the number of days that you want to keep old cloud migration copies of a data set around once a modified version of the same data set has been remigrated.
- An execution of secondary space management on an HSM that is cloud-enabled should clean up the old cloud migration copies after the specified clouddays has elapsed.
- As a side effect of specifying 0, after having a non-zero value for a time, all 'Retained MCA' records and the old cloud migration copies they describe should be deleted on the next execution of secondary space management.
Note: The MCD record of a no-longer-migrated data set that has multiple old migration copies in the cloud is not deleted until recalldays, reconnectdays (if applicable), and clouddays criteria ALL have been met. The presence of un-expired retained MCA versions will prevent the deletion of the control records even if recalldays and reconnectdays criteria have been met.
How can DFSMShsm cloud objects become orphaned?
A common way for DFSMShsm cloud objects to become orphaned is when the clouddays parameter in the SETSYS MIGRATIONCLEANUPDAYS command is set to 0 and DFSMShsm fails to scratch the old migration copy during the remigration of the data set.
An example scenario can be found in the following technote: ARC1582I Certificate validation error during a migrate to ML1/ML2 from a non-cloud enabled HSM instance within an HSMplex
Below are some APARs pertaining to the topic of orphaned cloud objects:
With clouddays = 0:
With clouddays > 0:
How to clean up DFSMShsm orphaned migration copies (objects) in the cloud?
There are two options to clean up orphaned migration copies in the cloud:
- Issue the AUDIT MEDIACONTROLS(CLOUD(cloudname)) NOFIX ODS('some_output_dsn') command and review the errors reported by DFSMShsm in the output and the reported orphaned migration copies in the cloud. If assistance is needed in reviewing the errors report, contact DFSMShsm Support. After reviewing the errors reported and verifying the fix actions generated by DFSMShsm are desired/expected, a subsequent AUDIT execution with the FIX parameter should delete the orphaned migration copies as well as resolve other errors surfaced in the output. If assistance is needed in reviewing the errors reported or questions arise about the errors reported, prior to issuing the AUDIT with the FIX parameter, contact DFSMShsm Support.
- Utilize the retained MCA support by specifying a clouddays value greater than 0 in the SETSYS MIGRATIONCLEANUPDAYS(recalldays statdays reconnectdays clouddays) command. An execution of secondary space management on an HSM that is cloud-enabled should clean up the old cloud migration copies after the specified clouddays has elapsed.
[{"Type":"MASTER","Line of Business":{"code":"LOB56","label":"Z HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG90","label":"z\/OS"},"ARM Category":[{"code":"a8m0z0000000A1mAAE","label":"DFSMS-\u003EHSM-\u003EGeneral"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"2.3.0;2.4.0;2.5.0;3.1.0;3.2.0"}]
Was this topic helpful?
Document Information
Modified date:
14 July 2025
UID
ibm17237306