August 15, 2017
© Copyright IBM Corporation, 2017 Page 36 of 117
the BVIR-Volume Map function. Once you have identified the physical volume, place it in the I/O station
and on pre 8.5.x.x systems refer to Appendix C, Re-inserting Copy Export Volumes. On systems running
with 8.5.x.x or higher the volume will automatically insert. The TS7700 will recognize that it owns the
volume, returning it to its pool and changing its state to READ-WRITE. Since it still has active data on it,
the volume status will continue to be FULL. The host job that needed the volume can now be re-run.
Note:
Since you have returned the physical volume to the source TS7700, you do not have an offsite copy
of the logical volumes it contains. Once the problem with the volume has been resolved, run copy export for
the pool again
,
so that the physical volume (and any other physical volume with new data in the pool) can be
moved to the offsite location.
Note: At code release level R2.1 and lower,
the logical volume that you restored will be only resident in
the cache on the TS7700 and will not be copied back to a physical volume in the secondary copy pool for up
to 4 hours. This means that it will not be eligible for copy export during that time. At code release level R3.0
and higher, the logical volume you stored except for bad state one will remain on a physical volume in the
secondary copy pool. This means that there is no need to wait for it coming to be eligible for copy export.
Note:
If a physical volume is in copy export hold state and becomes empty before it is exported, at the
beginning of next copy export on its pool, the empty export hold volumes will be automatically moved to
scratch volumes in the pool.