jfh@rpp386.Dallas.TX.US (The Beach Bum) (10/22/88)
In article <1130@lakesys.UUCP> jamesd@lakesys.UUCP (James Dicke) writes: >If cu doesn't work there is one way that I know to take care of it all. I use >a script to "disable /dev/ttyxx" before entering "cu" and then I "enable >/dev/ttyxx" when finished. This prevents uucico from cutting in. I too run >286 version of Xenix (though its 2.2.3). There should be no need to do this. disable only prevents someone from logging in on a line. cu should have a LCK.. file present on the line while it is in use. uucico should see this LCK.. file prior to starting up and then NOT use the line. Assuming SCO hasn't done something completely stupid, this means that getty or no getty, uucico shouldn't be stomping on your cu session. However, it obviously is. Someone needs to find out for once and for all WHO is eating lock files. I've seen it with lines enabled and not. What gives? -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (10/27/88)
I have been told that if you get the telebit upgrade to uucp and install
the new uucico without the new cu that there will be lock problems. I
installed them both, so I can't say, but there was a discussion of this
in another forum several months ago.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me