This has worked for me since I started with ADSM 2.1. I'll admit that they
may have broken it in TSM 4.x -- but I just fired up a "move data <offsite
volser>" and TSM is cheerfully mounting the original storage pool volumes to
put the data on a new tape for the off-site copy pool. I'm running TSM 3.7.4
on AIX 4.3.3.
I've had to do this for some time, as I've had DLT tapes (and now LTO) and
reclaim at xx% gets ugly when you want to recover a 50% full (and filling)
LTO tape that has 48 GB on it but do not want to reclaim a 50% full (and
full) LTO tape that hit 420 GB and now has 210 GB to reclaim.
Here's what I've got going right now:
adsm> move data 001351
ANR2232W This command will move all of the data stored on volume 001351 to
other volumes within the same storage pool; the data will be inaccessible to
users until the operation completes.
Do you wish to proceed? (Yes/No) y
ANS8003I Process number 3472 started.
3,472 Move Data Offsite Volume 001351 (storage pool
INCR-LT-COPY), Target Pool INCR-LT-COPY,
Moved
Files: 0, Moved Bytes: 0, Unreadable Files:
0,
Unreadable Bytes: 0. Current Physical File
(bytes): 911,150,749
Current input volume: 001311.
Current output volume: 001250.
ANR1157I Removable volume 001311 is required for Move Data process.
ANR8324I LTO volume 001311 is expected to be mounted (R/O).
ANR8337I LTO volume 001250 mounted in drive DRIVE_10 (/dev/rmt9).
ANR1340I Scratch volume 001250 is now defined in storage pool INCR-LT-COPY.
ANR8337I LTO volume 001311 mounted in drive DRIVE_02 (/dev/rmt1).
adsm> q vol 001311
Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
(MB)
------------------------ ----------- ---------- --------- -----
--------
--------
001311 NT-LT NIBLTO 190,091.7 91.0 Full
001311 NT-LT NIBLTO 190,091.7 91.0 Full
adsm> q vol 001351
Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
(MB)
------------------------ ----------- ---------- --------- -----
--------
--------
001351 INCR-LT-CO- NIBLTO 172,746.9 54.4 Filling
001351 INCR-LT-CO- NIBLTO 172,746.9 54.4 Filling
PY
Tom Kauffman
NIBCO, Inc
> -----Original Message-----
> From: Gabriel Wiley [mailto:wileyg AT US.IBM DOT COM]
> Sent: Monday, November 05, 2001 9:01 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM annoyances
>
>
> Unless something happened over night, that I have yet to hear about.
>
> "John, you don't need to bring copypool tapes back on site to
> reclaim them.
> Just do a "move data" on the off-site volume and TSM will
> rebuild it from
> the original tapes in the library."
>
> This statement would be false: If you are going to "move data" the
> off-site or what ever tape/data you are moving will have to be in the
> library.
>
> If you are going to "Reclaim" , the off-site/copy pool tape
> would not need
> to be present in the Library.
>
> Gabriel C. Wiley
> ADSM/TSM Administrator
> AIX Support
> Phone 1-614-308-6709
> Pager 1-877-489-2867
> Fax 1-614-308-6637
> Cell 1-740-972-6441
>
>
> "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>@VM.MARIST.EDU> on
> 11/05/2001 08:22:13
> AM
>
> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re: TSM annoyances
>
>
> John, you don't need to bring copypool tapes back on site to
> reclaim them.
> Just do a "move data" on the off-site volume and TSM will
> rebuild it from
> the original tapes in the library.
>
> Tom Kauffman
> NIBCO, Inc
>
> > -----Original Message-----
> > From: Johnn D. Tan [mailto:jdtan AT MED.CORNELL DOT EDU]
> > Sent: Friday, November 02, 2001 7:39 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: TSM annoyances
> >
> >
> > 1. Yet their device support website
> >
> (http://www.tivoli.com/support/storage_mgr/devices/all.html) lists the
> > element matrix for Gator, where slot 1 is element 1, but
> TSM actually
> > sees it as 1 + 29, or 30. And drive 1 is supposed to be 646, but TSM
> > sees it as 646 + 29, or 675. Again, despite their own matrix,
> > TSM seems
> > to have added 29 to the element addresses they list.
> >
> > 2. The reason I do "move data" is to consolidate the data that is
> > offsite. So, if I have a volume offsite that is
> > "under-utilized" (let's
> > say only 22% utilized), then I would want to check that tape
> > in, and do
> > a "move data" onto a pool-copy "filling" tape. But it won't
> > let me do a
> > "move data" unless the tapes associated with that one are
> also in the
> > library.
> >
> > 3. Yes, as I mentioned, it's most likely a SpectraLogic issue. Just
> > wanted to see if other folks were having similar issues.
> >
> > johnn
> >
> >
> >
> > On Friday, November 2, 2001, at 05:04 PM, George Lesho wrote:
> >
> > > 1.,The element numbers below 31 are associated with bulk
> > load, I/O port
> > > and
> > > other functions on my IBM 3575L32 Magstar tape library.
> Not Tivoli's
> > > fault
> > > or responsibility how the element numbers are mapped.
> > > 2. I let TSM worry about where it sticks the data on the tapes
> > > 3. Speak to your library vendor and ask them why their
> device driver
> > > microcode doesn't work right. The IBM Magstar doesn't
> > behave this way.
> > >
> > > George Lesho
> > > AFC Enterprises
> > > Storage/System Admin
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Johnn D. Tan" <jdtan AT MED.CORNELL DOT EDU>@VM.MARIST.EDU> on
> 11/02/2001
> > > 03:47:23 PM
> > >
> > > Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > >
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > cc: (bcc: George Lesho/Partners/AFC)
> > > Fax to:
> > > Subject: TSM annoyances
> > >
> > >
> > > I have a few annoyances with Tivoli -- not many, as it's a great
> > > product, just a handful.
> > >
> > > 1) We have TSM 4.1.3 server connected to SpectraLogic Gator/64000.
> > > Despite what Tivoli says on their website, the element
> > number of Slot 1
> > > in the library is not 1, but 30! This is very annoying!
> If I do a "q
> > > libv lib1" and look up a volume's home element, I have to
> > subtract 29 in
> > > order to really know what slot it's in on the library. Can this be
> > > corrected so that it is what Tivoli's website says it
> > should be -- i.e.,
> > > element 1 matches slot 1?
> > >
> > > 2) Is there a simple way to find out which volumes are
> > associated to any
> > > other? For instance, let's say I have to do a "move data"
> on 000115.
> > > Right now, here's what I do:
> > > q content 000115 count=-1 f=d
> > > q content 000115 count=1 f=d
> > > If either one of these has a segment 1/1, then
> everything's
> > > great,
> > > as there is no associated volume. But if either or both
> have 1/2 (or
> > > 2/2) then I have to issue:
> > > audit v 000115
> > > And find the associated volume. The catch is, if
> > there are *two*
> > > associated volumes, you have to check one of them in first
> > and update
> > > its status, before you can do another audit to find the
> > other associated
> > > volume.
> > > Is there any way to find these associated volumes
> > in one swift
> > > command?!
> > >
> > > 3) [I think this is more a SpectraLogic issue, but I'll gripe
> > > anyway ;).] When I want to "bulk load" a bunch of tapes
> > into the Gator
> > > tape library, I have to make sure no tapes are mounted in
> > the drives.
> > > Otherwise, the bulk load will just blindly put the new
> > tapes into the
> > > slots of the tapes in the drive. Doesn't TSM "talk" to the
> > tape library
> > > and tell it the home elements (or slots) of the tapes that
> > are mounted
> > > in the drives, so that the robotic picker won't put tapes
> into those
> > > slots??
> > >
> > > Thanks for any advice.
> > > johnn
> > >
> >
>
|
