Nice one Rex, Appendix B shows.......
MIGRATED │ MIGDS │ This is the number of data sets that has │ │ DS--TRKS │ MIGTRKS │ been migrated or deleted from the volume │ │ │ │ during the last volume space management. │ │ │ │ Tracks are not applicable for level 0 │ │ │ │ volumes and are excluded with asterisks │ │ │ │ (*). Both fields are only applicable for │ │ │ │ the last VOLUME request, not for a LEVEL │ │ │ │ request like secondary space management. │ ├─────────────────┼─────────────────┼─────────────────────────────────────── ─── so it's got nowt to do with how many Migrated Datasets are on the volume. That's what's been throwing me. many thanks for that. As for SSM not working, I've just looked at the AUTOMIG defs for our DASD SG's and find that 18 out of 21 are set to NO, 2 of the remaining 3 have 99% free space (I said it's a datamover so wouldn't expect much HSM activity) and the other has a low threshold of 50%. VTOC's and MCDS both low. Final question......Surely SSM has to start/end to take care of deleting expired data sets from the migration volumes, deleting obsolete MCDs, VSRs, and DSRs during migration cleanup even if it has nothing to shift to ML2? I have to assume we have such small migration activity that nothing needs deleting/cleaning? Many thanks to all who contributed and sorry for misleading anyone I mislead. Until the next time (which probably won't be long), Joe ---------------------------------------------------------------------- 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
