Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!unisoft!dual!ucbvax!UWOCC1.BITNET!A105 From: A105@UWOCC1.BITNET (Brent Sterner) Newsgroups: mod.computers.vax Subject: Another terminal port problem.... Message-ID: <8611121008.AA16400@ucbvax.Berkeley.EDU> Date: Tue, 11-Nov-86 13:57:00 EST Article-I.D.: ucbvax.8611121008.AA16400 Posted: Tue Nov 11 13:57:00 1986 Date-Received: Wed, 12-Nov-86 20:34:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 36 Approved: info-vax@sri-kl.arpa 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