PDP-10 Archive: tools/rmtcon/rmtcon.rno from tops20_version7_0_tools_tape_clock

Trailing-Edge - PDP-10 Archives - tops20_version7_0_tools_tape_clock_tape - tools/rmtcon/rmtcon.rno

There are 3 other files named rmtcon.rno in the archive. Click here to see a list.

.style headers 6,0,0 !causes all headers to be taken as is, no capitalizing
.set paragraph 0,1,2 !causes no indenting on first line in paragraph
.display number RL !number title and toc with lower case roman numerals
.ebb
.autoparagraph
.left margin 0
.right margin 72
.page size 59,83
.control characters
.set date
.set time
.flag substitute
.date !causes date to go under page number
.title
.blank 2
.center;Date: $$date##$$time
.center;Charge Number:V20-05113
.blank 1
.center;Revision "0.2" of
.center;Diagnostic Engineering Functional Specification for
.center;NI Services Program
.blank 1
.center;RMTCON
.page size 59,72
.autoparagraph
.title Overview of the Diagnostic Product
.no fill
Revisions:
.b1
Rev 0.1 26-Sep-83#By#John R. Kirchoff
Rev 0.2 17-Oct-84#By#Gary Papazian
.fill
.page
.subtitle Table of Contents
.autosubtitle !causes header level 1's to be used as subtitles
.center;Table of Contents
.right;Page
.right;----
.!the next cmd inserts the table of contents produced by TOC.EXE
.require "RMTCON.RNT" !name of file for runoff to process
.display number D !number pages with decimal numbers
.number page 1
.fill.just.page.rm72
.autoparagraph

.send toc.blank 1
.lm0
.hl1 OVERVIEW OF DIAGNOSTIC PRODUCT
.lm4
.hl2 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.

.hl2 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.

.hl2 Users and Uses

Field Service will use this Program to run remote diagnostic and utility programs on NI nodes.

.hl2 Pre-requisite software
.lm4
.list "o"
.le;TOPS-20 Operating System with the LLMOP% JSYS implemented.
.end list

.page

.send toc.blank 1
.lm0
.hl1 PRODUCT GOALS/NON-GOALS
.lm4
.send toc.blank 1
.hl2 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.

.hl3 Program size

The NI Services Program should not be more than 10k, including buffer storage.

.hl3 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.

.hl3 Exec mode capability

The NI Services Program will not run in Exec Mode.

.hl3 User mode capability

The user will need Wheel, Operator or Maintenance priviledges to run this Program.

.hl3 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.

.hl3 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.

.hl3 General user interface philosophy

The NI Services Program will use TOPS-20 style Parsing and Recognition.

.hl3 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.

.send toc.blank 1
.hl2 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.

.hl3 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.

.hl3 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.

.hl3 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.

.hl3 Operating systems (TOPS-20)

The NI Services Program will run under TOPS-20 release 6.1 and newer.

.hl3 Spear

The NI Services Program will be upward compatible with versions of SPEAR after TOPS-20 release 6.1 and newer.

.send toc.blank 1
.hl2 Failsoft goals
.hl3 CPU/Memory failures

The NI Services Program will be aborted by the Operating System.

.hl3 Power fail/restart

The Ni Services Program will have to be restarted by the user when the System is reloaded.

.send toc.blank 1
.hl2 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.

.hl3 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.

.hl3 User mode priority interrupts

The NI Services Program will not use any Hardware Interrupts. The Software Interrupt
System will be used.

.send toc.blank 1
.hl2 Non-Goals

.lm4
.list "o"
.le;The Ni Services Program will not do error retries.
.le;The NI Services Program will provide no exec mode support.
.le;The NI Services Program will provide no TOPS-10 support as part of this Project.
.end list

.page

.send toc.blank 1
.lm0
.hl1 REQUIREMENTS
.lm4

.hl2 Run time requirements

.list "o"
.le;A TOPS-20 Timesharing Monitor needs to be running.
.le;Adequate user priviledges.
.le;An NI (ETHERNET) Network
.le;A PLUTO, that has Console Carrier Server support.
.end list

.hl2 Development environment requirements

The hardware requirements needed to test the NI Services Program are:

.ls "o"
.le;A KL10 system that has a KLNI and a PLUTO is required.
.le;One Pluto system with a UNA.
.le;Two host systems residing on the NI.
.els

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.

.hl2 Evaluation system

Engineering, Manufacturing and CSSE are expected to make their own arrangements as to the availability of hardware for their Diagnostic evaluation.

.page

.send toc.blank 1
.lm0
.hl1 PROGRAM INTERFACES
.lm4
.hl2 Diagnostic software interfaces

Not Applicable

.hl2 Operating system interfaces (TOPS-10)

Not Supported

.hl2 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.

.page

.send toc.blank 1
.lm0
.hl1 COMMANDS
.lm4

The commands available to the user of the NI Services Program are:

.lit

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>

QUIT
| EXIT

Control-C
Control-Y
| Control-D
| Control-B
.el

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.
.bb

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.
.eb

The SHOW command is used to display the current state of various options and control flags in use by the program.
.bb

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.
.eb

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.

.page

.send toc.blank 1
.lm0
.hl1 FUNCTIONAL DESCRIPTION
.lm4

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.

.hl2 Relationship To Other Components

.lit

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
+----------+

.el

.page

.hl2 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:

.ls
.le;Exit from the REMOTE TERMINAL portion of the NI Services Program.
.le;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.
.le;Pass characters through that would otherwise be interpreted by the hosts terminal driver, for example _^C.
.els

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.

.hl2 PLUTO Console Carrier Server

The PLUTO console carrier server is being supplied by the PLUTO server base.

.hl2 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 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.

.hl3 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:

.ls
.le;Ask the remote system for a System ID message, and receive that message.
.le;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.
.le;Assuming that the remote system has an unreserved console, send that remote system a Reserve Console message.
.le;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.
.els

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 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.

.hl3 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:

.ls
.le;That the pipe will hide the imperfections of the physical medium; that is, they expect the path to be error-free.
.le;That everything entering at one end will come out the other in the same order; that is, they expect guaranteed delivery and sequentiality.
.le;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.
.le;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.
.le;Both processes expect a degree of flow control sufficient to protect themselves and the network from congestion and/or overrun.
.els

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 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 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.)

.hl2 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:

.lit

| RMTCON> CONNECT port-id

| RMTCON> CONNECT node-id

.el

If the connection is established with the specified node, the following message will be displayed on the user's terminal:

.lit
| To Disconnect & return to command mode, type a single control-D
.el

.bb
Typing one or several carrage returns will then result in the following prompt
to be displayed on the user's terminal:
.eb

.lit
| Local>
.el

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.

.hl3 Reservation States

The PLUTO console carrier server may be in one of three states when the user wishes to reserve the console:

.ls
.le;The PLUTO console carrier server is loaded and unreserved.
.le;The PLUTO console carrier server is loaded and reserved.
.le;The PLUTO console carrier server is not loaded.
.els

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.

.hl3 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:

.lit

REQUEST ID :
CODE = 15
RECEIPT NUMBER = requestors identification

.el

We will now see the possible responses to this request, and the actions that may be taken by the requestor in each case.

.hl3 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:

.lit

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)

.el

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.

.hl3 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:

.lit

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)
CONSOLE RESPONSE SIZE = (value to be determined)
HARDWARE ADDRESS = 48bit hardware UNA address
DEVICE = 1 (ie. UNA)

.el

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:

.lit

RESERVE CONSOLE :
CODE = 13

.el

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.

.hl3 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:

.lit

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 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)

.el

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.

.hl3 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:

.lit

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)

.el

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:

.lit

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)

.el

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:

.lit

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

.el

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:

.lit

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)

.el

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:

.lit

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
... the rest of this section depends on
the current state of the UNA

.el

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:

.lit

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

.el

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:

.lit

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

.el

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:

.lit

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

.el

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:

.lit

RESERVE CONSOLE :
CODE = 13

.el

The possible responses to the RESERVE CONSOLE message are explained in a previous section.

.hl2 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.

.page

.send toc.blank 1
.lm0
.hl1 ERROR REPORTING PHILOSOPHY
.lm4
.list "o"
.le;Report back to the user on functional errors.
.le;Hardware errors will be detected and logged by the Operating System.
.end list

.hl2 Reporting to SPEAR

The following information will be logged into the System Error Log for SPEAR use.
.lm4
.list "o"
.le;The current time when the remote console is reserved.
.le;The current time when the remote console is released.
.le;Port number/Node number.
.end list

.page

.send toc.blank 1
.lm0
.hl1 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.

.send toc.blank 1
.lm0
.hl1 SCHEDULE

.lit

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

.el

.page

.send toc.blank 1
.lm0
.hl1 BIBLIOGRAPHY
.lm4
.list "o"

.le;Diagnostic Engineering Project Plan For Support of the Ethernet Port (KLNI) on KL10.
.BR
Frank Gatulis / January 13,1983

.le;NI Node Product Architecture Specification
.BR
/ March 24,1982

.le;Digital Network Architecture - Low Level Maintenance Operations Architectural Specification
.BR
Bob Stewart, Ken Chapman / April 20,1982

.le;A PLUTO Implementation of a Console Carrier Server
.BR
Paul Weiss / March 3,1982
.end list

.page

.send toc.blank 1
.lm0
.hl1 GLOSSARY
.lm8
.list "o"
.le;CCR####Console Carrier Requestor, (the NI Services Program)
.le;CCS####Console Carrier Server
.le;FCS####First Customer Ship
.le;KLNI###KL10 NI Ethernet Adapter
.le;N/A####Not Applicable
.le;NI#####Network Interconnect (ETHERNET)
.le;PLUTO##Communications Controller
.le;RCS####Remote Console Service
.le;SCS####Systems Communications Services
.le;SPEAR##Standard Package for Error Analysis and Reporting
.le;TBD####To Be Determined
.le;UUT####Unit Under Test
.end list
.lm0

.send toc.blank 1
.lm0
.hl1 REVISION HISTORY
.lm8

Revision 0.1
.br
May 3, 1983
.BR
John R. Kirchoff
.BR
The first mailing of this document.

.page

.send toc.blank 1
.lm0
.hl1 ALGORITHMS

.hl2 NI Services Program algorithm

.lit

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

.el

.hl2 Normal Command Processing algorithm

.lit

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
.el

.page

.hl2 Reserve Remote Console algorithm

.lit

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

.el

.hl2 Release Remote Console algorithm

.lit

ROUTINE release_console
CALL transmit(release_console)
RETURN
.el

.page

.hl2 Load Server Code algorithm

.lit

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
.el

.page

.hl2 Multi-block Load algorithm

.lit

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
.el