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
