I wonder if you could have a label problem on that tape, you may want to re-label it. Also, when you run the command "q libvol TJULIB01_1120" what is the status of that one tape?
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: Friday, October 17, 2008 12:59 PM To: [email protected] Subject: [ADSM-L] Server looking for volume in wrong library We have a 5.4.2.0 server running under mainframe Linux. We are seeing an annoying error approximately once per month. We have three libraries defined in the TSM database. All three are really a single 3494 physical library. Library TJULIB01_3592 contains 3592 media formatted for an uncompressed capacity of 300 GB. It is used for primary storage pools. Library TJULIB01_1120 contains 3592 media formatted for an uncompressed capacity of 500 GB. It is used for copy storage pools. Library TJULIB01 contains 3590 media for copy storage pools. We have stopped writing to this type of media and will delete this library once we have a complete set of copies on 3592 media. We run reclamation for our new offsite storage pool with five concurrent processes. Approximately once per month TSM tries to find an input tape in library TJULIB01_1120. When this happens TSM displays a long series of messages requesting that the input tape involved be inserted into library TJULIB01_1120 and then reports a mount failure. When we investigate these failures, 'q libvol' commands always show that the volume is in TJULIB01_3592, as it should be, and 'mtlib' commands issued from a shell prompt show that the volume is in the physical library and has the right category. Searches of the activity log have never turned up any sign of 'checkin' and 'checkout' commands being used to shift the volume between libraries between the failure and the investigation. Searches for some of the message numbers that show up when the problem occurs turned up APAR IC48313, which does cause TSM to look for volumes in the wrong libraries. However, that APAR is only supposed to apply to TSM 5.3, and the APAR description indicates that the problem occurs when two reclamation processes try to access the same volume. The activity log for the last occurance of the problem shows no sign of concurrent requests. The volume was used and dismounted almost 14 hours before the problem occured, and the volume was not mentioned in the activity log again until TSM started asking that it be inserted into the wrong library.
