ACA handling for "temporary initiators"

[Jeff Williams]

Date:    Fri, 10 Jun 94 15:27:09 MST

To:      scsi at WichitaKS.NCR.COM

> This scenario was created in the context of XDWRITE command (from my XOR driv
> e
> command proposal, X3T10/94-111, that was passed out but not discussed at the
> May SCSI Working Group meeting) but the same situation can occur on a COPY
> command (which also can result in a temporary inititor). The problem is as
> follows:
>  
> 1) Initiator A sends a third party XDWRITE command to device B. The ACA bit i
> s
> set in the command bytes.
> 2) Device B sends an XPWRITE command to device C (in the course of the XDWRIT
> E
> operation) that ends with CHECK status. I presume the ACA bit was set in the
> command bytes of the XPWRITE command also. This results in an ACA "allegiance
> "
> from device C to device B.
> 3) Device B sends REQUEST SENSE to device C to retrieve the sense bytes (or
> receives the sense bytes as part of an autosense operation). Device B ends th
> e
> XDWRITE command with CHECK status (which results in an ACA "allegiance" from
> device B to initiator A) and returns sense data describing the fault on the
> third party drive (either as part of auto sense operation or inresponse to a
> REQUEST SENSE from initiator A).
> 4) Initiator A now has sense data describing the problem on device C, but
> cannot act to clear the problem because only device B can send commands (with
> ACA tag, of course) to device C. How can we solve this???
>  

I would like to avoid changing the rules to accommodate this command.

To me, this is an issue analogous to a drive getting a read command and
having some error on the mechanism.  It is up to the target controller
to clean up any error in the mechanism, not up to the initiator.  I would
use the same approach here.  The initiator gave the target/temp initiator
a command to execute which just so happens to propogate into another SCSI
command.  From the initiator's point of view, it is one command.  The 
target/temp initiator is responsible for any subsequent clean up on the
XPWRITE.  The initiator shouldn't even get involved.  If it wanted to be
involved, it should have issued XDWRITE, XDREAD, and XPWRITE by itself.


Regards,
Jeff
----------------------------------------------------------------------
Jeffrey L. Williams                                HP TelNet: 396-5030
Disk Controllers Lab             	 Telephone: (1) (208) 396-5030
Disk Memory Division                     Facsimile: (1) (208) 396-6858
Hewlett-Packard Co.                    ARPANET: jlw at hpdmd48.boi.hp.com
----------------------------------------------------------------------