bminnebo@vela.acs.oakland.edu (Brian P. Minnebo) (06/13/90)
Hello,
I have two Tower 600s connect with a rs-232 serial cable, for the purpose
of doing cu's, and uucp type stuff over. A problem I am experiencing is
the remote uugetty not cleaning itself up after a cu.
When the uugetty is initialyzed on both ends of the connection and a cu is
is initiated form on side, everything seems to work fine. However, when I
exit the cu session by logging off the remote host and exiting cu the remote
side does not seem to clean up correctly all the time (leaving a lock file
in /usr/spool/locks). This is most often apparent when I cu from one
direction and exit, then try a cu from the other direction.
I am certain that the cable is correctly wired, and the connections to
the tower are correct. Before my O.S. upgrade this worked fine using only
getty's. I would like this to work correctly using uugetty's, due to the
advantage of using the same lines going in either direction.
Currently one Tower is using SVR2 NCR release 2.01.00, the second Tower
is using SVR3 release 3.00.01. The uugetty options being used on both
sides are " uugetty -r -h ttyxx 19200 ". Any insights as to why these
hang every now and then would be greatly appreciated.
Two related questions:
- Doesn't the speed field in the uugetty option refer to a gettydef
entry rather than a speed in particular? and if so, would it be
better to use the same gettydef entry that a getty would use for
a dialup or login terminal?
- I don't remember why, but I was under the impression that when you
exit a system with a direct connect cable that it would cause the
cu to exit auto-matically, rather than using ~., I understand that
with a modem connection, it is a function of the remote modem setup
to hang up the phone on a logout, shouldn't a direct connect behave
similarily?
Thanks for you time, brian
--
Brian Minnebo | "Did you ask your mother if it was OK to jump
Oakland University | off the roof?" - Hobbes
bminnebo@vela.acs.oakland.edu | "I don't need to ask a question when I already
------------------------------| know what the answer is." - Calvinwescott@Columbia.NCR.COM (Mike Wescott) (06/13/90)
In article <1685@vela.acs.oakland.edu> bminnebo@vela.acs.oakland.edu (Brian P. Minnebo) writes: > A problem I am experiencing is the remote uugetty not cleaning itself > up after a cu. [...] > When the uugetty is initialyzed on both ends of the connection and a cu is > is initiated form on side, everything seems to work fine. However, when I > exit the cu session by logging off the remote host and exiting cu the remote > side does not seem to clean up correctly all the time (leaving a lock file > in /usr/spool/locks). This is most often apparent when I cu from one > direction and exit, then try a cu from the other direction. > Currently one Tower is using SVR2 NCR release 2.01.00, the second Tower > is using SVR3 release 3.00.01. The uugetty options being used on both > sides are " uugetty -r -h ttyxx 19200 ". Any insights as to why these > hang every now and then would be greatly appreciated. There's a bug in the latter releases of the Tower (when you have streams tty drivers) that cause the line to hang. The lock file sitting in the locks directory is NOT a problem as long as the process number in it is no longer valid. To check, cat the lock file (it's ASCII) and then try a ps -fp <number in the lock file> > - Doesn't the speed field in the uugetty option refer to a gettydef > entry rather than a speed in particular? and if so, would it be > better to use the same gettydef entry that a getty would use for > a dialup or login terminal? Possibly, but that won't get around the bug. > - I don't remember why, but I was under the impression that when you > exit a system with a direct connect cable that it would cause the > cu to exit auto-matically, rather than using ~., I understand that > with a modem connection, it is a function of the remote modem setup > to hang up the phone on a logout, shouldn't a direct connect behave > similarily? Yes, it should. Be sure that the remote has HUPCL set. -Mike -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM