TSM Topics Feed

Thursday, October 01, 2009

Update: Weird Volhist Records

Upon further investigation I found that my other shared library environment, that has multiple NAS devices defined to the library manager, is also showing the NAS device class for all LTO-3 volumes used by the library clients. If anyone has a NAS attached to a shared library environment please compare your volhist devclass to those of your library clients and tell me if you see the same situation. CRAZY THING IS, it doesn't seem to affect the library clients from using their tapes or acquiring scratch. What my concern is, is that I am slowing losing use of tapes that should be marked back as scratch, but due to the volhistory settings is unable to be released. I am wondering if this is a bug in TSM that could be affecting others.


  1. If you are sure the volumes are empty, I would try a delete volhist with type=remote. Then see if any of these return to scratch status. Check out Richard Sim's TSM Quick Facts page under the delete volhistory section.

  2. We did do that (I've been using that since 2005) but the issue is we would not have known it was doing this until we got low an scratch and TSM didn't seem to be release as many tapes as it should have. According to Tivoli support this mismatched device class labeling is normal and does not affect production...I don't see how that makes sense, but I am still working with them so we'll see. I expect others out there would see the same thing if they have a shared library environment.

  3. Hello Chad,

    do you have any news on that?


  4. I am still waiting on IBM support. I sent them trace logs and volhist files. I'll update as soon as they have an answer.

  5. Try: del volh tod=today type=remote volume=VOLUME_NAME force=y

    Refer to my blogpost http://tsmblog.asmholdings.info/2009/07/anr2400e-during-del-volhist-when-volume.html


  6. The issue is an application issue that actually doesn't cause any noticeable problems with the library controller assigning tapes. It's just odd it assigns them one DEVCLASS on the LM and another on the LC. I still have yet to get any response from IBM support as to what would cause this.