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