OS/2 Shareware BBS: 2 BBS/02-BBS.zip/PTKTDOC3.ZIP/OMMM_150.DOC

Text File | 1990-03-19 | 12KB | 267 lines

Documentation supplement for oMMM 1.50

This document is intended to be used in addition to the excellent
oMMM document written by Alan Applegate titled version 1.30.
This document explains the new features for version 1.50, and also
attempts to point out the diffences between 1.50 and prior versions.

HIGHLIGHTS
==========

- Verbs OPUS and BINKLEY are now simply NAKED. Ommm operates in a request
mode compatible with Opus. Use the verb NAKED or option -R to generate file
requests ALA Binkley Style.

- Ommm now defaults to Forwarding messages, and adding to any exisiting bundle
of a different flavor. Therefore making routing verbs ARCADDCM, etc...
obsolete. They are still there and by using the NO_ADD verb or -U options you
can use them. If no one objects, ADD routing verbs will dissapear in a later
release. As for Forwarding messages, use the NO_FORWARD verb (FORWARD verb is
no longer valid) or the -F option.

*** NOTE ***
the -F option now toggles the forwarding setting of Ommm.

- Routing verbs with 'ARC' (except the ADD verbs) are being replaced as
follows:
ARCCM  ==  STUFFCM
ARCDIRECT  ==  STUFFDIR
ARCHOLD  ==  STUFFHOLD
both are valid, but the ARC verbs will disappear in a future release, start
converting.

- Check the OMMM.CFG file, it's now a complete source of whats valid and
what isn't. Also do an OMMM -? for a list of command line options.

- NOTE: OMMM.CFG is REQUIRED!

- Routing now acts as documented.

- ADDRESS verb in OMMM.CFG MUST appear with full specifications as:
  ZZ:TT/NN.PP
  for example:
  ADDRESS 1:109/315.0

- Gone is the -I and Info_path in OMMM.CFG. This will allow OMMM to work with
other mailers.

- The -Z and Zone are gone. Use the ADDRESS verb with zone 0: for no zone
mailing or #: for acting in zone aware mode as the -Z option use to do.

- The -F now toggles mail forwarding (use to be -N).

- The -N now toggles normalizing the outbound area (use to be -F).

- To make file requests with mailers that treat .REQ files as normal mail use
the -R or NAKED verb in OMMM.CFG. This will create 'naked' request files for
mailers like Binkley. If your mailer requires a FLO packet such as Opus, do
not use these options. The -R and NAKED replace -B and Binkley.

- The -B, Binkley and Opus verbs are no longer supported. See the -R and NAKED
verb above.

- ALL routing verbs dealing with ZOO, ZIP, etc... (i.e. ZOOCM, ZI1direct) are
gone. Use the DEFINE_STUFFER and STUFFER verbs for other kinds of ARCMail.

COMMAND LINE OPTIONS
====================

The command line switches are intended to override values set in the
oMMM.CFG file. The only switch which would normally be used is the
-s(schedule) switch.

 -aZ:N/n        use the address Zone:Net/Node as the default
                instead of the first address in the CFG file
 -bOMMM_CFG     alternate configuration file name
 -cROUTEFILE    the file with routing information
 -f             Toggles forwarding messages from other nodes
 -g             tells oMMM to gate route interzone messages
 -hHOLDPATH     the outbound directory for the OUT/FLO files
 -mMESSAGEPATH  the directory containing netmail messages
 -n             Toggles normalizing 'no-send' packets
 -o             tells oMMM to use the old .MO? extensions and not .TU1, etc.
 -pPRESCANPATH  the file with routing information to be used
                before message scanning takes place
 -q             tells oMMM to run quietly (and marginally faster)
 -r             tells oMMM to make naked file requests
 -sSCHED        a single character for this schedule tag
 -tDAYS         delete bundles more than 'DAYS' days old
 -u             tells oMMM not to add to exisiting bundles.
 -xSIZE         maximum bundle size in kbytes (default 512k).

FILE COMPRESSOR SUPPORT
=======================

oMMM now supports any file compressor that's out there, as long as
that compressor's command line adheres to the following convention:

   name <options> compressed_file_name filename_to_be_compressed

All you have to do is define it in the CFG file, and declare which
nodes are to be bundled by that file compressor.

The advantages of using this method are:
 1.     No need for separate routing verbs for each compressor.
 2.     Compression type is specified for each node only once. This
        eliminates the chance of overlooking a node which may be declared
        in more than one place in the route file.
 3.     Users can add a new compressor without any source code changes.

When stuffers are declared the arce/pkarc switch is ignored, and
the first STUFFER declared will be used as the default. This allows you
to have a default other than ARCE or PKARC. Be careful here, since many
nodes cannot support other file compressors.


syntax: DEFINE_STUFFER <tag> <dos command line and arguments>

       This statement is used in conjunction with the STUFFER command.
       The tag must be unique, since it is used in the STUFFER command
       to identify the compressor. The tag can be anything you want.

       The dos command line and arguments is the same one you would use
       to invoke the file compressor from the dos prompt or in a bat file,
       to add a file to the compressed file (which may have to be created).
       Do not specify the option to delete the file once it's added, since
       oMMM will delete the packet only if the compressor returns a result
       code of 0.

       The first STUFFER defined will be used as the default STUFFER.
       This means that any node declared in the route file as receiving
       compressed bundles (ARCxxx or ONExxx) and not specified in any
       of the STUFFER statements, will be compressed by the first
       DEFINE_STUFFER statement found in the CFG file.


        WARNING!!!!!
        YOU DO NOT WANT TO CREATED "MIXED" BUNDLES. SOME COMPRESSORS
        WILL BLINDLY ADD TO A COMPRESSED FILE CREATED BY ANOTHER
        COMPRESSOR, WHICH "GRUNGES" THE FILE, SINCE NO COMPRESSOR CAN
        DE-COMPRESS IT. THE BEST TIME TO ADD OR CHANGE A FILE COMPRESSOR
        FOR A GIVEN NODE IS WHEN THERE IS NOTHING IN THE OUTBOUND DIRECTORY
        FOR THAT NODE. IF YOU CHANGE THE COMPRESSOR FOR A NODE, AND THERE
        IS A BUNDLE FOR THAT NODE IN THE OUTBOUND, YOU MUST MANUALLY
        UNCOMPRESS THAT BUNDLE WITH THE OLD COMPRESSOR, AND THEN COMPRESS
        ALL THE PACKETS WITH THE NEW COMPRESSOR.


syntax: STUFFER <tag> <[zone:][net/]node ...>

        Declare which nodes are to be bundled by one of the compressors
        defined. The tag must be the same declared in one of the
        DEFINE_STUFFER statements. There is no limit on # of nodes that
        can be declared for any stuffer, other than a line length limit
        of 512 characters per line. Therefore a tag may be used more
        than once.  If no zone is declared, the default zone will be used.
        Shorthand net/nodes may also be used.



Here is an example of the STUFFER declarations for the .CFG file:


Define_Stuffer  ARCA    arca
Define_Stuffer  PKARC   pkarc -oct a
Define_Stuffer  PAK     pak a
Define_Stuffer  ZOO     zoo -add
Define_Stuffer  ZIP     pkzip -a
Define_Stuffer  LHARC   lharc a /m

Stuffer  LHARC  307/1 7 381/48
Stuffer  PKARC  114/23
Stuffer  ZIP    103/501 114/18 30 33 36 45 47 58 115/876 128/40 303/3 307/9
Stuffer  ZIP    308/30 309/2 3 104/312 300/11 15/13 305/103
Stuffer  PAK    114/80
Stuffer  ZOO    3:123/456
Stuffer  ARCA   2:123/4567


Thanks to Jeffrey J. Nonken for the following features.

BUNDLE SIZE LIMIT
=================

oMMM  1.50   now  has  a way of  limiting  bundle  sizes  and  of
automatically deleting unsent bundles after a certain date. There
are limitations to both these functions, however.

Size limit: you can invoke a packet size limit by including a  -x
parameter  on  the command line or the keyword  'maxarc'  in  the
configuration  file.  Follow the keyword or  the  parameter  with
the  desired  limit size in kilobytes. For example, if  you  wish
packets to be limited to 256 kilobytes, do this:
     oMMM -x256 ...
If  you leave the number off the command line, or if you  specify
less than 1, it will default to 512k.

When oMMM 1.40 compresses and exports a packet, it simply adds it
to the first existing bundle it finds; or if there is a truncated
packet,  it  deletes the old one, increments the  extention,  and
starts a new one. oMMM 1.50 , however, looks for several  bundles
and  appends  only to the last one, if it  exists,  deleting  all
truncated bundles. If the packet size limitation option has  been
invoked, oMMM 1.50  will check the bundle size before  appending;
if  it is too large, oMMM will create a new bundle and add it  to
the outbound list.

oMMM 1.50  does not actively limit the bundle size; if the packet
it  adds  brings the bundle size over the requested  size  limit,
oMMM  will not attempt to do anything about it. oMMM will  simply
not  add to a bundle that already meets or exceeds the  requested
size limit. It is up to the export program to limit packet sizes.

oMMM  will use the .MO?, .TU?, .WE? extension  naming  convention
for bundles unless the sysop overrides with the -o parameter,  in
which  case oMMM only uses the .MO? extension. However, when  the
size  limit  feature is invoked, if the bundle .MO9  exceeds  the
size limit, oMMM will override the -o parameter and name the next
bundle  .TU0.  This ONLY happens if the bundle exceeds  the  size
limit.

In  the  unlikely event that 69 of the 70  possible  bundles  get
filled up, oMMM will override the size limit feature and continue
to append to the last bundle. (This has not been tested.)

KILL OLD BUNDLES
================

Old bundles: if you have a system that fails to pick up its  mail
regularly, you may want to automatically delete its old  bundles.
oMMM  will  not  seek these out, but if it finds  an  old  bundle
destined  for  a  system it's processing,  it  can  automatically
delete  it for you. This is especially useful for a  system  that
gets sent mail regularly, when you have a bundle size  limitation
set. Invoke the automatic 'timed' deletion with the -t  parameter
on  the  command  line, or with the keyword  'oldbundle'  in  the
configuration  file, followed by the number of days you  want  to
wait before deleting. For example:
     oMMM -t7 ...
This causes oMMM to delete any bundle it finds that is more  than
seven  days old. If you specify less than 1 it will default to  7
days.

Because of the way this function is implemented, if the bundle in the
example  is as much as 7 days and 1 second old, oMMM will  delete
it.  So  you could see oMMM delete one bundle that has  the  same
date stamp as another that it leaves alone.

Again,  oMMM  does  not actively seek out old  bundles.  It  only
checks  the  dates  of existing bundles that  it  happens  to  be
processing. However, if it finds a single bundle that is too old,
it  will delete it and then re-use its name for the  new  packet.
Since  the  intended recipient never got the  deleted  bundle,  I
cannot  think  of  any practical reason to  increment  the  name.
However, if it bothers enough people, I will go ahead and add the
code to do that.

There is an extremely unlikely situation that could come up: oMMM
finds  there are 69 bundle names used, the last one  exceeds  the
size limitation, and there is at least one aged bundle. oMMM will
delete the aged bundle(s) and append to the last one, even though
it  is oversized. (The next time oMMM is run it will  find  there
are  less than 69 bundles used and create a new one.) This is  an
artifact  of  the  structure of the  code,  and  considering  how
unlikely  an  occurrance this is, I refuse to bother to  make  it
work differently.