Google
 

Trailing-Edge - PDP-10 Archives - BB-H311D-RM - documentation/mscp-info.memos
There is 1 other file named mscp-info.memos in the archive. Click here to see a list.
THIS FILE CONTAINS:

   o	MSCP Driver Design Specification
   o	MSCP Server Design Specification
   o	MSCP Server Functional Specification
   o	MSCP (Disk) Specification

------------------
MSCP-DRIVER.DESIGN-SPECIFICATION


1.0    OVERVIEW



The MSCP driver is one of the intermediate levels of support
for  the  CI-20.  The driver is responsible for coordinating
all  access  between  PHYSIO  and  MSCP  disks.    It   must
communicate  to  the  HSC50  disks  using  the  SCA and MSCP
protocols.

The MSCP driver is part  of  the  PHYSIO  system.   This  is
necessary  to  interface  the operating system with the MSCP
disks.  The MSCP driver will be a Kontroller in  the  PHYSIO
system and will be the inferior to the KLIPA Controller.

This document describes the structure of the PHYMSC  driver,
the  specific  services  it performs and its relationship to
the other CI-related services and to the monitor in general.





1.1    References



   1.  Systems Communication Architecture, 20-Jul-84

     Rev 4 (Strecker)


   2.  Scampi Functional spec (Dunn)


   3.  TOPS-20 Coding Standard, 23-Mar-83 (Murphy)


   4.  Mass Storage Control Protocol Version 1.2 (Gardner)


   5.  PHYMSC Functional Specification (Mclean)





1.2    Purpose Of This Document



This document describes how PHYMSC implements  the  services
described  in  the  functional  specification [5].  Ideally,
this document is a template for the  implementor  to  follow
and  therefore  will  serve  as  a  "road  map" to the code.
                                                      Page 2


Portions of this document will appear as commentary  in  the
source  module  so  that  maintainers will benefit from this
design plan.





1.3    Driver Functions



The PHYMSC  driver  is  a  TOPS-20  device  driver.   It  is
generally  a  passive service that responds to requests from
higher and lower level components and  simply  performs  the
device-specific  operations  required  by the requests.  The
only operations it performs on its  own  are  those  of  the
poller.   However,  these  operations are transparent to the
rest of the monitor.

The driver is  responsible  for  maintaining  the  interface
between  the  MSCP disks and the PHYSIO system.  That is the
driver must locate all  the  remote  disks  when  they  come
online  and  it  must  recognize  their  characteristics and
create  an  interface   to   PHYSIO.    It   is   also   the
responsibility  of the driver to determine that those remote
servers are functioning and to try and reload them if  there
is a failure.

The only active part of the driver is the polling  operation
and  the  process  of  opening initial connections to remote
servers.  All other data transfers, datagrams  and  messages
are initiated by PHYSIO and SCA.



1.4    Driver Components And Data Structures



The Kontroller block (KDB).  This is  a  communication  area
for  PHYSIO.  This block contains the specific data for each
MSCP server to which PHYMSC has recognized.  This  block  is
identical to the standard PHYSIO KDB.

The Unit Data Block (UDB).  This is a communication area for
PHYSIO.  This block contains the specific data for each disk
unit which PHYSIO will recognize.  This block  is  identical
to the standard PHYSIO UDB.


The fundamental pieces of the driver are:

1.  The poller.  This is the code that attempts to recognize
new  servers  when  they  appear  on  the  CI  and to detect
                                                      Page 3


failures of these servers to respond.  It is  also  expected
to reload those servers if they consistently fail to respond
to a Get Command Status request.  The poller is called as  a
part  of  PHYSIO poller and therefore is periodically called
by PHYKLP.

2.  Interrupt service.  This code is called by  SCA  in  the
form  of  SCA  Callbacks.   These  are  events  that  happen
asynchronously and  are  usually  a  result  of  a  previous
request  for  service to SCA.  The interrupt service routine
is responsible for completion of  I/O  and  the  process  of
placing a disk online.

3.  PHYSIO interface.   These  are  a  set  of  routines  to
service the Start I/O requests and other responsibilities of
a Kontroller.


The remaining sections of this document will explore each of
the  pieces  described in the overview as well as provide an
operational description of PHYMSC.





2.0    LOCAL DATA DESCRIPTIONS



2.1    MSCCID

This table is used to keep track of the current  Connect  Id
of  each  connection.   This  table  has three states.  Zero
indicates an unused entry.  Minus  one  indicates  an  entry
that  is  no longer connected.  Other values are the Connect
Id of the current connection.





2.2    MSCOLD



This is a table of old Connect Id values.  It is mainly  for
debugging purposes.
                                                      Page 4


2.3    CIDATA



This is a table of the status of each entry in  MSCCID.   It
contains  the  state  of the connection during initalization
and after initialization the status of the connection.





2.4    CICMST



Status of the oldest command for each connection.   This  is
the  status  returned from the server.  If it is the same on
each polling cycle then the server is assumed to have died.




3.0    GLOBAL DATA USAGE



3.1    System Block


The system block is used to find  the  related  QOR  request
blocks and to find the port and node numbers.





3.2    BHD/BSD


The BHD and BSD's are used to describe the I/O transfers  at
Start I/O.





3.3    QOR


The QOR list is used to permit Start I/O to closely  control
the state of requests to the HSC.  This permits Start I/O to
re-queue the requests when the drive becomes offline.
                                                      Page 5


4.0    PHYMSC DESCRIPTION/OPERATION



4.1    PHYSIO Interface



PHYMSC is a device driver.  As such it is called  by  PHYKLP
to perform device polling, Start I/O and process interrupts.

PHYMSC creates the UDB and KDB tables that  PHYSIO  expects.
These tables are in the same format as any other UDB and KDB
in the PHYSIO system.

The poller is called from PHYKLP as a  part  of  the  PHYSIO
poller.





4.2    Initialization



The PHYMSC driver is started by a  call  from  PHYKLP.   The
initialization  process  starts by finding the configuration
of each node on the CI.  if a node of  type  KL  or  HSC  is
found then PHYMSC performs the following sequence.

1.  Attempt to connect to the remote system.  From  here  on
the connect Initialization sequence is interrupt driven.

2.  Loop back trying to find out the  configuration  of  the
next node.


Interrupt driven connect sequence:

1.  Connect response available SCA Callback occurs.   PHYMSC
checks  to  see if the connect is accepted and then save the
Connect Id if it is successful.

2.  Connect Response  available  causes  a  request  to  Set
Characteristics.


3.  The SCA callback from the  Set  Characteristics  permits
the  determination  of  the  type  of  device  on the remote
server.  If the remote device is not a 576 byte format  disk
it is ignored, otherwise, a Get Next Unit request is made to
determine what units are on the HSC.  The UDB is not created
for other than 576 disk types.  A BUGINF is created once for
such an occurence.
                                                      Page 6


4.  When the SCA callback from the Get Next Unit occurs  the
disk  characteristics  are  obtained.   These  are  used  to
generate a UDB and  the  Disk  is  onlined  with  an  ONLINE
request.

5.  When  the  SCA  callback  from  the  Online  occurs  the
geometry  of  the  disk  is determined.  The home blocks are
flagged as needing to  be  checked  and  the  initialization
process is complete.





4.3    Poller



Poller functions:

1.  When time and date become available to a new node a  Set
Characteristics  is  sent  with time and date information to
the remote system.


2.  Get Command Status  requests  are  made  to  the  remote
system for the oldest command on the queue.  This is done to
permit the determination of the state of the remote system.


3.  Check offline disk drives  and  attempt  to  place  them
online  as  soon  as  possible.   This  is  done  because an
Available message may become lost or may not  happen  for  a
long period of time.


4.  Disconnect/Re-connect/Reload a remote  HSC  server  that
has failed to respond with the status of the oldest request.





4.4    Start I/O



Start I/O  takes  requests  from  PHYSIO.   Start  I/O  then
performs the following functions.

1.  Validation of the function requested.

2.  Allocation of QOR, BSD and BHD space.

3.  Conversion of the addresses to physical block numbers.
                                                      Page 7


4.  Queueing of the request to SCA.


5.  Move the request from the Position  wait  queue  to  the
Transfer wait queue.


If a failure to be able  to  obtain  a  buffer  or  start  a
request  to  the  remote server occurs then Start I/O leaves
the request in the Position wait queue until a time when the
I/O  can  be  restarted  by  the  Poller  or  a SCA callback
indicating that credit is now available.





4.5    Unit Existence Check



This PHYSIO request causes PHYMSC to  search  thru  the  UDB
entries  and  return +1 if no unit is found and +2 if a unit
exists.





4.6    Error Recovery


Since all error recovery is done in the remote system PHYMSC
returns  +2  to  PHYSIO  to  indicate that error recovery is
complete.


All other PHYSIO Kontroller routines do not have any meaning
in PHYMSC and they return +1 to indicate success.



4.7    SCA Interface



PHYMSC relies on SCA to send messages, receive messages  and
datagrams and provide information on node and port states.


SCA is responsible for providing message buffers  sufficient
for all the PHYMSC traffic on the CI.  In particular, PHYMSC
does not create any buffers for its own use.
                                                      Page 8


5.0    INTERRUPT SERVICE



The interrupt service routines are all associated  with  SCA
callbacks.   Unused  SCA  callbacks  just  return since they
shouldn't happen due to the fact that they  are  unused  SCA
features.  The used callbacks are:


1.  Datagram

This callback only happens for error logging.  The error log
information  is  taken  directly  from  the  SCA  packet and
entered in the SYSERR log.  No  translations  are  performed
and the block type is SEC%EL.

2.  Port Broke Connection

This callback causes a cleanup of the database and  declares
all the units on the specified ports to be offline.

3.  Connect Response Available

This callback only occurs in response to the PHYMSC  connect
request  and  causes  us  to  go  to  the  next state in the
initialization of a unit.

4.  Node Came Online

This callback causes PHYMSC to  attempt  to  initialize  any
units on the specified node.

5.  Credit Available

When this callback  occurs  PHYMSC  attempts  to  start  any
transfers  that  have  been waiting due to lack of credit to
the specified HSC.

6.  Node Offline

This is the same as  2 since it is impossible to continue to
talk to a node that has gone offline.

7.  Message received

This is the mechanism with which PHYMSC is  notified  of  an
available  unit  and  the  status  of any MSCP requests (end
messages).  When an available occurs PHYMSC proceeds to  the
initialization  routine  to  attempt to online the unit.  If
the message was an End Message the type  is  determined  and
the specific service routine for initialization or I/O done.
If the end Message was unsolicited a BUGCHK will occur.

8.  All other SCA Callbacks are ignored and return +1.
                                                      Page 9


6.0    ERRORS



Errors fall into two major categories.   The  first  is  the
inability  to  obtain  buffers  for  requests  to the remote
server.  This failure will cause the current I/O requests to
remain  on  the  PHYSIO  position  wait  queue until buffers
become available for transmission to the remote server.  The
second failure is caused by data errors.





6.1    Data Errors



Device data errors are divided into two  classifications  to
be  mapped into the PHYSIO error returns.  ST%MFT and ST%DAT
are converted into IS.DAT which causes Bat Block allocation.
All  other errors are converted into device errors (IS.DVE).
Both of these types of errors cause the user to  receive  an
I/O error.  Error logging is done on datagrams by request of
the server as previously described.





6.2    Bat Blocks



The Bat Block  allocation  of  PHYSIO  is  not  altered  for
PHYMSC.   When  the  remote  servers  do implement Bat Block
replacement there should be no changes required for  PHYMSC.
Bat  Block  replacement  is  supposed to be invisible to the
host.  This means that if the server ever returns  an  error
it was impossible for the server to do Bat Block replacement
and we must perform Bat Block allocation in any case.





6.3    Server Failures/Hung Transfers



If a server fails it is assumed that the server will correct
any   problems   by   performing   a  dis-connect/re-connect
sequence.    The   server   is   expected   to    completely
re-initialize  internal database information on dis-connect.
                                                     Page 10


This means that the decision has been made not to  terminate
any  transfers  due  to  the  length  of time it takes for a
transfer to complete  to  a  remote  server.   As  long  Get
Command  Status  shows  progress  on  a  command  then it is
assumed that the remote server is alive.  If the server does
not show progress then PHYMSC will dis-connect/re-connect if
this still does not show progress PHYMSC will try to  reload
and  start  the  remote  server.   It  is  assumed that this
process should eventually work for all  remote  servers  and
therefore there should be no need to abort an I/O transfer.





6.4    Lack Of Credit



The lack of credit return from SCA is handled like any other
of  buffer  allocation failure.  If any message send request
fails due to lack of credit  PHYMSC  postpones  the  request
until more credit is available.



7.0    DUAL PORT SUPPORT



Dual Port disks are supported as provided for by the  HSC50.
The  disks  are  onlined  only  to one port and the Hardware
requires operator intervention switch ports  on  failure  of
the hardware by use of the Port select switches.





8.0    TAPE SERVICE AND RA60 SUPPORT



Currently we don't have any RA60 or Tape  drives  available.
The  code  for RA60's is implemented but untested.  The code
for Tape service (TA78's) exists  but  is  inaccessable  and
untested.  The tape project should be the subject of another
release  and  is  only  left  in  the  PHYMSC   driver   for
experimental  purposes to test the KLIPA hardware as soon as
possible.
                                                     Page 11


9.0    CONFIGURATION SUPPORT



Currently we support 16 CI nodes and  24  units/node.   This
can   be   restricted   further  when  Hardware  engineering
determines  the  maximum  configuration   that   should   be
supported on the HSC50.
MSCP-SERVER.DESIGN SPECIFICATION


1.0  OVERVIEW

The server appears to the MSCP driver to be an intelligent disk  controller
much  like  the  HSC50.   The MSCP server interfaces to TOPS-20 as a device
independant disk driver a la the DSKOP Jsys.   It  functions  at  a  higher
architectural  level  than  PHYSIO  but at a lower level than PAGEM/PAGUTL.
That is the MSCP server has no knowledge of the file system format.

The only supported user of the MSCP  server  is  the  TOPS-20  MSCP  driver
(PHYMSC).   The  MSCP  server  implements only the subset of MSCP functions
required for the operation of PHYMSC.

This document describes the  structure  of  the  MSCP  server,  it's  major
algorithms and data structures, the services it provides to the MSCP driver
and the services of TOPS-20 that are utilized by the MSCP server.



2.0  REFERENCES


     1.  Mass Storage Control Protocol Version 1.2, 8-Apr-82 (Gardner)

     2.  TOPS-20 MSCP Server Functional Specification, 1.0 /date/ (Moser)

     3.  TOPS-20 MSCP Driver Functional Specification /TBS/ (Mclean)

     4.  TOPS-20 SCA Functional Specification /TBS/ (Dunn)

     5.  Systems Communications Architecture, 20-July-82 (Strecker)

     6.  TOPS-20 Coding Standard, 23-Mar-83 (Murphy)

     7.  PHYSIO.MAC TOPS-20 Physical IO module




3.0  GLOBAL CONCEPTS

The reader of this document is expected to be  familiar  with  the  overall
concepts  and  interactions  of MSCP disk servers and disk class drivers as
described in [1].  The reader is also expected to be familiar with  TOPS-20
implementation  details  as  described  in  [2,3].   The  following section
describes global concepts, algorithms and data structures utilized  by  the
MSCP server.



                        Figure 1 - MSCP server flow



In general the  MSCP  server  performs  2  main  functions.   It  maintains
communications  with  MSCP  drivers  by  means  of  SCA  connections and it
                                                                     Page 2


processes commands from those drivers.



3.1  Connections And Connection States

MSCP servers and drivers communicate by means of SCA connections.  The MSCP
server  establishes  connections passivly.  It utilizes the services of SCA
to "listen" for a connection.  It listens for a connection  from  the  name
"T-20$DISK"  and  it  gives the name "MSCP$DISK" in the listen call to SCA.
Once a driver attempts to connect to a listner the server  decides  whether
to accept or reject that connection.

A connection is accepted if the connector is identified  as  a  KL  in  the
confiduration data block obtained from SCA.  Connections from drivers which
are not KL's are not accepted.

Connections may be terminated for several reasons.  They are:

     1.  Port error

     2.  Remote system dissapears

     3.  Driver requests connection termination

     4.  Server terminates connection for one of the following reasons

         1.  A driver does not  communicate  with  the  server  within  the
             timeout interval

         2.  A command does not complete (times  out)  within  the  timeout
             interval



The  MSCP  server  maintains  an  internal  connection  status   for   each
connection.   The  state  of a connection is defined by the setting of 0 or
more bits in the Server Connection Data  Block  (SCDB).   The  MSCP  server
recognizes that a connection may be in one of the following states:

     1.  Unused - No connection exists.  This is indicated by  the  absence
         of an SCDB.

     2.  Listen - Waiting for a connect as an SCA listener.

     3.  Waiting for OK to send -  A  response  to  our  listner  has  been
         accepted.  This state indicates that a connection is being opened.

     4.  OK to send - The connection is fully open.

     5.  Attention enable - This indicates that the  connector  desires  to
         recieve Attention messages.
                                                                     Page 3


     6.  Shutdown - This indicates that the connection has been terminated.
         This state has several possible substates that indicate the reason
         for connection termination.  They are:

         1.  Node offline - The other host has gone offline.

         2.  Port broke connection - The connection  was  terminated  by  a
             port error.

         3.  Forced shutdown - The connection was terminated because of  an
             error detected by the MSCP server.



Connection  state  transitions  are  explained  in  detail  later  but  the
following table summarizes the major transitions between connection states.


  ACTION       Previous State      New State       Comments
  ---------------------------------------------------------
   None          Unused              Unused        Initial connection state

   SC.LIS        Unused              LISTEN        SCDB exists. Waiting for
                                                   connect

   Connection    LISTEN              WAIT OK       Connection accepted. Waiting
   Accepted                                        for "OK to send". Need new 
                                                   listner

   OK TO SEND    WAIT OK             OPEN          "Normal" state server and
                                                   driver communicate

   PORT ERROR     any                SHUTDOWN      Connection closed. Messages
                                     PORT ERROR    discarded

   DISCONNECT     any                SHUTDOWN           "

   NODE OFFLINE   any                SHUTDOWN
                                     NODE OFFLINE       "

   FATAL MSCP
   ERROR          any                SHUTDOWN           "




3.2  Command States

Commands processed by the MSCP server can be in one of several states.   In
addition  to  these  states a command may be "Queued" or "Aborted" or both.
"Queued" and "Aborted" differ from other states in that they can be used in
conjunction  with  the  other  states.   Besides "queued" and "aborted" the
other states are mutually exclusive.  The possible states are:
                                                                     Page 4


     1.  Queued - May be used  in  conjunction  with  other  states.   This
         indicates that the command is on the command queue.

     2.  Aborted - May be used in  conjunction  with  other  states.   This
         indicates that the command has been aborted.

     3.  Command - The origional state of an MSCP  command.   It  indicates
         that no processing has been done.

     4.  Wait to send end - All command processing is complete but the  end
         packet must be sent.

     5.  Waiting to send buffer - The command is waiting to  send  a  named
         buffer to the other host.

     6.  Waiting to request buffer - The command is waiting  to  request  a
         named buffer from the other host.

     7.  Waiting for send of data - The command is waiting for named buffer
         send to complete.

     8.  Waiting for request of data - The command  is  waiting  for  named
         buffer request to complete.

     9.  IORB active - The command is waiting for  PHYSIO  to  complete  an
         IORB.


The following diagram shows  the  states  and  state  transitions  for  all
commands.



                       Figure 2 - State transitions






3.3  Command Processing And Queuing

3.3.1  Command Processing - All commands are SCA messages.  When a  message
is  recieved  the  opcode  field  of  the  command is compared to a list of
supported opcodes and  if  found  the  appropriate  processing  routine  is
called.   When  a  command is not found in the table it is treated as if it
had an illegal opcode.
                                                                     Page 5


3.3.2  Command Queueing - Commands which cannot be completed immediatly are
queued.  Command completion may be prevented by resources being unavailable
or by the nature of the command.  All READ and WRITE commands are queued as
are commands which fail to send end packets.  When a command is queued it's
state indicates what action must be performed for that command to complete.
Each  queued  command  has  a  queued command header which is used to store
information about the command as well as links to  other  commands  in  the
queue.   The  queued command header overlaps the SCA header area of the SCA
packet containing the command.  The format  of  that  header  is  described
under the section Global Data Structures.



3.3.2.1  Queue Structure - Command  queues  are  implemented  as  a  doubly
linked  list  of commands.  The SCDB contains pointers to the head and tail
of this list.  A zero indicates that there are  no  commands  queued.   The
queued  command header contains the forward and backward pointers needed to
implement the list.



3.3.2.2  Queueing Algorithm - A single subroutine is responsible for adding
commands  to  a queue.  It is concerned simply with list management and has
no knowledge of command format beyond  the  structures  required  for  list
maintenance.   The  Command  queueing  subroutine  relies on the status bit
QUEUED to indicate that a command resides on  a  queue.   This  bit  allows
calling  the command queueing routine whenever a command needs to be queued
(regardless of whether it is  already  queued).   The  queueing  subroutine
simply returns sucess it it is called with a previously queued command.

Command queueing is acomplished by the following steps:

     1.  Point the tail of the list to the command being queued

     2.  Point the command being queued at the (old) tail

     3.  Make the tail pointer in the  SCDB  point  at  the  command  being
         queued

     4.  Make the command's return address in the queued command header  is
         set  to  the  command dequeueing routine and the SCA buffer return
         address is saved in the queued commands header




3.3.2.3  Dequeueing - All commands are returned when command processing  is
complete.   This  returning  is acomplished by calling the subroutine whose
address is stored in the queued command  header  word,  .QCRTN,  This  word
initially  contains the buffer return address which is supplied by SCA when
a command is recieved.  When a command is queued this buffer return address
is  saved  in  word  .QCRT2  and .QCRTN contains the address of the command
dequeueing routine.

Command dequeueing is acomplished by the follwoing steps:
                                                                     Page 6


     1.  Point the previous command at the next command in the list

     2.  Point the next command at the previous

     3.  Release all command resources

     4.  Call the SCA buffer return routine, address in .QCRT2




3.4  Timeouts

3.4.1  Connection Timeout - The MSCP server checks for connection  timeouts
as  required  by  [1].   This  is probably a superfluous function since SCA
implements  it's  own  timeout  mechanism.   If  a   connection   has   not
communicated  (sent  a  message)  within  it's  timeout  interval then that
connection is closed.  The connection state becomes "Shutdown" and  "Forced
shutdown".



3.4.2  Command Timeout - The MSCP server times out commands.  This is never
necessary  in  theory  but  it  is done to identify any unexpected problems
which may cause a command to never complete.  A command times out if it  is
retried  more  than a defined number of times.  This value is determined by
the parameter MSRTMX which is currently defined  as  15.   When  a  command
times  out  a  BUGCHK, SRVCTO, is issued and the connection is closed.  The
connection state becomes "Shutdown" and "Forced shutdown".



3.5  Register Conventions

The MSCP server uses the following register conventions.



3.5.1  Internal Register Usage -

     1.  Q1 - Address of command being processed

     2.  Q2 - Address of SCA buffer to be sent to the remote system.   This
         will be an end packet or an attention message.

     3.  Q3 - Address of SCDB for the connection
                                                                     Page 7


3.5.2  PHYSIO Register Conventions - The following registers are used  when
calling PHYSIO subroutines.

     1.  P1 - CDB address

     2.  P2 - KDB address

     3.  P3 - UDB address

     4.  P4 - IORB address (unused by MSCP server)




3.6  Data Structures

3.6.1  MSCP SERVER DATA -

    !=====================================!
    !               STATUS                ! SVSTSW
    !-------------------------------------!
    !            LISTNER INDEX            ! SVSLSX
    !-------------------------------------!
    !           FIRST FREE IORB           ! SVIRBH
    !-------------------------------------!
    !         FIRST FREE IO PAGE          ! SVIOPH
    !-------------------------------------!
    !           BROADCAST COUNT           ! SVBDKN
    !-------------------------------------!
    !        LAST COMMAND EXECUTED        ! SVLCMD
    !-------------------------------------!
    !                                     ! SVIORB
    \                IORBS                \ 
    !                                     !
    !-------------------------------------!
    !                                     ! SCDBTB
    \             SCDB TABLE              \
    !                                     !
    !-------------------------------------!
    !                                     ! SVCMDC
    \          COUNT OF COMMANDS          \
    !                                     !
    !=====================================!

 Data is displayed as contiguous but this is not a necessary condition. Each
data section i.e. SVCMDC is contiguous but may not be contiguous with
other data. All data is RS type storage unless indicated.

 SVSTSW - 1B0 SVSINF Initialization flag. Set if initialized
          1B1 SVSILB Flag which indicates that the "Can't get listener" BUGINF
                     has been issued.

 SVSLSX - Settable connect ID bits, index into SCDBTB, of listner. -1 if none.

 SVBDKN - Number of disks which need broadcasts of AVAILABLE ATTENTION MESSAGES
                                                                     Page 8



 SVLCMD - Address of last command routine called (for debugging)

 SVIORB - IORBs (long form) used by the MSCP server

 SCDBTB - Address of SCDB for each connection. 0 if none. Index to this table
          matches settable ID in SCA Connect ID. Alloctaed from extended 
          resident code.

 SVCMDC - Count of commands. Parrellel to command dispatch table. (for 
          debugging - possibly SYSDPY). Alloctaed from extended 
          resident code.
                                                                     Page 9


3.6.2  QUEUED COMMAND WITH HEADER -

     !=====================================!
     !           RETURN ADDRESS            ! .QCRTN
     !-------------------------------------!
     !            NEXT COMMAND             ! .QCNXT
     !-------------------------------------!
     !          PREVIOUS COMMAND           ! .QCLST
     !-------------------------------------!
     !       VIRTUAL IO PAGE ADDRESS       ! .QCVPA
     !-------------------------------------!
     !!Q!A!STATE!END LEN.!      RETRY      ! .QCSTS
     !-------------------------------------!
     !            IORB ADDRESS             ! .QCIOR
     !-------------------------------------!
     !             BUFFER NAME             ! .QCDBD
     !-------------------------------------!
     !        QUEUED RETURN ADDRESS        ! .QCRT2
     !=====================================!
     \                                     \ REMAINDER OF SCA HEADER AREA
     !=====================================!
     \               COMMAND               \ .MHUDA
     !=====================================!

 Queued commands and headers are SCA message buffers. The header overlays the 
SCA header area.

 .QCRTN - Buffer return address (provided by SCA for nonqueued commands or
          address of Dequeue routine for queued commands)

 .QCVPA - Virtual address of locked page used for named buffer transfer
          (IO command only)

 .QCSTS - 1B0 - Command is Queued
          1B1 - Command is Aborted
          STATE - Command State
          ENDLEN - Length of end packet to send (state "Wait to send end" only)
          RETRY - Command retry count (timeout counter)

 .QCDBD - Buffer name used to do named buffer transfers (IO command only)

 .QCRT2 - Address to return buffer if .QCRTN contains Dequeue address
          (moved here from .QCRTN at command queueing time)
                                                                    Page 10


3.6.3  SERVER CONNECTION DATA BLOCK (SCDB) -

    !=====================================!
    !               STATUS                ! .SVCIS
    !-------------------------------------!
    !             CONNECT ID              ! .SVCID
    !-------------------------------------!
    !            TIMEOUT TIME             ! .SVTMO
    !-------------------------------------!
    !            TIMEOUT VALUE            ! .SVTMV
    !-------------------------------------!
    !        HEAD OF COMMAND QUEUE        ! .SVCMD
    !-------------------------------------!
    !        TAIL OF COMMAND QUEUE        ! .SVCME
    !-------------------------------------!
    !          CONNECT ID INDEX           ! .SVCIX
    !=====================================!

 The SCDB is allocated from extended resident free space when a listner is 
established.

 .SVCIS - Connection status
          1B0 - OK to send
          1B1 - Shutdown
          1B2 - Waiting for OK to send
          1B3 - Node offline
          1B4 - Port broke connection (port error)
          1B5 - Forced shutdown - Server initiated shutdown
          1B6 - Driver wants to recieve ATTENTION messages

 .SVCIX - Settable bits of connect ID. Index into SCDB table.

The MSCP server also uses word IRBLEN of the long form IORBS for  it's  own
use.   This  field  contains the address of the queued command which "owns"
the IORB and the Settable connect ID bits for the connection.   These  bits
are used to find the SCDB at IORB done time.



4.0  ALGORITHM DESCRIPTIONS

4.1  Initilization

The MSCP server is an SCA SYSAP,  as  such  it  is  initialized  at  system
startup  by  SCA  calling  a  routine  whose  address  is  in the SCA SYSAP
initialization table.  This rotuine does the following:

     1.  Links all long IORBs used by the MSCP server into  a  linked  list
         where  the  first  word of each IORB points at the next IORB.  The
         list is terminated by a zero link.  The head of the list is stored
         in SVIRBH.

     2.  Aquires a linked list of locked pages for IO requests using system
         routine PGRSKD.
                                                                    Page 11


     3.  Marks that no SCA connection listner exists.

     4.  Tries to aquire an SCA listner.  See description of  "LISTEN"  for
         details.

     5.  Calls the periodic check routine.




4.1.1  Possible Errors - Initialization may fail if no pages are  available
for  IO.   If  less  than the desired number of pages are aquired a BUGINF,
SRVNOP, is issued.



4.2  Periodic Check

The MSCP server performs a periodic check  which  is  invoked  through  the
normal CLK2 scheduler cycle checks.  This CHECK does the following:

     1.  Set the time for the next  check  to  be  SRVCHI  in  the  future.
         Currently the value is 10 seconds.

     2.  Check to see that all  active  connections  have  sent  a  message
         within  the connectors timeout interval.  If the connector has not
         sent a message the connection is closed.   The  connection  status
         becomes "shutdown" and "forced shutdown".

     3.  Retry all queued commands.  For details  see  the  description  of
         CREDIT AVAILABLE since it uses this same routine.

     4.  If no listner exists attempt to get one.

     5.  Send available messages to nodes which may need to know the status
         of new units.  This function is described under SMON INTERFACE.




4.3  SCA Interface

SCA calls the MSCP server at the address specified in  the  "listen"  call.
This  address dispatches through a table to various service routines.  Some
SCA callbacks are usused and dispatch to the monitor routine R which simply
returns.  The functions which have service routines are:

     1.  Function 1 - Message recieved

     2.  Function 2 - Port broke connection

     3.  Function 3 - Response to listen
                                                                    Page 12


     4.  Function 7 - Little credit remains  (unused  a  label  exists  for
         debugging)

     5.  Function 11 - OK to send data

     6.  Function 12 - Credit available

     7.  Function 13 - Node going offline

     8.  Function 14 - Named buffer transfer complete




4.3.1  Function 1 - Message Recieved - Messages are MSCP commands.  When  a
message is recieved the following actions are performed:

     1.  The queued command header area of the message  is  zeroed.   (This
         area is coincident with the SCA header area)

     2.  The address to return the message buffer is stored in the  command
         header

     3.  The current time  is  saved  as  the  time  of  the  last  message
         recieved.

     4.  The commands OPCODE is compared to the list of  supported  command
         OPCODEs

     5.  If a matching  OPCODE  is  found  dispatch  to  the  corresponding
         command processing subroutine.




4.3.1.1  Errors - If the connection is not in a legal state for recieving a
message  (shutdown  or  not  "OK  to  send") the server BUGHLTs with SRVICS
(Illegal connect state).

If no matching OPCODE is found in  the  table  of  legal  OPCODEs  then  an
invalid command end message is sent to the MSCP driver.



4.3.2  Function 2 - Port Broke Connection (SHUTDOWN) - Port           broke
connection  is  simply  one case of shutting down a connection.  It differs
from the other cases only in that the status bit MC.PBC is set in the SCDB.

In general shutting down a connection involves the following steps:

     1.  Set the generic shutdown bit, MC.SHT,  and  any  special  shutdown
         bits in the SCDB.
                                                                    Page 13


     2.  A BUGCHK SRVFSN is issued.

     3.  The connection is aborted using SCA call SC.ABT

     4.  All disk units are marked "offline" to the  connector  by  turning
         off the appropriate bit in the UDB

     5.  All queued commands (except those  awating  IORB  completion)  are
         released.




4.3.3  Function 3 - Response To Listen - This callback indicates that  some
connector  wants  to establish a connection with us.  This rotine checks to
insure that the connector is identified as a KL in  the  SCA  configuration
data.   If  it  is  not  the  connection  is  rejected.   If it is a KL the
connection is accepted and the  state  of  the  connection  becomes  MC.WOK
(Waiting for OK to send).



4.3.3.1  Errors - If the settable ID bits in the connect ID  do  not  match
the  number  stored  in  SVSLSX  (the number of the known listner) then the
server BUGHLTs with MSSLNM (Listner no match)



4.3.4  Function 7 - Little Credit Remains - This  routine  simply   returns
immediatly.



4.3.5  Function 11 - OK To Send Data - This SCA callback indicates  that  a
connection  is  fully  open  and  ready  to send and recieve messages.  The
conection state is set to MC.OKS (ok to send) and the timeout value is  set
to  60  seconds  as  required by [1].  The current time is used as the last
time a message was recieved from the connector.



4.3.6  Function 12 - Credit Available - This  routine  retries  all  queued
commands  for a connection.  If a command has been retried more than MSRTMX
(the timeout value currently 15) times the server assumes that the  command
will  never  complete and it closes the connection (see description of Port
broke connection).  The following table describes the retry  routine  based
on command state.

      STATE            !     ACTION
   ------------------------------------------------------------
      Command          !     Treat like new message recieved
   ------------------------------------------------------------
   Waiting to send end !     Send end packet
   ------------------------------------------------------------
   Wait for send data  !     No action
                                                                    Page 14


   ------------------------------------------------------------
   Wait for recv data  !     No action
   ------------------------------------------------------------
   Wait for IORB done  !     No action
   ------------------------------------------------------------
   Wait to send data   !     Send data
   ------------------------------------------------------------
   Wait to request data!     Request data
   ------------------------------------------------------------
   Any other state     !     BUGHLT SVILST



4.3.6.1  Errors - A BUGCHK, SRVCTO (Command TimeOut) is issued if a command
times out and the connection is closed.

If an illegal command  state  is  found  the  system  BUGHLTs  with  SVILST
(ILlegal STate).



4.3.7  Function 13 - Node Going Offline - Node going offline is simply  one
case  of  shutting down a connection.  It differs from the other cases only
in that the status bit MC.NOF is set in the SCDB.



4.3.8  Function 14 - Named Buffer Transfer Complete - This function is used
to  notify  the  MSCP  server that a transfer of data has completed.  These
data transfers are used to obtain and send the object  of  READ  and  WRITE
commands,  namely  pages  of data.  The service routine searches the queued
commands for a command whose buffer name matches the one provided  by  SCA.
When  the matching command is found it's state is checked against all legal
states.  The following table summarizes the action taken based on state.

           STATE        !     ACTION
   ------------------------------------------------------------
   Aborted              !     Send aborted end packet
   ------------------------------------------------------------
   Waiting for send data!     Send end packet (new state "wait to send end")
   ------------------------------------------------------------
   Waiting for recv data!     Give IORB to PHYSIO (new state "wait for IORB")
   ------------------------------------------------------------
   Any other state      !     BUGHLT SVILST



4.3.8.1  Errors - If no command is found which has a matching  buffer  name
the system BUGHLTs with SRVDNQ (buffer Done command Not Queued).

If an illegal command  state  is  found  the  system  BUGHLTs  with  SVILST
(ILlegal STate).
                                                                    Page 15


4.4  MSCP Commands

All MSCP commands are SCA messages.  All commands except READ and WRITE are
handled  in  a  similar  manner;   the  command  specifies  an action to be
performed and the driver which issued  the  command  is  returned  an  "end
packet"  which  is  also an SCA message.  The commands which are handled in
this manner are:

     1.  Set Controller Characteristics

     2.  Abort

     3.  Get Command Status

     4.  Get Unit Status

     5.  Available

     6.  Online


All of these commands fail only if the end packet buffer cannot be obtained
from  SCA  or  if  the  send  of  the  end  packet fails.  If the buffer is
unavailable the command is queued and  it's  state  remains  the  origional
"Command" state.



4.4.0.1  End Packet Transmission - If the end packet  cannot  be  sent  the
command is queued in state "wait to send end".  The image of the end packet
will be BLTed to the message area of the queued command and the  length  of
the  end  packet  saved  in the queued command header.  When credit becomes
available this end packet image is used to build the end  packet  which  is
resent at this time.

The following describes any features of  the  implementation  which  differ
from the description in [1] or are specific to TOPS-20.



4.4.1  Set Controller Characteristics - This command functions as described
in  [1].  It sets the bit in the connection status word to enable ATTENTION
messages if the driver requests it.  It also sets the driver timeout  value
and returns the server timeout value.



4.4.2  Abort - This function aborts the command specified.  If the  command
is  queued  and  not waiting for an IO operation to complete (IO states are
"Wait IORB", "Wait for send data" and "Wait for  recieve  data")  then  the
server  simply  sends  an  aborted  command  end packet.  If the command is
waiting for IO then it cannot be  aborted  until  the  IO  completes.   The
command  is  flagged as aborted in the queued command header.  This flag is
checked during IO completion processing and the aborted end packet is  sent
then.
                                                                    Page 16


4.4.3  Get Command Status - This returns a commands status if  the  command
is  found  (queued).   A  commands  status  is  determined by the following
formula:

  STATUS = (MAX TIMEOUT VALUE + 1) - CURRENT VALUE

  If command is waiting for IO then STATUS = STATUS * 2



4.4.4  Available - This command marks a unit MSCP  available.   The  states
AVAILABLE  and  ONLINE are determined by the setting of a bit in the UDBCHR
word of the disk units UDB.  There is 1 bit for each driver  (CI  host)  in
this  word.   Collectivly  these  bits are defined as UC.OLB (OnLine Bits).
The  bit  number  for  a  driver  is  (35  -  MAXDRIVERS)  +  DRIVERNUMBER.
DRIVERNUMBER is the index into the SCDB table and is stored as the settable
bits in the connect ID.  The AVAILABLE command clears the bit.



4.4.5  Online - The  ONLINE  command  sets  the  bit  describes  inder  the
AVAILABEL command.



4.5  IO Commands - READ And WRITE

The IO commands, READ and WRITE,  are  handled  somewhat  differently  than
other  MSCP commands since they require more resource management and do not
normally complete in a single step.  The 2 commands differ in the order  of
execution  of  their  steps  as  shown  in  figures  3  and 4 but the steps
themselves are common.  Both commands must:

     1.  Find the correct disk unit for IO operations.

     2.  Aquire a physical memory page for data transfer

     3.  Build a long form IORB to send to PHYSIO to  initiate  the  actual
         data trantfer from/to memory

     4.  Initiate the data  transfer  to/from  memory  form/to  disk  using
         PHYSIO

     5.  Initiate a named buffer transfer

     6.  Send a command end packet to the driver




                          Figure 3 - READ Command



                         Figure 4 - WRITE command
                                                                    Page 17


4.6  PHYSIO Interface

The MSCP server uses PHYSIO as a resource.  It uses various  Global  PHYSIO
subroutines  in the same manner as the rest of TOPS-20 (for example "find a
unit", "check legality of a unit", "step to the next unit" ...).   It  also
calls  the subroutine PHYSIO to schedule IORBs for disk transfers.  Drivers
which call PHYSIO can be notified at IORB start time  and  IORB  completion
time by specifying subroutine addresses in word IRBIVA of a long form IORB.

The MSCP server is called only at IORB completion time.  It checks  to  see
that the command has not been aborted.  If it has been it sends the aborted
command end packet and releases the command and it's resources.

If the  command  has  not  been  aborted  the  MSCP  server  proceeds  with
processing the command as shown in figures 3 and 4.



4.7  SMON / TMON / SETSPD Interface - AVAILABLE ATTENTION MESSAGE

The MSCP server requires a small user interface so that a subset of massbus
disks  may  be  selected  for  the  MSCP  server's  use.  This interface is
provided by the SMON and TMON jsyses and through the SETSPD commands  ALLOW
and RESTRICT.

A description of the SETSPD commands and JSYS interface  may  be  found  in
[TBS].   The  following  describes the implementation of these commands and
the handling of AVAILABLE ATTENTION MESSAGES.



4.7.1  RESTRICT / ALLOW - The SETSPD RESTRICT command causes a disk to stop
being  serviced  by  the  MSCP  server.  The ALLOW command has the oppsoite
effect.  The MSCP server determines whether a disk is RESTRICTed or ALLOWED
through the use of a bit, US.CIA, in the UDBSTS word of the disk units UDB.
US.CIA (CI Available) is cleared when a drive is RESTRICTed  and  set  when
the  drive is ALLOWed.  When a drive is allowed the MSCP server must notify
the MSCP drivers that have open connections to the server that there  is  a
new  disk online.  This must also happen when an ALLOWed drive comes online
to PHYSIO.



4.7.2  AVAILABLE ATTENTION MESSAGE - When The server must inform  a  driver
that  a new disk is online (either because the drive was ALLOWed or because
a previously ALLOWed comes online to TOPS-20) it  sends  all  drivers  with
connections  an  AVAILABLE ATTENTION MESSAGE.  Each drive that must have an
attention message sent for it has the bit US.BDK  (Broadcast)  set  in  the
UDBSTS word of the UDB.  The MSCP server maintains a count of the number of
drives which must have attention messages sent.

The MSCP server sends this  attention  message  to  all  drivers  who  have
enabled  attention  messages  and who have not issued an ONLINE command for
that unit.  When all drivers are successfully sent  the  attention  message
the  bit,  US.BDK, is cleared and the count of needed attention messages is
                                                                    Page 18


decremented.

If the server fails to send any driver an attention message it  leaves  the
bit, US.BDK, set in the UDB and does not decrement the count.  If the count
is non-zero during a periodic check the UDBs  are  scanned  and  all  those
having  US.BDK  set  have attention messages sent regarding them.  A driver
may recieve multiple attention messages for the same unit (allowed by  [1])
if the following occurs:

     1.  A send of an attention message succeeds to this driver  and  fails
         for some other driver.

     2.  The driver who recieved the attention message did not  ONLINE  the
         drive before the next periodic check
MSCP-SERVER.FUNCTIONAL-SPECIFICATION

















                       Functional description of the
                        TOPS-20 MSCP Server, PHYMVR

                        1-Sep-83 Revised: 24-NOV-84

                           Version 1, Revision 2
MSCP Server Functional Specification                                 Page 2


1.0  ARCHITECTURAL POSITION

PHYMVR is the TOPS-20 MSCP server module.  It is responsible  for  granting
access  to  massbus disks across the CI-20.  The only supported user of the
MSCP  server  is  the  TOPS-20  MSCP  driver  (PHYMSC).   The  MSCP  server
implements  only the subset of MSCP functions required for the operation of
PHYMSC.

The server appears to the MSCP driver to be an intelligent disk  controller
much  like  the  HSC50.   The MSCP server interfaces to TOPS-20 as a device
independant disk driver a la the DSKOP Jsys.   It  functions  at  a  higher
architectural  level  than  PHYSIO  but at a lower level than PAGEM/PAGUTL.
That is, the MSCP server has no knowledge of the file system format.

Because of the desirability of restricting the set of disks  which  can  be
accessed  through  the  MSCP  server, a small JSYS level interface has been
provided as a means of limiting the set of disks available through the MSCP
server.   The  SETSPD  program has been expanded to include 2 new commands,
ALLOW and RESTRICT, to provide the system administrator  with  a  means  to
select the disk drives which are handled by the MSCP server.

The server is a SCA SYSAP.  It communicates with the MSCP driver by sending
messages  and  data  across  the  CI  using  the facilities provided by the
TOPS-20 SCA interface described in [3].  The server is a generally  passive
device, responding to requests issued by the MSCP driver.

The MSCP server is needed only when the TOPS-20 Common File  System  is  in
use.  It is loaded under a conditional, CFSCOD, which also controls the use
of CFS.
MSCP Server Functional Specification                                 Page 3




















































                      Figure 1 - Software Components
MSCP Server Functional Specification                                 Page 4


2.0  RELATED STANDARDS AND SPECIFICATIONS

This document describes, at a functional level, those aspects of  the  MSCP
server  not  specified  in other documents.  In order for you to understand
this functional specification, you must  be  familiar  with  at  least  the
terminology, if not the details, of the following:

     1.  Mass Storage Control Protocol Version 1.2, 8-Apr-82 (Gardner)

     2.  TOPS-20 MSCP Driver Design Specification 20-Sep-83 (Mclean)

     3.  TOPS-20 SCA Functional Specification 21-Nov-83 (Dunn)

     4.  Systems Communications Architecture, 20-July-82 (Strecker)

     5.  TOPS-20 Coding Standard, 23-Mar-83 (Murphy)

     6.  PHYSIO.MAC TOPS-20 Physical IO module




3.0  GENERAL LIMITATIONS AND RESTRICTIONS

The MSCP server will only communicate with 4 MSCP drivers.  This can easily
be changed to allow any number of drivers.

Only one MSCP server can run at a time.   The  changes  required  to  allow
several  MSCP  servers are fairly minor.  There is probably no advantage to
running more than 1 MSCP server since the code is mainly  interrupt  driven
and very compact.



4.0  SETSPD / SMON% / TMON% INTERFACE FOR SYSTEM ADMINISTRATORS

The SMON% Jsys provides a method for a given site to limit the set of disks
available  through  the MSCP server.  This interface is available to a site
manager through the use of the RESTRICT and ALLOW commands of SETSPD.

When  a  system  is  booted  all  disks  are  treated  as  CI   unavailable
(RESTRICTed).  To set them available (ALLOWed) the following must be done:

        MOVEI AC1,.SFMSD
        MOVEI AC2,<address of argument block>
        SMON%

        where <argument block> has the following format

        OFFSET VALUE DESCRIPTION
        ------ ----- -----------
        .SVCNT   0   length of the block including this word
        .SVTYP   1   flags and drive type
        .SVDSH   2   High order serial number word
        .SVDSN   3   Low order serial number word
MSCP Server Functional Specification                                 Page 5



NOTE: Currently the high order serial number word for massbus disks is computed
by the monitor. The formula is:

        MOVEI AC1,<drive type>
        IORI AC1,400
        LSH AC1,20

Drive type symbol may be one of the following:

    .MSRP4==:1                  ;RP04
    .MSRP5==:5                  ;RP05
    .MSRP6==:6                  ;RP06
    .MSRP7==:7                  ;RP07
    .MSR20==:24                 ;RP20

         or use the SETSPD command

        ALLOW <drive type> <serial number (low)>

         or the alternate form

        ALLOW <drive type> <serial number (high)> <serial number (low)>

Drive type name may be one of the following:

    RP04
    RP05
    RP06
    RP07
    RP20

Examples:

          ALLOW RP06 1234
          ALLOW RP20 3327

        RETURNS:        +1 ALWAYS disk drive available

        Illegal instruction trap on the following conditions

                MSCPX1 - No MSCP server in current monitor
                MSCPX2 - Drive type error
                MSCPX3 - Requested drive not found
                SMONX1 - WHEEL or OPERATOR capability required

To set a disk drive unavailable use the following instruction sequence:


        MOVEI AC1,.SFMSD
        MOVEI AC2,<address of argument block>
        SMON%

        where <argument block> has the following format
MSCP Server Functional Specification                                 Page 6


        OFFSET VALUE DESCRIPTION
        ------ ----- -----------
        .SVCNT   0   length of the block including this word
        .SVTYP   1   flags and drive type. To restrict specify MS%DDU
        .SVDSH   2   High order serial number word
        .SVDSN   3   Low order serial number word

         or use the SETSPD command

        RESTRICT <drive type> <serial number (low)>

         or the alternate form

        RESTRICT <drive type> <serial number (high)> <serial number (low)>

Examples:

          RESTRICT RP06 17170432 1234
          RESTRICT RP20 3327

        RETURNS:        +1 ALWAYS disk drive restricted

        Illegal instruction trap on the following conditions

                MSCPX1 - No MSCP server in current monitor
                MSCPX2 - Drive type error
                MSCPX3 - Requested drive not found
                SMONX1 - WHEEL or OPERATOR capability required

There is a corresponding TMON% interface for reading  the  status  of  disk
drives it is:


        MOVEI AC1,.SFMSD
        MOVEI AC2,<address of argument block>
        TMON%

        where <argument block> has the following format

        OFFSET VALUE DESCRIPTION
        ------ ----- -----------
        .SVCNT   0   length of the block including this word
        .SVTYP   1   flags and drive type
        .SVDSH   2   High order serial number word
        .SVDSN   3   Low order serial number word

        RETURNS:        +1 ALWAYS T2/  0  drive is available through the 
                                          MSCP server
                                  T2/  1  drive is not available

        Illegal instruction trap on the following conditions

                MSCPX1 - No MSCP server in current monitor
                MSCPX2 - Drive type error
                MSCPX3 - Requested drive not found
MSCP Server Functional Specification                                 Page 7


There is no limitation on  the  number  of  disks  which  may  be  set  "CI
available"  since  the  server  is designed to handle an infinite number of
disks.  The MSCP driver may have a maximum number  of  disks  that  it  can
handle  but  the  server  cannot  determine  this  limit.  Since a site can
potentially rebuild their monitor to handle more or  less  disks  than  the
default,  the server does not return an error nor make any checks regarding
the number of disks serviced.  It is up  to  the  system  administrator  to
insure  that  the  number  of  disks serviced does not exceed the number of
disks accessable by the MSCP drivers on the CI.  At the  present  time  the
TOPS-20 MSCP driver will support up to 24 disks.



5.0  MSCP DRIVER INTERFACE

The complete interaction rules for an MSCP server and an  MSCP  driver  are
described  in  [1].   The  TOPS-20 MSCP server provides access only to disk
drives and does  not  provide  any  tape  device  service.   The  functions
implemented  by  the  TOPS-20 MSCP server are described in section 6 of [1]
entitled "Minimal Disk  MSCP  subset".   Therefore  the  following  section
describes  only  limitations,  differences  and restrictions of the TOPS-20
MSCP server implementation.



5.1  Unit Flags

The following restrictions apply to the unit flags described in section 6.1
of [1].

     1.  Compare reads and Compare writes -  These  flags  are  unsupported
         under  TOPS-20.   These  flags are not used by the MSCP driver and
         would require space in the UDB to implement.

     2.  Controller initiated Bat Block replacement - This flag  is  always
         returned  clear  since  the  MSCP  server  does  not  do BAT block
         replacement.  The server expects  that  the  driver  will  do  all
         management of BAT blocks.

     3.  Inactive shadow set unit  -  The  MSCP  server  does  not  support
         shadowing  and  does not examine this flag.  It is always returned
         clear.

     4.  Cache flags - The MSCP server does not support cacheing  and  does
         not examine these flags.  They are always returned clear.

     5.  Write protect (software) - This flag is unsupported under  TOPS-20
         as it is unused by the MSCP driver, and would require space in the
         UDB to implement.

     6.  576 byte sectors - This  flag  is  always  returned  set,  as  all
         TOPS-20 disks have logical sectors of 576 (32 bit) bytes.


All other unit flags are fully supported as described.
MSCP Server Functional Specification                                 Page 8


5.2  Controller Flags

The following restrictions apply  to  the  controller  flags  described  in
section 6.2 of [1].

     1.  Error log flags - These flags are fully  supported  in  the  sense
         that they are allowed to be set, but the MSCP server does not send
         error log datagrams.

     2.  Controller initiated bat block replacement - This flag  is  always
         returned clear since the MSCP server does not handle BAT blocks.

     3.  Shadowing - This flag is always  returned  clear  since  the  MSCP
         server does not support shadow units.

     4.  576 byte sectors - This flag is always returned set as all TOPS-20
         formatted disks have logical sectors of 576 (32 bit) bytes.


All other controller flags are fully supported as described.



5.3  Command Modifiers

The following restrictions apply to  the  command  modifiers  described  in
section 5.4 of [1].

     1.  Clear Serious Exception - This modifier is ignored.

     2.  Compare - This modifier is partially supported.  If this  modifier
         is  specified  on  a  READ or WRITE command then the IORB function
         "read validity" or "write validity" is used instead of  "read"  or
         "write".   However  the data is not reobtained from the source and
         compared with the destination data.

     3.  Express Request - This modifier is ignored.

     4.  Force Error - This modifier is ignored.

     5.  Suppress Error Correction - This modifier is ignored.

     6.  Suppress Error Recovery - This modifier is ignored.


Modifiers which affect caching and shadowing are  ignored,  as  the  server
does  not  support  these  features.  All other command modifiers are fully
supported as described.
MSCP Server Functional Specification                                 Page 9


5.4  Services Provided To The MSCP Driver

5.4.1  Supported Functions -

All supported functions contain a section labelled "Description"  which  is
copied  verbatim  from  [1].  This description is provided as an aid to the
reader  and  is  NOT  intended  to  provide  a  full  description  of   the
functionality  and  interactions  of  the  described  command.   A complete
understanding of these functions and interactions  may  be  found  in  [1].
Please  remember  that  all  references in the "Description" section of the
supported commands are references to [1] and not to this document.

     1.  ABORT command

               Description:

                   The ABORT command causes a specified command to be aborted at
                   the   earliest  time  convenient  for  the  controller.   The
                   specified command must, however,  either  be  aborted  or  be
                   completed   within  the  controller  timeout  interval.   See
                   Section 4.10, "Command Timeouts", for  a  discussion  of  the
                   interaction between ABORT and command timeouts.

                   The ABORT command always succeeds.   If  the  command  to  be
                   aborted  is not known to the controller, this implies that it
                   has already completed and the ABORT command will be  ignored.
                   The controller always returns the "Normal" status code in the
                   ABORT command's end message.

                   The controller may ignore the ABORT command  if  the  command
                   being  aborted  will  always  complete  within the controller
                   timeout interval.

                   The class driver must wait  for  the  aborted  command's  end
                   message,  or else re-synchronize with the MSCP server, before
                   reusing the aborted command's  command  reference  number  or
                   releasing  the aborted command's context.  If the command was
                   aborted, its end message will contain the  "Command  Aborted"
                   status  code.   Otherwise,  the  command  was completed.  The
                   class driver may ignore  the  ABORT  command's  end  message.
                   Note  that  the  class driver may receive the ABORT command's
                   end message either before or after the aborted command's  end
                   message.

         The ABORT command functions exactly as described.

     2.  AVAILABLE attention message

               Description:

                   An MSCP server sends an  AVAILABLE  attention  message  to  a
                   "Controller-Online"  class  driver when a unit asynchronously
                   becomes  "Unit-Available"  to  that  class   driver,   unless
                   AVAILABLE  attention  messages  have been suppressed for that
                   unit by an AVAILABLE command with the "Spin-down" modifier or
MSCP Server Functional Specification                                Page 10


                   by  an  error  with  similar  side  effects.   Changes to the
                   "Unit-Available" state due to the class driver itself issuing
                   an  AVAILABLE  command are synchronous.  All other changes to
                   "Unit-Available" are asynchronous.  See  Section  4.3,  "Unit
                   States".

                   The actual sending of an AVAILABLE attention message  may  be
                   delayed  for  an arbitrarily long time, due to communications
                   mechanism flow control, from the time that the unit  actually
                   becomes  "Unit-Available".   The  message must not be sent if
                   the class driver ceases to be "Controller-Online" during this
                   delay.   The  message must be sent anyway if the unit, or any
                   unit  with  which  it  shares   an   access   path,   becomes
                   "Unit-Online"  via another controller during this delay.  The
                   message may or may not be sent, at the  controller's  option,
                   if  the  unit  ceases  to  be  "Unit-Available" for any other
                   reason during this delay.

                   Note that, due  to  these  delays,  it  is  possible  for  an
                   AVAILABLE  attention  message  to be received after the class
                   driver has already brought the unit "Unit-Online".  Therefore
                   class  drivers  must  not use AVAILABLE attention messages to
                   flag "Unit-Online" units as having  become  "Unit-Available".
                   The  proper  procedure  is  to issue a command, such as a GET
                   UNIT STATUS, to a "Unit-Online" unit for which  an  AVAILABLE
                   attention  message  has been received, and only flag the unit
                   as having become "Unit-Available" if the command returns that
                   status code.

                   AVAILABLE attention messages are not sent for units that  are
                   already   "Unit-Available"   when   a  class  driver  enables
                   attention messages.  Class drivers that need to be  aware  of
                   all  "Unit-Available"  units  must enable attention messages,
                   then scan all units via the GET UNIT STATUS command with  the
                   "Next Unit" modifier set to locate all units that are already
                   "Unit-Available".   All  units   that   subsequently   become
                   "Unit-Available" will be reported with an AVAILABLE attention
                   message.

                   An MSCP server may  send  redundant  or  erroneous  AVAILABLE
                   attention  messages  at  any  time.   The  frequency  of such
                   messages must be low enough that  they  do  not  represent  a
                   significant  overhead  for either hosts or the communications
                   mechanism.  The information contained in such messages  (unit
                   number,  unit  identifier,  media type identifier, etc.) must
                   correspond to an actual, physical unit  that  is  potentially
                   accessible  via  that  MSCP  server  (i.e.,  connected to the
                   controller), although the unit need not be  "Unit-Available".
                   Note  that  hosts  must be able to handle seemingly erroneous
                   AVAILABLE attention messages in any case,  since  the  unit's
                   state  may  change  before  the  host can act on an otherwise
                   correct message.

         The AVAILABLE attention message is sent when a disk drive  is  set
         "CI-available"  through  the  SMON%  monitor  call  if the disk is
MSCP Server Functional Specification                                Page 11


         locally online.  Otherwise, it is sent when a disk which has  been
         set "CI available" comes online locally.  This message is not sent
         to a driver if it has not enabled attention  messages  or  if  the
         unit is already "Unit online" to a driver.  It is possible for the
         driver to recieve multiple  attention  messages  for  single  unit
         until that unit is ONLINEd by the driver.

     3.  AVAILABLE Command
               Description:

                   All  outstanding  commands  for  the   specified   unit   are
                   completed,  then  the  unit becomes "Unit-Available".  If the
                   "Spin-down" modifier was  not  specified,  the  unit  is  not
                   already  "Unit-Available", and no other units that share this
                   unit's  access  path  are  "Unit-Online"  (i.e.,  the  "Still
                   Connected"  status  sub-code  bit  flag  is  clear),  then an
                   AVAILABLE attention message is sent by any  other  controller
                   to which the unit is connected.  The controller to which this
                   command was sent need not itself send an AVAILABLE  attention
                   message.

                   If the "Spin-down" modifier is specified, the disk spins down
                   and its heads are unloaded, unless some other unit with which
                   this unit shares a spindle is "Unit-Online".  The disk may be
                   spun  up  with an ONLINE command or by operator intervention.
                   The "Spin-down" modifier also suppresses AVAILABLE  attention
                   messages  for  this  unit,  both  for this controller and any
                   other controllers to which the unit may  be  connected.   See
                   Section  4.3,  "Unit States", for a discussion of suppressing
                   AVAILABLE attention messages.

                   This command will be accepted if the unit is "Unit-Online" or
                   "Unit-Available".   It is nugatory to issue this command to a
                   unit that is "Unit-Available" unless the "Spin-down" modifier
                   is  specified.  Assuming no other errors occur, the "Success"
                   status code will be returned regardless of whether  the  unit
                   was previously "Unit-Online" or "Unit-Available".

                   If the unit was "Unit-Online" but had a duplicate unit number
                   prior  to  the  AVAILABLE command being issued, the AVAILABLE
                   command may complete, at the controller's option, with either
                   a   "Success"   or   a   "Unit-Offline"   status  code.   The
                   "Unit-Offline" status code  must  have  the  "Duplicate  Unit
                   Number"  sub-code flag set.  The "Success" status code may or
                   may not, at the controller's option, have the "Duplicate Unit
                   Number" sub-code flag set.  Subsequent attempts to access the
                   unit will return "Unit-Offline" status  with  the  "Duplicate
                   Unit  Number"  sub-code  flag  set  unless the duplicate unit
                   number has been eliminated.

         The AVAILABLE command makes  the  unit  "unit  available"  to  the
         driver  which  issued the command.  If the "spin-down" modifier is
         specified the sub-code "Spin-down ignored"  is  returned.   It  is
         currently not possible to initiate an unload of an massbus disk at
         a  software  level.   The  sub-code  "Still  connected"  is  never
MSCP Server Functional Specification                                Page 12


         returned.

     4.  GET COMMAND STATUS Command

               Description:

                   The GET  COMMAND  STATUS  command  is  used  to  monitor  the
                   progress of a command towards completion.  The command status
                   measures the "doneness" of the command.  The  value  returned
                   in  the  command  status  field is guaranteed to not increase
                   over time.   Furthermore,  the  command  status  of  an  MSCP
                   server's oldest outstanding command is guaranteed to decrease
                   within the controller timeout interval.   This  last  feature
                   may  be  used  by  a host class driver to detect an insane or
                   malfunctioning  controller.   See  Section   4.10,   "Command
                   Timeouts", for more details.

                   The GET COMMAND  STATUS  command  always  succeeds.   If  the
                   command  referenced  by the "outstanding reference number" is
                   not known to the MSCP server or has been  aborted,  then  the
                   MSCP  server  should return zero for its command status.  The
                   MSCP server may also return zero as the command status of any
                   command  that  will  always  complete  within  the controller
                   timeout  interval.   The  MSCP  server  always  returns   the
                   "Normal"  status code in the GET COMMAND STATUS command's end
                   message.

         The GET COMMAND STATUS command  functions  exactly  as  described.
         The command status returned is a function of the command's timeout
         value.  It is guaranteed  to  decrease  so  long  as  the  timeout
         counter  is  incremented  at shorter intervals than the controller
         timeout period.

     5.  GET UNIT STATUS Command

               Description:

                   The GET UNIT STATUS command returns the current  state  of  a
                   unit  plus  certain unit characteristics.  In particular, the
                   GET UNIT STATUS command  is  used  to  obtain  host  settable
                   characteristics and those fixed unit characteristics that are
                   not normally needed by the class driver.

                   Class drivers  can  determine  which  of  the  returned  unit
                   characteristics  are valid by examining the returned "status"
                   and "unit identifier" fields.  The following cases exist:

                   1.  "status"  is  "Success",  implying  that  the   unit   is
                       "Unit-Online".  All characteristics are valid.

                   2.  "status" is anything  other  than  "Success",  and  "unit
                       identifier"  is  not zero.  All unit flags except for the
                       "Removable  media"  flag  are   undefined.    All   other
                       characteristics are valid.
MSCP Server Functional Specification                                Page 13


                   3.  "status" is anything  other  than  "Success",  and  "unit
                       identifier"  is zero.  Only the "shadow unit" and "shadow
                       status"   characteristics   are   valid.     All    other
                       characteristics are undefined.

                   The three cases listed above are  the  only  cases  that  can
                   occur.   Note  that  if  "status"  is  "Success"  then  "unit
                   identifier" cannot be zero.

                   Rather than testing the entire quadword unit  identifier,  it
                   is  sufficient to merely test the high order word of the unit
                   identifier, containing the class and model code bytes, to see
                   if it is zero or not.

                   Controllers must supply valid values for all  characteristics
                   whenever  the unit is "Unit-Online".  Controllers must supply
                   a  non-zero  unit  identifier  and  valid  values   for   all
                   characteristics except those noted above whenever the unit is
                   "Unit-Available" or the unit is "Unit-Offline" solely due  to
                   being  disabled or known.  Controllers may or may not, at the
                   controller's option, provide valid characteristics  when  the
                   unit  is  "Unit-Offline"  for  any  other reason or any other
                   status code is returned.
               
                   The rules in the above paragraphs can be restated as follows:
               
                   1.  If "status" is "Success", then "unit identifier" must  be
                       non-zero and all characteristics must be valid.
               
                   2.  If "status" is "Unit-Available", then  "unit  identifier"
                       must  be  non-zero and almost all characteristics must be
                       valid.

                   3.  If "status" is "Unit-Offline" and the sole causes of  the
                       unit  being  offline are it being disabled or known, then
                       "unit  identifier"  must  be  non-zero  and  almost   all
                       characteristics must be valid.
               
                   4.  If "unit identifier" is zero, then "status"  must  either
                       be  "Unit-Offline"  with  some  reason other than the the
                       unit being disabled or known indicated, or "status"  must
                       be  "Controller  Error"  or  "Drive Error".  Virtually no
                       characteristics need be valid.

         The GET UNIT STATUS command functions exactly as described.

     6.  ONLINE Command

               Description:

                   The ONLINE command is used to bring a unit "Unit-Online", set
                   host  settable  unit  characteristics,  and obtain those unit
                   characteristics that are essential for  proper  class  driver
                   operation.   The unit is spun-up, if necessary, and its heads
                   are loaded  prior  to  returning  the  ONLINE  command's  end
MSCP Server Functional Specification                                Page 14


                   message.  Host settable characteristics are set exactly as if
                   a SET UNIT CHARACTERISTICS  command  were  issued.   See  the
                   description  of  that command.  Host settable characteristics
                   are set after the unit has been successfully spun-up and  any
                   other  validity  checks have succeeded.  Note that the unit's
                   host settable characteristics are NOT altered if the unit  is
                   already "Unit-Online".

                   The class driver must check if the "Controller Initiated  Bad
                   Block Replacement" unit flag is set or clear after bringing a
                   unit "Unit-Online".  If it is clear (implying that  the  host
                   is  performing  bad block replacement), then the class driver
                   must invoke a process that will access the unit's Replacement
                   and  Caching  Table  to  determine if a bad block replacement
                   operation has been partially performed or if the unit must be
                   write   protected.    The  details  of  this  check  and  its
                   consequences  are  described  in  Section  4.12,  "Bad  Block
                   Replacement", and DEC Standard Disk Format.  Controllers that
                   support Controller Initiated Bad  Block  Replacement  perform
                   these checks themselves.
          
                   Note that the format of the ONLINE command's end  message  is
                   identical  to  the  SET  UNIT  CHARACTERISTICS  command's end
                   message.

         The ONLINE command functions exactly as described.   It  is  never
         necessary  for a unit to be spun up.  It is a requirement that the
         disk be online at the local system to become "unit  available"  to
         the  MSCP  driver.   Massbus disks that are not spinning cannot be
         online at the local system.  For a complete  description  of  MSCP
         unit  states  see  the  section  entitled "MSCP unit states" under
         "Algorithms".

     7.  READ Command

               Description:

                   Data is read from  the  unit  and  transferred  to  the  host
                   buffer.

         The  read  command  functions  as  described.   If  the  "compare"
         modifier  is  used then data is read using the IORB function "read
         validity".

     8.  SET CONTROLLER CHARICTERISTICS Command

               Description:

                   The SET CONTROLLER CHARACTERISTICS command is used to set and
                   obtain  controller  characteristics.   The  default value for
                   "cntrlr. flags"  is  all  flags  clear  (i.e.,  all  messages
                   disabled).   The  default  value  for  "host  timeout"  is 60
                   seconds.  These default values are used from  the  time  that
                   the controller becomes "Controller-Online" to a host until it
                   stops being "Controller-Online" or until the  host  issues  a
MSCP Server Functional Specification                                Page 15


         The SET CONTROLLER CHARACTERISTICS command  functions  exactly  as
         described.   The  controller  identifier  is  composed  of the CPU
         serial number in the first word and a magic number in  the  second
         word.   This magic number is required because there is no assigned
         identifier number for a TOPS-20 MSCP server.

     9.  WRITE Command

               Description:

                   Data is fetched from the host data buffer and written to  the
                   unit.

         The write  command  functions  as  described.   If  the  "compare"
         modifier  is  used  then  data  is written using the IORB function
         "write validity".




5.4.2  Unsupported And Illegal Functions -

The following functions are part of the Minimal disk MSCP subset  described
in  [1].   They  are  not  implemented by the MSCP server for the following
reasons:

     1.  They are not required for the operation of the TOPS-20 MSCP driver
         and, in fact, are unused by the MSCP driver.

     2.  There is no existing method of testing these functions.

     3.  Implementation  of  these  functions  would  require   significant
         ammounts of code and data to be added to the TOPS-20 monitor.

     4.  These commands can be implemented should they be required  in  the
         future.

Commands specifying an unsupported function are treated like commands which
specify  an illegal function.  An "Invalid command end message" is returned
with sub code "Invalid opcode" specified.  The unsupported functions are:

     1.  ACCESS Command

     2.  ACCESS PATH Attention Message

     3.  COMPARE CONTROLLER DATA Command

     4.  COMPARE HOST DATA Command

     5.  DETERMINE ACCESS PATHS Command

     6.  DUPLICATE UNIT NUMBER Attention Message
MSCP Server Functional Specification                                Page 16


     7.  ERASE Command

     8.  FLUSH Command

     9.  SET UNIT CHARACTERISTICS Command




6.0  PHYSIO INTERFACE

The PHYSIO system of TOPS-20 provides the means by which  the  MSCP  server
accesses  massbus  disks.   The  MSCP server also stores disk unit specific
data in the Unit Data Block (UDB) for each disk.  This data is used only by
the MSCP server.



6.1  Services Provided By PHYSIO

The following is a list of PHYSIO services used by the MSCP server.  A  one
line description follows each subroutine name.  For calling conventions see
[6].

     1.  ADVCKS - Used to step to the next Channel, Kontroller, and Unit

     2.  CDSCCW(CDB) - Used to generate a CCW for a channel

     3.  CHKCKS - Used to check the validity of a Channel,  Kontroller  and
         Unit number

     4.  DGUMAP - Used to execute an instruction for each unit on a channel

     5.  FNDCKS - Converts from datablock addresses to C K U numbers

     6.  PHYSIO - Initiate a data operation (Read or Write)




6.2  PHYSIO Entries To The MSCP Server


1.  When a disk goes offline PHYSIO calls the MSCP  server.   This  insures
that  no  driver sees that disk as "controller online" until another ONLINE
command is issued by that driver.  NOTE:  This applies to the PHYOFL  label
in  PHYSIO  and  does not indicate that the drive is offline because of the
port being locked to the other side.

2.  PHYSIO also calls the MSCP server when a disk comes online so that  the
MSCP  server  may send an AVAILABLE attention message to all drivers if the
disk is marked as "CI Available".  If the disk is not "CI  available"  when
it  comes  online  the  MSCP  server flags job 0 to run SETSPD at a special
entry point to process ALLOW commands.  This is the same entry  point  that
processes tape drives coming online.
MSCP Server Functional Specification                                Page 17


3.  PHYSIO calls MSSIRD at IORB completion.  The address of the routine  to
call (MSSIRD) is stored in the IORB at location IRBIVA.



7.0  SERVICES REQUIRED OF SCAMPI

A full description of the services provided by SCAMPI may be found in  [3].
The MSCP server utilizes the following functions and callbacks.



7.1  SCAMPI Callbacks


     1.  Function 1 - .SSMGR - Message recieved

     2.  Function 2 - .SSPBC - Port broke connection

     3.  Function 3 - .SSCTL - Response to listen

     4.  Function 11 - .SSOSD - OK to send data

     5.  Function 12 - .SSRID - Request disconnect

     6.  Function 13 - .SSCIA - Credit available

     7.  Function 14 - .SSDMA - Named buffer transfer complete


Certain other SCA callbacks are ignored and do not generate  errors.   They
simply  return  to  SCA immediatly these are "don't care" conditions to the
server and are expected to occur during normal operation.  They are:

     1.  Function 5 - .SSMSC - Message or datagram send complete

     2.  Function 7 - .SSLCL - Little credit left


Finally there is a set of SCA callbacks which should  never  occur.   These
callbacks cause a BUGHLT, MSSSCA.  They are:

     1.  Function 0 - .SSDGR - Datagram recieved

     2.  Function 4 - .SSCRA - Connection response available

     3.  Function 6 - .SSDDG - Datagram dropped

     4.  Function 10 - .SSNCO - Node coming online
MSCP Server Functional Specification                                Page 18


7.2  Services Provided By SCAMPI


     1.  SC.ABF - Allocate a buffer

     2.  SC.ACC - Accept a connection

     3.  SC.DIS - Close a connection

     4.  SC.LIS - Listen for a connection

     5.  SC.NOD - Return node number given CID

     6.  SC.MAP - Map a named buffer

     7.  SC.RCD - Return configuration data for a node

     8.  SC.REJ - Reject a connection

     9.  SC.REQ - Request a named buffer

    10.  SC.SMG - Send a message

    11.  SC.SND - Send a named buffer

    12.  SC.UMP - Unmap a named buffer




8.0  PERIODIC CHECK

The MSCP server is called periodically by the  scheduler  as  part  of  the
normal  CLK2  scheduler cycle and when requested during the short scheduler
cycle.  During this periodic check the MSCP server does the following:

     1.  Retries all queued commands  and  closes  the  connection  if  the
         command has timed out.

     2.  Checks that all  drivers  have  communicated  within  the  drivers
         timeout  interval.  The connection is closed if the driver has not
         communicated.

     3.  Broadcasts AVAILABLE attention messages to drivers which  may  not
         have recieved the messages.

     4.  Checks the state of all SCA connections.
MSCP Server Functional Specification                                Page 19


9.0  ERROR HANDLING

9.1  Error Logging Datagrams

The MSCP server does not  generate  error  logging  datagrams,  nor  is  it
required   to   by  [1].   All  relevant  error  information  is  generated
automatically by existing mechanisms in PHYSIO  and  by  the  TOPS-20  BUG.
facility.   All relevant device error information is generated as a part of
the normal operation of PHYSIO.



9.2  IORB Error To MSCP Error Mapping

The following table shows the mapping of IORB errors  to  the  MSCP  status
bits which appear in the commands end packet.

      IORB ERROR BIT   !   MSCP STATUS BIT
      ------------------------------------
          IS.DVE       !      ST.DVE
          IS.WGU       !      ST.DVE
          IS.NRT       !      ST.DVE
          IS.DTE       !      ST.DAT
          IS.RTL       !      ST.DAT
          IS.WLK       !      ST.WPR




10.0  ALGORITHIMS

10.1  Unit Number Calculation

The MSCP server uses the following formula to determine unit numbers.

 <Unit number> = <channel number> * CHNCOD 
               + <<kontroller number> + 1> * KONCOD
               + <local unit number> + 1

Where CHNCOD = 420 octal and KONCOD = 20 octal.



10.2  Unit States

The following table describes the MSCP unit states.

        MASSBUS UNIT STATE !  ONLINE COMMAND GIVEN? !  MSCP UNIT STATE
                           !  AND IN EFFECT         !
        --------------------------------------------------------------
           Nonexistant     !          N/A           !  Offline
        ---------------------------------------------------------------
          Channel Offline  !          N/A           !  Offline
        ---------------------------------------------------------------
             Offline       !          NO            !  Offline
MSCP Server Functional Specification                                Page 20


        ---------------------------------------------------------------
             Offline       !          YES           !  Online **
        ---------------------------------------------------------------
             Online        !          NO            !  Available
        ---------------------------------------------------------------
             Online        !          YES           !  Online

** NOTE: When a unit is "massbus offline" it may be a transient condition due
to the drive being dual ported. If "MSCP online" is still in effect then the
unit is treated as "MSCP online" to save overhead. MSCP online is always 
cleared on an offline interrupt.



11.0  GLOBAL DATA STRUCTURES

11.1  UDB Changes

The MSCP server uses 2 bits in the UDBSTS word of the UDB.   The  first  of
these  bits,  US.BDK,  indicates that a broadcast of an AVAILABLE attention
message is needed.  There is also a bit, US.CIA, which is set  and  cleared
by  the  SMON  Jsys.   This  bit,  when  set, indicates that the disk is CI
available through the MSCP server.

The UDB characteristics word, UDBCHR, for disk devices contains a group  of
bits,  UC.OLB.   These bits are the rightmost bits in the word and indicate
which drivers have issued online commands for the unit.  There is  one  bit
for each driver (currently 4).



11.2  IORB Changes

Word IRBLEN of the long form IORBS contains  the  address  of  the  command
packet and the connection id index.  The CCW list starts at IRBLEN+1.



12.0  TESTING

The MSCP server will  be  tested  by  three  major  efforts:   DVT  (Design
Verification  Testing),  by  the  PAGES and MULTIO programs and by software
fault insertion and performance evaluation.  Additional testing will  occur
by  using  the disks for general timesharing.  DVT is conducted by hardware
engineering and includes a comprehensive fault insertion  effort  aimed  at
validating  the  operation  of  the hardware, microcode and software in the
face of failures.  This should provide adequate  assurance  that  the  MSCP
servers error recovery procedures are functioning correctly.

PAGES  and  MULTIO  are  programs  traditionally  used  to  verify   PHYSIO
interfaces to disks.  They provide heavy load to the PHYSIO/DISK structures
and when used on disks services by the MSCP  server  they  will  provide  a
considerable load for it also.

The software fault insertion  testing  is  an  informal  process  aimed  at
MSCP Server Functional Specification                                Page 21


testing   infrequently  used  paths  through  the  code.   The  performance
evaluation will be aimed at determining the  optimal  parameters  for  MSCP
server  operation,  and  determining  the typical access time for a page of
data on a disk handled by the MSCP server.  This  program  of  testing  and
evaluation  will  include running the MSCP server while there is a heavy CI
load and a heavy disk load.



13.0  DOCUMENTATION IMPACT

The  MSCP  server  is  largely  transparent  to   the   user   and   system
administrator.   Most existing documentation will be unnaffected except for
the following:

     1.  Monitor Calls  Manual  -  SMON%  and  TMON%  Documentation  should
         reflect the new function .SFMSD.

     2.  System Managers Guide - Should reflect the  new  SETSPD  commands,
         ALLOW and RESTRICT, and explain their use.

     3.  BUGHLT document - Should reflect the new BUGxxx gentrated  by  the
         MSCP server.

     4.  Installation Guide - Should reflect the new SETSPD commands.
MSCP12EXT.DOC




   Date:  30 October 1984


                                  PREFACE

           Due to the number  of  ECO  requests  currently  being
           considered  for  this document an update incorporating
           already approved ECOs will not be available  for  some
           time  to  come.   The  following is a list of the MSCP
           Version 1.2 ECOs approved up to this point:

            o  ECO #:   MSCP12-1  --  Geometry  Valid  Only  When
               ONLINE [approved March 1983]

            o  ECO #:  MSCP12-2 --  Error  Log  Sequence  Numbers
               [approved 7 February 1984]

            o  ECO #:  MSCP12-9 -- Reserve OPCODE Zero  [approved
               7 February 1984]

            o  ECO #:  MSCP12-10 -- Revised Appendix B (#MSCP12-6
               included) [approved as amended 16 March 1984]

            o  ECO #:  MSCP12-11 -- Revised Appendix C  [approved
               as amended 16 March 1984]

            o  ECO  #:   MSCP12-12  --  RCT  Access  Byte   Count
               Clarification [approved 16 March 1984]

            o  ECO   #:    MSCP12-16   --   Error   Log    Format
               Generalization [approved 29 June 1984]

            o  ECO #:  MSCP12-17 -- Expeditious  Abort  [approved
               29 June 1984]

            o  ECO #:  MSCP12-18 -- Revised  Appendix  B  for  BI
               [approved 29 June 1984]

            o  ECO  #:   MSCP12-19  --  Maximum  Error  Log  Size
               [approved 29 June 1984]

            o  ECO  #:   MSCP12-20  --   RC25   Waiver   Requests
               [approved 12 September 1984]

            o  ECO #:  MSCP12-22 -- Revised  Appendix  C  for  RX
               Drives [approved 29 June 1984]

            o  ECO #:  MSCP12-25 -- Revised Appendix C  for  QDAs
               [approved 29 June 1984]

            o  ECO  #:   MSCP12-26  --  Allocation  Class  Waiver
               (HSC/VMS) [approved 12 September 1984]

            o  ECO  #:   MSCP12-27  --  Read  Only  Device  Write
               Protect [approved as amended 10 August 1984]
                                                              Page 2
                                                     30 October 1984


            o  ECO  #:   MSCP12-30  --  Multi-Host  Functionality
               [approved as amended 10 August 1984]

            o  ECO #:  MSCP12-32 -- Maximum Byte Count  [approved
               10 August 1984]

            o  ECO #:   MSCP12-33  --  Controller  Initiated  Bad
               Block  Replacement  [approved as amended 10 August
               1984]

            o  ECO #:  MSCP12-34 -- Exclusive Access (Multi-Host)
               [approved as amended 10 August 1984]

            o  ECO #:  MSCP12-35 --  Access  Non-volatile  Memory
               Command [approved 14 September 1984]

            o  ECO #:  MSCP12-36 -- Data Encryption [approved  as
               amended 14 September 1984]
  
|           o  ECO #:  MSCP12-37 --  Host  BBR  Error  Log  Usage
|              [approved 19 October 1984]
|  
|           o  ECO #:  MSCP12-38 -- Host BBR RCT Full Error  Code
|              [approved 19 October 1984]
|  
|           o  ECO #:  MSCP12-39 -- TU81 Waiver Request [approved
|              19 October 1984]

           The text  of  the  approved  ECO  requests  have  been
           appended  to this document, effectively extending MSCP
           Version  1.2  to  include  the   revisions   described
           therein.

           Please contact  Jim  Zahrobsky  (DTN  522-2088,  E.net
           NEWTON::ZAHROBSKY)  for  information  regarding either
           approved or pending ECO requests.




                          Mass Storage Control Protocol

                             Version 1.2  08 Apr 82


                                Edward A. Gardner





             This document defines the Mass Storage Control Protocol
             (MSCP),  an  applications  protocol  intended  for  use
             between hosts and intelligent mass storage subsystems.

             Includes the  full  text  of  the  DEC  MSCP  standard,
             including references to unannounced products.


                        File:  MARIAH::HSC$DOCS:MSCP.DOC




        Digital Equipment Corporation makes no  representation  that  the
        interconnection  of  its  products in the manner described herein
        will not infringe existing or future patent rights,  nor  do  the
        descriptions  contained  herein imply the granting of licenses to
        make, use, or sell equipment or software constructed  or  drafted
        in accordance with the description.

        The information in this document is  for  informational  purposes
        only and is subject to change without notice by Digital Equipment
        Corporation.

        Digital assumes  no  responsibility  for  any  errors  which  may
        appear.

        The major trademarks of Digital Equipment Corporation are:

                   DEC            VT             IAS          
                   DECUS          DECsystem-10   MASSBUS      
                   DECMATE        DECSYSTEM-20   WORKPROCESSOR
                   DECnet         DECwriter      RSTS         
                   PDP            DIBOL          RSX          
                   UNIBUS         EduSystem      VMS          
                   VAX                                        


               Copyright, (c) Digital Equipment Corporation, 1982

                              COMPANY CONFIDENTIAL
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Table of Contents                                          Page 1
                                                                08 Apr 82


 1       Chapter 1       INTRODUCTION                                  

 2         1.1   Overview of MSCP Subsystem   . . . . . . . . . . . 1-1
 3         1.2   Purpose  . . . . . . . . . . . . . . . . . . . . . 1-3
 4         1.3   Method of Presentation . . . . . . . . . . . . . . 1-3
 5         1.4   Scope  . . . . . . . . . . . . . . . . . . . . . . 1-3


 6       Chapter 2       TERMINOLOGY                                   



 7       Chapter 3       CLASS DRIVER / MSCP SERVER COMMUNICATIONS     

 8         3.1   Connection . . . . . . . . . . . . . . . . . . . . 3-1
 9         3.2   Flow Control . . . . . . . . . . . . . . . . . . . 3-2
10         3.3   Class Driver Responsibilities  . . . . . . . . . . 3-5
11         3.4   MSCP Server Responsibilities . . . . . . . . . . . 3-6


12       Chapter 4       ALGORITHMS AND USAGE RULES                    

13         4.1   Controller States  . . . . . . . . . . . . . . . . 4-1
14         4.2   Controls and Indicators  . . . . . . . . . . . . . 4-4
15         4.3   Unit States  . . . . . . . . . . . . . . . . . . . 4-6
16         4.4   Unit Numbers . . . . . . . . . . . . . . . . . .  4-12
17         4.5   Command Catagories and Execution Order . . . . .  4-15
18         4.6   Class Driver / MSCP Server Synchronization . . .  4-19
19         4.7   Class Driver Error Recovery  . . . . . . . . . .  4-21
20         4.8   This section deliberately omitted. . . . . . . .  4-22
21         4.9   Host Access Timeouts . . . . . . . . . . . . . .  4-22
22         4.10  Command Timeouts . . . . . . . . . . . . . . . .  4-24
23         4.11  Disk Geometry and Format . . . . . . . . . . . .  4-27
24         4.11.1  Logical Block Number Address Space Structure .  4-27
25         4.11.2  Replacement and Caching Table (RCT) Overview .  4-28
26         4.11.3  Logical Block Contents . . . . . . . . . . . .  4-30
27         4.11.4  Performance Implications . . . . . . . . . . .  4-30
28         4.12  Bad Block Replacement  . . . . . . . . . . . . .  4-34
29         4.13  Write Protection . . . . . . . . . . . . . . . .  4-36
30         4.14  Compare Operations . . . . . . . . . . . . . . .  4-38
31         4.15  Multi-Unit Drives and Formatters . . . . . . . .  4-41
32         4.16  Controller and Unit Identifiers  . . . . . . . .  4-43
33         4.17  Media Type Identifiers . . . . . . . . . . . . .  4-44


34       Chapter 5       MSCP CONTROL MESSAGE FORMATS                  

35         5.1   Generic Control Message Format . . . . . . . . . . 5-1
36         5.2   Reserved and Undefined Fields  . . . . . . . . . . 5-3
37         5.3   Transfer Command Message Format  . . . . . . . . . 5-5
38         5.4   Command Modifiers  . . . . . . . . . . . . . . . . 5-8
39         5.5   End Message Format . . . . . . . . . . . . . . .  5-11
40         5.6   Status Codes . . . . . . . . . . . . . . . . . .  5-14
41         5.7   Unit Flags . . . . . . . . . . . . . . . . . . .  5-19
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Table of Contents                                          Page 2
                                                                08 Apr 82


 1         5.8   Controller Flags . . . . . . . . . . . . . . . .  5-21


 2       Chapter 6       MINIMAL DISK MSCP SUBSET                      

 3         6.1   Unit Flags . . . . . . . . . . . . . . . . . . . . 6-2
 4         6.2   Controller Flags . . . . . . . . . . . . . . . . . 6-4
 5         6.3   ABORT Command  . . . . . . . . . . . . . . . . . . 6-5
 6         6.4   ACCESS Command . . . . . . . . . . . . . . . . . . 6-7
 7         6.5   AVAILABLE Command  . . . . . . . . . . . . . . . . 6-9
 8         6.6   COMPARE CONTROLLER DATA Command  . . . . . . . .  6-12
 9         6.7   COMPARE HOST DATA Command  . . . . . . . . . . .  6-15
10         6.8   DETERMINE ACCESS PATHS Command . . . . . . . . .  6-17
11         6.9   ERASE Command  . . . . . . . . . . . . . . . . .  6-19
12         6.10  FLUSH Command  . . . . . . . . . . . . . . . . .  6-21
13         6.11  GET COMMAND STATUS Command . . . . . . . . . . .  6-24
14         6.12  GET UNIT STATUS Command  . . . . . . . . . . . .  6-27
15         6.13  ONLINE Command . . . . . . . . . . . . . . . . .  6-33
16         6.14  READ Command . . . . . . . . . . . . . . . . . .  6-39
17         6.15  REPLACE Command  . . . . . . . . . . . . . . . .  6-41
18         6.16  SET CONTROLLER CHARACTERISTICS Command . . . . .  6-43
19         6.17  SET UNIT CHARACTERISTICS Command . . . . . . . .  6-46
20         6.18  WRITE Command  . . . . . . . . . . . . . . . . .  6-52
21         6.19  Invalid Command End Message  . . . . . . . . . .  6-54
22         6.20  ACCESS PATH Attention Message  . . . . . . . . .  6-56
23         6.21  AVAILABLE Attention Message  . . . . . . . . . .  6-57
24         6.22  DUPLICATE UNIT NUMBER Attention Message  . . . .  6-60


25       Chapter 7       DISK MSCP OPTIONS                             

26         7.1   Multi-Host Support . . . . . . . . . . . . . . . . 7-1
27         7.2   Controller Initiated Bad Block Replacement . . . . 7-1
28         7.3   Caching  . . . . . . . . . . . . . . . . . . . . . 7-1
29         7.4   Shadowing  . . . . . . . . . . . . . . . . . . . . 7-1


30       Chapter 8       MSCP ERROR LOG MESSAGE FORMATS                

31         8.1   Introduction . . . . . . . . . . . . . . . . . . . 8-1
32         8.2   Generic Error Log Message Format . . . . . . . . . 8-4
33         8.3   Controller Errors  . . . . . . . . . . . . . . . . 8-9
34         8.4   Host Memory Access Errors with Bus Address . . .  8-10
35         8.5   Disk Transfer Errors . . . . . . . . . . . . . .  8-11
36         8.6   SDI Errors . . . . . . . . . . . . . . . . . . .  8-13
37         8.7   Small Disk Errors  . . . . . . . . . . . . . . .  8-15


38       Chapter 9       WAIVERS AND EXCEPTIONS                        

39         9.1   UDA50 -- Unit and Controller Revision Numbers  . . 9-1
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Table of Contents                                          Page 3
                                                                08 Apr 82


 1       Chapter 10      CLARIFICATIONS                                

 2         10.1  Invalid Commands . . . . . . . . . . . . . . . .  10-1


 3       Appendix A      OPCODE, FLAG, AND OFFSET DEFINITIONS          

 4         Table A-1   Control Message Opcodes                         
 5         Table A-2   Command Modifiers                               
 6         Table A-3   End Message Flags                               
 7         Table A-4   Controller Flags                                
 8         Table A-5   Unit Flags                                      
 9         Table A-6   Command Message Offsets                         
10         Table A-7   End and Attention Message Offsets               
11         Table A-8   Error Log Message Offsets                       
12         Table A-9   Error Log Message Format Codes                  
13         Table A-10  Error Log Message Flags                         


14       Appendix B      STATUS AND EVENT CODE DEFINITIONS             

15         Table B-1   Status and Event Codes                          
16         Table B-2   Standard Status and Event Sub-code Values       
17         Table B-3   Non-Standard Status and Event Sub-code Values   


18       Appendix C      CONTROLLER, UNIT, AND MEDIA TYPE IDENTIFERS   

19         Table C-1   Controller and Unit Identifier "Class" Values   
20         Table C-2   Mass Storage Controller "Model" Values          
21         Table C-3   DEC Standard 166 Disk Identifier Values         
22         Table C-4   Tape Identifier Values                          


23       Appendix D      BUFFER DESCRIPTOR FORMATS                     



24       Appendix E      REVISION HISTORY                              
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 1

 2                                INTRODUCTION



 3   |  1.1  Overview of MSCP Subsystem
 4   |  
 5   |  Mass Storage Control Protocol (MSCP) is the protocol  used  by  a
 6   |  family of mass storage controllers and devices designed and built
 7   |  by Digital Equipment Corporation.  In a system that uses an  MSCP
 8   |  storage   subsystem,  the  controller  contains  intelligence  to
 9   |  perform the detailed I/O handling tasks.  This arrangement allows
10   |  the  host  to simply send command messages (requests for reads or
11   |  writes) to the controller and receive response messages back from
12   |  the  controller.   The  host need not concern itself with details
13   |  such as device type,  media  geometry,  media  format,  or  error
14   |  recovery.
15   |  
16   |  The host uses two levels of software  to  accomplish  its  tasks.
17   |  The  higher level is called a "class driver".  The class driver's
18   |  knowledge of devices is limited to  the  device  class  (such  as
19   |  disks)  and  their  capacity.   The class driver does not have to
20   |  know the detailed nature of the communications  link  (I/O  bus),
21   |  controller, or devices that are being used.
22   |  
23   |  The second level of host software is called a "port driver".  The
24   |  port  driver  passes  messages to/from the communications link or
25   |  bus.  It is not aware of the messages' meaning.  The port  driver
26   |  does  have to know the exact nature of the communications link or
27   |  bus (communications mechanism).
28   |  
29   |  In the controller architecture, there  are  also  two  levels  of
30   |  software.   The  lower  of these two is also a "port driver" and,
31   |  like the port driver in the host, is concerned only with  passing
32   |  messages  on  and off of the bus.  The higher level of controller
33   |  software is the "MSCP Server".  It constitutes  the  intelligence
34   |  of  the controller and therefore defines the functionality of the
35   |  controller.
36   |  
37   |  The MSCP server concerns itself with determining  the  number  of
38   |  devices, their type, geometry, unit number, availability, status,
39   |  etc.  The MSCP server receives requests from the host  and  sends
40   |  responses  to  the host.  It optimizes the requests, performs the
41   |  operations, transfers the data to/from the  host,  transfers  the
42   |  data  to/from the device, and buffers the data as necessary.  The
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Introduction                                             Page 1-2
     |  1.1  Overview of MSCP Subsystem                         08 Apr 82


 1   |  MSCP server performs error detection and  recovery,  and  reports
 2   |  any significant errors to the host.
 3   |  
 4   |  Because the MSCP server handles the error detection and  recovery
 5   |  by  itself,  the  host  sees  a  "perfect  media",  an  important
 6   |  characteristic of an MSCP subsystem.  That is, the host need only
 7   |  report errors to higher level (user) software, as the MSCP server
 8   |  performs  all  error  recovery  and  media  defect  (bad   block)
 9   |  handling.
10   |  
11   |  The host's class driver and the controller's  MSCP  server  route
12   |  their  messages  through  the  path of the two port drivers and a
13   |  hardware  interconnect.   This  is  their  physical   connection.
14   |  However,  their  logical  communication  is  a  direct connection
15   |  because the port driver details are below their level of concern.
16   |  Therefore,  there  are  two paths to consider, a physical message
17   |  path and a logical  MSCP  connection.   This  is  illustrated  in
18   |  Figure 1.
19   |  
20   |  
21   |              Host                      Mass Storage Controller
22   |       + - - - - - - - - +                + - - - - - - - - +  
23   |       |                 |                |                 |  
24   |          +-----------+                      +-----------+     
25   |       |  |   Class   |  |      MSCP      |  |   MSCP    |  |  
26   |          |   Driver  | <------------------> |   Server  |     
27   |       |  +-----------+  |                |  +-----------+  |  
28   |                A                                  A           
29   |       |        |        |                |        |        |  
30   |                V                                  V           
31   |       |  +-----------+  | Communications |  +-----------+  |  
32   |          |   Port    | <------------------> |   Port    |     
33   |       |  |   Driver  |  |   Protocols    |  |   Driver  |  |  
34   |          +-----------+                      +-----------+     
35   |       |        A        |                |        A        |  
36   |       + - - - -|- - - - +                + - - - -|- - - - +  
37   |                |                                  |           
38   |                V                                  V           
39   |            +------------------------------------------+       
40   |            |  Port  |                        |  Port  |       
41   |            |  -  -  +                        +  -  -  |       
42   |            |         Communications Mechanism         |       
43   |            |                                          |       
44   |            +------------------------------------------+       
45   |  
46   |                      Figure 1   Example System
47   |  
48   |  
49   |  In summary, an MSCP subsystem is characterized by an  intelligent
50   |  controller that provides the host with the view of perfect media.
51   |  It is further characterized by host independence from a  specific
52   |  bus, controller, or device type.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Introduction                                             Page 1-3
     |  1.2  Purpose                                            08 Apr 82


 1   |  1.2  Purpose
 2   |  
 3   |  The purpose of this manual is to provide information on the rules
 4   |  of  MSCP  to  the  detail necessary for both writing a host class
 5   |  driver and implementing an MSCP server.
 6   |  
 7   |  
 8   |  
 9   |  1.3  Method of Presentation
10   |  
11   |  The method of presentation used in this manual is:
12   |  
13   |        o  to define new terms and concepts.
14   |  
15   |        o  list the responsibilities of the class driver.
16   |  
17   |        o  list the responsibilities of the MSCP  server  that  are
18   |           applicable to the class driver.
19   |  
20   |        o  list the responsibilities of the storage unit  that  are
21   |           applicable to the class driver.
22   |  
23   |        o  explain each command and response message.
24   |  
25   |        o  explain each error message.
26   |  
27   |        o  provide appropriate tables of consolidated information.
28   |  
29   |  
30   |  
31   |  
32   |  1.4  Scope
33   |  
34   |  The scope of this manual is limited to the details  of  the  MSCP
35   |  itself  and  does not provide information on any specific type of
36   |  host processor or any specific operating  system.   It  does  not
37   |  assume any particular bus, controller, device type, host, or port
38   |  driver implementation.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 2

 2                                 TERMINOLOGY



 3   |  
 4   |  Aborted Command
 5   |  
 6   |      From the viewpoint of a class driver, any command  for  which
 7   |      it  has  issued  an  ABORT command.  From the viewpoint of an
 8   |      MSCP server, a command for which it  has  received  an  ABORT
 9   |      command,  located  the  specified command, and taken explicit
10   |      action to abort  it.   An  aborted  command  will  be  either
11   |      rejected or terminated.  See Section 4.5, "Command Categories
12   |      and Execution Order".
13   |  

14      Command Categories

15          All MSCP commands fall into one of four  command  categories:
16          Immediate   commands,   Non-Sequential  commands,  Sequential
17          commands, and Special commands.  Each  command  category  has
18          certain  constraints  on when those commands may be executed,
19          thus limiting the scope  of  controller  optimizations.   See
20          Section 4.5, "Command Categories and Execution Order".

21   |  
22   |  Completed Command
23   |  
24   |      A command that the MSCP server has executed through  to  it's
25   |      normal  completion, which may be either successful completion
26   |      or  an  unrecoverable  error.   See  Section  4.5,   "Command
27   |      Categories and Execution Order".
28   |  

29      Controller Timeout Interval

30          A  time  interval,  measured  in  seconds,  supplied  by  the
31          controller   or   MSCP   server   in   the   SET   CONTROLLER
32          CHARACTERISTICS command's end message.  Controllers  or  MSCP
33          servers  guarantee  that  they  will  complete  all Immediate
34          commands plus some measurable amount of useful work on  their
35          oldest   outstanding   non-Immediate   command   within   the
36          controller timeout  interval.   See  Section  4.10,  "Command
37          Timeouts".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Terminology                                              Page 2-2
                                                                08 Apr 82


 1      Forced Error

 2          A data error (in a disk block)  that  has  been  deliberately
 3          caused by use of the "Force Error" command modifier.  Used to
 4          indicate that the  data  in  the  block  is  of  questionable
 5          validity.   For example, an unrecoverable error occurred when
 6          the data was copied from some other block.


 7      Forced Error Indicator

 8          The logical flag, present in each disk block, used to  record
 9          the presence of a Forced Error.  Depending upon the detailed,
10          low level format of the disk device, this may be  implemented
11          either as an actual bit flag or as a special pattern (such as
12          the complement of  the  normal  value)  of  error  correcting
13          and/or error detecting codes.


14      Immediate Commands

15          Commands  that  MSCP  servers  should  execute   immediately,
16          without   waiting   for   any  other  commands  to  complete.
17          Immediate commands are typically status inquiries,  and  must
18          be completed within the controller timeout interval.


19      Non-Sequential Commands

20          Commands whose execution order MSCP servers may rearrange, in
21          order to optimize performance.  The optimization may not move
22          a non-sequential  command  past  the  barrier  imposed  by  a
23          sequential command.


24      Nugatory

25          Of little or no consequence:  Trifling, Inconsequential.  See
26          Section 6.5, "AVAILABLE Command"

27   |  
28   |  Rejected Command
29   |  
30   |      A command that the MSCP server rejects, discards, aborts,  or
31   |      otherwise  finishes  before  it  begins  to  execute it.  See
32   |      Section 4.5, "Command Categories and Execution Order".
33   |  

34      Sequential Commands

35          Commands that MSCP servers must execute in  the  exact  order
36          that  they  were  received  from  class  drivers.  Sequential
37          commands typically change a unit's state or context.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Terminology                                              Page 2-3
                                                                08 Apr 82


 1      Special Commands

 2          Commands that have both the execution  order  constraints  of
 3          non-sequential   commands   plus   certain  special,  command
 4          dependent execution order constraints.

 5   |  
 6   |  Terminated Command
 7   |  
 8   |      A command that the MSCP server terminates after it  has  been
 9   |      partially executed.  See Section 4.5, "Command Categories and
10   |      Execution Order".
11   |  
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 3

 2                  CLASS DRIVER / MSCP SERVER COMMUNICATIONS



 3      3.1  Connection

 4      Host class drivers use the host port driver to  communicate  with
 5      MSCP  servers  in  controllers.   MSCP  servers similarly use the
 6      controller port driver  to  communicate  with  class  drivers  in
 7      hosts.   This  communication  takes  place across a link called a
 8      connection.

 9      The state of the connection is directly equivalent to  the  state
10      of  the  controller  or  MSCP  server  with  respect to the class
11      driver.  The controller is "Controller-Online" if and only if the
12      connection  is  established  and  functioning.  The controller is
13      "Controller-Available" if the connection is not established,  but
14      it  is  believed that it could be established.  The controller is
15      "Controller-Offline" if the connections is not established and it
16      is believed that it cannot be established.

17      Three types  of  communications  services  are  used  across  the
18      connection between a class driver and an MSCP server:

19            o  A sequential message communications  service,  used  for
20               MSCP   control   messages.    This   service  guarantees
21               sequential, duplicate free  delivery  for  all  messages
22               sent  across  the  same  connection.   This service must
23               support messages of at least 48 bytes in length.

24            o  A datagram communication service, used  for  MSCP  error
25               log  messages.   This service must deliver messages sent
26               on it with  very  high  probability.   Messages  may  be
27               delivered  out of sequence, lost, or duplicated, but the
28               probability of any of these occurring must be very  low.
29               This service must support messages of at least 384 bytes
30               in length.

31            o  A block data communication service, used  to  move  data
32               between   hosts  and  mass  storage  controllers.   This
33               service  provides  a  reliable,  efficient   method   of
34               transferring  the  contents  of  a  named  buffer in one
35               subsystem  to  a  named  buffer  in  another  subsystem.
36               Buffers  are  identified  by  buffer  descriptors, which
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-2
        3.1  Connection                                         08 Apr 82


 1               identify both the buffer and  the  subsystem  (host)  in
 2               which the buffer resides.

 3      The communications mechanism or port drivers discard all messages
 4      that,  at  the time a connection is terminated, have been sent or
 5      queued to  be  sent  via  the  sequential  message  and  datagram
 6      services  but  have not yet been delivered.  Block data transfers
 7      may or may not be terminated when a connection is terminated.  If
 8      terminated,  they  may  have  already  been  partially completed.
 9      Block data transfers from a previous incarnation of a  connection
10      are  guaranteed  to  have  been terminated when the connection is
11      re-established.

12      Besides using these three communications services directly,  MSCP
13      uses  the  establishment  of the connection itself to synchronize
14      class drivers and MSCP servers.  Either the class driver  or  the
15      MSCP  server  will  terminate the connection between them (become
16      "Controller-Available")  if  it   determines   that   they   must
17      re-synchronize with each other.  Events that require class driver
18      / MSCP server re-synchronization include certain errors  or  loss
19      of context by either process.  The connection is also terminated,
20      by a  port  driver,  if  an  unrecoverable  communications  error
21      occurs.  Termination of the connection signals the processes that
22      re-synchronization  is  necessary.   The  re-synchronization   is
23      accomplished  by  each  process  discarding all context regarding
24      outstanding  commands  or  transactions,  after   which   a   new
25      connection is established.

26      Following re-synchronization,  commands  which  were  outstanding
27      before the re-synchronization was performed may have completed to
28      an indeterminate extent.  Such commands may  have  been  rejected
29      (never  started), may have been terminated (partially completed),
30      or may have been fully completed.  The  only  guarantee  is  that
31      they  are  no longer outstanding, implying that the controller is
32      no longer performing work for them and that the class driver will
33      not  receive  an  end  message  for  them.   The  fact  that  the
34      controller is no longer performing work for them implies that  no
35      state changes or modification of data will take place as a result
36      of such commands.



37      3.2  Flow Control

38      Especially critical to MSCP is the concept of  flow  control  and
39      the  flow  control  based requirements that MSCP imposes on class
40      drivers and MSCP servers.  These items are discussed below.

41      Flow control arises from the need to avoid the congestion  and/or
42      deadlock  which  can  occur  if  one  process  sends messages too
43      quickly to another process.   The  receiving  process  must  have
44      buffers  in  which to place the incoming messages.  When all such
45      buffers are full, additional messages cannot be handled.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-3
        3.2  Flow Control                                       08 Apr 82


 1      The datagram communications service does not  use  flow  control.
 2      If   no   buffers  are  available,  incoming  datagrams  will  be
 3      discarded.  Thus the characteristic  that  the  datagram  service
 4      does  not  guarantee  delivery,  instead  only  assuring  a  high
 5      probability of delivery.  This high probability is dependent upon
 6      the  receiver  (i.e.,  the  class  driver)  always having buffers
 7      queued for incoming datagrams.

 8      The sequential  message  communications  service  does  use  flow
 9      control.   When a potential receiving process queues a buffer for
10      receiving messages on a connection, the presence of  this  buffer
11      is  communicated  (via  the underlying communications service) to
12      the potential sending process at the other end of the connection.
13      This  message  notifying  the  potential  sending  process of the
14      queued buffer grants the sending process a credit, which  is  the
15      priviledge  to  send  a message.  Therefore messages will only be
16      sent when the sending process knows that  the  receiving  process
17      has  queued  a  buffer  into  which  the message can be received,
18      ensuring that the receiving process will be able  to  handle  the
19      message.

20      A typical implementation of flow  control  will  be  somewhat  as
21      follows.   The  port driver maintains a counter on behalf of each
22      process participating in a connection.  That  counter  holds  the
23      process's  current  credit balance -- i.e., the number of receive
24      buffers that its partner has queued less the number  of  messages
25      that  it  has  sent.   Every  time the process's partner queues a
26      receive buffer, a message is  sent  causing  the  counter  to  be
27      incremented.  Every time the process sends a message, the counter
28      is decremented.  Messages may  only  be  sent  when  the  counter
29      (credit balance) is greater than zero, thus guaranteeing that the
30      counter will never be negative.  Indeed, we will see  later  that
31      some  messages  require  that  the  counter  be  greater  than  a
32      threshhold larger than zero.

33      Due to the inherent asynchrony of communications between multiple
34      processes  or  subsystems,  revoking  or  canceling  a previously
35      queued receive buffer is not  straightforward.   The  problem  is
36      that  the  buffer cannot be revoked and returned to the receiving
37      process until after the  sending  process  has  acknowledged  its
38      revocation,  as otherwise the sending process may attempt to send
39      a message  that  requires  the  revoked  buffer.   Therefore  the
40      algorithm for revoking receive buffers is as follows:

41           1.  The  revoking  process  (the  process  which  originally
42               queued the receive buffers) requests that some number of
43               buffers be revoked.

44           2.  The revocation request is communicated to  the  revoking
45               process's partner (actually to its port driver).
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-4
        3.2  Flow Control                                       08 Apr 82


 1           3.  The  revoking  process's  partner  (actually  its   port
 2               driver)  compares  the  number  of buffers to be revoked
 3               against its current credit balance and a threshhold.  If
 4               the requested number of buffers / credits can be revoked
 5               (i.e.,  subtracted  from  the  credit  balance)  without
 6               lowering  the  credit balance below the threshhold, then
 7               all of them will be revoked.  Otherwise, if  the  credit
 8               balance  is  above  the  threshhold,  it  is  set to the
 9               threshhold and the difference between its  former  value
10               and  the  threshhold  is the number of buffers / credits
11               actually revoked.  If the credit balance is  already  at
12               or  below  the threshhold, then it stays the same and no
13               buffers / credits are revoked.

14           4.  The actual  number  of  buffers  /  credits  revoked  is
15               communicated back to the revoking process's port driver.

16           5.  The revoking process's port driver returns  the  buffers
17               actually revoked to the revoking process.

18      If a threshhold of  zero  is  used,  the  revoking  or  receiving
19      process can always get back all of its buffers.  The fact that an
20      attempted revocation failed implies that the buffers have already
21      been  returned  to the process, since messages have been received
22      into them.

23      The above algorithm uses a threshhold to prevent revocation below
24      some  lower  limit.   The  mechanism  by which this threshhold is
25      obtained  is  not  critical  to  either  MSCP  or  to  the  above
26      algorithm.  The rules below are phrased as if the threshhold were
27      supplied by the  revoking  process  as  part  of  the  revocation
28      request.   This is purely to simplify the wording of those rules;
29      often  the  threshholds  will  be  constants  determined  when  a
30      connection   is   established.    In  such  an  implementation  a
31      threshhold of zero should  be  used  when  the  class  driver  is
32      revoking  credits  it  has  granted  to  the  MSCP  server  and a
33      threshhold of one should be used when the MSCP server is revoking
34      credits it has granted to the class driver.

35      MSCP is only concerned with credits  required  by  the  sequenced
36      message   service.   Some  communications  services  may  require
37      credits for the block data communication service  as  well.   Any
38      such  credits are invisible to MSCP, being communications service
39      dependent, and must  be  provided  in  addition  to  the  credits
40      required by the rules below.

41      Note that the above  discussion  merely  describes  a  conceptual
42      model   for   flow   control   within   the   sequential  message
43      communications  service.   There  is  no  requirement  that  flow
44      control  actually  be  implemented  this  way,  provided that the
45      results are the same.  For example,  almost  all  implementations
46      will  carry  credit information in a header added to messages and
47      processed by the receiving process's  port  driver,  rather  than
48      communicating  credits  with  separate  messages.  Some extremely
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-5
        3.2  Flow Control                                       08 Apr 82


 1      well behaved communications mechanisms may not need to  implement
 2      explicit flow control at all, since the underlying communications
 3      mechanism may provide it implicitly.



 4      3.3  Class Driver Responsibilities

 5      Given the  above  model  for  flow  control,  we  can  state  the
 6      requirements  MSCP  places  on  class  drivers  and MSCP servers.
 7      Class drivers must obey the following rules:

 8           1.  All MSCP commands fall into one of  several  categories;
 9               for  this  discussion  we  distinguish between Immediate
10               commands   (one   specific   command    category)    and
11               non-Immediate  commands  (the union of all other command
12               categories).  When the class driver's credit balance  is
13               zero, the class driver may not issue any commands.  When
14               it is one, the class driver  may  only  issue  Immediate
15               commands.   When  it  is two or larger, the class driver
16               may issue both Immediate and non-Immediate commands.  If
17               the  class driver's credit balance is one and there is a
18               GET COMMAND STATUS command waiting to be issued for  the
19               command  timeout  algorithm,  then the class driver must
20               issue that  GET  COMMAND  STATUS  command  as  the  next
21               command.

22               In essence, this rule means that the class  driver  must
23               reserve  one credit for the exclusive use of the command
24               timeout algorithm.  This credit may  be  "borrowed"  for
25               issuing  Immediate  commands, since such commands always
26               complete quickly.  The goal is  to  guarantee  that  the
27               command   timeout  algorithm  will  always  be  able  to
28               promptly issue a GET COMMAND STATUS command.

29           2.  The class driver must queue a receive  buffer  for  each
30               command  that  it  sends to an MSCP server.  The receive
31               buffer will be used to hold the command's  end  message.
32               The  receive  buffer  must  be  queued either before the
33               command is sent or as part of  an  atomic  (indivisible)
34               action that includes sending the command.  The important
35               point is that the MSCP server must  receive  the  credit
36               for  the  receive  buffer  either before or concurrently
37               with receiving the command.

38           3.  In  addition  to  queueing  receive  buffers   for   end
39               messages,  class  drivers that enable attention messages
40               must queue at least  one  receive  buffer  in  which  to
41               receive  attention messages.  Such a receive buffer must
42               be queued before  the  class  driver  enables  attention
43               messages  --  i.e.,  before the class driver sends a SET
44               CONTROLLER   CHARACTERISTICS   command   that    enables
45               attention  messages.   Additional receive buffers may be
46   |           queued at any time.  Note that, with  most  controllers,
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-6
        3.3  Class Driver Responsibilities                      08 Apr 82


 1   |           there  is no benefit to queueing more than one attention
 2   |           message receive buffer.

 3           4.  Upon receiving an attention message,  the  class  driver
 4               must  immediately  queue  another  (or the same) receive
 5               buffer back  for  more  attention  messages.   The  only
 6               resource  that  the  class  driver  may  require between
 7               receiving an  attention  message  and  queueing  another
 8               receive  buffer  is  host  CPU cycles.  The class driver
 9               must not require that it be able to send or receive  any
10               other  messages  or  wait for any I/O to complete before
11               queueing  another  receive  buffer.   This   effectively
12               requires  that  all  code  and data structures needed to
13               process attention messages must be permanently  resident
14               in  physical  memory,  so  that  an  incoming  attention
15               message can be immediately processed and the  buffer  in
16               which it was received immediately re-queued.

17           5.  With one exception, the class driver must  never  revoke
18               receive  buffers.   The one exception is after disabling
19               attention messages --  i.e.,  after  receiving  the  end
20               message  for  the SET CONTROLLER CHARACTERISTICS command
21               that disabled attention  messages.   At  that  time  the
22               class driver may revoke as many buffers as it has queued
23               for attention messages (i.e., total  number  of  buffers
24               queued  less  number  of  outstanding  commands).   This
25               revocation should specify a threshhold  of  zero.   Note
26               that  this  revocation  is  guaranteed to succeed if the
27               MSCP server is operating correctly.
28   |  
29   |           Note that the class driver can accomplish the effect  of
30   |           revoking  end  message  receive buffers by aborting MSCP
31   |           commands.  The receive buffers will be returned  to  the
32   |           class driver as soon as the (aborted) commands complete.

33      Failure of a class driver to follow the above rules may  lead  to
34      controller  deadlock,  command  timeouts,  or  the controller not
35      obeying its rules given below.  Any connection or process in  the
36      controller's subsystem may be affected, rather than just the MSCP
37      server with which the class driver is communicating.   Note  that
38      class  drivers  that enable error logging must also keep datagram
39      buffers queued so that they can receive error log messages.   Not
40      keeping  datagram  buffers queued may result in loss of error log
41      messages.



42      3.4  MSCP Server Responsibilities

43      The  rules  for  MSCP  servers  vary   depending   upon   certain
44      characteristics  of  the  server.   There  is  one general set of
45      rules, plus a simplification that certain classes of servers  may
46      follow.   In  all cases, an MSCP server's implementation of these
47      rules may require, for its correct operation (and thus  adherence
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-7
        3.4  MSCP Server Responsibilities                       08 Apr 82


 1      to  these  rules),  that class drivers correctly follow the rules
 2      given for them above.  The general set of rules,  which  must  be
 3      followed  by  all  MSCP servers that aren't in any of the special
 4      cases identified later, are as follows:

 5           1.  So long as it is "Controller-Online" to a class  driver,
 6               an MSCP server must ensure that the sum of the number of
 7               commands that are outstanding  from  that  class  driver
 8               plus the number of unused receive buffers / credits that
 9               it has granted to that class driver is never lower  than
10               the  values given below.  That is, the sum of the actual
11               and potential outstanding commands must be at least  the
12               values  below.   Between  the  time  that the controller
13               becomes "Controller-Online" and the  completion  of  the
14               first  SET  CONTROLLER CHARACTERISTICS command, this sum
15               must be at least one.  Following the completion  of  the
16               first  SET  CONTROLLER  CHARACTERISTICS  command, and so
17               long as the controller remains "Controller-Online", this
18               sum  must  be  at least two.  The first unit of this sum
19               allows the class driver  to  issue  Immediate  commands.
20               Any  excess,  beyond the value one, can be used to issue
21               "real" commands such as data transfers.  Note that these
22               requirements  imply  that,  following  a  SET CONTROLLER
23               CHARACTERISTICS command, the  MSCP  server  must  either
24               grant  a minimum of two receive buffers / credits to the
25               class driver or else terminate  the  connection  (become
26               "Controller-Available") with the class driver.

27           2.  So long as it is "Controller-Online" to a class  driver,
28               an MSCP server must ensure that the sum of the number of
29               immediate commands that are outstanding from that  class
30               driver  plus  the  number  of  unused  receive buffers /
31               credits that it has granted  to  that  class  driver  is
32               always at least one.  That is, the sum of the actual and
33               potential outstanding  Immediate  commands  must  be  at
34               least one.  This is in addition to requirement 1 above.

35           3.  An MSCP server may revoke receive buffers or credits  at
36               any  time so long as it continues to meet requirements 1
37               and 2 above.  Note that, in order to meet requirement 2,
38               the  sum  of  the threshhold used for the revoke request
39               plus the number of outstanding Immediate commands  (from
40               that   class   driver)  must  be  at  least  one.   This
41               restriction will typically be  met  by  always  using  a
42               threshhold of one.
43   |  
44   |       4.  Notwithstanding all  that  has  been  said  above,  MSCP
45   |           servers  must  allow  hosts to perform transfers without
46   |           the   host   having   to   issue   a   SET    CONTROLLER
47   |           CHARACTERISTICS  command.  This is necessary to simplify
48   |           the implementation of host bootstraps.  The commands  to
49   |           perform  such  transfers  must  be  issued one at a time
50   |           (rule 1 above ensures that the host has at least the one
51   |           credit  it  needs  to  issue  these commands).  The MSCP
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-8
        3.4  MSCP Server Responsibilities                       08 Apr 82


 1   |           server must either grant  the  host  a  minimum  of  two
 2   |           credits  when  it  becomes  "Controller-Online"  or else
 3   |           perform commands regardless of the fact that the host is
 4   |           nominally  violating  the  requirements described in the
 5   |           preceeding section.  The specific  requirement  violated
 6   |           is that the host will be issueing non-Immediate commands
 7   |           in spite of its credit balance being only one.

 8           5.  An MSCP server must keep track of the excess, if any, of
 9               its  credit  balance  over  the  number  of  outstanding
10               commands.  The server may only issue attention  messages
11               when  this  excess  is  greater  than  zero.   Attention
12               messages that cannot be  issued  immediately  should  be
13               saved  until  credits  are available with which to issue
14               them.   The  controller  must  continue  to  accept  new
15               commands,  process  outstanding  commands, and issue end
16               messages for completed commands while attention messages
17               are  being  saved.  If the conditions that triggered the
18               generation of an attention message disappear before that
19               attention   message  can  be  issued  (sent),  then  the
20               attention message may or may not still have to be  sent.
21               See the individual attention message descriptions.

22   |  With many communications  mechanisms  there  is  an  inherent  or
23   |  unavoidable  race  that MSCP servers must be prepared to resolve.
24   |  It can occur whenever the credit for an end message might be sent
25   |  as  a  distinct message, rather than always being embedded in the
26   |  communications mechanism header  for  the  corresponding  command
27   |  message.
28   |  
29   |  Suppose the host class driver grants  one  credit  for  attention
30   |  messages,  and  that  some  combination of events causes the MSCP
31   |  server to want to send two  attention  messages.   The  attention
32   |  message  credit  is  used to send the first attention message and
33   |  the second is queued  for  later  transmission.   Meanwhile,  the
34   |  class  driver  sends  a  command  and  its associated end message
35   |  credit to the MSCP server as  two  distinct  messages.   Per  the
36   |  class   requirements  described  in  the  previous  section,  the
37   |  notification of the end message credit must be sent first.   When
38   |  this  notification  arrives  at  the  controller, the MSCP server
39   |  thinks it is the attention message credit being  returned  (since
40   |  credits  are  anonymous)  and sends the second attention message.
41   |  Immediately thereafter the command arrives and  the  MSCP  server
42   |  discovers  an apparent rule violation by the class driver, namely
43   |  that it appears to have sent a command  without  an  accompanying
44   |  credit for the end message.
45   |  
46   |  This credit imbalance problem will ultimately  be  resolved  when
47   |  the  class  driver  returns the attention message credit.  As the
48   |  class driver is not allowed to perform any I/O  before  returning
49   |  attention message credits, we are assured that the credit will be
50   |  returned both promptly and without any possibility  of  deadlock.
51   |  Therefore,  whenever  this  race occurs, the MSCP server may hang
52   |  until the attention message credit is returned.  Although  it  is
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications                Page 3-9
        3.4  MSCP Server Responsibilities                       08 Apr 82


 1   |  permissable  for  all  MSCP  servers  for  all device classes and
 2   |  connections to hang, it is highly  desireable  if  only  the  one
 3   |  connection is affected.
 4   |  
 5   |  Typically the command(s) that  is(are)  lacking  an  end  message
 6   |  credit  would be held in a queue, with no work done on them until
 7   |  their end message credits arrive.  Note that if the host did  not
 8   |  return  attention  message credits promptly, this would result in
 9   |  command timeouts.  The  MSCP  server  must  service  the  waiting
10   |  commands  in  their  order  of  arrival.  Thus if another command
11   |  arrives with a credit embedded in  its  communications  mechanism
12   |  header,  the  MSCP server must transfer that credit to the oldest
13   |  command waiting for an end  message  credit  and  place  the  new
14   |  command on the waiting queue.

15      MSCP servers that limit the rate at which they generate attention
16      messages  can  replace  rule  5  above with a simpler rule.  This
17      alternate rule may be used, at the server's option, by  any  MSCP
18      server  that  will  generate  no  more  than  an  average  of two
19      attention messages  per  second,  averaged  over  the  controller
20      timeout  interval  (see  Section 4.10, "Command Timeouts").  That
21      is, if the controller timeout interval is  N  seconds,  then  the
22      server  will  generate no more than N*2 attention messages within
23      any N second period.  The MSCP server may assume, in  determining
24      its  maximum  attention message rate, that human operators do not
25      engage in pathological activity.  I.e., it may assume that  cases
26      such  as an operator continuously actuating the Run/Stop switches
27      on one or more drives will never occur.  Any MSCP server that can
28      meet  this  attention message rate restriction can substitute the
29      following alternate rule for rule 5 above:

30           5'. An MSCP server may  issue  attention  messages  and  end
31               messages  whenever  its  credit  balance is greater than
32               zero.  Attention messages and end messages  that  cannot
33               be  issued immediately should be saved until credits are
34               available with which to issue them.  If  the  conditions
35               that  triggered  the  generation of an attention message
36               disappear before the attention  message  can  be  issued
37               (sent), then that attention message may or may not still
38               have to be sent.  See the individual  attention  message
39               descriptions.   Saved  end messages must always be sent,
40               unless     the     MSCP     server     first     becomes
41               "Controller-Available" (i.e., terminates its connections
42               with the class driver), in  which  case  the  saved  end
43               messages  must not be sent.  Note that end messages must
44               always be sent in the  order  that  their  corresponding
45               commands completed.

46               An MSCP server may deadlock  or  cease  operating  on  a
47               connection  whenever  it has saved attention messages or
48               end messages waiting to be issued  on  that  connection.
49               The  only  operations  that  it must perform when it has
50               such messages  waiting  is  to  accept  incoming  credit
51               notifications,  send  the  waiting messages when credits
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Class Driver / MSCP Server Communications               Page 3-10
        3.4  MSCP Server Responsibilities                       08 Apr 82


 1               become available, and resume normal operation  when  all
 2               waiting  messages  have  been sent.  Note that accepting
 3               incoming credit notifications will  often  require  that
 4               the  MSCP  server  also accept new commands, although it
 5               need not begin processing of those  new  commands  until
 6               all  waiting  messages  have  been sent.  Note also that
 7               only  the  one  MSCP  server  may  deadlock   or   cease
 8               operating;   other  processes (i.e., other MSCP servers)
 9               in  the  same  subsystem   or   controller   and   other
10               connections   to  the  same  MSCP  server  must  not  be
11               affected.
12   |  The effect of this modified rule is  to  allow  MSCP  servers  to
13   |  "borrow" end message credits for the purpose of sending attention
14   |  message credits.
15   |  
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  
     |  
 1   |  
 2   |  
 3   |  
 4   |  
 5   |  
 6   |  
 7   |  
 8   |  
 9   |  
10   |  
11   |                              CHAPTER 4
12   |  
13   |                     ALGORITHMS AND USAGE RULES
14   |  
15   |  
16   |  
17   |  4.1  Controller States
18   |  
19   |  The controller may be in any of three states relative to  a  host
20   |  class  driver.   The  controller  may  be  in  a  different state
21   |  relative to each host  or  each  class  driver.   The  controller
22   |  states are:
23   |  
24   |  Controller-Offline
25   |  
26   |      A  controller  is  "Controller-Offline"  to  a  class  driver
27   |      whenever  it is not available to that class driver and cannot
28   |      perform  any  operations  on  its  behalf.   Possible  causes
29   |      include  inoperative  hardware  or  an operator disabling the
30   |      controller.  A  controller  is  "Controller-Offline"  exactly
31   |      when it is not possible to establish a connection between the
32   |      class driver and the MSCP server within the controller.  Note
33   |      that  a  controller  may be "Controller-Offline" to some of a
34   |      host's  class  drivers  yet  be   "Controller-Available"   or
35   |      "Controller-Online" to others.
36   |  
37   |  Controller-Available
38   |  
39   |      A controller is  "Controller-Available"  to  a  class  driver
40   |      whenever  it  could perform operations for that class driver,
41   |      but the driver has not yet synchronized with the  controller.
42   |      A  controller is "Controller-Available" exactly when it would
43   |      be possible to  establish  a  connection  between  the  class
44   |      driver  and  the  MSCP  server  within the controller, but no
45   |      connection has yet been established.
46   |  
47   |  Controller-Online
48   |  
49   |      A  controller  is  "Controller-Online"  to  a  class   driver
50   |      whenever it can both perform operations for that class driver
51   |      and the driver  has  synchronized  with  the  controller.   A
52   |      controller  is  "Controller-Online" exactly when a connection
53   |      exists between the class driver and the  MSCP  server  within
54   |      the controller.  This is the state used for normal operation.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-2
     |  4.1  Controller States                                  08 Apr 82


 1   |  Strictly speaking, the term "controller  state"  is  a  misnomer.
 2   |  The  states  described above actually exist between an individual
 3   |  class driver and an individual MSCP  server.   A  host  may  have
 4   |  several class drivers and a controller subsystem may have several
 5   |  MSCP servers.  Note also that the controller state  (MSCP  server
 6   |  state?)  is distinct from the state of any units connected to the
 7   |  controller.
 8   |  
 9   |  An MSCP server (controller) enters the "Controller-Offline" state
10   |  relative to a host whenever the MSCP server ceases to function or
11   |  otherwise becomes unable to  perform  operations  for  the  host.
12   |  Possible causes include:
13   |  
14   |       1.  Controller hardware, software, or power failure.
15   |  
16   |       2.  Controller   initialization,   either    requested    or
17   |           spontaneous.
18   |  
19   |       3.  An operator (typically Field Service)  disables  all  or
20   |           part of the controller.
21   |  
22   |       4.  Communications mechanism failures.
23   |  
24   |       5.  The controller has not been built yet, the controller is
25   |           still in its shipping crate, or it has otherwise not yet
26   |           been installed.
27   |  
28   |  
29   |  An MSCP server enters the "Controller-Available"  state  relative
30   |  to a host class driver when:
31   |  
32   |       1.  The controller or MSCP server  is  "Controller-Offline",
33   |           and  all  causes  of  it  being "Controller-Offline" are
34   |           removed.
35   |  
36   |       2.  The MSCP server is  "Controller-Online",  and  the  MSCP
37   |           server cannot successfully send a control message (i.e.,
38   |           an MSCP end or attention  message)  to  the  host  class
39   |           driver.
40   |  
41   |       3.  The MSCP server is  "Controller-Online",  and  the  host
42   |           access  timeout  expires.  See Section 4.9, "Host Access
43   |           Timeouts".
44   |  
45   |       4.  The MSCP server is  "Controller-Online",  and  the  MSCP
46   |           server  receives an invalid command from the host.  Note
47   |           that  this  transition  to   "Controller-Available"   is
48   |           optional, and therefore controller dependent.
49   |  
50   |       5.  The host class driver terminates the connection  between
51   |           the class driver and the MSCP server.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-3
     |  4.1  Controller States                                  08 Apr 82


 1   |       6.  A port driver or the communications mechanism terminates
 2   |           the  connection  between  the  class driver and the MSCP
 3   |           server, generally due to a communications error.
 4   |  
 5   |  The port driver should inform the class driver whenever the  MSCP
 6   |  server  enters  the  "Controller-Available"  state.  How the port
 7   |  driver  obtains  this  information  is  communications  mechanism
 8   |  dependent.   Note  that  the notification that the controller has
 9   |  become "Controller-Available"  is  not  necessarily  prompt.   In
10   |  particular,  with some communications mechanisms the notification
11   |  may not occur until the next  time  the  class  driver  issues  a
12   |  command to the controller.  Furthermore, the port driver need not
13   |  notify the class driver at all if a compound (multiple) error  is
14   |  associated  with the MSCP server becoming "Controller-Available".
15   |  In such a case the class driver will ultimately become  aware  of
16   |  the  state  change  when its Command Timeout expires (see Section
17   |  4.10, "Command Timeouts").
18   |  
19   |  Since  no  connection  exists  to  an   MSCP   server   that   is
20   |  "Controller-Offline"      or      "Controller-Available",     the
21   |  communications  mechanism  will  either  reject  or  discard  any
22   |  messages  (commands)  that a class driver attempts to send to it.
23   |  An   MSCP   server   that   becomes    "Controller-Offline"    or
24   |  "Controller-Available"  may either terminate commands in progress
25   |  or else continue processing the  commands  that  it  has  already
26   |  received.    However,  if  a  Sequential  command  from  a  given
27   |  connection is  terminated  or  rejected,  then  all  subsequently
28   |  received  non-Immediate  commands  from  the same connection must
29   |  also be rejected (i.e., must never begin processing).
30   |  
31   |  Typically, the MSCP server will continue  processing  outstanding
32   |  commands  until  it  "notices"  that  the connection to the class
33   |  driver has been terminated, at which point it will terminate  any
34   |  commands  still  outstanding and reject any commands that haven't
35   |  begun processing yet.  Note that the MSCP server  must  guarantee
36   |  that  all  outstanding  commands  have  been  completed, aborted,
37   |  rejected, or terminated (i.e.,  that  there  are  no  outstanding
38   |  commands)    before    it    completes    a    transition    from
39   |  "Controller-Available" to "Controller-Online".
40   |  
41   |  The MSCP server enters the "Controller-Online" state relative  to
42   |  a  host  class  driver  upon  successful synchronization with the
43   |  class driver.  The class driver synchronizes with the MSCP server
44   |  by establishing a connection with the MSCP server.  Note that the
45   |  MSCP server must guarantee that there are no outstanding commands
46   |  "leftover"  from  a previous incarnation of the connection before
47   |  it allows the new incarnation of the connection to be established
48   |  and enters the "Controller-Online" state.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-4
     |  4.2  Controls and Indicators                            08 Apr 82


 1   |  4.2  Controls and Indicators
 2   |  
 3   |  All storage units used with MSCP must have the following controls
 4   |  and indicators:
 5   |  
 6   |        o  Unit number select mechanism.
 7   |  
 8   |        o  Unit number display mechanism.
 9   |  
10   |        o  Run/Stop switch (on disk units) or a Load/Unload  switch
11   |           (on tape units).
12   |  
13   |        o  Write Protect switch or mechanism.
14   |  
15   |        o  Write Protect Status indicator.
16   |  
17   |  
18   |  The unit number select mechanism on an MSCP storage unit must  be
19   |  capable  of specifying any unit number in the range 0 through 251
20   |  inclusive.  Larger unit number ranges are acceptable, so long  as
21   |  they  include  the  range  0 through 251.  The unit number select
22   |  mechanism  must  operate  without  host  intervention  and   must
23   |  preserve  unit  numbers across power failures and other losses of
24   |  context.
25   |  
26   |  Alteration of the unit number must  be  possible  in  the  field.
27   |  That is, the unit number must be alterable by Field Service, both
28   |  when a device is first installed and subsequently when  a  system
29   |  is  reconfigured.   The  preferred  unit  select  mechanism  is a
30   |  removable unit number  plug,  allowing  the  unit  number  to  be
31   |  altered  by  users  as well as by Field Service.  Alternatives to
32   |  unit number plugs, however, are acceptable so long as they can be
33   |  altered  by Field Service and they provide the full 0 through 251
34   |  unit number range.
35   |  
36   |  A single unit number select mechanism may be shared by the  units
37   |  of a multi-unit drive or formatter (see Section 4.15, "Multi-Unit
38   |  Drives and Formatters").  Units that share a unit  number  select
39   |  mechanism  always  have consecutive unit numbers.  If exactly two
40   |  units share a unit number select mechanism, it is acceptable  for
41   |  the  first  unit  to always have an even unit number and the last
42   |  unit to always have an odd unit number.  If exactly N units share
43   |  a  unit  number  select mechanism, it is acceptable for the first
44   |  unit's unit number to always be a multiple of N, the next  unit's
45   |  unit number to always be a multiple of N plus 1, etc.
46   |  
47   |  The unit number display mechanism on an MSCP  storage  unit  must
48   |  display  the  unit  number(s) specified by the unit number select
49   |  mechanism.  The display must  be  visible  to  normal  (non-field
50   |  service) human operators.  If the unit number select mechanism is
51   |  a removable unit plug, then the unit number display mechanism  is
52   |  merely  a  number  printed on the plug.  If several units share a
53   |  unit number select mechanism, then they may  also  share  a  unit
54   |  number display mechanism.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-5
     |  4.2  Controls and Indicators                            08 Apr 82


 1   |  The Run/Stop switch or Load/Unload switch must  be  alterable  by
 2   |  normal  (non-field  service) human operators to allow or disallow
 3   |  host access to the unit(s).  When in the Run  or  Load  position,
 4   |  this  switch indicates that hosts should be allowed to access the
 5   |  unit(s).  When in  the  Stop  or  Unload  position,  this  switch
 6   |  indicates that hosts should not be allowed to access the unit(s).
 7   |  If the unit(s) have removable media, the  switch  also  indicates
 8   |  that human operators should be allowed to remove the units' media
 9   |  (i.e., that the unit should be  spun-down).   A  single  Run/Stop
10   |  switch  may  be  shared  by  any units of a multi-unit drive that
11   |  share a  spindle  (i.e.,  that  must  be  spun-up  and  spun-down
12   |  together).
13   |  
14   |  The write protect switch or mechanism must either be an  operator
15   |  accessible  switch or else some kind of mechanical deformation of
16   |  the media, such as a tape write-ring or the write-lockout tab  on
17   |  a  cassette.   In  either  case,  it  must be alterable by normal
18   |  (non-field service) human operators.  A  separate  write  protect
19   |  switch  or  mechanism  must  be  provided  for  each  unit  of  a
20   |  multi-unit drive.  When actuated, the  write  protect  switch  or
21   |  mechanism  prevents  write  access  to  the  unit  by  hosts  and
22   |  controllers.   In  the  case  of  a  write  protect  switch,  the
23   |  transition  to  the write protected state must be "smooth" rather
24   |  than immediate.  See Section 4.13, "Write Protection".
25   |  
26   |  The write protect status display mechanism must display the write
27   |  protect  status  of  the  unit.   A separate write protect status
28   |  display mechanism must be provided for each unit of a  multi-unit
29   |  drive.   The  write  protect  status display must be user visible
30   |  while a volume is mounted in the unit.  That is,  the  user  must
31   |  not  be  required to remove the volume from the unit to determine
32   |  whether or not it is write protected.
33   |  
34   |  The preferred write protect status display mechanism is a  light,
35   |  located  within the write protect switch, that is on whenever the
36   |  unit is write protected.  The light must be lit regardless of the
37   |  reason for the unit being write protected -- i.e., it must be lit
38   |  when the unit is Software or Volume Write Protected  as  well  as
39   |  when  the  unit  is  Hardware  Write  Protected  due to its write
40   |  protect mechanism being  activated.   See  Section  4.13,  "Write
41   |  Protection".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-6
     |  4.3  Unit States                                        08 Apr 82


 1   |  4.3  Unit States
 2   |  
 3   |  Each unit may be in one of three states relative  to  each  class
 4   |  driver that is "Controller-Online" to an MSCP server.  (Actually,
 5   |  it is really each unit number that these states apply to,  rather
 6   |  than  to  a  unit proper).  Each unit may be in a different state
 7   |  relative to each  "Controller-Online"  class  driver.   The  unit
 8   |  states are:
 9   |  
10   |  Unit-Offline
11   |  
12   |      A unit is "Unit-Offline" whenever it  is  unable  to  satisfy
13   |      normal  host  requests.   Except  for  status  queries,  MSCP
14   |      commands addressed to a unit that is "Unit-Offline"  will  be
15   |      rejected.   Furthermore,  many device characteristics may not
16   |      be available to status queries.

17      Unit-Available

18          A unit is "Unit-Available"  whenever  it  would  be  able  to
19          satisfy  normal  host  requests, except that the host has not
20          yet issued an ONLINE command to bring the unit "Unit-Online".

21      Unit-Online

22          A unit is "Unit-Online" whenever it is able to satisfy normal
23          host  requests  and  the host has issued a successfull ONLINE
24          command.

25      A unit's state is meaningless with respect to a class driver that
26      is  not  "Controller-Online"  to the MSCP server or when no class
27      driver is "Controller-Online" to the MSCP server.

28      The "Unit-Offline" state has six sub-states, related to the exact
29      reason for the unit being "Unit-Offline".  These substates are:

30           1.  Unit inoperative.  Some fatal  error  condition  in  the
31               drive  prevents  the unit from becoming "Unit-Available"
32               or "Unit-Online".

33           2.  Unit  disabled.   Field  Service  or  a  diagnostic  has
34               decided  that  continued  operation  of the unit's drive
35               will lead  to  progressive  deterioration  and  eventual
36               destruction  of some portion of the drive or media.  The
37               unit  has  been  disabled  to  prevent  its   use,   and
38               consequent  destruction,  until Field Service can repair
39               the   problem.    This   cause   of   the   unit   being
40               "Unit-Offline"  can  be overridden, and the unit brought
41               "Unit-Online", by use of the  "Allow  Self  Destruction"
42               modifier  to the ONLINE command.  Note that some devices
43               may have no way of detecting progressive  deterioration,
44               and consequently will never enter this sub-state.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-7
     |  4.3  Unit States                                        08 Apr 82


 1           3.  Unit known.  The controller  knows  that  the  specified
 2               unit  (i.e.,  a  unit  with  the  specified unit number)
 3               exists, but the unit is "Unit-Offline" for  some  normal
 4               (non-error) condition.  Typical causes of this sub-state
 5               include the unit's Run/Stop or Load/Unload switch  being
 6               in  the  Stop  or  Unload  position  or  no volume being
 7               mounted in the unit.

 8           4.  Online to another controller.  The specified unit exists
 9               and  would  be  "Unit-Available", except that it or some
10               other unit with which it shares an  access  path  (i.e.,
11               some   other  unit  on  the  same  multi-unit  drive  or
12               formatter) is "Unit-Online" to one  or  more  hosts  via
13               another    controller.     The    unit    will    become
14               "Unit-Available" via this controller if it and all units
15               with   which  it  shares  an  access  path  cease  being
16               "Unit-Online" to any hosts via  that  other  controller.
17               In terms of the "Unit-Offline" sub-state that is visible
18               to and reported by a controller, a unit that is actually
19               online  to  another  controller will typically oscillate
20               between the "Online to another controller" sub-state and
21               the  "Unit  unknown"  sub-state.   The  frequency of the
22               oscillation is determined  by  the  frequency  at  which
23               hosts issue DETERMINE ACCESS PATHS commands to the other
24               controller for this unit  or  any  unit  with  which  it
25               shares  an access path.  See Section 4.18, "Multi-Access
26               Drives".

27           5.  Duplicate unit numbers.  That is, two or  more  distinct
28               units  have  the  same  unit  number  assigned  to them.
29               Controllers must check for duplicate unit numbers across
30               all   units   of   the   same   device  class  that  are
31               "Unit-Online",  that  are  "Unit-Available",  that   are
32               "Unit-Offline"  solely due to being disabled or known or
33               having a duplicate unit number, or that  the  controller
34               knows  to be online to another controller.  A controller
35               may or may not, at its option, include inoperative units
36               when  checking  for duplicate unit numbers.  Controllers
37               must not check units  that  are  unknown  (as  described
38               below)  nor  may  they  check for duplicate unit numbers
39               across different device classes.  Note that a  duplicate
40               unit  number  does  not  affect  a  unit that is already
41               "Unit-Online".

42           6.  Unit unknown.  As far as the controller  can  determine,
43               no unit exists with the specified unit number.


44      It is possible for  a  unit  to  be  "Unit-Offline"  for  several
45      reasons at the same time (unless the unit is unknown).  If a unit
46      has a duplicate unit number and  is  not  inoperative,  then  the
47      controller  must  report the duplicate unit number;  other causes
48      of the unit being "Unit-Offline" may  also  be  reported  at  the
49      controller's  option.   In  all  other  cases the controller must
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-8
     |  4.3  Unit States                                        08 Apr 82


 1      report at least one cause of the unit being  "Unit-Offline",  but
 2      which  one it reports and whether or not it reports more than one
 3      is optional with the controller.

 4      The fact that a unit is inoperative may not be detectable until a
 5      host  attempts  to bring the unit "Unit-Online".  Such units will
 6      be treated as and appear to  be  "Unit-Available"  until  a  host
 7      issues   an  ONLINE  command.   The  ONLINE  command  will  fail,
 8      typically with a "Drive Error" status code.  At this time  either
 9      the  fact  that  the  unit is inoperative must be recorded in the
10      unit  itself  or  else  AVAILABLE  attention  messages  must   be
11      suppressed  for the unit, exactly as if an AVAILABLE command with
12      the "Spin-down" modifier set had been issued for  the  unit.   In
13      either  case,  AVAILABLE attention messages must not be generated
14      for that unit by any controller until a human interacts with  the
15      unit or some other event occurs that may clear the error, such as
16      a power failure.

17      Controllers  and/or  drives  should  keep  all  units  that   are
18      "Unit-Offline"  due  to  being  inoperative,  disabled, or having
19      duplicate unit numbers spun-down,  except  when  such  units  are
20      under  the  control  of a diagnostic.  The handling of units that
21      are in fact  inoperative,  but  that  the  controller  and  drive
22      believe to be operative, is described in the preceding paragraph.

23      For the purpose of automatic configuration  (i.e.,  for  the  GET
24      UNIT  STATUS  command  with the "Next Unit" modifier) controllers
25      must  acknowledge  the  existence   of   all   units   that   are
26      "Unit-Online"  or  "Unit-Available",  or  that are "Unit-Offline"
27      solely due to being disabled or known or  having  duplicate  unit
28      numbers.  Unknown units must not be acknowledged.  Units that are
29      inoperative or online to another controller may  or  may  not  be
30      acknowledged at the controller's option.

31      Controllers must report duplicate unit numbers with  a  DUPLICATE
32      UNIT  NUMBER  attention  message, then moniter the affected units
33      for the cessation of the duplicate unit number  condition.   When
34      all  units  except one have had their unit number changed or have
35      become unknown, the remaining unit becomes "Unit-Available".

36      Controllers must report units that they  know  to  be  online  to
37      other controllers with an ACCESS PATH attention message.  Section
38      4.18, "Multi-Access Drives", describes the detailed circumstances
39      in which this attention message must be sent.

40      The "Unit-Offline" sub-states are  all  reported  with  a  single
41      status  code;   they  are  partially  distinguished via different
42      sub-codes.  In addition, the sub-states are distinguished by  the
43      functioning  of  the  "Allow  Self  Destruction"  modifier to the
44      ONLINE command, the "Next Unit" modifier to the GET  UNIT  STATUS
45      command,  what  unit characteristics are returned by the GET UNIT
46      STATUS, ONLINE, and SET UNIT CHARACTERISTICS commands, and by the
47      DUPLICATE UNIT NUMBER and ACCESS PATH attention messages.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                               Page 4-9
     |  4.3  Unit States                                        08 Apr 82


 1      Possible causes of a unit being "Unit-Offline", and the resulting
 2      "Unit-Offline" sub-state, include:

 3           1.  The unit is "Unit-Online" via another  controller.   The
 4               unit  is  either  unknown  or else known to be online to
 5               another controller,  depending  upon  how  recently  the
 6               other  controller has processed a DETERMINE ACCESS PATHS
 7               command for this unit or a unit with which it shares  an
 8               access path.  See Section 4.18, "Multi-Access Drives".

 9           2.  A power failure  that  affects  the  unit  but  not  the
10               controller.  The unit is unknown.

11           3.  Hardware failure  in  the  unit  or  in  the  connection
12               between the unit and the controller.  The unit is either
13               unknown or inoperative.  Note that the unit  may  appear
14               to be "Unit-Available" until an ONLINE command is issued
15               for  it,  at  which  time  it  will  be  recognized   as
16               inoperative.

17           4.  Disconnecting the unit from the controller.  The unit is
18               unknown.

19           5.  Disabling  the  unit  number  select  mechanism   (i.e.,
20               removing  the  unit  number  select  plug).  The unit is
21               unknown.

22           6.  Duplicate unit numbers.  Note that this  condition  will
23               not  affect  a unit that is already "Unit-Online".  This
24               condition has its own sub-state.

25           7.  Duplicate unit identifiers.  The  unit  is  inoperative.
26               Note  that  the  controller need not check for duplicate
27               unit identifiers.

28           8.  Disabling the unit  with  the  Run/Stop  or  Load/Unload
29               switch.  The unit is known.

30           9.  Disabling the unit with port  selection  switches.   The
31               unit is unknown.

32          10.  Removal of the unit from service  by  operator  command,
33               typically  for  diagnostics,  formatting, maintenance or
34               repair.  The unit is inoperative.

35          11.  An internal controller diagnostic decides the  the  unit
36               is  sick  and  removes  it  from  service.   The unit is
37               disabled.

38          12.  No volume is present in the drive.  The unit is known.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-10
     |  4.3  Unit States                                        08 Apr 82


 1          13.  The unit has not been built yet, the unit  is  still  in
 2               its  shipping  crate,  or  it  has  otherwise  not  been
 3               installed yet.  The unit is unknown.

 4      In general, a unit that  is  "Unit-Offline"  to  one  host  class
 5      driver  via a specific MSCP server is "Unit-Offline" for the same
 6      reason (same sub-state) to all host class drivers via  that  same
 7      MSCP  server.   The  only  exception  is  a duplicate unit number
 8      condition that arises while a unit is  "Unit-Online"  to  one  or
 9      more  class  drivers.   The  unit  remains "Unit-Online" to those
10      class drivers to  which  it  is  already  "Unit-Online",  yet  is
11      "Unit-Offline" to all other class drivers.

12      All normal operator initiated transitions to  the  "Unit-Offline"
13      state  must be smooth, rather than abrupt.  Attempts to disable a
14      unit with its Run/Stop or Load/Unload switch and/or  attempts  to
15      dismount  (remove)  a  volume  from  a  unit  are, by definition,
16      "normal operator initiated transitions", and  must  therefore  be
17      smooth.   Any  other action that a human operator would typically
18      use to disable a drive in a non-emergency situation must also  be
19      smooth.   Note  that this does not preclude the existence of some
20      special mechanism for immediately disabling a unit or drive in an
21      emergency,  provided that it is not the normal way of disabling a
22      unit or drive.

23      A "smooth" transition to the "Unit-Offline"  state  implies  that
24      all  write  operations,  including  multi-block write operations,
25      must either be completed  in  their  entirety  or  else  rejected
26      (never  begun).  To accomplish a smooth transition the controller
27      must complete all write operations (commands) that  have  already
28      been  initiated.   Outstanding write operations that haven't been
29      initiated  yet  may  either  be  completed  or  rejected.   Other
30      outstanding   commands,   including   read   operations,  may  be
31      completed, rejected, or terminated, regardless of whether or  not
32      they  have been initiated.  However, if a Sequential command from
33      a  given  connection  is  rejected  or   terminated,   then   all
34      subsequently   received  non-Immediate  commands  from  the  same
35      connection must be rejected.  Any new commands issued by  a  host
36      should be rejected.

37      Note that establishing write protection must  also  be  a  smooth
38      transition.

39      A unit enters the "Unit-Available" state when:

40           1.  The unit is "Unit-Offline" and all causes  of  the  unit
41               being  "Unit-Offline"  are  removed.   The  unit becomes
42               "Unit-Available" with respect to all "Controller-Online"
43               class drivers.

44           2.  The unit is "Unit-Online" and a host class driver issues
45               an  AVAILABLE  command  for  the unit.  The unit becomes
46               "Unit-Available" with respect to that class driver.   If
47               the  "All Class Drivers" modifier was set, the unit also
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-11
     |  4.3  Unit States                                        08 Apr 82


 1               becomes "Unit-Available" with respect to all other class
 2               drivers  to  which  it  is  "Unit-Online"  via that MSCP
 3               server.


 4      If a class driver has enabled attention messages, the MSCP server
 5      uses AVAILABLE attention messages to notify the class driver that
 6      a unit has asynchronously become "Unit-Available".   If  a  class
 7      driver  itself  sends  the MSCP server an AVAILABLE command, then
 8      the transition to "Unit-Available" is synchronous to  that  class
 9      driver and an AVAILABLE attention message need not be sent to it.
10      Other class drivers, however, are notified.

11      The  possible   causes   of   an   asynchronous   transition   to
12      "Unit-Available" are as follows:

13           1.  Any transition from "Unit-Offline" to  "Unit-Available".
14               This  specifically  includes  the case in which the unit
15               was online to another controller and ceases to be online
16               to   that   other  controller,  even  if  the  unit  was
17               "Unit-Online" to the same class driver  via  that  other
18               controller.

19           2.  A transition  from  "Unit-Online"  to  "Unit-Available",
20               with  respect  to  this  class driver, that is caused by
21               some other class driver  issuing  an  AVAILABLE  command
22               with the "All Class Drivers" modifier set.

23           3.  Any  spontaneous  transition   from   "Unit-Online"   to
24               "Unit-Available".     I.e.,    any    transition    from
25               "Unit-Online" to "Unit-Available" that is not caused  by
26               an AVAILABLE command.

27      The one  exception  to  this  applies  to  a  unit  that  becomes
28      "Unit-Available"  due  to  an  AVAILABLE  command  that  has  the
29      "Spin-down" modifier set or as a side effect  of  certain  errors
30      which  also spin-down the unit.  Such commands or errors indicate
31      that all class drivers are disinterested in the volume mounted on
32      the  unit,  so  that  no  class  driver should be notified of the
33      transition until an operator mounts a  new  volume  or  otherwise
34      interacts  with the unit.  Therefore the request to spin-down the
35      unit suppresses AVAILABLE attention messages for that unit  until
36      an operator interacts with the unit.  Note that the messages must
37      be  suppressed  for  all  class  drivers,   MSCP   servers,   and
38      controllers  that  may  connect  to the unit, regardless of which
39      individual MSCP server and controller actually requested that the
40      unit  spin-down.   This  effectively means that, for multi-access
41      drives, the fact that AVAILABLE attention messages are suppressed
42      must  be  recorded  in  the  drive  itself,  rather  than  in the
43      controller.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-12
     |  4.3  Unit States                                        08 Apr 82


 1      AVAILABLE attention messages must be suppressed at least until an
 2      operator  interacts  with  the  unit's  drive,  the  unit becomes
 3      "Unit-Online" to any class driver via any  MSCP  server,  or  the
 4      unit's  drive loses context.  It is not acceptable for the unit's
 5      drive to "lose context" solely to forget that AVAILABLE attention
 6      messages  have  been  suppressed.  Loss of context must be due to
 7      some external reason, such as a power failure.   The  suppression
 8      of AVAILABLE attention messages must be cancelled or forgotten if
 9      the unit becomes "Unit-Online" to any class driver via  any  MSCP
10      server  or  if  an  operator  actuates  the  unit's  Run/Stop  or
11      Load/Unload switch, changes the unit number selected by the  Unit
12      Number  Select  Mechanism,  or  mounts  a different volume in the
13      unit.  Note that AVAILABLE attention messages are not  suppressed
14      (i.e., their suppression is instantly cancelled or forgotten) if,
15      after a  class  driver  issues  an  AVAILABLE  command  with  the
16      "Spin-down"  modifier  set,  the unit is still "Unit-Online" with
17      respect to one or more other class drivers.

18      MSCP  servers  may  send  redundant  or   unnecessary   AVAILABLE
19      attention  messages at any time, provided that attention messages
20      have been enabled, the  messages  have  not  been  suppressed  as
21      described  above, and the extra messages are infrequent enough to
22      avoid  causing   any   significant   overhead   in   either   the
23      communications mechanism or a host.  It is specifically allowable
24      for an  MSCP  server  to  precede  every  DUPLICATE  UNIT  NUMBER
25      attention  message  with  an  AVAILABLE attention message for the
26      same unit number.

27      A unit enters the "Unit-Online" state with  respect  to  a  class
28      driver upon the successful completion of an ONLINE command issued
29      by that class driver.



30      4.4  Unit Numbers

31      As described in Section 4.1, "Controls and Indicators", all  disk
32      and  tape drives accessible via MSCP must have a user visible and
33      Field Service alterable unit number.  The characters displayed as
34      the  unit number, interpreted as a decimal number, must match the
35      binary value passed in the "unit number" field  of  MSCP  control
36      messages.  Multi-unit drives and formatters may use a single unit
37      number select mechanism and display for the range of  consecutive
38      unit numbers assigned to their units.

39      MSCP  supports  unit  numbers  in  the  range  0  through   65535
40      (inclusive).  All controllers and units must support unit numbers
41      in the range 0 through 251 (inclusive).  Unit numbers between 252
42      and  65535  may  be  supported  or not at the controller's and/or
43      unit's option.  This implies that all units accessible  via  MSCP
44      must  have  a  unit number select mechanism capable of specifying
45      and a unit number display mechanism  capable  of  displaying  any
46      unit  number  in the range 0 through 251.  Controllers must treat
47      unsupported  unit  numbers  as   if   the   specified   unit   is
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-13
        4.4  Unit Numbers                                       08 Apr 82


 1      "Unit-Offline" due to being unknown (see preceding section).

 2      The intent of this broad range of unit numbers is that, within  a
 3      device class, all units that are accessible to a single host must
 4      have unique unit numbers.  In pursuit of  this  goal  units  with
 5      duplicate  unit  numbers  are  considered  to  be "Unit-Offline".
 6      However, this must be balanced against another goal, namely  that
 7      transient actions performed on another unit should not be allowed
 8      to affect continued  host  access  to  a  unit  that  is  already
 9      "Unit-Online".  Controllers must balance these two goals with the
10      following algorithms:

11           1.  Controllers detect and respond to duplicate unit numbers
12               across  all  units  that  are  "Unit-Online",  that  are
13               "Unit-Available", that are "Unit-Offline" solely due  to
14               being   disabled  or  known  or  having  duplicate  unit
15               numbers, or that the controller knows to  be  online  to
16               another  controller.   Units that are "Unit-Offline" due
17               to being unknown must not be  considered  for  duplicate
18               unit  number  detection.  Controllers may or may not, at
19               the  controller's  option,  consider  units   that   are
20               inoperative.   Detection  of  a  duplicate  unit  number
21               condition on one unit of a multi-unit drive  is  treated
22               as  a duplicate unit number condition on all other units
23               that share one or more of the following components  with
24               the unit having the duplicate unit number:

25               a.  A unit number select mechanism.

26               b.  A Run/Stop or Load/Unload switch.

27               c.  A spindle or other mechanical components.


28           2.  Discovery of a duplicate unit number condition does  not
29               affect  any  unit that is already "Unit-Online".  A unit
30               that is already  "Unit-Online"  remains  in  that  state
31               until  some other event (such as an AVAILABLE command or
32               loss of controller context) occurs that would  otherwise
33               cause  it  to become "Unit-Available", at which time the
34               unit  becomes  "Unit-Offline"  and   is   spun-down   as
35               described  below.   Note,  however,  that such a unit is
36               "Unit-Offline" to all other hosts (and therefore  cannot
37               be  brought "Unit-Online" by them) even while it remains
38               "Unit-Online" to its current hosts.

39   |       3.  When a controller becomes  aware  of  a  duplicate  unit
40   |           number  condition  on two or more units connected to it,
41   |           it  immediately  spins-down  all  such  units  that  are
42   |           "Unit-Available"  or  "Unit-Offline".   When a unit that
43   |           was "Unit-Online" with a duplicate unit number condition
44   |           becomes  "Unit-Available" for any reason, the controller
45   |           immediately spins it down.  In both  cases,  units  that
46   |           belong  to  a  multi-unit  drive  and share a spindle or
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-14
        4.4  Unit Numbers                                       08 Apr 82


 1   |           other mechanical components are to be spun down only  if
 2   |           all  of  the  units  of  the drive are "Unit-Offline" or
 3   |           "Unit-Available".

 4           4.  The controller returns "Unit-Offline" as the  state  for
 5               all units with duplicate unit number conditions that are
 6   |           not already "Unit-Online".  The controller  must  report
 7   |           that  the  units  are  "Unit-Offline"  due  to  having a
 8   |           duplicate unit number.  Other causes of the units  being
 9   |           "Unit-Offline"  may  or  may  not  be  reported  at  the
10   |           controller's option.

11           5.  The controller must  recognize  when  a  duplicate  unit
12               number  condition  goes  away.   That is, the controller
13               must recognize when all units except one with  the  same
14               duplicate  unit  number  have their unit numbers changed
15               and/or become unknown.  When this occurs, the controller
16               must send AVAILABLE attention messages for the remaining
17               unit  if  there  is  no  other  reason  for   it   being
18               "Unit-Offline",     since    it    has    just    become
19               "Unit-Available".

20      In addition to the above algorithms, controllers report duplicate
21      unit  number conditions to class drivers using the DUPLICATE UNIT
22      NUMBER attention message.  This allows hosts  to  complain  to  a
23      human  operator,  who will presumably remedy the condition.  This
24      message is sent to all  "Controller-Online"  class  drivers  that
25      have  attention  messages  enabled  when  a duplicate unit number
26      condition is first detected.  It is permissable for a  controller
27      to  send  redundant  or  extra  DUPLICATE  UNIT  NUMBER attention
28      messages,  provided  that  the  reported  duplicate  unit  number
29      condition  actually  exists.   See  Section 6.22, "Duplicate Unit
30      Number Attention Message", for more details.

31      The  above  algorithms  effectively  enforce  non-duplicate  unit
32      numbers  across  the  drives  connected  to  the same controller.
33      Although not required by  MSCP,  it  is  recommended  that  class
34      drivers use the following algorithm to enforce non-duplicate unit
35      numbers across the drives accessible to that class driver:

36           1.  Upon becoming aware of a unit (i.e., upon  receiving  an
37               AVAILABLE  attention  message),  the class driver should
38               check if it is already aware of a  unit  with  the  same
39               unit  number  on  a different MSCP server.  If it is not
40               aware of such a unit, it should exit.  If it is aware of
41               such  a  unit, it should check if that unit has the same
42               unit identifier.

43           2.  If the unit identifiers are the same,  it  is  the  same
44               unit multi-accessed to several controllers, so exit.  If
45               the unit identifiers are  different,  the  class  driver
46               should issue a GET UNIT STATUS command to see if the old
47               unit still exists.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-15
        4.4  Unit Numbers                                       08 Apr 82


 1           3.  If  the  old  unit  no   longer   exists   (i.e.,   it's
 2               "Unit-Offline"),  exit.   If  the old unit still exists,
 3               the class driver should check that the  unit  identifier
 4               returned  by  GET UNIT STATUS is also different from the
 5               unit identifier that  was  in  the  AVAILABLE  attention
 6               message.   If  the  unit identifiers are the same, exit.
 7               If the unit identifiers are different, the class  driver
 8               should  issue  an AVAILABLE command with the "Spin-down"
 9               modifier set for the new unit.  The class driver  should
10               also  issue  an  AVAILABLE  command with the "Spin-down"
11               modifier set for the old unit if the class driver is not
12               already "Unit-Online" to that unit.

13           4.  Whenever  a  class  driver   brings   an   MSCP   server
14               "Controller-Online",  the  class  driver  should  issue,
15               through that MSCP server, AVAILABLE  commands  with  the
16               "Spin-down"  modifier  set  for  all  units  that it has
17               "Unit-Online" via another MSCP server.

18           5.  Whenever a class driver brings a unit "Unit-Online", the
19               class  driver should issue ONLINE commands for that same
20               unit number to all  MSCP  servers.   If  more  than  one
21               ONLINE  commands succeeds, the class driver should check
22               that the unit identifiers returned by all the successful
23               ONLINE  commands  are  the  same.   If  any  of the unit
24               identifiers are different, then the class driver  should
25               treat all the ONLINE commands as having failed and issue
26               AVAILABLE commands with the "Spin-down" modifier set  to
27               all MSCP servers on which the ONLINE command succeeded.

28      Note that this algorithm uses the fact that an AVAILABLE  command
29      with  the "Spin-down" modifier set suppresses AVAILABLE attention
30      messages until a human operator interacts with the unit.



31      4.5  Command Catagories and Execution Order

32      MSCP commands fall into one of  four  command  categories.   Each
33      category  has  a  set  of  execution order restrictions that MSCP
34      servers must satisfy.  The four categories and their restrictions
35      are described below.

36      Immediate commands are those commands, such as status  inquiries,
37      that  both  require very little time to complete and do not cause
38      any unit context changes.  MSCP servers  must  process  immediate
39      commands  immediately,  without waiting for any other commands to
40      complete.  MSCP  servers  must  guarantee  that  all  outstanding
41      immediate  commands plus an additional GET COMMAND STATUS command
42      issued by each "Controller-Online"  class  driver  will  complete
43      within the controller timeout interval.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-16
        4.5  Command Catagories and Execution Order             08 Apr 82


 1      Class drivers may issue Immediate commands whenever their  credit
 2      balance is greater than zero, whereas all other commands may only
 3      be issued when the  class  driver's  credit  balance  is  two  or
 4      larger.   This is discussed further in Chapter 3, "Class Driver /
 5      MSCP Server Communications".  Class drivers are  thus  guaranteed
 6      to  be  able to issue at least one Immediate command, and have it
 7      executed,  regardless  of  what  other  commands  they  may  have
 8      outstanding.  In particular, the class driver is guaranteed to be
 9      able to issue a GET COMMAND STATUS command and have  it  complete
10      within the controller timeout interval.

11      Sequential commands are those commands that, for the  same  unit,
12      must be executed in precise order.  Sequential commands typically
13      alter a unit's context, such as by changing a unit characteristic
14      or  by  altering  the  position  of a tape drive.  All sequential
15      commands for a particular unit that  are  received  on  the  same
16      connection  must  be  executed  in  the exact order that the MSCP
17      server receives them.  The execution of a sequential command  may
18      not  be interleaved with the execution of any other sequential or
19      non-sequential commands for  the  same  unit.   Furthermore,  any
20      non-sequential   commands   received   before  and  on  the  same
21      connection as a particular sequential command must  be  completed
22      before  execution  of  that  sequential  command  begins, and any
23      non-sequential commands received after and on the same connection
24      as a particular sequential command must not begin execution until
25      after that sequential command is completed.  Sequential  commands
26      are,  in  effect,  a  barrier that non-sequential commands cannot
27      pass or penetrate.

28      Non-sequential commands are those commands that  controllers  may
29      re-order   so   as  to  optimize  performance.   Controllers  may
30      furthermore interleave the execution  of  several  non-sequential
31      commands  among themselves, performing each command a fragment at
32      a time.  The only restrictions are:

33           1.  Execution of a non-sequential command must not cross the
34               barrier  created  by  a  sequential command for the same
35               unit.

36           2.  The controller must complete useful work on  its  oldest
37               outstanding   command   within  the  controller  timeout
38               interval, so as to not cause  a  command  timeout.   See
39               Section 4.10, "Command Timeouts".


40      Special commands are similar to non-sequential commands, but have
41      additional,  unique  execution order requirements.  The execution
42      order requirements for special  commands  are  described  in  the
43      commands' description.

44      Note that tape class devices only have immediate  and  sequential
45      commands.   There is no such thing as a non-sequential or special
46      tape class command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-17
        4.5  Command Catagories and Execution Order             08 Apr 82


 1      Execution order is based on  the  order  in  which  commands  are
 2      received by the controller's MSCP server.  For commands sent by a
 3      single class driver, the order of transmission  is  identical  to
 4      the  order  of  reception.   For  commands  sent by several class
 5      drivers, the order of reception is essentially random.  The  only
 6      way  that a class driver can ensure that one of its commands will
 7      be received after some other  command  issued  by  another  class
 8      driver is to wait until the other class driver receives the first
 9      command's  end  message  (i.e.,  wait  until  the  first  command
10      completes) before sending the command.

11      For the purpose of determining  execution  order,  a  command  is
12      completed  when the controller's MSCP server queues the command's
13      end message for transmission to the host.   The  controller  need
14      not  wait  until  the  host has confirmed its reception, although
15      sequential message delivery guarantees must  be  preserved.   The
16      gist  of this is that after termination of the connection between
17      a host class  driver  and  an  MSCP  server,  the  absence  of  a
18      sequential  command's  end  message  implies  nothing  about  the
19      execution or non-execution of the sequential command.
20   |  
21   |  When an MSCP server finishes processing or executing  a  command,
22   |  the  command  can finish in any of four ways.  Based on which way
23   |  the server finishes a command, the command is said to  have  been
24   |  completed, rejected, terminated, or aborted.
25   |  
26   |  A completed command is  a  command  that  the  server  has  fully
27   |  executed  to  its normal conclusion.  A command that is completed
28   |  has either succeeded or encountered an unrecoverable  error.   In
29   |  normal operation all commands are completed.
30   |  
31   |  A rejected command is a command for which the server  never  even
32   |  starts processing.  Some commands are rejected due to termination
33   |  of the connection between the MSCP server and the  class  driver.
34   |  Such  commands  are discarded by the MSCP server, port driver, or
35   |  communications mechanism before any work is done on them.   Other
36   |  commands  are  rejected due to being illegal commands or due to a
37   |  unit being in an illegal state.  For example,  transfer  commands
38   |  are rejected if the specified unit is not "Unit-Online".
39   |  
40   |  A terminated command is a command for  which  the  server  begins
41   |  processing,  but  then  terminates  processing  part  way through
42   |  command execution.  Transfer commands  are  terminated  if  their
43   |  unit is disconnected (cable breaks or drive loses power) part way
44   |  through the transfer.  Transfer commands may also  be  terminated
45   |  if the connection between the MSCP server and the class driver is
46   |  terminated  part  way  through  the  transfer.   Generally   only
47   |  Non-Sequential   commands  can  be  terminated.   Termination  of
48   |  Sequential commands is discussed below.
49   |  
50   |  An aborted command is a command that the class driver  has  asked
51   |  to  have  aborted  via an ABORT command, and that furthermore has
52   |  been located and explicitly aborted by the MSCP server.  That is,
53   |  commands  that  the  MSCP  server  just  allows  to  complete are
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-18
        4.5  Command Catagories and Execution Order             08 Apr 82


 1   |  completed, not aborted.  An aborted command is effectively either
 2   |  rejected  or terminated, depending upon whether or not the server
 3   |  has begun execution of the command when it processes  the  ABORT.
 4   |  (This  definition  of an aborted command is from the viewpoint of
 5   |  an MSCP server.  From the viewpoint of a class driver, an aborted
 6   |  command  is  any  command  for  which  an  ABORT command has been
 7   |  issued.)
 8   |  
 9   |  Immediate commands are always completed if the connection between
10   |  MSCP  server  and  class  driver remains intact;  they may not be
11   |  rejected,  terminated,  or  aborted.   If   the   connection   is
12   |  terminated  before an Immedate command can be completed, then the
13   |  command  may  be  completed,  rejected,  or  terminated.    Since
14   |  Immediate  commands  do not change the state, context, or data of
15   |  the unit, these three command completion modes are equivalent  if
16   |  the connection has been terminated.
17   |  
18   |  Non-sequential commands may, in general, be completed,  rejected,
19   |  terminated,  or  aborted.   This  is  true both if the connection
20   |  remains intact or if it is terminated.   However,  there  is  one
21   |  restriction  regarding  write  operations.  Write operations must
22   |  not be terminated as a result of any normal operator interactions
23   |  with  the unit.  That is, write operations must not be terminated
24   |  (partially completed) as a result of an  operator  attempting  to
25   |  spin-down,  dismount,  or write protect the unit.  The purpose of
26   |  this restriction is to prevent data  corruption  due  to  partial
27   |  updates.   This  is  further  discussed  under  the term "smooth"
28   |  transitions in Section 4.3,  "Unit  States",  and  Section  4.13,
29   |  "Write Protection".
30   |  
31   |  Sequential commands may be completed or rejected, but in  general
32   |  may  not  be  terminated.  If a Sequential command is aborted, it
33   |  must be aborted before it begins execution (rejected) rather than
34   |  in  the middle of execution (terminated).  The reason for this is
35   |  that Sequential commands appear to hosts as atomic  (indivisible)
36   |  operations.  Thus both this requirement, that Sequential commands
37   |  cannot be terminated, therefore  preventing  subsequent  commands
38   |  from  acting on partially updated unit state and context, and the
39   |  requirement that execution of  a  Sequential  command  cannot  be
40   |  interleaved  with  any  other command on the same unit, therefore
41   |  preventing a concurrent command from acting on partially  updated
42   |  unit state and context.
43   |  
44   |  There are two exceptions to the  requirement  that  a  Sequential
45   |  command  may  not  be terminated.  The first is that a server may
46   |  terminate a  Sequential  command  in  the  middle  of  execution,
47   |  provided  that  the termination process undoes all unit state and
48   |  context changes that have  been  made  on  the  unit.   From  the
49   |  viewpoint of the class driver, this case is exactly equivalent to
50   |  the command having been rejected.  The second exception  is  that
51   |  the  controller  and/or  unit  loses  context, generally due to a
52   |  power failure or similar  event.   Since  the  unit's  state  and
53   |  context  will  be  completely  reset  when  power  and/or  normal
54   |  operation are restored,  the  fact  that  it  was  left  in  some
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-19
        4.5  Command Catagories and Execution Order             08 Apr 82


 1   |  indeterminate   state   does  not  matter.   Note  that,  if  the
 2   |  controller  loses  context,  it  must  lose   context   for   all
 3   |  connections  to  the  affected unit's device class (implying that
 4   |  all such connections have been  terminated),  as  otherwise  some
 5   |  other class driver may see the unit in an indeterminate state.
 6   |  
 7   |  Note that any command that fails due to an  unrecoverable  device
 8   |  or  data  error  is  a completed command.  Commands are rejected,
 9   |  terminated, or aborted only in  response  to  inappropriate  unit
10   |  state  or  context, connection termination, and being aborted via
11   |  ABORT commands.
12   |  
13   |  Commands that are rejected, terminated,  or  aborted  must  still
14   |  return  their  proper end message format with valid parameters as
15   |  defined in the individual command descriptions.  The  only  cases
16   |  where  a different end message format may be returned are Serious
17   |  Exceptions and protocol errors, both of which have a special  end
18   |  message format and end message opcode.



19      4.6  Class Driver / MSCP Server Synchronization

20      Synchronization  of  a  class  driver  with  an  MSCP  server  is
21      accomplished  by  establishing  or re-establishing the connection
22      between  the  class  driver  and  the  MSCP  server.   When   the
23      connection  is  established  or  re-established,  the MSCP server
24      terminates all commands that  are  outstanding  from  that  class
25      driver.   This  forces  the dialogue between the class driver and
26      MSCP server to a known, synchronized state:  that  of  having  no
27      outstanding  commands.   After  establishing  the  connection the
28      class  driver  can  issue   commands   without   worrying   about
29      duplicating  command  reference numbers or other unfortunate side
30      effects.  Note  that  synchronizing  with  the  MSCP  server,  if
31      successful, causes the MSCP server to become "Controller-Online".

32      As stated above,  the  main  purpose  of  synchronization  is  to
33      guarantee  that  there  are no outstanding commands, thus forcing
34      the dialogue between the class driver and MSCP server to a  known
35      state.   MSCP  servers  must  ensure  that  this guarantee is met
36      before they allow synchronization to complete (i.e., before  they
37      become  "Controller-Online").   In  particular, MSCP servers must
38      guarantee that no end messages will be sent  and  that  no  units
39      will  have  their  state, context, or (data) contents changed for
40      any commands that were issued on an earlier  incarnation  of  the
41      connection  between  the class driver and MSCP server.  Note that
42      an MSCP server may allow outstanding commands to complete, either
43      partially  or  entirely,  but  if  it  does  it  must  delay  the
44      completion  of   synchronization   (delay   the   transition   to
45      "Controller-Online")  until  all  such commands have completed or
46      terminated.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-20
        4.6  Class Driver / MSCP Server Synchronization         08 Apr 82


 1      Class drivers must synchronize with the MSCP server whenever  the
 2      host  boots,  recovers from a power failure, loses context, or is
 3      recovering from certain errors.  After synchronizing with an MSCP
 4      server, the class driver should do the following:

 5           1.  Issue  a  SET  CONTROLLER  CHARACTERISTICS  command   to
 6               establish  host  settable controller characteristics and
 7               obtain non-host settable controller characteristics.

 8           2.  Issue ONLINE commands  for  all  units  that  the  class
 9               driver wishes to be "Unit-Online".

10           3.  Re-issue all commands, if  any,  that  were  outstanding
11               before  the  class  driver  synchronized  with  the MSCP
12               server in the exact  order  that  they  were  originally
13               issued.   However,  any  commands that have been aborted
14               (i.e., for which an ABORT command has been issued)  must
15               not  be  re-issued.   Instead  the  class  driver should
16               assume that the command has  been  successfully  aborted
17               and is therefore no longer outstanding.

18      There is one exception  to  re-issuing  all  commands  that  were
19      outstanding.  The class driver must maintain a retry limit count,
20      to ensure that its oldest outstanding command  won't  be  retried
21      infinitely  many  times.   The  magnitude  of  this limit is host
22      dependent, although the oldest command must be retried  at  least
23      once.  When the class driver's oldest outstanding command exceeds
24      the retry limit count, an error  must  be  returned  rather  than
25      retrying  the  command  again.   All  other outstanding commands,
26      however, should still be retried.   See  Section  4.10,  "Command
27      Timeouts", for more information.

28      It may be possible that a class driver will receive messages from
29      an   MSCP   server   after   the   class   driver  has  initiated
30      synchronization   with   the   MSCP   server   but   before   the
31      synchronization  completes.   Whether  or  not  this  is  in fact
32      possible is communications mechanism  dependent,  as  it  depends
33      upon the detailed design of the communications mechanism and port
34      driver.  Any attention messages that the  class  driver  receives
35      during this interval should be discarded.  Any error log messages
36      should be logged in the normal fashion.  Any  end  messages  that
37      the  class  driver  receives  during  this interval may be either
38      handled normally (thus completing the corresponding  command)  or
39      else discarded.  If the class driver discards one end message, it
40      must   discard   all   subsequent   end   messages   until    the
41      synchronization  completes.   It  is  recommended,  although  not
42      required,  that  class  drivers  handle  all  such  end  messages
43      normally.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-21
        4.7  Class Driver Error Recovery                        08 Apr 82


 1      4.7  Class Driver Error Recovery

 2      The principle method of error recovery used by class  drivers  is
 3      to  re-synchronize  with  the  MSCP  server,  as described in the
 4      preceding section.  All  communications  mechanism  failures  and
 5      many   controller   failures  are  reported  by  terminating  the
 6      connection between the class driver and MSCP server, in  response
 7      to  which  the class driver should attempt to re-synchronize with
 8      the MSCP server.  If the class driver decides that the controller
 9      is  insane,  either  because the class driver received an invalid
10      message or because a command timed  out,  it  should  recover  by
11      re-synchronizing  with  the  MSCP server.  Similarly, if the MSCP
12      server decides that the class driver is insane, it may  terminate
13      the  connection  to  the class driver.  If the class driver is in
14      fact actually sane, it will re-synchronize with the  MSCP  server
15      after  the  port  driver notifies it that the connection has been
16      terminated.

17      Aside from  re-synchronization  as  described  in  the  preceding
18      paragraph, class drivers need perform very little error recovery,
19      since  controllers  handle  all  recoverable  errors.   The  only
20      exceptions to this guideline are as follows:

21           1.  Errors on multi-access drives should  be  retried  using
22               another controller.

23           2.  Commands   that   fail   due   to   the    unit    being
24               "Unit-Available"  should  typically  be  re-issued after
25               bringing the unit "Unit-Online".

26           3.  High  availability  systems  may  wish  to  perform  the
27               enhanced error recovery described below.


28      High  availability  systems  may  wish  to  use   the   following
29      additional  error  recovery  strategy  in  order  to minimize the
30      impact of certain types  of  controller  problems.   Rather  than
31      re-issuing    outstanding    commands    all    at   once   after
32      re-synchronizing with a controller, such a system should  instead
33   |  re-issue  the oldest outstanding command all by itself.  The host
34   |  class driver should re-issue all other outstanding commands  only
35   |  after  the  oldest  command  completes.   The  other  outstanding
36   |  commands may be re-issued either all at once (recommended) or one
37   |  at a time.
38   |  
39   |  If the oldest command times out or otherwise  fails  again  after
40   |  being re-issued, then it was presumably the source of the problem
41   |  and  normal  operation  will  resume.   If  the  oldest   command
42   |  succeeds,  then  the  problem  is  most  likely  due to some race
43   |  condition within the controller and will not  re-occur.   If  the
44   |  problem   does  re-occur,  then  successive  iterations  of  this
45   |  algorithm will execute commands one at a time until the offending
46   |  command is found and discarded.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-22
        4.8  This section deliberately omitted.                 08 Apr 82


 1      4.8  This section deliberately omitted.

 2      4.9  Host Access Timeouts

 3      MSCP servers provide  host  access  timeouts  to  guarantee  that
 4      multi-access  drives  will  be  accessible  in  spite  of certain
 5      communications mechanism failures.  If  the  communications  path
 6      between  hosts and a controller fails when one or more drives are
 7      "Unit-Online" via that  controller,  the  drives  would  normally
 8      become  inaccessible.   The  drives  can't  be  accessed  via the
 9      controller through  which  they  are  "Unit-Online",  since  that
10      controller  can't  be  accessed, and they can't be accessed via a
11      second controller, since they are "Unit-Online" through the first
12      controller.  The host access timeout, if enabled, eliminates this
13      problem by causing the first controller to automatically  release
14      all  drives  if  it  doesn't receive a command within a specified
15      time interval.

16      The exact mechanism used for host access timeouts is to have  the
17      controller's  MSCP  server become "Controller-Available" relative
18      to any host class driver whose host access timeout expires.   The
19      MSCP server automatically resets the timeout whenever it receives
20      a command from the class driver or has a command outstanding from
21      that  class  driver.   Therefore the timeout will never expire if
22      the class driver maintains a reasonably constant dialog with  the
23      MSCP  server.   Note  that implementing host access timeouts on a
24      per host  basis  has  the  benefit  that  the  MSCP  server  will
25      automatically  release  any resources allocated to a host if that
26      host goes down.

27      If communication with all hosts ceases, the host  access  timeout
28      of  each  class  driver  will ultimately expire, causing the MSCP
29      server to become "Controller-Available" relative  to  all  hosts.
30      Each  unit  will  be  released, allowing it to be accessed via an
31      alternate controller, as soon  as  all  class  drivers  that  are
32      "Unit-Online"  with  respect  to the unit (or any other unit that
33      shares its access path) cease to be "Unit-Online"  by  virtue  of
34      becoming  "Controller-Available".   Ultimately  all class drivers
35      will become "Controller-Available", thus releasing all units.

36      Class drivers specify the time interval that an MSCP server  will
37      use   for   the   host  access  timeout  in  the  SET  CONTROLLER
38      CHARACTERISTICS command.  A host access  timeout  value  of  zero
39      specifies  that  host  access  timeouts  should  be  disabled.  A
40      default host access timeout of 60 seconds is used from the time a
41      class  driver  becomes  "Controller-Online"  until  it issues its
42      first SET CONTROLLER CHARACTERISTICS command.

43      Each class driver may specify a  separate  time  interval.   This
44      allows  class drivers to vary the host access timeout interval in
45      accordance with host policy and availability requirements.   High
46      availability  systems  should  typically  use a fairly short host
47      access timeout, on the order of 10 to 30 seconds, together with a
48      background  process  that  verifies the continued availability of
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-23
        4.9  Host Access Timeouts                               08 Apr 82


 1      the host  to  controller  communications  path.   The  background
 2      process would have the desirable side effect of ensuring that the
 3      host access timeout never expired.  Normal systems should  use  a
 4      larger  timeout,  on  the  order  of  1  to  5  minutes, to avoid
 5      excessive resynchronizations, yet still allow  failure  recovery.
 6      Single user and other specialized systems may disable host access
 7      timeouts.  Note that host access  timeouts  should  typically  be
 8      enabled  even  on  systems  that  do not seem to require them, as
 9      drives may be multi-accessed to a totally separate host used as a
10      backup system.

11      MSCP servers must implement host access timeouts subject  to  the
12      following constraints:

13           1.  The host access timeout expires, for a particular  class
14               driver,  at  the  amount  of  the  host  access  timeout
15               interval after the controller or MSCP  server  completes
16               all   outstanding   commands  from  that  class  driver,
17               provided that no new commands  are  received  from  that
18               class driver during this interval.

19           2.  The MSCP server must  enter  the  "Controller-Available"
20               state  (as  a  result of host access timeout expiration)
21               relative to a class driver no sooner than the moment  of
22               host access timeout expiration defined in item 1 above.

23           3.  The MSCP server should enter the  "Controller-Available"
24               state (as a result of host access timeout expiration) as
25               soon as possible after the moment of host access timeout
26               expiration  defined  in  item  1 above.  Except when the
27               controller  is  saturated  with  work  for  other  class
28               drivers,  this must be no later than one second plus the
29               amount of the host access  timeout  interval  after  the
30               moment of host access timeout expiration.

31      In other words, the host access timeout is measured from the time
32      that  the  last  command is completed.  The MSCP server may defer
33      recognition of host access  timeout  expiration  for  up  to  one
34      second  plus  the  amount  of  the  host access timeout after the
35      formal expiration of the  timeout.   That  is,  the  host  access
36      timeout must be implemented with an accuracy range of -0% through
37      +100%+1 second.  Furthermore, this accuracy range may be extended
38      on  the  high  side  if the controller is saturated with work for
39      other class drivers.

40      This definition of host access timeouts has  been  structured  to
41      allow  at  least  two  alternative implementations.  In the first
42      implementation, the controller or MSCP server starts a timer when
43      it goes "idle" -- that is, when it completes the last outstanding
44      command.  The duration of the timer is the  host  access  timeout
45      interval.   The timer must be designed to not err on the low side
46      (too short an interval) and to err by no more than  a  factor  of
47      two  on  the  high  side  (too  long  an interval).  If the timer
48      expires before the MSCP server receives another command,  declare
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-24
        4.9  Host Access Timeouts                               08 Apr 82


 1      a  host  access  timeout  and become "Controller-Available".  The
 2      second implementation uses a  continuously  running  timer  which
 3      "ticks"  at  the  host  access  timeout  interval.   If the timer
 4      "ticks" twice in succession without there being  any  outstanding
 5      commands  or  without  the  MSCP server having received a command
 6      from the host, then declare a  host  access  timeout  and  become
 7      "Controller-Available".

 8      Each controller or MSCP server has a minimum and a  maximum  host
 9      access  timeout  interval  that it implements.  If a class driver
10      specifies a host access timeout interval that is  less  than  the
11      minimum,  then  the  MSCP  server  uses  its minimum.  If a class
12      driver specifies a host access timeout interval that  is  greater
13      than  the  controller's  maximum,  then  the  controller uses its
14      maximum.  A controller's or MSCP  server's  minimum  host  access
15      timeout  interval  must be 10 seconds or less.  A controller's or
16      MSCP server's maximum host access timeout  interval  must  be  at
17      least 255 seconds.  That is, all controllers must fully implement
18      host access timeout intervals in the range 10 through 255 seconds
19      inclusive.  Support of intervals outside this range is controller
20      dependent.  The range of host access  timeout  intervals  that  a
21      controller   supports  must  be  described  in  the  controller's
22      Functional Specification;  it cannot be obtained via MSCP.

23      Note that all controllers and MSCP servers  must  also  implement
24      the  host  access  timeout value zero, which disables host access
25      timeouts.



26      4.10  Command Timeouts

27      Host class drivers use command timeouts  to  guarantee  that  all
28      controller or communications mechanism failures will be detected.
29      The failures detected by command timeouts include partially  sane
30      or  deadlocked  controllers,  which  may  continue to process new
31      commands even though one or more old commands have been lost  and
32      will  never complete.  The use of command timeouts centers around
33      the GET COMMAND STATUS command.  Indeed, the primary  purpose  of
34      the GET COMMAND STATUS command is for command timeouts.

35      A controller is sane if and only if it will  ultimately  complete
36      all  commands  submitted to it.  For practical purposes, the term
37      "ultimately" must be replaced with the phrase "within  reasonable
38      time".   What  constitutes  a  "reasonable  time" varies with the
39      complexity of the command and the performance of  the  controller
40      and  drives.   We  can eliminate the difficulty of the host class
41      driver having to derive this "reasonable time" by re-stating  the
42      definition of a sane controller as follows:  A controller is sane
43      if and only if it will always complete useful work on its  oldest
44      outstanding request within reasonable time.  This definition lets
45      us set the "reasonable time" to some fixed value,  and  vary  the
46      units  in  which  we  measure  "useful  work"  according  to  the
47      complexity of the command.  Command timeouts are  based  on  this
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-25
        4.10  Command Timeouts                                  08 Apr 82


 1      second definition.

 2      A class  driver  implements  the  command  timeout  mechanism  as
 3      follows.     For    each    MSCP    server   to   which   it   is
 4      "Controller-Online",  the  class  driver  keeps  track  of  which
 5      command  is  its  oldest  outstanding  command  plus the previous
 6      "command status" value for its oldest outstanding  command.   The
 7      previous  "command  status"  value  should  be  set  to  all ones
 8      whenever the oldest command completes and a new  command  becomes
 9      the  oldest.   The  class  driver should issue GET COMMAND STATUS
10      commands for its oldest outstanding command at intervals  of  the
11      controller  timeout  interval  or  longer.  When each GET COMMAND
12      STATUS command completes, the class  driver  must  check  if  the
13      command  for  which it was issued is still outstanding and, if it
14      is, verify that the "command status" returned by the GET  COMMAND
15      STATUS command is lower than the previous "command status".  This
16      value measures the amount of work remaining before completion  of
17      the  command.   If the value ever increases or stays the same, or
18      if a GET COMMAND  STATUS  command  ever  takes  longer  than  the
19      controller  timeout  interval  to complete, then the class driver
20      should assume that the controller has failed  and  re-synchronize
21      with the controller.

22      In addition to guaranteeing that they will complete  useful  work
23      on  their  oldest  outstanding  command,  controllers  must  also
24      guarantee that they will complete all aborted commands within the
25      controller  timeout  interval.  That is, an aborted command's end
26      message must be sent no later than the amount of  the  controller
27      timeout  interval  after  the  ABORT command's end message.  Host
28      class drivers can check this by  setting  the  previous  "command
29      status"  value to one whenever the oldest outstanding command has
30      been aborted (i.e., when the  class  driver  receives  the  ABORT
31      command's  end  message  indicating  that  its oldest outstanding
32      command has been aborted).

33      Single host controllers (i.e., controllers that  do  not  provide
34      Multi-Host  support) need not guarantee that all aborted commands
35      will  complete  within  the  controller   timeout   interval   if
36      excessively  pathological  situations  arise.   Examples  of such
37      situations include:

38           1.  ACCESS or ERASE commands whose byte  counts  exceed  the
39               maximum  data  transfer  size  imposed on READ and WRITE
40               commands by the communications mechanism.  For  example,
41               the  UNIBUS  imposes  an  architectural maximum transfer
42               size of 2**18 bytes, since  that  is  the  size  of  the
43               UNIBUS   address  space.   Therefore  ACCESS  and  ERASE
44               commands  whose  byte  counts  exceed  2**18  bytes  are
45               excessively  pathological  for  controllers that use the
46               UNIBUS  as  their  communications  mechanism,   so   the
47               controller  need not meet the abort timeout requirements
48               when such commands are outstanding.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-26
        4.10  Command Timeouts                                  08 Apr 82


 1           2.  Compound or  multiple  errors,  causing  error  recovery
 2               sequences to stretch out to unrealistic lengths.

 3      If the command timeout for an aborted command expires due to such
 4      a  situation,  the class driver will re-synchronize with the MSCP
 5      server and re-issue all outstanding  commands  except  for  those
 6      that  had  been  aborted.  Since the aborted commands will not be
 7      re-issued, the timeout will not re-occur.  Thus this exception is
 8      transparent to host class drivers.

 9      The above algorithm applies to non-Immediate commands.  With  one
10      exception  the  same  algorithm  may  also  be used for Immediate
11      commands, although  a  simpler  one  (using  the  fact  that  all
12      Immediate   commands   complete  within  the  controller  timeout
13      interval) is also appropriate.  The  one  exception  is  the  GET
14      COMMAND  STATUS  command  used  by  the timeout algorithm itself.
15      This command must be timed out as follows.  If the class driver's
16      credit  balance is zero when it attempts to issue the GET COMMAND
17      STATUS command, it must queue the GET COMMAND STATUS command  for
18      immediate  transmission  (before  any  other commands that may be
19      outstanding) when its credit balance becomes  non-zero.   If  the
20      controller  timeout interval expires again before the GET COMMAND
21      STATUS command has both been transmitted and completed, then  the
22      class  driver should assume that the controller has failed.  Note
23      that the class  driver's  credit  balance  is  guaranteed  to  be
24      non-zero  when all outstanding Immediate commands have completed.
25      Note also that controllers or MSCP servers  must  guarantee  that
26      all  outstanding  Immediate  commands  plus  one  additional  GET
27      COMMAND  STATUS  command  will  complete  within  the  controller
28      timeout interval.

29      Upon concluding that a controller has failed,  the  class  driver
30      must   re-synchronize  with  the  controller's  MSCP  server  and
31      re-issue all commands (except  commands  that  it  has  tried  to
32      abort)  that  were  outstanding  to  that MSCP server in the same
33      order that they  were  originally  issued.   In  particular,  the
34      oldest  outstanding  command  (the  one  that  timed out) must be
35      issued first (after initial SET  CONTROLLER  CHARACTERISTICS  and
36      ONLINE commands).  The only exception to this is if the command's
37      retry count expires.  The class driver should  maintain  a  retry
38      count of the number of times the oldest command has timed out and
39      been retried.  If the retry count exceeds a host dependent  retry
40      limit,  the  class  driver  should  return  an  error rather than
41      retrying the command again.  The  size  of  the  retry  limit  is
42      determined  by  host  policy,  except  that  all commands must be
43      retried  at  least  once.   Note  that  sub-code  zero   of   the
44      "Controller  Error"  status  code  has been reserved for commands
45      that exceed their retry  count.   This  sub-code  must  never  be
46      generated by MSCP servers;  it is generated by class drivers as a
47      standard means of reporting command timeout errors.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-27
        4.10  Command Timeouts                                  08 Apr 82


 1      In order to implement command timeouts,  the  host  class  driver
 2      must  first  obtain  the  controller timeout interval via the SET
 3      CONTROLLER CHARACTERISTICS command.  Therefore the  class  driver
 4      should  issue  a  SET  CONTROLLER  CHARACTERISTICS command as the
 5      first command  after  becoming  "Controller-Online".   The  class
 6      driver should use a controller timeout interval of 10 seconds for
 7      this initial command.  The class driver must  never  use  a  time
 8      interval that is shorter than the controller specified controller
 9      timeout interval for its command timeout determination,  although
10      the  class driver may use a time interval that is longer than the
11      one specified by the controller.  The controller timeout interval
12      specified by the controller must not be larger than 4 minutes and
13      15 seconds (255 seconds).

14      One characteristic of this command timeout algorithm is that MSCP
15      servers  need  not implement, and indeed most will not implement,
16      the GET COMMAND STATUS command for  any  command  that  the  MSCP
17      server  can guarantee will complete within the controller timeout
18      interval.  The GET COMMAND STATUS command  should  always  return
19      the  value zero as the "command status" of such a command.  It is
20      acceptable  if,  due  to  vagaries  of  controller   optimization
21      algorithms,  such  a  command will occasionally timeout.  This is
22      acceptable,  so  long  as  the  frequency  of  such  timeouts  is
23      extremely  small and the controller immediately begins processing
24      the first command it receives  after  re-synchronization.   Since
25      the  class  driver re-issues commands in the same order that they
26      were originally issued,  the  oldest  or  timed  out  command  is
27      re-issued  first,  effectively  guaranteeing  that it will not be
28   |  delayed again by the controller's optimization algorithms.   (The
29   |  simplest  way  for most controllers to implement this is to treat
30   |  the  first  Non-Sequential  command  received  across   a   newly
31   |  established connection as if it were an Express Request).



32      4.11  Disk Geometry and Format

33      4.11.1  Logical Block Number Address Space Structure

34      The host accessible portion of a disk unit consists of  a  vector
35      of  fixed  length  blocks, called logical blocks.  Logical blocks
36      are identified by logical block numbers (LBNs) which  range  from
37      zero  through  N-1  inclusive,  where  "N" is the total number of
38      logical blocks on the unit.  The logical blocks  on  a  unit  are
39      divided into two mutually exclusive regions:

40           1.  The host area consists of those logical blocks available
41               for  host data storage.  Logical blocks in the host area
42               have LBNs in the range  zero  throught  US-1  inclusive,
43               where  "US"  is  the  "unit  size", or number of logical
44               blocks in the host area.  The host obtains "US"  or  the
45               "unit  size" from the ONLINE or SET UNIT CHARACTERISTICS
46               command end messages.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-28
        4.11  Disk Geometry and Format                          08 Apr 82


 1           2.  The unit's Replacement and Caching Table (RCT), used  to
 2               record   bad   block   replacement   and   miscellaneous
 3               housekeeping information.  This information  is  further
 4               described  below.  The RCT (actually, multiple copies of
 5               the RCT) occupies the logical blocks numbered US through
 6               N-1 inclusive.

 7   |  The presence of the RCT is optional;  see the description below.

 8      All of the logical blocks in the host area are guaranteed  to  be
 9      "good"  -- that is, to be free of permanent or hard errors (media
10      defects).   Most  controllers  implement  this  via   bad   block
11      replacement.    A  pool  of  replacement  blocks,  identified  by
12      replacement block  numbers  (RBNs),  is  provided  on  the  disk.
13      Replacement  blocks  are  not  directly accessible to hosts.  All
14      host area logical blocks that are bad (i.e., that  contain  media
15      defects  leading  to  hard errors or large numbers of correctable
16      errors) are replaced by a replacement block.  The mechanism  used
17      to  perform  this  replacement,  and  to revector accesses to bad
18      logical blocks to the proper replacement blocks, is described  in
19      the  DEC  Standard Disk Format and/or the controller's Functional
20      Specification.  The  pool  of  replacement  blocks  is  typically
21      distributed  throughout  the disk, so that revectoring of logical
22      block accesses to replacement blocks  has  negligible  impact  on
23      performance.   See Section 4.12, "Bad Block Replacement", and DEC
24      Standard  Disk  Format  for  more  information   on   bad   block
25      replacement.



26      4.11.2  Replacement and Caching Table (RCT) Overview

27      The logical blocks that contain the RCT are not guaranteed to  be
28      "good".   Since  the  RCT  describes  the  bad  logical  block to
29      replacement block mapping, mapping bad RCT blocks to  replacement
30      blocks  would present an insoluble recursion problem.  Instead of
31      using replacement blocks for  bad  RCT  blocks,  the  RCT  region
32      actually  contains  multiple copies of the RCT.  Hosts obtain the
33      size of each RCT copy and the number of RCT copies  via  the  GET
34      UNIT  STATUS command.  The last copy of the RCT may be truncated.
35      See the DEC Standard Disk Format.  Note that the disk is unusable
36      if the corresponding block is bad in every copy of the RCT.

37      The detailed  format  and  access  algorithms  for  the  RCT  are
38      described  in the DEC Standard Disk format.  In general, however,
39      each copy of the RCT contains the following information:

40           1.  One entry per replacement block, identifying the logical
41               block, if any, that has been replaced by the replacement
42               block.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-29
        4.11  Disk Geometry and Format                          08 Apr 82


 1           2.  Context   information   identifying   the   bad    block
 2               replacement  operation,  if  any,  that  is currently in
 3               progress on this unit.   This  information  is  used  to
 4               complete the bad block replacement operation if the host
 5               and/or controller should crash  in  the  middle  of  bad
 6               block replacement.

 7           3.  A Volume Write Protect flag.


 8      Alternatively, a controller may use  a  non-standard  replacement
 9      scheme  or  some  other  scheme  than  bad  block  replacement to
10      guarantee that the logical blocks in the host  area  are  "good".
11      The  mechanisms  used  by such a controller to guarantee that the
12      host area logical blocks are "good" must be totally invisible  to
13      hosts,   and   must   not  require  host  cooperation  for  their
14      initialization, use, or maintenance.  Such a controller  or  unit
15   |  may  or may not have to provide the first block of the RCT, which
16   |  contains the Volume Write Protect flag.
17   |  
18   |  If the controller and unit meet the following requirements:
19   |  
20   |       1.  They controller and/or unit implement a non-standard bad
21   |           block  handling  scheme  that  is  totally  invisible to
22   |           hosts.
23   |  
24   |       2.  The unit either  has  non-removeable  media  or  it  has
25   |           removeable media and the write protect mechanism is some
26   |           kind of mechanical deformation of the media.  An example
27   |           of  such  a  mechanical deformation is the write-lockout
28   |           tab on a cassette.
29   |  
30   |  then no RCT whatsoever need be present.   All  other  disks  must
31   |  have  at  least  a  one block RCT.  The remainder of the RCT need
32   |  only be present for disks  that  use  bad  block  replacement  as
33   |  described in DEC Standard Disk Format.
34   |  
35   |  The first block of the RCT serves several  purposes.   For  disks
36   |  that  use  the  DEC  Standard  Disk  Format bad block replacement
37   |  scheme, it provides a place to record any bad  block  replacement
38   |  that  may  be in progress, so that it can be completed regardless
39   |  of power failures and other losses of  context.   It  provides  a
40   |  write  protect  flag  (the  Volume  Write  Protect  flag) that is
41   |  associated with the media volume itself, so that write protection
42   |  status  can  be carried along with the volume as it is mounted on
43   |  different drives.
44   |  
45   |  Disks that meet  the  requirements  listed  above  satisfy  these
46   |  purposes  via  other  means,  so  they need not provide the first
47   |  block of  the  RCT.   Recording  a  block  block  replacement  in
48   |  progress   is   not  necessary  as  the  disk  uses  some  other,
49   |  non-standard scheme to handle bad blocks.  A write  protect  flag
50   |  that is carried along with the volume is provided by the hardware
51   |  write protect mechanism.  In the case of non-removeable media,  a
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-30
        4.11  Disk Geometry and Format                          08 Apr 82


 1   |  standard write protect switch on the drive satisfies this purpose
 2   |  since the volume cannot be moved.   In  the  case  of  removeable
 3   |  media,  a write protect mechanism based on mechanical deformation
 4   |  of the media is by definition associated with the volume, so this
 5   |  purpose is also satisfied.



 6      4.11.3  Logical Block Contents

 7      The host visible portion of each  logical  block  consists  of  a
 8      fixed  number  of data bytes.  The number of data bytes is either
 9      512 or 576, determined when the disk volume  is  formatted.   All
10      logical  blocks  on  a  disk  volume have the same number of data
11      bytes.

12      The data bytes are the only portion of logical  blocks  that  are
13      directly  host visible.  Certain other items, however, must be in
14      each logical block as their presence is implied by  various  MSCP
15      functions:

16           1.  Each block must contain a forced error indicator, so  as
17               to  properly  implement  and recognize the "Force Error"
18               command modifier.

19           2.  Each block must contain a bad block indicator,  so  that
20               references  to  bad blocks can be efficiently revectored
21               to the proper replacement blocks.  This  is  unnecessary
22               if  the controller does not use bad block replacement to
23               provide a "perfect" host area.

24   |  Note that the forced error indicator is fully distinct  from  the
25   |  512  or 576 bytes of data in each block.  Blocks written with the
26   |  "Force Error" command modifier must, when read back, return  both
27   |  correct  data and the presence of a forced error.  Blocks written
28   |  with forced errors must have similar error  rate  characteristics
29   |  as  blocks  written  normally,  without  forced errors.  A forced
30   |  error indicates that the host software writing the block did  not
31   |  have  fully  valid  data  to  write  into  that  block.  The disk
32   |  subsystem (controller and unit) must, however, preserve the  data
33   |  so as to avoid further data corruption.



34      4.11.4  Performance Implications

35      As stated above, the host area of  a  disk  is  structured  as  a
36      vector of logical blocks.  From a performance viewpoint, however,
37      it  is  more  appropriate  to  view  the  host  area  as  a  four
38      dimensional hyper-cube.  The four dimensions are cylinder, group,
39      track, and sector.  Thus, it is possible to decompose  a  logical
40      block  number  into  a  unique  quadruple of numbers;  namely the
41      block's cylinder number, group number, track number,  and  sector
42      number.  Cylinder number is most significant and sector number is
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-31
        4.11  Disk Geometry and Format                          08 Apr 82


 1      least significant.

 2      Alternatively, we can define a track as  consisting  of  a  fixed
 3      number  of  blocks,  a  group  as consisting of a fixed number of
 4      tracks, and a cylinder as consisting of a fixed number of groups.
 5      The position of a block within a track is the block's sector.

 6      The terms sector, track, and cylinder all come from the  geometry
 7      of   classical   disk   drives.   Groups  can  be  viewed  as  an
 8      optimization  for  short  seeks  whose  seek   time   is   easily
 9      predictable.

10      At any particular instant, the set of  logical  blocks  that  are
11      instantaneously accessible is those blocks in all tracks that are
12      in a particular sector, group, and cylinder.  In the  absence  of
13      transfers   to  a  different  group  or  cylinder,  this  set  of
14      instantaneously accessible blocks changes over  time  by  keeping
15      the  group  and  cylinder  constant while incrementing the sector
16      modulo the number of blocks/sectors in a track.  Referring to our
17      hyper-cube  analogy, the set of instantaneously accessible blocks
18      form a line parallel to the track axis.  This line moves parallel
19      to  the  sector axis, wrapping around when it reaches the edge of
20      the hyper-cube.  A disk therefore provides cyclic access  to  the
21      blocks in a particular group and cylinder.

22      This access structure to logical blocks implies that, to a  close
23      approximation,  the  track to which a block belongs has no effect
24      upon performance.  That is,  switching  tracks  within  the  same
25      group  and cylinder effectively requires zero time.  Two separate
26      transfers  in  the  same  group   and   cylinder   have   similar
27      performance,  regardless  of what tracks they are on.  To a first
28      order approximation, two separate transfers on successive sectors
29      of  different tracks in the same group and cylinder have the same
30      performance as a single, two sector (block) transfer.

31      Changing cylinders, however, does require  a  certain  amount  of
32      time.   The  amount  of  time  required  to  switch  between  two
33      cylinders is approximated by a monotonically increasing  function
34      of  the difference between the two cylinder numbers.  The time to
35      switch between cylinders is typically not affected by whether  or
36      not  groups  are  also being changed.  After switching cylinders,
37      the sector position of the disk (i.e., which sector's blocks  are
38      instantaneously accessible) is unpredictable.

39      Changing  groups  also  requires  a  certain  amount   of   time.
40      Generally, the time to switch between groups in the same cylinder
41      is no more than, and often less than, the time to switch  between
42      one  cylinder  and  the  next.   If cylinders and groups are both
43      changed  at  the  same  time,  the  time  to  switch  groups   is
44      effectively  zero,  as  it  is  included  in  the  time to switch
45      cylinders.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-32
        4.11  Disk Geometry and Format                          08 Apr 82


 1      When changing from one  group  to  the  next  (successive)  group
 2      within  the  same cylinder, the time required to switch groups is
 3      predictable.  Therefore the sector position following  completion
 4      of  the  group  switch  is also predictable, and transfers can be
 5      optimized across group boudaries.  If a transfer to sector  S  in
 6      group  G  is  followed  by  a  transfer  in group G+1 of the same
 7      cylinder, then sector S+1 (modulo the number of sectors/blocks in
 8      a  track) is the optimal sector for the new transfer and sector S
 9      is the maximally unoptimal sector for the new transfer.  The main
10      effect  of this is to optimize continuous (spiral) transfers that
11      cross group boundaries.

12      Note that what has been described herein is the  model  for  disk
13      logical  geometry,  which  may  have  a tenuous relationship to a
14      disk's actual physical geometry.  Disk designers should devise  a
15      logical to physical geometry mapping which optimizes the accuracy
16      of the model herein described.  This will generally  be  done  as
17      follows.   Head  or  track switches that effectively require zero
18      time (i.e., that require less than the inter-sector time) will be
19      reported  as  logical  MSCP  tracks.  Head or track switches that
20      require significant amounts of time  will  be  divided  into  two
21      classes:   those  that require only a little time (typically less
22      than one rotation) and whose time is predictable, and those  that
23      require  somewhat  more  time and/or a lot of time.  The switches
24      that require only a little time will be reported as logical  MSCP
25      groups.   The switches that require more time will be reported as
26      logical MSCP cylinders, where the switches should  be  mapped  to
27      cylinders  in  such  a  manner  as to minimize the amount of time
28      required to switch between cylinders that are  numerically  close
29      together.

30      The affect of  this  geometry  on  multi-block  transfers  is  as
31      follows.  A multi-block transfer requires a certain minimum time,
32      which is the time to transfer  one  block  or  sector  times  the
33      number  of  blocks  in  the  transfer.  Crossing track boundaries
34      requires no additional time.  Crossing a group boundary  requires
35      a  small,  relatively fixed additional amount of time.  This time
36      is typically less than the  time  to  transfer  an  entire  track
37      (i.e.,  less  than  one  rotation).  Crossing a cylinder boundary
38      requires a somewhat larger additional amount of time.  This  time
39      is typically at least the time to transfer an entire track (i.e.,
40      at least one rotation).

41      The affect of this  geometry  on  host  allocation  policies  for
42      random-access   files   is  as  follows.   Whenever  possible,  a
43      random-access file should be allocated within a single group.  If
44      this is not possible, the host should try to allocate it within a
45      single cylinder.  If this is also not possible, the  host  should
46      allocate it in the minimum number of adjacent cylinders.

47      When a block has a high probability of being accessed immediately
48      after another block, hosts should attempt to allocate both blocks
49      in the same group or, if  that  is  not  possible,  in  the  same
50      cylinder.   If  both  blocks  cannot be allocated within the same
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-33
        4.11  Disk Geometry and Format                          08 Apr 82


 1      cylinder, then they should be in  cylinders  that  are  as  close
 2      together as possible.

 3      Host's obtain the size of a unit's tracks, groups, and  cylinders
 4      from  the  GET  UNIT STATUS command's end message.  Some of these
 5      disk geometry concepts may not apply to all  disk  units.   Units
 6      report  the  fact  that a concept doesn't apply by specifying its
 7      size to be the same as the next larger concept.  For  example,  a
 8      disk  unit  that  doesn't have groups would specify one group per
 9      cylinder, implying that groups and cylinders are the  same  size.
10      Zero  should  be  supplied  for the cylinder size if the cylinder
11      concept is inappropriate to  a  disk  unit,  which  hosts  should
12      interpret  as the entire unit being a single cylinder.  The value
13      zero may equivalently be interpreted as specifying an arbitrarily
14      large   number  of  groups  per  cylinder.   This  may  propagate
15      downwards.  If both cylinders and groups are inappropriate to the
16      unit,  then  zero would be provided for both their sizes.  If the
17      model  of  cyclic  access  to  the  sectors   in   a   track   is
18      inappropriate,  then  the unit should typically specify one block
19      per track.

20      The following  examples  illustrate  how  inappropriate  concepts
21      should be specified:

22           1.  A "disk" implemented  as  a  pure  random-access  memory
23               (i.e.,  semiconductor  RAMs) would specify one block per
24               track (since cyclic access doesn't apply) and  zero  for
25               the  cylinder  and  group size (since the entire unit is
26               effectively a single group).

27           2.  A classical DECtape could be specified several ways, but
28               one  block per track, one track per group, and one group
29               per cylinder (i.e., each block is a  separate  cylinder)
30               is probably the most natural.

31           3.  A single loop shift register or delay line (such  as  an
32               ultrasonic delay line) would specify zero for the track,
33               group, and cylinder  size,  since  the  entire  unit  is
34               effectively a single track.


35      There is one exception to the above  discussion,  concerning  the
36      specification  of  track  size.  Track size, in addition to being
37      useful for performance prediction, is also used in the bad  block
38      replacement  algorithm specified in DEC Standard Disk Format.  It
39      is possible that  the  track  size  appropriate  for  performance
40      considerations  will be different from the track size required by
41      bad block replacement.  If this occurs, the track  size  required
42      by  bad  block  replacement must be specified, as the performance
43      effects are a secondary consideration.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-34
        4.11  Disk Geometry and Format                          08 Apr 82


 1      Note that all of this performance  oriented  disk  geometry  only
 2      applies  to  the host area of a disk unit.  The concepts need not
 3      apply to the Replacement and Caching Table (RCT)  and  any  other
 4      areas  of  a  disk,  as  access to those areas is not performance
 5      sensitive and/or not host visible.



 6      4.12  Bad Block Replacement

 7      Bad block replacement is a technique used with disk class devices
 8      to  present  each  unit  as  a single logically contiguous set of
 9      usable blocks.  See the preceding section  for  a  discussion  of
10      logical  blocks, replacement blocks, and a high level description
11      of bad block replacement.

12      Most bad blocks are detected when a disk volume is  manufactured.
13      These blocks are always replaced when the volume is formatted, as
14      are any other blocks that the formatter can  determine  are  bad.
15      Other  blocks  become bad during normal use, and must be replaced
16      dynamically.  MSCP is solely concerned  with  dynamic  bad  block
17      replacement.

18      A unit may operate in one of two modes:  Controller Initiated Bad
19      Block  Replacement  or  Host  Initiated Bad Block Replacement.  A
20      unit's mode is  determined  by  whether  or  not  the  controller
21      requires   hosts  assistance  in  performing  dynamic  bad  block
22      replacement for that unit.  Controller's report this to hosts via
23      the "Controller Initiated Bad Block Replacement" unit flag.

24      The controller  automatically  and  invisibly  replaces  all  bad
25      blocks if Controller Initiated Bad Block Replacement is used.  In
26      this mode the  controller  only  reports  bad  blocks  for  error
27      logging  purposes.   The  controller will reject both the REPLACE
28      command and all  host  write  accesses  to  the  Replacement  and
29      Caching Table (RCT).  This is necessary because the controller is
30      performing these functions and allowing  host  access  introduces
31      race conditions.

32      The host itself  must  perform  bad  block  replacement  if  Host
33      Initiated  Bad  Block  Replacement  is  used.   Usually,  but not
34      necessarily always, the host performs bad  block  replacement  in
35      response  to the controller reporting a bad block.  The algorithm
36      used to  perform  bad  block  replacement  is  described  in  DEC
37      Standard Disk Format.
38   |  
39   |  Controllers only report bad blocks (to hosts) in transfer command
40   |  end  messages.   (If  the  controller  is  performing  bad  block
41   |  replacement itselt, it  never  reports  bad  blocks  --  it  just
42   |  replaces  them).   This  is a direct consequence of the fact that
43   |  controllers  only  detect  bad  blocks  while   performing   disk
44   |  transfers.   They report bad blocks to hosts by means of the "Bad
45   |  Block Reported" end message flag.  If this flag is set, then  the
46   |  "First  Bad  Block" field in the end message is the logical block
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-35
        4.12  Bad Block Replacement                             08 Apr 82


 1   |  number of the first bad block (lowest block  number)  encountered
 2   |  by  the transfer.  A second flag, the "Bad Blocks Unreported" end
 3   |  message flag, may also be  set  to  indicate  that  multiple  bad
 4   |  blocks  were  encountered  by  the transfer, implying that one or
 5   |  more were not reported to the host.  After  replacing  the  first
 6   |  bad  block,  the host may (at its option) reissue the transfer to
 7   |  determine the next bad block, repeating this process until all of
 8   |  the  bad  blocks  are  replaced.   Given  the likely incidence of
 9   |  multiple bad blocks in a  transfer,  it  is  doubtful  that  this
10   |  yields any benefit.

11      When performing bad block replacement, the host must  access  and
12      update the unit's Replacement and Caching Table (RCT), inform the
13      controller that the block has been replaced, and  initialize  the
14      new  replacement  block.   The  host accesses and updates the RCT
15      using ordinary transfer operations, specifying  a  logical  block
16      number  in  the  range assigned to the RCT.  The host informs the
17      controller that the block has  been  replaced  with  the  REPLACE
18      command.  This command allows the controller to reformat the disk
19      to reflect the bad block replacement.  The new replacement  block
20      is  initialized  with  a normal WRITE command, specifying the bad
21      block's logical block  number,  after  the  REPLACE  command  has
22      completed.

23      While a bad block  replacement  operation  is  in  progress,  the
24      details of the replacement operation being performed are recorded
25      in a portion of the unit's Replacement and Caching  Table  (RCT).
26      The  information  recorded  includes  the  bad  block's  LBN, the
27      replacement block's RBN, and the data  to  be  written  into  the
28      block  at the conclusion of the replacement operation.  Recording
29      this information in the RCT  allows  the  bad  block  replacement
30      operation  to  be successfully completed in the event of a system
31      crash, power failure, or other interruption.  When the unit  next
32      becomes  "Unit-Online",  the host or the controller, whichever is
33      now performing bad block replacement,  must  check  the  RCT  and
34      complete  any replacement operation that was in progress.  At the
35      same time the host or the controller must  check  the  Write-back
36      Caching  in  Use  Flag and the Volume Write Protect flag and take
37      the actions described in Sections 4.13, "Write  Protection",  and
38      4.20, "Caching", if either is set.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-36
        4.13  Write Protection                                  08 Apr 82


 1      4.13  Write Protection

 2      There are several ways  that  a  unit  or  volume  may  be  write
 3      protected under MSCP:

 4      Hardware Write Protection

 5          The unit's write protect mechanism has been  activated  by  a
 6          user, causing the unit to be write protected.

 7      Volume Write Protection

 8          Either the "Volume Write Protect" flag is set in the volume's
 9          RCT  or  the  "Write-back  Caching in Use" flag is set in the
10          volume's RCT and the write-back cache  data  has  been  lost,
11          causing  the  unit  to  be  write  protected.   Volume  Write
12          Protection is only provided  by  controllers  that  implement
13          Controller  Initiated  Bad  Block Replacement, as it requires
14          manipulation of the RCT.  Note that a failed attempt  to  set
15          or  clear  Volume  Write Protection is a "serious exception".
16          Volume Write Protection is non-volatile;  since Volume  Write
17          Protect  status  is recorded on the volume itself, its status
18          will be maintained whenever  the  volume  is  dismounted  and
19          subsequently re-mounted.

20      Software Write Protection

21          The host has requested that  the  unit  be  write  protected.
22          Software  Write  Protection  is  used, by hosts, to implement
23          Volume Write Protection on controllers that do not  implement
24          Controller Initiated Bad Block Replacement.  Hosts enable and
25          disable Software Write Protection in  exactly  the  same  way
26          that  they  enable  and disable Volume Write Protection;  the
27          difference is whether or not it is recorded  on  the  volume,
28          and thus whether or not it is volatile.


29      Note that Volume Write Protection and Software  Write  Protection
30      are  mutually  exclusive;   controllers support either one or the
31      other, depending on whether  or  not  they  implement  Controller
32      Initiated Bad Block Replacement.

33      When Hardware Write Protection is established (i.e., when a  user
34      activates  the  unit's  write  protect mechanism), the controller
35      must provide a smooth transition  to  the  write  protect  state.
36      That  is,  the  controller  must  complete  all  write operations
37      (commands) that it has  already  initiated  on  the  unit  before
38      actually  prohibiting writes.  Note, however, that the controller
39      should immediately  reject  any  new  write  operations  that  it
40      receives  after  the  user  activates  the  unit's  write protect
41      mechanism.  Write operations that the controller received  before
42      the  write protect mechanism was activated, but that haven't been
43      initiated yet,  may  either  be  rejected  or  completed  at  the
44      controller's  option.   The  end  result  of  this  is  that each
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-37
        4.13  Write Protection                                  08 Apr 82


 1      individual write command or operation is either completed in  its
 2      entirety  or  else  rejected before any of its data is written to
 3      the unit.  Note that this issue  cannot  arise  with  Volume  and
 4      Software Write Protection, as they are established and cleared by
 5      sequential commands, which implies that no write  operations  can
 6      be outstanding.

 7      Note that it is not possible to establish or clear  Volume  Write
 8      Protection  when  a  unit  is  Hardware Write Protected, since it
 9      requires writing to the unit's RCT.  It is also not possible  for
10      either   the   controller  or  the  host  to  perform  bad  block
11      replacement when a unit is Hardware Write Protected.

12      A unit's Write Protect Status Display Mechanism must indicate the
13      "inclusive  or"  of  all forms of write protection.  That is, the
14      display must indicate that the unit is write protected both  when
15      it  is Hardware Write Protected and when it is Software or Volume
16      Write Protected.  In fact, this is one of the  main  purposes  of
17      Software  Write  Protection  --  it  allows the human engineering
18      aspects of the write protect  status  display  to  be  identical,
19      regardless  of  whether  the  controller  supports  Volume  Write
20      Protection or the host must emulate it.

21      Whenever a host brings a unit "Unit-Online", it  must  check  the
22      "Controller  Initiated  Bad  Block  Replacement"  unit  flag  and
23      emulate Volume Write Protection if the flag is clear.  This is in
24      addition  to  the  other  checks  it  must  make  for a partially
25      completed bad block replacement  operation.   See  Section  4.12,
26      "Bad  Block  Replacement".   If  the unit flag is clear, the host
27      must access the unit's RCT to check if either the  "Volume  Write
28      Protect"  flag  is set or if the "Write-back Caching in Use" flag
29      is set.  If either RCT flag is set, the host  should  immediately
30      (software) write protect the unit with a SET UNIT CHARACTERISTICS
31      command.  When a user or a higher level host process subsequently
32      decides  to  write  enable the volume, the Software Write Protect
33      status must be cleared with a SET  UNIT  CHARACTERISTICS  command
34      and the RCT accessed to clear the appropriate flag.  If the other
35      RCT flag is still set, the host must then issue another SET  UNIT
36      CHARACTERISTICS command to again Software Write Protect the unit.
37      See DEC Standard Disk Format for RCT access  algorithms  and  the
38      detailed format of these RCT flags.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-38
        4.14  Compare Operations                                08 Apr 82


 1      4.14  Compare Operations

 2      MSCP includes the following kinds of compare operations:

 3           1.  The COMPARE CONTROLLER DATA command.

 4           2.  The COMPARE HOST DATA command.

 5           3.  Read-compare operations, invoked by the "Compare  Reads"
 6               unit  flag  or  by  the  "compare"  modifier  on  a READ
 7               command.

 8           4.  Write-compare  operations,  invoked  by   the   "Compare
 9               Writes"  unit  flag  or  by  the "compare" modifier on a
10               WRITE command.

11      The operation of these different types of compare  operations  is
12      described  below.  Note that all of the compare operations report
13      the first difference or other error starting from  the  beginning
14      of  the  transfer.  Therefore the compare operation at the end of
15      the transfer may be aborted if a difference is discovered at  the
16      beginning.

17      The COMPARE CONTROLLER DATA command is used to  verify  that  all
18      copies  of  data that are managed by the controller and should be
19      identical are in fact identical.  This command does not  transfer
20      data to or from the host.

21      Multiple  copies  of  data  can  arise  in  two  ways,  with  two
22      corresponding uses for this command.  The first way that multiple
23      copies of data can arise is with shadow sets -- all active  units
24      of  a  shadow  set  should  contain identical data.  This command
25      provides an efficient way to determine whether or not  the  units
26      of  a shadow set are in fact identical.  Note that "efficient" is
27      a relative term -- comparing two entire  disks  for  equality  is
28      still  a  lengthy and expensive operation.  Note also that shadow
29      set differences  typically  result  from  use  of  the  "suppress
30      shadowing"  command  modifier  or  from  crashes in the middle of
31      write operations.

32      The second way that multiple copies of data  can  arise  is  from
33      caching  --  data will be duplicated both in the cache and on the
34      underlying units.  This command provides a way of verifying  that
35      the  data  in  the cache does in fact match the data on the unit.
36      Note that there is no way for a  host  to  cause  cache  data  to
37      differ  from  that  on  the  underlying  unit, except for pending
38      write-back data which is taken  into  account  by  this  command.
39      Therefore  all  cache  data differences are controller errors and
40      are reported as such.

41      The COMPARE HOST DATA command is used to verify that data in host
42      memory  matches  data  on  a unit.  The data is obtained from the
43      unit or shadow set in the  manner  that  is  most  convenient  or
44      efficient  for  the  controller.   The  data is obtained from the
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-39
        4.14  Compare Operations                                08 Apr 82


 1      cache if possible.  In this respect the COMPARE HOST DATA command
 2      operates identically to a READ command.  Unlike the READ command,
 3      the data is not transferred to host  memory.   Instead,  data  is
 4      obtained  from host memory and compared against the data obtained
 5      from the unit, shadow set, or  cache.   Upon  completion  of  the
 6      command  the controller reports whether the data was identical or
 7   |  different.  The data being different is reported  as  a  "Compare
 8   |  Error"  in  the  command's  end message.  No error log message is
 9   |  generated as this is not considered to be a  "significant"  error
10   |  (since  it  can  be  deliberately  caused by user programs).  The
11   |  controller may attempt retries or not  at  its  option.   As  the
12   |  retries  will always fail (assuming the host is not modifying the
13   |  buffer while the transfer is in progress), retries  will  have  a
14   |  deleterious  effect  on performance but will in no way affect the
15   |  final outcome of the operation.

16      Read-compare and write-compare operations are  performed  at  the
17      conclusion  of  the  appropriate transfer commands to verify that
18      the data was correctly transferred and that the data can  now  be
19      obtained  from its destination.  The general algorithm used is to
20      obtain the data from its destination and compare it  against  the
21      data re-obtained from its source.

22      If the transfer had multiple destinations, then each of them must
23      be  compared  against  the  source  or  else one must be compared
24      against  the  source  and  the   rest   compared   against   that
25      destination.   The data may be re-obtained from its source in the
26      manner that is most convenient or efficient for  the  controller.
27      In  particular, if the data has several potential sources (shadow
28      units or cache), then  the  controller  may  re-obtain  the  data
29      either  from  the same source as the original transfer or from an
30      alternate  source.   The  only  other  requirement  is  that  the
31      controller   should,   to  the  maximum  extent  allowed  by  its
32      architecture, operate all data transfer  paths  in  the  opposite
33      direction  from  that  of  the  original  transfer,  in  order to
34      maximize the probability of detecting a transfer error.

35      The read-compare operation is relatively  straightforward,  since
36      host  memory  is  the  only destination of the original transfer.
37      The data is re-obtained from the unit, shadow set, or  cache  and
38      compared  against  the  data  obtained  from  host  memory.  This
39      operation is effectively  identical  to  that  performed  by  the
40      COMPARE HOST DATA command, except for possible differences due to
41      operating data transfer paths in the opposite direction from  the
42      original  READ.   Ideally,  to  operate all transfer paths in the
43      opposite direction, the controller would obtain the data from the
44      host  and  send  it  to  the  drive, and the drive would actually
45      compare the data against the  original.   In  practice,  such  an
46      implementation  is infeasible, as the controller must perform the
47      actual compare function.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-40
        4.14  Compare Operations                                08 Apr 82


 1      The write-compare operation is  somewhat  more  complex,  as  the
 2      transfer  may  have multiple destinations.  Possible destinations
 3      include the cache and the other units of a shadow set as well  as
 4      the  unit  referenced by the command.  The controller must obtain
 5      the data from each destination and compare it  against  the  data
 6      re-obtained  from  host  memory.  At least one destination's data
 7      must actually be compared against the data re-obtained from  host
 8      memory.   Other destinations' data may be compared against either
 9      the data re-obtained from host memory or  against  data  obtained
10      from  a  destination  that has already been compared against host
11      memory.  The write-compare operation is similar to that performed
12      by  the  COMPARE  CONTROLLER  DATA and COMPARE HOST DATA commands
13      issued together, especially if the "suppress  shadowing"  command
14      modifier  was  not  specified.  The only differences, if any, are
15      those due to  operating  data  transfer  paths  in  the  opposite
16      direction  from  the  original transfer.  Ideally, to operate all
17      transfer paths in the opposite direction, the data should be sent
18      to  the  host  port, which would actually perform the comparison.
19      In  practice,  no  communications  mechanism  will  provide  such
20      capability, so that the comparisons will always take place in the
21      controller.

22      If  a  read-compare  or  write-compare   operation   fails,   the
23      controller  must  interpret  this  as  implying that the original
24      transfer failed and retry the original transfer  if  appropriate.
25      If  the  controller successfully obtains the data from its source
26      and destination, but the data is different, then  the  controller
27      must  retry the original transfer and report the compare error in
28      an error log message.   If  the  controller  cannot  successfully
29      obtain  the  data from its destination, but the error is one that
30      may be eliminated by re-writing the data to the destination, then
31      the  controller  must also retry the original transfer and report
32      the  error  (from  the  attempt  to  obtain  the  data  from  its
33      destination)  in an error log message.  All other errors need not
34      be retried, but must be reported in an error  log  message.   The
35      only  exception  to the above is commands that have the "Suppress
36      Error Recovery" modifier set.  The controller may or may not,  at
37      the controller's option, retry the original transfer if a compare
38      error occurs in such a command.

39      For example, "Data Errors", such as an uncorrectable  ECC  error,
40      must  be  retried  on write-compare operations.  They need not be
41      retried on read-compare operations, since an unrecoverable  "Data
42      Error"  implies that the READ itself will fail.  "Compare Errors"
43      must always be  retried.   Note  that  the  controller  need  not
44      discriminate  among  types  of  errors -- it may always retry all
45      errors   during   read-compare   or   write-compare   operations,
46      regardless  of whether or not the error will inhibit the original
47      transfer.

48      The number of retries required for read-compare and write-compare
49      operations  is  controller  dependent.   However, all controllers
50      must retry such operations at least once.  The  exact  number  of
51      retries  that  a  controller implements should be chosen based on
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-41
        4.14  Compare Operations                                08 Apr 82


 1      undetected error rate characteristics.  The controller may either
 2      retry  the  entire  transfer, or else only retry the portion that
 3      includes the error.



 4      4.15  Multi-Unit Drives and Formatters

 5      A multi-unit drive is a single physical disk drive  that  appears
 6      as  several  independent  units  to  hosts.  So-called fixed plus
 7      removable disk drives, providing one removable disk unit and  one
 8      non-removable   disk   unit,  are  the  most  common  example  of
 9      multi-unit drives.  A multi-unit formatter is  a  single  set  of
10      interface   or   read/write  electronics  that  connects  several
11      otherwise   independent   units   to   controllers.    Multi-unit
12      formatters  are  most  commonly  used  with tape drives, although
13      there is nothing that prevents their  use  with  disk  drives  as
14      well.

15      All the units of a multi-unit drive or formatter share  a  single
16      access  path  to controllers.  This implies that all of the units
17      must be "connected" to the same controller.   In  particular,  if
18      one  unit of a multi-unit drive or formatter is "Unit-Online" via
19      a controller, then all the other units of the multi-unit drive or
20      formatter may only be accessed by that same controller.  That is,
21      the other units are  "Unit-Offline"  to  all  other  controllers.
22      Awareness   of   this   characteristic   is   critical  for  high
23      availability systems -- if a failed operation on  a  multi-access
24      unit  is  to  be  retried via another controller, and the unit is
25      part of a multi-unit drive or formatter, then all  units  of  the
26      drive or formatter must be switched to the other controller.

27      Some units of  a  multi-unit  disk  drive  may  share  mechanical
28      components as well as interface electronics.  Such units are said
29      to share a spindle.  That  is,  the  units  must  either  be  all
30      spinning or all not spinning, just as if the units shared a drive
31      motor or spindle (which they typically will).   Such  units  must
32      also  share  a  single  Run/Stop  switch,  since  they are always
33      spun-up and spun-down together.  Hosts  must  also  be  aware  of
34      units  which  share  a  spindle,  as  dismounting  one  such unit
35      requires that all units sharing the same spindle be spun-down.

36      The units of a multi-unit drive or formatter  are  identified  by
37      the  "multi-unit  code"  unit characteristic field.  Hosts obtain
38      this two byte field via the AVAILABLE attention message or in the
39      end   message   of  a  GET  UNIT  STATUS,  ONLINE,  or  SET  UNIT
40      CHARACTERISTICS command.  The low byte of this field  contains  a
41      controller  dependent  encoding  of  the  access path between the
42      controller and the drive.  The high byte of this field contains a
43      controller  dependent  encoding  of  the spindle, on a particular
44      access path,  that  the  unit  uses.   Controllers  may  use  any
45      encoding  whatsoever,  provided  that  each  access path and each
46      spindle (within an access path) has a unique  value.   Note  that
47      the  access path byte is implicitly qualified by the controller's
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-42
        4.15  Multi-Unit Drives and Formatters                  08 Apr 82


 1      or  MSCP  server's  identity,  and  that  the  spindle  byte   is
 2      implicitly qualified by the access path.

 3      Hosts use the "multi-unit code" field as follows.   When  a  host
 4      decides  to  spin-down  a unit, it scans all other units that are
 5      "Unit-Online" via the same MSCP  server  for  those  units  whose
 6      entire  "multi-unit  code"  field  (both  bytes) matches the unit
 7      being spun-down.  Such units, if any, share a  spindle  or  other
 8      mechanical components with the unit being spun-down, so that they
 9      must be spun-down together.  When a host decides to access a unit
10      via  a  different  controller,  it scans all other units that are
11      "Unit-Online" via the same MSCP server for those units whose  low
12      byte  of  the  "multi-unit  code"  field  matches  the unit being
13      switched.  Such units, if any, share an access path with the unit
14      being  switched,  so  that  they must also be switched to the new
15      controller.

16      Note that the low byte of the "multi-unit code" field (the access
17      path)  is meaningless for units that are inherently restricted to
18      a single controller.  Controllers may return any fixed  value  as
19      the access path encoding for such units, provided that it doesn't
20      duplicate the value returned for any units on the same controller
21      that are not inherently restricted to a single controller.

22      This use and format of the "multi-unit code"  field  implies  the
23      following architectural restrictions on all controllers:

24           1.  All units that  share  a  spindle  or  other  mechanical
25               components  must  also  share an access path.  Note that
26               this is an essential restriction for multi-unit  drives,
27               regardless  of  how  shared components are communicated.
28               If units that share a spindle did not  share  an  access
29               path,  then  they  could be simultaneously "Unit-Online"
30               via  different  controllers,  making  it  impossible  to
31               coordinate a simultaneous spin-down.

32           2.  There is a maximum of 256 access paths  per  controller.
33               In  the absence of multi-unit drives or formatters, this
34               implies a maximum of 256 units per controller.

35           3.  There is a maximum of 256 spindles per access path.   In
36               the  absence  of shared spindles, this implies a maximum
37               of 256 units per access path or formatter.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-43
        4.16  Controller and Unit Identifiers                   08 Apr 82


 1      4.16  Controller and Unit Identifiers

 2      MSCP  requires  that  all  controllers  and  drives  have  unique
 3      identifiers,  called controller identifiers and unit identifiers.
 4      The structure of these identifiers is as follows:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |      unique device number     |
 8                      +-------+-------+               +
 9                      | class | model |               |
10                      +-------+-------+---------------+

11      The  "class"  byte  identifies  the  type  of  the  subsystem  --
12      controller,  disk  drive,  etc.   The "model" byte identifies the
13      exact model of the subsystem within its class.  All  valid  class
14      and model codes are non-zero, implying that all valid identifiers
15      are non-zero.  The "unique device  number"  field  must  uniquely
16      identify  the  device  among  all  devices of that same class and
17      model.  The device serial number could be  used  as  the  "unique
18      device  number", although that isn't required.  Currently defined
19      values for the "class" and "model" bytes are listed  in  Appendix
20      C.  Values for new devices must be added to that appendix, via an
21      ECO to this specification, as new products are  developed.   Note
22      that  different  units  of multi-unit drives are distinguished by
23      having different "model" bytes;  the "class" and  "unique  device
24      number"  fields are typically identical.  Note also that all MSCP
25      servers for the same device class within the same controller must
26      return the same controller identifier.

27      As previously stated, MSCP  requires  that  controller  and  unit
28      identifiers  be  unique  across  all devices accessible via MSCP.
29      This clearly cannot be checked by controllers.  Controllers  can,
30      however,  enforce  unique  unit identifiers across the units that
31      are attached to themselves.  This is  done  using  the  following
32      algorithms:

33           1.  Controllers should detect and respond to duplicate  unit
34               identifiers  across all units whose unit identifiers the
35               controller can obtain, including all  units  that  would
36               otherwise    be   "Unit-Online"   or   "Unit-Available".
37               Detection of a duplicate unit identifier on one unit  of
38               a  multi-unit  drive  is  treated  as  a  duplicate unit
39               identifier condition on all other units that  share  one
40               or more of the following components with the unit having
41               the duplicate unit identifier:

42               a.  A unit number select mechanism.

43               b.  A Run/Stop or Load/Unload switch.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-44
        4.16  Controller and Unit Identifiers                   08 Apr 82


 1               c.  A spindle or other mechanical components.

 2               Note  that  duplicate  unit  identifiers  are   detected
 3               regardless   of  the  state  of  a  unit's  Run/Stop  or
 4               Load/Unload switch.

 5           2.  Whenever a controller becomes aware of a duplicate  unit
 6               identifier, it immediately spins-down all units with the
 7               duplicate  identifier  and   forces   them   to   remain
 8               spun-down.    The   controller   spins-down   the  units
 9               regardless  of  their  current  state.   The  controller
10               typically  forces  them  to remain spun-down by spinning
11               them down again whenever an operator spins them up.

12           3.  The controller  returns  "Unit-Offline"  with  sub-state
13               "inoperative"  as the state for all units with duplicate
14               unit  identifiers.   In  addition,  if  the  unit  might
15               potentially  be  connected  to  another  controller, the
16               controller should flag the  presence  of  the  duplicate
17               unit  identifier  in  the  drive.  Other controllers, if
18               any, must check this flag and also  treat  the  unit  as
19               "Unit-Offline" if the flag is set.

20   |  Whether or not a controller does in fact check for duplicate unit
21   |  identifiers  is controller dependent.  Note that a duplicate unit
22      identifier is a drastic failure,  indicative  of  some  otherwise
23      undiagnosed hardware malfunction.



24      4.17  Media Type Identifiers

25      Controllers  return  a  media  type  identifier  for  each   unit
26      accessible  via  that  controller.   This  identifier encodes two
27      pieces of information:

28           1.  The preferred device type name for use  with  the  unit.
29               These  two alphabetic characters are conventionally used
30               with the unit number and a controller designator as  the
31               fully qualified operating system identifer for the unit.

32           2.  The name (product name) of the media used on  the  unit.
33               This  name  should  be printed on the unit's front panel
34               and on all removable media that may  be  used  with  the
35               unit.

36      The primary reason for returning this information is to  simplify
37      operating system support for generic device allocation.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Algorithms and Usage Rules                              Page 4-45
        4.17  Media Type Identifiers                            08 Apr 82


 1      The media type identifier returned via MSCP is a 32 bit  quantity
 2      encoded as follows:

 3                      31   26   21   16   11  7 6    0 
 4                      +----+----+----+----+----+------+
 5                      | D0 | D1 | A0 | A1 | A2 |   N  |
 6                      +----+----+----+----+----+------+

 7      where the fields are as follows:

 8      D0
 9      D1  The preferred device type name for the unit.  D0 and  D1  are
10          five bit fields, each encoding one alphabetic character.  "A"
11          is encoded with the value 1, "B" with the value 2,  etc.   D0
12          encodes  the  left  character of the device type name, D1 the
13          right character.

14      A0
15      A1
16      A2
17      N   The name of the media used on the unit.  A0  through  A2  are
18          five  bit  fields,  each  encoding an alphabetic character or
19          null.  "A" is encoded with the value 1, "B" with the value 2,
20          etc.   Zero  represents a null or the absence of a character.
21          One to three characters of the media name are  encoded,  left
22          justified,  in  A0  through  A2.   N  is  a  seven  bit field
23          containing the value of two decimal digits.

24      Note that the encoding of the media name assumes  that  the  name
25      consists  of one, two, or three alphabetic characters followed by
26      exactly two digits (i.e., ann, aann, or  aaann).   MSCP  requires
27      that  the  product  names  for all mass storage devices adhere to
28      this format.

29      Currently defined device type and media  names  (i.e.,  currently
30      defined  media  type identifier values) are listed in Appendix C.
31      Names or values for new devices must be added to  that  appendix,
32      via an ECO to this specification.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 5

 2                        MSCP CONTROL MESSAGE FORMATS



 3      5.1  Generic Control Message Format

 4      All MSCP control messages consist of a 12 byte header  and  a  36
 5      byte  or shorter parameter area.  The device class (disk or tape)
 6      does not appear in the control message.  It  is  implied  by  the
 7      connection  or  MSCP server to which the control message is sent.
 8      Multi-byte numbers are stored least significant byte first (i.e.,
 9      using the standard VAX number formats).  Messages are laid out as
10      follows:

11                      31                             0 
12                      +-------------------------------+
13                      |   command reference number    |
14                      +---------------+---------------+
15                      |   reserved    |  unit number  |
16                      +---------------+-------+-------+
17                      |  modifiers or status  | opcode|
18                      +-----------------------+-------+
19                      |                               |
20                      /          parameters           /
21                      /                               /
22                      |                               |
23                      +-------------------------------+

24      The length of  the  parameter  area  varies  depending  upon  the
25      opcode.

26      The communications mechanism conveys both the text of  a  message
27      and  its  length.   The  receiver of a message uses the length to
28      verify that all required parameters are in fact present.

29      The communications mechanism may restrict the  allowable  message
30      lengths.   For example, it might require that all messages have a
31      fixed length of 48 bytes or that the length be an  even  multiple
32      of  4 bytes.  For this reason the message lengths defined by MSCP
33      are minimum lengths.  Senders may pad messages  as  necessary  to
34      meet  communications mechanism length restrictions.  The contents
35   |  of the padding (that is, the contents of any data past the end of
36   |  the message formats shown in this document) are reserved and must
37      follow the rules for reserved fields  defined  in  the  following
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-2
        5.1  Generic Control Message Format                     08 Apr 82


 1   |  section.  (I.e., such padding must contain zeros).

 2      The fields in the message header are interpreted as follows:

 3      command reference number

 4          A 32 bit, unique,  non-zero  number  used  to  identify  host
 5          commands.   Class  drivers  should  supply a unique reference
 6          number in each command that they send to an MSCP server.  The
 7          MSCP  server copies the reference number to the command's end
 8          message and to all error log messages  that  relate  to  that
 9          specific  command.   The  MSCP  server  supplies  a reference
10          number of  zero  in  attention  messages  and  in  error  log
11          messages  that  do  not relate to a specific host command.  A
12          class driver may supply a zero reference number  if  it  does
13          not need to associate a command with its end message.

14          Command reference numbers must be unique across all  commands
15          that are outstanding on the same connection.  I.e., they must
16          be unique across all outstanding commands issued by a  single
17          class  driver  (host)  to  a  single  MSCP server.  The class
18          driver may re-use  a  command's  reference  number  when  the
19          command is no longer outstanding -- i.e., after receiving the
20          command's end message or after re-synchronizing with the MSCP
21          server.   Command  reference  numbers  need not be unique for
22          commands issued by different class drivers -- i.e.,  commands
23          issued  by  different  hosts  or  commands for different MSCP
24          servers from  the  same  host.   Therefore  controllers  must
25          internally  use the combination of a command reference number
26          and the connection on which the command was received  as  the
27          unique identifier of an outstanding command.
28   |  
29   |      Command reference numbers are not interpreted in any  way  by
30   |      MSCP   servers.    Their  purpose  is  to  provide  a  unique
31   |      identifier by which class drivers can  name  commands.   They
32   |      are used by class drivers to match end messages and error log
33   |      messages  with  the  corresponding  command  message  and  to
34   |      identify  the  object  of  an  ABORT  or  GET  COMMAND STATUS
35   |      command.

36      unit number

37          Identifies the specific unit within the device class to which
38          the  message applies.  This value is the binary equivalent of
39          the  decimal  unit  number  displayed  by  the  unit   select
40          mechanism.

41      opcode

42          Identifies  the  meaning  or  purpose  of  the  message.   In
43          messages  sent  from  a  class driver to an MSCP server, this
44          field specifies the operation or command to be performed.  In
45          messages  sent  from the controller to the class driver, this
46          field  specifies  whether  this  is  an  end  message  or  an
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-3
        5.1  Generic Control Message Format                     08 Apr 82


 1          attention  message.   The  opcode  of  an  end  message  also
 2          identifies the type (opcode) of the command to which the  end
 3          message corresponds.  A message's opcode implicitly specifies
 4          the  length  and  format  of  the  message,   including   the
 5          interpretation of any parameters that are present.

 6      modifiers or status

 7          This field has different formats in command messages and  end
 8          messages,  and is reserved in attention messages.  In command
 9          messages this field has the following format:

10                      31            16 15    8 7     0 
11                      +---------------+-------+-------+
12                      |   modifiers   | rsvd  | opcode|
13                      +---------------+-------+-------+

14          The "modifiers" field contains  bit  flags  that  modify  the
15          operation identified by "opcode", or zero if no modifiers are
16          specified.

17          In end messages this field has the following format:

18                      31            16 15    8 7     0 
19                      +---------------+-------+-------+
20                      |    status     | flags |endcode|
21                      +---------------+-------+-------+

22          The "status" field identifies the completion  status  of  the
23          command.   The  "flags"  field contains bit flags, called end
24          flags, that report certain conditions that are disjoint  from
25          normal  completion  status  of  a  command.  These fields are
26          further described in Sections 5.5, "End Message Format",  and
27          5.6, "Status Codes".



28      5.2  Reserved and Undefined Fields

29   |  Reserved fields are those fields that are intended  for  possible
30   |  future  extensions  to  MSCP.  The use of such fields must follow
31   |  certain rules, in order to ensure that such future extensions can
32   |  be  upwards  compatible  with  the  current  version of MSCP.  In
33   |  general, the sender of a message must supply the  value  zero  in
34   |  all  reserved  fields.  The action for a message receiver varies,
35   |  and is discussed below.
36   |  
37   |  An undefined field is just that -- its  contents  are  controller
38   |  implementation  dependent,  and  therefore  cannot be used in any
39   |  meaningful way by class drivers.  Undefined fields  are  provided
40   |  in  order  to  simplify controller implementation.  Class drivers
41   |  must ignore the contents of undefined fields.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-4
        5.2  Reserved and Undefined Fields                      08 Apr 82


 1      A field, as used in this discussion, may  have  any  length.   In
 2      particular,  it  may be an individual bit of a flags word or byte
 3      as well as an entire byte, word, or whatever.

 4      Class drivers must supply the value zero in the  reserved  fields
 5      of  all  messages  (commands) that they send to a controller, and
 6      must also ignore the contents  of  reserved  fields  in  all  the
 7      messages   (end  messages,  attention  messages,  and  error  log
 8      messages) that they receive from an MSCP  server.   MSCP  servers
 9      must supply the value zero in the reserved fields of all messages
10      (end messages, attention messages, and error log  messages)  that
11      they  send to class drivers.  MSCP servers must either ignore the
12      contents of reserved fields in the messages (commands) that  they
13      receive  from class drivers or verify that the contents are zero.
14      The command is treated as invalid if the contents  are  non-zero.
15      Whether  or  not an MSCP server verifies that reserved fields are
16      zero is controller dependent, and need not be consistent for  all
17      reserved fields.
18   |  
19   |  Many  controllers  generate  command  end  messages   by   simply
20   |  modifying   the   commands'   command  messages.   That  is,  the
21   |  controller copies a command  message  into  an  internal  buffer,
22   |  modifies  it in place during execution of the command, then sends
23   |  the resulting contents of the internal buffer  as  the  command's
24   |  end message.  To simplify such an implementation, controllers may
25   |  merely  "echo"  command  message   reserved   fields   when   the
26   |  corresponding  field  in  the  end  message should be zero.  More
27   |  precisely, if some field in the end message of a  command  should
28   |  be  zero,  and  the  corresponding  (same  position) field in the
29   |  command's command message is a reserved field, the controller may
30   |  copy  the  reserved  field  from  the  command message to the end
31   |  message rather than explicitly  zeroing  the  field  in  the  end
32   |  message.
33   |  
34   |  The above paragraphs have listed all of the allowable  controller
35   |  actions  when  a  controller  receives  a  command message with a
36   |  non-zero value in a reserved field.  That is, when  a  controller
37   |  receives  a  command  message with a non-zero value in a reserved
38   |  field it must do one of the following:
39   |  
40   |       1.  Reject the command as  invalid  and  return  an  Invalid
41   |           Command end message.
42   |  
43   |       2.  Totally ignore the non-zero  contents  of  the  reserved
44   |           field.   That  is, the command's execution, results, and
45   |           end message  contents  are  totally  unaffected  by  the
46   |           non-zero value.
47   |  
48   |       3.  If the corresponding field in  the  end  message  should
49   |           have  a  zero  value,  echo the contents of the reserved
50   |           field in the command message as the value of  the  field
51   |           in  the  end  message.  In all other ways totally ignore
52   |           the non-zero contents of the reserved field.   That  is,
53   |           the  command's  execution,  results, and the contents of
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-5
        5.2  Reserved and Undefined Fields                      08 Apr 82


 1   |           all  other  fields  in  the  end  message  are   totally
 2   |           unaffected by the non-zero value.
 3   |  
 4   |  Note that option 3 is primarily of use when a field  is  reserved
 5   |  in both command and end messages.
 6   |  
 7   |  It is recommended, although not required,  that  which  of  these
 8   |  options   a   controller  implements  be  based  on  whether  the
 9   |  controller's functionality is hard (ROM based) or soft  (loadable
10   |  microcode,  implying  it is easily altered).  The purpose of this
11   |  is to provide the maximum degree  of  error  checking  consistent
12   |  with  ease  of  future  extensions  to  MSCP.   Controllers whose
13   |  functionality  is  soft  or  relatively  easy  to  alter   should
14   |  implement  option  1,  verifying that reserved fields are in fact
15   |  zero.  Controllers whose functionality is hard  or  difficult  to
16   |  alter  should implement option 3 when the corresponding fields in
17   |  command and end messages are both reserved and option  2  in  all
18   |  other cases.
19   |  
20   |  Note that  controllers  must  implement  option  1  whenever  the
21   |  internal  functioning  of  the  controller  may  be  altered if a
22   |  reserved field contains a non-zero value.



23      5.3  Transfer Command Message Format

24      Although the parameters and  their  layout  is  command  (opcode)
25      dependent,  many  commands  perform  data  transfers and thus use
26      similar sets of  parameters.   Therefore  data  transfer  related
27      parameters are always laid out as follows:

28                      31                             0 
29                      +-------------------------------+
30                      |   command reference number    |
31                      +---------------+---------------+
32                      |   reserved    |  unit number  |
33                      +---------------+-------+-------+
34                      |   modifiers   | rsvd  | opcode|
35                      +---------------+-------+-------+
36                      |          byte count           |
37                      +-------------------------------+
38                      |                               |
39                      +---         buffer          ---+
40                      |                               |
41                      +---       descriptor        ---+
42                      |                               |
43                      +-------------------------------+
44                      |      logical block number     |
45                      +-------------------------------+
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-6
        5.3  Transfer Command Message Format                    08 Apr 82


 1      These parameters are interpreted as follows:

 2      byte count

 3          The total requested length of the  data  transfer  in  bytes.
 4          For  tape  class  devices, the "byte count" must be between a
 5          tape format dependent minimum and  maximum  block  size.   An
 6          "Invalid  Command"  status  code with an "Invalid Byte Count"
 7          sub-code is returned  if  the  "byte  count"  violates  these
 8          restrictions.   For disk class devices, the "byte count" must
 9          meet the requirements described in the next paragraph.

10          If the "logical block  number"  field  identifies  a  logical
11          block in the host area of the disk volume (i.e., the "logical
12          block number" is less than the "unit size"  returned  in  the
13          ONLINE  and  SET UNIT CHARACTERISTICS end messages), then the
14          "byte count" must be less than  or  equal  to  the  following
15          maximum byte count:

16               ( unit size - logical block number ) * block size

17          where "unit size" is the unit's host area size  (returned  in
18          the  ONLINE  and  SET  UNIT  CHARACTERISTICS  end  messages),
19          "logical block number" is the contents of the "logical  block
20          number" field in the command message, and "block size" is the
21          volume's block size, either 512 or 576 bytes.  The controller
22          or  MSCP server must check that the "byte count" is less than
23          or equal to the above maximum.  That is,  the  controller  or
24          MSCP  server  must  reject  or terminate any transfer command
25          that begins in the host area of a disk volume and attempts to
26          continue  into  the  volume's  Replacement  and Caching Table
27          (RCT).  An "Invalid Command" status  code  with  an  "Invalid
28          Byte  Count" sub-code must be returned if this restriction is
29          violated.

30          If the "logical block  number"  field  identifies  a  logical
31          block  in  the  disk  volume's  Replacement and Caching Table
32          (RCT) (i.e., the "logical block number" is  greater  than  or
33          equal  to the "unit size" returned in the ONLINE and SET UNIT
34          CHARACTERISTICS end messages), then the "byte count" must  be
35          exactly  the  block  size  (either  512  or 576 bytes).  If a
36          different "byte count" value is provided, the controller  may
37          either  perform  the transfer with the specified "byte count"
38          or else return an  "Invalid  Command"  status  code  with  an
39          "Invalid Byte Count" sub-code.

40          For all disk and tape transfer commands that contain  "buffer
41          descriptors"  (i.e.,  all transfer commands except ACCESS and
42          ERASE), the "byte count" must also be less than or  equal  to
43          the  size  of  the  buffer identified by "buffer descriptor".
44          Note that "buffer descriptor",  and  thus  the  size  of  the
45          buffer,  is  inherently  communications  mechanism dependent.
46          The size of a buffer is not necessarily available to the MSCP
47          server  until  it  attempts  to  transfer past the end of the
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-7
        5.3  Transfer Command Message Format                    08 Apr 82


 1          buffer.  A "Host Buffer Access Error" status code is returned
 2          if  the  "byte count" exceeds the length of the buffer.  Note
 3          that such errors are  not  necessarily  distinguishable  from
 4          other causes of "Host Buffer Access Errors".

 5          For  disk  transfer  commands   only,   some   communications
 6          mechanisms  may  prohibit odd "byte count" values.  Odd "byte
 7          count" values must be allowed in tape transfer  commands.   A
 8          "Host  Buffer  Access  Error"  status code is returned if the
 9          "byte count" is an illegal odd byte count.

10          "Byte count" values that exceed any  of  the  maximum  values
11          described above may be detected either before the transfer is
12          initiated or when the transfer attempts to cross the boundary
13          from  legal  to  invalid byte counts.  If detected before the
14          transfer is initiated (the transfer is  rejected),  the  MSCP
15          server must not transfer any data and must return zero in the
16          "byte count" field of the end message.  If detected when  the
17          transfer  attempts  to  cross  the  boundary (the transfer is
18          terminated), the MSCP server must transfer all data up to the
19          maximum  legal  byte  count and return the maximum legal byte
20          count in the "byte count" field of  the  end  message.   Data
21          must  not  be  transferred past the maximum legal byte count.
22          Which algorithm an MSCP server uses for detecting byte counts
23          that are too large is controller dependent.

24      buffer descriptor

25          Communication mechanism dependent identification of the  host
26          buffer to use for the data transfer.  The information encoded
27          in this 12 byte (96 bit) field includes:

28           o  A host identifier (port or node identification).

29           o  The name of a buffer on the host.

30          Note that the inclusion of a host identifier allows for third
31          party  transfers.   The  buffer  descriptor  formats  used by
32          various communication mechanisms are listed in Appendix D.

33      logical block number

34          Not present in tape  transfer  commands.   In  disk  transfer
35          commands,  the  logical  block  number (position) on the disk
36          volume at which to start the data transfer.  This value  must
37          not identify a block past the end of the volume's Replacement
38          and Caching Table (RCT).  Section 4.11,  "Disk  Geometry  and
39          Format",  describes  the  mapping of logical block numbers to
40          disk volume regions.  If the command is a write operation and
41          the  controller  is  performing  bad  block replacement, this
42          value also must not identify  a  block  within  the  volume's
43          Replacement and Caching Table.  Any of these errors cause the
44          command to be rejected with an "Invalid Command" status  code
45          and an "Invalid Logical Block Number" sub-code.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-8
        5.4  Command Modifiers                                  08 Apr 82


 1      5.4  Command Modifiers

 2      The  allowable  modifiers  on  a  command  are  command  (opcode)
 3      dependent.    The   individual   command  descriptions  list  the
 4      allowable modifiers for each command.  All modifiers that are not
 5      explicitly  allowed  for  a  command  are  reserved,  and must be
 6      treated in accordance with the requirements for  reserved  fields
 7      described  in  Section  5.2,  "Reserved  and  Undefined  Fields".
 8      Modifiers that are only allowed on one command are  described  in
 9      that  command's  description.   Modifiers that are common to many
10      commands are described below:

11      Clear Serious Exception

12          Clears the "serious exception"  condition  on  the  specified
13          unit or shadow set.  Ignored if there is no serious exception
14          condition in effect.  See Section 4.8, "Serious Exceptions".

15      Compare

16          Applicable to data transfer commands.   After  the  transfer,
17          the  data will be read back from the transfer destination and
18          verified against  the  original  data  re-obtained  from  the
19          source.    Specifying  this  modifier  is  similar,  but  not
20          identical, to following the transfer command with  a  COMPARE
21          HOST  DATA  command.  In particular, if the compare operation
22          fails, an error log message is generated (if enabled) and the
23   |      original  transfer operation retried.  (With the COMPARE HOST
24   |      DATA command, an error log message must not be  generated  on
25   |      compare  errors.  Retries are unnecessary, although innocuous
26   |      and  therefore  allowable).   See  Section   4.14,   "Compare
27          Operations",   for   a  more  detailed  description  of  this
28          modifier's effects.

29      Express Request

30          Applicable  to  non-sequential   commands.    This   modifier
31          requests  that  the controller ignore its normal optimization
32          policies in order to complete  this  command  as  quickly  as
33          possible.   The  exact  implementation of express requests is
34          controller  dependent  --  in  general  the  controller  will
35          complete  some  or  all  of  its  outstanding commands before
36          completing an express request.

37          Use  of  express  requests  disables  the  normal  controller
38          guarantees  that  ensure  that all commands are serviced in a
39          timely manner.  If express requests  are  repeatedly  issued,
40          some  or  all  other outstanding commands may time out (i.e.,
41          never be completed).

42          Express requests do NOT override sequential command execution
43          guarantees.   Some  controllers  may  completely  ignore  the
44          express request modifier.  The  exact  treatment  of  express
45          requests  should  be  described  in a controller's Functional
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                             Page 5-9
        5.4  Command Modifiers                                  08 Apr 82


 1          Specification.

 2      Force Error

 3          Applicable to write commands.  Causes the data to be  written
 4          with  the forced error indicator set, so that all attempts to
 5          read the data will fail.  The error will be  preserved  until
 6          the  next  time  the  block  is  written.   The forced errors
 7          produced  with  this  modifier  must  be  recognized  by  the
 8          controller as deliberate and never reported to the error log.
 9   |      Note that the data must be written to the block so as  to  be
10   |      obtainable  by  subsequent  READ commands, exactly as if this
11   |      modifier were not specified.  The only difference is  whether
12   |      subsequent  READ  commands  will return success or the forced
13   |      error status code.

14      Suppress Caching (high speed)

15          Applicable to read commands.  Prevents data accessed by  this
16          command  from  being  loaded into the controller's high speed
17          cache.  Ignored if the controller does not have a high  speed
18          cache.  This modifier does not affect the use of data that is
19          already in the cache.

20      Suppress Caching (low speed)

21          Applicable to read commands.  Prevents data accessed by  this
22          command  from  being  loaded  into the controller's low speed
23          cache.  Ignored if the controller does not have a  low  speed
24          cache.  This modifier does not affect the use of data that is
25          already in the cache.

26      Suppress Error Correction

27          Suppresses  error  correction   mechanisms,   such   as   ECC
28          correction.   Error recovery mechanisms, such as retries, are
29          not affected by this modifier.   This  modifier,  in  effect,
30          lowers  the  threshhold at which an error is considered to be
31          uncorrectable.  It typically lowers the threshhold  to  zero,
32          although  that  is  not  required.  Since error correction is
33          drive type dependent, the lowered error correction threshhold
34          is  also  drive type dependent.  If a drive has several error
35          correction mechanisms, it is permissable for this modifier to
36          suppress some and not affect others.

37      Suppress Error Recovery

38          Suppresses most  error  recovery  mechanisms,  such  as  read
39          retries.    Error   correction   mechanisms,   such   as  ECC
40          correction, and some error recovery mechanisms, such as  seek
41          retry,   are  not  affected  by  this  modifier.   The  exact
42          definition of which error recovery mechanisms are  suppressed
43          and which are not affected is drive type dependent.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-10
        5.4  Command Modifiers                                  08 Apr 82


 1      Suppress Shadowing

 2          Applicable to transfer commands.  Directs the command to  the
 3          specified unit of the shadow set and only to that unit.  Read
 4          commands are normally directed to any unit of  a  shadow  set
 5          (based   on   optimization  criteria).   Write  commands  are
 6          normally directed  to  all  units  of  a  shadow  set.   This
 7          modifier,  when  asserted,  causes the command to be executed
 8          exactly as if no shadow sets were defined.  It is permissable
 9          to specify this modifier on commands that are not directed to
10          a shadow set.

11      Write-back (non-volatile)

12          Applicable to write commands.   Causes  the  command  to  use
13          write-back  caching,  rather  than write-through caching, for
14          non-volatile caches.  Note that the controller, if  and  when
15          it  honors this modifier for a disk unit, must ensure that it
16          has flagged the existence of pending write-back data  in  the
17          volume's Replacement and Caching Table (RCT).

18      Write-back (volatile)

19          Applicable to write commands.   Causes  the  command  to  use
20          write-back  caching,  rather  than write-through caching, for
21          volatile caches.  Note that the controller, if  and  when  it
22          honors this modifier for a disk unit, must ensure that it has
23          flagged the existence  of  pending  write-back  data  in  the
24          volume's Replacement and Caching Table (RCT).

25      Write Shadow Set One Unit At a Time

26          Applicable to write commands.  Causes the write operation  to
27          be  fully  completed on one unit of a shadow set before it is
28          begun on the next.  See Section 4.19, "Shadowing".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-11
        5.5  End Message Format                                 08 Apr 82


 1      5.5  End Message Format

 2      An MSCP server sends an end message to a class driver  to  report
 3      completion  of  a  command.  The generic end message format is as
 4      follows:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |    status     | flags |endcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---                         ---+
17                      |           undefined           |
18                      +---                         ---+
19                      |                               |
20                      +-------------------------------+
21                      |        first bad block        |
22                      +-------------------------------+

23      The command reference number is copied from the command  message.
24      The remaining fields are as follows:

25      unit number

26          Normally copied from the command message.  If the command was
27          directed to a shadow set, however, this field may contain the
28          unit number of any unit of the shadow  set.   In  particular,
29          this  field  is  used to report the unit (of a shadow set) on
30          which the error reported by "status" occurred.

31      endcode

32          Identifies this message as an end message  and  the  type  of
33          command (opcode) that this is an end message for.  This field
34          implicitly specifies the format  and  interpretation  of  the
35          parameters.

36      flags

37          Bit flags, collectively called  end  flags,  used  to  report
38          various  conditions  detected  due  to  this  command but not
39          directly related to success or failure.  The following  flags
40          are defined:

41          Bad Block Reported

42              Set if one or more bad blocks were detected and the  host
43              is  performing bad block replacement.  Indicates that the
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-12
        5.5  End Message Format                                 08 Apr 82


 1              host should replace  the  bad  block  identified  in  the
 2              "first bad block" field.

 3          Bad Blocks Unreported

 4              Set if one or more  bad  blocks  were  detected  and  not
 5              reported  in  the  "first  bad block" field.  If the "Bad
 6              Block Reported" flag is also set, this indicates that two
 7              or  more bad blocks were detected, the host is performing
 8              bad block replacement, and the "first  bad  block"  field
 9              only reports the first bad block in the transfer.  If the
10              "Bad Block Reported" flag is clear, this  indicates  that
11              one  or  more  bad  blocks  were  detected  and  that the
12              controller either already has or soon will replace them.

13          Error Log Generated

14              Set if one or more error log messages were generated that
15              refer   to  this  command  --  i.e.,  that  contain  this
16              command's command reference number.  This flag allows the
17              host  to  save  any  outstanding  command context that it
18              wishes to include in the error log.  The MSCP server must
19              send  the  error  log  messages  either before or shortly
20              after it sends the end message containing this flag.

21          All other bits in  this  field  are  reserved,  and  must  be
22          treated  in  accordance  with  the  requirements for reserved
23          fields described in  Section  5.2,  "Reserved  and  Undefined
24          Fields".

25      status

26          The modifiers field is used for  a  completion  status  code.
27          The   status   code   indicates  whether  the  operation  was
28          successfully completed or, if it wasn't successful, what type
29          of error occurred.  Note that recoverable errors are reported
30          as successful completion of the command.  All errors, whether
31          recoverable  or  not,  are  reported  in a separate error log
32          message if they should be logged.

33          If several errors occur in a transfer operation,  the  status
34          code  reports  the first error starting from the beginning of
35          the transfer (i.e., the lowest byte count or  lowest  logical
36          block  number).  The only exception is transfer commands that
37          include  a  compare   operation   (i.e.,   read-compare   and
38          write-compare  operations);   errors in the original transfer
39          may take precedence over errors during the compare operation.

40          If a "Forced Error" and some other error occur  at  the  same
41          point  (same  byte  count  or  logical block number) within a
42          transfer operation, the other error must be reported.   If  a
43          "Compare  Error"  and some other error which is not a "Forced
44          Error" occur at the same point within a  transfer  operation,
45          the  other error must be reported.  If a "Forced Error" and a
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-13
        5.5  End Message Format                                 08 Apr 82


 1          "Compare Error" both occur at the same point,  and  no  other
 2          error  occurs  at  that  point,  the  "Compare Error" must be
 3          reported.   Otherwise,  which  error   of   multiple   errors
 4          occurring  at the same point should be reported is controller
 5          dependent.  An  alternative  way  of  stating  this  is  that
 6          "Forced  Errors"  are  the  error  of  last  resort  and that
 7          "Compare Errors" are the error of second to last resort.

 8          If several errors occur  in  a  non-transfer  operation,  the
 9          error  that  is  reported  is controller dependent unless the
10          individual command description states otherwise.

11      byte count

12          In  transfer  command  end  messages,  the  number  of  bytes
13          successfully  transferred,  counting  from  the  start of the
14          transfer to the first error (i.e., the lowest byte  count  or
15          lowest  logical  block  number  with  an  error).   Data that
16          follows the first error is not counted, even  if  transferred
17          successfully.   The  only exception is transfer commands that
18          include  a  compare   operation   (i.e.,   read-compare   and
19          write-compare  operations);   errors in the original transfer
20          may take precedence over errors during the compare operation.

21          The controller must have successfully transferred all data up
22          to  the  point  identified by "byte count".  Furthermore, the
23          error identified by "status" must have actually  occurred  at
24          the  position  identified  by "byte count".  The state of the
25          transfer following the position identified by "byte count" is
26          undefined.   None  of the transfer following "byte count" may
27          have been performed or attempted, all of  it  may  have  been
28          attempted (with unknown success), or some parts may have been
29          attempted and others not.

30          Again, the only exception to this is transfer  commands  that
31          include a compare operation.  Such a command makes two passes
32          over the data;  one for the original transfer and another for
33          the  compare  operation.  For most errors, there is no way to
34          determine in which pass the error  was  detected.   Therefore
35          the   only  guarantee  is  that  the  original  transfer  was
36          performed up to the point identified by "byte count"  without
37          detecting  any  errors.  The compare operation may or may not
38          have been performed up to that point.  If a  "Compare  Error"
39          is  reported, then both the original transfer and the compare
40          operation have been successfully performed up  to  the  point
41          identified  by  "byte count".  The state of both the original
42          transfer and the compare operation after that point, however,
43          is  undefined.   This  implies  that  the  compare  pass of a
44          transfer command that includes a  compare  operation  may  be
45          done  for  the  entire transfer as a unit, block by block, or
46          anywhere in between.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-14
        5.5  End Message Format                                 08 Apr 82


 1          For disk class devices, the granularity of the byte count  on
 2          errors (i.e., the resolution with which the point of error is
 3          identified) need not be any smaller than the  volume's  block
 4          size.   That  is, the byte count need only identify the block
 5          in which the error occurred, rather than the  exact  word  or
 6          byte.   In  particular,  the  byte  count  returned with such
 7          errors as "Compare Errors" and "Host  Buffer  Access  Errors"
 8          need  only  identify  the  block in which the error occurred,
 9          rather than the exact word or byte.  Note  that  a  block  is
10          identified  by  the  number  of  the first byte in the block.
11          Controllers may optionally provide finer granularity for  the
12          byte  count  field  on  errors.  If an error is not reported,
13          controllers must return the exact byte count that was in  the
14          command message.

15          For tape class devices, the granularity of the byte count  on
16          errors  must  be either one word (two bytes) or one byte.  If
17          an error is not reported, controllers must return  the  exact
18          byte count that was transferred.

19          Not present in non-transfer command end messages.

20      first bad block

21          In disk transfer command  end  messages,  the  logical  block
22          number  of  the first bad block (i.e., the bad block with the
23          lowest logical block number)  detected  during  the  transfer
24          that  the  host should replace.  Only valid if the "Bad Block
25          Reported" flag is set.  Undefined (garbage) if the "Bad Block
26          Reported" flag is clear.

27          Not present in non-transfer command end messages.



28      5.6  Status Codes

29      The "status code" field is divided into a 5-bit major status code
30      and an 11-bit status sub-code arranged as follows:

31                        15                         0 
32                        +-----------------+---------+
33                        |     sub-code    |  code   |
34                        +-----------------+---------+

35      The "event code" field of error log messages  has  the  identical
36      structure  and encoding.  Errors that are reported in both an end
37      message and an error log message use  identical  values  for  the
38      "status code" and "event code" fields.  The same value may not be
39      used to report a different type of event as a status code than as
40      an event code.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-15
        5.6  Status Codes                                       08 Apr 82


 1      The 5-bit major status code conveys the status  information  that
 2      hosts  need  for  normal  operation.   Therefore the major status
 3      codes are a formal part of MSCP.  All controllers must return the
 4      same major status codes for similar situations.

 5      The 11-bit sub-code exists to specify the exact error or  unusual
 6      situation  encountered  with  very  fine  detail.   As such it is
 7      primarily used for diagnostic purposes, and hosts should not need
 8      to examine it during normal operation.

 9      Sub-codes related to protocol or state errors are a  formal  part
10      of  MSCP.   All  controllers  must  return the same sub-codes for
11      protocol or state errors.   These  sub-codes  are  generally  bit
12      flags,  allowing  several  causes  of the major status code to be
13      reported.

14      Sub-codes related to controller  and/or  drive  errors,  however,
15      must  be allowed to vary from one controller or drive to another.
16      There is no requirement that the same sub-codes be  returned  for
17      similar   drive   or  controller  errors.   These  sub-codes  are
18      generally specific values, corresponding to one specific event or
19      error.   Each  sub-code must have the same meaning whenever it is
20      used.  It is the use of a sub-code that may vary  (i.e.,  whether
21      or  not  a  specific  controller  returns that sub-code), not its
22      meaning.  The defined sub-codes are listed in Appendix  B.   This
23      list  may  expand  (via  an  ECO to MSCP) whenever a new drive or
24      controller type is introduced.

25      The major status codes  that  may  be  returned  in  end  message
26      "status  code" fields are listed below along with the general use
27      made of sub-codes.  The  actual  sub-codes  used  are  listed  in
28      Appendix  B.   Those sub-codes that are a formal part of MSCP are
29      also listed in the descriptions of the commands that  may  return
30      them.

31      Success

32          The command was successfully completed.  This status code may
33          also  be  returned, for some commands, if the intended effect
34          of  the  command  has  already   been   accomplished   (i.e.,
35          requesting  a  drive  that isn't spinning to spin-down).  The
36          sub-code  consists  of  bit  flags  used  to  report  various
37          "alternate"  forms  of  success.   See the individual command
38          descriptions for details.

39          The status  code  value  associated  with  "Success"  is,  by
40          definition,  zero.   Sub-code  value  zero (i.e., no sub-code
41          bits set) is "Normal" success, and implies normal  completion
42          of  a command.  One sub-code bit, the "Duplicate Unit Number"
43          bit, is common to many commands.  This bit, when set, implies
44          that the unit is "Unit-Online" and the command succeeded, but
45          that the unit has a duplicate unit  number.   The  unit  will
46          become  "Unit-Offline",  due to the duplicate unit number, as
47          soon as it  ceases  to  be  "Unit-Online".   Other  "Success"
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-16
        5.6  Status Codes                                       08 Apr 82


 1          sub-code  bits  are  unique  to a particular command, and are
 2          described under the individual command descriptions.

 3      Invalid Command

 4          This status code is used for two purposes:

 5          1.  In normal command end messages,  it  is  used  to  report
 6              invalid   parameter   values  (e.g.,  bad  logical  block
 7              number).  Some controllers may not detect certain invalid
 8              parameters  until  after  performing  some  part  of  the
 9              command.  For example, a byte count that  runs  past  the
10              end  of a disk may not be detected until the transfer has
11              been performed up to the end of the disk.

12          2.  In the Invalid Command End Message, it is used to  report
13              invalid  MSCP  commands  (protocol errors).  A command is
14              invalid if some field contains a reserved  value  or  the
15              command   message  was  too  short  to  contain  all  the
16              parameters required by the opcode.


17          Note that an unknown  unit  number  does  not  constitute  an
18          invalid  parameter  or  command.   Unknown  unit  numbers are
19          treated as if the unit is "Unit-Offline".

20          The sub-code is used to report the offset, within the command
21          message,  of the field in error.  Bits 8 through 15 (the high
22          byte) of the "status code" field contain the byte offset from
23          the  start  of the message to the field in error.  Multi-byte
24          fields are identified by the offset  to  their  lowest  byte.
25          Single  byte  fields  positioned  at  an  odd  offset  may be
26          identified, at  the  controller's  option,  by  either  their
27          actual  offset  or  their offset minus one.  That is, offsets
28          may be truncated to an even value.  Sub-code zero is used  to
29          report  that the command message was too short to contain the
30          parameters required by the command's opcode.  Note  that  any
31          value  is  valid  for  the field at offset zero, the "command
32          reference number".

33          Note that protocol errors, reported via this status code  and
34          the Invalid Command end message, may cause the MSCP server to
35          become "Controller-Available" relative to  the  class  driver
36          that issued the invalid command.

37      Command Aborted

38          The command was aborted by an ABORT command.  The end message
39          for the aborted command (i.e., the end message containing the
40          "Command Aborted" status code) has the normal format for  the
41          command  and  all fields are valid.  In particular, the "byte
42          count" field  identifies  how  far  a  transfer  command  was
43          completed  before it was aborted.  The status of the transfer
44          beyond the returned byte count is undefined.   Sub-codes  are
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-17
        5.6  Status Codes                                       08 Apr 82


 1          not used.

 2      Unit-Offline

 3          The unit identified by the "unit number"  field  of  the  end
 4          message   is  in  the  "Unit-Offline"  state.   The  sub-code
 5          consists  of  bit  flags  that  indicate  why  the  unit   is
 6          "Unit-Offline".   Note  that there may be several reasons for
 7          the unit being "Unit-Offline".  If the sub-code is  zero,  it
 8          implies  that  the  unit  is  unknown -- i.e., the controller
 9          knows of no unit with the specified unit number.

10      Unit-Available

11          The unit identified by the "unit number"  field  of  the  end
12          message  is  in  the "Unit-Available" state.  The sub-code is
13          always zero.

14      Media Format Error

15          Only returned by the ONLINE command for disk  class  devices.
16          The  volume  mounted  on  the  unit  appears  to be formatted
17          incorrectly, so that it must be  reformatted  (and  all  data
18          lost)  before it may be used.  This error is also returned if
19          the volume  is  formatted  with  576  byte  sectors  and  the
20          controller  only  supports  512  byte sectors.  Note that the
21          volume may only "appear" to be  formatted  incorrectly;   the
22          typical  cause  of  this  error  is  a  fault  in the drive's
23          read/write electronics.  If this is the case, the volume  can
24          usually be successfully accessed on another drive.

25          Controllers must treat the unit as if  an  AVAILABLE  command
26          with  the  "Spin-down"  modifier  set  had been issued for it
27          whenever they return this error code.  The unit is  therefore
28          always in the "Unit-Available" state with AVAILABLE attention
29          messages suppressed until a human operator changes the volume
30          or  spins-up  the unit.  The sub-code reports which integrity
31          check the volume failed;  it is volume format, and  therefore
32          drive type, dependent.

33      Write Protected

34          The unit identified by the "unit number"  field  of  the  end
35          message is write protected and the command required that data
36          be written onto the drive.   The  sub-code  consists  of  bit
37          flags indicating the reasons why the unit is write protected.

38      Compare Error

39          A COMPARE HOST DATA command, a read compare operation,  or  a
40          write  compare  operation  found  different  data in the host
41          buffer and the unit identified by the "unit number" field  of
42          the  end  message, or a COMPARE CONTROLLER DATA command found
43          different data on different  units  of  a  shadow  set.   The
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-18
        5.6  Status Codes                                       08 Apr 82


 1          sub-code is always zero.

 2      Data Error

 3          Invalid or uncorrectable data was obtained from a  drive,  as
 4          determined  by  internal error detecting or correcting codes.
 5          The sub-code is used to  report  the  exact  error  detected.
 6          Sub-code zero is used for "Forced Errors".  All errors caused
 7          by the "Force Error" modifier must be reported with  sub-code
 8          zero.

 9      Host Buffer Access Error

10          The controller encountered an error when attempting to access
11          a  buffer in host memory.  The sub-code is used to report the
12          exact error encountered.  This status code is  also  returned
13          whenever  the  command's  buffer  descriptor  or  byte  count
14          violate any communications mechanism dependent restrictions.

15          Note that this status code  is  NOT  used  to  report  errors
16          encountered  when  transferring  command,  end, attention, or
17          error log messages between the controller and a  host.   Such
18          errors are reported by terminating the connection between the
19          class driver and MSCP server.  The  mechanism  for  reporting
20          such  errors  to  the  host's  error  log  is  communications
21          mechanism dependent.

22      Controller Error

23          The controller encountered an internal controller error.  The
24          sub-code  is  used to report the exact error encountered.  An
25          internal controller error is reported as a "Controller Error"
26          if and only if the controller has reasonable grounds to trust
27          its sanity and expects to complete,  either  successfully  or
28          with an appropriate error status code, all of its outstanding
29          commands.  All more severe controller errors are reported  by
30          terminating  the  connection  between  the  controller's MSCP
31          server and the host class driver.  This is  in  addition,  of
32          course, to attempting to generate an error log message.

33          Sub-code zero of  this  status  code  is  reserved  for  host
34          detected   command   timeouts.    All   other  sub-codes  are
35          controller dependent.

36          Note that some controller errors may be reported using  other
37          error  codes,  if  an  internal  controller  error causes the
38          controller to mis-diagnose the error.

39      Drive Error

40          The controller discovered an  error  within  a  drive.   Such
41          errors  are  typically, but not always, mechanical in nature,
42          since  most  non-mechanical  errors  are  reported  as  "Data
43          Errors".   The  sub-code  is  used  to report the exact error
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-19
        5.6  Status Codes                                       08 Apr 82


 1          encountered.

 2          In many cases a "Drive Error" will indicate that the unit  is
 3          broken  or  inoperative.   If  this occurs, the "Drive Error"
 4          should be reported once and the unit should  subsequently  be
 5          reported as being "Unit-Offline" due to being inoperative.

 6      The status codes that may be returned for a specific command  are
 7      command  (opcode)  dependent.   The  status  codes  that  may  be
 8      returned for each command and any special meaning that they  have
 9      specific  to  the command are listed in the command descriptions.
10      Note that the  format  of  a  command's  end  message  is  solely
11      determined  by  its  opcode.  The status code returned in the end
12      message does not affect the end message's format.  The  only  two
13      exceptions,  protocol  errors and serious exceptions, have unique
14      end messages that contain a special opcode.



15      5.7  Unit Flags

16      Several messages contain a field called  the  unit  flags  field.
17      This field consists of unit characteristics bit flags.  Some unit
18      flags are host settable.  Host settable unit flags may be set  or
19      cleared  with  the  ONLINE and SET UNIT CHARACTERISTICS commands.
20      Other unit flags are  non-host  settable.   The  controller  must
21      ignore  the values supplied by hosts for non-host settable flags,
22      and  always  return   the   correct   value   from   the   unit's
23      characteristics.   A  few  unit  flags  may  be  host settable or
24      non-host settable, depending on the  presence  or  absence  of  a
25      command modifier.

26      Many unit flags, including all host settable unit flags, are only
27      valid  when  the  unit is "Unit-Online".  The values returned for
28      such unit flags are undefined if the unit  is  "Unit-Offline"  or
29      "Unit-Available".   A  few non-host settable unit flags are valid
30      when  the   unit   is   "Unit-Available"   and   during   certain
31      "Unit-Offline"  sub-states.   These  flags  are identified in the
32      individual flag descriptions below.

33      Those bits in the "unit flags" word that are not defined as  unit
34      flags  are  reserved,  and must be treated in accordance with the
35      requirements  for  reserved  fields  described  in  Section  5.2,
36      "Reserved and Undefined Fields".

37      The unit characteristics flags are as follows:

38      Compare Reads

39          A host settable characteristic;  set if  all  read  transfers
40          should  be  verified with a compare operation.  Equivalent to
41          specifying the  "Compare"  modifier  on  all  READ  commands.
42          Undefined   when  the  unit  is  either  "Unit-Available"  or
43          "Unit-Offline".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-20
        5.7  Unit Flags                                         08 Apr 82


 1      Compare Writes

 2          A host settable characteristic;  set if all  write  transfers
 3          should  be  verified with a compare operation.  Equivalent to
 4          specifying the "Compare"  modifier  on  all  WRITE  commands.
 5          Undefined   when  the  unit  is  either  "Unit-Available"  or
 6          "Unit-Offline".

 7      Controller Initiated Bad Block Replacement

 8          A non-host settable characteristic;  set  if  the  controller
 9          will  perform  bad  block replacement for this unit, clear if
10          the host must perform bad block replacement  for  this  unit.
11          Undefined   when  the  unit  is  either  "Unit-Available"  or
12          "Unit-Offline".

13      Inactive Shadow Set Unit

14          A host settable characteristic;   set  if  this  unit  is  an
15          inactive   member   of   a   shadow   set.    The  controller
16          automatically clears this characteristic when  it  makes  the
17          unit  active,  which it does after initializing the unit with
18          data from another active unit of the shadow  set.   Undefined
19          when the unit is either "Unit-Available" or "Unit-Offline".

20      Removable Media

21          A  non-host  settable  characteristic;   set  if   unit   has
22          removable media.  Valid whenever the controller can determine
23          the unit's characteristics.  See the descriptions of the  GET
24          UNIT  STATUS,  ONLINE,  and SET UNIT CHARACTERISTICS commands
25          for more information.

26      Suppress Caching (high speed)

27          A host settable characteristic;  set  if  caching  using  the
28          controller's  high  speed  cache  is  disabled for this unit.
29          Equivalent to specifying the "Suppress Caching (high  speed)"
30          modifier  on  all  commands for which it is legal.  Undefined
31          when the unit is either "Unit-Available" or "Unit-Offline".

32      Suppress Caching (low speed)

33          A host settable characteristic;  set  if  caching  using  the
34          controller's  low  speed  cache  is  disabled  for this unit.
35          Equivalent to specifying the "Suppress Caching  (low  speed)"
36          modifier  on  all  commands for which it is legal.  Undefined
37          when the unit is either "Unit-Available" or "Unit-Offline".

38      Write-back (non-volatile)

39          A host settable characteristic;  set if  all  write  commands
40          should  use  write-back  caching,  rather  than write-through
41          caching, for non-volatile caches.  Equivalent  to  specifying
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-21
        5.7  Unit Flags                                         08 Apr 82


 1          the  "Write-back (non-volatile)" modifier on all commands for
 2          which it is legal.  Note that the controller must ensure that
 3          the  existence  of  pending write-back data is flagged in the
 4          volume's  Replacement  and  Caching  Table  before   actually
 5          performing  a  write-back operation.  Undefined when the unit
 6          is either "Unit-Available" or "Unit-Offline".

 7      Write Protect (hardware)

 8          A non-host settable characteristic;  set if and only  if  the
 9          unit's write protect mechanism is activated, causing the unit
10          to  be  Hardware  Write  Protected.   All  write  operations,
11          including  attempts  to  perform bad block replacement, alter
12          the state of Volume Write Protection, or otherwise modify the
13          RCT,  will  be  rejected  when this flag is set.  See Section
14          4.13, "Write Protection".  Undefined when the unit is  either
15          "Unit-Available" or "Unit-Offline".

16      Write Protect (software or volume)

17          Normally a non-host settable characteristic;  a host settable
18          characteristic  if  the  "Enable  Set  Write Protect" command
19          modifier  is   asserted   in   the   ONLINE   or   SET   UNIT
20          CHARACTERISTICS  commands.   Set  if  and only if the unit is
21          Software or Volume Write Protected.  See Section 4.13, "Write
22          Protection".     Undefined    when   the   unit   is   either
23          "Unit-Available" or "Unit-Offline".

24      576 Byte Sectors

25          Normally a non-host settable characteristic;  a host settable
26          characteristic  if  the  controller supports 576 byte sectors
27          and the "Ignore  Media  Format  Error"  command  modifier  is
28          asserted in the ONLINE command.  Set if the volume mounted on
29          the unit has 576 byte sectors.  Undefined when  the  unit  is
30          either "Unit-Available" or "Unit-Offline".



31      5.8  Controller Flags

32      The SET CONTROLLER CHARACTERISTICS command is  used  to  set  and
33      clear host settable controller flags, and to obtain the values of
34      non-host settable controller  flags.   Host  settable  controller
35      flags  are stored on a per class driver basis.  Each class driver
36      may have different settings for host settable  controller  flags.
37      Non-host   settable   controller   flags   are  fixed  controller
38      characteristics, and therefore common to all class drivers of the
39      same  device  class.   The  controller  must  ignore  the  values
40      supplied by hosts for non-host  settable  controller  flags,  and
41      always   return   the   correct   value   from  the  controller's
42      characteristics.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-22
        5.8  Controller Flags                                   08 Apr 82


 1      All  host  settable  controller  flags  are,  by  default,  clear
 2      whenever  a  class  driver becomes "Controller-Online" to an MSCP
 3      server.  The flags remain clear until the class driver sets  them
 4      with  a SET CONTROLLER CHARACTERISTICS command or until the class
 5      driver is no longer "Controller-Online" to the MSCP server.

 6      Those bits in the "controller flags" word that are not defined as
 7      controller  flags are reserved, and must be treated in accordance
 8      with the requirements for reserved fields  described  in  Section
 9      5.2, "Reserved and Undefined Fields".

10      The controller flags are as follows:

11      Enable Attention Messages

12          A host settable controller characteristic;  set if  attention
13          messages should be sent to this host.  Note that this flag is
14          applicable to all attention messages, regardless of type.

15      Enable Miscellaneous Error Log Messages

16          A host settable controller characteristic;  set if error  log
17          messages  that  do not relate to a specific command should be
18          sent to this host.

19      Enable Other Hosts' Error Log Messages

20          A host settable controller characteristic;  set if error  log
21          messages that relate to commands issued by other hosts should
22          be sent to this host.

23      Enable This Host's Error Log Messages

24          A host settable controller characteristic;  set if error  log
25          messages  that  relate to commands issued by this host should
26          be sent to this host.

27      Controller Initiated Bad Block Replacement

28          A non-host settable controller characteristic;   set  if  the
29          controller    supports   controller   initiated   bad   block
30          replacement on all disk drives that can be connected  to  the
31          controller.  That is, this flag is set if the host will never
32          have to perform bad block replacement for disks accessed  via
33          this  controller.   Note that this flag is only applicable to
34          the disk device class.

35      Shadowing

36          A non-host settable controller characteristic;   set  if  the
37          controller supports shadowing on this device class.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Control Message Formats                            Page 5-23
        5.8  Controller Flags                                   08 Apr 82


 1      576 Byte Sectors

 2          A non-host settable controller characteristic;   set  if  the
 3          controller  supports  disks  formatted with 576 byte sectors.
 4          Note that this flag is only applicable  to  the  disk  device
 5          class.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 6

 2                          MINIMAL DISK MSCP SUBSET



 3      This chapter describes the minimal subset of Disk MSCP, which all
 4      disk controllers must implement.  The following chapter describes
 5      Disk MSCP options, which a controller may or may not implement.

 6      Note that the minimal subset of Disk MSCP  that  general  purpose
 7      class  drivers  must implement includes both the the minimal Disk
 8      MSCP subset, described in this chapter, and Controller  Initiated
 9      Bad  Block  Replacement,  described in Section *****, "Controller
10      Initiated Bad Block Replacement".  The  only  consequences  of  a
11      class  driver  having to implement Controller Initiated Bad Block
12      Replacement  are  that  the  class  driver  must  recognize  some
13      additional  error  status  codes  and  be  able to clear "serious
14      exceptions".

15      This chapter first describes the unit and controller  flags  that
16      are  used  with  the  minimal Disk MSCP subset, then it describes
17      each command to which controllers must respond,  and  finally  it
18      describes   the  attention  messages  that  the  controller  must
19      generate.  The controller must respond with the  Invalid  Command
20      end  message  and  an "Invalid Opcode" status code to any command
21      that is not listed here.

22      Each command  description  includes  the  command's  category  or
23      execution   order  (see  Section  4.5,  "Command  Categories  and
24      Execution Order"), the command message  format,  a  list  of  the
25      allowable  command modifiers, the command's end message format, a
26      list of possible status codes, and a description of the command's
27      effects.  Use of any command modifiers other than the ones listed
28      for an individual command is reserved, and  must  be  treated  in
29      accordance with the requirements for reserved fields described in
30      Section 5.2, "Reserved and Undefined Fields".

31      Many of the command modifiers are ignored  in  the  minimal  Disk
32      MSCP  subset.   This  is  for  compatibility  with  the Disk MSCP
33      options for which they  are  present.   Command  modifiers  which
34      should  be  ignored  are  listed  under  the  individual  command
35      descriptions, just like all other legal command modifiers.   They
36      are  flagged with the denotation " -- ignored".  Controllers that
37      do not support the relevant options should  totally  ignore  such
38      command modifiers, regardless of whether they are clear or set.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-2
        6.1  Unit Flags                                         08 Apr 82


 1      6.1  Unit Flags

 2      This section describes the level of support for  each  unit  flag
 3      that  is  included  in the minimal Disk MSCP subset.  See Section
 4      5.7, "Unit Flags", for a description of each flag's purpose.

 5      The support for the various unit flags in the minimal  Disk  MSCP
 6      subset is as follows:

 7      Compare Reads
 8      Compare Writes

 9          These host settable unit flags must be fully supported.

10      Controller Initiated Bad Block Replacement

11          This non-host settable unit  flag  must  always  be  returned
12          clear by controllers that do not support Controller Initiated
13          Bad Block Replacement.  It is returned set to  indicate  that
14          the   controller  supports  Controller  Initiated  Bad  Block
15          Replacement for this unit.  See  Section  *****,  "Controller
16          Initiated  Bad  Block  Replacement",  for the consequences of
17          supporting this option.

18      Inactive Shadow Set Unit

19          This host settable unit flag is reserved  if  the  controller
20          does not support shadowing, and must be treated in accordance
21          with  the  requirements  for  reserved  fields  described  in
22          Section  5.2,  "Reserved  and Undefined Fields".  That is, it
23          must be supplied clear by  both  hosts  and  controllers.   A
24          controller  may  optionally  choose to check that hosts do in
25          fact supply it clear,  and  return  an  Invalid  Command  end
26          message  with  the "Invalid Unit Flags" status code if a host
27          attempts to set it.  Controllers that  do  support  shadowing
28          must support this flag as described in Section *****.

29      Removable Media

30          This non-host settable unit flag must be fully supported.

31      Suppress Caching (high speed)
32      Suppress Caching (low speed)
33      Write-back (non-volatile)

34          These host settable unit flags must  be  ignored  and  always
35          returned  clear  by  controllers that do not support caching.
36          See Section ***** for  the  consequences  of  supporting  the
37          caching option.

38      Write Protect (hardware)

39          This non-host settable unit flag must be fully supported.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-3
        6.1  Unit Flags                                         08 Apr 82


 1      Write Protect (software or volume)

 2          This unit flag is normally non-host  settable;   it  is  host
 3          settable  if  the  "Enable  Set  Write  Protect"  modifier is
 4          asserted in an ONLINE or SET UNIT CHARACTERISTICS command.

 5          If the controller does not support Controller  Initiated  Bad
 6          Block   Replacement,  then  this  unit  flag  must  be  fully
 7          supported as the Software Write Protect status of  the  unit.
 8          That  is,  this  flag  must  be copied to the unit's Software
 9          Write Protect flag  whenever  an  ONLINE  or  SET  CONTROLLER
10          CHARACTERISTICS  command  has  the "Enable Set Write Protect"
11          modifier asserted.  The  default  or  initial  state  of  the
12          Software Write Protect flag when a unit becomes "Unit-Online"
13          is clear, or write-enabled.  The  controller  always  returns
14          the  unit's actual Software Write Protect status as the value
15          of this unit flag.  The controller  must  write  protect  the
16          unit  whenever  its Software Write Protect flag is set or its
17          hardware write protect mechanism has  been  activated.   That
18          is,  the  unit's write protect status display should indicate
19          that the unit is write protected and  the  controller  should
20          reject  all write operations for the unit.  See Section 4.13,
21          "Write Protection".

22          If the controller does support Controller Initiated Bad Block
23          Replacement,  then  this flag must be supported as the Volume
24          Write  Protect  status  of  the  unit.   See  Section  *****,
25          "Controller Initiated Bad Block Replacement".

26      576 Byte Sectors

27          This unit flag must be  fully  supported  if  the  controller
28          supports disks formatted with either 512 or 576 byte sectors.
29          If the controller only supports disks formatted with 512 byte
30          sectors,  the  controller  must  ignore  any  value  the host
31          specifies for this flag and always  return  it  clear.   Note
32          that  all  controllers  must support disks formatted with 512
33          byte sectors.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-4
        6.2  Controller Flags                                   08 Apr 82


 1      6.2  Controller Flags

 2      This section describes the level of support for  each  controller
 3      flag  that  is  included  in  the  minimal Disk MSCP subset.  See
 4      Section 5.8, "Controller Flags" for a description of each  flag's
 5      purpose.

 6      The support for the various controller flags in the minimal  Disk
 7      MSCP subset is as follows:

 8      Enable Attention Messages
 9      Enable Miscellaneous Error Log Messages

10          These two  host  settable  controller  flags  must  be  fully
11          supported.

12      Enable Other Host's Error Log Messages

13          This  host  settable  controller  flag  must  be  ignored  by
14          controllers  that  do  not  provide  Multi-host Support.  See
15          Section *****, "Multi-Host Support", for the consequences  of
16          providing Multi-Host Support.

17      Enable This Host's Error Log Messages

18          This host settable controller flag must be fully supported.

19      Controller Initiated Bad Block Replacement

20          This  non-host  settable  controller  flag  must  always   be
21          returned  clear by controllers that do not support Controller
22          Initiated Bad Block Replacement.  Controllers that do support
23          Controller Initiated Bad Block Replacement must set this flag
24          if and only if Controller Initiated Bad Block Replacement  is
25          supported  on all disks that it is possible to connect to the
26          controller.

27      Shadowing

28          This  non-host  settable  controller  flag  must  always   be
29          returned  clear by controllers that do not support shadowing.
30          See  Section  *****  for  the  consequences   of   supporting
31          shadowing.

32      576 Byte Sectors

33          This  non-host  settable  controller  flag  must   be   fully
34          supported.   It  must  be  returned  set  if  the  controller
35          supports disks formatted with 576 byte sectors  or  clear  if
36          the  controller  does  not.   Note  that all controllers must
37          support disks formatted with 512 byte sectors.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-5
        6.3  ABORT Command                                      08 Apr 82


 1      6.3  ABORT Command



 2      Command category:

 3          Immediate


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      | outstanding reference number  |
14                      +-------------------------------+

15          unit number

16              Must be the same  as  the  "unit  number"  field  in  the
17              outstanding   command   to   be   aborted.   This  allows
18              controllers to optimize their search for the  outstanding
19              command.   If the incorrect unit number is supplied, some
20              controllers may erroneously conclude that the command  is
21              no   longer  outstanding  and  therefore  not  abort  the
22              command.

23          outstanding reference number

24              Command reference number of the command  to  be  aborted.
25              Note  that a class driver may only abort commands that it
26              itself has issued.   This  derives  from  the  fact  that
27              command reference numbers are implicitly qualified by the
28              connection on which the command was issued, so that class
29              drivers  have  no  way  of  naming  commands  issued by a
30              different class driver.


31      Allowable modifiers:

32          none
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-6
        6.3  ABORT Command                                      08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      | outstanding reference number  |
11                      +-------------------------------+

12          outstanding reference number

13              The command reference number  of  the  command  that  was
14              aborted.   Identical  to  the value supplied in the ABORT
15              command message.


16      Status Codes:

17          Success (sub-code "Normal")


18      Description:

19          The ABORT command causes a specified command to be aborted at
20          the   earliest  time  convenient  for  the  controller.   The
21          specified command must, however,  either  be  aborted  or  be
22          completed   within  the  controller  timeout  interval.   See
23          Section 4.10, "Command Timeouts", for  a  discussion  of  the
24          interaction between ABORT and command timeouts.

25          The ABORT command always succeeds.   If  the  command  to  be
26          aborted  is not known to the controller, this implies that it
27          has already completed and the ABORT command will be  ignored.
28          The controller always returns the "Normal" status code in the
29          ABORT command's end message.

30          The controller may ignore the ABORT command  if  the  command
31          being  aborted  will  always  complete  within the controller
32          timeout interval.

33          The class driver must wait  for  the  aborted  command's  end
34          message,  or else re-synchronize with the MSCP server, before
35          reusing the aborted command's  command  reference  number  or
36          releasing  the aborted command's context.  If the command was
37          aborted, its end message will contain the  "Command  Aborted"
38          status  code.   Otherwise,  the  command  was completed.  The
39          class driver may ignore  the  ABORT  command's  end  message.
40          Note  that  the  class driver may receive the ABORT command's
41          end message either before or after the aborted command's  end
42          message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-7
        6.4  ACCESS Command                                     08 Apr 82


 1      6.4  ACCESS Command



 2      Command category:

 3          Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---                         ---+
17                      |           reserved            |
18                      +---                         ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Express Request
26          Suppress Caching (high speed)       -- ignored
27          Suppress Caching (low speed)        -- ignored
28          Suppress Error Correction
29          Suppress Error Recovery
30          Suppress Shadowing                  -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-8
        6.4  ACCESS Command                                     08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available
28          Data Error
29          Controller Error
30          Drive Error


31      Description:

32          Data  is  read  from  the  unit,  checked  for  errors,   and
33          discarded.  The purpose of this command is to verify that the
34          designated data can be accessed (read) without error.

35          This command is exactly equivalent in function, although  not
36          in performance, to a READ whose data is ignored by the host.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                 Page 6-9
        6.5  AVAILABLE Command                                  08 Apr 82


 1      6.5  AVAILABLE Command



 2      Command category:

 3          Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+


13      Allowable modifiers:

14          All Class Drivers                   -- ignored
15          Clear Serious Exception             -- ignored

16          Spin-down

17              Requests that the disk stop spinning and that  the  heads
18              be  unloaded.  Note that the command completes as soon as
19              the spin-down has been initiated, rather than waiting for
20              the  disk  to  stop  spinning.  The spin-down will not be
21              initiated if this unit belongs to a multi-unit drive  and
22              this  unit  shares a spindle with some other unit that is
23              "Unit-Online".  See Section 4.15, "Multi-Unit Drives  and
24              Formatters".   Regardless of whether or not the spin-down
25              is actually initiated, AVAILABLE attention messages  will
26              be suppressed for this unit, both for this controller and
27              for any other  controllers  to  which  the  unit  may  be
28              connected.  See Section 4.3, "Unit States".


29      End message format:

30                      31                             0 
31                      +-------------------------------+
32                      |   command reference number    |
33                      +---------------+---------------+
34                      |   reserved    |  unit number  |
35                      +---------------+-------+-------+
36                      |    status     | flags |endcode|
37                      +---------------+-------+-------+
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-10
        6.5  AVAILABLE Command                                  08 Apr 82


 1      Status Codes:

 2          Success (sub-code "Normal")
 3          Success (sub-code "Duplicate Unit Number")

 4          Success (sub-code "Spin-down Ignored")

 5              The "Spin-down Ignored" sub-code bit flag is set  if  and
 6              only if the "Spin-down" modifier was specified and one or
 7              more other units with which this unit shares a spindle is
 8              still  "Unit-Online",  preventing this unit from spinning
 9              down.   See  Section   4.15,   "Multi-unit   Drives   and
10              Formatters", for an explanation of shared spindles.

11          Success (sub-code "Still Connected")

12              The "Still Connected" sub-code bit flag  is  set  if  and
13              only if this unit may potentially be accessed via another
14              controller and one or more other units  with  which  this
15              unit  shares  an  access  path  is  still  "Unit-Online",
16              preventing this unit from being accessed  via  the  other
17              controller  (if any).  The "Still Connected" sub-code bit
18              flag will always be set if the  "Spin-down  Ignored"  bit
19              flag  is  set.   See Section 4.18, "Multi-access Drives",
20              for a discussion of access paths.

21          Command Aborted

22   |          The command has been rejected and the  unit's  state  has
23   |          not  changed.   If  the  unit  was "Unit-Online" prior to
24   |          issueing  this  command,   then   the   unit   is   still
25   |          "Unit-Online" and it is still spinning.

26          Unit-Offline
27          Controller Error
28          Drive Error


29      Description:

30          All  outstanding  commands  for  the   specified   unit   are
31          completed,  then  the  unit becomes "Unit-Available".  If the
32          "Spin-down" modifier was  not  specified,  the  unit  is  not
33          already  "Unit-Available", and no other units that share this
34          unit's  access  path  are  "Unit-Online"  (i.e.,  the  "Still
35          Connected"  status  sub-code  bit  flag  is  clear),  then an
36          AVAILABLE attention message is sent by any  other  controller
37          to which the unit is connected.  The controller to which this
38          command was sent need not itself send an AVAILABLE  attention
39          message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-11
        6.5  AVAILABLE Command                                  08 Apr 82


 1          If the "Spin-down" modifier is specified, the disk spins down
 2          and its heads are unloaded, unless some other unit with which
 3          this unit shares a spindle is "Unit-Online".  The disk may be
 4          spun  up  with an ONLINE command or by operator intervention.
 5          The "Spin-down" modifier also suppresses AVAILABLE  attention
 6          messages  for  this  unit,  both  for this controller and any
 7          other controllers to which the unit may  be  connected.   See
 8          Section  4.3,  "Unit States", for a discussion of suppressing
 9          AVAILABLE attention messages.

10          This command will be accepted if the unit is "Unit-Online" or
11          "Unit-Available".   It is nugatory to issue this command to a
12          unit that is "Unit-Available" unless the "Spin-down" modifier
13          is  specified.  Assuming no other errors occur, the "Success"
14          status code will be returned regardless of whether  the  unit
15          was previously "Unit-Online" or "Unit-Available".

16          If the unit was "Unit-Online" but had a duplicate unit number
17          prior  to  the  AVAILABLE command being issued, the AVAILABLE
18          command may complete, at the controller's option, with either
19          a   "Success"   or   a   "Unit-Offline"   status  code.   The
20          "Unit-Offline" status code  must  have  the  "Duplicate  Unit
21          Number"  sub-code flag set.  The "Success" status code may or
22          may not, at the controller's option, have the "Duplicate Unit
23          Number" sub-code flag set.  Subsequent attempts to access the
24          unit will return "Unit-Offline" status  with  the  "Duplicate
25          Unit  Number"  sub-code  flag  set  unless the duplicate unit
26          number has been eliminated.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-12
        6.6  COMPARE CONTROLLER DATA Command                    08 Apr 82


 1      6.6  COMPARE CONTROLLER DATA Command



 2      Command category:

 3          Immediate or Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---                         ---+
17                      |           reserved            |
18                      +---                         ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Express Request                     -- ignored
26          Suppress Caching (high speed)       -- ignored
27          Suppress Caching (low speed)        -- ignored
28          Suppress Error Correction           -- ignored
29          Suppress Error Recovery             -- ignored
30          Suppress Shadowing                  -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-13
        6.6  COMPARE CONTROLLER DATA Command                    08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available


28      Description:

29          All  controllers  that  do  not  support  either  caching  or
30          shadowing  must  treat  this  command  as a no-op that always
31          succeeds.  This command is included in the minimal Disk  MSCP
32          subset  solely  for  compatibility  with  controllers that do
33          support caching or shadowing.

34          Controllers that do not support caching or  shadowing  should
35          construct  this command's end message by making the following
36          changes to the command message:

37          1.  Substitute the proper "endcode" for the "opcode".

38          2.  Clear the "flags" (end flags) byte, unless the controller
39              has  previously  verified  that  the corresponding "rsvd"
40              byte in the command message was zero.  (Most  controllers
41              will verify that the corresponding "rsvd" byte is zero as
42              part of checking for invalid opcodes).
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-14
        6.6  COMPARE CONTROLLER DATA Command                    08 Apr 82


 1          3.  Substitute the "Success" status code  combined  with  the
 2              "Normal" status sub-code for the "modifiers".

 3          The controller may optionally  validate  this  command  as  a
 4          transfer  command,  similar to the ACCESS and ERASE commands,
 5          before treating it as a no-op.  That is how  the  alternative
 6          status codes listed above may be generated.

 7          Controllers that support either  caching  or  shadowing  must
 8          treat  this command as a Non-Sequential command.  Controllers
 9          that do not support either of  these  options,  however,  and
10          therefore  treat  this command as a no-op as described above,
11          may treat this  as  either  an  Immediate  command  or  as  a
12          Non-Sequential command.  Host command timeout algorithms must
13          treat this as a non-Immediate command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-15
        6.7  COMPARE HOST DATA Command                          08 Apr 82


 1      6.7  COMPARE HOST DATA Command



 2      Command category:

 3          Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---         buffer          ---+
17                      |                               |
18                      +---       descriptor        ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Express Request
26          Suppress Caching (high speed)       -- ignored
27          Suppress Caching (low speed)        -- ignored
28          Suppress Error Correction
29          Suppress Error Recovery
30          Suppress Shadowing                  -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-16
        6.7  COMPARE HOST DATA Command                          08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available
28          Compare Error
29          Data Error
30          Host Buffer Access Error
31          Controller Error
32          Drive Error


33      Description:

34          Data is read from the unit and compared with the data in  the
35          host  buffer.   A "Compare Error" is reported unless the data
36          is identical.  Note that the occurence of  any  other  error,
37          except  a  "Forced  Error", at the same point as the "Compare
38          Error" will override the "Compare Error".  Note also that any
39          "Compare  Errors"  detected  by  this  command  must  NOT  be
40   |      reported to the error log.   Controllers  may  retry  compare
41   |      errors  detected by this command.  Provided the host does not
42   |      modify the buffer while the transfer  is  in  progress,  such
43   |      retries  will  have  a  deleterious effect on performance but
44   |      cannot alter the final outcome of the command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-17
        6.8  DETERMINE ACCESS PATHS Command                     08 Apr 82


 1      6.8  DETERMINE ACCESS PATHS Command



 2      Command Category:

 3          see below


 4      Command message format

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+


13      Allowable modifiers:

14          none


15      End message format:

16                      31                             0 
17                      +-------------------------------+
18                      |   command reference number    |
19                      +---------------+---------------+
20                      |   reserved    |  unit number  |
21                      +---------------+-------+-------+
22                      |    status     | rsvd  |endcode|
23                      +---------------+-------+-------+


24      Status codes:

25          Success (sub-code "Normal")
26          Success (sub-code "Duplicate Unit Number")
27          Command Aborted
28          Unit-Offline
29          Unit-Available
30          Controller Error
31          Drive Error


32      Description:
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-18
        6.8  DETERMINE ACCESS PATHS Command                     08 Apr 82


 1          Class drivers use this command to determine the  topology  of
 2          multi-access  drive configurations.  When sent to a unit that
 3          is "Unit-Online", it causes that unit  and  any  other  units
 4          that  share  its  access  path  to identify themselves to any
 5          other controller to  which  they  are  connected.   The  MSCP
 6          servers  in  the  other controllers will, as a result, become
 7          aware that the unit is online via  the  controller  receiving
 8          this  command.   They will then send an ACCESS PATH attention
 9          message to their "Controller-Online" class drivers, informing
10          the  class  drivers  of  alternate  access paths to the unit.
11          This command must be treated as a no-op that always  succeeds
12          if  the unit is incapable of being connected to more than one
13          controller.

14          The actual notification to another controller, and  thus  the
15          sending  of an ACCESS PATH attention message, is dependent on
16          the proper functioning of  the  unit  and  both  controllers.
17          Furthermore, it need not be 100% reliable.  That is, assuming
18          the unit and both controllers are functioning properly, there
19          need  only  be  a high probability (better than 50%) that the
20          other controller will in fact be notified and send an  ACCESS
21          PATH  attention message.  For this reason, plus the fact that
22          the topology may change while the unit remains "Unit-Online",
23          hosts  that  need  to  know  multi-access drive topology must
24          issue DETERMINE ACCESS PATHS commands  to  all  "Unit-Online"
25          units  on  a  periodic  basis,  such  as  once  every 5 to 15
26          minutes.

27          This command in no way affects the unit's actual state to any
28          controller.  The unit remains "Unit-Online" via the receiving
29          controller and remains "Unit-Offline" via other  controllers.
30          Note,  however,  that  this  command  may  affect  the unit's
31          "Unit-Offline"  sub-state  that   is   perceived   by   other
32          controllers.

33          The processing of this command may, and often will,  cause  a
34          transient  performance  degradation  for  the specified unit.
35          Controllers must consider this performance  degradation  when
36          specifying their controller timeout interval.

37          A controller may, at its option,  treat  this  as  either  an
38          Immediate,   Sequential,  or  Non-sequential  command.   Host
39          command timeout algorithms must treat this as a non-Immediate
40          command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-19
        6.9  ERASE Command                                      08 Apr 82


 1      6.9  ERASE Command



 2      Command category:

 3          Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---                         ---+
17                      |           reserved            |
18                      +---                         ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Express Request
26          Force Error
27          Suppress Error Recovery
28          Suppress Shadowing                  -- ignored
29          Write-back (non-volatile)           -- ignored
30          Write-back (volatile)               -- ignored
31          Write Shadow Set One Unit At a Time -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-20
        6.9  ERASE Command                                      08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available
28          Write Protected
29          Controller Error
30          Drive Error


31      Description:

32          All data in the specified region of the  unit  is  erased  by
33          overwriting it with zero.

34          This command is exactly equivalent in function, although  not
35          in  performance, to a WRITE command which references a buffer
36          that the host has zeroed.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-21
        6.10  FLUSH Command                                     08 Apr 82


 1      6.10  FLUSH Command



 2      Command category:

 3          Immediate or Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---                         ---+
17                      |           reserved            |
18                      +---                         ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Express Request                     -- ignored
26          Flush Entire Unit                   -- ignored
27          Suppress Error Correction           -- ignored
28          Suppress Error Recovery             -- ignored
29          Suppress Shadowing                  -- ignored
30          Volatile Only                       -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-22
        6.10  FLUSH Command                                     08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available


28      Description:

29          All controllers that do not support caching must  treat  this
30          command  as  a  no-op  that always succeeds.  This command is
31          included  in  the  minimal  Disk  MSCP  subset   solely   for
32          compatibility with controllers that do support caching.

33          Controllers that do not support caching should construct this
34          command's  end message by making the following changes to its
35          command message:

36          1.  Substitute the proper "endcode" for the "opcode".

37          2.  Clear the "flags" (end flags) byte, unless the controller
38              has  previously  verified  that  the corresponding "rsvd"
39              byte in the command message was zero.  (Most  controllers
40              will verify that the corresponding "rsvd" byte is zero as
41              part of checking for invalid opcodes).
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-23
        6.10  FLUSH Command                                     08 Apr 82


 1          3.  Substitute the "Success" status code  combined  with  the
 2              "Normal" status sub-code for the "modifiers".

 3          The controller may optionally  validate  this  command  as  a
 4          transfer  command,  similar to the ACCESS and ERASE commands,
 5          before treating it as a no-op.  That is how  the  alternative
 6          status codes listed above may be generated.

 7          Controllers that support caching must treat this command as a
 8          Non-Sequential  command.   Controllers  that  do  not support
 9          caching, however, and therefore treat this command as a no-op
10          as  described  above,  may  treat this as either an Immediate
11          command or as a Non-Sequential command.  Host command timeout
12          algorithms must treat this as a non-Immediate command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-24
        6.11  GET COMMAND STATUS Command                        08 Apr 82


 1      6.11  GET COMMAND STATUS Command



 2      Command category:

 3          Immediate


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      | outstanding reference number  |
14                      +-------------------------------+

15          unit number

16              Must be the same  as  the  "unit  number"  field  in  the
17              outstanding command whose status is to be obtained.  This
18              allows controllers  to  optimize  their  search  for  the
19              outstanding  command.   If  the  incorrect unit number is
20              supplied, some controllers may erroneously conclude  that
21              the   command   is  no  longer  outstanding,  leading  to
22              erroneous command timeouts.

23          outstanding reference number

24              The command reference number of the command whose  status
25              is  to  be  obtained.   Note that a class driver may only
26              obtain the status of commands that it itself has  issued.
27              This derives from the fact that command reference numbers
28              are implicitly qualified by the connection on  which  the
29              command  was issued, so that class drivers have no way of
30              naming commands issued by a different class driver.


31      Allowable modifiers:

32          none
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-25
        6.11  GET COMMAND STATUS Command                        08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      | outstanding reference number  |
11                      +---------------+---------------+
12                      |        command status         |
13                      +---------------+---------------+

14          outstanding reference number

15              The command reference number of the command whose  status
16              has  been  returned.   Identical to the value supplied in
17              the GET COMMAND STATUS command message.

18          command status

19              The amount of work remaining to be done to  complete  the
20              command, expressed as an unsigned integer.  This field is
21              zero if the command is not known to the controller,  such
22              as  when  the  command has already completed.  This field
23              should also be zero if the command has been aborted.  The
24              controller  may  also return zero in this field if it can
25              guarantee that  the  command  will  complete  within  the
26              controller  timeout  interval.  The controller must never
27              return a value of all ones (2**32-1) in  this  field,  as
28              that  value  is  used  to  initialize the command timeout
29              algorithm.

30              The units in which this value is measured  are  arbitrary
31              and  may  be  controller,  device  type,  and/or  command
32              dependent.  However, the units must remain the same for a
33              particular  command  for  as  long  as  that  command  is
34              outstanding.


35      Status Codes:

36          Success (sub-code "Normal")


37      Description:

38          The GET  COMMAND  STATUS  command  is  used  to  monitor  the
39          progress of a command towards completion.  The command status
40          measures the "doneness" of the command.  The  value  returned
41          in  the  command  status  field is guaranteed to not increase
42          over time.   Furthermore,  the  command  status  of  an  MSCP
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-26
        6.11  GET COMMAND STATUS Command                        08 Apr 82


 1          server's oldest outstanding command is guaranteed to decrease
 2          within the controller timeout interval.   This  last  feature
 3          may  be  used  by  a host class driver to detect an insane or
 4          malfunctioning  controller.   See  Section   4.10,   "Command
 5          Timeouts", for more details.

 6          The GET COMMAND  STATUS  command  always  succeeds.   If  the
 7          command  referenced  by the "outstanding reference number" is
 8          not known to the MSCP server or has been  aborted,  then  the
 9          MSCP  server  should return zero for its command status.  The
10          MSCP server may also return zero as the command status of any
11          command  that  will  always  complete  within  the controller
12          timeout  interval.   The  MSCP  server  always  returns   the
13          "Normal"  status code in the GET COMMAND STATUS command's end
14          message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-27
        6.12  GET UNIT STATUS Command                           08 Apr 82


 1      6.12  GET UNIT STATUS Command



 2      Command category:

 3          Immediate


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+


13      Allowable modifiers:

14          Clear Serious Exception             -- ignored

15          Next Unit

16              Requests that the controller return  the  status  of  the
17              next  unit  (in order of ascending unit numbers) that the
18              controller knows  to  exist  and  whose  unit  number  is
19              greater than or equal to the unit number specified in the
20              command.  See Section 4.3, "Unit States", for a  detailed
21              definition  of  which  units must be acknowledged by this
22              modifier.

23              If this modifier is specified, the "unit number" field in
24              the   end   message   corresponds   to   the  unit  whose
25              characteristics are being returned, and is typically  not
26              the  same  as  the  "unit  number"  field  in the command
27              message.  If there are no units that are  both  known  to
28              the controller and whose unit numbers are greater than or
29              equal  to  the  unit  number  specified  in  the  command
30              message, then zero is returned in the "unit number" field
31              of the end message.  The  remaining  fields  of  the  end
32              message  are  identical  to  the  values  that  would  be
33              returned for a GET  UNIT  STATUS  command  with  a  "unit
34              number"  of  zero  and  the  "Next  Unit"  modifier  left
35              unspecified.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-28
        6.12  GET UNIT STATUS Command                           08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |  unit flags   |multi-unit code|
11                      +---------------+---------------+
12                      |           reserved            |
13                      +-------------------------------+
14                      |                               |
15                      +---     unit identifier     ---+
16                      |                               |
17                      +-------------------------------+
18                      |     media type identifier     |
19                      +---------------+---------------+
20                      | shadow status |  shadow unit  |
21                      +---------------+---------------+
22                      |  group size   |   track size  |
23                      +-------+-------+---------------+
24   |                  |uhvrsn | usvrsn| cylinder size |
25                      +-------+-------+---------------+
26                      |copies | RBNs  |    RCT size   |
27                      +-------+-------+---------------+

28          The validity of the unit  characteristics  returned  by  this
29          command  varies  with  the  unit's  state.  Class drivers can
30          determine which characteristics are valid  by  examining  the
31          values returned in the "status" and "unit identifier" fields.
32          See the description below.

33          status

34              Encodes   the   current   unit   state   ("Unit-Offline",
35              "Unit-Available",   "Unit-Online").    See  status  codes
36              listed below.

37          multi-unit code

38              The low byte of this field  identifies  the  access  path
39              between  the  controller  and the unit.  The high byte of
40              this field identifies  the  spindle,  within  the  access
41              path,  to  which  the  unit  belongs.   See Section 4.15,
42              "Multi-unit Drives and Formatters", for more information.

43          unit flags

44              See Sections 5.7 and 6.1, "Unit Flags".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-29
        6.12  GET UNIT STATUS Command                           08 Apr 82


 1          unit identifier

 2              Uniquely identifies the unit among all devices accessible
 3              via   MSCP.   See  Section  4.16,  "Controller  and  Unit
 4              Identifiers".

 5          media type identifier

 6              Identifies the type of media used by this unit,  for  use
 7              by   host  generic  device  allocation  mechanisms.   See
 8              Section 4.17, "Media Type Identifiers".

 9          shadow unit

10              If the controller does not support shadowing, this  field
11              is  always identical to the "unit number" field.  Used by
12              controllers that  support  shadowing  to  indicate  which
13              units belong to the same shadow set.  See Section *****.

14          shadow status

15              Reserved if the controller does  not  support  shadowing.
16              Used  by  controllers  that support shadowing to indicate
17              the progress of a shadow  copy  operation.   See  Section
18              *****.

19          track size

20              The number of logical blocks in a track, or zero  if  the
21              concept  of  a  track is inappropriate to this unit.  See
22              Section 4.11, "Disk Geometry and Format".

23          group size

24              The number of tracks in a group, or zero if  the  concept
25              of  a  group  is inappropriate to this unit.  See Section
26              4.11, "Disk Geometry and Format".  Note that  this  value
27              must always be zero whenever "track size" is zero.

28          cylinder size

29              The number of groups  in  a  cylinder,  or  zero  if  the
30              concept of a cylinder is inappropriate to this unit.  See
31              Section 4.11, "Disk Geometry and Format".  Note that this
32              value must alway be zero whenever "group size" is zero.
33   |  
34   |      usvrsn
35   |  
36   |          The unit's  software,  firmware,  or  microcode  revision
37   |          number.   Always  zero  if  the product's development and
38   |          maintainability groups determine that there is no benefit
39   |          from supporting machine readable revision numbers.
40   |  
41   |      uhvrsn
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-30
        6.12  GET UNIT STATUS Command                           08 Apr 82


 1   |          The unit's hardware revision number.  Always zero if  the
 2   |          product's    development   and   maintainability   groups
 3   |          determine  that  there  is  no  benefit  from  supporting
 4   |          machine readable revision numbers.

 5          RCT size

 6              The difference between the starting logical block numbers
 7              of  successive  copies  of  the  unit's  Replacement  and
 8              Caching Table (RCT).  Excepting only the last copy,  this
 9              value  is also the size of each copy of the RCT.  See DEC
10   |          Standard Disk Format.  Zero if this disk  does  not  have
11   |          any RCT whatsoever;  see Section 4.11, "Disk Geometry and
12   |          Format".

13          RBNs

14              The number of replacement blocks per  track.   Note  that
15              this  is  the  total  number of replacement blocks on the
16              unit if "track size" is zero, since then the entire  unit
17   |          is  a  single track.  See DEC Standard Disk Format.  Zero
18   |          if this disk does  not  have  any  RCT  whatsoever;   see
19   |          Section 4.11, "Disk Geometry and Format".

20          copies

21              The number of copies of the Replacement and Caching Table
22              that  are  stored  on  the  unit.   See DEC Standard Disk
23   |          Format.   Zero  if  this  disk  does  not  have  any  RCT
24   |          whatsoever;    see   Section  4.11,  "Disk  Geometry  and
25   |          Format".


26      Status Codes:

27          Success (sub-code "Normal")
28          Success (sub-code "Duplicate Unit Number")

29              Both of these codes imply that the unit is "Unit-Online".

30          Unit-Offline
31          Unit-Available

32          Controller Error
33          Drive Error

34   |          For both of these status codes the actual drive state  is
35   |          unknown  (although  it will usually be "Unit-Offline" due
36   |          to being inoperative).  Therefore the class driver should
37   |          assume that the unit is "Unit-Offline".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-31
        6.12  GET UNIT STATUS Command                           08 Apr 82


 1      Description:

 2          The GET UNIT STATUS command returns the current  state  of  a
 3          unit  plus  certain unit characteristics.  In particular, the
 4          GET UNIT STATUS command  is  used  to  obtain  host  settable
 5          characteristics and those fixed unit characteristics that are
 6          not normally needed by the class driver.

 7          Class drivers  can  determine  which  of  the  returned  unit
 8          characteristics  are valid by examining the returned "status"
 9          and "unit identifier" fields.  The following cases exist:

10          1.  "status"  is  "Success",  implying  that  the   unit   is
11              "Unit-Online".  All characteristics are valid.

12   |      2.  "status" is anything  other  than  "Success",  and  "unit
13              identifier"  is  not zero.  All unit flags except for the
14              "Removable  media"  flag  are   undefined.    All   other
15              characteristics are valid.

16   |      3.  "status" is anything  other  than  "Success",  and  "unit
17              identifier"  is zero.  Only the "shadow unit" and "shadow
18              status"   characteristics   are   valid.     All    other
19              characteristics are undefined.

20   |      The three cases listed above are  the  only  cases  that  can
21   |      occur.   Note  that  if  "status"  is  "Success"  then  "unit
22   |      identifier" cannot be zero.

23          Rather than testing the entire quadword unit  identifier,  it
24          is  sufficient to merely test the high order word of the unit
25          identifier, containing the class and model code bytes, to see
26          if it is zero or not.

27          Controllers must supply valid values for all  characteristics
28          whenever  the unit is "Unit-Online".  Controllers must supply
29          a  non-zero  unit  identifier  and  valid  values   for   all
30          characteristics except those noted above whenever the unit is
31          "Unit-Available" or the unit is "Unit-Offline" solely due  to
32          being  disabled or known.  Controllers may or may not, at the
33          controller's option, provide valid characteristics  when  the
34   |      unit  is  "Unit-Offline"  for  any  other reason or any other
35   |      status code is returned.
36   |  
37   |      The rules in the above paragraphs can be restated as follows:
38   |  
39   |      1.  If "status" is "Success", then "unit identifier" must  be
40   |          non-zero and all characteristics must be valid.
41   |  
42   |      2.  If "status" is "Unit-Available", then  "unit  identifier"
43   |          must  be  non-zero and almost all characteristics must be
44   |          valid.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-32
        6.12  GET UNIT STATUS Command                           08 Apr 82


 1   |      3.  If "status" is "Unit-Offline" and the sole causes of  the
 2   |          unit  being  offline are it being disabled or known, then
 3   |          "unit  identifier"  must  be  non-zero  and  almost   all
 4   |          characteristics must be valid.
 5   |  
 6   |      4.  If "unit identifier" is zero, then "status"  must  either
 7   |          be  "Unit-Offline"  with  some  reason other than the the
 8   |          unit being disabled or known indicated, or "status"  must
 9   |          be  "Controller  Error"  or  "Drive Error".  Virtually no
10   |          characteristics need be valid.
11   |  
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-33
        6.13  ONLINE Command                                    08 Apr 82


 1      6.13  ONLINE Command



 2      Command categories:

 3          Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |  unit flags   |    reserved   |
14                      +---------------+---------------+
15                      |           reserved            |
16                      +-------------------------------+
17                      |                               |
18                      +---        reserved         ---+
19                      |                               |
20                      +-------------------------------+
21                      |  device dependent parameters  |
22                      +---------------+---------------+
23                      |  copy speed   |  shadow unit  |
24                      +---------------+---------------+

25          unit flags

26              Host settable unit flags.   See  Sections  5.7  and  6.1,
27              "Unit Flags".

28              If the unit is already "Unit-Online" to the class driver,
29              then  the  class  driver must specify the same values for
30              controller supported host  settable  unit  flags  as  are
31              currently  in  effect on the unit.  The controller may or
32              may not, at its option, check that the  flag  values  are
33              the  same.   If  it  does  check,  then it must return an
34              "Invalid Command" status code with "Invalid  Unit  Flags"
35              sub-code  if  they are different.  If the controller does
36              not check that they are the same, then it must ignore the
37              unit flags specified by the class driver and preserve the
38              flag settings currently in effect on the unit.  Note that
39              this checking becomes mandatory, rather than optional, if
40              the controller provides Multi-host Support.

41          device dependent parameters

42              Device  and/or   controller   dependent   device   tuning
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-34
        6.13  ONLINE Command                                    08 Apr 82


 1              parameters.   The  value  zero  in  this field means that
 2              default or  normal  tuning  parameters  should  be  used.
 3              Non-zero   values  for  this  field  should  normally  be
 4              established through  the  system  startup  command  file.
 5              Examples  of  the  use  of  this  field include selecting
 6              alternative  optimization  algorithms  or  enabling   and
 7              disabling automatic (online) diagnosis of the unit.

 8          shadow unit

 9              This field is reserved if the controller does not support
10              shadowing.   Section  *****  describes  how this field is
11              used by controllers that do support shadowing.

12          copy speed

13              This field is reserved if the controller does not support
14              shadowing.   Section  *****  describes  how this field is
15              used by controllers that do support shadowing.


16      Allowable modifiers:

17          Allow Self Destruction

18              Some controllers and/or drives are able to predict that a
19              unit  is  in  danger  of  imminent  self destruction, and
20              automatically spin-down and disable the unit  to  prevent
21              its  destruction.   Such  mechanisms  typically  sense an
22              exponentially  increasing   (correctable)   error   rate,
23              indicating  that  the  disk surface has been contaminated
24              with dust or other foreign objects.  Units that have been
25              disabled  for  this  reason  appear to be "Unit-Offline",
26              with a sub-code indicating that they have  been  disabled
27              by  field service or a diagnostic.  Therefore such a unit
28              cannot normally be brought "Unit-Online".

29              This modifier allows a host to bring a unit that has been
30              so  disabled  "Unit-Online", even though the consequences
31              for the unit may be fatal.  For this reason THIS MODIFIER
32              MUST  NEVER  BE  USED  UNLESS  FIELD  SERVICE  EXPLICITLY
33              DIRECTS A SITE TO DO SO.  When imminent self  destruction
34              has  been predicted for a unit, it is usually possible to
35              make one "last ditch" copy of the  unit  before  it  dies
36              completely,  recovering  all  or  most of the data on the
37              unit.  This modifier exists primarily to simplify support
38              of such a "last ditch" copy.  This modifier also provides
39              a means, if necessary, to work around a  diagnostic  that
40              is erroneously disabling a unit.

41              This modifier must be supported by:
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-35
        6.13  ONLINE Command                                    08 Apr 82


 1              1.  Any controller that may disable a unit for the reason
 2                  mentioned above.

 3              2.  Any controller that may potentially be connected to a
 4                  unit that can disable itself.

 5              3.  Any controller that does not  disable  units  itself,
 6                  but that will respond properly if a drive is disabled
 7                  by some other (more capable) controller.

 8              This modifier must be ignored if the unit  has  not  been
 9              disabled  or  if the controller does not fall into any of
10              the above categories.

11          Clear Serious Exception             -- ignored

12          Ignore Media Format Error

13              Suppresses most checking for "Media  Format  Errors"  and
14              causes  the  "576  Byte  Sectors"  unit  flag  to be host
15              settable.
16   |  
17   |          If either the controller or the  unit  only  support  512
18   |          byte   sectors,   then   setting   this  modifier  merely
19   |          suppresses Media Format  Error  checking.   The  unit  is
20   |          brought  "Unit-Online" as a 512 byte formatted volume and
21   |          the "576 Byte Sectors" unit flag is returned  clear.   If
22   |          both  the  controller  and  the  unit  support  576  byte
23   |          sectors, then the state of the "576  Byte  Sectors"  unit
24   |          flag  (in  the  unit  flags field of this ONLINE command)
25   |          specifies whether the volume is formatted with 512 or 576
26   |          byte  sectors.   The unit is brought "Unit-Online" in the
27   |          specified format, rather than the format being determined
28   |          from the volume itself.

29              Use of this modifier allows the host to set a unit to the
30              wrong  block  or sector size.  Reading a unit that is set
31              to the wrong block or sector size  may  yield  a  mix  of
32              erroneous  "Data Errors", "Drive Errors", and "Controller
33              Errors".  Writing a unit that is set to the  wrong  block
34              or  sector  size may permanently corrupt the volume.  The
35              volume must be re-formatted if this occurs.

36          Enable Set Write Protect

37              Causes the "Write Protect" unit flag to be host settable.
38              If  the  controller does not support Controller Initiated
39              Bad Block Replacement,  then  this  modifier  causes  the
40              state  of  the "Write Protect (software)" unit flag to be
41              copied to the Software Write Protect flag for this  unit.
42              See  Section 4.13, "Write Protection".  This modifier has
43              a somewhat different, although analogous, affect  if  the
44              controller   supports   Controller  Initiated  Bad  Block
45              Replacement.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-36
        6.13  ONLINE Command                                    08 Apr 82


 1          Shadow Unit Specified

 2              All controllers that do not support shadowing must  check
 3              that  this  modifier  is clear.  If this modifier is set,
 4              the controller must return an Invalid Command end message
 5              with  an  "Invalid  Modifiers"  status code.  Controllers
 6              that do support shadowing must support this  modifier  as
 7              described in Section *****.


 8      End message format:

 9                      31                             0 
10                      +-------------------------------+
11                      |   command reference number    |
12                      +---------------+---------------+
13                      |   reserved    |  unit number  |
14                      +---------------+-------+-------+
15                      |    status     | flags |endcode|
16                      +---------------+-------+-------+
17                      |  unit flags   |multi-unit code|
18                      +---------------+---------------+
19                      |           reserved            |
20                      +-------------------------------+
21                      |                               |
22                      +---     unit identifier     ---+
23                      |                               |
24                      +-------------------------------+
25                      |     media type identifier     |
26                      +---------------+---------------+
27                      | shadow status |  shadow unit  |
28                      +---------------+---------------+
29                      |           unit size           |
30                      +-------------------------------+
31                      |      volume serial number     |
32                      +-------------------------------+

33          The format and fields of the ONLINE command's end message are
34          identical  to  the  SET  UNIT  CHARACTERISTICS  command's end
35          message.  See the field descriptions under that command.  The
36          validity of the unit characteristics returned by this command
37          varies with the unit's state.  Class  drivers  can  determine
38          which  characteristics  are  valid  by  examining  the values
39          returned in the "status" and "unit identifier" fields.

40      Status Codes:

41          Success (sub-code "Normal")

42          Success (sub-code "Already Online")

43              The "Already Online" sub-code bit flag is set if and only
44              if  the  unit  is already "Unit-Online" to the requesting
45              class driver.  The unit's state and  characteristics  are
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-37
        6.13  ONLINE Command                                    08 Apr 82


 1              not  altered.   When the unit is already "Unit-Online" to
 2              the  requesting  class  driver,  the  controller   merely
 3              returns  the unit characteristics in the end message with
 4              this status bit flag set, without  performing  any  other
 5              actions.

 6          Invalid Command (sub-code "Invalid Unit Flags")

 7              The unit is already "Unit-Online"  and,  for  those  unit
 8              flags  that  are  both host settable and supported by the
 9              controller, the  class  driver  has  specified  different
10              values  from  those currently in effect on the unit.  The
11              unit remains "Unit-Online".  The host settable unit flags
12              are  not  changed,  and  the  end  message  returns their
13              settings.  Controllers that  do  not  provide  Multi-host
14              Support may, at their option, omit checking that the unit
15              flags are the same.  Such a controller  must  ignore  the
16              class  driver  specified  unit  flags  for units that are
17              already "Unit-Online", thus returning a "Success"  status
18              code with "Already Online" sub-code.

19          Command Aborted

20   |          The command has been rejected and the  unit's  state  has
21   |          not been changed.  If the unit was "Unit-Available" prior
22   |          to   issueing   this   command,   then   it   is    still
23   |          "Unit-Available".   However,  as  the unit's state is not
24   |          reported to the host, the host  should  assume  that  the
25   |          returned unit characteristics are invalid as the unit may
26   |          be "Unit-Offline".

27          Unit-Offline

28              Note that some causes of a unit being "Unit-Offline"  may
29              be   overridden   (suppressed)   by   the   "Allow   Self
30              Destruction" command modifier.

31          Media Format Error

32              The  unit  is  and  remains  "Unit-Available".   However,
33              attention  messages  are suppressed for this unit and the
34              controller attempts to spin-down this unit exactly as  if
35              an  AVAILABLE  command  with the "Spin-down" modifier set
36              were issued.  Note, however,  that  this  error  will  be
37              suppressed  and  the unit brought "Unit-Online" anyway if
38              the "Ignore Media Format Error" command modifier is  set.
39              See the modifier description above.

40          Controller Error

41   |          The actual drive state is unknown.  Therefore  the  class
42   |          driver should assume that the unit is "Unit-Offline".

43          Drive Error
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-38
        6.13  ONLINE Command                                    08 Apr 82


 1              The unit is "Unit-Offline" due to being inoperative.  The
 2              controller must suppress AVAILABLE attention messages for
 3              the unit and attempt to spin-down the unit, exactly as if
 4              an  AVAILABLE  command  with the "Spin-down" modifier set
 5              were  issued  for   the   unit.    The   controller   may
 6              subsequently    report   the   unit   as   being   either
 7              "Unit-Offline" or "Unit-Available".   The  reported  unit
 8              state  will depend upon exactly how the unit is "broken",
 9              and the interactions of the failure with the controller's
10              perception of the unit's state.


11      Description:

12          The ONLINE command is used to bring a unit "Unit-Online", set
13          host  settable  unit  characteristics,  and obtain those unit
14          characteristics that are essential for  proper  class  driver
15          operation.   The unit is spun-up, if necessary, and its heads
16          are loaded  prior  to  returning  the  ONLINE  command's  end
17          message.  Host settable characteristics are set exactly as if
18          a SET UNIT CHARACTERISTICS  command  were  issued.   See  the
19          description  of  that command.  Host settable characteristics
20          are set after the unit has been successfully spun-up and  any
21          other  validity  checks have succeeded.  Note that the unit's
22          host settable characteristics are NOT altered if the unit  is
23          already "Unit-Online".

24          The class driver must check if the "Controller Initiated  Bad
25          Block Replacement" unit flag is set or clear after bringing a
26          unit "Unit-Online".  If it is clear (implying that  the  host
27          is  performing  bad block replacement), then the class driver
28          must invoke a process that will access the unit's Replacement
29          and  Caching  Table  to  determine if a bad block replacement
30          operation has been partially performed or if the unit must be
31          write   protected.    The  details  of  this  check  and  its
32          consequences  are  described  in  Section  4.12,  "Bad  Block
33          Replacement", and DEC Standard Disk Format.  Controllers that
34          support Controller Initiated Bad  Block  Replacement  perform
35          these checks themselves.

36          Note that the format of the ONLINE command's end  message  is
37          identical  to  the  SET  UNIT  CHARACTERISTICS  command's end
38          message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-39
        6.14  READ Command                                      08 Apr 82


 1      6.14  READ Command



 2      Command category:

 3          Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---         buffer          ---+
17                      |                               |
18                      +---       descriptor        ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Compare
26          Express Request
27          Suppress Caching (high speed)       -- ignored
28          Suppress Caching (low speed)        -- ignored
29          Suppress Error Correction
30          Suppress Error Recovery
31          Suppress Shadowing                  -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-40
        6.14  READ Command                                      08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available
28          Compare Error
29          Data Error
30          Host Buffer Access Error
31          Controller Error
32          Drive Error


33      Description:

34          Data is read from  the  unit  and  transferred  to  the  host
35          buffer.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-41
        6.15  REPLACE Command                                   08 Apr 82


 1      6.15  REPLACE Command



 2      Command category:

 3          Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |    replacement block number   |
14                      +-------------------------------+
15                      |                               |
16                      +---                         ---+
17                      |           reserved            |
18                      +---                         ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+

23          replacement block number

24              Identifies the replacement block that has been  allocated
25              to replace the bad logical block.

26          logical block number

27              Identifies the bad logical block that is being replaced.


28      Allowable modifiers:

29          Clear Serious Exception             -- ignored
30          Express Request

31          Primary Replacement Block

32              Must be set if and only if the "replacement block number"
33              specifies  the  primary  replacement  block  for "logical
34              block number".  I.e., must be set  if  and  only  if  the
35              following expression is true:

36                   replacement block number =
37                             logical block number / track size * RBNs
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-42
        6.15  REPLACE Command                                   08 Apr 82


 1              where "track size" and "RBNs"  are  unit  characteristics
 2              obtained via the GET UNIT CHARACTERISTICS command and "/"
 3              denotes integer (truncating) division.  See DEC  Standard
 4              Disk   Format  for  more  information.   Note  that  this
 5              modifier  is  redundant  information  provided  for   the
 6              convenience of the controller.


 7      End message format:

 8                      31                             0 
 9                      +-------------------------------+
10                      |   command reference number    |
11                      +---------------+---------------+
12                      |   reserved    |  unit number  |
13                      +---------------+-------+-------+
14                      |    status     | flags |endcode|
15                      +---------------+-------+-------+

16      Status Codes:

17          Success (sub-code "Normal")
18          Success (sub-code "Duplicate Unit Number")
19          Invalid Command (sub-code "Invalid Replacement Block Number")
20          Invalid Command (sub-code "Invalid Logical Block Number")
21          Command Aborted
22          Unit-Offline
23          Unit-Available
24          Write Protected
25          Controller Error
26          Drive Error


27      Description:

28          The specified logical block is flagged to  indicate  that  it
29          has  been replaced with the specified replacement block.  The
30          volume's Replacement and Caching Table must have been updated
31          prior to using this command, and the replacement block should
32          be initialized with a write command to the same logical block
33          number  after  using  this  command.   See Section 4.12, "Bad
34          Block Replacement", and DEC Standard  Disk  Format  for  more
35          information on the use and function of this command.

36          Note that this command  is  unique  in  that  it  becomes  an
37          invalid  command if the controller supports an MSCP option --
38          this  command  is  invalid  for  controllers   that   support
39          Controller Initiated Bad Block Replacement.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-43
        6.16  SET CONTROLLER CHARACTERISTICS Command            08 Apr 82


 1      6.16  SET CONTROLLER CHARACTERISTICS Command



 2      Command category:

 3          Immediate


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |    reserved   |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      | cntrlr. flags |  MSCP version |
14                      +---------------+---------------+
15                      |   reserved    |  host timeout |
16                      +---------------+---------------+
17                      |           quad-word           |
18                      +---                         ---+
19                      |         time and date         |
20                      +-------------------------------+
21   |                  |controller dependent parameters|
22   |                  +-------------------------------+

23          MSCP version

24              Host class drivers must supply the  value  zero  in  this
25              field.  MSCP servers must verify this value and, if it is
26              not zero, return an Invalid Command  end  message.   This
27              value  will  be incremented if MSCP is ever modified in a
28              way that is not upwards compatible.

29          cntrlr. flags

30              Host settable controller flags.   See  Sections  5.8  and
31              6.2, "Controller Flags".

32          host timeout

33              The time interval that the controller should use for  the
34              host  access  timeout  with  this  host,  or  zero if the
35              controller should disable the  host  access  timeout  for
36              this  host.   Expressed  as an unsigned binary integer in
37              units of seconds.  Controllers should use a default  host
38              access  timeout of 60 seconds if they have not received a
39              SET CONTROLLER  CHARACTERISTICS  command  since  becoming
40              "Controller-Online".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-44
        6.16  SET CONTROLLER CHARACTERISTICS Command            08 Apr 82


 1              Even though this is a sixteen bit field, controllers  may
 2              treat  all  values  greater  than  255 as if 255 had been
 3              specified, and all values between 1 and 9 as  if  10  had
 4              been specified.  See Section 4.9, "Host Access Timeouts".

 5          quad-word time and date

 6              The current time and date, expressed  as  the  number  of
 7              clunks  since  00:00  o'clock,  November 17, 1858 (in the
 8              local time zone), or zero if the current time and date is
 9              not  available.  A clunk is 100 nanoseconds.  This is the
10              standard VAX/VMS time and date format.  The use  that  is
11              made of the current time and date and the action taken if
12              it is  not  supplied  (i.e.,  if  zero  is  supplied)  is
13              controller  dependent,  and  should  be described in each
14              controller's Functional Specification.  Controllers  must
15              not  require  that a time and date be supplied for proper
16              operation.
17   |  
18   |      controller dependent parameters
19   |  
20   |          Controller dependent tuning parameters.  The  value  zero
21   |          in  this  field  means  that  default  or  normal  tuning
22   |          parameters should be  used.   Non-zero  values  for  this
23   |          field  should  normally be established through the system
24   |          startup command file.


25      Allowable modifiers:

26          none


27      End message format:

28                      31                             0 
29                      +-------------------------------+
30                      |   command reference number    |
31                      +---------------+---------------+
32                      |   reserved    |    reserved   |
33                      +---------------+-------+-------+
34                      |    status     | flags |endcode|
35                      +---------------+-------+-------+
36                      | cntrlr. flags |  MSCP version |
37                      +-------+-------+---------------+
38   |                  |chvrsn | csvrsn|cntrlr. timeout|
39                      +-------+-------+---------------+
40                      |                               |
41                      +---  controller identifier  ---+
42                      |                               |
43                      +---------------+---------------+
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-45
        6.16  SET CONTROLLER CHARACTERISTICS Command            08 Apr 82


 1          cntrlr.  flags

 2              See Sections 5.8 and 6.2, "Controller Flags".

 3          cntrlr.  timeout

 4              The controller timeout interval;  the minimum  amount  of
 5              time  that  the  controller  needs  to  guarantee it will
 6              accomplish useful work on its oldest outstanding command.
 7              Expressed  as  an  unsigned  binary  integer  in units of
 8              seconds.  This value must not exceed 255 (one byte), even
 9              though  a  sixteen  bit  field  has  been  provided.  See
10              Section 4.10, "Command Timeouts".
11   |  
12   |      csvrsn
13   |  
14   |          The  controller's  software,   firmware,   or   microcode
15   |          revision   number.    Always   zero   if   the  product's
16   |          development and  maintainability  groups  determine  that
17   |          there  is  no  benefit  from  supporting machine readable
18   |          revision numbers.
19   |  
20   |      chvrsn
21   |  
22   |          The controller's hardware revision number.   Always  zero
23   |          if  the  product's development and maintainability groups
24   |          determine  that  there  is  no  benefit  from  supporting
25   |          machine readable revision numbers.

26          controller identifier

27              Uniquely identifies  the  controller  among  all  devices
28              accessible  via  MSCP.  See Section 4.16, "Controller and
29              Unit Identifiers".


30      Status Codes:

31          Success (sub-code "Normal")


32      Description:

33          The SET CONTROLLER CHARACTERISTICS command is used to set and
34          obtain  controller  characteristics.   The  default value for
35          "cntrlr. flags"  is  all  flags  clear  (i.e.,  all  messages
36          disabled).   The  default  value  for  "host  timeout"  is 60
37          seconds.  These default values are used from  the  time  that
38          the controller becomes "Controller-Online" to a host until it
39          stops being "Controller-Online" or until the  host  issues  a
40          SET CONTROLLER CHARACTERISTICS command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-46
        6.17  SET UNIT CHARACTERISTICS Command                  08 Apr 82


 1      6.17  SET UNIT CHARACTERISTICS Command



 2      Command category:

 3          Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |  unit flags   |    reserved   |
14                      +---------------+---------------+
15                      |           reserved            |
16                      +-------------------------------+
17                      |                               |
18                      +---        reserved         ---+
19                      |                               |
20                      +-------------------------------+
21                      |  device dependent parameters  |
22                      +---------------+---------------+
23                      |  copy speed   |  shadow unit  |
24                      +---------------+---------------+

25          unit flags

26              Host settable unit flags.   See  Sections  5.7  and  6.1,
27              "Unit Flags".

28          device dependent parameters

29              Device  and/or   controller   dependent   device   tuning
30              parameters.   The  value  zero  in  this field means that
31              default or  normal  tuning  parameters  should  be  used.
32              Non-zero   values  for  this  field  should  normally  be
33              established through  the  system  startup  command  file.
34              Examples  of  the  use  of  this  field include selecting
35              alternative  optimization  algorithms  or  enabling   and
36              disabling automatic (online) diagnosis of the unit.

37          shadow unit

38              This field is reserved if the controller does not support
39              shadowing.   Section  *****  describes  how this field is
40              used by controllers that do support shadowing.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-47
        6.17  SET UNIT CHARACTERISTICS Command                  08 Apr 82


 1          copy speed

 2              This field is reserved if the controller does not support
 3              shadowing.   Section  *****  describes  how this field is
 4              used by controllers that do support shadowing.


 5      Allowable modifiers:

 6          Clear Serious Exception             -- ignored

 7          Enable Set Write Protect

 8              Causes the "Write Protect" unit flag to be host settable.
 9              If  the  controller does not support Controller Initiated
10              Bad Block Replacement,  then  this  modifier  causes  the
11              state  of  the "Write Protect (software)" unit flag to be
12              copied to the Software Write Protect flag for this  unit.
13              See  Section 4.13, "Write Protection".  This modifier has
14              a somewhat different, although analogous, effect  if  the
15              controller   supports   Controller  Initiated  Bad  Block
16              Replacement.

17          Shadow Unit Specified

18              All controllers that do not support shadowing must  check
19              that  this modifier is not set.  If this modifier is set,
20              the controller must return an Invalid Command end message
21              with  an  "Invalid  Modifiers"  status code.  Controllers
22              that do support shadowing must support this  modifier  as
23              described in Section *****.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-48
        6.17  SET UNIT CHARACTERISTICS Command                  08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |  unit flags   |multi-unit code|
11                      +---------------+---------------+
12                      |           reserved            |
13                      +-------------------------------+
14                      |                               |
15                      +---     unit identifier     ---+
16                      |                               |
17                      +-------------------------------+
18                      |     media type identifier     |
19                      +---------------+---------------+
20                      | shadow status |  shadow unit  |
21                      +---------------+---------------+
22                      |           unit size           |
23                      +-------------------------------+
24                      |      volume serial number     |
25                      +-------------------------------+

26          The validity of the unit  characteristics  returned  by  this
27          command  and the ONLINE command varies with the unit's state.
28          Class drivers can determine which characteristics  are  valid
29          by  examining  the  values returned in the "status" and "unit
30          identifier" fields.  See the description below.

31          multi-unit code

32              The low byte of this field  identifies  the  access  path
33              between  the  controller  and the unit.  The high byte of
34              this field identifies  the  spindle,  within  the  access
35              path,  to  which  the  unit  belongs.   See Section 4.15,
36              "Multi-Unit Drives and Formatters", for more information.

37          unit flags

38              See Sections 5.7 and 6.1, "Unit Flags".

39          unit identifier

40              Uniquely identifies the unit among all devices accessible
41              via   MSCP.   See  Section  4.16,  "Controller  and  Unit
42              Identifiers".

43          media type identifier

44              Identifies the type of media used by this unit,  for  use
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-49
        6.17  SET UNIT CHARACTERISTICS Command                  08 Apr 82


 1              by   host  generic  device  allocation  mechanisms.   See
 2              Section 4.17, "Media Type Identifiers".

 3          shadow unit

 4              If the controller does not support shadowing, this  field
 5              is  always identical to the "unit number" field.  Used by
 6              controllers that  support  shadowing  to  indicate  which
 7              units belong to the same shadow set.  See Section *****.

 8          shadow status

 9              Reserved if the controller does  not  support  shadowing.
10              Used  by  controllers  that support shadowing to indicate
11              the progress of a shadow  copy  operation.   See  Section
12              *****.

13          unit size

14              The number of logical blocks in the  host  area  of  this
15              unit.   This  value  does  NOT  include the logical block
16              range occupied by  the  unit's  Replacement  and  Caching
17              Table.   The  logical  block number of the first block of
18              the unit's Replacement and Caching Table is equal to this
19              value.

20          volume serial number

21              The low order 32 bits of the serial number of the  volume
22              that  is  mounted  on this unit.  Zero if the volume does
23              not have  a  serial  number.   When  displayed  in  human
24              readable  form,  this number should be formatted as a ten
25              digit  decimal  number  with   leading   zeros   printed.
26              Undefined    if    the    unit   is   "Unit-Offline"   or
27              "Unit-Available", or if the "Ignore Media  Format  Error"
28              modifier was set in the ONLINE command that first brought
29              this unit "Unit-Online".

30              Hosts must not assume that the  value  returned  in  this
31              field  uniquely  identifies  the  volume.   Although this
32              value  often  will  be  unique,  the  uniqueness  is  not
33              guaranteed, especially across media obtained from several
34              independent  suppliers.   Also,  media  that  must   meet
35              external  (industry  compatible)  format  standards  will
36              typically be unable to implement a volume serial  number.
37              This field will always be zero for such media.


38      Status Codes:

39          Success (sub-code "Normal")
40          Success (sub-code "Duplicate Unit Number")

41              Imply that the unit is "Unit-Online".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-50
        6.17  SET UNIT CHARACTERISTICS Command                  08 Apr 82


 1          Command Aborted

 2   |          The command has been rejected and the  unit's  state  and
 3   |          context  have not been changed.  That is, the unit's unit
 4   |          flags,  device  dependent  parameters,  and  shadow   set
 5   |          membership are un-changed.  Since the unit's state is not
 6   |          reported to the host, the host  should  assume  that  the
 7   |          returned unit characteristics are invalid as the unit may
 8   |          be "Unit-Offline".
 9   |  
10   |      Unit-Offline
11   |      Unit-Available
12   |  
13   |      Controller Error
14   |      Drive Error
15   |  
16   |          For both of these status codes the actual drive state  is
17   |          unknown  (although  it will usually be "Unit-Offline" due
18   |          to being inoperative).  Therefore the class driver should
19   |          assume that the unit is "Unit-Offline".


20      Description:

21          The SET UNIT CHARACTERISTICS command  is  used  to  set  host
22          settable   unit   characteristics   and   obtain  those  unit
23          characteristics that are essential for  proper  class  driver
24          operation.   This  command  never  alters  the  unit's  state
25          ("Unit-Online",  "Unit-Available",  "Unit-Offline").   It  is
26          meaningless  to  set host settable characteristics for a unit
27          that is "Unit-Available" or "Unit-Offline".

28          The  ONLINE  command  performs  a  SET  UNIT  CHARACTERISTICS
29   |      operation after bringing a unit "Unit-Online".  Note that the
30   |      discussion below names status codes that may be returned  for
31   |      an  ONLINE  command as well as those that may be returned for
32   |      SET UNIT CHARACTERISTICS.

33          Class drivers  can  determine  which  of  the  returned  unit
34          characteristics  are valid by examining the returned "status"
35          and "unit identifier" fields.  The following cases exist:

36   |      1.  "status" is  "Success"  or  "Invalid  Command"  (sub-code
37   |          "Invalid   Unit   Flags"),  implying  that  the  unit  is
38              "Unit-Online".  All characteristics are valid.  Note that
39              the  value  of "volume serial number" is undefined if the
40              unit was first brought "Unit-Online" by an ONLINE command
41              with the "Ignore Media Format Error" modifier.

42   |      2.  "status" is anything other  than  "Success"  or  "Invalid
43   |          Command"  (sub-code  "Invalid  Unit  Flags"),  and  "unit
44              identifier" is not zero.  All unit flags except  for  the
45              "Removable  media"  flag  are  undefined  and the "volume
46              serial number" is undefined.  All  other  characteristics
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-51
        6.17  SET UNIT CHARACTERISTICS Command                  08 Apr 82


 1              are valid.

 2   |      3.  "status" is anything other  than  "Success"  or  "Invalid
 3   |          Command"  (sub-code  "Invalid  Unit  Flags"),  and  "unit
 4              identifier" is zero.  Only the "shadow unit" and  "shadow
 5              status"    characteristics    are   valid.    All   other
 6              characteristics are undefined.

 7   |      The three cases listed above are  the  only  cases  that  can
 8   |      occur.   Note  that  "unit  identifier"  cannot  be zero when
 9   |      "status" is either "Success" or "Invalid  Command"  (sub-code
10   |      "Invalid Unit Flags").

11          Rather than testing the entire quadword unit  identifier,  it
12          is  sufficient to merely test the high order word of the unit
13          identifier, containing the class and model code bytes, to see
14          if it is zero or not.

15          Controllers must supply valid values for all  characteristics
16          whenever  the unit is "Unit-Online".  Controllers must supply
17          a  non-zero  unit  identifier  and  valid  values   for   all
18          characteristics except those noted above whenever the unit is
19          "Unit-Available" or the unit is "Unit-Offline" solely due  to
20          being  disabled or known.  Controllers may or may not, at the
21          controller's option, provide valid characteristics  when  the
22          unit is "Unit-Offline" for any other reason.
23   |  
24   |      The rules in the above paragraphs can be restated as follows:
25   |  
26   |      1.  If "status" is "Success" or "Invalid  Command"  (sub-code
27   |          "Invalid  Unit  Flags"),  then  "unit identifier" must be
28   |          non-zero and all characteristics must be valid.
29   |  
30   |      2.  If "status" is "Unit-Available" or "Media Format  Error",
31   |          then  "unit  identifier"  must be non-zero and almost all
32   |          characteristics must be valid.
33   |  
34   |      3.  If "status" is "Unit-Offline" and the sole causes of  the
35   |          unit  being  offline are it being disabled or known, then
36   |          "unit  identifier"  must  be  non-zero  and  almost   all
37   |          characteristics must be valid.
38   |  
39   |      4.  If "unit identifier" is zero, then either  "status"  must
40   |          be  "Unit-Offline"  with  some  reason other than the the
41   |          unit being disabled or known indicated, or "status"  must
42   |          be   "Controller   Error",  "Drive  Error",  or  "Command
43   |          Aborted".  Virtually no characteristics need be valid.
44   |  

45          Note  that  the  format  of  the  SET  UNIT   CHARACTERISTICS
46          command's  end  message  is  identical  to that of the ONLINE
47          command's end message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-52
        6.18  WRITE Command                                     08 Apr 82


 1      6.18  WRITE Command



 2      Command category:

 3          Non-Sequential


 4      Command message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |   modifiers   | rsvd  | opcode|
12                      +---------------+-------+-------+
13                      |          byte count           |
14                      +-------------------------------+
15                      |                               |
16                      +---         buffer          ---+
17                      |                               |
18                      +---       descriptor        ---+
19                      |                               |
20                      +-------------------------------+
21                      |      logical block number     |
22                      +-------------------------------+


23      Allowable modifiers:

24          Clear Serious Exception             -- ignored
25          Compare
26          Express Request
27          Force Error

28          Suppress Error Correction

29              Note that this modifier only affects the compare pass  of
30              a write compare operation.  It has no affect on the write
31              operation itself.

32          Suppress Error Recovery
33          Suppress Shadowing                  -- ignored
34          Write-back (non-volatile)           -- ignored
35          Write-back (volatile)               -- ignored
36          Write Shadow Set One Unit At a Time -- ignored
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-53
        6.18  WRITE Command                                     08 Apr 82


 1      End message format:

 2                      31                             0 
 3                      +-------------------------------+
 4                      |   command reference number    |
 5                      +---------------+---------------+
 6                      |   reserved    |  unit number  |
 7                      +---------------+-------+-------+
 8                      |    status     | flags |endcode|
 9                      +---------------+-------+-------+
10                      |          byte count           |
11                      +-------------------------------+
12                      |                               |
13                      +---                         ---+
14                      |           undefined           |
15                      +---                         ---+
16                      |                               |
17                      +-------------------------------+
18                      |        first bad block        |
19                      +-------------------------------+


20      Status Codes:

21          Success (sub-code "Normal")
22          Success (sub-code "Duplicate Unit Number")
23          Invalid Command (sub-code "Invalid Byte Count")
24          Invalid Command (sub-code "Invalid Logical Block Number")
25          Command Aborted
26          Unit-Offline
27          Unit-Available
28          Write Protected
29          Compare Error
30          Data Error
31          Host Buffer Access Error
32          Controller Error
33          Drive Error


34      Description:

35          Data is fetched from the host data buffer and written to  the
36          unit.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-54
        6.19  Invalid Command End Message                       08 Apr 82


 1      6.19  Invalid Command End Message

 2      The  controller  returns  an  Invalid  Command  end  message  for
 3      commands that violate the MSCP protocol.


 4      End message format:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |   reserved    |  unit number  |
10                      +---------------+-------+-------+
11                      |    status     | flags |endcode|
12                      +---------------+-------+-------+
13   |                  |                               |
14   |                  /   echoed command parameters   /
15   |                  /          (see below)          /
16   |                  |                               |
17   |                  +-------------------------------+


18      Status Codes:

19          Invalid Command (sub-code "Invalid Message Length")
20          Invalid Command (sub-code "Invalid MSCP Version")
21          Invalid Command (sub-code "Invalid Opcode")
22          Invalid Command (sub-code "Invalid Modifier")
23          Invalid Command (sub-code "Invalid Unit Flags")
24          Invalid Command (sub-code "Invalid Controller Flags")
25          Invalid Command (sub-codes used for reserved fields)


26      Description:

27          The controller returns this end message for any command  that
28          violates  the  MSCP  protocol.   Protocol  violations include
29          illegal opcodes, messages that are too short to  include  the
30          parameters  required by the opcode, reserved bits set in flag
31          fields, and non-zero values in reserved fields.
32   |  
33   |      In order to aid error  diagnosis,  the  Invalid  Command  End
34   |      Message  is  largely an image of the invalid command that was
35   |      received from the host.  The controller makes  the  following
36   |      changes  to  the invalid command that it received in order to
37   |      construct the Invalid Command End Message:
38   |  
39   |      1.  The controller stores the constant  (OP.END)  defined  in
40   |          Table  A-1  in the "endcode" field, in order to flag this
41   |          as an Invalid Command End Message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-55
        6.19  Invalid Command End Message                       08 Apr 82


 1   |      2.  The controller may, at its option, either  copy  the  end
 2   |          message  flags  field  ("flags")  from  the corresponding
 3   |          field in the  invalid  command  or  else  clear  the  end
 4   |          message flags field.
 5   |  
 6   |      3.  The controller stores The "Invalid Command"  status  code
 7   |          with the sub-code appropriate for the field in error (any
 8   |          one field, at the controller's option, if several are  in
 9   |          error) in "status".
10   |  
11   |      4.  The controller  may  optionally  truncate  the  parameter
12   |          fields  ("echoed  command  parameters")  to  some  length
13   |          convenient for the controller.  Controllers should try to
14   |          echo as much of the parameters as possible.
15   |  
16   |      The contents of any field copied from the invalid command are
17   |      undefined  if  the  command  message was too short to contain
18   |      that field.  This primarily applies to the "command reference
19   |      number" and "unit number" fields.

20          The controller may or may  not,  at  its  option,  enter  the
21          "Controller-Available"  state  relative  to  the issuing host
22          class driver after it returns this end message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-56
        6.20  ACCESS PATH Attention Message                     08 Apr 82


 1      6.20  ACCESS PATH Attention Message



 2      Attention message format:

 3                      31                             0 
 4                      +-------------------------------+
 5                      |           reserved            |
 6                      +---------------+---------------+
 7                      |   reserved    |  unit number  |
 8                      +---------------+-------+-------+
 9                      |   reserved    | rsvd  |atncode|
10                      +---------------+-------+-------+

11          unit number

12              Identifies the unit for which an alternate access path is
13              being reported.


14      Description:

15          MSCP servers use this attention message to  report  alternate
16          access  paths  to  multi-access  units.  This message reports
17          that the specified unit is  potentially  accessible  via  the
18          sending  MSCP server -- i.e., it would be "Unit-Available" if
19          it and all units that share  its  access  path  ceased  being
20          "Unit-Online"  via  another  controller.   The specific event
21          that causes an MSCP server to send this attention message  is
22          the   receipt,  by  the  controller  to  which  the  unit  is
23          "Unit-Online", of a DETERMINE  ACCESS  PATHS  command.   This
24          attention  message  is  sent  to  all  class drivers that are
25          "Controller-Online" to  the  MSCP  server  and  have  enabled
26          attention messages.  See Section 4.18, "Multi-Access Drives",
27          for more information.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-57
        6.21  AVAILABLE Attention Message                       08 Apr 82


 1      6.21  AVAILABLE Attention Message



 2      Attention message format:

 3                      31                             0 
 4                      +-------------------------------+
 5                      |           reserved            |
 6                      +---------------+---------------+
 7                      |   reserved    |  unit number  |
 8                      +---------------+-------+-------+
 9                      |   reserved    | rsvd  |atncode|
10                      +---------------+-------+-------+
11                      |  unit flags   |multi-unit code|
12                      +---------------+---------------+
13                      |           undefined           |
14                      +-------------------------------+
15                      |                               |
16                      +---     unit identifier     ---+
17                      |                               |
18                      +-------------------------------+
19                      |     media type identifier     |
20                      +---------------+---------------+
21                      |                               |
22                      /         0 to 16 bytes         /
23                      /       of undefined data       /
24                      |                               |
25                      +-------------------------------+

26          unit number

27              Identifies the unit that just became "Unit-Available".

28          multi-unit code
29          unit flags
30          unit identifier
31          media type identifer

32              Identical to the corresponding fields  in  the  GET  UNIT
33              STATUS  or SET UNIT CHARACTERISTICS command end messages.
34              These fields must be valid as defined for the unit  being
35              "Unit-Available",  regardless  of the actual state of the
36              unit when the message is sent.  That is, the  "multi-unit
37              code",  "unit  identifier",  and  "media type identifier"
38              must all be valid and the  "Removable  media"  unit  flag
39              must be valid.


40      Description:
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-58
        6.21  AVAILABLE Attention Message                       08 Apr 82


 1          An MSCP server sends an  AVAILABLE  attention  message  to  a
 2          "Controller-Online"  class  driver when a unit asynchronously
 3          becomes  "Unit-Available"  to  that  class   driver,   unless
 4          AVAILABLE  attention  messages  have been suppressed for that
 5          unit by an AVAILABLE command with the "Spin-down" modifier or
 6          by  an  error  with  similar  side  effects.   Changes to the
 7          "Unit-Available" state due to the class driver itself issuing
 8          an  AVAILABLE  command are synchronous.  All other changes to
 9          "Unit-Available" are asynchronous.  See  Section  4.3,  "Unit
10          States".

11          The actual sending of an AVAILABLE attention message  may  be
12          delayed  for  an arbitrarily long time, due to communications
13          mechanism flow control, from the time that the unit  actually
14          becomes  "Unit-Available".   The  message must not be sent if
15          the class driver ceases to be "Controller-Online" during this
16          delay.   The  message must be sent anyway if the unit, or any
17          unit  with  which  it  shares   an   access   path,   becomes
18          "Unit-Online"  via another controller during this delay.  The
19          message may or may not be sent, at the  controller's  option,
20          if  the  unit  ceases  to  be  "Unit-Available" for any other
21          reason during this delay.

22          Note that, due  to  these  delays,  it  is  possible  for  an
23          AVAILABLE  attention  message  to be received after the class
24          driver has already brought the unit "Unit-Online".  Therefore
25          class  drivers  must  not use AVAILABLE attention messages to
26          flag "Unit-Online" units as having  become  "Unit-Available".
27          The  proper  procedure  is  to issue a command, such as a GET
28          UNIT STATUS, to a "Unit-Online" unit for which  an  AVAILABLE
29          attention  message  has been received, and only flag the unit
30          as having become "Unit-Available" if the command returns that
31          status code.

32          AVAILABLE attention messages are not sent for units that  are
33          already   "Unit-Available"   when   a  class  driver  enables
34          attention messages.  Class drivers that need to be  aware  of
35          all  "Unit-Available"  units  must enable attention messages,
36          then scan all units via the GET UNIT STATUS command with  the
37          "Next Unit" modifier set to locate all units that are already
38          "Unit-Available".   All  units   that   subsequently   become
39          "Unit-Available" will be reported with an AVAILABLE attention
40          message.

41          An MSCP server may  send  redundant  or  erroneous  AVAILABLE
42          attention  messages  at  any  time.   The  frequency  of such
43          messages must be low enough that  they  do  not  represent  a
44          significant  overhead  for either hosts or the communications
45          mechanism.  The information contained in such messages  (unit
46          number,  unit  identifier,  media type identifier, etc.) must
47          correspond to an actual, physical unit  that  is  potentially
48          accessible  via  that  MSCP  server  (i.e.,  connected to the
49          controller), although the unit need not be  "Unit-Available".
50          Note  that  hosts  must be able to handle seemingly erroneous
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-59
        6.21  AVAILABLE Attention Message                       08 Apr 82


 1          AVAILABLE attention messages in any case,  since  the  unit's
 2          state  may  change  before  the  host can act on an otherwise
 3          correct message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-60
        6.22  DUPLICATE UNIT NUMBER Attention Message           08 Apr 82


 1      6.22  DUPLICATE UNIT NUMBER Attention Message



 2      Attention message format:

 3                      31                             0 
 4                      +-------------------------------+
 5                      |           reserved            |
 6                      +---------------+---------------+
 7                      |   reserved    |  unit number  |
 8                      +---------------+-------+-------+
 9                      |   reserved    | rsvd  |atncode|
10                      +---------------+-------+-------+

11          unit number

12              Identifies the unit number that is duplicated on  two  or
13              more units.


14      Description:

15          An MSCP server sends DUPLICATE UNIT NUMBER attention messages
16          to  notify  hosts  that  two or more units of the same device
17          class have the same unit number.  This allows  the  hosts  to
18          complain  to an operator, who can correct the condition.  The
19          DUPLICATE UNIT NUMBER attention  messages  are  sent  to  all
20          hosts that are "Controller-Online" and have enabled attention
21          messages.  See Section 4.4, "Unit Numbers",  for  a  detailed
22          discussion  of  the handling of duplicate unit numbers.  Note
23          that a  DUPLICATE  UNIT  NUMBER  attention  message  is  sent
24          regardless   of   whether   or   not  one  of  the  units  is
25          "Unit-Online".

26          The actual sending  of  a  DUPLICATE  UNIT  NUMBER  attention
27          message  may  be delayed for an arbitrarily long time, due to
28          communications mechanism flow control, from the time that the
29          controller  first  detects  the  duplicate  unit number.  The
30          message must not be sent if the class  driver  ceases  to  be
31          "Controller-Online"  during  this  delay.  The message may or
32          may not be sent, at the controller's option, if the duplicate
33          unit number condition disappears during this delay.

34          DUPLICATE UNIT NUMBER attention messages  are  not  sent  for
35          duplicate  unit  number  conditions that already exist when a
36          class driver enables attention messages.  Class drivers  that
37          need to be aware of all duplicate unit number conditions must
38          enable attention messages, then scan all units  via  the  GET
39          UNIT  STATUS  command  with  the  "Next Unit" modifier set to
40          locate  all  duplicate  unit  numbers.   All  duplicate  unit
41          numbers  that  the  controller  subsequently  detects will be
42          reported with a DUPLICATE UNIT NUMBER attention message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Minimal Disk MSCP Subset                                Page 6-61
        6.22  DUPLICATE UNIT NUMBER Attention Message           08 Apr 82


 1          An MSCP server  may  send  redundant  DUPLICATE  UNIT  NUMBER
 2          attention  messages.   The frequency of such messages must be
 3          low enough that they do not represent a significant  overhead
 4          for   either   hosts   or   the   communications   mechanism.
 5          Furthermore,  the  duplicate  unit  number  condition   being
 6          reported  must  actually  exist  at  the time the MSCP server
 7          decides to  generate  the  DUPLICATE  UNIT  NUMBER  attention
 8          message.   Note,  however,  that  the  duplicate  unit number
 9          condition may have disappeared by the time the host  receives
10          or acts upon the message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 7

 2                              DISK MSCP OPTIONS



 3      7.1  Multi-Host Support

 4      /to be supplied/



 5      7.2  Controller Initiated Bad Block Replacement

 6      /to be supplied/



 7      7.3  Caching

 8      /to be supplied/



 9      7.4  Shadowing

10      /to be supplied/
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                  CHAPTER 8

 2                       MSCP ERROR LOG MESSAGE FORMATS



 3      8.1  Introduction

 4      MSCP controllers report errors  and  unusual  occurences  in  two
 5      ways:  end messages and error log messages.  Unrecoverable errors
 6      are reported in the end message of the command  that  encountered
 7      the  error.   Such  errors should be reported back to the program
 8      that initiated the command,  so  that  it  can  take  appropriate
 9      action.   Additionally,  all "significant" errors are reported in
10      error log messages, so that they can be recorded  in  the  host's
11      error  log  for eventual use by Field Service.  The definition of
12      what constitutes  a  "significant"  error  is  controller  and/or
13      device  specific.  In general, anything that would be of interest
14      to Field Service is a "significant" error.  The  errors  reported
15      by error log messages may be either recoverable or unrecoverable.
16      Note that hosts should not record errors reported in end messages
17      in  the  error  log.   If  the error is "significant", a separate
18      error log message will be generated.

19      When a host receives an error log message, the host  port  driver
20      passes the class driver the error log message text and the length
21      of the error log message.  In addition, the device  class  (i.e.,
22      disk  or  tape)  of  the  error  log  message  is implicit in the
23      connection on which the message  was  received.   Note  that  the
24      order  of  receipt  of  error  log  messages  relative  to end or
25      attention messages is expressly undefined.   Therefore  an  error
26      log message may be received either before or after an end message
27      that reports the same error or that has the "Error Log Generated"
28      flag set.

29      MSCP servers assign a sequence number to every error log  message
30      they generate.  This sequence number serves two purposes.  First,
31      if the same error log message is sent to  multiple  hosts,  which
32      then record it in a common error log file, it allows the multiple
33      copies of the same message to be  recognized  as  describing  the
34      same  error.   Second,  if  a host requests that it receive every
35      error log message that an MSCP server generates, it  allows  that
36      host  to  detect  missing or lost error log messages by detecting
37      gaps in the sequence numbers.  This second purpose requires  that
38      the  host set all three error log enable flags in the "controller
39      flags" field of the SET CONTROLLER CHARACTERISTICS command.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-2
        8.1  Introduction                                       08 Apr 82


 1      Some controllers can achieve these purposes via other means,  and
 2      therefore need not implement error log sequence numbers.  This is
 3      further described in the third paragraph below.

 4      Each MSCP server implements a single error log  sequence  number,
 5      which  it  uses for all error log messages for all class drivers.
 6      The server must  increment  its  sequence  number  each  time  it
 7      attempts  to  generate  an error log message.  Multiple copies of
 8      the same error log  message  must  all  have  the  same  sequence
 9      number.   The  sequence  number is reset whenever the MSCP server
10      loses context.  The first error log message after such a loss  of
11      context  has  sequence number zero.  The sequence number must not
12      be  reset  as  a  normal  result  of  the  MSCP  server  becoming
13      "Controller-Online"  or "Controller-Available" to a class driver.
14      Note that each MSCP server (i.e., each  device  class)  within  a
15      controller has its own error log sequence number.

16      As stated above, the error log sequence number is only reset when
17      the  MSCP server loses context.  The MSCP server reports the fact
18      that it has lost context with a  flag  in  the  first  error  log
19      message it sends to each class driver after said loss of context.
20      This means, in effect, that the MSCP server must  keep  track  of
21      all class drivers to which it has sent an error log message since
22      its last loss of context, regardless of  whether  or  not  it  is
23      currently "Controller-Online" to those class drivers.

24      MSCP servers that meet all of the following requirements need not
25      implement  error  log  sequence numbers, since their purposes are
26      achieved via other means.  The requirements are:

27           1.  The MSCP server must  never  drop  error  log  messages.
28               That  is,  whenever  it  has  an  error  log  message to
29               generate, it must block or deadlock until it is able  to
30               generate the message.

31           2.  The communications mechanism between the MSCP server and
32               the  class  driver must guarantee all error log messages
33               will be delivered without loss  or  duplication  in  the
34               order   that   they   were   generated.   That  is,  the
35               communications   mechanism   must   provide   the   same
36               guarantees  for  datagrams  (error log messages) that it
37               provides for sequential messages (control messages).

38           3.  The MSCP server and  communications  mechanism  must  be
39               inherently incapable of communicating with more than one
40               class driver.

41      MSCP servers that meet the above three requirements may  generate
42      all  error  log  messages with a sequence number of zero and with
43      the "Sequence  Number  Reset"  flag  set,  rather  than  actually
44      implementing  sequence  numbers.   All  other  MSCP  servers must
45      implement an actual error log sequence number.  Such  other  MSCP
46      servers  may  not  lose  context  solely  to  reset the error log
47      sequence number.  All losses of context must be  caused  by  some
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-3
        8.1  Introduction                                       08 Apr 82


 1      external event such as a power failure.

 2      Since error log messages are not subject to flow control,  it  is
 3      possible  for  a controller to generate error log messages faster
 4      than a host can record them  in  its  error  log.   In  order  to
 5      minimize the probability of this happening, and thus minimize the
 6      probability of losing error  log  information,  controllers  must
 7      generate  no  more than three error log messages in response to a
 8      single error.  Note that the definition of  what  constitutes  an
 9      error  is  necessarily  controller  and/or  drive dependent.  The
10      three message limit encompasses an original error and  all  error
11      recovery  /  correction  /  retry  sequences associated with that
12      error.  Seemingly unrelated  errors  that  occur  in  a  recovery
13      sequence are generally considered to be different errors, and are
14      therefore not covered by the three message limit.

15      For example, consider an  uncorrectable  ECC  error  on  a  read.
16      Re-reads  using  offset head positioning and the like are part of
17      the retry sequence, and thus fall under the three  message  limit
18      for   the  original  error.   However,  failure  of  the  command
19      directing the drive to use offset  head  positioning  (i.e.,  the
20      command  itself  fails,  indicating  that  the heads could not be
21      offset) would be considered a separate error, even though both it
22      and  the original read error might have a common cause (such as a
23      bad cable between the controller and the drive).

24      In order to achieve this three  message  limit,  most  error  log
25      messages summarize the results of an entire retry sequence.  This
26      approach generally results in exactly one error log  message  per
27      error.   The  other  approach is to generate a separate error log
28      message for each attempt or retry that fails.  This approach  can
29      only  be used with errors for which the number of retrys to small
30   |  (i.e., three or fewer attempts total),  as  otherwise  the  three
31      message limit will be exceeded.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-4
        8.2  Generic Error Log Message Format                   08 Apr 82


 1      8.2  Generic Error Log Message Format

 2      All MSCP error log messages must  be  384  bytes  or  shorter  in
 3      length.    The  actual  maximum  error  log  message  size  is  a
 4      controller  characteristic  and  should  be  described   in   the
 5      controller's   functional   specification.   All  host  software,
 6      however, should be prepared to handle error log  messages  up  to
 7      and  including  the 384 byte maximum size.  The general format of
 8      error log messages is as follows:

 9                      31                             0 
10                      +-------------------------------+
11                      |   command reference number    |
12                      +---------------+---------------+
13                      |sequence number|  unit number  |
14                      +---------------+-------+-------+
15                      |  event code   | flags | format|
16                      +---------------+-------+-------+
17                      |                               |
18                      +---  controller identifier  ---+
19                      |                               |
20                      +---------------+-------+-------+
21                      |multi-unit code|chvrsn | csvrsn|
22                      +---------------+-------+-------+
23                      |                               |
24                      +---     unit identifier     ---+
25                      |                               |
26                      +---------------+-------+-------+
27                      | fmt dependent |uhvrsn | usvrsn|
28                      +---------------+-------+-------+
29                      |      volume serial number     |
30                      +-------------------------------+
31                      |                               |
32                      /        format dependent       /
33                      /           information         /
34                      |                               |
35                      +-------------------------------+

36      The fields in the generic error log message are as follows:

37      command reference number

38          The command reference number of the MSCP command that  caused
39          the  error reported by this error log message, or zero if the
40          error does not correspond to a specific outstanding  command.
41          If  this  field contains a command reference number, then the
42          command's  end  message  will  also  have  the   "error   log
43          generated"  end  message  flag  set.  Note that the error log
44          message may be received either before or  shortly  after  the
45          command's end message.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-5
        8.2  Generic Error Log Message Format                   08 Apr 82


 1      unit number

 2          The unit number of the unit to which the  error  log  message
 3          relates, or zero if the message does not relate to a specific
 4          unit.  This field may contain the unit number of any unit  of
 5          the  drive  or  formatter  if  the error relates to an entire
 6          multi-unit drive or formatter.  The validity of this field is
 7          determined by the value in the "format" field.

 8      sequence number

 9          The sequence number of this error log message since the  last
10          time the MSCP server lost context, or zero if the MSCP server
11          does not implement error log  sequence  numbers.   Note  that
12          error  log  sequence numbers are common to all class drivers,
13          and are not reset by class driver  re-synchronization.   Note
14          also that the class driver may receive error log messages out
15          of sequence.

16      format

17          The value in this field identifies the detailed format of the
18          error log message, as defined in the following sections.

19      flags

20          Bit flags, collectively called error log message flags,  used
21          to  report  various  attributes  of the error.  The following
22          flags are defined:

23          Operation Successful

24              If set, the operation causing this error log message  has
25              been  successfully  completed.   The  error  log  message
26              summarizes the  retry  sequence  that  was  necessary  to
27              successfully  complete  the  operation.   If  clear,  the
28              operation has not yet been successfully completed.

29          Operation Continuing

30              If set, the retry sequence for  this  operation  will  be
31              continued.    This   error   log   message   reports  the
32              unsuccessful completion  of  one  or  more  retries.   If
33              clear,   the   retry  sequence  for  this  operation  has
34              terminated.   Provided  "Operation  Successful"  is  also
35              clear,  the  retry  limit  for  this  operation  has been
36              reached and an  unrecoverable  error  will  be  reported.
37              Undefined (meaningless) if "Operation Successful" is set.

38          Sequence Number Reset

39              If set, then the error  log  sequence  number  ("sequence
40              number"  field)  has  been reset by the MSCP server since
41              the last error log message sent to  the  receiving  class
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-6
        8.2  Generic Error Log Message Format                   08 Apr 82


 1              driver.   If  clear,  the  sequence  number  has not been
 2              reset, implying that the "sequence number" field  may  be
 3              used to detect missing error log messages.  Always set if
 4              the MSCP server does not  implement  error  log  sequence
 5              numbers.

 6   |      If "Operation Successful" and "Operation Continuing" are both
 7   |      clear,   then   the   error   log   message  reports  a  hard
 8   |      (unrecoverable) error.  If "Operation  Successful"  is  clear
 9   |      and "Operation Continuing" is set, then the error log message
10   |      reports  an  intermediate  step  within  an  error   recovery
11   |      operation.   It  is not yet certain whether the error is hard
12   |      or soft.  If "Operation Successful" is set,  then  the  error
13   |      log  message  summarizes  the  retry sequence used to recover
14   |      from a soft error.

15      event code

16          Identifies the specific error or event being reported by this
17          error log message.  The structure of event codes is identical
18          to  the  structure  of  the  status  codes  returned  in  end
19          messages.   That is, they consist of a 5 bit major event code
20          and an 11 bit sub-code.  All errors that may be reported with
21          both  error log messages and end messages must have identical
22          status and event codes.  Also, the same value may not be used
23          as  both  a  status and event code unless it reports the same
24          error in each case.

25          The sub-code portion of event codes is potentially controller
26          and/or  device  specific.   However,  the  same  major code /
27          sub-code combination, whenever it is used, must  always  have
28          the  same meaning.  Therefore new sub-codes may be defined as
29          new devices are introduced, but the meaning of old  sub-codes
30          should  not change.  Event code values are listed in Appendix
31          B.

32      controller identifier

33          Uniquely  identifies  the  controller   among   all   devices
34          accessible  via MSCP.  See Section 4.16, "Controller and Unit
35          Identifiers".

36      csvrsn

37          The controller's software, firmware,  or  microcode  revision
38   |      number.    Always  zero  if  the  product's  development  and
39   |      maintainability groups determine that  there  is  no  benefit
40   |      from supporting machine readable revision numbers.

41      chvrsn

42   |      The controller's hardware revision number.   Always  zero  if
43   |      the   product's   development   and   maintainability  groups
44   |      determine that there is no benefit  from  supporting  machine
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-7
        8.2  Generic Error Log Message Format                   08 Apr 82


 1   |      readable revision numbers.

 2      multi-unit code

 3          The multi-unit code, as defined in Section 4.15,  "Multi-Unit
 4          Drives  and  Formatters",  of the unit to which the error log
 5          message relates.  This field may contain the multi-unit  code
 6          of any unit of the drive or formatter if the error relates to
 7          an entire multi-unit drive or formatter.

 8      unit identifer

 9          Uniquely identifies the unit among all devices accessible via
10          MSCP.   See  Section 4.16, "Controller and Unit Identifiers".
11          This field is only  present  for  errors  that  relate  to  a
12          specific unit.

13      usvrsn

14          The unit's software, firmware, or microcode revision  number.
15          This  field  is  only  present  for  errors  that relate to a
16   |      specific unit.  Always zero if the product's development  and
17   |      maintainability  groups  determine  that  there is no benefit
18   |      from supporting machine readable revision numbers.

19      uhvrsn

20          The unit's hardware revision  number.   This  field  is  only
21   |      present  for  errors  that relate to a specific unit.  Always
22   |      zero if the product's development and maintainability  groups
23   |      determine  that  there  is no benefit from supporting machine
24   |      readable revision numbers.

25      volume serial number

26          The low order 32 bits of the serial number of the volume that
27          is  mounted  on the unit.  Zero if the unit's format does not
28          provide for a volume serial number.  Undefined  (garbage)  if
29          there  is  no  volume  mounted  in  the unit, the area of the
30          volume  that  contains  the  serial  number  cannot  be  read
31          successfully,  the  error  occurred  before the volume serial
32          number  could  be  determined   while   bringing   the   unit
33          "Unit-Online",  the unit is not "Unit-Online" to any host, or
34          if the "Ignore Media Format Error" modifier was specified  in
35          the ONLINE command that first brought the unit "Unit-Online".
36          This field is only  present  for  errors  that  relate  to  a
37          specific disk unit.

38      fmt dependent
39      format dependent information

40          The format of the remainder of the error log message  depends
41          upon  the  value of the "format" field.  Note that the fields
42          "unit number" and "multi-unit code"  through  "volume  serial
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-8
        8.2  Generic Error Log Message Format                   08 Apr 82


 1          number"  also  depend  on the value of the "format" field, as
 2          they are only present for those formats used to report errors
 3          that relate to a specific unit.

 4      The following sections describe the specific  error  log  message
 5      formats.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                           Page 8-9
        8.3  Controller Errors                                  08 Apr 82


 1      8.3  Controller Errors

 2      The  following  error  log  message  format  is  used  to  report
 3      controller errors:

 4                      31                             0 
 5                      +-------------------------------+
 6                      |   command reference number    |
 7                      +---------------+---------------+
 8                      |sequence number|    reserved   |
 9                      +---------------+-------+-------+
10                      |  event code   | flags | format|
11                      +---------------+-------+-------+
12                      |                               |
13                      +---  controller identifier  ---+
14                      |                               |
15                      +---------------+-------+-------+
16                      |               |chvrsn | csvrsn|
17                      |               +-------+-------+
18                      |          controller           |
19                      /          dependent            /
20                      /          information          /
21                      |                               |
22                      +-------------------------------+

23      controller dependent information

24          A variable  (controller  dependent)  amount  of  information.
25          Often  no  controller dependent information is provided.  The
26          length of this information is implied by the total length  of
27          the error log message, passed to the class driver by the port
28          driver.  This information will typically not  be  interpreted
29          by  error log formatting programs, instead being printed as a
30          series of octal values.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                          Page 8-10
        8.4  Host Memory Access Errors with Bus Address         08 Apr 82


 1      8.4  Host Memory Access Errors with Bus Address

 2      The following error log message format is  used  to  report  host
 3      memory  access  errors  when  the  host  memory  bus  address  is
 4      available to the controller:

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |sequence number|    reserved   |
10                      +---------------+-------+-------+
11                      |  event code   | flags | format|
12                      +---------------+-------+-------+
13                      |                               |
14                      +---  controller identifier  ---+
15                      |                               |
16                      +---------------+-------+-------+
17                      |   reserved    |chvrsn | csvrsn|
18                      +---------------+-------+-------+
19                      |      host memory address      |
20                      +-------------------------------+

21      host memory address

22          The address on the host memory bus at which the  host  memory
23          access  error  occurred, expressed as a 32 bit quantity.  The
24          resolution to which a controller identifies  the  address  at
25          which the error occurred is controller dependent, and must be
26          described in the controller's Functional Specification.  Disk
27          controllers  will  typically provide a resolution of one disk
28          block (either 512 or 576 bytes).
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                          Page 8-11
        8.5  Disk Transfer Errors                               08 Apr 82


 1      8.5  Disk Transfer Errors

 2      The following error log message format is used to  report  errors
 3      that  occur  during  a  disk  transfer.  Note that this format is
 4      generally used to report the results of a sequence of retries.

 5                      31                             0 
 6                      +-------------------------------+
 7                      |   command reference number    |
 8                      +---------------+---------------+
 9                      |sequence number|  unit number  |
10                      +---------------+-------+-------+
11                      |  event code   | flags | format|
12                      +---------------+-------+-------+
13                      |                               |
14                      +---  controller identifier  ---+
15                      |                               |
16                      +---------------+-------+-------+
17                      |multi-unit code|chvrsn | csvrsn|
18                      +---------------+-------+-------+
19                      |                               |
20                      +---     unit identifier     ---+
21                      |                               |
22   |                  +-------+-------+-------+-------+
23   |                  | retry | level |uhvrsn | usvrsn|
24   |                  +-------+-------+-------+-------+
25   |                  |      volume serial number     |
26   |                  +-------------------------------+
27   |                  |          header code          |
28   |                  +-------------------------------+
29                      |                               |
30                      /      controller or disk       /
31                      /     dependent information     /
32                      |                               |
33                      +-------------------------------+

34      level

35          The error recovery level used for the most recent attempt  at
36          the transfer.  The error recovery level is a device dependent
37          encoding of the special error recovery  procedures,  such  as
38          offset  head  positioning,  used for the most recent transfer
39          attempt.  The values zero and 255 (all ones) are reserved  to
40          indicate that no special error recovery procedures were used.

41      retry

42          The retry count, within the current error recovery level,  of
43          the  most  recent attempt at the transfer.  This value starts
44          at one  for  the  first  attempt  using  a  particular  error
45          recovery  level and increments for each subsequent attempt at
46          the same level.  This continues up to  some  drive  dependent
47          maximum,  at  which  time the retry count is reset to one and
48          the next error recovery level (if any) is tried.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                          Page 8-12
        8.5  Disk Transfer Errors                               08 Apr 82


 1   |  header code
 2   |  
 3   |      Identifies the physical disk  location  at  which  the  error
 4   |      occurred.   If the high four bits are 0000 (binary), then the
 5   |      low 28 bits are the logical block number at which  the  error
 6   |      occurred.   If the high four bits are 0110 (binary), then the
 7   |      low 28 bits are the replacement block  number  at  which  the
 8   |      error  occurred.  All other patterns of the high four bits of
 9   |      "header code" are reserved, and must not be returned  without
10   |      an  ECO to this specification to define their interpretation.
11   |      The 28  bit  logical  or  replacement  block  number  may  be
12   |      decomposed,  using  the  disk geometry parameters returned by
13   |      the GET UNIT STATUS command, to obtain the  cylinder,  group,
14   |      track, and sector position at which the error occurred.

15      controller or disk dependent information

16          A  variable  (controller  or  disk   dependent)   amount   of
17          information.    Often   no   controller   or  disk  dependent
18          information is provided.  The length of this  information  is
19          implied  by the total length of the error log message, passed
20          to the class driver by the  port  driver.   This  information
21          will  typically  not  be  interpreted by error log formatting
22          programs, instead being printed as a series of octal values.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                          Page 8-13
        8.6  SDI Errors                                         08 Apr 82


 1      8.6  SDI Errors

 2      The following error log  message  format  is  used  by  SDI  disk
 3      controllers to report drive detected errors and SDI communication
 4      errors.  Note that the controller retries these errors only  once
 5      or  twice,  so a separate error log message will be generated for
 6      each attempt that fails.

 7                      31                             0 
 8                      +-------------------------------+
 9                      |   command reference number    |
10                      +---------------+---------------+
11                      |sequence number|  unit number  |
12                      +---------------+-------+-------+
13                      |  event code   | flags | format|
14                      +---------------+-------+-------+
15                      |                               |
16                      +---  controller identifier  ---+
17                      |                               |
18                      +---------------+-------+-------+
19                      |multi-unit code|chvrsn | csvrsn|
20                      +---------------+-------+-------+
21                      |                               |
22                      +---     unit identifier     ---+
23                      |                               |
24                      +---------------+-------+-------+
25   |                  |   reserved    |uhvrsn | usvrsn|
26   |                  +---------------+-------+-------+
27   |                  |      volume serial number     |
28   |                  +-------------------------------+
29   |                  |          header code          |
30                      +-------------------------------+
31                      |                               |
32                      +---       SDI status        ---+
33                      |          information          |
34                      +---       (12 bytes)        ---+
35                      |                               |
36                      +-------------------------------+
37   |  
38   |  header code
39   |  
40   |      Identifies the physical disk  location  at  which  the  error
41   |      occurred.   If the high four bits are 0000 (binary), then the
42   |      low 28 bits are the logical block number at which  the  error
43   |      occurred.   If the high four bits are 0110 (binary), then the
44   |      low 28 bits are the replacement block  number  at  which  the
45   |      error  occurred.  All other patterns of the high four bits of
46   |      "header code" are reserved, and must not be returned  without
47   |      an  ECO to this specification to define their interpretation.
48   |      The 28  bit  logical  or  replacement  block  number  may  be
49   |      decomposed,  using  the  disk geometry parameters returned by
50   |      the GET UNIT STATUS command, to obtain the  cylinder,  group,
51   |      track, and sector position at which the error occurred.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                          Page 8-14
        8.6  SDI Errors                                         08 Apr 82


 1      SDI status information

 2          Twelve bytes of status information returned by  the  SDI  GET
 3          STATUS command or by the SDI UNSUCCESSFUL response.  The unit
 4          number information returned by the SDI command or response is
 5          not  included,  as  that information is provided elsewhere in
 6          the error log message.  Otherwise,  all  of  the  SDI  status
 7          information  is  included.  See the SDI specification for the
 8          format of this information.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        MSCP Error Log Message Formats                          Page 8-15
        8.7  Small Disk Errors                                  08 Apr 82


 1      8.7  Small Disk Errors

 2      The following error log message format is used  by  low-end  disk
 3      controllers  to report drive detected errors and other errors not
 4      amenable to the Disk Transfer Error  error  log  message  format.
 5      Note  that  this  format can only be used with disks that have no
 6      more than 65535 cylinders.

 7                      31                             0 
 8                      +-------------------------------+
 9                      |   command reference number    |
10                      +---------------+---------------+
11                      |sequence number|  unit number  |
12                      +---------------+-------+-------+
13                      |  event code   | flags | format|
14                      +---------------+-------+-------+
15                      |                               |
16                      +---  controller identifier  ---+
17                      |                               |
18                      +---------------+-------+-------+
19                      |multi-unit code|chvrsn | csvrsn|
20                      +---------------+-------+-------+
21                      |                               |
22                      +---     unit identifier     ---+
23                      |                               |
24                      +---------------+-------+-------+
25                      |   cylinder    |uhvrsn | usvrsn|
26                      +---------------+-------+-------+
27                      |      volume serial number     |
28                      +-------------------------------+
29                      |         controller or         |
30                      /         drive dependent       /
31                      /          information          /
32                      |                               |
33                      +-------------------------------+

34      cylinder

35          The cylinder to which the current transfer is directed.  This
36          field may or may not be meaningful, depending on the value in
37          "event code".

38      controller or drive dependent information

39          A  variable  (controller  or  drive  dependent)   amount   of
40          information.   The  length  of this information is implied by
41          the total length of the error  log  message,  passed  to  the
42          class  driver  by  the  port  driver.   This information will
43          typically  not  be  interpreted  by  error   log   formatting
44          programs, instead being printed as a series of octal values.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  
     |  
 1   |  
 2   |  
 3   |  
 4   |  
 5   |  
 6   |  
 7   |  
 8   |  
 9   |  
10   |  
11   |                              CHAPTER 9
12   |  
13   |                       WAIVERS AND EXCEPTIONS
14   |  
15   |  
16   |  
17   |  9.1  UDA50 -- Unit and Controller Revision Numbers
18   |  
19   |  
20   |  
21   |  Waiver:
22   |  
23   |      Early serial number UDA50  controllers  do  not  return  unit
24   |      revision  numbers  in  the  GET  UNIT  STATUS  end message or
25   |      controller   revision   numbers   in   the   SET   CONTROLLER
26   |      CHARACTERISTICS end message.
27   |  
28   |  
29   |  Justification:
30   |  
31   |      The UDA50 was already being shipped when the revision  number
32   |      fields were added to these end messages.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  
     |  
 1   |  
 2   |  
 3   |  
 4   |  
 5   |  
 6   |  
 7   |  
 8   |  
 9   |  
10   |  
11   |                             CHAPTER 10
12   |  
13   |                           CLARIFICATIONS
14   |  
15   |  
16   |  
17   |  10.1  Invalid Commands
18   |  
19   |  There are two kinds of invalid commands.  The first is  called  a
20   |  protocol error.  A protocol error is an invalid command for which
21   |  no meaning has been defined.  Examples  are  illegal  opcodes  or
22   |  non-zero  values  in  reserved fields.  The other kind of invalid
23   |  command is a parameter error.  The command  has  a  well  defined
24   |  meaning,  but  some  parameter is beyond the allowable range.  An
25   |  example is a block number larger than the size of the disk.
26   |  
27   |  Protocol  errors  are  reported  with  the  Invalid  Command  End
28   |  Message.   The  endcode  field  in  this end message contains the
29   |  constant OP.END and the parameter area is echoed from the command
30   |  (this is done to aid error diagnosis).
31   |  
32   |  Parameter errors are reported with the normal end message for the
33   |  command  with  the invalid parameter.  The endcode field contains
34   |  the command's opcode merged  with  the  end  message  flag.   The
35   |  parameter  area  contains the normal parameters (byte count, unit
36   |  characteristics, or whatever) for the command's end message.
37   |  
38   |  The following errors are parameter errors:
39   |  
40   |       1.  Invalid Byte Count -- byte count is too large  (transfer
41   |           crosses  from  host area into RCT) or transfer starts in
42   |           RCT and byte count is not equal to block size.
43   |  
44   |       2.  Invalid Logical Block Number -- logical block number  is
45   |           larger than the range supported by this disk.
46   |  
47   |       3.  Invalid Replacement Block Number  --  replacement  block
48   |           number is larger than the range supported by this disk.
49   |  
50   |       4.  Invalid Unit Flags (ONLINE command only) -- the unit  is
51   |           already  "Unit-Online"  and the host settable unit flags
52   |           specified by the class driver are different  from  those
53   |           already in effect on the unit.
54   |  
55   |  All other causes of invalid commands (all other  invalid  fields)
56   |  are  protocol  errors.  Note that unit flags that are invalid for
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
     |  Clarifications                                          Page 10-2
                                                                08 Apr 82


 1   |  any reason other the  one  listed  above  constitute  a  protocol
 2   |  error.   I.e.,  specifying  a  reserved  unit  flag is a protocol
 3   |  error.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                              APPENDIX A

 2                                 OPCODE, FLAG, AND OFFSET DEFINITIONS




 3      Notes:  1. The "x" in a 32 bit mnemonic for a bit flag will be either  a  "V"  or  an  "M",
 4                 respectively,  depending  on  whether  the  symbol  is  defined  as a bit number
 5                 (offset) or as a mask.

 6              2. All offset values and field sizes are expressed in bytes.


 7                                  Table A-1   Control Message Opcodes

 8      +--------------------+--------------------------+-----------------------------------------+
 9      |    Opcode Value    |   Preferred Mnemonics    |                                         |
10      | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Control Message Type                |
11      +------+------+------+--------+-----------------+-----------------------------------------+
12      |   1  |  01  |  01  | OP.ABO | MSCP$K_OP_ABORT | ABORT Command                           |
13      |  16  |  20  |  10  | OP.ACC | MSCP$K_OP_ACCES | ACCESS Command                          |
14      |   8  |  10  |  08  | OP.AVL | MSCP$K_OP_AVAIL | AVAILABLE Command                       |
15      |  17  |  21  |  11  | OP.CCD | MSCP$K_OP_CMPCD | COMPARE CONTROLLER DATA Command         |
16      |  32  |  40  |  20  | OP.CMP | MSCP$K_OP_COMP  | COMPARE HOST DATA Command               |
17      |  11  |  13  |  0B  | OP.DAP | MSCP$K_OP_DTACP | DETERMINE ACCESS PATHS Command          |
18      |  18  |  22  |  12  | OP.ERS | MSCP$K_OP_ERASE | ERASE Command                           |
19      |  19  |  23  |  13  | OP.FLU | MSCP$K_OP_FLUSH | FLUSH Command                           |
20      |   2  |  02  |  02  | OP.GCS | MSCP$K_OP_GTCMD | GET COMMAND STATUS Command              |
21      |   3  |  03  |  03  | OP.GUS | MSCP$K_OP_GTUNT | GET UNIT STATUS Command                 |
22      |   9  |  11  |  09  | OP.ONL | MSCP$K_OP_ONLIN | ONLINE Command                          |
23      +------+------+------+--------+-----------------+-----------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-2
                                                                                          08 Apr 82


 1                             Table A-1   Control Message Opcodes  (cont.)

 2      +--------------------+--------------------------+-----------------------------------------+
 3      |    Opcode Value    |   Preferred Mnemonics    |                                         |
 4      | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Control Message Type                |
 5      +------+------+------+--------+-----------------+-----------------------------------------+
 6      |  33  |  41  |  21  | OP.RD  | MSCP$K_OP_READ  | READ Command                            |
 7      |  20  |  24  |  14  | OP.RPL | MSCP$K_OP_REPLC | REPLACE Command                         |
 8      |   4  |  04  |  04  | OP.SCC | MSCP$K_OP_STCON | SET CONTROLLER CHARACTERISTICS Command  |
 9      |  10  |  12  |  0A  | OP.SUC | MSCP$K_OP_STUNT | SET UNIT CHARACTERISTICS Command        |
10      |  34  |  42  |  22  | OP.WR  | MSCP$K_OP_WRITE | WRITE Command                           |
11      |      |      |      |        |                  |                                        |
12      | 128  | 200  |  80  | OP.END | MSCP$K_OP_END   | End message flag (see note below)       |
13      |   7  |   7  |   7  | OP.SEX | MSCP$K_OP_SEREX | Serious Exception end msg. (see below)  |
14      |      |      |      |        |                 |                                         |
15      |  64  | 100  |  40  | OP.AVA | MSCP$K_OP_AVATN | AVAILABLE Attention Message             |
16      |  65  | 101  |  41  | OP.DUP | MSCP$K_OP_DUPUN | DUPLICATE UNIT NUMBER Attention Message |
17      |  66  | 102  |  42  | OP.ACP | MSCP$K_OP_ACPTH | ACCESS PATH Attention Message           |
18      +------+------+------+--------+-----------------+-----------------------------------------+
19      | Note:  End message opcodes (also called endcodes) are formed by adding the end message  |
20      |        flag to the command opcode.  For example, a READ command's end message contains  |
21      |        (using 16 bit mnemonics) the value OP.RD+OP.END in its opcode field.  The        |
22      |        Invalid Command end message contains just the end message flag (i.e., OP.END) in |
23      |        its opcode field.  The Serious Exception end message contains the sum of the end |
24      |        message flag plus the serious exception opcode shown above (i.e., OP.SEX+OP.END) |
25      |        in its opcode field.                                                             |
26      |                                                                                         |
27      |        Command opcode bits 6 and 7 indicate the type of message (command, end, or       |
28      |        attention message.  Command opcode bits 3 through 5 indicate the command         |
29      |        category (immediate, sequential, or non-sequential) and whether or not the       |
30      |        command includes a buffer descriptor.                                            |
31      +-----------------------------------------------------------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-3
                                                                                          08 Apr 82


 1                                     Table A-2   Command Modifiers

 2      +------+--------------+--------------------------+----------------------------------------+
 3      | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
 4      |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Command Modifier                   |
 5      +------+-------+------+--------+-----------------+----------------------------------------+
 6      | Generic Command Modifiers:   |                 |                                        |
 7      |  13  | 20000 | 2000 | MD.CSE | MSCP$x_MD_CLSEX | Clear Serious Exception                |
 8      |  14  | 40000 | 4000 | MD.CMP | MSCP$x_MD_COMP  | Compare                                |
 9      |  15  |100000 | 8000 | MD.EXP | MSCP$x_MD_EXPRS | Express Request                        |
10      |  12  | 10000 | 1000 | MD.ERR | MSCP$x_MD_ERROR | Force Error                            |
11      |  11  |  4000 |  800 | MD.SCH | MSCP$x_MD_SCCHH | Suppress Caching (high speed)          |
12      |  10  |  2000 |  400 | MD.SCL | MSCP$x_MD_SCCHL | Suppress Caching (low speed)           |
13      |   9  |  1000 |  200 | MD.SEC | MSCP$x_MD_SECOR | Suppress Error Correction              |
14      |   8  |   400 |  100 | MD.SER | MSCP$x_MD_SEREC | Suppress Error Recovery                |
15      |   7  |   200 |   80 | MD.SSH | MSCP$x_MD_SSHDW | Suppress Shadowing                     |
16      |   6  |   100 |   40 | MD.WBN | MSCP$x_MD_WBKNV | Write-back (non-volatile)              |
17      |   5  |    40 |   20 | MD.WBV | MSCP$x_MD_WBKVL | Write-back (volatile)                  |
18      |   4  |    20 |   10 | MD.SEQ | MSCP$x_MD_WRSEQ | Write Shadow Set One Unit At a Time    |
19      | AVAILABLE Command Modifiers:                   |                                        |
20      |   1  |     2 |    2 | MD.ALL | MSCP$x_MD_ALLCD | All Class Drivers                      |
21      |   0  |     1 |    1 | MD.SPD | MSCP$x_MD_SPNDW | Spin-down                              |
22      | FLUSH Command Modifiers:   |                   |                                        |
23      |   0  |     1 |    1 | MD.FEU | MSCP$x_MD_FLENU | Flush Entire Unit                      |
24      |   1  |     2 |    2 | MD.VOL | MSCP$x_MD_VOLTL | Volatile Only                          |
25      | GET UNIT STATUS Command Modifiers:             |                                        |
26      |   0  |     1 |    1 | MD.NXU | MSCP$x_MD_NXUNT | Next Unit                              |
27      | ONLINE Command Modifiers:  |                   |                                        |
28      |   0  |     1 |    1 | MD.RIP | MSCP$x_MD_RIP   | Allow Self Destruction                 |
29      |   1  |     2 |    2 | MD.IMF | MSCP$x_MD_IGNMF | Ignore Media Format Error              |
30      | ONLINE and SET UNIT CHARACTERISTICS Command Modifiers:                                  |
31      |   3  |    10 |    8 | MD.CWB | MSCP$x_MD_CLWBL | Clear Write-back Data Lost             |
32      |   2  |     4 |    4 | MD.SWP | MSCP$x_MD_STWRP | Enable Set Write Protect               |
33      |   4  |    20 |   10 | MD.SHD | MSCP$x_MD_SHDSP | Shadow Unit Specified                  |
34      | REPLACE Command Modifiers: |                   |                                        |
35      |   0  |     1 |    1 | MD.PRI | MSCP$x_MD_PRIMR | Primary Replacement Block              |
36      +------+-------+------+--------+-----------------+----------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-4
                                                                                          08 Apr 82


 1                                     Table A-3   End Message Flags

 2      +------+--------------+--------------------------+----------------------------------------+
 3      | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
 4      |Number| Octal | Hex. | 16 bit |32 bit (see note)|     End Message Flag                   |
 5      +------+-------+------+--------+-----------------+----------------------------------------+
 6      |   7  |   200 |   80 | EF.BBR | MSCP$x_EF_BBLKR | Bad Block Reported                     |
 7      |   6  |   100 |   40 | EF.BBU | MSCP$x_EF_BBLKU | Bad Block Unreported                   |
 8      |   5  |    40 |   20 | EF.LOG | MSCP$x_EF_ERLOG | Error Log Generated                    |
 9      |   4  |    20 |   10 | EF.SEX | MSCP$x_EF_SEREX | Serious Exception                      |
10      +------+-------+------+--------+-----------------+----------------------------------------+


11                                     Table A-4   Controller Flags

12      +------+--------------+--------------------------+----------------------------------------+
13      | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
14      |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Controller Flag                    |
15      +------+-------+------+--------+-----------------+----------------------------------------+
16      |   7  |   200 |   80 | CF.ATN | MSCP$x_CF_ATTN  | Enable Attention Messages              |
17      |   6  |   100 |   40 | CF.MSC | MSCP$x_CF_MISC  | Enable Miscellaneous Error Log Messages|
18      |   5  |    40 |   20 | CF.OTH | MSCP$x_CF_OTHER | Enable Other Host's Error Log Messages |
19      |   4  |    20 |   10 | CF.THS | MSCP$x_CF_THIS  | Enable This Host's Error Log Messages  |
20      |  15  |100000 | 8000 | CF.RPL | MSCP$x_CF_REPLC | Controller Initiated Bad Block Rplcmnt |
21      |   1  |     2 |    2 | CF.SHD | MSCP$x_CF_SHADW | Shadowing                              |
22      |   0  |     1 |    1 | CF.576 | MSCP$x_CF_576   | 576 Byte Sectors                       |
23      +------+-------+------+--------+-----------------+----------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-5
                                                                                          08 Apr 82


 1                                        Table A-5   Unit Flags

 2      +------+--------------+--------------------------+----------------------------------------+
 3      | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
 4      |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Unit Flag                          |
 5      +------+-------+------+--------+-----------------+----------------------------------------+
 6      |   0  |     1 |    1 | UF.CMR | MSCP$x_UF_CMPRD | Compare Reads                          |
 7      |   1  |     2 |    2 | UF.CMW | MSCP$x_UF_CMPWR | Compare Writes                         |
 8      |  15  |100000 | 8000 | UF.RPL | MSCP$x_UF_REPLC | Controller Initiated Bad Block Rplcmnt |
 9      |  14  | 40000 | 4000 | UF.INA | MSCP$x_UF_INACT | Inactive Shadow Set Unit               |
10      |   7  |   200 |   80 | UF.RMV | MSCP$x_UF_RMVBL | Removable Media                        |
11      |  11  |  4000 |  800 | UF.SCH | MSCP$x_UF_SCCHH | Suppress Caching (high speed)          |
12      |  10  |  2000 |  400 | UF.SCL | MSCP$x_UF_SCCHL | Suppress Caching (low speed)           |
13      |   6  |   100 |   40 | UF.WBN | MSCP$x_UF_WBKNV | Write-back (non-volatile)              |
14      |  13  | 20000 | 2000 | UF.WPH | MSCP$x_UF_WRTPH | Write Protect (hardware)               |
15      |  12  | 10000 | 1000 | UF.WPS | MSCP$x_UF_WRTPS | Write Protect (software or volume)     |
16      |   2  |     4 |    4 | UF.576 | MSCP$x_UF_576   | 576 Byte Sectors                       |
17      +------+-------+------+--------+-----------------+----------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-6
                                                                                          08 Apr 82


 1                                  Table A-6   Command Message Offsets

 2      +--------------------+--------------------------+-------+---------------------------------+
 3      |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
 4      | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
 5      +------+------+------+--------+-----------------+-------+---------------------------------+
 6      | Generic Command Message Offsets:              |       |                                 |
 7      |   0  |   0  |   0  | P.CRF  | MSCP$L_CMD_REF  |   4   | Command reference number        |
 8      |   4  |   4  |   4  | P.UNIT | MSCP$W_UNIT     |   2   | Unit number                     |
 9      |   6  |   6  |   6  |        |                 |   2   | Reserved                        |
10      |   8  |  10  |   8  | P.OPCD | MSCP$B_OPCODE   |   1   | Opcode                          |
11      |   9  |  11  |   9  |        |                 |   1   | Reserved                        |
12      |  10  |  12  |   A  | P.MOD  | MSCP$W_MODIFIER |   2   | Modifiers                       |
13      |  12  |  14  |   C  | P.BCNT | MSCP$L_BYTE_CNT |   4   | Byte count                      |
14      |  16  |  20  |  10  | P.BUFF | MSCP$Z_BUFFER   |  12   | Buffer descriptor               |
15      |  28  |  34  |  1C  | P.LBN  | MSCP$L_LBN      |   4   | Logical Block Number            |
16      |      |      |      |        |                 |       |                                 |
17      | ABORT and GET COMMAND STATUS Command Message Offsets: |                                 |
18      |  12  |  14  |   C  | P.OTRF | MSCP$L_OUT_REF  |   4   | Outstanding reference number    |
19      |      |      |      |        |                 |       |                                 |
20      | ONLINE and SET UNIT CHARACTERISTICS Command Message Offsets:                            |
21      |  12  |  14  |   C  |        |                 |   2   | Reserved                        |
22      |  14  |  16  |   E  | P.UNFL | MSCP$W_UNT_FLGS |   2   | Unit flags                      |
23      |  16  |  20  |  10  |        |                 |  12   | Reserved                        |
24      |  28  |  34  |  1C  | P.DVPM | MSCP$L_DEV_PARM |   4   | Device dependent parameters     |
25      |  32  |  40  |  20  | P.SHUN | MSCP$W_SHDW_UNT |   2   | Shadow unit                     |
26      |  34  |  42  |  22  | P.CPSP | MSCP$W_COPY_SPD |   2   | Copy speed                      |
27      |      |      |      |        |                 |       |                                 |
28      | REPLACE Command Message Offsets:              |       |                                 |
29      |  12  |  14  |   C  | P.RBN  | MSCP$L_RBN      |   4   | Replacement block number        |
30      |      |      |      |        |                 |       |                                 |
31      | SET CONTROLLER CHARACTERISTICS Command Message Offsets:                                 |
32      |  12  |  14  |   C  | P.VRSN | MSCP$W_VERSION  |   2   | MSCP version                    |
33      |  14  |  16  |   E  | P.CNTF | MSCP$W_CNT_FLGS |   2   | Controller flags                |
34      |  16  |  20  |  10  | P.HTMO | MSCP$W_HST_TMO  |   2   | Host timeout                    |
35      |  18  |  22  |  12  |        |                 |   2   | Reserved                        |
36      |  20  |  24  |  14  | P.TIME | MSCP$Q_TIME     |   8   | Quad-word time and date         |
37      +------+------+------+--------+-----------------+-------+---------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-7
                                                                                          08 Apr 82


 1                             Table A-7   End and Attention Message Offsets

 2      +--------------------+--------------------------+-------+---------------------------------+
 3      |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
 4      | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
 5      +------+------+------+--------+-----------------+-------+---------------------------------+
 6      | Generic End Message Offsets:                  |       |                                 |
 7      |   0  |   0  |   0  | P.CRF  | MSCP$L_CMD_REF  |   4   | Command reference number        |
 8      |   4  |   4  |   4  | P.UNIT | MSCP$W_UNIT     |   2   | Unit number                     |
 9      |   6  |   6  |   6  |        |                 |   2   | Reserved                        |
10      |   8  |  10  |   8  | P.OPCD | MSCP$B_OPCODE   |   1   | Opcode (also called endcode)    |
11      |   9  |  11  |   9  | P.FLGS | MSCP$B_FLAGS    |   1   | End message flags               |
12      |  10  |  12  |   A  | P.STS  | MSCP$W_STATUS   |   2   | Status                          |
13      |  12  |  14  |   C  | P.BCNT | MSCP$L_BYTE_CNT |   4   | Byte count                      |
14      |  16  |  20  |  10  |        |                 |  12   | Reserved                        |
15      |  28  |  34  |  1C  | P.FBBK | MSCP$L_FRST_BAD |   4   | First bad block                 |
16      |      |      |      |        |                 |       |                                 |
17      | ABORT and GET COMMAND STATUS End Message Offsets:     |                                 |
18      |  12  |  14  |   C  | P.OTRF | MSCP$L_OUT_REF  |   4   | Outstanding reference number    |
19      | GET COMMAND STATUS End Message Offsets:       |       |                                 |
20      |  16  |  20  |  10  | P.CMST | MSCP$L_CMD_STS  |   4   | Command status                  |
21      |      |      |      |        |                 |       |                                 |
22      | GET UNIT STATUS End Message Offsets:          |       |                                 |
23      |  12  |  14  |   C  | P.MLUN | MSCP$W_MULT_UNT |   2   | Multi-unit code                 |
24      |  14  |  16  |   E  | P.UNFL | MSCP$W_UNT_FLGS |   2   | Unit flags                      |
25      |  16  |  20  |  10  |        |                 |   4   | Reserved                        |
26      |  20  |  24  |  14  | P.UNTI | MSCP$Q_UNIT_ID  |   8   | Unit identifer                  |
27      |  28  |  34  |  1C  | P.MEDI | MSCP$L_MEDIA_ID |   4   | Media type identifier           |
28      |  32  |  40  |  20  | P.SHUN | MSCP$W_SHDW_UNT |   2   | Shadow unit                     |
29      |  34  |  42  |  22  | P.SHST | MSCP$W_SHDW_STS |   2   | Shadow status                   |
30      |  36  |  44  |  24  | P.TRCK | MSCP$W_TRACK    |   2   | Track size                      |
31      |  38  |  46  |  26  | P.GRP  | MSCP$W_GROUP    |   2   | Group size                      |
32      |  40  |  50  |  28  | P.CYL  | MSCP$W_CYLINDER |   2   | Cylinder size                   |
33   |  |  42  |  52  |  2A  | P.USVR | MSCP$B_UNIT_SVR |   1   | Unit software version           |
34   |  |  43  |  53  |  2B  | P.UHVR | MSCP$B_UNIT_HVR |   1   | Unit hardware version           |
35      |  44  |  54  |  2C  | P.RCTS | MSCP$W_RCT_SIZE |   2   | RCT table size                  |
36      |  46  |  56  |  2E  | P.RBNS | MSCP$W_RBNS     |   1   | RBNs / track                    |
37      |  47  |  57  |  2F  | P.RCTC | MSCP$B_RCT_CPYS |   1   | RCT copies                      |
38      +------+------+------+--------+-----------------+-------+---------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-8
                                                                                          08 Apr 82


 1                        Table A-7   End and Attention Message Offsets  (cont.)

 2      +--------------------+--------------------------+-------+---------------------------------+
 3      |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
 4      | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
 5      +------+------+------+--------+-----------------+-------+---------------------------------+
 6      | ONLINE and SET UNIT CHARACTERISTICS End Message and AVAILABLE Attention Message offsets:|
 7      |  12  |  14  |   C  | P.MLUN | MSCP$W_MULT_UNT |   2   | Multi-unit code                 |
 8      |  14  |  16  |   E  | P.UNFL | MSCP$W_UNT_FLGS |   2   | Unit flags                      |
 9      |  16  |  20  |  10  |        |                 |   4   | Reserved                        |
10      |  20  |  24  |  14  | P.UNTI | MSCP$Q_UNIT_ID  |   8   | Unit identifer                  |
11      |  28  |  34  |  1C  | P.MEDI | MSCP$L_MEDIA_ID |   4   | Media type identifier           |
12      |  32  |  40  |  20  | P.SHUN | MSCP$W_SHDW_UNT |   2   | Shadow unit                     |
13      |  34  |  42  |  22  | P.SHST | MSCP$W_SHDW_STS |   2   | Shadow status                   |
14      |  36  |  44  |  24  | P.UNSZ | MSCP$L_UNT_SIZE |   4   | Unit size                       |
15      |  40  |  50  |  28  | P.VSER | MSCP$L_VOL_SER  |   4   | Volume serial number            |
16      |      |      |      |        |                 |       |                                 |
17      | SET CONTROLLER CHARACTERISTICS End Message Offsets:   |                                 |
18      |  12  |  14  |   C  | P.VRSN | MSCP$W_VERSION  |   2   | MSCP version                    |
19      |  14  |  16  |   E  | P.CNTF | MSCP$W_CNT_FLGS |   2   | Controller flags                |
20      |  16  |  20  |  10  | P.CTMO | MSCP$W_CNT_TMO  |   2   | Controller timeout              |
21      |  18  |  22  |  12  |        |                 |   2   | Reserved                        |
22   |  |  18  |  22  |  12  | P.CSVR | MSCP$B_CNT_SVR  |   1   | Controller software version     |
23   |  |  19  |  23  |  13  | P.CHVR | MSCP$B_CNT_HVR  |   1   | Controller hardware version     |
24      |  20  |  24  |  14  | P.CNTI | MSCP$Q_CNT_ID   |   8   | Controller ID                   |
25      +------+------+------+--------+-----------------+-------+---------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                               Page A-9
                                                                                          08 Apr 82


 1                                 Table A-8   Error Log Message Offsets

 2      +--------------------+--------------------------+-------+---------------------------------+
 3      |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
 4      | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
 5      +------+------+------+--------+-----------------+-------+---------------------------------+
 6      | Generic Error Log Message Offsets:            |       |                                 |
 7      |   0  |   0  |   0  | L.CRF  | MSLG$L_CMD_REF  |   4   | Command reference number        |
 8      |   4  |   4  |   4  | L.UNIT | MSLG$W_UNIT     |   2   | Unit number                     |
 9      |   6  |   6  |   6  | L.SEQ  | MSLG$W_SEQ_NUM  |   2   | Sequence number                 |
10      |   8  |  10  |   8  | L.FMT  | MSLG$B_FORMAT   |   1   | Format                          |
11      |   9  |  11  |   9  | L.FLGS | MSLG$B_FLAGS    |   1   | Error log message flags         |
12      |  10  |  12  |   A  | L.EVNT | MSLG$W_EVENT    |   2   | Event code                      |
13      |  12  |  14  |   C  | L.CNTI | MSLG$Q_CNT_ID   |   8   | Controller ID                   |
14      |  20  |  24  |  14  | L.CSVR | MSLG$B_CNT_SVR  |   1   | Controller software version     |
15      |  21  |  25  |  15  | L.CHVR | MSLG$B_CNT_HVR  |   1   | Controller hardware version     |
16      |  22  |  26  |  16  | L.MLUN | MSLG$W_MULT_UNT |   2   | Multi-unit code                 |
17      |  24  |  30  |  18  | L.UNTI | MSLG$Q_UNIT_ID  |   8   | Unit ID                         |
18      |  32  |  40  |  20  | L.USVR | MSLG$B_UNIT_SVR |   1   | Unit software version           |
19      |  33  |  41  |  21  | L.UHVR | MSLG$B_UNIT_HVR |   1   | Unit hardware version           |
20      |  34  |  42  |  22  |        |                 |   2   | Format dependent                |
21      |  36  |  44  |  24  | L.VSER | MSLG$L_VOL_SER  |   4   | Volume serial number            |
22      |      |      |      |        |                 |       |                                 |
23      | Host Memory Access Errors with Bus Address Error Log Message Offsets:                   |
24      |  24  |  30  |  18  | L.BADR | MSLG$L_BUS_ADDR |   4   | Bus address                     |
25      |      |      |      |        |                 |       |                                 |
26      | Disk Transfer Errors Error Log Message Offsets:       |                                 |
27   |  |  34  |  42  |  22  | L.LVL  | MSLG$B_LEVEL    |   1   | Level                           |
28   |  |  35  |  43  |  23  | L.RTRY | MSLG$B_RETRY    |   1   | Retry                           |
29   |  |  36  |  44  |  24  | L.VSER | MSLG$L_VOL_SER  |   4   | Volume serial number            |
30   |  |  40  |  50  |  28  | L.HDCD | MSLG$L_HDR_CODE |   4   | Header code                     |
31      +------+------+------+--------+-----------------+-------+---------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Opcode, Flag, and Offset Definitions                                              Page A-10
                                                                                          08 Apr 82


 1                            Table A-8   Error Log Message Offsets  (cont.)

 2      +--------------------+--------------------------+-------+---------------------------------+
 3      |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
 4      | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
 5      +------+------+------+--------+-----------------+-------+---------------------------------+
 6      | SDI Errors Error Log Message Offsets:         |       |                                 |
 7   |  |  40  |  50  |  28  | L.HDCD | MSLG$L_HDR_CODE |   4   | Header code                     |
 8      |  44  |  54  |  2C  | L.SDI  | MSLG$Z_SDI      |  12   | SDI information                 |
 9      |      |      |      |        |                 |       |                                 |
10      | Small Disk Errors Error Log Message Offsets:  |       |                                 |
11      |  34  |  42  |  22  | L.SCYL | MSLG$W_SDE_CYL  |   2   | Cylinder                        |
12      |  36  |  44  |  24  | L.VSER | MSLG$L_VOL_SER  |   4   | Volume serial number            |
13      +------+------+------+--------+-----------------+-------+---------------------------------+


14                              Table A-9   Error Log Message Format Codes

15      +--------------------+--------------------------+-----------------------------------------+
16      |    Format Code     |   Preferred Mnemonics    |                                         |
17      | Dec. | Oct. | Hex. | 16 bit |      32 bit     |   Format Description                    |
18      +------+------+------+--------+-----------------+-----------------------------------------+
19      |   0  |   0  |   0  | FM.CNT | MSLG$K_CNT_ERR  | Controller Errors                       |
20      |   1  |   1  |   1  | FM.BAD | MSLG$K_BUS_ADDR | Host Memory Access Errors with Bus Addr.|
21      |   2  |   2  |   2  | FM.DSK | MSLG$K_DISK_TRN | Disk Transfer Errors                    |
22      |   3  |   3  |   3  | FM.SDI | MSLG$K_SDI      | SDI Errors                              |
23      |   4  |   4  |   4  | FM.SDE | MSLG$K_SML_DSK  | Small Disk Errors                       |
24      +------+------+------+--------+-----------------+-----------------------------------------+


25                                  Table A-10  Error Log Message Flags

26      +------+--------------+--------------------------+----------------------------------------+
27      | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
28      |Number| Octal | Hex. | 16 bit |32 bit (see note)|   Format Description                   |
29      +------+-------+------+--------+-----------------+----------------------------------------+
30      |   7  |   200 |   80 | LF.SUC | MSLG$x_LF_SUCC  | Operation Successful                   |
31      |   6  |   100 |   40 | LF.CON | MSLG$x_LF_CONT  | Operation Continuing                   |
32      |   0  |     1 |    1 | LF.SNR | MSLG$x_LF_SQNRS | Sequence Number Reset                  |
33      +------+-------+------+--------+-----------------+----------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)












 1                                              APPENDIX B

 2                                   STATUS AND EVENT CODE DEFINITIONS




 3      Notes:  1. The combination of a status or event code with a sub-code  should  be  expressed
 4                 (assuming 16 bit symbols) as:  (subcode*ST.SUB)+code

 5              2. In the sub-code tables, an asterisk in the "EV" column indicates that  the  code
 6                 and  sub-code  may  be  used  as  an event code.  An asterisk in the "ST" column
 7                 indicates that the code and sub-code may be used as a status code.
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Status and Event Code Definitions                                                  Page B-2
                                                                                          08 Apr 82


 1                                  Table B-1   Status and Event Codes

 2      +--------------------+--------------------------+-----------------------------------------+
 3      |       Value        |   Preferred Mnemonics    |                                         |
 4      | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Status or Event Code                |
 5      +------+------+------+--------+-----------------+-----------------------------------------+
 6      |   31 |   37 |   1F | ST.MSK | MSCP$M_ST_MASK  | Status / event code mask                |
 7      |   32 |   40 |   20 | ST.SUB | MSCP$K_ST_SBCOD | Sub-code multiplier                     |
 8      |      |      |      |        |                 |                                         |
 9      |    0 |    0 |    0 | ST.SUC | MSCP$K_ST_SUCC  | Success                                 |
10      |    1 |    1 |    1 | ST.CMD | MSCP$K_ST_ICMD  | Invalid Command                         |
11      |    2 |    2 |    2 | ST.ABO | MSCP$K_ST_ABRTD | Command Aborted                         |
12      |    3 |    3 |    3 | ST.OFL | MSCP$K_ST_OFFLN | Unit-Offline                            |
13      |    4 |    4 |    4 | ST.AVL | MSCP$K_ST_AVLBL | Unit-Available                          |
14      |    5 |    5 |    5 | ST.MFE | MSCP$K_ST_MFMTE | Media Format Error                      |
15      |    6 |    6 |    6 | ST.WPR | MSCP$K_ST_WRTPR | Write Protected                         |
16      |    7 |    7 |    7 | ST.CMP | MSCP$K_ST_COMP  | Compare Error                           |
17      |    8 |   10 |    8 | ST.DAT | MSCP$K_ST_DATA  | Data Error                              |
18      |    9 |   11 |    9 | ST.HST | MSCP$K_ST_HSTBF | Host Buffer Access Error                |
19      |   10 |   12 |    A | ST.CNT | MSCP$K_ST_CNTLR | Controller Error                        |
20      |   11 |   13 |    B | ST.DRV | MSCP$K_ST_DRIVE | Drive Error                             |
21      |   31 |   37 |   1F | ST.DIA | MSCP$K_ST_DIAG  | Message from an internal diagnostic     |
22      +------+------+------+--------+-----------------+-----------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Status and Event Code Definitions                                                  Page B-3
                                                                                          08 Apr 82


 1                         Table B-2   Standard Status and Event Sub-code Values

 2      +------+---------------------+-+-+--------------------------------------------------------+
 3      | Sub- |   Code + Sub-code   |E|S|                                                        |
 4      | code | Dec. |  Oct. | Hex. |V|T|          Status or Event Sub-Code                      |
 5      +------+------+-------+------+-+-+--------------------------------------------------------+
 6      | "Success" sub-code values: | | |                                                        |
 7      |   0  |    0 |     0 |    0 | |*| Normal                                                 |
 8      |   1  |   32 |    40 |   20 | |*| Spin-down Ignored                                      |
 9      |   2  |   64 |   100 |   40 | |*| Still Connected                                        |
10      |   4  |  128 |   200 |   80 | |*| Duplicate Unit Number                                  |
11      |   8  |  256 |   400 |  100 | |*| Already Online                                         |
12      |  16  |  512 |  1000 |  200 | |*| Still Online                                           |
13      |      |      |       |      | | |                                                        |
14      | "Invalid Command" sub-code values:                                                      |
15      |   0  |    1 |     1 |    1 | |*| Invalid Message Length                                 |
16      | many |      |       |      | |*| Other "Invalid Command" sub-codes values should be     |
17      |      |      |       |      | | | referenced as follows (note that this is combined with |
18      |      |      |       |      | | | the status code):                                      |
19      |      |      |       |      | | |                                                        |
20      |      |      |       |      | | |      offset*256.+code                                  |
21      |      |      |       |      | | |                                                        |
22      |      |      |       |      | | | where "offset" is the command message offset symbol    |
23      |      |      |       |      | | | for the field in error and "code" is the symbol for    |
24      |      |      |       |      | | | the "Invalid Command" status code.                     |
25      |      |      |       |      | | |                                                        |
26      | "Command Aborted" sub-code values:                                                      |
27      |      |      |       |      | |*| Sub-codes are not used.                                |
28      |      |      |       |      | | |                                                        |
29      | "Unit-Offline" sub-code values:                                                         |
30      |   0  |    3 |     3 |    3 | |*| Unit unknown or online to another controller.          |
31      |   1  |   35 |    43 |   23 | |*| No volume mounted or drive disabled via RUN/STOP switch|
32   |  |      |      |       |      | | |      (unit is in known substate of Unit-Offline)       |
33      |   2  |   67 |   103 |   43 | |*| Unit is inoperative                                    |
34      |   4  |  131 |   203 |   83 | |*| Duplicate unit number                                  |
35      |   8  |  259 |   403 |  103 | |*| Unit disabled by field service or internal diagnostic  |
36      +------+------+-------+------+-+-+--------------------------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Status and Event Code Definitions                                                  Page B-4
                                                                                          08 Apr 82


 1                    Table B-2   Standard Status and Event Sub-code Values  (cont.)

 2      +------+---------------------+-+-+--------------------------------------------------------+
 3      | Sub- |   Code + Sub-code   |E|S|                                                        |
 4      | code | Dec. |  Oct. | Hex. |V|T|          Status or Event Sub-Code                      |
 5      +------+------+-------+------+-+-+--------------------------------------------------------+
 6      | "Unit-Available" sub-code values:                                                       |
 7      |      |      |       |      | |*| Sub-codes are not used.                                |
 8      |      |      |       |      | | |                                                        |
 9      | "Media Format Error" sub-code values:                                                   |
10      | many |      |       |      |*|*| See Table B-3                                          |
11      |      |      |       |      | | |                                                        |
12      | "Write Protected" sub-code values:                                                      |
13      | 256  | 8198 | 20006 | 2006 | |*| Unit is Hardware Write Protected                       |
14      | 128  | 4102 | 10006 | 1006 | |*| Unit is Software Write Protected                       |
15      |      |      |       |      | | |                                                        |
16      | "Compare Error" sub-code values:                                                        |
17      |      |      |       |      | |*| Sub-codes are not used.                                |
18      |      |      |       |      | | |                                                        |
19      | "Data Error" sub-code values:  |                                                        |
20   |  |   0  |    8 |    10 |    8 | |*| Sector was written with "Force Error" modifier         |
21      | many |      |       |      |*|*| See Table B-3                                          |
22      |      |      |       |      | | |                                                        |
23      | "Host Buffer Access Error" sub-code values:                                             |
24      | many |      |       |      |*|*| See Table B-3                                          |
25      |      |      |       |      | | |                                                        |
26      | "Controller Error" sub-code values:                                                     |
27      |    0 |   10 |    12 |    A | | | Reserved for command timeout / retry limit exceeded.   |
28      | many |      |       |      |*|*| See Table B-3                                          |
29      |      |      |       |      | | |                                                        |
30      | "Drive Error" sub-code values:                                                          |
31      | many |      |       |      |*|*| See Table B-3                                          |
32      |      |      |       |      | | |                                                        |
33      | "Message from an internal diagnostic" sub-code values:                                  |
34      | many |      |       |      |*| | See Table B-3                                          |
35      +------+------+-------+------+-+-+--------------------------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Status and Event Code Definitions                                                  Page B-5
                                                                                          08 Apr 82


 1              Table B-3   Non-Standard Status and Event Sub-code Values                 
 2                    (Use of these sub-codes is controller or drive type dependent)

 3      +------+---------------------+-+-+--------------------------------------------------------+
 4      | Sub- |   Code + Sub-code   |E|S|                                                        |
 5      | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                           |
 6      +------+------+-------+------+-+-+--------------------------------------------------------+
 7   |  | "Media Format Error" sub-code values:                                                   |
 8   |  |    2 |   69 |   105 |   45 | |*| FCT unreadable -- Invalid sector header                |
 9      |    3 |  101 |   145 |   65 | |*| FCT unreadable -- Data sync timeout                    |
10      |    5 |  165 |   245 |   A5 | |*| Disk isn't formatted with 512 byte sectors             |
11      |    6 |  197 |   305 |   C5 | |*| Disk isn't formatted or FCT corrupted                  |
12      |    7 |  229 |   345 |   E5 | |*| FCT unreadable -- Uncorrectable ECC Error              |
13      |      |      |       |      | | |                                                        |
14   |  | "Data Error" sub-code values:  |                                                        |
15   |  |    2 |   72 |   110 |   48 |*|*| Header compare error (valid header not found)          |
16      |    3 |  104 |   150 |   68 |*|*| Data Sync not found (Data Sync timeout)                |
17      |    7 |  232 |   350 |   E8 |*|*| Uncorrectable ECC Error                                |
18      |    8 |  264 |   410 |  108 |*| | One Symbol ECC Error                                   |
19      |    9 |  296 |   450 |  128 |*| | Two Symbol ECC Error                                   |
20      |   10 |  328 |   510 |  148 |*| | Three Symbol ECC Error                                 |
21      |   11 |  360 |   550 |  168 |*| | Four Symbol ECC Error                                  |
22      |   12 |  392 |   610 |  188 |*| | Five Symbol ECC Error                                  |
23      |   13 |  424 |   650 |  1A8 |*| | Six Symbol ECC Error                                   |
24      |   14 |  456 |   710 |  1C8 |*| | Seven Symbol ECC Error                                 |
25      |   15 |  488 |   750 |  1E8 |*| | Eight Symbol ECC Error                                 |
26      |      |      |       |      | | |                                                        |
27      | "Host Buffer Access Error" sub-code values:                                             |
28      |    1 |   41 |    51 |   29 | |*| Odd transfer address                                   |
29      |    2 |   73 |   111 |   49 | |*| Odd byte count                                         |
30      |    3 |  105 |   151 |   69 | |*| Non-existent memory error                              |
31      |    4 |  137 |   211 |   89 | |*| Host memory parity error                               |
32      +------+------+-------+------+-+-+--------------------------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Status and Event Code Definitions                                                  Page B-6
                                                                                          08 Apr 82


 1              Table B-3   Non-Standard Status and Event Sub-code Values  (cont.)        
 2                    (Use of these sub-codes is controller or drive type dependent)

 3      +------+---------------------+-+-+--------------------------------------------------------+
 4      | Sub- |   Code + Sub-code   |E|S|                                                        |
 5      | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                           |
 6      +------+------+-------+------+-+-+--------------------------------------------------------+
 7      | "Controller Error" sub-code values:                                                     |
 8      |    1 |   42 |    52 |   2A |*|*| SERDES overrun error                                   |
 9   |  |    2 |   74 |   112 |   4A |*|*| EDC Error                                              |
10   |  |    3 |  106 |   152 |   6A |*|*| Inconsistent internal data structure.                  |
11      |      |      |       |      | | |                                                        |
12      | "Drive Error" sub-code values:                                                          |
13   |  |    1 |   43 |    53 |   2B |*|*| SDI command timed out (no response or seek incomplete) |
14   |  |    2 |   75 |   113 |   4B |*|*| Controller detected transmission or protocol error     |
15   |  |    3 |  107 |   153 |   6B |*|*| Positioner error (mis-seek)                            |
16   |  |    4 |  139 |   213 |   8B |*|*| Lost read/write ready during or between transfers      |
17   |  |    5 |  171 |   253 |   AB |*|*| Drive clock dropout                                    |
18   |  |    6 |  203 |   313 |   CB |*|*| Lost receiver ready between sectors                    |
19   |  |    7 |  235 |   353 |   EB |*|*| Drive detected error.                                  |
20   |  |    8 |  267 |   413 |  10B |*|*| Controller detected pulse or state parity error        |
21      +------+------+-------+------+-+-+--------------------------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)












 1                                              APPENDIX C

 2                              CONTROLLER, UNIT, AND MEDIA TYPE IDENTIFERS




 3      Notes:  1. Values for new products must be added to  this  appendix  via  an  ECO  to  this
 4                 specification.

 5              2. Values listed for unannounced products are preliminary and subject to change.


 6                       Table C-1   Controller and Unit Identifier "Class" Values

 7                      +----------+----------------------------------------------+
 8                      |Class Byte|                                              |
 9                      | (decimal)|     Subsystem Type                           |
10                      +----------+----------------------------------------------+
11                      |     0    | reserved -- must not be assigned             |
12                      |     1    | Mass storage controllers                     |
13   |                  |     2    | Disk class devices -- DEC Standard 166 disks |
14   |                  |     3    | Tape class devices                           |
15   |                  |     4    | Disk class devices -- DEC Standard 144 disks |
16                      +----------+----------------------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Controller, Unit, and Media Type Identifers                                        Page C-2
                                                                                          08 Apr 82


 1                          Table C-2   Mass Storage Controller "Model" Values

 2                           +----------+-----------------------------------+
 3                           |Model Byte|                                   |
 4                           | (decimal)|     Controller Type               |
 5                           +----------+-----------------------------------+
 6                           |     0    | reserved -- must not be assigned  |
 7                           |     1    | HSC50                             |
 8                           |     2    | UDA50                             |
 9                           |     3    | Aztec                             |
10   |                       |     4    | VMS (software MSCP server)        |
11   |                       |     5    | TU81 integrated controller        |
12   |                       |     6    | UDA52                             |
13   |                       |     7    | RD51/RX50                         |
14                           +----------+-----------------------------------+


15                          Table C-3   DEC Standard 166 Disk Identifier Values

16      +----------+---------+-------+---------------------------+--------------------------------+
17      |Model Byte|  Device | Media |   Media Type Identifier   |                                |
18      | (decimal)|Type Name| Name  |     octal     |    hex    |     Device                     |
19      +----------+---------+-------+---------------+-----------+--------------------------------+
20      |     0    |                         Reserved -- must not be assigned.                    |
21      |     1    |    DU   | RA80  | 022544,010120 | 2564,1050 | RA80 fixed disk drive.         |
22   |  |     2    |    DA   | RC25  | 020144,030031 | 2064,3019 | Aztec removable disk drive.    |
23   |  |     3    |    DA   | RCF25 | 020144,031431 | 2064,3319 | Aztec fixed disk drive.        |
24      |     4    |    DJ   | RA60  | 021244,010074 | 22A4,103C | Pinon removable disk drive.    |
25   |  |     5    |    DU   | RA81  | 022544,010121 | 2564,1051 | RA81 fixed disk drive.         |
26   |  |     6    |    DU   | RD51  | 022544,040063 | 2564,4033 | 10MB fixed disk drive.         |
27   |  |     7    |    DU   | RX50  | 022545,100062 | 2565,8032 | 5 1/4 inch floppy disk drive.  |
28      +----------+---------+-------+---------------+-----------+--------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)
        Controller, Unit, and Media Type Identifers                                        Page C-3
                                                                                          08 Apr 82


 1                                  Table C-4   Tape Identifier Values

 2      +----------+---------+-------+---------------------------+--------------------------------+
 3      |Model Byte|  Device | Media |   Media Type Identifier   |                                |
 4      | (decimal)|Type Name| Name  |     octal     |    hex    |     Device                     |
 5      +----------+---------+-------+---------------+-----------+--------------------------------+
 6      |     0    |                         Reserved -- must not be assigned.                    |
 7   |  |     1    |    MF   | TU78  | 064651,050116 | 69A9,504E | PE/GCR, 125 ips start/stop     |
 8      |     2    |    MU   | TU81  | 066551,050121 | 6D69,5051 | PE/GCR, 25/75 ips streamer     |
 9      +----------+---------+-------+---------------+-----------+--------------------------------+
        Copyright 1982 by Digital Equipment Corp.                              COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2                               (Edward A. Gardner)












 1                                 APPENDIX D

 2                          BUFFER DESCRIPTOR FORMATS



 3      The information in this Appendix is NOT a formal  part  of  MSCP.
 4      The  formal  specification  for  buffer  descriptors  is  in  the
 5      individual   communications   mechanism   specifications.    This
 6      information  is  summarized here in order to provide a convenient
 7      reference for all buffer descriptors in a single document.

 8      It  is  recommended  that  communications  mechanisms  adhere  as
 9      closely  as possible to the following preferred or generic buffer
10      descriptor format.  Although not required by MSCP, similarity  of
11      buffer descriptor format can only simplify the design of host and
12      controller  port  drivers.   The  preferred  or  generic   buffer
13      descriptor format is as follows:

14                      31                             0 
15                      +-------------------------------+
16                      |   offset to start of buffer   |
17                      +-------------------------------+
18                      |          buffer name          |
19                      +-------------------------------+
20                      |     connection identifier     |
21                      +-------------------------------+

22      The "connection  identifier"  identifies  a  specific  connection
23      across  which  the  block  data transfer should take place.  Thus
24      this field identifies, in a  communications  mechanism  dependent
25      manner,  the  host  or  node  with which the transfer should take
26      place.   The  "buffer  name"  identifies,  in  a   communications
27      mechanism  dependent  manner,  the  buffer or region of memory on
28      that system to which the transfer should take place.  The "offset
29      to  start of buffer" is the byte offset from the beginning of the
30      named buffer to the point at which the transfer  should  actually
31      start.

32      The "connection identifier" allows for third party  transfers  --
33      that  is,  it  allows a host to request transfers to or from some
34      other host's memory.  The "buffer name" provides a logical rather
35      than  physical  identification  of  the  buffer, thus simplifying
36      virtual memory management and possibly  providing  a  consistency
37      check  that the buffer is valid.  The "offset to start of buffer"
38      simplifies certain aspects of third party transfers.  It allows a
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Buffer Descriptor Formats                                Page D-2
                                                                08 Apr 82


 1      controlling host to accept a transfer from some other host, break
 2      the  transfer  up  into  segments,  and  forward   each   segment
 3      independently to a controller.  Such segmentation of transfers is
 4      especially useful  with  file  systems,  in  which  a  contiguous
 5      transfer  within  a  file  may  require  transferring  physically
 6      discontiguous portions of a disk.

 7      The buffer descriptor used with the CI  communications  mechanism
 8      uses   the  exact  format  illustrated  for  the  generic  buffer
 9      descriptor.  The "offset to start of buffer"  is  indeed  a  byte
10      offset  and  the  "buffer  name"  is the CI block transfer buffer
11   |  name.   The  "connection  identifier"  is  the  controller's  SCA
12      connection  identifier  for the connection between the disk class
13      driver and the disk MSCP server.

14      The format of the buffer descriptor  used  with  the  Unibus  and
15      Q-bus is as follows:

16                      31                             0 
17                      +-------+-----------------------+
18                      | chan  |buffer physical address|
19                      +-------+-----------------------+
20                      |           reserved            |
21                      +-------------------------------+
22                      |           reserved            |
23                      +-------------------------------+

24      The following interpretation shows how this  is  consistent  with
25      the  generic  buffer descriptor format.  The Unibus and Q-bus are
26      inherently single  host  busses.   Furthermore,  all  anticipated
27      controllers  for these busses only support a single device class.
28      Therefore there can only be a single connection between the  host
29      and  any  controller.   Thus  it  is reasonable to assign a fixed
30      connection identifier of zero.  Secondly, since these busses  are
31      not  used with any (bus visible) form of virtual memory, there is
32      no use for the concept of a logical  buffer  name.   Thus  it  is
33      reasonable  to  assign  a fixed buffer name of zero, denoting the
34      entire address space available on the bus.  This leaves  the  the
35      offset  field  to  denote  the  byte offset from address zero, or
36      merely  the  starting  address  of  the  buffer.   In  order   to
37      accomodate  VAX-11/780  UBAs,  it is necessary to include the UBA
38      channel number so that controllers can request UBA purges.   This
39      has  been placed with the bus address for controller convenience,
40      even though aesthetics might argue for it being called a  "buffer
41      name".
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)












 1                                 APPENDIX E

 2                              REVISION HISTORY



 3   |  The following changes were made from MSCP  Version  1.1  to  MSCP
 4   |  Version 1.2:
 5   |  
 6   |       1.  Editorial changes, primarily due to MSCP being  reviewed
 7   |           by  the  technical documentation group.  As part of this
 8   |           review  Chapter  1,  the  Introduction,  was  completely
 9   |           rewritten.   Other  editorial  changes  are  due to some
10   |           reviewer's request for a clarification.
11   |  
12   |       2.  The discussion of  Reserved  and  Undefined  fields  was
13   |           expanded and made into a separate section (Section 5.2).
14   |           This is in response to the frequent confusion concerning
15   |           this  topic  in  the  past.  Note that these changes are
16   |           purely editorial.
17   |  
18   |       3.  Consistent terminology was adopted for the ways in which
19   |           execution  of  a  command can finish.  Thus a command is
20   |           now  said  to  be  completed,  aborted,  terminated,  or
21   |           rejected.   These  terms  are defined in section 4.5 and
22   |           used consistently throughout the document.
23   |  
24   |       4.  Addition of the "controller dependent parameters"  field
25   |           to the SET CONTROLLER CHARACTERISTICS command.
26   |  
27   |       5.  The "Disk Transfer Errors" error log message format  was
28   |           substantially  changed.  Formerly this message contained
29   |           "logical block number",  "cylinder",  "group",  "track",
30   |           and  "sector" fields.  These have all been replaced with
31   |           a single "header code" field, which the host's error log
32   |           analyzer can decode if it desires.
33   |  
34   |       6.  The  "SDI  Errors"  error   log   message   format   was
35   |           substantially  changed.  Formerly this message contained
36   |           "logical block number", "cylinder", and "group"  fields.
37   |           These  have  been  replaced  with a single "header code"
38   |           field, which the host's error log analyzer can decode if
39   |           it desires.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Revision History                                         Page E-2
                                                                08 Apr 82


 1   |       7.  "EDC Error" has been eliminated as  a  sub-code  of  the
 2   |           "Media  Format  Error"  and  "Data  Error" status codes.
 3   |           Instead it is now a sub-code of the  "Controller  Error"
 4   |           status  code.   This  reflects  the fact that EDC errors
 5   |           should only be caused  by  faulty  controllers,  not  by
 6   |           faulty  disks.   Any  disk error that might cause an EDC
 7   |           error should also  cause  an  uncorrectable  ECC  error,
 8   |           which will be reported instead of the EDC error.
 9   |  
10   |       8.  Sub-codes  of  the  "Drive  Error"  status   code   were
11   |           completely  revised  to  reflect what the UDA50 actually
12   |           returns.
13   |  
14   |       9.  Additional identifiers  were  added  to  Appendix  C  to
15   |           reflect  all prospective MSCP devices that we know of at
16   |           this time.   In  addition,  the  Aztec  media  name  was
17   |           changed to reflect its new device name (RC25).
18   |  
19   |      10.  An additional rule for MSCP servers was added to Section
20   |           3.4.   This  rule  can  be  summarized  as  saying  that
21   |           bootstraps have to work, even though they  won't  follow
22   |           all  the  rules for "real" class drivers.  This rule has
23   |           always  existed  implicitly,  it  just  has  never  been
24   |           written down before.
25   |  
26   |      11.  The RCT has been made  optional  for  certain  types  of
27   |           devices.   This is primarily aimed at the RX51 and other
28   |           low end disks.
29   |  
30   |      12.  The discussion of forced errors was  expanded  to  state
31   |           that  the data must be recorded and preserved regardless
32   |           of  the  presence  of  a  forced  error  in   a   block.
33   |           Previously  this  was  a piece of folklore that everyone
34   |           "knew" to be true, as it was not formerly written down.
35   |  
36   |      13.  Unit and controller revision numbers were added  to  the
37   |           GET  UNIT  STATUS and SET CONTROLLER CHARACTERISTICS end
38   |           messages.
39   |  
40   |      14.  Statements were added that unit and controller  revision
41   |           numbers  need  not be returned if the groups responsible
42   |           for a product feel they are unnecessary.  This is merely
43   |           making  an  explicit  statement  of what has always been
44   |           implicitly true.
45   |  
46   |      15.  The Invalid Command End Message format was  extended  to
47   |           return  a  controller  dependent  portion of the command
48   |           parameter fields.  Thus the entire can be returned  with
49   |           only  the  opcode  and  modifiers fields lost, hopefully
50   |           simplifying error diagnosis.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Revision History                                         Page E-3
                                                                08 Apr 82


 1   |      16.  A waivers and exceptions chapter was  added  to  provide
 2   |           "grandfather"  exceptions for products that have already
 3   |           shipped, and therefore do not have  some  of  the  above
 4   |           changes implemented.
 5   |  
 6   |      17.  A clarifications chapter was added to record answers  to
 7   |           frequently asked questions and clarifications that don't
 8   |           fit in anywhere else.
 9   |  

10      The following changes were made from MSCP  Version  1.0  to  MSCP
11      Version 1.1:

12           1.  Editorial changes, including clarifications  in  various
13               sections.

14           2.  Addition  of  this  Appendix,  containing  the  Revision
15               History.

16           3.  Addition of Appendix D, Buffer Descriptor Formats.

17           4.  Addition of non-goal stating MSCP will  not  attempt  to
18               standardize  device  specific  error log information and
19               the interpretation of such information.

20           5.  Reduction of the required unit number range from 0  thru
21               255  to  0  thru 251.  The purpose of this change was to
22               allow a specific value (all ones) to  indicate  that  no
23               unit number is present.

24           6.  The majority of unit characteristics  will  be  provided
25               (to  hosts)  when  a unit is "Unit-Offline" but known to
26               exist.  This is necessary for generic device  allocation
27               --  previous  versions,  due  to an oversight, specified
28               that unit characteristics were not provided when a  unit
29               was "Unit-Offline".

30           7.  As a necessary  side  effect  of  the  previous  change,
31               duplicate  unit  numbers  must be checked for units that
32               are  "Unit-Offline"   but   otherwise   known   to   the
33               controller.   The  reason  for  this  is that controller
34               needs a unique set of characteristics to  return,  which
35               is not necessarily possible when a duplicate unit number
36               exists.

37           8.  The  command  timeout  requirements  were  loosened  for
38               aborted  commands  on  single host controllers, allowing
39               the  controllers  to  timeout  in  various  pathological
40               situations.  If this occurs the command will effectively
41               be aborted by the host reinitializing the controller.
        Copyright 1982 by Digital Equipment Corp.    COMPANY CONFIDENTIAL
        Mass Storage Control Protocol Version 1.2     (Edward A. Gardner)
        Revision History                                         Page E-4
                                                                08 Apr 82


 1           9.  The requirements for host access timeout timing accuracy
 2               were  loosened,  so  that  controllers need not maintain
 3               accurate  timeouts  for  an  idle  host  when  they  are
 4               saturated with work from other hosts.

 5          10.  Added the "Controller Initiated Bad  Block  Replacement"
 6               controller flag.

 7          11.  The maximum number of error log messages per  error  was
 8               increased from 2 to 3.

 9          12.  Waivers and exceptions relating to the BXV11, which  has
10               been cancelled, were removed.

11          13.  Host identifiers and the "Alter Host Identifier" command
12               modifier were removed.

13          14.  The "Error Log Flags" field was renamed to be a  general
14               purpose "Device Dependent Parameters" field.

15          15.  Sub-codes of the "Success" status code  were  reassigned
16               so  that all sub-codes would be unique bit flags.  I.e.,
17               the same bit will not have different meanings  depending
18               on the command.

19          16.  Sub-codes  of  the  "Unit-Offline"  status   code   were
20               reassigned to be bit flags, so that multiple reasons for
21               a device being "Unit-Offline"  could  be  reported.   In
22               addition,  an  additional  (unique) sub-code was defined
23               for the case of a unit being inoperative.

24          17.  Sub-codes of the  "Write  Protected"  status  code  were
25               reassigned to be bit flags.

26          18.  Unit and media type identifiers were defined for  Aztec.
27               In addition, preliminary values were defined for various
28               products that are currently under development.
   <<Begin approved ECOs>>


   <<ECO #: MSCP12-1 Geometry Valid Only When Online [approved March 1983]>>


ECO #: MSCP12-1          Due  to an  oversight, MSCP  is missing an important restriction.
ECO #: MSCP12-1          Unfortuneately, this  may  cause  some  problems  for  host class
ECO #: MSCP12-1          drivers. The restriction is: 

ECO #: MSCP12-1               All disk geometry fields are only valid  when  the  unit  is
ECO #: MSCP12-1               "Unit-Online".   Their  contents are undefined when the unit
ECO #: MSCP12-1               is "Unit-Offline" or "Unit-Available".


ECO #: MSCP12-1          The exact fields affected are as follows:

ECO #: MSCP12-1               GET UNIT STATUS end message:

ECO #: MSCP12-1                    track size
ECO #: MSCP12-1                    group size
ECO #: MSCP12-1                    cylinder size
ECO #: MSCP12-1                    RCT size
ECO #: MSCP12-1                    RBNs
ECO #: MSCP12-1                    copies

ECO #: MSCP12-1               ONLINE and SET UNIT CHARACTERISTICS end messages:

ECO #: MSCP12-1                    unit size

ECO #: MSCP12-1          The contents of these fields are undefined whenever the  unit  is
ECO #: MSCP12-1          not "Unit-Online".

ECO #: MSCP12-1          This translates to three cases:

ECO #: MSCP12-1               1.  Unit is "Unit-Offline" and unknown to controller.   Only
ECO #: MSCP12-1                   "shadow  unit" and "shadow status" are valid.  All other
ECO #: MSCP12-1                   fields and all unit flags are undefined.

ECO #: MSCP12-1               2.  Unit  is  "Unit-Offline"  and  known  to  controller  or
ECO #: MSCP12-1                   "Unit-Available".    Only   "multi-unit   code",   "unit
ECO #: MSCP12-1                   identifier", "media  type  identifier",  "shadow  unit",
ECO #: MSCP12-1                   "shadow   status",  "usvrsn",  and  "uhvrsn"  are  valid
ECO #: MSCP12-1                   ("usvrsn" and "uhvrsn" are only in the GET  UNIT  STATUS
ECO #: MSCP12-1                   end  message).   Only the "Removable Media" unit flag is
ECO #: MSCP12-1                   valid.  All other fields and unit flags are undefined.
ECO #: MSCP12-1          	   						   Page 2


ECO #: MSCP12-1               3.  Unit is "Unit-Online".  All fields and  all  unit  flags
ECO #: MSCP12-1                   are valid.


ECO #: MSCP12-1          The reason for this is as follows.  Consider a drive such as  the
ECO #: MSCP12-1          RA80.   The  geometry  of the drive -- i.e., the number of blocks
ECO #: MSCP12-1          per track and therefore the unit size -- is  different  depending
ECO #: MSCP12-1          on  whether  the  drive  has 512 or 576 byte sectors.  The sector
ECO #: MSCP12-1          size  is  not  determined  until  the  unit  is  brought  online.
ECO #: MSCP12-1          Therefore  the geometry parameters cannot be determined until the
ECO #: MSCP12-1          unit is online, and are invalid whenever the unit is not online.

ECO #: MSCP12-1          One alternative that someone might suggest is that we return  the
ECO #: MSCP12-1          geometry parameters for 512 byte sectors whenever the unit is not
ECO #: MSCP12-1          "Unit-Online".  Thus only 10/20 systems would  be  affected,  and
ECO #: MSCP12-1          they   can   handle   it   since   they're   not   shipping  yet.
ECO #: MSCP12-1          Unfortuneately this doesn't work either.  The RA60 has two  types
ECO #: MSCP12-1          of  packs -- one that only supports 512 byte sectors and one that
ECO #: MSCP12-1          supports both  512  and  576  byte  sectors.   The  geometry  and
ECO #: MSCP12-1          capacity  is different for the two pack types, even when both are
ECO #: MSCP12-1          formatted for 512 byte  sectors.   The  pack  type  can  only  be
ECO #: MSCP12-1          determined  when  the drive is spinning, and the only time we can
ECO #: MSCP12-1          be sure the drive is spinning is when it is online.  Therefore we
ECO #: MSCP12-1          can  only  determine the pack's geometry when it is online.  This
ECO #: MSCP12-1          problem is generic to any drive that has:  1)  removeable  media,
ECO #: MSCP12-1          2) embedded servo, and 3) supports both 512 and 576 byte sectors.


   <<End ECO #: MSCP12-1 Geometry Valid Only When Online>>


   <<ECO #: MSCP12-2 Error Log Sequence Numbers [approved 7 February 1984]>> 


ECO #: MSCP12-2          The majority of all  error  log  messages  produced  by  an  MSCP
ECO #: MSCP12-2          controller  report  errors encountered while executing a specific
ECO #: MSCP12-2          command.  This information is reported by including the command's
ECO #: MSCP12-2          reference  number  in  the  error  log message and by setting the
ECO #: MSCP12-2          "error log generated" flag in the command's end  message.   Error
ECO #: MSCP12-2          log analysis programs use this information to correlate the error
ECO #: MSCP12-2          back with the original host request, obtaining  such  information
ECO #: MSCP12-2          as the requesting program or whatever.

ECO #: MSCP12-2          The problem that arises is that MSCP allows error log messages to
ECO #: MSCP12-2          arrive out of sequence with respect to the end message.  That is,
ECO #: MSCP12-2          error log messages pertaining to a particular command may  arrive
ECO #: MSCP12-2          either  before  or  after  that command's end message.  Therefore
ECO #: MSCP12-2          matching error log messages with commands cannot always  be  done
ECO #: MSCP12-2          reliably,  and  has  the potential for consuming large amounts of
ECO #: MSCP12-2          resources (I've heard rumors of VMS sorting it's entire error log
ECO #: MSCP12-2          file...).

ECO #: MSCP12-2          MSCP allows error log messages to arrive after  the  end  message
ECO #: MSCP12-2          for  two  reasons  --  communications  mechanism  asynchrony  and
ECO #: MSCP12-2          controller asynchrony.  Communications  mechanism  asynchrony  is
ECO #: MSCP12-2          not  a  problem  -- it doesn't exist for all current and proposed
ECO #: MSCP12-2          communications mechanisms.  That is,  all  current  and  proposed
ECO #: MSCP12-2          communications  mechanisms  guarantee that, if a datagram is sent
ECO #: MSCP12-2          before a sequenced message,  and  the  datagram  is  successfully
ECO #: MSCP12-2          received,  then  the  datagram  is  received before the sequenced
ECO #: MSCP12-2          message.  (This guarantee isn't written into the  SCA  spec,  but
ECO #: MSCP12-2          it's  true  all  the  same).  Furthermore, even on communications
ECO #: MSCP12-2          mechanisms for which this guarantee wouldn't be  true,  it  would
ECO #: MSCP12-2          still  apply  to  virtually all datagrams, and "virtually all" is
ECO #: MSCP12-2          good enough for error log messages.

ECO #: MSCP12-2          Unfortuneately, having a well  behaved  communications  mechanism
ECO #: MSCP12-2          isn't good enough -- the communications mechanism only matters if
ECO #: MSCP12-2          the controller sends  the  error  log  messages  before  the  end
ECO #: MSCP12-2          message.   It  happens  that  this  is  not  true  for the HSC50.
ECO #: MSCP12-2          Although in principle the HSC50 could send the error log messages
ECO #: MSCP12-2          first,  this  would  require a major redesign of it error logging
ECO #: MSCP12-2          code.  There is no way this could be done prior to HSC FCS.
ECO #: MSCP12-2          							   Page 2


ECO #: MSCP12-2          So lets go back and look at what we want to accomplish.  The goal
ECO #: MSCP12-2          is  to  simplify matching error log messages with commands.  That
ECO #: MSCP12-2          is, we want to match a  command's  context  with  its  associated
ECO #: MSCP12-2          error  log  message.   To  do  this  simply,  we need to have the
ECO #: MSCP12-2          command's context  when  the  error  log  message  arrives.   The
ECO #: MSCP12-2          simplest approach, that of ensuring the error log message arrives
ECO #: MSCP12-2          before the command completes, when the context  must  necessarily
ECO #: MSCP12-2          be   around,   can't  be  used  per  the  discussion  above.   An
ECO #: MSCP12-2          alternative approach, almost as simple, is to  provide  a  simple
ECO #: MSCP12-2          way for a host to determine when the last error log message for a
ECO #: MSCP12-2          command has arrived.  If  an  end  message  had  the  "error  log
ECO #: MSCP12-2          generated"  flag  set,  the host would keep the command's context
ECO #: MSCP12-2          around until the last error log message  arrived.   This  is  the
ECO #: MSCP12-2          approach  that  I  suggest we adopt, and is the substance of this
ECO #: MSCP12-2          ECO.

ECO #: MSCP12-2          Error log messages already include an error log sequence  number,
ECO #: MSCP12-2          used  by  the  host to recognize missing and duplicated error log
ECO #: MSCP12-2          messages.  The sequence number of  the  last  error  log  message
ECO #: MSCP12-2          generated  for  a  particular  command  can  be  included  in the
ECO #: MSCP12-2          command's  end  message.   The  host  maintains  a  copy  of  the
ECO #: MSCP12-2          command's  context  until  that error log message arrives.  Since
ECO #: MSCP12-2          error log messages may be lost, the host must  also  release  the
ECO #: MSCP12-2          command's  context  if a later error log message arrives or if no
ECO #: MSCP12-2          error log message arrives within the controller timeout  interval
ECO #: MSCP12-2          (the  actual  timeout  used  doesn't  matter, but that's the most
ECO #: MSCP12-2          convenient one to use since it's already present).

ECO #: MSCP12-2          The actual details of the ECO are as follows:

ECO #: MSCP12-2               1.  Bytes 6 and  7  are  currently  reserved  in  every  end
ECO #: MSCP12-2                   message  (the  word  just after the unit number).  These
ECO #: MSCP12-2                   two bytes become the "error log sequence number"  field.
ECO #: MSCP12-2                   Note  that  this is in the same position as the sequence
ECO #: MSCP12-2                   number field in error log messages.

ECO #: MSCP12-2               2.  If the "Error Log Generated" flag is  clear  in  an  end
ECO #: MSCP12-2                   message,  then  the "error log sequence number" field is
ECO #: MSCP12-2                   reserved (and it's  contents  must  be  zero).   If  the
ECO #: MSCP12-2                   "Error  Log  Generated"  flag  is set in an end message,
ECO #: MSCP12-2                   then the "error log sequence number" field must  contain
ECO #: MSCP12-2                   the  sequence  number of the last error log message that
ECO #: MSCP12-2                   references this command's  "command  reference  number".
ECO #: MSCP12-2                   The  last  error  log  message may or may not be sent to
ECO #: MSCP12-2                   hosts,  depending  on  the  availability  of  controller
ECO #: MSCP12-2                   resources.

ECO #: MSCP12-2               3.  On each individual connection, the MSCP server must send
ECO #: MSCP12-2                   error  log  messages in the same order as their sequence
ECO #: MSCP12-2                   numbers.  (Remember that sequence numbers  wrap  around,
ECO #: MSCP12-2                   so  that  sequence  number 0 comes after sequence number
ECO #: MSCP12-2                   65535).  The relative order of error log  messages  sent
ECO #: MSCP12-2                   on  different  connections is undefined (and therefore a
ECO #: MSCP12-2                   controller option).
ECO #: MSCP12-2          							   Page 3


ECO #: MSCP12-2               4.  MSCP allows controllers that meet  certain  requirements
ECO #: MSCP12-2                   to  not  implement  error  log  sequence  numbers.  Such
ECO #: MSCP12-2                   controllers  always  return  zero  for  the  error   log
ECO #: MSCP12-2                   sequence  number  and  always  set  the "Sequence Number
ECO #: MSCP12-2                   Reset" flag in error  log  messages.   The  requirements
ECO #: MSCP12-2                   that  such  controllers  must  meet  are  listed in MSCP
ECO #: MSCP12-2                   Version  1.2,  page  8-2,  lines  27  through  40.   The
ECO #: MSCP12-2                   following additional requirement is added to this list:

ECO #: MSCP12-2                   The  MSCP  server  and  communications  mechanism   must
ECO #: MSCP12-2                   guarantee  that  the class driver will receive all error
ECO #: MSCP12-2                   log  messages  that  reference  a  particular  command's
ECO #: MSCP12-2                   reference  number  before  receiving  that command's end
ECO #: MSCP12-2                   message.

ECO #: MSCP12-2               5.  An MSCP server has pending  error  log  messages  for  a
ECO #: MSCP12-2                   connection  whenever it has notified the class driver on
ECO #: MSCP12-2                   that connection that one or more error log messages  are
ECO #: MSCP12-2                   forthcoming (i.e., set the "Error Log Generated" flag in
ECO #: MSCP12-2                   an end message), but has not yet  sent  or  dropped  all
ECO #: MSCP12-2                   error  log  messages up to the one whose sequence number
ECO #: MSCP12-2                   was reported in the end  message.   The  term  "dropped"
ECO #: MSCP12-2                   refers  to  the MSCP server determining that it will not
ECO #: MSCP12-2                   send a message due to lack of some internal resource.

ECO #: MSCP12-2                   Whenever an MSCP server has pending error  log  messages
ECO #: MSCP12-2                   for  a  connection,  it must send at least one error log
ECO #: MSCP12-2                   message on that connection within the controller timeout
ECO #: MSCP12-2                   interval.

ECO #: MSCP12-2                   Note that controllers that do not  implement  error  log
ECO #: MSCP12-2                   sequence  numbers never have pending error log messages,
ECO #: MSCP12-2                   and can ignore  this  requirement.   This  is  a  direct
ECO #: MSCP12-2                   consequence  of  the  requirements that such controllers
ECO #: MSCP12-2                   must meet in order to not implement error  log  sequence
ECO #: MSCP12-2                   numbers.

ECO #: MSCP12-2          All current controllers (i.e., the UDA50 and UDA52) already  meet
ECO #: MSCP12-2          the  above  requirements.   This  is  true since they always zero
ECO #: MSCP12-2          bytes 6 and 7 of end messages, they always report  an  error  log
ECO #: MSCP12-2          sequence  number  of  zero,  and error log messages always arrive
ECO #: MSCP12-2          before the corresponding end message.

ECO #: MSCP12-2          An example of how a host  might  use  this  follows.   The  class
ECO #: MSCP12-2          driver  keeps  track  of  the  sequence number of the most recent
ECO #: MSCP12-2          error log message it has received.  This sequence  number  should
ECO #: MSCP12-2          be  initialized  to  zero  when  the  connection  is established.
ECO #: MSCP12-2          Furthermore, in use command slots  (containing  command  context)
ECO #: MSCP12-2          come  in  two  forms  -- active commands and commands waiting for
ECO #: MSCP12-2          error log messages.  The class driver also keeps track of whether
ECO #: MSCP12-2          or  not  it  has  received  an  error  log  message  within  each
ECO #: MSCP12-2          controller timeout interval for its command timeout algorithm.

ECO #: MSCP12-2          When the class driver receives an end message,  it  first  checks
ECO #: MSCP12-2          the  "Error  Log  Generated"  flag.   If  that  flag is clear, it
ECO #: MSCP12-2          releases the command slot as no longer in use.  If that  flag  is
ECO #: MSCP12-2          							   Page 4


ECO #: MSCP12-2          set,  it  calls  the  RELEASE_SLOT  procedure.  If that procedure
ECO #: MSCP12-2          returns TRUE, it releases the command slot as no longer  in  use.
ECO #: MSCP12-2          If that procedure returns FALSE, it marks the slot as waiting for
ECO #: MSCP12-2          error log messages.  The RELEASE_SLOT procedure is at the end  of
ECO #: MSCP12-2          this  memo.  The procedure is called with the "error log sequence
ECO #: MSCP12-2          number" from the command's end message and the sequence number of
ECO #: MSCP12-2          the most recent error log message the class driver has received.

ECO #: MSCP12-2          When the class driver receives an error log message, it calls the
ECO #: MSCP12-2          RELEASE_SLOT procedure once for each command slot that is waiting
ECO #: MSCP12-2          for error log messages.   If  that  procedure  returns  TRUE,  it
ECO #: MSCP12-2          releases the command slot as no longer in use.  If that procedure
ECO #: MSCP12-2          returns FALSE, the slot remains marked as waiting for  error  log
ECO #: MSCP12-2          messages.   The  procedure  is called with the error log sequence
ECO #: MSCP12-2          number from the command  slot  (copied  from  the  command's  end
ECO #: MSCP12-2          message) and the sequence number of the new error log message.

ECO #: MSCP12-2          Command slots that are waiting for error log messages participate
ECO #: MSCP12-2          in  the class driver's command timeout algorithm just the same as
ECO #: MSCP12-2          slots  for  outstanding  commands.   If  the  oldest  outstanding
ECO #: MSCP12-2          command  slot is waiting for error log messages, the class driver
ECO #: MSCP12-2          checks if any error log messages have been  received  within  the
ECO #: MSCP12-2          controller  timeout  interval.  If one or more error log messages
ECO #: MSCP12-2          have been received, the slot remains in use.   If  no  error  log
ECO #: MSCP12-2          messages  have been received, the command slot is released -- the
ECO #: MSCP12-2          error log message for which the slot was waiting has been lost.

ECO #: MSCP12-2          The RELEASE_SLOT procedure accepts an error log  sequence  number
ECO #: MSCP12-2          from  an  end  message  and  a  sequence number from an error log
ECO #: MSCP12-2          message.  It returns TRUE if the error log number comes after the
ECO #: MSCP12-2          end  message  number  and FALSE otherwise.  This comparison takes
ECO #: MSCP12-2          into account sequence number wrap-around.  The procedure is:

ECO #: MSCP12-2               function RELEASE_SLOT (
ECO #: MSCP12-2                   end_msg_number : 0..65535 ;
ECO #: MSCP12-2                   err_log_number : 0..65535 ) : boolean ;
ECO #: MSCP12-2               const
ECO #: MSCP12-2                   FUDGE = 1 ;
ECO #: MSCP12-2               var
ECO #: MSCP12-2                   i : -65535..65535 ;
ECO #: MSCP12-2               begin ;
ECO #: MSCP12-2                   { following three lines are just a 16 bit signed }
ECO #: MSCP12-2                   { subtract operation, ignoring integer overflow  }
ECO #: MSCP12-2                   { (i.e., the PDP-11 SUB instruction).            }
ECO #: MSCP12-2                   i := err_log_number - end_msg_number ;
ECO #: MSCP12-2                   if i < -32768 then i := i + 65536 ;
ECO #: MSCP12-2                   if i >  32767 then i := i - 65536 ;
ECO #: MSCP12-2                   RELEASE_SLOT := (i >= FUDGE-1) ;
ECO #: MSCP12-2               end ;

ECO #: MSCP12-2          The constant  FUDGE  is  the  maximum  degree  of  communications
ECO #: MSCP12-2          mechanism non-sequentiality for datagrams.  Assume that datagrams
ECO #: MSCP12-2          n, n+1, n+2, etc. are sent in that  order  across  a  connection.
ECO #: MSCP12-2          FUDGE   is  the  smallest  value  for  which  the  communications
ECO #: MSCP12-2          mechanism guarantees  that,  if  both  datagram  n  and  datagram
ECO #: MSCP12-2          n+FUDGE are received, then datagram n is received before datagram
ECO #: MSCP12-2          							   Page 5


ECO #: MSCP12-2          n+FUDGE.  All current and proposed communications mechanisms have
ECO #: MSCP12-2          sequential  datagrams,  for which FUDGE is one.  The only type of
ECO #: MSCP12-2          communications mechanism for which FUDGE might have  a  different
ECO #: MSCP12-2          value  is  one  that has multiple paths between nodes, and allows
ECO #: MSCP12-2          datagrams for a single connection to follow different paths.


   <<End ECO #: MSCP12-2 Error Log Sequence Numbers>> 



   <<ECO #: MSCP12-9 Reserve OPCODE Zero [approved 7 February 1984]>>


ECO #: MSCP12-9  I (Ralph Weber) would like to see the MSCP operation code zero reserved 
ECO #: MSCP12-9  with  the intent that it never be used. 

ECO #: MSCP12-9  I am  working on reducing the number of instructions in  the  VMS  disk
ECO #: MSCP12-9  class  driver  main  READ  and WRITE operation code path to improve its
ECO #: MSCP12-9  performance.  Guaranteeing  that zero is an illegal MSCP operation code
ECO #: MSCP12-9  will assist in this effort.


   <<End ECO #: MSCP12-9 Reserve OPCODE Zero >>



   <<ECO #: MSCP12-10 Revised Appendix B [approved as amended 16 March 1984]>>

ECO #: MSCP12-10    Change bars (|) denote difference from MSCP Version 1.2 Appendix B.









ECO #: MSCP12-10                               APPENDIX B

ECO #: MSCP12-10                    STATUS AND EVENT CODE DEFINITIONS




ECO #: MSCP12-10    Notes:  1. The combination of a  status  or  event  code  with  a
ECO #: MSCP12-10               sub-code should be expressed (assuming 16 bit symbols)
ECO #: MSCP12-10               as:

ECO #: MSCP12-10                    (subcode*ST.SUB)+code

ECO #: MSCP12-10 |          2. The standard sub-code values shown in  Table  B-2  are
ECO #: MSCP12-10 |             only  returned  as status codes in end messages.  They
ECO #: MSCP12-10 |             are  never  returned  as  event  codes  in  error  log
ECO #: MSCP12-10 |             messages.

ECO #: MSCP12-10 |          3. The non-standard sub-code values (Tables  B-3  through
ECO #: MSCP12-10 |             B-8)  may  be returned as either status codes or event
ECO #: MSCP12-10 |             codes or both.  In those tables, an  asterisk  in  the
ECO #: MSCP12-10               "EV"  column  indicates that the code and sub-code may
ECO #: MSCP12-10               be returned as an event code.  An asterisk in the "ST"
ECO #: MSCP12-10               column  indicates  that  the  code and sub-code may be
ECO #: MSCP12-10               returned as a status code.
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-2



ECO #: MSCP12-10                                Table B-1   Status and Event Codes

ECO #: MSCP12-10    +--------------------+--------------------------+-----------------------------------------+
ECO #: MSCP12-10    |       Value        |   Preferred Mnemonics    |                                         |
ECO #: MSCP12-10    | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Status or Event Code                |
ECO #: MSCP12-10    +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-10    |   31 |   37 |   1F | ST.MSK | MSCP$M_ST_MASK  | Status / event code mask                |
ECO #: MSCP12-10    |   32 |   40 |   20 | ST.SUB | MSCP$K_ST_SBCOD | Sub-code multiplier                     |
ECO #: MSCP12-10    |      |      |      |        |                 |                                         |
ECO #: MSCP12-10    |    0 |    0 |    0 | ST.SUC | MSCP$K_ST_SUCC  | Success                                 |
ECO #: MSCP12-10    |    1 |    1 |    1 | ST.CMD | MSCP$K_ST_ICMD  | Invalid Command                         |
ECO #: MSCP12-10    |    2 |    2 |    2 | ST.ABO | MSCP$K_ST_ABRTD | Command Aborted                         |
ECO #: MSCP12-10    |    3 |    3 |    3 | ST.OFL | MSCP$K_ST_OFFLN | Unit-Offline                            |
ECO #: MSCP12-10    |    4 |    4 |    4 | ST.AVL | MSCP$K_ST_AVLBL | Unit-Available                          |
ECO #: MSCP12-10    |    5 |    5 |    5 | ST.MFE | MSCP$K_ST_MFMTE | Media Format Error                      |
ECO #: MSCP12-10    |    6 |    6 |    6 | ST.WPR | MSCP$K_ST_WRTPR | Write Protected                         |
ECO #: MSCP12-10    |    7 |    7 |    7 | ST.CMP | MSCP$K_ST_COMP  | Compare Error                           |
ECO #: MSCP12-10    |    8 |   10 |    8 | ST.DAT | MSCP$K_ST_DATA  | Data Error                              |
ECO #: MSCP12-10    |    9 |   11 |    9 | ST.HST | MSCP$K_ST_HSTBF | Host Buffer Access Error                |
ECO #: MSCP12-10    |   10 |   12 |    A | ST.CNT | MSCP$K_ST_CNTLR | Controller Error                        |
ECO #: MSCP12-10    |   11 |   13 |    B | ST.DRV | MSCP$K_ST_DRIVE | Drive Error                             |
ECO #: MSCP12-10    |   31 |   37 |   1F | ST.DIA | MSCP$K_ST_DIAG  | Message from an internal diagnostic     |
ECO #: MSCP12-10    +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-3



ECO #: MSCP12-10                          Table B-2   Standard Status Sub-code Values   

ECO #: MSCP12-10     +------+---------------------+---------------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |                                                         |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |                 Status Sub-Code                         |
ECO #: MSCP12-10     +------+------+-------+------+---------------------------------------------------------+
ECO #: MSCP12-10     | "Success" sub-code values: |                                                         |
ECO #: MSCP12-10     |    0 |    0 |     0 |    0 | Normal                                                  |
ECO #: MSCP12-10     |    1 |   32 |    40 |   20 | Spin-down Ignored                                       |
ECO #: MSCP12-10     |    2 |   64 |   100 |   40 | Still Connected                                         |
ECO #: MSCP12-10     |    4 |  128 |   200 |   80 | Duplicate Unit Number                                   |
ECO #: MSCP12-10     |    8 |  256 |   400 |  100 | Already Online                                          |
ECO #: MSCP12-10     |   16 |  512 |  1000 |  200 | Still Online                                            |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     | "Invalid Command" sub-code values:                                                   |
ECO #: MSCP12-10     |    0 |    1 |     1 |    1 | Invalid Message Length                                  |
ECO #: MSCP12-10     | many |      |       |      | Other  "Invalid  Command"  sub-codes  values should  be |
ECO #: MSCP12-10     |      |      |       |      | referenced  as  follows  (note  that  this  is combined |
ECO #: MSCP12-10     |      |      |       |      | with the status code):                                  |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     |      |      |       |      |      offset*256.+code                                   |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     |      |      |       |      | where "offset" is the command message offset symbol for |
ECO #: MSCP12-10     |      |      |       |      | the  field  in  error  and "code" is the symbol for the |
ECO #: MSCP12-10     |      |      |       |      | "Invalid Command" status code.                          |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     | "Command Aborted" sub-code values:                                                   |
ECO #: MSCP12-10     |    0 |    2 |     2 |    2 | Sub-codes are not used.                                 |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     | "Unit-Offline" sub-code values:                                                      |
ECO #: MSCP12-10     |    0 |    3 |     3 |    3 | Unit unknown or online to another controller.           |
ECO #: MSCP12-10     |    1 |   35 |    43 |   23 | No  volume  mounted  or  drive  disabled  via  RUN/STOP |
ECO #: MSCP12-10     |      |      |       |      | switch (unit is in known substate).                     |
ECO #: MSCP12-10     |    2 |   67 |   103 |   43 | Unit is inoperative                                     |
ECO #: MSCP12-10 |   |      |      |       |      |   For  SI  drives, the  controller has marked the drive |
ECO #: MSCP12-10 |   |      |      |       |      |   inoperative  due  to  an  unrecoverable  error  in  a |
ECO #: MSCP12-10     +------+------+-------+------+------+--------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-4



ECO #: MSCP12-10                    Table B-2   Standard Status Sub-code Values (continued)   

ECO #: MSCP12-10     +------+---------------------+---------------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |                                                         |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |                 Status Sub-Code                         |
ECO #: MSCP12-10     +------+------+-------+------+---------------------------------------------------------+
ECO #: MSCP12-10     | "Unit-Offline" sub-code values (continued):                                          |
ECO #: MSCP12-10 |   |      |      |       |      |   previous  level 2  exchange, the drive's C1  flag  is |
ECO #: MSCP12-10 |   |      |      |       |      |   set, or  the  drive  has a duplicate unit identifier. |
ECO #: MSCP12-10     |    4 |  131 |   203 |   83 | Duplicate unit number                                   |
ECO #: MSCP12-10     |    8 |  259 |   403 |  103 | Unit disabled by field service or diagnostic.           |
ECO #: MSCP12-10 |   |      |      |       |      |   For SI drives, the drive's DD flag is set.            |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     | "Unit-Available" sub-code values:                                                    |
ECO #: MSCP12-10     |    0 |    4 |     4 |    4 | Sub-codes are not used.                                 |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     | "Media Format Error" sub-code values -- see Table B-3                                |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10     | "Write Protected" sub-code values:                                                   |
ECO #: MSCP12-10     |  256 | 8198 | 20006 | 2006 | Unit is Hardware Write Protected                        |
ECO #: MSCP12-10     |  128 | 4102 | 10006 | 1006 | Unit is Software Write Protected                        |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10 |   | "Compare Error" sub-code values -- see Table B-4                                     |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10 |   | "Data Error" sub-code values -- see Table B-5                                        |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10 |   | "Host Buffer Access Error" sub-code values -- see Table B-6                          |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10 |   | "Controller Error" sub-code values -- see Table B-7                                  |
ECO #: MSCP12-10     |      |      |       |      |                                                         |
ECO #: MSCP12-10 |   | "Drive Error" sub-code values -- see Table B-8                                       |
ECO #: MSCP12-10     +------+------+-------+------+---------------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-5



ECO #: MSCP12-10                        Table B-3   "Media Format Error" Sub-code Values   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   | many |     |        |      |*|*| "Data Error" accessing RCT or FCT.                  |
ECO #: MSCP12-10 |   |      For  every "Data Error"  sub-code that may be  reported as a status code (i.e., |
ECO #: MSCP12-10 |   |      for every  sub-code  listed  in  Table B-5 that  has an  asterisk in  the  "ST" |
ECO #: MSCP12-10 |   |      column), the  exact  same sub-code   value may be returned  as a "Media  Format |
ECO #: MSCP12-10 |   |      Error" sub-code value.  These  sub-codes indicate that a transfer to the unit's |
ECO #: MSCP12-10 |   |      FCT or  RCT (using the multi-copy  structure read and  write algorithms) failed |
ECO #: MSCP12-10 |   |      for the  specified reason.  The sub-code reports the error that occurred on the |
ECO #: MSCP12-10 |   |      last  copy of  the multi-copy  structure.  For  example, the  sub-code  value 7 |
ECO #: MSCP12-10 |   |      (combined code and sub-code value of 229 decimal) indicates that the FCT or RCT |
ECO #: MSCP12-10 |   |      is unreadable due to an Uncorrectable ECC Error.                                |
ECO #: MSCP12-10 |   |                                                                                      |
ECO #: MSCP12-10 |   |      In addition to  these sub-code values copied from "Data Error" sub-code values, |
ECO #: MSCP12-10 |   |      the following sub-code values also exist:                                       |
ECO #: MSCP12-10     |      |      |       |      | | |                                                     |
ECO #: MSCP12-10     |    5 |  165 |   245 |   A5 | |*| Disk isn't formatted with 512 byte sectors          |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The  disk's FCT  indicates that  it is  formatted |
ECO #: MSCP12-10 |   |      |      |       |      | | |   with 576 byte  sectors, yet either the controller |
ECO #: MSCP12-10 |   |      |      |       |      | | |   or the drive only supports 512 byte sectors.      |
ECO #: MSCP12-10     |    6 |  197 |   305 |   C5 | |*| Disk isn't formatted or FCT corrupted               |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The disk's FCT does not indicate that the disk is |
ECO #: MSCP12-10 |   |      |      |       |      | | |   formatted with either 512 or 576 byte sectors.    |
ECO #: MSCP12-10 |   |    8 |  261 |   405 |  105 |*|*| RCT corrupted.                                      |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The RCT  search algorithm  encountered an invalid |
ECO #: MSCP12-10 |   |      |      |       |      | | |   RCT  entry.  This  sub-code  may be  returned  by |
ECO #: MSCP12-10 |   |      |      |       |      | | |   replacement  (searching   the  RCT   for  a   new |
ECO #: MSCP12-10 |   |      |      |       |      | | |   replacement block), by revectoring (searching the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   RCT  to  locate the replacement  block for  a bad |
ECO #: MSCP12-10 |   |      |      |       |      | | |   block), and when a unit is brought "Unit-Online". |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-6



ECO #: MSCP12-10                  Table B-3   "Media Format Error" Sub-code Values (continued)   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |    9 |  293 |   445 |  125 |*| | No replacement block available.                     |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Replacement  was attempted for a bad block, but a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   replacement block  could not  be allocated (i.e., |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the volume's RCT is  full).  This sub-code may be |
ECO #: MSCP12-10 |   |      |      |       |      | | |   returned  both during actual replacement and when |
ECO #: MSCP12-10 |   |      |      |       |      | | |   an interrupted  replacement is  completed as part |
ECO #: MSCP12-10 |   |      |      |       |      | | |   of bringing a unit "Unit-Online".                 |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+



ECO #: MSCP12-10 |                        Table B-4   "Compare Error" Sub-code Values   

ECO #: MSCP12-10 |   +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10 |   | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10 |   +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |    0 |    7 |    7  |    7 |*|*| Subcodes  are  not  used.  Note: the  compare error |
ECO #: MSCP12-10 |   |      |      |       |      | | | code  is only used  as an event code when the error |
ECO #: MSCP12-10 |   |      |      |       |      | | | occurs   during   a read-compare  or  write-compare |
ECO #: MSCP12-10 |   |      |      |       |      | | | operation.                                          |
ECO #: MSCP12-10 |   +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-7



ECO #: MSCP12-10 |                          Table B-5   "Data Error" Sub-code Values   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     |    0 |    8 |    10 |    8 | |*| Sector was written with "Force Error" modifier      |
ECO #: MSCP12-10 |   |    2 |   72 |   110 |   48 |*|*| Invalid header.                                     |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The  subsystem read  an invalid  or  inconsistent |
ECO #: MSCP12-10 |   |      |      |       |      | | |   header for the requested sector.  For recoverable |
ECO #: MSCP12-10 |   |      |      |       |      | | |   errors,  this code  implies that  a retry  of the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   transfer read  a valid header.  For unrecoverable |
ECO #: MSCP12-10 |   |      |      |       |      | | |   errors,  this code  implies  that  the  subsystem |
ECO #: MSCP12-10 |   |      |      |       |      | | |   attempted  tertiary  revectoring  and  determined |
ECO #: MSCP12-10 |   |      |      |       |      | | |   that  the  requested  sector  is  not  revectored |
ECO #: MSCP12-10 |   |      |      |       |      | | |   (i.e.,  the RCT indicates  that the sector is not |
ECO #: MSCP12-10 |   |      |      |       |      | | |   revectored).  Causes of an invalid header include |
ECO #: MSCP12-10 |   |      |      |       |      | | |   header  mis-sync,  header   sync  timeout, and  a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   garbage (inconsistent) header.                    |
ECO #: MSCP12-10     |    3 |  104 |   150 |   68 |*|*| Data Sync not found (Data Sync timeout).            |
ECO #: MSCP12-10 |   |    4 |  136 |   210 |   88 |*| | Correctable error in ECC field.                     |
ECO #: MSCP12-10 |   |      |      |       |      | | |   A transfer  encountered  a correctable  error  in |
ECO #: MSCP12-10 |   |      |      |       |      | | |   which only  the ECC field was affected.  That is, |
ECO #: MSCP12-10 |   |      |      |       |      | | |   all  data bits  were correct  but some portion of |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the ECC field was incorrect.  The severity of the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   error (i.e., the  number of symbols  in error) is |
ECO #: MSCP12-10 |   |      |      |       |      | | |   unknown.  If the  number of  symbols in  error is |
ECO #: MSCP12-10 |   |      |      |       |      | | |   known, an "n Symbol ECC Error" sub-code should be |
ECO #: MSCP12-10 |   |      |      |       |      | | |   returned instead.                                 |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-8



ECO #: MSCP12-10 |                    Table B-5   "Data Error" Sub-code Values (continued)   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     |    7 |  232 |   350 |   E8 |*|*| Uncorrectable ECC Error.                            |
ECO #: MSCP12-10 |   |      |      |       |      | | |   A    transfer   without   the   "Suppress   Error |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Correction"  modifier  encountered  an  ECC error |
ECO #: MSCP12-10 |   |      |      |       |      | | |   that  exceeds  the  correction capability  of the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   subsystem's  error  correction  algorithms, or  a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   transfer  with  the "Suppress  Error  Correction" |
ECO #: MSCP12-10 |   |      |      |       |      | | |   modifier encountered an ECC error of any severity |
ECO #: MSCP12-10 |   |      |      |       |      | | |   whatsoever.                                       |
ECO #: MSCP12-10     |    8 |  264 |   410 |  108 |*| | One Symbol ECC Error.                               |
ECO #: MSCP12-10     |    9 |  296 |   450 |  128 |*| | Two Symbol ECC Error.                               |
ECO #: MSCP12-10     |   10 |  328 |   510 |  148 |*| | Three Symbol ECC Error.                             |
ECO #: MSCP12-10     |   11 |  360 |   550 |  168 |*| | Four Symbol ECC Error.                              |
ECO #: MSCP12-10     |   12 |  392 |   610 |  188 |*| | Five Symbol ECC Error.                              |
ECO #: MSCP12-10     |   13 |  424 |   650 |  1A8 |*| | Six Symbol ECC Error.                               |
ECO #: MSCP12-10     |   14 |  456 |   710 |  1C8 |*| | Seven Symbol ECC Error.                             |
ECO #: MSCP12-10     |   15 |  488 |   750 |  1E8 |*| | Eight Symbol ECC Error.                             |
ECO #: MSCP12-10 |   |      |      |       |      | | |   A transfer  encountered  a correctable  ECC error |
ECO #: MSCP12-10 |   |      |      |       |      | | |   with  the  specified  number  of  ECC  symbols in |
ECO #: MSCP12-10 |   |      |      |       |      | | |   error.  The  number of  symbols in  error roughly |
ECO #: MSCP12-10 |   |      |      |       |      | | |   corresponds to the severity of the error.         |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                  Page B-9



ECO #: MSCP12-10 |                   Table B-6   "Host Buffer Access Error" Sub-code Values   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |    0 |    9 |    11 |    9 | |*| Host buffer access error, cause not available.      |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The controller was unable to access a host buffer |
ECO #: MSCP12-10 |   |      |      |       |      | | |   to perform a transfer, but has no visibility into |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the cause of the error.                           |
ECO #: MSCP12-10     |    1 |   41 |    51 |   29 | |*| Odd transfer address                                |
ECO #: MSCP12-10     |    2 |   73 |   111 |   49 | |*| Odd byte count                                      |
ECO #: MSCP12-10 |   |    3 |  105 |   151 |   69 |*|*| Non-existent memory error                           |
ECO #: MSCP12-10 |   |    4 |  137 |   211 |   89 |*|*| Host memory parity error                            |
ECO #: MSCP12-10 |   |    5 |  169 |   251 |   A9 |*|*| Invalid page  table entry (See Unibus/Q-bus Storage |
ECO #: MSCP12-10 |   |      |      |       |      | | | Systems Port Specification for  additional detail.) |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                 Page B-10



ECO #: MSCP12-10 |                       Table B-7   "Controller Error" Sub-code Values   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |    0 |   10 |    12 |    A |-|-| Reserved  for host  detected command  timeout error |
ECO #: MSCP12-10 |   |      |      |       |      | | | logging.  This  subcode  is  never  reported  by  a |
ECO #: MSCP12-10 |   |      |      |       |      | | | controller.                                         |
ECO #: MSCP12-10 |   |    1 |   42 |    52 |   2A |*|*| SERDES overrun or underrun error.                   |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Either the  drive is too fast for the controller, |
ECO #: MSCP12-10 |   |      |      |       |      | | |   or (more typically) a  controller hardware  fault |
ECO #: MSCP12-10 |   |      |      |       |      | | |   has  prevented controller  microcode  from  being |
ECO #: MSCP12-10 |   |      |      |       |      | | |   able to keep up with data transfer to or from the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   drive.                                            |
ECO #: MSCP12-10     |    2 |   74 |   112 |   4A |*|*| EDC Error.                                          |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The  sector was  read with correct or correctable |
ECO #: MSCP12-10 |   |      |      |       |      | | |   ECC and an invalid  EDC.  There is most  likely a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   fault in  the ECC logic of either this controller |
ECO #: MSCP12-10 |   |      |      |       |      | | |   or the controller that last wrote the sector.     |
ECO #: MSCP12-10 |   |    3 |  106 |   152 |   6A |*|*| Inconsistent internal control structure.            |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Some  high level  check detected  an inconsistent |
ECO #: MSCP12-10 |   |      |      |       |      | | |   data  structure.  For  example, a  reserved field |
ECO #: MSCP12-10 |   |      |      |       |      | | |   contained  a non-zero  value  or the  value  in a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   field  was outside  its valid  range.  This error |
ECO #: MSCP12-10 |   |      |      |       |      | | |   almost   always  implies   the  existence  of   a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   microcode bug.                                    |
ECO #: MSCP12-10 |   |    4 |  138 |   212 |   8A |*|*| Internal EDC error.                                 |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Some  low  level  check detected an  inconsistent |
ECO #: MSCP12-10 |   |      |      |       |      | | |   data    structure.  For   example,  a   microcode |
ECO #: MSCP12-10 |   |      |      |       |      | | |   implemented checksum or vertical parity (hardware |
ECO #: MSCP12-10 |   |      |      |       |      | | |   parity  is  horizontal)  associated with internal |
ECO #: MSCP12-10 |   |      |      |       |      | | |   sector data was inconsistent.  This error usually |
ECO #: MSCP12-10 |   |      |      |       |      | | |   implies a fault in the memory addressing logic of |
ECO #: MSCP12-10 |   |      |      |       |      | | |   one  or  more  of  the   controller's  processing |
ECO #: MSCP12-10 |   |      |      |       |      | | |   elements.  It  may also  result from a double bit |
ECO #: MSCP12-10 |   |      |      |       |      | | |   error   or  other  error  that  exceeds the error |
ECO #: MSCP12-10 |   |      |      |       |      | | |   detection capability of the controller's hardware |
ECO #: MSCP12-10 |   |      |      |       |      | | |   memory checking circuitry.                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                 Page B-11



ECO #: MSCP12-10 |                 Table B-7   "Controller Error" Sub-code Values (continued)   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |    5 |  170 |   252 |   AA |*|*| LESI Adaptor Card parity error on input (adaptor to |
ECO #: MSCP12-10 |   |      |      |       |      | | | controller).                                        |
ECO #: MSCP12-10 |   |    6 |  202 |   312 |   CA |*|*| LESI   Adaptor   Card    parity   error  on  output |
ECO #: MSCP12-10 |   |      |      |       |      | | | (controller to adaptor).                            |
ECO #: MSCP12-10 |   |    7 |  234 |   352 |   EA |*|*| LESI Adaptor Card "cable in place" not asserted.    |
ECO #: MSCP12-10 |   |    8 |  266 |   412 |  10A |*|*| Controller overrun or underrun.                     |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The   controller  attempted  to  perform too many |
ECO #: MSCP12-10 |   |      |      |       |      | | |   concurrent transfers, causing one or more of them |
ECO #: MSCP12-10 |   |      |      |       |      | | |   to fail due to a data overrun or underrun.        |
ECO #: MSCP12-10 |   |    9 |  298 |   452 |  12A |*|*| Controller memory error.                            |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The controller  detected an  error in an internal |
ECO #: MSCP12-10 |   |      |      |       |      | | |   memory, such  as a parity error or non-responding |
ECO #: MSCP12-10 |   |      |      |       |      | | |   address.  This  sub-code  only applies  to errors |
ECO #: MSCP12-10 |   |      |      |       |      | | |   that  do not  affect the controller's  ability to |
ECO #: MSCP12-10 |   |      |      |       |      | | |   properly  generate end and error log messages, as |
ECO #: MSCP12-10 |   |      |      |       |      | | |   errors  that  might  affect  end  and  error  log |
ECO #: MSCP12-10 |   |      |      |       |      | | |   messages  are not  reported via MSCP.  Therefore, |
ECO #: MSCP12-10 |   |      |      |       |      | | |   for most  controllers this  sub-code will only be |
ECO #: MSCP12-10 |   |      |      |       |      | | |   returned for controller  memory errors in data or |
ECO #: MSCP12-10 |   |      |      |       |      | | |   buffer    memory     and   non-critical   control |
ECO #: MSCP12-10 |   |      |      |       |      | | |   structures.  If the  controller  has several such |
ECO #: MSCP12-10 |   |      |      |       |      | | |   memories,  the   specific   memory   involved  is |
ECO #: MSCP12-10 |   |      |      |       |      | | |   reported   as   part  of the error address in the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   error log message.                                |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                 Page B-12



ECO #: MSCP12-10 |                         Table B-8   "Drive Error" Sub-code Values   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |    1 |   43 |    53 |   2B |*|*| Drive command time out.                             |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI drives, the  controller's timeout expired |
ECO #: MSCP12-10 |   |      |      |       |      | | |   for either a level 2 exchange or the assertion of |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Read/Write Ready after an Initiate Seek.          |
ECO #: MSCP12-10 |   |    2 |   75 |   113 |   4B |*|*| Controller detected transmission error.             |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For SI drives, the controller detected an invalid |
ECO #: MSCP12-10 |   |      |      |       |      | | |   framing  code  or a  checksum  error in a level 2 |
ECO #: MSCP12-10 |   |      |      |       |      | | |   response  from  the  drive.  The UDA50  and UDA52 |
ECO #: MSCP12-10 |   |      |      |       |      | | |   also return this sub-code for controller detected |
ECO #: MSCP12-10 |   |      |      |       |      | | |   protocol errors.  All other SI controllers return |
ECO #: MSCP12-10 |   |      |      |       |      | | |   sub-code 9 for protocol errors.                   |
ECO #: MSCP12-10     |    3 |  107 |   153 |   6B |*|*| Positioner error (mis-seek).                        |
ECO #: MSCP12-10 |   |      |      |       |      | | |   The  drive  reported  that  a  seek operation was |
ECO #: MSCP12-10 |   |      |      |       |      | | |   successful, but  the  controller  determined that |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the drive  had  positioned itself to an incorrect |
ECO #: MSCP12-10 |   |      |      |       |      | | |   cylinder.                                         |
ECO #: MSCP12-10     |    4 |  139 |   213 |   8B |*|*| Lost read/write ready during or between transfers.  |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI drives, Read/Write ready was negated when |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the  controller  attempted to initiate a transfer |
ECO #: MSCP12-10 |   |      |      |       |      | | |   or  at  the    completion   of  a  transfer,  and |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Read/Write  ready  had  previously  been asserted |
ECO #: MSCP12-10 |   |      |      |       |      | | |   (indicating  completion  of the preceeding seek). |
ECO #: MSCP12-10 |   |      |      |       |      | | |   This  usually  results   from  a  drive  detected |
ECO #: MSCP12-10 |   |      |      |       |      | | |   transfer error, in which case an additional error |
ECO #: MSCP12-10 |   |      |      |       |      | | |   log  message  may  be  generated  containing  the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   "Drive detected error" sub-code.                  |
ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                 Page B-13



ECO #: MSCP12-10 |                   Table B-8   "Drive Error" Sub-code Values (continued)   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     |    5 |  171 |   253 |   AB |*|*| Drive clock dropout.                                |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI  drives, either  data  or state clock was |
ECO #: MSCP12-10 |   |      |      |       |      | | |   missing  when  it should have been present.  This |
ECO #: MSCP12-10 |   |      |      |       |      | | |   is usually detected by means of a timeout.        |
ECO #: MSCP12-10 |   |    6 |  203 |   313 |   CB |*|*| Lost receiver ready for transfer.                   |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI  drives, Receiver Ready  was negated when |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the controller  attempted to  initiate a transfer |
ECO #: MSCP12-10 |   |      |      |       |      | | |   or  did   not  assert  at  the  completion  of  a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   transfer.  This  includes   all   cases  of   the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   controller's  timeout  expiring  for  a  transfer |
ECO #: MSCP12-10 |   |      |      |       |      | | |   operation (level 1 real time command).            |
ECO #: MSCP12-10     |    7 |  235 |   353 |   EB |*|*| Drive detected error.                               |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI  drives, the  controller  received  a Get |
ECO #: MSCP12-10 |   |      |      |       |      | | |   Status  or Unsuccessful response with the EL flag |
ECO #: MSCP12-10 |   |      |      |       |      | | |   set,  or  the controller received such a response |
ECO #: MSCP12-10 |   |      |      |       |      | | |   with  the  DR  flag  set  and it does not support |
ECO #: MSCP12-10 |   |      |      |       |      | | |   automatic diagnosis for that drive type.          |
ECO #: MSCP12-10     |    8 |  267 |   413 |  10B |*|*| Controller detected pulse or state parity error.    |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI drives, the  controller detected  a pulse |
ECO #: MSCP12-10 |   |      |      |       |      | | |   error  on  either  the  state or data line or the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   controller  detected  a  parity  error in a state |
ECO #: MSCP12-10 |   |      |      |       |      | | |   frame.                                            |
ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10    Status and Event Code Definitions                                                 Page B-14



ECO #: MSCP12-10 |                   Table B-8   "Drive Error" Sub-code Values (continued)   

ECO #: MSCP12-10     +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10     | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-10     | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-10 |   |   10 |  331 |   513 |  14B |*|*| Controller detected protocol error.                 |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI drives, a level 2 response from the drive |
ECO #: MSCP12-10 |   |      |      |       |      | | |   had  correct  framing codes and checksum, but was |
ECO #: MSCP12-10 |   |      |      |       |      | | |   not  a  valid  response within the constraints of |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the  SI  protocol.  That  is, the response had an |
ECO #: MSCP12-10 |   |      |      |       |      | | |   invalid  opcode, was  an  improper length, or was |
ECO #: MSCP12-10 |   |      |      |       |      | | |   not  a  possible  response  in the context of the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   exchange.                                         |
ECO #: MSCP12-10 |   |   11 |  363 |   553 |  16B |*|*| Drive failed initialization.                        |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI  drives, the  drive  clock did not resume |
ECO #: MSCP12-10 |   |      |      |       |      | | |   following  a controller attempt to initialize the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   drive.  This implies that the drive encountered a |
ECO #: MSCP12-10 |   |      |      |       |      | | |   fatal initialization error.                       |
ECO #: MSCP12-10 |   |   12 |  395 |   613 |  18B |*|*| Drive ignored initialization.                       |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For  SI  drives, the  drive  clock  did not cease |
ECO #: MSCP12-10 |   |      |      |       |      | | |   following  a controller attempt to initialize the |
ECO #: MSCP12-10 |   |      |      |       |      | | |   drive.  This  implies  that  the  drive  did  not |
ECO #: MSCP12-10 |   |      |      |       |      | | |   recognize the initialization attempt.             |
ECO #: MSCP12-10 |   |   13 |  427 |   653 |  1AB |*|*| Receiver Ready collision.                           |
ECO #: MSCP12-10 |   |      |      |       |      | | |   For SI drives, the controller attempted to assert |
ECO #: MSCP12-10 |   |      |      |       |      | | |   it's Receiver  Ready (to  receive a response) and |
ECO #: MSCP12-10 |   |      |      |       |      | | |   the drive's Receiver Ready was still asserted (to |
ECO #: MSCP12-10 |   |      |      |       |      | | |   receive a command).                               |
ECO #: MSCP12-10     +------+------+-------+------+-+-+-----------------------------------------------------+

   <<End ECO #: MSCP12-10 Revised Appendix B>>



   <<ECO #:  MSCP12-11 Revised Appendix C [approved 16 March 1984]>>

ECO #:  MSCP12-11    Differences from the original MSCP V1.2 Appendix C text are denoted by
ECO #:  MSCP12-11    the | character; additions are denoted by the # character.

ECO #:  MSCP12-11    Proposals:

ECO #:  MSCP12-11          o  Modify Table C-2 Mass  Storage  Controller  Model  Values  as
ECO #:  MSCP12-11             shown  below  to;  correctly  identify  the  RC25  and UDA50A
ECO #:  MSCP12-11             controllers; and, add the TOPS 10/20  software  MSCP  server,
ECO #:  MSCP12-11             TK50  (MAYA) controller, RUX50 (Unibus RX50) controller, RC26
ECO #:  MSCP12-11             (AZTEC II) controller, AIO controller,  QDA  controller,  BDA
ECO #:  MSCP12-11             controller, BSA controller, and CDR50 controller.

ECO #:  MSCP12-11                    +----------+------------------------------------+
ECO #:  MSCP12-11                    |Model Byte|                                    |
ECO #:  MSCP12-11                    | (decimal)|    Controller Type                 |
ECO #:  MSCP12-11                    +----------+------------------------------------+
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11 |                  |    3     | RC25                               |
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11                                            .
                   
ECO #:  MSCP12-11 |                  |    6     | UDA50A                             |
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11 #                  |    8     | TOPS 10/20 (software MSCP server)  |
ECO #:  MSCP12-11 #                  |    9     | TK50                               |
ECO #:  MSCP12-11 #                  |   10     | RUX50                              |
ECO #:  MSCP12-11 #                  |   11     | RC26                               |
ECO #:  MSCP12-11 #                  |   12     | AIO                                |
ECO #:  MSCP12-11 #                  |   13     | QDA                                |
ECO #:  MSCP12-11 #                  |   14     | BDA                                |
ECO #:  MSCP12-11 #                  |   15     | BSA                                |
ECO #:  MSCP12-11 #                  |   16     | CDR50                              |
ECO #:  MSCP12-11                                            .

ECO #:  MSCP12-11          o  Modify Table C-3 DEC Standard 166 Disk Identifier  Values  as
ECO #:  MSCP12-11             shown below to; correctly identify the RC25 and RCF25 drives;
ECO #:  MSCP12-11             and, add RD52, RD53, RD26, RA82, RC26, RCF26, and CDR50  disk
ECO #:  MSCP12-11             drives.

ECO #:  MSCP12-11    +-------+-------+------+----------------------------+--------------------------
ECO #:  MSCP12-11    | Model |Device |      |                            |
ECO #:  MSCP12-11    | Byte  |Type   |Media |    Media Type Identifier   |
ECO #:  MSCP12-11    | (dec.)|Name   |Name  |     octal      |    hex    |   Device
ECO #:  MSCP12-11    +-------+-------+------+----------------+-----------+--------------------------
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11 |  |    2  | DA    | RC25 | 020144,030031  | 2064,3019 | 26 MB removable disk drive
ECO #:  MSCP12-11 |  |    3  | DA    | RCF25| 020144,031431  | 2064,3319 | 26 MB fixed disk drive
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11 #  |    8  | DU    | RD52 | 022544,040064  | 2564,4034 | 25-27 MB fixed disk drive
ECO #:  MSCP12-11 #  |    9  | DU    | RD53 | 022544,040065  | 2564,4035 | 50-70 MB fixed disk drive
ECO #:  MSCP12-11                                                          		    Page 2


ECO #:  MSCP12-11 #  |   10  | DU    | RD26 | 022544,040032  | 2564,401A | 5 MB fixed disk drive  
ECO #:  MSCP12-11 #  |   11  | DU    | RA82 | 022544,010122  | 2564,1052 | 792 MB fixed disk drive
ECO #:  MSCP12-11 #  |   12  | DA    | RC26 | 020144,030032  | 2064,301A | 52 MB removable disk drive
ECO #:  MSCP12-11 #  |   13  | DA    | RCF26| 020144,031432  | 2064,331A | 52 MB fixed disk drive
ECO #:  MSCP12-11 #  |   14  | DU    | CDR50| 022506,044462  | 2546,4932 | 500 MB DAD (optical) format, removable disk drive
ECO #:  MSCP12-11                                            .

ECO #:  MSCP12-11          o  Modify Table C-4 Tape Identifier Values as  shown  below  to:
ECO #:  MSCP12-11             change  MF-TU78  to  MU-TA78;  and,  add  TK50  and TA81 tape
ECO #:  MSCP12-11             drives.

ECO #:  MSCP12-11    +-------+-------+------+----------------------------+--------------------------
ECO #:  MSCP12-11    | Model |Device |      |                            |
ECO #:  MSCP12-11    | Byte  |Type   |Media |    Media Type Identifier   |
ECO #:  MSCP12-11    | (dec.)|Name   |Name  |     octal      |    hex    |   Device
ECO #:  MSCP12-11    +-------+-------+------+----------------+-----------+--------------------------
ECO #:  MSCP12-11 |  |   1   | MU    | TA78 | 066550,010116  | 6D68,104E | PE/GCR, 125 ips start/stop
ECO #:  MSCP12-11                                            .
ECO #:  MSCP12-11 #  |   3   | MU    | TK50 | 066550,130062  | 6D68,B032 | 100 MB Cartridge drive
ECO #:  MSCP12-11 #  |   4   | MU    | TA81 | 066550,010121  | 6D68,1051 | STI version of the TU81
ECO #:  MSCP12-11                                            .

ECO #:  MSCP12-11    Justification:

ECO #:  MSCP12-11    Products which exist or  are  currently  planned  should  be  properly
ECO #:  MSCP12-11    identified.

ECO #:  MSCP12-11    Impact:

ECO #:  MSCP12-11    Host software must be modified to recognize  the  new  identifiers  as
ECO #:  MSCP12-11    required.

ECO #:  MSCP12-11    Minimal impact on TK50 development, controller model changed from 8 to
ECO #:  MSCP12-11    9.  Moderate impact on TA78 development, drive identifier changed from
ECO #:  MSCP12-11    MF-TU78 to MU-TA78.


   <<End ECO #:  MSCP12-11 Revised Appendix C>>



   <<ECO #: MSCP12-12 RCT Access Byte Count Clarification [approved 16 March 1984]>> 

ECO #: MSCP12-12    Differences  from  the  original  MSCP V1.2  text are denoted by the | 
ECO #: MSCP12-12    character.

ECO #: MSCP12-12    Proposal:

ECO #: MSCP12-12    Modify MSCP V1.2, Section  5.3,  "byte  count"  field  description  to
ECO #: MSCP12-12    include  the  specific  action  a controller should take if a transfer
ECO #: MSCP12-12    command with an LBN within the RCT also contains a  byte  count  which
ECO #: MSCP12-12    would  cause  the  transfer  to continue beyond the extent of the RCT.
ECO #: MSCP12-12    The change required to the current description is indicated by  change
ECO #: MSCP12-12    bars below.

ECO #: MSCP12-12            If the "logical block number" field  identifies
ECO #: MSCP12-12            a   logical   block   in   the   disk  volume's
ECO #: MSCP12-12            Replacement and Caching Table (RCT) (i.e.,  the
ECO #: MSCP12-12            "logical block number" is greater than or equal
ECO #: MSCP12-12            to the "unit size" returned in the  ONLINE  and
ECO #: MSCP12-12            SET  UNIT  CHARACTERISTICS  end messages), then
ECO #: MSCP12-12            the "byte count" must be exactly the block size
ECO #: MSCP12-12 |          (either  512  or  576  bytes).   If a different
ECO #: MSCP12-12 |          "byte count" value is provided, the  controller
ECO #: MSCP12-12 |          may   either  attempt  the  transfer  with  the
ECO #: MSCP12-12 |          specified  "byte  count"  or  else  reject  the
ECO #: MSCP12-12 |          command  with  an "Invalid Command" status code
ECO #: MSCP12-12 |          and an "Invalid Byte Count" sub-code.   If  the
ECO #: MSCP12-12 |          controller attempts the transfer, and the "byte
ECO #: MSCP12-12 |          count" causes the transfer to extend past  some
ECO #: MSCP12-12 |          boundary  within  the  RCT, then the controller
ECO #: MSCP12-12 |          performs the transfer up to that  boundary  and
ECO #: MSCP12-12 |          returns an "Invalid Command" status code and an
ECO #: MSCP12-12 |          "Invalid Byte Count" sub-code.  The location of
ECO #: MSCP12-12 |          the   boundary   or  boundaries  at  which  the
ECO #: MSCP12-12 |          controller   terminates   the   transfer    are
ECO #: MSCP12-12 |          controller dependent.

ECO #: MSCP12-12    Justification:

ECO #: MSCP12-12    In order to provide  consistancy  of  operation  across  the  DSA
ECO #: MSCP12-12    product   set  the  specification  should  define  the  operation
ECO #: MSCP12-12    expected when the condition described above is encountered.
ECO #: MSCP12-12                                                               Page 2

ECO #: MSCP12-12    Impact:

ECO #: MSCP12-12    Implementation of this proposal should have no adverse effect  on
ECO #: MSCP12-12    existing host class driver software.

ECO #: MSCP12-12    The following existing controllers may not implement the proposed
ECO #: MSCP12-12    functionality:

ECO #: MSCP12-12         1.  HSC50
ECO #: MSCP12-12         2.  RC25 (Note: RC25 complies according to Fred Zayas)
ECO #: MSCP12-12         3.  RQDX1
ECO #: MSCP12-12         4.  UDA50
ECO #: MSCP12-12         5.  UDA50A


ECO #: MSCP12-12    The  impact  of  existing  implementations  is   not   considered
ECO #: MSCP12-12    significant enough to require a retrofit of the installed base or
ECO #: MSCP12-12    stop shipment of any product which is shipping  or  about  to  be
ECO #: MSCP12-12    shipped.   Waivers  of  operation should therefore be granted for
ECO #: MSCP12-12    the existing products which do not conform.  All deviations  from
ECO #: MSCP12-12    the  proposed  operation  must  be  identified and listed in MSCP
ECO #: MSCP12-12    Chapter 9.

ECO #: MSCP12-12    The proposed operation must be incorporated into the  next  major
ECO #: MSCP12-12    release  (ECO  upgrade)  of  the existing products and all future
ECO #: MSCP12-12    products.



   <<End ECO #: MSCP12-12 RCT Access Byte Count Clarification>> 



   <<ECO #: MSCP12-16 Error Log Format Generalization [approved 29 June 1984]>>

ECO #: MSCP12-16    Proposal:

ECO #: MSCP12-16    Modify section 8.4 and Table A-8 of  MSCP  V1.2,  expanding  the  Host
ECO #: MSCP12-16    Memory  Access  Error  Log  format to allow reporting of both host and
ECO #: MSCP12-16    controller  memory  access  errors  and  include  a  device  dependent
ECO #: MSCP12-16    information  area.   The changes required are indicated by change bars
ECO #: MSCP12-16    below.

ECO #: MSCP12-16    --------------------------------------------------------------------
ECO #: MSCP12-16    ***** Section 8.4 Changes *****
ECO #: MSCP12-16    --------------------------------------------------------------------


ECO #: MSCP12-16 |  8.4 Memory Errors


ECO #: MSCP12-16 |  The following error log message format is used to report memory errors
ECO #: MSCP12-16 |  when  the  address  of  the  offending  location  is  available to the
ECO #: MSCP12-16 |  controller.   This  format  is  used  for  either  host  or   internal
ECO #: MSCP12-16 |  controller memory access errors.  The format is:


ECO #: MSCP12-16                      31                             0 
ECO #: MSCP12-16                      +-------------------------------+
ECO #: MSCP12-16                      |   command reference number    |
ECO #: MSCP12-16                      +---------------+---------------+
ECO #: MSCP12-16                      |sequence number|    reserved   |
ECO #: MSCP12-16                      +---------------+-------+-------+
ECO #: MSCP12-16                      |  event code   | flags | format|
ECO #: MSCP12-16                      +---------------+-------+-------+
ECO #: MSCP12-16                      |                               |
ECO #: MSCP12-16                      +---  controller identifier  ---+
ECO #: MSCP12-16                      |                               |
ECO #: MSCP12-16                      +---------------+-------+-------+
ECO #: MSCP12-16                      |   reserved    |chvrsn | csvrsn|
ECO #: MSCP12-16                      +---------------+-------+-------+
ECO #: MSCP12-16 |                    |        memory address         |
ECO #: MSCP12-16 |                    +-------------------------------+
ECO #: MSCP12-16 |                    |                               |
ECO #: MSCP12-16 |                    /          controller           /
ECO #: MSCP12-16 |                    /          dependent            /
ECO #: MSCP12-16 |                    /          information          /
ECO #: MSCP12-16 |                    /          (optional)           /
ECO #: MSCP12-16 |                    |                               |
ECO #: MSCP12-16 |                    +-------------------------------+
ECO #: MSCP12-16                                                               Page 2

ECO #: MSCP12-16 |  event code

ECO #: MSCP12-16 |      The event code identifies whether the error being reported occured
ECO #: MSCP12-16 |      in host or controller memory.  For errors in host memory the event
ECO #: MSCP12-16 |      code contains an appropriate "Host Buffer Access Error"  sub-code.
ECO #: MSCP12-16 |      For  errors  in  controller  memory  the  event  code  contains an
ECO #: MSCP12-16 |      appropriate "Controller Error" sub-code.

ECO #: MSCP12-16 |  memory address (host memory access error)

ECO #: MSCP12-16 |      For errors  accessing  host  memory  the  "memory  address"  field
ECO #: MSCP12-16 |      contains the address in the host's physical address space at which
ECO #: MSCP12-16 |      the error occurred.

ECO #: MSCP12-16 |      The units of "memory address" are those natural  to  the  host  --
ECO #: MSCP12-16 |      bytes  for 16 and 32 bit systems or words for 36 bit systems.  The
ECO #: MSCP12-16 |      resolution to which a controller identifies the address  at  which
ECO #: MSCP12-16 |      the  error occurred is controller dependent, and must be described
ECO #: MSCP12-16 |      in the controller's Functional  Specification.   Disk  controllers
ECO #: MSCP12-16 |      will typically provide a resolution of one disk block.

ECO #: MSCP12-16 |  memory address (controller memory access error)

ECO #: MSCP12-16 |      For errors accessing controller memory the "memory address"  field
ECO #: MSCP12-16 |      contains  the  location  in  the  controller's memory at which the
ECO #: MSCP12-16 |      error occurred.

ECO #: MSCP12-16 |      Only errors  that  do  not  affect  the  controller's  ability  to
ECO #: MSCP12-16 |      properly generate end and error log messages are reported via MSCP
ECO #: MSCP12-16 |      and this error log format.  Errors that might affect end and error
ECO #: MSCP12-16 |      log messages are reported via some mechanism other than MSCP.

ECO #: MSCP12-16 |      The units of "memory address" are those natural to the  memory  in
ECO #: MSCP12-16 |      which the error occurred.  This necessarily implies that the units
ECO #: MSCP12-16 |      are memory dependent.  Bytes  are  the  preferred  units  whenever
ECO #: MSCP12-16 |      there  is  any  ambiguity  as  to what are the natural units.  The
ECO #: MSCP12-16 |      resolution to which the address of the error is reported  is  also
ECO #: MSCP12-16 |      memory  dependent.   It is acceptable for some memories to have no
ECO #: MSCP12-16 |      address resolution.  That is, errors in such memories are reported
ECO #: MSCP12-16 |      with  a  fixed  address of zero regardless of the address at which
ECO #: MSCP12-16 |      the error occurred.  This will typically be used for  memories  in
ECO #: MSCP12-16 |      which any error renders the entire memory unusable.

ECO #: MSCP12-16 |      Controllers with multiple memories  may  identify  the  particular
ECO #: MSCP12-16 |      memory  in  which  the  error  occurred  either  by  imbedding the
ECO #: MSCP12-16 |      identification (as a sub field) in the "memory address"  field  or
ECO #: MSCP12-16 |      by  providing  the  identification  in  the  "controller dependent
ECO #: MSCP12-16 |      information" field (described below).
ECO #: MSCP12-16 |      The units of "memory  address",  address  resolution,  and  memory
ECO #: MSCP12-16 |      identification  (where required) are controller dependent and must
ECO #: MSCP12-16 |      be described in the controller's Functional Specification.
ECO #: MSCP12-16                                                                    Page 3


ECO #: MSCP12-16 |  controller dependent information

ECO #: MSCP12-16 |      An optional, variable length field containing controller dependent
ECO #: MSCP12-16 |      information.   The  length  of  this field is implied by the total
ECO #: MSCP12-16 |      length of the error log message, passed to the class driver by the
ECO #: MSCP12-16 |      port  driver.   This  field  may  be  used  to  provide additional
ECO #: MSCP12-16 |      information when reporting either controller or host memory errors
ECO #: MSCP12-16 |      or   both.   The  use  and  contents  must  be  described  in  the
ECO #: MSCP12-16 |      controller's Functional Specification.

ECO #: MSCP12-16    --------------------------------------------------------------------
ECO #: MSCP12-16    ***** End Section 8.4 Changes *****
ECO #: MSCP12-16    --------------------------------------------------------------------
ECO #: MSCP12-16    --------------------------------------------------------------------
ECO #: MSCP12-16    ***** Table A-8 Changes *****
ECO #: MSCP12-16    --------------------------------------------------------------------

ECO #: MSCP12-16                               Table A-8   Error Log Message Offsets

ECO #: MSCP12-16    +--------------------+--------------------------+-------+---------------------------------+
ECO #: MSCP12-16    |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
ECO #: MSCP12-16    | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
ECO #: MSCP12-16    +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-16                                                 .
ECO #: MSCP12-16                                                 .
ECO #: MSCP12-16                                                 .
ECO #: MSCP12-16 |  | Host Memory Errors with Bus Address Error Log Message Offsets:                          |
ECO #: MSCP12-16 |  |  24  |  30  |  18  | L.BADR | MSLG$L_BUS_ADDR |   4   | Host bus memory address         |
ECO #: MSCP12-16 |  |  28  |  34  |  1C  |        |                 |   *   | Controller dependent information|
ECO #: MSCP12-16 |  |      |      |      |        |                 |       | (optional)                      |
ECO #: MSCP12-16 |  |      |      |      |        |                 |       |                                 |
ECO #: MSCP12-16 |  | Controller Memory Errors with Memory Address Error Log Message Offsets:                 |
ECO #: MSCP12-16 |  |  24  |  30  |  18  | L.BADR | MSLG$L_BUS_ADDR |   4   | Controller memory address       |
ECO #: MSCP12-16 |  |  28  |  34  |  1C  |        |                 |   *   | Controller dependent information|
ECO #: MSCP12-16 |  |      |      |      |        |                 |       | (optional)                      |
ECO #: MSCP12-16                                                 .
ECO #: MSCP12-16                                                 .
ECO #: MSCP12-16                                                 .
ECO #: MSCP12-16    +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-16 |  | Note: An asterisk (*) in the field size indicates that the size varies.                 |
ECO #: MSCP12-16 |  +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-16    --------------------------------------------------------------------
ECO #: MSCP12-16    ***** End Table A-8 Changes *****
ECO #: MSCP12-16    --------------------------------------------------------------------

ECO #: MSCP12-16    Justification:

ECO #: MSCP12-16    Allow devices to report both host and controller memory access  errors
ECO #: MSCP12-16    via  a  common  format  and  also  provide  additional device specific
ECO #: MSCP12-16    information as an aid in error diagnosis.

ECO #: MSCP12-16    Impact:

ECO #: MSCP12-16    Implementation of this proposal  should  have  no  adverse  effect  on
ECO #: MSCP12-16    existing software or hardware.


   <<End ECO #: MSCP12-16 Error Log Format Generalization>>

   <<ECO #: MSCP12-17 Expeditious Abort [approved as amended 29 June 1984]>>

ECO #: MSCP12-17    Proposal:

ECO #: MSCP12-17    Modify section 4.5 Command Categories and  Execution  Order  to  allow
ECO #: MSCP12-17    aborted command end messages to be returned out of order regardless of
ECO #: MSCP12-17    the aborted command's command category.  The change affects  only  one
ECO #: MSCP12-17    paragraph  of section 4.5, namely the paragraph beginning on Page 4-17
ECO #: MSCP12-17    Line 50 of the existing specification.  The change is shown by  change
ECO #: MSCP12-17    bars below.

ECO #: MSCP12-17    ---------------------------------------------------------------------------
ECO #: MSCP12-17    ***** Section 4.5 Change
ECO #: MSCP12-17    ---------------------------------------------------------------------------
ECO #: MSCP12-17       An aborted command is a command that the class  driver  has  asked  to
ECO #: MSCP12-17       have  aborted  via  an  ABORT  command,  and that furthermore has been
ECO #: MSCP12-17       located and explicitly aborted by the MSCP server.  That is,  commands
ECO #: MSCP12-17       that  the  MSCP  server  just  allows  to  complete are completed, not
ECO #: MSCP12-17       aborted.   An  aborted  command  is  effectively  either  rejected  or
ECO #: MSCP12-17       terminated,  depending  upon  whether  or  not  the  server  has begun
ECO #: MSCP12-17       execution  of  the  command  when  it  processes  the  ABORT.    (This
ECO #: MSCP12-17       definition  of  an  aborted  command  is from the viewpoint of an MSCP
ECO #: MSCP12-17       server.  From the viewpoint of a class driver, an aborted  command  is
ECO #: MSCP12-17    |  any  command  for  which  an  ABORT  command has been issued.) The end
ECO #: MSCP12-17    |  message of an aborted  command must be returned  within one controller
ECO #: MSCP12-17    |  timeout  interval  following  rejection  or termination of the command
ECO #: MSCP12-17    |  regardless of the aborted command's command category.
ECO #: MSCP12-17    ---------------------------------------------------------------------------
ECO #: MSCP12-17    ***** End Section 4.5 Change
ECO #: MSCP12-17    ---------------------------------------------------------------------------

ECO #: MSCP12-17    Justification:

ECO #: MSCP12-17    Ensure the end message for  an  aborted  command  is  returned  in  an
ECO #: MSCP12-17    expeditious manner.

ECO #: MSCP12-17    Impact:

ECO #: MSCP12-17    Implementation of this proposal  should  have  no  adverse  effect  on
ECO #: MSCP12-17    existing software or hardware.

   <<End ECO #: MSCP12-17 Expeditious Abort>>


   <<ECO #: MSCP12-18 Revised Appendix B for BI [approved 29 June 1984]>>

ECO #: MSCP12-18    Proposed Change
ECO #: MSCP12-18    ---------------

ECO #: MSCP12-18    Table B-6 in MSCP Appendix B, as defined in ECO MSCP12-10, defines  host
ECO #: MSCP12-18    buffer  access  errors  as  seen  by controllers implementing the UQSSP.
ECO #: MSCP12-18    This proposal would extend the table with three new  subcodes,  each  of
ECO #: MSCP12-18    which describes a host buffer access error that can occur over the BISSP
ECO #: MSCP12-18    (BI Storage Systems Port), or over any port that implements the Vax Port
ECO #: MSCP12-18    Architecture.

ECO #: MSCP12-18    The three new error subcodes requested are:

ECO #: MSCP12-18         1.  INVALID BUFFER NAME.  The key in the buffer name does not match
ECO #: MSCP12-18             the  key  in  the  buffer  descriptor,  the V bit in the buffer
ECO #: MSCP12-18             descriptor is clear, or the index into  the  Buffer  Descriptor
ECO #: MSCP12-18             Table  is  too  large.  See the BI Storage Systems Port (BISSP)
ECO #: MSCP12-18             for more information.

ECO #: MSCP12-18         2.  BUFFER LENGTH VIOLATION.  The number of bytes requested in  the
ECO #: MSCP12-18             MSCP  command  exceeds  the  buffer  length as specified in the
ECO #: MSCP12-18             buffer desriptor.  See the BI Storage Systems Port (BISSP)  for
ECO #: MSCP12-18             more information.

ECO #: MSCP12-18         3.  ACCESS CONTROL VIOLATION.  The access  mode  specified  in  the
ECO #: MSCP12-18             buffer descriptor is protected against by the PROT field in the
ECO #: MSCP12-18             PTE.   See  the  BI  Storage  Systems  Port  (BISSP)  for  more
ECO #: MSCP12-18             information.

ECO #: MSCP12-18    These codes can be assigned any values you see fit.

ECO #: MSCP12-18    Justification
ECO #: MSCP12-18    -------------

ECO #: MSCP12-18    These errors are not adequately described by the existing  error  codes.
ECO #: MSCP12-18    The  distinction  between  this errors is visible to the controller, and
ECO #: MSCP12-18    should be passed back to the class driver.  The  alternative  to  adding
ECO #: MSCP12-18    new error codes is to group all these errors into the "Undetermined Host
ECO #: MSCP12-18    Buffer Access Error" subcode, which is unsatisfactory because  it  loses
ECO #: MSCP12-18    useful information.
ECO #: MSCP12-18                                                               Page 2


ECO #: MSCP12-18                       ADDENDUM (by Jim Zahrobsky)

ECO #: MSCP12-18            The changes required to Table B-6  are  shown  by
ECO #: MSCP12-18            change bars below.

ECO #: MSCP12-18                              Table B-6   "Host Buffer Access Error" Sub-code Values   

ECO #: MSCP12-18               +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-18               | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-18               | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-18               +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-18                                                          .
ECO #: MSCP12-18                                                          .
ECO #: MSCP12-18                                                          .
ECO #: MSCP12-18 |             |    6 |  201 |   311 |   C9 |*|*| Invalid buffer name                                 |
ECO #: MSCP12-18 |             |      |      |       |      | | |   The key in the buffer name does not match the key |
ECO #: MSCP12-18 |             |      |      |       |      | | |   in the buffer descriptor, the V bit in the buffer |
ECO #: MSCP12-18 |             |      |      |       |      | | |   descriptor is clear, or the index into the Buffer |
ECO #: MSCP12-18 |             |      |      |       |      | | |   Descriptor  Table  is  too  large.  (See  the  BI |
ECO #: MSCP12-18 |             |      |      |       |      | | |   Storage   Systems  Port  (BISSP)  for  additional |
ECO #: MSCP12-18 |             |      |      |       |      | | |   detail.)                                          |
ECO #: MSCP12-18 |             |    7 |  233 |   351 |   E9 |*|*| Buffer length violation                             |
ECO #: MSCP12-18 |             |      |      |       |      | | |   The  number  of  bytes  requested   in  the  MSCP |
ECO #: MSCP12-18 |             |      |      |       |      | | |   command   exceeds  the buffer length as specified |
ECO #: MSCP12-18 |             |      |      |       |      | | |   in  the  buffer  descriptor. (See the  BI Storage |
ECO #: MSCP12-18 |             |      |      |       |      | | |   Systems Port (BISSP) for additional detail.)      |
ECO #: MSCP12-18 |             |    8 |  265 |   411 |  109 |*|*| Access control violation                            |
ECO #: MSCP12-18 |             |      |      |       |      | | |   The   access   mode   specified   in  the  buffer |
ECO #: MSCP12-18 |             |      |      |       |      | | |   descriptor   is  protected  against  by  the PROT |
ECO #: MSCP12-18 |             |      |      |       |      | | |   field  in  the  PTE. (See  the BI Storage Systems |
ECO #: MSCP12-18 |             |      |      |       |      | | |   Port (BISSP) for for additional detail.)          |
ECO #: MSCP12-18                                                          .

   <<End ECO #: MSCP12-18 Revised Appendix B for BI>>


   <<ECO #: MSCP12-19 Maximum Error Log Size [approved 29 June 1984>>


ECO #: MSCP12-19    Proposal:

ECO #: MSCP12-19    As per the agreement at the 5 March 1984 MSCP V1.2 and TMSCP V1.6  ECO
ECO #: MSCP12-19    review  meeting,  this  memo recommends a new, lower maximum error log
ECO #: MSCP12-19    message byte count of 128 bytes.  This value is consistent with  error
ECO #: MSCP12-19    log  entry  lengths  for  current disk devices, such as the RK07.  The
ECO #: MSCP12-19    previous value was 384 bytes and  presented  many  problems,  not  the
ECO #: MSCP12-19    least  of  which  was  the  fact that only two such error log messages
ECO #: MSCP12-19    would exhaust the error log buffer capacity in the executive.

   <<End ECO #: MSCP12-19 Maximum Error Log Size>>


   
   <<ECO #: MSCP12-20 RC25 Waiver Requests [approved 12 September 1984]>> 
   
   
ECO #: MSCP12-20                       RC25 Waiver of MSCP Operation Request
   
ECO #: MSCP12-20       Portions of the following were extracted from a memo dealing with RC25
ECO #: MSCP12-20       MSCP  V1.2  compliance I received from Fred Zayas on 17 APR 1984.  The
ECO #: MSCP12-20       information  provided  describes  RC25  divergence  from   MSCP   V1.2
ECO #: MSCP12-20       (extended) operation and is submitted for your consideration as formal
ECO #: MSCP12-20       waiver of operation requests.  If approved the waivers will eventually
ECO #: MSCP12-20       be included in Chapter 9 of the MSCP specification.
   
ECO #: MSCP12-20       The number in the right margin is meant to separate the  issues  being
ECO #: MSCP12-20       addressed.   Please  refer  to  the  appropriate  issue number in your
ECO #: MSCP12-20       response.
   
   
ECO #: MSCP12-20    1       o  Error log messages are sent after, instead of before the
ECO #: MSCP12-20    1          corresponding end message.  See requirements of ECO #:
ECO #: MSCP12-20    1          MSCP12-2.
ECO #: MSCP12-20    1  
ECO #: MSCP12-20    1          Corrected in RC25 microcode.  Except for some pathalogical
ECO #: MSCP12-20    1          cases, error log packets are returned BEFORE the corresponding
ECO #: MSCP12-20    1          end packet.  The pathalogical cases are:
ECO #: MSCP12-20    1  
ECO #: MSCP12-20    1                  1. The host does not abide by the credit limit
ECO #: MSCP12-20    1                     supplied by the controller AND the host has
ECO #: MSCP12-20    1                     given us <credit limit>+1 outstanding requests
ECO #: MSCP12-20    1                     AND an error log is generated.
ECO #: MSCP12-20    1  
ECO #: MSCP12-20    1                  2. The host abides by the credit limit supplied
ECO #: MSCP12-20    1                     by the controller AND the host has given us
ECO #: MSCP12-20    1                     <credit limit> outstanding requests AND two
ECO #: MSCP12-20    1                     (or more) error log packets are generated.
ECO #: MSCP12-20    1  
ECO #: MSCP12-20    1                  3. There is a small window while processing immediate
ECO #: MSCP12-20    1                     commands if the host has <credit limit> outstanding
ECO #: MSCP12-20    1                     requests AND an error log packet is generated.
ECO #: MSCP12-20    1  
ECO #: MSCP12-20    1          In these cases, the 1st, 2nd or subsequent error logs will
ECO #: MSCP12-20    1          be sent to the host AFTER the corresponding end packet.
ECO #: MSCP12-20    1          (Basically, when we have no more internal resources (packet
ECO #: MSCP12-20    1          slots) for making up log packets, we send out the log packets
ECO #: MSCP12-20    1          after the end packet so we can use the end packet slot for
ECO #: MSCP12-20    1          error log packets).
ECO #: MSCP12-20                                                                              Page 2


ECO #: MSCP12-20    2  
ECO #: MSCP12-20    2       o  Data  Error  (sub-code  "Forced  Error")  status  is  not
ECO #: MSCP12-20    2          reported  if  a  block  written  with  the "forced error"
ECO #: MSCP12-20    2          modifier is encountered during  the  execution  of:   the
ECO #: MSCP12-20    2          compare  portion  of  a "compare" modified write command;
ECO #: MSCP12-20    2          or, the COMPARE HOST DATA command.  See  requirements  of
ECO #: MSCP12-20    2          MSCP  V1.2,  section 5.5, Page 5-12 (lines 40 through 45)
ECO #: MSCP12-20    2          through Page 5-13 (lines 1 through 7).
ECO #: MSCP12-20                                                                              Page 3


ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3       o  Duplicate unit number handling is improper.  Find enclosed
ECO #: MSCP12-20    3          the script output that demonstrates this.
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3          Please note that the disasterous case -- on controller init
ECO #: MSCP12-20    3          both master and slave units are duplicated -- is properly
ECO #: MSCP12-20    3          covered.  That is, either unit will fault on any spin up
ECO #: MSCP12-20    3          attempt.  Also note our intent to correct this problem in
ECO #: MSCP12-20    3          full in the RC26.
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3                           Note from Zahrobsky
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  The script output mentioned above was provided to me in hardcopy form.
ECO #: MSCP12-20    3  A  description of the "improper" operation I found during the analysis
ECO #: MSCP12-20    3  of that script output follows.
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  Before getting  into  the  analysis  some  background  information  is
ECO #: MSCP12-20    3  necessary.   The script output was created during a run of the Storage
ECO #: MSCP12-20    3  Architecture group's MSCP Detail Tester (DET) program.  The  input  to
ECO #: MSCP12-20    3  DET  was  a script file created by me and provided to Fred Zayas.  The
ECO #: MSCP12-20    3  script required two  RC25  drives  in  a  master/slave  configuration.
ECO #: MSCP12-20    3  Throughout the discussion below the master drive is referred to as "M"
ECO #: MSCP12-20    3  and the slave as "S".
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3        o  Divergence #1
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Test set up:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           1.  "M" drive spun up with 0/1 unit plug inserted
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           2.  "S" drive spun down with no unit  plug  (unknown  to  the
ECO #: MSCP12-20    3               controller)
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           3.  controller initialized and characteristics set
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           4.  "M" unit 0 and "M" unit 1 brought ONLINE to host
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           5.  duplicate unit number condition created by inserting  0/1
ECO #: MSCP12-20    3               unit number plug into "S" and attemptimg to spin it up
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Improper operation:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Status code 'Success (subcode "Duplicate  Unit  Number")'  is
ECO #: MSCP12-20    3           not  reported  in  the  end  messages  of  all commands which
ECO #: MSCP12-20    3           require it when a duplicate unit number condition exists  and
ECO #: MSCP12-20    3           the  affected  unit  is  ONLINE  to  a  host.   The  improper
ECO #: MSCP12-20    3           operation occured on the following commands:
ECO #: MSCP12-20    3            >  WRITE
ECO #: MSCP12-20    3            >  READ
ECO #: MSCP12-20    3            >  ACCESS
ECO #: MSCP12-20    3            >  COMPARE HOST DATA
ECO #: MSCP12-20    3            >  ERASE
ECO #: MSCP12-20    3            >  REPLACE
ECO #: MSCP12-20    3            >  SET UNIT CHARACTERISTICS
ECO #: MSCP12-20                                                                              Page 4


ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           The only command which reports the status  correctly  is  the
ECO #: MSCP12-20    3           GET  UNIT  STATUS  command.  The failure occurred on commands
ECO #: MSCP12-20    3           issued to both "M" unit 0 and "M" unit 1.
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3        o  Divergence #2
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Test set up:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           1.  "M" unit 0 and "M"  unit  1  ONLINE  from  previous  test
ECO #: MSCP12-20    3               sequence
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           2.  AVAILABLE command issued to "M" unit 0
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Improper operation:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           "M" unit 0 actually went 'available'  instead  of  'offline'.
ECO #: MSCP12-20    3           An  ONLINE  command directed to "M" unit 0 issued immediately
ECO #: MSCP12-20    3           after  the  AVAILABLE  command  reported  'Success   (subcode
ECO #: MSCP12-20    3           "Duplicate   Unit  Number")'  instead  of  'Offline  (subcode
ECO #: MSCP12-20    3           "Duplicate Unit Number")'.  'Success (subcode "Duplicate Unit
ECO #: MSCP12-20    3           Number")'  status  is  not  valid for the ONLINE command.  In
ECO #: MSCP12-20    3           addition, "M"  unit  0  was  actually  brought  'online'  and
ECO #: MSCP12-20    3           subsequent  commands  (same  sequence as listed in Divergence
ECO #: MSCP12-20    3           #1) were executed successfully (i.e., they reported  'Success
ECO #: MSCP12-20    3           (subcode "Normal")' status).
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3        o  Divergence #3
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Test set up:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           1.  "M" unit 1 ONLINE from previous test sequence
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           2.  AVAILABLE command issued to "M" unit 1
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Improper Operation:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Same as described in Divergence #2 above.  In  addition,  the
ECO #: MSCP12-20    3           drive was not spun down as required.
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3        o  Divergence #4
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Test set up:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           1.  controller initialized and default  host  access  timeout
ECO #: MSCP12-20    3               allowed  to  expire  resulting  in  the  controller going
ECO #: MSCP12-20    3               'controller available'
ECO #: MSCP12-20    3
ECO #: MSCP12-20    3           2.  "M" drive spun down with 0/1 unit plug inserted
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           3.  "S" drive spun down with 0/1 unit plug inserted
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           4.  controller initialized and characteristics set
ECO #: MSCP12-20    3  
ECO #: MSCP12-20                                                                              Page 5


ECO #: MSCP12-20    3           Improper operation:
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           Status code 'Offline (subcode "Duplicate  Unit  Number")'  is
ECO #: MSCP12-20    3           not  reported  in  the  end  messages  of  all commands which
ECO #: MSCP12-20    3           require it when a duplicate unit number condition exists  and
ECO #: MSCP12-20    3           the  affected unit is not ONLINE to a host.  The RC25 reports
ECO #: MSCP12-20    3           status code 'Offline (subcode "Unit Disabled by Field Service
ECO #: MSCP12-20    3           or  Internal  Diagnostic")  instead.   The improper operation
ECO #: MSCP12-20    3           occurred on the following commands:
ECO #: MSCP12-20    3            >  ONLINE
ECO #: MSCP12-20    3            >  GET UNIT STATUS
ECO #: MSCP12-20    3            >  WRITE
ECO #: MSCP12-20    3            >  READ
ECO #: MSCP12-20    3            >  ACCESS
ECO #: MSCP12-20    3            >  COMPARE HOST DATA
ECO #: MSCP12-20    3            >  ERASE
ECO #: MSCP12-20    3            >  REPLACE
ECO #: MSCP12-20    3            >  SET UNIT CHARACTERISTICS
ECO #: MSCP12-20    3  
ECO #: MSCP12-20    3           The failure occurred on commands issued to both  "M"  unit  0
ECO #: MSCP12-20    3           and "M" unit 1.
ECO #: MSCP12-20    3  
   
   
   <<End ECO #: MSCP12-20 RC25 Waiver Requests>>


   <<ECO #: MSCP12-22 Revised Appendix C for RX Drives [approved 29 June 1984]

ECO #: MSCP12-22    Proposal:
    
ECO #: MSCP12-22            Modify Table C-3 DEC Standard 166 Disk Identifier Values to include
ECO #: MSCP12-22            the following media:
    
ECO #: MSCP12-22            o RX31 (Device Type Name = DU; Device: 5 1/4 inch floppy disk drive)
ECO #: MSCP12-22            o RX32 (Device Type Name = DU; Device: 5 1/4 inch floppy disk drive)
ECO #: MSCP12-22            o RX18 (Device Type Name = DU; Device: 5 1/4 inch floppy disk drive)
    
ECO #: MSCP12-22    Justification:
    
ECO #: MSCP12-22            Products which are currently planned should be properly identified.
    
ECO #: MSCP12-22    Impact:
    
ECO #: MSCP12-22            Host software must be modified to recognize the new identifiers as
ECO #: MSCP12-22            required.


ECO #: MSCP12-22                         ADDENDUM (by Jim Zahrobsky)


ECO #: MSCP12-22    The changes to Table C-3 are shown by change bars below.


ECO #: MSCP12-22    +-------+-------+------+----------------------------+--------------------------
ECO #: MSCP12-22    | Model |Device |      |                            |
ECO #: MSCP12-22    | Byte  |Type   |Media |    Media Type Identifier   |
ECO #: MSCP12-22    | (dec.)|Name   |Name  |     octal      |    hex    |   Device
ECO #: MSCP12-22    +-------+-------+------+----------------+-----------+--------------------------
ECO #: MSCP12-22                                            .
ECO #: MSCP12-22                                            .
ECO #: MSCP12-22 |  |   15  | DU    | RX31 | 022545,100037  | 2565,801F | 5 1/4 inch floppy disk drive
ECO #: MSCP12-22 |  |   16  | DU    | RX32 | 022545,100040  | 2565,8020 | 5 1/4 inch floppy disk drive
ECO #: MSCP12-22 |  |   17  | DU    | RX18 | 022545,100022  | 2565,8012 | 5 1/4 inch floppy disk drive
ECO #: MSCP12-22                                            .

   <<End ECO #: MSCP12-22 Revised Appendix C for RX Drives>>


   <<ECO #: MSCP12-25 Revised Appendix C for QDAs [approved 29 June 1984]>>

ECO #: MSCP12-25 Proposal:

ECO #: MSCP12-25 Modify Table C-2 Mass Storage Controller Model Values as  shown  below
ECO #: MSCP12-25 to;  correctly  identify  the  QDA50  controller (listed in previously
ECO #: MSCP12-25 approved ECO #MSCP12-11 only as QDA); and, add the QDA25 controller.

ECO #: MSCP12-25                 +----------+------------------------------------+
ECO #: MSCP12-25                 |Model Byte|                                    |
ECO #: MSCP12-25                 | (decimal)|    Controller Type                 |
ECO #: MSCP12-25                 +----------+------------------------------------+
ECO #: MSCP12-25                                         .
ECO #: MSCP12-25                                         .
ECO #: MSCP12-25                                         .
ECO #: MSCP12-25                 |   13     | QDA50                              |
ECO #: MSCP12-25                                         .
ECO #: MSCP12-25                                         .
ECO #: MSCP12-25                                         .
ECO #: MSCP12-25                 |   17     | QDA25                              |

ECO #: MSCP12-25 Justification:

ECO #: MSCP12-25 Products which exist or  are  currently  planned  should  be  properly
ECO #: MSCP12-25 identified.

ECO #: MSCP12-25 Impact:

ECO #: MSCP12-25 Host software must be modified to recognize  the  new  identifiers  as
ECO #: MSCP12-25 required.

   <<End ECO #: MSCP12-25 Revised Appendix C for QDAs>>
   

   <<ECO #: MSCP12-26 Allocation Class Waiver (HSC/VMS) [approved 12 September 1984]>> 
   
ECO #: MSCP12-26    The  HSC50 (and  VAX/VMS) request  exemption from  the MSCP  requirement that
ECO #: MSCP12-26    reserved fields be returned as zeros for the byte at offset 4 in the MSCP Set
ECO #: MSCP12-26    Controller  Characteristics end  message.   MSCP describes this byte as being
ECO #: MSCP12-26    reserved.  However, the HSC50 and VAX/VMS use this byte in a private protocol
ECO #: MSCP12-26    commonly  known, as  "allocation-class."   This exemption  is requested to be
ECO #: MSCP12-26    effective  until one  year after the passage of an MSCP ECO which provides at
ECO #: MSCP12-26    least  one  byte  of  host-settable,  non-volatile  storage  in  at least all 
ECO #: MSCP12-26    multi-host MSCP  controllers.   At  that  time, both the  HSC50 and VMS  must 
ECO #: MSCP12-26    return to having zeros in that field.
   
   <<End ECO #: MSCP12-26 Allocation Class Waiver (HSC/VMS)>>


   <<ECO #: MSCP12-27 Read Only Device Write Protect [approved as amended 10 August 1984]>> 

ECO #: MSCP12-27    This ECO is being submitted on behalf of Jane Wang for the  RUX50
ECO #: MSCP12-27    floppy disk controller.


ECO #: MSCP12-27    Discussion

ECO #: MSCP12-27    The RUX50 controller, which supports several new types of  floppy
ECO #: MSCP12-27    disks,  has  recently pointed out a "hole" in MSCP.  The specific
ECO #: MSCP12-27    case presented is that of a 40 track floppy placed in  a  96  tpi
ECO #: MSCP12-27    drive.   The  RUX50  can  read the floppy, but cannot write it --
ECO #: MSCP12-27    thus it is write protected  in  some  sense.   However  there  is
ECO #: MSCP12-27    currently no provision in MSCP for reporting this situation.

ECO #: MSCP12-27    There are several ways we could address this.  We could invent  a
ECO #: MSCP12-27    new   form  of  write  protection,  with  a  new  unit  flag  and
ECO #: MSCP12-27    everything.  I would prefer not to do this.  Or we could  combine
ECO #: MSCP12-27    it  into one of the three existing forms of write protection.  Of
ECO #: MSCP12-27 |  the three, the semantics seem most similar to Data  Safety  Write
ECO #: MSCP12-27    Protection.  That is what I am proposing in the ECO that follows.



ECO #: MSCP12-27    ECO Text:

ECO #: MSCP12-27    The following discussion needs to be combined  with  the  current
ECO #: MSCP12-27    Section  4.13,  "Write  Protection".  I suspect it should replace
ECO #: MSCP12-27    the beginning of that section, but the whole  section  will  need
ECO #: MSCP12-27    some editorial work.

ECO #: MSCP12-27         There are three kinds of write protection that can apply  to
ECO #: MSCP12-27         an  MSCP  device:  Hardware Write Protection, Software Write
ECO #: MSCP12-27 |       Protection, and Data Safety Write Protection.  Each kind  of
ECO #: MSCP12-27         write  protection  is  controlled  from a separate source as
ECO #: MSCP12-27         follows:

ECO #: MSCP12-27         Hardware Write Protection

ECO #: MSCP12-27             Hardware Write Protection is controlled by the  user  or
ECO #: MSCP12-27             operator  using the unit's write protect mechanism.  The
ECO #: MSCP12-27             status  of  Hardware  Write  Protection  may  change  at
ECO #: MSCP12-27 								Page 2


ECO #: MSCP12-27             unpredictable times in response to human intervention.

ECO #: MSCP12-27         Software Write Protection

ECO #: MSCP12-27             Software Write Protection is controlled by the  host  or
ECO #: MSCP12-27             hosts.   Host(s)  set  or  change the status of Software
ECO #: MSCP12-27             Write  Protection  using  the   ONLINE   or   SET   UNIT
ECO #: MSCP12-27             CHARACTERISTICS  commands  with  the  "Enable  Set Write
ECO #: MSCP12-27             Protect" modifier.  In general, the detailed  causes  of
ECO #: MSCP12-27             Software  Write  Protection  are matters of host policy.
ECO #: MSCP12-27             However, Host Initiated Bad Block  Replacement  requires
ECO #: MSCP12-27             that  hosts  use  Software  Write  Protection to emulate
ECO #: MSCP12-27 |           certain causes of Data Safety Write Protection.

ECO #: MSCP12-27 |       Data Safety Write Protection

ECO #: MSCP12-27 |           Data Safety Write Protection is controlled by  the  MSCP
ECO #: MSCP12-27             server.   It  is set whenever some condition in the unit
ECO #: MSCP12-27             or volume prevents reliable modification of data on  the
ECO #: MSCP12-27             volume.  Possible causes include:

ECO #: MSCP12-27              o  An incomplete bad block replacement.

ECO #: MSCP12-27              o  An invalid RCT.

ECO #: MSCP12-27              o  The unit is only capable  of  reading  the  volume's
ECO #: MSCP12-27                 format.    I.e.,   a   single-density  volume  in  a
ECO #: MSCP12-27                 double-density drive.

ECO #: MSCP12-27             Note that there can be multiple causes for a unit  being
ECO #: MSCP12-27 |           Data  Safety  Write Protected.  Furthermore, some causes
ECO #: MSCP12-27             represent   errors   while   others   represent   normal
ECO #: MSCP12-27             occurences.

ECO #: MSCP12-27             Each individual cause can only  be  established  when  a
ECO #: MSCP12-27             unit is brought "Unit-Online".  Causes can be eliminated
ECO #: MSCP12-27 |           -- possibly allowing the unit to cease being Data Safety
ECO #: MSCP12-27             Write Protected -- while the unit remains "Unit-Online".
ECO #: MSCP12-27             However, the server can only establish a new  cause  for
ECO #: MSCP12-27 |           the  unit  to  be Data Safety Write Protected by forcing
ECO #: MSCP12-27             the unit to be "Unit-Available" to  all  class  drivers.
ECO #: MSCP12-27             Thus  class  drivers are guaranteed that a unit will not
ECO #: MSCP12-27 |           spontaneously become Data Safety Write  Protected  while
ECO #: MSCP12-27             the unit is "Unit-Online".


ECO #: MSCP12-27 |  Move the definition of the "Write Protected (Data  Safety)"  unit
ECO #: MSCP12-27    flag  into  Basic  MSCP  from  the Controller Initiated Bad Block
ECO #: MSCP12-27    Replacement ECO.


ECO #: MSCP12-27    Add the following status code to the ONLINE, GET UNIT STATUS, and
ECO #: MSCP12-27    SET UNIT CHARACTERISTICS commands:

ECO #: MSCP12-27    Success (sub-code "Read-only Volume Format")
ECO #: MSCP12-27 								Page 3


ECO #: MSCP12-27        The unit only implements read access for the  format  of  the
ECO #: MSCP12-27        volume  mounted  in  the unit.  For example, a single-density
ECO #: MSCP12-27        volume is mounted in a double-density drive that can read but
ECO #: MSCP12-27 |      not  write  it.  Note that the unit will be Data Safety Write
ECO #: MSCP12-27        Protected whenever this sub-code is returned.



ECO #: MSCP12-27    Add the following entry to Table B-2,  Standard  Status  Sub-code
ECO #: MSCP12-27    Values:

ECO #: MSCP12-27       +------+---------------------+----------------------------+
ECO #: MSCP12-27       | Sub- |   Code + Sub-code   |                            |
ECO #: MSCP12-27       | code | Dec. |  Oct. | Hex. |     Status Sub-Code        |
ECO #: MSCP12-27       +------+------+-------+------+----------------------------+
ECO #: MSCP12-27       | "Success" sub-code values: |                            |
ECO #: MSCP12-27       |  128 | 4096 | 10000 | 1000 | Read Only Volume Format    |


   <<End ECO #: MSCP12-27 Read Only Device Write Protect>>


   <<ECO #: MSCP12-30 Multi-Host Functionality [approved as amended 10 August 1984]>> 

ECO #: MSCP12-30         7.1  Multi Host Functionality

ECO #: MSCP12-30         Multi host functionality is an optional feature of MSCP  which  allows
ECO #: MSCP12-30         more  than  one  connection  to  simultaneously  access  a controller.
ECO #: MSCP12-30         Although the term 'host' is usually assumed to be synonomous with  the
ECO #: MSCP12-30         term  'connection',  it  need  not  be  so.   Indeed,  it is perfectly
ECO #: MSCP12-30         permissable for multiple connections to  be  open  to  a  single  MSCP
ECO #: MSCP12-30         server from one host.

ECO #: MSCP12-30         The operational characteristics of a controller utilizing this  option
ECO #: MSCP12-30         differ  only  slightly  from that of a single host controller, so only
ECO #: MSCP12-30         those  differences  will  be  detailed  herein.    Any   actions   not
ECO #: MSCP12-30         specifically  mentioned  in this section may be assumed to function in
ECO #: MSCP12-30         an identical manner to their single host counterparts.




ECO #: MSCP12-30         7.1.1  Class Driver / MSCP  Server  Communications - The  MSCP  server
ECO #: MSCP12-30         must  treat  each  connection  with  a  class driver as a seperate and
ECO #: MSCP12-30         unique entity, with each connection obeying all the rules detailed  in
ECO #: MSCP12-30         section 3.  New connections may be accepted or rejected without regard
ECO #: MSCP12-30         to  the  number  of  existing   connections   (other   than   resource
ECO #: MSCP12-30         limitations),  and no notification will be given to the new connection
ECO #: MSCP12-30         as  to  the  presence  or  absence  of   other   connections.    Class
ECO #: MSCP12-30         driver/server  synchronization  is  on a per connection basis, and the
ECO #: MSCP12-30         loss of synchronization between a class driver and the controller on a
ECO #: MSCP12-30         specific  connection which does not require the host to perform a hard
ECO #: MSCP12-30         initialization  of  the  controller  should  not  affect   any   other
ECO #: MSCP12-30         connections which may be open.

ECO #: MSCP12-30         The controller is responsible for retaining knowlege of the individual
ECO #: MSCP12-30         connections, and must insure that all MSCP responses and notifications
ECO #: MSCP12-30         are sent to the correct class driver.  It is not the responsibility of
ECO #: MSCP12-30         the  controller  however,  to  maintain the ordering of the individual
ECO #: MSCP12-30         requests (other than for sequential commands as detailed  later).   If
ECO #: MSCP12-30         more than one data transfer request for the same LBN is outstanding at
ECO #: MSCP12-30         the  same  time,  the  ordering  of  the  data  written/read  will  be
ECO #: MSCP12-30         indeterminate,  and  will  depend  only  on  the controller's internal
ECO #: MSCP12-30         ordering and optimization algorithms.



ECO #: MSCP12-30         7.1.2  MSCP Commands - The following list of commands are modified  as
ECO #: MSCP12-30         noted for multi host operation.  Any characteristics and/or actions of
ECO #: MSCP12-30         the command not specified may be assumed to operate  in  an  identical
ECO #: MSCP12-30         manner to their single host counterparts.

ECO #: MSCP12-30         The command category for each command remains the same as  for  single
ECO #: MSCP12-30         host  MSCP,  but  a  small  enhancement is made for the sequential and
ECO #: MSCP12-30 									Page 2

ECO #: MSCP12-30         non-sequential categories.



ECO #: MSCP12-30         7.1.2.1  Sequential Commands - As specified in section 4.5, sequential
ECO #: MSCP12-30         commands  are  those  which  must  be executed in the precise order in
ECO #: MSCP12-30         which they are received, and may not take effect until  such  time  as
ECO #: MSCP12-30         all  preceeding  sequential  and  non-sequential  commands  have  been
ECO #: MSCP12-30         executed on the specified unit.

ECO #: MSCP12-30         For multi host operation,  this  definition  is  further  enhanced  to
ECO #: MSCP12-30         include  all outstanding commands on all connections for the specified
ECO #: MSCP12-30         unit.  The implication of this is that if one host issues a sequential
ECO #: MSCP12-30         command  to a unit on which other hosts have outstanding commands, the
ECO #: MSCP12-30         sequential command in question is delayed until all commands from  all
ECO #: MSCP12-30         hosts  have  completed.   Furthermore,  any new commands from any host
ECO #: MSCP12-30         will be blocked pending completion of the sequential command.



ECO #: MSCP12-30         7.1.2.2  Non-sequential  Commands - As  specified  in   section   4.5,
ECO #: MSCP12-30         non-sequential  commands are those that the controller may re-order so
ECO #: MSCP12-30         as to optimize performance.  For multi-host operation, this definition
ECO #: MSCP12-30         is   further   enhanced  to  allow  the  controller  to  re-order  all
ECO #: MSCP12-30         non-sequential commands across all connections.



ECO #: MSCP12-30         7.1.2.3  Unit States - With multiple hosts connected to a  controller,
ECO #: MSCP12-30         it is possible for a single disk to be in different states relative to
ECO #: MSCP12-30         the different hosts.  A disk may be "Unit  Online"  to  one  host  for
ECO #: MSCP12-30         example,  but  be  "Unit  Available" to another.  For this reason, the
ECO #: MSCP12-30         controller must not only maintain the status of the disk  relative  to
ECO #: MSCP12-30         the controller, but must also maintain the status of the disk relative
ECO #: MSCP12-30         to each host on which a connection is open.



ECO #: MSCP12-30         7.1.2.4  AVAILABLE Command - If a host issues an AVAILABLE command  to
ECO #: MSCP12-30         a disk unit, the controller must determine the status of the disk unit
ECO #: MSCP12-30         relative  to  all  hosts  which  have  an  open  connection  prior  to
ECO #: MSCP12-30         proceeding.   There are exactly five cases, which may be summarized as
ECO #: MSCP12-30         follows:

ECO #: MSCP12-30         1.  The disk is "Unit Available" to all  hosts.   In  this  case,  the
ECO #: MSCP12-30             command  is  nugatory  if the MD.SPD (MSCP$x_MD_SPNDW) modifier is
ECO #: MSCP12-30             clear, but will be spun down if it is set.

ECO #: MSCP12-30         2.  The disk is "Unit Available" to the issuing host, "Unit Online" to
ECO #: MSCP12-30             one  or  more  other  hosts, and the MD.ALL modifier is clear.  In
ECO #: MSCP12-30             this case, the command is nugatory, and no action  is  taken.   If
ECO #: MSCP12-30             the  MD.SPD  modifier  is set, the disk is not spun down and a sub
ECO #: MSCP12-30             code of "Spin-down ignored"  is  returned.   The  returned  status
ECO #: MSCP12-30             flags  have  both  the  "Still Online" and "Still Connected" flags
ECO #: MSCP12-30 									Page 3

ECO #: MSCP12-30             set, with "Still Online" reflecting the  fact  that  the  unit  is
ECO #: MSCP12-30             still online to one or more other hosts, and the "Still Connected"
ECO #: MSCP12-30             flag  showing  that  the  unit  cannot  be  accessed  via  another
ECO #: MSCP12-30             controller.

ECO #: MSCP12-30         3.  The  disk  is  "Unit  Online"  to  the  issuing  host,  and  "Unit
ECO #: MSCP12-30             Available"  to  all other hosts, and the MD.ALL modifier is clear.
ECO #: MSCP12-30             In this case, the disk is sent "Unit Available"  relative  to  the
ECO #: MSCP12-30             issuing  host,  and  if  the  MD.SPD (MSCP$x_MD_SPNDW) modifier is
ECO #: MSCP12-30             specified, the disk will be spun down.

ECO #: MSCP12-30         4.  The disk is "Unit Online" to the issuing host,  "Unit  Online"  to
ECO #: MSCP12-30             one  or  more  other  hosts, and the MD.ALL modifier is clear.  In
ECO #: MSCP12-30             this case, the disk is sent "Unit Available" to the issuing  host,
ECO #: MSCP12-30             remains  "Unit  Online"  to  all  other  hosts  to  which  it  was
ECO #: MSCP12-30             previously "Unit Online".  If the MD.SPD modifier is set, the disk
ECO #: MSCP12-30             is  not  spun  down  and  a  sub  code  of  "Spin-down ignored" is
ECO #: MSCP12-30             returned.  The returned status flags have both the "Still  Online"
ECO #: MSCP12-30             and  "Still  Connected"  flags set, with "Still Online" reflecting
ECO #: MSCP12-30             the fact that the unit is still online to one or more other hosts,
ECO #: MSCP12-30             and  the  "Still  Connected"  flag showing that the unit cannot be
ECO #: MSCP12-30             accessed via another controller.

ECO #: MSCP12-30         5.  The disk is "Unit Online" to the issuing host,  "Unit  Online"  to
ECO #: MSCP12-30             zero  or  more  other  hosts,  and  the  MD.ALL  (MSCP$x_MD_ALLCD)
ECO #: MSCP12-30             modifier is specified.  In this case, the disk will transition  to
ECO #: MSCP12-30             a  state  of "Unit Available" relative to all hosts, and AVAILABLE
ECO #: MSCP12-30             attention messages will be sent  to  all  hosts.   If  the  MD.SPD
ECO #: MSCP12-30             modifier was specified, the disk will be spun down.




ECO #: MSCP12-30         7.1.2.5  ONLINE Command - This command will cause a unit to transition
ECO #: MSCP12-30         from the "Unit Available" state to the "Unit Online" state relative to
ECO #: MSCP12-30         the issuing host.  The unit will remain  in  the  same  state  it  was
ECO #: MSCP12-30         relative  to  other  hosts  prior to issuance of this command.  If the
ECO #: MSCP12-30         unit was already "Unit Online" to the issuing  host,  the  end  packet
ECO #: MSCP12-30         will be returned with a sub-code of "Already Online".  If the unit was
ECO #: MSCP12-30         "Unit Online" to a different host,  no  sub-code  will  be  issued  to
ECO #: MSCP12-30         inform  the  issuing host of this fact.  The optional unit flags check
ECO #: MSCP12-30         described in in MSCP V1.2, section 6.13, is no  longer  optional,  but
ECO #: MSCP12-30         MUST be performed in a multi-host environment.



ECO #: MSCP12-30         7.1.2.6  SET CONTROLLER  CHARACTERISTICS  Command - The  host  timeout
ECO #: MSCP12-30         field  specified  must  be interpreted by the controller as applicable
ECO #: MSCP12-30         only to the host which issued the command, and must not  interfere  or
ECO #: MSCP12-30         modify the host timeouts of other hosts connected to the controller.

ECO #: MSCP12-30         The CF.MLH (MSCP$x_CF_MHST) flag must be set in the end  packet  flags
ECO #: MSCP12-30         field  to  indicate  to the host that the controller supports multiple
ECO #: MSCP12-30         hosts.  Note that this is the only means for a host  to  determine  if
ECO #: MSCP12-30 									Page 4

ECO #: MSCP12-30         this  controller option is present.  This flag is read only, and has a
ECO #: MSCP12-30         value of 4.

ECO #: MSCP12-30         If a host has issued the SET CONTROLLER CHARACTERISTICS  command  with
ECO #: MSCP12-30         the  "Enable  Other  Host's  Error  Log  Messages" controller flag set
ECO #: MSCP12-30         (CF.OTH), then the controller will  send  a  copy  of  ALL  error  log
ECO #: MSCP12-30         messages  to  that host, even if the error log message in question was
ECO #: MSCP12-30         as a result of an action  taken  by  another  host.   In  effect,  the
ECO #: MSCP12-30         controller  will  send  error  log messages in a 3 step procedure (the
ECO #: MSCP12-30         ordering is unimportant):
   
ECO #: MSCP12-30         1.  If the error was generated as a result of a specific command by  a
ECO #: MSCP12-30             host  and  that host had set the CF.THS flag in the SET CONTROLLER
ECO #: MSCP12-30             CHARACTERISTICS command, the controller will  send  that  host  an
ECO #: MSCP12-30             error log message.
   
ECO #: MSCP12-30         2.  The controller will  send  duplicate  copies  of  that  error  log
ECO #: MSCP12-30             message  to all hosts which had previously issued a SET CONTROLLER
ECO #: MSCP12-30             CHARACTERISTICS command with the CF.OTH flag set.
   
ECO #: MSCP12-30         3.  If the error was not generated as a result of a specific  command,
ECO #: MSCP12-30             the  controller  will send an error log message to all hosts which
ECO #: MSCP12-30             had previously issued a  SET  CONTROLLER  CHARACTERISTICS  command
ECO #: MSCP12-30             with the CF.MSC flag set.
   
ECO #: MSCP12-30 									Page 5



ECO #: MSCP12-30 ADDENDUM TO MULTIHOST FUNCTIONALITY PROPOSAL


ECO #: MSCP12-30 This document is a description of how controller timeouts and progress
ECO #: MSCP12-30 indicators must work in a Multi-Host environment.



ECO #: MSCP12-30 1  HISTORY

ECO #: MSCP12-30 In a single host environment, the host  knows  the  Command  Reference
ECO #: MSCP12-30 Number  of  the  oldest  outstanding  command.   Once every Controller
ECO #: MSCP12-30 Timeout  interval,  the  hosts  requests  the  status  of  the  oldest
ECO #: MSCP12-30 outstanding  command  (via a GET COMMAND STATUS command).  If progress
ECO #: MSCP12-30 is not made on the oldest outstanding command  within  two  Controller
ECO #: MSCP12-30 Timeout  intervals,  then the host assumes the controller to be insane
ECO #: MSCP12-30 and reinitializes it.

ECO #: MSCP12-30 In a multi-host environment, each host has a different concept of what
ECO #: MSCP12-30 the  oldest  outstanding  command  is,  hence the controller must make
ECO #: MSCP12-30 progress on each of  those  oldest  outstanding  commands  within  the
ECO #: MSCP12-30 Controller Timeout interval.

ECO #: MSCP12-30 The controller is free to implement any mechanism that meets the above
ECO #: MSCP12-30 description.   The  intent  of  this  document  is  to  describe how a
ECO #: MSCP12-30 reasonable controller might implement such a mechanism.



ECO #: MSCP12-30 2  DIVIDE AND CONQUER

ECO #: MSCP12-30 Any outstanding command falls into one of the following categories:

ECO #: MSCP12-30      1.  Commands which have already been started.

ECO #: MSCP12-30      2.  Sequential commands which will be  started  as  soon  as  all
ECO #: MSCP12-30          previously started non-sequential commands have completed.

ECO #: MSCP12-30      3.  Commands which can not be started until the  already  started
ECO #: MSCP12-30          sequential command completes.

ECO #: MSCP12-30      4.  Commands which could be started now, but which have  not  yet
ECO #: MSCP12-30          been  started (for lack of resources or any other whim of the
ECO #: MSCP12-30          controller).

ECO #: MSCP12-30 The controller must keep an internal command status field composed  of
ECO #: MSCP12-30 two  subfields,  called  the Requested Commands Position (RCP) and the
ECO #: MSCP12-30 Started Commands Status (SCS).  It seems  easiest  to  describe  these
ECO #: MSCP12-30 fields in reference to each of the above categories.



ECO #: MSCP12-30 2.1  Started Commands

ECO #: MSCP12-30 RCP would be 0, implying that the specified command is at position  0,
ECO #: MSCP12-30 i.e.  is is running now.
ECO #: MSCP12-30 									Page 6


ECO #: MSCP12-30 SCS would be an encoding of the amount  of  work  (including  possible
ECO #: MSCP12-30 retries  etc.)  remaining  on  the  requested  command,  or  0  if the
ECO #: MSCP12-30 controller expects the command to finish within  the  next  Controller
ECO #: MSCP12-30 Timeout interval.



ECO #: MSCP12-30 2.2  Sequential Commands Waiting For I/O Rundown

ECO #: MSCP12-30 RCP would be 1, implying that the specified command will be  the  next
ECO #: MSCP12-30 command started.

ECO #: MSCP12-30 SCS would be an encoding of  the  amount  of  work  remaining  on  all
ECO #: MSCP12-30 started commands.



ECO #: MSCP12-30 2.3  Commands Waiting For The Completion Of A Sequential Command

ECO #: MSCP12-30 RCP would be the number of unstarted commands (+1) that will  have  to
ECO #: MSCP12-30 be started before this command is started.

ECO #: MSCP12-30 SCS would be the SCS value that  would  have  been  returned  for  the
ECO #: MSCP12-30 sequential command that is currently in progress.



ECO #: MSCP12-30 2.4  Commands Waiting For The Controller's Whim

ECO #: MSCP12-30 RCP  would  be  the  number  of  commands  (+1)  that  must  gain  the
ECO #: MSCP12-30 controllers whim, before this command will.

ECO #: MSCP12-30 SCS would be an encoding of  the  amount  of  work  remaining  on  all
ECO #: MSCP12-30 started commands.



ECO #: MSCP12-30 3  A PRACTICAL IMPLEMENTATION

ECO #: MSCP12-30 When the controller receives a new command it would initialize the RCP
ECO #: MSCP12-30 and SCS fields for the command to their maximum values (all bits set).
ECO #: MSCP12-30 At the same time the controller would initialize a copy  of  the  real
ECO #: MSCP12-30 Command Status field to reasonable maximum value.

ECO #: MSCP12-30 The controller should pick a reasonable maximum value for SCS; a week,
ECO #: MSCP12-30 a  day, an hour, 5 minutes, we can define a maximum period or leave it
ECO #: MSCP12-30 to the implementors.  (FYI - with a controller timeout interval of  50
ECO #: MSCP12-30 seconds, a day is contained in 11 bits, and 32 bits will hold 2 meg of
ECO #: MSCP12-30 days).

ECO #: MSCP12-30 When a  host  requests  status  on  a  command,  the  controller  then
ECO #: MSCP12-30 constructs  a  current  copy  of  RCP and SCS and compares them to the
ECO #: MSCP12-30 stored values.  (RCP is the high order  field).   If  the  constructed
ECO #: MSCP12-30 copy  is lower than the saved copy, then the real Command Status field
ECO #: MSCP12-30 is decremented.  Regardless, the new RCP and SCS values are stored  in
ECO #: MSCP12-30 									Page 7


ECO #: MSCP12-30 the controllers tables and the Command Status field is returned.

ECO #: MSCP12-30 In this manner, the host is told what he wants to  know,  whether  the
ECO #: MSCP12-30 command  he  is  asking about is any closer to being completed than it
ECO #: MSCP12-30 was the last time it asked about it.

ECO #: MSCP12-30 The controller timeout interval is then equal to or greater  than  the
ECO #: MSCP12-30 time  required to perform the longest atom of work as seen from inside
ECO #: MSCP12-30 the controller.

ECO #: MSCP12-30 This mechanism does require the host NOT to ask about the command more
ECO #: MSCP12-30 often than the controller timeout interval.

   <<End ECO #: MSCP12-30 Multi-Host Functionality>>


   <<ECO #: MSCP12-32 Maximum Byte Count [approved 10 August 1984]>> 


ECO #: MSCP12-32    Text of ECO Proposal

ECO #: MSCP12-32    Page, line, and section numbers refer  to  Mass  Storage  Control
ECO #: MSCP12-32    Protocol, Version 1.2, dated 08 Apr 82.

ECO #: MSCP12-32    While only the MSCP specification is referred to  directly,  this
ECO #: MSCP12-32    ECO is to apply to both disk MSCP and tape MSCP (TMSCP).

ECO #: MSCP12-32         1.  Section 4.10, "Command Timeouts", list item 1, page 4-25
ECO #: MSCP12-32             lines 38 through 48 inclusive.

ECO #: MSCP12-32             Delete this list item.

ECO #: MSCP12-32         2.  Section  5.3,   "Transfer   Command   Message   Format",
ECO #: MSCP12-32             description of "byte count" field, first paragraph, page
ECO #: MSCP12-32             5-6 lines 3 through 9.

ECO #: MSCP12-32             Replace this paragraph with the  following  text.   Note
ECO #: MSCP12-32             that  paragraph 3 (lines 30 through 39) on the same page
ECO #: MSCP12-32             was changed by ECO MSCP12-12,  "RCT  Access  Byte  Count
ECO #: MSCP12-32             Clarification".

ECO #: MSCP12-32                 The total requested length of the data  transfer  in
ECO #: MSCP12-32                 bytes.   This  length  must  meet both architectural
ECO #: MSCP12-32                 constraints and a server specified maximum.

ECO #: MSCP12-32                 An MSCP server returns the maximum byte  count  size
ECO #: MSCP12-32                 that    it    supports   in   the   SET   CONTROLLER
ECO #: MSCP12-32                 CHARACTERISTICS end message.  Class  drivers  should
ECO #: MSCP12-32                 not  issue  commands  with  larger byte counts.  The
ECO #: MSCP12-32                 server response to a command  whose  byte  count  is
ECO #: MSCP12-32                 larger than the server's maximum is undefined within
ECO #: MSCP12-32                 the following constraints:
ECO #: MSCP12-32 								Page 2

ECO #: MSCP12-32                 1.  The server may not destroy hardware  or  do  any
ECO #: MSCP12-32                     other  action  that  would require field service
ECO #: MSCP12-32                     attention.

ECO #: MSCP12-32                 2.  The  server  may  only  alter  host  memory   in
ECO #: MSCP12-32                     response  to  a READ command, and then only that
ECO #: MSCP12-32                     portion of host memory implied by the  command's
ECO #: MSCP12-32                     buffer descriptor and specified byte count.

ECO #: MSCP12-32                 3.  The server may only alter data on  the  unit  in
ECO #: MSCP12-32                     response  to  a WRITE or ERASE command, and then
ECO #: MSCP12-32                     only that portion of the  unit  implied  by  the
ECO #: MSCP12-32                     logical block number and specified byte count.

ECO #: MSCP12-32                 4.  Any error reported in the command's end  message
ECO #: MSCP12-32                     or  in  an  error log message must have actually
ECO #: MSCP12-32                     occurred at the position reported.

ECO #: MSCP12-32                 5.  With one exception, any other commands that  may
ECO #: MSCP12-32                     be  outstanding  at the same time as the command
ECO #: MSCP12-32                     whose  byte  count  is  too  large  may  not  be
ECO #: MSCP12-32                     affected.   The one exception is that the server
ECO #: MSCP12-32                     need not properly implement the command  timeout
ECO #: MSCP12-32                     algorithm  for any command, not just the command
ECO #: MSCP12-32                     whose byte count is too large.


ECO #: MSCP12-32                 Byte   counts   must   also   meet   the   following
ECO #: MSCP12-32                 architectural constraints, which vary depending upon
ECO #: MSCP12-32                 the device class.

ECO #: MSCP12-32                 For tape class devices, the  "byte  count"  must  be
ECO #: MSCP12-32                 larger  than  a format dependent minimum block size.
ECO #: MSCP12-32                 The command is rejected with  an  "Invalid  Command"
ECO #: MSCP12-32                 status  code and an "Invalid Byte Count" sub-code if
ECO #: MSCP12-32                 this requirement is not met.

ECO #: MSCP12-32                 For disk class devices, the requirements  depend  on
ECO #: MSCP12-32                 the contents of the "logical block number" field.

ECO #: MSCP12-32         3.  Section  5.3,   "Transfer   Command   Message   Format",
ECO #: MSCP12-32             description of "byte count" field, third paragraph, page
ECO #: MSCP12-32             5-7 line 10.

ECO #: MSCP12-32             Insert the word "architectural" immediately  before  the
ECO #: MSCP12-32             word "maximum".

ECO #: MSCP12-32         4.  Section 6.16, "SET CONTROLLER CHARACTERISTICS  Command",
ECO #: MSCP12-32             illustration  of end message format, page 6-44, lines 28
ECO #: MSCP12-32             through 43.

ECO #: MSCP12-32             Add the "maximum byte count" field at  the  end  of  the
ECO #: MSCP12-32             message so that it appears as follows:

ECO #: MSCP12-32                        31                             0 
ECO #: MSCP12-32 								Page 3

ECO #: MSCP12-32                        +-------------------------------+
ECO #: MSCP12-32                        |   command reference number    |
ECO #: MSCP12-32                        +---------------+---------------+
ECO #: MSCP12-32                        |   reserved    |    reserved   |
ECO #: MSCP12-32                        +---------------+-------+-------+
ECO #: MSCP12-32                        |    status     | flags |endcode|
ECO #: MSCP12-32                        +---------------+-------+-------+
ECO #: MSCP12-32                        | cntrlr. flags |  MSCP version |
ECO #: MSCP12-32                        +-------+-------+---------------+
ECO #: MSCP12-32                        |chvrsn | csvrsn|cntrlr. timeout|
ECO #: MSCP12-32                        +-------+-------+---------------+
ECO #: MSCP12-32                        |                               |
ECO #: MSCP12-32                        +---  controller identifier  ---+
ECO #: MSCP12-32                        |                               |
ECO #: MSCP12-32                        +-------------------------------+
ECO #: MSCP12-32 |                      | maximum byte count (optional) |
ECO #: MSCP12-32 |                      +-------------------------------+

ECO #: MSCP12-32         5.  Section 6.16, "SET CONTROLLER CHARACTERISTICS  Command",
ECO #: MSCP12-32             description of end message fields, page 6-45, line 29.

ECO #: MSCP12-32             Add the following field description:

ECO #: MSCP12-32             maximum byte count (optional)

ECO #: MSCP12-32                 The  maximum  byte  count  value  supported  by  the
ECO #: MSCP12-32                 server.   Class  drivers  should  not issue transfer
ECO #: MSCP12-32                 commands with byte counts larger  that  this  value;
ECO #: MSCP12-32                 byte counts equal to this value are supported.

ECO #: MSCP12-32                 This  value  must  be  at  least  as  large  as  the
ECO #: MSCP12-32                 following:

ECO #: MSCP12-32                  o  For  disk  class  devices,  16,777,216   (2**24)
ECO #: MSCP12-32                     bytes.

ECO #: MSCP12-32                  o  For tape class devices, 65535 (2**16-1) bytes.

ECO #: MSCP12-32                 That is, all servers must support transfers at least
ECO #: MSCP12-32                 as  large  as  the above values.  Support for longer
ECO #: MSCP12-32                 transfers is optional.

ECO #: MSCP12-32                 This field is  optional.   Class  drivers  determine
ECO #: MSCP12-32                 whether  or  not  this  field is included in the end
ECO #: MSCP12-32                 message by checking the message length  supplied  by
ECO #: MSCP12-32                 the  communications mechanism.  If this field is not
ECO #: MSCP12-32                 supplied, or if its  contents  are  zero,  then  the
ECO #: MSCP12-32                 server  supports  byte counts up to the values shown
ECO #: MSCP12-32                 in the previous paragraph.


   <<End ECO #: MSCP12-32 Maximum Byte Count>>


   <<ECO #: MSCP12-33 Controller Initiated Bad Block Replacement [approved as amended 10 August 1984]>> 

ECO #: MSCP12-33    Substitute the following for the current section 7.2:

ECO #: MSCP12-33    ************************************************************



ECO #: MSCP12-33    7.2  Controller Bad Block Replacement

ECO #: MSCP12-33    In Basic Disk MSCP, the disk MSCP server reports  bad  blocks  to
ECO #: MSCP12-33    the  class  driver,  and  the  class  driver  and/or an auxiliary
ECO #: MSCP12-33    process associated with it actually replaces the bad block.  With
ECO #: MSCP12-33    Controller  Bad  Block Replacement, the disk MSCP server replaces
ECO #: MSCP12-33    bad  blocks  itself,  transparent  to  the  class  driver.   This
ECO #: MSCP12-33    requires  that  the server also take over maintenance of the RCT,
ECO #: MSCP12-33    which contains replacement context information.

ECO #: MSCP12-33    Controller Bad Block Replacement does not apply to Tape MSCP,  as
ECO #: MSCP12-33    bad block replacement is not used on tape class devices.

ECO #: MSCP12-33    Conceptually, Controller Bad Block Replacement is implemented  by
ECO #: MSCP12-33    inserting  a  Controller  Bad Block Replacement layer between the
ECO #: MSCP12-33    Gatekeeper and Basic  MSCP  layers.   The  Controller  Bad  Block
ECO #: MSCP12-33    Replacement   layer   performs  bad  block  replacement  and  RCT
ECO #: MSCP12-33    maintenance by issuing Basic MSCP  requests  to  the  Basic  MSCP
ECO #: MSCP12-33    layer.   This  chapter describes the concepts that Controller Bad
ECO #: MSCP12-33    Block Replacement adds to Basic MSCP, the changes to MSCP control
ECO #: MSCP12-33    message  formats,  and  the algorithms used by the Controller Bad
ECO #: MSCP12-33    Block Replacement layer.  Actual  implementations  of  Controller
ECO #: MSCP12-33    Bad Block Replacement need not be a distinct layer or use exactly
ECO #: MSCP12-33    the algorithms given here, so long as all  class  driver  visible
ECO #: MSCP12-33    results are identical.
ECO #: MSCP12-33 								Page 2

ECO #: MSCP12-33                              Class Driver                        
ECO #: MSCP12-33                                   A                              
ECO #: MSCP12-33                                   |                              
ECO #: MSCP12-33                                   V                              
ECO #: MSCP12-33                / +----------------------------------+            
ECO #: MSCP12-33               /  |            Gatekeeper            |            
ECO #: MSCP12-33              /   +----------------------------------+            
ECO #: MSCP12-33      MSCP server | Controller Bad Block Replacement |            
ECO #: MSCP12-33              \   +----------------------------------+            
ECO #: MSCP12-33               \  |            Basic MSCP            |            
ECO #: MSCP12-33                \ +----------------------------------+            




ECO #: MSCP12-33    7.2.1  Write Protection -

ECO #: MSCP12-33    Basic MSCP has two forms of  write  protection.   Hardware  Write
ECO #: MSCP12-33    Protection   is   controlled   by  the  write  protect  mechanism
ECO #: MSCP12-33    associated with each unit.  Software Write Protection is  a  unit
ECO #: MSCP12-33    flag that can be set and cleared by the class driver.

ECO #: MSCP12-33    With Controller Bad Block Replacement,  there  is  an  additional
ECO #: MSCP12-33    form  called  Data  Safety  Write  Protection.  Data Safety Write
ECO #: MSCP12-33    Protection is in effect whenever the volume has  an  inconsistent
ECO #: MSCP12-33    RCT or a replacement has failed on the volume.  Its purpose is to
ECO #: MSCP12-33    protect the safety of data on such volumes,  as  they  cannot  be
ECO #: MSCP12-33    consistently accessed.

ECO #: MSCP12-33    When a unit is brought "Unit-Online", the  Controller  Bad  Block
ECO #: MSCP12-33    Replacement  layer  examines  block  0  of  the RCT to see if the
ECO #: MSCP12-33    volume must be Data Safety Write Protected.   If  so,  the  layer
ECO #: MSCP12-33    write  protects  the  unit and disables all bad block replacement
ECO #: MSCP12-33    attempts.  The layer provides read-only access to the unit  on  a
ECO #: MSCP12-33    "best  efforts"  basis, so that a host can copy the volume's data
ECO #: MSCP12-33    to a backup device.

ECO #: MSCP12-33    If a volume has an incomplete replacement attempt, and  its  unit
ECO #: MSCP12-33    is Hardware Write Protected when it is brought "Unit-Online", the
ECO #: MSCP12-33    Controller  Bad  Block  Replacement  layer  cannot  complete  the
ECO #: MSCP12-33    replacement attempt.  As an incomplete replacement attempt is one
ECO #: MSCP12-33    form of an inconsistent  RCT,  the  unit  is  Data  Safety  Write
ECO #: MSCP12-33    Protected   when  it  is  brought  "Unit-Online".   If  the  unit
ECO #: MSCP12-33    subsequently ceases to be Hardware  Write  Protected,  the  layer
ECO #: MSCP12-33    will  attempt  to  complete  the incomplete replacement.  If this
ECO #: MSCP12-33    succeeds, Data Safety Write Protection may  be  cleared  for  the
ECO #: MSCP12-33    unit.

ECO #: MSCP12-33    The only way to clear Data Safety  Write  Protection  due  to  an
ECO #: MSCP12-33    invalid RCT is to reformat the volume.
ECO #: MSCP12-33 								Page 3

ECO #: MSCP12-33    7.2.2  Bad Block Replacement -

ECO #: MSCP12-33    With Controller Bad Block Replacement, the MSCP  Server  performs
ECO #: MSCP12-33    all  bad  block  replacement.  At a minimum, the MSCP Server must
ECO #: MSCP12-33    replace the first bad block encountered by each transfer command.
ECO #: MSCP12-33    That  is,  the MSCP Server must replace all bad blocks that would
ECO #: MSCP12-33    have been reported in any end message's "first bad  block"  field
ECO #: MSCP12-33    with  Basic  MSCP.   Replacement  of  any  additional  bad blocks
ECO #: MSCP12-33    encountered by  a  transfer  is  strongly  recommended,  but  not
ECO #: MSCP12-33    required.

ECO #: MSCP12-33    Bad blocks can be detected by both  read  and  write  operations.
ECO #: MSCP12-33    For read operations, the success or failure of the read cannot be
ECO #: MSCP12-33    changed by retrying the read after  performing  the  replacement.
ECO #: MSCP12-33    However, with writes it is definitely possible (indeed, probable)
ECO #: MSCP12-33    that a write that fails before the replacement will succeed after
ECO #: MSCP12-33    the replacement.  Consider that most bad blocks detected on write
ECO #: MSCP12-33    operations will be due to  invalid  headers  --  defects  in  the
ECO #: MSCP12-33    header  area  of  a  sector.   A  write to such a block will fail
ECO #: MSCP12-33    before the replacement, but succeed afterwards.

ECO #: MSCP12-33    For this reason, if a write operation fails on a bad  block,  the
ECO #: MSCP12-33    Controller  Bad  Block  Replacement  layer  must  retry the write
ECO #: MSCP12-33    operation after replacing  the  block.   This  implies  that  the
ECO #: MSCP12-33    replacement  operation  must  be  performed  before  such a write
ECO #: MSCP12-33    command completes (i.e., before the end message is returned).  In
ECO #: MSCP12-33    all  other  cases,  however,  the  replacement  operation  may be
ECO #: MSCP12-33    asynchronous with respect  to  completion  of  the  command  that
ECO #: MSCP12-33    detected  the  bad  block.  That is, since the replacement cannot
ECO #: MSCP12-33    affect the success or failure of the command, the replacement may
ECO #: MSCP12-33    be performed either before or after the command completes.

ECO #: MSCP12-33    In addition to detecting bad blocks in transfers issued by  hosts
ECO #: MSCP12-33    or  higher  layers  in  the MSCP server, the Controller Bad Block
ECO #: MSCP12-33    Replacement layer may also check for  bad  blocks  spontaneously,
ECO #: MSCP12-33    without  receiving  any  actual  commands.  In effect, whenever a
ECO #: MSCP12-33    unit is "Unit-Online", the Controller Bad Block Replacement layer
ECO #: MSCP12-33    may  periodically  generate  reads  to  the unit.  Any bad blocks
ECO #: MSCP12-33    detected  by  such  internally  generated  transfers  should   be
ECO #: MSCP12-33    replaced,  exactly  the  same  as  if  the  read  were externally
ECO #: MSCP12-33    generated.

ECO #: MSCP12-33    Bad block replacement  cannot  be  performed  when  the  unit  is
ECO #: MSCP12-33    Hardware  Write  Protected.   If  a  bad  block  is detected on a
ECO #: MSCP12-33    Hardware Write Protected unit, replacement is not attempted.   If
ECO #: MSCP12-33    the  unit becomes Hardware Write Protected after the bad block is
ECO #: MSCP12-33    detected, but before the replacement is completed, some phase  of
ECO #: MSCP12-33    the  bad  block  replacement  algorithm  will  fail with a "Write
ECO #: MSCP12-33    Protect" error.  This error is handled  the  same  as  any  other
ECO #: MSCP12-33    failure   of   the  bad  block  replacement  algorithm;  see  the
ECO #: MSCP12-33    discussion below.
ECO #: MSCP12-33 								Page 4

ECO #: MSCP12-33    When both Basic MSCP and Controller  Bad  Block  Replacement  are
ECO #: MSCP12-33    implemented  in  the  same controller, it is strongly recommended
ECO #: MSCP12-33    that  the  controller  defer  recognition   of   Hardware   Write
ECO #: MSCP12-33    Protection   until   all   pending  replacement  operations  have
ECO #: MSCP12-33    completed.  That is, when an operator actuates the  unit's  write
ECO #: MSCP12-33    protect  mechanism,  the  controller  does  not  physically write
ECO #: MSCP12-33    protect the unit until after all previously detected  bad  blocks
ECO #: MSCP12-33    have  been replaced.  This is similar to the requirement in Basic
ECO #: MSCP12-33    MSCP of providing a smooth  transition  to  the  write  protected
ECO #: MSCP12-33    state (see Section 4.13, "Write Protection").

ECO #: MSCP12-33    Bad  block  replacement  must  be  performed  regardless  of  the
ECO #: MSCP12-33    Software  Write  Protect  status  of the unit.  If a bad block is
ECO #: MSCP12-33    detected  when  the  unit  is  Software  Write   Protected,   the
ECO #: MSCP12-33    Controller  Bad  Block  Replacement  layer  must write enable the
ECO #: MSCP12-33    unit, perform the replacement, then re-write  protect  the  unit.
ECO #: MSCP12-33    The  layer  must  guarantee  that  all host or higher layer write
ECO #: MSCP12-33    commands  are  still  rejected  in  spite  of  the   unit   being
ECO #: MSCP12-33    temporarily write enabled.

ECO #: MSCP12-33    Bad block replacement must not be attempted when the unit is Data
ECO #: MSCP12-33    Safety Write Protected or when the unit was brought "Unit-Online"
ECO #: MSCP12-33    with the "Ignore Media Format Error" modifier.

ECO #: MSCP12-33    If the unit is  Hardware  Write  Protected  when  it  is  brought
ECO #: MSCP12-33    "Unit-Online",  and  it  subsequently ceases to be Hardware Write
ECO #: MSCP12-33    Protected,  the  Controller  Bad  Block  Replacement  layer  must
ECO #: MSCP12-33    perform  certain  actions  before  it  attempts  a replacement or
ECO #: MSCP12-33    modifies the volume in any other way.  These actions are to  read
ECO #: MSCP12-33    and   re-write  RCT  block  0  and  attempting  to  complete  any
ECO #: MSCP12-33    incomplete replacement operation.  See  section  "Actions  Before
ECO #: MSCP12-33    First Modification".

ECO #: MSCP12-33    If a bad block replacement fails for any reason,  the  Controller
ECO #: MSCP12-33    Bad Block Replacement layer handles the failure as follows:

ECO #: MSCP12-33         1.  The status code returned for the command  that  detected
ECO #: MSCP12-33             the  bad block is not affected by the failed replacement
ECO #: MSCP12-33             attempt.  That is, the status code appropriate  for  the
ECO #: MSCP12-33             original access is returned.

ECO #: MSCP12-33         2.  The replacement failure is reported with  a  "Bad  Block
ECO #: MSCP12-33             Replacement Attempt" format error log message.

ECO #: MSCP12-33             Many of the errors that cause  replacement  failure  are
ECO #: MSCP12-33             themselves   reported  with  error  log  messages.   For
ECO #: MSCP12-33             example, failure of a multi-read or  multi-write  access
ECO #: MSCP12-33             to  the RCT produces at least two error log messages:  a
ECO #: MSCP12-33             (usually) "Disk Transfer Error"  message  reporting  the
ECO #: MSCP12-33             access  failure  and  a  separate "Bad Block Replacement
ECO #: MSCP12-33             Attempt" message reporting the replacement failure.  All
ECO #: MSCP12-33             such  error  log  messages  that  report  the cause of a
ECO #: MSCP12-33             replacement  failure  should  have  the  "Error   During
ECO #: MSCP12-33             Replacement"  error  log  flag  set  and  should be sent
ECO #: MSCP12-33 								Page 5

ECO #: MSCP12-33             before the "Bad Block  Replacement  Attempt"  error  log
ECO #: MSCP12-33             message.

ECO #: MSCP12-33         3.  The Controller Bad Block Replacement  layer  forces  the
ECO #: MSCP12-33             unit to become "Unit-Available" (or "Unit-Offline") with
ECO #: MSCP12-33             respect to all class drivers, exactly as if an AVAILABLE
ECO #: MSCP12-33             command  with  the "All Class Drivers" modifier had been
ECO #: MSCP12-33             issued.  This, of course, causes an AVAILABLE  Attention
ECO #: MSCP12-33             Message  to  be  sent  to  all  class  drivers that have
ECO #: MSCP12-33             enabled them.

ECO #: MSCP12-33             Note that Data Safety Write Protection will be in effect
ECO #: MSCP12-33             when  the  unit's  volume  is next brought "Unit-Online"
ECO #: MSCP12-33             (unless the problem is no longer present at that time).

ECO #: MSCP12-33         4.  Between  the  time  that  the   server   discovers   the
ECO #: MSCP12-33             replacement   failure   and   the  unit  completes  it's
ECO #: MSCP12-33             transition to "Unit-Available", the setting of the  Data
ECO #: MSCP12-33             Safety Write Protected unit flag is indeterminate.  This
ECO #: MSCP12-33             flag may be either set or clear if it is returned  to  a
ECO #: MSCP12-33             host during this interval.

ECO #: MSCP12-33         5.  Any pending bad block replacement attempts for the  unit
ECO #: MSCP12-33             are  discarded,  exactly  as  if  the unit had been Data
ECO #: MSCP12-33             Safety  Write  Protected  when  those  bad  blocks  were
ECO #: MSCP12-33             detected.  Error log messages or other notifications are
ECO #: MSCP12-33             not generated to report the dropped replacements.

ECO #: MSCP12-33         6.  No attempt is made to replace any additional bad  blocks
ECO #: MSCP12-33             that   may   be   detected   during  the  transition  to
ECO #: MSCP12-33             "Unit-Available", exactly  as  if  the  unit  were  Data
ECO #: MSCP12-33             Safety Write Protected.

ECO #: MSCP12-33         7.  Subject to the constraint of not attempting further  bad
ECO #: MSCP12-33             block   replacement,   the   server  must  complete  any
ECO #: MSCP12-33             outstanding commands that it has already initiated.  All
ECO #: MSCP12-33             new commands received after the replacement failure must
ECO #: MSCP12-33             be rejected.  Outstanding commands  that  have  not  yet
ECO #: MSCP12-33             been  initiated  may be completed or rejected.  Commands
ECO #: MSCP12-33             are rejected with a "Unit-Available"  or  "Unit-Offline"
ECO #: MSCP12-33             status code.


ECO #: MSCP12-33    The success or failure of read operations is not affected by  bad
ECO #: MSCP12-33    block  replacement  or the replacement's success or failure.  The
ECO #: MSCP12-33    status  code  reported  for  read  operations   is   the   status
ECO #: MSCP12-33    appropriate  to the original read attempt, before any replacement
ECO #: MSCP12-33    was performed.  The success or failure  of  write  operations  is
ECO #: MSCP12-33    affected  by  replacement,  since the write must be retried after
ECO #: MSCP12-33    the replacement is performed.  If the replacement  succeeds,  the
ECO #: MSCP12-33    status code reported is that appropriate to the retry (unless the
ECO #: MSCP12-33    retry  also  encounters  a  bad  block,  in  which  case  another
ECO #: MSCP12-33    replacement  and  another  retry  are  performed, and the process
ECO #: MSCP12-33    repeated until the retry does not encounter a bad block).  If the
ECO #: MSCP12-33 								Page 6

ECO #: MSCP12-33    replacement  fails,  the status code reported is that appropriate
ECO #: MSCP12-33    to  the  original  write  attempt  that  caused  the  bad   block
ECO #: MSCP12-33    replacement.   The  cause  of  a bad block replacement failure is
ECO #: MSCP12-33    only reported as an event code in an error  log  message;  it  is
ECO #: MSCP12-33    never reported as a status code in an end message.



ECO #: MSCP12-33    7.2.3  RCT Access -

ECO #: MSCP12-33    The Basic MSCP layer of an MSCP server must allow read and  write
ECO #: MSCP12-33    access to the RCT, as such access is required by higher layers in
ECO #: MSCP12-33    order  to  be  able  to  perform  bad  block  replacement.    The
ECO #: MSCP12-33    Controller  Bad  Block  Replacement  layer  need  not provide RCT
ECO #: MSCP12-33    access,  however,  since  it  implements  bad  block  replacement
ECO #: MSCP12-33    itself.

ECO #: MSCP12-33    Even though it is not necessary  for  the  Controller  Bad  Block
ECO #: MSCP12-33    Replacement  layer  to  provide  RCT  access, in many cases it is
ECO #: MSCP12-33    desirable to do so.  Providing  such  access  allows  a  host  to
ECO #: MSCP12-33    examine  certain additional information contained in RCT block 0.
ECO #: MSCP12-33    Also, since accessing a replacement block is usually slower  than
ECO #: MSCP12-33    accessing a good logical block, a host could use the RCT contents
ECO #: MSCP12-33    to allocate files with critical, real-time access requirements in
ECO #: MSCP12-33    portions of the volume that do not contain bad blocks.

ECO #: MSCP12-33    Therefore a server's Controller Bad Block Replacement layer  must
ECO #: MSCP12-33    provide  one of the following RCT access options.  The server may
ECO #: MSCP12-33    provide different options for different disk types.  The  options
ECO #: MSCP12-33    are:

ECO #: MSCP12-33         1.  No RCT access.  Any attempt to access any  block  inside
ECO #: MSCP12-33             the RCT will be rejected.

ECO #: MSCP12-33         2.  Read-only access to entire RCT.  Attempts  to  read  any
ECO #: MSCP12-33             block  in  the  first  copy  of the RCT will be honored.
ECO #: MSCP12-33             That is, a READ command with "logical block  number"  in
ECO #: MSCP12-33             the  range  "unit  size"  through  "unit size" plus "RCT
ECO #: MSCP12-33             size" minus one, inclusive, and "byte  count"  equal  to
ECO #: MSCP12-33             the  unit's  block  size  will  be  honored.   Any other
ECO #: MSCP12-33             attempt to access the RCT will be rejected.

ECO #: MSCP12-33    When an RCT access  attempt  is  rejected,  the  status  code  is
ECO #: MSCP12-33    "Invalid Command".  If the command is a READ command with a valid
ECO #: MSCP12-33    "logical block number", but the "byte count" is not equal to  the
ECO #: MSCP12-33    unit's  block  size,  then  the sub-code is "Invalid Byte Count".
ECO #: MSCP12-33    Otherwise  the  sub-code  is  "Invalid  Logical  Block   Number".
ECO #: MSCP12-33    Attempts  to  write the RCT are rejected with an "Invalid Logical
ECO #: MSCP12-33    Block Number" sub-code.

ECO #: MSCP12-33    Note that  option  2,  entire  RCT  access,  only  allows  access
ECO #: MSCP12-33    attempts  to the first copy of the RCT.  The Controller Bad Block
ECO #: MSCP12-33    Layer uses the multi-copy read algorithm to locate the proper RCT
ECO #: MSCP12-33    copy to use in satisfying the request.
ECO #: MSCP12-33 								Page 7

ECO #: MSCP12-33    The Controller Bad Block Replacement layer reports  which  option
ECO #: MSCP12-33    it  implements by altering the "RCT size" and "copies" parameters
ECO #: MSCP12-33    in the GET UNIT STATUS end message when it passes that message on
ECO #: MSCP12-33    to  higher  layers.  These parameters are altered to describe the
ECO #: MSCP12-33    host accessible portion of the RCT.  The actual  alterations  are
ECO #: MSCP12-33    as follows:

ECO #: MSCP12-33            RCT Access Option       "RCT size"       "copies"
ECO #: MSCP12-33            -----------------       ----------       --------

ECO #: MSCP12-33               No RCT access            0                0   

ECO #: MSCP12-33               Entire RCT        actual RCT size         1   


ECO #: MSCP12-33    It is recommended  that  high-functionality  controllers  provide
ECO #: MSCP12-33    access  to  the  entire  RCT.   Minimal, low-end controllers will
ECO #: MSCP12-33    probably provide no RCT access.  Note that any disk that  uses  a
ECO #: MSCP12-33    non-standard  means  of bad block replacement, and therefore does
ECO #: MSCP12-33    not have an RCT, appears identical to a disk that provides no RCT
ECO #: MSCP12-33    access.

ECO #: MSCP12-33    The Controller Bad Block Replacement layer may  optionally  allow
ECO #: MSCP12-33    additional  RCT  access when a unit is brought "Unit-Online" with
ECO #: MSCP12-33    the "Ignore Media  Format  Error"  modifier.   This  may  include
ECO #: MSCP12-33    read-write  access and/or access to individual copies of the RCT.
ECO #: MSCP12-33    The layer should ensure that the values returned for  "RCT  size"
ECO #: MSCP12-33    and  "copies"  reflect the RCT geometry presented to hosts.  Note
ECO #: MSCP12-33    that any additional access provided is  intended  for  diagnostic
ECO #: MSCP12-33    use,  and  is inherently controller dependent.  Attempts to write
ECO #: MSCP12-33    to the unit when the "Ignore Media  Format  Error"  modifier  has
ECO #: MSCP12-33    been  specified  may  have undefined results, including permanent
ECO #: MSCP12-33    corruption of the volume.  The errors produced by such corruption
ECO #: MSCP12-33    may be indistinguishable from device hardware failures.



ECO #: MSCP12-33    7.2.4  Atomic Bad Block Replacement -

ECO #: MSCP12-33    The Controller Bad Block Replacement layer must perform bad block
ECO #: MSCP12-33    replacement  operations  as  atomic operations.  That is, while a
ECO #: MSCP12-33    bad block replacement operation  is  in  progress,  any  transfer
ECO #: MSCP12-33    operations  for either the bad block being replaced or block 0 of
ECO #: MSCP12-33    the RCT must not be performed.  Such transfer operations must  be
ECO #: MSCP12-33    deferred  until  after  the  bad block replacement has completed.
ECO #: MSCP12-33    For  a  multi-block  transfer  that  includes  the  block   being
ECO #: MSCP12-33    replaced,  only  the transfer of the block being replaced need be
ECO #: MSCP12-33    deferred; the blocks before and after the one being replaced  may
ECO #: MSCP12-33    be transferred immediately.

ECO #: MSCP12-33    A bad block replacement operation begins just  before  the  "best
ECO #: MSCP12-33    guess"  data  is obtained for the block.  This is not necessarily
ECO #: MSCP12-33    the same transfer that detects the bad block and causes it to  be
ECO #: MSCP12-33    replaced.   The  bad  block replacement operation ends just after
ECO #: MSCP12-33 								Page 8

ECO #: MSCP12-33    RCT block 0 is updated to indicate that replacement is no  longer
ECO #: MSCP12-33    in  progress.   The  Controller  Bad Block Replacement layer must
ECO #: MSCP12-33    lock out all host and higher layer  access  to  the  block  being
ECO #: MSCP12-33    replaced and RCT block 0 between these two times.  Note that read
ECO #: MSCP12-33    access must be locked out as well as write access.



ECO #: MSCP12-33    7.2.5  Error Log Messages -

ECO #: MSCP12-33    Any error severe enough to warrant replacement  of  the  affected
ECO #: MSCP12-33    block  is,  by  definition,  a  "significant"  error that must be
ECO #: MSCP12-33    reported in an error log message.  The error log message must use
ECO #: MSCP12-33    the  "Disk  Transfer  Error"  format  or  some  other format that
ECO #: MSCP12-33    specifies the disk location at which  the  error  occurred.   The
ECO #: MSCP12-33    "Bad  Block  Replacement  Request"  error  log flag is set in the
ECO #: MSCP12-33    error log message to indicate that replacement of the block  will
ECO #: MSCP12-33    be  attempted.   When  the  replacement  attempt  completes,  the
ECO #: MSCP12-33    Controller Bad Block Replacement layer  generates  an  additional
ECO #: MSCP12-33    "Bad  Block  Replacement  Attempt"  format  error  log message to
ECO #: MSCP12-33    report the replacement attempt's success or failure.

ECO #: MSCP12-33    Due to its different error  characteristics,  controllers  should
ECO #: MSCP12-33    use  an  altered strategy for logging errors on RCT accesses.  In
ECO #: MSCP12-33    the host area of a disk, the most common errors are eliminated by
ECO #: MSCP12-33    bad  block  replacement.  Since bad block replacement is not used
ECO #: MSCP12-33    in the RCT, these common errors can be expected to occur, and are
ECO #: MSCP12-33    therefore relatively uninteresting for an error log.

ECO #: MSCP12-33    The goal for logging RCT errors is to  not  log  any  error  that
ECO #: MSCP12-33    would  cause bad block replacement in the host area.  Controllers
ECO #: MSCP12-33    that contain both Basic MSCP and Controller Bad Block Replacement
ECO #: MSCP12-33    can  do this precisely, since they know exactly which errors they
ECO #: MSCP12-33    use to trigger replacement.   Layered  controllers,  where  Basic
ECO #: MSCP12-33    MSCP  and Controller Bad Block Replacement are distinct, separate
ECO #: MSCP12-33    entities  can  only  approximate  this  by  filtering  out  "Data
ECO #: MSCP12-33    Errors".    That   is,   an   independent  Controller  Bad  Block
ECO #: MSCP12-33    Replacement layer should only  log  the  non-"Data  Errors"  that
ECO #: MSCP12-33    occur on RCT accesses.

ECO #: MSCP12-33    The one exception to not logging RCT "Data Errors" is when an RCT
ECO #: MSCP12-33    access  fails  --  that  is,  when  the multi-read or multi-write
ECO #: MSCP12-33    algorithms fail, indicating that the read or write failed to  all
ECO #: MSCP12-33    copies  of  the  RCT.   Whenever  the  multi-read  or multi-write
ECO #: MSCP12-33    algorithms fail, an error log message must be generated reporting
ECO #: MSCP12-33    the  error that occurred when the last RCT copy was accessed.  If
ECO #: MSCP12-33    this error is a "Data Error", its event code is  converted  to  a
ECO #: MSCP12-33    "Media  Format  Error"  with the same sub-code value before being
ECO #: MSCP12-33    reported in the error log message.  All other errors are reported
ECO #: MSCP12-33    without event code alteration.
ECO #: MSCP12-33 								Page 9

ECO #: MSCP12-33    Other than the altered strategy for  logging  RCT  "Data  Errors"
ECO #: MSCP12-33    described  above,  any errors resulting from accesses to the unit
ECO #: MSCP12-33    during bad block  replacement  are  logged  according  to  normal
ECO #: MSCP12-33    controller  policies.   The only change is that the "Error During
ECO #: MSCP12-33    Replacement" error log flag  should  be  set  in  such  messages,
ECO #: MSCP12-33    indicating  that  the  operation  was  requested by the bad block
ECO #: MSCP12-33    replacement process.  All such messages should be  issued  before
ECO #: MSCP12-33    the "Bad Block Replacement Attempt" format error log message that
ECO #: MSCP12-33    reports the replacement attempt's status.



ECO #: MSCP12-33    7.2.6  Unit Context Information -

ECO #: MSCP12-33    The  Controller  Bad  Block  Replacement  layer  must  separately
ECO #: MSCP12-33    maintain   the   following  unit  flags  for  each  unit  it  has
ECO #: MSCP12-33    "Unit-Online":

ECO #: MSCP12-33         Write Protected (software)
ECO #: MSCP12-33         Write Protected (data safety)

ECO #: MSCP12-33    The reason for this is that the Controller Bad Block  Replacement
ECO #: MSCP12-33    layer  sets  the  "Write  Protected  (software)" unit flag in the
ECO #: MSCP12-33    lower (Basic MSCP) layer if either of these flags are  set.   The
ECO #: MSCP12-33    replacement layer must keep track of these flags itself, in order
ECO #: MSCP12-33    to remember the reason(s) for write protecting the unit.

ECO #: MSCP12-33    The  Controller  Bad  Block  Replacement  layer  also   maintains
ECO #: MSCP12-33    internal, per unit, flags to record:

ECO #: MSCP12-33          o  The individual causes of Data Safety  Write  Protection.
ECO #: MSCP12-33             It   uses  these  flags  to  return  the  proper  status
ECO #: MSCP12-33             sub-codes.

ECO #: MSCP12-33          o  Whether or not RCT block 0 has been re-written  and  any
ECO #: MSCP12-33             incomplete   replacements   finished.    Normally  these
ECO #: MSCP12-33             actions  are  performed  when  the   unit   is   brought
ECO #: MSCP12-33             "Unit-Online".   However,  if the unit is Hardware Write
ECO #: MSCP12-33             Protected when it is brought "Unit-Online",  then  these
ECO #: MSCP12-33             actions  cannot  be performed.  Thus this flag is set to
ECO #: MSCP12-33             remember to perform these actions when or  if  the  unit
ECO #: MSCP12-33             subsequently  ceases  to  be  Hardware  Write Protected.
ECO #: MSCP12-33             This flag is further described in the sections  "Actions
ECO #: MSCP12-33             During ONLINE" and "Actions Before First Modification".

ECO #: MSCP12-33          o  Whether or not the "Ignore Media Format Error"  modifier
ECO #: MSCP12-33             was  specified  when the unit was brought "Unit-Online".
ECO #: MSCP12-33             It uses this flag to inhibit bad block replacement.
ECO #: MSCP12-33 								Page 10

ECO #: MSCP12-33    7.2.7  Actions During ONLINE -

ECO #: MSCP12-33    The Controller Bad Block Replacement layer performs two different
ECO #: MSCP12-33    courses  of action for an ONLINE command, depending on whether or
ECO #: MSCP12-33    not the  "Ignore  Media  Format  Error"  modifier  is  specified.
ECO #: MSCP12-33    Normally,  the  layer reads block 0 of the RCT to perform various
ECO #: MSCP12-33    volume consistency checks.  However, if the "Ignore Media  Format
ECO #: MSCP12-33    Error"  modifier is set, the layer does not access the RCT in any
ECO #: MSCP12-33    way.

ECO #: MSCP12-33    If an ONLINE command has the "Ignore Media Format Error" modifier
ECO #: MSCP12-33    specified,  the  Controller  Bad  Block  Replacement layer merely
ECO #: MSCP12-33    passes the  unmodified  command  on  to  the  Basic  MSCP  layer.
ECO #: MSCP12-33    Similarly,  it passes the unmodified response from the Basic MSCP
ECO #: MSCP12-33    layer back to the host or higher layer that issued  the  command.
ECO #: MSCP12-33    The layer's only additional action is to remember, in an internal
ECO #: MSCP12-33    flag,  that  the  "Ignore  Media  Format  Error"   modifier   was
ECO #: MSCP12-33    specified.    It   uses  this  flag  to  inhibit  all  bad  block
ECO #: MSCP12-33    replacement attempts and to optionally allow additional access to
ECO #: MSCP12-33    the RCT for diagnostics.

ECO #: MSCP12-33    When the "Ignore Media Format Error" modifier is  not  specified,
ECO #: MSCP12-33    the Controller Bad Block Replacement layer performs the following
ECO #: MSCP12-33    steps to process an ONLINE command:

ECO #: MSCP12-33         1.  Issue an ONLINE command to the Basic  MSCP  layer.   All
ECO #: MSCP12-33             fields  except the "modifiers" field are copied from the
ECO #: MSCP12-33             ONLINE command received by this layer.  The  "modifiers"
ECO #: MSCP12-33             field is constructed as follows:

ECO #: MSCP12-33             a.  The "Allow Self Destruction" modifier is copied from
ECO #: MSCP12-33                 the received command.

ECO #: MSCP12-33             b.  The "Exclusive Access" modifier is set.

ECO #: MSCP12-33             c.  All other modifiers are clear.


ECO #: MSCP12-33             If the Basic MSCP ONLINE fails, return its  end  message
ECO #: MSCP12-33             as  the  result of this layer's ONLINE and exit.  If the
ECO #: MSCP12-33             Basic MSCP ONLINE  reports  that  the  unit  is  already
ECO #: MSCP12-33             "Unit-Online",  the ONLINE has succeeded.  Again, return
ECO #: MSCP12-33             its end message as the result of this layer's ONLINE and
ECO #: MSCP12-33             exit.   Otherwise  save its end message as the prototype
ECO #: MSCP12-33             for this layer's ONLINE end message.

ECO #: MSCP12-33         2.  Read block  0  of  the  RCT  with  the  multi-copy  read
ECO #: MSCP12-33             algorithm.   If  the  multi-copy  read  algorithm fails,
ECO #: MSCP12-33             report its result as the status of this ONLINE and exit.

ECO #: MSCP12-33         3.  If the unit is Hardware Write Protected, set an internal
ECO #: MSCP12-33             flag  and  go to step 6.  This flag is further described
ECO #: MSCP12-33             in section "Actions Before First Modification".
ECO #: MSCP12-33 								Page 11

ECO #: MSCP12-33         4.  Write the data read by step 2 back out to block 0 of the
ECO #: MSCP12-33             RCT   with  the  multi-copy  write  algorithm.   If  the
ECO #: MSCP12-33             multi-copy write algorithm fails, report its  result  as
ECO #: MSCP12-33             the status of this ONLINE and exit.

ECO #: MSCP12-33         5.  If the data read by step 2 indicates that  there  is  an
ECO #: MSCP12-33             incomplete  bad block replacement on the volume, attempt
ECO #: MSCP12-33             to complete it.  If the completion attempt fails, report
ECO #: MSCP12-33             it  with  an  error log message.  Continue with the next
ECO #: MSCP12-33             step  regardless  of  whether  the  completion   attempt
ECO #: MSCP12-33             succeeds or fails.

ECO #: MSCP12-33         6.  Examine the contents of RCT block 0, as read in  step  2
ECO #: MSCP12-33             and  possibly  modified  in  step  5.   If  there  is an
ECO #: MSCP12-33             incomplete bad block replacement attempt or the  RCT  is
ECO #: MSCP12-33             invalid, set the "Write Protect (data safety)" unit flag
ECO #: MSCP12-33             in the unit's context.  The checks,  if  any,  that  the
ECO #: MSCP12-33             controller  performs  to  verify  the RCT's validity are
ECO #: MSCP12-33             specified by the DEC Standard  Disk  Format  and/or  the
ECO #: MSCP12-33             controller's functional specification.

ECO #: MSCP12-33         7.  If the "Enable Set Write Protect" modifier  was  set  in
ECO #: MSCP12-33             the  original  ONLINE  command  received from the higher
ECO #: MSCP12-33             layer, then copy the "Write Protected  (software)"  unit
ECO #: MSCP12-33             flag from the original command to the unit's context.

ECO #: MSCP12-33         8.  If either of the "Write Protect (data safety)" or "Write
ECO #: MSCP12-33             Protect  (software)"  unit  flags  are set in the unit's
ECO #: MSCP12-33             context, issue a SET UNIT CHARACTERISTICS command to the
ECO #: MSCP12-33             Basic MSCP layer to software write protect the unit.  If
ECO #: MSCP12-33             the command fails, report its status as  the  status  of
ECO #: MSCP12-33             this ONLINE and exit.

ECO #: MSCP12-33         9.  The ONLINE operation has completed  successfully.   Copy
ECO #: MSCP12-33             the  "Write  Protect  (data  safety)" and "Write Protect
ECO #: MSCP12-33             (software)" unit flags from this unit's context  to  the
ECO #: MSCP12-33             prototype  end  message saved in step 1.  If the unit is
ECO #: MSCP12-33             Data Safety Write Protected, set the appropriate  status
ECO #: MSCP12-33             sub-codes.  Return the resulting end message to the host
ECO #: MSCP12-33             or higher layer.


ECO #: MSCP12-33    If the ONLINE  operation  fails,  clean-up  may  or  may  not  be
ECO #: MSCP12-33    necessary, depending on where the failure occurs.  If the failure
ECO #: MSCP12-33    occurs in step 1 (the ONLINE command to the  Basic  MSCP  layer),
ECO #: MSCP12-33    the  unit will not be "Unit-Online" through the Basic MSCP layer,
ECO #: MSCP12-33    so no clean-up is necessary.   If  the  failure  occurs  anywhere
ECO #: MSCP12-33    else,  the  Controller  Bad Block Replacement layer must issue an
ECO #: MSCP12-33    AVAILABLE command with the "Spin-down" modifier set to the  Basic
ECO #: MSCP12-33    MSCP layer, since the unit may still be "Unit-Online" through the
ECO #: MSCP12-33    Basic MSCP layer.
ECO #: MSCP12-33 								Page 12


ECO #: MSCP12-33    As part of bringing a  unit  "Unit-Online",  the  Controller  Bad
ECO #: MSCP12-33    Block  Replacement  layer  attempts  to  complete  any incomplete
ECO #: MSCP12-33    replacement on the volume.  If the unit  is  not  Hardware  Write
ECO #: MSCP12-33    Protected, the attempt is made as part of the ONLINE command.  If
ECO #: MSCP12-33    the unit is Hardware Write Protected, the attempt is  made  after
ECO #: MSCP12-33    the  unit ceases to be Hardware Write Protected and no later than
ECO #: MSCP12-33    the first attempt to write to the unit  or  the  first  SET  UNIT
ECO #: MSCP12-33    CHARACTERISTICS  command  after  the  unit  ceases to be Hardware
ECO #: MSCP12-33    Write Protected.  This is discussed in  section  "Actions  Before
ECO #: MSCP12-33    First  Modification".   In either case, there is only one attempt
ECO #: MSCP12-33    to complete the replacement.  If that one attempt fails, no other
ECO #: MSCP12-33    attempt  will  be  made until the next time the volume is brought
ECO #: MSCP12-33    "Unit-Online".



ECO #: MSCP12-33    7.2.8  Actions During SET UNIT CHARACTERISTICS -

ECO #: MSCP12-33    The Controller Bad Block Replacement layer performs the following
ECO #: MSCP12-33    steps to process a SET UNIT CHARACTERISTICS command:

ECO #: MSCP12-33         1.  If the internal flag is set indicating that the unit was
ECO #: MSCP12-33             Hardware   Write   Protected   when   it   was   brought
ECO #: MSCP12-33             "Unit-Online",  and  it  is  no  longer  Hardware  Write
ECO #: MSCP12-33             Protected,  perform  the  actions  described  in section
ECO #: MSCP12-33             "Actions Before First Modification" and clear the  flag.
ECO #: MSCP12-33             If those actions fail, report their result as the status
ECO #: MSCP12-33             of this SET UNIT CHARACTERISTICS and  exit.   Note  that
ECO #: MSCP12-33             this  step  may  clear the "Write Protect (data safety)"
ECO #: MSCP12-33             unit flag in the unit's context.

ECO #: MSCP12-33         2.  If the "Enable Set Write Protect" modifier  was  set  in
ECO #: MSCP12-33             the  original  SET UNIT CHARACTERISTICS command received
ECO #: MSCP12-33             from the higher layer, then copy  the  "Write  Protected
ECO #: MSCP12-33             (software)"  unit  flag from the original command to the
ECO #: MSCP12-33             unit's context.

ECO #: MSCP12-33         3.  Issue a SET UNIT CHARACTERISTICS command  to  the  Basic
ECO #: MSCP12-33             MSCP  layer.   The  command is identical to the original
ECO #: MSCP12-33             SET  UNIT  CHARACTERISTICS  command  received  from  the
ECO #: MSCP12-33             higher layer with the following changes:

ECO #: MSCP12-33             a.  The "Enable Set Write Protect"  modifier  is  always
ECO #: MSCP12-33                 set.

ECO #: MSCP12-33             b.  The "Write Protect (software)" unit flag is  set  to
ECO #: MSCP12-33                 the   inclusive-or   of  the  "Write  Protect  (data
ECO #: MSCP12-33                 safety)" and "Write Protect (software)"  unit  flags
ECO #: MSCP12-33                 in the unit's context.

ECO #: MSCP12-33             If the command fails, report its status as the status of
ECO #: MSCP12-33             this SET UNIT CHARACTERISTICS and exit.
ECO #: MSCP12-33 								Page 13


ECO #: MSCP12-33         4.  The SET UNIT  CHARACTERISTICS  operation  has  completed
ECO #: MSCP12-33             successfully.   Copy  the  "Write Protect (data safety)"
ECO #: MSCP12-33             and "Write Protect  (software)"  unit  flags  from  this
ECO #: MSCP12-33             unit's  context  to  the  end  message  returned  in the
ECO #: MSCP12-33             previous  step.   If  the  unit  is  Data  Safety  Write
ECO #: MSCP12-33             Protected, set the appropriate status sub-codes.  Return
ECO #: MSCP12-33             the resulting end message to the host or higher layer.


ECO #: MSCP12-33    If the SET UNIT CHARACTERISTICS operation fails for  any  reason,
ECO #: MSCP12-33    the   Controller  Bad  Block  Replacement  layer  must  issue  an
ECO #: MSCP12-33    AVAILABLE command with all modifiers  clear  to  the  Basic  MSCP
ECO #: MSCP12-33    layer  and  send  an  AVAILABLE attention message to the host and
ECO #: MSCP12-33    higher layers.  This is necessary to preserve the rule  that  the
ECO #: MSCP12-33    unit may not be left "Unit-Online" if a command that might change
ECO #: MSCP12-33    the unit's context fails.



ECO #: MSCP12-33    7.2.9  Actions Before First Modification -

ECO #: MSCP12-33    As part of bringing a  unit  "Unit-Online",  the  Controller  Bad
ECO #: MSCP12-33    Block  Replacement  layer  reads  and re-writes RCT block 0.  The
ECO #: MSCP12-33    reason for this is that, when the volume was last in  use,  there
ECO #: MSCP12-33    may  have  been  a  failure after some copies of RCT block 0 were
ECO #: MSCP12-33    written but before all of them were written.  If  this  situation
ECO #: MSCP12-33    were  to  occur,  a  transient  or inconsistent error could cause
ECO #: MSCP12-33    successive reads of RCT block 0 to return different data, as data
ECO #: MSCP12-33    was  returned  from  different copies.  By reading and re-writing
ECO #: MSCP12-33    block 0 the layer ensures that all copies contain the same  data,
ECO #: MSCP12-33    so that successive reads will always return the same results.

ECO #: MSCP12-33    However, if the unit is  Hardware  Write  Protected  when  it  is
ECO #: MSCP12-33    brought "Unit-Online", this problem can still occur since block 0
ECO #: MSCP12-33    cannot be re-written.  So long as the unit remains Hardware Write
ECO #: MSCP12-33    Protected,  no  problems  can  occur,  since the volume cannot be
ECO #: MSCP12-33    modified.  However, if the  unit  ceases  to  be  Hardware  Write
ECO #: MSCP12-33    Protected, volume modification becomes possible.  If this occurs,
ECO #: MSCP12-33    RCT block 0 must be  read  and  re-written  prior  to  the  first
ECO #: MSCP12-33    modification.

ECO #: MSCP12-33    When a unit is brought "Unit-Online", the  Controller  Bad  Block
ECO #: MSCP12-33    Replacement  layer  sets an internal flag if the unit is Hardware
ECO #: MSCP12-33    Write Protected and RCT block 0 cannot be re-written.  This  flag
ECO #: MSCP12-33    must  be  checked  when a host or higher layer attempts to modify
ECO #: MSCP12-33    the volume and,  if  it  is  set,  the  actions  described  below
ECO #: MSCP12-33    performed.  There are three ways that the volume may be modified:

ECO #: MSCP12-33         1.  Bad block replacement.  The actions below are  performed
ECO #: MSCP12-33             after  checking  that  the  unit  is  not Hardware Write
ECO #: MSCP12-33             Protected, but before  checking  if  the  unit  is  Data
ECO #: MSCP12-33             Safety  Write Protected or modifying the RCT in any way.
ECO #: MSCP12-33             That is, these actions are performed after the bad block
ECO #: MSCP12-33             is   detected  but  before  the  bad  block  replacement
ECO #: MSCP12-33 								Page 14


ECO #: MSCP12-33             algorithm is initiated.

ECO #: MSCP12-33         2.  A SET UNIT CHARACTERISTICS command.  The point at  which
ECO #: MSCP12-33             the  actions below are performed is described in section
ECO #: MSCP12-33             "Actions During SET UNIT CHARACTERISTICS".

ECO #: MSCP12-33         3.  A host or higher layer  write  operation.   The  actions
ECO #: MSCP12-33             below  are performed after checking that the unit is not
ECO #: MSCP12-33             Hardware or Software  Write  Protected  but  before  any
ECO #: MSCP12-33             modification is performed on the unit.


ECO #: MSCP12-33    The Controller Bad Block Replacement layer need not wait until  a
ECO #: MSCP12-33    modification  is  attempted.   It  may  perform the actions below
ECO #: MSCP12-33    spontaneously  upon  the  unit  ceasing  to  be  Hardware   Write
ECO #: MSCP12-33    Protected.  From the viewpoint of a host or higher layer, this is
ECO #: MSCP12-33    no different from the actions below being performed  in  response
ECO #: MSCP12-33    to an attempted bad block replacement.

ECO #: MSCP12-33    The actions that must be performed before the first  modification
ECO #: MSCP12-33    are:

ECO #: MSCP12-33         1.  Check the internal flag discussed above.  If the flag is
ECO #: MSCP12-33             clear,  proceed  with  the modification.  If the flag is
ECO #: MSCP12-33             set, clear it and continue with the next step.

ECO #: MSCP12-33         2.  Read block  0  of  the  RCT  with  the  multi-copy  read
ECO #: MSCP12-33             algorithm.   If  the  multi-copy  read  algorithm fails,
ECO #: MSCP12-33             exit.

ECO #: MSCP12-33         3.  Check the internal flags recording the reasons, if  any,
ECO #: MSCP12-33             for  the unit being Data Safety Write Protected.  If the
ECO #: MSCP12-33             incomplete replacement flag is  clear,  then  clear  the
ECO #: MSCP12-33             incomplete  replacement  flags  in  RCT block 0.  If the
ECO #: MSCP12-33             invalid RCT flag is clear, implying  that  the  RCT  was
ECO #: MSCP12-33             valid  when  the unit was brought "Unit-Online", yet the
ECO #: MSCP12-33             current RCT image is  not  valid,  either  exit  with  a
ECO #: MSCP12-33             "Media  Format  Error"  or  "fix"  the  invalid RCT.  An
ECO #: MSCP12-33             example of "fixing" the RCT is zeroing a reserved  field
ECO #: MSCP12-33             that  was  zero when the unit was brought "Unit-Online",
ECO #: MSCP12-33             but that is now non-zero.

ECO #: MSCP12-33         4.  Write RCT block 0 with the value  read  in  step  2  and
ECO #: MSCP12-33             possibly  modified in step 3, using the multi-copy write
ECO #: MSCP12-33             algorithm.  If the  multi-copy  write  algorithm  fails,
ECO #: MSCP12-33             exit.

ECO #: MSCP12-33         5.  If the value just written to RCT block 0 indicates there
ECO #: MSCP12-33             is  an  incomplete  bad block replacement on the volume,
ECO #: MSCP12-33             attempt to  complete  it.   If  the  completion  attempt
ECO #: MSCP12-33             fails, report it with an error log message and continue.
ECO #: MSCP12-33 								Page 15


ECO #: MSCP12-33         6.  Set the "Write Protected (data safety)" unit flag to the
ECO #: MSCP12-33             inclusive-or of all internal flags representing possible
ECO #: MSCP12-33             causes of Data Safety Write Protection.

ECO #: MSCP12-33         7.  Issue a SET UNIT CHARACTERISTICS command  to  the  Basic
ECO #: MSCP12-33             MSCP  layer  to  set  the  unit's Software Write Protect
ECO #: MSCP12-33             status to the inclusive-or of the "Write  Protect  (data
ECO #: MSCP12-33             safety)"  and  "Write  Protect (software)" unit flags in
ECO #: MSCP12-33             the unit's context.  If the command fails, exit.

ECO #: MSCP12-33         8.  This  algorithm  has  completed.    Proceed   with   the
ECO #: MSCP12-33             modification attempt that caused it to be invoked.


ECO #: MSCP12-33    There are four places where this algorithm can  fail.   They  are
ECO #: MSCP12-33    the  multi-copy read operation in step 2, the attempt to "fix" an
ECO #: MSCP12-33    invalid RCT in step 3, the multi-copy write in step  4,  and  the
ECO #: MSCP12-33    SET  UNIT  CHARACTERISTICS  in step 7.  If the algorithm fails at
ECO #: MSCP12-33    one of these steps,  the  modification  attempt  fails  with  the
ECO #: MSCP12-33    status  code  resulting  from the failed step.  Also, the unit is
ECO #: MSCP12-33    forced "Unit-Available" to all class drivers.   The  handling  of
ECO #: MSCP12-33    other commands that may be outstanding is identical to that which
ECO #: MSCP12-33    is done for a failed replacement operation.

ECO #: MSCP12-33    Note that execution of  the  above  procedure  may  complete  the
ECO #: MSCP12-33    incomplete  replacement that was causing a unit to be Data Safety
ECO #: MSCP12-33    Write Protected.  This yields the possibility  that  Data  Safety
ECO #: MSCP12-33    Write  Protection may disappear spontaneously, as the result of a
ECO #: MSCP12-33    bad block replacement.



ECO #: MSCP12-33    7.2.10  Control Message Format Changes -

ECO #: MSCP12-33    This section describes the changes  in  control  message  formats
ECO #: MSCP12-33    between  Basic  Disk  MSCP  and  MSCP  with  Controller Bad Block
ECO #: MSCP12-33    Replacement.  All messages and fields that are not  mentioned  in
ECO #: MSCP12-33    this section are identical in the two MSCP variations.



ECO #: MSCP12-33    7.2.10.1  Unit Flags -

ECO #: MSCP12-33    The Controller Bad Block Replacement unit flag is always returned
ECO #: MSCP12-33    set, rather than being returned clear.

ECO #: MSCP12-33    A new "Write Protect (data safety)" unit flag is added to  report
ECO #: MSCP12-33    the unit's Data Safety Write Protect status.
ECO #: MSCP12-33 								Page 16


ECO #: MSCP12-33    7.2.10.2  Controller Flags -

ECO #: MSCP12-33    The Controller Bad Block Replacement controller flag is  returned
ECO #: MSCP12-33    set  if  the  server supports Controller Bad Block Replacement on
ECO #: MSCP12-33    all disk types that can  be  connected  to  it.   (A  server  may
ECO #: MSCP12-33    implement replacement on some disk types but not on others).



ECO #: MSCP12-33    7.2.10.3  Transfer Commands -

ECO #: MSCP12-33    The changes described  in  this  section  apply  to  the  ACCESS,
ECO #: MSCP12-33    COMPARE HOST DATA, ERASE, READ, and WRITE commands.

ECO #: MSCP12-33    The meaning of transfers addressed to the RCT portion of the disk
ECO #: MSCP12-33    is   substantially   changed;  see  section  "RCT  Access".   For
ECO #: MSCP12-33    transfers addressed to the host area of the disk, the only change
ECO #: MSCP12-33    is that the controller itself replaces bad blocks rather than the
ECO #: MSCP12-33    host.

ECO #: MSCP12-33    Since the controller is replacing  bad  blocks,  the  "Bad  Block
ECO #: MSCP12-33    Reported"  end  flag will always be clear and the contents of the
ECO #: MSCP12-33    "first bad block" end message field  will  always  be  undefined.
ECO #: MSCP12-33    The  "Bad  Block  Unreported"  end  flag  is set, however, if the
ECO #: MSCP12-33    transfer encountered one or more bad blocks.  The specific blocks
ECO #: MSCP12-33    that  were  bad and the results of their replacement are reported
ECO #: MSCP12-33    in the error log.



ECO #: MSCP12-33    7.2.10.4  ONLINE and SET UNIT CHARACTERISTICS Commands -

ECO #: MSCP12-33    Modifiers:

ECO #: MSCP12-33        The "Ignore Media Format  Error"  modifier  is  changed  from
ECO #: MSCP12-33        Basic  MSCP.   Note that this modifier is only allowed on the
ECO #: MSCP12-33        ONLINE command.  Its revised meansing is as follows:

ECO #: MSCP12-33        Ignore Media Format Error

ECO #: MSCP12-33            This modifier is only allowed on the ONLINE command.   In
ECO #: MSCP12-33            Basic  MSCP,  this  modifier  suppresses  media  (volume)
ECO #: MSCP12-33            format validity  checking.   With  Controller  Bad  Block
ECO #: MSCP12-33            Replacement, this modifier also suppresses the RCT checks
ECO #: MSCP12-33            normally performed when a unit is brought "Unit-Online".

ECO #: MSCP12-33            Normally, when a unit is brought "Unit-Online", the  MSCP
ECO #: MSCP12-33            server  makes  several  accesses  to  the unit.  In Basic
ECO #: MSCP12-33            MSCP,  these  accesses  merely   verify   volume   format
ECO #: MSCP12-33            validity.   With  Controller  Bad  Block Replacement, the
ECO #: MSCP12-33            MSCP server also accesses the RCT to  check  the  context
ECO #: MSCP12-33            information stored there.  If any of these accesses fail,
ECO #: MSCP12-33            the unit cannot be  brought  "Unit-Online"  and  a  Media
ECO #: MSCP12-33            Format  Error  is returned.  This modifier suppresses all
ECO #: MSCP12-33 								Page 17


ECO #: MSCP12-33            accesses performed when bringing the unit  "Unit-Online",
ECO #: MSCP12-33            thus  allowing  it to be brought "Unit-Online" when these
ECO #: MSCP12-33            accesses would fail.  The penalty for using this modifier
ECO #: MSCP12-33            is that data on the volume may be corrupted.

ECO #: MSCP12-33            The exact checks that are  suppressed  by  this  modifier
ECO #: MSCP12-33            are:

ECO #: MSCP12-33            1.  The format validity checks done by Basic MSCP.

ECO #: MSCP12-33            2.  Checking for  an  incomplete  bad  block  replacement
ECO #: MSCP12-33                operation, and completing it if possible.

ECO #: MSCP12-33            The unit is always brought "Unit-Online" with Data Safety
ECO #: MSCP12-33            Write Protection disabled (i.e., writes allowed).

ECO #: MSCP12-33            Specifying  this  modifier   inhibits   all   bad   block
ECO #: MSCP12-33            replacement   attempts   and   may   optionally   provide
ECO #: MSCP12-33            additional access to the RCT.

ECO #: MSCP12-33            Note that these checks exist  to  prevent  data  loss  or
ECO #: MSCP12-33            corruption.   Therefore this modifier should only be used
ECO #: MSCP12-33            in exceptional circumstances, such as backing up a  known
ECO #: MSCP12-33            bad  disk.   In particular, the results of any attempt to
ECO #: MSCP12-33            write to the unit are undefined when  this  modifier  has
ECO #: MSCP12-33            been specified.


ECO #: MSCP12-33    Status Codes:

ECO #: MSCP12-33        The  following  new  sub-codes  may  be  returned  with   the
ECO #: MSCP12-33        "Success"   status   code   for   the  ONLINE  and  SET  UNIT
ECO #: MSCP12-33        CHARACTERISTICS commands.  Remember that  the  sub-codes  are
ECO #: MSCP12-33        bit   flags,   and  that  the  sub-code  field  contains  the
ECO #: MSCP12-33        logical-or  of  all  applicable  sub-codes,   including   the
ECO #: MSCP12-33        sub-codes defined in Basic MSCP.

ECO #: MSCP12-33        Success (sub-code "Incomplete Replacement")

ECO #: MSCP12-33            The  volume  has  a   partially   completed   bad   block
ECO #: MSCP12-33            replacement operation, and the attempt to complete it did
ECO #: MSCP12-33            not succeed.  The  cause  of  the  attempt's  failure  is
ECO #: MSCP12-33            reported with an error log message.  This sub-code merely
ECO #: MSCP12-33            reports that there is a partially  completed  replacement
ECO #: MSCP12-33            on  the  volume.   Note that the unit will be Data Safety
ECO #: MSCP12-33            Write Protected whenever this sub-code is returned.


ECO #: MSCP12-33        Success (sub-code "Invalid RCT")

ECO #: MSCP12-33            The volume has an invalid RCT or,  if  the  disk  uses  a
ECO #: MSCP12-33            non-standard  means  of  bad block replacement, some data
ECO #: MSCP12-33            structure  used  to  control  bad  block  replacement  is
ECO #: MSCP12-33            invalid.    The  checks,  if  any,  that  the  controller
ECO #: MSCP12-33 								Page 18


ECO #: MSCP12-33            performs to verify the RCT's validity  are  specified  by
ECO #: MSCP12-33            the  DEC  Standard  Disk  Format  and/or the controller's
ECO #: MSCP12-33            functional specification.  Note that  the  unit  will  be
ECO #: MSCP12-33            Data  Safety  Write  Protected  whenever this sub-code is
ECO #: MSCP12-33            returned.


ECO #: MSCP12-33        "Media  Format  Errors"  may  be  reported   for   SET   UNIT
ECO #: MSCP12-33        CHARACTERISTICS, which could not happen with Basic MSCP.



ECO #: MSCP12-33    7.2.10.5  GET UNIT STATUS Command -

ECO #: MSCP12-33    End Message Fields:

ECO #: MSCP12-33        RCT size
ECO #: MSCP12-33        copies

ECO #: MSCP12-33            The  interpretation  and  meaning  of  these  fields   is
ECO #: MSCP12-33            identical  to  Basic  MSCP.  However, the values returned
ECO #: MSCP12-33            are altered as described in Section "RCT Access".


ECO #: MSCP12-33    Status Codes:

ECO #: MSCP12-33        The  following  new  sub-codes  may  be  returned  with   the
ECO #: MSCP12-33        "Success"  status  code  for  the  GET  UNIT STATUS commands.
ECO #: MSCP12-33        These sub-codes are identical to the new  sub-codes  returned
ECO #: MSCP12-33        for the ONLINE and SET UNIT CHARACTERISTICS commands; see the
ECO #: MSCP12-33        previous section for their description.   Remember  that  the
ECO #: MSCP12-33        sub-codes are bit flags, and that the sub-code field contains
ECO #: MSCP12-33        the logical-or of all  applicable  sub-codes,  including  the
ECO #: MSCP12-33        sub-codes defined in Basic MSCP.

ECO #: MSCP12-33        Success (sub-code "Incomplete Replacement")

ECO #: MSCP12-33        Success (sub-code "Invalid RCT")




ECO #: MSCP12-33    7.2.10.6  REPLACE Command -

ECO #: MSCP12-33    This command is illegal with Controller  Bad  Block  Replacement.
ECO #: MSCP12-33    As  its  sole  use  is  to  allow  hosts  to  perform  bad  block
ECO #: MSCP12-33    replacement, it is no longer needed.  This  command,  if  issued,
ECO #: MSCP12-33    results  in  an  Invalid Command end message with the status code
ECO #: MSCP12-33    indicating an invalid opcode.
ECO #: MSCP12-33 								Page 19


ECO #: MSCP12-33    7.2.11  Host Support for Controller Bad Block Replacement -

ECO #: MSCP12-33    The only specialized support that host class drivers must provide
ECO #: MSCP12-33    for  Controller  Bad  Block  Replacement  is at the time the host
ECO #: MSCP12-33    brings a unit "Unit-Online".  That  is,  these  actions  must  be
ECO #: MSCP12-33    performed  immediately  after  the ONLINE command completes.  The
ECO #: MSCP12-33    specific actions are:

ECO #: MSCP12-33         1.  Check the "Controller Initiated Bad  Block  Replacement"
ECO #: MSCP12-33             unit flag.  If this flag is clear, the class driver must
ECO #: MSCP12-33             examine  the  RCT  for  an  incomplete  replacement  and
ECO #: MSCP12-33             complete it if one is present.  If this flag is set, the
ECO #: MSCP12-33             class driver must skip this  step,  as  the  server  has
ECO #: MSCP12-33             already performed it.

ECO #: MSCP12-33         2.  If either of the "Incomplete  Replacement"  or  "Invalid
ECO #: MSCP12-33             RCT"  sub-code  flags  is set, report the problem to the
ECO #: MSCP12-33             user or  take  whatever  other  action  is  dictated  by
ECO #: MSCP12-33             operating    system   policy.    For   the   "Incomplete
ECO #: MSCP12-33             Replacement" flag, this might be a request  to  re-mount
ECO #: MSCP12-33             the  unit  write  enabled so that the replacement can be
ECO #: MSCP12-33             completed.  For the "Invalid RCT" flag, this might be  a
ECO #: MSCP12-33             warning that the volume has been corrupted.

ECO #: MSCP12-33    In all other cases, the Controller Bad  Block  Replacement  layer
ECO #: MSCP12-33    reports  things in a manner that is transparent to class drivers.
ECO #: MSCP12-33    It will never set the "Bad Block Reported" end flag, so the class
ECO #: MSCP12-33    driver  will  never  attempt  a replacement.  If the class driver
ECO #: MSCP12-33    attempts to read the RCT, the reported geometry is such that  the
ECO #: MSCP12-33    multi-copy read algorithm will work correctly.

ECO #: MSCP12-33    Aside from the above, a class driver that only  supports  servers
ECO #: MSCP12-33    with Controller Bad Block Replacement may omit substantial pieces
ECO #: MSCP12-33    of functionality.   These  include  the  bad  block  replacement,
ECO #: MSCP12-33    multi-copy  read,  and multi-copy write algorithms.  It also need
ECO #: MSCP12-33    never check the RCT for incomplete replacements.   Such  a  class
ECO #: MSCP12-33    driver should, however, check the "Controller Initiated Bad Block
ECO #: MSCP12-33    Replacement" unit flag whenever it brings a  unit  "Unit-Online".
ECO #: MSCP12-33    If the flag is clear, then that unit does not have Controller Bad
ECO #: MSCP12-33    Block Replacement, so it cannot be supported by the class driver.
ECO #: MSCP12-33    The class driver should immediately issue an AVAILABLE command to
ECO #: MSCP12-33    the unit and refuse to access it.

ECO #: MSCP12-33    ************************************************************
ECO #: MSCP12-33 								Page 20


ECO #: MSCP12-33    Add the following to the description of the "flags" field on page
ECO #: MSCP12-33    8-5 in section 8.2, "Generic Error Log Message Format":

ECO #: MSCP12-33        Bad Block Replacement Request

ECO #: MSCP12-33            If set, the block identified by the error log message  is
ECO #: MSCP12-33            a  bad  block,  and  the Controller Bad Block Replacement
ECO #: MSCP12-33            layer will soon attempt to replace it.

ECO #: MSCP12-33        Error During Replacement

ECO #: MSCP12-33            If set, the reported  error  occurred  during  an  access
ECO #: MSCP12-33            initiated by the bad block replacement process.





ECO #: MSCP12-33    Add Section 8.8:

ECO #: MSCP12-33    ************************************************************



ECO #: MSCP12-33    8.8  Bad Block Replacement Attempt

ECO #: MSCP12-33    The following error log message format is used by the  Controller
ECO #: MSCP12-33    Bad  Block  Replacement layer to report completion of a bad block
ECO #: MSCP12-33    replacement attempt.  Note that  a  message  of  this  format  is
ECO #: MSCP12-33    always  generated,  regardless  of  the success or failure of the
ECO #: MSCP12-33    replacement attempt.

ECO #: MSCP12-33                    31                             0 
ECO #: MSCP12-33                    +-------------------------------+
ECO #: MSCP12-33                    |   command reference number    |
ECO #: MSCP12-33                    +---------------+---------------+
ECO #: MSCP12-33                    |sequence number|  unit number  |
ECO #: MSCP12-33                    +---------------+-------+-------+
ECO #: MSCP12-33                    |  event code   | flags | format|
ECO #: MSCP12-33                    +---------------+-------+-------+
ECO #: MSCP12-33                    |                               |
ECO #: MSCP12-33                    +---  controller identifier  ---+
ECO #: MSCP12-33                    |                               |
ECO #: MSCP12-33                    +---------------+-------+-------+
ECO #: MSCP12-33                    |multi-unit code|chvrsn | csvrsn|
ECO #: MSCP12-33                    +---------------+-------+-------+
ECO #: MSCP12-33                    |                               |
ECO #: MSCP12-33                    +---     unit identifier     ---+
ECO #: MSCP12-33                    |                               |
ECO #: MSCP12-33                    +---------------+-------+-------+
ECO #: MSCP12-33                    | replace flags |uhvrsn | usvrsn|
ECO #: MSCP12-33                    +---------------+-------+-------+
ECO #: MSCP12-33                    |      volume serial number     |
ECO #: MSCP12-33                    +-------------------------------+
ECO #: MSCP12-33 								Page 21


ECO #: MSCP12-33                    |            Bad LBN            |
ECO #: MSCP12-33                    +-------------------------------+
ECO #: MSCP12-33                    |            Old RBN            |
ECO #: MSCP12-33                    +-------------------------------+
ECO #: MSCP12-33                    |            New RBN            |
ECO #: MSCP12-33                    +---------------+---------------+
ECO #: MSCP12-33                                    |     cause     |
ECO #: MSCP12-33                                    +---------------+

ECO #: MSCP12-33    command reference number

ECO #: MSCP12-33        Either zero or the command reference number  of  the  command
ECO #: MSCP12-33        that  caused  the  bad  block  to  be  detected and replaced.
ECO #: MSCP12-33        Controllers need not save this  value,  in  which  case  this
ECO #: MSCP12-33        field will always be zero.

ECO #: MSCP12-33    event code

ECO #: MSCP12-33        Reports the completion status of the  bad  block  replacement
ECO #: MSCP12-33        attempt.   The  major  code is always "Bad Block Completion".
ECO #: MSCP12-33        Sub-codes are defined in Table B-9.

ECO #: MSCP12-33    replace flags

ECO #: MSCP12-33        Bit flags reporting in detail the outcome of  the  bad  block
ECO #: MSCP12-33        replacement  attempt.   See  Table  A-11  for  detailed  flag
ECO #: MSCP12-33        definitions.

ECO #: MSCP12-33    Bad LBN

ECO #: MSCP12-33        The LBN that was the target of the replacement attempt.

ECO #: MSCP12-33    Old RBN

ECO #: MSCP12-33        The RBN with which the Bad LBN was formerly replaced, or zero
ECO #: MSCP12-33        if it was not formerly replaced.

ECO #: MSCP12-33    New RBN

ECO #: MSCP12-33        The RBN with which the Bad LBN is now replaced, or zero if no
ECO #: MSCP12-33        actual replacement was attempted.

ECO #: MSCP12-33    Cause

ECO #: MSCP12-33        The event code  from  the  original  error  that  caused  the
ECO #: MSCP12-33        replacement  to be attempted.  Zero if that event code is not
ECO #: MSCP12-33        available.

ECO #: MSCP12-33    ************************************************************
ECO #: MSCP12-33 								Page 22


ECO #: MSCP12-33    Add the following to Table A-5, Unit Flags:

ECO #: MSCP12-33    +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-33    | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-33    |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Unit Flag                          |
ECO #: MSCP12-33    +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33    |   8  |   400 |  100 | UF.WPD | MSCP$x_UF_WRTPD | Write Protect (data safety)            |





ECO #: MSCP12-33    Add the following to Table A-8, Error Log Message Offsets:

ECO #: MSCP12-33    +--------------------+--------------------------+-------+---------------------------------+
ECO #: MSCP12-33    |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
ECO #: MSCP12-33    | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
ECO #: MSCP12-33    +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33    | Bad Block Replacement Attempt Error Log Message Offsets:                                |
ECO #: MSCP12-33    |  34  |  42  |  22  | L.RPFL | MSLG$W_RPL_FLGS |   2   | Replace Flags                   |
ECO #: MSCP12-33    |  36  |  44  |  24  | L.VSER | MSLG$L_VOL_SER  |   4   | Volume serial number            |
ECO #: MSCP12-33    |  40  |  50  |  28  | L.LBN  | MSLG$L_BAD_LBN  |   4   | Bad LBN                         |
ECO #: MSCP12-33    |  44  |  54  |  2C  | L.ORBN | MSLG$L_OLD_RBN  |   4   | Old RBN                         |
ECO #: MSCP12-33    |  48  |  60  |  30  | L.NRBN | MSLG$L_NEW_RBN  |   4   | New RBN                         |
ECO #: MSCP12-33    |  52  |  64  |  34  | L.RPEV | MSLG$W_CAUSE    |   2   | Cause (an event code)           |





ECO #: MSCP12-33    Add the following to Table A-9, Error Log Message Format Codes:

ECO #: MSCP12-33    +--------------------+--------------------------+-----------------------------------------+
ECO #: MSCP12-33    |    Format Code     |   Preferred Mnemonics    |                                         |
ECO #: MSCP12-33    | Dec. | Oct. | Hex. | 16 bit |      32 bit     |   Format Description                    |
ECO #: MSCP12-33    +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33    |   9  |  11  |   9  | FM.RPL | MSLG$K_REPLACE  | Bad Block Replacement Attempt           |





ECO #: MSCP12-33    Add the following to Table A-10, Error Log Message Flags:

ECO #: MSCP12-33    +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-33    | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-33    |Number| Octal | Hex. | 16 bit |32 bit (see note)|   Error Log Message Flag               |
ECO #: MSCP12-33    +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33    |   5  |    40 |   20 | LF.BBR | MSLG$x_LF_BBR   | Bad Block Replacement Request          |
ECO #: MSCP12-33    |   4  |    20 |   10 | LF.RCT | MSLG$x_LF_RPLER | Error During Replacement               |
ECO #: MSCP12-33 									Page 23


ECO #: MSCP12-33    Add Table A-11:

ECO #: MSCP12-33                     Table A-11  Bad Block Replacement Attempt "Replace Flags"

ECO #: MSCP12-33    +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-33    | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-33    |Number| Octal | Hex. | 16 bit |32 bit (see note)|   Replace Flag                         |
ECO #: MSCP12-33    +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-33    |  15  |100000 | 8000 | LFR.RP | MSLG$x_LFR_RP   | Replacement attempted.  Set if block   |
ECO #: MSCP12-33    |      |       |      |        |                 |   was verified as bad.  Clear if block |
ECO #: MSCP12-33    |      |       |      |        |                 |   checked out OK.                      |
ECO #: MSCP12-33    |  14  | 40000 | 4000 | LFR.FE | MSLG$x_LFR_FE   | Force error.  Set if data could not be |
ECO #: MSCP12-33    |      |       |      |        |                 |   recovered, so block was re-written   |
ECO #: MSCP12-33    |      |       |      |        |                 |   with the Force Error modifier.       |
ECO #: MSCP12-33    |  13  | 20000 | 2000 | LFR.TE | MSLG$x_LFR_TE   | Tertiary revector.  Set if block was   |
ECO #: MSCP12-33    |      |       |      |        |                 |   revectored to a non-primary RBN.     |
ECO #: MSCP12-33    |  12  | 10000 | 1000 | LFR.RF | MSLG$x_LFR_RF   | Reformat error.  Set if the REPLACE    |
ECO #: MSCP12-33    |      |       |      |        |                 |   command or its analogue failed.      |
ECO #: MSCP12-33    |  11  |  4000 |  800 | LFR.RI | MSLG$x_LFR_RI   | RCT inconsistent.  Set if replacement  |
ECO #: MSCP12-33    |      |       |      |        |                 |   failed due to an inconsistent RCT.   |
ECO #: MSCP12-33    |  10  |  2000 |  400 | LFR.BR | MSLG$x_LFR_BR   | Bad RBN.  Set if LBN was previously    |
ECO #: MSCP12-33    |      |       |      |        |                 |   replaced, so a bad RBN was replaced. |
ECO #: MSCP12-33    +------+-------+------+--------+-----------------+----------------------------------------+





ECO #: MSCP12-33    Add note 4 to the beginning of Appendix B:

ECO #: MSCP12-33         4.  The standard sub-code values shown in  Table  B-9,  "Bad
ECO #: MSCP12-33             Block  Replacement  Completion"  Sub-code Values, are an
ECO #: MSCP12-33             exception to the above rules.  These sub-codes are  only
ECO #: MSCP12-33             returned  as  the  event  code in "Bad Block Replacement
ECO #: MSCP12-33             Attempt" error  log  messages,  where  they  report  the
ECO #: MSCP12-33             completion  status  of  a bad block replacement attempt.
ECO #: MSCP12-33             Although they are standard, they are  only  returned  as
ECO #: MSCP12-33             event codes.





ECO #: MSCP12-33    Add the following to Table B-1, Status and Event Codes:

ECO #: MSCP12-33    +--------------------+--------------------------+-----------------------------------------+
ECO #: MSCP12-33    |       Value        |   Preferred Mnemonics    |                                         |
ECO #: MSCP12-33    | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Status or Event Code                |
ECO #: MSCP12-33    +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33    |   20 |   24 |   14 | ST.BBR | MSCP$K_ST_BBR   | Bad Block Replacement Completion.       |
ECO #: MSCP12-33 									Page 24


ECO #: MSCP12-33    Add the following to Table B-2, Standard Status Sub-code Values:

ECO #: MSCP12-33        +------+---------------------+--------------------------------------------------+  
ECO #: MSCP12-33        | Sub- |   Code + Sub-code   |                                                  |  
ECO #: MSCP12-33        | code | Dec. |  Oct. | Hex. |          Status Sub-Code                         |  
ECO #: MSCP12-33        +------+------+-------+------+--------------------------------------------------+  
ECO #: MSCP12-33        | "Success" sub-code values: |                                                  |  
ECO #: MSCP12-33        |   32 | 1024 |  2000 |  400 | Incomplete Replacement                           |  
ECO #: MSCP12-33        |   64 | 2048 |  4000 |  800 | Invalid RCT                                      |  
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33        | "Write Protected" sub-code values:                                            |  
ECO #: MSCP12-33 |      |    8 |  262 |   406 |  106 | Unit is Data Safety Write Protected              |  
ECO #: MSCP12-33                                               . . . 
ECO #: MSCP12-33        | "Bad Block Replacement Completion" sub-code values -- see Table B-9           |  





ECO #: MSCP12-33    Add Table B-9:

ECO #: MSCP12-33                  Table B-9   "Bad Block Replacement Completion" Sub-code Values

ECO #: MSCP12-33    +------+---------------------+-+-+-----------------------------------------------------+  
ECO #: MSCP12-33    | Sub- |   Code + Sub-code   |E|S|                                                     |  
ECO #: MSCP12-33    | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |  
ECO #: MSCP12-33    +------+------+-------+------+-+-+-----------------------------------------------------+  
ECO #: MSCP12-33    |    0 |   20 |    24 |   14 |*| | Bad block successfully replaced.                    |  
ECO #: MSCP12-33    |    1 |   53 |    64 |   34 |*| | Block verified OK -- not a bad block.               |  
ECO #: MSCP12-33    |    2 |   84 |   124 |   54 |*| | Replacement failure -- REPLACE command or its       |  
ECO #: MSCP12-33    |      |      |       |      | | |   analogue failed.                                  |  
ECO #: MSCP12-33    |    3 |  116 |   164 |   74 |*| | Replacement failure -- Inconsistent RCT.            |  
ECO #: MSCP12-33    |    4 |  148 |   224 |   94 |*| | Replacement failure -- Drive access failure.  One   |  
ECO #: MSCP12-33    |      |      |       |      | | |   or more transfers specified by the replacement    |  
ECO #: MSCP12-33    |      |      |       |      | | |   algorithm failed.                                 |  
ECO #: MSCP12-33    +------+------+-------+------+-+-+-----------------------------------------------------+  


   <<End ECO #: MSCP12-33 Controller Initiated Bad Block Replacement>>


   <<ECO #: MSCP12-34 Exclusive Access (Multi-Host) [approved as amended 10 August 1984]>> 

ECO #: MSCP12-34    The following describes the proposed operation of the Exclusive Access
ECO #: MSCP12-34    modifier  on devices in a multi-host environment.  (And it's one, two,
ECO #: MSCP12-34    three what are we fighting four?)

ECO #: MSCP12-34    Note that  for  the  sake  of  simplicity  the  term  'host'  means  a
ECO #: MSCP12-34    connection.   A  single  host  can  make  multiple  connections  to  a
ECO #: MSCP12-34    controller, but the controller treats each connection as if it were  a
ECO #: MSCP12-34    separate host.



ECO #: MSCP12-34    1  ACQUIRING EXCLUSIVE ACCESS OF A DRIVE

ECO #: MSCP12-34    Any host may request Exclusive Access of a drive by issuing either  an
ECO #: MSCP12-34    ONLINE,  SET  UNIT  CHARACTERISTICS  or  AVAILABLE  command  with  the
ECO #: MSCP12-34    Exclusive Access Modifier set.   If  no  other  host  has  that  drive
ECO #: MSCP12-34    "Unit-Online",  and  if  no other host already has Exclusive Access of
ECO #: MSCP12-34    that drive, then the requesting host will be given Exclusive Access of
ECO #: MSCP12-34    that drive.



ECO #: MSCP12-34    2  EFFECTS OF EXCLUSIVE ACCESS ON OTHER HOSTS

ECO #: MSCP12-34    When one host has Exclusive Access of a drive, that drive will be Unit
ECO #: MSCP12-34    Offline  (subcode  =  Exclusive  Use  = 16.) to all other hosts.  This
ECO #: MSCP12-34    automatically prevents other hosts from altering  the  state  of  that
ECO #: MSCP12-34    drive,   while   allowing   them   to   inquire   about  that  drive's
ECO #: MSCP12-34    characteristics.



ECO #: MSCP12-34    3  EXCLUSIVE ACCESS UNIT FLAG

ECO #: MSCP12-34    The Exclusive Access Unit Flag is a non-host settable Unit Flag.

ECO #: MSCP12-34    When a drive is in the Exclusive Access state,  the  Exclusive  Access
ECO #: MSCP12-34    Unit  Flag  will  be  set; when a drive is not in the Exclusive Access
ECO #: MSCP12-34    state, the Exclusive Access Unit flag will be clear.

ECO #: MSCP12-34    When the Exclusive Access Unit Flag is set, it will  be  seen  by  all
ECO #: MSCP12-34    hosts  (that  choose to ask...).  The host that has acquired Exclusive
ECO #: MSCP12-34    Access of the drive will be the only host that does  not  receive  the
ECO #: MSCP12-34    "Unit Offline, Exclusive Access" status on commands to that drive.

ECO #: MSCP12-34    Note:  The only available Unit Flag common to both Disk and Tape  MSCP
ECO #: MSCP12-34    is  bit  3.   However,  2 bits are defined for suppressing caching and
ECO #: MSCP12-34    they could be redefined at a later date.  Also, the two proposed  Unit
ECO #: MSCP12-34    Flags  for Disk Shadowing could be moved to coincide with the two Tape
ECO #: MSCP12-34    specific Unit Flags for Variable Speed Units.  I  would  suggest  (but
ECO #: MSCP12-34    not  as  part  of  this  proposal) that we do move the Shadowing bits,
ECO #: MSCP12-34    unless someone expects to implement Shadowing for Tape MSCP.

ECO #: MSCP12-34    4  RELEASING EXCLUSIVE ACCESS
ECO #: MSCP12-34                                                                              Page 2



ECO #: MSCP12-34    A drive ceases to be in the  Exclusive  Access  state  relative  to  a
ECO #: MSCP12-34    particular host when any one of the following events occurs:

ECO #: MSCP12-34         1.  The host that has Exclusive Access of the drive releases said
ECO #: MSCP12-34             access  by  issuing an AVAILABLE, SET UNIT CHARACTERISTICS or
ECO #: MSCP12-34             ONLINE command to that drive,  which  does  not  specify  the
ECO #: MSCP12-34             Exclusive Access Modifier.

ECO #: MSCP12-34         2.  The controller loses (or breaks) the connection to  the  host
ECO #: MSCP12-34             that has Exclusive Access to the drive

ECO #: MSCP12-34         3.  The drive becomes unknown to the controller (e.g., port button
ECO #: MSCP12-34             disabled)

ECO #: MSCP12-34         4.  The drive becomes inoperative ("Unit-Offline, Inoperative")

ECO #: MSCP12-34         5.  The controller is 'rebooted', by itself, by an  operator,  or
ECO #: MSCP12-34             by any host




ECO #: MSCP12-34    5  ONLINE AND SET UNIT CHARACTERISTICS COMMANDS WITH EXCLUSIVE  ACCESS
ECO #: MSCP12-34       SPECIFIED

ECO #: MSCP12-34    When a host issues an ONLINE or SET UNIT CHARACTERISTICS command  with
ECO #: MSCP12-34    the  Exclusive  Access  modifier  specified  to  a  drive which is not
ECO #: MSCP12-34    already in exclusive use by any host, the following NEW cases exist:

ECO #: MSCP12-34         1.  The unit is already "Unit-Online" to  any  other  host.   The
ECO #: MSCP12-34             command   will   be  rejected  with  status  "Unit-Available"
ECO #: MSCP12-34             (subcode = Already In Use = 32.)

ECO #: MSCP12-34         2.  The  unit  is  "Unit-Available"  or  "Unit-Online"   to   the
ECO #: MSCP12-34             requesting  host  and is NOT "Unit-Online" to any other host.
ECO #: MSCP12-34             In this case, the unit will be placed  in  the  "Unit-Online"
ECO #: MSCP12-34             state  relative to the requesting host, and "Unit-Offline" to
ECO #: MSCP12-34             all other hosts.




ECO #: MSCP12-34    6  AVAILABLE WITH EXCLUSIVE ACCESS MODIFIER

ECO #: MSCP12-34    The Exclusive Access modifier on an AVAILABLE command allows a host to
ECO #: MSCP12-34    gain  or maintain Exclusive Access of a drive, while that drive is not
ECO #: MSCP12-34    necessarily "Unit-Online" or "Unit-Available".

ECO #: MSCP12-34    At the time the AVAILABLE command with the Exclusive  Access  modifier
ECO #: MSCP12-34    is  issued,  the  drive may NOT be "Unit-Online" to any other host, or
ECO #: MSCP12-34    the command will be rejected with a status of "Unit-Offline", sub-code
ECO #: MSCP12-34    "Already In Use".

ECO #: MSCP12-34    Note that this implies that a host  may  successfully  place  a  drive
ECO #: MSCP12-34    which is "Unit-Available" or "Unit-Offline, No Media Mounted" into the
ECO #: MSCP12-34    EXCLUSIVE ACCESS state without having to first bring the drive  ONLINE
ECO #: MSCP12-34                                                                              Page 3


ECO #: MSCP12-34    with  the  Exclusive  Access  modifier.   Also  note that the returned
ECO #: MSCP12-34    status may be "Unit-Available" or  "Unit-Offline,  No  Media  Mounted"
ECO #: MSCP12-34    even  when  Exclusive  Access  of  the drive is granted to the calling
ECO #: MSCP12-34    host.



ECO #: MSCP12-34    7  MISC.

ECO #: MSCP12-34    If a host has Exclusive Access of a drive, and that drive then becomes
ECO #: MSCP12-34    a duplicate unit, the host will be allowed to use the 'original' drive
ECO #: MSCP12-34    as though it were not a  duplicate,  until  the  Exclusive  Access  is
ECO #: MSCP12-34    released.   This  means  that  the  host may send the 'original' drive
ECO #: MSCP12-34    available, and bring it back Online  (ex:   a  reel  change  during  a
ECO #: MSCP12-34    multi-reel  backup),  as  long  as  the drive remains in the Exclusive
ECO #: MSCP12-34    Access state.

ECO #: MSCP12-34    A host can not explicitly determine that it has Exclusive Access of  a
ECO #: MSCP12-34    drive  from  the AVAILABLE End Packet.  Unit Flags are returned in the
ECO #: MSCP12-34    ONLINE, SET UNIT CHARACTERISTICS and GET UNIT STATUS responses.

ECO #: MSCP12-34    While a drive is in the Exclusive Access state,  the  controller  must
ECO #: MSCP12-34    maintain  access  to  that  unit (i.e.  in a multi-ported environment,
ECO #: MSCP12-34    other controllers must be prevented from bringing the unit Online).

ECO #: MSCP12-34    If a host has previously  been  granted  Exclusive  Access,  and  then
ECO #: MSCP12-34    issues  another  ONLINE  command  which specifies the Exclusive Access
ECO #: MSCP12-34    Modifier, and that command is rejected for Invalid Format  or  Invalid
ECO #: MSCP12-34    Unit Flags, the host will maintain its Exclusive Access of the drive.

ECO #: MSCP12-34    This ECO proposal, if approved, must be added to  both  the  Disk  and
ECO #: MSCP12-34    Tape MSCP Specifications.

ECO #: MSCP12-34    If a drive is not in exclusive use, and any host issues  an  AVAILABLE
ECO #: MSCP12-34    command  with  both  the  All Class Drivers modifier and the Exclusive
ECO #: MSCP12-34    Access modifier specified, the drive will be rewound (and unloaded  if
ECO #: MSCP12-34    the  Unload Modifier is specified) and the drive will be placed in the
ECO #: MSCP12-34    Exclusive Access state for the calling  host.   I.e.   the  All  Class
ECO #: MSCP12-34    Drivers  Modifier  is  processed before the Exclusive Access Modifier.
ECO #: MSCP12-34    (happy Bugs?)

ECO #: MSCP12-34    This proposal does not address Exclusive Access of Shadow  sets.   The
ECO #: MSCP12-34    author  of  this ECO proposal is currently involved in Tape (not Disk)
ECO #: MSCP12-34    MSCP, and hence is not the person to address a Disk specific issue.
ECO #: MSCP12-34                                                                                                            Page 4



ECO #: MSCP12-34            ADDENDUM (by Jim Zahrobsky)

ECO #: MSCP12-34    Changes from MSCP Version 1.2 Appendices A and B are denoted by change bars (|) in the left hand margin. 


ECO #: MSCP12-34                                               Table A-2   Command Modifiers

ECO #: MSCP12-34                +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-34                | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-34                |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Command Modifier                   |
ECO #: MSCP12-34                +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34    |           | AVAILABLE, ONLINE, and SET UNIT CHARACTERISTICS Command Modifiers:                      |
ECO #: MSCP12-34    |           |   5  |    40 |   20 | MD.EXC | MSCP$x_MD_EXCAC | Exclusive Access (unit)                |
ECO #: MSCP12-34                                                            .


ECO #: MSCP12-34                                                   Table A-5   Unit Flags

ECO #: MSCP12-34                +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-34                | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-34                |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Unit Flag                          |
ECO #: MSCP12-34                +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34    |           |   3  |    10 |    8 | UF.EXA | MSCP$x_UF_EXACC | Exclusive Access                       |
ECO #: MSCP12-34                                                            .


ECO #: MSCP12-34                                       Table B-2   Standard Status Sub-code Values   

ECO #: MSCP12-34                  +------+---------------------+---------------------------------------------------------+
ECO #: MSCP12-34                  | Sub- |   Code + Sub-code   |                                                         |
ECO #: MSCP12-34                  | code | Dec. |  Oct. | Hex. |                 Status Sub-Code                         |
ECO #: MSCP12-34                  +------+------+-------+------+---------------------------------------------------------+
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                  | "Unit-Offline" sub-code values:                                                      |
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34    |             |   16 |  451 |   703 |  1C3 | Exclusive Use                                           |
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                  | "Unit-Available" sub-code values:                                                    |
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34                                                            .
ECO #: MSCP12-34    |             |   32 |  836 |  1504 |  344 | Already In Use                                          |
ECO #: MSCP12-34                                                            .


   <<End ECO #: MSCP12-34 Exclusive Access (Multi-Host)>>



   <<ECO #: MSCP12-35 Access Non-volatile Memory Command [approved as submitted 14 September 1984]>> 


ECO #: MSCP12-35       Add the following new command to chapter 6:



ECO #: MSCP12-35       0.1  ACCESS NON-VOLATILE MEMORY Command



ECO #: MSCP12-35       Command category:

ECO #: MSCP12-35           Immediate


ECO #: MSCP12-35       Command message format:

ECO #: MSCP12-35                         31                             0 
ECO #: MSCP12-35                         +-------------------------------+
ECO #: MSCP12-35                         |   command reference number    |
ECO #: MSCP12-35                         +---------------+---------------+
ECO #: MSCP12-35                         |   reserved    |    reserved   |
ECO #: MSCP12-35                         +---------------+-------+-------+
ECO #: MSCP12-35                         |   modifiers   | rsvd  | opcode|
ECO #: MSCP12-35                         +---------------+-------+-------+
ECO #: MSCP12-35                         |           reserved            |
ECO #: MSCP12-35                         +-------------------------------+
ECO #: MSCP12-35                         |            offset             |
ECO #: MSCP12-35                         +---------------+---------------+
ECO #: MSCP12-35                         |    length     |   operation   |
ECO #: MSCP12-35                         +---------------+---------------+
ECO #: MSCP12-35                         |                               |
ECO #: MSCP12-35                         /         non-volatile          /
ECO #: MSCP12-35                         /         memory data           /
ECO #: MSCP12-35                         |                               |
ECO #: MSCP12-35                         +-------------------------------+

ECO #: MSCP12-35           offset

ECO #: MSCP12-35               The byte offset within the server's  non-volatile  memory
ECO #: MSCP12-35               at which to perform the operation.

ECO #: MSCP12-35           operation

ECO #: MSCP12-35               The  operation  to   be   performed   on   the   server's
ECO #: MSCP12-35               non-volatile memory.  Legal values are:

ECO #: MSCP12-35               0.  Read

ECO #: MSCP12-35               1.  Exchange

ECO #: MSCP12-35               2.  Test and Set

ECO #: MSCP12-35               The server rejects the command with an "Invalid  Command"
ECO #: MSCP12-35               status code and "Invalid Operation" sub-code if any other
ECO #: MSCP12-35                                                                              Page 2


ECO #: MSCP12-35               value is specified.

ECO #: MSCP12-35           length

ECO #: MSCP12-35               The number of bytes of non-volatile memory data  included
ECO #: MSCP12-35               in  this  command  message  or  to  be  returned  in this
ECO #: MSCP12-35               command's end message.  This must be an even value if the
ECO #: MSCP12-35               operation  is  "Test  and  Set".   The server rejects the
ECO #: MSCP12-35               command  with  an  "Invalid  Command"  status  code   and
ECO #: MSCP12-35               "Invalid Length" sub-code if an odd "length" is specified
ECO #: MSCP12-35               with the "Test and Set" operation.

ECO #: MSCP12-35               The maximum valid "length" is server dependent.  However,
ECO #: MSCP12-35               all  servers  that  implement  this  command must support
ECO #: MSCP12-35               values of "length" in the range 0 through  32  inclusive.
ECO #: MSCP12-35               The  server rejects the command with an "Invalid Command"
ECO #: MSCP12-35               status code and "Invalid Length" sub-code if  a  "length"
ECO #: MSCP12-35               larger than the server's maximum is specified.

ECO #: MSCP12-35           non-volatile memory data

ECO #: MSCP12-35               "Length" bytes of data to be used in the operation.


ECO #: MSCP12-35       Allowable modifiers:

ECO #: MSCP12-35           none


ECO #: MSCP12-35       End message format:

ECO #: MSCP12-35                         31                             0 
ECO #: MSCP12-35                         +-------------------------------+
ECO #: MSCP12-35                         |   command reference number    |
ECO #: MSCP12-35                         +---------------+---------------+
ECO #: MSCP12-35                         |   reserved    |    reserved   |
ECO #: MSCP12-35                         +---------------+-------+-------+
ECO #: MSCP12-35                         |    status     | flags |endcode|
ECO #: MSCP12-35                         +---------------+-------+-------+
ECO #: MSCP12-35                         |   non-volatile memory size    |
ECO #: MSCP12-35                         +-------------------------------+
ECO #: MSCP12-35                         |            offset             |
ECO #: MSCP12-35                         +---------------+---------------+
ECO #: MSCP12-35                         |     length    |   operation   |
ECO #: MSCP12-35                         +---------------+---------------+
ECO #: MSCP12-35                         |                               |
ECO #: MSCP12-35                         /         non-volatile          /
ECO #: MSCP12-35                         /         memory data           /
ECO #: MSCP12-35                         |                               |
ECO #: MSCP12-35                         +-------------------------------+

ECO #: MSCP12-35           non-volatile memory size

ECO #: MSCP12-35               The number of bytes of non-volatile memory implemented by
ECO #: MSCP12-35               the server.

ECO #: MSCP12-35           offset
ECO #: MSCP12-35                                                                              Page 3


ECO #: MSCP12-35           operation
ECO #: MSCP12-35           length

ECO #: MSCP12-35               Copied (without alteration) from the command message.

ECO #: MSCP12-35           non-volatile memory data

ECO #: MSCP12-35               "Length" bytes of data returned by the operation.


ECO #: MSCP12-35       Status Codes:

ECO #: MSCP12-35           Success (sub-code "Normal")
ECO #: MSCP12-35           Invalid Command (sub-code "Invalid Length")
ECO #: MSCP12-35           Invalid Command (sub-code "Invalid Operation")
ECO #: MSCP12-35           Compare Error


ECO #: MSCP12-35       Description:

ECO #: MSCP12-35           The ACCESS NON-VOLATILE MEMORY command provides class  driver
ECO #: MSCP12-35           access  to a non-volatile memory region within the controller
ECO #: MSCP12-35           or server.  Hosts may use  this  memory  to  store  arbitrary
ECO #: MSCP12-35           parameters  or  information.   MSCP  servers merely store the
ECO #: MSCP12-35           data; they do not use it in any way.

ECO #: MSCP12-35           The presence and size of  a  non-volatile  memory  is  server
ECO #: MSCP12-35           dependent.    However,   whenever   a   server   provides   a
ECO #: MSCP12-35           non-volatile memory, the memory must be  at  least  16  bytes
ECO #: MSCP12-35           long.   Multi-host servers must always implement a 16 byte or
ECO #: MSCP12-35           larger  non-volatile  memory.   Single   host   servers   may
ECO #: MSCP12-35           optionally  implement  a  non-volatile  memory  or not.  If a
ECO #: MSCP12-35           single host server does not implement a non-volatile  memory,
ECO #: MSCP12-35           then it need not implement this command.

ECO #: MSCP12-35           The non-volatile memory is addressed at offsets 0 through N-1
ECO #: MSCP12-35           inclusive,  where  N is the size of the server's non-volatile
ECO #: MSCP12-35           memory in bytes.  Class drivers  may  access  offsets  N  and
ECO #: MSCP12-35           higher,  even though they are not included in the implemented
ECO #: MSCP12-35           memory.  Attempts to write offsets N and higher  are  ignored
ECO #: MSCP12-35           and  always  succeed.   Attempts to read offsets N and higher
ECO #: MSCP12-35           return zero.

ECO #: MSCP12-35           Three operations are provided for accessing the  non-volatile
ECO #: MSCP12-35           memory.   The  detailed  semantics of these operations are as
ECO #: MSCP12-35           follows:

ECO #: MSCP12-35           0.  Read -- The server  reads  "length"  bytes  beginning  at
ECO #: MSCP12-35               offset  "offset"  and  returns  them as the "non-volatile
ECO #: MSCP12-35               memory data"  in  the  end  message.   The  "non-volatile
ECO #: MSCP12-35               memory data" in the command message is ignored.

ECO #: MSCP12-35           1.  Exchange -- The server reads "length" bytes beginning  at
ECO #: MSCP12-35               offset  "offset"  and  returns  them as the "non-volatile
ECO #: MSCP12-35               memory data" in the end message.  Next, the server writes
ECO #: MSCP12-35               "length"  bytes  beginning  at  offset  "offset" with the
ECO #: MSCP12-35               "non-volatile memory data" from the command message.
ECO #: MSCP12-35                                                                              Page 4



ECO #: MSCP12-35               This operation exchanges  the  non-volatile  memory  data
ECO #: MSCP12-35               with  the  memory  contents  stored  in  the server.  The
ECO #: MSCP12-35               command message provides the new memory  contents,  while
ECO #: MSCP12-35               the old memory contents are returned in the end message.

ECO #: MSCP12-35           2.  Test  and  Set  --  The  server  reads  "length"/2  bytes
ECO #: MSCP12-35               beginning  at  offset  "offset"  and  returns them as the
ECO #: MSCP12-35               first half of the "non-volatile memory data" in  the  end
ECO #: MSCP12-35               message.   Next,  the  server  compares  these "length"/2
ECO #: MSCP12-35               bytes against the first half of the "non-volatile  memory
ECO #: MSCP12-35               data"  from  the command message.  If they are different,
ECO #: MSCP12-35               the server returns a "Compare  Error"  status  code.   If
ECO #: MSCP12-35               they  are  the  same,  the server writes "length"/2 bytes
ECO #: MSCP12-35               beginning at offset "offset" with the second half of  the
ECO #: MSCP12-35               "non-volatile  memory  data" from the command message and
ECO #: MSCP12-35               returns a "Success" status  code.   In  both  cases,  the
ECO #: MSCP12-35               second  half of the "non-volatile memory data" in the end
ECO #: MSCP12-35               message is copied without  alteration  from  the  command
ECO #: MSCP12-35               message.

ECO #: MSCP12-35               This operation provides an atomic test-and-set operation.
ECO #: MSCP12-35               The  "non-volatile memory data" is divided into two equal
ECO #: MSCP12-35               length halves.  The first half is  compared  against  the
ECO #: MSCP12-35               values stored in the server to determine the "Success" or
ECO #: MSCP12-35               "Compare Error" status of  the  command.   If  comparison
ECO #: MSCP12-35               shows  both  values  are  equal,  then the second half of
ECO #: MSCP12-35               "non-volatile   memory   data"   is   stored   into   the
ECO #: MSCP12-35               non-volatile  memory.   In  either  case, the values that
ECO #: MSCP12-35               were stored in the server prior  to  this  operation  are
ECO #: MSCP12-35               returned   in   the  first  half  of  the  end  message's
ECO #: MSCP12-35               "non-volatile memory data".

ECO #: MSCP12-35           For all three operations, a "length" of zero is legal.  It is
ECO #: MSCP12-35           treated  as  a  no-op and always succeeds.  This is primarily
ECO #: MSCP12-35           useful as a means for class drivers to determine the size  of
ECO #: MSCP12-35           the server's non-volatile memory.

ECO #: MSCP12-35           The server must implement all operations  requested  by  this
ECO #: MSCP12-35           command as atomic operations.  If several ACCESS NON-VOLATILE
ECO #: MSCP12-35           MEMORY commands are outstanding  simultaneously,  the  server
ECO #: MSCP12-35           may  perform  them in any sequence, but must process only one
ECO #: MSCP12-35           of them at a time.

ECO #: MSCP12-35           The server must remember the  contents  of  its  non-volatile
ECO #: MSCP12-35           memory  across  power failures, re-initializations, losses of
ECO #: MSCP12-35           context, and other normal failures.  However,  the  following
ECO #: MSCP12-35           events  are  not  normal  and  may  result  in  loss  of  the
ECO #: MSCP12-35           non-volatile memory contents:

ECO #: MSCP12-35           1.  Field Service attention or other maintenance actions.  If
ECO #: MSCP12-35               the  component  containing  the  non-volatile  memory  is
ECO #: MSCP12-35               replaced, its contents may become undefined.

ECO #: MSCP12-35           2.  A power failure,  re-initialization,  or  other  loss  of
ECO #: MSCP12-35               context  while the non-volatile memory is being modified.
ECO #: MSCP12-35               The offset being modified, plus some controller dependent
ECO #: MSCP12-35                                                                              Page 5


ECO #: MSCP12-35               number of adjacent locations, may become undefined.

ECO #: MSCP12-35           The non-volatile memory should contain  all  zeros  in  newly
ECO #: MSCP12-35           shipped servers.

ECO #: MSCP12-35           One  characteristic  of   commonly   available   non-volatile
ECO #: MSCP12-35           memories  is that they can only be reliably written a limited
ECO #: MSCP12-35           number of times.  Therefore class drivers may not  treat  the
ECO #: MSCP12-35           non-volatile  memory  as  they  would  standard  RAM  or disk
ECO #: MSCP12-35           memory.  Class drivers should  design  their  algorithms  for
ECO #: MSCP12-35           using  the  non-volatile  memory  to  ensure that they do not
ECO #: MSCP12-35           alter it more often than an average of once per  day.   Short
ECO #: MSCP12-35           periods of frequent updates are acceptable, provided they are
ECO #: MSCP12-35           balanced by long periods of few updates.
ECO #: MSCP12-35                                                                                                            Page 6



ECO #: MSCP12-35            ADDENDUM (by Jim Zahrobsky)

ECO #: MSCP12-35    Changes from MSCP Version 1.2 Appendix A are denoted by change bars (|) in the left hand margin. 


ECO #: MSCP12-35                                            Table A-1   Control Message Opcodes

ECO #: MSCP12-35                +--------------------+--------------------------+-----------------------------------------+
ECO #: MSCP12-35                |    Opcode Value    |   Preferred Mnemonics    |                                         |
ECO #: MSCP12-35                | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Control Message Type                |
ECO #: MSCP12-35                +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35    |           |   5  |  05  |  05  | OP.ANM | MSCP$K_OP_ACCNM | ACCESS NON-VOLATILE MEMORY Command      |
ECO #: MSCP12-35                                                       .


ECO #: MSCP12-35                                            Table A-6   Command Message Offsets

ECO #: MSCP12-35                +--------------------+--------------------------+-------+---------------------------------+
ECO #: MSCP12-35                |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
ECO #: MSCP12-35                | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
ECO #: MSCP12-35                +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35    |           | ACCESS NON-VOLATILE MEMORY Command Message Offsets:                                     |
ECO #: MSCP12-35    |           |  12  |  14  |   C  |        |                 |   4   | Reserved                        |
ECO #: MSCP12-35    |           |  16  |  20  |  10  | P.ANOF | MSCP$L_ANM_OFFS |   4   | Offset                          |
ECO #: MSCP12-35    |           |  20  |  24  |  14  | P.ANOP | MSCP$W_ANM_OPER |   2   | Operation (see Table A-12)      |
ECO #: MSCP12-35    |           |  22  |  26  |  16  | P.ANDL | MSCP$W_ANM_DLGH |   2   | Data length                     |
ECO #: MSCP12-35    |           |  24  |  30  |  18  | P.ANMD | MSCP$Z_ANM_MEMD |   *   | Memory data                     |
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35                +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-35    |           | Note: An asterisk (*) in the field size indicates that the size varies.                 |
ECO #: MSCP12-35    |           +------+------+------+--------+-----------------+-------+---------------------------------+


ECO #: MSCP12-35                                       Table A-7   End and Attention Message Offsets

ECO #: MSCP12-35                +--------------------+--------------------------+-------+---------------------------------+
ECO #: MSCP12-35                |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
ECO #: MSCP12-35                | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
ECO #: MSCP12-35                +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35    |           | ACCESS NON-VOLATILE MEMORY End Message Offsets:                                         |
ECO #: MSCP12-35    |           |  12  |  14  |   C  | P.ANSZ | MSCP$L_ANM_SIZE |   4   | Memory Size                     |
ECO #: MSCP12-35    |           |  16  |  20  |  10  | P.ANOF | MSCP$L_ANM_OFFS |   4   | Offset                          |
ECO #: MSCP12-35    |           |  20  |  24  |  14  | P.ANOP | MSCP$W_ANM_OPER |   2   | Operation (see Table A-12)      |
ECO #: MSCP12-35    |           |  22  |  26  |  16  | P.ANDL | MSCP$W_ANM_DLGH |   2   | Data length                     |
ECO #: MSCP12-35    |           |  24  |  30  |  18  | P.ANMD | MSCP$Z_ANM_MEMD |   *   | Memory data                     |
ECO #: MSCP12-35                                                       .
ECO #: MSCP12-35    |           +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-35    |           | Note: An asterisk (*) in the field size indicates that the size varies.                 |
ECO #: MSCP12-35    |           +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-35                                                                                                            Page 7



ECO #: MSCP12-35    |                          Table A-12 Access Non-volatile Memory Command Operation Codes

ECO #: MSCP12-35    |           +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-35    |           | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-35    |           |Number| Octal | Hex. | 16 bit |     32 bit      |   Operation                            |
ECO #: MSCP12-35    |           +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-35    |           |   0  |     0 |    0 | ANM.RD | MSCP$K_ANM_READ | Read                                   |
ECO #: MSCP12-35    |           |   1  |     1 |    1 | ANM.EX | MSCP$K_ANM_EXCG | Exchange                               |
ECO #: MSCP12-35    |           |   2  |     2 |    2 | ANM.TS | MSCP$K_ANM_TSST | Test and Set                           |
ECO #: MSCP12-35    |           +------+-------+------+--------+-----------------+----------------------------------------+

   <<End ECO #: MSCP12-35 Access Non-volatile Memory Command>>
   <<ECO #: MSCP12-36 Data Encryption [approved as amended 14 September 1984]>> 

ECO #: MSCP12-36    +-----------------------------------------------------------------------+
ECO #: MSCP12-36    |                                                                       |
ECO #: MSCP12-36    | Note #1: There are three addendums to this ECO:                       |
ECO #: MSCP12-36    |                                                                       |
ECO #: MSCP12-36    |       o ADDENDUM #1 describes status codes not included in the        |
ECO #: MSCP12-36    |         original request.                                             |
ECO #: MSCP12-36    |                                                                       |
ECO #: MSCP12-36    |       o ADDENDUM #2 describes the use of a  controller  rather        |
ECO #: MSCP12-36    |         than a unit flag.                                             |
ECO #: MSCP12-36    |                                                                       |
ECO #: MSCP12-36    |       o ADDENDUM #3 defines all of the Appendix A and B  table        |
ECO #: MSCP12-36    |         values that  were  previously  listed  as  TBS/TBD  or        |
ECO #: MSCP12-36    |         implied by the text.                                          |
ECO #: MSCP12-36    |                                                                       |
ECO #: MSCP12-36    | Note #2: Editorial changes requested  during  the  review  are        |
ECO #: MSCP12-36    |          denoted by # characters in the left hand column.             |
ECO #: MSCP12-36    |                                                                       |
ECO #: MSCP12-36    +-----------------------------------------------------------------------+


ECO #: MSCP12-36            The following paragraphs describe the required use of encryption
ECO #: MSCP12-36    by the RRD50 device, but the reader will note from the text that this ECO
ECO #: MSCP12-36    is generic and extensible to other encryption/decryption schemes in the
ECO #: MSCP12-36    future.

ECO #: MSCP12-36            The RRD50 is the first storage peripheral that requires 
ECO #: MSCP12-36    the ability to read data that is encrypted by the DES algorithm.
ECO #: MSCP12-36    This algorithm requires an 8 byte key to be passed to the controller
ECO #: MSCP12-36    to decrypt the data. Data on the RRD50 disks may be encrypted or
ECO #: MSCP12-36    clear text. Presently there is no mechanism in MSCP to allow passing
ECO #: MSCP12-36    a key to read encrypted data.

ECO #: MSCP12-36            The philosophy of the encryption scheme being  proposed
ECO #: MSCP12-36    is as follows. Every controller that supports encryption will have a 
ECO #: MSCP12-36    unique 7 byte controller code recorded in its non-volatile memory.
ECO #: MSCP12-36    This code will be supplied to a software vendor, by the user, who
ECO #: MSCP12-36    will use some variable portion of the code (min. 16 bits) and
ECO #: MSCP12-36    produce a key that will be supplied to the user. This number
ECO #: MSCP12-36    is used as a key to access data. This number will be comprised of
ECO #: MSCP12-36    a 64 bit field, a 1 byte descriptor field, and up to 6 bytes of 
ECO #: MSCP12-36    a plain text field. This data is supplied to the controller in 
ECO #: MSCP12-36    an MSCP packet. The controller enters the 64 bit field into the
ECO #: MSCP12-36    key port of the DES chip. The descriptor byte indicates how many
ECO #: MSCP12-36    bits of the controller code are to be combined with the plain text
ECO #: MSCP12-36    field to create a 64 bit number. This is then entered into the 
ECO #: MSCP12-36    encrypted data input of the DES chip. The result is a 64 bit key, Kd,
ECO #: MSCP12-36    that is used by the controller to decrypt the data.

ECO #: MSCP12-36            The number of bits of the controller code used to generate 
ECO #: MSCP12-36    the Kd is a variable. This enables different software vendors the option
ECO #: MSCP12-36    of minimizing the cpu time needed to generate the user key by using a
ECO #: MSCP12-36    smaller number of bits.
ECO #: MSCP12-36                                                                              Page 2


ECO #: MSCP12-36    The following changes must be made to the MSCP spec.
ECO #: MSCP12-36    A further implication of this ECO is that the maximum command packet
ECO #: MSCP12-36    size will be increased from 48(10) bytes to 60(10) bytes.

ECO #: MSCP12-36 #  1.   New unit flag.
ECO #: MSCP12-36 #  
ECO #: MSCP12-36 #  See ADDENDUMs #2 and #3.

ECO #: MSCP12-36    2.   New Command Modifier for the Set Controller Characteristics command. 
    
ECO #: MSCP12-36         This modifier will instruct the controller to flush its encryption/
ECO #: MSCP12-36         decryption key cache.

ECO #: MSCP12-36         Add to section 5.4 Command Modifiers

ECO #: MSCP12-36            Flush Key Cache

ECO #: MSCP12-36            A controller may, at its option, set up a cache of keys. A key 
ECO #: MSCP12-36            identifier can be used to uniquely identify a key on a per 
ECO #: MSCP12-36            connection basis. By storing a number of keys, the controller can
ECO #: MSCP12-36            eliminate the need to access this data through the buffer descriptor.

ECO #: MSCP12-36 #          Applicable to Set Controller Characteristics command. If set, the 
ECO #: MSCP12-36 #          controller eliminates all keys associated with that connection from 
ECO #: MSCP12-36 #          its key cache.
ECO #: MSCP12-36 #  
ECO #: MSCP12-36 #          See ADDENDUM #3 for modifier value.
ECO #: MSCP12-36 #  
ECO #: MSCP12-36 #  3.    Make indicated changes to COMPARE CONTROLLER DATA, COMPARE HOST DATA, 
ECO #: MSCP12-36 #        ERASE, READ, and WRITE command descriptions (sections 6.6, 6.7,  6.9, 
ECO #: MSCP12-36 #        6.14, and 6.18).
ECO #: MSCP12-36 #  
ECO #: MSCP12-36 #        Change command packet format to the following:

ECO #: MSCP12-36                    31                              0
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    | command reference number      |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    | reserved     |  unit number   |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |  modifiers   | rsvd  |opcode  |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |          byte count           |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +--        buffer             --+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +--      descriptor           --+
ECO #: MSCP12-36 #                  |    (or reserved for ERASE)    |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |    logical block number       |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |    key identifier             |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |    key buffer length          |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                                                                              Page 3


ECO #: MSCP12-36                    +--                           --+
ECO #: MSCP12-36                    |    key buffer descriptor      |
ECO #: MSCP12-36                    +--                           --+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +-------------------------------+


ECO #: MSCP12-36 #      Add the following field descriptions:

ECO #: MSCP12-36            Key Identifier

ECO #: MSCP12-36            The host is required to synthesize a 32-bit number which is unique
ECO #: MSCP12-36            for each key on a per connection basis.  This number is the
ECO #: MSCP12-36            Key Identifier.  A controller may, at its option, cache a number
ECO #: MSCP12-36            of keys internally to avoid the overhead of fetching the key from
ECO #: MSCP12-36            host memory with each transfer command.  The key identifier
ECO #: MSCP12-36            facilitates key cacheing.

ECO #: MSCP12-36            A controller's cache of keys is on a per connection basis, and it
ECO #: MSCP12-36 #          is valid only when the controller  is "online". The host can clear 
ECO #: MSCP12-36 #          the controller's key cache either by issuing a SET CONTROLLER 
ECO #: MSCP12-36 #          CHARACTERISTICS with the "Flush Key Cache" modifier or by making
ECO #: MSCP12-36 #          the controller "Controller-Available". 

ECO #: MSCP12-36            Key identifier 0 is valid but never cached.

ECO #: MSCP12-36            Key Buffer Length

ECO #: MSCP12-36            This is the length in bytes of the key buffer. A key buffer length
ECO #: MSCP12-36            of 0 means no encryption/decryption is to be used.

ECO #: MSCP12-36            Key Buffer Descriptor

ECO #: MSCP12-36            Communication mechanism dependent identification of the host
ECO #: MSCP12-36            buffer to use for key data transfer.


ECO #: MSCP12-36    4. New Command - opcode TBD

ECO #: MSCP12-36          6.xx READ CONTROLLER ENCRYPTION/DECRYPTION CODE command

ECO #: MSCP12-36            command category immediate 

ECO #: MSCP12-36            command message format

ECO #: MSCP12-36                    31                              0
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    | command reference number      |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    | reserved     |  unit number   |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |  modifiers   | rsvd  |opcode  |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |    byte count                 |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +--                           --+
ECO #: MSCP12-36                                                                              Page 4


ECO #: MSCP12-36                    |        buffer descriptor      |
ECO #: MSCP12-36                    +--                           --+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +-------------------------------+

ECO #: MSCP12-36                    allowable modifiers

ECO #: MSCP12-36 #                  none

ECO #: MSCP12-36            Byte count 

ECO #: MSCP12-36            This is the size, in bytes, of the buffer that the host has 
ECO #: MSCP12-36            reserved in its memory for the controller encryption/decryption 
ECO #: MSCP12-36            code.

ECO #: MSCP12-36            Buffer descriptor

ECO #: MSCP12-36 #          Communication mechanism dependent identification of the host
ECO #: MSCP12-36 #          buffer.

ECO #: MSCP12-36                    End message

ECO #: MSCP12-36                    31                              0
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    | command reference number      |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    | reserved     |  unit number   |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |  status      | flags |endcode |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |  byte count (host transfer)   |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +---                        ----+
ECO #: MSCP12-36                    |         undefined             |
ECO #: MSCP12-36                    +---                        ----+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +---                        ----+
ECO #: MSCP12-36                    |                               |
ECO #: MSCP12-36                    +-------------------------------+
ECO #: MSCP12-36                    |  byte count (enc code length) |  
ECO #: MSCP12-36                    +-------------------------------+

ECO #: MSCP12-36            status codes

ECO #: MSCP12-36 #          success (sub-code normal)
ECO #: MSCP12-36 #          unit-offline
ECO #: MSCP12-36 #          controller error
ECO #: MSCP12-36 #          drive error
ECO #: MSCP12-36 #          host buffer access error
ECO #: MSCP12-36 #          record data truncated

ECO #: MSCP12-36         Description:

ECO #: MSCP12-36 #        This command will allow reading the controller encryption/decryption
ECO #: MSCP12-36 #        code. The format and interpretation of the encryption code is controller
ECO #: MSCP12-36 #        dependent (and usually differs from the key format).
ECO #: MSCP12-36                                                                              Page 5



ECO #: MSCP12-36            Byte count (host transfer)

ECO #: MSCP12-36 #          This field reflects the number of bytes successfully transferred.

ECO #: MSCP12-36            Byte count (enc code length)

ECO #: MSCP12-36            This is the length, in bytes, of the controller encryption/decryption
ECO #: MSCP12-36            code. If it is longer than the buffer assigned, the data will be
ECO #: MSCP12-36            truncated and a record data truncated status code will be returned.

ECO #: MSCP12-36 #          See ADDENDUM #3 for table values.

ECO #: MSCP12-36      Justification:            

ECO #: MSCP12-36            Encrypting data on the RRD50 is vital to the strategy of
ECO #: MSCP12-36    distributing  operating system software and associated layered products
ECO #: MSCP12-36    on the same RRD50 disk. The encryption protects the software until
ECO #: MSCP12-36    a customer purchases the software license. At that time the customer
ECO #: MSCP12-36    will be given the decrypt key to access the data. 

ECO #: MSCP12-36       Impact:

ECO #: MSCP12-36            This change should have no effect on existing controllers.
ECO #: MSCP12-36    It will impact host class drivers and operating system software that
ECO #: MSCP12-36    will support encrypted data.
ECO #: MSCP12-36                                                                              Page 6




ECO #: MSCP12-36            ADDENDUM #1 (by Ed Gardner)

ECO #: MSCP12-36    We need two  additional  status  codes.   The  first  reports  an
ECO #: MSCP12-36    invalid  parameter  value  for  parameters  that  are  not passed
ECO #: MSCP12-36    directly in the command message.  Invalid values of fields within
ECO #: MSCP12-36    command  messages  are reported with the "Invalid Command" status
ECO #: MSCP12-36    code.  We need the new "Invalid Parameter" status code to  report
ECO #: MSCP12-36    invalid values of fields within the encryption key buffer.

ECO #: MSCP12-36    The  second  new  status  code  reports  an  unauthorized  access
ECO #: MSCP12-36    attempt.   A controller may protect various portions of a volume,
ECO #: MSCP12-36    requiring that the host supply the correct key value in order  to
ECO #: MSCP12-36    access  it.   The  controller  returns the "Access Denied" status
ECO #: MSCP12-36    code if the host does not supply  the  correct  key  value.   The
ECO #: MSCP12-36    contents  of  the volume and of the host buffer remain unaltered.
ECO #: MSCP12-36    Note that different portions of a volume may  be  protected  with
ECO #: MSCP12-36    different  keys.   Therefore  it  is  possible  for the first few
ECO #: MSCP12-36    blocks of a transfer to succeed while the remainder fail with  an
ECO #: MSCP12-36    "Access  Denied" status code.  Note also that using a sub-code to
ECO #: MSCP12-36    report why access was denied would often compromise security.

ECO #: MSCP12-36    Whenever someone integrates ECOs into the body of the MSCP  spec,
ECO #: MSCP12-36    they  should  extract  appropriate portions of the preceeding two
ECO #: MSCP12-36    paragraphs and stick them in section 5.6.

ECO #: MSCP12-36 #  See ADDENDUM #3 for table values.
ECO #: MSCP12-36                                                                              Page 7




ECO #: MSCP12-36            ADDENDUM #2 (by Ed Gardner)

ECO #: MSCP12-36    The encryption ECO includes a unit flag to  indicate  whether  or
ECO #: MSCP12-36    not  the  controller  supports  encryption.  I believe that it is
ECO #: MSCP12-36    preferable that this be a controller  flag  rather  than  a  unit
ECO #: MSCP12-36    flag.   I  ask  that  you  cast  a  vote  for or against both the
ECO #: MSCP12-36    encryption ECO and this  amendment;  if  the  amendment  receives
ECO #: MSCP12-36    enough  favorable  votes  it  will apply to the ECO, otherwise it
ECO #: MSCP12-36    will be dropped.  I am in favor of the encryption ECO  regardless
ECO #: MSCP12-36    of whether or not this amendment passes.

ECO #: MSCP12-36    The flag in  question  reports  whether  or  not  the  controller
ECO #: MSCP12-36    supports  encryption.   "Supporting  encryption" means whether or
ECO #: MSCP12-36    not the controller understands the  proper  meaning  of  the  key
ECO #: MSCP12-36    identifier,  length,  and  buffer descriptor in transfer commands
ECO #: MSCP12-36    and  supports  the  READ  CONTROLLER  ENCRYPTION/DECRYPTION  CODE
ECO #: MSCP12-36    command.   If  a controller understands and supports these fields
ECO #: MSCP12-36    for any unit, then it should be required to understand  them  for
ECO #: MSCP12-36    all units.

ECO #: MSCP12-36    For  a  controller  that  supports  encryption  --   i.e.,   that
ECO #: MSCP12-36    understands  these  fields  --  there is the separate question of
ECO #: MSCP12-36    what key types  or  encryption  algorithms  it  supports.   If  a
ECO #: MSCP12-36    controller  does not have the hardware to encrypt or decrypt data
ECO #: MSCP12-36    for a specific unit, that means that it can only support key type
ECO #: MSCP12-36    zero  (no encryption) for that unit.  It should still be required
ECO #: MSCP12-36    to understand the meaning of the key fields.

ECO #: MSCP12-36    Knowing that a unit only supports key type zero is  no  different
ECO #: MSCP12-36    from  the current problem of knowing that the CDROM only supports
ECO #: MSCP12-36    key types  zero  and  one.   For  all  controllers  that  support
ECO #: MSCP12-36    encryption  the  host must "know" what key types it supports.  In
ECO #: MSCP12-36    effect this means that  users  must  not  request  encryption  or
ECO #: MSCP12-36    decryption  using  an  algorithm  that  isn't  supported  by  the
ECO #: MSCP12-36    controller.  There  is  no  way  to  determine  this  information
ECO #: MSCP12-36    through  MSCP  other  than  trying  out  a key type to see if the
ECO #: MSCP12-36    controller rejects it.

ECO #: MSCP12-36    As a minor point, we also have more spare controller  flags  than
ECO #: MSCP12-36    spare unit flags.
ECO #: MSCP12-36                                                                                                            Page 8




ECO #: MSCP12-36            ADDENDUM #3 (by Jim Zahrobsky)

ECO #: MSCP12-36    Change bars (|) denote changes from MSCP Version 1.2 Appendices A and B.

ECO #: MSCP12-36                                        Table A-1   Control Message Opcodes  

ECO #: MSCP12-36                +--------------------+--------------------------+-----------------------------------------+
ECO #: MSCP12-36                |    Opcode Value    |   Preferred Mnemonics    |                                         |
ECO #: MSCP12-36                | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Control Message Type                |
ECO #: MSCP12-36                +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           |  35  |  43  |  23  | OP.RCE | MSCP$K_OP_RCEDC | READ CONTROLLER ENCRYPTION/DECRYPTION   |
ECO #: MSCP12-36    |           |      |      |      |        |                 | CODE Command                            |
ECO #: MSCP12-36                                                     .

ECO #: MSCP12-36                                           Table A-2   Command Modifiers 

ECO #: MSCP12-36                +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-36                | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-36                |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Command Modifier                   |
ECO #: MSCP12-36                +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           | SET CONTROLLER CHARACTERISTICS Command Modifiers:                                       |
ECO #: MSCP12-36    |           |   0  |     1 |    1 | MD.FKC | MSCP$x_MD_FKC   | Flush Encryption/Decryption Key Cache  |
ECO #: MSCP12-36                                                     .

ECO #: MSCP12-36                                                Table A-4   Controller Flags

ECO #: MSCP12-36                +------+--------------+--------------------------+----------------------------------------+
ECO #: MSCP12-36                | Bit  |   Bit Mask   |   Preferred Mnemonics    |                                        |
ECO #: MSCP12-36                |Number| Octal | Hex. | 16 bit |32 bit (see note)|     Controller Flag                    |
ECO #: MSCP12-36                +------+-------+------+--------+-----------------+----------------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           |  14  | 40000 | 4000 | CF.EDC | MSCP$x_CF_EDCRP | Data Encrypt/Decrypt                   |
ECO #: MSCP12-36                                                     .

ECO #: MSCP12-36                                            Table A-6   Command Message Offsets

ECO #: MSCP12-36                +--------------------+--------------------------+-------+---------------------------------+
ECO #: MSCP12-36                |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
ECO #: MSCP12-36                | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
ECO #: MSCP12-36                +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           | COMPARE CONTROLLER DATA, COMPARE HOST DATA, ERASE, READ, and WRITE Command Message      |
ECO #: MSCP12-36    |           | Offsets (extention for controllers that support Data Encrypt/Decrypt):                  |
ECO #: MSCP12-36    |           |  32  |  40  |  20  | P.KID  | MSCP$L_KEY_ID   |   4   | Key identifier                  |
ECO #: MSCP12-36    |           |  36  |  44  |  24  | P.KLGH | MSCP$L_KEY_LGH  |   4   | Key length                      |
ECO #: MSCP12-36    |           |  40  |  50  |  28  | P.KBUF | MSCP$L_KEY_BUF  |  12   | Key buffer descriptor           |
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                                                                            Page 9


ECO #: MSCP12-36                                   Table A-7   End and Attention Message Offsets  

ECO #: MSCP12-36                +--------------------+--------------------------+-------+---------------------------------+
ECO #: MSCP12-36                |    Offset Value    |   Preferred Mnemonics    | Field |                                 |
ECO #: MSCP12-36                | Dec. | Oct. | Hex. | 16 bit |      32 bit     | Size  | Field Description               |
ECO #: MSCP12-36                +------+------+------+--------+-----------------+-------+---------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           | READ CONTROLLER ENCRYPT/DECRYPT CODE End Message Offsets:                               |
ECO #: MSCP12-36    |           |  32  |  40  |  20  | P.CLGH | MSCP$L_CODE     |   4   | Encrypt/Decrypt Code Length     |
ECO #: MSCP12-36                                                     .



ECO #: MSCP12-36                                   Table B-1   Status and Event Codes

ECO #: MSCP12-36                +--------------------+--------------------------+-----------------------------------------+
ECO #: MSCP12-36                |       Value        |   Preferred Mnemonics    |                                         |
ECO #: MSCP12-36                | Dec. | Oct. | Hex. | 16 bit |     32 bit      |     Status or Event Code                |
ECO #: MSCP12-36                +------+------+------+--------+-----------------+-----------------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           |   16 |   20 |   10 | ST.RDT | MSCP$K_ST_RDTRN | Record Data Truncated                   |
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           |   21 |   25 |   15 | ST.PRM | MSCP$K_ST_IPARM | Invalid Parameter                       |
ECO #: MSCP12-36    |           |   22 |   26 |   16 | ST.NFW | MSCP$K_ST_NFW   | Access Denied                           |
ECO #: MSCP12-36                                                     .


ECO #: MSCP12-36                               Table B-2   Standard Status Sub-code Values 

ECO #: MSCP12-36                +------+---------------------+---------------------------------------------------------+
ECO #: MSCP12-36                | Sub- |   Code + Sub-code   |                                                         |
ECO #: MSCP12-36                | code | Dec. |  Oct. | Hex. |                 Status Sub-Code                         |
ECO #: MSCP12-36                +------+------+-------+------+---------------------------------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           | "Record Data Truncated sub-code values:                                              |
ECO #: MSCP12-36    |           |    0 |   16 |    20 |   10 | Sub-codes are not used.                                 |
ECO #: MSCP12-36                |      |      |       |      |                                                         |
ECO #: MSCP12-36    |           | "Invalid Parameter" sub-code values:                                                 |
ECO #: MSCP12-36    |           |    1 |   53 |    65 |   35 | Invalid key length.                                     |
ECO #: MSCP12-36    |           |      |      |       |      |   The key length is too short  for  the  specified  key |
ECO #: MSCP12-36    |           |      |      |       |      |   type.                                                 |
ECO #: MSCP12-36    |           |    2 |   85 |   125 |   55 | Invalid key type.                                       |
ECO #: MSCP12-36    |           |      |      |       |      |   The controller does not implement the  specified  key |
ECO #: MSCP12-36    |           |      |      |       |      |   type.                                                 |
ECO #: MSCP12-36    |           |    3 |  117 |   165 |   75 | Invalid key value.                                      |
ECO #: MSCP12-36    |           |      |      |       |      |   A checksum or similar means indicates  that  the  key |
ECO #: MSCP12-36    |           |      |      |       |      |   value is internally inconsistent.                     |
ECO #: MSCP12-36                |      |      |       |      |                                                         |
ECO #: MSCP12-36    |           | "Access Denied" sub-code values:                                                     |
ECO #: MSCP12-36    |           |    0 |   22 |   26  |   16 | Sub-codes are not used.                                 |
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                                                                           Page 10


ECO #: MSCP12-36                                 Table B-6   "Host Buffer Access Error" Sub-code Values   

ECO #: MSCP12-36                +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-36                | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-36                | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-36                +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36                                                     .
ECO #: MSCP12-36    |           +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-36    |           | Note: The high order four bits of the "sub-code" field, Bits  8 - 11,  identify  the |
ECO #: MSCP12-36    |           |       command message buffer descriptor in use when the "Host Buffer  Access"  error |
ECO #: MSCP12-36    |           |       occurred. The value represents the descriptor's ordinal  position  within  the |
ECO #: MSCP12-36    |           |       command message (i.e., 0 = primary, 1 = secondary, etc.).                      |
ECO #: MSCP12-36    |           +------+-------------------------------------------------------------------------------+
ECO #: MSCP12-36                                                     .


   <<End ECO #: MSCP12-36 Data Encryption>>


   <<ECO #: MSCP12-37 Host BBR Error Log Usage [approved 19 October 1984]>> 


ECO #: MSCP12-37    VMS Development has  investigated  using  the  Bad  Block  Replacement
ECO #: MSCP12-37    Attempt   error   log  message  format  approved  for  usage  by  MSCP
ECO #: MSCP12-37    controllers at the 10 August 1984 MSCP  Woods  Meeting.   We  wish  to
ECO #: MSCP12-37    build  error log messages of this format whenever VMS attempts a host-
ECO #: MSCP12-37    initiated bad block replacement operation.  This appears  to  be  very
ECO #: MSCP12-37    practical  with  one  execption.   VMS  cannot  generate  a reasonable
ECO #: MSCP12-37    sequence number -- MSCP error log message field MSLG$W_SEQ_NUM.  As an
ECO #: MSCP12-37    alternative,  we  propose  providing  a sequence number field will all
ECO #: MSCP12-37    bits set (numeric value -1).

ECO #: MSCP12-37    The description of the error log message sequence number field  (found
ECO #: MSCP12-37    in  Section  8.1  of  the  MSCP  Specification)  describes the primary
ECO #: MSCP12-37    functions of sequence number as related  to  detecting  communications
ECO #: MSCP12-37    problems.   This  does not apply to a host attempting to make an entry
ECO #: MSCP12-37    in its own error log.  Also, the host has no mechanism to  communicate
ECO #: MSCP12-37    with  the  controller  which  requested  the  host-initiated bad block
ECO #: MSCP12-37    replacement for the purpose of "synchronizing" sequence number values.
ECO #: MSCP12-37    VMS  further  believes that this problem does not warrant invention of
ECO #: MSCP12-37    such a mechanism.

ECO #: MSCP12-37    A possible enhancement to this proposal is addition  of  a  flags  bit
ECO #: MSCP12-37    indicating  that  this  munging  of  the  sequence number has occured.
ECO #: MSCP12-37    However, I also believe that to do so constitutes frivolous use  of  a
ECO #: MSCP12-37    scarce resource, flags bits.

ECO #: MSCP12-37    To ensure that this usage of sequence number is  publicly  documented,
ECO #: MSCP12-37    VMS  respectfully  requests  that the following waiver be reviewed and
ECO #: MSCP12-37    approved by the MSCP review process.

ECO #: MSCP12-37           "VAX/VMS implements usage of the Bad  Block  Replacement
ECO #: MSCP12-37           Attempt  error  log  message  format  for host-initiated
ECO #: MSCP12-37           replacement operations  performed  by  VMS.   Error  log
ECO #: MSCP12-37           messages  so  generated  supply  all  messages fields in
ECO #: MSCP12-37           conformance to the MSCP specification with the execption
ECO #: MSCP12-37           of  the  sequence  number field.  In VMS generated error
ECO #: MSCP12-37           log messages, the sequence number field has all bits set
ECO #: MSCP12-37           (numeric value -1)."


   <<End ECO #: MSCP12-37 Host BBR Error Log Usage>>

   <<ECO #: MSCP12-38 Host BBR RCT Full Error Code [approved 19 October 1984]>>


ECO #: MSCP12-38    During  implementation  of  host-generated   Bad   Block   Replacement
ECO #: MSCP12-38    Attempted error log entries for host-initiated bad block replacements,
ECO #: MSCP12-38    VMS Development has been unable to find a way to report failure  of  a
ECO #: MSCP12-38    bad  block  replacement  attempt  due  to lack of a replacement block.
ECO #: MSCP12-38    Therefore, we request the addition of a sub-code for  "No  replacement
ECO #: MSCP12-38    block  available" to Table B-9, "Bad Block Replacement Completion Sub-
ECO #: MSCP12-38    code Values."  The exact sub-code value should be assigned by  Storage
ECO #: MSCP12-38    Architecture.

ECO #: MSCP12-38    N.B.  this sub-code may conflict with the Media Format Error  sub-code
ECO #: MSCP12-38    of the same name.  However, we believe it inappropriate to use a Media
ECO #: MSCP12-38    Format Error event code in a Bad Block Replacement Attempted error log
ECO #: MSCP12-38    entry.
ECO #: MSCP12-38                                                                                            Page 2
ECO #: MSCP12-38            ADDENDUM (by Jim Zahrobsky)

ECO #: MSCP12-38   Change bars (|) denote changes from MSCP Version 1.2 Appendix B as amended by ECO #: MSCP12-33.

ECO #: MSCP12-38           Table B-9   "Bad Block Replacement Completion" Sub-code Values  

ECO #: MSCP12-38   +------+---------------------+-+-+-----------------------------------------------------+
ECO #: MSCP12-38   | Sub- |   Code + Sub-code   |E|S|                                                     |
ECO #: MSCP12-38   | code | Dec. |  Oct. | Hex. |V|T|     Status or Event Sub-Code                        |
ECO #: MSCP12-38   +------+------+-------+------+-+-+-----------------------------------------------------+
ECO #: MSCP12-38                                        .
ECO #: MSCP12-38                                        .
ECO #: MSCP12-38 | |    5 |  180 |   264 |   B4 |*| | Replacement failure, no replacement block available.|
ECO #: MSCP12-38 | |      |      |       |      | | |   Replacement  was attempted for a bad block, but a |
ECO #: MSCP12-38 | |      |      |       |      | | |   replacement block  could not  be allocated (i.e., |
ECO #: MSCP12-38 | |      |      |       |      | | |   the volume's RCT is  full).                       |
ECO #: MSCP12-38                                        .


   <<End ECO #: MSCP12-38 Host BBR RCT Full Error Code>>


   <<ECO #: MSCP12-39 TU81 Waiver Request [approved 19 October 1984]>>



ECO #: MSCP12-39       The TU81 is requesting a permanent waiver for the following.

ECO #: MSCP12-39       1.   The TU81 doesn't support the "Enable Miscellaneous Error Log
ECO #: MSCP12-39            Messages" modifier. If the modifier is set the TU81 dosn't
ECO #: MSCP12-39            echo the bit in OP.SCC end messages. The TU81 dosn't generate
ECO #: MSCP12-39            miscellaneous error logs with the modifier in any state.

ECO #: MSCP12-39                        See MSCP V1.2 Section 6.2, Page 6-4, Lines  8-11  and
ECO #: MSCP12-39                        Section 5.8, Page 5-22, Lines 15-18.

ECO #: MSCP12-39         System impact

ECO #: MSCP12-39                 This problem has no system impact. The TU81 doesn't perform
ECO #: MSCP12-39            spontaneous health checks, etc. and therefore will not produce
ECO #: MSCP12-39            an error log that is not associated with a command reference
ECO #: MSCP12-39            number. Therefore the TU81 has no need to support this feature.
           

   <<ECO #: MSCP12-39 TU81 Waiver Request>>
   <<End ECOs>>