Add UUCP info documentation.

Lack pointed out by Hans Guenter Weigand <hgw@d1906.inka.de>.
- Virgin import of Taylor UUCP 1.06.1 texinfo doc.
- Makefile largely by millert@
ok millert@

3 files changed, 8389 insertions, 2 deletions

diff --git a/gnu/libexec/uucp/Makefile b/gnu/libexec/uucp/Makefile
index ad25c3f180e..ca23f05ab5e 100644
--- a/gnu/libexec/uucp/Makefile
+++ b/gnu/libexec/uucp/Makefile
@@ -1,9 +1,9 @@
 # This is the Makefile for Taylor UUCP
-# $Id: Makefile,v 1.2 1996/12/08 22:39:31 tholo Exp $
+# $Id: Makefile,v 1.3 2000/12/21 13:44:25 naddy Exp $
 
 SUBDIR=		libunix libuucp libuuconf \
 		cu uuchk uucico uuconv uucp uulog uuname uupick uusched \
 		uustat uuto uux uuxqt \
-		sample
+		doc sample
 
 .include <bsd.subdir.mk>
diff --git a/gnu/libexec/uucp/doc/Makefile b/gnu/libexec/uucp/doc/Makefile
new file mode 100644
index 00000000000..025202d7ad8
--- /dev/null
+++ b/gnu/libexec/uucp/doc/Makefile
@@ -0,0 +1,21 @@
+#	$OpenBSD: Makefile,v 1.1 2000/12/21 13:44:25 naddy Exp $
+
+INFO = uucp.info uucp.info-1 uucp.info-2 uucp.info-3 uucp.info-4 \
+       uucp.info-5 uucp.info-6 uucp.info-7 uucp.info-8
+SRCS = uucp.texi
+
+all: ${INFO}
+
+${INFO}: ${SRCS}
+	makeinfo ${.CURDIR}/${SRCS}
+
+clean cleandir:
+	-rm -f ${INFO}
+
+install: ${INFO}
+	 ${INSTALL} ${INSTALL_COPY} -o ${DOCOWN} -g ${DOCGRP} -m ${DOCMODE} ${INFO} ${DESTDIR}${SHAREDIR}/info
+	 install-info --info-dir=${DESTDIR}${SHAREDIR}/info uucp.info
+
+.include <bsd.own.mk>
+.include <bsd.obj.mk>
+.include <bsd.subdir.mk>
diff --git a/gnu/libexec/uucp/doc/uucp.texi b/gnu/libexec/uucp/doc/uucp.texi
new file mode 100644
index 00000000000..769225a549a
--- /dev/null
+++ b/gnu/libexec/uucp/doc/uucp.texi
@@ -0,0 +1,8366 @@
+\input texinfo   @c -*-texinfo-*-
+@c %**start of header
+@setfilename uucp.info
+@settitle Taylor UUCP
+@setchapternewpage odd
+@c %**end of header
+
+@iftex
+@finalout
+@end iftex
+
+@ifinfo
+@format
+START-INFO-DIR-ENTRY
+* UUCP: (uucp).                 Transfer mail and news across phone lines.
+END-INFO-DIR-ENTRY
+@end format
+
+This file documents Taylor UUCP, version 1.06.
+
+Copyright @copyright{} 1992, 1993, 1994, 1995 Ian Lance Taylor
+
+Permission is granted to make and distribute verbatim copies of this
+manual provided the copyright notice and this permission notice are
+preserved on all copies.
+
+@ignore 
+Permission is granted to process this file through TeX and print the
+results, provided the printed document carries a copying permission
+notice identical to this one except for the removal of this paragraph
+(this paragraph not being relevant to the printed manual).
+
+@end ignore
+Permission is granted to copy and distribute modified versions of this
+manual under the conditions for verbatim copying, provided also that the
+section entitled ``Copying'' are included exactly as in the original, and
+provided that the entire resulting derived work is distributed under the
+terms of a permission notice identical to this one.
+
+Permission is granted to copy and distribute translations of this manual
+into another language, under the above conditions for modified versions,
+except that the section entitled ``Copying'' may be included in a
+translation approved by the author instead of in the original English.
+@end ifinfo
+
+@titlepage
+@title Taylor UUCP
+@subtitle Version 1.06
+@author Ian Lance Taylor @code{<ian@@airs.com>}
+
+@page
+@vskip 0pt plus 1filll
+Copyright @copyright{} 1992, 1993, 1994, 1995 Ian Lance Taylor
+
+Published by Ian Lance Taylor @code{<ian@@airs.com>}.
+
+Permission is granted to make and distribute verbatim copies of this
+manual provided the copyright notice and this permission notice are
+preserved on all copies.
+
+Permission is granted to copy and distribute modified versions of this
+manual under the conditions for verbatim copying, provided also that the
+section entitled ``Copying'' are included exactly as in the original, and
+provided that the entire resulting derived work is distributed under the
+terms of a permission notice identical to this one.
+
+Permission is granted to copy and distribute translations of this manual
+into another language, under the above conditions for modified versions,
+except that the section entitled ``Copying'' may be included in a
+translation approved by the author instead of in the original English.
+@end titlepage
+
+@node Top, Copying, (dir), (dir)
+@top Taylor UUCP 1.06
+
+This is the documentation for the Taylor UUCP package, version 1.06.
+The programs were written by Ian Lance Taylor.  The author can be
+reached at @code{<ian@@airs.com>}, or at
+@display
+Ian Lance Taylor
+c/o Cygnus Support
+48 Grove Street
+Somerville, MA 02144
+USA
+@end display
+
+There is a mailing list for discussion of the package.  The list is
+hosted by Eric Schnoebelen at @code{cirr.com}.  To join (or get off) the
+list, send mail to @code{taylor-uucp-request@@cirr.com}.  Mail to this
+address is answered by the majordomo program.  To join the list, send
+the message @samp{subscribe @var{address}} where @var{address} is your
+e-mail address.  To send a message to the list, send it to
+@code{taylor-uucp@@cirr.com}.  The old list address,
+@code{taylor-uucp@@gnu.ai.mit.edu}, will also work.  There is an archive
+of all messages sent to the mailing list at @code{ftp.cirr.com}.
+
+@menu
+* Copying::                     Taylor UUCP Copying Conditions
+* Introduction::                Introduction to Taylor UUCP
+* Invoking the UUCP Programs::  Invoking the UUCP Programs
+* Installing Taylor UUCP::      Installing Taylor UUCP
+* Using Taylor UUCP::           Using Taylor UUCP
+* Configuration Files::         Taylor UUCP Configuration Files
+* Protocols::                   UUCP Protocol Descriptions
+* Hacking::                     Hacking Taylor UUCP
+* Acknowledgements::            Acknowledgements
+
+* Index (concepts)::            Concept Index
+* Index (configuration file)::  Index to New Configuration Files
+
+ --- The Detailed Node Listing ---
+
+Invoking the UUCP Programs
+
+* Standard Options::            Standard Options for the UUCP Programs
+* Invoking uucp::               Invoking uucp
+* Invoking uux::                Invoking uux
+* Invoking uustat::             Invoking uustat
+* Invoking uuname::             Invoking uuname
+* Invoking uulog::              Invoking uulog
+* Invoking uuto::               Invoking uuto
+* Invoking uupick::             Invoking uupick
+* Invoking cu::                 Invoking cu
+* Invoking uucico::             Invoking uucico
+* Invoking uuxqt::              Invoking uuxqt
+* Invoking uuchk::              Invoking uuchk
+* Invoking uuconv::             Invoking uuconv
+* Invoking uusched::            Invoking uusched
+
+Invoking uucp
+
+* uucp Description::            Description of uucp
+* uucp Options::                Options Supported by uucp
+
+Invoking uux
+
+* uux Description::             Description of uux
+* uux Options::                 Options Supported by uux
+* uux Examples::                Examples of uux Usage
+
+Invoking uustat
+
+* uustat Description::          Description of uustat
+* uustat Options::              Options Supported by uustat
+* uustat Examples::             Examples of uustat Usage
+
+Invoking cu
+
+* cu Description::              Description of cu
+* cu Commands::                 Commands Supported by cu
+* cu Variables::                Variables Supported by cu
+* cu Options::                  Options Supported by cu
+
+Invoking uucico
+
+* uucico Description::          Description of uucico
+* uucico Options::              Options Supported by uucico
+
+Installing Taylor UUCP
+
+* Compilation::                 Compiling Taylor UUCP
+* Testing the Compilation::     Testing the Compilation
+* Installing the Binaries::     Installing the Binaries
+* Configuration::               Configuring Taylor UUCP
+* Testing the Installation::    Testing the Installation
+
+Using Taylor UUCP
+
+* Calling Other Systems::       Calling Other Systems
+* Accepting Calls::             Accepting Calls
+* Mail and News::               Using UUCP for Mail and News
+* The Spool Directory Layout::  The Spool Directory Layout
+* Spool Directory Cleaning::    Cleaning the UUCP Spool Directory
+
+Using UUCP for Mail and News.
+
+* Sending mail or news::        Sending mail or news via UUCP
+* Receiving mail or news::      Receiving mail or news via UUCP
+
+The Spool Directory Layout
+
+* System Spool Directories::    System Spool Directories
+* Status Directory::            Status Spool Directory
+* Execution Subdirectories::    Execution Spool Subdirectories
+* Other Spool Subdirectories::  Other Spool Subdirectories
+* Spool Lock Files::            Spool Directory Lock Files
+
+Taylor UUCP Configuration Files
+
+* Configuration Overview::      Configuration File Overview
+* Configuration File Format::   Configuration File Format
+* Configuration Examples::      Examples of Configuration Files
+* Time Strings::                How to Write Time Strings
+* Chat Scripts::                How to Write Chat Scripts
+* config File::                 The Main Configuration File
+* sys File::                    The System Configuration File
+* port File::                   The Port Configuration Files
+* dial File::                   The Dialer Configuration Files
+* UUCP Over TCP::               UUCP Over TCP
+* Security::                    Security Issues
+
+Examples of Configuration Files
+
+* config File Examples::        Examples of the Main Configuration File
+* Leaf Example::                Call a Single Remote Site
+* Gateway Example::             The Gateway for Several Local Systems
+
+The Main Configuration File
+
+* Miscellaneous (config)::      Miscellaneous config File Commands
+* Configuration File Names::    Using Different Configuration Files
+* Log File Names::              Using Different Log Files
+* Debugging Levels::            Debugging Levels
+
+The System Configuration File
+
+* Defaults and Alternates::     Using Defaults and Alternates
+* Naming the System::           Naming the System
+* Calling Out::                 Calling Out
+* Accepting a Call::            Accepting a Call
+* Protocol Selection::          Protocol Selection
+* File Transfer Control::       File Transfer Control
+* Miscellaneous (sys)::         Miscellaneous sys File Commands
+* Default sys File Values::     Default Values
+
+Calling Out
+
+* When to Call::                When to Call
+* Placing the Call::            Placing the Call
+* Logging In::                  Logging In
+
+UUCP Over TCP
+
+* TCP Client::                  Connecting to Another System Over TCP
+* TCP Server::                  Running a TCP Server
+
+UUCP Protocol Internals
+
+* UUCP Protocol Sources::       Sources for UUCP Protocol Information
+* UUCP Grades::                 UUCP Grades
+* UUCP Lock Files::             UUCP Lock Files
+* Execution File Format::       Execution File Format
+* UUCP Protocol::               UUCP Protocol
+* g Protocol::                  g protocol
+* f Protocol::                  f protocol
+* t Protocol::                  t protocol
+* e Protocol::                  e protocol
+* Big G Protocol::              G protocol
+* i Protocol::                  i protocol
+* j Protocol::                  j protocol
+* x Protocol::                  x protocol
+* y Protocol::                  y protocol
+* d Protocol::                  d protocol
+* h Protocol::                  h protocol
+* v Protocol::                  v protocol
+
+UUCP Protocol
+
+* The Initial Handshake::       The Initial Handshake
+* UUCP Protocol Commands::      UUCP Protocol Commands
+* The Final Handshake::         The Final Handshake
+
+UUCP Protocol Commands
+
+* The S Command::               The S Command
+* The R Command::               The R Command
+* The X Command::               The X Command
+* The E Command::               The E Command
+* The H Command::               The H Command
+
+Hacking Taylor UUCP
+
+* System Dependence::           System Dependence
+* Naming Conventions::          Naming Conventions
+* Patches::                     Patches
+@end menu
+
+@node Copying, Introduction, Top, Top
+@unnumbered Taylor UUCP Copying Conditions
+
+This package is covered by the GNU Public License.  See the file
+@file{COPYING} for details.  If you would like to do something with this
+package that you feel is reasonable, but you feel is prohibited by the
+license, contact me to see if we can work it out.
+
+The rest of this section is some descriptive text from the Free Software
+Foundation.
+
+All the programs, scripts and documents relating to Taylor UUCP are
+@dfn{free}; this means that everyone is free to use them and free to
+redistribute them on a free basis.  The Taylor UUCP-related programs are
+not in the public domain; they are copyrighted and there are
+restrictions on their distribution, but these restrictions are designed
+to permit everything that a good cooperating citizen would want to do.
+What is not allowed is to try to prevent others from further sharing any
+version of these programs that they might get from you.
+
+Specifically, we want to make sure that you have the right to give away
+copies of the programs that relate to Taylor UUCP, that you receive
+source code or else can get it if you want it, that you can change these
+programs or use pieces of them in new free programs, and that you know
+you can do these things.
+
+To make sure that everyone has such rights, we have to forbid you to
+deprive anyone else of these rights.  For example, if you distribute
+copies of the Taylor UUCP related programs, you must give the recipients
+all the rights that you have.  You must make sure that they, too,
+receive or can get the source code.  And you must tell them their
+rights.
+
+Also, for our own protection, we must make certain that everyone finds
+out that there is no warranty for the programs that relate to Taylor
+UUCP.  If these programs are modified by someone else and passed on, we
+want their recipients to know that what they have is not what we
+distributed, so that any problems introduced by others will not reflect
+on our reputation.
+
+The precise conditions of the licenses for the programs currently being
+distributed that relate to Taylor UUCP are found in the General Public
+Licenses that accompany them.
+
+@node Introduction, Invoking the UUCP Programs, Copying, Top
+@chapter Introduction to Taylor UUCP
+
+General introductions to UUCP are available, and perhaps one day I will
+write one.  In the meantime, here is a very brief one that concentrates
+on the programs provided by Taylor UUCP.
+
+Taylor UUCP is a complete UUCP package.  It is covered by the GNU Public
+License, which means that the source code is always available.  It is
+composed of several programs; most of the names of these programs are
+based on earlier UUCP packages.
+
+@table @code
+
+@item uucp
+
+The @code{uucp} program is used to copy file between systems.  It is
+similar to the standard Unix @code{cp} program, except that you can
+refer to a file on a remote system by using @samp{system!} before the
+file name.  For example, to copy the file @file{notes.txt} to the system
+@samp{airs}, you would say @samp{uucp notes.txt airs!~/notes.txt}.  In
+this example @samp{~} is used to name the UUCP public directory on
+@samp{airs}.  For more details, see @ref{Invoking uucp, uucp}.
+
+@item uux
+
+The @code{uux} program is used to request the execution of a program on
+a remote system.  This is how mail and news are transferred over UUCP.
+As with @code{uucp}, programs and files on remote systems may be named
+by using @samp{system!}.  For example, to run the @code{rnews} program
+on @samp{airs}, passing it standard input, you would say @samp{uux -
+airs!rnews}.  The @samp{-} means to read standard input and set things
+up such that when @code{rnews} runs on @samp{airs} it will receive the
+same standard input.  For more details, see @ref{Invoking uux, uux}.
+
+@end table
+
+Neither @code{uucp} nor @code{uux} actually do any work immediately.
+Instead, they queue up requests for later processing.  They then start a
+daemon process which processes the requests and calls up the appropriate
+systems.  Normally the system will also start the daemon periodically to
+check if there is any work to be done.  The advantage of this approach
+is that it all happens automatically.  You don't have to sit around
+waiting for the files to be transferred.  The disadvantage is that if
+anything goes wrong it might be a while before anybody notices.
+
+@table @code
+
+@item uustat
+
+The @code{uustat} program does many things.  By default it will simply
+list all the jobs you have queued with @code{uucp} or @code{uux} that
+have not yet been processed.  You can use @code{uustat} to remove any of
+your jobs from the queue.  You can also it use it to show the status of
+the UUCP system in various ways, such as showing the connection status
+of all the remote systems your system knows about.  The system
+administrator can use @code{uustat} to automatically discard old jobs
+while sending mail to the user who requested them.  For more details,
+see @ref{Invoking uustat, uustat}.
+
+@item uuname
+
+The @code{uuname} program by default lists all the remote systems your
+system knows about.  You can also use it to get the name of your local
+system.  It is mostly useful for shell scripts.  For more details, see
+@ref{Invoking uuname, uuname}.
+
+@item uulog
+
+The @code{uulog} program can be used to display entries in the UUCP log
+file.  It can select the entries for a particular system or a particular
+user.  You can use it to see what has happened to your queued jobs in
+the past.  For more details, see @ref{Invoking uulog, uulog}.
+
+@item uuto
+@item uupick
+
+@code{uuto} is a simple shell script interface to @code{uucp}.  It will
+transfer a file, or the contents of a directory, to a remote system, and
+notify a particular user on the remote system when it arrives.  The
+remote user can then retrieve the file(s) with @code{uupick}.  For more
+details, see @ref{Invoking uuto, uuto}, and see @ref{Invoking uupick,
+uupick}.
+
+@item cu
+
+The @code{cu} program can be used to call up another system and
+communicate with it as though you were directly connected.  It can also
+do simple file transfers, though it does not provide any error checking.
+For more details, @ref{Invoking cu, cu}.
+
+@end table
+
+These eight programs just described, @code{uucp}, @code{uux},
+@code{uuto}, @code{uupick}, @code{uustat}, @code{uuname}, @code{uulog},
+and @code{cu} are the user programs provided by Taylor UUCP@.
+@code{uucp}, @code{uux}, and @code{uuto} add requests to the work queue,
+@code{uupick} extracts files from the UUCP public directory,
+@code{uustat} examines the work queue, @code{uuname} examines the
+configuration files, @code{uulog} examines the log files, and @code{cu}
+just uses the UUCP configuration files.
+
+The real work is actually done by two daemon processes, which are
+normally run automatically rather than by a user.
+
+@table @code
+
+@item uucico
+
+The @code{uucico} daemon is the program which actually calls the remote
+system and transfers files and requests.  @code{uucico} is normally
+started automatically by @code{uucp} and @code{uux}.  Most systems will
+also start it periodically to make sure that all work requests are
+handled.  @code{uucico} checks the queue to see what work needs to be
+done, and then calls the appropriate systems.  If the call fails,
+perhaps because the phone line is busy, @code{uucico} leaves the
+requests in the queue and goes on to the next system to call.  It is
+also possible to force @code{uucico} to call a remote system even if
+there is no work to be done for it, so that it can pick up any work that
+may be queued up remotely.  For more details, see @ref{Invoking uucico,
+uucico}.
+
+@need 1000
+@item uuxqt
+
+The @code{uuxqt} daemon processes execution requests made by the
+@code{uux} program on remote systems.  It also processes requests made
+on the local system which require files from a remote system.  It is
+normally started by @code{uucico}.  For more details, see @ref{Invoking
+uuxqt, uuxqt}.
+
+@end table
+
+Suppose you, on the system @samp{bantam}, want to copy a file to the
+system @samp{airs}.  You would run the @code{uucp} command locally, with
+a command like @samp{uucp notes.txt airs!~/notes.txt}.  This would queue
+up a request on @samp{bantam} for @samp{airs}, and would then start the
+@code{uucico} daemon.  @code{uucico} would see that there was a request
+for @samp{airs} and attempt to call it.  When the call succeeded,
+another copy of @code{uucico} would be started on @samp{airs}.  The two
+copies of @code{uucico} would tell each other what they had to do and
+transfer the file from @samp{bantam} to @samp{airs}.  When the file
+transfer was complete the @code{uucico} on @samp{airs} would move it
+into the UUCP public directory.
+
+UUCP is often used to transfer mail.  This is normally done
+automatically by mailer programs.  When @samp{bantam} has a mail message
+to send to @samp{ian} at @samp{airs}, it executes @samp{uux - airs!rmail
+ian} and writes the mail message to the @code{uux} process as standard
+input.  The @code{uux} program, running on @samp{bantam}, will read the
+standard input and store it, as well as the @code{rmail} request itself,
+on the work queue for @samp{airs}.  @code{uux} will then start the
+@code{uucico} daemon.  The @code{uucico} daemon will call up
+@samp{airs}, just as in the @code{uucp} example, and transfer the work
+request and the mail message.  The @code{uucico} daemon on @samp{airs}
+will put the files on a local work queue.  When the communication
+session is over, the @code{uucico} daemon on @samp{airs} will start the
+@code{uuxqt} daemon.  @code{uuxqt} will see the request on the work
+queue, and will run @samp{rmail ian} with the mail message as standard
+input.  The @code{rmail} program, which is not part of the UUCP package,
+is then responsible for either putting the message in the right mailbox
+on @samp{airs} or forwarding the message on to another system.
+
+Taylor UUCP comes with a few other programs that are useful when
+installing and configuring UUCP.
+
+@table @code
+
+@item uuchk
+
+The @code{uuchk} program reads the UUCP configuration files and displays
+a rather lengthy description of what it finds.  This is useful when
+configuring UUCP to make certain that the UUCP package will do what you
+expect it to do.  For more details, see @ref{Invoking uuchk, uuchk}.
+
+@item uuconv
+
+The @code{uuconv} program can be used to convert UUCP configuration
+files from one format to another.  This can be useful for administrators
+converting from an older UUCP package.  Taylor UUCP is able to read and
+use old configuration file formats, but some new features can not be
+selected using the old formats.  For more details, see @ref{Invoking
+uuconv, uuconv}.
+
+@item uusched
+
+The @code{uusched} script is provided for compatibility with older UUCP
+releases.  It starts @code{uucico} to call, one at a time, all the
+systems for which work has been queued.  For more details, see
+@ref{Invoking uusched, uusched}.
+
+@item tstuu
+
+The @code{tstuu} program is a test harness for the UUCP package; it can
+help check that the package has been configured and compiled correctly.
+However, it uses pseudo-terminals, which means that it is less portable
+than the rest of the package.  If it works, it can be useful when
+initially installing Taylor UUCP.  For more details, see @ref{Testing
+the Compilation, tstuu}.
+
+@end table
+
+@node Invoking the UUCP Programs, Installing Taylor UUCP, Introduction, Top
+@chapter Invoking the UUCP Programs
+
+This chapter describes how to run the UUCP programs.
+
+@menu
+* Standard Options::            Standard Options for the UUCP Programs
+* Invoking uucp::               Invoking uucp
+* Invoking uux::                Invoking uux
+* Invoking uustat::             Invoking uustat
+* Invoking uuname::             Invoking uuname
+* Invoking uulog::              Invoking uulog
+* Invoking uuto::               Invoking uuto
+* Invoking uupick::             Invoking uupick
+* Invoking cu::                 Invoking cu
+* Invoking uucico::             Invoking uucico
+* Invoking uuxqt::              Invoking uuxqt
+* Invoking uuchk::              Invoking uuchk
+* Invoking uuconv::             Invoking uuconv
+* Invoking uusched::            Invoking uusched
+@end menu
+
+@node Standard Options, Invoking uucp, Invoking the UUCP Programs, Invoking the UUCP Programs
+@section Standard Options
+
+All of the UUCP programs support a few standard options.
+
+@table @samp
+@item -x type
+@itemx --debug type
+Turn on particular debugging types.  The following types are recognized:
+@samp{abnormal}, @samp{chat}, @samp{handshake}, @samp{uucp-proto},
+@samp{proto}, @samp{port}, @samp{config}, @samp{spooldir},
+@samp{execute}, @samp{incoming}, @samp{outgoing}.  Not all types of
+debugging are effective for all programs.  See the @code{debug}
+configuration command for details (@pxref{Debugging Levels}).
+
+Multiple types may be given, separated by commas, and the @samp{--debug}
+option may appear multiple times.  A number may also be given, which
+will turn on that many types from the foregoing list; for example,
+@samp{--debug 2} is equivalent to @samp{--debug abnormal,chat}.  To turn
+on all types of debugging, use @samp{-x all}.
+
+The @code{uulog} program uses @samp{-X} rather than @samp{-x} to select
+the debugging type; for @code{uulog}, @samp{-x} has a different meaning,
+for reasons of historical compatibility.
+
+@item -I file
+@itemx --config file
+Set the main configuration file to use.  @xref{config File}.  When this
+option is used, the programs will revoke any setuid privileges.
+
+@item -v
+@itemx --version
+Report version information and exit.
+
+@item --help
+Print a help message and exit.
+@end table
+
+@need 2000
+@node Invoking uucp, Invoking uux, Standard Options, Invoking the UUCP Programs
+@section Invoking uucp
+
+@menu
+* uucp Description::            Description of uucp
+* uucp Options::                Options Supported by uucp
+@end menu
+
+@node uucp Description, uucp Options, Invoking uucp, Invoking uucp
+@subsection uucp Description
+
+@example
+uucp [options] @file{source-file} @file{destination-file}
+uucp [options] @file{source-file}... @file{destination-directory}
+@end example
+
+The @code{uucp} command copies files between systems.  Each @file{file}
+argument is either a file name on the local machine or is of the form
+@samp{system!file}.  The latter is interpreted as being on a remote
+system.
+
+When @code{uucp} is used with two non-option arguments, the contents of
+the first file are copied to the second.  With more than two non-option
+arguments, each source file is copied into the destination directory.
+
+A file may be transferred to or from @samp{system2} via @samp{system1}
+by using @samp{system1!system2!file}.
+
+Any file name that does not begin with @samp{/} or @samp{~} will be
+prepended with the current directory (unless the @samp{-W} or
+@samp{--noexpand} options are used).  For example, if you are in the
+directory @samp{/home/ian}, then @samp{uucp foo remote!bar} is
+equivalent to @samp{uucp /home/ian/foo remote!/home/ian/bar}.  Note that
+the resulting file name may not be valid on a remote system.
+
+A file name beginning with a simple @samp{~} starts at the UUCP public
+directory; a file name beginning with @samp{~name} starts at the home
+directory of the named user.  The @samp{~} is interpreted on the
+appropriate system.  Note that some shells will interpret an initial
+@samp{~} before @code{uucp} sees it; to avoid this the @samp{~} must be
+quoted.
+
+The shell metacharacters @samp{?} @samp{*} @samp{[} and @samp{]} are
+interpreted on the appropriate system, assuming they are quoted to
+prevent the shell from interpreting them first.
+
+The file copy does not take place immediately, but is queued up for the
+@code{uucico} daemon; the daemon is started immediately unless the
+@samp{-r} or @samp{--nouucico} option is given.  The next time the
+remote system is called, the file(s) will be copied.  @xref{Invoking
+uucico}.
+
+The file mode is not preserved, except for the execute bit.  The
+resulting file is owned by the uucp user.
+
+@node uucp Options,  , uucp Description, Invoking uucp
+@subsection uucp Options
+
+The following options may be given to @code{uucp}.
+
+@table @samp
+@item -c
+@itemx --nocopy
+Do not copy local source files to the spool directory.  If they are
+removed before being processed by the @code{uucico} daemon, the copy
+will fail.  The files must be readable by the @code{uucico} daemon, and
+by the invoking user.
+
+@item -C
+@itemx --copy
+Copy local source files to the spool directory.  This is the default.
+
+@item -d
+@itemx --directories
+Create all necessary directories when doing the copy.  This is the
+default.
+
+@item -f
+@itemx --nodirectories
+If any necessary directories do not exist for the destination file name,
+abort the copy.
+
+@item -R
+@itemx --recursive
+If any of the source file names are directories, copy their contents
+recursively to the destination (which must itself be a directory).
+
+@item -g grade
+@itemx --grade grade
+Set the grade of the file transfer command.  Jobs of a higher grade are
+executed first.  Grades run @kbd{0} to @kbd{9}, @kbd{A} to @kbd{Z},
+@kbd{a} to @kbd{z}, from high to low.  @xref{When to Call}.
+
+@item -m
+@itemx --mail
+Report completion or failure of the file transfer by sending mail.
+
+@item -n user
+@itemx --notify user
+Report completion or failure of the file transfer by sending mail to the
+named user on the destination system.
+
+@item -r
+@itemx --nouucico
+Do not start the @code{uucico} daemon immediately; merely queue up the
+file transfer for later execution.
+
+@item -j
+@itemx --jobid
+Print the jobid on standard output.  The job may be later cancelled by
+passing this jobid to the @samp{-kill} switch of @code{uustat}.
+@xref{Invoking uustat}.
+
+It is possible for some complex operations to produce more than one
+jobid, in which case each will be printed on a separate line.  For
+example
+@example
+uucp sys1!~user1/file1 sys2!~user2/file2 ~user3
+@end example
+will generate two separate jobs, one for the system @samp{sys1} and one
+for the system @samp{sys2}.
+
+@item -W
+@itemx --noexpand
+Do not prepend remote relative file names with the current directory.
+
+@item -t
+@itemx --uuto
+This option is used by the @code{uuto} shell script; see @ref{Invoking
+uuto}.  It causes @code{uucp} to interpret the final argument as
+@samp{system!user}.  The file(s) are sent to
+@samp{~/receive/@var{user}/@var{local}} on the remote system, where
+@var{user} is from the final argument and @var{local} is the local UUCP
+system name.  Also, @code{uucp} will act as though @samp{--notify user}
+were specified.
+
+@item -x type
+@itemx --debug type
+@itemx -I file
+@itemx --config file
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node Invoking uux, Invoking uustat, Invoking uucp, Invoking the UUCP Programs
+@section Invoking uux
+
+@menu
+* uux Description::             Description of uux
+* uux Options::                 Options Supported by uux
+* uux Examples::                Examples of uux Usage
+@end menu
+
+@node uux Description, uux Options, Invoking uux, Invoking uux
+@subsection uux Description
+
+@example
+uux [options] command
+@end example
+
+The @code{uux} command is used to execute a command on a remote system,
+or to execute a command on the local system using files from remote
+systems.  The command is not executed immediately; the request is queued
+until the @code{uucico} daemon calls the system and transfers the
+necessary files.  The daemon is started automatically unless one of the
+@samp{-r} or @samp{--nouucico} options is given.
+
+The actual command execution is done by the @code{uuxqt} daemon on the
+appropriate system.
+
+File arguments can be gathered from remote systems to the execution
+system, as can standard input.  Standard output may be directed to a
+file on a remote system.
+
+The command name may be preceded by a system name followed by an
+exclamation point if it is to be executed on a remote system.  An empty
+system name is taken as the local system.
+
+Each argument that contains an exclamation point is treated as naming a
+file.  The system which the file is on is before the exclamation point,
+and the file name on that system follows it.  An empty system name is
+taken as the local system; this form must be used to transfer a file to
+a command being executed on a remote system.  If the file name is not
+absolute, the current working directory will be prepended to it; the
+result may not be meaningful on the remote system.  A file name may
+begin with @samp{~/}, in which case it is relative to the UUCP public
+directory on the appropriate system.  A file name may begin with
+@samp{~name/}, in which case it is relative to the home directory of the
+named user on the appropriate system.
+
+Standard input and output may be redirected as usual; the file names
+used may contain exclamation points to indicate that they are on remote
+systems.  Note that the redirection characters must be quoted so that
+they are passed to @code{uux} rather than interpreted by the shell.
+Append redirection (@samp{>>}) does not work.
+
+All specified files are gathered together into a single directory
+before execution of the command begins.  This means that each file
+must have a distinct name.  For example,
+@example
+uux 'sys1!diff sys2!~user1/foo sys3!~user2/foo >!foo.diff'
+@end example
+will fail because both files will be copied to @samp{sys1} and stored
+under the name @file{foo}.
+
+Arguments may be quoted by parentheses to avoid interpretation of
+exclamation points.  This is useful when executing the @code{uucp}
+command on a remote system.
+
+Most systems restrict the commands which may be executed using
+@samp{uux}.  Many permit only the execution of @samp{rmail} and
+@samp{rnews}.
+
+A request to execute an empty command (e.g., @samp{uux sys!}) will
+create a poll file for the specified system; see @ref{Calling Other
+Systems} for an example of why this might be useful.
+
+@node uux Options, uux Examples, uux Description, Invoking uux
+@subsection uux Options
+
+The following options may be given to @code{uux}.
+
+@table @samp
+@item -
+@itemx -p
+@itemx --stdin
+Read standard input up to end of file, and use it as the standard input
+for the command to be executed.
+
+@item -c
+@itemx --nocopy
+Do not copy local files to the spool directory.  This is the default.
+If they are removed before being processed by the @code{uucico} daemon,
+the copy will fail.  The files must be readable by the @code{uucico}
+daemon, as well as the by the invoker of @code{uux}.
+
+@item -C
+@itemx --copy
+Copy local files to the spool directory.
+
+@item -l
+@itemx --link
+Link local files into the spool directory.  If a file can not be linked
+because it is on a different device, it will be copied unless one of the
+@samp{-c} or @samp{--nocopy} options also appears (in other words, use
+of @samp{--link} switches the default from @samp{--nocopy} to
+@samp{--copy}).  If the files are changed before being processed by the
+@code{uucico} daemon, the changed versions will be used.  The files must
+be readable by the @code{uucico} daemon, as well as by the invoker of
+@code{uux}.
+
+@item -g grade
+@itemx --grade grade
+Set the grade of the file transfer command.  Jobs of a higher grade are
+executed first.  Grades run @kbd{0} to @kbd{9}, @kbd{A} to @kbd{Z},
+@kbd{a} to @kbd{z}, from high to low.  @xref{When to Call}.
+
+@item -n
+@itemx --notification=no
+Do not send mail about the status of the job, even if it fails.
+
+@item -z
+@itemx --notification=error
+Send mail about the status of the job if an error occurs.  For many
+@code{uuxqt} daemons, including the Taylor UUCP @code{uuxqt}, this is
+the default action; for those, @samp{--notification=error} will have no
+effect.  However, some @code{uuxqt} daemons will send mail if the job
+succeeds, unless the @samp{--notification=error} option is used.  Some
+other @code{uuxqt} daemons will not send mail even if the job fails,
+unless the @samp{--notification=error} option is used.
+
+@item -a address
+@itemx --requestor address
+Report job status, as controlled by the @samp{--notification} option, to
+the specified mail address.
+
+@item -r
+@itemx --nouucico
+Do not start the @code{uucico} daemon immediately; merely queue up the
+execution request for later processing.
+
+@item -j
+@itemx --jobid
+Print the jobid on standard output.  A jobid will be generated for each
+file copy operation required to execute the command.  These file copies
+may be later cancelled by passing the jobid to the @samp{-kill} switch
+of @code{uustat}.  @xref{Invoking uustat}.  Cancelling any file copies
+will make it impossible to complete execution of the job.
+
+@item -x type
+@itemx --debug type
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node uux Examples,  , uux Options, Invoking uux
+@subsection uux Examples
+
+Here are some examples of using @code{uux}.
+
+@example
+uux -z - sys1!rmail user1
+@end example
+This will execute the command @samp{rmail user1} on the system
+@samp{sys1}, giving it as standard input whatever is given to @code{uux}
+as standard input.  If a failure occurs, mail will be sent to the user
+who ran the command.
+
+@example
+uux 'diff -c sys1!~user1/file1 sys2!~user2/file2 >!file.diff'
+@end example
+This will fetch the two named files from system @samp{sys1} and system
+@samp{sys2} and execute @samp{diff}, putting the result in
+@file{file.diff} in the current directory on the local system.  The
+current directory must be writable by the @code{uuxqt} daemon for this
+to work.
+
+@example
+uux 'sys1!uucp ~user1/file1 (sys2!~user2/file2)'
+@end example
+Execute @code{uucp} on the system @samp{sys1} copying @file{file1} (on
+system @samp{sys1}) to @samp{sys2}.  This illustrates the use of
+parentheses for quoting.
+
+@node Invoking uustat, Invoking uuname, Invoking uux, Invoking the UUCP Programs
+@section Invoking uustat
+
+@menu
+* uustat Description::          Description of uustat
+* uustat Options::              Options Supported by uustat
+* uustat Examples::             Examples of uustat Usage
+@end menu
+
+@node uustat Description, uustat Options, Invoking uustat, Invoking uustat
+@subsection uustat Description
+
+@example
+uustat -a
+uustat --all
+uustat [-eKRiMNQ] [-sS system] [-uU user] [-cC command] [-oy hours]
+       [-B lines] [--executions] [--kill-all] [--rejuvenate-all]
+       [--prompt] [--mail] [--notify] [--no-list] [--system system]
+       [--not-system system] [--user user] [--not-user user]
+       [--command command] [--not-command command] [--older-than hours]
+       [--younger-than hours] [--mail-lines lines]
+uustat [-kr jobid] [--kill jobid] [--rejuvenate jobid]
+uustat -q [-sS system] [-oy hours] [--system system]
+       [--not-system system ] [--older-than hours] [--younger-than hours]
+uustat --list [-sS system] [-oy hours] [--system system ]
+       [--not-system system] [--older-than hours] [--younger-than hours]
+uustat -m
+uustat --status
+uustat -p
+uustat --ps
+@end example
+
+The @code{uustat} command can display various types of status
+information about the UUCP system.  It can also be used to cancel or
+rejuvenate requests made by @code{uucp} or @code{uux}.
+
+With no options, @code{uustat} displays all jobs queued up for the
+invoking user, as if given the @samp{--user} option with the appropriate
+argument.
+
+If any of the @samp{-a}, @samp{--all}, @samp{-e}, @samp{--executions},
+@samp{-s}, @samp{--system}, @samp{-S}, @samp{--not-system}, @samp{-u},
+@samp{--user}, @samp{-U}, @samp{--not-user}, @samp{-c},
+@samp{--command}, @samp{-C}, @samp{--not-command}, @samp{-o},
+@samp{--older-than}, @samp{-y}, or @samp{--younger-than} options are
+given, then all jobs which match the combined specifications are
+displayed.
+
+The @samp{-K} or @samp{--kill-all} option may be used to kill off a
+selected group of jobs, such as all jobs more than 7 days old.
+
+@node uustat Options, uustat Examples, uustat Description, Invoking uustat
+@subsection uustat Options
+
+The following options may be given to @code{uustat}.
+
+@table @samp
+@item -a
+@itemx --all
+List all queued file transfer requests.
+
+@item -e
+@itemx --executions
+List queued execution requests rather than queued file transfer
+requests.  Queued execution requests are processed by @code{uuxqt}
+rather than @code{uucico}.  Queued execution requests may be waiting for
+some file to be transferred from a remote system.  They are created by
+an invocation of @code{uux}.
+
+@item -s system
+@itemx --system system
+List all jobs queued up for the named system.  These options may be
+specified multiple times, in which case all jobs for all the named
+systems will be listed.  If used with @samp{--list}, only the systems
+named will be listed.
+
+@item -S system
+@itemx --not-system system
+List all jobs queued for systems other than the one named.  These
+options may be specified multiple times, in which case no jobs from any
+of the specified systems will be listed.  If used with @samp{--list},
+only the systems not named will be listed.  These options may not be
+used with @samp{-s} or @samp{--system}.
+
+@item -u user
+@itemx --user user
+List all jobs queued up for the named user.  These options may be
+specified multiple times, in which case all jobs for all the named users
+will be listed.
+
+@item -U user
+@itemx --not-user user
+List all jobs queued up for users other than the one named.  These
+options may be specified multiple times, in which case no jobs from any
+of the specified users will be listed.  These options may not be used
+with @samp{-u} or @samp{--user}.
+
+@item -c command
+@itemx --command command
+List all jobs requesting the execution of the named command.  If
+@samp{command} is @samp{ALL} this will list all jobs requesting the
+execution of some command (as opposed to simply requesting a file
+transfer).  These options may be specified multiple times, in which case
+all jobs requesting any of the commands will be listed.
+
+@item -C command
+@itemx --not-command command
+List all jobs requesting execution of some command other than the named
+command, or, if @samp{command} is @samp{ALL}, list all jobs that simply
+request a file transfer (as opposed to requesting the execution of some
+command).  These options may be specified multiple times, in which case
+no job requesting one of the specified commands will be listed.  These
+options may not be used with @samp{-c} or @samp{--command}.
+
+@item -o hours
+@itemx --older-than hours
+List all queued jobs older than the given number of hours.  If used with
+@samp{--list}, only systems whose oldest job is older than the given
+number of hours will be listed.
+
+@item -y hours
+@itemx --younger-than hours
+List all queued jobs younger than the given number of hours.  If used
+with @samp{--list}, only systems whose oldest job is younger than the
+given number of hours will be listed.
+
+@item -k jobid
+@itemx --kill jobid
+Kill the named job.  The job id is shown by the default output format,
+as well as by the @samp{-j} or @samp{--jobid} options to @code{uucp} or
+@code{uux}.  A job may only be killed by the user who created the job,
+or by the UUCP administrator, or the superuser.  The @samp{-k} or
+@samp{--kill} options may be used multiple times on the command line to
+kill several jobs.
+
+@item -r jobid
+@itemx --rejuvenate jobid
+Rejuvenate the named job.  This will mark it as having been invoked at
+the current time, affecting the output of the @samp{-o},
+@samp{--older-than}, @samp{-y}, or @samp{--younger-than} options,
+possibly preserving it from any automated cleanup daemon.  The job id is
+shown by the default output format, as well as by the @samp{-j} or
+@samp{--jobid} options to @code{uucp} or @code{uux}.  A job may only be
+rejuvenated by the user who created the job, or by the UUCP
+administrator, or the superuser.  The @samp{-r} or @samp{--rejuvenate}
+options may be used multiple times on the command line to rejuvenate
+several jobs.
+
+@item -q
+@itemx --list
+Display the status of commands, executions and conversations for all
+remote systems for which commands or executions are queued.  The
+@samp{-s}, @samp{--system}, @samp{-S}, @samp{--not-system}, @samp{-o},
+@samp{--older-than}, @samp{-y}, and @samp{--younger-than} options may be
+used to restrict the systems which are listed.  Systems for which no
+commands or executions are queued will never be listed.
+
+@item -m
+@itemx --status
+Display the status of conversations for all remote systems.
+
+@item -p
+@itemx --ps
+Display the status of all processes holding UUCP locks on systems or
+ports.
+
+@need 500
+@item -i
+@itemx --prompt
+For each listed job, prompt whether to kill the job or not.  If the
+first character of the input line is @kbd{y} or @kbd{Y}, the job will be
+killed.
+
+@item -K
+@itemx --kill-all
+Automatically kill each listed job.  This can be useful for automatic
+cleanup scripts, in conjunction with the @samp{--mail} and
+@samp{--notify} options.
+
+@item -R
+@itemx --rejuvenate-all
+Automatically rejuvenate each listed job.  This may not be used with
+@samp{--kill-all}.
+
+@item -M
+@itemx --mail
+For each listed job, send mail to the UUCP administrator.  If the job is
+killed (due to @samp{--kill-all}, or @samp{--prompt} with an affirmative
+response) the mail will indicate that.  A comment specified by the
+@samp{--comment} option may be included.  If the job is an execution,
+the initial portion of its standard input will be included in the mail
+message; the number of lines to include may be set with the
+@samp{--mail-lines} option (the default is 100).  If the standard input
+contains null characters, it is assumed to be a binary file and is not
+included.
+
+@item -N
+@itemx --notify
+For each listed job, send mail to the user who requested the job.  The
+mail is identical to that sent by the @samp{-M} or @samp{--mail}
+options.
+
+@item -W comment
+@itemx --comment comment
+Specify a comment to be included in mail sent with the @samp{-M},
+@samp{--mail}, @samp{-N}, or @samp{--notify} options.
+
+@item -B lines
+@itemx --mail-lines lines
+When the @samp{-M}, @samp{--mail}, @samp{-N}, or @samp{--notify} options
+are used to send mail about an execution with standard input, this
+option controls the number of lines of standard input to include in the
+message.  The default is 100.
+
+@item -Q
+@itemx --no-list
+Do not actually list the job, but only take any actions indicated by the
+@samp{-i}, @samp{--prompt}, @samp{-K}, @samp{--kill-all}, @samp{-M},
+@samp{--mail}, @samp{-N} or @samp{--notify} options.
+
+@item -x type
+@itemx --debug type
+@itemx -I file
+@itemx --config file
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node uustat Examples,  , uustat Options, Invoking uustat
+@subsection uustat Examples
+
+@example
+uustat --all
+@end example
+Display status of all jobs.  A sample output line is as follows:
+@smallexample
+bugsA027h bugs ian 04-01 13:50 Executing rmail ian@@airs.com (sending 12 bytes)
+@end smallexample
+The format is
+@example
+jobid system user queue-date command (size)
+@end example
+The jobid may be passed to the @samp{--kill} or @samp{--rejuvenate}
+options.  The size indicates how much data is to be transferred to the
+remote system, and is absent for a file receive request.  The
+@samp{--system}, @samp{--not-system}, @samp{--user}, @samp{--not-user},
+@samp{--command}, @samp{--not-command}, @samp{--older-than}, and
+@samp{--younger-than} options may be used to control which jobs are
+listed.
+
+@example
+uustat --executions
+@end example
+Display status of queued up execution requests.  A sample output line
+is as follows:
+@smallexample
+bugs bugs!ian 05-20 12:51 rmail ian
+@end smallexample
+The format is
+@example
+system requestor queue-date command
+@end example
+The @samp{--system}, @samp{--not-system}, @samp{--user},
+@samp{--not-user}, @samp{--command}, @samp{--not-command},
+@samp{--older-than}, and @samp{--younger-than} options may be used to
+control which requests are listed.
+
+@example
+uustat --list
+@end example
+Display status for all systems with queued up commands.  A sample
+output line is as follows:
+@smallexample
+bugs            4C (1 hour)   0X (0 secs) 04-01 14:45 Dial failed
+@end smallexample
+This indicates the system, the number of queued commands, the age of the
+oldest queued command, the number of queued local executions, the age of
+the oldest queued execution, the date of the last conversation, and the
+status of that conversation.
+
+@example
+uustat --status
+@end example
+Display conversation status for all remote systems.  A sample output
+line is as follows:
+@smallexample
+bugs           04-01 15:51 Conversation complete
+@end smallexample
+This indicates the system, the date of the last conversation, and the
+status of that conversation.  If the last conversation failed,
+@code{uustat} will indicate how many attempts have been made to call the
+system.  If the retry period is currently preventing calls to that
+system, @code{uustat} also displays the time when the next call will be
+permitted.
+
+@example
+uustat --ps
+@end example
+Display the status of all processes holding UUCP locks.  The output
+format is system dependent, as @code{uustat} simply invokes @code{ps} on
+each process holding a lock.
+
+@example
+uustat -c rmail -o 168 -K -Q -M -N -W "Queued for over 1 week"
+@end example
+This will kill all @samp{rmail} commands that have been queued up
+waiting for delivery for over 1 week (168 hours).  For each such
+command, mail will be sent both to the UUCP administrator and to the
+user who requested the rmail execution.  The mail message sent will
+include the string given by the @samp{-W} option.  The @samp{-Q} option
+prevents any of the jobs from being listed on the terminal, so any
+output from the program will be error messages.
+
+@node Invoking uuname, Invoking uulog, Invoking uustat, Invoking the UUCP Programs
+@section Invoking uuname
+
+@example
+uuname [-a] [--aliases]
+uuname -l
+uuname --local
+@end example
+
+By default, the @code{uuname} program simply lists the names of all the
+remote systems mentioned in the UUCP configuration files.
+
+The @code{uuname} program may also be used to print the UUCP name of the
+local system.
+
+The @code{uuname} program is mainly for use by shell scripts.
+
+The following options may be given to @code{uuname}.
+
+@table @samp
+@item -a
+@itemx --aliases
+List all aliases for remote systems, as well as their canonical names.
+Aliases may be specified in the @file{sys} file (@pxref{Naming the
+System}).
+
+@item -l
+@itemx --local
+Print the UUCP name of the local system, rather than listing the names
+of all the remote systems.
+
+@item -x type
+@itemx --debug type
+@itemx -I file
+@itemx --config file
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node Invoking uulog, Invoking uuto, Invoking uuname, Invoking the UUCP Programs
+@section Invoking uulog
+
+@example
+uulog [-#] [-n lines] [-sf system] [-u user] [-DSF] [--lines lines]
+      [--system system] [--user user] [--debuglog] [--statslog]
+      [--follow] [--follow=system]
+@end example
+
+The @code{uulog} program may be used to display the UUCP log file.
+Different options may be used to select which parts of the file to
+display.
+
+@table @samp
+@item -#
+@itemx -n lines
+@itemx --lines lines
+Here @samp{#} is a number; e.g., @samp{-10}.  The specified number of
+lines is displayed from the end of the log file.  The default is to
+display the entire log file, unless the @samp{-f}, @samp{-F}, or
+@samp{--follow} options are used, in which case the default is to
+display 10 lines.
+
+@item -s system
+@itemx --system system
+Display only log entries pertaining to the specified system.
+
+@item -u user
+@itemx --user user
+Display only log entries pertaining to the specified user.
+
+@item -D
+@itemx --debuglog
+Display the debugging log file.
+
+@item -S
+@itemx --statslog
+Display the statistics log file.
+
+@item -F
+@itemx --follow
+Keep displaying the log file forever, printing new lines as they are
+appended to the log file.
+
+@item -f system
+@itemx --follow=system
+Keep displaying the log file forever, displaying only log entries
+pertaining to the specified system.
+
+@item -X type
+@itemx --debug type
+@itemx -I file
+@itemx --config file
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.  Note that @code{uulog} specifies the debugging
+type using @samp{-X} rather than the usual @samp{-x}.
+@end table
+
+The operation of @code{uulog} depends to some degree upon the type of
+log files generated by the UUCP programs.  This is a compile time
+option.  If the UUCP programs have been compiled to use HDB style log
+files, @code{uulog} changes in the following ways:
+
+@itemize @bullet
+@item
+The new options @samp{-x} and @samp{--uuxqtlog} may be used to list the
+@code{uuxqt} log file.
+
+@item
+It is no longer possible to omit all arguments: one of @samp{-s},
+@samp{--system}, @samp{-f}, @samp{--follow=system}, @samp{-D},
+@samp{--debuglog}, @samp{-S}, @samp{--statslog}, @samp{-x}, or
+@samp{--uuxqtlog} must be used.
+
+@item
+The option @samp{--system ANY} may be used to list log file entries
+which do not pertain to any particular system.
+@end itemize
+
+@node Invoking uuto, Invoking uupick, Invoking uulog, Invoking the UUCP Programs
+@section Invoking uuto
+
+@example
+uuto files... system!user
+@end example
+
+The @code{uuto} program may be used to conveniently send files to a
+particular user on a remote system.  It will arrange for mail to be sent
+to the remote user when the files arrive on the remote system, and he or
+she may easily retrieve the files using the @code{uupick} program
+(@pxref{Invoking uupick}).  Note that @code{uuto} does not provide any
+security---any user on the remote system can examine the files.
+
+The last argument specifies the system and user name to which to send
+the files.  The other arguments are the files or directories to be sent.
+
+The @code{uuto} program is actually just a trivial shell script which
+invokes the @code{uucp} program with the appropriate arguments.  Any
+option which may be given to @code{uucp} may also be given to
+@code{uuto}.  @xref{Invoking uucp}.
+
+@need 2000
+@node Invoking uupick, Invoking cu, Invoking uuto, Invoking the UUCP Programs
+@section Invoking uupick
+
+@example
+uupick [-s system] [--system system]
+@end example
+
+The @code{uupick} program is used to conveniently retrieve files
+transferred by the @code{uuto} program.
+
+For each file transferred by @code{uuto}, @code{uupick} will display the
+source system, the file name, and whether the name refers to a regular
+file or a directory.  It will then wait for the user to specify an
+action to take.  One of the following commands must be entered:
+
+@table @samp
+@item q
+Quit out of @code{uupick}.
+
+@item RETURN
+Skip the file.
+
+@item m [directory]
+Move the file or directory to the specified directory.  If no directory
+is specified, the file is moved to the current directory.
+
+@item a [directory]
+Move all files from this system to the specified directory.  If no
+directory is specified, the files are moved to the current directory.
+
+@item p
+List the file on standard output.
+
+@item d
+Delete the file.
+
+@item ! [command]
+Execute @samp{command} as a shell escape.
+@end table
+
+The @samp{-s} or @samp{--system} option may be used to restrict
+@code{uupick} to only present files transferred from a particular
+system.  The @code{uupick} program also supports the standard UUCP
+program options; see @ref{Standard Options}.
+
+@need 2000
+@node Invoking cu, Invoking uucico, Invoking uupick, Invoking the UUCP Programs
+@section Invoking cu
+
+@menu
+* cu Description::              Description of cu
+* cu Commands::                 Commands Supported by cu
+* cu Variables::                Variables Supported by cu
+* cu Options::                  Options Supported by cu
+@end menu
+
+@node cu Description, cu Commands, Invoking cu, Invoking cu
+@subsection cu Description
+
+@example
+cu [options] [system | phone | "dir"]
+@end example
+
+The @code{cu} program is used to call up another system and act as a
+dial in terminal.  It can also do simple file transfers with no error
+checking.
+
+The @code{cu} program takes a single non-option argument.
+
+If the argument is the string @samp{dir} cu will make a direct
+connection to the port.  This may only be used by users with write
+access to the port, as it permits reprogramming the modem.
+
+Otherwise, if the argument begins with a digit, it is taken to be a
+phone number to call.
+
+Otherwise, it is taken to be the name of a system to call.
+
+The @samp{-z} or @samp{--system} options may be used to name a system
+beginning with a digit, and the @samp{-c} or @samp{--phone} options may
+be used to name a phone number that does not begin with a digit.
+
+The @code{cu} program locates a port to use in the UUCP configuration
+files.  If a simple system name is given, it will select a port
+appropriate for that system.  The @samp{-p}, @samp{--port}, @samp{-l},
+@samp{--line}, @samp{-s}, and @samp{--speed} options may be used to
+control the port selection.
+
+When a connection is made to the remote system, @code{cu} forks into two
+processes.  One reads from the port and writes to the terminal, while
+the other reads from the terminal and writes to the port.
+
+@node cu Commands, cu Variables, cu Description, Invoking cu
+@subsection cu Commands
+
+The @code{cu} program provides several commands that may be used during
+the conversation.  The commands all begin with an escape character,
+which by default is @kbd{~} (tilde).  The escape character is only
+recognized at the beginning of a line.  To send an escape character to
+the remote system at the start of a line, it must be entered twice.  All
+commands are either a single character or a word beginning with @kbd{%}
+(percent sign).
+
+The @code{cu} program recognizes the following commands.
+
+@table @samp
+@item ~.
+Terminate the conversation.
+
+@item ~! command
+Run command in a shell.  If command is empty, starts up a shell.
+
+@item ~$ command
+Run command, sending the standard output to the remote system.
+
+@item ~| command
+Run command, taking the standard input from the remote system.
+
+@item ~+ command
+Run command, taking the standard input from the remote system and
+sending the standard output to the remote system.
+
+@item ~#, ~%break
+Send a break signal, if possible.
+
+@item ~c directory, ~%cd directory
+Change the local directory.
+
+@item ~> file
+Send a file to the remote system.  This just dumps the file over the
+communication line.  It is assumed that the remote system is expecting
+it.
+
+@item ~<
+Receive a file from the remote system.  This prompts for the local file
+name and for the remote command to execute to begin the file transfer.
+It continues accepting data until the contents of the @samp{eofread}
+variable are seen.
+
+@item ~p from to
+@itemx ~%put from to
+Send a file to a remote Unix system.  This runs the appropriate
+commands on the remote system.
+
+@item ~t from to
+@itemx ~%take from to
+Retrieve a file from a remote Unix system.  This runs the appropriate
+commands on the remote system.
+
+@item ~s variable value
+Set a @code{cu} variable to the given value.  If value is not given, the
+variable is set to @samp{true}.
+
+@item ~! variable
+Set a @code{cu} variable to @samp{false}.
+
+@item ~z
+Suspend the cu session.  This is only supported on some systems.  On
+systems for which @kbd{^Z} may be used to suspend a job, @samp{~^Z} will
+also suspend the session.
+
+@item ~%nostop
+Turn off XON/XOFF handling.
+
+@item ~%stop
+Turn on XON/XOFF handling.
+
+@item ~v
+List all the variables and their values.
+
+@item ~?
+List all commands.
+@end table
+
+@node cu Variables, cu Options, cu Commands, Invoking cu
+@subsection cu Variables
+
+The @code{cu} program also supports several variables.  They may be
+listed with the @samp{~v} command, and set with the @samp{~s} or
+@samp{~!}  commands.
+
+@table @samp
+@item escape
+The escape character.  The default is @kbd{~} (tilde).
+
+@item delay
+If this variable is true, @code{cu} will delay for a second, after
+recognizing the escape character, before printing the name of the local
+system.  The default is true.
+
+@item eol
+The list of characters which are considered to finish a line.  The
+escape character is only recognized after one of these is seen.  The
+default is @kbd{carriage return}, @kbd{^U}, @kbd{^C}, @kbd{^O},
+@kbd{^D}, @kbd{^S}, @kbd{^Q}, @kbd{^R}.
+
+@item binary
+Whether to transfer binary data when sending a file.  If this is false,
+then newlines in the file being sent are converted to carriage returns.
+The default is false.
+
+@item binary-prefix
+A string used before sending a binary character in a file transfer, if
+the @samp{binary} variable is true.  The default is @samp{^V}.
+
+@item echo-check
+Whether to check file transfers by examining what the remote system
+echoes back.  This probably doesn't work very well.  The default is
+false.
+
+@item echonl
+The character to look for after sending each line in a file.  The
+default is carriage return.
+
+@item timeout
+The timeout to use, in seconds, when looking for a character, either
+when doing echo checking or when looking for the @samp{echonl}
+character.  The default is 30.
+
+@item kill
+The character to use delete a line if the echo check fails.  The default
+is @kbd{^U}.
+
+@item resend
+The number of times to resend a line if the echo check continues to
+fail.  The default is 10.
+
+@item eofwrite
+The string to write after sending a file with the @samp{~>} command.
+The default is @samp{^D}.
+
+@item eofread
+The string to look for when receiving a file with the @samp{ ~<}
+command.  The default is @samp{$}, which is intended to be a typical
+shell prompt.
+
+@item verbose
+Whether to print accumulated information during a file transfer.  The
+default is true.
+@end table
+
+@node cu Options,  , cu Variables, Invoking cu
+@subsection cu Options
+
+The following options may be given to @code{cu}.
+
+@table @samp
+@item -e
+@itemx --parity=even
+Use even parity.
+
+@item -o
+@itemx --parity=odd
+Use odd parity.
+
+@item --parity=none
+Use no parity.  No parity is also used if both @samp{-e} and @samp{-o}
+are given.
+
+@item -h
+@itemx --halfduplex
+Echo characters locally (half-duplex mode).
+
+@item --nostop
+Turn off XON/XOFF handling (it is on by default).
+
+@item -E char
+@itemx --escape char
+Set the escape character.  Initially @kbd{~} (tilde).  To eliminate the
+escape character, use @samp{-E ''}.
+
+@item -z system
+@itemx --system system
+The system to call.
+
+@item -c phone-number
+@itemx --phone phone-number
+The phone number to call.
+
+@item -p port
+@itemx -a port
+@itemx --port port
+Name the port to use.
+
+@item -l line
+@itemx --line line
+Name the line to use by giving a device name.  This may be used to dial
+out on ports that are not listed in the UUCP configuration files.  Write
+access to the device is required.
+
+@item -s speed
+@itemx -#
+@itemx --speed speed
+The speed (baud rate) to use.  Here, @samp{-#} means an actual number;
+e.g., @samp{-9600}.
+
+@item -n
+@itemx --prompt
+Prompt for the phone number to use.
+
+@item -d
+Enter debugging mode.  Equivalent to @samp{--debug all}.
+
+@item -x type
+@itemx --debug type
+@itemx -I file
+@itemx --config file
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node Invoking uucico, Invoking uuxqt, Invoking cu, Invoking the UUCP Programs
+@section Invoking uucico
+
+@menu
+* uucico Description::          Description of uucico
+* uucico Options::              Options Supported by uucico
+@end menu
+
+@node uucico Description, uucico Options, Invoking uucico, Invoking uucico
+@subsection uucico Description
+
+@example
+uucico [options]
+@end example
+
+The @code{uucico} daemon processes file transfer requests queued by
+@code{uucp} and @code{uux}.  It is started when @code{uucp} or
+@code{uux} is run (unless they are given the @samp{-r} or
+@samp{--nouucico} options).  It is also typically started periodically
+using entries in the @file{crontab} table(s).
+
+When @code{uucico} is invoked with @samp{-r1}, @samp{--master},
+@samp{-s}, @samp{--system}, or @samp{-S}, the daemon will place a call
+to a remote system, running in master mode.  Otherwise the daemon will
+start in slave mode, accepting a call from a remote system.  Typically a
+special login name will be set up for UUCP which automatically invokes
+@code{uucico} when a remote system calls in and logs in under that name.
+
+When @code{uucico} terminates, it invokes the @code{uuxqt} daemon,
+unless the @samp{-q} or @samp{--nouuxqt} options were given;
+@code{uuxqt} executes any work orders created by @code{uux} on a remote
+system, and any work orders created locally which have received remote
+files for which they were waiting.
+
+If a call fails, @code{uucico} will normally refuse to retry the call
+until a certain (configurable) amount of time has passed.  This may be
+overriden by the @samp{-f}, @samp{--force}, or @samp{-S} options.
+
+The @samp{-l}, @samp{--prompt}, @samp{-e}, or @samp{--loop} options may
+be used to force @code{uucico} to produce its own prompts of
+@samp{login: } and @samp{Password:}.  When another @code{uucico} daemon
+calls in, it will see these prompts and log in as usual.  The login name
+and password will normally be checked against a separate list kept
+specially for @code{uucico}, rather than the @file{/etc/passwd} file
+(@pxref{Configuration File Names}).  It is possible, on some systems, to
+configure @code{uucico} to use @file{/etc/passwd}.  The @samp{-l} or
+@samp{--prompt} options will prompt once and then exit; in this mode the
+UUCP administrator, or the superuser, may use the @samp{-u} or
+@samp{--login} option to force a login name, in which case @code{uucico}
+will not prompt for one.  The @samp{-e} or @samp{--loop} options will
+prompt again after the first session is over; in this mode @code{uucico}
+will permanently control a port.
+
+If @code{uucico} receives a @code{SIGQUIT}, @code{SIGTERM} or
+@code{SIGPIPE} signal, it will cleanly abort any current conversation
+with a remote system and exit.  If it receives a @code{SIGHUP} signal it
+will abort any current conversation, but will continue to place calls to
+(if invoked with @samp{-r1} or @samp{--master}) and accept calls from
+(if invoked with @samp{-e} or @samp{--loop}) other systems.  If it
+receives a @code{SIGINT} signal it will finish the current conversation,
+but will not place or accept any more calls.
+
+@node uucico Options,  , uucico Description, Invoking uucico
+@subsection uucico Options
+
+The following options may be given to @code{uucico}.
+
+@table @samp
+@item -r1
+@itemx --master
+Start in master mode: call out to a remote system.  Implied by
+@samp{-s}, @samp{--system}, or @samp{-S}.  If no system is specified,
+sequentially call every system for which work is waiting to be done.
+
+@item -r0
+@itemx --slave
+Start in slave mode.  This is the default.
+
+@item -s system
+@itemx --system system
+Call the specified system.
+
+@item -S system
+Call the specified system, ignoring any required wait.  This is
+equivalent to @samp{-s system -f}.
+
+@item -f
+@itemx --force
+Ignore any required wait for any systems to be called.
+
+@item -l
+@itemx --prompt
+Prompt for login name and password using @samp{login: } and
+@samp{Password:}.  This allows @code{uucico} to be easily run from
+@code{inetd}.  The login name and password are checked against the UUCP
+password file, which need not be @file{/etc/passwd}.  The @samp{--login}
+option may be used to force a login name, in which cause @code{uucico}
+will only prompt for a password.
+
+@item -p port
+@itemx --port port
+Specify a port to call out on or to listen to.
+
+@item -e
+@itemx --loop
+Enter an endless loop of login/password prompts and slave mode daemon
+execution.  The program will not stop by itself; you must use
+@code{kill} to shut it down.
+
+@item -w
+@itemx --wait
+After calling out (to a particular system when @samp{-s},
+@samp{--system}, or @samp{-S} is specifed, or to all systems which have
+work when just @samp{-r1} or @samp{--master} is specifed), begin an
+endless loop as with @samp{--loop}.
+
+@item -q
+@itemx --nouuxqt
+Do not start the @code{uuxqt} daemon when finished.
+
+@item -c
+@itemx --quiet
+If no calls are permitted at this time, then don't make the call, but
+also do not put an error message in the log file and do not update the
+system status (as reported by @code{uustat}).  This can be convenient
+for automated polling scripts, which may want to simply attempt to call
+every system rather than worry about which particular systems may be
+called at the moment.  This option also suppresses the log message
+indicating that there is no work to be done.
+
+@item -C
+@itemx --ifwork
+Only call the system named by @samp{-s}, @samp{--system}, or @samp{-S}
+if there is work for that system.
+
+@item -D
+@itemx --nodetach
+Do not detach from the controlling terminal.  Normally @code{uucico}
+detaches from the terminal before each call out to another system and
+before invoking @code{uuxqt}.  This option prevents this.
+
+@item -u name
+@itemx --login name
+Set the login name to use instead of that of the invoking user.  This
+option may only be used by the UUCP administrator or the superuser.  If
+used with @samp{--prompt}, this will cause @code{uucico} to prompt only
+for the password, not the login name.
+
+@item -z
+@itemx --try-next
+If a call fails after the remote system is reached, try the next
+alternate rather than simply exiting.
+
+@item -i type
+@itemx --stdin type
+Set the type of port to use when using standard input.  The only
+supported port type is TLI, and this is only available on machines which
+support the TLI networking interface.  Specifying @samp{-i TLI} causes
+@code{uucico} to use TLI calls to perform I/O.
+
+@item -X type
+Same as the standard option @samp{-x type}.  Provided for historical
+compatibility.
+
+@item -x type
+@itemx --debug type
+@itemx -I file
+@itemx --config file
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node Invoking uuxqt, Invoking uuchk, Invoking uucico, Invoking the UUCP Programs
+@section Invoking uuxqt
+
+@example
+uuxqt [-c command] [-s system] [--command command] [--system system]
+@end example
+
+The @code{uuxqt} daemon executes commands requested by @code{uux} from
+either the local system or from remote systems.  It is started
+automatically by the @code{uucico} daemon (unless @code{uucico} is given
+the @samp{-q} or @samp{--nouuxqt} options).
+
+There is normally no need to run @code{uuxqt}, since it will be invoked
+by @code{uucico}.  However, @code{uuxqt} can be invoked directly to
+provide greater control over the processing of the work queue.
+
+Multiple invocations of @code{uuxqt} may be run at once, as controlled
+by the @code{max-uuxqts} configuration command; see @ref{Miscellaneous
+(config)}.
+
+The following options may be given to @code{uuxqt}.
+
+@table @samp
+@item -c command
+@itemx --command command
+Only execute requests for the specified command.  For example,
+@samp{uuxqt --command rmail}.
+
+@item -s system
+@itemx --system system
+Only execute requests originating from the specified system.
+
+@item -x type
+@itemx --debug type
+@itemx -I file
+@itemx --config 
+@itemx -v
+@itemx --version
+@itemx --help
+@xref{Standard Options}.
+@end table
+
+@node Invoking uuchk, Invoking uuconv, Invoking uuxqt, Invoking the UUCP Programs
+@section Invoking uuchk
+
+@example
+uuchk [-s system] [--system system]
+@end example
+
+The @code{uuchk} program displays information read from the UUCP
+configuration files.  It should be used to ensure that UUCP has been
+configured correctly.
+
+The @samp{-s} or @samp{--system} options may be used to display the
+configuration for just the specified system, rather than for all
+systems.  The @code{uuchk} program also supports the standard UUCP
+program options; see @ref{Standard Options}.
+
+@need 2000
+@node Invoking uuconv, Invoking uusched, Invoking uuchk, Invoking the UUCP Programs
+@section Invoking uuconv
+
+@example
+uuconv -i type -o type [-p program] [--program program]
+uuconv --input type --output type [-p program] [--program program]
+@end example
+
+The @code{uuconv} program converts UUCP configuration files from one
+format to another.  The type of configuration file to read is specified
+using the @samp{-i} or @samp{--input} options.  The type of
+configuration file to write is specified using the @samp{-o} or
+@samp{--output} options.
+
+The supported configuration file types are @samp{taylor}, @samp{v2}, and
+@samp{hdb}.  For a description of the @samp{taylor} configuration files,
+see @ref{Configuration Files}.  The other types of configuration files
+are used by traditional UUCP packages, and are not described in this
+manual.
+
+An input configuration of type @samp{v2} or @samp{hdb} is read from a
+compiled in directory (specified by @samp{oldconfigdir} in
+@file{Makefile}).  An input configuration of type @samp{taylor} is read
+from a compiled in directory by default, but may be overridden with the
+standard @samp{-I} or @samp{--config} options (@pxref{Standard
+Options}).
+
+The output configuration is written to files in the directory in which
+@code{uuconv} is run.
+
+Some information in the input files may not be representable in the
+desired output format, in which case @code{uuconv} will silently discard
+it.  The output of @code{uuconv} should be carefully checked before it
+is used.  The @code{uuchk} program may be used for this purpose; see
+@ref{Invoking uuchk}.
+
+The @samp{-p} or @samp{--program} option may be used to convert specific
+@code{cu} configuration information, rather than the default of only
+converting the @code{uucp} configuration information; see @ref{config
+File}.
+
+The @code{uuchk} program also supports the standard UUCP program
+options; see @ref{Standard Options}.
+
+@node Invoking uusched,  , Invoking uuconv, Invoking the UUCP Programs
+@section Invoking uusched
+
+The @code{uusched} program is actually just a shell script which invokes
+the @code{uucico} daemon.  It is provided for backward compatibility.
+It causes @code{uucico} to call all systems for which there is work.
+Any option which may be given to @code{uucico} may also be given to
+@code{uusched}.  @xref{Invoking uucico}.
+
+@node Installing Taylor UUCP, Using Taylor UUCP, Invoking the UUCP Programs, Top
+@chapter Installing Taylor UUCP
+
+These are the installation instructions for the Taylor UUCP package.
+
+@menu
+* Compilation::                 Compiling Taylor UUCP
+* Testing the Compilation::     Testing the Compilation
+* Installing the Binaries::     Installing the Binaries
+* Configuration::               Configuring Taylor UUCP
+* Testing the Installation::    Testing the Installation
+@end menu
+
+@node Compilation, Testing the Compilation, Installing Taylor UUCP, Installing Taylor UUCP
+@section Compiling Taylor UUCP
+
+If you have a source code distribution, you must first compile it for
+your system.  Free versions of Unix, such as Linux, NetBSD, or FreeBSD,
+often come with pre-compiled binary distributions of UUCP.  If you are
+using a binary distribution, you may skip to the configuration section
+(@pxref{Configuration}).
+
+Follow these steps to compile the source code.
+
+@enumerate
+
+@item
+Take a look at the top of @file{Makefile.in} and set the appropriate
+values for your system.  These control where the programs are installed
+and which user on the system owns them (normally they will be owned by a
+special user @code{uucp} rather than a real person; they should probably
+not be owned by @code{root}).
+
+@item
+Run the shell script @code{configure}.  This script was generated using
+the @code{autoconf} program written by David MacKenzie of the Free
+Software Foundation.  It takes a while to run.  It will generate the
+file @file{config.h} based on @file{config.h.in}, and, for each source
+code directory, will generate @file{Makefile} based on
+@file{Makefile.in}.
+
+You can pass certain arguments to @code{configure} in the environment.
+Because @code{configure} will compile little test programs to see what
+is available on your system, you must tell it how to run your compiler.
+It recognizes the following environment variables:
+
+@table @samp
+@item CC
+The C compiler.  If this is not set, then if @code{configure} can find
+@samp{gcc} it will use it, otherwise it will use @samp{cc}.
+@item CFLAGS
+Flags to pass to the C compiler when compiling the actual code.  If this
+is not set, @code{configure} will use @samp{-g}.
+@item LDFLAGS
+Flags to pass to the C compiler when only linking, not compiling.  If
+this is not set, @code{configure} will use the empty string.
+@item LIBS
+Libraries to pass to the C compiler.  If this is not set,
+@code{configure} will use the empty string.
+@item INSTALL
+The program to run to install UUCP in the binary directory.  If this is
+not set, then if @code{configure} finds the BSD @code{install} program,
+it will set this to @samp{install -c}; otherwise, it will use @samp{cp}.
+@end table
+
+Suppose, for example, you want to set the environment variable @samp{CC}
+to @samp{rcc}.  If you are using @code{sh}, @code{bash}, or @code{ksh},
+invoke @code{configure} as @samp{CC=rcc configure}.  If you are using
+@code{csh}, do @samp{setenv CC rcc; sh configure}.
+
+On some systems you will want to use @samp{LIBS=-lmalloc}.  On Xenix
+derived versions of Unix do not use @samp{LIBS=-lx} because this will
+bring in the wrong versions of certain routines; if you want to use
+@samp{-lx} you must specify @samp{LIBS=-lc -lx}.
+
+If @code{configure} fails for some reason, or if you have a very weird
+system, you may have to configure the package by hand.  To do this, copy
+the file @file{config.h.in} to @file{config.h} and edit it for your
+system.  Then for each source directory (the top directory, and the
+subdirectories @file{lib}, @file{unix}, and @file{uuconf}) copy
+@file{Makefile.in} to @file{Makefile}, find the words within @kbd{@@}
+characters, and set them correctly for your system.
+
+@item
+Igor V. Semenyuk provided this (lightly edited) note about ISC Unix 3.0.
+The @code{configure} script will default to passing @samp{-posix} to
+@code{gcc}.  However, using @samp{-posix} changes the environment to
+POSIX, and on ISC 3.0, at least, the default for @code{POSIX_NO_TRUNC}
+is 1.  This can lead to a problem when @code{uuxqt} executes
+@code{rmail}.  @code{IDA sendmail} has dbm configuration files named
+@file{mailertable.@{dir,pag@}}.  Notice these names are 15 characters
+long.  When @code{uuxqt} compiled with the @samp{-posix} executes
+@code{rmail}, which in turn executes @code{sendmail}, the later is run
+under the POSIX environment too.  This leads to @code{sendmail} bombing
+out with @samp{'error opening 'M' database: name too long'
+(mailertable.dir)}.  It's rather obscure behaviour, and it took me a day
+to find out the cause.  I don't use the @samp{-posix} switch; instead, I
+run @code{gcc} with @samp{-D_POSIX_SOURCE}, and add @samp{-lcposix} to
+@samp{LIBS}.
+
+@item
+On some versions of BSDI there is a bug in the shell which causes the
+default value for @samp{CFLAGS} to be set incorrectly.  If @samp{echo
+$@{CFLAGS--g@}} echoes @samp{g} rather than @samp{-g}, then you must set
+@samp{CFLAGS} in the environment before running configure.  There is a
+patch available from BSDI for this bug.  (Reported by David Vrona).
+
+@item
+On AIX 3.2.5, and possibly other versions, @samp{cc -E} does not work,
+reporting @samp{Option NOROCONST is not valid}.  Test this before
+running configure by doing something like @samp{touch /tmp/foo.c; cc -E
+/tmp/foo.c}.  This may give a warning about the file being empty, but it
+should not give the @samp{Option NOROCONST} warning.  The workaround is
+to remove the @samp{,noroconst} entry from the @samp{options} clause in
+the @samp{cc} stanza in @file{/etc/xlc.cfg}.  (Reported by Chris Lewis).
+
+@item
+You should verify that @code{configure} worked correctly by checking
+@file{config.h} and the instances of @file{Makefile}.
+
+@item
+Edit @file{policy.h} for your local system.  The comments explain the
+various choices.  The default values are intended to be reasonable, so
+you may not have to make any changes.
+
+You must decide what type of configuration files to use; for more
+information on the choices, see @ref{Configuration}.
+
+You must also decide what sort of spool directory you want to use.  If
+this is a new installation, I recommend @samp{SPOOLDIR_TAYLOR};
+otherwise, select the spool directory corresponding to your existing
+UUCP package.
+
+@item
+Type @samp{make} to compile everything.
+
+The @file{tstuu.c} file is not particularly portable; if you can't
+figure out how to compile it you can safely ignore it, as it is only
+used for testing.  To use STREAMS pseudo-terminals, tstuu.c must be
+compiled with @samp{-DHAVE_STREAMS_PTYS}; this is not determined by the
+configure script.
+
+If you have any other problems there is probably a bug in the
+@code{configure} script.
+
+@item
+Please report any problems you have.  That is the only way they will get
+fixed for other people.  Supply a patch if you can (@pxref{Patches}), or
+just ask for help.
+
+@end enumerate
+
+@node Testing the Compilation, Installing the Binaries, Compilation, Installing Taylor UUCP
+@section Testing the Compilation
+
+If your system supports pseudo-terminals, and you compiled the code to
+support the new style of configuration files (@code{HAVE_TAYLOR_CONFIG}
+was set to 1 in @file{policy.h}), you should be able to use the
+@code{tstuu} program to test the @code{uucico} daemon.  If your system
+supports STREAMS based pseudo-terminals, you must compile tstuu.c with
+@samp{-DHAVE_STREAMS_PTYS}.  (The STREAMS based code was contributed by
+Marc Boucher).
+
+To run @code{tstuu}, just type @samp{tstuu} with no arguments.  You must
+run it in the compilation directory, since it runs @file{./uucp},
+@file{./uux} and @file{./uucico}.  The @code{tstuu} program will run a
+lengthy series of tests (it takes over ten minutes on a slow VAX).  You
+will need a fair amount of space available in @file{/usr/tmp}.  You will
+probably want to put it in the background.  Do not use @kbd{^Z}, because
+the program traps on @code{SIGCHLD} and winds up dying.  The
+@code{tstuu} program will create a directory @file{/usr/tmp/tstuu} and
+fill it with configuration files, and create spool directories
+@file{/usr/tmp/tstuu/spool1} and @file{/usr/tmp/tstuu/spool2}.
+
+If your system does not support the @code{FIONREAD} call, the
+@samp{tstuu} program will run very slowly.  This may or may not get
+fixed in a later version.
+
+The @code{tstuu} program will finish with an execute file named
+@file{X.@var{something}} and a data file named @file{D.@var{something}}
+in the directory @file{/usr/tmp/tstuu/spool1} (or, more likely, in
+subdirectories, depending on the choice of @code{SPOOLDIR} in
+@file{policy.h}).  Two log files will be created in the directory
+@file{/usr/tmp/tstuu}.  They will be named @file{Log1} and @file{Log2},
+or, if you have selected @code{HAVE_HDB_LOGGING} in @file{policy.h},
+@file{Log1/uucico/test2} and @file{Log2/uucico/test1}.  There should be
+no errors in the log files.
+
+You can test @code{uuxqt} with @samp{./uuxqt -I /usr/tmp/tstuu/Config1}.
+This should leave a command file @file{C.@var{something}} and a data
+file @file{D.@var{something}} in @file{/usr/tmp/tstuu/spool1} or in
+subdirectories.  Again, there should be no errors in the log file.
+
+Assuming you compiled the code with debugging enabled, the @samp{-x}
+switch can be used to set debugging modes; see the @code{debug} command
+for details (@pxref{Debugging Levels}).  Use @samp{-x all} to turn on
+all debugging and generate far more output than you will ever want to
+see.  The @code{uucico} daemons will put debugging output in the files
+@file{Debug1} and @file{Debug2} in the directory @file{/usr/tmp/tstuu}.
+After that, you're pretty much on your own.
+
+On some systems you can also use @code{tstuu} to test @code{uucico}
+against the system @code{uucico}, by using the @samp{-u} switch.  For
+this to work, change the definitions of @code{ZUUCICO_CMD} and
+@code{UUCICO_EXECL} at the top of @file{tstuu.c} to something
+appropriate for your system.  The definitions in @file{tstuu.c} are what
+I used for Ultrix 4.0, on which @file{/usr/lib/uucp/uucico} is
+particularly obstinate about being run as a child; I was only able to
+run it by creating a login name with no password whose shell was
+@file{/usr/lib/uucp/uucico}.  Calling login in this way will leave fake
+entries in @file{wtmp} and @file{utmp}; if you compile @file{tstout.c}
+(in the @file{contrib} directory) as a setuid @code{root} program,
+@code{tstuu} will run it to clear those entries out.  On most systems,
+such hackery should not be necessary, although on SCO I had to su to
+@code{root} (@code{uucp} might also have worked) before I could run
+@file{/usr/lib/uucp/uucico}.
+
+You can test @code{uucp} and @code{uux} (give them the @samp{-r} switch
+to keep them from starting @code{uucico}) to make sure they create the
+right sorts of files.  Unfortunately, if you don't know what the right
+sorts of files are, I'm not going to tell you here.
+
+If you can not run @code{tstuu}, or if it fails inexplicably, don't
+worry about it too much.  On some systems @code{tstuu} will fail because
+of problems using pseudo terminals, which will not matter in normal use.
+The real test of the package is talking to another system.
+
+@node Installing the Binaries, Configuration, Testing the Compilation, Installing Taylor UUCP
+@section Installing the Binaries
+
+You can install the executable files by becoming @code{root} and typing
+@samp{make install}.  Or you can look at what @samp{make install} does
+and do it by hand.  It tries to preserve your old programs, if any, but
+it only does this the first time Taylor UUCP is installed (so that if
+you install several versions of Taylor UUCP, you can still go back to
+your original UUCP programs).  You can retrieve the original programs by
+typing @samp{make uninstall}.
+
+Note that by default the programs are compiled with debugging
+information, and they are not stripped when they are installed.  You may
+want to strip the installed programs to save disk space.  For more
+information, see your system documentation for the @code{strip} program.
+
+Of course, simply installing the executable files is not enough.  You
+must also arrange for them to be used correctly.
+
+@node Configuration, Testing the Installation, Installing the Binaries, Installing Taylor UUCP
+@section Configuring Taylor UUCP
+
+You will have to decide what types of configuration files you want to
+use.  This package supports a new sort of configuration file; see
+@ref{Configuration Files}.  It also supports V2 configuration files
+(@file{L.sys}, @file{L-devices}, etc.) and HDB configuration files
+(@file{Systems}, @file{Devices}, etc.).  No documentation is provided
+for V2 or HDB configuration files.  All types of configuration files can
+be used at once, if you are so inclined.  Currently using just V2
+configuration files is not really possible, because there is no way to
+specify a dialer (there are no built in dialers, and the program does
+not know how to read @file{acucap} or @file{modemcap}); however, V2
+configuration files can be used with a new style dial file (@pxref{dial
+File}), or with a HDB @file{Dialers} file.
+
+Use of HDB configuration files has two known bugs.  A blank line in the
+middle of an entry in the @file{Permissions} file will not be ignored as
+it should be.  Dialer programs, as found in some versions of HDB, are
+not recognized directly.  If you must use a dialer program, rather than
+an entry in @file{Devices}, you must use the @code{chat-program} command
+in a new style dial file; see @ref{dial File}.  You will have to invoke
+the dialer program via a shell script or another program, since an exit
+code of 0 is required to recognize success; the @code{dialHDB} program
+in the @file{contrib} directory may be used for this purpose.
+
+The @code{uuconv} (@pxref{Invoking uuconv}) program can be used to
+convert from V2 or HDB configuration files to the new style (it can also
+do the reverse translation, if you are so inclined).  It will not do all
+of the work, and the results should be carefully checked, but it can be
+quite useful.
+
+If you are installing a new system, you will, of course, have to write
+the configuration files; see @ref{Configuration Files} for details on
+how to do this.
+
+After writing the configuration files, use the @code{uuchk} program to
+verify that they are what you expect; see @ref{Invoking uuchk}.
+
+@node Testing the Installation,  , Configuration, Installing Taylor UUCP
+@section Testing the Installation
+
+After you have written the configuration files, and verified them with
+the @code{uuchk} program (@pxref{Invoking uuchk}), you must check that
+UUCP can correctly contact another system.
+
+Tell @code{uucico} to dial out to the system by using the @samp{-s}
+system switch (e.g., @samp{uucico -s uunet}).  The log file should tell
+you what happens.  The exact location of the log file depends upon the
+settings in @file{policy.h} when you compiled the program, and on the
+use of the @code{logfile} command in the @file{config} file.  Typical
+locations are @file{/usr/spool/uucp/Log} or a subdirectory under
+@file{/usr/spool/uucp/.Log}.
+
+If you compiled the code with debugging enabled, you can use debugging
+mode to get a great deal of information about what sort of data is
+flowing back and forth; the various possibilities are described with the
+@code{debug} command (@pxref{Debugging Levels}).  When initially setting
+up a connection @samp{-x chat} is probably the most useful (e.g.,
+@samp{uucico -s uunet -x chat}); you may also want to use @samp{-x
+handshake,incoming,outgoing}.  You can use @samp{-x} multiple times on
+one command line, or you can give it comma separated arguments as in the
+last example.  Use @samp{-x all} to turn on all possible debugging
+information.
+
+The debugging information is written to a file, normally
+@file{/usr/spool/uucp/Debug}, although the default can be changed in
+@file{policy.h}, and the @file{config} file can override the default
+with the @code{debugfile} command.  The debugging file may contain
+passwords and some file contents as they are transmitted over the line,
+so the debugging file is only readable by the @code{uucp} user.
+
+You can use the @samp{-f} switch to force @code{uucico} to call out even
+if the last call failed recently; using @samp{-S} when naming a system
+has the same effect.  Otherwise the status file (in the @file{.Status}
+subdirectory of the main spool directory, normally
+@file{/usr/spool/uucp}) (@pxref{Status Directory}) will prevent too many
+attempts from occurring in rapid succession.
+
+On older System V based systems which do not have the @code{setreuid}
+system call, problems may arise if ordinary users can start an execution
+of @code{uuxqt}, perhaps indirectly via @code{uucp} or @code{uux}.  UUCP
+jobs may wind up executing with a real user ID of the user who invoked
+@code{uuxqt}, which can cause problems if the UUCP job checks the real
+user ID for security purposes.  On such systems, it is safest to put
+@samp{run-uuxqt never} (@pxref{Miscellaneous (config)}) in the
+@file{config} file, so that @code{uucico} never starts @code{uuxqt}, and
+invoke @code{uuxqt} directly from a @file{crontab} file.
+
+Please let me know about any problems you have and how you got around
+them.  If you do report a problem, please include the version number of
+the package you are using, the operating system you are running it on,
+and a sample of the debugging file showing the problem (debugging
+information is usually what is needed, not just the log file).  General
+questions such as ``why doesn't @code{uucico} dial out'' are impossible
+to answer without much more information.
+
+@node Using Taylor UUCP, Configuration Files, Installing Taylor UUCP, Top
+@chapter Using Taylor UUCP
+
+@menu
+* Calling Other Systems::       Calling Other Systems
+* Accepting Calls::             Accepting Calls
+* Mail and News::               Using UUCP for Mail and News
+* The Spool Directory Layout::  The Spool Directory Layout
+* Spool Directory Cleaning::    Cleaning the UUCP Spool Directory
+@end menu
+
+@node Calling Other Systems, Accepting Calls, Using Taylor UUCP, Using Taylor UUCP
+@section Calling Other Systems
+@cindex calling out
+
+By default @code{uucp} and @code{uux} will automatically start up
+@code{uucico} to call another system whenever work is queued up.
+However, the call may fail, or you may have put in time restrictions
+which prevent the call at that time (perhaps because telephone rates are
+high) (@pxref{When to Call}).  Also, a remote system may have work
+queued up for your system, but may not be calling you for some reason
+(perhaps you have agreed that your system should always place the call).
+To make sure that work gets transferred between the systems withing a
+reasonable time period, you should arrange to periodically invoke
+@code{uucico}.
+
+These periodic invocations are normally triggered by entries in the
+@file{crontab} file.  The exact format of @file{crontab} files, and how
+new entries are added, varies from system to system; check your local
+documentation (try @samp{man cron}).
+
+To attempt to call all systems with outstanding work, use the command
+@samp{uucico -r1}.  To attempt to call a particular system, use the
+command @samp{uucico -s @var{system}}.  To attempt to call a particular
+system, but only if there is work for it, use the command @samp{uucico
+-C -s @var{system}}.  (@pxref{Invoking uucico}).
+
+A common case is to want to try to call a system at a certain time, with
+periodic retries if the call fails.  A simple way to do this is to
+create an empty UUCP command file, known as a @dfn{poll file}.  If a
+poll file exists for a system, then @samp{uucico -r1} will place a call
+to it.  If the call succeeds, the poll file will be deleted.
+
+A poll file can be easily created using the @samp{uux} command, by
+requesting the execution of an empty command.  To create a poll file for
+@var{system}, just do something like this:
+@example
+uux -r @var{system}!
+@end example
+The @samp{-r} tells @samp{uux} to not start up @samp{uucico}
+immediately.  Of course, if you do want @samp{uucico} to start up right
+away, omit the @samp{-r}; if the call fails, the poll file will be left
+around to cause a later call.
+
+For example, I use the following crontab entries locally:
+
+@example
+45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa
+40 4,10,15 * * * /usr/bin/uux -r uunet!
+@end example
+
+Every hour, at 45 minutes past, this will check if there is any work to
+be done, and, if there is, will call the appropriate system.  Also, at
+4:40am, 10:40am, and 3:40pm, this will create a poll file file for
+@samp{uunet}, forcing the next run of @code{uucico} to call
+@samp{uunet}.
+
+@node Accepting Calls, Mail and News, Calling Other Systems, Using Taylor UUCP
+@section Accepting Calls
+@cindex calling in
+@cindex accepting calls
+
+To accept calls from another system, you must arrange matters such that
+when that system calls in, it automatically invokes @code{uucico} on
+your system.
+
+The most common arrangement is to create a special user name and
+password for incoming UUCP calls.  This user name typically uses the
+same user ID as the regular @code{uucp} user (Unix permits several user
+names to share the same user ID).  The shell for this user name should
+be set to @code{uucico}.
+
+Here is a sample @file{/etc/passwd} line to accept calls from a remote
+system named airs:
+@example
+Uairs:@var{password}:4:8:airs UUCP:/usr/spool/uucp:/usr/lib/uucp/uucico
+@end example
+The details may vary on your system.  You must use reasonable user and
+group ID's.  You must use the correct file name for @code{uucico}.  The
+@var{password} must appear in the UUCP configuration files on the remote
+system, but will otherwise never be seen or typed by a human.
+
+Note that @code{uucico} appears as the login shell, and that it will be
+run with no arguments.  This means that it will start in slave mode and
+accept an incoming connection.  @xref{Invoking uucico}.
+
+On some systems, creating an empty file named @file{.hushlogin} in the
+home directory will skip the printing of various bits of information
+when the remote @code{uucico} logs in, speeding up the UUCP connection
+process.
+
+For the greatest security, each system which calls in should use a
+different user name, each with a different password, and the
+@code{called-login} command should be used in the @file{sys} file to
+ensure that the correct login name is used.  @xref{Accepting a Call},
+and see @ref{Security}.
+
+If you never need to dial out from your system, but only accept incoming
+calls, you can arrange for @code{uucico} to handle logins itself,
+completely controlling the port, by using the @samp{--endless} option.
+@xref{Invoking uucico}.
+
+@node Mail and News, The Spool Directory Layout, Accepting Calls, Using Taylor UUCP
+@section Using UUCP for Mail and News.
+@cindex mail
+@cindex news
+
+Taylor UUCP does not include a mail package.  All Unix systems come with
+some sort of mail delivery agent, typically @code{sendmail} or
+@code{MMDF}.  Source code is available for some alternative mail
+delivery agents, such as @code{IDA sendmail} and @code{smail}.
+
+Taylor UUCP also does not include a news package.  The two major Unix
+news packages are @code{C-news} and @code{INN}.  Both are available in
+source code form.
+
+Configuring and using mail delivery agents is a notoriously complex
+topic, and I will not be discussing it here.  Configuring news systems
+is usually simpler, but I will not be discussing that either.  I will
+merely describe the interactions between the mail and news systems and
+UUCP.
+
+A mail or news system interacts with UUCP in two ways: sending and
+receiving.
+
+@menu
+* Sending mail or news::        Sending mail or news via UUCP
+* Receiving mail or news::      Receiving mail or news via UUCP
+@end menu
+
+@node Sending mail or news, Receiving mail or news, Mail and News, Mail and News
+@subsection Sending mail or news via UUCP
+
+When mail is to be sent from your machine to another machine via UUCP,
+the mail delivery agent will invoke @code{uux}.  It will generally run a
+command such as @samp{uux - @var{system}!rmail @var{address}}, where
+@var{system} is the remote system to which the mail is being sent.  It
+may pass other options to @code{uux}, such as @samp{-r} or @samp{-g}
+(@pxref{Invoking uux}).
+
+The news system also invokes @code{uux} in order to transfer articles to
+another system.  The only difference is that news will use @code{uux} to
+invoke @code{rnews} on the remote system, rather than @code{rmail}.
+
+You should arrange for your mail and news systems to invoke the Taylor
+UUCP version of @code{uux}.  If you only have Taylor UUCP, or if you
+simply replace any existing version of @code{uux} with the Taylor UUCP
+version, this will probably happen automatically.  However, if you have
+two UUCP packages installed on your system, you will probably have to
+modify the mail and news configuration files in some way.
+
+Actually, if both the system UUCP and Taylor UUCP are using the same
+spool directory format, the system @code{uux} will probably work fine
+with the Taylor @code{uucico} (the reverse is not the case: the Taylor
+@code{uux} requires the Taylor @code{uucico}).  However, data transfer
+will be somewhat more efficient if the Taylor @code{uux} is used.
+
+@node Receiving mail or news,  , Sending mail or news, Mail and News
+@subsection Receiving mail or news via UUCP
+
+To receive mail, all that is necessary is for UUCP to invoke
+@code{rmail}.  Any mail delivery agent will provide an appropriate
+version of @code{rmail}; you must simply make sure that it is in the
+command path used by UUCP (it almost certainly already is).  The default
+command path is set in @file{policy.h}, and it may be overridden for a
+particular system by the @code{command-path} command
+(@pxref{Miscellaneous (sys)}).
+
+Similarly, for news UUCP must be able to invoke @code{rnews}.  Any news
+system will provide a version of @code{rnews}, and you must ensure that
+is in a directory on the path that UUCP will search.
+
+@node The Spool Directory Layout, Spool Directory Cleaning, Mail and News, Using Taylor UUCP
+@section The Spool Directory Layout
+@cindex spool directory
+
+In general, the layout of the spool directory may be safely ignored.
+However, it is documented here for the curious.  This description only
+covers the @code{SPOOLDIR_TAYLOR} layout.  The ways in which the other
+spool directory layouts differ are described in the source file
+@file{unix/spool.c}.
+
+Directories and files are only created when they are needed, so a
+typical system will not have all of the entries described here.
+
+@menu
+* System Spool Directories::    System Spool Directories
+* Status Directory::            Status Spool Directory
+* Execution Subdirectories::    Execution Spool Subdirectories
+* Other Spool Subdirectories::  Other Spool Subdirectories
+* Spool Lock Files::            Spool Directory Lock Files
+@end menu
+
+@node System Spool Directories, Status Directory, The Spool Directory Layout, The Spool Directory Layout
+@subsection System Spool Directories
+@cindex system spool directories
+
+@table @file
+@item @var{system}
+There is a subdirectory of the main spool directory for each remote
+system.
+
+@item @var{system}/C.
+This directory stores files describing file transfer commands to be sent
+to the @var{system}.  Each file name starts with @file{C.@var{g}}, where
+@var{g} is the job grade.  Each file contains one or more commands.  For
+details of the commands, see @ref{UUCP Protocol Commands}.
+
+@item @var{system}/D.
+This directory stores data files.  Files with names like
+@file{D.@var{g}@var{ssss}}, where @var{g} is the grade and @var{ssss} is
+a sequence number, are waiting to be transferred to the @var{system}, as
+directed by the files in the @file{@var{system}/C.} directory.  Files
+with other names, typically @file{D.@var{system}@var{g}@var{ssss}}, have
+been received from @var{system} and are waiting to be processed by an
+execution file in the @file{@var{system}/X.} directory.
+
+@item @var{system}/D.X
+This directory stores data files which will become execution files on
+the remote system.  In current practice, this directory rarely exists,
+because most simple executions, including typical uses of @code{rmail}
+and @code{rnews}, send an @samp{E} command rather than an execution file
+(@pxref{The E Command}).
+
+@item @var{system}/X.
+This directory stores execution files which have been received from
+@var{system}.  This directory normally exists, even though the
+corresponding @file{D.X} directory does not, because @code{uucico} will
+create an execution file on the fly when it receives an @samp{E}
+command.
+
+@item @var{system}/SEQF
+This file holds the sequence number of the last job sent to
+@var{system}.  The sequence number is used to ensure that file names are
+unique in the remote system spool directory.  The file is four bytes
+long.  Sequence numbers are composed of digits and the upper case
+letters.
+@end table
+
+@node Status Directory, Execution Subdirectories, System Spool Directories, The Spool Directory Layout
+@subsection Status Directory
+
+@table @file
+@item .Status
+@cindex .Status
+@cindex status files
+This directory holds status files for each remote system.  The name of
+the status file is the name of the system which it describes.  Each
+status file describes the last conversation with the system.  Running
+@code{uustat --status} basically just formats and prints the contents of
+the status files (@pxref{uustat Examples}).
+
+Each status file has a single text line with six fields.
+
+@table @asis
+@item code
+A code indicating the status of the last conversation.  The following
+values are defined, though not all are actually used.
+@table @samp
+@item 0
+Conversation completed normally.
+@item 1
+@code{uucico} was unable to open the port.
+@item 2
+The last call to the system failed while dailing.
+@item 3
+The last call to the system failed while logging in.
+@item 4
+The last call to the system failed during the initial UUCP protocol
+handshake (@pxref{The Initial Handshake}).
+@item 5
+The last call to the system failed after the initial handshake.
+@item 6
+@code{uucico} is currently talking to the system.
+@item 7
+The last call to the system failed because it was the wrong time to call
+(this is not used if calling the system is never permitted).
+@end table
+
+@item retries
+The number of retries since the last successful call.
+
+@item time of last call
+The time of the last call, in seconds since the epoch (as returned by
+the @code{time} system call).
+
+@item wait
+If the last call failed, this is the number of seconds since the last
+call before @code{uucico} may attempt another call.  This is set based
+on the retry time; see @ref{When to Call}.  The @samp{-f} or @samp{-S}
+options to @code{uucico} direct it to ignore this wait time; see
+@ref{Invoking uucico}.
+
+@item description
+A text description of the status, corresponding to the code in the first
+field.  This may contain spaces.
+
+@item system name
+The name of the remote system.
+@end table
+@end table
+
+@node Execution Subdirectories, Other Spool Subdirectories, Status Directory, The Spool Directory Layout
+@subsection Execution Subdirectories
+
+@table @file
+@item .Xqtdir
+@cindex .Xqtdir
+When @code{uuxqt} executes a job requested by @code{uux}, it first
+changes the working directory to the @file{.Xqtdir} subdirectory.  This
+permits the job to create any sort of temporary file without worrying
+about overwriting other files in the spool directory.  Any files left
+in the @file{.Xqtdir} subdirectory are removed after each execution is
+complete.
+
+@item .Xqtdir@var{nnnn}
+When several instances of @code{uuxqt} are executing simultaneously,
+each one executes jobs in a separate directory.  The first uses
+@file{.Xqtdir}, the second uses @file{.Xqtdir0001}, the third uses
+@file{.Xqtdir0002}, and so forth.
+
+@item .Corrupt
+@cindex .Corrupt
+If @code{uuxqt} encounters an execution file which it is unable to
+parse, it saves it in the @file{.Corrupt} directory, and sends mail
+about it to the UUCP administrator.
+
+@item .Failed
+@cindex .Failed
+If @code{uuxqt} executes a job, and the job fails, and there is enough
+disk space to hold the command file and all the data files, then
+@code{uuxqt} saves the files in the @file{.Failed} directory, and sends
+mail about it to the UUCP administrator.
+@end table
+
+@node Other Spool Subdirectories, Spool Lock Files, Execution Subdirectories, The Spool Directory Layout
+@subsection Other Spool Subdirectories
+
+@table @file
+@item .Sequence
+@cindex .Sequence
+This directory holds conversation sequence number files.  These are used
+if the @code{sequence} command is used for a system
+(@pxref{Miscellaneous (sys)}).  The sequence number for the system
+@var{system} is stored in the file @file{.Sequence/@var{system}}.  It is
+simply stored as a printable number.
+
+@item .Temp
+@cindex .Temp
+This directory holds data files as they are being received from a remote
+system, before they are moved to their final destination.  For file send
+requests which use a valid temporary file name in the @var{temp} field
+of the @samp{S} or @samp{E} command (@pxref{The S Command}),
+@code{uucico} receives the file into
+@file{.Temp/@var{system}/@var{temp}}, where @var{system} is the name of
+the remote system, and @var{temp} is the temporary file name.  If a
+conversation fails during a file transfer, these files are used to
+automatically restart the file transfer from the point of failure.
+
+If the @samp{S} or @samp{E} command does not include a temporary file
+name, automatic restart is not possible.  In this case, the files are
+received into a randomly named file in the @file{.Temp} directory
+itself.
+
+@item .Preserve
+@cindex .Preserve
+This directory holds data files which could not be transferred to a
+remote system for some reason (for example, the data file might be
+large, and exceed size restrictions imposed by the remote system).  When
+a locally requested file transfer fails, @code{uucico} will store the
+data file in the @file{.Preserve} directory, and send mail to the
+requestor describing the failure and naming the saved file.
+
+@item .Received
+@cindex .Received
+This directory records which files have been received.  If a
+conversation fails just after @code{uucico} acknowledges receipt of a
+file, it is possible for the acknowledgement to be lost.  If this
+happens, the remote system will resend the file.  If the file were an
+execution request, and @code{uucico} did not keep track of which files
+it had already received, this could lead to the execution being
+performed twice.
+
+To avoid this problem, when a conversation fails, @code{uucico} records
+each file that has been received, but for which the remote system may
+not have received the acknowledgement.  It records this information by
+creating an empty file with the name
+@file{.Received/@var{system}/@var{temp}}, where @var{system} is the name
+of the remote system, and @var{temp} is the @var{temp} field of the
+@samp{S} or @samp{E} command from the remote system (@pxref{The S
+Command}).  Then, if the remote system offers the file again in the next
+conversation, @code{uucico} refuses the send request and deletes the
+record in the @file{.Received} directory.  This approach only works for
+file sends which use a temporary file name, but this is true of all
+execution requests.
+@end table
+
+@node Spool Lock Files,  , Other Spool Subdirectories, The Spool Directory Layout
+@subsection Lock Files in the Spool Directory
+@cindex lock files in spool directory
+
+Lock files for devices and systems are stored in the lock directory,
+which may or may not be the same as the spool directory.  The lock
+directory is set at compilation time by @code{LOCKDIR} in
+@file{policy.h}, which may be overridden by the @code{lockdir} command
+in the @file{config} file (@pxref{Miscellaneous (config)}).
+
+For a description of the names used for device lock files, and the
+format of the contents of a lock file, see @ref{UUCP Lock Files}.
+
+@table @file
+@item LCK..@var{sys}
+@cindex LCK..@var{sys}
+@cindex system lock files
+A lock file for a system, where @var{sys} is the system name.  As noted
+above, these lock files are kept in the lock directory, which may not be
+the spool directory.  These lock files are created by @code{uucico}
+while talking to a remote system, and are used to prevent multiple
+simultaneous conversations with a system.  
+
+On systems which limit file names to 14 characters, only the first eight
+characters of the system name are used in the lock file name.  This
+requires that the names of each directly connected remote system be
+unique in the first eight characters.
+
+@item LCK.XQT.@var{NN}
+@cindex LCK.XQT.@var{NN}
+When @code{uuxqt} starts up, it uses lock files to determine how many
+other @code{uuxqt} daemons are currently running.  It first tries to
+lock @file{LCK.XQT.0}, then @file{LCK.XQT.1}, and so forth.  This is
+used to implement the @code{max-uuxqts} command (@pxref{Miscellaneous
+(config)}).  It is also used to parcel out the @file{.Xqtdir}
+subdirectories (@pxref{Execution Subdirectories}).
+
+@item LXQ.@var{cmd}
+@cindex LXQ.@var{cmd}
+When @code{uuxqt} is invoked with the @samp{-c} or @samp{--command}
+option (@pxref{Invoking uuxqt}), it creates a lock file named after the
+command it is executing.  For example, @samp{uuxqt -c rmail} will create
+the lock file @file{LXQ.rmail}.  This prevents other @code{uuxqt}
+daemons from executing jobs of the specified type.
+
+@item @var{system}/X./L.@var{xxx}
+@cindex L.@var{xxx}
+While @code{uuxqt} is executing a particular job, it creates a lock file
+with the same name as the @file{X.} file describing the job, but
+replacing the initial @samp{X} with @samp{L}.  This ensures that if
+multiple @code{uuxqt} daemons are running, they do not simultaneously
+execute the same job.
+
+@item LCK..SEQ
+This lock file is used to control access to the sequence files for each
+system (@pxref{System Spool Directories}).  It is only used on systems
+which do not support POSIX file locking using the @code{fcntl} system
+call.
+@end table
+
+@node Spool Directory Cleaning,  , The Spool Directory Layout, Using Taylor UUCP
+@section Cleaning the Spool Directory
+@cindex spool directory, cleaning
+@cindex cleaning the spool directory
+
+The spool directory may need to be cleaned up periodically.  Under some
+circumstances, files may accumulate in various subdirectories, such as
+@file{.Preserve} (@pxref{Other Spool Subdirectories}) or @file{.Corrupt}
+(@pxref{Execution Subdirectories}).
+
+Also, if a remote system stops calling in, you may want to arrange for
+any queued up mail to be returned to the sender.  This can be done using
+the @code{uustat} command (@pxref{Invoking uustat}).
+
+The @file{contrib} directory includes a simple @file{uuclean} script
+which may be used as an example of a clean up script.  It can be run
+daily out of @file{crontab}.
+
+You should periodically trim the UUCP log files, as they will otherwise
+grow without limit.  The names of the log files are set in
+@file{policy.h}, and may be overridden in the configuration file
+(@pxref{config File}).  By default they are are
+@file{/usr/spool/uucp/Log} and @file{/usr/spool/uucp/Stats}.  You may
+find the @code{savelog} program in the @file{contrib} directory to be of
+use.  There is a manual page for it in @file{contrib} as well.
+
+@node Configuration Files, Protocols, Using Taylor UUCP, Top
+@chapter Taylor UUCP Configuration Files
+
+This chapter describes the configuration files accepted by the Taylor
+UUCP package if compiled with @code{HAVE_TAYLOR_CONFIG} set to 1 in
+@file{policy.h}.
+
+The configuration files are normally found in the directory
+@var{newconfigdir}, which is defined by the @file{Makefile} variable
+@file{newconfigdir}; by default @var{newconfigdir} is
+@file{/usr/local/conf/uucp}.  However, the main configuration file,
+@file{config}, is the only one which must be in that directory, since it
+may specify a different location for any or all of the other files.  You
+may run any of the UUCP programs with a different main configuration
+file by using the @samp{-I} or @samp{--config} option; this can be
+useful when testing a new configuration.  When you use the @samp{-I}
+option the programs will revoke any setuid privileges.
+
+@menu
+* Configuration Overview::      Configuration File Overview
+* Configuration File Format::   Configuration File Format
+* Configuration Examples::      Examples of Configuration Files
+* Time Strings::                How to Write Time Strings
+* Chat Scripts::                How to Write Chat Scripts
+* config File::                 The Main Configuration File
+* sys File::                    The System Configuration File
+* port File::                   The Port Configuration Files
+* dial File::                   The Dialer Configuration Files
+* UUCP Over TCP::               UUCP Over TCP
+* Security::                    Security Issues
+@end menu
+
+@node Configuration Overview, Configuration File Format, Configuration Files, Configuration Files
+@section Configuration File Overview
+
+UUCP uses several different types of configuration files, each
+describing a different kind of information.  The commands permitted in
+each file are described in detail below.  This section is a brief
+description of some of the different types of files.
+
+The @file{config} file is the main configuration file.  It describes
+general information not associated with a particular remote system, such
+as the location of various log files.  There are reasonable defaults for
+everything that may be specified in the @file{config} file, so you may
+not actually need one on your system.
+
+There may be only one @file{config} file, but there may be one or more
+of each other type of file.  The default is one file for each type, but
+more may be listed in the @file{config} file.
+
+The @file{sys} files are used to describe remote systems.  Each remote
+system to which you connect must be listed in a @file{sys} file.  A
+@file{sys} file will include information for a system, such as the speed
+(baud rate) to use, or when to place calls.
+
+For each system you wish to call, you must describe one or more ports;
+these ports may be defined directly in the @file{sys} file, or they may
+be defined in a @file{port} file.
+
+The @file{port} files are used to describe ports.  A port is a
+particular hardware connection on your computer.  You would normally
+define as many ports as there are modems attached to your computer.  A
+TCP connection is also described using a port.
+
+The @file{dial} files are used to describe dialers.  Dialer is
+essentially another word for modem.  The @file{dial} file describes the
+commands UUCP should use to dial out on a particular type of modem.  You
+would normally define as many dialers as there are types of modems
+attached to your computer.  For example, if you have three Telebit
+modems used for UUCP, you would probably define three ports and one
+dialer.
+
+There are other types of configuration files, but these are the
+important ones.  The other types are described below.
+
+@node Configuration File Format, Configuration Examples, Configuration Overview, Configuration Files
+@section Configuration File Format
+
+All the configuration files follow a simple line-oriented
+@samp{@var{keyword} @var{value}} format.  Empty lines are ignored, as
+are leading spaces; unlike HDB, lines with leading spaces are read.  The
+first word on each line is a keyword.  The rest of the line is
+interpreted according to the keyword.  Most keywords are followed by
+numbers, boolean values or simple strings with no embedded spaces.
+
+The @kbd{#} character is used for comments.  Everything from a @kbd{#}
+to the end of the line is ignored unless the @kbd{#} is preceded by a
+@kbd{\} (backslash); if the @kbd{#} is preceeded by a @kbd{\}, the
+@kbd{\} is removed but the @kbd{#} remains in the line.  This can be
+useful for a phone number containing a @kbd{#}.  To enter the sequence
+@samp{\#}, use @samp{\\#}.  
+
+The backslash character may be used to continue lines.  If the last
+character in a line is a backslash, the backslash is removed and the
+line is continued by the next line.  The second line is attached to the
+first with no intervening characters; if you want any whitespace between
+the end of the first line and the start of the second line, you must
+insert it yourself.
+
+However, the backslash is not a general quoting character.  For example,
+you cannot use it to get an embedded space in a string argument.
+
+Everything after the keyword must be on the same line.  A @var{boolean}
+may be specified as @kbd{y}, @kbd{Y}, @kbd{t}, or @kbd{T} for true and
+@kbd{n}, @kbd{N}, @kbd{f}, or @kbd{F} for false; any trailing characters
+are ignored, so @code{true}, @code{false}, etc., are also acceptable.
+
+@node Configuration Examples, Time Strings, Configuration File Format, Configuration Files
+@section Examples of Configuration Files
+
+This section provides few typical examples of configuration files.
+There are also sample configuration files in the @file{sample}
+subdirectory of the distribution.
+
+@menu
+* config File Examples::        Examples of the Main Configuration File
+* Leaf Example::                Call a Single Remote Site
+* Gateway Example::             The Gateway for Several Local Systems
+@end menu
+
+@node config File Examples, Leaf Example, Configuration Examples, Configuration Examples
+@subsection config File Examples
+@cindex config file examples
+
+To start with, here are some examples of uses of the main configuration
+file, @file{config}.  For a complete description of the commands that
+are permitted in @file{config}, see @ref{config File}.
+
+In many cases you will not need to create a @file{config} file at all.
+The most common reason to create one is to give your machine a special
+UUCP name.  Other reasons might be to change the UUCP spool directory,
+or to permit any remote system to call in.
+
+If you have an internal network of machines, then it is likely that the
+internal name of your UUCP machine is not the name you want to use when
+calling other systems.  For example, here at @file{airs.com} our
+mail/news gateway machine is named @file{elmer.airs.com} (it is one of
+several machines all named @file{@var{localname}.airs.com}).  If we did
+not provide a @file{config} file, then our UUCP name would be
+@file{elmer}; however, we actually want it to be @file{airs}.
+Therefore, we use the following line in @file{config}:
+
+@example
+nodename airs
+@end example
+
+@cindex changing spool directory
+@cindex spool directory, changing
+The UUCP spool directory name is set in @file{policy.h} when the code is
+compiled.  You might at some point decide that it is appropriate to move
+the spool directory, perhaps to put it on a different disk partition.
+You would use the following commands in @file{config} to change to
+directories on the partition @file{/uucp}:
+
+@example
+spool /uucp/spool
+pubdir /uucp/uucppublic
+logfile /uucp/spool/Log
+debugfile /uucp/spool/Debug
+@end example
+
+You would then move the contents of the current spool directory to
+@file{/uucp/spool}.  If you do this, make sure that no UUCP processes
+are running while you change @file{config} and move the spool directory.
+
+@cindex anonymous UUCP
+Suppose you wanted to permit any system to call in to your system and
+request files.  This is generally known as @dfn{anonymous UUCP}, since
+the systems which call in are effectively anonymous.  By default,
+unknown systems are not permitted to call in.  To permit this you must
+use the @code{unknown} command in @file{config}.  The @code{unknown}
+command is followed by any command that may appear in the system file;
+for full details, see @ref{sys File}.
+
+I will show two possible anonymous UUCP configurations.  The first will
+let any system call in and download files, but will not permit them to
+upload files to your system.
+
+@example
+# No files may be transferred to this system
+unknown receive-request no
+# The public directory is /usr/spool/anonymous
+unknown pubdir /usr/spool/anonymous
+# Only files in the public directory may be sent (the default anyhow)
+unknown remote-send ~
+@end example
+
+@noindent
+Setting the public directory is convenient for the systems which call
+in.  It permits to request a file by prefixing it with @file{~/}.  For
+example, assuming your system is known as @samp{server}, then to
+retrieve the file @file{/usr/spool/anonymous/INDEX} a user on a remote
+site could just enter @samp{uucp server!~/INDEX ~}; this would transfer
+@file{INDEX} from @samp{server}'s public directory to the user's local
+public directory.  Note that when using @samp{csh} or @samp{bash} the
+@kbd{!} and the second @kbd{~} must be quoted.
+
+The next example will permit remote systems to upload files to a special
+directory named @file{/usr/spool/anonymous/upload}.  Permitting a remote
+system to upload files permits it to send work requests as well; this
+example is careful to prohibit commands from unknown systems.
+
+@example
+# No commands may be executed (the list of permitted commands is empty)
+unknown commands
+# The public directory is /usr/spool/anonymous
+unknown pubdir /usr/spool/anonymous
+# Only files in the public directory may be sent; users may not download
+# files from the upload directory
+unknown remote-send ~ !~/upload
+# May only upload files into /usr/spool/anonymous/upload
+unknown remote-receive ~/upload
+@end example
+
+@node Leaf Example, Gateway Example, config File Examples, Configuration Examples
+@subsection Leaf Example
+
+@cindex leaf site
+@cindex sys file example (leaf)
+A relatively common simple case is a @dfn{leaf site}, a system which
+only calls or is called by a single remote site.  Here is a typical
+@file{sys} file that might be used in such a case.  For full details on
+what commands can appear in the @file{sys} file, see @ref{sys File}.
+
+This is the @file{sys} file that is used at @file{airs.com}.  We use a
+single modem to dial out to @file{uunet}.  This example shows how you
+can specify the port and dialer information directly in the @file{sys}
+file for simple cases.  It also shows the use of the following:
+
+@table @code
+
+@item call-login
+Using @code{call-login} and @code{call-password} allows the default
+login chat script to be used.  In this case, the login name is specified
+in the call-out login file (@pxref{Configuration File Names}).
+
+@item call-timegrade
+@file{uunet} is requested to not send us news during the daytime.
+
+@item chat-fail
+If the modem returns @samp{BUSY} or @samp{NO CARRIER} the call is
+immediately aborted.
+
+@item protocol-parameter
+Since @file{uunet} tends to be slow, the default timeout has been
+increased.
+
+@end table
+
+This @file{sys} file relies on certain defaults.  It will allow
+@file{uunet} to queue up @samp{rmail} and @samp{rnews} commands.  It
+will allow users to request files from @file{uunet} into the UUCP public
+directory.  It will also allow @file{uunet} to request files from the
+UUCP public directory; in fact @file{uunet} never requests files, but
+for additional security we could add the line @samp{request false}.
+
+@example
+# The following information is for uunet
+system uunet
+
+# The login name and password are kept in the callout password file
+call-login *
+call-password *
+
+# We can send anything at any time.
+time any
+
+# During the day we only accept grade `Z' or above; at other times
+# (not mentioned here) we accept all grades.  uunet queues up news
+# at grade `d', which is lower than `Z'.
+call-timegrade Z Wk0755-2305,Su1655-2305
+
+# The phone number.
+phone 7389449
+
+# uunet tends to be slow, so we increase the timeout
+chat-timeout 120
+
+# We are using a preconfigured Telebit 2500.
+port type modem
+port device /dev/ttyd0
+port speed 19200
+port carrier true
+port dialer chat "" ATZ\r\d\c OK ATDT\D CONNECT
+port dialer chat-fail BUSY
+port dialer chat-fail NO\sCARRIER
+port dialer complete \d\d+++\d\dATH\r\c
+port dialer abort \d\d+++\d\dATH\r\c
+
+# Increase the timeout and the number of retries.
+protocol-parameter g timeout 20
+protocol-parameter g retries 10
+@end example
+
+@node Gateway Example,  , Leaf Example, Configuration Examples
+@subsection Gateway Example
+
+@cindex gateway
+@cindex sys file example (gateway)
+Many organizations have several local machines which are connected by
+UUCP, and a single machine which connects to the outside world.  This
+single machine is often referred to as a @dfn{gateway} machine.
+
+For this example I will assume a fairly simple case.  It should still
+provide a good general example.  There are three machines, @file{elmer},
+@file{comton} and @file{bugs}.  @file{elmer} is the gateway machine for
+which I will show the configuration file.  @file{elmer} calls out to
+@file{uupsi}.  As an additional complication, @file{uupsi} knows
+@file{elmer} as @file{airs}; this will show how a machine can have one
+name on an internal network but a different name to the external world.
+@file{elmer} has two modems.  It also has an TCP connection to
+@file{uupsi}, but since that is supposed to be reserved for interactive
+work (it is, perhaps, only a 9600 baud SLIP line) it will only use it if
+the modems are not available.
+
+A network this small would normally use a single @file{sys} file.
+However, for pedagogical purposes I will show two separate @file{sys}
+files, one for the local systems and one for @file{uupsi}.  This is done
+with the @code{sysfile} command in the @file{config} file.  Here is the
+@file{config} file.
+
+@example
+# This is config
+# The local sys file
+sysfile /usr/local/lib/uucp/sys.local
+# The remote sys file
+sysfile /usr/local/lib/uucp/sys.remote
+@end example
+
+Using the defaults feature of the @file{sys} file can greatly simplify
+the listing of local systems.  Here is @file{sys.local}.  Note that this
+assumes that the local systems are trusted; they are permited to request
+any world readable file and to write files into any world writable
+directory.
+
+@example
+# This is sys.local
+# Get the login name and password to use from the call-out file
+call-login *
+call-password *
+
+# The systems must use a particular login
+called-login Ulocal
+
+# Permit sending any world readable file
+local-send /
+remote-send /
+
+# Permit receiving into any world writable directory
+local-receive /
+remote-receive /
+
+# Call at any time
+time any
+
+# Use port1, then port2
+port port1
+
+alternate
+
+port port2
+
+# Now define the systems themselves.  Because of all the defaults we
+# used, there is very little to specify for the systems themselves.
+
+system comton
+phone 5551212
+
+system bugs
+phone 5552424
+@end example
+
+The @file{sys.remote} file describes the @file{uupsi} connection.  The
+@code{myname} command is used to change the UUCP name to @file{airs}
+when talking to @file{uupsi}.
+
+@example
+# This is sys.remote
+# Define uupsi
+system uupsi
+
+# The login name and password are in the call-out file
+call-login *
+call-password *
+
+# We can call out at any time
+time any
+
+# uupsi uses a special login name
+called-login Uuupsi
+
+# uuspi thinks of us as `airs'
+myname airs
+
+# The phone number
+phone 5554848
+
+# We use port2 first, then port1, then TCP
+
+port port2
+
+alternate
+
+port port1
+
+alternate
+
+# We don't bother to make a special entry in the port file for TCP, we
+# just describe the entire port right here.  We use a special chat
+# script over TCP because the usual one confuses some TCP servers.
+port type TCP
+address uu.psi.com
+chat ogin: \L word: \P
+@end example
+
+The ports are defined in the file @file{port} (@pxref{port File}).  For
+this example they are both connected to the same type of 2400 baud
+Hayes-compatible modem.
+
+@example
+# This is port
+
+port port1
+type modem
+device /dev/ttyd0
+dialer hayes
+speed 2400
+
+port port2
+type modem
+device /dev/ttyd1
+dialer hayes
+speed 2400
+@end example
+
+Dialers are described in the @file{dial} file (@pxref{dial File}).
+
+@example
+# This is dial
+
+dialer hayes
+
+# The chat script used to dial the phone.  \D is the phone number.
+chat "" ATZ\r\d\c OK ATDT\D CONNECT
+
+# If we get BUSY or NO CARRIER we abort the dial immediately
+chat-fail BUSY
+chat-fail NO\sCARRIER
+
+# When the call is over we make sure we hangup the modem.
+complete \d\d+++\d\dATH\r\c
+abort \d\d+++\d\dATH\r\c
+@end example
+
+@node Time Strings, Chat Scripts, Configuration Examples, Configuration Files
+@section Time Strings
+@cindex time strings
+
+Several commands use time strings to specify a range of times.  This
+section describes how to write time strings.
+
+A time string may be a list of simple time strings separated with a
+vertical bar @samp{|} or a comma @samp{,}.
+
+Each simple time string must begin with @samp{Su}, @samp{Mo}, @samp{Tu},
+@samp{We}, @samp{Th}, @samp{Fr}, or @samp{Sa}, or @samp{Wk} for any
+weekday, or @samp{Any} for any day.
+
+Following the day may be a range of hours separated with a hyphen using
+24 hour time.  The range of hours may cross 0; for example
+@samp{2300-0700} means any time except 7 AM to 11 PM.  If no time is
+given, calls may be made at any time on the specified day(s).  
+
+The time string may also be the single word @samp{Never}, which does not
+match any time.  The time string may also be a single word with a name
+defined in a previous @code{timetable} command (@pxref{Miscellaneous
+(config)}).
+
+Here are a few sample time strings with an explanation of what they
+mean.
+
+@table @samp
+
+@item Wk2305-0855,Sa,Su2305-1655
+
+This means weekdays before 8:55 AM or after 11:05 PM, any time Saturday,
+or Sunday before 4:55 PM or after 11:05 PM.  These are approximately the
+times during which night rates apply to phone calls in the U.S.A.  Note
+that this time string uses, for example, @samp{2305} rather than
+@samp{2300}; this will ensure a cheap rate phone call even if the
+computer clock is running up to five minutes ahead of the real time.
+
+@item Wk0905-2255,Su1705-2255
+
+This means weekdays from 9:05 AM to 10:55 PM, or Sunday from 5:05 PM to
+10:55 PM.  This is approximately the opposite of the previous example.
+
+@item Any
+
+This means any day.  Since no time is specified, it means any time on
+any day.
+
+@end table
+
+@node Chat Scripts, config File, Time Strings, Configuration Files
+@section Chat Scripts
+@cindex chat scripts
+
+Chat scripts are used in several different places, such as dialing out
+on modems or logging in to remote systems.  Chat scripts are made up of
+pairs of strings.  The program waits until it sees the first string,
+known as the @dfn{expect} string, and then sends out the second string,
+the @dfn{send} string.
+
+Each chat script is defined using a set of commands.  These commands
+always end in a string beginning with @code{chat}, but may start with
+different strings.  For example, in the @file{sys} file there is one set
+of commands beginning with @code{chat} and another set beginning with
+@code{called-chat}.  The prefixes are only used to disambiguate
+different types of chat scripts, and this section ignores the prefixes
+when describing the commands.
+
+@table @code
+
+@item chat @var{strings}
+@findex chat
+
+Specify a chat script.  The arguments to the @code{chat} command are
+pairs of strings separated by whitespace.  The first string of each pair
+is an expect string, the second is a send string.  The program will wait
+for the expect string to appear; when it does, the program will send the
+send string.  If the expect string does not appear within a certain
+number of seconds (as set by the @code{chat-timeout} command), the chat
+script fails and, typically, the call is aborted.  If the final expect
+string is seen (and the optional final send string has been sent), the
+chat script is successful.
+
+An expect string may contain additional subsend and subexpect strings,
+separated by hyphens.  If the expect string is not seen, the subsend
+string is sent and the chat script continues by waiting for the
+subexpect string.  This means that a hyphen may not appear in an expect
+string; on an ASCII system, use @samp{\055} instead.
+
+An expect string may simply be @samp{""}, meaning to skip the expect
+phase.  Otherwise, the following escape characters may appear in expect
+strings:
+
+@table @samp
+@item \b
+a backspace character
+@item \n
+a newline or line feed character
+@item \N
+a null character (for HDB compatibility)
+@item \r
+a carriage return character
+@item \s
+a space character
+@item \t
+a tab character
+@item \\
+a backslash character
+@item \@var{ddd}
+character @var{ddd}, where @var{ddd} are up to three octal digits
+@item \x@var{ddd}
+character @var{ddd}, where @var{ddd} are hexadecimal digits.
+@end table
+
+As in C, there may be up to three octal digits following a backslash,
+but the hexadecimal escape sequence continues as far as possible.  To
+follow a hexadecimal escape sequence with a hex digit, interpose a send
+string of @samp{""}.
+
+A chat script expect string may also specify a timeout.  This is done by
+using the escape sequence @samp{\W@var{seconds}}.  This escape sequence
+may only appear at the very end of the expect string.  It temporarily
+overrides the timeout set by @code{chat-timeout} (described below) only
+for the expect string to which it is attached.
+
+A send string may simply be @samp{""} to skip the send phase.
+Otherwise, all of the escape characters legal for expect strings may be
+used, and the following escape characters are also permitted:
+
+@table @samp
+@item EOT
+send an end of transmission character (@kbd{^D})
+@item BREAK
+send a break character (may not work on all systems)
+@item \c
+suppress trailing carriage return at end of send string
+@item \d
+delay sending for 1 or 2 seconds
+@item \e
+disable echo checking
+@item \E
+enable echo checking
+@item \K
+same as @samp{BREAK} (for HDB compatibility)
+@item \p
+pause sending for a fraction of a second
+@end table
+
+Some specific types of chat scripts also define additional escape
+sequences that may appear in the send string.  For example, the login
+chat script defines @samp{\L} and @samp{\P} to send the login name and
+password, respectively.
+
+A carriage return will be sent at the end of each send string, unless
+the @kbd{\c} escape sequence appears in the string.  Note that some UUCP
+packages use @kbd{\b} for break, but here it means backspace.
+
+Echo checking means that after writing each character the program will
+wait until the character is echoed.  Echo checking must be turned on
+separately for each send string for which it is desired; it will be
+turned on for characters following @kbd{\E} and turned off for characters
+following @kbd{\e}.
+
+@item chat-timeout @var{number}
+@findex chat-timeout
+
+The number of seconds to wait for an expect string in the chat script,
+before timing out and sending the next subsend, or failing the chat
+script entirely.  The default value is 10 for a login chat or 60 for any
+other type of chat.
+
+@item chat-fail @var{string}
+@findex chat-fail
+
+If the @var{string} is seen at any time during a chat script, the chat
+script is aborted.  The string may not contain any whitespace
+characters: escape sequences must be used for them.  Multiple
+@code{chat-fail} commands may appear in a single chat script.  The
+default is to have none.
+
+This permits a chat script to be quickly aborted if an error string is
+seen.  For example, a script used to dial out on a modem might use the
+command @samp{chat-fail BUSY} to stop the chat script immediately if the
+string @samp{BUSY} was seen.
+
+The @code{chat-fail} strings are considered in the order they are
+listed, so if one string is a suffix of another the longer one should be
+listed first.  This affects the error message which will be logged.  Of
+course, if one string is contained within another, but is not a suffix,
+the smaller string will always be found before the larger string could
+match.
+
+@item chat-seven-bit @var{boolean}
+@findex chat-seven-bit
+
+If the argument is true, all incoming characters are stripped to seven
+bits when being compared to the expect string.  Otherwise all eight bits
+are used in the comparison.  The default is true, because some Unix
+systems generate parity bits during the login prompt which must be
+ignored while running a chat script.  This has no effect on any
+@code{chat-program}, which must ignore parity by itself if necessary.
+
+@item chat-program @var{strings}
+@findex chat-program
+
+Specify a program to run before executing the chat script.  This program
+could run its own version of a chat script, or it could do whatever it
+wants.  If both @code{chat-program} and @code{chat} are specified, the
+program is executed first followed by the chat script.
+
+The first argument to the @code{chat-program} command is the program
+name to run.  The remaining arguments are passed to the program.  The
+following escape sequences are recognized in the arguments:
+
+@table @kbd
+@item \Y
+port device name
+@item \S
+port speed
+@item \\
+backslash
+@end table
+
+Some specific uses of @code{chat-program} define additional escape
+sequences.
+
+Arguments other than escape sequences are passed exactly as they appear
+in the configuration file, except that sequences of whitespace are
+compressed to a single space character (this exception may be removed in
+the future).
+
+If the @code{chat-program} command is not used, no program is run.
+
+On Unix, the standard input and standard output of the program will be
+attached to the port in use.  Anything the program writes to standard
+error will be written to the UUCP log file.  No other file descriptors
+will be open.  If the program does not exit with a status of 0, it will
+be assumed to have failed.  This means that the dialing programs used by
+some versions of HDB may not be used directly, but you may be able to
+run them via the @code{dialHDB} program in the @file{contrib} directory.
+
+The program will be run as the @code{uucp} user, and the environment
+will be that of the process that started @code{uucico}, so care must be
+taken to maintain security.
+
+No search path is used to find the program; a full file name must be
+given.  If the program is an executable shell script, it will be passed
+to @file{/bin/sh} even on systems which are unable to execute shell
+scripts.
+
+@end table
+
+Here is a simple example of a chat script that might be used to reset a
+Hayes compatible modem.
+
+@example
+chat "" ATZ OK-ATZ-OK
+@end example
+
+The first expect string is @samp{""}, so it is ignored.  The chat script
+then sends @samp{ATZ}.  If the modem responds with @samp{OK}, the chat
+script finishes.  If 60 seconds (the default timeout) pass before seeing
+@samp{OK}, the chat script sends another @samp{ATZ}.  If it then sees
+@samp{OK}, the chat script succeeds.  Otherwise, the chat script fails.
+
+For a more complex chat script example, see @ref{Logging In}.
+
+@node config File, sys File, Chat Scripts, Configuration Files
+@section The Main Configuration File
+@cindex config file
+@cindex main configuration file
+@cindex configuration file (config)
+
+The main configuration file is named @file{config}.
+
+Since all the values that may be specified in the main configuration
+file also have defaults, there need not be a main configuration file at
+all.
+
+Each command in @file{config} may have a program prefix, which is a
+separate word appearing at the beginning of the line.  The currently
+supported prefixes are @samp{uucp} and @samp{cu}.  Any command prefixed
+by @samp{uucp} will not be read by the @code{cu} program.  Any command
+prefixed by @samp{cu} will only be read by the @code{cu} program.  For
+example, to use a list of systems known only to @code{cu}, list them in
+a separate file @file{@var{file}} and put @samp{cu sysfile
+@file{@var{file}}} in @file{config}.
+
+@menu
+* Miscellaneous (config)::      Miscellaneous config File Commands
+* Configuration File Names::    Using Different Configuration Files
+* Log File Names::              Using Different Log Files
+* Debugging Levels::            Debugging Levels
+@end menu
+
+@node Miscellaneous (config), Configuration File Names, config File, config File
+@subsection Miscellaneous config File Commands
+
+@table @code
+
+@item nodename @var{string}
+@findex nodename
+@itemx hostname @var{string}
+@findex hostname
+@itemx uuname @var{string}
+@findex uuname
+@cindex UUCP system name
+@cindex system name
+
+These keywords are equivalent.  They specify the UUCP name of the local
+host.  If there is no configuration file, an appropriate system function
+will be used to get the host name, if possible.
+
+@item spool @var{string}
+@findex spool
+@cindex spool directory, setting
+@cindex /usr/spool/uucp
+
+Specify the spool directory.  The default is from @file{policy.h}.  This
+is where UUCP files are queued.  Status files and various sorts of
+temporary files are also stored in this directory and subdirectories of
+it.
+
+@item pubdir @var{string}
+@findex pubdir in config file
+@cindex public directory
+@cindex uucppublic
+@cindex /usr/spool/uucppublic
+
+Specify the public directory.  The default is from @file{policy.h}.
+When a file is named using a leading @kbd{~/}, it is taken from or to
+the public directory.  Each system may use a separate public directory
+by using the @code{pubdir} command in the system configuration file; see
+@ref{Miscellaneous (sys)}.
+
+@item lockdir @var{string}
+@findex lockdir
+@cindex lock directory
+
+Specify the directory to place lock files in.  The default is from
+@file{policy.h}; see the information in that file.  Normally the lock
+directory should be set correctly in @file{policy.h}, and not changed
+here.  However, changing the lock directory is sometimes useful for
+testing purposes.  This only affects lock files for devices and systems;
+it does not affect certain internal lock files which are stored in the
+spool directory (@pxref{Spool Lock Files}).
+
+@item unknown @var{string} @dots{}
+@findex unknown
+@cindex unknown systems
+
+The @var{string} and subsequent arguments are treated as though they
+appeared in the system file (@pxref{sys File}).  They are used to apply
+to any unknown systems that may call in, probably to set file transfer
+permissions and the like.  If the @code{unknown} command is not used,
+unknown systems are not permitted to call in.
+
+@item strip-login @var{boolean}
+@findex strip-login
+@cindex parity in login names
+
+If the argument is true, then, when @code{uucico} is doing its own login
+prompting with the @samp{-e}, @samp{-l}, or @samp{-w} switches, it will
+strip the parity bit when it reads the login name and password.
+Otherwise all eight bits will be used when checking the strings against
+the UUCP password file.  The default is true, since some other UUCP
+packages send parity bits with the login name and password, and few
+systems use eight bit characters in the password file.
+
+@item strip-proto @var{boolean}
+@findex strip-proto
+
+If the argument is true, then @code{uucico} will strip the parity bit
+from incoming UUCP protocol commands.  Otherwise all eight bits will be
+used.  This only applies to commands which are not encapsulated in a
+link layer protocol.  The default is true, which should always be
+correct unless your UUCP system names use eight bit characters.
+
+@item max-uuxqts @var{number}
+@findex max-uuxqts
+
+Specify the maximum number of @code{uuxqt} processes which may run at
+the same time.  Having several @code{uuxqt} processes running at once
+can significantly slow down a system, but, since @code{uuxqt} is
+automatically started by @code{uucico}, it can happen quite easily.  The
+default for @code{max-uuxqts} is 0, which means that there is no limit.
+If HDB configuration files are being read and the code was compiled
+without @code{HAVE_TAYLOR_CONFIG}, then, if the file @file{Maxuuxqts} in
+the configuration directory contains a readable number, it will be used
+as the value for @code{max-uuxqts}.
+
+@item run-uuxqt @var{string} or @var{number}
+@findex run-uuxqt
+
+Specify when @code{uuxqt} should be run by @code{uucico}.  This may be a
+positive number, in which case @code{uucico} will start a @code{uuxqt}
+process whenever it receives the given number of execution files from
+the remote system, and, if necessary, at the end of the call.  The
+argument may also be one of the strings @samp{once}, @samp{percall}, or
+@samp{never}.  The string @samp{once} means that @code{uucico} will
+start @code{uuxqt} once at the end of execution.  The string
+@samp{percall} means that @code{uucico} will start @code{uuxqt} once per
+call that it makes (this is only different from @code{once} when
+@code{uucico} is invoked in a way that causes it to make multiple calls,
+such as when the @samp{-r1} option is used without the @samp{-s}
+option).  The string @samp{never} means that @code{uucico} will never
+start @code{uuxqt}, in which case @code{uuxqt} should be periodically
+run via some other mechanism.  The default depends upon which type of
+configuration files are being used; if @code{HAVE_TAYLOR_CONFIG} is used
+the default is @samp{once}, otherwise if @code{HAVE_HDB_CONFIG} is used
+the default is @samp{percall}, and otherwise, for @code{HAVE_V2_CONFIG},
+the default is @samp{10}.
+
+@item timetable @var{string} @var{string}
+@findex timetable
+
+The @code{timetable} defines a timetable that may be used in
+subsequently appearing time strings; see @ref{Time Strings}.  The first
+string names the timetable entry; the second is a time string.
+
+The following @code{timetable} commands are predefined.  The NonPeak
+timetable is included for compatibility.  It originally described the
+offpeak hours of Tymnet and Telenet, but both have since changed their
+schedules.
+
+@example
+timetable Evening Wk1705-0755,Sa,Su
+timetable Night Wk2305-0755,Sa,Su2305-1655
+timetable NonPeak Wk1805-0655,Sa,Su
+@end example
+
+If this command does not appear, then, obviously, no additional
+timetables will be defined.
+
+@item v2-files @var{boolean}
+@findex v2-files
+
+If the code was compiled to be able to read V2 configuration files, a
+false argument to this command will prevent them from being read.
+This can be useful while testing.  The default is true.
+
+@item hdb-files @var{boolean}
+@findex hdb-files
+
+If the code was compiled to be able to read HDB configuration files, a
+false argument to this command will prevent them from being read.
+This can be useful while testing.  The default is true.
+
+@end table
+
+@node Configuration File Names, Log File Names, Miscellaneous (config), config File
+@subsection Configuration File Names
+
+@table @code
+
+@item sysfile @var{strings}
+@findex sysfile
+
+Specify the system file(s).  The default is the file @file{sys} in the
+directory @var{newconfigdir}.  These files hold information about other
+systems with which this system communicates; see @ref{sys File}.
+Multiple system files may be given on the line, and the @code{sysfile}
+command may be repeated; each system file has its own set of defaults.
+
+@item portfile @var{strings}
+@findex portfile
+
+Specify the port file(s).  The default is the file @file{port} in the
+directory @var{newconfigdir}.  These files describe ports which are used
+to call other systems and accept calls from other systems; see @ref{port
+File}.  No port files need be named at all.  Multiple port files may be
+given on the line, and the @code{portfile} command may be repeated.
+
+@item dialfile @var{strings}
+@findex dialfile
+
+Specify the dial file(s).  The default is the file @file{dial} in the
+directory @var{newconfigdir}.  These files describe dialing devices
+(modems); see @ref{dial File}.  No dial files need be named at all.
+Multiple dial files may be given on the line, and the @code{dialfile}
+command may be repeated.
+
+@item dialcodefile @var{strings}
+@findex dialcodefile
+@cindex configuration file (dialcode)
+@cindex dialcode file
+@cindex dialcode configuration file
+
+Specify the dialcode file(s).  The default is the file @file{dialcode}
+in the directory @var{newconfigdir}.  These files specify dialcodes that
+may be used when sending phone numbers to a modem.  This permits using
+the same set of phone numbers in different area-codes or with different
+phone systems, by using dialcodes to specify the calling sequence.  When
+a phone number goes through dialcode translation, the leading alphabetic
+characters are stripped off.  The dialcode files are read line by line,
+just like any other configuration file, and when a line is found whose
+first word is the same as the leading characters from the phone number,
+the second word on the line (which would normally consist of numbers)
+replaces the dialcode in the phone number.  No dialcode file need be
+used.  Multiple dialcode files may be specified on the line, and the
+@code{dialcodefile} command may be repeated; all the dialcode files will
+be read in turn until a dialcode is located.
+
+@item callfile @var{strings}
+@findex callfile
+@cindex call out file
+@cindex call configuration file
+@cindex call out login name
+@cindex call out password
+@cindex configuration file (call)
+
+Specify the call out login name and password file(s).  The default is
+the file @file{call} in the directory @var{newconfigdir}.  If the call
+out login name or password for a system are given as @kbd{*}
+(@pxref{Logging In}), these files are read to get the real login name or
+password.  Each line in the file(s) has three words: the system name,
+the login name, and the password.  The login name and password may
+contain escape sequences like those in a chat script expect string
+(@pxref{Chat Scripts}).  This file is only used when placing calls to
+remote systems; the password file described under @code{passwdfile}
+below is used for incoming calls.  The intention of the call out file is
+to permit the system file to be publically readable; the call out files
+must obviously be kept secure.  These files need not be used.  Multiple
+call out files may be specified on the line, and the @code{callfile}
+command may be repeated; all the files will be read in turn until the
+system is found.
+
+@item passwdfile @var{strings}
+@findex passwdfile
+@cindex passwd file
+@cindex passwd configuration file
+@cindex configuration file (passwd)
+@cindex call in login name
+@cindex call in password
+
+Specify the password file(s) to use for login names when @code{uucico}
+is doing its own login prompting, which it does when given the
+@samp{-e}, @samp{-l} or @samp{-w} switches.  The default is the file
+@file{passwd} in the directory @var{newconfigdir}.  Each line in the
+file(s) has two words: the login name and the password (e.g., @code{Ufoo
+foopas}).  They may contain escape sequences like those in a chat script
+expect string (@pxref{Chat Scripts}).  The login name is accepted before
+the system name is known, so these are independent of which system is
+calling in; a particular login may be required for a system by using the
+@code{called-login} command in the system file (@pxref{Accepting a
+Call}).  These password files are optional, although one must exist if
+@code{uucico} is to present its own login prompts.
+
+As a special exception, a colon may be used to separate the login name
+from the password, and a colon may be used to terminate the password.
+This means that the login name and password may not contain a colon.
+This feature, in conjunction with the @code{HAVE_ENCRYPTED_PASSWORDS}
+macro in @file{policy.h}, permits using a standard Unix
+@file{/etc/passwd} as a UUCP password file, providing the same set of
+login names and passwords for both @code{getty} and @code{uucico}.
+
+Multiple password files may be specified on the line, and the
+@code{passwdfile} command may be repeated; all the files will be read in
+turn until the login name is found.
+
+@end table
+
+@node Log File Names, Debugging Levels, Configuration File Names, config File
+@subsection Log File Names
+
+@table @code
+
+@item logfile @var{string}
+@findex logfile
+@cindex log file
+
+Name the log file.  The default is from @file{policy.h}.  Logging
+information is written to this file.  If @code{HAVE_HDB_LOGGING} is
+defined in @file{policy.h}, then by default a separate log file is used
+for each system; using this command to name a log file will cause all
+the systems to use it.
+
+@item statfile @var{string}
+@findex statfile
+@cindex statistics file
+
+Name the statistics file.  The default is from @file{policy.h}.
+Statistical information about file transfers is written to this file.
+
+@item debugfile @var{string}
+@findex debugfile
+@cindex debugging file
+
+Name the file to which all debugging information is written.  The
+default is from @file{policy.h}.  This command is only effective if the
+code has been compiled to include debugging (this is controlled by the
+@code{DEBUG} macro in @file{policy.h}).  If debugging is on, messages
+written to the log file are also written to the debugging file to make
+it easier to keep the order of actions straight.  The debugging file is
+different from the log file because information such as passwords can
+appear in it, so it must be not be publically readable.
+
+@end table
+
+@node Debugging Levels,  , Log File Names, config File
+@subsection Debugging Levels
+
+@table @code
+
+@item debug @var{string} @dots{}
+@findex debug in config file
+
+Set the debugging level.  This command is only effective if the code has
+been compiled to include debugging.  The default is to have no
+debugging.  The arguments are strings which name the types of debugging
+to be turned on.  The following types of debugging are defined:
+
+@table @samp
+@item abnormal
+Output debugging messages for abnormal situations, such as recoverable errors.
+@item chat
+Output debugging messages for chat scripts.
+@item handshake
+Output debugging messages for the initial handshake.
+@item uucp-proto
+Output debugging messages for the UUCP session protocol.
+@item proto
+Output debugging messages for the individual link protocols.
+@item port
+Output debugging messages for actions on the communication port.
+@item config
+Output debugging messages while reading the configuration files.
+@item spooldir
+Output debugging messages for actions in the spool directory.
+@item execute
+Output debugging messages whenever another program is executed.
+@item incoming
+List all incoming data in the debugging file.
+@item outgoing
+List all outgoing data in the debugging file.
+@item all
+All of the above.
+@end table
+
+The debugging level may also be specified as a number.  A 1 will set
+@samp{chat} debugging, a 2 will set both @samp{chat} and
+@samp{handshake} debugging, and so on down the possibilities.  Currently
+an 11 will turn on all possible debugging, since there are 11 types of
+debugging messages listed above; more debugging types may be added in
+the future.  The @code{debug} command may be used several times in the
+configuration file; every debugging type named will be turned on.  When
+running any of the programs, the @samp{-x} switch (actually, for
+@code{uulog} it's the @samp{-X} switch) may be used to turn on
+debugging.  The argument to the @samp{-x} switch is one of the strings
+listed above, or a number as described above, or a comma separated list
+of strings (e.g.,  @samp{-x chat,handshake}).  The @samp{-x} switch may
+also appear several times on the command line, in which case all named
+debugging types will be turned on.  The @samp{-x} debugging is in
+addition to any debugging specified by the @code{debug} command; there
+is no way to cancel debugging information.  The debugging level may also
+be set specifically for calls to or from a specific system with the
+@code{debug} command in the system file (@pxref{Miscellaneous (sys)}).
+
+The debugging messages are somewhat idiosyncratic; it may be necessary
+to refer to the source code for additional information in some cases.
+
+@end table
+
+@node sys File, port File, config File, Configuration Files
+@section The System Configuration File
+@cindex sys file
+@cindex system configuration file
+@cindex configuration file (sys) 
+
+By default there is a single system configuration, named @file{sys} in
+the directory @var{newconfigdir}.  This may be overridden by the
+@code{sysfile} command in the main configuration file; see
+@ref{Configuration File Names}.
+
+These files describe all remote systems known to the UUCP package.
+
+@menu
+* Defaults and Alternates::     Using Defaults and Alternates
+* Naming the System::           Naming the System
+* Calling Out::                 Calling Out
+* Accepting a Call::            Accepting a Call
+* Protocol Selection::          Protocol Selection
+* File Transfer Control::       File Transfer Control
+* Miscellaneous (sys)::         Miscellaneous sys File Commands
+* Default sys File Values::     Default Values
+@end menu
+
+@node Defaults and Alternates, Naming the System, sys File, sys File
+@subsection Defaults and Alternates
+
+The first set of commands in the file, up to the first @code{system}
+command, specify defaults to be used for all systems in that file.  Each
+@file{sys} file uses a different set of defaults.
+
+Subsequently, each set of commands from @code{system} up to the next
+@code{system} command describe a particular system.  Default values may
+be overridden for specific systems.
+
+Each system may then have a series of alternate choices to use when
+calling out or calling in.  The first set of commands for a particular
+system, up to the first @code{alternate} command, provide the first
+choice.  Subsequently, each set of commands from @code{alternate} up to
+the next @code{alternate} command describe an alternate choice for
+calling out or calling in.
+
+When a system is called, the commands before the first @code{alternate}
+are used to select a phone number, port, and so forth; if the call fails
+for some reason, the commands between the first @code{alternate} and the
+second are used, and so forth.  Well, not quite.  Actually, each
+succeeding alternate will only be used if it is different in some
+relevant way (different phone number, different chat script, etc.).  If
+you want to force the same alternate to be used again (to retry a phone
+call more than once, for example), enter the phone number (or any other
+relevant field) again to make it appear different.
+
+The alternates can also be used to give different permissions to an
+incoming call based on the login name.  This will only be done if the
+first set of commands, before the first @code{alternate} command, uses
+the @code{called-login} command.  The list of alternates will be
+searched, and the first alternate with a matching @code{called-login}
+command will be used.  If no alternates match, the call will be
+rejected.
+
+The @code{alternate} command may also be used in the file-wide defaults
+(the set of commands before the first @code{system} command).  This
+might be used to specify a list of ports which are available for all
+systems (for an example of this, see @ref{Gateway Example}) or to
+specify permissions based on the login name used by the remote system
+when it calls in.  The first alternate for each system will default to
+the first alternate for the file-wide defaults (as modified by the
+commands used before the first @code{alternate} command for this
+system), the second alternate for each system to the second alternate
+for the file-wide defaults (as modified the same way), and so forth.  If
+a system specifies more alternates than the file-wide defaults, the
+trailing ones will default to the last file-wide default alternate.  If
+a system specifies fewer alternates than the file-wide defaults, the
+trailing file-wide default alternates will be used unmodified.  The
+@code{default-alternates} command may be used to modify this behaviour.
+
+This can all get rather confusing, although it's easier to use than to
+describe concisely; the @code{uuchk} program may be used to ensure that
+you are getting what you want.
+
+@need 2000
+@node Naming the System, Calling Out, Defaults and Alternates, sys File
+@subsection Naming the System
+
+@table @code
+
+@item system @var{string}
+@findex system
+
+Specify the remote system name.  Subsequent commands up to the next
+@code{system} command refer to this system.
+
+@item alternate [@var{string}]
+@findex alternate
+
+Start an alternate set of commands (@pxref{Defaults and Alternates}).
+An optional argument may be used to name the alternate.  This name will
+be recorded in the log file if the alternate is used to call the system.
+There is no way to name the first alternate (the commands before the
+first @code{alternate} command).
+
+@item default-alternates @var{boolean}
+@findex default-alternates
+
+If the argument is false, any remaining default alternates (from the
+defaults specified at the top of the current system file) will not be
+used.  The default is true.
+
+@item alias @var{string}
+@findex alias
+
+Specify an alias for the current system.  The alias may be used by local
+@code{uucp} and @code{uux} commands, as well as by the remote system
+(which can be convenient if a remote system changes its name).  The
+default is to have no aliases.
+
+@item myname @var{string}
+@findex myname
+
+Specifies a different system name to use when calling the remote system.
+Also, if @code{called-login} is used and is not @samp{ANY}, then, when a
+system logs in with that login name, @var{string} is used as the local
+system name.  Because the local system name must be determined before
+the remote system has identified itself, using @code{myname} and
+@code{called-login} together for any system will set the local name for
+that login; this means that each locally used system name must have a
+unique login name associated with it.  This allows a system to have
+different names for an external and an internal network.  The default is
+to not use a special local name.
+
+@end table
+
+@node Calling Out, Accepting a Call, Naming the System, sys File
+@subsection Calling Out
+
+This section describes commands used when placing a call to another
+system.
+
+@menu
+* When to Call::                When to Call
+* Placing the Call::            Placing the Call
+* Logging In::                  Logging In
+@end menu
+
+@need 2000
+@node When to Call, Placing the Call, Calling Out, Calling Out
+@subsubsection When to Call
+
+@table @code
+
+@item time @var{string} [@var{number}]
+@findex time
+
+Specify when the system may be called.  The first argument is a time
+string; see @ref{Time Strings}.  The optional second argument specifies
+a retry time in minutes.  If a call made during a time that matches the
+time string fails, no more calls are permitted until the retry time has
+passed.  By default an exponentially increasing retry time is used:
+after each failure the next retry period is longer.  A retry time
+specified in the @code{time} command is always a fixed amount of time.
+
+The @code{time} command may appear multiple times in a single alternate,
+in which case if any time string matches the system may be called.  When
+the @code{time} command is used for a particular system, any @code{time}
+or @code{timegrade} commands that appeared in the system defaults are
+ignored.
+
+The default time string is @samp{Never}.
+
+@item timegrade @var{character} @var{string} [@var{number}]
+@findex timegrade
+@cindex grades
+
+The @var{character} specifies a grade.  It must be a single letter or
+digit.  The @var{string} is a time string (@pxref{Time Strings}).  All
+jobs of grade @var{character} or higher (where @kbd{0} > @kbd{9} >
+@kbd{A} > @kbd{Z} > @kbd{a} > @kbd{z}) may be run at the specified time.
+An ordinary @code{time} command is equivalent to using @code{timegrade}
+with a grade of @kbd{z}, permitting all jobs.  If there are no jobs of a
+sufficiently high grade according to the time string, the system will
+not be called.  Giving the @samp{-s} switch to @code{uucico} to force it
+to call a system causes it to assume there is a job of grade @kbd{0}
+waiting to be run.
+
+The optional third argument specifies a retry time in minutes.  See the
+@code{time} command, above, for more details.
+
+Note that the @code{timegrade} command serves two purposes: 1) if there
+is no job of sufficiently high grade the system will not be called, and
+2) if the system is called anyway (because the @samp{-s} switch was
+given to @code{uucico}) only jobs of sufficiently high grade will be
+transferred.  However, if the other system calls in, the
+@code{timegrade} commands are ignored, and jobs of any grade may be
+transferred (but see @code{call-timegrade} and @code{called-timegrade},
+below).  Also, the @code{timegrade} command will not prevent the other
+system from transferring any job it chooses, regardless of who placed
+the call.
+
+The @code{timegrade} command may appear multiple times without using
+@code{alternate}.  When the @code{timegrade} command is used for a
+particular system, any @code{time} or @code{timegrade} commands that
+appeared in the system defaults are ignored.
+
+If this command does not appear, there are no restrictions on what grade
+of work may be done at what time.
+
+@item max-retries @var{number}
+@findex max-retries
+
+Gives the maximum number of times this system may be retried.  If this
+many calls to the system fail, it will be called at most once a day
+whatever the retry time is.  The default is 26.
+
+@item success-wait @var{number}
+
+A retry time, in seconds, which applies after a successful call.  This
+can be used to put a limit on how frequently the system is called.  For
+example, an argument of 1800 means that the system will not be called
+more than once every half hour.  The default is 0, which means that
+there is no limit.
+
+@item call-timegrade @var{character} @var{string}
+@findex call-timegrade
+
+The @var{character} is a single character @kbd{A} to @kbd{Z}, @kbd{a} to
+@kbd{z}, or @kbd{0} to @kbd{9} and specifies a grade.  The @var{string}
+is a time string (@pxref{Time Strings}).  If a call is placed to the
+other system during a time which matches the time string, the remote
+system will be requested to only run jobs of grade @var{character} or
+higher.  Unfortunately, there is no way to guarantee that the other
+system will obey the request (this UUCP package will, but there are
+others which will not); moreover, job grades are historically somewhat
+arbitrary, so specifying a grade will only be meaningful if the other
+system cooperates in assigning grades.  This grade restriction only
+applies when the other system is called, not when the other system calls
+in.
+
+The @code{call-timegrade} command may appear multiple times without
+using @code{alternate}.  If this command does not appear, or if none of
+the time strings match, the remote system will be allowed to send
+whatever grades of work it chooses.
+
+@item called-timegrade @var{character} @var{string}
+@findex called-timegrade
+
+The @var{character} is a single character @kbd{A} to @kbd{Z}, @kbd{a} to
+@kbd{z}, or @kbd{0} to @kbd{9} and specifies a grade.  The @var{string}
+is a time string (@pxref{Time Strings}).  If a call is received from the
+other system during a time which matches the time string, only jobs of
+grade @var{character} or higher will be sent to the remote system.  This
+allows the job grade to be set for incoming calls, overriding any
+request made by the remote uucico.  As noted above, job grades are
+historically somewhat arbitrary, so specifying a grade will only be
+meaningful if the other system cooperates in assigning grades.  This
+grade restriction only applies to jobs on the local system; it does not
+affect the jobs transferred by the remote system.  This grade
+restriction only applies when the other system calls in, not when the
+other system is called.
+
+The @code{called-timegrade} command may appear multiple times.  If this
+command does not appear, or if none of the time strings match, any grade
+may be sent to the remote system upon receiving a call.
+
+@end table
+
+@need 2000
+@node Placing the Call, Logging In, When to Call, Calling Out
+@subsubsection Placing the Call
+
+@table @code
+
+@itemx speed @var{number}
+@findex speed in sys file
+@item baud @var{number}
+@findex baud in sys file
+
+Specify the speed (the term @dfn{baud} is technically incorrect, but
+widely understood) at which to call the system.  This will try all
+available ports with that speed until an unlocked port is found.  The
+ports are defined in the port file.  If both @code{speed} and
+@code{port} commands appear, both are used when selecting a port.  To
+allow calls at more than one speed, the @code{alternate} command must be
+used (@pxref{Defaults and Alternates}).  If this command does not
+appear, there is no default; the speed may be specified in the port
+file, but if it is not then the natural speed of the port will be used
+(whatever that means on the system).  Specifying an explicit speed of 0
+will request the natural speed of the port (whatever the system sets it
+to), overriding any default speed from the defaults at the top of the
+file.
+
+@item port @var{string}
+@findex port in sys file
+
+Name a particular port or type of port to use when calling the system.
+The information for this port is obtained from the port file.  If this
+command does not appear, there is no default; a port must somehow be
+specified in order to call out (it may be specified implicitly using the
+@code{speed} command or explicitly using the next version of
+@code{port}).  There may be many ports with the same name; each will be
+tried in turn until an unlocked one is found which matches the desired
+speed.
+
+@item port @var{string} @dots{}
+
+If more than one string follows the @code{port} command, the strings are
+treated as a command that might appear in the port file (@pxref{port
+File}).  If a port is named (by using a single string following
+@code{port}) these commands are ignored; their purpose is to permit
+defining the port completely in the system file rather than always
+requiring entries in two different files.  In order to call out, a port
+must be specified using some version of the @code{port} command, or by
+using the @code{speed} command to select ports from the port file.
+
+@item phone @var{string}
+@findex phone
+@itemx address @var{string}
+@findex address
+
+Give a phone number to call (when using a modem port) or a remote host
+to contact (when using a TCP or TLI port).  The commands @code{phone}
+and @code{address} are equivalent; the duplication is intended to
+provide a mnemonic choice depending on the type of port in use.
+
+When used with a modem port, an @kbd{=} character in the phone number
+means to wait for a secondary dial tone (although only some modems
+support this); a @kbd{-} character means to pause while dialing for 1
+second (again, only some modems support this).  If the system has more
+than one phone number, each one must appear in a different alternate.
+The @code{phone} command must appear in order to call out on a modem;
+there is no default.
+
+When used with a TCP port, the string names the host to contact.  It may
+be a domain name or a numeric Internet address.  If no address is
+specified, the system name is used.
+
+When used with a TLI port, the string is treated as though it were an
+expect string in a chat script, allowing the use of escape characters
+(@pxref{Chat Scripts}).  The @code{dialer-sequence} command in the port
+file may override this address (@pxref{port File}).
+
+When used with a port that not a modem or TCP or TLI, this command is
+ignored.
+
+@end table
+
+@node Logging In,  , Placing the Call, Calling Out
+@subsubsection Logging In
+@table @code
+
+@item chat @var{strings}
+@findex chat in sys file
+@item chat-timeout @var{number}
+@findex chat-timeout in sys file
+@item chat-fail @var{string}
+@findex chat-fail in sys file
+@item chat-seven-bit @var{boolean}
+@findex chat-seven-bit in sys file
+@item chat-program @var{strings}
+@findex chat-program in sys file
+
+These commands describe a chat script to use when logging on to a remote
+system.  This login chat script is run after any chat script defined in
+the @file{dial} file (@pxref{dial File}).  Chat scripts are explained in
+@ref{Chat Scripts}.
+
+Two additional escape sequences may be used in send strings.
+
+@table @samp
+@item \L
+Send the login name, as set by the @code{call-login} command.
+@item \P
+Send the password, as set by the @code{call-password} command.
+@end table
+
+Three additional escape sequences may be used with the
+@code{chat-program} command.  These are @samp{\L} and @samp{\P}, which
+become the login name and password, respectively, and @samp{\Z}, which
+becomes the name of the system of being called.
+
+The default chat script is:
+
+@example
+chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
+@end example
+
+This will send a carriage return (the @kbd{\c} suppresses the additional
+trailing carriage return that would otherwise be sent) and waits for the
+string @samp{ogin:} (which would be the last part of the @samp{login:}
+prompt supplied by a Unix system).  If it doesn't see @samp{ogin:}, it
+sends a break and waits for @samp{ogin:} again.  If it still doesn't see
+@samp{ogin:}, it sends another break and waits for @samp{ogin:} again.
+If it still doesn't see @samp{ogin:}, the chat script aborts and hangs
+up the phone.  If it does see @samp{ogin:} at some point, it sends the
+login name (as specified by the @code{call-login} command) followed by a
+carriage return (since all send strings are followed by a carriage
+return unless @kbd{\c} is used) and waits for the string @samp{word:}
+(which would be the last part of the @samp{Password:} prompt supplied by
+a Unix system).  If it sees @samp{word:}, it sends the password and a
+carriage return, completing the chat script.  The program will then
+enter the handshake phase of the UUCP protocol.
+
+This chat script will work for most systems, so you will only be
+required to use the @code{call-login} and @code{call-password} commands.
+In fact, in the file-wide defaults you could set defaults of
+@samp{call-login *} and @samp{call-password *}; you would then just have
+to make an entry for each system in the call-out login file.
+
+Some systems seem to flush input after the @samp{login:} prompt, so they
+may need a version of this chat script with a @kbd{\d} before the
+@kbd{\L}.  When using UUCP over TCP, some servers will not be handle the
+initial carriage return sent by this chat script; in this case you may
+have to specify the simple chat script @samp{ogin: \L word: \P}.
+
+@item call-login @var{string}
+@findex call-login
+
+Specify the login name to send with @kbd{\L} in the chat script.  If the
+string is @samp{*} (e.g., @samp{call-login *}) the login name will be
+fetched from the call out login name and password file
+(@pxref{Configuration File Names}).  The string may contain escape
+sequences as though it were an expect string in a chat script
+(@pxref{Chat Scripts}).  There is no default.
+
+@item call-password @var{string}
+@findex call-password
+
+Specify the password to send with @kbd{\P} in the chat script.  If the
+string is @samp{*} (e.g., @samp{call-password *}) the password will be
+fetched from the call-out login name and password file
+(@pxref{Configuration File Names}).  The string may contain escape
+sequences as though it were an expect string in a chat script
+(@pxref{Chat Scripts}).  There is no default.
+
+@end table
+
+@node Accepting a Call, Protocol Selection, Calling Out, sys File
+@subsection Accepting a Call
+
+@table @code
+
+@item called-login @var{strings}
+@findex called-login
+
+The first @var{string} specifies the login name that the system must use
+when calling in.  If it is @samp{ANY} (e.g., @samp{called-login ANY}) any
+login name may be used; this is useful to override a file-wide default
+and to indicate that future alternates may have different login names.
+Case is significant.  The default value is @samp{ANY}.  
+
+Different alternates (@pxref{Defaults and Alternates}) may use different
+@code{called-login} commands, in which case the login name will be used
+to select which alternate is in effect; this will only work if the first
+alternate (before the first @code{alternate} command) uses the
+@code{called-login} command.
+
+Additional strings may be specified after the login name; they are a
+list of which systems are permitted to use this login name.  If this
+feature is used, then normally the login name will only be given in a
+single @code{called-login} command.  Only systems which appear on the
+list, or which use an explicit @code{called-login} command, will be
+permitted to use that login name.  If the same login name is used more
+than once with a list of systems, all the lists are concatenated
+together.  This feature permits you to restrict a login name to a
+particular set of systems without requiring you to use the
+@code{called-login} command for every single system; you can achieve a
+similar effect by using a different system file for each permitted login
+name with an appropriate @code{called-login} command in the file-wide
+defaults.
+
+@item callback @var{boolean}
+@findex callback
+
+If @var{boolean} is true, then when the remote system calls
+@code{uucico} will hang up the connection and prepare to call it back.
+The default is false.
+
+@item called-chat @var{strings}
+@findex called-chat
+@item called-chat-timeout @var{number}
+@findex called-chat-timeout
+@item called-chat-fail @var{string}
+@findex called-chat-fail
+@item called-chat-seven-bit @var{boolean}
+@findex called-chat-seven-bit
+@item called-chat-program @var{strings}
+@findex called-chat-program
+  
+These commands may be used to define a chat script (@pxref{Chat
+Scripts}) that is run whenever the local system is called by the system
+being defined.  The chat script defined by the @code{chat} command
+(@pxref{Logging In}), on the other hand, is used when the remote system
+is called.  This called chat script might be used to set special modem
+parameters that are appropriate to a particular system.  It is run after
+protocol negotiation is complete, but before the protocol has been
+started.  For additional escape sequence which may be used besides those
+defined for all chat scripts, see @ref{Logging In}.  There is no default
+called chat script.  If the called chat script fails, the incoming call
+will be aborted.
+
+@end table
+
+@node Protocol Selection, File Transfer Control, Accepting a Call, sys File
+@subsection Protocol Selection
+
+@table @code
+
+@item protocol @var{string}
+@findex protocol in sys file
+
+Specifies which protocols to use for the other system, and in which
+order to use them.  This would not normally be used.  For example,
+@samp{protocol tfg}.
+
+The default depends on the characteristics of the port and the dialer,
+as specified by the @code{seven-bit} and @code{reliable} commands.  If
+neither the port nor the dialer use either of these commands, the
+default is to assume an eight-bit reliable connection.  The commands
+@samp{seven-bit true} or @samp{reliable false} might be used in either
+the port or the dialer to change this.  Each protocol has particular
+requirements that must be met before it will be considered during
+negotiation with the remote side.
+
+The @samp{t} and @samp{e} protocols are intended for use over TCP or
+some other communication path with end to end reliability, as they do no
+checking of the data at all.  They will only be considered on a TCP port
+which is both reliable and eight bit.  For technical details, see @ref{t
+Protocol}, and @ref{e Protocol}.
+
+The @samp{i} protocol is a bidirectional protocol.  It requires an
+eight-bit connection.  It will run over a half-duplex link, such as
+Telebit modems in PEP mode, but for efficient use of such a connection
+you must use the @code{half-duplex} command (@pxref{port File}).
+@xref{i Protocol}.
+
+The @samp{g} protocol is robust, but requires an eight-bit connection.
+@xref{g Protocol}.
+
+The @samp{G} protocol is the System V Release 4 version of the @samp{g}
+protocol.  @xref{Big G Protocol}.
+
+The @samp{a} protocol is a Zmodem like protocol, contributed by Doug
+Evans.  It requires an eight-bit connection, but unlike the @samp{g} or
+@samp{i} protocol it will work if certain control characters may not be
+transmitted.
+
+The @samp{j} protocol is a variant of the @samp{i} protocol which can
+avoid certain control characters.  The set of characters it avoids can
+be set by a parameter.  While it technically does not require an eight
+bit connection (it could be configured to avoid all characters with the
+high bit set) it would be very inefficient to use it over one.  It is
+useful over a eight-bit connection that will not transmit certain
+control characters.  @xref{j Protocol}.
+
+The @samp{f} protocol is intended for use with X.25 connections; it
+checksums each file as a whole, so any error causes the entire file to
+be retransmitted.  It requires a reliable connection, but only uses
+seven-bit transmissions.  It is a streaming protocol, so, while it can
+be used on a serial port, the port must be completely reliable and flow
+controlled; many aren't.  @xref{f Protocol}.
+
+The @samp{v} protocol is the @samp{g} protocol as used by the DOS
+program UUPC/Extended.  It is provided only so that UUPC/Extended users
+can use it; there is no particular reason to select it.  @xref{v
+Protocol}.
+
+The @samp{y} protocol is an efficient streaming protocol.  It does error
+checking, but when it detects an error it immediately aborts the
+connection.  This requires a reliable, flow controlled, eight-bit
+connection.  In practice, it is only useful on a connection that is
+nearly always error-free.  Unlike the @samp{t} and @samp{e} protocols,
+the connection need not be entirely error-free, so the @samp{y} protocol
+can be used on a serial port.  @xref{y Protocol}.
+
+The protocols will be considered in the order shown above.  This means
+that if neither the @code{seven-bit} nor the @code{reliable} command are
+used, the @samp{t} protocol will be used over a TCP connection and the
+@samp{i} protocol will be used over any other type of connection
+(subject, of course, to what is supported by the remote system; it may
+be assumed that all systems support the @samp{g} protocol).
+
+Note that currently specifying both @samp{seven-bit true} and
+@samp{reliable false} will not match any protocol.  If this occurs
+through a combination of port and dialer specifications, you will have
+to use the @code{protocol} command for the system or no protocol will be
+selected at all (the only reasonable choice would be @samp{protocol f}).
+
+A protocol list may also be specified for a port (@pxref{port File}),
+but, if there is a list for the system, the list for the port is
+ignored.
+
+@item protocol-parameter @var{character} @var{string} @dots{}
+@findex protocol-parameter in sys file
+
+@var{character} is a single character specifying a protocol.  The
+remaining strings are a command specific to that protocol which will be
+executed if that protocol is used.  A typical command is something like
+@samp{window 7}.  The particular commands are protocol specific.
+
+The @samp{i} protocol supports the following commands, all of which take
+numeric arguments:
+
+@table @code
+@item window
+The window size to request the remote system to use.  This must be
+between 1 and 16 inclusive.  The default is 16.
+@item packet-size
+The packet size to request the remote system to use.  This must be
+between 1 and 4095 inclusive.  The default is 1024.
+@item remote-packet-size
+If this is between 1 and 4095 inclusive, the packet size requested by
+the remote system is ignored, and this is used instead.  The default is
+0, which means that the remote system's request is honored.
+@item sync-timeout
+The length of time, in seconds, to wait for a SYNC packet from the remote
+system.  SYNC packets are exchanged when the protocol is started.  The
+default is 10.
+@item sync-retries
+The number of times to retry sending a SYNC packet before giving up.
+The default is 6.
+@item timeout
+The length of time, in seconds, to wait for an incoming packet before
+sending a negative acknowledgement.  The default is 10.
+@item retries
+The number of times to retry sending a packet or a negative
+acknowledgement before giving up and closing the connection.  The
+default is 6.
+@item errors
+The maximum number of errors to permit before closing the connection.
+The default is 100.
+@item error-decay
+The rate at which to ignore errors.  Each time this many packets are
+received, the error count is decreased by one, so that a long connection
+with an occasional error will not exceed the limit set by @code{errors}.
+The default is 10.
+@item ack-frequency
+The number of packets to receive before sending an acknowledgement.  The
+default is half the requested window size, which should provide good
+performance in most cases.
+@end table
+
+The @samp{g}, @samp{G} and @samp{v} protocols support the following
+commands, all of which take numeric arguments, except
+@code{short-packets} which takes a boolean argument:
+
+@table @code
+@item window
+The window size to request the remote system to use.  This must be
+between 1 and 7 inclusive.  The default is 7.
+@item packet-size
+The packet size to request the remote system to use.  This must be a
+power of 2 between 32 and 4096 inclusive.  The default is 64 for the
+@samp{g} and @samp{G} protocols and 1024 for the @samp{v} protocol.
+Many older UUCP packages do not support packet sizes larger than 64, and
+many others do not support packet sizes larger than 128.  Some UUCP
+packages will even dump core if a larger packet size is requested.  The
+packet size is not a negotiation, and it may be different in each
+direction.  If you request a packet size larger than the remote system
+supports, you will not be able to send any files.
+@item startup-retries
+The number of times to retry the initialization sequence.  The default
+is 8.
+@item init-retries
+The number of times to retry one phase of the initialization sequence
+(there are three phases).  The default is 4.
+@item init-timeout
+The timeout in seconds for one phase of the initialization sequence.  The
+default is 10.
+@item retries
+The number of times to retry sending either a data packet or a request
+for the next packet.  The default is 6.
+@item timeout
+The timeout in seconds when waiting for either a data packet or an
+acknowledgement.  The default is 10.
+@item garbage
+The number of unrecognized bytes to permit before dropping the
+connection.  This must be larger than the packet size.  The default is
+10000.
+@item errors
+The number of errors (malformed packets, out of order packets, bad
+checksums, or packets rejected by the remote system) to permit before
+dropping the connection.  The default is 100.
+@item error-decay
+The rate at which to ignore errors.  Each time this many packets are
+received, the error count is decreased by one, so that a long connection
+with an occasional error will not exceed the limit set by @code{errors}.
+The default is 10.
+@item remote-window
+If this is between 1 and 7 inclusive, the window size requested by the
+remote system is ignored and this is used instead.  This can be useful
+when dealing with some poor UUCP packages.  The default is 0, which
+means that the remote system's request is honored.
+@item remote-packet-size
+If this is between 32 and 4096 inclusive the packet size requested by
+the remote system is ignored and this is used instead.  There is
+probably no good reason to use this.  The default is 0, which means that
+the remote system's request is honored.
+@item short-packets
+If this is true, then the code will optimize by sending shorter packets
+when there is less data to send.  This confuses some UUCP packages, such
+as System V Release 4 (when using the @samp{G} protocol) and Waffle;
+when connecting to such a package, this parameter must be set to false.
+The default is true for the @samp{g} and @samp{v} protocols and false
+for the @samp{G} protocol.
+@end table
+
+The @samp{a} protocol is a Zmodem like protocol contributed by Doug
+Evans.  It supports the following commands, all of which take numeric
+arguments except for @code{escape-control}, which takes a boolean
+argument:
+
+@table @code
+@item timeout
+Number of seconds to wait for a packet to arrive.  The default is 10.
+@item retries
+The number of times to retry sending a packet.  The default is 10.
+@item startup-retries
+The number of times to retry sending the initialization packet.  The
+default is 4.
+@item garbage
+The number of garbage characters to accept before closing the
+connection.  The default is 2400.
+@item send-window
+The number of characters that may be sent before waiting for an
+acknowledgement.  The default is 1024.
+@item escape-control
+Whether to escape control characters.  If this is true, the protocol may
+be used over a connection which does not transmit certain control
+characters, such as @code{XON} or @code{XOFF}.  The connection must
+still transmit eight bit characters other than control characters.  The
+default is false.
+@end table
+
+The @samp{j} protocol can be used over an eight bit connection that will
+not transmit certain control characters.  It accepts the same protocol
+parameters that the @samp{i} protocol accepts, as well as one more:
+
+@table @code
+@item avoid
+A list of characters to avoid.  This is a string which is interpreted as
+an escape sequence (@pxref{Chat Scripts}).  The protocol does not have a
+way to avoid printable ASCII characters (byte values from 32 to 126,
+inclusive); only ASCII control characters and eight-bit characters may
+be avoided.  The default value is @samp{\021\023}; these are the
+characters @code{XON} and @code{XOFF}, which many connections use for
+flow control.  If the package is configured to use @code{HAVE_BSD_TTY},
+then on some versions of Unix you may have to avoid @samp{\377} as well,
+due to the way some implementations of the BSD terminal driver handle
+signals.
+@end table
+
+The @samp{f} protocol is intended for use with error-correcting modems
+only; it checksums each file as a whole, so any error causes the entire
+file to be retransmitted.  It supports the following commands, both of
+which take numeric arguments:
+
+@table @code
+@item timeout
+The timeout in seconds before giving up.  The default is 120.
+@item retries
+How many times to retry sending a file.  The default is 2.
+@end table
+
+The @samp{t} and @samp{e} protocols are intended for use over TCP or
+some other communication path with end to end reliability, as they do no
+checking of the data at all.  They both support a single command, which
+takes a numeric argument:
+
+@table @code
+@item timeout
+The timeout in seconds before giving up.  The default is 120.
+@end table
+
+The @samp{y} protocol is a streaming protocol contributed by Jorge Cwik.
+It supports the following commands, both of which take numeric
+arguments:
+
+@table @code
+@item timeout
+The timeout in seconds when waiting for a packet.  The default is 60.
+@item packet-size
+The packet size to use.  The default is 1024.
+@end table
+
+The protocol parameters are reset to their default values after each
+call.
+
+@end table
+
+@node File Transfer Control, Miscellaneous (sys), Protocol Selection, sys File
+@subsection File Transfer Control
+
+@table @code
+
+@item send-request @var{boolean}
+@findex send-request
+
+The @var{boolean} determines whether the remote system is permitted to
+request files from the local system.  The default is yes.
+
+@item receive-request @var{boolean}
+@findex receive-request
+
+The @var{boolean} determines whether the remote system is permitted to
+send files to the local system.  The default is yes.
+
+@item request @var{boolean}
+@findex request
+
+A shorthand command, equivalent to specifying both @samp{send-request
+@var{boolean}} and @samp{receive-request @var{boolean}}.
+
+@item call-transfer @var{boolean}
+@findex call-transfer
+
+The @var{boolean} is checked when the local system places the call.  It
+determines whether the local system may do file transfers queued up for
+the remote system.  The default is yes.
+
+@item called-transfer @var{boolean}
+@findex called-transfer
+
+The @var{boolean} is checked when the remote system calls in.  It
+determines whether the local system may do file transfers queued up for
+the remote system.  The default is yes.
+
+@item transfer @var{boolean}
+@findex transfer
+
+A shorthand command, equivalent to specifying both @samp{call-transfer
+@var{boolean}} and @samp{called-transfer @var{boolean}}.
+
+@item call-local-size @var{number} @var{string}
+@findex call-local-size
+
+The @var{string} is a time string (@pxref{Time Strings}).  The
+@var{number} is the size in bytes of the largest file that should be
+transferred at a time matching the time string, if the local system
+placed the call and the request was made by the local system.  This
+command may appear multiple times in a single alternate.  If this
+command does not appear, or if none of the time strings match, there are
+no size restrictions.
+
+With all the size control commands, the size of a file from the remote
+system (as opposed to a file from the local system) will only be checked
+if the other system is running this package: other UUCP packages will
+not understand a maximum size request, nor will they provide the size of
+remote files.
+
+@item call-remote-size @var{number} @var{string}
+@findex call-remote-size
+
+Specify the size in bytes of the largest file that should be transferred
+at a given time by remote request, when the local system placed the
+call.  This command may appear multiple times in a single alternate.  If
+this command does not appear, there are no size restrictions.
+
+@item called-local-size @var{number} @var{string}
+@findex called-local-size
+
+Specify the size in bytes of the largest file that should be transferred
+at a given time by local request, when the remote system placed the
+call.  This command may appear multiple times in a single alternate. If
+this command does not appear, there are no size restrictions.
+
+@item called-remote-size @var{number} @var{string}
+@findex called-remote-size
+
+Specify the size in bytes of the largest file that should be transferred
+at a given time by remote request, when the remote system placed the
+call.  This command may appear multiple times in a single alternate. If
+this command does not appear, there are no size restrictions.
+
+@item local-send @var{strings}
+@findex local-send
+
+Specifies that files in the directories named by the @var{strings} may
+be sent to the remote system when requested locally (using @code{uucp}
+or @code{uux}).  The directories in the list should be separated by
+whitespace.  A @samp{~} may be used for the public directory.  On a Unix
+system, this is typically @file{/usr/spool/uucppublic}; the public
+directory may be set with the @code{pubdir} command.  Here is an example
+of @code{local-send}:
+
+@example
+local-send ~ /usr/spool/ftp/pub
+@end example
+
+Listing a directory allows all files within the directory and all
+subdirectories to be sent.  Directories may be excluded by preceding
+them with an exclamation point.  For example:
+
+@example
+local-send /usr/ftp !/usr/ftp/private ~
+@end example
+
+@noindent
+means that all files in @file{/usr/ftp} or the public directory may be
+sent, except those files in @file{/usr/ftp/private}.  The list of
+directories is read from left to right, and the last directory to apply
+takes effect; this means that directories should be listed from top
+down.  The default is the root directory (i.e., any file at all may be
+sent by local request).
+
+@item remote-send @var{strings}
+@findex remote-send
+
+Specifies that files in the named directories may be sent to the remote
+system when requested by the remote system.  The default is @samp{~}.
+
+@item local-receive @var{strings}
+@findex local-receive
+
+Specifies that files may be received into the named directories when
+requested by a local user.  The default is @samp{~}.
+
+@item remote-receive @var{strings}
+@findex remote-receive
+
+Specifies that files may be received into the named directories when
+requested by the remote system.  The default is @samp{~}.  On Unix, the
+remote system may only request that files be received into directories
+that are writeable by the world, regardless of how this is set.
+
+@item forward-to @var{strings}
+@findex forward-to
+
+Specifies a list of systems to which files may be forwarded.  The remote
+system may forward files through the local system on to any of the
+systems in this list.  The string @samp{ANY} may be used to permit
+forwarding to any system.  The default is to not permit forwarding to
+other systems.  Note that if the remote system is permitted to execute
+the @code{uucp} command, it effectively has the ability to forward to
+any system.
+
+@item forward-from @var{strings}
+@findex forward-from
+
+Specifies a list of systems from which files may be forwarded.  The
+remote system may request files via the local system from any of the
+systems in this list.  The string @samp{ANY} may be used to permit
+forwarding to any system.  The default is to not permit forwarding from
+other systems.  Note that if a remote system is permitted to execute the
+@code{uucp} command, it effectively has the ability to request files
+from any system.
+
+@item forward @var{strings}
+@findex forward
+
+Equivalent to specifying both @samp{forward-to @var{strings}} and
+@samp{forward-from @var{strings}}.  This would normally be used rather
+than either of the more specific commands.
+
+@end table
+
+@node Miscellaneous (sys), Default sys File Values, File Transfer Control, sys File
+@subsection Miscellaneous sys File Commands
+
+@table @code
+
+@item sequence @var{boolean}
+@findex sequence
+
+If @var{boolean} is true, then conversation sequencing is automatically
+used for the remote system, so that if somebody manages to spoof as the
+remote system, it will be detected the next time the remote system
+actually calls.  This is false by default.
+
+@item command-path @var{strings}
+@findex command-path
+
+Specifies the path (a list of whitespace separated directories) to be
+searched to locate commands to execute.  This is only used for commands
+requested by @code{uux}, not for chat programs.  The default is from
+@file{policy.h}.
+
+@item commands @var{strings}
+@findex commands
+
+The list of commands which the remote system is permitted to execute
+locally.  For example: @samp{commands rnews rmail}.  If the value is
+@samp{ALL} (case significant), all commands may be executed.  The
+default is @samp{rnews rmail}.
+
+@item free-space @var{number}
+@findex free-space
+
+Specify the minimum amount of file system space (in bytes) to leave free
+after receiving a file.  If the incoming file will not fit, it will be
+rejected.  This initial rejection will only work when talking to another
+instance of this package, since older UUCP packages do not provide the
+file size of incoming files.  Also, while a file is being received,
+@code{uucico} will periodically check the amount of free space.  If it
+drops below the amount given by the @code{free-space} command, the file
+transfer will be aborted.  The default amount of space to leave free is
+from @file{policy.h}.  This file space checking may not work on all
+systems.
+
+@item pubdir @var{string}
+@findex pubdir in sys file
+
+Specifies the public directory that is used when @samp{~} is specifed in
+a file transfer or a list of directories.  This essentially overrides
+the public directory specified in the main configuration file for this
+system only.  The default is the public directory specified in the main
+configuration file (which defaults to a value from @file{policy.h}).
+
+@item debug @var{string} @dots{}
+@findex debug in sys file
+
+Set additional debugging for calls to or from the system.  This may be
+used to debug a connection with a specific system.  It is particularly
+useful when debugging incoming calls, since debugging information will
+be generated whenever the call comes in.  See the @code{debug} command
+in the main configuration file (@pxref{Debugging Levels}) for more
+details.  The debugging information specified here is in addition to
+that specified in the main configuration file or on the command line.
+
+@item max-remote-debug @var{string} @dots{}
+@findex max-remote-debug
+
+When the system calls in, it may request that the debugging level be set
+to a certain value.  The @code{max-remote-debug} command may be used to
+put a limit on the debugging level which the system may request, to
+avoid filling up the disk with debugging information.  Only the
+debugging types named in the @code{max-remote-debug} command may be
+turned on by the remote system.  To prohibit any debugging, use
+@samp{max-remote-debug none}.
+
+@end table
+
+@node Default sys File Values,  , Miscellaneous (sys), sys File
+@subsection Default sys File Values
+
+The following are used as default values for all systems; they can be
+considered as appearing before the start of the file.
+
+@example
+time Never
+chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
+chat-timeout 10
+callback n
+sequence n
+request y
+transfer y
+local-send /
+remote-send ~
+local-receive ~
+remove-receive ~
+command-path [ from @file{policy.h} ]
+commands rnews rmail
+max-remote-debug abnormal,chat,handshake
+@end example
+
+@node port File, dial File, sys File, Configuration Files
+@section The Port Configuration File
+@cindex port file
+@cindex port configuration file
+@cindex configuration file (port)
+
+The port files may be used to name and describe ports.  By default there
+is a single port file, named @file{port} in the directory
+@var{newconfigdir}.  This may be overridden by the @code{portfile}
+command in the main configuration file; see @ref{Configuration File
+Names}.
+
+Any commands in a port file before the first @code{port} command specify
+defaults for all ports in the file; however, since the @code{type}
+command must appear before all other commands for a port, the defaults
+are only useful if all ports in the file are of the same type (this
+restriction may be lifted in a later version).  All commands after a
+@code{port} command up to the next @code{port} command then describe
+that port.  There are different types of ports; each type supports its
+own set of commands.  Each command indicates which types of ports
+support it.  There may be many ports with the same name; if a system
+requests a port by name then each port with that name will be tried
+until an unlocked one is found.
+
+@table @code
+
+@item port @var{string}
+@findex port in port file
+
+Introduces and names a port.
+
+@item type @var{string}
+@findex type
+
+Define the type of port.  The default is @samp{modem}.  If this command
+appears, it must immediately follow the @code{port} command.  The type defines
+what commands are subsequently allowed.  Currently the types are:
+
+@table @samp
+@item modem
+For a modem hookup.
+@item stdin
+For a connection through standard input and standard output, as when
+@code{uucico} is run as a login shell.
+@item direct
+For a direct connection to another system.
+@item tcp
+For a connection using TCP.
+@item tli
+For a connection using TLI.
+@item pipe
+For a connection through a pipe running another program.
+@end table
+
+@item protocol @var{string}
+@findex protocol in port file
+
+Specify a list of protocols to use for this port.  This is just like the
+corresponding command for a system (@pxref{Protocol Selection}).  A
+protocol list for a system takes precedence over a list for a port.
+
+@item protocol-parameter @var{character} @var{strings} [ any type ]
+@findex protocol-parameter in port file
+
+The same command as the @code{protocol-parameter} command used for
+systems (@pxref{Protocol Selection}).  This one takes precedence.
+
+@item seven-bit @var{boolean} [ any type ]
+@findex seven-bit in port file
+
+This is only used during protocol negotiation; if the argument is true,
+it forces the selection of a protocol which works across a seven-bit
+link.  It does not prevent eight bit characters from being transmitted.
+The default is false.
+
+@item reliable @var{boolean} [ any type ]
+@findex reliable in port file
+
+This is only used during protocol negotiation; if the argument is
+false, it forces the selection of a protocol which works across
+an unreliable communication link.  The default is true.  It would
+be more common to specify this for a dialer rather than a port.
+
+@item half-duplex @var{boolean} [ any type ]
+@findex half-duplex in port file
+
+If the argument is true, it means that the port only supports
+half-duplex connections.  This only affects bidirectional protocols, and
+causes them to not do bidirectional transfers.
+
+@item device @var{string} [ modem, direct and tli only ]
+@findex device
+
+Names the device associated with this port.  If the device is not named,
+the port name is taken as the device.  Device names are system
+dependent.  On Unix, a modem or direct connection might be something
+like @file{/dev/ttyd0}; a TLI port might be @file{/dev/inet/tcp}.
+
+@itemx speed @var{number} [modem and direct only ]
+@findex speed in port file
+@item baud @var{number} [ modem and direct only ]
+@findex baud in port file
+
+The speed this port runs at.  If a system specifies a speed but no port
+name, then all ports which match the speed will be tried in order.  If
+the speed is not specified here and is not specified by the system, the
+natural speed of the port will be used by default.
+
+@itemx speed-range @var{number} @var{number} [ modem only ]
+@findex speed-range
+@item baud-range @var{number} @var{number} [ modem only ]
+@findex baud-range
+
+Specify a range of speeds this port can run at.  The first number is the
+minimum speed, the second number is the maximum speed.  These numbers
+will be used when matching a system which specifies a desired speed.
+The simple @code{speed} (or @code{baud}) command is still used to
+determine the speed to run at if the system does not specify a speed.
+For example, the command @samp{speed-range 300 19200} means that the
+port will match any system which uses a speed from 300 to 19200 baud
+(and will use the speed specified by the system); this could be combined
+with @samp{speed 2400}, which means that when this port is used with a
+system that does not specify a speed, the port will be used at 2400
+baud.
+
+@item carrier @var{boolean} [ modem and direct only ]
+@findex carrier in port file
+
+The argument indicates whether the port supports carrier.  
+
+If a modem port does not support carrier, the carrier detect signal will
+never be required on this port, regardless of what the modem chat script
+indicates.  The default for a modem port is true.
+
+If a direct port supports carrier, the port will be set to expect
+carrier whenever it is used.  The default for a direct port is false.
+
+@item hardflow @var{boolean} [ modem and direct only ]
+@findex hardflow
+
+The argument indicates whether the port supports hardware flow control.
+If it does not, hardware flow control will not be turned on for this
+port.  The default is true.  Hardware flow control is only supported on
+some systems.
+
+@item dial-device @var{string} [ modem only ]
+@findex dial-device
+
+Dialing instructions should be output to the named device, rather than
+to the normal port device.  The default is to output to the normal port
+device.
+
+@item dialer @var{string} [ modem only ]
+@findex dialer in port file
+
+Name a dialer to use.  The information is looked up in the dial file.
+There is no default.  Some sort of dialer information must be specified
+to call out on a modem.
+
+@item dialer @var{string} @dots{} [ modem only ]
+
+If more than one string follows the @code{dialer} command, the strings
+are treated as a command that might appear in the dial file (@pxref{dial
+File}).  If a dialer is named (by using the first form of this command,
+described just above), these commands are ignored.  They may be used to
+specify dialer information directly in simple situations without needing
+to go to a separate file.  There is no default.  Some sort of dialer
+information must be specified to call out on a modem.
+
+@item dialer-sequence @var{strings} [ modem or tcp or tli only ]
+@findex dialer-sequence
+
+Name a sequence of dialers and tokens (phone numbers) to use.  The first
+argument names a dialer, and the second argument names a token.  The
+third argument names another dialer, and so on.  If there are an odd
+number of arguments, the phone number specified with a @code{phone}
+command in the system file is used as the final token.  The token is
+what is used for @kbd{\D} or @kbd{\T} in the dialer chat script.  If the
+token in this string is @kbd{\D}, the system phone number will be used;
+if it is @kbd{\T}, the system phone number will be used after undergoing
+dialcodes translation.  A missing final token is taken as @kbd{\D}.
+
+This command currently does not work if @code{dial-device} is specified;
+to handle this correctly will require a more systematic notion of chat
+scripts.  Moreover, the @code{complete} and @code{abort} chat scripts,
+the protocol parameters, and the @code{carrier} and @code{dtr-toggle}
+commands are ignored for all but the first dialer.
+
+This command basically lets you specify a sequence of chat scripts to
+use.  For example, the first dialer might get you to a local network and
+the second dialer might describe how to select a machine from the local
+network.  This lets you break your dialing sequence into simple modules,
+and may make it easier to share dialer entries between machines.
+
+This command is to only way to use a chat script with a TCP port.  This
+can be useful when using a modem which is accessed via TCP.
+
+When this command is used with a TLI port, then if the first dialer is
+@samp{TLI} or @samp{TLIS} the first token is used as the address to
+connect to.  If the first dialer is something else, or if there is no
+token, the address given by the @code{address} command is used
+(@pxref{Placing the Call}).  Escape sequences in the address are
+expanded as they are for chat script expect strings (@pxref{Chat
+Scripts}).  The different between @samp{TLI} and @samp{TLIS} is that the
+latter implies the command @samp{stream true}.  These contortions are
+all for HDB compatibility.  Any subsequent dialers are treated as they
+are for a TCP port.
+
+@item lockname @var{string} [ modem and direct only ]
+@findex lockname
+
+Give the name to use when locking this port.  On Unix, this is the name
+of the file that will be created in the lock directory.  It is used as
+is, so on Unix it should generally start with @samp{LCK..}.  For
+example, if a single port were named both @file{/dev/ttycu0} and
+@file{/dev/tty0} (perhaps with different characteristics keyed on the
+minor device number), then the command @code{lockname LCK..ttycu0} could
+be used to force the latter to use the same lock file name as the
+former.
+
+@item service @var{string} [ tcp only ]
+@findex service
+
+Name the TCP port number to use.  This may be a number.  If not, it will
+be looked up in @file{/etc/services}.  If this is not specified, the
+string @samp{uucp} is looked up in @file{/etc/services}.  If it is not
+found, port number 540 (the standard UUCP-over-TCP port number) will be
+used.
+
+@item push @var{strings} [ tli only ]
+@findex push
+
+Give a list of modules to push on to the TLI stream.
+
+@item stream @var{boolean} [ tli only ]
+@findex stream
+
+If this is true, and the @code{push} command was not used, the
+@samp{tirdwr} module is pushed on to the TLI stream.
+
+@item server-address @var{string} [ tli only ]
+@findex server-address
+
+Give the address to use when running as a TLI server.  Escape sequences
+in the address are expanded as they are for chat script expect strings
+(@pxref{Chat Scripts}).
+
+The string is passed directly to the TLI @code{t_bind} function.  The
+value needed may depend upon your particular TLI implementation.  Check
+the manual pages, and, if necessary, try writing some sample programs.
+
+For AT&T 3B2 System V Release 3 using the Wollongong TCP/IP stack, which
+is probably typical, the format of TLI string is @samp{SSPPIIII}, where
+@samp{SS} is the service number (for TCP, this is 2), @samp{PP} is the
+TCP port number, and @samp{IIII} is the Internet address.  For example,
+to accept a connection from on port 540 from any interface, use
+@samp{server-address \x00\x02\x02\x1c\x00\x00\x00\x00}.  To only accept
+connections from a particular interface, replace the last four digits
+with the network address of the interface.  (Thanks to Paul Pryor for
+the information in this paragraph).
+
+@item command @var{strings} [ pipe only ]
+@findex command
+
+Give the command, with arguments, to run when using a pipe port type.
+When a port of this type is used, the command is executed and
+@code{uucico} communicates with it over a pipe.  This permits
+@code{uucico} or @code{cu} to communicate with another system which can
+only be reached through some unusual means.  A sample use might be
+@samp{command /bin/rlogin -E -8 -l @var{login} @var{system}}.  The
+command is run with the full privileges of UUCP; it is responsible for
+maintaining security.
+
+@end table
+
+@node dial File, UUCP Over TCP, port File, Configuration Files
+@section The Dialer Configuration File
+@cindex dial file
+@cindex dialer configuration file
+@cindex configuration file (dial)
+
+The dialer configuration files define dialers.  By default there is a
+single dialer file, named @file{dial} in the directory
+@var{newconfigdir}.  This may be overridden by the @code{dialfile}
+command in the main configuration file; see @ref{Configuration File
+Names}.
+
+Any commands in the file before the first @code{dialer} command specify
+defaults for all the dialers in the file.  All commands after a
+@code{dialer} command up to the next @code{dialer} command are
+associated with the named dialer.
+
+@table @code
+
+@item dialer @var{string}
+@findex dialer in dial file
+
+Introduces and names a dialer.
+
+@item chat @var{strings}
+@findex chat in dial file
+@item chat-timeout @var{number}
+@findex chat-timeout in dial file
+@item chat-fail @var{string}
+@findex chat-fail in dial file
+@item chat-seven-bit @var{boolean}
+@findex chat-seven-bit in dial file
+@item chat-program @var{strings}
+@findex chat-program in dial file
+
+Specify a chat script to be used to dial the phone.  This chat script is
+used before the login chat script in the @file{sys} file, if any
+(@pxref{Logging In}).  For full details on chat scripts, see @ref{Chat
+Scripts}.
+
+The @code{uucico} daemon will sleep for one second between attempts to
+dial out on a modem.  If your modem requires a longer wait period, you
+must start your chat script with delays (@samp{\d} in a send string).
+
+The chat script will be read from and sent to the port specified by the
+@code{dial-device} command for the port, if there is one.
+
+The following escape addition escape sequences may appear in send
+strings:
+
+@table @kbd
+@item \D
+send phone number without dialcode translation
+@item \T
+send phone number with dialcode translation
+@item \M
+do not require carrier
+@item \m
+require carrier (fail if not present)
+@end table
+
+See the description of the dialcodes file (@pxref{Configuration File
+Names}) for a description of dialcode translation.  If the port does not
+support carrier, as set by the @code{carrier} command in the port file,
+@kbd{\M} and @kbd{\m} are ignored.  If both the port and the dialer
+support carrier, as set by the @code{carrier} command in the port file
+and the @code{carrier} command in the dialer file, then every chat
+script implicitly begins with @kbd{\M} and ends with @kbd{\m}.  There is
+no default chat script for dialers.
+
+The following additional escape sequences may be used in
+@code{chat-program}:
+
+@table @kbd
+@item \D
+phone number without dialcode translation
+@item \T
+phone number with dialcode translation
+@end table
+
+If the program changes the port in any way (e.g., sets parity) the
+changes will be preserved during protocol negotiation, but once the
+protocol is selected it will change the port settings.
+
+@item dialtone @var{string}
+@findex dialtone
+
+A string to output when dialing the phone number which causes the modem
+to wait for a secondary dial tone.  This is used to translate the
+@kbd{=} character in a phone number.  The default is a comma.
+
+@item pause @var{string}
+@findex pause
+
+A string to output when dialing the phone number which causes the modem
+to wait for 1 second.  This is used to translate the @kbd{-} character
+in a phone number.  The default is a comma.
+
+@item carrier @var{boolean}
+@findex carrier in dial file
+
+An argument of true means that the dialer supports the modem carrier
+signal.  After the phone number is dialed, @code{uucico} will require
+that carrier be on.  One some systems, it will be able to wait for it.
+If the argument is false, carrier will not be required.  The default is
+true.
+
+@item carrier-wait @var{number}
+@findex carrier-wait
+
+If the port is supposed to wait for carrier, this may be used to
+indicate how many seconds to wait.  The default is 60 seconds.  Only
+some systems support waiting for carrier.
+
+@item dtr-toggle @var{boolean} @var{boolean}
+@findex dtr-toggle
+
+If the first argument is true, then DTR is toggled before using
+the modem.  This is only supported on some systems and some ports.  The
+second @var{boolean} need not be present; if it is, and it is
+true, the program will sleep for 1 second after toggling DTR.
+The default is to not toggle DTR.
+
+@need 500
+@item complete-chat @var{strings}
+@findex complete-chat
+@item complete-chat-timeout @var{number}
+@findex complete-chat-timeout
+@item complete-chat-fail @var{string}
+@findex complete-chat-fail
+@item complete-chat-seven-bit @var{boolean}
+@findex complete-chat-seven-bit
+@item complete-chat-program @var{strings}
+@findex complete-chat-program
+
+These commands define a chat script (@pxref{Chat Scripts}) which is run
+when a call is finished normally.  This allows the modem to be reset.
+There is no default.  No additional escape sequences may be used.
+
+@item complete @var{string}
+@findex complete
+
+This is a simple use of @code{complete-chat}.  It is equivalent to
+@code{complete-chat "" @var{string}}; this has the effect of sending
+@var{string} to the modem when a call finishes normally.
+
+@item abort-chat @var{strings}
+@findex abort-chat
+@item abort-chat-timeout @var{number}
+@findex abort-chat-timeout
+@item abort-chat-fail @var{string}
+@findex abort-chat-fail
+@item abort-chat-seven-bit @var{boolean}
+@findex abort-chat-seven-bit
+@item abort-chat-program @var{strings}
+@findex abort-chat-program
+
+These commands define a chat script (@pxref{Chat Scripts}) to be run
+when a call is aborted.  They may be used to interrupt and reset the
+modem.  There is no default.  No additional escape sequences may be
+used.
+
+@item abort @var{string}
+@findex abort
+
+This is a simple use of @code{abort-chat}.  It is equivalent to
+@code{abort-chat "" @var{string}}; this has the effect of sending
+@var{string} to the modem when a call is aborted.
+
+@item protocol-parameter @var{character} @var{strings}
+@findex protocol-parameter in dial file
+
+Set protocol parameters, just like the @code{protocol-parameter} command
+in the system configuration file or the port configuration file; see
+@ref{Protocol Selection}.  These parameters take precedence, then those
+for the port, then those for the system.
+
+@item seven-bit @var{boolean}
+@findex seven-bit in dial file
+
+This is only used during protocol negotiation; if it is true, it
+forces selection of a protocol which works across a seven-bit link.  It
+does not prevent eight bit characters from being transmitted.  The
+default is false.  It would be more common to specify this for a
+port than for a dialer.
+
+@item reliable @var{boolean}
+@findex reliable in dial file
+
+This is only used during protocol negotiation; if it is false, it
+forces selection of a protocol which works across an unreliable
+communication link.  The default is true.
+
+@item half-duplex @var{boolean} [ any type ]
+@findex half-duplex in dial file
+
+If the argument is true, it means that the dialer only supports
+half-duplex connections.  This only affects bidirectional protocols, and
+causes them to not do bidirectional transfers.
+
+@end table
+
+@node UUCP Over TCP, Security, dial File, Configuration Files
+@section UUCP Over TCP
+
+If your system has a Berkeley style socket library, or a System V style
+TLI interface library, you can compile the code to permit making
+connections over TCP.  Specifying that a system should be reached via
+TCP is easy, but nonobvious.
+
+@menu
+* TCP Client::                  Connecting to Another System Over TCP
+* TCP Server::                  Running a TCP Server
+@end menu
+
+@node TCP Client, TCP Server, UUCP Over TCP, UUCP Over TCP
+@subsection Connecting to Another System Over TCP
+
+If you are using the new style configuration files (@pxref{Configuration
+Files}), add the line @samp{port type tcp} to the entry in the
+@file{sys} file.  By default UUCP will get the port number by looking up
+@samp{uucp} in @file{/etc/services}; if the @samp{uucp} service is not
+defined, port 540 will be used.  You can set the port number to use with
+the command @samp{port service @var{xxx}}, where @var{xxx} can be either
+a number or a name to look up in @file{/etc/services}.  You can specify
+the address of the remote host with @samp{address @var{a.b.c}}; if you
+don't give an address, the remote system name will be used.  You should
+give an explicit chat script for the system when you use TCP; the
+default chat script begins with a carriage return, which will not work
+with some UUCP TCP servers.
+
+If you are using V2 configuration files, add a line like this to
+@file{L.sys}:
+@example
+@var{sys} Any TCP uucp @var{host}.@var{domain} chat-script
+@end example
+This will make an entry for system @var{sys}, to be called at any time,
+over TCP, using port number @samp{uucp} (as found in
+@file{/etc/services}; this may be specified as a number), using remote
+host @file{@var{host}.@var{domain}}, with some chat script.
+
+If you are using HDB configuration files, add a line like this to
+Systems:
+@example
+@var{sys} Any TCP - @var{host}.@var{domain} chat-script
+@end example
+and a line like this to @file{Devices}:
+@example
+TCP uucp - -
+@end example
+You only need one line in @file{Devices} regardless of how many systems
+you contact over TCP.  This will make an entry for system @var{sys}, to
+be called at any time, over TCP, using port number @samp{uucp} (as found
+in @file{/etc/services}; this may be specified as a number), using
+remote host @file{@var{host}.@var{domain}}, with some chat script.
+
+@node TCP Server,  , TCP Client, UUCP Over TCP
+@subsection Running a TCP Server
+
+The @code{uucico} daemon may be run as a TCP server.  To use the default
+port number, which is a reserved port, @code{uucico} must be invoked by
+the superuser (or it must be set user ID to the superuser, but I don't
+recommend doing that).
+
+You must define a port, either using the port file (@pxref{port File}),
+if you are using the new configuration method, or with an entry in
+@file{Devices} if you are using HDB; there is no way to define a port
+using V2.  If you are using HDB the port must be named @samp{TCP}; a
+line as shown above will suffice.  You can then start @code{uucico} as
+@samp{uucico -p TCP} (after the @samp{-p}, name the port; in HDB it must
+be @samp{TCP}).  This will wait for incoming connections, and fork off a
+child for each one.  Each connection will be prompted with @samp{login:}
+and @samp{Password:}; the results will be checked against the UUCP (not
+the system) password file (@pxref{Configuration File Names}).
+
+Another way to run a UUCP TCP server is to use the BSD @code{uucpd}
+program.
+
+Yet another way to run a UUCP TCP server is to use @code{inetd}.
+Arrange for @code{inetd} to start up @code{uucico} with the @samp{-l}
+switch.  This will cause @code{uucico} to prompt with @samp{login:} and
+@samp{Password:} and check the results against the UUCP (not the system)
+password file (you may want to also use the @samp{-D} switch to avoid a
+fork, which in this case is unnecessary).
+
+@node Security,  , UUCP Over TCP, Configuration Files
+@section Security
+
+This discussion of UUCP security applies only to Unix.  It is a bit
+cursory; suggestions for improvement are solicited.
+
+UUCP is traditionally not very secure.  Taylor UUCP addresses some
+security issues, but is still far from being a secure system.
+
+If security is very important to you, then you should not permit any
+external access to your computer, including UUCP.  Any opening to the
+outside world is a potential security risk.
+
+When local users use UUCP to transfer files, Taylor UUCP can do little
+to secure them from each other.  You can allow somewhat increased
+security by putting the owner of the UUCP programs (normally
+@code{uucp}) into a separate group; the use of this is explained in the
+following paragraphs, which refer to this separate group as
+@code{uucp-group}.
+
+When the @code{uucp} program is invoked to copy a file to a remote
+system, it will, by default, copy the file into the UUCP spool
+directory.  When the @code{uux} program is used, the @samp{-C} switch
+must be used to copy the file into the UUCP spool directory.  In any
+case, once the file has been copied into the spool directory, other
+local users will not be able to access it.
+
+When a file is requested from a remote system, UUCP will only permit it
+to be placed in a directory which is writable by the requesting user.
+The directory must also be writable by UUCP.  A local user can create a
+directory with a group of @code{uucp-group} and set the mode to permit
+group write access.  This will allow the file be requested without
+permitting it to be viewed by any other user.
+
+There is no provision for security for @code{uucp} requests (as opposed
+to @code{uux} requests) made by a user on a remote system.  A file sent
+over by a remote request may only be placed in a directory which is
+world writable, and the file will be world readable and writable.  This
+will permit any local user to destroy or replace the contents of the
+file.  A file requested by a remote system must be world readable, and
+the directory it is in must be world readable.  Any local user will be
+able to examine, although not necessarily modify, the file before it is
+sent.
+
+There are some security holes and race conditions that apply to the
+above discussion which I will not elaborate on.  They are not hidden
+from anybody who reads the source code, but they are somewhat technical
+and difficult (though scarcely impossible) to exploit.  Suffice it to
+say that even under the best of conditions UUCP is not completely
+secure.
+
+For many sites, security from remote sites is a more important
+consideration.  Fortunately, Taylor UUCP does provide some support in
+this area.
+
+The greatest security is provided by always dialing out to the other
+site.  This prevents anybody from pretending to be the other site.  Of
+course, only one side of the connection can do this.
+
+If remote dialins must be permitted, then it is best if the dialin line
+is used only for UUCP.  If this is the case, then you should create a
+call-in password file (@pxref{Configuration File Names}) and let
+@code{uucico} do its own login prompting.  For example, to let remote
+sites log in on a port named @samp{entry} in the port file (@pxref{port
+File}), you might invoke @samp{uucico -e -p entry}.  This would cause
+@code{uucico} to enter an endless loop of login prompts and daemon
+executions.  The advantage of this approach is that even if remote users
+break into the system by guessing or learning the password, they will
+only be able to do whatever @code{uucico} permits them to do.  They will
+not be able to start a shell on your system.
+
+If remote users can dial in and log on to your system, then you have a
+security hazard more serious than that posed by UUCP.  But then, you
+probably knew that already.
+
+Once your system has connected with the remote UUCP, there is a fair
+amount of control you can exercise.  You can use the @code{remote-send}
+and @code{remote-receive} commands to control the directories the remote
+UUCP can access.  You can use the @code{request} command to prevent the
+remote UUCP from making any requests of your system at all; however, if
+you do this it will not even be able to send you mail or news.  If you
+do permit remote requests, you should be careful to restrict what
+commands may be executed at the remote system's request.  The default is
+@code{rmail} and @code{rnews}, which will suffice for most systems.
+
+If different remote systems call in and they must be granted different
+privileges (perhaps some systems are within the same organization and
+some are not) then the @code{called-login} command should be used for
+each system to require that they use different login names.  Otherwise,
+it would be simple for a remote system to use the @code{myname} command
+and pretend to be a different system.  The @code{sequence} command can
+be used to detect when one system pretended to be another, but, since
+the sequence numbers must be reset manually after a failed handshake,
+this can sometimes be more trouble than it's worth.
+
+@c START-OF-FAQ
+@ignore
+This chapter is used to generate the comp.mail.uucp UUCP Internals FAQ,
+as well as being part of the Taylor UUCP manual.  Text that should
+appear only in the manual is bracketed by ifclear faq.  Text that should
+appear only in the FAQ is bracketed by ifset faq.
+@end ignore
+
+@ifset faq
+@paragraphindent asis
+@format
+Subject: UUCP Internals Frequently Asked Questions
+Newsgroups: comp.mail.uucp,comp.answers,news.answers
+Followup-To: comp.mail.uucp
+Reply-To: ian@@airs.com (Ian Lance Taylor)
+Keywords: UUCP, protocol, FAQ
+Approved: news-answers-request@@MIT.Edu
+
+Archive-name: uucp-internals
+Version: $Revision: 1.1 $
+Last-modified: $Date: 2000/12/21 13:44:25 $
+@end format
+@end ifset
+
+@node Protocols, Hacking, Configuration Files, Top
+@chapter UUCP Protocol Internals
+
+@ifclear faq
+This chapter describes how the various UUCP protocols work, and
+discusses some other internal UUCP issues.
+
+This chapter is quite technical.  You do not need to understand it, or
+even read it, in order to use Taylor UUCP.  It is intended for people
+who are interested in how the UUCP code works.
+
+The information in this chapter is posted monthly to the Usenet
+newsgroups @samp{comp.mail.uucp}, @samp{news.answers}, and
+@samp{comp.answers}.  The posting is available from any
+@samp{news.answers} archive site, such as @samp{rtfm.mit.edu}.  If you
+plan to use this information to write a UUCP program, please make sure
+you get the most recent version of the posting, in case there have been
+any corrections.
+@end ifclear
+
+@ifset faq
+Recent changes:
+@itemize @bullet
+@item Conversion to Texinfo format.
+@item Description of the @samp{E} command.
+@item Description of optional number following @samp{-N} and @samp{ROKN}
+in UUCP protocol startup.
+@item Detailed description of the @samp{y} protocol.
+@item Mention the name uuxqt uses for lock files.
+@end itemize
+
+This article was written by Ian Lance Taylor @samp{<ian@@airs.com>} and
+I may even update it periodically.  Please send me mail about
+suggestions or inaccuracies.
+
+This article describes how the various UUCP protocols work, and
+discusses some other internal UUCP issues.  It does not describe how to
+configure UUCP, nor how to solve UUCP connection problems, nor how to
+deal with UUCP mail.  I do not know of any FAQ postings on these topics.
+There are some documents on the net describing UUCP configuration, but I
+can not keep an up to date list here; try using archie.
+
+If you haven't read the @samp{news.announce.newusers} articles, read
+them.
+
+This article is in digest format.  Some newsreaders will be able to
+break it apart into separate articles.  Please don't ask me how to do
+this, though.
+
+This article covers the following topics.  If questions about one of
+these topics is posted to @samp{comp.mail.uucp}, please send mail to the
+poster referring her or him to this FAQ.  There is no reason to post a
+followup, as most of us know the answer already.
+@end ifset
+
+@menu
+* UUCP Protocol Sources::       Sources for UUCP Protocol Information
+* UUCP Grades::                 UUCP Grades
+* UUCP Lock Files::             UUCP Lock Files
+* Execution File Format::       Execution File Format
+* UUCP Protocol::               UUCP Protocol
+* g Protocol::                  g protocol
+* f Protocol::                  f protocol
+* t Protocol::                  t protocol
+* e Protocol::                  e protocol
+* Big G Protocol::              G protocol
+* i Protocol::                  i protocol
+* j Protocol::                  j protocol
+* x Protocol::                  x protocol
+* y Protocol::                  y protocol
+* d Protocol::                  d protocol
+* h Protocol::                  h protocol
+* v Protocol::                  v protocol
+@end menu
+
+@ifset faq
+@format
+UUCP Protocol Sources
+Alarm in Debugging Output
+UUCP Grades
+UUCP Lock Files
+Execution File Format
+UUCP Protocol
+UUCP @samp{g} Protocol
+UUCP @samp{f} Protocol
+UUCP @samp{t} Protocol
+UUCP @samp{e} Protocol
+UUCP @samp{G} Protocol
+UUCP @samp{i} Protocol
+UUCP @samp{j} Protocol
+UUCP @samp{x} Protocol
+UUCP @samp{y} Protocol
+UUCP @samp{d} Protocol
+UUCP @samp{h} Protocol
+UUCP @samp{v} Protocol
+Thanks
+
+----------------------------------------------------------------------
+
+From: UUCP Protocol Sources
+Subject: UUCP Protocol Sources
+
+@end format
+@end ifset
+
+@node UUCP Protocol Sources, UUCP Grades, Protocols, Protocols
+@section UUCP Protocol Sources
+
+@quotation
+``Unix-to-Unix Copy Program,'' said PDP-1.  ``You will never find a more
+wretched hive of bugs and flamers.  We must be cautious.''
+@flushright
+---DECWars
+@end flushright
+@end quotation
+
+I took a lot of the information from Jamie E. Hanrahan's paper in the
+Fall 1990 DECUS Symposium, and from @cite{Managing UUCP and Usenet} by Tim
+O'Reilly and Grace Todino (with contributions by several other
+people).  The latter includes most of the former, and is published by
+@example
+O'Reilly & Associates, Inc.
+103 Morris Street, Suite A
+Sebastopol, CA 95472
+@end example
+It is currently in its tenth edition.  The ISBN number is
+@samp{0-937175-93-5}.
+
+Some information is originally due to a Usenet article by Chuck Wegrzyn.
+The information on execution files comes partially from Peter Honeyman.
+The information on the @samp{g} protocol comes partially from a paper by
+G.L.@: Chesson of Bell Laboratories, partially from Jamie E. Hanrahan's
+paper, and partially from source code by John Gilmore.  The information
+on the @samp{f} protocol comes from the source code by Piet Berteema.
+The information on the @samp{t} protocol comes from the source code by
+Rick Adams.  The information on the @samp{e} protocol comes from a
+Usenet article by Matthias Urlichs.  The information on the @samp{d}
+protocol comes from Jonathan Clark, who also supplied information about
+QFT.  The UUPlus information comes straight from Christopher J. Ambler,
+of UUPlus Development; it applies to version 1.52 and up of the
+shareware version of UUPlus Utilities, called FSUUCP 1.52, but referred
+to in this article as UUPlus.
+
+Although there are few books about UUCP, there are many about networks
+and protocols in general.  I recommend two non-technical books which
+describe the sorts of things that are available on the network:
+@cite{The Whole Internet}, by Ed Krol, and @cite{Zen and the Art of the
+Internet}, by Brendan P. Kehoe.  Good technical discussions of
+networking issues can be found in @cite{Internetworking with TCP/IP}, by
+Douglas E. Comer and David L. Stevens and in @cite{Design and Validation
+of Computer Protocols} by Gerard J. Holzmann.
+
+@ifset faq
+@c Note that this section is only in the FAQ, since it does not fit in
+@c here in the manual.
+@format
+------------------------------
+
+From: Alarm in Debugging Output
+Subject: Alarm in Debugging Output
+
+Alarm in Debugging Output
+=========================
+@end format
+
+The debugging output of many versions of UUCP will include messages like
+@samp{alarm 1} or @samp{pkcget: alarm 1}.  Taylor UUCP does not use the
+word @samp{alarm}, but will instead log messages like @samp{Timed out
+waiting for packet}.
+
+These types of messages mean that the UUCP package has timed out while
+waiting for some sort of response from the remote system.  If it happens
+consistently when trying to transfer a particular file, then the most
+likely problem is that one of the modems will not transmit the XON or
+XOFF characters.  Several UUCP protocols require an eight bit clean
+connection, which means that the modems must treat XON or XOFF as normal
+data characters, not as flow control signals.  This should always be
+checked first.
+
+Other possible problems are that the modems have simply dropped their
+connection, or perhaps on one side or the other the serial buffer is
+overflowing and dropping characters.  Another possibility is that the
+UUCP packages disagree about some aspect of the UUCP protocol, which is
+uncommon but does happen occasionally.
+
+Using the information in the following sections, you should be able to
+figure out what type of data your UUCP was expecting to receive.  This
+may give some indication as to exactly what the problem is.  It is
+difficult to be more specific, since there are many possiblities.
+
+@format
+------------------------------
+
+From: UUCP Grades
+Subject: UUCP Grades
+@end format
+@end ifset
+
+@node UUCP Grades, UUCP Lock Files, UUCP Protocol Sources, Protocols
+@section UUCP Grades
+@cindex grades implementation
+
+Modern UUCP packages support a priority grade for each command.  The
+grades generally range from @kbd{A} (the highest) to @kbd{Z} followed by
+@kbd{a} to @kbd{z}.  Some UUCP packages (including Taylor UUCP) also
+support @kbd{0} to @kbd{9} before @kbd{A}.  Some UUCP packages may
+permit any ASCII character as a grade.
+
+On Unix, these grades are encoded in the name of the command file
+created by @code{uucp} or @code{uux}.  A command file name generally has
+the form @file{C.nnnngssss} where @samp{nnnn} is the remote system name
+for which the command is queued, @samp{g} is a single character grade,
+and @samp{ssss} is a four character sequence number.  For example, a
+command file created for the system @samp{airs} at grade @samp{Z} might
+be named @file{C.airsZ2551}.
+
+The remote system name will be truncated to seven characters, to
+ensure that the command file name will fit in the 14 character file
+name limit of the traditional Unix file system.  UUCP packages which
+have no other means of distinguishing which command files are intended
+for which systems thus require all systems they connect to to have
+names that are unique in the first seven characters.  Some UUCP
+packages use a variant of this format which truncates the system name
+to six characters.  HDB and Taylor UUCP use a different spool
+directory format, which allows up to fourteen characters to be used
+for each system name.
+
+The sequence number in the command file name may be a decimal integer,
+or it may be a hexadecimal integer, or it may contain any alphanumeric
+character.  Different UUCP packages are different.
+@ifclear faq
+Taylor UUCP uses any alphanumeric character.
+@end ifclear
+
+UUPlus Utilities (as FSUUCP, a shareware DOS based UUCP and news
+package) uses up to 8 characters for file names in the spool (this is a
+DOS file system limitation; actually, with the extension, 11 characters
+are available, but FSUUCP reserves that for future use).  FSUUCP
+defaults mail to grade @samp{D}, and news to grade @samp{N}, except that
+when the grade of incoming mail can be determined, that grade is
+preserved if the mail is forwarded to another system. The default grades
+may be changed by editing the @file{LIB/MAILRC} file for mail, or the
+@file{UUPLUS.CFG} file for news.
+
+UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade
+@samp{C}, news at grade @samp{d}, and file transfers at grade @samp{n}.
+The UUPC/extended @code{UUCP} and @code{RMAIL} commands accept grades to
+override the default, the others do not.
+
+I do not know how command grades are handled in other non-Unix UUCP
+packages.
+
+Modern UUCP packages allow you to restrict file transfer by grade
+depending on the time of day.  Typically this is done with a line in
+the @file{Systems} (or @file{L.sys}) file like this:
+@example
+    airs Any/Z,Any2305-0855 ...
+@end example
+This allows grades @samp{Z} and above to be transferred at any time.
+Lower grades may only be transferred at night.  I believe that this
+grade restriction applies to local commands as well as to remote
+commands, but I am not sure.  It may only apply if the UUCP package
+places the call, not if it is called by the remote system.
+
+Taylor UUCP can use the @code{timegrade} and @code{call-timegrade}
+commands to achieve the same effect.
+@ifclear faq
+@xref{When to Call}.
+@end ifclear
+It supports the above format when reading @file{Systems} or
+@file{L.sys}.
+
+UUPC/extended provides the @code{symmetricgrades} option to announce the
+current grade in effect when calling the remote system.
+
+UUPlus allows specification of the highest grade accepted on a per-call
+basis with the @samp{-g} option in @code{UUCICO}.
+
+This sort of grade restriction is most useful if you know what grades
+are being used at the remote site.  The default grades used depend on
+the UUCP package.  Generally @code{uucp} and @code{uux} have different
+defaults.  A particular grade can be specified with the @samp{-g} option
+to @code{uucp} or @code{uux}.  For example, to request execution of
+@samp{rnews} on @samp{airs} with grade @samp{d}, you might use something
+like
+@example
+    uux -gd - airs!rnews < article
+@end example
+
+Uunet queues up mail at grade @samp{C}, but increases the grade based on
+the size.  News is queued at grade @samp{d}, and file transfers at grade
+@samp{n}.  The example above would allow mail (below some large size) to
+be received at any time, but would only permit news to be transferred at
+night.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP Lock Files
+Subject: UUCP Lock Files
+@end format
+@end ifset
+
+@node UUCP Lock Files, Execution File Format, UUCP Grades, Protocols
+@section UUCP Lock Files
+@cindex lock files
+
+This discussion applies only to Unix.  I have no idea how UUCP locks
+ports on other systems.
+
+UUCP creates files to lock serial ports and systems.  On most, if not
+all, systems, these same lock files are also used by @code{cu} to
+coordinate access to serial ports.  On some systems @code{getty} also
+uses these lock files, often under the name @code{uugetty}.
+
+The lock file normally contains the process ID of the locking process.
+This makes it easy to determine whether a lock is still valid.  The
+algorithm is to create a temporary file and then link it to the name
+that must be locked.  If the link fails because a file with that name
+already exists, the existing file is read to get the process ID.  If the
+process still exists, the lock attempt fails.  Otherwise the lock file
+is deleted and the locking algorithm is retried.
+
+Older UUCP packages put the lock files in the main UUCP spool directory,
+@file{/usr/spool/uucp}.  HDB UUCP generally puts the lock files in a
+directory of their own, usually @file{/usr/spool/locks} or
+@file{/etc/locks}.
+
+The original UUCP lock file format encodes the process ID as a four byte
+binary number.  The order of the bytes is host-dependent.  HDB UUCP
+stores the process ID as a ten byte ASCII decimal number, with a
+trailing newline.  For example, if process 1570 holds a lock file, it
+would contain the eleven characters space, space, space, space, space,
+space, one, five, seven, zero, newline.  Some versions of UUCP add a
+second line indicating which program created the lock (@code{uucp},
+@code{cu}, or @code{getty/uugetty}).  I have also seen a third type of
+UUCP lock file which does not contain the process ID at all.
+
+The name of the lock file is traditionally @file{LCK..} followed by the
+base name of the device.  For example, to lock @file{/dev/ttyd0} the
+file @file{LCK..ttyd0} would be created.  On SCO Unix, the lock file
+name is always forced to lower case even if the device name has upper
+case letters.
+
+System V Release 4 UUCP names the lock file using the major and minor
+device numbers rather than the device name.  The file is named
+@file{LK.@var{XXX}.@var{YYY}.@var{ZZZ}}, where @var{XXX}, @var{YYY} and
+@var{ZZZ} are all three digit decimal numbers.  @var{XXX} is the major
+device number of the device holding the directory holding the device
+file (e.g., @file{/dev}).  @var{YYY} is the major device number of the
+device file itself.  @var{ZZZ} is the minor device number of the device
+file itself.  If @code{s} holds the result of passing the device to the
+stat system call (e.g., @code{stat ("/dev/ttyd0", &s)}), the following
+line of C code will print out the corresponding lock file name:
+@example
+    printf ("LK.%03d.%03d.%03d", major (s.st_dev),
+            major (s.st_rdev), minor (s.st_rdev));
+@end example
+The advantage of this system is that even if there are several links to
+the same device, they will all use the same lock file name.
+
+When two or more instances of @code{uuxqt} are executing, some sort of
+locking is needed to ensure that a single execution job is only started
+once.  I don't know how most UUCP packages deal with this.  Taylor UUCP
+uses a lock file for each execution job.  The name of the lock file is
+the same as the name of the @file{X.*} file, except that the initial
+@samp{X} is changed to an @samp{L}.  The lock file holds the process ID
+as described above.
+
+@ifset faq
+@format
+------------------------------
+
+From: Execution File Format
+Subject: Execution File Format
+@end format
+@end ifset
+
+@node Execution File Format, UUCP Protocol, UUCP Lock Files, Protocols
+@section Execution File Format
+@cindex execution file format
+@cindex @file{X.*} file format
+
+UUCP @file{X.*} files control program execution.  They are created by
+@code{uux}.  They are transferred between systems just like any other
+file.  The @code{uuxqt} daemon reads them to figure out how to execute
+the job requested by @code{uux}.
+
+An @file{X.*} file is simply a text file.  The first character of each
+line is a command, and the remainder of the line supplies arguments.
+The following commands are defined:
+
+@table @samp
+@item C command
+This gives the command to execute, including the program and all
+arguments.  For example, @samp{rmail ian@@airs.com}.
+
+@item U user system
+This names the user who requested the command, and the system from which
+the request came.
+
+@item I standard-input
+This names the file from which standard input is taken.  If no standard
+input file is given, the standard input will probably be attached to
+@file{/dev/null}.  If the standard input file is not from the system on
+which the execution is to occur, it will also appear in an @samp{F}
+command.
+
+@item O standard-output [system]
+This names the standard output file.  The optional second argument names
+the system to which the file should be sent.  If there is no second
+argument, the file should be created on the executing system.
+
+@item F required-file [filename-to-use]
+The @samp{F} command can appear multiple times.  Each @samp{F} command
+names a file which must exist before the execution can proceed.  This
+will usually be a file which is transferred from the system on which
+@code{uux} was executed, but it can also be a file from the local system
+or some other system.  If the file is not from the local system, then
+the command will usually name a file in the spool directory.  If the
+optional second argument appears, then the file should be copied to the
+execution directory under that name.  This is necessary for any file
+other than the standard input file.  If the standard input file is not
+from the local system, it will appear in both an @samp{F} command and an
+@samp{I} command.
+
+@item R requestor-address
+This is the address to which mail about the job should be sent.  It is
+relative to the system named in the @samp{U} command.  If the @samp{R}
+command does not appear, then mail is sent to the user named in the
+@samp{U} command.
+
+@item Z
+This command takes no arguments.  It means that a mail message should be
+sent if the command failed.  This is the default behaviour for most
+modern UUCP packages, and for them the @samp{Z} command does not
+actually do anything.
+
+@item N
+This command takes no arguments.  It means that no mail message should
+be sent, even if the command failed.
+
+@item n
+This command takes no arguments.  It means that a mail message should be
+sent if the command succeeded.  Normally a message is sent only if the
+command failed.
+
+@item B
+This command takes no arguments.  It means that the standard input
+should be returned with any error message.  This can be useful in cases
+where the input would otherwise be lost.
+
+@item e
+This command takes no arguments.  It means that the command should be
+processed with @file{/bin/sh}.  For some packages this is the default
+anyhow.  Most packages will refuse to execute complex commands or
+commands containing wildcards, because of the security holes this opens.
+
+@item E
+This command takes no arguments.  It means that the command should be
+processed with the @code{execve} system call.  For some packages this is
+the default anyhow.
+
+@item M status-file
+This command means that instead of mailing a message, the message should
+be copied to the named file on the system named by the @samp{U} command.
+
+@item # comment
+This command is ignored, as is any other unrecognized command.  
+@end table
+
+Here is an example.  Given the following command executed on system
+test1
+@example
+    uux - test2!cat - test2!~ian/bar !qux '>~/gorp'
+@end example
+(this is only an example, as most UUCP systems will not permit the cat
+command to be executed) Taylor UUCP will produce something like the
+following @file{X.}  file:
+@example
+U ian test1
+F D.test1N003r qux
+O /usr/spool/uucppublic test1
+F D.test1N003s
+I D.test1N003s
+C cat - ~ian/bar qux
+@end example
+The standard input will be read into a file and then transferred to the
+file @file{D.test1N003s} on system @samp{test2}.  The file @file{qux}
+will be transferred to @file{D.test1N003r} on system @samp{test2}.  When
+the command is executed, the latter file will be copied to the execution
+directory under the name @samp{qux}.  Note that since the file
+@file{~ian/bar} is already on the execution system, no action need be
+taken for it.  The standard output will be collected in a file, then
+copied to the directory @file{/usr/spool/uucppublic} on the system
+@samp{test1}.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP Protocol
+Subject: UUCP Protocol
+@end format
+@end ifset
+
+@node UUCP Protocol, g Protocol, Execution File Format, Protocols
+@section UUCP Protocol
+@cindex UUCP protocol
+@cindex protocol, UUCP
+
+The UUCP protocol is a conversation between two UUCP packages.  A UUCP
+conversation consists of three parts: an initial handshake, a series of
+file transfer requests, and a final handshake.
+
+@menu
+* The Initial Handshake::       The Initial Handshake
+* UUCP Protocol Commands::      UUCP Protocol Commands
+* The Final Handshake::         The Final Handshake
+@end menu
+
+@node The Initial Handshake, UUCP Protocol Commands, UUCP Protocol, UUCP Protocol
+@subsection The Initial Handshake
+@cindex initial handshake
+
+Before the initial handshake, the caller will usually have logged in the
+called machine and somehow started the UUCP package there.  On Unix this
+is normally done by setting the shell of the login name used to
+@file{/usr/lib/uucp/uucico}.
+
+All messages in the initial handshake begin with a @kbd{^P} (a byte with
+the octal value @samp{\020}) and end with a null byte (@samp{\000}).  A
+few systems end these messages with a line feed character (@samp{\012})
+instead of a null byte; the examples below assume a null byte is being
+used.
+
+Some options below are supported by QFT, which stands for Queued File
+Transfer, and is (or was) an internal Bell Labs version of UUCP.  
+
+Taylor UUCP size negotiation was introduced by Taylor UUCP, and is
+also supported by DOS based UUPlus and Amiga based wUUCP and
+UUCP-1.17.
+
+The initial handshake goes as follows.  It is begun by the called
+machine.
+
+@table @asis
+@item called: @samp{\020Shere=hostname\000}
+The hostname is the UUCP name of the called machine.  Older UUCP
+packages do not output it, and simply send @samp{\020Shere\000}.
+
+@item caller: @samp{\020Shostname options\000}
+The hostname is the UUCP name of the calling machine.  The following
+options may appear (or there may be none):
+
+@table @samp
+@item -QSEQ
+Report sequence number for this conversation.  The sequence number is
+stored at both sites, and incremented after each call.  If there is a
+sequence number mismatch, something has gone wrong (somebody may have
+broken security by pretending to be one of the machines) and the call is
+denied.  If the sequence number changes on one of the machines, perhaps
+because of an attempted breakin or because a disk backup was restored,
+the sequence numbers on the two machines must be reconciled manually.
+
+@item -xLEVEL
+Requests the called system to set its debugging level to the specified
+value.  This is not supported by all systems.
+
+@item -pGRADE
+@itemx -vgrade=GRADE
+Requests the called system to only transfer files of the specified grade
+or higher.  This is not supported by all systems.  Some systems support
+@samp{-p}, some support @samp{-vgrade=}.  UUPlus allows either @samp{-p}
+or @samp{-v} to be specified on a per-system basis in the @file{SYSTEMS}
+file (@samp{gradechar} option).
+
+@item -R
+Indicates that the calling UUCP understands how to restart failed file
+transmissions.  Supported only by System V Release 4 UUCP, QFT, and
+Taylor UUCP.
+
+@item -ULIMIT
+Reports the ulimit value of the calling UUCP.  The limit is specified as
+a base 16 number in C notation (e.g., @samp{-U0x1000000}).  This number
+is the number of 512 byte blocks in the largest file which the calling
+UUCP can create.  The called UUCP may not transfer a file larger than
+this.  Supported only by System V Release 4 UUCP, QFT and UUPlus.
+UUPlus reports the lesser of the available disk space on the spool
+directory drive and the ulimit variable in @file{UUPLUS.CFG}.  Taylor
+UUCP understands this option, but does not generate it.
+
+@item -N[NUMBER]
+Indicates that the calling UUCP understands the Taylor UUCP size
+negotiation extension.  Not supported by traditional UUCP packages.
+Supported by UUPlus.  The optional number is a bitmask of features
+supported by the calling UUCP, and is described below.
+@end table
+
+@item called: @samp{\020ROK\000}
+There are actually several possible responses.
+@table @samp
+@item ROK
+The calling UUCP is acceptable, and the handshake proceeds to the
+protocol negotiation.  Some options may also appear; see below.
+@item ROKN[NUMBER]
+The calling UUCP is acceptable, it specified @samp{-N}, and the called
+UUCP also understands the Taylor UUCP size limiting extensions.  The
+optional number is a bitmask of features supported by the called UUCP,
+and is described below.
+@item RLCK
+The called UUCP already has a lock for the calling UUCP, which normally
+indicates the two machines are already communicating.
+@item RCB
+The called UUCP will call back.  This may be used to avoid impostors
+(but only one machine out of each pair should call back, or no
+conversation will ever begin).
+@item RBADSEQ
+The call sequence number is wrong (see the @samp{-Q} discussion above).
+@item RLOGIN
+The calling UUCP is using the wrong login name.
+@item RYou are unknown to me
+The calling UUCP is not known to the called UUCP, and the called UUCP
+does not permit connections from unknown systems.  Some versions of UUCP
+just drop the line rather than sending this message.
+@end table
+
+If the response is @samp{ROK}, the following options are supported by
+System V Release 4 UUCP and QFT.
+@table @samp
+@item -R
+The called UUCP knows how to restart failed file transmissions.
+@item -ULIMIT
+Reports the ulimit value of the called UUCP.  The limit is specified as
+a base 16 number in C notation.  This number is the number of 512 byte
+blocks in the largest file which the called UUCP can create.  The
+calling UUCP may not send a file larger than this.  Also supported by
+UUPlus.  Taylor UUCP understands this option, but does not generate it.
+@item -xLEVEL
+I'm not sure just what this means.  It may request the
+calling UUCP to set its debugging level to the specified
+value.
+@end table
+
+If the response is not @samp{ROK} (or @samp{ROKN}) both sides hang up
+the phone, abandoning the call.
+
+@item called: @samp{\020Pprotocols\000}
+Note that the called UUCP outputs two strings in a row.  The protocols
+string is a list of UUCP protocols supported by the caller.  Each UUCP
+protocol has a single character name.  These protocols are discussed in
+more detail later in this document.  For example, the called UUCP might
+send @samp{\020Pgf\000}.
+
+@item caller: @samp{\020Uprotocol\000}
+The calling UUCP selects which protocol to use out of the protocols
+offered by the called UUCP.  If there are no mutually supported
+protocols, the calling UUCP sends @samp{\020UN\000} and both sides hang
+up the phone.  Otherwise the calling UUCP sends something like
+@samp{\020Ug\000}.
+@end table
+
+Most UUCP packages will consider each locally supported protocol in turn
+and select the first one supported by the called UUCP.  With some
+versions of HDB UUCP, this can be modified by giving a list of protocols
+after the device name in the @file{Devices} file or the @file{Systems}
+file.  For example, to select the @samp{e} protocol in @file{Systems},
+@example
+    airs Any ACU,e ...
+@end example
+or in Devices,
+@example
+    ACU,e ttyXX ...
+@end example
+Taylor UUCP provides the @code{protocol}
+command which may be used either
+for a system
+@ifclear faq
+(@pxref{Protocol Selection})
+@end ifclear
+or a
+@ifclear faq
+port (@pxref{port File}).
+@end ifclear
+@ifset faq
+port.
+@end ifset
+UUPlus allows specification of the protocol string on a per-system basis
+in the @file{SYSTEMS} file.
+
+The optional number following a @samp{-N} sent by the calling system, or
+an @samp{ROKN} sent by the called system, is a bitmask of features
+supported by the UUCP package.  The optional number was introduced in
+Taylor UUCP version 1.04.  The number is sent as an octal number with a
+leading zero.  The following bits are currently defined.  A missing
+number should be taken as @samp{011}.
+
+@table @samp
+@item 01
+UUCP supports size negotiation.
+
+@item 02
+UUCP supports file restart.
+
+@item 04
+UUCP supports the @samp{E} command.
+
+@item 010
+UUCP requires the file size in the @samp{S} and @samp{R} commands to be
+in base 10.  This bit is used by default if no number appears, but
+should not be explicitly sent.
+
+@item 020
+UUCP expects a dummy string between the notify field and the size field
+in an @samp{S} command.  This is true of SVR4 UUCP.  This bit should not
+be used.
+@end table
+
+After the protocol has been selected and the initial handshake has been
+completed, both sides turn on the selected protocol.  For some protocols
+(notably @samp{g}) a further handshake is done at this point.
+
+@node UUCP Protocol Commands, The Final Handshake, The Initial Handshake, UUCP Protocol
+@subsection UUCP Protocol Commands
+
+Each protocol supports a method for sending a command to the remote
+system.  This method is used to transmit a series of commands between
+the two UUCP packages.  At all times, one package is the master and the
+other is the slave.  Initially, the calling UUCP is the master.
+
+If a protocol error occurs during the exchange of commands, both sides
+move immediately to the final handshake.
+
+The master will send one of five commands: @samp{S}, @samp{R}, @samp{X},
+@samp{E}, or @samp{H}.
+
+Any file name referred to below is either an absolute file name
+beginning with @file{/}, a public directory file name beginning with
+@file{~/}, a file name relative to a user's home directory beginning
+with @file{~@var{USER}/}, or a spool directory file name.  File names in
+the spool directory are not absolute, but instead are converted to file
+names within the spool directory by UUCP.  They always begin with
+@file{C.} (for a command file created by @code{uucp} or @code{uux}),
+@file{D.} (for a data file created by @code{uucp}, @code{uux} or by an
+execution, or received from another system for an execution), or
+@file{X.} (for an execution file created by @code{uux} or received from
+another system).
+
+@menu
+* The S Command::               The S Command
+* The R Command::               The R Command
+* The X Command::               The X Command
+* The E Command::               The E Command
+* The H Command::               The H Command
+@end menu
+
+@node The S Command, The R Command, UUCP Protocol Commands, UUCP Protocol Commands
+@subsubsection The S Command
+@cindex S UUCP protocol command
+@cindex UUCP protocol S command
+
+@table @asis
+@item master: @samp{S @var{from} @var{to} @var{user} -@var{options} @var{temp} @var{mode} @var{notify} @var{size}}
+The @samp{S} and the @samp{-} are literal characters.  This is a request
+by the master to send a file to the slave.
+
+@table @var
+@item from
+The name of the file to send.  If the @samp{C} option does not appear in
+@var{options}, the master will actually open and send this file.
+Otherwise the file has been copied to the spool directory, where it is
+named @var{temp}.  The slave ignores this field unless @var{to} is a
+directory, in which case the basename of @var{from} will be used as the
+file name.  If @var{from} is a spool directory filename, it must be a
+data file created for or by an execution, and must begin with @file{D.}.
+
+@item to
+The name to give the file on the slave.  If this field names a directory
+the file is placed within that directory with the basename of
+@var{from}.  A name ending in @samp{/} is taken to be a directory even
+if one does not already exist with that name.  If @var{to} begins with
+@file{X.}, an execution file will be created on the slave.  Otherwise,
+if @var{to} begins with @file{D.} it names a data file to be used by
+some execution file.  Otherwise, @var{to} should not be in the spool
+directory.
+
+@item user
+The name of the user who requested the transfer.
+
+@item options
+A list of options to control the transfer.  The following
+options are defined (all options are single characters):
+@table @samp
+@item C
+The file has been copied to the spool directory
+(the master should use @var{temp} rather than @var{from}).
+@item c
+The file has not been copied to the spool directory (this is the
+default).
+@item d
+The slave should create directories as necessary (this is the default).
+@item f
+The slave should not create directories if necessary, but should fail
+the transfer instead.
+@item m
+The master should send mail to @var{user} when the transfer is complete.
+@item n
+The slave should send mail to @var{notify} when the transfer is
+complete.
+@end table
+
+@item temp
+If the @samp{C} option appears in @var{options}, this names the file to
+be sent.  Otherwise if @var{from} is in the spool directory, @var{temp}
+is the same as @var{from}.  Otherwise @var{temp} may be a dummy string,
+such as @file{D.0}.  After the transfer has been succesfully completed,
+the master will delete the file @var{temp}.
+
+@item mode
+This is an octal number giving the mode of the file on the master.  If
+the file is not in the spool directory, the slave will always create it
+with mode 0666, except that if (@var{mode} & 0111) is not zero (the file
+is executable), the slave will create the file with mode 0777.  If the
+file is in the spool directory, some UUCP packages will use the
+algorithm above and some will always create the file with mode 0600.
+This field is ignored by UUPlus, since it is meaningless on DOS; UUPlus
+uses 0666 for outgoing files.
+
+@item notify
+This field may not be present, and in any case is only meaningful if the
+@samp{n} option appears in @var{options}.  If the @samp{n} option
+appears, then, when the transfer is successfully completed, the slave
+will send mail to @var{notify}, which must be a legal mailing address on
+the slave.  If a @var{size} field will appear but the @samp{n} option
+does not appear, @var{notify} will always be present, typically as the
+string @samp{dummy} or simply a pair of double quotes.
+
+@item size
+This field is only present when doing Taylor UUCP or SVR4 UUCP size
+negotiation.  It is the size of the file in bytes.  Taylor UUCP version
+1.03 sends the size as a decimal integer, while versions 1.04 and up,
+and all other UUCP packages that support size negotiation, send the size
+in base 16 with a leading 0x.
+@end table
+
+The slave then responds with an @samp{S} command response.
+
+@table @samp
+@item SY @var{start}
+The slave is willing to accept the file, and file transfer begins.  The
+@var{start} field will only be present when using file restart.  It
+specifies the byte offset into the file at which to start sending.  If
+this is a new file, @var{start} will be 0x0.
+
+@item SN2
+The slave denies permission to transfer the file.  This can mean that
+the destination directory may not be accessed, or that no requests are
+permitted.  It implies that the file transfer will never succeed.
+
+@item SN4
+The slave is unable to create the necessary temporary file.  This
+implies that the file transfer might succeed later.
+
+@item SN6
+This is only used by Taylor UUCP size negotiation.  It means that the
+slave considers the file too large to transfer at the moment, but it may
+be possible to transfer it at some other time.
+
+@item SN7
+This is only used by Taylor UUCP size negotiation.  It means that the
+slave considers the file too large to ever transfer.
+
+@item SN8
+This is only used by Taylor UUCP.  It means that the file was already
+received in a previous conversation.  This can happen if the receive
+acknowledgement was lost after it was sent by the receiver but before it
+was received by the sender.
+
+@item SN9
+This is only used by Taylor UUCP (versions 1.05 and up) and UUPlus
+(versions 2.0 and up).  It means that the remote system was unable to
+open another channel (see the discussion of the @samp{i} protocol for
+more information about channels).  This implies that the file transfer
+might succeed later.
+
+@item SN10
+This is reportedly used by SVR4 UUCP to mean that the file size is too
+large.
+@end table
+
+If the slave responds with @samp{SY}, a file transfer begins.  When the
+file transfer is complete, the slave sends a @samp{C} command response.
+
+@table @samp
+@item CY
+The file transfer was successful.
+@item CYM
+The file transfer was successful, and the slave wishes to become the
+master; the master should send an @samp{H} command, described below.
+@item CN5
+The temporary file could not be moved into the final location.  This
+implies that the file transfer will never succeed.
+@end table
+@end table
+
+After the @samp{C} command response has been received (in the @samp{SY}
+case) or immediately (in an @samp{SN} case) the master will send another
+command.
+
+@node The R Command, The X Command, The S Command, UUCP Protocol Commands
+@subsubsection The R Command
+@cindex R UUCP protocol command
+@cindex UUCP protocol R command
+
+@table @asis
+@item master: @samp{R @var{from} @var{to} @var{user} -@var{options} @var{size}}
+The @samp{R} and the @samp{-} are literal characters.  This is a request
+by the master to receive a file from the slave.  I do not know how SVR4
+UUCP or QFT implement file transfer restart in this case.
+
+@table @var
+@item from
+This is the name of the file on the slave which the master wishes to
+receive.  It must not be in the spool directory, and it may not contain
+any wildcards.
+
+@item to
+This is the name of the file to create on the master.  I do not believe
+that it can be a directory.  It may only be in the spool directory if
+this file is being requested to support an execution either on the
+master or on some system other than the slave.
+
+@item user
+The name of the user who requested the transfer.
+
+@item options
+A list of options to control the transfer.  The following
+options are defined (all options are single characters):
+@table @samp
+@item d
+The master should create directories as necessary (this is the default).
+@item f
+The master should not create directories if necessary, but should fail
+the transfer instead.
+@item m
+The master should send mail to @var{user} when the transfer is complete.
+@end table
+
+@item size
+This only appears if Taylor UUCP size negotiation is being used.  It
+specifies the largest file which the master is prepared to accept (when
+using SVR4 UUCP or QFT, this was specified in the @samp{-U} option
+during the initial handshake).
+@end table
+
+The slave then responds with an @samp{R} command response.  UUPlus does
+not support @samp{R} requests, and always responds with @samp{RN2}.
+
+@table @samp
+@item RY @var{mode} [@var{size}]
+The slave is willing to send the file, and file transfer begins.  The
+@var{mode} argument is the octal mode of the file on the slave.  The
+master treats this just as the slave does the @var{mode} argument in the
+send command, q.v.  I am told that SVR4 UUCP sends a trailing @var{size}
+argument.  For some versions of BSD UUCP, the @var{mode} argument may
+have a trailing @samp{M} character (e.g., @samp{RY 0666M}).  This means
+that the slave wishes to become the master.
+
+@item RN2
+The slave is not willing to send the file, either because it is not
+permitted or because the file does not exist.  This implies that the
+file request will never succeed.
+
+@item RN6
+This is only used by Taylor UUCP size negotiation.  It means that the
+file is too large to send, either because of the size limit specifies by
+the master or because the slave considers it too large.  The file
+transfer might succeed later, or it might not (this may be cleared up in
+a later release of Taylor UUCP).
+
+@item RN9
+This is only used by Taylor UUCP (versions 1.05 and up) and FSUUCP
+(versions 1.5 and up).  It means that the remote system was unable to
+open another channel (see the discussion of the @samp{i} protocol for
+more information about channels).  This implies that the file transfer
+might succeed later.
+@end table
+
+If the slave responds with @samp{RY}, a file transfer begins.  When the
+file transfer is complete, the master sends a @samp{C} command.  The
+slave pretty much ignores this, although it may log it.
+
+@table @samp
+@item CY
+The file transfer was successful.
+@item CN5
+The temporary file could not be moved into the final location.
+@end table
+
+After the @samp{C} command response has been sent (in the @samp{RY}
+case) or immediately (in an @samp{RN} case) the master will send another
+command.
+@end table
+
+@node The X Command, The E Command, The R Command, UUCP Protocol Commands
+@subsubsection The X Command
+@cindex X UUCP protocol command
+@cindex UUCP protocol X command
+
+@table @asis
+@item master: @samp{X @var{from} @var{to} @var{user} -@var{options}}
+The @samp{X} and the @samp{-} are literal characters.  This is a request
+by the master to, in essence, execute uucp on the slave.  The slave
+should execute @samp{uucp @var{from} @var{to}}.
+
+@table @var
+@item from
+This is the name of the file or files on the slave which the master
+wishes to transfer.  Any wildcards are expanded on the slave.  If the
+master is requesting that the files be transferred to itself, the
+request would normally contain wildcard characters, since otherwise an
+@samp{R} command would suffice.  The master can also use this command to
+request that the slave transfer files to a third system.
+
+@item to
+This is the name of the file or directory to which the files should be
+transferred.  This will normally use a UUCP name.  For example, if the
+master wishes to receive the files itself, it would use
+@samp{master!path}.
+
+@item user
+The name of the user who requested the transfer.
+
+@item options
+A list of options to control the transfer.  It is not clear which, if
+any, options are supported by most UUCP packages.
+@end table
+
+The slave then responds with an @samp{X} command response.  FSUUCP does
+not support @samp{X} requests, and always responds with @samp{XN}.
+
+@table @samp
+@item XY
+The request was accepted, and the appropriate file transfer commands
+have been queued up for later processing.
+
+@item XN
+The request was denied.  No particular reason is given.
+@end table
+
+In either case, the master will then send another command.
+@end table
+
+@node The E Command, The H Command, The X Command, UUCP Protocol Commands
+@subsubsection The E Command
+@cindex E UUCP protocol command
+@cindex UUCP protocol E command
+
+@table @asis
+@item master: @samp{E @var{from} @var{to} @var{user} -@var{options} @var{temp} @var{mode} @var{notify} @var{size} @var{command}}
+The @samp{E} command is only supported by Taylor UUCP 1.04 and up.  It
+is used to make an execution request without requiring a separate
+@file{X.*} file.  
+@ifclear faq
+@xref{Execution File Format}.
+@end ifclear
+It is only used when the command to be executed requires a single input
+file which is passed to it as standard input.
+
+All the fields have the same meaning as they do for an @samp{S} command,
+except for @var{options} and @var{command}.
+
+@table @var
+@item options
+A list of options to control the transfer.  The following options are
+defined (all options are single characters):
+@table @samp
+@item C
+The file has been copied to the spool directory (the master should use
+@var{temp} rather than @var{from}).
+@item c
+The file has not been copied to the spool directory (this is the
+default).
+@item N
+No mail message should be sent, even if the command fails.  This is the
+equivalent of the @samp{N} command in an @file{X.*} file.
+@item Z
+A mail message should be sent if the command fails (this is generally
+the default in any case).  This is the equivalent of the @samp{Z}
+command in an @file{X.*} file.
+@item R
+Mail messages about the execution should be sent to the address in the
+@var{notify} field.  This is the equivalent of the @samp{R} command in
+an @file{X.*} file.
+@item e
+The execution should be done with @file{/bin/sh}.  This is the
+equivalent of the @samp{e} command in an @file{X.*} file.
+@end table
+
+@item command
+The command which should be executed.  This is the equivalent of the
+@samp{C} command in an @file{X.*} file.
+@end table
+
+The slave then responds with an @samp{E} command response.  These are
+the same as the @samp{S} command responses, but the initial character is
+@samp{E} rather than @samp{S}.
+
+If the slave responds with @samp{EY}, the file transfer begins.  When
+the file transfer is complete, the slave sends a @samp{C} command
+response, just as for the @samp{S} command.  After a successful file
+transfer, the slave is responsible for arranging for the command to be
+executed.  The transferred file is passed as standard input, as though
+it were named in the @samp{I} and @samp{F} commands of an @file{X.*}
+file.
+
+After the @samp{C} command response has been received (in the @samp{EY}
+case) or immediately (in an @samp{EN} case) the master will send another
+command.
+@end table
+
+@node The H Command,  , The E Command, UUCP Protocol Commands
+@subsubsection The H Command
+@cindex H UUCP protocol command
+@cindex UUCP protocol H command
+
+@table @asis
+@item master: @samp{H}
+This is used by the master to hang up the connection.  The slave will
+respond with an @samp{H} command response.
+
+@table @samp
+@item HY
+The slave agrees to hang up the connection.  In this case the master
+sends another @samp{HY} command.  In some UUCP packages the slave will
+then send a third @samp{HY} command.  At this point the protocol is shut
+down, and the final handshake is begun.
+@item HN
+The slave does not agree to hang up.  In this case the master and the
+slave exchange roles.  The next command will be sent by the former
+slave, which is the new master.  The roles may be reversed several times
+during a single connection.
+@end table
+@end table
+
+@node The Final Handshake,  , UUCP Protocol Commands, UUCP Protocol
+@subsection The Final Handshake
+@cindex final handshake
+
+After the protocol has been shut down, the final handshake is performed.
+This handshake has no real purpose, and some UUCP packages simply drop
+the connection rather than do it (in fact, some will drop the connection
+immediately after both sides agree to hangup, without even closing down
+the protocol).
+
+@table @asis
+@item caller: @samp{\020OOOOOO\000}
+
+@item called: @samp{\020OOOOOOO\000}
+@end table
+
+That is, the calling UUCP sends six @samp{O} characters and the called
+UUCP replies with seven @samp{O} characters.  Some UUCP packages always
+send six @samp{O} characters.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{g} Protocol
+Subject: UUCP @samp{g} Protocol
+@end format
+@end ifset
+
+@node g Protocol, f Protocol, UUCP Protocol, Protocols
+@section UUCP @samp{g} Protocol
+@cindex @samp{g} protocol
+@cindex protocol @samp{g}
+
+The @samp{g} protocol is a packet based flow controlled error correcting
+protocol that requires an eight bit clear connection.  It is the
+original UUCP protocol, and is supported by all UUCP implementations.
+Many implementations of it are only able to support small window and
+packet sizes, specifically a window size of 3 and a packet size of 64
+bytes, but the protocol itself can support up to a window size of 7 and
+a packet size of 4096 bytes.  Complaints about the inefficiency of the
+@samp{g} protocol generally refer to specific implementations, rather
+than to the correctly implemented protocol.
+
+The @samp{g} protocol was originally designed for general packet
+drivers, and thus contains some features that are not used by UUCP,
+including an alternate data channel and the ability to renegotiate
+packet and window sizes during the communication session.
+
+The @samp{g} protocol is spoofed by many Telebit modems.  When spoofing
+is in effect, each Telebit modem uses the @samp{g} protocol to
+communicate with the attached computer, but the data between the modems
+is sent using a Telebit proprietary error correcting protocol.  This
+allows for very high throughput over the Telebit connection, which,
+because it is half-duplex, would not normally be able to handle the
+@samp{g} protocol very well at all.  When a Telebit is spoofing the
+@samp{g} protocol, it forces the packet size to be 64 bytes and the
+window size to be 3.
+
+This discussion of the @samp{g} protocol explains how it works, but does
+not discuss useful error handling techniques.  Some discussion of this
+can be found in Jamie E. Hanrahan's paper, cited 
+@ifclear faq
+above (@pxref{UUCP Protocol Sources}).
+@end ifclear
+@ifset faq
+above.
+@end ifset
+
+All @samp{g} protocol communication is done with packets.  Each packet
+begins with a six byte header.  Control packets consist only of the
+header.  Data packets contain additional data.
+
+The header is as follows:
+
+@table @asis
+@item @samp{\020}
+Every packet begins with a @kbd{^P}.
+
+@item @var{k} (1 <= @var{k} <= 9)
+The @var{k} value is always 9 for a control packet.  For a data packet,
+the @var{k} value indicates how much data follows the six byte header.
+The amount of data is
+@ifinfo
+2 ** (@var{k} + 4), where ** indicates exponentiation.
+@end ifinfo
+@iftex
+@tex
+$2^{k + 4}$.
+@end tex
+@end iftex
+Thus a @var{k} value of 1 means 32 data bytes and a
+@var{k} value of 8 means 4096 data bytes.  The @var{k} value for a data
+packet must be between 1 and 8 inclusive.
+
+@item checksum low byte
+@itemx checksum high byte
+The checksum value is described below.
+
+@item control byte
+The control byte indicates the type of packet, and is described below.
+
+@item xor byte
+This byte is the xor of @var{k}, the checksum low byte, the checksum
+high byte and the control byte (i.e., the second, third, fourth and
+fifth header bytes).  It is used to ensure that the header data is
+valid.
+@end table
+
+The control byte in the header is composed of three bit fields, referred
+to here as @var{tt} (two bits), @var{xxx} (three bits) and @var{yyy}
+(three bits).  The control is @var{tt}@var{xxx}@var{yyy}, or @code{(@var{tt}
+<< 6) + (@var{xxx} << 3) + @var{yyy}}.
+
+The @var{TT} field takes on the following values:
+
+@table @samp
+@item 0
+This is a control packet.  In this case the @var{k} byte in the
+header must be 9.  The @var{xxx} field indicates the type of control
+packet; these types are described below.
+
+@item 1
+This is an alternate data channel packet.  This is not used by UUCP.
+
+@item 2
+This is a data packet, and the entire contents of the attached data
+field (whose length is given by the @var{k} byte in the header) are
+valid.  The @var{xxx} and @var{yyy} fields are described below.
+
+@item 3
+This is a short data packet.  Let the length of the data field (as given
+by the @var{k} byte in the header) be @var{l}.  Let the first byte in
+the data field be @var{b1}.  If @var{b1} is less than 128 (if the most
+significant bit of @var{b1} is 0), then there are @code{@var{l} -
+@var{b1}} valid bytes of data in the data field, beginning with the
+second byte.  If @code{@var{b1} >= 128}, let @var{b2} be the second byte
+in the data field.  Then there are @code{@var{l} - ((@var{b1} & 0x7f) +
+(@var{b2} << 7))} valid bytes of data in the data field, beginning with
+the third byte.  In all cases @var{l} bytes of data are sent (and all
+data bytes participate in the checksum calculation) but some of the
+trailing bytes may be dropped by the receiver.  The @var{xxx} and
+@var{yyy} fields are described below.
+@end table
+
+In a data packet (short or not) the @var{xxx} field gives the sequence
+number of the packet.  Thus sequence numbers can range from 0 to 7,
+inclusive.  The @var{yyy} field gives the sequence number of the last
+correctly received packet.
+
+Each communication direction uses a window which indicates how many
+unacknowledged packets may be transmitted before waiting for an
+acknowledgement.  The window may range from 1 to 7, and may be different
+in each direction. For example, if the window is 3 and the last packet
+acknowledged was packet number 6, packet numbers 7, 0 and 1 may be sent
+but the sender must wait for an acknowledgement before sending packet
+number 2.  This acknowledgement could come as the @var{yyy} field of a
+data packet, or as the @var{yyy} field of a @samp{RJ} or @samp{RR}
+control packet (described below).
+
+Each packet must be transmitted in order (the sender may not skip
+sequence numbers).  Each packet must be acknowledged, and each packet
+must be acknowledged in order.
+
+In a control packet, the @var{xxx} field takes on the following values:
+
+@table @asis
+@item 1 @samp{CLOSE}
+The connection should be closed immediately.  This is typically sent
+when one side has seen too many errors and wants to give up.  It is also
+sent when shutting down the protocol.  If an unexpected @samp{CLOSE}
+packet is received, a @samp{CLOSE} packet should be sent in reply and
+the @samp{g} protocol should halt, causing UUCP to enter the final
+handshake.
+
+@item 2 @samp{RJ} or @samp{NAK}
+The last packet was not received correctly.  The @var{yyy} field
+contains the sequence number of the last correctly received packet.
+
+@item 3 @samp{SRJ}
+Selective reject.  The @var{yyy} field contains the sequence number of a
+packet that was not received correctly, and should be retransmitted.
+This is not used by UUCP, and most implementations will not recognize
+it.
+
+@item 4 @samp{RR} or @samp{ACK}
+Packet acknowledgement.  The @var{yyy} field contains the sequence
+number of the last correctly received packet.
+
+@item 5 @samp{INITC}
+Third initialization packet.  The @var{yyy} field contains the maximum
+window size to use.
+
+@item 6 @samp{INITB}
+Second initialization packet.  The @var{yyy} field contains the
+packet size to use.  It requests a size of 
+@ifinfo
+2 ** (@var{yyy} + 5).
+@end ifinfo
+@iftex
+@tex
+$2^{yyy + 5}$.
+@end tex
+@end iftex
+Note that this is not the same coding used for the @var{k} byte in the
+packet header (it is 1 less).  Most UUCP implementations that request a
+packet size larger than 64 bytes can handle any packet size up to that
+specified.
+
+@item 7 @samp{INITA}
+First initialization packet.  The @var{yyy} field contains the maximum
+window size to use.
+@end table
+
+To compute the checksum, call the control byte (the fifth byte in the
+header) @var{c}.
+
+The checksum of a control packet is simply @code{0xaaaa - @var{c}}.
+
+The checksum of a data packet is @code{0xaaaa - (@var{check} ^
+@var{c})}, where @code{^} denotes exclusive or, and @var{check} is the
+result of the following routine as run on the contents of the data field
+(every byte in the data field participates in the checksum, even for a
+short data packet).  Below is the routine used by an early version of
+Taylor UUCP; it is a slightly modified version of a routine which John
+Gilmore patched from G.L.@: Chesson's original paper.  The @code{z}
+argument points to the data and the @code{c} argument indicates how much
+data there is.
+
+@example
+int
+igchecksum (z, c)
+     register const char *z;
+     register int c;
+@{
+  register unsigned int ichk1, ichk2;
+
+  ichk1 = 0xffff;
+  ichk2 = 0;
+
+  do
+    @{
+      register unsigned int b;
+
+      /* Rotate ichk1 left.  */
+      if ((ichk1 & 0x8000) == 0)
+        ichk1 <<= 1;
+      else
+        @{
+          ichk1 <<= 1;
+          ++ichk1;
+        @}
+
+      /* Add the next character to ichk1.  */
+      b = *z++ & 0xff;
+      ichk1 += b;
+
+      /* Add ichk1 xor the character position in the buffer counting from
+         the back to ichk2.  */
+      ichk2 += ichk1 ^ c;
+
+      /* If the character was zero, or adding it to ichk1 caused an
+         overflow, xor ichk2 to ichk1.  */
+      if (b == 0 || (ichk1 & 0xffff) < b)
+        ichk1 ^= ichk2;
+    @}
+  while (--c > 0);
+
+  return ichk1 & 0xffff;
+@}
+@end example
+
+When the @samp{g} protocol is started, the calling UUCP sends an
+@samp{INITA} control packet with the window size it wishes the called
+UUCP to use.  The called UUCP responds with an @samp{INITA} packet with
+the window size it wishes the calling UUCP to use.  Pairs of
+@samp{INITB} and @samp{INITC} packets are then similarly exchanged.
+When these exchanges are completed, the protocol is considered to have
+been started.
+
+Note that the window and packet sizes are not a negotiation.  Each
+system announces the window and packet size which the other system
+should use.  It is possible that different window and packet sizes will
+be used in each direction.  The protocol works this way on the theory
+that each system knows how much data it can accept without getting
+overrun.  Therefore, each system tells the other how much data to send
+before waiting for an acknowledgement.
+
+When a UUCP package transmits a command, it sends one or more data
+packets.  All the data packets will normally be complete, although some
+UUCP packages may send the last one as a short packet.  The command
+string is sent with a trailing null byte, to let the receiving package
+know when the command is finished.  Some UUCP packages require the last
+byte of the last packet sent to be null, even if the command ends
+earlier in the packet.  Some packages may require all the trailing bytes
+in the last packet to be null, but I have not confirmed this.
+
+When a UUCP package sends a file, it will send a sequence of data
+packets.  The end of the file is signalled by a short data packet
+containing zero valid bytes (it will normally be preceeded by a short
+data packet containing the last few bytes in the file).
+
+Note that the sequence numbers cover the entire communication session,
+including both command and file data.
+
+When the protocol is shut down, each UUCP package sends a @samp{CLOSE}
+control packet.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{f} Protocol
+Subject: UUCP @samp{f} Protocol
+@end format
+@end ifset
+
+@node f Protocol, t Protocol, g Protocol, Protocols
+@section UUCP @samp{f} Protocol
+@cindex @samp{f} protocol
+@cindex protocol @samp{f}
+
+The @samp{f} protocol is a seven bit protocol which checksums an entire
+file at a time.  It only uses the characters between @samp{\040} and
+@samp{\176} (ASCII @kbd{space} and @kbd{~}) inclusive, as well as the
+carriage return character.  It can be very efficient for transferring
+text only data, but it is very inefficient at transferring eight bit
+data (such as compressed news).  It is not flow controlled, and the
+checksum is fairly insecure over large files, so using it over a serial
+connection requires handshaking (XON/XOFF can be used) and error
+correcting modems.  Some people think it should not be used even under
+those circumstances.
+
+I believe that the @samp{f} protocol originated in BSD versions of UUCP.
+It was originally intended for transmission over X.25 PAD links.
+
+The @samp{f} protocol has no startup or finish protocol.  However, both
+sides typically sleep for a couple of seconds before starting up,
+because they switch the terminal into XON/XOFF mode and want to allow
+the changes to settle before beginning transmission.
+
+When a UUCP package transmits a command, it simply sends a string
+terminated by a carriage return.
+
+When a UUCP package transmits a file, each byte @var{b} of the file is
+translated according to the following table:
+
+@example
+       0 <= @var{b} <=  037: 0172, @var{b} + 0100 (0100 to 0137)
+     040 <= @var{b} <= 0171:       @var{b}        ( 040 to 0171)
+    0172 <= @var{b} <= 0177: 0173, @var{b} - 0100 ( 072 to  077)
+    0200 <= @var{b} <= 0237: 0174, @var{b} - 0100 (0100 to 0137)
+    0240 <= @var{b} <= 0371: 0175, @var{b} - 0200 ( 040 to 0171)
+    0372 <= @var{b} <= 0377: 0176, @var{b} - 0300 ( 072 to  077)
+@end example
+
+That is, a byte between @samp{\040} and @samp{\171} inclusive is
+transmitted as is, and all other bytes are prefixed and modified as
+shown.
+
+When all the file data is sent, a seven byte sequence is sent: two bytes
+of @samp{\176} followed by four ASCII bytes of the checksum as printed
+in base 16 followed by a carriage return.  For example, if the checksum
+was 0x1234, this would be sent: @samp{\176\1761234\r}.
+
+The checksum is initialized to 0xffff.  For each byte that is sent it is
+modified as follows (where @var{b} is the byte before it has been
+transformed as described above):
+
+@example
+      /* Rotate the checksum left.  */
+      if ((ichk & 0x8000) == 0)
+        ichk <<= 1;
+      else
+        @{
+          ichk <<= 1;
+          ++ichk;
+        @}
+
+      /* Add the next byte into the checksum.  */
+      ichk += @var{b};
+@end example
+
+When the receiving UUCP sees the checksum, it compares it against its
+own calculated checksum and replies with a single character followed
+by a carriage return.
+
+@table @samp
+@item G
+The file was received correctly.
+
+@item R
+The checksum did not match, and the file should be resent from the
+beginning.
+
+@item Q
+The checksum did not match, but too many retries have occurred and the
+communication session should be abandoned.
+@end table
+
+The sending UUCP checks the returned character and acts accordingly.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{t} Protocol
+Subject: UUCP @samp{t} Protocol
+@end format
+@end ifset
+
+@node t Protocol, e Protocol, f Protocol, Protocols
+@section UUCP @samp{t} Protocol
+@cindex @samp{t} protocol
+@cindex protocol @samp{t}
+
+The @samp{t} protocol is intended for use on links which provide
+reliable end-to-end connections, such as TCP.  It does no error checking
+or flow control, and requires an eight bit clear channel.
+
+I believe the @samp{t} protocol originated in BSD versions of UUCP.
+
+When a UUCP package transmits a command, it first gets the length of the
+command string, @var{c}.  It then sends @code{((@var{c} / 512) + 1) *
+512} bytes (the smallest multiple of 512 which can hold @var{c} bytes
+plus a null byte) consisting of the command string itself followed by
+trailing null bytes.
+
+When a UUCP package sends a file, it sends it in blocks.  Each block
+contains at most 1024 bytes of data.  Each block consists of four bytes
+containing the amount of data in binary (most significant byte first,
+the same format as used by the Unix function @code{htonl}) followed by
+that amount of data.  The end of the file is signalled by a block
+containing zero bytes of data.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{e} Protocol
+Subject: UUCP @samp{e} Protocol
+@end format
+@end ifset
+
+@node e Protocol, Big G Protocol, t Protocol, Protocols
+@section UUCP @samp{e} Protocol
+@cindex @samp{e} protocol
+@cindex protocol @samp{e}
+
+The @samp{e} protocol is similar to the @samp{t} protocol.  It does no
+flow control or error checking and is intended for use over networks
+providing reliable end-to-end connections, such as TCP.
+
+The @samp{e} protocol originated in versions of HDB UUCP.
+
+When a UUCP package transmits a command, it simply sends the command
+as an ASCII string terminated by a null byte.
+
+When a UUCP package transmits a file, it sends the complete size of the
+file as an ASCII decimal number.  The ASCII string is padded out to 20
+bytes with null bytes (i.e. if the file is 1000 bytes long, it sends
+@samp{1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0}).  It then sends the entire
+file.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{G} Protocol
+Subject: UUCP @samp{G} Protocol
+@end format
+@end ifset
+
+@node Big G Protocol, i Protocol, e Protocol, Protocols
+@section UUCP @samp{G} Protocol
+@cindex @samp{G} protocol
+@cindex protocol @samp{G}
+
+The @samp{G} protocol is used by SVR4 UUCP.  It is identical to the
+@samp{g} protocol, except that it is possible to modify the window and
+packet sizes.  The SVR4 implementation of the @samp{g} protocol
+reportedly is fixed at a packet size of 64 and a window size of 7.
+Supposedly SVR4 chose to implement a new protocol using a new letter to
+avoid any potential incompatibilities when using different packet or
+window sizes.
+
+Most implementations of the @samp{g} protocol that accept packets larger
+than 64 bytes will also accept packets smaller than whatever they
+requested in the @samp{INITB} packet.  The SVR4 @samp{G} implementation
+is an exception; it will only accept packets of precisely the size it
+requests in the INITB packet.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{i} Protocol
+Subject: UUCP @samp{i} Protocol
+@end format
+@end ifset
+
+@node i Protocol, j Protocol, Big G Protocol, Protocols
+@section UUCP @samp{i} Protocol
+@cindex @samp{i} protocol
+@cindex protocol @samp{i}
+
+The @samp{i} protocol was written by Ian Lance Taylor (who also wrote
+this
+@ifclear faq
+manual).
+@end ifclear
+@ifset faq
+FAQ).
+@end ifset
+It was first used by Taylor UUCP version 1.04.
+
+It is a sliding window packet protocol, like the @samp{g} protocol, but
+it supports bidirectional transfers (i.e., file transfers in both
+directions simultaneously).  It requires an eight bit clear connection.
+Several ideas for the protocol were taken from the paper @cite{A
+High-Throughput Message Transport System} by P.@: Lauder.  I don't know
+where the paper was published, but the author's e-mail address is
+@code{piers@@cs.su.oz.au}.  The @samp{i} protocol does not adopt his
+main idea, which is to dispense with windows entirely.  This is because
+some links still do require flow control and, more importantly, because
+using windows sets a limit to the amount of data which the protocol must
+be able to resend upon request.  To reduce the costs of window
+acknowledgements, the protocol uses a large window and only requires an
+ack at the halfway point.
+
+Each packet starts with a six byte header, optionally followed by data
+bytes with a four byte checksum.  There are currently five defined
+packet types (@samp{DATA}, @samp{SYNC}, @samp{ACK}, @samp{NAK},
+@samp{SPOS}, @samp{CLOSE}) which are described below.  Although any
+packet type may include data, any data provided with an @samp{ACK},
+@samp{NAK} or @samp{CLOSE} packet is ignored.
+
+Every @samp{DATA}, @samp{SPOS} and @samp{CLOSE} packet has a sequence
+number.  The sequence numbers are independent for each side.  The first
+packet sent by each side is always number 1.  Each packet is numbered
+one greater than the previous packet, modulo 32.
+
+Every packet has a local channel number and a remote channel number.
+For all packets at least one channel number is zero.  When a UUCP
+command is sent to the remote system, it is assigned a non-zero local
+channel number.  All packets associated with that UUCP command sent by
+the local system are given the selected local channel number.  All
+associated packets sent by the remote system are given the selected
+number as the remote channel number.  This permits each UUCP command
+to be uniquely identified by the channel number on the originating
+system, and therefore each UUCP package can associate all file data
+and UUCP command responses with the appropriate command.  This is a
+requirement for bidirectional UUCP transfers.
+
+The protocol maintains a single global file position, which starts at 0.
+For each incoming packet, any associated data is considered to occur at
+the current file position, and the file position is incremented by the
+amount of data contained.  The exception is a packet of type
+@samp{SPOS}, which is used to change the file position.  The reason for
+keeping track of the file position is described below.
+
+The header is as follows:
+
+@table @asis
+@item @samp{\007}
+Every packet begins with @kbd{^G}.
+
+@item @code{(@var{packet} << 3) + @var{locchan}}
+The five bit packet number combined with the three bit local channel
+number.  @samp{DATA}, @samp{SPOS} and @samp{CLOSE} packets use the
+packet sequence number for the @var{packet} field.  @samp{NAK} packet
+types use the @var{packet} field for the sequence number to be resent.
+@samp{ACK} and @samp{SYNC} do not use the @var{packet} field, and
+generally leave it set to 0.  Packets which are not associated with a
+UUCP command from the local system use a local channel number of 0.
+
+@item @code{(@var{ack} << 3) + @var{remchan}}
+The five bit packet acknowledgement combined with the three bit remote
+channel number.  The packet acknowledgement is the number of the last
+packet successfully received; it is used by all packet types.  Packets
+which are not sent in response to a UUCP command from the remote system
+use a remote channel number of 0.
+
+@item @code{(@var{type} << 5) + (@var{caller} << 4) + @var{len1}}
+The three bit packet type combined with the one bit packet direction
+combined with the upper four bits of the data length.  The packet
+direction bit is always 1 for packets sent by the calling UUCP, and 0
+for packets sent by the called UUCP.  This prevents confusion caused by
+echoed packets.
+
+@item @var{len2}
+The lower eight bits of the data length.  The twelve bits of data length
+permit packets ranging in size from 0 to 4095 bytes.
+
+@item @var{check}
+The exclusive or of the second through fifth bytes of the header.  This
+provides an additional check that the header is valid.
+@end table
+
+If the data length is non-zero, the packet is immediately followed by
+the specified number of data bytes.  The data bytes are followed by a
+four byte CRC 32 checksum, with the most significant byte first.  The
+CRC is calculated over the contents of the data field.
+
+The defined packet types are as follows:
+
+@table @asis
+@item 0 @samp{DATA}
+This is a plain data packet.
+
+@item 1 @samp{SYNC}
+@samp{SYNC} packets are exchanged when the protocol is initialized, and
+are described further below.  @samp{SYNC} packets do not carry sequence
+numbers (that is, the @var{packet} field is ignored).
+
+@item 2 @samp{ACK}
+This is an acknowledgement packet.  Since @samp{DATA} packets also carry
+packet acknowledgements, @samp{ACK} packets are only used when one side
+has no data to send.  @samp{ACK} packets do not carry sequence numbers.
+
+@item 3 @samp{NAK}
+This is a negative acknowledgement.  This is sent when a packet is
+received incorrectly, and means that the packet number appearing in the
+@var{packet} field must be resent.  @samp{NAK} packets do not carry
+sequence numbers (the @var{packet} field is already used).
+
+@item 4 @samp{SPOS}
+This packet changes the file position.  The packet contains four bytes
+of data holding the file position, most significant byte first.  The
+next packet received will be considered to be at the named file
+position.
+
+@item 5 @samp{CLOSE}
+When the protocol is shut down, each side sends a @samp{CLOSE} packet.
+This packet does have a sequence number, which could be used to ensure
+that all packets were correctly received (this is not needed by UUCP,
+however, which uses the higher level @samp{H} command with an @samp{HY}
+response).
+@end table
+
+When the protocol starts up, both systems send a @samp{SYNC} packet.
+The @samp{SYNC} packet includes at least three bytes of data.  The first
+two bytes are the maximum packet size the remote system should send,
+most significant byte first.  The third byte is the window size the
+remote system should use.  The remote system may send packets of any
+size up to the maximum.  If there is a fourth byte, it is the number of
+channels the remote system may use (this must be between 1 and 7,
+inclusive).  Additional data bytes may be defined in the future.
+
+The window size is the number of packets that may be sent before a
+packet is acknowledged.  There is no requirement that every packet be
+acknowledged; any acknowledgement is considered to acknowledge all
+packets through the number given.  In the current implementation, if one
+side has no data to send, it sends an @samp{ACK} when half the window is
+received.
+
+Note that the @samp{NAK} packet corresponds to the unused @samp{g}
+protocol @samp{SRJ} packet type, rather than to the @samp{RJ} packet
+type.  When a @samp{NAK} is received, only the named packet should be
+resent, not any subsequent packets.
+
+Note that if both sides have data to send, but a packet is lost, it is
+perfectly reasonable for one side to continue sending packets, all of
+which will acknowledge the last packet correctly received, while the
+system whose packet was lost will be unable to send a new packet because
+the send window will be full.  In this circumstance, neither side will
+time out and one side of the communication will be effectively shut down
+for a while.  Therefore, any system with outstanding unacknowledged
+packets should arrange to time out and resend a packet even if data is
+being received.
+
+Commands are sent as a sequence of data packets with a non-zero local
+channel number.  The last data packet for a command includes a trailing
+null byte (normally a command will fit in a single data packet).  Files
+are sent as a sequence of data packets ending with one of length zero.
+
+The channel numbers permit a more efficient implementation of the UUCP
+file send command.  Rather than send the command and then wait for the
+@samp{SY} response before sending the file, the file data is sent
+beginning immediately after the @samp{S} command is sent.  If an
+@samp{SN} response is received, the file send is aborted, and a final
+data packet of length zero is sent to indicate that the channel number
+may be reused.  If an @samp{SY} reponse with a file position indicator
+is received, the file send adjusts to the file position; this is why the
+protocol maintains a global file position.
+
+Note that the use of channel numbers means that each UUCP system may
+send commands and file data simultaneously.  Moreover, each UUCP system
+may send multiple files at the same time, using the channel number to
+disambiguate the data.  Sending a file before receiving an
+acknowledgement for the previous file helps to eliminate the round trip
+delays inherent in other UUCP protocols.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{j} Protocol
+Subject: UUCP @samp{j} Protocol
+@end format
+@end ifset
+
+@node j Protocol, x Protocol, i Protocol, Protocols
+@section UUCP @samp{j} Protocol
+@cindex @samp{j} protocol
+@cindex protocol @samp{j}
+
+The @samp{j} protocol is a variant of the @samp{i} protocol.  It was
+also written by Ian Lance Taylor, and first appeared in Taylor UUCP
+version 1.04.
+
+The @samp{j} protocol is a version of the @samp{i} protocol designed for
+communication links which intercept a few characters, such as XON or
+XOFF.  It is not efficient to use it on a link which intercepts many
+characters, such as a seven bit link.  The @samp{j} protocol performs no
+error correction or detection; that is presumed to be the responsibility
+of the @samp{i} protocol.
+
+When the @samp{j} protocol starts up, each system sends a printable
+ASCII string indicating which characters it wants to avoid using.  The
+string begins with the ASCII character @kbd{^} (octal 136) and ends with
+the ASCII character @kbd{~} (octal 176).  After sending this string,
+each system looks for the corresponding string from the remote system.
+The strings are composed of escape sequences: @samp{\ooo}, where
+@samp{o} is an octal digit.  For example, sending the string
+@samp{^\021\023~} means that the ASCII XON and XOFF characters should be
+avoided.  The union of the characters described in both strings (the
+string which is sent and the string which is received) is the set of
+characters which must be avoided in this conversation.  Avoiding a
+printable ASCII character (octal 040 to octal 176, inclusive) is not
+permitted.
+
+After the exchange of characters to avoid, the normal @samp{i} protocol
+start up is done, and the rest of the conversation uses the normal
+@samp{i} protocol.  However, each @samp{i} protocol packet is wrapped to
+become a @samp{j} protocol packet.
+
+Each @samp{j} protocol packet consists of a seven byte header, followed
+by data bytes, followed by index bytes, followed by a one byte trailer.
+The packet header looks like this:
+
+@table @asis
+@item @kbd{^}
+Every packet begins with the ASCII character @kbd{^}, octal 136.
+
+@item @var{high}
+@itemx @var{low}
+These two characters give the total number of bytes in the packet.  Both
+@var{high} and @var{low} are printable ASCII characters.  The length of
+the packet is @code{(@var{high} - 040) * 0100 + (@var{low} - 040)},
+where @code{040 <= @var{high} < 0177} and @code{040 <= @var{low} <
+0140}.  This permits a length of 6079 bytes, but there is a further
+restriction on packet size described below.
+
+@item @kbd{=}
+The ASCII character @kbd{=}, octal 075.
+
+@item @var{data-high}
+@itemx @var{data-low}
+These two characters give the total number of data bytes in the packet.
+The encoding is as described for @var{high} and @var{low}.  The number
+of data bytes is the size of the @samp{i} protocol packet wrapped inside
+this @samp{j} protocol packet.
+
+@item @kbd{@@}
+The ASCII character @kbd{@@}, octal 100.
+@end table
+
+The header is followed by the number of data bytes given in
+@var{data-high} and @var{data-low}.  These data bytes are the @samp{i}
+protocol packet which is being wrapped in the @samp{j} protocol packet.
+However, each character in the @samp{i} protocol packet which the
+@samp{j} protocol must avoid is transformed into a printable ASCII
+character (recall that avoiding a printable ASCII character is not
+permitted).  Two index bytes are used for each character which must be
+transformed.
+
+The index bytes immediately follow the data bytes.  The index bytes are
+created in pairs.  Each pair of index bytes encodes the location of a
+character in the @samp{i} protocol packet which was transformed to
+become a printable ASCII character.  Each pair of index bytes also
+encodes the precise transformation which was performed.
+
+When the sender finds a character which must be avoided, it will
+transform it using one or two operations.  If the character is 0200 or
+greater, it will subtract 0200.  If the resulting character is less than
+020, or is equal to 0177, it will xor by 020.  The result is a printable
+ASCII character.
+
+The zero based byte index of the character within the @samp{i} protocol
+packet is determined.  This index is turned into a two byte printable
+ASCII index, @var{index-high} and @var{index-low}, such that the index
+is @code{(@var{index-high} - 040) * 040 + (@var{index-low} - 040)}.
+@var{index-low} is restricted such that @code{040 <= @var{index-low} <
+0100}.  @var{index-high} is not permitted to be 0176, so @code{040 <=
+@var{index-high} < 0176}.  @var{index-low} is then modified to encode
+the transformation:
+
+@itemize @bullet
+@item If the character transformation only had to subtract 0200, then
+@var{index-low} is used as is.
+
+@item If the character transformation only had to xor by 020, then 040
+is added to @var{index-low}.
+
+@item If both operations had to be performed, then 0100 is added to
+@var{index-low}.  However, if the value of @var{index-low} was initially
+077, then adding 0100 would result in 0177, which is not a printable
+ASCII character.  For that special case, @var{index-high} is set to
+0176, and @var{index-low} is set to the original value of
+@var{index-high}.
+@end itemize
+
+The receiver decodes the index bytes as follows (this is the reverse of
+the operations performed by the sender, presented here for additional
+clarity):
+
+@itemize @bullet
+@item The first byte in the index is @var{index-high}, and the second is
+@var{index-low}.
+
+@item If @code{040 <= @var{index-high} < 0176}, the index refers to the
+data byte at position @code{(@var{index-high} - 040) * 040 +
+@var{index-low} % 040}.
+
+@item If @code{040 <= @var{index-low} < 0100}, then 0200 must be added
+to indexed byte.
+
+@item If @code{0100 <= @var{index-low} < 0140}, then 020 must be xor'ed
+to the indexed byte.
+
+@item If @code{0140 <= @var{index-low} < 0177}, then 0200 must be added
+to the indexed byte, and 020 must be xor'ed to the indexed byte.
+
+@item If @code{@var{index-high} == 0176}, the index refers to the data
+byte at position @code{(@var{index-low} - 040) * 040 + 037}.  0200 must
+be added to the indexed byte, and 020 must be xor'ed to the indexed
+byte.
+@end itemize
+
+This means the largest @samp{i} protocol packet which may be wrapped
+inside a @samp{j} protocol packet is @code{(0175 - 040) * 040 + (077 -
+040) == 3007} bytes.
+
+The final character in a @samp{j} protocol packet, following the index
+bytes, is the ASCII character @kbd{~} (octal 176).
+
+The motivation behind using an indexing scheme, rather than escape
+characters, is to avoid data movement.  The sender may simply add a
+header and a trailer to the @samp{i} protocol packet.  Once the receiver
+has loaded the @samp{j} protocol packet, it may scan the index bytes,
+transforming the data bytes, and then pass the data bytes directly on to
+the @samp{i} protocol routine.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{x} Protocol
+Subject: UUCP @samp{x} Protocol
+@end format
+@end ifset
+
+@node x Protocol, y Protocol, j Protocol, Protocols
+@section UUCP @samp{x} Protocol
+@cindex @samp{x} protocol
+@cindex protocol @samp{x}
+
+The @samp{x} protocol is used in Europe (and probably elsewhere) with
+machines that contain an builtin X.25 card and can send eight bit data
+transparently across X.25 circuits, without interference from the X.28
+or X.29 layers.  The protocol sends packets of 512 bytes, and relies on
+a write of zero bytes being read as zero bytes without stopping
+communication.  It first appeared in the original System V UUCP
+implementation.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{y} Protocol
+Subject: UUCP @samp{y} Protocol
+@end format
+@end ifset
+
+@node y Protocol, d Protocol, x Protocol, Protocols
+@section UUCP @samp{y} Protocol
+@cindex @samp{y} protocol
+@cindex protocol @samp{y}
+
+The @samp{y} protocol was developed by Jorge Cwik for use in FX UUCICO,
+a PC uucico program.  It is designed for communication lines which
+handle error correction and flow control.  It requires an eight bit
+clean connection.  It performs error detection, but not error
+correction: when an error is detected, the line is dropped.  It is a
+streaming protocol, like the @samp{f} protocol; there are no packet
+acknowledgements, so the protocol is efficient over a half-duplex
+communication line such as PEP.
+
+Every packet contains a six byte header:
+
+@table @asis
+@item sequence low byte
+@itemx sequence high byte
+A two byte sequence number, in little endian order.  The first sequence
+number is 0.  Since the first packet is always a sync packet (described
+below) the sequence number of the first data packet is always 1.  Each
+system counts sequence numbers independently.
+
+@item length low byte
+@itemx length high byte
+A two byte data length, in little endian order.  If the high bit of the
+sixteen bit field is clear, this is the number of data bytes which
+follow the six byte header.  If the high bit is set, there is no data,
+and the length field is a type of control packet.
+
+@item checksum low byte
+@itemx checksum high byte
+A two byte checksum, in little endian order.  The checksum is computed
+over the data bytes.  The checksum algorithm is described below.  If
+there are no data bytes, the checksum is sent as 0.
+@end table
+
+When the protocol starts up, each side must send a sync packet.  This is
+a packet with a normal six byte header followed by data.  The sequence
+number of the sync packet should be 0.  Currently at least four bytes of
+data must be sent with the sync packet.  Additional bytes should be
+ignored.  They are defined as follows:
+
+@table @asis
+@item version
+The version number of the protocol.  Currently this must be 1.  Larger
+numbers should be ignored; it is the responsibility of the newer version
+to accommodate the older one.
+
+@item packet size
+The maximum data length to use divided by 256.  This is sent as a single
+byte.  The maximum data length permitted is 32768, which would be sent
+as 128.  Customarily both systems will use the same maximum data length,
+the lower of the two requested.
+
+@item flags low byte
+@itemx flags high byte
+Two bytes of flags.  None are currently defined.  These bytes should be
+sent as 0, and ignored by the receiver.
+@end table
+
+A length field with the high bit set is a control packet.  The
+following control packet types are defined:
+
+@table @asis
+@item 0xfffe @samp{YPKT_ACK}
+Acknowledges correct receipt of a file.
+
+@item 0xfffd @samp{YPKT_ERR}
+Indicates an incorrect checksum.
+
+@item 0xfffc @samp{YPKT_BAD}
+Indicates a bad sequence number, an invalid length, or some other error.
+@end table
+
+If a control packet other than @samp{YPKT_ACK} is received, the
+connection is dropped.  If a checksum error is detected for a received
+packet, a @samp{YPKT_ERR} control packet is sent, and the connection is
+dropped.  If a packet is received out of sequence, a @samp{YPKT_BAD}
+control packet is sent, and the connection is dropped.
+
+The checksum is initialized to 0xffff.  For each data byte in a packet
+it is modified as follows (where @var{b} is the byte before it has been
+transformed as described above):
+
+@example
+      /* Rotate the checksum left.  */
+      if ((ichk & 0x8000) == 0)
+        ichk <<= 1;
+      else
+        @{
+          ichk <<= 1;
+          ++ichk;
+        @}
+
+      /* Add the next byte into the checksum.  */
+      ichk += @var{b};
+@end example
+
+This is the same algorithm as that used by the @samp{f} protocol.
+
+A command is sent as a sequence of data packets followed by a null byte.
+In the normal case, a command will fit into a single packet.  The packet
+should be exactly the length of the command plus a null byte.  If the
+command is too long, more packets are sent as required.
+
+A file is sent as a sequence of data packets, ending with a zero length
+packet.  The data packets may be of any length greater than zero and
+less than or equal to the maximum permitted packet size specified in the
+initial sync packet.
+
+After the zero length packet ending a file transfer has been received,
+the receiving system sends a @samp{YPKT_ACK} control packet.  The
+sending system waits for the @samp{YPKT_ACK} control packet before
+continuing; this wait should be done with a large timeout, since there
+may be a considerable amount of data buffered on the communication path.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{d} Protocol
+Subject: UUCP @samp{d} Protocol
+@end format
+@end ifset
+
+@node d Protocol, h Protocol, y Protocol, Protocols
+@section UUCP @samp{d} Protocol
+@cindex @samp{d} protocol
+@cindex protocol @samp{d}
+
+The @samp{d} protocol is apparently used for DataKit muxhost (not
+RS-232) connections.  No file size is sent.  When a file has been
+completely transferred, a write of zero bytes is done; this must be read
+as zero bytes on the other end.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{h} Protocol
+Subject: UUCP @samp{h} Protocol
+@end format
+@end ifset
+
+@node h Protocol, v Protocol, d Protocol, Protocols
+@section UUCP @samp{h} Protocol
+@cindex @samp{h} protocol
+@cindex protocol @samp{h}
+
+The @samp{h} protocol is apparently used in some places with HST modems.
+It does no error checking, and is not that different from the @samp{t}
+protocol.  I don't know the details.
+
+@ifset faq
+@format
+------------------------------
+
+From: UUCP @samp{v} Protocol
+Subject: UUCP @samp{v} Protocol
+@end format
+@end ifset
+
+@node v Protocol,  , h Protocol, Protocols
+@section UUCP @samp{v} Protocol
+@cindex @samp{v} protocol
+@cindex protocol @samp{v}
+
+The @samp{v} protocol is used by UUPC/extended, a PC UUCP program.  It
+is simply a version of the @samp{g} protocol which supports packets of
+any size, and also supports sending packets of different sizes during
+the same conversation.  There are many @samp{g} protocol implementations
+which support both, but there are also many which do not.  Using
+@samp{v} ensures that everything is supported.
+
+@ifset faq
+@format
+------------------------------
+
+From: Thanks
+Subject: Thanks
+@end format
+
+Besides the papers and information acknowledged at the top of this
+article, the following people have contributed help, advice,
+suggestions and information:
+@format
+    Earle Ake 513-429-6500 <ake@@Dayton.SAIC.COM>
+    chris@@uuplus.com (Christopher J. Ambler)
+    jhc@@iscp.bellcore.com (Jonathan Clark)
+    jorge@@laser.satlink.net (Jorge Cwik)
+    celit!billd@@UCSD.EDU (Bill Davidson)
+    "Drew Derbyshire" <ahd@@kew.com>
+    erik@@pdnfido.fidonet.org
+    Matthew Farwell <dylan@@ibmpcug.co.uk>
+    dgilbert@@gamiga.guelphnet.dweomer.org (David Gilbert)
+    kherron@@ms.uky.edu (Kenneth Herron)
+    Mike Ipatow <mip@@fido.itc.e-burg.su>
+    Romain Kang <romain@@pyramid.com>
+    "Jonathan I. Kamens" <jik@@GZA.COM>
+    "David J. MacKenzie" <djm@@eng.umd.edu>
+    jum@@helios.de (Jens-Uwe Mager)
+    peter@@xpoint.ruessel.sub.org (Peter Mandrella)
+    david nugent <david@@csource.oz.au>
+    Stephen.Page@@prg.oxford.ac.uk
+    joey@@tessi.UUCP (Joey Pruett)
+    James Revell <revell@@uunet.uu.net>
+    Larry Rosenman <ler@@lerami.lerctr.org>
+    Rich Salz <rsalz@@bbn.com>
+    evesg@@etlrips.etl.go.jp (Gjoen Stein)
+    kls@@ditka.Chicago.COM (Karl Swartz)
+    Dima Volodin <dvv@@hq.demos.su>
+    John.Woods@@proteon.com (John Woods)
+    jon@@console.ais.org (Jon Zeeff)
+    Eric Ziegast <ziegast@@uunet.uu.net>
+
+------------------------------
+
+End of UUCP Internals Frequently Asked Questions
+******************************
+@end format
+@end ifset
+@c END-OF-FAQ
+
+@node Hacking, Acknowledgements, Protocols, Top
+@chapter Hacking Taylor UUCP
+
+This chapter provides the briefest of guides to the Taylor UUCP source
+code itself.
+
+@menu
+* System Dependence::           System Dependence
+* Naming Conventions::          Naming Conventions
+* Patches::                     Patches
+@end menu
+
+@node System Dependence, Naming Conventions, Hacking, Hacking
+@section System Dependence
+
+The code is carefully segregated into a system independent portion and a
+system dependent portion.  The system dependent code is in the
+@file{unix} subdirectory, and also in the file @file{sysh.unx} (also
+known as @file{sysdep.h}).
+
+With the right configuration parameters, the system independent code
+calls only ANSI C functions.  Some of the less common ANSI C functions
+are also provided in the @file{lib} directory.  The replacement function
+@code{strtol} in @file{lib/strtol.c} assumes that the characters @kbd{A}
+to @kbd{F} and @kbd{a} to @kbd{f} appear in strictly sequential order.
+The function @code{igradecmp} in @file{uuconf/grdcmp.c} assumes that the
+upper and lower case letters appear in order.  Both assumptions are true
+for ASCII and EBCDIC, but neither is guaranteed by ANSI C.  Disregarding
+these caveats, I believe that the system independent portion of the code
+is strictly conforming.
+
+That's not too exciting, since all the work is done in the system
+dependent code.  I think that this code can conform to POSIX 1003.1,
+given the right compilation parameters.  I'm a bit less certain about
+this, though.
+
+The code has been used on a 16 bit segmented system with no function
+prototypes, so I'm fairly certain that all casts to long and pointers
+are done when necessary.
+
+@node Naming Conventions, Patches, System Dependence, Hacking
+@section Naming Conventions
+
+I use a modified Hungarian naming convention for my variables and
+functions.  As with all naming conventions, the code is rather opaque if
+you are not familiar with it, but becomes clear and easy to use with
+time.
+
+The first character indicates the type of the variable (or function
+return value).  Sometimes additional characters are used.  I use the
+following type prefixes:
+
+@table @samp
+@item a
+array; the next character is the type of an element
+@item b
+byte or character
+@item c
+count of something
+@item e
+stdio FILE *
+@item f
+boolean
+@item i
+generic integer
+@item l
+double
+@item o
+file descriptor (as returned by open, creat, etc.)
+@item p
+generic pointer
+@item q
+pointer to structure
+@item s
+structure
+@item u
+void (function return values only)
+@item z
+character string
+@end table
+
+A generic pointer (@code{p}) is sometimes a @code{void *}, sometimes a
+function pointer in which case the prefix is pf, and sometimes a pointer
+to another type, in which case the next character is the type to which
+it points (pf is overloaded).
+
+An array of strings (@code{char *[]}) would be named @code{az} (array of
+string).  If this array were passed to a function, the function
+parameter would be named @code{paz} (pointer to array of string).
+
+Note that the variable name prefixes do not necessarily indicate the
+type of the variable.  For example, a variable prefixed with @kbd{i} may
+be int, long or short.  Similarly, a variable prefixed with @kbd{b} may
+be a char or an int; for example, the return value of @code{getchar}
+would be caught in an int variable prefixed with @kbd{b}.
+
+For a non-local variable (extern or file static), the first character
+after the type prefix is capitalized.
+
+Most static variables and functions use another letter after the type
+prefix to indicate which module they come from.  This is to help
+distinguish different names in the debugger.  For example, all static
+functions in @file{protg.c}, the @samp{g} protocol source code, use a
+module prefix of @samp{g}.  This isn't too useful, as a number of
+modules use a module prefix of @samp{s}.
+
+@node Patches,  , Naming Conventions, Hacking
+@section Patches
+
+I am always grateful for any patches sent in.  Much of the flexibility
+and portability of the code is due to other people.  Please do not
+hesitate to send me any changes you have found necessary or useful.
+
+When sending a patch, please send the output of the Unix @code{diff}
+program invoked with the @samp{-c} option (if you have the GNU version
+of @code{diff}, use the @samp{-p} option).  Always invoke @code{diff}
+with the original file first and the modified file second.
+
+If your @code{diff} does not support @samp{-c} (or you don't have
+@code{diff}), send a complete copy of the modified file (if you have
+just changed a single function, you can just send the new version of the
+function).  In particular, please do not send @code{diff} output without
+the @samp{-c} option, as it is useless.
+
+If you have made a number of changes, it is very convenient for me if
+you send each change as a separate mail message.  Sometimes I will think
+that one change is useful but another one is not.  If they are in
+different messages it is much easier for me to apply one but not the
+other.
+
+I rarely apply the patches directly.  Instead I work my way through the
+hunks and apply each one separately.  This ensures that the naming
+remains consistent, and that I understand all the code.
+
+If you can not follow all these rules, then don't.  But if you do, it
+makes it more likely that I will incorporate your changes.  I am not
+paid for my UUCP work, and my available time is unfortunately very
+restricted.  The package is important to me, and I do what I can, but I
+can not do all that I would like, much less all that everybody else
+would like.
+
+Finally, please do not be offended if I do not reply to messages for
+some time, even a few weeks.  I am often behind on my mail, and if I
+think your message deserves a considered reply I will often put it aside
+until I have time to deal with it.
+
+@node Acknowledgements, Index (concepts), Hacking, Top
+@chapter Acknowledgements
+
+This is a list of people who gave help or suggestions while I was
+working on the Taylor UUCP project.  Appearance on this list does not
+constitute endorsement of the program, particularly since some of the
+comments were criticisms.  I've probably left some people off, and I
+apologize for any oversight; it does not mean your contribution was
+unappreciated.
+
+First of all, I would like to thank the people at Infinity Development
+Systems (formerly AIRS, which lives on in the domain name) for
+permitting me to use their computers and @file{uunet} access.  I would
+also like to thank Richard Stallman @code{<rms@@gnu.ai.mit.edu>} for
+founding the Free Software Foundation, and John Gilmore
+@code{<gnu@@cygnus.com>} for writing the initial version of gnuucp which
+was a direct inspiration for this somewhat larger project.  Chip
+Salzenberg @code{<chip@@tct.com>} has contributed many patches.
+@ifinfo
+Franc,ois
+@end ifinfo
+@iftex
+@tex
+Fran\c cois
+@end tex
+@end iftex
+Pinard @code{<pinard@@iro.umontreal.ca>} tirelessly tested the code and
+suggested many improvements.  He also put together the initial version
+of this manual.  Doug Evans contributed the zmodem protocol.  Marc
+Boucher @code{<marc@@CAM.ORG>} contributed the code supporting the pipe
+port type.  Jorge Cwik @code{jorge@@laser.satlink.net} contributed the
+@samp{y} protocol code.  Finally, Verbus M. Counts
+@code{<verbus@@westmark.com>} and Centel Federal Systems, Inc., deserve
+special thanks, since they actually paid me money to port this code to
+System III.
+
+In alphabetical order:
+
+@example
+"Earle F. Ake - SAIC" @code{<ake@@Dayton.SAIC.COM>}
+@code{mra@@searchtech.com} (Michael Almond)
+@code{cambler@@zeus.calpoly.edu} (Christopher J. Ambler)
+Brian W. Antoine @code{<briana@@tau-ceti.isc-br.com>}
+@code{jantypas@@soft21.s21.com} (John Antypas)
+@code{james@@bigtex.cactus.org} (James Van Artsdalen)
+@code{jima@@netcom.com} (Jim Avera)
+@code{nba@@sysware.DK} (Niels Baggesen)
+@code{uunet!hotmomma!sdb} (Scott Ballantyne)
+Zacharias Beckman @code{<zac@@dolphin.com>}
+@code{mike@@mbsun.ann-arbor.mi.us} (Mike Bernson)
+@code{bob@@usixth.sublink.org} (Roberto Biancardi)
+@code{statsci!scott@@coco.ms.washington.edu} (Scott Blachowicz)
+@code{bag%wood2.cs.kiev.ua@@relay.ussr.eu.net} (Andrey G Blochintsev)
+@code{spider@@Orb.Nashua.NH.US} (Spider Boardman)
+Gregory Bond @code{<gnb@@bby.com.au>}
+Marc Boucher @code{<marc@@CAM.ORG>}
+Ard van Breemen @code{<ard@@cstmel.hobby.nl>}
+@code{dean@@coplex.com} (Dean Brooks)
+@code{jbrow@@radical.com} (Jim Brownfield)
+@code{dave@@dlb.com} (Dave Buck)
+@code{gordon@@sneaky.lonestar.org} (Gordon Burditt)
+@code{dburr@@sbphy.physics.ucsb.edu} (Donald Burr)
+@code{mib@@gnu.ai.mit.edu} (Michael I Bushnell)
+Brian Campbell @code{<brianc@@quantum.on.ca>}
+Andrew A. Chernov @code{<ache@@astral.msk.su>}
+@code{jhc@@iscp.bellcore.com} (Jonathan Clark)
+@code{mafc!frank@@bach.helios.de} (Frank Conrad)
+Ed Carp @code{<erc@@apple.com>}
+@code{mpc@@mbs.linet.org} (Mark Clements)
+@code{verbus@@westmark.westmark.com} (Verbus M. Counts)
+@code{cbmvax!snark.thyrsus.com!cowan} (John Cowan)
+Bob Cunningham @code{<bob@@soest.hawaii.edu>}
+@code{jorge@@laser.satlink.net} (Jorge Cwik)
+@code{kdburg@@incoahe.hanse.de} (Klaus Dahlenburg)
+Damon @code{<d@@exnet.co.uk>}
+@code{celit!billd@@UCSD.EDU} (Bill Davidson)
+@code{hubert@@arakis.fdn.org} (Hubert Delahaye)
+@code{markd@@bushwire.apana.org.au} (Mark Delany)
+Allen Delaney @code{<allen@@brc.ubc.ca>}
+Gerriet M. Denkmann @code{gerriet@@hazel.north.de}
+@code{denny@@dakota.alisa.com} (Bob Denny)
+Drew Derbyshire @code{<ahd@@kew.com>}
+@code{ssd@@nevets.oau.org} (Steven S. Dick)
+@code{gert@@greenie.gold.sub.org} (Gert Doering)
+@code{gemini@@geminix.in-berlin.de} (Uwe Doering)
+Hans-Dieter Doll @code{<hd2@@Insel.DE>}
+@code{deane@@deane.teleride.on.ca} (Dean Edmonds)
+Mark W. Eichin @code{<eichin@@cygnus.com>}
+@code{erik@@pdnfido.fidonet.org}
+Andrew Evans @code{<andrew@@airs.com>}
+@code{dje@@cygnus.com} (Doug Evans)
+Marc Evans @code{<marc@@synergytics.com>}
+Dan Everhart @code{<dan@@dyndata.com>}
+@code{kksys!kegworks!lfahnoe@@cs.umn.edu} (Larry Fahnoe)
+Matthew Farwell @code{<dylan@@ibmpcug.co.uk>}
+@code{fenner@@jazz.psu.edu} (Bill Fenner)
+@code{jaf@@inference.com} (Jose A. Fernandez)
+"David J. Fiander" @code{<golem!david@@news.lsuc.on.ca>}
+Thomas Fischer @code{<batman@@olorin.dark.sub.org>}
+Mister Flash @code{<flash@@sam.imash.ras.ru>}
+@code{louis@@marco.de} (Ju"rgen Fluk)
+@code{erik@@eab.retix.com} (Erik Forsberg)
+@code{andy@@scp.caltech.edu} (Andy Fyfe)
+Lele Gaifax @code{<piggy@@idea.sublink.org>}
+@code{Peter.Galbavy@@micromuse.co.uk}
+@code{hunter@@phoenix.pub.uu.oz.au} (James Gardiner [hunter])
+Terry Gardner @code{<cphpcom!tjg01>}
+@code{dgilbert@@gamiga.guelphnet.dweomer.org} (David Gilbert)
+@code{ol@@infopro.spb.su} (Oleg Girko)
+@code{jimmy@@tokyo07.info.com} (Jim Gottlieb)
+Benoit Grange @code{<ben@@fizz.fdn.org>}
+@code{elg@@elgamy.jpunix.com} (Eric Lee Green)
+@code{ryan@@cs.umb.edu} (Daniel R. Guilderson)
+@code{greg@@gagme.chi.il.us} (Gregory Gulik)
+Richard H. Gumpertz @code{<rhg@@cps.com>}
+Scott Guthridge @code{<scooter@@cube.rain.com>}
+Michael Haberler @code{<mah@@parrot.prv.univie.ac.at>}
+Daniel Hagerty @code{<hag@@eddie.mit.edu>}
+@code{jh@@moon.nbn.com} (John Harkin)
+@code{guy@@auspex.auspex.com} (Guy Harris)
+@code{hsw1@@papa.attmail.com} (Stephen Harris)
+Petri Helenius @code{<pete@@fidata.fi>}
+@code{gabe@@edi.com} (B. Gabriel Helou)
+Bob Hemedinger @code{<bob@@dalek.mwc.com>}
+Andrew Herbert @code{<andrew@@werple.pub.uu.oz.au>}
+@code{kherron@@ms.uky.edu} (Kenneth Herron)
+Peter Honeyman @code{<honey@@citi.umich.edu>}
+@code{jhood@@smoke.marlboro.vt.us} (John Hood)
+Mike Ipatow @code{<mip@@fido.itc.e-burg.su>}
+Bill Irwin @code{<bill@@twg.bc.ca>}
+@code{pmcgw!personal-media.co.jp!ishikawa} (Chiaki Ishikawa)
+@code{ai@@easy.in-chemnitz.de} (Andreas Israel)
+@code{iverson@@lionheart.com} (Tim Iverson)
+@code{bei@@dogface.austin.tx.us} (Bob Izenberg)
+@code{djamiga!djjames@@fsd.com} (D.J.James)
+Rob Janssen @code{<cmgit!rob@@relay.nluug.nl>}
+@code{harvee!esj} (Eric S Johansson)
+Kevin Johnson @code{<kjj@@pondscum.phx.mcd.mot.com>}
+@code{rj@@rainbow.in-berlin.de} (Robert Joop)
+Alan Judge @code{<aj@@dec4ie.IEunet.ie>}
+@code{chris@@cj_net.in-berlin.de} (Christof Junge)
+Romain Kang @code{<romain@@pyramid.com>}
+@code{tron@@Veritas.COM} (Ronald S. Karr)
+Brendan Kehoe @code{<brendan@@cs.widener.edu>}
+@code{warlock@@csuchico.edu} (John Kennedy)
+@code{kersing@@nlmug.nl.mugnet.org} (Jac Kersing)
+@code{ok@@daveg.PFM-Mainz.de} (Olaf Kirch)
+Gabor Kiss @code{<kissg@@sztaki.hu>}
+@code{gero@@gkminix.han.de} (Gero Kuhlmann)
+@code{rob@@pact.nl} (Rob Kurver)
+"C.A. Lademann" @code{<cal@@zls.gtn.com>}
+@code{kent@@sparky.IMD.Sterling.COM} (Kent Landfield)
+Tin Le @code{<tin@@saigon.com>}
+@code{lebaron@@inrs-telecom.uquebec.ca}  (Gregory LeBaron)
+@code{karl@@sugar.NeoSoft.Com} (Karl Lehenbauer)
+@code{alex@@hal.rhein-main.de} (Alexander Lehmann)
+@code{merlyn@@digibd.com} (Merlyn LeRoy)
+@code{clewis@@ferret.ocunix.on.ca} (Chris Lewis)
+@code{gdonl@@ssi1.com} (Don Lewis)
+@code{libove@@libove.det.dec.com} (Jay Vassos-Libove)
+@code{bruce%blilly@@Broadcast.Sony.COM} (Bruce Lilly)
+Godfrey van der Linden @code{<Godfrey_van_der_Linden@@NeXT.COM>}
+Ted Lindgreen @code{<tlindgreen@@encore.nl>}
+@code{andrew@@cubetech.com} (Andrew Loewenstern)
+"Arne Ludwig" @code{<arne@@rrzbu.hanse.de>}
+Matthew Lyle @code{<matt@@mips.mitek.com>}
+@code{djm@@eng.umd.edu} (David J. MacKenzie)
+John R MacMillan @code{<chance!john@@sq.sq.com>}
+@code{jum@@helios.de} (Jens-Uwe Mager)
+Giles D Malet @code{<shrdlu!gdm@@provar.kwnet.on.ca>}
+@code{mem@@mv.MV.COM} (Mark E. Mallett)
+@code{pepe@@dit.upm.es} (Jose A. Manas)
+@code{peter@@xpoint.ruessel.sub.org} (Peter Mandrella)
+@code{martelli@@cadlab.sublink.org} (Alex Martelli)
+W Christopher Martin @code{<wcm@@geek.ca.geac.com>}
+Yanek Martinson @code{<yanek@@mthvax.cs.miami.edu>}
+@code{thomasm@@mechti.wupper.de} (Thomas Mechtersheimer)
+@code{jm@@aristote.univ-paris8.fr} (Jean Mehat)
+@code{me@@halfab.freiburg.sub.org} (Udo Meyer)
+@code{les@@chinet.chi.il.us} (Leslie Mikesell)
+@code{bug@@cyberdex.cuug.ab.ca} (Trever Miller)
+@code{mmitchel@@digi.lonestar.org} (Mitch Mitchell)
+Emmanuel Mogenet @code{<mgix@@krainte.jpn.thomson-di.fr>}
+@code{rmohr@@infoac.rmi.de} (Rupert Mohr)
+Jason Molenda @code{<molenda@@sequent.com>}
+@code{ianm@@icsbelf.co.uk} (Ian Moran)
+@code{jmorriso@@bogomips.ee.ubc.ca} (John Paul Morrison)
+@code{brian@@ilinx.wimsey.bc.ca} (Brian J. Murrell)
+@code{service@@infohh.rmi.de} (Dirk Musstopf)
+@code{lyndon@@cs.athabascau.ca} (Lyndon Nerenberg)
+@code{rolf@@saans.north.de} (Rolf Nerstheimer)
+@code{tom@@smart.bo.open.de} (Thomas Neumann)
+@code{mnichols@@pacesetter.com}
+Richard E. Nickle @code{<trystro!rick@@Think.COM>}
+@code{stephan@@sunlab.ka.sub.org} (Stephan Niemz)
+@code{nolan@@helios.unl.edu} (Michael Nolan)
+david nugent @code{<david@@csource.oz.au>}
+Jim O'Connor @code{<jim@@bahamut.fsc.com>}
+@code{kevin%kosman.uucp@@nrc.com} (Kevin O'Gorman)
+Petri Ojala @code{<ojala@@funet.fi>}
+@code{oneill@@cs.ulowell.edu} (Brian 'Doc' O'Neill)
+@code{Stephen.Page@@prg.oxford.ac.uk}
+@code{abekas!dragoman!mikep@@decwrl.dec.com} (Mike Park)
+Tim Peiffer @code{peiffer@@cs.umn.edu}
+@code{don@@blkhole.resun.com} (Don Phillips)
+"Mark Pizzolato 415-369-9366" @code{<mark@@infocomm.com>}
+John Plate @code{<plate@@infotek.dk>}
+@code{dplatt@@ntg.com} (Dave Platt)
+@code{eldorado@@tharr.UUCP} (Mark Powell)
+Mark Powell @code{<mark@@inet-uk.co.uk>}
+@code{pozar@@kumr.lns.com} (Tim Pozar)
+@code{joey@@tessi.UUCP} (Joey Pruett)
+Paul Pryor @code{ptp@@fallschurch-acirs2.army.mil}
+@code{putsch@@uicc.com} (Jeff Putsch)
+@code{ar@@nvmr.robin.de} (Andreas Raab)
+Jarmo Raiha @code{<jarmo@@ksvltd.FI>}
+James Revell @code{<revell@@uunet.uu.net>}
+Scott Reynolds @code{<scott@@clmqt.marquette.Mi.US>}
+@code{mcr@@Sandelman.OCUnix.On.Ca} (Michael Richardson)
+Kenji Rikitake @code{<kenji@@rcac.astem.or.jp>}
+@code{arnold@@cc.gatech.edu} (Arnold Robbins)
+@code{steve@@Nyongwa.cam.org} (Steve M. Robbins)
+Ollivier Robert @code{<Ollivier.Robert@@keltia.frmug.fr.net>}
+Serge Robyns @code{<sr@@denkart.be>}
+Lawrence E. Rosenman @code{<ler@@lerami.lerctr.org>}
+Jeff Ross @code{<jeff@@wisdom.bubble.org>}
+Aleksey P. Rudnev @code{<alex@@kiae.su>}
+"Heiko W.Rupp" @code{<hwr@@pilhuhn.ka.sub.org>}
+@code{wolfgang@@wsrcc.com} (Wolfgang S. Rupprecht)
+@code{tbr@@tfic.bc.ca} (Tom Rushworth)
+@code{jsacco@@ssl.com} (Joseph E. Sacco)
+@code{rsalz@@bbn.com} (Rich Salz)
+@code{sojurn!mike@@hobbes.cert.sei.cmu.edu} (Mike Sangrey)
+Nickolay Saukh @code{<nms@@ussr.EU.net>}
+@code{heiko@@lotte.sax.de} (Heiko Schlittermann)
+Eric Schnoebelen @code{<eric@@cirr.com>}
+@code{russell@@alpha3.ersys.edmonton.ab.ca} (Russell Schulz)
+@code{scott@@geom.umn.edu}
+Igor V. Semenyuk @code{<iga@@argrd0.argonaut.su>}
+Christopher Sawtell @code{<chris@@gerty.equinox.gen.nz>}
+@code{schuler@@bds.sub.org} (Bernd Schuler)
+@code{uunet!gold.sub.org!root} (Christian Seyb)
+@code{s4mjs!mjs@@nirvo.nirvonics.com} (M. J. Shannon Jr.)
+@code{shields@@tembel.org} (Michael Shields)
+@code{peter@@ficc.ferranti.com} (Peter da Silva)
+@code{vince@@victrola.sea.wa.us} (Vince Skahan)
+@code{frumious!pat} (Patrick Smith)
+@code{roscom!monty@@bu.edu} (Monty Solomon)
+@code{sommerfeld@@orchard.medford.ma.us} (Bill Sommerfeld)
+Julian Stacey @code{<stacey@@guug.de>}
+@code{evesg@@etlrips.etl.go.jp} (Gjoen Stein)
+Harlan Stenn @code{<harlan@@mumps.pfcs.com>}
+Ralf Stephan @code{<ralf@@ark.abg.sub.org>}
+@code{johannes@@titan.westfalen.de} (Johannes Stille)
+@code{chs@@antic.apu.fi} (Hannu Strang)
+@code{ralf@@reswi.ruhr.de} (Ralf E. Stranzenbach)
+@code{sullivan@@Mathcom.com} (S. Sullivan)
+Shigeya Suzuki @code{<shigeya@@dink.foretune.co.jp>}
+@code{kls@@ditka.Chicago.COM} (Karl Swartz)
+@code{swiers@@plains.NoDak.edu}
+Oleg Tabarovsky @code{<olg@@olghome.pccentre.msk.su>}
+@code{ikeda@@honey.misystems.co.jp} (Takatoshi Ikeda)
+John Theus @code{<john@@theus.rain.com>}
+@code{rd@@aii.com} (Bob Thrush)
+ppKarsten Thygesen @code{<karthy@@dannug.dk>}
+Graham Toal @code{<gtoal@@pizzabox.demon.co.uk>}
+@code{rmtodd@@servalan.servalan.com} (Richard Todd)
+Martin Tomes @code{<mt00@@controls.eurotherm.co.uk>}
+Len Tower @code{<tower-prep@@ai.mit.edu>}
+Mark Towfiq @code{<justice!towfiq@@Eingedi.Newton.MA.US>}
+@code{mju@@mudos.ann-arbor.mi.us} (Marc Unangst)
+Matthias Urlichs @code{<urlichs@@smurf.noris.de>}
+Tomi Vainio @code{<tomppa@@fidata.fi>}
+@code{a3@@a3.xs4all.nl} (Adri Verhoef)
+Andrew Vignaux @code{<ajv@@ferrari.datamark.co.nz>}
+@code{vogel@@omega.ssw.de} (Andreas Vogel)
+Dima Volodin @code{<dvv@@hq.demos.su>}
+@code{jos@@bull.nl} (Jos Vos)
+@code{jv@@nl.net} (Johan Vromans)
+David Vrona @code{<dave@@sashimi.wwa.com>}
+@code{Marcel.Waldvogel@@nice.usergroup.ethz.ch} (Marcel Waldvogel)
+@code{steve@@nshore.org} (Stephen J. Walick)
+@code{syd@@dsinc.dsi.com} (Syd Weinstein)
+@code{gerben@@rna.indiv.nluug.nl} (Gerben Wierda)
+@code{jbw@@cs.bu.edu} (Joe Wells)
+@code{frnkmth!twwells.com!bill} (T. William Wells)
+Peter Wemm @code{<Peter_Wemm@@zeus.dialix.oz.au>}
+@code{mauxci!eci386!woods@@apple.com} (Greg A. Woods)
+@code{John.Woods@@proteon.com} (John Woods)
+Michael Yu.Yaroslavtsev @code{<mike@@yaranga.ipmce.su>}
+Alexei K. Yushin @code{<root@@july.elis.crimea.ua>}
+@code{jon@@console.ais.org} (Jon Zeeff)
+Matthias Zepf @code{<agnus@@amylnd.stgt.sub.org>}
+Eric Ziegast @code{<uunet!ziegast>}
+@end example
+
+@node Index (concepts), Index (configuration file), Acknowledgements, Top
+@unnumbered Concept Index
+
+@printindex cp
+
+@node Index (configuration file),  , Index (concepts), Top
+@unnumbered Configuration File Index
+
+@printindex fn
+
+@contents
+@bye