Really getting rid of AEN

JimMcGrath at JimMcGrath at
Tue Jan 7 16:44:19 PST 2003

* From the T10 Reflector (t10 at, posted by:
* JimMcGrath at


I'd suggest that the SAM level issue that should be addressed is not a
particular mechanism for generating the asynchronous status change
indication (which may be protocol specific), but rather the requirement
that a SCSI transport implement in some way the ability to pass to a host
an asynchronous status change for a device.  In SAMese this is the ability
to have the device server notify the application client of an asynchronous
status change.  Stated at that level of generality, if would be a suitable
subject for discussion for SAM.  Afterall, the purpose of SAM is to
enumerate the architectural requirements for SCSI, not the implementation
(covered in all of the other standards).


PS linked commands is another of those annoying implementation dependent
issues that made it's way into SAM.  However, the ability to create some
atomicity around multiple commands outside of the reservation process might
indeed be a useful attribute of SCSI that would be incorporated into SAM
(or not).

                      "Edward A.                                                                                                       
                      Gardner"                 To:       T10 at                                                                   
                      <eag at        cc:                                                                                     
                      >                        Subject:  Re: Really getting rid of AEN                                                 
                      Sent by:                                                                                                         
                      owner-t10 at                                                                                                
                      01/07/2003 12:03                                                                                                 

* From the T10 Reflector (t10 at, posted by:
* "Edward A. Gardner" <eag at>
AEN, as presently defined by SAM and SAM-2, is fatally flawed.  The problem

is its interaction with the Unit Attention system.  Sending an AEN is
specified to clear the UA.  With a non-interlocked bus (i.e. anything other

than traditional parallel SCSI) the following would occur if AEN were

1.  Target detects a UA (e.g. media change) and sends AEN, clearing the UA.
2.  Initiator sends a command that alters the media.
3.  Target received and processes the command, corrupting the media.
4.  Initiator receives the AEN and realizes that its too late.

In other words, AEN on a non-interlocked bus defeats the entire purpose of
having a UA.

Going forward, all SCSI transports are non-interlocked.

One could define a mechanism to report asynchronous events that does not
clear Unit Attention, such as the SRP AER mechanism for Infiniband.  Such a

mechanism was suggested for SAS.  A major vendor's device groups objected
to the context overhead needed to keep track of which initiators should /
should not get the AER.  Attempts to develop alternatives bogged down as
they proved complex, unreliable or both.

At present AEN is being removed because it is unworkable (well, that's my
opinion, and I wasn't there for the vote, but I suspect it is what underlay

the vote).  Good move.  Now what about linked commands? :-)

There is no champion for an alternate AER mechanism.  That is, no initiator

vendor both willing to implement an alternate and waving purchase orders at

target vendors to "encourage" them to implement it as well.  The market has

found alternatives, e.g. polling in small configurations, SRP AER in
Infiniband, the FC name server and RSCN for FC.  Until there is a champion
demanding another alternative, there is not much point in wasting time
discussing one.

At 16:42 06-01-2003, JimMcGrath at wrote:
>* From the T10 Reflector (t10 at, posted by:
>* JimMcGrath at
>What is suppose to replace AEN (aka AER) going forward?  That is, how does
>a target (device server) notify the initiator (application client) of a
>change in status unrelated to a command, and especially without awaiting
>for a command?
>This capability is not physical protocol related, and I don't think is
>device type related, and so should be in SAM (if not, then what document
>will it be in?)
>PS while I saw the notice of the decision (and vote) to remove AEN in the
>minutes, I did not see a proposal on the topic (which would usually
>these sorts of issues).

Edward A. Gardner               eag at
Basil Networks                  719 593-8866 CO voice
1262 Hofstead Terrace           719 210-7200 cell
Colorado Springs, CO  80907     408 635-8741 CA voice

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

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

More information about the T10 mailing list