Tivoli makes "destroyed" volume a scratch again

[Castaway]

I had a 3590 drive in an ATL eat an onsite tape. The CE pried it out with a crow bar :-o and it is physically not in the unit. I called back the offsite tapes needed to "RESTORE" this volume and ran the RESTORE VOL command and it told me it changed the UNAVAILABLE volume to DESTROYED. Great. When it was done, lo and behold, I had a SCRATCH volume instead of a DESTROYED one. Does this make sense for Tivoli to do this? Is it because the ATL thinks it still has the tape since it couldn't be ejected through the ATL console? I can't delete the volume to Tivoli because it is not a member of any pool. Won't Tivoli try to use it at some point and pump out nasty messages about it being not available again?



I have an AIX5.3 TSM server running TSM5.3.3.0, 3494 ATL with both 3590 & 3592 drives.

 

[heada]

If you perform a 3494 inventory, the 3494 will update it's internal database without the volume.(should have happened when the library was opened, but have the CE run one manually. This can take a very long time, depending on the size of the 3494) Once that is done, perform an audit library within TSM to update TSM's database with what the 3494 has.(again, can take a very long time, depending on the size of the 3494) You should no longer have the "scratch" (but very destroyed) volume.



-Aaron

 

[Castaway]

I was afraid that was going to be the answer! Thanks...I think!

The fact that the CE "paused" the library to get to the drive from the front door make any difference? I don't know a whole lot about the ATL console but it sure would be nice to be able to trash that one tape someway without having to do a full inventory.

 

[may]

I am not sur to really understand your prob, but if the tape is bad, can't you just remove it from libray by doing "Checkout libvol remove=yes/no (as you want)"?

 

[heada]

Pausing the 3494 prevents the robot arm from entering a crash-stop mode. If you manually modified the 3494's inventory (remove/add a volume) then there is nothing to tell the 3494 what you've done. At a bare minimum, you need to have the 3494 re-inventory itself so that it knows that the volume is now gone. TSM will auto-update itself (in a way) when it asks the 3494 to mount that volume and the 3494 denys the mount request because the volume isn't in the inventory.



When you have the CE re-inventory the library, it will not take THAT long. The 3494 will read the barcode on each volume. Performing this on a 8 module library took me about 30 minutes. When TSM performs an audit library, there should be 2 methods of performing this. First, and the fastest, is to just read the barcodes. This should take no more time than it took for the 3494 to re-inventory. The second, and by far MUCH slower would be to mount and read the internal label on each volume. If you use this method, be prepared to wait a few hours to days, depending on the size of the 3494.



There might be a way to manually update the 3494's inventory with mtlib but I don't know all the options so I can't tell you how to do that.



-Aaron