Path: utzoo!attcan!uunet!samsung!sdd.hp.com!ucsd!swrinde!emory!hubcap!ncrcae!sauron!wescott From: wescott@Columbia.NCR.COM (Mike Wescott) Newsgroups: comp.sys.ncr Subject: Re: uugetty on Tower to Tower connection Keywords: uugetty Message-ID: <2184@sauron.Columbia.NCR.COM> Date: 13 Jun 90 13:20:22 GMT References: <1685@vela.acs.oakland.edu> Sender: news@sauron.Columbia.NCR.COM Reply-To: wescott@micky.Columbia.NCR.COM (Mike Wescott) Organization: E&M-Columbia, NCR Corp, W Columbia, SC Lines: 44 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 > - 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