A105@UWOCC1.BITNET (Brent Sterner) (11/11/86)
I'm not a communications guru, but the following has been reported to me. Perhaps there is a solution. We run a KERMIT command procedure to allow outbound connections from our 8600 for connecting into any of our other systems. The connection is from the 8600 port to the input side of the PACX, so the user can go anywhere he likes. Originally we used Gandalf mini-modems (LDS 126) between the 8600 and the PACX, but some services (eg DATAPAC in Canada) can be terminated ungracefully, leaving a "stuck" logical connection in the PACX. To address the stuck connections, we attempted to drop DTR and raise it again (set terminal/nomodem, then /modem) within the KERMIT.COM when the port was allocated. Unfortunately the mini-modems failed to pass on the change in DTR, so we tried a more inteligent (powered) modem in its place (LDS 120). This appears to work just fine, but now there seems to be another problem, this time when the ports are NOT in use. The symptom we see is a periodic a) DTR drop, b) 2 seconds later RTS drop, c) 5-6 seconds later both DTR and RTS come up together. This activity does not make the PACX very happy. This activity is considered to be a connection request. These requests are logged on the statistics port of the PACX and swallowed and digested by a process on each of our systems, incurring significant overhead. Worse than that, the PACX gets very upset after a while and blacklists the port. Does anyone have any idea of the origin of this deadly handshake? The powered modems seem to be necessary, and will do the job for us if we can just stop this undesirable activity. Any suggestions? Brent Sterner Computing & Communications Services Natural Sciences Building The University of Western Ontario London, Ontario, Canada N6A 5B7 Telephone (519)661-2151 x6036 Network <A105@UWOCC1.BITNET>
SIT.BUSH@CU20B.COLUMBIA.EDU (Nick Bush) (11/12/86)
I ran into the same problem while doing almost exactly the same thing. The problem occurs because of the way VMS and the PACX handle the port: When no one has the port allocated under VMS and it is set to /MODEM, VMS will keep DTR high, waiting for a phone call. The PACX sees DTR high and assumes that the terminal on the line (in this case the VAX) wants to talk to it so it raises CD and DSR. VMS sees these, thinks the modem has answered a phone call so it starts its timer waiting for someone to attempt to log in. After nothing happens for a little while, the timer expires and VMS drops DTR to hang up the phone. After a couple of seconds, VMS will raise DTR again, starting the loop all over again. The solution to this is simple. Set the permanent terminal characteristics to /NOMODEM so that DTR will only be on when someone is actually trying to use the port to "dial out (have your "KERMIT.COM" set /MODEM). You should also have the terminal set /NOTYPEAHEAD as a permanent characteristic and set /TYPEAHEAD in your command file. This will avoid any possibility of a loop between the PACX and the VAX. - Nick Bush SIT.BUSH@CU20B.COLUMBIA.EDU SIT.BUSH@CU20B (BITNET) -------