home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Professional
/
OS2PRO194.ISO
/
os2
/
com
/
bbs
/
ommm
/
ommm_150.doc
< prev
next >
Wrap
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.