Bell Tech HUB6 Serial I/O Problem?

[M.BAKER]

Hi ----

I would appreciate any help or insights on the following problem:

	I am using a Bell Tech HUB6 Serial I/O board (actually
	2 of them) in an AT&T 6386E machine under UNIX(r) System
	V - 3.2.  The problem is as follows:                  

		When a GETTY is running on one of the Bell Tech
		ports, and the session ends, the DTR and RTS
		lines do NOT momentarily deassert to release the
		DATAKIT, or modem, or whatever.  More to the
		point, the writeup for getty(1M) indicates that
		if GETTY is invoked without the -h option
		(we do not use this option in our /etc/inittab
		entry(ies)),    "
					....getty will force a
					hangup on the line by
					setting the speed to
					zero before setting the
					speed to the default or
					specified speed."

		The GETTY entry works just fine on the internal
		"COM1:" [pardon my DOS] port as well as serial
		ports of an AT&T IPC board.  As expected, the
		RTS & DTR lines "waggle" after typing "exit"
		or otherwise logging out.

		I believe that the Bell Tech board is not 
		responding correctly to the set baud rate = 0
		(i.e., hangup) command as requested through the
		c_cflag field in TERMIO control structure/IOCTL
		call.  More correctly, perhaps, the device driver does
		not appear to be doing its job in this case, as the
		DTR & RTS lines change state quite nicely when
		explicitly opening and closing the port.

The next thing to try is a little test program which sets the
baud rate to zero, while watching the RS-232 lines on an analyzer.
I just thought that someone else may have run into this problem.

E-mail replies to "homxc!mrb1" (or whatever you can make work based
on the header) would be greatly appreciated.....however, I will
watch for postings in comp.unix.questions.  Apologies to any
inappropriate group to which this may have been cross-posted, but
I tried to be selective and still drum up a response or two!
By the way, any other narratives on user experience(s) dealing with
Bell Tech would be valuable, too.

Thanks again :-) !

M. Baker
homxc!mrb1 (via UUCP)