NOTE: IF YOU HAVE INSTALLED DECWINDOWS THEN YOU ALREADY HAVE A DIGITAL SUPPLIED VERSION OF THESE DRIVERS. AS FAR AS I KNOW THE DRIVERS ARE COMPATIBLE. SINCE I CANNOT WARRANT THAT DECWINDOWS APPLICATIONS WILL ALWAYS WORK WITH THESE DRIVERS (THOUGH I THINK THEY WILL) YOU SHOULD USE THE DECWINDOWS DRIVERS IF POSSIBLE. THE NOTES AND DOCUMENTATION SUPPLIED WITH THESE PUBLIC DOMAIN DRIVERS SHOULD APPLY TO DECWINDOWS WITH VMS V5.1 These notes document some caveats I have found. This information complements the documentation in PTY_DOC.TXT with some additional observations I've made. 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. This version has been modified further for VMS V5 and the terminal device name has been changed, once again, to TWAn: because VAX PSI has usurped TPAn:. TWAn: and PYAn: have been registered within Digital for DECwindows since DECwindows is currently (VMS V5.1) using these drivers. Note that they are not supported by Digital for any use other than by DECwindows, though they should be completly compatible with the source and documentation supplied in this distribution. This distribution has been tested under VMS V5.1 but should work without change on VMS V4.0 through V5.1 (with reassembly between major versions). The driver detects during assembly whether it is being built under VMS V4 or V5 and conditionally builds the proper variant. A message will be issued indicating the version being built. You cannot build the driver on one major version of VMS to execute on another. Also note that the LINK warning message %LINK-W-USRTFR, image has no user transfer address is normal for device drivers and should be ignored. Load the two drivers as PYA0: and TWA0: using a SYSGEN command such as (SEE NOTE ABOVE RE: DECWINDOWS BEFORE LOADING THESE DRIVERS!): $ MCR SYSGEN SYSGEN> LOAD DISK:[DIRECTORY]TWDRIVER SYSGEN> LOAD DISK:[DIRECTORY]PYDRIVER SYSGEN> CONNECT TWA0/NOADAPTER/DRIVER=TWDRIVER SYSGEN> CONNECT PYA0/NOADAPTER/DRIVER=PYDRIVER Assigning a channel to PYA0: will create a PYAn: and a TWAn: pseudo-terminal pair (the unit numbers just go up). Anything you write to that channel appears on the TW as if typed at a terminal. Any output to the terminal TWAn: 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 TW terminal had, anywhere from 1 to MAXBUF. If the QIO to the TW 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 TW 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 TWAn: 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 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 TW and both devices should be deleted. Currently, the TW will not disappear, though the PY will and the TW 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 TWA53:, 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 TW or if you have no processes active on the TW when the PY and TW are to be deleted. These two cases are generally the norm. It should be possible to set the TW terminal characteristics through the PY device, so the controlling program can set them. There may be ramifications of changing device characteristics on TTDRIVER unexpectedly, however, that have to be figured out first. If you need to set characteristics of the terminal device right now, you must assign a channel to the TW device and use a SETCHAR QIO then deassign the channel before giving the TW 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. This is sufficient for most applications that need to set characteristics only before starting up another process to use the device. If you need to set the characteristics after your other process has assigned a channel to the terminal device, you will need the SHARE privilege to assign your own channel to it and do the SETMODE. Note that the SETMODE QIO you do should be asynchronous as your QIO may get queued behind other QIO's and your application probably does not want to wait for completion. /Kevin Carosso Innosoft International, Inc. kvc@ymir.bitnet April 24, 1989 (supersedes NOTES.TXT dated June 17, 1988)