OS/2 Shareware BBS: 2 BBS

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / PTKTDOC3.ZIP / OMMM.DOC < prev next >

Wrap

Text File | 1989-01-18 | 80KB | 1,826 lines

+---+ | | | |====================+ \ \ | | / / \ +---+ / oMMM The Opus Matrix Message Masher A Mail Processing and Routing Program for Opus-CBCS and BinkleyTerm Systems Version 1.30 January 21, 1989 Software Written by Marshall Presnell and Jim Nutt Based on Bob Hartman's Original Code From a Concept and Framework Coded by Wynn Wagner Documentation Written and Hacked by Alan Applegate Under the Influence of Homebrew Some Segments From "MATRIX.DOC" Copyright (C) 1987, Wynn Wagner, All Rights Reserved Used by Permission Software Copyright (C) 1988, 1989 BS Software Documentation Copyright (C) 1988, 1989 Alan D. Applegate All Rights of the Copyright Holders Strictly Reserved Use and Distribution Allowed Only in Accordance With the Terms Listed Herein Multi-Zone Operation Section by Vince Perriello oMMM Version 1.30 - Page 1 +---+ | | Contents | |====================+ \ \ | | / / \ +---+ / INTRODUCTION 2 STUFF AND NONSENSE 3 What You Can and Cannot Do 3 Acknowledgements 4 SPECIAL NOTICES 5 Regarding ARCmail 5 Regarding ZOOmail 5 Politics 5 Regarding Archiving Programs 5 TECHNORATA 6 How Mail is Handled 6 A Sample Message, Start to Finish 9 The Concept of Cost 10 More on File Names 10 Other Files 11 What oMMM Does 13 HOW TO 15 Making it Mash 15 Control File Parameters 15 Leave Related Commands 16 General Commands 17 Mail Routing - Direct Flavor Commands 19 - Hold Flavor Commands 20 - Continuous Flavor Commands 22 ZOOmail Command Differences 24 Add Command Modifiers 24 oMMM Command Line Options 25 OMMM.CFG Configuration File 28 EXAMPLES 29 Sample oMMM Control File for BinkleyTerm and Opus 1.1x 29 Sample oMMM Control File for Opus 1.0x 29 MULTI-ZONE SUPPORT 31 General Information 31 oMMM Version 1.30 - Page 2 +---+ | | Introduction | |====================+ \ \ | | / / \ +---+ / oMMM, the Opus Matrix Message Masher (hence the mallet illustration) is a mail processing and routing program originally intended for use with Opus-CBCS, a FidoNet compatible BBS package. oMMM is also used in conjunction with BinkleyTerm, a FidoNet compatible mail interface package. oMMM performs several tasks, including packing of NetMail, archiving of mail into "ARCmail" packets, routing of outbound mail, re-routing of pending outbound mail, and more. This documentation is divided into three primary sections: TECHNORATA A technical description of mail operation and how oMMM affects that process. HOW TO What oMMM's various functions are, and how they are used. EXAMPLES Situations you may encounter, and practical ways to handle them. There are other sections as well. Please refer to the Contents page for a complete listing. NOTE! This documentation does not go out of its way to explain new concepts or terminology. The documentation for your system (Opus-CBCS or BinkleyTerm) should serve as your main reference. oMMM Version 1.30 - Page 3 +---+ | | Stuff and Nonsense | |====================+ \ \ | | / / \ +---+ / WHAT YOU CAN AND CAN'T DO The license for the oMMM software is contained separately in the oMMM distribution package. The following pertains ONLY to the documentation. This oMMM documentation is a copyrighted, creative work. The rights to it are owned exclusively by the author, who provides a limited license granting certain rights which may be altered or revoked at any time. You are licensed to use and distribute the oMMM documentation under these terms: - The documentation must not be altered and subsequently distributed to others. - No profit may be realized directly from its distribution. So-called "pay systems" who offer it for download may levy their normal charge. - If the documentation is to be distributed in hard copy form, the hard copy must be for personal use, or limited to non-profit uses only. - No rights whatsoever are granted to reproduce this document for profit in any form, in whole or part, except as provided herein. - No rights whatsoever are granted to reproduce any portion of this documentation as part of another work without the express, written permission of the author, except as provided by Federal Copyright Laws, and applicable international treaties. - All translation rights are retained by the author. For further clarification or information regarding this license, or to obtain a license for a specific purpose please write: oMMM Documentation Alan D. Applegate P. O. Box 260723 Lakewood, CO 80226-0723 oMMM Version 1.30 - Page 4 ACKNOWLEDGEMENTS The following names are either trademarks of and/or the efforts of the person and/or organization given: Fido, FidoNet - Tom Jennings, Fido Software ARCmail, ARC - Thom Henderson, System Enhancement Associates, Inc. Opus-CBCS - Wynn Wagner BinkleyTerm - Bit Bucket Software XlaxNode - Scott Samet XlatList - Thom Henderson, System Enhancement Associates, Inc. ConfMail, ParseLst - Bob Hartman, Spark Software Inc., Sirius - Bob Klahn, Micro Solutions QuickBBS - Adam Hudson ARCA, ARCE - Vernon Buerg, Wayne Chin, System Enhancement Associates, Inc. PKARC, PKXARC, PKPAK, PKUNPAK - Phil Katz, PKware, Inc. ZOO - Rahul Dhesi OOPS - Tom Kashuba AMAX - Alan Applegate oMMM Version 1.30 - Page 5 +---+ | | Special Notices | |====================+ \ \ | | / / \ +---+ / REGARDING ARCMAIL "ARCmail" is a trademark of System Enhancement Associates, Inc., for their FidoNet compatible mail processing program of the same name. oMMM is capable of producing compressed mail of a type compatible with that of the ARCmail program. We use the term "ARCmail" within this documentation to avoid the use of other, longer terms, and to avoid confusion with ZOOmail, another type of compressed mail. No rights are claimed by use of the term "ARCmail" within this documentation. All appearances of the term "ARCmail" herein should be construed to mean "ARCmail compatible" without any implied reference to the ARCmail program. REGARDING ZOOMAIL oMMM now provides ZOOmail compatibility. ZOOmail, like ARCmail, is compressed FidoNet compatible packets, named in a consistent and recognized manner. The oMMM implementation of ZOOmail follows the same naming convention as oMMM uses for ARCmail. The only difference is that the ZOO compression utility is used to create the finished product, rather than an ARC-compatible compression utility. This ZOOmail functionality is provided for compatibility with other influential ZOOmail implementations that have been implemented or are planned. No political statement is implied by the implementation of ZOOmail in oMMM. POLITICS It is the earnest desire of the current developers and documenters of oMMM to avoid participation as a unit in actions or choices regarding the oMMM package which are motivated by network politics. Statements by persons associated with oMMM development are strictly the opinion of the individual, and may or may not reflect the opinion of other persons associated with oMMM development. REGARDING ARCHIVING PROGRAMS In recognition of the wide variety of needs, desires and opinions within FidoNet and compatible networks, oMMM endeavors to provide the widest possible choice of archiving programs for use in creating compressed mail. oMMM is capable of using ARCA by V. Buerg, PKARC/PKPAK (in "compatibility" mode) by P. Katz, and ZOO by R. Dhesi. No recommendation is made by the developers, and none should be construed by any statements made herein. ARCmail and ZOOmail are often referred to by the term "compressed mail." oMMM Version 1.30 - Page 6 +---+ | | Technorata | |====================+ \ \ | | / / \ +---+ / HOW MAIL IS HANDLED In order to understand what oMMM is supposed to do, it's important to have a working knowledge of the concepts involved with mail handling for Opus-CBCS and BinkleyTerm. Understanding the concepts is easy if you're new to FidoNet, and this is your first experience with handling FidoNet mail. However, if you're a "grizzled veteran" of FidoNet, and have experience with other FidoNet compatible mailers or BBS packages, then the following box contains everything you should remember about the way other programs handle mail: +-------------------------------------------+ | | | | | | | | | | +-------------------------------------------+ In this section, the term "your system" is implied to mean Opus- CBCS or BinkleyTerm, the two mailer systems that use oMMM at this writing. Sending outbound mail with your system is fairly simple. If you are a complete neophyte, this section is intended to give you an understanding of the concepts involved. It is suggested reading even if you think you know all about FidoNet mail handling. IDEA #1. Mail events are less important than they are with other mailing methods and systems. With your system, you paint a wide brush telling the system what to do with 'classes' of remote systems. When systems handled mail only at specific times, routing and times were of great importance. Because more and more systems can process mail at any time (including yours), the idea of a schedule become less important. The item of prime importance with your system is COST. We are going to try and relieve you of the tedious details of scheduling, and concentrate on doing things for the least cost. More on this later. IDEA #2. Another new idea deals with the way that packets are created. If you have used other mailer systems, you're probably used to seeing packets generated several times. With some programs, oMMM Version 1.30 - Page 7 packets are built every time a mail schedule starts. As a result, one message may be put into a packet several times. With your system, packets are built once by an external program called oMMM. They may be remarked and rerouted once they're built, but they are physically built only once, and placed in a special sub-directory called the outbound holding area. IDEA #3. Your system uses 'Continuous Mail.' If you are already using a program that supports 'Crash Mail' then you understand a little of what Continuous Mail does. Continuous Mail differs from Crash Mail in a couple of areas. In other mailer systems, you would mark a message as 'Crash' meaning that you wanted this message to go out NOW. These mailer programs would shut down human caller access to the BBS and try ardently to get the message through. Your system uses Continuous Mail, meaning that this is a message going to a system that can accept mail at any time of day. Your system makes no frantic attempts to dial out, rather it will try and deliver the message between incoming calls. IDEA #4. The driving forces of outbound traffic are file names! This is very important to understand, so read carefully. You'll have a special sub-directory set aside just for packets (processed outbound messages), ARCmail (or ZOOmail) packets and other outbound network files. The sub-directory belongs to your system, which will maintain the directory for you. It's a good idea not to play with this area unless you know exactly what you're doing. As we mentioned before, packets are created only once, and are placed in your outbound area for holding until they are sent. Your system differentiates between the various files based entirely on file names. oMMM's basic concept is to scan your NetMail message area (for some systems, this may be done by other software), place new messages into packets in your outbound area, then scan the outbound area and rename files according to the oMMM control file. That's right, one of oMMM's major functions is renaming files. oMMM also may append a new outbound message onto the end of an existing packet, or add additional packets to existing compressed mail packets. The file names of the packets tell your system how to treat the different packets. Here's a typical packet name: 00680024.OUT That says that the packet is for 0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The ".OUT" means it is a Normal oMMM Version 1.30 - Page 8 packet. Packet extensions are: .OUT . . . Normal, meaning that this packet hasn't been processed by oMMM yet. If left unprocessed, it will be treated the same as a .DUT packet. .HUT . . . Hold this packet for pickup by the remote system. .CUT . . . The other system can receive Continuous Mail. .DUT . . . Direct, meaning the other system can NOT receive Continuous Mail. One nice thing is that you can manually change the file extensions if you need to, or you can use fancy utilities such as OOPS and AMAX to do this sort of thing for you. By changing the file extension, you change the "flavor" of the packet. The oMMM program knows about these extensions and creates them based on information you put into the oMMM control file. You'll have statements like: NormHold 124/102 Any messages you enter to 124/102 would be turned into a .HUT packet file, placed in the outbound area, and your system would hold that packet for 124/102 to call and pickup. oMMM control file statements are covered in detail later in this document. Files are also sent through FidoNet. oMMM builds and maintains a file that tells Opus or BinkleyTerm what files to send (or hold) for whom. A typical 'file attach' file might be named: 00680024.FLO This would designate that there is a file waiting to be sent to 0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The ".FLO" says it is a Normal file attach. File attach files are also called 'flow files' after the .FLO file extension. Flow file extensions are: .FLO . . . Normal, meaning that this flow file hasn't been processed by oMMM yet. If left unprocessed, it will be treated the same as a .DLO flow file. .HLO . . . Hold these files for pickup by the remote system. .CLO . . . The other system can receive Continuous Mail. .DLO . . . Direct, meaning the other system can NOT receive Continuous Mail. A flow file is just a flat ASCII text file. It contains a list of files that are to be send to (or held for) another system: #c:\binkley\outbound\0000fc9c.mo1 c:\pascal\notes.doc oMMM Version 1.30 - Page 9 The '#' prior to a flow file entry says to truncate the file to zero-length after successfully sending the file to the remote system. This is normally only employed when sending compressed mail to the remote. Once the mail is sent, you don't need it anymore, so the file is truncated. Files may also be deleted after they are sent by preceding the file entry in a flow file with a carat (^) sign. This is not compatible with early versions your system. The oMMM program will also put messages into archives for you. Details on how this is done can be found later in this documentation. The point is that oMMM combines the functionality of "generating packets" with that of programs like ARCmail. A SAMPLE MESSAGE, START TO FINISH So here's a practical example. Say I enter a message to Rod Lamping at 104/610. I mark the message as KILL/SENT when I enter it. I also enter the message designating a file to attach to Rod, named C:\FILE\REQ\PARSELST.ARC. I then enter a message in an EchoMail conference. My conference host is Phil Kaiser at 104/904. I hold my mail for his system to call and pickup. Among other things, I have two lines in my oMMM control file that tell my system how to handle mail addressed to Phil and Rod: NormCM 104/610 OneHold 104/904 'NormCM' tells oMMM to mark the message as Continuous Mail (since Rod runs a mailer 24 hours a day). 'OneHold' tells oMMM to both archive the mail to 104/904, and mark it Hold-for-Pickup. NOTE: Don't worry! You won't have to list each node individually in your control file. Only systems that require special handling need to be listed. Other oMMM control file statements handle broad groups of nodes, essentially by designating default settings. First, my EchoMail utilities are run to turn EchoMail messages into Normal packets, and place them in the outbound area for processing by oMMM. This may be handled by my system (in the case of a bare Opus), by a utility that comes with my system (in the case of QuickBBS) or by other enhanced utilities available separately (such as ConfMail). Next, I execute oMMM. It first scans the NetMail message area (where I entered my message to Rod) and turns new messages there into Normal packets, and if there are files attached, it creates Normal flow files. oMMM's second step is to use its control oMMM Version 1.30 - Page 10 file, and apply the statements in the file against the mail in the outbound area, renaming or appending outbound files as needed. Since I have Rod's board listed as NormCM, oMMM renames the file extension of the Normal packet and flow file for Rod to .CUT and .CLO respectively, for Continuous Mail. My system will attempt to send the message and file to Rod as soon as possible. Since I have Phil's board listed as OneHold, first oMMM archives the packets to Phil, then creates a flow file with a file extension of .HLO for Hold-for-Pickup. My system will wait for Phil's system to call me (poll), and will only then release the ARCmail to Phil. I would then have the following in my outbound area: 00680262.CUT Message to Rod. 00680262.CLO Flow File to Rod. It lists the file I wanted to send him, C:\FILE\REQ\PARSELST.ARC. 00680388.HLO Flow File to Phil. It lists the ARCmail file that I'm sending him. 0000FC9C.MO1 Compressed Mail Message to Phil. More information about the various oMMM control file statements is given later in this documentation. THE CONCEPT OF COST As mentioned earlier, one of the prime considerations with your system is sending mail for the least cost. Cost is, of course, determined by the nodelist entry. With a properly compiled nodelist, local FidoNet nodes have '0' in the cost field for their nodelist entry (assuming local calls are free of charge). Other entries have cost fields that realistically reflect the actual cost of sending mail to a particular node. In most areas, it is cheapest to send toll calls at night. Therefore, your system is normally set-up to send such mail only at night. The event scheduling facilities built into your system have the functionality to create events that are 'local only.' As already mentioned, nodes with a '0' cost field are assumed to be local. When an event is local only, only zero-cost calls are made. A local only event should be used whenever it costs the most money to make toll calls, and removed for events during which toll calls are cheapest. More about this is in the documentation for your system. Cost and the limitations on cost that you set for a given schedule will always override any message marking, i.e., Normal, Direct, Continuous Mail. MORE ON FILE NAMES As mentioned previously, one of the driving forces behind mail oMMM Version 1.30 - Page 11 handling for your system is file names. Your system uses the names to determine what to send to whom, and in conjunction with your event scheduling, when it should be sent. There are four types or "flavors" that can be used to describe various forms of packets or flow files (attaches). We've covered these concepts already, but here's more detail. Remember, file names are one of the driving forces of outbound mail! NORMAL is the default flavor of packets and attaches. oMMM may build Normal packets and attaches and place them in your outbound area as it scans your NetMail message area (does not apply to systems such as QuickBBS). EchoMail utilities such as ConfMail may also place Normal packets in the outbound area. Packets and attaches will stay marked as Normal until one of oMMM's statement affects a particular packet or attach, as described later. If for some reason a Normal packet or attach does not get remarked to another flavor, it will be handled in the same manner as a Direct packet or attach. DIRECT packets and attaches started life as Normal, and were remarked as Direct by one of oMMM's control file statements. Direct packets and attaches are destined for systems that CANNOT accept Continuous Mail. Such systems include Fido 11w that functionally cannot accept Continuous Mail. Also included are any systems that by choice of the system operator are not on-line 24 hours a day. Mail must be sent to these systems during pre- defined mail hours, such as FidoNet's National Mail Hour at 9:00 UTC (GMT). In the raw FidoNet nodelist, such system are typically designated with a '#09' flag. CONTINUOUS MAIL packets and attaches also started life as Normal, and were remarked as Continuous Mail by one of oMMM's control file statements. Continuous Mail packets and attaches are destined for systems that are functionally able to accept incoming mail at any time. These system include Opus, BinkleyTerm, Fido 12, SEAdog, D'Bridge, FrontDoor, Dutchie and others. Continuous Mail is sent to any nodes listed with a '#CM' flag in the raw nodelist. HOLD packets and attaches also started life as Normal, and were remarked as Hold by one of oMMM's control file statements. Hold packets and attaches are destined for systems that must call your system to pick-up their mail. Under no circumstances will Hold packets and attaches be sent by your system. The only way that they can reach their destination is by having the destination system call your system directly. OTHER FILES Also in your outbound area are three more types of files. The first type is compressed mail packets. Compressed mail packets are message packets that have been placed into compressed, archived form for faster sending and disk space economy. oMMM Version 1.30 - Page 12 Although any outbound messages may be compressed, it's primarily employed for EchoMail, which typically involves a significant message volume. oMMM creates ARCmail packets using the ARCA program or PKARC, commonly available archiving utilities (see the section on oMMM's command line for more information). For ZOOmail, oMMM uses the ZOO utility. Should EchoMail need to be sent to a system that does not support ARCmail or ZOOmail, then the outgoing EchoMail would be represented by regular message packets. This is controlled entirely with oMMM control file statements. Compressed mail packets are named in a similar manner to packets and attaches. The first four digits represent a net number, the last four represent a node number. But with compressed mail, the representation is not of the destination address, but the difference between your address and the destination address. For example, if you were at 104/36, and had an outbound ARCmail packet for 104/56, the packet would be named 00000014.???, because the difference between the net numbers is 0 (the first four digits) and the difference between the node numbers is 20, represented in hexadecimal as 14 (the last four digits). File extensions created and used by oMMM are consistent with SEA's original ARCmail program. The first two digits of the file extension are MO, TU, WE, TH, FR, SA and SU, the last digit is a single number, 0 through 9. Originally, the first two digits of the extension corresponded to the day of the week the packet was created. oMMM does not follow this convention exactly; details about the procedure are given in the section on how to use oMMM. The second type of file is a call progress entry. This file is named in the same manner that packets and attaches are, except that the file extension is .$$? - the last digit being a single number. This file is used by Opus-CBCS and/or BinkleyTerm to determine how many times a system has been called, and how successful the call(s) have been. The last digit of the file extension indicates how many times a bad connect has occurred with the destination system. These bad connects are when the destination system has answered, but session was not established. In long distance cases, these bad connects are billable calls (both Opus-CBCS and BinkleyTerm have ways of limiting the number of bad connects). The call progress file is two bytes long. The two bytes represent an integer value of the number of call attempts that have been made. These attempts ended with a busy signal or no answer status, and are typically not billable calls. Call progress entries are established, maintained and deleted by the software (Opus-CBCS or BinkleyTerm). The files can safely be manually deleted; once the limit of bad connects has been reached, deleting the call progress file is the only way to make the software again dial out to the given destination system. In Opus, this is known as "clearing undialables." Finally, the third file is an outbound request file. It is named oMMM Version 1.30 - Page 13 in the same manner that packets and attaches are, except that the file extension is .REQ. Inside the file is the name of a file to be requested from the destination system. The file can contain more than one filename; each filename is shown on a separate line. These files can be generated manually, but are typically produced by some sort of utility designed for the purpose. Once the system has been dialed and the request given, the file is deleted. Typically, .REQ files are treated in the same manner as .OUT files. In other words, an .REQ file would prompt your software to dial out under the same circumstances as it would for a .OUT file. If you want the request to made sooner, a null packet or attach must be created with the desired "flavor" to make the system dial out sooner (many utilities that build .REQ files also build this null file). You can also manually poll the destination system to force the request to be passed. WHAT OMMM DOES oMMM has a host of integrated functions. Most of the functions are controlled by a separate text control file, discussed later, and/or by command line parameters. As mentioned previously, the software you use will generally build .OUT and/or .FLO files and place them in the outbound area. oMMM may also build these files as it scans your NetMail message area. Once the .OUT and .FLO files are in place, oMMM changes the files to implement routing of outbound messages (host routing, discussed earlier, or other routing arrangements) and to change the "flavor" of existing files to that which you specify. Your software will also place packets of EchoMail in the outbound area; oMMM may use ARCA, PKARC or ZOO to create compressed mail if you instruct it to do so. oMMM follows a series of instructions that you give it with a control file, typically named OMMM.CTL. The commands that can be used in this file are given later. Of equal importance are the command line arguments used when oMMM is invoked, which are also discussed later. Typically, oMMM is invoked by way of a batch file, the same one you use to start your system. oMMM should be invoked after entering a NetMail message, and after EchoMail scanning has been performed (if you run EchoMail on your system). How you accomplish the invoking of oMMM is up to you. Refer to your system's documentation for information on setting-up your batch file. When invoked, oMMM first uses the information in a "pre- processing" control file, if any, and applies the information against the files in your outbound area. Next, oMMM scans your NetMail (Matrix) message area as given on the command line. New messages are packed into .OUT files and placed into the outbound oMMM Version 1.30 - Page 14 area, and the "sent" flag of the message is set (so oMMM won't send it again). Note that if the Kill/Sent flag of the message is set, the message will be deleted once oMMM creates a packet and/or attach for the message. If the message has the file attach flag set, oMMM will build a .FLO attach file, pointing to the file that you specified when the message was entered. If the message has the file request flag set, oMMM will build a .REQ file containing the name of the file you specified when you entered the message. NOTE: Message "flags" should be explained more thoroughly in the documentation for the program you use for entering your messages, i.e., Opus, Sirius, etc. Finally, oMMM uses the regular control file, and applies the information against the files in your outbound area. This main control file contains routing information and instructions for oMMM to process your mail correctly. Based on information you place in the control file, oMMM is capable of archiving mail, changing mail from one flavor to another (i.e., Continuous to Normal, Normal to Hold, etc.), host routing .OUT files, etc. oMMM can mark particular packets or attaches as "leave" meaning that your system will completely ignore their presence. Of course, oMMM is capable of reversing the "leave" marking as well. One of the most useful features of oMMM is the ability to make it use some control file commands at one time of the day, and another set of control file commands at another time of day. This is the schedule feature of oMMM, and shouldn't be confused with the scheduling of events on your system (although they work in conjunction with each other). You communicate the schedule oMMM is supposed to use at the oMMM command line. Therefore, you may wish to invoke oMMM with different command lines at different times, something that can be accomplished by using the scheduling capabilities of your software. Examples of this confusing concept are given in the examples section. oMMM Version 1.30 - Page 15 +---+ | | How To | |====================+ \ \ | | / / \ +---+ / MAKING IT MASH So how do you make oMMM do its thing? First is the control file. Typically, a pre-processing file (as mentioned above) is NOT used. You'll be able to judge this for yourself after using oMMM and analyzing your own situation. The control file commands that are about to be described apply to both the pre-processing and main control files, however. The only difference between the pre-processing control file and the primary control file is when the information is used and applied to your outbound mail. Remember, when oMMM is invoked, it first uses and applies the information in the pre-processing control file, THEN it scans your NetMail message area, THEN it uses and applies the information in the primary control file. The control file information is used and applied in the order it appears within the file. The control file is standard ASCII text, one instruction per line. You can edit or create the file with any common text editor, such as DOS' own EDLIN command. If you are planning on having oMMM create ARCmail, then you must have ARCA or PKARC in the current directory, or on the DOS path (which you use depends on your command line; refer to the section "oMMM Command Line Parameters" for information). If you will be having oMMM create ZOOmail, the ZOO program MUST be on the DOS path. CONTROL FILE PARAMETERS The parameters described in this section apply only to oMMM Version 1.10 or higher. Very early oMMM versions used a different set of parameters. oMMM 1.30 contains some limited changes from previous versions. If you're reading this documentation, one assumes that you also have a current version of oMMM at hand. There are several "global" designators available to you with oMMM. A global is used instead of explicit references to a specific group of systems. Globals available are: WORLD (also possible is "ALL") The word "WORLD" means roughly "all systems." "104/WORLD" for example means "all systems in net 104." This should be used with care to avoid undesired results. oMMM Version 1.30 - Page 16 NET??? Equivalent to the "???/WORLD" statement. If you used "NET104" for example, it would mean "all systems in net 104." OURNET Means "all nodes in my net." If you are located in net 128, for example, "OURNET" would mean "all systems in net 128." OTHERS Means "all nodes NOT in my net." If you are located in net 132, for example, "OTHERS" would mean "all systems NOT in net 132." Now for the control file statements. Below, "syntax" shows the proper usage of the command. "Example" shows a sample control file entry. "Effect" shows the names of the files in your outbound area that are affected, and how they are affected. The second "example" shows how a typical entry would be changed. LEAVE RELATED COMMANDS Leave Mark packets or attaches addressed to node(s) given in <destination(s)...> as "do not send." This will cause your system to COMPLETELY IGNORE this mail in ANY situation. SYNTAX: Leave <destination(s)...> EXAMPLE: Leave 104/36 112/101 EFFECT: xxxxyyyy.?UT to xxxxyyyy.N?T xxxxyyyy.?LO to xxxxyyyy.N?O EXAMPLE: 00680024.CUT to 00680024.NCT 00700065.FLO to 00700065.NFO Send Un-mark all packets or attaches addressed to node(s) given in <destination(s)...> that have previously been marked "do not send" (with the 'Leave' statement) so oMMM Version 1.30 - Page 17 that the system can once again be aware of their presence. SYNTAX: Send <destination(s)...> EXAMPLE: Send 104/36 112/101 EFFECT: xxxxyyyy.N?T to xxxxyyyy.?UT xxxxyyyy.N?O to xxxxyyyy.?LO EXAMPLE: 00680024.NCT to 00680024.CUT 00700065.NFO to 00700065.FLO DoCM Un-mark Continuous Mail packets or attaches addressed to node(s) given in <destination(s)...> that have previously been marked "do not send" (with the 'Leave' statement) so that the system can once again be aware of their presence. Only Continuous Mail packets and/or attaches are affected; all others are left untouched by this statement. SYNTAX: DoCM <destination(s)...> EXAMPLE: DoCM 104/36 EFFECT: xxxxyyyy.NCT to xxxxyyyy.CUT xxxxyyyy.NCO to xxxxyyyy.CLO EXAMPLE: 00680024.NCT to 00680024.CUT GENERAL COMMANDS Poll This creates a dummy .FLO (normal attach) file for the system(s) given in <destination(s)...> if there are no non-Hold packets or attaches already addressed to the given system(s). If there are already Normal, Direct or Continuous Mail packets or attaches addressed to a given system, then no .FLO file will be created ("hold for pick-up" mail does not affect this command). SYNTAX: Poll <destination(s)...> EXAMPLE: Poll 104/36 oMMM Version 1.30 - Page 18 EFFECT: If no xxxxyyyy.[F/C/D]LO or xxxyyyy.[O/C/D]UT file, then create xxxxyyyy.FLO EXAMPLE: If no 00680024.FLO/.CLO/.DLO or 00680024.OUT/.CUT/.DUT file, then create 00680024.FLO HostRoute Host route any remaining Normal packets (.OUT files). Any .OUT files that have not already been affected by an oMMM control file command will be re-addressed (routed) to the host for the destination system's network. Normally, this is the LAST STATEMENT in your oMMM control file (except for 'Poll' statements, they should be VERY LAST, if used). SYNTAX: HostRoute EXAMPLE: HostRoute EFFECT: xxxxyyyy.OUT to xxxx0000.OUT EXAMPLE: 00680024.OUT to 00680000.OUT Password Encrypts ARCmail packets to the system given in <destination> with the password given in <password> during the archiving process. The destination system must not only support ARCmail, but must have their system set-up to un-arc the ARCmail packets with the same password you use. Has no effect on mail other than ARCmail. SYNTAX: PASSWORD <destination> <password> EXAMPLE: PASSWORD 132/101 mypass Sched This statement starts a schedule as named by <tag>. All oMMM statements between the 'Sched' statement and the next 'Sched' statement will be executed only if the tag matches the one given on the oMMM command line (refer to the section "oMMM Command Line Parameters"). The schedule tag is a single letter that can be in upper or lower case. Statements prior to the FIRST 'Sched' statement are executed with every invocation of oMMM, regardless of oMMM Version 1.30 - Page 19 the schedule tag. SYNTAX: SCHED <tag> EXAMPLE: SCHED A MAIL ROUTING - DIRECT FLAVOR COMMANDS ARCDirect Takes .OUT packets addressed to nodes in the <routelist...> and archives them into an ARCmail packet, then builds a Direct attach file addressed the <destination> system. Such usage allows for routing of messages through another system. If no <routelist...> is given, mail to the destination system only will be archived. The destination system must be capable of processing ARCmail. SYNTAX: ARCDirect <destination> [<routelist...>] EXAMPLE: ARCDirect 124/0 124/WORLD EFFECT: xxxxyyyy.OUT to xxxxyyyy.DLO with ARCmail packet also created EXAMPLE: 007C0058.OUT \ 007C000F.OUT > to 007C0000.DLO 007C001D.OUT / with ARCmail packet also created OneDirect Takes .OUT packets addressed to nodes in the <destination(s)...> list and archives them into ARCmail packets, then builds separate Direct attach files addressed to the given system(s). This statement is like 'ARCDirect,' except that NO routing takes place, and all nodes listed have the packets archived into ARCmail INDIVIDUALLY. SYNTAX: OneDirect <destination(s)...> EXAMPLE: OneDirect 104/36 132/101 EFFECT: xxxxyyyy.OUT to xxxxyyyy.DLO with ARCmail packet(s) also created oMMM Version 1.30 - Page 20 EXAMPLE: 00680024.OUT to 00680024.DLO 00840065.OUT to 00840065.DLO with ARCmail packet(s) also created UnDirect Any Direct packets or attaches addressed to the node(s) given in the <destination(s)...> are re-marked Normal. SYNTAX: UnDirect <destination(s)...> EXAMPLE: UnDirect 104/36 132/101 EFFECT: xxxxyyyy.DUT to xxxxyyyy.OUT xxxxyyyy.DLO to xxxxyyyy.FLO EXAMPLE: 00680024.DUT to 00680024.OUT 00840065.DLO to 00840065.FLO NormDirect Any Normal packets or attaches addressed to the node(s) given in the <destination(s)...> are re-marked as Direct. NO archiving is performed. SYNTAX: NormDirect <destination(s)...> EXAMPLE: NormDirect 104/36 132/101 EFFECT: xxxxyyyy.OUT to xxxxyyyy.DUT xxxxyyyy.FLO to xxxxyyyy.DLO EXAMPLE: 00680024.OUT to 00680024.DUT 00840065.FLO to 00840065.DLO MAIL ROUTING - HOLD FLAVOR COMMANDS ARCHold Takes .OUT packets addressed to nodes in the <routelist...> and archives them into an ARCmail packet, then builds a Hold attach file addressed the <destination> system. Such usage allows for routing of messages through another system. If no <routelist...> is given, mail to the destination system only will be archived. The destination system must be capable of processing ARCmail. oMMM Version 1.30 - Page 21 SYNTAX: ARCHold <destination> [<routelist...>] EXAMPLE: ARCHold 124/0 124/WORLD EFFECT: xxxxyyyy.OUT to xxxxyyyy.HLO with ARCmail packet also created EXAMPLE: 007C0058.OUT \ 007C000F.OUT > to 007C0000.HLO 007C001D.OUT / with ARCmail packet also created OneHold Takes .OUT packets addressed to nodes in the <destination(s)...> list and archives them into ARCmail packets, then builds separate Hold attach files addressed to the given system(s). This statement is like 'ARCHold,' except that NO routing takes place, and all nodes listed have the packets archived into ARCmail INDIVIDUALLY. SYNTAX: OneHold <destination(s)...> EXAMPLE: OneHold 104/36 132/101 EFFECT: xxxxyyyy.OUT to xxxxyyyy.HLO with ARCmail packet(s) also created EXAMPLE: 00680024.OUT to 00680024.HLO 00840065.OUT to 00840065.HLO with ARCmail packet(s) also created UnHold Any Hold packets or attaches addressed to the node(s) given in the <destination(s)...> are re-marked Normal. SYNTAX: UnHold <destination(s)...> EXAMPLE: UnHold 104/36 132/101 EFFECT: xxxxyyyy.HUT to xxxxyyyy.OUT xxxxyyyy.HLO to xxxxyyyy.FLO EXAMPLE: 00680024.HUT to 00680024.OUT 00840065.HLO to 00840065.FLO NormHold Any Normal packets or attaches addressed to the node(s) given in the <destination(s)...> are re-marked as Hold. oMMM Version 1.30 - Page 22 NO archiving is performed. SYNTAX: NormHold <destination(s)...> EXAMPLE: NormHold 104/36 132/101 EFFECT: xxxxyyyy.OUT to xxxxyyyy.HUT xxxxyyyy.FLO to xxxxyyyy.HLO EXAMPLE: 00680024.OUT to 00680024.HUT 00840065.FLO to 00840065.HLO MAIL ROUTING - CONTINUOUS FLAVOR COMMANDS ARCCM Takes .OUT packets addressed to nodes in the <routelist...> and archives them into an ARCmail packet, then builds a Continuous Mail attach file addressed the <destination> system. Such usage allows for routing of messages through another system. If no <routelist...> is given, mail to the destination system only will be archived. The destination system must be capable of processing ARCmail. SYNTAX: ARCCM <destination> [<routelist...>] EXAMPLE: ARCCM 124/0 124/WORLD EFFECT: xxxxyyyy.OUT to xxxxyyyy.CLO with ARCmail packet also created EXAMPLE: 007C0058.OUT \ 007C000F.OUT > to 007C0000.CLO 007C001D.OUT / with ARCmail packet also created OneCM Takes .OUT packets addressed to nodes in the <destination(s)...> list and archives them into ARCmail packets, then builds separate Continuous Mail attach files addressed to the given system(s). This statement is like 'ARCCM,' except that NO routing takes place, and all nodes listed have the packets archived into ARCmail INDIVIDUALLY. oMMM Version 1.30 - Page 23 SYNTAX: OneCM <destination(s)...> EXAMPLE: OneCM 104/36 132/101 EFFECT: xxxxyyyy.OUT to xxxxyyyy.CLO with ARCmail packet(s) also created EXAMPLE: 00680024.OUT to 00680024.CLO 00840065.OUT to 00840065.CLO with ARCmail packet(s) also created UnCM Any Continuous Mail packets or attaches addressed to the node(s) given in the <destination(s)...> are re- marked Normal. SYNTAX: UnCM <destination(s)...> EXAMPLE: UnCM 104/36 132/101 EFFECT: xxxxyyyy.CUT to xxxxyyyy.OUT xxxxyyyy.CLO to xxxxyyyy.FLO EXAMPLE: 00680024.CUT to 00680024.OUT 00840065.CLO to 00840065.FLO NormCM Any Normal packets or attaches addressed to the node(s) given in the <destination(s)...> are re-marked as Continuous Mail. NO archiving is performed. SYNTAX: NormCM <destination(s)...> EXAMPLE: NormCM 104/36 132/101 EFFECT: xxxxyyyy.OUT to xxxxyyyy.CUT xxxxyyyy.FLO to xxxxyyyy.CLO EXAMPLE: 00680024.OUT to 00680024.CUT 00840065.FLO to 00840065.CLO oMMM Version 1.30 - Page 24 ZOOMAIL COMMAND DIFFERENCES oMMM now supports ZOOmail. This is compressed mail named in the same manner as ARCmail, but the compression is performed with the ZOO utility by Rahul Dhesi, rather than an ARC-compatible compression utility. To cause oMMM to create ZOOmail rather than ARCmail, certain commands must be used. Rather than list and describe each command separately, the following chart shows the oMMM ARCmail command, then it's ZOOmail counterpart. ARCmail Command ZOOmail Command --------------- --------------- ARCHold ZOOHold ARCDirect ZOODirect ARCCM ZOOCM OneHold Z1Hold OneDirect Z1Direct OneCM Z1CM ADD COMMAND MODIFIERS The Add modifier is a mechanism design ed to provide a measure of control over the number of call (actually, successful net sessions) made to a given node. It is used ONLY with compressed mail statements. Consider the case of a net level EchoMail hub, using AT&T Reach Out America (ROA) hours for most of its work. This node polls his regional hub twice a night, but otherwise has no specific call window to his regional hub. After successfully completing the first poll (or before), his downstream nodes both pick-up and drop-off mail. If the nbet hub is doing immediate mail processing, it will try to call the regional hub again (and again). In the old oMMM environment, there were only two paths to deal with this - pay the piper by making many short calls, or have a tightly regulated schedule with yout upstream node(s). Very often, neither of these options is very attractive. The Add modifier attempts to address this situation. Let's assume the net level hub is 321/109 and the regional 132/101. During ROA timne, 321/109 would use: ZooAddHold 132/101 in his events. At specific times (perhaps 22:00 and ZMH+1), 321/109 would do the following: UnHold 132/101 Poll 132/101 oMMM Version 1.30 - Page 25 Under ideal conditions, this will result in 321/109 making two successful calls to 132/101. Note that the execution of specific oMMM statements (or groups of them) is handled by the 'Sched' statement discussed previously. Here's how it actually works. If you are in an Add type compressed mail statement, and compressed mail already exists, any new mail is simply added to the compressed mail file, and NOTHING is done to the attach (flow) file. If no compressed mail exists, a new compressed mail file is created, and an attach file of the flavor specified in the statement is created also. ARCAddHold would result in an .HLO file, ARCAddCM would result in a .CLO file, etc. In order to use this successfully, one must be VERY careful not to otherwise alter the flavor of nodes so handled in the control file (whether main or prescan), or by any other external process. This means careful thought must be given to the use of ALL, WORLD and other such wildcard global designators, and ANY statements referencing nodes so handled, whether they are compressed mail related or not. The following tables lists oMMM statements which may be modified by 'Add' and what the modified statements are: oMMM Statement Modified Statement -------------- ------------------ ARCHold ARCAddHold ARCDirect ARCAddDirect ARCCM ARCAddCM OneHold OneAddHold OneDirect OneAddDirect OneCM OneAddCM ZOOHold ZOOAddHold ZOODirect ZOOAddDirect ZOOCM ZOOAddCM Z1Hold Z1AddHold Z1Direct Z1AddDirect Z1CM Z1AddCM OMMM COMMAND LINE OPTIONS oMMM is always invoked with a set of command line options. The options tell oMMM various things about your system. If you use 'Sched' statement in your control file, then you tell oMMM what schedule it is by way of the command line. As mentioned earlier, it's up to you to configure your system in such a way as oMMM is called, at the proper times, with the desired command line. oMMM Version 1.30 - Page 26 This is normally accomplished by programming your system to exit to your start-up batch file with various ERRORLEVEL values at the times you designate. The batch file in turn uses the ERRORLEVEL value to decide what to run and how to run it. Samples are shown in the sample section. oMMM can also use an optional OMMM.CFG configuration file, which will be discussed later. Command line options which may be included in OMMM.CFG instead of on the command line are marked with an asterisk (*). oMMM uses a command line in the following format (oMMM must be have all of the command line options on one continuous line; the line is broken here to fit on the page): oMMM -c<filename> -h<path> -i<filename> -m<path> [-p<filename>] [-s<tag>] [-z<zone>] [-a] [-f] [-n] [-o] [-q] [-g] * -c This designates the filename of the primary oMMM control file. This file contains the processing commands outlined in the previous section. A complete path may be given in addition to the filename. This parameter is required. EXAMPLE EXCERPT: -cC:\OPUS\OMMM.CTL * -h This designates the path to the outbound mail holding area. This parameter is required. EXAMPLE EXCERPT: -hC:\OPUS\OUTBOUND * -i This designates the filename of the Opus style parameter file to be used by oMMM. Opus creates this file. For BinkleyTerm systems, the BTCTL utility creates this file. This parameter is required. EXAMPLE EXCERPT: -iC:\OPUS\BINKLEY.PRM * -m This designates the path to your NetMail (Matrix) message area. This area contains Fido compatible messages. This parameter is required. EXAMPLE EXCERPT: -mC:\MSG\NET * -p This designates the filename of the pre-processing oMMM control file. This file contains the processing commands outlined in the previous section. This control file varies from the primary control file in that it is used first (refer to the section "What oMMM Does" for information). This parameter is OPTIONAL. EXAMPLE EXCERPT: -pC:\OPUS\OMMM_ALT.CTL -s This tells oMMM what schedule to execute. The tag oMMM Version 1.30 - Page 27 given corresponds to the tag(s) given with the 'Sched' statement in the control file. This parameter is OPTIONAL. EXAMPLE EXCERPT: -sA * -a Instructs oMMM to use PKARC for archiving of ARCmail packets instead of ARCA (default). oMMM must be able to find the archiving program (regardless of "-a" setting) in the current directory or by a previously set DOS path. If "-a" is used, oMMM will use PKARC's "-oct" command line switch to force compatibility with older archiving methods (occurs automatically). NOTE! If you use PKPAK, you must rename it to PKARC, or have a renamed copy available. * -z This tells oMMM your zone number. If used, this will cause oMMM to operate in zone smart mode, and messages to other zones will be placed in their own outbound area, as expected by BinkleyTerm and Opus 1.1x. Users of Opus 1.0x should NOT use this switch. EXAMPLE EXCERPT: -z1 -f This tells oMMM to un-mark all packets and attaches that have been marked as "no-send" (by the 'Leave' statement of the control file) so that the system knows of their existence once again. This is a global version of the 'Send' control file statement. * -n This tells oMMM not to forward messages that are "in- transit." These are messages addressed to systems other than your own that have been routed to you from other nodes. * -o Tells oMMM to name ARCmail using file extensions of .MO? only (like older oMMM versions). Without the "-o" switch, oMMM uses file extensions of.MO1, .MO2, ... .SU9, .SU0, in sequence, then wraps around to .MO1 again. This follows the style used by ConfMail and other EchoMail utilities, except that the file extension does not necessarily correspond to the day of the week. -q Tells oMMM to operate in "quiet mode," producing marginally faster processing throughput. * -g Tells oMMM to gate route inter-zone messages. This means that messages to other zone will be routed through established zone gateways within your own zone. oMMM Version 1.30 - Page 28 OMMM.CFG CONFIGURATION FILE Some of the command line options, as previously mentioned, can be stored in a stand-alone, raw text configuration file. This file can be created or edited with any standard text editor, such as DOS' own EDLIN command. A sample OMMM.CFG configuration file comes with the oMMM distribution package. The sample file includes all possible statements that may be included in the file, including proper syntax. Refer to that file for information. oMMM Version 1.30 - Page 29 +---+ | | Examples | |====================+ \ \ | | / / \ +---+ / SAMPLE OMMM CONTROL FILE FOR BINKLEYTERM AND OPUS 1.1x BinkleyTerm and Opus 1.1x are "continuous mail" smart. Nodes marked "#CM" in the nodelist are flagged as such in the compiled nodelist files that these systems use. Nodelist versions that support this information are: Opus Version 6, QuickBBS 2.00, and TBBS w/ the special BinkleyTerm adjunct nodelist file. If you use any of the three previously mentioned nodelist formats with your system, you can follow this guide for creating a basic control file: Compress to EchoMail Hub(s) | | v Continuous to OurNet | | v HostRoute All Others For example, a sample for node 104/36 might look like this: OneCM 104/610 104/45 NormCM OurNet HostRoute SAMPLE OMMM CONTROL FILE FOR OPUS 1.0x Older versions of Opus use the Opus Version 5 nodelist. This nodelist does not offer complete information to the system, so a slightly longer oMMM control file is needed. Like this: Compress to EchoMail Hub(s) | | v Continuous to Crashable OurNet Nodes | | v Direct to All Other OurNet Nodes | | v HostRoute All Others oMMM Version 1.30 - Page 30 The control file for 104/36 might look like this: OneCM 104/610 104/45 NormCM 104/19 104/56 104/604 104/44 104/43 132/101 141/491 NormDirect OurNet HostRoute oMMM Version 1.30 - Page 31 +---+ | | Multi-Zone Operation | |====================+ \ \ | | / / \ +---+ / GENERAL INFORMATION BinkleyTerm Version 2.00 and above, and (at some point before release) Opus 1.10, both implement support for direct NetMail to and from other zones, using discrete outbound areas. oMMM 1.30 is capable of storing messages in these discrete outbound areas, but since Opus 1.03b and below, and, as of this date, Opus 1.10 test versions, are not capable of processing these outbound areas, this oMMM feature is disabled by default and must be enabled using a command line switch. To enable multiple zone support in oMMM, add the -z<zone> switch to the oMMM command line. For example, if your address is 2:507/1, there should be a -z2 on the command line. When oMMM sees this switch, it makes several significant changes in its processing: 1) All addressing becomes zone-sensitive in the control file. You may include zone information in addresses where necessary. When zone information is omitted, the zone number specified on the command line will be used as the default. 2) All messages in the NetMail area that are candidates for mashing will be scanned for the IFNA "extended addressing" field associated with inter-zone mail. 3) All mail destined to your zone will be stored in the "default" outbound directory. 4) All mail destined to other zones, and which contain the IFNA "extended addressing" field previously mentioned, will be stored in a discrete directory for those zones. Using 2:507/1 as a sample address again, and assuming C:\OPUS\OUTBOUND as the "default" outbound area, oMMM will store mail for Zone 1 in the directory C:\OPUS\OUTBOUND.001 (yes, that's right, directory names MAY have extensions!) and mail for Zone 3 in C:\OPUS\OUTBOUND.003. 5) All mail destined to other zones that DOES NOT contain the IFNA "extended addressing" field will NOT be placed into the discrete outbound areas mentioned previously...such mail will be placed in the primary, default outbound area. It is possible to support up to 4095 zones using this method, as the zone number is encoded in hexadecimal. For example, Zone 99 would use extension .063.