DECUS UUCP (VMSNET Software)
                           Version 2.0

                     System Manager's Guide


                          June 26, 1992
                   (Spring 1992 Distribution)



                    The VMSnet Working Group
                      DECUS VAX Systems SIG


                        Jamie E. Hanrahan
                     Kernel Mode Consulting
                         P. O. Box 16540
                       San Diego, CA 92116
                         +1 619-284-8492
                         jeh@cmkrnl.com


Tom Allebrandi II                                  Mark Pizzolato
Inland Steel Research Labs                   1558 Fernside Street
East Chicago, IN                            Redwood City CA 94061
+1 219-399-6306                                   +1 415-369-9366
allebrandi@inland.com                           mark@infocomm.com
..!decwrl!simpact!inland!allebrandi       ...!decwrl!infopiz!mark
   DECUS UUCP Version 2.0 System Manager's Guide             Page ii









   This document was prepared with DSR, Digital Standard Runoff.
   The .MEM file supplied is formatted for correct printing on line
   printers and other devices that support the "return with no line
   feed" method of underlining.  60 lines per page (the intent is
   for a half inch margin at top and bottom) and 65 characters per
   line (allowing for one-inch side margins, even at 10 characters
   per inch) are used.  A few long lines appear in examples.  If
   your printer does not provide a satisfactory left margin, set
   your default directory to [.DOC] and type "@USRGD20 /RIGHT=n" at
   the DCL prompt; this will produce a new .MEM file with the text
   shifted right by the specified amount.  You can also use the
   /BACKSPACE qualifier to cause DSR to use the backspace method of
   underlining.

   IMPORTANT!!!

   Users of prior versions of this software should be sure to read
   the Appendix, "Converting From Previous Versions", and the
   Appendices, "Changes in Version 2.0", "Changes in Version 1.3x",
   etc., according to which version you're now running.
|  
|  Significant changes from the 1.3x edition of this document are
|  identified by change bars.

                                                      ___
   Those who are familiar with uucp under Unix should not assume
   that all of their experience is transferable.  For example,
   configuration files (control and system) are different here; chat
   scripts are very different.  (We didn't write all of this text
   for nothing!)



   VAX and VMS are trademarks of Digital Equipment Corporation.
   Hayes is a registered trademark of Hayes Microcomputer Products,
   Inc.
   Telebit, TrailBlazer, TrailBlazer Plus, and WorldBlazer are
   trademarks of Telebit Corporation.
   Unix is, as we all know very well by now, a registered trademark
   of AT&T.



   THIS DOCUMENT IS IN THE PUBLIC DOMAIN.
   DECUS UUCP Version 2.0 System Manager's Guide            Page iii















|  
|                           PRIVACY WARNING
|  
|  
|          This release of DECUS uucp will, by default,
|          attempt to send mail to a special mailbox
|          (uucpinst20@cmkrnl.com) to notify the uucp
|          developers of successful installation, if either
|          cmkrnl.com or uunet.uu.net is reachable according
|          to the local node's uucp map database.
|  
|          If you don't want this to happen, you can inhibit
|          it.  Simply define the logical name
|          UUCP_UUCLEAN_INHIBIT_DEVMAIL with an equivalence
|          string of "TRUE".  This is done (in this release)
|          via the control file, UUCP_CFG:CONTROL.
|          Information in this manual describes how to
|          define logicals via the control file.  You may
|          also wish to refer to the example control file,
|          [UUCP.EXAMPLES.CFG]CONTROL.
|  
|          The "code" that performs this operation is in
|          UUCP_BIN:UUCLEAN.COM.  Search for the string
|          "DEVMAIL" to find it.
|  
   DECUS UUCP Version 2.0 System Manager's Guide                  Page iv



                                      CONTENTS



   CHAPTER 0       INTRODUCTION

           0.1     How to Read This Document  . . . . . . . . . . . . 0-1
           0.2     Special Note for Cluster Users . . . . . . . . . . 0-2
           0.2.1     Special Note Regarding Multiple Queue Files  . . 0-2
           0.3     How To Get More Help . . . . . . . . . . . . . . . 0-2
           0.3.1     Everything You Wanted To Know About uucp (Mostly 
                     Under Unix, Though)  . . . . . . . . . . . . . . 0-2
           0.3.2     Don't Call Us, At Least Not Very Often . . . . . 0-3
           0.4     On-Line Help . . . . . . . . . . . . . . . . . . . 0-4
           0.4.1     Via The Network  . . . . . . . . . . . . . . . . 0-4
           0.4.2     DECUServe  . . . . . . . . . . . . . . . . . . . 0-4
           0.4.3     "Pageswapper" Notes System . . . . . . . . . . . 0-5
           0.4.4     For More Help and Updates After It's Running . . 0-5
           0.5     Squeaky Wheels Get The Grease  . . . . . . . . . . 0-5


   CHAPTER 1       CONCEPTS AND TERMINOLOGY

           1.1     The Basics . . . . . . . . . . . . . . . . . . . . 1-1
           1.2     What Is DECUS UUCP?  . . . . . . . . . . . . . . . 1-2
           1.3     How Do I Apply To Join The Network?  . . . . . . . 1-2
           1.4     How Are Mail and News Supported? . . . . . . . . . 1-3
           1.5     Netnews, Usenet, and VMSnet  . . . . . . . . . . . 1-3
           1.6     Internet...  . . . . . . . . . . . . . . . . . . . 1-4
           1.7     ...And Beyond  . . . . . . . . . . . . . . . . . . 1-5


   CHAPTER 2       INSTALLING THE FILES

           2.1     Organization of the Distribution Kit . . . . . . . 2-1
           2.2     What do I need?  . . . . . . . . . . . . . . . . . 2-2
           2.3     Organization and Nomenclature  . . . . . . . . . . 2-3
           2.3.1     "Example" Configuration Files and Command 
                     Procedures . . . . . . . . . . . . . . . . . . . 2-3
           2.4     Restoring the Files from the Savesets  . . . . . . 2-4
           2.4.1     From the VAX SIG Symposium Tape  . . . . . . . . 2-4
           2.4.2     From Magtape Distributions . . . . . . . . . . . 2-5
           2.4.3     From Network Distributions . . . . . . . . . . . 2-5


   CHAPTER 3       MODEMS AND MULTIPLEXERS

           3.1     Setting Terminal Characteristics . . . . . . . . . 3-1
           3.1.1     Conventional Multiplexers  . . . . . . . . . . . 3-1
           3.1.2     Terminal Servers . . . . . . . . . . . . . . . . 3-3
           3.1.2.1   DECserver 200MC, software version 3.0  . . . . . 3-3
           3.1.2.2   DECserver 200MC, software version 3.1  . . . . . 3-4
           3.1.2.3   RS232 Control Signals and Terminal Servers . . . 3-6
           3.1.2.4   Login Scripts  . . . . . . . . . . . . . . . . . 3-6
           3.1.2.5   Typeahead Buffers  . . . . . . . . . . . . . . . 3-6
           3.1.2.6   Additional Terminal Server Considerations  . . . 3-6
   DECUS UUCP Version 2.0 System Manager's Guide                   Page v



           3.1.2.6.1 LAT Circuit Timer  . . . . . . . . . . . . . . . 3-6
           3.1.2.6.2 The HOSTSYNC Characteristic  . . . . . . . . . . 3-7
           3.1.2.6.3 DECserver 200's and the Data Carrier Detect 
                     (DCD) signal . . . . . . . . . . . . . . . . . . 3-7
           3.2     Data Path Requirements . . . . . . . . . . . . . . 3-8
           3.3     Requirements for Serial Ports  . . . . . . . . . . 3-9
           3.4     Requirements for Modems  . . . . . . . . . . . .  3-10
           3.4.1     Result Codes . . . . . . . . . . . . . . . . .  3-10
           3.4.1.1   Background . . . . . . . . . . . . . . . . . .  3-10
           3.4.1.2   The Problem  . . . . . . . . . . . . . . . . .  3-10
           3.4.1.3   Solutions  . . . . . . . . . . . . . . . . . .  3-11
           3.4.1.4   Special Considerations for DMF32 Users . . . .  3-11
           3.5     RS232 Control Signals  . . . . . . . . . . . . .  3-12
           3.5.1     Data Terminal Ready (DTR)  . . . . . . . . . .  3-12
           3.5.2     Carrier Detect (CD)  . . . . . . . . . . . . .  3-13
           3.5.3     Data Set Ready (DSR) . . . . . . . . . . . . .  3-13
           3.5.3.1   DSR and Local Multiplexers . . . . . . . . . .  3-13
           3.5.3.2   DSR and Terminal Servers . . . . . . . . . . .  3-13
           3.5.3.3   Arranging For Correct DSR Signals  . . . . . .  3-14
           3.5.4     Clear To Send (CTS)  . . . . . . . . . . . . .  3-14
           3.5.5     Flow Control from VAX to Modem . . . . . . . .  3-15
           3.5.6     Sysgen Parameter TTY_DIALTYPE  . . . . . . . .  3-15
           3.5.7     Cabling  . . . . . . . . . . . . . . . . . . .  3-15
           3.6     Testing  . . . . . . . . . . . . . . . . . . . .  3-16
           3.7     Summary  . . . . . . . . . . . . . . . . . . . .  3-16


   CHAPTER 4       ARRANGING FOR UUCP CONNECTIONS

           4.1     Choose Your Host Name  . . . . . . . . . . . . . . 4-1
           4.2     Finding a Neighbor . . . . . . . . . . . . . . . . 4-2
           4.2.1     Performance Systems International  . . . . . . . 4-3
           4.2.2     UUNET  . . . . . . . . . . . . . . . . . . . . . 4-3
           4.3     Exchange Login Procedures  . . . . . . . . . . . . 4-4


   CHAPTER 5       CONFIGURING DECUS UUCP

           5.1     Create the uucp Username(s)  . . . . . . . . . . . 5-1
           5.1.1     Manual Account Creation  . . . . . . . . . . . . 5-1
           5.1.2     Test Account . . . . . . . . . . . . . . . . . . 5-3
           5.2     Create Your UUCP Map Entry . . . . . . . . . . . . 5-4
           5.3     The UUCP_SYSTARTUP.COM Command Procedure . . . . . 5-4
           5.4     Create The UUCP Control File . . . . . . . . . . . 5-4
           5.4.1     Control File Parameters  . . . . . . . . . . . . 5-5
           5.4.1.1   hostname . . . . . . . . . . . . . . . . . . . . 5-5
           5.4.1.2   filealias  . . . . . . . . . . . . . . . . . . . 5-6
           5.4.1.3   UUCP_DOMAIN_NAME . . . . . . . . . . . . . . . . 5-6
           5.4.1.4   UUCP_POSTMASTER  . . . . . . . . . . . . . . . . 5-6
           5.4.1.5   UUCP_TIME_ZONE . . . . . . . . . . . . . . . . . 5-7
           5.4.1.6   Debug  . . . . . . . . . . . . . . . . . . . . . 5-7
           5.4.1.7   Port . . . . . . . . . . . . . . . . . . . . . . 5-7
           5.4.1.8   sleeptime  . . . . . . . . . . . . . . . . . . . 5-9
           5.4.1.9   Enbrmtrcv  . . . . . . . . . . . . . . . . . . . 5-9
           5.4.1.10  UUCP_PUBLIC  . . . . . . . . . . . . . . . . . . 5-9
           5.4.1.11  Other Directory Specifications . . . . . . . .  5-10
   DECUS UUCP Version 2.0 System Manager's Guide                  Page vi



           5.4.1.12  UUCP_BATCH_NODE  . . . . . . . . . . . . . . .  5-10
           5.4.1.13  UUCP_BATCH_UUCICO_CALLOUT_JOBS . . . . . . . .  5-10
           5.4.1.14  Other Entries  . . . . . . . . . . . . . . . .  5-11
           5.4.2     "Activating" the Control File  . . . . . . . .  5-11
           5.5     Create The UUCP Systems File . . . . . . . . . .  5-11
           5.5.1     <hostname> field . . . . . . . . . . . . . . .  5-12
           5.5.2     <entry-name> field . . . . . . . . . . . . . .  5-13
           5.5.3     <luser> field  . . . . . . . . . . . . . . . .  5-13
           5.5.4     <protocols> field  . . . . . . . . . . . . . .  5-14
           5.5.5     <options> field  . . . . . . . . . . . . . . .  5-14
           5.5.5.1   c - callback   . . . . . . . . . . . . . . . .  5-14
           5.5.5.2   p - parity during login script . . . . . . . .  5-14
           5.5.5.3   x - debug bits . . . . . . . . . . . . . . . .  5-15
           5.5.5.4   b and w - buffer and window sizes  . . . . . .  5-15
           5.5.5.5   Specifying Multiple <option>s  . . . . . . . .  5-15
           5.5.6     <when> field . . . . . . . . . . . . . . . . .  5-16
           5.5.6.1   <days> . . . . . . . . . . . . . . . . . . . .  5-16
           5.5.6.2   [times]  . . . . . . . . . . . . . . . . . . .  5-16
           5.5.6.3   Multiple Day and Time Intervals  . . . . . . .  5-17
           5.5.6.4   Recall Time Restrictions (success, fail, and 
                     poll)  . . . . . . . . . . . . . . . . . . . .  5-17
           5.5.6.4.1 Success recall interval  . . . . . . . . . . .  5-17
           5.5.6.4.2 Fail recall interval . . . . . . . . . . . . .  5-17
           5.5.6.4.3 Poll recall interval . . . . . . . . . . . . .  5-17
           5.5.6.5   Grade restrictions . . . . . . . . . . . . . .  5-18
           5.5.6.6   Examples of valid <when> fields  . . . . . . .  5-18
           5.5.7     <Port Name> field  . . . . . . . . . . . . . .  5-20
           5.5.8     <Speed> field  . . . . . . . . . . . . . . . .  5-20
           5.5.9     <Phone Number> field . . . . . . . . . . . . .  5-21
           5.5.10    <Login Script> field . . . . . . . . . . . . .  5-21
           5.5.11    <Str0>...<Str7> fields . . . . . . . . . . . .  5-21
           5.5.12    Interaction Between The Systems File and Your 
                     Map Entry  . . . . . . . . . . . . . . . . . .  5-21
           5.6     Script Files . . . . . . . . . . . . . . . . . .  5-22
           5.6.1     Dial Scripts . . . . . . . . . . . . . . . . .  5-22
           5.6.2     Login Scripts  . . . . . . . . . . . . . . . .  5-23
           5.6.3     Hangup Scripts . . . . . . . . . . . . . . . .  5-23
           5.7     Summary  . . . . . . . . . . . . . . . . . . . .  5-24


   CHAPTER 6       THE SCRIPT LANGUAGE

           6.1     Script File Format . . . . . . . . . . . . . . . . 6-1
           6.2     Script File Statements . . . . . . . . . . . . . . 6-2
           6.2.1     Action Statements  . . . . . . . . . . . . . . . 6-2
           6.2.1.1   Termination and informational statements . . . . 6-2
           6.2.1.2   Sending data . . . . . . . . . . . . . . . . . . 6-2
           6.2.1.3   Special terminal control statements  . . . . . . 6-3
           6.2.1.4   Counting, branching, and testing statements  . . 6-3
           6.2.2     Waitfor Statements . . . . . . . . . . . . . . . 6-4
           6.3     Script Processing Details  . . . . . . . . . . . . 6-4
           6.3.1     Extended Strings . . . . . . . . . . . . . . . . 6-4
           6.3.2     String Parameters  . . . . . . . . . . . . . . . 6-5
           6.3.3     "Wait" and "Pause" Characters in Dial Strings  . 6-5
           6.3.4     Default Timeouts for Dial Strings  . . . . . . . 6-6
           6.3.5     Trailing Carriage Returns Not Assumed  . . . . . 6-6
   DECUS UUCP Version 2.0 System Manager's Guide                 Page vii



           6.3.6     Expecting Ambiguous Strings  . . . . . . . . . . 6-6
           6.3.7     Parity . . . . . . . . . . . . . . . . . . . . . 6-7
           6.3.8     The HOSTSYNC Characteristic  . . . . . . . . . . 6-8
           6.3.9     Ambiguous Labels . . . . . . . . . . . . . . . . 6-8
           6.3.10    Overriding Defaults  . . . . . . . . . . . . . . 6-8
           6.4     Written Any Good Scripts Lately? . . . . . . . . . 6-9


   CHAPTER 7       FINISHING AND TESTING THE INSTALLATION OF UUCP

           7.1     Check SYSGEN Parameters  . . . . . . . . . . . . . 7-1
           7.2     File Protection  . . . . . . . . . . . . . . . . . 7-1
           7.3     Define UUCP Logical Names  . . . . . . . . . . . . 7-1
           7.4     Generating The Path Data Base  . . . . . . . . . . 7-2
           7.5     Start It Up  . . . . . . . . . . . . . . . . . . . 7-2
           7.6     Test It  . . . . . . . . . . . . . . . . . . . . . 7-3
           7.7     If The Call Doesn't Work . . . . . . . . . . . . . 7-3
           7.8     If the Call Goes Through but the Mail Doesn't  . . 7-4
           7.9     Make it Automatic  . . . . . . . . . . . . . . . . 7-5
           7.10    Note For Cluster Users . . . . . . . . . . . . . . 7-5
           7.11    Tell Your Users  . . . . . . . . . . . . . . . . . 7-5
           7.12    Tell The World . . . . . . . . . . . . . . . . . . 7-6
           7.13    Tell Us  . . . . . . . . . . . . . . . . . . . . . 7-6
           7.14    Obtaining Current Maps . . . . . . . . . . . . . . 7-6
           7.15    Adding More Neighbors  . . . . . . . . . . . . . . 7-7


   CHAPTER 8       TROUBLESHOOTING UUCP

           8.1     How It Works . . . . . . . . . . . . . . . . . . . 8-1
           8.1.1     The Basics . . . . . . . . . . . . . . . . . . . 8-1
           8.1.2     Details: B, X, C, and D Files  . . . . . . . . . 8-2
           8.1.3     Locks  . . . . . . . . . . . . . . . . . . . . . 8-2
           8.1.4     Uucp Protocol Details  . . . . . . . . . . . . . 8-3
           8.2     Log Files  . . . . . . . . . . . . . . . . . . . . 8-3
           8.2.1     UUCP.LOG . . . . . . . . . . . . . . . . . . . . 8-3
           8.2.1.1   UUCP.LOG Entry Format  . . . . . . . . . . . . . 8-3
           8.2.1.1.1 Program Name . . . . . . . . . . . . . . . . . . 8-4
           8.2.1.1.2 Call Progress and Direction Indicator  . . . . . 8-4
           8.2.1.1.3 Hostname . . . . . . . . . . . . . . . . . . . . 8-4
           8.2.1.1.4 Date, Time, and PID Stamp  . . . . . . . . . . . 8-4
           8.2.1.1.5 Error Indicator  . . . . . . . . . . . . . . . . 8-5
           8.2.1.1.6 Event Description  . . . . . . . . . . . . . . . 8-5
           8.2.1.1.7 Username . . . . . . . . . . . . . . . . . . . . 8-5
           8.2.1.2   Hints on Log File Interpretation . . . . . . . . 8-5
           8.2.1.2.1 Time Sequencing  . . . . . . . . . . . . . . . . 8-6
           8.2.1.2.2 Throughput . . . . . . . . . . . . . . . . . . . 8-6
           8.2.1.2.3 Benign "Errors"  . . . . . . . . . . . . . . . . 8-6
           8.2.1.2.4 Sys$Assign: No Privilege For Attempted Operation 8-7
           8.2.1.2.5 Entry Names Vs. System Names . . . . . . . . . . 8-7
           8.2.1.2.6 Using "SEARCH" . . . . . . . . . . . . . . . . . 8-7
           8.2.2     The Debug Log File . . . . . . . . . . . . . . . 8-8
           8.2.2.1   Setting Debug Levels . . . . . . . . . . . . . . 8-9
           8.2.2.1.1 Outbound Calls . . . . . . . . . . . . . . . . . 8-9
           8.2.2.1.2 Inbound Calls  . . . . . . . . . . . . . . . . . 8-9
           8.2.2.2   Where Does The Debug Log Go? . . . . . . . . . . 8-9
   DECUS UUCP Version 2.0 System Manager's Guide                Page viii



           8.2.2.2.1 Inbound Calls  . . . . . . . . . . . . . . . .  8-10
           8.2.2.2.2 Outbound Calls . . . . . . . . . . . . . . . .  8-10
           8.2.3     SYS$ERROR  . . . . . . . . . . . . . . . . . .  8-10
           8.2.4     Status Files . . . . . . . . . . . . . . . . .  8-11
           8.2.5     UUXQT's Batch Log  . . . . . . . . . . . . . .  8-11
           8.2.6     Other Sources of Information . . . . . . . . .  8-11
           8.2.6.1   The Dump . . . . . . . . . . . . . . . . . . .  8-11
           8.2.6.2   Temporary Files in the Spool Directory . . . .  8-12
           8.2.6.3   The VMS Accounting File  . . . . . . . . . . .  8-12
           8.2.6.4   Process Names  . . . . . . . . . . . . . . . .  8-13
           8.2.6.5   UUCP_STATUS Logical Name . . . . . . . . . . .  8-13
           8.2.6.6   Tail . . . . . . . . . . . . . . . . . . . . .  8-13
           8.2.7     "Expected Problems"  . . . . . . . . . . . . .  8-13
           8.2.8     Restarting the Batch Jobs  . . . . . . . . . .  8-14
           8.2.9     "MicroVAX Crashes While Running DECUS uucp"  .  8-15


   CHAPTER 9       UUCP FILE TRANSFERS

           9.1     Introduction . . . . . . . . . . . . . . . . . . . 9-1
           9.1.1     The UUCP Command . . . . . . . . . . . . . . . . 9-1
           9.2     Directories  . . . . . . . . . . . . . . . . . . . 9-2
           9.3     Directory Listings . . . . . . . . . . . . . . . . 9-5
           9.4     ACL-Based Security in the UUCP_PUBLIC Tree . . . . 9-5
           9.5     Security Issues  . . . . . . . . . . . . . . . . . 9-6
           9.5.1     Files Sent By Your Users . . . . . . . . . . . . 9-6
           9.5.2     Files Requested By Your Users From Other Systems 9-7
           9.5.3     Files Sent To You By Other Sites . . . . . . . . 9-7
           9.5.4     Files Requested By Other Sites . . . . . . . . . 9-7
           9.5.5     Special Considerations for the UUCP_PUBLIC Tree  9-7
           9.6     Unix UUCP Compatibility Issues . . . . . . . . . . 9-8
           9.6.1     Stream Files . . . . . . . . . . . . . . . . . . 9-8
           9.6.2     Lower Case in File Names . . . . . . . . . . . . 9-8


   CHAPTER 10      REGISTERING AS AN INTERNET DOMAIN

           10.1    Why Should I Become a Domain?  . . . . . . . . .  10-1
           10.1.1    Acquiring an "@-style" Address . . . . . . . .  10-1
           10.1.2    Better Mail Connectivity . . . . . . . . . . .  10-1
           10.1.3    Supporting an Internal Network . . . . . . . .  10-2
           10.2    Why Do I Need A Forwarder? . . . . . . . . . . .  10-2
           10.3    How Do I Register? . . . . . . . . . . . . . . .  10-3
           10.4    What Then? . . . . . . . . . . . . . . . . . . .  10-4
           10.4.1    Update Your Map Entry  . . . . . . . . . . . .  10-4
           10.4.2    Change Logical Names . . . . . . . . . . . . .  10-5
           10.4.3    Publish Your New Address . . . . . . . . . . .  10-5
           10.4.4    Set Up The Mail Address Rewrite File . . . . .  10-5
           10.4.4.1  Rule Sets  . . . . . . . . . . . . . . . . . .  10-6
           10.4.4.1.1 Inbound-To  . . . . . . . . . . . . . . . . .  10-6
           10.4.4.1.2 Outbound-From . . . . . . . . . . . . . . . .  10-6
           10.4.4.1.3 Inbound-From  . . . . . . . . . . . . . . . .  10-6
           10.4.4.1.4 Outbound-To . . . . . . . . . . . . . . . . .  10-7
           10.4.4.2  Rewrite file format  . . . . . . . . . . . . .  10-8
           10.4.4.2.1 Comments  . . . . . . . . . . . . . . . . . .  10-8
           10.4.4.2.2 Set selectors . . . . . . . . . . . . . . . .  10-8
   DECUS UUCP Version 2.0 System Manager's Guide                  Page ix



           10.4.4.2.3 Rules . . . . . . . . . . . . . . . . . . . .  10-8
           10.4.4.3  Suggestions for Rewrite Rules for Internet 
                     Domains  . . . . . . . . . . . . . . . . . . .  10-9
           10.4.4.4  Special Note for MX Users  . . . . . . . . . . 10-10
           10.5    What If Another Machine In My Company Is Already 
                   Registered?  . . . . . . . . . . . . . . . . . . 10-10
           10.6    Domain Names: Machines vs. Companies . . . . . . 10-11
           10.7    Special Acknowledgement  . . . . . . . . . . . . 10-12


   CHAPTER 11      GETTING READY TO RUN NEWS

           11.1    Newsgroups -- What to Carry? . . . . . . . . . .  11-1
           11.1.1    Strongly Recommended Newsgroups from the Usenet 
                     Hierarchy  . . . . . . . . . . . . . . . . . .  11-1
           11.1.2    The VMSnet Newsgroups  . . . . . . . . . . . .  11-2
           11.1.3    Others . . . . . . . . . . . . . . . . . . . .  11-2
           11.1.3.1  Telebit Newsgroup  . . . . . . . . . . . . . .  11-2
           11.1.3.2  "to." Newsgroups . . . . . . . . . . . . . . .  11-3
           11.1.3.3  Local Newsgroups . . . . . . . . . . . . . . .  11-3
           11.1.4    Decisions, Decisions . . . . . . . . . . . . .  11-3
           11.2    Arranging for News Feeds . . . . . . . . . . . .  11-3
           11.3    Feeding News to Other Sites  . . . . . . . . . .  11-4
           11.4    ANU News and DECUS uucp  . . . . . . . . . . . .  11-5
           11.5    News System Configurations . . . . . . . . . . .  11-5
           11.5.1    VAXclusters  . . . . . . . . . . . . . . . . .  11-5
           11.5.2    Independent News Machines Connected by DECnet   11-6
           11.5.3    Independent News Machines Connected by uucp  .  11-6
           11.5.4    NNTP Via DECnet  . . . . . . . . . . . . . . .  11-6
           11.5.5    NNTP Via TCP/IP  . . . . . . . . . . . . . . .  11-7
           11.5.6    NNTP with Unix Server  . . . . . . . . . . . .  11-7
           11.5.7    Variations . . . . . . . . . . . . . . . . . .  11-7
           11.6    A Bit More about NNTP  . . . . . . . . . . . . .  11-7
           11.6.1    Why Do We Send More Stuff Over Slower Links? .  11-8
           11.6.2    NNTP For Batched News Transfers  . . . . . . .  11-8
           11.6.3    Combinations . . . . . . . . . . . . . . . . .  11-8
           11.6.4    NNTP Warning . . . . . . . . . . . . . . . . .  11-8


   CHAPTER 12      INSTALLING AND INTEGRATING NEWS

           12.1    The ANU News Distribution  . . . . . . . . . . .  12-1
           12.1.1    Documentation  . . . . . . . . . . . . . . . .  12-1
           12.2    Installing News: Comments on the News User's 
                   Guide  . . . . . . . . . . . . . . . . . . . . .  12-2
           12.2.1    Installing News Files  . . . . . . . . . . . .  12-2
           12.2.2    Compiling and Linking NEWS . . . . . . . . . .  12-2
           12.2.3    Creating NEWS Accounts . . . . . . . . . . . .  12-3
           12.2.4    Define Logical Names . . . . . . . . . . . . .  12-3
           12.2.4.1  NEWS_ORGANISATION  . . . . . . . . . . . . . .  12-4
           12.2.4.2  NEWS_DEVICE  . . . . . . . . . . . . . . . . .  12-4
           12.2.4.3  NEWS_ROOT  . . . . . . . . . . . . . . . . . .  12-4
           12.2.4.4  NEWS_MANAGER, NEWS_MANAGER_DEV . . . . . . . .  12-5
           12.2.4.5  NEWS_MGR_UN  . . . . . . . . . . . . . . . . .  12-5
           12.2.4.6  NEWSMAIL, RNEWS  . . . . . . . . . . . . . . .  12-6
           12.2.4.7  USENET . . . . . . . . . . . . . . . . . . . .  12-6
   DECUS UUCP Version 2.0 System Manager's Guide                   Page x



           12.2.4.8  NEWS_MGR_ID  . . . . . . . . . . . . . . . . .  12-6
           12.2.4.9  NEWS_ADDRESS . . . . . . . . . . . . . . . . .  12-7
           12.2.4.10 NEWS_NODE and NEWS_PATHNAME  . . . . . . . . .  12-7
           12.2.4.11 NEWS_BATCH_QUEUE . . . . . . . . . . . . . . .  12-7
           12.2.4.12 NEWS_BATCH_NODE  . . . . . . . . . . . . . . .  12-8
           12.2.4.13 NEWS_EXECUTE_CONTROL . . . . . . . . . . . . .  12-8
           12.2.4.14 NEWS_AUTO_CREGRP . . . . . . . . . . . . . . .  12-8
           12.2.4.15 NEWS_TIMEZONE  . . . . . . . . . . . . . . . .  12-9
           12.2.4.16 NEWS_GMT_OFFSET  . . . . . . . . . . . . . . .  12-9
           12.2.4.17 Other Logical Names  . . . . . . . . . . . . .  12-9
           12.2.5    Create NEWS Logical Names  . . . . . . . . . .  12-9
           12.2.6    Global DCL Symbols . . . . . . . . . . . . . . 12-10
           12.2.7    Installing NEWS.EXE As a Known Image . . . . . 12-10
           12.2.8    Initial Environment  . . . . . . . . . . . . . 12-10
           12.2.8.1  Creating the NEWSMANAGER identifier  . . . . . 12-10
           12.2.8.2  Creating the directories . . . . . . . . . . . 12-10
           12.2.8.3  Copy NEWS.HLB to NEWS_ROOT . . . . . . . . . . 12-11
           12.2.9    Installing NEWS.EXE  . . . . . . . . . . . . . 12-11
           12.2.10   News Control Files . . . . . . . . . . . . . . 12-11
           12.2.10.1 NEWS.SYS . . . . . . . . . . . . . . . . . . . 12-11
           12.2.10.2 NEWS.SYSD  . . . . . . . . . . . . . . . . . . 12-13
           12.2.10.3 NEWS.DISTRIBUTION  . . . . . . . . . . . . . . 12-13
           12.2.10.4 NEWS.ALIASES . . . . . . . . . . . . . . . . . 12-13
           12.2.10.5 MAILPATHS. . . . . . . . . . . . . . . . . . . 12-13
           12.2.10.6 UUCP_BIN:NEWSSKIM.COM  . . . . . . . . . . . . 12-14
           12.2.10.7 NEWSSKIM_LOGICALS.COM  . . . . . . . . . . . . 12-14
           12.2.10.8 NEWS_ADDRESS.CNF . . . . . . . . . . . . . . . 12-14
           12.2.10.9 NEWS_POST.DEFAULTS . . . . . . . . . . . . . . 12-15
           12.2.10.10 NEWS_POST.CC  . . . . . . . . . . . . . . . . 12-15
           12.2.10.11 NEWSRC.TEMPLATE . . . . . . . . . . . . . . . 12-15
           12.2.10.12 Other files . . . . . . . . . . . . . . . . . 12-15
           12.2.11   First Time Execution of News . . . . . . . . . 12-16
           12.2.11.1 Startup  . . . . . . . . . . . . . . . . . . . 12-16
           12.2.11.2 Creating "control", "local", and "junk"  . . . 12-17
           12.2.11.3 Creating the Initial Newsgroup Set . . . . . . 12-17
           12.3    Exchanging News with Other Sites (Batch 
                   Transfers) . . . . . . . . . . . . . . . . . . . 12-19
           12.3.1    DECnet Transfers . . . . . . . . . . . . . . . 12-19
           12.3.2    UUCP Transfers (both to Unix and to VMS) . . . 12-20
           12.3.3    Ihave/Sendme Transfers via UUCP or DECnet  . . 12-21
           12.3.4    Feeding News via NNTP  . . . . . . . . . . . . 12-22
           12.3.5    Receiving a News Feed via NNTP . . . . . . . . 12-22
           12.4    NNTP Client/Server Support . . . . . . . . . . . 12-22
           12.5    Start Up the Transfer Processes  . . . . . . . . 12-22


   APPENDIX A      USING TELEBIT MODEMS

           A.1     Serial Port Requirements . . . . . . . . . . . . . A-1
           A.2     Goals  . . . . . . . . . . . . . . . . . . . . . . A-2
           A.3     Modem Settings . . . . . . . . . . . . . . . . . . A-3
           A.4     Setting it Up  . . . . . . . . . . . . . . . . . . A-4
           A.5     Control and Systems File Entries . . . . . . . . . A-6
           A.6     Communicating with Other Telebits  . . . . . . . . A-7
           A.7     Compatibility Issues (old history) . . . . . . . . A-7
   DECUS UUCP Version 2.0 System Manager's Guide                  Page xi



   APPENDIX B      PATHALIAS (UUCP MAP FILE FORMAT DETAILS)

           B.1     Description  . . . . . . . . . . . . . . . . . . . B-1
           B.2     Uucp Map File Format . . . . . . . . . . . . . . . B-1
           B.2.1     Uucp Mapping Project Requirements  . . . . . . . B-1
           B.2.2     Network Characters . . . . . . . . . . . . . . . B-2
           B.2.3     Costs  . . . . . . . . . . . . . . . . . . . . . B-2
           B.2.4     Terminal Links . . . . . . . . . . . . . . . . . B-3
           B.2.5     Aliases  . . . . . . . . . . . . . . . . . . . . B-3
           B.2.6     Networks . . . . . . . . . . . . . . . . . . . . B-3
           B.2.7     Hidden Hosts . . . . . . . . . . . . . . . . . . B-4
           B.2.8     Preventing Routing Through Certain Hosts, Links, 
                     or Networks  . . . . . . . . . . . . . . . . . . B-4
           B.2.9     Gateways . . . . . . . . . . . . . . . . . . . . B-4
           B.2.10    Domains  . . . . . . . . . . . . . . . . . . . . B-5
           B.2.11    Smart Hosts  . . . . . . . . . . . . . . . . . . B-5
           B.3     Output Format  . . . . . . . . . . . . . . . . . . B-6
           B.4     Bugs and Deficiencies  . . . . . . . . . . . . . . B-6


   APPENDIX C      UTILITIES

           C.1     Checkaddr  . . . . . . . . . . . . . . . . . . . . C-2
           C.2     Tail . . . . . . . . . . . . . . . . . . . . . . . C-3
           C.3     Compress . . . . . . . . . . . . . . . . . . . . . C-5
           C.3.1     Synopsis . . . . . . . . . . . . . . . . . . . . C-5
           C.3.2     Description  . . . . . . . . . . . . . . . . . . C-5
           C.3.3     Options  . . . . . . . . . . . . . . . . . . . . C-5
           C.3.4     Diagnostics  . . . . . . . . . . . . . . . . . . C-6
           C.3.5     Notes  . . . . . . . . . . . . . . . . . . . . . C-7
           C.3.6     References . . . . . . . . . . . . . . . . . . . C-7
           C.4     Feedcheck - Summarize news logs  . . . . . . . . . C-8
           C.5     Uuname - Report on available uucp neigbors   . .  C-10
           C.6     Uustat - Report on and allow control of queued 
                   uucp jobs  . . . . . . . . . . . . . . . . . . .  C-11
           C.7     Uurate - Report Transfer and Connect Times for 
                   Uucp Calls . . . . . . . . . . . . . . . . . . .  C-13
           C.7.1     Synopsis . . . . . . . . . . . . . . . . . . .  C-13
           C.7.2     Description  . . . . . . . . . . . . . . . . .  C-13
           C.7.3     Options  . . . . . . . . . . . . . . . . . . .  C-13
           C.7.4     Example Output . . . . . . . . . . . . . . . .  C-13
           C.7.4.1   Example 1  . . . . . . . . . . . . . . . . . .  C-13
           C.7.4.2   Example 2  . . . . . . . . . . . . . . . . . .  C-14
           C.7.5     Notes  . . . . . . . . . . . . . . . . . . . .  C-15
           C.7.6     Bugs . . . . . . . . . . . . . . . . . . . . .  C-15


   APPENDIX D      ADDRESS FORMATS

           D.1     The Simple Cases . . . . . . . . . . . . . . . . . D-1
           D.1.1     How Do People Send Mail To Me? . . . . . . . . . D-1
           D.1.2     How Do I Send Mail Out?  . . . . . . . . . . . . D-2
           D.2     The Complex Cases  . . . . . . . . . . . . . . . . D-3
           D.2.1     Percent Signs  . . . . . . . . . . . . . . . . . D-3
           D.2.2     Mixed Uucp/Domain Addresses  . . . . . . . . . . D-4
   DECUS UUCP Version 2.0 System Manager's Guide                 Page xii



   APPENDIX E      MISCELLANEOUS QUESTIONS AND ANSWERS

           E.1     Why Are File Transfers So Slow?  . . . . . . . . . E-1
           E.2     Why Batch Jobs?  . . . . . . . . . . . . . . . . . E-2
           E.3     Why do all the uucp usernames have the same UIC? . E-3
           E.4     Why Must NEWS_MANAGER be on the same disk as 
                   NEWS_DEVICE ?  . . . . . . . . . . . . . . . . . . E-3
           E.5     I enabled long packets and large windows, but... . E-6
           E.5.1     Should I Bother Playing With This in the First 
                     Place? . . . . . . . . . . . . . . . . . . . . . E-7
           E.5.2     What Do These Values Mean? . . . . . . . . . . . E-7
           E.5.3     Advice on Twiddling Window and Buffer Size . . . E-8
           E.6     Can I "Redirect" Incoming uucp Mail via VAX MAIL's 
                   SET FORWARD mechanism? . . . . . . . . . . . . . . E-8
           E.7     Details on startup in a VMScluster . . . . . . . . E-9
           E.8     Why is UUCICO.EXE installed with CMKRNL? . . . .  E-10


   APPENDIX F      SECURITY ISSUES

           F.1     Decus Uucp Security Provisions . . . . . . . . . . F-1
           F.1.1     Directory Access . . . . . . . . . . . . . . . . F-2
           F.1.2     File Protection Masks  . . . . . . . . . . . . . F-3
           F.1.3     Priviliges and MAIL.EXE  . . . . . . . . . . . . F-3
           F.1.4     Why is UUXQT.EXE installed with SETPRV ? . . . . F-3
           F.1.5     Privileges and Uucico  . . . . . . . . . . . . . F-5
           F.1.6     "Remote Receive" Requests Disabled . . . . . . . F-5
           F.2     Things They Can Do To You  . . . . . . . . . . . . F-5
           F.2.1     Creation of Files in the Spool and Public 
                     Directories  . . . . . . . . . . . . . . . . . . F-6
           F.2.2     Non-Direct Mail is not Private . . . . . . . . . F-7
           F.2.3     Spoofing of Mail Origins . . . . . . . . . . . . F-7
           F.3     Contrast With Unix Uucp  . . . . . . . . . . . . . F-7
           F.4     The Internet Worm  . . . . . . . . . . . . . . . . F-8
           F.5     Uucp Security History  . . . . . . . . . . . . . . F-8
           F.6     Brief Summary of Configuration Differences . . . . F-9
           F.6.1     The Systems File . . . . . . . . . . . . . . . . F-9
           F.6.2     UUCP_ and NEWS_SYSTARTUP.COM   . . . . . . . . . F-9
           F.6.3     The Control File . . . . . . . . . . . . . . . . F-9
           F.6.4     Arrangement and Placement of NEWS_MANAGER 
                     directory tree . . . . . . . . . . . . . . . . . F-9
           F.7     Upgrade Procedure  . . . . . . . . . . . . . . .  F-10


   APPENDIX G      CHANGES IN VERSION 2.0 (FROM 1.3X)

           G.1     Configuration  . . . . . . . . . . . . . . . . . . G-1
           G.1.1     Expanded Role of the control File  . . . . . . . G-1
           G.1.2     Automatic Control File Generation  . . . . . . . G-1
           G.1.3     Automatic NEWS_MANAGER Reconfiguration . . . . . G-1
           G.2     UUCICO . . . . . . . . . . . . . . . . . . . . . . G-2
           G.2.1     Extended Window and Packet Sizes . . . . . . . . G-2
           G.2.2     Debug levels for incoming calls  . . . . . . . . G-2
           G.2.3     Local hostname Aliasing  . . . . . . . . . . . . G-2
           G.2.4     Filename Aliasing  . . . . . . . . . . . . . . . G-2
           G.2.5     Transfer Grade Restrictions  . . . . . . . . . . G-2
   DECUS UUCP Version 2.0 System Manager's Guide                Page xiii



           G.2.6     Multiple UUCICO Callout Daemons  . . . . . . . . G-3
           G.2.7     Work Scans . . . . . . . . . . . . . . . . . . . G-3
           G.2.8     Data Path Tests  . . . . . . . . . . . . . . . . G-3
           G.2.9     Disk Space Management  . . . . . . . . . . . . . G-3
           G.2.10    Debug Log Performance  . . . . . . . . . . . . . G-4
           G.2.11    Debug Log Formatting . . . . . . . . . . . . . . G-4
           G.2.12    File and Directory Access  . . . . . . . . . . . G-4
           G.2.13    Detailed Description of Changes to UUCP Source 
                     Files  . . . . . . . . . . . . . . . . . . . . . G-5
           G.3     UUXQT  . . . . . . . . . . . . . . . . . . . . . . G-5
           G.3.1     Multiple recipients for inbound mail . . . . . . G-5
           G.3.2     Debugging  . . . . . . . . . . . . . . . . . . . G-5
           G.4     Mail Integration . . . . . . . . . . . . . . . . . G-5
           G.4.1     UUCP Mail Handler (UUCP_MAILSHR) Bug Fixes . . . G-5
           G.4.1.1   Extra Bangs (!) in From_ Headers . . . . . . . . G-5
           G.4.1.2   Long Line Wrapping . . . . . . . . . . . . . . . G-5
           G.4.1.3   Miscellaneous Bug Fixes  . . . . . . . . . . . . G-6
           G.4.2     Mail Handler New Features  . . . . . . . . . . . G-6
           G.4.2.1   Random Access Violation in Mail Handler Solved . G-6
           G.4.2.2   Quoted strings in outbound from addresses now 
                     preserved for rewriting  . . . . . . . . . . . . G-6
           G.4.2.3   Filename Aliasing  . . . . . . . . . . . . . . . G-7
           G.4.2.4   UUCP_SPOOL Subdirectories  . . . . . . . . . . . G-7
           G.4.2.5   New Spool File Name Formats  . . . . . . . . . . G-7
           G.4.2.6   New uucico Daemon Wakeup Mechanism   . . . . . . G-7
           G.4.2.7   Expanded Image Dump Information  . . . . . . . . G-8
           G.4.2.8   Version Numbers in Mail Headers  . . . . . . . . G-8
           G.4.2.9   Additional privileges needed   . . . . . . . . . G-8
           G.5     NEWS Integration . . . . . . . . . . . . . . . . . G-9
           G.5.1     NEWS Version . . . . . . . . . . . . . . . . . . G-9
           G.5.2     Directory Structure  . . . . . . . . . . . . . . G-9
           G.5.3     Disk Space Management  . . . . . . . . . . . .  G-10
           G.5.4     Forwarding Priority  . . . . . . . . . . . . .  G-10
           G.6     Utilities  . . . . . . . . . . . . . . . . . . .  G-10
           G.6.1     UUrate (nightly uucp activity reports) . . . .  G-10
           G.6.2     Uuname . . . . . . . . . . . . . . . . . . . .  G-10
           G.6.3     Uustat . . . . . . . . . . . . . . . . . . . .  G-11
           G.6.4     FEEDCHECK (new nightly report) . . . . . . . .  G-11


   APPENDIX H      CHANGES IN VERSION 1.3X (FROM 1.2X)

           H.1     NEWS . . . . . . . . . . . . . . . . . . . . . . . H-1
           H.2     Changes in Configuration Files . . . . . . . . . . H-1
           H.3     Uucico.exe . . . . . . . . . . . . . . . . . . . . H-2
           H.4     UUCP_CONFIG.COM  . . . . . . . . . . . . . . . . . H-2
           H.5     The Mailer . . . . . . . . . . . . . . . . . . . . H-2
           H.5.1     Makepaths and PathProc . . . . . . . . . . . . . H-2
           H.5.2     Pathalias  . . . . . . . . . . . . . . . . . . . H-2
           H.5.3     UUCP_MAILSHR . . . . . . . . . . . . . . . . . . H-2
           H.5.3.1   To: Headers  . . . . . . . . . . . . . . . . . . H-2
           H.5.3.1.1 To: Headers for Multiple Addressees  . . . . . . H-2
           H.5.3.1.2 Continuation Lines in To: Headers  . . . . . . . H-3
           H.5.3.2   From: and From_ Headers  . . . . . . . . . . . . H-3
           H.5.3.2.1 Generating VMSmail From: Lines from UUCP From_ 
                     Lines  . . . . . . . . . . . . . . . . . . . . . H-3
   DECUS UUCP Version 2.0 System Manager's Guide                 Page xiv



           H.5.3.2.2 Not Generating From: Headers . . . . . . . . . . H-3
           H.5.3.3   Other Headers  . . . . . . . . . . . . . . . . . H-3
           H.5.3.3.1 X-VMS-To . . . . . . . . . . . . . . . . . . . . H-4
           H.5.3.4   Crash Dump Facility  . . . . . . . . . . . . . . H-4
           H.5.3.5   File Handling  . . . . . . . . . . . . . . . . . H-4
           H.5.3.5.1 Always Closing PATHS . . . . . . . . . . . . . . H-4
           H.5.3.5.2 Required Origin for Inbound Mail Files . . . . . H-4
           H.5.3.5.3 "X" File Contents  . . . . . . . . . . . . . . . H-5
           H.5.3.6   Miscellaneous Fixes  . . . . . . . . . . . . . . H-5
           H.5.3.6.1 Compatibility with VAX PSI . . . . . . . . . . . H-5
           H.5.3.7   Miscellaneous Changes  . . . . . . . . . . . . . H-5
           H.5.3.7.1 Change from BISON to Yacc  . . . . . . . . . . . H-5
           H.5.3.7.2 Development Direcotory Structure Changes . . . . H-5


   APPENDIX I      CHANGES IN VERSION 1.2X (FROM 1.1)

           I.1     Example Configuration Files  . . . . . . . . . . . I-1
           I.2     New Facilities . . . . . . . . . . . . . . . . . . I-1
           I.2.1     UUCP Command . . . . . . . . . . . . . . . . . . I-1
           I.2.2     Utilities  . . . . . . . . . . . . . . . . . . . I-1
           I.3     The Mailer . . . . . . . . . . . . . . . . . . . . I-2
           I.3.1     Header Processing  . . . . . . . . . . . . . . . I-2
           I.3.2     Logical Names  . . . . . . . . . . . . . . . . . I-3
           I.3.3     Address Rewriting  . . . . . . . . . . . . . . . I-3
           I.3.4     File Names and Protection  . . . . . . . . . . . I-4
           I.3.5     Username Fields in B (X) Files . . . . . . . . . I-5
           I.3.6     MAKEPATHS  . . . . . . . . . . . . . . . . . . . I-5
           I.3.7     Help file for MAIL . . . . . . . . . . . . . . . I-5
           I.4     UUCP . . . . . . . . . . . . . . . . . . . . . . . I-5
           I.4.1     Protocol Handling  . . . . . . . . . . . . . . . I-5
           I.4.2     Call Requests and Decisions  . . . . . . . . . . I-6
           I.4.3     Script Processing  . . . . . . . . . . . . . . . I-6
           I.4.4     Terminal I/O . . . . . . . . . . . . . . . . . . I-7
           I.4.5     File Handling  . . . . . . . . . . . . . . . . . I-8
           I.4.6     Configuration Files  . . . . . . . . . . . . . . I-8
           I.5     NEWS . . . . . . . . . . . . . . . . . . . . . . . I-8


   APPENDIX J      CHANGES IN VERSION 1.1 (FROM 0.2)

           J.1     Name Changes . . . . . . . . . . . . . . . . . . . J-1
           J.1.1     Logical Name Prefixes and Directories  . . . . . J-1
           J.1.2     Images . . . . . . . . . . . . . . . . . . . . . J-1
           J.1.3     Other Files  . . . . . . . . . . . . . . . . . . J-1
           J.2     Required Configuration Changes . . . . . . . . . . J-1
           J.2.1     Control File Changes . . . . . . . . . . . . . . J-1
           J.2.2     Systems File Format Change . . . . . . . . . . . J-2
           J.3     New Features . . . . . . . . . . . . . . . . . . . J-2
           J.3.1     Operational Features . . . . . . . . . . . . . . J-2
           J.3.1.1   The Mailer . . . . . . . . . . . . . . . . . . . J-2
           J.3.1.1.1 Name change  . . . . . . . . . . . . . . . . . . J-2
           J.3.1.1.2 Not-a-neighbor routing . . . . . . . . . . . . . J-2
           J.3.1.1.3 smart-host . . . . . . . . . . . . . . . . . . . J-2
           J.3.1.1.4 Local delivery . . . . . . . . . . . . . . . . . J-2
           J.3.1.1.5 From header format . . . . . . . . . . . . . . . J-3
   DECUS UUCP Version 2.0 System Manager's Guide                  Page xv



           J.3.1.1.6 Accessing the paths file . . . . . . . . . . . . J-3
           J.3.1.1.7 LongUserName . . . . . . . . . . . . . . . . . . J-3
           J.3.1.1.8 Rewrite rules  . . . . . . . . . . . . . . . . . J-3
           J.3.1.2   News Integration . . . . . . . . . . . . . . . . J-3
           J.3.1.3   Call Time Control  . . . . . . . . . . . . . . . J-4
           J.3.1.4   "On-Demand" Outbound Calls . . . . . . . . . . . J-4
           J.3.1.5   Polling  . . . . . . . . . . . . . . . . . . . . J-4
           J.3.1.6   System-Specific Debug Levels . . . . . . . . . . J-4
           J.3.1.7   Improved Log Files . . . . . . . . . . . . . . . J-4
           J.3.1.8   Login and Dialer Scripts . . . . . . . . . . . . J-4
           J.3.2     Security Features  . . . . . . . . . . . . . . . J-5
           J.3.2.1   Local Username Checking  . . . . . . . . . . . . J-5
           J.3.2.2   Callback Support . . . . . . . . . . . . . . . . J-5
           J.3.2.3   Remote File Receive Requests Disabled  . . . . . J-5
           J.4     Implementation Changes . . . . . . . . . . . . . . J-5
           J.4.1     Improved "g" Protocol Implementation . . . . . . J-6
           J.4.2     New Execution Strategies . . . . . . . . . . . . J-6
           J.5     Bug Fixes  . . . . . . . . . . . . . . . . . . . . J-6


   APPENDIX K      WANT TO HELP? 

           K.1     Version 2.0  . . . . . . . . . . . . . . . . . . . K-2
           K.2     Version 1.2x, 1.3x . . . . . . . . . . . . . . . . K-2
           K.3     Version 1.0 and 1.1  . . . . . . . . . . . . . . . K-2
           K.4     Version 0.2  . . . . . . . . . . . . . . . . . . . K-3












                               CHAPTER 0

                             INTRODUCTION



   Welcome to the fifth distribution of DECUS uucp (formerly "VMSnet
   Software"), a package which allows VMS systems to exchange mail
   with other computers using the uucp 'g' protocol.  This version
   (2.0) is being prepared for distribution via the Spring '92 US
   Symposium Tapes, and also via direct mail, the DECUS Program
   Library, and anonymous ftp.

   Most of the executable images in this version of DECUS uucp were
   built under VMS Version 5.4 or 5.5, and all are known to run
   under 5.4.  Some DCL command procedures depend on features that
   appeared in VMS V5.2.  To the best of our knowledge there is no
   code that depends on any features that appeared in VMS after
   V5.2; it should be possible to relink the object files under VMS
   Version 5.2 or any release thereafter.  We regret that we have
   not had time to prepare an easily-linked kit of object files;
   this will likely be made available sometime during Summer 1992.


   0.1  How to Read This Document

   Read all of it.  But not necessarily all at once.

   This document is less of a "user's guide", in the sense of
   instructions for end users, than a set of instructions to you,
   the prospective DECUS uucp site manager, for bringing up the
   package.  (End user instructions are provided in the form of a
   help library.)  So most of the chapters here are instructions for
   "major steps" in the procedure, and the sections and subsections
   within each chapter break the major steps into small tasks.  The
   appendices provide supplemental information for some of the
   steps.  A quick scan of the table of contents will give you a
   good idea of what you're facing.

   In addition to the table of contents, there is an index (compiled
                                                                ___
   by Earle Ake, ake@dayton.saic.com).  Also, don't forget that you
   ____ ___ ______ _______
   have the manual on-line!!!  That means that you can use the
   SEARCH utility to find things that aren't immediately obvious in
   the index or ToC.

   We have left News integration for the last chapters (not counting
   Appendices).  This is deliberate.  You are strongly encouraged to
   get uucp mail working reliably before attempting to add News.
   INTRODUCTION                                             Page 0-2
   How to Read This Document


   Do not expect to grasp all of this at one sitting, particularly
   if you are unfamiliar with uucp networking.  Skim through it
   once, perhaps on a Friday afternoon, just for the highlights.
   Come back to it Monday or Tuesday and look at it again; there
   are, inevitably, a lot of "forward references" that won't be
   filled in until you've been through it a few times.


   0.2  Special Note for Cluster Users

   If you're running a VAXcluster (CI, NI, or mixed), the usual
   setup is to run uucp on just one node.  Other nodes will still be
   able to send and receive uucp mail, but only one node will
   actually be running the uucp processes that place and receive
   calls.  If you're using a traditional terminal multiplexer, the
   "uucp node" will be the machine to which the modems are attached;
   if your modems are on LAT ports it can be any machine that can
   access the terminal server and has the other required resources.

   For now, perform all of the instructions on your intended "uucp
   node".  We'll have another "Note for Cluster Users" later on, to
   tell you how to make uucp mail available on the other nodes.  (If
   you're curious now, see the index entry for "Cluster Users".)


   0.2.1  Special Note Regarding Multiple Queue Files

   The uucp startup procedures assume that you have a single
   cluster-wide queue database (JBCSYSQUE.DAT, or QMAN$MASTER.DAT).
   They will not work entirely correctly on a cluster if you have
   more than one queue file.  Things will work fine on the uucp
   node, but the startup procedures will also attempt to start the
   uucp batch jobs on the other nodes (because they won't be able to
   see that the jobs have already been started).  Since the real
   queues won't exist, these extra jobs will stay in the "starting"
   state forever.

   This situation (separate queue files for each cluster node) is
   essentially impossible for us to detect, and even more difficult
   to support, so if you are running your cluster this way you are
   essentially on your own.

   Multiple queue files have never been a supported feature of VMS,
   "it just happened to work after a fashion, but when it failed it
   was not pretty" -- Simon Szeto, szeto@zko.mts.dec.com.


   0.3  How To Get More Help

   0.3.1  Everything You Wanted To Know About uucp (Mostly Under
          Unix, Though)

                                              _____ ____ ___ ______
   We strongly urge you to purchase the books Using uucp and Usenet,
   ________ ____ ___ ______      _____  _ _________ __ __________
   Managing uucp and Usenet, and !%@::  A Directory of Electronic
   ____ __________ ___ ________
   Mail Addressing and Networks.  These say nothing about running
   uucp on VMS; they are strictly for the Unix user and system
   INTRODUCTION                                             Page 0-3
   How To Get More Help


   manager (or "administrator", as they're known in that
   domain). [2]  But if you are at all unfamiliar with uucp
   networking, these books will help put you on common speaking
   terms with the people with whom you may well be establishing your
   first uucp connections.  All three of us have copies of both
   books, and refer to them often.

   The books may be ordered directly from the publisher:

|          O'Reilly And Associates
|          103 Morris Street, Suite A
|          Sebastapol, CA 95472
|          1-800-338-6887
|          1-707-829-0515
|          1-707-829-0104 (fax)

   They will accept phone orders using Visa, MC, and AmEx.
   Well-stocked technical or computer bookstores may also carry
   these titles.  (Disclaimer:  We have no financial interest in any
   part of this.)

   If you have access to the documentation for a Unix, Ultrix, or
   similar system, look for a paper titled "Uucp Implementation
                                             _____________ _________
   Description" by D. A. Nowitz.  (Check the Supplementary Documents
   volumes, if present.)

   The article "HoneyDanBer UUCP -- Bringing Unix Systems into the
   Information Age" by Bill Rieken and Jim Webb has a very
   interesting description of the most recent Unix implementation of
   uucp.  It appeared in Volume 1, Numbers 3 and 4 (May/June and
                         _______
   July/August, 1986) of ;login:, the journal of the Usenix
   Association.


   0.3.2  Don't Call Us, At Least Not Very Often

   We really hate to have to say this, but we have to say this:

           WE, THE AUTHORS, CANNOT PROVIDE MUCH TELEPHONE
           SUPPORT FOR THIS SOFTWARE.

   Our respective employers do support these efforts, because
   network connections are good things to have and the work is
   related to the rest of what we do.  But this is very much a
   "spare time" activity; it doesn't make any money.  If we start
   getting phone calls to the extent that our real work is
   interfered with, we may be asked to stop working on DECUS uucp
   entirely, and to refuse all telephone calls relating to it.  And
   we really would like to stay open to those (hopefully few) phone
                                             ______
   calls that you just have to make when you really get stuck!

                        ___
   So, please:  Exhaust all other avenues before calling us.  Okay?
   ____________________

   [2]  The publisher, to their credit, has expressed an interest in
   incorporating VMS-related material in future editions.
   INTRODUCTION                                             Page 0-4
   How To Get More Help


   Look at it this way:  If you haven't had a uucp connection to
   your VMS machine in the past, it's doubtful that the world will
   end if you don't have one the day after you restore the
   distribution tape to disk.  Go home, forget about it, and come
   back to it the next day.  (If you're like us, the answer will
   come to you while you're brushing your teeth the next morning.)

   If you're still stuck after a week or so (and other options --
   see below -- haven't proven fruitful), go ahead and call.  We
                                  ___
   didn't say we couldn't provide any support, just that we can't
   take too much time away from our jobs to do so.

                   ____
   Of course, we'd love to hear success stories.  But even "Hey!  I
   got it running on the first try!" calls will be a problem if we
   start getting a dozen or two a day.  When you do get connected,
   send us mail!


   0.4  On-Line Help

   If you do need to ask us for help, there are ways to contact us
   other than by phone.


   0.4.1  Via The Network

   Of course if you could get connected you wouldn't need help,
   but...  try to obtain a "guest" account on one of your neighbor
   machines, and use it to send mail to one (or all) of us.  Our
   network addresses are listed on the front page.  This will give
   you the fastest response, and probably a better response than if
   you just call by phone, at least if you have a problem we haven't
   seen before.


   0.4.2  DECUServe

   You are urged to sign up with DECUServe, DECUS's dial-up on-line
   conferencing system.  Topic 58 in the PUBLIC_DOMAIN_SOFTWARE
   conference is devoted to announcements, bug reports, and bug
   fixes relating to DECUS uucp, ANU News, related software, and
   sites running same.  A query posted there will usually be
   answered within a day or two.

   To join DECUServe, send a note to

           DECUS -- DECUServe Processing
           219 Boston Post Road, BPO2
           Marlboro, MA 01752-1850

   and ask for an application form.

   DECUServe's dialin numbers are in the Boston area, and are
   reachable via PC-Pursuit, so phone costs should not be
                                                ______
   prohibitive.  DECUServe is also reachable by telnet connections
   on the Internet (eisner.decus.org).
   INTRODUCTION                                             Page 0-5
   On-Line Help


   0.4.3  "Pageswapper" Notes System

   You may also, or instead, wish to acquire an account on Larry
   Kilgallen's "Pageswapper" VAXnotes system.  This is free (except
   for phone line time charges).  To obtain an account, call
   1-617-262-6830 at 1200 bps and log in to account PAGESWAPPER (no
   password).  You will be asked to fill out an on-line account
   application, and you will likely receive your username and
   password (by US Mail) in a week or two.

   Note 1211 in the "IO" conference on Pageswapper is dedicated to
   DECUS uucp, ANU News, and related issues.


   0.4.4  For More Help and Updates After It's Running

   Once you can send and receive network mail, send mail to

           vmsnet-request@drycas.club.cc.cmu.edu

   requesting to be placed on the "VMSnet mailing list".  (Note that
   that's a hyphen, not an underscore, in "vmsnet-request".)  To
   send items to the list itself, send mail to

           vmsnet@drycas.club.cc.cmu.edu

   and they'll be relayed to everyone else who has signed up.

   Once you have News running, if you carry the VMSnet newsgroup
   hierarchy (to be described), you can resign from the mailing list
   if you prefer, as the vmsnet.uucp newsgroup is gatewayed to the
   list.

                                 NOTE

           Once you have access to News or to the vmsnet
                         ______
           mailing list, please send help requests there
           rather than via personal mail to us.  There is
           always the chance that you have a problem which
           we haven't seen but which somebody else out there
           has -- so by sending it to the mailing list or to
           News, you increase the chances of reaching
           someone who can help.  You also give all the
           other News and mailing list readers the chance to
           see and understand a problem which they might
           encounter in the future.



   0.5  Squeaky Wheels Get The Grease

   Now, having done our best to discourage certain types of
                                      ______ __
   interruptions, we must say that we really do want those problem
   reports!  If any aspect of this package doesn't work, please
   don't just put it aside and forget about it!  We have found and
   fixed all the bugs that became evident in our test
   INTRODUCTION                                             Page 0-6
   Squeaky Wheels Get The Grease


   environments -- but obviously we can't test everything under all
   possible "real world" situations.

       We can only correct problems which are reported to us!

   This is even true -- or perhaps especially true -- of problems in
   this manual.  Our goal is to make this software as easy to use as
   possible, and the manual plays a big part in that.  The text here
   makes sense to us, but then we're obviously very familiar with
   the software being described.  So any suggestions -- from
   pointing out typos, through ideas for organizational changes, to
                                                       _______
   text to be included in the next edition -- would be greatly
   appreciated.












                               CHAPTER 1

                       CONCEPTS AND TERMINOLOGY



   This chapter will attempt to provide background information for
   those unfamiliar with uucp networks in general or with DECUS uucp
   in particular.


   1.1  The Basics

   In the Unix world, "uucp" means "Unix to Unix Copy".  (We now
   prefer to think of it as "uucp to uucp copy".)  This is the name
   for a set of programs which allow Unix systems to copy files to
   one another over (mostly) dialup telephone links.  Several
   different link-level protocols, identified by single letters, are
   used; over dial-up links, the "g" protocol is most common.

   On Unix, "uucp" is also a command, available at the command line
   interpreter ("shell") prompt, for requesting such a file
   transfer.

   Unix also supplies a "uux" command, for "Unix to Unix execute".
   This command accepts a shell command as an argument and copies
   this command to a neighboring system via uucp.  The shell command
   is then executed on the neighboring system.

   Uucp is used for mail transfer in the following manner:  A user
   sends mail to an address of the form "othersite!user".  Two
   files, a "data file" and an "execution file", are copied to the
   neighboring system "othersite".  Upon receipt of the execution
   file, the "uuxqt" program on the neighbor system interprets the
   execution file.  The execution file includes an "rmail" shell
   command which mails the data file to "user", the intended
   recipient.

   File transfer via uucp is limited to adjacent, or neighboring,
   systems, but mail can be sent to nonadjacent sites via "bang
   path" notation.  (So called because, when such addresses are read
   aloud, the exclamation point is pronounced as "bang".)  For
   example, if my node talks to a node called "ibm", and "ibm" in
   turn talks to "dec", and I have a friend who uses "dec" with the
   username "ken", I can send mail to ibm!dec!ken .  In this case
   the rmail program at ibm sees a "to" address of "dec!ken", and
   queues the mail back into the uucp system, exactly as if it had
   been sent to dec!ken from someone on ibm.  When it arrives in
   CONCEPTS AND TERMINOLOGY                                 Page 1-2
   The Basics


   ken's mailbox the "from" address says dec!ibm!myname -- each
   system prepends its own name to the "from" address as the mail
   passes through -- so that replies work.

   News is handled in a similar fashion, with data and execution
   files, although the routing mechanism is different.  In general,
   each site sends news items to all adjacent sites through which
   the items have not yet passed (as determined by a "path" header
   which is constructed on each item).  There are many redundancies
   and other potential sources of "loops" in the news distribution
   routes, so that a given site might receive the same news item
   from several sites, but this is taken care of by putting a unique
   identifier on each message when it is created; no machine will
   keep more than one copy of a message with a given identifier.


   1.2  What Is DECUS UUCP?

   DECUS uucp is a partial implementation of uucp facilities for VMS
   systems.  It provides support for uucp mail and news transfer,
   allowing you to join the existing uucp mail and news network.
   User-requested file transfers (the "uucp" command) are also
   available, but at present files can only be received into uucp's
   spool directory, and by default, the DECUS uucp system will not
   respond other systems' requests to receive files.  There is no
   provision for user-requested remote command execution (ie, no
   "uux" command is provided).

   At the heart of DECUS uucp is the program "uucico" which, like
   Unix's uucico, performs the actual file transfer from one machine
   to another using the "g" protocol.  About twenty other executable
   programs and command procedures provide "uuxqt", interfaces to
   mail and news, and various support functions.


   1.3  How Do I Apply To Join The Network?

   You don't; the uucp network has no central authority.  You join
   the network by finding one or more (hopefully) nearby sites with
   whom your uucp machine will exchange phone calls.  Information
   provided with DECUS uucp (in this document and elsewhere) will
   help you find such a site.

   There are two optional steps you can take to make it easier for
   other sites to send mail to you.  First, you are strongly
   encouraged to publish your "uucp map entry".  This is a
   description of your uucp connections (sites you exchange phone
   calls with) in a well-defined format.  "Publishing" it consists
   of mailing it to a special mailbox at rutgers, making it
   available to the "UUCP Mapping Project" (all volunteers).  Soon
   it appears in a special newsgroup in the network news and is
   used, automatically, to update each uucp host's routing tables.
   The result of all that is that uucp sites running "smart mailers"
   (which includes DECUS uucp sites) can simply send mail to
   alan@frisbie (or whatever), without worrying about how the mail
   will get there.
   CONCEPTS AND TERMINOLOGY                                 Page 1-3
   How Do I Apply To Join The Network?


   Going one step farther, you can register all the machines you
   control as an "Internet domain".  This makes it easy for people
   on the Internet to send mail to you, again without having to find
   an Internet/uucp gateway.  It also makes it possible for you to
   allow other machines on your company's internal network to send
   and receive uucp mail, without your having to publish map entries
   for them all.

   Details on uucp maps and Internet domain registry are in
   subsequent chapters.


   1.4  How Are Mail and News Supported?

   Under DECUS uucp, VMS users send and receive uucp mail with the
   standard VMS Mail program.  To send mail to someone via uucp, a
   special form of "To:" address is used.  This function is provided
   via Mail's (undocumented) foreign mail protocol interface.  Mail
   received via uucp appears to have come from addresses of the same
   form, so that Mail's REPLY command usually works correctly.

   For news, DECUS uucp includes command procedures and programs for
   integration with Geoff Huston's NEWS program (commonly referred
   to as "ANU News", for Australia National University, where Geoff
   works); we will either use this term, or spell NEWS in all caps,
   when confusion between the program and news in general would
   otherwise be likely).  NEWS provides the user interface and
   implements the news database, and calls upon uucp for transfer of
   news items to and from remote sites.  (NEWS can also transfer
   news items via DECnet and several other mechanisms.)


   1.5  Netnews, Usenet, and VMSnet

   In the Unix world, "Netnews" is a coinage used to refer to the
   "Network news" in general.

   "Usenet" (User's Network) refers to the machines which carry
   news, or, more rigorously, to the machines which carry the
   newsgroups approved by the "Usenet backbone" sites.  Note that
   this is not the same as "the uucp mail network", which refers to
   the machines which use uucp to exchange mail.  For one thing, a
   lot of news is carried via means other than uucp; for another,
   many uucp links do not carry news, but only mail.  Many people,
   however, mistakenly say "Usenet" when they should be saying "the
   uucp network", or just "the net".  (Occasionally the distinction
   is important, but not usually.)

   Analogously, we have coined the term "VMSnet" to refer to sites
   running this software and exchanging the newsgroups in the
   "VMSnet hierarchy".  More information on this is in the chapters
   on News integration.  (We previously referred to the software
   itself as "the VMSnet software", but later realized that when
   people went looking for "uucp for VMS" in the DECUS Program
   Library catalog they wouldn't be likely to trip over "VMSnet".)
   CONCEPTS AND TERMINOLOGY                                 Page 1-4
   Internet...


   1.6  Internet...

   "The Internet" is a conglomeration of machines talking to one
   another over hardwired point-to-point links, LANs, leased lines,
   packet-switching networks, and so on, using TCP/IP protocols.
   They share a common node address space, and addresses are
   coordinated and registered with a central authority, the Network
   Information Center at SRI in Menlo Park, California.  Internet
   includes what used to be called Arpanet, that part of the Arpanet
   which is now called Milnet, and many others.

   For administrative purposes, the Internet is divided into
   hierarchies called "domains".  (The "administrative" distinction
                             ___
   is important.  Domains do not, in general, reflect connectivity.)
   There is a "top-level" domain for each foreign country, with the
   domain name derived from the ISO country name code.  Within the
   United States there are several top-level domains with names like
   ".com" (commercial institutions), ".edu" (educational), and
   ".mil" (military).  A typical system name within the Internet is

           arisia.dnet.ge.com

   and a typical mail address is

           everhart@arisia.dnet.ge.com

   where "ge" is a company name and "arisia.dnet" identifies a
   machine at ge. [1]

   A uucp connection does not provide "a connection to the
                                                         ________
   Internet".  However, there are numerous uucp/Internet gateways --
   machines which are connected to Internet and which also can send
   and receive mail via uucp, and which can forward mail between the
   two.  If you can get an Internet site to agree to act as your
   mail forwarder (this is usually quite easy), you can register
   your site in the domain system; Internet sites will then be able
   to easily send you mail. [2]  Thus, a uucp connection is
   sufficient to get an "Internet address" for your site and for
   everyone reachable through your site, though technically you
   won't be "an Internet site".  The chapter on "Internet Registry"
   provides more information.

   The mail routing software used on Unix systems, and ported to VMS
   as part of DECUS uucp, supports the Internet addressing syntax,
   and also allows systems that are not registered with the
   Internet -- but which are listed in the uucp maps -- to be
   ____________________

   [1]  Yes, this is Glenn Everhart, VAX SIG Tapecopy coordinator
   and member of the DECUS Library Committee.
   ____________________

   [2]  They can send you mail even if you haven't registered and
   arranged for a specific forwarder, by explicitly routing their
   mail to you through one of the better-known gateways.  But
                                  ____
   registering your site makes it much easier for them.
   CONCEPTS AND TERMINOLOGY                                 Page 1-5
   Internet...


   addressed via "Internet-style" names.


   1.7  ...And Beyond

   Collectively, the uucp mail network, the Internet, and the many
   other networks (SPAN, Bitnet, HEPNET, Digital's Easynet, and
   others) that are gatewayed into Internet, form a worldwide
   ___________
   metanetwork, which for convenience is most often called "the
   net".  An excellent (now dated, but still excellent) source of
   information about "the net" is the article "Notable Computer
                                        ______________ __ ___ ___
   Networks" by Quarterman and Hoskins (Communications of the ACM,
   Volume 29, Number 10 (October, 1986), pages 932 through 971).

                                                       ___ _______
   A much-expanded version of this material appears in The Matrix:
   ________ ________ ___ ____________ _______ _________
   Computer Networks and Conferencing Systems Worldwide by John S.
   Quarterman, published by Digital Press.  (Order number
   EY-C176E-DP; $59.95 plus tax.  Digital Press, DEC, 12 Crosby
   Drive BU0/E94, Bedford MA 01730 U.S.A.  We highly recommend this
   book.)












                               CHAPTER 2

                         INSTALLING THE FILES



   2.1  Organization of the Distribution Kit

   Most of the DECUS uucp V2.0 distribution is in a collection of
   BACKUP savesets.  This is to make it easy for you to restore just
   what you need, as well as reducing peak disk space requirements.
   In the VAX SIG Symposium tape distribution, and in network
   distributions, most of the savesets are in compressed form.

   A few files, such as this document and the utilities needed to
   uncompress and restore the savesets, are distributed as separate
   files (on the VAX SIG Symposium tapes) or are in a non-compressed
   saveset, UU20BOOT.BKP (network and magtape distributions).
   Included in this group are files with names of the form
   savesetname.BKP_LIST; these are the output of BACKUP/LIST on the
   corresponding savesets, and savesetname.ATT; these are the file
   attributes of the compressed savesets, and will be applied
   automatically by the restore procedure.  Also, the file
   UU20.DIRLIS contains the results of DIRECTORY [...] and DIRECTORY
   [...]/SIZE/TOTAL on the entire [UUCP...] tree.
   INSTALLING THE FILES                                     Page 2-2
   Organization of the Distribution Kit


   Following are descriptions of the contents of the savesets.
   Note, if the savesets are distributed in compressed form, they
   will have "-Z" appended to their names, to indicate compression
   with the supplied "compress" utility.

   -----------------------------------------------------------------
                                                        Uncompressed 
   Saveset         Contents                            Size (Blocks)
   -----------------------------------------------------------------
   UU20BOOT.BKP    (other-than-SIGtape distribution         1,600
                   only) This document, plus tools for
                   restoring the compressed savesets.

   RUN.BKP         Executables, (incl. NEWS.EXE),           6,800
                   command procs, example files, and
                   plain-text version of primary NEWS 
                   documentation

   MAPS.BKP        UUCP map files                          11,200

   SUPPDOC.BKP     Supplementary documentation              5,080

   SUPPNEWS.BKP    NNTP-related news executables; News     10,540
                   doc in LaTeX, PostScript, and RTF forms;
                   supplementary news documentation

   DEVEL.BKP       Source and object files for             13,200    
                   executables in RUN.BKP; sources
                   and executables for development
                   tools; historical sources

   NEWSDEVEL.BKP   Source and object files for              6,680 
                   executables in NEWS.BKP
   -----------------------------------------------------------------

   The compressed savesets are each about half of these figures.


   2.2  What do I need?


         o  All sites, new and existing, need RUN. and (for other
            than SIG tape distributions) UU20BOOT.

         o  New sites will likely need MAPS., unless (a) you don't
            need the maps to find potential neighbor sites and (b)
            one of your neighbors can do "smart-host" routing for
            you.  (See the index entries for "smart-host".)

            Note that these maps will be somewhat out of date by the
            time you receive this distribution.  A later chapter
            includes instructions for fetching up-to-date maps via
            uucp from uunet, via their 900-number access.  You may
            also be able to get current maps from one of your
            prospective neighbor sites.  If you can do either of
            these, you need not restore the maps that are provided
   INSTALLING THE FILES                                     Page 2-3
   What do I need?


            here.

            Existing sites who are getting current maps via news
                   ___
            should not restore the maps in the distribution, as they
            will almost certainly be older than the ones you already
            have.

         o  SUPPDOC. contains much that is useful, but no one site
            will likely need all of it.  You will probably want to
            restore it, find out what is important to you, and
            delete the rest.

         o  SUPPNEWS.:  Needed if you will be using NNTP (either in
            addition to, or instead of, uucp) news feeds, or if you
            want to (and are equipped to) print the NEWS
            documentation from LaTeX, RTF, or PostScript sources.

         o  The other two savesets are interesting only if you want
            to work on the software.


   2.3  Organization and Nomenclature

   For all future references to the directories, we will assume that
   [UUCP] is a top-level directory and that device:[UUCP] is the
   default.  For example, [UUCP.BIN] will be referred to as [.BIN].

   This directory tree is essentially a copy of the "live" tree in
   use at cmkrnl (minus, of course, our current news data base, log
   files, and sensitive information such as our neighbor systems'
   phone numbers, usernames, and passwords).  The intent is that you
   can restore the tree from the tape, edit some configuration files
   to match your site's requirements, define a few logical names to
   point to the disk containing the ufd [UUCP], and everything
   should work.

   You can change it all around if you like, but we haven't designed
   things with this in mind and have done no testing with any other
   tree structure.  In particular, though we have tried to use a
   separate logical name for each directory used at run-time, there
   may be a few assumptions lurking in the code about what
   directories are subdirectories of other directories; so if you do
   decide to reorganize things, be prepared to chase down some
   problems.


   2.3.1  "Example" Configuration Files and Command Procedures

   There are several text files which you need to edit to set things
   up for your particular environment.  Full details on this appear
   later, but for now we need to mention the location of the example
   files.

   There is a subdirectory tree, [.EXAMPLES...], which contains
   "examples" or "templates" for each such file.  For example, one
   file that uucp needs is called [.CFG]SYSTEMS.  You won't find a
   INSTALLING THE FILES                                     Page 2-4
   Organization and Nomenclature


   file called [.CFG]SYSTEMS. here, but you will find one in
   [.EXAMPLES.CFG]SYSTEMS.  You'll need to edit the latter to create
   the former, according to instructions given in a folowing
   chapter.

   The intent of this scheme is twofold:  First, you never have to
   worry about doing a PURGE and losing the original versions of any
   of these files; and second, you can install this package on top
   of an existing earlier version of DECUS uucp without having your
   "live" files supplanted by our examples.

   When installing "on top of" an existing version, you should of
   course not assume that you need make no changes in your existing
   configuration files; review the new examples, and the
   documentation here for each, to see what's changed.  The right
   thing to do in most cases will be to edit the new example file to
   create your new live file, using your old live file as a guide.

   Where we have referred to these "to be edited" files in the
   documentation, most references will be to their "live" locations,
   e.g. [.CFG]CONTROL. rather than [.EXAMPLES.CFG]CONTROL., even if
   we haven't gotten to the place in the procedures where we create
   the live file yet.


   2.4  Restoring the Files from the Savesets


                                 NOTE

           In all cases, if you are restoring into an
           existing [UUCP] tree, specify /NEW_VERSION on the
           BACKUP restore command to ensure that the files
           become the latest versions.  This is essential if
           the supplied automatic upgrade procedure is to
           work correctly.  The files in this distribution
           are arranged so that files which you have
           customized in your old distribution will not be
           superseded, except where necessary.  (The BACKUP
           command in the supplied command procedure,
           [UUCP.BIN]DECOMP_DIST_20.COM, has the
           /NEW_VERSION qualifier on it.)



   2.4.1  From the VAX SIG Symposium Tape


        1.  Restore the non-saveset files, plus the compressed
            savesets you want, to the disk of your choice.  Use a
            backup command such as

            $ BACKUP mmcu:saveset./SAVE/SELECT=[VAXnnn.UUCP...] -
             /EXCLUDE=(NEWSDEVEL.BKP-Z,DEVEL.BKP-Z) - 
             ddcu:[UUCP...]/NEW_VERSION
   INSTALLING THE FILES                                     Page 2-5
   Restoring the Files from the Savesets


            This will force the files to restore into [UUCP...].  If
            you have an existing [UUCP...] tree, restore these files
            into the current tree.

        2.  Invoke the command procedure
            [UUCP.BIN]DECOMP_DIST_20.COM .


   2.4.2  From Magtape Distributions

   Each of the savesets described above is a separate saveset on the
   tape.  Restore the ones you want, using commands such as

   $ BACKUP mmcu:RUN.BKP/SAVE ddcu:[*...]/NEW_VERSION

   The files will restore into [UUCP...].


   2.4.3  From Network Distributions


        1.  Fetch the UU20BOOT. saveset.

        2.  Restore it using a command such as

                                                         _
            $ BACKUP UU20BOOT.BKP/SAVE ddcu:[UUCP...]/NEWVERSION

            This will create [UUCP...], if it doesn't already exist.

        3.  Fetch the compressed savesets that you want (based on
            the descriptions earlier in this chapter), placing them
            anywhere within the [UUCP...] tree.

        4.  Invoke the command procedure
            [UUCP.BIN]DECOMP_DIST_20.COM .

   Proceed either to the next chapter (for new installations) or to
   the Appendix, "Upgrading from Previous Versions".












                               CHAPTER 3

                        MODEMS AND MULTIPLEXERS



   This chapter describes how to set up modems and serial lines for
   connections to uucp neighbors.  A great deal of this information
   is also applicable to modems and serial lines used for ordinary
   interactive dialin, so if you are having problems with that, keep
   reading.  (If interactive dialin doesn't work, uucp dialin won't
   work either, though uucp dialout might.)

                                 NOTE

           The following sections will discuss the need to
           change some of the terminal-related SYSGEN
           parameters.  The needs for another SYSGEN
           parameter change will be described in a later
           chapter.  Hold off on all parameter changes until
           then.



   3.1  Setting Terminal Characteristics

   The serial ports you'll use for uucp dialin and dialout may be
   configured in such a way that they are useful for ordinary
   interactive dialins as well as for uucp.


   3.1.1  Conventional Multiplexers

   The port should at least support what DEC calls "partial modem
   control".  (A later section on RS232 control signals describes
   the requirements in detail.)

   For a conventional serial port (that is, not one that comes out
   of a terminal server), all that is necessary is to an issue an
   appropriate SET TERMINAL command.  During initial setup, you can
   issue these commands "live"; when you are satisfied with the
   configuration, be sure to edit your SYSTARTUP_V5.COM (or
   equivalent) procedure to execute these commands.
   MODEMS AND MULTIPLEXERS                                  Page 3-2
   Setting Terminal Characteristics


   The following SET TERMINAL command will configure the port
   correctly:

           $ SET TERMINAL TXA1: /PERMANENT /AUTOBAUD /SET_SPEED -
                   /MODEM /DIALUP /HANGUP /DMA /NOPARITY -
                   /TYPEAHEAD /ALTYPEAHD -
                   /SYSPASSWORD /DISCONNECT -
                   /HOSTSYNC /TTSYNC /LINE_EDIT /DEVICE=VT100

   The qualifiers on the first three lines are required (with
   possible modifications as described below).

   If your modem is one (such as a Telebit) that can use a single
   locked host interface speed while making connections at various
   (lower) speeds, use /SPEED=nnnn/NOSET_SPEED instead of
   /AUTOBAUD/SET_SPEED .

   Syspassword can be used as you deem appropriate; uucp systems
   (including ours) are able to negotiate logins involving system
   passwords, so if you normally use system passwords for dialin
   lines there is no reason not to use them for uucp.

   The other qualifiers on the last two lines are for the benefit of
   interactive users who dial in through the same line used by uucp.
   Uucp changes these as appropriate (in particular, it turns off
   hostsync, ttsync, tab, etc., and sets pasthru), and changes them
   back at the end of each call.

   Along with enabling the alternate typeahead buffer on the lines
   to be used by uucp, we recommend that you raise the SYSGEN
   parameter TTY_ALTYPAHD from its default of 200 bytes to at least
   210 bytes.  (This is not a dynamic parameter, so a reboot is
   necessary for the change to take effect.)  Together with the
   /ALTYPEAHEAD characteristic, this will allow the remote system to
   send you a complete "window" of three uucp data packets (70 bytes
   each, including 6-byte headers) without overrunning the typeahead
   buffer, even if you can't get around to posting any reads for a
   while.

   This parameter change will have an utterly trivial effect on
   nonpaged pool usage (ten extra bytes will be allocated for each
   port set to /ALTYPEAHD).  If you don't make this change, and some
   characters are dropped in this fashion during a uucp transfer,
   the receiving system will simply ask the sending system to send
   the corrupted packet(s) again.  No data will be lost, but
   throughput will suffer.

   An exception to the "no data will be lost" statement above may
   occur if one or more of the systems you call display extremely
   long "banner" messages either before or after the Username (or
   login) prompt.  Since uucp's error detection and retransmission
   is not in effect at this point, these prompts (or other strings
   prior to the startup of the protocol) might be lost.  In this
   case, large typeahead buffers (enough to hold the entire banner
   at once) may be necessary.
   MODEMS AND MULTIPLEXERS                                  Page 3-3
   Setting Terminal Characteristics


                                 NOTE

           Larger values for TTY_ALTYPAHD will be needed if
           you want to use long packets and large windows.



   3.1.2  Terminal Servers

   Here we enter a moderately difficult area.  We have successfully
   run DECUS uucp with a few terminal servers.  There are, however,
   many more variations in terminal servers (and software for them)
   than there are in conventional multiplexers.  We cannot possibly
   provide setup information for all possible cases.  We will have
   to be content with describing two situations that are known to
   work.  If your situation (terminal server type, software version,
   etc.) is different, you will have to extrapolate from what is
   provided here.

   DECUS uucp is known to work with modems on DECserver 200MC ports,
   provided that:

         o  The server is running V3.0 or V3.1 of the DS200
            software.  (Earlier versions do not allow the VAX enough
            control over the port.)

         o  The modem is configured to send call progress result
            codes, in particular a success indication such as
            "CONNECT", to the local DTE, when making an outgoing
            call.  (Hayes-like modems will do this.)  This is
            desirable for all modems but absolutely essential for
            modems on LAT ports, since the VAX has no way to read
            the carrier detect signal from a LAT port.  (The modem
            must still provide a proper carrier detect signal for
            the benefit of the DECserver itself.)


   3.1.2.1  DECserver 200MC, software version 3.0

   Let's suppose you are setting up port 2 on a DECserver whose node
   name is "DSRV01".  We are assuming that the port's name has not
   been changed (in the server) from its default of PORT_3.

   Issue the following commands:

           $ RUN SYS$SYSTEM:LATCP
           CREATE PORT LTA1200: /NOLOG
           SET PORT LTA1200: /APPLICATION /NODE=DSRV01 /PORT=PORT_3
           EXIT

   (When you are confident that everything is working, place these
   CREATE and SET PORT commands in your LTLOAD.COM.)

   Now, tell the terminal server to configure the port as follows
   (Only changes from the default settings are listed):
   MODEMS AND MULTIPLEXERS                                  Page 3-4
   Setting Terminal Characteristics


              ACCESS DYNAMIC           DSRLOGOUT ENABLED
              DIALUP ENABLED           LOSS NOTIFICATION DISABLED
              DTRWAIT ENABLED          MODEM CONTROL ENABLED
           |  REMOTE MODIFICATION ENABLED

                  plus your choice of either

           |  AUTOBAUD ENABLED                                      (A)

                               or

              AUTOBAUD DISABLED  and   SPEED nnnn                   (B)

   If your modem's host interface speed "floats" according to the
   speed of the connection, use option (A).  If your modem supports
   a locked host interface speed regardless of actual connection
   speed, you can use option (B).  If the modem will operate either
   way, our preference is to avoid autobaud hassles and go with
   locked interface speeds, but your experience may be different.
   Either way, be sure to configure the modem appropriately.

   Here is the complete "LIST PORT" output from the port.  This is
   from an actual DECserver 200MC port that was successfully tested
   with DECUS uucp.  (In this case we are using a locked interface
   speed.)

       Port 3:                                Server: DSRV01

       Character Size:            8           Input Speed:       19200
       Flow Control:            XON           Output Speed:      19200
       Parity:                 None           Modem Control:   Enabled

       Access:              Dynamic           Local Switch:       None
       Backwards Switch:       None           Name:             PORT_3
       Break:                 Local           Session Limit:         4
       Forwards Switch:        None           Type:               Soft

       Preferred Service: None

       Authorized Groups:   0
       (Current)  Groups:   0

       Enabled Characteristics:

       Autoprompt,  Broadcast,  Dialup,  DSRlogout,  DTRwait,  Input
       Flow Control, Message Codes,  Output Flow Control,  
       |  Remote Modification,
       Verification

|  
|  
|  3.1.2.2  DECserver 200MC, software version 3.1
|  
|  Under DECserver 200 version 3.1, the setup is slightly different.
|  Under this release, outbound connections to LAT ports, where the
|  port to be used is defined via LATCP SET PORT ..., are now
   MODEMS AND MULTIPLEXERS                                  Page 3-5
   Setting Terminal Characteristics


   ______
|  queued.  This means that if uucp tries to allocate the LAT port
|  for an outbound call, and the port is already in use, uucp will
|  be forced to wait for five minutes (!) before finally being
|  notified that the attempt failed.  Furthermore, the error status
|  will be a "timeout" indication, which uucp interprets as
|  something more serious; the result is that even if you have
|  multiple LAT ports defined, if the first port is busy, uucp won't
|  go on to attempt to use the others.
|  
|  (There is a QUEUING DISABLED/ENABLED option for ports, but it is
|  disabled by default and doesn't appear to be what we want anyway;
|  it's for queueing inbound connection requests (from users at LAT
|  ports to services offered by hosts), not the other way around.)
|  
|  We can get around this by associating the LAT ports with LAT
|  "services".  There are just three steps.
|  
|        o  In the VMS system, the LATCP SET PORT command becomes
|  
|           LATCP> SET PORT LTAnnn /NODE=nnnn /SERVICE=servicename
|  
|           the servicename can be "MODEM1", or even "PORT2" --
|           anything that's unique within the server.
|  
|        o  In the DECserver whose name is nnnn (check via SHOW
|           SERVER):
|  
|           Local> DEFINE SERVICE servicename PORT n QUEUE DISABLED
|  
|           This relates the servicename to a physical port
|           (identified by number, not name) on the server.  QUEUE
|           DISABLED is important; the default is enabled, and the
|           queueing behavior is what we're trying to avoid.
|  
|        o  Repeat the above DEFINE SERVICE command replacing DEFINE
|           with SET.
|  
|  This method should probably work under version 3.0 also, but we
|  haven't tested it.
|  
|  If you have more than one modem on terminal servers, you can
|  define a different servicename for each, with different LTAnnn
|  device names.
|  
|  Or, you can associate a single servicename with several physical
|  ports.  Then at the VAX side, use multiple
|  
|  LATCP> SET PORT LTAnnn /NODE=nnnn /SERVICE=servicename
|  
|  commands, one per attached modem, to create multiple LTAnnn ports
|  that refer to the same servicename.
|  
|  Different servicenames should probably be used for different
|  modem types.  In other words, if you have three identical modems,
|  they should probably share the same servicename, but three
|  different modems should have three different servicenames.
   MODEMS AND MULTIPLEXERS                                  Page 3-6
   Setting Terminal Characteristics


   3.1.2.3  RS232 Control Signals and Terminal Servers

   In the following section on RS232 control signals, we mention the
   desirability of using CTS flow control with certain types of
   modems.  We have found that the DECserver 200MC ports honor CTS
   flow control even when set to the default of XON flow control.
   Since XON flow control is useful if interactive users will be
   dialing in through the modem, it is a good idea to leave it
                                       ___
   enabled.  DECUS uucp tells the port not to use XON/XOFF flow
   control while the the uucp protocol is running.


   3.1.2.4  Login Scripts

   Most uucps (including ours) have sufficient scripting ability to
   be able to log in to the server port, CONNECT to the appropriate
   service, and then log into the VAX.  You can of course use server
   options like AUTOCONNECT ENABLED, BREAK DISABLED, DEDICATED
   SERVICE, and USERNAME to simplify the connection process for
   incoming uucp calls.  This of course may reduce the usefulness of
   the port and modem for normal interactive logins.


   3.1.2.5  Typeahead Buffers

   As described in the preceding section on non-LAT ports, uucp
   needs a typeahead buffer of (at least) 210 bytes.  Enabling this
   on LAT ports presents a special problem.

   We can issue a SET TERMINAL /PERMANENT/ALTYPEAHEAD command on the
   port we've created for outbound calls (LTA1200: in the preceding
   example), but this doesn't help for incoming calls, as a new
   LTAnnnn device is created for each login -- and the alternate
   typeahead characteristic can't be enabled afterwards.  Instead it
   must be specified by setting bit 7 (hex 00000080) in the
   system-wide default terminal characteristics mask given by the
   SYSGEN parameter TTY_DEFCHAR.

                                                   ___
   This enables the alternate typeahead buffer for all terminals,
   and this in turn suggests an easier solution:  Leave TTY_DEFCHAR
                             ________
   alone, and simply set the standard typeahead buffer size
   (TTY_TYPAHDSZ to 210.  The cost in nonpaged pool space will be
   about 130 extra bytes per terminal device.


   3.1.2.6  Additional Terminal Server Considerations

|  3.1.2.6.1  LAT Circuit Timer -
|  
|  The default value for this timer is 80 milliseconds, This timer
|  is the interval that the server will wait, after getting a
|  character from one of its serial ports, before sending that
|  character in a packet to the VAX host.  Larger values for the
|  timer generally result in fewer packets sent by the server, since
|  more characters may arrive during the wait interval.  80
|  milliseconds is about as large as this timer can be before
   MODEMS AND MULTIPLEXERS                                  Page 3-7
   Setting Terminal Characteristics


|  interactive users on terminal server ports begin to notice delays
|  in the echoing of characters.  Smaller values result in packets
|  being sent more frequently to the host, increasing the load on
|  the Ethernet but possibly improving perceived response time.
|  
|  This delay strategy assumes that the source of characters coming
|  into the serial ports will be humans typing at keyboards at a
|  high average of about ten characters per second each.  A
|  high-speed modem might send data continuously at nearly 4,000
                                                      ___
|  characters per second.  Reducing the circuit timer may result in
|  improved uucp performance, by allowing the server to send data to
|  the host as soon as a complete uucp packet (normally 70 bytes)
|  has arrived.  A value of 30 is suggested.
|  
|          Local> set priv
|          Password>
|          Local> define circuit timer 30
|          Local> initialize delay 0
|  
|  This is a server-wide parameter; it cannot be specified for
|  individual lines.  If you have more than one high-speed modem, it
|  would be reasonable to put them all on the same server, and hence
|  get the most efficient use of these more frequent LAT packets.
|  (Data for multiple LAT connections to the same host can travel in
|  the same packet.)
|  
|  
|  3.1.2.6.2  The HOSTSYNC Characteristic -
|  
|  At one time, "HOSTSYNC" on a LAT connection changed the
|  out-of-band flow control mechanism.  If a port is in PASSALL mode
|  (the server calls this Pasthru mode), the server's behavior to
|  flow control changes, and the HOSTSYNC was needed to backpressure
|  the LAT link (which is bizarre because LAT is a credit-based
|  protocol, but there it is).  (This explanation is from Terry
|  Kennedy, terry@spcvxb.spc.edu)
|  
|  Accordingly, we used to enable HOSTSYNC on LAT connections.
|  Starting with Version 2.0, HOSTSYNC is enabled for outgoing calls
|  (so that the VAX can do flow control on the data from the remote
|  system, perhaps in the event that the remote has an extremely
|  long login banner) up to the time we begin the "Shere exchange".
|  It may be turned off via a script file command.  Hostsync is
|  unconditionally turned off once the Shere exchange begins (to
|  ensure a transparent data path).
|  
|  
|  3.1.2.6.3  DECserver 200's and the Data Carrier Detect (DCD)
|             signal -
|  
|  Don Stokes (don@zl2tnm.gen.nz) reports:
|          "The DS200MC, when modem control is enabled, goes deaf
|          during the transition of DCD from lo to hi.  The deaf
|          period lasts about a second or two; plenty long enough to
|          lose the "CONNECT" message from a Hayes modem, which it
|          does pretty consistently.  My standard fix for this is to
   MODEMS AND MULTIPLEXERS                                  Page 3-8
   Setting Terminal Characteristics


|          wire a cable with DCD and DSR at the DS200 end connected
|          to DSR only at the modem end.  A Hayes modem usually
|          raises DSR when it hears something that sounds like it
|          might be a carrier, and DCD when it's sure."
|  We haven't seen this problem, and in my experience Hayes modems
|  are more likely to keep DSR raised all the time (leading to "DTR
                                                 ____
|  cycling" described elsewhere).  But there are lots of modems and
|  many versions of the DECserver 200 software out there, so if you
|  are on a 200MC and your dial scripts are consistently missing the
|  "CONNECT" string from the modem, try the cable fix Don describes.


   3.2  Data Path Requirements

   For simple situations, where you and your network neighbors have
   standard modems and phone lines and you call each other, data
   path requirements are (probably) taken care of, and you can skip
   this section.  (But you should probably read it anyway, just to
   make sure that everything is ok.)

   Often it is desirable to run uucp over more complex connections
   that just happen to look like serial links at each end.  A
   typical example is a packet-switching network providing X.29 PAD
   service; you might have your VAX dial a local PAD, then connect
   through the network to the target system.  This section describes
   the pitfalls that may be encountered in such environments.

   Uucp must do all serial line I/O in what Unix calls "raw" mode,
   requiring an eight-bit-wide, fully-transparent data path.  This
   means that all 256 possible eight-bit characters, from NUL (with
   high bit clear) to DELETE (with high bit set), must be
   transferred without deletion or modification by any part of the
   link.  Even if you will only be sending mail and uncompressed
   news (in other words, plain Ascii text files), "funny
   characters", which might literally be any characters out of the
   possible 256, often appear in the packet headers.  So, no part of
   the serial link may change the high bit of each character to a
   parity bit, or clear it, or set it, or do anything else to it
   other than send it intact.

   Furthermore, no element of the serial link may add any characters
   to those sent or received, or assign any significance to any
   characters or sequence of characters.  This precludes the use of
   "inband" flow control (e.g. XON/XOFF, ENQ/ACK, etc.).  Flow
   control is not required anyway (except with special modem types;
   see below), since uucp's link-level protocol has its own flow
   control mechanisms built in.

   Many connections over packet-switching networks will violate
   these rules (by setting the high bit of each byte to be a parity
   bit, interpreting "@" characters as PAD commands unless sent
   twice, and so on) unless special steps are taken when setting up
   a call.  On the other hand, we are told that Telenet's PC
   Pursuit (tm) works fine (we haven't tried it).
   MODEMS AND MULTIPLEXERS                                  Page 3-9
   Data Path Requirements


                                 NOTE

           The following sections give detailed requirements
           for modems, serial ports, and cables to be used
           for DECUS uucp dialout and dialin.  If you
           already have some modems that are working on your
           VAX ports, they will probably work as-is; you can
           probably skip ahead to the "Testing" and
           "Summary" sections at the end of the chapter.

           Most of these considerations are not specific to
           DECUS uucp; they apply equally to modems and
           ports used for interactive dialin and dialout.



   3.3  Requirements for Serial Ports

   ("Can I connect a modem to this port?")

   At a minimum, a serial line to be used with uucp (or for ordinary
   dialin applications, for that matter) must supply a Data Terminal
   Ready (DTR) signal and must interpret Carrier Detect (CD).
                                ___
   Multiplexers that we know do not meet this requirement include
   the CXA16, ports 2 through 7 of the DMF32, the serial port on (at
   least early models of) the VAXstation 3100, and those ports on
   the MicroVAX 2000 which are implemented through modified modular
   jacks (MMJs).

   The VAX normally keeps DTR raised, but it is dropped momentarily
   in response to $QIO requests (which uucico issues at appropriate
   times, such as at the end of a call), when the assigned channel
   count for the terminal goes from nonzero to zero, and when VMS
   detects exceptions in the expected sequence of modem control
   signal transitions.  A terminal multiplexer which keeps DTR
   raised at all times, or which "pretends" that CD is raised at all
              ___
   times, can not be used with uucp.

                                 NOTE

           You can break the above rules and use a non-modem
           control port, provided that you don't allow
           inbound calls, and provided that the modem has
           some way, other than dropping DTR, for the VAX to
           get its attention and make it hang up the line.
           Hayes-like modems that honor the (one second
           pause)+++(one second pause) escape sequence fit
           the latter requirement.  You cannot use modems
           for incoming calls on a port that does not sense
           the carrier detect (CD) signal without opening a
           large security hole.  If someone calls in and
           disconnects without logging out, and the VAX
           can't detect the hangup event (which it can't if
           CD is not sensed), the user will not be logged
           out and their process will not be disconnected
           from the terminal; the next user who calls the
   MODEMS AND MULTIPLEXERS                                 Page 3-10
   Requirements for Serial Ports


           same line will end up in the previous user's
           process without having to log in.


   A later section goes into more detail on RS232 control signals.


   3.4  Requirements for Modems

   3.4.1  Result Codes

   To properly accept incoming calls, modems must not send "result
   codes" to the "local DTE" (that is, to your VAX) when incoming
   calls are being placed.


   3.4.1.1  Background

   When you are dialing out through a modem, the modem usually sends
   you result codes (such as "OK", "RINGING", "CONNECTED", etc.) to
   inform you of the progress of the call.  This is fine, and uucp's
   dial scripts use these result codes (if visible) to keep things
   in step.

   However, many modems also send similar codes to the VAX for
   ________
   incoming calls.  For example, Hayes-type modems send the word
   "RINGING" when the ring signal for an incoming call appears,
   followed by "CONNECT".


   3.4.1.2  The Problem

   The trouble is that at this point no one has a channel assigned
   to the serial port in question, and VMS responds to these codes
   as it would to any other unsolicited input:  It starts a login
   sequence.  This means that it sends a "Username:" prompt, or
   perhaps (if system passwords are enabled) just a bell, to the
                                                         ____ ___
   modem.  And the Hayes-type modems we have tested will drop the
   __________
   connection if they get data on their serial port (that is, from
   the local VAX) in the interval between detection of an incoming
   call and the establishing of carrier between the two modems.  The
   establishing of carrier does not occur for some time, often
   several seconds, after the "RINGING" message is sent to the VAX.

   The result of all this -- and the tell-tale symptom of this
   problem -- is that the modem will answer the phone and send
   carrier back to the modem that originated the call, but before
   the other system (or user) can log in, the call is dropped and
   the remote system sees the carrier go away (assuming that there
   was time to establish carrier at all).  So the modem will be
   useless for incoming calls, though outgoing ones will likely work
   fine.  (Colloquially, this is known as the "chatty modem"
   syndrome.)
   MODEMS AND MULTIPLEXERS                                 Page 3-11
   Requirements for Modems


   3.4.1.3  Solutions

   Some modems can be optioned to turn off result codes for incoming
   calls, but to automatically enable them for outgoing.  This is an
   ideal solution; owners of such modems can configure them this
   way, (hopefully) store the settings in the modem's nonvolatile
   memory (so they persist through power off/on cycles), and skip
   the rest of this section.

   A majority of Hayes-type modems have an option to turn off result
   codes entirely.  This is less desirable; we'd like to see result
   codes on outgoing calls.  Without them we have to dial the modem
   "blind", [1]  the only way we have to detect call success is
   watching for Carrier Detect (CD) to be raised after we send the
   whole dial sequence to the modem, and we can only detect dial
   failures via a timeout while waiting for CD.

   DECUS uucp addresses this through its "dial scripts".  You
   configure the modem to suppress result codes completely, so it
   works fine for incoming calls.  For outgoing calls the dial
   script tells the modem to turn result codes on as the first step
   in the dial sequence.  A corresponding "hangup script", executed
   after each call, turns them back off again.

   There is a small window of vulnerability -- if uucico dies before
   it has run the hangup script, the modem will be left with result
   codes enabled, and will be unable to accept calls.  Uucico's
   death is most often due to unexpected system shutdowns and the
   like, and we have not yet written the kernel mode image rundown
   handler necessary to deal with this situation.  For now, if uucp
   has been stopped in the midst of an outgoing call, you will have
   to reset the modem it was using manually.  (Or just wait until it
   places another call and completes it.  It doesn't matter whether
       ____
   the call completes successfully; that is, uucp will still run the
   hangup script after, for instance, a call is aborted due to a
   busy signal.)

   Some modems have a nonvolatile memory in which user-specified
   configuration parameters (different from the factory's) are
   stored, and will reset to these parameters whenever the Data
   Terminal Ready (DTR) signal from the VAX is dropped.  This is a
   good feature, as it eliminates the "window of vulnerability".
   You set up the modem to not send result codes and store this
   setting in the modem's memory.  The dial script temporarily turns
                           _____
   result codes on.  Since every call ends with DTR being dropped
   (even if someone does a STOP/ID=nnn on uucico's process), the
   modem will always be reset properly.  (See the discussion of DTR
   in a later section.)


   ____________________

   [1]  Modem manufacturers use the term "blind dialing" to refer to
   dialing without waiting for a dial tone.  We use it to refer to
   dialing without being able see the modem's response codes.  Sorry
   about that.
   MODEMS AND MULTIPLEXERS                                 Page 3-12
   Requirements for Modems


   3.4.1.4  Special Considerations for DMF32 Users

   If the modem in question is attached to port 0 or 1 of a DMF32,
                                          _______ ___ _____
   there is no problem, because the DMF32 ignores all input from the
   serial port until the modem (or whatever is attached) raises
   Carrier Detect (CD).  The ignored data is not even stored in the
   DMF32's hardware buffers, it is utterly ignored.  Of course, once
   CD is raised, it is perfectly safe for the VAX to send a
   Username: prompt to the modem.

   The bad aspect of this is that the dial procedure has to operate
   blind, since it can't see result codes.  (The script language has
   a way to detect "blind" multiplexers -- at present, the DMF32 --
   so that scripts need not expect result codes when none will be
   forthcoming.)

   A few modems, such as some models made by Racal-Vadic, can be
   optioned to use Carrier Detect normally for incoming calls, but
   to raise it immediately for outgoing calls (that is, as soon as
   the modem detects the start of the dial command sequence).  Once
   carrier is received from the other end, CD assumes its normal
   role -- that is, if carrier is lost, the modem will drop the CD
   signal, even during an outgoing call.  If available on your
   modem, this option provides a good solution to the "DMF32
   problem".  If your modem acts this way, you'll have to make sure
   that your dial script (described in later chapters) ignores the
   carrier signal from the modem, relying solely on the modem's
   result codes to determine when an outbound call succeeds.


   3.5  RS232 Control Signals

   VMS places stringent requirements on how the modem and the VAX
   port use RS232 control signals, particularly for incoming calls.
   Uucp adds a few more requirements.  In general, if you can use
   the modem and port for incoming calls, it is probably set up
   properly for uucp; but there are a few exceptions to this, as
   described below.


   3.5.1  Data Terminal Ready (DTR)

   The VAX must be able to drop DTR at the end of a call, and the
   modem must hang up the line when the VAX drops DTR.

   Many modems have a switch or setup option to "force DTR high"
   (which really means "ignore DTR and assume that it's high", since
   DTR is controlled by the local VAX, not the modem); this must be
   disabled so that the modem always obeys DTR as signalled by the
   VAX.
   MODEMS AND MULTIPLEXERS                                 Page 3-13
   RS232 Control Signals


   3.5.2  Carrier Detect (CD)

   On inbound calls, the modem should raise CD when, and only when,
   a carrier is received from the remote modem.  If carrier is
   absent, CD must be low (false).

   Many modems have an option to force Carrier Detect high, even in
   the absence of a carrier from a remote modem.  This option must
   be disabled; CD must accurately reflect the presence or absence
   of carrier.

   Some modems can be set up to use CD correctly for inbound calls,
   but to raise CD immediately for outbound calls, as soon as
   commands from the local system are recognized.  If your modem
   acts this way, you'll have to make sure that your dial script
   (described in later chapters) ignores the carrier signal from the
   modem, relying solely on the modem's result codes to determine
   when an outbound call succeeds.


   3.5.3  Data Set Ready (DSR)

   Some modems always raise DSR when they are ready to receive data
   (such as dialing commands) from the local system; others can be
   optioned to do so.  Modems to be used with VMS cannot use DSR in
   this fashion.


   3.5.3.1  DSR and Local Multiplexers

   Whenever VMS sees DSR raised, it enters a thirty second wait; if
   the modem has not raised CD and Clear To Send (CTS) by the end of
   the wait, VMS will drop DTR to the modem, forcing a hangup. [2]

   The symptom of this is that the "DTR" light on the modem will
   turn off for two seconds, every thirty seconds, when the modem is
   not in use.  If you see this happening, your modem is asserting
   DSR continuously, and you must correct this.

   This makes outward dialing difficult, since it often takes longer
   than thirty seconds for carrier to be received.


   3.5.3.2  DSR and Terminal Servers

   The DECserver 200MC will not relay characters from the modem to
   the VAX if DSR is raised in the absence of CD.  If the modem
   keeps DSR raised all the time, or if it raises it in response to
   an "attention" command (such as "AT" for Hayes-type modems), the
   VAX will be unable to see result codes from the modem.  This will
   ____________________

   [2]  This is the "timeout" exit from the "Init" state in
                                                    ___ ______
   Figure 8-1 of the Terminal Driver chapter of the I/O User's
   _________ ______
   Reference Manual.  This behavior can be overridden by the
   TTY_DIALTYPE SYSGEN parameter, but this is not recommended.
   MODEMS AND MULTIPLEXERS                                 Page 3-14
   RS232 Control Signals


   make it impossible for the uucp software to recognize when a call
   has been successfully placed to a remote modem.


   3.5.3.3  Arranging For Correct DSR Signals

   The modem should be optioned so that DSR follows CD.

   If this is not possible, the problem can be solved with an
   adapter cable or breakout box.  Disconnect the line connecting
   pin 6 (DSR) from the modem to the VAX, and jumper pin 6 to pin 8
   (CD) at the VAX side of the cable, so that DSR follows CD as far
   as the VAX is concerned.  (This of course assumes that the modem
   controls CD properly!) The following diagram should make this
   clear:

           standard wiring of DSR and CD:

           To modem                        To VAX port

            DSR (6) >--------------------> (6) DSR

             CD (8) >--------------------> (8) CD

           modified to correct for "DSR always on" problem:

           To modem                        To VAX port

            DSR (6) >--------------x  +--> (6) DSR
                                      |
             CD (8) >-----------------+--> (8) CD




   3.5.4  Clear To Send (CTS)

   If the modem's host interface speed may be faster than the
                                                     ___
   connection speed (as is true for Telebit modems), and it is to be
   used by interactive users, the serial port on the VAX needs to
   support CTS flow control, and the modem must be set up to use it.
   That is, the modem must drop CTS when its buffer for outgoing
   data is getting full, and raise CTS when the buffer is emptied.
   The VAX (or DECserver port) must stop sending data when it CTS is
   dropped, and resume sending when the modem raises CTS again.

   This is not needed for "ordinary" modems, since pairs of such
   modems behave essentially like a long piece of wire.  But if the
   modems provide buffering, data compression, error correction,
   data rate conversion, etc., the modem will on occasion need to
   tell the VAX to stop sending data for a moment.

   Flow control isn't needed during uucp connections because the
   protocol provides its own.  (This assumes that the modem's buffer
   for outgoing data can hold at least 210 bytes.)
   MODEMS AND MULTIPLEXERS                                 Page 3-15
   RS232 Control Signals


   XON-XOFF flow control between the modem and the VAX is not usable
   as it violates the "transparent data path" requirement.

   VMS supports CTS flow control with certain terminal multiplexers
   (those listed in the Terminal Driver chapter of the I/O User's
   Reference Manual, Table 8-1, as providing "full modem
   control"), [3]  and with the ports on the DECserver 200MC.


   3.5.5  Flow Control from VAX to Modem

   The VAX hardware and software do not provide any hardware flow
   control in the other direction; that is, the VAX has no way,
   other than XON/XOFF (which can't be used with uucp, so our
   software turns it off during uucp calls), to tell the modem "I'm
   busy, stop sending for a moment".  Again, this is not generally a
   problem, since uucp has its own flow control in its packet-level
   protocol.

   Special considerations apply for Telebit modems (again, see the
   relevant Appendix).

   Some modems (including the Telebits) can be optioned to use the
   Request To Send (RTS) signal from the local computer as a sort of
   reverse equivalent to CTS.  This is a nonstandard use of RTS, but
   has become somewhat common in the personal computer world.  It
   will not work with the VAX, since the VAX does not use RTS in
   this manner.  Setups which would require the use of RTS flow
   control will therefore not work with VMS.  (If your modem
                            __
   supports this option, it is safe to leave it enabled, but it
   won't accomplish anything.)


   3.5.6  Sysgen Parameter TTY_DIALTYPE

   Set the three low-order bits of this parameter to 0 unless you
   have certain knowledge that something else is required.


   3.5.7  Cabling

   ____________________

   [3]  We have also tested the DB25 serial port connector on the
   MicroVAX 2000 (TTA2: if you have the three-port expansion box),
   and found that it also supports CTS flow control, though it is
   not listed as a "full modem control" device in the VMS
   documentation.

   CTS flow control has other uses.  For instance, many third-party
   serial printers drop DTR to indicate "my buffer is full, send me
   no more data".  Accessory "black boxes" are sold which convert
   this to XON/XOFF flow control, but the printer can be used as-is
   if the terminal line used supports CTS flow control and if a
   special null modem cable which connects the printer's DTR (pin
   20) to the VAX's CTS (pin 5) is used between the printer and VAX.
   MODEMS AND MULTIPLEXERS                                 Page 3-16
   RS232 Control Signals


   The cable used to connect the modem to the VAX multiplexer must
   be a "straight through" and not a "null modem" type.  At a
   minimum, this cable must connect pins 1 through 8, 20, and 22.
   As noted previously under the discussion of the Data Set Ready
   (DSR) signal, you may need to modify this if the modem insists on
   asserting DSR all the time.


   3.6  Testing

   When you are finished, do the following if you have set up any
   new modems, or if you have never used dialout through your
   modems.

   Obtain another (compatible) modem, attach it to a terminal and
   phone line, and use it to call each of the new modems in turn.
   Make sure you can log in, do a few simple operations, and log
   out.  If you can do this, remote uucp systems will (once you've
   configured the uucp system, as described in subsequent chapters)
   be able to log in too.

   Then go back to a terminal on the VAX and do the following.  (We
   assume that the modem being tested is attached to device TXA7.)

            $ ALLOCATE TXA7
            $ SET TERM TXA7/SPEED=nnnn
            $ SET HOST/DTE TXA7

   You will now be "talking to" the VAX's modem, and it will talk
   back (unless it's on a DMF32).  Using the modem's manual, figure
   out how to send it a dial command, and tell it to dial the phone
   number of the modem from which you just called the VAX.  The
   other modem should answer, and after that, characters which you
   type at the VAX terminal should appear on the screen of the
   "remote" terminal (but will not be echoed back to you), and vice
   versa.  Type a control-backslash (^\) to disconnect, and then

            $ DEALLOCATE TXA7


   3.7  Summary

   Here is a brief list of the requirements for uucp serial links.

         o  Configure the VAX ports as you would for interactive
            dialins, but be sure to allow 210-byte typeahead buffers
            and, if the terminal multiplexer supports it, /DMA.

         o  Ensure that the modem and other elements of the link
            from your system to your network neighbors will provide
            a fully-transparent, eight-bit-wide data path.

         o  Configure the modem to not send result codes, or
            configure it to send result codes only for outgoing
            calls, or otherwise head off the "chatty modem" problem.
   MODEMS AND MULTIPLEXERS                                 Page 3-17
   Summary


         o  Ensure that your terminal port and modem correctly
            provide and interpret all of the required RS232 control
            signals.  The most frequent pitfall here is a modem that
            constantly asserts Data Set Ready (DSR).

         o  Use a straight-through cable that connects at least pins
            1 through 8, 20, and 22, unless the modem asserts DSR at
            inappropriate times, in which case a modified cable may
            be used.  (See the discussion of the Data Set Ready
            signal.)

         o  Test the modem with simple dialin and dialout
            operations.

         o  If you are using a Telebit modem, refer to the relevant
            Appendix for setup instructions.












                               CHAPTER 4

                    ARRANGING FOR UUCP CONNECTIONS



   This chapter describes three "administrative" tasks which must be
   performed before you can begin configuring DECUS uucp.


   4.1  Choose Your Host Name

   You must choose a name by which the network will know your site.
   We will refer to this as your "uucp host name", or just the "host
   name".

   Names must be unique within the first six characters.  Searching
   the map files in [.DATA.MAPSRC] is a good way to find out if your
   candidate name is already taken. [1]

   The uucp world lives almost exclusively in lower case.  The uucp
   Mapping Project (about which more later) has this to say on the
   subject of host names:

           Host names may contain the following characters:
           "a" through "z", "0" through "9", and "-" (dash).
           Fully qualified domain names may contain "."
           (dot).  No other characters, including uppercase
           alphabetics and underscore, will be accepted
           anywhere in the name.  In addition, host names
                    ___
           ...  may not end with a dash.
|  
|  Some uucp hosts use their domain names (which include dots) as
|  their uucp host name.  If either you or your neighbors do this,
|  you will need to use the various "aliasing" options in your
|  systems file entries; this is described later in this chapter.

   Your host name should be in lower case everywhere it appears in
   uucp's configuration files, and also in your "map entry"
   (described in the next chapter).  So should all other host names
   that appear in your configuration files, unless you have certain
   knowledge to the contrary.

   If your system is owned by a company, the company name (or an
   ____________________

   [1]  Murphy's Law, as applied to the theory of supply and demand:
   "All the good ones are taken."
   ARRANGING FOR UUCP CONNECTIONS                           Page 4-2
   Choose Your Host Name


   abbreviation) is a good choice; it may not be very imaginative
   but it will be easy for people to remember.

   A DECnet node name (even if converted to lower case) is probably
   not a good choice for a uucp host name:  It was likely chosen to
   be mnemonic for the machine within your company rather than for
   the company itself, and in any case the two namespaces are likely
   to overlap.  Machine-type designations (like "ucbvax", an early
   example) are to be avoided:  The type of machine you're running
   on isn't really important outside of your site, so the extra
   characters necessitate more typing without adding any
   information.

   Soon you will probably want to register your organization as an
   Internet domain, at which time your machine will acquire another
   name in the form

           sysname.orgname.com

   where sysname designates a machine within your company (and may
   in fact be a DECnet node name; this makes mail routing easier),
   orgname is likely the company name, and "com" reflects that
   you're a commercial site rather than military, educational, or
   other.  More information on this is in a later chapter.  For now
                                   ___
   we are concentrating on getting one of your machines connected to
   one or a few existing uucp systems.

   Since the maps will always be at least a little bit out of date,
   there is always the possibility that you and some other new site
   will pick the same name at the same time.  Also, there are sites
   that don't appear in the maps.  Don't worry too much about this
   at this point -- pick a unique name based on the information you
   have, and mail your map entry to the map coordinators at Rutgers
   (as described in a following section).  If there is a conflict
   you will be told, and it is easy to change your name later.  (Of
   course, if you change your name, mail sent to the old name won't
   get to you, but if your old name conflicted with somebody else's,
   your mail won't necessarily get to you anyway...)


   4.2  Finding a Neighbor

   You have to find at least one (hopefully nearby) site with which
   you will exchange uucp calls, ie, sites who are willing to become
   your "uucp neighbors".  The map files (in [.DATA.MAPSRC]) should
   give you a good start; use the DCL SEARCH command to look for
   your city name, area code, or zip code.  (The README file in the
   maps directory will explain the format of the map entries.)
   Contact the indicated system administrator at several likely
   sites.

   Remember that you will most likely be an "end node" in the uucp
   world, at least at first.  You are therefore relying on the
   generosity of many other sites to relay your mail.  If you find
   yourself exchanging a lot of mail with a particular site, arrange
   to exchange calls with them directly.  This is especially
   ARRANGING FOR UUCP CONNECTIONS                           Page 4-3
   Finding a Neighbor


   important if the other site is another of your company's offices;
   you shouldn't "do business" on other people's phone line time.

   If you are in an isolated area, your nearest neighbor may be a
   long-distance call away.  Generally l-d calls are handled on a
   cooperative basis:  People pay for the calls they place, under
   the assumption that each new site on the net will add to the
   power and usefulness of the "group mind", and a few l-d calls are
   a small price to pay for the benefits.  I've never heard of
   anybody billing anybody else for phone charges (other than psi
   and uunet, which are for-pay services anyway).

                                      __
   If your neighbor insists on making no long-distance calls, you
   can set up DECUS uucp to poll them, perhaps once a day.  For mail
   the traffic is generally low enough that no one worries about it.
   If you want a full news feed (over 20 MB/day) at 2400 bps over
   long-distance, you probably ought to volunteer to make all the
   calls.

   There are also two commercial services which provide uucp
   connections.  If you don't have a nearby site that can give you a
   high-speed connection, either of these can offer a real cost
   savings as well as good connectivity.  They are listed here in
   alphabetical order.


   4.2.1  Performance Systems International

   PSI provides connections through local dial-in numbers in a large
   number of cities around the country; you pay for the call to the
   nearest (possibly local) number, and PSI bills you a flat monthly
   fee beyond that.  They can also set up leased lines for extremely
   high-speed connections (at correspondingly higher costs, of
   course).  They can act as your Internet mail forwarder and mail
   exchanger (described later).  For information, contact

           Performance Systems International
           11800 Sunrise Valley Drive, Suite 1100
           Reston, VA 22901
           phone: (703) 620-6651
             FAX: (703) 620-4586
           email: info@psi.com


   4.2.2  UUNET

   Uunet is a commercial venture operated by one of the Unix user's
   groups.  There is a small monthly fee and access time charges,
   but uunet provides many valuable services, including archiving of
   material posted to the net, Internet domain name registry, and
   Internet mail forwarding.  They are also the best-connected news
   and mail machine in the country.  Uunet is reachable not only via
   direct dial-up lines, which all run Telebit modems, but also via
   a local call to a Tymnet PAD.
   ARRANGING FOR UUCP CONNECTIONS                           Page 4-4
   Finding a Neighbor


   Uunet also offers a "900 number" service which can be used for
   retrieving files from their archive area.  This can be used by
   anyone with uucp (including DECUS uucp) software, without prior
   arrangement with Uunet.  Some information can be found in
   [.DOC.UUNET] .

   To get complete, up-to-date information and an application form,
   send your U. S. Mail address to

           UUNET Communications Services
           P.O. Box 2685
           Fairfax, VA 22031-0685
           1-703-876-5050

   (While you're at it, ask them to send information on Internet
   domain registry as well.)


   4.3  Exchange Login Procedures

   You must exchange access information with the system manager at
   each site with whom you will exchange calls.  (See the following
   chapter for guidelines on creating the required VMS usernames.)
   On your side, this will consist of your dialup access phone
   number(s), the VMS username and password that you want the site
   to use, your system password (if you have one), and any other
   information that they need to log in to your machine.  They also
   need to give you similar information for their system.

   If you don't trust them with this information, you can arrange
   for uucp on your VMS system to call them periodically to see if
   they have work for you.  Of course, this requires that they trust
            _____
   you with their access information!  The bottom line is that,
   unless you only place outgoing calls, you and the system
   administrators at your neighbor sites have to trust each other
   with this data.

   Bear in mind that these usernames will be strictly captive
   accounts; even if an intruder learns your phone number, uucp
   login username, and password from one of your neighbors, the
   worst they will be able to do is masquerade as your neighbor,
   perhaps sending you "aliased" mail messages, or at worst filling
   up your spool directory (at their expense for the phone call, if
   long distance).  You can prevent this by using the "callback"
   feature of DECUS uucp, described in the next chapter.  (The
   Appendix on "Security Issues" has more information about DECUS
   uucp's security precautions.)

   If your prospective network neighbors are unfamiliar with VMS, or
   if you have an unusual dialin environment (perhaps your modems
   are attached to terminal servers or port selectors rather than
   directly to the VAX, requiring several steps before the dialin
   user gets to a Username:  prompt), you will also have to tell
   them how to use the username, password, etc., to log in to your
   system.  Similarly, your first network neighbors will probably be
   Unix systems, and if you aren't familiar with Unix, be sure to
   ARRANGING FOR UUCP CONNECTIONS                           Page 4-5
   Exchange Login Procedures


   get complete information for negotiating the login sequence.  A
   good way for both of you to be sure you have all of this right is
   to set up guest accounts for each other and let each other log in
   as ordinary interactive users.

   If your neighbor isn't running DECUS uucp, s/he will probably
   want to exchange "chat scripts" with you.  Explain to them that
   DECUS uucp implements the same function as chat scripts, but in a
   different way.  They will probably grumble a bit, but on the
   other hand they may be jealous if you describe our "script files"
   to them, so don't feel bad.  (If you're interested, complete
                                                    ________ ____
   information on Unix uucp chat scripts appears in Managing uucp
   ___ ______
   and Usenet.)












                               CHAPTER 5

                        CONFIGURING DECUS UUCP



   This chapter describes how to set up DECUS uucp to communicate
   with neighboring systems.


   5.1  Create the uucp Username(s)

   Create at least one UAF entry for the "uucp login".  We will
   consistently use this term to refer to the VMS username via which
                                                          ___
   your neighbors on the net will log in to your machine (not to
   users on your machine who send or receive mail or news via uucp).
   The batch jobs that are part of DECUS uucp (uucico, uuxqt, and
   uuclean) also run under this account.

   The best way to set things up is to have one account for the
   local batch jobs, one for each of your uucp neighbors, and
   another for local testing.

   The command procedure [.BIN]UUCP_CONFIG will do everything
   necessary to create these accounts.  Invoke it from an account
   that has write access to the UAF.  If you don't already have uucp
   accounts on your system, it will create them (after displaying
   its intended action and asking you if it's okay to continue), and
   then proceed to set the file ownerships and protections on files
   in the [UUCP...] tree to correspond to the new identifiers it's
   created.  If you already have some uucp accounts, do the
   following:

         o  Use option 1 to set up the account for local batch jobs
            (UUCP_DAEMON), plus a template account (UUCP_DEFAULTS)
            from which other accounts will be created.  Both of
            these will be placed in a previously-unused UIC group.

         o  Use option 3 to add an account for each of your uucp
            neighbors.


   5.1.1  Manual Account Creation

   If you prefer, you can of course set up the uucp accounts
   manually.  They should be an ordinary nonprivileged accounts
   (except for NETMBX and TMPMBX).
   CONFIGURING DECUS UUCP                                   Page 5-2
   Create the uucp Username(s)


|                                NOTE
|  
|          The material in this section has not been updated
|          to reflect the exact account quotas, etc.,
|          recommended for the current version of DECUS
|          uucp.  Up-to-date information may be obtained by
|          inspection of UUCP_CONFIG.COM .
|  

   Create a new UIC group, unused by anyone else on your system and
   outside of the system UIC group range (by default, this means the
   group number should be 11 octal or greater), for the uucp logins.
                                                              ___
   If you have more than one uucp login, they should all have the
   ____ ___
   same UIC (group and member number) and other characteristics
   (other than, of course, the username, password, and "Owner"
   fields).

   Automatic (timed) password expiration is probably a bad idea; no
   uucp (including this one) will know what to do if it logs in and
   is greeted with "Password has expired; change immediately with
   SET PASSWORD"!  Set the RESTRICTED, DISCTLY, DISMAIL, DISNEWMAIL,
   DISWELCOME, DISREPORT, and DISRECONNECT flags for the account.
   (Prior to Version 5.2, use CAPTIVE instead of RESTRICTED.) If you
   have separate accounts for your uucp neighbors, they can be set
   CAPTIVE even under 5.2 and beyond (the account for the local
   batch jobs cannot be set CAPTIVE).

   We don't know the exact minimum values for all of the UAF quotas
   that allow uucp to work.  The following are known to work: [1]

           PRCLM = 2       TQELM = 10
           PRIO = 4        ENQLM = 30
           FILLM = 30      BYTLM = 15000
           BIOLM = 18      WSDEFAULT = 1500
           DIOLM = 18      WSQUOTA = 1500
           ASTLM = 24      PGFLQUOTA = 10000

   Note that all "daemon" processes (those that run forever waiting
   for something to do, as opposed to being started only when
   there's work) purge their working sets before idling, so as not
   to tie up memory when they're not doing anything.

   Incoming uucp calls to your machine will start up fastest if you
                                                      ___
   modify your system-wide login command procedure to not print
   system announcement messages, fortune cookies, and so on when
   this user logs in, and if you suppress any SET TERMINAL/INQUIRE
   commands.  (This is not absolutely necessary; some of us make no
   such efforts and communications to our uucp neighbors work fine.
   Some uucp systems, though, will choke if they have to wade
   through several thousand characters of announcements.)

   ____________________

   [1]  There may be slight discrepancies between this list, the
   example account shown at the end of this section, and accounts
   created by UUCP_CONFIG.COM.  They'll all work, though.
   CONFIGURING DECUS UUCP                                   Page 5-3
   Create the uucp Username(s)


   The default device and directory for this account don't matter;
   you could set them to the uucp spool directory
   (UUCP_DISK:[UUCP.SPOOL]).  The LGICMD for this account must be
   UUCP_BIN:UUCP_LOGIN.COM .

   UUCP_LOGIN.COM is, of course, a captive command procedure.  For
   interactive logins it executes a single image (uucico), and when
   that image exits, the process logs out.  For batch the command
   procedure exits so the process can execute whatever command
   procedure is specified for the batch job.

   Here is how the uucp login for one of simpact's neighbors appears
   in the UAF.


   Username: UU_CRASH                         Owner:  Crash TimeSharing
   Account:                                   UIC:    [11,2] ([UUCP_LOGIN])
   CLI:      DCL                              Tables: DCLTABLES
   Default:  UUCP_DISK:[UUCP.BIN]
   LGICMD:   UUCP_LOGIN
   Login Flags:  Disctly Restricted Diswelcome Disnewmail Dismail Disreport
                 Disreconnect Captive
   Primary days:   Mon Tue Wed Thu Fri
   Secondary days:                     Sat Sun
   No access restrictions
   Expiration:            (none)    Pwdminimum:  6   Login Fails:     0
   Pwdlifetime:           (none)    Pwdchange:   3-AUG-1989 20:57
   Last Login:  8-JUN-1990 01:31 (interactive), 26-MAY-1990 21:25 (non-interactive)
   Maxjobs:         0  Fillm:        40  Bytlm:        20000
   Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
   Maxdetach:       0  BIOlm:        40  JTquota:       1024
   Prclm:           2  DIOlm:        40  WSdef:         1500
   Prio:            4  ASTlm:        50  WSquo:         2048
   Queprio:         0  TQElm:        20  WSextent:      4096
   CPU:        (none)  Enqlm:        50  Pgflquo:      10240
   Authorized Privileges:
     TMPMBX NETMBX
   Default Privileges:
     TMPMBX NETMBX


   5.1.2  Test Account

   Some of us have found it useful to create an additional uucp
   login with the same UIC and privileges, but without the CAPTIVE
   and RESTRICTED flags and with LGICMD pointing to something that
   gets you to a DCL prompt.  This "uucp test account" is not used
   for other systems to call in; in fact, you should disable dialup
   access for this account.  You will use this account to run uucp
   outgoing calls from your terminal, watching the debug output on
   your screen; this will be described later.

   If you want to create a test account with UUCP_CONFIG, use
   option 3 to create an account for a new "neighbor", and then use
   AUTHORIZE to change the LGICMD, CAPTIVE, and RESTRICTED fields.
   CONFIGURING DECUS UUCP                                   Page 5-4
   Create Your UUCP Map Entry


   5.2  Create Your UUCP Map Entry

   In the map source directory ([.DATA.MAPSRC]), create a file that
   describes your connections to your network neighbor(s).  The file
   should be called U.something; U.myhostname will do.  The README
                                                         _________
   file in [.DATA.MAPSRC], together with the Appendix on pathalias,
   describe the format for a map entry.  You should also browse
   through the existing map files to get a feel for the format.

   You'll find a file called U.cmkrnl in [.EXAMPLES.MAPSRC]; this is
   cmkrnl's "live" map entry at the time this document was prepared.
                                          ____
   You can use this as an example, but be very careful to not copy
   it verbatim into [.DATA.MAPSRC]!

   Note also that you should not place lines like

           esther = .esther.acci.com

   or

           simpact simpact.com

   in your map entry unless you are actually registered as an
   Internet domain (that will come later).

   If one of your neighbors can act as a "smart host" -- that is, if
   they can do uucp routing for you -- create another file, perhaps
   called [.DATA.MAPSRC]U.LOCAL_DATA, with the following line:

           smart-host = theiruucpname

   replacing, of course, `theiruucpname' with their actual uucp
   name.  Then delete, or save to tape and delete, all of the other
   map files (except your own).  Other "things you know about the
   net" can also appear in this file.  An example of a "local" map
   file appears in [.EXAMPLES.MAPSRC]U.CMKRNL_LOCAL .
|  
|  
|  5.3  The UUCP_SYSTARTUP.COM Command Procedure
|  
|  In previous versions of DECUS uucp, part of the configuration was
|  done by editing logical name definitions in the command procedure
|  [.CFG]UUCP_SYSTARTUP.COM.  This is no longer the case; the
|  definitions of these logical names have been moved to the
|  CONTROL. file, as described in the next section.  Most sites
|  should be able to use the supplied UUCP_SYSTARTUP.COM without
|  modification.


   5.4  Create The UUCP Control File

       _______
   The control file establishes parameters used by several parts of
   the uucp system; UUCP_SYSTARTUP, uucico, and uuxqt all read it
   upon startup. [2]  This file is supplied in template form in
   [.EXAMPLES.CFG]CONTROL. .  Please print a copy of this file, or
   have it available in an editor window, before proceeding.
   CONFIGURING DECUS UUCP                                   Page 5-5
   Create The UUCP Control File


   (Ready?  Sorry, but we'll be doing a lot of that.  It is much
   easier (not to mention less error-prone) to have you print out
   the actual files than to bring copies of them all into the text.)

   You will be editing the example file to create [.CFG]CONTROL. .
   Most sites will need to specify only a few of the possible
   entries.  We do recommend that you read the whole file to see
   what is possible.

                                 NOTE

                                                   ____
           The programs that read the control file must find
           it under the name UUCP_CFG:CONTROL. (with no
           filename extension).  There is no way to change
           this other than by editing and recompiling the
           source code.


   The format of each line in this file is extremely free-form.
   Parameter names start in column one, followed by any amount of
   whitespace (tabs and spaces), and then the value associated with
   the parameter.  There is no provision for continuing lines, but
   none should be needed as all lines are quite short.  Empty lines
   and lines starting with "!", "#", a space, or a tab, are ignored,
   and all other lines starting with unrecognized strings are simply
   skipped.
|  
|  There are additional conventions regarding comment lines that
|  begin with the "!+" or "!-" delimiters; see the comments in the
|  file for details.


   5.4.1  Control File Parameters

   The following sections describe the control file parameters which
   you will most likely need to specify for your system.  Leave the
   rest of the file as it appears in the example file unless you
   thoroughly understand the ramifications of what you are doing.

   Note that the parameters do not necessarily appear in the example
   file in the order in which they are described here.


   5.4.1.1  hostname

   ____________________

   [2]  This point is worth repeating:  The file is normally read
   ____
   only when the program starts up.  By contrast, all of the other
   files described in this chapter are read "dynamically", whenever
   the program in question needs the information in the file.  This
   is important because one element of the uucp system, the "uucico
   daemon", is intended to be started once upon system bootstrap and
   to run forevermore afterwards.  There is a way, however, to force
   the uucico daemon to read the control file anew; see "Changing
   the Control File" later in this chapter.
   CONFIGURING DECUS UUCP                                   Page 5-6
   Create The UUCP Control File


   Edit the "hostname" line to contain your chosen uucp host name.

                                 NOTE

           In Version 0.2 of DECUS uucp, the parameter name
           for this was "nodename".  We have changed it to
           avoid confusion with DECnet node names, since
           uucp host names and DECnet node names will
           generally be different.  The code in the current
           version will still accept "nodename", but will
           write a warning message in the log file.

|  
|  
|  5.4.1.2  filealias
|  
|  This entry is optional, and does not appear in the example file.
|  Most sites won't need it.
|  
|  The filealias entry is used when the local uucp hostname contains
|  one or more dots, or is otherwise unsuitable for contructing a
|  VMS filename extension; or when the hostname is longer than seven
|  characters and one or more of your uucp neighbors has a file
|  system that restricts file names to 14 characters.
|  
|  If specified, the filealias is used in place of the local
|  hostname in constructing uucp work file names.


   5.4.1.3  UUCP_DOMAIN_NAME

   This entry reflects the name of the Internet domain in which your
   machine resides.  If you are setting up uucp for the first time,
   you probably don't have a domain name yet (registering a domain
   is covered in a later chapter), in which case you should comment
   out this entry.
|  
|  
|  5.4.1.4  UUCP_POSTMASTER
|  
|  It is a network-wide convention that all sites maintain a
|  username, or at least a forwarding name, called "postmaster".
|  This allows people to send mail queries (such as "how do I reach
|  such-and-such person at your site") without knowing a username in
|  advance.  Thie UUCP_POSTMASTER entry defines the VMS username of
|  the "postmaster" at your site.  This should be someone who is
|  willing (and able) to handle problems with the uucp system and to
|  answer queries from other sites.  (The person defined as the
|  postmaster is also the recipient of a nightly summary of uucp's
|  activities.)
|  
|  At your site, this will probably be you -- the person doing the
|  uucp installation.  So, edit the entry in the example file to
|  reflect your VMS username.
   CONFIGURING DECUS UUCP                                   Page 5-7
   Create The UUCP Control File


|  5.4.1.5  UUCP_TIME_ZONE
|  
|  Edit this entry to show the time zone in which you reside.
|  (Remember to change this when your area changes from standard to
|  daylight savings time and back -- if it does.) Allowable values
|  for this, as defined by RFC822, include:
|  
|        o  the United States timezone identifiers, PST, PDT, MST,
|           MDT, CST, CDT, EST, EDT
|  
|        o  UT or GMT, both referring to Coordinated Universal Time
|  
|        o  Military designations:  1M through 1A (J not used) = -12
|           to -1 from UTC; 1N through 1Y = +1 to +12 from UTC
|  
|        o  +HHMM through -HHMM, giving the local differential in
|           hours and minutes from UTC
|  
|  
|  5.4.1.6  Debug
|  
|  The "debug" parameter specifies the classes of debug output that
|  are written to the debug log files.  It is interpreted as a
|  binary mask; each bit corresponds to a class of debug messages.
|  
|                                NOTE
|  
|          This parameter is interpreted according to the
|          syntax rules for C integer constants, meaning
                _______ ______ ____ __ _____ __ ___ ______
|          that leading zeroes (one or more) in the number
           _____ __ __ __ ___________ __ _____
|          cause it to be interpreted in octal.  If you
|          prefer hex notation, change it to the form
|          0xhhhh, where hhhh represents any number of hex
|          digits; the "x" may be in upper or lower case.
|          In either case, at least one leading zero is
|          required.  If you eliminate the leading zeroes,
|          the number will be interpreted in decimal.
|  
|  
|  The value shown (0201, meaning 201 octal) enables the basic debug
|  log (essentially a copy of the UUCP activity log) and records any
|  errors in the uucp protocol.  This is the recommended default
|  setting.  Changing the value here will change the debug output
       ___
|  for all uucp processes, and is not recommended.  There are ways
|  to add increased debug output for particular connections, such as
|  when you are setting things up with a new uucp neighbor; these
|  will be discussed later.


   5.4.1.7  Port

   Provide a "port" line for each serial line which you intend to
   allow uucp to use for dialout.  The format of this line is:

           port  <port-name> <modem-type> <vms-device> <speed> <flags>
   CONFIGURING DECUS UUCP                                   Page 5-8
   Create The UUCP Control File


                                                  ___
   The angle brackets are metacharacters; they do not appear in the
   file.

         o  As shown in the supplied example file, "port" is a
            literal string.  It must start in the first column of
            the line.

         o  <port-name> is a uucp-specific name for the port, or for
            a class of ports (which is to say that multiple port
            entries can specify the same name).  By convention we
            use "ACU" (short for Automatic Calling Unit, an archaic
            piece of AT&T hardware with which uucp was first used)
            to specify conventional autodialing modems.  Modems that
            support particular modulation schemes can be identified
            via special port-names.

            The port-name is used to match port entries with entries
            in the systems file (described in the next section).

         o  <modem-type> can be anything, but typically it is either
            "none" (for hardwired connections to other systems,
            perhaps in the same room) or the name of a type of
            modem.  If this string is anything other than "none",
            uucp uses it as the extension of the file name for dial
            and hangup scripts for the modem in question.  For
            example, with the control file shown, uucp will expect
            to find files [.CFG]DIAL.HAYES, HANGUP.HAYES, DIAL.PEPG,
            etc.  Scripts are described in detail in the next
            chapter.

         o  <vms-device> and <speed>

            The <vms-device> and <speed> are the VMS device name of
            the serial port and the bit rate which the modem (or
            neighbor systems, for hardwired links) supports.  If
            your modem supports multiple speeds (as most do), and
            you want uucp to use them, put several "ports" lines in
            the file, one for each speed.
|  
|           On a cluster, either logical names or full device names
|           of the form VS3100$TTA2:  should be used for directly
|           connected ports.  This allows for different ports to be
|           used on different nodes.  When using LAT connected
|           modems, logical names should be used in the control file
|           to refer to the ports.  These logicals should be defined
|           in the LAT procedure that creates these ports.  When
|           using LATMASTER, LATCP's CREATE PORT command has a
|           /LOGICAL qualifier which can be used to automatically
|           create the logical name without caring what the actual
|           port name that is used.

         o  <flags>

            This field is optional.  If present, it contains one or
            more characters which describe special characteristics
            of the port and/or modem.  In this version, only one
   CONFIGURING DECUS UUCP                                   Page 5-9
   Create The UUCP Control File


            flag character is defined:

            L -- specifies that the modem uses a locked host
            interface speed.  If this flag is present, uucp will not
            attempt to change the port's speed when placing an
            outgoing call, regardless of the desired speed of the
            connection.  The <speed> field is then used only to
            indicate that the port may be used for connections at
            that modulation speed.  If this option is used, the
            modem is expected to do speed conversion between the
            host interface's speed and the modulation speed.  The
            speed of the host interface is not specified here; it is
            known only to the port itself (via a SET
            TERMINAL/SPEED=nnn/PERM command, or equivalent command
            to a LAT port) and to the modem.


   5.4.1.8  sleeptime

   The "sleeptime" parameter specifies the maximum time, in minutes,
   that the uucico batch job, or "daemon", will "sleep" between
   scans for reasons to call your neighbor systems. [3]  The value
   shown, 15 minutes, seems to give a good balance between fast
   movement of work and system overhead.  (A work scan consists of
   searching the spool directory for files called C.systemname_*,
   and usually only takes a few seconds per system unless the spool
   directory is very full.)


   5.4.1.9  Enbrmtrcv

   This is short for "enable remote receive".  This line is
   commented out in the supplied example file.

   If you want to allow other uucp systems to request that your
   system send files to them, in response to user-level "uucp"
   requests (as opposed to mail or news transfers, which are always
   initiated by the system which is sending the mail or news),
   change the line in the file to appear as:

           enbrmtrcv       1

   Note that, even if this function is enabled line in the control
   file, the only directories that can be used for this function are
   those in the tree identified by the UUCP_PUBLIC control file
   entry (to be described in the next section).
|  
|  
   ____________________

   [3]  The actual mechanism used for the "sleep" is not hibernate/
   wake (as might be inferred from the term "sleep"), but waiting
   for a local event flag.  So, when the daemon is sleeping, expect
   SHOW SYSTEM to show it in LEF rather than HIB state.  Uucico does
   use hibernate/wake in the protocol module, when it is actually
   communicating with a remote system.
   CONFIGURING DECUS UUCP                                  Page 5-10
   Create The UUCP Control File


|  5.4.1.10  UUCP_PUBLIC
|  
|  This defines the root of a directory tree which may be used by
|  your uucp neighbors to send files to you, or to request files
|  from you.  (It is not used for mail or news transfers, nor for
|  file transfers from your machine that are requested by your
|  users.)
|  
|  This line of the example file is commented out, restricting your
|  uucp system to mail, news, and "push mode" file transfers (even
|  if a directory called [UUCP.PUBLIC] exists, which it does in the
|  distribution savesets).
|  
|  If you wish to allow your uucp neighbors to send files to you
|  other than mail or news, or to request files from you, uncomment
|  this line, and ensure that the directory it points to exists.
|  
|  Note that even if this directory is defined, the "enbrmtrcv"
|  capability must still be explicitly enabled in the control file
|  if your neighbors are to be allowed to request files from your
|  machine.
|  
|  Also, ACLs may be used on the directories in the UUCP_PUBLIC tree
|  to restrict access on a per-neighbor, per-directory basis, per-
|  request-type basis.  More details are in the chapter, "Uucp File
|  Transfers".


   5.4.1.11  Other Directory Specifications

   Leave the entries for "spool", "logfile", "logdir", "cfgdir",
   "debugfile", "sysfile", "userfile", "UUCP_DATA", "UUCP_DUMP",
   "UUCP_RCVDNEWS", and "UUCP_TOOLS" alone unless you don't mind
   rearranging the directory structure (and generally making things
   difficult for yourself!).


   5.4.1.12  UUCP_BATCH_NODE

   If you're in a cluster, this logical specifies the node within
   the cluster on which the UUCP batch queue will execute.  This may
   be any node which has access to the serial port(s) to which your
   modem(s) are connected.

   If you aren't running in a cluster, leave this defined as "-".


   5.4.1.13  UUCP_BATCH_UUCICO_CALLOUT_JOBS

   See the comments in the file.
   CONFIGURING DECUS UUCP                                  Page 5-11
   Create The UUCP Control File


   5.4.1.14  Other Entries

   Most of the other entries in the example file pertain to NEWS,
   which we'll set up later, or to the "UUCLEAN" batch job.  You can
   leave all of these as they are for now.
|  
|  
|  5.4.2  "Activating" the Control File
|  
|  After creating a new [.CFG]CONTROL. file, do the following:
|  
|        o  $ @[UUCP.BIN]UUCP_SYSTARTUP LOGICALS [INCLUDE_NEWS]
|  
|        o  $ @UUCP_BIN:GENERATE_CONTROL
|  
|  The first of these steps interprets your control file and creates
|  logical names from the entries in it.  Use the INCLUDE_NEWS P2
|  parameter if you have included NEWS-related logical names in the
|  file.  (When first setting up uucp, don't specify INCLUDE_NEWS.)
|  
|  The second step produces a new "normalized" control file from the
|  existing logical names (plus other entries in your control file).
|  
|  GENERATE_CONTROL also give the user the option to stop and
|  restart the uucp processes.  This option should normally be taken
|  if uucp has already been started.  The restarted processes will
|  read the new control file and will make use of the newly-defined
|  logical names.


   5.5  Create The UUCP Systems File

   The systems file tells the uucp system who your neighbors are and
   how to reach them.  The uucico "daemon" scans this file once each
                              _____
   time it is awakened.  Each entry in the file describes a neighbor
   system.  For each entry in the file, the daemon checks to see if
   the indicated remote system should be called, and places the call
   if appropriate.  (The call decisions are described below with the
   description of the "times" field.)

   The systems file is also used when uucp is handling an incoming
   call, but in that case only the line for the system calling in,
   and only a few of that line's fields, are important.

   An example systems file is supplied in [.EXAMPLES.CFG]SYSTEMS. ;
   except for phone numbers, usernames, passwords, and other access
   information, this is a copy of Simpact's "live" systems file.
   Please print a copy of this file before proceeding.  As with the
   control file, you will be editing this file to create
   [.CFG]SYSTEMS.

   Each entry in the systems file consists of one or more lines,
   every line except the last ending with a backslash (\).  (The \
               ____
   must be the very last character on the line, with no subsequent
   blanks.) Leading !'s, #'s, blanks, or tabs may be used to denote
   comment lines.  Comment lines beginning with !'s or #'s may
   CONFIGURING DECUS UUCP                                  Page 5-12
   Create The UUCP Systems File


   appear in between the lines of a single entry.

   The format of each entry is:

   <hostname> <entry-name> <luser> <protocols> <options> <when> \
           <port-name> <speed> <phone-number> <loginscript> \
           <str0> <str1> <str2> ... <str7>

   This is a series of strings, or fields, separated by whitespace
   (any combination of blanks, tabs, and, if preceded by
                                                        ______
   backslashes, line breaks).  No whitespace may appear inside any
   of the strings.  (There is an "escape convention" to allow the
   encoding of whitespace within certain strings, should that be
   necessary.)

   The angle brackets denote syntactic elements; they do not appear
   in the file.

   When a line is continued, the "newline" between each pair of
   lines disappears completely; it does not appear as whitespace in
   the assembled entry (but if you have whitespace before the
   backslash or at the beginning of the new line, it is preserved).

   The following subsections describe each field in turn.


   5.5.1  <hostname> field

   is the uucp host name of the remote system.  Uucico will only
   call systems whose names appear in the systems file.  In
   addition, it will normally not permit incoming calls from any
   system whose name does not appear in the local systems file.
   (You can circumvent this latter check by creating a systems file
   entry with an asterisk (*) for the hostname.  This would allow
   you to support "anonymous uucp" access, wherein you publish the
   telephone number and other information and allow anybody to call
   in and obtain copies of, for example, archived public-domain
   software which you keep on your machine.  Several sites on the
   net provide this service.)

   A single system might have multiple entries in the file, perhaps
   specifying different telephone numbers.  When the daemon
   encounters the first entry for a given system, it sees if the
   system should and can be called according to the rules given by
   that particular entry.  If the answer is yes, and the call is
   placed and is successful, all successive entries for that system
   are skipped.  If the answer is no, or if the call attempt is
   unsuccessful, processing continues with the next entry, and the
   call decision is made according to that entry's fields.

   This repeats until either all of the given system's entries have
   been looked at, or a successful call is made.

   As shown in the example file, it is a good idea to use comments
   in the systems file to record information such as the name, voice
   telephone number, and so on, of the system manager at each of
   CONFIGURING DECUS UUCP                                  Page 5-13
   Create The UUCP Systems File


   your neighbor sites.
|  
|  The hostname may optionally be of the form hostname/filealias
|  where the "/" is lexically significant and filealias specifies
|  the alias name which is used for this site.  This is useful if
|  the hostname contains characters which are not good for use in a
|  VMS file name extension (such as one or more dots).
|  
|  If the neighbor happens to have both a long uucp hostname (longer
|  than 7 characters), and a file system that limits his file names
|  to 14 characters (System V comes to mind), systems entries that
|  describe the site should use a "filealias" which is 7 or fewer
|  characters, even if his hostname doesn't contain characters which
|  would construct an invalid VMS filename extension


   5.5.2  <entry-name> field

   is a string used to identify the systems file entry in certain
   log file records.  A hyphen (-) will cause the hostname to be
   used; this is fine if you have just one systems file entry per
   uucp neighbor.  If your systems file is more complex than that,
   putting a different entry-name on each entry will help to make
   the log file less ambiguous, as the log entries will show which
   systems entry was being used for each outbound call.


   5.5.3  <luser> field

   is the "uucp username" for the remote system -- the VMS username,
   on your system, which the remote system will use when it calls
   you.  (We created these usernames in Section 6.1.)  During
   incoming calls, uucico checks this against the actual username of
   the process, and terminates the connection if they don't match.
   If you don't want this checking to be performed for this
   particular entry, use a hyphen (-) as a placeholder.
|  
|  The luser field may optionally be of the form
|  luser@hostalias/spooldir where the "/" and the "@" are lexically
|  signifcant.  spooldir specifies the name of the per site spool
|  directory used to process inbound execution request for this
|  site.  hostalias is the hostname that we identify ourselves as
|  when we use this entry to call the specified neighbor site, or
|  when they call and log in as luser.  If the spooldir is
|  unspecified, it defaults to the same value as the filealias,
|  which if unspecified defaults to the hostname If hostalias is
|  unspecified, it defaults to our CONTROL value for hostname.
|  
|  Local hostname aliasing can be used to enable testing of uucp
|  from one port to another on the same node.  A pair of system file
|  entries point to special ports defined in the control file, which
|  are connected to each other via a null modem cable.
|  
|  Here are sample system file entries using hostname aliasing for
|  this purpose:
   CONFIGURING DECUS UUCP                                  Page 5-14
   Create The UUCP Systems File


|  #
|  #       Test loopback entries
|  #
|  loopout             loopout UU_loopout@infocomm.com g b64w6x0201   Any,5 \
|                  Direct  19200   -       VMS UU_loopin   password
|  infocomm.com/loopin loopin  UU_loopin@loopout       g b64w6x0201   Any,5 \
|                  Direct  19200   -       VMS UU_loopout  password
|  
|  
|  IMPORTANT:  Both the filealias and the spooldir (see above)
|  should be specified identically on every systems entry for a
|  particular site.


   5.5.4  <protocols> field

   is a list of characters which identify the link level protocols
|  supported by the remote system.  This parameter is interpreted in
|  the current software, but the only supported value is a lowercase
|  `g'.  Future versions will support other protocols, and at that
|  time, this parameter will be interpreted as a list of allowable
|  protocols for the connection (in order of preference).


   5.5.5  <options> field

   may be `-' (as a placeholder) or one or more of:

           c      callbacks required
           px     use parity x during login
           xn     set the debug level to n
|          wn     allow neighbor to send with window size n
|          bnn    allow neighbor to send with buffer size nn


   5.5.5.1  c - callback

   The c option indicates that, when the remote system calls in and
   logs in, the local uucico will not go ahead with the call but
   will instead hang up and then call the remote system back.  With
   this enabled, even if someone else learns the uucp login username
   and password used by one of your network neighbors, they will be
   unable to call in and masquerade as your neighbor.


   5.5.5.2  p - parity during login script

   The p option specifies the parity to be used when logging into
   the remote system (processing the login script) during outbound
   calls.  The character x should be replaced by n (for no parity),
   s (for space parity), m (for mark), e (for even), or o (for odd).
   By default, no parity is used.  Regardless of this option, no
   parity is used for the dial or hangup scripts.  (See the
   following chapter on script processing for more information on
   parity options.)
   CONFIGURING DECUS UUCP                                  Page 5-15
   Create The UUCP Systems File


   5.5.5.3  x - debug bits

   The x option sets the debug mask to be used.  If present, this
   overrides the value specified in the control file for the
   duration of the call (or call attempt) that uses the system entry
   in question.  This feature is useful when difficulties are
   encountered with calls to or from only one of your network
   neighbors; debug log output can be kept to a minimum for all
   other systems.

   The characters immediately following the "x" are interpreted just
   like the debug value in the control file, which is to say that
   one or more leading zeroes denote octal notation, while a leading
   "0x" denotes hex.  So to specify the debug value in hex, the
   complete <options> field would look like

           x0x8F

   the first "x" being the flag character that says "set debug
   level", and the subsequent "0x" denoting hexadecimal notation.

   The example systems file includes a description of all of the
   debug control bits.
|  
|  
|  5.5.5.4  b and w - buffer and window sizes
|  
|  The w and b options specify the maximum window and buffer
|  (packet) sizes, respectively, which the remote system is allowed
|  to use when sending to us.  These default to 3 and 64,
|  respectively.  For window size, specify wn where n is a digit
|  from 1 to 7.  For buffer size, specify bnn where nn is one of:
|  32, 64, 128, 256, 512, 1024, 2048, or 4096.  Note that large
|  buffer and window sizes require correspondingly large typeahead
|  buffers.
|  
|                                NOTE
|  
|          Do not override the default window and buffer
|          sizes when using a Telebit modem in g-protocol
|          "spoofing" mode.
|  
|  
|  Additional information on specifying window and buffer sizes may
|  be found in the Appendix on Miscellaneous Topics.


   5.5.5.5  Specifying Multiple <option>s

   If you need more than one option, just concatenate them all
   together, with no intervening spaces.  The order is not
   significant.  For example, to specify callbacks, even parity, and
   debug level 3607 (octal), the option field could be

           cpex03607
   CONFIGURING DECUS UUCP                                  Page 5-16
   Create The UUCP Systems File


   If you use hexadecimal for the debug level, you may need to put
   this option (x) last in the string to avoid ambiguities.

                                 NOTE

           The preceding are the only elements of the
           systems entry required to handle incoming calls;
           if you will not be calling out to the neighbor
           described in this entry, you can stop here.



   5.5.6  <when> field

   The when string indicates when calls may be placed to the remote
   system.  It takes the following form:

|  <days>[times][|<days>[times]...][,succ[,fail[,poll]]][/grade]

   The brackets (angle and square) denote syntactic elements, and
   should not appear in the actual file.  Square brackets denote
   optional elements, angle brackets denote required ones, and
   ellipses (...) shows an element that may be repeated.  The other
   special characters shown (or-bar (|), comma (,), and slash (/)
   are all part of the required syntax if the elements in which they
   appear are present.


   5.5.6.1  <days>


   1.  <days> is a string consisting of one or more of the following
   day codes, all run together:

           Su Mo Tu We Th Fr Sa Wk Any Never

   "Wk" means any weekday (short for MoTuWeThFr), "Any" means any
   day at all, and "Never" means never call no matter what else
   appears in the string.  ("Never" is useful for temporarily
   turning off calls to a system with a minimal change to the file,
   to wit, adding "Never" to the first days string.)


   5.5.6.2  [times]

   The time interval field is optional.  If present, it indicates
   the start and end of the time interval during which calls may be
   made on the days indicated in the preceding <days> string.  It is
   expressed as a start time and an end time, as follows:

           ssss-eeee

   The times must be precisely four digits long in military time
   format, and must be separated by a hyphen (-).
   CONFIGURING DECUS UUCP                                  Page 5-17
   Create The UUCP Systems File


                                           __________
   If ssss is greater than eeee, calls are disallowed from eeee to
   ssss.

   If no time range is specified, any time of day on the indicated
   days is considered to be okay to call.


   5.5.6.3  Multiple Day and Time Intervals

   As indicated in the preceding format, the <days>[times] element
   may be repeated any number of times, separated by or-bars (|).
   Examples are shown at the end of this section.


   5.5.6.4  Recall Time Restrictions (success, fail, and poll)

   These elements of the <when> field are optional.  If present,
   they immediately follow the last (or only) <days>[times] element,
   preceded and separated by commas (,).


   5.5.6.4.1  Success recall interval -

   <succ> is the minimum time (in minutes) that must elapse between
   a successful contact with the remote system (whether via incoming
   or outgoing call) and your system's next outgoing call attempt.
   If not specified, it defaults to 55 minutes.


   5.5.6.4.2  Fail recall interval -

   <fail> is the minimum time (in minutes) that must elapse between
   a failed contact with the system and your system's next call
   attempt.  If not specified, it defaults to 5 minutes.

   Uucico keeps track of how many successive failed contacts have
   occurred; if this number is greater than 1, the fail interval is
   multiplied by 1.5 raised to the power (nfails-1).  This avoids a
   rapid succession of calls to a nonresponsive system (or to an
   incorrect phone number, no doubt someone's home, perhaps in the
   middle of the night).  The maximum actual fail interval that will
   be employed is 10,000 minutes (about a week).  With the default
   fail interval of five minutes, this is reached after about twenty
   calls.


   5.5.6.4.3  Poll recall interval -

   <poll> indicates how often (in minutes) your system will call the
   remote system in the absence of local work for that system.  If
   not specified, <poll> defaults to 0, which disables polling;
   uucico then only places calls if your system knows that it has
   work for the remote system, relying on the other system to call
   in if it has work for your system.
   CONFIGURING DECUS UUCP                                  Page 5-18
   Create The UUCP Systems File


   An extremely short <succ>, <fail>, or <poll> interval will not
   necessarily cause the uucico daemon to place calls at those
   intervals.  At most, uucico will place one call for each entry in
   the systems file, each time the systems file is scanned.  This
   occurs only when the "sleeptime" interval elapses or when someone
   sends uucp mail, whichever comes first.  Thus, if you really
   want, for example, a poll interval of five minutes, you'll have
   to change "sleeptime" in the control file to specify five minutes
   (or less) between scans of the systems file.
|  
|  
|  5.5.6.5  Grade restrictions
|  
|  The <grade> field is a single letter, separated from the rest of
|  the <when> string by a slash (/).  If present, it indicates a
|  file transfer grade restriction for calls initiated with this
|  systems entry:  During a call placed through this systems entry,
|  only those files with a grade letter equal to or earlier than (in
|  ASCII collating sequence) the one specified will be transferred.
|  
|  This is typically used in combination with the <times> field to
|  allow mail to move at any time while general file transfers (uucp
|  requests) and news are restricted to evening hours.  In DECUS
|  uucp, mail is queued with a grade of A, uucp file transfer
|  requests with a grade of G, and news with a grade of N.
|  
|  Note that it is the system that places the call that controls the
|  grade restrictions, regardless of the direction of file transfer,
|  so <grade> specifications on system file entries on your systems
|  will not control which files are moved during calls placed to you
|  by your neighbors.


   5.5.6.6  Examples of valid <when> fields

   Here are some examples of valid "when" fields, with
   interpretations:

   Any

           Simplest possible "when" field.  No day or time
           restrictions.  Success and fail intervals default to 55
           and 5 minutes:  We won't call if we've had a successful
           call to or from them within the last 55 minutes, but if
           the last contact with them failed, retry every
           (5*1.5^(nfails-1)) minutes until we get through.  No
           polling will occur.

   Any1800-2200

           Calls can be placed on any day, but only between 6 and 10
           pm.  Again, success and fail intervals default to 55 and
           5 minutes, and we don't poll.

   Wk1700-0600|SaSu,240,60,1440
   CONFIGURING DECUS UUCP                                  Page 5-19
   Create The UUCP Systems File


           Calls can be placed before 6 am or after 5 pm on
           weekdays, or any time on weekends.  Success and (initial)
           fail intervals are four hours and one hour, respectively.
           If your system hasn't had a successful contact (incoming
           or outgoing) with them within the last twenty four hours
           (1440 = 24*60), call them even in the absence of outgoing
           work, in case they have work for us but can't call out
           for some reason.

|  Wk0800-1700,240,60,1440/G
|  
|          Calls can be placed between 8 am and 5 pm on weekdays,
|          but only to transfer files of grade "G" or higher (this
|          excludes news transfers).  Same success, fail, and poll
|          intervals as the preceding.  (A systems entry with a
|          <when> field like this one would normally be accompanied
|          by another entry, similar in most respects, but allowing
|          calls during evening hours without a grade restriction.)

   The day and time-of-day restrictions take precedence over the
   success, fail, and poll intervals.  That is, the daemon first
   checks to see whether any calls at all are allowed according to
   the days and optional times fields; if so, it then makes the
   "need we call" decision based on the presence or absence of
   outgoing work and the completion status and time of the most
   recent contact with the system.

   The success, fail, and poll intervals apply to all of the days
   and times restrictions, not just the last in the string.

   None of the restrictions affect the times during which we will
   ______
   accept calls from the system.  If you want that sort of control,
   you could use login time restrictions in the UAF entry for the
   remote site's uucp login, assuming that you use different
   usernames for different remote sites.  A better approach is to
   ask the system manager of the neighbor system to only call you
   during the desired times; this prevents the neighbor system from
   logging "call failures" that really aren't.

   If an outbound call ends in failure (perhaps due to a busy
   signal), and the uucico daemon encounters subsequent entries in
   the systems file for the same system on the same scan of the
   systems file, the call decisions are made as if the call had not
   been attempted, except that the fail interval is forced to zero.
   For example, if a system has several phone numbers that are not
   on a rotary selector, you can place an entry in the systems file
   for each number, with all other fields the same.  If a call to
   the number given in the first entry fails, the daemon will go
   ahead and try the number specified in the next entry for that
   system, even though the fail interval specified in that entry (or
   the default fail interval of five minutes) will almost certainly
   not have elapsed.  In other words, a failure to call a given
   system is only logged at most once per scan of the systems file,
   after all of the system's entries have been encountered, and even
   if more than one of these entries have resulted in call attempts
   that resulted in failure.  (This only works if all of the entries
   CONFIGURING DECUS UUCP                                  Page 5-20
   Create The UUCP Systems File


   for a system appear in sequence in the file, with no other
   systems' entries intervening.)

   There are two typical reasons for specifying day and time
   restrictions:  To minimize uucp activity during peak load
   periods, and to force outbound long distance calls to be made
   when the rates are cheap.  In the latter case, remember that your
   computer's clock might not agree with the phone company's, so it
   might not be a good idea to say that calls can be started at
   _______
   exactly 6 pm (or whenever the desired rate period begins); allow
   five or ten minutes' slack. [4]

   When setting up a new connection, it is reasonable to use a
   <when> field such as the following:

           Any,1,1

   This will permit immediate outbound calls whenever you attempt to
   send mail, regardless of how recently a call succeeded or failed.
   (In case of failure, the one-minute fail interval will not cause
   uucico to retry immediately and forever, as the minimum
   "automatic" interval is set by the daemon sleep time.)


   5.5.7  <Port Name> field

   identifies the port, or class of ports, which may be used to
   contact the system.  If the system is reached via a hardwired
   connection, this should be the <name> that appears in the
   corresponding "ports" entry in the control file; otherwise it
   should be "ACU" (or whatever name you gave to your ports with
   autodial modems).

   If you want contacts with a particular system to use a particular
   type of modem, and matching on the supported speed isn't
   sufficient to make the selection (see the next section), you can
   invent a special port name.  Add "ports" entries to the control
   file to specify the physical devices to which those modems are
   connected.


   5.5.8  <Speed> field

   is the line speed which the neighbor supports.

   When the uucico daemon decides to call a system, based on a
   particular entry for that system in the systems file, it scans
   the control file for a "ports" entry with matching <port-name>
   and <speed> fields.  The <speed> fields must match exactly;
   "2400" is not taken to mean either "2400 or less" or "2400 or
   more".

   Uucico will set the line to this speed prior to attempting any
   ____________________

                                     ________ ____ ___ ______
   [4]  This hint came from the book Managing uucp and Usenet.
   CONFIGURING DECUS UUCP                                  Page 5-21
   Create The UUCP Systems File


   data exchanges with the modem, unless the port entry in the
   control file includes the "L" flag.  In that case the <speed>
   field of the port entry merely tells uucico what speed the modem
   supports, and the port is run at whatever speed has been
   established by $ SET TERMINAL/SPEED=nnnn/PERMANENT.


   5.5.9  <Phone Number> field

   is the number to dial to reach the system.  You can include "W"s
   in the string to denote wait-for-dialtone and "P"s to denote a
   timed pause for two seconds, if your modem supports these
   functions.  Use these characters regardless of the actual codes
   your modem wants in its dial command; they will be translated
   when the dial script is processed.

   The "W" and "P" characters must be uppercase to be recognized;
   lowercase "W" and "P" will simply be passed through to the modem
   as part of the dial string.


   5.5.10  <Login Script> field

   is the filename extension applied to UUCP_CFG:LOGIN. to derive
   the name of the script that will be used to log into the remote
   systems.  Login (and other) scripts are described briefly in the
   next section; the following chapter provides a complete
   description of the script language.


   5.5.11  <Str0>...<Str7> fields

   are optional string parameters, available to the login
   script. [5]  Note that no blanks or other whitespace per se may
   appear in these strings, but blanks may be specified as \s, tabs
   as \t, etc., as described under "Extended Strings" in the next
   chapter.  If you want an actual backslash in one of these
   strings, use two backslashes in succession.  Trailing unspecified
   parameters default to empty strings; a nontrailing empty string
   may be specified as "-" (a lone hyphen), and a string containing
   only a hyphen may appear as \- (that is, a backslash followed by
   a hyphen).


   5.5.12  Interaction Between The Systems File and Your Map Entry

   There isn't any.

   The systems file is used by the uucico program to place outbound
   calls and to validate inbound calls.  No calls will ever be
   placed to, or received from, neighbors who do not have entries in
   the systems file.
   ____________________

   [5]  And to the dial and hangup scripts, for that matter, though
   they are typically only used with the login script.
   CONFIGURING DECUS UUCP                                  Page 5-22
   Create The UUCP Systems File


   The map entry (actually, your map file, plus all of the other map
   files) is used by the command procedure MAKEPATHS to generate a
   file called PATHS.  This file, in turn, is used by the uucp
   mailer to determine routes for outbound mail (and for
   route-through mail for which no routing has been specified by the
   sender).

   If your systems entry defines a neighbor who doesn't appear in
   your map entry, you can send mail to them directly (by sending to
   neighbor!username), but the mailer will never route mail to other
   sites through that mailer.

   If your map entry defines a neighbor who doesn't appear in your
   systems file, the mailer (and perhaps mailers on other systems!)
   will attempt to send mail through that neighbor.  Such mail will
   be placed in your spool directory, where it will sit forever, or
   at least until you notice it and clean it out.

   There is no automatic mechanism for ensuring that your systems
   file and your map entry are synchronized, but for things to work
   well, they need to be.  If you change your systems file, be sure
   to make corresponding changes to your map entry.


   5.6  Script Files

   The final set of configuration files you will need are "script
   files".  These tell uucico how to dial a remote system, how to
   log into the remote system, and (optionally) what to do to the
   modem at the end of the call.

|  The script files provided (in [.EXAMPLES.CFG]) should serve for
   the majority of applications (Hayes-compatible, Telebit, and
   several other types of modems, and logins for VMS and Unix
   systems, with and without terminal servers and port selectors).
   If these are not suitable for your situation, you will find a
   complete description of the script language in the following
   chapter.

   In any case, you will need to ensure that the following script
   files exist in [.CFG] and are correct for your situation:


   5.6.1  Dial Scripts

   For each different <modem-type> that appears in a "ports" entry
   in the control file, you will need a script file called
   [.CFG]DIAL.<modem-type> .  This script tells uucico how to use
   that type of modem's autodial feature.  For instance, for
   Hayes-type modems, the script (to simplify matters a bit) tells
   uucico to send "AT<CR>", wait for an "OK", and then send "ATDT"
   followed by the <phone number> from the systems entry and a
   carriage return, and then wait for a response from the modem
   indicating success or failure.
   CONFIGURING DECUS UUCP                                  Page 5-23
   Script Files


   We have supplied several dial scripts, with names like DIAL.HAYES
   and DIAL.TBGSPOOF, in [.EXAMPLES.CFG] .  These have been tested
   with Hayes-type modems and with Telebit modems in g protocol
   "spoofing" mode, respectively.  Several generous folks have sent
   in dial scripts for other types of modems; their names are listed
   in the comments in the respective files.
|  
|                                NOTE
|  
|          All of the supplied dial scripts assume
|          touch-tone dialing (e.g., for Hayes modems, they
|          use ATDT...).  If you can only use pulse dialing,
|          you will need to edit the scripts accordingly.
|  
|  
|  
|  5.6.2  Login Scripts
|  
|  If the dial script ends in success, the uucico daemon then uses
|  the <login script> specified in the systems entry for the called
|  system to negotiate the login sequence (wait for "Username:"
|  prompt, send username, etc.).  The name of the login script used
|  is [.CFG]LOGIN.extension, where the filename extension is given
|  by the <login script> parameter of the current system entry.
|  
|  "Standard" login scripts are provided for typical VMS and Unix
|  systems; the username, password, and system password are provided
|  by the <str0>, <str1>, etc., fields in the systems entry.  For
|  special circumstances, such as systems which must be accessed
|  through a port selector, you may have to devise your own login
|  scripts; a sample of such a script is provided in
|  [.CFG]LOGIN.SCUBED .
|  
|  
|  5.6.3  Hangup Scripts
|  
                                        ___
|  Finally, for some <modem-type>s, you may need a script file
|  called [.CFG]HANGUP.<modem-type> .  This script, if present, is
|  run at the end of each outgoing call through modems of the
|  specified type.  It tells uucico how to return the modem to a
|  state suitable for accepting incoming calls.  For example, in
|  order to accept incoming calls under VMS, most modems must be
                 ___
|  configured to not send "result codes" (strings such as RINGING,
|  CONNECT 2400, and the like) to the local VAX, and so these modems
|  are normally configured that way.  But it is convenient to get
|  result codes from the modems during the dial sequence, so the
|  dial sequence starts with steps to turn result codes on.  The
|  hangup script is used to turn them back off again at the end of
|  the outgoing call.  (See the preceding chapter on modem setup
|  options.)
|  
|  Some modems allow you to store your desired option settings in
|  nonvolatile RAM, and will reset to these settings whenever the
|  VAX drops the Data Terminal Ready (DTR) signal.  Since DTR is
|  dropped at the end of each call, even if uucico terminates
|  abnormally, this provides a convenient way to ensure that the
   CONFIGURING DECUS UUCP                                  Page 5-24
   Script Files


|  modem gets reset to the correct state.  For such modems, hangup
|  scripts need not be provided.
|  
|  Some other modems will work correctly for both outgoing calls and
|  incoming calls with the same set of options; in this case no
|  option changes are needed in the dial script, so no hangup script
|  is needed either.
|  
|  One hangup script, HANGUP.HAYES, is provided; this turns off
|  result codes for Hayes-type modems.  (No hangup script is
|  required for Telebit modems.)
|  
|  
|  5.7  Summary
|  
|  Here is a brief list of the steps required to set up uucp's
|  configuration files:
|  
|        o  Create one or more "uucp login" UAF entries, which your
|           network neighbors will use for their calls to your
|           system, plus one more for uucp batch job execution.
|  
|        o  Create your "uucp map entry".
|  
|        o  Edit the control file to specify your uucp host name,
|           the work scan sleep interval, the default debug options,
|           and the serial ports to be used for outgoing calls.
|  
|        o  Create one or more entries in the systems file for each
|           of your network neighbors.
|  
|        o  Review, and modify as appropriate, the supplied dial,
|           login, and hangup script files.
|  
|  
|  
|  
|  
|  
|  
|  
|  
|  
|  
|  
|                              CHAPTER 6
|  
|                         THE SCRIPT LANGUAGE
|  
|  
|  
|  DECUS uucp uses "script files" to direct modem dialing, login
|  sequence, and modem reset operations.  Script files are somewhat
|  like DCL (or other CLI) command procedures, with some
|  modifications as appropriate for this application.
|  
|  Formally, a script file describes a state machine; uucico
|  interprets the script file [1]  and does what the state machine
|  tells it to.
|  
|  Before proceeding, please obtain listings of the script files in
|  the [.CFG] directory (DIAL.*, LOGIN.*, and HANGUP.*) .  The rest
|  of the discussion will assume that you have these available for
|  reference.
|  
|  
|  6.1  Script File Format
|  
                                                   ________  ______
|  Script files are ordinary text files containing comments, labels,
       __________
|  and statements.
|  
|  Comments are denoted by leading "!" or "#" characters.  Some
|  statements (those which do not end with an "extended string"
|  argument; see below) can also have trailing comments.
|  
|  Labels begin in column one and are ended by colons (:).  A label
|  specifies a state name.  All lines between a pair of labels are
|  the statements for a single state.
|  
|  Processing always begins at the head of the script (no leading
|  state name is necessary).
|  
|  Statements are divided into two categories, "action" and
|  "waitfor".  When a state is entered, all of its actions are
|  performed in the order in which they appear in the file.
|  
|  A transition to another state may occur for any of three reasons:
|  
|  ____________________
|  
|  [1]  Technically the script is translated into an internal form
|  first, but this process is so trivial that I can't bring myself
|  to call it "compilation".
|  THE SCRIPT LANGUAGE                                      Page 6-2
|  Script File Format


|        o  One of the actions may cause a transition to another
|           state, in which case the rest of the current state's
|           actions (and any waitfors, if present) are skipped.
|           Processing resumes with the first action statement of
|           the new state.
|  
|        o  If none of the actions cause a state transition, and
|           there are no waitfors in the state, processing "falls
|           through" to the next state in the file.
|  
|        o  If none of the actions cause a state transition, but
|           there are waitfors in the state, the state machine
|           pauses until the conditions of one of the waitfors is
|           "satisfied".  It then transitions to the state named in
|           that statement.
|  
|  Finally, there are two action statements which, when executed,
|  cause the script to exit.
|  
|  
|  6.2  Script File Statements
|  
|  This section describes all of the statements that may appear in
|  script files, except for a few special action statements.  Those
|  are described in a later section, "Overriding Defaults".
|  
|  Some statements accept one or two arguments, referred to in the
|  following descriptions as "int", "ns", "str", or "xstr", to
|  indicate whether the argument is an integer, a new state name, a
|  string, or an "extended string" (described in a later section).
|  
       ___
|  For all statements that accept two arguments, the first is the
|  name of a new state, and the second specifies a condition or
|  reason for changing to the new state.
|  
|  
|  6.2.1  Action Statements
|  
|  6.2.1.1  Termination and informational statements
|  
|  log     xstr     send xstr to log file.
|  
|  logerr  xstr     send xstr to log file, with error indicator.
|  
|  failed           exit script with "failed" status.
|  
|  success          exit script with "success" status.
|  
|  
|  6.2.1.2  Sending data
|  
|  dial             send the string given by the <phone number>
|                   field in the systems entry to the serial port.
|                   "W" and "P" characters in the phone number are
|                   converted as described under "dial strings",
|                   below.  This statement also sets a default
|  THE SCRIPT LANGUAGE                                      Page 6-3
|  Script File Statements


|                   timeout value, as described under the "timeout"
|                   statement.
|  
|  send    xstr     send the string xstr to the serial port.
|  
|  sendstr int      the argument of this statement is a digit from 0
|                   through 7.  Send the corresponding string
|                   parameter (<str0>, <str1>, etc.) from the
|                   systems entry (interpreted as an extended
|                   string).
|  
|  
|  6.2.1.3  Special terminal control statements
|  
|  flush            flush the terminal port's typeahead buffer.
|  
|  break            send a break signal.
|  
|  hangup           momentarily drop Data Terminal Ready on the
|                   serial port, causing the modem to hang up.  (Not
|                   usually needed, since uucp does this at the end
|                   of each call.)
|  
|  
|  6.2.1.4  Counting, branching, and testing statements
|  
|  sleep   int      delay for int milliseconds.
|  
|  zero             clear the counter.
|  
|  count            add one to the counter.
|  
|  ifgtr   ns int   go to state ns if counter greater than int.
|  
|  ifblind ns       go to state ns if terminal multiplexer does not
|                   allow receipt of data when Carrier Detect absent
|                   (e.g. DMF32).
|  
                                                               ___
|  ifblgtr ns int   go to state ns if counter greater than int and
|                   the terminal multiplexer does not allow receipt
|                   of data when Carrier Detect absent (e.g. DMF32).
|  
|  goto    ns       go to state ns unconditionally.
|  
|  ifstr   ns int   go to state ns if string parameter str<int> is
|                   nonempty.
|  
|  ifnstr  ns int   go to state ns if string parameter str<int> is
|                   empty.
|  
|  iflat   ns       go to state ns if terminal is a LAT port.
|  
|  ifnlat  ns       go to state ns if terminal is not a LAT port.
|  THE SCRIPT LANGUAGE                                      Page 6-4
|  Script File Statements


|  6.2.2  Waitfor Statements
|  
|  Waitfor statements are usually the last statements that appear in
|  a given state, though in fact they can appear anywhere within the
|  state.  Even if they appear at the beginning, the script
|  processor always does all of the action statements first.  As a
|  practical matter, the order of these statements is not
|  significant; they are all interpreted "in parallel".
|  
|  ifcarr  ns       change to state ns if Carrier Detect is true.
|  
|  timeout ns int   change to state ns if the time (in milliseconds)
|                   given by int has elapsed without satisfying any
|                   expects.  If the time specified is 0, a default
|                   timeout value (calculated from the length and
|                   other characteristics of the most recent dial
|                   string) is used.
|  
|  expect  ns xstr  change to state ns if the string specified by
|                   xstr is received from the serial port.  Case is
|                   significant, but high-order bits are not
|                   checked.
|  
            ______
|  Multiple expect statements can appear within a state; see
|  [.CFG]DIAL.HAYES for an example.
|  
|                                NOTE
|  
             _______
|          A timeout statement must appear within any state
                         ______    ______
|          that includes ifcarr or expect statements.
|  
|  
|  
|  6.3  Script Processing Details
|  
|  6.3.1  Extended Strings
|  
|  In the statements that accept string arguments, the strings are
|  interpreted as "extended strings".  Extended strings begin with
|  the first nonblank character and continue, including all imbedded
|  and trailing blanks and other whitespace, until (but not
|  including) the end of the line in the script file.  (There is no
|  provision for line continuation.)  No trailing spaces should be
|  present between the last "desired" character of the string and
|  the end of the line, as they will be included in the stored
|  string and sent or expected, just as they appear in the script
|  file.  And, obviously, no trailing comments are permitted!  They
|  will just be stored as part of the string.
|  
|  Within an extended string, the following "escape sequences" will
|  be converted as indicated before being sent or expected:
|  
|          \d      EOT character (control-D)
|          \N      null character
|          \n      line feed
|          \r      carriage return
|  THE SCRIPT LANGUAGE                                      Page 6-5
|  Script Processing Details


|          \s      space
|          \t      tab
|          \-      hyphen
|          \\      backslash
|          \ooo    character with value ooo (in octal)
|  
|  Since extended strings in scripts can include imbedded spaces,
|  tabs, etc., these escape sequences are only required in strings
|  appearing in systems entries, though they may be used in script
|  files to improve readability.
|  
|  The octal-character specification (\ooo) may have from one to
|  three octal digits; it is terminated either after the third digit
|  or when a non-octal character is encountered.  But if you want to
|  specify one of these followed by something that happens to be a
|  valid octal character -- for example, a control-A followed by a
|  7 -- make sure to include all three digits after the \.  (\0017
|  would become a control-A followed by the Ascii character "7", but
|  \17 or \017 would become a control-Y (decimal value 25).  \1S
|  would convert to a control-A followed by an "S".)
|  
|  Extended strings are stored without a trailing carriage return
|  unless one is explicitly present in the string (via \r).
|  
|  
|  6.3.2  String Parameters
|  
       _______
|  The sendstr statement sends (after conversion from extended
|  string format) one of the string parameters (<str0>, <str1>,
|  etc.) in the current systems entry.  The parameter is selected by
|  the integer argument of the statement.
|  
|  This allows "generic" script files (such as LOGIN.VMS) to serve
|  for many different systems; the string parameters in the systems
|  entry provide the username, password, etc.  Character
|  substitutions described under "extended strings" above are
|  performed on these strings.
|  
       _____     ______
|  The ifstr and ifnstr statements allow further generality in
|  script files, by testing whether a particular parameter is
|  present in the systems entry.  For example, a single script,
|  LOGIN.VMS, can be used both for those VMS systems that require a
|  system password and those that do not.  The system password is
|  specified as the string parameter <str2> in the systems entry;
|  the script tests for this parameter's existence and skips the
|  system password sequence if the parameter is empty.
|  
|  
|  6.3.3  "Wait" and "Pause" Characters in Dial Strings
|  
|  A different conversion is performed on dial strings.  Dial
               ___
|  strings are not interpreted as extended strings.  However, the
|  characters "W" and "P" within a dial string are interpreted as
|  "wait for dial tone" and "pause", and may be converted to other
|  characters.  By default, "W" is left alone, and "P" is converted
|  to a comma (,); these are appropriate for Hayes-type modems.  The
|  THE SCRIPT LANGUAGE                                      Page 6-6
|  Script Processing Details


|  dial script may specify other substitutions (see below).  Note
|  that these characters must be in upper case to be recognized;
|  lowercase "w" and "p" will be simply sent to the modem.
|  
|  
|  6.3.4  Default Timeouts for Dial Strings
|  
          ____
|  When a dial statement is executed, a default timeout value is
                                                        _______
|  set.  This is the timeout value used by a subsequent timeout
|  statement if the statement specifies a timeout value of 0.
|  
|  The default timeout is given by ctime + (ndigits*dgttime) +
|  (nwchar*wtime) + (npchar*ptime), where ndigits, nwchar, and
|  npchar are the number of digits, wait characters, and pause
|  characters in the dial string, and ctime, dgttime, wtime, and
|  ptime are 45 seconds, 0.1 seconds, 10 seconds, and 2 seconds,
|  respectively.  All of these times may be changed as specified
|  below under "Overriding Defaults".
|  
|  
|  6.3.5  Trailing Carriage Returns Not Assumed
|  
          ____     _______
|  In the dial and sendstr statements, the dial string or systems
|  entry string parameter is sent with no trailing carriage return;
|  if a carriage return must be sent after one of these, a separate
   ____
|  send statement must provide it.
|  
|  
          ______
|  6.3.6  Expecting Ambiguous Strings
|  
|  We've run into one modem that sends a simple "B" to indicate
|  "busy", or "Bnnnn" to indicate a connection at the indicated
|  speed (for example, B2400 for 2400 bits/sec).  How would you
|  write a script to deal with this?
|  
|  The following
|  
|          dial
|          expect  busy    B
|          expect  con_12  B1200
|          expect  con_24  B2400
|          timeout nocarr  40000
|  
|  won't work; if the modem sends "B1200" or "B2400", the first
   ______
|  expect will be matched and the modem will be assumed to be busy.
                                           ______
|  This is true regardless of the order of expect statements.
|  
|  A workaround for this particular situation is to not bother
|  checking for the "busy" case, and just delete the "expect busy B"
|  statement.  If the called line is busy, the modem will only send
                                _______
|  a "B", none of the remaining expects will be matched, and the
   _______
|  timeout statement will go to the "nocarr" state after 40 seconds.
|  
|  Here is a more general solution:
|  
|          dial
|  THE SCRIPT LANGUAGE                                      Page 6-7
|  Script Processing Details


|          expect  got_b   B
|          timeout nocarr  40000
|  
|  got_b:
|          expect  con_12  1200
|          expect  con_24  2400
|          timeout busy    1000
|  
|  
|  6.3.7  Parity
|  
                                                             __
|  Most VMS systems use no parity (that is, eight data bits, no
|  parity bits, one stop bit, usually designated as 8N1) for async
|  terminal lines.  DECUS uucp follows suit and uses 8N1 parity
|  during all phases of operation.
|  
                                               ___
|  Once the uucp "shere exchange" has started, all uucp "g" protocol
|  implementations use 8N1, as a fully-transparent eight-bit data
|  path is required by the protocol.
|  
|  Some Unix systems (and a smaller, but nonzero, percentage of VMS
|  systems) have their terminal lines set for other than no parity.
|  Many Unix systems, for example, expect logins to use even parity.
|  
|  The script processor makes several allowances for parity for
|  outbound calls.
|  
|  The high bit of all incoming data is set to zero before matching
|  against "expect" strings, so it doesn't matter to us whether the
|  remote system is sending parity or not.
|  
|  As for the data we send, most systems, even ones that send us
|  characters with parity, are "forgiving" and will permit logins
|  from no-parity sources.  However, if a system requires you to use
|  parity when logging in, For inbound calls, VMS is "forgiving" --
|  the high bits of the username and password are zeroed before
|  comparison.
|  
|  As described in the previous chapter, the "p" option in systems
|  entries specifies the parity to be used when sending data from
|  the login script.
|  
|  Despite the "p" option, dial and hangup scripts will still be run
|  with no parity.  Almost all VMS systems use eight data bits, no
|  parity, so we expect that most modems connected to VMS systems
|  will be set up that way.
|  
|  The script language provides five statements for changing the
|  parity to be used to send characters.  These may be used in dial
|  and hangup scripts (if yuo absolutely must run your modems with
|  other than no parity), or in login scripts, if parity must be
|  changed "on the fly":
|  
|  parity_none      set to no parity (8N1)
|  THE SCRIPT LANGUAGE                                      Page 6-8
|  Script Processing Details


|  parity_space     set to space parity (7 data bits, high bit
|                   forced clear)
|  
|  parity_mark      set to mark parity (7 data bits, high bit forced
|                   set)
|  
|  parity_even      set to even parity ("A" is sent as 11000001, "C"
|                   as 11000011)
|  
|  parity_odd       set to odd parity ("A" is sent as 11000001, "C"
|                   as 01000011)
|  
|                                NOTE
|  
|          If you are one of those rare VMS sites that uses
|          something other than no parity for your
|          interactive terminals, we strongly advise you to
|          reconsider.  The use of anything other than eight
|          data bits, no parity bit, on VMS terminal lines
|          invariably causes more problems than it solves.
|  
|  
|  
|  6.3.8  The HOSTSYNC Characteristic
|  
|  By default, HOSTSYNC is disabled at all times on incoming uucp
|  calls, and is disabled for outgoing calls as soon as the "Shere
|  exchange" begins (essentially, as soon as we recognize that the
|  remote has started its uucico program).  However, script
|  processing for outgoing calls is done with HOSTSYNC enabled.
|  This is done to allow the local VAX to flow-control the remote
|  system if, for instance, the remote is known to have a very long
|  login banner message.
|  
|  The following commands allow explicit control of the HOSTSYNC
|  characteristic during script processing:
|  
|  hostsync_off     turn hostsync off
|  
|  hostsync_on      turn hostsync on


   6.3.9  Ambiguous Labels

   If you have two or more states with identical labels, only the
   first will be recognized; it will be impossible to change state
   to the others (other than by "falling through" from the
   immediately-preceding state).  The script processor will emit no
   error messages for duplicate state names.


   6.3.10  Overriding Defaults

   The script processor sets several default values upon beginning a
   script.  The following statements, which override these defaults,
   may be useful in certain circumstances.
|  THE SCRIPT LANGUAGE                                      Page 6-9
|  Script Processing Details


   chrdly  int      Since many modems cannot accept dialing commands
                    at full "computer speed", the script processor
                    sends all strings with a brief inter-character
                    delay.  This statement specifies the delay time,
                    in milliseconds.  The default is 100 (0.1
                    second).

   pchar   str      Specifies the character to which "P"s in the
                    dial string should be converted.  Default is
                    ",", for use with Hayes-type modems.

   ptime   int      Specifies the time, in milliseconds, to allow in
                    the default timeout for each pause character in
                    the dial string.  Default is 2000 (2 seconds).

   wchar   str      Specifies the character to which "W"s in the
                    dial string should be converted.  Default is
                    "W", for Hayes modems.

   wtime   int      Specifies the time, in milliseconds, to allow in
                    the default timeout for each wait-for-dialtone
                    character in the dial string.  Default is 10000
                    (10 seconds).

   dgttime int      Specifies the time, in milliseconds, to allow in
                    the default timeout for each digit character in
                    the dial string.  Default is 100 (0.1 second).

   ctime   int      Specifies the time, in milliseconds, to allow in
                    the default timeout for carrier to appear after
                    the dial string is sent.  Default is 45000 (45
                    seconds).


   6.4  Written Any Good Scripts Lately?

   If you come up with any new script files, please send them to us.

   Scripts to deal with PC-Pursuit, various types of port selectors
   (both at your end and at the target system), and so on, would
   also be valuable.












                               CHAPTER 7

            FINISHING AND TESTING THE INSTALLATION OF UUCP



   7.1  Check SYSGEN Parameters

   Change the following SYSGEN parameters, as necessary:

         o  TTY_ALTYPAHD or TTY_TYPAHDSZ must be at least 210 bytes
            (see the chapter on configuring terminal ports).

         o  Ensure that the lower three bits of TTY_DIALTYPE are
            zero, unless you have certain knowledge that they should
            be otherwise.

         o  VIRTUALPAGECNT must be at least 20000 pages.


   7.2  File Protection

   Invoke [.BIN]UUCP_CONFIG and use option 2 to set the correct
   ownership and protection codes on the files in the [UUCP...]
   tree.

   Note that as a practical matter, there is no point in denying
   world read access to any of uucp's executable images, or indeed
   to any of the files supplied with the package, since anybody in
   the (literal) world can obtain copies of them from DECUS.


   7.3  Define UUCP Logical Names

   If you have not already done so, execute the following DCL
   command:

           $ @ddcu:[UUCP.BIN]UUCP_SYSTARTUP LOGICALS

   The parameter causes the procedure to define the logical names as
   specified in your control file.  Some of these names are needed
   in the next step.
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-2
   Generating The Path Data Base


   7.4  Generating The Path Data Base

   In this step you will create the file [.DATA]PATHS. , which tells
   the mail router how to reach other sites in the uucp mail network
   (and in the other networks to which there are uucp gateways).  To
   do this, enter either of the following DCL commands:

           $ @UUCP_BIN:MAKEPATHS

   or
           $ SUBMIT/NOPRINT UUCP_BIN:MAKEPATHS

   The account from which this is run should have a paging file
   quota (PGFLQUOTA) of at least 20,000 blocks, and access to a
   working set of 4K pages or so.  On a one-VUP VAX, an 8200,
   MAKEPATHS took about twenty minutes of CPU time, and thirty
   minutes elapsed time.  On a VAXstation 4000/60, it took about two
   minutes of CPU time, and ten minutes elapsed time.

   If MAKEPATHS ever terminates with an access violation, it needs a
   larger VIRTUALPAGECNT, more PGFLQUOTA, or both.

   As supplied, MAKEPATHS is memory-intensive.  You can make it use
   more disk space and less memory for its working files by defining
   the logical name UUCP_MAKEPATHS; see the comments in
   [.BIN]MAKEPATHS.COM for details.

   If you have defined a "smart host" (see the preceding chapter on
   configuration files, or the later appendix on Pathalias), you
   still need to run MAKEPATHS, but with only two short map files to
   read (yours, and the one declaring your smart host) it should
   take less than a minute to run.

                                 NOTE

           If you ever modify [.DATA]PATHS. by means other
           than running MAKEPATHS, ensure that the result is
           a streamlf file.



   7.5  Start It Up

   Take a deep breath, log in to a fully-privileged account [1]
   (though you can turn off BYPASS), and type

           @UUCP_BIN:UUCP_SYSTARTUP

   (with no P1 parameter).  It will:

   ____________________

   [1]  We have not had time to determine just what the minimum set
   of privileges is for running UUCP_SYSTARTUP.  It is intended to
   be run from the system-wide startup command procedure, which is
   fully privileged anyway.
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-3
   Start It Up


         o  Submit the UUCICO_CALLOUT batch job, which runs uucico
            in "daemon" mode.  Uucico will look for outbound work
            (mail or news) for all neighbor systems named in the
            systems file.  It will attempt to call any neighbor
            systems for which (a) outbound work exists or (b)
            polling has been enabled in the systems file entry.
            After this, the "daemon" will "sleep" (enter LEF wait
            state) until the "sleeptime" interval from the control
            file has passed, or until someone sends outgoing uucp
            mail, whichever comes first.

         o  Uucico will in turn submit the UUXQT_BATCH batch job for
            execution.  This will run uuxqt.exe, which in turn will
            spawn a subprocess running uuxqt_dcl.com.  Uuxqt.exe
            will then look for "X" files in [.SPOOL]; finding none,
            it will hibernate.

         o  Submit the UUCP_CLEANUP batch job for execution one hour
            later (this will resubmit itself every hour).


   7.6  Test It

   You should be able to "bounce" mail off of a neighbor machine.
   Invoke MAIL, type the SEND command, and enter the following in
   response to the "To:  " prompt:

           UUCP%"neighbor_hostname!my_hostname!my_user_name"

   and it should be sent to the other machine and echoed back.  As
   soon as you send uucp mail, your uucico daemon should place the
   appropriate call (unless call time restrictions prevent it from
   doing so right away).  For other tests, send mail to the
   postmaster or to your contact at your neighbor system.  Details
   on address formats can be found in one of the Appendices.

                                    ___
   Note that "looped" mail is often not echoed within the same call
   in which it was sent.

   You can also test local mail delivery by sending mail to

           UUCP%"my_hostname!my_user_name"

   This involves only uuxqt, not uucico.


   7.7  If The Call Doesn't Work

   The most common reasons for this will be file protection troubles
   and call/login problems.  Look in the debug file (described in
   the chapter on "Troubleshooting") for information on what
   happened.

   If you prefer, you can run the call from your terminal, and watch
   the debug output appear "live".  To do this, invoke the
   UUCICO_CALLOUT command procedure interactively, as follows:
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-4
   If The Call Doesn't Work


           $ @UUCP_BIN:UUCICO_CALLOUT "neighborname" "-x0217"

   neighborname must be in lower case and surrounded by quotes, as
   shown.  The second parameter will force the debug level for the
   call to at least 217 octal, enabling you to see the dial and
   login script processing in action.  You may prefer to do this via
   SET HOST 0/LOG, at a hardcopy terminal, or by some other means
   which will let you preserve the entire session.  Running uucico
   this way bypasses all retry period and call time checking.

                                 NOTE

           You should do this only from your uucp test
           account, as this account has the same privileges
           (none), UIC, and other attributes as the account
           under which the uucico daemon normally runs.
           Testing under any other account may introduce
           other problems, or invisibly get around the
           original problem (usually due to file protection,
           UIC differences, and other factors).


   Another way to stimulate a call without actually sending mail is
   to run the uupoll program.  Define uupoll as a foreign command by
   executing [.BIN]USERCMDS.COM, and then:

           $ uupoll neighborname

   This will create a dummy C-file in the spool directory and awaken
   the daemon.  The daemon should call the indicated system.  At
   this time there will be no work waiting at either side, so the
   two systems will say hello, say goodbye, and hang up.  Check the
   log file and debug log file (see the "Troubleshooting" chapter)
   to see what actually happened.  This method of inducing a call
        ___
   does not bypass uucico's retry period and call time checking; if
   we just tried to call the indicated system a few minutes ago,
   nothing will happen until the relevant retry period (success or
   failure, depending on how the previous call ended) has expired.
|  
|  
|  7.8  If the Call Goes Through but the Mail Doesn't
|  
|  If you see log entries indicating a successful call, leading up
|  to "We want to send...", or "They want to send...", and then a
|  series of errors, the most likely problem is a non-transparent
|  data path:  A terminal mux, or a modem, or a statistical
|  multiplexer, or something, is either not passing the high bit of
|  the ascii characters or is placing some special interpretation on
|  some characters (most often XON and XOFF).
|  
|  By far the most frequent problem that sites have when either
|  first coming on line with DECUS uucp, or when changing or adding
|  new modems, is that they don't get the line/modem configured
|  correctly to pass all possible 8 bit values.  UUCICO has been
|  extended to explicitly perform a test of the datapath.  This test
|  is requested by calling UUCICO_CALLOUT.COM with P1 as the site to
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-5
|  If the Call Goes Through but the Mail Doesn't


|  test against (as above) and P2 as either "-d" or "-Dtestargs".
|  The first case "-d" causes a default test which should be
|  sufficient to verify the path for most users, while the
|  "-Dtestargs" allows control of the test control variables see the
|  code for explicit details of the parameter meanings.  (The
|  calling system gets to select the the mode of testing since it is
|  his phone bill.)
|  
|  The default test first passes all possible byte values back and
|  forth, then the intervening buffering and flow control mechanisms
|  are stressed a bit by passing gradually increasing buffers
|  containing a range of possible values.  This buffer test defaults
|  to starting at 70 bytes, stepping up by 70 bytes until buffers of
|  210 bytes are being exchanged.  The range of values exchanged in
|  the original byte by byte test and the range of values and the
|  buffer sizes in the buffer testing can be varied as options in
|  the "-Dtestargs" form of the test.
|  
|  This will work only against a neighbor system that is running
|  DECUS uucp V2.0 or later.  Future versions of other uucp
|  implementations may add a compatible feature.


   7.9  Make it Automatic

   When you are happy with things, put a command to execute
   ddcu:[UUCP.BIN]UUCP_SYSTARTUP.COM (with no parameter) in your
   site-specific system startup command procedure.  (Remember that
   UUCP_SYSTARTUP.COM defines the logical UUCP_BIN, so you can't use
   the logical to find the right disk at boot time!)

   To make the tail, News, and other commands available to users,
   place a command to execute UUCP_BIN:USERCMDS.COM in your
   site-wide login command procedure.


   7.10  Note For Cluster Users

   ___
   All machines in the cluster (all those that are to have access to
   uucp mail, at any rate) should execute UUCP_SYSTARTUP.COM upon
   startup.  This procedure automatically checks the node name
   against the name defined by the logical UUCP_BATCH_NODE .  If
   they're the same, it does everything; otherwise, it just defines
   the logical names and installs the mail shareable images.


   7.11  Tell Your Users

   After you have things working reliably and have some experience
   sending and receiving network mail, you will want to tell the
   other users at your site about it.  The "Address Formats"
   appendix should provide most of the information they will need to
   send and receive mail.  You will likely want to customize it for
   your site.
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-6
   Tell Your Users


   There is a HELP module describing uucp mail in
   [.DOC]MAIL_UUCP.HLP .  Again, you will probably want to customize
   this a bit for your site.  You can include it in the standard VMS
   DCL-level help library (SYS$HELP:HELPLIB.HLB) or place it in an
   alternate help library (accessed via a logical of the form
   HLP$LIBRARY_n).


   7.12  Tell The World

   Mail a copy of your map entry to:

           uucp%"rutgers!uucpmap"

   or to the address specified in [.DATA.MAPSRC]README .  Within a
   month or so it will appear in an update to the appropriate U.xxx
   file, will be distributed via the network News to all interested
   parties, and so will be reflected in everyone's PATHS. databases,
   allowing other folks to easily send mail to you.  By that time
   you should have News running (see the chapters on adding News
   support), so you'll get a copy too, as well as updated maps for
   many other sites.


   7.13  Tell Us

   ______
   Please send mail to one (or all) of the VMSnet team.  This
   needn't be an elaborate missive; a copy of your map entry will do
   just fine!  Of course, comments on any difficulties you
                                                    _______
   encountered (and how you resolved them) would be greatly
   appreciated.  (See the front cover for addresses)


   7.14  Obtaining Current Maps

   Regardless of how you obtain this package, the maps that come
   with it will be a little (or maybe a lot) out of date.  They will
   probably be good enough to get you going, but you should arrange
   to get a new set as soon as possible (unless, of course, you're
   relying on a smart host).

   One of your prospective network neighbors should be able to
   supply you with a more up-to-date set of maps.  If they are
   running the Unix operating system, ask them to put the maps onto
   a "tar" (tape archive; somewhat analogous to VMS's BACKUP) tape.
   The program [.BIN]TARREAD.EXE will read such a tape; instructions
   are in [.DOC.UTILS]TARREAD.DOC .  After recovering the files from
   the tar tape, use the command procedure [.BIN]FIXTARMAP.COM to
   change the underscores (_) in the file name extensions to hyphens
   (-).  (The uucp map files use multiple periods in their names.
   We used one convention for converting the filenames to VMS
   format, and the folks who wrote TARREAD used another.)

   You can also use your uucp system to retrieve reasonably up-to-
   date maps from uunet via their 900 number, even if you are not a
   uunet subscriber.  Instructions on the 900 service are in
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-7
   Obtaining Current Maps


   [.DATA.UUNET].  At this writing, the cost to retrieve the maps is
   about eight dollars with Telebit modems.  The following procedure
   will retrieve the entire map database (about 1.7 megabytes):

           $ uucp "uunet!~/uumap.tar.Z" "~/uunet/"
           $! (case is significant in the first file name above)
           $ set default uucp_public:[uunet]
           $ compress -d uumap.tar
           $ define tape uucp_public:[uunet]uumap.tar
           $ set default [uucp.data.mapsrc]
           $ tarread == "$uucp_bin:tarread"
           $ tarread xv
           $ @uucp_bin:fixtarmap

   Again, the files will come out with names like U.USA_CA_1
   (TARREAD's convention) instead of U.USA-CA-1 (our convention);
   FIXTARMAP.COM will rename them for you.  You can then delete
   uucp_public:[uunet]uumap.tar.

   You can also ask uunet for individual map files for your area.
   For example, to retrieve u.usa.ca.1, the command

           $ uucp "uunet!~/uumap/u.usa.ca.1" "~/uunet/u.usa-ca-1"

   will place the file u.usa-ca-1 in UUCP_PUBLIC:[UUNET].  Rename it
   into [.DATA.MAPSRC] and you're done.

   When you are set up to receive News, you will get map updates in
   the newsgroup comp.mail.maps .  The News/uucp integration
   mechanisms supplied with DECUS uucp will extract these into
   [.DATA.MAPSRC] and submit MAKEPATHS for execution, so that PATHS.
   will be kept up to date automatically.


   7.15  Adding More Neighbors

   Soon you will probably want to add more neighbor systems.  Here
   is a checklist of things to do:

         o  Create a uucp login for the new neighbor (use
            [.BIN]UUCP_CONFIG.COM).

         o  Exchange phone numbers, usernames, passwords, and other
            access information with the neighbor system manager.

         o  Add one or more entries to your systems file.

         o  If an existing login script isn't suitable, create an
            appropriate one.

         o  Test the link by sending mail to a known user on the
            neighbor system, or by "bouncing" mail through the
            neighbor back to yourself.
   FINISHING AND TESTING THE INSTALLATION OF UUCP           Page 7-8
   Adding More Neighbors


         o  Update your uucp map entry to reflect the new
            connection, run MAKEPATHS to rebuild your local routing
            database, and mail the new map entry to
            rutgers!uucpmap .












                               CHAPTER 8

                         TROUBLESHOOTING UUCP



   8.1  How It Works

                                                        ________
   First, here is a brief description of how things are supposed to
   work.


   8.1.1  The Basics

   When you send mail to UUCP%"user@somewhere", VMS MAIL activates
   the UUCP_MAILSHR image, which in turn uses the path data base to
   find an appropriate route.  The route will be of the form
                                       ______
   system!system2!...!user.  The first system in the route will be
   name of the neighbor system to which your mail will be sent for
   forwarding.  In the filename examples to be given, this will be
   called system "them", and your system will be called system "us".

   UUCP_MAILSHR then creates three files in UUCP_SPOOL:

         o  B.usAnnnn - a uuxqt command file to be sent to the
            remote system

         o  C.them_Annnn - commands to the local uucico program

         o  D.usAnnnn - the actual mail file, with RFC822 headers

   When uucico looks for work for "them" (either when deciding
   whether to call them, or when they call us), it will find the C
   file.  (C files are in fact sometimes referred to as "work
   files".)  This file tells it to copy the D file to the remote
   system as-is, and to copy the B file with its name changed to
   X.usAnnnn .

                                 NOTE

           In order to prevent uucico from finding C files
           before UUCP_MAILSHR is done with them, the C file
           is not directly created.  Instead, UUCP_MAILSHR
           creates the file as Z.them_Annnn.  The last thing
           UUCP_MAILSHR does for outgoing mail is to rename
           Z.them_Annnn to C.them_Annnn, thus making the
           file available to uucico.  You should never see Z
                                                    ____
           files in the spool directory (other than very
   TROUBLESHOOTING UUCP                                     Page 8-2
   How It Works


           briefly) -- if you do, something is wrong.


   To process incoming mail, uucico awakens uuxqt whenever uucico
   receives an X file.  uuxqt looks for X files in the spool
   directory.  The X file tells uuxqt which files in the spool
   directory to access and what command to execute on the receiving
   system to process those files.  For mail, this command is
                                                     ____
   "rmail".  (We have hardwired our uuxqt so that it only responds
   to rmail and rnews commands.)  Rmail in turn delivers the mail to
   the intended recipient, (perhaps by sending it, via uucp, to the
   next system in the path).


   8.1.2  Details:  B, X, C, and D Files

   We are going to cop out here and refer you to the relevant
                                               ________ ____ ___
   sections of Appendix A, "Working Files", in Managing uucp and
   ______
   Usenet (see Chapter 0).  We hope to find time to expound upon the
   "internals" in a future version of the manual.


   8.1.3  Locks

   DECUS uucp uses the VMS lock manager to trigger uuxqt wakeup (via
   a "doorbell" lock, using a blocking AST), and also to prevent
   multiple uucico processes from trying to contact the same
   neighbor at the same time.  For example, when an incoming call is
   received, uucico attempts to acquire (in exclusive access mode) a
   lock with the name

           UUCP_SYS_hostname

   Similarly, the uucico daemon attempts to acquire the same lock
   when processing the systems file entry for hostname.  Only one of
   these processes can own the lock at one time, so multiple
   contacts are prohibited.

   Access to the serial ports is controlled through VMS's standard
   implicit device allocation mechanism; since the terminal ports
   are nonshareable devices, no two processes can simultaneously
   have a channel assigned to one port.

   No Unix-style "lock files" are used.  If a uucp process is
   "stuck", and holds a lock which prevents its replacement from
   functioning, simply delete the "stuck" process with a DCL STOP/ID
   command.  This will release all locks owned by the process.

   The SHOW LOCKS and SHOW PROCESS/LOCKS commands to the system dump
   analyzer (invoked with ANALYZE/SYSTEM) will display all of the
   locks known on your system, and all of the locks held by a given
   process, respectively.  These commands may be of use in finding
   out which processes are holding the locks in question.
   TROUBLESHOOTING UUCP                                     Page 8-3
   How It Works


   8.1.4  Uucp Protocol Details

   For additional details on the uucp "g" protocol, see the document
   [.DOC.MISC]UUGPROT.RNOM .


   8.2  Log Files

   DECUS uucp has an extensive system of log files to help keep you
   informed of what it is doing.  Most failures can be quickly
   analyzed by examining the log files and the appropriate records
   in the regular VMS accounting file.  This section will describe
   the various log files and conclude with a discussion of common
   and likely problems.


   8.2.1  UUCP.LOG

   This single file is uucp's primary event log.  It appears in the
   log directory [.LOG] (as do all of the other log files described
   in this chapter).  All processes running uucico (both the dialout
   daemon and for incoming calls), as well as uuxqt, append entries
   to this file to record "major events".  Most problems will be
   recorded in this file.  The causes for the problems will
   generally not be obvious, but as will be seen, entries here will
   usually point you to other log files which will provide more
   information.

   Somewhat like VMS's error log, uucp.log is opened for append
   access and then closed again every time an entry is added.  This
   causes a bit of extra overhead but means that the latest entries
   in the file are always immediately accessible for viewing.  The
   uuclean batch job (UUCP_CLEANUP) renames this file to
   UUCP.LOG_mmdd each night, shortly after midnight, so that no one
   file gets too large.  Uuclean also searches the previous day's
   UUCP.LOG file(s) for entries denoting errors and mails such
   entries to the UUCP_POSTMASTER.

   Here is a sample entry from uucp.log:

   p:uucp << h:esther  [04/20-16:48:49-0000051a]   Startup ok     (g) u:-

   We will eventually write many tens of pages about all of the
   different log entries that can appear and what they all mean.
   (The adventurous and the impatient can look for calls to the
   procedure logit() in [.DEVEL.UUCP.SRC]*.C .)  For now, we'll
   describe the entry format and point out a few perhaps-non-obvious
   details.


   8.2.1.1  UUCP.LOG Entry Format

   Log entries follow a consistent format.  Reading from left to
   right, the elements of an entry are:
   TROUBLESHOOTING UUCP                                     Page 8-4
   Log Files


   8.2.1.1.1  Program Name -

   The name of the program that made the entry, preceded by "p:".
   This will be either "uucp" (which really means uucico) or "uxqt"
   (short for uuxqt).  Uuxqt's entries are rarely interesting.


   8.2.1.1.2  Call Progress and Direction Indicator -

   Two "funny characters" that together indicate the direction and
   status of a call.  For entries from "uucp", the combinations that
   can appear are:

               (empty) program startup
           --  sleeping, waiting for work
           ?>  scanning spool directory for work
           ->  placing call to system named in "h:"
           =>  dialed ok, doing login script and protocol handshake
           >>  handshake succeeded, exchanging work
           -<  incoming call received
           =<  incoming call, doing protocol handshake
           <<  handshake succeeded, exchanging work

   This may seem excessively cute, but it lets us pack a great deal
   of information into each log entry in a minimum amount of space.
   There is no need to find the most recent "Incoming" and
   "Outgoing" messages to determine the system name and call
   direction for any given log entry, since this information appears
      _____
   in every log entry.

   Note that for "uucp" entries the arrow does not indicate the
   direction of data transfer, but the direction of the telephone
   call.  (A left-pointing arrow is an incoming call -- to uucp --
   while a right-pointing arrow is an outgoing call, usually from
   the uucico daemon.)  Data can always be exchanged in both
   directions during any given call.

   For "uxqt" entries (other than program startup) there is a much
   smaller set:

           =<  beginning X file processing
           <<  handing X file contents to UUXQT\_DCL



   8.2.1.1.3  Hostname -

   The uucp hostname of the system at the other end of the serial
   link, preceded by "h:".


   8.2.1.1.4  Date, Time, and PID Stamp -

   The date (month and day only) and time the log entry was made,
   and the VMS process identification (PID) of the process that made
   the entry, all surrounded by square brackets.  As will be seen,
   TROUBLESHOOTING UUCP                                     Page 8-5
   Log Files


   the PID is the key to several other vital pieces of information.


   8.2.1.1.5  Error Indicator -

   This is an asterisk in the second character position after the
   closing bracket of the time-and-pid field.  It does not appear in
   the preceding example, because that entry did not denote an
   error.  Here is a sequence that includes some error indicators:

   p:uucp -- h:-       [04/20-17:50:38-00000487]   Waiting         (15 minutes) u:-
   p:uucp ?> h:crash   [04/20-17:53:28-00000487]   Outgoing        (_TTB1: 2400 bps) u:-
   p:uucp -> h:crash   [04/20-17:53:28-00000487]   Calling         (crash) u:-
   p:uucp -> h:crash   [04/20-17:54:02-00000487] * Script log      (Modem reported NO CARRIER) u:-
   p:uucp -> h:crash   [04/20-17:54:03-00000487] * Dial failed     (crash) u:-
   p:uucp -> h:crash   [04/20-17:54:03-00000487]   Dropping DTR    () u:-
   p:uucp -> h:crash   [04/20-17:54:10-00000487] * Call failed     (see prev msg) u:-
   p:uucp -- h:-       [04/20-17:54:11-00000487]   Waiting         (15 minutes) u:-

   ("crash" is the uucp host name of the system being called, not a
   description of what happened afterwards.)  The asterisk is there
   to call your attention to the errors amongst all of the other
   entries.  Sometimes (as seen here) other nearby entries will
   provide more information.  The "Script log" entry was generated
        ___
   by a log statement in the dial script, and the "Modem reported NO
                                         ___
   CARRIER" text was the argument of the log statement.  The script
                              ______
   then exited by executing a failed statement, causing uucico to
   write the "Dial failed" log entry.


   8.2.1.1.6  Event Description -

   A very brief statement of the event, followed (usually) by
   additional information pertaining to the event.  The latter is
   enclosed in parentheses.


   8.2.1.1.7  Username -

   Preceded by "u:".  Immediately after startup of uucico, contains
   the VMS username associated with the process.  After a connection
   is established with a remote uucp host, and work is being
   exchanged, this field reflects the name of the user who requested
   the action that is being reported by the log entry.  Often
   appears in hostname!user or user@host.domain format, and may
   reflect a username on the local system or the neighbor system,
   depending on the entry.  If unknown or not applicable at this
   point in the call, appears as "-".


   8.2.1.2  Hints on Log File Interpretation

   TROUBLESHOOTING UUCP                                     Page 8-6
   Log Files


   8.2.1.2.1  Time Sequencing -

   We should mention once again that all processes running uucico or
   uuxqt append entries to this file.  The following sequence, for
   example, shows mail being received by uucico, and processing of
   the "rmail" command by uuxqt before uucico exits:

   p:uucp << h:esther  [04/20-16:48:55-0000051a]   They want to send (S D.estherA0794 D.estherA0794 jeh@SIMPACT.UUCP - D.estherA0794 0666 )
   u:jeh@SIMPACT.UUCP
   p:uucp << h:esther  [04/20-16:48:59-0000051a]   File rcvd ok    (370 bytes, 3 secs, 123 Cps) u:jeh@SIMPACT.UUCP
   p:uucp << h:esther  [04/20-16:49:01-0000051a]   They want to send (S B.estherA0794 X.estherA0794 jeh@SIMPACT.UUCP - B.estherA0794 0666 )
   u:jeh@SIMPACT.UUCP
   p:uucp << h:esther  [04/20-16:49:04-0000051a]   File rcvd ok    (70 bytes, 2 secs, 35 Cps) u:jeh@SIMPACT.UUCP
   p:uxqt =< h:esther  [04/20-16:49:04-00000481]   Processing      (X.esther_A0794) u:-
   p:uxqt << h:esther  [04/20-16:49:04-00000481]   Executing       (rmail jeh < uucp_spool:D.esther_A0794 > NL:) u:-
   p:uucp << h:esther  [04/20-16:49:08-0000051a]   End of call     (complete) u:jeh@SIMPACT.UUCP
   p:uucp << h:esther  [04/20-16:49:08-0000051a]   Dropping DTR    () u:jeh@SIMPACT.UUCP

   It can get worse:  If you have more than one modem, your uucico
   daemon might be calling out on one line while someone is calling
   in on another; you'll see the entries from two "uucp"s
   interspersed in the log.  The PIDs will let you sort things out;
   that's why they're there.


   8.2.1.2.2  Throughput -

   As shown in the following example, uucico will report the net
   throughput in charcters per second after each file transfer:

   ...0000051a]   File rcvd ok    (370 bytes, 3 secs, 123 Cps) u:jeh@simpact.uucp

   Do not expect throughputs approaching the line speed unless the
   file is large enough to need ten to twenty seconds to transfer.
   The actual transfer time for short files like the one reported in
   the preceding example is overshadowed by the startup and shutdown
   times for the file copy operation, and these are not compensated
   for in the throughput calculation.


   8.2.1.2.3  Benign "Errors" -

   There is one "error message" that may appear after a call on a
   noisy line:

   ...00000487] * Protocol stats  (errs: 1 pks in/out: 5/13) u:jeh

   Do not be alarmed by the non-zero "errs:", as this (probably)
   does not indicate that bad data was received.  The uucp "g"
   protocol does a sixteen-bit checksum validation on each 64-byte
   data segment, and each six-byte packet header (which includes the
   checksum) is further protected by an XOR byte.  We say "probably"
   because the simple checksum algorithm used will let some
   single-bit errors slip by, but is quite good at detecting the
   "bursty" errors that predominate in serial communications.
   TROUBLESHOOTING UUCP                                     Page 8-7
   Log Files


   8.2.1.2.4  Sys$Assign:  No Privilege For Attempted Operation -

   Uucico may report this error when it tries to assign a channel to
   a port to place an outgoing call.  It may mean that the device
   protection mask or ACL has not been set properly (see the SET
   DEVICE/ACL commands in UUCP_SYSTARTUP.COM); this should be fixed.
   But it may also simply mean that some other process was using the
   port at the time.


   8.2.1.2.5  Entry Names Vs. System Names -

   The hostname (h: field) in log entries for outgoing calls is
   taken from the <hostname> field in the systems entry being used.
   If you have several systems entries for a single neighbor system,
   this could be a bit ambiguous, particularly when looking at "dial
   failed" (which number was it dialing?) and the like.  So, for the
   following event descriptions, the <entry-name> from the systems
   entry appears in the supplemental information (within
   parentheses):

         o  Calling

         o  Dial failed

         o  Login failed

         o  Sys entry too short

         o  No ports avail

         o  Bad <when>

   The supplemental information field is used for other things in
   other log entries, so only the (perhaps ambiguous) hostname field
   will appear (after the h:).  However, you can find the related
   systems file "entry name" by looking for one of the above
   messages (at least one of them will always appear for any
   outgoing call) with a matching PID field.  See the description of
   the <hostname> and <entry-name> fields in systems file entries in
   the chapter, "Configuring UUCP", for more information.


   8.2.1.2.6  Using "SEARCH" -

   The VMS SEARCH command can be used to good advantage to find
   "interesting" entries in the log.  This is the reason for some of
   the punctuation in the log entries; it allows us to easily
   specify unambiguous search targets.  For example,

           $ search esther

   might find places in the log where "esther" appeared in file
   names, but

           $ search "h:esther"
   TROUBLESHOOTING UUCP                                     Page 8-8
   Log Files


   will just match where esther appears as a host name.

           $ search "0000051a]"

   will match all entries from the given process ID , and

           $ search "] * "

   will find all errors.

   Multiple search targets can of course be combined via the /match
   qualifier.  For example,

           $ search "h:crash","] * "/match=and

   will find all error entries associated with host crash, and

           $ search "> h:crash","] *"/match=and

   will limit the search to outbound calls only.


   8.2.2  The Debug Log File

   In addition to the UUCP.LOG "event log", uucico is thoroughly
   laced with code which provides for writing to its "debug log".
   (Uuxqt also writes to a debug log, but its debug output is far
   less interesting.)  Debug output is divided into a number of
   categories, each controlled by a bit in the debug enable mask.
   (These bits are documented in the example systems file,
   [.CFG]SYSTEMS.EXAMPLE.)  The control file sets the default value
   for this mask, but as we have seen, each entry in the systems
   file can provide an overriding value which is in effect for any
   call using that entry.

   Many of the debug log options are useful only to people debugging
   uucico, but others are useful for troubleshooting configuration
   problems, and login and dial script problems in particular.  The
   most interesting debug options for most such problems will be:

        000001  error messages and a copy of the log file output
        000002  dial,login,init trace -- errors only
        000004  dial,login,init trace -- nonerrors (incl char I/O)
        000010  file transfer commands -- errors only
        000200  packets -- errors only

   (all specified in octal).  "Or" these together and you get 217.

   If, for example, you aren't using the correct password to login
   to a particular neighbor, the debug log (with this option
   enabled) will show the "User authorization failure" message (or
   equivalent) sent by the remote system.

   Nonprintable characters in the log are shown in hex, using the
   notation 0xhh.  Printable characters with the high bit set are
   shown with a leading `.  Every time one second (approximately)
   TROUBLESHOOTING UUCP                                     Page 8-9
   Log Files


   passes while processing the waitfor statements in a state, the
   word "tick" is written to the log.  (It is after each of these
              ______     _______
   ticks that ifcarr and timeout statements, if present in the
   state, are checked.  The ticks are not necessarily a full second
                                                       _______
   apart, but this does not affect the accuracy of the timeout.)

                                 NOTE

           One of the debug mask values, 004000, enables a
           probabilistic error generator within the "g"
           protocol module.  This simulates line noise; we
           used it to ensure that our "g" protocol
           implementation would recover properly under
           various sequences of error conditions.  Special
           entries in the control file must also be present
           for this feature to work.  See the giowvms.c and
           uumisc.c modules for details.

|  
|  
|  8.2.2.1  Setting Debug Levels
|  
|  The control file establishes a default debug level for all uucp
|  processes.  Generally you will want this to be at a relatively
|  low level, and just increase the debug levels for particular
|  calls.
|  
|  
|  8.2.2.1.1  Outbound Calls -
|  
|  Specify the debug levels for outbound calls to a particular site
|  by using the "x" option in the options field of each of the
|  site's entries in the systems file.
|  
|  
|  8.2.2.1.2  Inbound Calls -
|  
|  If the logical UUCP_UUCICO_DIALIN_DEBUG is defined, its
|  translation is prefixed by "-x" and UUCICO is invoked with this
|  option (debug level) for all incoming calls.
|  
|  If the logical UUCP_UUCICO_DIALIN_DEBUG_username is defined, its
|  translation is similarly prefixed by "-x" and UUCICO is invoked
|  with this option (debug level) for incoming calls from the
|  indicated username.  (We can't do it by hostname, because at the
|  time we need to set the debug level we don't yet know their uucp
|  hostname.)


   8.2.2.2  Where Does The Debug Log Go?

   Unlike UUCP.LOG, debug logs are not shared; each process running
   uucico (or uuxqt) has its own, so all entries therein pertain to
   just that one process.
   TROUBLESHOOTING UUCP                                    Page 8-10
   Log Files


   8.2.2.2.1  Inbound Calls -

   By default uucico writes its debug log output to the "standard
   output" (SYS$OUTPUT in VMS parlance).  This is obviously
   unsuitable for inbound calls, where SYS$OUTPUT points to the
   serial port, so the debug log is redirected at a file called
   [.LOG]UUCICO_DBG.pid, where pid is the process id, in hex (but
   not zero-filled, so on a non-clustered machine the filename
   extensions are nice and short).  Use the entries in uucp.log to
   find the pids that are of interest.  For example, when looking at
   the following log excerpt

   p:uucp -< h:-       [04/20-17:35:18-00000527]   Incoming       (_TTB1: 2400 bps) u:-
   p:uucp -< h:crash   [04/20-17:35:19-00000527]   Call from      (crash) u:-
   p:uucp =< h:crash   [04/20-17:35:24-00000527]   Carrier lost   () u:-

   we could expect to find some clues as to what happened in
   [.LOG]UUCICO_DBG.527 (and also in the system accounting file).
   ("Carrier lost" doesn't have an error indicator because this
   event occurs during the normal sequence of every call; it just
   happened early this time.)

   Once a night, the uuclean batch job deletes files with names of
   this form which are over a day old and for which there are no
   error entries in UUCP.LOG.


   8.2.2.2.2  Outbound Calls -

   For outbound calls, the uucico daemon writes the debug log to its
   SYS$OUTPUT, which is its batch job log file,
   [.LOG]UUCICO_CALLOUT.LOG .


   8.2.3  SYS$ERROR

   For inbound calls, SYS$ERROR is directed to a file called

           [.LOG]SYSERROR.pid

   where "pid" is, again, the process identification (without
   leading zeroes).  These files can help find login and startup
   problems caused by protection violations and similar
   difficulties.  Zero-length files with names of this form are
   automatically deleted once an hour by the UUCP_CLEANUP batch job.

   For outbound calls, SYS$ERROR is of course the batch job's log
   file, [.LOG]UUCICO_CALLOUT.LOG .  If uucico should ever terminate
   abnormally (perhaps with an access violation), you'll find the
   traceback output in one of these files.  (Please mail it to one
   of the authors as soon as possible!)
   TROUBLESHOOTING UUCP                                    Page 8-11
   Log Files


   8.2.4  Status Files

   These are not, strictly speaking, log files; they are used by
   uucico to record the completion status of the most recent call to
   or from each neighbor system.  Their names are
   [.LOG]STST.hostname .  Each contains just one line of text.  For
   example:

   f: 0 c: 6 nf: 0 sq: 348 success outbound normal - [04/21-00:11:45-00000487]

   The latter part of that should look familiar:  It's the same as
   the time-and-pid stamp in the log file.  At the beginning of the
   line are four numeric fields, set off by short, minimally-
   mnemonic codes:

           f:   0 or 1 to indicate success or failure, respectively
           c:   a numeric code representing the completion status
           nf:  the number of successive failures
           sq:  call sequence number

   Following this is a textual interpretation of the "c:" value.

   These files are used by the call time decision mechanism in the
   uucico daemon.  Note that the revision date and time of the file,
   and not the date and time stored in text in the file, is used to
   determine "time of last call":  If you edit one of these files,
   uucico will assume that the last contact was at the time you
   edited the file.  (One good reason for editing an STST file is to
   set a large nf count to zero after a long-standing problem has
   been fixed, to circumvent the failure retry backoff mechanism.)


   8.2.5  UUXQT's Batch Log

   Uuxqt, the program that handles incoming "execution" files, runs
   in a batch job by itself and so has its own batch log,
   [.LOG]UUXQT.LOG.  The SYS$OUTPUT from uuxqt's DCL subprocess gets
   written here too.  There normally won't be much in this file
   except messages from UUXQT_DCL indicating the start of processing
   of each X-file.  Any DCL error messages found in this log should
   be reviewed carefully; they will probably be associated with
   files in [.DUMP] (to be described) and/or [.RCVDNEWS], and
   possibly [.SPOOL].


   8.2.6  Other Sources of Information

   8.2.6.1  The Dump

   In the [.DUMP] directory you may find X- and D-files.  These are
   received X- and D-files which could not be processed correctly.
   Entries in uucp.log, and possibly uuxqt_dcl.log, should indicate
   the reason.  You can search for the file name in uucp.log, or
   look at the creation dates and search the log file for the
   appropriate "mm/dd-hh:ss" strings.  Also, find the appropriate
   UUXQT.LOG file (using creation dates) and look in it for the file
   TROUBLESHOOTING UUCP                                    Page 8-12
   Log Files


   name.


   8.2.6.2  Temporary Files in the Spool Directory

   The existence of one or more files called TM_Unnnn in the
   per-site subdirectories of the [.SPOOL...] tree, when uucp is not
   handling and incoming or outgoing call, indicates that a previous
   call failed in the midst of a file transfer.  Uucico always
   receives data into files named TM_Unnnn; when the entire file has
   been received correctly, uucico renames it to the proper name
   (D.* or X.* for mail and news).  Only after a D- and X-file pair
   are received can mail or news be delivered.  If a call "dies" in
   the midst of receipt of a file, you'll be left with the TM_ file;
   if it dies in between the two files, you'll be left with the D.-
   file.  In both cases, the file transfer will begin again on the
   next call to or from the neighbor system.

                                 NOTE

           Dialup phone lines being what they are,
           occasional unexpected disconnects are only to be
           expected.  Only when disconnects occur
           repeatedly, perhaps during contacts with a
           particular neighbor, are they cause for concern.


   Check the creation date on each such file, and search UUCP.LOG
   for entries associated with the sending system's hostname
   (indicated by the subdirectory you found the file in) around that
   date and time; these will tell you the name of the sending system
   and the intended final filename.  The sending system should send
   you the file again during a later call, as uucp never deletes
   outgoing files until they have been transferred successfully.

   You can always safely delete these TM_ files.  (We leave them in
   the spool directory so that their presence will alert you to
   possible problems.)

   D.- files require special care.  You need to examine the log
   files and see if a file of the same name was successfully
   transferred from the same system during a later call.

   Do not delete D.- files that are in the top-level directory of
   the UUCP_SPOOL tree.  These are associated with C.- and,
                                      ________
   possibly, B.- files that represent outbound work from your
   machine.


   8.2.6.3  The VMS Accounting File

   Don't forget that you can ask the Accounting utility to show you
   entries by PID:

           $ accounting/ident=xxxxxxxx/full
   TROUBLESHOOTING UUCP                                    Page 8-13
   Log Files


   The "Final status text" displayed here may point out some
   problems such as file protection conflicts, password troubles for
   inbound calls, and so forth.


   8.2.6.4  Process Names

   Any process running uucico or uuxqt will set its name to

           <progname> <indicator> <hostname>

   just like the first three log entry fields of its most recent log
   entry, but without the "u:" and "h:" delimiters.  So SHOW SYSTEM
   will tell you what uucp processes exist, what they're doing, and
   who they're talking to (if anybody).  For example, the following
   excerpt lines from a SHOW SYSTEM display show the uucico daemon
   (PID 116) in the midst of an outgoing call to scubed, and another
   process (PID 560) servicing in incoming call from crash.  The
   uuxqt batch job and its DCL subprocess (PIDs 356 and 357) are,
   for the moment, idle.

   00000116 uucp >> scubed  HIB      9   103982   0 00:26:28.84     85508    693  B
   00000356 uxqt -- -       HIB      6     1586   0 00:00:26.38      7502     86  B
   00000357 uxqt dcl        LEF      7     4973   0 00:03:00.32     37929    203  S
   00000560 uucp << crash   HIB      8     1384   0 00:00:12.16       980    762


   8.2.6.5  UUCP_STATUS Logical Name

   Whenever a process running uucico writes a "major" entry into the
   log, it copies the entry into the equivalence-name of the system
   logical name UUCP_STATUS_uucp.  SHOW SYSTEM will thus give you a
   quick glance at everything that's happening with uucp, and SHOW
   LOG UUCP_STATUS* will show you the last log entry, without having
   to look at the file.


   8.2.6.6  Tail

       ____
   The tail utility (in [.BIN]) can be used to conveniently examine
   the last few lines (which are often the most interesting) in any
   of the log files.  Tail is described in one of the appendices.


   8.2.7  "Expected Problems"

   As noted earlier, the places where you can expect to see problems
   have to do with dial and login script processing and with file
   protection.  File protection problems will show up as VMS error
   messages in the uucico daemon's batch job log file,
   UUCICO_CALLOUT.LOG (for outgoing calls), and in the SYSERROR.pid
   files (for incoming).

   Dial and script processing applies only to outgoing calls; the
   after-the-failure info can be found in UUCICO_CALLOUT.LOG .
   Sometimes it helps to place the outgoing call from your
   TROUBLESHOOTING UUCP                                    Page 8-14
   Log Files


   terminal -- seeing the log output "as it happens" often makes the
   problems much more obvious than when you're reading the log
   files.

   If you are having real problems with your dial or login scripts,
   the best way to find them is to "play computer".  Use Kermit, SET
   HOST/DTE, VAXNET, or other "terminal emulator" to connect your
   terminal to the modem, and try to "execute" the dial and login
   scripts just as uucico would.  After you successfully log in to
   the remote system using the uucp login, you should shortly see
   the message

           Shere

   or, possibly,

           Shere=theirhostname

   and the cursor should stop at the end of the message.  This
   message is sent by the uucico in the other machine when invoked
   in "slave mode" (that is, when handling an incoming call).
   (There's not much else you can do from your terminal, so hang up
   the phone at this point.)  If you seem to log in successfully but
   _____
   don't see the Shere (perhaps a command line interpreter prompt
   appears instead), your uucp login is not set up correctly on the
   neighbor system.

   Of course, when someone calls your system, and UUCP_LOGIN invokes
   uucico, it sends "Shere" back to the caller.  If others are
   having problems calling you, try logging into one of the "real"
   uucp logins (not the test account) yourself.  If something other
   than "Shere" appears after you've supplied the correct username
   and password, something is wrong with the account setup; perhaps
   its default device, directory, or login command procedure are
   wrong.


   8.2.8  Restarting the Batch Jobs

   If any of uucp's batch jobs fails for any reason, enter the
   following DCL command to restart them:

           $ @UUCP_BIN:UUCP_SYSTARTUP BATCH_JOBS

   The parameter causes the command procedure to only start the
   batch jobs and not redefine the logical names, etc.  Only those
   batch jobs which have actually failed will be restarted.  (If you
   want to do the same for the NEWS-related batch job, NEWSSKIM, use

           $ @UUCP_BIN:UUCP_SYSTARTUP INCLUDE_NEWS
   TROUBLESHOOTING UUCP                                    Page 8-15
   Log Files


   8.2.9  "MicroVAX Crashes While Running DECUS uucp"

   This was the synopsis of one of the first bug reports we got
   after Version 1.1 was released.  Now, DECUS uucp is all user-mode
                                    ____
   code, so it isn't supposed to be able to cause a crash, if
   everything in VMS's inner layers is doing the right things.  But
   it certainly can exercise some parts of system code in ways that
   expose previously-latent bugs.

   The culprit in every one of these cases was a third-party
   controller in the Q-bus (typically a disk controller) that
   interrupted at BR5 rather than BR4 (which is what the VMS disk
   driver expects).  Reordering the controllers in the Qbus so that
   the high-BR-level controllers were first in the bus solved the
   problem in each case.

   Early Emulex QD21's (Q-BUS MSCP disk controller) were known to
   use BR5.  Revision E or F corrected it to BR4.












                               CHAPTER 9

                          UUCP FILE TRANSFERS



|  9.1  Introduction
|  
|  The UUCP system can be used to copy arbitrary files to or from
                             ____
|  your neighbor sites.  The uucp command is provided to request
|  such transfers.  Users at your neighbor sites can also send files
|  to you, or (if you have enabled this) request files from your
|  system.
|  
|                                NOTE
|  
|          The image UUCP.EXE must be installed with SYSPRV,
|          because it needs to write into the UUCP_SPOOL
|          directory, which is protected against access by
|          non-system UICs.  There is a logical, definable
|          via the CONTROL file, which inhibits this
|          installation of UUCP.EXE, thereby denying the use
|          of the UUCP command to anyone who doesn't have
|          SYSPRV.
|  
|  
|  
|  9.1.1  The UUCP Command
|  
|  The format of the uucp command is as follows:
|  
|          $ uucp [-options] from ...  to
|  
|  The parameters are:
|  
|  
|  from    the source file name.  If this is a request to copy a
|          file from your system to someone else's, this is an
|          ordinary VMS file specficiation.  If you are "pulling" a
|          file from someone else's system to yours, this is of the
|          form
|  
|          "neighbornode!filespec"
|  
|          where:
   UUCP FILE TRANSFERS                                      Page 9-2
|  Introduction


|           o  neighbornode is the uucp hostname of the neighbor
|              system from which you're requesting the file
|  
|           o  filespec is a valid file specification on that system
|  
|           o  the quotes (") and bang (!) are required
|  
|          Note that multiple "from" parameter can appear in the
|          same uucp command (separate them by spaces).
|  
|  to      the destination file name.  Similar syntax to the "from",
|          but reversed:  For "pulling" a file from a neighbor
                                                              ______
|          system, this is an ordinary VMS file specification within
           ___ ___________ _________ ____
|          the UUCP_PUBLIC directory tree (see the section following
|          on "Directories").  For "pushing" a file to a neighbor
|          system, this is in the form
|  
|          "neighbornode!filespec"
|  
|          As described above.
|  
|          Unlike the "from", only one "to" file may appear on the
|          command line.
|  
|  options specify one or more options, each preceded by a hyphen
|          (-) and followed by a space.  The available options are:
|  
|          -d      make necessary directories if don't exist
|          -f      don't make necessary directories if don't exist
|          -gprio  transfer priority.  "prio" is a single letter, default "G".
|                  (no relation to "g" protocol)
|          -m      notify requester (on local machine) upon completion
|          -nuser  notify 'user' on neighbor machine via mail upon completion
|          -r      queue the request, but don't start uucico
|          -j      display job id for transfer
|          -x      enable debug output
|          -v      image mode transfer (preserve VMS file attributes if possible)
|  
|  The -v option causes the file to be stored on the destination
|  system with its VMS file attributes preserved in a special
|  header.  When such file is uucp'd back to another system running
|  DECUS uucp V2.0 (or later), its original file attributes will be
|  restored.  This is useful for copying VMS files to a Unix system
|  for archiving and later retrieval by other VMS systems.  (File
|  transfers directly between DECUS uucp V2.0 or later systems will
|  automatically preserve the file attributes; there is no need to
|  request the -v option.)
|  
|  
|  9.2  Directories
|  
|  It would obviously be ungood to allow uucp neighbors to transfer
|  files to arbitrary places on your disks.  DECUS uucp therefore
|  places severe restrictions on the "arrival points" for files
|  being copied into your machine (whether at the request of local
|  or remote users).  Here are the rules that are in effect:
   UUCP FILE TRANSFERS                                      Page 9-3
|  Directories


|        o  All inbound files that don't explicitly specify a
|           directory will actually arrive in the per-site
|           subdirectory of UUCP_SPOOL.  (This is normally the case
|           with files associated with news and mail.)
|  
|        o  All inbound files of this type must be named
|           "D.something" or "X.something".  Any request to transfer
|           a file named other than D.* or X.* into your system,
|           without specifying a target directory, will be rejected.
|  
|        o  Inbound file requests that do explicitly specify a
|           directory will only be honored if the logical name
|           UUCP_PUBLIC is defined similar to:
|  
|                   UUCP_PUBLIC $DISK6:[uucp.public.]
|  
|           in the [.CFG]CONTROL. file.  In addition, the "path"
|           specified in the transfer request must either explicitly
|           or implicitly refer to UUCP_PUBLIC as the destination
|           "device" of the transfer.
|  
|           Examples of allowed explicit references:
|  
|           UUCP_PUBLIC:[XXX]file.dat
|           UUCP_PUBLIC:[000000]file.dat
|           UUCP_PUBLIC:file.dat
|  
|           Examples of allowed implicit references:
|  
|  -----------------------------------------------------------------
|  Path specification              Is interpreted as
|  -----------------------------------------------------------------
|  ~/XXX/file.dat                  UUCP_PUBLIC:[XXX]file.dat
|  ~/file.dat                      UUCP_PUBLIC:[000000]file.dat
|  /usr/spool/uucppublic/file.dat  UUCP_PUBLIC:[000000]file.dat
|  -----------------------------------------------------------------
|  
|                                NOTE
|  
|          The directory specified by UUCP_PUBLIC must be
|          writable by the UUCP accounts for inbound
|          transfers to work.  If not, then an appropriate
|          error response is returned to the requesting
|          host.
|  
|  
|        o  Remote requests to copy files out of the local machine
|           are first enabled (still) by the UUCP_CFG:CONTROL.
|           variable "enbrmtrcv".  All such requests must now either
|           explicitly or implicitly refer to files in UUCP_PUBLIC.
|           The name translation rules for these requests are the
|           same as for inbound requests (see above), and also
|           require READ permission by the uucp account accessing
|           it.
   UUCP FILE TRANSFERS                                      Page 9-4
|  Directories


|        o  All outbound traffic actually goes through UUCP_SPOOL as
|           it always has.
|  
|  The "file name" part of file specifications which reference
|  UUCP_PUBLIC (explicitly or implicitly), are translated to a VMS
|  valid name of they would not normally be an allowable VMS name.
|  Names with mixed case are also translated.  The rules for this
|  special case name translation are the same as the rules for
|  MultiNet's Name translation rules for NFS.  For example, a Unix
|  file such as
|  
|  gcc-2.1.tar.Z
|  
|  is stored on VMS as:
|  
|  GCC-2.1$5NTAR$5N$Z
|  
|  The following table shows how various "destination file names"
|  specified by remote systems will be interpreted locally.  Note:
|  The "Related Name" is the name of the source file, which is
|  propagated to the destination file if the destination file is a
|  directory.
|  ----------------------------------------------------------------------
|  Destination File Name  Related Name  Result String
|  ----------------------------------------------------------------------
|  ~/aaa/bbb/ccc          xxx.yyy       if ccc is not a directory:
|                                        UUCP_PUBLIC:[aaa.bbb]ccc
|                                       if ccc is a directory:
|                                        UUCP_PUBLIC:[aaa.bbb.ccc]xxx.yyy
|  ~user/file             xxx.yyy       UUCP_PUBLIC:[user]file
|  ~user                  xxx.yyy       UUCP_PUBLIC:[user]xxx.yyy
|  ~/aaa/bbb/             xxx.yyy       UUCP_PUBLIC:[aaa.bbb]xxx.yyy
|  ~/aaa/bbb.dir          xxx.yyy       UUCP_PUBLIC:[aaa.bbb]xxx.yyy
|  ~/a.b                  xxx.yyy       UUCP_PUBLIC:[000000]a.b
|  ~uucp/a.b              xxx.yyy       UUCP_PUBLIC:[000000]a.b
|  ~uucp/                 xxx.yyy       UUCP_PUBLIC:[000000]xxx.yyy
|  ~/                     xxx.yyy       UUCP_PUBLIC:[000000]xxx.yyy
|  /usr/spool/uucppublic/aaa.bbb
|                         xxx.yyy       UUCP_PUBLIC:[000000]aaa.bbb
|  X.something            xxx.yyy       UUCP_SPOOL:X.something
|  D.something            xxx.yyy       UUCP_SPOOL:D.something
|  UUCP_PUBLIC:[aaa.bbb]ccc
|                         xxx.yyy       UUCP_PUBLIC:[aaa.bbb]ccc
|  UUCP_PUBLIC:[aaa.bbb]  xxx.yyy       UUCP_PUBLIC:[aaa.bbb]xxx.yyy
|  UUCP_PUBLIC:aaa.bbb    xxx.yyy       UUCP_PUBLIC:[000000]xxx.yyy
|  ----------------------------------------------------------------------
|  
|  The unix convention of the significance of ~ as a leading part of
|  a file spec is that ~joe or ~joe/ refers to the home directory
|  for user 'joe', and ~ or ~/ refers to the home directory for the
|  current user which in the case of the typical uucp transfer is
|  the "uucp" user, so uucp/, /, /usr/spool/uucppublic/ all are
|  simple attempts to refer to the login directory of the uucp
|  account(s).  Our name translation routines explicitly don't allow
|  access to directories outside of UUCP_PUBLIC, but attempt to
|  accomodate references to this by just letting these be references
   UUCP FILE TRANSFERS                                      Page 9-5
|  Directories


|  to subdirectories of UUCP_PUBLIC.
|  
|  When we transfer things to neighbor Unix uucp sites, we typically
|  keep a subdirectory of ~/ (/usr/spool/uucppublic/) as our
|  "private" interchange point.  Hence the above accomodation allows
|  this similar capability.
|  
|  
|  9.3  Directory Listings
|  
|  Many uucp sites that keep extensive sets of files available for
|  uucp'ing keep a directory listing in their top-level directory.
|  The file is normally named ls-lR; its output is the equivalent of
|  the VMS command
|  
|          DIRECTORY [...]/SIZE=ALL/DATE
|  
|  Fetching this ls-lR file Lets you have access to s listing of the
|  contents of the directory:
|  
|          $ UUCP -m "neighborname!/uucp/ls-lR" /neighborname/
|  
|  When we've fetched the same file from uunet (not recently), we've
|  simply asked for "uunet!/ls-lR.Z".  Note that this file is
|  compressed.  Decompress it with the compress utility supplied
|  with DECUS uucp.
|  
|  
|  9.4  ACL-Based Security in the UUCP_PUBLIC Tree
|  
|  We have incorporated facilities to allow ACLs placed on files and
                          _
|  directories in the UUCPPUBLIC tree to control access to those
|  files by neighbor systems.
|  
|  The normal VMS mechanism of using Authorize to grant Identifiers
|  to particular accounts is not appropriate for use with UUCP:
|  Although each UUCP login is a different username, they share a
|  common UIC, and the granted ID's are associated with the UIC, not
|  the Username.  This is not really an issue, since even if we did
|  have separate UICs for each uucp neighbor, additional levels of
|  control would be needed anyway.  (For example, calls originated
|  by the local system are always performed under the same UIC
|  regardless of which neighbor is being called.)
|  
|  In order to support all of the things we would like to do while
|  still maintaining security, we need to base access controls on
|  the following factors:
|  
|        o  Which site we are talking to
|  
|        o  Which account was used to call in
|  
|        o  Whether we called out or whether they called in
   UUCP FILE TRANSFERS                                      Page 9-6
|  ACL-Based Security in the UUCP_PUBLIC Tree


|        o  Whether we or they originated the transfer request
|  
|        o  Whether a request is to READ or WRITE a file
|  
|  The mechanism is based on dynamically granting and revoking
|  identifiers to the process running UUCICO to describe the details
|  of its state.  The names of the identifiers that are dynamically
|  granted (and revoked) are the following:
|  
|  UUCP_ID_SYS_<hostname>               (which uucp neighbor is it?)
|  UUCP_ID_USER_<login_username>   
|                             (with what username did they call in?)
|  UUCP_ID_CALLIN or UUCP_ID_CALLOUT          (who placed the call?)
|  UUCP_ID_REMOTE_REQUEST or UUCP_ID_LOCAL_REQUEST 
|                       (who made the request to transfer the file?)
|  -----------------------------------------------------------------
|  
|  ANY of the above identifier names may optionally:
|  
|        o  Exist or not, depending on your goals
|  
|        o  Be defined as executive mode logicals that translate to
|           the desired identifier names
|  
|  ACLs on Files and/or directories in UUCP_PUBLIC may grant or deny
|  access depending on the desired combination of any or all of the
|  above identifiers.
|  
|  A reasonable setup might be:
|  
|        o  Allow read-only access to certain directories in
|           UUCP_PUBLIC.
|  
|        o  Maintain separate subtrees under UUCP_PUBLIC for each
|           uucp neighbor from whom you will accept file transfers.
|           These directories are writable only by the corresponding
|           neighbor sites.
|  
|        o  If you have some directories in which large files are
|           kept so that other sites may fetch them, allow read
|           access to those directories only when the remote system
|           is calling you; ie, when they are paying for the call
|  
|  
|  9.5  Security Issues
|  
|  9.5.1  Files Sent By Your Users
|  
|  The question may arise, "what files can a user on my machine send
|  to other sites via the uucp command?"  The answer is, "any files
|  to which they would normally have read access".
|  
|  In other words, the uucp command can't read any files that the
|  user can't read by any other means (e.g.  COPY), nor does it
|  place any additional restrictions on such access.  (This is
|  reasonable, since even in the absence of the uucp command, users
   UUCP FILE TRANSFERS                                      Page 9-7
|  Security Issues


|  could encapsulate files in mail messages and send them out
|  anyway.)
|  
|  
|  9.5.2  Files Requested By Your Users From Other Systems
|  
|  What files may be requested is under the control of your uucp
|  neighbors.  Inbound file transfer requests ("pull mode") from
|  your users can't cause files to arrive anywhere except in the
|  UUCP_PUBLIC tree.
|  
|  
|  9.5.3  Files Sent To You By Other Sites
|  
|  These will always arrive in the UUCP_PUBLIC tree.
|  
|  
|  9.5.4  Files Requested By Other Sites
|  
|  Other sites will not be able to fetch any files from your machine
|  that you haven't put in the UUCP_PUBLIC tree.
|  
|  
|  9.5.5  Special Considerations for the UUCP_PUBLIC Tree
|  
|  There exists the possibility that a local user with "E" access
|  (access by specific file name) to a directory on the same volume
|  as the UUCP_PUBLIC tree, and with write access to the UUCP_PUBLIC
|  tree, could do something like this:
|  
|          $ set file sys$sysdevice:[000000]sys$common.dir -
|                          /enter=uucp_public:[000000]system.dir
|  
|  This would extend the scope of the UUCP_PUBLIC tree to include
|  the named directory.  For example, neighbor sites could now
|  request files from your SYS$COMMON:[SYSEXE] directory by
|  requesting files from UUCP_PUBLIC:[SYSTEM.SYSEXE].  They could
|  also try to send files to such directories.
|  
|  This does not really open any new holes, since
|  
|        o  The only files which uucico will copy out to your
|           neighbor sites are ones that are readable to the uucp
|           UIC group;
|  
|        o  Since the uucp UIC group is used only by uucp, this
|           means only files that are marked readable by World; and
|  
|        o  Files that are readable by world could be copied (or
|           e-mailed, or for that matter, printed and mailed out on
|           paper) out by your users anyway.
|  
|        o  Similarly, since directories outside of the uucp tree
|           will not be owned by a uic within the uucp group, only
|           directories which are writeable by world could be
|           written into by uucp by this method.
   UUCP FILE TRANSFERS                                      Page 9-8
|  Security Issues


|  In other words, nothing is do-able by this method that isn't
|  do-able by any user on your system anyway.
|  
            ______
|  However, either of the following steps will prevent, or minimize
|  the impact of, such an action:
|  
|        o  Keep the UUCP_PUBLIC tree on a volume that will have no
|           secure information.  (If you have a separate volume for
|           your NEWS_DEVICE, this might be a good place to put
|           UUCP_PUBLIC since there are no sensitive files among
|           news articles.)
|  
|        o  Deny your users write access to the directories in the
|           UUCP_PUBLIC tree.  If desired, allow the UUCP_LOGIN id
|           write access to these directories via explicit ACLs.
|           This lets other sites send anything in, which is benign,
|           and local users can still send arbitrary files out, but
|           they can't directly setup things in the directories in
|           the tree.


   9.6  Unix UUCP Compatibility Issues

   9.6.1  Stream Files

   VMS files opened for reading (that is, for transmission to a
   remote uucp system) are always opened for stream access.  Thus,
   even if the file was not written in stream mode, uucico sees it
   as if it was.

   File opened for writing (that is, files being received from a
   remote system) are opened for writing in stream mode.
|  
|  An exception to this rule applies if the remote uucp system is
|  recognized as running DECUS uucp V2.0 or greater; in this case,
|  VMS files are transferred with attributes intact.  (The "Created"
|  date of the file on the target system remains the same as it was
|  on the originating system, while the "Revised" date of the target
|  file reflects the time of the copy.)


   9.6.2  Lower Case in File Names

   Some Unix uucp implementations send D- and X-files with sequence
   "numbers" that can include not only the ten digits but also the
   fifty-two upper- and lower-case characters.  Unix distinguishes
   case in filenames:  "A.TXT" is not the same file as "a.TXT".
   We've seen instances where a Unix system sent us two sets of
   files, with sequence "numbers" that differed only in case.

   We correct this by applying the following transformation to file
   names received from any remote uucp system:  We scan the file
   name extension from left to right, and insert an underscore (_)
                       _______
   every time the case changes.  The extension is assumed to start
   in lower case (as it does, since the first thing in the extension
   is the remote system name, which is always in lower case.)
   UUCP FILE TRANSFERS                                      Page 9-9
   Unix UUCP Compatibility Issues


   This is done by uucico, when we receive both the X- and D-files.
   It is also done within uuxqt, when we encounter the D-file name
   in "F" and "I" commands in the X-file.












                              CHAPTER 10

                   REGISTERING AS AN INTERNET DOMAIN



   After you have things running well and reliably, you should
   consider registering your organization as an Internet domain.
   Note that sending your map entry to rutgers and seeing it come
                                                          ___
   back in the appropriate posting in comp.mail.maps does not
   constitute Internet domain registry.


   10.1  Why Should I Become a Domain?

   There are several good reasons for becoming an Internet domain.


   10.1.1  Acquiring an "@-style" Address

   As a user on a machine within an Internet domain, you can
   legitimately publish your "net address" on your business card,
   your postings on DECUServe, etc., as user@host.company.com (or
   whatever).  A lot of non-registered sites who are in the uucp
   maps use things like user@host.uucp, and while this will
   sometimes work (especially from uucp sites, but also from some
   Internet sites) it is not officially correct.  (This is discussed
   in a bit more detail later.)


   10.1.2  Better Mail Connectivity

   Anyone else who handles Internet domain-style addresses correctly
   will be able to send mail to you, even if they've never heard of
   you before, and even if they don't use the uucp maps.  Here's
   how:

   If their machine doesn't know how to send to "host.company.com",
   it then tries "company.com"; if that fails, it asks its
   "nameserver" (another machine on the Internet, which either keeps
   or has access to up-to-date routing information for all
   registered domains) how to reach your domain.  If you are
   properly registered, the nameserver will respond with
   instructions to send the mail to the Internet site designated as
   your "forwarder".
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-2
   Why Should I Become a Domain?


   Your forwarder then sends the mail to the designated "gateway"
   for your domain -- probably your uucp machine -- and your gateway
   then figures out how to get the message to the correct host
   within your domain.  This is the whole point of your managing
   your own domain:  The nameservers don't need to know how to reach
   any of the machines in your domain other than the domain gateway.


   10.1.3  Supporting an Internal Network

   If you have several machines in your company, perhaps connected
   to your uucp machine via DECnet (or other mechanisms), and you
   want users on those machines to be able to send and receive uucp
   mail, becoming an Internet domain lets you avoid publishing
   separate map entries for them all.  They can become
   machine1.company.com, machine2.company.com, and so on.  Once you
   are registered as "company.com", you need do nothing else
   externally to set this up -- just arrange for the proper
   forwarding to and from the machines in your domain, and add their
   names to your uucp machine's map entry, so the rest of the net
   will know that they can be reached through you.  (DECUS uucp
   provides for such forwarding, as described later in this
   chapter.)


   10.2  Why Do I Need A Forwarder?

   At this point many people wonder why each Internet-registered
   uucp host must have a designated "forwarder":  Why can't the
   Internet simply send any mail destined for user@host.company.com
   to a single designated forwarder, which would deliver it to uucp
   hostname "company"?  There are several reasons why this wouldn't
   work:

   First, there is no guarantee that the uucp hostname and the
   second-level domain name ("company" in this example) will be the
   same.  Your particular site has to have an entry in the
   forwarder's routing tables specifying the uucp hostname for your
   domain's gateway machine.

   Second, there's no reason to suspect that "company.com" is even
   reachable via uucp; forwarders usually support many different
   transport mechanisms.  Again, your domain must be entered in the
   forwarder's routing tables, with a field specifying delivery via
   uucp.

   Finally, if there were a single Internet/uucp forwarder, it would
   have to carry an unreasonable amount of traffic.

   In self-defense (mostly to avoid having to answer hundreds of
   "how do I send mail to uucphost!user" questions from their
   users), many Internet sites have set things up so that mail sent
   to "user@uucphost.uucp" from one of their machines will be sent
   to a known Internet/uucp gateway, with the addresses set up so
   that the gateway recognizes the target machine as a uucp host,
   and so just sends the mail via uucp to uucphost!user.  This works
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-3
   Why Do I Need A Forwarder?


                            ___________
   because in this case the originating machine knows the uucp
   hostname, and so can construct the address properly.  It works
                                   __
   best if the originating machine is the Internet/uucp gateway in
   question.  But, as we've said before, this use of ".uucp" as an
   unofficial domain name is fraught with peril, since ".uucp" also
   happens to be an officially registered zone.


   10.3  How Do I Register?

   There are currently two good ways for uucp sites to become
   Internet domains.

   One is registry through the "uucp zone", which is administered
   for the Network Information Center by Uunet.  This is probably
   the more appropriate method if you will be setting up a domain
   with more than one machine in it.  The file
   [.DOC.DOMAINREG]UUNETREG.TXT has details.

                                 NOTE

           The uucp zone was formerly administered by
           Stargate Information Services, but this function
           has been taken over by uunet.


   The other method is to register your machine(s) in the "US
   domain".  This seems to be more appropriate if you expect to be
   running just a single machine.  See
   [.DOC.DOMAINREG]USDOMAIN.TXT .

   There are other files in [.DOC.DOMAINREG] which provide
   additional information on the domain registry process and on
   domains in general; see [.DOC.DOMAINREG]AAAREADME.TXT .

   In either case you will need to find a "forwarder" -- a machine
   that can forward mail sent to you from the rest of the Internet.
   There are two points about forwarders which seem to be poorly
   understood (at least, a lot of people seem to have misconceptions
   about these points):

         o  First, the forwarder must be a "real Internet" machine,
            meaning that it must be connected via TCP/IP to the rest
            of the Internet.  This is because Internet sites, upon
            finding out from the relevant nameservers that mail to
            you is to be sent to your forwarder for delivery, will
                                                       ___ ______
            attempt to send the mail to your forwarder via TCP/IP.

         o  Second, you need not have a "direct uucp" connection to
            your forwarder.  For that matter, the forwarder need not
            use uucp at all to forward your mail; DECnet or TCP/IP,
            for example, will work fine.  If your forwarder does use
            uucp to send mail to you, a direct (one-hop) connection
            is obviously preferable, but is not required.
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-4
   What Then?


   10.4  What Then?

   Okay, you've sent off your application form and received
   confirmation that your new domain is active.  Now what?


   10.4.1  Update Your Map Entry

   The "#N" line in your map entry stays the same.

   Add a line of the following form:

           #F      for1.company.com[,for2.co2.com...]

   where "for1..." are the Internet name(s) of your forwarders.
   (Yes, you can have more than one.  I'm not sure why you'd want
   this unless one of them is unreliable.)

   In the pathalias data, add

           uucpname    .yourcompany.com

   and

           uucpname =  machname.yourcompany.com
           uucpname =  yourcompany.com

   making appropriate substitutions for all elements.  The first
   (note the leading period!) is a domain gateway declaration to
   pathalias (the program that interprets the maps), declaring
   "uucpname [your uucp hostname] is a gateway to domain
                                                            _______
   .yourcompany.com".  The latter are name equivalences, or aliases,
   ensuring that pathalias can recognize any of the strings which
   represent your uucp host.  (You have to be able to recognize your
   own name, however disguised.)

   Note that uucpname and machname might be the same name, but don't
   have to be; machname here might well be a DECnet node name.
   There is no concern here that a given "machname" might be used by
   other sites, since it is qualified by the rest of the domain
   name.

   The second of the two aliases shown allows people to send mail to
   users on the "uucp gateway host" at your company without knowing
   its machname.  If you publish map entries for more than one
   machine, such an alias declaration is probably only appropriate
   in one of them.

   If you're going to take advantage of the ability to "hide" your
   internal network behind your domain, read the "Networks" section
   of the pathalias appendix, and change the map entry as
   appropriate.

   As usual, mail your updated map entry to rutgers!uucpmap .
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-5
   What Then?


                                 NOTE

           The file [.DATA.MAPSRC]README.  is not entirely
           up to date on these points.



   10.4.2  Change Logical Names

   In [.BIN]UUCP_SYSTARTUP.COM, change the definition of
   UUCP_DOMAIN_NAME to reflect your name.


   10.4.3  Publish Your New Address

   You can now have business cards and so on printed that show your
   brand-new Internet address.  One caution:  Many Internet sites
   still do not use the name domain server, and others do not
   properly understand "MX" (mail forwarding) records, so for the
   widest possible acceptance, publish two addresses.  One (the
   preferred one) will show just your "native" Internet domain name,
   and the other will show explicit forwarding.  For example, if
   uunet (whose Internet name is uunet.uu.net) is your forwarder,
   and you are user@aridus.megacorp.com, you might publish the
   following addresses for yourself:

           user@aridus.megacorp.com
           user%aridus.megacorp.com@uunet.uu.net

   Make sure before you do this that your forwarder can handle names
   of the second form.  (Uunet can do so, and most others can at
   least potentially do so, but ask to make sure that it's been set
   up.)


   10.4.4  Set Up The Mail Address Rewrite File

   The mailer looks for a file called UUCP_CFG:MAIL_REWRITE.RULES
   for address rewriting rules.  If this file exists, the mailer
   uses the rules in it to transform addresses from one form to
   another.  These can be used to allow mail sent by users on your
   internal network (which probably uses a non-Internet style
   addressing syntax) to go out to the net in "standard" form.  You
   can also use them, in some cases, to repair particular addresses
   that are giving you or a downstream mailer some trouble.

   An example rules file (from dcs.simpact.com) is included in
                        ___
   [.EXAMPLES.CFG].  Do not use this file as-is!  Print it out and
   study it while reading this section, and use it as a basis for
   your own rules file.

                                 NOTE

           The basic functionality of the address rewriter
           was extracted from ANU NEWS.  Except for the
           addition of the 4 rule sets, the rewriter works
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-6
   What Then?


           just like the one in NEWS.  You cannot, however,
           use NEWS's rewrite rules file, as NEWS's
           rewriting is performed in a different context.



   10.4.4.1  Rule Sets

   There are four rule sets that are applied to addresses at various
   points in the mailer.  The rules for all four sets are given in
   the rewrite file.  These rule sets are:


   10.4.4.1.1  Inbound-To -

   The target address in the uucp envelope (rmail command in the X
   file) is processed for possible rewriting.  The primary purpose
   here is to allow qualified domain addresses to be converted into
   whatever local syntax will achieve delivery.  For example, at
   Simpact, "jeh@onyx.simpact.uucp" can be rewritten as "onyx::jeh"
   since "onyx" is connected to "simpact.uucp" via DECnet, and our
   DECnet node names are used for the lowest-level domain names.
   The rewrite rule

           *@*.simpact.com        \002::\001

   takes care of all such cases.

                                 NOTE

           The "To:" header in the message body is NOT
           processed by the mail address rewriter.



   10.4.4.1.2  Outbound-From -

   Outbound from rules are essentially the inverse of the inbound-to
   rules.  That is, they allow you to create qualified domain names
   from the "From" addresses given to you by the hosts in your
   domain.

   For example, at Simpact, when someone sends mail from
   decnetnode::user, we want it to go out on the net with a "From"
   address of user@decnetnode.simpact.com .  The rewrite rule

           *::*        \002@\001.simpact.com

   accomplishes this.


   10.4.4.1.3  Inbound-From -

   The "From" address in an inbound message can be rewritten.  You
   can use this to repair problem addresses, converting them into a
   form that can be replied to.
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-7
   What Then?


   For example, at Simpact, mail that comes from CSNET sites arrives
   with "From" lines of the form

           user%domainname@relay.cs.net

   which is unreplyable.  But it invariably works if we send the
   reply to user@domainname.  So the rewrite rule

           *%*@relay.cs.net     \001@\002

   is used to strip off the "@relay.cs.net" and change the first "%"
   to a "@".


   10.4.4.1.4  Outbound-To -

   When an address is presented to the mailer for outbound delivery,
   it can be processed by the rewriter before being routed via the
   PATHS. database.  This can be used to "handcraft" routes to
   hard-to-reach sites where the normal automatic routing does not
   produce a valid path.

   For example, mail sent to Bitnet sites (user@machine.bitnet) goes
   to a Bitnet gateway.  The particular gateway is automatically
   selected via the uucp maps.  Unfortunately, the gateway that is
   usually chosen at Simpact can't seem to handle many Bitnet
   addresses.  But we know that cunyvm.cuny.edu is a Bitnet gateway,
   and mail sent through there has never failed.  So the rewrite
   rule

           *@*.bitnet      \001%\002.BITNET@cunyvm.cuny.edu

   is used to force the use of this gateway.

   After the mailer performs an outbound-to transformation it looks
   at the resulting address to see if it contains a "!".  If it
   does, it assumes that the address contains a complete uucp
                          ___
   bang-path, and so will not pass the address to the standard
   router (for routing via PATHS.).  If the rewritten address does
   not contain a "!", or if no transformation was performed, the
   address is passed to the router.

   This convention allows a special kind of rewrite rule which is
   useful for directing mail to one of your uucp neighbors for
   routing.  Suppose, for example, that site "router" is one of your
   uucp neighbors and that they can handle ".bitnet" addresses well;
   you might want to use the following outbound-to rewrite:

           *@*.bitnet        router!\001@\002.bitnet

   The result of this rewrite will be a "mixed mode" address.  In
   this case (only) DECUS uucp will interpret such an address as
   "send to uucp host 'router', and ask them to send the mail to
   \001@\002.bitnet".
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-8
   What Then?


   10.4.4.2  Rewrite file format

   Three types of lines may appear in UUCP_CFG:MAIL_REWRITE.RULES:
   comments, set selectors and rules.  The first character of the
   line decides which kind of line it is.


   10.4.4.2.1  Comments -

   If a line begins with a "#", it is a comment and will be ignored.


   10.4.4.2.2  Set selectors -

   If a line is surrounded by square brackets (that is,
   "[" ... "]"), it is a rule selector.  The text inside the "[...]"
   declares that subsequent rules, until the next selector (or the
   end of the file), are to be placed in the given set.  The text
                      ____
   within the "[...]" must match one of the following exactly
   (lowercase won't work):

           [INBOUND-TO]
           [OUTBOUND-FROM]
           [INBOUND-FROM]
           [OUTBOUND-TO]

   If the selector is not valid, the rules following it are ignored.

                                 NOTE

           At the present time, there is no report sent
           anywhere when a bad selector is encountered.



   10.4.4.2.3  Rules -

   Anything else in the file is assumed to be a rule.  A rule
   consists of two fields specifying an input pattern and an output
   pattern.  Any amount of whitespace separates the two fields.  The
   input pattern may contain wildcards - a "?" matches a single
   character and a "*" matches a substring.

                            _______
   When an input pattern is matched, the output pattern is applied.
   Text is copied from the input string to the output string using
   the rule given in the output pattern.  Special flags in the
   output pattern will be replaced by corresponding wildcard text
   from the input string.  The flags are specified using a "\"
   followed by a three-digit OCTAL number indicating the position of
   the wildcard in the input pattern.

   Suppose you have the following rules:

           *!* \002@\001.my.domain
           *::* \002@\001.my.domain
   REGISTERING AS AN INTERNET DOMAIN                       Page 10-9
   What Then?


   If these were declared as [OUTBOUND-FROM] rules, then the
   following transformations would occur on the "From" addresses in
   mail going out from your machine:

           marty!ta2     ==>     ta2@marty.my.domain
           monica::ta3   ==>     ta3@monica.my.domain

   Rules are tried in the order in which they appear in the file.
   The first one that matches terminates the search.  This allows
   you you to place a catch-all rule at the end of all the rules in
   a given set.  For example, this might be a set of [INBOUND-TO]
   rules:

           *@marty.acci.com      marty!\001
           *@esther.acci.com     \001
           *@acci.com            \001
           *@*.acci.com          uucp_postmaster

   In this rule set, mail aimed at "marty.acci.com" is delivered to
   "marty" via uucp.  "esther.acci.com" is the "acci.com" gateway,
   mail to that system should be reduced to just the name of the
   user.  There are no other hosts in the "acci.com" domain, so mail
   to them should be forwarded to the postmaster for further action.

                               Warning!

           The rule

                   *!* \002@\001.my.domain

           makes for a nice example but lousy practice.
           Mail that was initiated by one of your uucp
           connections, and routed through you, may have a
           "From" address that will match the pattern.  If
           that neighbor is not in your domain, you don't
           want to rewrite their "From" addresses.



   10.4.4.3  Suggestions for Rewrite Rules for Internet Domains

   (by Tom Allebrandi)

   If you have a registered Internet domain acting as a gateway to
   only DECnet connected hosts, you should probably use

           [INBOUND-TO]
           *@*.your.domain             \002::\001
           *.your.domain!*             \001::\002
           [OUTBOUND-FROM]
           *::*                        \001@\002.your.domain

   If you have a mixture of conections (that is, some of the hosts
   in your domain are reached via DECnet, and some are reached via,
   for example, uucp), you will have to enumerate them.  That is:
   REGISTERING AS AN INTERNET DOMAIN                      Page 10-10
   What Then?


           [INBOUND-TO]
           *@dnhost.your.domain        dnhost::\001
           *@uuhost.your.domain        uuhost!\001
                          ...  etc ...

   If you do not have a registered Internet domain, you should use
   the following for your DECnet hosts:

           [INBOUND-TO]
           dnhosta!*                   dnhosta::\001
           dnhostb!*                   dnhostb::\001
           [OUTBOUND-FROM]
           *::*                        yourhost!\001!\002

   On the [INBOUND-TO] you cannot use

           *!*                         dnhosta::\001 because that
   will intercept all messages passing through your host.  On the
   [OUTBOUND-FROM] side, you need to include your host name as it is
   likely that you will not publish your DECnet host names.  If you
   do not publish your DECnet host names, you must give something
   that is relative your gateway host.

   Note that this latter problem only applies to the RFC822 From:
   address.  The UUCP From_ line is self-relative (assuming that
   every host that touches it handles it correctly.)
|  
|  
|  10.4.4.4  Special Note for MX Users
|  
|  Users of Matt Madison's "MX" (Mail Exchange) package should be
|  aware that, under MX 3.1C, MX will use the uucp rewrite rules
|  file if the logical name MX_UUCP_REWRITE is defined.  MX 3.1C is
|  available from the DECUS Library.


   10.5  What If Another Machine In My Company Is Already
         Registered?

   Or, to put it another way, "What if my company already has an
   Internet domain name?"  (See the next section, "Machines vs.
   Companies".)

   For example, simpact.com has been registered -- but not in the
   uucp zone; we have a small VAX running Unix with a real TCP/IP
   connection to the real Internet. [2]  So I can't very well send
   off a domain registration form asking for "simpact.com"; not only
   will it be rejected as a duplicate name, but I'll look silly.
   ("Don't those people talk to each other?")

   I should feel relieved; I don't have to apply for a domain name.
   On the other hand, before I can publish my address as
   ____________________

   [2]  The situation would be much the same if its connection to
   the world was via uucp.
   REGISTERING AS AN INTERNET DOMAIN                      Page 10-11
   What If Another Machine In My Company Is Already Registered?


   jeh@dcp.simpact.com (my uucp machine), I have to make sure that
   mail sent to the Unix machine will get here, and that mail which
   I need to send through the Unix machine gets sent there, and so
   on.

   This requires a communication link between the Unix machine and
   myvax (obviously uucp will work), and appropriate entries in the
   various configuration files on both sides.  (We can't give more
   details because we haven't done it yet.)  If the "machine that's
   already registered" is an Internet machine, you can go ahead and
   publish a uucp map entry reflecting your connection to it.  If
                                         ___
   it's connected to the world via uucp, its map entry should be
                                         ___
   revised to reflects its connection to you.  In this case there is
   no need for a map entry for your machine; the whole point of
   domains -- one of the whole points, anyway -- is to keep from
   having to publish map entries for all machines within a domain
   (in this case, within a company).

   If the link between the "already-registered machine" and yours is
   something other than uucp (perhaps DECnet/Ultrix, or some flavor
   of TCP/IP), please let us know how you did it.  (We may be able
   to provide more help later; subscribe to the VMSnet newsgroups
   and watch for announcements and updates to the manual.)


   10.6  Domain Names:  Machines vs. Companies

   Technically speaking, it isn't the machines that are registered
   (other than in the US domain).  A name like acci.com doesn't
   refer to a machine, but rather to a company, organization, or
   other group of people responsible for the machines in the named
   domain.  A lot of people get this point wrong, at least in casual
   conversation (and probably elsewhere in this document).

   Usually it doesn't matter; in practice, a domain name is
   registered to get a particular machine "known" to the network.
   Of course to do this the machine needs a name of its own; the
   domain name isn't it, so we tack on another name, for example
   esther.acci.com, meaning "machine esther in the domain acci.com".

   Having said all that, we will now confuse the issue by noting
   that the gateway machine for acci.com (that is, the machine that
   accepts all mail destined for the acci.com domain, and forwards
   it to the appropriate machines within that domain) can interpret
   *@*.acci.com any way it pleases, and in particular in ways that
   blur the distinction between domain and machine names.  For
   instance, Tom Allebrandi, who lives on esther.acci.com, publishes
   his address as ta2@acci.com.  Technically, acci.com is just a
   domain, administered by a particular organization (ACCI);
   ________
   machines in that domain are esther.acci.com and marty.acci.com.

   But in "ta2@acci.com", "ta2" is an alias for the right mailbox
   within the acci.com domain.  It matters not to the rest of the
   net whether that mailbox is on esther.acci.com or marty.acci.com;
   it is up to the domain gateway to get it delivered.  Tom lives on
                                 __
   esther, and esther happens to be the gateway, but it would still
   REGISTERING AS AN INTERNET DOMAIN                      Page 10-12
   Domain Names: Machines vs. Companies


   work if tom lived on marty, as long as the domain gateway knows
   how to reach "ta2".  So the "host name" part -- "esther." or
   "marty." -- can be dropped out of the domain name in published
   addresses, for convenience.

   Small domains like acci tend to do it this way since the aliasing
   is easy (perhaps just a matter of entering one or two or a dozen
   VMS Mail forwarding commands).  For a large domain, the aliasing
   can become a nightmare to administer, and so the domain
   administrator generally requires the full domain name and
   provides no intra-domain aliasing (except perhaps for those who
   live on or near the gateway node).

   For example, it is only due to administrative issues that you
   can't simply send mail to olsen_k@dec.com.  (Would you like the
   job of setting up an alias for everyone on the DEC's internal
                      ___
   network?)  But you can send to user@decwrl.dec.com if user lives
   on any of the machines (not just decwrl) at DEC's Palo Alto
   facility; the facility is small enough that their postmaster can
   maintain aliasing tables for everyone who works there.


   10.7  Special Acknowledgement

   Thanks to Bill Blue, Erik Fair, Glenn Sueyoshi, and Paul Vixie,
   whose articles and e-mail on these subjects contributed both to
   this chapter and to the "Address Formats" appendix.  All
   mistakes, on the other hand, are our fault.












                              CHAPTER 11

                       GETTING READY TO RUN NEWS



   At this point you have a working uucp mail machine, possibly
   known via an Internet domain-style address.  You can now think
   about setting up news.

   Before proceeding, find the file [.DOC.NEWS_SETUP]NEWS.ANNOUNCE .
   This file contains the most recent (at the time this package was
   assembled) editions of articles that are posted monthly to the
   newsgroup news.announce.newusers.  Print this file and read it
   before proceeding.  (Once you have NEWS running, you can add the
   articles in this file to your news database, for benefit of your
   users.)


   11.1  Newsgroups -- What to Carry?

   In setting up News and arranging for "news feeds" to and from
   other sites, you must decide which newsgroups you intend to carry
   on your machine.  You probably do not want to accept everything
   that's available.  The Usenet groups, listed in "List of Active
   Newsgroups" in NEWS.ANNOUNCE, plus all of the alternate
   hierarchies (see "Alternative Newsgroup Hierarchies", also in
   NEWS.ANNOUNCE) would total around sixteen megabytes a day, and a
   large percentage of it would be "noise".

   The following sections describe the small subset of newsgroups
   which all VMSnet sites should carry, and others which will likely
   prove valuable.


   11.1.1  Strongly Recommended Newsgroups from the Usenet Hierarchy

   Although the term "Usenet" is commonly (loosely) used to refer to
   "all sites exchanging network news", technically there is a list
   of "official" Usenet newsgroups.  This list appears in "List of
   Active Newsgroups".  From this list, only the following are
   required for effective use of DECUS uucp:


   comp.mail...              technically you only need
                             comp.mail.maps (to keep your map files,
                             and therefore PATHS., up to date), but
                             at least some of the information in the
   GETTING READY TO RUN NEWS                               Page 11-2
   Newsgroups -- What to Carry?


                             other subgroups here will be useful to
                             you, and the total volume is low.  If
                             you must keep things to a bare minimum
                             eliminate .elm, .mh, and .sendmail .

   comp.os.vms               this is in the "if you don't want this,
                             why are you reading this?" category.

                                                                ____
   comp.org.decus            same comment as preceding.  Volume very
                             low.

   news...                   nearly everything here is important.
                             news.software.b, news.software.c, and
                             news.software.notes can be eliminated,
                             but volume is low enough in those
                             groups that it isn't worth the bother.

   news.software.anu-news    absolutely vital.

   The following groups are quite optional, but have proved
   valuable:


   comp.sources.misc         miscellaenous source programs (mostly
                             in C)

   comp.sources.unix         C programs for Unix

   A surprising percentage of these sources are usable under VMS
   (assuming you have the VAX C compiler).


   11.1.2  The VMSnet Newsgroups

   Following established practice (cf. the gnu, alt, biz, etc.,
   newsgroup hierarchies), we have established an alternate
   newsgroup hierarchy for discussion of VMSnet-related issues:
   Operational questions, bug reports and fixes, greetings from new
   sites, and so on.  Initially, these will only be available from
   other DECUS uucp sites.  We strongly encourage you, as a VMSnet
   site, to agree to feed these groups to other sites (both VMSnet
   and non-), if at all possible.

   A list of the VMSnet newsgroups may be found in the file
   GROUPS.VMSNET .


   11.1.3  Others

   11.1.3.1  Telebit Newsgroup

   If you are using a Telebit modem, you should carry the group
   "biz.telebit" .  (The "biz" hierarchy was established to allow
   businesses to conduct exchanges which would violate the
   non-commercialism guidelines agreed to for the Usenet groups.)
                                           _________
   Volume in the entire "biz" hierarchy is extremely low.
   GETTING READY TO RUN NEWS                               Page 11-3
   Newsgroups -- What to Carry?


   11.1.3.2  "to." Newsgroups

   By convention, News sites generally establish a newsgroup called
   "to.<hostname>", for example to.simpact .  These are only
   exchanged with neighboring sites, and are not "routed through" to
   neighbor's neighbors, and so on.  Among other things, these
   groups are used for the exchange of "ihave/sendme" messages
   (discussed later).  Thus, you would have a "to.neighborname"
   newsgroup for each neighbor with whom you exchange news.


   11.1.3.3  Local Newsgroups

   It should not escape your notice that News can be a very
   effective tool for intra-company communication as well as
   communication with the existing world.  You will probably want to
   create a hierarchy appropriate for your needs These newsgroups
                    ___
   should obviously not be fed to sites outside of your company.
   Their names are usually the company name or an abbreviation
   thereof.  For example, we use simpact..., Hewlett-Packard uses
   hp..., and so on.


   11.1.4  Decisions, Decisions

   Don't feel that you have to get all of this right the first time;
   everything can be changed and fine-tuned to your heart's content.
   So pick an initial set of newsgroups, realize that you'll make it
   better later on, and proceed.


   11.2  Arranging for News Feeds

   Now that you have some idea of what newsgroups you want, you'll
   need to find somewhere to get them.  At least one of your network
   neighbor system managers probably asked you "do you want News?"
   when you asked for a connection; your answer should have been
   "not yet".  Now is the time to call them up (or send them mail)
   and say, "I need a news feed".

   All news sites are expected to maintain a username, or mail
   forwarding name, called "usenet".  Mail sent there will be
   directed to the person responsible for maintaining the news
   software and data base on the machine.  Sending queries about
   news feeds to "neighbornode!usenet" may get a better response
   than sending to "neighbornode!postmaster".

   However you contact them, tell them that you can send and receive
   News in "compressed rnews" format.  This is the preferred method
   for transferring news in the uucp world.  The compression/
   decompression program, COMPRESS.EXE, is supplied in [.BIN].  (It
   is largely compatible with the LZCMP/LZDCM distributed through
   DECUS, but has some special features for handling compressed
   news.)
   GETTING READY TO RUN NEWS                               Page 11-4
   Arranging for News Feeds


   Most well-connected uucp sites will carry the Usenet newsgroups
   listed above.  (But they may not be willing to feed you,
   especially if you want a lot of newsgroups.  A full news feed
   ties up a modem and considerable CPU resources for the "feeding"
   site.)

   Your main news feed may not carry the newsgroups in the VMSnet
   hierarchy.  To find a feed for these groups, send mail to Terry
   Poot, tp@mccall.com; he is coordinating the VMSnet sub-network.

   If none of your network neighbors carry the newsgroups you want,
   or if they can't feed you for some reason, ask them for
   suggestions as to where to get a feed.  Or, inspect the map files
   for your region and look for sites that claim to be running News.

   You can also get news from PSI or uunet.  (In fact, this is one
   of the primary main reasons that a lot of sites subscribe to a
   commercial service.)  They are committed to carrying the entire
   Usenet hierarchy plus all "alternate" hierarchies, so if you like
   you can get all your news from them -- including the VMSnet
   newsgroups.


   11.3  Feeding News to Other Sites

   Obviously, if a majority of sites wanted only to receive news but
   didn't want to bother passing it on to anyone, the network would
   cease to function.  At first VMSnet sites will, of necessity, be
   "end nodes" as far as the non-VMSnet newsgroups are concerned,
   but this condition should not last for long.  If it does, we will
   be accused -- and rightly so -- of letting others pay the freight
   for our traffic.

   So, if you can provide a news feed to one or more of your uucp
   neighbors, we urge you to consider doing so.

   On the other hand, this is not a responsibility to be assumed
   lightly.  Do not agree to provide a news feed unless you can be
   reasonably certain that you can continue to do so for the
   forseeable future; at the very least, if you must cut a site off
   from your news feed, you should try to give them a few weeks'
   warning.

   Also, if your system is down a lot, you don't want other people
   relying on you for news feeds.  (An unreliable feed is worse than
   none at all!)

   This will be a non-problem for some time, since you won't be
                                               ______
   well-enough known; nobody out there will be asking you for news
   feeds (other than other VMSnet sites, asking for the VMSnet
   newsgroups).
   GETTING READY TO RUN NEWS                               Page 11-5
   ANU News and DECUS uucp


   11.4  ANU News and DECUS uucp

   Geoff Huston's News for VMS, referred to here and elsewhere as
   "ANU News" (for Australia National University News), or simply
   "News", is an implementation of Unix's "network news"
   functionality for VMS.

   The version of ANU News included with this distribution of DECUS
|  uucp [1]  is Version 6.1-ALPHA4, as received from Geoff Huston.
   We have applied several bug fixes received from the net to the
   News source files and recompiled them.  (These changes are
                                 _
   described in [.NEWS61]0PATCHESAPPLIES. .)

   DECUS uucp does include several programs, command procedures, and
   other files which integrate ANU News with uucp -- that is, they
   allow ANU News to exchange News with other sites (whether running
   ANU News, or Unix news implementations) via the uucp transport
   mechanism.  Some of these are modifications of files supplied
   with ANU News, while others are our own invention.  The latter
   are in directories other than those defined by Geoff.

   We'll describe all of the files, the directory organization, and
   so on, in the next chapter.


   11.5  News System Configurations

   An organization with a single VMS machine will run News in the
   simplest possible way, that is, with the News software and data
   base on that machine.  But ANU News supports several more complex
   configurations.  The following sections describe the
   possibilities.

                                 NOTE

           Just as we advised you to get your uucp links
           running for mail transfers before attempting to
           deal with News, we also advise you to get News
           running in "single-node" mode before making
           things more complicated.



   11.5.1  VAXclusters

   A VAXcluster should be viewed as a "single News environment",
   with one copy of the News database on a disk visible to all
   cluster nodes (or at least all nodes from which users will be
   accessing it via the News user interface program).  As usual for
   clusters, the logical names that define the News environment must
   ____________________

   [1]  Note that while ANU News is included with DECUS uucp, it is
       ____ __
   not part of DECUS uucp; we supply it for convenience.  It isn't
   that we wouldn't be proud to have it under our umbrella; on the
   contrary, it deserves recognition and acclaim on its own.
   GETTING READY TO RUN NEWS                               Page 11-6
   News System Configurations


   be defined on each node in the cluster.  If you are exchanging
                                               ___
   News with either sites (by whatever means), one node in the
   cluster should be chosen to run the batch job that performs this
   function (described in full later on).  By default this will be
   the same node in which uucp runs, but it doesn't have to be.
   Processing incoming and outgoing News can easily be done by
   another node in a VAXcluster, allowing better use of I/O
   bandwidth and CPU resources.


   11.5.2  Independent News Machines Connected by DECnet

   If you have other VMS machines in remote locations, connected by
   low-speed (less than 56 Kbps) DECnet links, each of these
   machines would likely keep its own copy of News data base.  Users
   would run the News software to interact with the data base on
   their local machine.  Periodically (usually nightly), the News
   software on each machine will automatically forward (feed) News
   posted on each machine to all of the others, as directed by the
   configuration files.  The transfers are normally performed during
   times when the systems and their DECnet links aren't in used for
   much else.


   11.5.3  Independent News Machines Connected by uucp

   Additional programs, command procedures, etc., provided with
   DECUS uucp allow the news to be forwarded via uucp as an
   alternative to DECnet.  This is most probably how you will
   exchange News with existing "Usenet" sites.  This is not an
   either-or decision; some systems can be fed via DECnet and others
   via uucp.


   11.5.4  NNTP Via DECnet

   If you have other VMS machines nearby, connected to your
   "primary" News machine via high-speed DECnet links, you can use
   the "NNTP client/server" capabilities of news, and avoid keeping
   copies of the News database on each system.

   NNTP stands for Network News Transfer Protocol.  Users on the
   other machines use the NNTP "client" program (supplied as part of
   ANU NEWS) to read and respond to the news; this program's user
   interface is exactly the same as if they were running News
   directly on their local machine.  But instead of accessing a
   local News database, the NNTP client program uses DECnet to
   communicate with News "server" software running on the primary,
   accessing the News database remotely.

   Only the news articles that are actually read are moved across
   the network, and no articles are stored on the client machines.
   GETTING READY TO RUN NEWS                               Page 11-7
   News System Configurations


   11.5.5  NNTP Via TCP/IP

   You can also use NNTP if your server and client communicate via a
   TCP/IP network.  This is probably irrelevant if all of the
   systems are VMS systems and have DECnet available.  But if, for
   instance, you have a Unix system that can communicate with your
   VMS "news server" via TCP/IP, you need not arrange for news feeds
   to the Unix system; you can run NNTP news reader software on the
   Unix system, and it can obtain the articles to be displayed from
   the VMS server.


   11.5.6  NNTP with Unix Server

   Conversely, if you already have a Unix system that's getting
   news, and if your VMS system can communicate with it via TCP/IP,
   you can run the ANU News client software on the VMS system and
   let it fetch news as required from the Unix-based NNTP news
   server software.  The Unix NNTP server and client software are
   available from other sources (see the article, "Usenet Software:
   History and Sources").


   11.5.7  Variations

   You can also "mix and match" these options.  A VMS NNTP News
   server can serve some clients via DECnet and others via TCP/IP,
   and also allow local users to access the data base directly, and
   also forward and accept nightly news database updates amongst
   remote machines in the organization.

   The one thing that probably does not make sense is to run the
                    ___
   NNTP News client and server software on the same machine, except
   for test purposes.


   11.6  A Bit More about NNTP

   The difference between NNTP and doing batched nightly news
   transfers (whether via DECnet or uucp) is a little like the
   difference between copying a set of files from a remote system to
   your local system, editing one or two files on the local system,
   and copying the changed files back, and simply editing one or two
   files via remote file specifications on the edit commands (EDIT
   node::file...) .  In both cases the editor itself is running on
   your local machine, and the user interface is the same.  But in
   the former case the file transfer is all performed outside of the
   edit session, and the entire set of files is copied over as a
   unit and then copied back.  In the latter case the data transfer
   is done within the edit session, and only those files actually
   being modified are transferred.
   GETTING READY TO RUN NEWS                               Page 11-8
   A Bit More about NNTP


   11.6.1  Why Do We Send More Stuff Over Slower Links?

   At first glance the options described -- NNTP over high-speed
   links, and transfer-all-new-news over low-speed links, seem
   backwards:  If you're maintaining a complete news database on two
   different machines, and having them update each other each night,
   why would you do this over a low-speed connection?  With a
   low-speed link, wouldn't it be better to just transfer the
   newsitems being read and written?

   The trouble is that you can't do that until someone runs the News
   client program, since until then you don't know what people want
   to see -- and the low-speed connection doesn't provide sufficient
   response time for interactive use (like editing a remote file
   when the DECnet link runs at just 9600 bps).


   11.6.2  NNTP For Batched News Transfers

   Now, obviously, if a News client can use NNTP to ask a server for
   a particular news item (for display to the interactive user who's
   running the client software), an News system with its own data
   base could also use NNTP to ask a server for a news item (for
   updating its own news data base).  Indeed, NNTP can be used for
   batched news transfers via a part of NNTP called "ihave/sendme".
   This part of NNTP can be used not only over DECnet and TCP/IP
   links, but uucp links as well.

   The idea is that the server sends the other system a list of news
   items that are eligible for transfer ("I have..."), and the other
   system sends back a (presumably smaller) list of the ones it
   wants ("Send me...").  In this way, a system that gets news from
   several sources can avoid receiving -- and paying for
   transmission time for -- multiple copies of the same item.

   (The multiple copies won't result in multiple appearances of the
   same item in the News data base, since News rejects incoming
   items whose Identification headers have already been seen, but
   they do take time to transfer; the intent of ihave/sendme is to
   reduce this redundant transmission time.)


   11.6.3  Combinations

   News can be set up with some newsgroups kept locally and others
   "served", ie accessed on another machine via NNTP.


   11.6.4  NNTP Warning

   We have no experience with NNTP Client/Server modes; all of the
   following assumes that you are setting up either a single-node
   News system, or multiple News systems with DECnet and uucp for
   standard (non ihave/sendme) batched file transfers.  We hope to
   provide additional information on the NNTP Client/Server and
   ihave/sendme options in a future version of the documentation.












                              CHAPTER 12

                    INSTALLING AND INTEGRATING NEWS



   This chapter will tell you how to set up the ANU News software
   and integrate it with uucp, so that you can exchange News with
   other sites.

                                 NOTE

           Before attempting to send or receive network
           news, you should have the uucp package running
           and properly exchanging mail with your neighbor
           sites.  You can of course run News in "local
           mode", that is, without forwarding to or
           accepting from other sites, before you have
           accomplished this.



   12.1  The ANU News Distribution

   The ANU News distribution, as supplied with with DECUS uucp, is
   in [UUCP.NEWS61...] (if you have restored all of the savesets).
   The vital files are NEWS.EXE (which we have already copied to
   [.BIN], NEWS.HLB (which we have copied to [UUCP.NEWS]), and
   [.NEWS61.NEWS_DOC]NEWSDOC.TXT (which we have copied to
   [UUCP.DOC.NEWS_SETUP]).


   12.1.1  Documentation

   The news documentation as supplied by Geoff Huston appears in
   [.NEWS61.NEWS_DOC].  In addition to the "plaintext" form in
   NEWSDOC.TXT, it is also present in PostScript, LaTeX, and RTF
   formats.

   Before proceeding, print whatever form of the News User's Guide
   (henceforth called the NUG) you can, read all chapters except
   "NEWS Commands" thoroughly, and skim "NEWS Commands".  (Relax;
   "NEWS Commands" is the bulk of the document.)

   Some additional information appears in text files in
   [.NEWS61.NEWS_DIST] and [.NEWS61.NEWS_DOC].  The latter directory
   also contains samples for the News configuration files, which we
   will be editing in later steps.  We have copied these to
   INSTALLING AND INTEGRATING NEWS                         Page 12-2
   The ANU News Distribution


   [.EXAMPLES.NEWS_MGR];


   12.2  Installing News:  Comments on the News User's Guide

   You are now presumably ready and anxious to bring up News and see
                                                                ____
   how (and if!) it all works.  (In our experience at least, it does
   work.)  The last chapter in the NUG, "Installing News", provides
   some step-by-step instructions.

   The following subsections amount to "release notes" for this
   material, based on actual installation experiences.  The idea is
   to read a section in the "Installing News" of the NUG, then read
   the corresponding section here before doing anything.

   The subsection headers below reference the names of the
   corresponding sections in the NUG.


   12.2.1  Installing News Files

   This section of the NUG assumes you have received the news
   distribution as several different savesets.  The instructions for
   restoring the various savesets into directories do not apply to
   the DECUS uucp distribution; this has already been done.


   12.2.2  Compiling and Linking NEWS

   NEWS 6.1-ALPHA4, as supplied with DECUS uucp, was compiled and
   linked under VMS Version 5.5, without support for any TCP/IP
   networking package.  You should not need to recompile it unless
   you need to run under a significantly earlier version of VMS or
   need to include TCP/IP support.  (Actually, we've found that it
   works fine under VMS V5.4 as well as 5.5.)

   If you do want to rebuild it, you'll need the components of the
   [.NEWS61...] tree out of the NEWSDEVEL saveset.  Make whatever
   changes you wish to the source files, then submit
   [.NEWS61.NEWS_BUILD]NEWSBUILD.BAT to your favorite batch queue.
   Read the comments in [.NEWS61.NEWS_BUILD]NEWSBUILD.COM to
   determine the command procedure parameters required for the
   TCP/IP package you are using, and pass these to NEWSBUILD.BAT .
   It will in turn invoke [.NEWS61.NEWS_SRC]NEWSBUILD.COM, which
   will only compile those objects dated earlier than their
   corresponding sources.

   (NEWSBUILD.BAT performs the SET DEFAULT command described in the
   NUG as being critical to the build procedure; in fact, that's the
   whole reason for NEWSBUILD.BAT's existence -- it doesn't matter
   what your default directory is when it's run.  NEWSBUILD.BAT will
   also work fine interactively.)

   When the build is done, the new executables will be in
   [.NEWS61.NEWS_DIST], along with a new copy of NEWS.HLB.  Inspect
   NEWSBUILD.LOG to ensure that no errors occurred.  (Be sure to
   INSTALLING AND INTEGRATING NEWS                         Page 12-3
   Installing News: Comments on the News User's Guide


   check for "undefined symbols" messages from the Linker; these are
   reported only as warnings, but are almost always fatal if you try
   to execute the resulting code.)  When you're satisfied with the
   results, you can delete the old .EXE and .HLB files that were
   supplied with the distribution.


   12.2.3  Creating NEWS Accounts

   The account created in this step will not be used by an actual
   person (and, in fact, you can disable interactive logins for it).
   Rather, it exists to provide an account under which the NEWSSKIM
   batch job will run, and to provide a mail destination for News
   items that are received as mail.  (NEWSSKIM automatically "reads"
   the mail directed to this account and imports it into News.)  The
   use of the term "News manager" in connection with this account is
   somewhat misleading, as "manager" usually is a reference to a
   real person, but in this case it refers only to an automatic
   procedure.  In order to avoid conflicts with the NUG, we will
   continue to refer to this as the "News manager" account, but in
   quotes, so you'll know that this "manager" isn't a person.

   To create this account, simply invoke the command procedure
   [.BIN]UUCP_CONFIG , and choose option 4.

   As noted in the NUG, this account requires SYSPRV.  In a cluster
   environment it will need NETMBX also.

   You can disable all but batch access for this account; its only
   purpose is to run the command procedure NEWSSKIM.COM in a
   self-repeating batch job.

   The default device and directory for this account should be
   NEWS_MANAGER_DEV:[000000].  The account should have a paging file
   quota (PGFLQUOTA) of at least 20,000 blocks.

   All tests with this software have used the VMS standard file
   protection (S:RWED,O:RWED,G:RE,W).  Problems may occur if your
   system uses a different default.  Insofar as the NEWSSKIM batch
   job is concerned, these problems may be obviated by placing the
   following command in the news manager account's LOGIN.COM :

           $ SET PROTECTION=(S:RWED,O:RWED,G:RE,W)

   We have done this in the supplied LOGIN.COM in [.NEWS_MGR].


   12.2.4  Define Logical Names

   The referenced file, SETUP_LOG_EXAMPLE.COM, does not appear in
|  the current version of NEWS.  For DECUS uucp, logical names are
|  defined in the CONTROL. file and created by the UUCP_SYSTARTUP
|  procedure when run with the P2 parameter equal to "INCLUDE_NEWS".
   INSTALLING AND INTEGRATING NEWS                         Page 12-4
   Installing News: Comments on the News User's Guide


|  Therefore, to define the logical names, edit your
|  [UUCP.CFG]CONTROL. file and then use the GENERATE_CONTROL.COM
|  command procedure to "activate" the new file.
|  [UUCP.EXAMPLES.CFG]CONTROL. shows all of the news-related names
|  that can be defined.

   Following is a description of some of the logical names that may
   be defined for NEWS.


   12.2.4.1  NEWS_ORGANISATION

   This logical supplies the string which News places in the
   "Organization" header for locally-created news items.  Set it to
   a (brief) exposition of your company name and location.  (Users
   may override this with a process-level logical name.)


   12.2.4.2  NEWS_DEVICE

   This is a rooted directory specification which identifies the
   root of the directory tree in which the individual news item
   files will be stored.  Newsgroups are kept in subdirectories
   under this directory; for example, all articles in comp.os.vms
   will be stored in NEWS_DEVICE:[COMP.OS.VMS].

   If this logical is not defined in CONTROL., UUCP_SYSTARTUP.COM
   will define it as UUCP_DISK:[NEWS.] or UUCP_DISK:[UUCP.NEWS.] if
   it finds them (in that order of priority).


   12.2.4.3  NEWS_ROOT

   This points to a directory in which NEWS stores its indexed
   files.  NEWS.HLB also has to live here.

   Unless overridden by an explicit declaration in CONTROL.,
   UUCP_SYSTARTUP.COM assumes that this is the same as the root
   directory of the NEWS_DEVICE tree.  In other words, NEWS_ROOT is
   assumed to be the same directory that would be identified as
   NEWS_DEVICE:[000000].

   Note that while it is perfectly okay to place [.NEWS] under
   another directory (as we have done here), the logicals NEWS_ROOT
                            __ ____
   and NEWS_DEVICE must not in turn be defined in terms of rooted
   directories!  In other words, something like the following would
   ___
   not work:

           UUCP_DEVICE     UUCP_DISK:[UUCP.]
           NEWS_ROOT       UUCP_DEVICE:[NEWS]
           NEWS_DEVICE     UUCP_DEVICE:[NEWS.]

   The same warning applies to the NEWS_MANAGER and NEWS_MANAGER_DEV
   logicals defined next.  (Thanks to Rand P. Hall, who bumped into
   this problem and posted the explanation to the net.)
   INSTALLING AND INTEGRATING NEWS                         Page 12-5
   Installing News: Comments on the News User's Guide


|  Due to the very large number of tiny files which are created in
|  this tree, it is best if it is on a separate disk device, or at
|  least one where the fragmentation caused by the creation and
|  deletion of these tiny files will not adversely affect other
|  applications.  (We note in passing that the actual impact of disk
|  fragmentation on most applications is greatly exaggerated.)
|  
|  If possible, it is a good idea to place NEWS_DEVICE on a disk by
|  itself, while NEWS_ROOT should be on the same device as the
|  [UUCP...] tree.
|  
|  
|  12.2.4.4  NEWS_MANAGER, NEWS_MANAGER_DEV
|  
|  These logicals needed to be defined in previous versions of DECUS
|  uucp.  In Version 2.0, they are automatically defined by
|  UUCP_SYSTARTUP, and these definitions cannot be overridden.
|  
|  These logicals point to the directory in which the "news
|  management" files are kept.  These include a number of control
|  files (to be created in a later step) and subdirectories which
|  are used for forwarding news to other nodes.  Its functions are
|  thus analogous to the combined functions of the [.CFG] and
|  [.SPOOL] directories used by uucp.  In addition, the login
|  default directory for the "news manager" account must be
|  NEWS_MANAGER_DEV:[000000].
|  
|  In the DECUS uucp distribution, NEWS_MANAGER is supplied as a
|  subdirectory, [UUCP.NEWS_MGR], and NEWS_MANAGER_DEV is the same
|  directory defined as a rooted logical.
|  
|  UUCP_SYSTARTUP.COM automatically defines these to point to the
|  NEWS_MGR directory on the same disk device, and with the same
|  upper-level directories (if any), as the NEWS directory pointed
|  to by the NEWS_DEVICE logical.  In other words,
|  
|  -----------------------------------------------------------------
|  if NEWS_DEVICE is       then NEWS_MANAGER & NEWS_MANAGER_DEV are
|  -----------------------------------------------------------------
|  ddcu:[UUCP.NEWS.]       ddcu:[UUCP.NEWS_MGR], ddcu:[UUCP.NEWS_MGR.]
|  ddcu:[NEWS.]            ddcu:[NEWS_MGR], ddcu:[NEWS_MGR.]
|  -----------------------------------------------------------------
|  
|  Thus, if NEWS_DEVICE is a top-level directory on a different disk
|  from the UUCP tree and NEWS_ROOT (which is what we recommend),
|  NEWS_MANAGER should be a top-level directory on the same disk as
|  NEWS_DEVICE.


   12.2.4.5  NEWS_MGR_UN

   equates to the username of the "News manager" account created in
   the preceding step.  This is used in subsequent INIT/BATCH and
   SUBMIT commands.  We assume that this is "NETNEWS" if the
   CONTROL. file does not say otherwise.
   INSTALLING AND INTEGRATING NEWS                         Page 12-6
   Installing News: Comments on the News User's Guide


   12.2.4.6  NEWSMAIL, RNEWS

   These are the names of "mail drop" accounts which are used when
   sending News as mail.  Mail sent to either of these usernames
   must be forwarded to the "News manager" username, defined by the
   logical NEWS_MGR_UN.  UUCP_SYSTARTUP.COM defines these
   automatically.


   12.2.4.7  USENET

   You need to arrange for personal e-mail sent to the username
   "USENET" to be forwarded to the person responsible for the
   management of the news system.  Note that "News manager" in this
             ___
   step does not refer to the account created previously, but rather
   to the real person (probably you!) who will be responsible for
   creating and deleting newsgroups, approving control messages, and
   so on.  The established convention on the net is for this person
   to be addressable as "USENET"; that is, if another site wants to
   send you a query such as "Do you carry rec.nude?", they will send
   it to usenet@yoursite unless they know your actual username.

   In addition, when "control" messages (such as create group,
   delete group, cancel newsitem, and so on) are received by News,
   its default behavior is to not execute them right away, but
   convert them into DCL command procedures and mail same to the
   USENET account.  You are supposed to review them, pass judgement
   on them, and, if you deem appropriate, EXTRACT them and execute
   them.  (You can also arrange for News to handle control messages
   without your supervision; in this case it will mail confirmation
   messages to USENET.  See the description of the
   NEWS_EXECUTE_CONTROL logical name, preceding.)

   You can create an actual account called USENET, but you will then
   have to remember to log into it periodically to check up on
   pending work.  Of course, this may be preferable to being
   bothered with control message execution requests in your regular
   VMS account!
|  
|  The supplied UUCP_SYSTARTUP.COM establishes a system logical
|  name, USENET, pointing to the same equivalence string as the
|  logical UUCP_POSTMASTER (defined in UUCP_SYSTARTUP.COM).  You
|  should not need to change this default unless you want the mail
|  relating to NEWS maintenance sent to someone other than the UUCP
|  postmaster.  To specify someone else other than the
|  UUCP_POSTMASTER to receive this mail, you should specify a
       _
|  UUCPCFG:CONTROL.  file entry for this selection.


   12.2.4.8  NEWS_MGR_ID

   translates to an identifier name, which must be created and
   granted to the "News manager" account, and also to the accounts
   of any real people who are to be authorized to execute News
   management commands.  The command procedure assumes that the
   identifier name is NEWSMANAGER, which is what the NUG describes.
   INSTALLING AND INTEGRATING NEWS                         Page 12-7
   Installing News: Comments on the News User's Guide


   You can use something else as long as you change it
   consistently. [1]


   12.2.4.9  NEWS_ADDRESS

   This should translate to the same name as UUCP_DOMAIN_NAME , and
   the supplied command procedure performs this translation
   automatically.  It is used to generate "Reply-To" headers which
|  are used for mail replies to posted articles.  If you don't
|  specify it, UUCP_SYSTARTUP will automatically use your domain
|  name (from the logical UUCP_DOMAIN_NAME), or if that is not
|  specified, hostname.UUCP .


   12.2.4.10  NEWS_NODE and NEWS_PATHNAME

   These logicals define the name by which this system will be known
                                             ___
   to the rest of the News network.  This is not (usually) the
   DECnet node name of the system (as described in the NUG), but
   rather the system's uucp hostname, as defined by the logical
   UUCP_HOST_NAME .  This should be the same as the name of the
   system as defined in the entry in NEWS.SYS that defines the local
   node's filter set.  (NEWS.SYS is a NEWS configuration file,
   described later in this chapter.)

   NEWS_NODE is the string that NEWS looks for in the Path: line of
   incoming articles to determine whether an incoming article has
   already passed through this node.

   NEWS_PATHNAME is the string which NEWS inserts in the Path: line
   of outgoing articles (whether locally-generated or route-
   through).  It should normally be the same as NEWS_NODE .
|  
|  By default, UUCP_SYSTARTUP.COM defines both of these to be the
|  same as the UUCP_HOST_NAME or UUCP_DOMAIN_NAME logical (with
|  preference for the former).


   12.2.4.11  NEWS_BATCH_QUEUE

   translates to the name of a batch queue in which the "News
|  manager" batch job, NEWSSKIM.COM, will run.  UUCP_SYSTARTUP.COM
|  will create the queue if it doesn't already exist.
|  
   ____________________

   [1]  If you are new to identifiers, you may well wonder why we
   can't use the identifier that's already associated with the "News
   manager" account (normally the same as its username).  The answer
   is that an identifier that was created automatically as the
   result of the creation of an account, and which therefore
   translates to a UIC rather than to general identifier number,
   cannot be granted to other accounts.  We have to create a
   separate identifier for the purpose; this will be done in a
   subsequent step.
   INSTALLING AND INTEGRATING NEWS                         Page 12-8
   Installing News: Comments on the News User's Guide


|                                NOTE
|  
                                     ________
|          Previously this queue was required to be
                                                    ____
|          single-threaded; that is, its /JOB_LIMIT must
|          have been one, and no more.  Now, all the issues
|          necessary to allow concurrent execution of NEWS
|          "ADD" and/or "SKIM" processing have been
|          resolved.  If you want to allow multiple inbound
|          RNEWS jobs to execute, you can specify this with
|          a UUCP_CFG:CONTROL. file entry:  Set
|          NEWS_BATCH_QUEUE_CONCURRENT_JOBS to the value you
|          wish for the /JOB_LIMIT for this queue.  If
|          unspecified, the default is one.
|  


   12.2.4.12  NEWS_BATCH_NODE

   On clustered systems, this logical defines which cluster node
   will execute the jobs in NEWS_BATCH_QUEUE.  For nonclustered
   systems, this logical's equivalence name should be a hyphen
   ("-"), as in the supplied file.


   12.2.4.13  NEWS_EXECUTE_CONTROL

   translates to "Y" or "N".  If "N", received control messages will
   be converted to command procedures and MAILed to the "USENET"
   account.  If "Y", received control messages (to create and delete
   newsgroups, etc.) will be processed automatically, and
|  confirmation notices will be MAILed to USENET.  The default for
|  this parameter is "N".  We recommend leaving it this way unless
|  you are comfortable with what News is doing with the control
|  messages you receive from other sites.
|  
|                                NOTE
|  
|          These control messages include "newgroup" and
|          "rmgroup" messages which can cause creation (or
|          deletion) of newsgroups.  If your feed includes
|          the "alt." heirarchy, it is rather common to
|          receive many "rmgroup" and/or "newgroup" messages
|          for completely bogus groups.  These usually occur
|          in flurries with the resulting activities
|          referred to as a "newgroup/rmgroup war".
|  


   12.2.4.14  NEWS_AUTO_CREGRP

   translates to "Y" or "N".  If "N", received news items that are
   destined for newsgroups that don't exist on your machine will be
   placed in the newsgroup "junk".  If "Y", the missing newsgroups
   will be created automatically.
   INSTALLING AND INTEGRATING NEWS                         Page 12-9
   Installing News: Comments on the News User's Guide


                                 NOTE

           A hazard of automatically created newsgroups is
           that this mechanism has no way of knowing when to
           create the groups as moderated.  If you use this,
           watch for incoming "cregrp" control messages and
           execute those which specify moderated groups.



   12.2.4.15  NEWS_TIMEZONE

   The three-letter abbreviation for the timezone in which your news
   system runs.  The supplied command procedure creates this
   automatically, based on the uucp logical UUCP_TIME_ZONE.

   This timezone must be something that is recognized by other news
   software.  At least one popular Unix-based news system, "C-News",
   will simply throw away articles with an unknown "timezone" field.
   (One site we heard from uses "EST" and just changes
   NEWS_GMT_OFFSET as required.)
|  
|  Remember to change the value of UUCP_TIME_ZONE when your area
|  enters or leaves Daylight Savings Time (if it does).


   12.2.4.16  NEWS_GMT_OFFSET

   This logical provides the offset, in VMS time format, from
   Coordinated Universal Time (UTC, formerly known as GMT) to your
   local time zone.  NEWS uses this value to convert the times in
   news item headers (which are passed around the network in UTC
   form) to local time.
|  
|  By default, UUCP_SYSTARTUP.COM will define this logical correctly
|  based on the value of UUCP_TIMEZONE, provided that the latter is
|  in one of the formats allowed by RFC822 (see the description of
|  UUCP_TIMEZONE in the chapter on configuring uucp).


   12.2.4.17  Other Logical Names

   Several other logicals, mostly associated with batch queues and
   with the NEWSSKIM procedure, are mentioned in the template
   CONTROL. file.  These are described in the comments.


   12.2.5  Create NEWS Logical Names

   This completes the customization of the control file for news.
   You may now define the logical names, via

           $ @[.BIN]UUCP_SYSTARTUP LOGICALS INCLUDE_NEWS
   INSTALLING AND INTEGRATING NEWS                        Page 12-10
   Installing News: Comments on the News User's Guide


   and then

           $ @[.BIN]GENERATE_CONTROL

   to produce a new "normalized" control file.

   If you elect in a later step to change the locations of one of
   the directories, etc., simply edit the CONTROL. file to reflect
   the changes, then repeat the above two steps to redefine the
   logical names.


   12.2.6  Global DCL Symbols

   [.BIN]USERCMDS.COM defines the NEWS symbol as

           $ NEWS == "$UUCP_BIN:NEWS"

   Edit your system-wide login command procedure to execute
   USERCMDS.COM for interactive logins, or otherwise make
   USERCMDS.COM available to those who will be using News.


   12.2.7  Installing NEWS.EXE As a Known Image

   We will do this in a later step.


   12.2.8  Initial Environment

   12.2.8.1  Creating the NEWSMANAGER identifier

   The UUCP_CONFIG command procedure creates this identifier and
   grants it to the NEWSMGR account when you create the account.
   All that is necessary is to grant this identifier to your own
   account, via the following command to AUTHORIZE:

           UAF> GRANT/IDENTIFIER NEWSMANAGER yourusername


   12.2.8.2  Creating the directories

   These directories, as named by the appropriate logicals, already
   exist under [UUCP].

   DECUS uucp defines another special directory used for
   News-related log files.  This is [.NEWS_LOG] in the DECUS uucp
   distribution.

   Use option 5 of [.BIN]UUCP_CONFIG to ensure that all file
   ownerships and protections are set correctly for the NEWS
   directories.
   INSTALLING AND INTEGRATING NEWS                        Page 12-11
   Installing News: Comments on the News User's Guide


   12.2.8.3  Copy NEWS.HLB to NEWS_ROOT

   If your NEWS_ROOT directory is somewhere other than
   UUCP_DISK:[UUCP.NEWS], copy NEWS.HLB to NEWS_ROOT: .


   12.2.9  Installing NEWS.EXE

   NEWS.EXE already appears in the [.BIN] directory in the DECUS
   uucp distribution.  To install the image with the necessary
   privileges, use the command

           $ @[UUCP.BIN]UUCP_SYSTARTUP INSTALLS INCLUDE_NEWS


   12.2.10  News Control Files

   In this step we create the control or configuration files used by
   News.  Sample files for each of these are in
   [.EXAMPLES.NEWS_MGR].

   Note that these files use the Unix convention that a comment is a
   line beginning with a "#" in column 1, and continued lines are
   denoted with a trailing "\" on every line of the set except the
   last.

   In the "live" news system, all of these files will reside in
   NEWS_MANAGER. [3]

   The following sections will describe each file in detail.


   12.2.10.1  NEWS.SYS

   This file establishes the incoming and outgoing news "filter
   sets", which determine which newsgroups your site will accept
   into its database, and which newsgroups your site will in turn
   forward to each of its neighbor sites.

   The first entry in the file is for the local node (though the
   entry for the local node need not be the first entry; the local
   node's entry is identified by the empty <flags> and <transmission
   command> fields (trailing "::").  The system name here (the field
   at the beginning of the entry) must be the same as that defined
   by the logical NEWS_NODE .

   The next entry in the example file specifies a dummy systemname,
   "mapsink", which is used for collecting the uucp map data.  This
   tells News to copy all newly-arrived maps into the directory
   named in this entry; the NEWSSKIM batch job will find them and
   ____________________

   [3]  The NUG describes editing NEWSSKIM.COM as part of the
   customization, and indicates that this file resides in NEWS_ROOT.
   In the DECUS uucp distribution, NEWSSKIM.COM resides in [.BIN],
   and no customization of it is necessary.
   INSTALLING AND INTEGRATING NEWS                        Page 12-12
   Installing News: Comments on the News User's Guide


   automatically update the mail routing data base ([.DATA]PATHS.).
   The directory name, [UUCP_MAPS], is "magic" (that is, there is
   code in NEWSSKIM.COM that looks for this name explicitly) and
   must not be changed.  You can copy this entire entry from the
   example file.

   The next entries are for various "news neighbors".  Read the
   comments in the file to see why things are set up as they are.

   Each site should be explicitly enabled to receive the newsgroup
   "to.theirhostname", and in the entry for your system, you should
   enable the receipt of "to" (i.e. all "to.xxx" groups).

   For each entry that specifies news to be sent to another site
   (that is, all but the first, which is the entry for the local
   site), we need to specify the <flags> and <transmission command>
   fields.  In the configuration described by the example file,
   ihave/sendme is not used with any of the news neighbors, so all
   of the <flags> are "B" (send in B News format).  The
   <transmission command> specifies a directory and file name into
   which the outgoing news for the system in question will be
   written.  This should always be

           NEWS_MANAGER_DEV/[POST_<channel><hostname>]NEWS.BATCH^B

   Where <hostname> is normally the same as the system name at the
   head of the command, and <channel> dictates how the News will get
   there:

         o  (empty), e.g. [POST_SITE1], means send via DECnet

         o  "DECNET_", e.g. [POST_DECNET_SITE2], means send via
            DECnet (same as previous)

         o  "UUCP_", e.g.  [POST_UUCP_SITE3], means send
            uncompressed news via uucp to the "rnews" program on the
            target system

         o  "UUCP$CMPRS_", e.g.  [POST_UUCP$CMPRS_SITE4], means send
            __________
            compressed news via uucp to the "rnews" program on the
            target system

   The latter is the method preferred by almost all existing Unix
   News sites.

   The filename, NEWS.BATCH, can be anything; NEWSSKIM looks for all
   files in the named directories.

   Note that for DECnet transfers, <hostname> is used as a DECnet
   node name.  For uucp transfers, it is used as a uucp hostname,
   and it must be a neighbor system -- that is, one that is named in
   [.CFG]SYSTEMS .

   For each <hostname> to which you will be forwarding News, create
   these directories as subdirectories under NEWS_MANAGER_DEV.  For
   example, for site inland, we did the following:
   INSTALLING AND INTEGRATING NEWS                        Page 12-13
   Installing News: Comments on the News User's Guide


           $ CREATE/DIRE NEWS_MANAGER_DEV:[POST_UUCP$CMPRS_INLAND]

   and similarly for all other sites to which we forward News.

   Finally, create the directory used by the map update mechanism:

           $ CREATE/DIRE NEWS_MANAGER_DEV:[UUCP_MAPS]

   Ensure that the "news manager" owns and has write access to all
   of these.


   12.2.10.2  NEWS.SYSD

   This file is similar to NEWS.SYS (described previously).  It
   contains an entry for your own node, plus one for each news
   neighbor, and specifies the "distributions" which each news
   system willl accept.  There are several "distribution" newsgroup
   names shown in the supplied file:  "world", "usa", "na" (for
   North America), "ca" (for California), and "ba" (for [San
   Francisco] "Bay area").  News will not accept or forward messages
   whose "Distribution:" headers specify a name that does not appear
   in the target node's distribution filter set.  This is used most
   often to limit the distribution of messages on a geographical
   basis.  Your prospective news feed sites should be able to tell
   you the appropriate names to use here.


   12.2.10.3  NEWS.DISTRIBUTION

   This file describes the topology of the News network from the
   point of view of your site, but only for your adjacent nodes.
   Its main purpose is to prevent "loops", ie the "reflection" of
   news from a site back to that site, which would cause no great
   harm (due to the message ids) but which would waste transmission
   bandwidth.

   Note that an entry is required for the mythical "mapsink" site,
   used for automatic processing of received map data.  (See the
   description of the NEWS.SYS file above, and the comments in both
   files.)


   12.2.10.4  NEWS.ALIASES

   Defines local aliases for newsgroup names.  These may be used
   temporarily while newsgroup name changes are in progress.


   12.2.10.5  MAILPATHS.

   When someone on your site tries to post a message to a moderated
   newsgroup, News forwards the message to the moderator.  (See
   Chapter 7 in the NUG, and also the article "List of Moderators"
   in NEWS.ANNOUNCE).  Rather than requiring all sites to maintain
   an up-to-date list of moderators' addresses, the Usenet backbone
   INSTALLING AND INTEGRATING NEWS                        Page 12-14
   Installing News: Comments on the News User's Guide


   sites have agreed to provide a "forwarding" service.  The
   comments in the file explain the mechanism further.

   In almost all cases, DECUS uucp sites will need but a single
   entry in this file, specifying "backbone".  The target address is
   the address of your "nearest" backbone site (nearest in terms of
   the mail network topology, which is not necessarily the same as
   geographical nearness).  Unless a site name jumps out at you as
   the obvious choice, you will have to inspect the map files to
   find out where these various sites are and where they are likely
   to be in relation to yours.


   12.2.10.6  UUCP_BIN:NEWSSKIM.COM

   This is the command procedure that runs as a batch job under the
   "News manager"'s account.

                                 NOTE

           The DECUS uucp version of NEWSSKIM.COM (in
           [UUCP.BIN]) is substantially different from that
                                   ______
           in [.NEWS61.NEWS_DIST]; ignore the latter version
           and use ours.

|  
|  You should not need to alter NEWSSKIM.COM .  There are several
|  optional aspects of its operation; these are controlled by
|  logical names which should be defined in [.CFG]CONTROL.  See the
|  example CONTROL. file for details; look for logicals with the
|  NEWS_NEWSSKIM_ prefix.


   12.2.10.7  NEWSSKIM_LOGICALS.COM

   This file is invoked by NEWSSKIM.COM to define logical names for
   mail forwarding used in either mail-based news feeds or in
   gatewaying newsgroups to mailing lists.  If you aren't doing
   either of these, ignore this file (ie you don't need a version of
   it in [.UUCP_BIN]).


   12.2.10.8  NEWS_ADDRESS.CNF

   This file allows News users to easily send Mail, possibly through
   DECnet, uucp, or other transport mechanisms, to the authors of
   news articles.  It specifies how author's addresses, as shown in
   "From:  " headers in news items, are to be translated so that
   they are acceptable to VMS Mail.

   ANU uses PMDF for its Internet mail, so its address translation
   rules specify "IN%..." (IN% is PMDF's equivalent to our UUCP%).

   cmkrnl uses uucp for Internet mail, so our address translation
   rules specify the now-familiar UUCP% for anything we can't send
   locally.
   INSTALLING AND INTEGRATING NEWS                        Page 12-15
   Installing News: Comments on the News User's Guide


   Note that earlier versions (5.7 and earlier) of ANU NEWS needed
   bunches more quotes (") in the entries in this file.  For
   example, where we used to say
           *@*     "UUCP%""001@002"""

   we now say
           *@*     UUCP%"001@002"

   If you are converting from 5.7 or an earlier version of News, be
   sure to change this file accordingly.


   12.2.10.9  NEWS_POST.DEFAULTS

   Read the comments.  The purpose of this file is to force the
   "Distribution:" and "Followup-To:" headers in items posted to
   specified newsgroup to specified values.  For example, this might
   be used to ensure that local newsgroups stay local (by
   constraining the "Distribution:" header).


   12.2.10.10  NEWS_POST.CC

   This file associates unmoderated newsgroups which happen to be
   gatewayed with mailing lists, with those mailing lists.  Leave
   this file empty unless you are serving as the gateway for such a
   list.


   12.2.10.11  NEWSRC.TEMPLATE

   Ordinarily, when a user runs NEWS for the first time, they are
   registered to no newsgroups, and they are presented with a
   DIRECTORY/ALL screen showing all available newsgroups on the
   system.

   If the file NEWS_MANAGER:NEWSRC.TEMPLATE exists, it is used as a
   template for the creation of the user's new NEWSRC. file.  Thus,
   the NEWSRC.TEMPLATE file may be used to automatically register
   new NEWS users into a predetermined set of newsgroups.

   No example file is provided for NEWSRC.TEMPLATE .


   12.2.10.12  Other files

   Two other files are supplied in [.NEWS61.DIST]; we have copied
   them to uucp directories as follows:

         o  [.DOC.NEWS_SETUP]DCLNEWS.HLP is a help module for
            insertion in a site-specific extension to HELPLIB.HLB
            (or into HELPLIB.HLB itself, if you are so inclined).
            While NEWS_ROOT:NEWS.HLB provides the help that is
            available within News, this file provides information on
            the News DCL command, available by typing "HELP NEWS" at
            the DCL prompt.  If you use this file, be sure to
   INSTALLING AND INTEGRATING NEWS                        Page 12-16
   Installing News: Comments on the News User's Guide


            customize it for your site.

         o  [.BIN]NEWSEDIT_EXAMPLE.COM is a template for a command
            procedure which would allow a user to specify a
            non-standard editor for the creation of News items.
            (The standard editors available are TPU and Callable
            EDT.)  See the description of the logical name,
            NEWS_EDIT, in the NUG.

         o  If you have unpacked the SUPPNEWS saveset, you will find
            the following additional command procedures in
            [.NEWS61.NEWS_DIST].  Their functions are incorporated
            in DECUS uucp's version of NEWSSKIM.COM.  Accordingly,
            these files may be ignored:

            NEWSADD.COM          NEWSDAILY.COM
            NEWSPACK.COM         NEWSSKIM_ALT.COM:


   12.2.11  First Time Execution of News

   12.2.11.1  Startup

   Double check everything, ensure that you have SYSPRV privilege
   and the NEWSMANAGER identifier, and enter:

           $ @UUCP_BIN:USERCMDS
           $ NEWS

   NEWS will respond with

           NEWS - create new ITEM file
           NEWS - first time installation...
           VMS NEWS V6.1 - LICENSE

   and then sit there.

   ____ _ ________ ______
   Type a carriage return to display the first screen of the license
   form; continue hitting return to display the rest.

   This form is also placed in the file
   NEWS_MANAGER:000README.NEWS_LICENSE .  Please print it, fill it
   out, and mail it to Geoff, or edit it, fill it out, and send it
   to him via electronic mail.

   After a final <return> to continue, NEWS will say

           NEWS - create new GROUP file

   and will then place you in a newsgroup directory screen, with no
   newsgroups visible (since none have been created).

                                 NOTE

              ___
           Do not exit News at this point without creating
           at least one newsgroup!  (See the next section.)
   INSTALLING AND INTEGRATING NEWS                        Page 12-17
   Installing News: Comments on the News User's Guide


           If you do it will leave your "NEWSRC" file in an
           incorrect state, causing News to abort with an
           access violation on subsequent attempts to run
                                                    _
           it.  If you make this mistake (guess how I know
           about this!), delete NEWS_ROOT:NEWS*.V50 and
           SYS$LOGIN:NEWSRC., and start again.



   12.2.11.2  Creating "control", "local", and "junk"

   Enter the following commands at the NEWS> prompt:

           create group control
           create group local
           create group junk

   After each command it will respond with "Create Newsgroup?
   [n]:".  Enter "Y" followed by a return to confirm.  After
   creating these groups, enter the EXIT command (or a Ctrl-Z) to
   exit News.


   12.2.11.3  Creating the Initial Newsgroup Set

   At this point you need to tell News about the newsgroups you have
   decided to accept from various sources.

   In [.DOC.NEWS_SETUP] there is a file, CHECKGROUPS., which is a
   copy of the most recent "checkgroups" postings as of this
   writing.  What you want to do is produce a file in this same
   format which reflects only those newsgroups you want to carry.

   Edit the CHECKGROUPS file to create MYGROUPS.TXT, as directed in
   the opening remarks (delete the first "=========" line and
   everything before it, and delete the last "=========" line and
   everything after it; this will leave you with

           Newsgroups: news.admin.ctl,control
           Distribution: local
           Approved: spaf@cs.purdue.edu
           Subject: cmsg checkgroups
           Control: checkgroups

           !mod
           comp.ai                 Artificial intelligence
           discussions.
           comp.ai.shells          Artificial intelligence applied
           to shells. (Moderated)
                  .
                  .
                  .
           talk.rumors             For the posting of rumors.

   INSTALLING AND INTEGRATING NEWS                        Page 12-18
   Installing News: Comments on the News User's Guide


   Note that the blank line between the "Control:  checkgroups" and
   the first line of the newsgroup list must be present.

   Now edit what's left to eliminate all the groups you don't want.
   Append to MYGROUPS.TXT descriptions of all of the VMSnet groups
   (you can find these, listed in the correct format, in
   CHECKGROUPS.VMSNET).

   If you are interested in any of the groups in the "alternate"
   hierarchies, edit the file NEWS.ANNOUNCE, find the "Alternative
   Newsgroup Hierarchies" article, and append to MYGROUPS.TXT the
   descriptions of the groups you want.

   Finally, add a line to MYGROUPS.TXT that says

           to.myhostname   messages from neighbors


   When you are satisfied with your first version of MYGROUPS.TXT,
   you can invoke NEWS again, and at the NEWS prompt type:

           NEWS> ADD FILE MYGROUPS.TXT/GEN

   A few messages will appear, and you will get a Mail message
   (assuming that messages sent to USENET are forwarded to you).
   Exit News, enter Mail, and EXTRACT/NOHEADER the first of these
   into a disk file (perhaps MYGROUPS.COM).  Exit from Mail and,
   from the DCL prompt, execute this file as a command procedure,
   e.g.

           $ @MYGROUPS.COM

   This will create the newsgroups you have requested.  NEWS is now
   ready to accept these newsgroups from your news feeds.

   Assuming that you have included the newsgroup
   news.announce.newusers, you can again invoke NEWS and

           NEWS> ADD FILE [UUCP.DOC.NEWS_SETUP]NEWS.ANNOUNCE

   This will add the articles contained in the file to the
   newsgroup.

   By default, groups are created with a default item retention
   period of thirty days.  You can modify the default for all
   groups, and you can also modify the retention period for
   particular groups, with the SET NEWSGROUP command; see the NEWS
   documentation.
|  
|  The NEWSSKIM batch job, as supplied with DECUS uucp (in [.BIN],
|  can automatically modify the retention period of newsgroups based
|  on whether or not anybody at your site has subscribed to them.
|  Local overrides are provided for.  This is enabled via a logical
|  defined in the CONTROL. file; it is disabled by default.  Review
|  the relevant portions of NEWSSKIM.COM and see if this is
|  appropriate for your site.
   INSTALLING AND INTEGRATING NEWS                        Page 12-19
   Installing News: Comments on the News User's Guide


   You will probably want to set the retention period for
   comp.mail.maps down to one day.  All newly-arrived maps are
   copied into the UUCP_DATA_MAPSRC directory within a day, where
   they remain until replaced by later versions of the same maps.
   Since the maps are updated on a monthly basis, the default
   retention period will cause you to retain two complete copies of
   the map data -- at least one of them uncompressed! -- which is a
   needless waste of space.

   The final step is to ensure that incoming news batches get routed
   to News, and that News can properly forward to the sites you
   feed, whether via DECnet or uucp.  This is covered in the
   following sections.


   12.3  Exchanging News with Other Sites (Batch Transfers)

   12.3.1  DECnet Transfers

   The method used for DECnet transfers is as follows:

         o  When news items are posted, News uses the NEWS.SYS file
            to determine which, if any, systems the newsgroups in
            question are forwarded to.  It then creates files
            containing the items to be forwarded in the directory
            named in each system's entry in NEWS.SYS.  The format of
            the directory name in the NEWS.SYS entry specifies that
            the transfer is to be via DECnet.

         o  The NEWSSKIM command procedure, which runs periodically
            as a batch job under the "News manager" account, looks
            for these files and copies them (using ordinary DECnet
            file copy) to the corresponding DECnet node.

         o  The NEWSSKIM command procedure on the target node,
            running periodically, looks for these received files in
            the NEWS_MANAGER directory.  When it finds them, it adds
            them to the news data base.

            (Of course, in most environments, the two systems will
            exchange news in both directions.  NEWSSKIM always looks
                              ___
            for incoming news and sends outbound news.)

   For this to work, the following conditions must be met:

         o  News must be set up as described here on all machines in
            the network.

         o  DECnet default proxy login entries must exist for the
            "News manager" account on all systems, so that the
            DECnet file copy goes to the "News manager"'s default
            directory on the target system, and so that the copied
            files are owned by the correct account.
   INSTALLING AND INTEGRATING NEWS                        Page 12-20
   Exchanging News with Other Sites (Batch Transfers)


         o  The default device and directory of the "News manager"
            account on each node must point to the same directory as
            the logical name, NEWS_MANAGER.

         o  Appropriate entries must exist in the NEWS.SYS file to
            specify transfer via DECnet, and the subdirectories
            named in those entries must exist under NEWS_MANAGER.

         o  If news received from other sites is to be sent to the
            DECnet node, appropriate entry(ies) must exist in
            NEWS.DISTRIBUTION .

         o  The NEWSSKIM batch job must run periodically on all
            machines.


   12.3.2  UUCP Transfers (both to Unix and to VMS)

   Ignore the relevant section in the NUG; very few Unix sites are
   happy to deal with Mail-based News feeds, and since the DECUS
   uucp distribution supports the more desirable "compressed rnews"
   mechanism, there is no need for them to do so.

   Uucp news transfers work as follows:

         o  When news items are posted, News uses the NEWS.SYS file
            to determine which, if any, systems the newsgroups in
            question are forwarded to.  It then creates files
            containing the items to be forwarded in the directory
            named in each system's entry in NEWS.SYS.  The format of
            the directory name in this case specifies that the
            transfer is to be via uucp, and whether or not the files
            are to be compressed before transmission.

         o  The NEWSSKIM command procedure, which runs periodically
            as a batch job under the "News manager" account, looks
            for these files, compresses them if necessary, and
            invokes the "uux_rnews" program for each.

         o  Uux_rnews creates the necessary files in the uucp spool
            directory so that, during the next uucp call to or from
            the neighbor system, the news batch file and an
            "execution" file will be transferred.

         o  Upon receipt of the "execution" file, the receiving
            system passes the received news batch file to the
            "rnews" program.  Under DECUS uucp, rnews is a command
            procedure, UUCP_BIN:NEWS_RNEWS.COM, which is run in the
            NEWS_BATCH queue by UUXQT_DCL.

         o  For incoming news, the neighbor system places in the
            uucp spool directory a D.xxx file containing the
            (possibly compressed) news batch, and an X.xxx file
            containing instructions for processing the D.xxx file.
            Upon receipt of the X.xxx file, the uucico program
            awakens the uuxqt image, which passes the X.xxx file to
   INSTALLING AND INTEGRATING NEWS                        Page 12-21
   Exchanging News with Other Sites (Batch Transfers)


            the uuxqt DCL subprocess.  This in turn submits a batch
            job, NEWS_RNEWS.COM, in the News batch queue.  This job
            (finally!) runs the compress utility (in decompress
            mode), if required, and then invokes NEWS to ADD the
            contents of the file to the News database.  Finally, all
            intermediate work files are deleted.

   For this to work, the following conditions must be met:

         o  News must be set up as described here on all of the VMS
            machines in the network.

         o  Appropriate entries must exist in the NEWS.SYS file to
            specify transfer using (probably compressed) uucp, and
            the corresponding subdirectories must exist under
            NEWS_MANAGER.

         o  If news received from other sites is to be sent to the
            uucp host, appropriate entry(ies) must exist in
            NEWS.DISTRIBUTION .

         o  The NEWSSKIM batch job must run periodically.

         o  You must have a uucp connection to each of the systems
            you're sending news to (as described in NEWS.SYS).


   12.3.3  Ihave/Sendme Transfers via UUCP or DECnet

   (This will not be used by most sites.)

   This is similar to the setup for standard uucp or DECnet
   transfers.  Make the following changes in NEWS.SYS for each
   system to which News will be forwarded using ihave/sendme:

         o  Change the third field in the system's entry (the
            <flags> field; a single character, with colons on either
            side) from "B" ("B" news format) to "N" (NNTP
            ihave/sendme).

         o  Depending on the capabilities of each system, you may
                               ____
            need to change the last character in the system's
            entry -- the article format -- from "B" (for batched
            transfer; all articles to be transferred to one system
            go in a single file) to "M" (for multiple, meaning that
            each article goes in a separate file).

   Changing the <flags> field causes News, when collecting News for
   transfer to the other system, to merely build a list of article
   ids in the transfer file (or files, if the article format is
   "M").  This list is sent to the other system as an "ihave"
   control message.  The other system examines the list and sends
   back a "sendme" control message; News on your machine responds by
   queueing for transfer the articles listed in the "sendme"
   (usually during a later call).  The intended result is less
   transmission time but greater transfer latency.
   INSTALLING AND INTEGRATING NEWS                        Page 12-22
   Exchanging News with Other Sites (Batch Transfers)


   12.3.4  Feeding News via NNTP

   We have no experience with this; refer to the NUG.  There is a
   faint possibility that one of our changes to NEWSSKIM.COM, or
   other procedures, may have "broken" the instructions provided for
   NNTP News feeds.  We would appreciate hearing from anybody who
   gets this running.


   12.3.5  Receiving a News Feed via NNTP

   This must be possible, but I don't quite see how to set it up.
   If a News_server is running, would it accept News feeds via NNTP?


   12.4  NNTP Client/Server Support

   Again, we have no experience with NNTP; refer to the NUG.

   Anyone who sets up News in NNTP Client or NNTP Server mode, or
   who uses NNTP news feeds, is urged to keep a log of what you do
   while you're setting it up.  Send it to both Geoff Huston and the
   VMSnet Working Group, so that we can enhance future versions of
   the documentation (with credit, of course!).


   12.5  Start Up the Transfer Processes

   Submit the NEWSSKIM batch job for periodic execution.  You can do
   this by invoking the startup procedure as follows:

           $ @UUCP_BIN:UUCP_SYSTARTUP BATCH_JOBS INCLUDE_NEWS

   When you are satisfied that all is well, edit the command in your
   system startup command procedure that invokes UUCP_SYSTARTUP to
   include a P2 parameter, as follows:

           $ @ddcu:[UUCP.BIN]UUCP_SYSTARTUP "" INCLUDE_NEWS

   This will cause UUCP_SYSTARTUP to invoke NEWS_SYSTARTUP at the
   appropriate time in the startup sequence, that is, after all of
   the UUCP_ logicals have been defined, but before any of uucp's
   batch jobs are started.  (NEWSSKIM might fail if it tries to run
   before the UUCP_ logicals exist, and the uuxqt batch job might
   fail if it tries to run before the NEWS_ logicals exist.)












                              APPENDIX A

                         USING TELEBIT MODEMS



   The Telebit Trailblazer Plus, Telebit 2500, WorldBlazer, and
   similar modems have become a de facto standard for high-speed
   links in the uucp world.  Besides their "ordinary" high speed and
   error correcting capabilities, they offer a "spoofing" mode for
   the uucp "g" protocol, wherein the modem speaks the uucp protocol
   to the local system but runs its own error-correcting protocol
   over the telephone link.  This provides much better throughput
   than would be possible with a standard high-speed modem, since it
   eliminates the necessity to move uucp's error-protection data
   over the wire, and also allows for more-rapid acknowledgements of
   transmitted packets to the sending system.

   Uunet gets 11,000 bits per second throughput with Telebits in PEP
   mode "on real data under real conditions" (according to Uunet's
   information packet); in tests between DECUS uucp systems with
   quiet lines we regularly achieve 12,000 bps, and often reach
   14,000.

   In short, these modems can provide a real cost savings over
   2400 bps modems if you move a lot of data over long-distance
   lines.  This Appendix describes how to use the Telebit
   Trailblazer Plus and T2500 modems with DECUS uucp. [1]  We have
   no direct experience with other Telebit models.

   (We really don't mean to sound as though we're putting in a plug
   for Telebit's modems; we have no connection with the company
                 ____
   other than as very satisfied customers.)


   A.1  Serial Port Requirements

   The setup to be described assumes that the VAX serial port to be
   used implements modem control signals, as described in the
   chapter on "Modems and Multiplexers".

   If you will be using the Telebit for uucp ordinary interactive
   dialin, the port must support the Clear To Send signal.  Such
   ports include:
   ____________________

   [1]  This material is based very closely on an article Mark
   Pizzolato wrote for posting to netnews, earlier this year.
   USING TELEBIT MODEMS                                     Page A-2
   Serial Port Requirements


         o  All ports in the DHV11, DHQ11, DHU11, DMB32, DMZ32,
            CXY08

         o  Ports 0 and 1 on the DMF32

         o  The DB25 serial port on the MicroVAX 2000

         o  All ports on a DECserver 200MC

   Ports which implement partial modem control (such as those on the
   DZ family) may be used with a Telebit modem for uucp, but not for
   interactive dialin.

   Ports on the CXA16, CXB16, and ports 2 through 7 on the DMF32,
   provide no modem control signals.  Telebits will not work as
   described below with these ports.  (This doesn't mean that they
   won't work at all, only that you'll have to live with the
   security problems that exist when the VAX can't make the modem
   hang up the line.  These security problems are not specific to
   Telebit modems; they exist any time you connect a dial-in modem
   to a port that does not notify the VAX when the phone connection
   is dropped.)


   A.2  Goals

   We have several seemingly contradictory requirements.  We want:

         o  To be able to initiate uucp outbound calls at a speed
            appropriate for the modem being called;

         o  To have the default outbound speed on the line be 19200
            when using "SET HOST/DTE" and/or asynchronous DECnet,
            since dynamic speed select is not normally possible with
            "SET HOST/DTE";

         o  To allow callers to dial in at a speed appropriate for
            the modem they were using and dynamically autobaud to
            their speed; and

         o  To be able to call some Telebits that answer with PEP
            tones last, but still establish a PEP connection.

   The solution is to use a locked interface speed (at 19,200 bps)
   for both incoming and outgoing calls, allowing the modem to
   connect at the speed of the other modem and take care of the
   speed difference between that and the VAX.

   Running the phone line at a lower speed than the interface to the
   VAX (for incoming calls) raises the possibility that the VAX
   could send data faster than the modem could send it down the
   line.  This is not a problem for uucp connections (either to
   other Telebits or to ordinary low-speed modems) because the uucp
                                               __
   protocol includes its own flow control.  It is a problem for
   interactive users.  We take care of this by using hardware flow
   control (using the CTS signal), if available, to throttle data
   USING TELEBIT MODEMS                                     Page A-3
   Goals


   going from the VAX to the modem.  No flow control is needed in
   the other direction (modem to VAX) because we're going the "other
   way" -- from a lower-speed line to a higher-speed line.

   We also need to comply with the other requirements detailed in
   the chapter on "Modems and Multiplexers", but this is not
   difficult with the Telebit modems.


   A.3  Modem Settings

   Here are the settings that are different from the factory
   defaults.  These are described for the Telebit TrailBlazer Plus,
   the T2500.  and for the WorldBlazer.  If you have another type of
   Telebit modem, you'll have to read the manual and see for
   yourself how applicable these are.

         o  S0=1        Answer the phone after 1 ring for incomming
            calls.

         o  E0          Don't echo commands from host,

         o  Q2          Return result codes only on outgoing calls.
            (WorldBlazer)

         o  Q6          Return result codes only on outgoing calls.
            (others)

         o  S59=15      Return result codes including connection
            info.  (WorldBlazer only)

         o  X2          MNP & PEP extended result codes enabled.
            (WorldBlazer)

         o  X3          MNP & PEP extended result codes enabled.
            (others)

         o  &T5         Deny test requests from the remote modem.
            (T2500, WorldBlazer)

         o  S7=90       Allow 90-second wait for carrier.

         o  S51=5       Set host interface speed to 19200.

         o  &D3         Hang up and reset to EEPROM values on DTR
            drop.  (WorldBlazer)

         o  S52=2       Hang up and reset to EEPROM values on DTR
            drop.  (others)

         o  S54=3       Pass BREAKs transparently.  (TrailBlazer
            Plus & T2500 only)

         o  S61=0       Pass BREAKs transparently.  (TrailBlazer
            Plus & T2500 only)
   USING TELEBIT MODEMS                                     Page A-4
   Modem Settings


         o  S58=0       No flow control is used to control the flow
            of data coming from the modem to the host (since the
            host can take data at 19200, faster than the modem can
            possibly send it, no flow control is needed).

         o  S66=1       Lock interface speed and enable flow
            control.  (TrailBlazer Plus and T2500 only)

         o  S68=2       Use hardware flow control from modem to
            host:  The modem turns CTS off when its buffer for
            outgoing data is full, and on when the modem can accept
            more data.

         o  S92=1       Issue the PEP answer tones at the end of the
            search sequence rather than at the beginning to
            accommodate connecting with slower speed (non-PEP)
            modems.

         o  S110=0      LZW Data compression is disabled.
            (TrailBlazer Plus & T2500 only) (The bulk of our traffic
            will be news, which is already compressed.)

         o  S191=6      LZW Data compression is disabled.
            (WorldBlazer only) (The bulk of our traffic will be
            news, which is already compressed.)

         o  S131=1      CD is ON when carrier is detected.  (T2500
            only)

         o  &C1         CD is ON when carrier is detected.
            (WorldBlazer only)

         o  S53=2       DSR ON only when DCD is ON.  DCD is ON when
            carrier is detected.  (TrailBlazer Plus only)

         o  S130=5      DSR follows CD.  (T2500 only)

         o  &S4         DSR ON only when DCD is ON.  DCD is ON when
            carrier is detected.  (WorldBlazer only)



   A.4  Setting it Up

   Here's the full procedure for getting a brand-new Telebit working
   with your VAX under DECUS uucp.  We assume that it's connected to
   a port named TXA0:.

        1.  Set up the port attributes somewhere in the system
            startup files with the following command:

            $ SET TERMINAL TXA0: /PERMANENT/SPEED=19200 - ! needed
                  /MODEM/HANGUP/DIALUP/TYPEAHEAD/ALTYPEAHD - !
            needed
                  /DMA/SYSPASSWORD/TTSYNC/HOSTSYNC        ! optional
   USING TELEBIT MODEMS                                     Page A-5
   Setting it Up


            Note the explicit setting of /SPEED vs. /AUTOBAUD.  See
            Chapter 4 for information about the optional attributes.
            We recommend /DMA, /TTSYNC, and /HOSTSYNC; /SYSPASSWORD
            is up to you.

                  ___
            We do not recommend trying to use a Telebit without
            using the alternate typeahead buffer; further, the
                                                             __
            SYSGEN parameter TTY_ALTYPAHDSZ should be set to at
            _____
            least 210 (up from its default of 200). [2]

        2.  The following instructions assume that the modem's
            starting configuration is that with which the modem is
            shipped from the factory.  If the modem's default
            power-up configuration has been changed, refer to the
            modem's instruction manual to restore it to the factory
            settings.  (See, for example, pages 6 and 7 in the
            _______ _____ ____ _____ _____
            Telebit T2500 Fast Start Guide.)

        3.  If you have a T2500, or other model with "A/B" and "T/D"
            switches on the front panel, the "A/B" switch selects
            one of two non-volatile memories for user-modified
            parameters.  This switch may be set to either position,
            but whatever position the switch is in when the modem is
            configured as described below, the switch must remain in
            that position for subsequent use by uucp.

        4.  Connect to the modem using:

            $ ALLOCATE TXA0:
            $ SET TERMINAL/SPEED=19200
            $ SET HOST/DTE TXA0:

            and then type the following:
            AT<cr>
            (the modem should respond with "OK".  If not, try typing AT<cr>
            a few more times.)

            (for the TrailBlazer Plus)

            AT &F Q6 X3 S0=1 S7=90 S52=2 S54=3 S58=0 S68=2 <cr>
            AT E0 S51=5 S66=1 S92=1 S110=0 S53=2 &W<cr>

   ____________________

   [2]  As noted in the chapter on modems and terminal multiplexers,
|  A typeahead buffer size of 210 will be sufficient for uucp with
|  default buffer and window sizes.  Larger values may be
|  appropriate if you are using larger buffers or windows, or if you
   intend to use the Telebit for "normal" interactive logins to
   other computers with Telebits.  The Telebit's data compression
   capability, along with latencies in common terminal emulation
   software (including KERMIT and SET HOST/DTE), can result in the
   modem sending large bursts of data faster than the software is
   capable of emptying the typeahead buffer.  Larger values
   (approximately 2000 for one screen's worth) may help avoid data
   overrun conditions in these cases.
   USING TELEBIT MODEMS                                     Page A-6
   Setting it Up


            (for the T2500)

            AT &F Q6 X3 S0=1 S7=90 S52=2 S54=3 S58=0 S68=2 <cr>
            AT E0 S51=5 S66=1 S92=1 S110=0 S130=5 S131=1 &T5 &W<cr>

            (for the WorldBlazer)

            AT &F X2 Q2 S0=1 S7=90 S61=0 S59=15 S58=0 S68=2 <cr>
            AT E0 S51=5 S92=1 S191=6 &D3 &C1 &S4 &T5 &W <cr>

            The <cr> of course represents a carriage return.  Note
            that you may need to hit "A" several times at the
            beginning of the line before the modem autobauds and
            echoes an "A".

            The above command will cause DSR & DCD to drop, so "SET
            HOST/DTE" might exit immediately.  This is all right,
            but to be sure that things worked right, "SET HOST/DTE"
            again and use

            AT &N<cr>

            or, if you have a WorldBlazer

            AT &V<cr>

            to display the modem's settings.

        5.  Exit back to DCL with ^\ (that is, Ctrl-Backslash) and
            release the modem port:

            $ DEALLOCATE TXA0:


   A.5  Control and Systems File Entries

   The supplied file [.CFG]CONTROL. shows such a modem on TXA0:

           port ACU hayes     txa0: 2400 L
           port ACU tbgspoof  txa0: 19200 L

   This says that systems entries specifying "ACU" and "2400" will
   use the normal Hayes dial script, but those specifying "ACU" and
   "19200" will use the special "tbgspoof" script, which enables "g"
   protocol spoofing.  Naturally, the 19200 speed should only appear
   in systems entries with phone numbers to which Telebit modems are
   connected!

   The trailing "L" (may be upper or lower case) tells DECUS uucp to
   not change the port speed on outbound calls.  In this case the
   speed in the port entry simply tells DECUS uucp which speeds the
   modem is capable of using.  These modems will correctly connect
   to modems of various speeds and perform speed conversion between
   the line and the VAX.
   USING TELEBIT MODEMS                                     Page A-7
   Communicating with Other Telebits


   A.6  Communicating with Other Telebits

   Ensure that other sites which call you with Telebit modems give
   their modem an S50=255 command before dialing your number.  This
   assures that a PEP connection will be made even though your modem
   answers with the PEP tones last.


   A.7  Compatibility Issues (old history)

   While debugging this, Mark Pizzolato found a bug in Telebit's
   implementation of the "g" protocol.  At the time, we were still
   using the non-windowed "g" protocol implementation from the
   original gnuucp, and this used a feature of the protocol that
   neither HoneyDanBer or other Unix uucp implementations seem to
   use.  Since Telebit had never seen it used, they didn't provide
   for it.  Telebit will have a fix, but since it only affects the
   VMSnet Version 0.1 and 0.2 distributions, and DECUS uucp 1.0 does
   ___
   not use the feature, you need not worry as to whether or not your
   modem is upgraded.

   For the curious only:

   The problem was that, in certain cases, piggybacked ACKs weren't
   being handled correctly by the modem, and the modem would hang.
   Piggybacked ACKs are a mechanism whereby the acknowledgement of
   data message in one direction rides "piggy back" in the control
   portion of a data message going in the other direction.  The "g"
   protocol allows this, but since Telebits have been such a
   success, and this problem hasn't come up before, gnuucp's "g"
   protocol implementation must at least be using this in a way that
   the Unix implementations don't.

   In Version 1.0 of DECUS uucp, we always ensure that all pending
   ACKs are sent before sending any data messages, and so we never
   send a "piggybacked ACK" if we haven't already sent the
   corresponding data message.  Piggybacked ACKs can be a real win
   if you have large amounts of data moving in both directions on a
   line at the same time, but since the "upper layers" of uucp only
   use the link in a half-duplex manner (at any given time, one file
   is being moved in one direction; it cannot overlap file copy in
   and copy out operations), elimination of piggybacked ACKs costs
   nothing in terms of performance.

   Many, many thanks to Mike Ballard at Telebit for his support
   while isolating the "g" protocol bug and debugging changes to
   gnuucp's gio module to accommodate the modem.  -- MP












                              APPENDIX B

               PATHALIAS (UUCP MAP FILE FORMAT DETAILS)



   The following material is adapted from the "manual page" for Unix
   pathalias(1), written by Dr. Peter Honeyman.


   B.1  Description

   The command procedure [.BIN]MAKEPATHS.COM generates the file
   [.DATA]PATHS., which reflects the shortest paths and
   corresponding routes from one host (computer system) to all other
   known, reachable hosts.  Most of the work is performed by the
           _________
   program pathalias.  Pathalias reads host-to-host connectivity
   information from the uucp map files in [.DATA.MAPSRC], and writes
   a list of host-route pairs on the standard output.


   B.2  Uucp Map File Format

   A line beginning with white space continues the preceding line.
   Anything following "#" on an input line is ignored.  A large
   number of conventions for "#"-lines is recommended for map
   entries (see the file [.DATA.MAPSRC]README.); these lines are
   important to the people who maintain the map database, but are
   ignored by pathalias.

   Pathalias's primary input consists of lists of host-to-host
                                                          ____
   connections.  Such a list of connections consists of a from host
   in column 1, followed by white space, followed by a
                                              _____
   comma-separated list of "to" hosts, called links.


   B.2.1  Uucp Mapping Project Requirements

   In entries published in the uucp maps, host and domain names may
   contain the following characters:  "a" through "z", "0" through
   "9", and "-" (dash).  Fully qualified domain names may contain
   "." (dot).  No other characters, including uppercase alphabetics
   and underscore will be accepted anywhere in the name.  In
   addition, host names and each section of the domain name must
                                             ___
   begin with a lowercase alphabetic and may not end with a dash.
   PATHALIAS (UUCP MAP FILE FORMAT DETAILS)                 Page B-2
   Uucp Map File Format


   The above applies to all names given on the #N and #F lines as
   well as all names that appear in the link description portion of
                            ___
   your map entry.  It does not apply to pseudo network names used
   to help describe internal networks, as defined below.


   B.2.2  Network Characters

   A link may be preceded or followed by a network character to use
   in the route.  Valid network characters are "!" (default), "@",
   ":", and "%".

                                 NOTE

           The uucp mapping project will not accept map
           entries with network characters other than "!"
           (which is the default anyway, so why bother).



   B.2.3  Costs

   A link (and network character, if present) should usually be
   followed by a "cost" enclosed in parentheses.  Costs may be
   arbitrary arithmetic expressions involving numbers, parentheses,
   "+", "-", "*", and "/".  The following symbolic costs are
   recognized:

             LOCAL       25   (local-area network connection)
             DEDICATED   95   (high speed dedicated link)
             DIRECT     200   (toll-free call)
             DEMAND     300   (long-distance call)
             HOURLY     500   (hourly poll)
             EVENING   1800   (time restricted call)
             DAILY     5000   (daily poll, also called POLLED)
             WEEKLY   30000   (irregular poll)

   In addition, DEAD is a very large number (effectively infinite),
   HIGH and LOW are -5 and +5 respectively, for baud-rate or quality
   bonuses/penalties, and FAST is -80, for adjusting costs of links
   that use high-speed (9.6 Kbaud or more) modems.  These symbolic
   costs represent an imperfect measure of bandwidth, monetary cost,
   and frequency of connections.

   For most mail traffic, it is important to minimize the number of
   hosts in a route.  So, for example, HOURLY * 24 is much larger
   than DAILY.  If no cost is given, a default of 4000 is used.

   For the most part, arithmetic expressions that mix symbolic
   constants other than HIGH, LOW, and FAST make no sense.  For
   example, if a host calls a local neighbor whenever there is work,
   and additionally polls every evening, the cost is DIRECT, not
   DIRECT+EVENING.
   PATHALIAS (UUCP MAP FILE FORMAT DETAILS)                 Page B-3
   Uucp Map File Format


   Some examples:

             down      princeton!(DEDICATED), tilt,
                       %thrash(LOCAL)
             princeton topaz!(DEMAND+LOW)
             topaz     @rutgers(LOCAL+1)

   If a link is encountered more than once, the least-cost
   occurrence dictates the cost and network character.  Links are
   treated as bidirectional but asymmetric:  for each link declared
   in the input, a DEAD reverse link is assumed.


   B.2.4  Terminal Links

   If the "to" host in a link is surrounded by angle brackets, the
                      ________
   link is considered terminal, and further links beyond this one
   are heavily penalized.  For example, with input

             seismo    <research>(10), research(100), ihnp4(10)
             research  allegra(10)
             ihnp4     allegra(50)

   the path from seismo to research is direct, but the path from
   seismo to allegra uses ihnp4 as a relay, not research.  The way
   to think of this is to imagine two copies of research, one that's
   cheap to get to, but has no neighbors, and one that's expensive
   to get to, but has neighbors.  (This is an exception to the
   "least-cost link" rule above.)


   B.2.5  Aliases

   The set of names by which a host is known to its neighbors is
              _______
   called its aliases.  Aliases are declared as follows:

             name = alias, alias ...

   The name used in the route to or through aliased hosts is the
   name by which the host is known to its predecessor in the route.


   B.2.6  Networks

   Fully-connected networks, such as the ARPANET or a local-area
   network, are declared as follows:

             net = {host, host, ...}

   The host-list may be preceded or followed by a routing character,
   and may be followed by a cost:

             princeton-ethernet = {down, up, princeton}!(LOCAL)
             ARPA = @{sri-unix, mit-ai, su-score}(DEDICATED)

   The routing character used in a route to a network member is the
   PATHALIAS (UUCP MAP FILE FORMAT DETAILS)                 Page B-4
   Uucp Map File Format


   one encountered when "entering" the network.  See also the
   sections on gateways and domains.


   B.2.7  Hidden Hosts

   Connection data may be given while hiding host names by declaring

             private {host, host, ...}

   Pathalias will not generate routes for private hosts, but may
   produce routes through them.  The scope of a private declaration
   extends from the declaration to the end of the input file in
   which it appears, or to a private declaration with an empty host
   list, whichever comes first.  The latter scope rule offers a way
   to retain the semantics of private declarations when reading from
   the standard input.


   B.2.8  Preventing Routing Through Certain Hosts, Links, or
          Networks

   Dead hosts, links, or networks may be presented in the input
   stream by declaring

           dead {arg, ...}

         ___
   where arg may be any of:

         o  A single host name.  The host is treated as dead and is
            used as a relay host of last resort on any path.

         o  The form "host-1!host-2".  The link from host-1 to
            host-2 is treated as an extremely high cost (that is,
            DEAD) link.

         o  A network name.  Such a declaration indicates that the
            network requires a gateway.


   B.2.9  Gateways

   A network is represented by a pseudo-host and a set of network
   members.  Links from the members to the network have the weight
   given in the input, while the cost from the network to the
   members is zero.  If a network is declared dead, the
   member-to-network links are marked dead, which effectively
   prohibits access to the network from its members.

   However, if the input also shows an explicit link from any host
   to the network, then that host can be used as a gateway.  (In
   particular, the gateway need not be a network member.)

   For example, if CSNET is declared dead and the input contains

             CSNET = {...}
   PATHALIAS (UUCP MAP FILE FORMAT DETAILS)                 Page B-5
   Uucp Map File Format


             csnet-relay         CSNET

   then routes to CSNET hosts will use csnet-relay as a gateway.


   B.2.10  Domains

   A network whose name begins with "." is called a domain.  Domains
   are presumed to require gateways, that is, they are DEAD.  The
   route given by a path through a domain is similar to that for a
   network, but here the domain name is tacked onto the end of the
   next host.  Subdomains are permitted.

   For example:

             harvard   .EDU      # harvard is gateway to .EDU domain
             .EDU      = {.BERKELEY, .UMICH}
             .BERKELEY = {ernie}

   yields

             ernie     ...!harvard!ernie.BERKELEY.EDU!%s

   Output is given for the nearest gateway to a domain.  For
   instance, the example above gives

             .EDU      ...!harvard!%s

   Output is given for a subdomain if it has a different route than
   its parent domain, or if all its ancestor domains are private.


   B.2.11  Smart Hosts

   Pathalias and the DECUS uucp mailer support the "smart host"
   notion.  If a smart host is defined, and the mailer is handed an
   address that it can't resolve, the mail is sent to the smart host
                 __
   in hopes that it can deal with the address.

   To set a smart-host alias, place a line like

           smart-host = host

   in a file called U.something in the [.DATA.MAPSRC] directory.
   (Do not include this line in the map file which you mail to the
   uucp mapping project!  Keeping it in a separate file reduces the
   chances of making this mistake.)

   The smart host mechanism makes it possible to completely avoid
   the use of the uucp maps, simply by handing all of your mail to
   another host for routing.

                                 NOTE

           It is only reasonable to contact the postmaster
           on "host" and obtain their permission to do this,
   PATHALIAS (UUCP MAP FILE FORMAT DETAILS)                 Page B-6
   Uucp Map File Format


           rather than blithely assuming that they won't
           mind routing all of your site's mail.



   B.3  Output Format

   A list of host-route pairs is written to the output, where route
   is a string appropriate for use with printf(), for example:

             rutgers   princeton!topaz!%s@rutgers

   The "%s" in the route string is replaced by the user name at the
   destination host.  (This task is normally performed by the
   mailer.)

              _______
   Except for domains, the name of a network is never used in
   routes.  Thus, in the earlier example, the path from down to up
   would be "up!%s," not "princeton-ethernet!up!%s."


   B.4  Bugs and Deficiencies

   Terminal nets are not implemented.

   Pathalias can generate hybrid (that is, ambiguous) routes, which
   are abhorrent and most certainly should not be given as examples
   in the manual entry.  Experienced mappers largely shun "@" when
   preparing input; this is historical, but also reflects uucp's
   facile syntax for source routes.

   Multiple "@"s in routes are loathsome, so pathalias resorts to
   the "magic %" rule when necessary.  This convention is not
   documented anywhere, including here.












                              APPENDIX C

                               UTILITIES



   This appendix describes several utilities provided with the DECUS
   uucp package.

   All of these utilities are defined as foreign commands by
   [.BIN]USERCMDS.COM .  Many of them (as described) include support
   for Unix-style I/O redirection, pipes, and execution in a spawned
   subprocess.
   UTILITIES                                                Page C-2
   Checkaddr


   C.1  Checkaddr

   This utility allows you to test the effects of your PATHS. and
   MAIL_REWRITE.RULES files.

   The command checkaddr takes one or more network addresses as
   arguments, optionally preceded by a rewrite rule set specifier,
   as follows:

   usage:  checkaddr addr [addr ...]
      or:  checkaddr -outbound-to addr [addr ...]
      or:  checkaddr -inbound-from addr [addr...]
      or:  checkaddr -inbound-to addr [addr ...]
      or:  checkaddr -outbound-from addr [addr...]


   Addresses preceded by a rewrite rule specifier are first
   translated according to the indicated rules, and then routed via
   PATHS.  Addresses not so preceded are simply routed via PATHS.

   The "addr" arguments must nearly always be surrounded by
   quotation marks, or DCL will interpret !'s, @'s, and so on.

   Several different types of addresses may be checked in one
   command, as in

           checkaddr addr1 -inbound-from addr2 -outbound-from addr3

   UTILITIES                                                Page C-3
   Tail


   C.2  Tail

   This is a VMS version of the standard Unix "tail" utility.  Its
   prime purpose is to read a file such as a log file and display
   only the last few lines (the "tail").

   The following is the output of "tail -help".  "-help" is an
   invalid option, but any invalid option causes tail to produce
   this usage description.

   usage:  tail [+-][n][arf] [file]
     +n  Begin copying at 'n' lines from the beginning of the file.
           If number is not specified, the value 10 is used.
     -n  Begin copying at 'n' lines from the end of the file.  If
           number is not specified, the value 10 is used.  This
           option is the default if neither "-" nor "+" appears.
     -r  Copy lines from the end of the file in reverse order.  The
           default for 'r' is to print the entire file this way.
     -f  If the input file is not a pipe, do not terminate after the
           line of the input file has been copied, but enter an
           endless loop, sleeping for a second and then attempting
           to read and copy further records from the input file.
           This option may be used to monitor the growth of a file
           that is being written by some other process.  For
           example, the command:

                   tail -40f barney

           will print the last forty lines of the file barney,
           followed by any lines that are appended to barney between
           the time tail is initiated and killed.
     -a  Modifies the 'f' option.  The existence of both the 'a' and
           'f' switches causes tail to continue outputting even if
           the file gets smaller (i.e. a new version is created).
           This feature is useful with log files and others which
           are periodically reopened.  For example, the following
           command

                   tail -af uucp_log:uucp.log &

           will always show the current (latest) version of
           uucp.log, even past midnight when the UUCLEAN batch job
           renames the original file.

   The following is a useful way to use tail with the uucp log file:


   $ tail -20af uucp_log:uucp.log &

   This writes the tail of the logfile, then continues to display
   additional lines as they are written.  The trailing "&" causes
   the command to run in a subprocess, so you can continue to work
   at your terminal.
   UTILITIES                                                Page C-4
   Tail


   The only restriction on the "-f" option is that if the file being
   "tail"ed is open by another process, its growth will only be
   noticed when the file header is updated to reflect the new
   growth.  This happens with batch log files once a minute or
   however often you specify via the SET OUTPUT_RATE DCL command.
   It is not a problem with the uucp log file because this file is
   opened anew (for append access) and closed for each write.
   UTILITIES                                                Page C-5
   Compress


   C.3  Compress

   C.3.1  Synopsis

           compress [ -c ] [ -d ] [ -f ] [ -v ] [ -p ] [ -z ]
                   [ -b bits ] [ filename ... ]

           uncompress [ -c ] [ -v ] [ -p ] [ -z ] [ filename ... ]

           zcat [ filename ... ]

   Unix shell-style I/O redirection (>, <, >>, |) and background
   processing (&) are supported.


   C.3.2  Description

   "compress" reduces the size of the named files using adaptive
   Lempel-Ziv coding.  Whenever possible, each file is replaced by
   one with one with "-Z" concatenated to the extension, while
   keeping the same ownership, modes and modification times.  If no
   files are specified, the standard input is compressed to the
   standard output.

   Compressed files can be restored to their original form using
   "uncompress" (aka "compress -d").  This replaces the compressed
   file with the uncompressed version with the "-Z" removed.

   "zcat" produces uncompressed output on the standard output, but
   leaves the compressed "-Z" file intact.  "zcat" (aka "compress
   -dc") defaults to a simple "cat" for files that are not actually
   compressed.


   C.3.3  Options

   -c      Write to the standard output; no files are changed.  The
           nondestructive behavior of "zcat" is identical to that of
           "uncompress -c", or "compress -dc".
   -d      If given, decompression is done instead.
   -f      Force compression of "name", even if one already exists,
           and even if no space is saved by compressing.
           Except when run in the background (or in a batch job), if
           -f is not given and "compress" is run in the foreground,
           the user is prompted as to whether an existing "name"-Z
           file should be overwritten.  On VMS output files are not
           actually overwritten, a new version is merely created.
   -v      Verbose.  Display the percentage reduction for each file
           compressed.
   -b bits Set the upper limit (in bits) for common substring codes.
           "bits" must be between 9 and 16 (16 is the default).
   -p      Prefixes compressed files with the string "#!  cunbatchn"
           while compressing, and strips (and requires) this prefix
           from a file being uncompressed.  Used for sending
           (compressing) and receiving (decompressing) news.
   UTILITIES                                                Page C-6
   Compress


   -z      Leave name unchanged and don't impose or require "-Z"
           file names.
   filename ...
           Files to be compressed.  If none specified, stdin is
           used.


   C.3.4  Diagnostics

   Exit status is normally success (1); if the last file was not
   compressed because it became larger, the severity is WARNING.  If
   an error occurs, the severity is ERROR.

   Usage:  compress [-fvc] [-b maxbits] [file ...]
           Invalid options were specified on the command line.

   Missing maxbits
           Maxbits must follow -b.

   "file":  not in compressed format
           The file specified to "uncompress" has not been
           compressed.

   "file":  compressed with "xx" bits, can only handle "yy" bits
           "file" was compressed by a program that could deal with
           more "bits" than the compress code on this machine.
           Recompress the file with smaller "bits".

   "file":  already has -Z suffix -- no change
           The file is assumed to be already compressed.  Rename the
           file and try again.

   "file" already exists; do you wish to overwrite (y or n)?
           Respond "y" if you want the output file to be replaced;
           "n" if not.

   uncompress:  corrupt input
           A SIGSEGV violation was detected, which usually means
           that the input file is corrupted.

   Compression:  xx.xx%
           Percentage of the input saved by compression.  (Relevant
           only for -v.)

   -- not a regular file:  unchanged
           When the input file is not a regular file, (e.g. a
           directory), it is left unaltered.

   -- file unchanged
           No savings are achieved by compression.  The input
           remains uncompressed.
   UTILITIES                                                Page C-7
   Compress


   C.3.5  Notes

   This program uses the same algorithms as LZCMP and LZDCM, which
   are widely distributed through DECUS; in fact, we have used LZDCM
   to unpack "compress"ed files.  The only reason we need "compress"
   is to support the "#!cunbatch" header line placed in compressed
   News batches.  It seemed better to supply what looks like a
   completely different program for this purpose than to modify
   LZCMP and LZDCM, since those programs are being maintained by
   other people.

   "compress" should only be used on files that won't be bothered by
   conversion to stream-LF format, as it does not preserve record
   attributes (or other information from the file header).

   The amount of compression obtained depends on the size of the
   input, the number of "bits" per code, and the distribution of
   common substrings.  Typically, text such as source code or
   English is reduced by 50-60%.  Compression is generally much
   better than that achieved by Huffman coding (as used in "pack"),
   or adaptive Huffman coding ("compact"), and takes less time to
   compute.

   The "bits" parameter specified during compression is encoded
   within the compressed file, along with a "magic number" to ensure
   that neither decompression of random data nor recompression of
   compressed data is subsequently allowed.


   C.3.6  References

   "A Technique for High Performance Data Compression", Terry A.
   Welch, "IEEE Computer", vol.  17, no.  6 (June 1984), pp.  8-19.
   UTILITIES                                                Page C-8
|  Feedcheck - Summarize news logs


|  C.4  Feedcheck - Summarize news logs
|  
|  $ feedcheck/junk/since=y/before=today news_log:*.*
|  Site:    Files:Accept: Dups:Junked:Reject:Total: %Bad:%TAcpt:I've: Xmit:Bytes:
|  ==============================================================================
|  abekas                                                              4098  8.5M
|  athertn                                                             7501 17.5M
|  cmkrnl  4(96.0K)   26     4                  30  13.3%   0.3%          5  5.5K
|  decwrl  15(6.2M) 1477  1142    282         2901  49.1%  15.6%       8066 19.5M
|  inland   2(6.4K)          3                   3 100.0%                 1   938
|  lupine 28(19.5M) 7941   113    297         8351   4.9%  84.0%  562    27 46.2K
|  mail    3(20.7K)    5     6                  11  54.5%   0.1%
|  maps                                                                   3  128K
|  mccall                                                                27 70.1K
|  tcad                                                                  57  430K
|  
|           Files:Accept: Dups:Junked:Reject:Total: %Bad:%TAcpt:I've: Xmit:Bytes:
|  TOTAL: 73(25.8M) 9449  1268    579        11296  16.4%         562 19785 46.1M
|   7950   
|  Junked Newsgroups:
|  ======================
|      1 Articles in: alt.3d
|             1 from: lupine
|      9 Articles in: alt.abortion.inequity
|             4 from: lupine
|             5 from: decwrl
|      1 Articles in: alt.angst.xibo.sex
|             1 from: lupine
|      1 Articles in: alt.astrology
|             1 from: lupine
|      1 Articles in: alt.buddha.short.fat.guy
|             1 from: lupine
|      2 Articles in: alt.cad
|             2 from: lupine
|      4 Articles in: alt.cad.autocad
|             4 from: lupine
|      2 Articles in: alt.conspiracy.jfk
|             2 from: lupine
|      2 Articles in: alt.dads-rights
|             1 from: lupine
|             1 from: decwrl
|      2 Articles in: alt.devilbunnies
|             2 from: lupine
|      5 Articles in: alt.drumcorps
|             3 from: lupine
|             2 from: decwrl
|     13 Articles in: alt.duke.basketball
|            13 from: lupine
|      1 Articles in: alt.education.distance
|             1 from: lupine
|      6 Articles in: alt.ensign.wesley.die.die.die
|             4 from: lupine
|             2 from: decwrl
|      1 Articles in: alt.ernie-pook
|             1 from: decwrl
|      3 Articles in: alt.fan.frank-zappa
   UTILITIES                                                Page C-9
|  Feedcheck - Summarize news logs


|  
|  
   UTILITIES                                               Page C-10
|  Uuname - Report on available uucp neigbors


|  C.5  Uuname - Report on available uucp neigbors
|  
|  UUNAME.C        - has been enhanced to optionally display adjacent site 
|                    file-alias, spool directory, login account and option
|                    flags.
|  
|          $ uuname -?
|          uuname usage: uuname [option]
|          option
|                  -l      print the local system's uucp name and exit
|                  -s site check for definition of 'site'
|                  -d      display site spool directory
|                  -a      display site login account
|                  -o      display site option flags
|                  
|          $ uuname -d -a -o
|          decwrl                    decwrl       uu_decwrl      x0201     
|          athertn                   athertn      uu_atherton    -         
|          lupine                    lupine       uu_lupine      -         
|          mv3100                    mv3100       uu_mv3100      v         
|          simpact                   simpact      uu_simpact     -         
|          cmkrnl                    cmkrnl       uu_cmkrnl      -         
|          inland                    inland       uu_inland      -         
|          tcad                      tcad         uu_tcad        v         
|          triton                    triton       uu_triton      -         
|          capri-sun(capri)          capri-sun    uu_capri_sun   -         
|          fnn                       fnn          uu_fnn         v         
|          hisoft                    hisoft       uu_hisoft      x0201     
|          hiland                    hiland       uu_hiland      -         
|          abekas                    abekas       uu_abekas      -         
|          mas1                      mas1         uu_mas1        -         
|          uunet                     uunet        -              x7        
|          slc                       slc          -              x07       
|  
   UTILITIES                                               Page C-11
|  Uustat - Report on and allow control of queued uucp jobs


|  C.6  Uustat - Report on and allow control of queued uucp jobs
|  
|  UUSTAT.C        - This program is a reporting and control tool for the uucp
|                    queue system:
|  
|          $ UUSTAT -?
|          usage: uustat [-p] [-a]|[-q]|[-kjobid]|[-rjobid]|[-ssystem]|[-uuser]
|          options:
|                  -p      shows current uucp processes and ports
|                  -a      Shows Detail of jobs in queue
|                  -q      Shows Summary of queued jobs
|                  -gG     Restricts job selection to Grade 'G'
|                  -m      Shows accessability status of machines
|                  -n      Includes status of News
|                  -ssys   Restrict report to jobs relating to site 'sys'
|                  -suser  Restrict report to jobs relating to user 'user'
|                  -kjobid Kill Job 'jobid'
|                  -rjobid Rejuvinate Job 'jobid'
|                  -x      Turn on debug output
|  
|          Note, not all options make sense together.
|  
|  $ uustat -p -q
|  
|                    UUCP processes and Modem Line users:
|  
|  Username:     Node:   Process Name:     PID:    Terminal:
|  MARK          VS3100  MARK_3          2020014C  FTA10:
|                                                  Port: MODEM3: LTA5009:
|                                                                (DS200/T2500-1)
|                                                  Image: DTEPAD
|  UU_DECWRL     VS3100  uucp << decwrl  202004BD  VTA43: LTA5092:(DS200/TBPLUS)
|                                                  Image: UUCICO
|  UUCP_TEST     RCVAX   uucp -< -       20400256  VTA49:
|                                                  Image: UUCICO_DBG
|  UU_DECWRL     RCVAX   uxqt dcl        204006D3  (subprocess of 204005D2)
|  UU_DECWRL     RCVAX   uxqt << decwrl  204005D2  (batch)
|                                                  Image: UUXQT
|  UUCP_DAEMON   RCVAX   uucp -- -       20400811  (batch)
|                                                  Image: UUCICO
|  
|  Last Status:
|  p:uucp << h:decwrl  [03/11-11:08:56-202004bd]   They want to send (S D.decwrlBYB
|  k2 D.decwrlSYBk2 news - D.decwrlBYBk2 0666) u:news
|  
|               decwrl:  13 jobs,   0 files in,  26 files out, 2925674 bytesout
|  
|              athertn:   9 jobs,   0 files in,  18 files out, 3318594 bytesout
|  
|                 tcad:   1 jobs,   0 files in,   2 files out,   17676 bytesout
|  
|  Total Callout:        23 jobs,   0 files in,  46 files out, 6261944 bytesout
|  
|               decwrl:   2 jobs,   0 files in,   2 files out,    6665 bytesout
|  
|  Total Execute:         2 jobs,   0 files in,   2 files out,    6665 bytesout
   UTILITIES                                               Page C-12
|  Uustat - Report on and allow control of queued uucp jobs


|  
|  Total ReExecute:       1 jobs,   0 files in,   1 files out,     470 bytesout
|  
|          Grand Total:  26 jobs,   0 files in,  49 files out, 6269079 bytesout
|  
|  $ uustat -a
|  
|  [ ... Extra stuff deleted ... ]
    
|  Job: X-decwrl_myd_n3    3/11-11:01:17
|          Command: rmail netnews@infocomm.com
|          Input 4911 bytes in: $DISK6:[UUCP.SPOOL.decwrl]D.DECWRL_SYD_N2
|  Job: X-decwrl_mye93     3/11-11:01:26
|          Command: rmail mel@hisoft.infocomm.com
|          Input 1754 bytes in: $DISK6:[UUCP.SPOOL.decwrl]D.DECWRL_SYE92
|               decwrl:   2 jobs,   0 files in,   2 files out,    6665 bytesout
|  
|  Total Execute:         2 jobs,   0 files in,   2 files out,    6665 bytesout
|  
|  Job: REMAIL_X-infopiz_a1168    3/11-11:00:47
|          Command: rmail etst.infocomm.com!mark
|          Input 470 bytes in: $DISK6:[UUCP.SPOOL]D.INFOPIZ_A1168
|  Total ReExecute:       1 jobs,   0 files in,   1 files out,     470 bytesout
|  
|          Grand Total:  26 jobs,   0 files in,  49 files out, 6269079 bytesout
|  
|  $ uustat -k REMAIL_X-infopiz_a1168
|  Job: REMAIL_X-infopiz_a1168   --   Killed
|  $ 
|  
   UTILITIES                                               Page C-13
   Uurate - Report Transfer and Connect Times for Uucp Calls


   C.7  Uurate - Report Transfer and Connect Times for Uucp Calls

   C.7.1  Synopsis

           uurate [-s] [-c] [-h hostname] logfile ...  logfile


   C.7.2  Description

   "uurate" scans the specified uucp log files extracting and
   accumulating transfer rates and connect times for inbound and
   outbound uucp processing.

   Logfile names may include standard VMS wildcards.


   C.7.3  Options

   -s      Separate dialed in vs.  dialed out statistics in the
           resulting report.  The default is to report combined
           statistics.

   -c      Include information about uuxqt activity (rmail, rnews)

   -h host Restrict report to logfile entries relating to the
           indicated uucp neighbor


   C.7.4  Example Output

|  C.7.4.1  Example 1
|  
|  $ uurate -c uucp_log:uucp.log_0424
|   abekas: called out  13 of  19,  4812 secs, called in   9 of  10,   511 secs
|  athertn: called out   0 of   0,     0 secs, called in   6 of   6, 20827 secs
|   cmkrnl: called out   8 of  15,   892 secs, called in   0 of   0,     0 secs
|   decwrl: called out  14 of  24, 19846 secs, called in  16 of  16, 14738 secs
|      fnn: called out   2 of   8,   209 secs, called in   0 of   0,     0 secs
|   hisoft: called out   9 of  19,   796 secs, called in   5 of   5,   516 secs
|  infopiz: called out   0 of   0,     0 secs, called in   0 of   0,     0 secs
|   inland: called out   2 of   2,   177 secs, called in   1 of   1,    33 secs
|   lupine: called out  11 of  32,  9738 secs, called in  10 of  10,  3122 secs
|     tcad: called out   7 of   9,  1348 secs, called in   1 of   1,    12 secs
|  
|    TOTAL: called out  66 of 128, 37818 secs, called in  48 of  49, 39759 secs
|  
|  got from     abekas    2 files      885 bytes     6 secs  147.50 bytes/sec
|  got from     cmkrnl    4 files    40020 bytes    73 secs  548.22 bytes/sec
|  got from     decwrl  180 files 17415468 bytes 21800 secs  798.87 bytes/sec
|  got from        fnn    2 files    11684 bytes    56 secs  208.64 bytes/sec
|  got from     hisoft   71 files    15893 bytes   187 secs   84.99 bytes/sec
|  got from     inland    2 files     5303 bytes     7 secs  757.57 bytes/sec
|  got from     lupine   76 files 13744245 bytes 12995 secs 1057.66 bytes/sec
|  
|  sent to      abekas   70 files  5060191 bytes  4579 secs 1105.09 bytes/sec
|  sent to     athertn  112 files 21038923 bytes 18154 secs 1158.91 bytes/sec
   UTILITIES                                               Page C-14
   Uurate - Report Transfer and Connect Times for Uucp Calls


|  sent to      cmkrnl   26 files    78678 bytes   156 secs  504.35 bytes/sec
|  sent to      decwrl  114 files 10871426 bytes 13248 secs  820.61 bytes/sec
|  sent to      hisoft   14 files    12052 bytes    53 secs  227.40 bytes/sec
|  sent to      inland    6 files     6526 bytes    22 secs  296.64 bytes/sec
|  sent to      lupine   38 files  1337517 bytes  1525 secs  877.06 bytes/sec
|  sent to        tcad   28 files   181252 bytes   893 secs  202.97 bytes/sec
|  
|  sent to   ALL SITES  408 files 38586565 bytes 38630 secs  998.88 bytes/sec
|  
|      abekas total  5323 secs  overhead   738 secs
|     athertn total 20827 secs  overhead  2673 secs
|      cmkrnl total   892 secs  overhead   663 secs
|      decwrl total 34584 secs  overhead  -464 secs
|         fnn total   209 secs  overhead   153 secs
|      hisoft total  1312 secs  overhead  1072 secs
|     infopiz total     0 secs  overhead     0 secs
|      inland total   210 secs  overhead   181 secs
|      lupine total 12860 secs  overhead -1660 secs
|        tcad total  1360 secs  overhead   467 secs
|  
|  TOTAL Connect time 21:32:57, overhead   01:03:43
|  
|  Work from     abekas initiated the following commands:
|                                                    1 executions of rnews
|  Work from     cmkrnl initiated the following commands:
|                                                    2 executions of rnews
|  Work from     decwrl initiated the following commands:
|                                                   40 executions of rmail
|                                                   50 executions of rnews
|  Work from        fnn initiated the following commands:
|                                                    1 executions of rmail
|  Work from     hisoft initiated the following commands:
|                                                   23 executions of rmail
|  Work from    infopiz initiated the following commands:
|                                                   54 executions of rmail
|  Work from     inland initiated the following commands:
|                                                    1 executions of rnews
|  Work from     lupine initiated the following commands:
|                                                   37 executions of rnews
|                                                    1 executions of rmail
|  
|  Work from  ALL SITES initiated the following commands:
|                                                  119 executions of rmail
|                                                   91 executions of rnews
|  
|  
|  
|  
|  
|  C.7.4.2  Example 2
|  
|  $ uurate -sc UUCP_LOG:uucp.log_0424
|   simpact called us   4 times,  1163 secs
|  got from  simpact    6 files   252896 bytes  1105 secs  228.87 bytes/sec
|  sent to   simpact    2 files     1889 bytes     5 secs  377.80 bytes/sec
|  
   UTILITIES                                               Page C-15
   Uurate - Report Transfer and Connect Times for Uucp Calls


|  we called  simpact   9 times,    66 secs
|  sent to   simpact    2 files     1007 bytes     5 secs  201.40 bytes/sec
|  
|    inland called us   6 times,    36 secs
|  
|    lupine called us   1 times,  1441 secs
|  got from   lupine    2 files   317221 bytes  1431 secs  221.68 bytes/sec
|  
|  we called   lupine   7 times,  2830 secs
|  sent to    lupine   12 files  1060339 bytes  2679 secs  395.80 bytes/sec
|  
|   athertn called us   1 times,   332 secs
|  got from  athertn    4 files     4283 bytes    15 secs  285.53 bytes/sec
|  sent to   athertn    6 files   283071 bytes   278 secs 1018.24 bytes/sec
|  
|  we called  athertn  20 times,   212 secs
|  got from  athertn    8 files    21874 bytes    37 secs  591.19 bytes/sec
|  sent to   athertn    4 files     9197 bytes    15 secs  613.13 bytes/sec
|  
|      simpact live  1229 secs  dead   114 secs
|       esther live    36 secs  dead    36 secs
|       lupine live  4271 secs  dead   161 secs
|      athertn live   544 secs  dead   199 secs
|  
|  Work from  simpact initiated the following commands:
|                                                    3 executions of rmail
|  Work from   lupine initiated the following commands:
|                                                    1 executions of rnews
|  Work from  athertn initiated the following commands:
|                                                    3 executions of rnews
|                                                    3 executions of rmail
|  
|  
|  (The "live" times show total times for all calls; "dead" refers
|  to those periods within the calls when no data is being
|  transferred:  Login, protocol negotiation, searching for work,
|  etc.)
|  
|  
|  C.7.5  Notes
|  
|  Uurate is run automatically once a day by the UUCP_CLEANUP batch
|  job.  The resulting report is mailed to UUCP_POSTMASTER.
|  
|  
|  C.7.6  Bugs
|  
|  As might be expected of a utility ported from Unix, the "-s"
|  option here has a completely different meaning than the "-s"
|  option to uucico.  We'll fix this in a later release.
|  
|  The call times reported by uurate are not necessarily the times
|  the telephone company will charge for.  For example, if login
|  fails after a successful dial, the uucp log file (and therefore
|  uurate) treats it as a zero-length call.  (This was noticed by
|  Chetan Premani, root@shakti.ernet.in.  Some improvements are
   UTILITIES                                               Page C-16
   Uurate - Report Transfer and Connect Times for Uucp Calls


|  possible in this area, but since the phone company starts billing
|  as soon as the called modem picks up, even if we never even get
|  carrier, we can't do it perfectly.)












                              APPENDIX D

                            ADDRESS FORMATS



   This appendix provides a brief introduction to the construction
   and use of network addresses.


   D.1  The Simple Cases

   D.1.1  How Do People Send Mail To Me?

   Until you are registered as an Internet domain, you can tell
   people that your network address is

           yourhost!user

   (where "yourhost" is your uucp host name, and "user" is your
   regular VMS username).

   A lot of mail sent that way won't get to you until your map entry
   gets out to the world in general, so for a month or two at least,
   it's best to publicize an address like

           well-known-host!intermediate-host!...!...!yourhost!user

   where the ellipses represent whatever other sites are in the path
   between you and the well-known-host.  In fact, it's best to
   continue this practice indefinitely, since many uucp sites still
   aren't using the maps.  If your host is connected to several
   well-known hosts, you might publish something like this:

           {wkh1, wkh2, wkh3}!yourhost!user

   The commas are interpreted as meaning "or".

   Received mail sent to yourhost!user will be placed in that user's
   VMSmail NEWMAIL folder, just like regular VMSmail.  The VMSmail
   "From:" line will show UUCP%"...", where ... will usually be in a
   form acceptable to the uucp mail router.  In other words, the
   VMSmail REPLY command should work.  (If it doesn't, see the next
   sections.)

   Do not advertise yourself as having a "domainized" name (for
   example, user@yourhost.companyname.com) until your domain is
   officially registered.
   ADDRESS FORMATS                                          Page D-2
   The Simple Cases


   As discussed in the chapter on Internet domain registration, many
   sites use ".uucp" as a domain, e.g. user@yourhost.uucp until they
   are officially registered.  This used to be benign, but ".uucp"
   is now an officially recognized Internet zone (but not a domain).
   The ".uucp" practice is still widespread, however, and in fact
   many Internet sites have mailers that can (usually) send to
   "user@host.uucp" automatically, so unregistered uucp sites will
   probably continue to publicize names of this form.

   Note that the mail router used here and at many other uucp sites
   makes it possible to send to "user@host" as long as the host is
                                                                ___
   known in the uucp maps.  But the success of this syntax does not
   mean that the site in question has an officially registered
   "domain name".  See the chapter on Internet Domain Registry for
   more details.


   D.1.2  How Do I Send Mail Out?

            ____
   For most sites, you will be able to respond to the VMSmail "To:"
   prompt with

           UUCP%"user@site"

         ____
   where site is usually something like machine.organization.domain
                                                   ____
   , but may be as simple as a uucp host name, and user is a
   username on that system.

   If someone gives you an address like

           remhost!user

   you can generally use a VMSmail "To:" address of

           UUCP%"user@remhost"

   If you get something in the more complex form shown previously,

           well-known-host!intermediate-host!...!...!theirhost!user

   you can try sending to UUCP%"user@theirhost" first; if that
   doesn't work, just wrap UUCP%"..." around the whole mess.  You
   needn't worry about how to get to well-known-host:  If it's
   well-known it'll be in the maps, and the mailer will figure out
   the path from your system.

   If your addressee has given you an address like

           {wkh1, wkh2, wkh3}!theirhost!user

       ______
   you cannot pass this to Mail directly.  The idea is that you are
                                        ___
   supposed to figure out how to get to one of the
   "well-known-hosts" mentioned (your choice as to which).  So try
   something like

           UUCP%"wkh2!theirhost!user"
   ADDRESS FORMATS                                          Page D-3
   The Complex Cases


   D.2  The Complex Cases

   The above techniques will often fail for @-form addresses when
   networks other than uucp or Internet are involved (and sometimes
   even then).  This is particularly true of Bitnet, which uses
   Internet-style addresses and otherwise looks like part of the
   Internet, but isn't really.

   The general solution is to "send the mail through a gateway".  A
   later version of this document will expound upon the
   possibilities.  For now, refer to the files in [.DOC.ADDRESSING],
   which are mostly a collection of questions and answers on these
   issues that have appeared on the net.


   D.2.1  Percent Signs

   Many addresses include imbedded percent signs; for example:

           TNIELAND%FALCON@AAMRL.AF.MIL

   There are differences of opinion as to how this should be
   interpreted.  In general it usually is interpreted with
   everything to the left of the "@" as being a "funny username", so
   the mail is sent to

           TNEILAND%FALCON   at   AAMRL.AF.MIL

   on the assumption that aamrl.af.mil will know what to do with it.
   (In this particular case, they do.)

   Troubles may arise when addresses of this form are handed to uucp
   (any uucp, not just ours).  For uucp transmission we must convert
   __________
   everything to bang-path notation, so we end up with something
   like

           neighbor!...!AAMRL.AF.MIL!TNEILAND%FALCON

   This works fine when I send mail to this address (actually I send
   to UUCP%"TNIELAND%FALCON@AAMRL.AF.MIL"), but Tom Allebrandi's
   uucp "neighbor" hates to see !'s and %'s in the same address, and
   either bounces it as undeliverable or does horrible things to it.
   Tom gets around this by converting the % to a !  himself, sending
   to

           UUCP%"FALCON!TNEILAND@AAMRL.AF.MIL"

   This workaround succeeds in this particular case because aamrl
   knows to handle falcon!tneiland just as it would handle
   tneiland%falcon.  In the general case, success depends on the
   capabilities of the target Internet host.  The next section
   discusses addresses of this form in more detail.
   ADDRESS FORMATS                                          Page D-4
   The Complex Cases


   D.2.2  Mixed Uucp/Domain Addresses

   Sometimes you will see an address of the form

           uuhost!user@inethost.company.com

   Such an address, combining "!" and "@" notation (with maybe some
   "%"s thrown in for good measure), is referred to as a "mixed
   mode" address.  These addresses are often used by uucp sites
   (uuhost in this example) who do not have registered domain names,
   but have a uucp connection to a nearby host
   (inethost.company.com) who does.  In general more sites will know
   how to get to inethost.company.com than to uuhost, so they are
   trying to make it easy for people to send mail to them.

   If someone -- particularly someone on the Internet -- is having
   trouble sending mail to you, you might try telling them to use
   such an address.  For example, if you know of an Internet site
   (isite.dom.ain) that reaches you reliably via uucp, you might
   suggest that they try

           yourhostname!you@isite.dom.ain

   meaning "send mail to isite.dom.ain, who will send it to
   yourhostname!you".

   Addresses of this form should not, in general, be published "at
   large" as your "standard" address, but only given out to
   individual correspondents to solve particular problems.  DECUS
   uucp will generally do the right thing when asked to send mail to
   an address like this, but this is not true of all other uucp
   systems.  This is because the interpretation of such an address
   as a mail destination varies depending on the machine sending the
   mail.

   Using the second example above:  If the machine from which mail
   is being sent to you understands "@"-signs (as DECUS uucp
   machines do), this address is equivalent to

           isite.dom.ain!yourhostname!you

   meaning "send it to isite.dom.ain, who will send it to
   yourhostname!you, which is what you want.  (In practice there
   will probably be some additional hosts in the bang-path prior to
   isite.dom.ain .)  But a "pure uucp" machine might send it this
   way:

           yourhostname!isite.dom.ain!you

   which is obviously wrong, since the pure uucp machine likely
   doesn't talk to yourhostname.  (If they do, they can just send to
   yourhostname!you and avoid all this bother.)  Even if the message
   does get to yourhostname, this address tells yourhostname to send
   it to isite.dom.ain, and you don't live there!
   ADDRESS FORMATS                                          Page D-5
   The Complex Cases


   So, in general, it is a bad idea to publicize addresses of this
   form.  If you want an "@" in your e-mail address, register your
   site as an Internet domain, as described in a subsequent chapter.












                              APPENDIX E

                  MISCELLANEOUS QUESTIONS AND ANSWERS



|  E.1  Why Are File Transfers So Slow?
|  
|  We frequently get complaints that uucp is reporting file
|  transfers at much slower speeds than the sites' modems are
|  capable of.  Let's look at the reasons for this.
|  
|  First, the "Cps" shown in the log files (and uurate output) is
|  characters/second.  (In previous versions it was "Bps", which
|  many interpreted as "bits per second".)  So you are probably
|  thinking that with a modem speed of 9600 bits/sec you should be
|  getting close to 960 bytes/sec.  And you probably are, in bursts.
|  
|  However, the time we log for a uucp file transfer includes the
|  all of the file transfer setup time, which typically involves
|  
|  (sender)                                (receiver)
|  
|  start = current_time()
|  send "request to send" message (S) -->
|                                          start = current_time()
|                                  <---    send "go ahead" message (SY)
|  send file -->
|                                  <---    send "got it" message (CY)
|                                          end = current_time()
|  [upon receipt of CY message]            elapsed = end-start
|  end = current_time()                    speed = file_size / elapsed
|  elapsed = end-start
|  speed = file_size / elapsed
|  
|  
|  So the elapsed time, from which the speed in the log files is
|  calculated, includes a little more than just the sending of the
|  file itself.  These extra messages are quite short, but they must
|  be sent in a "stop and wait" fashion; windowing applies only to
|  the data link level.  The sender, for example, cannot simply send
|  the "request to send" message and then blithely start sending the
|  file; it has to wait for the "go ahead" message to come back.
|  
|  Each of these messages can add half a second or so to the total
|  elapsed time, For very short files sent over high-speed links,
|  these little delays can be a large part of the total elapsed
|  time!  This gets especially bad on Telebit PEP links, since these
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-2
|  Why Are File Transfers So Slow?


|  are essentially half-duplex modems and they have to turn the line
|  around for each message.
|  
|  Also, our times are counted simply in seconds (so the elapsed
|  time is accurate only to plus-or-minus two seconds, an error
|  which can easily swamp the transfer time of small files).
|  
|  For example, I just got a file of length 1130 bytes over a
|  Telebit PEP link.  total elapsed time was measured as three
|  seconds...  so uucp reported 377 Bps.  Oh well.
|  
|  (This is the motivation for "uubatch", which we may support
|  further down the line.  uubatch collects outgoing mail for a
|  given neighbor and batches it into a single compressed file, much
|  as is done for news.)
|  
|  Have your neighbor send you a file of, say, 30,000 bytes length
|  or so, and look at the log file to see how fast we think that
|  happens.
|  
|  But even if you do that and see "920 Bps" in the logs for that
|  particular file, don't expect uurate to report that the next
|  morning, not if you also have a lot of mail traffic (small
|  files).  Uurate adds up all of the files and all of the transfer
|  times and divides, so if you have lots of small files the low
|  effective transfer rates on them will be averaged in with your
|  single big file.
|  
|  
|  E.2  Why Batch Jobs?
|  
|  "Why did you [we] make the uucico_callout and uuxqt processes
|  batch jobs instead of detached processes?  I always see them
|  (plus the holding uuclean job) when I look at batch queues and
|  their status is even 'executing', though I know that if I look at
|  them with SHOW SYSTEM I shall nearly always find them in LEF or
|  HIB status."
|  
|  Because of the way they're invoked.  Both of them need to have
|  DCL present for one reason or another.  The technique of starting
|  a detached process that runs the loginout image, and pointing its
|  sys$input at a command procedure, is, for all its popularity, not
|  supported.  Nor does it do the right things with the log files we
|  want written to sys$output.
|  
|  Anyway, what is the problem?  An executing batch job takes no
|  more resources than an executing detached process -- In fact, it
|  *is* an executing detached process, it just happens to have been
|  created by the job controller.
|  
|  The other side to this question is "why do they have to be
|  executing all the time, can't they be created upon demand and
|  then go away?" We tried that fairly early; we found we were
|  creating them very very often, so often that on small machines
|  the process-creation overhead was unacceptable.  In addition, the
|  create-on-demand approach would create dozens upon dozens of
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-3
|  Why Batch Jobs?


                             ___ ___
|  small batch job log files per day.  This way we just get one per
|  batch job.
|  
|  
|  E.3  Why do all the uucp usernames have the same UIC?
|  
|  There are several independent arguments for this approach.  The
|  most cogent is:
|  
|  It is entirely appropriate to have these different usernames with
|  the same UIC.  It would be different if these accounts were used
|  by different interactive users (that is, different people).  But
|  they are used by different incarnations of automatic processes.
|  Each and every one of those processes should be treated in
|  exactly the same way with respect to file protection, the
|  ownership of files it creates, and other UIC's access to those
|  files.  That that makes "the uucp accounts" a single "user" as
|  far as VMS file security philosophy is concerned.
|  
|  It is true that one might want to have different restrictions to
|  files in the UUCP_PUBLIC directory (assuming that you have
|  defined one) for different neighbor sites.  However, unique UICs
                                             ______
|  for each neighbor do not begin to provide enough control --
                          ________
|  particularly since all outbound calls to all neighbors will
|  always be performed under the auspices of a single UIC (that of
|  the UUCICO_CALLOUT batch job) anyway.
|  
|  Discounting for a moment the UUCP_PUBLIC issue, it is certainly
|  possible to set the different uucp usernames into different
|  members of the same UIC group.  But then you have to go around
|  and fix things up with ACLs and protection masks so that all the
|  different members of this group are treated so that they are all
|  equivalent and so that they have access to the files created by
|  each other.  But once you have done that, where is the
|  distinction between the different UICs?  If you are going to do
|  that anyway (and you have to, for uucp to work right), why did
|  you want them to have separate UICs in the first place?
|  
|  
|  E.4  Why Must NEWS_MANAGER be on the same disk as NEWS_DEVICE ?
|  
|  This didn't used to be a requirement and at least some people are
                                                    _
|  set up with news_manager on the same disk as newsroot instead (I
|  know I was -- JEH).  However, Mark Pizzolato has done extensive
|  research in this area.  Here is his answer.
|  
|  The placement of NEWS_MANAGER is not particular to the version of
|  NEWS, but specifically to the assumptions that are made in
|  NEWS_RNEWS and NEWSSKIM.  These assumptions are being made to
|  avoid potential deadlocks of news flow, due to disk space
|  considerations.  These potential deadlocks can be avoided if you
|  have NEWS_DEVICE on a different disk than UUCP_DISK.  If
|  NEWS_DEVICE is the same device as UUCP_DISK, the potential will
|  always exist.
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-4
|  Why Must NEWS_MANAGER be on the same disk as NEWS_DEVICE ?


|  First, performance is not the driving issue.  Consider the
|  typical case of an incoming batch that is compressed.  The
|  compressed batch in UUCP_RCVDNEWS is uncompressed with output to
|  NEWS_MANAGER.  In theory separate disks for this operation might
|  be preferred, but the I/O that is going on here is very well
|  buffered (i.e.  read/writes of 100+ blocks), so it would be hard
|  to measure much of a difference in either case.  So this is not a
|  contributing factor to a "preference" for NEWS_MANAGER being in
|  one place or another.
|  
|  The result, however, sets things up for the next step, which is
|  the actual ADD processing into news.  During this phase, data is
|  read from the uncompressed batch (with reasonably large buffers,
|  so once again preference for a different spinle is mitigated).
|  Info from each item being added is added to the index files, and
|  COPIES of each item are placed in:
|  
|  - The directory for EACH newsgroup mentioned in the Newsgroup:
|  header line.  Most items actually are NOT cross posted, so the
|  word EACH above should probably not be in caps.  I contend,
|  however, that the I/O load to update file system data structures
|  for this item (File Header, & Directory blocks), is usually
|  greater than the I/O to actually write the actual item contents.
|  This I/O is exceptionally bad since operations that update these
|  file system critical data structures are done (by the XQP), with
|  "datacheck", so this is twice the normal I/O.
|  
|  - The NEWS.BATCH file for EACH downstream site.  These are
|  updated to include the contents of the new item.  The changes I
|  have submitted to Geoff (included in News 6.1 Alpha4, which is
|  the version included in this release) minimize the I/O load for
|  this.  In the past, the downstream batch files were opened,
|  written, and closed for EACH downstream sites for EACH item.  Now
|  I/O to these files uses large buffers and only closes the file
|  either at the end of the whole input batch or when the size of
|  the downstream batch files exceeds its maxsize threshold.  Hence,
|  I/O load for I/O to the downstream batch files is usually not
|  much of a bottleneck.
|  
|  Thus, performance is, in general, not a significant part of why
|  NEWS_MANAGER should be off the UUCP_DISK.
|  
|  Second, fragmentation is not the driving issue.
|  
|  In general the activities in UUCP_SPOOL don't contribute in a
|  horrible way to fragmentation since this stuff tends to get
|  created and completely deleted together, hence you are shortly
|  exactly where you started (i.e.  once ths batch has been
|  transmitted).  This argument breaks down when the dribbling
|  growth of the UUCP_LOG files is taken into account.  These little
|  pieces of log have different lifetimes than the quickly
|  transitional aspect of the batch contents.
|  
|  We do prefer NEWS_ROOT (big index files) to be on a different
|  device from the NEWS_DEVICE (tens of thousands of small
|  sequential files) solely for reasons related to fragmentation and
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-5
|  Why Must NEWS_MANAGER be on the same disk as NEWS_DEVICE ?


|  not performance.  Performance benefits from multiple spindles are
|  best realized when you overlap I/O.  The processing of a single
|  inbound news batch really doesn't overlap any I/O at all so the
|  only gain you get from separate spindles is possible "locality of
|  reference" effects.
|  
|  The driving factor behind the placement of the NEWS_MANAGER tree
|  is the management of disk space so that things continue to
|  function.
|  
|  NEWS_MANAGER will contain approximately a 2*(1+n) amount of EXTRA
|  disk space (for the uncompressed copy of the original batch, AND
|  copies for EACH down stream site).  Space on the NEWS_DEVICE
|  (home of the item files) already has the largest dynamic range
|  since even without feeding any downstream sites, stuff comes in
|  all day, and space usage peaks just prior to the nightly skim.
|  With a reasonably full feed, this variation is more than 50mb on
|  a typical day with peaks FAR greater than that depending on how
|  smooth things are flowing in the net in general (I've gotten
|  peaks of 50MB compressed in from DECWRL in a single day).
|  
|  Feeding multiple sites implies that a single inbound batch can
|  explode by a significant number while it is being processed.  In
|  order to handle the dynamics of this explosion it should be
|  stored on the device that already has the need/capacity for large
|  usage fluctuations.
|  
|  My real world case operating in this mode:
|  
|          NEWS_DEVICE and NEWS_MANAGER on a large disk
|          UUCP_SPOOL on a disk with approximately 15000 blocks free (MAX)
|          UUCP_MINIMUM_DISK_SPACE set at 3000
|  
|  Take Yesterday's UURATE is a typical example:
|  
|   lupine: called out   1 of  24,   595 secs, called in   4 of   5, 17895 secs
|   decwrl: called out  14 of  17, 23218 secs, called in   9 of  10, 26645 secs
|     tcad: called out  11 of  12,  2169 secs, called in   1 of   1,   160 secs
|   abekas: called out  11 of  12,  5693 secs, called in   7 of   7,  3620 secs
|      fnn: called out   1 of   3,    69 secs, called in   2 of   2,    78 secs
|   inland: called out   2 of   3,   179 secs, called in   1 of   1,    25 secs
|   hisoft: called out   8 of   9,   648 secs, called in   3 of   3,   111 secs
|   cmkrnl: called out   7 of  16,  1004 secs, called in   2 of   2,    50 secs
|  athertn: called out   0 of   0,     0 secs, called in   6 of   6, 14704 secs
|  simpact: called out   0 of   0,     0 secs, called in   2 of   2,    18 secs
|  
|    TOTAL: called out  55 of  96, 33575 secs, called in  37 of  39, 63306 secs
|  
|  got from     lupine   90 files 16467392 bytes 15643 secs 1052.70 bytes/sec
|  got from     decwrl  172 files 12458903 bytes 15392 secs  809.44 bytes/sec
|  got from       tcad    2 files     2502 bytes    16 secs  156.38 bytes/sec
|  got from     abekas    4 files     1164 bytes    22 secs   52.91 bytes/sec
|  got from        fnn    2 files     7450 bytes    51 secs  146.08 bytes/sec
|  got from     inland    2 files     3392 bytes     6 secs  565.33 bytes/sec
|  got from     hisoft    4 files     1848 bytes    11 secs  168.00 bytes/sec
|  got from     cmkrnl   14 files   201616 bytes   278 secs  725.24 bytes/sec
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-6
|  Why Must NEWS_MANAGER be on the same disk as NEWS_DEVICE ?


|  
|  got from  ALL SITES  290 files 29144267 bytes 31419 secs  927.60 bytes/sec
|  
|  sent to      lupine   34 files  1357073 bytes  1047 secs 1296.15 bytes/sec
|  sent to      decwrl  232 files 22285196 bytes 29631 secs  752.09 bytes/sec
|  sent to        tcad   34 files   307804 bytes  1520 secs  202.50 bytes/sec
|  sent to      abekas  104 files  9981829 bytes  7894 secs 1264.48 bytes/sec
|  sent to      inland    4 files     8354 bytes    16 secs  522.13 bytes/sec
|  sent to      hisoft   16 files    14600 bytes    87 secs  167.82 bytes/sec
|  sent to      cmkrnl   18 files    39650 bytes    97 secs  408.76 bytes/sec
|  sent to     athertn   98 files 22211445 bytes 19650 secs 1130.35 bytes/sec
|  
|  sent to   ALL SITES  540 files 56205951 bytes 59942 secs  937.67 bytes/sec
|  
|      lupine total 18490 secs  overhead  1800 secs
|      decwrl total 49863 secs  overhead  4840 secs
|        tcad total  2329 secs  overhead   793 secs
|      abekas total  9313 secs  overhead  1397 secs
|         fnn total   147 secs  overhead    96 secs
|      inland total   204 secs  overhead   182 secs
|      hisoft total   759 secs  overhead   661 secs
|      cmkrnl total  1054 secs  overhead   679 secs
|     athertn total 14704 secs  overhead -4946 secs
|     simpact total    18 secs  overhead    18 secs
|  
|  TOTAL Connect time 26:54:41, overhead   01:32:00
|  
|  That's 85mb of traffic passing trough some 8mb of UUCP_SPOOL
|  space.  Peak space consumed in NEWS_MANAGER_DEV easily reaches
|  25mb (Note this is uncompressed form).
|  
|  If things were rearranged with NEWS_MANAGER_DEV on the UUCP_SPOOL
|  device, the first time the UUCP_SPOOL disk gets too close to
|  filling, you get wedged permanantly -- because NEWS_MANAGER_DEV
|  gets emptied by taking the batches and compressing them into
|  files in UUCP_SPOOL.  The wedging can happen if your news node
|  gets busy with other work, if it has to go off the air for some
|  time (and then gets hit with several days' worth of news in one
|  day), or simply gets behind processing the inbound flow.  In
|  these cases processing of inbound batches does nothing to free
|  space on the spool disk since the downstream feeds will be
|  consuming more that input batch frees.
|  
|  With NEWS_DEVICE and NEWS_MANAGER_DEV the same device, things can
|  get at worst temporarily wedged if this disk gets full.  The
|  wedging is still only temporary if both UUCP_DISK and NEWS_DEVICE
|  gets full since space will be freed nightly by the skim
|  processing.
|  
|  
|  E.5  I enabled long packets and large windows, but...
|  
|  ..I started getting typeahead buffer overflow warnings; or
|  ..Throughput dropped through the floor; or
|  ..nothing changed.
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-7
|  I enabled long packets and large windows, but...


|  E.5.1  Should I Bother Playing With This in the First Place?
|  
|  Larger-than-default window and buffer sizes can drastically
|  improve throughput on connections that are:
|  
|        o  4800 char/sec or faster modem modulation speed.
|  
|        o  Made over relatively long distances.
|  
|        o  Not "spoofed".
|  
|        o  Made to systems that correctly support larger values for
|           these parameters.
|  
|  Some uucp implementations will stop working if the neighbor
|  system "advertises" that it supports larger-than-default values
|  for these parameters.  Therefore, don't experiment if you aren't
|  having throughput problems.
|  
       _____
|  And don't try it with spoofed connections through Telebit modems;
|  these connections (a) only support the default 3x64, (b) wouldn't
|  go any faster if they supported larger values; and (c) may have
|  problems if you try to use larger values.
|  
|  
|  E.5.2  What Do These Values Mean?
|  
|  The maximum window and buffer sizes declared in your systems file
|  specify two values each:
|  
|        o  The maximum window and buffer sizes you will allow the
|           neighbor you use when they transmit to you; and
|  
|        o  The maximum window and buffer sizes which you will use
|           when sending to your neighbor.
|  
|  These default to the uucp standard of 3 packets, 64 bytes per
|  packet (respectively).
|  
                                       _______
|  Note that in any case these are the maximum values:
|  
|        o  For transmissions from your neighbor, your neighbor's
|           maximum transmit window and buffer sizes may be smaller
|           than what you've said you'll allow, in which case your
|           neighbor will use their local maximum values.
|  
|        o  For transmissions to your neighbor, the maximum values
|           your neighbor will allow you to use may be smaller than
|           what you will allow, in which case your side will use
|           your neighbor's maximum values.
|  
|  By the way, it is these latter values (the negotiated sizes which
|  you will use in sending to your neighbor; these are the smaller
|  of what you and they will support) that are reported in the new
|  "Startup ok" message ("xmt w=n, b=nn").  Thus, if you are talking
|  to a neighbor that doesn't support large windows or long buffers,
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-8
|  I enabled long packets and large windows, but...


|  and you say w7b4096 in your systems file, your log will still
|  show "xmt w=3, b=64".  This is normal; it does not mean that your
|  new system file entry is not working; it means that your neighbor
|  doesn't support these higher values.
|  
|  As for the other direction, we really have no way to know what
|  the neighbor is going to use for buffer and window size when
|  sending to you, except by observing their data packets as they
|  come in.  The 2.0 code reports the maximum packet size sent by
                       ___
|  the neighbor at the end of the call (in the "Shutdown ok"
|  message), and does not report the window size.
|  
|  
|  E.5.3  Advice on Twiddling Window and Buffer Size
|  
|  First, set w to 7.  See if things still work.
|  
|  Then try increasing b one step at a time (start with b128, then
|  b256, etc.) until performance "levels off"; going further will
|  only introduce problems.
|  
|  Note, large buffer*window sizes means correspondingly large
|  typeahead buffers if you expect it to work!  Really large buffers
|  will require an increase in the SYSGEN parameter MAXBUF.  (MAXBUF
|  sets an upper limit on the size of any buffered I/O operation.
|  It is a dynamic parameter, so you can change it without a
|  reboot.)  Also, make sure that BYTLM for the uucp accounts is at
|  least 20000.
|  
|  If you have problems, set w back down to 3 and try again with
|  b128, b256, ...).  (Large windows will increase recovery time
|  after an error.)
|  
      ___
|  If any increase in buffer size causes problems, try leaving it
|  defaulted and increasing the window size.  (Some uucps claim to
|  support long packets, but fail when they actually receive them.)
|  
|  In every case, the typeahead buffer for the line in question must
|  be able to hold an entire "window" of packets.  The packet size
|  is actually 6 bytes longer than the buffer size we are setting
|  here.  So, for example, a window size of 7 with buffer size of
|  4096 would require a typeahead buffer of 7*(4096+6) = 28,714
|  bytes.  (Now you know why we recommend setting the buffer size
|  only as large as it needs to be to increase throughput.)
|  
|  
|  E.6  Can I "Redirect" Incoming uucp Mail via VAX MAIL's SET
|       FORWARD mechanism?
|  
|  Sure.  When the mail arrives at the destination node, it is
|  simply delivered to the local username.  This may be redirected
|  in either of two ways:
|  
|          MAIL> SET FORWARD /USER=username forwarding-address
   MISCELLANEOUS QUESTIONS AND ANSWERS                      Page E-9
|  Can I "Redirect" Incoming uucp Mail via VAX MAIL's SET FORWAR ...


|  or
|  
|          $ DEFINE username forwarding-address
|  
|  The former requires SYSNAM privilege.  The latter must be done in
|  a context where the UUXQT process will "see" it, perhaps in the
|  group logical name table for the uucp UIC.
|  
|  In either case, the "username" does not actually have to exist in
|  the UAF.
|  
|  The MAIL> SET FORWARD method overrides any logicals (i.e. if MAIL
|  finds a forwarding entry, it doesn't bother looking for a logical
|  name).
|  
|  If forwarding to another foreign protocol mechanism, such as MX
|  or PMDF, be careful to use an adequate number of quotes.  For
|  example:
|  
|          MAIL> SET FORWARD /USER=username
|  "MX%""user@foo.bar.com"""
|  
|  or
|  
|          $ DEFINE username "PMDF%""user@foo.bar.com"""
|  
|  
|  E.7  Details on startup in a VMScluster
|  
|  Q:  The startup procedures in a cluster seem to do too much on
|  the non-UUCP nodes.  The other nodes really shouldn't need to
|  know about the batch jobs at all, and the executables (other than
|  UUCP_MAILSHR) shouldn't have to be installed.
|  
|  A:  From Mark Pizzolato (who wrote the V2.0 startup procedures,
|  GENERATE_CONTROL.COM, etc.):
|  
|  Well, it all comes down to par of providing a reliable mechanism
|  that deals with all possible combinations of:
|  
|        o  which node in the cluster is the UUCP_BATCH_NODE
|  
|        o  which node in the cluster is the boot node
|  
|        o  which node in the cluster serves the UUCP_DISK to the
|           cluster
|  
|        o  which order each of these nodes boots
|  
|        o  handling the possibility of any of these nodes rebooting
|           in any particular order.
|  
|  There might be some flexibilty with the new
|  batch/print/queue-manager in VMS V5.5, but it's a little early to
|  build in such dependencies.  :-)
   MISCELLANEOUS QUESTIONS AND ANSWERS                     Page E-10
|  Details on startup in a VMScluster


|  Q:  It would be good to have as few installed images as possible.
|  It's not obvious that UUCICO.EXE, RUNUUXQT.EXE, and UUXQT.EXE
|  must be installed on every system in the cluster.
|  
|  A:  This involves about 3 global sections and less than 200
|  global page table entries (at a cost of one physical page per 128
|  entries) per node.  Don't worry about it.
|  
|  By the way, it is always a good idea to increase the SYSGEN
|  parameter GBLPAGES to some huge value, like 100,000, to ensure
|  against running out.  100,000 extra global page table entries
|  will cost about 6 pages of physical memory if they are never
|  used.  This is cheap insurance against running out.  For global
|  page table entries that are used (perhaps by an installed image),
|  the cost is only one page of physical memory per 128 page table
|  entries.  Global pages are only mapped to actual physical pages
|  when one or more processes have them in their working set (just
|  as with any other part of process virtual address space).
|  
|  
|  E.8  Why is UUCICO.EXE installed with CMKRNL?
|  
|  The code that allows uucico to grant itself various identifiers
|  based on the remote uucp hostname, the local username with which
|  they're calling in, etc., requires this privilege.  (See the
|  chapter on UUCP File Transfers.)  If you don't like this, you can
|  edit UUCP_SYSTARTUP.COM to not give this privilege to
|  UUCIOCO.EXE.  In that case, file transfers in and out of the
|  UUCP_PUBLIC directory will be governed only by normal UIC- and
|  ACL-based protection, in the context of the uucp usernames.  This
|  is still secure (ie UUCICO will still force all file transfers to
|  the UUCP_PUBLIC or UUCP_SPOOL directories, as described
|  elsewhere) but does not allow the fine degree of control that is
|  possible with the identifier mechanism.












                              APPENDIX F

                            SECURITY ISSUES



   Unix uucp is notorious for being insecure by default.  The paper
   "Uucp Implementation Description" by D. A. Nowitz says this:

           "The uucp system, left unrestricted, will let any outside
           user execute any commands and copy in/out any file which
           is readable/writeable by the uucp login user.  It is up
           to the individual sites to be aware of this and apply the
           protections that they feel are necessary."

   In retrospect, this is understandable, as Unix uucp was
   originally developed to transfer arbitrary files and allow remote
   command execution in a completely-trusted environment (mail came
   a bit later, and news came much later).

   We were quite aware of uucp's history and reputation,
   particularly since many of the people who expressed interest in
   "uucp mail" for their VMS systems also expressed grave concerns
   over security issues.  So, a prime goal of this project was to
                                         __ _______
   make DECUS uucp as secure as possible by default -- that is, with
   no special action by the VMS system manager, and in spite of the
   lax security in effect on many (if not most) VMS systems.  (VMS,
   for example, comes with just about everything set world readable;
   this may be fine within your shop, but you probably don't want
   your uucp neighbors reading your SYSTARTUP_V5.COM, the SYSUAF.LIS
   files that you forgot to delete, and so on.)

   We believe we have achieved this; DECUS uucp should be secure
   even if you don't set up the directory and file protections we
   recommend, or even if you do something silly, like give the uucp
   login a system UIC.

   We want you to trust this system to such an extent that you're
   willing to use it; so in the following sections we will describe
   in detail DECUS uucp's security provisions, and also 'fess up to
   a few problems.


   F.1  Decus Uucp Security Provisions

   SECURITY ISSUES                                          Page F-2
   Decus Uucp Security Provisions


   F.1.1  Directory Access

   In the past we had an explicit goal that UUCP would not transfer
   files into or out of anywhere but UUCP_SPOOL.  UUCP_SPOOL
   therefore served as the repository of all incoming and outgoing
   files.  Now, there is a slightly more precise concept of what the
   uucp spool directory is used for.

   The directory defined by UUCP_SPOOL: is used to hold all outgoing
   jobs from the local system, while a subdirectory within
   UUCP_SPOOL is used for each adjacent site for incoming files.
   The only files that are received into these directories are
   D.xxxx data, and X.yyyy execute files (both associated with mail
   and news transfers).  Temporary files with names of the form
   TM_Upid for inbound files are stored here when in slave mode, and
   in UUCP_SPOOL, when in Master mode.

   Attempts by neighbor systems to transfer files with names other
   than D. or X. to the spool subdirectory (i.e. without an explicit
   directory specification), are rejected with an "access denied"
   status (this is compatible with unix uucp implementations).

   There is now an optional directory tree called UUCP_PUBLIC, which
   is generally accessable for arbitrary incoming and outgoing file
   transfer requests.  We say "optional" since if UUCP_PUBLIC is
   undefined, any request by a neighbor system to transmit a file
   that is not part of a mail message or a news batch will be
   rejected as unauthorized.  (By saying "generally accessable" we
   really mean subject to the local system's standard file
   protection mechanisms; optional detailed control is available
   through the ACL-based security mechanisms described in the
   chapter on the UUCP command.)

   This explictly applies even to the uucp command, even if it's
   installed with SYSPRV; files arriving from other systems will
   always go to the spool or public directory tree (or will be
   rejected), regardless of what the initiating uucp command looked
   like.

   If someone sends us a file spec with a directory delimiter we
   don't recognize, the result will be a bad file spec, not a file
   in some unexpected place.  The worst anybody should be able to do
   is create an odd-looking file in the spool or public directory.

   This prevents uucp from being told to reconfigure itself (perhaps
   by someone sending you a new control file; sure, they can send
   you a file called CONTROL., but it will just sit in the public
   directory and be ignored).  It also prevents uucp from poking
             _____
   around in other directories in the system (outside of the uucp
   hierarchy), which many system managers leave world-readable.

       ____
   The only way to eliminate these restrictions is to modify the
   source and recompile uucico.
   SECURITY ISSUES                                          Page F-3
   Decus Uucp Security Provisions


   Uucico also dynamically grants itself identifiers based on who it
   is talking to, whether they called us or we called them, etc.,
   and these identifiers (if defined in your system) may be used to
   achieve a fine level of control over files in your UUCP_PUBLIC
   directory.  Details are given in the chapter on the uucp command.


   F.1.2  File Protection Masks

   In the chapters on uucp configuration, we stated that all
   executables, command procedures, and configuration files (which,
   for one thing, specify what the spool directory is) should be
   protected against write access by the uucp login and by other
                                  ___
   users on your system.  This is not necessary to prevent a
   neighbor from telling your uucp to reconfigure itself, since that
   is already accomplished by restricting uucico's copy in/copy out
   operations to the spool and public directories.  It does,
   however, prevent other users on your system from reconfiguring
   your uucp system, or perhaps replacing uucico.exe with a version
   that lacks the directory restrictions.


   F.1.3  Priviliges and MAIL.EXE

   Under VMS Version 5, the old MAIL image (which was installed with
   SYSPRV, among others) was split up into several pieces.  One of
   them, MAIL.EXE, is not normally installed with privileges.  But
   it needs SYSPRV in order to access the foreign mail protocol
   handler, so UUCP_SYSTARTUP reinstalls MAIL.EXE with SYSPRV.  (We
   also install MAIL.EXE with SYSLCK and SYSNAM to support other
   features of the uucp mail handler; these are described
   elsewhere.)

   The same thing is necessary for any other package which uses the
   foreign mail protocol "hook".  DEC has stated that, in order to
   use other such packages, installing MAIL.EXE with SYSPRV is
   appropriate and safe, as it only turns privileges on when
   necessary.  (It does not, for instance, have SYSPRV on when you
   SPAWN from the MAIL> prompt.)


   F.1.4  Why is UUXQT.EXE installed with SETPRV ?

   The sharp-eyed system manager will no doubt have noticed that
   UUCP_SYSTARTUP.COM installs the uuxqt.exe image with the SETPRV
   privilege (among others).  This is necessary to enable incoming
   mail to be delivered in a "replyable" format.  For this, our
   "uuxqt" must execute the DCL command MAIL/PROTOCOL, which
   requires the SYSPRV and DETACH privileges (and, under VMS
   Version 5, BYPASS).

   Captive account or no, hardwired directory names or no, we
   obviously don't want to give these privileges to the uucp login,
   or even to the image (uucico) run thereby, so we use the
   following roundabout method to let uuxqt do what it needs to do
   while uucico runs in a nonprivileged environment:
   SECURITY ISSUES                                          Page F-4
   Decus Uucp Security Provisions


         o  Uuxqt.exe is installed with SETPRV.  It is started in a
            batch job by UUCP_SYSTARTUP, typically at system boot
            time.  It spawns a subprocess running the DCL command
            procedure uuxqt_dcl.com, and then turns off SETPRV (and
            all other unneeded privileges).  Now the subprocess has
            SETPRV, but the process running uuxqt.exe does not.

         o  Uuxqt.exe hibernates while waiting for work; the dcl
            subprocess is in a local event flag wait (waiting for a
            read on a mailbox, to which uuxqt.exe will write).

         o  When an X-file is received, uucico awakens uuxqt.exe
            (via a "doorbell" implemented with locks and blocking
            ASTs; this works across nodes on a cluster, whereas
            mailboxes and ordinary hibernate/wake do not).  Upon
            being awakened, uuxqt searches for any X-files in the
            spool directory.  For each X-file, it modifies any
            referenced filenames as described above (forcing the
            directory to UUCP_SPOOL:), and passes the X-file
            contents through the mailbox to the DCL subprocess.

         o  The subprocess uses SETPRV to turn the needed privileges
            on just before executing rmail and rnews commands, and
            turns them off again immediately thereafter.

   To summarize:  The uucp login never runs any images installed
   with setprv, but only runs uucico.  Uucico can only create files
   in the spool directory; uuxqt can only look for files in the
   spool directory; and uuxqt_dcl can only use those files to send
   mail or to bring news into the news database.

   As long as the uucp login cannot change UUXQT.EXE or UUXQT_DCL --
   which is triply ensured; first, the uucp login has only execute
   access to these files; second, the uucp login does not have write
   access to the directory these files live in; and third, the only
   program that the uucp login can run, uucico, can't create files
   anywhere but in the spool directory -- the SETPRV privilege with
   which UUXQT is installed cannot be exploited.

   Note that uucico is installed also.  The primary purpose of this
   is to guarantee that it has PRMMBX, SYSNAM (needed to create its
   permanent mailbox), and SYSLCK (needed to establish the remote
   hostname lock and to trigger uuxqt execution via the blocking AST
   mechanism).  However, this also ensures that the installed
   images, uucico and uuxqt, were linked /NOTRACEBACK (since the
   INSTALL utility will reject attempts to install executable images
                                        ___
   with privileges if those images were not linked with
   /NOTRACEBACK).  The result of all this is that, even if the
   "captive account" mechanism failed and a uucp login "intruder"
   managed to get to a DCL prompt, the intruder could not activate
   either uucico or uuxqt and then use the debugger to exploit the
   privileges with which the image is installed.
   SECURITY ISSUES                                          Page F-5
   Decus Uucp Security Provisions


   F.1.5  Privileges and Uucico

   To prevent problems that might occur if uucico is ever run from a
   privileged account, uucico explicitly turns off all unneeded
   privileges immediately upon startup.  (See the sysinit() routine
   in sysdep.c.  This is called from uucico.c's main() procedure.)
|  
|  Beginning with Version 2.0 of DECUS uucp, uucico is installed
|  with CMKRNL to allow it to dynamically grant identifiers to
|  itself.  These identifiers may be used to implement access
|  controls on the UUCP_PUBLIC directory tree, as described in the
|  chapter on the uucp command.


   F.1.6  "Remote Receive" Requests Disabled

   To send mail or news, the originating system tells the target, "I
   want to send these files".  ("Originating" here refers to the
   immediate source of the mail or news, not to which system placed
   the phone call.  Work, if available, is transferred in both
   directions during all calls.)  Unix uucp also supports "receive"
   requests, as in "I want to receive file xyzzy.plugh".
|  
|  In general, uucico will not honor "I want to receive" requests
|  from other systems, unless you have explicitly enabled this
|  capability.  You enable this by adding the "enbrmtrcv" entry to
|  the control file (see the description of the control file in the
|  chapter, "Configuring UUCP").
|  
                                              ___
|  Prior to Version 2.0 of DECUS uucp, if you did enable remote
|  receive requests, it was just barely possible that a malicious
|  neighbor could inspect the sequence numbers of X- and D-files
|  received legitimately from your system and send you "I want to
|  receive" requests for D-files with "nearby" sequence numbers.
|  Some of these might have been D-files intended for other systems,
|  so they might have been able to read (and prevent proper delivery
|  of) other people's mail.
|  
|  Beginning with Version 2.0 of DECUS uucp, remote systems may only
|  request transfer of files that are located in your UUCP_PUBLIC
|  directory, and hence cannot have access to or influence traffic
|  going to other sites, even if you have enabled remote receive
|  requests.


                    ___
   F.2  Things They Can Do To You

   The preceding measures are sufficient to ensure that a system
   running DECUS uucp is "secure", to the extent that uucp cannot be
   used to either read or write files outside of the spool or public
   directories.  This section describes a few things that a neighbor
   (or, more likely, someone -- referred to here as an "intruder" --
   who learns the access information for your system used by one of
                   ___
   your neighbors) can do to you despite all of the above.
   SECURITY ISSUES                                          Page F-6
   Things They Can Do To You


   The risk of username/password compromise can be reduced somewhat
   by enabling callbacks.  This does not protect against the
   "wiretap" intruder; if they got the username and password off the
   phone line they can intercept the callback too.  But it does help
   protect against the (presumably far more likely) case where the
   neighbor system manager just makes a mistake and leaves your
   access information where someone else can find it.
|  
|  
|  F.2.1  Creation of Files in the Spool and Public Directories
|  
|  Neighbor systems can only create files in your public and spool
|  directories.  Files sent to your spool directories can only be D.
|  and X. files (the files used to send you mail and news).
|  
|  If you have defined a public directory tree, a neighbor with
|  write access to it might send you a "trojan horse" command
|  procedure.  If any command procedures, source files, or other
|  "strange" files ever appear somewhere in your public directory
            ___
|  tree, do not execute them or make them available to anyone else
|  on your system without careful inspection.
|  
|  If odd D. or X. files appear in a per-site subdirectory of the
|  spool directory, or if any odd files appear in the public
|  directory tree (if you have one), you can inspect UUCP.LOG to see
|  when these files arrived (a DCL SEARCH command with the file name
|  as the search target is all that's needed).  The log entries will
|  show you which site sent the files.  (Additionally, for files in
|  the spool area, you'll know which neighbor sent them by the
|  subdirectory you find them in.)
|  
|  If appropriate, you can ask their system manager what's going on.
                   _____
|  Have them check their log entries to see if they recorded a call
|  to your system at the time indicated in your log.

   Neighbor systems can only create files in the spool directory,
   but they are not restricted to creating D- and X-files (the files
   used to send you mail and news).  The file name can be anything
   desired as long as it's a valid VMS file name.  For example, an
   intruder trying to probe your security might try to send you a
   new CONTROL. file.  Or they might send you a "trojan horse"
   command procedure.

   If any command procedures, source files, or other "strange" files
   (anything, really, other than the regular uucp work files, B.*,
                                                              ___
   C.*, D.*, and X.*) ever appear in your spool directory, do not
   execute them or make them available to anyone else on your
   system.  Inspect UUCP.LOG to see which neighbor system
   purportedly sent them to you (a DCL SEARCH command with the file
   name as the search target is all that's needed), and ask their
                                                    _____
   system manager what's going on.  Have them check their log
   entries to see if they recorded a call to your system at the time
   indicated in your log.
   SECURITY ISSUES                                          Page F-7
   Things They Can Do To You


                                 NOTE

           The appearance of such files is more likely to be
           evidence that your access information has been
           compromised than that your neighbor system
           manager is trying to do nasty things.  Given that
                                           ___
           assumption, it would be wise to not use uucp mail
           for this inquiry.


   Another possibility is that an intruder might simply try to fill
   up the disk on which your spool directory resides.  This is
   unlikely given modern disk capacities and the transfer speeds
   available over dial-up lines (even with Telebit modems), but if
   the prospect bothers you, you can always set an appropriate disk
   quota for the uucp login.


   F.2.2  Non-Direct Mail is not Private

   Remember that mail which does not go directly to the target site
   (with no intervening hops) is passing, in clear, through other
   systems, and that it may stay in those systems' spool directories
   for periods ranging from a few minutes to a few days.  System
   managers and other privileged users can read files in the spool
   directories.  Therefore, consider all mail sent to or from other
   than neighbor sites to be sent via a broadcast medium.


   F.2.3  Spoofing of Mail Origins

   An intruder, by masquerading as your neighbor, might intercept
   outgoing mail which you intended to route through your neighbor,
   or might generate bogus mail to users at your site (making it
   appear as though it came from literally anyone on the net).  Of
   course, with non-direct mail paths, this could happen anywhere on
   the net.

   (This problem is not specific to uucp mail; in fact, anybody on
   your system can generate mail with bogus From: lines by, for
   example, sending Mail-11 commands to the Mail DECnet object.)


   F.3  Contrast With Unix Uucp

   Unix uucp uses a "userfile", which controls which directories and
   files local users and remote systems can access, and a "commands
   file", which specifies which commands can be executed locally by
   remote sites.  DECUS uucp does not have (and does not need)
   either of these, since it does not support arbitrary remote
   command execution and forces all remote file access to the spool
   or public directories.

   A subtle opening in Unix uucp/netnews security has to do with the
   map propagation scheme, as the maps are sent out in "shar" (shell
   archive) format.  Many sites have an automatic procedure which
   SECURITY ISSUES                                          Page F-8
   Contrast With Unix Uucp


   extracts the new map entries from the newsgroup and executes them
   directly as "shell" (command language interpreter) scripts
   (command procedures).  Obviously, a bogus map posting might
   contain shell commands intended to exploit whatever privileges
   are in effect when this is done.

   In DECUS uucp, the map entries are interpreted by special-purpose
   code; the worst that can happen in such a case is that the
   MAKEPATHS command procedure might generate invalid paths, or stop
   with an error message.


   F.4  The Internet Worm

   No discussion of computer security these days is complete without
   some reference to the infamous "Internet Worm" of November, 1988.
   We have analyzed the description of the worm (see "A Tour of the
   Worm" by Donn Seeley, reprinted in the Unix Systems SIG
                                   _____ ____ _______ ____
   Newsletter that appeared in the DECUS U.S. Chapter SIGs
   __________
   Newsletter for March, 1989, Vol. 4, No. 7, pages Uni-2 through
   Uni-20).  None of the three security holes exploited by the worm
   are applicable to this uucp implementation, or to any other uucp
   for that matter.


   F.5  Uucp Security History

   Despite Unix uucp's requirement for an "active" security effort
   on the part of the system manager, the uucp network has been
   remarkably free of security problems.  A small number of
   "aliased" mail and news messages have been posted; these have
   usually resulted in a public outcry on News and isolation
   (quarantine?) of the originating systems.  Once the steps
   recommended in the Unix documentation are taken, Unix uucp is
   secure enough that many system managers publish their system's
   phone number and a username and password to be used for
   "anonymous uucp logins".  (The usual purpose of this is to set up
   a "file library" from which large software packages may be
   distributed.  Since the person who wants the software places the
   phone call direct to the "library", the library incurs no
   expenses for the transfer.)

   Because of the default security mechanisms built into DECUS uucp,
   we are confident that DECUS uucp, with no special action on the
   part of the system manager, is considerably more secure than Unix
   uucp -- even when all of Unix uucp's security features have been
   properly set up.

   appendix Upgrading from Previous Versions

   If you are already running a previous version of DECUS uucp (and,
   possibly, NEWS), installing this version will be fairly simple.
   SECURITY ISSUES                                          Page F-9
   Brief Summary of Configuration Differences


   F.6  Brief Summary of Configuration Differences

   F.6.1  The Systems File

   The systems file has some new options, but otherwise is
   unchanged.  These are described in the chapter, "Configuring
   UUCP".


   F.6.2  UUCP_ and NEWS_SYSTARTUP.COM

   Specification of logical names and other site-specific
   information is no longer done by editing UUCP_SYSTARTUP.COM and
   NEWS_SYSTARTUP.COM, but via the uucp control file.
   NEWS_SYSTARTUP.COM really does not exist any more (it is supplied
   only as a placeholder).  UUCP_SYSTARTUP.COM should be usable by
   almost all sites with no modification.


   F.6.3  The Control File

   The template control file in [.EXAMPLES.CFG]CONTROL. shows most
   of the possible logical names, with descriptions of each.  This
   file is described in detail in the chapter on Configuring DECUS
   uucp.

   However, to make upgrades easier, a GENERATE_CONTROL command
   procedure is provided with this release; this will produce a
   2.0-compatible control file from your existing configuration.
   The control file built by GENERATE_CONTROL.COM specifies only
   those names which differ from the default values (documented in
   the comments in the file).

   You should also use GENERATE_CONTROL whenever you subsequently
   edit your Version 2.0 control file.  The procedure is as follows:

        1.  Edit your existing file to reflect the desired change.

        2.  Invoke UUCP_SYSTARTUP.COM with P1=LOGICALS and, if
            NEWS-related logicals are being changed, P2=INCLUDE_NEWS

        3.  Invoke GENERATE_CONTROL.COM to produce a new
            "normalized" file, complete with comments describing
            each logical name.  This file will only specify those
            logicals which differ from the default values.


   F.6.4  Arrangement and Placement of NEWS_MANAGER directory tree

   ;Previous versions allowed some leeway in the arrangement of the
   NEWS_MANAGER and NEWS_MANAGER_DEV directories.  This version
   requires that:

         o  NEWS_MANAGER (the home of the news configuration files
            such as NEWS.SYS) is the same directory as is specified
            by NEWS_MANAGER_DEV:[000000] .
   SECURITY ISSUES                                         Page F-10
   Brief Summary of Configuration Differences


         o  The login default device for the "news manager" user
            (the username under which the news batch jobs run) is
            NEWS_MANAGER_DEV, and the login default directory for
            this user is [000000] .

         o  If the NEWS_ROOT directory (home of NEWS.ITEMS,
            NEWS.GROUPS, HISTORY.V60, and NEWS.HLB) is on a
            different disk than NEWS_DEVICE (root of the directory
            tree corresponding to the newsgroup namespace, in which
            are stored the news item files, *.ITM), the NEWS_MANAGER
            tree is required to be on the same disk as NEWS_DEVICE.

   The upgrade procedure will attempt to make the necessary
   corrections if it finds a different arrangement.  If you have a
   significantly different arrangement, these attempts may fail; you
   may find it easier to change your existing configuration to match
   the requirements just described.


   F.7  Upgrade Procedure


        1.  Ensure that your existing uucp and NEWS systems are up
            and running.

        2.  Restore the "runtime" saveset from the distribution into
            your "live" uucp directory tree, using the /NEW_VERSION
            qualifier to ensure that the files from the distribution
            become the highest-numbered versions.  This saveset
            includes the following directories:

            [UUCP.BIN]
            [UUCP.CFG]
            [UUCP.EXAMPLES...]
            [UUCP.NEWS]    (new NEWS.HLB only)
            [UUCP.NEWS_MGR...]

            Note, the [UUCP.CFG] directory in the saveset is empty.
            All files that used to be provided here now appear in
            [UUCP.EXAMPLES.CFG] .  Thus, restoring this saveset with
            the NEW_VERSION qualifier will not override any modified
            dial scripts, etc., which you may have.

            The new versions of UUCP_SYSTARTUP.COM and
                                  ___
            NEWS_SYSTARTUP.COM do not need to be customized for your
            site; all customization is handled by the
            [UUCP.CFG]CONTROL. file.  Therefore, do not worry about
            the fact that the new versions of these files will
            supplant your own -- they're intended to!

            In the next step, a new CONTROL. file will be
            automatically generated to reflect your existing
            configuration.
   SECURITY ISSUES                                         Page F-11
   Upgrade Procedure


        3.  With the existing UUCP up and running, from the SYSTEM
            (or other suitably privileged) account:

            $ @UUCP_BIN:UUCP_CONFIG 1 "" 4 "" 6
            $ @UUCP_BIN:GENERATE_CONTROL

            UUCP_CONFIG and GENERATE_CONTROL will ask several
            questions; answer "Y" to each.

        4.  Remove the P3 and P4 arguments from the call to
            UUCP_SYSTARTUP.COM in your
            SYS$MANAGER:SYSTARTUP_V5.COM .  (INCLUDE_NEWS works just
            as before, as the p2 parameter for UUCP_SYSTARTUP .)

   The upgrade is now finished, and you are running with V2.0 of
   DECUS uucp, and NEWS 6.1 Alpha-4.












                              APPENDIX G

                  CHANGES IN VERSION 2.0 (FROM 1.3X)



   This Appendix provides a brief description of the new features of
   version 2.0 of DECUS uucp, relative to Version 1.3x.  Appendices
   describe changes in earlier versions.

   Tom Allebrandi (Mailer) and Mark Pizzolato (nearly everything
   else) are responsible for most of the changes here.  (I added the
   support for extended windows and packet sizes, and did most of
   the updates to the manual -- JEH.)


   G.1  Configuration

   G.1.1  Expanded Role of the control File

   All logical names formerly configured by editing
   UUCP_SYSTARTUP.COM and NEWS_SYSTARTUP.COM, are now specified in
   the uucp CONTROL. file.  There should be no need for most sites
   to edit the command procedures.


   G.1.2  Automatic Control File Generation

   The new command procedure [.BIN]GENERATE_CONTROL.COM will
   generate a control file (including logical name definitions)
   based on the existing control file plus existing logical name
   definitions.


   G.1.3  Automatic NEWS_MANAGER Reconfiguration

   Previous versions of the news integration command procedures
   distributed with DECUS uucp were fairly forgiving about the
   arrangement of the NEWS_MANAGER directory, the NEWS_MANAGER_DEV
   rooted logical, and the default directory for the "news
   manager"'s account.  These have been "rationalized" in this
   version.  The command procedure UUCP_CONFIG will automatically
   correct an existing directory structure, if necessary.
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-2
   UUCICO


   G.2  UUCICO

   G.2.1  Extended Window and Packet Sizes

   ..are now supported.  See the documentation on the options field
   in the systems file.


   G.2.2  Debug levels for incoming calls

   If the logical UUCP_UUCICO_DIALIN_DEBUG is defined, its
   translation is prefixed by "-x" and UUCICO is invoked with this
   option (debug level) for all incoming calls.

   If the logical UUCP_UUCICO_DIALIN_DEBUG_username is defined, its
   translation is similarly prefixed by "-x" and UUCICO is invoked
   with this option (debug level) for incoming calls from the
   indicated username.


   G.2.3  Local hostname Aliasing

   It is now possible to present a different hostname to a
   particular neighbor when either initiating or answering a call
   with them.  Among other things, this can be used for local
   testing (looping from one port to another).


   G.2.4  Filename Aliasing

   Some uucp sites use hostnames which cause problems on VMS
   systems, because their hostname is used to construct file names
   on the local system.  An example might be a site with a uucp
   hostname of "a.b".  The systems file entry for such a site can
             _________
   specify a filealias which is used in place of the neighbor's
   hostname in locally-constructed file names.

   The name of the spool subdirectory for a particular neighbor may
   be aliased.

   The control file can specify a filename alias for the local uucp
   host.  This would permit a DECUS uucp site to have a hostname of,
   for example, "a.b".  It should also be used where the local
   hostname is more than seven characters long and one or more
   neighbors do not allow filenames longer than 14 characters total
   (such as Unix System V).  In either case, the alias is used in
   place of the local hostname to construct filename extensions.


   G.2.5  Transfer Grade Restrictions

   The systems file now supports "grade" letters.
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-3
   UUCICO


   G.2.6  Multiple UUCICO Callout Daemons

   ..are now supported.


   G.2.7  Work Scans

   Spool directories are now searched "one more time" before
   concluding that there is no more work.  One result of this is
   that mail that is "bounced" off of a neighbor DECUS uucp site
   will generally be returned in the same call (assuming that the
   neighbor is also running the new code).


   G.2.8  Data Path Tests

   By far the most frequent problem that sites have when either
   first coming on line with DECUS uucp, or when changing or adding
   new modems, is that they don't get the line/modem configured
   correctly to pass all possible 8 bit values.  UUCICO has been
   extended to explicitly perform a test of the datapath.  This test
   is requested by calling UUCICO_CALLOUT.COM with P1 as the site to
   test against and P2 as either "-d" or "-Dtestargs".  The first
   case "-d" causes a default test which should be sufficient to
   verify the path for most users, while the "-Dtestargs" allows
   control of the test control variables see the code for explicit
   details of the parameter meanings.  (The calling system gets to
   select the the mode of testing since it is his phone bill.) The
   default test first passes all possible byte values back and
   forth, then the intervening buffering and flow control mechanisms
   are stressed a bit by passing gradually increasing buffers
   containing a range of possible values.  This buffer test defaults
   to starting at 70 bytes, stepping up by 70 bytes until buffers of
   210 bytes are being exchanged.  The range of values exchanged in
   the original byte by byte test and the range of values and the
   buffer sizes in the buffer testing can be varied as options in
   the "-Dtestargs" form of the test.


   G.2.9  Disk Space Management

   Spool Disk capacity is verified whenever a request to send a file
   into the system is attempted.  If insufficient space is
   available, the transfer is rejected with a SN4 message.  This is
   how both BSD and HDB implementations handle this situation.  We
   are fully prepared to continue after we send such a message (and
   when we receive one).  When HDB sites receive a SN4 message they
   immediately hangup the line without another peep.  BSD 4.3
   systems nicely continue and offer to switch roles to allow our
   side to drain some outbound stuff and possibly make room for the
   file they originally wanted to send.  The potential problem that
   is part of the BSD approach is that if they are unable to create
   enough space after switching roles, and we eventually switch
   roles back we will once again be stuck with no space,...  the
   potential for an infinite loop exists here.  This is solved in
   DECUS uucp by remembering that the above scenario has transpired;
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-4
   UUCICO


   we will offer to switch roles at most one time after this event.
   (Mark Pizzolato had an E-mail discussion with Peter Honeyman
   about why his stuff so abusively hangs up and he agreed that
   Mark's idea of only switching roles one more time is a good one
   and would consider implementing it.)


   G.2.10  Debug Log Performance

   It is often the case that enabling high levels of debug log
   output introduces delays which mask the problem that one was
   attempting to troubleshoot.  A new debug control bit (see the
   example systems file) causes debug information to be buffered in
   a ring buffer in memory and only written out in the event of a
   failure of the g protocol.


   G.2.11  Debug Log Formatting

   "All characters sent or received in packet mode" are now
   formatted nicely.  (This enhancement is due to Earle Ake,
   ake@dayton.saic.com)


   G.2.12  File and Directory Access

   Previous versions would only transfer files into or out of the
   uucp spool directory.  In version 2.0, the following changes are
   made:

         o  Incoming mail and news files (D. and X. files) arrive in
            subdirectories of the spool directory corresponding to
            the uucp neighbor name (ie [.SPOOL.CMKRNL] for neighbor
            site cmkrnl).  These subdirectories are automatically
            created as needed.

         o  Outgoing mail and news, and outgoing file transfers
            requested by local use of the "uucp" command ("push
            mode"), are "buffered" through temporary files in the
            spool directory (UUCP_SPOOL).

            A new logical, UUCP_PUBLIC, may point to the top of a
            directory tree (normally [UUCP.PUBLIC]) that (if
            defined) is used as follows:

         o  Incoming file transfers requested by local use of the
            "uucp" command ("pull mode") cause the files to arrive
            in the specified location in the UUCP_PUBLIC tree.  The
            UUCP_PUBLIC tree, and the logical, must exist for this
            to work.  (Subdirectories of UUCP_PUBLIC will be created
            on demand, as requested by the "uucp" command, but the
            root of the UUCP_PUBLIC tree must already exist.)

         o  Neighbor systems may transfer files into or out of the
            UUCP_PUBLIC tree, provided that the logical and the root
            of the tree already exist.
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-5
   UUCICO


   File transfers into and out of the UUCP_PUBLIC directory (which
   is to say, everything except mail, news, and locally-originated
   requests to send files) are subject to additional levels of
   control via identifiers and ACLs.  See the chapter on "UUCP File
   Transfers" for details.


   G.2.13  Detailed Description of Changes to UUCP Source Files

   This may be found in the file [UUCP.DEVEL.UUCP.SRC]0CHANGES.20 .


   G.3  UUXQT

   G.3.1  Multiple recipients for inbound mail

   ..are now supported.


   G.3.2  Debugging

   - the verbose mode of UUXQT_DCL is now controlled by the logical
   UUCP_UUXQT_VERBOSE which is read at the beginning of each job
   being processed.  Note, this just enables the BABBLE messages NOT
   a full verify.  A full DCL VERIFY can be enabled by setting the
   logical UUCP_UUXQT_VERIFY which is also now read at the beginning
   of each job.


   G.4  Mail Integration

   G.4.1  UUCP Mail Handler (UUCP_MAILSHR) Bug Fixes

   G.4.1.1  Extra Bangs (!) in From_ Headers

   In the 1.3[A] mailer, messages passing through the Mail Handler
   would receive an extra "!" in the UUCP From_ header when the
   target destination was the MX (Message Exchange) Mail Router.
   This has been corrected.


   G.4.1.2  Long Line Wrapping

   VAX Mail imposes an input line length restriction of 255
   characters.  The Mail Handler was not observing this restriction
   causing it to abort when presented with an inbound message whose
   lines were longer than 255 characters.

   Inbound messages with lines longer than 255 characters will now
   be wrapped at the nearest space or tab preceeding the 255
   character point.  If no break point can be found, the line will
   be wrapped at 255 characters.

   Note that this method may accidentally invalidate excessively
   long RFC-822 format headers.  (RFC-822 allows wrapping at
   syntactic whitespace, not convenient whitespace as is currently
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-6
   Mail Integration


   implemented.) No one should ever be emitting headers that contain
   255-character lines so the possibility of this problem is
   considered low.


   G.4.1.3  Miscellaneous Bug Fixes

   A bug was discovered in the routine that cracks the address
   string that VAX Mail supplies for local mail into the address and
   personal name.  This has been corrected.

   One of the error handling routines was arbitrarily converting all
   passed status codes to fatal severity -- this included success
   codes and resulted and in the (infamous) %x10000004
   (NOMSG-F-NORMAL) status code being returned to DCL.

   If the protocol between VMS Mail and the UUCP Mail Handler
   encountered a problem during initialization, the real error was
   lost and a status indicating a problem with the command line was
   returned.  Now, the correct error is signalled.

   Inbound message files with a maximum record size attribute that
   was not zero or 65535 would cause the inbound delivery code to
   abort.


   G.4.2  Mail Handler New Features

   G.4.2.1  Random Access Violation in Mail Handler Solved

   Since the first distribution of DECUS UUCP (nee VMSnet Software),
   some users have been plagued by a randomly occuring access
   violation while sending mail.  We believe that we have found the
   cause of this problem.

   The problem appears to be in the Pascal Runtime Library as
   distributed by Digital.  The problem itself is not a problem with
   the UUCP Mail Handler; however, the likelyhood of the problem
   occuring is much higher than with other applications.  (By
   default, the UUCP Mail Handler uses fairly large buffers which
   can be a contributor to the conditions under which the bug in the
   Pascal RTL occurs.)

   See the file UUCP_BIN:ACCVIO.PATCH for more information about
   this problem.


   G.4.2.2  Quoted strings in outbound from addresses now preserved
            for rewriting

   For locally generated messages, including those that arrive over
   DECnet, if the sender address is in the form

           mumble::"something"
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-7
   Mail Integration


   the address is not cracked into a username and personal name.
   Instead, the entire sender address is now placed into the
   username field making it available for processing via the
   [OUTBOUND-FROM] rewrite rules.

   (The DEC Message Router (MRGATE) has been observed to generate
   addresses in this format.)


   G.4.2.3  Filename Aliasing

   Remote and local filename aliasing via the
                      _
   UUCP_SITE_FILEALIAShostname and UUCP_HOST_FILEALIAS is
   implemented.  This change was made to stay in synch with NEWS and
   the UUCP commands.


   G.4.2.4  UUCP_SPOOL Subdirectories

   The requirement that inbound message files come from the UUCP
   Spooling directory (UUCP_SPOOL:) has been relaxed.  Now, inbound
   message files may come from the UUCP Spooling directory, or any
   subdirectory thereof.  Also, from the point of view of the Mail
   Handler, UUCP_SPOOL may be a search list logical name.  It may
   not be a rooted device name.

   Please note that the definition of UUCP_SPOOL must come from the
   System logical name table at Executive mode.


   G.4.2.5  New Spool File Name Formats

   The filenaming unique-ifiers are now 3 character alphanumerics
   instead of the old 4 digit numbers.  This change increases the
   number of possible sequence numbers in order to increase the
   amount of time before they roll over.

   A minor change was made in the spool file names to match the rest
   of the package.  The Mail Handler was creating B, D, and X files
   names that included the service grade.  This is not required;
   other DECUS UUCP utilities such as News as UUCP were not creating
   their names this way.


   G.4.2.6  New uucico Daemon Wakeup Mechanism

   The UUCP Mail Handler now uses a system-wide lock in the
   "doorbell" mode to alert the uucico transport daemon to the
   presence of waiting mail.  This method works much faster in a
   VMScluster than the old "DECnet write to the mailbox" mechanism.

   Note that this change requires that VMS Mail and DECwindows Mail
   be installed with the SYSLCK privilege.
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-8
   Mail Integration


   G.4.2.7  Expanded Image Dump Information

   The information produced by a UUCP_MAILSHR_CRASH_DUMP has been
   expanded for this release.  Further, if requested, the crash dump
   module will produce a process image dump.

   The UUCP Mail Handler developer may ask you to enable these
   features if you are having a peculiar problem.


   G.4.2.8  Version Numbers in Mail Headers

   The UUCICO transport utility and the UUXQT execution utility have
   been modified to make their version numbers easier to find.  The
   UUCP Mail Handler now attempts to locate these version numbers in
   order to display them in the "Received:" header for the local
   host.  The comment are in the header, which in the past has said
   something like

           (DECUS UUCP ///1.3-1/2.5/)

   will now say something like

           (DECUS UUCP /2.0/2.0/2.0/)

   The first number is the version number for UUCICO, the second is
   for UUXQT and the third is for the Mail Handler.

   These changes were made for the convenience of the developers.
   Now, when you send mail to one of the developers, the outgoing
   mail message contains the version numbers of the major
   components.


   G.4.2.9  Additional privileges needed

   The UUCP Mail Handler has always required that the base program
   image be installed with the privilege SYSPRV.  Common examples
   include VMS Mail (SYS$SYSTEM:MAIL.EXE), DECwindows Mail
   (SYS$SYSTEM:DECW$MAIL.EXE) and user written programs that will
   send UUCP Mail via the Callable Mail programming interface.

   For this release, the Mail Handler needs the SYSLCK and SYSNAM
   privileges to implement two of its features.  However, it will
   continue to operate if these privileges are not available.

   SYSLCK is needed in order to use the "doorbell" mechanism to wake
   up the uucico transport daemon.  The Mail Handler wakes the
   daemon whenever outgoing mail is created.  The doorbell mechanism
   is implemented using VMScluster wide resource locks hence the
   need for the SYSLCK privilege.  This is far more efficient than
   the previous method of sending a record via DECnet to the
   daemon's mailbox.
   CHANGES IN VERSION 2.0 (FROM 1.3X)                       Page G-9
   Mail Integration


   SYSNAM is needed to create system-wide logical names.  A new
   feature of this release is that the version id's for the UUCICO
   transport utility and the UUXQT execution utility are now
   included in the "Received:" header for the local host.  These
   version id's are found by searching the appropriate executable
   image file.  Once the id's have been located, the Mail Handler
   "remembers" where it found them by storing some information in a
   logical name in the system logical name table.  The next time the
   Mail Handler is run, it uses the stored information to reduce the
   time it takes to generate the information for the header.
   Creating a system table logical name requires the SYSNAM
   privilege.

   The question naturally arises, does installing MAIL.EXE with
   these enhanced privileges open any security "holes"?

   To the best of our knowledge, no, it does not.  Very eary in
   MAIL.EXE, and reportedly in DECW$MAIL.EXE, Digital disables all
   priv's that user does not normally have.  In other words, those
   inherited from the installation of the image.  Exceptions to this
   are TMPMBX, NETMBX and EXQUOTA which are left in place if they
   are on when mail is started.

   This means that subprocesses created directly from the Mail SPAWN
   command or indirectly to start an editor for a message will not
   inherit SYSNAM or SYSLCK from the parent process.

   Executable code, such as a foreign transport or a callable
   editor, which are called as subroutines by MAIL could enable the
   installed privileges.  Remember however that since MAIL is
   installed with priv's, any images it activates must also be
   installed.

   In all cases in the UUCP Mail Handler, we explicitly enable a
   privilege right before we need it and disable it as soon as we no
   longer need it.

   And, the system table logical names that are created by the UUCP
   Mail Handler are created at user mode.  We would need CMEXEC priv
   to create them at executive mode.


   G.5  NEWS Integration

   G.5.1  NEWS Version

   The NEWS software supplied with this release of DECUS uucp is
   Version 6.1A4.  NEWS is of course maintained by Geoff Huston.


   G.5.2  Directory Structure

   Previous versions assumed that NEWS_MANAGER and NEWS_MANAGER_DEV
   were on UUCP_DISK, and allowed provision (via P2 & P3) to put
   NEWS_ROOT and NEWS_DEVICE elsewhere.  Specific assumptions that
   are most reasonable for any site that actually feeds downstream
   CHANGES IN VERSION 2.0 (FROM 1.3X)                      Page G-10
   NEWS Integration


   sites, makes it more reasonable for NEWS_MANAGER and
   NEWS_MANAGER_DEV to be on the same device as NEWS_DEVICE.  The
   UUCP_CONFIG procedure will automatically correct things if
   necessary.


   G.5.3  Disk Space Management

   Outflow processing of batches to down stream sites, is regulated
   by available disk space on the UUCP_SPOOL device.  If space is
   unavailable, flushing of these batches is deferred to hopefully
   allow the spool space to be drained by adjacent sites.

   Processing of newly arrived MAPS is also regulated by a disk
   capacity check.  If insufficient space is available, mail to
   UUCP_POSTMASTER indicates this problem, and we hopefully will be
   able to do this successfully tomorrow.


   G.5.4  Forwarding Priority

   Forwarding of news batches to down stream sites can now be
   processed in an order different than the lexical scan order of
   the site names.  This is achieved by naming the directories that
   contain the outbound news batches with names of the following
   form:

   NEWS_MANAGER:POST_<transmission_mode_><node>.DIR

   The transmission mode may optionally be prepended with a "scan
   priority", which is specified as:  prio-transmission.  (Note the
   "-" being lexically significant).  The ONLY purpose of this
   priority is to reorder which POST directories get flushed first.
   For example, if you feed two sites:  AAAA and ZZZZ, and it is
   more important that outbound traffic for size ZZZZ gets sent
   before that for AAAA, then using the priority mechanism is
   appropriate.


   G.6  Utilities

   G.6.1  UUrate (nightly uucp activity reports)

   This program has been enhanced to provide additional information.


   G.6.2  Uuname

   This new utility provides information about the local node's uucp
   neighbors.
   CHANGES IN VERSION 2.0 (FROM 1.3X)                      Page G-11
   Utilities


   G.6.3  Uustat

   This new utility provides information about queued uucp jobs and
   allows them to be cancelled or resubmitted.


   G.6.4  FEEDCHECK (new nightly report)

   This program is optionally run during the nightly NEWSSKIM.  The
   function performed is to process the NEWSSKIM and RNEWS logs from
   the prior day and to generate a report on the activities noticed
   from the site's feed, and also a summary of how much feeding has
   been done.












                              APPENDIX H

                  CHANGES IN VERSION 1.3X (FROM 1.2X)



   This appendix provides a brief description of the new features of
   version 1.3x of DECUS uucp, relative to Version 1.2x.  Subsequent
   appendices describe changes in earlier versions.


   H.1  NEWS

   This DECUS uucp distribution includes ANU NEWS Version
   6.1-ALPHA4, plus various fixes that have appeared on the net.


   H.2  Changes in Configuration Files

                                                              __
   We are happy to report that most sites should need to make no
   changes in their uucp configuration files to use DECUS uucp 1.3A.
   (The only exception will be sites that are still running V0.2; in
   that case you should read the chapter on configuration files very
   carefully.)

   There is one change required by the current version of News,
   relative to News V5.7:  If you've used nested quoting in your
   NEWS_ADDRESS.CNF file, you'll have to change it, and strip off
   the outer layer of quotes.  For example, in the DECUS uucp world,
   we used to say

   *@*     "UUCP%""001@002"""

   but now we say

   *@*     UUCP%"001@002"

   This change was actually required by NEWS 5.8, and all subsequent
   versions.

   NEWS 6.1-x can use either a separate file, NEWS.SYSD, or special
   fields in the NEWS.SYS file, to specify "distribution" filters.
   This means that newsgroup hierarchies (such as "ba...") will no
   longer be confused with similar distribution names.  Existing
   NEWS sites who are upgrading to NEWS 6.1-x should read the
   comments in the example NEWS.SYS and NEWS.SYSD files, and modify
   their own files accordingly.
   CHANGES IN VERSION 1.3X (FROM 1.2X)                      Page H-2
   Uucico.exe


   H.3  Uucico.exe

   A "memory leak" (failure to deallocate dynamically allocated
   memory) has been found and corrected.  (This fix due to Mark
   Pizzolato)


   H.4  UUCP_CONFIG.COM

   Mark Pizzolato has updated this procedure to be compatible with
   VMS Version5.4 as well as all previous versions.  Also, the
   procedure now checks for the existence of [.SPOOL], [.LOG], and
   other directories that are shipped "empty", and creates them if
   they're missing.  (BACKUP procedures used for some distributions
   of DECUS uucp would not create empty directories.)


   H.5  The Mailer

   Most of the changes in DECUS uucp V1.3A have to do with the mail
   interface and related software.


   H.5.1  Makepaths and PathProc

   The Makepaths procedure and the PathProc utility program have not
   changed for this release.  (That is, they have not changed from
   version 1.2.)


   H.5.2  Pathalias

   Pathalias, the utility used to determine mail delivery routes
   from the UUCP map files, has changed for this release.  The new
   version contains the latest source code from Peter Honeyman, the
   Pathalias developer.

   This new version should be immune to the problem that occasionaly
   sent the previous release into an infinite memory grabbing loop.


   H.5.3  UUCP_MAILSHR

   H.5.3.1  To:  Headers

   H.5.3.1.1  To:  Headers for Multiple Addressees -

   A side effect of a bug fix required some rework on the generation
   of the To:  header.  A result of the change is that for outbound
   mail, UUCP_MAILSHR will attempt to create an RFC 822 To:  header
   containing a list of addresses.  Previously, when a single
   message was sent to multiple people, the To:  header in each copy
   contained just the address of the person receiving it.
   CHANGES IN VERSION 1.3X (FROM 1.2X)                      Page H-3
   The Mailer


   When sending mail to more than one recipient, VAX Mail at its
   discretion may choose to invoke UUCP_MAILSHR once passing all of
   the target addresses, or many times passing a few addresses each
   time.  The list form of the To:  header is created from only
   those addresses which are passed in a particular invocation.
   Note that local addresses are never passed to UUCP_MAILSHR.


   H.5.3.1.2  Continuation Lines in To:  Headers -

   The handling of the To:  header for inbound mail delivery has
   been changed.  Previously, UUCP_MAILSHR would pass to VAX Mail
   just the first line of the header, ignoring any continuation
   lines.  Now, if the To:  header is continued, as much of the
   header as can be passed to VAX Mail will be.

   Note that this processing has nothing to with the delivery
   address in the mail envelope.  The contents of the To:  header
   are passed to VAX Mail so that it can construct the text for its
   To:  field which is used for displaying the message.


   H.5.3.2  From:  and From_ Headers

   H.5.3.2.1  Generating VMSmail From:  Lines from UUCP From_ Lines
   If a received message contained a UUCP From_ but not an RFC 822
   From:, the UUCP From_ was ignored.  This meant that for local
   delivery, the VMS From:  address was "(cannot determine sender)"
   even though a valid address was in the message.  This has been
   fixed.


   H.5.3.2.2  Not Generating From:  Headers -

   Version 1.2 introduced a feature which added missing headers to
   messages which were passing through the local system from one
   host to another.  Among other problems, this feature would
   generate an RFC 822 From:  header regardless of whether or not a
   UUCP From_ header was present.  The generated From:  contained an
   address indicating that the message came from uucp_daemon on the
   local host.

   The net effect was that downstream mailers might have ignored the
   correct return address in the From_ header, instead using the
   false one in the From:  header.

   For this release, the mail handler no longer supplies missing
   headers on pass through mail.


   H.5.3.3  Other Headers

   CHANGES IN VERSION 1.3X (FROM 1.2X)                      Page H-4
   The Mailer


   H.5.3.3.1  X-VMS-To -

   The generation of the X-VMS-To:  header has been intermittent in
   the past.  Sometimes VAX Mail would pass the information and
   sometimes it wouldn't.  The reason for this has been found and
   the problem has been fixed.


   H.5.3.4  Crash Dump Facility

   A "crash dump" facility has been added to UUCP_MAILSHR.  This
   facility is normally dormant, it must be enabled before it takes
   effect.

   When the "crash dump" facility is enabled, the signalling of any
   unexpected conditions will cause a crash dump file to be written.
   Expected conditions are those whose messages begin with a
   Facility ID of "%UUCP".  Anything else, such as an access
   violation or a runtime library error, are considered unexpected
   and will cause a crash dump file to be written -- if crash
   dumping is enabled.

   To enable the crash dump facility:

           DEFINE UUCP_MAILSHR_CRASH_DUMP anything

   When a crash occurs, the file SYS$SCRATCH:UUCP_MAILSHR.CRASH_DUMP
   will be created.  This file should be included in any problem
   reports.

   Note that the condition "%UUCP-F-NORECIP, Required recipient
   parameter on command line missing" if often wrong and actually
   indicates a condition that would generate a crash dump.


   H.5.3.5  File Handling

   H.5.3.5.1  Always Closing PATHS -

   The Paths.  file was not explicitly closed at the end of an
   outgoing mail session.  This never really caused a problem since
   the exit from MAIL itself caused the file to be closed.

   However, people who use the DECwindows mail utility usually put
   it in the icon state and only exit every few days.  This could
   cause out of date versions of the Paths.  file to be used.

   UUCP_MAILSHR now closes the Paths.  file explicitly during the
   termination of a session with VAX Mail.


   H.5.3.5.2  Required Origin for Inbound Mail Files -

   During inbound mail delivery, UUCP_MAILSHR now requires the input
   file to reside in UUCP_SPOOL:.  This change should only affect
   alternate mail transport systems such as Matt Madison's MX.
   CHANGES IN VERSION 1.3X (FROM 1.2X)                      Page H-5
   The Mailer


   H.5.3.5.3  "X" File Contents -

   The "U" line in "X" files contains the username and host which
   produced the UUCP request.  Some UUCP systems, such as
   HoneyDanBer, use this information to determine which commands
   UUXQT may process.

   Some implementations appear to choke on a username longer than 8
   characters.  HDB as implemented under Xenix has been reported to
   have this problem.

   Versions of the mail handler prior to 1.2 generated all manor of
   interesting things for the "U" line.  For 1.2, the behavior was
   changed to always generate "U uucp_daemon yourhost".  At 1.2a,
   the mail handler was changed again to generate "U uucp yourhost"
   in the X file.


   H.5.3.6  Miscellaneous Fixes

   H.5.3.6.1  Compatibility with VAX PSI -

   Patches for VAX PSI version 4.3 broke the inbound delivery
   interaction between UUCP_MAILSHR and VAX Mail.  This problem has
   been found and fixed.


   H.5.3.7  Miscellaneous Changes

   H.5.3.7.1  Change from BISON to Yacc -

   BISON, the GNU Yacc-alike, is no longer supplied with DECUS UUCP.
   We have changed to Berkeley Yacc, source for which is included in
   this release.

   Since this is a development tool, the source code is in the
   [.YACC] subdirectory of UUCP_TOOLS:.  The executable is in
   UUCP_TOOLS:


   H.5.3.7.2  Development Direcotory Structure Changes -

   The source code directory structure for the Mail Handler
   components has been rearranged.  This includes the source code
   for UUCP_Mailshr, Pathalias, PathProc and Smail.  Previously,
   each of these components had their own subdirectories under
   [UUCP.ORIG_CODE] and [UUCP.DEVEL].

   The subdirectories have been pushed down one level, and are now
   found in [UUCP.ORIG_CODE.MAIL_HANDLER] and
   [UUCP.DEVEL.MAIL_HANDLER].  This rearrangement is in preparation
   for some signficant Mail Handler component changes in a future
   release of DECUS UUCP.












                              APPENDIX I

                  CHANGES IN VERSION 1.2X (FROM 1.1)



   This appendix provides a brief description of the new features of
   version 1.2x of DECUS uucp, relative to Version 1.1x.  Subsequent
   appendices describe changes in earlier versions.

   1.2A, 1.2B, and 1.2C changes are identified via appropriate
   prefixes.


   I.1  Example Configuration Files

   The command procedures which we expect you to modify as part of
   your installation procedure are now provided in a new
   subdirectory tree, [.EXAMPLES...] .  For example, the supplied
   example control file is [.EXAMPLES.CFG]CONTROL. rather than
   [.CFG]CONTROL. ; no file called "CONTROL." is in [.CFG].


   I.2  New Facilities

   I.2.1  UUCP Command

   A rudimentary uucp command is now provided.  It will only be
   useful to privileged users, as it requires SYSPRV to run and we
   don't install it that way.

   (1.2B) The uucp.exe image would fail with an access violation if
   the logical UUCP_DOMAIN_NAME was not defined; this has been
   corrected.


   I.2.2  Utilities

   The following new utilities are provided:

         o  MODATT -- examine, store for later use, and change file
            attributes.  (This is Joe Meadows' FILE utility, under a
            different name.)

         o  BATCHNEWS -- collect news from news directories into a
            news batch
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-2
   New Facilities


         o  DIFF and PATCH -- ported versions of public-domain
            Unix-like context difference and patch programs.

         o  ARBITRON and INPATHS -- collect readership and
            propagation data from your news data base for
            transmission to the Usenet research project at decwrl.
            (Invoked automatically by NEWSSKIM.)


   I.3  The Mailer

   I.3.1  Header Processing

   UUCP_MAILSHR now generates any headers that it does not find when
   processing a message.  When processing a locally generated
   message, it assumes that no headers are present and generates
   them all.  (A side effect of this feature us is that it fixes the
   problems caused when the first line of a message happened to look
   like an RFC822 format header, e.g. "Greetings:")

   UUCP_MAILSHR now processes and/or generates RFC 822 Message-ID's.

   A new header, X-VMS-Mail-CC, is now created for locally generated
   mail whenever VAX Mail passes the contents of the users "CC"
   input to UUCP_MAILSHR.  As with previous versions of
   UUCP_MAILSHR, the X-VMS-Mail-To header is generated whenever VAX
   Mail passes the contents of the users "To" input to UUCP_MAILSHR.
   However, VAX Mail does not seem to always pass this information
   along.

   UUCP From_ line processing has been reworked.  This should
   eliminate all known bugs with the handling of this header and
   improve compliance with Internet RFC 976.  Also, in previous
   releases, From_ lines were discarded by the header processor.
   They are no longer deleted and will appear in the messages you
   receive.

   In UUCP_MAILSHR, the bug in parenthesis counting for RFC 822
   From: lines has been fixed.

   (1.2A) The 1.2 mailer generated From_ lines containing
   DECnet-style addresses (node::user) for mail that originated on
   DECnet nodes other than the uucp node.  This has been fixed in
   1.2A.

   (1.2A) Version 1.2 introduced the processing of Message-Id
   headers.  RFC822 indentifies the header name as "Message-ID",
   but, in practice, most of the Internet uses "Message-Id".  (Lower
   case "d".) In 1.2, the test for the header name was case
   sensitive.  This caused the code to miss valid "Message-Id"'s
   causing it to create another one.  The test has been changed to
   be case insensitive, also, for conformity, the generated field
   name now uses the lower case "d".
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-3
   The Mailer


   (1.2A) Personal name text in RFC822 headers is now always
   enclosed in quotes, and imbedded quotes are escaped with
   backslashes.  Thus, a personal name of the form

           John Q.  Citizen - "An honest guy, vote for me"

   will now appear as

           "John Q.  Citizen - \"An honest guy, vote for me\""

   in the "From:" header.

   (1.2A)  Some Unix hosts running MMDF have been complaining about
   a "parse error" when processing the "From:" generated by the
   mailer.  The problem appears to be caused when mail is sent from
   a user that has not defined a personal name.  A strict reading of
   RFC822 indicates that in the absence of a personal name, the
   address should not be placed in "<>".  For 1.2A, this is handled
   correctly.

   (1.2A) A received message that contained a really ugly RFC 822
   From: header caused UUCP_MAILSHR to crash with an access
   violation.  A short scratch buffer was located in the bowels of
   the address rewriter.  The text of the From: was longer than the
   buffer causing the stack to become trashed.  For version 1.2A the
   length of this scratch buffer has been changed to exceed the
   length of the text passed to the address rewriter.


   I.3.2  Logical Names

   (1.2A) For locally generated messages, UUCP_MAILSHR will look for
   the logical name UUCP_PERSONALNAME.  If it is present, it will
   use its translation for the personal name field of the messages
   From address.  If there is no translation, then NEWS_PERSONALNAME
   is tried.  If neither one translates, then the personal name
   supplied by VAX Mail is used.  This allows users to have
   different personal names for local and for network mail.  (In
   1.2, the order of search for these names was backwards.)

   It is no longer necessary (or desirable) to define the
   UUCP_DOMAIN_NAME logical if you do not have a registered domain.
   If UUCP_DOMAIN_NAME is not defined, or if the name ends in
   ".UUCP", From: addresses will be generated in "host!user" format
   instead of the "user@host.uucp" format that was previously used.


   I.3.3  Address Rewriting

   Pattern matching in the UUCP_MAILSHR rewriter is now case
   insensitive.  Previously, the strings to be tested was forced to
   lower case, while the patterns from the rules file were left in
   their original case.  Now, both the strings and the rules are
   forced to lower case before pattern matching is attempted.
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-4
   The Mailer


   [INBOUND-FROM] rewrite processing has been enhanced slightly.
   Normally, when a message is delivered into your system, a "UUCP%"
   and quotation marks are added to the From:  address.  This makes
   the address replyable with the VAX Mail REPLY command.  Now, if
   an [INBOUND-FROM] rewrite of the From:  address results in a
   string that contains a foreign protocol selector -- such as
   IN% -- the address is passed on as is.  This makes it possible to
   pretend that UUCP delivered mail arrived by some other means.
   (Note that the rewrite must return not only the foreign protocol
   selector, but the quotation marks in their normal positions for
   this feature to occur.)

   CHECKADDR (aka UUPATH) now supports the use of rewrite rules.
   This allows the rules to be tested without having to send mail
   and see what happens.  (This was actually documented as existing
   in the V1.1 manual, but the code that was packaged with 1.1 did
   not support it.)

   CHECKADDR now creates two DCL symbols to reflect to the last path
   displayed.  (It actually does it for all paths displayed, each
   display overwrites the previous values.) The symbol UUCP_PATH
   contains the path that CHECKADDR displayed; UUCP_PATH_LENGTH
   contains the number of bangs ("!") in the path.  Upon exit, a
   Success status code (%x10000001) reflects that a path was found;
   a Warning status (%x10000000) indicates that no path was
   displayed.


   I.3.4  File Names and Protection

   For the files that get transferred to a remote host, specifically
   the B and D files, UUCP_MAILSHR now creates names that are no
   longer than fourteen characters.  It does this by truncating the
   hostname portion of the name whenever your hostname is longer
   than 7 characters.  Both the filenames for the files stored in
   the local spooling directory, and the names passed to the remote
   host receive this treatment.  This allows mail to be exchanged
   with older uucp systems that can't handle longer filenames, even
   though your uucp hostname might be greater than seven characters
   long.

   Files created by UUCP_MAILSHR in the spooling directory will now
   always receive a file protection of (S:RWED,O:RWED,G:RWED,W)
   regardless of the users current default file protection setting.
   (Formerly, if a user had set their default protection to
   System:No access, they could not use the uucp mailer.)

   In the UUCP spooling files created by UUCP_MAILSHR, the user
   identification fields now reflect that the files come from
   "uucp_daemon" at your host.  Previous releases improperly placed
   From line information in these fields.
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-5
   The Mailer


   I.3.5  Username Fields in B (X) Files

   (1.2A)  The "U" line in "X" files contains the username and host
   which produced the UUCP request.  Some UUCP systems, such as
   HoneyDanBer, use this information to determine which commands
   UUXQT may process.

   Some implementations appear to choke on a username longer than 8
   characters.  HDB as implemented under Xenix has been reported to
   have this problem.

   Versions of the mail handler prior to 1.2 generated all manner of
   interesting things for the "U" line.  For 1.2, the behavior was
   changed to always generate "U uucp_daemon yourhost".  For 1.2A,
   the mail handler will generate "U uucp yourhost" in the X file.


   I.3.6  MAKEPATHS

   MAKEPATHS may now be instructed to use more disk and less memory.
   See the commentary at the beginning of UUCP_BIN:MAKEPATHS.COM for
   instructions on how to set the UUCP_MAKEPATHS logical name to
   achieve this.


   I.3.7  Help file for MAIL

   In [.DOC] you will find a help module, MAIL_UUCP.HLP, which may
   be inserted in your SYS$HELP:MAILHELP.HLB help library.
   (Courtesy of Kent Brodie)


   I.4  UUCP

   I.4.1  Protocol Handling

   During the uucp startup sequence ("shere exchanage"), we now
   ignore leading NULs when looking for strings starting with DLE
   and ending with NUL.  This avoids a problem that shows up as "No
   ROK received" logfile messages on outbound calls.  (This fix due
   to Todd Aven, manager@usgcdh.com)

   On incoming calls, we now send Shere=ourname instead of just
   Shere.  Most uucps prefer the former, and all seem to be able to
   take it.

   On outbound calls, the timeout during the shere exchange is
   increased from 10 to 40 seconds, to give the answering system a
   ____
   long time to get uucico going.

   BSD 4.3 uucp's send two null bytes before (after?) each packet.
   We no longer report these as errors in the log.  (This fix due to
   Jerry Leichter, yale!lrw!leichter)
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-6
   UUCP


   We no longer increase the debug level after a number of errors
   have occurred.

   Allow for receipt of ACK while in CLOSE state, and for INITC in
   RUN state.  This eliminates some spurious (benign) error reports.

   (1.2A) Comment lines delimited with either "#" or "!" may appear
   in the systems. file in the midst of continued entries.

   (1.2A) The uucico "Shere exchange" sequence will now accomodate
   certain Sun systems which apparently terminate their Shere, etc.,
   messages with linefeeds rather than nulls.


   I.4.2  Call Requests and Decisions

   The progressive recall time calculation is modified to not give
   floating-point overflows after large numbers of failures and/or
   long failure intervals.  (This fix due to Tom Allebrandi)

   Don't bump nfails in the stst file if calling the same system as
   before during the same scan of the systems file.  Formerly, if
   you had 'n' entries for a given system, and uucico tried and
   failed to reach them using all 'n' entries, this would be counted
   as 'n' failures.  It's now counted as just one.

   Messages written to the uucico daemon's mailbox (UUCP_REQUESTS:)
   are now logged in the regular log file rather than the debug log.

   The "$READCTL" message which can be written to the uucico
   daemon's mailbox to force a new read of the control file, is now
   case insensitive.

   (1.2A) A fail interval of zero (either explicit, or from an entry
   such as Any,15,,) would previously cause a divide by zero
   exception; this has been fixed.

   (1.2B) Formerly, the uucico daemon would only perform "polling"
   calls if it was awakened by expiration of its "sleeptime"
   interval; it would not perform polling after being awakened by
   notification of an outbound work request (e.g. a user sending
   mail).  Unfortunately, this meant that if work requests always
   arrived before the "sleeptime" had expired, no polling would ever
   be done.  This has been corrected; neighbors can now be polled
   both upon sleeptime expiration and upon outbound work
   notification.


   I.4.3  Script Processing

   Allow for talking to systems that want us to log in with other
   than no parity.  A default parity for the login script may be
   specified in the systems entry, and this default may be changed
   within scripts via new script commands (parity_even, etc.).
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-7
   UUCP


   iflat and ifnlat script statements allow scripts to do different
   things depending on whether the port is a LAT port or not.

   (1.2C) In previous versions, the script processor failed to match
   incoming strings if more than 127 characters, with one or more
   null bytes, arrived before the target string did.  In other
   words, one had trouble finding "username" and "login" prompts
   when calling systems with long pre-login announcements, if this
   output included null bytes.  This has been fixed.  (The fix is
   due to Bruce Tanner, tanner@cerritos.edu.)


   I.4.4  Terminal I/O

   For outbound calls, if the port is a LAT port, do the right
   things regarding CONNECTing and DISCONnecting the port as far as
   the LAT box is concerned.  While we're at it, log the LATserver's
   name and the port name.

   The infamous "hangup bug", which caused the uucico daemon to
   become "wedged" after terminating an outbound call, has been
   fixed.

   VMS Version 5 introduced a bug in the terminal driver such that
   SET TERMINAL/NODISCONNECT no longer did what we want it to, that
   is, clean up and exit our image at the end of an incoming call,
   even if the port was set to /DISCONNECT originally.  The effect
   was that, at the end of a call, the "Disconnected" process would
   wait around for the reconnect timeout interval, sometimes with
   the lock for the remote system still held.  We've worked around
   the problem.  (This fix by Mark Pizzolato.)

   In the control file, a new option on "port" lines tells uucico to
   not change the port speed for outgoing calls.  (Useful with
   Telebit and other modems that can run at various line speeds with
   a single locked host interface speed.) We now recommend using
   these modems with a locked interface speed for both inbound and
   outbound calls.

   Do an automatic typeahead buffer flush after hanging up the line
   on outbound calls.  This avoids certain autobaud and "huh?-what?"
   problems that get started when the modem sends a burst of noise
   to the VAX when the VAX drops DTR.

   (1.2A) Uucico now refuses to talk to RTAnnn devices, since such
   devices do not support several of the required $QIO SETMODE
   functions.

   (1.2C) The above-described check for RT devices, and the code for
   checking for LAT terminals, did not work if the device had a
   cluster-style name (node$RTAnnn).  The code has been corrected to
   use information from $QIO sensemode and $GETDVI to identify LAT
   and RT devices, rather than looking for strings in the device
   name.
   CHANGES IN VERSION 1.2X (FROM 1.1)                       Page I-8
   UUCP


   I.4.5  File Handling

   Add "~" to the list of characters we look for when stripping
   directory specs from file names received from other systems.

   When processing a C file, don't delete each file as we send it.
   Instead, make a list of files sent and then delete them all at
   once when (and only if) the whole C file is processed
   successfully.  (This fix due to Mark Pizzolato)

   Make the few-characters-at-a-time output in log files readable
   the way it's supposed to be (not one character per line).

   When logging the other system's transmissions to us during the
   startup sequence, print a leading ` if the high bit is set.

   There were several conditions under which the uucico daemon would
   leave channels open to temporary files in the spool directory if
   a file receive failed.  This has been corrected.

   (1.2A) Uucico and uuxqt will now correctly handle received X and
   D filenames (but no others) containing more than one period (.).


   I.4.6  Configuration Files

   "!" may now be used as welll as "#" as a comment indicator in the
   control file.


   I.5  NEWS

   The DECUS uucp distribution includes ANU NEWS Version 5.9C.












                              APPENDIX J

                   CHANGES IN VERSION 1.1 (FROM 0.2)



   This appendix describes the changes that were made in DECUS uucp
   from the first released version, 0.2, to the second released
   version, 1.1.


   J.1  Name Changes

   J.1.1  Logical Name Prefixes and Directories

   The top-level directory is now called [UUCP] (you can change this
   via logical name assignments), and all logicals are now prefixed
   with UUCP_ rather than VMSNET_ .  We shouldn't have to change
   them again because we have registered the facility name, "UUCP",
   and the corresponding logical name prefix and shareable image
   names, with Digital.


   J.1.2  Images

   The gnuucp.exe image has been renamed to uucico.exe, to better
   reflect its correspondence to the Unix program of the same name.


   J.1.3  Other Files

   Many files such as log files, debug log files, and data files
   have had their names "rethought" to better reflect their function
   and to reduce the number of keystrokes required to access them.


   J.2  Required Configuration Changes

   J.2.1  Control File Changes

   The "nodename" entry has been renamed to "hostname", to avoid
   confusion between the DECnet node name and the uucp host name
   (since this entry reflects the latter).

   The debug level is now interpreted as a bit mask, not a simple
   number.  To make it easy to specify the bit mask, the number
   supplied in the control file can be specified in hex or octal as
   well as in decimal.
   CHANGES IN VERSION 1.1 (FROM 0.2)                        Page J-2
   Required Configuration Changes


   Several new items have been added to the control file.


   J.2.2  Systems File Format Change

   Entries in the systems file must be modified to include several
   new fields; also, the login script information (expect-send
   sequence) has been moved out of the systems file into "script
   files", to which the entries in the systems file point.


   J.3  New Features

   J.3.1  Operational Features

   J.3.1.1  The Mailer

   J.3.1.1.1  Name change -

   To reflect the change in name of the entire software package, the
   mailer is now called UUCP_MAILSHR and is invoked via UUCP%.


   J.3.1.1.2  Not-a-neighbor routing -

   The previous version of the mailer accepted pure uucp bang path
   addresses verbatim:  Mail was always queued to the next hop,
   regardless of whether or not you communicate with that host.  The
   result was that the mail sat in your spool directory forever.

   For this release, the router checks to see if the next host is
   one you communicate with, as defined in your map entry.  If not,
   it generates a route to the host, then tacks on the rest of the
   bang path from the address you specified.


   J.3.1.1.3  smart-host -

   This version of the mailer supports the "smart-host" alias.  If a
   smart-host alias is defined in your local routing data, and the
   router encounters an address it can't resolve, the message is
   passed on to the smart-host.  The presumption is that the
   smart-host should be able to figure out what to do with the mail
   address.


   J.3.1.1.4  Local delivery -

   The previous version of the mailer did not allow addresses which
   resolved to the local machine.  When it encountered one, it
   refused to send the mail.  This restriction has been removed.
   CHANGES IN VERSION 1.1 (FROM 0.2)                        Page J-3
   New Features


   J.3.1.1.5  From header format -

   The format of the "From:" header in the mail body has been
   changed.  Previously, the format was

        user@host (Personal Name)

   Now, it is

        Personal Name <user@host>


   Both forms are valid according to the Internet specifications
   (RFC-822).  It is hoped that the new form will work better with
   mailers that have trouble with ()'s in the personal name.


   J.3.1.1.6  Accessing the paths file -

   The mailer now enables SYSPRV before opening UUCP_DATA:PATHS.
   There is no longer a requirement to make that file world
   readable, though it really should not hurt anything if it is.


   J.3.1.1.7  LongUserName -

   In the previous version, when mail was sent out from a VMS
   account that had a full 12 character username, the username did
   not appear in the "From:" address.  This is fixed.


   J.3.1.1.8  Rewrite rules -

   The mailer now supports a limited amount of address rewriting.
   The primary purpose for this is to allow the host running DECUS
   uucp to be a gateway for a local subdomain or a DECnet network.
   Inbound addresses to the gateway can be rewritten into a form
   that is correct to achieve the target delivery.  Outbound
   addresses can be rewritten to allow them to be replied to by
   hosts that don't know (or care!) about your local topology.


   J.3.1.2  News Integration

   We are supplying a complete set of command procedures and
   programs for integrating ANU News with DECUS uucp.  The package
   can now exchange News with Unix sites using the preferred
   "compressed rnews" format.

   When maps are received in the comp.mail.maps newsgroup, they will
   be automatically placed in the [.DATA.MAPSRC] directory, and the
   local PATHS. database will be updated, all without manual
   intervention.
   CHANGES IN VERSION 1.1 (FROM 0.2)                        Page J-4
   New Features


   J.3.1.3  Call Time Control

   The systems entry can now specify the days of the week and times
   during those days when the remote system may be called.  In
   addition, the format allows the specification of retry intervals;
   these are used to prevent too-frequent outbound calls.


   J.3.1.4  "On-Demand" Outbound Calls

   Uucico.exe (formerly gnuucp.exe) will now automatically awaken,
   search for outbound work, and (if call time restrictions permit)
   initiate the appropriate call when a user on the local system
   sends uucp mail.  This can reduce mail forwarding latency if the
   normal sleep interval is long.


   J.3.1.5  Polling

   If desired, DECUS uucp can now automatically "poll" neighbor
   systems in the absence of local work destined for those systems.
   This is useful for neighbors which cannot originate calls.


   J.3.1.6  System-Specific Debug Levels

   The system file entry for each neighbor system may specify the
   debug level that is to be used during calls to and from that
   system.  This value, if present, overrides that specified in the
   control file for the duration of the call (or call attempt) that
   uses the system entry in question.


   J.3.1.7  Improved Log Files

   Log file entries have been reformatted and made easier to read.

   More debug log options are available, and debug log options may
   be specified independently of one another (for instance, turning
   on option 9 does not automatically turn on all lower-numbered
   ones).

   When a neighbor system dials in, SYS$ERROR is directed to a file
   in the log directory.  The contents of this file will sometimes
   provide clues in the event that uucico terminates abnormally
   during an incoming call.


   J.3.1.8  Login and Dialer Scripts

   The code that deals with autodialing modems and handles
   "expect-send" sequences for outgoing calls has been completely
   rewritten to use "script files".  These are ordinary text files
   that reside in [.CFG] .  Two scripts, DIAL.modemtype and
   HANGUP.modemtype, provide dialing and hangup instructions for
   modems, so it is now easy to add support for additional modem
   CHANGES IN VERSION 1.1 (FROM 0.2)                        Page J-5
   New Features


   types without modifying the source code.

   Another script, LOGIN.systype, is used to negotiate the login
   sequence for remote systems.  The "systype" field is obtained
   from the entry in the systems file for the neighbor being called.
   Additional string parameters can be passed from the systems entry
   to the login script, so that one script can serve for many
   neighbor systems.


   J.3.2  Security Features

   J.3.2.1  Local Username Checking

   The systems entry for each neighbor system can now specify the
   uucp login which that system is supposed to use for calls to your
   system.  When servicing an incoming call, DECUS uucp checks this
   against the actual username of the process, and rejects the call
   in case of a mismatch.


   J.3.2.2  Callback Support

   DECUS uucp now supports automatic callbacks.  A "callback
   required" flag in the local systems file dictates that inbound
   calls from the indicated system are to be rejected, following
   which the local uucp system will call the neighbor back.  This
   provides enhanced security in case an intruder learns the uucp
   login username and password used by one of your neighbor systems;
   if your systems entry specifies callback, the only result will be
   spurious calls on your part to that neighbor.

   If the remote system is also running DECUS uucp, symmetrical
   callbacks are allowed; that is, a pair of systems can specify
   callbacks for each other; DECUS uucp will recognize the returned
   call as a callback, and will not go into an "infinite callback"
   loop.


   J.3.2.3  Remote File Receive Requests Disabled

   Unix uucp supports both remote send and receive requests,
   although only sends are used for transferring mail (that is, each
   system tells the other "I want to send this file").  For mail
   transfer, only sends are used, so we have inhibited our
   implementation from responding to other systems' "I want to
   receive file foo.bar" requests.  (This capability may be
   reinstated by adding a line to the control file.)


   J.4  Implementation Changes

   CHANGES IN VERSION 1.1 (FROM 0.2)                        Page J-6
   Implementation Changes


   J.4.1  Improved "g" Protocol Implementation

   The implementation of the "g" protocol now supports "windowing",
   and reads a reasonable number of characters at a time (not just
   one) from the serial port.  The result is a dramatic improvement
   in throughput, together with an equally dramatic reduction in VAX
   CPU load, over the Version 0.2 implementation.


   J.4.2  New Execution Strategies

   In Version 0.2, the gnuucp image for placing outgoing calls was
   run in a self-resubmitting batch job; it attempted to place calls
   each time it ran.  Its replacement, uucico, is still run in a
   batch job, but it is now designed to be started once (typically
   when the VMS system is started) and should run until the system
   is shut down.  The image waits (rather than exiting) between each
   series of work scans.  (In order to conserve physical memory,
   uucico purges its working set before entering the wait.)

   Similarly, uuxqt now "runs" continuously.  Its batch job is
   started when the rest of the DECUS uucp system is started.  After
   processing all available work (normally none at startup time), it
   hibernates rather than exiting, waiting for the next execution
   file to be received.  This single uuxqt job processes all
   incoming work from all neighbor systems, rather than being
   invoked to handle work from a single call.

   The uuxqt process is awakened each time an execution file is
   received rather than once at the end of a call.  This should
   result in greater overlap between uuxqt (which is mostly
   disk-bound) and uucico (which spends most of its time waiting for
   I/O on the serial link); peak disk space requirements will also
   be decreased.

   The process invoked by the MAKEPATHS procedure has been
   streamlined to improve CPU utilization and significantly reduce
   temporary disk storage.  Previously, the output from the
   Pathalias route generator was sent to disk and subsequently
   postprocessed by three separate utilities.  The three utilities
   have been replaced by a new utility, PathProc.  PathProc attempts
   to do all of the postprocessing work in memory, and will only use
   temporary disk space if it runs out of memory.  Further, PathProc
   will cause Pathalias to be run in a subprocess, with the output
   from Pathalias being fed directly to PathProc, using no
   intermediate disk space.  (A working set of around 4K pages is
   required for efficient operation, however.)


   J.5  Bug Fixes

   The following problems were discovered in Version 0.2.  These
   have been corrected in this release.
   CHANGES IN VERSION 1.1 (FROM 0.2)                        Page J-7
   Bug Fixes


         o  The gnuucp and uuxqt images would abort with an access
            violation when running on a clustered system.
            (Corrected in sysdep.c)

         o  The mail delivery mechanism for incoming mail failed
            under VMS V5 due to lack of sufficient privileges.
            (Corrected in uuxqt_dcl.com)

         o  Uuxqt was sensitive to the name format of received
            X-files.  (Corrected in uuxqt.c)

         o  The "g" protocol had several problems communicating with
            certain types of Unix uucp's as well as the Telebit
            Trailblazer's implementation.  (Gio.c replaced with
            giowvms.c)












                              APPENDIX K

                             WANT TO HELP?



   This is a volunteer effort, and if you want to help out, we
   certainly want to encourage you to do so.  However, we do ask
            ______ _______ __ _____
   that you please contact us first.

   We are still working very actively on DECUS uucp; the code you
   have will almost certainly be an earlier version than what we are
   working with.  If you go off and implement something without
   talking to us first, we'll try to incorporate it, but you must
   realize that:

         o  We may already have done it, or

         o  We may have thought about it and made provisions for
            doing it in a different way, or

         o  We may already have done something else that precludes
            your implementation from working, or

                                                ____
         o  We may, for some other reason, have very strong
            requirements on how it needs to be done.

   If we can compare notes before you start, we can save everybody a
   lot of time, trouble, and aggravation.  We really don't want to
   have to say "gosh, that's nice, but we can't use it", as this is
   not likely to encourage you to contribute again later.  We'd much
   rather work with you beforehand!

   The following list provides style and design guidelines.

         o  Local variables and function names should be in
            lowercase; globals (externals) should have their first
            character capitalized.  Defined symbols should be in all
            caps.

         o  We are not going to make any rules about brace/indent
            style, especially since the three of us each prefer a
            different one.  If you create new code, pick a style you
            like and use it consistently.  If you modify existing
            code, stick to the style that already exists in the
            routine(s) in question.
   WANT TO HELP?                                            Page K-2



         o  Any event flags used should be allocated via LIB$GET_EF
            .  Do not use LIB$FREE_EF to make any of the flags in
            cluster 0 available for allocation, or existing code
            which relies on the allocation of multiple flags from
            the same cluster will break.

         o  Do not use the $HIBER/$WAKE mechanism within uucico, at
            least not while the packet protocol is running; use
            event flags instead.  $HIBER/$WAKE is in use by the g
            protocol implementation.  Having some other code thread
            do $HIBERs or $WAKEs while the packet protocol is
            running could cause it to fail.

   .appendix Acknowledgements


   K.1  Version 2.0

   Mark Pizzolato has made vast and sweeping changes in the uucico
   code, mostly in the area of file handling.  All of the new
   support for generalized uucp file transfers, complete with VMS
   file attributes, is his code.  He is also responsible for the new
   UUCP_SYSTARTUP.COM, GENERATE_CONTROL.COM, and UUCP_CONFIG.COM .

   Tom Allebrandi has contributed a large set of improvements to the
   mailer.

   Jamie Hanrahan's main contribution this time around was in the
   documentation and in collecting the distribution (and in endless
   pestering Tom and Mark about the changes they were making).

   Earle Ake contributed several "behind the scenes" items,
   including the new packet buffer log file format, and the
   foundation for supporting additional data link protocols.


   K.2  Version 1.2x, 1.3x

   As before, Jamie Hanrahan made a few changes to uucico and
   friends; Tom Allebrandi made improvements to UUCP_MAILSHR; and
   Mark Pizzolato tweaked the NEWS interface.  Mark also wrote
   UUCP_CONFIG.COM .


   K.3  Version 1.0 and 1.1

   Tom Allebrandi made many improvements to UUCP_MAILSHR (formerly
   VN_MAILSHR), allowing routing of bang-path addresses, and
   implemented the address rewrite mechanism essential for local
   subdomain support.  He also wrote the PathProc utility.

   Jamie Hanrahan implemented the windowed g protocol, the
   dial/login script processor, and the new uuxqt execution
   mechanism.  He (I) also did most of the writing for this manual.
   WANT TO HELP?                                            Page K-3
   Version 1.0 and 1.1


   Mark Pizzolato wrote the new call scheduling and status recording
   code, and also created the programs and command procedures
   necessary to integrate ANU News and DECUS uucp.  He also made
   several improvements in the character I/O performance of the
   non-windowing g protocol implementation of Version 0.2 and
   debugged several problems in its packet handling.  None of the
   latter code survives in the current windowing version, but his
   work provided a great deal of information which was invaluable
   during the implementation and testing of the windowing code.
   Mark also got a modified Version 0.2 working with a Trailblazer
   modem and wrote the Appendix describing how he did it.

   Anyone who wants to understand windowed protocols is referred to
                                                  ________ ________
   Chapter 4 of the standard work on the subject, Computer Networks
                                                          _______ _
   by Andrew S. Tanenbaum (Prentice-Hall).  Another book, Kermit, A
   ____ ________ ________
   File Transfer Protocol by Frank da Cruz (Digital Press), provided
   a very lucid (dare I say "transparent"?) description of the
   sliding-window extension to Kermit.  Although windowed Kermit
   differs in several important ways from uucp "g", this material
   was of great assistance in designing the windowed "g"
   implementation.


   K.4  Version 0.2

   Tom Allebrandi is responsible for the port of pathalias and for
   the integration of smail with the VN_MAILSHR image.  The UUCP
   Project authored the original smail, and Dr. Peter Honeyman
   created pathalias.

   Jamie Hanrahan worked on gnuucp, uuxqt, and rmail, and the
   documentation you're reading.  (The occasional "I" that creeps
   into the text here refers to him.  Me, that is.)

   VN_MAILSHR and rmail were derived from Kevin Carosso's uucp mail
   interface, as distributed on the Spring '87 DECUS VAX SIG tape.
   rmail has become a procedure called by uuxqt.

   Gnuucp and uuxqt are derived from John Gilmore's gnuucp package,
   with mods for VMS by Lol Grant.  Jamie made some changes to the
   dialer code and to the uuxqt execution mechanism to get it to run
   well with dialup lines.  The dialer code was taken from
   C-Kermit/VMS, and modified to work with VMS ports (many of which
   won't send you data until they see carrier, so it's useless to
   look for "CONNECT" strings).

   Credit is also due to Todd Aven, whose MAKE utility Jamie used,
   and to the original authors of the MFTU utility, which Todd
   distributed.  (We used MFTU to transfer LZCMP'd backup savesets
   between Tom's and my machine via Kermit.)

     _____
   A large round of applause goes to Bill Blue, proprietor of Crash
   Timesharing in El Cajon, California.  Bill's machine
   (crash.cts.com) was (and still is) Jamie's primary "guinea pig"
   for testing gnuucp and mail.  Bill spent many hours answering
   Jamie's naive questions and interpreting uucp log files after
   WANT TO HELP?                                            Page K-4
   Version 0.2


   (numerous) failed attempts.  It is no exaggeration to say that
   the VMSnet software would not be running today if it were not for
   Bill's assistance.  Thanks, Bill!

   (Bill is also the uucp map coordinator for Southern California
   and Arizona, and the completeness and accuracy of the maps for
   this region are due largely to his efforts.)

   Bison, and the versions of gnuucp and uuxqt which appear in our
   [.ORIG_CODE] directories, are Copyright by the Free Software
   Foundation, and are made available under the terms of the GNU
   software license.  The full text of this may be found somewhere
   in [.ORIG_CODE...].  Recipients of this software are asked to
   comply with its terms.

   These original versions of gnuucp and uuxqt were in turn based on
   a public domain program called "uuslave", author unknown.  In the
   case of these programs, therefore, the GNU license only applies
   to the portions of the code written by John Gilmore.

   Our changes and additions to all of these programs are in the
   public domain.
                                                             Page Index-1


                                   INDEX



   Aliasing                            Hostsync (terminal
     of hostnames, 4-1, 5-6, 5-13          characteristic), 6-8
     of local hostname, 5-13
     of spool directory name, 5-13     Internet, 1-4 to 1-5
   ANU-News                            Internet Domain Registration, 1-3,
     DECnet, 11-6                          4-2 to 4-3, 10-1 to 10-3
     NNTP via DECnet, 11-6             Internet Mail Forwarder, 1-4, 4-3
     NNTP via TCP/IP, 11-7
     NNTP with Unix, 11-7              LAT Ports, 3-3, A-6
     UUCP, 11-6
     VAXclusters, 11-5                 Makepaths, 7-2, B-1
    
   CD, 3-9, 3-13 to 3-14               Newsgroups, 11-1
   Cluster Users, 0-2, 5-10, 7-5         ANU-News, 11-5
   Commercial UUCP Services              Biz.telebit, 11-2
     Performance Systems                 Comp.mail..., 11-1
         International, 4-3              Comp.org.decus, 11-2
     UUNET Communications Services,      Comp.os.vms, 11-2
         4-3                             Comp.sources.misc, 11-2
   Configuration Files, ii, 2-3,         Comp.sources.unix, 11-2
       5-22, 5-24                        Feeding News, 11-4
   Control File, A-6                     local, 11-3
     ACU, A-6                            News..., 11-2
     L option, A-6                       News.software.anu-news, 11-2
   CTS, 3-6, 3-14 to 3-15                Newsfeeds, 11-3
   CXA16, 3-9, A-2                       To., 11-3
   CXB16, A-2                            VMSnet..., 11-2
   CXY08, A-1
                                       Packet size, 5-15
   DB25, A-1                           Pageswapper, 0-5
   DECserver, 3-3 to 3-4, 3-6, 3-13,   Parity, 6-7
       A-1                             Path Data Base, 7-2
   DECUServe, 0-4                      Pathalias, B-1, B-5 to B-6
   DHQ11, A-1                          Paths, 7-2
   DHU11, A-1                          Performance Systems International,
   DHV11, A-1                              4-3
   DMB32, A-1                          Postmaster, 5-6
   DMF32, 3-9, 3-12, A-1 to A-2        PSI Performance Systems
   DMZ32, A-1                              International, 4-3
   Domain name
     in control file, 5-6              $READCTL, I-6
   DSR, 3-13 to 3-14                   Rewrite Rules
   DTR, 3-9, 3-12 to 3-13                Inbound-From, 10-6
                                         Inbound-To, 10-6
   GMT, 12-9                             Outbound-From, 10-6
   Graded transfers, 5-18                Outbound-To, 10-7
                                         Rules, 10-8
   Hostname                              Set Selectors, 10-8
     aliasing, 5-13                      Suggestions, 10-9
     local, 5-5                        RS232, 3-6, 3-12, 3-14
   Hostname aliasing, 4-1, 5-6, 5-13     CD, 3-9, 3-13 to 3-14
                                                             Page Index-2


     CTS, 3-6, 3-14 to 3-15              Costs, B-2
     DSR, 3-14                           Domains, B-5
     DTR, 3-9                            Format, B-1
                                         Gateways, B-4
   Smart-Host, 5-4, 7-2, 7-6, B-5        Hidden Hosts, B-4
   Spool directory                       Names, B-1
     aliasing, 5-13                      Networks, B-3
   SYSUAF quotas for UUCP Account,       Route Restricting, B-4
       5-2                               Smart Hosts, B-5
                                         Terminal links, B-3
   Telebit Modems, A-1                 UUCP Reference Books, 0-2
     initial setup, A-4                UUCP Script Files, 5-22, 6-1
     modem settings, A-3                 Action Statements, 6-2
     serial port, A-1                      failed, 6-2
   Telebit T2500, A-5                      log, 6-2
   Telebit TrailBlazer Plus, A-5           logerr, 6-2
   Terminal characteristics                success, 6-2
     Hostsync, 6-8                       Default Timeouts, 6-6
   Terminal Setup, 3-2                   Dial Scripts, 5-22
   Time restrictions, 5-16               Extended Strings, 6-4
   Time zones, 5-6                       Format, 6-1
   TTY_DIALTYPE, 3-15                    Hangup Scripts, 5-23
   Typeahead Buffer, 3-6                 Hostsync, 6-8
                                         Login Scripts, 5-23
   Usercmds.com, 7-4 to 7-5, 12-10,      Misc, 6-3
       12-16, C-1                          count, 6-3
   UTC, 12-9                               goto, 6-3
   Utilities, C-1                          ifblgtr, 6-3
     Checkaddr, C-2                        ifblind, 6-3
     Compress, C-5                         ifgtr, 6-3
     Tail, C-3                             iflat, 6-3
     Usercmds.com, C-1                     ifnlat, 6-3
     Uurate, C-13                          ifnstr, 6-3
   UUCP Account                            ifstr, 6-3
     creation, 5-1                         sleep, 6-3
     login flags, 5-2                      zero, 6-3
     password expiration, 5-2            Overriding Defaults, 6-8
     SYSUAF quotas, 5-2                    chrdly, 6-9
   UUCP Control File, 5-4                  ctime, 6-9
     changes, 5-11                         dgttime, 6-9
     debug, 5-7                            pchar, 6-9
     Enbrmtrcv, 5-9                        ptime, 6-9
     filealias, 5-6                        wchar, 6-9
     hostname, 5-5                         wtime, 6-9
     port, 5-7                           Parity, 6-7
       flags, 5-8                          even, 6-8
       modem-type, 5-8                     mark, 6-8
       port-name, 5-8                      none, 6-7
       speed, 5-8                          odd, 6-8
       vms-device, 5-8                     space, 6-8
     sleeptime, 5-9                      Sending Data, 6-2
   UUCP Map Entry, 4-1, 5-4                dial, 6-2
     Host Names, 4-1                       send, 6-3
   UUCP Maps                               sendstr, 6-3
     Aliases, B-3                        String Parameters, 6-5
                                                             Page Index-3


       pause, 6-5                        port name, 5-20
       wait, 6-5                         protocols, 5-14
     Terminal Control, 6-3               speed, 5-20
       break, 6-3                        when, 5-16
       flush, 6-3                          days, 5-16
       hangup, 6-3                         examples, 5-18 to 5-19
     Waitfor, 6-4                          fail, 5-17
       expect, 6-4                         grade, 5-18
       ifcarr, 6-4                         poll, 5-17
       timeout, 6-4                        succ, 5-17
   UUCP Systems File, 5-11                 time interval, 5-16
     entry-name, 5-13                  UUCP_CONFIG, 5-1
     hostname, 5-12                    UUCP_REQUESTS, I-6
       filealias, 4-1, 5-13            UUNET Communications Services,
     login script, 5-21                    4-3
     luser, 5-13                       Uupoll, 7-4
       spooldir, 5-13
     options, 5-14                     VAXclusters, 0-2, 5-10, 7-5
       b, 5-15                         VMSnet mailing list, 0-5
       c, 5-14
       p, 5-14                         Window size, 5-15
       w, 5-15
       x, 5-14
     phone number, 5-21                XON/XOFF, 3-6, 3-8, 3-15