These notes should be considered an addition to the documentation
to be found in PSEUDO.DOC.  These notes document some enhancements
I have made to the drivers as well as some caveats I have found.

First of all, I want to grant credit to the original authors of the
driver, they are listed at the beginning of the two source files.  In
private correspondence with Dale Moore at CMU, he has chosen to release the
driver to the public domain.  There have been various incarnations of this
driver in the past.  I started with a version that was modified to run
under VMS V4 and cleaned it up and made CONNECT/DISCONNECT and HANGUP work
consistently.  I also changed the device name of the terminal device from
PTAn: to TPAn: because VMS now uses PTA0: for MSCP tapes.

The drivers have been tested on VMS V4.0 through V4.4.

Load the two drivers as PYA0: and TPA0:.  Assigning a channel to
PYA0: will create a PYAn: and a TPAn: pseudo-terminal pair (the unit
numbers just go up).  Anything you write to that channel appears on the
TP as if typed at a terminal.  Any output to the terminal TPAn: is available
to be read from PYAn:.  On output, the devices do flow control between one
another and all buffering.  You can just read, for example, with a 100
char buffer from PY and the read will complete with whatever number of
characters the QIO to the TP terminal had, anywhere from 1 to MAXBUF.
If the QIO to the TP had more chars than your read buffer, it'll just
fill the read buffer and return, and you can get the rest on the next
read.  On input, it is possible to overrun the TP device's terminal
type-ahead buffer, as it is with a real terminal.

If you assign a mailbox with the PYAn: device (use LIB$ASN_WTH_MBX
when assigning the channel to PYA0:) you will get an MSG$_TRMHANGUP
message in the mailbox whenever the terminal is hung-up.  This occurs
when a process deassigns the last channel to the device, just as a HANGUP
will on terminals with modem signals.  You may ignore the hangup message if
you choose and continue to use the device after the message.

Should you deassign all channels to the PYAn: device, a hangup will be
forced on any process using the TPAn: device.  Just like dropping carrier on
a modem line.  If the pseudo-terminal is in use by an interactive process
and has an associated virtual terminal, the process will be disconnected,
otherwise the interactive process will be logged out.

To enable virtual terminals on pseudo-terminals, you must have the
TT2$M_DISCONNECT bit set in the system default terminal characteristics
(TTY_DEFCHAR2 in SYSGEN).

Note that, just as with normal VMS terminals, you will only get a
VTAn: if the line has the DISCONNECT terminal characteristic before
you log into it, and only if you use LOGINOUT to start a process on
the terminal.  Sending a <CR> into the pseudo-terminal device will
start up LOGINOUT as it would on a real terminal.

There is currently one minor known bug in the drivers, a side-effect of
the driver being cautious in order to prevent possible problems.  If you
have a virtual terminal associated with the pseudo-terminal, and you
deassign the last channel to the control device (the PY device) then a
DISCONNECT is forced on any process on the TP and both devices should be
deleted.  Currently, the TP will not disappear, though the PY will and
the TP will be marked as OFFLINE.  This is because I rely on VMS to do
the actual delete of the device and it appears that virtual terminals
screw up the way device reference counts work, so VMS never gets around to
deleting the device.  It is marked for delete, so anything you do (I like
SHOW TERM TPA53:, for example) will cause it to disappear.  I could fix this
by zapping the device explicitly after forcing the DISCONNECT, however I
am not convinced that someone, somewhere, won't try to reference the UCB and
thus cause bad things to occur.  Note that it DOES get deleted correctly if
you do not have a virtual terminal associated with the TP or if you have no
processes active on the TP when the PY and TP are to be deleted.  These two
cases are generally the norm.

I am currently considering a few enhancements:

 o  It should be possible to set the TP terminal characteristics through
    the PY device, so the controlling program can set them.  

 o  The TP device driver should notify the controlling program (via the
    associated mailbox) whenever the TP terminal characteristics are
    changed in case applications need to know such things.

 o  There should be a mechanism, again utilizing the associated mailbox,
    for the controlling application to be notified when the TP's typeahead
    buffer fills.

I need to think about the ramifications of changing device characteristics on
TTDRIVER unexpectedly, however, before I make the first change.

If you need to set characteristics of the terminal device right now,
you must assign a channel to the TP device and use a SETMODE QIO
then deassign the channel before giving the TP to another process. You
will get a HANGUP message in the associated mailbox when you
deassign if the HANGUP attribute was set on the device.  You can
ignore this message, however, and go ahead and use the device.

You cannot set characteristics of the master device.  This used to be
allowed, though it had no purpose, and it crashes the system (at
least under V4).

	/Kevin Carosso               kvc%engvax.UUCP@usc-oberon.usc.edu
	 Hughes Aircraft Co.

	 December 9, 1986