tim@tslvax.UUCP (Timothy Beres) (08/05/86)
Hi,
For about 7 months now (I'm busy) our newsfeed is sent by us (tslvax)
the following message to root after news (only news, not mail)
is done:
uuxqt cmd (rcnews) status (exit 0, signal 0)
Being that I have had a few spare nanoseconds, I thought I would track
this down. I came up with zero. I thought it was because our uucp lacked
the -z option, as explained in the USENET installation manual; our uucp,
however, does have this option. I reviewed our news* programs and
uucp programs, remade everything after careful review, and nothing changed.
A fellow administrator (Mikel Manitius - ATT I.S.) suggested that it
was our feed requesting successful completion confirmation, and not our
site. I had our site check, but they say it ain't us.
What gives? Thanks in advance!
* NEWS is 2.10.2 with few, if any patches installed; using batched transfers;
System V release 2 on a VAX 750; Hayes Smartmodem.
--
...!ihnp4!{duke, akgua}!ucf-cs!tslvax!tim Tim Beres
Tech-Source # subsidiary of Ciprico, Inc.jhc@mtune.UUCP (Jonathan Clark) (08/07/86)
In article <117@tslvax.UUCP> tim@tslvax.UUCP (Timothy Beres) writes: > For about 7 months now (I'm busy) our newsfeed is sent by us (tslvax) >the following message to root after news (only news, not mail) is done: > > uuxqt cmd (rcnews) status (exit 0, signal 0) Isn't this just a result of invoking uux (from sys) without the -n option? Without this it helpfully tells you what happened to your uux command. -- Jonathan Clark [NAC,attmail]!mtune!jhc My walk has become rather more silly lately.
heiby@cuae2.UUCP (Ron Heiby) (08/07/86)
In older UUCP implementations, the "-z" flag to uux(1) meant that failure
notifications should be sent back to the job originator. In modern UUCP
implementations, that behaviour is the default, and the "-z" flag means
"Send *success* notifications back to the originator." If you take the
"-z" flag out of the uux(1) command line(s) in your defs.h file as well
as your sendbatch and/or csendbatch file, this annoyance should disappear.
--
Ron Heiby {NAC|ihnp4}!cuae2!heiby Moderator: mod.newprod & mod.os.unix
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
"'Cause there's lots of things in this world that need to BE turned around."grr@cbmvax.cbm.UUCP (George Robbins) (08/09/86)
In article <117@tslvax.UUCP> tim@tslvax.UUCP (Timothy Beres) writes: > > For about 7 months now (I'm busy) our newsfeed is sent by us (tslvax) >the following message to root after news (only news, not mail) >is done: > > uuxqt cmd (rcnews) status (exit 0, signal 0) > >Being that I have had a few spare nanoseconds, I thought I would track >this down. I came up with zero. I thought it was because our uucp lacked >the -z option, as explained in the USENET installation manual; our uucp, >however, does have this option. I reviewed our news* programs and >...!ihnp4!{duke, akgua}!ucf-cs!tslvax!tim Tim Beres >Tech-Source # subsidiary of Ciprico, Inc. The problem is most likely that the system feeding you is not sending your system the flag corresponding to the -z or -n on it's end. First, check that they are actually trying to send you the flag - many flavors of uucp default to no messages if no error, or make special allowances for programs named 'rmail' or 'rnews', so they may never have had to bother with the switch. Unfortunatly, the news installation documents make an issue of these switches but don't clearly explain what's going on. And if they are not implemented or documented on your system, then things can really get confusing. Here: -z Send completion messages only for non-zero return codes -n Never send completion messages Defaults vary and may be sensitive to particular program names. The simplest way I've found to test the action of the various switches is to add the programs 'true' and 'false' to your L-commands file, and then remotely try to execute these with different switches. You can also create something called rnews which is actually a link to true or false. If the sytem feeding you has a flavor of uucp that can't generate either switch, it's not too hard to patch their uux executable to modifiy the sprintf format used to write the command so that it includes the -n option. Too messy to explain here... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
csg@pyramid.UUCP (Carl S. Gutekunst) (08/09/86)
In article <117@tlsvax.UUCP> tim@tslvax.UUCP (Timothy Beres) writes: > For abut 7 months now (I'm busy) our newsfeed is sent by us (tslvax) >the following message to root after news is done: > > uuxqt cmd (rcnews) status (exit 0, signal 0) > >.... I thought it was because our uucp lacked >the -z option, as explained in the USENET installation manual; our uucp, >however, does have this option. In article <2286@cuae2.UUCP> heiby@cuae2.UUCP (-Ron Heiby) writes: >.... In modern UUCP implementations .... the "-z" flag means >"Send *success* notifications back to the originator." If you take the >"-z" flag out of the uux(1) command line(s) in your defs.h file as well >as your sendbatch and/or csendbatch file, this annoyance should disappear. This suggestion is one-third right. It's tlsvax's *feed* (ucf-cs?) that would have to change their defs.h, not tlsvax itself. And it assumes that ucf-cs is running HoneyDanBer UUCP (which is, I presume, what you meant by "modern." :-)) To understand what's really happening here, one has to consider the uux(1C) command on the feed, what it writes to the UUCP Job Control Language (or 'X.') file, and how the JCL stream is interpreted by the command executor, uuxqt(1M) (or uuxqt(8) for Berkeloids). The JCL stream includes the command to be executed, a list of all files needed by the command, stdin and stdout redirections, and miscellaneous flags. If not specified otherwise in the JCL stream, uuxqt always mails back a command com- pletion acknowledgement to the originator of the request. If an 'N' command appears, then no acknowledgement is set back. Both 4.2bsd and HoneyDanBer added a new command to the JCL, 'Z', meaning send back an acknowledgement only if the program run by uuxqt exits with a non-zero status. HDB also added an 'n' command, to send back an ack on zero status. (On non-zero status, HDB also mails back a copy of the stderr from the command.) All versions of uux(1C) provide the '-n' option, which is written into the JCL as the 'N' command. 4.2bsd uux(1C) provides '-z', which is mapped into the JCL as the 'Z' command (meaning "send acknowledgement only on error"). Version 7, System V, and early SVR2 versions of uux don't have the '-z' flag at all. For these, a set of patches is provided in the Netnews distribution to modify uux to accept the '-z' option as 4.2bsd does, and to modify uuxqt to understand the JCL 'Z' command. HoneyDanBer uux(1C) always writes the 'Z' command into the JCL stream, so by default uuxqt(1M) will return a message only on a non-zero exit. The '-z' opt causes HDB uux(1C) to write both a 'Z' command and an 'n' command, meaning "send an ack on error, *and* send an ack when there is no error." The '-n' option writes only an 'N' command. SUMMARY: Timothy states that his uux(1C) does have the '-z' option. This implies that his uuxqt will correctly interpret 'Z' commands in the JCL. So the problem has to be at his feed. If the feed is running HoneyDanBer, then they should *not* use the '-z' option on uux(1C); if they are running 4.2 or 4.3bsd, then they *should* include the '-z'. If they are running something else (like version 7 or System VR1) they will have to apply the Netnews patches to add BSD-like '-z' support to their UUCP. If Timothy misunderstood something and his uux(1C) does not really have any kind of '-z', then he'll have to patch his own UUCP so that his uuxqt doesn't throw away the Z command. Worst come to worst, he can also look at the X. files himself and see if they make sense. If no 'Z' command is seen, then the feed is not running HDB and either needs to use the '-z' option or fix their code. If both 'Z' and 'n' are there, then the feed is running HDB and needs to remove the '-z' option. If neither of these is the case, it's tlsvax's problem. Hope this clarifies a rather esoteric point about UUCP. <csg>