Trailing-Edge
-
PDP-10 Archives
-
bb-m836d-bm
-
tools/rmtcon/rmtcnd.txt
There are 4 other files named rmtcnd.txt in the archive. Click here to see a list.
Date: 27 May 88 12:37:09
Charge Number:V20-05113
Revision "0.2" of
Diagnostic Engineering Functional Specification for
NI Services Program
RMTCON
Revisions:
Rev 0.1 26-Sep-83 By John R. Kirchoff
Rev 0.2 17-Oct-84 By Gary Papazian
Overview of the Diagnostic Product Page ii
Table of Contents 27 May 88
Table of Contents
Page
----
1.0 OVERVIEW OF DIAGNOSTIC PRODUCT . . . . . . . . . . . 1
1.1 Scope of this document . . . . . . . . . . . . . . 1
1.2 General program description . . . . . . . . . . . 1
1.3 Users and Uses . . . . . . . . . . . . . . . . . . 1
1.4 Pre-requisite software . . . . . . . . . . . . . . 1
2.0 PRODUCT GOALS/NON-GOALS . . . . . . . . . . . . . . 2
2.1 Performance goals . . . . . . . . . . . . . . . . 2
2.1.1 Program size . . . . . . . . . . . . . . . . . . 2
2.1.2 Program run time . . . . . . . . . . . . . . . . 2
2.1.3 Exec mode capability . . . . . . . . . . . . . . 2
2.1.4 User mode capability . . . . . . . . . . . . . . 2
2.1.5 Fault Detection . . . . . . . . . . . . . . . . 2
2.1.6 Fault isolation . . . . . . . . . . . . . . . . 2
2.1.7 General user interface philosophy . . . . . . . 3
2.1.8 Program documentation . . . . . . . . . . . . . 3
2.2 Compatibility goals . . . . . . . . . . . . . . . 3
2.2.1 CPU family . . . . . . . . . . . . . . . . . . . 3
2.2.2 Standard diagnostic support software . . . . . . 3
2.2.3 Operating systems (TOPS-10) . . . . . . . . . . 3
2.2.4 Operating systems (TOPS-20) . . . . . . . . . . 4
2.2.5 Spear . . . . . . . . . . . . . . . . . . . . . 4
2.3 Failsoft goals . . . . . . . . . . . . . . . . . . 4
2.3.1 CPU/Memory failures . . . . . . . . . . . . . . 4
2.3.2 Power fail/restart . . . . . . . . . . . . . . . 4
2.4 Restrictions . . . . . . . . . . . . . . . . . . . 4
2.4.1 User mode privileges . . . . . . . . . . . . . . 4
2.4.2 User mode priority interrupts . . . . . . . . . 4
2.5 Non-Goals . . . . . . . . . . . . . . . . . . . . 5
3.0 REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 6
3.1 Run time requirements . . . . . . . . . . . . . . 6
3.2 Development environment requirements . . . . . . . 6
3.3 Evaluation system . . . . . . . . . . . . . . . . 6
4.0 PROGRAM INTERFACES . . . . . . . . . . . . . . . . . 7
4.1 Diagnostic software interfaces . . . . . . . . . . 7
4.2 Operating system interfaces (TOPS-10) . . . . . . 7
4.3 Operating system interfaces (TOPS-20) . . . . . . 7
5.0 COMMANDS . . . . . . . . . . . . . . . . . . . . . . 8
6.0 FUNCTIONAL DESCRIPTION . . . . . . . . . . . . . . 10
6.1 Relationship To Other Components . . . . . . . . 10
6.2 NI Services Program . . . . . . . . . . . . . . 11
6.3 PLUTO Console Carrier Server . . . . . . . . . . 12
Overview of the Diagnostic Product Page iii
Table of Contents 27 May 88
6.4 Console Carrier Protocol . . . . . . . . . . . . 12
6.4.1 Message Flow Within The CC Protocol . . . . . 13
6.4.2 Characteristics And Uses Of The Protocol . . . 14
6.5 Remote Console Reservation . . . . . . . . . . . 16
6.5.1 Reservation States . . . . . . . . . . . . . . 16
6.5.2 Reservation Details . . . . . . . . . . . . . 17
6.5.3 Console Carrier exists - but console in use . 18
6.5.4 Console Carrier exists - Console not reserved 18
6.5.5 Console Carrier exists - we own the console . 19
6.5.6 Console Carrier code does not exist . . . . . 20
6.6 Remote Console Operation . . . . . . . . . . . . 23
7.0 ERROR REPORTING PHILOSOPHY . . . . . . . . . . . . 24
7.1 Reporting to SPEAR . . . . . . . . . . . . . . . 24
8.0 OPEN ISSUES . . . . . . . . . . . . . . . . . . . 25
9.0 SCHEDULE . . . . . . . . . . . . . . . . . . . . . 25
10.0 BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . 26
11.0 GLOSSARY . . . . . . . . . . . . . . . . . . . . . 27
12.0 REVISION HISTORY . . . . . . . . . . . . . . . . . 27
13.0 ALGORITHMS . . . . . . . . . . . . . . . . . . . . 28
13.1 NI Services Program algorithm . . . . . . . . . 28
13.2 Normal Command Processing algorithm . . . . . . 28
13.3 Reserve Remote Console algorithm . . . . . . . . 29
13.4 Release Remote Console algorithm . . . . . . . . 29
13.5 Load Server Code algorithm . . . . . . . . . . . 30
13.6 Multi-block Load algorithm . . . . . . . . . . . 31
Overview of the Diagnostic Product Page 1
OVERVIEW OF DIAGNOSTIC PRODUCT 27 May 88
1.0 OVERVIEW OF DIAGNOSTIC PRODUCT
1.1 Scope of this document
This document describes the functional definition, design details,
testing requirements and schedule for the "NI Services Program
[DFNIC] of the TOPS-20 implementation of the TOPS-20/PLUTO. This
program implements the console carrier requestor portion (CCR) of
the NI based system. This document will be updated whenever changes
are necessitated in these areas.
1.2 General program description
The NI Services Program is a user mode only Program that will run
under the TOPS-20 Operating System (Release 6.1 or newer). In
simple terms the NI Services Program is basically a terminal
interface between TOPS-20(host) and a remote program which resides
in a PLUTO(node) on the NI. This Program will have the ability to
cause a Diagnostic or a Utility program in the remote node to be
loaded and executed. It will also be able to communicate with the
remote program while it is running and may take status or terminate
its operation.
Command and Response Packets are passed between the NI Services
Program and the PLUTO Console Carrier Server Task using the Console
Carrier Protocol and the NI Remote Console Interface provided by the
LLMOP% JSYS.
1.3 Users and Uses
Field Service will use this Program to run remote diagnostic and
utility programs on NI nodes.
1.4 Pre-requisite software
o TOPS-20 Operating System with the LLMOP% JSYS implemented.
Overview of the Diagnostic Product Page 2
PRODUCT GOALS/NON-GOALS 27 May 88
2.0 PRODUCT GOALS/NON-GOALS
2.1 Performance goals
To be able to execute, with a high degree of predictability, the
commands received by the user on a terminal and relay messages
effectively from the remote program.
2.1.1 Program size
The NI Services Program should not be more than 10k, including
buffer storage.
2.1.2 Program run time
Run time in the traditional sense does not apply. This program is
used as a terminal interface between TOPS-20 and a remote NI node.
2.1.3 Exec mode capability
The NI Services Program will not run in Exec Mode.
2.1.4 User mode capability
The user will need Wheel, Operator or Maintenance priviledges to run
this Program.
2.1.5 Fault Detection
The NI Services Program will not have any of its own Fault
Detection. Any error detected by the remote program will be
displayed for the User to see. A JSYS failure will be displayed on
the users terminal like all other TOPS-20 programs.
2.1.6 Fault isolation
The NI Services Program has no built in isolation capability. Any
Functional Fault Detected will be passed back to the user by the
remote program for analysis and reporting.
Overview of the Diagnostic Product Page 3
PRODUCT GOALS/NON-GOALS 27 May 88
2.1.7 General user interface philosophy
The NI Services Program will use TOPS-20 style Parsing and
Recognition.
2.1.8 Program documentation
Excerpts from this Functional Specification will be incorporated in
the final Program documentation. The Program Documentation will be
in conformance to the Diagnostic Q.A. Manual.
2.2 Compatibility goals
The NI Services Program will support the manditory functionality as
defined in the "A PLUTO IMPLEMTATION OF A CONSOLE CARRIER SERVER",
3-Mar-82 by Paul Weiss.
2.2.1 CPU family
The NI Services Program is a user Program and is Monitor dependent
rather than Hardware dependent. It will run on any KL10 Model B 36
bit CPU provided the Monitor is a TOPS-20 Monitor that supports the
NI.
2.2.2 Standard diagnostic support software
The NI Services Program will not use any of the Standard Diagnostic
Support Software. It will be a self contained program with an
".EXE" extension.
2.2.3 Operating systems (TOPS-10)
There is no planned TOPS-10 support for the NI Services Program. If
in the future it is decided to have the NI Services Program run
under TOPS-10, it will be done as a separate project. The TOPS-10
effort will be minimized by organizing the Software in a modular
fashion.
Overview of the Diagnostic Product Page 4
PRODUCT GOALS/NON-GOALS 27 May 88
2.2.4 Operating systems (TOPS-20)
The NI Services Program will run under TOPS-20 release 6.1 and
newer.
2.2.5 Spear
The NI Services Program will be upward compatible with versions of
SPEAR after TOPS-20 release 6.1 and newer.
2.3 Failsoft goals
2.3.1 CPU/Memory failures
The NI Services Program will be aborted by the Operating System.
2.3.2 Power fail/restart
The Ni Services Program will have to be restarted by the user when
the System is reloaded.
2.4 Restrictions
The NI Services Program will only work under a TOPS-20 Operating
System and communication will only be with a PLUTO node located on
the NI.
2.4.1 User mode privileges
The LLMOP% JSYS requires Wheel, Operator or Maintenence priviledges.
This means that the directory the user is logged on to must have the
above priviledges.
2.4.2 User mode priority interrupts
The NI Services Program will not use any Hardware Interrupts. The
Software Interrupt System will be used.
Overview of the Diagnostic Product Page 5
PRODUCT GOALS/NON-GOALS 27 May 88
2.5 Non-Goals
o The Ni Services Program will not do error retries.
o The NI Services Program will provide no exec mode support.
o The NI Services Program will provide no TOPS-10 support as part
of this Project.
Overview of the Diagnostic Product Page 6
REQUIREMENTS 27 May 88
3.0 REQUIREMENTS
3.1 Run time requirements
o A TOPS-20 Timesharing Monitor needs to be running.
o Adequate user priviledges.
o An NI (ETHERNET) Network
o A PLUTO, that has Console Carrier Server support.
3.2 Development environment requirements
The hardware requirements needed to test the NI Services Program
are:
o A KL10 system that has a KLNI and a PLUTO is required.
o One Pluto system with a UNA.
o Two host systems residing on the NI.
The NI Services Program must be tested with the PLUTO console server
in each of the three possible states described below under
Reservation States.
The NI Services Program must be tested with the PLUTO at micro-odt
level and with the PLUTO based diagnostics package to test the
normal processing of commands.
3.3 Evaluation system
Engineering, Manufacturing and CSSE are expected to make their own
arrangements as to the availability of hardware for their Diagnostic
evaluation.
Overview of the Diagnostic Product Page 7
PROGRAM INTERFACES 27 May 88
4.0 PROGRAM INTERFACES
4.1 Diagnostic software interfaces
Not Applicable
4.2 Operating system interfaces (TOPS-10)
Not Supported
4.3 Operating system interfaces (TOPS-20)
The programming interface will be with the Monitor. Packets of
information will be sent and recieved using Monitor Calls that will
be supported in TOPS-20 Release 6.1 and newer.
Overview of the Diagnostic Product Page 8
COMMANDS 27 May 88
5.0 COMMANDS
The commands available to the user of the NI Services Program are:
HELP
ENABLE/DISABLE
| Debug
Spear-Reporting
Output-Logging (to) <file-spec>
| Trace
IDENTIFY (node) <node-address>
| DISPLAY-ADDRESS <of>
| All
| Local-node
| Remote-nodes-on-network
| READ-COUNTERS <node>
| REDEFINE
| CONNECT (port) <number>
| CONNECT (node) <node-address>
SHOW
| All
| Debug
| Logging
| Spear-reporting
| Trace
QUIT
| EXIT
Control-C
Control-Y
| Control-D
| Control-B
The HELP command will list information about the other commands and
their options
The ENABLE command is used to enable or "turn-on" certain program
features.
The DISABLE command is used to disable or "turn-off" certain program
features.
Overview of the Diagnostic Product Page 9
COMMANDS 27 May 88
| The IDENTIFY command will cause the program to perform a REQUEST ID
| to the address specified as part of the command and will print the
| SYS-ID information obtained from that address.
|
| The DISPLAY-ADDRESS command displays the address of the local node
| and/or all the remote nodes on the network.
|
| The READ-COUNTERS command will read the counters of the specified
| node.
|
| The REDEFINE command will enable the user to change the exit
| character to exit from the remote mode.
|
| The CONNECT command actually connects the user's terminal to the
| PLUTO console terminal to transfer characters back and forth between
| the two. A "control-D" typed by the user will disconnect the user's
| terminal from this mode and return the user's terminal to command
| mode. A "control-B" typed on the user's terminal will cause a BREAK
| to be sent to the the PLUTO.
The SHOW command is used to display the current state of various
options and control flags in use by the program.
|
| The QUIT and EXIT commands will return the user to TOPS20 monitor
| level. It will Deselect a selected NODE properly before returning
| to the monitor and close the logging file if it was in use.
|
| A CONTROL-D typed while in the Remote Terminal mode will cause a
| disconnect from the remote mode and put the user back to the command
| level.
|
| Two CONTROL-C's typed while the program is in command or remote mode
| will always put the user back to TOPS20 monitor level.
A CONTROL-Y typed while the program is in any mode will cause an
immediate return to TOPS20 monitor level. The monitor CONTINUE
command will then resume operation from the interrupted point.
Overview of the Diagnostic Product Page 10
FUNCTIONAL DESCRIPTION 27 May 88
6.0 FUNCTIONAL DESCRIPTION
The PLUTO hardware does not include a physical console terminal.
Instead, a facility has been designed whereby a terminal on a host
node can be connected logically to the console interface on the
PLUTO and hence act as its console.
The standard PLUTO Server software will not use the console at all,
but there are occasions where this facility will be useful. For
example, diagnostics will use this facility extensively to
communicate with the user running the diagnostic - this enables
diagnostics that currently exist to be used without being rewritten.
Also, the 11/24 PLUTO processor includes micro-ODT, and so the
remote console facility may be used to control or debug a failing
node, much in the same way that a standard 11/24 may be controlled
via its own console terminal.
6.1 Relationship To Other Components
Terminal
|
|
V
+-----+ LLMOP% +---------+ NI +-------+ ASYNC +-------+
| NIS |<-------->| TOPS-20 |<------->| PLUTO |<------->| PLUTO |
+-----+ +---------+ (MOP) | UNA | Console | 11/24 |
| | CCS | +-------+
| +----------+ +-------+
+----------->| Volatile |
| Data | NIS = NI Services Program
| Base | CCS = Console Carrier Server
+----------+
Overview of the Diagnostic Product Page 11
FUNCTIONAL DESCRIPTION 27 May 88
6.2 NI Services Program
The NI Services Program will communicate with the PLUTO console
carrier server (CCS) which resides on a target node to provide
remote access to normal PLUTO console services. The NI Services
Program will provide the user interface to communicate with the
remote console. This program communicates via the LLMOP% interface
with the TOPS-20 monitor which in turn communicates with the PLUTO
console carrier server on a target node. It is a requirement that
the user be a privileged user in order to invoke the NI Services
Program and communicate with the PLUTO console carrier server.
There are two pieces of software that implement the remote console
facility. The NI Services Program on a TOPS20 host implements the
Console Carrier protocol and transfers characters transmitted across
the NI to and from a physical terminal on the host. The PLUTO UNA
code that implements this facility is known as the Console Carrier
Server.
The PLUTO remote console is a resource, and as such is subject to
contention between multiple requesting hosts. There is a mechanism
to resolve conflicts in using the remote console, viz.
'reservation' of the console. The requestor has to 'reserve' the
console before it may be used to transfer characters, and normally
the requestor 'releases' the remote console when it is no longer
required.
There is a timeout associated with reservation of the remote
console; the requestor must communicate with the server often
enough so that the reservation timer does not complete and hence
cause the remote console to be released from the requestor. The
value of the reservation timer is of the order of minutes; its
exact value will be determined later.
Having reserved the PLUTO's remote console facility and confirmed
that the reservation was successful, the NI Services Program may now
initiate communication to and from the PLUTO remote console.
Normally this would involve communications with a real terminal,
taking characters typed by the user on the real terminal and passing
them to the remote console and taking characters from the remote
console and displaying them on the users real terminal.
There is a requirement to provide an escape convention, so that the
terminal user may effect the following features:
1. Exit from the REMOTE TERMINAL portion of the NI Services
Program.
2. Emulate an input break condition, as though the user had hit the
break key on a local 11/24 console. This will force the PLUTO
processor into its micro-ODT, making available all the features
that micro-ODT permits, ie. examining memory, depositing
memory, resetting the machine etc.
Overview of the Diagnostic Product Page 12
FUNCTIONAL DESCRIPTION 27 May 88
3. Pass characters through that would otherwise be interpreted by
the hosts terminal driver, for example ^C.
As previously described, the requestor program should ensure that
there is communications with the server often enough to avoid the
reservation timer in the server expiring and forcing the remote
console back in the unreserved state. The Console Carrier protocol
includes the ability to send 'null' messages so that communication
can still occur between a functioning requestor and the server
without passing any data.
When the terminal user has finished with the remote console, the
requestor should relinquish control. The remote console facility is
now available to other requestors.
6.3 PLUTO Console Carrier Server
The PLUTO console carrier server is being supplied by the PLUTO
server base.
6.4 Console Carrier Protocol
The Console Carrier (CC) protocol is, as its name implies, a means
of transporting ("carrying") the information flow between a computer
console and that console's usually human user, in a situation in
which the user's terminal is attached to a system other than the
system of interest. The information is typically streams of ASCII
characters, though that is not a requirement of the protocol. The
physical console serving as a paradigm for the model is not an
"old-fashioned" console with a switch register, boot, continue,
examine, address, and deposit switches, but rather an ASCII console.
Such a console is a distinguished terminal. It can be used as a
normal terminal I/O device until a particular sequence of characters
is input by the human, after which point it has all the capabilities
of the old-fashioned console.
The objects of interest in the protocol are a requestor module, a
server module (the objects which speak the protocol) and a requestor
user process and server user process. Typically the latter two will
be a human using the remote console, and the target system's ASCII
console, respectively. The requestor and server protocol modules
occupy levels III through VI in the ISO model: they make direct use
of a data link layer (DDCMP or NI Data Link), under which is a
physical link layer (RS232-C or Ethernet Physical Link). The end
users make direct use of the CC Requestor and Server.
The Console Carrier protocol is a simple half-duplex polled protocol
designed to provide some degree of end-to-end (or user-to-user)
communication without the overhead of DECnet logical links. These
sections will discuss the operation of the protocol in terms of
Overview of the Diagnostic Product Page 13
FUNCTIONAL DESCRIPTION 27 May 88
message interchanges, the services the protocol affords, and what
the costs are for supplying those services in such an "inexpensive"
manner. The description will be informal; the protocol is formally
defined in the DNA Low-level Maintenance Operations Spec.
6.4.1 Message Flow Within The CC Protocol
The protocol is comprised of six different types of messages:
Request System ID, System ID, Reserve Console, Release Console,
Console Command and Poll, and Console Response and Acknowledgement.
The procedure which a Console Requestor must follow to reserve a
remote console is:
1. Ask the remote system for a System ID message, and receive that
message.
2. Note that the remote system has a remote console, and that the
console is not reserved. These two pieces of information are
included in the system ID message.
3. Assuming that the remote system has an unreserved console, send
that remote system a Reserve Console message.
4. Again ask the remote system for a System ID message by means of
a Request System ID message. If the requestor system has been
successful in reserving the remote console, the requestor's
address will appear as the console owner in the System ID
message.
If the remote system does not have a remote console, it may be
possible to "put a console on the system". This is not part of the
CC protocol, but is rather a function of a particular
implementation. For instance, it will be seen later in this paper
that the CC server for a Pluto implementation runs on the CPU aboard
the Pluto's UNA, not on the Pluto's CPU. This CC server can be
down-line loaded into the UNA, at which time the remote system will
"have" a console.
After reserving the remote console, the requestor must maintain that
reservation by sending Console Commands and Polls at some interval
less than the console's reservation timer. (The magnitude of the
timer is contained, again, within the System ID message.)
After the point at which the console is successfully reserved, the
communication consists of an arbitrarily long series of Console
Commands and Polls, answered by Console Responses and
Acknowledgements. Any messages may have null data; the protocol is
concerned only with the correct state changes. This dialog is
driven by the Requestor, which is responsible for issuing commands
and polling for responses from the Server. The Server cannot
independently return a response. Therefore, the Requestor must know
when and how often it must poll a response in order to prevent a
Overview of the Diagnostic Product Page 14
FUNCTIONAL DESCRIPTION 27 May 88
buffer overrun at the Server. The association of Requestor-defined
command data to Server-returned response data is made in the user
layer above the CC protocol. The communications path thus
established between Requestor User and Server User will remain
intact until the console is explicitly given up by the Requestor by
means of a Release Console message, or until the interval between
Console Commands and Polls exceeds the Console Server-defined
reservation timer. The protocol state is reflected unchanged by the
Console Server. The burden of recognizing an unsynchronized
protocol rests on the requestor. To resynchronize the protocol, the
requestor must release, then re-reserve the console.
6.4.2 Characteristics And Uses Of The Protocol
A user process within a DECnet network (or other modern layered
protocol network) has available certain services which allow that
user to believe that there exists a direct, exclusive, error free
communication path between him/herself and some physically distant
analogous user process. Of course, neither of the "users" need be
human, and the physical distance may vary by several orders of
magnitude, but in all cases, a model of two users "conversing" over
an I/O channel (telephone line, "pipe") is a useful one. Such user
processes have the following expectations of an end-to-end protocol:
1. That the pipe will hide the imperfections of the physical
medium; that is, they expect the path to be error-free.
2. That everything entering at one end will come out the other in
the same order; that is, they expect guaranteed delivery and
sequentiality.
3. That no other user's traffic will be interjected into their data
stream, and that the data that they input will be delivered only
to the partner process.
4. The initiating process expects that, if an attempted connection
succeeds, that connection will be made only to the object with
which it is specifically interested in communicating.
5. Both processes expect a degree of flow control sufficient to
protect themselves and the network from congestion and/or
overrun.
The CC protocol addresses all of these problems except the first by
the expedient of ignoring them: it is entirely the concern of the
user processes to see that they get done. The first, the error-free
path, is assumed to be supplied by the data link layer protocol.
Delivery is not guaranteed: if a requestor doesn't poll the server
as fast as the server generates responses, response data will be
lost. If the requestor generates commands faster than the server or
the server user process is able to process them, commands will be
Overview of the Diagnostic Product Page 15
FUNCTIONAL DESCRIPTION 27 May 88
lost, or the association of response to command will become skewed.
Access to the PLUTO Console Carrier Server is controlled by
requiring that the value of the "verification" field in a Reserve
Console message match the verification field which is stored in the
PLUTO UNA. How the verification field value in the PLUTO UNA gets
set is yet to be defined. Access to the CC requestor module is
neither specified nor controlled by the protocol. (However, CC
requestors will typically be implemented on larger, more controlled
systems.)
Because the protocol assumes no layers between itself and a user
layer, and because it demands no particular proof of identity from
its users, the server user process is that process which happens to
be interested in being the server user. Control of the access to
the console by a requestor user is within the protocol: a requestor
sends the console server a request to reserve the console, and then
asks the console to send a system ID. If the requestor has
successfully reserved the console, the requestor's own address will
appear in the ID message as the console user. A requestor may
explicitly release a reserved console. In addition, a reservation
timer, the magnitude of which is indicated in the system ID message,
determines how long the requestor may remain idle (not sending
commands or polling for data) before its ownership will be
rescinded. (The magnitude of this timer is not yet defined; it is
thought to be of the order of minutes.) This value will be
hard-coded into the Console Carrier Server microcode.
Flow control is very rudimentary: only one message may be
outstanding at any one time; to return response data requires a
command/poll. Lost response data is reported by the CC server. The
protocol state is kept as a one-bit sequence number. The first
command from the requestor has a sequence number of one. The
protocol state of the requestor may be thought of as the message
number of the current command/poll that it is currently attempting
to get across. The protocol state of the server may be thoght of as
the message number of the last correctly received command/poll. A
change in state implies an ACK, and is accompanied by (possibly
null) command data or response data. Command/polls with no state
changes and no data are used by the Console Requestor to NAK Console
Responses. The Console Server has the ability to indicate that it
has dropped (or lost, or scrambled) a Console Command, and the
ability to piggyback Console Response data on that NAK. Such a
response might be better called a WAK (wait/acknowledgement), with
the semantic meaning: "I've received your command, but no action
will be taken on it. Please retransmit the command, and,
incidently, here is some response data."
All of this should be taken to mean that this protocol assumes that
the requestor user process has the intelligence of a human, that in
fact the requestor user process is a human. Although the preceeding
traits seem to describe a terrible protocol, they are, in fact, very
much the same traits exhibited by a real ASCII console terminal
connected to a computer system in which one may be interested. That
terminal may be attached by some process of no interest, it may be
Overview of the Diagnostic Product Page 16
FUNCTIONAL DESCRIPTION 27 May 88
too slow to output the information from the process without dropping
characters, it may be typing out the uncoordinated interspersed
outputs of several processes, it may be a terminal on a "dead"
machine, etc. In such a case, the human user would either make some
sense of the scrambled mess presented to him/her, or would put the
terminal into console mode and reboot the system, perhaps using the
console emulator to try to figure the system's state first. (Of
course, it will frequently be the case that the terminal will afford
the user exactly the desired capabilities.)
6.5 Remote Console Reservation
The user must specify the target node with which the user wishes to
communicate. The required input to the NI Services Program will be
a node id (ie. either node name or node address). The other
parameters are optional. If not specified in the command line, they
must be specified in the Ni Services data base. If specified in the
command line, they override the parameters set in the NI Services
data base. The syntax for the command line input is:
| RMTCON> CONNECT port-id
| RMTCON> CONNECT node-id
If the connection is established with the specified node, the
following message will be displayed on the user's terminal:
| To Disconnect & return to command mode, type a single control-D
|
| Typing one or several carrage returns will then result in the
| following prompt to be displayed on the user's terminal:
| Local>
The user can now begin communications as a remote terminal.
In order for the NI Services Program to communicate with a remote
node, the SERVICE CIRCUIT, HARDWARE ADDRESS, and SERVICE PASSWORD
must be specified in either the command line or the volatile data
base. The names of the files containing the special secondary
loader and the micro-code will be hardwired into the program image.
6.5.1 Reservation States
The PLUTO console carrier server may be in one of three states when
the user wishes to reserve the console:
1. The PLUTO console carrier server is loaded and unreserved.
2. The PLUTO console carrier server is loaded and reserved.
Overview of the Diagnostic Product Page 17
FUNCTIONAL DESCRIPTION 27 May 88
3. The PLUTO console carrier server is not loaded.
If the PLUTO console carrier server is loaded and unreserved, the NI
Services Program will reserve it. At this point, the user will
enter commands as if he were physically located at a console. The
commands will be transmitted by the requestor to the server. The
appropriate response will be transmitted by the server to the
requestor. The requestor will display this information to the user.
If the PLUTO console carrier server is loaded and reserved, an error
message will be displayed to the user on the issuing terminal.
If the PLUTO console carrier server is not loaded, the requestor
will load the server. It may be necessary for the requestor to
identify the target node via the 48-bit hardware address if the
target node is not known to the network. Once the server is loaded,
the requestor will attempt to reserve the console and proceed as
above.
6.5.2 Reservation Details
The PLUTO UNA code that implements the Console Carrier protocol may
or may not be resident in the PLUTO UNA. Thus the requestor must
check whether the Console Carrier code is present in the PLUTO UNA
and if necessary load the appropriate server code into the PLUTO UNA
via the NI.
The target PLUTO may be responding to one of two 48bit NI addresses,
depending on the state of the PLUTO UNA. Thus the requestor should
attempt to communicate with both the PLUTO 48bit hardware UNA
address and the PLUTO 48bit Phase IV UNA address and use whichever
one that responds in subsequent messages.
In its initial state, the PLUTO UNA will respond to its 48bit
hardware UNA address. When the PLUTO Server software initializes
the UNA for a phase IV node, it changes the UNA address to be a
Phase IV 48bit address. The Phase IV 48bit address is formed by
appending the 16bit Phase IV node number to a fixed 32bit value.
The following sections describe the different situations which may
occur when the requestor tries to connect to the remote console
facility. The requestor sends the initial request, to both 48bit
addresses if necessary, as follows:
REQUEST ID :
CODE = 15
RECEIPT NUMBER = requestors identification
We will now see the possible responses to this request, and the
actions that may be taken by the requestor in each case.
Overview of the Diagnostic Product Page 18
FUNCTIONAL DESCRIPTION 27 May 88
6.5.3 Console Carrier exists - but console in use
In this case, the Console Carrier code has been loaded into the
PLUTO UNA previously, but at the moment, another host has reserved
the console, so that it is unavailable to us.
The format of the reply is:
SYSTEM ID :
CODE = 7
RECEIPT NUMBER = matches value sent in REQUEST ID
OTHER INFO :
MAINTENANCE VERSION = 3.0.0
FUNCTIONS = at least console carrier
CONSOLE USER = non-zero 48bit Phase IV address
which does not match our address
RESERVATION TIMER = (value to be determined)
CONSOLE COMMAND SIZE = (value to be determined)
CONSOLE RESPONSE SIZE = (value to be determined)
HARDWARE ADDRESS = 48bit hardware UNA address
DEVICE = 1 (ie. UNA)
In this case, console carrier is known to be present as the 'console
carrier' bit is set in the FUNCTIONS field - other bits will be set
in this field depending on the current state of the PLUTO UNA. The
console is reserved by some user as CONSOLE USER is non zero.
However the host is not the current user of the remote console
feature as the value of this field does not match the hosts 48bit
Phase IV address.
In this case, the host is unable to reserve the console. There are
two options at this point: either wait a while and try again, or
return an error message to the user who is requesting the console
service for the PLUTO.
6.5.4 Console Carrier exists - Console not reserved
In this case, the Console Carrier code has been previously loaded
into the PLUTO UNA, but at the moment there is no requestor who has
reserved the console.
The reply looks like:
SYSTEM ID :
CODE = 7
RECEIPT NUMBER = matches value sent in REQUEST ID
OTHER INFO :
MAINTENANCE VERSION = 3.0.0
FUNCTIONS = at least console carrier
CONSOLE USER = 0 (ie. not reserved)
RESERVATION TIMER = (value to be determined)
CONSOLE COMMAND SIZE = (value to be determined)
Overview of the Diagnostic Product Page 19
FUNCTIONAL DESCRIPTION 27 May 88
CONSOLE RESPONSE SIZE = (value to be determined)
HARDWARE ADDRESS = 48bit hardware UNA address
DEVICE = 1 (ie. UNA)
Here we see that the Console Carrier code is running, as the console
carrier bit is set in the FUNCTIONS byte. However, CONSOLE USER is
0 meaning that there is no current host that has reserved the
console.
We may now attempt to reserve the console, as follows:
RESERVE CONSOLE :
CODE = 13
This will attempt to reserve the remote console for our exclusive
use. However it is possible that another user is trying to reserve
the console, and managed to do so before we were able to. There is
also a possibility that the Console Carrier in the PLUTO UNA has
been disabled before we were able to reserve the console. Thus we
need to check whether we did indeed manage to reserve the console
successfully.
We now issue another REQUEST ID message, and depending on the reply,
we will find that we own the console, or that some other host has
reserved the console before us, or that Console Carrier is no longer
operational in the PLUTO, and will therefore have to be reloaded.
6.5.5 Console Carrier exists - we own the console
Assuming that we have tried to reserve the console, as in the
previous case, then we would normally expect this reply when we
issue the second REQUEST ID. In this case, we have managed to
successfully reserve the PLUTO console carrier server and may
proceed to use the remote console feature.
It is also possible that due to some error, the console believes we
own it, but we were not aware that we own it. This case is an error
as there can only be one user of the Console Carrier request code
for a given PLUTO at any time. In this case, the requestor should
issue a warning message, then release the console via a RELEASE
CONSOLE message and then attempt to reserve the console again via a
RESERVE CONSOLE message.
The format of the reply is:
SYSTEM ID :
CODE = 7
RECEIPT NUMBER = matches value sent in REQUEST ID
OTHER INFO :
MAINTENANCE VERSION = 3.0.0
FUNCTIONS = at least console carrier
Overview of the Diagnostic Product Page 20
FUNCTIONAL DESCRIPTION 27 May 88
CONSOLE USER = non-zero 48bit Phase IV address
which matches our address
RESERVATION TIMER = (value to be determined)
CONSOLE COMMAND SIZE = (value to be determined)
CONSOLE RESPONSE SIZE = (value to be determined)
HARDWARE ADDRESS = 48bit hardware UNA address
DEVICE = 1 (ie. UNA)
The console carrier code is present, as determined by the bit set in
the FUNCTIONS field, and we are designated as the console requestor
as the CONSOLE USER is set to be our 48bit Phase IV address. We may
now use the console carrier server and communicate between the host
terminal and the DL on the PLUTO.
6.5.6 Console Carrier code does not exist
Either there has never been any console carrier code operating in
the PLUTO, or else it had previously been loaded but has since been
disabled.
The reply in this case looks like:
SYSTEM ID :
CODE = 7
RECEIPT NUMBER = matches value sent in REQUEST ID
OTHER INFO :
MAINTENANCE VERSION = 3.0.0
FUNCTIONS = does not include console carrier
HARDWARE ADDRESS = 48bit UNA hardware address
DEVICE = 1 (ie. UNA)
In this case, the FUNCTIONS field does not include the console
carrier bit, so there is no running PLUTO Console Carrier server on
the PLUTO's UNA. Therefore we must load the console carrier code
into the UNA. This is accomplished by sending a BOOT message to the
PLUTO indicating that we wish to load the communications processor,
ie. the UNA, rather than the PLUTO itself.
The message format is:
BOOT :
CODE = 6
VERIFICATION = 8 bytes of password
PROCESSOR = 1 (ie. communications processor)
CONTROL :
BOOT SERVER = 1 (ie. requesting system)
BOOT DEVICE = 0 (ie. system default)
DEVICE ID = 0 (ie. irrelevant)
SOFTWARE ID = -1 (ie. system image)
Overview of the Diagnostic Product Page 21
FUNCTIONAL DESCRIPTION 27 May 88
As in the case of loading a PLUTO from a host, the password field
may be set up in the PLUTO UNA as 8 octets of zero, or it may be
non-zero. The requestor should attempt this message twice if
necessary, once with the normal password, and once with the
VERIFICATION field consisting of 8 octets of zeros. Only one of
these requests will be responded to. Note that the SOFTWARE ID is
always -1; "diagnostic" is not supported when trying to boot the
communications processor (ie. the UNA).
The reply to the BOOT message will be a REQUEST PROGRAM, which is a
request for the host to load the appropriate secondary loader into
the PLUTO UNA. The format of the request is as follows:
REQUEST PROGRAM :
CODE = 8
DEVICE TYPE = 1 (ie. UNA)
FORMAT VERSION = 1
PROGRAM TYPE = 0 (ie. secondary loader)
SOFTWARE ID = -1 (ie. system image)
OTHER INFO :
MAINTENANCE VERSION = 3.0.0
FUNCTIONS = dependant on current UNA state
... the rest of this section depends on
the current UNA state
The secondary loader that the host responds with is not the same as
would be sent for a load of the complete node. This secondary
loader is a loader which will load an image into the PLUTO UNA WCS
rather than the PLUTO memory. The secondary loader is contained in
a file PLUTOWL.SYS on the PLUTO directory.
The host sends the secondary loader in a single message as follows:
MEMORY LOAD WITH TRANSFER ADDRESS :
CODE = 0
LOAD NUMBER = 0
LOAD ADDRESS = (value to be determined)
IMAGE DATA = data from PLUTOWL.SYS
TRANSFER ADDRESS = (value to be determined)
The PLUTO WCS secondary loader now runs and requests the PLUTO WCS
code to be loaded, ie. the console carrier server code. The
message is as follows:
REQUEST PROGRAM :
CODE = 8
DEVICE TYPE = 1 (ie. UNA)
FORMAT VERSION = 1
PROGRAM TYPE = 2 (ie. system)
SOFTWARE ID = -1 (ie. loading standard software)
OTHER INFO :
MAINTENANCE VERSION = 3.0.0
FUNCTIONS = dependant on current UNA state
Overview of the Diagnostic Product Page 22
FUNCTIONAL DESCRIPTION 27 May 88
... the rest of this section depends on
the current state of the UNA
The host will now load down the PLUTO console carrier server code
into the PLUTO UNA WCS. This is a multiblock load. The PLUTO
console carrier server code is in the file PLUTOCC.SYS on the PLUTO
directory.
The host sends the following message:
MEMORY LOAD :
CODE = 2
LOAD NUMBER = starts at zero
LOAD ADDRESS = starting address to load this segment
IMAGE DATA = data to be loaded into the UNA's WCS
The exact method for determining LOAD ADDRESS and IMAGE DATA from
the file PLUTOCC.SYS will be determined later. The PLUTO UNA
secondary loader will reply with a message in the following form:
REQUEST MEMORY LOAD :
CODE = 10
LOAD NUMBER = number of next segment to load
ERROR = 0, if the last segment received correctly
1, if the last segment received was in error
The sequence of MEMORY LOAD and REQUEST MEMORY LOAD is repeated as
often as necessary to complete the load of the PLUTO console carrier
server. The load is terminated with a message of the form:
PARAMETER LOAD WITH TRANSFER ADDRESS :
CODE = 20
LOAD NUMBER = matches the last REQUEST MEMORY LOAD value
PARAMETERS :
0 (ie. no parameters)
TRANSFER ADDRESS = starting address of Console Carrier server
The actual value for TRANSFER ADDRESS will be determined later.
At this stage the PLUTO console carrier server is loaded and running
in the PLUTO UNA WCS. The host should now issue a RESERVE CONSOLE
request to attempt to get exclusive access to the remote console
facility. The format of the message is as follows:
RESERVE CONSOLE :
CODE = 13
The possible responses to the RESERVE CONSOLE message are explained
in a previous section.
Overview of the Diagnostic Product Page 23
FUNCTIONAL DESCRIPTION 27 May 88
6.6 Remote Console Operation
Once the remote console is reserved, a timer routine will be
executed once per second. The timer routine will transmit a console
command and poll message to the server with any data which has been
typed in by the user since the last transmit. If any response data
is received from the server, this data will be displayed on the
user's terminal exactly as it was received from the server. The
reservation timer for the server must be specified in units of
seconds. Since the requestor is polling at one second intervals,
there is no problem with satisfying the requirement that the server
must be polled within the time specified by its reservation timer.
Overview of the Diagnostic Product Page 24
ERROR REPORTING PHILOSOPHY 27 May 88
7.0 ERROR REPORTING PHILOSOPHY
o Report back to the user on functional errors.
o Hardware errors will be detected and logged by the Operating
System.
7.1 Reporting to SPEAR
The following information will be logged into the System Error Log
for SPEAR use.
o The current time when the remote console is reserved.
o The current time when the remote console is released.
o Port number/Node number.
Overview of the Diagnostic Product Page 25
OPEN ISSUES 27 May 88
8.0 OPEN ISSUES
There must be some special character which will be used to specify a
'BREAK' command in order to get the attention of micro-odt. [Control-B]
There must also be some special character to exit console carrier mode.
[Control-X]
These special characters should be agreed upon by all host
implementations (VMS and TOPS). At this point, there has not been any
agreement on the details in these areas.
The manner in which circuits over the UNA are modelled in network
management has not been defined as yet. For DDCMP circuits, the owner
is changed to the appropriate module (ex. LOOPER) and the state and
sub-state of the circuit is set according to the operation (ex.
on-looping). There is currently no definition of the model of UNA
circuits which specifies that this information will be kept or how this
information will be passed to network management if it will be
collected.
9.0 SCHEDULE
Milestone Target Date
--------- -----------
1. Functional Spec 6 May 83
Complete
2. Design/Code 1 July 83
Complete
3. Begin Debug 5 July 83
4. Complete Debug 15 July 83
5. Documentation 29 July 83
Complete
6. Evaluation 5 Aug 83
Complete
7. Completed 12 Aug 83
Overview of the Diagnostic Product Page 26
BIBLIOGRAPHY 27 May 88
10.0 BIBLIOGRAPHY
o Diagnostic Engineering Project Plan For Support of the Ethernet
Port (KLNI) on KL10.
Frank Gatulis / January 13,1983
o NI Node Product Architecture Specification
/ March 24,1982
o Digital Network Architecture - Low Level Maintenance Operations
Architectural Specification
Bob Stewart, Ken Chapman / April 20,1982
o A PLUTO Implementation of a Console Carrier Server
Paul Weiss / March 3,1982
Overview of the Diagnostic Product Page 27
GLOSSARY 27 May 88
11.0 GLOSSARY
o CCR Console Carrier Requestor, (the NI Services Program)
o CCS Console Carrier Server
o FCS First Customer Ship
o KLNI KL10 NI Ethernet Adapter
o N/A Not Applicable
o NI Network Interconnect (ETHERNET)
o PLUTO Communications Controller
o RCS Remote Console Service
o SCS Systems Communications Services
o SPEAR Standard Package for Error Analysis and Reporting
o TBD To Be Determined
o UUT Unit Under Test
12.0 REVISION HISTORY
Revision 0.1
May 3, 1983
John R. Kirchoff
The first mailing of this document.
Overview of the Diagnostic Product Page 28
ALGORITHMS 27 May 88
13.0 ALGORITHMS
13.1 NI Services Program algorithm
MODULE NIS
Get node to connect to
Check for required parameters in data base
IF user is privileged THEN
Open circuit
IF NI circuit THEN
Set characteristics
ENDIF
CALL Reserve_console
IF success then
Clear exit_flag
WHILE exit_flag not set DO
CALL process_command
ENDWHILE
Call release_console
ENDIF
Close circuit
ELSE
Display error messge
ENDIF
EXIT
13.2 Normal Command Processing algorithm
ROUTINE process_command
WHILE exit not set DO
Complement message number
IF timer expired or character received THEN
IF character received = exit character THEN
Set exit
ELSE
Transmit console command and poll message
Display response if any
ENDIF
ELSE
Wait
ENDIF
Overview of the Diagnostic Product Page 29
ALGORITHMS 27 May 88
13.3 Reserve Remote Console algorithm
ROUTINE reserve_console
Clear error
CALL transmit(request_id)[receive system id message]
IF CCS not loaded THEN
CALL load_server
ELSEIF CCS reserved by other node THEN
Display error message
Set error
ELSEIF CCS reserved by local node THEN
CALL release_console
ENDIF
IF no error THEN
Retry = 0
Clear fatal_error
WHILE retry < 5 and not fatal_error and not success DO
IF no error THEN
CALL transmit(reserve_console)
CALL transmit(request_id)
IF reservation not successful THEN
IF not loaded THEN
CALL load_server
ELSE
Set fatal_error
Display error message
ENDIF
ELSE
Get reservation timer from system id message
Message_number = 0
Set success
ENDIF
ENDIF
ENDWHILE
ENDIF
RETURN
13.4 Release Remote Console algorithm
ROUTINE release_console
CALL transmit(release_console)
RETURN
Overview of the Diagnostic Product Page 30
ALGORITHMS 27 May 88
13.5 Load Server Code algorithm
ROUTINE load
Transmit boot message - no service password
IF no reply THEN
Transmit boot message - include service password
IF no reply THEN Set fatal error
ENDIF
WHILE no fatal error DO
Set secondary comm loader flag
WHILE no error and more to load DO
Open image and check for proper format
IF improper format THEN
Set file error
ELSE
Get start address, length, and transfer address
IF loading secondary comm loader THEN
Read entire image
Transmit memory load with transfer address
ELSE
Call multi-block load
Set retry counter to 0
WHILE no error and request memory load
and req segment = load number DO
Transmit memory load with transfer address
IF no error and request memory load
and req segment = load number
and retry counter < 5 THEN
Increment retry counter
ELSE
Increment load segment number
ENDIF
ENDWHILE
ENDIF
ENDIF
IF no error THEN
Close file being loaded
IF loading server image THEN
IF request memory and segment = load number THEN
Indicate no more to load
ELSE
Set line protocol error
ENDIF
ELSE
IF request program received THEN
Set file to load from Program Request
ELSE
Set line protocol error
ENDIF
ENDIF
ENDIF
ENDWHILE
ENDWHILE
RETURN
Overview of the Diagnostic Product Page 31
ALGORITHMS 27 May 88
13.6 Multi-block Load algorithm
ROUTINE multi-block_load
Set Load Segment number to 0
Set Requested Segment number to 0
WHILE no error and more to load DO
Read a segment of memory from file
Set retry count to 0
WHILE no error and Requested Segment = Load Segment DO
Transmit Memory Load Message
IF no error THEN
IF Request Memory Load received THEN
Set Requested Segment number from message
IF Requested Segment = Load Segment THEN
IF Retry count less than 5 THEN
Increment retry count
ELSE
Set Line Communication error
ENDIF
ELSE
IF Req Segment .ne. Load Segment+1 THEN
Set Line Protocol error
ENDIF
ENDIF
ELSE
Set Line Protocol error
ENDIF
ENDIF
ENDWHILE
Increment Load Segment number
ENDWHILE
RETURN