jdc@naucse.UUCP (John Campbell) (09/01/89)
Hello. I have my ATT 3B1 (thunde) connected to our campus Ultrix
machine (naucse) via uucp. Most things work just fine--rmail always
works and uucp works if I start from thunde and request the file.
(But rmail works in both directions). USERFILE on naucse has my
/csarea/compserv/jdc path listed in addition to ~uucp (/usr/spool/uucp).
I'm running stock uucp on a 3.51 with 1 fix disk (3.51a?).
If I uucp from naucse (the Ultrix machine) I get the following in
my thunde (3B1) LOGFILE:
naucse!uucp (8/31-4:09:32) (C,10580,0) OK (DIAL ph0 P5232600 18)
naucse!uucp (8/31-4:09:39) (C,10580,0) SUCCEEDED (call to naucse )
naucse!uucp (8/31-4:09:46) (C,10580,0) OK (startup)
naucse!uucp (8/31-4:09:49) (C,10580,0) REQUESTED (S /csarea/compserv/jdc/Xfer/gnused.src1 ~uucp/ jdc)
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 tried the copy the other way and got this gnused.src1 file on the first
try.)
I've watched this stuff happen and it appears that a /usr/spool/uucp/TM*
file is created (note the 32 minutes of traffic) and it seems when the
transfer is complete that I get the dreaded (INPUT FAILURE) message.
For now I've begun to initiate all transfers from the 3B1. This seems
to always work. Any ideas on why I'm having frequent problems going
the other way?
I *think* I've sent small copies down from the naucse machine a couple of
times. I probably haven't given enough info--uustat on naucse, for instance
always says 04000--transfer queued. What are the "tricks" to use to find
out why this is happening?
--
John Campbell ...!arizona!naucse!jdc
CAMPBELL@NAUVAX.bitnet
unix? Sure send me a dozen, all different colors.rhh@alice.UUCP (r hardin) (09/08/89)
In article <1673@naucse.UUCP>, jdc@naucse.UUCP (John Campbell) writes: > 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) check that hardware flow control has been set off. the conversation hangs when a ctrl/s happens to occur in the data.
mhw@lock60.UUCP (Mark H. Weber) (09/09/89)
In article <1673@naucse.UUCP>, jdc@naucse.UUCP (John Campbell) writes: > > If I uucp from naucse (the Ultrix machine) I get the following in > my thunde (3B1) LOGFILE: > > naucse!uucp (8/31-4:09:32) (C,10580,0) OK (DIAL ph0 P5232600 18) > naucse!uucp (8/31-4:09:39) (C,10580,0) SUCCEEDED (call to naucse ) > naucse!uucp (8/31-4:09:46) (C,10580,0) OK (startup) > naucse!uucp (8/31-4:09:49) (C,10580,0) REQUESTED (S /csarea/compserv/jdc/Xfer/gnused.src1 ~uucp/ jdc) > 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) > Here's what I get: uucp gvlv2 (9/6-19:36:46,20543,16) REMOTE REQUESTED (gvlv2!D.gvlv2B2hw2 --> lock60!D.gvlv2S2hw2 (news)) news gvlv2 (9/6-19:42:51,20543,17) IN SEND/SLAVE MODE (INPUT FAILURE) news gvlv2 (9/6-19:42:52,20543,17) FAILED (conversation complete) The transfer succeeds on the next poll. This happened to me several days in a row. I think I know, what's going on in my case, anyway, though. The failure occurs almost exactly 1 hour after the batch transfer began. I have my uudemon set to run once per hour, and I suspect that the current transfer is being clobbered by the new one starting up. I think I have fixed this, by making the uucico startup conditional on whether a lock file exists for the modem port (LCK..ph1 in /usr/spool/uucp). Send me email if you want more info on this. Mark -- Mark H. Weber ( mhw@Lock60.LS.Com or ...!uunet!lgnp1!lock60!mhw or ...gatech!psuvax1!burdvax!gvlv2!lock60!mhw )
mhw@lock60.UUCP (Mark H. Weber) (09/10/89)
In article <9867@alice.UUCP> rhh@alice.UUCP (r hardin) writes: >In article <1673@naucse.UUCP>, jdc@naucse.UUCP (John Campbell) writes: >> 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) > >check that hardware flow control has been set off. the conversation >hangs when a ctrl/s happens to occur in the data. 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? Mark -- Mark H. Weber ( mhw@Lock60.LS.Com or ...!uunet!lgnp1!lock60!mhw or ...gatech!psuvax1!burdvax!gvlv2!lock60!mhw )
rjg@sialis.mn.org (Robert J. Granvin) (09/11/89)
>>> 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."
darryl@lemuria.UUCP (Darryl P. Wagoner) (09/13/89)
In article <9867@alice.UUCP> rhh@alice.UUCP (r hardin) writes: >In article <1673@naucse.UUCP>, jdc@naucse.UUCP (John Campbell) writes: >> 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) > >check that hardware flow control has been set off. the conversation >hangs when a ctrl/s happens to occur in the data. Is this true? Isn't hardware flow control for CTS/RTS? I have been running my MicroCom AX/2400 using hardware flow control without any problem. I don't know what the problem is but I don't think it is hfc. -- Darryl Wagoner (home) darryl@lemuria.uucp Crosfield-Hastech; OS/2, Just say No! Manchester,NH (w) 603-623-3330 (h) 603-465-7130 UUCP: ubbs-nh!lemuria!dpw