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]