These files make up a pseudo terminal driver for VAX/VMS. This driver was
originally developed at Carnegie-Mellon University and has made the
rounds before as the CMU PTY driver.  I picked up the driver just after
it had been migrated from V3 to V4, made a lot of improvements, and have
been redistributing it ever since.

This driver runs under VMS V4 and V5.  It will not work under any VMS
prior to V4.  It has been minimally tested by me on V4.7 and V5.0.  It
should work on earlier V4 point releases as well, but I haven't tried it.

Note that during assembly the driver will detect the version of VMS and
build the proper variant.  You do not need to modify the sources for V4
of V5.

See PTY_DOC.TXT for documentation and NOTES.TXT for my additional comments
and observations.

Changes for version 05-006A (PYDRIVER) and 05-004A (TWDRIVER) include:

  o  Support for VMS V5 including Symmetric Multiprocessing environments.
     Conditional assembly of the drivers will produce V4 or V5
     compatible drivers.  This also includes changes to the PY$FDTWRITE
     routine to be smarter about grabbing and releasing the device
     (device IPL in V5, device lock in V5).  It used to raise and
     lower IPL quite a lot, but this is expensive when converted to
     lock/unlock for SMP.

  o  The port control MULTISESSION bit is now set by the driver, causing
     terminal sessions on TW devices to NOT count against your license
     limit.  This is good for programs like PHOTO, but not so good
     for network logins.  This really should be made settable by the
     application controlling the PY device.

  o  Writes to the PY device will now return SS$_DATAOVERUN if the TW
     signals XOFF.  In the case of DATA OVER-RUN the bytecount field in
     the IOSB is the number of characters actually delivered. Note that
     if the last character causes XOFF you will receive SS$_DATAOVERUN
     instead of SS$_NORMAL.  Applications should check for SS$_DATAOVERUN
     in the IOSB after a write to the PY device and keep track of how
     many characters remain to be delivered later.  You probably want to
     use the new flow-control AST mechanism, described below, in
     conjunction with this so you know when to continue delivering data
     to the PY device.

  o  There is now a SETMODE and SETCHAR function that allows you to
     enable three new ASTs.  It does not take any function modifiers and
     only sets the specified ASTs.  The QIO parameters are:

		P1 - ASTADDR
		P2 - ASTPARAM (16 bits only on TW$XON or TW$XOFF)
		P3 - ACCESS MODE to deliver AST in -- usual rules
		P4 - AST to deliver -- legal values are
			1 - Deliver AST when TW$XON is called.  When the
			    AST is delivered the low order word of
			    ASTPARAM will be the character supplied to
			    TW$XON to send.  The high order word will
			    be your ASTPARAM.
			2 - Deliver AST when TW$XOFF is called.  When the
			    AST is delivered the low order word of
			    ASTPARAM will be the character supplied to
			    TW$XOFF to send.  The high order word will
			    be your ASTPARAM.
			3 - Deliver AST when TW$SET_LINE is called.

  o  The TW device now defaults to HOSTSYNC.  This may be disabled
     with a SET TERM DCL command or the proper SETMODE or SETCHAR
     QIO to the TW device.  The TW device is always set NOMODEM and
     will not allow MODEM to be set.

  o  The PY device now accepts a SENSEMODE and SENSECHAR QIO function
     to read the device characteristics of the TW terminal device.
     These work exactly the same as they would to a terminal device.
     The IOSB and return data buffer have the same format.  This allows
     the controlling application to track the state of the associated TW
     device.

     NOTE:  Because SENSEMODE now returns TW terminal characteristics,
            you can no longer use it to return the PY device dependent
            longword which contains the unit number for the associated
            TW device.  You must use $GETDVI instead.  You should already
            have been using $GETDVI.

  o  Modification to slave terminal device ownership to function
     correctly after "Security Upgrade V2" has been applied to a
     VMS V4 system.  The security upgrade is incorporated into V5.

  o  The PY device now supports writes of buffers greater than 64K.
     Note that use of such large buffers probably requires that you monitor
     the flow control ASTs.

     The security upgrade fixed a bug whereby cloned terminal devices
     were not protected in accordance with the system-wide terminal
     protection mask, but were left wide open.  Cloned terminals are
     no longer G,W:RWLP.  This caused some PTY applications to break,
     since they needed access to the created terminal device without
     privileges.  This version of the PTY drivers sets the device owner
     of the cloned terminal device to that of the creator.  This should
     allow applications that were sensitive to the device protection to
     continue to function.  Additionally, the device remains inaccessible
     to GROUP and WORLD, in keeping with system security requirements.

     Other solutions to this problem have been proposed which merely force
     the terminal protections wide open.  This is not a good idea as it
     circumvents system security requirements.

  o  The terminal device name has been changed from TPAn: to TWAn: because
     the VAX PSI product now uses TP.  PY and TW are the names of choice
     now since they have been registered within Digital by a development
     group.  Some applications which are hard-coded for TPAn: or some
     other name are going to break.  Perhaps they should have used a
     logical name to refer to the device in the first place.  Oh well.

     Source code is available for such applications (the two types of
     PHOTO utility come to mind) and will have to be changed.  Alternately,
     it is a simple patch to the executable if source code is not
     available.  Finally, you may be able to get by with defining TPA0
     to be TWA0 if you cannot fix or patch but this is may cause problems
     if you use VAX PSI.  I urge anyone distributing an application which
     will break due to this change to fix their application and make it
     available again.

     Please note that not all applications of PTY need to know the
     terminal device name.  The TEK-CMU IP/TCP package, at least in
     V6.0 with which I am familiar, uses PTYs but does not care what
     the terminal device name is.

     On a final note, if the results of the Digital development effort which
     is using PY and TW should find their way onto your system, you
     should be able to continue to use your applications with the Digital
     supplied devices.  I will do my best to keep abreast of developments
     in that arena and make public any caveats I find with the Digital
     supplied devices.  At the worst, the DEC devices may be completely
     changed, and we will change the names of PY and TW again.  Note that
     this may be the time for you application writers to use (properly
     prefixed -- naturally) logical names for your pseudo-terminal
     device specifications.

	/Kevin Carosso                     kvc@nrc.com
	 Network Research Co.              kvc@ymir.bitnet

	June 9, 1988

PS:

In case anyone has a REALLY old version, here's the notes from my
previous distribution (note the date at the bottom).  These changes,
where applicable, are all incorporated into the current distribution.

---------------------------------------------------------------------

The distribution version 04-006 fixes the following problems:

  o  ^S^Y system crasher
  o  randomly munged <LF> and <ESC> characters
  o  SHOW DEVICE stack dumps
  o  system crashes due to attempted use of the TPA0: device
  o  terminal device name changed from PTAn: to TPAn: because
     VMS uses PTA for MSCP tapes.

	/Kevin Carosso              kvc@engvax.scg.hac.com
	 Hughes Aircraft Co.	or  kvc%engvax@oberon.usc.edu

	 December 9, 1986