Hi Sander, These are the commands that I am using on each tape that needs to be put in scratch.
checkout libv N00201 3494r remove=no force=yes For the second command for TSM to recognize the tapes again checkin libv 3494r status=scratch search=yes checkl=b Should I put the tapelabel (N00201) in the second command somewhere so It will know what tape I am placing in scratch status? Is this syntax correct?? thanks again! Sander te Riet Scholten wrote: > If you don't use DRM so the DB tapes are not in state MOUNTABLE use the > following steps to free those tapes: > > Get a list of the tapes that are in the wrong status. > Use the following command on every tape in the library: > > checkout libv <tapelabel> <libraryname> remove=no force=yes (this > will remove the tapes from the library inventory) > > For TSM to recognize the tapes again use the following command: > > checkin libv 3582lib stat=scr search=yes checkl=b > > Good luck! > Sander > > Timothy Hughes <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 12/14/2004 08:48 PM > Please respond to > "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > To > [EMAIL PROTECTED] > cc > > Subject > Re: DBtape won't go to scratch status > > Thanks Sander, > > What if the Tapes are in NotMountable status? And we are not > using DRM? > > Thanks Sander > > Sander te Riet Scholten wrote: > > > Hello, > > > > If you use DRM, follow the steps below: > > > > If the database tapes are in status MOUNTABLE, you need to checkout > those > > tapes, after the checkout the tapes will become VAULTRETRIEVE > immediately. > > For some reason DB-tapes that are in the library will NOT become SCRATCH > > automatically. You need to checkout/checkin those tapes for them to > become > > SCRATCH. > > > > Regards, > > Sander > > > > Timothy Hughes <[EMAIL PROTECTED]> > > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > 12/14/2004 03:14 PM > > Please respond to > > "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > > To > > [EMAIL PROTECTED] > > cc > > > > Subject > > Re: DBtape won't go to scratch status > > > > Richard, > > > > The Dbbackups are being pruned, see the following. > > > > We have Delete Volhistory set > > Schedule Name DELETE_VOLHIST_DBDACK > > Description - > > Command delete volhistory type=dbbackup todate=today-14 > > Priority 5 > > Start date 2002-06-18 > > Start time 08:57:00 > > Duration 1 > > Duration units HOURS > > Period 1 > > Period units DAYS > > Day of Week ANY > > Expiration - > > Active? YES > > Last Update Date/Time 2004-04-28 07:36:44.000000 > > Last Update by (administrator) > > Managing profile - > > > > The date on the tape shows 12/23/03 it show have been > > pruned a long time ago. > > > > Don, We have Reclamation set. I have not tried running a move data yet > > > > Schedule Name TAPE_RECLAIM_ON > > Description reclaim tapes > > Command UPD STG TAPEPOOL RECLAIM=20 > > Priority 5 > > Start date 2002-06-17 > > Start time 09:00:00 > > Duration 12 > > Duration units HOURS > > Period 1 > > Period units DAYS > > Day of Week ANY > > Expiration - > > Active? YES > > Last Update Date/Time 2004-12-03 15:15:17.000000 > > Last Update by (administrator) > > Managing profile - > > > > Thanks Richard, Don and Jin > > > > Richard Sims wrote: > > > > > On Dec 13, 2004, at 2:16 PM, Timothy Hughes wrote: > > > > > > > Hello all, > > > > > > > > Not sure If I wrote about this one before, I do know I had this > > > > problem before but was never able to get it resolved. > > > > > > > > > > > > I have a couple tapes that are in Dbackup and I would like to > change > > > > to > > > > scratch status I tried using update library volume using the TSM > Gui > > > > and > > > > received the following message > > > > > > > > ANR8443E UPDATE LIBVOLUME: Volume N00275 in library IBM3494R > > > > cannot be assigned a status of SCRATCH. > > > > > > > > The DBbackup volume has a date of 12/23/03. So that data is not > valid > > > > > > > > Anyone ever had a tape problem like this? > > > > > > > > > > Dbbackup volumes are pruned via DELete VOLHistory ... Type=DBBackup . > > > The most recent dbbackup volume is not deleteable, to assure that > > > you have *something* to recover with. > > > > > > Richard Sims
