Attached you will find a little hack, erm, 'workaround' :-). It allows me (and hopefully you) to connect a modem to the TTA2: port of a VAX- station 3100 AND set the port /MODEM. With this little piece of soft- ware a process which is logged in via TTA2: is really deleted when the connection aborts. A process that has dialed out gets notified of the hangup. Most people know that you can not do this with the default setup (at least I have never heard about it). I won't go into the detail; it has been discussed several times in the past. During my test I've found out that there are still situations when the system still says: %LOGIN-F-NOTMODEM, VAX/VMS host system modem not wired correctly; contact your system manager It looks to me that this only happens, when the modem somehow drops carrier during the login phase or when a login-process is started after powering down the modem. I've seen no problems during successfull callins or callouts. Uwe ZEssin, zessin@decus.decus.de --- Here is what to do: At first you need to get a modified cable. Connect common ground, receive and transmit data as usual. Connect DTR from the VAXstation to DTR of the modem and tell the modem to honor DTR. Now connect CD (carrier detect) from the modem to DSR of the VAXstation. Yes, that's right! Do not forget to tell the modem that CD must reflect the state of the carrier; it must not 'force CD high'! I know that the system parameter TTY_DIALTYPE is somehow related with the timing of the modem signals. My software works when I use the default setup where the value is 0. I haven't tried to fiddle with this and I have not tried to understand the mechanisms behind it. Lazy, but true... Assemble and link the program: $ MACRO DSMOD_LOAD $ LINK DSMOD_LOAD To run the program you can either define a foreign command or RUN it directly: 1. $ DSMOD_LOAD == "$device:[directory]DSMOD_LOAD" $ DSMOD_LOAD TTA2: 2. $ run DSMOD_LOAD _Device: TTA2: Now the code has been loaded and activated. If you enter the name of a device that is not a terminal port the program will come back with the message: %SYSTEM-F-IVDEVNAM, invalid device name That's the best I could find... After the code is active you can set the port /PERMANENT/MODEM. Here is my setup: Terminal Characteristics: Interactive Echo Type_ahead No Escape No Hostsync TTsync Lowercase Tab Wrap Scope No Remote Eightbit No Broadcast No Readsync No Form Fulldup Modem No Local_echo No Autobaud Hangup No Brdcstmbx No DMA Altypeahd Set_speed No Commsync Line Editing Overstrike editing No Fallback Dialup Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics No Soft Characters No Printer Port Numeric Keypad ANSI_CRT No Regis No Block_mode Advanced_video Edit_mode DEC_CRT DEC_CRT2 DEC_CRT3 No DEC_CRT4 VMS Style Input --- Here is what it does and how it works: The loader part gets the device name from the command line and checks whether this is a terminal port. I admit that one could include more checks (you can even specify the name of a RTA-terminal), but hey, I didn't wanted to make it too much complicated. It then goes into kernel mode and gets the UCB address of the specified device. Now it allocates some non-paged memory and copies the modification code into that block. The loader calculates the address of the terminal class driver vector table and the address of the CLASS_DS_TRANS vector. Please refer to the 'OpenVMS VAX Device Support Manual'. It is in Chapter 18, more precise 18.5.3 in the manual that I have access to. By the way: the symbolic name specifying the offset is named CLASS_DS_TRAN without a trailing 'S'. The address of the specified device's (normally TTA2:) UCB is stored at a specific location in the allocated block for later use. This allows you to run the loader multiple times specifying different device names. The modification codes are then simply chained. Well, that doesn't make sense on my VAXstation 3100, but it was not a big deal and perhaps someone can use that feature. That, by the way, is the reason that you must specify the device name. Back to the code. The old vector is stored in the allocated block, too, because it is needed to either jump to the terminal class driver or chain to the next piece of code if you ran the loader multiple times. Now the old vector is overwritten with the address of the modification code and THIS has activated the code! Please note that if you do this multiple times the code that has been first loaded will be executed at the last one in the chain. The loader will then return from kernel mode and get back to DCL. The modification code is now active and can be called via the CLASS_DS_TRAN(S) vector from the terminal port driver. If will only act when the transition type is MODEM$C_DATASET and register R5 points to the UCB of the device specified at load time. When this is true it will check if the DSR signal (which really is the CD signal due to the modified cable!) is cleared. If not, it will raise CD and CTS as well. This avoids the DTR-repeatedly- drops-after-30-seconds problem that many have seen. If DSR is cleared the code will clear CD and CTS as well. I have not bothered to check if this is really necessary. Better safe than sorry. Finally the code jumps to the address that was stored in the old vector. This can either be the real address of the terminal class driver routine or the entry of a previously loaded modificatin code. CD, CTS and DSR will look like 'hard-wired' together (hm, ever heard about 'soft-wired' or 'soft-soldered' ? :-), but it does work on OpenVMS VAX Version 6.0. --- I'd like to mention that programming in MACRO or internals pro- gramming is NOT my daily job. Please forgive me, if some parts look, err, 'strange' to you. However I DO appreciate feedback to make things better next time ;-). I have also thought about an enhancement that allows the unloading of the code, but it looks a bit more complicated to me to do that in a safe way and I don't want you to come to me and tell me that your system has crashed. Perhaps in the next release ...