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@us.ibm.com
http://www-03.ibm.com/servers/storage/
Dennis Painter <dennis@hale-pohaku.com>
03/14/2006 11:51 AM
Please respond to
dennis
To
Kevin D Butt/Tucson/IBM@IBMUS
cc
t10@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@us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
> Dennis Painter
To T10 Reflector
<T10@t10.org>
<dennis@hale-pohaku.com>
Sent by: owner-t10@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@t10.org), posted by:
> * Dennis Painter <dennis@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@t10.org
>