To: dennis@hale-pohaku.com Cc: t10@t10.org Subject: Re: SSC-3 Tape Alert Flag 20h Question From: Kevin D Butt <kdbutt@us.ibm.com> Date: Tue, 14 Mar 2006 12:14:20 -0700 X-Message-Number: 6720 Formatted message: HTML-formatted message 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@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 >