Release Notes
Abstract
This document highlights recommendations related to improving the DFSMShsm transparent cloud tiering (TCT) Migration to Cloud experience.
Content
Ensure the initial TCT maintenance is installed.
Once the initial maintenance is installed, always ensure the latest maintenance is installed which can be found using the following FIXCAT category: IBM.Function.DFSMSCloudStorage and DFSMSCS/K.
The following PTFs provide improvements with patch commands allowing users to tune their environment:
1. A limited number of large data sets can be migrated to the cloud at the same time. If this number is exceeded, large data sets are skipped. These large data sets are revisited later when the currently processing large data sets completes. When only the large data sets remain to process, DFSMShsm will wait this interval before the next scan.
The following PATCH can be used to change this interval.
PATCH .MGCB.+152 X'nnnn'
Where nnnn - the time in seconds.
The default value is X'001E' (30 seconds).
The following PATCH can be used to change this interval.
PATCH .MGCB.+152 X'nnnn'
Where nnnn - the time in seconds.
The default value is X'001E' (30 seconds).
2. Set the interval for issuing the Disk controller busy, ARC1587I, message:
An ARC1587I message indicates that all disk controller cloud data movement threads are busy for a specified number of seconds. The following PATCH can be used to change the interval in which the message is issued:
PATCH .MGCB.+164 X'nnnn'
Where nnnn - the time in seconds.
If this value is set to X'7FFF', no interval checking is executed and no ARC1587 messages are issued.
The default value is X'7FFF'.
3. Setting the maximum wait time in seconds to get a disk controller for moving data to the cloud:
You can set the maximum wait time in seconds to get a disk controller cloud data movement thread lock. Space Management for a volume terminates, when a disk controller cannot be reserved within the allotted time. When the wait time is exceeded, message ARC0535I is issued and volume processing is terminated.
The following patch can be used to tune the wait time:
PATCH .MGCB.+9A X'nnnn'
Where nnnn is the time in seconds.
If this value is set to X'7FFF', no interval checking is executed and Space Management of a volume is not be terminated. The default value is X'7FFF'.
An ARC1587I message indicates that all disk controller cloud data movement threads are busy for a specified number of seconds. The following PATCH can be used to change the interval in which the message is issued:
PATCH .MGCB.+164 X'nnnn'
Where nnnn - the time in seconds.
If this value is set to X'7FFF', no interval checking is executed and no ARC1587 messages are issued.
The default value is X'7FFF'.
3. Setting the maximum wait time in seconds to get a disk controller for moving data to the cloud:
You can set the maximum wait time in seconds to get a disk controller cloud data movement thread lock. Space Management for a volume terminates, when a disk controller cannot be reserved within the allotted time. When the wait time is exceeded, message ARC0535I is issued and volume processing is terminated.
The following patch can be used to tune the wait time:
PATCH .MGCB.+9A X'nnnn'
Where nnnn is the time in seconds.
If this value is set to X'7FFF', no interval checking is executed and Space Management of a volume is not be terminated. The default value is X'7FFF'.
4. Setting the minimum size of a large data set:
The data set is considered as "large", when its size is larger than this value in the MCVT. The following patch can be used to tune this value:
PATCH .MCVT.+5AC X'nnnnnnnn'
Where nnnnnnnn is a data set size in tracks.
The default value is X'000186A0' (100000) tracks.
The data set is considered as "large", when its size is larger than this value in the MCVT. The following patch can be used to tune this value:
PATCH .MCVT.+5AC X'nnnnnnnn'
Where nnnnnnnn is a data set size in tracks.
The default value is X'000186A0' (100000) tracks.
5. Setting the minimum number of small data set threads for moving data to the cloud:
Since there is a limited number of CEC threads for data movement, DFSMShsm prevents large data sets from consuming all threads and preventing any small data sets from being processed. As a default, DFSMShsm reserves one thread out of the maximum number of threads in a CEC to process small data sets.
Since there is a limited number of CEC threads for data movement, DFSMShsm prevents large data sets from consuming all threads and preventing any small data sets from being processed. As a default, DFSMShsm reserves one thread out of the maximum number of threads in a CEC to process small data sets.
If it is known that only large data sets are to be processed, this value can be patched to '0'. A large data set is one that exceeds the default value of 100,000 tracks or the customer defined value in the MCVT+5AC. A patch value of '0' enables DFSMShsm to use all CEC threads for processing large data sets without concern for blocking out small data set processing.
The following patch can be used to tune this value:
PATCH .MCVT.+3CE X'nnnn'
Where nnnn is a number of small data sets. The default value is X'0001'.
The following patch can be used to tune this value:
PATCH .MCVT.+3CE X'nnnn'
Where nnnn is a number of small data sets. The default value is X'0001'.
6. Allowing DFSMShsm to trace threads checking and reservation during migration to cloud storage:
By default, threads checking and reservation traces are not written during migration to cloud storage. To enable this option, apply the following patch:
PATCH .MCVT.+24F BITS(...1....)
This processing can be reversed or disabled by issuing the following patch:
PATCH .MCVT.+24F BITS(...0....)
By default, threads checking and reservation traces are not written during migration to cloud storage. To enable this option, apply the following patch:
PATCH .MCVT.+24F BITS(...1....)
This processing can be reversed or disabled by issuing the following patch:
PATCH .MCVT.+24F BITS(...0....)
7. Defining MIGRATE STORAGEGROUP command behavior:
MIGRATE STORAGEGROUP command migrates the eligible data sets on the volumes in one or more storage groups. When the MIGRATE STORAGEGROUP command is issued, DFSMShsm reads the SMS storage group definition and determine the list of volumes defined by this storage group. Next, the data sets residing on these volumes are processed in a similar way to automatic migration processing.
By default the main differences are:
MIGRATE STORAGEGROUP command migrates the eligible data sets on the volumes in one or more storage groups. When the MIGRATE STORAGEGROUP command is issued, DFSMShsm reads the SMS storage group definition and determine the list of volumes defined by this storage group. Next, the data sets residing on these volumes are processed in a similar way to automatic migration processing.
By default the main differences are:
- Volumes can be processed several times a day.
- In a multihost environment, the command can go into a wait state up to 5 minutes if the volume required for processing is reserved by another host.
The following patch can be applied to provide MIGRATE STORAGEGROUP command behavior that is fully consistent with automatic migration:
PATCH .MGCB.+113 BITS(..1.....)
This processing can be reversed or disabled by issuing the following patch:
PATCH .MGCB.+113 BITS(..0.....)
This processing can be reversed or disabled by issuing the following patch:
PATCH .MGCB.+113 BITS(..0.....)
8. Allowing DFSMShsm automatic functions or MIGRATE STORAGEGROUP command to process volumes other than once per day:
Running MIGRATE STORAGEGROUP command multiple times a day
If MIGRATE STORAGEGROUP command behavior is fully consistent with automatic migration (by the patch applied) and DAYS(0) or MOVE parameter is not specified, the volumes can be processed only once every 14 hours. In this case, the tuning of MIGRATE STORAGEGROUP command processing is the same as automatic primary space management of SMS volumes.
If MIGRATE STORAGEGROUP command behavior is fully consistent with automatic migration (by the patch applied) and DAYS(0) or MOVE parameter is not specified, the volumes can be processed only once every 14 hours. In this case, the tuning of MIGRATE STORAGEGROUP command processing is the same as automatic primary space management of SMS volumes.
MIGRATE STORAGEGROUP command with DAYS(0) or MOVE parameter can process the volumes once every 3 hours and 59 minutes.
If MIGRATE STORAGEGROUP command with DAYS(0) or MOVE parameter completed and you want to start this command again, use the following patch:
PATCH .MCVT.+5B0 X'nnnnnnnn' /* Minimum time between */
/* MIGRATE SG() command with */
/* DAYS(0) or MOVE parameter */
/* (Number in seconds) */
If MIGRATE STORAGEGROUP command with DAYS(0) or MOVE parameter completed and you want to start this command again, use the following patch:
PATCH .MCVT.+5B0 X'nnnnnnnn' /* Minimum time between */
/* MIGRATE SG() command with */
/* DAYS(0) or MOVE parameter */
/* (Number in seconds) */
Example of redefining an interval for MIGRATE STORAGEGROUP command with DAYS(0) or MOVE parameter of SMS volumes processing
There are times when a user wants to modify the definition of a minimum time between volume processing to occur more often or less often. By changing the bytes that define the minimum amount of time between volume processing, you can permit MIGRATE STORAGEGROUP command with DAYS(0) or MOVE parameter to be performed at a different frequency. For example, a user might want a volume to be processed more frequently than 3 hours and 59 minutes. In order to define the minimum interval of 30 minutes, you must apply the following patch:
PATCH .MCVT.+5B0 X'00000708' VER(.MCVT.+5B0 X'00003804')
9. Setting the wait Interval before the next SSL checking will be executed during migration to cloud storage when multiple migration subtasks are enabled.
The following patch can be used to change the interval in seconds before the next migration subtask will start to migrate the first data set to cloud storage.
PATCH .MGCB.+166 X'nnnn'
Where nnnn - the time in seconds.
If this value is set to X'0000', the next migration subtask will not wait before data set processing. The default value is X'0000'.
Example:
Subtask1 starts immediately, Subtask2 starts 60 seconds after the first, Subtask3 starts 120 seconds after the first, Subtask4 starts 180 seconds after the first, and so on.
There are times when a user wants to modify the definition of a minimum time between volume processing to occur more often or less often. By changing the bytes that define the minimum amount of time between volume processing, you can permit MIGRATE STORAGEGROUP command with DAYS(0) or MOVE parameter to be performed at a different frequency. For example, a user might want a volume to be processed more frequently than 3 hours and 59 minutes. In order to define the minimum interval of 30 minutes, you must apply the following patch:
PATCH .MCVT.+5B0 X'00000708' VER(.MCVT.+5B0 X'00003804')
9. Setting the wait Interval before the next SSL checking will be executed during migration to cloud storage when multiple migration subtasks are enabled.
The following patch can be used to change the interval in seconds before the next migration subtask will start to migrate the first data set to cloud storage.
PATCH .MGCB.+166 X'nnnn'
Where nnnn - the time in seconds.
If this value is set to X'0000', the next migration subtask will not wait before data set processing. The default value is X'0000'.
Example:
Subtask1 starts immediately, Subtask2 starts 60 seconds after the first, Subtask3 starts 120 seconds after the first, Subtask4 starts 180 seconds after the first, and so on.
PERFORMANCE RECOMMENDATIONS:
- OA63678: NEW FUNCTION- TCT PERFORMANCE IMPROVEMENTS APAR OA63678 is a new performance improvement that allows users to specify how long to keep old cloud migration copies of data sets. The new feature is enabled through the use of DFSMShsm's SETSYS MIGRATIONCLEANUPDAYS command:
- SETSYS MIGRATIONCLEANUPDAYS (recalldays statdays reconnectdays clouddays)
The deletion of old cloud migration copies will now occur only during Secondary Space Management (SSM) and not during the migration of the data set to the cloud such as MIGRATE DSN or MIGRATE SG or Primary Space Management (PSM).- If users previously used the patch listed in OA59765 to turn on the asynchronous deletion of migration copies from the cloud may now turn this patch off.
- The patch was: HSEND PATCH .MGCB.+113 BITS(...1....)
- To turn this off, use this patch command: HSEND PATCH .MGCB.+113 BITS(...0....) and patch can be removed from ARCCMDxx parmlib member.
- If users previously used the patch listed in OA59765 to turn on the asynchronous deletion of migration copies from the cloud may now turn this patch off.
- SETSYS MIGRATIONCLEANUPDAYS (recalldays statdays reconnectdays clouddays)
- Enable Migration Subtasking with the following SETSYS command:
SETSYS MIGRATIONSUBTASKS(YES)
ADDITIONAL GENERAL RECOMMENDATIONS:
- OA60278 NEW FUNCTION APAR for DFSMSHSM TRANSPARENT CLOUD TIERING FULL VOLUME DUMP AND RESTORE SUPPORT Please notice that this new function apar changed DFSMShsm's default container creation cycle to 92 days from the previous default of 7 days. Users who have been using the previous patch to change the container creation value to a value higher than 7, may now remove the patch statement from their ARCCMDxx parmlib member as the new default is 92.
- Set a unique plex name per HSMplex with the following SETSYS command:
SETSYS PLEXNAME(plexname) - Separate cloud work with the following SETSYS command:
SETSYS MIGRATIONAUTOCLOUD(NOCLOUD | CLOUDONLY)
- TESTING MIGRATION TO CLOUD
The MIGRATE DSN command is a single threaded command. This is not a proficient means of testing migration to cloud. Instead, use the MIGRATE STORAGEGROUP DAYS(0) or MOVE parameter so the volumes are distributed equally across the CECs.
OTHER CONSIDERATIONS:
- Large data sets will take a long time to go to the cloud. Please be patient!
- Be sure to know your average throughput going to your cloud provider.
- If DFSMShsm seems stalled or seems to not be progressing, make sure to have the ENABLE(AOM496I) parameter in DEVSUPXX parmlib member set. The AOM496I status message will go to the console for transparent cloud tiering operations. It is disabled by default. More information on this can be found in the z/OS MVS Initialization and Tuning Reference.
- When a user cancels a "stalled" HSM task, it cancels the task in the z/OS host but it does not cancel the DS8K thread moving the data set to the cloud.
- The new patches are documented in the DFSMShsm Implementation and Customization Guide book under Tuning Patches Supported by HSM.
- Always run with the latest maintenance which can be found using the following FIXCAT category: IBM.Function.DFSMSCloudStorage and DFSMSCS/K.
[{"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":"a8m0z0000000AHoAAM","label":"DFSMS-\u003EHSM-\u003EMigration"}],"Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
05 June 2024
UID
ibm16468023