Appendixes (These Appendixes are not part of the requirements of American National Standard X3.131-198x, but are included for information only.) A. SCSI Signal Sequence Example This Appendix is included to provide an example of the signal sequencing of an I/O process that includes most of the SCSI bus phases (Figure A-1). In this example, the target does not disconnect from the SCSI bus prior to completing the I/O process. The following notes apply to Figure A-1: NOTE: In a typical system, the computer's host adapter acts as the "initiator" and the peripheral device's controller acts as the "target." In general, this standard does not attempt to distinguish between a computer and its host adapter. These functions may be separate or merged. The term "initiator" encompasses both. The term "target" refers to the controller portion of the peripheral device, which may be separate (bridge controller) from the peripheral device or merged with it (embedded controller). The term "SCSI device" refers to a device that may be connected to the SCSI bus. An SCSI device may act in the initiator role, the target role, or both roles. Figure A-1: SCSI Signal Sequence Example DATA BUS NOTES: (1) DB(7) is the most significant bit. (2) DB(7) is the highest priority arbitration bit. (3) DB(P) is the data parity bit (odd). Parity is not valid during the ARBITRATION phase. BUS PHASE NOTES: BUS FREE phase. BUS FREE phase begins when the SEL and BSY signals are both continuously false for a bus settle delay. It ends when the BSY signal becomes true. (In the SCSI-1 single-initiator option, BUS FREE phase could also end when the SEL signal became true.) ARBITRATION phase. This phase is documented as mandatory in SCSI-2. In SCSI-1, this phase was optional. At least one bus free delay after first detecting BUS FREE phase, but no more than a bus set delay after the bus was last free, the initiator asserts the BSY signal and its assigned SCSI device ID bit on the DATA BUS. The initiator waits an arbitration delay, then examines the DATA BUS. If a higher priority SCSI device ID bit is true, the initiator loses arbitration and may release the BSY signal and its SCSI ID bit. Otherwise, the initiator wins arbitration and asserts the SEL signal. All SCSI devices must release the BSY signal and their SCSI ID bit within a bus clear delay after the SEL signal becomes true (even if they have not yet examined the DATA BUS). The winning SCSI device waits at least a bus clear delay plus a bus settle delay after asserting the SEL signal before changing any signals on the bus. SELECTION phase. The I/O signal is false during this phase to distinguish it from the RESELECTION phase. NONARBITRATING SYSTEMS (only permitted in SCSI-1): In such systems, the initiator waits at least a bus clear delay after detecting BUS FREE phase, then it asserts the target's SCSI ID bit and, optionally, the initiator's SCSI ID bit on the DATA BUS. After at least two deskew delays, the initiator asserts the SEL signal. ARBITRATING SYSTEMS: In such systems, the SCSI device that won arbitration has both the BSY and SEL signals asserted. After at least a bus clear delay plus a bus settle delay, it places both the target's and the initiator's SCSI ID bits on the DATA BUS. At least two deskew delays later, it releases the BSY signal. ALL SYSTEMS: The target determines that it is selected when the SEL signal and its SCSI ID bit are true and the BSY and I/O signals are false for at least a bus settle delay. The target then asserts the BSY signal within a selection abort time after it last determined that it was still being selected. (The target is not required to respond to a selection within a selection abort time; but it must ensure that it will not assert the BSY signal more than a selection abort time after the initiator aborts a selection attempt.) At least two deskew delays after the initiator detects the BSY signal is true, it releases the SEL signal. MESSAGE OUT phase. During this phase the initiator sends an IDENTIFY message to the target. The target asserts the C/D and MSG signals and negates the I/O signal for the message transfer. After detecting the assertion of the REQ signal, the initiator negates the ATN signal before asserting the ACK signal. (Refer to the handshake procedure for the COMMAND phase.) COMMAND phase. The target asserts the C/D signal and negates the I/O and MSG signals for all of the bytes transferred during this phase. The direction of transfer is from the initiator to the target. HANDSHAKE PROCEDURE: The target asserts the REQ signal. Upon detecting the REQ signal is true, the initiator drives the DATA BUS to the desired value, waits at least one deskew delay plus a cable skew delay and then asserts the ACK signal. The initiator continues to drive the DATA BUS until the REQ signal is false. When the ACK signal is true at the target, the target reads the DATA BUS and then negates the REQ signal. When the REQ signal becomes false at the initiator, the initiator may change or release the DATA BUS and negate the ACK signal. The target may continue to request command bytes by asserting the REQ signal again. The number of command bytes is determined by the group code (most significant 3 bits) that is contained in the first command byte. DATA IN phase. The target asserts the I/O signal and negates the C/D and MSG signal for all of the bytes transferred during this phase. The direction of transfer is from the target to the initiator. HANDSHAKE PROCEDURE: The target first drives the DATA BUS to their desired values, waits at least one deskew delay plus a cable skew delay, and then asserts the REQ signal. The target continues to drive the DATA BUS until the ACK signal is true. When the REQ signal is true at the initiator, the initiator reads the DATA BUS and then asserts the ACK signal. When the ACK signal is true at the target, the target may change or release the DATA BUS and negate the REQ signal. When the REQ signal is false at the initiator, the initiator negates the ACK signal. After the ACK signal is false, the target may continue the transfer by driving the DATA BUS and asserting the REQ signal as described above. DATA OUT phase (not shown in the figure). The target negates the C/D, I/O, and MSG signals for all of the bytes transferred during this phase. The direction of transfer is from the initiator to the target. (Refer to the handshake procedure for the COMMAND phase.) STATUS phase. The target asserts the C/D and I/O signals and negates the MSG signal for the byte transferred during this phase. The direction of transfer is from the target to the initiator. (Refer to the handshake procedure for the DATA IN phase.) MESSAGE IN phase. The target asserts the C/D, I/O, and MSG signals during the byte transferred during this phase. Typically, a COMMAND COMPLETE message would be sent at this point. The direction of transfer is from the target to the initiator. (Refer to the handshake procedure for the DATA IN phase.) BUS FREE phase. The target returns to BUS FREE phase by releasing the BSY signal. Both the target and the initiator release all bus signals within a bus clear delay after the BSY signal is continuously false for a bus settle delay. B. Typical Bus Phase Sequence This Appendix is included to provide an example of the SCSI bus phase sequence for a typical READ command (Tables B-1 and B-2). In this example, the target does not disconnect from the SCSI bus prior to completing the command. Table B-1: Typical READ Command Phase Sequence ============================================================================== Signals --------------------------------------------------------------- B S A M C I R A R D D S E T S / / E C S B B Bus Phase Y L N G D O Q K T (7-0) (P) Comment ------------------------------------------------------------------------------ BUS FREE - - - - - - - - - - - SCSI bus is available. ARBITRATION 1 - - - - - - - - ID X Initiator tries to get " 1 the SCSI bus. SELECTION 1 1 1 - - - - 0 - ID I,T V Initiator has SCSI bus " - 1 ID I,T V and selects a target. " 1 1 ID I,T V ATN is on. " 1 - X X MESSAGE OUT 1 - 1 1 1 0 0 0 - X X Target has control of " 1 1 0 X X the bus and gets the " 0 1 1 Message V IDENTIFY message from " 0 0 1 X X the initiator. " 0 0 0 X X COMMAND 1 - 0 0 1 0 0 0 - X X Target gets a command " 1 0 X X byte from the " 1 1 Command V initiator. (This " 0 1 X X handshake is repeated " 0 0 X X for each byte.) ============================================================================== Table B-2: Typical READ Command Phase Sequence (Continued) ============================================================================== Signals --------------------------------------------------------------- B S A M C I R A R D D S E T S / / E C S B B Bus Phase Y L N G D O Q K T (7-0) (P) Comment ------------------------------------------------------------------------------ DATA IN 1 - 0 0 0 1 0 0 - X X Target sends data to " 1 0 Read Data V the initiator. (This " 1 1 X X handshake is repeated " 0 1 X X for each byte.) " 0 0 X X STATUS 1 - 0 0 1 1 0 0 - X X Target sends status to " 1 0 Status V the initiator. " 1 1 X X " 0 1 X X " 0 0 X X MESSAGE IN 1 - 0 1 1 1 0 0 - X X Target sends a COMMAND " 1 0 Message V COMPLETE message to the " 1 1 X X initiator. " 0 1 X X " 0 0 X X BUS FREE - - - - - - - - - - - SCSI bus is available. ============================================================================== Key: - = Signal driver is passive. 0 = Signal is false. 1 = Signal is true. "Blank" = Signal state is the same as the previous line. ID = SCSI ID for arbitration. ID I,T = SCSI ID of initiator and target. V = Parity is valid. X = The signal is not guaranteed to be in a known state. C. SCSI System Operation This Appendix is included to provide an explanation of the relationship of the various pieces of an SCSI system. This Appendix also provides additional information about the use of SCSI in a multi-tasking system. Such systems typically use a host adapter circuit to interface from the host memory to the SCSI bus. Although other architectures are possible (including native or embedded SCSI), the host adapter logic still exists as part of the system. The term "initiator" is used throughout this standard to encompass all such architectures. The term "host adapter" is used within this Appendix to refer to the logic that interfaces from the host memory to the SCSI bus. C.1. Host Memory, Host Adapter, SCSI Target Relationship The SCSI architecture utilizes the concept of host memory blocks for command, data, and status interchange between the host system and the SCSI target. In the middle of this exchange is the SCSI host adapter, which acts as the gateway between host memory and the SCSI bus. The host adapter is an important portion of the overall intelligence of SCSI. Along with providing an information path from the SCSI bus to the host bus, the host adapter is intimately involved in assuring data integrity and proper performance of the I/O subsystem. In order to fully understand SCSI operation, the concepts of I/O memory blocks and nexus are detailed. Figure C1 presents an example block diagram of a single host/single peripheral SCSI I/O subsystem. The host memory contains three I/O blocks: command, data, and status. The SCSI disk controller target needs to read the command block and write to the status block in order to perform the task specified by the host in the command block. Likewise, the SCSI controller needs to either read or write the data block in host memory, depending on the task specified. The SCSI controller "reaches into host memory" via the SCSI host adapter. The host adapter must know the addresses of the command, data, and status blocks in order for it to "reach" into the right spot in memory. In other words, the host adapter must be given a pointer to the start of each block by the host. As the SCSI controller takes information from the command block, the memory pointer for the command block advances to the next byte. The same is true for the data and status pointers. SCSI architecture provides for two sets of three pointers within the host adapter. The first set is known as the current (or active) pointer values. These are the pointers to the next command, data, or status byte to be transferred between the host memory and the SCSI controller. There is only one set of current pointers in the host adapter. The current pointers are shared among all devices and are used by the current device connected to the host adapter. The second set is known as the saved pointer values. There is one set of saved pointers for each active I/O process. For command and status, these pointers always point to the start of the memory command block and memory status block. The saved data pointer points to the start of the data block at the beginning of each command. It remains at this value until the controller sends a SAVE DATA POINTER message to the host adapter which copies the value of the current data pointer into the saved data pointer. The controller may retrieve the saved value by sending a RESTORE POINTERS message. This moves the value of each of the three saved pointers into the current pointers. Whenever an SCSI device disconnects from the bus, only the saved pointer values are retained. The current pointer values are set from the saved values upon the next reconnection. The current and saved pointers provide an efficient method to break up large transfers into smaller bursts, and to facilitate error retry and recovery. C.2. SCSI READ Command Example One method of understanding the "host, host adapter, SCSI controller" relationship is via an example. Consider the case of a multiple sector READ command that will cross a cylinder boundary on a direct-access device such as a disk. The first activity in the I/O operation is for the system to create a command descriptor block in memory and determine where the data and status are to be written in host memory. The host then sends a command to the host adapter that includes the starting address (pointer) for each of the command, data, and status blocks and the SCSI address of the peripheral to perform the operation. In this example, there is only one SCSI controller and physical disk, but its address is required in order for the host adapter to select it. Upon receiving the command, the host adapter arbitrates for the SCSI bus and wins (due to the lack of competing devices) and proceeds to select the target SCSI device with the ATN signal asserted. The ATTENTION condition indicates to the SCSI target that the initiator (the host adapter) has a message to send to the target. When the target responds to the SELECTION phase, an I_T nexus is established between the two devices. After the SELECTION phase is completed, the target responds to the initiator's ATTENTION condition by receiving an IDENTIFY message from the initiator. This message, generated by the host adapter, indicates the desired logical unit number in the target and whether the initiator can support bus disconnect. In this example, the initiator supports disconnect. When the controller receives the IDENTIFY message, an I_T_L nexus is established. The nexus uniquely identifies the relationship between the initiator and the specified logical unit of the target disk controller. An additional message following the IDENTIFY may be sent for purposes of command queuing. If a QUEUE TAG message is sent, the I_T_L nexus is replaced by an I_T_L_Q nexus. This I_T_L_Q nexus behaves in a similar manner as the I_T_L nexus for purposes of pointer management; it merely permits more sets of pointers to be identified. In this example, however, command queuing is not used. Input/output activity from this point are principally controlled by the target. The host adapter is simply an "arm" of the target used to reach into host memory. Utilizing this arm, the target reads in the command descriptor block (CDB). The host adapter is expected to ensure that the target does not reach outside its allocated blocks. After decoding the instruction, the controller determines that a disk seek is required to get the starting data block. Since the SCSI bus will not be utilized until data has been read from the disk, the target controller disconnects from the bus. The disconnect process includes the transmission of a SAVE DATA POINTER message and DISCONNECT message from the target to the host adapter. The host adapter responds to the SAVE DATA POINTER message by saving the current data pointer, which is still set to the start of the data block. (Strictly speaking, the target need not send the SAVE DATA POINTER message following the command phase since at that time the saved and current pointers are equal.) After transmission of the DISCONNECT message the target releases the BSY signal, freeing the bus. Although the initiator host adapter and target disk controller are disconnected, the I/O process has not completed and the I_T_L nexus still exists. Both devices know they have a command to finish and will return to that job at a later point in time. The ability to disconnect allows multiple I/O processes to occur simultaneously, utilizing a single physical bus. The logical connection is actually not just between the host adapter and the disk controller, but runs all the way from the host memory I/O block to the peripheral device (disk) performing the operation. (See Figure C-2 for a pictorial presentation of this concept.) Once the target has started filling its data buffers, it can transmit data to the initiator, but first it must revived the connection. The reconnection process involves the target arbitrating for the bus and reselecting the host adapter. After the reselection is made, the target sends an IDENTIFY message to the host adapter to indicate which target logical unit is reconnecting. This information provides the correct logical connection via the I_T_L nexus into host memory. After reconnection, the roles of the initiator and target are just as they were prior to disconnection. The target transfers data into host memory via the host adapter. The data transfer continues until the disk reaches the end of its cylinder and the disk controller determines that a second physical seek is required to complete the READ command. The target again performs a SAVE DATA POINTER message and a DISCONNECT message. However, this time the current data pointer is not at the beginning of the memory data block, and is required to ensure that the I/O process continues at the correct data block location. The saved value at disconnect reflects the change. After seek completion and transfer of data into its buffer, the controller reconnects to the host adapter and completes the data transfer as requested by the READ command. At this point, the controller sends ending status into host memory via the host adapter. The final action of the target is to send the host adapter a COMMAND COMPLETE message and go to BUS FREE. The target has completed its operation and considers the I/O process ended. Upon receipt of the COMMAND COMPLETE message, the host adapter signals the host that the I/O process is complete. This signal can be an interrupt or the setting of a flag read by the host in a polled I/O environment. This action by the host adapter breaks the logical connection between the host adapter and the I/O memory blocks of the host. The host reviews the status of the operation in the status block and proceeds to utilize the data transferred into the data block. C.3. I/O Channel Concept The I/O channel concept fully utilizes the high performance capability of the SCSI. The I/O channel is basically an intelligent SCSI host adapter that can maintain multiple simultaneous I/O processes between host memory I/O blocks and different SCSI devices. The I/O channel utilizes a single direct memory access (DMA) path into host memory supporting the DMA operations of numerous SCSI peripherals. Since the SCSI bus is a single physical bus and most host computers have a single physical backplane bus, multiple DMA channels into memory are not necessary. In many implementations of a multiple DMA channel architecture, when a channel is accessing memory, all other channels are idle. In such implementations, a single channel supporting multiple I/O processes can supply the same performance as separate DMA peripherals. An obvious advantage to the host is lower system cost as well as the saving in backplane card slots. In the READ command example discussed in C.2, the I/O channel is the SCSI host adapter. The host gives the I/O channel a command by providing it with pointers to the I/O memory blocks and the SCSI peripheral address. This establishes a logical connection between the host adapter and the host I/O memory blocks. The I/O channel then opens a sub-channel that is assigned the task of managing the physical link and nexus between the host adapter and the target controller. All physical connections and reconnections to the host adapter are managed by this sub-channel. The number of active or open sub- channels an I/O channel can support is totally dependent upon its design. The SCSI definition could, in theory, support an I/O channel with up to 56 sub- channels for simple I_T_L nexus, and many more if target routines and command queuing are implemented. Figure C-1: Snapshot Prior to Initial Selection Figure C-2: Snapshot Prior to Data Transfer D. Additional Medium Type and Density Code Standards In Sections 8 and 9 of this standard, the MODE SELECT and MODE SENSE data define medium type codes and density codes for certain flexible disks and magnetic tapes. American National Standards are referenced for code values if a standard exists for that code value. In many cases, other standards or X3 draft documents also exist for a code value. Tables D-1 and D-2 in this Appendix provide additional references to those standards or draft documents. DISCLAIMER: It is not the purpose of this Appendix to indicate that these standards are exactly equivalent to each other. However, these standards may be useful. Please refer to Sections 8 and 9 for additional information. Table D-1: Direct-Access Medium-Type Codes ====================================================================== Code Medium Type ---------- ---------------------------------------------------------- 00h See Section 8. 01h See Section 8. 02h See Section 8. Flexible-Disk Reference Standard(s) 05h X3.73-1980 ECMA-54 ISO 5654-1 : 1984 ISO 5654-2 : 1985 06h ECMA-59 09h (None -- X3B8 has abandoned this project.) 0Ah X3.121-1984 ECMA-69 ISO 7065-1 : 1985 ISO 7065-2 : 1985 0Dh X3.82-1980 ECMA-66 ISO 6596-1 : 1985 ISO 6596-2 : 1985 12h X3.125-1985 ECMA-70 ISO 7487-1 : 1985 ISO 7487-2 : 1985 ISO 7487-3 : 1984 16h X3.126-1986 ECMA-78 DIS 8378/1-1984 DIS 8378/2 DIS 8378/3 1Ah X3B8/86-32 (Note 1) ECMA-99 DIS 8630/1-1985 DIS 8630/2-1985 1Eh X3.137 (Note 1) ECMA-100 DIS 8860/1-1985 DIS 8860/2-1985 Direct-Access Magnetic Tape Standard(s) ANSI ECMA ISO ------------------- -------------- ----------------- 40h X3B5/85-151 (Note 2) ECMA TC19/83/39 44h X3B5/85-151 (Note 2) ECMA TC19/83/39 80h-FFh Vendor unique All others Reserved ====================================================================== NOTES: (1) These listings are currently under development. Please check with the X3 Secretariat for information concerning status and availability. (2) This draft document is for unrecorded miniature cartridge media. The usage referred to here is for serial GCR recording using a format known as QIC-100. Since Subcommittee X3B5 issues a new document number for each revision of their working draft document, please contact the chairman of X3B5 for the latest document number. Table D-2: Sequential-Access Density Codes ============================================================================== Code Value Density ---------- ------------------------------------------------------------------ 00h See Section 9. Magnetic Tape Reference Standard(s) ANSI ECMA ISO -------------------------- --------- --------------------------- 01h X3.22-1983, ECMA-62, ISO 1863-1976 02h X3.39-1986, ECMA-62, ISO 3788-1976 03h X3.54-1986, ECMA-62, ISO 5652-1984 04h Old format known as QIC-11 05h X3.136-1986, ECMA-98 06h X3B5/85-194A (See Note) 07h X3.116-1986, ECMA-79, ISO 8063/1-1984 08h X3B5/86-099 (See Note) 09h X3B5/86-055 (See Note) 0Ah X3B5/85-88 (See Note) 0Bh X3.55-1982, X3.56-1986, ECMA-46, ISO 4057-1979 80h -- FFh Vendor unique All others Reserved ============================================================================== NOTE: Draft document. Subcommittee X3B5 assigns a new document number to each revision of their documents. Please contact the chairman of X3B5 for the latest document number. E. Data Integrity and I/O Process Queuing This Appendix demonstrates the practicality of having the target reorder I/O processes which have been queued for a specific logical unit under its control with a minimum of explicit direction by the initiator. A clear and precise written explanation was deemed appropriate. While this appendix is only directly applicable to direct-access devices, the same concepts can be applied to any SCSI device. This appendix is not intended to indicate how command queuing must be implemented by the target in order to insure correct execution. Rather, it simply illustrates one possible implementation that does insure correctness at a reasonable cost (in overhead and performance) and is easy to analyze. E.1. Glossary Unless otherwise stated, all terms used in this Appendix are as defined in the body of this standard. The following terms are new: correct execution sequence. Any sequence of execution from the I/O process queue(s) for a logical unit that both obeys the rules for I/O process queuing and which results in the state of the media, and the data returned to the initiator concerning the contents of the media, to be identical to those of a first-in first-out (FIFO) execution of the primary queue. NOTE: The state of other components of the target, such as the buffer, are not guaranteed to the be same under different re-orderings that result in correct execution. explicit ordered I/O process. This is an I/O process that includes an ORDERED QUEUE TAG message. implicit ordered I/O process. This is an I/O process that includes a SIMPLE QUEUE TAG message, but the target has determined it will treat as an ordered I/O process for the purposes of queuing. head of queue queue. This is the queue for a specific logical unit containing head of queue I/O processes for that logical unit. LBA. An abbreviation for "logical block address". ordered I/O process. This is an explicit or implicit ordered I/O process. primary queue. This is the queue for a specific logical unit containing the ordered and unordered I/O processes for that logical unit. Each primary queue can be divided into a series of one or more segments. Each segment normally consists of a sequence of I/O processes containing zero or more unordered I/O processes and one ordered I/O process such that the ordered I/O process is the last in the sequence and the unordered I/O processes are those which arrived after the ordered I/O process of the previous segment in the queue and before the ordered I/O process in this segment. The last segment in the queue is a special case which may not include an ordered I/O process. For example, a queue containing commands in the following order: U U O O U O U O O O U U U U U can be divided into segments as follows: (U U O) (O) (U O) (U O) (O) (O) (U U U U U) where, "U" represents an unordered command and "O" represents an ordered command. regeneration point. The point in time when no command is under execution and the first I/O process of a new segment in the primary queue is the next I/O process to be executed. reordering rule. The algorithm used by a target to reorder commands in the primary queue of a logical unit. state of the media. At any particular moment, the state is defined to be the complete mapping of logical block addresses to the data stored in those logical block addresses. Thus the state is a measure of the contents of the device. TL. An abbreviation for "transfer length". E.2. Thesis The point of this Appendix is that the target can implement reordering rules which result in a correct execution sequence at: (1) low cost in command overhead, (2) high improvement in performance, and (3) without requiring the initiator to explicitly order commands (although such ordering is allowed). Under any reordering rule, only the reordering done within a queue segment can make the execution sequence incorrect. This follows directly from the definitions in the above glossary and the entire philosophy of I/O process queuing, under which the explicit ordering of a I/O process or the use of a head of queue I/O process indicates that the initiator is removing any control of order of execution from the target. Doing so shifts any risk that the resulting execution sequence may be "incorrect" from the target to the initiator. A sequence of execution is correct if for each queue segment the execution of I/O processes in that segment, if considered to be the total queue for the logical unit, would be considered to be correct. Since the order of execution of head of queue I/O processes and the order of execution of queue segments is restricted to a single ordering by the rules of I/O process queuing, only reordering within a segment can create a deviation from the FIFO primary queue execution sequence which is always correct. Assume all unordered I/O processes other than those containing READ(6), READ(10), WRITE(6), and WRITE(10) commands to be implicitly ordered by the target. (For simplicity, "read" is used for "READ(6) or READ(10)" and "write" is used for "WRITE(6) or WRITE(10)" in the following section.) Note that this assumption does not significantly decrease the performance gains to be realized by reordering (since the remaining unordered I/O processes still make up over 99.9% of the I/O processes actually encountered during normal execution), nor increase the overhead (since a simple operation code check is all that is required), but will significantly simplify the analysis of reordering rules. Targets might be able to insure correct execution sequence without this restriction, but allowing such commands as MODE SELECT, RESERVE/RELEASE, and FORMAT to be reordered obviously leads to potential difficulties and much complexity for little gain. The test for correct execution is made at regeneration points. Note that I/O processes cannot be reordered across regeneration points. This implies that halting execution (e.g., for an error) in the middle of a queue segment may leave the state of the media in an incorrect state. As always, it is up to the initiator to successfully perform recovery operations. All segments (except for the last, which is treated as a special case) are finite, and any reordering algorithm eventually results in reaching a regeneration point. For the last segment, the target insures that all commands are executed in a finite period of time (i.e., starvation does not occur). Many popular reordering algorithms prevent starvation, and the assumption is that one such algorithm is implemented. Thus the problem has been reduced to requiring that the reordering of I/O processes within a segment does not result in the return of data which differs from that of a FIFO execution nor leaves the media in a different state. Note that under any reordering of a segment, the ordered command is always constrained to be executed last. Thus as long as the data returned and the state of the media for the sequence of unordered I/O processes meets the correctness criteria, then the I/O processes in the segment as a whole are correctly executed. All unordered I/O processes in a segment contain a variety of either the read or write commands. Consider the N unordered I/O processes in a segment to be numbered 1 to N. Then any reordering is uniquely defined by the N! (N factorial) ordered pairs of I/O processes (x,y), where each pair implies that I/O process x comes before I/O process y in the reordering. If all the pairs were (read,read) pairs (i.e., all unordered commands were reads), then any reordering could not affect the state of the media (since it is never changed) nor the returned data. Similarly, if a pair was a (read,write), a (write,read), or a (write,write) then the reordering of these two commands could not affect correctness as long as the range of the specified logical block addresses for each command did not intersect. Thus the above is both a necessary and sufficient condition for generating a correct execution sequence. However, the target need not generate the N! pairs and perform the check required by theory. A more practical implementation of the above test would be the following: First, any reordering of I/O processes implies that a sorting operation (usually with respect to the LBA of the command) be performed. The sort may result in an explicit data structure (i.e., a binary tree of pointers) or an implicit structure (i.e., the command descriptor blocks are reordered in an array, or an array of pointers to command descriptor blocks are reordered). In any event, denote T as the time required to perform such sorting, and denote A as the resulting sequence of execution. This list is now sorted so that the LBA+TL of the immediately preceding command is <= the LBA of the next command. Note that LBA+TL is one more than the last LBA in the command, and this sort can be performed at a cost no greater than T (note that LBA+TL must be computed for each command anyway in order to perform a range check against the logical unit's maximum LBA, and that a more sophisticated data structure can reduce the incremental effort to perform this second sort considerably). This ordering is denoted as B. For each segment, a I/O process has a position in both queues denoted by the pair (a,b). The execution sequence is then determined as follows: 1) Attempt to execute I/O process in the ordering determined by A. 2) If a = b, then execute the I/O process. 3) If a < b, then scan A until a command equaling b is found. For all commands in A between a and this b, search B and keep track of the I/O process that appears last in B (denote this c). Now scan A again, but use c as the search target instead of b. Continue the search process, alternating between A and B, until all I/O processes to search for are exhausted. The result is a subsequence of I/O processes in A and B such that each I/O process in the subsequence in A appears in the subsequence in B and vice-versa, but the orders differ between the subsequences. These I/O processes should be executed in the original FIFO order (i.e., both re-orderings should be ignored). 4) when done, go to step 1) again until the queue is empty. As an example, considering the following pairs of ordered LBA ranges: (0,3) (6,8) (7,12) (8,15) (20,23) (28,32) (31,35) (36,39) (37,38) (0,3) (7,12) (6,8) (8,15) (20,23) (31,35) (28,32) (37,38) (36,39) Thus the execution order is: (0,3) (6,8) (7,12) in FIFO order (8,15) (20,23) (28,32) (31,35) in FIFO order (36,39) (37,38) in FIFO order Note that other execution sequences may be defined that provide greater performance (i.e., (read,read) sequences can be freely reordered) at a cost of greater overhead. But in the normal case of few intersections, the total overhead is 2*T plus a check per I/O process (this can grow to N*N checks in the worse case). Finally, overhead should not be an issue in I/O process queuing. Overhead grows as the queue lengthens, but the opportunity to overlap queuing tasks with seek time and rotational latency also grows with the queue length. Thus most, if not all, of the queuing overhead can be effectively hidden. Explicit ordering of I/O processes by the initiator can shift the the implementation burden from target to initiator, and this may have many practical benefits. Error recovery might prove easier to implement, and target resources might be more profitably used. F. Power On Protocols - Recommended Initialization Procedure This appendix describes the normal mechanisms for obtaining the information required for system initialization from SCSI-2 devices as well as all SCSI devices meeting conformance level 2 as defined in Appendix E of SCSI-1. This procedure documents the steps required to obtain this information and to achieve the desired initial states in the attached devices. F.1. System Initialization The following list of information is assumed necessary and sufficient for normal system initialization: 1) A list of each installed and powered on SCSI device for each SCSI address. SCSI devices that are not power-on are treated as not installed, assuming that the terminators are powered from a source other than the power-off SCSI devices. 2) A list of the installed logical units for each SCSI device. Power-off or failing logical units may not be completely identifiable. 3) The device type for each available logical unit. 4) The manufacturer and model for each available logical unit. (This information may not be available for SCSI-1 devices) 5) The critical device type information for each available logical unit. This information varies depending on the device type. 6) Extended functionality of SCSI devices such as target role capability in devices that are principally initiators, AEN capability, etc. The following states are established for each attached logical unit that has power available and is not failing: 1) The ready state for each available logical unit, including any required medium initialization, but not formatting. 2) All error conditions associated with the starting process are cleared. 3) All UNIT ATTENTION conditions are cleared. 4) All data transfer parameters are established. 5) All pertinent system tuning parameters are established where known. Note that these may be modified dynamically to improve the performance characteristics of the system. The following procedures show the sequences necessary to implement a system that initializes itself with a minimum of information available at power-on. In reality many systems are not as generalized, and have considerable information available about the configuration at power-on. In those cases, the sequence steps that would have been necessary to obtain information about the configuration may be skipped or ignored. F.2. General Procedure for Initializing Devices The system should execute the following steps to perform initialization. Some of the steps are detailed in subsequent paragraphs. Note that the text represents a primitive pseudo-code that can be converted to the appropriate software object code by those who implement device drivers. F.2.1. General Procedure Executed by Initiators Initiator Activities: Power On: It is assumed that each SCSI device, as it is powered on, performs appropriate internal reset operations and internal test operations. Once powered on, initiators that have target capability should be prepared to respond to a selection within a system-specific time. Reset: At power-on time, it is likely that an SCSI device has caused errors to the ongoing activities on the SCSI bus. A bus reset should be generated to notify attached devices that any activities that may have been occurring should be restarted. Find Devices: Each SCSI address other than the initiator's SCSI address should be tested to determine if an SCSI device responds. If an SCSI device responds, an INQUIRY command to logical unit 0 should be executed. The information obtained indicates the device type, manufacturer, and model of the attached logical unit 0 if the response data format field is one or two. If the response data format field is zero, only the device type field is valid. In addition, the version of the command set supported by the device is indicated by the ANSI-approved version field. Find logical units: Each possible logical unit number on the attached targets should be tested for existence using an INQUIRY command. Those found with a non-zero peripheral qualifier in the INQUIRY data should not be included in the list of available logical units. Each available logical unit should be added to the host configuration information, identifying the associated logical unit number, device type, manufacturer, and model. Verify State: The verify state test (see F.2.3) should be made to clear any outstanding errors, capture and clear UNIT ATTENTION conditions, and determine the state of readiness of the available logical units. The logical units should be identified as ready, not ready, or failing by this test. Device Initialization: The device undergoes a device-dependent initialization process. This process is described for direct-access devices, sequential-access devices, and processor devices. Other device initialization procedures are not described since they tend to be similar to one of these initialization procedures. The initialization process takes into account the state of the device as identified during the verify state test. Device On-line: The successful completion of the device initialization process allows the device-table entry to be fully enabled. The device joins the system with all key parameters identified and initialized. The device state is known and may be presented to the system operator. F.2.2. Procedure Executed by Temporary Initiators A temporary initiator typically performs initiator operations only under the direction of a host processor. Such operations may include read and write commands associated with management of a COPY command. Other possible operations include issuing a SEND command associated with asynchronous event notification. As such, temporary initiators need not completely perform the last two steps defined above. Since all commands are managed by a host processor, temporary initiators normally need not recover information about the media density, the sparing algorithms, or other detailed information that may be required only by a host processor. F.2.3. Verify State Test The verify state test uses the following steps to identify any outstanding errors, clear any UNIT ATTENTION conditions, and determine the readiness of the devices. The verify state test should be executed against each available logical unit. TEST UNIT READY (1) | | ________________|______________ | GOOD | CHECK CONDITION | | exit: LOGICAL UNIT READY | REQUEST SENSE (2) _______________| | | TEST UNIT READY (3) | | ______________|_______________ | GOOD | CHECK CONDITION | | exit: LOGICAL UNIT READY | REQUEST SENSE (4) | _______________| | | TEST UNIT READY (5) | | _____________|_______________ | GOOD | CHECK CONDITION | | exit: LOGICAL UNIT READY | _______________| | | REQUEST SENSE (6) | | _____________|_______________ | NOT READY | OTHER CHECK | | exit: LOGICAL UNIT NOT READY exit: LOGICAL UNIT FAILED Figure F-1: Verify State Test TEST UNIT READY (1): This TEST UNIT READY command is used to determine if any outstanding CHECK CONDITION or UNIT ATTENTION condition exists. If not, the device is indicated to be ready. REQUEST SENSE (2): This REQUEST SENSE command is used to clear the outstanding CHECK CONDITION. Most SCSI-2 logical units return UNIT ATTENTION sense key in this sense information. TEST UNIT READY (3): This TEST UNIT READY command is used to see if the UNIT ATTENTION condition or other error was successfully cleared. In some special cases, another error may have been nested with the UNIT ATTENTION and this TEST UNIT READY command may also return CHECK CONDITION status. REQUEST SENSE (4): This REQUEST SENSE command is used to determine which error or exception was associated with the CHECK CONDITION status returned by the TEST UNIT READY (3) command. In addition, this REQUEST SENSE command is used to clear the outstanding CHECK CONDITION. This may be a NOT READY sense key or another unexpected error. TEST UNIT READY (5): This TEST UNIT READY command is used to see if all outstanding CHECK CONDITION statuses have finally been cleared. If so, the logical unit is identified as ready. REQUEST SENSE (6): This REQUEST SENSE command is used to determine why there is a persistent CHECK CONDITION status. If the sense key is NOT READY, the logical unit is identified as not ready. If the sense key indicates some other failure, the logical unit is identified as failing and the sense key is logged in the appropriate area. IMPLEMENTORS NOTE: Commands that receive BUSY or RESERVATION CONFLICT status should be re-issued until some other status is received. F.3. Direct-Access Device Initialization Procedure The device-dependent initialization process for a direct-access device may be divided into three independent activities. The first activity enables the minimum logical function required for execution of READ commands on the boot device. The second activity is performed on all direct-access devices, including the boot device. It establishes all required initial parameters and operating conditions. The third activity is performed on direct-access devices that have never been formatted or initialized. This activity is normally performed by an initialization utility program. F.3.1. Boot Device Initialization Procedure It is assumed that the boot program and boot device have been prepared in such a manner that proper block lengths, data file contents, and logical addresses have been implemented by both the boot device and the boot program. The boot program prepares the boot device for operation in the following manner: Verify Ready: The state of the device as determined by the verify state test (see F.2.3) is examined. If the test indicates that the required drive has failed, the boot device initialization is not performed and appropriate error indications are presented. Start Device: A START STOP UNIT command should be issued with the start bit set to one. The Immed bit should be set to zero in order to guarantee that the returned status reflects the completion of the device start operation. A disconnect operation is likely to occur since the start process may take a considerable period of time. If system-controlled power sequencing of the peripheral devices is required, it is done by managing the timing relationship of the START STOP UNIT commands to different logical units. If GOOD status is returned, the next step should be started. If CHECK CONDITION status is returned, a REQUEST SENSE command is issued to determine what error condition was detected. If an ILLEGAL REQUEST sense key is found, the START STOP UNIT command was not supported by the target or peripheral device and the next step should be started. If any other error is detected (BUSY status is not an error), the boot device initialization should be terminated and appropriate error indications should be presented. Verify Ready / Spinning: A verify state test should be performed. If the device is ready, the next step should be started. If the device is not ready or failing, the boot device initialization should be terminated and appropriate error indications should be presented. Boot: The boot READ commands can now be started on the boot device. It is assumed that the information read includes the programs that are required to continue the system initialization and bring-up process, including the necessary programs and device drivers to perform the other system initialization procedures. F.3.2. General Direct-Access Device Initialization Procedure A general direct-access device initialization procedure is defined below. The initialization procedure should be executed for each attached logical unit that has been identified as a direct-access device. Execution of this procedure may be overlapped from one logical unit to another. If the initiator supports only a limited range of devices, parts of this procedure may be skipped or simplified. Verify Ready: The state of the device as determined by the verify state test (see F.2.3) should be examined. If the device has failed, the general direct-access device initialization should not be performed and appropriate error indications should be presented. Start Device: A START STOP UNIT command should be issued with the start bit set to one. If GOOD status is returned, the next step should be started. If CHECK CONDITION status is returned, a REQUEST SENSE command should be issued to determine what error condition was detected. If an ILLEGAL REQUEST sense key is found, the START STOP UNIT command was not supported by the device and the next step should be started. If any other error is detected (BUSY status is not an error), the general direct-access device initialization procedure should be terminated on this logical unit and appropriate error indications should be presented. Verify Ready / Spinning: A verify state test (see F.2.3) should be performed. If the device is ready, the next step should be started. If the device is not ready or failing, the general direct-access device initialization should be terminated for this logical unit and appropriate error indications should be presented. Determine Parameters: If the ANSI-approved version field of the previously executed INQUIRY command was 0 or 1, the MODE SENSE information, if any, may be vendor specific and this function should be skipped unless required by the vendor specific initialization protocols. If the ANSI-approved version field is 2, optional MODE SENSE information is by this standard. In this case, a MODE SENSE command should be executed with the page control field set to request current values and the page code field set to request all pages. A record should be made of the current values. If a CHECK CONDITION status is returned to the MODE SENSE command, then a REQUEST SENSE command should be issued. If the sense key is ILLEGAL REQUEST, then the target does not support the MODE commands. In this case, the initiator should skip to the determine capacity step. A second MODE SENSE command should be executed with the page control field set to request changeable values and the page code field set to request all pages. A record should be made of the changeable values. Any errors that occur during the two MODE SENSE commands should be recorded and the initialization for the failing logical unit should be terminated. Set Parameters: If the ANSI-approved version field is 0 or 1, the initialization operation may be vendor specific and may be executed according to the vendor's rules for the peripheral device. The system is assumed to have some other source of information concerning these requirements or it may skip this step, accepting the target's default parameters. If the ANSI-approved version field is 2, the optional MODE SELECT command is defined by this standard. The actual requirements for the parameters are characteristic of the particular system and should be known to the system. The current values and the changeable values obtained from the previous MODE SENSE commands should be examined to see if the system's requirements are satisfied and if the parameters can be modified. If all values are correct, the remainder of this step may be skipped. If modifications need to be made to the changeable values, a MODE SELECT command should be issued to modify the appropriate pages. This may include modifying error recovery parameters or performance tuning parameters. Most geometry parameters should not be modified during general direct-access device initialization. Determine Capacity: The capacity and block size of the logical unit are determined by issuing a READ CAPACITY command. The information is stored for access by the system device drivers. The direct-access device is now fully initialized and all required information has been made available to the system. When all available non- failing devices have been initialized, the system initialization is considered complete. F.3.3. Direct-Access Device Medium Initialization Procedure The following initialization procedure is not part of normal power-up system initialization. It is assumed to be performed after completion of the general system initialization process but uses only the INQUIRY data information obtained during that process. It is performed to initialize the device medium and is normally performed only by an initialization utility program. Determine Format Requirement: The requirement to perform a format operation is normally generated by an operator who has just installed a new device known to require formatting. It may also be generated by recognition that the device has information that is no longer valid and should be totally erased. It may also be generated by changes in system requirements, including different block sizes. Finally, reformatting may also be required to restructure the defect management. The general direct-access device initialization procedure may have identified the device as failing because of the inability of the device to recover the READ CAPACITY parameters. The device is assumed to have been started during the general direct-access device initialization procedure. The verify state test should be executed again. The device should be ready according to that test. If the logical unit is not ready or failing, the direct-access device medium initialization procedure should be terminated and appropriate error indications should be presented. If it was determined in the general direct-access device initialization procedure that the target does not support the MODE commands, then the initiator should either proceed to the perform format operation step or it should perform the determine format parameters and set format parameters steps in the vendor-specified manner. Determine Format Parameters: If the ANSI-approved version field is 0 or 1, the direct-access device medium initialization procedure may be vendor specific and should be executed according to the vendor's rules for the peripheral device. The system is assumed to have some other source of information concerning these requirements or to be willing to accept the target's default format. If the ANSI-approved version field is 2, a MODE SENSE command should be issued with the page control field set to current values and the page code field set to return all pages. A MODE SENSE command should be issued again with the page control field set to changeable values and the page code field set to return all pages. The information returned by the two MODE SENSE commands indicates what values should be provided by the system to complete the format parameters. If either of these MODE SENSE operations does not complete normally, the media initialization operation should be terminated and appropriate error indications should be presented. Set Format Parameters: If the ANSI-approved version field is 0 or 1, the format requirements may be vendor specific and the appropriate commands should be known to the initialization utility or it should be willing to accept the target's default format. Those format preparation commands, if any, should be executed at this time. If the ANSI-approved version field is 2 and the target supports the MODE commands, the logical unit should be prepared for medium formatting by executing a MODE SELECT command. The necessary formatting parameters are selected to meet the system requirements and are placed into the changeable value locations. The MODE SELECT command is then issued. If the command fails, the media initialization procedure should be terminated and appropriate error indications should be presented. If the command succeeds, the next step should be performed. Perform Format Operation: After the appropriate format parameters are established, the FORMAT command should be executed. The FORMAT parameters depend on the system requirements and the device capabilities. These parameters should be made easily variable in the operating system architecture so that modifications can be performed when system or device requirements change. An error may be returned if improper format parameters are selected. If the FORMAT command fails, the media initialization procedure should be terminated and appropriate error indications should be presented. If the command succeeds, the device is fully operational and the next step should be performed. Set Parameters: If the ANSI-approved version field is 0 or 1 or if the target does not support the MODE commands, the initialization operation may be vendor specific and may be executed according to the vendor's rules for the peripheral device. The system is assumed to have some other source of information concerning these requirements or it may skip this step, accepting the target's default parameters. If the ANSI-approved version field is 2, the optional MODE SELECT command is defined by this standard. The actual requirements for the parameters are characteristic of the particular system and should be known to the system. The current values and the parameters established by the MODE SELECT and FORMAT commands should be examined to determine if the system requirements are satisfied and if the parameters should be modified. If all values are correct, the remainder of this step may be skipped. If modifications need to be made to the changeable values, a MODE SELECT command should be issued to modify the appropriate pages. This may include modifying error recovery parameters or performance tuning parameters. Most geometry parameters were established by the storing of parameters during the MODE SELECT and FORMAT commands and should not be modified. Determine Capacity: The capacity and block size of the logical unit should be determined by issuing a READ CAPACITY command. The information should be stored for access by the system device drivers. Upon completion of this procedure the device should be initialized and prepared to partake in system-oriented activities. Other system initialization operations may also be required, including the establishment of system volume labels, tables of contents, and other structures. F.4. Sequential Access Device Initialization Procedure The initialization process for a sequential-access device may be divided into two independent activities. The first activity establishes all required initial parameters and operating conditions for the identified devices. The second activity performs any required medium initialization for the available logical units. F.4.1. General Sequential-Access Device Initialization A general sequential-access device initialization procedure is defined below. The initialization procedure should be executed for each attached logical unit that has been identified as a sequential-access device. Execution of this procedure may be overlapped from one logical unit to another. If initiator supports only a limited range of devices, parts of this procedure may be skipped or simplified. Verify Ready: The state of the device as determined by the verify state test (see F.2.3) should be examined. If the device has failed, the general direct-access device initialization should not be performed and appropriate error indications should be presented. Start Device: A LOAD UNLOAD command should be issued with the load bit set one. If GOOD status is returned, the next step should be started. If CHECK CONDITION status is returned, a REQUEST SENSE command should be issued to determine what error condition was detected. If an ILLEGAL REQUEST sense key is found, the LOAD UNLOAD command was not supported by the device and the next step should be started. If any other error is detected, the device initialization procedure should be terminated on this logical unit and appropriate error indications should be presented. Verify Ready / Loaded: If necessary, a verify state test (see F.2.3) should be performed. If the device and medium are ready, the next step should be started. If a NOT READY sense key is reported, manually loading the medium or activating a switch mechanism may be required to establish the ready state for the device. If any other error is detected, the device initialization procedure should be terminated and the appropriate error indications should be presented. Determine Parameters: A READ BLOCK LIMITS command should be issued to determine the range of block sizes supported by the device. Following this command, a MODE SENSE command should be issued to determine additional operating parameters of the device. If the ANSI-approved version field of the previously executed INQUIRY command is 0 or 1, any MODE SENSE data following the header and block descriptor is vendor specific. If the ANSI-approved version field is 2, additional pages of MODE SENSE data may be available as defined in this standard. In this case, a MODE SENSE command should be issued with the page code field set to return all pages. If any unrecovered errors are detected during execution of the READ BLOCK LIMITS or MODE SENSE commands, the device initialization process should be terminated and the appropriate error indications should be presented. Set Parameters: Specific system requirements may require that certain operating parameters be changed from the values reported in the previously executed MODE SENSE command. If changes are required, a MODE SELECT command should be issued to modify the appropriate parameters. This may include error recovery parameters, performance tuning parameters, or other basic operating parameters. If any unrecovered error occurs during this step, the device initialization process should be terminated and the appropriate error indications should be presented. If no change is required or no unrecovered error occurs, the general sequential-access device initialization procedure is complete. F.5. Asynchronous Event Notification Initialization Procedure A target using asynchronous event notification, must first execute an initialization procedure. This initialization procedure allows the target device to determine which SCSI devices are capable and willing to receive an asynchronous event notification. Parameters that affect asynchronous event notification within the target device is specified in the control mode page. The initialization procedure is performed at power-on (after waiting the recommended 10 seconds for all devices to be able to respond and waiting the time specified in the control mode page). It may also be performed following a reset condition, or when a target becomes aware of another SCSI device, or following the issuance of the control mode page or prior to a device issuing an asynchronous event notification. The target device that uses asynchronous event notification must determine which devices on the bus are capable of receiving an asynchronous event notification. This is done by the target device becoming a temporary initiator and selecting each SCSI device. If the SCSI device responds to selection, the verify state test (see F.2.3) is performed. If the verify state test fails, then the SCSI device does not support asynchronous event notification. If the verify state test succeeds then an INQUIRY command is issued to logical unit zero. The peripheral qualifier field in the INQUIRY data is examined to determine if the SCSI device is a processor device type and then the AENC bit is examined. An AENC bit of zero indicates that asynchronous event notification is not supported by the SCSI device. An AENC bit of one, indicates that asynchronous event notification is supported by the SCSI device. Disabling of asynchronous event notification can be done by using a vendor- specific hardware mechanism (e.g., switch or jumper), or by issuing control mode pages to devices that support saved parameters. G. Fast SCSI Skew Time This Appendix is included to explain the skew budget for the fast SCSI option which is defined in Section 4. Synchronous transfer rates using a transfer period between 100 ns and 200 ns are known as the "fast SCSI" option. Fast data transfer times have been tested using the following skew budget (Figure G-1) with the differential alternative using transceivers with 25 meters of 0.08042 square mm (28 AWG) twisted pair cable as specified in 4.2.3. The transceivers were subjected to a maximum temperature difference of 25 degrees celsius and a maximum of 200 mV of VCC difference. +----------------------------------------------+ | FAST SCSI JITTER BUDGET | |---+-------------------------------+----------| | # | parameter | +-budget| |---+-------------------------------+----------| | a | clock offset | 5 | | b | transmitting logic skew | 3 | | c | foil delay | 1 | TRANSMITTER | d | transmitter prop. delay skew | 6 | | e | foil delay | 1 | | f | drop cable prop. delay | 1 | |----------------------------------------------| | CONNECTOR | |----------------------------------------------| | g | external cable - skew | 5 | | | between pairs | | | h | distortion due to cable | 1 | | | imbalance | | CABLE | i | distortion due to | 2 | | | intersymbol interference | | | j | bias distortion | 2 | |----------------------------------------------| | CONNECTOR | |----------------------------------------------| | k | drop cable prop. delay | 1 | | l | foil delay | 1 | | m | receiver skew | 9 | RECEIVER | n | foil delay | 1 | | o | logic setup/hold | 5 | |---+-------------------------------+----------| | TOTAL 44nS | +----------------------------------------------+ Figure G-1: Fast SCSI Jitter Budget Mapping the above jitter or skew budget to the SCSI format in 4.7 and 4.8 is done in Figure G-2. +-------------------------------------------+ | Table # | parameter in 4.7-8 | value | |---------+------------------------+--------| | g | Fast Cable Skew Delay | 5 | | h - n | Fast Deskew Delay | ~20 | | o | Fast Hold Time | ~10 | | * | Fast Assertion Period | 30 | | * | Fast Negation Period | 30 | +-------------------------------------------+ Figure G-2: Mapping of Jitter to SCSI NOTES: (1) Values preceded with "~" are rounded up from the numbers shown in the previous table. (2) The assertion and negation pulse widths are derived from isolated pulse measurements and represent a minimum pulse width with a satisfactory margin. The maximum driver skew allowed was 6 ns (tPLH min. - tPHL max.) and the maximum receiver skew tested was 9 ns (tPLH min. - tPHL max.). Values greater than these could be used if other numbers could be reduced -- the sum is what is important. Fast data transfer timing parameters were not tested for the single-ended transceiver option prior to publication of this standard. H. Other SCSI Standardization Activities This appendix provides information on other formal standardization activities related to SCSI. H.1. SCSI-3 Standards Project Accredited Standards Committee X3 has approved a project proposal to maintain and enhance the SCSI-2 standard. This project is assigned to the X3T9.2 Task Group which developed this standard and the SCSI-1 standard. Please contact the Chairman of X3T9.2 for further information concerning this project. H.2. Digital Data Exchange for Color Electronic Prepress Systems Accredited Standards Committee IT8 is developing a standard for the exchange of digital data between color electronic prepress systems and direct digital color proofers. These are devices that prepare color pictures for high quality color printing. Please contact the Secretary of IT8 for further information concerning this project. H.3. Fiber Channel Accredited Standards Committee X3 has approved a project proposal to develop a fiber optic channel physical layer for the Intelligent Peripheral Interface (IPI), SCSI, and the High Performance Parallel Interface (HPPI). This project is assigned to the X3T9.3 Task Group. Please contact the Chairman of X3T9.3 for further information concerning this project. I. Numeric Order Codes This Appendix contains SCSI-2 additional sense codes and operation codes in numeric order as a reference. In the event of a conflict with the alphabetical definitions of these codes in Table 7-41 and in the appropriate tables of commands in sections 7 through 17, those definitions should be regarded as correct. Table I-1: ASC and ASCQ Assignments ============================================================================== ASC AND ASCQ ASSIGNMENTS D = DIRECT ACCESS DEVICE T = SEQUENTIAL ACCESS DEVICE L = PRINTER DEVICE P = PROCESSOR DEVICE W = WRITE ONCE READ MULTIPLE DEVICE R = READ ONLY (CD-ROM) DEVICE S = SCANNER DEVICE O = OPTICAL MEMORY DEVICE M = MEDIA CHANGER DEVICE C = COMMUNICATION DEVICE BYTE 12 13 DTLPWRSOMC DESCRIPTION -- -- ------------------------------------------------------------ 00 00 DTLPWRSOMC NO ADDITIONAL SENSE INFORMATION 00 01 T FILEMARK DETECTED 00 02 T S END-OF-PARTITION/MEDIUM DETECTED 00 03 T SETMARK DETECTED 00 04 T S BEGINNING-OF-PARTITION/MEDIUM DETECTED 00 05 T S END-OF-DATA DETECTED 00 06 DTLPWRSOMC I/O PROCESS TERMINATED 00 11 R AUDIO PLAY OPERATION IN PROGRESS 00 12 R AUDIO PLAY OPERATION PAUSED 00 13 R AUDIO PLAY OPERATION SUCCESSFULLY COMPLETED 00 14 R AUDIO PLAY OPERATION STOPPED DUE TO ERROR 00 15 R NO CURRENT AUDIO STATUS TO RETURN 01 00 D W O NO INDEX/SECTOR SIGNAL 02 00 D WR OM NO SEEK COMPLETE 03 00 DTL W SO PERIPHERAL DEVICE WRITE FAULT 03 01 T NO WRITE CURRENT 03 02 T EXCESSIVE WRITE ERRORS 04 00 DTLPWRSOMC LOGICAL UNIT NOT READY, CAUSE NOT REPORTABLE 04 01 DTLPWRSOMC LOGICAL UNIT IS IN PROCESS OF BECOMING READY 04 02 DTLPWRSOMC LOGICAL UNIT NOT READY, INITIALIZING COMMAND REQUIRED 04 03 DTLPWRSOMC LOGICAL UNIT NOT READY, MANUAL INTERVENTION REQUIRED 04 04 DTL O LOGICAL UNIT NOT READY, FORMAT IN PROGRESS 05 00 DTL WRSOMC LOGICAL UNIT DOES NOT RESPOND TO SELECTION 06 00 D WR OM NO REFERENCE POSITION FOUND 07 00 DTL WRSOM MULTIPLE PERIPHERAL DEVICES SELECTED 08 00 DTL WRSOMC LOGICAL UNIT COMMUNICATION FAILURE 08 01 DTL WRSOMC LOGICAL UNIT COMMUNICATION TIME-OUT ============================================================================== Table I-1: ASC and ASCQ Assignments (Continued) ============================================================================== BYTE 12 13 DTLPWRSOMC DESCRIPTION -- -- ------------------------------------------------------------ 08 02 DTL WRSOMC LOGICAL UNIT COMMUNICATION PARITY ERROR 09 00 DT WR O TRACK FOLLOWING ERROR 09 01 WR O TRACKING SERVO FAILURE 09 02 WR O FOCUS SERVO FAILURE 09 03 WR O SPINDLE SERVO FAILURE 0A 00 DTLPWRSOMC ERROR LOG OVERFLOW 0B 00 0C 00 T S WRITE ERROR 0C 01 D W O WRITE ERROR RECOVERED WITH AUTO REALLOCATION 0C 02 D W O WRITE ERROR - AUTO REALLOCATION FAILED 0D 00 0E 00 0F 00 10 00 D W O ID CRC OR ECC ERROR 11 00 DT WRSO UNRECOVERED READ ERROR 11 01 DT W SO READ RETRIES EXHAUSTED 11 02 DT W SO ERROR TOO LONG TO CORRECT 11 03 DT W SO MULTIPLE READ ERRORS 11 04 D W O UNRECOVERED READ ERROR - AUTO REALLOCATE FAILED 11 05 WR O L-EC UNCORRECTABLE ERROR 11 06 WR O CIRC UNRECOVERED ERROR 11 07 W O DATA RESYCHRONIZATION ERROR 11 08 T INCOMPLETE BLOCK READ 11 09 T NO GAP FOUND 11 0A DT O MISCORRECTED ERROR 11 0B D W O UNRECOVERED READ ERROR - RECOMMEND REASSIGNMENT 11 0C D W O UNRECOVERED READ ERROR - RECOMMEND REWRITE THE DATA 12 00 D W O ADDRESS MARK NOT FOUND FOR ID FIELD 13 00 D W O ADDRESS MARK NOT FOUND FOR DATA FIELD 14 00 DTL WRSO RECORDED ENTITY NOT FOUND 14 01 DT WR O RECORD NOT FOUND 14 02 T FILEMARK OR SETMARK NOT FOUND 14 03 T END-OF-DATA NOT FOUND 14 04 T BLOCK SEQUENCE ERROR 15 00 DTL WRSOM RANDOM POSITIONING ERROR 15 01 DTL WRSOM MECHANICAL POSITIONING ERROR 15 02 DT WR O POSITIONING ERROR DETECTED BY READ OF MEDIUM 16 00 D W O DATA SYNCHRONIZATION MARK ERROR 17 00 DT WRSO RECOVERED DATA WITH NO ERROR CORRECTION APPLIED 17 01 DT WRSO RECOVERED DATA WITH RETRIES 17 02 DT WR O RECOVERED DATA WITH POSITIVE HEAD OFFSET 17 03 DT WR O RECOVERED DATA WITH NEGATIVE HEAD OFFSET 17 04 WR O RECOVERED DATA WITH RETRIES AND/OR CIRC APPLIED 17 05 D WR O RECOVERED DATA USING PREVIOUS SECTOR ID 17 06 D W O RECOVERED DATA WITHOUT ECC - DATA AUTO-REALLOCATED 17 07 D W O RECOVERED DATA WITHOUT ECC - RECOMMEND REASSIGNMENT ============================================================================== Table I-1: ASC and ASCQ Assignments (Continued) ============================================================================== BYTE 12 13 DTLPWRSOMC DESCRIPTION -- -- ------------------------------------------------------------ 18 00 DT WR O RECOVERED DATA WITH ERROR CORRECTION APPLIED 18 01 D WR O RECOVERED DATA WITH ERROR CORRECTION AND RETRIES APPLIED 18 02 D WR O RECOVERED DATA - DATA AUTO-REALLOCATED 18 03 R RECOVERED DATA WITH CIRC 18 04 R RECOVERED DATA WITH LEC 18 05 D WR O RECOVERED DATA - RECOMMEND REASSIGNMENT 19 00 D O DEFECT LIST ERROR 19 01 D O DEFECT LIST NOT AVAILABLE 19 02 D O DEFECT LIST ERROR IN PRIMARY LIST 19 03 D O DEFECT LIST ERROR IN GROWN LIST 1A 00 DTLPWRSOMC PARAMETER LIST LENGTH ERROR 1B 00 DTLPWRSOMC SYNCHRONOUS DATA TRANSFER ERROR 1C 00 D O DEFECT LIST NOT FOUND 1C 01 D O PRIMARY DEFECT LIST NOT FOUND 1C 02 D O GROWN DEFECT LIST NOT FOUND 1D 00 D W O MISCOMPARE DURING VERIFY OPERATION 1E 00 D W O RECOVERED ID WITH ECC CORRECTION 1F 00 20 00 DTLPWRSOMC INVALID COMMAND OPERATION CODE 21 00 DT WR OM LOGICAL BLOCK ADDRESS OUT OF RANGE 21 01 M INVALID ELEMENT ADDRESS 22 00 D ILLEGAL FUNCTION (SHOULD USE 20 00, 24 00, OR 26 00) 23 00 24 00 DTLPWRSOMC INVALID FIELD IN CDB 25 00 DTLPWRSOMC LOGICAL UNIT NOT SUPPORTED 26 00 DTLPWRSOMC INVALID FIELD IN PARAMETER LIST 26 01 DTLPWRSOMC PARAMETER NOT SUPPORTED 26 02 DTLPWRSOMC PARAMETER VALUE INVALID 26 03 DTLPWRSOMC THRESHOLD PARAMETERS NOT SUPPORTED 27 00 DT W O WRITE PROTECTED 28 00 DTLPWRSOMC NOT READY TO READY TRANSITION (MEDIUM MAY HAVE CHANGED) 28 01 M IMPORT OR EXPORT ELEMENT ACCESSED 29 00 DTLPWRSOMC POWER ON, RESET, OR BUS DEVICE RESET OCCURRED 2A 00 DTL WRSOMC PARAMETERS CHANGED 2A 01 DTL WRSOMC MODE PARAMETERS CHANGED 2A 02 DTL WRSOMC LOG PARAMETERS CHANGED 2B 00 DTLPWRSO C COPY CANNOT EXECUTE SINCE HOST CANNOT DISCONNECT 2C 00 DTLPWRSOMC COMMAND SEQUENCE ERROR 2C 01 S TOO MANY WINDOWS SPECIFIED 2C 02 S INVALID COMBINATION OF WINDOWS SPECIFIED 2D 00 T OVERWRITE ERROR ON UPDATE IN PLACE 2E 00 2F 00 DTLPWRSOMC COMMANDS CLEARED BY ANOTHER INITIATOR 30 00 DT WR OM INCOMPATIBLE MEDIUM INSTALLED 30 01 DT WR O CANNOT READ MEDIUM - UNKNOWN FORMAT 30 02 DT WR O CANNOT READ MEDIUM - INCOMPATIBLE FORMAT 30 03 DT CLEANING CARTRIDGE INSTALLED ============================================================================== Table I-1: ASC and ASCQ Assignments (Continued) ============================================================================== BYTE 12 13 DTLPWRSOMC DESCRIPTION -- -- ------------------------------------------------------------ 31 00 DT W O MEDIUM FORMAT CORRUPTED 31 01 D L O FORMAT COMMAND FAILED 32 00 D W O NO DEFECT SPARE LOCATION AVAILABLE 32 01 D W O DEFECT LIST UPDATE FAILURE 33 00 T TAPE LENGTH ERROR 34 00 35 00 36 00 L RIBBON, INK, OR TONER FAILURE 37 00 DTL WRSOMC ROUNDED PARAMETER 38 00 39 00 DTL WRSOMC SAVING PARAMETERS NOT SUPPORTED 3A 00 DTL WRSOM MEDIUM NOT PRESENT 3B 00 TL SEQUENTIAL POSITIONING ERROR 3B 01 T TAPE POSITION ERROR AT BEGINNING-OF-MEDIUM 3B 02 T TAPE POSITION ERROR AT END-OF-MEDIUM 3B 03 L TAPE OR ELECTRONIC VERTICAL FORMS UNIT NOT READY 3B 04 L SLEW FAILURE 3B 05 L PAPER JAM 3B 06 L FAILED TO SENSE TOP-OF-FORM 3B 07 L FAILED TO SENSE BOTTOM-OF-FORM 3B 08 T REPOSITION ERROR 3B 09 S READ PAST END OF MEDIUM 3B 0A S READ PAST BEGINNING OF MEDIUM 3B 0B S POSITION PAST END OF MEDIUM 3B 0C S POSITION PAST BEGINNING OF MEDIUM 3B 0D M MEDIUM DESTINATION ELEMENT FULL 3B 0E M MEDIUM SOURCE ELEMENT EMPTY 3C 00 3D 00 DTLPWRSOMC INVALID BITS IN IDENTIFY MESSAGE 3E 00 DTLPWRSOMC LOGICAL UNIT HAS NOT SELF-CONFIGURED YET 3F 00 DTLPWRSOMC TARGET OPERATING CONDITIONS HAVE CHANGED 3F 01 DTLPWRSOMC MICROCODE HAS BEEN CHANGED 3F 02 DTLPWRSOMC CHANGED OPERATING DEFINITION 3F 03 DTLPWRSOMC INQUIRY DATA HAS CHANGED 40 00 D RAM FAILURE (SHOULD USE 40 NN) 40 NN DTLPWRSOMC DIAGNOSTIC FAILURE ON COMPONENT NN (80H-FFH) 41 00 D DATA PATH FAILURE (SHOULD USE 40 NN) 42 00 D POWER-ON OR SELF-TEST FAILURE (SHOULD USE 40 NN) 43 00 DTLPWRSOMC MESSAGE ERROR 44 00 DTLPWRSOMC INTERNAL TARGET FAILURE 45 00 DTLPWRSOMC SELECT OR RESELECT FAILURE 46 00 DTLPWRSOMC UNSUCCESSFUL SOFT RESET 47 00 DTLPWRSOMC SCSI PARITY ERROR 48 00 DTLPWRSOMC INITIATOR DETECTED ERROR MESSAGE RECEIVED 49 00 DTLPWRSOMC INVALID MESSAGE ERROR 4A 00 DTLPWRSOMC COMMAND PHASE ERROR 4B 00 DTLPWRSOMC DATA PHASE ERROR ============================================================================== Table I-1: ASC and ASCQ Assignments (Continued) ============================================================================== BYTE 12 13 DTLPWRSOMC DESCRIPTION -- -- ------------------------------------------------------------ 4C 00 DTLPWRSOMC LOGICAL UNIT FAILED SELF-CONFIGURATION 4D 00 4E 00 DTLPWRSOMC OVERLAPPED COMMANDS ATTEMPTED 4F 00 50 00 T WRITE APPEND ERROR 50 01 T WRITE APPEND POSITION ERROR 50 02 T POSITION ERROR RELATED TO TIMING 51 00 T O ERASE FAILURE 52 00 T CARTRIDGE FAULT 53 00 DTL WRSOM MEDIA LOAD OR EJECT FAILED 53 01 T UNLOAD TAPE FAILURE 53 02 DT WR OM MEDIUM REMOVAL PREVENTED 54 00 P SCSI TO HOST SYSTEM INTERFACE FAILURE 55 00 P SYSTEM RESOURCE FAILURE 56 00 57 00 R UNABLE TO RECOVER TABLE-OF-CONTENTS 58 00 O GENERATION DOES NOT EXIST 59 00 O UPDATED BLOCK READ 5A 00 DTLPWRSOM OPERATOR REQUEST OR STATE CHANGE INPUT (UNSPECIFIED) 5A 01 DT WR OM OPERATOR MEDIUM REMOVAL REQUEST 5A 02 DT W O OPERATOR SELECTED WRITE PROTECT 5A 03 DT W O OPERATOR SELECTED WRITE PERMIT 5B 00 DTLPWRSOM LOG EXCEPTION 5B 01 DTLPWRSOM THRESHOLD CONDITION MET 5B 02 DTLPWRSOM LOG COUNTER AT MAXIMUM 5B 03 DTLPWRSOM LOG LIST CODES EXHAUSTED 5C 00 D O RPL STATUS CHANGE 5C 01 D O SPINDLES SYNCHRONIZED 5C 02 D O SPINDLES NOT SYNCHRONIZED 5D 00 5E 00 5F 00 60 00 S LAMP FAILURE 61 00 S VIDEO ACQUISITION ERROR 61 01 S UNABLE TO ACQUIRE VIDEO 61 02 S OUT OF FOCUS 62 00 S SCAN HEAD POSITIONING ERROR 63 00 R END OF USER AREA ENCOUNTERED ON THIS TRACK 64 00 R ILLEGAL MODE FOR THIS TRACK 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 6C 00 ============================================================================== Table I-1: ASC and ASCQ Assignments (Continued) ============================================================================== BYTE 12 13 DTLPWRSOMC DESCRIPTION -- -- ------------------------------------------------------------ 6D 00 6E 00 6F 00 70 00 71 00 72 00 73 00 74 00 75 00 76 00 77 00 78 00 79 00 7A 00 7B 00 7C 00 7D 00 7E 00 7F 00 ------------------------------------------ 80 XX \ THROUGH > VENDOR SPECIFIC. FF XX / XX 80 \ THROUGH > VENDOR SPECIFIC QUALIFICATION OF STANDARD ASC. XX FF / ALL CODES NOT SHOWN OR BLANK ARE RESERVED. ============================================================================== Table I-2: SCSI-2 Operation Codes ============================================================================== Device Columns M = Mandatory Key: O = Optional V = Vendor unique = Reserved (Blank) D = Direct-Access Device T = Sequential-Access Device L = Printer Device P = Processor Device W = Write-Once Device R = CD-ROM Device S = Scanner Device O = Optical Memory Device M = Medium Changer Device C = Communication Device OP DTLPWRSOMC Description -- ---------- ---------------------------------------------------------------- 00 MMMMMMMMMM TEST UNIT READY 01 M REWIND 01 O V OO OO REZERO UNIT 02 VVVVVV V 03 MMMMMMMMMM REQUEST SENSE 04 O FORMAT 04 M O FORMAT UNIT 05 VMVVVV V READ BLOCK LIMITS 06 VVVVVV V 07 O INITIALIZE ELEMENT STATUS 07 OVV O OV REASSIGN BLOCKS 08 M GET MESSAGE(06) 08 OMV OO OV READ(06) 08 O RECEIVE 09 VVVVVV V 0A M PRINT 0A M SEND MESSAGE(06) 0A M SEND(06) 0A OM O OV WRITE(06) 0B O OO OV SEEK(06) 0B O SLEW AND PRINT 0C VVVVVV V 0D VVVVVV V 0E VVVVVV V 0F VOVVVV V READ REVERSE 10 O O SYNCHRONIZE BUFFER 10 VM VVV WRITE FILEMARKS 11 VMVVVV SPACE 12 MMMMMMMMMM INQUIRY 13 VOVVVV VERIFY(06) 14 VOOVVV RECOVER BUFFERED DATA 15 OMO OOOOOO MODE SELECT(06) ============================================================================== Table I-2: SCSI-2 Operation Codes (Continued) ============================================================================== OP DTLPWRSOMC Description -- ---------- ---------------------------------------------------------------- 16 M MM MO RESERVE 16 MM M RESERVE UNIT 17 M MM MO RELEASE 17 MM M RELEASE UNIT 18 OOOOOOOO COPY 19 VMVVVV ERASE 1A OMO OOOOOO MODE SENSE(06) 1B O LOAD UNLOAD 1B O SCAN 1B O STOP PRINT 1B O OO O STOP START UNIT 1C OOOOOOOOOO RECEIVE DIAGNOSTIC RESULTS 1D MMMMMMMMMM SEND DIAGNOSTIC 1E OO OO OO PREVENT ALLOW MEDIUM REMOVAL 1F 20 V VV V 21 V VV V 22 V VV V 23 V VV V 24 V VVM SET WINDOW 25 O GET WINDOW 25 M M M READ CAPACITY 25 M READ CD-ROM CAPACITY 26 V VV 27 V VV 28 O GET MESSAGE(10) 28 M MMMM READ(10) 29 V VV O READ GENERATION 2A O SEND MESSAGE(10) 2A O SEND(10) 2A M M M WRITE(10) 2B O LOCATE 2B O POSITION TO ELEMENT 2B O OO O SEEK(10) 2C V O ERASE(10) 2D V O O READ UPDATED BLOCK 2E O O O WRITE AND VERIFY(10) 2F O OO O VERIFY(10) 30 O OO O SEARCH DATA HIGH(10) 31 O OBJECT POSITION 31 O OO O SEARCH DATA EQUAL(10) 32 O OO O SEARCH DATA LOW(10) 33 O OO O SET LIMITS(10) 34 O GET DATA BUFFER STATUS 34 O OO O PRE-FETCH 34 O READ POSITION 35 O OO O SYNCHRONIZE CACHE 36 O OO O LOCK UNLOCK CACHE ============================================================================== Table I-2: SCSI-2 Operation Codes (Continued) ============================================================================== OP DTLPWRSOMC Description -- ---------- ---------------------------------------------------------------- 37 O O READ DEFECT DATA(10) 38 O O MEDIUM SCAN 39 OOOOOOOO COMPARE 3A OOOOOOOO COPY AND VERIFY 3B OOOOOOOOOO WRITE BUFFER 3C OOOOOOOOOO READ BUFFER 3D O O UPDATE BLOCK 3E O OO O READ LONG 3F O O O WRITE LONG 40 OOOOOOOOOO CHANGE DEFINITION 41 O WRITE SAME 42 O READ SUB-CHANNEL 43 O READ TOC 44 O READ HEADER 45 O PLAY AUDIO(10) 46 47 O PLAY AUDIO MSF 48 O PLAY AUDIO TRACK INDEX 49 O PLAY TRACK RELATIVE(10) 4A 4B O PAUSE RESUME 4C OOOOOOOOOO LOG SELECT 4D OOOOOOOOOO LOG SENSE 4E 4F 50 51 52 53 54 55 OOO OOOOOO MODE SELECT(10) 56 57 58 59 5A OOO OOOOOO MODE SENSE(10) 5B 5C 5D 5E 5F A0 A1 A2 A3 A4 A5 M MOVE MEDIUM A5 O PLAY AUDIO(12) ============================================================================== Table I-2: SCSI-2 Operation Codes (Continued) ============================================================================== OP DTLPWRSOMC Description -- ---------- ---------------------------------------------------------------- A6 O EXCHANGE MEDIUM A7 A8 O GET MESSAGE(12) A8 OO O READ(12) A9 O PLAY TRACK RELATIVE(12) AA O SEND MESSAGE(12) AA O O WRITE(12) AB AC O ERASE(12) AD AE O O WRITE AND VERIFY(12) AF OO O VERIFY(12) B0 OO O SEARCH DATA HIGH(12) B1 OO O SEARCH DATA EQUAL(12) B2 OO O SEARCH DATA LOW(12) B3 OO O SET LIMITS(12) B4 B5 B5 O REQUEST VOLUME ELEMENT ADDRESS B6 B6 O SEND VOLUME TAG B7 O READ DEFECT DATA(12) B8 B8 O READ ELEMENT STATUS B9 BA BB BC BD BE BF ============================================================================== J. Vendor Identification This Appendix contains the list of SCSI-2 vendor identifications as of the date of this document. The purpose of this list is to help avoid redundant usage of vendor identifications. Task Group X3T9.2 of Accredited Standards Committee X3 maintains an informal list of vendor identifications currently in use. Please contact the chairman of X3T9.2 prior to using a new vendor identification to avoid conflicts. Table J-1: Vendor Identification List ============================================================================== ID Organization -------- -------------------------------------------------------------------- 3M 3M Company ADAPTEC Adaptec ADSI Adaptive Data Systems, Inc. (a Western Digital subsidiary) AMCODYNE Amcodyne ANAMATIC Anamartic Limited (England) ANCOT ANCOT Corp. ANRITSU Anritsu Corporation APPLE Apple Computer, Inc. ARCHIVE Archive ASPEN Aspen Peripherals AST AST Research AT&T AT&T ATTO ATTO Technology Inc. ATX Alphatronix BALLARD Ballard Synergy Corp. BERGSWD Berg Software Design BULL Bull Peripherals Corp. CALIPER Caliper (California Peripheral Corp.) CAST Advanced Storage Tech CDC Control Data or MPI CHEROKEE Cherokee Data Systems CIE&YED YE Data, C.Itoh Electric Corp. CIPHER Cipher Data Products Ciprico Ciprico, Inc. CNGR SFW Congruent Software, Inc. COGITO Cogito COMPORT Comport Corp. CONNER Conner Peripherals CROSFLD Crosfield Electronics CSM, INC Computer SM, Inc. CYGNET Cygnet Systems, Inc. DATABOOK Databook, Inc. DATACOPY Datacopy Corp. DATAPT Datapoint Corp. DEC Digital Equipment DENON Denon/Nippon Columbia ============================================================================== Table J-1: Vendor Identification List (Continued) ============================================================================== ID Organization -------- -------------------------------------------------------------------- DEST DEST Corp. DGC Data General Corp. DIGIDATA Digi-Data Corporation DILOG Distributed Logic Corp. DTC Data Technology Corp. DPT Distributed Processing Technology DXIMAGIN DX Imaging EMULEX Emulex EPSON Epson EXABYTE Exabyte Corp. FILENET FileNet Corp. FUJI Fuji Electric Co., Ltd. (Japan) FUJITSU Fujitsu FUTURED Future Domain Corp. GIGATAPE GIGATAPE GmbH GIGATRND GigaTrend Incorporated Goidelic Goidelic Precision, Inc. GOULD Gould HITACHI Hitachi America Ltd or Nissei Sangyo America Ltd HONEYWEL Honeywell Inc. HP Hewlett Packard IBM International Business Machines ICL ICL IGR Intergraph Corp. IMPRIMIS Imprimis Technology Inc. IOC I/O Concepts, Inc. IOMEGA Iomega ISi Information Storage inc. JVC JVC Information Products Co. KODAK Eastman Kodak KONAN Konan KONICA Konica Japan LAPINE Lapine Technology LASERDRV LaserDrive Limited LMS Laser Magnetic Storage International Company MATSHITA Matsushita MAXTOR Maxtor Corp. MELA Mitsubishi Electronics America MELCO Mitsubishi Electric (Japan) MICROBTX Microbotics Inc. MICROP Micropolis MICROTEK Microtek Storage Corp MINSCRIB Miniscribe MOTOROLA Motorola NAI North Atlantic Industries ============================================================================== Table J-1: Vendor Identification List (Continued) ============================================================================== ID Organization -------- -------------------------------------------------------------------- NatSemi National Semiconductor Corp. NCL NCL America NCR NCR Corporation NEC NEC NISCA NISCA Inc. NKK NKK Corp. NT Northern Telecom OSI Optical Storage International OPTIMEM Cipher/Optimem OPTOTECH Optotech OTL OTL Engineering PERTEC Pertec Peripherals Corporation PFTI Performance Technology Inc. PRAIRIE PrairieTek PTI Peripheral Technology Inc. PRIAM Priam QUALSTAR Qualstar QUANTEL Quantel Ltd. QUANTUM Quantum Corp. RADSTONE Radstone Technology RICOH Ricoh RODIME Rodime RTI Reference Technology SANYO SANYO Electric Co., Ltd. SEAGATE Seagate SIEMENS Siemens SMS Scientific Micro Systems/OMTI SONY Sony Corporation Japan SPERRY Sperry (now Unisys Corp.) STK Storage Technology Corporation SUN Sun Microsystems, Inc. SYSGEN Sysgen T-MITTON Transmitton England TALLGRAS Tallgrass Technologies TANDBERG Tandberg Data A/S TANDON Tandon TEAC TEAC Japan Tek Tektronix TI-DSG Texas Instruments TOSHIBA Toshiba Japan UNISYS Unisys USDC US Design Corp. VERBATIM Verbatim Corporation VRC Vermont Research Corp. WangDAT WangDAT WANGTEK Wangtek WDIGTL Western Digital XEBEC Xebec Corporation ============================================================================== (This page is intentionally blank.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End of Document <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<