Xref: utzoo comp.unix.xenix:3213 comp.unix.microport:1469
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!mordor!joyce!zodiac!ames!killer!dcs!wnp
From: wnp@dcs.UUCP (Wolf N. Paul)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Re: Buggy UUCP (was: Re: Bell Tech 386 SysVr3)
Message-ID: <193@dcs.UUCP>
Date: 2 Sep 88 11:49:58 GMT
References: <25145@ucbvax.BERKELEY.EDU> <465@sp7040.UUCP> <11643@steinmetz.ge.com> <936@cerebus.UUCP> <7013@icdi10.uucp> <12017@steinmetz.g <385@pigs.UUCP> <394@marob.MASA.COM>
Reply-To: wnp@dcs.UUCP (Wolf N. Paul)
Organization: DCS, Dallas, Texas
Lines: 56

In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
>>i am currently having trouble on three systems i administer with LCK..
>>files for the terminals getting nuked.  one of the systems runs the
>>"telebit" uucp.  the others don't (because they don't run xenix).
>Funny you should mention nuked LCK.. files. I just began noticing the
>same thing on a system which just got updated with the TeleBit uucp.
>In this case the problem occurs when non-uucp communications programs
>(such as Kermit, ProComm or `CU') placed the LCK.. files there. The
>new uucico (having been started from some daemon) seems to disbelieve
>these `foreign' LCK.. files and unlinks them.

I believe that's because of the way UUCP-related programs determine the
validity of lock files.

Pre-HDB versions (under Sys V, don't know for sure about Xenix) write
(a) their PID in a binary format ( write(fd,&PID, sizeof(PID)) ) into
the lock file, and (b) touch the lockfile regularly to make sure it
doesn't grow older than (I think) an hour. Other programs are supposed
to either check the age of the lockfile, or otherwise (if available on
your system) use the syntax kill(PID, 0) to determine if the process
owning the lock file is still alive.

HDB uucp doesn't care about the age of the lock files, but uses an
ASCII-format PID (fprintf(fp, "%10.10d\n", PID)) to identify the owner of a lock file,
and then determines the validity of that PID by means of kill(PID,0).

Most of the non-uucp communications programs I have come across
have very weak lockfile handling, and do not conform to either of these
rules. 

If you use the cu that came with your system, and the uucico that came with
your system, they should cooperate. If you acquired a different uucico
(i.e. Trailblazer), you might want to check what format the LCK..* files
are it creates -- od -c might do that. If the cu (old) uses binary PIDS
and the uucico (new) uses ASCII PIDS, you will see the symptoms you 
describe above. You need to pester your vendor for a compatible version of
cu.

If you use kermit, or pcomm, or any other public-domain comm program, 
try to get source and fix it.

Sorry I don't know how lockfiles would be handled in a DOS-under-UNIX
environment, which is the only way to run ProComm -- but again, I 
suspect that the lockfile format is incompatible.

The "+++" and "ATH" is legitimate. uucico has just tried to call once,
and has been unsuccessful because the modem, being otherwise occupied,
did not dial, or otherwise respond in a way uucico recognizes. So
uucico tries to hang up (which is what you see), and attempts to call
again. You probably should have seen the dial command from uucico a
little while before the hangup -- if you missed it, it's probably because
it had less drastic results than the hangup command.
-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:     killer!dcs!wnp                 ESL: 62832882
DOMAIN:   dcs!wnp@killer.dallas.tx.us    TLX: 910-380-0585 EES PLANO UD