Command migration is going to do what you tell it to do regardless of the SMS attributes. Why not let SMS manage these datasets?
Stan Weyman Senior Software Engineer [email protected] EMC² (508)249-3966 where information lives It is wise to keep in mind that neither success nor failure is ever final... -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of willie bunter Sent: Friday, November 19, 2010 9:01 AM To: [email protected] Subject: DFHSM MIGRATE MYSTERY Hallo To All, I came across a problem where dsns are not being migrated from a given Storage Group. The STORAGE GROUP is SMS managed but it is exempt from Auto Migrate. A batch job is executed weekly to manually migrate the dsns - below is the command : HMIG 'SYS2.B*.HISTORY.D*.T*' ML2 Below is the construct of this particular Management Class Expiration Attributes Expire after Days Non-usage . : 55 Expire after Date/Days . . . . : 55 Retention Limit . . . . . . . : NOLIMIT Migration Attributes Primary Days Non-usage . : 3 Level 1 Days Date/Days . : 0 Command or Auto Migrate . : BOTH When the batch job is executed all the dsns (these are all VSAM dsns) are migrated ML2 - including those that were created this morning before the migrate was done. According to the Migration Attributes shouldn't those dsns which were created today & yesterday not be migrated? Could someone help me understand where else I should look. Thanks in advance for your help. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
