synchro.net/synchro.net.tar/synchro.net/modem.madness/SMMNETML/CPML_120.ZIP/COPYMAIL.DOC

Text File | 1991-06-16 | 14.0 KB | 282 lines

CopyMail Version 1.20 -- Copyright 1991 by W. F. Muldrow

    This program is an original work by W. F. Muldrow (8:928/1@RBBSNet or
1:3617/1@FidoNet).  Permission is granted to freely distribute unmodified
copies of this program together with its documentation and sample
configuration files so long as no fee is charged for such distribution.
Permission is also granted to use the original program or a modified version
of this program and to incorporate any or all of this program into other
applications so long as no fee is charged for any derivative work.

    COPYMAIL is intended for use in multitasking, multi-node, or multi-
domain unattended mailer applications.  It provides the capability of moving
outbound mail packets and bundles which were created in an off-line directory
to the on-line outbound area in a controlled and safe manner.  Multiple nodes
are supported.  Multiple off-line outbound areas are supported in order to
facilitate multi-zone applications.  For multi-domain use, it can easily
support Binkley-Term's outbound directory naming conventions, because you
explicitly name the directories that CopyMail should copy to and from.

    There are several goals to meet in order to efficiently move mail in
a multitasking and/or multinode environment:

        1.  All mailer nodes should be online and ready to answer inbound
calls a maximum amount of time.

        2.  All mailer nodes should be able to share common outbound areas
so that callers may receive all available mail by calling any available node.

        3.  The mailer must not transmit files which are in use by a mail
processor and the mail processor must not compress packets or update bundles
that the mailer is attempting to send.

    CopyMail to the rescue!  All of these goals can be satisfied using
CopyMail together with Binkley-Term 2.40 or later.  It is expected that a
future release of Opus will also allow the same processing method to work.
Here's how it's done:

        1.  For multi-node systems, all mailer nodes are configured to share
the same set of outbound directories and each node has a unique (not shared)
inbound files directory.

        2.  The mail processor is configured to use a different set of
inbound and outbound directories that are not shared with the mailer(s).

        3.  When mail is received by the mailer, it is copied from that
node's inbound files area to the mailer's inbound file area.

        4.  If the mail processor is not already active, it is started.
When running under a multitasking environment such as Desqview or Windows,
this involves opening an additional window to allow background processing
of the mail.  In a network environment it may involve a mailer node remaining
off line in order to process mail, but even so, only one node need be off
line to process all of the mail that has been received on any node.

        5.  When the mail processor is finished and new outbound mail has
been packed up for the mailer to send, the mail processor's batch file
invokes CopyMail.  CopyMail will happily and safely move the new outbound
mail into the mailer's outbound directory(ies).

        6.  After CopyMail has done it's thing, the mail processor's batch
file should check to see if more unprocessed mail has been received.  If
so, return to step 4 and process more mail.  Otherwise, if in a window, the
window can be closed; or if in a network, the node can go back on line.

    Copymail uses the Binkley-Term version 2.40 convention of looking for
and creating a flag file (xxxxyyyy.BSY) in the outbound directory to indicate
when it is unsafe to alter outbound files for a node.  To enable this feature
in Binkley-Term, the TaskNumber and Flags configuration verbs should be
enabled.  Copymail will also create task flags in Binkley's Flags directory
to help in coordinating multitasking operations.  The way these flags work
is this:

    The "flag" file is located in the Binkley-Term (or Opus) outbound
files directory.  It has a file name of "xxxxyyyy.BSY" where "xxxx" and
"yyyy" are the net/node number in hexadecimal notation.  Binkley-Term will
create this flag just before attempting to dial the node or if the connection
is an inbound call, just before sending files.  If the flag already exists,
then some other process (or node) is using those files, and Bink will leave
them alone.  CopyMail creates the flag just before copying mail for that
node into the outbound directory, and will skip that node's mail if the flag
already exists.  The busy flag is all that is required for CopyMail and
Binkley-Term to correctly hand-shake with each other.  CopyMail creates the
flag files in both the "to" and "from" directories, so it can be used to
copy mail both to and from the "live" Binkley outbound directories.

    The "task" flag is named "TASK.xx" where xx is the task number in
hexadecimal.  All the task flags reside in the "flags" directory, and are
used to show that the task is active.  Binkley-Term creates its task flag
any time it is "connected" to another modem.  The task flag is deleted when
Bink drops through to the BBS or disconnects the line.  CopyMail creates
the task flag at the end of its initialization and deletes it when it
finishes executing.  CopyMail will NOT run if its task flag already exists,
so you can prevent it from copying mail by creating the appropriate task
flag from somewhere else.  Although Binkley-Term maintains its task flag,
the only program that I am aware of that USES the task flag is a system
monitor that displays the currently active task flags on the screen.

    When copying or combining outbound mail files, the flavor of the
outbound file will be the higher priority of the file being copied and any
existing outbound file for the same node address.  The priorities are (from
highest to lowest) Crash, Direct, Normal, and Hold.  Renaming outbound mail
priorities can be turned off using the NORENAME config file option or the
/R command line parameter.  As an example, if a *.DLO file is copied to a
directory which already contains an *.FLO, then the existing *.FLO will be
renamed to *.DLO and the new file appended to it.  If the source was an
*.HUT and an *.DUT already existed, then the *.HUT would be appended to the
existing *.DUT so that the resulting flavor was Direct.  This applies only
to *.?UT and *.?LO files.  The table below shows the "flavor" of the
resulting mail files:

      +----------+------------------------------------------+
      |          |              Existing Mail               |
      |   New    +---------+----------+----------+----------+
      |   Mail   |  Crash  |  Direct  |  Normal  |  Hold    |
      +----------+---------+----------+----------+----------+
      |  Crash   |  Crash  |  Crash   |  Crash   |  Crash   |
      |  Direct  |  Crash  |  Direct  |  Direct  |  Direct  |
      |  Normal  |  Crash  |  Direct  |  Normal  |  Normal  |
      |  Hold    |  Crash  |  Direct  |  Normal  |  Hold    |
      +----------+---------+----------+----------+----------+

    Outbound compressed mail files will be created using the current
day of the week in the file extension.  Old outbound mail bundles which
have been truncated to zero length will be deleted.  Since the compressed
mail bundles are always created with the current day in the file extension,
you can gather several old bundles that were created over a several day
period into a single bundle just by copying them out to a separate directory
and then copying them back to the original one.  This comes in handy if you
are feeding nodes that don't pick up mail often.

    The files you should have received in this package are:

        COPYMAIL.DOC -- This file.
        COPYMAIL.EXE -- Executable program for 8088, 8086, 80186.
        COPYMAIL.286 -- Executable program for 80286, 80386.
        COPYMAIL.CFG -- Sample configuration file.
        COPYMAIL.TXT -- The archive directory with file sizes and checksums.

    To run CopyMail, first edit the sample configuration file (you'll find
additional documentation in the sample).  The default configuration file name
is COPYMAIL.CFG.  CopyMail expects to find this file in the current directory
when it is executed (unless you tell it where to find it on the command line).
If you have a PC or XT type computer, run the COPYMAIL.EXE file.  If you
have an AT or 386, you'll probably want to delete COPYMAIL.EXE and rename
COPYMAIL.286 to COPYMAIL.EXE and use it instead.  When running CopyMail, the
following command line should be used:

    COPYMAIL [flags] [config-file-name]

    The optional flags on the line above may be any of:

        /W   -- To override the config file specification and operate in WAIT
                mode (see the discussion of WAIT and NOWAIT in the config
                file documentation).
        /N   -- To operate in NOWAIT mode.

        /S   -- To open files in DOS's "deny none" file sharing mode.
        /C   -- To open files in DOS's "compatibility" mode.  If using
                COMPATIBLE mode in the config file, it may also be
                necessary to use this command line flag if you also
                specify a config file name on the command line.  (The config
                file documentation contains more information.)

        /O   -- To force the NoOut mode (don't move *.OUT files).

        /Tnn -- To override the config file Task number.  nn is a decimal
                number between 0 and 255.

        /R   -- Don't rename outbound *.?UTs and *.?LOs.

        /H   -- Produces a command line summary.

    The optional config-file-name may provide a complete pathname to be used
for the CopyMail configuration file.  This will override the default name of
COPYMAIL.CFG.

    All command line and configuration file options may be provided in either
upper or lower case.  Pathnames may use either forward or backward slashes to
divide directory names.  Flags may be preceded by either a forward slash or a
hyphen, and may appear either before or after the configuration file name.

    Below, are listed some sample batch file segments which illustrate how
to use CopyMail in a Desqview environment.  DVC is used to open an
additional Desqview window to process inbound mail.  (By the way, CopyMail
has been tested on several different multitaskers and in several LAN
environments, and performs solidly on all that we've tested.  It's
coincidence that the sample below is for Desqview.)  The batch files below
create and test for "dummy" files that are used as signals between different
processes.  The same signaling method shown here will also work in a LAN
environment or with other multitasking software.  Desqview enthusiasts may
prefer using "named" mail boxes, which is also a good approach.

Binkley.Bat:       (mail tossing segment for node 1)

    :Toss
    Remark -- If no mail was received, go back online
    if not exist c:\Bink\Node1\*.* Goto Start

    Remark -- Now copy all of the new stuff to the mail processor
    copy c:\Bink\Node1\*.* c:\Mail\Files
    del  c:\Bink\Node1\*.*

    Remark -- Set a flag to show that new mail has arrived
    echo . >c:\Mail\FlagFile.New

    Remark -- If the mail processor is already running, we're done
    if exist c:\Mail\FlagFile.Bsy Goto Start

    Remark -- Otherwise, set the "Active" flag and start the processor
    echo . >c:\Mail\FlagFile.Bsy
    dvc open c:\dv\mt-pif.dvp
    goto Start

The file MT-PIF.DVP used above is the Desqview program information file that
is used to start the mail batch file shown below.

Mail.Bat

    :Start
    c:
    cd \Mail
    Remark -- Kill the "New Mail" flag
    del c:\Mail\FlagFile.New

    Remark -- Use QMail to process all of the new mail.
    QM Toss Scan Pack

    Remark -- Use CopyMail to give the mail to the mailer's outbound
    CopyMail

    Remark -- Check to see if more mail came in during processing
    if exist c:\Mail\FlagFile.New Goto Start

    Remark -- Kill the "Active" flag and close the window
    del c:\Mail\FlagFile.Bsy
    exit

    Similar use of the "Active" flag can be used to be sure that no mail
is being processed when doing message area maintenance and scanning.  With
only a little work, all routine chores can be handled in the background
leaving nodes on line nearly all of the time.  Using these methods, I have
managed to reduce my offline time to less than 4 percent of the day.

    Another use for CopyMail is to collect mail into a single bundle for
nodes who poll on an infrequent basis.  Because of the way that CopyMail
names the compressed mail bundles when it moves mail, if you copy mail from
your outbound area into a different directory, and then copy it back to
the outbound area, all of the similarly named compressed bundles will be
concatenated into a single bundle.  For example, *.FR?, *.SA? and *.SU? will
all be combined into *.SU0 (if you do this on Sunday).  For mail processors
like QMail that always assume that SU? bundles are older than SA? bundles,
this will ensure that the mail is processed in the correct chronological
sequence.

    I'd like to extend a special "Thank you" to all the folks who have risked
both their mail and reputations to helping me test this program.  Without
their bug reports and fresh ideas, CopyMail would not as good a product as
the one you see.  A special thanks to (in alphabetical order):

        Steve Cross       1:123/19
        Don Dawson        1:141/730
        Bob Germer        1:266/21
        Lawrence Kolada   1:327/452
        George Peace      1:13/13
        Terry Rossi       1:266/22
        John Souvestre    1:396/1
        Dave West         8:952/12

Revision history:

    1.00 -- Initial release.

    1.10 -- NoOut option added.
            Binkley-Term "task" number and file support added.
            Log file formats and messages revised.

    1.20 -- MaxSize support added for outbound bundles.
            ARJ compression support added.
            NORENAME option added.
            Bug in "different compression types" squashed.
            Bug in "task number" resolved.