RESERVATION CONFLICT etc...
Charles Monia, SHR3-2/W3, 237-6757 17-Aug-1994 2236
monia at starch.enet.dec.com
Wed Aug 17 19:51:57 PDT 1994
>Charles's suggestion was as follows:
>> I would suggest deleting the current wording
>>in clause 4.6.5 and adding the following paragraph to 4.2 "Status" to define
>>the reporting precedence when several conditions exist concurrently.
?>"If more than one condition applies to a completed task, a condition associated
>>with a BUSY, RESERVATION CONFLICT, ACA ACTIVE or TASK SET FULL status shall be
>>reported in preference to any other condition associated with the task."
>This wording doesn't go far enough. What if RESERVATION CONFLICT and TASK SET
>FULL are both "true conditions"? Which one do I report? Is the order you list
>the items in supposed to be a priority order, such that the first one is
>reported if active or the 2nd one is reported if it is active and the 1st one
>isn't, etc.? If so, this needs to be stated. Then I think Reservation Conflict
>should be 1st, then ACA Active, Busy, Task Set Full (I would agree to have this
>ahead of Busy if the committee desired), Check Condition, Command Terminated,
>the two "condition met" possibilities, Intermediate, and Good (in this order).
>There also has to be prioritization among CHECK CONDITION statuses. Checks that
>intend to report Unit Attention sense key should have 1st priority, then checks
>that would report deferred errors (from previous commands), then checks for the
>The point is that a test case can be made so that any pair of these statuses
>can be simultaneously active. If the standard doesn't specify how to handle
>these cases, then every product will have to make that decision for itself.
>This priority order wasn't in SCSI-2 because the committee thought the order
>wasn't important enough to cause inconpatibilities in a real system. Maybe a
>different decision is warranted for SCSI-3.
There is no prioritization intended other than the one stated in my proposal.
If there are simultaneous ACA ACTIVE and TASK SET FULL conditions, for example,
the choice of which of these statuses to return would be implementation
specific. If the only goal of prioritizing status is to avoid the deadlock
condition mentioned in Giles' note then, in my opinion, the proposal is
adequate as it now stands. I see no value in adding additional complexity.
More information about the T10