So now we have a bit more background..... Are you aware of Interval Migration? Assuming you have a discrete SMS Storage Group (could be a big assumption, but I am hopeful...) for these backups, you can set the high threshold to a reasonably low value, so that it will force Interval migration to pretty much continually kick in, and migrate anything that it finds eligible. IM kicks in every hour, by default.
The problem is, if you want automigration to keep (only) your latest version of your backups on disk, then that can be pretty tricky.....hence my suggestion to use GDGs, whereby you can specify in the management class, retention of a certain number of GDG versions online (in your case, you would want only 1 online [i.e. the latest one]), and interval migration would send anything older than the latest version, to tape. Not sure I understand your comment about GDGs complicating restores.....GDGs are just datasets....that are migrated....so if they are referenced by any recovery, they will be recalled from tape, as per any other dataset. If GDGs are a complete no no (and I have been in a scenario where they were), then another approach could be to change the management class (using IDCAMS ALTER) of your backup datasets, to effectively make them eligible for migration under your own control (with IM doing the necessary, as described above). The rough principle would to create the dataests with a 'no migrate' MC, and then subsequently change those to be 'migrate eligible' when you write out the 'next' version.. You dont give details of how your backup datasets are versioned, so I cant specify explicitly how that could be done, but there are variations of they way that it could be handled, depending your naming conventions / backup cycling approach. Or another alternative, if you have more than one LPAR [running HSM], you could route your HMIGRATEs (well, they would probably have to be routed F DFHSM, MIGRATE dataset-name operator commands to make life easy), so you get the parallelism from using multiple hosts. On 24 September 2013 13:56, Robert A. Rosenberg <[email protected]> wrote: > At 21:40 +0100 on 09/18/2013, Graham Harris wrote about Re: HMIGRATE in > parallel: > > > I agree. What should not be hard for HSM to create multiple migration >> subtasks (each with its own ML2 dataset) and have the master task pass one >> dataset at a time to each subtask (ie: The subtask does the same work as >> is >> currently done for a migrate). As each subtask finishes it asks the master >> task for another dataset to migrate. That way you are migrating as many >> datasets in parallel as you have subtasks allocated. >> </snip> >> >> ...which is exactly what HSM provides for automatic migration, under the >> control of maxmigration task setsys settings. What HSM does not provide >> is >> such controls/parallelism for manual (HMIGRATE) migration, which is what >> the OP is seemingly wanting, but no explanation as to why he wants this, >> as >> opposed to letting HSM do what it was designed to do. >> > > HSM auto migrate does the migration whenever it wants to not on the "Do It > NOW" basis that HMIGRATE does. Thus there is no assurance of when a dataset > will be auto migrated (only that it will eventually occur once the > migration criteria is met). HMIGRATE insures that the migration is > triggered immediately once the migration request is made. > > > ------------------------------**------------------------------**---------- > 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
