DATE: Mar. 12, 1991                  document  X3T9.2/91-032 R0


  TO: X3T9.2 Committee (SCSI)

FROM: Gerry Houlder (Seagate)

SUBJECT: Response to ATN during RESELECTION phase

At the last meeting, Gary Stephens suggested that the response to 
ATN during RESELECTION phase be changed so that the target must 
go to MESSAGE OUT phase (in response to the ATN signal) before 
sending the IDENTIFY message.  The existing wording requires the 
target to send the IDENTIFY message before responding to ATN.

I do not support this wording change.  There are a number of 
problems with this wording change that I wish to address.

1. The existing wording has been in SCSI-2 since 1987.  Many
   implementors (including Seagate) have implemented to the 
   existing wording and would become non-compliant if the wording 
   was changed to require targets to change to MESSAGE OUT phase 
   immediately after RESELECTION phase.  For many companies, this 
   alone is enough reason to retain the current wording because 
   such technical changes aren't supposed to be allowed at this 
   stage of the review cycle.

2. The intent of the SCSI-2 rule was to define only one response.
   This is why the wording didn't allow both immediately after 
   RESELECTION and after the IDENTIFY message as options. 

3. Some messages that could be sent by an initiator cannot be
   correctly acted upon until the LUN information in the IDENTIFY 
   message is known to both ends.  Examples are:

   ABORT message - If the initiator aborts the I/O process before 
     the LUN is known, it may not abort the right I/O process.  
     More recent wording changes suggest that RESELECTION is 
     lumped with SELECTION in that only the reconnection is 
     aborted but the wording of 1987 didn't seem to allow this.

   ABORT TAG message - Worse problem than ABORT because the tag
     value must also be known and it must come after IDENTIFY.

   DISCONNECT message - If the initiator sends this before the
     IDENTIFY message, it can't know which LUN is being 
     disconnected.  Usually the initiator wants to know which job 
     is reselecting before sending a DISCONNECT message.

   IDENTIFY message - The initiator can't send another IDENTIFY
     message (to change disconnect privilege) until the target's 
     IDENTIFY message has been received.



   INITIATOR DETECTED ERROR message - Again, the initiator can't
     tell how his error will affect this I/O process until the 
     LUN information is received.  Imagine how hard it would be 
     for the target to decide if retry should be done? Retry (or 
     even CHECK status) can't be done until the IDENTIFY msg is 
     sent anyway.

   Any illegal message - The target can't return CHECK status and
     set up sense data until after the LUN information in 
     IDENTIFY has been sent.

   TERMINATE I/O PROCESS message - The target can't go to status
     phase to report COMMAND TERMINATED status until the IDENTIFY 
     message has been returned so the initiator knows which LUN 
     will have the associated sense data.

   The other messages shouldn"t be a problem if sent right after 
   RESELECTION without an IDENTIFY message.  However, with so 
   many messages having potential problems until the IDENTIFY 
   message is sent, why not get around them by requiring the 
   target to send the IDENTIFY message before responding to the 
   ATN signal?  This was the reasoning behind the current 
   wording.

4. Some SCSI Protocol chips (ESP1xx, ESP2xx, 53C9x families for
   example) use a combinational target reselection command that 
   handles the arbitration, reselection, IDENTIFY message as one 
   group.  These chips do not interrupt out of this sequence 
   after RESELECTION if the ATN signal goes active.  The first 
   chance the target has of responding to the ATN signal is 
   after the IDENTIFY message has already been sent.  There is 
   no performance advantage to recognizing the ATN signal sooner 
   either.  I don't wish to make it difficult to implement SCSI-2 
   with these parts or to force lower performing implementation 
   on the users of these parts just for the sake of "SCSI 
   purity".

In summary, the current RESELECTION response maintains the best 
performance while leaving the least amount of problems to be 
addressed by the target when deciding what response is needed for 
certain messages.  Any change now will make SCSI life more 
complicated for a lot of people (including my company!).  Gary's 
suggested wording change should not be accepted for SCSI-2 or 
SCSI-3.