Not that I know of - this all happens on the SAN, beyond the
reach/knowledge of the UNIX server.  This is why we upgraded to v7.x so
we could use the "verify label on unload" parameter on the library
definition.  

If your zoning does not allow any windows servers to access the tape
drives, this is a non-issue.

-Teresa

-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTMAIL.TEMPLE DOT EDU]
On Behalf Of Robert Maiello
Sent: Monday, November 22, 2004 1:19 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] SCSI bus resets rewind tape in SAN?

Thanks.  The tape drives in question are connected to and zoned for Unix
Storage Nodes.  Would the RSM on a windows client leave anything in the
logs that a signal was sent to Unix tape drives?

Robert Maiello
Pioneer Data Systems


On Mon, 22 Nov 2004 09:19:45 -0500, Teresa Biehler <tpbsys AT RIT DOT EDU>
wrote:

>Also, if you have a Windows box that is zoned to see the tape drives,
>the Removable Storage Service should be disabled.  This service will
>occasionally request a status from the drive and, if it is found in an
>unexpected state (like when another system is writing), it will send a
>signal to rewind the tape.
>
>-Teresa
>
>
>
>-----Original Message-----
>From: Legato NetWorker discussion
[mailto:NETWORKER AT LISTMAIL.TEMPLE DOT EDU]
>On Behalf Of Davina Treiber
>Sent: Monday, November 15, 2004 5:15 AM
>To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
>Subject: Re: [Networker] SCSI bus resets rewind tape in SAN?
>
>Darren Dunham wrote:
>
>>>Has anyone had a problem where a scsi bus reset rewound the drive
>without
>>>Networker's knowledge?   Any logs or ways to trace this?
>>
>>
>> I have no evidence that "scsi bus resets" or anything else in
>particular
>> was the cause, but I have seen tape corruption of older versions of
>> networker that appeared to be caused by unexpected rewinds.
>>
>
>Some SAN hardware using certain older firmware versions suffered from a
>problem where the type of SCSI resets sent was particularly destructive
>in this sense. The solution was to upgrade to firmware versions that
did
>not send TPRLO resets.
>
>--
>Note: To sign off this list, send a "signoff networker" command via
>email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list. Questions regarding this list
>should be sent to stan AT temple DOT edu
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
>--
>Note: To sign off this list, send a "signoff networker" command via
email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list. Questions regarding this list
>should be sent to stan AT temple DOT edu
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via
email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=