Google
 

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

   o	HSC-50 Functional Specification
   o	HSC-50 Multi-Host Policies
   o	HSC-50 Error Hnadling Policies
   o	HSC-50 ROM Bootstrap Documentation
   o	HSC-50 Controller Diagnostics Documentation
   o	HSC-50 Version 2.00 Release Notes

------------------
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


			TABLE OF CONTENTS


Section 1
	Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
	 Scope and Organization of This Document . . . . . . . . . 4
	 Product Overview  . . . . . . . . . . . . . . . . . . . . 4
	 Product Motivation  . . . . . . . . . . . . . . . . . . . 5
	  Market Target  . . . . . . . . . . . . . . . . . . . . . 5
	  Product Goals  . . . . . . . . . . . . . . . . . . . . . 6
	   Generic Goals . . . . . . . . . . . . . . . . . . . . . 6
	   Specific Goals  . . . . . . . . . . . . . . . . . . . . 6
	   Non-Goals . . . . . . . . . . . . . . . . . . . . . . . 7
	  New Concepts . . . . . . . . . . . . . . . . . . . . . . 7
	   Remote Controller Shareable by Multiple Hosts . . . . . 7
	   Mass Storage Cluster of Disks and Tapes Of Varying Types 8
	   Uniform Attachment  . . . . . . . . . . . . . . . . . . 8
	   Geometric Independence and "Perfect Disks"  . . . . . . 8
	   Local Terminal and Pseudo-Terminal  . . . . . . . . . . 9
	   Controller Local Functions  . . . . . . . . . . . . . . 9
	    Diagnostics  . . . . . . . . . . . . . . . . . . . . . 9
	    Utility Functions  . . . . . . . . . . . . . . . . . . 10
	   Partitioning of I/O Responsibilities  . . . . . . . . . 10
	    Error Handling . . . . . . . . . . . . . . . . . . . . 10
	    Diagnostics  . . . . . . . . . . . . . . . . . . . . . 11
	    Performance Optimizations  . . . . . . . . . . . . . . 11
	   High Availability . . . . . . . . . . . . . . . . . . . 12

Section 2
	Subsystem Architecture . . . . . . . . . . . . . . . . . . 13
	 Overview  . . . . . . . . . . . . . . . . . . . . . . . . 13
	 Functional Elements of the Subsystem  . . . . . . . . . . 13


Section 3
	Performance  . . . . . . . . . . . . . . . . . . . . . . . 15
	 Request Level Throughput  . . . . . . . . . . . . . . . . 15
	 Host Bus Burst Data Bandwidth . . . . . . . . . . . . . . 17


Section 4
	Host Interface . . . . . . . . . . . . . . . . . . . . . . 18
	 Hardware Interconnect (ICCS)  . . . . . . . . . . . . . . 18
	 Software Interconnects (Port Driver and Class Driver) . . 18
	  Port Interconnect  . . . . . . . . . . . . . . . . . . . 18
	  Class Driver Interconnect  . . . . . . . . . . . . . . . 18
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


Section 5
	Human Interface  . . . . . . . . . . . . . . . . . . . . . 22
	 Front Panel Buttons . . . . . . . . . . . . . . . . . . . 22
	 Access Control Switch . . . . . . . . . . . . . . . . . . 23
	 Cassette Load Device  . . . . . . . . . . . . . . . . . . 24
	 Local Terminal  . . . . . . . . . . . . . . . . . . . . . 25
	  Local Terminal Operation . . . . . . . . . . . . . . . . 26
	 Pseudo-Terminal . . . . . . . . . . . . . . . . . . . . . 28
	 Operational Procedures  . . . . . . . . . . . . . . . . . 28
	  Bootstrapping the Subsystem  . . . . . . . . . . . . . . 28
	  Local Terminal and Pseudo-terminal Command Syntax. . . . 29
	   Program Input . . . . . . . . . . . . . . . . . . . . . 30
	   Program Output  . . . . . . . . . . . . . . . . . . . . 33

Section 6
	Disk Interface (SDI) . . . . . . . . . . . . . . . . . . . 34

Section 7
	Tape Interface (STI) . . . . . . . . . . . . . . . . . . . 35

Section 8
	Physical Characteristics . . . . . . . . . . . . . . . . . 36
	 Module Definitions  . . . . . . . . . . . . . . . . . . . 36
	  P.ioc (I/O Control Processor)  . . . . . . . . . . . . . 36
	  M.std1 and M.std2 (Memory, versions 1 and 2) . . . . . . 36
	  K.iccs (ICCS Control)  . . . . . . . . . . . . . . . . . 36
	  K.sdi (Standard Disk Interface Control)  . . . . . . . . 36
	  K.sti (Standard Tape Interface Control)  . . . . . . . . 37
	 Configuration . . . . . . . . . . . . . . . . . . . . . . 37
	  Configuration Rules and Limits . . . . . . . . . . . . . 37
	  Configuration Considerations . . . . . . . . . . . . . . 37
	  Typical Configurations . . . . . . . . . . . . . . . . . 38
	 Packaging . . . . . . . . . . . . . . . . . . . . . . . . 40
	  Cabinet  . . . . . . . . . . . . . . . . . . . . . . . . 40
	   Cabinet Exterior  . . . . . . . . . . . . . . . . . . . 40
	   Cabinet Interior  . . . . . . . . . . . . . . . . . . . 42
	  Environment  . . . . . . . . . . . . . . . . . . . . . . 42
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


Section 9
	Programs That Execute in the Subsystem . . . . . . . . . . 44
	 Utility Functions . . . . . . . . . . . . . . . . . . . . 44
	  Subsystem Crash Dump (CDMP)  . . . . . . . . . . . . . . 44
	  Subsystem Parameter Alteration (SET) . . . . . . . . . . 44
	  Subsystem Parameter Interrogation (SHOW) . . . . . . . . 46
	  TU58 Duplication (T58C)  . . . . . . . . . . . . . . . . 47
	  TU58 Patch (TPAT)  . . . . . . . . . . . . . . . . . . . 48
	  Offline Disk Volume Copy (DCPY)  . . . . . . . . . . . . 48
	  Offline Disk-to-Tape Volume Copy (BCKP)  . . . . . . . . 49
	  Offline Tape-to-Disk Volume Restore (RSTO) . . . . . . . 50
	  Offline Disk Formatter (DFMT)  . . . . . . . . . . . . . 50
	 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . 52
	  F-11 micro-ODT . . . . . . . . . . . . . . . . . . . . . 52
	  Diagnostic Output  . . . . . . . . . . . . . . . . . . . 52
	  Diagnostic Arguments . . . . . . . . . . . . . . . . . . 53
	  Continuously Scheduled Diagnostics . . . . . . . . . . . 53
	  Initialization Diagnostics . . . . . . . . . . . . . . . 53
	   Initialization P.ioc Test (BPIO)  . . . . . . . . . . . 53
	   Initialization F-11 Test (BF11) . . . . . . . . . . . . 54
	   Initialization Control Memory Test (BCM)  . . . . . . . 54
	   Initializaton K.sdi Test (BKDI) . . . . . . . . . . . . 54
	   Initializaton K.sti Test (BKTI) . . . . . . . . . . . . 55
	   Initialization K.iccs Test (BKCI) . . . . . . . . . . . 55
	   Initialization Buffer Memory Test (BBM) . . . . . . . . 56
	   Initialization Quick-verify Functional Test (BFQV). . . 56
	  OFFLINE DIAGNOSTICS  . . . . . . . . . . . . . . . . . . 56
	   Offline F-11 Test (OF11)  . . . . . . . . . . . . . . . 56
	   Offline Private Memory Test (OPM) . . . . . . . . . . . 56
	   Offline Control Memory Test (OCM) . . . . . . . . . . . 57
	   Offline Buffer Memory Test (OBM)  . . . . . . . . . . . 57
	   Offline K.iccs Test (OKCI)  . . . . . . . . . . . . . . 57
	   Offline Internal Bus Test (OIBT)  . . . . . . . . . . . 58
	   Offline Multi-drive Exerciser (OMDE)  . . . . . . . . . 58
	   Offline System Functional Verification (OSFV) . . . . . 59
	  INLINE DIAGNOSTICS . . . . . . . . . . . . . . . . . . . 59
	   Inline TU58 Test (IT58) . . . . . . . . . . . . . . . . 59
	   Inline Buffer Memory Test (IBM) . . . . . . . . . . . . 60
	   Inline Disk Drive Interface Test (ISDI) . . . . . . . . 60
	   Inline Disk Drive Test (IDT)  . . . . . . . . . . . . . 60
	   Inline Tape Formatter Test (ITT)  . . . . . . . . . . . 60
	   Inline K.sdi Test (IKDI)  . . . . . . . . . . . . . . . 61
	   Inline K.sti Test (IKTI)  . . . . . . . . . . . . . . . 61
	  ERROR RATE ANALYSIS  . . . . . . . . . . . . . . . . . . 61
	   Analyze Disk Read/Write Errors (ARDW) . . . . . . . . . 61
	   Analyze Seek Errors (ASKE)  . . . . . . . . . . . . . . 62
	  SUPPORT ROUTINES FOR DIAGNOSTICS . . . . . . . . . . . . 62
	   Support K-INIT Sequence (SKSQ)  . . . . . . . . . . . . 62
	   Support Drive Test (SDRT) . . . . . . . . . . . . . . . 62

	APPENDIX A (SYSTEM MESSAGES) . . . . . . . . . . . . . . . 63

	APPENDIX B (BCKP/RSTO TAPE FORMATS)  . . . . . . . . . . . 64
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


 
 
 
 
 
 
 
 
 
 
 
                                 PRELIMINARY
                                 -----------


                        HSC50 Functional Specification
                        ------------------------------


                                 Revision 0.1
                                 ------------






References:
-----------
 
Additional detailed architectural and design information is available  in  the
following supplemental documents:

     1.  HSC50  Internal  Hardware/Software  Interface  Description,   Revised
         (Bean, Blackledge 8-Nov-79)

     2.  HSC50 P.ioc Functional Specification (Fava, Sergeant 10-Oct-79)

     3.  HSC50 K.sdi Interface Functional Specification (Lary 19-Jul-79)

     4.  HSC50 K.host Generic Functional Specification (Blackledge 12-Sep-79)

     5.  HSC50 K.iccs Functional Specification (Blackledge 14-Sep-79)

     6.  HSC50 Control Program Functional Specification (Bean 3-Jan-80)

     7.  HSC50 Backplane Bus Specification (Blackledge 17-Aug-79)

     8.  DEC Standard Disk Interface Specification (Bean 3-Jan-80)

     9.  DEC Serial Tape Interface Specification (to-be-published)

     10. Mass Storage Control Protocol Specification (Gardner 10-Dec-79)

     11. DEC Standard for Disk  Format  on  Intelligent  Subsystems  (Rubinson
         to-be-published)
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 2
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


     12. Diagnostic   Engineering   Project   Plan   for   HSC50    Controller
         (TeGrotenhuis to-be-published)

     13. HSC50 Diagnostic Execution Monitor  Functional  Specification  (Field
         to-be-published)

     14. HSC50   Pioc   Bootstrap   Test   Functional   Specification    (Hare
         to-be-published)

     15. HSC50 Generic K Diagnostic Microcode Functional Specification (Sicola
         13-Dec-79)

     16. HSC50 K.sdi Diagnostic  Microcode  Functional  Specification  (Sicola
         13-Dec-79)
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 3
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


 
                            IMPORTANT HSC50 FACTS
                            ---------------------
 
All reviewers please take notice of the following:

     1.  The HSC50 is the first release of a product in the HSC series.   This
         functional  specification is for that first incarnation, and IS NOT a
         functional or architectural specification for the entire series.   Do
         not  confuse  the  capabilities  of  the HSC50 with the potential for
         other contemporary HSC products or for HSC products of the future.

     2.  The set of utility functions provided at the  first  release  of  the
         HSC50  has  been  artificially  restricted  for  the  sake of reduced
         development risk.  This does not preclude the development for  future
         release of more sophisticated or more extensive utility functionality
         as the need arises.

     3.  The HSC50 will not have a data caching capability at first release.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 4
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


1.0  Introduction




1.1  Scope and Organization of This Document


This document comprises the functional  specification  for  the  HSC50.   This
document is organized (as outlined below) into nine sections.

Section 1 contains an overview of the product.

Section 2 summarizes the subsystem architecture.

Section 3 specifies the expected performance characteristics of the subsystem.

Section 4 specifies the interface from the host to the subsystem.

Section 5 describes the human  interface  at  the  subsystem  local  terminal,
pseudo-terminal and front panel.

Section 6 specifies the interface from the subsystem to disk drives.

Section 7 specifies the interface from the subsystem to tape drives.

Section 8 describes the physical characteristics of the subsystem.

Section 9 describes the utility and diagnostic programs that can be run on the
subsystem.



1.2  Product Overview


The HSC50 is a standalone disk and tape  subsystem  that  interfaces  multiple
hosts  (currently 15 according to ICCS limitations) on the ICCS bus with up to
24  disk  drives  and/or  tape  formatters.   The  subsystem  contains   local
intelligence  capable  of  managing  the  physical  activity  of  the  drives,
optimizing subsystem throughput, detecting and correcting physical errors, and
performing   local   functions  such  as  diagnostic  execution  without  host
intervention.

The HSC50 connects to any disk drive that conforms to the  DEC  Standard  Disk
Interface  (SDI)  and  any tape formatter that conforms to the DEC Serial Tape
Interface (STI).  The HSC50 masks the physical peculiarities  of  these  units
from  the  host,  presenting the host operating system with uniform disk class
(random access) and tape class (serial access) interfaces.

The HSC50 communicates with hosts using  the  Mass  Storage  Control  Protocol
(MSCP)  for  control functions and the ICCS data transport mechanisms for data
functions.

The HSC50 functions and host interface are  a  compatible  superset  of  those
provided  by  the  UDA50  (Unibus  Disk Adaptor).  In addition, the HSC50 will
attach to the same disks as the UDA50 and provide compatible data transfer and
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 5
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


error handling capability.



1.3  Product Motivation




1.3.1  Market Target - 

Mass Storage  Engineering  is  currently  committed  to  building  a  pair  of
compatible  controllers  with  common  software  interfaces to host and common
interconnect  to  drive.   They  differ  from  each  other  in  the  level  of
functionality  and  performance  they are capable of delivering.  HSC50 is the
high-end controller;  it is capable of connection to a large number of  drives
and to multiple hosts, and it delivers the higher average throughput.  It also
delivers significant functionality beyond that  of  the  smaller  and  cheaper
UDA50.

HSC50 is expected to to be marketed with the upper midrange and high range  of
DEC  systems configurations (those that typically have a price of greater than
$100K).  Among the systems for which HSC50 is destined are:
 
                VAX 11/780
                VENUS
                HYDRA
                2080
 
HSC50 is designed with functionality that provides the most benefit to:

     1.  High availability systems requiring maximum availability of the  data
         base to one or more processors.

     2.  Systems  with  I/O  intensive  applications,  such  as  a  commercial
         transaction processing system.

     3.  Systems with large data bases requiring large numbers of drives.

Among the features unique to the HSC50 that will make  it  effective  in  this
market are:

     1.  Support of both tapes and disks on the same subsystem.

     2.  Ability to attach to multiple hosts simultaneously.

     3.  High bandwidth internal data paths capable of  supporting  high  data
         rates.

     4.  Comprehensive media error detection and recovery algorithms.

     5.  Ability to diagnose and repair some malfunctions while the  subsystem
         continues to operate.

     6.  Ability to diagnose and repair independent of the host.

     7.  Ability to continue operating in a degraded manner when  non-critical
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 6
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


         subsystem components fail.

     8.  Ability to perform volume duplication and  backup  functions  without
         host involvement.

     9.  Ability to retrofit performance enhancement features (such as a  data
         cache) in the future.

     10. Automatic volume shadowing.

     11. Optimized device management for maximum subsystem throughput.




1.3.2  Product Goals - 



1.3.2.1  Generic Goals - 

As a member of the compatible controller set,  the  HSC50  has  the  following
goals in common with the UDA50:

     1.  It must  interface  to  the  host  using  the  Mass  Storage  Control
         Protocol.   It  will use a superset of the interface supported by the
         UDA50, but those functions supported in common with the UDA50 must be
         compatible  such  that  the  same disk class driver can function with
         either controller.

     2.  It must support disk drives that conform to  the  DEC  Standard  Disk
         Interface (SDI).

     3.  It must implement the new DEC Standard 166 disk format.

     4.  It must provide data buffering to allow for error correction  and  to
         serve  as  a  cushion  between high data rate devices and slower host
         busses and/or high-latency interconnects.

     5.  It  must  minimize  the  number  and   complexity   of   mass-storage
         diagnostics that run on the host.

     6.  It must support overlapped seeks.




1.3.2.2  Specific Goals - 

In addition to the above, the HSC50 has the following specific goals:

     1.  It must support any tape drive that has an average data rate of 10MHz
         or  less (6250 BPI, 200 IPS) and that conforms to the DEC Serial Tape
         Interface (STI).

     2.  It must support disks with burst data rates up to 25MHz.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 7
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


     3.  It must safeguard the integrity of the data  base  and  maximize  the
         availablity of the data base to the host(s).

     4.  It must maximize the overall throughput of the mass storage subsystem
         as perceived by the host.

     5.  It must simplify the attachment of future mass storage devices to DEC
         computer systems.

     6.  The  implementation  must  be  extensible  for   future   growth   in
         functionality,  capacity, and performance.  Specifically, it must not
         preclude  the  addition  of  logical  data   structure   manipulation
         functionality in some future product.




1.3.2.3  Non-Goals - 

The following are specific non-goals for the HSC50.

     1.  The HSC50 is a PHYSICAL I/O controller only.  It has no knowledge  of
         file structures or any other higher level organization of information
         stored on its drives.

     2.  The HSC50 is a slave to each and every host to which it is  attached,
         and  does  not  provide  any  coordination  function between multiple
         hosts.   It  obeys  every  legal  command  literally;   it   is   the
         responsibility  of  multiple  hosts  to  implement  the policies that
         arbitrate between them.




1.3.3  New Concepts - 

The  HSC50  and  UDA50  introduce  several  approaches  new  to  mass  storage
management  within  most  DEC systems.  Appreciation of these differences will
enhance the understanding of this document.



1.3.3.1  Remote Controller Shareable by Multiple Hosts - 

The HSC50 subsystem is electrically and  logically  independent  of  any  host
computer.   Packaged  and  powered  separately,  it contains all the resources
needed for its own operation.  The only connection with the  host  is  through
the  host  interconnect,  and the interconnect to any particular host does not
need to be operational for the HSC50 to service other hosts.

This logical and physical separation  makes  it  possible  for  the  HSC50  to
service  multiple  hosts  simultaneously.   It  also  prevents  failure of any
particular host from bringing the I/O subsystem down with it.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 8
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


1.3.3.2  Mass Storage Cluster of Disks and Tapes Of Varying Types - 

The HSC50 allows any mix of SDI disks and  STI  tapes  to  be  attached.   The
interaction between controller and drive is entirely parameter-driven, and the
SDI  and  STI  interfaces  provide  that  drive-specific  parameters  be  made
available  to  the  controller  at  the  time a drive is brought online to the
controller.  The dynamic nature of this approach should  allow  connection  of
future  drives  to  installed  subsystems  with  no subsystem or host software
alteration.



1.3.3.3  Uniform Attachment - 

The HSC50 masks most device-specific parameters from the host, and presents to
the host a series of disk and tape units, the only important characteristic of
which is their capacities.  This makes it possible to attach many  devices  of
dramatically  differing  geometrical  and  performance characteristics without
requiring host software to recognize the differences.

Certain sophisticated host software systems,  however,  do  desire  visibility
into  some  of  the  drive-specific characteristics so that host buffers, host
caches, and other host-controlled functions can  be  optimally  utilized.   To
this  end,  the  HSC50  makes  available  to  the  host certain drive-specific
parameters.  In addition, conventions for the  use  of  this  information  are
suggested  to minimize the impact of future disks with differing parameters on
host software.



1.3.3.4  Geometric Independence and "Perfect Disks" - 

The HSC50 presents each disk unit to the host as a randomly  accessible  group
of  blocks numbered 0 to n-1, where n is the number of blocks available to the
host on the unit.  In addition, the HSC50  is  capable  of  guaranteeing  that
every  block in this space is usable by automatically "repairing" those blocks
that go bad due to wear  (up  to  a  device-dependent  limit).   This  is  all
independent  of  the  physical geometry of the disk and holds true in spite of
the presence of actual physical flaws on the surface of the medium.

This is achieved by a controller feature called "revectoring".  Spare  sectors
are  reserved  on the medium at the time it is formatted, and these spares are
used as necessary to "replace" those sectors that  are  or  become  physically
unusable.   Revectoring is entirely a controller function, and is managed in a
way that minimizes the performance impact.

The presence of these logically "perfect" disks makes possible such  functions
as  unit  shadowing  and  fast  unit copy without regard to the file system or
other system-specific information organization on the disk.  It also makes the
host  insensitive  to the number of actual flaws on the disk and minimizes the
amount of bad block processing required on host systems.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)           PAGE 9
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


1.3.3.5  Local Terminal and Pseudo-Terminal - 

Because the HSC50 is a stand-alone intelligent subsystem, there are  occasions
when  terminal  input  and  output  directly  to  and  from  the  subsystem is
appropriate (such as control of the local functions described next).

The HSC50 allows for a local terminal directly  connected  to  the  subsystem.
When this terminal is present, it is used by the subsystem to report subsystem
activity, and may be used by an operator  or  FE  to  control  some  subsystem
activities locally.

For the cases where a local terminal is not present or appropriate, the  HSC50
provides  the  ability  for  a  suitable  host  program  to engage in dialogue
directly with the controller via ASCII characters as if they were entered  and
displayed  locally.   This  facility  (called the "pseudo-terminal") enables a
host program to make one of the host terminals "appear" to a  user  as  if  it
were  the  subsystem local terminal.  The pseudo-terminal facility can also be
used by a suitable host  program  to  control  subsystem  diagnostic  activity
directly without major human intervention.



1.3.3.6  Controller Local Functions - 

Because the  HSC50  has  a  local  storage  medium  (TU58  cassettes)  and  an
input/output  device  (the  local terminal or pseudo-terminal), it is possible
for programs to be loaded and executed  within  the  subsystem  itself.   This
capability  is  utilized  to allow diagnostics and media maintenance functions
(such as formatting) to be performed by the controller  independently  of  the
host.   In  addition  to  operator  or  FE activation at the local terminal or
pseudo-terminal, it is possible for the host to interact with subsystem  local
functions over the host interface.



1.3.3.6.1  Diagnostics - 

The subsystem has the capability to run diagnostic programs  while  continuing
to service host requests.  This capability is utilized in two ways:

     1.  Automatic Diagnostics.

         The subsystem monitors the behavior of its components, and if one  is
         determined   to   be  potentially  malfunctioning,  a  diagnostic  is
         automatically loaded and  executed  in  a  attempt  to  identify  the
         problem.

     2.  Inline Diagnostics.

         The host or a human at the local terminal or pseudo-terminal  may  at
         any  time  request  that  the  subsystem  execute  one  of its inline
         diagnostics.   Communicating  with  the  diagnostic  via  the   local
         terminal   or   the   pseudo-terminal,  the  requestor  controls  the
         diagnostic execution and interprets the results.

The only impact of execution of the above diagnostics on host activity is that
subsystem  performance  may degrade while the diagnostic is executing, and the
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 10
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


unit being diagnosed may have to be taken offline  for  the  duration  of  the
activity.

Finally, there is a third form of diagnostic that runs in the  controller  but
which  prevents  the  subsystem from operating simultaneously.  These "offline
diagnostics" are necessary only when a critical component is to be diagnosed.



1.3.3.6.2  Utility Functions - 

The  subsystem  also  has  the  capability  of  performing  certain  "utility"
functions  independently  of the host.  Disk volume formatting and duplicating
functions, and disk-to-tape backup and restore functions can be  performed  by
the  controller without involving the host.  Because the subsystem buffers and
data paths are  fast  and  the  operations  can  be  locally  optimized,  such
functions  can  typically be performed significantly faster than they can with
host intervention.

Because the controller has no knowledge of information structure on  the  disk
(remember  that  it  is  a physical I/O subsystem only), utility functions are
limited to those which are strictly physical in nature.

Utility  functions  are  controlled  either  at  the  local  terminal  or  the
pseudo-terminal.



1.3.3.7  Partitioning of I/O Responsibilities - 

The separation  of  the  I/O  subsystem  from  the  main  processor  causes  a
partitioning  of  responsibilities  between  host and controller which differs
from the traditional.



1.3.3.7.1  Error Handling - 

In conjunction with attached devices, the HSC50 performs all reasonable device
error  recovery actions automatically whenever a device error is detected.  If
an operation is reported to the host as unsuccessful, there is no  action  the
host  can  take  that  might  recover  the data via the current path where the
subsystem could not.  The only action a host should take after a  fatal  error
reported by the HSC50 is to attempt to recover the data through another access
path (if there is one).  The  HSC50  error  codes  will  indicate  whether  an
alternate path might be beneficial or whether it would be a waste of time.

Among the disk  error  recovery  actions  taken  by  the  controller  are  the
following:

     1.  Automatic correction of up to 8 errors (of up to  10  bits  each)  in
         each sector via the SDI ECC code.

     2.  Automatic retries of erroneous reads.

     3.  Automatic revectoring of bad blocks to their replacements.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 11
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


     4.  Automatic replacement of blocks that go bad due to wear.

     5.  Automatic detection and  recovery  of  mechanical  failures  such  as
         mis-seeks.

     6.  Automatic recovery from errors in the sector header.

     7.  Automatic power-fail recovery.

     8.  Automatic detection of subsystem internal data path errors.


Among the tape  error  recovery  actions  taken  by  the  controller  are  the
following:

     1.  Automatic power-fail recovery.

     2.  Automatic detection of subsystem internal data path errors.

     3.  Automatic retries of erroneous data operations.


Among the host interface error recovery actions taken by  the  controller  are
the following:

     1.  Automatic retransmission of data corrupted  during  transmission  (if
         detected).

     2.  Automatic retransmission on alternate host path (if any)  if  primary
         path fails.

     3.  Automatic power-fail recovery.

     4.  Automatic detection of subsystem internal data path errors.




1.3.3.7.2  Diagnostics - 

There are only two HSC50 diagnostics which run on the host processor;  a  host
interconnect test and a subsystem exerciser.  All other diagnostics execute in
the subsystem or drives.



1.3.3.7.3  Performance Optimizations - 

The HSC50 utilizes its  proximity  to  the  devices  it  controls  to  perform
multiple requests in a manner that optimizes AVERAGE throughput.  This is done
independently of the host (although a host can bypass or disable  it).   Among
the optimizations performed by the controller are:

     1.  Overlapped  Seeks.   Head  motion  on  multiple  disks   is   managed
         simultaneously by the subsystem.

     2.  Ordered Seeks.  Disk  head  motion  is  managed  in  a  fashion  that
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 12
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


         maximizes  average throughput.  This means that host requests are not
         necessarily performed in the order in which they are issued.

     3.  Multiple Data Channels.  The HSC50 allows for up to 6 data  channels,
         2  of  which  may transfer simultaneously for an aggregate of up to 6
         MB/sec instantaneous data transfer rate.

     4.  Data Channel Utilization Optimization.  The selection of which  drive
         transfers  next  is made based on their rotational positions relative
         to any requests outstanding.

     5.  Rotational Position Optimization.  Individual transfers  are  managed
         such  that  data  is  transferred  as soon as it comes underneath the
         heads, rather than waiting for the  first  block  of  a  request  and
         transferring  all  data in the request sequentially.  This means that
         hosts may not receive the data for any given  request  in  sequential
         order.

     6.  Interleaving of Normal I/O  with  Error  Recovery.   The  HSC50  will
         continue   to  process  requests  in  parallel  with  required  error
         recovery.   Only  requests  requiring   recovery   should   incur   a
         significant  performance  impact, unless an unusual type or number of
         errors impacts performance on a particular unit or on  the  subsystem
         as a whole.




1.3.3.8  High Availability - 

The HSC50 makes every attempt possible to  continue  to  service  the  host(s)
despite  failures  of HSC50 components.  There are three classes of failure in
the subsystem, each dealt with differently:

     1.  Certain failures (such as the failure of a drive or of a non-critical
         portion  of subsystem memory) can be accomodated by the subsystem via
         a dynamic "adjustment" of internal  parameters  around  the  failure.
         The subsystem automatically adjusts around such failures and notifies
         the host of the failed component.

     2.  More serious but still non-critical failures (such as  failure  of  a
         portion  of  subsystem  private  memory  or  failure  of  one  of the
         peripheral   interfaces)   are   accomodated   by    a    spontaneous
         reinitailization and reconfiguration of the subsystem.  The subsystem
         is unable  to  service  requests  while  the  reconfiguration  is  in
         progress,  but  once accomplished the subsystem is again available to
         service the host (with potentially  diminished  functionality  and/or
         performance).    Reconfiguration   time  is  approximately  equal  to
         subsystem bootstrap time.

     3.  There are certain components without which the HSC50 cannot run (such
         as   the  processor  and  the  host  interface).   Failure  of  these
         conponents will keep the subsystem out of  service  relative  to  the
         host.   The  subsystem  will  remain  available  for local diagnostic
         execution if the processor has not failed and  a  local  terminal  is
         available.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 13
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


2.0  Subsystem Architecture


Extensive architectural  documentation  exists  for  the  HSC50;   a  detailed
discussion   is   avoided   here.    See  the  references  for  more  detailed
architectural discussion.



2.1  Overview


The HSC50 is a collection  of  intelligent,  high-speed  peripheral  interface
units,  the  activity  of  which  is  orchestrated  by  a  PDP-11  I/O control
processor.  The peripheral interfaces (known as K.xxx) and the  I/O  processor
(known  as  P.ioc)  share  access  to  a common control memory and common data
memory.  It is primarily through shared data structures in the control  memory
that  the subsystem elements communicate with each other and are controlled by
the I/O control processor.



2.2  Functional Elements of the Subsystem


The HSC50 contains the following functional components:

     1.  I/O Control Processor (P.ioc)

         The P.ioc is the focal point of subsystem control and operation.   It
         has  a  local  connection  to  a  private  memory  that  contains the
         operational software.  The P.ioc is a  PDP-11  based  processor.   In
         addition   to  the  private  memory  interface,  the  P.ioc  contains
         interfaces to the TU58's, to a local terminal, and to  the  subsystem
         control and data memories.

     2.  Disk Interface (K.sdi)

         The  K.sdi  is  the  intelligent  SDI  disk  interface.   Driven   by
         horizontal  microcode  stored  in  a  local ROM, K.sdi transfers data
         between the data memory  and  disk,  and  implements  the  mechanisms
         necessary  in  support of the SDI protocol.  The actions of K.sdi are
         controlled by a series of data structures in  control  memory.   Each
         K.sdi serves as a single data channel to its attached drives.

     3.  Tape Interface (K.sti)

         The K.sti is the intelligent tape  interface.   It  is  identical  to
         K.sdi,  except  that  a different microprogram controls its activity.
         It transfers data between the data memory and  tape,  and  implements
         the  STI  protocol  mechanisms.   Each  K.sti serves as a single data
         channel to its attached formatters.

     4.  Host Interface (K.iccs)

         The  K.iccs  is  the  intelligent  host  interface.   Architecturally
         similar  to K.sdi and K.sti, it moves data between the host and HSC50
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 14
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


         data memory, and implements the mechanisms  necessary  for  the  host
         bus-level protocols.  It also is controlled by shared data structures
         in control memory.

     5.  Private Memory (M.priv)

         The private memory is a RAM memory  accessible  only  by  the  P.ioc.
         Functional  software  is  loaded into private memory from the TU58 at
         subsystem bootstrap time.

     6.  Control Memory (M.ctrl)

         The control memory is a high speed, interlockable  memory  accessible
         to the P.ioc and all the K's in the subsystem.  The control memory is
         initialized  and  set  up  by  the  P.ioc  to  contain  the   control
         information  which  will  drive  the  activities of the K's.  The K's
         operate on the entities in  control  memory  using  rigidly  defined,
         general  mechanisms;  all the policy level implementation is in P.ioc
         software.


     7.  Data Memory (M.data)

         Data memory is a high speed, non-interlockable memory  accessible  to
         the P.ioc and all the K's.  It is used for data buffers.

A simplified diagram of the HSC50 internal structure and connections follows:
 
                                                control bus
                =================================================
                    |    |              |          |        |
                    |    |              |   +-disk |        |
                    |    |              |   +-disk |     M.ctrl
        host        |    |            K.sdi-+-disk |
        bus         |    |              |   +-disk |
        <-------> K.iccs | +--terminal  |          |
                    |    | |            | tape-+   |
                    |  P.ioc--M.priv    | tape-+   |
                    |    | |            | tape-+-K.sti   M.data
                    |    | +--TU58      | tape-+   |        |
                    |    |              |          |        |
                =================================================
                                                data bus
 
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 15
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


3.0  Performance




3.1  Request Level Throughput


The following performance PROJECTIONS were obtained using a SIMULATION  model.
The  HSC50 architecture was modelled, and a request stream which represented a
typical VAX VMS request stream was input to the model.  In interpreting  these
results, it is important to understand the following:

     1.  The request length profile represents a "typical" length profile  for
         one  of  DEC's  operating  systems.   It  was obtained through actual
         measurement of the system in question.  However, the distribution  of
         requests  across the disk and the arrival rate were both random.  The
         simulation results will vary for other systems as a function of their
         request length profile.  The performance of the actual subsystem will
         also  vary  from  these  projections  as  a   function   of   request
         distribution and arrival rate.

     2.  The data does NOT represent the instantaneous maximum performance  of
         the  subsystem  under artificially optimal circumstances, NOR does is
         represent expected performance for request arrival rates  typical  of
         today's  host  systems.   Rather, it reflects the average performance
         over an extended period of time given  typical  host  request  length
         characteristics  and a sufficient request arrival rate to sustain the
         indicated throughput.  It is possible to exceed these  numbers  given
         artificially  large  numbers of large transfers on fast disks.  It is
         possible to fail to achieve these numbers given insufficient  request
         arrival rates.

     3.  The performance capabilities of the system are  affected  by  several
         external and configuration parameters.  Among these parameters are:

         1.  The number of disks and their distribution across data  channels.
             The  more  disks  and the more transfer channels, the more likely
             that one of the disks will be able to transfer at any  particular
             time.

         2.  The data rate of the disks.  The faster the data source, the more
             data that can be moved per unit time.

         3.  The amount of buffer and control memory  in  the  subsystem.   If
             either  memory  is small enough, the subsystem loses considerable
             time  starved  for  memory  resources.   As  memory   is   added,
             throughput  improves  until  a  point  is  reached where there is
             usually spare memory around.  At this  point,  additional  memory
             only marginally improves average throughput.

         4.  The  bandwidth  of  the  host  interconnect.    If   interconnect
             bandwidth  is lower than the average disk data rate, it becomes a
             limit on subsystem throughput.

         The data supplied below varies the number and data rates of the disks
         to give a feel for the impact of these parameters.  The data given is
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 16
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


         limited to 8 drives;  for more than  8  drives,  the  performance  is
         expected  to  approximate  that  for  8 drives with some improvement,
         especially for slow data-rate disks.  The  usable  bandwidth  of  the
         host   interconnect   was   kept   constant   at   2.5  MB/sec.   The
         requests/second and sectors/second figures are given as  a  range  of
         numbers.   The  range  encompasses a range of HSC50 data memory sizes
         from 16KB to 128KB.

     4.  The data below is normalized for an average request latency of 500ms.
         This  is  equivalent to the average latency measured at the operating
         system-to-driver interface in an optimized I/O system.


The parameters which defined the locality of the host I/O request stream are:

     1.  the "on-cylinder" probability,

     2.  the "read" (vs.  "write") probability, and

     3.  the request-size profile.


For all simulations in this study, the above parameters were  constants.   The
constants were derived from statistical analyses of VAX VMS trace tapes.

The host-request constants were as follows:

     1.  The "on-cylinder" probability was 0.1.

     2.  The "read" probability was 0.77.

     3.  The VMS request-size profile was  that  described  in  the  following
         table.

 
        length of request       probability of occurrence
        (number of sectors)
        -------------------     -------------------------
 
                1                       .49
                2                       .11
                3-5                     .11
                6-10                    .06
                11-28                   .03
                29-33                   .05
                34-73                   .05
                127                     .10
 
Weighted Average Size of VMS Disk Transfer = 19.3 sectors

The rate at which host I/O requests arrive at the subsystem was also an  input
parameter  for the simulations.  Experimentally, the arrival rate was "pushed"
up  to  the  overload  point  and  then  "backed  down"  until  the  simulated
architecture  could keep pace with it.  In this fashion the maximum achievable
throughput was determined.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 17
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


 
               PROJECTED (BY SIMULATION)
               SUSTAINED THROUGHPUT (VMS)
        for normalized request latencies (500 ms.)
 
        speed of  |# of |avg sectors!avg requests!
        disks     |disks|per second ! per second !
        ----------+-----+-----------+------------+
        1.1 MB/sec|   2 |   1119    |     58     |
        ----------+-----+-----------+------------+
        1.1 MB/sec|   4 |   1390    |     72     |
        ----------+-----+-----------+------------+
        1.1 MB/sec|   8 | 2548-2895 |  132-150   |
        ----------+-----+-----------+------------+
        3.0 MB/sec|   2 | 1505-1640 |   78-85    |
        ----------+-----+-----------+------------+
        3.0 MB/sec|   4 | 2316-2567 |  120-133   |
        ----------+-----+-----------+------------+
        3.0 MB/sec|   8 | 3358-4516 |  174-234   |
        ----------+-----+-----------+------------+
 



3.2  Host Bus Burst Data Bandwidth


The HSC50 is internally  limited  to  a  sustainable  bandwidth  on  the  host
interconnect of 6 MB/sec.

HSC50 is limited by the ICCS to an average bandwidth on a lightly loaded  ICCS
bus of approximately 2 MB/sec.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 18
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


4.0  Host Interface




4.1  Hardware Interconnect (ICCS)


The HSC50 will conform to the ICCS standard interfaces  as  defined  by  "ICCS
Link  Functional  and  Interface  Specification"  (Buzynski, Oct 79) and "ICCS
Architecture Specification" (Casabona, Aug 79) with the  following  exceptions
and clarifications:

     1.  HSC50 will support either 512 or 576 (data) bytes per  ICCS  transfer
         on  a  unit-by-unit basis.  Which mode a particular transfer operates
         in is determined by the format of the disk pack currently mounted  on
         the  unit.   An  error  will be returned if the ICCS data packet size
         differs from the disk sector size.

     2.  All HSC50's will support two ICCS data paths, although only one  path
         can  support a transfer attempt at any instant.  HSC50 will support a
         single-path host node.

     3.  HSC50  will  power-up  in  the  "uninitialized  (without  maintenance
         enabled)"   state  until  the  initialization  process  is  complete.
         Thereafter, it will be in the "enabled  (with  maintenance  enabled)"
         state  supporting  'Request  ID',  'Reset'  and 'Reqmadr' maintenance
         packets only.




4.2  Software Interconnects (Port Driver and Class Driver)




4.2.1  Port Interconnect - 

The HSC50 port interfaces to the host "port driver" using  the  standard  port
driver  interface  as  defined by "tbd(Gardner)" with the following exceptions
and clarifications:

     1.  tbd(Gardner)




4.2.2  Class Driver Interconnect - 

The HSC50 interfaces to the  host  "class  driver"  using  the  MSCP  standard
protocol  as  defined by "Mass Storage Control Protocol" (Gardner, 10-Dec-79))
with the following exceptions and clarifications:

     1.  The HSC50 does NOT support the DOWNLINE LOAD command.

     2.  The HSC50 does support auto-replacement, shadowing, 576 byte  format,
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 19
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


         and the ERASE command.

     3.  The HSC50 supports the PSEUDO-TERMINAL  command  with  the  following
         restrictions:

         1.  The HSC50  is  not  a  multi-user  interactive  computer  system;
             rather   it   is   a   controller  that  has  the  capability  to
             synchronously dialogue with one input stream at a time.  In light
             of this, the following approach is taken regarding terminal input
             access control from multiple hosts and the local terminal:

             1.  While a diagnostic or utility program is running,  access  is
                 restricted  to  the local terminal or the host from which the
                 original command  was  received.   Attempts  to  access  from
                 another  host  (or the local terminal if a pseudo-terminal is
                 active) will result in an error.

             2.  A host or the local terminal may obtain exclusive  access  to
                 the input stream via the SET TERMINAL BUSY operation, and may
                 release it for use by others  via  the  SET  TERMINAL  NOBUSY
                 operation.   While  SET TERMINAL BUSY is in effect, all input
                 from any source other than the  owning  source  is  rejected,
                 regardless  of whether or not a utility or diagnostic program
                 is running.

             3.  If the controller leaves the controller-online state relative
                 to a host that controls input stream access, the input stream
                 is automatically set not-busy.


         2.  Each PSEUDO-TERMINAL packet must contain a complete  line  of  no
             more than 30 characters terminated by a CRLF pair (for a total of
             32 input bytes), 30 characters terminated by a CR (for a total of
             31  input  bytes),  or a single control character (for a total of
             one input byte).  The HSC50 terminates on CR and  ignores  LF  on
             input.    Input   bytes   beyond   those  accounted  for  in  the
             PSEUDO-TERMINAL count byte are ignored.  Each packet  is  assumed
             to  contain  a  complete  and  distinct  line or a single control
             character.

         3.  Each pseudo-terminal END packet from the controller will  contain
             a  complete line of output of no more than 30 printing characters
             with up to two imbedded non-printing characters (for a  total  of
             32  data bytes).  The HSC50 supplies terminators and line control
             characters as appropriate;  if  the  host  program  reflects  the
             characters  on  the  terminal  exactly  as they are received, the
             desired effect will be achieved.

         4.  The only non-printing characters  legal  in  the  PSEUDO-TERMINAL
             input  data are CTRL/C, CTRL/Z, CTRL/X, SP, CR and LF.  All other
             non-printing characters are ignored.

         5.  The pseudo-terminal is activated by receipt of a  PSEUDO-TERMINAL
             packet  with  a  CTRL/C  as  the  first and only character in the
             packet.  If the pseudo-terminal is available, the controller will
             respond  with  a prompt message and request for input.  If access
             to the input stream is denied,  the  initiating  packet  will  be
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 20
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


             rejected  with  an error.  All PSEUDO-TERMINAL packets other than
             one containing CTRL/C sent while the pseudo-terminal is  inactive
             will be rejected.

         6.  While the pseudo-terminal is active, the host is required to have
             a  PSEUDO-TERMINAL command pending at all times to receive output
             (unless the last END packet requested input).  If  the  last  END
             received  did  not  request input, a null PSEUDO-TERMINAL command
             must be generated immediately to receive the next line of  output
             from  the  controller.  If the last END packet did request input,
             the  input  should  be  collected  and   placed   in   the   next
             PSEUDO-TERMINAL packet before it is sent.

         7.  PSEUDO-TERMINAL dialogues are timed.  If the HSC50 must wait more
             than  5  minutes  for a PSEUDO-TERMINAL packet during a dialogue,
             the running program aborts and the input stream is  automatically
             set not-busy.

         8.  Receipt of a PSEUDO-TERMINAL command other than CTRL/X while  one
             is  pending  will  cause  the new one to be rejected.  Receipt of
             CTRL/X while a previous PSEUDO-TERMINAL command is  pending  will
             cause  the  HSC50  to send an END packet for the previous with an
             appropriate message, followed by an END packet for the CTRL/X.

         9.  The last message output by all HSC50 programs is a single message
             of the form:
              
                pnam>EXIT<CR><LF>

             The reception of this message by the host should  be  interpreted
             as  a  signal  that  the pseudo-terminal dialogue is complete and
             should  cause  the  host  to   refrain   from   sending   further
             PSEUDO-TERMINAL  commands  associated  with this dialogue.  After
             receipt of this message, the pseudo-terminal must be  reactivated
             as discussed above.

         10. There is no way to generate a BREAK character  or  dialogue  with
             micro-ODT from the pseudo-terminal.

         With the  exception  of  the  above  and  the  inability  to  receive
         spontaneous report messages, the pseudo-terminal has the same command
         repertoire and dialogue characteristics as the local terminal.

     4.  The FLUSH command is a NOP and the cache modifiers are ignored in the
         first release.  

     5.  The HSC50 issues a REINITIALIZED attention  message  to  all  enabled
         hosts  whenever  it  makes the transition to the controller-available
         state, whether spontaneous or forced.

     6.  The  "error  dependent  information"  in  HSC50  error  log  messages
         contains the ASCII error report equivalent to that typed on the local
         terminal (if there is one).  This report is  in  the  standard  error
         report  format  for  the HSC50, ready for display.  It is recommended
         that any error log analysis program for the HSC50 provide a means for
         the ready display of the ASCII portion of HSC50 error log messages.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 21
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


     7.  HSC50 conditionally logs  the  following  information  for  units  in
         service:

         1.  Every uncorrectable error.

         2.  Every  correctable   error   that   exceeds   a   device-specific
             "significance threshold".

         3.  Every state transition of the subsystem as a whole (such as every
             hard re-initialize).

         4.  Every SPONTANEOUS state transition of any subsystem unit.

         5.  Every execution of an automatically-triggered diagnostic.


     8.  The HSC50 supports the following flags, modifiers, and status codes:

         1.  tbd(Gardner)
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 22
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


5.0  Human Interface


This section describes the GENERIC interface to the  subsystem  at  the  front
panel, and at the local terminal and pseudo-terminal.



5.1  Front Panel Buttons


As shown below, the HSC50 has the following illuminable buttons:
 
          white         red         white        white        white
        +-------+    +-------+    +-------+    +-------+    +-------+
        !       !    !       !    !       !    !       !    !       !
        ! INIT  !    ! FAULT !    !ONLINE !    ! blank !    ! blank !
        !       !    !       !    !       !    !       !    !       !
        +-------+    +-------+    +-------+    +-------+    +-------+
        momentary    momentary     in/out       in/out       in/out
         contact      contact      switch       switch       switch
         switch       switch

     1.  INIT

         This is a momentary contact switch, the depression  of  which  causes
         the controller to reboot and reinitialize as if it were being powered
         up for the  first  time.   When  lit,  it  indicates  that  subsystem
         initialization  is underway.  While the INIT switch is depressed, all
         other panel lights are lit as a lamp test.

     2.  FAULT

         This is a red momentary contact switch  which,  when  lit,  signifies
         that  a  significant  hardware  failure  has been detected inside the
         subsystem.  The subsystem may or may not continue running  when  this
         switch  is lit.  Depressing this switch once will display a blinking,
         5-bit binary code in the panel lights describing which component  has
         failed  (if  any).   Depressing  this switch a second time causes the
         fault light to go off if the subsystem continues running and  returns
         the  other  lights  to  their  normal function.  The fault light will
         remain off in this instance unless a new failure or another occurance
         of the original failure is detected.  If a major failure prevents the
         subsystem from operating, the  fault  light  remains  lit  after  the
         switch is depressed the second time.


     3.  OFFLINE

         This is an in/out two position switch which  serves  to  isolate  the
         HSC50 from the host interconnect.  If the switch is out, the HSC50 is
         disconnected from the host interconnect and the light is out.  If the
         switch  is in, the host interconnect path is enabled and the light is
         on if the controller is operating and available to service hosts over
         the  specified  path.  The light will be off if the controller is not
         functioning, or is offline for diagnostic purposes.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 23
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


     4.  blank

         These are in/out two position switches.  In the first release of  the
         HSC50,  the  position of these switches is ignored (they are reserved
         for future use), and the light is used only  as  part  of  the  fault
         display (see above).




5.2  Access Control Switch


The HSC50 front panel has a 5-position key switch which controls the operation
of  the front panel switches and the local terminal and pseudo-terminal.  This
switch provides a signal to an external unit (such as a DIANA box) to indicate
permission  that  it  may switch between the local TU58 and terminal lines and
remote lines.

It is intended that when in the LOCAL position, the local  TU58  and  terminal
lines are active and the external unit (if any) prevents itself from accessing
the subsystem.  When in the REMOTE position, the local TU58 and terminal lines
remain active unless and until the external unit intervenes and switches these
lines to remote use.  Note that if a subsystem has no external line  switching
unit, there is no distinction between the LOCAL and REMOTE positions.

When the switch is in an  ENABLE  position,  full  privilege  is  granted  the
terminals  and front panel switches.  When in a DISABLE position, terminal and
front panel operations  are  restricted  to  those  that  do  not  impact  the
operation of the subsystem.

The five positions and their function (going clockwise from the left) are:

     1.  OFF

         When the switch is in this position, the HSC50 is powered down.

     2.  LOCAL DISABLE

         When in this position, the HSC50 is powered up but terminal  commands
         and front panel buttons that effect processor operation are disabled.
         In addition, HALT instructions executed by the P.ioc trap rather than
         entering  micro-ODT.   Terminal  operations  and  front  panel button
         operations   which   interrogate   status   continue   to    operate.
         Specifically:

         1.  The BREAK function on the local terminal is disabled.  The  HSC50
             processor cannot be halted.

         2.  The INIT and OFFLINE front panel buttons are disabled  and  their
             alteration will not be recognized by the system.

         3.  "SHOW" is the only local program that can be  executed  from  the
             local terminal or pseudo-terminal.

         4.  The FAULT button will be enabled, and depressing it will  display
             the fault code.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 24
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L



         Basically, the operator may interrogate the  subsystem  but  may  not
         alter its operation.

     3.  LOCAL ENABLE

         When  the  switch  is  in  this   position,   all   local   terminal,
         pseudo-terminal,  and  front  panel operations are enabled, and their
         activation will be recognized by the  subsystem.   HALT  instructions
         executed by the P.ioc will enter micro-ODT.  Specifically:

         1.  The BREAK function is enabled and will halt the processor.

         2.  The  INIT  and  OFFLINE  panel  buttons  are  enabled  and  their
             alteration will be recognized.

         3.  All local diagnostic and utility programs can  be  executed  from
             the local terminal and pseudo-terminal.

         Basically, the operator has complete control over the subsystem.

     4.  REMOTE DISABLE

         When the switch is in this position, the operation of  the  subsystem
         is  identical  to  LOCAL  DISABLE  except  that  control of the local
         terminal and TU58 lines by an external unit is possible.

     5.  REMOTE ENABLE

         When the switch is in this position, the operation of  the  subsystem
         is  identical  to  LOCAL  ENABLE  except  that  control  of the local
         terminal and TU58 lines by an external unit is possible.




5.3  Cassette Load Device


The HSC50 has two TU58 drives, labelled Unit 0 and Unit 1.  Tapes are  mounted
and dismounted from these units in the standard fashion.

The subsystem  is  shipped  with  several  pre-recorded  cassettes.   Two  are
labelled  "HSC50 SYSTEM CASSETTE", and are identical copies of each other (one
for backup  in  case  the  first  is  accidentally  destroyed).   The  "system
cassette"  contains  the software necessary for normal subsystem operation and
automatic diagnosis, and it is from these  cassettes  that  the  subsystem  is
bootstrapped.   The  remaining  tapes  are labelled "HSC50 DIAGNOSTIC CASSETTE
#n", and these tapes contain diagnostic and utility programs.  These cassettes
are mounted as necessary when programs they contain are to run.

Whenever the subsystem is running, a "system cassette" must be mounted  (write
enabled)  in  the  unit from which the subsystem was bootstrapped.  Removal of
the  system  tape  from  a  running  system  will   reduce   the   subsystem's
functionality  and jeopardize the subsystem's ability to recover properly from
hardware errors.  An error message will result from removal of the system tape
from a running subsystem.  Unit 0 is usually reserved for the system tape.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 25
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


Unit 1 is used as a backup bootstrap unit if Unit 0 is down, as  a  means  for
making  backup  copies  of  distributed  cassettes, and as the unit from which
online diagnostics and utility functions can be loaded.  The cassette in  Unit
1  is usually changed as the result of direction from a program running in the
subsystem.

HSC50 cassettes are recorded in RT11 file format.  Any system supporting  RT11
format  TU58's  (RT-11 itself, RSX and VMS FLX, RSTS FIT) may be used to copy,
list the directory of, dump, or otherwise manipulate these tapes.



5.4  Local Terminal


The HSC50 has a standard RS-232-C/RS-423 compatible  ASCII  port  to  which  a
terminal can be connected for the purposes of controlling local diagnostic and
utility execution.  This port is capable  of  running  at  300  or  9600  baud
(switch selectable).

It is intended that HSC50 spares kits will be equipped with a small,  portable
ASCII  terminal  (known  as  the  "diagnostic  keypad") consisting of an ASCII
keypad and an alphanumeric display.  It is also intended that this keypad will
also  be an option that can be purchased by the customer.  The exact nature of
the diagnostic keypad  is  still  under  investigation;   the  HSC50  will  be
programmed to accept any dumb ASCII keypad of any display width.

If a local terminal is present, all errors  and  other  significant  subsystem
activities  will  be  reported  on the local terminal as well as logged to the
host error log.  In addition, the local terminal can be  used  to  interrogate
subsystem status and control subsystem local functions.

The HSC50 is programmed such that it will support any ASCII terminal connected
to  its  local  port.   It  is  possible  to  connect  any compatible video or
hard-copy terminal to the HSC50.  Installations  which  choose  to  utilize  a
local terminal will realize the following benefits:

     1.  All errors detected by the subsystem will  be  output  to  the  local
         terminal  as  well  as  logged  to the host.  If the terminal is hard
         copy, this provides an error logging capability that  is  independent
         of the host.

     2.  It will be possible to execute diagnostics and obtain detailed  error
         reports  even  when  the  host  interface  or  certain other critical
         components are down.  This  will  provide  more  information  in  the
         initial  problem  call  to  field service, and should shorten MTTR in
         these cases.


Note that if an HSC50 has a local terminal, it or the pseudo-terminal  may  be
active, but not both at the same time.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 26
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


5.4.1  Local Terminal Operation - 

The local terminal has the following operational characteristics:

     1.  The HSC50 is programmed  to  support  a  minimal  keypad  capable  of
         displaying only a few characters at a time and without hard copy.  In
         addition, it compatibly supports more powerful terminals.  To achieve
         this, the HSC50 interface has the following attributes:

         1.  There is  a  settable  HSC50  parameter  describing  whether  the
             terminal  has a minimal display or whether it is to be treated as
             a normal terminal.

         2.  When in minimal display mode, the HSC50 "remembers" the  last  10
             lines   output.   As  new  lines  are  output,  the  "oldest"  is
             forgotten.  The "current" line is the line being  displayed,  and
             may differ from the "newest" line in some cases.

         3.  When in minimal display  mode,  certain  control  characters  are
             interpreted  by  the  HSC50 as "keypad display control commands",
             and can be used to cause the HSC50 to redisplay text that is part
             of the set of remembered lines.


     2.  The HSC50 will  refuse  input  (except  for  the  control  characters
         described  below)  unless  there  is  an  outstanding  request from a
         program running in the HSC50 (signalled to the user by an appropriate
         prompt).   Input refusal is indicated by ringing the bell.  The HSC50
         will also refuse input other than control characters and DELETE  when
         the  input line exceeds 30 characters.  In this latter case, the bell
         is also rung to signal that the input limit has been exceeded.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 27
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


The HSC50 terminal interface supports the following control functions:
 
 Char.  Code                     Effect
----------------------------------------------------------------------
CTRL/C  003     Alert the HSC50 to accept a new command. Echoes as "^C".
                The HSC50 responds with a command prompt or with a suitable
                error message. CTRL/C performs an implicit CTRL/Q.
----------------------------------------------------------------------
DELETE  177     Erase the last character entered. Echoes as
                "backslash, character, backslash" on a hard copy
                terminal. Echoes as "backspace, space, backspace" if
                SET TERMINAL SCOPE is in effect.
                Echoes as a redisplay of the
                input line less the deleted character if
                SET TERMINAL KEYPAD is in effect.
----------------------------------------------------------------------
CTRL/O  017     Discard all output till the next input operation
                or CTRL/O is again typed. Echoes as "^O".
----------------------------------------------------------------------
CTRL/U  025     Erase all input characters (if any). Echoes
                with "^U" and repeats the current prompt (if any).
----------------------------------------------------------------------
CTRL/R  022     Re-output the current line. Echoes with "^R"
                and repeats the current line.
----------------------------------------------------------------------
CTRL/S  023     Stop output.
----------------------------------------------------------------------
CTRL/Q  021     Resume output.
----------------------------------------------------------------------
CTRL/E  005     Change current line to "next" line in set of
                lines currently remembered and redisplay it. If newest line
                already current line, the command is ignored.
                Ignored if SET TERMINAL KEYPAD not in effect.
----------------------------------------------------------------------
CTRL/F  006     Change current line to "previous" line in set
                of lines currently remembered and redisplay it. If oldest
                line already current line, the command is ignored.
                Ignored if SET TERMINAL KEYPAD not in effect.
----------------------------------------------------------------------
CTRL/A  001     Increase the speed of output by one unit. If
                output is already at maximum rate, the
                command is ignored.
                Ignored if SET TERMINAL KEYPAD not in effect.
----------------------------------------------------------------------
CTRL/B  002     Decrease the speed of output by one unit. If
                output is already at minimum rate, the
                command is ignored.
                Ignored if SET TERMINAL KEYPAD not in effect.
----------------------------------------------------------------------
CTRL/Z  032     Erase all input characters (if any) and
                signal "end of dialogue-default remaining input" to
                program. Echoes as "^Z".
----------------------------------------------------------------------
CTRL/X  030     Erase all input characters (if any) and abort the
                program currently running. Echoes as "^X".
----------------------------------------------------------------------
 
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 28
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


With the exception of TAB, all other non-printing characters are ignored.  TAB
is echoed as a single space.

Any printing character will have one of two effects:

     1.  If the HSC50 was not waiting for input, the character is ignored, the
         bell is rung, and no output is generated.

     2.  If the HSC50 was waiting for input, the new character is echoed.   If
         SET  TERMINAL  KEYPAD is in effect, the newest line is redisplayed if
         it is not the current display line.




5.5  Pseudo-Terminal


The HSC50 allows the host to pass  ASCII  characters  to  the  controller  and
receive  output  characters  from  the controller via the PSEUDO-TERMINAL MSCP
command.  Because MSCP is involved, the pseudo-terminal can only be used  when
the subsystem is running and the host interface is working correctly.

The subsystem directs the dialogue for and the output  of  any  diagnostic  or
utility  program  to  the  pseudo-terminal  if  and  only  if that program was
initiated at the pseudo-terminal.  Spontaneous output (such as error  log  and
other  system status information) is never sent to the pseudo-terminal;  it is
always sent to the host log.  A host program that wishes to  emulate  a  local
terminal   completely   must   therefore   monitor  both  the  error  log  and
pseudo-terminal message streams.

It is expected that host support of the pseudo-terminal will usually involve a
simple utility that accepts input from a user terminal and transmits it to the
controller, and accepts output from the controller and prints it on  the  user
terminal.  See Section 4 and the MSCP specification for more detail.



5.6  Operational Procedures




5.6.1  Bootstrapping the Subsystem - 

The subsystem is bootstrapped from a cold start  according  to  the  following
procedure:

     1.  A copy of the cassette labelled "HSC50 SYSTEM CASSETTE"  is  inserted
         into Unit 0.

     2.  The INIT button on the front panel is  momentarily  depressed.   When
         the INIT button is depressed, all the front panel lights will be lit,
         serving as both a lamp test and notification that the INIT  has  been
         recognized.   When  the  INIT  button is released, all lights will be
         extinguished and the initialization sequence will begin.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 29
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


     3.  The P.ioc will be tested from a diagnostic  ROM.   If  the  processor
         fails its minimal test, it will halt and all lights will remain out.

     4.  If the main processor passes its minimal  integrity  test,  the  INIT
         light   will  be  lit  and  remain  lit  for  the  remainder  of  the
         initialization process.  The INIT light should  come  on  within  one
         second after the INIT button is released.

     5.  When the  subsystem  initialization  sequence  is  complete  and  the
         subsystem  is  running,  the  INIT light will be extinguished and all
         other panel lights revert to their  normal  usage.   In  addition,  a
         message  will  be displayed on the local terminal (if any) and logged
         to the host announcing successful startup and  identifying  the  tape
         unit  from  which  the  subsystem  was  booted.   The  initialization
         sequence may take a few minutes to complete.

     6.  If for any reason the initialization sequence  cannot  be  completed,
         the  INIT light will be extinguished and the FAULT light will be lit.
         If sufficient software has been loaded,the  local  terminal  will  be
         used  to  report  the  nature  of  the  problem.   In  all cases, the
         subsystem will then allow the FAULT switch to be used in  the  normal
         fashion  to  display  the  failure  code,  but  will  permit no other
         activity.  INIT is used to restart the sequence when the problem  has
         been corrected.


The subsystem bootstrap  code  first  verifies  the  subsystem  processor  and
attempts  to  begin  loading off TU58 Unit 0.  If Unit 0 is inoperable or does
not contain a system cassette, the bootstrap then tries Unit 1.   Finally,  it
attempts to boot over the local terminal line if all else fails.

If the bootstrap succeeds, the system cassette from which  the  subsystem  was
bootstrapped  must remain mounted.  If the subsystem was bootstrapped over the
local terminal line, local terminal functions as disabled.

If the bootstrap fails, a system cassette should be inserted in Unit 1 and the
bootstrap attempt should be repeated.



5.6.2  Local Terminal and Pseudo-terminal Command Syntax - 

The command language at the local terminal and pseudo-terminal is designed  to
be simple and culturally compatible with other diagnostic implementations.

The local terminal and pseudo-terminal are always in one of two modes:  active
or inactive.

In inactive  mode,  the  local  terminal  responds  only  to  certain  control
characters.   The  operator  may  examine  the  contents of the current output
buffer if SET TERMINAL KEYPAD is in effect, but may not enter new information.
In  inactive  mode,  the  pseudo-terminal responds to nothing.  Both the local
terminal and pseudo-terminal are changed to active mode by the CTRL/C  control
function.

In active mode, either terminal may be used to dialogue with and  display  the
output  of  a  diagnostic  or  utility program running in the subsystem.  Each
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 30
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


input line is preceded by a prompt for the appropriate information.  Each  new
group  of  output  lines  contains  the  program  identifier  as the first few
characters on the first line.

Except for certain control functions, terminal input will be refused  when  in
active  mode  if  there is no active request for input.  With the exception of
certain control functions, all input  to  the  subsystem  must  be  solicited.
There is no such thing as unsolicited input or type-ahead.

The terminals remain in active  mode  until  the  utility  or  the  diagnostic
program exits, signalled by a final output line of the form:
 
        pnam>DONE

The HSC50 is capable of running only one diagnostic or utility  program  at  a
time,  so the local terminal and pseudo-terminal can only ever "talk" with one
program at a time.  On the pseudo-terminal, all I/O will  be  associated  with
the  program.  On the local terminal, it is possible for spontaneous error log
and other system messages to be interspersed with  program  output,  but  this
will  be  done  in  such  a  way that the source of each line of output can be
easily identified.  Once a terminal is active and talking to a program,  there
are only three ways to free the terminal for use with another program:

     1.  The program terminates naturally.

     2.  The program is aborted by the arrival of an CTRL/X character from the
         invoking terminal.

     3.  The program terminates because the terminal timeout has expired.




5.6.2.1  Program Input - 

In response to CTRL/C, the HSC50 prompts with a display of the form:
 
        COMMAND:
 
and waits for input.  Legal responses are  any  valid  HSC50  command.   Valid
HSC50 commands are:

     1.  the name of a diagnostic or utility program.   The  valid  diagnostic
         and utility programs are described in Section 9.


When a valid command  has  been  entered,  the  HSC50  then  prompts  for  the
arguments required by that command:
 
        prompt (form) [default]?
          .
          .
        prompt (form) [default]?
 
Although prompts are program specific, they follow a  standard  general  form.
The  information needed is identified, followed in parentheses by the form the
entry should take (A = alphanumeric input, D  =  decimal  number,  O  =  octal
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 31
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


number, H = hex number, U = unit identifier, Y/N = yes/no), followed in square
brackets by the default (if any).  If there is no default, the square brackets
will be empty.  The prompts issued by and the input arguments required by each
program are described in Section 9.  The default may be selected by entering a
null  line  (just CR).  The default for this input and any remaining inputs in
the dialogue may be selected by  entering  CTRL/Z.   If  any  entries  in  the
dialogue  are not defaultable, CTRL/Z defaults up to that undefaultable entry,
at which point the dialogue reverts to normal.  Alphanumeric responses may  be
abbreviated to any number of characters that makes the response unique.

Unit identifiers are of the standard form "Dnnn" for disk and "Tnnn" for  tape
where nnn is a decimal number from 0 to 255.

The HSC50 will only wait for input for 5 minutes.  If no input is received  in
that  time,  the running program aborts and an error message is displayed.  An
active pseudo-terminal will automatically  be  disconnected  if  there  is  no
activity  for  5 minutes or if the controller leaves the online state relative
to the host.

When the last argument has been entered, the program  acknowledges  successful
initiation  of  the  operation  with  appropriate  output.   If  there  is  no
appropriate immediate output, the program prints a message of the form:
 
        operation STARTED

If the operator wishes to terminate a dialogue, he  enters  the  XIT  (CTRL/X)
command function.  This is acknowledged by the message
 
        pname>EXIT
 
and the terminal returns to inactive mode.

Rather than enter each command and argument on a separate line,  the  operator
has the option of entering one or more aruments on the same line, separated by
commas.  If the operator specifies one or more arguments in the command  line,
or  specifies  multiple  arguments  in response to the prompt for a particular
argument, the arguments entered are used to satisfy subsequent inquiries,  and
the  prompts  for  the  satisfied  arguments  will  not  appear.  Defaults are
selected with two consecutive commas.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 32
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


For example, the following dialogues are all equivalent (assuming the  default
for START ADDR (MAX) is 100000, PATTERN is 5 and ITERATIONS is 1):
 
1)      COMMAND: CMEM
        START ADDR (O) [MAX]? 100000
        PATTERN (D) [5]? 5
        ITERATIONS(D) [1]? 1
 
2)      COMMAND: CMEM 100000
        PATTERN(D) [5]? 5
        ITERATIONS (D) [1]? 1
 
3)      COMMAND: CMEM 100000,5
        ITERATIONS(D) [1]? 1
 
4)      COMMAND: CMEM
        START ADDR (O) [MAX]? 100000,5,1
 
5)      COMMAND: CMEM 100000
        PATTERN (D) [5]? 5,1
 
6)      COMMAND: CMEM 100000,5,1
 
7)      COMMAND: CMEM 100000,,1
 
8)      COMMAND: CMEM ,,,
 
9)      COMMAND: CMEM
        START ADDR (O) [MAX]? 100000
        PATTERN (D) [5]? ^Z
 
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 33
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


5.6.2.2  Program Output - 

The first line of each distinct "message" output from  any  HSC50  program  is
preceded by an identifier of the form "name>", where "name" is the name of the
program generating the output.  Programs generate output as  appropriate,  and
tend to generate it in groups of related lines.

If the operator wishes to terminate a program that is  outputting,  he  enters
XIT (CTRL/X), and the program will terminate.

An example of a simple  dialogue  that  executes  a  diagnostic  program  that
outputs  the  result  immediately follows (see Section 9.2 for a definition of
the fields in the standard diagnostic output format):
 
        [CMD(CTRL/C)]
        COMMAND: CMEM                   (invoke diagnostic program "CMEM")
        START ADDR (O) [MAX]?100000     (supply necessary parameters)
        ITERATIONS (D) [1]? 1
        CMEM>13:47 T#002 E#045 U-CMEM   (CMEM output starts)
        WRITE ERRS 10000-11000
        FRU1-xxxxxx FRU2-yyyyyy  
        CMEM>EXIT                       (CMEM execution complete)
 
An example of a dialogue that initiates an exerciser that does
not respond immediately follows:
 
        [CMD(CTRL/C)]
        COMMAND: EX1                    (invoke diagnostic program "EX1)
        ITERATIONS (D) [1]?3            (supply necessary parameters)   
        EX1 STARTED                     (initiation acknowledged)
        EX1 >13:47 T#001 E#    U-D0     (EX1 output starts)
        PASS 1 - NO ERRORS
        EX1 >13:55 T#001 E#    U-D0     (EX1 outputs again)
        PASS 2 - NO ERRORS
        EX1 >14:05 T#001 E#    U-D0     (EX1 outputs last time)
        PASS 3 - NO ERRORS
        EX1 >EXIT                       (EX1 completion)
 
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 34
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


6.0  Disk Interface (SDI)


The HSC50 will conform to the DEC Standard Disk Interface as defined  in  "DEC
Standard  Disk  Interface"  (Bean, 3-Jan-80) with the following exceptions and
clarifications:

     1.  The host activity timeout period will be 10 seconds.   If  the  HSC50
         does not hear from any host in 10 seconds, it will react to a "verify
         connection" attention condition from a drive by releasing  the  drive
         to the available state.


\Issue:Do we need to reflect operator activity at the drive switches  all  the
way back to the host before taking any action?\
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 35
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


7.0  Tape Interface (STI)


The HSC50 will conform to the DEC Serial Tape Interface  as  defined  in  "DEC
Serial  tape  Interface"  (to-be-published)  with the following exceptions and
clarifications:

     1.  tbd(McCarthy)
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 36
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


8.0  Physical Characteristics




8.1  Module Definitions


The HSC50 has 5 components which are combined to yield the desired  functional
and  performance  characteristics.   Each  component  is  one or more standard
extended hex modules and plugs into the HSC50 backplane.



8.1.1  P.ioc (I/O Control Processor) - 

The P.ioc is one extended-hex  board  which  contains  the  subsystem  control
processor.   One  P.ioc  board  is  required in each HSC50.  More than 1 P.ioc
board is not supported in the HSC50 first release.



8.1.2  M.std1 and M.std2 (Memory, versions 1 and 2) - 

The M.std boards contain private, control and data memories.  Each board is  a
single extended hex module.  There are two variations of the M.std board:

     1.  M.std1 is a partially populated board and contains 64 KB  of  private
         memory, 16 KB of control memory, and 16 KB of data memory.

     2.  M.std2 is a fully populated board  and  contains  64  KB  of  private
         memory, 32 KB of control memory, and 64 KB of data memory.

One M.std board is required  in  each  HSC50.   Additional  M.std  boards  are
optional  up  to  the  limits specified by the configuration rules in the next
section.  Any arbitrary mix of M.std1 and M.std2 boards may be used.



8.1.3  K.iccs (ICCS Control) - 

K.iccs is three extended-hex boards which contain  the  ICCS  link,  the  ICCS
packet  buffers,  and  the  HSC50 port interface to the rest of the subsystem.
Each K.iccs supports two data paths to the host.

One K.iccs is required in each HSC50.  Additional K.iccs  components  are  not
supported in HSC50.



8.1.4  K.sdi (Standard Disk Interface Control) - 

K.sdi is one extended-hex board which interfaces the subsystem to up  to  four
SDI  disk drives.  Each K.sdi provides a separate "data channel" to its drives
which is independent of any other K.sdi or K.sti components in the subsystem.

No K.sdi components are required in the HSC50 if there are no SDI disk drives.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 37
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


One  K.sdi  is  required for every four SDI disk drives to be supported, up to
the configuration limits specified in the next section.  It  is  not  required
that all SDI connections on each K.sdi be utilized.



8.1.5  K.sti (Standard Tape Interface Control) - 

K.sti is one extended-hex board which interfaces the subsystem to up  to  four
STI  tape  formatters  and  their  associated  drives.   Each K.sti provides a
separate "data channel" to its drives which is independent of any other  K.sdi
or K.sti components in the subsystem.

No K.sti components are required in the HSC50 if there are no STI tape drives.
One  K.sti  is required for every four STI tape formatters to be supported, up
to the configuration limits specified in the next section.  It is not required
that all STI connections on each K.sti be utilized.



8.2  Configuration




8.2.1  Configuration Rules and Limits - 

The allowable  combinations  of  the  above  components  are  limited  by  the
following:

     1.  A total of nine "bus drops"  are  allowed  in  the  subsystem.   Each
         component  (P.ioc,  M.std, K.iccs, K.sdi and K.sti) requires one "bus
         drop" for each copy of the component in  the  subsystem.   Since  one
         copy  each  of  P.ioc,  K.iccs,  and  M.std  are  required  in  every
         subsystem, and P.ioc and K.iccs are limited to one  copy  each,  this
         leaves   six  "bus  drops"  for  optional  M.std,  K.sdi,  and  K.sti
         components.

     2.  Support for tape or more than 8 disk drives requires more memory than
         that available on the M.std1 board.  Such systems must therefore have
         at least one M.std2 or two M.std1 boards.




8.2.2  Configuration Considerations - 

The following considerations figure into configuration decisions:

     1.  Maximum numbers of drives are supported by utilizing all SDI  or  STI
         connections  on each K.sdi or K.sti component.  Because each K.sdi or
         K.sti can only access one drive at a time,  however,  the  number  of
         drives  that can be simultaneously accessed are limited to the number
         of channels present.  Performance is  improved  by  adding  a  second
         channel  and  my distributing drive connections across those channels
         to maximize utilization.  In redundant  configurations,  the  primary
         paths should be distributed across channels rather than concentrating
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 38
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


         the primary paths on one channel and the backup paths  on  a  second.
         Additional guidelines will be published at a later date.

     2.  Reliability is improved if certain  components  are  replicated.   If
         multiple  M.std  boards  are  present, the subsystem will continue to
         operate until the last one fails.  If multiple K.sdi or K.sti  boards
         are  present,  failure of a given interface affects only those drives
         connected to it.

     3.  Under certain conditions, performance improves as  memory  is  added.
         Guidelines will be published at a later date.

     4.  There is only one subsystem  topology  that  maximizes  availability.
         This  topology  has two paths to every device and two copies of every
         item of logical information on separate devices.  There is no  single
         point   of  failure.   No  other  subsystem  configuration  maximizes
         availability.

 
             host                     host
              | |                      | |
        ------+-|----+-----------------+-|---+-----------
                |    |     ICCS          |   |
        --------+----|-+-----------------+---|-+---------
                     | |                     | |
                    HSC50                   HSC50
                     | |                     | |
                     | +------ drive --------+ |
                     |                         |
                     +-------- drive ----------+
 



8.2.3  Typical Configurations - 

Examples of three HSC50 packages which meet "typical" needs are the following:

     1.  Entry Level Disk-only Subsystem

         The  minimum  cost  disk-only  subsystem   contains   the   following
         components.  It supports up to 4 disk drives.
          
                1 P.ioc
                1 K.iccs
                1 M.std1
                1 K.sdi connected to up to 4 disk drives

     2.  Average Disk and Tape Subsystem

         The average cost disk  and  tape  subsystem  contains  the  following
         components.  It supports up to 8 disk drives and 4 tape formatters.
          
                1 P.ioc
                1 K.iccs
                1 M.std2
                2 K.sdi connected to up to 8 disk drives
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 39
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


                1 K.sti connected to up to 4 tape formatters

     3.  "Disk/Tape Farm" Subsystem

         The "disk/tape farm" subsystem contains the following components.  It
         supports  the  maximum number of disk drives and tape formatters (24)
         which may be divided into disk drives and tape formatters at any unit
         of 4 boundary.
          
                1 P.ioc
                1 K.iccs
                1 M.std2
                6 K.sdi/K.sti each connected to up to 4 drives or formatters

The reliability of the above systems can be improved by:

     1.  Using 2 M.std1 boards in place of 1 M.std2 board if  sufficient  "bus
         drops" exist.

The performance of the above systems can be improved by:

     1.  Adding memory according to the guidelines (to be published).

     2.  Reducing the ratio of  drives/formatters  to  K.sdi/K.sti  interfaces
         according to the guidelines (to be published).
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 40
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


8.3  Packaging




8.3.1  Cabinet - 

The HSC50 is housed in a separate, standalone H9642 "Cross  Products"  cabinet
with the following dimensions:
 
        Width = 21.25 in. [53.98 cm.]
        Depth = 30.0 in. [76.2 cm.]
        Height = 41.62 in. [105.71 cm.]
        Front door swing radius = 18.56 in. [47.14 cm.];
                                         pivot point 1.56 in. [3.96 cm.] from
                                         left side of cabinet
        Rear door swing radius = 18.56 in. [47.14 cm.];
                                         pivot point 1.56 in. [3.96 cm.] from
                                         right side of cabinet
        Maximum door swing approximately 120 degrees

The HSC50 itself occupies the lower 2/3 of the  cabinet;   the  upper  1/3  is
available  to  hold  a  suitable disk drive (such as an RA80).  When the HSC50
itself is maximally configured but the upper 1/3 is empty, the cabinet  weighs
tbd(Clark) pounds.



8.3.1.1  Cabinet Exterior - 

The cabinet has metallic skins on the  left  and  right  side,  a  full-height
removable  access  door in the back, and a 2/3 height removable access door in
the front.  An optional cosmetic cover is available for the upper 1/3  of  the
cabinet front in the event that the upper space is unoccupied by a drive.

The front door allows operator  access  (without  opening  the  door)  to  the
operator control panel.  This panel includes the TU58 drives, a 5-position key
switch, the front panel control buttons, and  an  optional  ASCII  keypad  and
display  (the  diagnostic  keypad).   If the optional diagnostic keypad is not
present, suitable cosmetic  treatment  is  given  to  the  space  it  normally
occupies.

The nature of the control buttons, 5-position key switch, and diagnostic panel
are discussed in detail in Section 5.

Peripheral cables (SDI, STI, ICCS cables) enter from the back of the cabinet.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 41
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


                            HSC50 CABINET (front)

























                                TO BE SUPPLIED
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 42
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


8.3.1.2  Cabinet Interior - 

The HSC50 cabinet contains a 14 slot card cage capable of  holding  up  to  14
extended hex boards.  Two modules are slot-specific;  the P.ioc must be in the
rightmost card insertion slot, and the K.iccs  link  module  must  be  in  the
leftmost card insertion slot.  The remaining modules may be placed anywhere in
the cage.

The card cage sits on the front left side of  the  cabinet.   The  cabinet  is
powered  using  a modified 869-type or 861-type power controller (in the rear)
and the MPS "Modular Power Supply" (on the front bottom right).

Behind the front door near the operator panel is a  plug  for  the  EIA  local
terminal  connection.   This  plug  is not accessable from the operator panel;
the front door must be opened for access.

Access for HSC50 and MPS module service is from the front.

Access for peripheral cable connections is  from  the  back.   All  peripheral
cables  plug  into  and  terminate at a bulkhead connector accessible from the
rear.  Smaller cables connect from the bulkhead  to  pins  on  the  backplane;
there  are no peripheral cable connections directly to any boards.  Peripheral
cables can be plugged into and removed from the bulkhead while  the  HSC50  is
operating  without  disturbing  the  operation  of  the rest of the subsystem.
Sufficient  bulkhead-to-backplane  connectors  are  installed  to  cover   all
peripheral ports for each K as the K is installed.

\The inclusion of a DIANA-box interface inside the cabinet is  being  studied.
It is not committed.\




8.3.2  Environment - 

The HSC50 is a Class B device (as defined by DEC Std 102).

It has a noise level of tbd(Clark).

Cooling air enters the cabinet at the bottom front and exhausts in the rear at
a  height  approximately  2/3  of  the cabinet height.  Air flow required is a
minimum of 350 CFM and is driven by 3 fans (two for the card cage and one  for
the power supply).

The power supply delivers up to 2500 watts.

Specific DC power available from the power supply is as follows:
 
        +5V @ tbd(Blackledge) A
        +12V @ tbd(Blackledge) A
        -4.5V @ tbd(Blackledge) A
        -5.2V @ tbd(Blackledge) A

AC input power requirements are:
 
        Domestic:       220V, 60Hz, 3 phase, tbd(Blackledge) VA
        Foreign:        250V, 50Hz, 3 phase, tbd(Blackledge) VA
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 43
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


HSC50 power requirements will be approximately balanced over all  three  input
phases.   The  inclusion of a drive in the upper 1/3 of the cabinet will cause
an imbalance in one phase according to the power requirements of that drive.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 44
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.0  Programs That Execute in the Subsystem


Following are summary descriptions of  each  of  the  utility  and  diagnostic
programs executable in the subsystem.  The name used to invoke the program and
to identify program output  is  shown  in  parentheses  following  the  formal
program name.  The input prompts and a brief description are included for each
program.

Note  that  in  addition  to  these  explicit  utilities,  there  are  certain
additional  utility-like functions performed in support of MSCP functions such
as shadowing.  See the MSCP document fro a discussion of these operations.



9.1  Utility Functions




9.1.1  Subsystem Crash Dump (CDMP) - 

Input Parameters:
 
        None

Under certain circumstances, a dump of memory contents will  be  important  to
analysis  of  complicated software or hardware problems being encountered at a
particular installation.  For this purpose, a program is provided which  dumps
memory onto a TU58 for forwarding to DEC.

The program  will  be  executed  automatically  by  the  subsystem  after  the
appropriate  internal  parameter  has been set (see below).  This parameter is
usually set under field or remote diagnosis direction.

CDMP requires that a TU58 drive other than the drive from which the  subsystem
was booted be dedicated to the automatic dump facility while it is enabled.  A
scratch cassette must be mounted at all times while the facility is enabled.

\Issue:  The current plan is to write a dump analysis program in a  high-level
language for execution on machines available at our support facilities.  There
is a potential need to be able to do dump analysis at customer sites.   Should
the dump analysis program run on the HSC50?\



9.1.2  Subsystem Parameter Alteration (SET) - 

Input Parameters:
 
        OPTION (A) []?                  (name of parameter to be changed)
            option-specific prompt      (some options prompt for specific
                                         values, such as unit numbers)
        NEW VALUE (x) [y]?              (new value for option. Form and
                                         default vary with option)
                .
                .                       (repeat until "EXIT" entered)
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 45
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


        OPTION (A) []?EXIT

This utility program is used  to  alter  the  operational  parameters  of  the
subsystem.   Some  of  these  parameters  are also settable via the MSCP SYNCH
command;  those are marked with an asterisk.  The set  of  legal  options  and
their values are:
 
        AUTODUMP tu58-unit ENABLE/DISABLE
                                        enables/disables automatic dump
                                        facility on specified TU58 drive
 
        CONTROLLER ONLINE/OFFLINE       makes controller
                                        available/unavailable
                                        to service host requests
 
     *  DAYTIME dd-mmm-yy hh:mm         alters date and time
 
        DISK unit ONLINE/OFFLINE        makes specified disk unit 
                                        available/unavailable to host
 
        TAPE unit ONLINE/OFFLINE        makes specified tape formatter/drive
                                        pair available/unavailable to host
 
        HOST host-id path-id ENABLE/DISABLE
                                        enables/disables access to specified
                                        host on the specified ICCS path
 
        K k-slot-number ENABLE/DISABLE  enables/disables a specific K and
                                        all drives connected to it
 
        INTERCONNECT k-slot-number interconnect-number ENABLE/DISABLE
                                        enables/disables a specific SDI or
                                        STI interconnect on a specific K 
 
        THRESHOLD threshold-id value    sets named diagnostic threshold to
                                        specified value.
 
        SECTORSIZE 512/576              enables/disables the processing of
                                        disks with 576 byte sectors.
 
        mmmmmm nnnnnn                   changes the contents of physical
                                        location "mmmmmm" to "nnnnnn"
 
        TERMINAL BUSY/NOBUSY            disables/enables public access to
                                        local and pseudo-terminals
 
        TERMINAL SCOPE/NOSCOPE          describes terminal as soft or
                                        hard copy
 
        TERMINAL KEYPAD/NOKEYPAD        describes terminal as minimal ASCII
                                        keypad requiring display control or
                                        as "normal" terminal

With the exception of the DAYTIME and memory location change options,  changes
in  any of these parameters are permanent.  The specified values are retained,
even across subsystem reinitialization, until they are changed by a subsequent
SET operation or the system cassette is changed to a different system cassette
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 46
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


and the subsystem is rebooted.

SET reports any error conditions detected, gives the user a chance to  recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.



9.1.3  Subsystem Parameter Interrogation (SHOW) - 

Input Parameters:
 
        OPTION (A) []?                  (name of parameter to be displayed)
            option-specific prompt      (some options prompt for specific
                                         arguments, such as unit numbers)
            current value(s)            (current values are displayed in
                                         option-specific format)
                .
                .                       (repeat until "EXIT" entered)
        OPTION (A) []?EXIT

This utility program is used to display  the  current  values  of  operational
parameters of the subsystem.  The set of legal options is:
 
        AUTODUMP                        displays enabled/disabled state of
                                        automatic dump facility
 
        CONFIGURATION                   displays which boards are in the
                                        subsystem, which backplane slots they
                                        occupy, which drives are connected to
                                        which K boards, and which SDI or STI
                                        interconnect on each K board each
                                        drive is connected to
 
        CONTROLLER                      displays controller state relative to
                                        enabled hosts
 
        DAYTIME                         displays current date and time
 
        DISK unit                       displays disk state relative to host
                                        and relative to controller
 
        TAPE unit                       displays tape formatter/drive pair
                                        state relative to host
                                        and relative to controller
 
        ERRORS unit                     displays contents of error table for
                                        specified unit
 
        HOST host-id                    displays enabled/disabled status of
                                        specified host path(s)
 
        K k-slot-number                 displays enabled/disabled status of
                                        specified K
 
        LOG unit                        displays the "log control flags" in
                                        effect for the specified unit
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 47
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


 
        INTERCONNECT k-slot-number interconnect-number
                                        displays enabled/disabled status of
                                        specified SDI or STI interconnect on
                                        specified K             
 
        THRESHOLD threshold-id          displays value of specified
                                        diagnostic threshold
 
        nnnnnn                          displays the current contents of
                                        controller physical location "nnnnnn"
 
        SECTORSIZE                      displays the current disk sector
                                        size parameters
 
        TERMINAL                        displays the current terminal status
                                        and parameters

All values displayed are those at the time of  the  inquiry.   Certain  values
(such  as  ERRORS,  DAYTIME,  and  specific  location contents) are subject to
constant change and will vary as a function of subsystem activity.

Most of the SHOW options will accept the argument "ALL" in place of a specific
id  or  unit field.  In this instance, the entire set of applicable parameters
will be displayed.

SHOW reports any erroneous commands detected and gives the user  a  chance  to
recover.



9.1.4  TU58 Duplication (T58C) - 

Input Parameters:
 
        SOURCE TU58 UNIT (D) []?
        TARGET TU58 UNIT (D) []?
        FULL VERIFICATION (Y/N) [Y]?
        UNIT target
         ARE YOU SURE (Y/N) []?

This utility program  is  used  to  make  copies  of  the  distributed  system
cassettes.   It provides a means for the installation to make backup copies of
the distributed system, and  to  make  copies  of  cassettes  prior  to  their
alteration by TPAT (see below).

T58C requires two operational TU58 drives.  Since there are only two drives on
the  subsystem, the "SYSTEM CASSETTE" will be unavailable to the subsystem and
may  have  to  be  removed  for  the  duration  of  the  copy,  limiting   the
functionality of the subsystem.  When the copy is finished, restoration of the
system cassette restores full functionality.

T58C reports any error conditions detected, gives the user a chance to recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 48
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.1.5  TU58 Patch (TPAT) - 

Input Parameters:
 
        TU58 UNIT (D) []?
        FILE NAME (A) []?
        UNIT number FILE name
         ARE YOU SURE (Y/N) []?
        BASE ADDR (O) [0]?
        ADDR (O) [0]?                   (address of location to modify)
        CONTENTS (O) [nnnnnn]?          (nnnnnn = current contents)
        ADDR (O) [yyyyyy]?              (yyyyyy = last address modified +2)
        CONTENTS (O) [nnnnnn]?
                .
                .                       (repeat until "EXIT" entered)
        ADDR (O) [yyyyyy]? EXIT
        PATCH CHECKSUM (O)?             (checksum to validate input stream)

This utility program modifies the contents of a specific file on  one  of  the
system cassettes, and is used to install patches in HSC50 functional, utility,
or diagnostic software.  The patch dialogue is "checksummed" and the  checksum
is  validated  before  the  patch  is actually affected.  This prevents typing
errors from resulting in bad patches.

The file name entered is a standard RT11 file name of the form "filnam.ext".

It is expected that this program will be used only when so  directed  by  DEC,
and  that such direction will take the form of "menus" describing exactly what
is to be entered.  Note  that  an  "auto-patch"  facility  is  not  current;ly
planned  because  a  revised  TU58  that  includes  the  patch  is  as easy to
distribute as any "auto-patch" cassette.

TPAT reports any error conditions detected, gives the user a chance to recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.



9.1.6  Offline Disk Volume Copy (DCPY) - 

Input Parameters:
 
        SOURCE DISK UNIT (U) []?
        TARGET DISK UNIT (U) []?
        FULL VERIFICATION (Y/N) [N]?
        FAST COPY (Y/N) [N]?
        UNIT target
         ARE YOU SURE (Y/N) []?

This utility program makes an image of one disk onto another.  Both disks must
be  of the same type and both units must be offline to the host.  The complete
LBN space of the source disk is copied to the LBN space of  the  target  disk,
and  any necessary bad block replacements on the target disk are automatically
performed.

Selection of FAST COPY causes the subsystem to give resource priority  to  the
copy  program,  causing  a  serious  degradation  of  subsystem performance on
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 49
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


regular host requests but minimizing copy  time.   Selection  of  "slow  copy"
causes  the  system  to minimize the perfomance impact on normal requests with
the result that the copy will take considerably longer.

DCPY reports any error conditions detected, gives the user a chance to recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.  It also reminds  the  user  that  the  unit  remains
offline on completion.



9.1.7  Offline Disk-to-Tape Volume Copy (BCKP) - 

Input Parameters:
 
        SOURCE DISK UNIT (U) []?
        TARGET TAPE UNIT (U) []?
        TARGET TAPE UNIT (U) []?
                .
                .                       (repeated until null response)
        TARGET TAPE UNIT (U) []?
        FULL VERIFICATION (Y/N) [N]?
        FAST BACKUP (Y/N) [N]?
        UNIT(S) target,target,...,target
         ARE YOU SURE (Y/N) []?

This utility function performs a physical backup of the entire  LBN  space  of
the  specified disk onto magtape.  All units must be offline to the host.  The
complete LBN space of the disk is imaged onto the tape independent of any file
structure in use on the disk.  Tapes are automatically labelled by the utility
using ANSI label format.  Each  volume  contains  a  single  file  of  \tbd\KB
records  containing  the  sector  images.   The  volume  and  file  labels are
constructed from the current date and time in the controller and the  sequence
number of the volume in the set of volumes necessary to back up the disk.  See
Appendix B for the volume and file label format.

When additional volumes are required to accomodate the disk, BCKP  checks  the
next target unit in the sequence to see if a tape is mounted.  If so, the tape
is used.  If not, BCKP requests that a new volume be mounted.
 
        BCKP>MOUNT ANOTHER BLANK TAPE
        ON TAPE UNIT target []?

Selection of FAST BACKUP causes the subsystem to give resource priority to the
backup  program,  causing  a  serious  degradation of subsystem performance on
regular host requests but minimizing backup time.  Selection of "slow  backup"
causes  the  system  to minimize the perfomance impact on normal requests with
the result that the backup will take considerably longer.

BCKP reports any error conditions detected, gives the user a chance to recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.  It also reminds  the  user  that  the  units  remain
offline on completion.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 50
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.1.8  Offline Tape-to-Disk Volume Restore (RSTO) - 

Input Parameters:
 
        SOURCE TAPE UNIT (U) []?
        SOURCE TAPE UNIT (U) []?
                .
                .                       (repeated until null response)
        SOURCE TAPE UNIT (U) []?
        TARGET DISK UNIT (U) []?
        FULL VERIFICATION (Y/N) [N]?
        FAST RESTORE (Y/N) [N]?
        UNIT target
         ARE YOU SURE (Y/N) []?

This utility function restores the entire LBN space of the specified disk from
the  magtapes  created  by the BCKP utility.  All units must be offline to the
host.  The  complete  LBN  space  of  the  disk  is  restored  from  the  tape
independent  of  any  file structure in use on the disk.  Tape volume and file
labels are automatically checked to make certain that the tapes  were  created
by an HSC50 from a disk of type identical to the one being restored.

Multiple tape volumes must be mounted in sequence;   the  proper  sequence  is
enforced by the controller.  When the next volume is required, RSTO checks the
next source unit in sequence to determine if the proper tape is  mounted.   If
so,  it is used.  If not, RSTO requests that the proper tape be mounted on the
proper unit.
 
        RSTO>MOUNT TAPE tape-id
        ON TAPE UNIT source []?

Selection of FAST RESTORE causes the subsystem to give  resource  priority  to
the restore program, causing a serious degradation of subsystem performance on
regular host  requests  but  minimizing  restore  time.   Selection  of  "slow
restore"  causes  the  system  to  minimize  the  perfomance  impact on normal
requests with the result that the restore will take considerably longer.

RSTO reports any error conditions detected, gives the user a chance to recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.  It also reminds  the  user  that  the  units  remain
offline on completion.



9.1.9  Offline Disk Formatter (DFMT) - 

Input Parameters:
 
        DISK UNIT (U) []?
        SECTOR SIZE (D) [512]?
        FULL VERIFICATION (Y/N) [N]?
        RETAIN PREVIOUS
         REPLACEMENTS (Y/N) [N]?
        FAST FORMAT (Y/N) [N]?
        UNIT target
         ARE YOU SURE (Y/N) [N]?
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 51
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


This utility function  reformats  the  specified  disk  unit,  destroying  the
previous  contents.  During the reformatting process it automatically replaces
any bad sectors encountered, resulting  in  a  logically  perfect  disk.   The
specified  disk  unit must be offline to the host.  It outputs the identity of
bad sectors discovered and replaced, the identity of bad headers  encountered,
and the additional capacity available for future replacement.

Selection of FAST FORMAT causes the subsystem to give resource priority to the
format  program,  causing  a  serious  degradation of subsystem performance on
regular host requests but minimizing  formatting  time.   Selection  of  "slow
format" causes the system to minimize the perfomance impact on normal requests
with the the result that the formatting will take considerably longer.

FMAT reports any error conditions detected, gives the user a chance to recover
if  possible,  and  reports  successful  or  unsuccessful  completion  of  the
operation when finished.  It also reminds  the  user  that  the  unit  remains
offline on completion.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 52
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2  Diagnostics




9.2.1  F-11 micro-ODT - 

The P.ioc implements the standard F-11 micro-ODT for use by  FE's  and  remote
diagnostics.  When the HSC50 is in LOCAL ENABLE or REMOTE ENABLE mode, receipt
of a BREAK on the local terminal line or execution of a HALT instruction  will
cause micro-ODT to execute.



9.2.2  Diagnostic Output - 

Diagnostics generate output under the following conditions:

     1.  Continuously scheduled diagnostics that discover  significant  errors
         report   them.    They   DO   NOT   report  each  execution  that  is
         insignificant.

     2.  Any diagnostic that is explicitly invoked reports the result  to  the
         invoking terminal, whether an error is detected or not.

     3.  Any diagnostic that is automatically invoked  reports  to  the  local
         terminal  (if  present)  and generates a log message whether an error
         was detected or not.


Error information and diagnostic  results  are  reported  both  on  the  local
terminal and in log packets in the following standard format:
         
        pnam>hh:mm T#ddd E#ddd U-addd           (mandatory)
          error description                     (mandatory if error detected)
        FRU1-aaaaaa FRU2-aaaaaa                 (optional)
        MA- media address                       (optional)
        EXP- expected results                   (optional)
        ACT- actual results                     (optional)
          program specific info                 (optional)
          program specific info                 (optional)
          program specific info                 (optional)
          program specific info                 (optional)
         
        where:
                hh:mm   = time in 24-hour format
                d       = decimal digit
                a       = alphanumeric character
                T#      = "test number"
                E#      = "error number"
                U       = "unit"
                FRU     = "field replaceable unit"

The lines marked "mandatory" are present in every diagnostic report and  error
message.   Those  marked  optional are present only when appropriate, but when
present, are present in the order indicated.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 53
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2.3  Diagnostic Arguments - 

Several diagnostics (such as the inline  K.sdi  diagnostic)  require  a  "slot
number" as an input parameter that specifies which of multiple incarnations of
the board in question is to be diagnosed.  The "slot  number"  corresponds  to
the  backplane  slot  (numbered  right to left) that the board occupies.  This
information can be obtained without opening the cabinet via the  CONFIGURATION
option to the SHOW program described previously.  All diagnostics that require
"slot number" arguments verify that the specified slot contains a board of the
proper type before beginning.



9.2.4  Continuously Scheduled Diagnostics - 

Certain diagnostic routines will be loaded as part of  the  normal  functional
software  image.  These routines will be executed more or less continuously in
whatever spare time the processor  has  left  over  from  its  normal  request
processing  needs.   These  routines are coded so they can perform their tasks
with minimal impact on the performance of normal operations.  Among the duties
performed by the continuously scheduled diagnostics are:

     1.  K.sdi, K.sti, and K.iccs integrity verification.

     2.  Buffer memory and data bus integrity verification.

     3.  Control memory and control bus integrity verification.

     4.  SDI, STI and ICCS verification.


These diagnostics are only visible to the  outside  world  when  and  if  they
uncover  a problem.  At that point they report the problem and trigger further
diagnosis or appropriate subsystem reaction.  They run  without  any  operator
input.

For more information on the continuously scheduled diagnostics, see  Reference
12.



9.2.5  Initialization Diagnostics - 

Initialization diagnostics are those diagnostics that are executed during  the
subsystem  bootstrap/reinitialization  process.   With  the exception of BPIO,
they may also be executed via terminal command if the subsystem is offline.



9.2.5.1  Initialization P.ioc Test (BPIO) - 

Input Parameters:
 
        none

The BPIO diagnostic is resident in the P.ioc  ROM  and  is  executed  on  each
subsystem  initialize,  power-up,  or  programmed  entry  into  the proper ROM
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 54
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


location.  The program consists of three tests:

     1.    F-11 Test

         This phase tests a  subset  of  the  F-11  instruction  set  and  the
         addressing  modes  used in the loading and execution of the remainder
         of the tests.

     2.    Private Memory Test

         This phase tests the private F-11 memory that is required in the next
         tests.    The   tests   consist  of  address  verification  and  data
         reliability tests.

     3.    TU58 Test

         This phase tests the functionality of the data and  control  path  to
         the  TU58.  It also tests the ability of the device to perform simple
         position commands and data reads.




9.2.5.2  Initialization F-11 Test (BF11) - 

Input Parameters:
 
         none

This program tests the full F-11 instruction set, addressing  modes,  extended
instruction set, control memory windows, and memory management.  It also tests
the interrupt and vectoring and  verifies  the  F-11's  abililty  to  properly
detect  and  indicate  errors.  This test is much the same as the offline F-11
test and may be an abbreviated version or a quick pass of that test.



9.2.5.3  Initialization Control Memory Test (BCM) - 

Input Parameters:
 
        none

This program performs a quick verification of data and addressing integrity in
control  memory.   It  also  forces  data parity errors and verifies the error
detection mechanism.



9.2.5.4  Initializaton K.sdi Test (BKDI) - 

Input Parameters:
 
        none

The K.sdi resident diagnostic is totally contained in the K.sdi  ROM.   It  is
initiated by a signal over the control bus.  It reports success as appropriate
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 55
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


status in control memory or failure through a dedicated location  in  the  I/O
page.   Portions  of  the  resident code can be initiated on command to K.sdi.
The basic test sequence for K.sdi includes the following:

     1.  Microprocessor instruction set and addressing tests

     2.  ROM tests (sequencer, checksum, parity, etc)

     3.  Drive interface test

     4.  SERDES and RSGEN tests




9.2.5.5  Initializaton K.sti Test (BKTI) - 

Input Parameters:
 
        none

The K.sti resident diagnostic is totally contained in the K.sti  ROM.   It  is
initiated by a signal over the control bus.  It reports success as appropriate
status in control memory or failure through a dedicated location  in  the  I/O
page.   Portions  of  the  resident code can be initiated on command to K.sti.
The basic test sequence for K.sti includes the following:

     1.  Microprocessor instruction set and addressing tests

     2.  ROM tests (sequencer, checksum, parity, etc)

     3.  Formatter interface test




9.2.5.6  Initialization K.iccs Test (BKCI) - 

Input Parameters:
 
        none

The K.iccs resident diagnostic is totally contained in the K.iccs ROM.  It  is
initiated by a signal over the control bus.  It reports success as appropriate
status in control memory or failure through a dedicated location  in  the  I/O
page.   Portions  of  the resident code can be initiated on command to K.iccs.
The basic test sequence for K.iccs includes the following:

     1.  Microprocessor instruction set and addressing tests

     2.  ROM tests (sequencer, checksum, parity, etc)

     3.  Host interface test
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 56
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2.5.7  Initialization Buffer Memory Test (BBM) - 

Input Parameters:
 
        none

This  test  performs  a  quick  verification  of  the  data   and   addressing
capabilities  of  Data Memory.  Data parity errors are forced and parity error
detection is checked.



9.2.5.8  Initialization Quick-verify Functional Test (BFQV) - 

Input Parameters:
 
        none

This test will route test operations  through  the  subsystem  to  verify  the
correct  operation  of  the  P.ioc and K's.  It will test the operation of the
various  transmission  queues,  counters,  and  buffer  manipulation  in   the
hardware/software interface.  It will test the proper operation of hardware in
terms of data transfers and interrupts.  The control and  data  path  to  each
drive will be tested.



9.2.6  OFFLINE DIAGNOSTICS - 

Offline diagnostics  are  those  diagnostics  other  than  the  initialization
diagnostics  that  execute  when  the  subsystem  is offline to the host.  The
requirement that a diagnostic  executes  offline  arises  because  either  the
resource  being  diagnosed is critical to subsystem operation or the amount or
type of subsystem resources needed to run a particular diagnostic is such that
subsystem operation cannot continue.



9.2.6.1  Offline F-11 Test (OF11) - 

Input Parameters:
 
        ITERATIONS (D) [1]?

This test is a comprehensive diagnostic for the F-11.  It includes testing the
entire  instruction  set,  the extended instruction set, all addressing modes,
all error detection, interrupts, traps, vectors, control memory  windows,  and
memory management.  Existing F-11 diagnostics will be adapted for this task.



9.2.6.2  Offline Private Memory Test (OPM) - 

Input Parameters:
 
        START ADDR (O) [0]?
        END ADDR (O) [MAX]?
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 57
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


        ITERATIONS (D) [1]?

This test will fully test the F-11 private memory.  It  will  use  worst  case
data  and  addressing patterns as stimuli with the expected result of locating
any failing or sensitive bits  or  locations.   The  test  will  identify  the
failures over an address range.  Failure identification capabilities are to be
more precisely specified when the memory test has been designed.  The test  is
also required to throughly test all parity bits and error detection features.



9.2.6.3  Offline Control Memory Test (OCM) - 

Input Parameters:
 
        START ADDR (O) [0]?
        END ADDR (O) [MAX]?
        ITERATIONS (D) [1]?

This test has the same functions as those described for  the  private  memory.
In  addition,  this test will fully test the control bus data, addressing, and
parity capabilities.  It will also test the memory access paths from all K's.



9.2.6.4  Offline Buffer Memory Test (OBM) - 

Input Parameters:
 
        START ADDR (O) [0]?
        END ADDR (O) [MAX]?
        ITERATIONS (D) [1]?

This test has the same functions as  those  described  for  the  other  memory
tests.   It  has  the  same  responsibilities  relative to the data bus as the
Offline Control Memory Test test has for the control bus.  It will  also  test
the memory access paths from all K's.



9.2.6.5  Offline K.iccs Test (OKCI) - 

Input Parameters:
 
        TEST NUMBER (D) []?
        ITERATIONS (D) [1]?

This test will initiate a resident K.iccs diagnostic, monitor the result,  and
execute a series of normal K.iccs operations, including loopback from the ICCS
star coupler.  The K.iccs must be dedicated to this operation, which  requires
that the subsystem be offline for the duration.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 58
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2.6.6  Offline Internal Bus Test (OIBT) - 

Input Parameters:
 
        ITERATIONS (D) [1]?

These tests will test for  interaction  between  the  P.ioc  and  K's  in  the
subsystem.  Four tests are required.  They are:

     1.  P.ioc with K.iccs

     2.  P.ioc with K.sdi

     3.  P.ioc with K.sti

     4.  P.ioc with K.iccs with K.sdi with K.sti

The interactions tested will be for memory contention (both control and data),
bus  contention  (both  control  and  data), interrupt interaction, and proper
usage and control of queue pointers and counters.



9.2.6.7  Offline Multi-drive Exerciser (OMDE) - 

Input Parameters:
 
        NUMBER OF DRIVES (D) []?        (Number of drives in test)
 
        DRIVE UNIT NUMBER (U) []?       (Specify first drive)
        CHANGE DRIVE PARAM (Y/N) [N]?   (Do  you  want  to  change
                                        the paramterers  for this
                                        drive?)
            READ ONLY (Y/N) [N]?
            WRITE ONLY (Y/N) [N]?
            WRITE CHECK (Y/N) [N]?
                CHECK ALL WRITES (Y/N) [N]?     (Write chk on all writes)
            DATA COMPARE (Y/N) [N]?     (No will  per-
                                        form limited compare. Yes
                                        will compare all data.)
            CHANGE TEST AREA (Y/N) [N]? (Normal testing is done in
                                        Diagnostic Blocks.)
                OUTSIDE DIAG CYL (Y/N) [N]? (Yes enables writes
                                                 outside Diag Cyl.)
                    ARE YOU SURE (Y/N) [N]?
                        START BLOCK NUM (D) []?
                        END BLOCK NUM (D) []?
 
        DRIVE UNIT NUMBER (U) [N]?      (2nd drive to be tested.)
                .                       (Repeat  drive   specific
                .                       inputs for this  and  remainder
                .                       of drives to be tested.)
 
        WRITE BEFORE TEST (Y/N) [N]?    
        DATA PER PASS-MBITS (D) [1]? 
        ERROR LIMIT (D) [20]?
        RETRY/CORRECTION (Y/N) [Y]?
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 59
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


        ENABLE ERROR LOG (Y/N) [N]?
        ITERATIONS (D) [1]?

The multi-drive exerciser will exercise from 1 to n (where n  is  the  maximum
drives  on  the  subsystem)  disk  and tape drives.  The exercise will be of a
random nature with respect to drive sequence,  data  patterns,  and  operation
sequences.   Errors  will  be reported on a functional level, i.e.  no failure
analysis or identification will be attempted.  Operations and errors  will  be
counted   for  statistical  reporting.   Full  subsystem  error  handling  and
correcting facilities will be employed.  In short, this exerciser will  be  of
the  traditional  variety except that it will be subsystem resident as opposed
to host resident.



9.2.6.8  Offline System Functional Verification (OSFV) - 

Input Parameters:
 
        ITERATIONS (D) [1]?

The purpose of functional verification is to test the subsystem  functionality
in  normal  and  special  cases.   This test will generate activity within the
subsystem    to    verify    correct    operation    of    routing,     buffer
allocation/deallocation,  request block generation/retiring, optimization, and
other subsystem mechanisms.  It will generate (or simulate) very high activity
levels  that  will  cause  buffer shortages, high error handling requirements,
overflowing error thresholds, etc.  It will  cause  (or  simulate)  all  error
types  to  verify  proper  error  processing.   It  is  the intent to test all
possible route, data path, error path, and process linkages.



9.2.7  INLINE DIAGNOSTICS - 

Inline diagnostics are those diagnostics that execute in the  subsystem  while
the  subsystem  is  online  to  the  host.   The  subsystem  may be performing
functional operations while these diagnostics are executing but the  subsystem
resource being diagnosed cannot be in use;  it is dedicated to diagnosis.  The
inline diagnostic may need other resources from the  subsystem,  but  it  will
compete  with  other  processes  performing  functional  operations for use of
shared resources.



9.2.7.1  Inline TU58 Test (IT58) - 

Input Parameters:
 
        TU58 UNIT (D) []?
        ITERATIONS (D) [1]?

This test will throughly test and exercise the TU58 interface and  drive.   It
will utilize the diagnostic features of the TU58.  The drive being tested must
not be the drive from which the subsystem was bootstrapped.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 60
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2.7.2  Inline Buffer Memory Test (IBM) - 

Input Parameters:
 
        ITERATIONS (D) [1]?

This test will test each buffer in buffer  memory  as  it  becomes  available.
Buffers that are found to be faulty will be retired from use and reported.



9.2.7.3  Inline Disk Drive Interface Test (ISDI) - 

Input Parameters:
 
        K SLOT NUMBER (D) []?
        INTERCONNECT NUMBER (D) []?
        ITERATIONS (D) [1]?

This test will  test  a  specific  disk  drive  interface.   The  drive  whose
interface  is  being  tested must be dedicated to the test.  Loopback and echo
facilities of the SDI will be used.  Based on the results  of  the  test,  the
drive (and its interface) will either be returned to service or retired.



9.2.7.4  Inline Disk Drive Test (IDT) - 

Input Parameters:
 
        DISK UNIT NUMBER (U) []?
        ITERATIONS (D) [1]?

This test will test a specific drive.  That drive must  be  dedicated  to  the
test.   The  test  will  consist of initiating all drive resident diagnostics,
down-line loading  to  satisfy  a  diagnostic  request  from  the  drive,  and
executing  a  series  of I/O operations on the drive (positions, reads, writes
based on drive specifics available as characteristics from the drive).



9.2.7.5  Inline Tape Formatter Test (ITT) - 

Input Parameters:
 
        K SLOT NUMBER (D) []?
        STI INTERCONNECT NUMBER (D) []?
        ITERATIONS (D) [1]?

This test will test a specific tape formatter.  That formatter (and  therefore
its  attached drives) must be dedicated to the test.  The test will consist of
initiating all formatter resident diagnostics, down-line loading to satisfy  a
diagnostic  request  from  the  formatter,  and  executing  a  series  of  I/O
operations  on  the  drives  (positions,  reads,  writes)  connected  to   the
formatter.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 61
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2.7.6  Inline K.sdi Test (IKDI) - 

Input Parameters:
 
        K SLOT NUMBER (D) []?
        TEST NUMBER (D) []?
        ITERATIONS (D) [1]?
 

This test will initiate K.sdi resident diagnostics, monitor  the  result,  and
execute  a series of normal K.sdi operations.  This will include operations on
all the drives available to the K.sdi.  K.sdi must be dedicated  to  the  test
and  if  there  is only one, the subsystem cannot perform any disk operations.
If K.sdi passes the test, it will be returned to service.   If  a  failure  is
detected, the K.sdi will be retired from service.



9.2.7.7  Inline K.sti Test (IKTI) - 

Input Parameters:
 
        K SLOT NUMBER (D) []?
        TEST NUMBER (D) []?
        ITERATIONS (D) [1]?
 

This test is much the same as IKDI.  K.sti must be dedicated to the  test  and
if  there  is  only one, the subsystem cannot perform any tape operations.  If
K.sti passes the test, it will be  returned  to  service.   If  a  failure  is
detected, the K.sti will be retired from service.



9.2.8  ERROR RATE ANALYSIS - 



9.2.8.1  Analyze Disk Read/Write Errors (ARDW) - 

Input Parameters:
 
        DRIVE UNIT NUMBER (D) []?

The purpose of read/write error analysis is two-fold.  The primary purpose  is
to analyze errors to determine the quality of the media.  The secondary reason
is to predict an impending failure because of degrading read/write capability.
Stored  error  information  will  be  the  basis  of the analysis.  That error
information will include  the  device  number,  the  cyclinder  number,  track
number,  sector  number,  and a figure of merit of performance.  The figure of
merit is based on the number of errors and the number of operations.   As  the
error  history  develops,  the figure of merit will reflect the performance of
the drive read/write electronics and the media.  If the figure of merit  drops
below  a  selected  value,  the  drive  (and  the  media) will be removed from
service.  The analysis diagnostic will  report  the  reason  for  the  failure
(read/write electronics or the media).
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 62
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


9.2.8.2  Analyze Seek Errors (ASKE) - 

Input Parameters:
 
        DRIVE UNIT NUMBER (D) []?

As in the case of read/write errors, a figure of merit  for  seeking  will  be
developed  based  on  the  number  of positioning operations and the number of
errors.  If the figure of merit becomes too low, it  will  be  symptomatic  of
impending positioner failure and, possibly, defective media (servo surface).



9.2.9  SUPPORT ROUTINES FOR DIAGNOSTICS - 



9.2.9.1  Support K-INIT Sequence (SKSQ) - 

Input Parameters:
 
        K SLOT NUMBER (D) []?
        K TEST NUMBER (D) []?
        ITERATIONS (D) []?

This routine will determine the sequence of the  K  initialization  diagnostic
execution.   It  will monitor the results of each K initialization and perform
the reporting as necessary.  This routine, when it  is  initiated  on  demand,
will  accept  parameters  that specify a particular K and a particular test in
that K.



9.2.9.2  Support Drive Test (SDRT) - 

Input Parameters:
 
        DRIVE UNIT NUMBER (U) []?
        DRIVE TEST NUMBER (D) []?
        DOWNLINE LOAD (Y/N) [N]?
        TEST ID (D) []?
        ITERATIONS (D) [1]?

This routine will receive requests for drive diagnosis (from the  local  panel
or the Extended Function DCP command) and initiate the requested diagnostic in
the drive.  It will receive the response (results) from the drive and  perform
the proper reporting.
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 63
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


                                  APPENDIX A
                                  ----------
 
                               SYSTEM MESSAGES
 
Following are the possible messages output by various programs in  the  HSC50.
They  may appear on the local terminal, on the pseudo-terminal, or in the host
error log.  Their interpretation is also included:
 
        SYSTEM MESSAGE                  INTERPRETATION
        --------------                  --------------
 
tbd(Software Group)
HSC50 Functional Specification   Revision 0.1 (Bean 8-Jan-79)          PAGE 64
Digital Equipment Corporation -- C O M P A N Y  C O N F I D E N T I A L


                                  APPENDIX B
                                  ----------
 
                            BCKP/RSTO TAPE FORMATS
 
B.1 Volume Layout
 
tbd(McCarthy)
 
B.2 Volume Labels
 
tbd(McCarthy)
 
B.3 File Labels
 
tbd(McCarthy)
 
HSC-50 MULTI-HOST POLICIES



                          HSC50 MULTI-HOST POLICIES

                               Barry Rubinson

                                 March 1979



1.0  Introduction




1.1  Overview

     This document addresses the HSC50's interactions with multiple host
     systems.  Issues examined include:

          1.  Host Identification - how the HSC50 determines which  host
              has sent a command and where to return any results.  

          2.  Controller Identification - how the host determines  which
              HSC50  controller  it  is connected to and what version of
              the software is being executed.  

          3.  Reinitialization  by  the  Host  -  what  happens   in   a
              multi-host  configuration  when one host issues a DCP INIT
              command to an HSC50 controller.  

          4.  "LOG" and "ATTENTION" DCP messages - which host(s) receive
              these messages from the controller and when.  

          5.  Front Panel Switches - what are the effects of  using  the
              HOST PORT A and HOST PORT B switches.




1.2  Definitions


          1.  Host - a computer system that issues DCP commands  to  the
              HSC50  and  receives from the HSC50 DCP completion, error,
              attention,  and  logging  messages;   the  host   is   the
              source/recipient  of data.  Note that, each host is unique
              and is treated  as  such  by  the  higher  levels  of  the
              protocol.  

          2.  Interconnect - a communications path between one  or  more
              hosts and one or more HSC50s.  

          3.  Port - an HSC50 mechanism that connects an interconnect to
              an  HSC50.   Note that, those interconnects with more than
HSC50 Multi-Host Policies (Rubinson, Mar-79)                      page 2



              one bus used for high  availability  purposes  only  (i.e.
              ICCS) are considered to have only one port.  

          4.  Attention Messages - an asynchronous  unsolicited  message
              sent  from  the  HSC50  to a host indicating a significant
              change in status (i.e.   drive  available,  write-protect,
              etc.).   These messages may be acted upon by the host, but
              such action is not required for the correct  operation  of
              the system.  

          5.  Logging Messages -  an  asynchronous  unsolicited  message
              sent  from the HSC50 to a host indicating a problem.  This
              message is typically  entered  into  the  diagnostic  log.
              Additionally,  this message may be acted upon by the host,
              but such action is not required for the correct  operation
              of the system.  

          6.  Physical Switch - a switch that has an immediate effect on
              the   subsystem's   state.    This   switch  is  typically
              implemented via hardware.  

          7.  Logical  Switch  -  a   switch   that   requires   logical
              interpretation  before  its  effect  on  the  subsystem is
              determined.  

          8.  Hard Initialization - using the ROM  bootstrap  to  reload
              the subsystem software and start the controller.  

          9.  Soft Initialization - eliminating the outstanding requests
              for any given host without impacting the operations of any
              other user.




1.3  Goals

     Goals are those  things  we  will  try  to  achieve  in  the  HSC50
     subsystem,  but  may  be  traded off against schedule or cost.  The
     following goals have not been prioritized:

          1.  Individual host access to any device or feature should  be
              able to be limited via a keypad interaction.  

          2.  Individual host access to the HSC50 should be able  to  be
              disabled  via  a  keypad  interaction.   This is useful in
              those cases where the interconnect is a multidrop bus with
              more than one host node.
HSC50 Multi-Host Policies (Rubinson, Mar-79)                      page 3



1.4  Constraints

     Subsystem constraints are to be met regardless of cost or schedule.

          1.  No host should have the capability to disable  the  access
              of  another  host.  Note that, this is an exception to the
              general rule that all keypad type interactions can be done
              via DCP commands.  

          2.  All logging and attention messages that are  caused  by  a
              specific  I/O  command  will  be  directed to the host (or
              keypad) that issued the command.  

          3.  The subsystem interface to the host will be consistent for
              single host, multiple host, and multiple port systems.  




2.0  Host Identification

     The  Device  Control  Protocol  is  a   layered   protocol.    Host
     identification occurs at several layers.  These are:

          1.  The packet transmission layer - the host is identified  by
              the  port,  and node names.  These names do not have to be
              unique across ports.  This information  is  appended  onto
              all commands by the port.  

          2.  The  application  layer  (DCP)  -  the  host  request   is
              identified by a host request identifier that is unique for
              each host request and for each incarnation of each request
              (i.e.   if  the  request must be reissued then a new ID is
              required).

     Thus, the combination of the port and node ID and  the  request  ID
     uniquely  determine  the  identity of each request.  Note that, the
     assumption has been made that no host  will  connect  to  a  single
     HSC50  via more than one node.  If a multi-node connection is made,
     the HSC50 will treat the requests as if they were from  two  hosts.
     This includes soft initialization requests.  



3.0  Controller Identification

              The controller is identified to  the  host  in  a  similar
              manner to the host identification:  

          1.  The  packet  transmission  layer  -  the   controller   is
              identified by its port and node names.  

          2.  The application layer - the controller is identified by  a
HSC50 Multi-Host Policies (Rubinson, Mar-79)                      page 4



              unique   (serial  number)  identifier  and  a  version/ECO
              number.  This is done to facilitate  the  coordination  of
              special features that may be present in future releases.




4.0  Initialization

     The subsystem provides a  hardware  based  mechanism  that  detects
     "hard"    initialization    commands   and   initiates   the   hard
     initialization sequence in the controller's  ROM  bootstrap.   This
     initialization  is unconditional.  Any single host can issue a hard
     init.  The policy as to which host issues hard init and under  what
     circumstances  is  left up to the hosts.  After issuing a hard init
     the issuer must wait  (tbd)  seconds  before  reissuing  it  again.
     Under  normal  circumstances  the  issuer will receive an attention
     message from the HSC50 and can cancel the timer.  The long timer is
     used   to   eliminate   any   race   conditions   on  a  multi-host
     configuration.  Any unsuspecting host (one that did not  issue  the
     hard  init)  that  has  I/O in progress will have to reissue all of
     these requests after the time-out  on  these  outstanding  requests
     occurs.  Indeed the connection protocol must also be reissued.  The
     purpose of the hard initialization is to take the controller out of
     some  unsatisfactory  state.   It  should  only be issued after all
     other controller level recoveries have failed.  Hard  init  is  not
     required for device recoveries, as the controller will have already
     tried to bring the  device  back  into  service  and  failed.   The
     subsystem  also  provides  a  soft  initialization mechanism.  This
     mechanism places the controller into a pristine state with  respect
     to the host that issued the command.  Operations on other hosts are
     not affected.  The soft init command should be the default for host
     bootstrapping and most other situations.  



5.0  Attention and Logging Messages

     Attention and logging messages belong to the class  of  unsolicited
     asynchronous  DCP  messages.   They  are  issued  upon  significant
     changes in system state (attention) or upon  the  detection  of  an
     error  that  should  be  placed  into  the  logging  file  (and may
     optionaly be acted upon by the prudent host).  There are two  basic
     types:

          1.  Directed  messages  -  these  are  attention  and  logging
              messages  sent  to  a  specific host.  Usually this is the
              host that sent an I/O command that caused the  message  to
              be generated.  

          2.  Broadcast messages  -  these  are  attention  and  logging
              messages that are non-specific (i.e.  drive available).
HSC50 Multi-Host Policies (Rubinson, Mar-79)                      page 5



     Attention and logging messages  are  informational  in  nature  and
     require  no  reply  to  the  controller.  Note that there is a host
     specific characteristic  (SET  CHARACTERISTICS  DCP  command)  that
     allows  various  levels of logging messages to be filtered from the
     host.  



6.0  Front Panel Switches

     There are two switches on the front panel of the HSC50  that  allow
     the  manual  selection of which ports (in an optionaly multi-ported
     configuration) the HSC50 will listen to.  The operator  can  select
     one  or both ports.  If both ports are selected then the HSC50 will
     accept commands from both ports.  It is the responsibility  of  the
     hosts  to assure that there are no logical conflicts between hosts.
     The front panel switches are logically mediated by the  controller.
     Any  changes  in  controller  state requested by a change in switch
     state may be delayed by the HSC50 software in  order  to  allow  an
     orderly I/O rundown for that port.  /Should an attention message be
     sent to those hosts being disconnected?/ 



7.0  Conclusions

     This document is the first pass at a policy for handling more  than
     one host.  Comments and suggestions are solicited.
HSC-50 ERROR HANDLING POLICIES





                           ERROR HANDLING POLICIES

                                   FOR THE

                       HIERARCHICAL STORAGE CONTROLLER








                                 REVISION 2








                             MICHAEL E. BECKMAN

                              30 NOVEMBER 1978
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 2



     TABLE OF CONTENTS
      
     1.0        INTRODUCTION
     1.1                Overview
     1.2                Goals
      
     2.0        ERROR HANDLING ENVIRONMENT
     2.1                Processes
     2.1.1                      Non-Resource Ownership
     2.1.2                      Exclusive Resource Ownership
     2.1.3                      Consistency Check
     2.2                Structures
     2.2.1                      Error Table
     2.2.2                      Secondary Data Structures
      
     3.0        INITIATION
      
     4.0        ERROR DEFINITIONS AND CORRECTION PHILOSOPHIES
     4.1                Drive Transfer Errors
     4.2                Drive Errors
     4.3                Cache
     4.4                Interface and Communication
     4.5                CPU
     4.6                Tape
     4.7                Other
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 3



1.0 INTRODUCTION

1.1 OVERVIEW

     This document addresses  data  integrity  and  system  availability
     issues  for  the  HSC50.  This includes error handling policies for
     all subsystem detectable errors.  Errors discussed  include  Memory
     errors, CPU and Memory Management traps and aborts, errors detected
     during data transfer from peripherals such  as  drives  and  tapes,
     cache  errors,  host  and  peripheral  interface  errors and errors
     detected on peripherals and conveyed to the subsystem.

     Error Handling provides data integrity for the user and consists of
     detection,   correction,   and   monitoring  of  error  conditions.
     Detection  is  the   most   fundamental   policy   and   any   data
     communications  system  must find and report all detectable errors.
     Detection will consist of usual  hardware  mechanisms  as  well  as
     low-priority software which performs consistency checks on code and
     control structures.  An  error  can  be  corrected  with  a  unique
     correction  scheme,  as  part  of  a generalized strategy or merely
     flagged to the host.  For each error  the  correction  policy  will
     depend  on  the  frequency  and  severity  of  the  error  and  the
     implementation cost.   Monitoring  of  errors  will  consist  of  a
     subsystem   error   table.   The  table  will  be  used  to  invoke
     diagnostics and notify the host when  error  levels  exceed  preset
     thresholds.   The sophistication of this mechanism will also depend
     on implementation cost.

     The fail-soft policy will  provide  for  the  availability  of  the
     subystem  on  the failure of any non-critical resource.  There will
     be no attempt to keep a failing resource  available  save  invoking
     diagnostics.

1.2 Goals

      1.  Implementation of the DEC Reed-Solomon Error  Correcting  Code
          in  an  environment capable of recovering data in the presence
          of a raw bit error rate of 5 x 10-6.  This  corresponds  to  1
          sector in error in every 50 sectors (worst case).

      2.  Recovery from cache ECC-detected errors.

      3.  Detection  of  code  and  control  and  data-structure  errors
          through consistency check routines.

      4.  Detecting and recovery of transient errors in all parts of the
          controller and interface.

      5.  Recovery from non-transient header compare errors.

      6.   Detection  and  possible   recovery   from   memory   errors,
          particularly parity and non-existent memory errors.
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 4



      7.  Detection and recovery of  host  and  peripheral  interconnect
          errors.

      8.  Static Recovery from CCD board failure.

      9.  Static recovery from all detectable CPU and memory  management
          errors.

     10.  A method of collecting and storing statistics  on  errors  for
          the   purpose   of   invoking   diagnostics   and   predicting
          degenerating conditions on a resource.

     11.  Tape error recovery.

     12.  TU58 error recovery.

2.0 ERROR HANDLING ENVIRONMENT

2.1 PROCESSES

2.1.1 Shared Resource Processes

     These processes perform those error recovery  techniques  which  do
     not  require sole possession of a resource.  They run interactively
     with the normal processes in  the  subsystem.   Processes  such  as
     rereads,  error  table  handling  and  drive misposition tests, are
     examples of interactive processes.

2.1.2 Exclusive Resource Processes

     These processes are invoked when the interactive routines  fail  to
     correct an error condition.  Usually these routines will run at the
     end of normal processing for that resource, and will  handle  those
     operations which could not complete normally.  For instance, errors
     on a cylinder of a drive which cannot  be  corrected  interactively
     will  wait  for  further processing until normal processing for all
     requests queued to that cylinder is  attempted.   Examples  include
     recalibration  or  offset recovery for a drive, or remapping of the
     cache in case of a CCD board failure.

2.1.3 Consistency Check Process

     This process performs consistency checks on the control  structures
     and  code in the subystem.  This includes parity checks on code and
     proper linkages in the control and data structures.  This is a  low
     priority job and may be part of the null job.

2.2 STRUCTURES

2.2.1 Error Table

     There will be a subsystem error table to keep  track  of  subsystem
     and peripheral errors.  It can be used to collect statistics on the
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 5



     performance of the  subsystem  and  peripherals  and  to  flag  the
     presence of abnormally high error rates on a resource.  A two-level
     threshold will be associated with types of  errors  in  the  table.
     When  the  first  level  threshold is exceeded or if a severe error
     occurs (threshold of 1) a diagnostic is invoked  and  the  host  is
     notified.   If  the  diagnostic  determines  that  the  resource is
     capable of continuing normal operation, it sets  the  second  level
     threshold  in  the error table and dynamic configuration table.  If
     the second level threshold is exceeded, then the resource is  taken
     off  line.  It requires operator intervention to bring the resource
     back into service.

     The interrupt level to the host is decreased by not reporting every
     error  to  the  host.  The host, however, has the option to ask for
     all error information instead of only being notified  of  threshold
     violations.

2.2.2 Secondary Data Structures

     When an exclusive resource process (error recovery  or  diagnostic)
     is  executing, it is sometimes necessary to queue artificial sector
     requests to a drive.  These requests can  be  used  to  verify  the
     position  of  the  heads  or  to  test  the drive's and interface's
     ability to transfer data correctly.   Although  exclusive  resource
     processes have the exclusive use of the DRAT table, it is necessary
     to queue artificial transfers or selective error recovery transfers
     without  disturbing  the  primary DRAT structure.  A secondary DRAT
     table handles these cases.  The address of the DRAT  table  is  set
     for  the data channel by the software.  The artificial or selective
     transfers are queued on a secondary table.  Any memory address on a
     512  word  boundary  can  be  used as the start of a secondary DRAT
     table.

3.0 INITIATION OF ERROR RECOVERY

     The detection of an  error  can  result  in  the  initiation  of  a
     non-resource  ownership  process,  an  exclusive resource ownership
     process or a process which immediately quiesces the subsystem.  The
     majority  of  errors  will  be  those  detected on the data channel
     during the transfer of data from a drive.  Most of  these  will  be
     errors  detected  by  the  ECC mechanism.  Data transfer errors are
     queued to  a  non-resource  ownership  process  which  performs  an
     appropriate recovery routine, interactively with normal processing.
     Should these procedures fail for any error, that error is queued to
     an   exclusive   resource   ownership  process.   When  all  normal
     processing on a cylinder which can be completed without errors  has
     finished,   the  exclusive  ownership  process  is  initiated.   It
     requests from the monitor the resources it needs and controls these
     resources  until  it  has  recovered  from as many of the errors as
     possible  or  has  determined  that  the   remaining   errors   are
     unrecoverable.

     Errors for which there are no interactive recovery  procedures  are
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 6



     queued  directly  to exclusive resource ownership processes.  Cache
     ECC errors which cannot be corrected by the ECC code in  the  cache
     processor  are  one such example.  Detection of a seek error during
     header error recovery is another example of an error for  which  no
     handling  can  be attempted until the resource is owned exclusively
     by the error handling process.  These  classes  of  errors  usually
     also result in the initiation of a diagnostic.

     Certain severe errors will result in the subsystem  being  quiesced
     immediately.   The  quiescing  code,  for  example, is initiated on
     consistency errors in the system  code  and  for  certain  CPU  and
     Memory Management traps.

4.0 ERROR DEFINITIONS AND RECOVERY PHILOSOPHIES

4.1 DRIVE TRANSFER ERRORS

     First pass design indicates  that  the  following  errors  will  be
     relevant:
               ECC Errors
               Header Compare Errors
               Data Channel Timeout
               Data Late Error
               Sync Mark Error
               Drive Clock Error
               Drive Available
               Sector Pulse Error

4.1.1 ECC Error

     The ECC code for the HSC50 controller is the DEC Reed-Solomon code.
     The Reed-Solomon codes are a cyclic, non-binary subset of the B-C-H
     codes (See "Specification for  NDS  Error  Correcting"  -  Riggle).
     Shortened  versions  of  the  code  were  chosen in order to reduce
     implementation cost.  170  bits  of  ECC  are  generated  for  each
     sector.   For  the  byte  formated machines the sector length is 4k
     bits while the 36 bit format machines use a 4608 bit  sector.   The
     information  bits  are broken down into 10 bit symbols (sectors are
     padded with zeroes to make them module-10) which  are  mapped  into
     elements  of a Galois Field.  17 10-bit symbols are appended to the
     end of each sector.  The code is capable of correcting  any  sector
     (information and ECC symbols) which has 8 or fewer symbols in error
     and can detect any sector which has 9 symbols in error.  Most,  but
     not  all  sectors with 10 or more errors are also detected.  Severe
     errors (10 or more symbols in error) may result in  the  error  not
     being   detected  or  in  being  detected  but  miscorrected.   The
     probabilities of these occuring are (tbs).

     The ECC redundancy bits  are  generated  in  hardware  as  data  is
     transferred  over the channel to the drive.  The bits are generated
     in real time and are appended to the data  stream  written  to  the
     drive.   When  data is read from the drive, the redundancy bits are
     again  generated  from  the  data  and  exclusive  ORed  with   the
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 7



     redundancy  bits  read  from the end of the data stream.  The XORed
     pattern, known within DEC as the ECC residue,  is  written  to  the
     buffer  with  the  data.  An error is detected by the K-disk if the
     residue is non-zero.  Correction will either be performed by the  K
     disk or by the P(io).

     The specified raw bit error probability for the R81 drive is 1  bit
     error in 10-6 bits.  This corresponds to one sector in error out of
     244 sectors (worst case).  The goal is to implement the code in  an
     environment  capable  of  handling  a  raw rate of 5 x 10-6 without
     seriously degrading system throughput.   This  corresponds  to  one
     sector in error per 50 sectors (worst case).

4.1.2 Header Compare Error

     The sector header will be 8 words long, repeating a 2-word  logical
     block  number  4 times.  The header-compare hardware is in the data
     channel.  It compares each half of the logical header  against  the
     correct value.  Any 2 out of 4 of the first word and any 2 out of 4
     of the second word must compare against  the  correct  value.   The
     comparison is differentiated into 4 cases:
          .  Successful compare,
          .  successful first word - unsuccessful second word,
          .  successful second word - unsuccessful first word,
          .  unsuccessful compare on both words.

     The primary cause of header errors should be  transient  conditions
     which  cause  corruption  of  the  header field instead of the data
     field.  The probability should be [to be specified]that  the  error
     occurs  in  the  header  field  for  the  raw  error  rate  assumed
     throughout this document.  Mispositioning  due  to  misseek,  servo
     problem,  or  head or PLO error will appear as header errors if not
     detected elsewhere.  Dirt, media defect, scratches on  the  surface
     or  malfunctioning  of  the hardware, as well as offset problems on
     removable  media,  will  also  show  up  as  header   errors   with
     unpredictable regularity.

     Transient errors, such as  those  caused  by  electrical  noise  or
     magnetic  interference,  will  be  handled  with  rereads.   If the
     rereads are not successful, the only available method  of  recovery
     without  taking  over  the  resource is to access the data with the
     header compare inhibited.  Recoveries which take over the  resource
     include recalibration and reseeking, offset recovery, if available,
     and slew manipulation.

     Header compare inhibit accesses are only  performed  on  reads  and
     only  when  it  has been determined that the proper sector is being
     accessed.  On all read operations, the  header  is  read  into  the
     buffer.   A  header  error  results  in  the  data  transfer  being
     terminated but the header is still placed  into  the  buffer.   The
     header is used to try to determine whether the header error was due
     to mispositioning of the head.  The recovery procedure also has the
     ability  to  queue  artificial  requests  to  the drive in order to
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 8



     confirm that the drive is positioning correctly.  After determining
     that the positioning is correct, the primary sector can be accessed
     with the header compare inhibited.

4.1.3 Data Channel Timeout

     This indicates a hardware error on the data channel.  The  transfer
     in progress is terminated.  Error handling policy is to be defined.

4.1.4 Data Late Error

     This indicates that a grant was not received  for  a  data  request
     from  the data channel.  It is an error that occurs when reading or
     writing to memory.  The handling policy is to be defined.

4.1.5 Drive Clock Error

     There has been a loss of drive clock from either the servo  surface
     or the data surface.  It is detected by the K-disk if a transfer is
     in progress.  The transfer is terminated.  Handling policy is to be
     defined.

4.1.6 Sync Detection Error

     There will be a 12-bit autocorrelated  synchronization  pattern  at
     the  beginning of the header and again at the beginning of the data
     field.  It must compare, to a  certain  confidence  level,  with  a
     predefined  pattern  before  the sector will be read.  The transfer
     will be terminated  if  the  comparison  fails.   Rereads  will  be
     attempted.   If  these  fail,  offset recovery will be attempted on
     removable media drives.

4.1.7 Drive Available Error

     There is a line in the disk interface, Drive Available, which  goes
     false  when  any  condition  occurs on the drive or interface which
     makes it impossible to confidently transfer data to the controller.
     The  K-disk  detects  the  error  condition and terminates any data
     transfer  in  progress.   An  attention  message   describing   the
     condition  in  more  detail  will  be  requested  from the drive if
     possible.  If data  transfer  was  in  progress,  the  transfer  is
     retried.   If retires fail a diagnostic is called for the interface
     and then for the drive.

4.1.8 Sector Pulse Error

     Sector Pulse error is a timeout error which occurs  if  the  K-disk
     does  not  detect  a sector pulse on the arbitrated drive.  Rereads
     are attempted.  If the error persists and is present  on  all  data
     transfers,  then  there  is  a hard error such as media corruption,
     servo  problem  or  failing  hardware.   Diagnostic  evaluation  is
     necessary.  If the problem is isolated to one sector, then the host
     is notified that the data is not retrievable.
HSC50 Error Handling Policies (Beckman, 30-Nov-78)                page 9



4.2 DRIVE ERRORS

     These errors, and others which will occur on the  interface  or  on
     the drives, need to be further defined for the product.
       .  No Data - No transistions have occurred on the Read/Write Data
          lines  within 160 servo clock periods after Read Command Level
          or Write Gate have  been  asserted.   Read  data  was  checked
          before  the  transmitter;   write  data  was checked after the
          receiver.
       .  Drive Clock Dropout - Drive Clock dropped in frequency or  was
          lost.
       .  Write Strobe Dropout - Write Data Strobe dropped in  frequency
          or was lost.
       .  Read and Write Error - Read and Write Gates were  asserted  at
          the same time.
       .  Invalid Head Select - Invalid head address was  received  from
          the data channel.
       .  Data Separator Unsafe - A write  check  failed  or  late  data
          strobing    and    early    data   strobing   were   attempted
          simultaneously.

     On all these errors,  drive  available  was  dropped  and  internal
     diagnostics run.

4.3 CACHE

     Although the cache directory is organized on a cluster  basis,  the
     cache  is  a  sector  based  device  and  sector  error recovery is
     possible.  There is ECC on data in the cache.  For every 16 bits of
     information,  there  are  2 bits of ECC, one of which is implicitly
     parity.  The code operates  on  5  word  sets  and  is  capable  of
     correcting  1  bit  in  error  in  each of the 5 words.  The ECC is
     generated as data is written into the cache, and is transparent  to
     the rest of the subsystem.

     When an ECC Error occurs on a sector of the cache  that  sector  is
     immediately  suspect.   This presents two problems:  recovering the
     data, and  determining  if  that  sector  of  the  cache  is  still
     functional.   If  the error is within the corrective ability of the
     ECC code then recovering the data is straightforward.  The ECC code
     corrects  the  data  transparent  to  the rest of the subsystem and
     notifies the error processes that a cache error has occurred.   For
     any ECC error that physical sector of cache is made unavailable.  

     For an uncorrectable error on  a  write-through  cache,  the  first
     problem  is  solved  by treating the request as an uncached request
     and the data is  read  from  or  written  to  the  drive.   For  an
     uncorrectable error on a write-back cache, the data on the drive is
     not up to date  and  is  guaranteed  only  up  to  the  last  FLUSH
     operation.   The  sectors  in question are invalidated in the cache
     and the cache control structure is modified.A log message  is  sent
     to  the  host  which  may  or may not be acted upon.  Reads to that
     sector are returned to the host as errors.On  a  write  request  to
HSC50 Error Handling Policies (Beckman, 30-Nov-78)               page 10



     that sector, the data is written through to the drive and the cache
     control stucture is updated to indicate that reads to  that  sector
     are   now  valid.   Across  power  failure  the  information  in  a
     write-back cache is not guaranteed to be correct.   The  write-back
     user may have the ability to request that the bad data in the cache
     be written to the drive.

     Determination of whether a sector in the cache is still  functional
     is  independent  of  write-through  or write-back.  The simple, but
     non-optimal, soluction is merely to mark that section of the  cache
     invalid  in  the  directory.   A  more  optimal solution will be to
     initiate a diagnostic to determine  whether  that  section  of  the
     cache  can  be  returned  to service.  Each cache block in question
     will be queued to the diagnostic.  If an area cannot be returned to
     service  the cache should statically or dynamically be reconfigured
     with the remaining boards.  If this can be done dynamicaly  without
     excessive  cost, it will minimize system degradation once the cache
     has been reconfigured.  If this can only be done statically due  to
     technical or cost reasons, then the directory should immediately be
     updated to invalidate the areas of the cache  in  question  and  be
     reconfigured when the subsystem is next initialized.

4.4 INTERCONNECT ERRORS

     Communication between the subsystem and  peripherals,  and  between
     subsystem  and host, involves a three-level protocol.  The protocol
     is documented in "Standard Disk Interface Specification" by  Robert
     Bean.  Level 1 performs consistency checks on the response from the
     drive (CRC and framing checks), initiates  timeouts,  and  receives
     and  acknowledges  attention  messages.   On consistency errors and
     timeouts on a peripheral, the level one will  "init"  the  resource
     and  retry  the  command.   Failure on the retry will result in the
     subsystem being notified that a diagnostic is needed for  the  bus.
     If no error is found on the bus, a diagnostic for the drive will be
     run.  Attention messages will be routed to an appropriate process.

     Level 2 receives messages which are consistent from level 1.   This
     does  not imply successful completion, rather only that the CRC and
     framing tests were successful on the  result.   The  non-successful
     completion  message  can  indicate  that the command had an invalid
     CRC, that the command was inconsistent with the parameters  of  the
     device, or that the command could not be completed due to a failure
     on the device.  In  the  first  two  cases,  the  command  will  be
     reformatted  and  resent.  The latter case should be followed by an
     attention message  from  the  device  giving  more  specific  error
     information.   An appropriate diagnostic will be initiated internal
     to the drive.  

     The drives are intermittently polled by  a  low  priority  task  to
     verify that they are still connected and operational.
HSC50 Error Handling Policies (Beckman, 30-Nov-78)               page 11



4.5 CPU AND MEMORY MANAGEMENT ERRORS

     Odd Addressing Trap - CPU:  This occurs when  a  process  tries  to
     execute a word instruction on a byte address.  The CPU will trap to
     location 4 and set bit 7 in the CPU  Error  Register.   This  error
     will only occur if code, data, or structures have been corrupted or
     a hardware error has taken place.

     The subsystem will be quiesced.  The host will be notified that all
     requests  are  being  terminated.   Diagnostics  will be invoked to
     determine if there is a hardware problem.   The  software  will  be
     reloaded  and  the  subsystem  reinitiated  if  diagnostics fail to
     determine that there is a problem.

     Non-Existent Memory Error - CPU:  This occurs when a process  tries
     to  reference a memory location outside of the set limits.  The CPU
     will trap to location 4 and set bit 5 in the  CPU  Error  Register.
     This  will  be  handled  in  the same fashion as the Odd Addressing
     Trap.

     Power Fail in CPU:  This will happen when the  AC  drops  below  95
     volts or the frequency is out of the 47 to 63 Hz range.  Notify the
     host if possible.  

     Memory Management Abort - Invalid Access Code:  The access code  is
     not  defined  or  is  non-resident.  There will be an abort through
     Kernel location 250.  Bit 15  will  be  set  in  Memory  Management
     register 0.

     Memory Management Abort - Page  Length  Error:   Program  tried  to
     access  a  location  outside  of the bounds of the page definition.
     This, too, will abort through location 250 in the Kernel  and  will
     set bit 14 in the MM register 0.

     Memory Management Abort -  Read  Only  Access  Violation:   Program
     attempted  to  write  to  a  write-protected  page.  Aborts through
     location 250 in the Kernel and sets bit 13 in MM register 0.

     The Memory  Management  aborts  are  all  handled  the  same.   The
     subsystem  is quiesced.  These errors should not occur as transient
     type errors.  They are indicative of code  corruption  or  hardware
     failure.   The  host  will  be notified that the subsystem is going
     down.  Diagnostics will be invoked to check the  virtual  addresses
     which   generated   the   abort  and  to  check  the  software  for
     consistency.  Hardware diagnostics should also be run.

4.6 TAPES

     The subsystem will have  both  half-inch  tape  and  cassette  tape
     (TU58).   The  cassette will only be used for loading processes and
     diagnostics.  Errors on tapes are a normal rather than  exceptional
     condition.   This  is  due  to  the nature of the device and media.
     There are often holes and defects in the recording surface and  the
HSC50 Error Handling Policies (Beckman, 30-Nov-78)               page 12



     tape  is not rigid, which causes skipping, flopping and movement at
     a non-constant velocity.  Electrical noise also contributes  random
     errors  as  on  disks.   Since errors are so prevalent, tape drives
     have  been  designed  with  sophisticated  error  recovery  in  the
     controller.   Group Coded Recording (GCR) tapes have an ECC and CRC
     mechanism.  Phase-Encoded tapes do not use the ECC mechanism.   Raw
     bit tape error rates are in the 10-5 to 10-7 range with the GCR ECC
     improving the hard rate to 1 in 10-8 to 10-9.

     It is not known at this time which 1/2" tape will  be  attached  to
     the  HSC-50.  Definitive error handling policies will be defined at
     a later date.  DEC Standard  174  concerning  Magnetic  Tape  Error
     Recovery will be followed.

     The TU58 is a two-track binary formatted  non-directory  structured
     cassette tape drive.  It is preformatted into 2048 records of fixed
     length of 128 bytes of data.  There is a  16-bit  interrecord  gap.
     The header contains a 16-bit preamble, a 16-bit record number and a
     16-bit checksum on the header.  There is a 32-bit gap  between  the
     header  and  the  data.   The  data  field  is followed by a 16-bit
     checksum on the data.  If  either  the  header  or  data  checksums
     detect  an  error,  the tape is backed up and reread up to 5 items.
     After that a hard error is flagged.  The TU58 suffers from the same
     drawbacks  as  the  TM78  in  terms  of noise and the nature of the
     media.  In addition, the tape on the TU58 is always in contact with
     the  heads.   The  tape  wears  during  rewind  as  well  as during
     read/write.  The tape can wear out in as  few  as  5000  end-to-end
     runs.   Since  the  HSC  only  uses  the  TU58 to load programs and
     diagnostics, this number is not relevant.  The soft data error rate
     (reread  recoverable) is specified at 1 in 104 records and the hard
     error rate is specified at 1 in 106 searches.  The TU58 is designed
     to  communicate  to  a  host  with  the  Radial Serial Interconnect
     Protocol.

     Tape Error Recovery strategies are:

          .    Rereads

          .    Rereads with varied voltage thresholds

          .    Rereads with varied skew settings

          .    Clean tape, followed by the above

4.7 OTHERS

     Parity Error on Memory:  Memory has one bit of odd parity per byte.
     Internal  buses  will also have odd byte parity on data and control
     lines.

     For memory parity errors, there are two problems, as in the  cache.
     The  data  has to be restored and it must be determined whether the
     piece of memory is functional.  For error on a piece  of  data,  if
HSC50 Error Handling Policies (Beckman, 30-Nov-78)               page 13



     the  request  block  pointer can be recovered, then the data can be
     restored.  If any  of  the  control  structures  beneath  the  host
     request  blocks  are  corrupted,  they can be restored.  Error in a
     host request block will result in notification to the host that the
     request  has  been  aborted  and should be re-issued.  Buffers with
     parity errors will be dynamically allocated to a  bad  buffer  pool
     and the subsystem will continue to run.  When buffers are set up at
     init time there should be an in-line diagnostic run  to  check  the
     memory for parity errors.

     Clock Errors:  There will be a master clock for the whole susbystem
     and  at  least  one  clock  under  software  control.  Timeouts for
     software routines will probably be handled by  preset  monostables.
     Errors on any of these clocks, like errors on any critical resource
     in the subsystem, should cause the subsystem to be quiesced pending
     diagnostic or field service support.

     LED Display Errors:  The function of these displays in relation  to
     error conditions has not yet been defined.

     
HSC-50 ROM BOOTSTRAP DOCUMENTATION



                               USER DOCUMENTATION
                               ------------------


              PRODUCT CODE:  XX-XXXXX-XX

              PRODUCT NAME:  HSC50 - P.IOC ROM BOOTSTRAP

              PRODUCT DATE:  12-APR-1983

              MAINTAINER:    Diagnostic Engineering - Colorado (CX)

              AUTHOR:        Mike Hare




                   The information  in  this  document  is  subject  to
              change  without  notice, and should not be construed as a
              commitment by  Digital  Equipment  Corporation.   Digital
              Equipment  Corporation  assumes no responsibility for any
              errors that may appear in this document.

                   The software described in this document is furnished
              under  a  license  and  may  only  be  used  or copied in
              accordance with the terms of such license.

                   Digital    Equipment    Corporation    assumes    no
              responsibility for the use or reliability of its software
              on equipment that is not supplied by Digital.

              Copyright (C) 1982,1983 by Digital Equipment Corporation
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 2
          TABLE OF CONTENTS


                               TABLE OF CONTENTS



              1.0      GENERAL INFORMATION
                1.1    Program Abstract
                1.2    System Requirements
                1.3    Related Documents
                1.4    Hardware Assumed to be Working

              2.0      OPERATING INSTRUCTIONS
                2.1    Start-Up Procedure
                2.2    Test Parameter Entry
                2.3    Setting/Clearing Flags
                2.4    Progress Reports

              3.0      ERROR INFORMATION
                3.1    Error Reporting Scheme
                3.2    Specific Error Codes

              4.0      TEST SUMMARIES
                4.1    Test 0 - Basic PDP-11 instruction set
                4.2    Test 1 - Program Memory (Swap Bits)
                4.3    Test 2 - Program Memory (Vector Area)
                4.4    Test 3 - Program Memory (8 Kword Partition)
                4.5    Test 4 - TU58 Tests
                4.6    Test 5 - Transfer Control to Loaded Image
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 3
          GENERAL INFORMATION


              SECTION 1 - GENERAL INFORMATION

              1.1    PROGRAM ABSTRACT

                     The HSC50 P.ioc ROM Bootstrap verifies the basic integrity
                     of  the  HSC50's  P.ioc  module,  Program memory, and TU58
                     interface.  The goal of the bootstrap  tests  is  to  test
                     enough  of  the  HSC50 to allow further tests to be loaded
                     from the TU58.

                     The  bootstrap  is   the   first   step   in   the   HSC50
                     Initialization  process, and is run for every bootstrap or
                     reload of the HSC50 operational  software  (CRONIC).   The
                     bootstrap  is  initiated automatically each time the HSC50
                     is powered-on, and is also  initiated  by  CRONIC  when  a
                     software re-boot is required.

                     The bootstrap is a PDP-11 program, written to  execute  in
                     an  F11  CPU in a stand-alone environment.  I.E.  No other
                     software processes co-exist with the bootstrap.

                     Bootstrap failures  are  reported  via  the  'Fault  Lamp'
                     mechanism,  which  specifies the module (P.ioc, memory, or
                     TU58) which is the most likely cause of the  problem.   In
                     addition, certain information relating to TU58 failures is
                     saved in a table in  the  Program  memory,  to  assist  in
                     diagnosing tape errors.

              1.2    SYSTEM REQUIREMENTS

                     In order for the bootstrap to complete  successfully,  the
                     following hardware must be working:

                       o  Basic instruction set of the PDP-11

                       o  First 2,048 bytes of Program memory, plus 8 Kwords of
                          contiguous Program memory below address 160000.

                       o  A TU58 drive and controller, containing a tape with a
                          bootable image.

              1.3    RELATED DOCUMENTS

                     1) HSC50 - P.ioc ROM Bootstrap program listing
                     2) TU58 Users Guide

              1.4    HARDWARE ASSUMED TO BE WORKING

                     This program is the first software executed when the HSC50
                     is  powered-on.   No other diagnostics are executed before
                     the bootstrap.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 4
          OPERATING INSTRUCTIONS


              SECTION 2 - OPERATING INSTRUCTIONS

              2.1    START-UP PROCEDURE

                     Follow the steps below to initiate the  bootstrap.   Refer
                     to section 2.1.1 if this procedure fails.

                     1.  Insert the HSC50 CRONIC  SOFTWARE  cassette  into  the
                         TU58's unit 0 drive .  (left-hand drive)

                     2.  If the HSC50 power is OFF,  turn  power  ON.   If  the
                         HSC50  power  is  ON,  depress  the  INIT  lamp.   The
                         bootstrap will initiate automatically.

                     3.  The INIT lamp on the HSC50's front  panel  will  light
                         when the bootstrap's PDP-11 tests are done.

                     4.  The TU58's drive-motion LED  should  light  within  10
                         seconds,  indicating  that  the cassette's boot blocks
                         are being loaded into Program memory.

                     5.  The  bootstrap  transfers   control   to   the   first
                         instruction of the image just loaded from tape.


              2.1.1  IN CASE OF TROUBLE

                     Most failures in the bootstrap will result in lighting the
                     'FAULT'  lamp  on the HSC50's front panel.  Depressing the
                     'FAULT' lamp momentarily will cause a failure code  to  be
                     displayed  in  the  front  panel lamps.  Section 3 of this
                     document lists the  meaning  of  each  failure  code,  and
                     specifies  which  of  the HSC50 modules is the most likely
                     cause of the bootstrap failure.

                     If a failure occurs in the tests  of  the  PDP-11's  basic
                     instruction  set, the FAULT lamp mechanism can not be used
                     to report the failure.  Instead the PDP-11 will execute  a
                     'Branch  dot'  (E.G.   "BR  ."), and will not continue the
                     bootstrap program.  Failures of this type can be identifed
                     by  the failure of the INIT lamp to light.  (The INIT lamp
                     is  lighted  immediately  after  the  basic  PDP-11  tests
                     complete.)  If a local terminal is connected to the P.ioc,
                     the exact instruction that failed  can  be  determined  by
                     depressing  the  terminal's  'BREAK'  key,  and noting the
                     address displayed on the terminal.  Using a listing of the
                     bootstrap,   this   address   can  be  used  to  find  the
                     instruction that failed.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 5
          OPERATING INSTRUCTIONS


              2.2    TEST PARAMETER ENTRY

                     The  bootstrap   does   not   accept   any   user-supplied
                     parameters.

              2.3    SETTING/CLEARING FLAGS

                     The bootstrap does not have any user-modifiable flags.

              2.4    PROGRESS REPORTS

                     The bootstrap does not issue progress reports in the usual
                     sense,  however  certain  indications  of  the bootstrap's
                     progress are visible to the user, as listed below:

                     1.  LAMPS CLEAR - One of the first operations performed by
                         the  bootstrap  is  to  clear all of the HSC50's front
                         panel lamps.  If the lamps fail to  clear  immediately
                         after  the  bootstrap  is  initiated, a failure of the
                         P.ioc is probable.  (Circuitry on the P.ioc module  is
                         responsible for initiating the bootstrap program.)

                     2.  INIT LAMP - The INIT lamp will be lit as soon  as  the
                         basic  tests  of  the  PDP-11's  instruction  set  are
                         completed.  These tests will normally complete  within
                         milli-seconds   after   the  bootstrap  is  initiated.
                         Failure of the INIT lamp to light indicates a  failure
                         in the P.ioc's PDP-11 processor.

                     3.  TAPE MOTION - Following the tests of  the  PDP-11  and
                         the Program memory, the bootstrap will try to load the
                         INIT P.IOC TEST from the TU58.  The LED  on  the  tape
                         drive  containing  the  HSC50  CRONIC  software should
                         begin to blink as the load is proceeding.  If the tape
                         motion  LED fails to blink within 15 seconds after the
                         boot is initiated, see section 3.2.3 of this  document
                         for a discussion of possible causes of this failure.

                     4.  STATE  LAMP  -  When  the  bootstrap   completes   and
                         initiates  the INIT P.IOC test (or OFFLINE P.IOC TEST)
                         the STATE lamp will be lighted.  When the  STATE  lamp
                         is lit, the INIT lamp will be extinguished.

                     5.  FAULT LAMP - If the FAULT lamp lights during the  boot
                         process,  the  ROM  tests have detected a fatal error.
                         Refer to section 3 of this document.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 6
          ERROR INFORMATION


              SECTION 3 - ERROR INFORMATION

              3.1    ERROR REPORTING SCHEME

                     The bootstrap is  designed  to  operate  without  a  local
                     terminal,  thus the bootstrap cannot use the terminal as a
                     reporting mechanism  for  errors.   Instead,  the  HSC50's
                     front  panel  lamps  are  used  to  report  errors, and to
                     indicate the module (P.ioc, Memory, or TU58) which is  the
                     most likely cause of the error.

                     When the bootstrap detects an error,  it  will  light  the
                     FAULT  lamp on the front panel.  Depressing the FAULT lamp
                     momentarily will cause the bootstrap to display a  failure
                     code  in  the  front  panel  lamps.  The failure code will
                     blink on and off at 1/2 second intervals.  The meaning  of
                     each  failure  code is given in sections 3.2.x below.  The
                     bootstrap may be re-initiated  by  momentarily  depressing
                     the INIT lamp on the front panel.

              3.2    SPECIFIC ERROR CODES

                     The following sections identify the HSC50 modules that are
                     indicated  by  specific  error  codes  in  the front panel
                     lamps.

              3.2.1  CODE 21 - P.IOC MODULE FAILURE

                                     FRONT PANEL LAMPS

                       +------+    +------+    +------+    +------+    +------+
                       |      |    |      |    |      |    |      |    |      |
                       |  ON  |    | OFF  |    | OFF  |    | OFF  |    |  ON  |
                       |      |    |      |    |      |    |      |    |      |
                       +------+    +------+    +------+    +------+    +------+

                               FAILURE CODE 21  -  P.ioc Module Failure

                     This code specifies the P.ioc module as  the  most  likely
                     cause  of  the bootstrap failure.  The P.ioc module should
                     be replaced.

                     If a local terminal is connected to the  P.ioc,  the  user
                     can  determine  which  test  failed  by examining the Test
                     Number.  Refer to the Manual  Troubleshooting  section  of
                     this document (section 3.3).
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 7
          ERROR INFORMATION


              3.2.2  CODE 22 - M.STD MODULE FAILURE

                                     FRONT PANEL LAMPS

                       +------+    +------+    +------+    +------+    +------+
                       |      |    |      |    |      |    |      |    |      |
                       |  ON  |    | OFF  |    | OFF  |    |  ON  |    | OFF  |
                       |      |    |      |    |      |    |      |    |      |
                       +------+    +------+    +------+    +------+    +------+

                               FAILURE CODE 22  -  M.std Module Failure

                     This code specifies the M.std (memory) module as the  most
                     likely  cause  of a bootstrap failure.  Possible causes of
                     this failure include:

                     a) The memory test of the first 1 Kword (vector  area)  of
                     Program  Memory  failed, and using the SWAP BANKS and SWAP
                     BOARDS bits  in  the  P.ioc  CSR  failed  to  correct  the
                     problem.  (Test 2).

                     b) A contiguous 8 Kword partition could not  be  found  in
                     Program Memory below address 00160000.  (Test 3).

                     In either of the above cases, the M.std module  should  be
                     replaced.   If a local terminal is connected to the P.ioc,
                     the user can determine which of  the  errors  occurred  by
                     examining   the   Test   number.    Refer  to  the  Manual
                     Troubleshooting Section of this document (section 3.3).
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 8
          ERROR INFORMATION


              3.2.3  CODE 23 - TU58 FAILURE

                                     FRONT PANEL LAMPS

                       +------+    +------+    +------+    +------+    +------+
                       |      |    |      |    |      |    |      |    |      |
                       |  ON  |    | OFF  |    | OFF  |    |  ON  |    |  ON  |
                       |      |    |      |    |      |    |      |    |      |
                       +------+    +------+    +------+    +------+    +------+

                               FAILURE CODE 23  -  TU58 Failure

                     This failure code indicates that  the  TU58  is  the  most
                     likely  cause  of the bootstrap failure.  This failure can
                     be caused by a hardware problem in the TU58 controller  or
                     drives, but can also be caused if none of the HSC50's TU58
                     drives contains a tape  with  a  bootable  image.   Before
                     replacing  the  TU58,  try  booting from a different drive
                     (the  bootstrap  will  attempt  to  boot  from  any  drive
                     connected  to  the  P.ioc).   If  booting from a different
                     drive also fails, try using another tape.  If  neither  of
                     the  above  two  steps  succeeds, and no local terminal is
                     connected to the P.ioc, replace the TU58 controller.   (If
                     a  local terminal is available, refer to section 3.3).  If
                     the bootstrap succeeds when a different drive is used, the
                     original  drive  should  be  replaced.   If  the bootstrap
                     succeeds when  a  different  tape  is  used,  replace  the
                     original tape.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP             Page 9
          ERROR INFORMATION


              3.3    MANUAL TROUBLESHOOTING

                     If a local terminal is connected to the P.ioc module,  the
                     ODT  program (built into the PDP-11 microcode) can be used
                     to obtain further information about a  bootstrap  failure.
                     Refer  to  section  3.3.1, 3.3.2, or 3.3.3, depending upon
                     the failure symptom.

              3.3.1  'INIT' and 'FAULT' ARE BOTH OFF

                     If the INIT lamp and FAULT lamp are both OFF,  either  the
                     bootstrap  program was not automatically initiated, or the
                     bootstrap's PDP-11 instruction test failed.  To  determine
                     which failure occurred, depress the BREAK key on the local
                     terminal.  The ODT program built into  the  PDP-11  should
                     respond  by  halting the PDP-11 and displaying the address
                     of the current instruction in the bootstrap.  To determine
                     which  instruction  failed,  use  the address displayed to
                     locate the corresponding instruction in the listing of the
                     bootstrap  program.   Some  PDP-11  failures  will put the
                     machine in a state such that depressing the BREAK key will
                     have  no  effect,  making  it  impossible  to  know  which
                     instruction is failing.   If  spares  are  available,  try
                     replacing the PDP-11 CPU chip and the PDP-11 MMU chip (one
                     at a time, in that order).  If replacing  the  chips  does
                     not  fix the problem, or if spare chips are not available,
                     replace the P.ioc module.

              3.3.2  'INIT' IS OFF, 'FAULT' IS LIT

                     If the INIT lamp is OFF, and  the  FAULT  lamp  is  on,  a
                     failure  in  the PDP-11 instruction test is indicated.  If
                     spares are available, try replacing the PDP-11  CPU  chip,
                     and  the  PDP-11  MMU chip (one at a time, in that order).
                     If replacing the chips does not fix  the  problem,  or  if
                     spare chips are not available, replace the P.ioc module.

              3.3.3  'INIT' and 'FAULT' BOTH LIT

                     If the INIT lamp and FAULT lamp are both ON,  depress  the
                     FAULT   lamp  momentarily  and  the  fault  code  will  be
                     displayed.  Then  depress  the  BREAK  key  on  the  local
                     terminal  to  halt  the  program.   Now  type:   '172340/'
                     (without the quotes).  ODT will respond by displaying  the
                     contents of address 172340, which is the test number.  Use
                     the test number to refer to the proper test description in
                     section 4 of this document.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP            Page 10
          TEST SUMMARIES


              SECTION 4 - TEST SUMMARIES

              4.0    TEST SUMMARIES

                     The following sections summarize the  tests  performed  by
                     the bootstrap.

              4.1    TEST 0 - BASIC PDP-11 INSTRUCTION SET

                     This test verifies the correct operation of  a  subset  of
                     the  PDP-11's instruction set.  The subset of instructions
                     chosen  for  testing  includes  only  those   instructions
                     required   for  the  completion  of  the  bootstrap.   The
                     following instructions are tested:

                     Single Operand Instructions Tested  (both  word  and  byte
                     mode):

                       ADC,CLR,COM,INC,DEC,NEG,TST,ROR,ROL,ASR,ASL,SWAB,NOP

                     Double Operand Instructions (both word and byte modes):

                       MOV,CMP,BIT,BIC,BIS,ADD,SUB

                     Branch Instructions Tested:

                       BR,BNE,BEQ,BPL,BMI,BCC(BHIS),BCS(BLO)
                       BGE,BLT,BGT,BLE,BHI,BLOS,BVC,BVS

                     Jump and Miscellaneous Instructions Tested:

                       JMP,JSR,RTS,SOB,MTPS,MFPS
                       CCC,CLN,CLV,CLZ,SEN,SEV,SEZ

                     Addressing Modes Tested:

                       All 8 addressing modes are tested.

                     The PDP-11  instruction  set  test  uses  two  methods  of
                     reporting  errors.   During  the initial part of the test,
                     errors result in an infinite program loop at the  location
                     where  the  error was detected.  During the latter part of
                     the test, (when enough instructions have been tested), the
                     'FAULT' lamp mechanism is used to report failures (section
                     2.1.1).
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP            Page 11
          TEST SUMMARIES


              4.2    TEST 1 - PROGRAM MEMORY (SWAP BITS)

                     The memory modules designed for the HSC50 include  special
                     logic  that allows the address range of the Program memory
                     to be changed.  The address range of the Program memory is
                     controlled  by  two bits in the P.ioc's Control and Status
                     Register (CSR):  the SWAP BANKS bit, and the  SWAP  BOARDS
                     bit.  The purpose of this test is to verify that these two
                     bits can be set and cleared.  (The actual memory switching
                     is  not  tested,  just  the ability of the bits to set and
                     clear.) A failure in this test indicates  that  the  P.ioc
                     module must be replaced.

              4.3    TEST 2 - PROGRAM MEMORY (VECTOR AREA)

                     In order for the HSC50 Control Program  to  function,  the
                     first  2,048  bytes  of  Program  memory  must  be working
                     (addresses 000000 thru 003777).  This test  verifies  that
                     the  first  part of Program memory works properly.  If the
                     test fails, the SWAP BANKS and SWAP  BOARDS  features  are
                     used  in  an attempt to swap a good portion of memory into
                     the 000000 thru 0003777 address range.  If the test  still
                     fails after all combinations of SWAP BANKS and SWAP BOARDS
                     have been tried, a Program memory error  is  reported  via
                     the  Fault  lamp  mechanism (section 2.1.1).  A failure in
                     this  test  indicates  that  the  M.std  module  must   be
                     replaced.

              4.4    TEST 3 - PROGRAM MEMORY (8 KWORD PARTITION)

                     After verifying that the first part of Program  memory  is
                     working,  the bootstrap tries to find a good 8 Kword chunk
                     of Program memory  between  address  0004000  and  address
                     160000.   This  partition  will  be  used to load the INIT
                     P.IOC TEST from the TU58.  If  a  large  enough  chunk  of
                     memory  can't be found, a Program memory error is reported
                     via the Fault lamp mechanism.   A  failure  in  this  test
                     indicates that the M.std module must be replaced.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP            Page 12
          TEST SUMMARIES


              4.5    TEST 4 - TU58 TESTS

                     The goal of the TU58 test is to find a working  TU58  tape
                     drive  that  contains a cassette with a bootable image.  A
                     bootable image is identified by a PDP-11  NOP  instruction
                     in  the first word of the image.  Once a suitable drive is
                     found, the first 8 blocks of the tape are loaded into  the
                     8  Kword  partition  found in test 3.  The 8 blocks loaded
                     consist of the first 5 blocks of the INIT P.IOC TEST,  the
                     RT-11  Volume  ID  block,  and  the  first RT-11 directory
                     segment on the tape.  (The directory blocks are loaded  at
                     this time to save directory look-up time in the INIT P.IOC
                     TEST).

                     The TU58 drives are tested in serial order until the first
                     working  drive  is  found  that  also  contains a bootable
                     image.  The order of testing is as follows:

                         CSR    UNIT    (SYMBOLIC NAME)
                       ------   ----    ---------------
                       177520    0        $SL1
                       177520    1        $SL1
                       177530    0        $SL2
                       177530    1        $SL2
                       177560    0        $SL0 (console)
                       177560    1        $SL0

                     If no suitable TU58  drive  is  found,  a  Tape  error  is
                     displayed via the Fault lamp mechanism.  An error table is
                     maintained in Program memory addresses 000400 thru 000412,
                     which remembers why each rejected TU58 drive failed.  Each
                     word of the table corresponds to one TU58 unit.  The lower
                     byte  of each word contains a failure code assigned by the
                     bootstrap software, which  specifies  why  the  drive  was
                     rejected  (see  definition  of  software  error  codes  in
                     section 4.5.1 below).   If  the  TU58  controller  sent  a
                     radial  serial  end  packet  with an error code, this code
                     will be stored in the upper byte of  the  error  word  for
                     that  TU58  drive (see definition of TU58 end packet error
                     codes in section 4.5.2 below).  The error  table  is  laid
                     out as follows:

                           ADDRESS   CSR/UNIT
                           000400    177520/0
                           000402    177520/1
                           000404    177530/0
                           000406    177530/1
                           000410    177560/0
                           000412    177560/1

                     If a TU58 controller fails to synchronize,  or  fails  its
                     self-test,  the software error code will be stored in unit
                     0's error table entry, and unit 1 of that controller  will
                     not be tried.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP            Page 13
          TEST SUMMARIES


                     If the boot fails with a TU58 error, and a local  terminal
                     is  available,  the  PDP-11's  ODT  feature may be used to
                     examine the TU58 error table to determine  why  each  TU58
                     drive  failed  the test (remember that the bootstrap tries
                     all drives before declaring an error).  Do  the  following
                     to examine the TU58 error table:

                       a) Depress the BREAK key on the local terminal

                       b) The terminal should  type  out  the  address  of  the
                       current  instruction  of  the bootstrap, and then prompt
                       for input with an '@' character.

                       c) Type '400/' (without the quotes)

                       d) The terminal should print  the  (octal)  contents  of
                       address 000400

                       e) Type 'linefeed' to examine the rest of the table.

                       f) The low byte of each word in  the  table  contains  a
                       software error code assigned by the bootstrap.  Refer to
                       section 4.5.1 below for  the  meaning  of  the  software
                       error codes.

                       g) The high byte of each word of the table  contains  an
                       error code sent by the TU58 controller in an end packet,
                       or a zero if no error code was sent by  the  controller.
                       Refer to section 4.5.2 below for the meaning of TU58 end
                       packet error codes.
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP            Page 14
          TEST SUMMARIES


              4.5.1  TU58 SOFTWARE ERROR CODES

                     These error codes are assigned by the  bootstrap  software
                     to  indicate  why a particular TU58 drive was not used for
                     booting.

                        CODE(octal)    MEANING
                        -----------    -------
                          0        No error
                          1        NXM trap while accessing CSR's
                          2        TU58 sync sequence failed
                          3        TU58 failed its self-test
                          4        Drive did not contain bootable image
                          5        Checksum error in received packet (note 1)
                          6        Timeout on Transmitter Ready bit
                          7        Timeout on Receiver Done bit
                         10        Overrun or Framing error
                         11        Unknown packet type received

                     NOTE 1 - Checksum  Errors  -  When  a  checksum  error  is
                     detected in a received radial serial packet, the bootstrap
                     will save the expected and actual checksum.  The  expected
                     checksum  (as  computed  from  the bytes of the packet) is
                     stored in Program memory location 000414, and  the  actual
                     checksum  (as  received  at the end of the packet) will be
                     stored  in  location  000416.   If  more  than  one  drive
                     produces  a  checksum error, the checksum words pertain to
                     the last drive tested.  A local terminal  is  required  to
                     examine  the  expected and actual checksum, using the same
                     procedure described in the preceeding section (4.5).
          User Documentation for HSC50 - P.IOC ROM BOOTSTRAP            Page 15
          TEST SUMMARIES


              4.5.2  TU58 END PACKET ERROR CODES

                     The following table lists the error codes  that  the  TU58
                     sends  in radial serial end packets.  The codes are listed
                     as they will appear when the TU58 error  table  words  are
                     examined  (I.E.   the  codes  are in the upper byte of the
                     word).  All values are  in  the  octal  radix.   The  'xx'
                     portion of each word represents the software error code in
                     the lower byte of each word.

                       ERROR WORD CONTENTS      MEANING
                       -------------------      -------
                           1774xx               Self-test failed
                           1770xx               End of Tape encountered
                           1750xx               Hard Read Error
                           1740xx               Bad Unit Number Given
                           1734xx               No Cassette Mounted
                           1724xx               Write Protected
                           1674xx               Data Check Error
                           1600xx               Seek Error
                           1574xx               Motor Stopped
                           1500xx               Bad Op Code
                           1444xx               Bad Block Number Given

              4.6    TEST 5 - TRANSFER CONTROL TO LOADED IMAGE

                     This part of the bootstrap is not actually a test, but  is
                     given  a  test  number  in  case  an  error occurs in this
                     section of code.  The PDP-11 general registers are  loaded
                     with certain parameters (CSR and Unit of load device, base
                     address and size  of  partition,  etc.),  then  the  image
                     loaded  from the TU58 is initiated by jumping to the first
                     instruction.  Any errors that occur in this  part  of  the
                     bootstrap   would   probably   be   unexpected   traps  or
                     interrupts,  caused  by  intermittent   P.ioc   or   M.std
                     failures.   When  the  loaded  image is started, the STATE
                     lamp will be lit, and the INIT lamp will be turned off.
HSC-50 CONTROLLER DIAGNOSTICS












                            CHAPTER 4

           CONTROLLER DIAGNOSTICS Company Confidential



4.1  INTRODUCTION

This  chapter  describes  how  to  run   the   HSC50   controller
diagnostics using the local terminal.  Included is an abstract of
the diagnostics and how to start  them  and  how  to  answer  the
parameters.   If  you  can not interpret the error printouts, you
should refer to the explanation of the error  on  microfiche  for
the particular diagnostic.


                              NOTE


               In this chapter the letter K stands
               for  the  collection  of the K.sti,
               k.sdi, and K.ci modules.





4.2  INITIALIZATION DIAGNOSTICS

The  HSC50  subsystem  contains  a  set  of  initialization-level
diagnostics.    The   hard  core  subset  of  the  initialization
diagnostics   are   read-only   memory    (ROM)    resident    or
programable-read-only  memory  (PROM)  resident;   the  rest  are
stored on the HSC50 Offline DIAGNOSIC tape cartridge.

At initialization time, the bootstrap diagnostic that resides  in
the  P.ioc  ROM  is  executed  first.   Then a more comprehensive
initialization diagnostic is loaded from the TU58 tape  cartridge
and  executed.   At  appropriate  points  in  the  initialization
sequence the on-board PROM-resident microdiagnostics in the  K.ci
and  in  the individual copies of the K.sdi and K.sti are, one by
one, triggered into execution.



                               4-1
CONTROLLER DIAGNOSTICS Company Confidential
INITIALIZATION DIAGNOSTICS


The full set of initialization diagnostics is executed each  time
the  subsystem  is  powered up or the INIT switch is pushed.  The
result is a complete sanity  test  and  bootstrap  of  the  HSC50
subsystem  itself  in  2  minutes or less.  This process does not
extend  to  drive-level  tests  (except   for   verification   of
communication paths to/from the drives).

The following is a  description  of  the  set  of  initialization
diagnostics.



4.2.1  P.IOC ROM BOOTSTRAP

The P.ioc read-only memory (ROM) bootstrap diagnostic  tests  the
following logic.

      o  F11

         Tests a subset of the PDP-11  instruction  set  and  the
         addressing  modes  used  in testing the remainder of the
         hardcore and in loading the INIT P.ioc diagnostic.

      o  Memory

         Tests that amount of the P.ioc program  memory  that  is
         required   to  load  the  next  diagnostic  (INIT  P.ioc
         diagnostic).   The  memory  test  consists  of   address
         verification and data-reliability verification.

      o  TU58

         Tests the functionality of the data and control path  to
         the  TU58.   It  also  tests  the ability of the TU58 to
         perform its self-test command.


Finally, the INIT P.ioc test or Offline P.ioc test is  loaded  to
program  memory  and  started.   The  diagnostic  that  is loaded
depends on which of the HSC50 tape cartridges is mounted.  If the
CONTROL  PROGRAM  tape  is  mounted,  the INIT P.ioc test will be
loaded.  If the OFFLINE DIAGNOSTIC tape is mounted,  the  Offline
P.ioc test will be loaded.

The bootstrap is the  first  step  in  the  HSC50  initialization
process,  and  is  run for every bootstrap or reload of the HSC50
Control Program (in some documentation  known  as  CRONIC).   The
bootstrap  is  initiated  automatically  each  time  the HSC50 is
powered-on, and is also initiated by the  HSC50  Control  Program
when a software reboot is required.



                               4-2
                      CONTROLLER DIAGNOSTICS Company Confidential
                                       INITIALIZATION DIAGNOSTICS


The bootstrap is a  PDP-11  program,  written  to  execute  in  a
stand-alone  environment  (no  other  software processes co-exist
with the bootstrap).

Bootstrap failures are reported via the  operator  control  panel
indicators,  which  specifies the module (P.ioc, memory, or TU58)
which is the most likely cause  of  the  problem.   In  addition,
certain information relating to TU58 failures is saved in a table
in the program memory, to assist in diagnosing tape errors.

This diagnostic is the first software executed when the HSC50  is
powered-on.    No  other  diagnostics  are  executed  before  the
bootstrap.

To initiate the bootstrap, press the INIT  switch  on  the  HSC50
Operator Control Panel.



4.2.1.1  In Case Of Trouble -

Most failures in the bootstrap will result in lighting the  FAULT
indicator  on the HSC50's operator control panel.  Depressing the
FAULT  switch  momentarily  will  cause  a  failure  code  to  be
displayed in the operator control panel indicators.

If  a  failure  occurs  in  the  tests  of  the  PDP-11's   basic
instruction  set,  the  FAULT indicator can not be used to report
the failure.  Instead  the  PDP-11  will  execute  a  branch  dot
(example:   BR  .),  and will not continue the bootstrap program.
Failures of this type can be identifed by the failure of the INIT
indicator to light.  (The INIT indicator lights immediately after
the  basic  PDP-11  tests  complete.)  If  a  local  terminal  is
connected, the exact instruction that failed can be determined by
depressing the terminal's  BREAK  key,  and  noting  the  address
displayed  on  the  terminal.   Using a listing of the bootstrap,
this address can be used to find the instruction that failed.



4.2.1.2  Progress Reports -

The bootstrap does not issue progress reports in the usual sense.
However,  the  following  describes  certain  indications  of the
bootstrap's progress which are visible to you.

      o  Indicators clear - One of the first operations performed
         by the bootstrap is to clear all of the HSC50's operator
         control panel indicators.  If  the  indicators  fail  to
         clear  immediately  after  the bootstrap is initiated, a



                               4-3
CONTROLLER DIAGNOSTICS Company Confidential
INITIALIZATION DIAGNOSTICS


         failure of the P.ioc is  probable.   (Circuitry  on  the
         P.ioc module is responsible for initiating the bootstrap
         program.)

      o  INIT indicator - The INIT indicator will light  as  soon
         as  the  basic tests of the PDP-11's instruction set are
         completed.  These tests will  normally  complete  within
         milli-seconds after the bootstrap is initiated.  Failure
         of the INIT indicator to light indicates  a  failure  in
         the P.ioc's PDP-11 processor.

      o  Tape motion  - Following the tests of the PDP-11 and the
         program  memory, the bootstrap will try to load the INIT
         P.ioc or OFFLINE P.ioc diagnostic from  the  TU58.   The
         run indicator on the tape drive should begin to blink as
         the load is proceeding.

      o  State Indicator - Notice that the state indicator lights
         when  the  INIT  P.ioc  diagnostic  or the Offline P.ioc
         diagnostic begins to  execute.   Notice  that  when  the
         State   indicator   is   lit   the   INIT  indicator  is
         extinguished.




4.2.1.3  Test Termination -

Once initiated, the bootstrap  can  only  be  terminated  in  the
following ways.

     1.  Bootstrap completes successfully and  transfers  control
         to  the  INIT  P.ioc  diagnostic  or  the  Offline P.ioc
         diagnostic.

     2.  Bootstrap is halted by depressing the BREAK key  on  the
         local terminal.

     3.  Bootstrap is restarted by pressing the INIT switch.




4.2.1.4  Error Reporting Scheme -

The bootstrap is designed to operate without  a  local  terminal,
thus  the  bootstrap  cannot  use  the  terminal  as  a reporting
mechanism for errors.   Instead,  the  HSC50's  operator  control
panel lamps are used to report errors, and to indicate the module
(P.ioc, memory, or TU58) which is the most likely  cause  of  the



                               4-4
                      CONTROLLER DIAGNOSTICS Company Confidential
                                       INITIALIZATION DIAGNOSTICS


error.

When the bootstrap detects an error,  it  will  light  the  FAULT
indicator  on  the  operator control panel.  Depressing the FAULT
swith momentarily will cause the bootstrap to display  a  failure
code  in the operator control panel indicators.  The failure code
(refer to Figure 4-?)  will  blink  on  and  off  at  1/2  second
intervals.   The  bootstrap  may  be  reinitiated  by momentarily
depressing the INIT switch on the operator control panel.

The following table  lists  all  the  fault  codes  that  can  be
displayed  in the HSC50's Operator Control Panel lamps.  Only the
P.ioc, Memory, and TU58 fault codes are used  by  the  bootstrap.
The other fault codes are displayed by the INIT P.ioc test or the
HSC50 Control Program.


                      ------   ------   ------   ------   ------ 
                     |      | |      | |      | |      | |      |
                     |INIT  | | FAULT| |ONLINE| |      | |      |
                     |      | |      | |      | |      | |      |
                      ------   ------   ------   ------   ------ 
-----------------------------------------------------------------
K.PLI FAILURE        |  OFF  |  OFF  |   OFF   |  OFF   |  ON   |
-----------------------------------------------------------------
K.SDI FAILURE        |  OFF  |  OFF  |   OFF   |  ON    |  OFF  |
-----------------------------------------------------------------
K.STI FAILURE        |  OFF  |  OFF  |   OFF   |  ON    |  ON   |
-----------------------------------------------------------------
P.IOC MODULE FAILURE |  ON   |  OFF   |  OFF   |  OFF   |  ON   |
-----------------------------------------------------------------
MEMORY MODULE FAILURE|  ON   |  OFF   |  OFF   |  ON    |  OFF  |
-----------------------------------------------------------------
TU58 FAILURE         |  ON   |  OFF   |  OFF   |  ON    |  ON   |
-----------------------------------------------------------------
PILA MODULE FAILURE  |  ON   |  OFF   |  ON    |  OFF   |  OFF  |
-----------------------------------------------------------------
LINK MODULE FAILURE  |  ON   |  OFF   |  ON    |  OFF   |  ON   |
-----------------------------------------------------------------
MISSING FILES        |  ON   |  OFF   |  ON    |  ON    |  OFF  |
-----------------------------------------------------------------
ERROR LOG ATTENTION  |  ON   |  OFF   |  ON    |  ON    |  ON   |
-----------------------------------------------------------------
NO K'S IN SYSTEM     |  ON   |  ON    |  OFF   |  OFF   |  OFF  |
-----------------------------------------------------------------
REBOOT WHILE BOOTING |  ON   |  ON    |  OFF   |  OFF   |  ON   |
-----------------------------------------------------------------
SW INCONSISTENCY     |  ON   |  ON    |  OFF   |  ON    |  OFF  |
-----------------------------------------------------------------




                               4-5
CONTROLLER DIAGNOSTICS Company Confidential
INITIALIZATION DIAGNOSTICS


        Figure 4-?  Operator Control Panel Failure Codes





4.2.2  INIT P.ioc Diagnostic

The INIT P.ioc diagnostic completes the testing begun by the  ROM
bootstrap.  The following sections of logic are tested:

      o  P.IOC

         The remainder of the P.ioc logic that was not tested  by
         the  bootstrap  is  tested.   This includes the complete
         instruction set, interrupts and traps, memory management
         (including  the control memory windows), and the control
         memory  lock-cycle  circuitry.   Any  failures  detected
         results  in  the display of an error code in the HSC50's
         operator control panel indicators.

      o  Memory

         All three HSC50 memories  are  completely  tested.   The
         program memory is tested from the P.ioc, but the control
         and data memories  are  tested  by  a  K  module,  under
         control  of the P.ioc.  Data parity errors are forced to
         check the parity error detection logic.

      o  K.sti, K.sdi, and K.ci

         All K modules in the system are enabled (one at a  time)
         and  the  status  is collected and placed in a table for
         the HSC50 control program's  INIT  process.   When  a  K
         module   is   enabled,  it  will  automatically  execute
         internal microdiagnostics.   These  diagnostics  perform
         the following functions:

          o  Test  the  microprocessor's  instruction   set   and
             addressing functions

          o  Test ROM (sequencer, checksum, parity, etc.)

          o  Test special logic that is unique to that particular
             module


         When the K  module  completes  its  microdiagnostics,  a
         status  code  is  passed  to the P.ioc.  The status code
         indicates the type  of  K  (sdi,sti,ci)  module  if  the



                               4-6
                      CONTROLLER DIAGNOSTICS Company Confidential
                                       INITIALIZATION DIAGNOSTICS


         diagnostics completed without errors, or the status code
         represents an error code  if  the  diagnostics  found  a
         failure.

         As the  INIT  P.ioc  diagnostic  is  testing  the  HSC50
         Control  and Data memories, it is also loading the HSC50
         Control program.  When the memory  tests  are  complete,
         control  is  passed  to  the  INIT  process of the HSC50
         control program.  At this  point  the  STATE  lamp  will
         begin to blink on and off.

         Fault isolation in the INIT P.ioc test is to the  module
         level.   The fault code will identify the module that is
         the most likely cause of a failure.




4.2.2.1  Start-Up Procedure -

Follow the steps below to initiate the INIT P.IOC diagnostic:

     1.  Insert the HSC50 CONTROL PROGRAM tape cartridge into the
         TU58's unit 0 drive (left hand drive).

     2.  Power-on the HSC50, or  depress  and  release  the  INIT
         switch on the HSC50 operator control panel.

     3.  The TU58 run indicator should light within  10  seconds,
         indicating  that the bootstrap is loading the INIT P.ioc
         diagnostic to program memory.

     4.  As the  INIT  P.ioc  diagnostic  is  testing  the  HSC50
         memories  the  TU58  motion light will blink on and off,
         indicating the HSC50 Control Program software  is  being
         read from the tape cartrige to program memory.

     5.  When the INIT P.ioc test  initiates  the  HSC50  Control
         program, the STATE lamp will begin to blink on and off.

     6.  After about 3 minutes  of  loading,  the  HSC50  control
         program   will   indicate  it  has  loaded  properly  by
         displaying its name and version.

         HSC50 Version nnnn DD-MMM-YYYY tt:tt:tt








                               4-7
CONTROLLER DIAGNOSTICS Company Confidential
INITIALIZATION DIAGNOSTICS


4.2.2.2  In Case Of Trouble -

If the test fails to load when the above  start-up  procedure  is
followed, refer to the items in the checklist below.

     1.  Try booting the  tape  from  the  TU58's  unit  1  drive
         (right-hand  drive).   If  your system has more than two
         TU58 drives, try booting from one of the other drives.

     2.  Try booting another tape  cartridge.   If  another  tape
         cartridge  will  boot,  the  original  tape  is probably
         damaged or worn.

     3.  Try booting the HSC50 Offline DIAGNOSTIC tape cartridge.
         This  tape  contains the OFFLINE P.ioc diagnostic, which
         provides more extensive error  reporting  features  than
         the INIT P.ioc diagnostic.




4.2.2.3  Progress Reports -

The INIT P.ioc diagnostic does not issue  any  progress  reports.
If  the test runs to completion with no errors, the HSC50 control
program software is  loaded  and  started.   If  the  P.ioc  test
detects  an  error,  the FAULT indicator on the HSC50 front panel
will light.



4.2.2.4  Test Termination -

Once initiated, the INIT P.ioc diagnostic can only be  terminated
by  halting  the machine and rebooting, or by depressing the INIT
switch.



4.2.2.5  Error Reporting Scheme -

The INIT P.ioc diagnostic is designed to operate without a  local
terminal, so the standard HSC50 error reporting scheme can not be
used.  Instead, all failures are reported by lighting  the  FAULT
indicator  on  the HSC50 operator control panel.  After the FAULT
indicator is lit, depressing the  FAULT  switch  results  in  the
display   of  a  failure  code  in  the  operator  control  panel
indicators.  The  failure  code  indicates  which  of  the  HSC50
modules  is  the  most  probable  cause  of  the failure that was
detected.  The failure code will blink on  and  off  with  a  one



                               4-8
                      CONTROLLER DIAGNOSTICS Company Confidential
                                       INITIALIZATION DIAGNOSTICS


second  interval  until the FAULT swiatch is again depressed.  To
restart the boot procedure, depress the INIT switch.  To identify
the probable failing module, refer to Figure 4-?.



4.2.3  INIT K.sdi Microdiagnostic

The K.sdi resident diagnostic is totally contained in  the  K.sdi
ROM.   It  is  initiated  by  a  signal over the control bus.  It
reports pass/fail status in a dedicated location  of  the  PDP-11
I/O  page.   Portions  of  the  resident code can be initiated on
command to K.sdi.  The basic test sequence for K.sdi includes the
following.

      o  Microprocessor's instruction set and addressing

      o  ROM tests (sequencer, checksum, parity, etc)

      o  Drive interface test

      o  Special tests of hardware unique to the K.sdi module


This test detects and identify 95% of all hard  failures  in  the
K.sdi.



4.2.4  INIT K.ci Microdiagnostic

The K.ci resident diagnostic is totally  contained  in  the  K.ci
ROM.   It  is  initiated  by  a  signal over the control bus.  It
reports pass/fail status in a dedicated location  of  the  PDP-11
I/O  page.   Portions  of  the  resident code can be initiated on
command to K.ci.  The basic test sequence for K.ci  includes  the
following.

      o  Microprocessor's instruction set and addressing

      o  ROM tests (sequencer, checksum, parity, etc)

      o  Host interface test

      o  Special tests of hardware unique to the K.ci module


This test is designed to detect and  identify  95%  of  all  hard
errors in the K.ci.




                               4-9
CONTROLLER DIAGNOSTICS Company Confidential
INITIALIZATION DIAGNOSTICS


4.2.5  INIT K.sti Microdiagnostic

The K.sti resident diagnostic is totally contained in  the  K.sti
ROM.   It  is  initiated  by  a  signal over the control bus.  It
reports pass/fail status in a dedicated location  of  the  PDP-11
I/O  page.   Portions  of  the  resident code can be initiated on
command to K.sti.  The basic test sequence for K.sti includes the
following.

      o  Microprocessor's instruction set and addressing

      o  ROM tests (sequencer, checksum, parity, etc)

      o  Tape drive interface test

      o  Special tests of hardware unique to the K.sti module


This test is designed to detect and  identify  95%  of  all  hard
failures in the K.sti.



4.3  PERIODICALLY SCHEDULED DIAGNOSTICS

Periodically scheduled diagnostics are tests  that  will  be  run
periodically  when the subsystem has little or no I/O to perform.
These  tests  will  run  very  quickly  (in  terms  of  10's   of
milliseconds)  to  avoid throughput impact.  For this reason, the
tests are microcoded as much as possible.  Where  the  tests  are
macrocode,  they  are  co-resident  in  the  subsystem  with  the
functional code.



4.3.1  Start-up Procedures

Normally the periodic diagnostics are enabled within the  HSC  by
default  with  a  time  interval  of  10 minutes.  To verify that
periodic  diagnostics  are  enabled  the  user  should  type  the
following SETSHOW command:

     1.  Type Control Y (Remember - no carriage  return  required
         for control characters)

     2.  The HSC50 will respond with a HSC50> prompt

     3.  Type SHOW SYSTEM





                              4-10
                      CONTROLLER DIAGNOSTICS Company Confidential
                               PERIODICALLY SCHEDULED DIAGNOSTICS


     4.  The system will load the SETSHOW program from  the  TU58
         tape  system.   This  may  take  as  much as a minute to
         complete.  While the load is in progress, the HSC50 will
         not  respond  to  Control-Y.   When the program has been
         successfully loaded you will see among the rest  of  the
         HSC50  system  data  the diagnostic flags and intervals.
         Periodic diagnostics are enabled if included within  the
         information is the following line:

         Periodic Diagnostics Interval - dd - enabled

         where:  dd is the time interval

     5.  Should periodic diagnostics be disabled, or  should  the
         user  wish  to  change  the time interval, the following
         SETSHOW command should be used:

     6.  Type Control Y (Remember - no carriage  return  required
         for control characters)

     7.  The HSC50 will respond with a HSC50> prompt

     8.  Type SET PERIODIC dd

     9.  Notice that the SETSHOW program  will  insist  that  the
         HSC50  be  rebooted for this command to take affect.  If
         you wish to enable periodic diagnostics you must  answer
         'YES' to the following prompt:

         Rebooting HSC;  Y to continue, CTRL/Y to abort:

    10.  By typing a 'Y' you will notice that the HSC will reboot
         and  enable  the  periodic diagnostics for the specified
         time interval.

    11.  To  diasable  periodic  diagnostics  a  simliar  SETSHOW
         should be used which is described as follows:

    12.  Type Control Y (Remember - no carriage  return  required
         for control characters)

    13.  The HSC50 will respond with a HSC50> prompt

    14.  Type SET NOPERIODIC

    15.  Notice that the SETSHOW program  will  insist  that  the
         HSC50  be  rebooted for this command to take affect.  If
         you wish to disable periodic diagnostics you must answer
         'YES' to the following prompt:




                              4-11
CONTROLLER DIAGNOSTICS Company Confidential
PERIODICALLY SCHEDULED DIAGNOSTICS


         Rebooting HSC;  Y to continue, CTRL/Y to abort:

    16.  By typing a 'Y' you will notice that the HSC will reboot
         with periodic diagnostics disabled.


The following  is  a  description  of  the  set  of  periodically
scheduled diagnostics.



4.3.2  Periodic K.sdi And K.sti Integrity

This diagnostic verifies the operation of  the  K.sdi  and  K.sti
hardware.   Specifically  it  tests  the  SERDES,  RSGEN, and the
microprocessors.  The data SERDES is tested by  the  sending  and
receiving  data in a loopback mode.  The microprocessor is tested
by executing a series of instructions and testing for an expected
result.   These  tests  also  include  verification  of all fault
detection capabilities  in  K.sdi  and  K.sti  by  simulating  or
forcing the detectable conditions.  The fault isolation available
through this test is strictly  limited  by  the  fault  isolation
capabilities of the K microdiagnostics themselves.



4.3.3  Periodically Scheduled Memory & Bus Integrity

This diagnostic performs tests of the P.ioc's  Control  and  Data
Bus  tranceivers.   Addresses  and data are wrapped back from the
output of the tranceivers to insure  that  proper  addresses  and
data are generated.  A test of the P.ioc's parity detection logic
is also performed by writing  bad  parity  and  insuring  that  a
parity trap occurs when the location is read.



4.4  IN-LINE DIAGNOSTICS

In-line diagnostics are diagnostics that execute in the subsystem
while  the  subsystem remains on-line to the host.  The subsystem
may be performing functional operations while  these  diagnostics
are  executing, but the subsystem resource being diagnosed cannot
itself be in functional use;  it is dedicated to diagnosis.   The
in-line diagnostic may need other resources of the subsystem, but
it  will  compete  with  other  processes  performing  functional
operations for use of the shared resources.






                              4-12
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


The in-line diagnostics are on the  HSC50  CONTROL  PROGRAM  tape
cartridge  and  are  initiated in two ways, automatic and demand.
Automatic initiation is started by the HSC50 control program if a
error threshold is crossed.  Demand initiation is done by you.

If the HSC50 control  program  initiates  an  in-line  diagnostic
automatically,  you  will  receive  the  following display on the
local terminal.

NNNNNN>A> Execution Starting


                              NOTE

               NNNNNN in the display is a mnemonic
               for the in-line diagnostic name.



The following is a description of the set of in-line diagnostics.



4.4.1  In-Line TU58 Diagnostic

The INLINE TU58 diagnostic is designed to  test  any  TU58  drive
attached  to  the  HSC50.  This test runs concurrently with other
HSC50 conrol program processes, and uses the  services  of  HSC50
control  program  and  the  diagnostic execution monitor (DEMON).
This test can be invoked by an operator via the local terminal or
DUP command.

Because the HSC50 Control program tests the TU58 each time it  is
used,  the  Inline  TU58  diagnostic  performs  minimal  testing.
Several writes  and  reads  are  performed  to  test  the  TU58's
internal data paths and read/write electronics.

This diagnostic tests only the TU58 itself,  and  the  data  path
(serial  line)  between the P.ioc and the TU58.  All other system
hardware is assumed to be working.



4.4.1.1  Start-Up Procedure -

To start this test, type a

^Y (control-Y)





                              4-13
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


to get the attention of  the  HSC50  control  program's  keyboard
monitor.   The  keyboard  monitor  will  respond to the ^Y with a
prompt (HSC50>).  Then type

RUN ILTU58<CR>

to initiate the in-line TU58 diagnostic.

If the HSC50 System Tape is mounted on a failing tape  drive,  it
may not be possible to load the INLINE TU58 TEST from that drive.
In this case the HSC50 System Tape should  be  moved  to  another
drive,  and  the system rebooted.  Once the boot is complete, the
test can be invoked to check out the failing  drive.   Note  that
rebooting  the  HSC50  will have a performance impact on any Host
I/O that is in progress.



4.4.1.2  Test Parameter Entry -

The device name of the TU58 drive to test is the  only  parameter
sought  by  this  test.   When the test is invoked, the following
prompt is displayed:

Device Name of TU58 to test (A) [] ?

The (A) indicates that an  ASCII  string  is  expected.   The  []
indicates  that there is no default value for the parameter.  The
user must enter one of the following strings.

     1.  DD0:
     2.  DD1:
     3.  DD2:
     4.  DD3:
     5.  LB:


If one of the above strings in not entered, the test will print

ILTU58>D>Illegal Device Name

and the prompt will be repeated.


                              NOTE


               The string LB:  indicates the  TU58
               unit from which the system booted.




                              4-14
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


4.4.1.3  Setting/Clearing Flags -

This diagnostic does not support any flags.  This  diagnostic  is
only  intended  to  verify  that  a  pariticular  TU58  drive and
controller combination is working or failing, and is not intended
to  be  used  as  a trouble-shooting aid.  Looping the test would
result in media damage if allowed to loop  too  long,  since  the
test  always reads and writes the same block of the tape.  If the
test indicates that a  particular  controller  or  drive  is  not
operating correctly, the proper repair strategy is to replace the
drive and/or controller.



4.4.1.4  Progress Reports -

At the end of the test, the following messages is  displayed  (by
DEMON).

ILTU58>D>tt:tt Execution Complete

where:  tt:tt = current time



4.4.1.5  Test Termination -

This diagnostic can be terminated by typing a

^Y (control-Y).

The  diagnostic  will  automatically   terminate   itself   after
reporting most errors.  The following lists the two exceptions.

     1.  If the error displayed is  retries  required,  the  test
         will continue

     2.  If the error displayed is Data Compare Error,  the  test
         will continue




4.4.1.6  Error Message FORMAT -

All error  messages  produced  by  the  in-line  TU58  diagnostic
conform  to the HSC50 diagnostic error message format.  The first
line of the error message contains general information concerning
the  error.   The  second  line  is a text message describing the
nature of the error.  Lines 1 and 2 are mandatory, and appear  in



                              4-15
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


all  error  messages.   Line 3, and any succeeding lines, display
additional information, and are  optional.   Optional  lines  are
displayed  for  certain  errors  that  need to provide additional
information.  Listed below is a typical error message.

ILTU58>D>tt:tt T#aaa E#bbb U-ccc        (mandatory line)
<Text string describing error>          (mandatory line)
FRU1-dddddd FRU2-eeeeee                 (optional line)
MA -ffffff                              (optional line)
EXP-yyyyyy                              (optional line)
ACT-zzzzzz                              (optional line)

WHERE:

tt:tt     =  current time
aaa       =  Decimal # denoting test that failed
bbb       =  Decimal # denoting error detected
ccc       =  Unit   of drive being tested
dddddd    =  Name of most likely Field Replaceable Unit
eeeeee    =  Name of next most likely Field Replaceable Unit
MA        =  Media Address
ffffff    =  Octal # denoting Offset within block
yyyyyy    =  Octal # denoting data expected
zzzzzz    =  Octal # denoting data actually found



4.4.2  In-Line Memory Diagnostic

This diagnostic test Data buffers which  produced  parity  errors
while  being  used by the HSC50 Control program.  Failing buffers
are placed on a  queue,  and  the  Inline  Memory  diagnostic  is
initiated  automatically.   When  the diagnostic gets a buffer to
test, it checks to see if the same buffer was previously  tested.
If the buffer was previously tested, it is sent to a queue of bad
buffers and is retired from  service.   If  the  buffer  was  not
previously  sent  to  the Inline Memory Diagnostic, the buffer is
tested.  If the test passes, the buffer is put  back  in  service
for  further use by the Control program.  If the buffer fails, it
is sent to a queue of bad buffers and is retired from service.



4.4.3  In-Line Disk Drive Diagnostic

The Inline Disk Drive diagnostic  (IDDD)  tests  any  disk  drive
connected  to  the HSC50 controller.  IDDD runs concurrently with
other HSC50 software processes, and  uses  disk  functional  code
subroutines  to  test  disk  drives.   The  SDI interface and the
drive's read/write electronics  are  tested.   In  addition,  the



                              4-16
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


drive is directed to execute its own diagnostics.

The major funtion served by IDDD is to diagnose a  drive  failure
and  isolate  the failure to a field replacable unit (FRU).  This
unit may be the K.sdi to which the drive is  connected,  the  SDI
cable, or the drive itself.



4.4.3.1  Start-Up Procedure -

The Inline Disk Drive diagnostic may be  initiated  automatically
or on demand.


                              NOTE


               Included in the  description  below
               are  several references to the user
               typing a response or command to the
               HSC50  system.   Implied  with each
               reference is a carriage  return  to
               end the response.  The HSC50 system
               will   recognize    only    control
               characters   without   a   carriage
               return.  Therefore, the user should
               type a carriage return to terminate
               every command or response entered.



Automatic Initiation

     The SDI manager may initiate IDDD automatically when  it  is
     unable  to  communicate with a drive.  The Error Handler may
     intiate IDDD when  an  error  threshold  is  exceeded  in  a
     specific   drive.   In  either  case  IDDD  will  cause  the
     initiation  of  the  full  complement  of   drive   resident
     diagnostics.   IDDD will also try to conduct a series of I/O
     operations on the disk drive.   The  user  will  receive  no
     prompts,  but  instead  will  see the following on the local
     terminal:

     IDDD  >A>Execution Starting

     Any error reports will be displayed on the user's  terminal.
     When   execution   has  completed  the  user  will  see  the
     following:




                              4-17
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


     IDDD  >A>Execution Complete.

Demand Initiation

     IDDD may  also  be  initiated  by  user  request.   Such  an
     initiation is referred to as demand initiation.

     Perform the following steps to initiate IDDD:

     1.  Type Control Y (Remember - no carriage  return  required
         for control characters)

     2.  The HSC50 will respond with a HSC50> prompt

     3.  Type RUN IDDD

     4.  The system will load the  program  from  the  TU58  tape
         system.   This may take as much as a minute to complete.
         While the load  is  in  progress,  the  HSC50  will  not
         respond   to  Control-Y.   When  the  program  has  been
         successfully loaded you will see the following message.

         IDDD  >D>Execution Starting

         Notice that this is similar to the message  received  in
         the  case of an automatic initiation of IDDD except that
         the message contains a D rather than an A.  This  is  to
         identify that this is a demand initiation of IDDD.

     5.  Notice that IDDD  will  now  prompt  the  user  for  the
         parameters   necessary.    (For  a  description  of  the
         parameters see the section below)

     6.  Notice  that  after  you  have  finished  answering  all
         prompts,  the  execution of the diagnostic will proceed.
         You will then only see error reports returned from IDDD.

     7.  Notice that when IDDD has completed all tests  requested
         and  has  reported any errors found, IDDD concludes with
         the following message.

         IDDD  >D>Execution Complete











                              4-18
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


4.4.3.2  Test Parameter Entry -

You will be prompted with the following parameters.

Drive Unit Number (U) [] ?

You enter the unit number of the drive to be tested.  There is no
default  for  this prompt.  Unit numbers are of the form 'Dnnnn',
where  nnnn  is  a  decimal  number  between  0  and  4095  which
corresponds  to  the  number  printed  on  the drive's unit plug.
Terminate the unit number with  a  carriage  return.   IDDD  will
attempt to acquire the specified unit, via the HSC50's Diagnostic
Interface.  If the unit is acquired successfully, IDDD will  next
prompt  for the number of passes to be performed (see below).  If
the  acquire  fails,  one  of  the   following   conditions   was
encountered:

     1.  The specified drive is UNAVAILABLE.  This indicates that
         the  drive  is  connected to the HSC50, but is currently
         ONLINE to a Host CPU or HSC50 utiltiy.  Drives that  are
         ONLINE cannot be diagnosed.  IDDD will repeat the prompt
         for the unit number.

     2.  The specifed  drive  is  UNKNOWN  to  the  HSC50's  Disk
         Functional  software.  Drives are UNKNOWN for one of the
         following reasons:

          o  The drive and/or K.sdi port is  broken,  and  cannot
             communicate with the Disk Functional Software.

          o  The drive  was  previously  communicating  with  the
             HSC50,  but  a  serious error occurred and the HSC50
             has ceased communicating with the drive.

         In either case, IDDD will ask the user if they desire to
         enter a Requestor and Port number.  (See below).


When IDDD cannot acquire the  unit  you  specify,  the  following
prompt will be issued:

Do you want to enter a Requestor and Port # (Y/N) [N] ?

Answer with a Y if you want to test the  drive  by  specifying  a
Requestor  and Port number.  The requestor and port number can be
determined in one of two ways:

      o  By tracing the SDI cable from the desired disk drive  to
         the  HSC50 bulkhead connector, then tracing the bulkhead
         connector to a specific  port  on  one  of  the  HSC50's



                              4-19
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


         K.sdi's.

      o  By  using  the  'Show  Disks'  command  to  display  the
         requestor  and port numbers of all known drives.  To use
         this method, exit IDDD by typing a control-Y.  Then type
         'Show Disks' in response to the HSC50 prompt.  A list of
         all known drives will be displayed.   The  display  will
         include  the  requestor  and port number for each drive.
         Each K.sdi (requestor) has four possible ports to  which
         a drive can be connected.  By inference, the port number
         of the unknown unit must be one of the ports that is not
         listed  in the 'Show Disks' display.  (Assuming that the
         K.sdi to which the unknown drive  is  connected  is  not
         defective.   Defective  K.sdi's will have an illuminated
         red LED on the lower front edge of the module.)


If you indicate that you want to  supply  a  requestor  and  port
number, IDDD will prompt:

Enter Requestor Number (2 thru 7) (D) [] ?

You enter the requestor number of the K.sdi to which the drive is
connected, then IDDD will prompt:

Enter Port Number (0 thru 3) (D) [] ?

You enter the port number by which the drive is connected to  the
K.sdi  module.   Once  a Requestor and Port are supplied to IDDD,
the program will check to insure that the specified Requestor and
Port  do not match any drive that is known to the HSC50 software.
If the Requestor and Port do not match a known drive,  IDDD  will
next  prompt  for  the  number of passes to perform, as described
below.

After getting the Unit Number (or Requestor and Port), IDDD  will
prompt:

# of Passes to Perform (1 to 32767) (D) [1] ?

Enter a decimal number between 1 and 32767, which  specifies  the
number  of times to repeat the test.  Terminate the response with
a  carriage-return.   Typing  just  a  carriage-return,   without
entering any number, will result in running the test one time.









                              4-20
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


4.4.3.3  Progress Reports -

The only progress reports that you may see during  the  execution
of  IDDD  are  the error reports from the diagnostics executed or
end of pass statements.  If no errors were found  IDDD  will  not
generate  any  additional reports.  If more than one iteration of
IDDD was requested, however, you will see the  following  message
at the end of each pass.

End Of Pass # nnnnn



4.4.3.4  Test Termination -

Upon completion of the test selected and  the  reporting  of  any
errors  found,  IDDD  will  terminate  normally.   All resources,
including the drive being tested, will be released.  If you  wish
to terminate this program before normal completion you may type a
Control Y.  Certain parts of IDDD cannot be interrupted,  so  the
Control-Y may have no effect.



4.4.4  In-Line Tape Formatter Diagnostic (ITDD)

This diagnostic tests a specific  tape  formatter  that  must  be
dedicated to the test.  The diagnostic consists of initiating all
formatter resident diagnostics, and of executing a series of  I/O
operations  on  the  drive(s)  (positioning,  reads,  and writes)
connected to this formatter.  This diagnostic provides 80%  fault
isolation  between  the  formatter,  the SI interconnect, and the
drive itself.  The error detection capabilities within the  drive
are strictly limited by the drive's self-test diagnostics.



4.4.5  In-Line Multi Drive Exerciser

The multi drive exerciser (OMDEXR)  diagnostic  exercises  either
disk  or  tape  data  transfers on 1 to 10 drives where 10 is the
maximum number of drives which we can test  simultaneously.   The
exercise  is  of  a random nature with respect to drive sequence,
data patterns, and operation sequences.   Operations  and  errors
are  counted  for  statistical  reporting.   Full subsystem error
handling and correcting features are  employed.   This  exerciser
provides for no fault isolation.






                              4-21
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


4.4.5.1  Start-Up Procedure -

The Multi-Drive Exerciser may only be initiated by user  request.
Such an initiation is referred to as a demand initiation.

     Perform the following steps to initiate OMDEXR  (Multi-Drive
     Execiser):

     1.  Type Control Y (Remember - no carriage  return  required
         for control characters)

     2.  The HSC50 will respond with a HSC50> prompt

     3.  Type RUN OMDEXR

     4.  The system will load the  program  from  the  TU58  tape
         system.   This may take as much as a minute to complete.
         While the load  is  in  progress,  the  HSC50  will  not
         respond   to  Control-Y.   When  the  program  has  been
         successfully loaded you will see the following message.

         OMDEXR>D>Execution Starting

     5.  Notice that OMDEXR will now  prompt  the  user  for  the
         parameters   necessary.    (For  a  description  of  the
         parameters see the section below)

     6.  Notice  that  after  you  have  finished  answering  all
         prompts,  the  execution of the diagnostic will proceed.
         You  will  then  see  error  reports   and   performance
         summaries returned from OMDEXR.

     7.  Notice  that  when  OMDEXR  has  completed   all   tests
         requested  and has reported any errors found and a final
         performance summary, OMDEXR concludes with the following
         message.

         OMDEXR>D>Execution Complete




4.4.5.1.1  Test Parameter Entry -

You will be prompted with the following parameters.

DRIVE UNIT NUMBER (U) [] ?






                              4-22
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


You enter the unit number of the drive to be tested.  There is no
default for this prompt.  Unit numbers are of the form 'Dnnnn' or
'Tnnnn', where nnnn is a decimal number between 0 and 4095  which
corresponds  to  the  number printed on the drive's unit plug and
the 'D' or  'T'  implies  either  a  disk  drive  or  tape  drive
respectively.   Terminate the unit number with a carriage return.
OMDEXR will attempt  to  acquire  the  specified  unit,  via  the
HSC50's   Diagnostic   Interface.    If   the  unit  is  acquired
successfully, OMDEXR will continue with the next prompt.  If  the
acquire fails, one of the following conditions was encountered:

     1.  The specified drive is UNAVAILABLE.  This indicates that
         the  drive  is  connected to the HSC50, but is currently
         ONLINE to a Host CPU or HSC50 utiltiy.  Drives that  are
         ONLINE  cannot  be  diagnosed.   OMDEXR  will repeat the
         prompt for the unit number.

     2.  The specifed  drive  is  UNKNOWN  to  the  HSC50's  Disk
         Functional  software.  Drives are UNKNOWN for one of the
         following reasons:

          o  The drive and/or K.sdi port is  broken,  and  cannot
             communicate with the Disk Functional Software.

          o  The drive  was  previously  communicating  with  the
             HSC50,  but  a  serious error occurred and the HSC50
             has ceased communicating with the drive.

         In either case, OMDEXR will ask the user for  the  drive
         unit number again.


Once the user has selected a drive, and OMDEXR has  both  aquired
the  drive and brought it ONLINE, the user will see the following
prompts.  Notice that if a disk drive was specified  one  set  of
prompts  is presented.  If a tape drive was selected, notice that
an entirely different set of prompts  is  presented.   In  either
case  the  user  may  wish to select all default parameters for a
given drive.  In this case they would only need to answer  up  to
the  last  prompt  they  do  not  want to default and then type a
Control Z to cause the remaining parameters to default.



4.4.5.1.2  Disk Drive User Prompts -








                              4-23
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


                              NOTE

               The following prompts are presented
               if  the  drive  selected was a disk
               drive.



ACCESS USER DATA AREA (Y/N) [N]?

Normal testing is done only in the Diagnostic Blocks.  Should the
user  answer  YES  to  this and the following prompt, OMDEXR will
perform testing in  the  user  data  space.   It  is  the  user's
responsibility  to  see  to it that the data contained therein be
either backed up or of no value.

ARE YOU SURE (Y/N) [N]?

The potential of erasing user data requires that the user clearly
identify  that  they  are  sure it is permissible to write on the
users area.     A 'NO' response will cause the previous prompt to
be asked again.

START BLOCK NUMBER (D) [0]?

This value shall represent the starting block number of the users
data  space within which this program may access.  This prompt is
only asked when the user has requested access to the user's  data
space as described above.

END BLOCK NUMBER (D) [0=MAX]?

This value shall specify the ending block  number  of  the  users
data space where this program      may   access.    If  the  user
supplies a '0' this will imply that the  program  shall  use  the
highest LBN as the ending block number.  Thus, by supplying 0 for
the starting block number and 0 as the ending block  number,  the
user  will  have  indicated that the program is to use the entire
user data space as its test area.

INITIAL WRITE TEST AREA (Y/N) [N]?

The user shall have the option of performing an initial write  on
the test area which the user selected above.  This will write the
same data  pattern  (selected  below)  to  every  BN  within  the
selected  data  space.   If  the user selected access to the user
data space, then the space described between the  starting  block
number  and  the  ending block number will be written with a user
selected data pattern.  If the user did not select access to user
data  space, then all testing, including this initial write, will



                              4-24
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


be performed  within  the  diagnostic  cylinders  on  the  drive.
Should  the user answer 'NO' to this question, the user will next
see the question  pertaining  to  test  mode;   specifically  the
prompt  for  READ  ONLY  mode  next,  and the prompts immediately
following this prompt shall be omitted.

TERMINATE TEST ON THIS DRIVE FOLLOWING INITIAL WRITE (Y/N) [N]?

This question will give the user  the  option  of  performing  an
initial  write on the drive being tested and terminating the test
at that point.  The default answer, 'NO', will permit the user to
perform  this  initial  write  and,  having completed the initial
write, continue to exercise the drive.


                              NOTE

               The following prompts  specify  the
               test  sequence for that part of the
               test following  the  initial  write
               portion of the test.  That is, even
               if the user requests READ ONLY mode
               below,  the drive will not be write
               protected until after  any  initial
               write, as requested above, has been
               completed.



SEQUENTIAL ACCESS (Y/N) [N]?

The user shall have the option of requesting that all  disk  data
access be performed in a sequential manner.

READ ONLY (Y/N) [N]?

If answered 'NO' the user will be asked for both a pattern number
and  the  possibility  of  WRITE ONLY mode.  If the user answered
'YES', then OMDEXR will not  prompt  for  WRITE  ONLY  mode.   In
addition,  OMDEXR would only ask for a data pattern number if the
user had requested the initial write function described above.

DATA PATTERN NUMBER (0-15) (D) [15]?

The user shall have the option of selecting one of  the  16  disk
data  patterns  available.   By selecting data pattern 0 the user
shall be able to specify the contents of the pattern of up to  16
words.   The default data pattern (15) is the factory format data
pattern.




                              4-25
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


WRITE ONLY (Y/N) [N]?

This prompt will only be asked in the case where the user did not
request  READ  ONLY  mode  above.   If  READ  ONLY  mode had been
selected, this prompt would not appear.

DATA COMPARE (Y/N) [N]?

A 'NO' response will cause no data compares to be  performed.   A
'YES' response will cause the following prompt to be presented.

DATA COMPARE ALWAYS (Y/N) [N]?

A 'YES' response will select data compares  to  be  performed  on
every data transfer.  A 'NO' response will cause data compares to
be performed on 15% of the data transfers.

ANOTHER DRIVE (Y/N) []?

The user is asked if there is another drive  to  be  tested.   If
answered 'YES' the prompts noted above, beginning with the prompt
for DRIVE UNIT NUMBER, will be repeated.  If answered  'NO'  then
the  prompts  noted  below as 'global prompts' will be presented.
There is no default on this prompt so as to permit  the  user  to
default all other prompts and yet be able to parameterize another
drive for this pass of OMDEXR.



4.4.5.1.3  Tape Drive User Prompts -


                              NOTE

               The following prompts will be asked
               if  the  drive  selected  is a tape
               drive:



IS A SCRATCH TAPE MOUNTED (Y/N) [N]?

If the user responds 'NO' to this prompt the user  will  see  the
prompt  for the drive unit number and will have to select another
drive.  This is necessary so as to protect the user's  media.   A
'YES'  response  to  this  prompt  will result in the next prompt
being displayed.






                              4-26
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


ARE YOU SURE (Y/N) [N]?

This prompt will verify that the user has indeed mounted  scratch
media.   Again,  if the answer is 'NO' the user will next see the
prompt for the drive unit number the user  must  select  a  drive
again.

DATA PATTERN NUMBER (17-22) (D) [21]?

The user shall have the option of selecting one of  6  tape  data
patterns  to be used for this test.  The default pattern (pattern
21) is defined below in a later section.

DENSITY (1=800, 2=1600, 3=6250) (D) [2] ?

The user shall supply a '1', '2', or '3' as  the  density  to  be
used  on  the  tape.   Any other response will be illegal and the
prompt will be asked again.

OMDEXR>D>FIXED [VARIABLE] SPEEDS AVAILABLE:

This is an informational message which shall identify what speeds
are  available  to the user.  If the speeds are fixed their value
shall be presented to the user.  If, on the other hand, the speed
is  variable within a range, then the range shall be listed.  The
next prompt shall aske the user to select a speed.

SELECT FIXED [VARIABLE] SPEED (D) [1]?

If the speed is fixed then the first speed shall be  selected  by
default.   The  user may, at this time, select a speed other than
the default by selecting one of the aletrnate speeds available as
presented in the message described above.

RECORD LENGTH IN BYTES (1 or greater) (D) [512]?

The user is given the opportunity to specify the size, in  bytes,
of  a tape record.  Maximum size is TBD.  The default value shall
be 512 which is a standard buffer size.

DATA COMPARE (Y/N) [N]?

A 'NO' response will cause no data compares to be  performed.   A
'YES' response will cause the following prompt to be presented.

DATA COMPARE ALWAYS (Y/N) [N]?

A 'YES' response will select data compares  to  be  performed  on
every data transfer.  A 'NO' response will cause data compares to
be performed on 15% of the data transfers.



                              4-27
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


ANOTHER DRIVE (Y/N) []?

The user is asked if there is another drive  to  be  tested.   If
answered 'YES' the prompts noted above, beginning with the prompt
for DRIVE UNIT NUMBER, will be repeated.  If answered  'NO'  then
the  prompts  noted  below as 'global prompts' will be presented.
There is no default on this prompt so as to permit  the  user  to
default all other prompts and yet be able to parameterize another
drive for this pass of OMDEXR.



4.4.5.1.4  Global User Prompts -


                              NOTE

               The  following  prompts   will   be
               presented  to  the  user when there
               are no more drives  to  be  entered
               into  the  testing sequence.  These
               prompts are  global  in  the  sense
               that  pertain  to  all  the  drives
               selected above.



RUN TIME IN MINUTES (D) [10]?

The user shall be able to  determine  the  total  time  that  the
exerciser  shall execute in minutes.  The minimum time shall be 1
minute.  After the exerciser has  executed  for  that  period  of
time, all testing shall terminate and a final performance summary
shall be displayed.

HARD ERROR LIMIT (D) [20]?

When any  of  the  drives  selected  above  has  accumulated  the
specified number of hard errors, that drive shall be removed from
the testing sequence.

NARROW REPORT (Y/N) [N]?

There is a special format for the performance  summary  which  is
suitable for use on a handheld terminal with a narrow line length
(32 characters).  If the user is running this program from an HHT
then  it  would  be  to their best interest to specify the narrow
report.





                              4-28
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


ENABLE SOFT ERROR REPORTS (Y/N) [N]?

This prompt shall permit the user to enable soft  error  reports.
The  default  shall  be  that  the  user  will  see no soft error
reports.  This will not  inhibit  the  performance  summary  from
reporting the number of soft errors encountered.

OMDEXR>D>DEFINE PATTERN 0 .  .  .

This is an informational message.   If  the  user  selected  data
pattern  0  for  any  drive  above,  then the user must enter the
contents of this data pattern (ie.  pattern 0 is the user defined
data  pattern.   The  pattern  may consist of up to 16 words that
shall be repeated within the data buffers.

HOW MANY WORDS (16 IS MAX) (D) [16]?

The user shall be  expected  to  define  the  size  of  the  data
pattern.   If  a  number  larger  than  16  is supplied, an error
message will be displayed  and  this  prompt  will  be  presented
again.   When  the  user  has  presentaed  a  valid response, the
following prompt will be presented the specified number of times.

DATA IN HEX (H) [0]?

The user shall be provided with this prompt as many times as  the
number  of words specified in the response above.  The user shall
supply a 4 character HEX value as the answer to this prompt.



4.4.5.2  User Output -

There are three basic forms of user output;   the  data  transfer
error report, the performance summary, and a communications error
report.  The data transfer error report, described below, will be
printed  each  time  an error is encountered in one of the drives
being tested.

The performance summary report, also  described  below,  will  be
printed  when  OMDEXR  completes  this  pass  on each drive being
exercised or when the user terminates the pass.  This performance
summary  is also printed on a periodic basis during the execution
of OMDEXR.  There are two forms of the performance summary;   one
which  is  a  normal  80  column  report,  and  a second which is
designed for a hand help terminal  (HHT)  with  a  narrow  screen
field (32 characters wide).






                              4-29
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


The communications error report shall be sent  to  the  user  any
time   that   OMDEXR   is   unable   to  establish  and  maintain
communications  with  a  drive  the  user  has  selected  to   be
exercised.



4.4.5.2.1  Data Transfer Error Report -

The report described here shall be printed on the users  terminal
each  time a data transfer error is found during the execution of
this pass of OMDEXR.  The report shall describe the nature of the
error  which  occured  and all data pertinent to the error found.
This report shall in no way provide any analysis of the error nor
shall it explicitly call out any FRU.

The  data  transfer  error  report  shall  describe   hard   (non
recoverable)  errors  and soft errors on each drive being tested.
The report shall contain such information as the  description  of
the  error,  the  media  address  at which the error occured, the
first word in error, the number  of  words  in  error,  the  data
expected  and  that  which  was  actually  received, and the MSCP
status code.

The format of the data transfer error report is described below.

                   DATA TRANSFER ERROR REPORT

          OMDEXR>D>hh:mm T#HHH E#HHH U-uddd
          OMDEXR>D>Error Description
          OMDEXR>D>MA - HHHHHHHHHH
          OMDEXR>D>EXP - HHHH
          OMDEXR>D>ACT - HHHH
          OMDEXR>D>MSCP STATUS CODE = HHHH
          OMDEXR>D>FIRST WORD IN ERROR = ddddd
          OMDEXR>D>NUMBER OF WORDS IN ERROR = ddddd


     Where:


     1.  hh:mm is a time stamp since the start of OMDEXR

     2.  MA - is the media address where the error occured.

     3.  EXP - is the data which was expected.  This could also
         be the expected EDC or similar code in the case where
         the error was other than a data compare error.





                              4-30
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


     4.  ACT - is the data (or code) that was actually received.

     5.  MSCP STATUS CODE - is the code received from the
         operation.  (This may be replaced by an ASCII text
         associated with that code).

     6.  FIRST WORD IN ERROR - describes the number of the first
         word found in error.

     7.  NUMBER OF WORDS IN ERROR - once an error is found the
         routine continues to check the remainder of the data
         returned and counts the number of words found in error.






4.4.5.2.2  Performance Summary -


The Performance summary shall be printed on the users terminal at
the  end  of  the  testing  session, when the user terminates the
testing session, or every specified number  of  minutes  for  the
periodic performance summary.  This report shall provide the user
with the statistical data which was  being  tabulated  by  OMDEXR
during the execution of this test.

The performance summary shall present the  statistics  which  are
maintained  on  each drive.  This summary shall contain the drive
unit number, the drive serial  number,  the  number  of  position
commands  performed, the number of .5Kbytes read and written, the
number of hard errors, the number of soft errors, and the  number
software  correctable  transfers.  For tape drive being exercised
by OMDEXR there is an additional report  which  breaks  down  the
software correctable errors into eight different categories.

The performance summary comes in two formats;   one  which  is  a
normal  80  column format, and a second which is designed for use
on a hand held terminal which has only 32 characters per line.

The format of the Performance Summary is given below:











                              4-31
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


                  PERFORMANCE SUMMARY (DEFAULT)

UNIT  SERIAL    POSI   .5 KBYTE   .5 KBYTE  HARD  SOFT  SOFTWARE
 NO   NUMBER     TION    READ      WRITTEN  ERROR ERROR CORRECTED

Dddd HHHHHHHHHHH ddddd dddddddddd dddddddddd ddddd ddddd  ddddd
Tddd HHHHHHHHHHH ddddd dddddddddd dddddddddd ddddd ddddd  ddddd

                              etc.

In addition, if there were any tape drives  being  exercised  the
following  summary  is displayed within each performance summary.
This report shall break down the software correctable errors into
eight categories.

UNIT  MEDIA  DOUBLE  DOUBLE  SINGLE  SINGLE  OTHER  OTHER  OTHER
 NO   ERROR  TRKERR  TRKREV  TRKERR  TRKREV  ERR A  ERR B  ERR C

Tddd  ddddd  ddddd    ddddd   ddddd   ddddd  ddddd  ddddd  ddddd

                              etc.

                  PERFORMANCE SUMMARY (NARROW)

     OMDEXR>D>PER SUM
     D[T]ddd
     SN HHHHHHHHHHHH
     P ddddd
     R dddddddddd
     W dddddddddd
     HE ddddd
     SE ddddd
     SC ddddd

The report above is repeated for each drive  tested.   Note  that
there  is  a  one  to one correspondence between the items in the
narrow report as they flow down the page to the default report as
it flows across the page.

In addition, if any tape drives were being tested, after all  the
drive  performance summaries were displayed, the following report
shall be issued for each tape drive under test.

     OMDEXR>D>ERR SUM
     OMDEXR>D>Tddd
     OMDEXR>D>ME ddddd
     OMDEXR>D>DF ddddd
     OMDEXR>D>DR ddddd
     OMDEXR>D>SF ddddd
     OMDEXR>D>SR ddddd



                              4-32
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


     OMDEXR>D>OA ddddd
     OMDEXR>D>OB ddddd
     OMDEXR>D>OC ddddd

Again, as in the performance summary,  there  is  a  one  to  one
correspondence  between  the  items  listed  down the page in the
narrow error summary to the items listed across the page  in  the
default format of the error summary as shown above.



4.4.5.2.3  Communications Error Report -

Whenever OMDEXR encounters an error such that  it  is  unable  to
communicate  with one of the drives to be exercised, OMDEXR shall
issue a standard error report to the user.  These  reports  shall
give  such  detail  as  to  identify  the  problem.   For further
isolation of the problem the user would be advised to run another
diagnostic  specifically designed to isolate the failure (IDDD or
ITDD).

               COMMUNICATIONS ERROR REPORT FORMAT


The actual error message reported to the user shall appear in the
following format:


     OMDEXR>D>hh:mm T#HHH E#HHH U-uddd
     OMDEXR>D>Error Description
     OMDEXR>D>Optional Data lines follow here


Where:

     1.  hh:mm - time stamp for the start of OMDEXR

     2.  Error Description - is an ASCII string which will
         decribe the error encountered.

     3.  Optional Data lines - there are a maximum of 8 such
         optional lines per report.











                              4-33
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


4.4.5.3  Test Termination -

Upon completion of the  exercise  on  each  selected  drive,  the
reporting  of  any errors found, and a final performance summary,
OMDEXR will terminate normally.   All  resources,  including  the
drive  being  tested, will be released.  If you wish to terminate
this program before normal completion you may type a  Control  Y.
Certain  parts  of OMDEXR cannot be interrupted, so the Control-Y
may have no effect for a brief moment and may have to be repeated
a  couple  of  times.   Whenever  OMDEXR  is  terminated, whether
normally or by user  abort,  OMDEXR  will  always  run  down  any
outstanding IO requests and print a final performance summary.



4.4.5.4  OMDEXR Data Patterns -

The data patterns available for use with OMDEXR are listed below.
Note  that  Pattern  0  is  a user defined data pattern.  Room is
available for a repeating pattern of up to 16 words.

































                              4-34
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


4.4.5.4.1  Disk Drive Data Patterns -

Pattern 0       Pattern 1       Pattern 2       Pattern 3

User Defined    105613          031463          030221


Pattern 4       Pattern 5       Pattern 6       Pattern 7
Shifting 1s     Shifting 0s     Alter 1s,0s     B1011011011011001

000001          177776          000000          133331
000003          177774          000000
000007          177770          000000
000017          177760          177777
000037          177740          177777
000077          177700          177777
000177          177600          000000
000377          177400          000000
000777          177000          177777
001777          176000          177777
003777          174000          000000
007777          170000          177777
017777          160000          000000
037777          140000          177777
077777          100000          000000
177777          000000          177777



Pattern 8       Pattern 9       Pattern 10      Pattern 11
B0101../B1010.. B110...         26455/151322    

052525          155554          026455          066666
052525                          026455
052525                          026455
125252                          151322
125252                          151322
125252                          151322
052525                          026455
052525                          026455
125252                          151322
125252                          151322
052525                          026455
125252                          151322
052525                          026455
125252                          151322
052525                          026455
125252                          151322





                              4-35
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


Pattern 12      Pattern 13      Pattern 14      Pattern 15
Ripple 1        Ripple 0        Manufacture  -  Patterns

000001          177776          155555          155555
000002          177775          133333          133333
000004          177773          155555          066666
000010          177767          155555          155555
000020          177757          133333          133333
000040          177737          155555          066666
000100          177677          155555          155555
000200          177577          133333          133333
000400          177377          155555          066666
001000          176777          155555          155555
002000          175777          133333          133333
004000          173777          155555          066666
010000          167777          155555          155555
020000          157777          133333          133333
040000          137777          155555          066666
100000          077777          155555          155555







4.4.5.4.2  Tape Drive Data Patterns -


Pattern 17      Pattern 18      Pattern 19      Pattern 20

All Zeros       All Ones        Alternating     Alternating
                                bytes of all    two bytes 1's
                                Zeros and       and two bytes
                                all Ones.       0's



Pattern 21      Pattern 22

Alternating     Alternating
four bytes      three bytes
1's and four    1's and one
bytes 0's       byte 0's









                              4-36
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              IN-LINE DIAGNOSTICS


4.4.6  In-Line CI Responder Diagnostic

This program responds to commands from the CI NODE TESTER  (CINT)
or  CI  EXERCISER  (CIE).  The CINT and CIE (based in a host CPU)
test the CI by simulating normal and abnormal traffic on the  CI.
In  order  for  the tests of the CI to work properly, the various
nodes on the CI co-operate by responding to commands sent by CINT
or  CIE.   The  INL  CI  RESPONDER  will support a sub-set of the
functions specified for a CI  responder,  but  certain  functions
(such  as maintenance buffers) will not be supported due to HSC50
program memory space restraints.



4.4.6.1  Start-up Procedures -

The INL CI RESPONDER (RS) may only  be  initiated  automatically.
There  are  no  user  input  prompts, neither are there any error
messages from the RS directly sent to the  user.   Instead,  once
the responder is loaded it simply responds to its counterparts on
the CI cluster (ie.  CINT and CIE).

Normally your HSC50 will ship with the responder set to load  and
execute  automatically.   To  verify  that  this is true type the
following SETSHOW commands.

     1.  Type Control Y (Remember - no carriage  return  required
         for control characters)

     2.  The HSC50 will respond with a HSC50> prompt

     3.  Type SHOW LOAD

     4.  The system will load the SETSHOW program from  the  TU58
         tape  system.   This  may  take  as  much as a minute to
         complete.  While the load is in progress, the HSC50 will
         not  respond  to  Control-Y.   When the program has been
         successfully loaded you will see among the rest  of  the
         HSC50  system  data  the diagnostic flags and intervals.
         Your  responder  is  enabled  if  included  within   the
         information is the following line:

         CI Responder

     5.  Should the CI Responder have not been  loaded  the  user
         may set the CI Responder to load by typing the following
         SETSHOW command:






                              4-37
CONTROLLER DIAGNOSTICS Company Confidential
IN-LINE DIAGNOSTICS


     6.  Type Control Y (Remember - no carriage  return  required
         for control characters)

     7.  The HSC50 will respond with a HSC50> prompt

     8.  Type SET LOAD RS

     9.  Notice that the SETSHOW program  will  insist  that  the
         HSC50  be  rebooted for this command to take affect.  If
         you wish the CI Responder to be loaded you  must  answer
         'YES' to the following prompt:

         Rebooting HSC;  Y to continue, CTRL/Y to abort:

    10.  By typing a 'Y' you will notice that the HSC will reboot
         and load the CI Responder.




4.5  OFFLINE DIAGNOSTICS

The  Offline  diagnostics  are  stored  on  the   HSC50   OFFLINE
DIAGNOSTIC  tape cartridge.  The Offline diagnostic tape contains
the following diagnostics:

      o  Offline P.ioc Test
      o  Offline Memory Test
      o  Offline K/P Memory Test
      o  Offline Bus Interaction Test
      o  Offline K Test Selector
      o  Offline Memory Refresh Test
      o  Offline Sizer
      o  Offline Operator Control Panel (OCP) Test


Also included on the tape cartridge  is  the  Offline  Diagnostic
Loader  (ODL).  The Offline Diagnostic Loader provides a software
environment  for  the  HSC50  Offline  diagnostics.   The  loader
supports a command language that permits an Offline diagnostic to
be loaded  (from  the  HSC50's  TU58)  into  program  memory  and
executed.   The loader's command language also permits displaying
and modifying  the  contents  of  any  location  in  the  HSC50's
program, data, or control memories.

The  software  environment  provided  for   Offline   diagnostics
includes  a  TU58  driver  and  a terminal driver.  These drivers
supply a standard  software  interface  between  diagnostics  and
these  devices,  and  make  it unnecessary for each diagnostic to
contain routines to interface to  the  tape  and  terminal.   The



                              4-38
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


loader  also  maintains  a timer that keeps track of the relative
time since the loader was last booted.   This  allows  diagnostic
error messages to be time-stamped.

In the process of loading the Offline Diagnostic Loader,  several
diagnostics  are  run.   The ROM bootstrap tests the basic PDP-11
instruction set, tests a partition in program memory,  and  tests
the TU58 used for the boot.  Then the bootstrap loads the Offline
P.ioc test, which  completes  the  PDP-11  tests  and  tests  the
remainder  of  the  P.ioc module.  After these tests, the Offline
Diagnostic Loader is loaded from the TU58 to memory, and  control
is  passed  to  the  loader.   Due  to the sequence of tests that
precede the loader, the loader assumes that the P.ioc module  and
the TU58 are tested and working.



4.5.1  Start-Up Procedure

Use the following steps to boot the Offline Loader.

     1.  Insert the HSC50 OFFLINE DIAGNOSTIC tape cartridge  into
         the TU58's unit 0 drive (left hand drive).

     2.  Power-on the HSC50, or  depress  and  release  the  INIT
         switch on the HSC50 operator control panel.

     3.  The TU58 run indicator should light within  10  seconds,
         indicating  that  the  bootstrap  is loading the Offline
         Diagnostic Loader to program memory.

     4.  After  about  60  seconds  of   loading,   the   Offline
         Diagnostic  Loader  will  indicate  that  it  has loaded
         properly by displaying the following report.

         HSC50 OFL Diagnostic Loader, Version Vnn-nn
         Radix=Octal,Data Length=Word,Reloc=00000000
         ODL>

     5.  The Offline Loader is now ready to accept commands.




4.5.2  In Case Of Trouble

If the tape cartridge fails  to  load  when  the  above  start-up
procedure is followed, refer to the items below.





                              4-39
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     1.  Try booting your tape  from  the  TU58's  Unit  1  Drive
         (right-hand  drive).   If  your  system  has more than 2
         drives, try booting your tape  from  one  of  the  other
         drives.

     2.  Try booting another tape.  If another  tape  will  boot,
         the original tape is probably damaged or worn.

     3.  A TU58 failure can be caused by a  bad  or  misconnected
         cable between the TU58 and the P.ioc.  Inspect the cable
         between the TU58  and  the  P.ioc  module.   Insure  the
         connectors are well seated, and inserted properly.




4.5.3  Command Language

This section describes the commands  recognized  by  the  Offline
loader.

HELP COMMAND

     The  HELP  command  provides  an  abbreviated  list  of  all
     commands  that  the  loader  recognizes.  In response to the
     help command, the loader reads the file OFLLDR.HLP from  the
     TU58  and  displays  the  contents of this file on the local
     terminal.

SIZE COMMAND

     The Offline system sizer is invoked  by  the  SIZE  command.
     The  sizer  will determine the sizes of the HSC50's program,
     control, and data memories, and the type of K in each  HSC50
     requestor  number.   (The  HSC50  requestor number refers to
     priority of a particular K on the data  and  control  memory
     buses.   It  does  not match up with the numbering of module
     slots.)

INVOKING OFFLINE DIAGNOSTICS

     The loader's TEST command is  used  to  invoke  the  various
     Offline  diagnostics  available on the HSC50.  The following
     sections list the particular form of the test  command  used
     to  invoke  each  diagnostic.  In general, the format of the
     test command is designed so that an operator  specifies  the
     system  component that should be tested.  Example:  The TEST
     MEMORY command invokes the Offline Memory test.

MEMORY TEST



                              4-40
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


     The Offline memory  test  is  invoked  by  the  TEST  MEMORY
     command.   The  Offline  memory diagnostic uses the P.ioc to
     test the program, control, or data memories.  Refer  to  the
     Offline memory diagnostic paragraph for further information.


                                 NOTE


         For a faster test of the control or  data  memories,
         use the test memory by K command as described in the
         following section.



K/P MEMORY TEST

     The Offline K/P memory test is invoked by the TEST MEMORY BY
     K  command.  The K/P memory diagnostic uses one of the HSC50
     K's to  test  either  the  data  or  control  memory.   This
     diagnostic  runs  faster  than the Offline memory diagnosic,
     since a K is roughly 7 times faster  than  the  P.ioc.   The
     program  memory can not be tested using the K/P memory test,
     since the K's do not have an interface to the program memory
     bus.   Refer  to  the  Offline K/P memory test paragraph for
     further information.

K TEST SELECTOR

     The Offline K  Test  Selector  is  invoked  by  the  TEST  K
     command.   The  K  test  selector  allows an operator to run
     specific K microdiagnostics.  Refer to the  Offline  K  Test
     Selector paragraph for further information.

BUS INTERACTION TEST

     The Offline Bus Interaction test is invoked by the TEST  BUS
     command.   The  Bus Interaction test generates contention on
     the HSC50's data and control memory buses, by having two  or
     more  K's  simultaneously  test  different  sections  of the
     control and data  memories.   At  the  same  time  that  bus
     contention is generated by the K's, the P.ioc interacts with
     the TU58, OCP,  and  all  three  HSC50  memories.   The  Bus
     Interaction  test  is  a  HSC50 system exerciser designed to
     stimulate intermittent errors that may not  be  detected  by
     the other offline tests.







                              4-41
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


                                 NOTE


         Two or more working K's are  required  to  run  this
         test.   Refer  to  the  Offline Bus Interaction test
         paragraph for further information.



MEMORY REFRESH TEST

     The Offline Memory Refresh  test  is  invoked  by  the  TEST
     REFRESH  command.  This diagnostic tests the refresh feature
     of the HSC50 memories.

OPERATOR CONTROL PANEL (OCP) TEST

     The Offline OCP test is initiated by the TEST  OCP  command.
     This  test  provides a complete check of all HSC50 lamps and
     switches.

LOAD AND START COMMANDS
LOAD COMMAND

     The LOAD command allows a program to be  loaded  into  HSC50
     program  memory  without  being  started.  The format of the
     command is

     LOAD <filename>

     where <filename> is the name of  any  file  on  the  HSC50's
     OFFLINE DIAGNOSTIC tape cartridge.  The Loader will find the
     specified file and load it into the  program  memory.   This
     command  is  useful  when  you wish to patch a program image
     before starting execution.  After a patch has been made, the
     program  can be initiated via the START command as described
     in the following section.

START COMMAND

     The START command directs the loader to initiate the program
     that  is  currently  loaded  in  program  memory.  The START
     command can be used in conjunction  with  the  LOAD  command
     (see  preceeding  section),  or it may be used to reinitiate
     the last Offline diagnostic.  This saves the  time  required
     to reload the program from the TU58.

     Example:





                              4-42
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


     You have previously  typed  SIZE  to  initiate  the  Offline
     system  sizer  program.  After the sizer completes, you wish
     to run the sizer again.  Typing START<CR> will  restart  the
     sizer  without  having  to reload the program again from the
     TU58, saving many seconds of load time.

EXAMINE AND DEPOSIT COMMANDS

     The EXAMINE and DEPOSIT commands can be used to  display  or
     modify  the contents of any location in the HSC50's program,
     control, and data memories.  Qualifiers  (switches)  may  be
     used  with  these  commands  to  display  bytes, words, long
     words, or quad words, and the radix (octal, decimal, hex) of
     the  displayed  data  can  also be controlled by qualifiers.
     Alternately, the SET DEFAULT command can be used to set  the
     default  data  length  and radix for all EXAMINE and DEPOSIT
     commands.

EXAMINE COMMAND

     The EXAMINE command is used to display the contents  of  any
     location  in the HSC50's program, data, or control memories.
     The format of the command is

     EXAMINE <address>

     where <address> can be a string of  digits  in  the  current
     (default)  radix,  but  certain  symbolic addresses are also
     permitted.

     EXAMPLE:

     ODL> E 14017776 <CR>
     (D) 14017776  125252

     In the example you entered a command to examine the contents
     of  location  14017776.  Notice that the EXAMINE command can
     be abbreviated to a single E.  When the loader displays  the
     contents of location 14017776, the address is preceeded by a
     (D) to indicate that the location is within the HSC50's data
     memory.   The  display  indicates that the location contains
     the value 125252.

DEPOSIT COMMAND

     The DEPOSIT command is used to modify the  contents  of  any
     location  in the HSC50's program, control, or data memories.
     The format of the command is





                              4-43
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     DEPOSIT <address> <data>

     where <address> can be a string of  digits  in  the  current
     (default)  radix,  but  certain  symbolic addresses are also
     permitted (see next section).

     EXAMPLE:

     ODL> D 14017776 123456 <CR>

     In the example above, you entered a  command  to  store  the
     value  123456  into  the  contents of address 14017776.  The
     previous contents of  this  data  memory  location  will  be
     replaced  with  the  value  specified in the DEPOSIT command
     (123456).

SYMBOLIC ADDRESSES

     1.  *  -  The symbol * can be used  as  an  <address>  in  a
         DEPOSIT  or  EXAMINE command.  The symbol means that the
         loader is to use the same address as  was  used  in  the
         last EXAMINE or DEPOSIT command.

         EXAMPLE:

         If you just examined the contents of  address  16012344,
         and  now  wish  to  deposit the value 1234 into the same
         address, you can type

         DEPOSIT * 1234

         instead of typing

         DEPOSIT 16012344 1234.

     2.  +  -  The symbol + can  be  used  as  an  address  in  a
         DEPOSIT or EXAMINE command.  The symbol + means that the
         loader is to use the address following the last  address
         used  by an EXAMINE or DEPOSIT command.  When the loader
         sees a + as an address, the loader will  take  the  last
         address  used  by  EXAMINE  or DEPOSIT and add an offset
         which depends on the current default  data  length.   If
         the  current  default  data length is a byte, the loader
         will add 1 to the last address.  If  the  default  is  a
         word,  the  loader  will add 2 to the last address.  The
         offset will be 4 for longword data  length,  and  8  for
         quadword.   This  feature  is  useful  when  examining a
         number of items that are stored in successive locations.





                              4-44
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


         EXAMPLE:

         If you are examining  a  table  of  words  beginning  at
         address  14125234,  you would examine the first location
         by typing

         EXAMINE 14125234.

         The next location could now be examined by typing

         EXAMINE +

         instead of typing

         EXAMINE 14125236.

     3.  "-"  -  The symbol - can be used  as  an  address  in  a
         DEPOSIT or EXAMINE command.  The symbol - means that the
         loader is to use the address preceeding the last address
         used  by an EXAMINE or DEPOSIT command.  When the loader
         sees a - as an address, the loader will  take  the  last
         address  used  by  an EXAMINE or DEPOSIT and subtract an
         offset which depends on the current default data length.
         If the current default data length is a byte, the loader
         will subtract 1 from the last address.  If  the  default
         is  a  word,  the  loader  will subtract 2 from the last
         address.  The loader will subtract 4 for  longword  data
         length,  and  8 for quadword.  This feature is useful in
         the same way  as  the  +  symbol  (see  above),  but  is
         designed  for  examining a table starting at the highest
         address and proceeding down to lower addresses.

         EXAMPLE:

         If you want to examine a table of  words  that  ends  at
         address 14012346, you would examine the last location of
         the table by typing

         EXAMINE 14012346.

         The preceeding  location  in  the  table  could  now  be
         accessed by typing

         EXAMINE -

         instead of having to type

         EXAMINE 14012344.





                              4-45
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     4.  @  -  The symbol @ can  be  used  as  an  address  in  a
         DEPOSIT or EXAMINE command.  The symbol @ means that the
         loader is to use the  data  from  the  last  EXAMINE  or
         DEPOSIT  command  as an address.  This feature is useful
         when following linked lists.   For  example:   The  user
         first examines location 123434, which contains a pointer
         to a linked list.  Now the user can type  EXAMINE  @  to
         examine   the  location  to  which  the  first  location
         pointed.


REPEATING EXAMINE AND DEPOSIT COMMANDS

     When troubleshooting memory problems, it is sometimes useful
     to  continuously  execute  an  EXAMINE  or  DEPOSIT command.
     While the command is being repeated, an oscilloscope can  be
     used  to  detect  errors  in  the  memory data, address, and
     timing circuits.

     The repeat  command  is  used  to  continuously  execute  an
     EXAMINE  or DEPOSIT command.  The user types repeat followed
     by the EXAMINE or DEPOSIT command to be repeated.

     EXAMPLE - Repeating a DEPOSIT command

     REPEAT DEPOSIT 14017776 125252 <CR>
     or  RE D 14017776 125252 <CR>

     In the example above, you wish to continuously  deposit  the
     value  125252 into address 14017776.  Notice that the format
     of the DEPOSIT command does not change.  The DEPOSIT command
     is  just preceeded by the word REPEAT.  Notice also that the
     REPEAT command can be abbreviated to RE.

     EXAMPLE - Repeating an EXAMINE command

     REPEAT EXAMINE 14017776 <CR>
     or  RE E 14017776 <CR>

     In the example above, you wish to continuously  examine  the
     contents of address 14017776.  Notice that the format of the
     EXAMINE command does not change.   The  EXAMINE  command  is
     just  preceeded  by  the  word REPEAT.  Also notice that the
     REPEAT command can be abbreviated to RE.

     In the example as shown, the contents of  location  14017776
     would  be  displayed  continuously on the terminal.  On hard
     copy devices this wastes paper, and in  any  case  it  slows
     down  the  repetition  of  the  command  which  may  make it
     difficult to sync a scope on the memory signals.  The output



                              4-46
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


     to  the  terminal may be stopped by typing a control-o (^O),
     but the loader's language also provides a special  qualifier
     for  the  EXAMINE  command  which  suppresses  output to the
     terminal.  This qualifier (/INHIBIT) is discussed later.

     To stop a repeated command, type a CONTROL C.

USING THE RELOCATION REGISTER

     The loader provides a relocation register which can be  used
     to  reduce the number of address digits typed for an EXAMINE
     or DEPOSIT command when all  addresses  are  in  either  the
     control  or  data  memories.  The contents of the relocation
     register are added to the address given with an  EXAMINE  or
     DEPOSIT  command.   The  relocation register contains a zero
     when the loader is initiated, so it normally has  no  effect
     on the addresses typed in an EXAMINE or DEPOSIT command.

     EXAMPLE - Relocation to data memory

     You wish to examine a large number of locations in the  data
     memory.

     ODL> SET RELOCATION:14000000 <CR>
     ODL> EXAMINE 0 <CR>
     (D) 14000000 123432

     ODL> EXAMINE 1234 <CR>
     (D) 14001234 154323

     You load the relocation register with  the  address  of  the
     first  location  in  data  memory (14000000).  Then when you
     issue an EXAMINE command with an address of  0,  the  loader
     adds  the  relocation  register to the address given by you,
     resulting in address  14000000  being  examined.   Likewise,
     when  the  you  issue  an EXAMINE command with an address of
     1234, the loader  will  display  the  contents  of  location
     14001234.

     EXAMPLE - Relocation to control memory

     You wish to examine a  large  number  of  locations  in  the
     control memory.

     ODL> SET RELOCATION:16000000 <CR>
     ODL> EXAMINE 0 <CR>
       (C) 16000000 125252

     ODL> EXAMINE 4320 <CR>
       (C) 16004320 125432



                              4-47
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     You load the relocation register with  the  address  of  the
     first  location in the Control memory (16000000).  Then when
     you issue an EXAMINE command  with  an  address  of  0,  the
     loader  adds the relocation register to the address given by
     you, resulting in the contents  of  address  16000000  being
     displayed.  Likewise, when you issue an EXAMINE command with
     an address of 4320, the  loader  displays  the  contents  of
     location 16004320.

EXAMINE AND DEPOSIT QUALIFIERS (SWITCHES)

     1.  /NExt:#  -  The /NEXT qualifier  allows  an  EXAMINE  or
         DEPOSIT  command  to work on successive addresses.  When
         used with a valid EXAMINE  command,  it  specifies  that
         after  the  location  specified  in the command has been
         displayed, the loader should also display the next #  of
         locations following the first.  For example, the command
         E 1000/NEXT:5 would result in the  display  of  location
         1000,  1002,  1004,  1006,  1010, and 1012 (assuming the
         default data length is a word).  The # argument  can  be
         any  value  in  the  current  default radix which can be
         contained in 31 binary bits or less.

         EXAMPLE:

         If the default radix is octal, the # argument can be any
         value  between  1  and 17777777777.  The /NEXT qualifier
         works the same way for DEPOSIT commands, except that the
         data  given  with  the  deposit  will  be  stored in the
         location specified and the next # locations following.

     2.  /Byte/Word/Long/Quad  -  These qualifiers can be used to
         control  the  data-length of examined or deposited data.
         Normally, the loader uses the default  data-length  when
         data  is  examined or deposited, however the data-length
         qualifiers can be used to override  the  default  for  a
         single EXAMINE or DEPOSIT.

         EXAMPLE:

         Assume the default data-length is currently a word,  and
         you wish to examine a byte quantity at address 16001234.
         The command EXAMINE 16001234/Byte <CR> would display the
         proper byte without affecting the default data length.

     3.  /Octal/Decimal/Hex  -  The qualifiers can be  used  with
         an  EXAMINE  command to control the radix of the address
         and data displayed.  They are NOT used  to  control  the
         radix  of  the  address supplied in the EXAMINE command.
         The radix of  the  address  and  data  displayed  by  an



                              4-48
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


         EXAMINE  command  is  usually  controlled by the current
         default radix but  the  /Byte/Word/Long/Quad  qualifiers
         can  be  used to override the default radix for a single
         EXAMINE command.

         EXAMPLE:

         Assume the default radix is octal.  The command  EXAMINE
         14001234/Hex<CR>  will  display  the contents of address
         14001234(8)  in  the  hexadecimal  radix.   The  EXAMINE
         display would be

         (D)  30029C  HHHH.

         HHHH represents the contents of the  location  displayed
         in  hex.   Notice  that the address is also displayed in
         hex.

     4.  /INH  -  The /INHIBIT (abbreviated to /INH) qualifier is
         used  when  repeating  an EXAMINE command to inhibit the
         display of examined  data.   This  is  useful  both  for
         saving  paper  on  hardcopy devices, and for speeding up
         the EXAMINE operation for scope loop purposes.

         EXAMPLE:

         The command

         REPEAT EXAMINE 16012346/INH

         will result  in  the  loader  continuously  reading  the
         contents   of   location  16012346,  without  displaying
         anything on the console.


SETTING AND SHOWING DEFAULTS

     The SET DEFAULT command is used to change the default  radix
     and/or data length.  The default radix controls the radix of
     parameters supplied with EXAMINE and DEPOSIT  commands,  and
     the  radix  of  data  displayed by the EXAMINE command.  The
     default     data     length     controls     the      length
     (byte,word,long,quad)  of  data  displayed  by  the  EXAMINE
     command, or data stored by a DEPOSIT command.

     The  default  radix  may  be  set  to  octal,  decimal,   or
     hexadecimal.   When  the Offline loader is first started, it
     sets the default radix to octal.  To set the  default  radix
     to hexadecimal, you would type the following command.




                              4-49
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     SET DEFAULT HEX<CR>

     (See loader help file for abbreviation  rules  for  the  SET
     DEFAULT command.)

     Once the default radix has been  set,  it  will  remain  set
     until  another  SET DEFAULT command is issued, or the loader
     is rebooted.

     The default data length may be set to byte, word,  longword,
     or  quadword.  When the loader is first started, it sets the
     default data length to word (16 bits).  To set  the  default
     data  length  to  longword  (32  bits),  you  would type the
     following command.

     SET DEFAULT LONG <CR>

     (See loader help file for abbreviation  rules  for  the  SET
     DEFAULT command.)

     Setting the default data length to longword  will  cause  an
     EXAMINE  command  to  display  longword quantities, and will
     cause the DEPOSIT  command  to  store  longword  quantities.
     (Since  the  Loader  is executing in a PDP-11, longwords are
     stored and retrieved as two successive 16-bit  words.)  Once
     the  default  data  length  has been set, it will remain set
     until changed by another set default, or until the loader is
     rebooted.

EXECUTING INDIRECT COMMAND FILES

     The loader is capable of executing  indirect  command  files
     stored  on  the  TU58.  These command files consist of valid
     Offline Loader  commands  terminated  by  a  carriage-return
     (<CR>)  and a line-feed (<LF>).  Comments may also be placed
     in indirect command files by preceeding a comment line  with
     an  exclamation  mark  (!).   Comment  lines  must  also  be
     terminated with a <CR> and <LF>.

     EXAMPLE:

     The Offline Loader help file is  an  indirect  command  file
     that contains only comments.

     Indirect command files cannot be created by  the  Loader  or
     the  HSC50  Control  Program.   The  command  files  must be
     created in RT-11 format and  stored  on  the  HSC50  OFFLINE
     DIAGNOSTIC  tape cartridge.  Any editor that does not insert
     line numbers in the output  files  can  be  used  to  create
     command files.



                              4-50
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


The following information is a brief repeat of the commands


                              NOTE


               In the following commands,  capital
               letters  are  required input, lower
               case are optional.  All commands  a
               terminated by a RETURN.


EXAMINE

     The EXAMINE command  allows  you  to  display  data  at  the
     address specified.

     Format

     Examine <address>

     You can use a digit string in the current default radix  for
     <address> or one of the following options.

      o  A * following the examine command  means  use  the  same
         address as last EXAMINE or DEPOSIT command

      o  A + following the EXAMINE command means use the  address
         following the last address

      o  A - following the EXAMINE command means use the  address
         preceeding the last address

      o  A @ following the EXAMINE means use the <data> from last
         EXAMINE or DEPOSIT command as the address


     EXAMINE qualifiers

          /Next:#

               Repeat EXAMINE on next # addresses

          /Byte,/Word,/Long,/Quad

               Use specified data length instead of default

          /Octal,/Decimal,/Hex





                              4-51
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


               Use specified radix for EXAMINE display

          /INH

               Inhibit display of examined data

DEPOSIT

     The DEPOSIT command  allows  you  to  deposit  data  at  the
     specified address.

     Format

     Deposit <address> <data>

     You can use a digit string in the current default radix  for
     <address> or one of the following options.

      o  A * following the DEPOSIT command  means  use  the  same
         address as last EXAMINE or DEPOSIT command

      o  A + following the DEPOSIT command means use the  address
         following the last address

      o  A - following the DEPOSIT command means use the  address
         preceeding the last address


     DEPOSIT qualifiers

          /Next:#

               Repeat DEPOSIT on next # addresses

          /Byte,/Word,/Long,/Quad

               Use specified data length instead of default

HELP

     The HELP command displays the help file.

     Format

     HElp

@






                              4-52
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


     The @ command followed by a filename  executes  an  indirect
     command file.

     Format

     @<filename>

LOAD

     The LOAD command loads a file to the diagnostic partition.

     Format

     Load <filename>

REPEAT

     The  REPEAT  command  followed  by  a  command  repeats  the
     specified command until you enter a ^C.

     Format

     REpeat <command>

SET DEFAULT

     The SET DEFAULT command allows you to set default  radix  or
     data length.

     Format

     SEt Default <option>,<option>

     The <options> are as follows.

      o  Byte
      o  Word
      o  Long
      o  Quad
      o  Hex
      o  Octal
      o  Decimal


SET RELOCATION

     The SET RELOCATION command allows you to set the  relocation
     register  to  value.   The  relocation  register  is  22-bit
     positive number added to the  address  of  all  examine  and
     deposit commands.



                              4-53
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     Format

     SEt Relocation:#

SHOW

     The SHOW command displays the defaults and diagnostic loader
     version.

     Format

     SHow

SIZE

     The SIZE command displays the size of the HSC50 memories and
     the  status  of the K modules.  You need to know the size of
     the memories before running any memory test.

     Format

     SIze

START

     The  START  command  starts  a  program  in  the  diagnostic
     partition.

     Format

     Start

TEST BUS

     The TEST BUS  command  loads  and  starts  the  Offline  Bus
     Interaction test.

     Format

     Test Bus

TEST K

     The TEST K command loads  and  starts  the  Offline  K  Test
     Selector.

     Format






                              4-54
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


     Test K

TEST MEMORY

     The TEST MEMORY command loads and starts the Offline  Memory
     test.

     Format

     Test MEmory

TEST MEMORY BY K

     The TEST MEMORY BY K command loads and  starts  the  Offline
     K/P Memory test.

     Format

     Test MEmory By K

TEST OCP

     The TEST OCP command loads and starts the Offline OCP test.

     Format

     Test Ocp



4.5.4  Unexpected Traps And Interrupts

When the loader detects an  unexpected  trap  or  interrupt,  the
following message is displayed:

Unexpected trap thru www, VPC=xxx, PSW=yyy
Error Address = zzz

Where:

www = The address of the trap or interrupt vector
xxx = Virtual PC of loader at time of trap
yyy = Contents of PSW at time of trap
zzz = Address of location causing NXM or Parity trap

The first line of the unexpected trap report is  issued  for  all
unexpected  traps  or interrupts.  The second line is only issued
if the trap was through vector addresses  000004  (NXM  trap)  or
000114 (parity trap).  The address of the vector is a direct clue
to the cause of the trap.  Refer to the following section  for  a



                              4-55
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


list  of  the  devices  and error conditions associated with each
vector.  The virtual PC (VPC) of the instruction that  was  being
executed   when   the   trap  occurred  is  sometimes  useful  in
determining the cause of the trap.  The VPC can be referenced  in
the  listing  to  find  the  instruction  that  caused  the trap.
Remember that the VPC will be  the  address  of  the  instruction
following  the  instruction that was being executed when the trap
occurred.

NXM traps can be caused by EXAMINE or DEPOSIT  commands,  if  you
specify an address that is not contained in a particular HSC50.

EXAMPLE:

If an HSC50 only contains data  memory  from  addresses  14000000
thru  14177776,  and  YOU  TRY  to  examine  or  deposit  address
14200000, the loader will report an NXM trap.  In  this  example,
the NXM trap would NOT represent an error condition.

Parity traps can be caused by an EXAMINE command, if you  examine
an  address that has not been initialized with good parity.  When
the HSC50 memories are powered-on, the parity bits are in  random
states.  Thus if you examine a location that has not been written
since power-on, the location may generate a parity  error.   This
would  not constitute an error condition.  However, if a location
produces a parity error, and that location has been written since
power-on,  a memory error is indicated.  Also note that the P.ioc
and K's have bits which allow them to write bad parity  to  allow
the  parity  circuit to be tested.  These bits are never supposed
to be used except by diagnostics.



4.5.5  Trap And Interrupt Vectors

The following is a list of trap and interrupt vectors for various
devices  and  error  conditions  recognized by the P.ioc's PDP-11
processor.

Vector     Device or Error Condition
------     -------------------------
000004      Non-Existent-memory, stack overflow
000010      Illegal instruction, F11 control chip error
000014      BPT instruction
000020      IOT instruction
000024      Power Fail Interrupt
000030      EMT instruction
000034      TRAP instruction
000060      Console Terminal - receiver interrupt
000064      Console Terminal - Transmitter interrupt



                              4-56
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


000100      Line Clock Interrupt
000114      Parity Trap
000120      Control Bus Interrupt - Level 4
000124      Control Bus Interrupt - Level 5
000130      Control Bus Interrupt - Level 6
000134      Control Bus Interrupt - Level 7
000250      MMU Abort (Trap)
000300      TU58 #1, Receiver Interrupt
000304      TU58 #1, Transmitter Interrupt
000310      TU58 #2, Receiver Interrupt
000314      TU58 #2, Transmitter Interrupt



4.5.6  Error Message Format

All error messages produced by the Offline diagnostics conform to
the HSC50 diagnostic error message format.  The first line of the
error message contains general information concerning the  error.
The  second  line  is a text message describing the nature of the
error.  Lines 1 and 2 are mandatory,  and  appear  in  all  error
messages.   Line  3,  and  succeeding  lines, of an error message
display additional  information,  and  are  optional.   They  are
displayed  for  certain  errors  that  need  to  provide  further
information.  All numeric information  displayed  with  an  error
report  is  in  the OCTAL radix.  Listed below is a typical error
message for the Offline Memory test.

OMEM>tt:tt T#aaa E#bbb U-000      (mandatory line)
<Text string describing error>    (mandatory line)
MA -xxxxxxxx                      (optional line)
EXP-yyyyyy                        (optional line)
ACT-zzzzzz                        (optional line)

WHERE:

tt:tt    = Hours and minutes since last boot
aaa      = Octal number denoting test that failed
bbb      = Octal number denoting error detected
xxxxxxxx = Failing address (if appropriate)
yyyyyy   = Data expected   (if appropriate)
zzzzzz   = Data found      (if appropriate)

If there is a  difference  or  more  error  information  for  the
diagnostic,  the  text  for  each  diagnostic  will  mention  the
difference.







                              4-57
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


4.5.7  Offline P.ioc Test

The Offline P.ioc test is a repair level diagnostic, designed  to
test  the  HSC50 P.ioc module.  All P.ioc logic not tested by the
bootstrap  is  covered.   The  test   runs   in   a   stand-alone
environment, with no other HSC50 processes running.  By providing
specific  error  messages,  the  test  aids  in  isolating  P.ioc
failures to a specific section of logic.  If the entire test runs
with no errors, the Offline Diagnostic Loader is read  to  memory
from the TU58 and started.

The Offline P.ioc test is loaded by the HSC50 P.IOC ROM Bootstrap
program.   The  bootstrap  performs  tests  of  the  basic PDP-11
instruction set, the lower 2048 bytes of  program  memory,  an  8
Kword  partition  in  program  memory,  and  the TU58 used by the
bootstrap.  Hence when the Offline P.ioc test begins to  execute,
most  PDP-11 logic has been tested, and is assumed to be working.
Likewise, the memory occupied by the test, and the TU58  used  to
load the test, are also assumed to be tested and working.

The Offline P.ioc diagnostic tests the following logic.

      o  Entire instruction set
      o  Extended instruction set
      o  Addressing modes
      o  Error detection
      o  Interrupts
      o  Traps
      o  Vectors
      o  Control memory windows
      o  Memory management




4.5.7.1  Start-Up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).   This  diagnostic  is  run  prior  to  the HSC50 Offline
Diagnostic Loader being loaded.

To rerun this diagnostic, you would push the INIT switch.











                              4-58
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


4.5.7.2  Test Parameter Entry -

The  Offline  P.ioc  test  does  not   have   any   user-supplied
parameters.



4.5.7.3  Progress Reports -

The Offline P.ioc test does not issue any progress  reports.   If
the  test  runs  to completion with no errors detected, the HSC50
Offline  Diagnostic  Loader  is  loaded  and  started.   If   the
diagnostic detects an error, an error report will be displayed.



4.5.7.4  Test Termination -

Once initiated, the Offline P.ioc test can only be terminated  by
halting the machine and rebooting.



4.5.7.5  Error Message Format -

The first part of the error message is the same as  mentioned  in
error report format in paragraph 4.?.

The PDP-11 HALTS after printing the error message.  R0 contains a
pointer  to  a  9-word  array  which  holds a copy of the general
registers at the time the error was detected, plus the error  and
test number.  The 9-word array is arranged as follows:

word 0  -  saved contents of R0
word 1  -  saved contents of R1
word 2  -  saved contents of R2
word 3  -  saved contents of R3
word 4  -  saved contents of R4
word 5  -  saved contents of R5
word 6  -  saved contents of R6
word 7  -  Test Number
word 8  -  Error Number

After halting, the Offline P.ioc diagnostic may be restarted from
the  beginning by typing a P (proceed) on the terminal.  The rest
of the test  may  be  skipped  by  examining  R1  with  ODT,  and
depositing the value found in R1 into R7 (the PC).  Then type a P
to start loading the Offline Loader.





                              4-59
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


4.5.7.6  Primitive Error Reports (HALT At 000400) -

Certain errors are detected before the entire Offline P.ioc  test
has  been  loaded to memory.  These errors can not use the normal
error reporting method (text on the terminal).  Instead,  a  more
primitive  error  reporting  method  is used.  General Register 0
(R0) is loaded with the error number, and the PDP-11  halts  with
the PC=000400.  The test can only be repeated by rebooting.

The following errors use the primitive error reporting mechanism.

      o  Unexpected trap  while  loading  the  remainder  of  the
         Offline P.ioc test from the tape.  (Error 000)

      o  TU58 read error  while  loading  the  remainder  of  the
         Offline P.ioc test from the tape.  (Error 003)

      o  Failure to find a tape directory entry for  the  Offline
         P.ioc test.  (Error 002)




4.5.7.7  What To Do In The Event Of A Crash -

Certain P.ioc failures may cause the program to crash,  (halt  or
loop  indefinitely),  without  printing  an error report.  In the
event this happens, use the BREAK key to halt  the  PDP-11,  then
use PDP-11 ODT to examine the following locations:

000422 (TSTNUM) holds current test number
000424 (ERRNUM) holds current error number

The test number should indicate the test causing the crash.   The
error  number  will  ONLY  BE  VALID  if the crash occurred while
trying to report an error.  Additionally,  the  contents  of  the
PDP-11  general registers (R0 thru R7), and the last few words on
the stack, may help determine the exact point where the  test  is
failing.



4.5.8  Offline Memory Test

The Offline  memory  test  is  designed  to  exercise  the  HSC50
memories.   The  operator  may  select  control, data, or program
memory to be tested.  Three memory testing algorithms  are  used:
the Quick Verify algorithm, the Moving Inversions algorithm,





                              4-60
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


and the Walking 1's algorithm.  The algorithms  are  designed  to
stress  the  memories  in  an  effort  to detect transient errors
caused by bus and memory timing problems.  Errors are reported on
the  console  terminal  as  they  occur.   After reporting a data
error, testing continues where it left off.   After  reporting  a
parity or NXM error, testing is restarted from the beginning.



4.5.8.1  Start-Up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).  After receiving the ODL> prompt, type in

T ME or TEST MEMORY

to start the diagnosic.  When the  diagnostic  starts,  you  will
receive the following report.

HSC50 OFL Memory Test, Version Vnn-nn



4.5.8.2  Parameter Entry -

The Offline memory test prompts for the following parameters.

Control(0),Data(1),or Program(2) Memory [0] ?

Type a 0 to test control memory, type a 1 to test data memory, or
type a 2 to test program memory.  After typing the desired digit,
type a carriage-return to terminate your response.  Typing just a
carriage-return  will  cause  the  Control memory to be tested by
default.  The memory test next prompts for the first  address  to
test.

First (min=XXXXXXXX) [min] ?

Type the first address to be tested.  Addresses are 8  digits  in
length.  The min address displayed is the lowest address that may
be entered for the memory chosen.  Typing just a  carriage-return
will  cause the first address to default to the min value.  After
typing   the   address,   terminate   your   response   with    a
carriage-return.   The  test  now prompts for the last address to
test.

Last (max=XXXXXXXX) [] ?






                              4-61
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


Type the last address to be tested.  The max address displayed is
the  highest  address that is still within the memory chosen.  If
your system does not have a  fully  populated  memory,  the  last
address  that  may  be  tested  will be less than the max address
displayed.  If you choose a last address that exceeds the  amount
of  memory  in  your  system,  the  memory  test  will  display a
non-existent-memory (NXM) error when the test reaches  the  first
address beyond the end of your memory.  You will then receive the
next prompt.

# of passes to perform (D) [1] ?

Enter a decimal number between 1 and 4,294,967,303 (omit commas),
which  specifies  the  number  of times the memory test should be
repeated.  (Entering a 0, or just a carriage-return, will  result
in  1  pass  being  performed.)  The  test  will  now begin.  The
diagnostic can be aborted at any time by typing a CONTROL C.


                              NOTE


               For any of the above  prompts,  use
               the  DELETE key to delete mis-typed
               parameters before  the  terminating
               carriage-return  is  typed.  If you
               note an error in a  parameter  that
               has  already been terminated with a
               carriage-return, type a  CONTROL  C
               to return to the initial prompt and
               reenter all parameters.





4.5.8.3  Reusing Parameters -

After the first memory test has been specified and completed, the
following prompt will be issued.

Re-use parameters (Y/N) [Y] ?

Answering this prompt with a carriage-return, or a Y followed  by
a  carriage-return, results in repeating the last test specified,
using the parameters that were previously  used.   Answering  the
prompt with a N followed by a carriage-return will cause the test
to prompt for new parameters.  Answering with a  CONTROL  C  will
terminate the diagnostic.




                              4-62
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


4.5.8.4  Progress Reports -

A complete pass thru the memory test consists of one pass through
the  Quick  Verify  test, once pass through the Moving Inversions
test, and one pass through the Walking  Ones  test.   After  each
complete pass, an end of pass message is displayed as follows.

End of Pass nnnnnn, xxxxxx Errors, yyyyyy Total Errors

The pass count nnnnnn  is  a  decimal  count  of  the  number  of
complete  passes  made.   The  error  count  xxxxxx indicates the
number of errors detected on the current pass of the  test.   The
total  count yyyyyy indicates the total errors detected since the
test was started.



4.5.8.5  Disabling P.ioc Parity Traps -

When a parity error occurs, it is desirable to know  whether  the
error  was  produced by the loss or gain of a data bit, or by the
loss or gain of a parity bit.  When a parity trap occurs  in  the
P.ioc,  the  data  that  was  read  is  discarded  by the PDP-11.
However, a feature  of  the  P.ioc  allows  parity  traps  to  be
disabled.   Using  this  feature,  you  can determine if a parity
error is being caused by a data or parity bit as follows.

     1.  After a (P.ioc detected) parity trap is reported, type a
         CONTROL C to terminate the memory test.

     2.  Type  another  CONTROL  C  to  return  to  the   Offline
         diagnostic loader.  The loader will prompt:  ODL>.

     3.  Type Ex 17770042 followed by a carriage-return.

     4.  The contents of the  P.ioc  switch  control  and  status
         register  (SWCSR)  will  be  displayed  as follows:  (I)
         17770042 nnnnnn.

     5.  Type DE  nnnn4n  followed  by  a  carriage-return.   The
         nnnn4n represents the previous contents of the register,
         including a one in bit 5.  P.ioc parity  traps  are  now
         disabled.

     6.  Return to the memory test by typing start, followed by a
         carriage-return.

     7.  Rerun memory test with original parameters.





                              4-63
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


     8.  If the location that previously produced a parity  error
         now  produces a data error, the original parity trap was
         caused by a data bit problem.   The  error  report  will
         indicate  the  failing  bit  via the EXPected and ACTual
         data displayed.

     9.  If the location that previously produced a  parity  trap
         does  not  fail  when  the  memory  test  is  rerun, the
         original parity trap was caused by an error  in  one  of
         the parity bits (high or low byte) for that word.

    10.  Type a CONTROL C to return to the loader,  and  reenable
         parity  errors by typing DE 17770042 nnnn0n, followed by
         a carriage-return.  The nnnn0n represents  the  original
         contents  of the P.ioc's SWCSR, before parity traps were
         disabled.




4.5.8.6  Error Message Format -

The error message is the same as mentioned in error report format
in paragraph 4.?.  However,Parity trap and NXM trap errors do not
include expected and actual data.



4.5.9  Offline K/P Memory Test

The Offline K/P memory test allows the  HSC50  control  and  data
memories to be tested from a K (K.sdi, K.ci, K.sti).  The Offline
K/P memory test executes from the P.ioc, and  uses  the  HSC50  K
control area to instruct one of the sub-system K's to test either
the control or data memories.  You select the K to be  used,  and
the  starting and ending addresses of the section of memory to be
tested.  The test algorithm used by the K is designed  to  stress
the  memories  in  an effort to detect transient errors caused by
bus and memory timing  problems.   Errors  are  reported  on  the
console terminal as they occur.



4.5.9.1  Start-Up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).  After receiving the ODL> prompt, type in






                              4-64
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


T ME B K or TEST MEMORY BY K

to start the test.  When the test starts, you  will  receive  the
following report.

HSC50 OFL K/P Memory Test, Version Vnn-nn



4.5.9.2  Parameter Entry -

The Offline K/P Memory test prompts for the following parameters.

K requestor # (1 thru 7) [] ?

Answer this question with single digit (1 thru 7), that specifies
the  requestor  # of the K to be used.  Terminate the response by
typing a carriage-return.  After the requestor # is  supplied,  a
K-control-area is located in the control memory and tested.  This
area is required for communicating with the K that  will  perform
tests of data and control memory.  The test then prompts.

Control (0) or Data (1) memory [0] ?

Type a 0 to test control memory, or type a 1 to test data memory.
If  you  type  just a carriage-return, the control memory will be
tested by default.   After  typing  the  desired  digit,  type  a
carriage-return to terminate your response.  The memory test next
prompts for the first address to test.

First (min=XXXXXXXX) [min] ?

Type the first address to  be  tested.   Addresses  are  8  octal
digits  in  length.   The  min  address  displayed  is the lowest
address that may be entered for the memory chosen.  Typing just a
carriage-return  will  cause  the first address to default to the
min address.  After typing the address, terminate  your  response
with  a  carriage-return.   The  test  now  prompts  for the last
address to test.

Last (max=XXXXXXXX) [] ?

Type the last address to be tested.  The max address displayed is
the  highest  address that is still within the memory chosen.  If
your system does not have a  fully  populated  memory,  the  last
address  that  may  be  tested  will be less than the max address
displayed.  If you choose a last address that exceeds the  amount
of  memory  in  your  system,  the  memory  test  will  display a
non-existent-memory (NXM) error when the test reaches  the  first
address  beyond  the end of your memory.  Finally, the K/P memory



                              4-65
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


test prompts.

# of passes to perform (D) [1] ?

Enter a decimal number between 1 and 4,294,967,303 (omit commas),
which  specifies  the  number  of times the memory test should be
repeated.  (Entering a 0, or just a carriage-return, will  result
in  1  pass  being performed.) The test will now begin.  The test
can be aborted at any time by typing a CONTROL C.


                              NOTE


               For any of the above  prompts,  use
               the  DELETE key to delete mis-typed
               parameters before  the  terminating
               carriage-return  is  typed.  If you
               note an error in a  parameter  that
               has  already been terminated with a
               carriage-return, type a  CONTROL  C
               to return to the initial prompt and
               reenter all parameters.





4.5.9.3  Reusing Parameters -

After the first memory test has been specified and completed, the
following prompt will be issued.

Re-use parameters (Y/N) [Y] ?

Answering this prompt with a carriage-return, or a Y followed  by
a  carriage-return, results in repeating the last test specified,
using the parameters that were previously  used.   Answering  the
prompt with a N followed by a carriage-return will cause the test
to  prompt  for  new  parameters.   Entering  a  CONTROL  C  will
terminate the diagnosic.



4.5.9.4  Progress REPORTS -

Each time the K  completes  one  full  pass  through  the  memory
specified,  an  end  of pass report is displayed.  A full pass is
defined below.




                              4-66
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


     1.  A complete test of the memory specified with  no  errors
         detected.

     2.  Testing the memory specified until an error occurs


The end of pass message is displayed as follows.

End of Pass nnnnnn, xxxxxx Errors, yyyyyy Total Errors

The pass count nnnnnn  is  a  decimal  count  of  the  number  of
complete  passes  made.   The  error  count  xxxxxx indicates the
number of errors detected on the current pass of the  test.   The
total  count yyyyyy indicates the total errors detected since the
test was started.



4.5.9.5  Error Message Format -

The error message is the same as mentioned in error report format
in paragraph 4.?.



4.5.9.6  K Error Summary Information -

When the K reports a  memory  test  failure  to  the  P.ioc,  the
following information is supplied:

     1.  The address of the failing memory location.

     2.  The data expected and data actually found.

     3.  Error summary information.


The error summary information is supplied as a 3-bit field, which
includes the following:

     1.  A bit indicating a Parity error occurred  while  reading
         the location.

     2.  A bit indicating a NXM error  occurred  while  accessing
         the location.

     3.  A bit indicating Control Bus (CBUS) error occurred while
         accessing the location.





                              4-67
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


When a memory error report is issued for an error detected by the
K,  the  last line of the error report will include a list of the
error summary bits that were set (if any).

A control bus (CBUS) error  indicates  that  the  K  asserted  an
illegal  combination  of  the  three  CCYCLE lines when accessing
control memory.  Since these lines were  previously  tested  from
the  P.ioc  (in  the  Offline P.ioc test), a control bus error is
most likely to be caused by a problem with the K's  drivers  that
assert the CCYCLE lines.



4.5.10  Offline K Test Selector

The Offline K test selector allows you to command a K to  perform
one of its internal microdiagnostic tests.

The Offline K test selector executes from the P.ioc, and uses the
HSC50  K  control  area  to instruct one of the sub-system K's to
test itself.  The operator selects the K to be used, and  selects
the test number of the microdiagnostic test to be executed.

Errors are reported on the console terminal as they occur.



4.5.10.1  Start-Up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).  After receiving the ODL> prompt, type in

T K or TEST K

to start the test.  When the test starts, you  will  receive  the
following report.

HSC50 OFL K Test Selector, Version Vnn-nn



4.5.10.2  Parameter Entry -

The Offline K Test Selector prompts for the following parameters.

K requestor # (1 thru 7) [] ?

Answer this question with single digit (1 thru 7), that specifies
the  requestor  # of the K to be used.  Terminate the response by
typing a carriage-return.  After the requestor # is  supplied,  a



                              4-68
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


K-control-area is located in the control memory and tested.  This
area is required for communicating with the K that  will  perform
its microdiagnostics.  The test then prompts:

Test # (1 thru 11) (O) [] ?

Legal test numbers are octal numbers between 1 and 11(8),  except
for 5.  (Test 5 is the K's control and data memory test, which is
supported by the Offline K/P Memory Test.) Terminate the  test  #
with a carriage-return.  The test will then prompt:

# of passes to perform (D) [1] ?

Enter a decimal number between 1 and 2,147,483,647 (omit commas),
which  specifies  the  number  of times the memory test should be
repeated.  Entering a 0, or just a carriage-return,  will  result
in 1 pass being performed.

The P.ioc now instructs the K to perform the selected test.   The
P.ioc allows up to 10 seconds for the K to complete its test.  If
the K completes the test within this time, the P.ioc will display
an  end  of  pass  message.  If the K fails to complete within 10
seconds, the P.ioc will display a K time-out error  (Error  009).
The  K  microdiagnostics  are  designed  to hang when an error is
detected,  so  all  failures  in  the  microdiagnostics  will  be
reported as time-out errors.

The current test may be aborted at any time by typing  a  CONTROL
C.


                              NOTE


               For any of the above  prompts,  use
               the  DELETE key to delete mis-typed
               parameters before  the  terminating
               carriage-return  is  typed.  If you
               note an error in a  parameter  that
               has  already been terminated with a
               carriage-return, type a  CONTROL  C
               to return to the initial prompt and
               re-enter all parameters.










                              4-69
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


4.5.10.3  Reusing Parameters -

After the first  test  has  been  specified  and  completed,  the
following prompt will be issued.

Re-use parameters (Y/N) [Y] ?

Answering this prompt with a carriage-return, or a Y followed  by
a  carriage-return, results in repeating the last test specified,
using the parameters that were previously  used.   Answering  the
prompt with a N followed by a carriage-return will cause the test
to prompt for new parameters.



4.5.10.4  Progress Reports -

Each time  the  K  completes  one  full  pass  through  the  test
specified,  an  end  of pass report is displayed.  A full pass is
defined as follows.

     1.  The K completes the test with no errors detected.

     2.  The K fails its test, and the P.ioc times-out.


The end of pass message is as follows:

End of Pass nnnnnn, xxxxxx Errors, yyyyyy Total Errors

The pass count nnnnnn  is  a  decimal  count  of  the  number  of
complete  passes  made.   The  error  count  xxxxxx indicates the
number of errors detected on the current pass of the  test.   The
total  count yyyyyy indicates the total errors detected since the
test was started.



4.5.10.5  Error Message Format -

The error message is the same as mentioned in error report format
in paragraph 4.?.











                              4-70
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


4.5.10.6  Specific Error Messages -

Errors detected by this test fall into one of three classes.

     1.  Control memory errors detected by the P.ioc when testing
         the K control area.

     2.  Unexpected traps detected by the P.ioc (NXM and parity).

     3.  Failures in a K microdiagnostic, detected by a time-out.


Control memory errors occur when the P.ioc is testing the portion
of  control  memory  that will be used to communicate with the K.
(The P.ioc does not test data memory.)

Error numbers 000 thru 007 are all control memory errors detected
by  the P.ioc.  The difference among these errors being the exact
step in the memory test where they are detected.  The step  where
an  error  was detected can be a helpful clue to the cause of the
error.

Error 008 indicates that the K failed to initialize properly.

Error  009   indicates   that   the   K   failed   the   selected
microdiagnostic.

Errors 010 and 011 are unexpected trap  errors  detected  by  the
P.ioc.  Error 010 signifies a parity trap occurred, and error 011
indicates a non-existent-memory trap.  The reports for unexpected
trap  errors differ slightly from a data error report, since they
do not display expected and actual data.



4.5.11  Offline Bus Interaction Test

The Offline Bus Interaction test creates  control  and  data  bus
contention  among the K's in the HSC50 subsystem.  The contention
is generated by simultaneously testing different portions of  the
same  memory  (control  and/or  data) from different K's.  In the
process of testing the memories, the various K's in the subsystem
will  contend with each other for the use of the control and data
memory.  While the K's are generating bus contention,  the  P.ioc
is  exercising  the OCP, TU58, and all three HSC50 memories.  The
Bus Interactions test is a HSC50  system  exerciser  designed  to
stimulate  intermittent  faults  that  may not be detected by the
other offline tests.





                              4-71
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


This test requires a minimum of  two  working  K's  in  order  to
operate,  and  will use a maximum of 7 K's if they are available.
The more K's that are available for use by this test, the greater
the  amount  of  bus  contention.   The  run  time  of  this test
increases linearly as the number of K's is increased.   A  larger
number of K's makes it easier to isolate problems to a particular
source.

Errors are reported on the console terminal as they occur.



4.5.11.1  Start-Up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).  After receiving the ODL> prompt, type in

T B or TEST BUS

to start the diagnosic.  When the test starts, you  will  receive
the following report.

HSC50 OFL Bus Interaction Test, Version Vnn-nn



4.5.11.2  Parameter Entry -

After displaying the program name and version,  the  Control  and
Data  memories  are  sized  to  determine  the  amount  of memory
available for the interaction test.  Then the user is prompted to
select the K's that should be used for the test, as follows.

Use requestor #001, K.ci (Y/N) [Y] ?

Answer  with  a  carriage-return,  (or  a   Y   followed   by   a
carriage-return)  if  the  K  should  be  used.  Answer with an N
followed by a carriage-return if the K should not be used.

At least two working K's must be used to run the  bus  contention
test,  since one K cannot generate bus contention by itself.  The
program will display the following error message if less  than  2
K's remain after the user has indicated which K's should be used.

Not Enough K's Available for Test

If two or more K's are available for the testing, the  test  will
prompt:





                              4-72
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


P.ioc Memory Interaction Desired (Y/N) [Y] ?

Type a carriage-return if you desire the P.ioc to  interact  with
memory  while  the  K's  are generating bus contention.  Type a N
followed by a carriage-return if P.ioc memory interaction is  not
desired.   If  P.ioc  memory  interaction  is  not  selected, the
program will skip to the OCP interaction prompt.  If P.ioc memory
interaction is selected, the test will prompt:

Interact With Program Memory (Y/N) [Y] ?

Type a carriage-return if Program memory interaction is  desired,
or  type  a  N  followed  by  a carriage-return if Program memory
interaction is not desired.  The test will prompt:

Interact With Control Memory (Y/N) [N] ?

Type a carriage-return if Control memory interaction is  desired,
or  type  a  N  followed  by  a carriage-return if Control memory
interaction is not desired.  The test will prompt:

Interact With Data Memory (Y/N) [Y] ?

Type a carriage-return if Data memory interaction is desired,  or
type a N followed by a carriage-return if Data memory interaction
is not desired.  The test will prompt:

OCP Interaction Desired (Y/N) [Y] ?

Type a carriage-return if interaction with the  Operator  Control
Panel  (OCP)  is desired.  Type a N followed by a carriage-return
if OCP is not desired.

Interact With TU58 (Y/N) [Y] ?

Type a carriage-return if interaction with the TU58  is  desired,
or type a N followed by a carriage-return if interaction with the
TU58 is not desired.  The test will now prompt:

# of passes to perform (D) [1] ?

Enter a decimal number between 1 and 2,147,483,647 (omit commas),
which  specifies  the  number  of times the memory test should be
repeated.  Entering a 0, or just a carriage-return,  will  result
in 1 pass being performed.

The test will now begin.  The test continues until all passes are
completed, or unitil terminated by a CONTROL C.





                              4-73
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


                              NOTE


               For any of the above  prompts,  use
               the  DELETE key to delete mis-typed
               parameters before  the  terminating
               carriage-return  is  typed.  If you
               note an error in a  parameter  that
               has  already been terminated with a
               carriage-return, type a  CONTROL  C
               to return to the initial prompt and
               reenter all parameters.





4.5.11.3  Reusing Parameters -

After the first memory test has been specified and completed, the
following prompt will be issued.

Re-use parameters (Y/N) [Y] ?

Answering this prompt with a carriage-return, or a Y followed  by
a  carriage-return, results in repeating the last test specified,
using the parameters that were previously  used.   Answering  the
prompt with a N followed by a carriage-return will cause the test
to prompt for new parameters.



4.5.11.4  Progress Reports -

Each time the program completes one full set  of  bus  contention
tests,  an  end  of pass report is displayed.  A pass consists of
completing a full set of contention  tests,  including:   control
bus  tests,  data  bus  tests,  and combined control and data bus
tests.  The end of pass message is displayed as follows.

End of Pass nnnnnn, xxxxxx errors, yyyyyy total errors

Where:

      o  nnnnnn = decimal count of the number of passes completed

      o  xxxxxx = decimal count of the number of errors  detected
         on current pass





                              4-74
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


      o  yyyyyy = decimal count of the  total  number  of  errors
         detected since the test was initiated




4.5.11.5  Error Message Format -

The the error message is the same as mentioned  in  error  report
format in paragraph 4.?.

You may also receive the following type of error message:

Memory Test Configuration:
K.ci  ,requestor 001, M.ctl 16000700 - 16100274
K.sdi ,requestor 006, M.ctl 16100300 - 16177674

This portion of the error report summarizes the  part  of  memory
being  tested  by  each  K.   In  the example above, the K.ci was
testing addresses 16000700 thru 16100274 of the  control  memory,
and  the  K.sdi  in  requestor  position  6 was testing addresses
16100300 thru 16177674 of the control memory.



4.5.11.6  K Error Summary Information -

When the K reports a  memory  test  failure  to  the  P.ioc,  the
following information is supplied.

      o  The address of the failing memory location
      o  The data expected and data actually found
      o  Error summary information


The error summary information is supplied as a 3-bit field, which
includes the following:

      o  A bit indicating a parity error occurred  while  reading
         the location

      o  A bit indicating a NXM error  occurred  while  accessing
         the location

      o  A bit indicating Control Bus (CBUS) error occurred while
         accessing the location







                              4-75
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


When a memory error report is issued for an error detected by the
K,  the  last line of the error report will include a list of the
error summary bits that were set (if any).

A control bus (CBUS) error  indicates  that  the  K  asserted  an
illegal  combination  of  the  three  CCYCLE lines when accessing
control memory.  Since these lines were  previously  tested  from
the  P.ioc  (in  the  Offline P.ioc test), a control bus error is
most likely to be caused by a problem with the K's  drivers  that
assert the CCYCLE lines.



4.5.12  Offline Memory Refresh Test

The Offline Memory  Refresh  test  is  designed  to  find  memory
problems related to refresh.  Patterns are written to memory, and
checked after waiting one minute.  Three  separate  patterns  are
used  to test each memory bit (including parity bits) in both the
'one' and 'zero' states.  All three  HSC50  memories  are  tested
(Program,  Control,  and  Data),  although  only  the Program and
Control memories require refreshing.  Tests of  Data  memory  are
included  because  some  static  ram  failures  resemble  refresh
problems.

The refresh test can find problems in the memories that will  not
be  detected by the normal memory tests.  The refresh test is not
intended to be run on  memories  which  fail  the  normal  memory
tests.  Each pass of the refresh test requires 3 minutes.



4.5.12.1  Start-Up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).  After receiving the ODL> prompt, type in

T R or TEST REFRESH

to start the test.  When the test starts, you  will  receive  the
following report.

HSC50 OFL Memory Refresh Test, Version Vnn-nn










                              4-76
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


4.5.12.2  Parameter Entry -

The Offline Memory Refresh Test first prompts:

# of passes to perform (D) [1] ?

Enter a decimal number between 1 and 2,147,483,647 (omit commas),
which  specifies  the  number of times the refresh test should be
repeated.  (Entering a 0, or just a carriage-return, will  result
in  1  pass  being performed.) The test will now begin.  The test
can be aborted at any time by typing a control-c.  Each  pass  of
the test requires 3 minutes to complete.


                              NOTE


               For any of the above  prompts,  use
               the  DELETE key to delete mis-typed
               parameters before  the  terminating
               carriage-return  is  typed.  If you
               note an error in a  parameter  that
               has  already been terminated with a
               carriage-return, type  a  control-c
               to return to the initial prompt and
               re-enter all parameters.





4.5.12.3  Reusing Parameters -

After the refresh test completes, the following  prompt  will  be
issued:

Re-use parameters (Y/N) [Y] ?

Answering this prompt with a carriage-return, or a  'Y'  followed
by  a  carriage-return,  results  in repeating the test using the
parameters that were previously used.  Answering the prompt  with
a 'N' followed by a carriage-return will cause the test to prompt
for new parameters.










                              4-77
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


4.5.12.4  Progress Reports -

Each time the refresh test completes one full  pass,  an  end  of
pass  report  is  displayed.   Each  pass  of the test requires 3
minutes to complete.  The end of pass  message  is  displayed  as
follows:

End of Pass nnnnnn, xxxxxx Errors, yyyyyy Total Errors

The pass count 'nnnnnn' is a  decimal  count  of  the  number  of
complete  passes  made.   The  Error count (xxxxxx) indicates the
number of errors detected on the current pass.  The  total  error
count (yyyyyy) indicates the number of errors detected during the
passes completed so far.



4.5.12.5  Error Message Format -

The error message is the same as mentioned in error report format
in paragraph 4.?.



4.5.13  Offline Operator Control Panel (OCP) Test

The Offline Operator Control Panel (OCP) test provides a means to
test  the  operation  of the HSC50's lamps and switches.  Testing
includes the 5 OCP lamps and switches, the  STATE  LED,  and  the
SECURE/ENABLE switch and ENABLE LED.



4.5.13.1  Start-up Procedure -

Use the start-up procedure for the Offline diagnostics (paragraph
5.?.?).  After receiving the ODL> prompt, type in

T O or TEST OCP

to start the test.  When the test starts, you  will  receive  the
following report.

HSC50 OFL Operator Control Panel Test, Version Vnn-nn









                              4-78
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


4.5.13.2  Parameter Entry -

The test first checks the position of the  SECURE/ENABLE  switch,
via  a  bit  in  the P.ioc's Control and Status Register (address
170040).  If the switch is in the SECURE position, the  following
prompt is issued, otherwise the test skips to the next prompt.

Put SECURE/ENABLE switch into ENABLE position

If the SECURE/ENABLE switch is in the ENABLE  position,  and  the
above prompt is issued anyway, there is a problem with the bit in
the P.ioc  CSR  that  monitors  the  SECURE/ENABLE  switch.   The
program  waits  until  the SECURE/ENABLE switch is changed to the
ENABLE position, then issues the following message:

(ENABLE LED should be lit, STATE LED should be blinking)

Check that the ENABLE LED is lit,  and  STATE  LED  is  blinking.
There  are  two STATE LEDs, one is to the left of the INIT switch
on the HSC50's front panel, the other is  located  on  the  P.ioc
module (the fourth LED from the bottom of the rightmost module in
the HSC50 card cage).  The test will now prompt for a lamp test:

Press FAULT (All OCP lamps should light) (Y/N) [Y] ?

Press the FAULT lamp and observe that all OCP  lamps  light.   If
none  of the lamps light, there may be a problem in the lamp test
logic on the OCP assembly.  (Refer to OCP schematics).  If one or
two  lamps  fail  to light, replace those lamps before proceeding
with  the  test.   If  all   lamps   light   properly,   type   a
carriage-return to continue the test.

Now the program  checks  that  all  OCP  switches  are  OFF  (out
position).   If  any  switch  bits  in the P.ioc's Switch/Display
register read as 'ones' (on), the program lights  the  lamps  for
those switches, and prompts the operator:

Put all lit switches in OFF (out) position (Y/N) [Y] ?

If the FAULT or INIT lamps are lit (non-locking switches),  there
is  a  problem  with  the wiring in those switches, or with their
respective bits in the Switch/Display register.  Otherwise  press
all   lit   switches   to   release   their  locks,  and  type  a
carriage-return.  If the message repeats, and one or  more  lamps
remain  lit  even  thought  the  switches are OFF (out position),
there is a problem with the P.ioc's Switch  Display  register  or
the wiring between the OCP and the register.






                              4-79
CONTROLLER DIAGNOSTICS Company Confidential
OFFLINE DIAGNOSTICS


The program will now test each of the  OCP  switches,  one  at  a
time.  A switch will be lit, then the operator will be prompted:

Press and release the lit switch

Press the switch that is lit.  The program  will  allow  about  1
second  for  the  switch  to be released after it is pressed, and
then will continue to the next prompt.  If the program  fails  to
respond  when  a  switch is pressed, there is a problem with that
switch or with  the  corresponding  bit  in  the  P.ioc's  Switch
Display register.

For those switches that lock in the ON position (ONLINE  and  the
two unmarked switches), the program will prompt:

Press and release the lit switch again

Press the switch again to return it to the  OFF  (out)  position.
If  the ONLINE switch or either of the unmarked switches fails to
lock in the ON position, the switch is defective  and  should  be
replaced.

After the OCP switch tests are completed, several features of the
SECURE/ENABLE  switch  are  tested.  The program will begin these
tests by prompting:

Put SECURE/ENABLE switch into SECURE position

The program will wait until the SECURE/ENABLE switch  is  in  the
proper  position  before  continuing.   If  the  program fails to
respond when the switch is moved to the SECURE position, there is
a  problem  with  the Secure/Enable switch or the P.ioc's Control
and Status register.

Once the program  detects  that  the  switch  is  in  the  SECURE
position, it will prompt:

(ENABLE LED should turn off)

Check that the ENABLE LED is off.  If this LED fails to turn  off
when  the  switch  is  in  the SECURE position, a short or wiring
problem is likely.

The program will next prompt:

Press INIT (HSC should not re-boot) (Y/N) [Y] ?

Press the INIT switch.  When the SECURE/ENABLE switch is  in  the
SECURE  position, pressing the INIT switch should have no effect.
(Do not press any other switch or an error message will  result.)



                              4-80
                      CONTROLLER DIAGNOSTICS Company Confidential
                                              OFFLINE DIAGNOSTICS


If  the HSC50 starts to perform a bootstrap, (INIT lamp turns on,
green  LED  on  P.ioc  turns  off,  TU58  starts   moving),   the
SECURE/ENABLE  switch  is  not  disabling  the action of the INIT
switch.  Refer to the circuit schematics for the OCP assembly.

After pressing INIT, type a  carriage-return  to  continue.   The
test will respond with the following prompt:

Press terminal BREAK key (HSC should not halt) (Y/N) [Y] ?

Press the BREAK key as directed.  When in SECURE mode, the  BREAK
key  should  not  cause the P.ioc's F-11 processor to halt (enter
ODT).  If the terminal displays the "@" character when  BREAK  is
pressed,  the SECURE/ENABLE switch is not disabling the action of
the BREAK key.

After pressing the BREAK key, type a carriage-return to  continue
the test.  The final prompt of the test is:

Put SECURE/ENABLE switch into ENABLE position

The test will wait until the SECURE/ENABLE switch is returned  to
the  ENABLE  position, then the test will terminate and return to
the Offline Loader.

The test may be aborted at any time by typing a control-c.



4.5.13.3  Reusing Parameters -

After the OCP  test  completes,  the  following  prompt  will  be
issued:

Re-use parameters (Y/N) [Y] ?

Answering this prompt with a carriage-return, or a  'Y'  followed
by  a  carriage-return,  results  in repeating the test using the
parameters that were previously used.  Answering the prompt  with
a 'N' followed by a carriage-return will cause the test to prompt
for new parameters.



4.5.13.4  Error Message Format -

The error message format is the same as  mentioned  in  paragraph
4.?.





                              4-81
CONTROLLER DIAGNOSTICS Company Confidential
HOST-EXECUTED DIAGNOSTICS


4.6  HOST-EXECUTED DIAGNOSTICS

There are no HSC50-specific programs that execute in a host  CPU.
The  INL  CI  RESPONDER  is implemented in the HSC50 to interface
with the CI  Node  Tester  (CINT)  and  the  CI  Exerciser  (CIE)
programs.















































                              4-82
! HSC50 OFL Diagnostic Loader Help File - V01-01
! Capital letters = required input, lower case = optional
!Commands (terminated by CR):
! 'Examine <address>'		;display data at <address> specified
! 'Deposit <address> <data>'	;deposit <data> to <address>
!	<address> = digit string in current default radix, or:
!		'*' = use same address as last ex or de
!		'+' = use address following last address
!		'-' = use address preceeding last address
!		'@' = use <data> from last ex or de as address
! 'HElp'			;print this file
! '@<filename>'			;execute indirect command file
! 'Load <filename>'		;load file to diagnostic partition
! 'REpeat <command>'		;repeat specified command until ^C
! 'SEt Default <option>,<option>;set default radix or data length
!    <options> = Byte,Word,Long,Quad,Hex,Octal,Decimal
! 'SEt Relocation:#'		;set relocation register to #
!	relocation register is 22-bit positive # added to address
!	of all 'Ex' and 'De' commands.
! 'SHow'			;display defaults and Loader version
! 'SIze'			;Size HSC50 memories and display K status
! 'Start'			;start program in diagnostic partition
! 'Test Bus'			;load and start the OFL Bus Interaction test
! 'Test K'			;load and start the OFL K Test Selector
! 'Test MEmory'			;load and start the OFL Memory Test
! 'Test MEmory By K'		;load and start the OFL K/P Memory Test
! 'Test Ocp'			;load and start the OFL OCP Test
! 'Test Refresh'		;load and start the OFL Refresh Test
!
!Qualifiers (switches) for 'Ex' and 'De':
! '/Next:#'			;repeat Ex or De on next '#' addresses
! '/Byte,/Word,/Long,/Quad'	;use specified data length instead of default
! '/Octal,/Decimal,/Hex'	;use specified radix for Ex display
! '/INH'			;inhibit display of examined data
! <end of help file>
HSC-50 VERSION 2.00 RELEASE NOTES


         







                                        HSC50

                                        Y2.00

                                    Release Notes










                                     October 1984


                 This  document  contains  information  not  included
                 elsewhere  in  the  document  set.   Typically, this
                 information  covers  firmware  and/or  documentation
                 errors  that  were  discovered  or changes that were
                 made late  in  the  development  cycle,  plus  hints
                 concerning subsystem operation.
                 This document should be read before the subsystem is
                 installed or used.




              REVISION/UPDATE INFORMATION: 
                                           This document supersedes
                                           the HSC50 Mass Storage Server
                                           Subsystem Usage Guidelines,
                                           Version V1.10
                                           (Order No. AV-X703B-TK).

              FIRMWARE VERSION:            HSC50 Y2.00







                DIGITAL EQUIPMENT CORPORATION  --  MAYNARD, MASSACHUSETTS


                                             First Edition June, 1983
                                        Second Edition December, 1983
                                          Third Edition October, 1984


                 The material in this  manual  is  for  informational
                 purposes and is subject to change without notice.

                 Digital    Equipment    Corporation    assumes    no
                 responsibility  for  any  errors which may appear in
                 this manual.





               Copyright (c) 1983, 1984, Digital Equipment Corporation
                                 All Rights Reserved


                                  Printed in U.S.A.




               The  following  are  trademarks  of  Digital   Equipment
               Corporation, Maynard, Massachusetts:

                     DEC              DECnet             OMNIBUS
                     DECUS            DECsystem-10       OS/8   
                     DIGITAL          DECSYSTEM-20       PDT    
                     Digital Logo     DECwriter          RSTS   
                     PDP              DIBOL              RSX    
                     UNIBUS           EduSystem          VMS    
                     VAX              IAS                VT     
                     UDA50            RA60               RA80   
                     HSC              RA81               MASSBUS


                                  TABLE  OF CONTENTS
                                 -------------------


                                      CONTENTS


           1       Y2.00 GENERAL INFORMATION  . . . . . . . . . . . . . 1
           1.1       Related Documentation  . . . . . . . . . . . . . . 1

           2       THE HSC50 VERSION Y2.00 KIT  . . . . . . . . . . . . 3
           2.1       Contents . . . . . . . . . . . . . . . . . . . . . 3
           2.2       Installing The Y2.00 Kit . . . . . . . . . . . . . 3
           2.3       Contents Of The Y2.00 Cassettes  . . . . . . . . . 6
           2.3.1       HSC50 SYSTEM TAPE Y200 . . . . . . . . . . . . . 6
           2.3.2       HSC50 UTILITY TAPE Y200  . . . . . . . . . . . . 7
           2.3.3       HSC50 OFFLINE DIAGS Y200 . . . . . . . . . . . . 7

           3       REVISION LEVELS  . . . . . . . . . . . . . . . . . . 8
           3.1       VAXcluster . . . . . . . . . . . . . . . . . . . . 8
           3.2       VAX/VMS  . . . . . . . . . . . . . . . . . . . . . 8
           3.3       CI780 Microcode  . . . . . . . . . . . . . . . . . 8
           3.4       HSC50  . . . . . . . . . . . . . . . . . . . . . . 8
           3.4.1       Firmware Version   . . . . . . . . . . . . . . . 8
           3.4.2       HSC50 Patches  . . . . . . . . . . . . . . . . . 9
           3.5       Disk Drives  . . . . . . . . . . . . . . . . . . . 9
           3.5.1       RA60 Disk Drive  . . . . . . . . . . . . . . . . 9
           3.5.2       RA81 Disk Drive  . . . . . . . . . . . . . . .  10
           3.5.3       RA80 Disk Drive  . . . . . . . . . . . . . . .  10
           3.6       Tape Formatters  . . . . . . . . . . . . . . . .  10
           3.6.1       TA78 Tape Formatter  . . . . . . . . . . . . .  11

           4       Y2.00 ENHANCEMENTS . . . . . . . . . . . . . . . .  12
           4.1       User Interface . . . . . . . . . . . . . . . . .  12
           4.2       Host Interface . . . . . . . . . . . . . . . . .  12
           4.2.1       Error-logging  . . . . . . . . . . . . . . . .  12
           4.2.2       "VC Closed" Messages . . . . . . . . . . . . .  12
           4.3       Disk Firmware  . . . . . . . . . . . . . . . . .  12
           4.3.1       Bad Block Replacement  . . . . . . . . . . . .  12
           4.3.1.1       Controller-Initiated Replacement . . . . . .  12
           4.3.1.2       Error Messages . . . . . . . . . . . . . . .  13
           4.3.2       DISK ONLINE Command  . . . . . . . . . . . . .  13
           4.4       Magnetic Tape Firmware . . . . . . . . . . . . .  13
           4.4.1       Tape Server  . . . . . . . . . . . . . . . . .  13
           4.4.1.1       Error Messages . . . . . . . . . . . . . . .  14
           4.5       Diagnostics  . . . . . . . . . . . . . . . . . .  14
           4.5.1       ILTAPE . . . . . . . . . . . . . . . . . . . .  14
           4.5.1.1       Canned Sequence  . . . . . . . . . . . . . .  14
           4.6       Utilities  . . . . . . . . . . . . . . . . . . .  15
           4.6.1       Backup Utility (BACKUP)  . . . . . . . . . . .  15
           4.6.1.1       Backup - General Information . . . . . . . .  15
           4.6.2       Restore Utility (RESTOR) . . . . . . . . . . .  15
           4.6.3       SET / SHOW Utility (SETSHO)  . . . . . . . . .  16
           4.6.3.1       SET ALLOCATE . . . . . . . . . . . . . . . .  16
           4.6.3.2       SET MAXFORMATTERS  . . . . . . . . . . . . .  16
           4.6.3.3       SET MAX_TAPE . . . . . . . . . . . . . . . .  16


           4.6.3.4       SET START  . . . . . . . . . . . . . . . . .  17
           4.6.4       TU58 Directory Utility (DIRECT)  . . . . . . .  17

           5       V1.10 RESTRICTIONS NOW LIFTED IN Y2.00 . . . . . .  18
           5.1       Initialization Problems  . . . . . . . . . . . .  18
           5.2       User Interface Problems  . . . . . . . . . . . .  18
           5.2.1       WRITE PROTECT Light  . . . . . . . . . . . . .  18
           5.3       Disk Firmware Problems . . . . . . . . . . . . .  18
           5.3.1       Drives Mounted /FOREIGN  . . . . . . . . . . .  18
           5.3.2       Duplicate Units  . . . . . . . . . . . . . . .  18
           5.3.3       Duplicate Unit Number 0  . . . . . . . . . . .  19
           5.3.4       Error Recovery - Bad Headers . . . . . . . . .  19
           5.3.5       DISK ONLINE Command  . . . . . . . . . . . . .  19
           5.3.5.1       Drive Error  . . . . . . . . . . . . . . . .  19
           5.3.5.2       Reading FCT Or RCT . . . . . . . . . . . . .  19
           5.3.5.3       Unrecoverable Error  . . . . . . . . . . . .  20
           5.4       Diagnostic Problems  . . . . . . . . . . . . . .  20
           5.4.1       ILEXER . . . . . . . . . . . . . . . . . . . .  20
           5.4.1.1       Unit Numbers . . . . . . . . . . . . . . . .  20
           5.4.2       Periodic Tests (K.sdi) . . . . . . . . . . . .  20
           5.5       Utility Problems . . . . . . . . . . . . . . . .  20
           5.5.1       FORMAT Utility . . . . . . . . . . . . . . . .  20
           5.5.2       VERIFY Utility . . . . . . . . . . . . . . . .  20
           5.5.2.1       EDC Errors . . . . . . . . . . . . . . . . .  20
           5.5.2.2       Incorrect Error Message  . . . . . . . . . .  21


           6       Y2.00 RESTRICTIONS . . . . . . . . . . . . . . . .  22
           6.1       User Interface Restrictions  . . . . . . . . . .  22
           6.1.1       Operator Control Panel (OCP) . . . . . . . . .  22
           6.1.2       Console Terminal . . . . . . . . . . . . . . .  22
           6.1.2.1       Control Sequences  . . . . . . . . . . . . .  22
           6.1.2.2       Console Problems . . . . . . . . . . . . . .  22
           6.1.3       Diagnostic And Utilities Protocol (DUP)  . . .  22
           6.2       Host Interface Restrictions  . . . . . . . . . .  22
           6.2.1       Heavy Virtual Circuit Activity   . . . . . . .  23
           6.3       Disk Firmware Restrictions . . . . . . . . . . .  23
           6.3.1       Disk Volume Shadowing  . . . . . . . . . . . .  23
           6.3.2       Disk Drive State Transitions . . . . . . . . .  23
           6.3.3       General Manipulation Of Panel Switches . . . .  23
           6.3.4       Manipulation Of SDI Cables . . . . . . . . . .  24
           6.3.5       Manipulation Of Unit Plugs . . . . . . . . . .  24
           6.3.6       Spin-up Of AVAILABLE Disk Drives . . . . . . .  24
           6.4       Magnetic Tape Firmware Restrictions  . . . . . .  24
           6.4.1       Error Logs . . . . . . . . . . . . . . . . . .  24
           6.4.2       Features Not Supported . . . . . . . . . . . .  24
           6.4.3       Number Of Tape Drives Supported  . . . . . . .  25
           6.4.4       Tape Drive State Transitions . . . . . . . . .  25
           6.4.5       Duplicate Tape Units . . . . . . . . . . . . .  25
           6.5       Diagnostics Restrictions . . . . . . . . . . . .  25
           6.5.1       General Restrictions . . . . . . . . . . . . .  26
           6.5.1.1       Dual-ported Drives . . . . . . . . . . . . .  26
           6.5.1.2       Inoperative Drives . . . . . . . . . . . . .  26
           6.5.1.3       Periodic Diagnostics . . . . . . . . . . . .  26
           6.5.1.4       User Syntax  . . . . . . . . . . . . . . . .  26
           6.5.2       ILDISK . . . . . . . . . . . . . . . . . . . .  27
           6.5.2.1       Initiation . . . . . . . . . . . . . . . . .  27
           6.5.2.2       Unknown Disks  . . . . . . . . . . . . . . .  27
           6.5.2.3       One Disk Drive; Two HSC's  . . . . . . . . .  27
           6.5.3       ILTAPE . . . . . . . . . . . . . . . . . . . .  27
           6.5.3.1       Initiation . . . . . . . . . . . . . . . . .  27
           6.5.3.2       Read Reverse . . . . . . . . . . . . . . . .  27
           6.5.4       ILEXER . . . . . . . . . . . . . . . . . . . .  27
           6.6       Utilities Restrictions . . . . . . . . . . . . .  27
           6.6.1       Backup Utility (BACKUP)  . . . . . . . . . . .  28
           6.6.1.1       Drives Already In Use  . . . . . . . . . . .  28
           6.6.1.2       Tape Format  . . . . . . . . . . . . . . . .  28
           6.6.2       Restore Utility (RESTOR) . . . . . . . . . . .  28
           6.6.2.1       Drives Already In Use  . . . . . . . . . . .  28
           6.6.2.2       Tape Format  . . . . . . . . . . . . . . . .  28
           6.6.3       Set / Show Utility (SETSHO)  . . . . . . . . .  28
           6.6.3.1       SET CI . . . . . . . . . . . . . . . . . . .  29
           6.6.3.2       SET/SHOW CONTROL_BLOCKS  . . . . . . . . . .  29
           6.6.3.3       SET DUMP . . . . . . . . . . . . . . . . . .  29
           6.6.3.4       SET HOST . . . . . . . . . . . . . . . . . .  29
           6.6.3.5       SET MAX_FORMATTER  . . . . . . . . . . . . .  29
           6.6.3.6       SET MAX_TAPE . . . . . . . . . . . . . . . .  30
           6.6.3.7       SET REQUESTOR, SHOW REQUESTOR  . . . . . . .  30
           6.6.3.8       SET/SHOW SHORT_LIFETIME_CONTROL_BLOCKS . . .  30
           6.6.3.9       SET START  . . . . . . . . . . . . . . . . .  31
           6.6.3.10      SET WCS  . . . . . . . . . . . . . . . . . .  31
           6.6.4       TUCOPY . . . . . . . . . . . . . . . . . . . .  31
           6.6.5       PURGE  . . . . . . . . . . . . . . . . . . . .  31


           7       V2.00 KNOWN ERRORS . . . . . . . . . . . . . . . .  32

           8       Y2.00 KNOWN ERRORS . . . . . . . . . . . . . . . .  33
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 1
   Y2.00 GENERAL INFORMATION


        1  Y2.00 GENERAL INFORMATION

        This document describes the differences in functionality  between  the
        V1.10  and  Y2.00  versions of the firmware for the HSC50 Mass Storage
        Server.  It also identifies any differences  that  exist  between  the
        Y2.00  version  and  the  features  that  are  described  in the HSC50
        Installation Manual (EK-HSC50-IN), the HSC50  User  Guide  Revision  2
        (EK-HSC50-UG-002),   and   the   HSC50  Utilities  User  Documentation
        (EK-UHSC5-UG).



        1.1  Related Documentation

        External Digital customers  may  order  from  the  following  list  of
        HSC50-related manuals.

            o  HSC50 User Guide (EK-HSC50-UG)

            o  HSC50 Installation Manual (EK-HSC50-IN)

            o  HSC50 Service Manual (EK-HSC50-SV)

            o  HSC50 Maintenance Guide (AA-P672A-TC)

            o  HSC50 Illustrated Parts Breakdown (EK-HSC50-IP)

            o  HSC50 Inline Diagnostics User Documentation (EK-IHSC5-UG)

            o  HSC50 Offline Diagnostics User Documentation (EK-OHSC5-UG)

            o  HSC50 Utilities User Documentation (EK-UHSC5-UG)

            o  DSA Controllers Documentation Kit (QP906-GZ)

            o  DSA Drives Documentation Kit (QP907-GZ)

            o  TU58 DECtape II User Guide (EK-0TU58-UG)

            o  Star Coupler User Guide (EK-SC008-UG)
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 2
   Y2.00 GENERAL INFORMATION


           The  DSA  Controllers  Documentation  Kit  consists  of   a   small
           loose-leaf   binder   and   the  maintenance  guides  for  all  DSA
           controllers.  The DSA Drives Documentation kit consists of the  two
           small  binders  containing the current maintenance guides for disks
           and tapes that operate on the DSA controllers.

           Within the United States,  external  Digital  customers  can  order
           these  items  from  the  Accessories  and Supplies Group (toll free
           number,  800-258-1710).   Mail  orders   are   addressed   to   the
           appropriate primary distribution center, as follows:



           Northeast/Mid-Atlantic Region


              Accessories & Supplies Group
              Cotton Road
              Nashua, New Hampshire 03060
              Tel:  (603) 884-5111


        Central Region


              Accessories & Supplies Group
              1050 E. Remington Road
              Schaumberg, Illinois 60195
              Tel:  (312) 640-5612


        Western Region


              Accessories & Supplies Group
              Moffett Park Warehouse
              632 East Caribbean Drive
              Sunnyvale, California 94086
              Tel:  (408) 734-9125



        Outside the United States, consult local Digital offices.

        Internal Digital customers can order the  related  documents  directly
        from Printing and Circulation Services, 444 Whitney Street, Northboro,
        Massachusetts 01532.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 3
   THE HSC50 VERSION Y2.00 KIT


        2  THE HSC50 VERSION Y2.00 KIT

        2.1  Contents

        Both current and new customers will receive a  distribution  kit  with
        the following contents:

         o  Three (3) TU58 cassettes labelled as follows:

             -  HSC50 SYSTEM TAPE Y200

             -  HSC50 UTILITY TAPE Y200

             -  HSC50 OFFLINE DIAGS Y200


         o  HSC50 Y2.00 Release Notes.

        The cassette marked SYSTEM TAPE is the primary  tape,  which  must  be
        loaded at all times for normal system operation.

        The cassette marked UTILITY TAPE is the secondary system tape,  to  be
        mounted  in  conjunction  with the primary tape when Utility or Online
        Diagnostic functions are being used.

        The cassette marked  HSC50  OFFLINE  DIAGS  is  mounted  whenever  the
        Offline Diagnostic programs are to be run in stand-alone mode.



        2.2  Installing The Y2.00 Kit


                                         NOTE

                An HSC50 subsystem already running  version  V1.00  or
                V1.10  should  be  upgraded to Y2.00.  Installation of
                the Y2.00  kit  at  a  new  customer  site  should  be
                performed  by  qualified  field service personnel as a
                part of the Field Acceptance and  Checkout  procedures
                described in the HSC50 Installation Manual.


        Installation of the HSC50 Y2.00  kit  is  accomplished  by  using  the
        following procedure.

           1.  Ensure that any host (re-)making a logical connection  may  not
               indavertently   affect   the  integrity  of  the  Y2.00  SYSTEM
               cassette.  With the  subsystem  initialized  from  the  current
               (V1.00 or V1.10) system cassette:

               o  Open the HSC50 front door.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 4
   THE HSC50 VERSION Y2.00 KIT


               o  Push the Secure/Enable switch into the ENABLE position.

               o  Ensure that the Online switch is in the "out" position  (the
                  OFFLINE state).


       2.  Type CTRL/Y, followed by SHO SYS.

       3.  Preserve the resulting hardcopy record of the installation-specific
           parameter settings for later use.

       4.  Select a copy of HSC50 SYSTEM TAPE V200 and ensure that  the  write
           protect  tab  has been moved towards the edge of the tape cartridge
           to set it into the RECORD position.

       5.  Mount the HSC50 SYSTEM TAPE Y200 cartridge in Drive 0 of the TU58.

       6.  Select a copy of the HSC50 UTILITY TAPE Y200 and  ensure  that  the
           write  protect tab is in the RECORD position.  If not, move the tab
           towards the edge of the tape cartridge to set it  into  the  RECORD
           position.

       7.  Mount the HSC50 UTILITY TAPE Y200 cartridge in Drive 1 of the TU58.

       8.  Push and release the Init switch while holding in the Fault switch.
           Continue  holding in the Fault switch until the INIPIO-I Booting...
           message appears on the console.  This action causes the software to
           autoconfigure  itself by initializing certain information contained
           on the SYSTEM TAPE, as described in section 3.2.1 of the HSC50 User
           Guide.

       9.  Wait until the initialization message appears on  the  console,  as
           shown in section 3.2 of this document.

      10.  Type CTRL/Y,  followed  by  RUN  SETSHO.   This  initiates  a  full
           interactive  session  allowing multiple SET and SHOW commands to be
           issued.

      11.  Refer to the hardcopy record from the SHO SYS command in step 2.

      12.  Restore installation-specific parameters (such as NAME, ID,  Sector
           size,  ..)  to  their  previous  state  (under V1.00 or V1.10) with
           appropriate SET commands.  Refer to the HSC50 User  Guide,  chapter
           3, for instructions on altering subsystem parameters.

      13.  Confirm with a SHO SYS command that the previous steps achieved the
           desired settings.

      14.  Type EXIT.  This ensures that the SETSHO process is terminated with
           any  required update of the system configuration table (SCT) on the
           SYSTEM TAPE.

      15.  If the following prompt is issued, respond with Y:

                    Rebooting HSC;  Y to continue,  CNTRL/Y to abort:
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 5
   THE HSC50 VERSION Y2.00 KIT


      16.  Refer to the TU58 Duplication Utility in Chapter  3  of  the  HSC50
           User  Guide, and generate at least two backup copies of each of the
           three master cassettes in the Y2.00 kit.

      17.  Select a copy of HSC50 SYSTEM TAPE Y200 and ensure that  the  write
           protect

      18.  Restore the Online switch to the "in" position (the  ONLINE  state)
           when   the   previous   step   is  completed,  including  the  full
           reinitialization process if it proves necessary.

      19.  Restore the Secure/Enable switch to the state which is  normal  for
           the installation, and close the HSC50 front door.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 6
   THE HSC50 VERSION Y2.00 KIT


        2.3  Contents Of The Y2.00 Cassettes

        After making backup copies of each of the three Y2.00  cassettes,  the
        user  may invoke the HSC50 DIRECTORY utility to ascertain the contents
        of the individual tapes.  Type CTRL/Y followed by DIR DDn:,  depending
        on  the  TU58  drive  in  which the specific cassette is mounted.  The
        resulting file directory output can be checked against  the  following
        lists  to  ensure  that the appropriate files are present and that the
        size of the files are correct.



        2.3.1  HSC50 SYSTEM TAPE Y200 -


           SYSCOM.INI     5                 SCT.   INI     1
           INIPIO.INI    16                 EXEC.  INI    44
           SUBLIB.INI    15                 HSCODT.INI    32
           SETSHO.UTL    31                 SINI.  UTL     5                
           CERF.  SYM    24                 DEMON. SYM    12
           CIMGR. SYM    25                 DFECC. SYM     4
           MSCP.  SYM    27                 ILTU58.DIA     6
           TPATCH.UTL     7                 DIRECT.UTL     4
           EXECP6.INI    44                 TFUNCT.SYM    63
           STRTH2.COM     1                 ERROR. SYM    28
           SDI.   SYM    18                 MSCX.  SYM    22
           SERVER.SYM    16                 TTRASH.SYM     4
           RSPNDR.SYM    14                 DUP.   SYM    14

            25 Files, 493 Blocks
            21 Free blocks
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 7
   THE HSC50 VERSION Y2.00 KIT


        2.3.2  HSC50 UTILITY TAPE Y200 -



           ILTU58.DIA     6                 ILMEMY.DIA     4
           ILTCOM.DIA    19                 USRSQ2.DIA     1
           USRSQ3.DIA     1                 CHESS. UTL    27
           2NDTAP.VER     1                 VTDPY. UTL    11
           FORMAT.UTL    25                 VERIFY.UTL    25
           BACKUP.UTL    50                 RESTOR.UTL    39
           TUCOPY.UTL     6                 DKCOPY.UTL    17
           ILEXER.DIA    51                 ILDISK.DIA    27
           ILTAPE.DIA    40                 USRSQ4.DIA     1

            18 Files, 353 Blocks
            151 Free blocks




        2.3.3  HSC50 OFFLINE DIAGS Y200 -



           OFLLDR.HLP     4                 OFLMEM.SAV     6
           OFLOCP.SAV     4                 OFLSIZ.SAV     5
           OFLBIT.SAV    14                 OFLKPM.SAV     6
           OFLKTS.SAV     6                 OFLRFT.SAV     5
           OFLPIO.SAV    14                 OFLLDR.SAV    16

            10 Files, 80 Blocks
            428 Free blocks
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 8
   REVISION LEVELS


        3  REVISION LEVELS

        3.1  VAXcluster

        This version of the HSC50 subsystem provides a level of  functionality
        which  is  required for reliable operation in a VAXcluster which is at
        revision D1 or higher.

        The major components  of  version  D1  of  the  VAXcluster  and  their
        interdependencies  with the Version Y2.00 HSC50 subsytem are listed in
        the following sections.



        3.2  VAX/VMS

        The D1 version  of  VAXcluster  functionality  requires  that  VAX/VMS
        version V4.0 or later be installed.



        3.3  CI780 Microcode

        The  D1  version  of  VAXcluster  functionality  requires  that  CI780
        microcode version V3.0 or later be installed.



        3.4  HSC50

        The version of the HSC50 subsystem to be described  in  this  document
        consists of a number of components (hardware, microcode, firmware) and
        jointly comprise a product which is at revision C1 or higher.



        3.4.1  Firmware Version -

        When the HSC50 completes the initialization  process,  it  displays  a
        message  defining  the  version  of the firmware being loaded from the
        TU58 system tape cartridge:


               HSC50 Version Y200 17-Aug-1984 20:00:09    System nnnnnn


        The "nnnnnn"  field  which  follows  the  word  "System"  denotes  the
        subsystem  node  name.   The node name is either the default of HSCnn,
        where nn is the CI node number, or set by the SET NAME command.

        The version identifier "Y200" is also displayed  in  response  to  the
        "SHO  SYS"  command,  and  the same information is made known to a VMS
        host in a format that is limited to a four byte field.  In  the  event
        that  patch releases to the firmware are supplied by Digital Equipment
        Corporation, a step-by-step procedure will be provided.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                    Page 9
   REVISION LEVELS


        3.4.2  HSC50 Patches -

        The SYSTEM and UTILITY cassettes are treated as  a  single  entity  in
        this  procedure  and  both  must  be  mounted simultaneously and write
        enabled if either or both is to be updated.

        If the OFFLINE DIAGNOSTICS  cassette  is  to  be  patched,  the  HSC50
        subsystem must be initialized from the normal SYSTEM cassette with the
        OFFLINE  DIAGNOSTICS  cassette  mounted  and  write  enabled  in   the
        secondary drive.

        The patching process will:

           1.  Verify that the current version number of  the  TU58  cartridge
               (pair) in question is valid to receive the patch.

           2.  Update the contents of  the  cartridge  (pair),  including  the
               incrementation of the firmware version number from "Y200<n>" to
               "Y200<n+1>".

        If the current version is invalid, or if the  supplied  checksum  does
        not  match  the  changes,  the  patch  utility  exits leaving the TU58
        cartridge (pair) intact.



        3.5  Disk Drives

        This  section  discusses  the  revision  levels  of  Digital   Storage
        Architecture  (DSA) disk drives that are qualified to operate with the
        Y2.00 version of the HSC50 Mass Storage  Server  firmware,  and  hence
        with the D1 Version of the VAXcluster.

        If there is a requirement to attach a drive that has been in operation
        with  a  UDA50 controller (rather than a drive that is being installed
        jointly with an HSC50 Mass Storage Server), the  user  should  contact
        his field service representative before proceeding further.

        Confirmation of the current revision level of a  drive  model  may  be
        obtained by typing the command "SHOW DISKS" at the HSC50 console.  The
        model of drive will then be given  under  the  heading  "Model".   The
        levels  of  the  Microcode and Hardware version of each unit are under
        the heading "Version".  The Microcode level is shown  as  "MC- n"  and
        the Hardware level as "HV- n".

        If this procedure indicates that either or both of  the  Microcode  or
        Hardware  revision  levels does not meet the requirements stated below
        for the given drive type, the user should contact  his  field  service
        representative in order to determine the proper remedial action.



        3.5.1  RA60 Disk Drive -

        This  version  of  HSC50  subsystem  functionality  supports  and   is
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 10
   REVISION LEVELS


        supported  by  Microcode  version 3 or later and Hardware version 1 or
        later.

                               Note: VMS V4.0 operation

                If an RA60 disk  drive  containing  Microcode  earlier
                than  version 3 is attached to an HSC50 subsystem in a
                VAXcluster   running   VMS   V4.0    in    dual-ported
                configurations,  problems  will be encountered, and an
                excessive number of "SDI framing/pulse errors" will be
                reported.

                This is due to the fact that VMS V4.0  makes  periodic
                checks  on  dual-path access as a part of the strategy
                for fail-over.  The HSC50  supports  this  process  by
                transmitting  SDI-level  Topology commands, which were
                executed incorrectly by earlier versions of  the  RA60
                Microcode.

                As noted above, if it is determined that  RA60  drives
                do  not  meet this requirement the user should contact
                his field service representative.




        3.5.2  RA81 Disk Drive -

        This  version  of  HSC50  subsystem  functionality  supports  and   is
        supported  by  Microcode  version 6 or later and Hardware version 4 or
        later.



        3.5.3  RA80 Disk Drive -

        This  version  of  HSC50  subsystem  functionality  supports  and   is
        supported  by Microcode version 11 or later, and Hardware version 1 or
        later.



        3.6  Tape Formatters

        This  section  discusses  the  revision  levels  of  Digital   Storage
        Architecture  (DSA)  tape  formatters and drives that are qualified to
        operate with the Y2.00  version  of  the  HSC50  Mass  Storage  Server
        firmware, and hence with the D1 Version of the VAXcluster.

        Confirmation of the current revision level of a tape formatter may  be
        obtained by typing the command "SHOW TAPES" at the HSC50 console.  The
        drive type will then be given under the heading "Type".  The levels of
        the  Microcode and Hardware version of each formatter / drive pair are
        under the heading "Version".  The Drive Microcode level  is  shown  as
        "DMC- n"  and  the  Drive  Hardware  level  as "DHV- n"; the Formatter
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 11
   REVISION LEVELS


        Microcode level is shown as "FMC- n" and the Formatter Hardware  level
        as "FHV- n".



        3.6.1  TA78 Tape Formatter -

        This  version  of  HSC50  subsystem  functionality  supports  and   is
        supported  by  Drive  Microcode version 0 or later, and Drive Hardware
        version 0 or later, and by Formatter Microcode version 2 or later, and
        Formatter Hardware version 1 or later.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 12
   Y2.00 ENHANCEMENTS


        4  Y2.00 ENHANCEMENTS

        This section deals with enhancements and  general  changes  that  have
        been  introduced  over  and  above the level of functionality that was
        present in version V1.10.



        4.1  User Interface

        4.2  Host Interface

        4.2.1  Error-logging -

        Additional code to support the logging of  various  levels  of  errors
        over Virtual Circuits between the HSC50 and host Port Drivers has been
        implemented in this Version of HSC50 functionality; these are referred
        to  as  "Out-of-band  Errors".   This  differs from previous versions,
        which logged errors only over a Connection between  HSC50  server  and
        host class driver, and was thus confined to those "Inband" errors that
        were encountered in the course of performing host-requested I/O.



        4.2.2  "VC Closed" Messages -

        The "VC Closed" error  message  has  been  enhanced  to  differentiate
        between   various  reasons  for  Virtual  Circuit  closure  so  as  to
        facilitate the support of clusters and to improve error analysis.  The
        revised messages define the following events:

            o  Closures caused by the HSC50 CI port (K.ci)

            o  Closures caused by disconnect timeout

            o  Closures caused by an unexpected disconnect request

            o  Closures caused by receipt of a START command from the host




        4.3  Disk Firmware

        4.3.1  Bad Block Replacement -



        4.3.1.1  Controller-Initiated Replacement -

        In this version of the HSC50 firmware, Controller-Initiated bad  block
        replacement   is   fully   operational.    Host-Initiated   bad  block
        replacement is no longer utilized.

        This eliminates the possibility of  loss  of  data  integrity  when  a
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 13
   Y2.00 ENHANCEMENTS


        volume  mounted for multi-host access under VMS V4.0 or later requires
        that logical blocks be replaced, with concurrent accesses to the RCT.



        4.3.1.2  Error Messages -

        The introduction of Controller-Initiated bad block replacement has led
        to  the introduction of several new error messages which relate to the
        new functionality.  A list of these new messages is shown below.

           ERROR-W Bad Block Replacement (Block OK) 

           ERROR-E Bad Block Replacement (Drive Inoperative)

           ERROR-E Bad Block Replacement (RCT Inconsistent) 

           ERROR-E Bad Block Replacement (REPLACE Failure)

           ERROR-W Bad Block Replacement (Success) 



        4.3.2  DISK ONLINE Command -

        As the result of a change to the specification of  the  Standard  Disk
        Interconnect (SDI) the HSC50 (in common with other DSA controllers and
        servers) is now required to wait for a period of approximately two (2)
        seconds  between  receiving  and issuing an ONLINE command to a drive.
        The user should be aware that ONLINE commands will now demonstrate  an
        appreciable delay before taking effect.



        4.4  Magnetic Tape Firmware

        4.4.1  Tape Server -

        This version of the HSC50 subsystem firmware  supports  Magnetic  Tape
        I/O.  The full complement of TMSCP commands are supported.
        This in turn implies the following levels of functionality:

            o  Multiple host connections may be made to the tape MSCP server;

            o  Multiple outstanding requests are possible per tape drive;

            o  Drives are capable of being made dynamically (un)available;

            o  All errors are handled and logged to the hosts;

            o  CONNECT / DISCONNECT functionality is fully  implemented,  with
               automatic release of acquired units on DISCONNECT;
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 14
   Y2.00 ENHANCEMENTS


            o  Hosts have control of tape density and speed;

            o  Records may be  transferred  up  to  a  maximum  length  of  64
               Kilobytes;

            o  Software and Hardware Write Protect are supported;

            o  There is full diagnostic support,  including  exclusive  access
               for diagnostics.

            o  Optimized  rewind  handling  is  operational,  which   includes
               asynchronous  REWIND  completion  --  the IMMEDIATE modifier is
               supported.




        4.4.1.1  Error Messages -

        The introduction of Magnetic Tape support has led to the  introduction
        of  related  error  messages.   The messages fall into two categories:
        those which involve Magnetic Tape I/O over an  established  Connection
        to  a  Host Class Driver (the Inband Messages); those which arise from
        non-Host activity (the Out-of-band Messages).



        4.5  Diagnostics

        4.5.1  ILTAPE -



        4.5.1.1  Canned Sequence -

        ILTAPE is supported in this version of the HSC50 subsystem.

        (The following note is included for the benefit of  field  test  sites
        which  had  experience  with  an early version of this diagnostic test
        program).

        The current version includes the following new features for the canned
        sequence:

            o  A timer is implemented;

            o  Either or both densities may be selected at the user's option;

            o  For compares a distinction is made  between  read  and  compare
               errors.

        The canned sequence uses a record size of 512  bytes  in  writing  the
        first  200  feet  of tape; random record sizes are used in writing the
        next 50 feet.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 15
   Y2.00 ENHANCEMENTS


        Note that the total  run  time  for  the  canned  sequence  when  BOTH
        densities are selected is approximately 15 minutes.



        4.6  Utilities

        4.6.1  Backup Utility (BACKUP) -

        The Disk to Tape Backup Utility is  operational  in  this  version  of
        HSC50 firmware, in conjunction with the Restore Utility.

        The joint use of Backup and Restore is  subject  to  the  restrictions
        stated  in section 6.6.1, which should first be read before making use
        of these facilities.

        The Backup program is located on the UTILITY tape and  is  invoked  by
        typing CTRL/Y followed by RUN DD1:BACKUP.



        4.6.1.1  Backup - General Information -

        As an indication of the levels of performance that  may  be  achieved,
        the following typical figures have been observed during testing.  With
        2400 foot reels of tape pre-mounted,  and  with  the  TA78  set  to  a
        density  of  6250 bpi,  the  approximate time to perform a full Backup
        operation for a given model of disk drive is indicated below.


                              Disk     Tape      Time 
                              Drive    Reels      in
                              Model    Reqd.    Minutes
                              -----    -----    -------
                              RA80       1        < 4
                              RA60       2        < 6
                              RA81       4        <15



        4.6.2  Restore Utility (RESTOR) -

        The Tape to Disk Restore Utility is operational  in  this  version  of
        HSC50  firmware,  in conjunction with the Backup Utility.  Their joint
        use is subject to the restrictions  stated  in  section  6.6.1,  which
        should first be read before making use of these facilities.

        This program is located on the UTILITY tape and is invoked  by  typing
        CTRL/Y followed by RUN DD1:RESTOR.  The user should refer to the HSC50
        Utilities User Documentation manual (EK-UHSC5-UG) to  obtain  detailed
        information on the use of this program.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 16
   Y2.00 ENHANCEMENTS


        4.6.3  SET / SHOW Utility (SETSHO) -



        4.6.3.1  SET ALLOCATE -

        The SET ALLOCATE command has been extended to cover the  tape  server.
        As  with  the  disk  server,  this  command  is intended to be used in
        conjunction with VAX/VMS V4.0 functionality.  The  revised  syntax  of
        this command is:

                                             { DIS[K]  n }
                            SET  ALL[OCATE] {            }
                                             { TAP[E]  n }

        where 'n' is a decimal number in the inclusive range 0 through 255.

        The default value of  'n'  for  both  'SET  ALLOCATE  DISK'  and  'SET
        ALLOCATE TAPE' on the Y2.00 system cassette is '0'.



        4.6.3.2  SET MAXFORMATTERS -

        This version of the SETSHO  utility  includes  a  'SET  MAXFORMATTERS'
        command.  The default value is 24.  The syntax is:

                               SET  MAX_F[ORMATTERS] f 

        where 'f' is a decimal number in the inclusive range 1 through 24.

        The effect  is  to  preallocate  only  as  many  Private  Memory  data
        structures  as are defined by the value of 'f', the next time that the
        HSC50 is reinitialized following the use of this command.

        The user should set the  value  of  'f'  to  conform  to  a  realistic
        expectation  of  the  number  of  magnetic  tape formatters within the
        configuration, in order to avoid memory resource allocation problems.



        4.6.3.3  SET MAX_TAPE -

        This version of the SETSHO utility includes a 'SET MAX_TAPES' command.
        The default value is 96.  The syntax is:

                                 SET  MAX_T[APES] t 

        where 't' is a decimal number in the inclusive range 1 through 96.

        The effect  is  to  preallocate  only  as  many  Private  Memory  data
        structures  as are defined by the value of 't', the next time that the
        HSC50 is reinitialized following the use of this command.

        The user should set the  value  of  't'  to  conform  to  a  realistic
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 17
   Y2.00 ENHANCEMENTS


        expectation   of  the  number  of  magnetic  tape  drives  within  the
        configuration, in order to avoid memory resource allocation problems.



        4.6.3.4  SET START -

        This version of the SETSHO utility includes  a  'SET  START  DISABLED'
        (ENABLED) command.  The effect of this command is that when 'START' is
        enabled a special text file (STRTH2.COM) is read from the TU58  system
        cassette  whenever the HSC50 susbsystem is initialized.  This contents
        of this file are intended to be utilized in  conjunction  with  future
        functionality in setting the values of certain subsystem parameters.

        The  default  value  of  'START'  on  the  Y2.00  system  cassette  is
        'ENABLED'.

        (See also section 6.6.3.9).



        4.6.4  TU58 Directory Utility (DIRECT) -

        If analysis of the TU58 directory shows that the  directory  structure
        is invalid, DIRECT prints the message

            DIRECT-F Corrupted HSC directory structure
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 18
   V1.10 RESTRICTIONS NOW LIFTED IN Y2.00


        5  V1.10 RESTRICTIONS NOW LIFTED IN Y2.00

        This section deals with restrictions that were present in V1.10, which
        have been removed or radically changed in version Y2.00.



        5.1  Initialization Problems

        [No differences]



        5.2  User Interface Problems

        5.2.1  WRITE PROTECT Light -

        A problem has been noted when a drive was both hardware  and  software
        write  protected.   If  the  WRITE  PROTECT switch was popped out, the
        light would go out and remain unlit, although the drive would in  fact
        stay   software  write  protected.   The  light  would  thus  indicate
        (incorrectly) that the drive was NOT write  protected.   This  problem
        has now been fixed.



        5.3  Disk Firmware Problems

        5.3.1  Drives Mounted /FOREIGN -

        A problem has existed when disk drives  were  mounted  /FOREIGN  under
        VAX/VMS  by  more  than  one host.  The problem occurred in situations
        where   one   host   was   performing   I/O    to    drives    mounted
        /FOR /DATA=(READ,WRITE),  and  another  host  had  the  drives mounted
        /FOREIGN but was not performing any I/O.

        If the HSC50 were now to be reinitialized for any reason, it would  be
        Host  Cleared  and  initialized  a  second time by the "inactive" host
        immediately after coming back on line.   This  problem  has  now  been
        fixed.



        5.3.2  Duplicate Units -

        A problem has arisen in connection with  the  handling  of  "duplicate
        unit  number"  situations.   The  symptom  was  that  when  the  HSC50
        recognized that a drive had made itself  available  with  a  duplicate
        unit number, the "original" unit with the same number was removed from
        the list of online units in violation of the MSCP specification.

        The problem was compounded  by  the  fact  that  the  subsystem  would
        thereafter continue to retain control of the drive, preventing further
        access by any host; the only way  to  resolve  the  situation  was  to
        "remove" the original drive by popping its port buttons.  This problem
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 19
   V1.10 RESTRICTIONS NOW LIFTED IN Y2.00


        has now been fixed.



        5.3.3  Duplicate Unit Number 0 -

        When  a  SET  CONTROLLER  CHARACTERISTICS  command  was  issued  to  a
        subsystem to which a drive was attached having a duplicate unit number
        equal to zero (0), then the operation would fail.   This  problem  has
        now been fixed.



        5.3.4  Error Recovery - Bad Headers -

        Various problems have existed with previous versions  when  the  error
        recovery  code had to deal with blocks with bad headers, either within
        the host addressable space (LBNs) or the Relocation and Caching  Table
        (RCT).   The symptoms usually appeared as subsystem deadlocks, leading
        to a host-clear reinitialization of  the  subsystem.   These  problems
        have now been fixed.



        5.3.5  DISK ONLINE Command -



        5.3.5.1  Drive Error -

        In previous versions a problem existed in which the disk code reported
        a  'media  format  error'  with  an undefined subcode if a drive error
        occured during an ONLINE command.   This  resulted  in  ambiguous  VMS
        mount failure messages.  In addition, the drive did not spin-down, nor
        was it flagged  as  'unit  offline'  under  circumstances  where  such
        actions would be proper.

        For these reasons, a VMS error message of  "mount  failure"  with  the
        reason  given  as "media format error" was previously considered to be
        ambiguous.  This problem has been fixed, and VMS error messages having
        to  do  with  "mount  failure"  should  NO  LONGER be considered to be
        potentially ambiguous.



        5.3.5.2  Reading FCT Or RCT -

        Problems have been encountered when the  Disk  Server  was  reading  a
        Format Control Table (FCT) or Relocation and Caching Table (RCT) block
        while performing an ONLINE command.  These  problems  would  typically
        cause a subsystem hang, leading to a Host Clear Initialization.  These
        problems have now been fixed.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 20
   V1.10 RESTRICTIONS NOW LIFTED IN Y2.00


        5.3.5.3  Unrecoverable Error -

        Various problems have been encountered  when  an  unrecoverable  error
        occurred  during an ONLINE command.  One problem was that a failure to
        read the Format Control Table (FCT) did not return the  proper  status
        codes;  another  was  that the drive did not spin down when the status
        was media format or drive error.  Both of these problems have now been
        fixed.



        5.4  Diagnostic Problems

        5.4.1  ILEXER -



        5.4.1.1  Unit Numbers -

        A  problem  existed  with  previous  versions  in  which  the   ILEXER
        diagnostic  program  had  a  problem which prevented correct operation
        when matching disk and tape drive unit numbers were called out.   This
        problem has now been fixed.



        5.4.2  Periodic Tests (K.sdi) -

        Because of a problem within  an  earlier  version  of  the  disk  data
        channel  (K.sdi)  diagnostic microcode, previous versions of the HSC50
        firmware have deliberately avoided  running  K.sdi  periodic  test  2.
        This situation has now been rectified, based on a conditional check of
        the K.sdi microcode version number.



        5.5  Utility Problems

        5.5.1  FORMAT Utility -

        If CTRL/Y was issued at a console while running FORMAT,  the  terminal
        could  enter  a state where it would not honor any characters typed at
        the keyboard, although the FORMAT utility would continue to run.  This
        problem has now been fixed.



        5.5.2  VERIFY Utility -



        5.5.2.1  EDC Errors -

        The VERIFY utility has experienced a problem in handling blocks within
        the  Replacement  Block  (RBN)  space which contained hard EDC errors.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 21
   V1.10 RESTRICTIONS NOW LIFTED IN Y2.00


        When such a block was encountered it would cause  an  extra  incorrect
        error message to be printed as follows:

                     VERIFY-I-RBN n. has solid errors: ... <etc>

        This problem has now been fixed.



        5.5.2.2  Incorrect Error Message -

        A message printed by the VERIFY utility  following  the  scan  of  DBN
        space  stated  erroneously  "initial  write  should  be  specified for
        INLMDE",  whereas  the  reference  should  have  been  to  the  ILEXER
        diagnostic program.  This problem has now been fixed.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 22
   Y2.00 RESTRICTIONS


        6  Y2.00 RESTRICTIONS

        6.1  User Interface Restrictions

        6.1.1  Operator Control Panel (OCP) -

        There are two peculiarities of the ONLINE button of the HSC panel:

            1.  It's function is not affected by the SECURE/ENABLE switch.

            2.  Popping the button out does not affect VC's that  are  already
                established




        6.1.2  Console Terminal -



        6.1.2.1  Control Sequences -

        When running an inline diagnostic where  a  broken  drive  produces  a
        continuous  stream  of  errors,  it  is  recommended that the drive be
        powered down to terminate the diagnostic.  Control characters from the
        console  may  not be processed and a crash of the subsystem may result
        if the condition is not cleared.



        6.1.2.2  Console Problems -

        If the HSC console is connected, and it runs out of  paper,  a  CTRL/S
        sent  to the HSC50 by the terminal will eventually crash the subsystem
        from running if enough output is queued up.  Likewise, if  the  HSC50>
        prompt  is left for the 5 minute timeout period, a backlogged burst of
        console messages due to some errors can cause the same problem.

        These problems can be avoided by disabling CNTL-S  in  terminal  setup
        and by not leaving the console waiting on input.

        In addition to the problems sited above, messages from the HSC  loader
        ignore X-on/X-off.  The only side-effect is unexpected messages.



        6.1.3  Diagnostic And Utilities Protocol (DUP) -

        DUP protocol is not supported by this version of the HSC50 firmware.



        6.2  Host Interface Restrictions
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 23
   Y2.00 RESTRICTIONS


        6.2.1  Heavy Virtual Circuit Activity -

        There is a possibility that the subsystem may crash  under  conditions
        of heavy virtual circuit activity from more than one host.  If a crash
        occurs and the active process (as shown on the crash dump)  is  "HOST"
        or "POLLER", the user should take actions as noted in section 3.3.3 of
        the HSC50 User  Guide  to  preserve  this  information,  and  make  it
        available to the field service representative.



        6.3  Disk Firmware Restrictions

        6.3.1  Disk Volume Shadowing -

        Disk Volume Shadowing is  not  supported  in  this  version  of  HSC50
        firmware.



        6.3.2  Disk Drive State Transitions -

        Some minor quirks in  HSC50  behavior  are  evident,  particularly  in
        multi-host  situations  and  in the presence of heavy I/O loads if the
        state of a disk drive connected to an HSC50 is altered.   In  general,
        these  incidents  are  reduced  considerably as compared with previous
        versions.

        If the following general rule is observed, the user can avoid all such
        problems.



                                     GENERAL RULE

                  Any manipulation of the drive (such as spin-up  or
                  spin-down,  changing  unit  plugs  or SDI cabling)
                  should be preceded by disabling the port switches.
                  This  eliminates  transient  error  conditions and
                  minimizes the impact on the functioning subsystem.




        6.3.3  General Manipulation Of Panel Switches -

        Under excessively heavy I/O loads, there may be  a  perceptible  delay
        between  actuation  of a drive panel switch and the observed response.
        This is because the HSC50 defers its response  until  I/O  rundown  of
        previously  submitted  requests  for  that unit is complete.  When I/O
        rundown is finished, the HSC50 again samples the state of the  drive's
        panel switches and responds accordingly.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 24
   Y2.00 RESTRICTIONS


        6.3.4  Manipulation Of SDI Cables -

        The user should first  ensure  that  the  drive's  port  switches  are
        disabled   to   the  relevant  controller(s)  when  an  SDI  cable  is
        manipulated.  After any illuminated port lights are  extinguished,  it
        is safe to change the SDI cable.

        If the port switches are NOT disabled, the HSC50 may  report  spurious
        drive error messages as a result of the cable manipulation.



        6.3.5  Manipulation Of Unit Plugs -

        After any illuminated port lights are  extinguished,  it  is  safe  to
        change  the  unit  plug.   When  the  unit  plug  of  a  disk drive is
        manipulated, the user  should  first  ensure  that  the  drive's  port
        switches are disabled to the relevant controller(s).



        6.3.6  Spin-up Of AVAILABLE Disk Drives -

        After any illuminated port lights are  extinguished,  it  is  safe  to
        alter  the  drive RUN switch.  The drive's port switches may safely be
        re-enabled as soon as the RUN light  is  illuminated.   When  manually
        spinning up an AVAILABLE disk drive, the user should first ensure that
        the drive's port switches are disabled to the relevant controller(s).

        If the port switches are NOT disabled, the HSC50 may  report  spurious
        drive error messages during the spin-up operation, except for RA60's.



        6.4  Magnetic Tape Firmware Restrictions

        6.4.1  Error Logs -

        In general, the user should be aware that it is normal  for  the  tape
        server to log errors with much greater frequency than the disk server.
        This is compounded by  the  fact  that  the  tape  server  has  little
        visibility  into  the  context  of  "Tape Drive Requested Error Logs".
        Consequently  they  are  ALL  logged  as   ERROR,   rather   than   as
        INFORMATIONAL   or   WARNING.    Errors  may  be  reduced  greatly  by
        periodically cleaning the tapes as well as the drives.



        6.4.2  Features Not Supported -

        The following features are NOT fully supported by this version of  the
        HSC50 subsystem:
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 25
   Y2.00 RESTRICTIONS


         o  Resource Management:  if resource starvation occurs because of  an
            abnormally  high  level of host demands for magnetic tape I/O, the
            tape server may block, leading to a host-clear reinitialization.

            It must be  emphasised  that  this  condition  occurs  only  under
            extreme  conditions,  and  is highly unlikely to take place during
            normal operations.

         o  Time-out of Rewind  completions:   if  a  formatter  continues  to
            report that a tape drive is rewinding, then the subsystem may wait
            indefinitely for the completion of that rewind.




        6.4.3  Number Of Tape Drives Supported -

        The current maxmimum tape configuration that is supported is four tape
        drives,  two  masters  and  two  slaves.   The  connectability  of the
        subsystem allows for ninety-six drives, but  configurations  exceeding
        four drives is as yet untested.



        6.4.4  Tape Drive State Transitions -

        The user should be aware that the general rule given for  disk  drives
        in  section  6.3.2 applies also to tape drives:  all manual operations
        to ONLINE tape drives should be preceeded by popping the port buttons.

        This version of tape firmware imposes an additional  restriction.   If
        the  ONLINE  button  is accessed while a drive is operational the tape
        firmware may be unable to recover gracefully from the resulting  state
        transition.



        6.4.5  Duplicate Tape Units -

                                         NOTE

                  The cluster will CRASH if duplicate tape units are
                  detected  by  an  HSC  for  VMS version V4.0.  The
                  problem is corrected in V4.1.




        6.5  Diagnostics Restrictions
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 26
   Y2.00 RESTRICTIONS


        6.5.1  General Restrictions -



        6.5.1.1  Dual-ported Drives -

        In configurations where disk or tape drives are dual-ported, the  user
        should  NOT  attempt to invoke ILDISK or ILTAPE concurrently from more
        than one HSC50 subsystem to the same target drive.

        Failure to observe this restriction may lead  to  one  or  both  HSC50
        subsystems being host-clear reinitialized.



        6.5.1.2  Inoperative Drives -

        Because the ILDISK and ILTAPE diagnostic programs  are  not  performed
        automatically   (see   sections  6.5.2,  6.5.3)  some  "endless  loop"
        situations may arise, until the user or operator performs  an  act  of
        manual intervention.

        One example is that of the host operating system attempting to MOUNT a
        removable disk drive which does not contain a loaded pack.

        When  the  HSC50  determines  that  the  drive  failed  to   spin   up
        successfully  no  diagnostic  analysis  is  undertaken:   the drive is
        simply marked as "Inoperative".  After a time-out interval  the  drive
        will re-assert itself as "AVAILABLE"; the host system will then repeat
        the cycle by  re-issuing  the  ONLINE  command.   This  sequence  will
        terminate  only  when  one of two events occurs:  the host system user
        exits with CTRL/Y, or the MOUNT finally completes  when  the  operator
        opens the drive and loads the disk pack.



        6.5.1.3  Periodic Diagnostics -

        In this version of HSC50 firmware periodic diagnostics are NOT invoked
        for  Tape Data Channel (K.sti) modules.  ILTAPE can be run to diagnose
        a K.sti.



        6.5.1.4  User Syntax -

        The diagnostic progams ILDISK, ILEXER, and ILTAPE will each  accept  a
        list  of  valid arguments, separated by commas.  If, however, the user
        responds to a prompt for a drive unit number by attempting to  pass  a
        list of device numbers, the diagnostic program will first respond with
        the message:  "Invalid Parameter" and then continue.  The user  should
        realize  that  under  these  circumstances the program accepted and is
        acting upon the first device number in the multiple list.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 27
   Y2.00 RESTRICTIONS


        6.5.2  ILDISK -



        6.5.2.1  Initiation -

        The initiation of the  ILDISK  diagnostic  program  is  NOT  performed
        automatically.



        6.5.2.2  Unknown Disks -

        In this version of HSC50  firmware  the  ILDISK  diagnostic  does  not
        handle  the  case  where  a disk drive is in the "Undefined" state, as
        determined by the use of the SHOW DISK command.



        6.5.2.3  One Disk Drive; Two HSC's -

        ILDISK can cause a crash if requestor/port access is used to one drive
        through two HSC's.  Avoiding this use of ILDISK is recommended.



        6.5.3  ILTAPE -



        6.5.3.1  Initiation -

        The initiation of the  ILTAPE  diagnostic  program  is  NOT  performed
        automatically.



        6.5.3.2  Read Reverse -

        The reverse read option of ILTAPE does not work.



        6.5.4  ILEXER -

        The "compare always" option should not be used in order to  avoid  "SI
        command  timeouts".   If  the  option is used, transfer size should be
        restricted to 4 blocks or less.



        6.6  Utilities Restrictions

        The following set of restrictions apply to the Y2.00  version  of  the
        HSC50 utility programs.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 28
   Y2.00 RESTRICTIONS


        6.6.1  Backup Utility (BACKUP) -



        6.6.1.1  Drives Already In Use -

        If a tape drive is online and is performing  a  long  operation  (e.g.
        ERASE),  and  that  same  unit number is specified for use in a Backup
        operation, it may take several minutes  before  the  program  declares
        that the unit is already in use.



        6.6.1.2  Tape Format -

        In section 4.6.1 it was stated that the Disk to Tape Backup Utility is
        operational in this version of HSC50 firmware, in conjunction with the
        Restore Utility.

        Existing BACKUP tapes that have been written with earlier versions  of
        HSC50  firmware  (including  the  present  release)  may  no longer be
        capable of being restored to disk using the new version of the Restore
        Utility.

        The user should not, therefore, archive BACKUP tapes  that  have  been
        written  with  the  current version, and have a critical dependence on
        their being restorable following the installation of  future  releases
        of HSC50 firmware.



        6.6.2  Restore Utility (RESTOR) -



        6.6.2.1  Drives Already In Use -

        If a tape drive is online and is performing  a  long  operation  (e.g.
        ERASE),  and  that  same unit number is specified for use in a Restore
        operation, it may take several minutes  before  the  program  declares
        that the unit is already in use.



        6.6.2.2  Tape Format -

        Existing BACKUP tapes that have been written with earlier versions  of
        HSC50  firmware  may  no  longer  be capable of being restored to disk
        using the new version of the Restore Utility.



        6.6.3  Set / Show Utility (SETSHO) -
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 29
   Y2.00 RESTRICTIONS


        6.6.3.1  SET CI -

        As a SET operation, this command  performs  correctly.   However,  the
        statistics  produced by the command are those which relate to the last
        node for which the command was issued, rather than for  the  specified
        node.   If  the  command had not previously been issued since the last
        subsystem initialization, then the statistics are summarized  for  ALL
        nodes.



        6.6.3.2  SET/SHOW CONTROL_BLOCKS -

        This command (and the associated SHOW command)  is  described  in  the
        HSC50 User Guide and the HSC50 Utilities User Documentation.  However,
        the command has no effect.

        SHOW POOL gives the proper information on free control memory  blocks,
        short lifetime control memory blocks, and buffers.

        (See also section 6.6.3.8).



        6.6.3.3  SET DUMP -

        The TU58 dump option is not supported.



        6.6.3.4  SET HOST -

        A problem exists with the 'SET HOST' command when a disk drive is spun
        up and down manually.

        If Dnnn is a disk drive which has been spun down, then typing SET Dnnn
        NOHOST  works  correctly.   This may be confirmed by typing SHOW DISK,
        which indicates that the disk in question is AVAILABLE-NOHOST ACCESS.

        However, if the disk is now spun up manually and the SHOW DISK command
        is typed once more, the drive is shown to be AVAILABLE-HOST ACCESS.

        Care should therefore be exercised in using the command.  If  a  drive
        is  to  be  isolated from host access across spin-up or spin-down, the
        desired effect should be achieved and confirmed with the judicious use
        of SET HOST and SHOW DISK commands.



        6.6.3.5  SET MAX_FORMATTER -

        No error message is printed if this command specifies a  number  which
        lies  outside  the  permitted range; however, The proper action of not
        changing the value is taken.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 30
   Y2.00 RESTRICTIONS


        Care should therefore be exercised  in  using  the  command,  and  the
        effect  should  be  noted by following it up with the appropriate SHOW
        command.



        6.6.3.6  SET MAX_TAPE -

        No action is taken if this  command  specifies  a  number  which  lies
        outside  the  permitted  range.   In  other words, no error message is
        printed, nor is the referenced value changed.

        Care should therefore be exercised  in  using  the  command,  and  the
        effect  should  be  noted by following it up with the appropriate SHOW
        command.



        6.6.3.7  SET REQUESTOR, SHOW REQUESTOR -

        SET REQUESTOR is not supported.

        A  documentation  problem  exists  with  respect  to  these  commands.
        According to the HSC50 User Guide Revision 2 (EK-HSC50-UG-002) and the
        HSC50 Utilities User Documentation (EK-UHSC5-UG), permitted  requestor
        numbers are in the range 2 through 9.

        In this version of  the  HSC50  firmware  the  SHOW  command  provides
        information  on  requestors  0  through 9, and the SET command permits
        numbers to be used in the range 1 through 9.  (Note that  requestor  0
        is the P.ioc, and 1 is the K.ci module).

        These features are intended to provide  latent  software  support  for
        future  hardware  functionality,  although  the  legal  range for data
        channels in this version of the subsystem is 2 through 7.

        The user should restrict the use of the SET REQUESTOR command  to  the
        range  2  through  7,  unless  directed otherwise by the field service
        representative.



        6.6.3.8  SET/SHOW SHORT_LIFETIME_CONTROL_BLOCKS -

        This command (and the associated SHOW command)  is  described  in  the
        HSC50 User Guide and the HSC50 Utilities User Documentation.  However,
        the command has no effect.

        SHOW POOL gives the proper information on free control memory  blocks,
        short lifetime control memory blocks, and buffers.

        (See also section 6.6.3.2).
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 31
   Y2.00 RESTRICTIONS


        6.6.3.9  SET START -

        This version of the SETSHO utility includes a 'SET START'  command  as
        discussed  in  section 5.6.3.2.  However, the 'START' parameter should
        NOT be enabled  by  the  user:   improper  use  may  have  undesirable
        consequences.



        6.6.3.10  SET WCS -

        This version of the SETSHO  utility  includes  a  'SET  WCS'  command.
        However, the command has no effect and it should not be invoked.



        6.6.4  TUCOPY -

        There is no limit to the number of error retries for TUCOPY.



        6.6.5  PURGE -

        Although the file name may still be added to the end of this  command,
        it is ignored.  All files are always purged.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 32
   V2.00 KNOWN ERRORS


        7  V2.00 KNOWN ERRORS


        1.  "NOHOST ACCESS" gets lost whenver a drive goes unavailable.

        2.  Host memory/VC errors can cause TAPE crashes.  (Low probability)

        3.  Periodic diagnositics are not run on K.sti's.

        4.  CTRL-Y during boot can cause boot failure.

        5.  The LOADER ignores console X-off.

        6.  Errant LBN information from a drive to a status command can  cause
            crash.

        7.  Aborting a MOUNT to a malfunctioning disk drive can cause  a  Host
            clear of the HSC.

        8.  Incomplete cleanup of a connection can cause a subsequent MOUNT to
            lead  to  a  Host  clear  of  the  HSC.   This condition can occur
            whenever a VC break occurs during an  operation  such  as  a  long
            ERASE.

        9.  Large diagnostic transfers with large  host  transfers  can  crash
            K.tape.

       10.  Tape transfers are not timed-out,  leading  to  undetected  K.tape
            hangs.

       11.  Tape rewinds are not timed-out.

       12.  Running ILDISK from two controllers at once leads to HSC crashes.

       13.  Compare errors are not logged or reported to  the  host.   Instead
            they appear as controller errors.

       14.  Excessive tape workloads may lead to crashes or Host clears of the
            HSC.

       15.  "Compare Always" option of ILEXER causes SI timeouts.

       16.  ILTAPE reverse reads do not work.

       17.  VC breaks can lead to HSC crashes.
   HSC50 Y2.00 Release Notes 26 October 84, 13:51:08                   Page 33
   Y2.00 KNOWN ERRORS


        8  Y2.00 KNOWN ERRORS


        1.  Incomplete messages for VC closures are sometimes printed.

        2.  If CNTRL-Y is hit during the TU58 wheelspin, the loopback  bit  is
            left  on,  producing  a  201  status condition that is not cleared
            until the next wheelspin (once  every  2  hours).   The  condition
            prohibits any program loads from the TU58 tape.

        3.  ILTAPE and ILTCOM can crash if drive online button is  popped  out
            then in.

        4.  VC breaks can lead to a host being unable to reestablish a VC with
            the HSC.

        5.  "SET Dn (NO)HOST ACCESS" can cause an HSC crash.

        6.  DAP command to drive with a state interrupt pending/processing can
            cause an HSC crash.

        7.  "Compare Always" option of ILEXER will hang HSC console.
[End of HSC-INFO.MEMOS]