SAM2, rev23 ACA question

Jim Hafner hafner at almaden.ibm.com
Thu Sep 5 08:11:18 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Jim Hafner <hafner at almaden.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 005343E888256C2B_=
Content-Type: text/plain; charset="us-ascii"


Ralph, 

To fill the gap: AFAIU= As Far As I Understand.... 

Actually my complaint comes down to the whole of the tst=001b row, not
just the upper half. 

My issue is that when tst=001b, there is only one initiator involved
with the task set (one task set per initiator).  So, either that
initiator has not faulted, in which case Table 25 applies, OR that
initiator is faulted in which case Table 27 applies.   You can't have
tst=001b, have an ACA condition (this implies the initiator is faulted)
and get a command from a non-faulted initiator *directed to that task
set*. So I don't see how the conditions of that row (the whole tst=001b
row) of the table can occur.  At least, AFAIU :-{).   Am I really
missing something here?     

In answer to your question:  So... what is a device server to do if it
receives a task
with the ACA attribute and there is no ACA condition? ANSWER: SEE Table
25. 

I'm taking the perspective that these tables apply to the actions of the
device server *with respect to a particular task set*.  Maybe that's the
confusion I'm having (maybe it's meant to describe the actions of the
device server with respect to all task sets); but a CA or ACA condition
is a state of a task set (not a condition of a logical unit or a device
server) so that's how I'm reading it. 

Regards,
Jim Hafner


Please respond to roweber at acm.org 


Sent by:        owner-t10 at t10.org 


To:        t10 at t10.org 
cc:        Jim Hafner/Almaden/IBM at IBMUS 
Subject:        Re: SAM2, rev23 ACA question 



* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
*
Jim,

As far as I am concerned, all the conditions described in
table 29 can occur. Therefore, I am having some difficulty
parsing your message, to whit: "AFAIU, this particular
combination can't occur." Of course, not being able to
make heads or tails of the AFAIU is not making this task
any easier.

As far as I can tell, your complaint boils down to the
purpose of the upper half of the TST=001b row. Proceeding
|from that assumption, here is the debate.

As you point out, "If it's not faulted [the initiator
sending the new task], then there can be no ACA condition."
So... what is a device server to do if it receives a task
with the ACA attribute and there is no ACA condition?

The partial row that you would have removed describes
exactly that case. As such, its presence it the table is
critical and it should not be removed.

All the best.

.Ralph

Jim Hafner wrote:

> Folks,
>
> In looking at SAM2, rev23, Table29 (Handling for new tasks from
non-faulted initiators during ACA), I'm confused by the description in
the updated
> part of the table where TST field is 001b.
>
> AFAIU, this particular combination can't occur. When TST=001b, there
is only one initiator associated to the task set, so either that
initiator is
> faulted or it's not.  If it is, then another table applies.   If it's
not faulted, then there can be no ACA condition.  If there is an ACA,
then
> there are no non-faulted initiators with respect to this task set.
Right?
>
> I understand the description in footnote "e" and do find that
enlightening.  However, the case of TST=001b and ACA attribute in the
table is
> confusing. It seems to indicate that commands are going to get
rejected, when they really can't (because the combination can't occur).
>
> I think it would be clearer (assuming I've got this right) to replace
the TST=001b row with
> | 001b |  Any attribute  | 0 or 1 |  n/a  |  Process the task (e)  |
see 5.8.1.3  |
>
> Or am I completely misunderstanding the issue?
>
> Regards,
> Jim Hafner


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




--=_alternative 005343E888256C2B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Ralph,</font>
<br>
<br><font size=2 face="sans-serif">To fill the gap: AFAIU= As Far As I Understand....</font>
<br>
<br><font size=2 face="sans-serif">Actually my complaint comes down to the whole of the tst=001b row, not just the upper half.</font>
<br>
<br><font size=2 face="sans-serif">My issue is that when tst=001b, there is only one initiator involved with the task set (one task set per initiator). &nbsp;So, either that initiator has not faulted, in which case Table 25 applies, OR that initiator is faulted in which case Table 27 applies. &nbsp; You can't have tst=001b, have an ACA condition (this implies the initiator is faulted) and get a command from a non-faulted initiator *directed to that task set*. So I don't see how the conditions of that row (the whole tst=001b row) of the table can occur. &nbsp;At least, AFAIU :-{). &nbsp; Am I really missing something here? &nbsp; &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">In answer to your question: </font><font size=2><tt>&nbsp;So... what is a device server to do if it receives a task<br>
with the ACA attribute and there is no ACA condition? ANSWER: SEE Table 25.</tt></font>
<br>
<br><font size=2 face="sans-serif">I'm taking the perspective that these tables apply to the actions of the device server *with respect to a particular task set*. &nbsp;Maybe that's the confusion I'm having (maybe it's meant to describe the actions of the device server with respect to all task sets); but a CA or ACA condition is a state of a task set (not a condition of a logical unit or a device server) so that's how I'm reading it.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Jim Hafner<br>
</font>
<p><font size=1 color=#800080 face="sans-serif">Please respond to roweber at acm.org </font>
<p><font size=1 color=#800080 face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;owner-t10 at t10.org</font>
<p><font size=1 color=#800080 face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">t10 at t10.org</font>
<br><font size=1 color=#800080 face="sans-serif">cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">Jim Hafner/Almaden/IBM at IBMUS</font><font size=1 color=#800080 face="sans-serif"> </font>
<br><font size=1 color=#800080 face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">Re: SAM2, rev23 ACA question</font>
<br>
<br>
<br>
<br><font size=2><tt>* From the T10 Reflector (t10 at t10.org), posted by:<br>
* Ralph Weber <ralphoweber at compuserve.com&gt;<br>
*<br>
Jim,<br>
</tt></font>
<br><font size=2><tt>As far as I am concerned, all the conditions described in<br>
table 29 can occur. Therefore, I am having some difficulty<br>
parsing your message, to whit: "AFAIU, this particular<br>
combination can't occur." Of course, not being able to<br>
make heads or tails of the AFAIU is not making this task<br>
any easier.<br>
</tt></font>
<br><font size=2><tt>As far as I can tell, your complaint boils down to the<br>
purpose of the upper half of the TST=001b row. Proceeding<br>
|from that assumption, here is the debate.<br>
</tt></font>
<br><font size=2><tt>As you point out, "If it's not faulted [the initiator<br>
sending the new task], then there can be no ACA condition."<br>
So... what is a device server to do if it receives a task<br>
with the ACA attribute and there is no ACA condition?<br>
</tt></font>
<br><font size=2><tt>The partial row that you would have removed describes<br>
exactly that case. As such, its presence it the table is<br>
critical and it should not be removed.<br>
</tt></font>
<br><font size=2><tt>All the best.<br>
</tt></font>
<br><font size=2><tt>.Ralph<br>
</tt></font>
<br><font size=2><tt>Jim Hafner wrote:<br>
</tt></font>
<br><font size=2><tt>> Folks,<br>
><br>
> In looking at SAM2, rev23, Table29 (Handling for new tasks from non-faulted initiators during ACA), I'm confused by the description in the updated<br>
> part of the table where TST field is 001b.<br>
><br>
> AFAIU, this particular combination can't occur. When TST=001b, there is only one initiator associated to the task set, so either that initiator is<br>
> faulted or it's not. &nbsp;If it is, then another table applies. &nbsp; If it's not faulted, then there can be no ACA condition. &nbsp;If there is an ACA, then<br>
> there are no non-faulted initiators with respect to this task set. &nbsp;Right?<br>
><br>
> I understand the description in footnote "e" and do find that enlightening. &nbsp;However, the case of TST=001b and ACA attribute in the table is<br>
> confusing. It seems to indicate that commands are going to get rejected, when they really can't (because the combination can't occur).<br>
><br>
> I think it would be clearer (assuming I've got this right) to replace the TST=001b row with<br>
> | 001b | &nbsp;Any attribute &nbsp;| 0 or 1 | &nbsp;n/a &nbsp;| &nbsp;Process the task (e) &nbsp;| see 5.8.1.3 &nbsp;|<br>
><br>
> Or am I completely misunderstanding the issue?<br>
><br>
> Regards,<br>
> Jim Hafner<br>
</tt></font>
<br>
<br><font size=2><tt>*<br>
* For T10 Reflector information, send a message with</tt></font>
<br><font size=2><tt>* 'info t10' (no quotes) in the message body to majordomo at t10.org</tt></font>
<br>
<br>
--=_alternative 005343E888256C2B_=--




More information about the T10 mailing list