Doug, ABARS can help you in this case. You would run the ABACKUP command using the PROCESSONLY(MIGRATIONLEVEL2). You could also process ML1 as well; there is a separate PROCESSONLY(MIGRATIONLEVEL1). If you were to specify the MOVE parm , it would also delete the migrated entries from the source system (use with caution)
On the receiving system, run the ARECOVER with the MIGRATEDDATA option. ML1 means recover all migrated data to ML1; the manual says this is the default. Specifying ML2 will recover to ML2 and MIGRATEDDATA (SOURCELEVEL) means to recover back to the original migration level. Your selection dataset would need to look something like INCLUDE(**) and then exclude any datasets if needed. All datasets (sms and non-sms) must be cataloged in order for ABARS to process them, but since these are migrated datasets this is not an issue. Chapter 3.3 of the DFSMShsm Storage Administration Guide discusses ABARS in detail. I do not think there is a compatibilty problem regarding the different z/OS DFSMS levels that you are running, but it might be worth checking into that. Hope this helps. ---------------------------------------------------------------------- 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
