I have worked on this problem a LOT, and as far as I know there is nothing
in TSM, DRM, or Autovault that deals with the situation you describe,

We also do a lot of tape movement due to vaulting, and there is inevitably a
case where someone bring back tape ABC221 instead of ABC211, etc.

The opposite problem can also occur :  If a PHYSICAL eject fails for a tape
going to the vault, and the operator responsible doesn't notice that he/she
has only 10 tapes to take to the vault instead of 11, you have a tape that
is checked out as far as TSM knows, but is still left in the robot when it
should be in the vault.

And the bigger your TSM server, the more tapes you move, and the more of
these errors you get.

If it isn't a really common problem, the cheapest/simplest way to resolve it
is to have an ops do a MANUAL AUDIT of your vault periodically - say once a
quarter.  It's easy to generate a list of everything that SHOULD be in the
vault for them to compare to, and note any discrepancies for you to track
down.

If it's a BIG problem, I have had to write my own RECONCILE scripts.
Depending on the TSM server host and the type of library and your scripting
preference, you can use TSM SELECTs and a combination of PERL or shell
scripts to generate and compare multiple lists:  All the tapes that SHOULD
BE IN THE VAULT ( a list of DBB tapes and COPYPOOL tapes, for example)
compared to all the tapes that SHOULD BE in the robot to all the tapes that
are CHECKED IN  compared to all the tapes that EXIST, and you can eventually
get a list of (1) tapes that should be in the vault but are in the robot,
and (2) tapes that aren't accounted for (and therefore are usually in the
vault but shouldn't be).  And while you're at it, check for tapes that are
checked in PRIVATE but should really be SCRATCH.

I've done this in several forms, and have never come up with scripts that
are generic enough to post.  There are too many variables depending on site
practices, what classes of tapes you vault, and the type of library (not to
mention my perl is pretty primitive!)

I guess the other thing you could do, would be to take the list of tapes in
VAULTRETRIEVE status, generate commands to check them in as PRIVATE , THEN
compare the list of LIBVOLS against the list still in VAULTRETRIEVE to make
sure they all got back.  THEN move them to ONSITE RETRIEVE.  But that will
require some pretty messy scripting, also.

Maybe the folks at Autovault or TSMMANager or Servergraph can come up with a
better solution!

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************




-----Original Message-----
From: Matt Simpson [mailto:msimpson AT UKY DOT EDU]
Sent: Friday, October 25, 2002 11:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: drm operator scripts


At 9:37 AM -0500 10/25/02, Mark Stapleton wrote:
>         UPDATE STG <stgpool_name> REUSEDELAY=<number_of_days>
>
>Tape volumes in the storage pool will now go to PENDING status when they
are
>moved to ONSITERETRIEVE status. You won't be able to check them in as
>scratch tapes until the reusedelay period of time expires.

That's not exactly the problem I'm trying to solve. I want to check
them in as scratch tapes. I just don't want them to disappear out of
the database before that happens.

Example. We generate a list of all tapes in VAULTRETRIEVE status, and
give that to a human and tell him to bring all those tapes back from
the vault.  We move all the tapes on the list to ONSITERETRIEVE
status.  Human brings tapes back from the vault. We load them into
the bulk entry door and issue the CHECKIN command to check them in as
scratch.  All is OK if human retrieves all the right tapes.  But if
one doesn't get retrieved for some reason, there is no longer any
record that the tape exists and isn't where it belongs.  I'd like to
have it left in the database in some status, VAULTRETRIEVE or
COURIERRETRIEVE or anything that would indicate that it exists and
needs to be returned to the library.
--


Matt Simpson --  OS/390 Support
219 McVey Hall  -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe --   An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders.  And this year's run twice as fast
as last year's.