In our case the restore time increased substantially(2-3hours to >8 hours) but eventually finished. TSM seemed to prefer the copypool data that was stored on virtual volumes on a remote TSM server. So, this also increased network usage by quite a bit. Oddly, TSM would mount the correct primary volume but not use it and immediately look for a copypool volume. Also, our primary pool volume are colocated but copypool volumes aren't. This had the effect of mounting many more volumes than necessary on both the local and remote TSM servers. If the copypool volumes aren't available then the restore did use the primary pool volumes. But like you said how often do you get advanced warning of restores? So, if you can wait, then install 7.1.1.200 when it is released. However, if you have to upgrade for some reason, then call IBM for the efix.
Rick Saylor Austin Community College At 08:27 AM 2/4/2015, you wrote:
When the mounting of both primary and copypool volumes occurs, does the restore run successfully anyway, even if the copypool is nor marked Unavailable? Is the mounting of both primary pool and copypool volumes just a waste of tape drives, or does it crash the restore or export? Our client admins run their own restores. We are rarely notified before one is submitted. If additional bad effects happen, please describe them. I may be misisng the obvious. One of our TSM admins is going to retire later this year. We are being urged to upgrade the TSM servers to a stable version of 7.x before that happens. If I present the APAR in 7.1.1.100 to management as a reson to delay the upgrade, I will be asked what harm is caused by it. Again, client admins run their own restores, so we cannot take preemptive action to prevent undesirable side-effects. With many thanks, Keith Arbogast Indiana University