12/22/89                                      X3T9.2/90-002 Rev 0

To: X3T9.2 Committee (SCSI)

From: Gerry Houlder   (Seagate)

Subject: Clarification of Multi-Initiator Tagged Queuing

A very important difference of interpretation arose over the 
meaning of the words on page 6-17, section 6.8, second paragraph:
  "A target may be capable of both methods of queuing, but only
   one method may be in use at a time."
Someone thought this meant that if a target has queued tagged 
commands from one initiator, it must not accept untagged commands 
from that initiator or any other initiator either.

I remember that restriction as being a "per initiator" 
restriction, so that one initiator can send tagged commands while 
another initiator is sending untagged commands.  If the committee 
agrees with this, then some wording changes must be made to 
clarify the explanation.

On page 6-17, section 6.8, last sentence of second paragraph:
It currently reads
  "A target may be capable of both methods of queuing, but only
   one method may be in use at any time."
Change it to read
  "A target may be capable of both methods of queuing, but only 
  one method may be used by a given initiator at one time.  Other 
  initiators on the bus may choose the other queuing method; in 
  this case, the target will manage both types of queued 
  commands.  For queue management purposes, untagged commands are 
  treated as tagged commands received with ORDERED QUEUE TAG 
  messages."

If the committee decides that all initiators must use the same 
queuing method, then the second paragraph of section 6.8 must be 
more strongly worded so it is clear that all initiators on the 
bus (even temporary copy managers, which have no way of knowing 
if it must use tagged queue messages) must use the same queuing 
method.  Also, section 6.5.2 (Incorrect Initiator Connection) 
must note that an existing I_T_L_Q nexus for any initiator must 
cause rejection of an I_T_L nexus establishment attempt by any 
initiator and vice versa.

I would argue against the latter course of action because it 
requires initiators (even temporary initiators and targets doing 
asynchronous event notification) to know whether the other 
initiators on the bus are issuing tagged or untagged commands.  
This seems like too much to expect.

Whichever course is taken, I believe the wording changes must be 
made in the SCSI-2 standard.  If we cannot agree that the change 
is editorial, then this proposal must be treated as a public 
review comment.