On Sun, Jun 01, 2003 at 02:33:22PM +0300, Zlatko Krastev/ACIT wrote:
> --> ... from storage pool COPY01 to storage pool COPY01 ...
>
> TSM is smart enough. Try using TOstgpool=<another copypool> parameter of
> MOVe NODEdata command.
This is not possible (emphasis mine):
TOstgpool
Specifies the name of a storage pool to which data will be moved. This
storage pool must be in the NATIVE or NONBLOCK data format. **This
parameter is optional and does not apply when the source storage pool
is a copy storage pool.** That is, if the source storage pool is a copy
storage pool the destination must be the same copy storage pool. If a
value is not specified, data is moved to other volumes within the
source pool.
Note:
If you are moving data within the same storage pool, there must be
volumes available that do not contain the node data you are
moving. That is, the server cannot use volumes that contain the
data to be moved as destination volumes.
If MOVE NODEDATA would work the same way as MOVE DATA does for an offsite
volume beloning to a copypool (i.e.: retrieve the files from an onsite
primary pool), this would provide for a very easy and cheap way to make
sure that certain filespaces are quickly restored in a DR scenario. By way
of the MOVE NODEDATA command, you would only need one or two volume mounts (in
a noncollocated copypool) instead of many more when restoring during DR.
Unfortunately, MOVE NODEDATA only works this way when the volumes that
contain the data to be moved are onsite and available. This make MOVE
NODEDATA almost useless in this scenario, since copypool volumes are
offsite for a reason. :-)
I opened a PMR with IBM support for this behaviour. Initially, I was told
that this 'works as designed'. However, MOVE NODEDATA does things
that are not right in my (very humble) opinion:
* MOVE NODEDATA reports success, even when a non-existant filespace was
specified.
* If, for a random filespace, some copypool volumes are onsite and some
are offsite, MOVE NODEDATA only moves the files in the filespace that
are contained on the onsite part of the filespace. However, MOVE
NODEDATA still reports success in this case, and no mention whatsoever
is made that part of the filespace has not been moved at all (not even
in the 'Failed files' counter of the summary). The only way you can tell
is to check whether the summary of the MOVE NODEDATA reports a
'Moved Files' number equal to the amount of files in the entire filespace.
This gets difficult if you're moving entire nodes.
So I told this to IBM Support in response to their 'works as designed', and
above issues are still being checked out.
Thanks for your reply,
--
Jurjen Oskam
PGP Key available at http://www.stupendous.org/
