Check the migration log. There are many possible reasons for a dataset not to migrate.
ARC0734I present you with a return code and reason code for each action taken. Lookup the ARC0734I will refer you to another ARC12xx or ARC13xx message that contains the detailed explanation based to the return and reason codes. Common retcodes that show up in my shot are 8, 37, 19, 20, 99 8 - dataset too large for ML1 migration 37 - insufficient space on ML1 for dataset 19 - data set in use 20 - invalid file (usually a null file or invalid dsorg) 99 - other, in my case the other sysprog APF auths a "personal" dataset for testing. HTH, <snip> I have noticed that a storage pool has dsns which go back to 2 months even thought the management class is set to 3 days. On this partition we have HSM running however there is no ML2 migration, however migration is turned on : Auto Migrate . . Y (Y, N, I or P) Auto Backup . . Y (Y or N) Auto Dump . . . N (Y or N) Overflow . . . . N (Y or N) PRIMARY, SECONDARY & INTERVAL SPACE management kicks off at the designated times. Could it be that space management is ignoring some of the volumes in the pool because of the migration threshold? This is what it is set to: Allocation/migration Threshold : High . . 75 (1-99) Low . . 3 (0-99) Alloc/Migr Threshold Track-Managed: High . . 85 (1-99) Low . . 1 (0-99) Below are the Expiration Attributes of this management class: Expire after Days Non-usage . : 3 Expire after Date/Days . . . . : 3 Retention Limit . . . . . . . : 0 If this is the case (migration threshold) how could I have HSM perform a clean up of these datasets which are over 3 days old? If this is not the case could someone tell me where else I should look? </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
