Google
 

Trailing-Edge - PDP-10 Archives - BB-R598A-RM_1983 - swskit-v3/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]