For the volumes outside the storage group, it did. IBM is looking to see if it took DAYS(0) as a default.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Hervey Martinez Sent: Wednesday, January 23, 2019 1:35 PM To: [email protected] Subject: Re: HSM Migrate Storagegroup Command APAR OA56695 Hi Chuck, So, what you're saying is that the command ignored management class attributes for each of these files? Hervey -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Chuck Kreiter Sent: Wednesday, January 23, 2019 1:14 PM To: [email protected] Subject: HSM Migrate Storagegroup Command APAR OA56695 My firm was recently hit with a bug in the MIGRATE STORAGEGROUP command. When issued, HSM began migrating the storage group requested but then moved on to other volumes in different storage groups. We discovered this after several CICS datasets were migrated while the region was down and the restart was delayed for recalls. I just wanted to pass this along to those who use this command. The APAR describes running MIGRATE STORAGEGROUP commands on a system that runs primary space management. However, we hit this on a system that doesn't run primary space management as well. From the dump of HSM on this system, IBM discovered the SMS VT had thousands of volumes in it rather than just the ones in the SG selected for migration. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
