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. 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:. The previous distribution of the drivers had been tested on VMS V4.0 through V4.7. This distribution has been tested under V4.7, V5 FT2, and V5.0. Note that the the conditional assembly for VMS_V4 must be commented out and the driver reassembled and relinked for V5. 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: $ 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. I am currently considering a few enhancements: o It should be possible to set the TW terminal characteristics through the PY device, so the controlling program can set them. o It should be possible to get the TW terminal characteristics through the PY device, so the controlling program can see them. o The TW device driver should notify the controlling program (via the associated mailbox) whenever the TW 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 TW'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 TW device and use a SETMODE 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. 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@nrc.com Network Research Co. kvc@ymir.bitnet May 29, 1988 (supersedes NOTES.TXT dated December 9, 1986)