Trailing-Edge
-
PDP-10 Archives
-
BB-H348C-RM_1982
-
swskit-v21/nvt/vms.pro
There is 1 other file named vms.pro in the archive. Click here to see a list.
Spec Distribution List:
VMS Team
Digital Equipment Corporation COMPANY CONFIDENTIAL
Title: VAX/VMS Network Command Terminal Protocol
Specification Status: n/a
Architectural Status: n/a
File: SGD104.RNO
PDM #: not used
Date: 8-Dec-1980
Superseded Specs: none
Author: Scott G. Davis
Typist: Scott G. Davis
Abstract:
This specification describes the protocol messages
and operation for the VAX/VMS network command terminal
implementation (remote terminals). The implementation
comprises RTTDRIVER (pseudo-terminal driver), REMACP
(remote terminal ACP), and RTPAD (SET HOST utility).
Revision History:
Rev.# Description Author Revised Date
1 Incorporate review comments S.G.D. 10-Dec-1980
2 Incorporate review comments S.G.D. 12-Dec-1980
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 1
Product Overview
1.0 Product Overview
1.1 Product Abstract
This protocol provides the VMS to VMS network command
terminal function. It conforms to the only network terminal
specification so far approved by the DRG.
1.2 References
DNA Network Virtual Terminal Specification, Version 1.0.
VAX/VMS Command Language Users Guide.
VAX/VMS I/O User's Guide.
1.3 Glossary
PAD Packet assembler/disassembler. This is the interface
between a terminal and a network.
1.4 Internal Interfaces Under ECO Control
1.5 Markets
1.6 Competitive Analysis
Since other computer manufacturers with whom DEC competes
have the network command terminal function, this product allows
us to continue to compete.
1.7 Product Audience
Anyone interested in implementing the protocol should read
this specification.
2.0 Product Goals
This protocol was designed to allow for simple
implementation and to allow ALL terminal functions to work
remotely the same as locally.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 2
Product Goals
2.1 Performance
The protocol was designed to allow simple implementation.
Optimum performance was not a goal of this project.
2.2 Support Objectives
The protocol is intended only for use in VMS-VMS operation.
Although the protocol may be implemented in other systems, THERE
IS NO GUARANTEE, EXPRESS OR IMPLIED, THAT THE PROTOCOL WILL NOT
BE ALTERED IN AN INCOMPATIBLE FASHION. IN ADDITION,
MODIFICATIONS TO THE PROTOCOL ARE NOT SUBJECT TO REVIEW OF ANYONE
OUTSIDE THE VMS DEVELOPMENT GROUP.
2.3 Environments
This protocol is intended to operate between machines running
VAX/VMS V2.0 and higher (and DECnet-VAX).
2.4 RAS Goals
2.5 Non Goals
It is not intended that this protocol be compatible with any
other network virtual terminal protocol, except insofar as both
conform to the DNA specification mentioned above.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 3
Functional Description
3.0 Functional Description
3.1 Operational Description
See section on protocols.
3.2 Restrictions
It is not intended that this protocol be compatible with any
other network virtual terminal protocol, except insofar as both
conform to the DNA specification mentioned above.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 4
Compatibility
4.0 Compatibility
4.1 DEC Products
VAX/VMS network command terminals are not necessarily
compatible with any similar function on other systems.
4.2 DEC Standards
This protocol is compatible with the DNA Network Virtual
Terminal Specification, Version 1.0.
4.3 External Standards
This protocol is not intended to be compatible with such
related standards as X.28, X.29, or X.3.
5.0 Input/Output Interactions and Impacts
5.1 Users
5.1.1 Input Interactions
The network command terminal facility is invoked by the SET
HOST DCL command. In addition, there are special considerations
for using ^Y to terminate a session. See the VAX/VMS Command
Language User's Guide for details.
All other input operations are functionally identical to
those available to any terminal on a VMS system.
5.1.2 Output Interactions
All output operates the same as it does over any VMS
terminal. Operation is functionally identical on terminals and
remote terminals.
5.1.3 VMS Terminal Driver Line Feed Processing
VMS terminal I/O has the following conventions for line feed
<LF> processing of formatted read and write operations.
Formatted operations are those other than passall or noecho.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 5
Input/Output Interactions and Impacts
The typical record type operations for input and output are
shown below:
READ
<LF> [Optional prompt] input data <terminator>
!----- Express or implied in prompt
WRITE
<LF> output data <CR>
To insure that input records do not overwrite previous
output when no leading LF is specified in a prompt, or no prompt
is specified, the following rules are followed:
1. All formatted reads beginning on a separate line need a
leading <LF> either express or implied. If a <LF> is
not actually specified in the prompt string, the
terminal driver must insert one according to rules 2 and
3.
2. If the last output character prior to the read was a
<CR> then a <LF> must be output prior to the first
prompt character or echo of read data. When this <LF>
is output, it takes the place of the leading <LF> in the
prompt string (if any).
3. Formatted reads terminated by a <CR> echo the <CR> as a
<CR><LF>. Since the <LF> is output in advance, it takes
the place of any leading <LF> (either express or
implied) of the next operation (read or write).
5.2 Software Products
5.2.1 Products That Use This Product
This protocol is used by the RTPAD, RTTDRIVER, and REMACP
components of VAX/VMS.
5.2.2 Products That This Product Uses
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 6
Input/Output Interactions and Impacts
5.3 Other Systems
Although not officially supported, similar implementations
on other systems are capable of connecting to REMACP (RSTS and
RSX, at this writing), and being connected to by RTPAD (RSTS,
RSX, and TOPS-20, at this writing).
5.4 Protocols
The protocol defined by the DNA Network Virtual Terminal
specification is intended as a method of starting up and closing
down network terminal operation in a common manner. The protocol
described here is actually the system-dependent protocol which is
permitted by the DNA specification.
First, the operation of the protocol will be presented, so
that the actual messages to be used can be understood in the
proper context.
To start up a remote terminal connection, the connector
(RTPAD), running where the "real" terminal resides, issues a
logical link connection request to DECnet object 23, the reserved
number for the "Host Terminal Handler". Provided there are
sufficient resources, the host terminal facility (REMACP) accepts
the logical link connection request. RTPAD and REMACP then
exchange configuration messages, as specified by the DNA Network
Virtual Terminal Specification. In the configuration message,
REMACP specifies that it understands Version 1 of the protocol,
that it is a VMS system facility, and that it is capable of
speaking the VMS-specific terminal protocol and no other.
REMACP expects to receive a similar message, with 8 bytes of
configuration message data postfixed: these 8 bytes are the
characteristics of the real terminal with which REMACP will be
interfacing. These characteristics are those obtained via the
VAX/VMS $GETDEV or $GETCHN system services.(See VAX/VMS I/O
User's Guide). The 8 bytes are those starting at offset
DIB$B_CLASS in the primary characteristics buffer returned by
either of the system services mentioned. Note that if the
characteristics are sent as 8 null bytes, the terminal will be
considered type "UNKNOWN" in the VMS system.
If REMACP is unhappy with the configuration message, it
sends a network virtual terminal disconnect protocol message and
then disconnects the logical link; if REMACP is satisfied that
it can converse with the connecting program, it posts a receive
on the logical link and awaits the first VMS-specific protocol
message. The same statements apply to RTPAD, except that, in
addition, RTPAD sends an "unsolicited data" notification as the
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 7
Input/Output Interactions and Impacts
first VMS-specific message. The purpose of this message is to
cause the job controller on the node where REMACP is running to
behave identically to the way in which it would if a user typed
^Y or carriage return on an unallocated terminal. That is, a
process is created and the LOGINOUT image begins to execute.
After the set up of the logical link is complete, and until
the logical link is broken at the termination of the dialogue,
the operation of the protocol is basically to have RTTDRIVER send
I/O requests issued by user programs to RTPAD for execution at
the real terminal interface, followed by the response returned by
RTPAD to RTTDRIVER for delivery to the image which originally
issued the QIO system service request. REMACP is the conduit
used by RTTDRIVER and RTPAD to communicate. Parameters to the
QIO system service are sent from RTTDRIVER to RTPAD, including
any attendant buffers such as terminal output, prompt strings, or
device characteristics. RTPAD responds with I/O status and any
attendant data, such as terminal input or device characteristics.
In addition, RTPAD may send attention notifications, such as
typeahead (unsolicited data) or ^Y,to RTTDRIVER.
The session is considered as normally terminated when RTPAD
receives a DECnet "synchronous disconnect", "disconnect abort",
or "partner exit" notification from REMACP. It is also
legitimate for RTPAD to terminate the logical link, as in the
case of "double ^Y". (See VAX/VMS Command Language User's
Guide).
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 8
Input/Output Interactions and Impacts
5.4.1 DNA Network Virtual Terminal Protocol Messages
For completeness, the set up messages are included here.
The CONFIG message sent by REMACP is of the form:
.BYTE 1 ! This is a CONFIGURATION message
.BYTE 1 ! This is version 1 of the protocol
.BYTE 0 ! ECO number
.BYTE 0 ! Customer modification number
.WORD 7 ! This is a VMS system
.WORD 4 ! Only VMS-specific protocol is known
The message sent by RTPAD is of the following form:
.BYTE 1 ! This is a CONFIGURATION message
.BYTE 1 ! This is version 1 of the protocol
.BYTE 0 ! ECO number
.BYTE 0 ! Customer modification number
.WORD system ! This is a "something" system
.WORD 4 ! VMS-specific protocol is known
! Other bits may be set, if RTPAD talks
! to other implementations
.QUAD characteristics ! 8 bytes of terminal characteristics
The DISCONNECT message is of the following format:
.BYTE 2 ! This is a DISCONNECT message
.BYTE reason ! Disconnect reason:
! 1 - incompatible protocol versions
! 2 - incompatible system support
5.4.2 VMS-specific Protocol messages
The following messages are used to implement actual terminal
I/O. The messages will be presented in DNA notation.
5.4.2.1 Messages from RTTDRIVER to RTPAD (OPERATION messages)
The messages from RTTDRIVER to RTPAD are those which result
from I/O requests issued by a program on the host system to a
remote terminal device. These I/O requests are packaged together
with any data required and transmitted to RTPAD for execution on
the real terminal. Beside I/O's issued by programs, I/O cancel
requests (possibly due to rundown operations) and broadcast
requests are also transmitted from RTTDRIVER to RTPAD.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 9
Input/Output Interactions and Impacts
+--------+--------+--------+--------+--------+
! OPCODE ! OPMOD ! REFID ! UNIT ! DATA !
+--------+--------+--------+--------+--------+
OPCODE (2): B = function code to be processed, the 6-bit
function from the system service, except:
A value of -1 means "broadcast".
A value of 38(16) - i.e., IO$_ACPCONTROL,
means cancel I/O.
High order bits must be zero.
OPMOD (2): B = The 10 bits of function modifier from the
$QIO system service. High order
bits must be zero.
REFID (4): B = Reference ID for operation. This number must
be returned in the END packet used to show
I/O completion. (See below).
UNIT (2): B = This is a field reserved for future
expansion. Must be present. Ignored.
DATA (many): B = Message-dependent data. This portion of the
OPERATION message varies with the operation
being performed. Following are the possible
formats for the DATA field:
READ: (OPCODES: IO$_READVBLK, IO$_READLBLK,
IO$_READPROMPT, IO$_READPBLK,
IO$_TTYREADALL, IO$_TTYREADPALL)
(OPMODS: IO$M_CVTLOW, IO$M_DSABLMBX,
IO$M_NOECHO, IO$M_NOFILTR, IO$M_PURGE,
IO$M_REFRESH, IO$M_TIMED,
IO$M_TRMNOECHO)
BCNT (4) B = byte count, i.e.,
P2 of $QIO.
TIMOUT (4) B = timeout count, i.e.,
P3 of $QIO.
Optional.
TERMIN (I-n) B = terminator string as
byte of length plus
terminator mask.
Optional.
PROMPT (n+2) B = prompt string as word
of length plus string.
Optional.
WRITE: (OPCODES: IO$_WRITEVBLK, IO$_WRITELBLK,
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 10
Input/Output Interactions and Impacts
IO$_WRITEPBLK)
(OPMODS: IO$M_CANCTRLO, IO$M_ENABLMBX,
IO$M_REFRESH, IO$M_NOFORMAT)
BCNT (4) B = byte count, i.e.,
P2 of $QIO.
CARCON (4) B = carriage control, i.e.,
P4 of $QIO.
Optional.
WDATA (n) B = write data.
SET MODE/CHARACTERISTICS:
(OPCODES: IO$_SETMODE, IO$_SETCHAR)
(OPMODS: IO$M_HANGUP, IO$M_CTRLCAST,
IO$M_CTRLYAST)
CHAR (8) B = device characteristics
(Same as from $GETCHN
or $GETDEV).
SPEED (4) B = speed specifier, i.e.,
P3 of $QIO.
FILL (4) B = fill specifier, i.e.,
P4 of $QIO.
PARITY(4) B = parity flags, i.e.,
P5 of $QIO.
BROADCAST:
BCNT (4) B = byte count.
WDATA (n) B = write data.
5.4.2.2 Messages from RTPAD to RTTDRIVER
5.4.2.2.1 ATTENTION Messages
ATTENTION messages are used to convey notification of some
terminal action by the user outside of the normal $QIO context.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 11
Input/Output Interactions and Impacts
+--------+--------+
! OPCODE ! REASON !
+--------+--------+
OPCODE (2): B = A value of -1 means "ATTENTION" message.
REASON (2): B = Attention reason. The possible values are:
0 - Unsolicited data available.
1 - Terminal hangup occurred.
2 - Control C (^C) struck.
3 - Control Y (^Y) struck.
5.4.2.2.2 END messages
END messages are used by RTPAD to signal completion of an
I/O operation which was requested by RTTDRIVER. These messages
carry I/O status, along with any data required by the operation.
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 12
Input/Output Interactions and Impacts
+--------+--------+--------+--------+--------+--------+
! OPCODE ! OPMOD ! REFID ! UNIT ! IOSB ! DATA !
+--------+--------+--------+--------+--------+--------+
OPCODE (2): B = A value of -2 means "END" message.
OPMOD (2): B = Must be present. Ignored.
REFID (4): B = Reference ID for operation. This number must
match the REFID in the message specifying
the operation which is now being completed.
UNIT (2): B = This is a field reserved for future
expansion. Must be present. Ignored.
IOSB (8): B = I/O status. This is the exact contents of
the I/O Status Block resulting from RTPAD's
executing the requested operation.
DATA (many): B = Message-dependent data. This portion of the
END message varies with the operation
being performed. Following are the posssible
formats for the DATA field:
READ:
RDATA (n+2) B = read data as word
of length plus string,
with terminator at end.
SENSE MODE/CHARACTERISTICS:
CHAR (8) B = device characteristics
(Same as from $GETCHN
or $GETDEV).
Digital Equipment Corporation COMPANY CONFIDENTIAL Page 13
Error Reporting
6.0 Error Reporting
6.1 Failures Within This product
Errors are reported to the user by means of the standard
VAX/VMS message facility.
6.2 Failures Within the Total Environment
7.0 Packaging and System Generation
The modules implementing this protocol are part of VAX/VMS.
7.1 Distribution Media
7.2 System Generation
8.0 Documentation
See the "SET HOST" command in the VAX/VMS Command Language
User's Guide.
9.0 User Examples
See the "SET HOST" command in the VAX/VMS Command Language
User's Guide.
[end of SGD104.RNO]