Mislabeled Tapes Headache

I am periodically running into a situation where TSM will check in our tapes as private or relabel them to private, causing me headaches until I get the tapes status updated. So how do you identify the tapes that are mislabeled? Well if you have setup a library controller instance (which I recommend even if you will only have one instance for clients) then this script should work for you. What you will find when tapes are mislabeled is that they will show the library controller as their owner, will have a NULL value for LAST USE, and will of course be in private status. So a simple select statement can identify them for use.

select VOLUME_NAME from LIBVOLUMES where volume_name not in (select volume_name from volumes) and status='Private' and last_use is NULL and owner=''

If your library uses different types of media (LTO-2 and LTO-3) and you have different volume label series for them you can add another filter to further refine the results. For example my LTO-3 tape labels all start with L3 so I use:

select VOLUME_NAME from LIBVOLUMES where volume_name not in (select volume_name from volumes) and status='Private' and last_use is NULL and owner='' and volume_name like 'L3'

Once TSM has generated a list you can then run it through a while loop to reset their status or do further refining of the list if you like. If you are proficient with scripts you can automate the whole process and make life a lot easier.

Rebinding Archives

I would like to thank Nate Tade for allowing me to link to his article on how to extend (rebind) the retention for archives due to expire. I haven't had to extend archives so this is a good "How To". You can find the article by clicking the title of this post or going here.

Phantom Drive

We recently experienced an issue with a drive that we could not remove or force delete. What was happening is that TSM continually tried to dismount a volume from this drive but failed. The tape it was trying to dismount was in its home slot and not in the drive and the drive showed idle in ACSLS. TSM would not let us remove the path for it so we could not eliminate the problem. We tried a reboot and the dismount retries came up with the TSM server and NOTHING could get rid of the issue. Even turning the drive off in the library did not eliminate the "phantom" dismount attempt by TSM (We even removed the device from AIX to no avail). So did my manager finally find to be the issue? It turned out to be an incorrect WWN for the drive. How it got changed we have no idea...but it did and it caused days worth of headaches and flooded the activity log with errors. So it you ever come across a "phantom" drive check the WWN and make sure you don't suffer as we did.

Sorry!

I wish to apologize to everyone for the lack of new content. I am currently going through a divorce and it has sapped my time and my desire to write. I have 4 kids that come first and I might not be posting much until things settle down. I do have one item I will share concerning the phantom drive issue we were experiencing. Hang in there with me and I'll get back to posting items more frequently.

Useful SQL statements

Here is a grand list of TSM SQL statements that you can use in your daily report. Excellent work by Thobias, thank you very much.

Issue With NAS Path

I'm hoping someone else has seen this weird behavior with NAS paths and can shed some light on the issue. What I am currently experiencing is constant errors issuing to the actlog of my library controller instance caused by a failed mount/dismount for an NDMP backup. The TSM instance has been rebooted and the path put offline but I am still getting these errors:

05/15/2008 14:51:18 ANR9999D pvrremot.c(488): ThreadId <32> The PVR remote
descriptor is NULL.(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> issued message 9999 from: (SESSION:
24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x0000000100025bf4 outDiagf
(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x00000001004cd380
PvrRemoteOpenDrive (SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x000000010025193c
PvrOpenTapeDrive@AF144_48 (SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x0000000100245a0c
PvrOpenTapeDrive (SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x0000000100245930 PvrOpenDrive
(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x00000001002a0150 MgrGetIdleVol
(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x00000001002a0e78 PerformDismount
(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x00000001002a0850
PerformDismountNow (SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x00000001002a0d24 DismountThread
(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x000000010000fe5c StartThread
(SESSION: 24492)
05/15/2008 14:51:18 ANR9999D ThreadId <32> 0x090000000040f448 _pthread_body
(SESSION: 24492)

The problem is that support wants me to reboot my Powderhorn, which is just not feasible. ACSLS is not showing anything in the drive and that the drive is available so I don't see how it's a library/ACSLS issue.

My Lack of Recent Posts

I apologize for the lack of posts lately. I would like to let all TSMExpert visitors know I am currently going through some personal issues that have been very hard on me and have been and will continue to take my attentions elsewhere for the next few months. I thank those contributing in the meantime in advance and hope to get back to blogging as soon as I can.