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 [EMAIL PROTECTED] "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@;CARGILL.COM] >Sent: Saturday, November 09, 2002 4:40 AM >To: [EMAIL PROTECTED] >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: [EMAIL PROTECTED] [mailto:ebrodeur@;SERTI.COM] >Sent: Friday, November 08, 2002 14:31 >To: [EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> >Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >11/08/2002 02:21 PM >Please respond to "ADSM: Dist Stor Manager" > > To: [EMAIL PROTECTED] > cc: > Subject: Re: delete volhist doesn't return volume to >scratch > > >From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.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 ([EMAIL PROTECTED]) >Certified TSM consultant >Certified AIX system engineer >MCSE >
