Len, FWIW, I have seen the same behavior and talked with the STK specialist
here.
He said that the cleaning light comes on for two different things -
sometimes it means "clean requested", and sometimes means "clean required".
There is a tiny cable that goes from the drives back to the robot (at least
in our robot). With hardware cleaning on, that is how the "clean required"
gets back to the robot and causes it to mount the cleaning tape. A "clean
request" doesn't.
This guy usually knows what he is talking about, and it explained the
results I saw here - sometimes when the clean light was on a clean occurred,
and sometimes it didn't. That may also explain the results you have seen
with software cleaning. I don't think TSM has any way to sense that the
drive is in degraded mode, or in a "clean request" rather than a "clean
required" state, because I don't think the hardware sends any data back.
It's an unfortunate design issue with the hardware (and using one yellow
light to mean two different things when you can't tell which is which is
just part of the problem.).
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
[EMAIL PROTECTED]
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
> -----Original Message-----
> From: Len Boyle [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, October 10, 2000 6:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Damaged Tapes using TSM 3.7.2 for NT and DST Tape Drives
>
> In article <[EMAIL PROTECTED]>, Dennis
> Berestecki <[EMAIL PROTECTED]> says:
> >
> >This appears to be an old subject, but it is new to me.
>
> Hello Dennis
>
> Welcome to the fun times with windows nt and dlt 7000 drives.
> We have two windows nt servers and two stk robots.
> When we used to use several stackers with dlt4000's, we almost
> never seemed to see any problem. But the dlt7000 are another story.
>
> Most of the time they work correctly and the dlt7000 v95 microcode
> level with the co-rec adsm 3.1... and 3.7... code levels helped
> improve things. But there is a problem if a dlt drive gets into a
> bad state.
>
> The other thing is that the stk guys would like use to use software
> cleaning when available and the adsm/tsm guys say that they do not
> support software cleaning when hardware cleaning is availalbe, and
> they say that this is because quantum tells them this is the best
> method.Of course we have tried both, and neither works all the time.
>
> ADSM/TSM does not appear to notice when a drive is in a degraded
> mode with or without the cleaning light on. (Note: the cleaning light
> does not mean that the drive needs cleaning, but that their was
> a failure of an i/o which might be cleared by cleaning)
>
> So adsm/tsm will put a tape up on a drive with the cleaning light set,
> which I understand is not always fatal, but may be. It will continue
> to use a tape after the cleaning light is on somethimes. With software
> cleaning TSM notices sometimes and clean the drive. Sometimes TSM
> picks up on the problems and treat the problem as an hard error, marking
> the tape read only. This was the change introduced to go with the
> v95 microcode. This was a good thing.
>
> My background is more from the mf background where a fatal error
> can cause the tape to be feniced or boxed by the tape control unit
> or the i/o subsystem. As far as I can tell with the stk robots
> this is not possible as I do not believe that there is a feedback
> loop from the drive to the robot to the software. In theory I believe
> that the software could do it using the different dlt7000 status,
> but the adsm folks have not learned how to do it without a performance
> problem. And it does not help that quantum witll only talk with the
> robot folks and not the endusers or software vendors.
>
> From the talk I listened to on ATL there may be more going on, as I
> believe that the software does not talk directly to the dlt7000 but
> goes thru a ATL computer which handles all the tape i/o. So you would
> think that they should be handling the i/o problems.
>
> I would like to see the ADSM/TSM folks do a better job of detecting
> problems with the dlt7000 at run time. The other thing that would be
> nice for ADSM/TSM is better volume/drive stat reporting.
> The show library command lists the number of i/o errors for the last
> mounted tape on a drive. it would be nice is adsm could record
> somewhere the stats by volume serial for each volume dismounted.
> This way we could track trends in problems by volume and by drive.
> This is done via erep reports on the IBM MF.
>
> Has anyone written up an enhancement request along these lines.
>
>
> The short term solution, stolen from another on this list, is to
> check that you have either the hardware or software set to clean the
> drive. And they check yourself. If a drive has a cleaning light on
> try cleaning it. If that does not work, try one more time, if that
> does not work ask the vendor to replace the drive.
> May sure that any tape that causes the cleaning light to come on is
> only used to read the data off of the tape. It appears that a tape
> that has been setup badly will set the drive in a bad mode which
> can lead to other problems. The funny thing is that the tape may
> not be bad and a reinit and use again may work fine.
>
> PS Anyone know how the new 100gig tape drives work for TSM?
> -------------------------------------------------------------------------
> Leonard Boyle [EMAIL PROTECTED]
> SAS Institute Inc. ussas4hs@ibmmail
> Room RB448 [EMAIL PROTECTED]
> 1 SAS Campus Drive (919) 677-8000 ext 6241
> Cary NC 27513
