SCSI-2 Contingent Allegiance handling

Gerry Houlder Gerry_Houlder at
Thu Sep 28 15:36:29 PDT 1995

After checking the response in our targets, I found that we accept the next 
command from the initiator with an outstanding contingent allegiance and 
execute it as long as the command doesn't violate other queuing rules. An 
untagged command will never violate the rules (because of explicit words in 
SCSI-2 describing this case) and a tagged command is OK as long as it doesn't 
overlap an outstanding untagged command (which would be a very rare and unusual 
occurrance if the CHECK occurred with an untagged command). This is done 
because it is uncomplicated to handle and doesn't cause problems for any of our 
customers (and thats a lot of customers).

Creating an artifical status like QUEUE FULL seems like an unnecessary 
complication. Returning BUSY status is more reasonable (because that is what 
you would return to other initiators when a CA exists for this initiator). We 
have found in the past that returning BUSY at strange times causes trouble for 
some customers and I expect that a QUEUE FULL would be equally distressing to 
those customers.

In my opinion, clearing the Contingent Allegiance should only be done with a 
command that ends with GOOD status or CHECK status (the CHECK will set up a new 
CA immediately). Commands that end with BUSY or QUEUE FULL shouldn't clear the 
CA because this could prevent the initiator from retrieving sense data that 
should have been retrievable. A design that checks for queue full and busy 
conditions before checking for CA conflicts would have this behavior.

The bottom line is that the standard didn't envision that systems would 
actually intermix tagged and untagged commands in normal operations, so the 
particular CA response you are asking about never happens except in some 
qualification tests or as secondary failures. This is why there was so little 
thought put into describing this case in the standard.

More information about the T10 mailing list