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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thomas Denier
Sent: Friday, October 17, 2008 12:59 PM
To: ADSM-L AT VM.MARIST DOT EDU
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.