Trailing-Edge
-
PDP-10 Archives
-
QT020_T20_4.1_6.1_SWSKIT_851021
-
swskit-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>>