Mass Storage Control Protocol ECO Controlled Version 2.4.0 11 June 1992 Send inquiries and comments to SSAG::SSAG This document defines the Mass Storage Control Protocol (MSCP), an applications protocol intended for use between hosts and intelligent mass storage subsystems. DIGITAL EQUIPMENT CORPORATION CONFIDENTIAL AND PROPRIETARY This document is an unpublished work and contains valuable trade secrets which are confidential and proprietary to Digital Equipment Corporation, and may only be disclosed to individuals who have entered into a confidentiality agreement with Digital, and may not be copied or reproduced in whole or in part. Copyright (c) Digital Equipment Corporation 1992. All Rights Reserved. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page ii 11 June 1992 CONTENTS CHAPTER 1 INTRODUCTION 1.1 Overview Of MSCP Subsystem . . . . . . . . 1-1 1.2 Purpose . . . . . . . . . . . . . . . . . . 1-3 1.3 Method Of Presentation . . . . . . . . . . . 1-3 1.4 Scope . . . . . . . . . . . . . . . . . . . 1-3 CHAPTER 2 TERMINOLOGY CHAPTER 3 CLASS DRIVER / MSCP SERVER COMMUNICATIONS 3.1 Connection . . . . . . . . . . . . . . . . . 3-1 3.2 Flow Control . . . . . . . . . . . . . . . . 3-2 3.2.1 Class Driver Responsibilities . . . . . . 3-5 3.2.2 MSCP Server Responsibilities . . . . . . . 3-7 3.3 Multihost Communication . . . . . . . . . . 3-10 CHAPTER 4 ALGORITHMS AND USAGE RULES 4.1 Controller States . . . . . . . . . . . . . 4-1 4.2 Controls And Indicators . . . . . . . . . . 4-4 4.3 Unit States . . . . . . . . . . . . . . . . 4-6 4.4 Unit Numbers . . . . . . . . . . . . . . . . 4-14 4.5 Command Categories And Execution Order . . . 4-18 4.6 Class Driver / MSCP Server Synchronization . 4-22 4.7 Class Driver Error Recovery . . . . . . . . 4-24 4.8 Serious Exceptions . . . . . . . . . . . . . 4-25 4.9 Host Access Timeouts . . . . . . . . . . . . 4-25 4.10 Command Timeouts . . . . . . . . . . . . . . 4-28 4.11 Host Buffer Access . . . . . . . . . . . . . 4-31 4.12 Disk Geometry And Format . . . . . . . . . . 4-31 4.12.1 Replacement Control Table (RCT) Overview . 4-32 4.12.2 Logical Block Contents . . . . . . . . . . 4-33 4.12.3 Performance Implications . . . . . . . . . 4-34 4.13 Bad Block Replacement . . . . . . . . . . . 4-37 4.14 Write Protection . . . . . . . . . . . . . . 4-37 4.15 Compare Operations . . . . . . . . . . . . . 4-39 4.16 Special Drive Topologies . . . . . . . . . . 4-41 4.16.1 Multiaccess Drives . . . . . . . . . . . . 4-41 4.16.2 Multiunit Drives And Formatters . . . . . 4-43 4.17 Controller And Unit Identifiers . . . . . . 4-45 4.18 Media Type Identifiers . . . . . . . . . . . 4-47 4.19 Controller-based Cache . . . . . . . . . . . 4-49 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page iii 11 June 1992 CHAPTER 5 MSCP CONTROL MESSAGES 5.1 Generic Control Message Format . . . . . . . 5-1 5.2 Reserved And Undefined Fields . . . . . . . 5-2 5.3 Command Messages . . . . . . . . . . . . . . 5-4 5.3.1 Transfer Command Message Format . . . . . 5-7 5.3.2 Command Modifiers . . . . . . . . . . . . 5-13 5.4 End Messages . . . . . . . . . . . . . . . . 5-15 5.4.1 Transfer Command End Message Format . . . 5-19 5.5 Status And Event Codes . . . . . . . . . . . 5-21 5.6 Controller Flags . . . . . . . . . . . . . . 5-32 5.7 Unit Flags . . . . . . . . . . . . . . . . . 5-37 5.8 Attention Messages . . . . . . . . . . . . . 5-41 5.8.1 ACCESS PATH Attention Message . . . . . . 5-43 5.8.1.1 Attention Message Format . . . . . . . . 5-43 5.8.1.2 Description . . . . . . . . . . . . . . 5-43 5.8.2 AVAILABLE Attention Message . . . . . . . 5-44 5.8.2.1 Attention Message Format . . . . . . . . 5-44 5.8.2.2 Description . . . . . . . . . . . . . . 5-45 5.8.3 DUPLICATE UNIT NUMBER Attention Message . 5-47 5.8.3.1 Attention Message Format . . . . . . . . 5-47 5.8.3.2 Description . . . . . . . . . . . . . . 5-47 5.9 Error Log Messages . . . . . . . . . . . . . 5-48 5.9.1 Maximum Error Log Message Size . . . . . . 5-53 5.9.2 Generic Error Log Message Format . . . . . 5-57 5.9.3 CONTROLLER ERRORS Error Log Format . . . . 5-63 5.9.4 MEMORY ERRORS Error Log Format . . . . . . 5-64 5.9.5 DISK TRANSFER ERRORS Error Log Format . . 5-67 5.9.6 SDI ERRORS Error Log Format . . . . . . . 5-69 5.9.7 SMALL DISK ERRORS Error Log Format . . . . 5-71 5.9.8 BAD BLOCK REPLACEMENT ATTEMPT Error Log Format . . . . . . . . . . . . . . . . . . 5-73 5.9.9 DISK COPY DATA CORRELATION Error Log Format . . . . . . . . . . . . . . . . . . 5-75 CHAPTER 6 MINIMAL MSCP COMMAND SET 6.1 Overview . . . . . . . . . . . . . . . . . . 6-1 6.1.1 No-Operation Commands . . . . . . . . . . 6-2 6.2 ABORT Command . . . . . . . . . . . . . . . 6-4 6.2.1 Command Message Format . . . . . . . . . . 6-4 6.2.2 End Message Format . . . . . . . . . . . . 6-5 6.2.3 Description . . . . . . . . . . . . . . . 6-6 6.3 ACCESS Command . . . . . . . . . . . . . . . 6-7 6.3.1 Command Message Format . . . . . . . . . . 6-7 6.3.2 End Message Format . . . . . . . . . . . . 6-8 6.3.3 Description . . . . . . . . . . . . . . . 6-9 6.4 AVAILABLE Command . . . . . . . . . . . . . 6-10 6.4.1 Command Message Format . . . . . . . . . . 6-10 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page iv 11 June 1992 6.4.2 End Message Format . . . . . . . . . . . . 6-11 6.4.3 Description . . . . . . . . . . . . . . . 6-12 6.5 COMPARE HOST DATA Command . . . . . . . . . 6-13 6.5.1 Command Message Format . . . . . . . . . . 6-13 6.5.2 End Message Format . . . . . . . . . . . . 6-14 6.5.3 Description . . . . . . . . . . . . . . . 6-15 6.6 DETERMINE ACCESS PATHS Command . . . . . . . 6-16 6.6.1 Command Message Format . . . . . . . . . . 6-16 6.6.2 End Message Format . . . . . . . . . . . . 6-17 6.6.3 Description . . . . . . . . . . . . . . . 6-18 6.7 DISK COPY DATA Command . . . . . . . . . . . 6-19 6.7.1 Command Message Format . . . . . . . . . . 6-19 6.7.2 End Message Format . . . . . . . . . . . . 6-28 6.7.3 Description . . . . . . . . . . . . . . . 6-43 6.7.3.1 Operation . . . . . . . . . . . . . . . 6-44 6.7.3.2 Error Logs And Correlation Logs . . . . 6-54 6.8 DISPLAY Command . . . . . . . . . . . . . . 6-57 6.8.1 Command Message Format . . . . . . . . . . 6-57 6.8.2 End Message Format . . . . . . . . . . . . 6-59 6.8.3 Description . . . . . . . . . . . . . . . 6-61 6.9 ERASE Command . . . . . . . . . . . . . . . 6-67 6.9.1 Command Message Format . . . . . . . . . . 6-67 6.9.2 End Message Format . . . . . . . . . . . . 6-70 6.9.3 Description . . . . . . . . . . . . . . . 6-73 6.10 FORMAT Command . . . . . . . . . . . . . . . 6-74 6.10.1 Command Message Format . . . . . . . . . . 6-74 6.10.2 End Message Format . . . . . . . . . . . . 6-75 6.10.3 Description . . . . . . . . . . . . . . . 6-76 6.11 GET COMMAND STATUS Command . . . . . . . . . 6-79 6.11.1 Command Message Format . . . . . . . . . . 6-79 6.11.2 End Message Format . . . . . . . . . . . . 6-80 6.11.3 Description . . . . . . . . . . . . . . . 6-81 6.12 GET UNIT STATUS Command . . . . . . . . . . 6-82 6.12.1 Command Message Format . . . . . . . . . . 6-82 6.12.2 End Message Format . . . . . . . . . . . . 6-83 6.12.3 Description . . . . . . . . . . . . . . . 6-87 6.13 ONLINE Command . . . . . . . . . . . . . . . 6-88 6.13.1 Command Message Format . . . . . . . . . . 6-88 6.13.2 End Message Format . . . . . . . . . . . . 6-91 6.13.3 Description . . . . . . . . . . . . . . . 6-94 6.14 READ Command . . . . . . . . . . . . . . . . 6-95 6.14.1 Command Message Format . . . . . . . . . . 6-95 6.14.2 End Message Format . . . . . . . . . . . . 6-96 6.14.3 Description . . . . . . . . . . . . . . . 6-97 6.15 REPLACE Command . . . . . . . . . . . . . . 6-98 6.15.1 Command Message Format . . . . . . . . . . 6-98 6.15.2 End Message Format . . . . . . . . . . . 6-100 6.15.3 Description . . . . . . . . . . . . . . 6-101 6.16 SET CONTROLLER CHARACTERISTICS Command . . 6-102 6.16.1 Command Message Format . . . . . . . . . 6-102 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page v 11 June 1992 6.16.2 End Message Format . . . . . . . . . . . 6-105 6.16.3 Description . . . . . . . . . . . . . . 6-107 6.17 SET UNIT CHARACTERISTICS Command . . . . . 6-108 6.17.1 Command Message Format . . . . . . . . . 6-108 6.17.2 End Message Format . . . . . . . . . . . 6-110 6.17.3 Description . . . . . . . . . . . . . . 6-113 6.18 WRITE Command . . . . . . . . . . . . . . 6-114 6.18.1 Command Message Format . . . . . . . . . 6-114 6.18.2 End Message Format . . . . . . . . . . . 6-118 6.18.3 Description . . . . . . . . . . . . . . 6-121 6.19 WRITE HISTORY MANAGEMENT Command . . . . . 6-122 6.19.1 Command Message Format . . . . . . . . . 6-122 6.19.2 End Message Format . . . . . . . . . . . 6-128 6.19.3 Description . . . . . . . . . . . . . . 6-132 CHAPTER 7 MULTIHOST SUPPORT 7.1 Overview . . . . . . . . . . . . . . . . . . 7-1 7.2 Multihost ABORT Command . . . . . . . . . . 7-3 7.2.1 Command Message Format . . . . . . . . . . 7-3 7.2.2 End Message Format . . . . . . . . . . . . 7-4 7.2.3 Description . . . . . . . . . . . . . . . 7-5 7.3 Multihost ACCESS NONVOLATILE MEMORY Command 7-6 7.3.1 Command Message Format . . . . . . . . . . 7-6 7.3.2 End Message Format . . . . . . . . . . . . 7-8 7.3.3 Description . . . . . . . . . . . . . . . 7-9 7.4 Multihost AVAILABLE Command . . . . . . . . 7-12 7.4.1 Command Message Format . . . . . . . . . . 7-12 7.4.2 End Message Format . . . . . . . . . . . . 7-15 7.4.3 Description . . . . . . . . . . . . . . . 7-18 7.5 Multihost GET COMMAND STATUS Command . . . . 7-19 7.5.1 Command Message Format . . . . . . . . . . 7-19 7.5.2 End Message Format . . . . . . . . . . . . 7-20 7.5.3 Description . . . . . . . . . . . . . . . 7-24 7.6 Multihost GET UNIT STATUS Command . . . . . 7-25 7.6.1 Command Message Format . . . . . . . . . . 7-25 7.6.2 End Message Format . . . . . . . . . . . . 7-26 7.6.3 Description . . . . . . . . . . . . . . . 7-28 7.7 Multihost ONLINE Command . . . . . . . . . . 7-29 7.7.1 Command Message Format . . . . . . . . . . 7-29 7.7.2 End Message Format . . . . . . . . . . . . 7-32 7.7.3 Description . . . . . . . . . . . . . . . 7-36 7.8 Multihost SET CONTROLLER CHARACTERISTICS Command . . . . . . . . . . . . . . . . . . 7-37 7.8.1 Command Message Format . . . . . . . . . . 7-37 7.8.2 End Message Format . . . . . . . . . . . . 7-39 7.8.3 Description . . . . . . . . . . . . . . . 7-41 7.9 Multihost SET UNIT CHARACTERISTICS Command . 7-42 7.9.1 Command Message Format . . . . . . . . . . 7-42 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page vi 11 June 1992 7.9.2 End Message Format . . . . . . . . . . . . 7-45 7.9.3 Description . . . . . . . . . . . . . . . 7-48 7.10 Multihost TERMINATE CLASS DRIVER/SERVER CONNECTION Command . . . . . . . . . . . . . 7-49 7.10.1 Command Message Format . . . . . . . . . . 7-49 7.10.2 End Message Format . . . . . . . . . . . . 7-51 7.10.3 Description . . . . . . . . . . . . . . . 7-52 CHAPTER 8 CONTROLLER INITIATED BAD BLOCK REPLACEMENT 8.1 Controller Initiated Bad Block Replacement Overview . . . . . . . . . . . . . . . . . . 8-1 8.2 Data Safety Write Protection . . . . . . . . 8-2 8.3 Bad Block Replacement . . . . . . . . . . . 8-3 8.4 Replacement Control Table Access . . . . . . 8-6 8.5 Atomic Bad Block Replacement . . . . . . . . 8-8 8.6 Error Log Messages . . . . . . . . . . . . . 8-8 8.7 Unit Context Information . . . . . . . . . . 8-9 8.8 Actions During ONLINE . . . . . . . . . . . 8-10 8.9 Actions During SET UNIT CHARACTERISTICS . . 8-12 8.10 Actions Before First Modification . . . . . 8-14 8.11 MSCP Control Message Format Changes . . . . 8-16 8.11.1 Controller Flags . . . . . . . . . . . . . 8-16 8.11.2 Unit Flags . . . . . . . . . . . . . . . . 8-16 8.11.3 Transfer Commands . . . . . . . . . . . . 8-17 8.11.4 ONLINE and SET UNIT CHARACTERISTICS Commands . . . . . . . . . . . . . . . . . 8-17 8.11.5 GET UNIT STATUS Command . . . . . . . . . 8-19 8.11.6 REPLACE Command . . . . . . . . . . . . . 8-19 8.12 Host Support For Controller Initiated Bad Block Replacement . . . . . . . . . . . . . 8-20 APPENDIX A OPCODE, FLAG, AND OFFSET DEFINITIONS APPENDIX B STATUS AND EVENT CODE DEFINITIONS APPENDIX C CONTROLLER, UNIT, AND MEDIA TYPE IDENTIFIERS APPENDIX D BUFFER DESCRIPTOR FORMATS APPENDIX E WAIVERS AND EXCEPTIONS E.1 UDA50 . . . . . . . . . . . . . . . . . . . E-1 E.1.1 Unit And Controller Revision Numbers . . . E-1 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page vii 11 June 1992 E.2 RC25 . . . . . . . . . . . . . . . . . . . . E-1 E.2.1 Error Log Message Ordering . . . . . . . . E-1 E.2.2 Data Error (subcode "Forced Error") Reporting . . . . . . . . . . . . . . . . E-2 E.2.3 Improper Duplicate Unit Number Processing E-3 E.3 HSC And VAX/VMS . . . . . . . . . . . . . . E-6 E.3.1 "Bundled" Shadowing . . . . . . . . . . . E-6 E.3.1.1 Shadowing Concepts . . . . . . . . . . . E-6 E.3.1.1.1 Shadowing Functionality . . . . . . . E-6 E.3.1.1.2 Invalid Commands . . . . . . . . . . . E-7 E.3.1.1.3 Virtual And Member Units . . . . . . . E-9 E.3.1.1.4 Shadow Member Compatibility . . . . . E-9 E.3.1.1.4.1 Hardware Write Protected Shadow Sets E-10 E.3.1.1.5 Shadow Set Management . . . . . . . . E-11 E.3.1.1.6 MSCP Command Changes . . . . . . . . . E-13 E.3.1.1.6.1 ONLINE Command Changes . . . . . . . E-13 E.3.1.1.6.1.1 Changes in the ONLINE Command Syntax . . . . . . . . . . . . . . E-13 E.3.1.1.6.1.2 Changes Which Enforce Shadow Set Membership Rules . . . . . . . . . E-17 E.3.1.1.6.1.3 Changes in Sequential Gatekeeping E-18 E.3.1.1.6.1.4 Performing Shadow Copy Operations E-19 E.3.1.1.6.1.5 Restrictions and Miscellaneous Notes . . . . . . . . . . . . . . E-21 E.3.1.1.6.2 ONLINE End Message Changes . . . . . E-21 E.3.1.1.6.3 SET UNIT CHARACTERISTICS Command Changes . . . . . . . . . . . . . . E-23 E.3.1.1.6.4 SET UNIT CHARACTERISTICS End Message Changes . . . . . . . . . . . . . . E-24 E.3.1.1.6.5 AVAILABLE Command Changes . . . . . E-24 E.3.1.1.6.6 GET UNIT STATUS Command End Message Changes . . . . . . . . . . . . . . E-25 E.3.1.1.6.7 DETERMINE ACCESS PATHS Command Changes . . . . . . . . . . . . . . E-25 E.3.1.1.6.8 COMPARE CONTROLLER DATA Command Changes . . . . . . . . . . . . . . E-26 E.3.1.1.6.9 Transfer Commands . . . . . . . . . E-26 E.3.1.1.6.9.1 READ Operations . . . . . . . . . E-27 E.3.1.1.6.9.2 WRITE Operations . . . . . . . . . E-30 E.3.1.1.6.9.3 Host Write Failure Recovery . . . E-32 E.3.1.1.6.9.4 Read/Write Concurrency . . . . . . E-34 E.3.1.1.6.10 Shadow Set Membership Changes . . . E-35 E.3.1.1.6.11 Multihost Access . . . . . . . . . . E-35 E.3.1.1.6.11.1 Member Unit Actions . . . . . . . E-35 E.3.1.1.6.11.2 Shadow Set Virtual Unit Actions . E-37 E.3.1.1.6.11.3 Shadow Copy Actions . . . . . . . E-38 E.3.1.1.6.11.4 Get Unit Status Actions . . . . . E-38 E.3.1.1.6.12 Error Logs . . . . . . . . . . . . . E-38 E.3.1.1.7 "Bundled Shadowing" Definitions . . . E-39 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page viii 11 June 1992 E.3.1.1.8 "Bundled Shadowing" Specific Status Code Definitions . . . . . . . . . . . E-42 E.4 TU81 . . . . . . . . . . . . . . . . . . . . E-45 E.4.1 "Enable Miscellaneous Error Log Messages" Modifier Not Fully Supported . . . . . . . E-45 E.5 VAX/VMS . . . . . . . . . . . . . . . . . . E-45 E.5.1 Bad Block Replacement Attempt Error Log Usage . . . . . . . . . . . . . . . . . . E-45 E.6 RV80 . . . . . . . . . . . . . . . . . . . . E-45 E.6.1 Media Loader Error Logs . . . . . . . . . E-45 E.6.1.1 Controller And Unit Identifiers . . . . E-46 E.6.1.2 Media Loader Error Log Format . . . . . E-48 E.6.1.3 Error Log Message Offsets . . . . . . . E-51 E.6.1.4 Error Log Message Format Codes . . . . . E-52 E.6.1.5 Status And Event Codes . . . . . . . . . E-52 E.6.1.6 Media Loader Error Status Or Event Subcodes . . . . . . . . . . . . . . . . E-53 E.6.1.7 Controller And Unit Identifier Class Values . . . . . . . . . . . . . . . . . E-53 E.6.1.8 Media Loader Identifier Values . . . . . E-54 APPENDIX F PORT ADDRESS AND SYSTEM ADDRESS FORMATS F.1 Port Address Formats . . . . . . . . . . . . F-1 F.1.1 CI Port Address . . . . . . . . . . . . . F-1 F.2 System Address Formats . . . . . . . . . . . F-1 F.2.1 SCA System Address . . . . . . . . . . . . F-2 APPENDIX G REVISION HISTORY APPENDIX H UNANNOUNCED PRODUCTS FIGURES 1-1 Example System . . . . . . . . . . . . . . . 1-2 8-1 Controller Initiated Bad Block Replacement Layers . . . . . . . . . . . . . . . . . . . 8-2 TABLES A-1 Control Message Opcodes . . . . . . . . . . A-1 A-2 Command Modifiers . . . . . . . . . . . . . A-3 A-3 End Message Flags . . . . . . . . . . . . . A-5 A-4 Controller Flags . . . . . . . . . . . . . . A-6 A-5 Unit Flags . . . . . . . . . . . . . . . . . A-7 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTENTS Page ix 11 June 1992 A-6 Command Message Offsets . . . . . . . . . . A-8 A-7 End and Attention Message Offsets . . . . . A-11 A-8 Error Log Message Offsets . . . . . . . . . A-14 A-9 Error Log Message Format Codes . . . . . . . A-17 A-10 Error Log Message Flags . . . . . . . . . . A-17 A-11 Bad Block Replacement Attempt "Replace Flags" . . . . . . . . . . . . . . . . . . . A-18 A-12 Access Nonvolatile Memory Command Operation Codes . . . . . . . . . . . . . . . . . . . A-19 A-13 Format Function Codes . . . . . . . . . . . A-19 A-14 WRITE HISTORY MANAGEMENT Command Operation Codes . . . . . . . . . . . . . . . . . . . A-20 A-15 Write History Entry Entry Flags . . . . . . A-21 A-16 Write History Entry Offsets . . . . . . . . A-21 A-17 Cache Access Attribute Values . . . . . . . A-21 B-1 Status and Event Codes . . . . . . . . . . . B-2 B-2 Status Only Subcode Values . . . . . . . . . B-3 B-3 "Media Format Error" Status or Event Subcode Values . . . . . . . . . . . . . . . . . . . B-5 B-4 "Compare Error" Status or Event Subcode Values . . . . . . . . . . . . . . . . . . . B-6 B-5 "Data Error" Status or Event Subcode Values B-6 B-6 "Host Buffer Access Error" Status or Event Subcode Values . . . . . . . . . . . . . . . B-9 B-7 "Controller Error" Status or Event Subcode Values . . . . . . . . . . . . . . . . . . . B-10 B-8 "Drive Error" Status or Event Subcode Values B-14 B-9 "Bad Block Replacement Completion" Event Only Subcode Values . . . . . . . . . . . . B-16 B-10 "Media Loader Error" Status or Event Subcode Values . . . . . . . . . . . . . . . . . . . B-16 B-11 "Informational" Event Only Subcode Values . B-17 B-12 "Subcommand Error" Status or Event Subcode Values . . . . . . . . . . . . . . . . . . . B-17 B-13 "Cache Error" Status or Event Subcode Values B-18 C-1 Controller and Unit "Class" Values . . . . . C-1 C-2 Mass Storage Controller "Model" Values . . . C-2 C-3 Disk Drive/Media Identifier Values . . . . . C-5 C-4 Tape Drive/Media Identifier Values . . . . . C-8 C-5 Media Loader Identifier Values . . . . . . . C-10 C-6 SCSI Storage Device/Media Identifier Values C-11 H-1 Unannounced Controller "Model" Values . . . H-1 H-2 Unannounced Disk Drive/Media Identifier Values . . . . . . . . . . . . . . . . . . . H-2 H-3 Unannounced Tape Drive/Media Identifier Values . . . . . . . . . . . . . . . . . . . H-3 H-4 Unannounced SCSI Storage Device/Media Identifier Values . . . . . . . . . . . . . H-4 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 INTRODUCTION Page 1-1 11 June 1992 1 CHAPTER 1 2 INTRODUCTION 3 1.1 Overview Of MSCP Subsystem 4 Mass Storage Control Protocol (MSCP) is the protocol used by a 5 family of mass storage controllers and devices designed and built 6 by Digital Equipment Corporation. In a system that uses an MSCP 7 storage subsystem, the controller contains intelligence to 8 perform the detailed I/O handling tasks. This arrangement allows 9 the host to simply send command messages (requests for reads or 10 writes) to the controller and receive response messages back from 11 the controller. The host need not concern itself with details 12 such as device type, media geometry, media format, or error 13 recovery. 14 The host uses two levels of software to accomplish its tasks. 15 The higher level is called a "class driver." The class driver's 16 knowledge of devices is limited to the device class (such as 17 disks) and their capacity. The class driver does not have to 18 know the detailed nature of the communications link (I/O bus), 19 controller, or devices that are being used. 20 The second level of host software is called a "port driver." The 21 port driver passes messages to/from the communications link or 22 bus. It is not aware of the messages' meaning. The port driver 23 does have to know the exact nature of the communications link or 24 bus (communications mechanism). 25 In the controller architecture, there are also two levels of 26 software. The lower of these two is also a "port driver" and, 27 like the port driver in the host, is concerned only with passing 28 messages on and off of the bus. The higher level of controller 29 software is the "MSCP Server." It constitutes the intelligence 30 of the controller and therefore defines the functionality of the 31 controller. 32 The MSCP server concerns itself with determining the number of 33 devices, their type, geometry, unit number, availability, status, 34 etc. The MSCP server receives requests from the host and sends 35 responses to the host. It optimizes the requests, performs the 36 operations, transfers the data to/from the host, transfers the 37 data to/from the device, and buffers the data as necessary. The 38 MSCP server performs error detection and recovery, and reports 39 any significant errors to the host. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 INTRODUCTION Page 1-2 Overview Of MSCP Subsystem 11 June 1992 1 Because the MSCP server handles the error detection and recovery 2 by itself, the host sees "perfect media," an important 3 characteristic of an MSCP subsystem. That is, the host need only 4 report errors to higher level (user) software, as the MSCP server 5 performs all error recovery and media defect (bad block) 6 handling. 7 The host's class driver and the controller's MSCP server route 8 their messages through the path of the two port drivers and a 9 hardware interconnect. This is their physical connection. 10 However, their logical communication is a direct connection 11 because the port driver details are below their level of concern. 12 Therefore, there are two paths to consider: a physical message 13 path and a logical MSCP connection. This is illustrated in 14 Figure 1-1. 15 Host Mass Storage Controller 16 + - - - - - - - - + + - - - - - - - - + 17 | | | | 18 +-----------+ +-----------+ 19 | | Class | | MSCP | | MSCP | | 20 | Driver | <------------------> | Server | 21 | +-----------+ | | +-----------+ | 22 A A 23 | | | | | | 24 V V 25 | +-----------+ | Communications | +-----------+ | 26 | Port | <------------------> | Port | 27 | | Driver | | Protocols | | Driver | | 28 +-----------+ +-----------+ 29 | A | | A | 30 + - - - -|- - - - + + - - - -|- - - - + 31 | | 32 V V 33 +------------------------------------------+ 34 | Port | | Port | 35 | - - + + - - | 36 | Communications Mechanism | 37 | | 38 +------------------------------------------+ 39 Figure 1-1: Example System 40 In summary, an MSCP subsystem is characterized by an intelligent 41 controller that provides the host with the view of perfect media. 42 It is further characterized by host independence from a specific 43 bus, controller, or device type. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 INTRODUCTION Page 1-3 Purpose 11 June 1992 1 1.2 Purpose 2 The purpose of this manual is to provide information on the rules 3 of MSCP to the detail necessary for both writing a host class 4 driver and implementing an MSCP server. 5 1.3 Method Of Presentation 6 The method of presentation used in this manual is: 7 o to define new terms and concepts. 8 o list the responsibilities of the class driver. 9 o list the responsibilities of the MSCP server that are 10 applicable to the class driver. 11 o list the responsibilities of the storage unit that are 12 applicable to the class driver. 13 o explain each command and response message. 14 o explain each error message. 15 o provide appropriate tables of consolidated information. 16 1.4 Scope 17 The scope of this manual is limited to the details of the MSCP 18 itself and does not provide information on any specific type of 19 host processor or any specific operating system. It does not 20 assume any particular bus, controller, device type, host, or port 21 driver implementation. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 TERMINOLOGY Page 2-1 11 June 1992 1 CHAPTER 2 2 TERMINOLOGY 3 Aborted Command 4 From the viewpoint of a class driver, any command for which 5 it has issued an ABORT command. From the viewpoint of an 6 MSCP server, a command for which it has received an ABORT 7 command, located the specified command, and taken explicit 8 action to abort it. An aborted command will be either 9 rejected or terminated. See Section 4.5, "Command Categories 10 and Execution Order." 11 Backing-store 12 In a cached memory system, the memory being served by the 13 cache. This memory is usually much larger and much slower 14 than the cache memory and its performance is enhanced by the 15 cache between it and the user. In the case of cached mass 16 storage, the backing store is the disk or tape media. 17 Cache 18 A fast memory placed between a larger slow memory known as 19 the backing-store and the user. By retaining frequently 20 accessed data in the cache, the apparent performance of the 21 backing-store is improved. A number of different algorithms 22 may be used for the selection of data retained in the cache. 23 Cache Consistency 24 The property that ensures that cached data behaves exactly as 25 if no cache existed. That is, only the last written data 26 will be returned to users and in the case of write-back 27 cache, the last written data will be properly written to the 28 backing-store even in the event of power failure. 29 Command Categories 30 All MSCP commands fall into one of four command categories: 31 Immediate commands, Non-Sequential commands, Sequential 32 commands, and Special commands. Each command category has 33 certain constraints on when those commands may be executed, 34 thus limiting the scope of controller optimizations. See 35 Section 4.5, "Command Categories and Execution Order." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 TERMINOLOGY Page 2-2 11 June 1992 1 Completed Command 2 A command that the MSCP server has executed through to its 3 normal completion, which may be either successful completion 4 or an unrecoverable error. See Section 4.5, "Command 5 Categories and Execution Order." 6 Controller Timeout Interval 7 A time interval, measured in seconds, supplied by the 8 controller or MSCP server in the SET CONTROLLER 9 CHARACTERISTICS command's end message. Controllers or MSCP 10 servers guarantee that they will complete all Immediate 11 commands plus some measurable amount of useful work on their 12 oldest outstanding non-Immediate command within the 13 controller timeout interval. See Section 4.10, "Command 14 Timeouts." 15 Forced Error 16 A data error (in a disk block) that has been deliberately 17 caused by use of the "Force Error" command modifier. Used to 18 indicate that the data in the block is of questionable 19 validity. For example, an unrecoverable error occurred when 20 the data was copied from some other block. 21 Forced Error Indicator 22 The logical flag, present in each disk block, used to record 23 the presence of a Forced Error. Depending upon the detailed, 24 low level format of the disk device, this may be implemented 25 either as an actual bit flag or as a special pattern (such as 26 the complement of the normal value) of error correcting 27 and/or error detecting codes. 28 Immediate Commands 29 Commands that MSCP servers shall execute immediately, without 30 waiting for any other commands to complete. Immediate 31 commands are typically status inquiries, and shall be 32 completed within the controller timeout interval. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 TERMINOLOGY Page 2-3 11 June 1992 1 May 2 Denotes a lack of prohibition when used as a directive. It 3 is used to indicate an option or options architecturally 4 permissible for an implementation. No bias for or against 5 the option is implied. "May not" denotes strict prohibition 6 when used as a directive. 7 Non-Sequential Commands 8 Commands whose execution order MSCP servers may rearrange in 9 order to optimize performance. The optimization shall not 10 move a Non-Sequential command past the barrier imposed by a 11 Sequential command. 12 Nugatory 13 Of little or no consequence: Trifling, Inconsequential. See 14 Section 6.4, "AVAILABLE Command." 15 Prefetch 16 The act of reading data logically following requested data 17 during a data transfer command. If the user access patterns 18 frequently access the data following previously requested 19 data, performance improvement will result. 20 Rejected Command 21 A command that the MSCP server rejects, discards, aborts, or 22 otherwise finishes before it begins to execute it. See 23 Section 4.5, "Command Categories and Execution Order." 24 Sequential Commands 25 Commands that MSCP servers shall execute in the exact order 26 that they were received from class drivers. Sequential 27 commands typically change a unit's state or context. 28 Shall 29 Denotes an architectural requirement. It is used as a 30 directive to express what is mandatory for an implementation. 31 "Shall not" denotes strict prohibition. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 TERMINOLOGY Page 2-4 11 June 1992 1 Should 2 Denotes an emphatic recommendation when used as a directive. 3 It is used where "shall" might be too strong because of the 4 possibility of technical, implementation specific obstacles 5 or other overriding considerations. 6 Special Commands 7 Commands that have both the execution order constraints of 8 Non-Sequential commands plus certain special, command 9 dependent execution order constraints. 10 Terminated Command 11 A command that the MSCP server terminates after it has been 12 partially executed. See Section 4.5, "Command Categories and 13 Execution Order." 14 Write-back Cache 15 A cache in which a write operation places the data in the 16 cache and the completion response is returned before the data 17 is written to the backing-store. 18 Write-through Cache 19 A cache in which a write operation places the data in the 20 cache and writes it to the backing-store before the 21 completion response is returned. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-1 11 June 1992 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 connection 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 -- i.e., command, end, and 21 attention messages. This service guarantees sequential, 22 duplicate-free delivery for all messages sent across the 23 same connection. This service supports messages of at 24 least 48 bytes in length. 25 o A datagram communication service, used for MSCP error 26 log messages. This service delivers messages sent on it 27 with very high probability. Messages may be delivered 28 out of sequence, lost, or duplicated, but the 29 probability of any of these occurring shall be very low. 30 This service supports messages of no more than 128 bytes 31 in length. 32 o A block data communication service, used to move data 33 between hosts and mass storage controllers. This 34 service provides a reliable, efficient method of 35 transferring the contents of a named buffer in one 36 subsystem to a named buffer in another subsystem. 37 Buffers are identified by buffer descriptors, which 38 identify both the buffer and the subsystem (host) in 39 which the buffer resides. 40 The communications mechanism or port drivers discard all messages *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-2 Connection 11 June 1992 1 that, at the time a connection is terminated, have been sent or 2 queued to be sent via the sequential message and datagram 3 services but have not yet been delivered. Block data transfers 4 may or may not be terminated when a connection is terminated. If 5 terminated, they may have already been partially completed. 6 Block data transfers from a previous incarnation of a connection 7 are guaranteed to have been terminated when the connection is 8 re-established. 9 Besides using these three communications services directly, MSCP 10 uses the establishment of the connection itself to synchronize 11 class drivers and MSCP servers. Either the class driver or the 12 MSCP server will terminate the connection between them (become 13 "Controller-Available") if it determines that they must 14 resynchronize with each other. Events that require class driver 15 / MSCP server resynchronization include certain errors or loss of 16 context by either process. The connection is also terminated, by 17 a port driver, if an unrecoverable communications error occurs. 18 Termination of the connection signals the processes that 19 resynchronization is necessary. The resynchronization is 20 accomplished by each process discarding all context regarding 21 outstanding commands or transactions, after which a new 22 connection is established. 23 Following resynchronization, commands which were outstanding 24 before the resynchronization was performed may have completed to 25 an indeterminate extent. Such commands may have been rejected 26 (never started), may have been terminated (partially completed), 27 or may have been fully completed. The only guarantee is that 28 they are no longer outstanding, implying that the controller is 29 no longer performing work for them and that the class driver will 30 not receive an end message for them. The fact that the 31 controller is no longer performing work for them implies that no 32 state changes or modification of data will take place as a result 33 of such commands. 34 3.2 Flow Control 35 Especially critical to MSCP is the concept of flow control and 36 the flow control based requirements that MSCP imposes on class 37 drivers and MSCP servers. These items are discussed below. 38 Flow control arises from the need to avoid the congestion and/or 39 deadlock which can occur if one process sends messages too 40 quickly to another process. The receiving process must have 41 buffers in which to place the incoming messages. When all such 42 buffers are full, additional messages cannot be handled. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-3 Flow Control 11 June 1992 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 privilege 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 threshold 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. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-4 Flow Control 11 June 1992 1 2. The revocation request is communicated to the revoking 2 process's partner (actually to its port driver). 3 3. The revoking process's partner (actually its port 4 driver) compares the number of buffers to be revoked 5 against its current credit balance and a threshold. If 6 the requested number of buffers / credits can be revoked 7 (i.e., subtracted from the credit balance) without 8 lowering the credit balance below the threshold, then 9 all of them will be revoked. Otherwise, if the credit 10 balance is above the threshold, it is set to the 11 threshold and the difference between its former value 12 and the threshold is the number of buffers / credits 13 actually revoked. If the credit balance is already at 14 or below the threshold, then it stays the same and no 15 buffers / credits are revoked. 16 4. The actual number of buffers / credits revoked is 17 communicated back to the revoking process's port driver. 18 5. The revoking process's port driver returns the buffers 19 actually revoked to the revoking process. 20 If a threshold of zero is used, the revoking or receiving process 21 can always get back all of its buffers. The fact that an 22 attempted revocation failed implies that the buffers have already 23 been returned to the process, since messages have been received 24 into them. 25 The above algorithm uses a threshold to prevent revocation below 26 some lower limit. The mechanism by which this threshold is 27 obtained is not critical to either MSCP or to the above 28 algorithm. The rules below are phrased as if the threshold were 29 supplied by the revoking process as part of the revocation 30 request. This is purely to simplify the wording of those rules; 31 often the thresholds will be constants determined when a 32 connection is established. In such an implementation a threshold 33 of zero should be used when the class driver is revoking credits 34 it has granted to the MSCP server and a threshold of one should 35 be used when the MSCP server is revoking credits it has granted 36 to the class driver. 37 MSCP is only concerned with credits required by the sequenced 38 message service. Some communications services may require 39 credits for the block data communication service as well. Any 40 such credits are invisible to MSCP, being communications service 41 dependent, and shall be provided in addition to the credits 42 required by the rules below. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-5 Flow Control 11 June 1992 1 Note that the above discussion merely describes a conceptual 2 model for flow control within the sequential message 3 communications service. There is no requirement that flow 4 control actually be implemented this way, provided that the 5 results are the same. For example, almost all implementations 6 will carry credit information in a header added to messages and 7 processed by the receiving process's port driver, rather than 8 communicating credits with separate messages. Some extremely 9 well behaved communications mechanisms may not need to implement 10 explicit flow control at all, since the underlying communications 11 mechanism may provide it implicitly. 12 3.2.1 Class Driver Responsibilities 13 Given the above model for flow control, we can state the 14 requirements MSCP places on class drivers and MSCP servers. 15 Class drivers shall obey the following rules: 16 1. All MSCP commands fall into one of several categories; 17 for this discussion we distinguish between Immediate 18 commands (one specific command category) and 19 non-Immediate commands (the union of all other command 20 categories). When the class driver's credit balance is 21 zero, the class driver may not issue any commands. When 22 it is one, the class driver may only issue Immediate 23 commands. When it is two or larger, the class driver 24 may issue both Immediate and non-Immediate commands. If 25 the class driver's credit balance is one and there is a 26 GET COMMAND STATUS command waiting to be issued for the 27 command timeout algorithm, then the class driver shall 28 issue that GET COMMAND STATUS command as the next 29 command. 30 In essence, this rule means that the class driver shall 31 reserve one credit for the exclusive use of the command 32 timeout algorithm. This credit may be "borrowed" for 33 issuing Immediate commands, since such commands always 34 complete quickly. The goal is to guarantee that the 35 command timeout algorithm will always be able to 36 promptly issue a GET COMMAND STATUS command. 37 2. The class driver shall queue a receive buffer for each 38 command that it sends to an MSCP server. The receive 39 buffer will be used to hold the command's end message. 40 The receive buffer shall be queued either before the 41 command is sent or as part of an atomic (indivisible) 42 action that includes sending the command. The important 43 point is that the MSCP server must receive the credit 44 for the receive buffer either before or concurrently 45 with receiving the command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-6 Flow Control 11 June 1992 1 3. In addition to queuing receive buffers for end messages, 2 class drivers that enable attention messages shall queue 3 at least one receive buffer in which to receive 4 attention messages. Such a receive buffer shall be 5 queued before the class driver enables attention 6 messages -- i.e., before the class driver sends a SET 7 CONTROLLER CHARACTERISTICS command that enables 8 attention messages. Additional receive buffers may be 9 queued at any time. Note that, with most controllers, 10 there is no benefit to queuing more than one attention 11 message receive buffer. 12 4. Upon receiving an attention message, the class driver 13 shall immediately queue another (or the same) receive 14 buffer back for more attention messages. The only 15 resource that the class driver may require between 16 receiving an attention message and queuing another 17 receive buffer is host CPU cycles. The class driver 18 shall not require that it be able to send or receive any 19 other messages or wait for any I/O to complete before 20 queuing another receive buffer. This effectively 21 requires that all code and data structures needed to 22 process attention messages be permanently resident in 23 physical memory, so that an incoming attention message 24 can be immediately processed and the buffer in which it 25 was received immediately requeued. 26 5. With one exception, the class driver shall never revoke 27 receive buffers. The one exception is after disabling 28 attention messages -- i.e., after receiving the end 29 message for the SET CONTROLLER CHARACTERISTICS command 30 that disabled attention messages. At that time the 31 class driver may revoke as many buffers as it has queued 32 for attention messages (i.e., total number of buffers 33 queued less number of outstanding commands). This 34 revocation should specify a threshold of zero. Note 35 that this revocation is guaranteed to succeed if the 36 MSCP server is operating correctly. 37 Note that the class driver can accomplish the effect of 38 revoking end message receive buffers by aborting MSCP 39 commands. The receive buffers will be returned to the 40 class driver as soon as the (aborted) commands complete. 41 Failure of a class driver to follow the above rules may lead to 42 controller deadlock, command timeouts, or the controller not 43 obeying its rules given below. Any connection or process in the 44 controller's subsystem may be affected, rather than just the MSCP 45 server with which the class driver is communicating. Note that 46 class drivers that enable error logging must also keep datagram *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-7 Flow Control 11 June 1992 1 buffers queued so that they can receive error log messages. Not 2 keeping datagram buffers queued may result in loss of error log 3 messages. 4 3.2.2 MSCP Server Responsibilities 5 The rules for MSCP servers vary depending upon certain 6 characteristics of the server. There is one general set of 7 rules, plus a simplification that certain classes of servers may 8 follow. In all cases, an MSCP server's implementation of these 9 rules may require, for its correct operation (and thus adherence 10 to these rules), that class drivers correctly follow the rules 11 given for them above. The general set of rules, which shall be 12 followed by all MSCP servers that are not in any of the special 13 cases identified later, are as follows: 14 1. So long as it is "Controller-Online" to a class driver, 15 an MSCP server shall ensure that the sum of the number 16 of commands that are outstanding from that class driver 17 plus the number of unused receive buffers / credits that 18 it has granted to that class driver is never lower than 19 the values given below. That is, the sum of the actual 20 and potential outstanding commands shall be at least the 21 values below. Between the time that the controller 22 becomes "Controller-Online" and the completion of the 23 first SET CONTROLLER CHARACTERISTICS command, this sum 24 shall be at least one. Following the completion of the 25 first SET CONTROLLER CHARACTERISTICS command, and so 26 long as the controller remains "Controller-Online," this 27 sum shall be at least two. The first unit of this sum 28 allows the class driver to issue Immediate commands. 29 Any excess, beyond the value one, may be used to issue 30 "real" commands such as data transfers. Note that these 31 requirements imply that, following a SET CONTROLLER 32 CHARACTERISTICS command, the MSCP server shall either 33 grant a minimum of two receive buffers / credits to the 34 class driver or else terminate the connection (become 35 "Controller-Available") with the class driver. 36 2. So long as it is "Controller-Online" to a class driver, 37 an MSCP server shall ensure that the sum of the number 38 of Immediate commands that are outstanding from that 39 class driver plus the number of unused receive buffers / 40 credits that it has granted to that class driver is 41 always at least one. That is, the sum of the actual and 42 potential outstanding Immediate commands shall be at 43 least one. This is in addition to requirement 1 above. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-8 Flow Control 11 June 1992 1 3. An MSCP server may revoke receive buffers or credits at 2 any time so long as it continues to meet requirements 1 3 and 2 above. Note that, in order to meet requirement 2, 4 the sum of the threshold used for the revoke request 5 plus the number of outstanding Immediate commands (from 6 that class driver) must be at least one. This 7 restriction will typically be met by always using a 8 threshold of one. 9 4. Notwithstanding all that has been said above, MSCP 10 servers shall allow hosts to perform transfers without 11 the host having to issue a SET CONTROLLER 12 CHARACTERISTICS command. This is necessary to simplify 13 the implementation of host bootstraps. The commands to 14 perform such transfers shall be issued one at a time 15 (rule 1 above ensures that the host has at least the one 16 credit it needs to issue these commands). The MSCP 17 server shall either grant the host a minimum of two 18 credits when it becomes "Controller-Online" or else 19 perform commands regardless of the fact that the host is 20 nominally violating the requirements described in 21 Section 3.2.1, "Class Driver Responsibilities." The 22 specific requirement violated is that the host will be 23 issuing non-Immediate commands in spite of its credit 24 balance being only one. 25 5. An MSCP server shall keep track of the excess, if any, 26 of its credit balance over the number of outstanding 27 commands. The server may only issue attention messages 28 when this excess is greater than zero. Attention 29 messages that cannot be issued immediately should be 30 saved until credits are available with which to issue 31 them. The controller shall continue to accept new 32 commands, process outstanding commands, and issue end 33 messages for completed commands while attention messages 34 are being saved. If the conditions that triggered the 35 generation of an attention message disappear before that 36 attention message can be issued (sent), then the 37 attention message may or may not still have to be sent. 38 See the individual attention message descriptions 39 contained in Section 5.8, "Attention Messages." 40 With many communications mechanisms there is an inherent or 41 unavoidable race that MSCP servers must be prepared to resolve. 42 It can occur whenever the credit for an end message might be sent 43 as a distinct message, rather than always being embedded in the 44 communications mechanism header for the corresponding command 45 message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-9 Flow Control 11 June 1992 1 Suppose the host class driver grants one credit for attention 2 messages, and that some combination of events causes the MSCP 3 server to want to send two attention messages. The attention 4 message credit is used to send the first attention message and 5 the second is queued for later transmission. Meanwhile, the 6 class driver sends a command and its associated end message 7 credit to the MSCP server as two distinct messages. Per the 8 class driver requirements described in Section 3.2.1, "Class 9 Driver Responsibilities," the notification of the end message 10 credit must be sent first. When this notification arrives at the 11 controller, the MSCP server thinks it is the attention message 12 credit being returned (since credits are anonymous) and sends the 13 second attention message. Immediately thereafter the command 14 arrives and the MSCP server discovers an apparent rule violation 15 by the class driver, namely that it appears to have sent a 16 command without an accompanying credit for the end message. 17 This credit imbalance problem will ultimately be resolved when 18 the class driver returns the attention message credit. As the 19 class driver is not allowed to perform any I/O before returning 20 attention message credits, we are assured that the credit will be 21 returned both promptly and without any possibility of deadlock. 22 Therefore, whenever this race occurs, the MSCP server may hang 23 until the attention message credit is returned. Although it is 24 permissible for all MSCP servers for all device classes and 25 connections to hang, it is highly desirable if only the one 26 connection is affected. 27 Typically the command(s) that is(are) lacking an end message 28 credit would be held in a queue, with no work done on them until 29 their end message credits arrive. Note that if the host did not 30 return attention message credits promptly, this would result in 31 command timeouts. The MSCP server shall service the waiting 32 commands in their order of arrival. Thus if another command 33 arrives with a credit embedded in its communications mechanism 34 header, the MSCP server shall transfer that credit to the oldest 35 command waiting for an end message credit and place the new 36 command on the waiting queue. 37 MSCP servers that limit the rate at which they generate attention 38 messages can replace rule 5 above with a simpler rule. This 39 alternate rule may be used, at the server's option, by any MSCP 40 server that will generate no more than an average of two 41 attention messages per second, averaged over the controller 42 timeout interval (see Section 4.10, "Command Timeouts"). That 43 is, if the controller timeout interval is N seconds, then the 44 server will generate no more than N*2 attention messages within 45 any N second period. The MSCP server may assume, in determining 46 its maximum attention message rate, that human operators do not 47 engage in pathological activity. I.e., it may assume that cases *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-10 Flow Control 11 June 1992 1 such as an operator continuously actuating the Run/Stop switches 2 on one or more drives will never occur. Any MSCP server that can 3 meet this attention message rate restriction may substitute the 4 following alternate rule for rule 5 above: 5 5'. An MSCP server may issue attention messages and end 6 messages whenever its credit balance is greater than 7 zero. Attention messages and end messages that cannot 8 be issued immediately should be saved until credits are 9 available with which to issue them. If the conditions 10 that triggered the generation of an attention message 11 disappear before the attention message can be issued 12 (sent), then that attention message may or may not still 13 have to be sent. See the individual attention message 14 descriptions contained in Section 5.8, "Attention 15 Messages." Saved end messages shall always be sent, 16 unless the MSCP server first becomes 17 "Controller-Available" (i.e., terminates its connection 18 with the class driver), in which case the saved end 19 messages shall not be sent. Note that end messages 20 shall always be sent in the order that their 21 corresponding commands completed. 22 An MSCP server may deadlock or cease operating on a 23 connection whenever it has saved attention messages or 24 end messages waiting to be issued on that connection. 25 The only operations that it is required to perform when 26 it has such messages waiting are to accept incoming 27 credit notifications, send the waiting messages when 28 credits become available, and resume normal operation 29 when all waiting messages have been sent. Note that 30 accepting incoming credit notifications will often 31 require that the MSCP server also accept new commands, 32 although it need not begin processing of those new 33 commands until all waiting messages have been sent. 34 Note also that only the one MSCP server may deadlock or 35 cease operating; other processes (i.e., other MSCP 36 servers) in the same subsystem or controller and other 37 connections to the same MSCP server shall not be 38 affected. 39 The effect of this modified rule is to allow MSCP servers to 40 "borrow" end message credits for the purpose of sending attention 41 message credits. 42 3.3 Multihost Communication 43 Chapter 1, "Introduction," Figure 1-1, "Example System," shows a 44 "Single Host" system, where a single host is connected to a 45 single controller. Certain communications mechanisms permit *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CLASS DRIVER / MSCP SERVER COMMUNICATIONS Page 3-11 Multihost Communication 11 June 1992 1 communications between multiple entities (nodes) interconnected 2 along the same physical path. With such a communications 3 mechanism it is possible to create a "Multihost" system, where 4 multiple hosts are connected to a single controller. 5 Controllers which support multinode communications mechanisms 6 will usually (not an absolute requirement of MSCP) implement the 7 Multihost Support option (see Section 5.6, "Controller Flags"). 8 Multihost Support allows simultaneous communication between 9 multiple host class drivers and an MSCP server. The 10 communication takes place across separate logical connections 11 established between the class drivers and the MSCP server. The 12 MSCP server shall treat each connection with a class driver as a 13 separate and unique entity, with each connection obeying all the 14 communication rules detailed in the preceding sections of this 15 chapter. New connections may be accepted or rejected without 16 regard to the number of existing connections (other than resource 17 limitations), and no notification will be given to the new 18 connection as to the presence or absence of other connections. 19 Class driver/server synchronization is on a per connection basis, 20 and the loss of synchronization between a class driver and the 21 controller on a specific connection should not affect any other 22 connections which may be open, unless all connections are 23 affected and a hard initialization of the controller is required. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-1 11 June 1992 1 CHAPTER 4 2 ALGORITHMS AND USAGE RULES 3 4.1 Controller States 4 The controller may be in any of three states relative to a host 5 class driver. The controller may be in a different state 6 relative to each host or each class driver. The controller 7 states are: 8 Controller-Offline 9 A controller is "Controller-Offline" to a class driver 10 whenever it is not available to that class driver and cannot 11 perform any operations on its behalf. Possible causes 12 include inoperative hardware or an operator disabling the 13 controller. A controller is "Controller-Offline" exactly 14 when it is not possible to establish a connection between the 15 class driver and the MSCP server within the controller. Note 16 that a controller may be "Controller-Offline" to some of a 17 host's class drivers yet be "Controller-Available" or 18 "Controller-Online" to others. 19 Controller-Available 20 A controller is "Controller-Available" to a class driver 21 whenever it could perform operations for that class driver, 22 but the driver has not yet synchronized with the controller. 23 A controller is "Controller-Available" exactly when it would 24 be possible to establish a connection between the class 25 driver and the MSCP server within the controller, but no 26 connection has yet been established. 27 Controller-Online 28 A controller is "Controller-Online" to a class driver 29 whenever it can both perform operations for that class driver 30 and the driver has synchronized with the controller. A 31 controller is "Controller-Online" exactly when a connection 32 exists between the class driver and the MSCP server within 33 the controller. This is the state used for normal operation. 34 Strictly speaking, the term "controller state" is a misnomer. 35 The states described above actually exist between an individual 36 class driver and an individual MSCP server. A host may have 37 several class drivers and a controller subsystem may have several 38 MSCP servers (usually one for each device class supported). 39 Furthermore, controllers that provide Multihost Support allow *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-2 Controller States 11 June 1992 1 multiple connections between its server(s) and multiple class 2 drivers resident in one or more hosts. 3 Note also that the controller state (MSCP server state?) is 4 distinct from the state of any unit connected to the controller. 5 An MSCP server (controller) enters the "Controller-Offline" state 6 relative to a host whenever the MSCP server ceases to function or 7 otherwise becomes unable to perform operations for the host. 8 Possible causes include: 9 1. Controller hardware, software, or power failure. 10 2. Controller initialization, either requested or 11 spontaneous. 12 3. An operator (typically Field Service) disables all or 13 part of the controller. 14 4. Communications mechanism failures. 15 5. The controller has not been built yet, the controller is 16 still in its shipping crate, or it has otherwise not yet 17 been installed. 18 An MSCP server enters the "Controller-Available" state relative 19 to a host class driver when: 20 1. The controller or MSCP server is "Controller-Offline," 21 and all causes of it being "Controller-Offline" are 22 removed. 23 2. The MSCP server is "Controller-Online," and the MSCP 24 server cannot successfully send a control message (i.e., 25 an MSCP end or attention message) to the host class 26 driver. 27 3. The MSCP server is "Controller-Online," and the host 28 access timeout expires. See Section 4.9, "Host Access 29 Timeouts." 30 4. The MSCP server is "Controller-Online," and the MSCP 31 server receives an "Invalid Command" (see "Invalid 32 Command" status in Section 5.5, "Status Codes") from the 33 host. Note that this transition to 34 "Controller-Available" is optional, and therefore 35 controller dependent. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-3 Controller States 11 June 1992 1 5. The host class driver terminates the connection between 2 the class driver and the MSCP server. 3 6. A port driver or the communications mechanism terminates 4 the connection between the class driver and the MSCP 5 server, generally due to a communications error. 6 7. An MSCP server terminates the connection between itself 7 and a host class driver as a result of the execution of 8 a TERMINATE CLASS DRIVER/SERVER CONNECTION command as 9 described in Section 7.10, "Multihost TERMINATE CLASS 10 DRIVER/SERVER CONNECTION Command." 11 The port driver should inform the class driver whenever the MSCP 12 server enters the "Controller-Available" state. How the port 13 driver obtains this information is communications mechanism 14 dependent. Note that the notification that the controller has 15 become "Controller-Available" is not necessarily prompt. In 16 particular, with some communications mechanisms the notification 17 may not occur until the next time the class driver issues a 18 command to the controller. Furthermore, the port driver need not 19 notify the class driver at all if a compound (multiple) error is 20 associated with the MSCP server becoming "Controller-Available." 21 In such a case the class driver will ultimately become aware of 22 the state change when its Command Timeout expires (see Section 23 4.10, "Command Timeouts"). 24 Since no connection exists to an MSCP server that is 25 "Controller-Offline" or "Controller-Available," the 26 communications mechanism will either reject or discard any 27 messages (commands) that a class driver attempts to send to it. 28 An MSCP server that becomes "Controller-Offline" or 29 "Controller-Available" may either terminate commands in progress 30 or else continue processing the commands that it has already 31 received. However, if a Sequential command from a given 32 connection is terminated or rejected, then all subsequently 33 received non-Immediate commands from the same connection shall 34 also be rejected (i.e., shall never begin processing). 35 Typically, the MSCP server will continue processing outstanding 36 commands until it "notices" that the connection to the class 37 driver has been terminated, at which point it will terminate any 38 commands still outstanding and reject any commands that haven't 39 begun processing yet. Note that the MSCP server shall guarantee 40 that all outstanding commands have been completed, aborted, 41 rejected, or terminated (i.e., that there are no outstanding 42 commands) before it completes a transition from 43 "Controller-Available" to "Controller-Online." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-4 Controller States 11 June 1992 1 The MSCP server enters the "Controller-Online" state relative to 2 a host class driver upon successful synchronization with the 3 class driver. The class driver synchronizes with the MSCP server 4 by establishing a connection with the MSCP server. Note that the 5 MSCP server shall guarantee that there are no outstanding 6 commands "leftover" from a previous incarnation of the connection 7 before it allows the new incarnation of the connection to be 8 established and enters the "Controller-Online" state. 9 4.2 Controls And Indicators 10 All storage units used with MSCP must have the following controls 11 and indicators: 12 o Unit number select mechanism. 13 o Unit number display mechanism. 14 o Run/Stop switch (on disk units) or a Load/Unload switch 15 (on tape units). 16 o Write protect switch or mechanism. 17 o Write protect status indicator. 18 The unit number select mechanism on an MSCP storage unit shall 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 shall operate without host intervention and shall 23 preserve unit numbers across power failures and other losses of 24 context. 25 Alteration of the unit number must be possible in the field. 26 That is, the unit number shall be alterable by Field Service, 27 both when a device is first installed and subsequently when a 28 system is reconfigured. The preferred unit select mechanism is a 29 removable unit number plug, allowing the unit number to be 30 altered by users as well as by Field Service. Alternatives to 31 unit number plugs, however, are acceptable so long as they can be 32 altered by Field Service and they provide the full 0 through 251 33 unit number range. 34 A single unit number select mechanism may be shared by the units 35 of a multiunit drive or formatter (see Section 4.16.2, "Multiunit 36 Drives and Formatters"). Units that share a unit number select 37 mechanism shall always have consecutive unit numbers. If exactly 38 two units share a unit number select mechanism, it is acceptable 39 for the first unit to always have an even unit number and the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-5 Controls And Indicators 11 June 1992 1 last unit to always have an odd unit number. If exactly N units 2 share a unit number select mechanism, it is acceptable for the 3 first unit's unit number to always be a multiple of N, the next 4 unit's unit number to always be a multiple of N plus 1, etc. 5 The unit number display mechanism on an MSCP storage unit shall 6 display the unit number(s) specified by the unit number select 7 mechanism. The display shall be visible to normal (non-Field 8 Service) human operators. If the unit number select mechanism is 9 a removable unit plug, then the unit number display mechanism may 10 merely be a number printed on the plug. If several units share a 11 unit number select mechanism, then they may also share a unit 12 number display mechanism. 13 The Run/Stop switch or Load/Unload switch shall be alterable by 14 normal (non-Field Service) human operators to allow or disallow 15 host access to the unit(s). When in the Run or Load position, 16 this switch indicates that hosts should be allowed to access the 17 unit(s). When in the Stop or Unload position, this switch 18 indicates that hosts should not be allowed to access the unit(s). 19 If the unit(s) have removable media, the switch also indicates 20 that human operators should be allowed to remove the units' media 21 (i.e., that the unit should be spun-down). A single Run/Stop 22 switch may be shared by any units of a multiunit drive that share 23 a spindle (i.e., that must be spun-up and spun-down together). 24 The write protect switch or mechanism shall either be an operator 25 accessible switch or else some kind of mechanical deformation of 26 the media, such as a tape write-ring or the write-lockout tab on 27 a cassette. In either case, it shall be alterable by normal 28 (non-Field Service) human operators. A separate write protect 29 switch or mechanism shall be provided for each unit of a 30 multiunit drive. When actuated, the write protect switch or 31 mechanism prevents write access to the unit by hosts and 32 controllers. In the case of a write protect switch, the 33 transition to the write protected state shall be "smooth" rather 34 than immediate. See Section 4.14, "Write Protection." 35 The write protect status display mechanism shall display the 36 write protect status of the unit. A separate write protect 37 status display mechanism shall be provided for each unit of a 38 multiunit drive. The write protect status display shall be user 39 visible while a volume is mounted in the unit. That is, the user 40 shall not be required to remove the volume from the unit to 41 determine whether or not it is write protected. 42 The preferred write protect status display mechanism is a light, 43 located within the write protect switch, that is on whenever the 44 unit is write protected. The light shall be lit regardless of 45 the reason for the unit being write protected -- i.e., it shall *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-6 Controls And Indicators 11 June 1992 1 be lit when the unit is Software Write Protected or Data Safety 2 Write Protected as well as when the unit is Hardware Write 3 Protected due to its write protect mechanism being activated. 4 See Section 4.14, "Write Protection." 5 4.3 Unit States 6 Each unit may be in one of three states relative to each class 7 driver that is "Controller-Online" to an MSCP server. (Actually, 8 it is really each unit number that these states apply to, rather 9 than to a unit proper.) Each unit may be in a different state 10 relative to each "Controller-Online" class driver. Controllers 11 shall therefore maintain the unit state separately for each 12 connection. Note that a unit's state is meaningless with respect 13 to a class driver that is not "Controller-Online" to the MSCP 14 server or when no class driver is "Controller-Online" to the MSCP 15 server. 16 The three unit states are: 17 Unit-Offline 18 A unit is "Unit-Offline" whenever it is unable to satisfy 19 normal host requests. Except for status queries, MSCP 20 commands addressed to a unit that is "Unit-Offline" shall be 21 rejected. Furthermore, many device characteristics may not 22 be available to status queries. 23 Unit-Available 24 A unit is "Unit-Available" whenever it would be able to 25 satisfy normal host requests, except that the host has not 26 yet issued an ONLINE command to bring the unit 27 "Unit-Online." 28 Unit-Online 29 A unit is "Unit-Online" whenever it is able to satisfy normal 30 host requests and the host has issued a successful ONLINE 31 command. 32 A fourth unit state, actually a pseudo-state, exists with 33 controllers that provide Multihost Support. Each MSCP server 34 contained in such a controller shall implement the "Exclusive 35 Access" feature, which allows a single host class driver to 36 reserve a unit for its exclusive use. The host that has obtained 37 "Exclusive Access" of a unit has complete control of that unit 38 and may perform all normal unit operations. All other hosts are 39 prevented from performing any operation that would alter the 40 state or context of the unit in any manner. The other hosts are, *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-7 Unit States 11 June 1992 1 however, permitted to obtain the unit's characteristics as 2 maintained by the controller via all commands that return those 3 characteristics. While a unit is under the "Exclusive Access" of 4 a host the controller shall prevent any other controller to which 5 the unit may be connected from bringing that unit or some other 6 unit with which it shares an access path online with respect to 7 that controller (see Sections 4.16.1, "Multiaccess Drives" and 8 4.16.2, "Multiunit Drives and Formatters"). "Exclusive Access" 9 is termed a pseudo-state because that context is maintained 10 solely by the controller without the knowledge nor direct 11 participation of the unit. The state of the unit with respect to 12 the host that has "Exclusive Access" is totally dependent on the 13 operations that host has requested: it may be "Unit-Online," 14 "Unit-Available," or "Unit-Offline" (provided the unit remains 15 operative and known to the controller). The unit is 16 "Unit-Offline" with respect to all other hosts. Host control of 17 "Exclusive Access" is provided through the operation of the 18 AVAILABLE, ONLINE or SET UNIT CHARACTERISTICS commands. See the 19 description of those commands contained in Chapter 7, "Multihost 20 Support" for more details. 21 The "Unit-Offline" state has seven substates, related to the 22 exact reason for the unit being "Unit-Offline." These substates 23 are: 24 1. Unit inoperative. Some fatal error condition in the 25 drive prevents the unit from becoming "Unit-Available" 26 or "Unit-Online." 27 2. Unit disabled. Field Service or a diagnostic has 28 decided that continued operation of the unit's drive 29 will lead to progressive deterioration and eventual 30 destruction of some portion of the drive or media. The 31 unit has been disabled to prevent its use, and 32 consequent destruction, until Field Service can repair 33 the problem. This cause of the unit being 34 "Unit-Offline" can be overridden, and the unit brought 35 "Unit-Online," by use of the "Allow Self Destruction" 36 modifier to the ONLINE command. Note that some devices 37 may have no way of detecting progressive deterioration, 38 and consequently will never enter this substate. 39 3. Unit known. The controller knows that the specified 40 unit (i.e., a unit with the specified unit number) 41 exists, but the unit is "Unit-Offline" for some normal 42 (nonerror) condition. Typical causes of this substate 43 include the unit's Run/Stop or Load/Unload switch being 44 in the Stop or Unload position or no volume being 45 mounted in the unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-8 Unit States 11 June 1992 1 4. Under exclusive use of another host. The specified unit 2 exists and would be "Unit-Available," except that 3 another host connected via the same controller has been 4 granted "Exclusive Access" of the unit. 5 5. Online to another controller. The specified unit exists 6 and would be "Unit-Available," except that it or some 7 other unit with which it shares an access path (i.e., 8 some other unit on the same multiunit drive or 9 formatter) is "Unit-Online" to one or more hosts or is 10 under the "Exclusive Access" of a host via another 11 controller. The unit will become "Unit-Available" via 12 this controller if it and all units with which it shares 13 an access path cease being "Unit-Online" to any hosts or 14 under the "Exclusive Access" of a particular host via 15 that other controller. In terms of the "Unit-Offline" 16 substate that is visible to and reported by a 17 controller, a unit that is actually online to another 18 controller will typically oscillate between the "Online 19 to another controller" substate and the "Unit unknown" 20 substate. The frequency of the oscillation is 21 determined by the frequency at which hosts issue 22 DETERMINE ACCESS PATHS commands to the other controller 23 for this unit or any unit with which it shares an access 24 path. See Sections 4.16.1, "Multiaccess Drives" and 25 4.16.2, "Multiunit Drives and Formatters" for more 26 information. 27 6. Duplicate unit numbers. That is, two or more distinct 28 units have the same unit number assigned to them. 29 Controllers shall check for duplicate unit numbers 30 across all units of the same device class that are 31 "Unit-Online," that are "Unit-Available," or that are in 32 one of the following "Unit-Offline" substates: unit 33 disabled, unit known, under exclusive use of another 34 host, duplicate unit numbers, or online to another 35 controller. A controller may or may not, at its option, 36 include inoperative units when checking for duplicate 37 unit numbers. Controllers may not check units that are 38 unknown (as described below) nor may they check for 39 duplicate unit numbers across different device classes. 40 Note that a duplicate unit number does not affect a unit 41 that is already "Unit-Online" to or under the "Exclusive 42 Access" of a host. 43 7. Unit unknown. As far as the controller can determine, 44 no unit exists with the specified unit number. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-9 Unit States 11 June 1992 1 It is possible for a unit to be "Unit-Offline" for several 2 reasons at the same time (unless the unit is unknown). If a unit 3 has a duplicate unit number and is not inoperative, then the 4 controller shall report the duplicate unit number; other causes 5 of the unit being "Unit-Offline" may also be reported at the 6 controller's option. In all other cases the controller shall 7 report at least one cause of the unit being "Unit-Offline," but 8 which one it reports and whether or not it reports more than one 9 is optional with the controller. 10 The fact that a unit is inoperative may not be detectable until a 11 host attempts to bring the unit "Unit-Online." Such units will 12 be treated as and appear to be "Unit-Available" until a host 13 issues an ONLINE command. The ONLINE command will fail, 14 typically with a "Drive Error" status code. At this time either 15 the fact that the unit is inoperative shall be recorded in the 16 unit itself or else AVAILABLE attention messages shall be 17 suppressed for the unit, exactly as if an AVAILABLE command with 18 the "Spin-down" modifier set had been issued for the unit as 19 described later in this section. In either case, AVAILABLE 20 attention messages shall not be generated for that unit by any 21 controller until a human interacts with the unit or some other 22 event occurs that may clear the error, such as a power failure. 23 Controllers and/or drives should keep all units that are 24 "Unit-Offline" due to being inoperative, disabled, or having 25 duplicate unit numbers spun-down, except when such units are 26 under the control of a diagnostic. The handling of units that 27 are in fact inoperative, but that the controller and drive 28 believe to be operative, is described in the preceding paragraph. 29 Controllers may spontaneously release a host's "Exclusive Access" 30 of a unit only if the unit becomes inoperative, disabled, or 31 unknown. 32 For the purpose of automatic configuration (i.e., for the GET 33 UNIT STATUS command with the "Next Unit" modifier) controllers 34 shall acknowledge the existence of all units that are 35 "Unit-Online" or "Unit-Available," or that are in one of the 36 following "Unit-Offline" substates: unit disabled, unit known, 37 under exclusive use of another host, or duplicate unit numbers. 38 Unknown units shall not be acknowledged. Units that are 39 inoperative or online to another controller may or may not be 40 acknowledged at the controller's option. 41 Controllers shall report duplicate unit numbers with a DUPLICATE 42 UNIT NUMBER attention message, then monitor the affected units 43 for the cessation of the duplicate unit number condition. When 44 all units except one have had their unit number changed or have 45 become unknown, the remaining unit becomes "Unit-Available." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-10 Unit States 11 June 1992 1 Controllers shall report units that they know to be online to 2 other controllers with an ACCESS PATH attention message. See 3 Section 4.16.1, "Multiaccess Drives," for more information. 4 The "Unit-Offline" substates are all reported with a single 5 status code; they are partially distinguished via different 6 subcodes. In addition, the substates are distinguished by the 7 functioning of the "Allow Self Destruction" modifier to the 8 ONLINE command, the "Next Unit" modifier to the GET UNIT STATUS 9 command, what unit characteristics are returned by the GET UNIT 10 STATUS, ONLINE, and SET UNIT CHARACTERISTICS commands, and by the 11 DUPLICATE UNIT NUMBER and ACCESS PATH attention messages. 12 Possible causes of a unit being "Unit-Offline," and the resulting 13 "Unit-Offline" substate, include: 14 1. The unit is "Unit-Online" or is under "Exclusive Access" 15 via another controller. The unit is either unknown or 16 else known to be online to another controller, depending 17 upon how recently the other controller has processed a 18 DETERMINE ACCESS PATHS command for this unit or a unit 19 with which it shares an access path. See Sections 20 4.16.1, "Multiaccess Drives" and 4.16.2, "Multiunit 21 Drives and Formatters" for more information. 22 2. A power failure that affects the unit but not the 23 controller. The unit is unknown. 24 3. Hardware failure in the unit or in the connection 25 between the unit and the controller. The unit is either 26 unknown or inoperative. Note that the unit may appear 27 to be "Unit-Available" until an ONLINE command is issued 28 for it, at which time it will be recognized as 29 inoperative. 30 4. Disconnecting the unit from the controller. The unit is 31 unknown. 32 5. Disabling the unit number select mechanism (e.g., 33 removing the unit number select plug). The unit is 34 unknown. 35 6. Duplicate unit numbers. This condition has its own 36 substate. Note that this condition will not affect a 37 unit that is already "Unit-Online" or is under 38 "Exclusive Access." 39 7. Duplicate unit identifiers. The unit is inoperative. 40 Note that the controller need not check for duplicate 41 unit identifiers. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-11 Unit States 11 June 1992 1 8. Disabling the unit with the Run/Stop or Load/Unload 2 switch. The unit is known. 3 9. Disabling the unit with port selection switches. The 4 unit is unknown. 5 10. Removal of the unit from service by operator command, 6 typically for diagnostics, formatting, maintenance or 7 repair. The unit is inoperative. 8 11. An internal controller diagnostic decides the unit is 9 sick and removes it from service. The unit is disabled. 10 12. No volume is present in the drive. The unit is known. 11 13. The unit has not been built yet, the unit is still in 12 its shipping crate, or it has otherwise not been 13 installed yet. The unit is unknown. 14 In general, a unit that is "Unit-Offline" to one host class 15 driver via a specific MSCP server is "Unit-Offline" for the same 16 reason (same substate) to all host class drivers via that same 17 MSCP server. There are two exceptions: 18 1. A duplicate unit number condition that arises while a 19 unit is "Unit-Online" to one or more class drivers. The 20 unit remains "Unit-Online" to those class drivers to 21 which it is already "Unit-Online," yet is "Unit-Offline 22 (substate 'Duplicate Unit')" to all other class drivers. 23 2. A host has been granted "Exclusive Access" of the unit. 24 The state of the unit relative to the host that was 25 granted "Exclusive Access" remains unchanged. The unit 26 is "Unit-Offline (substate 'Exclusive Use')" to all 27 other class drivers. 28 All normal operator initiated transitions to the "Unit-Offline" 29 state shall be smooth, rather than abrupt. Attempts to disable a 30 unit with its Run/Stop or Load/Unload switch and/or attempts to 31 dismount (remove) a volume from a unit are, by definition, 32 "normal operator initiated transitions," and shall therefore be 33 smooth. Any other action that a human operator would typically 34 use to disable a drive in a nonemergency situation shall also be 35 smooth. Note that this does not preclude the existence of some 36 special mechanism for immediately disabling a unit or drive in an 37 emergency, provided that it is not the normal way of disabling a 38 unit or drive. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-12 Unit States 11 June 1992 1 A "smooth" transition to the "Unit-Offline" state implies that 2 all write operations, including multiblock write operations, 3 shall either be completed in their entirety or else rejected 4 (never begun). To accomplish a smooth transition the controller 5 shall complete all write operations (commands) that have already 6 been initiated. Outstanding write operations that haven't been 7 initiated yet may either be completed or rejected. Other 8 outstanding commands, including read operations, may be 9 completed, rejected, or terminated, regardless of whether or not 10 they have been initiated. However, if a Sequential command from 11 a given connection is rejected or terminated, then all 12 subsequently received non-Immediate commands from the same 13 connection shall be rejected. Any new commands issued by a host 14 should be rejected. 15 Note that establishing write protection shall also be a smooth 16 transition. 17 A unit enters the "Unit-Available" state when: 18 1. The unit is "Unit-Offline" and all causes of the unit 19 being "Unit-Offline" are removed. The unit becomes 20 "Unit-Available" with respect to all "Controller-Online" 21 class drivers unless the unit is under the "Exclusive 22 Access" of a host. In that case the unit becomes 23 "Unit-Available" only to the class driver that has 24 "Exclusive Access" of the unit. 25 2. The unit is "Unit-Online" and a host class driver issues 26 an AVAILABLE command for the unit. The unit becomes 27 "Unit-Available" with respect to that class driver. If 28 the "All Class Drivers" modifier was set, the unit also 29 becomes "Unit-Available" with respect to all other class 30 drivers to which it is "Unit-Online" via that MSCP 31 server, unless the "Exclusive Access" modifier was also 32 set. If the "Exclusive Access" modifier was set the 33 unit becomes "Unit-Available" to as well as under the 34 "Exclusive Access" of the issuing class driver and 35 "Unit-Offline (substate 'Exclusive Use')" to all other 36 class drivers. 37 3. The unit is "Unit-Online" or "Unit-Available" to and 38 under the "Exclusive Access" of a host and that host's 39 class driver issues an AVAILABLE, ONLINE, or SET UNIT 40 CHARACTERISTICS command with the "Exclusive Access" 41 modifier clear, thereby releasing "Exclusive Access" of 42 the unit. The state of the unit with respect to the 43 issuing class driver depends on which of those commands 44 was issued as well as the state of the unit prior to the 45 command being issued. (See the descriptions of those *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-13 Unit States 11 June 1992 1 commands in Chapter 7, "Multihost Support" for complete 2 details.) The unit becomes "Unit-Available" to all other 3 class drivers, regardless of the unit state with respect 4 to the issuing class driver. 5 If a class driver has enabled attention messages, the MSCP server 6 uses AVAILABLE attention messages to notify the class driver that 7 a unit has asynchronously become "Unit-Available." If a class 8 driver itself sends the MSCP server an AVAILABLE command, then 9 the transition to "Unit-Available" is synchronous to that class 10 driver and an AVAILABLE attention message need not be sent to it. 11 Other class drivers, however, are notified. 12 The possible causes of an asynchronous transition to 13 "Unit-Available" are as follows: 14 1. Any transition from "Unit-Offline" to "Unit-Available." 15 This specifically includes the following cases: 16 a. The unit was online to another controller and ceases 17 to be online to that other controller. Note that 18 this includes the possibility that the unit was 19 "Unit-Online" to or under the "Exclusive Access" of 20 the same class driver via that other controller. 21 b. The unit was under the "Exclusive Access" of a host 22 and that host has released the "Exclusive Access" of 23 the unit. 24 2. A transition from "Unit-Online" to "Unit-Available," 25 with respect to this class driver, that is caused by 26 some other class driver issuing an AVAILABLE command 27 with the "All Class Drivers" modifier set. 28 3. Any spontaneous transition from "Unit-Online" to 29 "Unit-Available." I.e., any transition from 30 "Unit-Online" to "Unit-Available" that is not caused by 31 an AVAILABLE command. 32 The one exception to this applies to a unit that becomes 33 "Unit-Available" due to an AVAILABLE command that has the 34 "Spin-down" modifier set or as a side effect of certain errors 35 that also spin-down the unit. Such commands or errors indicate 36 that all class drivers are disinterested in the volume mounted on 37 the unit, so that no class driver should be notified of the 38 transition until an operator mounts a new volume or otherwise 39 interacts with the unit. Therefore the request to spin-down the 40 unit suppresses AVAILABLE attention messages for that unit until *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-14 Unit States 11 June 1992 1 an operator interacts with the unit. Note that the messages 2 shall be suppressed for all class drivers, MSCP servers, and 3 controllers that may connect to the unit, regardless of which 4 individual MSCP server and controller actually requested that the 5 unit spin-down. This effectively means that, for multiaccess 6 drives, the fact that AVAILABLE attention messages are suppressed 7 must be recorded in the drive itself, rather than in the 8 controller. 9 AVAILABLE attention messages shall be suppressed at least until 10 an operator interacts with the unit's drive, the unit becomes 11 "Unit-Online" to any class driver via any MSCP server, or the 12 unit's drive loses context. It is not acceptable for the unit's 13 drive to "lose context" solely to forget that AVAILABLE attention 14 messages have been suppressed. Loss of context must be due to 15 some external reason, such as a power failure. The suppression 16 of AVAILABLE attention messages shall be canceled or forgotten if 17 the unit becomes "Unit-Online" to any class driver via any MSCP 18 server or if an operator actuates the unit's Run/Stop or 19 Load/Unload switch, changes the unit number selected by the Unit 20 Number Select Mechanism, or mounts a different volume in the 21 unit. Note that AVAILABLE attention messages are not suppressed 22 (i.e., their suppression is instantly canceled or forgotten) if, 23 after a class driver issues an AVAILABLE command with the 24 "Spin-down" modifier set, the unit is still "Unit-Online" with 25 respect to one or more other class drivers. 26 MSCP servers may send redundant or unnecessary AVAILABLE 27 attention messages at any time, provided that attention messages 28 have been enabled, the messages have not been suppressed as 29 described above, and the extra messages are infrequent enough to 30 avoid causing any significant overhead in either the 31 communications mechanism or a host. It is specifically allowable 32 for an MSCP server to precede every DUPLICATE UNIT NUMBER 33 attention message with an AVAILABLE attention message for the 34 same unit number. 35 A unit enters the "Unit-Online" state with respect to a class 36 driver upon the successful completion of an ONLINE command issued 37 by that class driver. 38 4.4 Unit Numbers 39 As described in Section 4.2, "Controls and Indicators," all disk 40 and tape drives accessible via MSCP must have a user visible and 41 Field Service alterable unit number. The characters displayed as 42 the unit number, interpreted as a decimal number, shall match the 43 binary value passed in the "unit number" field of MSCP control 44 messages. Multiunit drives and formatters may use a single unit 45 number select mechanism and display for the range of consecutive *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-15 Unit Numbers 11 June 1992 1 unit numbers assigned to their units. 2 MSCP supports unit numbers in the range 0 through 65535. All 3 controllers and units shall support unit numbers in the range 0 4 through 251. Unit numbers between 252 and 65535 may be supported 5 or not at the controller's and/or unit's option. This implies 6 that all units accessible via MSCP shall have a unit number 7 select mechanism capable of specifying and a unit number display 8 mechanism capable of displaying any unit number in the range 0 9 through 251. Controllers shall treat unsupported unit numbers as 10 if the specified unit is "Unit-Offline" due to being unknown (see 11 Section 4.3, "Unit States"). 12 The intent of this broad range of unit numbers is that, within a 13 device class, all units that are accessible to a single host have 14 unique unit numbers. In pursuit of this goal units with 15 duplicate unit numbers are considered to be "Unit-Offline." 16 However, this must be balanced against another goal, namely that 17 transient actions performed on another unit should not be allowed 18 to affect continued host access to a unit that is already 19 "Unit-Online" or under "Exclusive Access." Controllers shall 20 balance these two goals with the following algorithms: 21 1. Controllers detect and respond to duplicate unit numbers 22 across all units that are "Unit-Online," that are 23 "Unit-Available," or that are in one of the following 24 "Unit-Offline" substates: unit disabled, unit known, 25 under exclusive use of another host, duplicate unit 26 numbers, or online to another controller. Units that 27 are "Unit-Offline" due to being unknown shall not be 28 considered for duplicate unit number detection. 29 Controllers may or may not, at the controller's option, 30 consider units that are inoperative. Detection of a 31 duplicate unit number condition on one unit of a 32 multiunit drive is treated as a duplicate unit number 33 condition on all other units that share one or more of 34 the following components with the unit having the 35 duplicate unit number: 36 a. A unit number select mechanism. 37 b. A Run/Stop or Load/Unload switch. 38 c. A spindle or other mechanical components. 39 2. Discovery of a duplicate unit number condition does not 40 affect any unit that is already "Unit-Online" or under 41 "Exclusive Access." The state of such a unit remains 42 unchanged until some other event (such as an AVAILABLE *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-16 Unit Numbers 11 June 1992 1 command or loss of controller context) occurs that would 2 otherwise cause it to become "Unit-Available" to all 3 hosts, at which time the unit becomes "Unit-Offline" and 4 is spun-down as described below. Note that in the 5 already "Unit-Online" case the unit becomes 6 "Unit-Offline" to all other hosts (and therefore cannot 7 be brought "Unit-Online" by them) even while it remains 8 "Unit-Online" to its current hosts. 9 3. When a controller becomes aware of a duplicate unit 10 number condition on two or more units connected to it, 11 it immediately spins-down all such units that are 12 "Unit-Available" or "Unit-Offline" with respect to all 13 hosts. When a unit that was "Unit-Online" or under 14 "Exclusive Access" with a duplicate unit number 15 condition becomes "Unit-Available" to all hosts for any 16 reason, the controller immediately spins it down. In 17 both cases, units that belong to a multiunit drive and 18 share a spindle or other mechanical components are to be 19 spun down only if all of the units of the drive are 20 either "Unit-Offline" or "Unit-Available" to all hosts. 21 4. The controller reports "Unit-Offline" due to having a 22 duplicate unit number as the state for all units with 23 duplicate unit number conditions that are not already 24 "Unit-Online" or under "Exclusive Access." Other causes 25 of the units being "Unit-Offline" may or may not be 26 reported at the controller's option. 27 5. The controller recognizes when a duplicate unit number 28 condition goes away. That is, the controller recognizes 29 when all units except one with the same duplicate unit 30 number have their unit numbers changed and/or become 31 unknown. When this occurs, the controller sends 32 AVAILABLE attention messages for the remaining unit if 33 there is no other reason for it being "Unit-Offline," 34 since it has just become "Unit-Available." 35 In addition to the above algorithms, controllers report duplicate 36 unit number conditions to class drivers using the DUPLICATE UNIT 37 NUMBER attention message. This allows hosts to complain to a 38 human operator, who will presumably remedy the condition. This 39 message is sent to all "Controller-Online" class drivers that 40 have attention messages enabled when a duplicate unit number 41 condition is first detected. It is permissible for a controller 42 to send redundant or extra DUPLICATE UNIT NUMBER attention 43 messages, provided that the reported duplicate unit number 44 condition actually exists. See Section 5.8.3, "Duplicate Unit 45 Number Attention Message," for more details. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-17 Unit Numbers 11 June 1992 1 The above algorithms effectively enforce nonduplicate unit 2 numbers across the drives connected to the same controller. 3 Although not required by MSCP, it is recommended that class 4 drivers use the following algorithm to enforce nonduplicate unit 5 numbers across the drives accessible to that class driver: 6 1. Upon becoming aware of a unit (i.e., upon receiving an 7 AVAILABLE attention message), the class driver should 8 check if it is already aware of a unit with the same 9 unit number on a different MSCP server. If it is not 10 aware of such a unit, it should exit. If it is aware of 11 such a unit, it should check if that unit has the same 12 unit identifier. 13 2. If the unit identifiers are the same, it is the same 14 unit multiaccessed to several controllers, so exit. If 15 the unit identifiers are different, the class driver 16 should issue a GET UNIT STATUS command to see if the old 17 unit still exists. 18 3. If the old unit no longer exists (i.e., it's 19 "Unit-Offline"), exit. If the old unit still exists, 20 the class driver should check that the unit identifier 21 returned by GET UNIT STATUS is also different from the 22 unit identifier that was in the AVAILABLE attention 23 message. If the unit identifiers are the same, exit. 24 If the unit identifiers are different, the class driver 25 should issue an AVAILABLE command with the "Spin-down" 26 modifier set for the new unit. The class driver should 27 also issue an AVAILABLE command with the "Spin-down" 28 modifier set for the old unit if the class driver is not 29 already "Unit-Online" to that unit. 30 4. Whenever a class driver brings an MSCP server 31 "Controller-Online," the class driver should issue, 32 through that MSCP server, AVAILABLE commands with the 33 "Spin-down" modifier set for all units that it has 34 "Unit-Online" via another MSCP server. 35 5. Whenever a class driver brings a unit "Unit-Online," the 36 class driver should issue ONLINE commands for that same 37 unit number to all MSCP servers. If more than one 38 ONLINE command succeeds, the class driver should check 39 that the unit identifiers returned by all the successful 40 ONLINE commands are the same. If any of the unit 41 identifiers are different, then the class driver should 42 treat all the ONLINE commands as having failed and issue 43 AVAILABLE commands with the "Spin-down" modifier set to 44 all MSCP servers on which the ONLINE command succeeded. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-18 Unit Numbers 11 June 1992 1 Note that this algorithm uses the fact that an AVAILABLE command 2 with the "Spin-down" modifier set suppresses AVAILABLE attention 3 messages until a human operator interacts with the unit. 4 4.5 Command Categories And Execution Order 5 MSCP commands fall into one of four command categories. Each 6 category has a set of execution order restrictions that MSCP 7 servers must satisfy. The four categories and their restrictions 8 are described below. 9 Immediate commands are those commands, such as status inquiries, 10 that both require very little time to complete and do not cause 11 any unit context changes. MSCP servers shall process Immediate 12 commands immediately, without waiting for any other commands to 13 complete. MSCP servers shall guarantee that all outstanding 14 Immediate commands plus an additional GET COMMAND STATUS command 15 issued by each "Controller-Online" class driver will complete 16 within the controller timeout interval. 17 A class driver may issue Immediate commands whenever its credit 18 balance is greater than zero, whereas all other commands may only 19 be issued when the class driver's credit balance is two or 20 larger. This is discussed further in Chapter 3, "Class Driver / 21 MSCP Server Communications." Class drivers are thus guaranteed 22 to be able to issue at least one Immediate command, and have it 23 executed, regardless of what other commands they may have 24 outstanding. In particular, the class driver is guaranteed to be 25 able to issue a GET COMMAND STATUS command and have it complete 26 within the controller timeout interval. 27 Sequential commands are those commands that, for the same unit, 28 shall be executed in precise order. Sequential commands 29 typically alter a unit's context, such as by changing a unit 30 characteristic or by altering the position of a tape drive. All 31 Sequential commands for a particular unit shall be executed in 32 the exact order that the MSCP server receives them. The 33 execution of a Sequential command may not be interleaved with the 34 execution of any other Sequential or Non-Sequential commands for 35 the same unit. Furthermore, any Non-Sequential commands received 36 before a particular Sequential command shall be completed before 37 execution of that Sequential command begins, and any 38 Non-Sequential commands received after a particular Sequential 39 command shall not begin execution until after that Sequential 40 command is completed. Sequential commands are, in effect, a 41 barrier that Non-Sequential commands may not pass or penetrate. 42 Note that Sequential command execution is performed on a unit 43 basis rather than a single connection basis. Controllers that 44 provide Multihost Support shall therefore enforce the Sequential 45 command execution guarantees across all "Controller-Online" *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-19 Command Categories And Execution Order 11 June 1992 1 connections. 2 Non-Sequential commands are those commands that controllers may 3 reorder so as to optimize performance. Controllers may 4 furthermore interleave the execution of several Non-Sequential 5 commands among themselves, performing each command a fragment at 6 a time. The only restrictions are: 7 1. Execution of a Non-Sequential command shall not cross 8 the barrier created by a Sequential command for the same 9 unit. 10 2. The controller shall complete useful work on its oldest 11 outstanding command on each "Controller-Online" 12 connection within the controller timeout interval, so as 13 not to cause a command timeout. See Section 4.10, 14 "Command Timeouts." 15 Note that controller performance optimization of Non-Sequential 16 commands, although not a strict requirement of MSCP, is highly 17 recommended. The optimization algorithms used are controller 18 implementation dependent and will undoubtedly differ from 19 controller to controller. Controllers that provide Multihost 20 Support are expressly permitted to include all Non-Sequential 21 commands received from all "Controller-Online" class drivers, 22 directed to the same unit, in the optimization (algorithm) being 23 performed on the unit. One consequence of such optimization that 24 must be noted is that if more than one data transfer request with 25 the same target received from different class drivers 26 (connections) are outstanding at the same time, the ordering of 27 the data written/read will be indeterminate. 28 Special commands are similar to Non-Sequential commands, but have 29 additional, unique execution order requirements. The execution 30 order requirements for Special commands are described in the 31 commands' description. 32 Note that tape class devices only have Immediate and Sequential 33 commands. There is no such thing as a Non-Sequential or Special 34 tape class command. 35 Execution order is based on the order in which commands are 36 received by the controller's MSCP server. For commands sent by a 37 single class driver, the order of transmission is identical to 38 the order of reception. For commands sent by several class 39 drivers, the order of reception is essentially random. The only 40 way that a class driver can ensure that one of its commands will 41 be received after some other command issued by another class 42 driver is to wait until the other class driver receives the first *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-20 Command Categories And Execution Order 11 June 1992 1 command's end message (i.e., wait until the first command 2 completes) before sending the command. 3 For the purpose of determining execution order, a command is 4 completed when the controller's MSCP server queues the command's 5 end message for transmission to the host. The controller need 6 not wait until the host has confirmed its receipt, although 7 sequential message delivery guarantees must be preserved. The 8 gist of this is that after termination of the connection between 9 a host class driver and an MSCP server, the absence of a 10 Sequential command's end message implies nothing about the 11 execution or nonexecution of the Sequential command. 12 When an MSCP server finishes processing or executing a command, 13 the command can finish in any of four ways. Based on which way 14 the server finishes a command, the command is said to have been 15 completed, rejected, terminated, or aborted. 16 A completed command is a command that the server has fully 17 executed to its normal conclusion. A command that is completed 18 has either succeeded or encountered an unrecoverable error. In 19 normal operation all commands are completed. 20 A rejected command is a command for which the server never even 21 starts processing. Some commands are rejected due to termination 22 of the connection between the MSCP server and the class driver. 23 Such commands are discarded by the MSCP server, port driver, or 24 communications mechanism before any work is done on them. Other 25 commands are rejected due to being illegal commands or due to a 26 unit being in an illegal state. For example, transfer commands 27 are rejected if the specified unit is not "Unit-Online." 28 A terminated command is a command for which the server begins 29 processing, but then terminates processing part way through 30 command execution. Transfer commands are terminated if their 31 unit is disconnected (cable breaks or drive loses power) part way 32 through the transfer. Transfer commands may also be terminated 33 if the connection between the MSCP server and the class driver is 34 terminated part way through the transfer. Generally only 35 Non-Sequential commands can be terminated. Termination of 36 Sequential commands is discussed below. 37 An aborted command is a command that the class driver has asked 38 to have aborted via an ABORT command, and that furthermore has 39 been located and explicitly aborted by the MSCP server. That is, 40 commands that the MSCP server just allows to complete are 41 completed, not aborted. An aborted command is effectively either 42 rejected or terminated, depending upon whether or not the server 43 has begun execution of the command when it processes the ABORT. 44 (This definition of an aborted command is from the viewpoint of *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-21 Command Categories And Execution Order 11 June 1992 1 an MSCP server. From the viewpoint of a class driver, an aborted 2 command is any command for which an ABORT command has been 3 issued.) The end message of an aborted command shall be returned 4 within one controller timeout interval following rejection or 5 termination of the command regardless of the aborted command's 6 command category. 7 Immediate commands are always completed if the connection between 8 MSCP server and class driver remains intact; they may not be 9 rejected, terminated, or aborted. If the connection is 10 terminated before an Immediate command can be completed, then the 11 command may be completed, rejected, or terminated. Since 12 Immediate commands do not change the state, context, or data of 13 the unit, these three command completion modes are equivalent if 14 the connection has been terminated. 15 Non-Sequential commands may, in general, be completed, rejected, 16 terminated, or aborted. This is true both if the connection 17 remains intact or if it is terminated. However, there is one 18 restriction regarding write operations. Write operations shall 19 not be terminated as a result of any normal operator interactions 20 with the unit. That is, write operations shall not be terminated 21 (partially completed) as a result of an operator attempting to 22 spin-down, dismount, or write protect the unit. The purpose of 23 this restriction is to prevent data corruption due to partial 24 updates. This is further discussed under the term "smooth" 25 transitions in Section 4.3, "Unit States," and Section 4.14, 26 "Write Protection." 27 Sequential commands may be completed or rejected, but in general 28 may not be terminated. If a Sequential command is aborted, it 29 shall be aborted before it begins execution (rejected) rather 30 than in the middle of execution (terminated). The reason for 31 this is that Sequential commands appear to hosts as atomic 32 (indivisible) operations. Thus, there is both this requirement, 33 that Sequential commands cannot be terminated, therefore 34 preventing subsequent commands from acting on partially updated 35 unit state and context, and the requirement that execution of a 36 Sequential command cannot be interleaved with any other command 37 on the same unit, therefore preventing a concurrent command from 38 acting on partially updated unit state and context. 39 There are two exceptions to the requirement that a Sequential 40 command may not be terminated. The first is that a server may 41 terminate a Sequential command in the middle of execution, 42 provided that the termination process undoes all unit state and 43 context changes that have been made on the unit. From the 44 viewpoint of the class driver, this case is exactly equivalent to 45 the command having been rejected. The second exception is that 46 the controller and/or unit loses context, generally due to a *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-22 Command Categories And Execution Order 11 June 1992 1 power failure or similar event. Since the unit's state and 2 context will be completely reset when power and/or normal 3 operation are restored, the fact that it was left in some 4 indeterminate state does not matter. Note that if the controller 5 loses context, it must lose context for all connections to the 6 affected unit's device class (implying that all such connections 7 have been terminated), as otherwise some other class driver may 8 see the unit in an indeterminate state. 9 Note that any command that fails due to an unrecoverable device 10 or data error is a completed command. Commands are rejected, 11 terminated, or aborted only in response to inappropriate unit 12 state or context, connection termination, and being aborted via 13 ABORT commands. 14 Commands that are rejected, terminated, or aborted shall still 15 return their proper end message format with valid parameters as 16 defined in the individual command descriptions. The only case 17 where a different end message format may be returned is if the 18 command is rejected as a protocol error type "Invalid Command." 19 A special end message format and end message opcode is used for 20 that purpose. See "Invalid Command" status in Section 5.5, 21 "Status Codes" for more detail. 22 4.6 Class Driver / MSCP Server Synchronization 23 Synchronization of a class driver with an MSCP server is 24 accomplished by establishing or re-establishing the connection 25 between the class driver and the MSCP server. When the 26 connection is established or re-established, the MSCP server 27 terminates all commands that are outstanding from that class 28 driver. This forces the dialogue between the class driver and 29 MSCP server to a known, synchronized state: that of having no 30 outstanding commands. After establishing the connection the 31 class driver can issue commands without worrying about 32 duplicating command reference numbers or other unfortunate side 33 effects. Note that synchronizing with the MSCP server, if 34 successful, causes the MSCP server to become 35 "Controller-Online." 36 As stated above, the main purpose of synchronization is to 37 guarantee that there are no outstanding commands, thus forcing 38 the dialogue between the class driver and MSCP server to a known 39 state. MSCP servers shall ensure that this guarantee is met 40 before they allow synchronization to complete (i.e., before they 41 become "Controller-Online"). In particular, MSCP servers shall 42 guarantee that no end messages will be sent and that no units 43 will have their state, context, or (data) contents changed for 44 any commands that were issued on an earlier incarnation of the 45 connection between the class driver and MSCP server. Note that *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-23 Class Driver / MSCP Server Synchronization 11 June 1992 1 an MSCP server may allow outstanding commands to complete, either 2 partially or entirely, but if it does it must delay the 3 completion of synchronization (delay the transition to 4 "Controller-Online") until all such commands have completed or 5 terminated. 6 Class drivers shall synchronize with the MSCP server whenever the 7 host boots, recovers from a power failure, loses context, or is 8 recovering from certain errors. After synchronizing with an MSCP 9 server, the class driver should do the following: 10 1. Issue a SET CONTROLLER CHARACTERISTICS command to 11 establish host-settable controller characteristics and 12 obtain non-host-settable controller characteristics. 13 2. Issue ONLINE commands for all units that the class 14 driver wishes to be "Unit-Online." 15 3. Reissue all commands, if any, that were outstanding 16 before the class driver synchronized with the MSCP 17 server in the exact order that they were originally 18 issued. However, any commands that have been aborted 19 (i.e., for which an ABORT command has been issued) shall 20 not be reissued. Instead the class driver should assume 21 that the command has been successfully aborted and is 22 therefore no longer outstanding. 23 There is one exception to reissuing all commands that were 24 outstanding. The class driver shall maintain a retry limit 25 count, to ensure that its oldest outstanding command won't be 26 retried infinitely many times. The magnitude of this limit is 27 host dependent, although the oldest command shall be retried at 28 least once. When the class driver's oldest outstanding command 29 exceeds the retry limit count, an error shall be returned rather 30 than retrying the command again. All other outstanding commands, 31 however, should still be retried. See Section 4.10, "Command 32 Timeouts," for more information. 33 It may be possible that a class driver will receive messages from 34 an MSCP server after the class driver has initiated 35 synchronization with the MSCP server but before the 36 synchronization completes. Whether or not this is in fact 37 possible is communications mechanism dependent, as it depends 38 upon the detailed design of the communications mechanism and port 39 driver. Any attention messages that the class driver receives 40 during this interval should be discarded. Any error log messages 41 should be logged in the normal fashion. Any end messages that 42 the class driver receives during this interval may be either 43 handled normally (thus completing the corresponding command) or 44 else discarded. If the class driver discards one end message, it *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-24 Class Driver / MSCP Server Synchronization 11 June 1992 1 shall discard all subsequent end messages until the 2 synchronization completes. It is recommended, although not 3 required, that class drivers handle all such end messages 4 normally. 5 4.7 Class Driver Error Recovery 6 The principal method of error recovery used by class drivers is 7 to resynchronize with the MSCP server, as described in Section 8 4.6, "Class Driver / MSCP Server Synchronization." All 9 communications mechanism failures and many controller failures 10 are reported by terminating the connection between the class 11 driver and MSCP server, in response to which the class driver 12 should attempt to resynchronize with the MSCP server. If the 13 class driver decides that the controller is insane, either 14 because the class driver received an invalid message or because a 15 command timed out, it should recover by resynchronizing with the 16 MSCP server. Similarly, if the MSCP server decides that the 17 class driver is insane, it may terminate the connection to the 18 class driver. If the class driver is in fact actually sane, it 19 will resynchronize with the MSCP server after the port driver 20 notifies it that the connection has been terminated. 21 Aside from resynchronization as described in the preceding 22 paragraph, class drivers need perform very little error recovery, 23 since controllers handle all recoverable errors. The only 24 exceptions to this guideline are as follows: 25 1. Errors on multiaccess drives should be retried using 26 another controller. 27 2. Commands that fail due to the unit being 28 "Unit-Available" should typically be reissued after 29 bringing the unit "Unit-Online." 30 3. High availability systems may wish to perform the 31 enhanced error recovery described below. 32 High availability systems may wish to use the following 33 additional error recovery strategy in order to minimize the 34 impact of certain types of controller problems. Rather than 35 reissuing outstanding commands all at once after resynchronizing 36 with a controller, such a system should instead reissue the 37 oldest outstanding command all by itself. The host class driver 38 should reissue all other outstanding commands only after the 39 oldest command completes. The other outstanding commands may be 40 reissued either all at once (recommended) or one at a time. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-25 Class Driver Error Recovery 11 June 1992 1 If the oldest command times out or otherwise fails again after 2 being reissued, then it was presumably the source of the problem 3 and normal operation will resume. If the oldest command 4 succeeds, then the problem is most likely due to some race 5 condition within the controller and will not recur. If the 6 problem does recur, then successive iterations of this algorithm 7 will execute commands one at a time until the offending command 8 is found and discarded. 9 4.8 Serious Exceptions 10 A serious exception is an unrecoverable error or some other 11 unusual condition that requires host acknowledgment before 12 additional commands are processed. Serious exceptions occur only 13 on tape class devices. See Tape Mass Storage Control Protocol 14 Specification (TMSCP) for complete details. 15 4.9 Host Access Timeouts 16 MSCP servers provide host access timeouts to guarantee that 17 multiaccess drives (described in Section 4.16.1, "Multiaccess 18 Drives") will be accessible in spite of certain communications 19 mechanism failures. If the communications path between hosts and 20 a controller fails when one or more drives are "Unit-Online" or 21 under "Exclusive Access" via that controller, the drives would 22 normally become inaccessible. The drives can't be accessed via 23 the controller through which they are "Unit-Online" or under 24 "Exclusive Access," since that controller can't be accessed, and 25 they can't be accessed via a second controller, since they are 26 already accessed through the first controller. The host access 27 timeout, if enabled, eliminates this problem by causing the first 28 controller to automatically release all drives if it doesn't 29 receive a command within a specified time interval. 30 The exact mechanism used for host access timeouts is to have the 31 controller's MSCP server become "Controller-Available" relative 32 to any host class driver whose host access timeout expires. The 33 MSCP server automatically resets the timeout whenever it receives 34 a command from the class driver or has a command outstanding from 35 that class driver. Therefore the timeout will never expire if 36 the class driver maintains a reasonably constant dialog with the 37 MSCP server. Note that implementing host access timeouts on a 38 per host basis has the benefit that the MSCP server will 39 automatically release any resources allocated to a host if that 40 host goes down. 41 If communication with all hosts ceases, the host access timeout 42 of each class driver will ultimately expire, causing the MSCP 43 server to become "Controller-Available" relative to all hosts. 44 Each unit will be released, allowing it to be accessed via an *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-26 Host Access Timeouts 11 June 1992 1 alternate controller, as soon as all class drivers that are 2 "Unit-Online" or under "Exclusive Access" with respect to the 3 unit (or any other unit that shares its access path) cease to be 4 "Unit-Online" or under "Exclusive Access" by virtue of becoming 5 "Controller-Available." Ultimately all class drivers will become 6 "Controller-Available," thus releasing all units. 7 Class drivers specify the time interval that an MSCP server will 8 use for the host access timeout in the SET CONTROLLER 9 CHARACTERISTICS command. A host access timeout value of zero 10 specifies that host access timeouts should be disabled. A 11 default host access timeout of 60 seconds is used from the time a 12 class driver becomes "Controller-Online" until it issues its 13 first SET CONTROLLER CHARACTERISTICS command. 14 Each class driver may specify a separate time interval. This 15 allows class drivers to vary the host access timeout interval in 16 accordance with host policy and availability requirements. High 17 availability systems should typically use a fairly short host 18 access timeout, on the order of 10 to 30 seconds, together with a 19 background process that verifies the continued availability of 20 the host to controller communications path. The background 21 process would have the desirable side effect of ensuring that the 22 host access timeout never expired. Normal systems should use a 23 larger timeout, on the order of 1 to 5 minutes, to avoid 24 excessive resynchronizations, yet still allow failure recovery. 25 Single user and other specialized systems may disable host access 26 timeouts. Note that host access timeouts should typically be 27 enabled even on systems that do not seem to require them, as 28 drives may be multiaccessed to a totally separate host used as a 29 backup system. 30 MSCP servers shall implement host access timeouts subject to the 31 following constraints: 32 1. The host access timeout expires, for a particular class 33 driver, at the amount of the host access timeout 34 interval after the controller or MSCP server completes 35 all outstanding commands from that class driver, 36 provided that no new commands are received from that 37 class driver during this interval. 38 2. The MSCP server shall enter the "Controller-Available" 39 state (as a result of host access timeout expiration) 40 relative to a class driver no sooner than the moment of 41 host access timeout expiration defined in item 1 above. 42 3. The MSCP server should enter the "Controller-Available" 43 state (as a result of host access timeout expiration) as 44 soon as possible after the moment of host access timeout *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-27 Host Access Timeouts 11 June 1992 1 expiration defined in item 1 above. Except when the 2 controller is saturated with work for other class 3 drivers, this shall be no later than one second plus the 4 amount of the host access timeout interval after the 5 moment of host access timeout expiration. 6 In other words, the host access timeout is measured from the time 7 that the last command is completed. The MSCP server may defer 8 recognition of host access timeout expiration for up to one 9 second plus the amount of the host access timeout after the 10 formal expiration of the timeout. That is, the host access 11 timeout shall be implemented with an accuracy range of -0% 12 through +100%+1 second. Furthermore, this accuracy range may be 13 extended on the high side if the controller is saturated with 14 work for other class drivers. 15 This definition of host access timeouts has been structured to 16 allow at least two alternative implementations. In the first 17 implementation, the controller or MSCP server starts a timer when 18 it goes "idle" -- that is, when it completes the last outstanding 19 command. The duration of the timer is the host access timeout 20 interval. The timer is designed to not err on the low side (too 21 short an interval) and to err by no more than a factor of two on 22 the high side (too long an interval). If the timer expires 23 before the MSCP server receives another command, declare a host 24 access timeout and become "Controller-Available." The second 25 implementation uses a continuously running timer that "ticks" at 26 the host access timeout interval. If there is no outstanding 27 command and the timer "ticks" twice in succession without the 28 MSCP server having received a command from the host, then declare 29 a host access timeout and become "Controller-Available." 30 Each controller or MSCP server has a minimum and a maximum host 31 access timeout interval that it implements. If a class driver 32 specifies a host access timeout interval that is less than the 33 minimum, then the MSCP server uses its minimum. If a class 34 driver specifies a host access timeout interval that is greater 35 than the controller's maximum, then the controller uses its 36 maximum. A controller's or MSCP server's minimum host access 37 timeout interval shall be 10 seconds or less. A controller's or 38 MSCP server's maximum host access timeout interval shall be at 39 least 255 seconds. That is, all controllers shall fully 40 implement host access timeout intervals in the range 10 through 41 255 seconds. Support of intervals outside this range is 42 controller dependent. The range of host access timeout intervals 43 that a controller supports shall be described in the controller's 44 Functional Specification; it cannot be obtained via MSCP. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-28 Host Access Timeouts 11 June 1992 1 Note that all controllers and MSCP servers shall also implement 2 the host access timeout value zero, which disables host access 3 timeouts. 4 4.10 Command Timeouts 5 Host class drivers use command timeouts to guarantee that all 6 controller or communications mechanism failures will be detected. 7 The failures detected by command timeouts include partially sane 8 or deadlocked controllers, which may continue to process new 9 commands even though one or more old commands have been lost and 10 will never complete. The use of command timeouts centers around 11 the GET COMMAND STATUS command. Indeed, the primary purpose of 12 the GET COMMAND STATUS command is for command timeouts. 13 A controller is sane if and only if it will ultimately complete 14 all commands submitted to it. For practical purposes, the term 15 "ultimately" must be replaced with the phrase "within reasonable 16 time." What constitutes a "reasonable time" varies with the 17 complexity of the command and the performance of the controller 18 and drives. We can eliminate the difficulty of the host class 19 driver having to derive this "reasonable time" by restating the 20 definition of a sane controller as follows: A controller is sane 21 if and only if it will always complete useful work on its oldest 22 outstanding request within reasonable time. This definition lets 23 us set the "reasonable time" to some fixed value, and vary the 24 units in which we measure "useful work" according to the 25 complexity of the command. Command timeouts are based on this 26 second definition. 27 A class driver implements the command timeout mechanism as 28 follows. For each MSCP server to which it is 29 "Controller-Online," the class driver keeps track of which 30 command is its oldest outstanding command plus the previous 31 "command status" value for its oldest outstanding command. The 32 previous "command status" value should be set to all ones 33 whenever the oldest command completes and a new command becomes 34 the oldest. The class driver should issue GET COMMAND STATUS 35 commands for its oldest outstanding command at intervals of the 36 controller timeout interval or longer. When each GET COMMAND 37 STATUS command completes, the class driver checks if the command 38 for which it was issued is still outstanding and, if it is, 39 verifies that the "command status" returned by the GET COMMAND 40 STATUS command is lower than the previous "command status." This 41 value measures the amount of work remaining before completion of 42 the command. If the value ever increases or stays the same, or 43 if a GET COMMAND STATUS command ever takes longer than the 44 controller timeout interval to complete, then the class driver 45 should assume that the controller has failed and resynchronize 46 with the controller. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-29 Command Timeouts 11 June 1992 1 In addition to guaranteeing that they will complete useful work 2 on their oldest outstanding command, controllers shall also 3 guarantee that they will complete all aborted commands within the 4 controller timeout interval. That is, an aborted command's end 5 message shall be sent no later than the amount of the controller 6 timeout interval after the ABORT command's end message. Host 7 class drivers can check this by setting the previous "command 8 status" value to one whenever the oldest outstanding command has 9 been aborted (i.e., when the class driver receives the ABORT 10 command's end message indicating that its oldest outstanding 11 command has been aborted). 12 Single host controllers (i.e., controllers that do not provide 13 Multihost Support) need not guarantee that all aborted commands 14 will complete within the controller timeout interval if 15 excessively pathological situations arise (e.g., compound or 16 multiple errors, causing error recovery sequences to stretch out 17 to unrealistic lengths). 18 If the command timeout for an aborted command expires due to such 19 a situation, the class driver will resynchronize with the MSCP 20 server and reissue all outstanding commands except for those that 21 had been aborted. Since the aborted commands will not be 22 reissued, the timeout will not recur. Thus this exception is 23 transparent to host class drivers. 24 The above algorithm applies to non-Immediate commands. With one 25 exception the same algorithm may also be used for Immediate 26 commands, although a simpler one (using the fact that all 27 Immediate commands complete within the controller timeout 28 interval) is also appropriate. The one exception is the GET 29 COMMAND STATUS command used by the timeout algorithm itself. 30 This command shall be timed out as follows. If the class 31 driver's credit balance is zero when it attempts to issue the GET 32 COMMAND STATUS command, it shall queue the GET COMMAND STATUS 33 command for immediate transmission (before any other commands 34 that may be outstanding) when its credit balance becomes nonzero. 35 If the controller timeout interval expires again before the GET 36 COMMAND STATUS command has both been transmitted and completed, 37 then the class driver should assume that the controller has 38 failed. Note that the class driver's credit balance is 39 guaranteed to be nonzero when all outstanding Immediate commands 40 have completed. Note also that controllers or MSCP servers 41 guarantee that all outstanding Immediate commands plus one 42 additional GET COMMAND STATUS command will complete within the 43 controller timeout interval. 44 Upon concluding that a controller has failed, the class driver 45 shall resynchronize with the controller's MSCP server and reissue 46 all commands (except commands that it has tried to abort) that *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-30 Command Timeouts 11 June 1992 1 were outstanding to that MSCP server in the same order that they 2 were originally issued. In particular, the oldest outstanding 3 command (the one that timed out) shall be issued first (after 4 initial SET CONTROLLER CHARACTERISTICS and ONLINE commands). The 5 only exception to this is if the command's retry count expires. 6 The class driver should maintain a retry count of the number of 7 times the oldest command has timed out and been retried. If the 8 retry count exceeds a host dependent retry limit, the class 9 driver should return an error rather than retrying the command 10 again. The size of the retry limit is determined by host policy, 11 except that all commands shall be retried at least once. Note 12 that subcode zero of the "Controller Error" status code has been 13 reserved for commands that exceed their retry count. This 14 subcode shall never be generated by MSCP servers; it is generated 15 by class drivers or non-MSCP entities (e.g., a controller's port 16 driver) as a standard means of reporting command timeout errors. 17 In order to implement command timeouts, the host class driver 18 shall first obtain the controller timeout interval via the SET 19 CONTROLLER CHARACTERISTICS command. Therefore the class driver 20 should issue a SET CONTROLLER CHARACTERISTICS command as the 21 first command after becoming "Controller-Online." The class 22 driver should use a controller timeout interval of 10 seconds for 23 this initial command. The class driver shall never use a time 24 interval that is shorter than the controller specified controller 25 timeout interval for its command timeout determination, although 26 the class driver may use a time interval that is longer than the 27 one specified by the controller. The controller timeout interval 28 specified by the controller shall not be larger than 4 minutes 29 and 15 seconds (255 seconds). 30 One characteristic of this command timeout algorithm that MSCP 31 servers need not implement, and indeed most will not implement, 32 is the GET COMMAND STATUS command for any command that the MSCP 33 server can guarantee will complete within the controller timeout 34 interval. The GET COMMAND STATUS command should always return 35 the value zero as the "command status" of such a command. It is 36 acceptable if, due to vagaries of controller optimization 37 algorithms, such a command will occasionally timeout. This is 38 acceptable, so long as the frequency of such timeouts is 39 extremely small and the controller immediately begins processing 40 the first command it receives after resynchronization. Since the 41 class driver reissues commands in the same order that they were 42 originally issued, the oldest or timed out command is reissued 43 first, effectively guaranteeing that it will not be delayed again 44 by the controller's optimization algorithms. (The simplest way 45 for most controllers to implement this is to treat the first 46 Non-Sequential command received across a newly established 47 connection as if the Express Request modifier were set. See 48 Section 5.3.2, "Command Modifiers" for a description of the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-31 Command Timeouts 11 June 1992 1 affects of that modifier.) 2 4.11 Host Buffer Access 3 The block data communications service (see Section 3.1, 4 "Connection") transfers the contents of one named buffer to 5 another. Hosts describe buffers (name and size) with a buffer 6 descriptor and byte count in the command message of a transfer 7 command. 8 In a read operation, the host provides a buffer to receive the 9 data. To the host, that buffer (the portion of host memory 10 described by the buffer descriptor and specified byte count) is 11 exactly equivalent to an undefined field in an MSCP control 12 message from the time that the class driver issues the READ 13 command to its port driver to the time that it receives the end 14 message for that READ command from its port driver. That is, the 15 contents are controller implementation dependent and cannot be 16 used in any meaningful way by the class driver. The class driver 17 shall ignore the contents of the buffer and may not alter the 18 contents in any way. The server may alter the contents of that 19 memory in any way it chooses during that time. 20 Note that this holds true regardless of any sequencing rules 21 imposed by command categories on execution order. For example, 22 the host queues an ONLINE command followed by a READ command. 23 The contents of the READ buffer are undefined from the moment the 24 READ command is queued, despite the ONLINE command being a 25 Sequential command. The contents of the buffer remain undefined 26 until the end message for the READ command is received by the 27 class driver, even before receipt of the ONLINE end message and 28 regardless of the success or failure of the ONLINE command. 29 Note also that once the end message has been received by the 30 class driver, only that portion of the buffer described by the 31 "byte count" in the end message is defined as containing data 32 from the unit. The contents of the remainder of the buffer are 33 undefined. 34 In a write type operation, the host loads the data to be written 35 into a buffer in host memory. The server shall not access that 36 buffer before the server receives the command message or after 37 the server queues the end message for transmission to the host. 38 4.12 Disk Geometry And Format 39 The host accessible portion of a disk unit consists of a vector 40 of fixed length blocks, called logical blocks. Logical blocks 41 are identified by logical block numbers (LBNs) which range from *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-32 Disk Geometry And Format 11 June 1992 1 zero through N-1, where "N" is the total number of logical blocks 2 on the unit. The logical blocks on a unit are divided into two 3 mutually exclusive regions: 4 1. The host area consists of those logical blocks available 5 for host data storage. Logical blocks in the host area 6 have LBNs in the range zero through US-1, where "US" is 7 the "unit size," or number of logical blocks in the host 8 area. The host obtains "US" or the "unit size" from the 9 ONLINE or SET UNIT CHARACTERISTICS command end messages. 10 2. The unit's Replacement Control Table (RCT), used to 11 record bad block replacement information. This 12 information is further described below. The RCT 13 (actually, multiple copies of the RCT) occupies the 14 logical blocks numbered US through N-1. 15 The presence of the RCT is optional; see the description below. 16 All of the logical blocks in the host area are guaranteed to be 17 "good" -- that is, to be free of permanent or hard errors (media 18 defects). Most controllers implement this via bad block 19 replacement. A pool of replacement blocks, identified by 20 replacement block numbers (RBNs), is provided on the disk. 21 Replacement blocks are not directly accessible to hosts. All 22 host area logical blocks that are bad (i.e., that contain media 23 defects leading to hard errors or large numbers of correctable 24 errors) are replaced by a replacement block. The mechanism used 25 to perform this replacement, and to revector accesses to bad 26 logical blocks to the proper replacement blocks, is described in 27 the Digital Storage Architecture Disk Format Specification (DSDF) 28 and/or the controller's functional specification. The pool of 29 replacement blocks is typically distributed throughout the disk, 30 so that revectoring of logical block accesses to replacement 31 blocks has negligible impact on performance. See Section 4.13, 32 "Bad Block Replacement," and DSDF for more information on bad 33 block replacement. 34 4.12.1 Replacement Control Table (RCT) Overview 35 The logical blocks that contain the RCT are not guaranteed to be 36 "good." Since the RCT describes the bad logical block to 37 replacement block mapping, mapping bad RCT blocks to replacement 38 blocks would present an insoluble recursion problem. Instead of 39 using replacement blocks for bad RCT blocks, the RCT region 40 actually contains multiple copies of the RCT. Hosts obtain the 41 size of each RCT copy and the number of RCT copies via the GET 42 UNIT STATUS command. The last copy of the RCT may be truncated. 43 See the Digital Storage Architecture Disk Format Specification 44 (DSDF). Note that the disk is unusable if the corresponding *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-33 Disk Geometry And Format 11 June 1992 1 block is bad in every copy of the RCT. 2 The detailed format and access algorithms for the RCT are 3 described in DSDF. In general, however, each copy of the RCT 4 contains the following information: 5 1. One entry per replacement block, identifying the logical 6 block, if any, that has been replaced by the replacement 7 block. 8 2. Context information identifying the bad block 9 replacement operation, if any, that is currently in 10 progress on this unit. This information is used to 11 complete the bad block replacement operation if the host 12 and/or controller should crash in the middle of bad 13 block replacement. 14 Alternatively, a controller may use a nonstandard replacement 15 scheme or some scheme other than bad block replacement to 16 guarantee that the logical blocks in the host area are "good." 17 The mechanisms used by such a controller to guarantee that the 18 host area logical blocks are "good" shall be totally invisible to 19 hosts, and shall not require host cooperation for their 20 initialization, use, or maintenance. Such a controller or unit 21 will not provide a host accessible RCT. 22 4.12.2 Logical Block Contents 23 The host visible portion of each logical block consists of a 24 fixed number of data bytes. The number of data bytes is either 25 512 or 576, determined when the disk volume is formatted. All 26 logical blocks on a disk volume have the same number of data 27 bytes. 28 The data bytes are the only portion of logical blocks that are 29 directly host visible. Certain other items, however, must be in 30 each logical block as their presence is implied by various MSCP 31 functions: 32 1. Each block shall contain a forced error indicator, so as 33 to properly implement and recognize the "Force Error" 34 command modifier. 35 2. Each block shall contain a bad block indicator, so that 36 references to bad blocks can be efficiently revectored 37 to the proper replacement blocks. This is unnecessary 38 if the controller does not use bad block replacement to 39 provide a "perfect" host area. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-34 Disk Geometry And Format 11 June 1992 1 Note that the forced error indicator is fully distinct from the 2 512 or 576 bytes of data in each block. Blocks written with the 3 "Force Error" command modifier shall, when read back, return both 4 correct data and the presence of a forced error. Blocks written 5 with forced errors shall have similar error rate characteristics 6 as blocks written normally, without forced errors. A forced 7 error indicates that the host or controller process writing the 8 block did not have fully valid data to write into that block. 9 The disk subsystem (controller and unit) shall, however, preserve 10 the data so as to avoid further data corruption. 11 4.12.3 Performance Implications 12 As stated above, the host area of a disk is structured as a 13 vector of logical blocks. From a performance viewpoint, however, 14 it is more appropriate to view the host area as a four 15 dimensional hyper-cube. The four dimensions are cylinder, group, 16 track, and sector. Thus, it is possible to decompose a logical 17 block number into a unique quadruple of numbers; namely the 18 block's cylinder number, group number, track number, and sector 19 number. Cylinder number is most significant and sector number is 20 least significant. 21 Alternatively, we can define a track as consisting of a fixed 22 number of blocks, a group as consisting of a fixed number of 23 tracks, and a cylinder as consisting of a fixed number of groups. 24 The position of a block within a track is the block's sector. 25 "Spindles" are physical entities across which both seek and 26 rotational latencies are unpredictable. A unit consists of one 27 or more spindles or spindle "groups." 28 The terms sector, track, cylinder, and spindle all come from the 29 geometry of classical disk drives. Groups can be viewed as an 30 optimization for short seeks whose seek time is easily 31 predictable. 32 At any particular instant, the set of logical blocks that are 33 instantaneously accessible is those blocks in all tracks that are 34 in a particular sector, group, and cylinder. In the absence of 35 transfers to a different group or cylinder, this set of 36 instantaneously accessible blocks changes over time by keeping 37 the group and cylinder constant while incrementing the sector 38 modulo the number of blocks/sectors in a track. Referring to our 39 hyper-cube analogy, the set of instantaneously accessible blocks 40 form a line parallel to the track axis. This line moves parallel 41 to the sector axis, wrapping around when it reaches the edge of 42 the hyper-cube. A disk therefore provides cyclic access to the 43 blocks in a particular group and cylinder. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-35 Disk Geometry And Format 11 June 1992 1 This access structure to logical blocks implies that, to a close 2 approximation, the track to which a block belongs has no effect 3 upon performance. That is, switching tracks within the same 4 group and cylinder effectively requires zero time. Two separate 5 transfers in the same group and cylinder have similar 6 performance, regardless of what tracks they are on. To a first 7 order approximation, two separate transfers on successive sectors 8 of different tracks in the same group and cylinder have the same 9 performance as a single, two sector (block) transfer. 10 Changing cylinders, however, does require a certain amount of 11 time. The amount of time required to switch between two 12 cylinders is approximated by a monotonically increasing function 13 of the difference between the two cylinder numbers. The time to 14 switch between cylinders is typically not affected by whether or 15 not groups are also being changed. After switching cylinders, 16 the sector position of the disk (i.e., which sector's blocks are 17 instantaneously accessible) is unpredictable. 18 Changing groups also requires a certain amount of time. 19 Generally, the time to switch between groups in the same cylinder 20 is no more than, and often less than, the time to switch between 21 one cylinder and the next. If cylinders and groups are both 22 changed at the same time, the time to switch groups is 23 effectively zero, as it is included in the time to switch 24 cylinders. 25 When changing from one group to the next (successive) group 26 within the same cylinder, the time required to switch groups is 27 predictable. Therefore the sector position following completion 28 of the group switch is also predictable, and transfers can be 29 optimized across group boundaries. If a transfer to sector S in 30 group G is followed by a transfer in group G+1 of the same 31 cylinder, then sector S+1 (modulo the number of sectors/blocks in 32 a track) is the optimal sector for the new transfer and sector S 33 is the least desirable. The main effect of this is to optimize 34 continuous (spiral) transfers that cross group boundaries. 35 Note that what has been described herein is the model for disk 36 logical geometry, which may have a tenuous relationship to a 37 disk's actual physical geometry. Disk designers should devise a 38 logical to physical geometry mapping which optimizes the accuracy 39 of the model herein described. This will generally be done as 40 follows. Head or track switches that effectively require zero 41 time (i.e., that require less than the intersector time) will be 42 reported as logical MSCP tracks. Head or track switches that 43 require significant amounts of time will be divided into two 44 classes: those that require only a little time (typically less 45 than one rotation) and whose time is predictable, and those that 46 require somewhat more time and/or a lot of time. The switches *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-36 Disk Geometry And Format 11 June 1992 1 that require only a little time will be reported as logical MSCP 2 groups. The switches that require more time will be reported as 3 logical MSCP cylinders, where the switches should be mapped to 4 cylinders in such a manner as to minimize the amount of time 5 required to switch between cylinders that are numerically close 6 together. 7 The effect of this geometry on multiblock transfers is as 8 follows. A multiblock transfer requires a certain minimum time, 9 which is the time to transfer one block or sector times the 10 number of blocks in the transfer. Crossing track boundaries 11 requires no additional time. Crossing a group boundary requires 12 a small, relatively fixed additional amount of time. This time 13 is typically less than the time to transfer an entire track 14 (i.e., less than one rotation). Crossing a cylinder boundary 15 requires a somewhat larger additional amount of time. This time 16 is typically at least the time to transfer an entire track (i.e., 17 at least one rotation). 18 The effect of this geometry on host allocation policies for 19 random-access files is as follows. Whenever possible, a 20 random-access file should be allocated within a single group. If 21 this is not possible, the host should try to allocate it within a 22 single cylinder. If this is also not possible, the host should 23 allocate it in the minimum number of adjacent cylinders. 24 When a block has a high probability of being accessed immediately 25 after another block, hosts should attempt to allocate both blocks 26 in the same group or, if that is not possible, in the same 27 cylinder. If both blocks cannot be allocated within the same 28 cylinder, then they should be in cylinders that are as close 29 together as possible. 30 Hosts obtain the size of a unit's tracks, groups, and cylinders 31 from the GET UNIT STATUS command's end message. Some of these 32 disk geometry concepts may not apply to all disk units. Units 33 report the fact that a concept doesn't apply by specifying its 34 size to be the same as the next larger concept. For example, a 35 disk unit that doesn't have groups would specify one group per 36 cylinder, implying that groups and cylinders are the same size. 37 Note that the value of zero is reserved and illegal for track 38 size, group size, and cylinder size. 39 Track size, in addition to being useful for performance 40 prediction, is also used in the bad block replacement algorithm 41 specified in the Digital Storage Architecture Disk Format 42 Specification (DSDF). It is possible that the track size 43 appropriate for performance considerations will be different from 44 the track size required by bad block replacement. If this 45 occurs, the track size required by bad block replacement shall be *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-37 Disk Geometry And Format 11 June 1992 1 specified, as the performance effects are a secondary 2 consideration. 3 Note that all of this performance oriented disk geometry only 4 applies to the host area of a disk unit. The concepts need not 5 apply to the Replacement Control Table (RCT) and any other areas 6 of a disk, as access to those areas is not performance sensitive 7 and/or not host visible. 8 4.13 Bad Block Replacement 9 Bad block replacement is a technique used with disk class devices 10 to present each unit as a single logically contiguous set of 11 usable blocks. 12 A unit may operate in one of two modes: Controller Initiated Bad 13 Block Replacement or Host Initiated Bad Block Replacement. A 14 unit's mode is determined by whether or not the controller 15 requires host assistance in performing dynamic bad block 16 replacement for that unit. Controllers report this to hosts via 17 the "Controller Initiated Bad Block Replacement" unit flag (see 18 Section 5.7, "Unit Flags" for more detail). 19 For a complete description of Controller Initiated Bad Block 20 Replacement, see Chapter 8, "Controller Initiated Bad Block 21 Replacement." 22 For a complete description of Host Initiated Bad Block 23 Replacement, see the Digital Storage Architecture Disk Format 24 (DSDF) specification section on "Host Initiated Bad Block 25 Replacement." 26 4.14 Write Protection 27 There are three kinds of write protection that can apply to an 28 MSCP device: Hardware Write Protection, Software Write 29 Protection, and Data Safety Write Protection. Each kind of write 30 protection is controlled from a separate source as follows: 31 Hardware Write Protection 32 Hardware Write Protection is controlled by the user 33 or operator manipulating the unit's write protect 34 mechanism. The status of Hardware Write Protection 35 may change at unpredictable times in response to 36 human intervention. 37 When Hardware Write Protection is established (i.e., 38 when a user activates the unit's write protect 39 mechanism), the controller shall provide a smooth *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-38 Write Protection 11 June 1992 1 transition to the write protect state. That is, the 2 controller shall complete all write operations 3 (commands) that it has already initiated on the unit 4 before actually prohibiting writes. Note, however, 5 that the controller should immediately reject any 6 new write operations that it receives after the user 7 activates the unit's write protect mechanism. Write 8 operations that the controller received before the 9 write protect mechanism was activated, but that 10 haven't been initiated yet, may either be rejected 11 or completed at the controller's option. The end 12 result of this is that each individual write command 13 or operation is either completed in its entirety or 14 else rejected before any of its data is written to 15 the unit. Note that it is not possible for either 16 the controller or the host to perform bad block 17 replacement when a unit is Hardware Write Protected, 18 since it requires writing to the unit's Replacement 19 Control Table. 20 Software Write Protection 21 Software Write Protection is controlled by the host 22 or hosts. Host(s) set or change the status of 23 Software Write Protection via the ONLINE or SET UNIT 24 CHARACTERISTICS commands ("Enable Set Write Protect" 25 modifier and "Software Write Protect" unit flag). 26 In general, the detailed causes of Software Write 27 Protection are matters of host policy. However, 28 Host Initiated Bad Block Replacement, as described 29 in the Digital Storage Architecture Disk Format 30 Specification (DSDF), requires that hosts use 31 Software Write Protection to emulate certain causes 32 of Data Safety Write Protection. 33 Unlike the transition to Hardware Write Protect the 34 transition to Software Write Protect is a naturally 35 smooth process since it is established by Sequential 36 commands (i.e., ONLINE and SET UNIT 37 CHARACTERISTICS), which implies that all write 38 operations will have been completed prior to 39 Software Write Protection being established. 40 Data Safety Write Protection 41 Data Safety Write Protection is controlled by the 42 MSCP server. It is set whenever some condition in 43 the unit or volume prevents reliable modification of 44 data on the volume. Possible causes include: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-39 Write Protection 11 June 1992 1 o An incomplete bad block replacement. 2 o An invalid RCT. 3 o The unit is only capable of reading the 4 volume's format (e.g., a single-density 5 volume in a double-density drive). 6 Note that there can be multiple causes for a 7 unit being Data Safety Write Protected. 8 Furthermore, some causes represent errors while 9 others represent normal occurrences. 10 Each individual cause can only be established 11 when a unit is brought "Unit-Online." Causes 12 can be eliminated -- possibly allowing the unit 13 to cease being Data Safety Write Protected -- 14 while the unit remains "Unit-Online." However, 15 the server can only establish a new cause for 16 the unit to be Data Safety Write Protected by 17 forcing the unit to be "Unit-Available" to all 18 class drivers. Thus class drivers are 19 guaranteed that a unit will not spontaneously 20 become Data Safety Write Protected while the 21 unit is "Unit-Online." 22 A unit's Write Protect Status Display Mechanism shall indicate 23 the "inclusive or" of all forms of write protection. That is, 24 the display shall indicate that the unit is write protected when 25 it is Hardware or Software or Data Safety Write Protected. 26 4.15 Compare Operations 27 MSCP includes the following kinds of compare operations: 28 1. The COMPARE HOST DATA command. 29 2. Read-compare operations, invoked by the "Compare Reads" 30 unit flag or by the "compare" modifier on a READ 31 command. 32 3. Write-compare operations, invoked by the "Compare 33 Writes" unit flag or by the "compare" modifier on a 34 WRITE command. 35 The operation of these different types of compare operations is 36 described below. Note that all of the compare operations report 37 the first difference or other error starting from the beginning 38 of the transfer. Therefore the compare operation at the end of *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-40 Compare Operations 11 June 1992 1 the transfer may be aborted if a difference is discovered at the 2 beginning. 3 The COMPARE HOST DATA command is used to verify that data in host 4 memory matches data on a unit. The data is obtained from the 5 unit in the manner that is most convenient or efficient for the 6 controller. In this respect the COMPARE HOST DATA command 7 operates identically to a READ command. Unlike the READ command, 8 the data is not transferred to host memory. Instead, data is 9 obtained from host memory and compared against the data obtained 10 from the unit. Upon completion of the command the controller 11 reports whether the data was identical or different. The data 12 being different is reported as a "Compare Error" in the command's 13 end message. No error log message is generated as this is not 14 considered to be a "significant" error (since it can be 15 deliberately caused by user programs). The controller may 16 attempt retries or not at its option. As the retries will always 17 fail (assuming the host is not modifying the buffer while the 18 transfer is in progress), retries will have a deleterious effect 19 on performance but will in no way effect the final outcome of the 20 operation. 21 Read-compare and write-compare operations are performed at the 22 conclusion of the appropriate transfer commands to verify that 23 the data was correctly transferred and that the data can now be 24 obtained from its destination. The general algorithm used is to 25 obtain the data from its destination and compare it against the 26 data reobtained from its source. 27 In particular, during a read-compare operation the controller 28 reobtains the data from the unit and compares it against the data 29 obtained from host memory. Conversely, for the write-compare 30 operation the controller obtains the data from the unit and 31 compares it against the data reobtained from host memory. 32 An additional requirement for performing read-compare and 33 write-compare operations is that the controller should, to the 34 maximum extent allowed by its architecture, operate all data 35 transfer paths in the opposite direction from that of the 36 original transfer, in order to maximize the probability of 37 detecting a transfer error. 38 Ideally, to operate all transfer paths in the opposite direction, 39 during a read-compare operation, the controller would obtain the 40 data from the host and send it to the drive, and the drive would 41 actually compare the data against the original. Conversely, 42 during a write-compare operation, the data would be sent to the 43 host port, which would actually perform the comparison. However, 44 neither implementation is currently feasible since no drive nor 45 communications mechanism provides such comparison capabilities. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-41 Compare Operations 11 June 1992 1 So for now controllers must perform the actual compare functions. 2 If a read-compare or write-compare operation fails, the 3 controller shall interpret this as implying that the original 4 transfer failed and retry the original transfer if appropriate. 5 If the controller successfully obtains the data from its source 6 and destination, but the data is different, then the controller 7 shall retry the original transfer and report the compare error in 8 an error log message. If the controller cannot successfully 9 obtain the data from its destination, but the error is one that 10 may be eliminated by rewriting the data to the destination, then 11 the controller shall also retry the original transfer and report 12 the error (from the attempt to obtain the data from its 13 destination) in an error log message. All other errors need not 14 be retried, but shall be reported in an error log message. The 15 only exception to the above is commands that have the "Suppress 16 Error Recovery" modifier set. The controller may or may not, at 17 the controller's option, retry the original transfer if a compare 18 error occurs in such a command. 19 For example, "Data Errors," such as an uncorrectable ECC error, 20 shall be retried on write-compare operations. They need not be 21 retried on read-compare operations, since an unrecoverable "Data 22 Error" implies that the READ itself will fail. "Compare Errors" 23 shall always be retried. Note that the controller need not 24 discriminate among types of errors -- it may always retry all 25 errors during read-compare or write-compare operations, 26 regardless of whether or not the error will inhibit the original 27 transfer. 28 The number of retries required for read-compare and write-compare 29 operations is controller dependent. However, all controllers 30 shall retry such operations at least once. The exact number of 31 retries that a controller implements should be chosen based on 32 undetected error rate characteristics. The controller may either 33 retry the entire transfer, or else only retry the portion that 34 includes the error. 35 4.16 Special Drive Topologies 36 4.16.1 Multiaccess Drives 37 A multiaccess drive is a drive that may be physically connected 38 to more than one controller simultaneously via separate physical 39 paths (ports). The primary purpose of the multiaccess drive 40 capability is to enhance the availability of data by providing 41 alternate access paths to the data, thereby safeguarding against 42 individual host, controller, or communications mechanism failure. 43 High availability systems typically utilize multiaccess drives 44 and the replication of some or all of the other major system *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-42 Special Drive Topologies 11 June 1992 1 components in order to recover from such failures without human 2 intervention. 3 Although a multiaccess drive may be physically connected to more 4 than one controller, only one controller at any one time may 5 establish the logical connection (i.e., bring it online) 6 necessary for any unit of the drive to become "Unit-Online" or 7 under the "Exclusive Access" of a host via that controller (see 8 Section 4.3, "Unit States"). Note that the detailed definition 9 of the logical connection between a controller and a drive is 10 device dependent, and therefore not the concern of this 11 specification. 12 Once the logical connection between a multiaccess drive and a 13 controller is established, the unit of a drive or the units of a 14 multiunit drive or formatter (see Section 4.16.2, "Multiunit 15 Drives and Formatters") can only be accessed via that same 16 controller and MSCP server. The unit or units therefore become 17 inaccessible (i.e., "Unit-Offline") via all other controllers to 18 which the multiaccess drive is physically connected. 19 A controller may only retain the logical connection with a drive 20 as long as one or more units of that drive are "Unit-Online" or 21 under "Exclusive Access" via that controller. That is, a 22 controller shall release its logical connection with a drive as 23 soon as all units of the drive cease to be "Unit-Online" to any 24 host or under the "Exclusive Access" of a particular host. Host 25 class drivers may therefore switch access paths to a multiaccess 26 drive from one controller to another under program control by 27 making all units of the drive "Unit-Available" through the 28 controller to which the drive is currently logically connected, 29 then bringing one of the units "Unit-Online" or under "Exclusive 30 Access" via the other controller. 31 A controller shall also release the logical connections to all 32 units of a multiaccess drive whenever the host access timeout 33 (specified via the SET CONTROLLER CHARACTERISTICS command) 34 expires, in order to permit access to the drive via another 35 access path. See Section 4.9, "Host Access Timeouts" for 36 complete details. 37 The logical connection between a controller and a multiaccess 38 drive must exist in order for any unit of the drive to be 39 "Unit-Online" or under "Exclusive Access" with respect to any 40 host. However, certain status information must be available to 41 all controllers without the existence of a logical connection. 42 The specific cases are: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-43 Special Drive Topologies 11 June 1992 1 1. When no units of the drive are "Unit-Online" to or under 2 the "Exclusive Access" of any class driver (that is, 3 when they are all "Unit-Available" or "Unit-Offline"), 4 the multiaccess drive shall report its existence, unit 5 number(s), and certain characteristics to all 6 controllers to which it is attached. The actual 7 mechanism by which this information is reported is 8 device dependent, and therefore may use such schemes as 9 time-multiplexing or polling of a single communication 10 path. However, controllers shall present the conceptual 11 view to hosts that this information is reported 12 continuously and simultaneously to all controllers. The 13 drive characteristics that shall be reported are those 14 returned in the AVAILABLE attention message and in the 15 GET UNIT STATUS and SET UNIT CHARACTERISTICS command end 16 messages for the current state of the drive's units 17 ("Unit-Available" or "Unit-Offline"). 18 2. When a drive is logically connected to some controller, 19 and that controller receives a DETERMINE ACCESS PATHS 20 command for one of the units that is "Unit-Online," the 21 drive shall report its existence, unit number, and 22 certain characteristics to all other controllers to 23 which it is attached. The characteristics that it shall 24 report are those returned in the ACCESS PATH attention 25 message. As detailed in Section 6.6.3, "DETERMINE 26 ACCESS PATHS Command, Description" successful 27 communication of the ACCESS PATH attention message may 28 be probabilistic rather than guaranteed. Note that the 29 drive need only make this report when instructed to do 30 so by the controller. 31 Note that those two cases are only of concern with multiaccess 32 drives, as a single access drive cannot have the problem of 33 trying to communicate with two or more controllers at once. 34 Also, if a multiaccess drive is logically connected to a 35 controller, and that controller never receives a DETERMINE ACCESS 36 PATHS command for a "Unit-Online" unit of that drive, then that 37 drive need not communicate in any way with any other controller. 38 The drive need not even report its existence until the logical 39 connection is broken (i.e., it ceases to be "Unit-Online" or 40 under "Exclusive Access") or the controller receives a DETERMINE 41 ACCESS PATHS command. 42 4.16.2 Multiunit Drives And Formatters 43 A multiunit drive is a single physical disk drive that appears as 44 several independent units to hosts. So-called fixed plus 45 removable disk drives, providing one removable disk unit and one 46 nonremovable disk unit, are the most common example of multiunit *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-44 Special Drive Topologies 11 June 1992 1 drives. A multiunit formatter is a single set of interface or 2 read/write electronics that connects several otherwise 3 independent units to controllers. Multiunit formatters are most 4 commonly used with tape drives, although there is nothing that 5 prevents their use with disk drives as well. 6 All the units of a multiunit drive or formatter share a single 7 access path to controllers. This implies that all of the units 8 must be "connected" to the same controller. In particular, if 9 one unit of a multiunit drive or formatter is "Unit-Online" or 10 under "Exclusive Access" via a controller, then all the other 11 units of the multiunit drive or formatter may only be accessed by 12 that same controller. That is, the other units are 13 "Unit-Offline" to all other controllers. Awareness of this 14 characteristic is critical for high availability systems -- if a 15 failed operation on a multiaccess unit is to be retried via 16 another controller, and the unit is part of a multiunit drive or 17 formatter, then all units of the drive or formatter must be 18 switched to the other controller. 19 Some units of a multiunit disk drive may share mechanical 20 components as well as interface electronics. Such units are said 21 to share a spindle. That is, the units must either be all 22 spinning or all not spinning, just as if the units shared a drive 23 motor or spindle (which they typically will). Such units must 24 also share a single Run/Stop switch, since they are always 25 spun-up and spun-down together. Hosts must also be aware of 26 units which share a spindle, as dismounting one such unit 27 requires that all units sharing the same spindle be spun-down. 28 The units of a multiunit drive or formatter are identified by the 29 "multiunit code" unit characteristic field. Hosts obtain this 30 two byte field via the AVAILABLE attention message or in the end 31 message of a GET UNIT STATUS, ONLINE, or SET UNIT CHARACTERISTICS 32 command. The low byte of this field contains a controller 33 dependent encoding of the access path between the controller and 34 the drive. The high byte of this field contains a controller 35 dependent encoding of the spindle, on a particular access path, 36 that the unit uses. Controllers may use any encoding whatsoever, 37 provided that each access path and each spindle (within an access 38 path) has a unique value. Note that the access path byte is 39 implicitly qualified by the controller's or MSCP server's 40 identity, and that the spindle byte is implicitly qualified by 41 the access path. 42 Hosts use the "multiunit code" field as follows. When a host 43 decides to spin-down a unit, it scans all other units that are 44 "Unit-Online" via the same MSCP server for those units whose 45 entire "multiunit code" field (both bytes) matches the unit being 46 spun-down. Such units, if any, share a spindle or other *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-45 Special Drive Topologies 11 June 1992 1 mechanical components with the unit being spun-down, so that they 2 must be spun-down together. When a host decides to access a unit 3 via a different controller, it scans all other units that are 4 "Unit-Online" via the same MSCP server for those units whose low 5 byte of the "multiunit code" field matches the unit being 6 switched. Such units, if any, share an access path with the unit 7 being switched, so that they must also be switched to the new 8 controller. 9 Note that the low byte of the "multiunit code" field (the access 10 path) is meaningless for units that are inherently restricted to 11 a single controller. Controllers may return any fixed value as 12 the access path encoding for such units, provided that it doesn't 13 duplicate the value returned for any units on the same controller 14 that are not inherently restricted to a single controller. 15 This use and format of the "multiunit code" field implies the 16 following architectural restrictions on all controllers: 17 1. All units that share a spindle or other mechanical 18 components shall also share an access path. Note that 19 this is an essential restriction for multiunit drives, 20 regardless of how shared components are communicated. 21 If units that share a spindle did not share an access 22 path, then they could be simultaneously "Unit-Online" 23 via different controllers, making it impossible to 24 coordinate a simultaneous spin-down. 25 2. There is a maximum of 256 access paths per controller. 26 In the absence of multiunit drives or formatters, this 27 implies a maximum of 256 units per controller. 28 3. There is a maximum of 256 spindles per access path. In 29 the absence of shared spindles, this implies a maximum 30 of 256 units per access path or formatter. 31 4.17 Controller And Unit Identifiers 32 MSCP requires that all controllers and drives have unique 33 identifiers, called controller identifiers and unit identifiers. 34 The structure of these identifiers is as follows: 35 31 0 36 +-------------------------------+ 37 | unique device number | 38 +-------+-------+ + 39 | class | model | | 40 +-------+-------+---------------+ *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-46 Controller And Unit Identifiers 11 June 1992 1 The fields in a controller or unit identifier are as follows: 2 unique device number 3 Uniquely identifies the device among all devices of that 4 same class and model. The device serial number could be 5 used as the "unique device number," though that isn't 6 required. 7 model 8 Identifies the exact model of the subsystem within its 9 class. All valid class and model codes are nonzero, 10 implying that all valid identifiers are nonzero. Table 11 C-2, "Mass Storage Controller 'Model' Values"contains the 12 "model" values for both disk and tape controllers. 13 Tables C-3, "Disk Drive/Media Identifier Values" and C-4, 14 "Tape Drive/Media Identifier Values" contain the "model" 15 values for disk and tape drives, respectively. 16 class 17 Identifies the type of the subsystem -- controller, disk 18 drive, etc. Table C-1, "Controller and Unit 'Class' 19 Values" contains the "class" values for both controllers 20 and drives. 21 The Storage Systems Architecture Group is responsible for 22 assigning new values. Requests for additions to the tables 23 should be addressed to SSAG::SSAG. Note that different units of 24 multiunit drives are distinguished by having different "model" 25 bytes; the "class" and "unique device number" fields are 26 typically identical. Note also that all MSCP servers for the 27 same device class within the same controller shall return the 28 same controller identifier. 29 As previously stated, MSCP requires that controller and unit 30 identifiers be unique across all devices accessible via MSCP. 31 This clearly cannot be checked by controllers. Controllers can, 32 however, enforce unique unit identifiers across the units that 33 are attached to themselves. This is done using the following 34 algorithms: 35 1. Controllers should detect and respond to duplicate unit 36 identifiers across all units whose unit identifiers the 37 controller can obtain, including all units that would 38 otherwise be "Unit-Online" or "Unit-Available." 39 Detection of a duplicate unit identifier on one unit of 40 a multiunit drive is treated as a duplicate unit *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-47 Controller And Unit Identifiers 11 June 1992 1 identifier condition on all other units that share one 2 or more of the following components with the unit having 3 the duplicate unit identifier: 4 a. A unit number select mechanism. 5 b. A Run/Stop or Load/Unload switch. 6 c. A spindle or other mechanical components. 7 Note that duplicate unit identifiers are detected 8 regardless of the state of a unit's Run/Stop or 9 Load/Unload switch. 10 2. Whenever a controller becomes aware of a duplicate unit 11 identifier, it immediately spins-down all units with the 12 duplicate identifier and forces them to remain 13 spun-down. The controller spins-down the units 14 regardless of their current state. The controller 15 typically forces them to remain spun-down by spinning 16 them down again whenever an operator spins them up. 17 3. The controller reports "Unit-Offline (subcode 18 'Inoperative')" status for all units with duplicate unit 19 identifiers. In addition, if the unit might potentially 20 be connected to another controller, the controller 21 should flag the presence of the duplicate unit 22 identifier in the drive. Other controllers, if any, 23 should check this flag and also treat the unit as 24 "Unit-Offline" if the flag is set. 25 Whether or not a controller does in fact check for duplicate unit 26 identifiers is controller dependent. Note that a duplicate unit 27 identifier is a drastic failure, indicative of some otherwise 28 undiagnosed hardware malfunction. 29 4.18 Media Type Identifiers 30 Controllers return a media type identifier for each unit 31 accessible via that controller. This identifier encodes two 32 pieces of information: 33 1. The preferred device type name for use with the unit. 34 These two alphabetic characters are conventionally used 35 with the unit number and a controller designator as the 36 fully qualified operating system identifier for the 37 unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-48 Media Type Identifiers 11 June 1992 1 2. The name (product name) of the media used on the unit. 2 This name should be printed on the unit's front panel 3 and on all removable media that may be used with the 4 unit. 5 The primary reason for returning this information is to simplify 6 operating system support for generic device allocation. 7 The media type identifier returned via MSCP is a 32 bit quantity 8 encoded as follows: 9 31 26 21 16 11 7 6 0 10 +----+----+----+----+----+------+ 11 | D0 | D1 | A0 | A1 | A2 | N | 12 +----+----+----+----+----+------+ 13 where the fields are as follows: 14 D0 15 D1 The preferred device type name for the unit. D0 and D1 are 16 five bit fields, each encoding one alphabetic character. "A" 17 is encoded with the value 1, "B" with the value 2, etc. D0 18 encodes the left character of the device type name, D1 the 19 right character. 20 A0 21 A1 22 A2 23 N The name of the media used on the unit. A0 through A2 are 24 five bit fields, each encoding an alphabetic character or 25 null. "A" is encoded with the value 1, "B" with the value 2, 26 etc. Zero represents a null or the absence of a character. 27 One to three characters of the media name are encoded, left 28 justified, in A0 through A2. N is a seven bit field 29 containing the value of two decimal digits. 30 Note that the encoding of the media name assumes that the name 31 consists of one, two, or three alphabetic characters followed by 32 exactly two digits (i.e., ann, aann, or aaann). MSCP requires 33 that the product names for all mass storage devices adhere to 34 this format. 35 Currently defined device type and media names (i.e., currently 36 defined media type identifier values) are listed in Appendix C, 37 "Controller, Unit, and Media Type Identifiers." Tables C-3, 38 "Disk Drive/Media Identifier Values" and C-4, "Tape Drive/Media 39 Identifier Values" contain the "media identifier" values for disk 40 and tape drives, respectively. The Storage Systems Architecture 41 Group is responsible for assigning new values. Requests for 42 additions to the tables should be addressed to SSAG::SSAG. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-49 Controller-based Cache 11 June 1992 1 | 4.19 Controller-based Cache 2 The purpose of a controller-based cache is to minimize the mean 3 response time for the aggregate set of I/O requests serviced by 4 the controller. Controller-based caches are intended to be 5 invisible to the user except for this performance improvement. 6 Implementations shall ensure the data integrity with the cache 7 employed is comparable to the backing-store even through power 8 failures, so that the only reason to use or avoid the cache is 9 performance. Implementing controller-based cache does not waive 10 any normal storage device responsibilities as defined in this 11 specification. 12 This implies that a cached device has the same responsibility as 13 any other device in terms of setting the forced error flag in an 14 LBN if the data integrity of that LBN is in question. If it 15 knows corrupt data exists on the device but does not know which 16 data, it shall assume the Offline/Unit inoperative state and 17 maintain this state even through power failure. In this case, it 18 must provide a diagnostic or DUP path for recovery of user data. 19 No single point of failure may allow the unreported return of the 20 wrong or corrupt data. 21 The following are implementation examples that demonstrate the 22 implications of these responsibilities. 23 o If storage units are dual ported to two or more 24 controllers, the controllers will write data to the unit 25 backing-store as well as the cache before returning the 26 command complete response so that the failure of one of 27 the controllers cannot cause loss of user data or its 28 consistency. 29 o Controllers whose cache may lose user data or its 30 consistency in the event of power failure will write the 31 data to the backing-store as well as the cache before 32 returning the command complete response. For commands 33 with the compare modifier, the command complete will not 34 be sent until the compare has been made with the backing 35 store. 36 o Controllers whose cache is capable of maintaining the 37 user data integrity and its consistency at a level 38 comparable to the backing-store, even through power 39 failure, can return the command complete response as 40 soon as the data is in the cache, before writing to the 41 backing-store. For commands with the compare modifier, 42 the command complete response may also be returned as 43 soon as the user data is compared to the cache data. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 ALGORITHMS AND USAGE RULES Page 4-50 Controller-based Cache 11 June 1992 1 o A controller-based cache implementation can degrade its 2 cache actions in the event of component failure as long 3 as the specified data integrity is maintained. For 4 example, if a controller implementing a cache that can 5 maintain its integrity through power failure recognizes 6 its cache memory integrity is degrading, it can flush 7 the cache and revert to a mode where it writes to the 8 backing-store as well as the cache before returning the 9 command complete response. 10 The manner in which users access their data varies greatly. Some 11 access it totally randomly, others walk through files 12 sequentially. Some access the same data many times, others 13 access each piece of data only once. These differing access 14 patterns have a great effect on the performance of a cache 15 algorithm. 16 Transfer commands are provided with a "Cache Access Attributes" 17 field so that the cache action can be optimized for these 18 patterns. This is an optional use field that allows users to 19 provide "advice" as to the access patterns they expect. A 20 particular cache implementation, knowing its specific caching 21 algorithm and its current state, may make use of this advice to 22 optimize its performance. No specific action is mandatory or 23 architecturally defined. Each implementation shall specify its 24 actions. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-1 11 June 1992 1 CHAPTER 5 2 MSCP CONTROL MESSAGES 3 5.1 Generic Control Message Format 4 All MSCP control messages -- i.e., command, end, error log, and 5 attention messages -- consist of a 12 byte header and a variable 6 length parameter area. The generic control message format is as 7 follows: 8 31 0 9 +--------------------------------+ 10 | | 11 +------- control message --------+ 12 | type specific | 13 +------- header --------+ 14 | | 15 +--------------------------------+ 16 | | 17 / parameters / 18 / / 19 | | 20 +--------------------------------+ 21 The device class (disk or tape) does not appear in the control 22 message. It is implied by the connection or MSCP server to/from 23 which the control message is sent/received. 24 Multibyte numbers are stored least significant byte first (i.e., 25 using the standard VAX number formats). 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 (typically equal to the longest message supported) 32 or that the length be an even multiple of bytes. For this reason 33 the message lengths defined by MSCP are minimum lengths. Senders 34 may pad messages as necessary to meet communications mechanism 35 length restrictions. The contents of the padding (that is, the 36 contents of any data past the end of the message formats shown in 37 this document) are reserved and follow the rules for reserved 38 fields defined in Section 5.2, "Reserved and Undefined Fields" 39 (i.e., such padding contains zeros). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-2 Reserved And Undefined Fields 11 June 1992 1 5.2 Reserved And Undefined Fields 2 Reserved fields are those fields that are intended for possible 3 future extensions to MSCP. The use of such fields shall follow 4 certain rules, in order to ensure that such future extensions can 5 be upwards compatible with the current version of MSCP. In 6 general, the sender of a message shall supply the value zero in 7 all reserved fields. The action for a message receiver varies, 8 and is discussed below. 9 An undefined field is just that -- its contents are controller 10 implementation dependent, and therefore cannot be used in any 11 meaningful way by class drivers. Undefined fields are provided 12 in order to simplify controller implementation. Class drivers 13 shall ignore the contents of undefined fields. 14 A field, as used in this discussion, may have any length. In 15 particular, it may be an individual bit of a flags word or byte 16 as well as an entire byte, word, or whatever. 17 Class drivers shall supply the value zero in the reserved fields 18 of all messages (commands) that they send to a controller, and 19 shall also ignore the contents of reserved fields in all the 20 messages (end messages, attention messages, and error log 21 messages) that they receive from an MSCP server. MSCP servers 22 shall supply the value zero in the reserved fields of all 23 messages (end messages, attention messages, and error log 24 messages) that they send to class drivers. MSCP servers shall 25 either ignore the contents of reserved fields in the messages 26 (commands) that they receive from class drivers or verify that 27 the contents are zero. The command is treated as an "Invalid 28 Command" ("reserved field" protocol error; see "Invalid Command" 29 status in Section 5.5, "Status and Event Codes") if the 30 controller chooses to verify and the contents are found to be 31 nonzero. Whether an MSCP server verifies that reserved fields 32 are zero is controller dependent, and need not be consistent for 33 all reserved fields. 34 Many controllers generate command end messages by simply 35 modifying the commands' command messages. That is, the 36 controller copies a command message into an internal buffer, 37 modifies it in place during execution of the command, then sends 38 the resulting contents of the internal buffer as the command's 39 end message. To simplify such an implementation, controllers may 40 merely "echo" command message reserved fields when the 41 corresponding field in the end message should be zero. More 42 precisely, if some field in the end message of a command should 43 be zero, and the corresponding (same position) field in the 44 command's command message is a reserved field, the controller may 45 copy the reserved field from the command message to the end *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-3 Reserved And Undefined Fields 11 June 1992 1 message rather than explicitly zeroing the field in the end 2 message. 3 The above paragraphs have listed all of the allowable controller 4 actions when a controller receives a command message with a 5 nonzero value in a reserved field. That is, when a controller 6 receives a command message with a nonzero value in a reserved 7 field it shall do one of the following: 8 1. Reject the command as an "Invalid Command" ("reserved 9 field" protocol error; see "Invalid Command" status in 10 Section 5.5, "Status and Event Codes"). 11 2. Totally ignore the nonzero contents of the reserved 12 field. That is, the command's execution, results, and 13 end message contents are totally unaffected by the 14 nonzero value. 15 3. If the corresponding field in the end message should 16 have a zero value, echo the contents of the reserved 17 field in the command message as the value of the field 18 in the end message. In all other ways totally ignore 19 the nonzero contents of the reserved field. That is, 20 the command's execution, results, and the contents of 21 all other fields in the end message are totally 22 unaffected by the nonzero value. 23 Note that option 3 is primarily of use when a field is reserved 24 in both command and end messages. 25 It is recommended, although not required, that which of these 26 options a controller implements be based on whether the 27 controller's code is hard (ROM based) or soft (loadable 28 microcode, implying it is easily altered). The purpose of this 29 is to provide the maximum degree of error checking consistent 30 with ease of future extensions to MSCP. Controllers whose code 31 is soft or relatively easy to alter should implement option 1, 32 verifying that reserved fields are in fact zero. Controllers 33 whose code is hard or difficult to alter should implement option 34 3 when the corresponding fields in command and end messages are 35 both reserved and option 2 in all other cases. 36 Note that controllers shall implement option 1 whenever the 37 internal functioning of the controller may be altered if a 38 reserved field contains a nonzero value. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-4 Command Messages 11 June 1992 1 5.3 Command Messages 2 A host class driver sends a command message to an MSCP server to 3 have a certain operation performed. Note that command messages 4 are flow controlled as described in Section 3.2, "Flow Control" 5 and associated subsections. 6 The generic command message format is as follows: 7 31 0 8 +--------------------------------+ 9 | command reference number | 10 +---------------+----------------+ 11 | reserved | unit number | 12 +---------------+-------+--------+ 13 | modifiers | caa | opcode | 14 +---------------+-------+--------+ 15 | | 16 / parameters / 17 / / 18 | | 19 +--------------------------------+ 20 The fields in the generic command message are as follows: 21 command reference number 22 A 32 bit, unique, nonzero number used to identify host 23 commands. Class drivers should supply a unique reference 24 number in each command that they send to an MSCP server. 25 Command reference numbers are not interpreted in any way 26 by MSCP servers. Their purpose is to provide a unique 27 identifier by which class drivers can name commands. 28 They are used by class drivers to match end messages and 29 error log messages with the corresponding command message 30 and to identify the object of an ABORT or GET COMMAND 31 STATUS command. A class driver may supply a zero 32 reference number if it does not need to associate a 33 command with its end message. 34 Command reference numbers shall be unique across all 35 commands that are outstanding on the same connection. 36 I.e., they shall be unique across all outstanding 37 commands issued by a single class driver (host) to a 38 single MSCP server. The class driver may reuse a 39 command's reference number when the command is no longer 40 outstanding -- i.e., after receiving the command's end 41 message or after resynchronizing with the MSCP server. 42 Command reference numbers need not be unique for commands 43 issued by different class drivers -- i.e., commands *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-5 Command Messages 11 June 1992 1 issued by different hosts or commands for different MSCP 2 servers from the same host. Therefore controllers shall 3 internally use the combination of a command reference 4 number and the connection on which the command was 5 received as the unique identifier of an outstanding 6 command. 7 unit number 8 Identifies the specific unit within the device class to 9 which the message applies. This value is the binary 10 equivalent of the decimal unit number displayed by the 11 unit select mechanism. Note that the unit number field 12 appears in all command messages with the exception of the 13 ACCESS NONVOLATILE MEMORY and SET CONTROLLER 14 CHARACTERISTICS commands. It is reserved in those 15 messages. 16 opcode 17 Identifies the operation to be performed by the 18 controller. The opcode implicitly specifies the length 19 and format of the message, including the interpretation 20 of any parameters that are present. 21 Appendix A, "Opcode, Flag, and Offset Definitions," Table 22 A-1, "Control Message Opcodes," lists the valid opcodes 23 and their meanings. 24 A command message is rejected as an "Invalid Command" 25 ("invalid opcode" protocol error; see "Invalid Command" 26 status in Section 5.5, "Status and Event Codes") if its 27 opcode is: zero, any value not listed as a valid command 28 message opcode in the "Standard Command Messages" portion 29 of Table A-1, or an optional command listed in the 30 "Optional Command Messages" portion of Table A-1 that is 31 not supported by the controller. 32 The "Controller Implementation Specific Command Messages" 33 portion of Table A-1 shows a range of opcodes reserved 34 for implementation of controller specific special purpose 35 functions. Implementation of any or all of those opcodes 36 is a controller dependent option. Those opcodes will 37 typically be used by control layers internal to a 38 controller to invoke diagnostic or maintenance type 39 functions. Controllers may also honor those opcodes from 40 the host for use by manufacturing or other external 41 diagnostics. In cases where such an opcode is available 42 for host use, the command message format and operation 43 associated with the opcode shall be described in the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-6 Command Messages 11 June 1992 1 controller's functional specification. Although not an 2 absolute requirement of MSCP, it is recommended that 3 controllers implement a manually actuated control 4 mechanism (e.g., the installation of a jumper) that 5 explicitly enables and disables those opcodes available 6 for host use in order to prevent unintentional execution 7 of a special purpose function during normal operations. 8 A command message received from the host containing a 9 "Controller Implementation Specific Command Message" 10 opcode is rejected as an "Invalid Command" ("invalid 11 opcode" protocol error; see "Invalid Command" status in 12 Section 5.5, "Status and Event Codes") if the controller: 13 1. does not implement the opcode at all. 14 2. implements the opcode for internal use only. 15 3. implements a manually actuated control mechanism that 16 enables and disables host use of the opcode and host 17 use has not been explicitly enabled via that 18 mechanism. 19 caa (cache access attributes) -- for transfer commands 20 only 21 The cache access attributes field may contain a value 22 that advises the controller-based cache manager of the 23 user's expected future access of data. See Section 24 5.3.1, "Transfer Command Message Format." 25 modifiers 26 The modifiers field contains bit flags that modify the 27 operation identified by the command's opcode, or zero if 28 no modifiers are specified. See Section 5.3.2, "Command 29 Modifiers," for more details. 30 parameters 31 The parameter area is typically divided into distinct 32 fields that convey the information necessary to perform 33 the desired operation in a defined manner. The length 34 and content of the parameter area varies depending upon 35 the command's opcode. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-7 Command Messages 11 June 1992 1 Chapter 6, "Minimal MSCP Command Set" describes the operation and 2 command message format of the various commands required to be 3 supported by an MSCP disk controller. 4 The following section describes the command message format common 5 to many data transfer commands. 6 5.3.1 Transfer Command Message Format 7 Although the parameters and their layout are command (opcode) 8 dependent, many commands perform data transfers and thus use 9 similar sets of parameters. Therefore data transfer related 10 command messages are typically laid out as follows: 11 31 0 12 +--------------------------------+ 13 | command reference number | 14 +---------------+----------------+ 15 | reserved | unit number | 16 +---------------+-------+--------+ 17 | modifiers | caa | opcode | 18 +---------------+-------+--------+ 19 | byte count | 20 +--------------------------------+ 21 | | 22 +--- buffer ---+ 23 | | 24 +--- descriptor ---+ 25 | | 26 +--------------------------------+ 27 | logical block number | 28 +--------------------------------+ 29 The fields in the transfer command message are as follows: 30 command reference number 31 unit number 32 opcode 33 caa (cache access attributes) 34 The Cache Access Attributes (caa) field is only used with 35 specified transfer commands. The individual command 36 descriptions contained in Chapter 6, "Minimal MSCP 37 Command Set" show the commands for which Cache Access 38 Attributes are applicable. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-8 Command Messages 11 June 1992 1 The Cache Access Attributes field contains a value that 2 describes the access attributes of the data. The content 3 of this field is not intended to be a command to the 4 cache, but rather it is advice to the cache as to the 5 access attributes of the data which may affect the manner 6 in which the cache manages itself. Since this field is 7 only advisory in nature, any device may ignore it. The 8 implementor of the controller-based cache is responsible 9 for defining the action an implementation takes in 10 response to each Cache Access Attribute value. 11 Two generic attributes are defined and four values are 12 assigned to the four combinations of these generic 13 attributes. The assigned values are described in 14 Appendix A, "Opcodes, Flags, and Offset Definitions," 15 Table A-17, "Cache Access Attribute Values." The 16 attributes are as follows: 17 Random - A storage element implements prefetch with 18 the assumption that it is worthwhile prefetching the 19 data logically following user requested data. 20 - Random should be specified if the user believes 21 this will not be true for his request. 22 - Otherwise, Random should not be specified. 23 Single - A storage element implements a cache with 24 the assumption that it is worthwhile caching data 25 that has been previously accessed. 26 - Single should be specified if the user believes 27 this will not be true for his request. 28 - Otherwise, Single should not be specified. 29 The zero value is defined as the default value. Each 30 implementation shall define its action in terms of the 31 generic attributes in response to this value. All 32 unassigned values shall be acted upon as though they were 33 the default value, unless modified by the System Manager. 34 Some users may have unique access patterns that require 35 unique definition. In these cases, a user may be 36 assigned one or more Cache Access Attribute values for 37 the application. These values shall be assigned by the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-9 Command Messages 11 June 1992 1 Responsible Architect. Its access pattern definition 2 will be negotiated between the user and the cache 3 implementors. 4 A system manager may modify a device action to a Cache 5 Access Attribute value at configuration or 6 reconfiguration. This modification consists of changing 7 the action of a given value to that defined by another 8 value. For example, the system manager could make the 9 action in response to value 85 hex be the same as the 10 action in response to value 80 hex. Implementations that 11 allow such modification should allow all 256 Cache Access 12 Attribute Values to be modified, including those that 13 have not yet been assigned in this specification. 14 modifiers 15 | See Section 5.3.2, "Command Modifiers." 16 byte count 17 The total requested length of the data transfer in bytes. 18 This length shall meet both architectural constraints and 19 a server specified maximum. 20 An MSCP server may, at its option, return the maximum 21 byte count size that it supports in the SET CONTROLLER 22 CHARACTERISTICS end message (see Section 6.16.2, "SET 23 CONTROLLER CHARACTERISTICS, End Message Format" for 24 default values used if the size is not provided by the 25 server). Class drivers should not issue commands with 26 larger byte counts. The server response to a command 27 whose byte count is larger than the server's maximum is 28 undefined. If the server does not reject the command, it 29 is subject to the following constraints: 30 1. The server may not destroy hardware or do any 31 other action that would require field service 32 attention. 33 2. The server may alter host memory only in response 34 to a READ command, and then only that portion of 35 host memory implied by the command's buffer 36 descriptor and specified byte count. See Section 37 4.11, "Host Buffer Access." 38 3. The server may alter data on the unit only in 39 response to a WRITE or ERASE command, and then 40 only that portion of the unit implied by the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-10 Command Messages 11 June 1992 1 logical block number and specified byte count. 2 4. Any error reported in the command's end message 3 or in an error log message must have actually 4 occurred at the position reported. 5 5. With one exception, any other commands that may 6 be outstanding at the same time as the command 7 whose byte count is too large may not be 8 affected. The one exception is that the server 9 need not properly implement the command timeout 10 algorithm for any such command, not just the 11 command whose byte count is too large. 12 Byte counts shall also meet the following architectural 13 constraints, which vary depending upon the device class. 14 | For tape class devices, if the "byte count" specified is 15 | larger than a format dependent maximum block size or the 16 | byte count is zero, the command is rejected as an 17 | "Invalid Command" subcode "invalid byte count" parameter 18 | error; (see "Invalid Command" status in TMSCP, Chapter 4, 19 | Section "Status Codes"). 20 For disk class devices, the requirements depend on the 21 contents of the "logical block number" field. 22 If the "logical block number" field identifies a logical 23 block in the host area of the disk volume (i.e., the 24 "logical block number" is less than the "unit size" 25 returned in the ONLINE and SET UNIT CHARACTERISTICS end 26 messages), then the "byte count" shall be less than or 27 equal to the following maximum byte count: 28 ( unit size - logical block number ) * block size 29 where "unit size" is the unit's host area size (returned 30 in the ONLINE and SET UNIT CHARACTERISTICS end messages), 31 "logical block number" is the contents of the "logical 32 block number" field in the command message, and "block 33 size" is the volume's block size, either 512 or 576 34 bytes. The controller or MSCP server shall check that 35 the "byte count" is less than or equal to the above 36 maximum. That is, the controller or MSCP server shall 37 reject or terminate any transfer command that begins in 38 the host area of a disk volume and attempts to continue 39 into the volume's Replacement Control Table (RCT). The 40 command is rejected as an "Invalid Command" ("byte count" 41 parameter error) if this restriction is violated. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-11 Command Messages 11 June 1992 1 If the "logical block number" field identifies a logical 2 block in the disk volume's RCT (i.e., the "logical block 3 number" is greater than or equal to the "unit size" 4 returned in the ONLINE and SET UNIT CHARACTERISTICS end 5 messages), then the "byte count" shall be exactly the 6 block size (either 512 or 576 bytes). The treatment of a 7 "byte count" that does not match the block size differs 8 depending on whether or not the controller performs bad 9 block replacement. Section 8.4, "Replacement Control 10 Table Access" describes the action a controller that 11 performs bad block replacement will take. If the 12 controller does not perform bad block replacement and a 13 different (than block size) "byte count" value is 14 provided, the controller may either attempt the transfer 15 with the specified "byte count" or else reject the 16 command as an "Invalid Command" ("byte count" parameter 17 error). If the controller attempts the transfer, and the 18 "byte count" causes the transfer to extend past some 19 boundary within the RCT, then the controller performs the 20 transfer up to that boundary and terminates the command 21 as an "Invalid Command" ("byte count" parameter error). 22 The location of the boundary or boundaries at which the 23 controller terminates the transfer are controller 24 dependent. 25 For all disk and tape transfer commands that contain 26 "buffer descriptors" (i.e., all transfer commands except 27 ACCESS and ERASE), the "byte count" shall also be less 28 than or equal to the size of the buffer identified by 29 "buffer descriptor." Note that "buffer descriptor," and 30 thus the size of the buffer, is inherently communications 31 mechanism dependent. The size of a buffer is not 32 necessarily available to the MSCP server until it 33 attempts to transfer past the end of the buffer. A "Host 34 Buffer Access Error" status code is returned if the "byte 35 count" exceeds the length of the buffer. Note that such 36 errors are not necessarily distinguishable from other 37 causes of "Host Buffer Access Errors." 38 For disk transfer commands only, some communications 39 mechanisms may prohibit odd "byte count" values. Odd 40 "byte count" values shall be allowed in tape transfer 41 commands. A "Host Buffer Access Error" status code is 42 returned if the "byte count" is an illegal odd byte 43 count. For disk transfer commands that do not use a host 44 buffer (ACCESS and ERASE), a controller may return this 45 status code, or it may round the byte count up to the 46 nearest whole sector size and perform the operation. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-12 Command Messages 11 June 1992 1 "Byte count" values that exceed any of the architectural 2 maximum values described above may be detected either 3 before the transfer is initiated or when the transfer 4 attempts to cross the boundary from legal to invalid byte 5 counts. If detected before the transfer is initiated 6 (the transfer is rejected), the MSCP server shall not 7 transfer any data and shall return zero in the "byte 8 count" field of the end message. If detected when the 9 transfer attempts to cross the boundary (the transfer is 10 terminated), the MSCP server shall transfer all data up 11 to the maximum legal byte count and return the maximum 12 legal byte count in the "byte count" field of the end 13 message. Data shall not be transferred past the maximum 14 legal byte count. In either case the command is treated 15 as an "Invalid Command" ("byte count" parameter error). 16 Which algorithm an MSCP server uses for detecting byte 17 counts that are too large is controller dependent. 18 buffer descriptor 19 Communication mechanism dependent identification of the 20 host buffer to use for the data transfer. The 21 information encoded in this 12 byte (96 bit) field 22 includes: 23 o A host identifier (port or node identification). 24 o The name of a buffer on the host. 25 Note that the inclusion of a host identifier allows for 26 third party transfers. The buffer descriptor formats 27 used by various communication mechanisms are listed in 28 Appendix D, "Buffer Descriptor Formats." 29 logical block number 30 Not present in tape transfer commands. In disk transfer 31 commands, the logical block number (position) on the disk 32 volume at which to start the data transfer. This value 33 shall not identify a block past the end of the volume's 34 Replacement Control Table (RCT). Section 4.12, "Disk 35 Geometry and Format," describes the mapping of logical 36 block numbers to disk volume regions. If the command is 37 a write operation and the controller is performing bad 38 block replacement, this value also shall not identify a 39 block within the volume's RCT (see Section 8.4, 40 "Replacement Control Table Access"). Any of these errors 41 cause the command to be rejected as an "Invalid Command" 42 "logical block number" parameter error. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-13 Command Messages 11 June 1992 1 5.3.2 Command Modifiers 2 The allowable modifiers on a command are command (opcode) 3 dependent. The individual command descriptions contained in 4 Chapters 6, "Minimal MSCP Command Set" and 7, "Multihost Support" 5 list the allowable modifiers for each command. Modifiers that 6 are only allowed on one command are described in that command's 7 description. Modifiers that are common to many commands are 8 described below: 9 Clear Serious Exception 10 Clears the "serious exception" condition on the specified 11 unit. Ignored if there is no serious exception condition 12 in effect. Serious exceptions only occur on tape class 13 devices. See Tape Mass Storage Control Protocol 14 Specification (TMSCP) for complete details. 15 Compare 16 Applicable to data transfer commands. After the 17 transfer, the data will be read back from the transfer 18 destination and verified against the original data 19 reobtained from the source. Specifying this modifier is 20 similar, but not identical, to following the transfer 21 command with a COMPARE HOST DATA command. In particular, 22 if the compare operation fails, an error log message is 23 generated (if enabled) and the original transfer 24 operation retried. (With the COMPARE HOST DATA command, 25 an error log message is not generated on compare errors. 26 Retries are unnecessary, although innocuous and therefore 27 allowable.) See Section 4.15, "Compare Operations," for a 28 more detailed description of this modifier's effects. 29 Express Request 30 Applicable to Non-Sequential commands. This modifier 31 requests that the controller ignore its normal 32 optimization policies in order to complete this command 33 as quickly as possible. The exact implementation of 34 express requests is controller dependent -- in general 35 the controller will complete some or all of its 36 outstanding commands before completing an express 37 request. 38 Use of express requests disables the normal controller 39 guarantees that ensure that all commands are serviced in 40 a timely manner. If express requests are repeatedly 41 issued, some or all other outstanding commands may time 42 out (i.e., never be completed). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-14 Command Messages 11 June 1992 1 Express requests do NOT override sequential command 2 execution guarantees. Some controllers may completely 3 ignore the express request modifier. The exact treatment 4 of express requests should be described in a controller's 5 functional specification. 6 Force Error 7 Applicable only to write commands directed to disk class 8 devices. Causes the data to be written with the forced 9 error indicator set, so that all attempts to read the 10 data will fail. The error will be preserved until the 11 next time the block is written. The forced errors 12 produced with this modifier shall be recognized by the 13 controller as deliberate and never reported to the error 14 log. Note that the data shall be written to the block so 15 as to be obtainable by subsequent READ commands, exactly 16 as if this modifier were not specified. The only 17 difference is whether subsequent READ commands will 18 return success or the forced error status code. 19 Suppress Error Correction 20 Suppresses error correction mechanisms, such as ECC 21 correction. Error recovery mechanisms, such as retries, 22 are not affected by this modifier. This modifier, in 23 effect, lowers the threshold at which an error is 24 considered to be uncorrectable. It typically lowers the 25 threshold to zero, although that is not required. Since 26 error correction is drive type dependent, the lowered 27 error correction threshold is also drive type dependent. 28 If a drive has several error correction mechanisms, it is 29 permissible for this modifier to suppress some and not 30 affect others. 31 Suppress Error Recovery 32 Suppresses most error recovery mechanisms, such as read 33 retries. Error correction mechanisms, such as ECC 34 correction, and some error recovery mechanisms, such as 35 seek retry, are not affected by this modifier. The exact 36 definition of which error recovery mechanisms are 37 suppressed and which are not affected is drive type 38 dependent. 39 Refer to Appendix A, "Opcode, Flag, and Offset Definitions," 40 Table A-2, "Command Modifiers" for the values assigned to all 41 command modifiers. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-15 Command Messages 11 June 1992 1 All modifiers that are not explicitly allowed for a command are 2 reserved, and shall be treated in accordance with the 3 requirements for reserved fields described in Section 5.2, 4 "Reserved and Undefined Fields." The only exception is that 5 certain modifiers (allowable on certain commands) are either 6 ignored or treated as reserved depending on whether or not a 7 controller supports certain optional MSCP functions. See Table 8 A-2 for complete details. Note that those modifiers are not 9 listed in the individual command descriptions. 10 5.4 End Messages 11 An MSCP server sends an end message to a class driver to report 12 completion of a command. Note that end messages are flow 13 controlled as described in Section 3.2, "Flow Control" and 14 associated subsections. 15 The generic end message format is as follows: 16 31 0 17 +--------------------------------+ 18 | command reference number | 19 +---------------+----------------+ 20 |sequence number| unit number | 21 +---------------+-------+--------+ 22 | status | flags | endcode| 23 +---------------+-------+--------+ 24 | | 25 / parameters / 26 / / 27 | | 28 +--------------------------------+ 29 The fields in the generic end message are as follows: 30 command reference number 31 unit number 32 Both of these fields are copied from the command message. 33 See Section 5.3, "Command Messages." 34 sequence number 35 This field depends on the state of the "error log 36 generated" flag in the "flags" field. If that flag is 37 set, this field contains the "sequence number" of the 38 LAST error log message that refers to this command -- 39 i.e., that contains this command's command reference 40 number. If that flag is clear, this field will be zero. 41 (Note that MSCP servers meeting certain requirements need *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-16 End Messages 11 June 1992 1 not implement error log sequence numbers. See Section 2 5.9, "Error Log Messages." Servers that meet those 3 requirements shall always return a zero in the sequence 4 number field.) This field allows the host to determine 5 when all error log messages for a particular command have 6 been received and when the command's context saved for 7 inclusion in the error log, if any, can be released. 8 Section 5.9, "Error Log Messages" provides complete 9 details regarding host and MSCP server error logging 10 operation. 11 endcode 12 Identifies this message as an end message and the type of 13 command (opcode) that this is an end message for. This 14 field implicitly specifies the length, format, and 15 interpretation of the parameters. 16 Normally the endcode is formed by adding the constant 17 (OP.END) to the command opcode (see Table A-1, "Control 18 Message Opcodes"). An exception is the Invalid Command 19 End Message (see "Invalid Command" status in Section 5.5, 20 "Status and Event Codes"). 21 flags 22 Bit flags, collectively called end flags, used to report 23 various conditions detected due to this command but not 24 directly related to success or failure. The following 25 flags are defined: 26 Allocation Failure 27 Set if the server was unable to allocate a new 28 "write history entry" in a History Log modified 29 write type command. Indicates that no "write 30 history entry" was generated for this command. 31 This condition is recorded in the Allocation 32 Failure Table in the controller. For more 33 details, see Section 6.19.3, "WRITE HISTORY 34 MANAGEMENT Command, Description," and the 35 descriptions of the History Log and Reuse Entry 36 modifiers in any write type command (WRITE, 37 ERASE, and DISK COPY DATA). 38 Bad Block Reported 39 Set if one or more bad blocks were detected and 40 the host is performing bad block replacement. 41 Indicates that the host should replace the bad *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-17 End Messages 11 June 1992 1 block identified in the "first bad block" field. 2 Note that this end flag is applicable only to 3 disk class devices. 4 Bad Blocks Unreported 5 Set if one or more bad blocks were detected and 6 not reported in the "first bad block" field. If 7 the "Bad Block Reported" flag is also set, this 8 indicates that two or more bad blocks were 9 detected, the host is performing bad block 10 replacement, and the "first bad block" field only 11 reports the first bad block in the transfer. If 12 the "Bad Block Reported" flag is clear, this 13 indicates that one or more bad blocks were 14 detected and that the controller either already 15 has or soon will replace them. Note that this 16 end flag is applicable only to disk class 17 devices. 18 Error Log Generated 19 Set if one or more error log messages were 20 generated that refer to this command -- i.e., 21 that contain this command's command reference 22 number. When set this flag signals the host to 23 save any command context that it wishes to 24 include in its error log until all error log 25 messages associated with the command have arrived 26 (see also "sequence number" field described 27 above). 28 History Logged 29 Set if the "write history log" contains a valid 30 "write history entry" for this command. See 31 Section 6.19.3, "WRITE HISTORY MANAGEMENT 32 Command, Description," for details of write 33 history logging. 34 Serious Exception 35 Set if an unrecoverable error or some other 36 unusual exception condition requires that the 37 host recognize the exception before additional 38 commands are processed. The host shall clear the 39 error before subsequent commands can be executed. 40 Note that this end flag is applicable only to 41 tape class devices. See Tape Mass Storage 42 Control Protocol Specification (TMSCP) for *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-18 End Messages 11 June 1992 1 complete details. 2 Refer to Appendix A, "Opcode, Flag, and Offset 3 Definitions," Table A-3, "End Message Flags" for the 4 values assigned to the defined flags. All other bits in 5 the "flags" field are reserved, and shall be treated in 6 accordance with the requirements for reserved fields 7 described in Section 5.2, "Reserved and Undefined 8 Fields." 9 status 10 The status field contains a status code that indicates 11 whether the operation was successfully completed or, if 12 it wasn't successful, what type of error occurred (see 13 also Section 5.5, "Status and Event Codes"). Note that 14 recoverable errors are reported as successful completion 15 of the command. All errors, whether recoverable or not, 16 are reported in a separate error log message if they 17 should be logged (see Section 5.9, "Error Log Messages" 18 for more detail). 19 Note that if several errors occur in a nontransfer 20 operation, the error that is reported is controller 21 dependent unless the individual command description 22 states otherwise. See the "status" field description in 23 Section 5.4.1, "Transfer Command End Message Format" for 24 specifics of multiple error handling for transfer 25 commands. 26 Chapter 6, "Minimal MSCP Command Set" describes the operation, 27 command message format, and end message format of the various 28 commands required to be supported by an MSCP disk controller. 29 The following section describes the end message format common to 30 many data transfer commands. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-19 End Messages 11 June 1992 1 5.4.1 Transfer Command End Message Format 2 Although the parameters and their layout are command (endcode) 3 dependent, many commands perform data transfers and thus return 4 similar sets of parameters. Therefore data transfer related end 5 messages are typically laid out as follows: 6 31 0 7 +--------------------------------+ 8 | command reference number | 9 +---------------+----------------+ 10 |sequence number| unit number | 11 +---------------+-------+--------+ 12 | status | flags |endcode | 13 +---------------+-------+--------+ 14 | byte count | 15 +--------------------------------+ 16 | | 17 +--- ---+ 18 | undefined | 19 +--- ---+ 20 | | 21 +--------------------------------+ 22 | first bad block | 23 +--------------------------------+ 24 The fields in the transfer command end message are as follows: 25 command reference number 26 unit number 27 sequence number 28 endcode 29 flags 30 See Section 5.4, "End Messages." 31 status 32 If several errors occur in a transfer operation, the 33 status code reports the first error starting from the 34 beginning of the transfer (i.e., the lowest byte count or 35 lowest logical block number). The only exception is 36 transfer commands that include a compare operation (i.e., 37 read-compare and write-compare operations); errors in the 38 original transfer may take precedence over errors during 39 the compare operation. 40 If a "Forced Error" and some other error occur at the 41 same point (same byte count or logical block number) 42 within a transfer operation, the other error shall be *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-20 End Messages 11 June 1992 1 reported. If a "Compare Error" and some other error that 2 is not a "Forced Error" occur at the same point within a 3 transfer operation, the other error shall be reported. 4 If a "Forced Error" and a "Compare Error" both occur at 5 the same point, and no other error occurs at that point, 6 the "Compare Error" shall be reported. Otherwise, which 7 error of multiple errors occurring at the same point 8 should be reported is controller dependent. An 9 alternative way of stating this is that "Forced Errors" 10 are the error of last resort and that "Compare Errors" 11 | are the error of second to last resort. See also 12 | "Section 5.5, "Status and Event Codes." 13 byte count 14 In transfer command end messages, the number of bytes 15 successfully transferred, counting from the start of the 16 transfer to the first error (i.e., the lowest byte count 17 or lowest logical block number with an error). Data that 18 follows the first error is not counted, even if 19 transferred successfully. The only exception is transfer 20 commands that include a compare operation (i.e., 21 read-compare and write-compare operations); errors in the 22 original transfer may take precedence over errors during 23 the compare operation. 24 The error identified by "status" must have actually 25 occurred at the position identified by "byte count." The 26 controller must have successfully transferred all data up 27 to that point. If Data Error (subcode "Forced Error") 28 status is returned for a READ command (addressed to a 29 disk class device), the controller must have also 30 transferred all the data contained in the block marked 31 with forced error. Beyond this point the state of the 32 transfer is undefined. None of the transfer may have 33 been performed or attempted, all of it may have been 34 attempted (with unknown success), or some parts may have 35 been attempted and others not. 36 Again, the only exception to this is transfer commands 37 that include a compare operation. Such a command makes 38 two passes over the data; one for the original transfer 39 and another for the compare operation. For most errors, 40 there is no way to determine in which pass the error was 41 detected. Therefore the only guarantee is that the 42 original transfer was performed up to the point 43 identified by "byte count" without detecting any errors. 44 The compare operation may or may not have been performed 45 up to that point. If a "Compare Error" is reported, then 46 both the original transfer and the compare operation have *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-21 End Messages 11 June 1992 1 been successfully performed up to the point identified by 2 "byte count." The state of both the original transfer 3 and the compare operation after that point, however, is 4 undefined. This implies that the compare pass of a 5 transfer command that includes a compare operation may be 6 done for the entire transfer as a unit, block by block, 7 or anywhere in between. 8 For disk class devices, the granularity of the byte count 9 on errors (i.e., the resolution with which the point of 10 error is identified) need not be any smaller than the 11 volume's block size. That is, the byte count need only 12 identify the block in which the error occurred, rather 13 than the exact word or byte. In particular, the byte 14 count returned with such errors as "Compare Errors" and 15 "Host Buffer Access Errors" need only identify the block 16 in which the error occurred, rather than the exact word 17 or byte. Note that a block is identified by the number 18 of the first byte in the block. Controllers may 19 optionally provide finer granularity for the byte count 20 field on errors. If an error is not reported, 21 controllers shall return the exact byte count that was in 22 the command message. 23 For tape class devices, the granularity of the byte count 24 on errors shall be either one word (two bytes) or one 25 byte. If an error is not reported, controllers shall 26 return the exact byte count that was transferred. For 27 host buffer access details see Section 4.11, "Host Buffer 28 Access." 29 first bad block 30 In disk transfer command end messages, the logical block 31 number of the first bad block (i.e., the bad block with 32 the lowest logical block number) detected during the 33 transfer that the host should replace. Only valid if the 34 "Bad Block Reported" flag is set. Undefined (garbage) if 35 the "Bad Block Reported" flag is clear. 36 5.5 Status And Event Codes 37 | Status and Event codes are essentially identical except for the 38 | manner in which they are returned. The "status code" field in 39 | returned in end messages and is used to report whether an 40 | operation was successfully completed or, if it was not 41 | successfully completed, what type of error occurred. The "event 42 | code" field is returned in error log messages and has the 43 | identical structure and encoding of a status code, but identifies 44 | the specific error or event being reported by the error log *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-22 Status And Event Codes 11 June 1992 1 | message. Errors that are reported in both an end message and an 2 | error log message use identical values for the "status code" and 3 | "event code" fields. The same value may not be used to report 4 | one type of event as a "status code" and a different type of 5 | event as an "event code". 6 | There are, however, certain codes that are used as "status only" 7 | codes and others used as "event only" codes. For example, if a 8 | command is issued to a unit that is Unit-Offline, the result is 9 | reported as a "status only" code. It is not necessary to report 10 | this information in an error log; it is up to the program that 11 | initiated the command to take the appropriate action. If a WRITE 12 | command is issued and a bad block is encountered and is 13 | successfully replaced, the end message for the command will 14 | return the appropriate status outcome, in addition to setting the 15 | flags for bad block reported and error log message generated. 16 | The Bad Block Replacement Attempted event code will never be 17 | returned as a status code; it will only be returned as an event 18 | code in an error log message. 19 The "status code" and the "event code" fields are divided into a 20 5-bit major status code and an 11-bit status and/or event subcode 21 arranged as follows: 22 15 0 23 +-----------------+---------+ 24 | subcode | code | 25 +-----------------+---------+ 26 The 5-bit major status code conveys the status information that 27 hosts need for normal operation. Therefore the major status 28 codes are a formal part of MSCP. All controllers shall return 29 the same major status codes for similar situations. 30 The 11-bit subcode exists to specify the exact error or unusual 31 situation encountered with very fine detail. As such it is 32 primarily used for diagnostic purposes, and hosts should not need 33 to examine it during normal operation. 34 Subcodes related to protocol or state errors are a formal part of 35 MSCP. All controllers shall return the same subcodes for 36 protocol or state errors. These subcodes are generally bit 37 flags, allowing several causes of the major status code to be 38 reported. 39 Subcodes related to controller and/or drive errors, however, 40 shall be allowed to vary from one controller or drive to another. 41 There is no requirement that the same subcodes be returned for 42 similar drive or controller errors. These subcodes are generally 43 specific values, corresponding to one specific event or error. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-23 Status And Event Codes 11 June 1992 1 Each subcode shall have the same meaning whenever it is used. It 2 is the use of a subcode that may vary (i.e., whether or not a 3 specific controller returns that subcode), not its meaning. The 4 defined subcodes are listed in Appendix B, "Status and Event Code 5 Definitions." This list may expand (via an ECO to MSCP) whenever 6 a new drive or controller type is introduced. 7 The major status codes that may be returned in end message 8 "status code" fields are listed below along with the general use 9 made of subcodes. The actual subcodes used are listed in 10 Appendix B, "Status and Event Code Definitions." Those subcodes 11 that are a formal part of MSCP are also listed in the 12 descriptions of the commands that may return them. 13 Success 14 The command was successfully completed. This status code 15 may also be returned, for some commands, if the intended 16 effect of the command has already been accomplished 17 (e.g., requesting a drive that isn't spinning to 18 spin-down). The subcode consists of bit flags used to 19 report various "alternate" forms of success. See the 20 individual command descriptions for details. 21 The status code value associated with "Success" is, by 22 definition, zero. Subcode value zero (i.e., no subcode 23 bits set) is "Normal" success, and implies normal 24 completion of a command. One subcode bit, the "Duplicate 25 Unit Number" bit, is common to many commands. This bit, 26 when set, implies that the unit is "Unit-Online" and the 27 command succeeded, but that the unit has a duplicate unit 28 number. The unit will become "Unit-Offline," due to the 29 duplicate unit number, as soon as it ceases to be 30 "Unit-Online." Other "Success" subcode bits are unique 31 to a particular command, and are described under the 32 individual command descriptions. 33 Invalid Command 34 Controllers detect and report two different types of 35 invalid command errors. 36 The first type is called a protocol error. The 37 controller reports a protocol error if during initial 38 command message validation it finds: 1) a message format 39 violation, 2) an MSCP version number mismatch, or 3) that 40 a field contains a value that specifies an undefined 41 operation. 42 The following are MSCP protocol errors: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-24 Status And Event Codes 11 June 1992 1 Invalid Message Length 2 The command message is too short to contain the 3 parameters required by the command's opcode. 4 Invalid Modifiers 5 An undefined modifier bit is set or a modifier 6 that is defined but not supported by that 7 controller is set. See the descriptions of the 8 History Log and Reuse Entry modifiers in the DISK 9 COPY DATA, ERASE, and WRITE Commands, Sections 10 6.7.1, 6.9.1, and 6.18.1. 11 Invalid MSCP Version 12 The "MSCP version" field of a SET CONTROLLER 13 CHARACTERISTICS command is nonzero (see Section 14 6.16.1, "SET CONTROLLER CHARACTERISTICS Command, 15 Command Message Format"). 16 Invalid Opcode 17 See "opcode" field in Section 5.3, "Command 18 Messages" for possible causes. 19 Invalid Operation 20 The "operation" field of an ACCESS NONVOLATILE 21 MEMORY command or WRITE HISTORY MANAGEMENT 22 command contains an illegal value (see Section 23 7.3.1, "Multihost ACCESS NONVOLATILE MEMORY 24 Command, Command Message Format" and Section 25 6.19.1, "WRITE HISTORY MANAGEMENT Command, 26 Command Message Format"). 27 {reserved field violations} 28 A "reserved" field in the command message 29 contains a nonzero value. Note that "reserved" 30 field checking is optional (see Section 5.2, 31 "Reserved and Undefined Fields"). 32 Note also that modifiers not explicitly allowed 33 for a command received by the server and any 34 undefined controller flag and unit flag bits are 35 considered to be "reserved" fields. 36 The second type is a parameter error. After determining 37 through initial command message validation that the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-25 Status And Event Codes 11 June 1992 1 command message has a well defined meaning, the 2 controller reports a parameter error if some parameter is 3 found to be outside the range allowed. Note that some 4 parameter errors are detected during follow-on command 5 message validation before command execution begins, while 6 others may be detected afterwards. 7 The following are parameter errors: 8 Invalid Byte Count 9 See "byte count" field in Section 5.3.1, 10 "Transfer Command Message Format" for possible 11 causes. Log modifier in the ERASE and WRITE 12 Commands, Sections 6.9.1 and 6.18.1. 13 Invalid CRN 14 A value of zero was supplied in the crn 15 (connection reference number) field of a SET 16 CONTROLLER CHARACTERISTICS or TERMINATE CLASS 17 DRIVER/SERVER CONNECTION command message. 18 Invalid Display Text 19 The specified display text is invalid or not 20 implemented for the specified display item and 21 mode. For more information, see Section 6.8.3, 22 "DISPLAY Command, Description." 23 Invalid Entry Locator 24 The value specified in the "entloc (entry 25 locator)" field of a WRITE HISTORY MANAGEMENT, 26 ERASE, WRITE, or DISK COPY DATA command is not 27 within the limits of the server's "write history 28 entry" set. See Section 6.19.3, "WRITE HISTORY 29 MANAGEMENT Command, Description" for more detail. 30 Invalid Entry Id 31 The value specified in the "entry id" field of a 32 WRITE HISTORY MANAGEMENT, ERASE, WRITE, or DISK 33 COPY DATA command does not match the value in the 34 "write history entry" identified by the entry 35 locator or the host supplied a value of FFFF 36 (hex) in the "entry id" field of a History Log 37 modified write type command. See Section 6.19.3, 38 "WRITE HISTORY MANAGEMENT Command, Description" 39 for more detail. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-26 Status And Event Codes 11 June 1992 1 Invalid Item 2 The specified display item code is not 3 implemented and the "Must Be Implemented" 4 modifier was set. For more information, see 5 Section 6.8.3, "DISPLAY Command, Description." 6 Invalid Length 7 The "length" field of an ACCESS NONVOLATILE 8 MEMORY command contains an odd value and the 9 "operation" field requested a "Test and Set" 10 operation (see Section 7.3.1, "Multihost ACCESS 11 NONVOLATILE MEMORY Command, Command Message 12 Format"). 13 Invalid Logical Block Count 14 Invalid Src Unit Number 15 Invalid Source Unit Identifier 16 Invalid Destination LBN 17 Invalid Source LBN 18 Invalid Source Unit's Storage Subsystem Port Address 19 Invalid Source Unit's Storage Subsystem System 20 Address 21 See Section 6.7.1, "DISK COPY DATA Command, 22 Command Message Format" for descriptions of these 23 command message fields. 24 Invalid Logical Block Number 25 See "logical block number" field in Section 26 5.3.1, "Transfer Command Message Format" for 27 possible causes. 28 Invalid Mode 29 The specified display mode is not implemented for 30 the specified display item and the "Must Be 31 Implemented" modifier was set. For more 32 information, see Section 6.8.3, "DISPLAY Command, 33 Description." 34 Invalid Replacement Block Number 35 See Section 6.15.2, "REPLACE Command, End Message 36 Format" for possible causes. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-27 Status And Event Codes 11 June 1992 1 Invalid Unit Flags 2 The the host-settable unit flags specified in the 3 "unit flags" field of an ONLINE command message 4 issued to a unit that is already "Unit-Online" 5 are different from those already in effect on the 6 unit (see Sections 6.13, "ONLINE Command" and 7 7.7, "Multihost ONLINE Command"). 8 Note that an unknown unit number does not constitute an 9 invalid parameter or command. Unknown unit numbers are 10 treated as if the unit were "Unit-Offline." 11 In order for hosts to clearly distinguish the two types 12 of invalid commands controllers use two different end 13 message formats. 14 Protocol errors are reported via the Invalid Command End 15 Message. The Invalid Command End Message is largely an 16 image of the invalid command message that was received 17 from the host. In order to construct the Invalid Command 18 End Message, the controller makes the following changes 19 to the invalid command message that it received: 20 1. The controller stores the constant (OP.END), 21 defined in Appendix A, "Opcode, Flag, and Offset 22 Definitions," Table A-1, "Control Message 23 Opcodes," in the "endcode" field, in order to 24 flag this as an Invalid Command End Message. 25 (Note that the command opcode is not added to 26 OP.END.) 27 2. The controller may, at its option, either copy 28 the end message "flags" field from the 29 corresponding field in the invalid command or 30 else clear the end message "flags" field. 31 3. The controller stores the "Invalid Command" 32 status code with an appropriate subcode in the 33 end message "status" field. The subcode is set 34 equal to the byte offset, from the start of the 35 command message, of the field in error (any one 36 field, at the controller's option, if several are 37 in error). Multibyte fields are identified by 38 the offset to their lowest byte. Single byte 39 fields positioned at an odd offset may be 40 identified, at the controller's option, by either 41 their actual offset or their offset minus one. 42 That is, offsets may be truncated to an even 43 value. Subcode zero is used to report that the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-28 Status And Event Codes 11 June 1992 1 command message was too short to contain the 2 parameters required by the command's opcode. 3 Note that any value is valid for the field at 4 offset zero, the "command reference number." 5 4. The controller may optionally truncate the 6 parameter fields ("echoed command parameters") to 7 some length convenient for the controller. 8 Controllers should try to echo as much of the 9 parameters as possible. 10 The contents of any field copied from the invalid command 11 are undefined if the command message was too short to 12 contain that field. This primarily applies to the 13 "command reference number" and "unit number" fields. 14 Note that the controller may, at its option, enter the 15 "Controller-Available" state relative to the issuing host 16 class driver after it returns the Invalid Command End 17 Message (see Section 4.1, "Controller States"). 18 Parameter errors are reported via the invalid command's 19 normal (i.e., opcode dependent, see "endcode" field in 20 Section 5.4, "End Messages") end message. The "status" 21 field is set equal to the "Invalid Command" status code, 22 with the subcode set equal to the byte offset, relative 23 to the start of the command message, of the parameter 24 field in error. Multibyte fields are identified by the 25 offset to their lowest byte. All other fields (byte 26 count, unit characteristics, etc.) reflect the state of 27 the execution of the command up to the point the invalid 28 parameter was detected. 29 Command Aborted 30 The command was aborted by an ABORT command. The end 31 message for the aborted command (i.e., the end message 32 containing the "Command Aborted" status code) has the 33 normal format for the command and all fields are valid. 34 In particular, the "byte count" field identifies how far 35 a transfer command was completed before it was aborted. 36 The status of the transfer beyond the returned byte count 37 is undefined. Subcodes are not used. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-29 Status And Event Codes 11 June 1992 1 Unit-Offline 2 The unit identified by the "unit number" field of the end 3 message is in the "Unit-Offline" state. The subcode 4 consists of bit flags that indicate why the unit is 5 "Unit-Offline." Note that there may be several reasons 6 for the unit being "Unit-Offline." If the subcode is 7 zero, it implies that the unit is unknown -- i.e., the 8 controller knows of no unit with the specified unit 9 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 subcode is 13 zero, except when "Exclusive Access" of the unit was 14 denied. In that case the "Already In Use" subcode is 15 returned (see the descriptions of the AVAILABLE, ONLINE, 16 and SET UNIT CHARACTERISTICS commands in Chapter 7, 17 "Multihost Support" for more detail). 18 Media Format Error 19 Only returned by the ONLINE command for disk class 20 devices. The volume mounted on the unit appears to be 21 formatted incorrectly, so that it must be reformatted 22 (and all data lost) before it may be used. This error is 23 also returned if the volume is formatted with 576 byte 24 sectors and the controller only supports 512 byte 25 sectors. Note that the volume may only "appear" to be 26 formatted incorrectly; the typical cause of this error is 27 a fault in the drive's read/write electronics. If this 28 is the case, the volume can usually be successfully 29 accessed on another drive. 30 Whenever they return this error code controllers shall 31 treat the unit as if an AVAILABLE command with the 32 "Spin-down" modifier set had been issued for it. The 33 unit is therefore always in the "Unit-Available" state 34 with AVAILABLE attention messages suppressed until a 35 human operator changes the volume or spins-up the unit. 36 The subcode reports which integrity check the volume 37 failed; it is volume format, and therefore drive type, 38 dependent. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-30 Status And Event Codes 11 June 1992 1 Write Protected 2 The unit identified by the "unit number" field of the end 3 message is write protected and the command required that 4 data be written onto the drive. The subcode consists of 5 bit flags indicating the reasons why the unit is write 6 protected. 7 Compare Error 8 A COMPARE HOST DATA command, a read compare operation, or 9 a write compare operation found different data in the 10 host buffer and the unit identified by the "unit number" 11 field of the end message. The subcode is always zero. 12 Data Error 13 Invalid or uncorrectable data was obtained from a drive, 14 as determined by internal error detecting or correcting 15 codes. The subcode is used to report the exact error 16 detected. Subcode zero is used for "Forced Errors." All 17 errors caused by the "Force Error" modifier shall be 18 reported with subcode zero. 19 Host Buffer Access Error 20 The controller encountered an error when attempting to 21 access a buffer in host memory. The subcode is used to 22 report the exact error encountered. This status code is 23 also returned whenever the command's buffer descriptor or 24 byte count violate any communications mechanism dependent 25 restrictions. 26 Note that this status code is NOT used to report errors 27 encountered when transferring command, end, attention, or 28 error log messages between the controller and a host. 29 Such errors are reported by terminating the connection 30 between the class driver and MSCP server. The mechanism 31 for reporting such errors to the host's error log is 32 communications mechanism dependent. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-31 Status And Event Codes 11 June 1992 1 Controller Error 2 The controller encountered an internal controller error. 3 The subcode is used to report the exact error 4 encountered. An internal controller error is reported as 5 a "Controller Error" if and only if the controller has 6 reasonable grounds to trust its sanity and expects to 7 complete, either successfully or with an appropriate 8 error status code, all of its outstanding commands. All 9 more severe controller errors are reported by terminating 10 the connection between the controller's MSCP server and 11 the host class driver. This is in addition, of course, 12 to attempting to generate an error log message. 13 Subcode zero of this status code is reserved for host or 14 non-MSCP entity (e.g., a controller's port driver) 15 detected command timeouts. It is never generated by an 16 MSCP server. All other subcodes are controller 17 dependent. 18 Note that some controller errors may be reported using 19 other error codes if an internal controller error causes 20 the controller to misdiagnose the error. 21 Drive Error 22 The controller discovered an error within a drive. Such 23 errors are typically, but not always, mechanical in 24 nature, since most nonmechanical errors are reported as 25 "Data Errors." The subcode is used to report the exact 26 error encountered. 27 In many cases a "Drive Error" will indicate that the unit 28 is broken or inoperative. If this occurs, the "Drive 29 Error" should be reported once and the unit should 30 subsequently be reported as being "Unit-Offline" due to 31 being inoperative. 32 Invalid Parameter 33 The controller encountered an invalid parameter value for 34 a parameter that is not passed directly in the command 35 message. Invalid values in fields of a command message 36 are reported with the "Invalid Command" status code. 37 "Invalid Parameter" typically reports an invalid value in 38 a field in a host-supplied buffer. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-32 Status And Event Codes 11 June 1992 1 The status codes that may be returned for a specific command are 2 command (opcode) dependent. The status codes that may be 3 returned for each command and any special meaning that they have 4 specific to the command are listed in the command descriptions 5 contained in Chapter 6, "Minimal MSCP Command Set" and Chapter 7, 6 "Multihost Support." Note that the format of a command's end 7 message is solely determined by its opcode. The status code 8 returned in the end message does not affect the end message's 9 format. The only exception is the Invalid Command End Message 10 (see "Invalid Command" status above), which contains a special 11 endcode. 12 | "Event Only" event codes and subcodes shall only be used in error 13 | log or informational messages and shall never be used as status 14 | codes reported in end messages. The currently defined "Event 15 | Only" event codes are: 16 | Bad Block Replacement Attempted 17 | This event code is used after every attempt (by the 18 | controller or host) to replace a bad block, regardless of 19 | the success or failure of that attempt (see Section 20 | 5.8.7, "BAD BLOCK REPLACEMENT ATTEMPT Error Log Format"). 21 | For details of bad block replacement, see Chapter 8, 22 | "Controller Initiated Bad Block Replacement" and the 23 | Digital Storage Architecture Disk Format (DSDF) 24 | specification. 25 | Informational Log 26 | Informational Log messages are used by the server to 27 | report such things as statistics or error log summary 28 | information that may have been compiled in the device. 29 | In all error log messages with this event code, the 30 | "Informational" error log message flag (see Section 31 | 5.9.2, "Generic Error Log Message Format") should 32 | normally be set. 33 5.6 Controller Flags 34 Controllers maintain a set of bit flags, collectively known as 35 the "controller flags," which represent the controller's 36 operating characteristics. Two different types of controller 37 flags are used to accommodate two different types of controller 38 characteristics. Host-settable controller flags allow hosts to 39 enable or disable the host selectable operating characteristics 40 (e.g., Enable Attention Messages) supported by all controllers. 41 Controllers use non-host-settable controller flags to indicate 42 the presence or absence of implementation dependent optional 43 functions (e.g., Multihost Support). The currently defined *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-33 Controller Flags 11 June 1992 1 controller flags are described later in this section. 2 The SET CONTROLLER CHARACTERISTICS command is used to modify the 3 host-settable controller flags according to the value supplied in 4 the "controller flags" field of the command message. If a 5 host-settable flag is set the controller enables the 6 corresponding host selectable operating characteristic. A clear 7 flag causes the controller to disable it. Controllers shall 8 always ignore the values supplied for the non-host-settable 9 controller flags. All host-settable controller flags are, by 10 default, clear (i.e., all host selectable operating 11 characteristics are disabled) whenever a class driver first 12 becomes "Controller-Online" to an MSCP server. 13 The controller dependent values of the non-host-settable 14 controller flags, as well as the current values of the 15 host-settable controller flags, are returned in the "controller 16 flags" field of the SET CONTROLLER CHARACTERISTICS command's end 17 message. A controller shall set only those non-host-settable 18 controller flags for the corresponding optional functions it 19 supports, if any. 20 Controllers that provide Multihost Support shall maintain, and 21 operate according to the setting of, a separate set of 22 host-settable controller flags for each host class driver/MSCP 23 server connection established. Each class driver is expressly 24 permitted to specify different settings for the host-settable 25 controller flags and as a result realize different controller 26 operation. The non-host-settable controller flags remain fixed, 27 and are therefore common to all class drivers of the same device 28 class. 29 The host-settable controller flags are as follows: 30 Enable Attention Messages 31 When this flag is set the controller shall send attention 32 messages to this host. If this flag is clear the 33 controller discards attention messages. Note that this 34 flag is applicable to all attention messages, regardless 35 of type. 36 Enable Miscellaneous Error Log Messages 37 When this flag is set the controller shall send error log 38 messages that do not relate to a specific command to this 39 host. If this flag is clear the controller discards any 40 such error logs. 41 Enable Other Hosts' Error Log Messages *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-34 Controller Flags 11 June 1992 1 When this flag is set error log messages that relate to 2 commands issued by other hosts should be sent to this 3 host. Controllers that provide Multihost Support shall 4 implement this characteristic separately for each host 5 class driver connected. Even though this operation is 6 only useful in a multihost environment, controllers that 7 do not provide Multihost Support shall still honor this 8 flag. That is, the flag may not be treated as reserved 9 and the current state as set by the host shall be 10 returned in the end message field. 11 Enable This Host's Error Log Messages 12 When this flag is set error log messages that relate to 13 commands issued by this host should be sent to this host. 14 If this flag is clear the controller discards those error 15 logs, except in a multihost environment where another 16 host has set the "Enable Other Hosts' Error Log Messages" 17 flag. 18 The non-host-settable controller flags are as follows: 19 Controller Initiated Bad Block Replacement 20 This flag shall be set if and only if the controller 21 supports Controller Initiated Bad Block Replacement on 22 all disk drives that can be connected to the controller. 23 If this flag is set the host will never have to perform 24 bad block replacement for disks accessed via this 25 controller. Note that controllers may also support 26 Controller Initiated Bad Block Replacement on certain 27 individual disk drives and not others. In that case this 28 flag shall be returned clear; the setting of the 29 Controller Initiated Bad Block Replacement unit flag 30 (described in Section 5.7, "Unit Flags") determines 31 whether or not the host must perform bad block 32 replacement on a particular disk drive. Note also that 33 that unit flag shall always be returned set if this flag 34 is returned set. 35 Support of Controller Initiated Bad Block Replacement, 36 either on a single disk drive or all disk drives, is a 37 controller implementation dependent option. See Chapter 38 8, "Controller Initiated Bad Block Replacement" for 39 complete details. 40 Local Disk Copy Data 41 This flag shall be returned set if and only if the 42 controller supports interdevice transfer of data, via the 43 DISK COPY DATA command (see Section 6.7), between all the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-35 Controller Flags 11 June 1992 1 disk drives connected to the controller. 2 Support of Local Disk Copy Data is an implementation 3 dependent option. Local Disk Copy Data may be 4 implemented by controllers that provide Multihost Support 5 as well as those that do not. However, for controllers 6 that provide Multihost Support, support of Remote Disk 7 Copy Data (see the Remote Disk Copy Data flag below) is 8 preferred. 9 Controllers that implement Local Disk Copy Data shall 10 also implement Controller Initiated Bad Block Replacement 11 on all disk drives connected to them (see Controller 12 Initiated Bad Block Replacement flag above). 13 Multihost Support 14 This flag shall be returned set if and only if the 15 controller supports simultaneous access, by multiple 16 hosts, to all drives (disk and tape) connected to the 17 controller. See Chapter 7, "Multihost Support." 18 Remote Disk Copy Data 19 This flag shall be returned set if and only if the 20 controller supports interdevice transfer of data, via the 21 DISK COPY DATA command (see Section 6.7), between disk 22 drives connected to itself and disk drives connected to 23 another storage subsystem that is connected to the same 24 communications mechanism. 25 Support of Remote Disk Copy Data is an implementation 26 dependent option. Remote Disk Copy Data can only be 27 implemented by controllers that also provide Multihost 28 Support. 29 Controllers that implement Remote Disk Copy Data shall 30 also implement Local Disk Copy Data (see Local Disk Copy 31 Data flag above) and Controller Initiated Bad Block 32 Replacement (see Controller Initiated Bad Block 33 Replacement flag above) on all disk drives connected to 34 them. 35 Restricted DISK COPY DATA Operations 36 This flag shall be returned set if and only if the 37 controller does not support any of: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-36 Controller Flags 11 June 1992 1 o Local DISK COPY DATA between units with unlike 2 geometries 3 o Local DISK COPY DATA where the source and destination 4 LBNs differ 5 o DISK COPY DATA where the source and destination are 6 the same unit 7 Note that controllers either support all of the above 8 operations and return this flag clear or support none of 9 these options and return the flag set. 10 Write History Logging Support 11 This flag shall be returned set if and only if the 12 controller supports "write history logging" as described 13 in Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 14 Description." "Write history logging" was defined 15 primarily for the purpose of assisting in the operation 16 of host based volume shadowing implementations. Note 17 that Write History Logging support includes support of 18 the TERMINATE CLASS DRIVER/SERVER CONNECTION command. 19 576 Byte Sectors 20 This flag shall be set if and only if the controller 21 supports disks formatted with 576 byte sectors as well as 22 disks formatted with 512 byte sectors. Note that all 23 controllers that support disk class devices must support 24 disks formatted with 512 byte sectors. 25 Refer to Appendix A, "Opcode, Flag, and Offset Definitions," 26 Table A-4, "Controller Flags" for the values assigned to the 27 currently defined host-settable and non-host-settable controller 28 flags. Those bits in the "controller flags" field that are not 29 defined as controller flags are reserved, and shall be treated in 30 accordance with the requirements for reserved fields described in 31 Section 5.2, "Reserved and Undefined Fields." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-37 Unit Flags 11 June 1992 1 5.7 Unit Flags 2 For each unit connected to a controller, the controller maintains 3 a set of bit flags, collectively known as the "unit flags," which 4 represent the unit's operating characteristics. Two different 5 types of unit flags are used to accommodate two different types 6 of unit characteristics. Host-settable unit flags allow hosts to 7 enable or disable certain host selectable operating 8 characteristics (e.g., Compare Reads). The non-host-settable 9 unit flags are used to indicate certain physical or logical 10 characteristics (e.g., 576 Byte Sectors, Write Protect) as well 11 as the presence or absence of certain controller implementation 12 dependent optional functions (e.g., Controller Initiated Bad 13 Block Replacement). The currently defined unit flags are 14 described later in this section. Except as noted in those 15 descriptions all controllers shall fully support all 16 non-host-settable unit flags on all units. 17 The ONLINE and SET UNIT CHARACTERISTICS commands are used to 18 modify the host-settable unit flags for the unit identified in 19 the "unit" field of the command message, according to the value 20 supplied in the "unit flags" field of the command message. If a 21 host-settable unit flag is set the controller enables the 22 corresponding host selectable operating characteristic for the 23 unit. A clear flag causes the controller to disable it. Note 24 that the state of the unit (Offline, Available, or Online) when 25 the command is received affects the setting or clearing of the 26 unit flags. See the descriptions of the ONLINE and SET UNIT 27 CHARACTERISTICS commands in Chapters 6, "Minimal MSCP Command 28 Set" and 7, "Multihost Support" for complete details. Except as 29 noted in the individual flag descriptions below, controllers 30 shall ignore the values supplied for the non-host-settable unit 31 flags. 32 The non-host-settable unit flags, as well as the current values 33 of the host-settable unit flags, are returned in the "unit flags" 34 field of the ONLINE, GET UNIT STATUS, and SET UNIT 35 CHARACTERISTICS command end messages and the AVAILABLE Attention 36 message. Many unit flags, including all host-settable unit 37 flags, are only valid when the unit is "Unit-Online." The values 38 returned for such unit flags are undefined if the unit is 39 "Unit-Offline" or "Unit-Available." A few non-host-settable unit 40 flags are valid when the unit is "Unit-Available" and during 41 certain "Unit-Offline" substates. These flags are identified in 42 the individual flag descriptions below. 43 Controllers that provide Multihost Support maintain only one set 44 of host-settable unit flags for a particular unit regardless of 45 the number of hosts (class drivers) that have brought the unit 46 into the "Unit-Online" state. The unit will operate in an *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-38 Unit Flags 11 June 1992 1 identical manner (according to the setting of the host-settable 2 unit flags) for each host that has brought the unit 3 "Unit-Online." Any host may alter the setting of the 4 host-settable unit flags (for itself and all others) only via the 5 SET UNIT CHARACTERISTICS command and only after bringing the unit 6 "Unit-Online." Attempts to change the host-settable unit flags 7 from their current setting via an ONLINE command (regardless of 8 whether the unit was already "Unit-Online" to the issuing host) 9 will cause the ONLINE command to be rejected as an "Invalid 10 Command" ("invalid unit flag" parameter error. See "Invalid 11 Command" status in Section 5.5, "Status and Event Codes"). 12 The unit characteristics flags are as follows: 13 Compare Reads 14 A host-settable characteristic; set if all read transfers 15 should be verified with a compare operation. Equivalent 16 to specifying the "Compare" modifier on all READ 17 commands. See Section 4.15, "Compare Operations" for 18 complete details. 19 Compare Writes 20 A host-settable characteristic; set if all write 21 transfers should be verified with a compare operation. 22 Equivalent to specifying the "Compare" modifier on all 23 WRITE commands. See Section 4.15, "Compare Operations" 24 for complete details. 25 Controller Initiated Bad Block Replacement 26 A non-host-settable characteristic; set if the controller 27 will perform bad block replacement for this disk drive 28 (unit), clear if the host must perform bad block 29 replacement for this disk drive. Note that controllers 30 may support Controller Initiated Bad Block Replacement on 31 all or some disk drives connected to it. If Controller 32 Initiated Bad Block Replacement is provided for all disk 33 drives this flag and the Controller Initiated Bad Block 34 Replacement controller flag (described in Section 5.6, 35 "Controller Flags") shall both be set. 36 Note that a host disk class driver shall check if the 37 "Controller Initiated Bad Block Replacement" unit flag is 38 set or clear after bringing a unit "Unit-Online." If it 39 is clear (implying that the host is performing bad block 40 replacement), then the class driver shall invoke a 41 process that will access the unit's Replacement Control 42 Table to determine if a bad block replacement operation *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-39 Unit Flags 11 June 1992 1 has been partially performed or if the unit must be write 2 protected. The details of this check and its 3 consequences are described in the Digital Storage 4 Architecture Disk Format specification (DSDF) in the 5 section on "Host Initiated Bad Block Replacement." 6 Controllers that support Controller Initiated Bad Block 7 Replacement perform these checks themselves. 8 See Chapter 8, "Controller Initiated Bad Block 9 Replacement" for complete details. 10 Exclusive Access 11 A non-host-settable characteristic; set if this unit is 12 under the "Exclusive Access" of a particular host. That 13 is, the unit although in a multihost environment and 14 normally accessible by multiple hosts is now only 15 accessible by the one host that requested and was granted 16 exclusive access of the unit via an AVAILABLE, ONLINE or 17 SET UNIT CHARACTERISTICS command. See the descriptions 18 of those commands in Chapter 7, "Multihost Support." 19 This characteristic shall be fully supported by 20 controllers that provide Multihost Support. 21 Removable Media 22 A non-host-settable characteristic; set if this unit has 23 removable media. 24 This characteristic shall be fully supported by all 25 controllers that support units with removable media. 26 Valid whenever the controller can determine the unit's 27 characteristics. See the descriptions of the GET UNIT 28 STATUS, ONLINE, and SET UNIT CHARACTERISTICS command end 29 messages contained in Chapters 6, "Minimal MSCP Command 30 Set" and 7, "Multihost Support" for complete details. 31 Write History Logging Support 32 A non-host-settable characteristic; shall be returned set 33 if and only if the controller supports "write history 34 logging" for this unit as described in Section 6.19.3, 35 "WRITE HISTORY MANAGEMENT Command, Description." See the 36 description of the Write History Logging Support 37 controller flag in Section 5.6, "Controller Flags." 38 Write Protect (data safety) *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-40 Unit Flags 11 June 1992 1 A non-host-settable characteristic; set by the controller 2 whenever some condition in the unit or volume prevents 3 reliable modification of data on the volume. Possible 4 causes include: 5 o An incomplete bad block replacement. 6 o An invalid Replacement Control Table (RCT). 7 o The unit is only capable of reading the volume's 8 format (e.g., a single-density volume in a 9 double-density drive). 10 The consequences of Write Protection are described in 11 Section 4.14, "Write Protection." 12 This characteristic shall be fully supported if the 13 controller provides Controller Initiated Bad Block 14 Replacement support or supports units capable of only 15 reading a volume's format (e.g., a single-density volume 16 in a double-density drive). 17 Write Protect (hardware) 18 A non-host-settable characteristic; set if the unit's 19 write protect mechanism is activated, causing the unit to 20 be Hardware Write Protected. The consequences of Write 21 Protection are described in Section 4.14, "Write 22 Protection." 23 Write Protect (software) 24 Normally a non-host-settable characteristic; set if the 25 unit is "Software" Write Protected. A host-settable 26 characteristic if the "Enable Set Write Protect" command 27 modifier is set in the ONLINE or SET UNIT CHARACTERISTICS 28 command. If the "Enable Set Write Protect" command 29 modifier is set the controller enables or disables 30 "Software" Write Protection according to the state (set 31 or clear, respectively) of the "Write Protect (software)" 32 flag in the "unit flags" field. If the "Enable Set Write 33 Protect" command modifier is clear the controller ignores 34 the "Write Protect (software)" flag in the "unit flags" 35 field; the state of "Software" Write Protection remains 36 unchanged. The consequences of Write Protection are 37 described in Section 4.14, "Write Protection." 38 576 Byte Sectors *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-41 Unit Flags 11 June 1992 1 Normally a non-host-settable characteristic; set if the 2 disk volume mounted on the unit has 576 byte sectors. A 3 host-settable characteristic if the controller supports 4 576 byte sectors and the "Ignore Media Format Error" 5 command modifier is set in the ONLINE command (see 6 Section 6.13.1, "ONLINE Command, Command Message Format" 7 for complete details). 8 This characteristic shall be fully supported if the 9 controller supports disks formatted with either 512 or 10 576 byte sectors. If the controller only supports disks 11 formatted with 512 byte sectors, the controller shall 12 ignore any value the host specifies for this flag and 13 always return it clear. Note that all controllers that 14 support disk class devices shall support disks formatted 15 with 512 byte sectors. 16 Refer to Appendix A, "Opcode, Flag, and Offset Definitions," 17 Table A-5, "Unit Flags" for the values assigned to the currently 18 defined host-settable and non-host-settable unit flags. Those 19 bits in the "unit flags" field that are not defined as unit flags 20 are reserved, and shall be treated in accordance with the 21 requirements for reserved fields described in Section 5.2, 22 "Reserved and Undefined Fields." 23 5.8 Attention Messages 24 MSCP servers report duplicate unit number conditions and the 25 availability of units spontaneously to hosts via attention 26 messages. Hosts may enable or disable attention messages via the 27 setting of the "Enable Attention Messages" flag in the 28 "controller flags" field of the SET CONTROLLER CHARACTERISTICS 29 command (see Section 5.6, "Controller Flags"). Note that 30 attention messages are flow controlled as described in Section 31 3.2, "Flow Control" and associated subsections. Hosts shall 32 discard any attention messages that they do not recognize. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-42 Attention Messages 11 June 1992 1 The generic attention message format is as follows: 2 31 0 3 +--------------------------------+ 4 | reserved | 5 +---------------+----------------+ 6 | reserved | unit number | 7 +---------------+-------+--------+ 8 | reserved | rsvd |atncode | 9 +---------------+-------+--------+ 10 | | 11 / parameters / 12 / / 13 | | 14 +--------------------------------+ 15 The fields in the generic attention message are as follows: 16 unit number 17 Identifies the specific unit within the device class to 18 which the attention message applies. This value is the 19 binary equivalent of the decimal unit number displayed by 20 the unit select mechanism. 21 atncode 22 Identifies the attention message type. The atncode 23 implicitly specifies the length and format of the 24 message, including the interpretation of any parameters 25 that are present. 26 Appendix A, "Opcode, Flag, and Offset Definitions," Table 27 A-1, "Control Message Opcodes," lists the valid atncodes 28 and their meanings. 29 Appendix A, "Opcode, Flag, and Offset Definitions," Table A-7, 30 "End and Attention Message Offsets" defines the preferred 31 mnemonic and numeric value of the offset within the attention 32 message of the various attention message parameter fields, as 33 well as the size of each field. 34 The following sections describe the specific attention message 35 formats. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-43 Attention Messages 11 June 1992 1 5.8.1 ACCESS PATH Attention Message 2 5.8.1.1 Attention Message Format 3 31 0 4 +--------------------------------+ 5 | reserved | 6 +---------------+----------------+ 7 | reserved | unit number | 8 +---------------+-------+--------+ 9 | reserved | rsvd |atncode | 10 +---------------+-------+--------+ 11 | The fields in the ACCESS PATH attention message are as follows: 12 unit number 13 Identifies the unit for which an alternate access path is 14 being reported. 15 atncode 16 See Section 5.8, "Attention Messages." 17 5.8.1.2 Description 18 MSCP servers use this attention message to report alternate 19 access paths to multiaccess units. This message reports that the 20 specified unit is potentially accessible via the sending MSCP 21 server -- i.e., it would be "Unit-Available" if it and all units 22 that share its access path ceased being "Unit-Online" or under 23 "Exclusive Access" via another controller. The specific event 24 that causes an MSCP server to send this attention message is the 25 receipt, by the controller to which the unit is "Unit-Online" or 26 is under "Exclusive Access," of a DETERMINE ACCESS PATHS command. 27 This attention message is sent to all class drivers that are 28 "Controller-Online" to the MSCP server and have enabled attention 29 messages. See Section 4.16.1, "Multiaccess Drives," for more 30 information. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-44 Attention Messages 11 June 1992 1 5.8.2 AVAILABLE Attention Message 2 5.8.2.1 Attention Message Format 3 31 0 4 +--------------------------------+ 5 | reserved | 6 +---------------+----------------+ 7 | reserved | unit number | 8 +---------------+-------+--------+ 9 | reserved | rsvd |atncode | 10 +---------------+-------+--------+ 11 | unit flags | multiunit code | 12 +---------------+----------------+ 13 | undefined | 14 +--------------------------------+ 15 | | 16 +--- unit identifier ---+ 17 | | 18 +--------------------------------+ 19 | media type identifier | 20 +---------------+----------------+ 21 | The fields in the AVAILABLE attention message are as follows: 22 unit number 23 Identifies the unit that just became "Unit-Available." 24 atncode 25 See Section 5.8, "Attention Messages." 26 multiunit code 27 unit flags 28 unit identifier 29 media type identifier 30 Identical to the corresponding fields in the GET UNIT 31 STATUS or SET UNIT CHARACTERISTICS command end messages. 32 These fields shall be valid as defined for the unit being 33 "Unit-Available," regardless of the actual state of the 34 unit when the message is sent. That is, the "multiunit 35 code," "unit identifier," and "media type identifier" 36 shall all be valid and the "Removable Media" unit flag 37 shall be valid. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-45 Attention Messages 11 June 1992 1 5.8.2.2 Description 2 An MSCP server sends an AVAILABLE attention message to a 3 "Controller-Online" class driver when a unit asynchronously 4 becomes "Unit-Available" to that class driver, unless AVAILABLE 5 attention messages have been suppressed for that unit by an 6 AVAILABLE command with the "Spin-down" modifier or by an error or 7 other condition with similar side effects. Changes to the 8 "Unit-Available" state due to the class driver itself issuing an 9 AVAILABLE command are synchronous. All other changes to 10 "Unit-Available" are asynchronous. See Section 4.3, "Unit 11 States." 12 The actual sending of an AVAILABLE attention message may be 13 delayed for an arbitrarily long time, due to communications 14 mechanism flow control, from the time that the unit actually 15 becomes "Unit-Available." The message shall not be sent if the 16 class driver ceases to be "Controller-Online" during this delay. 17 The message shall be sent anyway if the unit, or any unit with 18 which it shares an access path, becomes "Unit-Online" or under 19 "Exclusive Access" via another controller during this delay. The 20 message may or may not be sent, at the controller's option, if 21 the unit ceases to be "Unit-Available" for any other reason 22 during this delay. 23 Note that, due to these delays, it is possible for an AVAILABLE 24 attention message to be received after the class driver has 25 already brought the unit "Unit-Online" or under "Exclusive 26 Access." Therefore class drivers shall not use AVAILABLE 27 attention messages to flag such units as having become 28 "Unit-Available." The proper procedure is to issue a command, 29 such as a GET UNIT STATUS, to a "Unit-Online" unit for which an 30 AVAILABLE attention message has been received, and only flag the 31 unit as having become "Unit-Available" if the command returns 32 that status code. 33 AVAILABLE attention messages are not sent for units that are 34 already "Unit-Available" when a class driver enables attention 35 messages. Class drivers that need to be aware of all 36 "Unit-Available" units shall enable attention messages, then scan 37 all units via the GET UNIT STATUS command with the "Next Unit" 38 modifier set to locate all units that are already 39 "Unit-Available." All units that subsequently become 40 "Unit-Available" will be reported with an AVAILABLE attention 41 message. 42 An MSCP server may send redundant or erroneous AVAILABLE 43 attention messages at any time. The frequency of such messages 44 shall be low enough that they do not represent a significant 45 overhead for either hosts or the communications mechanism. The *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-46 Attention Messages 11 June 1992 1 information contained in such messages (unit number, unit 2 identifier, media type identifier, etc.) shall correspond to an 3 actual, physical unit that is potentially accessible via that 4 MSCP server (i.e., connected to the controller), although the 5 unit need not be "Unit-Available." Note that hosts must be able 6 to handle seemingly erroneous AVAILABLE attention messages in any 7 case, since the unit's state may change before the host can act 8 on an otherwise correct message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-47 Attention Messages 11 June 1992 1 5.8.3 DUPLICATE UNIT NUMBER Attention Message 2 5.8.3.1 Attention Message Format 3 31 0 4 +--------------------------------+ 5 | reserved | 6 +---------------+----------------+ 7 | reserved | unit number | 8 +---------------+-------+--------+ 9 | reserved | rsvd |atncode | 10 +---------------+-------+--------+ 11 The fields in the DUPLICATE UNIT NUMBER attention message are as 12 follows: 13 unit number 14 Identifies the unit number that is duplicated on two or 15 more units. 16 atncode 17 See Section 5.8, "Attention Messages." 18 5.8.3.2 Description 19 An MSCP server sends DUPLICATE UNIT NUMBER attention messages to 20 notify hosts that two or more units of the same device class have 21 the same unit number. This allows the hosts to complain to an 22 operator, who can correct the condition. The DUPLICATE UNIT 23 NUMBER attention messages are sent to all hosts that are 24 "Controller-Online" and have enabled attention messages. See 25 Section 4.4, "Unit Numbers," for a detailed discussion of the 26 handling of duplicate unit numbers. Note that a DUPLICATE UNIT 27 NUMBER attention message is sent regardless of whether or not one 28 of the units is "Unit-Online" or under "Exclusive Access." 29 The actual sending of a DUPLICATE UNIT NUMBER attention message 30 may be delayed for an arbitrarily long time, due to 31 communications mechanism flow control, from the time that the 32 controller first detects the duplicate unit number. The message 33 shall not be sent if the class driver ceases to be 34 "Controller-Online" during this delay. The message may or may 35 not be sent, at the controller's option, if the duplicate unit 36 number condition disappears during this delay. 37 DUPLICATE UNIT NUMBER attention messages are not sent for 38 duplicate unit number conditions that already exist when a class 39 driver enables attention messages. Class drivers that need to be *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-48 Attention Messages 11 June 1992 1 aware of all duplicate unit number conditions shall enable 2 attention messages, then scan all units via the GET UNIT STATUS 3 command with the "Next Unit" modifier set to locate all duplicate 4 unit numbers. All duplicate unit numbers that the controller 5 subsequently detects will be reported with a DUPLICATE UNIT 6 NUMBER attention message. 7 An MSCP server may send redundant DUPLICATE UNIT NUMBER attention 8 messages. The frequency of such messages shall be low enough 9 that they do not represent a significant overhead for either 10 hosts or the communications mechanism. Furthermore, the 11 duplicate unit number condition being reported must actually 12 exist at the time the MSCP server decides to generate the 13 DUPLICATE UNIT NUMBER attention message. Note, however, that the 14 duplicate unit number condition may have disappeared by the time 15 the host receives or acts upon the message. 16 5.9 Error Log Messages 17 MSCP controllers report errors and unusual occurrences in two 18 ways: end messages and error log messages. Unrecoverable errors 19 are reported in the end message of the command that encountered 20 the error. Such errors should be reported back to the program 21 that initiated the command so that it can take appropriate 22 action. Additionally, all "significant" errors are reported in 23 error log messages so that they can be recorded in the host's 24 error log for eventual use by Field Service. The definition of 25 what constitutes a "significant" error is controller and/or 26 device specific. In general, anything that would be of interest 27 to Field Service is a "significant" error. The errors reported 28 by error log messages may be either recoverable or unrecoverable. 29 Note that hosts should not record errors reported in end messages 30 in the error log. If the error is "significant," a separate 31 error log message will be generated. 32 When a host receives an error log message, the host port driver 33 passes the class driver the error log message text and the length 34 of the error log message. In addition, the device class (i.e., 35 disk or tape) of the error log message is implicit in the 36 connection on which the message was received. Note that the 37 order of receipt of error log messages relative to end or 38 attention messages is expressly undefined. Therefore, an error 39 log message may be received either before or after an end message 40 that reports the same error or that has the "Error Log Generated" 41 flag set. 42 MSCP servers assign a sequence number to every error log message 43 they generate. The sequence number assigned is reported to the 44 host in the "Sequence Number" field in each error log message and 45 in each command end message that has the "Error Log Generated" *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-49 Error Log Messages 11 June 1992 1 flag set. This sequence number serves the following purposes: 2 1. It permits the host to determine when all error log 3 messages associated with a particular command have been 4 received. The host can then release any of the command's 5 context it may have saved for inclusion in its error log. 6 An example of how a host might use the error log sequence 7 number for this purpose appears later in this section. 8 2. If the same error log message is sent to multiple hosts, 9 which then record it in a common error log file, it 10 allows the multiple copies of the same message to be 11 recognized as describing the same error. 12 3. If a host requests that it receive every error log 13 message that an MSCP server generates, it allows that 14 host to detect missing or lost error log messages by 15 detecting gaps in the sequence numbers. In this case the 16 host is required to set all three error log enable flags 17 in the "controller flags" field of the SET CONTROLLER 18 CHARACTERISTICS command (see Section 5.6, "Controller 19 Flags"). 20 Some controllers can achieve these purposes via other means, and 21 therefore need not implement error log sequence numbers. The 22 requirements such controllers must meet are described later in 23 this section. 24 Each MSCP server implements a single error log sequence number, 25 which it uses for all error log messages for all class drivers. 26 The server increments its sequence number each time it attempts 27 to generate an error log message. (Note that sequence numbers 28 may wrap around, so that sequence number 0 comes after sequence 29 number 65535.) 30 Multiple copies of the same error log message shall all have the 31 same sequence number. On each individual connection, the MSCP 32 server shall send error log messages in the same order as their 33 sequence numbers. The relative order of error log messages sent 34 on different connections is undefined (and therefore a controller 35 option). 36 Whenever an MSCP server has pending error log messages for a 37 connection, it shall send at least one error log message on that 38 connection within the controller timeout interval. 39 An MSCP server has pending error log messages for a connection 40 whenever it has notified the class driver on that connection that 41 one or more error log messages are forthcoming (i.e., set the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-50 Error Log Messages 11 June 1992 1 "Error Log Generated" flag in an end message), but has not yet 2 sent or dropped all error log messages up to the one whose 3 sequence number was reported in the end message. The term 4 "dropped" refers to the MSCP server determining that it will not 5 send a message due to lack of some internal resource. 6 The sequence number is reset whenever the MSCP server loses 7 context. The first error log message after such a loss of 8 context has sequence number zero. The sequence number shall not 9 be reset as a normal result of the MSCP server becoming 10 "Controller-Online" or "Controller-Available" to a class driver. 11 Note that each MSCP server (i.e., each device class) within a 12 controller has its own error log sequence number. 13 As stated above, the error log sequence number is only reset when 14 the MSCP server loses context. The MSCP server reports the fact 15 that it has lost context by setting the "Sequence Number Reset" 16 flag (see Section 5.9.2, "Generic Error Log Message Format") in 17 the first error log message it sends to each class driver after 18 said loss of context. This means, in effect, that the MSCP 19 server must keep track of all class drivers to which it has sent 20 an error log message since its last loss of context, regardless 21 of whether or not it is currently "Controller-Online" to those 22 class drivers. 23 An example of how a host might use the error log sequence number 24 to correlate error log messages with outstanding command context 25 follows. 26 The class driver keeps track of the sequence number of 27 the most recent error log message it has received. This 28 sequence number should be initialized to zero when the 29 connection is established. Furthermore, in use command 30 slots (containing command context) come in two forms -- 31 active commands and commands waiting for error log 32 messages. The class driver also keeps track of whether 33 or not it has received an error log message within each 34 controller timeout interval for its command timeout 35 algorithm. 36 When the class driver receives an end message, it first 37 checks the "Error Log Generated" flag. If that flag is 38 clear, it releases the command slot as no longer in use. 39 If that flag is set, it calls the RELEASE_SLOT procedure 40 (see pseudo-code below) with the "sequence number" from 41 the command's end message and the sequence number of the 42 most recent error log message the class driver has 43 received. If RELEASE_SLOT returns TRUE, the class driver 44 releases the command slot as no longer in use. If that 45 procedure returns FALSE, the class driver marks the slot *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-51 Error Log Messages 11 June 1992 1 as waiting for error log messages. 2 When the class driver receives an error log message, it 3 calls the RELEASE_SLOT procedure, with the error log 4 sequence number from the command slot (copied from the 5 command's end message) and the sequence number of the new 6 error log message, once for each command slot that is 7 waiting for error log messages. If RELEASE_SLOT returns 8 TRUE, the class driver releases the command slot as no 9 longer in use. If RELEASE_SLOT returns FALSE, the slot 10 remains marked as waiting for error log messages. 11 Command slots that are waiting for error log messages 12 participate in the class driver's command timeout 13 algorithm (see Section 4.10, "Command Timeouts") just the 14 same as slots for outstanding commands. If the oldest 15 outstanding command slot is waiting for error log 16 messages, the class driver checks if any error log 17 messages have been received within the controller timeout 18 interval. If one or more error log messages have been 19 received, the slot remains in use. If no error log 20 messages have been received, the command slot is released 21 -- the error log message for which the slot was waiting 22 has been lost. 23 The RELEASE_SLOT procedure accepts an error log sequence 24 number from an end message and a sequence number from an 25 error log message. It returns TRUE if the error log 26 number comes after the end message number and FALSE 27 otherwise. This comparison takes into account sequence 28 number wrap-around. The procedure (pseudo-code) is: 29 function RELEASE_SLOT ( 30 end_msg_number : 0..65535 ; 31 err_log_number : 0..65535 ) : boolean ; 32 const 33 FUDGE = 1 ; 34 var 35 i : -65535..65535 ; 36 begin ; 37 { following three lines are just a 16 bit } 38 { signed subtract operation, ignoring } 39 { integer overflow (i.e., the PDP-11 SUB } 40 { instruction). } 41 i := err_log_number - end_msg_number ; 42 if i < -32768 then i := i + 65536 ; 43 if i > 32767 then i := i - 65536 ; 44 RELEASE_SLOT := (i >= FUDGE-1) ; 45 end ; *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-52 Error Log Messages 11 June 1992 1 The constant FUDGE is the maximum degree of 2 communications mechanism nonsequentiality for datagrams. 3 Assume that datagrams n, n+1, n+2, etc. are sent in that 4 order across a connection. FUDGE is the smallest value 5 for which the communications mechanism guarantees that, 6 if both datagram n and datagram n+FUDGE are received, 7 then datagram n is received before datagram n+FUDGE. All 8 current and proposed communications mechanisms have 9 sequential datagrams, for which FUDGE is one. The only 10 type of communications mechanism for which FUDGE might 11 have a different value is one that has multiple paths 12 between nodes, and allows datagrams for a single 13 connection to follow different paths. 14 As mentioned earlier, controllers need not implement error log 15 sequence numbers, since their purposes can be achieved via other 16 means. Controllers that meet all of the following requirements 17 need not implement error log sequence numbers: 18 1. The MSCP server never drops error log messages. That 19 is, whenever it has an error log message to generate, it 20 blocks or deadlocks until it is able to generate the 21 message. 22 2. The communications mechanism between the MSCP server and 23 the class driver guarantees all error log messages will 24 be delivered without loss or duplication in the order 25 that they were generated. That is, the communications 26 mechanism provides the same guarantees for datagrams 27 (error log messages) that it provides for sequential 28 messages (control messages). 29 3. The MSCP server and communications mechanism guarantee 30 that the class driver will receive all error log 31 messages that reference a particular command's reference 32 number before receiving that command's end message. 33 4. The MSCP server and communications mechanism are 34 inherently incapable of communicating with more than one 35 class driver. 36 MSCP servers that meet the above four requirements may generate 37 all error log messages with a sequence number of zero and with 38 the "Sequence Number Reset" flag set, rather than actually 39 implementing sequence numbers. All other MSCP servers shall 40 implement an actual error log sequence number. Such other MSCP 41 servers may not lose context solely to reset the error log 42 sequence number. All losses of context must be caused by some 43 external event such as a power failure. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-53 Error Log Messages 11 June 1992 1 Since error log messages are not subject to flow control (see 2 Section 3.2, "Flow Control"), it is possible for a controller to 3 generate error log messages faster than a host can record them in 4 its error log. In order to minimize the probability of this 5 happening, and thus minimize the probability of losing error log 6 information, controllers shall generate no more than three error 7 log messages in response to a single error. Note that the 8 definition of what constitutes an error is necessarily controller 9 and/or drive dependent. The three message limit encompasses an 10 original error and all error recovery / correction / retry 11 sequences associated with that error. Seemingly unrelated errors 12 that occur in a recovery sequence are generally considered to be 13 different errors, and are therefore not covered by the three 14 message limit. 15 For example, consider an uncorrectable ECC error on a read. 16 Rereads 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 retries is small 30 (i.e., three or fewer attempts total), as otherwise the three 31 message limit will be exceeded. 32 5.9.1 Maximum Error Log Message Size 33 MSCP and TMSCP do not place any explicit limit on the maximum 34 size of an error log message. Rather, they simply require that 35 in any supported or operational configuration, the maximum error 36 log message size generated by a device's MSCP or TMSCP server 37 must be less than or equal to the maximum supported by the host 38 class driver and any intervening adapters. In essence, error log 39 message size limits are outside the scope of this specification. 40 In order to assist in determining if maximum error log message 41 sizes are compatible in a particular configuration, all MSCP and 42 TMSCP entities shall register their error log message size limits 43 with the SSAG Architectural Compliance Registry. Information on 44 procedures for using the registry may be obtained by sending mail 45 to SSAG::SSAG. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-54 Error Log Messages 11 June 1992 1 Each MSCP or TMSCP class driver shall register the maximum error 2 log message size they support. They shall list multiple sizes 3 with appropriate qualification if they support different sizes in 4 different circumstances, such as with different port drivers or 5 adapters. Any limits imposed by adapters shall be included in 6 the class driver's registered limits, since such limitations are 7 extremely few in number. 8 Each MSCP or TMSCP server shall register the maximum size of any 9 error log message it may generate. It is reasonable to list 10 multiple sizes if class drivers and/or system configurations can 11 affect what sizes are used. For example, if the longest messages 12 will only be generated if a particular option is used, it is 13 reasonable to list limits both with and without that option being 14 used. An MSCP or TMSCP server shall not generate an error log 15 message longer than what it has registered, under whatever 16 conditions or qualifications are included in its registration. 17 Furthermore, an MSCP or TMSCP server may not register a maximum 18 error log message size unless a corresponding class driver is 19 already registered as supporting at least that maximum. 20 The purpose of this last restriction is to make it clear that the 21 burden of obtaining support for a new, longer maximum error log 22 message size lies upon the device wishing to use those longer 23 messages. The device development group must first obtain 24 agreement from some host OS group to support the longer messages, 25 leading to the host OS group changing its Architectural 26 Compliance Registry entry to indicate the longer size. Only then 27 may the device group register its device and begin to generate 28 the longer messages. 29 Notwithstanding the above requirements, the following guidelines 30 should be followed by all new or significantly modified products. 31 Adherence to these guidelines will minimize support and 32 compatibility problems with regard to error log message sizes. 33 1. For SSP devices, all class drivers should be designed to 34 support a maximum error log message size of 124 bytes or 35 larger. This corresponds to a 128 byte SSP message 36 buffer less 4 bytes overhead. Note, however, that at 37 the time this was written the KFQSA adapter imposed a 38 limit of 88 bytes on MSCP or TMSCP error log messages. 39 2. For all other devices, all class drivers should be 40 designed to support a maximum error log message size of 41 512 bytes or larger. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-55 Error Log Messages 11 June 1992 1 3. For SSP devices, servers should be designed to use error 2 log messages no longer than 60 bytes. Longer messages 3 may encounter compatibility problems with older 4 software. 5 4. For all other devices, servers should be designed to use 6 error log messages no longer than 128 bytes. Longer 7 messages may encounter compatibility problems with older 8 software. 9 These are only recommended guidelines, and may be violated 10 without affecting MSCP or TMSCP compliance. But special care 11 should be taken to consider the risk of incompatibility whenever 12 these recommendations are not followed. 13 As has already been stated, in any supported or operational 14 configuration, the maximum error log message size generated by a 15 device's MSCP or TMSCP server must be less than or equal to the 16 maximum supported by the host class driver and any intervening 17 adapters. The converse of this is that if a device might 18 generate an error log message longer than an adapter or host 19 class driver supports, then their combination is not a supported 20 configuration and need not be operational. All the same, such 21 mis-configured systems will occur in practice, so defensive 22 programming techniques should be used to simplify diagnosis and 23 minimize problems with mis-configurations. A system crash or 24 weird behavior that only occurred when a particular error log 25 message arrived would be extremely difficult to diagnose. 26 To this end it is strongly recommended that all entities 27 participating in an MSCP or TMSCP connection explicitly check 28 error log message sizes, rather than implicitly assuming they are 29 valid. Ideally an explicit message would be displayed to report 30 the mis-configuration, although this may be impractical for most 31 devices. If the communications mechanism allows it, error log 32 message sizes should be checked when a connection is established 33 rather than waiting for an overly long error log message to be 34 generated. If a mis-configuration is present, the connection 35 should be rejected, rather than establishing the connection only 36 to have a problem at the unpredictable time a long error log 37 message is generated. 38 If an error log message longer than that which is supported is 39 nonetheless generated, it should be truncated to the supported 40 maximum size on that connection. The actual truncation may occur 41 in the server, class driver, an adapter, or anywhere else 42 convenient. With most communications mechanisms, any truncation 43 should be performed by the sender before the error log message is 44 sent. For example, truncation to the SCA maximum datagram size *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-56 Error Log Messages 11 June 1992 1 should occur in the server sending the error log message, before 2 it is passed to SCA. Similarly, truncation to the size of an SSP 3 message buffer should occur in the SSP adapter. Truncation to 4 the maximum size supported by the host's error logging subsystem 5 would normally be done in the host. 6 The truncated size should be recorded with the error log message, 7 so that undefined data is not mistakenly interpreted as belonging 8 to the message. Error log analysis tools might subsequently use 9 device dependent knowledge to recognize that the message has been 10 truncated and report the mis-configuration. Connections should 11 not be broken if an overly long error log message is generated, 12 nor should such messages be discarded due to their size. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-57 Error Log Messages 11 June 1992 1 5.9.2 Generic Error Log Message Format 2 31 0 3 +--------------------------------+ 4 | command reference number | 5 +---------------+----------------+ 6 |sequence number| unit number | 7 +---------------+-------+--------+ 8 | event code | flags | format | 9 +---------------+-------+--------+ 10 | | 11 +--- controller identifier ---+ 12 | | 13 +---------------+-------+--------+ 14 | multiunit code|chvrsn | csvrsn | 15 +---------------+-------+--------+ 16 | | 17 +--- unit identifier ---+ 18 | | 19 +---------------+-------+--------+ 20 | fmt dependent |uhvrsn | usvrsn | 21 +---------------+-------+--------+ 22 | volume serial number | 23 +--------------------------------+ 24 | | 25 / format dependent / 26 / information / 27 | | 28 +--------------------------------+ 29 The fields in the generic error log message are as follows: 30 command reference number 31 The command reference number of the MSCP command that 32 caused the error reported by this error log message, or 33 zero if the error does not correspond to a specific 34 outstanding command. If this field contains a command 35 reference number, then the command's end message will 36 also have the "error log generated" end message flag set. 37 Note that the error log message may be received either 38 before or shortly after the command's end message. 39 unit number 40 The unit number of the unit to which the error log 41 message relates, or zero if the message does not relate 42 to a specific unit. This field may contain the unit *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-58 Error Log Messages 11 June 1992 1 number of any unit of the drive or formatter if the error 2 relates to an entire multiunit drive or formatter. The 3 validity of this field is determined by the value in the 4 "format" field. 5 sequence number 6 The sequence number of this error log message since the 7 last time the MSCP server lost context, or zero if the 8 MSCP server does not implement error log sequence 9 numbers. Note that error log sequence numbers are common 10 to all class drivers, and are not reset by class driver 11 resynchronization. Note also that the class driver may 12 receive error log messages out of sequence. 13 format 14 The value in this field identifies the detailed format of 15 the error log message, as defined in the following 16 sections. 17 Refer to Appendix A, "Opcode, Flag, and Offset 18 Definitions," Table A-9, "Error Log Message Format Codes" 19 for the values assigned to the currently defined formats. 20 flags 21 Bit flags, collectively called error log message flags, 22 used to report various attributes of the error. The 23 following flags are defined: 24 Bad Block Replacement Request 25 If set, the block identified by the error log 26 message is a bad block, and the Controller 27 Initiated Bad Block Replacement layer will soon 28 attempt to replace it. Note that this flag is 29 reported only by controllers that support 30 Controller Initiated Bad Block Replacement for 31 disk class devices. 32 Disk Copy Data Correlate 33 If set, the reported error occurred during the 34 execution of a DISK COPY DATA command where the 35 source unit is located in a remote subsystem as 36 described in Section 6.7.3, "DISK COPY DATA 37 Command, Description." Note that the server 38 sends a DISK COPY DATA CORRELATION error log as 39 described in Section 5.9.9, prior to sending the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-59 Error Log Messages 11 June 1992 1 end message for a particular DISK COPY DATA 2 command. See that section for related 3 information. 4 Error During Replacement 5 If set, the reported error occurred during an 6 access initiated by the bad block replacement 7 process. Note that this flag is reported only by 8 controllers that support Controller Initiated Bad 9 Block Replacement for disk class devices. 10 Operation Successful 11 If set, the operation causing this error log 12 message has been successfully completed. The 13 error log message summarizes the retry sequence 14 that was necessary to successfully complete the 15 operation. If clear, the operation has not yet 16 been successfully completed. 17 Operation Continuing 18 If set, the retry sequence for this operation 19 will be continued. This error log message 20 reports the unsuccessful completion of one or 21 more retries. If clear, the retry sequence for 22 this operation has terminated. Provided 23 "Operation Successful" is also clear, the retry 24 limit for this operation has been reached and an 25 unrecoverable error will be reported. Undefined 26 (meaningless) if "Operation Successful" is set. 27 Sequence Number Reset 28 If set, then the error log sequence number 29 ("sequence number" field) has been reset by the 30 MSCP server since the last error log message sent 31 to the receiving class driver. If clear, the 32 sequence number has not been reset, implying that 33 the "sequence number" field may be used to detect 34 missing error log messages. Always set if the 35 MSCP server does not implement error log sequence 36 numbers. 37 Informational 38 If set, the data contained in this error log 39 message is informational only. The information 40 is not necessarily related to any single command *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-60 Error Log Messages 11 June 1992 1 or event. Note that the error log message does 2 NOT signify the occurrence of an error and shall 3 not be included in device error counts. 4 If "Operation Successful" and "Operation Continuing" are 5 both clear, then the error log message reports a hard 6 (unrecoverable) error. If "Operation Successful" is 7 clear and "Operation Continuing" is set, then the error 8 log message reports an intermediate step within an error 9 recovery operation. It is not yet certain whether the 10 error is hard or soft. If "Operation Successful" is set, 11 then the error log message summarizes the retry sequence 12 used to recover from a soft error. 13 Refer to Appendix A, "Opcode, Flag, and Offset 14 Definitions," Table A-10, "Error Log Message Flags" for 15 the values assigned to the currently defined flags. 16 event code 17 Identifies the specific error or event being reported by 18 | this error log message. See Section 5.5, "Status and 19 | Event Codes." 20 The subcode portion of the event code is potentially 21 controller and/or device specific. However, the same 22 major code / subcode combination, whenever it is used, 23 must always have the same meaning. Therefore, new 24 subcodes may be defined as new devices are introduced, 25 but the meaning of old subcodes should not change. Event 26 code values are listed in Appendix B, "Status and Event 27 Code Definitions." 28 controller identifier 29 Uniquely identifies the controller among all devices 30 accessible via MSCP. See Section 4.17, "Controller and 31 Unit Identifiers." 32 csvrsn 33 The controller's software, firmware, or microcode 34 revision number. Always zero if the product's 35 development and maintainability groups determine that 36 there is no benefit from supporting machine readable 37 revision numbers. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-61 Error Log Messages 11 June 1992 1 chvrsn 2 The controller's hardware revision number. Always zero 3 if the product's development and maintainability groups 4 determine that there is no benefit from supporting 5 machine readable revision numbers. 6 multiunit code 7 The multiunit code, as defined in Section 4.16.2, 8 "Multiunit Drives and Formatters," of the unit to which 9 the error log message relates. This field may contain 10 the multiunit code of any unit of the drive or formatter 11 if the error relates to an entire multiunit drive or 12 formatter. 13 unit identifier 14 Uniquely identifies the unit among all devices accessible 15 via MSCP. See Section 4.17, "Controller and Unit 16 Identifiers." This field is only present for errors that 17 relate to a specific unit. 18 usvrsn 19 The unit's software, firmware, or microcode revision 20 number. This field is only present for errors that 21 relate to a specific unit. Always zero if the product's 22 development and maintainability groups determine that 23 there is no benefit from supporting machine readable 24 revision numbers. 25 uhvrsn 26 The unit's hardware revision number. This field is only 27 present for errors that relate to a specific unit. 28 Always zero if the product's development and 29 maintainability groups determine that there is no benefit 30 from supporting machine readable revision numbers. 31 volume serial number 32 The low order 32 bits of the serial number of the volume 33 that is mounted on the unit. Zero if the unit's format 34 does not provide for a volume serial number. Undefined 35 (garbage) if there is no volume mounted in the unit, the 36 area of the volume that contains the serial number cannot 37 be read successfully, the error occurred before the 38 volume serial number could be determined while bringing 39 the unit "Unit-Online," the unit is not "Unit-Online" to *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-62 Error Log Messages 11 June 1992 1 any host, or if the "Ignore Media Format Error" modifier 2 was specified in the ONLINE command that first brought 3 the unit "Unit-Online." This field is only present for 4 errors that relate to a specific disk unit. 5 fmt dependent 6 format dependent information 7 The format of the remainder of the error log message 8 depends upon the value of the "format" field. Note that 9 the fields "unit number" and "multiunit code" through 10 "volume serial number" also depend on the value of the 11 "format" field, as they are only present for those 12 formats used to report errors that relate to a specific 13 unit. 14 Appendix A, "Opcode, Flag, and Offset Definitions," Table A-8, 15 "Error Log Message Offsets" defines the preferred mnemonic and 16 numeric value of the offset within the error log message of the 17 various error log parameter fields, as well as the size of each 18 field. 19 The following sections describe the specific error log message 20 formats. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-63 Error Log Messages 11 June 1992 1 5.9.3 CONTROLLER ERRORS Error Log Format 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 The fields in the CONTROLLER ERRORS error log message are as 24 follows: 25 command reference number 26 sequence number 27 format 28 flags 29 event code 30 controller identifier 31 csvrsn 32 chvrsn 33 See Section 5.9.2, "Generic Error Log Message Format." 34 controller dependent information 35 A variable (controller dependent) amount of information. 36 Often no controller dependent information is provided. 37 The length of this information is implied by the total 38 length of the error log message, passed to the class 39 driver by the port driver. This information will 40 typically not be interpreted by error log formatting 41 programs, instead being printed as a series of values. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-64 Error Log Messages 11 June 1992 1 5.9.4 MEMORY ERRORS Error Log Format 2 The following error log message format is used to report memory 3 errors when the address of the offending location is available to 4 the controller. This format is used for either host or internal 5 controller memory access errors. The format is: 6 31 0 7 +--------------------------------+ 8 | command reference number | 9 +---------------+----------------+ 10 |sequence number| reserved | 11 +---------------+-------+--------+ 12 | event code | flags | format | 13 +---------------+-------+--------+ 14 | | 15 +--- controller identifier ---+ 16 | | 17 +---------------+-------+--------+ 18 | reserved |chvrsn | csvrsn | 19 +---------------+-------+--------+ 20 | memory address | 21 +--------------------------------+ 22 | | 23 / controller / 24 / dependent / 25 / information / 26 / (optional) / 27 | | 28 +--------------------------------+ 29 The fields in the MEMORY ERRORS error log message are as follows: 30 command reference number 31 sequence number 32 format 33 flags 34 event code 35 controller identifier 36 csvrsn 37 chvrsn 38 See Section 5.9.2, "Generic Error Log Message Format." 39 event code 40 The event code identifies whether the error being 41 reported occurred in host or controller memory. For 42 errors in host memory the event code contains an 43 appropriate "Host Buffer Access Error" subcode (see Table *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-65 Error Log Messages 11 June 1992 1 B-6, "'Host Buffer Error' Status or Event Code Subcode 2 Values"). For errors in controller memory the event code 3 contains an appropriate "Controller Error" subcode (see 4 Table B-7, "'Controller Error' Status or Event Code 5 Subcode Values"). 6 memory address (host memory access error) 7 For errors accessing host memory the "memory address" 8 field contains the address in the host's physical address 9 space at which the error occurred. 10 The units of "memory address" are those natural to the 11 host -- bytes for 16 and 32 bit systems or words for 36 12 bit systems. The resolution to which a controller 13 identifies the address at which the error occurred is 14 controller dependent, and shall be described in the 15 controller's functional specification. Disk controllers 16 will typically provide a resolution of one disk block. 17 memory address (controller memory access error) 18 For errors accessing controller memory the "memory 19 address" field contains the location in the controller's 20 memory at which the error occurred. 21 Only errors that do not affect the controller's ability 22 to properly generate end and error log messages are 23 reported via MSCP and this error log format. Errors that 24 might affect end and error log messages are reported via 25 some mechanism other than MSCP. 26 The units of "memory address" are those natural to the 27 memory in which the error occurred. This necessarily 28 implies that the units are memory dependent. Bytes are 29 the preferred units whenever there is any ambiguity as to 30 what are the natural units. The resolution to which the 31 address of the error is reported is also memory 32 dependent. It is acceptable for some memories to have no 33 address resolution. That is, errors in such memories are 34 reported with a fixed address of zero regardless of the 35 address at which the error occurred. This will typically 36 be used for memories in which any error renders the 37 entire memory unusable. 38 Controllers with multiple memories may identify the 39 particular memory in which the error occurred either by 40 embedding the identification (as a subfield) in the 41 "memory address" field or by providing the identification 42 in the "controller dependent information" field *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-66 Error Log Messages 11 June 1992 1 (described below). The units of "memory address," 2 address resolution, and memory identification (where 3 required) are controller dependent and shall be described 4 in the controller's functional specification. 5 controller dependent information 6 An optional, variable length field containing controller 7 dependent information. The length of this field is 8 implied by the total length of the error log message, 9 passed to the class driver by the port driver. This 10 field may be used to provide additional information when 11 reporting either controller or host memory errors or 12 both. The use and contents shall be described in the 13 controller's functional specification. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-67 Error Log Messages 11 June 1992 1 5.9.5 DISK TRANSFER ERRORS Error Log Format 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 |multiunit 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 The fields in the DISK TRANSFER ERRORS error log message are as 35 follows: 36 command reference number 37 unit number 38 sequence number 39 format 40 flags 41 event code 42 controller identifier 43 csvrsn 44 chvrsn 45 multiunit code 46 unit identifier *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-68 Error Log Messages 11 June 1992 1 usvrsn 2 uhvrsn 3 volume serial number 4 See Section 5.9.2, "Generic Error Log Message Format." 5 level 6 The error recovery level used for the most recent attempt 7 at the transfer. The error recovery level is a device 8 dependent encoding of the special error recovery 9 procedures, such as offset head positioning, used for the 10 most recent transfer attempt. The values zero and 255 11 (all ones) are reserved to indicate that no special error 12 recovery procedures were used. 13 retry 14 The retry count, within the current error recovery level, 15 of the most recent attempt at the transfer. This value 16 starts at one for the first attempt using a particular 17 error recovery level and increments for each subsequent 18 attempt at the same level. This continues up to some 19 drive dependent maximum, at which time the retry count is 20 reset to one and the next error recovery level (if any) 21 is tried. 22 header code 23 Identifies the physical disk location at which the error 24 occurred. If the high four bits are 0000 (binary), then 25 the low 28 bits are the logical block number at which the 26 error occurred. If the high four bits are 0110 (binary), 27 then the low 28 bits are the replacement block number at 28 which the error occurred. All other patterns of the high 29 four bits of "header code" are reserved, and may not be 30 returned without an ECO to this specification to define 31 their interpretation. The 28 bit logical or replacement 32 block number may be decomposed, using the disk geometry 33 parameters returned by the GET UNIT STATUS command, to 34 obtain the cylinder, group, track, and sector position at 35 which the error occurred. 36 controller or disk dependent information 37 A variable (controller or disk dependent) amount of 38 information. Often no controller or disk dependent 39 information is provided. The length of this information 40 is implied by the total length of the error log message, 41 passed to the class driver by the port driver. This *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-69 Error Log Messages 11 June 1992 1 information will typically not be interpreted by error 2 log formatting programs, instead being printed as a 3 series of values. 4 5.9.6 SDI ERRORS Error Log Format 5 The following error log message format is used by Standard Disk 6 Interconnect (SDI) disk controllers to report drive detected 7 errors and SDI communication errors. Note that the controller 8 retries these errors only once or twice, so a separate error log 9 message will be generated for each attempt that fails. 10 31 0 11 +--------------------------------+ 12 | command reference number | 13 +---------------+----------------+ 14 |sequence number| unit number | 15 +---------------+-------+--------+ 16 | event code | flags | format | 17 +---------------+-------+--------+ 18 | | 19 +--- controller identifier ---+ 20 | | 21 +---------------+-------+--------+ 22 |multiunit code |chvrsn | csvrsn | 23 +---------------+-------+--------+ 24 | | 25 +--- unit identifier ---+ 26 | | 27 +---------------+-------+--------+ 28 | reserved |uhvrsn | usvrsn | 29 +---------------+-------+--------+ 30 | volume serial number | 31 +--------------------------------+ 32 | header code | 33 +--------------------------------+ 34 | | 35 +--- SDI status ---+ 36 | information | 37 +--- (12 bytes) ---+ 38 | | 39 +--------------------------------+ 40 The fields in the SDI ERRORS error log message are as follows: 41 command reference number 42 unit number 43 sequence number 44 format 45 flags *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-70 Error Log Messages 11 June 1992 1 event code 2 controller identifier 3 csvrsn 4 chvrsn 5 multiunit code 6 unit identifier 7 usvrsn 8 uhvrsn 9 volume serial number 10 See Section 5.9.2, "Generic Error Log Message Format." 11 header code 12 Identifies the physical disk location at which the error 13 occurred. If the high four bits are 0000 (binary), then 14 the low 28 bits are the logical block number at which the 15 error occurred. If the high four bits are 0110 (binary), 16 then the low 28 bits are the replacement block number at 17 which the error occurred. All other patterns of the high 18 four bits of "header code" are reserved, and may not be 19 returned without an ECO to this specification to define 20 their interpretation. The 28 bit logical or replacement 21 block number may be decomposed, using the disk geometry 22 parameters returned by the GET UNIT STATUS command, to 23 obtain the cylinder, group, track, and sector position at 24 which the error occurred. 25 SDI status information 26 Twelve bytes of status information returned by the SDI 27 GET STATUS command or by the SDI UNSUCCESSFUL response. 28 The unit number information returned by the SDI command 29 or response is not included, as that information is 30 provided elsewhere in the error log message. Otherwise, 31 all of the SDI status information is included. See the 32 SDI specification for the format of this information. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-71 Error Log Messages 11 June 1992 1 5.9.7 SMALL DISK ERRORS Error Log Format 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 |multiunit 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 The fields in the SMALL DISK ERRORS error log message are as 35 follows: 36 command reference number 37 unit number 38 sequence number 39 format 40 flags 41 event code 42 controller identifier 43 csvrsn 44 chvrsn 45 multiunit code 46 unit identifier *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-72 Error Log Messages 11 June 1992 1 usvrsn 2 uhvrsn 3 volume serial number 4 See Section 5.9.2, "Generic Error Log Message Format." 5 cylinder 6 The cylinder to which the current transfer is directed. 7 This field may or may not be meaningful, depending on the 8 value in "event code." 9 controller or drive dependent information 10 A variable (controller or drive dependent) amount of 11 information. The length of this information is implied 12 by the total length of the error log message, passed to 13 the class driver by the port driver. This information 14 will typically not be interpreted by error log formatting 15 programs, instead being printed as a series of values. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-73 Error Log Messages 11 June 1992 1 5.9.8 BAD BLOCK REPLACEMENT ATTEMPT Error Log Format 2 The following error log message format is used by the (Controller 3 Initiated) Bad Block Replacement layer to report completion of a 4 bad block replacement attempt. Note that a message of this 5 format is always generated regardless of the success or failure 6 of the replacement attempt. 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 |multiunit code |chvrsn | csvrsn | 20 +---------------+-------+--------+ 21 | | 22 +--- unit identifier ---+ 23 | | 24 +---------------+-------+--------+ 25 | replace flags |uhvrsn | usvrsn | 26 +---------------+-------+--------+ 27 | volume serial number | 28 +--------------------------------+ 29 | Bad LBN | 30 +--------------------------------+ 31 | Old RBN | 32 +--------------------------------+ 33 | New RBN | 34 +---------------+----------------+ 35 | cause | 36 +----------------+ 37 The fields in the BAD BLOCK REPLACEMENT ATTEMPT error log message 38 are as follows: 39 unit number 40 sequence number 41 format 42 flags 43 controller identifier 44 csvrsn 45 chvrsn 46 multiunit code *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-74 Error Log Messages 11 June 1992 1 unit identifier 2 usvrsn 3 uhvrsn 4 volume serial number 5 See Section 5.9.2, "Generic Error Log Message Format." 6 command reference number 7 Either zero or the command reference number of the 8 command that caused the bad block to be detected and 9 replaced. Controllers need not save this value, in which 10 case this field will always be zero. 11 event code 12 Reports the completion status of the bad block 13 replacement attempt. The major code is always "Bad Block 14 Completion." Subcodes are defined in Table B-9, "'Bad 15 Block Replacement Completion' Event Only Subcode 16 Values." 17 replace flags 18 Bit flags reporting in detail the outcome of the bad 19 block replacement attempt. See Table A-11, "Bad Block 20 Replacement Attempt 'Replace Flags'" for the definitions 21 of those flags. 22 Bad LBN 23 The LBN that was the target of the replacement attempt. 24 Old RBN 25 If the "Bad RBN" replace flag is set, the RBN with which 26 the Bad LBN was formerly replaced. Zero otherwise. 27 New RBN 28 If the "Replacement Attempted" replace flag is set, the 29 RBN with which the Bad LBN is now replaced. Zero 30 otherwise. 31 Cause 32 The event code from the original error that caused the 33 replacement to be attempted. Zero if that event code is 34 not available. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-75 Error Log Messages 11 June 1992 1 5.9.9 DISK COPY DATA CORRELATION Error Log Format 2 The following error log message format is used to report specific 3 context related to errors detected during the execution of a DISK 4 COPY DATA command. See Section 6.7.3, "DISK COPY DATA Command, 5 Description." 6 This error log shall be generated if one or more error logs was 7 generated by a remote source. In this case, the event code 8 returned will be Informational (subcode "Disk Copy Data 9 Correlation"). The error logs generated by the remote source 10 will have the Disk Copy Data Correlate error log flag set and 11 will have the same "command reference number" as this 12 Informational error log. This error log allows all error logs 13 related to such a DISK COPY DATA command to be correlated with 14 that command's context. 15 This error log is also sent for certain classes of fatal errors 16 detected by the server during attempted execution of the DISK 17 COPY DATA command. See the descriptions of the status codes in 18 Section 6.7.2, "DISK COPY DATA Command, End Message Format" for 19 specifics. In these cases, this error log shall contain the 20 appropriate event code/subcode. Note that for most of these 21 fatal errors, this will be the only error log related to this 22 DISK COPY DATA command generated by the server. 23 Note that in either case this error log is only sent once for a 24 particular DISK COPY DATA command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-76 Error Log Messages 11 June 1992 1 31 0 2 +--------------------------------+ 3 | command reference number | 4 +---------------+----------------+ 5 |sequence number|dst unit number | 6 +---------------+-------+--------+ 7 | event code | flags | format | 8 +---------------+-------+--------+ 9 | | 10 +--- controller identifier ---+ 11 | | 12 +---------------+-------+--------+ 13 | undefined |chvrsn | csvrsn | 14 +---------------+-------+--------+ 15 | destination | 16 +--- unit ---+ 17 | identifier | 18 +---------------+----------------+ 19 | undefined |src unit number | 20 +---------------+----------------+ 21 | source | 22 +--- controller ---+ 23 | identifier | 24 +---------------+-------+--------+ 25 | undefined |schvrsn|scsvrsn | 26 +---------------+-------+--------+ 27 | source | 28 +--- unit ---+ 29 | identifier | 30 +--------------------------------+ 31 |source unit's storage subsystem | 32 +--- port ---+ 33 | address | 34 +--------------------------------+ 35 |source unit's storage subsystem | 36 +--- system ---+ 37 | address | 38 +--------------------------------+ 39 | | 40 / event dependent / 41 / information / 42 | | 43 +--------------------------------+ 44 The fields in the DISK COPY DATA CORRELATION error log message 45 are as follows: 46 command reference number 47 sequence number 48 format *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-77 Error Log Messages 11 June 1992 1 controller identifier 2 csvrsn 3 chvrsn 4 See Section 5.9.2, "Generic Error Log Message Format." 5 The contents of the "command reference number" field in 6 this message shall be identical to the contents of the 7 "command reference number" field of the DISK COPY DATA 8 command for which this message is sent. 9 dst unit number (destination unit number) 10 destination unit identifier 11 src unit number 12 source unit identifier 13 source unit's storage subsystem port address 14 source unit's storage subsystem system address 15 The values of these fields are copied without 16 modification from the corresponding fields of the DISK 17 COPY DATA command message identified in the "command 18 reference number" field of this message. See Section 19 6.7.1, "DISK COPY DATA Command, Command Message Format" 20 for descriptions of these fields. 21 flags 22 See Section 5.9.2, "Generic Error Log Message Format." 23 The Informational error log flag shall be set in this 24 message if the event code is Informational. 25 event code 26 For DISK COPY DATA commands that terminate with an end 27 message major status code of Controller Error, Host 28 Buffer Access Error, or Subcommand Error, the event code 29 shall be set to the corresponding event code/subcode. 30 Otherwise, the event code is Informational (subcode "Disk 31 Copy Data Correlation"). 32 source controller identifier 33 scsvrsn (source csvrsn) 34 schvrsn (source chvrsn) 35 The values of these fields are from the end message of 36 the SET CONTROLLER CHARACTERISTICS command issued when 37 bringing the remote server "Controller-Online." Zero if 38 that information is not available. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MSCP CONTROL MESSAGES Page 5-78 Error Log Messages 11 June 1992 1 event dependent information 2 A variable amount of information dependent on the event 3 that caused this error log message to be generated. The 4 length of this information is implied by the total length 5 of the error log message, passed to the class driver by 6 the port driver. This information will typically not be 7 interpreted by error log formatting programs, instead 8 being printed as a series of values. See Sections 6.7.2, 9 "DISK COPY DATA Command, End Message Format," and 6.7.3, 10 "DISK COPY DATA Command, Description" for details on 11 what, if anything, should be placed in this field. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-1 11 June 1992 1 CHAPTER 6 2 MINIMAL MSCP COMMAND SET 3 6.1 Overview 4 This chapter describes the minimal MSCP command set implemented 5 by an MSCP disk controller. Refer to the Tape Mass Storage 6 Control Protocol Specification (TMSCP) for details of the minimal 7 command set implemented by MSCP tape controllers. A number of 8 commands operate identically on both disk and tape class devices. 9 TMSCP relies on the descriptions contained in this chapter for 10 those commands. 11 Controllers that support only the minimal MSCP command set 12 implicitly provide single host operation and rely on the host for 13 the replacement of bad blocks. 14 General purpose disk class drivers shall at the very minimum 15 implement both the minimal MSCP command set, described in this 16 chapter, and Controller Initiated Bad Block Replacement, 17 described in Chapter 8. 18 Note that with the exception of the commands noted in Section 19 6.1.1, "No-Operation Commands" controllers that support only the 20 minimal MSCP command set reject any command not described in this 21 chapter as an "Invalid Command" ("invalid opcode" protocol error. 22 See "Invalid Command" status in Section 5.5, "Status Codes"). 23 Within this chapter a separate major section is dedicated to each 24 minimal command set command. The major section identifies the 25 command by name as well as its permissible command category(s) 26 (see Section 4.5, "Command Categories and Execution Order"). 27 Separate subordinate sections describe the command's command 28 message format, end message format, and (operation) description. 29 The command message format subsection shows the layout of the 30 command message fields and describes their use. (Appendix A, 31 "Opcode, Flag, and Offset Definitions," Table A-6, "Command 32 Message Offsets" defines the size and the preferred mnemonic and 33 numeric value of the offset of the command message fields.) Note 34 that the omission of a parameter field description implies that 35 it functions as described elsewhere in this specification. In 36 particular, the command message header fields (i.e., the "command 37 reference number," "unit number," "opcode," and "modifiers") are 38 described in Section 5.3, "Command Messages" and the fields 39 common to data transfer commands (i.e., "byte count," "buffer 40 descriptor," and "logical block number") are described in Section 41 5.3.1, "Transfer Command Message Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-2 Overview 11 June 1992 1 The command message format subsection also lists the modifiers 2 allowed for the command (modifier use is opcode dependent) and 3 describes their use. Note that the omission of a modifier 4 description implies that it functions as described in Section 5 5.3.2, "Command Modifiers." Note also that any command modifiers 6 other than the ones listed for an individual command are reserved 7 and treated in accordance with the requirements for reserved 8 fields described in Section 5.2, "Reserved and Undefined Fields." 9 The end message format subsection shows the layout of the end 10 message fields and describes their use. (Appendix A, "Opcode, 11 Flag, and Offset Definitions," Table A-7, "End and Attention 12 Message Offsets" defines the size and the preferred mnemonic and 13 numeric value of the offset of the end message fields.) Note that 14 the omission of a parameter field description implies that it 15 functions as described elsewhere in this specification. In 16 particular, the end message header fields (i.e., the "command 17 reference number," "unit number," "sequence number," "endcode," 18 "flags," and "status") are described in Section 5.4, "End 19 Messages" and the fields common to data transfer commands (i.e., 20 "status," "byte count," and "first bad block") are described in 21 Section 5.4.1, "Transfer Command End Message Format." 22 The end message format subsection also lists all the status codes 23 (and subcodes) possible for the command and describes their 24 meaning. Note that the omission of a status description implies 25 that its meaning is defined in Section 5.5, "Status Codes." Note 26 also that the MSCP protocol violation "Invalid Command" statuses 27 are not listed for any of the commands but can occur for each. 28 See "Invalid Command" status in Section 5.5, "Status Codes" for 29 more detail. 30 The description subsection defines the purpose of the command and 31 provides details about the command's operation. In some cases 32 the description subsection relies heavily on the other 33 subsections associated with the command for specific operational 34 details. 35 6.1.1 No-Operation Commands 36 The opcodes listed in the "Standard Command Messages" portion of 37 Appendix A, "Opcode, Flag, and Offset Definitions," Table A-1 as 38 "allocated for future use" act as place holders in anticipation 39 of their use in Volume Shadowing and/or Data Caching. Volume 40 Shadowing and Data Caching have not yet been formalized for disk 41 class devices. Data Caching has, however, been formalized for 42 tape class devices (see the Tape Mass Storage Control Protocol 43 Specification (TMSCP) for details). In order to ensure 44 compatibility with controllers that support Volume Shadowing 45 and/or Data Caching, controllers which do not shall treat those *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-3 Overview 11 June 1992 1 opcodes as no-operations. In other words, controllers that do 2 not support Volume Shadowing and/or Data Caching shall recognize 3 those opcodes and not reject them as "Invalid Commands" and 4 furthermore shall not perform any action that alters the state of 5 the unit, its media, or the controller. 6 The particular actions such a controller may perform in treating 7 those opcodes as no-operations are as follows: 8 1. Treat those opcodes as either Immediate commands or as 9 Non-Sequential commands at its option. (Host command 10 timeout algorithms shall treat them as non-Immediate 11 commands.) 12 2. Construct the end message by making the following 13 changes to the command message: 14 a. Substitute the proper "endcode" for the "opcode." 15 b. Clear the "flags" (end flags) byte, unless the 16 controller has previously verified that the 17 corresponding "rsvd" byte in the command message was 18 zero. (Most controllers will verify that the 19 corresponding "rsvd" byte is zero as part of 20 checking for invalid opcodes.) 21 c. Substitute the "Success" status code combined with 22 the "Normal" status subcode for the "modifiers." 23 The controller may optionally validate the "byte 24 count" and "logical block number" fields to see if 25 they are within proper limits and return the 26 "Invalid Command" status with appropriate subcode if 27 they are not (i.e., validate the command as a 28 transfer command similar to the ACCESS and ERASE 29 commands). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-4 ABORT Command 11 June 1992 1 6.2 ABORT Command 2 Command Category: 3 Immediate 4 6.2.1 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 Shall 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 Allowable modifiers: 26 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-5 ABORT Command 11 June 1992 1 6.2.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-6 ABORT Command 11 June 1992 1 6.2.3 Description 2 The ABORT command causes a specified command to be aborted at the 3 earliest time convenient for the controller. The specified 4 command shall, however, either be aborted or be completed within 5 the controller timeout interval. See Section 4.10, "Command 6 Timeouts," for a discussion of the interaction between ABORT and 7 command timeouts. 8 The ABORT command always succeeds. If the command to be aborted 9 is not known to the controller, this implies that it has already 10 completed and the ABORT command will be ignored. The controller 11 always returns the Success (subcode "Normal") status code/subcode 12 in the ABORT command's end message. 13 The controller may ignore the ABORT command if the command being 14 aborted will always complete within the controller timeout 15 interval. 16 The class driver shall wait for the aborted command's end 17 message, or else resynchronize with the MSCP server, before 18 reusing the aborted command's command reference number or 19 releasing the aborted command's context. If the command was 20 aborted, its end message will contain the "Command Aborted" 21 status code. Otherwise, the command was completed. The class 22 driver may ignore the ABORT command's end message. Note that the 23 class driver may receive the ABORT command's end message either 24 before or after the aborted command's end message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-7 ACCESS Command 11 June 1992 1 6.3 ACCESS Command 2 Command Category: 3 Non-Sequential 4 6.3.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | caa | opcode| 12 +---------------+-------+-------+ 13 | byte count | 14 +-------------------------------+ 15 | | 16 +--- ---+ 17 | reserved | 18 +--- ---+ 19 | | 20 +-------------------------------+ 21 | logical block number | 22 +-------------------------------+ 23 Allowable modifiers: 24 Express Request 25 Clear Serious Exception (ignored for disk class devices) 26 Suppress Error Correction 27 Suppress Error Recovery *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-8 ACCESS Command 11 June 1992 1 6.3.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 (subcode "Normal") 22 Success (subcode "Duplicate Unit Number") 23 Invalid Command (subcode "Invalid Byte Count") 24 Invalid Command (subcode "Invalid Logical Block Number") 25 Command Aborted 26 Unit-Offline 27 Unit-Available 28 Data Error 29 Host Buffer Access Error (subcode "Odd Byte Count") 30 If the communications mechanism does not allow odd byte 31 transfers, the controller may return this status 32 code/subcode despite there being no host buffer. This 33 allows the use of common code for command validation of 34 all transfer commands. Alternatively, the controller may 35 round the byte count up to the nearest whole sector size 36 and perform the operation. 37 Controller Error 38 Drive Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-9 ACCESS Command 11 June 1992 1 6.3.3 Description 2 Data is read from the unit, checked for errors, and discarded. 3 The purpose of this command is to verify that the designated data 4 can be accessed (read) without error. 5 This command is exactly equivalent in function, although not in 6 performance, to a READ whose data is ignored by the host. 7 The caa field will be ignored and the backing store will be read. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-10 AVAILABLE Command 11 June 1992 1 6.4 AVAILABLE Command 2 Command Category: 3 Sequential 4 6.4.1 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 in single host case) 15 Clear Serious Exception (ignored for disk class devices) 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 multiunit drive and 22 this unit shares a spindle with some other unit that is 23 "Unit-Online." See Section 4.16.2, "Multiunit 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." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-11 AVAILABLE Command 11 June 1992 1 6.4.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 Status Codes: 11 Success (subcode "Normal") 12 Success (subcode "Duplicate Unit Number") 13 Success (subcode "Spin-down Ignored") 14 The "Spin-down Ignored" subcode bit flag is set if and 15 only if the "Spin-down" modifier was specified and one or 16 more other units with which this unit shares a spindle is 17 still "Unit-Online," preventing this unit from spinning 18 down. See Section 4.16.2, "Multiunit Drives and 19 Formatters," for an explanation of shared spindles. 20 Success (subcode "Still Connected") 21 The "Still Connected" subcode bit flag is set if and only 22 if this unit may potentially be accessed via another 23 controller and one or more other units with which this 24 unit shares an access path is still "Unit-Online," 25 preventing this unit from being accessed via the other 26 controller (if any). The "Still Connected" subcode bit 27 flag will always be set if the "Spin-down Ignored" bit 28 flag is set. See Section 4.16.1, "Multiaccess Drives," 29 for a discussion of access paths. 30 Command Aborted 31 The command has been rejected and the unit's state has 32 not changed. If the unit was "Unit-Online" prior to 33 issuing this command, then the unit is still 34 "Unit-Online" and it is still spinning. 35 Unit-Offline 36 Controller Error 37 Drive Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-12 AVAILABLE Command 11 June 1992 1 6.4.3 Description 2 All outstanding commands for the specified unit are completed, 3 then the unit becomes "Unit-Available." If the "Spin-down" 4 modifier was not specified, the unit is not already 5 "Unit-Available," and no other units that share this unit's 6 access path are "Unit-Online" (i.e., the "Still Connected" status 7 subcode bit flag is clear), then an AVAILABLE attention message 8 is sent by any other controller to which the unit is connected. 9 The controller to which this command was sent need not itself 10 send an AVAILABLE attention message. 11 If the "Spin-down" modifier is specified, the disk spins down and 12 its heads are unloaded, unless some other unit with which this 13 unit shares a spindle is "Unit-Online." The disk may be spun up 14 with an ONLINE command or by operator intervention. The 15 "Spin-down" modifier also suppresses AVAILABLE attention messages 16 for this unit, both for this controller and any other controllers 17 to which the unit may be connected. See Section 4.3, "Unit 18 States," for a discussion of suppressing AVAILABLE attention 19 messages. 20 This command will be accepted if the unit is "Unit-Online" or 21 "Unit-Available." It is nugatory to issue this command to a unit 22 that is "Unit-Available" unless the "Spin-down" modifier is 23 specified. Assuming no other errors occur, the "Success" status 24 code will be returned regardless of whether the unit was 25 previously "Unit-Online" or "Unit-Available." 26 If the unit was "Unit-Online" but had a duplicate unit number 27 prior to the AVAILABLE command being issued, the AVAILABLE 28 command may complete, at the controller's option, with either a 29 "Success" or a "Unit-Offline" status code. The "Unit-Offline" 30 status code shall have the "Duplicate Unit Number" subcode flag 31 set. The "Success" status code may or may not, at the 32 controller's option, have the "Duplicate Unit Number" subcode 33 flag set. Subsequent attempts to access the unit will return 34 "Unit-Offline" status with the "Duplicate Unit Number" subcode 35 flag set unless the duplicate unit number has been eliminated. 36 When a unit with controller-based write-back cache ceases to be 37 Online, it should write to the media all data contained in the 38 cache but not yet written to the backing store. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-13 COMPARE HOST DATA Command 11 June 1992 1 6.5 COMPARE HOST DATA Command 2 Command Category: 3 Non-Sequential 4 6.5.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | caa | 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 for disk class devices) 25 Express Request 26 Suppress Error Correction 27 Suppress Error Recovery *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-14 COMPARE HOST DATA Command 11 June 1992 1 6.5.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 (subcode "Normal") 22 Success (subcode "Duplicate Unit Number") 23 Invalid Command (subcode "Invalid Byte Count") 24 Invalid Command (subcode "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 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-15 COMPARE HOST DATA Command 11 June 1992 1 6.5.3 Description 2 Data is read from the unit and compared with the data in the host 3 buffer. A "Compare Error" is reported unless the data is 4 identical. Note that the occurrence of any other error, except a 5 "Forced Error," at the same point as the "Compare Error" will 6 override the "Compare Error." Note also that any "Compare 7 Errors" detected by this command shall NOT be reported to the 8 error log. Controllers may retry compare errors detected by this 9 command. Provided the host does not modify the buffer while the 10 transfer is in progress, such retries will have a deleterious 11 effect on performance but cannot alter the final outcome of the 12 command. 13 If a controller-based cache exists, the cache manager may use the 14 Cache Access Attribute advice in managing the caching and 15 comparing of the requested data area. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-16 DETERMINE ACCESS PATHS Command 11 June 1992 1 6.6 DETERMINE ACCESS PATHS Command 2 Command Category: 3 Controller implementation dependent. See Section 6.6.3. 4 6.6.1 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 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-17 DETERMINE ACCESS PATHS Command 11 June 1992 1 6.6.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 Status codes: 11 Success (subcode "Normal") 12 Success (subcode "Duplicate Unit Number") 13 Command Aborted 14 Unit-Offline 15 Unit-Available 16 Controller Error 17 Drive Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-18 DETERMINE ACCESS PATHS Command 11 June 1992 1 6.6.3 Description 2 Class drivers use this command to determine the topology of 3 multiaccess drive configurations (described in Section 4.16.1, 4 "Multiaccess Drives"). When sent to a unit that is 5 "Unit-Online," it causes that unit and any other units that share 6 its access path to identify themselves to any other controller to 7 which they are connected. The MSCP servers in the other 8 controllers will, as a result, become aware that the unit is 9 online via the controller receiving this command. They will then 10 send an ACCESS PATH attention message to their 11 "Controller-Online" class drivers, informing the class drivers of 12 alternate access paths to the unit. This command shall be 13 treated as a no-op that always succeeds if the unit is incapable 14 of being connected to more than one controller. 15 The actual notification to another controller, and thus the 16 sending of an ACCESS PATH attention message, is dependent on the 17 proper functioning of the unit and both controllers. 18 Furthermore, it need not be 100% reliable. That is, assuming the 19 unit and both controllers are functioning properly, there need 20 only be a high probability (better than 50%) that the other 21 controller will in fact be notified and send an ACCESS PATH 22 attention message. For this reason, plus the fact that the 23 topology may change while the unit remains "Unit-Online," hosts 24 that need to know multiaccess drive topology must issue DETERMINE 25 ACCESS PATHS commands to all "Unit-Online" units on a periodic 26 basis, such as once every 5 to 15 minutes. 27 This command in no way affects the unit's actual state with 28 respect to any controller. The unit remains "Unit-Online" via 29 the receiving controller and remains "Unit-Offline" via other 30 controllers. Note, however, that this command may affect the 31 unit's "Unit-Offline" substate 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 shall 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 command 39 timeout algorithms shall treat this as a non-Immediate command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-19 DISK COPY DATA Command 11 June 1992 1 6.7 DISK COPY DATA Command 2 Command Category: 3 Non-Sequential (except as described in Section 6.7.3) 4 6.7.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | rsvd | opcode| 12 +---------------+-------+-------+ 13 | logical block count | 14 +---------------+---------------+ 15 | reserved |src unit number| 16 +---------------+---------------+ 17 | source | 18 +--- unit ---+ 19 | identifier | 20 +-------------------------------+ 21 | destination lbn | 22 +---------------+---------------+ 23 | entry id | hrn or entloc | 24 +---------------+---------------+ 25 | reserved | 26 +-------------------------------+ 27 | source lbn | 28 +-------------------------------+ 29 |source unit's storage subsystem| 30 +--- port ---+ 31 | address | 32 +-------------------------------+ 33 |source unit's storage subsystem| 34 +--- system ---+ 35 | address | 36 +-------------------------------+ 37 unit number 38 Identifies the destination unit -- i.e., the device to 39 which data is to be copied. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-20 DISK COPY DATA Command 11 June 1992 1 | Allowable modifiers: 2 Clear Serious Exception (ignored) 3 Establish Communications Paths 4 To perform a copy operation the server establishes a 5 communications path to the source unit in the same manner 6 as a host class driver -- i.e., establishes a 7 "Controller-Online" connection with the source unit's 8 server (possibly itself) and brings the source unit into 9 the "Unit-Online" state. The server already has a 10 communications path established to the destination; if 11 not, it would reject the command with a status of 12 "Unit-Available" or "Unit-Offline." The communications 13 path is established on behalf of the issuing host class 14 driver. See Section 6.7.3, "DISK COPY DATA Command, 15 Description" for details of the establish communications 16 paths operation. 17 The server rejects the command as an "Invalid Command" 18 ("invalid modifier" protocol error. See "Invalid 19 Command" status in Section 5.5, "Status Codes") if either 20 of the following conditions exist: 21 1. This modifier is clear and communications paths 22 have not been established on behalf of the 23 issuing host class driver. 24 2. This modifier is set and communications paths 25 previously established on behalf of the issuing 26 host class driver are still intact. 27 History Log 28 Reuse Entry 29 The History Log and Reuse Entry modifiers are 30 interdependent and described together here to avoid 31 confusion. 32 Note that the History Log modifier, the Reuse Entry 33 modifier, the "hrn or entloc" field, and the "entry id" 34 field are valid only for servers that provide "write 35 history logging" support (see Section 5.6, "Controller 36 Flags" for related information). 37 The setting of the History Log modifier determines 38 whether information about this command is to be stored in 39 a "write history entry." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-21 DISK COPY DATA Command 11 June 1992 1 The setting of the Reuse Entry modifier determines 2 whether the server is to allocate a new "write history 3 entry" or reuse one that was previously allocated. 4 If "write history logging" is supported, the History Log 5 modifier is set, and the Reuse Entry modifier is clear, 6 the server allocates a new "write history entry" and then 7 stores the value contained in the "hrn (host reference 8 number)" field, "entry id" field, and other information 9 related to this command into the "write history entry" 10 just allocated. If the server has no "write history 11 entry" to allocate, it shall remember this fact. See 12 Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 13 Description" for more details. To report this allocation 14 failure to the host, the server returns FFFF(hex) in the 15 "entry locator" field of the end message and sets the 16 Allocation Failure end flag. See Section 5.4, "End 17 Messages," for a description of this flag. 18 If "write history logging" is supported, the History Log 19 modifier is set, and the Reuse Entry modifier is set, the 20 server uses the value contained in the "entloc (entry 21 locator)" field to locate the associated "write history 22 entry" and then stores the other information related to 23 this command into that "write history entry." 24 See Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 25 Description" for details regarding the maintenance and 26 format of "write history entries." 27 If "write history logging" is supported and the History 28 Log modifier is clear, the server ignores the setting of 29 the Reuse Entry modifier and the contents of the "hrn or 30 entloc" and "entry id" fields. 31 If "write history logging" is not supported and the 32 History Log modifier or the Reuse Entry modifier is set, 33 the server rejects the command as an "Invalid Command" 34 ("invalid modifier" protocol error. See "Invalid 35 Command" status in Section 5.5, "Status Codes"). 36 If "write history logging" is supported, the History Log 37 modifier is set, and the "logical block count" field is 38 zero, the server reject the command as an Invalid Command 39 ("invalid logical block count" parameter error. See 40 "Invalid Command" status in Section 5.5, "Status Codes"). 41 The server shall set the History Logged end flag in this 42 command's end message if it has caused the write history 43 log to contain a valid "write history entry" for this *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-22 DISK COPY DATA Command 11 June 1992 1 command. See Section 5.4, "End Messages," for 2 descriptions of all end message flags. 3 Local Source Unit 4 Host class drivers set this modifier to indicate that the 5 source unit is served by the server that received this 6 command. If this modifier is set, the server ignores the 7 contents of the "source unit's subsystem port address" 8 and the "source unit's subsystem system address" fields. 9 Host class drivers clear this modifier to indicate that 10 the source unit is served by a server located in another 11 storage subsystem. 12 This modifier is ignored by servers that only support 13 Local Disk Copy Data. 14 Retain Communications Paths 15 See the description of the Establish Communications Paths 16 modifier above for information about establishing 17 communications paths. 18 The setting of this modifier determines whether the 19 server should retain the communications paths established 20 on behalf of the issuing host class driver after the copy 21 operation has been aborted, completed, or terminated. 22 If this modifier is set, the server retains the 23 communications paths established on behalf of the issuing 24 host class driver. A host class driver may therefore 25 issue subsequent DISK COPY DATA commands without 26 incurring the overhead associated with the server 27 re-establishing the communications paths. 28 If this modifier is clear, the server performs the 29 operations necessary to disconnect the communications 30 paths established on behalf of the issuing host class 31 driver, upon completion of the request. See Section 32 6.7.3, "DISK COPY DATA Command, Description" for details 33 of the disconnect operation. 34 Note that under certain circumstances the server will 35 disconnect the communications paths established on behalf 36 of the issuing host class driver regardless of the 37 setting of this modifier. The particular circumstances 38 are described in Section 6.7.3, "DISK COPY DATA Command, 39 Description." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-23 DISK COPY DATA Command 11 June 1992 1 Note also that the Communications Paths Retained end flag 2 reflects the state of the communications paths relative 3 to the issuing host as described in the "flags" field 4 description contained in Section 6.7.2, "DISK COPY DATA 5 Command, End Message Format." 6 | logical block count 7 Zero or the total number of logical blocks to be copied 8 from the source unit to the destination unit. 9 If this value is nonzero, certain architectural 10 constraints imposed by the destination unit and the 11 source unit shall be met. The constraints depend on the 12 contents of the "destination lbn" or "source lbn" fields. 13 Those fields shall identify a logical block in the host 14 area of the associated disk volume (i.e., the "lbn" is 15 less than the "unit size" returned in the ONLINE end 16 message) and the "logical block count" shall be less than 17 or equal to the following maximum: 18 unit size - logical block number 19 where "unit size" is the unit's host area size (returned 20 in the ONLINE end message) and "logical block number" is 21 the contents of the associated "lbn" field in the command 22 message. If the "logical block count" is greater than 23 the above maximum for either the destination unit or the 24 source unit, the server rejects the command as an 25 "Invalid Command" ("invalid logical block count" 26 parameter error. See "Invalid Command" status in Section 27 5.5, "Status Codes"). 28 A host class driver should specify a zero value in this 29 field when it is necessary to manipulate the 30 communications paths established on its behalf without 31 performing a copy operation. See the descriptions of the 32 Establish Communications Paths and Retain Communications 33 Paths modifiers later in this section for related 34 information. The server ignores the contents of the 35 "source lbn" and "destination lbn" fields when this field 36 is zero. In addition, if this field is zero and the 37 Local Source Unit modifier is set or the server only 38 supports Local Disk Copy Data, the server ignores the 39 contents of the "source unit's storage subsystem port 40 address" and "source unit's storage subsystem system 41 address" fields as well as the other fields listed above. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-24 DISK COPY DATA Command 11 June 1992 1 src unit number 2 Identifies the source unit -- i.e., the device from which 3 data is to be copied. 4 If the server does not support local copies between units 5 with unlike geometries and copies where the source and 6 destination are the same unit, has indicated this lack of 7 support by setting the Restricted DISK COPY DATA 8 Operations controller flag (see Section 5.6, "Controller 9 Flags") in the SET CONTROLLER CHARACTERISTICS end 10 message, and receives a local DISK COPY DATA command in 11 which either of these conditions exists, it rejects the 12 command as an "Invalid Command" ("invalid src unit 13 number" parameter error. See "Invalid Command" status in 14 Section 5.5, "Status Codes"). 15 If the server supports Remote Disk Copy Data the source 16 unit may be the same as the destination unit, one of the 17 other units served by the server that received this 18 command, or a unit served by a (disk) MSCP server located 19 in another storage subsystem, depending on the the 20 setting of the Local Source Unit modifier and the values 21 specified in this field, the "source unit's storage 22 subsystem port address" field, and the "source unit's 23 storage subsystem system address" field. Note that 24 servers that provide Remote Disk Copy Data support 25 implicitly provide Local Disk Copy Data support. 26 source unit identifier 27 The unique identifier assigned to the source unit as 28 returned in the "unit identifier" end message field of a 29 GET UNIT STATUS, ONLINE, or SET UNIT CHARACTERISTICS 30 command addressed to the source unit. 31 Host class drivers should obtain this information 32 directly from the source unit, via one of the commands 33 listed above, prior to issuing this command. 34 The server compares the value of this field against the 35 "unit identifier" it obtains directly from the source 36 unit. If the values do not match exactly, the server 37 rejects the command as an "Invalid Command" ("invalid 38 source unit identifier" parameter error. See "Invalid 39 Command" status in Section 5.5, "Status Codes"). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-25 DISK COPY DATA Command 11 June 1992 1 destination lbn 2 The logical block number (position) on the destination 3 unit's disk volume at which the copy operation is to 4 start. Write access to the destination unit's disk 5 volume Replacement Control Table as part of the copy 6 operation is prohibited. Therefore, this value shall 7 identify a logical block in the host area of the 8 destination unit's disk volume (i.e., the "destination 9 lbn" is less than the "unit size" returned in the ONLINE 10 end message). If this value is not in the host area, the 11 server rejects the command as an "Invalid Command" 12 ("invalid destination lbn" parameter error. See "Invalid 13 Command" status in Section 5.5, "Status Codes"). 14 hrn or entloc 15 entry id 16 These fields are used in conjunction with the History Log 17 and Reuse Entry modifiers. See the description of those 18 modifiers below. 19 source lbn 20 The logical block number (position) on the source unit's 21 disk volume at which the copy operation is to start. 22 Read access to the source unit's disk volume Replacement 23 Control Table as part of the copy operation is 24 prohibited. Therefore, this value shall identify a 25 logical block in the host area of the source unit's disk 26 volume (i.e., the "source lbn" is less than the "unit 27 size" returned in the ONLINE end message). If this value 28 is not in the host area, the server rejects the command 29 as an "Invalid Command" ("invalid source lbn" parameter 30 error. See "Invalid Command" status in Section 5.5, 31 "Status Codes"). 32 If the server does not support local DISK COPY DATA for 33 transfers in which the source and destination LBNs are 34 different and has indicated this lack of support by 35 setting the Restricted DISK COPY DATA Operations 36 controller flag (see Section 5.6, "Controller Flags") in 37 the SET CONTROLLER CHARACTERISTICS end message, the 38 server rejects the command as an "Invalid Command" 39 ("invalid source lbn" parameter error). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-26 DISK COPY DATA Command 11 June 1992 1 source unit's storage subsystem port address 2 The communications mechanism dependent port address of 3 the storage subsystem to which the source unit is 4 physically connected. The information encoded in this 8 5 byte (64 bit) field is the port address formatted as 6 required by the communications mechanism being used. See 7 Appendix F, "Port Address And System Address Formats" for 8 a description of the formats currently defined. 9 The server ignores this field if either of the following 10 conditions exists: 11 1. The server does not provide Remote Disk Copy 12 Data support -- i.e., only Local Disk Copy Data 13 is supported. 14 2. The server supports Remote Disk Copy Data but 15 the Local Source Unit modifier is set. Note 16 that servers that provide Remote Disk Copy Data 17 support implicitly provide Local Disk Copy Data 18 support. 19 If Remote Disk Copy Data is supported and the Local 20 Source Unit modifier is clear, the server rejects the 21 command as an "Invalid Command" ("source unit's storage 22 subsystem port address" parameter error. See "Invalid 23 Command" status in Section 5.5, "Status Codes") if the 24 content of this field: 25 1. Is not formatted correctly for the 26 communications mechanism being used. 27 2. Identifies the subsystem in which the server 28 receiving this command is located. (Host class 29 drivers shall set the Local Source Unit 30 modifier to request a Local Disk Copy Data 31 operation.) 32 source unit's storage subsystem system address 33 The communications protocol dependent system address of 34 the storage subsystem to which the source unit is 35 physically connected. The information encoded in this 8 36 byte (64 bit) field is the system address value formatted 37 as required by the communications protocol being used. 38 See Appendix F, "Port Address And System Address Formats" 39 for a description of the formats currently defined. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-27 DISK COPY DATA Command 11 June 1992 1 The server ignores this field if either of the following 2 conditions exists: 3 1. The server does not provide Remote Disk Copy 4 Data support -- i.e., only Local Disk Copy Data 5 is supported. 6 2. The server supports Remote Disk Copy Data but 7 the Local Source Unit modifier is set. Note 8 that servers that provide Remote Disk Copy Data 9 support implicitly provide Local Disk Copy Data 10 support. 11 If Remote Disk Copy Data is supported, the Local Source 12 Unit modifier is clear, and this field is not formatted 13 correctly for the communications protocol being used, the 14 server rejects the command as an "Invalid Command" 15 ("source unit's storage subsystem system address" 16 parameter error. See "Invalid Command" status in Section 17 5.5, "Status Codes"). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-28 DISK COPY DATA Command 11 June 1992 1 6.7.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | logical block count | 11 +-------------------------------+ 12 | | 13 +--- ---+ 14 | | 15 +--- subcommand status ---+ 16 | | 17 +--- ---+ 18 | | 19 +---------------+---------------+ 20 | entry id | entry locator | 21 +---------------+---------------+ 22 flags 23 Communications Paths Retained 24 The setting of this end flag indicates whether the 25 communications paths the server established on behalf 26 of the issuing host class driver have been retained. 27 If this end flag is set, the communications paths 28 have been retained. If this end flag is clear, the 29 communications paths have been disconnected. 30 Note that the Communications Paths Retained end flag is 31 only valid in this end message. Furthermore, only the 32 Communications Paths Retained, Error Log Generated, 33 Allocation Failure, and Bad Block Unreported end flags 34 may be returned set in this end message; all other end 35 flags are reserved. 36 logical block count 37 The number of logical blocks successfully copied from the 38 source unit to the destination unit. 39 If an unrecoverable error occurs, the server sets this 40 value equal to the number of contiguous logical blocks 41 beginning with the "destination lbn" that were *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-29 DISK COPY DATA Command 11 June 1992 1 successfully copied to the destination unit prior to the 2 occurrence of the unrecoverable error. 3 If no unrecoverable errors occur during the copy 4 operation, the server sets this value equal to the exact 5 "logical block count" that was specified in the command 6 message. 7 subcommand status 8 This field contains information related to the failure of 9 a subcommand issued by the server to the source unit or 10 the destination unit. 11 The contents of this field are undefined unless this 12 command was terminated with a Subcommand Error status 13 code. If this command is terminated with that status 14 code, the "Destination" or "Source" bit flag (contained 15 in the subcode portion of the status field) identifies 16 which device encountered the condition or error. In 17 cases where multiple conditions or errors have occurred, 18 either on one or on both devices, the server only records 19 and reports the first condition or error detected; all 20 other condition or error context is discarded. 21 The information supplied when this field is valid (i.e., 22 defined) is a portion of the command or end message 23 (depending on the Subcommand Error subcode reported; see 24 the descriptions of those subcodes for more detail) of 25 the subcommand that encountered the condition or error. 26 The portion of the command or end message supplied begins 27 with the message's "unit number" field and ends with the 28 highest field capable of being stored in the space 29 allotted for this field. 30 The purpose of this field is to provide host class 31 drivers with information to aid in recovering from 32 failures that occur during the copy operation. However, 33 when a failure occurs information is only provided for 34 one of the devices involved in the copy operation. The 35 state of the other device cannot be deduced from that 36 information. Host class drivers should therefore query 37 the other device for its current state to determine 38 whether copy operation recovery should be attempted. 39 entry locator 40 If "write history logging" is supported and the History 41 Log modifier is set in the command message, this field 42 contains the value assigned by the server that uniquely *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-30 DISK COPY DATA Command 11 June 1992 1 identifies the internal location of the "history entry" 2 where this command's information was stored. If, 3 however, an allocation failure occurred, this field 4 contains the value FFFF(hex). Otherwise, this field is 5 undefined. 6 This field contains a valid entry locator of a "write 7 history entry" for this command if and only if the 8 History Logged end flag is set in the "flags" field of 9 this end message. 10 See the description of the History Log and Reuse Entry 11 modifiers in Section 6.7.1, "DISK COPY DATA Command, 12 Command Message Format" and Section 6.19.3, "WRITE 13 HISTORY MANAGEMENT Command, Description" for more detail. 14 entry id 15 If "write history logging" is supported and the History 16 Log modifier is set in the command message, the contents 17 of the corresponding command message field is copied 18 without modification to this field. Otherwise this field 19 is undefined. 20 See the description of the History Log and Reuse Entry 21 modifies in Section 6.7.1, "DISK COPY DATA Command, 22 Command Message Format" and Section 6.19.3, "WRITE 23 HISTORY MANAGEMENT Command, Description" for more detail. 24 Status Codes: 25 Success (subcode "Normal") 26 Success (subcode "Duplicate Unit Number") 27 Before returning this status the server performs the 28 following: 29 1. Sets the "logical block count" end message 30 field as described in that field's description. 31 2. If the the Retain Communication Paths modifier 32 is clear, performs the operations necessary to 33 disconnect the communications paths established 34 on behalf of the issuing host class driver. 35 See Section 6.7.3, "DISK COPY DATA Command, 36 Description" for details of the disconnect 37 operations. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-31 DISK COPY DATA Command 11 June 1992 1 Invalid Command (subcode "Invalid Modifier") 2 See the description of the Establish Communications Paths 3 modifier in Section 6.7.1, "DISK COPY DATA Command, 4 Command Message Format" for specific information about 5 this error. Note that if the command is rejected with 6 this status, communications paths are retained only if 7 already established by a previous DISK COPY DATA command. 8 Invalid Command (subcode "Invalid Logical Block Count") 9 Invalid Command (subcode "Invalid Destination LBN") 10 Invalid Command (subcode "Invalid Source LBN") 11 See the descriptions of the "logical block count," 12 "destination lbn," and "source lbn," command message 13 fields in Section 6.7.1, "DISK COPY DATA Command, Command 14 Message Format" for specific information about these 15 errors. 16 Note that communications paths are retained even when the 17 command is rejected with one of these status codes. 18 Invalid Command (subcode "Invalid Src Unit Number") 19 Invalid Command (subcode "Invalid Source Unit Identifier") 20 See the description of the "src unit number" and "source 21 unit identifier" command message fields in Section 6.7.1, 22 "DISK COPY DATA Command, Command Message Format" for 23 specific information about these errors. Note that if 24 the command is rejected with one of these status codes, 25 the communications paths are not retained, regardless of 26 the setting of the Retain Communications Path command 27 modifier. 28 Invalid Command (subcode "Invalid Source Unit's Storage 29 Subsystem Port Address") 30 Invalid Command (subcode "Invalid Source Unit's Storage 31 Subsystem System Address") 32 See the descriptions of the "source unit's storage 33 subsystem port address," and "source unit's storage 34 subsystem system address" command message fields in 35 Section 6.7.1, "DISK COPY DATA Command, Command Message 36 Format" for specific information about these errors. 37 Invalid Command (subcode "Invalid Entry Locator") 38 The value specified in the "entloc (entry locator)" field 39 is not within the limits of the server's "write history 40 entry" set. Note that if the command is rejected with *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-32 DISK COPY DATA Command 11 June 1992 1 this status, communications paths are retained only if 2 already established by a previous DISK COPY DATA command. 3 See the description of the History Log and Reuse Entry 4 modifiers in Section 6.7.1, "DISK COPY DATA Command, 5 Command Message Format" and Section 6.19.3, "WRITE 6 HISTORY MANAGEMENT Command, Description" for more detail. 7 Note that this error can only occur if "write history 8 logging" is supported and the History Log and Reuse Entry 9 modifiers are both set in the command message. 10 Invalid Command (subcode "Invalid Entry Id") 11 The server located the "write history entry" identified 12 in the "entloc (entry locator)" field but found that the 13 "entry id" contained in that entry does not equal the 14 value supplied by a host class driver when that entry was 15 allocated. This status may also be returned if the 16 History Log modifier was set, the Reuse Entry modifier 17 was clear, and the host supplied a value of FFFF (hex) in 18 the "entry id" field. Note that if the command is 19 rejected with this status, communications paths are 20 retained only if already established by a previous DISK 21 COPY DATA command. 22 See the description of the History Log and Reuse Entry 23 modifiers in Section 6.7.1, "DISK COPY DATA Command, 24 Command Message Format" and Section 6.19.3, "WRITE 25 HISTORY MANAGEMENT Command, Description" for more detail. 26 Note that this error can only occur if "write history 27 logging" is supported and the History Log modifier is set 28 in the command message. 29 Command Aborted 30 Before returning this status code the server performs the 31 following: 32 1. Ceases issuing transfer subcommands to the 33 destination unit and the source unit. 34 2. Allows all transfer subcommands that are 35 currently outstanding on the destination unit 36 to complete. Outstanding transfer subcommands 37 issued to the source may be aborted or allowed 38 to complete. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-33 DISK COPY DATA Command 11 June 1992 1 3. Discards any and all data obtained from the 2 source unit and buffered prior to the receipt 3 of the ABORT command as well as any data 4 obtained from the source unit as a result of 5 allowing outstanding transfer subcommands to 6 complete in Step 2 above. 7 4. Sets the "logical block count" end message 8 field as if an unrecoverable error had occurred 9 as described in that field's description. 10 5. If the Retain Communication Paths modifier is 11 clear, performs the operations necessary to 12 disconnect the communications paths established 13 on behalf of the issuing host class driver. 14 See Section 6.7.3, "DISK COPY DATA Command, 15 Description" for details of the disconnect 16 operations. 17 Unit-Available 18 Unit-Offline 19 Write Protected 20 If any of these conditions is detected on the destination 21 unit prior to initiating the copy operation, the server 22 shall reject the command with the appropriate status 23 code. 24 If any of these conditions is detected on the destination 25 unit after the copy operation has been initiated, the 26 server reports it via the Subcommand Error status code. 27 In the case of the Unit-Available and Unit-Offline 28 conditions, the server shall perform the operations 29 necessary to disconnect the communications paths 30 previously established on behalf of the issuing host 31 class driver, if any. See Section 6.7.3, "DISK COPY DATA 32 Command, Description" for details of the disconnect 33 operations. 34 In the case of the Write Protected condition, 35 communications paths are not retained, regardless of the 36 setting of the Retain Communications Paths command 37 modifier. 38 Controller Error (subcode "Remote Connection Lost") 39 The "Controller-Online" connection between the server and 40 a remote source unit's server was spontaneously lost (for *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-34 DISK COPY DATA Command 11 June 1992 1 any reason). 2 Note that unlike a host class driver the server will not 3 attempt to recover from a remote connection lost 4 condition (e.g., re-establish the communications path, 5 reissue previously outstanding commands, etc.). Instead, 6 the server performs the following before returning this 7 status: 8 1. Ceases issuing transfer subcommands to the 9 destination unit. 10 2. Allows all transfer subcommands that are 11 currently outstanding on the destination unit 12 to complete. 13 3. Discards any and all data obtained from the 14 source unit and buffered prior to the 15 occurrence of the connection lost condition. 16 4. Sets the "logical block count" end message 17 field as if an unrecoverable error had occurred 18 as described in that field's description. 19 5. Performs the operations necessary to disconnect 20 the destination unit communications path 21 established on behalf of the issuing host class 22 driver (regardless of the setting of the Retain 23 Communication Paths modifier). See Section 24 6.7.3, "DISK COPY DATA Command, Description" 25 for details of the disconnect operations. 26 6. Sends a DISK COPY DATA CORRELATION information 27 log message with the Controller Error (subcode 28 "Remote Connection Lost") event code to the 29 appropriate host class driver. See Section 30 6.7.3, "DISK COPY DATA Command, Description, 31 Error Logs and Correlation Logs," for related 32 information. 33 Note also that this error can only occur if the source 34 unit is located in a remote subsystem. 35 Controller Error (subcode "Remote Connection Request Failed, 36 Insufficient Resources to Request Remote 37 Connection) 38 Controller Error (subcode "Remote Connection Request Failed, 39 Subsystem Port Address Responded But 40 Subsystem System Address Does Not Match") 41 Controller Error (subcode "Remote Connection Request Failed, *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-35 DISK COPY DATA Command 11 June 1992 1 Subsystem Port Address Responded But No 2 MSCP Server Present") 3 Controller Error (subcode "Remote Connection Request Failed, 4 Subsystem Port Address Responded But No 5 Resources Available") 6 Controller Error (subcode "Remote Connection Request Failed, 7 Subsystem Port Address Responded But No 8 Credits Available") 9 Controller Error (subcode "Remote Connection Request Failed, 10 No Response From Subsystem Port Address") 11 Controller Error (subcode "Remote Connection Request Failed, 12 Subsystem Port Address Responding But 13 Negative Acknowledge Retry Algorithm 14 Exhausted") 15 Controller Error (subcode "Remote Connection Request Failed, 16 Subsystem Port Request Timeout Exceeded") 17 Controller Error (subcode "Remote Connection Request Failed, 18 Subsystem Port Address Responded But 19 Rejected With Disconnected") 20 The server's initial attempt to establish a 21 "Controller-Online" connection with a remote source 22 unit's server failed for the reason indicated by the 23 subcode value. New subcode values for this status may be 24 added as the need arises via an ECO to this 25 specification. 26 The server should check for and report a "subsystem 27 system address" mismatch before checking for and 28 reporting the unavailability of an MSCP server. If that 29 is not possible, a statement to that effect shall appear 30 in the server's (controller's) Functional Specification. 31 Before returning this status code the server shall send a 32 DISK COPY DATA CORRELATION information log message with 33 the appropriate Controller Error (subcode "Remote 34 Connection Request Failed") event code to the appropriate 35 host class driver. See Section 6.7.3.2, "DISK COPY DATA 36 Command, Description, Error Logs and Correlation Logs," 37 for related information. 38 Note that these errors can only occur if the source unit 39 is located in a remote subsystem. 40 Controller Error (subcode "Local Connection Request Failed, 41 Insufficient Resources to Request Local 42 Connection) 43 The server's initial attempt to establish a 44 "Controller-Online" connection with a local source unit's *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-36 DISK COPY DATA Command 11 June 1992 1 server failed due to insufficient controller resources. 2 Note that this error can only occur if the source unit is 3 located in the same subsystem as the server. 4 Write History Entry Access Error (subcode "Allocation Failure 5 Table Full") 6 The server was unable to allocate a "write history entry" 7 and could not record this fact because the Allocation 8 Failure Table was full. This is a transient condition; 9 therefore, the host should reissue the command. See 10 Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 11 Description" for more details. 12 Note that this error can occur only if "write history 13 logging" is supported and the History Log modifier is set 14 and Reuse Entry modifier is clear in the command message. 15 Note also that communications paths are retained, 16 regardless of the setting of the Retain Communications 17 Paths command modifier. 18 Subcommand Error (subcode "Destination -- Command Timed Out") 19 Subcommand Error (subcode "Source -- Command Timed Out") 20 The oldest outstanding subcommand the server issued to 21 the destination unit or the source unit timed out. The 22 subcode bit flag, "Destination" or "Source," identifies 23 the device on which the time out occurred. 24 Note that the server shall implement the command timeout 25 algorithm described in Section 4.10, "Command Timeouts" 26 for all outstanding subcommands in the same manner as a 27 host class driver, with one exception. The only 28 exception is that the server makes no attempt to recover 29 from a command time out failure (e.g., re-establish the 30 communications path, reissue previously outstanding 31 commands, etc.). 32 Note also that the server's command timeout interval may 33 be shorter than the command timeout interval of the 34 remote server. Therefore, the server may indicate 35 "progress" to the host while waiting for the subcommand's 36 longer interval to lapse. 37 Before returning this status the server performs the 38 following: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-37 DISK COPY DATA Command 11 June 1992 1 1. Ceases issuing transfer subcommands to the 2 destination unit and the source unit. 3 2. Allows all transfer subcommands that are 4 currently outstanding on the destination unit 5 and not affected by the command timeout to 6 complete. Outstanding transfer subcommands 7 issued to the source and not affected by the 8 command timeout may be aborted or allowed to 9 complete. 10 3. Discards any and all data obtained from the 11 source unit and buffered prior to the 12 occurrence of the command timeout as well as 13 any data obtained from the source unit as a 14 result of allowing outstanding transfer 15 subcommands to complete in Step 2 above. 16 4. Places the appropriate portion of the timed out 17 command's command message in the "subcommand 18 status" end message field. 19 5. Sets the "logical block count" end message 20 field as if an unrecoverable error had occurred 21 as described in that field's description. 22 6. Performs the operations necessary to disconnect 23 the communications paths established on behalf 24 of the issuing host class driver (regardless of 25 the setting of the Retain Communication Paths 26 modifier). See Section 6.7.3, "DISK COPY DATA 27 Command, Description" for details of the 28 disconnect operations. 29 7. Sends a DISK COPY DATA CORRELATION information 30 log message with the appropriate Subcommand 31 Error event code/subcode to the appropriate 32 host class driver. The "event dependent 33 information" field should contain a copy of the 34 MSCP command message for the subcommand that 35 timed out. See Section 6.7.3.2, "DISK COPY 36 DATA Command, Description, Error Logs and 37 Correlation Logs," for related information. 38 Subcommand Error (subcode "Destination -- Inconsistent 39 State") 40 Subcommand Error (subcode "Source -- Inconsistent State") 41 The server detected an operational inconsistency as a *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-38 DISK COPY DATA Command 11 June 1992 1 result of the execution of a subcommand it issued to the 2 destination unit or the source unit. The subcode bit 3 flag, "Destination" or "Source," identifies the device on 4 which the inconsistent state was detected. 5 This status is returned under the following conditions: 6 A. The source unit is located in a remote 7 subsystem and the Controller Initiated Bad 8 Block Replacement (CIBBR) flag is not set in 9 the end message of the SET CONTROLLER 10 CHARACTERISTICS command issued to a remote 11 source unit's server or the ONLINE command 12 issued to a remote source unit. Note that 13 CIBBR is required on a remote source unit 14 because the server will not provide "Host 15 Initiated Bad Block Replacement." 16 B. The server determines via ONLINE commands 17 issued to the source unit and the destination 18 unit that the sector format (512 bytes or 576 19 bytes) of the source unit is not identical to 20 that of the destination unit. 21 C. An ONLINE command issued to the destination 22 unit or the source unit is completed with a 23 status of Success (subcode "Already Online"). 24 D. An Invalid Command status was returned for a 25 subcommand issued to the destination unit or 26 the source unit. 27 E. 28 | A READ command issued to the source unit, or a 29 | WRITE command issued to the destination unit is 30 | terminated with a status of Host Buffer Access 31 | Error (all subcodes except "Cause Not 32 Available" and "Host Memory Parity Error"). 33 F. An AVAILABLE command issued to the destination 34 unit or the source unit is completed or 35 rejected with a status of Success (subcode 36 "Spin-down Ignored"), Success (subcode "Still 37 Online/Unload Ignored"), or Unit-Available 38 (subcode "Already In Use"). 39 Before returning this status the server performs the 40 following: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-39 DISK COPY DATA Command 11 June 1992 1 1. Ceases issuing transfer subcommands to the 2 destination unit and the source unit. 3 2. Allows all transfer subcommands that are 4 currently outstanding on the destination unit 5 to complete. Outstanding transfer subcommands 6 issued to the source may be aborted or allowed 7 to complete. 8 3. Discards any and all data obtained from the 9 source unit and buffered prior to the detection 10 of the inconsistency as well as any data 11 obtained from the source unit as a result of 12 allowing outstanding transfer subcommands to 13 complete in Step 2 above. 14 4. Places the appropriate portion of the failed 15 command's end message in the "subcommand 16 status" end message field. 17 5. Sets the "logical block count" end message 18 field as if an unrecoverable error had occurred 19 as described in that field's description. 20 6. Performs the operations necessary to disconnect 21 the communications paths established on behalf 22 of the issuing host class driver (regardless of 23 the setting of the Retain Communication Paths 24 modifier). See Section 6.7.3, "DISK COPY DATA 25 Command, Description" for details of the 26 disconnect operations. 27 7. For the last four "Inconsistent State" 28 conditions listed above (i.e., C through F), 29 sends a DISK COPY DATA CORRELATION error log 30 message with the appropriate Subcommand Error 31 event code/subcode to the appropriate host 32 class driver. The "event dependent 33 information" field should contain a copy of the 34 subcommand's end message. See Section 6.7.3.2, 35 "DISK COPY DATA Command, Description, Error 36 Logs and Correlation Logs," for related 37 information. 38 8. The last four "Inconsistent State" conditions 39 listed above (i.e., C through F) indicate a 40 serious malfunction in the server's operation. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-40 DISK COPY DATA Command 11 June 1992 1 After attempting to deliver the end message for 2 the DISK COPY DATA Command, the server shall 3 enter the "Controller-Available" state relative 4 to all hosts. 5 Subcommand Error (subcode "Destination -- Unrecoverable 6 Error") 7 Subcommand Error (subcode "Source -- Unrecoverable Error") 8 An unrecoverable error occurred during the execution of a 9 subcommand issued by the server to the destination unit 10 or the source unit. The subcode bit flag, "Destination" 11 or "Source," identifies the device on which the 12 unrecoverable error occurred. 13 The following are classed as unrecoverable errors: 14 A. Any subcommand issued to the destination unit 15 or the source unit is rejected with any of the 16 following status codes: Controller Error, 17 Drive Error, Media Format Error, 18 Unit-Available, or Unit-Offline. 19 B. 20 | A READ command issued to the source unit, or a 21 | WRITE command issued to the destination unit is 22 | terminated with a status of Host Buffer Access 23 | Error (subcode "Cause Not Available" or "Host 24 Memory Parity Error"). 25 C. 26 | A READ subcommand issued to the source unit is 27 | rejected with either of the following status 28 | codes: Compare Error or Data Error. 29 D. A WRITE subcommand issued to the destination 30 unit is rejected or terminated with any of the 31 following status codes: Compare Error, Data 32 Error, or Write Protected. 33 Before returning this status the server performs the 34 following: 35 1. Ceases issuing transfer subcommands to the 36 destination unit and the source unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-41 DISK COPY DATA Command 11 June 1992 1 2. Allows all transfer subcommands that are 2 currently outstanding on the destination unit 3 or the source unit to complete. 4 3. Discards any and all data obtained from the 5 source unit and buffered prior to the detection 6 of the unrecoverable error. 7 4. Allows all transfer subcommands that are 8 currently outstanding on the destination unit 9 to complete. Outstanding transfer subcommands 10 issued to the source may be aborted or allowed 11 to complete. 12 5. Discards any and all data obtained from the 13 source unit and buffered prior to the detection 14 of the unrecoverable error as well as any data 15 obtained from the source unit as a result of 16 allowing outstanding transfer subcommands to 17 complete in Step 2 above. 18 6. Places the appropriate portion of the failed 19 command's end message in the "subcommand 20 status" end message field. 21 7. Sets the "logical block count" end message 22 field as described in that field's description. 23 8. With the exception of the occurrence of the 24 Media Format Error, Unit-Available, and 25 Unit-Offline error conditions listed in A 26 above, performs the operations necessary to 27 disconnect the communications paths established 28 on behalf of the issuing host class driver if 29 the Retain Communication Paths modifier is 30 clear. 31 If the Media Format Error, Unit-Available, and 32 Unit-Offline error conditions listed in A above 33 occur, performs the operations necessary to 34 disconnect the communications paths established 35 on behalf of the issuing host class driver 36 (regardless of the setting of the Retain 37 Communication Paths modifier). See Section 38 6.7.3, "DISK COPY DATA Command, Description" 39 for details of the disconnect operations. 40 9. Sends a DISK COPY DATA CORRELATION information 41 log message with the appropriate Subcommand 42 Error event code/subcode to the appropriate *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-42 DISK COPY DATA Command 11 June 1992 1 host class driver. The "event dependent 2 information" field should contain a copy of the 3 subcommand's end message. See Section 6.7.3.2, 4 "DISK COPY DATA Command, Description, Error 5 Logs and Correlation Logs," for related 6 information. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-43 DISK COPY DATA Command 11 June 1992 1 6.7.3 Description 2 Support of the DISK COPY DATA command is a server implementation 3 dependent option. Servers that do not provide such support shall 4 reject this command as an "Invalid Command" ("invalid opcode" 5 protocol error. See "Invalid Command" status in Section 5.5, 6 "Status Codes"). 7 For servers that support only local DISK COPY DATA operations, 8 the minimum command length is 44 bytes. For servers that support 9 remote DISK COPY DATA operations, the minimum command length is 10 60 bytes. All DISK COPY DATA commands issued by the host shall 11 be at least as long as the minimum length supported by the 12 server. If a server receives a DISK COPY DATA command that is 13 shorter than the minimum command length, it rejects the command 14 as an "Invalid Command" ("invalid message length" protocol error. 15 See "Invalid Command" status in Section 5.5, "Status Codes"). 16 Servers that support remote DISK COPY DATA shall support remote 17 copies between units with unlike geometries and remote copies 18 where the source LBN and destination LBN differ. All servers 19 should support copies between units with unlike geometries, 20 copies where the source and destination LBN differ, and copies 21 where the source and destination are the same unit. Servers that 22 do not support local copies between units with unlike geometries, 23 local copies where the source and destination LBN differ, and 24 copies where the source and destination are the same unit 25 indicate this lack of support by setting the Restricted DISK COPY 26 DATA Operations controller flag in the SET CONTROLLER 27 CHARACTERISTICS end message (see Section 5.6, "Controller 28 Flags"). 29 This command allows data to be copied from one disk device to 30 another without host intervention. A server may support two 31 different types of copy operations: local and remote. In a 32 local copy operation, both the source and destination disk drives 33 are physically connected to the storage subsystem in which the 34 server that receives this command is located. In a remote copy 35 operation, the destination disk drive is physically connected to 36 the storage subsystem in which the server that received this 37 command is located and the source disk drive is physically 38 connected to another storage subsystem connected to the same 39 communications mechanism. Local copy operations may be supported 40 by servers that provide Multihost Support as well as those that 41 do not. A server that provides Multihost Support may, at its 42 option, support both local and remote copy operations or only 43 local copy operations. However, support of both local and remote 44 copy operations is preferred. A server signifies the type of 45 copy operation it supports by setting the Local Disk Copy Data *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-44 DISK COPY DATA Command 11 June 1992 1 and Remote Disk Copy Data controller flags appropriately. 2 6.7.3.1 Operation 3 To perform a copy operation a host class driver merely specifies 4 the devices that are to act as the data source and data 5 destination, the starting logical block numbers on the source and 6 destination, and the quantity of data to be copied from the 7 source to the destination. The server then performs the 8 following operations to fulfill the host's DISK COPY DATA 9 request: 10 1. Checks the contents of the command message 11 modifiers and fields to ensure that a valid copy 12 operation can be performed. The checks performed 13 are described in (or implied by) the various 14 modifier and field descriptions in Section 6.7.1, 15 "DISK COPY DATA Command, Command Message Format." 16 If any of the checks fail, the command is rejected 17 as an "Invalid Command." 18 Some of the checks require information provided by 19 operations performed in Steps 4, 5, and 6 below. 20 Command message field validation is therefore not 21 complete until those steps have been completed. 22 2. If communications paths to the destination unit and 23 the source unit have already been established on 24 behalf of the issuing host class driver and those 25 paths remain intact, proceeds to Step 6. 26 Otherwise, proceeds to Step 3. 27 3. Performs the internal operations necessary to 28 establish a "Controller-Online" connection with 29 itself to enable communications with the 30 destination unit and in the case of a Local Disk 31 Copy Data (i.e., the Local Source Unit modifier is 32 set or the server only supports Local Disk Copy 33 Data) with the source unit. 34 If the source unit is local, proceeds to Step 4. 35 If the source unit is remote (i.e., it is connected 36 to a storage subsystem other than the one in which 37 the server is located), performs the communication 38 protocol dependent operations necessary to 39 establish a "Controller-Online" connection with the 40 source unit's server (i.e., the remote disk MSCP 41 server) and then proceeds to Step 4. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-45 DISK COPY DATA Command 11 June 1992 1 4. Issues a SET CONTROLLER CHARACTERISTICS commands to 2 itself and, if the source unit is located in a 3 remote subsystem, to the source unit's server, to 4 set an appropriate "host timeout," to request the 5 generation of error logs if required, and to 6 determine the maximum byte count supported. 7 Note that processing related to "host timeout" and 8 error logging is discussed later in this section. 9 5. Issues an ONLINE command to the source unit to 10 bring it into the "Unit-Online" state (relative to 11 the server) and ensures that the destination unit 12 is "Unit-Online." 13 Note that the server shall issue only one ONLINE 14 command if the destination unit is the same as the 15 source unit. 16 6. Issues GET UNIT STATUS commands to the destination 17 unit and the source unit to obtain device 18 characteristics (i.e., disk volume geometry) useful 19 for optimizing the copy operation. 20 Note that during this step the server shall 21 validate the "source unit identifier" command 22 message field using the value returned in the "unit 23 identifier" end message field of the GET UNIT 24 STATUS command issued. See the description of the 25 "source unit identifier" field in Section 6.7.1 for 26 more detail. 27 7. Issues a READ command to the source unit to obtain 28 the source data. 29 8. Issues a WRITE command to the destination unit to 30 copy the source data. 31 9. Steps 7 and 8 are repeated until the copy operation 32 is aborted, completed, or terminated. 33 Note that for subsequent DISK COPY DATA commands 34 issued by the same host class driver the server 35 will not perform Steps 3, 4, and 5 (provided the 36 communications paths involved remain intact). 37 However, the server shall perform Steps 1 and 6 (as 38 well as Steps 7 and 8) for each DISK COPY DATA 39 command received. The server shall retain all 40 information acquired in Steps 4 and 5 that is 41 required to perform Step 1 until the communications *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-46 DISK COPY DATA Command 11 June 1992 1 paths involved are no longer intact. 2 The operations described in the preceding steps provide a 3 simplified model of operation that is solely intended to 4 identify and describe functions that are implied in other 5 sections of this command's description. Any deviations from 6 the model shall be implemented in a manner that guarantees 7 that all host class driver visible results are identical to 8 those described in this command description. 9 The actions the server takes after the copy operation has been 10 aborted, completed, or terminated are described in the various 11 status code descriptions in Section 6.7.2, "DISK COPY DATA 12 Command, End Message Format." 13 Throughout this command description numerous references are made 14 to the effect that the server issues standard MSCP commands (in 15 the same manner as a host class driver). Note that the server is 16 expressly permitted to perform any equivalent internal operation 17 instead of issuing a standard command provided that the following 18 rules are followed: 19 A. The result of the internal operation shall be identical 20 to that of the standard command. 21 B. If the internal operation results in an error, the 22 "subcommand status" end message field shall be set as 23 if a standard command had been issued. 24 Naturally, the use of internal operations is limited to 25 transactions the server can perform on itself and the unit(s) it 26 serves. Standard commands shall be used in all transactions 27 dealing with a remote source unit and its server. 28 The server shall provide "Controller Initiated Bad Block 29 Replacement" (CIBBR) support on all disk drives that it serves -- 30 i.e., the CIBBR controller flag shall be set. 31 The server will not perform "Host Initiated Bad Block 32 Replacement" for a remote source unit. Host class drivers should 33 verify that CIBBR is supported on a remote source unit prior to 34 issuing this command. Failure to do so will result in the 35 rejection of this command with a status of Subcommand Error 36 (subcode "Source -- Inconsistent State"). See the description of 37 that status in Section 6.7.2, "DISK COPY DATA Command, End 38 Message Format," for more detail. 39 As mentioned in the description of the Subcommand Error (subcode 40 "Destination/Source -- Command Timeout) status in Section 6.7.2 41 the server shall implement the command timeout algorithm *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-47 DISK COPY DATA Command 11 June 1992 1 described in Section 4.10, "Command Timeouts" for all outstanding 2 subcommands in the same manner as a host class driver, with one 3 exception. The only exception is that the server makes no 4 attempt to recover from a command time out failure (e.g., reissue 5 previously outstanding commands). 6 With regard to GET COMMAND STATUS commands that specify the 7 "outstanding reference number" of a DISK COPY DATA command the 8 server shall provide status based on the progress of the copy 9 operation in the same manner required for any other command. See 10 Sections 6.11, "GET COMMAND STATUS Command" and 7.5, "Multihost 11 GET COMMAND STATUS Command" for more detail. Note that certain 12 communications protocols (e.g., SCA) do not provide a direct 13 method for determining whether a remote subsystem exists. If 14 such a communications protocol is in use, the server's request to 15 establish a "Controller-Online" connection with a remote source 16 unit's server will never complete if the subsystem does not 17 exist. To allow host class drivers to react to such an 18 occurrence the server shall not show progress for a DISK COPY 19 DATA command where the source unit is located in a remote 20 subsystem until after the "Controller-Online" connection to the 21 remote subsystem has been successfully established. That action 22 will eventually cause the host class driver to timeout the 23 affected DISK COPY DATA command as described in Section 4.10, 24 "Command Timeouts." In such a case it is highly recommended that 25 a host class driver not resynchronize with the server without 26 first checking that it can still access the remote source unit. 27 If the remote source can no longer be accessed, the host class 28 driver should issue an ABORT command referencing the affected 29 DISK COPY DATA command. In response to such an ABORT command the 30 server shall cancel the connection establishment request and 31 terminate the command in the normal fashion. If the remote 32 source unit can still be accessed, the host class driver should 33 assume that the server may be insane and perform the normal 34 command timeout operations as prescribed. 35 The server shall not limit the use of a particular destination 36 unit or source unit to copy operations requested by any single 37 host class driver. Communications paths established on behalf of 38 multiple class drivers may be managed in any manner convenient to 39 the server. Regardless of the method used for communications 40 path management the server shall: 41 A. Maintain state context separately for each host class 42 driver to give the appearance that a communications 43 path is established solely on an individual host class 44 driver's behalf. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-48 DISK COPY DATA Command 11 June 1992 1 B. Associate the communications paths established on a 2 particular host class driver's behalf with the 3 "Controller-Online" connection established between the 4 server and that host class driver. (This association 5 is provided to ensure that the communications paths are 6 dissolved following the loss of a "Controller-Online" 7 connection.) 8 The server shall disconnect the communications paths established 9 on behalf of a host class driver under the following 10 circumstances if and only if the Retain Communications Paths 11 modifier is clear: 12 A. This command is aborted -- i.e., status is Command 13 Aborted. 14 B. This command is completed successfully -- i.e., status 15 is Success (subcode "Normal"). 16 C. An unrecoverable error occurred during the execution of 17 a subcommand issued by the server to the destination 18 unit or the source unit -- i.e., this command is 19 terminated with a Subcommand Error (subcode 20 "Destination/Source -- Unrecoverable Error") status, 21 all causes except Media Format Error, Unit-Available, 22 and Unit-Offline. 23 Regardless of the setting of the Retain Communications Paths 24 modifier the server shall disconnect the communications paths 25 established on behalf of a host class driver under the following 26 circumstances: 27 A. The "Controller-Online" connection to the host class 28 driver is lost -- i.e., the server becomes 29 "Controller-Available" or "Controller-Offline" relative 30 to the issuing host class driver. 31 B. The destination unit enters the "Unit-Available" or 32 "Unit-Offline" state relative to the host class driver 33 -- i.e., this command is rejected with a Unit-Available 34 or Unit-Offline status. 35 C. An unrecoverable error occurred during the execution of 36 a subcommand issued by the server to the destination 37 unit or the source unit -- i.e., this command is 38 terminated with a Subcommand Error (subcode 39 "Destination/Source -- Unrecoverable Error") status, 40 only if the error status is Media Format Error, 41 Unit-Available, or Unit-Offline. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-49 DISK COPY DATA Command 11 June 1992 1 D. The "Controller-Online" connection to a remote source 2 unit's server is lost -- i.e., this command is 3 terminated with a Controller Error (subcode "Remote 4 Connection Lost") status. 5 E. A subcommand issued by the server to the destination or 6 the source unit is timed out -- i.e., this command is 7 terminated with a Subcommand Error (subcode 8 "Destination/Source -- Command Timed Out") status. 9 F. An inconsistent state is detected by the server -- 10 i.e., this command is terminated with a Subcommand 11 Error (subcode "Destination/Source -- Inconsistent 12 State") status. 13 The server performs the following operations to disconnect the 14 communications paths established on behalf of a host class 15 driver: 16 A. Discards the communications path state context being 17 maintained on behalf of the issuing host class driver. 18 B. Issues an AVAILABLE command to the destination unit. 19 Note that the server shall not issue this command if 20 the disconnect is being performed as a result of a 21 command time out failure on the destination unit. 22 C. Issues an AVAILABLE command to the source unit. 23 Note that the server shall not issue this command if 24 the disconnect is being performed as a result of a 25 command time out failure on the source unit or if the 26 destination unit is the same as the source unit. 27 D. Performs the internal operations necessary to 28 disconnect the internal "Controller Online" connection 29 to itself. 30 E. If the source unit is located on a remote subsystem, 31 performs the communications protocol dependent 32 operations necessary to disconnect the "Controller 33 Online" connection between itself and the source unit's 34 server. 35 Note that if a communications path is shared among multiple host 36 class drivers, the server shall not perform any of the disconnect 37 steps described above that would result in the loss of a 38 communications path established on behalf of a host class driver 39 other than the issuing host class driver. That is, the server *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-50 DISK COPY DATA Command 11 June 1992 1 shall not disconnect the communications path established on 2 behalf of a host class driver unless the server is processing a 3 DISK COPY DATA command issued by that host class driver. 4 To prevent needless consumption of remote source unit server 5 resources in cases where the server spontaneously loses context 6 (e.g., crashes, power failures) after having established and 7 retained a communications path on behalf of a host class driver, 8 the server shall perform the following: 9 A. Supply an implementation dependent "host timeout" value 10 in the SET CONTROLLER CHARACTERISTICS command issued to 11 the remote source unit's server in Step 4 above. 12 The "host timeout" value supplied should be large 13 enough to not cause a timeout on the communications 14 path established and retained on behalf of a host class 15 driver while the "Controller-Online" connection between 16 that host class driver and the server remains intact 17 and operations appear to be normal. 18 B. Whenever a DISK COPY DATA command that involves the 19 remote source unit (and the associated communications 20 path) is not currently in progress, periodically issue 21 an innocuous command (e.g., GET UNIT STATUS) to the 22 remote source unit at intervals no greater than the 23 "host timeout" supplied. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-51 DISK COPY DATA Command 11 June 1992 1 The chart below summarizes the condition under which the server 2 retains or terminates communications paths prior to returning the 3 DISK COPY DATA end message. 4 +-----------------------------------+------------+--------------+ 5 | | Retain CP | Comm Paths | 6 | End Message Status Code/Subcode | modifier | Retained | 7 | |in cmd mess | end flag | 8 +-----------------------------------+------------+--------------+ 9 | Success, subcodes | | | 10 | "Normal" | | | 11 | "Duplicate Unit Number" | Set | | 12 | Command Aborted | | | 13 | Subcommand Error, subcode +------------+--------------+ 14 | "Src/Dst Unrecoverable Error" (1)| Clear | Clear | 15 +-----------------------------------+------------+--------------+ 16 | Invalid Command, subcodes | | | 17 | "Invalid Source LBN" | | Set | 18 | "Invalid Destination LBN" | | (Comm Paths | 19 | "Invalid Logical Block Count" | | always | 20 | "Invalid Entry ID" | | retained) | 21 | "Invalid Entry Locator" | | | 22 | Write Hist Entry Access Error | | | 23 | "Allocation Failure Table Full" | | | 24 +-----------------------------------+ +--------------+ 25 | Invalid Command, subcodes | | Set if Comm | 26 | "Invalid Modifier" | | Paths up from| 27 | | | previous DCD;| 28 | | | no otherwise.| 29 +-----------------------------------+ +--------------+ 30 | Invalid Command, subcodes | | | 31 | "Invalid Src Unit Number" | | Clear | 32 | "Invalid Src Unit Identifier" | Ignored | (Comm Paths | 33 | Controller Error (all subcodes) | | never | 34 | Subcommand Error, subcodes | | retained) | 35 | "Src/Dst Unrecoverable Error" (2)| | | 36 | "Src/Dst Command Timed Out" | | | 37 | "Src/Dst Inconsistent State" | | | 38 +-----------------------------------+ +--------------+ 39 | Invalid Command, subcodes | | | 40 | "Invalid Source Unit's Storage | | Clear. Server| 41 | Subsystem Port Address" | | rejects the | 42 | "Invalid Source Unit's Storage | | DCD command. | 43 | Subsystem System Address" | | Comm Paths | 44 | Unit Available | | do not get | 45 | Unit Offline | | established. | 46 | Write Protected | | | 47 +-----------------------------------+------------+--------------+ *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-52 DISK COPY DATA Command 11 June 1992 1 Notes: 2 1. All cases except Media Format Error, Unit-Available, Unit- 3 Offline. So, errors like Data Error on a READ subcommand 4 only cause the server to terminate the communications 5 paths if the Retain CP modifier is clear. 6 2. Reports cases where a subcommand is rejected with Media 7 Format Error, Unit-Available, or Unit-Offline status. 8 The server shall not request attention messages (i.e., set the 9 Enable Attention Messages controller flag) from a remote source 10 unit's server via the SET CONTROLLER CHARACTERISTICS command 11 issued in Step 4 above. Therefore, host class drivers should set 12 the "Enable Attention Messages" flag via a SET CONTROLLER 13 CHARACTERISTICS command issued over a separate 14 "Controller-Online" connection to the remote source unit's server 15 if attention messages related to that unit are desired. 16 The server shall not attempt to change the current device 17 characteristics of the source unit via the ONLINE command issued 18 in Step 5 above. If a host class driver requires certain source 19 unit characteristics to be set, it should set them prior to 20 issuing this command. 21 The server shall execute a DISK COPY DATA command as a 22 Non-Sequential command -- i.e., in relation to all other commands 23 addressed to the destination unit, the transfer subcommands the 24 server issues to the destination unit as part of the copy 25 operation may be reordered to optimize performance, may be 26 interleaved with other Non-Sequential commands, and all of them 27 shall be completed before the execution of a Sequential command 28 can be initiated. Host software developers are advised to give 29 careful consideration to the effects of issuing a lengthy DISK 30 COPY DATA command on Sequential command execution. 31 The only exception to the Non-Sequential execution just described 32 is that access to the server's "immediate target" on the 33 destination unit is controlled. The server's "immediate target" 34 is the range of logical blocks on the destination unit that the 35 server is about to act upon or is currently acting upon. To be 36 more specific the "immediate target" is the range of logical 37 blocks specified in the READ subcommand used to obtain a fragment 38 of source data and the WRITE subcommand used to copy the 39 resultant data to the destination unit. 40 Access to the server's "immediate target" on the destination unit 41 shall be controlled according to the following rules: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-53 DISK COPY DATA Command 11 June 1992 1 a. If a command that specifies a range of logical blocks 2 that is within or overlaps the server's "immediate 3 target" is currently in progress, the server postpones 4 issuing any subcommands that affect the "immediate 5 target" until such an in progress command completes, 6 terminates, or is aborted. 7 b. If a command that specifies a range of logical blocks 8 that is within or overlaps the server's "immediate 9 target" is received while server action on the 10 "immediate target" is postponed (as described in "a" 11 above), the server postpones the execution of the 12 command received until the subcommands that affect the 13 "immediate target" have been initiated and have then 14 completed or terminated. 15 c. If a command that specifies a range of logical blocks 16 that is within or overlaps the server's "immediate 17 target" is received while the subcommands that affect 18 the "immediate target" are currently in progress, the 19 server postpones the execution of the command received 20 until the subcommands that affect the "immediate 21 target" have been completed or terminated. 22 The effect of these rules is to treat access to the server's 23 "immediate target" as Sequential operations. When selecting the 24 number of logical blocks to be included in a server's "immediate 25 target," server developers are advised to give careful 26 consideration to the effects of postponing host I/O to the 27 "immediate target." 28 The reason for providing the "immediate target" access behavior 29 described above is to allow host class drivers to perform write 30 type operations (i.e., DISK COPY DATA, ERASE, and WRITE) on the 31 destination unit in a manner that guarantees that while a DISK 32 COPY DATA command is in progress, all data written to logical 33 blocks on the destination unit will be identical to those 34 contained on the source unit. To fulfill that guarantee, host 35 class drivers shall ensure that write operations that specify a 36 range of logical blocks that is within or overlaps the range of 37 logical blocks specified in a DISK COPY DATA command are issued 38 to the source unit and completed there before the equivalent 39 operation is issued to the destination unit. 40 Note that the result of a read type operation (i.e., ACCESS, 41 COMPARE HOST DATA, and READ) issued to the destination unit that 42 specifies a range of logical blocks that is within or overlaps 43 the range of logical blocks specified in a DISK COPY DATA command 44 is unpredictable. Host class drivers should therefore rely 45 solely on the contents of the source unit for read type *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-54 DISK COPY DATA Command 11 June 1992 1 operations. 2 6.7.3.2 Error Logs And Correlation Logs 3 All error logs generated due to the execution of a DISK COPY DATA 4 command are handled by the server and returned to the appropriate 5 host class drivers, irrespective of whether the error originated 6 from the destination unit, a local source unit, or a remote 7 source unit. 8 For error logs generated as a result of subcommands issued to the 9 destination and source units the server performs the following 10 operations: 11 A. Sets the "command reference number" field equal to the 12 value supplied in the "command reference number" field 13 of the related DISK COPY DATA command message. 14 B. If the error log message is from the source unit, sets 15 the Informational error log message flag. 16 C. If the error log message is from a remote source unit, 17 sets the Disk Copy Data Correlate error log message flag 18 and remembers that at least one error log associated 19 with this command has been delivered so that one DISK 20 COPY DATA CORRELATION error log message may be delivered 21 to the appropriate class drivers prior to the delivery 22 of the end message for this particular DISK COPY DATA 23 command. 24 D. Sends the modified message to the appropriate host class 25 drivers. 26 | E. If a source unit communications path is shared by 27 | multiple host class drivers, the server shall treat 28 error logs received over that path according to the 29 following rules (assuming that the host class driver has 30 properly enabled error logging): 31 1. Error logs generated by subcommands issued on behalf 32 of an individual host class driver shall be sent 33 only to that particular host class driver. 34 2. Error logs generated by subcommands issued on behalf 35 of all the host class drivers that share the same 36 path shall be sent to all the host class drivers 37 sharing that path. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-55 DISK COPY DATA Command 11 June 1992 1 Prior to sending the end message for a particular DISK COPY DATA 2 command, the server generates a DISK COPY DATA CORRELATION error 3 log and delivers it to the appropriate class drivers for the 4 following cases: 5 1. The server determines that the source or destination 6 unit is in an inconsistent state for any of the reasons 7 described in Section 6.7.2, "DISK COPY DATA Command, End 8 Message Format," except: Controller Initiated Bad Block 9 Replacement is not supported by the remote source unit's 10 server or the source and destination units have 11 different formats. 12 The event code is the same as the status code returned 13 in the DISK COPY DATA command's end message (see Section 14 6.7.2, "DISK COPY DATA Command, End Message Format"). 15 The "event dependent information" field should contain a 16 copy of the subcommand's end message. 17 2. The status code returned in the end message of a 18 subcommand issued to the source or destination unit 19 indicates an unrecoverable error other than Unit 20 Available, Unit Offline, or Write Protected. 21 The event code is the same as the status code returned 22 in the DISK COPY DATA command's end message (see Section 23 6.7.2, "DISK COPY DATA Command, End Message Format"). 24 The "event dependent information" field should contain a 25 copy of the subcommand's end message. 26 3. The server fails to establish a connection to or 27 spontaneously loses an established connection to the 28 remote source unit's server. 29 The event code is the same as the Controller Error 30 status code returned in the DISK COPY DATA command's end 31 message (see Section 6.7.2, "DISK COPY DATA Command, End 32 Message Format"). 33 4. The server times out the oldest outstanding command to 34 either the source or destination unit. 35 The event code is the same as the status code returned 36 in the DISK COPY DATA command's end message (see Section 37 6.7.2, "DISK COPY DATA Command, End Message Format"). 38 The "event dependent information" field should contain a 39 copy of the subcommand's command message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-56 DISK COPY DATA Command 11 June 1992 1 5. At least one error log has been delivered as described 2 in item C of the previous list. 3 The event code is Informational (subcode "Disk Copy Data 4 Correlation"). 5 Note that if more than one of the above conditions exists, the 6 DISK COPY DATA CORRELATION error log shall be as specified by the 7 lowest numbered condition. That is, the conditions listed above 8 are ordered by priority. 9 The server shall send the DISK COPY DATA CORRELATION error log 10 and the error logs modified as described above only to host class 11 drivers that have enabled error logging by setting the Enable 12 This Host's Error Logs controller flag or setting the Enable 13 Other Host's Error Logs controller flag in a SET CONTROLLER 14 CHARACTERISTICS command. 15 The server performs the following special actions with regard to 16 the source unit communications path established on behalf of a 17 host class driver when error logging is enabled as previously 18 described: 19 A. If a host class driver enables error logging before a 20 source unit communications path has been established, 21 the server shall set the Enable This Host's Error Logs 22 controller flag via the SET CONTROLLER CHARACTERISTICS 23 command issued to the source unit's server in Step 4 24 above. 25 B. If a host class driver enables error logging after a 26 source unit communications path has been established, 27 the server shall issue a SET CONTROLLER CHARACTERISTICS 28 command to the source unit's server to set the Enable 29 This Host's Error Logs controller flag for that 30 connection before issuing any other subcommand to the 31 source unit. 32 C. If any host class driver or server action occurs which 33 causes error logging to be disabled after the server has 34 issued a SET CONTROLLER CHARACTERISTICS command to the 35 source unit's server to set the Enable This Host's Error 36 Logs controller flag on a connection, the server shall 37 issue a SET CONTROLLER CHARACTERISTICS command to the 38 source unit's server to clear the Enable This Host's 39 Error Logs controller flag for that connection before 40 issuing any other subcommand to the source unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-57 DISPLAY Command 11 June 1992 1 6.8 DISPLAY Command 2 Command Category: 3 Controller implementation dependent. See Section 6.8.3 4 6.8.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | rsvd | opcode| 12 +---------------+-------+-------+ 13 | mode | item | 14 +---------------+---------------+ 15 | | 16 / display / 17 / text / 18 | | 19 +-------------------------------+ 20 item 21 | Identifies the information meant to be conveyed to an 22 | operator. Qualifies the interpretation of the mode and 23 display text fields. See description below. 24 mode 25 | Identifies the mode or state of the information meant to 26 | be conveyed to an operator. Often represented as an icon 27 or by the visual rendition of the information. See 28 description below. 29 display text 30 | One or more text strings containing the information meant 31 | to be conveyed to an operator. The contents of the item 32 and mode fields determine the expected number of text 33 strings and their interpretation; see description below. 34 Each text string consists of one byte containing the 35 length followed by that number of bytes encoding 36 characters from the ISO Latin-1 character set. A length 37 byte that contains zero is followed by no characters and 38 denotes a null or zero length string. While ISO Latin-1 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-58 DISPLAY Command 11 June 1992 1 | is the character set encoding, operator communication 2 | devices need only implement those characters that are 3 meaningful for the specified item and mode on that 4 device. Multiple text strings are concatenated without 5 any intervening bytes. Any bytes between the last text 6 string and the end of the command message shall contain 7 zeros, denoting null strings. 8 If the host supplies fewer than the expected number of 9 text strings, then the MSCP server shall append null 10 strings (zero bytes) to make up the difference. If the 11 host supplies more than the expected number of text 12 strings, and the extra strings are null, then the extra 13 strings shall be ignored. If any extra string is not 14 null, the server shall ignore the string if the "Must Be 15 Implemented" modifier is clear or reject the command if 16 that modifier is set. If the length byte of a string 17 specifies that the string extends past the end of the 18 command message, the server shall truncate the string at 19 the end of the command message; this is not considered an 20 error. 21 The following example display text field shows each 22 byte's value in hexadecimal and the equivalent ISO 23 Latin-1 character in parentheses. This example specifies 24 "VMSRL5" as the first string followed by "Placez" as the 25 second string. These are followed by null third and 26 fourth strings; these two strings would be ignored if the 27 item and mode field values implied that only two strings 28 were expected. 29 +-------+-------+-------+-------+ 30 | 73(S) | 4D(M) | 56(V) | 06 | 31 +-------+-------+-------+-------+ 32 | 06 | 35(5) | 4C(L) | 52(R) | 33 +-------+-------+-------+-------+ 34 | 63(c) | 61(a) | 6C(l) | 50(P) | 35 +-------+-------+-------+-------+ 36 | 00 | 00 | 7A(z) | 65(e) | 37 +-------+-------+-------+-------+ 38 Allowable modifiers: 39 Must Be Implemented 40 If clear, the MSCP server shall ignore and return success 41 for an unimplemented DISPLAY operation. If set, the MSCP 42 server shall reject and return the appropriate "Invalid 43 Command" status for an unimplemented DISPLAY operation. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-59 DISPLAY Command 11 June 1992 1 6.8.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 Status Codes: 11 Success (subcode "Normal") 12 Either the requested DISPLAY operation is implemented and 13 has been successfully accomplished, or it is not 14 implemented and the "Must Be Implemented" modifier was 15 clear. 16 Invalid Command (subcode "Invalid Opcode") 17 The unit or controller does not implement the DISPLAY 18 command in its entirety. 19 Invalid Command (subcode "Invalid Item") 20 The specified display item code is not implemented and 21 the "Must Be Implemented" modifier was set. 22 Invalid Command (subcode "Invalid Mode") 23 The specified display mode is not implemented for the 24 specified display item and the "Must Be Implemented" 25 modifier was set. 26 Invalid Command (subcodes "Invalid Display Text") 27 The specified display text is invalid or not implemented 28 for the specified display item and mode. Note that many 29 different subcodes may be returned, as the subcode 30 indicates the location of the invalid display text. The 31 following conditions return these subcodes: 32 1. The host supplied a non-null value for an extra or 33 unimplemented string and the "Must Be Implemented" 34 modifier was set. The subcode indicates the location 35 of the offending string's length byte. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-60 DISPLAY Command 11 June 1992 1 2. The host did not supply a value or it supplied a null 2 value for a string that requires a non-null value. 3 The subcode indicates the location of the offending 4 string's length byte. Note that the subcode may 5 indicate a location past the end of the command 6 message if the host did not supply a value for the 7 string. 8 3. The host supplied a value that is invalid due to 9 being either too long or too short. The subcode 10 indicates the location of the offending string's 11 length byte. 12 4. The host supplied a value that contains an invalid 13 character. The subcode indicates the location of the 14 offending character. 15 Command Aborted 16 Unit-Offline 17 Unit-Available 18 The specified display operation is implemented but is 19 inappropriate in the unit's current state. These status 20 codes shall not be returned for unimplemented display 21 operations. 22 Controller Error 23 Drive Error 24 | Media Loader Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-61 DISPLAY Command 11 June 1992 1 6.8.3 Description 2 | A controller may, at its option, treat the DISPLAY command as 3 | either an Immediate, Sequential, or Non-sequential command. Host 4 | command timeout algorithms shall treat it as a non-Immediate 5 | command. 6 | The DISPLAY command conveys information meant to be communicated 7 | to an operator. Some devices implement device displays to 8 | communicate with human operators. A device display provides a 9 | means of displaying text and other information associated with a 10 | particular device or unit. Other devices may pass the 11 | information to a robotic operator, such as a media loader. This 12 | specification architects the intent or meaning of the information 13 | being conveyed. Whether or not particular information can be 14 | communicated, the means of communication, the nature of the 15 | operator communicated to, and the result of such communication 16 | are device and operator dependent. 17 The conceptual model for use of the DISPLAY command is a 18 simplified version of the model for forms management systems such 19 | as DECforms. Information is presented in a manner analogous to a 20 pre-printed form. A form dictates the arrangement of fields, how 21 they appear or are separated, and can provide fixed explanatory 22 text. Forms also contain variable fields whose contents are 23 supplied by an application program. 24 A key feature of forms management systems is that the format and 25 appearance of a form is kept separate from supplying information 26 contained in the form. The application passes information to the 27 run-time control portion of the forms system, called the Forms 28 Control System. The Forms Control System presents the 29 information using a form layout appropriate to the particular 30 display device. Form layouts can be defined for new display 31 devices or be redefined for existing devices at any time, without 32 any application modifications. Also, display devices need not be 33 visual displays: voice output, tactile output, or other 34 nonvisual devices might be used. 35 In this forms management system model, the DISPLAY command 36 corresponds to the interface between the application and the 37 Forms Control System. The host class driver, together with other 38 host software, acts as the application. The DISPLAY command is 39 the means by which the host passes information to the Forms 40 Control System associated with a drive. 41 The Forms Control System associated with a drive has complete 42 control of the appearance of the device display. It takes the 43 information provided by the host via the DISPLAY command and 44 presents it in whatever manner the drive designers deemed *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-62 DISPLAY Command 11 June 1992 1 appropriate. In effect, each new drive design incorporates a new 2 display device and the drive designers must define the layout of 3 the MSCP DISPLAY command form on that display device. Note that 4 not all information need appear in the layout. That is, the form 5 layout for a device might ignore and not display certain 6 | information that is unimportant for that device. A device with 7 | suitable hardware capability might act on the information 8 | directly, rather than waiting for a human operator to perform 9 | equivalent actions. Or the drive designers might prioritize the 10 available information and only display the most important, 11 perhaps using drive state or other internal information sources. 12 Such techniques are typically used to fit within the constraints 13 of a small physical display. 14 Whereas general purpose forms management systems typically deal 15 | with many forms, the DISPLAY command only deals with one. That 16 is, there is a single form, a single set of variable fields whose 17 contents can be specified by the host. The logical definition of 18 this single form, its variable fields and their meaning, is 19 specified here as part of the DISPLAY command definition. 20 Changes to this logical form definition are ECOs to this 21 specification. However, the layout or appearance of the 22 information is part of individual device designs; new or changed 23 layouts for this information need not be reflected in this 24 specification. 25 The item field of the DISPLAY command designates a variable field 26 in the device display form. Item field values are defined below; 27 those definitions specify the meaning, interpretation, or 28 semantic content of the information in that field. The mode and 29 display text fields provide the information for that field. The 30 mode field provides nontextual or state information. It is 31 typically used with items that can be in one of several states or 32 modes. The drive designer might choose to present this 33 information by displaying a keyword describing the mode, 34 displaying an icon designating the mode, by changing the visual 35 rendition of the field, or by any other means. The display text 36 field provides textual information that might be displayed in 37 that field. The drive designer may alter the text or choose to 38 not display it at all, so long as its meaning is preserved. 39 Often, state information is conveyed in both the mode field and 40 as a string in the display text field. 41 A unit or controller that does not implement the DISPLAY command 42 at all shall return "Invalid Command" status with an "Invalid 43 Opcode" subcode for this command. A controller may implement the 44 DISPLAY command for some units but not for others. A unit or 45 controller that does implement the DISPLAY command may 46 selectively implement the item and mode field values appropriate 47 to that device, subject to the restrictions on individual item *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-63 DISPLAY Command 11 June 1992 1 and mode combinations described below. Not implementing an item 2 or mode field value is equivalent to determining that that 3 information is irrelevant to the device and need never be 4 | displayed or utilized. The host can use the "Must Be 5 Implemented" modifier to indicate that the host considers the 6 information to be important, so that the item and mode field 7 value must be implemented and presented to the operator or else 8 an error returned. 9 If the "Must Be Implemented" modifier is clear, a unit or 10 controller that implements the DISPLAY command shall ignore 11 DISPLAY commands that request unimplemented display operations. 12 Hosts will typically use this for advisory messages, where the 13 host will continue with the same actions regardless of whether 14 | the information is actually displayed or otherwise utilized by 15 | the device. 16 If the "Must Be Implemented" modifier is set, a unit or 17 controller that implements the DISPLAY command shall return 18 "Invalid Command" status for DISPLAY commands that request 19 unimplemented display operations. Hosts will typically use this 20 | when absence of a device display or other device specific means 21 | of satisfying the request requires that the host communicate the 22 information via another means. 23 All item and mode field values are defined below. An ECO adding 24 new item and mode field values to this list must be approved 25 before any device can implement the new values. 26 Item = 0, Mode = any 27 Item 0 shall never be implemented by any display device. Hosts 28 may use this item field value to determine if the DISPLAY command 29 is implemented with the assurance that no display information 30 will be altered. 31 Item = any, Mode = 0 32 Mode 0 shall be implemented for every implemented item; it is not 33 implemented for unimplemented items. Mode 0 restores the 34 specified display item to its default state upon reset or 35 power-up, typically blank or empty. Mode 0 expects no text 36 strings regardless of the item field value. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-64 DISPLAY Command 11 June 1992 1 | Item = 1 Volume Identification 2 | Item 1 identifies the volume associated with the unit or the 3 volume mounted on the unit. For all nonzero mode values the 4 | first text string is the volume label. Device displays shall 5 support at least the number of characters and character set that 6 the applicable volume format standard allows for volume labels. 7 | If a device display is present, any character not displayable by 8 the device display is invalid. For most disk devices the 9 applicable standard is Files-11, which in the past has allowed up 10 to 12 characters from the upper case alphabet, digits, dollar 11 sign, underscore, and space. For most tape devices the 12 applicable standard is the ANSI tape label standard, which in the 13 past has allowed up to 6 characters from the upper case alphabet, 14 digits, dollar sign, underscore, space, and the following special 15 characters: 16 ! " % ' ( ) * + , - . / : ; < = > ? 17 Implementors are responsible for verifying that their device 18 supports the current version of the applicable standard. They 19 shall not assume that the above description is current. 20 Any unit that implements display item 1 shall implement the three 21 modes 0, 1, and 2 for that display item. This display item shall 22 function whenever the unit is "Unit-Online," "Unit-Available," or 23 "Unit-Offline, Known." This display item shall not function 24 whenever the unit is "Unit-Offline" for any other reason; the 25 DISPLAY command shall be rejected with "Unit-Offline" status and 26 | the appropriate subcode. A unit may optionally reject mode 2, 27 | Mount Request Volume Identification, when the unit is 28 | "Unit-Online" to any host. If the unit chooses to reject this 29 | mode when "Unit-Online", it should treat it as unimplemented and 30 | return either "Success" status (subcode "Normal") or "Invalid 31 | Command" status (subcode "Invalid Mode"), depending on the state 32 | of the "Must Be Implemented" modifier. 33 | The unit or device display shall clear its volume identification 34 information on reset, power-up, or any other loss of context. It 35 | shall also clear its volume identification information whenever a 36 volume is inserted or removed from the drive. It should not 37 | otherwise alter its volume identification information unless 38 directed to by a host (via this command). 39 | Item = 1, Mode = 0 Clear Volume Identification 40 | Clears the volume identification information. Expects no 41 text strings. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-65 DISPLAY Command 11 June 1992 1 | Item = 1, Mode = 1 Current Volume Identification 2 Conveys the volume label currently associated with the unit 3 | or the volume mounted on the unit. Expects one non-null text 4 | string containing the volume label. 5 | Item = 1, Mode = 2 Mount Request Volume Identification 6 | Identifies the volume that an operator should mount on the 7 unit. Typically the drive should highlight or emphasize the 8 | volume identification to notify the operator of the mount 9 | request. Units that are associated with a media loader may 10 | satisfy mount requests directly, without passing mount 11 | requests to a human operator. Expects three text strings. 12 | The first text string is either null or the requested 13 | volume's label. The second text string is optional; this 14 mode shall function regardless of whether the second string 15 is null or non-null. If the second text string is non-null, 16 then it is the command "Mount" expressed in the local 17 language. The entire ISO Latin-1 character set is valid for 18 the second text string; the device display may ignore this 19 text string (treat it as if it were null), display it 20 unmodified, or translate it to a form that can be displayed. 21 For example, a device display might translate the lower case 22 alphabet to upper case. If a device display can neither 23 display the second text string nor translate the string to a 24 form that can be displayed, then it shall ignore the string 25 as if it were null. 26 | The third text string is either null or the requested 27 | volume's location. With device displays and human operators, 28 | this would typically use the same character set as the volume 29 | label. Any character not displayable by the device display 30 | is invalid. The format and meaning of the location codes are 31 | outside the scope of T/MSCP; they will typically be chosen by 32 | the individual site or installation. With robotic media 33 | loaders, the location will typically be a decimal digit 34 | string encoding the number of the element within the loader 35 | that contains the requested volume. If the string does not 36 | identify a valid or potentially valid element within the 37 | media loader, then some character in it is invalid. 38 | If both the first and third text strings are null, then this 39 | is a request to mount an unidentified volume. If the first 40 | is non-null and the third null, then this is a request to 41 | mount a volume with the specified volume label. If the first 42 | is null and the third non-null, then this is a request to 43 | mount the volume that normally resides at the specified 44 | location. If both are non-null, then this is a request to *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-66 DISPLAY Command 11 June 1992 1 | mount a volume that both has the specified label and that 2 | normally resides at the specified location. A unit need only 3 | use the information that is consistent with its display 4 | device's or media loader's capabilities. 5 | The means by which a mount request is resolved, resulting in 6 | a specific physical volume being located and mounted, are 7 | outside the scope of T/MSCP. In general, mount requests may 8 | specify volumes that do not exist, ambiguously specify 9 | multiple volumes, or be self-contradictory. With a human 10 | operator, treatment of these conditions will depend on the 11 | operator's intelligence and local site-specific policies. 12 | With robotic operators, treatment of these conditions will 13 | depend on the cleverness of the device's designers. While 14 | not required, it is recommended that robotic media loaders 15 | detect any mount request that does not specify a unique 16 | volume and either treat it as unimplemented or return some 17 | other error. 18 | Note that the DISPLAY command with this mode and item merely 19 | delivers a mount request. Completion of the DISPLAY command 20 | does not mean that the mount request itself can or will be 21 | satisfied. If the mount request is in fact eventually 22 | satisfied, the unit will become "Unit-Available" when the 23 | volume is mounted and an attention message delivered if 24 | enabled. However there is no guarantee that the correct or 25 | requested volume was indeed mounted, since operators (whether 26 | human or robotic) make mistakes. The host must use 27 | non-T/MSCP means, such as label verification, to ensure that 28 | the correct or a suitable volume has been mounted. If a 29 | mount request cannot be satisfied, there is in general no way 30 | to report that with T/MSCP. Hosts might use timeouts or 31 | similar means to detect mount request failures. 32 | Notwithstanding the above, if a device can determine, during 33 | the normal execution of the DISPLAY command, that a mount 34 | request cannot or will not be satisfied, then it should 35 | report that failure with the DISPLAY command's status code. 36 | This is most likely to be possible with robotic media 37 | loaders. However T/MSCP do not preclude such failure 38 | reporting with human operators as well, if any device can 39 | implement it. The ability to detect mount request failures 40 | and which failures are or are not reported as DISPLAY command 41 | status codes are all extremely device dependent. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-67 ERASE Command 11 June 1992 1 6.9 ERASE Command 2 Command Category: 3 Non-Sequential 4 6.9.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | caa | opcode| 12 +---------------+-------+-------+ 13 | byte count | 14 +-------------------------------+ 15 | | 16 +--- ---+ 17 | reserved | 18 +--- ---+ 19 | | 20 +-------------------------------+ 21 | logical block number | 22 +---------------+---------------+ 23 | entry id | hrn or entloc | (optional) 24 +---------------+---------------+ 25 hrn (host reference number) or entloc (entry locator) 26 entry id 27 Optional fields, used in conjunction with the History Log 28 and Reuse Entry modifiers. See the descriptions of those 29 modifiers below. 30 Allowable modifiers: 31 Clear Serious Exception (ignored for disk class devices) 32 Express Request 33 Force Error 34 Suppress Error Recovery 35 History Log 36 Reuse Entry 37 The History Log and Reuse Entry modifiers are 38 interdependent and described together here to avoid 39 confusion. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-68 ERASE Command 11 June 1992 1 Note that the History Log modifier, the Reuse Entry 2 modifier, the "hrn or entloc" field, and the "entry id" 3 field are valid only for servers that provide "write 4 history logging" support (i.e., the server sets the Write 5 History Logging Support controller flag; see Section 5.6, 6 "Controller Flags" for related information). 7 The setting of the History Log modifier determines 8 whether information about this command is to be stored in 9 a "write history entry." 10 The setting of the Reuse Entry modifier determines 11 whether the server is to allocate a new "write history 12 entry" or reuse one that was previously allocated. 13 If "write history logging" is supported and the History 14 Log modifier is set and the Reuse Entry modifier is 15 clear, the server allocates a new "write history entry" 16 and then stores the value contained in the "hrn (host 17 reference number)" field, "entry id" field, and other 18 information related to this command into the "write 19 history entry" just allocated. If the server has no 20 "write history entry" to allocate, it shall remember this 21 fact. See Section 6.19.3, "WRITE HISTORY MANAGEMENT 22 Command, Description" for more details. To report this 23 allocation failure to the host, the server returns 24 FFFF(hex) in the "entry locator" field of the end message 25 and sets the Allocation Failure end flag. See Section 26 5.4, "End Messages," for a description of this flag. 27 If "write history logging" is supported and the History 28 Log modifier is set and the Reuse Entry modifier is set, 29 the server uses the value contained in the "entloc (entry 30 locator)" field to locate the associated "write history 31 entry" and then stores the other information related to 32 this command into that "write history entry." 33 See Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 34 Description" for details regarding the maintenance and 35 format of "write history entries." 36 Note that when "write history logging" is supported and 37 the History Log modifier is set, host class drivers shall 38 supply both the "hrn or entloc" and the "entry id" 39 fields. If the History Log modifier is set and those 40 fields are not supplied, the server rejects the command 41 as an "Invalid Command" ("invalid message length" 42 protocol error. See "Invalid Command" status in Section 43 5.5, "Status Codes"). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-69 ERASE Command 11 June 1992 1 If "write history logging" is supported and the History 2 Log modifier is clear, the server ignores the setting of 3 the Reuse Entry modifier and the contents of the "hrn or 4 entloc" and "entry id" fields if they are supplied. Note 5 that host class drivers need not supply those fields when 6 the History Log modifier is clear. 7 If "write history logging" is not supported and the 8 History Log modifier or the Reuse Entry modifier is set, 9 the server rejects the command as an "Invalid Command" 10 ("invalid modifier" protocol error. See "Invalid 11 Command" status in Section 5.5, "Status Codes"). 12 If "write history logging" is supported, the History Log 13 modifier is set, and the "byte count" field is zero, the 14 server rejects the command as an Invalid Command 15 ("invalid byte count" parameter error. See "Invalid 16 Command" status in Section 5.5, "Status Codes"). 17 The server shall set the History Logged end flag in this 18 command's end message if it has caused the write history 19 log to contain a valid "write history entry" for this 20 command. See Section 5.4, "End Messages," for 21 descriptions of all end message flags. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-70 ERASE Command 11 June 1992 1 6.9.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 | entry id | entry locator | (conditionally present) 21 +---------------+---------------+ 22 entry locator 23 This field is present if and only if the corresponding 24 command message field is present. If present and the 25 History Log modifier is set in the command message, this 26 field contains the value assigned by the server that 27 uniquely identifies the internal location of the "history 28 entry" where this command's information was stored. If, 29 however, an allocation failure occurred, this field 30 contains the value FFFF(hex). If present and the History 31 Log modifier is clear in the command message, this field 32 is undefined. 33 This field contains a valid entry locator of a "write 34 history entry" for this command if and only if the 35 History Logged end flag is set in the "flags" field of 36 this end message. 37 See the description of the History Log and Reuse Entry 38 modifiers in Section 6.9.1, "ERASE Command, Command 39 Message Format" and Section 6.19.3, "WRITE HISTORY 40 MANAGEMENT Command, Description" for more detail. 41 entry id 42 This field is present if and only if the corresponding *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-71 ERASE Command 11 June 1992 1 command message field is present. If present and the 2 History Log modifier is set in the command message, the 3 contents of the corresponding command message field is 4 copied without modification to this field. If present 5 and the History Log modifier is clear in the command 6 message, this field is undefined. 7 See the description of the History Log and Reuse Entry 8 modifies in Section 6.9.1, "ERASE Command, Command 9 Message Format" and Section 6.19.3, "WRITE HISTORY 10 MANAGEMENT Command, Description" for more detail. 11 Status Codes: 12 Success (subcode "Normal") 13 Success (subcode "Duplicate Unit Number") 14 Invalid Command (subcode "Invalid Byte Count") 15 A byte count of zero was specified with the History Log 16 modifier set. 17 Invalid Command (subcode "Invalid Entry Locator") 18 The value specified in the "entloc (entry locator)" field 19 is not within the limits of the server's "write history 20 entry" set. 21 See the description of the History Log and Reuse Entry 22 modifiers in Section 6.9.1, "ERASE Command, Command 23 Message Format" and Section 6.19.3, "WRITE HISTORY 24 MANAGEMENT Command, Description" for more detail. 25 Note that this error can only occur if "write history 26 logging" is supported and the History Log and Reuse Entry 27 modifiers are both set in the command message. 28 Invalid Command (subcode "Invalid Entry Id") 29 The server located the "write history entry" identified 30 in the "entloc (entry locator)" field but found that the 31 "entry id" contained in that entry does not equal the 32 value supplied by a host class driver when that entry was 33 allocated. This status may also be returned if the 34 History Log modifier was set, the Reuse Entry modifier 35 was clear, and the host supplied a value of FFFF (hex) in 36 the "entry id" field. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-72 ERASE Command 11 June 1992 1 See the description of the History Log and Reuse Entry 2 modifiers in Section 6.9.1, "ERASE Command, Command 3 Message Format" and Section 6.19.3, "WRITE HISTORY 4 MANAGEMENT Command, Description" for more detail. 5 Note that this error can only occur if "write history 6 logging" is supported and the History Log modifier is set 7 in the command message. 8 Invalid Command (subcode "Invalid Logical Block Number") 9 Command Aborted 10 Unit-Offline 11 Unit-Available 12 Write Protected 13 Host Buffer Access Error (subcode "Odd Byte Count") 14 If the communications mechanism does not allow odd byte 15 transfers, the controller may return this status 16 code/subcode despite there being no host buffer. This 17 allows the use of common code for command validation of 18 all transfer commands. Alternatively, the controller may 19 round the byte count up to the nearest whole sector size 20 and perform the operation. 21 Controller Error 22 Drive Error 23 Write History Entry Access Error (subcode "Allocation Failure 24 Table Full") 25 The server was unable to allocate a "write history entry" 26 and could not record this fact because the Allocation 27 Failure Table was full. This is a transient condition; 28 therefore, the host should reissue the command. See 29 Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 30 Description" for more details. 31 Note that this error can occur only if "write history 32 logging" is supported and the History Log modifier is set 33 and Reuse Entry modifier is clear in the command message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-73 ERASE Command 11 June 1992 1 6.9.3 Description 2 All data in the specified region of the unit is erased by 3 overwriting it with zero. 4 This command is exactly equivalent in function, although not in 5 performance, to a WRITE command which references a buffer that 6 the host has zeroed. 7 If a controller-based cache exists, the cache manager may use the 8 Cache Access Attribute advice in managing the caching and 9 comparing of the requested data area. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-74 FORMAT Command 11 June 1992 1 6.10 FORMAT Command 2 Command Category: 3 Sequential 4 6.10.1 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 | format function | 22 +-------------------------------+ 23 byte count 24 buffer descriptor 25 If "byte count" is non-zero, these two parameters 26 identify a buffer containing additional format 27 information. If "byte count" is zero, then "buffer 28 descriptor" is reserved. See description below. 29 format function 30 A code from Table A-13, "Format Function Codes," 31 indicating the desired format for the volume. 32 Allowable modifiers: 33 Clear Serious Exception (ignored for disk class devices) 34 Compare -- ignored 35 Express Request -- ignored 36 Suppress Error Correction -- ignored 37 Suppress Error Recovery -- ignored *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-75 FORMAT Command 11 June 1992 1 6.10.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 Status Codes: 11 Success (subcode "Normal") 12 Invalid Command 13 Command Aborted 14 Unit-Offline 15 Unit-Available 16 Media Format Error 17 Write Protected 18 Host Buffer Access Error 19 Controller Error 20 Drive Error 21 Invalid Parameter *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-76 FORMAT Command 11 June 1992 1 6.10.3 Description 2 This command formats or reformats the volume mounted on the 3 specified unit. Support for this command is completely optional. 4 Controllers that do not implement this command, or that do not 5 implement it for the specified unit, shall reject it with 6 "Invalid Command -- Invalid Opcode" status. 7 A controller may choose to implement this command, a DUP 8 formatting program, both, or neither. All combinations are 9 allowed and reasonable for various devices. However, this 10 command is the preferred means of formatting devices for which 11 formatting is considered a normal, user-invoked operation. 12 Floppy diskettes are common examples of such devices. 13 Hosts shall use the following command sequence to format the 14 volume on a unit using this command. This command sequence is 15 the only context in which the FORMAT command shall be issued. 16 1. The unit should be "Unit-Available" or "Unit-Offline" to 17 all hosts at the start of the command sequence. That 18 is, the unit should not be "Unit-Online" to any host. 19 2. The host brings the unit "Unit-Online" using an ONLINE 20 command with the "Ignore Media Format Error" modifier 21 set. The host shall exit (not continue the formatting 22 sequence) if this command does not succeed. It is 23 recommended, although not required, that the host also 24 set the "Exclusive Access" modifier. 25 3. The host may optionally issue any number of READ 26 commands to the unit. These commands might be used to 27 verify that the correct volume is mounted. The host may 28 exit or continue as it sees fit, regardless of the 29 success or failure of these READ commands. The host 30 should issue an AVAILABLE command to the unit if it 31 chooses to exit. Note that these READ commands will 32 normally fail if the volume has not been previously 33 formatted. 34 4. The host issues a FORMAT command to the unit. 35 The controller shall verify that the unit was brought 36 "Unit-Online" by an ONLINE command with the "Ignore Media Format 37 Error" modifier set. If the unit is "Unit-Offline" or 38 "Unit-Available" the controller shall reject the FORMAT command 39 with the corresponding status code and leave the unit state 40 unaltered. If the unit is "Unit-Online" but the "Ignore Media 41 Format Error" modifier was not specified, then the controller *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-77 FORMAT Command 11 June 1992 1 shall reject the FORMAT command with a "Unit-Available" status 2 code and the unit becomes "Unit-Available." 3 The controller shall return "Invalid Command," "Unit-Offline," 4 "Unit-Available," "Write Protected," or "Invalid Parameter" 5 status if a FORMAT command is rejected. These status codes all 6 imply that the volume on the unit has not been altered. The unit 7 state is unaltered, except for the case described in the 8 preceding paragraph. 9 The controller shall return "Success" status if the format 10 operation is successful. The unit is left "Unit-Available." 11 Any other status code implies that the volume may have been 12 partially formatted. The volume must be successfully reformatted 13 before it can be used reliably. The unit may be either 14 "Unit-Available" or "Unit-Offline." 15 The FORMAT command often causes the unit to transition from 16 "Unit-Online" to "Unit-Available." This is a synchronous 17 transition. Therefore the controller need not generate an 18 AVAILABLE attention message. 19 The FORMAT command neither obtains nor releases Exclusive Access 20 to the unit. 21 The actual formatting operation is controlled by the format 22 function code value and the additional format information in the 23 buffer described by the "byte count" and "buffer descriptor" 24 fields. Format function code values are listed in Table A-13. 25 The format function determines the use, structure, and 26 interpretation of any additional format information. 27 Most format functions do not use additional format information. 28 The controller shall ignore the "byte count" and "buffer 29 descriptor" fields, as well as any buffer described by them, when 30 the format function does not use additional format information. 31 If the format function does use additional format information, 32 the controller shall validate the additional format information 33 before it begins the formatting process. The controller shall 34 reject the FORMAT command with an "Invalid Parameter" status code 35 if the additional format information is invalid. 36 Format function code value zero specifies that a default 37 formatting operation should be performed. A default format 38 function shall be supported by all controller/unit combinations 39 that support the FORMAT command. The exact definition of the 40 default format function is device specific. It does not require 41 additional format information. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-78 FORMAT Command 11 June 1992 1 Support for non-default format functions is device dependent. 2 Table A-13 indicates which functions are applicable to different 3 classes of devices, but the final determination of supported 4 format functions is device dependent. Controllers shall reject 5 FORMAT commands that specify an unsupported format function with 6 "Invalid Command -- Invalid Format Function" status. 7 NOTE 8 At the present time there are no format functions 9 that use additional format information. The 10 definition of additional format information has 11 been included in this command for those host 12 operating systems that choose to implement 13 support for it in advance of any device 14 requirements for such support. Valid host 15 implementations need not support additional 16 format information. Any device that anticipates 17 using additional format information must 18 negotiate for host support, just as if they were 19 proposing a totally new feature. The ECO that 20 defines the first use of additional format 21 information should also remove this note. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-79 GET COMMAND STATUS Command 11 June 1992 1 6.11 GET COMMAND STATUS Command 2 Command Category: 3 Immediate 4 6.11.1 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 Shall 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. 26 Allowable modifiers: 27 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-80 GET COMMAND STATUS Command 11 June 1992 1 6.11.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 shall 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 shall remain the same for 33 a particular command for as long as that command is 34 outstanding. 35 Status Codes: 36 Success (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-81 GET COMMAND STATUS Command 11 June 1992 1 6.11.3 Description 2 The GET COMMAND STATUS command is used to monitor the progress of 3 a command towards completion. The command status measures the 4 "doneness" of the command. The value returned in the command 5 status field is guaranteed to not increase over time. 6 Furthermore, the command status of an MSCP server's oldest 7 outstanding command is guaranteed to decrease within the 8 controller timeout interval. This last feature may be used by a 9 host class driver to detect an insane or malfunctioning 10 controller. See Section 4.10, "Command Timeouts," for more 11 details. 12 The GET COMMAND STATUS command always succeeds. If the command 13 referenced by the "outstanding reference number" is not known to 14 the MSCP server or has been aborted, then the MSCP server should 15 return zero for its command status. The MSCP server may also 16 return zero as the command status of any command that will always 17 complete within the controller timeout interval. The MSCP server 18 always returns the "Normal" status code in the GET COMMAND STATUS 19 command's end message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-82 GET UNIT STATUS Command 11 June 1992 1 6.12 GET UNIT STATUS Command 2 Command Category: 3 Immediate 4 6.12.1 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 for disk class devices) 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 are acknowledged by this 22 modifier. 23 If this modifier is set, the "unit number" field in the 24 end message corresponds to the unit whose characteristics 25 are being returned, and is typically not the same as the 26 "unit number" field in the command message. If there are 27 no units that are both known to the controller and whose 28 unit numbers are greater than or equal to the unit number 29 specified in the command message, then zero is returned 30 in the "unit number" field of the end message. The 31 remaining fields of the end message are identical to the 32 values that would be returned for a GET UNIT STATUS 33 command with a "unit number" of zero and the "Next Unit" 34 modifier left clear. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-83 GET UNIT STATUS Command 11 June 1992 1 6.12.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | unit flags |multiunit code | 11 +---------------+---------------+ 12 | reserved |spndles| 13 +-------------------------------+ 14 | | 15 +--- unit identifier ---+ 16 | | 17 +-------------------------------+ 18 | media type identifier | 19 +-------------------------------+ 20 | reserved | 21 +-------------------------------+ 22 | group size | track size | 23 +-------+-------+---------------+ 24 |uhvrsn | usvrsn| cylinder size | 25 +-------+-------+---------------+ 26 |copies | RBNs | RCT size | 27 +-------+-------+---------------+ 28 | status 29 The validity of the unit characteristics varies with the 30 unit's state implied by the contents of this field. See 31 the Status Codes listed later in this section and Section 32 6.12.3, "GET UNIT STATUS Command, Description" for 33 complete details. 34 multiunit code 35 The low byte of this field identifies the access path 36 between the controller and the unit. The high byte of 37 this field identifies the spindle, within the access 38 path, to which the unit belongs. See Section 4.16.2, 39 "Multiunit Drives and Formatters," for more information. 40 unit flags 41 See Section 5.7, "Unit Flags." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-84 GET UNIT STATUS Command 11 June 1992 1 spndles 2 The number minus one of spindles or spindle "groups" in 3 the unit. The value of zero indicates one spindle. See 4 Section 4.12, "Disk Geometry and Format." 5 IMPLEMENTATION NOTE 6 The "spndles" field was defined in February 1991. Before 7 that it was a reserved field, but not all controllers 8 zeroed it. To ensure validity of the "spndles" field, 9 class drivers should send GET UNIT STATUS command 10 messages of at least 20 bytes and zero all bytes beyond 11 byte 12. 12 unit identifier 13 Uniquely identifies the unit among all devices accessible 14 via MSCP. See Section 4.17, "Controller and Unit 15 Identifiers." 16 media type identifier 17 Identifies the type of media used by this unit, for use 18 by host generic device allocation mechanisms. See 19 Section 4.18, "Media Type Identifiers." 20 track size 21 The number of logical blocks in a track. The value of 22 zero is reserved and illegal. See Section 4.12, "Disk 23 Geometry and Format." 24 group size 25 The number of tracks in a group. The value of zero is 26 reserved and illegal. See Section 4.12, "Disk Geometry 27 and Format." 28 cylinder size 29 The number of groups in a cylinder. The value of zero is 30 reserved and illegal. See Section 4.12, "Disk Geometry 31 and Format." 32 usvrsn 33 The unit's software, firmware, or microcode revision 34 number. Always zero if the product's development and *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-85 GET UNIT STATUS Command 11 June 1992 1 maintainability groups determine that there is no benefit 2 from supporting machine readable revision numbers. 3 uhvrsn 4 The unit's hardware revision number. Always zero if the 5 product's development and maintainability groups 6 determine that there is no benefit from supporting 7 machine readable revision numbers. 8 RCT size 9 The difference between the starting logical block numbers 10 of successive copies of the unit's Replacement Control 11 Table (RCT). Excepting only the last copy, this value is 12 also the size of each copy of the RCT. See Digital 13 Storage Architecture Disk Format Specification (DSDF). 14 Zero if this disk has no RCT whatsoever; see Section 15 4.12, "Disk Geometry and Format." 16 RBNs 17 The number of replacement blocks per track. 18 See Digital Storage Architecture Disk Format 19 Specification (DSDF). Zero if this disk has no RCT 20 whatsoever; see Section 4.12, "Disk Geometry and 21 Format." 22 copies 23 The number of copies of the Replacement Control Table 24 that are stored on the unit. See Digital Storage 25 Architecture Disk Format Specification (DSDF). Zero if 26 this disk has no RCT whatsoever; see Section 4.12, "Disk 27 Geometry and Format." 28 Status Codes: 29 Success (subcode "Normal") 30 Success (subcode "Duplicate Unit Number") 31 Both of these codes imply that the unit is 32 "Unit-Online." 33 Unit-Offline 34 Unit-Available *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-86 GET UNIT STATUS Command 11 June 1992 1 Controller Error 2 Drive Error 3 For both of these status codes the actual drive state is 4 unknown (although it will usually be "Unit-Offline" due 5 to being inoperative). Therefore the class driver should 6 assume that the unit is "Unit-Offline." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-87 GET UNIT STATUS Command 11 June 1992 1 6.12.3 Description 2 The GET UNIT STATUS command returns the current state of a unit 3 plus certain unit characteristics. In particular, the GET UNIT 4 STATUS command is used to obtain host-settable characteristics 5 and those fixed unit characteristics that are not normally needed 6 by the class driver. 7 Class drivers can determine which of the returned unit 8 characteristics are valid from the unit state implied by the 9 returned "status" (see Status Codes listed above) as follows: 10 1. Unit is "Unit-Offline" and unknown to controller. All 11 characteristic fields and all unit flags are undefined. 12 2. Unit is "Unit-Offline" and known to the controller or it 13 is "Unit-Available." The "multiunit code," "unit 14 identifier," "media type identifier," "usvrsn," 15 "uhvrsn," and "spndles" characteristic fields are valid. 16 The "Removable Media" unit flag is valid. All other 17 characteristic fields and unit flags are undefined. 18 3. Unit is "Unit-Online." All characteristics fields and 19 all unit flags are valid. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-88 ONLINE Command 11 June 1992 1 6.13 ONLINE Command 2 Command categories: 3 Sequential 4 6.13.1 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 | reserved | 24 +-------------------------------+ 25 | unit flags 26 Host-settable unit flags. See Section 5.7, "Unit 27 Flags." 28 If the unit is already "Unit-Online" to the class driver, 29 then the class driver shall specify the same values for 30 controller supported host-settable unit flags as are 31 currently in effect on the unit. The controller may, at 32 its option, check that the flag values are the same. If 33 it does check, then it shall reject the command as an 34 "Invalid Command" ("invalid unit flags" parameter error. 35 See "Invalid Command" status in Section 5.5), if they are 36 different. If the controller does not check that they 37 are the same, then it shall ignore the unit flags 38 specified by the class driver and preserve the flag 39 settings currently in effect on the unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-89 ONLINE Command 11 June 1992 1 device dependent parameters 2 Device and/or controller dependent device tuning 3 parameters. The value zero in this field means that 4 default or normal tuning parameters should be used. 5 Nonzero values for this field should normally be 6 established through the system startup command file. 7 Examples of the use of this field include selecting 8 alternative optimization algorithms or enabling and 9 disabling automatic (online) diagnosis of the unit. 10 Allowable modifiers: 11 Allow Self Destruction 12 Some controllers and/or drives are able to predict that a 13 unit is in danger of imminent self destruction, and 14 automatically spin-down and disable the unit to prevent 15 its destruction. Such mechanisms typically sense an 16 exponentially increasing (correctable) error rate, 17 indicating that the disk surface has been contaminated 18 with dust or other foreign objects. Units that have been 19 disabled for this reason appear to be "Unit-Offline," 20 with a subcode indicating that they have been disabled by 21 field service or a diagnostic. Therefore such a unit 22 cannot normally be brought "Unit-Online." 23 This modifier allows a host to bring a unit that has been 24 so disabled "Unit-Online," even though the consequences 25 for the unit may be fatal. For this reason THIS MODIFIER 26 SHALL NEVER BE USED UNLESS FIELD SERVICE EXPLICITLY 27 DIRECTS A SITE TO DO SO. When imminent self destruction 28 has been predicted for a unit, it is usually possible to 29 make one "last ditch" copy of the unit before it dies 30 completely, recovering all or most of the data on the 31 unit. This modifier exists primarily to simplify support 32 of such a "last ditch" copy. This modifier also provides 33 a means, if necessary, to work around a diagnostic that 34 is erroneously disabling a unit. 35 This modifier shall be supported by: 36 1. Any controller that may disable a unit for the reason 37 mentioned above. 38 2. Any controller that may potentially be connected to a 39 unit that can disable itself. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-90 ONLINE Command 11 June 1992 1 3. Any controller that does not disable units itself, 2 but that will respond properly if a drive is disabled 3 by some other (more capable) controller. 4 This modifier shall be ignored if the unit has not been 5 disabled or if the controller does not fall into any of 6 the above categories. 7 Clear Serious Exception (ignored for disk class devices) 8 Ignore Media Format Error 9 Suppresses most checking for "Media Format Errors" and 10 causes the "576 Byte Sectors" unit flag to be 11 host-settable. 12 If either the controller or the unit only support 512 13 byte sectors, then setting this modifier merely 14 suppresses Media Format Error checking. The unit is 15 brought "Unit-Online" as a 512 byte formatted volume and 16 the "576 Byte Sectors" unit flag is returned clear. If 17 both the controller and the unit support 576 byte 18 sectors, then the state of the "576 Byte Sectors" unit 19 flag (in the unit flags field of this ONLINE command) 20 specifies whether the volume is formatted with 512 or 576 21 byte sectors. The unit is brought "Unit-Online" in the 22 specified format, rather than the format being determined 23 from the volume itself. 24 Use of this modifier allows the host to set a unit to the 25 wrong block or sector size. Reading a unit that is set 26 to the wrong block or sector size may yield a mix of 27 erroneous "Data Errors," "Drive Errors," and "Controller 28 Errors." Writing a unit that is set to the wrong block 29 or sector size may permanently corrupt the volume. The 30 volume must be reformatted if this occurs. 31 Enable Set Write Protect 32 Causes the "Write Protect" unit flag to be host-settable. 33 This modifier causes the state of the "Write Protect 34 (software)" unit flag to be copied to the Software Write 35 Protect flag for this unit. See Section 4.14, "Write 36 Protection." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-91 ONLINE Command 11 June 1992 1 6.13.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | unit flags |multiunit code | 11 +---------------+---------------+ 12 | reserved |spndles| 13 +-------------------------------+ 14 | | 15 +--- unit identifier ---+ 16 | | 17 +-------------------------------+ 18 | media type identifier | 19 +-------------------------------+ 20 | reserved | 21 +-------------------------------+ 22 | unit size | 23 +-------------------------------+ 24 | volume serial number | 25 +-------------------------------+ 26 | status 27 The validity of the unit characteristics varies with the 28 unit's state implied by the contents of this field. See 29 Status Codes listed below and Section 6.17.3, "SET UNIT 30 CHARACTERISTICS Command, Description" for complete 31 details. 32 All other fields of the ONLINE command's end message are 33 identical to the SET UNIT CHARACTERISTICS command's end 34 message. Refer to Section 6.17.2, "SET UNIT CHARACTERISTICS 35 Command, End Message Format" for a description of the fields. 36 Status Codes: 37 Success (subcode "Normal") 38 Implies that the unit is "Unit-Online." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-92 ONLINE Command 11 June 1992 1 Success (subcode "Already Online") 2 The "Already Online" subcode bit flag is set if and only 3 if the unit is already "Unit-Online" to the requesting 4 class driver. The unit's state and characteristics are 5 not altered. When the unit is already "Unit-Online" to 6 the requesting class driver, the controller merely 7 returns the unit characteristics in the end message with 8 this status bit flag set, without performing any other 9 actions. 10 Invalid Command (subcode "Invalid Unit Flags") 11 The unit is already "Unit-Online" and, for those unit 12 flags that are both host-settable and supported by the 13 controller, the class driver has specified different 14 values from those currently in effect on the unit. The 15 unit remains "Unit-Online." The host-settable unit flags 16 are not changed, and the end message returns all unit 17 flags. Controllers may, at their option, omit checking 18 that the unit flags are the same and just ignore the 19 class driver specified unit flags for units that are 20 already "Unit-Online," thus returning a "Success" status 21 code with "Already Online" subcode. 22 Command Aborted 23 The command has been rejected and the unit's state has 24 not been changed. If the unit was "Unit-Available" prior 25 to issuing this command, then it is still 26 "Unit-Available." However, as the unit's state is not 27 reported to the host, the host should assume that the 28 returned unit characteristics are invalid as the unit may 29 be "Unit-Offline." 30 Unit-Offline 31 Note that some causes of a unit being "Unit-Offline" may 32 be overridden (suppressed) by the "Allow Self 33 Destruction" command modifier. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-93 ONLINE Command 11 June 1992 1 Media Format Error 2 The unit is and remains "Unit-Available." However, 3 attention messages are suppressed for this unit and the 4 controller attempts to spin-down this unit exactly as if 5 an AVAILABLE command with the "Spin-down" modifier set 6 were issued. Note, however, that this error will be 7 suppressed and the unit brought "Unit-Online" anyway if 8 the "Ignore Media Format Error" command modifier is set. 9 See the modifier description above. 10 Controller Error 11 The actual drive state is unknown. Therefore the class 12 driver should assume that the unit is "Unit-Offline." 13 Drive Error 14 The unit is "Unit-Offline" due to being inoperative. The 15 controller shall suppress AVAILABLE attention messages 16 for the unit and attempt to spin-down the unit, exactly 17 as if an AVAILABLE command with the "Spin-down" modifier 18 set were issued for the unit. The controller may 19 subsequently report the unit as being either 20 "Unit-Offline" or "Unit-Available." The reported unit 21 state will depend upon exactly how the unit is "broken," 22 and the interactions of the failure with the controller's 23 perception of the unit's state. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-94 ONLINE Command 11 June 1992 1 6.13.3 Description 2 The ONLINE command is used to bring a unit "Unit-Online," set 3 host-settable unit characteristics, and obtain those unit 4 characteristics that are essential for proper class driver 5 operation (see Section 5.7, "Unit Flags" for additional 6 information). The unit is spun-up, if necessary, and its heads 7 are loaded prior to returning the ONLINE command's end message. 8 Host-settable characteristics are set exactly as if a SET UNIT 9 CHARACTERISTICS command were issued (see Section 6.17.2, "SET 10 UNIT CHARACTERISTICS Command"). Host-settable characteristics 11 are set after the unit has been successfully spun-up and any 12 other validity checks have succeeded. Note that the unit's 13 host-settable characteristics are NOT altered if the unit is 14 already "Unit-Online." 15 For details of class driver responsibilities with respect to Host 16 Initiated Bad Block Replacement, see the Digital Storage 17 Architecture Disk Format (DSDF) Specification section on "Host 18 Initiated Bad Block Replacement." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-95 READ Command 11 June 1992 1 6.14 READ Command 2 Command Category: 3 Non-Sequential 4 6.14.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | caa | 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 for disk class devices) 25 Compare 26 Express Request 27 Suppress Error Correction 28 Suppress Error Recovery *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-96 READ Command 11 June 1992 1 6.14.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 (subcode "Normal") 22 Success (subcode "Duplicate Unit Number") 23 Invalid Command (subcode "Invalid Byte Count") 24 Invalid Command (subcode "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 *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-97 READ Command 11 June 1992 1 6.14.3 Description 2 Data is read from the unit and transferred to the host buffer. 3 For host buffer access details see Section 4.11, "Host Buffer 4 Access." 5 If a controller-based cache exists, the cache manager may use the 6 Cache Access Attribute advice in managing the caching and 7 comparing of the requested data area. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-98 REPLACE Command 11 June 1992 1 6.15 REPLACE Command 2 Command Category: 3 Non-Sequential 4 6.15.1 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 for disk class devices) 30 Express Request *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-99 REPLACE Command 11 June 1992 1 Primary Replacement Block 2 Shall be set if and only if the "replacement block 3 number" specifies the primary replacement block for 4 "logical block number." I.e., set if and only if the 5 following expression is true: 6 replacement block number = 7 logical block number / track size * RBNs 8 where "track size" and "RBNs" are unit characteristics 9 obtained via the GET UNIT CHARACTERISTICS command and "/" 10 denotes integer (truncating) division. See Digital 11 Storage Architecture Disk Format Specification (DSDF) for 12 more information. Note that this modifier is redundant 13 information provided for the convenience of the 14 controller. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-100 REPLACE Command 11 June 1992 1 6.15.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 Status Codes: 11 Success (subcode "Normal") 12 Success (subcode "Duplicate Unit Number") 13 Invalid Command (subcode "Invalid Replacement Block Number") 14 Replacement block number is outside the range supported 15 by this disk. 16 Invalid Command (subcode "Invalid Logical Block Number") 17 Command Aborted 18 Unit-Offline 19 Unit-Available 20 Write Protected 21 Controller Error 22 Drive Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-101 REPLACE Command 11 June 1992 1 6.15.3 Description 2 The specified logical block is flagged to indicate that it has 3 been replaced with the specified replacement block. The volume's 4 Replacement Control Table (RCT) shall have been updated prior to 5 using this command, and the replacement block should be 6 initialized with a write command to the same logical block number 7 after using this command. See Section 4.13, "Bad Block 8 Replacement," and Digital Storage Architecture Disk Format 9 Specification (DSDF) for more information on the use and function 10 of this command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-102 SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 6.16 SET CONTROLLER CHARACTERISTICS Command 2 Command Category: 3 Immediate 4 6.16.1 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 | crn | (optional) 24 +---------------+ 25 MSCP version 26 Host class drivers shall supply the value zero in this 27 field. MSCP servers shall verify this value and, if it 28 is not zero, reject the command as an "Invalid Command" 29 ("invalid MSCP version" protocol error. See "Invalid 30 Command" status in Section 5.5). This value will be 31 incremented if MSCP is ever modified in a way that is not 32 upwards compatible. 33 cntrlr. flags 34 Host-settable controller flags. See Section 5.6, 35 "Controller Flags." 36 host timeout 37 The time interval that the controller should use for the 38 host access timeout with this host, or zero if the 39 controller should disable the host access timeout for *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-103 SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 this host. Expressed as an unsigned binary integer in 2 units of seconds. Controllers should use a default host 3 access timeout of 60 seconds if they have not received a 4 SET CONTROLLER CHARACTERISTICS command since becoming 5 "Controller-Online." 6 Even though this is a sixteen bit field, controllers may 7 treat all values greater than 255 as if 255 had been 8 specified, and all values between 1 and 9 as if 10 had 9 been specified. See Section 4.9, "Host Access 10 Timeouts." 11 quad-word time and date 12 The current time and date, expressed as the number of 13 clunks since 00:00 o'clock, November 17, 1858 (in the 14 local time zone), or zero if the current time and date is 15 not available. A clunk is 100 nanoseconds. This is the 16 standard VAX/VMS time and date format. The use that is 17 made of the current time and date and the action taken if 18 it is not supplied (i.e., if zero is supplied) is 19 controller dependent, and should be described in each 20 controller's Functional Specification. Controllers shall 21 not require that a time and date be supplied for proper 22 operation. 23 controller dependent parameters 24 Controller dependent tuning parameters. The value zero 25 in this field means that default or normal tuning 26 parameters should be used. Nonzero values for this field 27 should normally be established through the system startup 28 command file. 29 crn (connection reference number) 30 The nonzero value the server is to associate with the 31 "Controller-Online" connection over which this command is 32 received for the purpose of terminating the class 33 driver/server connection a host has established with the 34 server. See Section 7.10, "Multihost TERMINATE CLASS 35 DRIVER/SERVER CONNECTION Command" for more information 36 regarding the use of this field for that purpose. 37 This field is valid only for servers that provide Write 38 History Logging Support or servers that support just the 39 TERMINATE CLASS DRIVER/SERVER CONNECTION command. See 40 Section 5.6, "Controller Flags" for related information. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-104 SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 If a server provides such support, this field is 2 optional. A host class driver need only supply this 3 field if the TERMINATE CLASS DRIVER/SERVER CONNECTION 4 command is to be used. If a value of zero is supplied in 5 this field, the server rejects the command as an "Invalid 6 Command" ("invalid crn" parameter error). 7 If the Connection Reference Number Present modifier is 8 set and the "crn" field is not supplied, the server 9 rejects the command as an Invalid Command (subcode 10 "Invalid Message Length") protocol error (see Section 11 5.5, "Status Codes"). 12 Allowable modifiers: 13 Connection Reference Number Present 14 Shall be set if and only if the host provides the 15 optional "crn (connection reference number)" command 16 message field. See the description of that field above. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-105 SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 6.16.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| reserved | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | cntrlr. flags | MSCP version | 11 +-------+-------+---------------+ 12 |chvrsn | csvrsn|cntrlr. timeout| 13 +-------+-------+---------------+ 14 | | 15 +--- controller identifier ---+ 16 | | 17 +-------------------------------+ 18 | maximum byte count (optional) | 19 +-------------------------------+ 20 cntrlr. flags 21 See Section 5.6, "Controller Flags." 22 cntrlr. timeout 23 The controller timeout interval; the minimum amount of 24 time that the controller needs to guarantee it will 25 accomplish useful work on its oldest outstanding command. 26 Expressed as an unsigned binary integer in units of 27 seconds. This value may not exceed 255 (one byte), even 28 though a sixteen bit field has been provided. See 29 Section 4.10, "Command Timeouts." 30 csvrsn 31 The controller's software, firmware, or microcode 32 revision number. Always zero if the product's 33 development and maintainability groups determine that 34 there is no benefit from supporting machine readable 35 revision numbers. 36 chvrsn 37 The controller's hardware revision number. Always zero 38 if the product's development and maintainability groups 39 determine that there is no benefit from supporting 40 machine readable revision numbers. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-106 SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 controller identifier 2 Uniquely identifies the controller among all devices 3 accessible via MSCP. See Section 4.17, "Controller and 4 Unit Identifiers." 5 maximum byte count (optional) 6 The maximum byte count value supported by the server. 7 Class drivers should not issue transfer commands with 8 byte counts larger than this value; byte counts equal to 9 this value are supported. 10 This value shall be at least as large as the following: 11 o For disk class devices, 16,777,216 (2**24) bytes. 12 o For tape class devices, 65535 (2**16-1) bytes. 13 That is, all servers shall support transfers at least as 14 large as the above values. Support for longer transfers 15 is optional. 16 This field is optional. Class drivers determine whether 17 or not this field is included in the end message by 18 checking the message length supplied by the 19 communications mechanism. If this field is not supplied, 20 or if its contents are zero, then the server supports 21 byte counts up to the values shown in the previous 22 paragraph. 23 Status Codes: 24 Success (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-107 SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 6.16.3 Description 2 The SET CONTROLLER CHARACTERISTICS command is used to set and 3 obtain controller characteristics. The default value for 4 "cntrlr. flags" is all flags clear (i.e., all messages disabled). 5 The default value for "host timeout" is 60 seconds. These 6 default values are used from the time that the controller becomes 7 "Controller-Online" to a host until it stops being 8 "Controller-Online" or until the host issues a SET CONTROLLER 9 CHARACTERISTICS command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-108 SET UNIT CHARACTERISTICS Command 11 June 1992 1 6.17 SET UNIT CHARACTERISTICS Command 2 Command Category: 3 Sequential 4 6.17.1 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 | reserved | 24 +-------------------------------+ 25 unit flags 26 Host-settable unit flags. See Section 5.7, "Unit 27 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 Nonzero 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. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-109 SET UNIT CHARACTERISTICS Command 11 June 1992 1 Allowable modifiers: 2 Clear Serious Exception (ignored for disk class devices) 3 Enable Set Write Protect 4 Causes the "Write Protect" unit flag to be host-settable. 5 This modifier causes the state of the "Write Protect 6 (software)" unit flag to be copied to the Software Write 7 Protect flag for this unit. See Section 4.14, "Write 8 Protection." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-110 SET UNIT CHARACTERISTICS Command 11 June 1992 1 6.17.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | unit flags |multiunit code | 11 +---------------+---------------+ 12 | reserved |spndles| 13 +-------------------------------+ 14 | | 15 +--- unit identifier ---+ 16 | | 17 +-------------------------------+ 18 | media type identifier | 19 +-------------------------------+ 20 | reserved | 21 +-------------------------------+ 22 | unit size | 23 +-------------------------------+ 24 | volume serial number | 25 +-------------------------------+ 26 | status 27 The validity of the unit characteristics varies with the 28 unit's state implied by the contents of this field. See 29 Status Codes listed later in this section and Section 30 6.17.3, "SET UNIT CHARACTERISTICS Command, Description" 31 for complete details. 32 multiunit code 33 The low byte of this field identifies the access path 34 between the controller and the unit. The high byte of 35 this field identifies the spindle, within the access 36 path, to which the unit belongs. See Section 4.16.2, 37 "Multiunit Drives and Formatters," for more information. 38 unit flags 39 See Section 5.7, "Unit Flags." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-111 SET UNIT CHARACTERISTICS Command 11 June 1992 1 spndles 2 The number minus one of spindles or spindle "groups" in 3 the unit. The value of zero indicates one spindle. See 4 Section 4.12, "Disk Geometry and Format." 5 unit identifier 6 Uniquely identifies the unit among all devices accessible 7 via MSCP. See Section 4.17, "Controller and Unit 8 Identifiers." 9 media type identifier 10 Identifies the type of media used by this unit, for use 11 by host generic device allocation mechanisms. See 12 Section 4.18, "Media Type Identifiers." 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 Control Table 17 (RCT). The logical block number of the first block of 18 the unit's RCT is equal to this value. 19 volume serial number 20 The low order 32 bits of the serial number of the volume 21 that is mounted on this unit. Zero if the volume does 22 not have a serial number. When displayed in human 23 readable form, this number should be formatted as a ten 24 digit decimal number with leading zeros printed. 25 Undefined if the unit is "Unit-Offline" or 26 "Unit-Available," or if the "Ignore Media Format Error" 27 modifier was set in the ONLINE command that first brought 28 this unit "Unit-Online." 29 Hosts may not assume that the value returned in this 30 field uniquely identifies the volume. Although this 31 value often will be unique, the uniqueness is not 32 guaranteed, especially across media obtained from several 33 independent suppliers. Also, media that must meet 34 external (industry compatible) format standards will 35 typically be unable to implement a volume serial number. 36 This field will always be zero for such media. 37 Status Codes: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-112 SET UNIT CHARACTERISTICS Command 11 June 1992 1 Success (subcode "Normal") 2 Success (subcode "Duplicate Unit Number") 3 Imply that the unit is "Unit-Online." 4 Command Aborted 5 The command has been rejected and the unit's state and 6 context have not been changed. That is, the unit's unit 7 flags and device dependent parameters are unchanged. 8 Since the unit's state is not reported to the host, the 9 host should assume that the returned unit characteristics 10 are invalid as the unit may be "Unit-Offline." 11 Unit-Offline 12 Unit-Available 13 Controller Error 14 Drive Error 15 For both of these status codes the actual drive state is 16 unknown (although it will usually be "Unit-Offline" due 17 to being inoperative). Therefore the class driver should 18 assume that the unit is "Unit-Offline." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-113 SET UNIT CHARACTERISTICS Command 11 June 1992 1 6.17.3 Description 2 The SET UNIT CHARACTERISTICS command is used to set host-settable 3 unit characteristics and obtain those unit characteristics that 4 are essential for proper class driver operation. This command 5 never alters the unit's state ("Unit-Online," "Unit-Available," 6 "Unit-Offline"). It is meaningless to set host-settable 7 characteristics for a unit that is "Unit-Available" or 8 "Unit-Offline." 9 Class drivers can determine which of the returned unit 10 characteristics are valid from the unit state implied by the 11 returned "status" (see Status Codes listed above) as follows: 12 1. Unit is "Unit-Offline" and unknown to controller. All 13 characteristic fields and all unit flags are undefined. 14 2. Unit is "Unit-Offline" and known to the controller or it 15 is "Unit-Available." The "multiunit code," "unit 16 identifier," and "media type identifier" characteristic 17 fields are valid. The "Removable Media" unit flag is 18 valid. All other characteristic fields and unit flags 19 are undefined. 20 3. Unit is "Unit-Online". All characteristics fields and 21 all unit flags are valid. 22 Note that the format of the SET UNIT CHARACTERISTICS command's 23 end message is identical to that of the ONLINE command's end 24 message because the ONLINE command performs a SET UNIT 25 CHARACTERISTICS operation after bringing a unit "Unit-Online." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-114 WRITE Command 11 June 1992 1 6.18 WRITE Command 2 Command Category: 3 Non-Sequential 4 6.18.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | unit number | 10 +---------------+-------+-------+ 11 | modifiers | caa | opcode| 12 +---------------+-------+-------+ 13 | byte count | 14 +-------------------------------+ 15 | | 16 +--- buffer ---+ 17 | | 18 +--- descriptor ---+ 19 | | 20 +-------------------------------+ 21 | logical block number | 22 +---------------+---------------+ 23 | entry id | hrn or entloc | (optional) 24 +---------------+---------------+ 25 hrn (host reference number) or entloc (entry locator) 26 entry id 27 Optional fields, used in conjunction with the History Log 28 and Reuse Entry modifiers. See the descriptions of those 29 modifiers below. 30 Allowable modifiers: 31 Clear Serious Exception (ignored for disk class devices) 32 Compare 33 Express Request 34 Force Error 35 History Log 36 Reuse Entry 37 The History Log and Reuse Entry modifiers are 38 interdependent and described together here to avoid 39 confusion. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-115 WRITE Command 11 June 1992 1 Note that the History Log modifier, the Reuse Entry 2 modifier, the "hrn or entloc" field, and the "entry id" 3 field are valid only for servers that provide "write 4 history logging" support (i.e., the server sets the Write 5 History Logging Support controller flag; see Section 5.6, 6 "Controller Flags" for related information). 7 The setting of the History Log modifier determines 8 whether information about this command is to be stored in 9 a "write history entry." 10 The setting of the Reuse Entry modifier determines 11 whether the server is to allocate a new "write history 12 entry" or reuse one that was previously allocated. 13 If "write history logging" is supported and the History 14 Log modifier is set and the Reuse Entry modifier is 15 clear, the server allocates a new "write history entry" 16 and then stores the value contained in the "hrn (host 17 reference number)" field, "entry id" field, and other 18 information related to this command into the "write 19 history entry" just allocated. If the server has no 20 "write history entry" to allocate, it shall remember this 21 fact. See Section 6.19.3, "WRITE HISTORY MANAGEMENT 22 Command, Description" for more details. To report this 23 allocation failure to the host, the server returns 24 FFFF(hex) in the "entry locator" field of the end message 25 and sets the Allocation Failure end flag. See Section 26 5.4, "End Messages," for a description of this flag. 27 If "write history logging" is supported and the History 28 Log modifier is set and the Reuse Entry modifier is set, 29 the server uses the value contained in the "entloc (entry 30 locator)" field to locate the associated "write history 31 entry" and then stores the other information related to 32 this command into that "write history entry." 33 See Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 34 Description" for details regarding the maintenance and 35 format of "write history entries." 36 Note that when "write history logging" is supported and 37 the History Log modifier is set host class drivers shall 38 supply both the "hrn or entloc" and the "entry id" 39 fields. If the History Log modifier is set and those 40 fields are not supplied, the server rejects the command 41 as an "Invalid Command" ("invalid message length" 42 protocol error. See "Invalid Command" status in Section 43 5.5, "Status Codes"). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-116 WRITE Command 11 June 1992 1 If "write history logging" is supported and the History 2 Log modifier is clear, the server ignores the setting of 3 the Reuse Entry modifier and the contents of the "hrn or 4 entloc" and "entry id" fields if they are supplied. Note 5 that host class drivers need not supply those fields when 6 the History Log modifier is clear. 7 If "write history logging" is not supported and the 8 History Log modifier or the Reuse Entry modifier is set, 9 the server rejects the command as an "Invalid Command" 10 ("invalid modifier" protocol error. See "Invalid 11 Command" status in Section 5.5, "Status Codes"). 12 If "write history logging" is supported, the History Log 13 modifier is set, and the "byte count" field is zero, the 14 server rejects the command as an Invalid Command 15 ("invalid byte count" parameter error. See "Invalid 16 Command" status in Section 5.5, "Status Codes"). 17 The server shall set the History Logged end flag in this 18 command's end message if it has caused the write history 19 log to contain a valid "write history entry" for this 20 command. See Section 5.4, "End Messages," for 21 descriptions of all end message flags. 22 | Supplement Write Log 23 | The Supplement Write log modifier allows the transfer 24 | length field of an existing write log in a controller to 25 | be modified. When this modifier is set, the transfer 26 | length of the current WRITE command is added to the 27 | transfer length field of the specified write log entry. 28 | No other fields in the write log entry are modified. In 29 | particular, the unit number field, the flags field, the 30 | logical block number field, the entry id field, and the 31 | hrn field shall remain unchanged. 32 | This modifier is valid only if the History Log and Reuse 33 | Entry modifiers are both set, and the controller supports 34 | Write History Logging; Write History Logging Support flag 35 | set, otherwise it shall be ignored. 36 | Proper use of this modifier requires that hosts should 37 | not issue more than one MSCP command at a time using the 38 | same entry locator. Requests for a given entry locator 39 | using this modifier shall be in exact logical block 40 | number sequence order with each successive logical block 41 | number being higher by precisely the transfer length 42 | (converted to sectors) of the previous WRITE command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-117 WRITE Command 11 June 1992 1 Suppress Error Correction 2 Note that this modifier only affects the compare pass of 3 a write-compare operation. It has no affect on the write 4 operation itself. 5 Suppress Error Recovery *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-118 WRITE Command 11 June 1992 1 6.18.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| 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 | entry id | entry locator | (conditionally present) 21 +---------------+---------------+ 22 entry locator 23 This field is present if and only if the corresponding 24 command message field is present. If present and the 25 History Log modifier is set in the command message, this 26 field contains the value assigned by the server that 27 uniquely identifies the internal location of the "history 28 entry" where this command's information was stored. If, 29 however, an allocation failure occurred, this field 30 contains the value FFFF(hex). If present and the History 31 Log modifier is clear in the command message, this field 32 is undefined. 33 This field contains a valid entry locator of a "write 34 history entry" for this command if and only if the 35 History Logged end flag is set in the "flags" field of 36 this end message. 37 See the description of the History Log and Reuse Entry 38 modifiers in Section 6.18.1, "WRITE Command, Command 39 Message Format" and Section 6.19.3, "WRITE HISTORY 40 MANAGEMENT Command, Description" for more detail. 41 entry id 42 This field is present if and only if the corresponding *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-119 WRITE Command 11 June 1992 1 command message field is present. If present and the 2 History Log modifier is set in the command message, the 3 contents of the corresponding command message field is 4 copied without modification to this field. If present 5 and the History Log modifier is clear in the command 6 message, this field is undefined. 7 See the description of the History Log and Reuse Entry 8 modifiers in Section 6.18.1, "WRITE Command, Command 9 Message Format" and Section 6.19.3, "WRITE HISTORY 10 MANAGEMENT Command, Description" for more detail. 11 Status Codes: 12 Success (subcode "Normal") 13 Success (subcode "Duplicate Unit Number") 14 Invalid Command (subcode "Invalid Byte Count") 15 A byte count of zero was specified with the History Log 16 modifier set. 17 Invalid Command (subcode "Invalid Entry Locator") 18 The value specified in the "entloc (entry locator)" field 19 is not within the limits of the server's "write history 20 entry" set. 21 See the description of the History Log and Reuse Entry 22 modifiers in Section 6.18.1, "WRITE Command, Command 23 Message Format" and Section 6.19.3, "WRITE HISTORY 24 MANAGEMENT Command, Description" for more detail. 25 Note that this error can only occur if "write history 26 logging" is supported and the History Log and Reuse Entry 27 modifiers are both set in the command message. 28 Invalid Command (subcode "Invalid Entry Id") 29 The server located the "write history entry" identified 30 in the "entloc (entry locator)" field but found that the 31 "entry id" contained in that entry does not equal the 32 value supplied by a host class driver when that entry was 33 allocated. This status may also be returned if the 34 History Log modifier was set, the Reuse Entry modifier 35 was clear, and the host supplied a value of FFFF (hex) in 36 the "entry id" field. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-120 WRITE Command 11 June 1992 1 See the description of the History Log and Reuse Entry 2 modifiers in Section 6.18.1, "WRITE Command, Command 3 Message Format" and Section 6.19.3, "WRITE HISTORY 4 MANAGEMENT Command, Description" for more detail. 5 Note that this error can only occur if "write history 6 logging" is supported and the History Log modifier is set 7 in the command message. 8 Invalid Command (subcode "Invalid Logical Block Number") 9 Command Aborted 10 Unit-Offline 11 Unit-Available 12 Write Protected 13 Compare Error 14 Data Error 15 Host Buffer Access Error 16 Controller Error 17 Drive Error 18 Write History Entry Access Error (subcode "Allocation Failure 19 Table Full") 20 The server was unable to allocate a "write history entry" 21 and could not record this fact because the Allocation 22 Failure Table was full. This is a transient condition; 23 therefore, the host should reissue the command. See 24 Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, 25 Description" for more details. 26 Note that this error can occur only if "write history 27 logging" is supported and the History Log modifier is set 28 and Reuse Entry modifier is clear in the command message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-121 WRITE Command 11 June 1992 1 6.18.3 Description 2 Data is fetched from the host data buffer and written to the 3 unit. For host buffer access details see Section 4.11, "Host 4 Buffer Access." 5 If a controller-based cache exists, the cache manager may use the 6 Cache Access Attribute advice in managing the caching and 7 comparing of the requested data area. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-122 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 6.19 WRITE HISTORY MANAGEMENT Command 2 Command Category: 3 Sequential 4 6.19.1 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 | "write history" | 16 +--- ---+ 17 | buffer | 18 +--- ---+ 19 | descriptor | 20 +---------------+---------------+ 21 | offset | operation | 22 +---------------+---------------+ 23 | entry id | hrn or entloc | 24 +---------------+---------------+ 25 byte count 26 The total requested length of the data transfer ("write 27 history entries") in bytes; that is, the number of "write 28 history entries" requested times the size of a "write 29 history entry" (16 bytes). If value in this field is not 30 a multiple of the "write history entry" size, the server 31 shall reject the command as an Invalid Command (subcode 32 "Invalid Byte Count") parameter error. See the 33 description of the "byte count" field in Section 5.3.1, 34 "Transfer Command Message Format," for more details on 35 architectural and server constraints. 36 The interpretation of this field varies depending on the 37 "write history management" operation specified. See the 38 description of the READ ALL and READ BY HOST REFERENCE 39 NUMBER operations in the "operation" field description 40 below for complete details. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-123 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 "write history" buffer descriptor 2 Identification of the host buffer where "write history 3 entries" are to be stored when a READ ALL or a READ BY 4 HOST REFERENCE NUMBER operation is specified. See the 5 description of those operations in the "operation" field 6 above for complete details. 7 The format of the "'write history' buffer descriptor" is 8 identical to the "buffer descriptor" field described in 9 Section 5.3.1, "Transfer Command Message Format." 10 operation 11 The "write history management" operation to be performed: 12 DEALLOCATE ALL 13 The server deallocates all of the "write history 14 entries" associated with the unit identified in the 15 "unit number" field. 16 This operation clears any "previous allocation 17 failure" condition associated with this unit for all 18 host reference numbers. This is accomplished by 19 deleting all entries with this unit number from the 20 controller's Allocation Failure Table. 21 The server ignores the "'write history' buffer 22 descriptor," "byte count," "offset," "hrn or entloc," 23 and "entry id" fields when this operation is 24 specified. 25 DEALLOCATE BY HOST REFERENCE NUMBER 26 The server deallocates all of the "write history 27 entries" that are associated with both the value 28 supplied in the "hrn (host reference number)" field 29 and the unit identified in the "unit number" field. 30 This operation clears any "previous allocation 31 failure" condition associated with this unit for this 32 host reference number. That is, the server deletes 33 the entry associated with this host reference number 34 and unit in its Allocation Failure Table if such an 35 entry exists. This does not affect "previous 36 allocation failures" associated with other units or 37 other host reference numbers. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-124 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 The server ignores the "'write history' buffer 2 descriptor," "byte count," "offset," and "entry id" 3 fields when this operation is specified. 4 DEALLOCATE BY ENTRY LOCATOR 5 The server deallocates the "write history entry" that 6 is located at the internal server location specified 7 in the "entloc (entry locator)" field. 8 If the "entry locator" is not within the limits of 9 the server's "write history entry" set, the server 10 rejects the command as an "Invalid Command" ("invalid 11 entry locator" parameter error. See "Invalid 12 Command" status in Section 5.5, "Status Codes"). 13 If the "write history entry" is already deallocated, 14 the server rejects the command as an "Invalid 15 Command" ("invalid entry id" parameter error). 16 If the value contained in the "entry id" field of the 17 command message is FFFF (hex) and the entry is not 18 already deallocated, the server deallocates the 19 "write history entry" and does not compare this value 20 with the "entry id" value associated with the "write 21 history entry." 22 If the value contained in the "entry id" field of the 23 command message is not FFFF (hex) and it does not 24 equal the "entry id" value associated with the "write 25 history entry" located via the "entry locator," the 26 server rejects the command as an "Invalid Command" 27 ("invalid entry id" parameter error. See "Invalid 28 Command" status in Section 5.5, "Status Codes"). 29 The server ignores the "'write history' buffer 30 descriptor," "byte count," and "offset" fields when 31 this operation is specified. 32 DECREMENT ALLOCATION FAILURE COUNT 33 The server decrements the count field of the entry 34 associated with this host reference number and unit 35 in its Allocation Failure Table if such an entry 36 exists. If this causes the count field to go to 37 zero, the entry is deleted. If no such entry exists, 38 the server rejects the command with a status of Write 39 History Entry Access Error (subcode "No Such Entry"). 40 Otherwise, the server returns Success. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-125 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 The server may, at its option, treat a WRITE HISTORY 2 MANAGEMENT command with the DECREMENT ALLOCATION 3 FAILURE COUNT operation as an Immediate command. 4 The server ignores the "'write history' buffer 5 descriptor," "byte count," "offset," and "entry id" 6 fields when this operation is specified. 7 READ ALL 8 If the "byte count" field is zero, the server sets 9 the command's end message "count" field equal to the 10 number of "write history entries" that are associated 11 with the unit identified in the "unit number" field, 12 and then completes the command with a status of 13 Success (subcode "Normal"). In this case the server 14 ignores the "'write history' buffer descriptor," 15 "offset," "hrn or entloc," and "entry id" fields. 16 If the "byte count" field is nonzero, the server 17 transfers the number of "write history entries" 18 implied by the "byte count" field to the host class 19 driver's buffer (specified in the "'write history' 20 buffer descriptor" field) beginning at the offset 21 specified in the "offset" field into the group of 22 entries associated with the unit identified in the 23 "unit number" field. There may be fewer "write 24 history entries" than implied by the "byte count" 25 field. The server indicates the number of "write 26 history entries" actually transferred in the "count" 27 field of the end message. Note that only those 28 "write history entries" that are associated with the 29 unit identified in the "unit number" field are 30 included in the transfer. In this case the server 31 ignores the "hrn or entloc," and "entry id" fields. 32 Note also that the "count" returned by the server may 33 be zero if there are no more entries beginning at the 34 specified offset but there is at least one entry 35 associated with the unit identified in the "unit 36 number" field. If there is no entry in the write 37 history log associated with the unit identified in 38 the "unit number" field, the server completes the 39 command with a status of Write History Entry Access 40 Error (subcode "No Such Entry"). 41 READ BY HOST REFERENCE NUMBER 42 If the "byte count" field is zero, the server sets 43 the command's end message "count" field equal to the 44 number of "write history entries" that are associated *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-126 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 with both the value contained in the "hrn (host 2 reference number)" field and the unit identified in 3 the "unit number" field, and then completes the 4 command with a status of Success (subcode "Normal"). 5 In this case the server ignores the "'write history' 6 buffer descriptor," "offset," and "entry id" fields. 7 If the "byte count" field is nonzero, the server 8 transfers the number of "write history entries" 9 implied by the "byte count" field to the host class 10 driver's buffer (specified in the "'write history' 11 buffer descriptor" field) beginning at the offset 12 specified in the "offset" filed into the group of 13 entries associated with both the value contained in 14 the "hrn (host reference number)" field and the unit 15 identified in the "unit number" field. There may be 16 fewer "write history entries" than specified in the 17 "count" field. The server indicates the number of 18 "write history entries" actually transferred in the 19 "count" field of the end message. Note that only 20 those "write history entries" that are associated 21 with both the value contained in the "hrn (host 22 reference number)" field and the unit identified in 23 the "unit number" field are included in the transfer. 24 In this case the server ignores the "entry id" field. 25 Note also that the "count" returned by the server may 26 be zero if there are no more entries beginning at the 27 specified offset but there is at least one entry 28 associated with both the value in the "hrn (host 29 reference number)" field and the unit identified in 30 the "unit number" field. If there is no entry in the 31 write history log associated with the specified host 32 reference number and unit, the server completes the 33 command with a status of Write History Entry Access 34 Error (subcode "No Such Entry"). 35 See Appendix A, "Opcode, Flag, and Offset Definitions," 36 Table A-14, "Write History Management Command Operation 37 Codes" for the values and mnemonics assigned to those 38 operations. 39 If an operation not listed in Table A-14 is specified, 40 the server rejects the command as an "Invalid Command" 41 ("invalid operation" protocol error. See "Invalid 42 Command" status in Section 5.5, "Status Codes"). 43 Note that the server shall perform the specified 44 operation when the unit is in the "Unit-Offline" (all 45 substates except "Exclusive Use"), "Unit-Online," or the 46 "Unit-Available" state relative to the issuing host class *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-127 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 driver. 2 offset 3 The offset (in "write history entries") into the group of 4 "write history entries" specified by a READ ALL or READ 5 BY HOST REFERENCE NUMBER operation. See the description 6 of these WRITE HISTORY MANAGEMENT operations in the 7 "operation" field above for complete details. 8 hrn (host reference number) or entloc (entry locator) 9 The interpretation of this field varies depending on the 10 "write history management" operation specified. See the 11 descriptions of the DEALLOCATE BY HOST REFERENCE NUMBER, 12 DEALLOCATE BY ENTRY LOCATOR, DECREMENT ALLOCATION FAILURE 13 COUNT, and READ BY HOST REFERENCE NUMBER operations in 14 the "operation" field above for complete details. 15 See Sections 6.19.3, "WRITE HISTORY MANAGEMENT Command, 16 Description," 6.7, "DISK COPY DATA Command," 6.9, "ERASE 17 Command," and 6.18, "WRITE Command" for more information 18 regarding this field. 19 entry id 20 The interpretation of this field varies depending on the 21 "write history management" operation specified. See the 22 description of the DEALLOCATE BY ENTRY LOCATOR operation 23 in the "operation" field above for complete details. 24 See Sections 6.19.3, "WRITE HISTORY MANAGEMENT Command, 25 Description," 6.7, "DISK COPY DATA Command," 6.9, "ERASE 26 Command," and 6.18, "WRITE Command" for more information 27 regarding this field. 28 Allowable modifiers: 29 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-128 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 6.19.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | byte count | 11 +---------------+---------------+ 12 | server alloc | unit alloc | 13 +---------------+---------------+ 14 | |server unalloc | 15 + +---------------+ 16 | undefined | 17 +---------------+---------------+ 18 | offset | count | 19 +---------------+---------------+ 20 | entry id | hrn or entloc | 21 +---------------+---------------+ 22 byte count 23 The number of bytes successfully transferred. See 24 Section 5.3.1, "Transfer Command End Message Format," for 25 more details. 26 unit alloc 27 The total number of "write history entries" currently 28 allocated and associated with the unit identified in the 29 command message "unit number" field. This field is 30 undefined if the operation specified in the command was 31 DEALLOCATE BY ENTRY LOCATOR or DECREMENT ALLOCATION 32 FAILURE COUNT. 33 server alloc 34 The total number of "write history entries" currently 35 allocated across all units served by the server. This 36 field is undefined if the operation specified in the 37 command was DEALLOCATE BY ENTRY LOCATOR or DECREMENT 38 ALLOCATION FAILURE COUNT. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-129 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 server unalloc 2 The total number of unallocated "write history entries" 3 currently available. This field is undefined if the 4 operation specified in the command was DEALLOCATE BY 5 ENTRY LOCATOR or DECREMENT ALLOCATION FAILURE COUNT. 6 count 7 The interpretation of this field varies depending on the 8 "operation" specified and the outcome of the operation's 9 execution. See the descriptions of those operations 10 above and the descriptions of the various status codes 11 below for specific details. 12 offset 13 Copied without modification from the corresponding 14 command message field. 15 hrn (host reference number) or entloc (entry locator) 16 The interpretation of this field varies depending on the 17 "operation" specified and possibly the outcome of the 18 operation's execution. 19 If a DEALLOCATE BY HOST REFERENCE NUMBER, DEALLOCATE BY 20 ENTRY LOCATOR, DECREMENT ALLOCATION FAILURE COUNT, or 21 READ BY HOST REFERENCE NUMBER operation was specified, 22 this field is copied without modification from the 23 corresponding command message field. 24 If a DEALLOCATE ALL or READ ALL operation was specified, 25 this field is undefined. 26 entry id 27 If a DEALLOCATE BY ENTRY LOCATOR operation was specified, 28 this field is copied without modification from the 29 corresponding command message field. Otherwise, this 30 field is undefined. 31 Status Codes: 32 Success (subcode "Normal") 33 Success (subcode "Duplicate Unit Number") 34 If a DEALLOCATE ALL, DEALLOCATE BY HOST REFERENCE NUMBER, 35 or DEALLOCATE BY ENTRY LOCATOR operation was specified, 36 the server sets the end message "count" field equal to *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-130 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 the number of "write history entries" deallocated. 2 If a DECREMENT ALLOCATION FAILURE COUNT operation was 3 specified, the server sets the end message "count" field 4 to the decremented value in the count field of the entry 5 in the Allocation Failure Table. 6 If a READ ALL operation with a zero command message "byte 7 count" field was specified, the server sets the end 8 message "count" field equal to the number of "write 9 history entries" associated with the unit identified in 10 the "unit number" command message field. 11 If a READ BY HOST REFERENCE NUMBER operation with a zero 12 command message "byte count" field was specified, the 13 server sets the end message "count" field equal to the 14 number of "write history entries" associated with both 15 the value contained in the "hrn (host reference number)" 16 command message field and the unit identified in the 17 "unit number" command message field. 18 If a READ ALL or READ BY HOST REFERENCE NUMBER operation 19 with a nonzero command message "byte count" field was 20 specified, the server sets the end message "count" field 21 equal to the number of "write history entries" actually 22 transferred to the host's buffer. 23 Invalid Command (subcode "Invalid Byte Count") 24 Invalid Command (subcode "Invalid Operation") 25 Invalid Command (subcode "Invalid Entry Locator") 26 Invalid Command (subcode "Invalid Entry Id") 27 Command Aborted 28 Unit-Offline (subcode "Exclusive Use") 29 The unit is under the "Exclusive Access" of a host class 30 driver other than the host class driver that issued this 31 command. 32 As described in Section 6.19.3, "WRITE HISTORY MANAGEMENT 33 Command, Description," all of the "write history entries" 34 associated with the unit are only accessible by the host 35 class driver that was granted "Exclusive Access" to the 36 unit. The server will therefore take no action on the 37 "write history entries" associated with the unit when 38 this condition exists. 39 Host Buffer Access Error 40 Before returning this status the server sets the end *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-131 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 message "count" field equal to the number of "write 2 history entries" transferred before the error occurred. 3 Note that this error can only occur if the operation 4 specified is either a READ ALL or READ BY HOST REFERENCE 5 NUMBER with a nonzero "byte count" field. 6 Write History Entry Access Error (subcode "No Such Entry") 7 The server returns this status under the following 8 conditions: 9 1. A READ ALL operation was specified but the server 10 could not find any "write history entries" associated 11 with the unit identified in the "unit number" command 12 message field. 13 2. A READ BY HOST REFERENCE NUMBER operation was 14 specified but the server could not find any "write 15 history entries" associated with both the value 16 contained in the "hrn (host reference number)" 17 command message field and the unit identified in the 18 "unit number" command message field. 19 3. A DEALLOCATE BY ENTRY LOCATOR operation was specified 20 but the specified "write history entry" is not 21 currently associated with the unit identified in the 22 "unit number" command message field. 23 4. A DECREMENT ALLOCATION FAILURE COUNT operation was 24 specified but no entry associated with this host 25 reference number and unit was found in the Allocation 26 Failure Table. 27 In all the above cases, the server zeros the end message 28 "count" field. 29 Write History Entry Access Error (subcode "Previous 30 Allocation Failure") 31 A READ BY HOST REFERENCE NUMBER operation was specified 32 but a previous "write history entry" allocation failure 33 condition exists for this host reference number and unit 34 or a READ ALL operation was specified and a previous 35 allocation failure exists for some host reference number 36 and this unit. In either case, no "write history 37 entries" are transferred to the host. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-132 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 6.19.3 Description 2 Support of "write history logging" is a server implementation 3 dependent option. Servers that do not provide such support shall 4 reject this command as an "Invalid Command" ("invalid opcode" 5 protocol error. See "Invalid Command" status in Section 5.5, 6 "Status Codes"). 7 Servers that provide "write history logging" support shall also 8 support the TERMINATE CLASS DRIVER/SERVER CONNECTION command as 9 described in Section 7.10, "Multihost TERMINATE CLASS 10 DRIVER/SERVER CONNECTION Command." Note that servers that 11 support "write history logging" but do not provide Multihost 12 Support treat the TERMINATE CLASS DRIVER/SERVER CONNECTION 13 command as a no-operation as described in Section 6.1.1, 14 "No-Operation Commands." 15 "Write history logging" and the TERMINATE CLASS DRIVER/SERVER 16 CONNECTION command were defined primarily for the purpose of 17 assisting in the operation of host based volume shadowing 18 implementations. All servers that support "write history 19 logging" (and therefore the TERMINATE CLASS DRIVER/SERVER 20 CONNECTION command) shall set the Write History Logging Support 21 controller flag. 22 "Write history logging" provides host class drivers with a means 23 for detecting and recovering from the incomplete execution of 24 DISK COPY DATA, ERASE, and WRITE commands addressed to a disk 25 unit caused by unexpected host failure (e.g., a system crash). 26 The server provides a set of "write history entries" for logging 27 information related to write type commands issued by a host. The 28 number of "write history entries" contained in the set provided 29 by a server is implementation dependent. The number provided 30 depends on an implementation's memory availability and speed of 31 I/O request execution. In a multihost environment the host class 32 drivers are responsible for managing the distribution of the 33 "write history entry" set among themselves. 34 The server also provides a table, the Allocation Failure Table, 35 for recording "write history entry" allocation failures. A 36 "write history entry" allocation failure occurs when the server 37 cannot allocate a new "write history entry" in response to a 38 write type command requesting such an allocation because all 39 "write history entries" are already allocated. The Allocation 40 Failure Table is initially empty (i.e., contains no entries). An 41 entry has three fields: "host reference number," "unit number," 42 and "count." When an allocation failure occurs, the server 43 searches the Allocation Failure Table for entry with the host 44 reference number and unit number associated with the write type 45 command. If such an entry is found, the server increments the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-133 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 "count" field of that entry and completes processing of the 2 allocation failure as detailed below. If no such entry is found 3 and the table is not full, the server creates a new entry with 4 the host reference number and unit number associated with the 5 write type command and sets the "count" field to one. The server 6 then completes processing of the allocation failure as detailed 7 below. If no such entry is found and the table is full, the 8 server rejects the write type command with a status of Write 9 History Entry Access Error (subcode "Allocation Failure Table 10 Full"). 11 The host can use the WRITE HISTORY MANAGEMENT command to clear an 12 allocation failure condition using either the DECREMENT 13 ALLOCATION FAILURE COUNT operation or a DEALLOCATE operation. 14 Normally, the host will use the former method after being 15 notified of the condition by the end message of the write type 16 command that caused it. Therefore, allocation failure conditions 17 are usually transitory in nature. Note that an allocation 18 failure condition exists for a given host reference number and 19 unit exactly when there exists an entry in the Allocation Failure 20 Table for that host reference number and unit. Therefore, 21 clearing an allocation failure condition using a DEALLOCATE 22 operation amounts to deleting the entry in the Allocation Failure 23 Table associated with that host reference number and unit, 24 regardless of the value in the "count" field in that entry. 25 If a write type command is rejected with a status of Write 26 History Entry Access Error (subcode "Allocation Failure Table 27 Full"), the host should reissue the command since this condition 28 is transitory in nature and the reissued command is likely to 29 | succeed. The server may maintain the "write history entry" set 30 | in volatile memory and shall initialize all "write history 31 | entries" after each power-up. 32 The initialization process the server performs consists of 33 setting the "write history entries" into the deallocated state 34 and deleting all entries in the Allocation Failure Table. "Write 35 history entries" are allocated only via a History Log modified 36 write type command. A "write history entry" is considered 37 deallocated exactly when it is not accessible to a host via the 38 WRITE HISTORY MANAGEMENT command or via a History Log and Reuse 39 Entry modified write type command. The exact mechanism for 40 tracking the status of a "write history entry" is server 41 implementation dependent. However, in order to provide one such 42 mechanism, the host shall never supply a value of FFFF (hex) in 43 the "entry id" field. The server may, at its option, reject a 44 command with an "entry id" field of FFFF (hex) as an "Invalid 45 Command" ("invalid entry id" parameter error). *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-134 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 For the purposes of retrieving and deallocating the "write 2 history entries," when an entry is associated with a write type 3 command it is also associated with the unit to which the command 4 was addressed. (The "unit number" is stored within the entry.) 5 The loss of the "Controller-Online" connection between the server 6 and a host class driver shall have no effect on any allocated 7 "write history entry" or Allocation Failure Table entry. Such 8 entries will remain allocated until they are specifically 9 deallocated 10 o by a host class driver request (i.e., via a WRITE 11 HISTORY MANAGEMENT command that specifies an appropriate 12 operation) 13 o by the occurrence of a condition that requires the 14 server to initialize its set of "write history entries" 15 as described earlier in this section 16 Host class drivers associate a write type command with a "write 17 history entry" by setting the History Log modifier in the 18 command's message. The class driver also supplies information in 19 the command message which allows the host to: 20 1. Associate an entry with a group of entries -- "hrn 21 (host reference number)" field. 22 2. Reuse an entry it has already allocated -- "entloc 23 (entry locator)" field. 24 3. Uniquely identify an entry among all of the entries in 25 a group that are available for its use -- "entry id" 26 field. 27 See Sections 6.7, "DISK COPY DATA Command," 6.9, "ERASE Command," 28 and 6.18, "WRITE Command" for descriptions of that modifier and 29 those fields. The actions a server takes when a History Log 30 modified write type command is received are described in more 31 detail later in this section. 32 The WRITE HISTORY MANAGEMENT command allows host class drivers to 33 manage the "write history entries" associated with a unit via the 34 following operations: 35 o Deallocate all entries. 36 o Deallocate the group of entries associated with a 37 particular "host reference number." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-135 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 o Deallocate a specific entry. 2 o Read all entries. 3 o Read the group of entries associated with a particular 4 "host reference number." 5 o Decrement the count of an Allocation Failure Table 6 entry. 7 See the description of the "operation" field in Section 6.19.1, 8 "WRITE HISTORY MANAGEMENT Command, Command Message Format" for 9 complete descriptions of those operations. 10 A server may use any appropriate internal format for a "write 11 history entry." A "write history entry" presented to a host in 12 response to a WRITE HISTORY MANAGEMENT READ ALL or READ BY HRN 13 operation shall have the following format: 14 31 0 15 +---------------+---------------+ 16 | unit number | entry locator | 17 +---------------+---------------+ 18 | transfer length | 19 +-------------------------------+ 20 | starting logical block number | 21 +---------------+---------------+ 22 | entry flags | hrn | 23 +---------------+---------------+ 24 entry locator 25 The value assigned by the server that uniquely identifies 26 the internal location of the "write history entry." 27 unit number 28 Identifies the unit to which the command associated with 29 the "write history entry" was addressed. 30 transfer length 31 The format of this field varies depending on the setting 32 of the "Transfer Length in Blocks" entry flag in the 33 "write history entry." The server may, at its option, 34 store the transfer length of the associated command in 35 bytes or blocks. If the byte count in the associated 36 command was not a multiple of the unit's block size, the 37 server may store the exact byte count, the byte count *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-136 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 rounded up to the next multiple of the unit's block size, 2 or the block count computed by rounding the byte count up 3 to a multiple of the unit's block size. 4 starting logical block number 5 The logical block number (position) on the disk volume at 6 which the write operation is to start as specified in the 7 associated command. 8 hrn (host reference number) 9 The value assigned by a host class driver for referencing 10 a group of "write history entries." 11 entry flags 12 Bit flags, collectively known as entry flags, used to 13 indicate the state of a "write history entry." The 14 following flags are defined: 15 Error 16 Set if and only if the write type command for 17 which the "write history entry" was created or 18 updated did not complete with a status of 19 Success. 20 Transfer Length in Blocks 21 Set if and only if the "transfer length" field of 22 the "write history entry" is specified in blocks 23 rather than in bytes. Note that a server may 24 convert the transfer length of a command from 25 bytes to blocks or vice versa before storing it 26 in the "transfer length" field. Such conversion 27 shall not truncate partial blocks. 28 Refer to Appendix A, "Opcode, Flag, and Offset 29 Definitions," Table A-15, "Write History Entry Flags" for 30 the values assigned to the defined flags. All other 31 entry flag bits are reserved, and shall be treated in 32 accordance with the requirements for reserved fields 33 described in Section 5.2, "Reserved and Undefined 34 Fields." 35 entry id 36 The value assigned by a host class driver to uniquely 37 identify a "write history entry" among all of the "write *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-137 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 history entries" in a group that are available for its 2 use. This field is NOT present in the host-visible 3 "write history entry" pictured above. However, the 4 server shall internally maintain the association between 5 the "entry id" specified in the History Log modified 6 command and its corresponding "write history entry." 7 Note that the host may not supply a value of FFFF (hex) 8 for this field. That value is reserved for use by 9 servers to mark a "write history entry" as unallocated in 10 its internal format. Supplying an "entry id" value of 11 FFFF (hex) will result in unpredictable behavior, 12 possibly leading to user data corruption. 13 Upon receipt of a host class driver issued History Log modified 14 write type command the server performs the following operations: 15 1. Validates the command message fields and checks the 16 unit state in the normal manner. Note that this 17 implies having an established communications path in 18 the case of History Log modified DISK COPY DATA command 19 (see Section 6.7, "DISK COPY DATA Command"). 20 If the field validation or unit state checks fail, the 21 server rejects the command with the appropriate status. 22 Otherwise, the server proceeds to Step 2. 23 2. Checks the setting of the Reuse Entry modifier to see 24 whether the command is to be associated with a newly 25 allocated "write history entry" or with a previously 26 allocated "write history entry." 27 If the the Reuse Entry modifier is clear, the server 28 proceeds to Step 3 (allocate new). Otherwise, the 29 server proceeds to Step 4 (reuse previously allocated). 30 3. Searches the set of "write history entries" for an 31 entry that is not currently allocated. 32 If an unallocated "write history entry" is not found, 33 the server shall record this fact in the Allocation 34 Failure Table as described above and continue normal 35 processing of the command. The server shall return 36 FFFF(hex) in the "entry locator" field of the end 37 message and set the Allocation Failure end flag in the 38 end message. 39 If the server cannot record the failure in the 40 Allocation Failure Table, it shall reject the command 41 with a status of Write History Entry Access Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-138 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 (subcode "Allocation Failure Table Full"). Due to the 2 transitory nature of this condition, the host should 3 reissue the failed write type command as it will likely 4 succeed on retry. 5 If an unallocated "write history entry" is found, the 6 server performs the following operations: 7 a. Copies the contents of the associated command's 8 command message "unit number" field to the 9 "unit number" field in that entry. 10 b. Preserves the associated command's transfer 11 length ("byte count" or "logical block count") 12 in that entry as detailed in the description of 13 "transfer length" above. 14 c. Copies the contents of the associated command's 15 command message "logical block number" (or 16 "destination lbn") field to the "starting 17 logical block number" field within that entry. 18 d. Copies the contents of the associated command's 19 command message "hrn (host reference number)" 20 field to the "hrn (host reference number)" 21 field within that entry. 22 e. Associates the associated command's command 23 message "entry id" field with that entry. 24 f. Continues normal processing of the command. 25 4. Checks the value contained in the "entry locator" command 26 message field to ensure that it is within the limits of 27 the set of "write history entries." 28 If the "entry locator" is not within the limits of the 29 set, the server rejects the command as an "Invalid 30 Command" ("invalid entry locator" parameter error. See 31 "Invalid Command" status in Section 5.5, "Status Codes"). 32 If the "entry locator" is within the limits of the set, 33 the server uses the value of the "entry locator" as an 34 index into the set of "write history entries" and then 35 proceeds to Step 5. 36 5. Compares the "entry id" value associated with the located 37 "write history entry" with the value contained in the 38 "entry id" command message field. Note that the value *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MINIMAL MSCP COMMAND SET Page 6-139 WRITE HISTORY MANAGEMENT Command 11 June 1992 1 FFFF (hex) is reserved for servers to mark "write history 2 entries" as unallocated. 3 If those values do not match, the server rejects the 4 command as an "Invalid Command" ("invalid entry id" 5 parameter error. See "Invalid Command" status in Section 6 5.5, "Status Codes"). The server may optionally check 7 that the value supplied in the "entry id" command message 8 field is not FFFF (hex) and, if it is, reject the command 9 with this same status. If the command is not rejected 10 and the values do match, the server proceeds to Step 6. 11 6. The server performs the following operations: 12 a. Copies the contents of the associated command's 13 command message "unit number" field to the 14 "unit number" field in the located entry. 15 b. Preserves the associated command's transfer 16 length ("byte count" or "logical block count") 17 in that entry as detailed in the description of 18 "transfer length" above. 19 c. Copies the contents of the associated command's 20 command message "logical block number" (or 21 "destination lbn") field to the "starting 22 logical block number" field in the located 23 entry. 24 d. Continues normal processing of the command. 25 After a command associated with a "write history entry" has 26 aborted, terminated, or completed, the server shall set or clear 27 the "Error" flag in the "entry flags" field of the "write history 28 entry" and continue processing. The server clears the "Error" 29 flag if and only if the associated command completed with a 30 status of "Success" and sets the "Error" flag in all other cases. 31 In addition, prior to returning the end message of a command 32 associated with a "write history entry" the server shall copy the 33 "entry id" field of the command message to the "entry id" field 34 of the end message and copy the "entry locator" field of the 35 "write history entry" to the "entry locator" field of the end 36 message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-1 11 June 1992 1 CHAPTER 7 2 MULTIHOST SUPPORT 3 7.1 Overview 4 Multihost Support is an MSCP option that allows simultaneous 5 communication between multiple host class drivers and an MSCP 6 server across separate logical connections. 7 Various aspects of Multihost Support have already been discussed 8 in previous chapters. A brief review of the more important 9 aspects, along with specific section references, follows: 10 o Controllers shall maintain each host class driver/MSCP 11 server connection as a separate communications entity. 12 See Section 3.3, "Multihost Communication." Controller 13 state actually reflects the state of each class 14 driver/MSCP server connection. See Section 4.1, 15 "Controller States." 16 o Controllers shall maintain the state of a unit 17 ("Unit-Offline," "Unit-Available," and "Unit-Online") 18 separately for each class driver/MSCP server connection. 19 See Section 4.3, "Unit States." That section also 20 contains important details regarding "Exclusive Access" 21 of a unit (a mandatory feature of Multihost Support). 22 o Command execution ordering is performed on a unit basis 23 rather than a single connection basis. Controllers shall 24 therefore enforce the Sequential command execution 25 guarantees across all "Controller-Online" connections. 26 Controllers are expressly permitted to include all 27 Non-Sequential commands received from all 28 "Controller-Online" class drivers, directed to the same 29 unit, in any optimization algorithm being performed on 30 the unit. See 4.5, "Command Categories and Execution 31 Order." 32 o Controllers shall maintain and operate according to the 33 setting of a separate set of host-settable controller 34 flags for each host class driver/MSCP server connection. 35 Each class driver is expressly permitted to specify 36 different settings for the host-settable controller flags 37 and as a result realize different controller operation. 38 See Section 5.6, "Controller Flags." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-2 Overview 11 June 1992 1 o Controllers shall maintain only one set of host-settable 2 unit flags for a particular unit regardless of the number 3 of host class drivers that have brought the unit into the 4 "Unit-Online" state. The unit will operate in an 5 identical manner (according to the setting of the 6 host-settable unit flags) for each host that has brought 7 the unit "Unit-Online." Any host may alter the setting 8 of the host-settable unit flags (for itself and all 9 others) only via the SET UNIT CHARACTERISTICS command and 10 only after bringing the unit "Unit-Online." See Section 11 5.7, "Unit Flags." 12 Controllers that provide Multihost Support shall implement all 13 the commands described in Chapter 6, "Minimal MSCP Command Set." 14 Command operation is identical to what is described there, with 15 the exception of the the ABORT, AVAILABLE, GET COMMAND STATUS, 16 GET UNIT STATUS, ONLINE, SET CONTROLLER CHARACTERISTICS, and SET 17 UNIT CHARACTERISTICS commands. The operation of each of those 18 commands within a Multihost environment is described later in 19 this chapter. The same major section/subsection format described 20 in Section 6.1, "[Minimal MSCP Command Set] Overview" is used for 21 the command descriptions in this chapter. The references 22 contained in Section 6.1 for message offset definitions and 23 treatment of invalid and no-operation commands apply to the 24 Multihost environment as well. In cases where information 25 contained in the Chapter 6 command descriptions is identical for 26 both the single host and multihost operation, the Chapter 6 27 information is referenced rather than repeating it in this 28 chapter. In addition, the ACCESS NONVOLATILE MEMORY command, 29 which shall be supported by all controllers that provide 30 Multihost Support, is also described. Note that controllers that 31 do not provide Multihost Support may optionally implement the 32 ACCESS NONVOLATILE MEMORY command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-3 Multihost ABORT Command 11 June 1992 1 7.2 Multihost ABORT Command 2 Command Category: 3 Immediate 4 7.2.1 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 See Section 6.2.1, "ABORT Command, Command Message 17 Format." 18 outstanding reference number 19 The "command reference number" of the command that is to 20 be aborted. 21 As described in Section 5.3, "Command Messages," "command 22 reference numbers" need not be unique for commands issued 23 by different class drivers -- i.e., commands issued by 24 different hosts or commands for different MSCP servers 25 from the same host. Controllers shall therefore use the 26 combination of the "outstanding reference number" and the 27 connection on which the ABORT command was received in 28 order to uniquely identify commands issued by different 29 hosts. 30 Allowable modifiers: 31 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-4 Multihost ABORT Command 11 June 1992 1 7.2.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | outstanding reference number | 11 +-------------------------------+ 12 outstanding reference number 13 See Section 6.2.2, "ABORT Command, End Message Format." 14 Status Codes: 15 Success (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-5 Multihost ABORT Command 11 June 1992 1 7.2.3 Description 2 See Section 6.2.3, "ABORT Command, Description." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-6 Multihost ACCESS NONVOLATILE MEMORY Command 11 June 1992 1 7.3 Multihost ACCESS NONVOLATILE MEMORY Command 2 Command Category: 3 Immediate 4 7.3.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | reserved | 10 +---------------+-------+-------+ 11 | modifiers | rsvd | opcode| 12 +---------------+-------+-------+ 13 | reserved | 14 +-------------------------------+ 15 | offset | 16 +---------------+---------------+ 17 | length | operation | 18 +---------------+---------------+ 19 | | 20 / nonvolatile / 21 / memory data / 22 | | 23 +-------------------------------+ 24 offset 25 The byte offset within the server's nonvolatile memory at 26 which to perform the operation. 27 operation 28 The operation to be performed on the server's nonvolatile 29 memory: 30 Read 31 Exchange 32 Test and Set 33 See Appendix A, "Opcode, Flag, and Offset Definitions," 34 Table A-12, "Access Nonvolatile Memory Command Operation 35 Codes" for the values and mnemonics assigned to those 36 operations. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-7 Multihost ACCESS NONVOLATILE MEMORY Command 11 June 1992 1 If any other value is specified the server rejects the 2 command as an "Invalid Command" ("invalid operation" 3 protocol error. See "Invalid Command" status in Section 4 5.5, "Status Codes"). 5 length 6 The number of bytes of nonvolatile memory data included 7 in this command message or to be returned in this 8 command's end message. This should be an even value if 9 the operation is "Test and Set." If an odd "length" is 10 specified with the "Test and Set" operation the server 11 rejects the command as an "Invalid Command" ("invalid 12 length" parameter error. See "Invalid Command" status in 13 Section 5.5, "Status Codes"). 14 The maximum valid "length" is server dependent. However, 15 all servers that implement this command shall support 16 values of "length" in the range 0 through 32. If a 17 "length" larger than the server's maximum is specified 18 the server rejects the command as an "Invalid Command" 19 ("invalid length" parameter error. See "Invalid Command" 20 status in Section 5.5, "Status Codes"). 21 nonvolatile memory data 22 "Length" bytes of data to be used in the operation. 23 Allowable modifiers: 24 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-8 Multihost ACCESS NONVOLATILE MEMORY Command 11 June 1992 1 7.3.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| reserved | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | nonvolatile memory size | 11 +-------------------------------+ 12 | offset | 13 +---------------+---------------+ 14 | length | operation | 15 +---------------+---------------+ 16 | | 17 / nonvolatile / 18 / memory data / 19 | | 20 +-------------------------------+ 21 nonvolatile memory size 22 The number of bytes of nonvolatile memory implemented by 23 the server. 24 offset 25 operation 26 length 27 Copied without alteration from the command message. 28 nonvolatile memory data 29 "Length" bytes of data returned by the operation. 30 Status Codes: 31 Success (subcode "Normal") 32 Invalid Command (subcode "Invalid Length") 33 Invalid Command (subcode "Invalid Operation") 34 Compare Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-9 Multihost ACCESS NONVOLATILE MEMORY Command 11 June 1992 1 7.3.3 Description 2 The ACCESS NONVOLATILE MEMORY command provides class driver 3 access to a nonvolatile memory region within the controller or 4 server. Hosts may use this memory to store arbitrary parameters 5 or information. MSCP servers merely store the data; they do not 6 use it in any way. 7 The presence and size of a nonvolatile memory is server 8 dependent. However, whenever a server provides a nonvolatile 9 memory, the memory must be at least 16 bytes long. Servers that 10 provide Multihost Support shall always implement a 16 byte or 11 larger nonvolatile memory. Single host servers may optionally 12 implement a nonvolatile memory. If a single host server does not 13 implement a nonvolatile memory, then it need not implement this 14 command. In that case the controller shall reject this command's 15 opcode as an "Invalid Command" ("invalid opcode" protocol error. 16 See "Invalid Command" status in Section 5.5, "Status Codes"). 17 The nonvolatile memory is addressed at offsets 0 through N-1, 18 where N is the size of the server's nonvolatile memory in bytes. 19 Class drivers may access offsets N and higher, even though they 20 are not included in the implemented memory. Attempts to write 21 offsets N and higher are ignored and always succeed. Attempts to 22 read offsets N and higher return zero. 23 Three operations are provided for accessing the nonvolatile 24 memory. The detailed semantics of these operations are as 25 follows: 26 Read 27 The server reads "length" bytes beginning at offset 28 "offset" and returns them as the "nonvolatile memory 29 data" in the end message. The "nonvolatile memory 30 data" in the command message is ignored. 31 Exchange 32 The server reads "length" bytes beginning at offset 33 "offset" and returns them as the "nonvolatile memory 34 data" in the end message. Next, the server writes 35 "length" bytes beginning at offset "offset" with the 36 "nonvolatile memory data" from the command message. 37 This operation exchanges the nonvolatile memory data 38 with the memory contents stored in the server. The 39 command message provides the new memory contents, 40 while the old memory contents are returned in the end 41 message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-10 Multihost ACCESS NONVOLATILE MEMORY Command 11 June 1992 1 Test and Set 2 The server reads "length"/2 bytes beginning at offset 3 "offset" and returns them as the first half of the 4 "nonvolatile memory data" in the end message. Next, 5 the server compares these "length"/2 bytes against 6 the first half of the "nonvolatile memory data" from 7 the command message. If they are different, the 8 server returns a "Compare Error" status code. If 9 they are the same, the server writes "length"/2 bytes 10 beginning at offset "offset" with the second half of 11 the "nonvolatile memory data" from the command 12 message and returns a "Success" status code. In both 13 cases, the second half of the "nonvolatile memory 14 data" in the end message is copied without alteration 15 from the command message. 16 This operation provides an atomic test-and-set 17 operation. The "nonvolatile memory data" is divided 18 into equal length halves. The first half is compared 19 against the values stored in the server to determine 20 the "Success" or "Compare Error" status of the 21 command. If comparison shows both values are equal, 22 then the second half of "nonvolatile memory data" is 23 stored into the nonvolatile memory. In either case, 24 the values that were stored in the server prior to 25 this operation are returned in the first half of the 26 end message's "nonvolatile memory data." 27 For all three operations, a "length" of zero is legal. It is 28 treated as a no-operation and always succeeds. This is primarily 29 useful as a means for class drivers to determine the size of the 30 server's nonvolatile memory. 31 The server shall implement all operations requested by this 32 command as atomic operations. If several ACCESS NONVOLATILE 33 MEMORY commands are outstanding simultaneously, the server may 34 perform them in any sequence, but shall process only one of them 35 at a time. 36 The server shall remember the contents of its nonvolatile memory 37 across power failures, reinitializations, losses of context, and 38 other normal failures. However, the following events are not 39 normal and may result in loss of the nonvolatile memory contents: 40 1. Field Service attention or other maintenance actions. If 41 the component containing the nonvolatile memory is 42 replaced, its contents may become undefined. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-11 Multihost ACCESS NONVOLATILE MEMORY Command 11 June 1992 1 2. A power failure, reinitialization, or other loss of 2 context while the nonvolatile memory is being modified. 3 The offset being modified, plus some controller dependent 4 number of adjacent locations, may become undefined. 5 The nonvolatile memory should contain all zeros in newly shipped 6 servers. 7 One characteristic of commonly available nonvolatile memories is 8 that they can only be reliably written a limited number of times. 9 Therefore class drivers may not treat the nonvolatile memory as 10 they would standard RAM or disk memory. Class drivers should 11 design their algorithms for using the nonvolatile memory to 12 ensure that they do not alter it more often than an average of 13 once per day. Short periods of frequent updates are acceptable, 14 provided they are balanced by long periods of few updates. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-12 Multihost AVAILABLE Command 11 June 1992 1 7.4 Multihost AVAILABLE Command 2 Command Category: 3 Sequential 4 7.4.1 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 15 If the "All Class Drivers" modifier is set and the unit 16 is "Unit-Online" to the issuing host as well as one or 17 more other hosts, the unit becomes "Unit-Available" to 18 all hosts. 19 If the "All Class Drivers" modifier is set and the unit 20 is "Unit-Online" only to the issuing host, the unit 21 becomes "Unit-Available" to the issuing host. 22 If the "All Class Drivers" modifier is clear and the unit 23 is "Unit-Online" to the issuing host as well as one or 24 more other hosts, the unit becomes "Unit-Available" to 25 the issuing host only. The state of the unit relative to 26 all other hosts is unaffected. 27 If the unit is "Unit-Offline" or already "Unit-Available" 28 to the issuing host, the setting of the "All Class 29 Drivers" modifier is ignored. 30 Clear Serious Exception (ignored for disk class devices) 31 Exclusive Access 32 If the "Exclusive Access" modifier is set and the unit is 33 "Unit-Online" to the issuing host and is not 34 "Unit-Online" to any other host, the unit becomes 35 "Unit-Available" to and under the "Exclusive Access" of 36 the issuing host. This specifically includes the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-13 Multihost AVAILABLE Command 11 June 1992 1 possibility that the unit became "Unit-Available" to the 2 issuing host as well as to other hosts as a result of the 3 "All Class Drivers" modifier also being set in the 4 command. Note that controllers shall service the "All 5 Class Drivers" modifier before servicing the "Exclusive 6 Access" modifier. 7 If the "Exclusive Access" modifier is set and the unit is 8 "Unit-Available" to the issuing host and is not 9 "Unit-Online" to any other host or the unit is "Unit 10 Offline (substate 'No Media Loaded')", the issuing host 11 is granted "Exclusive Access" of the unit. The unit's 12 state is otherwise unchanged. 13 If the "Exclusive Access" modifier is set and the unit is 14 "Unit-Online" to and under the "Exclusive Access" of the 15 issuing host, the unit becomes "Unit-Available" to the 16 issuing host. "Exclusive Access" of the unit is, 17 however, retained. 18 If the "Exclusive Access" modifier is clear and the unit 19 is "Unit-Online" to and under the "Exclusive Access" of 20 the issuing host, the unit becomes "Unit-Available" to 21 the issuing host and "Exclusive Access" of the unit is 22 released. 23 If the "Exclusive Access" modifier is clear and the unit 24 is "Unit-Available" or "Unit Offline (substate 'No Media 25 Loaded')" to and also under the "Exclusive Access" of the 26 issuing host, "Exclusive Access" to the unit is released. 27 The unit's state is otherwise unchanged. 28 If the unit is "Unit-Offline" to the issuing host for any 29 reason other than "No Media Loaded," the "Exclusive 30 Access" modifier is ignored. 31 Note that granting "Exclusive Access" of a unit to a host 32 implicitly causes the unit to become "Unit-Offline 33 (substate 'Exclusive Use')" to all other hosts connected 34 via this controller and "Unit-Offline (substate 'Online 35 To Another Controller')" to hosts which may potentially 36 have access to the unit via another controller. 37 Conversely, the release of a unit from the "Exclusive 38 Access" of a host implicitly causes the unit to become 39 "Unit-Available" to all other hosts. 40 Note also that controllers ignore duplicate unit number 41 conditions when a host retains "Exclusive Access" of a 42 unit. That is, if the unit is "Unit-Online" to and under 43 the "Exclusive Access" of the issuing host and in *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-14 Multihost AVAILABLE Command 11 June 1992 1 addition had a duplicate unit number prior to the receipt 2 of an AVAILABLE command with the "Exclusive Access" 3 modifier set, the unit will not be become "Unit-Offline" 4 nor will it be spun-down. Instead the unit becomes 5 "Unit-Available" to and "Exclusive Access" is retained by 6 the issuing host. 7 | Note also that "Exclusive Access" is released if any of 8 | the following events occur: 9 | 1. The controller loses or breaks the connection to 10 | the host that has "Exclusive Access" of the 11 | drive. 12 | 2. The drive becomes unknown to the controller 13 | (e.g., port button disabled.) 14 | 3. The drive becomes inoperative, "Unit-Offline, 15 | Inoperative." 16 | 4. The controller is 'rebooted', by itself, by an 17 | operator, or by any host. 18 Spin-down 19 Requests that the disk stop spinning and that the heads 20 be unloaded. Note that the command completes as soon as 21 the spin-down has been initiated, rather than waiting for 22 the disk to stop spinning. The spin-down will not be 23 initiated if either or both of the following conditions 24 exist: 25 1. The unit belongs to a multiunit drive and shares 26 a spindle with some other unit that is 27 "Unit-Online" (See Section 4.16.2, "Multiunit 28 Drives and Formatters"). 29 2. The unit is still "Unit-Online" to one or more 30 other hosts and the "All Class Drivers" modifier 31 is clear. 32 Note that a spin-down request is honored and performed 33 (unless prohibited as just described) when the unit is 34 "Unit-Available" to the issuing host as well as when it 35 is "Unit-Online" to the issuing host. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-15 Multihost AVAILABLE Command 11 June 1992 1 7.4.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 Status Codes: 11 Success (subcode "Normal") 12 This status code (i.e., subcode zero) is returned under 13 the following conditions: 14 1. The unit changes from "Unit-Online" to 15 "Unit-Available" and the action or actions (if 16 any) requested by the setting of the "All Class 17 Drivers," "Exclusive Access," and "Spin-down" 18 modifiers were successfully completed. 19 2. The unit was already "Unit-Available" to the 20 issuing host and the action or actions (if any) 21 requested by the setting of the "Exclusive 22 Access" and "Spin-down" modifiers were 23 successfully completed. 24 Separate bits within the "Success" status subcode field 25 are used to indicate that the actions requested by the 26 setting of the "All Class Drivers" and "Spin-down" 27 modifiers could not be performed but the command was 28 otherwise successful. See the "Spin-down Ignored" and 29 "Still Online" subcode bit flag descriptions below. 30 Another "Success" status subcode bit is used to indicate 31 that the command was successful and that the unit will 32 remain connected to the controller (see the "Still 33 Connected" bit flag description). 34 Note that if the unit was "Unit-Online" (and not under 35 the "Exclusive Access" of the issuing host) but had a 36 duplicate unit number prior to the AVAILABLE command 37 being issued, the controller may optionally return a 38 status code of: "Success (subcode 'Normal')" or "Success 39 (subcode 'Duplicate Unit Number')" or "Unit-Offline *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-16 Multihost AVAILABLE Command 11 June 1992 1 (subcode 'Duplicate Unit Number')." 2 Success (subcode "Spin-down Ignored") 3 The "Spin-down Ignored" subcode bit flag is set if the 4 unit could not be spun-down due to one of the following 5 conditions: 6 1. One or more other units with which this unit 7 shares a spindle is still "Unit-Online" (see 8 Section 4.16.2, "Multiunit Drives and 9 Formatters," for an explanation of shared 10 spindles). 11 2. The unit is still "Unit-Online" to one or more 12 other hosts. 13 Success (subcode "Still Connected") 14 The "Still Connected" subcode bit flag is set if the unit 15 may potentially be accessed via another controller and 16 one or more other units with which this unit shares an 17 access path is still "Unit-Online," preventing this unit 18 from being accessed via that other controller (if any). 19 See Section 4.16.1, "Multiaccess Drives," for a 20 discussion of access paths. 21 The "Still Connected" subcode bit flag will always be set 22 if the "Spin-down Ignored" subcode bit flag is set. 23 Success (subcode "Still Online") 24 The "Still Online" subcode bit flag is set if the unit is 25 still "Unit-Online" to one or more other hosts via this 26 controller. If the "Exclusive Access" modifier was set 27 this status code implies that "Exclusive Access" of the 28 unit was denied. 29 The "Still Online" subcode bit flag will always be set if 30 the "Spin-down Ignored" subcode bit flag is set. 31 Command Aborted 32 The command has been rejected and the unit's state has 33 not changed. If the unit was "Unit-Online" prior to 34 issuing this command, then the unit is still 35 "Unit-Online" and it is still spinning. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-17 Multihost AVAILABLE Command 11 June 1992 1 Unit-Available (subcode "Already In Use") 2 The unit was "Unit-Available" to the issuing host and 3 "Exclusive Access" of the unit was denied because it is 4 currently "Unit-Online" to another host. 5 Unit-Offline 6 All subcodes may be returned. Note that "Unit-Offline 7 (subcode 'No Media Loaded')" implies "Success (subcode 8 'Normal')" when "Exclusive Access" of the unit was 9 granted while the unit was "Unit-Offline (substate 'No 10 Media Loaded')." Note also that in cases where the unit 11 was "Unit-Online" (and not under the "Exclusive Access" 12 of the issuing host) but had a duplicate unit number 13 prior to the AVAILABLE command being issued, the 14 controller may, at its option, return the "Unit-Offline 15 (subcode 'Duplicate Unit Number') status code or two 16 forms of the "Success" status code (see Success (subcode 17 "Normal") above). 18 Unit Offline (subcode "Exclusive Use") 19 The unit is currently under the "Exclusive Access" of 20 some other host connected via this controller. 21 Controller Error 22 Drive Error *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-18 Multihost AVAILABLE Command 11 June 1992 1 7.4.3 Description 2 The operation of the AVAILABLE command depends on the settings of 3 the "All Class Drivers," "Exclusive Access," and "Spin-down" 4 modifiers as well as the state of the specified unit relative to 5 the issuing host and all other "Controller-Online" hosts (class 6 drivers) as described in the preceding sections. All 7 combinations of those modifiers are permissible. 8 Note that issuing an AVAILABLE command with the "All Class 9 Drivers," "Exclusive Access," and "Spin-down" modifiers clear to 10 a unit that is already "Unit-Available" to and not under the 11 "Exclusive Access" of the issuing host is essentially a 12 sequential no-operation. 13 Upon completion of the requested AVAILABLE command operation(s) 14 an AVAILABLE attention message is sent by all controllers to 15 which the specified unit is connected under the following 16 conditions (provided the "Spin-down" modifier was clear): 17 1. The unit's state changes from "Unit-Online" to 18 "Unit-Available" relative to the the issuing host as 19 well as all other "Controller-Online" hosts and the 20 issuing host was not granted "Exclusive Access" of the 21 unit in the process. 22 2. The unit's state changes from "Unit-Online" to 23 "Unit-Available" relative to the issuing class driver 24 and "Exclusive Access" of the unit was also released. 25 3. The unit was already "Unit-Available" to the issuing 26 host and "Exclusive Access" of the unit was released. 27 In all the cases just described the controller to which the 28 AVAILABLE command was sent need not send an AVAILABLE attention 29 message. 30 If the "Spin-down" modifier was set, AVAILABLE attention messages 31 will be suppressed for the specified unit both for this 32 controller and for any other controllers to which the unit may be 33 connected, regardless of whether the spin-down was actually 34 initiated. See Section 4.3, "Unit States" for a discussion of 35 suppressing AVAILABLE attention messages. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-19 Multihost GET COMMAND STATUS Command 11 June 1992 1 7.5 Multihost GET COMMAND STATUS Command 2 Command Category: 3 Immediate 4 7.5.1 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 See Section 6.11.1, "GET COMMAND STATUS Command, Command 17 Message Format." 18 outstanding reference number 19 The "command reference number" of the command whose 20 status is to be obtained. 21 As described in Section 5.3, "Command Messages," "command 22 reference numbers" need not be unique for commands issued 23 by different class drivers -- i.e., commands issued by 24 different hosts or commands for different MSCP servers 25 from the same host. Controllers shall therefore use the 26 combination of the "outstanding reference number" and the 27 connection on which the GET COMMAND STATUS command was 28 received in order to uniquely identify commands issued by 29 different hosts. 30 Allowable modifiers: 31 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-20 Multihost GET COMMAND STATUS Command 11 June 1992 1 7.5.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | outstanding reference number | 11 +---------------+---------------+ 12 | command status | 13 +---------------+---------------+ 14 outstanding reference number 15 See Section 6.11.2, "GET COMMAND STATUS Command, End 16 Message Format." 17 command status 18 The amount of work remaining to be done to complete the 19 command, expressed as an unsigned integer. This field is 20 zero if the command is not known to the controller, such 21 as when the command has already completed or was aborted. 22 The controller may also return zero in this field if it 23 can guarantee that the command will complete within the 24 controller timeout interval. The controller shall never 25 return a value of all ones (2**32-1) in this field, as 26 that value is used to initialize the host's command 27 timeout algorithm (see Section 4.10, "Command Timeouts"). 28 Each "Controller-Online" class driver has a different 29 concept of which command is the oldest outstanding 30 command. As mentioned earlier the command for which 31 status is being obtained is uniquely qualified by the 32 "outstanding reference number" and the connection on 33 which the command GET COMMAND STATUS was received. 34 Controllers shall therefore return a status value that 35 reflects the "doneness" of the specified command relative 36 to the issuing host. 37 An example of how a controller might produce status 38 values that meet all the requirements defined in the 39 preceding paragraphs follows. Note that the algorithm 40 described in the example is driven solely by the host's 41 issuance of the GET COMMAND STATUS command, not an 42 internal controller timer. For the algorithm to function 43 properly the host must not issue a GET COMMAND STATUS *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-21 Multihost GET COMMAND STATUS Command 11 June 1992 1 command for a particular command more frequently than the 2 value returned by the controller in the "controller 3 timeout" field of the SET CONTROLLER CHARACTERISTICS 4 command's end message. 5 The controller maintains two distinctly different 6 command status values in the context of each command 7 received by the controller: 8 o Controller-Host Command Status (CHCS) 9 A 32-bit unsigned integer value which is 10 the actual "Command Status" value 11 returned to the host. The controller 12 initializes CHCS to a reasonable maximum 13 value (e.g., 2**32-2). 14 o Command-Specific Command Status (CSCS) 15 An unsigned integer value consisting of 16 two subfields: the Requested Command's 17 Position (RCP) and the Requested 18 Command's Status (RCS). RCP is the high 19 order field. (The size of the CSCS as 20 well as the RCP and RCS subfields is 21 controller dependent, as discussed 22 later.) The controller initializes the 23 CSCS to its maximum value (all bits set). 24 Upon receipt of a GET COMMAND STATUS command for a 25 particular command the controller constructs a 26 current copy of CSCS according to the requested 27 command's current execution state as follows: 28 o Unknown (e.g., no longer outstanding) 29 RCP and RCS are both set to zero. 30 o Already In-progress 31 RCP is set to zero, implying that the 32 requested command is at execution 33 position 0. 34 RCS is set to an encoding of the amount 35 of work (including possible retries, 36 etc.) remaining before the requested 37 command completes, or zero if the 38 controller expects the command to finish 39 within the "controller timeout" interval. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-22 Multihost GET COMMAND STATUS Command 11 June 1992 1 o Sequential Command Waiting For In-progress 2 Commands to Complete 3 RCP is set to one, implying that the 4 requested command will be the next 5 command initiated. 6 RCS is set to an encoding of the amount 7 of work remaining on all in-progress 8 commands. 9 o Non-Sequential Command Waiting For An 10 In-progress Sequential Command To Complete 11 RCP is set equal to the number of 12 commands which are scheduled for 13 initiation ahead of the requested 14 command, plus one to account for the 15 in-progress Sequential command. 16 RCS is set equal to the in-progress 17 Sequential command's RCS value. 18 o Sequential or Non-Sequential Command Waiting 19 For Other Reasons (e.g., a controller 20 resource to become available) 21 RCP is set equal to the number of 22 commands that are scheduled for 23 initiation ahead of the requested 24 command, plus one to account for the 25 requested command. 26 RCS is set to an encoding of the amount 27 of work remaining on all in-progress 28 commands. 29 The controller then tests the value of the 30 constructed CSCS. If the constructed CSCS is zero 31 due to the command being unknown, the controller 32 zeros the "command status" field of the GET COMMAND 33 STATUS command's end message, and completes the GET 34 COMMAND STATUS command. If the constructed CSCS is 35 zero and the command is known, the command's CHCS is 36 set equal to zero. If the constructed CSCS is 37 nonzero, the controller compares the constructed CSCS 38 to the command's CSCS stored previously. If the 39 constructed CSCS is less than the command's CSCS, the 40 controller decrements the command's CHCS by one. If 41 the constructed CSCS is greater than or equal to the *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-23 Multihost GET COMMAND STATUS Command 11 June 1992 1 command's CSCS, the controller leaves the command's 2 CHCS at the same value. Then the controller stores 3 the constructed CSCS in the requested command's 4 context, obtains the current value of the CHCS from 5 the requested command's context and stores it in the 6 "command status" field of the GET COMMAND STATUS 7 command's end message, and completes the GET COMMAND 8 STATUS command. 9 As mentioned above the size of CSCS is controller 10 dependent. CSCS size actually depends on the maximum 11 values of the RCP and RCS subfields the controller 12 can reasonably expect to encounter, determined as 13 follows: 14 o RCP 15 The maximum number of command messages 16 the controller is capable of queuing at 17 any one time. 18 o RCS 19 The maximum amount of time the longest 20 command execution (including error 21 recovery retries) can possibly consume, 22 expressed as the number of ticks starting 23 from the initiation of the longest 24 command execution through its completion. 25 A tick is the amount of time it takes to 26 complete the longest single operation of 27 all the individual operations which are 28 used to execute commands within the 29 controller. The "controller timeout" 30 interval is equal to one tick. 31 Status Codes: 32 Success (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-24 Multihost GET COMMAND STATUS Command 11 June 1992 1 7.5.3 Description 2 The GET COMMAND STATUS command is used to monitor the progress of 3 a command towards completion. The command status measures the 4 "doneness" of the command. The value returned in the command 5 status field is guaranteed to not increase over time. 6 Furthermore, the command status of an MSCP server's oldest 7 outstanding command relative to the issuing host is guaranteed to 8 decrease within the controller timeout interval. This last 9 feature may be used by a host class driver to detect an insane or 10 malfunctioning controller. See Section 4.10, "Command Timeouts," 11 for more details. 12 The GET COMMAND STATUS command always succeeds. If the command 13 referenced by the "outstanding reference number" is not known to 14 the MSCP server or has been aborted, then the MSCP server should 15 return zero for its command status. The MSCP server may also 16 return zero as the command status of any command that will always 17 complete within the controller timeout interval. The MSCP server 18 always returns the "Normal" status code in the GET COMMAND STATUS 19 command's end message. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-25 Multihost GET UNIT STATUS Command 11 June 1992 1 7.6 Multihost GET UNIT STATUS Command 2 Command Category: 3 Immediate 4 7.6.1 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 for disk class devices) 15 Next Unit 16 See Section 6.12.1, "GET UNIT STATUS Command, Command 17 Message Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-26 Multihost GET UNIT STATUS Command 11 June 1992 1 7.6.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | unit flags |multiunit code | 11 +---------------+---------------+ 12 | reserved |spndles| 13 +-------------------------------+ 14 | | 15 +--- unit identifier ---+ 16 | | 17 +-------------------------------+ 18 | media type identifier | 19 +-------------------------------+ 20 | reserved | 21 +-------------------------------+ 22 | group size | track size | 23 +-------+-------+---------------+ 24 |uhvrsn | usvrsn| cylinder size | 25 +-------+-------+---------------+ 26 |copies | RBNs | RCT size | 27 +-------+-------+---------------+ 28 status 29 The validity of the unit characteristics varies with the 30 unit's state implied by the contents of this field. See 31 the Status Codes listed later in this section and Section 32 6.12.3, "GET UNIT STATUS Command, Description" for 33 complete details. 34 multiunit code 35 unit identifier 36 media type identifier 37 track size 38 group size 39 cylinder size 40 usvrsn 41 uhvrsn 42 RCT size 43 RBNs 44 copies 45 See Section 6.12.2, "GET UNIT STATUS Command, End Message *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-27 Multihost GET UNIT STATUS Command 11 June 1992 1 Format." 2 unit flags 3 See Section 5.7, "Unit Flags." 4 Exclusive Access 5 The Exclusive Access unit flag is non-host-settable; 6 it is set when the unit is under the "Exclusive 7 Access" of this or some other host via this 8 controller and clear when it is not. 9 spndles 10 The number minus one of spindles or spindle "groups" in 11 the unit. The value of zero indicates one spindle. See 12 Section 4.12, "Disk Geometry and Format." 13 Status Codes: 14 Unit-Offline 15 All subcodes may be returned. Note that "Unit-Offline 16 (subcode 'Exclusive Use')" indicates that the unit is 17 under the "Exclusive Access" of some other host connected 18 via this controller. All characteristic fields and unit 19 flags are valid when that status is returned. 20 Success (subcode "Normal") 21 Success (subcode "Duplicate Unit Number") 22 Unit-Available 23 Controller Error 24 Drive Error 25 See Section 6.12.2, "GET UNIT STATUS Command, End Message 26 Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-28 Multihost GET UNIT STATUS Command 11 June 1992 1 7.6.3 Description 2 See Section 6.12.3, "GET UNIT STATUS Command, Description." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-29 Multihost ONLINE Command 11 June 1992 1 7.7 Multihost ONLINE Command 2 Command categories: 3 Sequential 4 7.7.1 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 | reserved | 24 +-------------------------------+ 25 | unit flags 26 Host-settable unit flags. See Section 5.7, "Unit 27 Flags." 28 If the unit is already "Unit-Online" to any host (class 29 driver), then the class driver shall specify the same 30 values for controller supported host-settable unit flags 31 as are currently in effect on the unit. The controller 32 shall check that the flag values are the same. If they 33 are different then it shall reject the command as an 34 "Invalid Command" ("invalid unit flags" parameter error. 35 See "Invalid Command" status in Section 5.5, "Status 36 Codes"). 37 device dependent parameters 38 See Section 6.13.1, "ONLINE Command, Command Message 39 Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-30 Multihost ONLINE Command 11 June 1992 1 Note that controllers may either maintain the "device 2 dependent parameters" separately for each 3 "Controller-Online" class driver or singularly for all 4 "Controller-Online" class drivers, at their option. In 5 the latter case the value expressed in this field by the 6 host that issued the most recent ONLINE or SET UNIT 7 CHARACTERISTICS command dictates which device dependent 8 parameters are in effect. 9 Allowable modifiers: 10 Allow Self Destruction 11 Clear Serious Exception (ignored for disk class devices) 12 Ignore Media Format Error 13 See Section 6.13.1, "ONLINE Command, Command Message 14 Format." 15 The server may, at its option, reject the command as an 16 Invalid Command (subcode "Invalid Modifiers") if the unit 17 is already "Unit-Online" to another host. 18 Enable Set Write Protect 19 See "unit flags" field description above and Section 20 6.13.1, "ONLINE Command, Command Message Format." 21 Exclusive Access 22 If the "Exclusive Access" modifier is set and the unit is 23 "Unit-Available" to the issuing host and is not 24 "Unit-Online" to nor under the "Exclusive Access" of any 25 other host, the unit becomes "Unit-Online" to and under 26 the "Exclusive Access" of the issuing host. 27 If the "Exclusive Access" modifier is set and the unit is 28 "Unit-Available" to and under the "Exclusive Access" of 29 the issuing host, the unit becomes "Unit-Online" to the 30 issuing host. "Exclusive Access" of the unit is 31 retained. 32 If the "Exclusive Access" modifier is set and the unit is 33 already "Unit-Online" to and not under the "Exclusive 34 Access" of the issuing host and is not "Unit-Online" to 35 any other host, the issuing host is granted "Exclusive 36 Access" of the unit. The unit's state relative to the 37 issuing host is otherwise unchanged. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-31 Multihost ONLINE Command 11 June 1992 1 If the "Exclusive Access" modifier is set and the unit is 2 "Unit-Online" to and under the "Exclusive Access" of the 3 issuing host, the issuing host retains "Exclusive Access" 4 of the unit. The unit's state relative to the issuing 5 host is otherwise unchanged. 6 If the "Exclusive Access" modifier is clear and the unit 7 is "Unit-Available" to and under the "Exclusive Access" 8 of the issuing host, the unit becomes "Unit-Online" to 9 the issuing host and "Exclusive Access" of the unit is 10 released. 11 If the "Exclusive Access" modifier is clear and the unit 12 is "Unit-Online" to and under the "Exclusive Access" of 13 the issuing host, "Exclusive Access" of the unit is 14 released. The unit's state relative to the issuing host 15 is otherwise unchanged. 16 If the unit is "Unit-Offline" to the issuing host the 17 setting of the "Exclusive Access" modifier is ignored. 18 Note that granting "Exclusive Access" of a unit to a host 19 implicitly causes the unit to become "Unit-Offline 20 (substate 'Exclusive Use')" to all other hosts connected 21 via this controller and "Unit-Offline (substate 'Online 22 To Another Controller')" to hosts that may potentially 23 have access to the unit via another controller. 24 Conversely, the release of a unit from the "Exclusive 25 Access" of a host implicitly causes the unit to become 26 "Unit-Available" to all other hosts. 27 | Note also that "Exclusive Access" is released if any of 28 | the following events occur: 29 | 1. The controller loses or breaks the connection to 30 | the host that has "Exclusive Access" of the 31 | drive. 32 | 2. The drive becomes unknown to the controller 33 | (e.g., port button disabled.) 34 | 3. The drive becomes inoperative, "Unit-Offline, 35 | Inoperative." 36 | 4. The controller is 'rebooted', by itself, by an 37 | operator, or by any host. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-32 Multihost ONLINE Command 11 June 1992 1 7.7.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | unit flags |multiunit code | 11 +---------------+---------------+ 12 | reserved |spndles| 13 +-------------------------------+ 14 | | 15 +--- unit identifier ---+ 16 | | 17 +-------------------------------+ 18 | media type identifier | 19 +-------------------------------+ 20 | reserved | 21 +-------------------------------+ 22 | unit size | 23 +-------------------------------+ 24 | volume serial number | 25 +-------------------------------+ 26 | status 27 The validity of the unit characteristics varies with the 28 unit's state implied by the contents of this field. See 29 Status Codes listed below and Section 6.17.3, "SET UNIT 30 CHARACTERISTICS Command, Description" for complete 31 details. 32 unit flags 33 See Section 5.7, "Unit Flags." 34 Exclusive Access 35 The Exclusive Access unit flag is non-host-settable; 36 it is set when the unit is under the "Exclusive 37 Access" of this or some other host via this 38 controller and clear when it is not. 39 All other fields of the ONLINE command's end message are 40 identical to the SET UNIT CHARACTERISTICS command's end 41 message. Refer to Section 7.9.2, "Multihost SET UNIT 42 CHARACTERISTICS Command, End Message Format" for a *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-33 Multihost ONLINE Command 11 June 1992 1 description of the fields. 2 Status Codes: 3 Success (subcode "Normal") 4 The unit has become "Unit-Online" to the issuing host. 5 The unit may have already been "Unit-Online" to one or 6 more other hosts and, for those unit flags that are both 7 host-settable and supported by the controller, the class 8 driver specified values identical to those currently in 9 effect on the unit. 10 As described earlier (see "Exclusive Access" modifier in 11 the preceding section), "Exclusive Access" of the unit by 12 the issuing host may have been granted, retained, or 13 released depending on the setting of the "Exclusive 14 Access" modifier and whether or not the unit was already 15 under the "Exclusive Access" of the issuing host. 16 The unit's state relative to all other hosts remains 17 unchanged unless "Exclusive Access" of the unit was 18 granted or released. See "Exclusive Access" modifier in 19 the preceding section. 20 Success (subcode "Already Online") 21 The "Already Online" subcode bit flag is set only if the 22 unit was already "Unit-Online" to the issuing host and, 23 for those unit flags that are both host-settable and 24 supported by the controller, the class driver specified 25 values identical to those currently in effect on the 26 unit. The unit remains "Unit-Online" to the issuing 27 host. 28 As described earlier (see "Exclusive Access" modifier in 29 the preceding section) "Exclusive Access" of the unit by 30 the issuing host may have been granted, retained, or 31 released depending on the setting of the "Exclusive 32 Access" modifier and whether or not the unit was already 33 under the "Exclusive Access" of the issuing host. 34 The unit's state relative to all other hosts remains 35 unchanged, unless "Exclusive Access" of the unit was 36 granted or released. See "Exclusive Access" modifier in 37 the preceding section. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-34 Multihost ONLINE Command 11 June 1992 1 Invalid Command (subcode "Invalid Unit Flags") 2 The unit was already "Unit-Online" to one or more hosts 3 and, for those unit flags that are both host-settable and 4 supported by the controller, the class driver specified 5 different values from those currently in effect on the 6 unit. The unit state relative to the issuing host 7 remains unchanged. The host-settable unit flags are not 8 changed, and the end message returns their current 9 settings. 10 As described earlier (see "Exclusive Access" modifier in 11 the preceding section) "Exclusive Access" of the unit by 12 the issuing host may have been denied, granted, retained, 13 or released depending on the setting of the "Exclusive 14 Access" modifier, whether or not the unit was already 15 under the "Exclusive Access" of the issuing host, and the 16 state of the unit relative to all other hosts. Note that 17 controllers shall service the "Exclusive Access" modifier 18 before checking for equality of the host-settable unit 19 flags. 20 The unit's state relative to all other hosts remains 21 unchanged, unless "Exclusive Access" of the unit was 22 granted or released. See "Exclusive Access" modifier in 23 the preceding section. 24 Unit-Offline 25 All subcodes may be returned. Note that "Unit-Offline 26 (subcode 'Exclusive Use')" status indicates that the unit 27 is under the "Exclusive Access" of another host via this 28 controller. All characteristic fields and unit flags are 29 valid when that status is returned. Also note that some 30 causes of a unit being "Unit-Offline" may be overridden 31 (suppressed) by the "Allow Self Destruction" command 32 modifier. 33 Unit-Available (subcode "Already In Use") 34 The unit was "Unit-Available" to the the issuing host and 35 "Exclusive Access" of the unit was denied because it is 36 currently "Unit-Online" to another host via this 37 controller. All characteristic fields and unit flags are 38 valid. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-35 Multihost ONLINE Command 11 June 1992 1 Command Aborted 2 Media Format Error 3 Controller Error 4 Drive Error 5 See Section 6.13.2, "ONLINE Command, End Message 6 Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-36 Multihost ONLINE Command 11 June 1992 1 7.7.3 Description 2 The ONLINE command is used to bring a unit "Unit-Online," set 3 host-settable unit characteristics, and obtain those unit 4 characteristics that are essential for proper class driver 5 operation (see Section 5.7, "Unit Flags" for additional 6 information). The unit is spun-up, if necessary, and its heads 7 are loaded prior to returning the ONLINE command's end message. 8 Host-settable characteristics are set exactly as if a SET UNIT 9 CHARACTERISTICS command were issued (see Section 7.9.2, 10 "Multihost SET UNIT CHARACTERISTICS Command"). Host-settable 11 characteristics are set after the unit has been successfully 12 spun-up and any other validity checks have succeeded. 13 In addition, "Exclusive Access" of the unit by the issuing host 14 may have been denied, granted, retained, or released depending on 15 the setting of the "Exclusive Access" modifier, whether or not 16 the unit was already under the "Exclusive Access" of the issuing 17 host, and the state of the unit relative to all other hosts. See 18 "Exclusive Access" modifier description above. 19 Note that if the unit is already "Unit-Online" to the issuing 20 host or any other host(s), the unit's host-settable 21 characteristics and state relative to the issuing host as well as 22 all other hosts are not altered. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-37 Multihost SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 7.8 Multihost SET CONTROLLER CHARACTERISTICS Command 2 Command Category: 3 Immediate 4 7.8.1 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 | crn | (optional) 24 +---------------+ 25 MSCP version 26 See Section 6.16.1, "SET CONTROLLER CHARACTERISTICS 27 Command, Command Message Format." 28 cntrlr. flags 29 Host-settable controller flags. See Section 5.6, 30 "Controller Flags." 31 Note that controllers maintain a separate set of 32 host-settable "controller flags" for each 33 "Controller-Online" class driver. 34 host timeout 35 See Section 6.16.1, "SET CONTROLLER CHARACTERISTICS 36 Command, Command Message Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-38 Multihost SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 Note that controllers maintain a separate "host timeout" 2 for each "Controller-Online" class driver. 3 quad-word time and date 4 See Section 6.16.1, "SET CONTROLLER CHARACTERISTICS 5 Command, Command Message Format." 6 Note that controllers maintain a single "quad-word time 7 and date" for all "Controller-Online" class drivers. 8 controller dependent parameters 9 See Section 6.16.1, "SET CONTROLLER CHARACTERISTICS 10 Command, Command Message Format." 11 Note that controllers may either maintain the "controller 12 dependent parameters" separately for each 13 "Controller-Online" class driver or singularly for all 14 "Controller-Online" class drivers, at their option. 15 crn (connection reference number) 16 See Section 6.16.1, "SET CONTROLLER CHARACTERISTICS 17 Command, Command Message Format." 18 Allowable modifiers: 19 none *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-39 Multihost SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 7.8.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| rsvd | alloc | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | cntrlr. flags | MSCP version | 11 +-------+-------+---------------+ 12 |chvrsn | csvrsn|cntrlr. timeout| 13 +-------+-------+---------------+ 14 | | 15 +--- controller identifier ---+ 16 | | 17 +-------------------------------+ 18 | maximum byte count (optional) | 19 +-------------------------------+ 20 alloc 21 Allocation Class. Zero, unless manually altered in a 22 controller implementation dependent manner. Multihost 23 controllers shall provide an external method for setting 24 this field (via DUP commands is sufficient). When a new 25 allocation class value takes effect, all connections 26 shall be broken to allow hosts to recognize the new value 27 upon reconnection. Allocation class shall be preserved 28 in nonvolatile controller memory to allow correct 29 operation across power failure. 30 cntrlr. flags 31 See Section 5.6, "Controller Flags." 32 For those controller options that a controller supports 33 the corresponding non-host-settable flag and those 34 host-settable flags that are currently in effect for the 35 issuing host will be returned set. Note that controllers 36 shall set the "Multihost Support" flag. 37 cntrlr. timeout 38 See Section 6.16.2, "SET CONTROLLER CHARACTERISTICS 39 Command, End Message Format," Section 4.10, "Command 40 Timeouts," and Section 7.5, "Multihost GET COMMAND STATUS 41 Command." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-40 Multihost SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 csvrsn 2 chvrsn 3 controller identifier 4 maximum byte count (optional) 5 See Section 6.16.2, "SET CONTROLLER CHARACTERISTICS 6 Command, End Message Format." 7 Status Codes: 8 Success (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-41 Multihost SET CONTROLLER CHARACTERISTICS Command 11 June 1992 1 7.8.3 Description 2 See Section 6.16.3, "SET CONTROLLER CHARACTERISTICS Command, 3 Description." 4 For those host-settable controller characteristics that are 5 maintained separately, controllers shall operate according to the 6 value(s) specified by each individual "Controller-Online" class 7 driver. The operational characteristics requested by one 8 "Controller-Online" class driver shall not interfere with or 9 modify in any manner those requested by another. Each 10 "Controller-Online" class driver is expressly permitted to 11 specify different operational characteristics and as a result 12 realize different controller operation. 13 For those host-settable characteristics that are maintained 14 singularly, controllers shall operate according to the value(s) 15 specified by the host that issued the most recent SET CONTROLLER 16 CHARACTERISTICS command. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-42 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 7.9 Multihost SET UNIT CHARACTERISTICS Command 2 Command Category: 3 Sequential 4 7.9.1 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 | reserved | 24 +-------------------------------+ 25 unit flags 26 Host-settable unit flags. See Section 5.7, "Unit 27 Flags." 28 Note that controllers maintain a single set of 29 host-settable unit flags for all "Controller-Online" 30 class drivers. 31 device dependent parameters 32 See Section 6.17.1, "SET UNIT CHARACTERISTICS Command, 33 Command Message Format." 34 Note that controllers may either maintain the "device 35 dependent parameters" separately for each 36 "Controller-Online" class driver or singularly for all 37 "Controller-Online" class drivers, at their option. In 38 the latter case the value expressed in this field by the 39 host that issued the most recent ONLINE or SET UNIT 40 CHARACTERISTICS command dictates which device dependent *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-43 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 parameters are in effect. 2 Allowable modifiers: 3 Clear Serious Exception (ignored for disk class devices) 4 Enable Set Write Protect 5 See Section 6.17.1, "SET UNIT CHARACTERISTICS Command, 6 Command Message Format." 7 Exclusive Access 8 If the "Exclusive Access" modifier is set and the unit is 9 "Unit-Available" to the issuing host and is not 10 "Unit-Online" to any other host, "Exclusive Access" of 11 the unit is granted to the issuing host. 12 If the "Exclusive Access" modifier is set and the unit is 13 "Unit-Available" to and under the "Exclusive Access" of 14 the issuing host, "Exclusive Access" of the unit is 15 retained. 16 If the "Exclusive Access" modifier is set and the unit is 17 "Unit-Online" to and not under the "Exclusive Access" of 18 the issuing host and is not "Unit-Online" to any other 19 host, the issuing host is granted "Exclusive Access" of 20 the unit. 21 If the "Exclusive Access" modifier is set and the unit is 22 "Unit-Online" to and under the "Exclusive Access" of the 23 issuing host, the issuing host retains "Exclusive Access" 24 of the unit. 25 If the "Exclusive Access" modifier is clear and the unit 26 is "Unit-Available" to and under the "Exclusive Access" 27 of the issuing host, "Exclusive Access" of the unit is 28 released. 29 If the "Exclusive Access" modifier is clear and the unit 30 is "Unit-Online" to and under the "Exclusive Access" of 31 the issuing host, "Exclusive Access" of the unit is 32 released. 33 If the unit is "Unit-Offline" to the issuing host the 34 setting of the "Exclusive Access" modifier is ignored. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-44 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 In all the cases just listed the unit's state relative to 2 the issuing host remains unchanged. 3 Note that granting "Exclusive Access" of a unit to a host 4 implicitly causes the unit to become "Unit-Offline 5 (substate 'Exclusive Use')" to all other hosts connected 6 via this controller and "Unit-Offline (substate 'Online 7 To Another Controller')" to hosts which may potentially 8 have access to the unit via another controller. 9 Conversely, the release of a unit from the "Exclusive 10 Access" of a host implicitly causes the unit to become 11 "Unit-Available" to all other hosts. 12 | Note also that "Exclusive Access" is released if any of 13 | the following events occur: 14 | 1. The controller loses or breaks the connection to 15 | the host that has "Exclusive Access" of the 16 | drive. 17 | 2. The drive becomes unknown to the controller 18 | (e.g., port button disabled.) 19 | 3. The drive becomes inoperative, "Unit-Offline, 20 | Inoperative." 21 | 4. The controller is 'rebooted', by itself, by an 22 | operator, or by any host. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-45 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 7.9.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| unit number | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | unit flags |multiunit code | 11 +---------------+---------------+ 12 | reserved |spndles| 13 +-------------------------------+ 14 | | 15 +--- unit identifier ---+ 16 | | 17 +-------------------------------+ 18 | media type identifier | 19 +-------------------------------+ 20 | reserved | 21 +-------------------------------+ 22 | unit size | 23 +-------------------------------+ 24 | volume serial number | 25 +-------------------------------+ 26 | status 27 The validity of the unit characteristics varies with the 28 unit's state implied by the contents of this field. See 29 Status Codes listed later in this section and Section 30 6.17.3, "SET UNIT CHARACTERISTICS Command, Description" 31 for complete details. 32 unit flags 33 See Section 5.7, "Unit Flags." 34 Exclusive Access 35 The Exclusive Access unit flag is non-host-settable; 36 it is set when the unit is under the "Exclusive 37 Access" of this or some other host via this 38 controller and clear when it is not. 39 spndles 40 The number minus one of spindles or spindle "groups" in 41 the unit. The value of zero indicates one spindle. See *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-46 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 Section 4.12, "Disk Geometry and Format." 2 multiunit code 3 unit identifier 4 media type identifier 5 unit size 6 volume serial number 7 See Section 6.17.2, "SET UNIT CHARACTERISTICS Command, 8 End Message Format." 9 Status Codes: 10 Success (subcode "Normal") 11 Success (subcode "Duplicate Unit Number") 12 The unit is "Unit-Online" to the issuing host. The unit 13 may also be "Unit-Online" to one or more other hosts. 14 The unit will operate according to the setting of those 15 unit flags that are both host-settable and supported by 16 the controller, as specified by the issuing class driver, 17 for all hosts to which the unit is "Unit-Online." 18 As described earlier (see "Exclusive Access" modifier in 19 the preceding section) "Exclusive Access" of the unit by 20 the issuing host may have been granted, retained, or 21 released depending on the setting of the "Exclusive 22 Access" modifier and whether or not the unit was already 23 under the "Exclusive Access" of the issuing host. 24 The unit's state relative to all other hosts remains 25 unchanged, unless "Exclusive Access" of the unit was 26 granted or released. See "Exclusive Access" modifier in 27 the preceding section. 28 Unit-Offline 29 All subcodes may be returned. Note that "Unit-Offline 30 (subcode 'Exclusive Use')" status indicates that the unit 31 is under the "Exclusive Access" of some other host via 32 this controller. All characteristic fields and unit 33 flags are valid when that status is returned. 34 Unit-Available (subcode "Available") 35 This status code implies "Success (subcode 'Normal')" 36 when "Exclusive Access" of the unit was granted while the 37 unit was "Unit-Available." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-47 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 Unit-Available (subcode "Already In Use") 2 The unit was "Unit-Online" or "Unit-Available" to the the 3 issuing host and "Exclusive Access" of the unit was 4 denied because it is currently "Unit-Online" to another 5 host via this controller. All characteristic fields and 6 unit flags are valid. 7 Command Aborted 8 Controller Error 9 Drive Error 10 See Section 6.17.2, "SET UNIT CHARACTERISTICS Command, 11 End Message Format." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-48 Multihost SET UNIT CHARACTERISTICS Command 11 June 1992 1 7.9.3 Description 2 The SET UNIT CHARACTERISTICS command is used to set host-settable 3 unit characteristics and obtain those unit characteristics that 4 are essential for proper class driver operation. The setting of 5 the host-settable unit flags is effective only when the unit is 6 "Unit-Online" to the issuing host and affects all hosts to which 7 the unit is "Unit-Online." 8 In addition, "Exclusive Access" of the unit by the issuing host 9 may have been denied, granted, retained, or released depending on 10 the setting of the "Exclusive Access" modifier, whether the unit 11 was already under the "Exclusive Access" of the issuing host, and 12 the state of the unit relative to all other hosts. See 13 "Exclusive Access" modifier description above. 14 Note that the format of the SET UNIT CHARACTERISTICS command's 15 end message is identical to that of the ONLINE command's end 16 message because the ONLINE command performs a SET UNIT 17 CHARACTERISTICS operation after bringing a unit "Unit-Online." *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-49 Multihost TERMINATE CLASS DRIVER/SERVER CONNECTI ... 11 June 1992 1 7.10 Multihost TERMINATE CLASS DRIVER/SERVER CONNECTION Command 2 Command Category: 3 Immediate 4 7.10.1 Command Message Format 5 31 0 6 +-------------------------------+ 7 | command reference number | 8 +---------------+---------------+ 9 | reserved | 10 +---------------+-------+-------+ 11 | modifiers | rsvd | opcode| 12 +---------------+-------+-------+ 13 | | 14 +--- ---+ 15 | | 16 +--- ---+ 17 | reserved | 18 +--- ---+ 19 | | 20 +--- ---+ 21 | | 22 +---------------+---------------+ 23 | crn | 24 +---------------+ 25 crn (connection reference number) 26 The identification of the host whose class driver/server 27 connection is to be terminated. 28 Note that host class drivers associate a "connection 29 reference number" with the "Controller-Online" connection 30 they establish with the server via the SET CONTROLLER 31 CHARACTERISTICS command as described in Section 6.16.1, 32 "SET CONTROLLER CHARACTERISTICS Command, Command Message 33 Format." 34 If the value supplied in this field is zero, the server 35 rejects the command as an "Invalid Command" ("invalid 36 crn" parameter error. See Section 5.5, "Status Codes" 37 for complete details. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-50 Multihost TERMINATE CLASS DRIVER/SERVER CONNECTI ... 11 June 1992 1 Allowable modifiers: 2 None *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-51 Multihost TERMINATE CLASS DRIVER/SERVER CONNECTI ... 11 June 1992 1 7.10.2 End Message Format 2 31 0 3 +-------------------------------+ 4 | command reference number | 5 +---------------+---------------+ 6 |sequence number| reserved | 7 +---------------+-------+-------+ 8 | status | flags |endcode| 9 +---------------+-------+-------+ 10 | | 11 +--- ---+ 12 | | 13 +--- ---+ 14 | undefined | 15 +--- ---+ 16 | | 17 +--- ---+ 18 | | 19 +---------------+---------------+ 20 | crn | 21 +---------------+ 22 crn (connection reference number) 23 Zero or the value supplied in the command message "crn 24 (connection reference number)" field. 25 If this field is zero, the server was unable to find a 26 class driver/server connection associated with the host 27 specified in the command message "crn (connection 28 reference number)" field. 29 If this field is nonzero, the server found a class 30 driver/server connection associated with the host 31 specified in the command message "crn (connection 32 reference number)" field and performed the operations 33 necessary to terminate it. 34 Status Codes: 35 Success (subcode "Normal") *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 MULTIHOST SUPPORT Page 7-52 Multihost TERMINATE CLASS DRIVER/SERVER CONNECTI ... 11 June 1992 1 7.10.3 Description 2 Support of the TERMINATE CLASS DRIVER/SERVER CONNECTION command 3 is a Disk MSCP server implementation dependent option. Disk MSCP 4 servers that do not provide such support shall reject this 5 command as an "Invalid Command" ("invalid opcode" protocol error. 6 See "Invalid Command" status in Section 5.5, "Status Codes"). 7 Tape MSCP servers shall not implement this command. 8 Servers that support "write history logging" as described in 9 Section 6.19.3, "WRITE HISTORY MANAGEMENT Command, Description" 10 shall also support the TERMINATE CLASS DRIVER/SERVER CONNECTION 11 command. Note that servers that support "write history logging" 12 but do not provide Multihost Support shall treat the TERMINATE 13 CLASS DRIVER/SERVER CONNECTION command as a no-operation as 14 described in Section 6.1.1, "No-Operation Commands." 15 "Write history logging" and the TERMINATE CLASS DRIVER/SERVER 16 CONNECTION command were defined primarily for the purpose of 17 assisting in the operation of host based volume shadowing 18 implementations. All servers that support "write history 19 logging" (and therefore the TERMINATE CLASS DRIVER/SERVER 20 CONNECTION command) shall set the Write History Logging Support 21 controller flag. A server that does not support "write history 22 logging" may, at its option, support the TERMINATE CLASS 23 DRIVER/SERVER CONNECTION command. 24 If supported and the server also provides Multihost Support, this 25 command permits a host class driver to terminate the class 26 driver/server connection a host has established with the server 27 receiving this command. 28 After performing the operations necessary to terminate the 29 connection between itself and the class driver located in the 30 specified host system the server enters the 31 "Controller-Available" state relative to that class driver. See 32 Section 4.1, "Controller States," for information regarding the 33 processing of new and outstanding commands received when a class 34 driver/server connection is terminated. Note that the server 35 shall "notice" connection terminations resulting from the 36 execution of this command prior to returning this command's end 37 message. 38 Note that in cases where multiple class drivers located in the 39 specified host system have established separate connections with 40 the server receiving this command and each of those connections 41 is associated with the same "connection reference number," the 42 server shall terminate all connections so established. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-1 11 June 1992 1 CHAPTER 8 2 CONTROLLER INITIATED BAD BLOCK REPLACEMENT 3 8.1 Controller Initiated Bad Block Replacement Overview 4 Controller Initiated Bad Block Replacement is an MSCP option that 5 relieves host class drivers from the task of performing bad block 6 replacement on disk drives. 7 In a disk MSCP server that does not provide Controller Initiated 8 Bad Block Replacement the server reports bad blocks to the class 9 driver, and the class driver and/or an auxiliary process 10 associated with it actually replaces the bad block. With 11 Controller Initiated Bad Block Replacement, the disk MSCP server 12 replaces bad blocks itself, transparent to the class driver. 13 This requires that the server also take over maintenance of the 14 Replacement Control Table (RCT), which contains replacement 15 context information. 16 Note that a controller may implement Controller Initiated Bad 17 Block Replacement on some or all of the disk types that may be 18 connected to it, at its option. In addition, Controller 19 Initiated Bad Block Replacement does not apply to Tape Mass 20 Storage Control Protocol, as bad block replacement is not used on 21 tape class devices. 22 Conceptually, Controller Initiated Bad Block Replacement is 23 implemented by inserting a Bad Block Replacement layer between a 24 Gatekeeper layer and the Disk MSCP layer, as shown in Figure 8-1 25 below. The Gatekeeper layer ensures that Sequential, 26 Non-Sequential, and Immediate commands behave as described. It 27 recognizes when a Sequential command has begun execution, and 28 defers all Non-Sequential commands on that unit until the 29 Sequential command completes. The Bad Block Replacement layer 30 performs bad block replacement and RCT maintenance by issuing 31 MSCP commands to the Disk MSCP layer. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-2 Controller Initiated Bad Block Replacement Overview 11 June 1992 1 Class Driver 2 A 3 | 4 V 5 / +----------------------------------+ 6 / | Gatekeeper | 7 / +----------------------------------+ 8 MSCP server | Bad Block Replacement | 9 \ +----------------------------------+ 10 \ | Disk MSCP | 11 \ +----------------------------------+ 12 Figure 8-1: Controller Initiated Bad Block Replacement 13 Layers 14 The remainder of this chapter describes the algorithms used by 15 the Bad Block Replacement layer, the concepts that Controller 16 Initiated Bad Block Replacement adds to standard Disk MSCP, the 17 changes to MSCP control message formats (described in Chapter 6, 18 "Minimal MSCP Command Set" and, if the controller provides 19 Multihost Support, Chapter 7, "Multihost Support"). Actual 20 implementations of Controller Initiated Bad Block Replacement 21 need not be a distinct layer or use exactly the algorithms given 22 here, so long as all class driver visible results are identical. 23 8.2 Data Safety Write Protection 24 As described in Section 4.14, "Write Protection," MSCP has three 25 forms of write protection: Hardware Write Protection, Software 26 Write Protection, and Data Safety Write Protection. Data Safety 27 Write Protection shall be put into effect whenever the Bad Block 28 Replacement layer detects that the volume has an inconsistent 29 Replacement Control Table (RCT) or a replacement has failed on 30 the volume. 31 When a unit is brought "Unit-Online," the Bad Block Replacement 32 layer examines block 0 of the RCT to see if the volume must be 33 Data Safety Write Protected. If so, the layer write protects the 34 unit and disables all bad block replacement attempts. The layer 35 provides read-only access to the unit on a "best efforts" basis, 36 so that a host can copy the volume's data to a backup device. 37 If a volume has an incomplete replacement attempt, and its unit 38 is Hardware Write Protected when it is brought "Unit-Online," the 39 Bad Block Replacement layer cannot complete the replacement 40 attempt. As an incomplete replacement attempt is one form of an 41 inconsistent RCT, the unit is Data Safety Write Protected when it 42 is brought "Unit-Online." If the unit subsequently ceases to be *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-3 Data Safety Write Protection 11 June 1992 1 Hardware Write Protected, the layer shall attempt to complete the 2 incomplete replacement. If this succeeds, Data Safety Write 3 Protection may be cleared for the unit. 4 The only way to clear Data Safety Write Protection due to an 5 invalid RCT is to reformat the volume. 6 8.3 Bad Block Replacement 7 With Controller Initiated Bad Block Replacement, the MSCP server 8 performs all bad block replacement. At a minimum, the MSCP 9 server replaces the first bad block encountered by each transfer 10 command. That is, the MSCP server shall replace all bad blocks 11 that would have been reported in any end message's "first bad 12 block" field by an MSCP server that does not provide Controller 13 Initiated Bad Block Replacement. Replacement of any additional 14 bad blocks encountered by a transfer is strongly recommended, but 15 not required. 16 Bad blocks can be detected by both read and write operations. 17 For read operations, the success or failure of the read cannot be 18 changed by retrying the read after performing the replacement. 19 However, with writes it is definitely possible (indeed, probable) 20 that a write that fails before the replacement will succeed after 21 the replacement. Consider that most bad blocks detected on write 22 operations will be due to invalid headers -- defects in the 23 header area of a sector. A write to such a block will fail 24 before the replacement, but succeed afterwards. 25 For this reason, if a write operation fails on a bad block, the 26 Bad Block Replacement layer shall retry the write operation after 27 replacing the block. This implies that the replacement operation 28 must be performed before such a write command completes (i.e., 29 before the end message is returned). In all other cases, 30 however, the replacement operation may be asynchronous with 31 respect to completion of the command that detected the bad block. 32 That is, since the replacement cannot affect the success or 33 failure of the command, the replacement may be performed either 34 before or after the command completes. 35 In addition to detecting bad blocks in transfers issued by hosts 36 or higher layers in the MSCP server, the Bad Block Replacement 37 layer may also check for bad blocks spontaneously, without 38 receiving any actual commands. In effect, whenever a unit is 39 "Unit-Online," the Bad Block Replacement layer may periodically 40 generate reads to the unit. Any bad blocks detected by such 41 internally generated transfers should be replaced, exactly the 42 same as if the read were externally generated. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-4 Bad Block Replacement 11 June 1992 1 Bad block replacement cannot be performed when the unit is 2 Hardware Write Protected. If a bad block is detected on a 3 Hardware Write Protected unit, replacement is not attempted. If 4 the unit becomes Hardware Write Protected after the bad block is 5 detected, but before the replacement is completed, some phase of 6 the bad block replacement algorithm will fail with a "Write 7 Protect" error. This error is handled the same as any other 8 failure of the bad block replacement algorithm; see the 9 discussion below. 10 When both Disk MSCP and Controller Initiated Bad Block 11 Replacement are implemented in the same controller, it is 12 strongly recommended that the controller defer recognition of 13 Hardware Write Protection until all pending replacement 14 operations have completed. That is, when an operator actuates 15 the unit's write protect mechanism, the controller does not 16 physically write protect the unit until after all previously 17 detected bad blocks have been replaced. This is similar to the 18 requirement in standard Disk MSCP of providing a smooth 19 transition to the write protected state (see Section 4.14, "Write 20 Protection"). 21 Bad block replacement shall be performed regardless of the 22 Software Write Protect status of the unit. If a bad block is 23 detected when the unit is Software Write Protected, the Bad Block 24 Replacement layer shall write enable the unit, perform the 25 replacement, then re-write protect the unit. The layer shall 26 guarantee that all host or higher layer write commands are still 27 rejected in spite of the unit being temporarily write enabled. 28 Bad block replacement shall not be attempted when the unit is 29 Data Safety Write Protected or when the unit was brought 30 "Unit-Online" with the "Ignore Media Format Error" modifier. 31 If the unit is Hardware Write Protected when it is brought 32 "Unit-Online" and it subsequently ceases to be Hardware Write 33 Protected, the Bad Block Replacement layer shall perform certain 34 actions before it attempts a replacement or modifies the volume 35 in any other way. These actions are to read and rewrite 36 Replacement Control Table (RCT) block 0 and to attempt to 37 complete any incomplete replacement operation. See Section 8.10, 38 "Actions Before First Modification." 39 If a bad block replacement fails for any reason, the Bad Block 40 Replacement layer handles the failure as follows: 41 1. The status code returned for the command that detected 42 the bad block is not affected by the failed replacement 43 attempt. That is, the status code appropriate for the 44 original access is returned. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-5 Bad Block Replacement 11 June 1992 1 2. The replacement failure is reported with a "Bad Block 2 Replacement Attempt" error log message (see Section 3 5.9.8). 4 Many of the errors that cause replacement failure are 5 themselves reported with error log messages. For 6 example, failure of a multiread or multiwrite access to 7 the RCT produces at least two error log messages: a 8 (usually) "Disk Transfer Error" message reporting the 9 access failure and a separate "Bad Block Replacement 10 Attempt" message reporting the replacement failure. All 11 such error log messages that report the cause of a 12 replacement failure should have the "Error During 13 Replacement" error log flag set and should be sent 14 before the "Bad Block Replacement Attempt" error log 15 message. 16 3. The Bad Block Replacement layer forces the unit to 17 become "Unit-Available" (or "Unit-Offline") with respect 18 to all class drivers, exactly as if an AVAILABLE command 19 with the "All Class Drivers" modifier had been issued. 20 This, of course, causes an AVAILABLE Attention message 21 to be sent to all class drivers that have enabled them. 22 Note that Data Safety Write Protection will be in effect 23 when the unit's volume is next brought "Unit-Online" 24 (unless the problem is no longer present at that time). 25 4. Between the time that the server discovers the 26 replacement failure and the unit completes its 27 transition to "Unit-Available," the setting of the Data 28 Safety Write Protected unit flag is indeterminate. This 29 flag may be either set or clear if it is returned to a 30 host during this interval. 31 5. Any pending bad block replacement attempts for the unit 32 are discarded, exactly as if the unit had been Data 33 Safety Write Protected when those bad blocks were 34 detected. Error log messages or other notifications are 35 not generated to report the dropped replacements. 36 6. No attempt is made to replace any additional bad blocks 37 that may be detected during the transition to 38 "Unit-Available," exactly as if the unit were Data 39 Safety Write Protected. 40 7. Subject to the constraint of not attempting further bad 41 block replacement, the server shall complete any 42 outstanding commands that it has already initiated. All 43 new commands received after the replacement failure *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-6 Bad Block Replacement 11 June 1992 1 shall be rejected. Outstanding commands that have not 2 yet been initiated may be completed or rejected. 3 Commands are rejected with a "Unit-Available" or 4 "Unit-Offline" status code. 5 The success or failure of read operations is not affected by bad 6 block replacement or the replacement's success or failure. The 7 status code reported for read operations is the status 8 appropriate to the original read attempt, before any replacement 9 was performed. The success or failure of write operations is 10 affected by replacement, since the write must be retried after 11 the replacement is performed. If the replacement succeeds, the 12 status code reported is that appropriate to the retry (unless the 13 retry also encounters a bad block, in which case another 14 replacement and another retry are performed, and the process 15 repeated until the retry does not encounter a bad block). If the 16 replacement fails, the status code reported is that appropriate 17 to the original write attempt that caused the bad block 18 replacement. The cause of a bad block replacement failure is 19 only reported as an event code in an error log message; it is 20 never reported as a status code in an end message. 21 8.4 Replacement Control Table Access 22 The standard Disk MSCP server shall allow read and write access 23 to the Replacement Control Table (RCT), as such access is 24 required by higher layers in order to be able to perform bad 25 block replacement. The Bad Block Replacement layer need not 26 provide RCT access, however, since it implements bad block 27 replacement itself. 28 Even though it is not necessary for the Bad Block Replacement 29 layer to provide RCT access, in many cases it is desirable to do 30 so. Providing such access allows a host to examine certain 31 additional information contained in RCT block 0. Also, since 32 accessing a replacement block is usually slower than accessing a 33 good logical block, a host could use the RCT contents to allocate 34 files with critical, real-time access requirements in portions of 35 the volume that do not contain bad blocks. 36 Therefore a server's Bad Block Replacement layer shall provide 37 one of the following RCT access options. The server may provide 38 different options for different disk types. The options are: 39 1. No RCT access. Any attempt to access any block inside 40 the RCT will be rejected. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-7 Replacement Control Table Access 11 June 1992 1 2. Read-only access to the entire RCT. Attempts to read 2 any block in the first copy of the RCT will be honored. 3 That is, a READ command with "logical block number" in 4 the range "unit size" through "unit size" plus "RCT 5 size" minus one and "byte count" equal to the unit's 6 block size will be honored. Any other attempt to access 7 the RCT will be rejected. 8 When an RCT access attempt is rejected the command is rejected as 9 an "Invalid Command" parameter error (see "Invalid Command" 10 status in Section 5.5, "Status Codes"). If the command is a READ 11 command with a valid "logical block number," but the "byte count" 12 is not equal to the unit's block size, then the subcode is 13 "Invalid Byte Count." Otherwise the subcode is "Invalid Logical 14 Block Number." Attempts to write the RCT are rejected with an 15 "Invalid Logical Block Number" subcode. 16 Note that option 2, entire RCT access, only allows access 17 attempts to the first copy of the RCT. The Bad Block Replacement 18 layer uses the multicopy read algorithm to locate the proper RCT 19 copy to use in satisfying the request. 20 The Bad Block Replacement layer reports which option it 21 implements by altering the "RCT size" and "copies" parameters in 22 the GET UNIT STATUS end message when it passes that message on to 23 higher layers. These parameters are altered to describe the host 24 accessible portion of the RCT. The actual alterations are as 25 follows: 26 RCT Access Option "RCT size" "copies" 27 ----------------- ---------- -------- 28 No RCT access 0 0 29 Entire RCT actual RCT size 1 30 It is recommended that high-end controllers provide access to the 31 entire RCT. Minimal, low-end controllers will probably provide 32 no RCT access. Note that any disk that uses a nonstandard means 33 of bad block replacement, and therefore does not have an RCT, 34 appears identical to a disk that provides no RCT access. 35 The Bad Block Replacement layer may optionally allow additional 36 RCT access when a unit is brought "Unit-Online" with the "Ignore 37 Media Format Error" modifier. This may include read-write access 38 and/or access to individual copies of the RCT. The layer should 39 ensure that the values returned for "RCT size" and "copies" 40 reflect the RCT geometry presented to hosts. Note that any 41 additional access provided is intended for diagnostic use, and is 42 inherently controller dependent. Attempts to write to the unit *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-8 Replacement Control Table Access 11 June 1992 1 when the "Ignore Media Format Error" modifier has been set may 2 have undefined results, including permanent corruption of the 3 volume. The errors produced by such corruption may be 4 indistinguishable from device hardware failures. 5 8.5 Atomic Bad Block Replacement 6 The Bad Block Replacement layer shall perform bad block 7 replacement operations as atomic operations. That is, while a 8 bad block replacement operation is in progress, any transfer 9 operations for either the bad block being replaced or block 0 of 10 the Replacement Control Table (RCT) shall not be performed. Such 11 transfer operations shall be deferred until after the bad block 12 replacement has completed. For a multiblock transfer that 13 includes the block being replaced, only the transfer of the block 14 being replaced need be deferred; the blocks before and after the 15 one being replaced may be transferred immediately. 16 A bad block replacement operation begins just before the "best 17 guess" data is obtained for the block. This is not necessarily 18 the same transfer that detects the bad block and causes it to be 19 replaced. The bad block replacement operation ends just after 20 RCT block 0 is updated to indicate that replacement is no longer 21 in progress. The Controller Bad Block Replacement layer shall 22 lock out all host and higher layer access to the block being 23 replaced and RCT block 0 between these two times. Note that read 24 access must be locked out as well as write access. 25 8.6 Error Log Messages 26 Any error severe enough to warrant replacement of the affected 27 block is, by definition, a "significant" error that shall be 28 reported in an error log message. The error log message shall 29 use the "Disk Transfer Error" format or some other format that 30 specifies the disk location at which the error occurred. The 31 "Bad Block Replacement Request" error log flag is set in the 32 error log message to indicate that replacement of the block will 33 be attempted. 34 When the replacement attempt completes, the Bad Block Replacement 35 layer generates an additional "Bad Block Replacement Attempt" 36 format error log message to report the replacement attempt's 37 success or failure. 38 Due to the different error characteristics of the Replacement 39 Control Table (RCT), controllers should use an altered strategy 40 for logging errors on RCT accesses. In the host area of a disk, 41 the most common errors are eliminated by bad block replacement. 42 Since bad block replacement is not used in the RCT, these common 43 errors can be expected to occur, and are therefore relatively *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-9 Error Log Messages 11 June 1992 1 uninteresting for an error log. 2 The goal for logging RCT errors is to not log any error that 3 would cause bad block replacement in the host area. Controllers 4 that contain both standard Disk MSCP and Controller Initiated Bad 5 Block Replacement can do this precisely, since they know exactly 6 which errors they use to trigger replacement. Layered 7 controllers, where standard Disk MSCP and Controller Initiated 8 Bad Block Replacement are distinct entities, can only approximate 9 this by filtering out "Data Errors." That is, an independent Bad 10 Block Replacement layer should only log the non-"Data Errors" 11 that occur on RCT accesses. 12 The one exception to not logging RCT "Data Errors" is when an RCT 13 access fails -- that is, when the multiread or multiwrite 14 algorithms fail, indicating that the read or write failed to all 15 copies of the RCT. Whenever the multiread or multiwrite 16 algorithms fail, an error log message shall be generated 17 reporting the error that occurred when the last RCT copy was 18 accessed. If this error is a "Data Error," its event code is 19 converted to a "Media Format Error" with the same subcode value 20 before being reported in the error log message. All other errors 21 are reported without event code alteration. 22 Other than the altered strategy for logging RCT "Data Errors" 23 described above, any errors resulting from accesses to the unit 24 during bad block replacement are logged according to normal 25 controller policies. The only change is that the "Error During 26 Replacement" error log flag should be set in such messages, 27 indicating that the operation was requested by the bad block 28 replacement process. All such messages should be issued before 29 the "Bad Block Replacement Attempt" format error log message that 30 reports the replacement attempt's status. 31 8.7 Unit Context Information 32 The Bad Block Replacement layer shall separately maintain the 33 following unit flags for each unit it has "Unit-Online": 34 Write Protected (software) 35 Write Protected (data safety) 36 The reason for this is that the Bad Block Replacement layer sets 37 the "Write Protected (software)" unit flag in the Disk MSCP layer 38 if either of these flags are set. The replacement layer shall 39 keep track of these flags itself, in order to remember the 40 reason(s) for write protecting the unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-10 Unit Context Information 11 June 1992 1 The Bad Block Replacement layer also maintains internal, per 2 unit, flags to record: 3 o The individual causes of Data Safety Write Protection. 4 It uses these flags to return the proper status 5 subcodes. 6 o Whether Replacement Control Table (RCT) block 0 has been 7 rewritten and any incomplete replacements finished. 8 Normally these actions are performed when the unit is 9 brought "Unit-Online." However, if the unit is Hardware 10 Write Protected when it is brought "Unit-Online," then 11 these actions cannot be performed. Thus this flag is 12 set to remember to perform these actions when or if the 13 unit subsequently ceases to be Hardware Write Protected. 14 This flag is further described in Sections 8.8, "Actions 15 During ONLINE" and 8.10, "Actions Before First 16 Modification." 17 o Whether the "Ignore Media Format Error" modifier was set 18 when the unit was brought "Unit-Online." It uses this 19 flag to inhibit bad block replacement. 20 8.8 Actions During ONLINE 21 The Bad Block Replacement layer performs two different courses of 22 action for an ONLINE command, depending on whether the "Ignore 23 Media Format Error" modifier is set. Normally, the layer reads 24 block 0 of the Replacement Control Table (RCT) to perform various 25 volume consistency checks. However, if the "Ignore Media Format 26 Error" modifier is set, the layer does not access the RCT in any 27 way. 28 If an ONLINE command has the "Ignore Media Format Error" modifier 29 set, the Bad Block Replacement layer merely passes the unmodified 30 command on to the Disk MSCP layer. Similarly, it passes the 31 unmodified response from the Disk MSCP layer back to the host or 32 higher layer that issued the command. The replacement layer's 33 only additional action is to remember, in an internal flag, that 34 the "Ignore Media Format Error" modifier was set. It uses this 35 flag to inhibit all bad block replacement attempts and to 36 optionally allow additional access to the RCT for diagnostics. 37 When the "Ignore Media Format Error" modifier is not set, the Bad 38 Block Replacement layer performs the following steps to process 39 an ONLINE command: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-11 Actions During ONLINE 11 June 1992 1 1. Issue an ONLINE command to the Disk MSCP layer. All 2 fields except the "modifiers" field are copied from the 3 ONLINE command received by the replacement layer. The 4 "modifiers" field is constructed as follows: 5 a. The "Allow Self Destruction" modifier is copied from 6 the received command. 7 b. If the Disk MSCP layer provides Multihost Support, 8 the "Exclusive Access" modifier is set. 9 c. All other modifiers are clear. 10 If the Disk MSCP ONLINE fails, return its end message as 11 the result of this layer's ONLINE and exit. If the Disk 12 MSCP ONLINE reports that the unit is already 13 "Unit-Online," the ONLINE has succeeded. Again, return 14 its end message as the result of this layer's ONLINE and 15 exit. Otherwise save its end message as the prototype 16 for this layer's ONLINE end message. 17 2. Read block 0 of the RCT with the multicopy read 18 algorithm. If the multicopy read algorithm fails, 19 report its result as the status of this ONLINE and exit. 20 3. If the unit is Hardware Write Protected, set an internal 21 flag and go to step 6. This flag is further described 22 in Section 8.10, "Actions Before First Modification." 23 4. Write the data read by step 2 back out to block 0 of the 24 RCT with the multicopy write algorithm. If the 25 multicopy write algorithm fails, report its result as 26 the status of this ONLINE and exit. 27 5. If the data read by step 2 indicates that there is an 28 incomplete bad block replacement on the volume, attempt 29 to complete it. If the completion attempt fails, report 30 it with an error log message. Continue with the next 31 step regardless of whether the completion attempt 32 succeeds or fails. 33 6. Examine the contents of RCT block 0, as read in step 2 34 and possibly modified in step 5. If there is an 35 incomplete bad block replacement attempt or the RCT is 36 invalid, set the "Write Protect (data safety)" unit flag 37 in the unit's context. The checks, if any, that the 38 controller performs to verify the RCT's validity are 39 specified by the Digital Storage Architecture Disk 40 Format and/or the controller's functional specification. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-12 Actions During ONLINE 11 June 1992 1 7. If the "Enable Set Write Protect" modifier was set in 2 the original ONLINE command received from the higher 3 layer, then copy the "Write Protected (software)" unit 4 flag from the original command to the unit's context. 5 8. If either of the "Write Protect (data safety)" or "Write 6 Protect (software)" unit flags are set in the unit's 7 context, issue a SET UNIT CHARACTERISTICS command to the 8 Disk MSCP layer to software write protect the unit. If 9 the command fails, report its status as the status of 10 this ONLINE and exit. 11 9. The ONLINE operation has completed successfully. Copy 12 the "Write Protect (data safety)" and "Write Protect 13 (software)" unit flags from this unit's context to the 14 prototype end message saved in step 1. If the unit is 15 Data Safety Write Protected, set the appropriate status 16 subcodes. Return the resulting end message to the host 17 or higher layer. 18 If the ONLINE operation fails, clean-up may or may not be 19 necessary, depending on where the failure occurs. If the failure 20 occurs in step 1 (the ONLINE command to the Disk MSCP layer), the 21 unit will not be "Unit-Online" through the Disk MSCP layer, so no 22 clean-up is necessary. If the failure occurs anywhere else, the 23 Bad Block Replacement layer shall issue an AVAILABLE command with 24 the "Spin-down" modifier set to the Disk MSCP layer, since the 25 unit may still be "Unit-Online" through the Disk MSCP layer. 26 As part of bringing a unit "Unit-Online," the Bad Block 27 Replacement layer attempts to complete any incomplete replacement 28 on the volume. If the unit is not Hardware Write Protected, the 29 attempt is made as part of the ONLINE command. If the unit is 30 Hardware Write Protected, the attempt is made after the unit 31 ceases to be Hardware Write Protected and no later than the first 32 attempt to write to the unit or the first SET UNIT 33 CHARACTERISTICS command after the unit ceases to be Hardware 34 Write Protected. This is discussed in Section 8.10, "Actions 35 Before First Modification." In either case, there is only one 36 attempt to complete the replacement. If that one attempt fails, 37 no other attempt will be made until the next time the volume is 38 brought "Unit-Online." 39 8.9 Actions During SET UNIT CHARACTERISTICS 40 The Bad Block Replacement layer performs the following steps to 41 process a SET UNIT CHARACTERISTICS command: *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-13 Actions During SET UNIT CHARACTERISTICS 11 June 1992 1 1. If the internal flag is set indicating that the unit was 2 Hardware Write Protected when it was brought 3 "Unit-Online" and it is no longer Hardware Write 4 Protected, perform the actions described in Section 5 8.10, "Actions Before First Modification" and clear the 6 flag. If those actions fail, report their result as the 7 status of this SET UNIT CHARACTERISTICS and exit. Note 8 that this step may clear the "Write Protect (data 9 safety)" unit flag in the unit's context. 10 2. If the "Enable Set Write Protect" modifier was set in 11 the original SET UNIT CHARACTERISTICS command received 12 from the higher layer, then copy the "Write Protected 13 (software)" unit flag from the original command to the 14 unit's context. 15 3. Issue a SET UNIT CHARACTERISTICS command to the Disk 16 MSCP layer. The command is identical to the original 17 SET UNIT CHARACTERISTICS command received by the 18 replacement layer with the following changes: 19 a. The "Enable Set Write Protect" modifier is always 20 set. 21 b. The "Write Protect (software)" unit flag is set to 22 the "inclusive-or" of the "Write Protect (data 23 safety)" and "Write Protect (software)" unit flags 24 in the unit's context. 25 If the command fails, report its status as the status of 26 this SET UNIT CHARACTERISTICS and exit. 27 4. The SET UNIT CHARACTERISTICS operation has completed 28 successfully. Copy the "Write Protect (data safety)" 29 and "Write Protect (software)" unit flags from this 30 unit's context to the end message returned in the 31 previous step. If the unit is Data Safety Write 32 Protected, set the appropriate status subcodes. Return 33 the resulting end message to the host or higher layer. 34 If the SET UNIT CHARACTERISTICS operation fails for any reason, 35 the Bad Block Replacement layer shall issue an AVAILABLE command 36 with all modifiers clear to the Disk MSCP layer and send an 37 AVAILABLE attention message to the host and higher layers. This 38 is necessary to preserve the rule that the unit may not be left 39 "Unit-Online" if a command that might change the unit's context 40 fails. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-14 Actions Before First Modification 11 June 1992 1 8.10 Actions Before First Modification 2 As part of bringing a unit "Unit-Online," the Bad Block 3 Replacement layer reads and rewrites Replacement Control Table 4 (RCT) block 0. The reason for this is that, when the volume was 5 last in use, there may have been a failure after some copies of 6 RCT block 0 were written but before all of them were written. If 7 this situation were to occur, a transient or inconsistent error 8 could cause successive reads of RCT block 0 to return different 9 data, as data was returned from different copies. By reading and 10 rewriting block 0 the layer ensures that all copies contain the 11 same data, so that successive reads will always return the same 12 results. 13 However, if the unit is Hardware Write Protected when it is 14 brought "Unit-Online," this problem can still occur since block 0 15 cannot be rewritten. So long as the unit remains Hardware Write 16 Protected, no problems can occur, since the volume cannot be 17 modified. However, if the unit ceases to be Hardware Write 18 Protected, volume modification becomes possible. If this occurs, 19 RCT block 0 shall be read and rewritten prior to the first 20 modification. 21 When a unit is brought "Unit-Online," the Bad Block Replacement 22 layer sets an internal flag if the unit is Hardware Write 23 Protected and RCT block 0 cannot be rewritten. This flag shall 24 be checked when a host or higher layer attempts to modify the 25 volume and, if it is set, the actions described below performed. 26 There are three ways that the volume may be modified: 27 1. Bad block replacement. The actions below are performed 28 after checking that the unit is not Hardware Write 29 Protected, but before checking if the unit is Data 30 Safety Write Protected or modifying the RCT in any way. 31 That is, these actions are performed after the bad block 32 is detected but before the bad block replacement 33 algorithm is initiated. 34 2. A SET UNIT CHARACTERISTICS command. The point at which 35 the actions below are performed is described in Section 36 8.9, "Actions During SET UNIT CHARACTERISTICS." 37 3. A host or higher layer write operation. The actions 38 below are performed after checking that the unit is not 39 Hardware or Software Write Protected but before any 40 modification is performed on the unit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-15 Actions Before First Modification 11 June 1992 1 The Bad Block Replacement layer need not wait until a 2 modification is attempted. It may perform the actions below 3 spontaneously upon the unit ceasing to be Hardware Write 4 Protected. From the viewpoint of a host or higher layer, this is 5 no different from the actions below being performed in response 6 to an attempted bad block replacement. 7 The actions that shall be performed before the first modification 8 are: 9 1. Check the internal flag discussed above. If the flag is 10 clear, proceed with the modification. If the flag is 11 set, clear it and continue with the next step. 12 2. Read block 0 of the RCT with the multicopy read 13 algorithm. If the multicopy read algorithm fails, exit. 14 3. Check the internal flags recording the reasons, if any, 15 for the unit being Data Safety Write Protected. If the 16 incomplete replacement flag is clear, then clear the 17 incomplete replacement flags in RCT block 0. If the 18 invalid RCT flag is clear, implying that the RCT was 19 valid when the unit was brought "Unit-Online," yet the 20 current RCT image is not valid, either exit with a 21 "Media Format Error" or "fix" the invalid RCT. An 22 example of "fixing" the RCT is zeroing a reserved field 23 that was zero when the unit was brought "Unit-Online," 24 but that is now nonzero. 25 4. Write RCT block 0 with the value read in step 2 and 26 possibly modified in step 3, using the multicopy write 27 algorithm. If the multicopy write algorithm fails, 28 exit. 29 5. If the value just written to RCT block 0 indicates there 30 is an incomplete bad block replacement on the volume, 31 attempt to complete it. If the completion attempt 32 fails, report it with an error log message and continue. 33 6. Set the "Write Protected (data safety)" unit flag to the 34 "inclusive-or" of all internal flags representing 35 possible causes of Data Safety Write Protection. 36 7. Issue a SET UNIT CHARACTERISTICS command to the Disk 37 MSCP layer to set the unit's Software Write Protect 38 status to the "inclusive-or" of the "Write Protect (data 39 safety)" and "Write Protect (software)" unit flags in 40 the unit's context. If the command fails, exit. *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-16 Actions Before First Modification 11 June 1992 1 8. This algorithm has completed. Proceed with the 2 modification attempt that caused it to be invoked. 3 There are four places where this algorithm can fail. They are 4 the multicopy read operation in step 2, the attempt to "fix" an 5 invalid RCT in step 3, the multicopy write in step 4, and the SET 6 UNIT CHARACTERISTICS in step 7. If the algorithm fails at one of 7 these steps, the modification attempt fails with the status code 8 resulting from the failed step. Also, the unit is forced 9 "Unit-Available" to all class drivers. The handling of other 10 commands that may be outstanding is identical to that which is 11 done for a failed replacement operation. 12 Note that execution of the above procedure may complete the 13 incomplete replacement that was causing a unit to be Data Safety 14 Write Protected. This yields the possibility that Data Safety 15 Write Protection may disappear spontaneously, as the result of a 16 bad block replacement. 17 8.11 MSCP Control Message Format Changes 18 This section describes the changes in control message formats 19 between standard Disk MSCP and MSCP with Controller Initiated Bad 20 Block Replacement. All messages and fields that are not 21 mentioned in this section are identical to the descriptions found 22 in Chapter 6, "Minimal MSCP Command Set" and if the controller 23 provides Multihost Support, Chapter 7, "Multihost Support." 24 8.11.1 Controller Flags 25 The Controller Initiated Bad Block Replacement controller flag is 26 returned set in the "controller flags" field of a SET CONTROLLER 27 CHARACTERISTICS command's end message only if the server supports 28 Controller Initiated Bad Block Replacement on all disk types that 29 can be connected to it. Note that a controller is expressly 30 permitted to implement replacement on some disk types but not on 31 others. In that case this flag shall be returned clear. See 32 also the description of this flag in Section 5.6, "Controller 33 Flags" for additional detail. 34 8.11.2 Unit Flags 35 The Controller Initiated Bad Block Replacement unit flag is 36 returned set in the "unit flags" field of the GET UNIT STATUS, 37 ONLINE, and SET UNIT CHARACTERISTICS command's end messages only 38 if bad block replacement for this unit will be performed by the 39 controller. This flag is returned clear if the host is 40 responsible for bad block replacement for this unit. (As noted 41 in the previous section, a controller may implement replacement *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-17 MSCP Control Message Format Changes 11 June 1992 1 on some disk types but not on others.) See also the description 2 of this flag in Section 5.7, "Unit Flags" for additional detail. 3 8.11.3 Transfer Commands 4 The changes described in this section apply to the ACCESS, 5 COMPARE HOST DATA, ERASE, READ, and WRITE commands. 6 The meaning of transfers addressed to the Replacement Control 7 Table (RCT) portion of the disk is substantially changed; see 8 Section 8.4, "Replacement Control Table Access." For transfers 9 addressed to the host area of the disk, the only change is that 10 the controller itself replaces bad blocks rather than the host. 11 Since the controller is replacing bad blocks, the "Bad Block 12 Reported" end flag will always be clear and the contents of the 13 "first bad block" end message field will always be undefined. 14 The "Bad Block Unreported" end flag is set, however, if the 15 transfer encountered one or more bad blocks. The specific blocks 16 that were bad and the results of their replacement are reported 17 only via error log messages. 18 8.11.4 ONLINE and SET UNIT CHARACTERISTICS Commands 19 Modifiers: 20 The "Ignore Media Format Error" modifier is changed from 21 standard Disk MSCP. Note that this modifier is only allowed 22 on the ONLINE command. Its revised meaning is as follows: 23 Ignore Media Format Error 24 This modifier is only allowed on the ONLINE command. In 25 standard Disk MSCP, this modifier suppresses media 26 (volume) format validity checking. With Controller 27 Initiated Bad Block Replacement, this modifier also 28 suppresses the Replacement Control Table (RCT) checks 29 normally performed when a unit is brought "Unit-Online." 30 Normally, when a unit is brought "Unit-Online," the MSCP 31 server makes several accesses to the unit. In standard 32 Disk MSCP, these accesses merely verify volume format 33 validity. With Controller Initiated Bad Block 34 Replacement, the MSCP server also accesses the RCT to 35 check the context information stored there. If any of 36 these accesses fail, the unit cannot be brought 37 "Unit-Online" and a Media Format Error is returned. This 38 modifier suppresses all accesses performed when bringing 39 the unit "Unit-Online," thus allowing it to be brought 40 "Unit-Online" when these accesses would fail. The *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-18 MSCP Control Message Format Changes 11 June 1992 1 penalty for using this modifier is that data on the 2 volume may be corrupted. 3 The exact checks that are suppressed by this modifier 4 are: 5 1. The format validity checks done by standard Disk 6 MSCP. 7 2. Checking for an incomplete bad block replacement 8 operation, and completing it if possible. 9 The unit is always brought "Unit-Online" with Data Safety 10 Write Protection disabled (i.e., writes allowed). 11 Setting this modifier inhibits all bad block replacement 12 attempts and may optionally provide additional access to 13 the RCT. 14 Note that these checks exist to prevent data loss or 15 corruption. Therefore this modifier should only be used 16 in exceptional circumstances, such as backing up a known 17 bad disk. In particular, the results of any attempt to 18 write to the unit are undefined when this modifier has 19 been set. 20 Status Codes: 21 The following new subcodes may be returned with the "Success" 22 status code for the ONLINE and SET UNIT CHARACTERISTICS 23 commands. Remember that the subcodes are bit flags, and that 24 the subcode field contains the "logical-or" of all applicable 25 subcodes, including the subcodes defined in standard Disk 26 MSCP. 27 Success (subcode "Incomplete Replacement") 28 The volume has a partially completed bad block 29 replacement operation, and the attempt to complete it did 30 not succeed. The cause of the attempt's failure is 31 reported with an error log message. This subcode merely 32 reports that there is a partially completed replacement 33 on the volume. Note that the unit will be Data Safety 34 Write Protected whenever this subcode is returned. 35 Success (subcode "Invalid RCT") 36 The volume has an invalid RCT or, if the disk uses a 37 nonstandard means of bad block replacement, some data *** RESTRICTED DISTRIBUTION *** Digital Equipment Corporation Confidential And Proprietary Mass Storage Control Protocol Version 2.4.0 CONTROLLER INITIATED BAD BLOCK REPLACEMENT Page 8-19 MSCP Control Message Format Changes 11 June 1992 1 structure used to control bad block replacement is 2 invalid. The checks, if any, that the controller 3 performs to verify the RCT's validity are specified by 4 the Digital Storage Architecture Disk Format and/or the 5 controller's functional specification. Note that the 6 unit will be Data Safety Write Protected whenever this 7 subcode is returned. 8 "Media Format Errors" may be reported for SET UNIT 9 CHARACTERISTICS, which could not happen with standard Disk 10 MSCP. 11 8.11.5 GET UNIT STATUS Command 12 End Message Fields: 13 RCT size 14 copies 15 The interpretation and meaning of these fields is 16 identical to standard Disk MSCP. Howev