<snip> 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. The OP's statement seems a perfect fit with GDG processing, whereby only the latest version is retained online using standard HSM/SMS-mgmtclas '# GDGS ONLINE' settings. But as others have already stated, more details from the OP are needed. On 18 September 2013 16:36, Glenn Wilcock <[email protected]> wrote: > Hi, > > Please provide more detail related to your environment so that we can > better help. Thanks, Glenn > > ---------------------------------------------------------------------- > 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
