naim@nucsrl.UUCP (Naim Abdullah) (11/06/86)
Our uucp log for the system chinet (from whom we get news) shows
the following entry:
UUCP chinet (11/5-17:50-5930) SUCCEEDED (call to chinet )
UUCP chinet (11/5-17:52-5930) FAILED (imsg 1)
**NSC** chinet (11/5-18:08-5944) FAILED (LOGIN)
**NSC** chinet (11/5-18:08-5944) FAILED (call to chinet )
This is produced by the 4.3bsd uucp running on a vax 11/780. Anybody
know what is happening ? I tried looking for NSC in the sources for
uucp but couldn't find it (via egrep NSC /usr/src/usr.bin/uucp/*.[ch]; I
also looked in the aculib and the vms subdirectories but it wasn't
there).
Also "imsg 1" sounds catastrophic because the level 1 is supposed to be
for pretty serious errors. Can anybody explain what can produce an
"imsg 1" ?
I wish somebody "in the know" could write a description of the g protocol
for the rest of us poor slobs who yearn to understand it. Ofcourse, it
would be given only to those who have source licenses.
Naim Abdullah
Dept. of EECS,
Northwestern University,
{ihnp4, chinet}!nucsrl!naimjrw@hropus.UUCP (Jim Webb) (11/07/86)
> Our uucp log for the system chinet (from whom we get news) shows > the following entry: > > UUCP chinet (11/5-17:50-5930) SUCCEEDED (call to chinet ) > UUCP chinet (11/5-17:52-5930) FAILED (imsg 1) > **NSC** chinet (11/5-18:08-5944) FAILED (LOGIN) > **NSC** chinet (11/5-18:08-5944) FAILED (call to chinet ) > I tried looking for NSC in the sources for > uucp but couldn't find it (via egrep NSC /usr/src/usr.bin/uucp/*.[ch] **NSC** is the login of the process (5944) that failed in calling chinet, so it is no wonder it did not show up in an egrep ;-). The imsg() routine is used before any protocol (read g) is used, so I would imagine that either your uucico is messed up, or, more likely, you are having line noise/flow control problems that are messing up its reading of the protocol message. -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Use the Force, Read the Source"