Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!bionet!ames!ncar!tank!uwvax!umn-d-ub!umn-cs!nis!sialis!rjg
From: rjg@sialis.mn.org (Robert J. Granvin)
Newsgroups: comp.sys.att
Subject: Re: uucp on my 3b1...
Keywords: uucp, 3b1, INPUT FAILURE
Message-ID: <1827@sialis.mn.org>
Date: 11 Sep 89 04:53:07 GMT
References: <1673@naucse.UUCP> <9867@alice.UUCP> <334@lock60.UUCP>
Reply-To: rjg@sialis.mn.org (Robert J. Granvin)
Organization: Dr. Ho Laboratory and Day Care Center
Lines: 30

>>> naucse!jdc (8/31-4:41:05) (C,10580,1) IN SEND/SLAVE MODE (INPUT FAILURE)
>>> naucse!jdc (8/31-4:41:05) (C,10580,1) FAILED (conversation complete)
>
>I am having a similar problem. How do you set hardware flow control off?
>Isn't this already done by uucico (or something similar)? I am using the
>7300's internal modem via /dev/ph1.
>
>If the problem is being caused by a ctrl/s in the data, then why is the
>file able to be transferred with no problem on a subsequent poll?

It's not HFC.  

Basically, stock UUCP under at least certain conditions with the OBM, 
will ignore any lockfile that is over one hour old, making the (incorrect) 
assumption that the job is too old, and therefore must not be active 
anymore (it was a "safety feature" for the original market of the machine).

So, if you have a currently running process that's an hour or more old, and 
you kick off a poll, the lockfile will be ignored, uucico will start up and 
grab the phone line, which will just cause havoc, and your call will die.

If you have your own daemon or cron script that kicks off polls, it's a wise 
measure to make sure that the lockfile is indeed invalid before you just pop 
off to uucico.

-- 
________Robert J. Granvin________        INTERNET: rjg@sialis.mn.org
____National Computer Systems____          BITNET: rjg%sialis.mn.org@cs.umn.edu
__National Information Services__            UUCP: ...amdahl!bungia!sialis!rjg
 "Insured against Aircraft, including self-propelled missiles and spacecraft."