From: brodie@fps.mcw.edu
Newsgroups: vmsnet.uucp
Subject: CHANGES in DECUS UUCP (1.3x -> V2.0) a.k.a. "appendix G"
Date: 23 Jul 92 10:27:15 CST
Organization: Medical College of Wisconsin,  Milwaukee, WI

I'v had several requests for this, so here you go.   The following
is "appendix G" from the decus uucp V2.0 manual, which describes
the changes from V1.3x to V2.0.   This should help you decide
whether or not to go to V2.0 or not.....

                              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.

























-- 
Kent C. Brodie - Sr. Systems Manager		InterNet:  brodie@fps.mcw.edu
Faculty Physicians & Surgeons			uucpNet:   fps.mcw.edu!brodie
Medical College of Wisconsin			MaBellNet: +1 414 266 5080

"Little bunny FOO-FOO, hoppin' through the forest,
   scoopin' up the field mice and boppin' 'em on the head.."  -childrens song
Xref: sparky vmsnet.uucp:605 comp.os.vms:12858