>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
