On Tue, Nov 11, 2003 at 01:06:31PM -0500, Lee, Gary D. wrote:
> Don't think you can do a move nodedata for a copy pool. Must be done
> on a primary pool.
From: Jurjen Oskam [mailto:[EMAIL PROTECTED]
>That's not true. MOVE NODEDATA works on any storagepool, *if* the
needed volumes are onsite and
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Move Nodedata starts and
ends without doing anything
On Tue, Nov 11, 2003 at 02:01:33PM -0500, Richard Sims wrote:
> That obviously precludes Access=Offsite. And wouldn't it be nice if the
> programmers put out some kind of message when the function ends up copying
> none of the data that the customer requested? (Come on, IBM - that's not
> "enter
On Tue, Nov 11, 2003 at 01:06:31PM -0500, Lee, Gary D. wrote:
> Don't think you can do a move nodedata for a copy pool. Must be done on a primary
> pool.
That's not true. MOVE NODEDATA works on any storagepool, *if* the
needed volumes are onsite and readable.
Early MOVE NODEDATA versions just
On Tue, Nov 11, 2003 at 10:08:02AM -0600, Todd Lundstedt wrote:
> them from the old copy storage pool. But nothing moved. What is wrong?
The implementation of MOVE NODEDATA (especially early versions) is a bit
wobbly. For your particular problem, see APAR IC36499.
--
Jurjen Oskam
PGP Key avai
/2003 02:05 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Move Nodedata starts and ends without doing anything
>Don't think you can do a move nodedata for a copy pool. Must be done on
=
>a prima
Well, there it is then. We'll see if TSM support comes back with this bit
of information on their next attempt to "resolve" this issue. Their first
attempt was to tell me that I couldn't move nodedata from a copy storage
pool to another storage pool. I guess they didn't read the entire ESR.
Anyw
>Don't think you can do a move nodedata for a copy pool. Must be done on =
>a primary pool.
Says the reference manual:
"The data can be located in either a primary or copy storage pool."
The problem with the attempted operation was Offsitedness and TSM
documentation and programming shortcomings.
>Shouldn't it use primary storage volumes to get the data, just like a
>reclamation or a move data for acc=offsite volumes?
Again, I urge reading the Technical Guide redbook to fully understand
TSM functions before trying to use them. It's particularly important
to do so because the command refer
Don't think you can do a move nodedata for a copy pool. Must be done on a primary
pool.
The Admin Ref says for Move Data:
You can use this command to move files from an offsite volume in a copy
storage
pool. Because the offsite volume cannot be mounted, the server obtains
the files
that are on the offsite volume from either a primary storage pool or
another copy
storage pool. These f
Shouldn't it use primary storage volumes to get the data, just like a
reclamation or a move data for acc=offsite volumes?
>But nothing moved. What is wrong?
The tapes are offsite and thus the data can't be moved?
The only way I know of to get rid of the obsolete data in the original
offsite storage pool is to delete vol discarddata=yes on the
volumes involved in the offsite pool and then do a backup stg of the
original primary storagepool to recopy the data remaining in that pool.
David
>>> [EMAIL PR
>But nothing moved. What is wrong?
The tapes are offsite and thus the data can't be moved?
Recently, I moved data for several nodes from one Primary storage pool to
another. That new primary storage pool is backing up to a different copy
storage pool. Data for those servers in the original copy storage pool
(stgpool_name='OFFSITE') is no longer needed. So, I was going to perform
a "mo
15 matches
Mail list logo
