I'd recommend pulling the two tapes with incorrect labels out of the library. Then do a move data on the two tapes with the duplicate label but real data to move that data to new tapes. Then after your reuse delay period, those two tapes will drop out of the storage pool (assuming you are using scratch tapes and not private tapes; if you are using private tapes they will go to empty status and you will need to del vol on them). Once they are out of the storage pool, pull them from the library, put in the other two, label them correctly, then reinsert the remaining two tapes.
David >>> Skylar Thompson <[EMAIL PROTECTED]> 1/24/2007 11:12 AM >>> Ronald Le Large wrote: > Skylar, > > Isn't it perhaps that TSM thinks that there is still data on the tape (q > cont volumename) ? > If you are absolutely sure there is no data on tape, delete the vol using > the discarddata=yes parame I did an audit volume on the two "real" tapes (the tapes whose on-tape labels match their barcodes) and TSM didn't find any problems, which means that no data would have ended up on the tapes whose on-tape labels don't match their barcodes. I had tried checking the bad volumes out of the library and relabelling them when I checked them back in, but it still checks the on-tape label even if you tell it to use the barcode, and then complains that the on-tape label matches a tape that's already in a storage pool. Is there another way to remove the label? I could try dd'ing a megabyte of zeros to the beginning of the tape, but I'd have to stop TSM to do that. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Systems Administrator, Genome Sciences Department -- University of Washington, School of Medicine
