Trailing-Edge
-
PDP-10 Archives
-
QT020_T20_4.1_6.1_SWSKIT_851021
-
swskit-documentation/cterm-info.memos
There are no other files named cterm-info.memos in the archive.
MEMOS CONTAINED IN THIS FILE INCLUDE:
o CTERM Host functional and design specification
o CTERM Server functional and design specification
o VMS CTERM implementation document
------------------------------------
CTERM-HOST-FUNCTIONAL-AND-DESIGN.SPECIFICATION
CTERM Host Functional and Design Specification
Date: 27-Jul-84
Author: Mark McIntee
CTERM Server Functional and Design Specification Page 2
Table of Contents
1.0 PREFACE . . . . . . . . . . . . . . . . . . . . . . 3
2.0 REFERENCES . . . . . . . . . . . . . . . . . . . . . 3
3.0 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 3
CHAPTER I CTERM HOST FUNCTIONAL SPECIFICATION
I.1 AT THE SYSTEM LEVEL . . . . . . . . . . . . . . . . 4
I.2 AT THE PROGRAM LEVEL . . . . . . . . . . . . . . . . 6
I.2.1 .MOCTM - Is this a CTERM terminal ? . . . . . . . 6
I.2.2 .MOTXT - Set up for remote TEXTI% call . . . . . . 6
I.3 CTHSRV ENTRY POINTS . . . . . . . . . . . . . . . . 7
I.3.1 TTYSRV TDCALLs . . . . . . . . . . . . . . . . . . 7
I.3.2 CTERM specific MTOPR function . . . . . . . . . . 9
I.3.3 Initialization . . . . . . . . . . . . . . . . . 10
I.3.4 DECnet . . . . . . . . . . . . . . . . . . . . . 11
I.4 CTHSRV'S SIGNIFICANT EXTERNAL REFERENCES . . . . . 12
I.4.1 DECnet . . . . . . . . . . . . . . . . . . . . . 12
I.4.2 TTYSRV . . . . . . . . . . . . . . . . . . . . . 13
I.5 DOCUMENTATION . . . . . . . . . . . . . . . . . . 15
I.6 SYSTEM IMPACT . . . . . . . . . . . . . . . . . . 15
I.7 COMPATIBILITY . . . . . . . . . . . . . . . . . . 15
CHAPTER II CTERM HOST DESIGN SPECIFICATION
II.1 DESIGN OVERVIEW . . . . . . . . . . . . . . . . . 17
II.2 LAYERING . . . . . . . . . . . . . . . . . . . . . 18
II.3 NAMING CONVENTIONS . . . . . . . . . . . . . . . . 19
II.4 DATA BASE . . . . . . . . . . . . . . . . . . . . 20
II.4.1 Per terminal . . . . . . . . . . . . . . . . . . 20
II.4.2 System wide . . . . . . . . . . . . . . . . . . 21
II.4.3 Interconnections in the data base . . . . . . . 22
II.5 ALGORITHMS . . . . . . . . . . . . . . . . . . . . 23
II.5.1 Locking, Blocking and Revalidation. . . . . . . 23
II.5.2 Making a connection . . . . . . . . . . . . . . 24
II.5.3 State diagram . . . . . . . . . . . . . . . . . 25
II.5.4 Breaking a connection . . . . . . . . . . . . . 26
II.5.5 Sending CTERM messages to the server . . . . . . 27
II.5.6 Receiving CTERM messages from the server . . . . 27
II.5.7 Requesting TTY input from the server . . . . . 27
II.5.8 Receiving TTY input from the server . . . . . . 28
II.5.9 Sending TTY output to the server . . . . . . . 28
II.5.10 SIBE% . . . . . . . . . . . . . . . . . . . . . 29
II.5.11 TEXTI% and RDTTY%. . . . . . . . . . . . . . . . 29
II.5.12 TDCALLs and MTOPR% routines . . . . . . . . . . 30
II.6 TESTING . . . . . . . . . . . . . . . . . . . . . 31
CTERM HOST FUNCTIONAL AND DESIGN SPECIFICATION Page 3
PREFACE
1.0 PREFACE
CTERM is a protocol used to communicate between terminals and
operating systems. The protocol is layered on DECnet, and is defined in
[1] and [2]. TOPS-20 may serve both as host to other systems' terminals
and as server for its own terminals to do processing on other systems
which have implemented the CTERM protocol using DECnet. This
specification describes the host end of the CTERM protocol in TOPS-20.
2.0 REFERENCES
[1] Digital Terminal Software Architecture Network Command
Terminal Specification, Version 1.4, Leland Webber,
George Conant, Henry Lowe, and Chuck Jones, 15 Feb 1984.
[2] Digital Terminal Software Architecture Foundation Services
Specification, Version 2.4, George Conant, Henry Lowe,
and Chuck Jones, 15 Feb 1984.
[3] DECnet-36 Monitor Interface Description
William G. Nichols, 23 June 1983.
3.0 GLOSSARY
o CTERM definitions
* CTERM switch sequence: A sequence of two characters used
to momentarily switch control of the terminal back to the
server.
* CTERM terminal - A terminal which communicates with a
processor using the CTERM protocol.
* Host - The end of the CTERM connection which processes the
user's commands.
* Server - The end of the CTERM connection to which the
terminal is physically attached.
o TOPS-20 definitions
* CDB - CTERM data base (per terminal)
* TDB - TTY dynamic data base
* SAB - Session control argument block. Passed to the DECnet
interface routine, SCTNSF.
* Listener - A DECnet link in connect wait state; it is
waiting for a connect attempt.
CHAPTER I
CTERM HOST FUNCTIONAL SPECIFICATION
I.1 AT THE SYSTEM LEVEL
The CTERM host in TOPS-20 will consist of one new module in the
monitor, CTHSRV, and modifications to the existing modules TTYSRV and
FILMSC, to call routines in CTHSRV for CTERM type terminals, and
modifications to the module COMND to take advantage of CTERM
functionality.
CTHSRV will handle terminal I/O when TOPS-20 is the host (ie, the
user's program is running under TOPS-20). It is a terminal driver,
and so, takes data from the TTYSRV's output buffer and sends it to the
terminal server, asks the terminal server for data, and puts that data
in TTYSRV's input buffer. TTYSRV is responsible for moving the data
from the TTYSRV's input buffer to the user's program, and from the
user's program to TTYSRV's output buffer. CTHSRV will communicate
with the server using the internal interface to DECnet as described in
[3]. COMND, by using MTOPRs, will determine if the terminal is a
CTERM terminal, and if so, will cause the server to do some of the
input editing. See figure 1.
CTERM HOST FUNCTIONAL SPECIFICATION Page I-2
AT THE SYSTEM LEVEL
- FIGURE 1 -
TOPS-20 AS HOST
INTERCONNECTIONS OF MONITOR MODULES, PROGRAM, AND TERMINAL
(FLOW IS IN BOTH DIRECTIONS)
._______
! \
! TTY \
!_________!
!
xxxxxxxxxxxxxxx ! xxxxxxxxxxxxxxxxxxxxxxxx
x .___!_____. x
x ! TERMINAL! x
x ! DRIVER/ ! x
x ! CTERM ! x
x ! SERVER ! x
x !_________! x
x ! x REMOTE SERVER
x .___!_____. x
x ! ! x
x ! DECNET ! x
x !_________! x
x ! x
xxxxxxxxxxxxxxx !/! xxxxxxxxxxxxxxxxxxxxxx
!
! COMMUNICATIONS LINK
!
xxxxxxxxxxxxxxx !/! xxxxxxxxxxxxxxxxxxxxxx
x .___!_____. x
x ! ! MONITOR LEVEL x
x ! DECNET ! x
x !_________! x
x ! x TOPS20 HOST
x ._____!___. x
x ! ! x
x ! CTHSRV ! x
x !_________! x
x ! x
x .____!_____. x
x ! ! x
x ! TTYSRV, ! x
x ! I/O JSYSs! x
x !__________! x
x ! x
x/////////////// ! //////////////////////x
x ! x
x .____!____. USER LEVEL x
x ! ! x
x ! PROGRAM ! x
x !_________! x
x x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CTERM HOST FUNCTIONAL SPECIFICATION Page I-3
AT THE PROGRAM LEVEL
I.2 AT THE PROGRAM LEVEL
A user mode program uses CTERM via the usual I/O JSYSs, and is
transparent to the user. Those JSYSs will dispatch to CTERM routines
as their device-dependent code.
CTERM devices can do some things which other terminals cannot:
they have the ability to do local editing and to parse escape
sequences, for example. Therefore the implementation of CTERM will
include a new MTOPR% functions to enable some local editing features.
There will also be an MTOPR% function to determine if a TTY is a CTERM
TTY.
Like all MTOPRs, they take a JFN in AC1, and function code in AC2.
The new MTOPR% functions are:
o .MOCTM - Is this a CTERM terminal ?
o .MOTXT - Set up for remote TEXTI%
I.2.1 .MOCTM - Is this a CTERM terminal ?
Returns +1 always with:
AC3/ 1 if this is a CTERM terminal
AC3/ 0 if this is not a CTERM terminal
I.2.2 .MOTXT - Set up for remote TEXTI% call
Call with AC 3/ flags,,length, where flags have the same format as
the .RDLFG word in the TEXTI% jsys, and length is the maximum length
of the read. Note that the following flags are the only significant
ones:
o RD%RIE - return if input buffer empty
o RD%RAI - raise input
o RD%NED - disable some editing characters
This MTOPR% does NOT return any data. Data is received from the
terminal via a BIN% or other normal terminal jsys, with the editing
taking place at the server before TOPS20 sees them. The way this
MTOPR% is used in TEXTI% is by invoking it at the beginning before
each BIN%.
CTERM HOST FUNCTIONAL SPECIFICATION Page I-4
CTHSRV ENTRY POINTS
I.3 CTHSRV ENTRY POINTS
I.3.1 TTYSRV TDCALLs
o Set up the terminal's buffers
TDCALL <<CH,CTHSOF>>
T1/ Line number
T2/ Address of TTY dynamic data block
Returns +1 always
o Start output
TDCALL <<CH,CTHSTO>>
T2/ Address of TTY dynamic data block
Returns +1 always
o Output buffer full
TDCALL <<CH,CTHFOU>>
T2/ Address of TTY dynamic data block
Returns +1 always
o Input buffer empty
TDCALL <<CH,CTHTCI>>
T2/ Address of TTY dynamic data block
Returns +1 always
o Change terminal pause/unpause characters
TDCALL <<CH,CTHPPC>>
T2/ Address of TTY dynamic data block
Returns +1 always
o Enable/disable XON/XOFF recognition
TDCALL <<CH,CTHEXF>>
T2/ Address of TTY dynamic data block
Returns +1 always
CTERM HOST FUNCTIONAL SPECIFICATION Page I-5
CTHSRV ENTRY POINTS
o Set immediate and deferred out-of-band characters
TDCALL <<CH,CTHSPS>>
T1/ Old setting of immediate mask
T2/ Address of TTY dynamic data block
T3/ Old setting of deferred mask
Returns +1 always
o Get the input buffer character count
TDCALL <<CH,CTHCKI>>
T1/ Character count so far
T2/ Address of TTY dynamic data block
Returns +1 always
with T1/ Total input character count
o Detach
TDCALL <<CH,CTHLGO>>
T2/ Address of TTY dynamic data block
Returns +1 always
o STPAR%
TDCALL <<CH,CTHSPR>>
T1/ New settings
T2/ Address of TTY dynamic data block
Returns +1 always
o Decide if echoing is in progress.
TDCALL <<CH,CTHOOE>>
T2/ Address of TTY dynamic data block
Returns +1 if echoing is in progress
Returns +2 otherwise
CTERM HOST FUNCTIONAL SPECIFICATION Page I-6
CTHSRV ENTRY POINTS
o MTOPR% function .MOSPD - set terminal speed
TDCALL <<CH,CTHSSP>>
T2/ TTY number
T3/ input speed,,output speed
Returns +1 always
o MTOPR% function .MOSLW - set terminal width
TDCALL <<CH,CTHSWD>>
T1/ New width
T2/ Address of TTY dynamic data block
Returns +1 always
o MTOPR% function .MOSLL - set terminal length
TDCALL <<CH,CTHSLN>>
T1/ New length
T2/ Address of TTY dynamic data block
Returns +1 always
o MTOPR% function .MOSBM - set break mask
TDCALL <<CH,CTHSBM>>
T1/ Address of new 4 word break mask
T2/ Address of TTY dynamic data block
which contains old break mask.
Returns +1 always
I.3.2 CTERM specific MTOPR function
o Function .MOTXT - Do remote TEXTI%
CALL CTHTXT
T2/ TTY number
User AC3/ Address of argument block
Returns +1 on failure with error in T1
Returns +2 on success
CTERM HOST FUNCTIONAL SPECIFICATION Page I-7
CTHSRV ENTRY POINTS
I.3.3 Initialization
Initialize the CTERM system
CALL CTHINI
with no arguments
Returns +1 always
This is called during system startup after DECnet-36 has been
initialized.
CTERM HOST FUNCTIONAL SPECIFICATION Page I-8
CTHSRV ENTRY POINTS
I.3.4 DECnet
Callback on DECnet event
Queue up the event to read at scheduler level
CALL MSGINT
with
T1/ OLD-STATUS,,PSI-MASK
T2/ NEW-STATUS,,CHANNEL-NUMBER
T4/ LINK ID
Q1/ XOR OF OLD-STATUS and NEW-STATUS
Returns +1 always
CTERM HOST FUNCTIONAL SPECIFICATION Page I-9
CTHSRV'S SIGNIFICANT EXTERNAL REFERENCES
I.4 CTHSRV'S SIGNIFICANT EXTERNAL REFERENCES
I.4.1 DECnet
CTHSRV uses the internal interface to DECnet
as described in [3]
o All DECnet functions
CALL SCTNSF
with T1/ address of SAB
Returns +1 always
o Queue up DECnet link for scheduler level
CALL SCTWKQ
with T1/ link identifier
Returns +1 always
o Dequeue DECnet link
CALL SCTPSQ
with T1/ address of SJB
Returns +1 always with
T1, T2/ PSMOR, PSPSM, PSSTS, PSCHN (DECnet structure definitions)
CTERM HOST FUNCTIONAL SPECIFICATION Page I-10
CTHSRV'S SIGNIFICANT EXTERNAL REFERENCES
I.4.2 TTYSRV
o Get character from TTY output buffer
CALL TTSND with T2/ TDB address
Returns +1 if buffer was empty
Returns +2 if buffer was not empty with T1/ character
Preserves T2
o Store character into TTY input buffer
CALL TTCHI
with T1/ character
T2/ terminal line number
Returns +1 on failure (illegal argument or buffer full)
Returns +2 on success
o Do carrier off action
CALL NTYCOF with T2/ line number
Returns +1 always
Preserves T2
o Deallocate TTY dynamic data block
CALL TTYDE0 with T2/ TTY line number
Returns +2 always
Preserves T2
o Lock TDB
CALL TLOCK
with T2/ TTY line number
Returns +1 on failure with T1/ error
Returns +2 on success with T2/ TDB address
o Unlock TTY dynamic data block
CALL ULKTTY with T2/ TDB address (locked via TLOCK)
Returns +1 always
o Flush output
CALL TTCBF9 with T2/ TDB address
Returns +1 always
CTERM HOST FUNCTIONAL SPECIFICATION Page I-11
CTHSRV'S SIGNIFICANT EXTERNAL REFERENCES
o Get PSI code
CALL GPSICD with T1/ character
Returns +1 always with T1/ PSI code or -1.
o Give PSI
CALL TTPSI2 with
T2/ TDB address
T3/ PSI code
Returns +1 always
o Get TDB address
CALL STADYN
with T2/ TTY line #
Returns +1 on failure
Returns +2 on success with T2/ TDB address
CTERM HOST FUNCTIONAL SPECIFICATION Page I-12
DOCUMENTATION
I.5 DOCUMENTATION
The Monitor Calls Reference Manual must be modified to reflect the
new CTERM specific functions of the MTOPR% jsys, as described above.
***********
A section will be added to chapter 2 of the Monitor Calls User's
Guide. This section will tell users how to improve performance while
using BIN, PBIN, and SIN JSYS's by setting the wake-up mask (using an
MTOPR). By default the mask causes the monitor to wake up the program
on every character; restricting it so the monitor wakes up the
program as seldom as possible will have a significant effect of the
performance of programs running on CTERM terminals.
***********
I.6 SYSTEM IMPACT
If past analyses are accurate, then the average active terminal
sends 1/2 character per second of input to the processor, and accepts
20 characters per second of output. Also, the average size of a read
is 5 characters and the average size of a write is 50 characters. A
CTERM read requires two DECnet messages, a CTERM write requires one.
There are also messages exchanged for control of the terminal
characteristics and out-of-band characters. These events I estimate
would happen at once every four seconds. Under these assumptions, the
demands of a single active CTERM user on DECnet would be 51 messages
per minute.
I.7 COMPATIBILITY
Any system which can establish a DECnet link to a TOPS20 system,
and implements the server end of the CTERM protocol, will be able to
communicate with the TOPS20 host. Any terminal connected in such a
manner will behave as if it were connected directly to the TOPS20
host. This compatibility also results from adherence to the CTERM
protocol ([1] and [2]).
CHAPTER II
CTERM HOST DESIGN SPECIFICATION
CTERM HOST DESIGN SPECIFICATION Page II-2
DESIGN OVERVIEW
II.1 DESIGN OVERVIEW
The structure of the design is highly influenced by the CTERM
architecture document [1]. Much of the terminology is taken from
there. The foundation layer of the terminal services architecture
deals with the primitive terminal handling services: connection
management, changing modes (breaking back to the server system, or
changing to another higher level protocol) and physical and logical
terminal characteristics. CTERM is a protocol built on the foundation
layer, and stands for "network command terminal". Potentially, there
could be several different protocols built on the foundation layer,
(eg, a "forms" protocol) A program which knew different protocols
could run, say, CTERM. If the user wished to, s/he would use the
switch sequence to get back to the foundation layer, and then connect
to a node using the "forms" protocol. The CTERM protocol deals with:
out-of-band input, normal input, output, echoing of input, input
editing characters, escape sequence recognition, and coordination of
echoing and output.
A CTERM terminal runs at clock level and at process level. Clock
level handles all DECnet events (incoming messages,
connect/disconnect), all terminal output to the remote terminal, and
allocation/deallocation of terminals. Process level sets terminal
characteristics (by sending DECnet messages to the server), and reads
the local CTERM data base. Since received DECnet messages are
processed at clock level, and cannot be processed until the entire
message has been received, there must be one input buffer per DECnet
link, since a message may consist of multiple segments. Process level
sends CTERM protocol messages and reads the local CTERM data base. A
global interlock is used to coordinate process level and clock level,
and is described in the algorithms section.
Sent DECnet messages are only one segment in length, and the send
function is only attempted if NSNDR (normal data request available) in
that link's status is set. If the output should happen to not
complete, (because there are no system buffers) it will be retried at
scheduler level; scheduler level only handles one such "blocked
link", thus if there is one "blocked link", no other DECnet output
will occur. Since there are no system buffers, no output can be done
anyway. Consequences of these decisions are: simpler lock/unlock
mechanism, one output message buffer per system simpler scheduler
level, and one SAB per system.
CTERM HOST DESIGN SPECIFICATION Page II-3
LAYERING
II.2 LAYERING
CTHSRV is divided into three layers: DECnet, Foundation, and
CTERM.
DATA FLOW is in both directions:
N ----- DECnet layer ----- Foundation layer ----- CTERM layer ----- TTYSRV
E
T
W
O
R
K
FLOW OF CONTROL:
N <---> DECnet layer <---> Foundation layer <---> CTERM layer <---> TTYSRV
E | |
T V ^
W | (for TTY allocation) |
O +----------->--------------------------+
R
K
The DECnet layer takes care of receiving and sending DECnet
messages, managing DECnet connections, and keeping a listening link
available for incoming DECnet connections.
The foundation layer takes care of receiving and sending CTERM
messages, and managing CTERM connections, which involves
allocation/deallocation of CTERM terminals.
The CTERM layer translates TTYSRV requests into CTERM protocol,
sending CTERM messages to the server, and changes the state of the TTY
according to CTERM messages received from the server.
CTERM HOST DESIGN SPECIFICATION Page II-4
NAMING CONVENTIONS
II.3 NAMING CONVENTIONS
All local routine names have a three letter prefix defining which
layer the routine is in.
o MSG - DECnet layer
o FND - Foundation layer
o CTM - CTERM layer
All global routine names begin with "CTH".
CTERM HOST DESIGN SPECIFICATION Page II-5
DATA BASE
II.4 DATA BASE
II.4.1 Per terminal
The per terminal data base is called the CTERM data block (CDB)
and is referenced by the BEGSTR CH.
o CHIMB - address of incoming message buffer
o CHUID - unique id. used for stale detection.
o CHCO1 - CCOC bits last sent to server (word 1)
o CHCO2 - CCOC bits last sent to server (word 2)
o CHBR1 - Break mask last sent to server (word 1)
o CHBR2 - Break mask last sent to server (word 2)
o CHBR3 - Break mask last sent to server (word 3)
o CHBR4 - Break mask last sent to server (word 4)
o CHRFL - Last start-read flags sent to server
o CHLIN - TOPS20 TTY number
o CHCHL - DECnet channel number
o CHINC - Count of bytes in input buffer
o CHSTS - Current status of DECnet link
o CHSTA - Current CTERM state for this TTY.
o CHSSZ - Maximum protocol message size.
o CHMAX - Maximum input buffer length.
o CHRLN - START-READ length
o CHRDA - A read request is active in the server.
o CHMRD - There is input data available in the server
o CHSSD - Set "do not discard" in the next write message
o CHDSO - Discard output (control-O is in effect)
o CHRCX - CR-LF forced on in server's break mask
o CHCLI - Clear input buffer
o CHASR - Send another START-READ
o CHEDT - Remote server supports continuation reads.
o CHCTM - A CTERM INITIATE message has been seen.
CTERM HOST DESIGN SPECIFICATION Page II-6
DATA BASE
II.4.2 System wide
o MSGOMB - byte pointer to the outgoing DECnet message buffer
o MSGOMC - count of space left in outgoing DECnet message
buffer
o MSGOMP - current pointer into outgoing DECnet message buffer
o CTHSAP - address of the CTERM SAB (used for calling DECnet)
o CTHCHP - address of the DECnet channel-to-CDB address table
o MSGBLW - CDB address of the terminal which caused the output
blockage or 0 if no blockage. CHSOQ - The bit map of queued
TTYSRV requests.
o MSGCWL - The number of links in listen state (0 or 1).
o CTMUID - The next unique id to be used by a CDB allocation.
o CTMLOK - The CTERM lock
o LKFRK - The fork index of the last locker of CTMLOK.
o LOKPC - The PC of the last caller of LOKCDB.
CTERM HOST DESIGN SPECIFICATION Page II-7
DATA BASE
II.4.3 Interconnections in the data base
TDB CDB CTHCHP (indexed by DECnet channel #)
+-------+ +-------+ +------+
| TTDEV |----> | CHCHL |----> | |
| | <----| CHLIN | <--- | |
+-------+ +-------+ +------+
CTERM HOST DESIGN SPECIFICATION Page II-8
ALGORITHMS
II.5 ALGORITHMS
II.5.1 Locking, Blocking and Revalidation.
When process level wishes to send a CTERM message to the server,
it must acquire the interlock. The interlock is CTMLOK, MSGBLW=0, and
NSNDR positive for that link. MSGBLW=0 is needed to guarantee access
to the CTERM output message buffer.
If the interlock is not acquired, the process must unlock the TDB
and wait. When the process is finished waiting, then it must reverify
that the terminal/CDB is the same as when it started. The
verification: the TTY number, and the CDB unique id (field CHUID) are
saved before the terminal is unlocked. Upon completion of waiting,
the terminal is locked, checked for being active. If it is active,
and there is a CDB, the CDB unique id is checked to see if it is the
same as the saved one. If all these tests are passed, then the
verification has succeeded, otherwise it has failed.
The clock level routine is always called with CTMLOK locked. If
the clock level routine wishes to send a CTERM message to the server
it also checks for MSGBLW=0, and NSNDR positive for that link. If
those two conditions are not satisfied, it does not service the
request at that time.
CTERM HOST DESIGN SPECIFICATION Page II-9
ALGORITHMS
II.5.2 Making a connection
In the DECnet callback routine, MSGINT, connect attempts are
detected, queued up (on the "DECnet event queue) for examination at
scheduler level, and the count of listeners (MSGCWL) is decremented.
Clock level (routine CTMCLK) checks the count of listeners
(MSGCWL), and starts another if needed (routine MSGPAS - this includes
allocating a CDB, and making an entry in CTHCHP). If the DECnet event
clock has expired, (cell CTMCLI), it processes all DECnet links on the
DECnet event queue. If the state of a link is "connect received",
then the foundation layer is called (routine FNDCON) to allocate a
TDB. TTPRM (in the TDB) is set, so that the TDB will not be
deallocated before CTHSRV has as chance to clean up its data base (the
DECnet link, the CDB, and the pointer to the CDB in CTHCHP). If the
allocation fails, then the connection is rejected, and a BUGINF is
generated. If the allocation succeeds, then the connection is
accepted, and the CTERM state (CHSTA in the CDB) is set to .STINI
(initializing), and output service is requested for this line (routine
CTMSRV). When the output request is serviced (routine CTMSOT), it
dispatches on the CTERM state:
o .STINI - request sending of foundation BIND-REQUEST
o .STFND - foundation started
o .STRUN - run state
o .STSHU - request shutdown
If the state is .STINI, a BIND-REQUEST foundation message is sent
to the server.
Later, a DECnet message will arrive for this link. It should be a
BIND-ACCEPT. If so, the CTERM state is changed to .STFND, and output
service is requested for this line. If not, it is a protocol error.
If the state is .STFND, a CTERM INITIATE message is sent to the
server, and the state is set to .STRUN, and a control-C is fed to
TTYSRV to start up a job.
At some time, another DECnet message will arrive. If the message
type is "common data", then the CTERM message(s) are passed to the
CTERM layer (routine CTMGET - note that several CTERM messages may be
contained in one foundation message). CTMGET dispatches on CTERM
message type. If the message type is "initiate", then the CHCTM bit
in the CDB is checked. It should be zero. (if not, protocol error).
It is then set.
CTERM HOST DESIGN SPECIFICATION Page II-10
ALGORITHMS
II.5.3 State diagram
(connect (BIND-ACCEPT
received) received)
o ----------> .STINI -------------> .STFND --------> .STRUN
[accept connection] [send CTERM
[send BIND-REQUEST] INITIATE]
CTERM HOST DESIGN SPECIFICATION Page II-11
ALGORITHMS
II.5.4 Breaking a connection
If, at any time, protocol is violated - by being in the wrong
CTERM or foundation state, or by receiving a larger than expected
message, the connection is broken and the terminal resources are
freed. The DECnet link is released, the CDB is deallocated, the entry
in CTHCHP is cleared, and the TDB is released, by clearing TTPRM,
calling NTYCOF, and calling TTYDE0.
If the terminal is detached, TTYDE0 calls CTHSRV (TDCALL CTHLGO),
which sets the CTERM state to .STSHU (shutting down), and queueing the
the line for output service. The request is serviced as above.
CTERM HOST DESIGN SPECIFICATION Page II-12
ALGORITHMS
II.5.5 Sending CTERM messages to the server
When a CTERM protocol message needs to be sent, from process
level, CTMLOK is locked, MSGBLW is checked to be 0, and NSNDR (normal
data request available) is checked for that link. If NSNDR is not
positive, try it later. (block if at process level, try next
iteration if at clock level) If NSNDR is set, build the CTERM message
in the system CTERM output buffer and send it to the server.
When a CTERM message needs to be sent from clock level, the CTERM
state of the line is set to the appropriate value, and the appropriate
bits in the CDB are lit, as needed, and the line is queued for service
by calling routine CTMSRV.
If the message is not completely sent (no more system buffers), it
becomes the blocked message and will be retried every time clock level
runs, until it is sent, or the DECnet link goes out of run state.
While there is such a blocked message, no other output will be
attempted; note that no other output could be sent anyway. MSGBLW
will contain the address of the CDB of the terminal which caused the
blockage, or 0 if there is no blockage.
II.5.6 Receiving CTERM messages from the server
All received CTERM messages are processed by the clock level
routine. Since a received message may be multiple segments, it is
copied into a per link buffer (pointed to by CHIMB in the CDB). When
the DECnet end-of-message flag is detected, the message is passed to
the foundation layer.
II.5.7 Requesting TTY input from the server
When the TOPS20 TTY input buffer is empty and data is needed,
CHRDA ("read in progress") in the CDB is checked. If it is on, and
the break mask has not changed since the last START-READ message was
sent to the server, there is nothing to do. If CHRDA is on, and the
break mask has changed, an UNREAD is issued, and then a new START-READ
message is sent. If CHRDA is off, send a START-READ message to the
server with the TERMINATOR-SET field being the TTY break mask, (except
that CR, LF are always set in the TERMINATOR-SET field) and set CHRDA
for that TTY. But before any START-READ is issued, send any changes
to the CCOC words to the server, and check to see if output is active
(TTOTP in the TDB). If output is active, do not issue the START-READ.
Instead set CHASR and request service. The request will be serviced
by clock level, when output is no longer active.
There is anonther way to cause a START-READ message to be sent to
the server - the .MOTXT MTOPR% - which lights some flags in the
START-READ message to tell the server to do input editing. The input
editing done in the server is handling DELETE, and control-W (delete
CTERM HOST DESIGN SPECIFICATION Page II-13
ALGORITHMS
word). Control-U (delete line) and control-R (redisplay line) are not
done in the server, because TOPS20 can do multiple line reads, and in
that case, control-U and control-R must be handled by the host. The
.MOTXT MTOPR% will not send a START-READ message if any of the
following are true:
o There are characters in the TTY's input buffer (TTICT in TDB)
o A BKJFN% has been done (TTRFG in TDB)
o The last character read (TYLCH in TDB) is carriage return and
TT%DAM is not binary.
II.5.8 Receiving TTY input from the server
When the server has TTY input to give to the host, it sends it in
a CTERM read message. The received message is processed by clock
level, passed up through the foundation layer to the CTERM layer
routine CTMRRD, which puts the characters into the terminal's input
buffer. If the termination reason is not "unread", the "read in
progress" flag in the CDB (field CHRDA) is cleared. If the
termination reason is "unread", another START-READ message will have
been sent to the server. If the termination reason is "underflow",
then a DELETE is fed to TTYSRV.
Echoing is done by the server, and thus must be disabled in
TTYSRV; this is accomplished by setting CHTCI in the CDB when feeding
characters to TTYSRV (in routine CTMRDO). During the feeding, CTERM
is locked and the routine is NOSKED. TTYSRV will use the CTHOOE
TDCALL to read this bit.
If CTMRDD detects that the read was terminated for reasons other
than that specified by the originator (i.e., input buffer full, break
on CR/LF and user's break mask did not contain CR/LF), it causes
another read request to be sent. (by setting CHASR in the CDB, and
requesting service from clock level) If the read was terminated due to
underflow, CTMRDD puts a DELETE into the terminal's input buffer.
II.5.9 Sending TTY output to the server
When TTYSRV wants TTY output to be sent to the terminal, the
request is flagged by setting TTOTP in the TDB and requesting service
from clock level. A CTERM write message is built using characters
from the TTY output buffer, and sent to the server.
CTERM HOST DESIGN SPECIFICATION Page II-14
ALGORITHMS
II.5.10 SIBE%
This implementation does not keep exact track of the number of
characters in the server's input and preinput buffers - but it does
track whether the input and preinput buffers are nonempty.
II.5.11 TEXTI% and RDTTY%.
The routine RCOMN, which handles both JSYSs has been taught about
CTERM terminals. In its initialization, it will decide if the input
JFN is a CTERM terminal, by using the .MOCTM function, and will flag
that fact. If so, before each BIN% (in routine RDBIN), the .MOTXT
MTOPR% will be invoked.
CTERM HOST DESIGN SPECIFICATION Page II-15
ALGORITHMS
II.5.12 TDCALLs and MTOPR% routines
For the most part, these routines are obvious translations into
CTERM messages or allocating/deallocation routines. Exceptions:
1. CTHPPC - Change pause/unpause characters. There is no analog
in CTERM, so this just sets the characters to be out of band
for the server; character, when received, is passed to
TTYSRV, which will do the right thing. Exception: if the
characters are S and Q, there is CTERM protocol to tell the
server. The default pause/unpause character is A.
2. CTHCKI - Get input buffer character count. This routine will
say if whether or not any characters are in the server's
input buffer, and pretends there is at most one character.
CTERM HOST DESIGN SPECIFICATION Page II-16
TESTING
II.6 TESTING
This program will be tested by running it against the TOPS20 CTERM
server, and the VMS CTERM server using TOPS20 programs that use the
terminal in different ways. The programs will include: the EXEC,
OPR, screen editors (EMACS, VTECO, TV, SED, EDT) MS, PTYCON, WINDOW,
DDT, SYSDPY.
CTERM-SERVER-FUNCTIONAL-AND-DESIGN.SPECIFICATION
CTERM Server Functional and Design Specification
Date: 13-Jul-84
Author: Mark McIntee
CTERM Server Functional and Design Specification Page 2
Table of Contents
CHAPTER I CTERM SERVER FUNCTIONAL SPECIFICATION
I.1 PREFACE . . . . . . . . . . . . . . . . . . . . . . 3
I.2 REFERENCES . . . . . . . . . . . . . . . . . . . . . 3
I.3 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . 3
I.4 AT THE SYSTEM LEVEL . . . . . . . . . . . . . . . . 5
I.5 AT THE USER LEVEL . . . . . . . . . . . . . . . . . 7
I.6 PERFORMANCE . . . . . . . . . . . . . . . . . . . . 7
I.7 COMPATIBILITY . . . . . . . . . . . . . . . . . . . 7
CHAPTER II CTERM SERVER DESIGN SPECIFICATION
II.1 DESIGN OVERVIEW . . . . . . . . . . . . . . . . . . 8
II.1.1 Pictures . . . . . . . . . . . . . . . . . . . . . 9
II.1.2 Initialization . . . . . . . . . . . . . . . . . 10
II.1.3 DECnet Layer . . . . . . . . . . . . . . . . . . 10
II.1.4 Foundation Layer . . . . . . . . . . . . . . . . 10
II.1.5 CTERM Layer . . . . . . . . . . . . . . . . . . 10
II.1.6 Preinput Process . . . . . . . . . . . . . . . . 10
II.1.7 Input Process . . . . . . . . . . . . . . . . . 11
II.1.8 Output Process . . . . . . . . . . . . . . . . . 11
II.1.9 Timer Process . . . . . . . . . . . . . . . . . 11
II.1.10 Debug process . . . . . . . . . . . . . . . . . 12
II.1.11 Message Templates . . . . . . . . . . . . . . . 13
II.1.12 Macros . . . . . . . . . . . . . . . . . . . . . 13
II.2 FLOW . . . . . . . . . . . . . . . . . . . . . . . 15
II.3 CAVEATS . . . . . . . . . . . . . . . . . . . . . 16
II.4 NAMING CONVENTIONS . . . . . . . . . . . . . . . . 18
II.5 DATA BASES . . . . . . . . . . . . . . . . . . . . 19
II.5.1 CTERM characteristics . . . . . . . . . . . . . 19
II.5.2 PSI system . . . . . . . . . . . . . . . . . . . 22
II.5.3 Terminal . . . . . . . . . . . . . . . . . . . 23
II.5.4 Preinput process . . . . . . . . . . . . . . . . 25
II.5.5 Input process . . . . . . . . . . . . . . . . . 26
II.5.6 Output process . . . . . . . . . . . . . . . . . 28
II.5.7 DECnet layer . . . . . . . . . . . . . . . . . . 29
II.5.8 Debug process . . . . . . . . . . . . . . . . . 30
II.5.9 Timer process . . . . . . . . . . . . . . . . . 31
II.6 ALGORITHMS . . . . . . . . . . . . . . . . . . . . 32
II.6.1 Character attributes and the preinput process . 32
II.6.2 Input process . . . . . . . . . . . . . . . . . 34
II.6.2.1 Starting a read . . . . . . . . . . . . . . . 34
II.6.2.2 Terminal data available . . . . . . . . . . . 36
II.6.2.3 Termination of a read . . . . . . . . . . . . 37
II.6.3 Output process . . . . . . . . . . . . . . . . . 38
II.6.4 Timer process . . . . . . . . . . . . . . . . . 40
II.7 TESTING . . . . . . . . . . . . . . . . . . . . . 41
CHAPTER I
CTERM SERVER FUNCTIONAL SPECIFICATION
I.1 PREFACE
CTERM is a protocol used to communicate between terminals and
operating systems. The protocol is layered on DECnet, and is defined
in [1] and [2]. CTERM is a protocol by which terminals on one
computer may connect to other computers. TOPS-20 may serve both as
host to other systems' terminals and as server for its own terminals
to do processing on other systems which have implemented the CTERM
protocol using DECnet. This specification describes the
implementation of the server end of the CTERM protocol in TOPS-20.
I.2 REFERENCES
[1] Digital Terminal Software Architecture Network Command
Terminal Specification, Version 1.4, Leland Webber,
George Conant, Henry Lowe, and Chuck Jones, 15 February 1984.
[2] Digital Terminal Software Architecture Foundation Services
Specification, Version 2.4, George Conant, Henry Lowe,
and Chuck Jones, 15 February 1984
I.3 GLOSSARY
o CTERM terms
* CTERM terminal - A terminal which communicates with a
processor using the CTERM protocol.
* Host - The end of the CTERM DECnet connection which
processes the user's commands.
CTERM SERVER FUNCTIONAL SPECIFICATION Page I-2
GLOSSARY
* Server - The end of the CTERM DECnet connection to which
the terminal is physically attached.
* CTERM switch sequence - A sequence of two characters used
to momentarily switch control of the terminal back to the
server.
* Hello out of band character - An out of band character
does not affect the server's input stream.
* Hello out of band with copy - An out of band character
which causes an out of band message to be sent to the
host, and also puts a copy of the character into the
server's normal input data stream.
* Clear out of band character - An out of band character
which clears the server's typeahead buffer and terminates
the server's current read (if there is one).
* Deferred out of band character - The same in function as
clear out of band, but consists of two consecutive
identical control characters.
* Prompt and initial data for a read - A host, when it
sends a request for input (START-READ message) may,
optionally, send some data to be preloaded into the input
buffer. The part of the data which is deleteable (by
means of editing characters such as DELETE) is called
initial data; and that which is not deleteable is called
the prompt. An example: A command line (with prompt) is
being typed in, and an ESCAPE is typed in the middle. A
READ message is sent to the host. The host parses the
partial line, completes the field whcih the ESCAPE
terminated, then sends a START-READ message to the server
with the prompt and the partial command line (with the
completed field).
o TOPS20 terms
* CCOC words - The control character output control words:
tell how the characters 0-32. are to be represented on
the terminal. The CCOC words are set by the SFCOC% jsys
and read by the RFCOC% jsys.
* JFN mode word - contains all the program information
about the TTY; the program-related modes (wakeup
control, echo mode, terminal data mode) and the device
parameters (page width, page length, case conversion,
mechanical characteristics).
CTERM SERVER FUNCTIONAL SPECIFICATION Page I-3
AT THE SYSTEM LEVEL
I.4 AT THE SYSTEM LEVEL
The CTERM server in TOPS-20 is a user program called CTERM-SERVER.
The CTERM-SERVER program will handle terminal I/O when TOPS-20 is the
server (ie, the user is logged into TOPS-20 and is connected via
DECnet to another system). CTERM-SERVER accepts output data messages
from DECnet and displays it on the user's terminal, and accepts read
request messages and sends data which the user types to satisfy those
requests. It also formats the data, edits the data, and echoes the
input as requested by the host. The CTERM-SERVER program communicates
with the TOPS-20 monitor via the usual DECnet and terminal JSYSs. See
figure 1.
CTERM SERVER FUNCTIONAL SPECIFICATION Page I-4
AT THE SYSTEM LEVEL
- FIGURE 1 -
THE TOPS-20 CTERM-SERVER PROGRAM
INTERCONNECTIONS OF MONITOR MODULES, PROGRAM, AND TERMINAL
._______
! \
! TTY \
!_________!
!
xxxxxxxxxxxxxxx ! xxxxxxxxxxxxxxxxxxxxxxxx
x .___!_____. x
x ! TTYSRV, ! MONITOR LEVEL x
x !I/O JSYSs! x
x !_________! x
x ! x TOPS-20
x////////////// ! ///////////////////////x
x .___!_____. x
x ! CTERM- ! USER LEVEL x
x ! SERVER ! x
x !_________! x
x ! x
x////////////// ! ///////////////////////x
x .___!_____. x
x ! DECNET ! MONITOR LEVEL x
x ! JSYSs ! x
x !_________! x
x ! x
xxxxxxxxxxxxxxx !/! xxxxxxxxxxxxxxxxxxxxxx
!
! COMMUNICATION LINK
!
xxxxxxxxxxxxxxx !/! xxxxxxxxxxxxxxxxxxxxxx
x .___!_____. x
x ! ! x
x ! DECNET ! x
x !_________! x
x ! x REMOTE HOST
x ._____!___________. x
x ! CTERM HOST/ ! x
x ! TERMINAL DRIVER ! x
x !_________________! x
x ! x
x ._____!___. x
x ! ! x
x ! PROGRAM ! x
x !_________! x
x x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CTERM SERVER FUNCTIONAL SPECIFICATION Page I-5
AT THE USER LEVEL
I.5 AT THE USER LEVEL
At the EXEC prompt, the user types "CTERM-SERVER node-name" to
connect to the desired host, or if the user wishes to use a nondefault
switch sequence, s/he merely types "CTERM-SERVER", and is prompted for
the node name and the switch sequence. The program will attempt to
connect to that host, and if successful, the user's terminal will
appear to be directly connected to that host system. If the user
wants to return to the original system, s/he types the two character
CTERM switch sequence. The program may be continued at this point, in
the usual TOPS-20 manner. The terminal session is ended when the fork
running the program is reset. If the user, while connected to the
host system, wishes to send the first character of the escape sequence
to the host system, s/he must type it twice. If not specified, the
default CTERM switch sequence used is: control-, carriage return.
I.6 PERFORMANCE
If past analyses are accurate, then the average active terminal
sends 1/2 character per second of input to the processor, and accepts
20 characters per second of output. Also, the average size of a read
is 5 characters and the average size of a write is 50 characters. A
CTERM read requires two DECnet messages, a CTERM write requires one.
There are also messages exchanged for control of the terminal
characteristics and out-of-band characters, which are estimated to
occur once every four seconds. Under these assumptions, the demands
of a single active CTERM user on DECnet would be 51 messages per
minute.
I.7 COMPATIBILITY
Using this program, a user on any TOPS-20 system will be able to
use any system as a host provided a DECnet link can be established
between the two systems and the other system implements the host side
of the CTERM protocol. Once connected to that host system, the user's
terminal will behave as if it were connected directly to the host
system. This compatibility results from adherence to the CTERM
protocol ([1] and [2]).
CHAPTER II
CTERM SERVER DESIGN SPECIFICATION
II.1 DESIGN OVERVIEW
The structure of the design is highly influenced by the CTERM
architecture document [1]. Much of the terminology is taken from
there. The foundation layer of the terminal services architecture
deals with the primitive terminal handling services: connection
management, changing modes (breaking back to the server system, or
changing to another higher level protocol) and physical and logical
terminal characteristics. CTERM is a protocol built on the foundation
layer, and stands for "network command terminal". Potentially, there
could be several different protocols built on the foundation layer,
(eg, a "forms" protocol) A program which knew different protocols
could run, say, CTERM. If the user wished to, s/he would use the
switch sequence to get back to the foundation layer, and then connect
to a node using the "forms" protocol. The CTERM protocol deals with:
out-of-band input, normal input, echoing of input, input editing
characters, escape sequence recognition, and coordination of echoing
and output.
After initialization is complete, the program is driven by PSIs
and and the timer. The PSIs are:
o interrupt on switch sequence (two character interrupt).
o interrupt on terminal input buffer nonempty
o interrupt on the out-of-band characters
o interrupt on control-X, if enabled
o interrupt on control-O, if enabled
o interrupt on DECnet data available/disconnect
DECnet interrupt, and terminal input buffer nonempty interrupt are at
level 3, out-of-band characters (including control-O and control-X)
are at level 2, and the two character switch sequence interrupt is at
level 1. Interlocking is accomplished by turning off interrupts while
in interrupt routines; exception is during the data available
interrupt routine while doing a TEXTI% or PBIN% which may block due to
deferred interrupt characters.
In addition, in the DECnet interrupt handler, interrupts are
turned back on, in between processing messages. The timer process
runs at normal level, and also uses turns off the interrupt system
when it isn't sleeping.
CTERM SERVER DESIGN SPECIFICATION Page II-2
DESIGN OVERVIEW
II.1.1 Pictures
DATA FLOW FROM HOST: DATA FLOW TO HOST:
N ---> DECnet ---> Foundation ---> CTERM N <--- DECnet <---- Input
E layer layer layer E layer process
T | T | |
W V W ^ ^
O | O | |
R +-------------------------+ R | .______
K | | K Preinput <---- ! \
V V process ! TTY \
| | !________!
Output <------------- Input
process (for prompt) process
| (and initial)
V (data)
|
.______
! \
! TTY \
!________!
FLOW OF CONTROL
NETWORK
| |
V ^
| |
DECnet <----+----<---------+------<---------------+
layer | | |
| ^ ^ ^
| | | |
| Output <----- Preinput <-------+ |
| process process | |
V | ^ | | |
| ^ | V | ^
Foundation | +-. | ^ |
layer | \ | | |
| | \ | .______ |
V | \ | ! \ |
| CTERM \ Input ! TTY \ |
+-----> layer -----> process <---- !________! ^
| | | | |
| | ^ V |
| | | | |
| | Timer |
| | process |
| | |
V V |
| | |
+-->----------+--->--------------------+
CTERM SERVER DESIGN SPECIFICATION Page II-3
DESIGN OVERVIEW
II.1.2 Initialization
The initialization consists of making the DECnet connection to the
host, and exchanging the foundation protocol initialization messages,
and the CTERM protocol initialization messages. At each stage, the
program waits for a response (the PSI system is not turned on).
II.1.3 DECnet Layer
The DECnet layer handles incoming messages and disconnects (by
PSI), outgoing messages (by request) and the connect (in the
initialization). The incoming messages are sent to the foundation
layer.
II.1.4 Foundation Layer
The foundation layer handles all incoming DECnet messages. It
dispatches on foundation message type, the significant types being
BIND, UNBIND, MODE-DATA, and COMMON-DATA. BIND is taken care of in
the initialization. UNBIND means that the host wants to break off the
session. MODE-DATA and COMMON-DATA mean the same - each of the DATA
fields is a CTERM message. Each such CTERM message is extracted from
the foundation message and sent to the CTERM layer.
II.1.5 CTERM Layer
The CTERM layer handles incoming CTERM messages. It dispatches on
the CTERM message type, and parses the CTERM message. It changes and
reads the characteristics data base (described in the DATA BASES
section) and calls the input and output processes as needed.
II.1.6 Preinput Process
This differs from the preinput process as modeled in the
architecture, because some of the architecture's model is implemented
in the TOPS20 monitor. The TOPS20 monitor:
o Maintains the typeahead buffer (the line buffer)
o Decides which characters are out of band, and passes them to
the server program by means of a PSI.
o Recognizes the CTERM switch sequence and gives the server
program a PSI.
o Recognizes the discard output character, control-O, when
enabled, and gives the server program a PSI.
CTERM SERVER DESIGN SPECIFICATION Page II-4
DESIGN OVERVIEW
o Recognizes the clear typeahead buffer character, control-X,
when enabled, and and gives the server program a PSI.
Thus the preinput process in this server program is completely PSI
driven, and does not deal with the normal input data flow, just the
out of bands, control-O, control-X and the switch sequence. It calls
the output process to toggle the output discard state. It calls the
DECnet layer to send OUT-OF-BAND messages to the host. It controls
which characters it is to get a PSI on.
II.1.7 Input Process
The input process in this server program also differs from that
modeled in the architecture, because the TOPS20 monitor handles input
echoing and input editing characters. The input process handles the
start of a read, the processing of a read, and the termination of a
read. A read is started when a START-READ message is received from
the host. The processing of a read is driven by PSI on character
available, and ordinary input, parsing input escape sequences, and
control of the timer. The quote character (control-V) is also handled
here, (not in the TOPS20 monitor), as is the echoing of carriage
return, for reasons described in the Algorithms section, under input
process. The termination of a read involves sending a READ message to
the host, and is done from many places. The input process calls the
output process to display the "prompt and initial data" for a read,
(see glossary).
II.1.8 Output Process
The output process is called from the CTERM layer on reception of
a WRITE message, and sends output to the terminal. It also can "lock
out" input echoing, which means that echoing of input will be
deferred. Discarding output is done here. The output process is
called by the input process for the display of prompt and initial
data. WRITE-COMPLETION messages are sent to the host, if needed.
II.1.9 Timer Process
The timer process implements the TIMEOUT in the START-READ
message. The timer is set and cleared by the input process. The
timer process may call the input process to terminate a read.
CTERM SERVER DESIGN SPECIFICATION Page II-5
DESIGN OVERVIEW
II.1.10 Debug process
If enabled, the debugging mechanism allows gives control of the
terminal back to the user upon typing the debug character. The
debugger commands are:
o CONTINUE - resume the program
o EXIT - exit the program. It is continuable
o HELP - print this text
o LOG {file-spec} - send all tracing to this file.
o SHOW - show all turned on tracing flags, and the logging file
o TRACE {identifier} - trace the collection of events
associated with that identifier:
* ALL
* DDT
* RECEIVED-DECNET-MESSAGES
* RECEIVED-CTERM-MESSAGES
* SENT-DECNET-MESSAGES
* OUT-OF-BANDS
o UNTRACE {identifier} - turn off the tracing associated with
that identifier
The debugger is enabled by depositing a 1 in location "DEBUG",
before running the SERVER. During the program initialization, the
program will start off in the debug command parser, and any time the
two character switch sequence is typed, the control will be returned
to the debugger, not the EXEC. The debugger may also be enabled while
the server is running by typing the two character switch sequence,
depositing a 1 in location DEBUG, and continuing.
CTERM SERVER DESIGN SPECIFICATION Page II-6
DESIGN OVERVIEW
II.1.11 Message Templates
These are a collection of buffers which contain foundation/CTERM
messages, and pointers to the fields in those messages which need to
be filled in. They are used for all outgoing messages.
II.1.12 Macros
1. Instruction macros
o GET1BY - used in parsing a foundation/CTERM message.
Takes three arguments - byte pointer into message, count
of bytes left in message, and result (which must be a
register). It update the pointer and the count.
Nonskippable.
o GET2BY - same as GET1BY, except it gets a 2 byte value
(PDP-11 style). Nonskippable.
o PUT2BY - put a 2 byte value (PDP-11 style) into a CTERM
message. Two arguments - byte pointer into message,
value (which must be a register) Nonskippable.
o $PSOUT - Puts a string out to the terminal. First
argument is byte pointer to string, second is count.
Features: checks for count equal to zero, and puts the
last character in the string in the cell OUPCR. See
discussion on the format flag in the START-READ message.
o $PBOUT - Puts a character out to the terminal, and also
puts it in the cell OUPCR.
o PROERR - used when a protocol error is detected. Takes
one argument - ASCII text of message to be printed out.
Skippable.
o BUGMSG - used to generate a debugging message and
optionally, a string (displayed in ASCII and OCTAL). Two
or four arguments - the name for the debug control bit,
the debugging message, and optionally, the byte pointer
to the string, and the byte count of the string.
Skippable.
o KEYWRD - command parsing macro for keywords. First
argument is keyword table, second is address to go to on
failure. Returns value of keyword (right half of the
corresponding table entry) in T1. Nonskippable.
2. Table generating macros
o DSPGEN - used to generate a dispatch table and the
corresponding offsets. Takes three arguments - prefix
for offsets, prefix for routine names, and the list of
suffixes for the offsets and routines.
o BITIT - used to generate the bit number to bit mask
translation table
CTERM SERVER DESIGN SPECIFICATION Page II-7
DESIGN OVERVIEW
o SWAPIT - used to generate the byte swapping table, needed
for the translation of the terminator set.
CTERM SERVER DESIGN SPECIFICATION Page II-8
FLOW
II.2 FLOW
The host drives the protocol: changes the terminal's
characteristics (CHARACTERISTICS message), starts a read (START-READ
message), starts a write (WRITE message), and queries the server's
data base. The server responds to the host: completes a read (READ
message), completes a write (WRITE-COMPLETION message) and tells its
characteristics (CHARACTERISTICS message).
In this server implementation:
o Incoming DECnet messages are driven by PSI.
o Normal TTY input is driven by PSI, echoing and input editing
are done in the monitor, as a consequence of using the TEXTI%
jsys.
o Out of band TTY input is driven by PSI, echoing is done in
the server, (using the CCOC words, set by SFCOC% jsys).
o An interrupt (IIC%) on the data available channel is
generated when output becomes unlocked and also when a
START-READ message is received.
o disabling control characters is done by clearing the
appropriate bits in the terminal interrupt words.
CTERM SERVER DESIGN SPECIFICATION Page II-9
CAVEATS
II.3 CAVEATS
1. Only control-A through control-Z, ESCAPE, DELETE, and SPACE
can be declared as out-of-band characters. TOPS20 allows
only these characters to be associated with a PSI. Changing
this would be extremely difficult, if not impossible.
2. DELETE can only be echoed in "standard form" (Control-?) when
it is enabled as an out-of-band character. TOPS20 has no
mechanism for controlling this.
3. Hello out-of-band with copy is not implemented. Example:
Suppose that control-T is defined as a hello out of band with
copy, and the characters "A", "B", "control-T", "C" are typed
in when there is no read active (ie, typed ahead). An out of
band message is sent immediately to the host, because of the
control-T. When a read is started, the characters "A", "B",
"control-T", "C" will appear, in order, in the input buffer.
Support for this would require some work in the TOPS20
terminal driver, which is not planned.
4. Character declared as out-of-band will not be quoted if
"typed ahead". The quoting must work synchronously in the
input process, and so must be implemented in the input
process - during processing of the read. If there is no read
active, the out of band interrupt will occur before the quote
has a chance. A solution: the ability to enable control-V
as a "super quote" character, which would turn off all
character terminal interrupts. This would have to be
implemented at the lowest level of the terminal driver of
TOPS20, which is not planned.
5. Hardcopy terminal:
o Display of deleted characters. (ABC<DEL><DEL><DEL> = ABCA\B\C\)
o Display of deleted line (" XXX" followed by CRLF)
o Display of deleted word ("_")
This is the way TOPS20 does it.
6. Softcopy terminal:
o Control-R redisplay will be on the same line.
7. Output-stop-length is always the same as page-length.
8. Vertical tabs are always expanded as 1 LF.
9. The terminator-echo flag is not implemented. Difficult to
change TEXTI% to respect this. Can control terminator
echoing on control characters by the CCOC words (SFCOC%).
CTERM SERVER DESIGN SPECIFICATION Page II-10
CAVEATS
10. Input-count-state messages are sent automatically only on the
transition from zero to nonzero.
11. Control-C, when set up as out of band, will always be a
deferred out of band. That is because the EXEC sets up
control-C as deferred out of band.
CTERM SERVER DESIGN SPECIFICATION Page II-11
NAMING CONVENTIONS
II.4 NAMING CONVENTIONS
All routine names have a three letter prefix defining which
layer/process it is in.
1. MSG - DECnet layer
2. FND - Foundation layer
3. CTM - CTERM layer
4. PRE - Preinput process
5. INP - Input process
6. OUP - Output process
7. TIM - Timer process
8. BUG - Debug process
If the prefix for a set of dispatch routines is "ABC", then the
prefix for the corresponding set of offset values is ".AB".
CTERM SERVER DESIGN SPECIFICATION Page II-12
DATA BASES
II.5 DATA BASES
II.5.1 CTERM characteristics
These are as described in the CTERM and Foundation specs [1], [2],
and are modified and read by the host by means of the CHARACTERISTICS
and READ-CHARACTERISTICS messages. Each characteristic is defined by
its type and identifier. Type is one of: physical, logical, handler.
Identifier is a positive integer. Each characteristic is accessed by
its own routines for reading and writing. These routines are in the
tables xCHy, where x = PHY, LOG, HND, (for physical, logical, handler)
and y = R, W (read, write) Those tables are indexed by identifier, and
are pointed to by the tables ACCESR and ACCESW, which are indexed by
type.
Handler characteristics and their representations:
1. IGNORE-INPUT - word INPIGN, used by input process. When this
is set, all terminal interrupts are turned off, except
terminal input available, and the debug character.
2. CHARACTER-ATTRIBUTES - Implemented only for control
characters, and DELETE. Table OOBCHA (indexed by character)
and word DELCHA. The table entries contain type (none,
clear, deferred clear, hello), include flag, discard flag,
echoing characteristic, and special function flag as defined
in the CTERM spec [1]. It also contains the PSI channel
associated with that out of band (if there is one). Echoing
of control characters is done by setting the CCOC words.
Out-of-band characters are done by enabling terminal
interrupts for those characters. Control-O (discard output),
and control-X (discard typeahead) are also done that way.
The editing characters (control-R, control-U, control-V,
control-W, and DELETE) are enabled/disabled by using TEXTI%
options in the input process.
3. CONTROL-O PASSTHROUGH - Always false. Meaning: Control-O is
to be passed through as a normal data character as well as
performing its normal control function.
4. RAISE INPUT - TT%LIC bit in the JFN mode word
5. NORMAL-ECHO - TT%ECO bit in the JFN mode word
6. INPUT-ESCAPE-SEQUENCE-RECOGNITION - word CHRIEX, used by the
input process. ESCAPE's echo is turned off in the CCOC
words, and is a break character for the TEXTI%. All echoing
is turned off during the parsing of an input escape sequence.
7. OUTPUT-ESCAPE-SEQUENCE-RECOGNITION - word CHROEX, used by the
output process.
CTERM SERVER DESIGN SPECIFICATION Page II-13
DATA BASES
8. INPUT-COUNT-STATE - word CHRICT, used by the input process.
9. AUTO-PROMPT - word CHRATP, used by the input process.
Meaning: A control-A is sent to the terminal after the
prompt, before the read starts.
10. ERROR-PROCESSING - errors are always ignored.
Logical characteristics and their representations:
1. MODE-WRITING-ALLOWED - Always true. Meaning: The physical
and logical characteristics may be changed.
2. TERMINAL-ATTRIBUTES - GTTYP% translation. Not settable.
Meaning: The only current terminal attribute is
video/hardcopy.
3. TERMINAL-TYPE - GTTYP% translation. Not settable. Meaning:
This is a string which is the terminal's name (VT100, LA36,
etc.)
4. OUTPUT-FLOW-CONTROL - TT%PGM bit in JFN mode word. Meaning:
An XOFF on input stops output, and an XON on input resumes
it.
5. OUTPUT-PAGE-STOP - MTOPR%, .MOXOF function. Meaning: The
end of a page stops output, and an XON on input resumes it.
6. FLOW-CHARACTER-PASS-THROUGH - Always false. Meaning: the
XON/XOFF character is sent through as input.
7. INPUT-FLOW-CONTROL - Always false. Meaning: An XOFF is sent
to the terminal when resources are short.
8. LOSS-NOTIFICATION - Always true. Meaning: A BEL is sent to
the terminal if an input character is dropped.
9. LINE-WIDTH - MTOPR% functions .MORLW and .MOSLW and word
LINWID (used when WRAP characteristic is 1, see below)
10. PAGE-LENGTH - MTOPR% functions .MORLL and .MOSLL
11. STOP-LENGTH - MTOPR% functions .MORLL and .MOSLL
12. CR-FILL - Always 0 Meaning: The number of nulls sent to the
terminal after a CR is written
13. LF-FILL - Always 0 Meaning: The number of nulls sent to the
terminal after a LF is written
CTERM SERVER DESIGN SPECIFICATION Page II-14
DATA BASES
14. WRAP - Word LINWRP. Always 1 or 3 - No wrap OR hardware is
wrapping and SERVER is attempting to track (using RFPOS%)
Meaning: A CRLF is sent to the terminal when the line width
is exceeded.
15. HORIZONTAL-TAB - Always 1 - Hardware is handling and SERVER
is attempting to track (uses RFPOS%)
16. VERTICAL-TAB - Always 1 - Hardware is handling and SERVER is
attempting to track (uses RFPOS%)
17. FORM-FEED - Always 1 - Hardware is handling and SERVER is
attempting to track (uses RFPOS%)
The physical characteristics and their representations:
1. INPUT-SPEED - MTOPR% functions .MORSP and .MOSPD
2. OUPUT-SPEED - MTOPR% functions .MORSP and .MOSPD
3. PHYSICAL-CHARACTER-SIZE - Always 7
4. PARITY-ENABLED - Always false
5. PARITY-TYPE - N/A (always 0)
6. MODEM-PRESENT - Always false
7. AUTO-BAUD-DETECT - Always false
8. MANAGEMENT-GUARANTEED - Always true. Meaning: The user is
guaranteed that the SWITCH characters always work.
9. SWITCH-CHARACTER-1 - MTOPR% functions .MOTCE and .MORTC.
Meaning: The first character of the two character switch
sequence that enables the user to break back to the terminal
10. SWITCH-CHARACTER-2 - MTOPR% functions .MOTCE and .MORTC.
Meaning: The second character of the two character switch
sequence that enables the user to break back to the terminal
11. EIGHT-BIT - Always false. Meaning: This is an eight bit
terminal.
12. MANAGEMENT-ENABLED - Always true. Meaning: The switch
characters are enabled.
CTERM SERVER DESIGN SPECIFICATION Page II-15
DATA BASES
II.5.2 PSI system
1. PSIPTR - Pointer to the free PSI channel list.
2. PSITAB - Table of allocatable PSI channels
3. OOBTAB - The table containing the interrupt handling routine
and associated PSI channel (if enabled) indexed by character,
for the characters from 0 to 31.
4. DELTAB - The word containing the interrupt handling routine
and associated PSI channel (if enabled) for delete
5. CHNTAB - The PSI channel table
6. LEVTAB - The PSI level table
7. LEV1PC, LEV2PC, LEV3PC - storage for PC on interrupt of the
three levels.
Note that some channels are preallocated: DECnet event, terminal
input available, switch sequence.
CTERM SERVER DESIGN SPECIFICATION Page II-16
DATA BASES
II.5.3 Terminal
The information needed to restore the terminal to its original
state when the program exits.
1. OLDCOC - CCOC words
2. OLDRFM - JFN mode word
3. OLDMOD - Pause on end of page mode
4. OLDWID - line width
5. OLDLEN - page length
6. OLDRTI - terminal interrupt mask for this process
7. OLDRTJ - job wide terminal interrupt mask
8. OLDSWI - Two character switch sequence
9. OLDTYP - Terminal type
The information needed to restore the terminal to its CTERM state
when the program reenters.
1. CTMCOC - CCOC words
2. CTMRFM - JFN mode word
3. CTMMOD - Pause on end of page mode
4. CTMWID - line width
5. CTMLEN - page length
6. CTMRTI - terminal interrupt mask for this process
7. CTMRTJ - job wide terminal interrupt mask
8. CTMSWI - Two character switch sequence
9. CTMTYP - Terminal type
Permanent data
o TTYTBL - TBLUK% table translating terminal names to TOPS20
terminal type,
o TRMTAB - Table of terminal characteristics, indexed by TOPS20
terminal type, described by the BEGSTR TM.
CTERM SERVER DESIGN SPECIFICATION Page II-17
DATA BASES
o TRMSTB - Table of terminal names, indexed by TOPS20 terminal
type
o TRMTYP - This terminal's type. (GTTYP%)
o TRMCHA - This terminal's characteristics.
CTERM SERVER DESIGN SPECIFICATION Page II-18
DATA BASES
II.5.4 Preinput process
1. OOBCHA - indexed by character, holds the character attributes
for all control characters
2. DELCHA - holds the character attributes for DELETE.
The character attributes are:
BEGSTR OB
FILLER ^D29 ;right justify
FIELD SPC,1 ;Special flag
FIELD ECH,2 ;Control character echoing characteristics
FIELD DSC,1 ;Output discard state flag
FIELD INC,1 ;Include flag
FIELD OOB,2 ;Out of band type
ENDSTR
CTERM SERVER DESIGN SPECIFICATION Page II-19
DATA BASES
II.5.5 Input process
State variables:
1. INPIGN - ignore input. If this is nonzero, throw away all
input. This takes precedence over the state variable, INPSTA
2. INPSTA - the state of the input process - ordinary, parsing
input escape sequence, quote in progress, single character
read (.INORD, .INESC, .INQOT, .INBIN)
Fields from the START-READ message:
o INPFLG - Flags described by the BEGSTR RD:
* RDRAI - raise input
* RDCON - continuation read
* RDVTF - terminate on vertical change
* RDFMT - Format flag: special LF/CR handling. See
Algorithm section.
* RDCLT - Clear typeahead
* RDUND - Underflow
* RDTRM - non-default terminator
* RDTIM - timeout
* RDTEC - echo terminator
* RDNEC - no-echo
* RDDCD - disable control definition
* RDESS - escape sequence recognition
o INPLEN - MAX-LENGTH
o INPEOD - END-OF-DATA
o INPTIM - TIMEOUT
o INPEOP - END-OF-PROMPT
o INPSOD - START-OF-DISPLAY
o INPLOW - LOW-WATER
o INPTBM - TERMINATOR-SET
o INPBPT - DATA-POINTER
o INPBCT - DATA-COUNT
Information needed during a read:
1. INPQOT - "quote character enabled" flag (control-V).
2. INPBLK - the TEXTI% argument block.
3. INPLEN - the maximum length of the input buffer for this read
4. INPTMO - the timeout enabled flag
5. INPTIM - the input timeout interval
CTERM SERVER DESIGN SPECIFICATION Page II-20
DATA BASES
6. INPUND - "terminate on underflow" flag
7. INPRAI - "restore raise after read completes" flag
8. INPECH - "restore echo after read completes" flag
9. INPCTL - "enable control characters after read completes"
flag
10. INPTIW - the terminal interrupt words to reenable control
characters
11. INPTBM - the terminator set specified in the START-READ
message
12. INPXBM - the break mask for the TEXTI%, pointed to by the
TEXTI% argument block, and equals the boolean expression:
(INPTMB or INPUBM) and not INPEBM
Explained in the Alogorithm section under the input process.
13. INPUBM - the "unediting" break mask. All editing characters
that are disabled.
14. INPEBM - the "editing" break mask. All editing characters
that are enabled. This is to make sure that no enabled
editing characters are in the TEXTI% break mask, since if
they are, they won't have their editing functions.
15. INPUNV - the "universal" terminator set (constant)
16. INPESR - input escape sequence recognition enabled for this
read
17. INPSEE - a character has been seen during this read
The input escape parsing variables.
1. ESCSTA - State of the parse
2. ESCBUF - Pointer to start of input escape sequence buffer
3. ESCMAX - Size of input escape sequence buffer in bytes
4. ESCPTR - Pointer into input escape sequence buffer
5. ESCCNT - Count of bytes left in input escape sequence buffer
6. ESCMOD - The saved JFN mode word at the start of the parse.
CTERM SERVER DESIGN SPECIFICATION Page II-21
DATA BASES
II.5.6 Output process
* WRFLAG - Flags from received WRITE message described by
BEGSTR WR.
* OUPSKP - Skip-next-line-feed flag
* OUPCR - Last character sent to terminal OR 0 if it wasn't CR.
* FREELF - Free LF was supplied by TOPS20.
* OUPIPT - Point to queued input data
* OUPICT - Negative count of queued input data
* OUPLCK - Output is locked against echoing.
* OUPDS1 - Requested output discard state
* OUPDS2 - Real output discard state
Fields from the WRITE message that are set up on each WRITE
message
* OUPBOM - beginning of message
* OUPEOM - end of message
* OUPBPT - pointer to data
* OUPBCT - byte count of data
* OUPOUT - set real and requested output state to "do not
discard"
Fields from WRITE message that are set up only when OUPBOM is
true.
1. OUPLOK - Lock definition
2. OUPNWL - Newline flag
3. OUPPFX - Prefix code
4. OUPPFC - Prefix character/count
5. OUPPSX - Postfix code
6. OUPPSC - Postfix character/count
7. OUPCMP - Completion status requested
8. OUPTRN - Transparent output
CTERM SERVER DESIGN SPECIFICATION Page II-22
DATA BASES
II.5.7 DECnet layer
1. NETJFN - JFN for the network connection
2. NODSPC - storage for the network JFN file spec
3. REMPTR - pointer to buffer for incoming message
4. NODPTR - pointer to remote node name
5. LPCNT - number of intervals to wait before timing out connect
attempt
6. LPVAL - waiting interval time
CTERM SERVER DESIGN SPECIFICATION Page II-23
DATA BASES
II.5.8 Debug process
1. DEBUG - the "debugger enabled" flag
2. BUGFLG - the debug flags, one for each collection of traces.
o BG.ALL - all flags
o BG.ENA - debugging enabled
o BG.MSI - incoming DECnet messages
o BG.MSO - outgoing DECnet messages
o BG.CTR - incoming CTERM messages
o BG.OOB - Out of band processing
3. BUGFIL - the JFN for the debug output
4. BUGJFN - holds new JFN during command parsing (in case of
reparse)
5. BUGACS - Save registers during DDT
6. BUGMPT - BUG message pointer
7. BUGDPT - BUG data pointer
8. BUGCNT - BUG data count
9. KEYMAI - the top level command keyword table
10. KEYTRC - the tracing keyword table
CTERM SERVER DESIGN SPECIFICATION Page II-24
DATA BASES
II.5.9 Timer process
1. JOBNO - the job number of the current job
2. TIMSTA - the state of the timer
3. TIMOUT - the timeout period in seconds
CTERM SERVER DESIGN SPECIFICATION Page II-25
ALGORITHMS
II.6 ALGORITHMS
II.6.1 Character attributes and the preinput process
When a character's attributes are changed (by a CHARACTERISTICS
message received from the host), the new attributes are compared with
the old attributes. If the character has newly become out of band, a
free PSI channel is allocated (PSIPTR), the channel is activated
(AIC%, STIW% if deferred, entry made in CHNTAB, entry made in OOBTAB)
and associated with that character (STI%). If the character has
become not out of band, its PSI channel (found in OOBTAB) is
deallocated, and the PSI channel is deactivated (DIC%, and entry
removed from CHNTAB) and disassociated (DTI%) from that character. If
the character is a control character, the CCOC word is updated, using
the new echo characteristic. Then the new attributes are put into the
data base (OOBCHA, DELCHA) If the "special flag" is on, the editing
and unediting break masks are updated. (INPEBM and INPUBM). The
"special flag" is the name of a flag in the CHARACTERISTICS message,
which, when it is set, means that the special function associated with
this character is to be enabled. The characters which have a special
function and the special functions are:
o DELETE - delete character
o control-W - delete word
o control-U - delete line
o control-V - quote the next character
o control-R - redisplay line
o control-O - discard/do not discard output
o control-X - clear typeahead and input buffers
When an out of band character is typed in, a PSI goes off, and its
PSI routine passes the character to the common routine - PREOOB which:
o checks the interrupted PC for being in the TEXTI% or PBIN%;
if so, then it changes it to restart. This needs to be done
because a deferred interrupt character (control-C for
example) will cause a data available interrupt.
o sends an OUT-OF-BAND message to the host
o clears the typeahead buffer and calls the output process to
allow input echoing (if the character is a clear or deferred
clear out of band)
o calls the output process to set the output state to "discard"
(if the character is a "discard" clear out of band).
o simulates the echoing of the character, (the CCOC words have
no effect, since the PSI bypasses the input stream)
Each out of band character has to have its own PSI channel, since a
PSI gives no information other than the channel it occurred, and yet
the out of band character must be sent to the host (in a CTERM
OUT-OF-BAND message). Thus there can only be 15 out of band
characters enabled at any one time.
CTERM SERVER DESIGN SPECIFICATION Page II-26
ALGORITHMS
Control-X and control-O, when enabled for their special functions
(clear typeahead and input buffers, and toggle output discard state,
respectively), use the PSI system, just dispatching to a different
routine.
CTERM SERVER DESIGN SPECIFICATION Page II-27
ALGORITHMS
II.6.2 Input process
II.6.2.1 Starting a read
When a read is "started", (a START-READ message is received from
the host) the input process's data base is set up as described below
(by routine INPSTR). If the formatting flag is on, execute the
formatting algorithm, (described below) which may output a LF before
the prompt. The prompt and initial data is then sent to the output
process (routine OUPDSP). Reset the output-page-stop position
(SFPOS%). Generate a PSI on the terminal input data available channel
(IIC%). If timeout is enabled for this read, set the timer.
The formatting algorithm : If OUPCR equals carriage return, then
a LF is output and OUPCR is cleared unless one of these conditions
hold:
o First character of prompt/initial data is LF
o First two characters of prompt/initial data are CR,LF
o Echoing is off, and there is no prompt/initial data
o FREELF is set.
The data base which must be set up on the start of a read.
1. INPLEN - initialized to the MAX-LENGTH field of the
START-READ message
2. INPTMO - set to the TIMEOUT-FIELD-PRESENT field of the
START-READ message
3. INPTIM - initialized to the TIMEOUT field of the START-READ
message
4. INPUND - set nonzero iff the UNDERFLOW field of the
START-READ message is "terminate"
5. INPRAI - set nonzero iff the RAISE-INPUT field of the
START-READ message is "no raise" and TT%LIC of the JFN mode
word is set.
6. INPECH - set nonzero iff the NO-ECHO flag of the START-READ
message is set. In that case, clear TT%ECO in the JFN mode
word.
7. INPQOT - set nonzero iff control-V's characteristic has the
special flag set and the DISABLE-CONTROL-CHARACTER field of
the START-READ message is neither "disable all editing
characters" nor "disable all control characters"
8. INPCTL - set nonzero iff the DISABLE-CONTROL-CHARACTER field
of the START-READ message is "disable all control character".
In that case, save the terminal interrupt words in INPTIW,
and clear all bits in the terminal interrupt words
corresponding to control characters, DELETE, and SPACE.
CTERM SERVER DESIGN SPECIFICATION Page II-28
ALGORITHMS
9. INPTBM - Set up according to the NON-DEFAULT-TERMINATOR field
in the START-READ message: same as previous read, INPUNV, or
the TERMINATOR-SET in the START-READ message.
10. INPXBM - The TEXTI% break mask, set to:
(INPTBM or INPUBM) and not INPEBM or (ESCAPE and INPESR).
Since RD%NED is set in the flags word of the TEXTI%
argument block, any editing character that is in the TEXTI%
break mask will not have its usual editing function, and any
editing character that is not in the TEXTI% break will. So
all disabled editing characters (INPUBM) must be in the
TEXTI% break mask, while no enabled editing character
(INPEBM) can be. The exception to this is control-V. ESCAPE
must be in the break mask if input escape recognition is
enabled, so that its alogrithm will be followed.
Control-V is always set in INPXBM: If control-V is
enabled for its quote function, then it must be in the break
mask, so that the out of band character PSIs can be turned
off. If control-V is disabled for its quote function, then
it must be in the break mask, so that no characters are
quoted. The problem is that in TOPS20, the quote character
does not apply to out of band characters.
11. INPESR - set nonzero iff the RECOGNIZE-INPUT-ESCAPE-SEQUENCES
field of the START-READ message is "perform recognition" or
(is "use characteristic" and the
RECOGNIZE-INPUT-ESCAPE-SEQUENCE characteristic is true.) and
set ESCAPE in INPXBM.
12. INPBLK - the TEXTI% argument block.
word .RDCWB: size of argument block - always set to 10
word .RDFLG: Flags word
RD%JFN, RD%RIE, RD%BEG and RD%NED always set.
RD%RAI set if "raise input" is set in the START-READ message.
RD%RND is set if underflow flag is "terminate" or "ignore".
word .RDIOJ: Input JFN and output JFN
always contains .PRIIN,,.PRIOU
word .RDDBP: Current destination byte pointer
initialized to correspond to END-OF-DATA field
word .RDDBC: Current destination byte count
initialized to space left in buffer (INPLEN - END-OF-DATA)
word .RDBFP: Byte pointer to start of destination buffer.
corresponds to END-OF-PROMPT field of START-READ message
word .RDRTY: Byte pointer to prompt buffer.
corresponds to START-OF-DISPLAY field of START-READ message
CTERM SERVER DESIGN SPECIFICATION Page II-29
ALGORITHMS
word .RDBRK: address of the break mask (always INPXBM)
word .RDBKL: Byte pointer to backup limit in destination buffer
initialized to correspond to LOW-WATER field of START-READ message
II.6.2.2 Terminal data available
When a PSI occurs on the terminal input available channel, the
input process (routine INPENT) does:
o checks if IGNORE-INPUT (INPIGN) is set. If so, then it just
clears the typeahead buffer (CFIBF%) and DEBRK%s.
o checks if the buffers have newly become nonempty, and sends
an INPUT-COUNT-STATE message if needed.
o If a read is not active or output is locked against echoing,
DEBRK%s.
After that checking there are four states it can be in:
o input escape sequence parsing in progress
o quote in progress
o ordinary input
o ordinary input, single character mode.
Input escape parsing (routine INPESC) does PBIN%s with echoing
turned off and dispatches according its own state machine. There are
three conclusions, each of which will terminate the current read:
o valid escape sequence
o invalid escape sequence
o input buffer full
INPESC also uses its own buffer to hold the escape sequence.
Quote in progress (routine INPQOT) does a PBIN%, depositing the
character into the input buffer, turns the out of band interrupts back
on, and goes back to ordinary state.
Ordinary state (routine INPORD) does a TEXTI% (for which the
argument block has previously been set up) with RD%RIE set (return if
input buffer empty). There are three bits returned by the TEXTI%,
checked (in order)
o RD%BLR (backup limit for editing reached) - alter .RDBKL to
reflect that.
o RD%BFE (buffer empty) - check the INPUND flag and terminate
the read if set.
o RD%BTM (break character terminated read) - Clear FREELF. If
the break character was CR, eat the LF, and if echoing is on,
set FREELF. This is done because the echo characteristics
for CR and LF must remain "normal" for TEXTI% to work
properly. If the break character is in the CTERM terminator
set (INPTBM) then terminate the read, else check for quote
CTERM SERVER DESIGN SPECIFICATION Page II-30
ALGORITHMS
character (control-V, if enabled) and for ESCAPE (input
escape recognition, if enabled). The quote character turns
off all character interrupts, and changes the state to "quote
in progress" (.INQOT). ESCAPE turns off echoing and changes
the state to "escape sequence parsing in progress" (.INESC).
The state "ordinary, single character read" is an optimization -
for single character reads, and does a PBIN% instead of a TEXTI%.
If the read has not been terminated, and the state is still
ordinary (.INORD or .INBIN):
o Check for input buffer full, and if it is, terminate the
read.
o Check to see if any more character are available (SIBE%), and
if so, loop.
o If timeout is enabled, reset the timer, and DEBRK%.
II.6.2.3 Termination of a read
Termination of a read (routine INPEND), can occur from the input
process, the preinput process, the timer process, and from receipt of
an UNREAD message from the host. It sends a READ message to the host.
and deactivates the terminal input available PSI channel. It also
clears the timer if it was set and cleans up any characteristics which
were set by the read for the duration of that read. (See definition
of INPRAI, INPECH, INPCTL) It also determines if the last character
echoed was a carriage return, by examination of it and its echo
characteristic.
CTERM SERVER DESIGN SPECIFICATION Page II-31
ALGORITHMS
II.6.3 Output process
The output process is invoked upon receipt of a WRITE message from
the host (routine OUPENT), when displaying the prompt and initial data
for a read (routine OUPDSP), and when the output discard state is to
be changed. (OUPSTP, OUPTOG, OUPUNL) Processing a WRITE message: The
CTERM layer parses the message and sets up:
o OUPBOM - Beginning of message
o OUPEOM - End of message
o OUPOUT - Allow output
o OUPBPT - Pointer to data
o OUPBCT - Count of data
and if OUPBOM is set,
o OUPLOK - locking definition (locking out input echoing)
o OUPNWL - newline flag
o OUPPFX - Prefix code
o OUPPFC - Prefix character/count
o OUPPSX - Postfix code
o OUPPSC - Postfix character/count
o OUPCMP - Completion status requested
o OUPTRN - Transparent output
The output process then does:
1. If OUPOUT is set then set the output discard state to "do not
discard". This means the host wishes to allow output to go
to the terminal, usually after the host has seen the "second"
control-O.
2. If OUPTRN is set then set the data mode to binary. (TT%DAM
field of JFN mode word set to .TTBIN with SFMOD% jsys)
3. If OUPBOM is set then handle the locking against input
echoing (OUPLOK), the skip-line-feed, and the prefix (OUPPFX,
OUPPFC). The locking options are:
* unlock
* lock
* lock and unlock after write completion
* lock and unlock after write completion and redisplay
input buffer on write completion.
To lock means to set the word OUPLCK, which the input process
checks. To unlock means to clear the word OUPLCK, display
the queued input prompt (described below), and to generate an
interrupt (IIC%) on the terminal input data available channel
if an interrupt has been lost. The skip-line-feed handling:
if skip-next-line-feed flag (OUPSKP) is set and the first
character to be written is a line feed then skip it, and
clear OUPSKP.
CTERM SERVER DESIGN SPECIFICATION Page II-32
ALGORITHMS
4. If the output discard state is "do not discard" then send the
data to the terminal (OUPBPT, OUPBCT).
5. If OUPEOM is set, then:
* output the postfix (OUPPSX, OUPPSC),
* handle the newline flag (OUPNWL) - if set, set OUPSKP and
output a line feed.
* Do the unlocking as specified in OUPLOK. and if OUPCMP
is set, then send a WRITE-COMPLETE message to the host,
and
* If OUPTRN is set, then put the terminal into "translate
echo only" mode. (TT%DAM field of the JFN mode word set
to .TTATE with SFMOD% jsys).
* If the OUPEOM is set, then handle the unlocking against
input echoing (OUPLOK), possibly redisplaying the input
buffer, or the queued up input prompt.
Displaying the prompt checks the output lock (OUPLCK); if the
lock is not set, it sends the output to the terminal - if the lock is
set, it queues up the request (OUPIPT, OUPICT describe the buffer) to
be done when the lock is unlocked.
During all of this sending output to the terminal, FREELF is
checked, and if appropriate, FREELF is cleared, and a LF from the
message is not output ( since a LF has already been). The cases that
are checked:
* prefix containing LFs
* data starting with LF, or CR - LF.
* newline flag
Changing the output discard state: There are two variables, the
requested output discard state (DSCRD1) and the real output discard
state (DSCRD2). If DSCRD2 gets set, then output is discarded, and
output is unlocked against input echoing. Three cases:
1. A WRITE message is received from the host with the
SET-OUTPUT-DISCARD-STATE field set. This clears both DSCRD1
and DSCRD2, putting the OUTPUT-DISCARD-STATE into "do not
discard".
2. DSCRD1 is clear and the user types in a control-O. This sets
both DSCRD1 and DSCRD2, and a DISCARD-STATE message is sent
to the host with the DISCARD-CONTROL field = 0 (output is to
be discarded)
3. DSCRD1 is set and the user types in a control-O. This clears
DSCRD1 and a DISCARD-STATE message is sent to the host with
the host with the DISCARD-CONTROL field = 1, which tells the
host that output is no longer to be discarded)
CTERM SERVER DESIGN SPECIFICATION Page II-33
ALGORITHMS
II.6.4 Timer process
The timer process provides the start-read timeout functionality
and is the idle loop for the program. It is driven by its state
variable (TIMSTA) and the timeout value (TIMOUT), and runs with
interrupts disabled, except for the THIBR% instruction. There are
three states: off, set request, and ticking, with off being the
initial state. If the timer process awakens and is in:
1. off state - stay in off state and do a THIBR% for a long time
2. set request - go to ticking state and do a THIBR% for the
timeout value
3. ticking - terminate the read, go to off state and do a THIBR%
for a long time
Setting the timer: change the state to set request, set up
TIMOUT, and do a TWAKE%. Clearing the timer: change the state to
off.
CTERM SERVER DESIGN SPECIFICATION Page II-34
TESTING
II.7 TESTING
This program will be tested by running it against the VMS CTERM
host, running programs on VMS which do things to terminals. The
programs will include MAIL, TRACER, MONITOR, PHONE, EDT, NOTES, SOS
and TECO. It will also be test by running it against the TOPS20 CTERM
host, using various programs that use the terminal in different ways.
The programs will include: the EXEC, OPR, screen editors (EMACS,
VTECO, TV, SED, EDT) MS, PTYCON, WINDOW, DDT.
VMS-CTERM.DOC
CHAPTER 1
VMS CTERM
1.1 GOALS OF THIS DOCUMENT
The purpose of this document is to record the details of the VMS
CTERM implementation. It includes the exceptions and additions to the
standard CTERM specification. An attempt to make objective comments and
criticisms of the architecture will also be made.
It is assumed that the reader is familiar with the CTERM and FOUND
specs, and that s/he has a copy to refer to when reading this document.
1.2 HISTORY
Remote terminal implementations have always been done via ad-hoc
methods which resulted in heterogeneous protocols. The result of this
was that each operating system within the company had to know how to
communicate with every other system explicitly. For VMS, the SET HOST
software understood protocols for VMS, RSX, RSTS and TOPS-20. Setting
host to a system other than VMS was not supported. CTERM (command
terminal protocol) is the first homogeneous protocol within the company.
Engineers from the operating systems and architects spent a period of
over a year coming up with a protocol that all systems could support.
1.3 WHAT CTERM IS
CTERM is a protocol for implementing remote command terminals across
DECnet circuits. The Digital Terminal Software Architecture (TSA)
defines the syntax and semantics of CTERM. The protocol includes
messages that create bindings, start reads from the terminal, send write
data to the terminal, manage characteristics, and so forth.
1.4 WHAT CTERM IS NOT
Many people within the company have expected CTERM to be more than
it can be. CTERM is not a great panacea that will cause all of
VMS CTERM Page 1-2
Digital's cross system compatibility problems to go away. Certain basic
philosophical differences that exist between operating systems will
almost certainly always prevent complete cross system supportability of
every terminal feature available.
Another problem is one of dynamics. The CTERM protocol captured a
fairly good set of terminal driver functions at the time it was written,
but implementation of features has continued. One example of this is
the line editing functions that will be available in VMS V4.0. This
feature has been conceived since the CTERM spec was written. It
obsoletes (as far as VMS is concerned) any definition in the CTERM spec
of what line editing is.
Because of these problems, CTERM does not make a good protocol for
terminal servers. As an operating system changes, the terminal server
(and the protocol) must keep pace. If it doesn't, the user directly
connected to a VAX system will have more features available than a user
connected through a terminal server. It is certainly not impossible to
implement a server that completely mimics the host, just very difficult.
The only case where this is easily implemented and compatible is where
the server is the same system as the host (in other words, they are
running the exact same terminal driver).
These problems are not minor and should not be ignored or glossed
over. However, CTERM is still a very viable architecture and will solve
a lot of the problems of the past. VMS is planning to drop its own
operating system specific protocol in favor of CTERM and VMS specific
extensions. The extendability of CTERM is one of its stongest features
and will allow very flexible and extensive modifications. Another
advantage is that the protocol allows very efficient use of the DECnet
circuit being used.
1.5 BASICS
In order that the VMS terminology is understood, I will first
describe the overall VMS implementation. There are two distinct pieces
to the CTERM support, namely SERVER and HOST. The server software
consists entirely of the RTPAD image (aka SET HOST) and the standard
terminal driver interface. The host software consists of two pieces,
REMACP and CTDRIVER. REMACP simply answers requests for object type 42
and handles creation and deletion of remote terminal I/O database
objects. CTDRIVER maps QIO requests into CTERM protocol and sends them
to the server via DECnet. Figure 1 illustrates this.
VMS CTERM Page 1-3
process
|
| QIO requests
|
server host V
+---------------+ +---------------+
| | | |
| RTPAD |~~ DECnet circuit ~~| CTDRIVER |
| | | (and REMACP) |
+---------------+ +---------------+
|
| QIO interface
|
V
+---------------+
| |
| VMS terminal |
| driver |
| |
+---------------+
|
V
+-------+
| |
| tty |
| |
+-------+
\........\
\........\
`-------'
Figure 1. VMS pieces of CTERM support.
CHAPTER 2
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION
2.1 REASONS FOR DIFFERENCES
There are several reasons that an implementation of CTERM might not
be completely in keeping with the specification. The major reason for
these differences is that the lower levels of terminal support (i.e.
the terminal driver) may not support a needed feature. There are many
reasons why it may not be possible to add this feature to the terminal
support. These reasons include:
1. Feasibility -- Due to a restriction in memory or architecture,
it may not be feasible to implement a given feature.
2. Supportability -- Any feature included in the lower levels
would have to be supportable for use by customers. In some
cases, this may not be practical.
3. Philosophy -- Low level terminal services are radically
different from system to system within the company. These
differences are due to varying philosophies regarding terminal
services. Without radical changes, it would be impossible to
provide certain features.
VMS has looked at each feature from a viewpoint of "is this a valuable
function in general?". If the answer to this was no, we opted to leave
out the feature. We are not saying that VMS will never implement the
things that have been left out, only that the features will not be in
VMS V4.0. If CTERM becomes highly usable and viable for connections
with RSX and TOPS-20, additional work would be in order to make
usability even better.
2.2 CHARACTERISTICS SUPPORT
The first aspect of the VMS implementation will deal with
characteristics. As terminal characteristics determine the "feel" of a
terminal interface, it is probably a good place to start.
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-2
2.2.1 CTERM Characteristics
Also called handler maintained characteristics, these have been broken
out as characteristics which are unique to command mode interaction.
Whether this is strictly true will not be debated here.
1. IGNORE-INPUT -- the closest thing VMS has to this
characteristic is NOTYPAHD (no type ahead). This results in
data being discarded only when a read is not active. This is
what we map for this characteristic.
2. CHARACTER-ATTRIBUTES -- specifies the characteristics of a
character. This is probably the most difficult, most ambiguous
characteristic in all of the architecture. I suspect that this
characteristic and the way it is handled will cause most of the
cross-system inconsistencies.
- Out-of-Band Handling - VMS does not handle anything other
than control characters as out-of-band characters. This is
not in keeping with the spec's defintion of immediate hello
(type 3) out-of-bands which include the full 8 bit
character set. It is felt that the cost in terms of
non-paged pool (i.e. physical memory in VMS) would be too
high to implement this. Also, deferred clear out-of-bands
(type 2) are treated as immediate clear (type 1) by the
server. A VMS host will never request deferred clear.
- Include Flag - full support. Enabled by IO$M_INCLUDE
function modifier.
- Discard Flag - full support in server. Only requested on
immediate clear requests from host.
- Control Character Echoing - not supported. With VMS V4.0,
control characters either have a function (e.g. delete
word) or they are a nop. The reason for this is to prevent
fumbled fingered typists from terminating a read before
they really wanted. What sense does it make to insert a
form feed (for instance) into a DCL command?
The CTERM spec only allows echoing of control characters
when they are input characters. Echoing of out-of-bands is
not addressed clearly. For VMS, there are two types of
out-of-bands. The first type is the standard ^C or ^Y
(cancel and interrupt) which echo when typed. The second
is the normal out-of-band (like ^T) which does not echo the
character. It is therefore possible to enable a ^C
out-of-band that echos (through IO$_SETMODE!IO$M_CTRLCAST)
or one that doesn't echo (through
IO$_SETMODE!IO$M_OUTBAND). The way in which this
information is preserved is by setting the "echo in
standard form" for standard ^C and ^Y in the protocol
message.
Another difference is the way in which VMS V4.0 will echo
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-3
^C, ^Y, ^O and ^Z. The following table lists the echo
strings.
1. ^C - Cancel
2. ^Y - Interrupt
3. ^Z - Exit
4. ^O - Output Off (or) Output On
- Enable/Disable special characters - not supported. All
special characters are always enabled.
3. CONTROL-O-PASS-THROUGH -- not supported in server. Host will
never request. Treated as always false.
4. RAISE-INPUT -- full support. VMS ties this to its UPPERCASE
characteristic. This means that output is upcased as well as
input. The original reason for this characteristic was to
support uppercase only terminals. These terminals are rare
these days, but we still support them.
5. NORMAL-ECHO -- full support. Mapped to NOECHO in VMS.
6. INPUT-ESCAPE-SEQUENCE-ENABLE and OUTPUT-ESCAPE-SEQUENCE-ENABLE
-- full support, except that host always requests both and
setting one implies the other in the server. This is because
VMS only has an ESCAPE characteristic which applies to both
input and output streams.
7. INPUT-COUNT-STATE -- full support for DO-NOT-SEND and
NO-READ-SEND. NO-READ-SEND is always requested from VMS host.
Unable to implement SEND. Does RSX or TOPS need this?
8. AUTO-PROMPT -- full support. This characteristic, known as
script mode in VMS, is unsupported and undocumented. It is
used for doing load testing within performance groups in the
company. The CTERM spec says that the control A should be
inserted before the prompt. I believe this is an error, and
that the control A should be sent as the last character of the
prompt.
9. ERROR-PROCESSING -- no support in Field Test 1, although it is
possible to implement a close parallel to this in our server.
2.2.2 LOGICAL Characteristics
ALthough both logical and physical characteristics are defined in the
Foundation Services Specification, they are all handled more or less the
same in the VMS implementation. Because of this, it is logical for the
description of these characteristics to be in this document.
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-4
1. MODE-WRITING-ALLOWED -- Ignored.
2. TERMINAL-ATTRIBUTES -- full support.
3. TERMINAL-TYPE -- full support for terminals listed in VMS SPD.
4. OUTPUT-FLOW-CONTROL -- full support. Mapped to TTSYNC
characteristic.
5. OUTPUT-PAGE-STOP -- ignored.
6. FLOW-CHARACTER-PASS-THROUGH -- ignored. Always false.
7. INPUT-FLOW-CONTROL -- mapped to HOSTSYNC.
8. LOSS-NOTIFICATION -- BELL only when INPUT-FLOW-CONROL is false.
This is because VMS implements HOSTSYNC as "send XOFF" when
true and "send BELL" when false.
9. LINE-WIDTH -- full support.
10. PAGE-LENGTH -- full support.
11. STOP-LENGTH -- ignored.
12. CR-FILL -- full support.
13. LF-FILL -- full support.
14. WRAP -- values supported as follows:
1. 1 - mapped to NO WRAP on server.
2. 2 - data only discard when NO WRAP and HARDCOPY.
3. 3 - no support in VMS. Hardware wrapping is not supported.
4. 4 - mapped to WRAP in VMS.
15. HORIZONTAL-TAB -- full support. Mapped to MECHTAB in server.
16. VERTICAL-TAB -- no support. VMS outputs VT as four line feeds.
17. FORM-FEED -- full support. Mapped to MECHFORM in server.
2.2.3 PHYSICAL Characteristics
1. INPUT-SPEED -- full support.
2. OUTPUT-SPEED -- full support.
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-5
3. CHARACTER-SIZE -- full support. (FT1?)
4. PARITY-ENABLE -- full support. (FT1?)
5. PARITY-TYPE -- full support. (FT1?)
6. MODEM-PRESENT -- full support. Mapped to MODEM characteristic.
7. AUTOBAUD-DETECT -- full support.
8. MANAGEMENT-GUARANTEED -- ignored.
9. SWITCH-CHARACTER-1 -- ignored.
10. SWITCH-CHARACTER-2 -- ignored.
2.3 INITIATE
The Initiate message is fully supported. Values sent are in table 1.
selector value sent value sent
value by VMS server by VMS host
-------- ------------- -----------
1 ? ?
2 ? ?
3 ? ?
4 (VMS private) ? ?
2.4 START READ
Read processing is complete except in one respect. Functions included
to implement distributed input editing have not been included in the
server. A VMS host will never request these features. The specifics
are listed below.
2.4.1 READ FLAGS
The following flags are not handled because they are intended
for the distributed editing case. They are always ignored by
the server, and never requested by the host.
1. UNDERFLOW-HANDLING
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-6
2. TERMINATE ON VERITCAL CHANGE
3. CONTINUATION READ
The following flags are at least partially supported.
1. CLEAR TYPE-AHEAD -- full support via IO$M_PURGE modifier.
2. FORMATTING FLAG -- Essentially, this is the free line feed
logic in the VMS terminal driver. This is always on in VMS. I
doubt anyone will ever notice that value 0 (no special action)
is not supported in the VMS server.
3. RAISE INPUT -- values 0 and 2 are mapped by IO$M_CVTLOW. Value
1 (no upcase conversion for this read only) handled as is 0
were requested.
4. DISABLE CONTROL -- values supported as follows:
1. 0 - full support.
2. 1 - disable ^U and ^R - this is a distributed editing hook,
not supported.
3. 2 - full support mapped by IO$M_NOFILTR.
4. 3 - full support mapped by IO$_TTYREADPALL.
5. NOECHO -- full support mapped by IO$M_NOECHO.
6. TERMINATOR ECHO -- full support mapped by IO$M_TRMNOECHO.
7. TIME-OUT FLAG -- full support mapped by IO$M_TIMED.
8. NON-DEFAULT TERMINATOR SET -- full support. Definition of
default terminators is new with VMS version 4.0. Only CR or an
escape sequence terminates a read.
9. RECOGNIZE INPUT ESCAPE SEQUENCE - full support for 0 and 2
mapped by IO$M_ESCAPE. Value 1 (do not recognize for this read
only) handled as if zero were requested.
2.4.2 READ PARAMETERS
1. MAX-LENGTH -- full support.
2. END-OF-DATA -- full support.
3. TIMEOUT -- full support.
4. END-OF-PROMPT -- full support.
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-7
5. START-OF-DISPLAY -- full support.
6. LOW-WATER -- ignored. This is another distributed editing
hook.
7.
2.5 READ DATA
1. Flag indicating "more type-ahead data" is never set.
2. LOW-WATER is never set.
3. VERTICAL-CHANGE is used to return the cursor position for the
end of the line. In other words, if a user types three left
arrows before typing <CR>, this field is returned as three.
2.6 OUT-OF-BAND
Full support for control character set.
2.7 UNREAD
Full support. VMS host only requests unconditional unread.
2.8 CLEAR INPUT
Full support in server. Not requested by VMS host.
2.9 WRITE
Full support except:
1. lock handling: VMS does not handle unlock (type 0). VMS
terminal services are implicitly locked when doing output.
2. Write completion not requested by VMS host. It is very easy to
patch host software to request write completion on every write
though.
DIFFERENCES BETWEEN THE TSA SPEC AND THE VMS IMPLEMENTATION Page 2-8
3. undefined bit 2 (between D.UU) is used for VMS function
"newline". Writing a CR with this flag causes CR and LF to be
written with the internal "skip the next line feed" flag to be
set. This is used in applications that read "terminator no
echo" and wish to output a CR exactly as if it had been echoed
by the read terminating.
2.10 WRITE COMPLETION
Full support in server. Note that the horizontal and vertical position
information that is included in the spec is most likely for VMS. Note
also that we are considering removing support for this return data. Any
buffering of output requires that this information can not be returned.
2.11 DISCARD STATE
Full support.
2.12 READ CHARACTERISTICS AND CHARACTERISTICS
Full support of messages, see previous text for handling of individual
characteristics.
2.13 CHECK INPUT
Requested by host. Maps IO$_SETMODE!IO$M_TYPEAHDCNT QIO request.
2.14 INPUT COUNT
Full support in server. Note that VMS requires the first character in
typeahead as well on this function. This is handled by sending a 5 byte
message instead of a 4 byte message. The VMS host software uses the
length of the message to know whether the character as been included.
2.15 INPUT STATE
Zero to non-zero transitions are sent. Count became zero is not
supported.
CHAPTER 3
VMS EXTENSIONS TO CTERM
3.1 REASONS FOR EXTENSIONS
Why is it necessary to extend CTERM for VMS to VMS connections?
The CTERM protocol allowed expressing most command terminal functions at
the time it was written. However, the base CTERM specification does not
cover all of the VMS characteristics, or new functions like read verify.
It was known in the later stages of the CTERM specification that
these were real problems. Because of this, hooks were placed in the
protocol to make these extensions easy to add and "consistent" with the
remainder of the protocol. The most important of these decisions was
defining a "base CTERM" and allowing other messages to be added at will
and arbitrated during the initial binding.
3.2 CHANGES TO EXISTING PROTOCOL
This section includes changes to existing messages in the CTERM
protocol. These include adding new parameters and adding new flags.
3.2.1 The INIT Message
The initiate message includes a new parmeter type. We use value 4
for this new parameter. It is only sent from a VMS server to a VMS
host. The parameter includes the characteristics of the server terminal
and is used for the initial characteristics of the newly created remote
terminal.
The format of the message is as follows:
PARMTYPE(1) : 4
CHAR(I-255) : VMS initial characteristics
VMS EXTENSIONS TO CTERM Page 3-2
3.2.2 The WRITE Message
One additional flag is used in the write message. The first free
bit in the write message (the "." in "D.UU") is used for the VMS
IO$M_NEWLINE function. It is always set when this function is
requested, regardless of the server system type.
The semantics of this flag are as follows: At the end of a write,
output a line feed and set the internal "skip line feed" flag, so that
if the first character in the next write is a line feed, double spacing
is avoided. The reason this has been implemented is so that an
application that does read with terminators not echoing can output a
"CR" which echos as a "CR,LF" in the same manner as does the read
processing.
3.2.3 The Read Message
Two additional flags are defined when talking VMS to VMS. These flags
are modifiers added for the read editing enhancements done in V4.
Bitwise, they are placed next to the escape modifier flags. In "..EE",
they appear as "ROEE" where:
O = turn off enhanced editing functions
0: Do regular read editing
1: Do V3.0 flavor editing,
DELETE, ^U, ^R only.
R = Turn off recall
0: allow last command recall by driver
1: pass recall back to caller to
allow him to process recall request
(Used by DCL to support the last 20
commands recall feature)
3.3 NEW MESSAGES
VMS has added 3 new message to the CTERM protocol. They are for VMS
private characteristics, an upline broadcast message, and extended reads
(also known as read verify). These messages use message type codes 15,
16 and 17 and are specified in the INIT message mask.
3.3.1 VMS Characteristics (H <---> S)
The format of the VMS characteristics message host to server and server
to host is basically a protocol version of the VMS QIO parameters. It
has been done this way so that any VMS QIO can be represented in this
single message. The format of this message is so VMS specific that it
is meaningless to any other system, and it will not be specified here.
This message uses message type code 15.
VMS EXTENSIONS TO CTERM Page 3-3
3.3.2 Upline Broadcast (H <--- S)
The upline broadcast is used in the following case. A VMS to VMS remote
terminal session is in progress. The application on the remote terminal
has set up a broadcast mailbox and enabled it. Any broadcast to either
the remote terminal or the server terminal will result in the message
being delivered to the mailbox in the host system. This means that
RTPAD (the VMS server) will get a mailbox message, send it up the wire
to the VMS host, and the host is responsible for writing the message to
the application mailbox.
The format of the message is as follows:
MSGTYPE (1) : C = 16
FLAGS (2) : C = 0
No flags defined.
MSGCODE (2) : C = MSG$_TRMBRDCST (53 hex)
VMS mailbox message code.
UNITNUM (2) : device unit number
DEVNAME (16) : counted string of device name
MSGLEN (2) : byte count of message that follows
MSGTXT (n) : character string of text
3.3.3 Extended READ (H ---> S)
The extened read handles all of the additional parameters in the read
verify QIO request. These reads are used by FMS and TDMS to allow
efficient processing of field validated data. The format was kept as
compatible with the current START READ message so that common code can
be used to parse a good portion of both of these messages.
The format is the same up to the point of the terminator mask. At this
point, 4 additional words are added to describe the additional strings
that follow. So at the point where the terminator in the START READ is
specified, the START EXTENDED READ message continues as follows:
ALT ECHO SIZE (2) : alternate echo size
PIC STR SIZE (2) : picture string size
EXTENDED FLAGS (2) : additional flags
BM = .... .... .... ..RA
VMS EXTENSIONS TO CTERM Page 3-4
R = Right justify
0: Do normal justification
1: Do right justification
A = autotab
0: Don't do autotab
1: Do autotab
FILLCHAR (2) : Fill characters
first byte - fill character
second byte - clear character
TERMINATION-SET (I-32) : same as normal START READ
strings that follow:
PROMPT STRING
INITIAL STRING
PICTURE STRING
ALTERNATE ECHO STRING
*** I need to get a description here with the actions and semantics
of extended read processing *** Voyager needs this asap.
CHAPTER 4
VMS V4.0 COMMAND LINE EDITING
4.1 OVERVIEW
The purpose of this chapter is to give an overview of the functions
of the VMS V4.0 command line editing that the terminal driver offers.
The command line editor is much more sophisticated than anything
previously offered in a Digital operating system. The editor has two
modes: insert (like EDT) or overstrike (recommended by human factors
for novice users). The default mode is setable as a characteristic
which is set at the beginning of each read. The mode can then be
toggled by use off ^A. Table 4.1 shows the functions and the keys used
to implement them.
function key notes
----------- ------------- -------------------------
DELETE CHAR DELETE
DELETE WORD LINE FEED (^J) does not conform to TSA
DELETE LINE ^U deletes from cursor to BOL
MOVE LEFT ^D or left arrow
MOVE RIGHT ^F or right arrow
MOVE TO BOL ^H BOL = beginning of line
MOVE TO EOL ^E EOL = end of line
TOGGLE INS/OVER ^A
RECALL ^B recall last command
QUOTE ^V allows escape sequence to be
quoted as well
Table 4.1 - Read Editing Keys
In addition to the control character, VMS has made the following
assignments to the LK201 keyboard. These are the key assignments VMS
has made currently. Note this may not be final. Note that dead keys
are reserved for future use by VMS.
key function same as
--- -------- -------
F6 cancel ^C
F7 dead key
F8 dead key
F9 Recall ^B
VMS V4.0 COMMAND LINE EDITING Page 4-2
F10 Exit ^Z
F11 dead key
F12 BOL ^H
F13 DelWord ^J
F14 Ins/Over ^A
Table 4.2 - LK201 keyboard defintions
--------