ADSM-L

[ADSM-L] Server looking for volume in wrong library

2008-10-17 15:59:57
Subject: [ADSM-L] Server looking for volume in wrong library
From: Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 17 Oct 2008 15:59:01 -0400
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.

<Prev in Thread] Current Thread [Next in Thread>