Thank you Richard,
I'll start looking into these possible causes for the problem.
And I guess I'll also have to come up with a way to monitor for this
problem outside of TSM and the 3494.
Thanks to everyone for their comments and suggestions.
Frank,
[EMAIL PROTECTED]
916.658.1353
-----Original Message-----
From: Richard Sims [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 28, 2000 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Repeated mount of bad scratch tape
>Thank you for the replies.
>The main thing I am trying to prevent is the cancellation of the job
because
>of the failure of TSM
>to recognize that repeated mounts of a bad tape is not going to make the
>tape "all better" and usable.
Frank - A problem with 3590 cartridges should be extremely rare, given that
this is premium technology. What I would do is investigate the
failed
volume to determine just what its problem is and how it got that way, to
deal with any systemic cause that may result in the same kind of incident
with
another tape. The TSM database, Activity Log, and opsys error log can help
identify prior incidents with this and other cartridges. Check the usage
history
for that tape relative to others, number of mounts, etc. Assure that the
library
has cleaning tapes, and that they are being used on a reasonable frequency.
Inspect the interior of the library for untoward dirt/dust levels. (It is
not
unknown for someone to point the exhaust end of a vacuum cleaner toward
computer room equipment when floors are being cleaned.) If it was a new
tape,
maybe it's a bad one, or came from a bad lot. This is the kind of situation
where ongoing statistics on volume usage can come in handy.
If you have some kind of system monitoring software, you could have it
watch the operating system log or otherwise notice Perm type I/O errors and
have the program take action by doing a Checkout or Category Code change on
the bad volume. Check the APARs database for any fixes to the problem of
TSM failing to go on to another scratch volume, and boost your server level
as appropriate.
Richard Sims, BU
