Concerning CLEAR TASK SET and TST=001b

PJohansson PJohansson at
Tue Apr 7 21:55:27 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* PJohansson <PJohansson at>
Despite the editor's assertion that he considers the matter closed, I think
there are still inconsistencies in SAM and SPC with respect to task

In section 6 of SAM-2, "Task management", I believe that an additional input
parameter, Initiator identifier, needs to be added to the function definitions
for ABORT TASK and ABORT TASK SET. Without this parameter it seems impossible
to correctly identify the task set to which the function pertains. I am
uncertain whether or not Initiator identifier is needed by CLEAR ACA, since I
am neither a contingent nor an auto contingent allegiance maven.

With respect to CLEAR TASK SET, the situation is murkier. Ralph asserts, "The
meaning of ABORT TASK SET is affected by the Task Set Type (TST) field, the
meaning of CLEAR TASK SET is not.  Both have valid, T10 approved, definitions
when TST=001b (and incidentally the definitions are different)." How are they
different? If CLEAR TASK SET references a task set correlated with the
requesting initiator, the only tasks in that set belong to one initiator:
ABORT TASK SET and CLEAR TASK SET are identical. If CLEAR TASK SET references
all task sets for all initiators for a particular logical unit then ABORT TASK
SET and CLEAR TASK SET differ. But this is the CLEAR ALL TASK SETS
functionality that was removed from 97-225 by Gene Milligan in its latest

What, then is the true meaning of CLEAR TASK SET? Does it reference a singular
task set, that created by the initiator making the request? In that case the
new input parameter, Initiator identifier, is needed for the function call.

Can an initiator originate a CLEAR TASK SET directed to another initiator's
task set?

It may be satisfying to defend the current state of affairs as the result of a
recorded decision of the working group." But it's irrelevant for two reasons:
no one has ever attacked the decision on the grounds that it was made
unconsciously nor that procedural errors were made; and even the most
carefully considered decision can still be inconsistent, incomplete or both.

* Are the *effects* of ABORT TASK SET and CLEAR TASK SET identical when TST
equals 001b?

* If so, why do we support two ways of doing the same thing?

* Do initiators expect different behavior from ABORT TASK SET and CLEAR TASK
SET when TST equals zero?

* If so, is there not a possibility for error (as the result of unexpected
target behaior) if, when TST equals 001b, an initiator issues CLEAR TASK SET
but does not affect the tasks of any other initiators?

I see two possible solutions: 1) Document that ABORT TASK SET and CLEAR TASK
SET are identical when TST equals 001b; or 2) collapse them into one function
when TST equals 001b. If you think I believe the first option to be silly,
you're right. The software for the TST equals 001b case is new and we don't
have to be concerned to protect legacy implementations.

If the first solution is selected, silly as I consider it, it would encourage
transport protocols that cannot support TST equals zero to collapse the symbol
encoding of ABORT TASK SET and CLEAR TASK SET into the same numeric value.

If there are other solutions, I'm all ears. I don't think that doing nothin'
is a solution.


Peter Johansson

PS In section 4.7.4 of SAM-2, don't tagged and untagged task addresses need to
be qualified with Initiator identifier just as in the case for tagged and
untagged task identifiers? How else is it made clear that task addresses are
unique within the scope of the task set that contains the task?

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list