Re: delete volhist doesn't return volume to scratch

I hope to clear this up since a bunch of folks seem to be unclear on
this.

The most common way of running an ITSM server's tape pool is to check
them all in as SCRATCH, and then when a new tape is needed for any
reason, it is taken from the list of scratch tapes. So, a tape can be in
one of four states:

1. SCRATCH (A volume can go from here to either 2 or 4)

2. In a Tape Storage Pool containing backed-up data. (A volume goes from
here to State 3 if REUSEDELAY is 1 or longer, or from here back to
SCRATCH if REUSEDELAY=0.)

3. PENDING, that is it was in state 2, and it got reclaimed or deleted,
and the REUSEDELAY period has not yet expired. (A volume from here goes
back to State 1.) You can manually use DELETE VOL to short circuit the
REUSEDELAY and return PENDING tapes to SCRATCH status immediately, which
you might want to do if you are running out of scratch tapes.

4. Listed in the Volume History File, because they have been used for
Database Backups for instance. Tapes listed in the Volume History File
are not in a Storage Pool per se, although they could be considered to
be in their own different kind of storage pool. When you run the DELETE
VOLHIST command, or when the DRMDBBACKUPEXPIREDAYS interval expires,
tapes that are no longer listed in the Volume History File go directly
to state 1 - SCRATCH. This occurs immediately - the REUSEDELAY is not an
applicable concept here.

5. (I know, I said four) PRIVATE. I use PRIVATE status for tapes that
are of suspicious media quality and are waiting for me to get off my
lazy rear end and check them out of the library and ship them off to the
recertifier. The only way a tape is in PRIVATE status and is not also in
State 2, 3, or 4, is if I put it there manually. I have an SQL query
that checks this daily and sends me the result in email. The signature
for tapes in this status is that the LASTUSE is blank.

There seems to be some confusion as to what happens to tapes in state 4.
The doc is very clear about DELETE VOLHIST:

"When you delete records for volumes that are not in storage pools (for
example, database backup or export volumes), the volumes return to
scratch status even if TSM acquired them as private volumes."

Therefore this statement is incorrect:

>private.  They return to their original state.

There is one exception here - if you use Disaster Recovery Manager,
which adds a whole new layer of complication. If you are using DRM, you
hopefully understand how it impacts this process.

This whole area is glitchy - so much so that it has its own error
message numbers. (This happened to me several times in the last couple
days, and I had to look them up.) The messages manual says that one
thing that can clear out tapes stuck in limbo like this is a simple
server restart. Or, if the tape was PENDING when it got stuck, DELETE
VOL will work to clear it back to SCRATCH status.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
"Have you ever, like, tried to put together a bicycle in public? Or a
grill?" Astronauts David Wolf and Piers Sellers, explaining the
difficulties encountered in attaching equipment to the Space Station


On Mon, 11 Nov 2002, Michelle Wiedeman wrote:

>I cant remember what its called under tsm but i know there is an option in
>which u tell tsm NOT to claim a tape just as dbb tape. Is it possible this
>happened and ur dbb tape also containes other data? That would explain why
>it doesnt return to scratch.
>
>Michelle
>
>-----Original Message-----
>From: Paul Miller [mailto:Paul_Miller AT CARGILL DOT COM]
>Sent: Saturday, November 09, 2002 4:40 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: delete volhist doesn't return volume to scratch
>
>
>Thanks, everyone for your replies.  I migrated one of the problem TSM
>servers to new hardware today (was going to do it anyway), and it seems
>to be working fine.  I just noticed this problem on one of my HP-UX
>servers today, as well, though, and that one's running 5.1.  Curiouser
>and curiouser...
>
>Etienne, I check all my tapes in as scratch and let TSM take care of
>doling them out, so that wasn't it.  Good question, though.
>
>Mark, I don't think dbb tapes go into a pool, do they?
>
>-----Original Message-----
>From: ebrodeur AT SERTI DOT COM [mailto:ebrodeur AT SERTI DOT COM]
>Sent: Friday, November 08, 2002 14:31
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: delete volhist doesn't return volume to scratch
>
>
>Did you perhaps label it and check it in the library as private?  I seem
>to recall I had similar thing happen with tapes I originally checked in
>as
>private.  They return to their original state.
>
>Etienne Brodeur
>
>
>
>
>Mark Stapleton <stapleto AT BERBEE DOT COM>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>11/08/2002 02:21 PM
>Please respond to "ADSM: Dist Stor Manager"
>
>        To:     ADSM-L AT VM.MARIST DOT EDU
>        cc:
>        Subject:        Re: delete volhist doesn't return volume to
>scratch
>
>
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
>Paul Miller
>> No, it's not the last one.  It leaves the last one as it should.
>After
>> I run the command, the volume history is indeed deleted, but the tape
>> remains "private" with a last use of "dbbackup".  I can update the
>> libvolume and make it scratch, but that's not what's supposed to
>happen.
>
>Do you have a REUSEDELAY setting for your tape pool?
>
>--
>Mark Stapleton (stapleton AT berbee DOT com)
>Certified TSM consultant
>Certified AIX system engineer
>MCSE
>