Yes! It does work for TSM 4.x! This is great! Saves us a heck of a lot
of back and forth trips up to our library.

And for Joe Faracchio: I'm also going to look into your method too. The
only question is, at the end of the reclamation, how do you know which
15-30 tapes got reclaimed? Do you just do a "q v
stg=[offsite-backup-copy-name] acc=offsite" and look for 0.0%/Empty?

I assume you can then just checkin these volumes as "scratch" (or do you
have to check them in as private, do a delete, and then check them out
again?).

Now if I can just sync up the home elements and the slot numbers, I'll
be able to change my subject line ;).

Thanks again to everyone for the help!
johnn

On Monday, November 5, 2001, at 10:14 AM, Kauffman, Tom wrote:

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


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

                           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