Bell Tech HUB6 problem with hanging up GETTY lines upon exit

[M.BAKER]

Hello -----

Several weeks ago (wow, I guess it's almost a month ago :-)
I posted a question about using the Bell Tech HUB6 board on
getty-driven UNIX SysV/386/3.2 terminal lines.  Specifically,
my setup was NOT waggling the DTR & RTS signals when the session
ended (via Ctrl-D, or exit, or whatever).  Both the AT&T IPC
board and the built-in serial port COM1: worked "OK".  The problem
manifested itself when talking to a RADIAN host port....the machine
never released the connection through the PSDN and the LAN port   
remained "busy" (until you pulled the plug momentarily).

Well, I got several nice replies from net-readers as well as a
phone call.  THANKS to all who offered suggestions, etc. --- and
my apologies for this long-delayed summary.

At first, I suspected that the Bell Tech board/driver was not
handling the B0 (hang-up) c_cflag correctly.  But a quick
test program in C proved that idea wrong.

I think I have finally solved the problem in 3 steps:

	1.) We had been using the /etc/inittab entry of

		..... /etc/getty tty4foo 9600

	    for each line.  Well our /etc/gettydefs file
	    also contained a set of "H" entries (as in
	    9600H, 4800H, etc.).   They included the 'hupcl'
	    option, along with the substitution of 'sane' for
	    numerous particular flag settings in the normal
	    '9600' entry.  getty's ruuning on HUB serial ports
	    now use 9600H instead of 9600 in order to take
	    advantage of the alternate definition (I'll bet it's
	    the hupcl that does it :-)  I just didn't want to
	    muck around with changing the '9600' entry which
	    works fine everywhere else).

	2.) The HUB6 card lets you refer to its ports two ways:
	    tty4a-tty4f are non-modem controls ports while
	    tty4A-tty4F are modem controls ports.  Now logic
	    made me originally choose the "big letters" for my
	    getty entries in /etc/inittab (since we wanted
	    'modem' controls) but everything works the way I want
	    when I switch to defining my getty with the "little
	    letters".

At this point, the line dropped just fine when you enter "exit"
command or Ctrl-D to the shell.  However, if you connect via
the dataswitch and get the login prompt, but then disconnect
before entering anything,
the getty never died and kept the line "busied-out".  The solution
here is to:

	3.) Add a -t (timeout) option onto the getty entry in
	    /etc/inittab.  I used 60 seconds....that seems about
	    right....plenty of time to get that login keyed in,
	    while still saving a long walk to the system in order
	    to jiggle wires and unjam the RADIAN port.

Sorry this may be a bit wordy, but I hope it might save someone
else a bit of time and trouble if they are ever in this (or a similar
situation).  Once again, thanks for everyone's help!

M. Baker
homxc!mrb1