 
Working								X3T10
Draft								Project 856D



									Revision 4a
									11 January, 1995





Information technology -
SCSI-3 Interlocked Protocol


Secretariat:
Computer & Business Equipment Manufacturers Association


This is a draft proposed American National Standard of Accredited Standards Committee X3. As such this 
is not a completed standard. The X3T10 Technical Committee may modify this document as a result of 
comments received during public review and its approval as a standard. Use of the information contained 
here in is at your own risk.

Permission is granted to members of X3, its technical committees, and their associated task groups to 
reproduce this document for the purposes of X3 standardization activities without further permission, 
provided this notice is included. All other rights are reserved. Any duplication of this document for 
commercial or for-profit use is strictly prohibited.







	 
		










	



POINTS OF CONTACT:

X3T10 Chair 					X3T10 Vice-Chair
John B. Lohmeyer 			 	Lawrence J. Lamers 
NCR Microelectronics				Adaptec 
1635 Aeroplaza Drive 				691 South Milpitas Blvd
 Colo Spgs, CO 80916				Milpitus, CA 95035

Tel:       (719) 573-3362				Tel:      (408) 975-7817
Fax:      (719) 573-3037				Fax:     (408) 957-7193 
Email:    john.lohmeyer@hmpd.com		Email:   ljlamers@aol.com

X3 Secretariat
Lynn Barra 
Administrator Standards Processing 
X3 Secretariat					Telephone:    202-626-5738 
1250 Eye Street, NW   Suite 200			Facsimile:    202-638-4922 
Washington, DC   20005

SCSI Reflector	     
Internet address for subscription of the SCSI reflector: scsi-request@wichitaks.ncr.co
Internet address for distribution via SCSI reflector: scsi@wichitaks.ncr.com

SCSI Bulletin Board					                 
719-574-0424

Document Distribution
Global Engineering				Telephone: 303-792-2181 or
15 Inverness Way East			                 	     800-854-7179
Englewood, CO 80112-5704			Facsimile:   303-792-2192


ABSTRACT

This standard defines the protocol required to allow a SCSI Initiator and Target to execute commands and task 
management functions using the SCSI-3 Parallel Interface. 

 PATENT STATEMENT

CAUTION: The developers of this standard have requested that holder's of patents that may be required 
for the implementation of the standard, disclose such patents to the publisher. However neither the 
developers nor the publisher have undertaken a patent search in order to identify which if any patents may 
apply to this standard.

As of the date of publication of this standard and following calls for the identification of patents that may be 
required for the implementation of the standard, no such claims have been made. No further patent search is 
conducted by the developer or the publisher in respect to any standard it processes. No representation is made or 
implied that licenses are nor required to avoid infringement in the use of this standard.

Contents

Editors note: a more detailed, program generated, table of contents is needed and will be supplied with the next 
revision.

Foreword.......................................................................................................................................4

Introduction...................................................................................................................................4

1	Scope...............................................................................................................................5

2	References........................................................................................................................5
	2.1 Normative references..................................................................................................5
	2.2 Informative references................................................................................................5

3	Glossary, abbreviations, and conventions.........................................................................6
	3.1 Glossary.....................................................................................................................6
	3.2 Abbreviations...........................................................................................................11
	3.3 Editorial conventions................................................................................................11

4	SIP reference model........................................................................................................11
	4.1 Services provided to the application layer..................................................................13
	4.2 Services requested of the physical interconnect layer.................................................13

5	SIP conditions................................................................................................................18
	5.1 Attention condition...................................................................................................18
	5.2 Reset condition.........................................................................................................19
	5.3 Parity condition........................................................................................................20
	5.4 Bus free condition.....................................................................................................20

6	SIP message system description......................................................................................21
	6.1 Overview..................................................................................................................21
	6.2 Task management messages.....................................................................................25
	6.3 Link management messages.....................................................................................27
	6.4 Queue tag messages..................................................................................................37

7	SCSI command processing ............................................................................................39
	7.1 SCSI pointers...........................................................................................................39
	7.2 Incorrect initiator connection....................................................................................39
	7.3 Interlocked asynchronous event reporting.................................................................40
	7.4 Unexpected reselection.............................................................................................41
	7.5 Unit attention condition............................................................................................4


Foreword

This standard, ISO/IEC ***** does not replace any existing standard.  This standard encompasses the fol-
lowing:

Clause 1
describes the scope
Clause 2
lists the normative and informative references
Clause 3
provides a glossary, editorial conventions, and a list of abbreviations 
Clause 4
describes SIP behavior in terms of the SCSI-3 Architecture Model
Clause 5
describes SIP conditions, such as reset
Clause 6
describes the SIP message system 
Clause 7
discusses command processing considerations


Introduction

The SCSI protocol is designed to provide an efficient peer-to-peer I/O bus with up to 32 devices, including 
one or more hosts.  Data may be transferred asynchronously at rates that depend primarily on device 
implementation and cable length.  Synchronous data transfers are supported at rates up to 20 
mega-transfers per second.  Three data path widths are allowed, 8-bit, 16-bit, and 32-bit.  The correspond-
ing maximum transfer rates are 20, 40 and 80 megabytes per second.

SCSI is an I/O interface that can be operated over a wide range of media and data rates. The objectives of the 
Parallel Interface and Interlocked Protocol in SCSI-3 are:

1. To provide host computers with device independence within a class of devices.  Thus, different disk drives, 
tape drives, printers, optical media drives, and other devices can be added to the host com-puters without 
requiring modifications to generic system hardware.  Provision is made for the addition of special features and 
functions through the use of vendor unique indications.  Reserved areas are provided for future standardization.
 
2. To provide compatibility with SCSI-2 devices.  Devices meeting SCSI-2 and the SCSI-3 Parallel Interface 
standards can co-exist on the same bus.  Properly conforming SCSI-2 devices, both initiators and targets, 
should respond in an acceptable manner to reject SCSI-3 protocol extensions.  All SCSI-3 protocol extensions 
are designed to be permissive of such rejections and to allow the SCSI-2 device to continue operation without 
requiring the use of the extension.
 
3. To move device-dependent intelligence out to the SCSI-3 devices. Refer to the SCSI-3  command level 
standards.
 
The interface protocol includes provision for the connection of multiple initiators (SCSI devices capable of 
initiating a task) and multiple targets (SCSI devices capable of responding to a request to perform 
a task).  Distributed arbitration (i.e., bus-contention logic) is built into the architecture of parallel SCSI.  A priority 
system awards interface control to the highest priority SCSI device that is contending for use of the bus.

With any technical document there may arise questions of interpretation as new products are imple-
mented.  The X3 Committee has established procedures to issue technical opinions concerning the stan-
dards developed by the X3 organization. These procedures may result in SCSI Technical Information 
Bulletins being published by X3.

These Bulletins, while reflecting the opinion of the Technical Committee that developed the standard, are 
intended solely as supplementary information to other users of the standard.  This standard, ANS 
X3.***-199x, as approved through the publication and voting procedures of the American National Stan-
dards Institute, is not altered by these bulletins.  Any subsequent revision to this standard may or may not 
reflect the contents of these Technical Information Bulletins. 

Current X3 practice is to make Technical Information Bulletins available through:

Global Engineering				
15 Inverness Way East
Englewood, CO   80112-5704			
Telephone:	303-792-2181 or800-854-7179
Facsimile:	303-792-2192


1. Scope

This standard defines the SCSI-3 Interlocked Protocol (SIP).  The role of SIP is to supply a mapping of the SCSI 
command sets to the SCSI parallel bus as defined in the SCSI-3 Parallel Interface (SPI) document.  SIP is closely 
derived from the protocol portions of the SCSI-2 standard.  SIP is intended to be a fully compliant expression of the 
SCSI-3 Architecture Model (SAM). 


2. References
2.1 Normative references

The SCSI-3 Architecture Model (X3T10-xxxx) defines the conceptual structure and base requirements for SCSI-3.

The SCSI-3 Parallel Interface (X3T10-xxxx) defines the bus conditions, phase sequences, messaging, 
and interlocked-specific functions and and status needed to support the Parallel Interface.

The group of SCSI-3 command set documents (see below) defines the device-specific command sets used by both 
the SCSI-3 Packetized Protocol and the SCSI-3 Interlocked Protocol.

X3T10/995D
Primary Commands
X3T10/996D
Block Commands
X3T10/997D
Streaming Commands
X3T10/998D
Graphics Commands
X3T10/999D
Medium Changer Commands
X3T10/1047D
Controller Commands
X3T10/1048D
Multi-Media Commands

2.2 Informative reference
American National Standard Small Computer System Interface - 2, X3.131-1994, may also be useful to 
achieve compatibility with devices that conform to version 2 of SCSI.

3. Glossary, abbreviations, and conventions
3.1 	Glossary
Editors note: I have only made minor changes to the glossary from the May 1993 version.  I believe a more 
major update is due.  Feel free to make suggestions.
3.1.1 accept (a command): 

A received command is accepted by a logical unit when it passes vali-
dation.
3.1.2 auto-contingent allegiance (ACA):  

A condition established in a target when an error is detected.
3.1.3 ASCII BYTE: 

A byte whose value is interpreted for graphic presentation according to the ASCII 
collating sequence.
3.1.4 asynchronous event notification: 

A procedure used by targets to notify initiators of events 
that occur when a pending task does not exist (e.g., unit attention or medium removal).
3.1.5 assigned: 

A Target Controller Function is assigned when it is permitted to accept tasks 
only from certain Path Groups.
3.1.6 block:  

A logical or physical byte string.
3.1.7 block peripheral device: 

A peripheral device which is in one of the following device classes: 
direct access, write once, CD-ROM, or optical memory.
3.1.8 byte: 

In this standard, this term indicates an 8-bit (octet) construct.
3.1.9 byte string:  

A contiguous set of ASCII bytes.
3.1.10 command parameter data: 

A collection of zero or more fields provided by an initiator as an 
addendum to some command descriptor blocks. 
3.1.11 command response data:  

A collection of zero or more fields provided by a target in 
response to some commands (e.g., Sense Data).
3.1.12 connect:  

An initiator function that selects a target for the purpose of establishing a nexus and 
starting a task.  The connection that results is an initial connection.
3.1.13 connection:  

An initial connection or reconnection.  A connection can only occur between one 
initiator and one target on the same bus.  A connection begins when conditions exist between an 
initiator and a target for information transfer.  A connection ends with the next disconnect.
3.1.14 current task:

A task that is in the process of sending status or transferring command data to or from the initiator.
3.1.15 disconnect: 

The action that occurs when a SCSI device releases control of the SCSI bus, 
allowing it to go to the BUS FREE phase.
3.1.16 dual port:  

SCSI devices may provide two SCSI connectors in a dual port configuration that 
allows any port to connect to the attached logical unit(s). 
3.1.17 field: 

A set of one or more contiguous bits.
3.1.18 flag
An abstraction indicating that the condition being described will be communicated to the recipient of the flag, as in 
the statement "the status indication contains status and the parity flag".  No particular form of implementation is 
prescribed. 
3.1.19 initial connection: 

An initial connection is the result of a connect.  It exists from the assertion 
of the BSY signal in a SELECTION service until the next BUS FREE indication occurs.
3.1.20 initiator: 

A SCSI device (usually a host system) that requests a task to be performed 
by another SCSI device (a target).
3.1.21  initiator role: 

The mode of operation of a port in which the port performs initiator functions.
3.1.22  invalid: 

An illegal, reserved, or unsupported bit, field, code value, bus phase, or protocol

3.1.23 I_T nexus: 

A nexus which exists between an initiator and a target.
3.1.24 I_T_L nexus: 

A nexus which exists between an initiator, a target, and a logical unit.  This rela-
tionship replaces the prior I_T nexus.
3.1.25 I_T_L_Q nexus: 

A nexus between an initiator, a target, a logical unit, and a queue tag following 
the successful receipt of one of the queue tag messages.  This relationship replaces the prior 
I_T_L nexus.
3.1.26 I_T_L_y nexus: 

A nexus which is either an I_T_L or I_T_L_Q.
3.1.27 logical block: 

A unit of data supplied or requested by an initiator usually for a peripheral 
device. A logical block may be fixed or variable in length.
3.1.28 logical block data:  

A sequence of bytes from or to a logical block.
3.1.29 logical unit: 

An addressable function within a target that implements the SPI model.  A logical 
unit is addressed by the logical unit number, and it has a command set.
3.1.30 logical unit number: 

The address of a logical unit.
3.1.31 message:  

One or more bytes transferred between an initiator and a target for the purpose of 
controlling the nexus.
3.1.32 nexus: 

A relationship between an initiator and a target that begins with an initial connection and 
ends with the completion of the associated I/O process.  The relationship may be restricted to a 
single logical unit using the identify function.  Each initiator and target may have zero or more nex-
uses established at a time.  The relationship may be further restricted by the successful transfer of 
a queue tag message.  For dual port implementations, the relationship is restricted to the port on 
which the initial connection was established.
3.1.33 one: 

A true signal value or a true condition of a variable. A field value numerically equal to 1b.
3.1.34 port: 

The portion of a SCSI device that attaches to the SCSI bus. A SCSI device may have 
more than one port. Each port may attach to a different bus.
3.1.35 queue: 

See task set.
3.1.36 queue tag: 

The parameter associated with a task that uniquely identifies it from other 
tagged tasks for a logical unit from the same initiator.
3.1.37 pending task: 

A task tht is not the current task.
3.1.38 receive (a command): 

A command is received after it has been transferred from an Initiator to 
a Target.
3.1.39 reconnect: 

The act of reviving a nexus to continue a task. A target completes when 
conditions are appropriate for the physical bus to transfer data associated with a nexus between 
an initiator and a target.
3.1.40 reconnection: 

A reconnection is the result of a reconnect. After a connect, a reconnection 
exists from the end of a reconnect until the next disconnect.
3.1.41 reject (a command): 

A received command is rejected by a Logical Unit or Target Routine 
when it fails validation.
3.1.42 reserved: 

The term used for fields, code values, and bus phases set aside for future standard-
ization.
3.1.43 SCSI Command Processing: 

SCSI commands are processed in the following order:
3.1.44 SPI ID:  

The bit-significant representation of the address referring to one of the data bus signal 
lines available to the SPI device, excluding parity signals.
3.1.45 target: 

An SPI device that performs a task requested by an initiator.
3.1.46 target role: 

The mode of operation of a port in which the port performs target functions.
3.1.47 task: 

A task consists of one initial connection and zero or more reconnections, 
all pertaining to a single command or a group of linked commands.  More specifically, the connec-
tion(s) pertain to a nexus as defined below in which zero or more command descriptor blocks are 
transferred. A task begins with the establishment of a nexus.  A task normally 
ends with the BUS FREE indication following successful transfer of a COMMAND COMPLETE 
message.  A task also ends with the BUS FREE indication following an ABORT TASK 
SET, ABORT TASK, TARGET RESET, or CLEAR TASK SET task management service or when a 
hard RESET condition or an unexpected disconnect occurs.
3.1.48 task set:  

A group of tasks within a target device, whose interaction is dependent on the queueing and auto-contingent 
allegiance rules of SAM. 
3.1.49 unexpected disconnect:

A disconnection that occurs because of a protocol error.
3.1.50 validate (a command): . 

A command is validated when a Logical Unit verifies that all fields 
contain legal values.
3.1.51 vendor specific (VS): 

Something (e.g., a bit, field, code value, etc.) that is not defined by this 
standard and may be used differently in various implementations.
3.1.52 zero: 

A field with a value of 0b in each bit position. A false signal value or a false condition of a 
variable.

3.2 Abbreviations

	ACA		Auto-contingent allegiance
	
	LSB  		Least significant bit.

	LUN		Logical unit number.

	MSB		Most significant bit.

	SAM		SCSI-3 Architecture Model	

	SCSI		The Small Computer System Interface

	SPI   		SCSI-3 Parallel Interface.

3.3 Editorial conventions

Certain words and terms used in this International Standard have a specific meaning beyond the normal 
English meaning.  These words and terms are defined either in clause 3 or in the text where they 
first appear.  Names of signals, phases, messages, commands, statuses, sense keys, additional 
sense codes, and additional sense code qualifiers are in all uppercase (e.g.  REQUEST SENSE).  
Lower case is used for words having the normal English meaning.

Fields containing only one bit are usually referred to as the "name" bit instead of the "name" field.

Numbers that are not immediately followed by lower-case "b" or "h" are decimal values.

Numbers immediately followed by lower-case "b" (xxb) are binary values.

Numbers immediately followed by lower-case "h" (xxh) are hexadecimal values.

A  mathematical expression representing the number m raised to the nth power is written as 'm**n'. In 
SCSI, both m and n are integer decimal numbers.

4. SIP Reference Model

This section summarizes the behavior of SIP implementations at an abstract level.  It is derived from, and intended 
to be compliant with, the SCSI-3 Architecture Model (SAM).  

In the SAM model there are three layers, as shown in Figure 1.  These are part of the layered client-server 
architecture of SCSI-3.  See the SAM document for a full description.


Figure 1 - SCSI-3 Architecture Layers




















 









The SCSI-3 Interlocked Protocol (SIP) described in this document is one implementation of the SCSI-3 Protocol 
Layer.  

Transactions between  equivalent layers of an initator and target take place through a service interface with the next 
lower level until the physical interconnect is reached.  At any service interface, the transaction  is divided into 4 
steps:

1. Request
The upper layer client issues a request to the lower layer for transmission to 
the server.
2. Indication
After passing through whatever layers and conversions are necessary, the 
information necessary to execute the request is passed to the upper layer 
server as an indication.
3. Response
Upon completion of the request, the upper level server issues a response to 
the lower layer for transmission to the client.
4. Confirmation
The upper level client is notified of the outcome of its request by receipt of a 
confirmation from the lower layer.


4.1 Services provided to the application layer
4.1.1 SAM device server requests

[Briefly describe command execution request here]
4.1.2 SAM task management requests

[Briefly describe task management requests here.  Reference readers to messages section.]

4.2 Services requested of the physical interconnect layer

The physical interconnect layer defined to work with SIP is the SCSI-3 Parallel Interface (SPI).
See the SPI document for a description of the physical interface.
4.2.1 Bus free service

A bus free service requests an unconfirmed service which generates a bus free phase.  This ser-
vice shall only be requested by SIP while operating in a target role.

4.2.2 Reset service

A reset service requests an unconfirmed service which generates a SCSI bus reset. The reset 
service may be requested at any time by SIP while operating in either a target role or an initiator 
role.   If a reset indication is received and the SIP is operating in a target role the SIP shall request a 
Bus Free service as its next action.

4.2.3 Selection service 

A selection service request is a confirmed service that combines the arbitration phase and the 
selection phase.  The selection service establishes an initial connection.  This service shall only 
be requested by SIP while operating in an initiator role. 


Selection request

The selection request contains the SCSI ID of the device to be selected and shall 
set the attention flag.  The attention flag is set to inform a target role SIP that a 
Message Out Phase is being requested from an initiator role SIP.

Selection indication

The selection indication contains the selection ID's, the atten-
tion flag, and the parity flag.  The attention flag when set informs the target 
role SIP that a message out phase is being requested from an initiator role SIP.  
The parity flag when set informs the target role SIP that SPI detected a parity 
error on the SCSI bus.
[GOP - What to do when SCSI ID's are not valid (1 or more than one).  

Selection response

The selection response contains a selection accepted flag.  The selection 
accepted flag is set by a target role SIP to inform SPI of a valid selection. 

Selection confirmation

The selection confirmation contains the arbitration lost flag, a selection won 
flag, and a the selection time-out flag.  The arbitration lost flag when set 
informs the initiator role SIP that SPI lost the arbitration.  The selection won 
flag when set informs the initiator role SIP that the target role SIP has accepted 
the selection requested and an I_T nexus has been created.  The selection time-
out flag when set informs the initiator role SIP selection was lost because of a 
time-out detected by SPI during the selection phase.


4.2.4 Reselection service 

The reselection service request is a confirmed service that combines the  arbitration phase and 
the reselection phase.  The reselection service provides a means to reconnect.  This service 
shall only be requested by SIP while operating in a target role.
Reselection request

The reselection request contains the SCSI ID of the device to be reselected.

Reselection indication

The reselection indication contains the reselection ID's and the parity flag.  
The parity flag when set informs the initiator role SIP that SPI detected a 
parity error.

Reselection response

The reselection response contains a reselection accepted flag.  The reselection 
accepted flag is set by an initiator role SIP to inform SPI of a valid 
reselection.

Reselection confirmation

The reselection confirmation contains the arbitration lost flag, a reselection 
won flag, and a the selection time-out flag.  The arbitration lost flag when set 
informs the target role SIP that SPI lost the arbitration.  The reselection won 
flag when set informs the target role SIP that the initiator role SIP has 
accepted the reselection requested and an I_T nexus has been created.  The 
selection time-out flag when set informs the target role SIP reselection was 
lost because of a time-out detected by SPI during the reselection phase.




4.2.5 Command service

The command service request is a confirmed service that provides the means to transfer a single 
command byte from the initiator to the target.  This service shall only be requested by SIP while 
operating in a target role.
Command request

The command request contains no parameters.

Command indication

The command indication contains no parameters.

Command response

The command response contains the command byte and the attention flag.  
The attention flag is set to inform a target role SIP that a message out phase is 
being requested from an initiator role SIP.

Command confirmation

The command confirmation contains the command byte, the attention flag and 
the parity flag.  The attention flag when set informs the target role SIP that a 
message out phase is being requested from an initiator role SIP.  The parity 
flag when set informs the target role SIP that SPI detected a parity error on the 
SCSI bus.



4.2.6 Data out service

The data out service request is a confirmed service that provides the means to transfer a data 
word from the initiator to the target. This service shall only be requested by SIP while operating in 
a target role.
Data out request

The data out request contains the data bus width, the transfer period, and the 
REQ/ACK offset.

Data out indication

The data out indication contains no parameters.

Data out response

The data out response contains the data word and the attention flag.  The 
attention flag is set to inform a target role SIP that a message out phase is being 
requested from an initiator role SIP.

Data out confirmation

The data out confirmation contains the data word, the attention flag and the 
parity flag.  The attention flag when set informs the target role SIP that a 
message out phase is being requested from an initiator role SIP.  The parity flag 
when set informs the target role SIP that SPI detected a parity error on the SCSI 
bus.










4.2.7 Data in service

The data in service is a confirmed service that provides the means to transfer a data word from 
the target to the initiator.  This service shall only be requested by SIP while operating in a target 
role.



Data in request

The data in request contains the data word, the data bus width, the transfer 
period, and the REQ/ACK offset.

Data in indication

The data in indication contains data word and the parity flag.The parity flag 
when set informs the initiator role SIP that SPI detected a parity error on the 
SCSI bus.

Data in response

The data in response contains the attention flag.The attention flag is set to inform 
a target role SIP that a message out phase is being requested from an initiator 
role SIP.

Data in confirmation

The data in confirmation contains the attention flag.  The attention flag when set 
informs the target role SIP that a message out phase is being requested from an 
initiator role SIP.





4.2.8 Status service

The status service request is a confirmed service that provides the means to transfer a status 
byte from the target to the initiator.  This service shall only be requested by SIP while operating in 
a target role.
Status request

The status request contains the status byte.

Status indication

The status indication contains status and the parity flag.  The parity flag when set 
informs the initiator role SIP that SPI detected a parity error on the SCSI bus.

Status response

The status response contains the attention flag.  The attention flag is set to inform 
a target role SIP that a message out phase is being requested from an initiator role 
SIP.

Status confirmation

The status confirmation contains the attention flag.  The attention flag when set 
informs the target role SIP that a message out phase is being requested from an 
initiator role SIP.





4.2.9 Message out service

The message out service request is a confirmed service that provides the means to transfer a 
single message out byte from the initiator to the target.  This service shall only be requested by 
SIP while operating in a target role.

Message out request

The message out request contains no parameters.

Message out indication

The message out indication contains no parameters.

Message out response

The message out response contains the message out byte and the attention 
flag.  The attention flag when set informs the target role SIP and SPI that the 
initiator role SIP has another message byte to transfer.

Message out confirmation

The message out confirmation contains the message out byte, the attention 
flag and the parity flag.The attention flag when set informs the target role 
SIP that an initiator role SIP is requesting the message out phase be 
continued.  The parity flag when set informs the target role SIP that SPI 
detected a parity error on the SCSI bus.



4.2.10 Message in service

The message in service request is a confirmed service that provides the means to transfer a 
message in byte from the target to the initiator.  This service shall only be requested by SIP while 
operating in a target role.
Message in request

The message in request contains the message in byte.

Message in indication

The message in indication contains message in byte and the parity flag.  The 
parity flag when set informs the initiator role SIP that SPI detected a parity 
error on the SCSI bus.

Message in response

The message in response contains the attention flag.  The attention flag is set 
to inform a target role SIP that a message out phase is being requested from 
an initiator role SIP.

Message in confirmation

The message in confirmation contains the attention flag.  The attention flag 
when set informs the target role SIP that a message out phase is being 
requested from an initiator role SIP.











5. SIP Conditions


The SCSI  interlocked protocol  notifies the SCSI application layer of the following conditions:

1. An attention condition;
 
2. A reset condition;
 
3. A parity condition;
 
4. A bus free condition.

These conditions cause the SCSI device to perform certain actions and can alter the phase 
sequence. The attention condition is the result of the attention flag being set.  The reset condition 
is caused by a reset indication.  The parity condition is the result of the parity flag being set. The 
bus free condition is caused by a bus free indication.  These events are described in the SCSI 
Parallel Interface document.

At power on, a SCSI device should be able to respond with appropriate status and sense data 
to the TEST UNIT READY, INQUIRY, CHANGE DEFINITION, and REQUEST SENSE com-
mands after a power-on to selection time.

5.1 Attention condition

The attention condition allows the initiator's SIP layer to inform a target SIP that the initiator has 
a message sequence  to send.  The target SIP may  receive this message sequence by request-
ing a message out service.

A target SIP shall respond to an attention condition as follows:

A. If the attention flag is set in a command confirmation the target SIP shall request a message out service after 
transferring all or part  of the command descriptor block.
 
B. If the attention flag is set in a data out confirmation or data in confirmation the target SIP shall request a 
message out service as soon as possible.  The initiator shall continue to respond to data out and data in 
indications until it receives a message out indication.
 
C. If the attention flag is set in a status confirmation, the target SIP shall request a message out service.
 
D. If the attention flag is set in a message in confirmation, the target SIP shall request a mes-sage out service 
before it requests another message in service.  This permits a MESSAGE PARITY ERROR message from the 
initiator to be associated with the appropriate message.
 
E. If the attention flag is set in a selection indication the target SIP shall request a message out service.
 
F. If the attention flag is set during a reselection service, the target SIP shall request a message out service after it 
has received a message in confirmation for the IDENTIFY message.
 
G. If the attention flag is set in a message out confirmation the target SIP shall request a message out service.
 
5.2 Reset condition

The reset condition shall take precedence over all other services and conditions.  Any SCSI 
device may cause a reset condition by requesting a reset service.

The effect of the reset condition on all I/O processes, SCSI device reservations, and SCSI device 
operating modes is determined by whether the SCSI device has implemented the hard reset 
alternative or the soft reset alternative.  Either the hard or the soft reset alternative shall be imple-
mented.  The hard and soft reset alternatives are mutually exclusive within a system.  A facility 
for targets to report which reset alternative is implemented is provided by the SftRe bit of the 
INQUIRY data.

5.2.1 Hard reset alternative

SCSI devices that implement the hard reset alternative, upon detection of the reset condition, shall: 

1. Clear all I/O processes.
 
2. Release all SCSI device reservations. 
 
3. Return any SCSI device operating modes to their initial conditions, similar to those conditions that would be  
found after a normal power-on reset.  MODE SELECT conditions  shall be restored to their last saved values if 
saved values have  been established.  MODE SELECT conditions for which no saved  values have been saved 
shall be returned to their default values. 
 
4. Unit attention condition shall be set.

It is recommended that, following a reset to selection time after  a hard reset condition ends, 
SCSI targets be able to respond with  appropriate status and sense data to the TEST UNIT 
READY, INQUIRY, and REQUEST SENSE commands.

In dual port implementations, the SCSI device shall apply the hard reset only to the port on which 
the reset indication was received.  In this case:

1. all I/O processes on the port not reset are unaffected;
 
2. reservations on the port not reset are preserved;
 
3. operating modes on the port not reset are not changed;
 
4. unit attention is only generated on the reset port unless mode parameters affecting the port not reset are 
changed.

5.2.2 Soft reset alternative

SCSI devices that implement the soft reset alternative, upon detection of the reset condition, shall:

1. preserve SCSI device reservations;
 
2. preserve SCSI device operating modes;
 
3. preserve all pending tasks at the time of reset;
 
4. perform reset operation (this is vendor-specific);
 
5. attempt to complete any  tasks that were fully identified.

The soft reset alternative allows an initiator to reset the SCSI bus with minimum disruption to the 
operation of other initiators in a multiple initiator system.  To ensure proper operation: 

A. An initiator shall not consider a task to be fully identified until an indication other than a message out 
indication is received.
 
B. A target shall consider a task to be fully identified when it receives a message out confirmation with the 
attention flag cleared during the initial connection.
 
C. If an initiator creates an I_T_L_Q nexus for which there already is an active I/O process with the same nexus, 
the target shall abort the original I/O process and perform the new I/O pro-cess.
 
D. If a target creates an I_T_L_Q nexus for an I/O process for which the initiator has no record, the initiator shall 
abort that I/O process.
 
E. If the reset condition occurs between the time that the target requests the message in service for the SAVE 
DATA POINTER message and the confirmation is received, the target shall terminate the task with CHECK 
CONDITION status.  The target shall set the sense key to ABORTED COMMAND.  This is necessary because 
the target cannot deter-mine whether the data pointer has actually been saved.

If the attention condition exists on the confirmation for the SAVE DATA POINTERS or COM-
MAND COMPLETE messages, the target would normally switch to MESSAGE OUT phase and 
attempt to transfer a message byte.  If the reset condition occurs before the target receives the 
message in confirmation, it may assume that the initiator has not successfully received the COM-
MAND COMPLETE message or the SAVE DATA POINTER message.  In the case of COM-
MAND COMPLETE message, the target may reselect the initiator and attempt to send the 
COMMAND COMPLETE message again.  In the case of the SAVE DATA POINTER message, 
the target may rerequest a reselect service and abort the task.

5.3 Parity condition

The parity condition is created by the receipt of the parity flag with a value of one during the indication or 
confirmation stage of a SCSI transaction.  This indicates that a byte with even parity was detected during a parallel 
bus transfer.
5.4 Unexpected bus free condition

The Unexpected Bus Free condition is created by a Bus Free Indication which is unexpected by 
the initiator. Initiators normally do not expect a Bus Free Indication except after  one of the follow-
ing occurrences:

1. after a Reset Indication has been received;
 
2. after an ABORT message is successfully received by a target;
 
3. after a BUS DEVICE RESET message is successfully received by a target;
 
4. after a DISCONNECT message confirmation is successfully received by a target;
 
5. after a COMMAND COMPLETE message is successfully sent from a target
 
6. after a RELEASE RECOVERY message is successfully received by a target;
 
7. after an ABORT TAG message is successfully received by a target;
 
8. after a CLEAR QUEUE message is successfully received by a target.
 
9. after an unsuccessful selection or reselection.

If a SPI device in an initiator role detects a Bus Free indication at any other time an Unexpected 
Bus Free condition is said to exist. A target uses this condition to inform an initiator of a protocol 
error.  The target may create the Unexpected Bus Free condition independent of the existence of 
the Attention Condition.

The initiator shall manage this condition as an unsuccessful I/O process termination.  The target 
terminates the I/O Process by clearing all pending data and status information for the affected 
nexus.  The target may optionally prepare sense data that may be retrieved by a REQUEST 
SENSE command. When an initiator detects an Unexpected Bus Free Condition, it is recom-
mended that a REQUEST SENSE command be attempted to obtain any valid sense data that 
may be available.

6. SCSI Interlocked Protocol Message System Description
6.1 Overview
The message system allows communication between an initiator and target for the purpose of 
link and task management.   One or more messages may be sent during a single MESSAGE phase, but a message 
may not be split over MESSAGE phases.

One-byte, Two-byte, and Extended message formats are defined.  The first byte of the message 
determines the format as defined in Table 2.

Table 2 -Message Format

Value
Message Format
00h

One-Byte Message (COMMAND COMPLETE)

01h

Extended Messages 

02h - 1Fh

One-Byte Messages

20h - 2Fh

Two-Byte Messages

30h - 7Fh

Reserved
80h - FFh

One-Byte Message (IDENTIFY)

6.1.1 One-byte and two-byte messages

One-byte messages consist of a single byte transferred during a MESSAGE phase.  The value of 
the byte determines which message is to be performed as defined in Table 3.

Two-byte messages consist of two consecutive bytes transferred during a MESSAGE phase.  
The value of the first byte determines which message is to be performed as defined in Table 3.  
The second byte is a parameter byte which is used as defined in the message description.


Table 3 -Message Codes

Code
Support
Message Name
Direction
Negate ATN 
Before Last ACK

Initiator

Target





06h
O
M
ABORT 

Out
Yes
0Dh
O
O
ABORT TAG (Note 1)

Out
Yes
24h
M
M
ACA TAG

Out
Not Required
0Ch
O
M
BUS DEVICE RESET

Out
Yes
14h
O
M
BUS DEVICE RESET
 OTHER PORT (Note 3)

Out
Yes
0Eh
O
O
CLEAR QUEUE (Note 1)

Out
Yes
16h
M
M
CLEAR ACA

Out
Not Required
00h
M
M
COMMAND COMPLETE
In

n/a
12h
O
O
CONTINUE I/O PROCESS

Out
Yes
04h
O
O
DISCONNECT
In

n/a
04h
O
O
DISCONNECT

Out
Yes
21h
O
O
HEAD OF QUEUE TAG

Out
Not Required
80h+
M
O
IDENTIFY
In

n/a
80h+
M
M
IDENTIFY

Out
Not Required
23h
O
O
IGNORE WIDE RESIDUE 
In

n/a
05h
M
M
INITIATOR DETECTED ERROR

Out
Yes
0Ah
O
O
LINKED COMMAND 
COMPLETE
In

n/a
0Bh
O
O
LINKED COMMAND 
COMPLETE (WITH FLAG)
   In

n/a
09h
M
M
MESSAGE PARITY ERROR

Out
Yes
07h
M
M
MESSAGE REJECT
In
Out
Yes
***
O
O
MODIFY DATA POINTER
In

n/a
08h
M
M
NO OPERATION

Out
Yes
Key:	M=Mandatory support, O=Optional support
	In=Target to initiator, Out = Initiator to target
	Yes = Initiator shall negate ATN before last ACK of message
	Not Required = Initiator may or may not negate ACK before last ACK of message
	n/a = Not applicable
	*** = Extended message
	80h+ = Codes 80h through FFh are used for IDENTIFY messages

Notes:
1.  The ABORT TAG and CLEAR QUEUE messages are required if tagged queuing is implemented.
2.  The BUS DEVICE RESET OTHER PORT message is required if the dual port option is implemented.



Table 3 -Message Codes(continued)


Code
Support
Message Name
Direction`
Negate ATN 
Before Last ACK

Initiator
Target




22h
O
O
ORDERED QUEUE TAG

Out
Not Required
03h
O
O
RESTORE POINTERS
In

n/a
02h
O
O
SAVE DATA POINTER
In

n/a
20h
O
O
SIMPLE QUEUE TAG
In

Not Required
***
O
O
SYNCHRONOUS DATA 
TRANSFER REQUEST
In
Out
Yes
13h
O
O
TARGET TRANSFER DISABLE

Out
Yes
***
O
O
WIDE DATA TRANSFER 
REQUEST
In
Out
Yes
11h
O
O
TERMINATE TASK

Out
Yes
15h-1Fh


Reserved



24h-2Fh


Reserved



30h-7Fh


Reserved



Key:	M=Mandatory support, O=Optional support
	In=Target to initiator, Out = Initiator to target
	Yes = Initiator shall negate ATN before last ACK of message
	Not Required = Initiator may or may not negate ACK before last ACK of message
	n/a = Not applicable
	*** = Extended message
	80h+ = Codes 80h through FFh are used for IDENTIFY messages

Notes:
1.  The ABORT TAG and CLEAR QUEUE messages are required if tagged queuing is implemented.
2.  The BUS DEVICE RESET OTHER PORT message is required if the dual port option is implemented.



6.1.2 Extended messages

A value of  01h in the first byte of a message indicates the beginning of a multiple-byte extended 
message. The minimum number of bytes sent for an extended message is three.  The extended 
message format and the extended message codes are shown in Tables 4 and 5, respectively.


Table 4 -Extended Message Format

Bit
7
6
5
4
3
2
1
0
Byte








0
Extended Message (01h)
1
Extended Message Length (n)
2
Extended Message Code (y)
3-n
Extended Message Arguments



The extended message length specifies the length in bytes of the extended message code plus 
the extended message arguments to follow.  Therefore, the total length of the message is equal 
to the extended message length plus two.  A value of zero for the extended message length indi-
cates 256 bytes follow.

The extended message codes are listed in Table 5.  The extended message arguments are 
specified within the extended message descriptions.

Table 5 -Extended Message Codes


Code (y)
Description
00h
MODIFY DATA POINTER
01h
SYNCHRONOUS DATA TRANSFER REQUEST
02h
Reserved (see note below)
03h
WIDE DATA TRANSFER REQUEST
04h-07h
Reserved
80h-FFh
Vendor Specific
             Note: Extended message code 02h was used for the EXTENDED IDENTIFY message in SCSI-1.


6.1.3 Rules for messages

The first message sent by the initiator after the SELECTION phase shall be an IDENTIFY, 
ABORT, or BUS DEVICE RESET message.  If a target receives any other message it shall issue 
a BUS FREE request (see Unexpected Bus Free condition, 5.1.3)

If the first message is an IDENTIFY message, then it may be immediately followed by other mes-
sages, such as the first of a pair of SYNCHRONOUS DATA TRANSFER REQUEST messages.  
If tagged queuing is used the queue tag message immediately follows the IDENTIFY message.  
The IDENTIFY message establishes a logical connection between the initiator and the specified 
logical unit within the target known as an I_T_L nexus.  After the RESELECTION phase, the tar-
get's first message shall be IDENTIFY.  This allows the I_T_L nexus to be re-established.  Only 
one logical unit shall be identified for any connection; if a target receives a second IDENTIFY 
message with a different logical unit number during a connection, it shall issue a BUS FREE 
request. 

All initiators shall implement the mandatory messages tabulated in the "Initiator" column of Table 3.  
All targets shall implement the mandatory messages tabulated in the "Target" column of Table 3. 

The initiator is required to end the MESSAGE OUT phase (by clearing the attention flag in a MESSAGE OUT 
response) when it sends certain messages identified in Table 3.  These are identified by a "Yes" entry in the column 
headed "Negate ATN Before Dropping ACK".

Whenever an I_T_L nexus is established by an initiator that is allowing disconnection, the initia-
tor shall ensure that the active pointers are equal to the saved pointers for that particular logical 
unit.  An implied restore pointers operation shall occur as a result of a reconnection.
6.2 Task management messages
6.2.1 ABORT

The ABORT message implements the SAM Abort Task Set task management function.
In response to this message, the target shall clear all tasks for the I_T_L nexus.
Upon successful receipt of this message and completion of the specified function, the target shall 
issue a BUS FREE indication. The pending data, status and tasks for any other I_T_L 
nexus shall not be cleared. 

If only an I_T nexus has been established, the target shall issue a BUS FREE request.  No status 
or message shall be sent for the current task and no other task shall be affected.

The ABORT message in the case of only an I_T nexus is useful to an initiator that cannot get an 
IDENTIFY message through to the target due to parity errors and just needs to end the current 
connection.  No pending data, status, or tasks are affected.

It is not an error to issue this message to an I_T_L nexus that does not have any pending or current tasks.
6.2.2  ABORT TAG
The ABORT TAG message implements the SAM Abort task task management function.
The target shall issue a BUS FREE indication following the successful receipt of this message and completion of 
the specified function. The target shall clear the current task. Any pending status or data for the task shall be 
cleared and no status or ending message shall be sent to the initiator. 
Other tasks for the I_T_L nexus shall not be affected.

On a reconnection, the ABORT TAG message aborts the current task if it is fully identi-
fied. If the task is not fully identified (i.e., an I_T_L nexus exists, but the target is recon-
necting for an I_T_L_Q nexus), then the task is not aborted and the target issues a BUS 
FREE request.

6.2.3 BUS DEVICE RESET

The BUS DEVICE RESET message implements the SAM Target Reset task management function.
This message is sent from an initiator to direct a target to clear all tasks on that SCSI device. 
This message has the same effect as a reset condition with the hard reset alternative to the 
selected SCSI device. The target shall issue a BUS FREE request following successful receipt of 
this message and completion of the specified function. 

Editor's note: should there be a statement here about not clearing assigned Ids of SCAM devices?
6.2.4 BUS DEVICE RESET OTHER PORT

The BUS DEVICE RESET OTHER PORT message implements the SAM Target Reset Other Port task 
management function.  This message   shall be implemented if the device implements the dual port option.   The 
BUS DEVICE RESET OTHER PORT message is sent from an initiator to direct a target to 
clear  all tasks associated with the other port on that SCSI device. The target shall issue 
a BUS FREE indication upon successful receipt of this message and completion of the specified 
function.


<<Should the bus device reset message cause a bus free on the other port? GOP yes>>
6.2.5 CLEAR ACA

The CLEAR ACA message implements the SAM Clear Auto Contingent Allegiance task management function.  
The target shall issue a BUS FREE indication upon successful receipt of this message and 
completion of the specified function.

It is not an error to issue a CLEAR AUTO CONTINGENT ALLEGIANCE message when no ACA 
condition is in effect.

6.2.6 CLEAR QUEUE
The CLEAR QUEUE message implements the SAM Clear Task Set task management function.

The target shall issue a Bus Free indication upon successful receipt of the message and completion of the 
specified function.  The target shall perform an action equivalent to receiving a series of ABORT messages from 
each initiator. All tasks, from all initiators, in the task set for the specified logical unit shall be cleared from the 
task set. The medium may have been altered by partially executed com-
mands. All pending status and data for that logical unit for all initiators shall be cleared. No status 
or message shall be sent for any of the tasks. A unit attention condition shall be generated for all other initiators 
that had pending tasks in the task set when the CLEAR QUEUE message was received.  The additional sense code 
shall be set to COMMANDS CLEARED BY ANOTHER INITIATOR.

For dual port implementations, only tasks for the port from which the message was 
received are affected.  No tasks are cleared for the other port and no unit attention con-
ditions are generated for initiators on the other port. 

Previously established conditions, including MODE SELECT parameters, reservations, and  auto 
contingent allegiance shall not be changed by the CLEAR QUEUE message.


6.2.7 TERMINATE TASK

The TERMINATE TASK message implements the SAM Terminate task task management function.  This message 
is sent from the initiator to the target to terminate the task without corrupting the medium.

If the target does not support this message or is unable to stop the current task, it shall send a MESSAGE REJECT 
message to the initiator and continue the task in a normal manner.



Table 6 summarizes the effect of the ABORT, ABORT TAG, BUS DEVICE RESET, BUS DEVICE RESET 
OTHER PORT, and CLEAR QUEUE messages on tasks.



Table 6 -Task Initialization Messages



BUS 
DEVICE 
RESET
BUS 
DEVICE 
RESET 
OTHER 
PORT
CLEAR QUEUE

ABORT

ABORT TAG
Current 
Nexus
Any
Any
I_T
I_T_x_y
I_T
I_T_x_y
I_T
I_T_x_y
Current 
Process 
Cleared
Yes
Yes
Note 1
Yes
Yes
Yes
Note 1
Yes
Pending 
Processes 
Cleared
Yes
Yes
Note 1
Yes
No
Yes
Note 1
No
For Which 
Initiators
All
All
Note 1
All
Selecting
Selecting
Note 1
Selecting
Mode 
Parameters 
Initialized
Yes
Yes
Note 1
No
No
No
Note 1
No
ACA Cleared
Yes
Yes
Note 1
No
No
No
Note 1
No
CA Cleared 
Note 2
Yes
Yes
Note 1
Yes
Yes
Yes
Note 1
Yes
Reservations 
Cleared
Yes
Yes
Note 1
No
No
No
Note 1
No
Unit 
Attention 
Established
Yes,
all initiators
Yes,
all initiators
Note 1
Yes,  all 
except 
selecting 
initiator 
No
No
Note 1
No
Note 1: It is illegal for an initiator to issue this message with only an I_T nexus established

Note 2: Applies to SCSI-2 targets in a SCSI-3 evironment..


6.3 Link management messages
6.3.1 COMMAND COMPLETE

The COMMAND COMPLETE message is sent from a target to an initiator to indicate that an I/O 
process has completed and that valid status has been sent to the initiator.  After successfully 
sending this message, the target issue a bus free request.  The target shall consider the mes-
sage transmission to be successful on receipt of a message in confirmation with the attention 
flag cleared.

The task may have completed successfully or unsuccessfully as indicated in the status.


6.3.2 CONTINUE I/O PROCESS

Editors note: should the name of this message be changed to CONTINUE TASK?

The CONTINUE I/O PROCESS message is sent from the initiator to the target to reconnect to an 
task.  This message shall be sent in the same MESSAGE OUT phase as the IDENTIFY 
message.

Thus the MESSAGE OUT phase following SELECTION phase consists of the IDENTIFY, queue 
tag (if any), and CONTINUE I/O PROCESS messages.

The purpose of the CONTINUE I/O PROCESS message is to distinguish a valid initiator recon-
nection from an incorrect initiator reconnection.

If the target expects a significant delay before it will be ready to continue processing the recon-
nected TASK, it may attempt to free the SCSI bus by sending a DISCONNECT mes-
sage to the initiator. The initiator may reject the disconnection attempt by responding with 
MESSAGE REJECT message.

If the CONTINUE I/O PROCESS message occurs on an initial connection then the target shall 
issue a Bus Free request.

If the CONTINUE I/O PROCESS message occurs on a subsequent connection then the target 
may either treat this as a dynamic head-of-queue request or it may reject the message with a 
MESSAGE REJECT message.

An initiator that gets rejected should assert the ATN signal and send an ABORT TAG message 
on the resulting MESSAGE OUT phase. Otherwise, the target may treat the connection as an 
incorrect initiator connection.

Initiators should avoid sending this message to targets which have not implemented this mes-
sage.  Such targets may not respond as described in this section.  An initiator can determine 
whether a target implements this message by examining the TranDis bit in the standard 
INQUIRY data (see SCSI-3 Primary Commands).

6.3.3 DISCONNECT

The DISCONNECT message is sent from a target to inform an initiator that the present connec-
tion is going to be broken, but that a later reconnect will be required in order to complete the I/O 
process.  This message shall not cause the initiator to save the data pointer.  After successfully 
sending this message, the target shall issue a Bus Free request.  The target shall consider the 
message transmission to be successful when it receives a message in confirmation with the 
attention flag cleared.

Targets which break data transfers into multiple connections shall end each successful connec-
tion (except possibly the last) with a SAVE DATA POINTER - DISCONNECT message 
sequence.

This message may also be sent from an initiator to a target to instruct the target to disconnect 
from the SCSI bus.  If this option is supported, and after the DISCONNECT message is received, 
the target shall switch to MESSAGE IN phase, send the DISCONNECT message to the initiator 
(possibly preceded by SAVE DATA POINTER message), and then issue a bus free request.  
After issuing the bus free request the target shall not issue a reselection request for at least a 
200 microseconds. If this option is not supported or the target cannot disconnect at the time 
when it receives the DISCONNECT message from the initiator, the target shall respond by send-
ing a MESSAGE REJECT message to the initiator.

6.3.4 IDENTIFY

The IDENTIFY message is sent by either the initiator or the target to establish an I_T_L nexus. 
For dual port implementations: if the target disconnects from the bus during a task, it 
shall reconnect through the same port when the task is continued.

Table 7 -IDENTIFY Message Format


Bit
7
6
5
4
3
2
1
0

Identify
DiscPriv
Reserved
LUN

The identify bit shall be set to one to specify that this is an IDENTIFY message.

A disconnect privilege (DiscPriv) bit of one specifies that the initiator has granted the target the 
privilege of disconnecting.  A DiscPriv bit of zero specifies that the target shall not disconnect.  
This bit is not defined and shall be set to zero when an IDENTIFY message is sent by a target.

The logical unit number (LUN) field specifies a logical unit number. 

An IDENTIFY message is invalid if a reserved bit is set to one.  A device may respond to an 
invalid IDENTIFY message by immediately sending a MESSAGE REJECT message or by 
returning CHECK CONDITION status.  If a CHECK CONDITION status is returned, the sense 
key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID 
BITS IN IDENTIFY MESSAGE FIELD.

Only one logical unit number shall be identified per task.  The initiator may send one or 
more IDENTIFY messages during a connection.  A second IDENTIFY message with a different 
value in the LUN field shall not be issued before a BUS FREE phase has occurred;  if a target 
receives a second IDENTIFY message with a different value in this field, it shall issue a Bus Free 
Request.  Thus an initiator may change the DiscPriv bit, but may not attempt to switch to another task.  (See the 
DTDC field of the disconnect/reconnect mode page in SCSI-3 Primary Commands for additional controls over 
disconnection.)

An implied RESTORE POINTERS message shall be performed by the initiator prior issuing a 
message in response of a message in indication for an IDENTIFY message sent during recon-
nection.









6.3.5 IGNORE WIDE RESIDUE 

Table 8 -IGNORE WIDE RESIDUE Message Format


Bit
7
6
5
4
3
2
1
0
Byte 0
Message Code (23h)
Byte 1
Number Of Bytes To Ignore (01h, 02h, 03h)

The IGNORE WIDE RESIDUE message shall be sent from a target to indicate that the number 
of valid bytes sent in the last data word of a DATA IN phase is less than the negotiated transfer 
width.  The ignorefield indicates the number of invalid data bytes transferred.  This message 
shall be sent immediately following that DATA IN phase and prior to any other messages. 

6.3.6 INITIATOR DETECTED ERROR

The INITIATOR DETECTED ERROR message is sent from an initiator to inform a target that an 
error has occurred that does not preclude the target from retrying the task.  The source of 
the error may either be related to previous activities on the SCSI bus or may be internal to the ini-
tiator and unrelated to any previous SCSI bus activity.  Although present pointer integrity is not 
assured, a RESTORE POINTERS message or a disconnect followed by a reconnect, shall 
cause the pointers to be restored to their defined prior state.

6.3.7 LINKED COMMAND COMPLETE

The LINKED COMMAND COMPLETE message is sent from a target to an initiator to indicate 
that a linked command has completed and that status has been sent.  The initiator shall then set 
the pointers to the initial state for the next linked command.
6.3.8 LINKED COMMAND COMPLETE (WITH FLAG)

The LINKED COMMAND COMPLETE (WITH FLAG) message is sent from a target to an initiator 
to indicate that a linked command (with the flag bit set to one) has completed and that status has 
been sent.  The initiator shall then set the pointers to the initial state of the next linked command.  
Typically this message would be used to cause an interrupt in the initiator between two linked 
commands.

6.3.9 MESSAGE PARITY ERROR

The MESSAGE PARITY ERROR message is sent from the initiator to the target to indicate that it 
received a MESSAGE IN indication with the parity flag set.

In order to indicate its intentions of sending this message, the initiator shall set the attention flag 
in the MESSAGE IN response for the MESSAGE IN indication which has the parity flag set.  This 
provides an interlock so that the target can determine which message byte has the parity error.  If 
the target receives this message under any other circumstance, it shall signal a catastrophic 
error condition by issuing a bus free request without any further information transfer attempt.


If after receiving the MESSAGE PARITY ERROR message the target returns to the MESSAGE 
IN phase before switching to some other phase, the target shall re-send the entire message that 
had the parity error.

6.3.10 MESSAGE REJECT

The MESSAGE REJECT message is sent from either the initiator or target to indicate that the 
last message or message byte it received was inappropriate or has not been implemented.

In order to indicate its intentions of sending this message, the initiator shall set the attention flag 
in the message in response for the message in indication that is to be rejected.  If the target 
receives this message under any other circumstance, it shall reject this message.  

When a target sends this message, it shall change to MESSAGE IN phase and send this mes-
sage prior to requesting additional message bytes from the initiator.  This provides an interlock 
so that the initiator can determine which message byte is rejected.

If the attention flag is set in the MESSAGE REJECT conformation then it shall return to the MESSAGE OUT 
phase.  The subsequent MESSAGE OUT phase shall begin with the first byte of a message.

6.3.11 MODIFY DATA POINTER

Table 9 -MODIFY DATA POINTER Message Format

Bit
7
6
5
4
3
2
1
0
Byte 0
Extended Message (01h)
Byte 1
Extended Message Length (05h)
Byte 2
MODIFY DATA POINTER (00h)
Byte 3
   --
   --
Byte 6
(MSB)
                                                    Arguments
                                                                                                                                       (LSB)


The MODIFY DATA POINTER message is sent from the target to the initiator and requests that 
the signed argument be added (two's complement) to the value of the current data pointer. The 
Enable Modify Data Pointer (EMDP) bit in the Disconnect-Reconnect mode page (see SCSI-3 
Primary Commands) indicates whether or not the target is permitted to issue the MODIFY DATA 
POINTER message.

6.3.12 NO OPERATION

The NO OPERATION message is sent from an initiator in response to a target's request for a 
message when the initiator does not currently have any other valid message to send.

For example, if the target does not respond to the attention condition until a later phase and at 
that time the original message is no longer valid the initiator may send the NO OPERATION 
message when the target enters the MESSAGE OUT phase.

6.3.13 RESTORE POINTERS

The RESTORE POINTERS message is sent from a target to direct the initiator to copy the most 
recently saved command, data, and status pointers for the task to the corresponding 
active pointers.  The command and status pointers shall be restored to the beginning of the 
present command and status areas.  The data pointer shall be restored to the value at the begin-
ning of the data area in the absence of a SAVE DATA POINTER message or to the value at the 
point at which the last SAVE DATA POINTER message occurred for that nexus.

6.3.14 SAVE DATA POINTER

The SAVE DATA POINTER message is sent from a target to direct the initiator to copy the active 
data pointer to the saved data pointer for the current task (see 5.2 for a description of 
pointers).

6.3.15 SYNCHRONOUS DATA TRANSFER REQUEST


Table 11 -Synchronous Data Transfer Request

Bit
7
6
5
4
3
2
1
0
Byte 0
Extended Message (01h)
Byte 1
Extended Message Length (03h)
Byte 2
SYNCHRONOUS DATA TRANSFER REQUEST (01h)
Byte 3
Transfer Period Factor
Byte 4
REQ/ACK Offset


SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) messages are used to negotiate a syn-
chronous data transfer agreement between two SCSI devices. The agreement applies to all logi-
cal units of both SCSI devices, regardless of the target or initiator role. That is, if SCSI device A, 
acting as an initiator negotiates a synchronous data transfer agreement with SCSI device B (in 
the target role), then the same data transfer agreement applies to SCSI devices A and B even if 
SCSI device B changes to the initiator role. 

A synchronous data transfer agreement only applies to the two SCSI devices that negotiate the 
agreement. Separate synchronous data transfer agreements are negotiated for each pair of 
SCSI devices.

An SDTR message exchange shall be initiated by a SCSI device whenever a previously-
arranged data transfer agreement may have become invalid.  The agreement becomes invalid 
after any condition which may leave the data transfer agreement in an indeterminate state such 
as:

1.	after a hard reset condition;
2.	after a BUS DEVICE RESET message and;
3.	after a power cycle.

In addition, a SCSI device may initiate an SDTR message exchange whenever it is appropriate 
to negotiate a new data transfer agreement (either synchronous or asynchronous).  SCSI 
devices that are capable of synchronous data transfers shall not respond to an SDTR message 
with a MESSAGE REJECT message.

Re-negotiation at every selection is not recommended, since a significant performance impact is 
likely. 

The SDTR message exchange establishes the permissible transfer periods and the REQ/ACK 
offsets for all logical units on the two devices.  This agreement only applies to data phases.

The transfer period factor times four is the value of the transfer period, with one exception.  A value of 12 (0Ch) 
denotes a transfer period of 50 nsec.  This is to accomodate the fact that 50 is not evenly divisible by 4, yet is a 
value that must be supported since it represents the maximum allowable speed within the Fast-20 timings specified 
for the SCSI-3 parallel interface.

The REQ/ACK offset is the maximum number of data words allowed to be outstanding before a 
DATA IN or DATA OUT response is received.  The size of a data word may be 1, 2, or 4 bytes depending on what 
values, if any, have been previously negotiated through an exchange of WIDE DATATRANSFER REQUEST 
messages.  The offset value is chosen to prevent overflow conditions in the device's reception buffer and offset 
counter.  A REQ/ACK offset value of zero shall indicate asynchronous data transfer mode; a value of FFh shall 
indicate unlimited REQ/ACK offset.
The originating device (the device that sends the first of the pair of SDTR messages) sets its val-
ues according to the rules above to permit it to receive data successfully.  If the responding 
device can also receive data successfully with these values (or smaller transfer periods or larger 
REQ/ACK offsets or both), it returns the same values in its SDTR message.  If it requires a larger 
transfer period, a smaller REQ/ACK offset, or both in order to receive data successfully, it substi-
tutes values in its SDTR message as required, returning unchanged any value not required to be 
changed.  Each device when transmitting data shall respect the limits set by the other's SDTR 
message, but it is permitted to transfer data with larger transfer periods, smaller REQ/ACK off-
sets, or both than specified in the other's SDTR message.  The successful completion of an 
exchange of SDTR messages implies an agreement as follows:

Responding Device SDTR Response
Implied Agreement
Non-zero REQ/ACK offset
Each device transmits data with a transfer period 
equal to or greater than and a REQ/ACK offset 
equal to or less than the values received in the 
responding device's SDTR message.
REQ/ACK offset equal to zero
Asynchronous transfer
MESSAGE REJECT message
Asynchronous transfer

If the initiator recognizes that negotiation is required, it asserts the ATN signal and sends a SDTR 
message to begin the negotiating process.  After successfully completing the MESSAGE OUT 
phase, the target shall respond with the proper SDTR message.  If an abnormal condition pre-
vents the target from returning an appropriate response, both devices shall go to asynchronous 
data transfer mode for data transfers between the two devices.

Following the target response of non-zero REQ/ACK offset, the implied agreement for synchronous operation shall 
be considered to be negated by both the initiator and the target if the initiator asserts the ATN signal and the first 
message out is either MESSAGE PARITY ERROR or MESSAGE REJECT. In this case, both devices shall go to 
asynchronous data transfer mode for data transfers between the 
two devices.  For the MESSAGE PARITY ERROR case, the implied agreement shall be rein-
stated if a re-transmittal of the second of the pair of messages is successfully accomplished.  
After a vendor-specific number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY 
ERROR message, it shall terminate the retry activity.  This may be done either by 
changing to any other information transfer phase and transferring at least one byte of information 
or by going to the BUS FREE phase.  The initiator shall accept such action as aborting the nego-
tiation, and both devices shall go to asynchronous data transfer mode for data transfers between 
the two devices.  

The implied synchronous agreement shall remain in effect until a BUS DEVICE RESET message 
is received, until a hard reset condition occurs, or until one of the two SCSI devices elects to 
modify the agreement.  The default data transfer mode is asynchronous data transfer mode.  The 
default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or 
after a hard reset condition.

6.3.16 Target initiated negotiation

If the target recognizes that negotiation is required, it sends an SDTR message to the initiator.  

The initiator shall set the attention flag for the message in response for one of the bytes of the 
SDTR message.  In the following MESSAGE OUT phase the initiator shall respond with an SDTR message or with 
a MESSAGE REJECT message.

If an abnormal condition prevents the initiator from issuing a MESSAGE OUT request both 
devices shall return to their default agreement.

Following an initiator's responding SDTR message, an implied agreement for synchronous oper-
ation shall not be considered to exist until the target leaves the MESSAGE OUT phase, indicat-
ing that the target has accepted the negotiation.  After a vendor-specific number of retry attempts 
(greater than zero), if the target has not received the initiator's responding SDTR message, it 
shall go to the BUS FREE phase without any further information transfer attempt (see 5.1.3).  
This indicates that a catastrophic error condition has occurred.  Both devices shall go to asyn-
chronous data transfer mode for data transfers between the two devices.

If, following an initiator's responding SDTR message, the target shifts to MESSAGE IN phase 
and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be 
negated and both devices shall go to asynchronous data transfer mode for data transfers 
between the two devices.
6.3.16.1 Initiator initiated negotiation

If the initiator recognizes that negotiation is required, it sets the attention flag on a response to an 
indication.

In the following MESSAGE OUT phase the initiator shall respond with an SDTR message.  

If an abnormal condition prevents the initiator from issuing a MESSAGE OUT request both 
devices shall return to their default agreement.

Following an initiator's responding SDTR message, an implied agreement for synchronous oper-
ation shall not be considered to exist until the target leaves the MESSAGE OUT phase, indicat-
ing that the target has accepted the negotiation.  After a vendor-specific number of retry attempts 
(greater than zero), if the target has not received the initiator's responding SDTR message, it 
shall go to the BUS FREE phase without any further information transfer attempt (see 5.1.3).  
This indicates that a catastrophic error condition has occurred.  Both devices shall go to asyn-
chronous data transfer mode for data transfers between the two devices.
If, following an initiator's responding SDTR message, the target shifts to MESSAGE IN phase 
and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be 
negated and both devices shall go to asynchronous data transfer mode for data transfers 
between the two devices.

The implied synchronous agreement shall remain in effect until a BUS DEVICE RESET message 
is received, until a hard reset condition occurs, or until one of the two SCSI devices elects to 
modify theagreement.  The default data transfer mode is asynchronous data transfer mode.  The 
default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or 
after a hard reset condition.

6.3.17 TARGET TRANSFER DISABLE

The TARGET TRANSFER DISABLE message is sent from an initiator to a target to request that 
subsequent reconnections for data transfer on the task be done by the initiator instead of 
the target. The target may reconnect for other purposes, but shall not enter a data phase on a 
target reconnection. SCSI devices that implement this message shall also implement the CON-
TINUE TASK message.

This message shall be sent as the last message of the first  MESSAGE OUT phase of an initial 
connection. The target may continue the task, including any DATA OUT phases on the 
initial connection, until the target would normally disconnect, but the target shall not reconnect to  
transfer data.  That is, the target shall not enter a DATA IN phase on the  initial connection and 
the target shall not enter any data phase on any subsequent target reconnection for the task.

When the target is ready to transfer data for a disconnected task for  which a TARGET 
TRANSFER DISABLE message has been sent, the target shall reconnect to the initiator  for the 
task (via a RESELECTION phase, an IDENTIFY message, and an  optional SIMPLE 
QUEUE TAG message), send a DISCONNECT message, and, if the  initiator does not respond 
with a MESSAGE REJECT message, go to the BUS FREE  phase.  This connection serves to 
notify the initiator that the task is  ready for data transfer.  If the initiator rejects the DIS-
CONNECT message, the  target may enter a data phase; otherwise, the initiator may reconnect 
to the task as described in the CONTINUE I/O PROCESS message to perform the data 
transfer.

Initiators should avoid sending the TARGET TRANSFER DISABLE message to targets which 
have not implemented this message.  Such targets may not respond as described in this section.  
An initiator can determine whether a target implements this message  by examining the TranDis 
bit in the standard INQUIRY data (see SCSI-3 Primary Commands).

6.3.18 WIDE DATA TRANSFER REQUEST 

Table 12 -Wide Data Transfer Message


Bit
7
6
5
4
3
2
1
0
Byte 0
Extended Message (01h)
Byte 1
Extended Message Length (02h)
Byte 2
WIDE DATA TRANSFER REQUEST (03h)
Byte 3
Transfer Width Exponent (m)

A WIDE DATA TRANSFER REQUEST (WDTR) message exchange shall be initiated by a SCSI 
device whenever a previously-arranged transfer width agreement may have become invalid.  
The agreement becomes invalid after any condition which may leave the data transfer agree-
ment in an indeterminate state such as:

1.	after a hard reset condition;

2.	after a BUS DEVICE RESET message and;

3.	after a power cycle.

In addition, a SCSI device may initiate an WDTR message exchange whenever it is appropriate 
to negotiate a new transfer width agreement.  SCSI devices that are capable of wide data trans-
fers (greater than eight bits) shall not respond to an WDTR message with a MESSAGE REJECT 
message.

Re-negotiation at every selection is not recommended, since a significant performance impact is 
likely. 

The WDTR message exchange establishes an agreement between two SCSI devices on the 
width of the data path to be used for DATA phase transfers between the two devices.  This 
agreement applies to DATA IN and DATA OUT phases only.  All other information transfer 
phases shall use an eight-bit data path.

If a SCSI device implements both wide data transfer option and synchronous data transfer 
option, then it shall negotiate the wide data transfer agreement prior to negotiating the synchro-
nous data transfer agreement.  If a synchronous data transfer agreement is in effect, then an 
SCSI device that accepts a WDTR message shall reset the synchronous agreement to asyn-
chronous mode.

The transfer width is two to the transfer width exponent bytes wide.  The transfer width that is 
established applies to all logical units on both SCSI devices.  Valid transfer widths are 8 bits 
(m=00h), 16 bits (m=01h), and 32 bits (m=02h).  Values of m greater than 02h are reserved.

The originating SCSI device (the SCSI device that sends the first of the pair of WDTR messages) 
sets its transfer width value to the maximum data path width it elects to accommodate.  If the 
responding SCSI device can also accommodate this transfer width, it returns the same value in 
its WDTR message.  If it requires a smaller transfer width, it substitutes the smaller value in its 
WDTR message.  The successful completion of an exchange of WDTR messages implies an 
agreement as follows:

Responding Device WDTR Response
Implied Agreement
Non-zero transfer width
Each device transmits and receives data with a 
transfer width equal to the responding SCSI 
device's transfer width.

Transfer width equal to zero
Eight-bit Data Transfer
MESSAGE REJECT message
Eight-bit Data Transfer

If the initiator recognizes that negotiation is required, it asserts the ATN signal and sends a 
WDTR message to begin the negotiating process.  After successfully completing the MESSAGE 
OUT phase, the target shall respond with the proper WDTR message.  If an abnormal condition 
prevents the target from returning an appropriate response, both devices shall go to eight-bit 
data transfer mode for data transfers between the two devices.

Following a target response of non-zero transfer width, the implied agreement for wide data transfers shall be 
considered to be negated by both the initiator and the target if the initiator asserts ATN and the first message out is 
either MESSAGE PARITY ERROR or MESSAGE REJECT.  In this case, both 
devices shall go to eight-bit data transfer mode for data transfers between the two devices.  For 
the MESSAGE PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of 
the pair of messages is successfully accomplished.  After a vendor-specific 
number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY ERROR 
message, it shall terminate the retry activity.  This may bedone either by changing to any other 
information transfer phase and transferring at least one byte of information or by going to the 
BUS FREE phase (see 5.1.3).  The initiator shall accept such action as aborting the negotiation, 
and both devices shall go to eight-bit data transfer mode for data transfers between the two 
devices. 

If the target recognizes that negotiation is required, it sends a WDTR message to the initiator.  
Prior to releasing the ACK signal on the last byte of the WDTR message from the target, the initi-
ator shall assert the ATN signal and respond with its WDTR message or with a MESSAGE 
REJECT message.  If an abnormal condition prevents the initiator from returning an appropriate 
response, both devices shall go to eight-bit data transfer mode for data transfers between the 
two devices.

Following an initiator's responding WDTR message, an implied agreement for wide data transfer 
operation shall not be considered to exist until the target leaves the MESSAGE OUT phase, indi-
cating that the target has accepted the negotiation.  After a vendor-specific number of retry 
attempts (greater than zero), if the target has not received the initiator's responding WDTR mes-
sage, it shall go to the BUS FREE phase without any further information transfer attempt (see 
5.1.3).  This indicates that a catastrophic error condition has occurred.  Both devices shall go to 
eight-bit data transfer mode for data transfers between the two devices.

If, following an initiator's responding WDTR message, the target shifts to MESSAGE IN phase 
and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be 
negated and both devices shall go to eight-bit data transfer mode for data transfers between the 
two devices.

The implied transfer width agreement shall remain in effect until a BUS DEVICE RESET mes-
sage is received, until a hard reset condition occurs, or until one of the two SCSI devices elects 
to modify the agreement.  The default data transfer width is eight-bit data transfer mode.  The 
default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or 
after a hard reset condition.

6.4 Queue tag messages

Table 10 -Q Tag Message Format

Bit
7
6
5
4
3
2
1
0
Byte 0
Message Code (20h, 21h, 22h, 24h)
Byte 1
Queue Tag (00h-FFh)



Table 10 defines the format for the queue tag messages.  If the target implements tagged queu-
ing, all of the queue tag messages are mandatory:  ACA TAG, HEAD OF QUEUE TAG, 
ORDERED QUEUE TAG, and SIMPLE QUEUE TAG.

If a target does not implement tagged queuing and a queue tag message is received it shall 
respond with a MESSAGE REJECT message and accept the task as if it were untagged.

The queue tag messages are used to specify an identifier, called a queue tag, for a task 
which establishes the I_T_L_Q nexus.  The queue tag field is an 8-bit unsigned integer assigned 
by the initiator during an initial connection.  The queue tag for every task for each I_T_L 
nexus should be unique. If the target receives a queue tag that is currently in use for the I_T_L 
nexus, then it shall respond as defined in 6.5.2.  A queue tag becomes available for re-assign-
ment when the task ends.  The numeric value of a queue tag has no effect on the order of 
execution.

For each logical unit on each target, each initiator has up to 256 queue tags to assign to tasks. Thus a target with 
eight logical units could have up to 14336 tasks concurrently in existence if there were seven initiators on the bus.

Whenever an initiator connects to a target, the appropriate queue tag message shall be sent 
immediately following the IDENTIFY message and within the same MESSAGE OUT phase to 
establish the I_T_L_Q nexus for the task.  Only one I_T_L_Q nexus may be established 
during a connection.  If a queue tag message is not sent, then only an I_T_L nexus is established 
for the task (untagged command).

Whenever a target reconnects to an initiator to continue a tagged task, the SIMPLE 
QUEUE TAG message shall be sent immediately following the IDENTIFY message and within 
the same MESSAGE IN phase to revive the I_T_L_Q nexus for the task.  Only one 
I_T_L_Q nexus may occur during a reconnection.  If the SIMPLE QUEUE TAG message is not 
sent, then only an I_T_L nexus occurs for the task (untagged command).

If a target attempts to reconnect using an invalid queue tag, then the initiator should respond with 
an ABORT TAG message.
6.4.1 ACA QUEUE TAG

The ACA QUEUE TAG message specifies that the task shall be placed in the task set as an ACA task.  The rules 
used by the device server to handle ACA tasks within a task set are defined in the SCSI-3 Architecture Model 
standard.

6.4.2 HEAD OF QUEUE TAG

The HEAD OF QUEUE TAG message specifies that the task shall be placed in the task 
set as a HEAD OF QUEUE task.  The rules used by the device server to handle HEAD 
OF QUEUE tasks within a task set are defined in the SCSI-3 Architecture Model stan-
dard.

6.4.3 ORDERED QUEUE TAG

The ORDERED QUEUE TAG message specifies that the task shall be placed in the task 
set as an ORDERED QUEUE task.  The rules used by the device server to handle 
ORDERED QUEUE tasks within a task set are defined in the SCSI-3 Architecture Model 
standard.

6.4.4 SIMPLE QUEUE TAG

The SIMPLE QUEUE TAG message specifies that the task shall be placed in the task set 
as a SIMPLE QUE TAG task.  The rules used by the device server to handle SIMPLE 
QUEUE TAG tasks within a task set are defined in the SCSI-3 Architecture Model stan-
dard.



7. SCSI Command Processing

The following sections describe some aspects of commnd processing, including exception conditions and error 
handling.

7.1 SCSI pointers

The SCSI Interlocked Protocol provides for a set of three pointers for each task, called 
the saved pointers.  The set of three pointers consist of one for the command, one for the data, 
and one for the status.  When an I/O process becomes active, its three saved pointers are copied 
into the initiator's set of three active pointers.  There is only one set of active pointers in each ini-
tiator.  The active pointers point to the next command, data, or status byte to be transferred 
between the initiator's memory and the target. The saved and active pointers reside in the initia-
tor.

The saved command pointer always points to the start of the command descriptor block for the task.  The saved 
status pointer always points to the start of the status area for the task.  The saved data pointer points to the start of 
the data area until the target sends a SAVE DATA POINTER message for the task.

In response to the SAVE DATA POINTER message, the initiator stores the value of the active data pointer into the 
saved data pointer for that task.  The target may restore the active pointers to the saved pointer values for the active 
task by sending a RESTORE POINTERS message to the initiator.  The initiator then copies the set of saved 
pointers into the set of active pointers.  Whenever a target disconnects from the bus, only the set of saved pointers 
are retained.  The set of active pointers is restored from the set of saved pointers upon reconnection of the I/O 
process.

Since the data pointer value may be modified by the target before the task ends, it should not be used to test for 
actual transfer length because it is not reliable.

7.2 Incorrect initiator connection

An incorrect initiator connection occurs on a reconnection if:

1. an initiator attempts to reconnect to a task, and;
 
2. a soft reset condition has not occurred, and;
 
3. the initiator does not send an ABORT, ABORT TAG, BUS DEVICE RESET, CLEAR QUEUE, CONTINUE 
TASK, or TERMINATE TASK message during the same MESSAGE OUT phase as the IDENTIFY message.

A target that detects an incorrect initiator connection shall abort all tasks for the initiator 
on the logical unit and shall return CHECK CONDITION status.  The sense key shall be set to 
ABORTED COMMAND and the additional sense code shall be set to OVERLAPPED COM-
MANDS ATTEMPTED.

If an initiator reconnects to a task and a soft reset condition has occurred, the target 
shall meet the requirements of the soft reset alternative (see 5.1.2.2).

An incorrect initiator connection may be indicative of a serious error and, if not detected, could 
result in a task operating with a wrong set of pointers.  This is considered a catastrophic 
failure on the part of the initiator.  Therefore, vendor-specific error recovery procedures may be 
required to guarantee the data integrity on the medium.  The target may return additional sense 
data to aid in this error recovery procedure (e.g., sequential-access devices may return the resi-
due of blocks remaining to be written or read at the time the second command was received).

Some targets may not detect an incorrect initiator connection until after the command descriptor 
block has been received.

7.3 Interlocked asynchronous event reporting

Notification of an asynchronous event is performed using the SEND command with the AER bit set to one. The 
information identifying the condition being reported shall be returned during the DATA OUT phase of the SEND 
command.

An error condition or unit attention condition shall be reported once per occurrence of the event 
causing it.  The target may choose to use an asynchronous event notification or to return CHECK 
CONDITION status on a subsequent command, but not both.  Notification of command-related 
error conditions shall be sent only to the processor that initiated the task.

The asynchronous event notification protocol can be used to notify processor devices that a sys-
tem resource has become available.  If a target chooses to use this method, the sense key in the 
sense data sent to the processor device shall be set to UNIT ATTENTION. 

The asynchronous event notification protocol shall be used only to SCSI devices that return pro-
cessor device type with an AERC bit of one in response to an INQUIRY command.  The 
INQUIRY command should be issued to logical unit zero of each SCSI device responding to 
selection.  This procedure shall be conducted prior to the first asynchronous event notification 
and shall be repeated whenever the device deems it appropriate or when an event occurs that 
may invalidate the current information.  (See SYNCHRONOUS DATA TRANSFER REQUEST 
message for examples of these events.)

Each SCSI device that returns processor device type with an AERC bit of one shall be issued a 
TEST UNIT READY command to determine that the SCSI device is ready to receive an asyn-
chronous event notification.  A SCSI device returning CHECK CONDITION status is issued a 
REQUEST SENSE command.  This clears any pending unit attention condition.  A SCSI device 
that returns processor device type with an AERC bit of one and returns GOOD status when 
issued a TEST UNIT READY command shall accept a SEND command with an AER bit of one.

A SCSI device which can use asynchronous event notification at initialization time should pro-
vide means to defeat these notifications.  This can be done with a switch or jumper wire.  
Devices which implement saved parameters may alternatively save the asynchronous event 
notification permissions either on a per SCSI device basis or as a system wide option.  In any 
case, a device conducts a survey with INQUIRYcommands to be sure that the devices on the 
SCSI bus are appropriate destinations for SEND commands with an AER bit of one.  (The 
devices on the bus or the SCSI ID assignments may have changed.)  

7.4 Unexpected reselection

An unexpected reselection occurs if a SCSI device attempts to reconnect to a task for which a nexus does not exist.  
A SCSI device should respond to an unexpected reselection by sending an ABORT message.

7.5 Unit attention condition

The target shall generate a unit attention condition for each initiator on each valid logical unit whenever the target 
has been reset by a BUS DEVICE RESET message, a hard reset condition, or by a power-on reset. For dual port 
implementations, the unit attention condition for:

1. the hard reset condition;
 
2. the BUS DEVICE RESET message, and;
 
3. the BUS DEVICE RESET OTHER PORT message.

only affects the initiators on one port as described in sections previously. The target shall also generate a unit 
attention condition on the affected logical unit(s) for each initiator whenever one of the following events occurs:

1. A removable medium may have been changed.
 
2. The mode parameters in effect for this initiator have been changed by another initiator.
 
3. The version or level of microcode has been changed.
 
4. Tagged commands queued for this initiator were cleared by another initiator.
 
5. INQUIRY data has been changed.
 
6. The mode parameters in effect for the initiator have been restored from non-volatile mem-ory.
 
7. A change in the condition of a synchronized spindle.
 
8. Any other event occurs that requires the attention of the initiator.
 
Targets may queue unit attention conditions on logical units.  After the first unit attention condition 
is cleared, another unit attention condition may exist (e.g., a power on condition followed by a 
microcode change condition).


The unit attention condition shall persist on the logical unit for each initiator until that initiator 
clears the condition as described in the following paragraphs.

If an INQUIRY command is received from an initiator to a logical unit with a pending unit attention 
condition (before the target generates the contingent allegiance condition), the target shall per-
form the INQUIRY command and shall not clear the unit attention condition.  If the INQUIRY 
command is received after the target has generated the contingent allegiance condition for a 
pending unit attention condition, then the unit attention condition on the logical unit shall be 
cleared, and the target shall perform the INQUIRY command.

If any other command is received after the target has generated the contingent allegiance condi-
tion for a pending unit attention condition, the unit attention condition on the logical unit shall be 
cleared, and if no other unit attention condition is pending the target shall perform the command.  
If another unit attention condition is pending the target shall not perform the command and shall 
generate another contingent allegiance condition.

If a REQUEST SENSE command is received from an initiator with a pending unit attention condi-
tion (before the target generates the contingent allegiance condition), then the target shall either:

1. report any pending sense data and preserve the unit attention condition on the logical unit, or,
 
2. report the unit attention condition, may discard any pending sense data, and clear the unit attention condition 
on the logical unit for that initiator.

If the target has already generated the contingent allegiance condition for the unit attention condition, the target 
shall perform the second action listed above.

If an initiator issues a command other than INQUIRY or REQUEST SENSE while a unit attention 
condition exists for that initiator (prior to generating the contingent allegiance condition for the 
unit attention condition), the target shall not perform the command and shall report CHECK 
CONDITION status unless a higher priority status as defined by the target is also pending (e.g., 
BUSY or RESERVATION CONFLICT).

If after generating the contingent allegiance condition for a pending unit attention condition, the 
next command received from that initiator on the logical unit is not REQUEST SENSE, then that 
command shall be performed and the unit attention condition shall be cleared for that initiator on 
the logical unit and the sense data is lost.

If a target becomes a temporary initiator to issue a SEND command with an AER bit of one, 
which informs the initiator (temporary target) of the unit attention condition, and the SEND com-
mand completes with GOOD status, then the target shall clear the unit attention condition for that 
initiator on the logical unit.


3	12.02.98                     	SIP Working Draft 4a


