Thanks Jurjen and Richard,

Sorry for omitting the subject..

I forgot to mention in my original post that STK guy upgraded all drives to
the latest firmware a couple of weeks ago... we are now at 53Y2.  I just
discovered that one drive is at 5AT0... and it is the one with the highest
number of occurrences of that tapealert.  We also upgraded the library code
to 3.11.02.   I wonder if these levels could be buggy...

We discovered the CM problem a year ago.  But, we only noticed it when
attempting to read a corrupted tape, and we got a different tapealert.  I
always assumed that there was no indication when the corruption occurred,
only when it was found.  Is this tapealert new to TSM 5.3 (vs. 5.2 which we
were at last year)?  It's certainly better to detect the problem when it
happens than maybe years later!

We handled the CM problem by setting up an Openview monitor that started an
audit of each volume that got the tapealert.  When we started, we had maybe
20 audits a day.  Over several months, the audits  decreased, and now we
rarely have one.  We probably still have some corrupted tapes in the
inventory, as many have not been mounted in years.  I'm not sure if we can
use tapeutil in the HP-UX environment, but I didn't like that approach
anyway because it's a manual process.

Robin Sharpe
Berlex Labs



             Jurjen Oskam
             <jurjen@STUPENDOU
             S.ORG>                                                     To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .EDU>                     Re: TapeAlerts on LTO2 drives,
                                       tapes

             06/29/2006 03:48
             AM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






On Wed, Jun 28, 2006 at 02:23:33PM -0400, Richard Sims wrote:

> You might experiment with one of your drives, boosting it to the
> latest microcode level (if not already there) and see if amelioration
> occurs.

Back in 2005 we also had problems with our IBM LTO2 drives in a 3584
library. In the end we found out that these were all microcode-related.
After upgrading to a fixed microcode level, we still kept seeing
problems with some tapes. What happened was that the chip in the
cartridge contained 'bad' information (due to the drive microcode
problems earlier on) and this causes weird behaviour (TapeAlerts)
even after we installed correct microcode. The fix for this was to
use 'Space to End of Data' in tapeutil: this apparently clears or
reinitializes the chip in the tapes.

(Even now, we sometimes get a TapeAlert "This tape is not data-grade"
on a rarely used volume.)
--
Jurjen Oskam

Savage's Law of Expediency:
        You want it bad, you'll get it bad.