SSC-3 Tape Alert Flag 20h Question

[Kevin D Butt]

Formatted message: <A HREF="r0603142_f.htm">HTML-formatted message</A>

Dennis,
It can be reported over a second interface port or to the library.  Both 
of these scenarios exist in the industry today.  You are correct that it 
cannot be reported over the interface that has the error.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
Dennis Painter <dennis at hale-pohaku.com> 
03/14/2006 11:51 AM
Please respond to
dennis
To
Kevin D Butt/Tucson/IBM at IBMUS
cc
t10 at t10.org
Subject
Re: SSC-3 Tape Alert Flag 20h Question
Hello Kevin,
I understand what SSC says but am still left with my question:
"... how does this flag ever get reported to a host if it is deactivated
when the interface is working?"
It seems to me that without some change it can never be reported, but I
hope I am wrong and that someone can show how.
Thanks,
Dennis
Kevin D Butt wrote:
>
> Dennis,
>
> In our discussions of this TapeAlert in the SSC Working Group no
> company had any issues with this behavior. In fact this is how we
> interpreted SSC.   As TapeAlerts are defined in SSC,
> Each flag shall be cleared in the following circumstances:
> a) At drive power on;
> b) after the TapeAlert log page is read - note in multi-initiator
> environments the TapeAlert flags shall be cleared on a per-initiator
> basis such that set flags are still visible to other initiators;
> <<<< c) when the specified corrective action has been taken (such as
> using a cleaning cartridge); >>>>
> d) on SCSI bus reset or bus device reset message; or
> e) on LOG SELECT reset.
>
> The whole TapeAlert concept has not been well defined in SSC.  We have
> been making attempts to define it more concisely and to also add a new
> method of reporting tapeAlerts that are state based and not reset on
> reporting. (ala ADC)
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
> Dennis Painter
				    To T10 Reflector <T10 at t10.org>
  <dennis at hale-pohaku.com>
  Sent by: owner-t10 at t10.org	    cc
				       SSC-3 Tape Alert Flag 20h
  03/13/2006 12:32 PM	       Subject Question
   Please respond to
	 dennis
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Dennis Painter <dennis at hale-pohaku.com>
> *
> I note that ssc3r04 now defines a deactivation condition for the
> Interface flag, 20h.
>
> Deactivation condition for flag 20h being "After interface returns to
> operation"
>
> My question is how does this flag ever get reported to a host if it is
>
> deactivated when the interface is working?
>
> For example with a parallel interface if a parity error is detected by
>
> the target I would expect the target to activate the flag. If the next
>
> interface transaction has no error I would expect the target,
> following
> the deactivation condition specified, to deactivate the flag. Since
> the
> flag is now deactivated a poll of the log page would never show the
> flag
> was ever set. If this is the case what's the point of having flag 20h?
>
> >From a purely historical perspective I recall this being discussed at
> a
> Tape Alert working group before Tape Alert was added to SSC. At that
> discussion it was agreed that this flag should be "sticky" and persist
>
> until reported to the host. To the best of my knowledge that
> discussion
> was never written into the pre SSC Tape Alert documents. I do know
> that
> this "sticky" attribute has been used in implementation of Tape Alert
> but now that the standard specifies a deactivation condition that
> implementation will need to change to be compliant with SSC-3.
>
> Thanks for any clarification on this item,
>
> Dennis Painter
>
>
>
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>