Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!cbosgd!ucbvax!hplabs!pyramid!csg From: csg@pyramid.UUCP (Carl S. Gutekunst) Newsgroups: net.news.adm Subject: Re: Annoying completion messages from uuxqt Message-ID: <565@pyramid.UUCP> Date: Sat, 9-Aug-86 01:18:28 EDT Article-I.D.: pyramid.565 Posted: Sat Aug 9 01:18:28 1986 Date-Received: Sun, 10-Aug-86 19:47:35 EDT References: <117@tslvax.UUCP> <694@mtune.UUCP> <2286@cuae2.UUCP> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Distribution: net Organization: Pyramid Technology Corp., Mountain View, CA Lines: 73 Summary: What UUCP is your feed using? 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.