ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / MSGTOS2B.ZIP / MSGTOSS.DOC < prev next >

Wrap

Text File | 1992-02-11 | 140.8 KB | 3,697 lines

MSGTOSS Version 2.0 High-Performance FidoNet Mail Processor for RBBS-PC Copyright(c) 1989-92 Mike Zakharoff & Warren Muldrow Mike : FidoNet 1:138/154 Rbbsnet 8:918/10 Warren: FidoNet 1:3617/1 Rbbsnet 8:928/1 ALL RIGHTS RESERVED T E C H N I C A L M A N U A L for MSGTOSS RBBS-PC Mail Processor Written by Mike Zakharoff, assisted by Tim Jacobs & Craig Gagner DISCLAIMER ---------- The authors make no claims or warranties with respect to the contents or accuracy of this publication, or the product it describes, including any warranties of fitness or merchantability for a particular purpose. Any stated or expressed warranties are in lieu of all obligations or liability for any damages, whether special, indirect, or consequential, arising out of or in connection with the use of this publication or the product it describes. Furthermore, the right is reserved to make any changes to this publication without obligation to notify any person of such changes. MSGTOSS Version 2.0 L I C E N S E ------------- MSGTOSS is not a Public Domain program and is not free. MSGTOSS is copyright(c) 1989,1990,1991,1992 by Mike Zakharoff and Warren Muldrow. Non-registered users of this program are granted a two week license to evaluate the program suitability for their requirements. Any usage of Msgtoss beyond evaluation time period requires registration. Use of non- registered copies of Msgtoss beyond the original evaluation period is not wished. You are free to distribute the PUBLICLY AVAILABLE shareware version of MSGTOSS. MSGTOSS is SHAREWARE. MSGTOSS was not an easy project, as it took 1000's of hours to develop and test. The author has written other RBBS utilities such as MSGRENUM, MAILWAIT, MSGECHO, FIXMSG, all of which were released as freeware; none of which compares to the complexity of MSGTOSS. Fu- ture releases of MSGTOSS will depend upon how much support the author re- ceives. Therefore the author is asking for $25.00 for its use to: MIKE ZAKHAROFF 18004 22ND ST CT E SUMNER, WA 98390 Keep in mind that the authors could have easily crippled MSGTOSS with all sorts of schemes, including disabling the multi-tasking/network support, requiring a password, annoying "not-registered" lines appended to the tear line, beg screens, long delays, and other things to pester you to support the authors. If I were to figure out the amount of hours it took to devel- op and test this program, it would easily run into 10,000 hours of personal time that really can't be assigned any value. This was a service to the RBBS-PC community, and its development will set the stage for RBBS-PC's fu- ture in the Fidonet community. Cards and letters always welcome! Registered users will receive a personal registration code (See REGCODE in MSGCFG.DOC), as much personal support as possible. Non-supporters will basically be doomed to slither in their own guilt for all eternity. WARRANTIES ---------- MSGTOSS is guaranteed only to occupy space on your hard drive. Therefore the use of MSGTOSS is solely at your own risk! MSGTOSS had been beta tested extensively to eliminate bugs, however due to the limitless pos- sibilities of system configurations, no warranty is possible. Also, there are no guarantees that the author will upgrade MSGTOSS. TRADEMARKS ---------- The following products have been mentioned in this document: Areafix,Bascom 7.0,Binkleyterm,Confmail,D'Bridge,Desqview,Echodor, FrontDoor,Lharc,Makearc,Msged,Ommm,Polyxarc,Qmail,Quickbasic 3.0, RBBC-PC,Rbbsmail,Smlnet,Spaz,Subject & SeaDog Page - 2 MSGTOSS Version 2.0 Table of Contents ------------------ Page Mail Tosser Shock ............................................ 5 Purpose....................................................... 5 Non RBBS-PC installations..................................... 5 Features...................................................... 6 SPEED of MSGTOSS........................................... 8 What MSGTOSS won't do (yet)................................ 8 Credits....................................................... 9 Requirements.................................................. 10 MSGTOSS Theory ............................................... 11 TOSS (8 Phases of mail tossing)............................ 12 1 Un-Archiving Mail.................................... 12 2 Packet Identification................................ 13 3 Analyze Pkt Files.................................... 13 Null messages..................................... 14 4 Purge/Expand Message Bases........................... 14 Sysop Messages.................................... 15 Users Messages.................................... 15 Message renumbering............................... 16 Purging whiles users on-line...................... 16 5 Toss messages........................................ 17 File and Record Locking........................... 17 Duplicate Messages................................ 17 Oversized Messages................................ 18 Bad Date or message............................... 18 Unknown Messages.................................. 18 Capturing Messages................................ 18 Right Margin or RBBS messages..................... 19 Security Level of RBBS Messages................... 19 Private RBBS Messages............................. 19 Auto Breaking of Large messages................... 20 Stripping Echomail Control Lines.................. 20 Elastic Message bases............................. 21 Extremely Large Message bases..................... 21 Tossing Display................................... 22 Echomail to SYSOP................................. 22 Feeding Downstream Nodes.......................... 22 Passthru areas.................................... 22 Tossing NETMAIL................................... 23 Killing classes of messages....................... 23 After tossing the *.PKT........................... 23 6 Set Mailwaiting...................................... 24 7 Create MSGTOSS.LOG................................... 24 8 Create Maintenance Batch Files....................... 26 SCAN ...................................................... 27 Private messages........................................... 27 Scanning Philosophy........................................ 27 Mirror scanning............................................ 28 Initialization......................................... 28 Scan RBBS message bases................................ 29 Scan FIDO messages areas............................... 30 Re-scanning to net/nodes............................... 31 Create MSGTOSS.LOG..................................... 31 Page - 3 MSGTOSS Version 2.0 Table of Contents (continued) ------------------------------ Page What does DOMAIN mean......................................... 32 Networking/Multitasking....................................... 34 Effects of purging whiles users are on-line............ 34 MSGTOSS as a User...................................... 35 INSTALLATION.................................................. 36 Create MSGTOSS directory............................... 36 Copy files to MSGTOSS directory........................ 36 Print & read documentation............................ 37 Modify sample MSGTOSS.CFG.............................. 38 If you are not running RBBS-PC...................... 39 Modify sample MSGTOSS.BBS.............................. 40 Modify default MSGTOSS.BBS Keywords.................... 41 Create MSGTOSS.NOD using MSGNLST.EXE................... 43 Test system setup...................................... 44 Mail tossing test...................................... 47 Mail scanning test..................................... 47 Packing up mail..................................... 47 Command line switches.................................. 48 Batch file modification................................ 49 Packet Unarchiving Info............................. 49 Batch file example.................................. 50 HELP!......................................................... 51 Msgtoss beta testers................................... 51 Msgtoss Beta Distribution Matrix.............................. 52 Errors........................................................ 53 Performance Optimization...................................... 54 Modify RBBSSUB2.BAS to support /MUSER: ....................... 55 Epilog........................................................ 56 INDEX (See MSGIDX.DOC)........................................ <- Page - 4 MSGTOSS Version 2.0 MAIL TOSSER SHOCK ----------------- MSGTOSS is a comprehensive, highly configurable program. Because of its comprehensive nature, the documentation has been split up into four (4) separate documents. These documents are: MSGTOSS.DOC - Technical Manual theory of operation & installation MSGCFG.DOC - Reference Manual for MSGTOSS.CFG (configuration) MSGBBS.DOC - Reference Manual for MSGTOSS.BBS (areas.bbs) MSGSWI.DOC - Reference Manual for MSGTOSS command line switches MSGIDX.DOC - Integrated INDEX of all 4 manuals The printing out of these manuals should be considered mandatory for the setup and installation of MSGTOSS. The authors have attempted to provide as much reference material as possible for MSGTOSS, hopefully avoiding as many questions as possible for new users. If you are one of those people who will blindly try to install MSGTOSS without reading the documentation first, you are in for a surprise. Jan Maaskant (1:387/255 & 8:931/1) invented the term "mail tosser shock" to describe the anticipated reaction of new users of MSGTOSS 2.0, especially after running version 1.3. Reading the provided documentation as much as possible will help alleviate the symptoms of mail tosser shock. PURPOSE ------- MSGTOSS is a high performance tosser/scanner for RBBS systems. It was de- signed to allow RBBS-PC sysops to import and export Fidonet compatible Echomail or Netmail into RBBS-PC message bases (or Fido-style sub-direc- tories), in a fast and efficient manner. In addition, MSGTOSS is highly zone/domain aware, using its own proprietary nodelist for packet identifi- cation. MSGTOSS imports messages directly from Fidonet compatible message packets (*.PKT files) into RBBS message bases. This direct importing feature makes tossing of messages extremely fast. It has the capability to toss mail simultaneously to RBBS message bases, FIDO sub-directories, passthru to downstream nodes and points, all in one clean sweep. These fea- tures allows MSGTOSS to be ideal for a HUB situation, as well as a static node, where all mail can be processed in one sweep. NON RBBS-PC INSTALLATIONS ------------------------- Although MSGTOSS is designed exclusively for RBBS, MSGTOSS can also be con- figured to be run in a non-RBBS system (only support #.MSG messages). For specific details on this, see INSTALLATION section , "If you are not run- ning RBBS-PC". Page - 5 MSGTOSS Version 2.0 FEATURES -------- Here is a high-level summary of MSGTOSS 2.0 features: 1) - Domain and zone aware. 2) - Tosses and scans from both RBBS and Fido message areas. 3) - Feeds to downstream nodes simultaneously with tossing. 4) - Can be run in a non-RBBS environment (#.MSG format only). 5) - Purges and renumbers RBBS message bases as required. 6) - Maintains RBBS user file Last Message Read pointers. 7) - Maintains its own high water mark to speed up scanning. 8) - Handles selective message and file forwarding. 9) - Handles up to 200 unique nodes in the *.bbs file. 10) - Compatible with AreaFix, QMail, Ommm, etc. 11) - Tosses to RBBS directly from *.PKT files. 12) - Scans directly from RBBS to *.OUT files. 13) - Supports Binkley-Term's outbound area naming for domains. 14) - 25% faster M.DEF & 30% faster Fido tossing from old version. 15) - 200% faster internal purging (over MSGTOSS 1.0) 16) - Improved the MSGTOSS help program. "MSGHELP.EXE <rtn>". 17) - Support to toss from #.MSG format into M.DEF format. 18) - Ability to SCAN individually #.MSG or M.DEF, or both. 19) - Ability to re-scan message bases (for hubbing) to new nodes. 20) - INDIVIDUAL conference configuration of.... a) Whether to re-number message bases b) When to re-number message bases (threshold setting) c) Security level of each message base can be different d) Auto-Breaks large messages into smaller, multiple messages e) Right margin of messages f) Whether to support "private" echomail. g) Whether to strip echo control lines (PATH, SEEN-BY, etc.) h) Whether to divert messages that contain selected text i) Whether to provide duplicate checking services j) Whether to set the mailwaiting bits. k) Unique Origin lines. Page - 6 MSGTOSS Version 2.0 l) Whether to prevent purging of user messages for XX days m) Whether to force messages tossed as "already scanned" n) Whether to archive purged messages (HISTORY FILE) 21) - NETBIOS, DESQVIEW, PC-NET & 10-NET record/file locking. Allows safe tossing, scanning & purging while users are on-line. 22) - Supports OPUS-Style (date-written & arrived) date stamps 23) - Supports "capturing" of messages that contain selected text. 24) - MSGTOSS "metacommands". Allows a single command line word to mean a pre-defined sequence of commands. 25) - GLOBAL maintenance features. Allows MSGTOSS to create a batch file or execute a command for ALL message bases. 26) - Selectively Kill all netmail or routed mail. 27) - A new "MSGTOSS /TEST" command to validate system set-up. 28) - Allows multiple incoming files directories. 29) - Allows MSGTOSS to become a "user" on the system while tossing. Anyone entering [W]ho will see MSGTOSS execution status. 30) - Full "point" support, with built-in remapping. 31) - Positively identify the DOMAIN & ZONE of receiving mail packets, even if PKTS were created by a "zone-dumb" packer. 32) - Allows Intelligent individual MAIL & FILE Routing capabilities, with ability to "authorize" certain ZONE/NET/NODES (commence routing) at the same time "lock-out" certain ZONE/NET/NODES (deny routing). 33) - Ability to identify the sending nodes packer by name. 34) - Ability to "link" multiple AREAS.BBS files. 35) - Ability to import and export, unlimited size messages. 36) - Ability to "mirror scan" messages, where if you have DUAL areas (both RBBS format and Fido format), MSGTOSS will create a carbon copy of a message entered in Fido format to RBBS format, and vice versa. 37) - Supports Qmail-Style "PASSTHRU" areas for HUB support 38) - Does NOT fragment RBBS message bases! 39) - Maintains a "history" file of purged messages. 40) - Option of killing null messages (maintains log file) 41) - Overall more reliable operation, with all 1.3 bugs swatted. Page - 7 MSGTOSS Version 2.0 SPEED OF MSGTOSS ---------------- This is a relative comparison, but MSGTOSS will toss messages into RBBS message bases directly from *.PKT file at a rate of approximately 404 messages per minute (no duplicate checking). This is based on an 12 mhz IBM AT clone with a 300K disk cache. Actual speed will vary considerably. Users with high performance 386 machines have reported tossing throughput of over 1000 messages per minute. One off the great assets of MSGTOSS is the practicality of carrying hundreds of echo's on a single RBBS system, where speed of importing (prior to MSGTOSS) was prohibitive. Speed is also affected whether MSGTOSS is feeding (/FEED) downstream nodes or points. When /TOSS /FEED is active, tossing speed is significantly slower as MSGTOSS needs to process SEEN-BY lines, where normally it is not required. WHAT MSGTOSS WON'T DO (YET) --------------------------- Currently, MSGTOSS does NOT provide PACKING of mail packets (*.OUT files). To accomplish this you will need either OMMM (version 1.52+ recom- mended), QMAIL (just its pack function) or MAKEARC (for file-attach mail- ers, such as Frontdoor). Aside from the packer, MSGTOSS is the only utility that would be required for most node configurations. MSGTOSS will create *.OUT files after either a scanning run (/SCAN) or during a tossing run (/TOSS) with the /FEED switch. The packing of these files (along with scanning of Fido NETMAIL directories) need to accom- plished via the above mentioned utilities. NOTE: MSGTOSS does NOT scan NETMAIL directories. The above packers will accomplish this. NOTE: It should be noted that complete packing features are in the- planning/coding phases, and will be implemented in future re- leases of MSGTOSS. Page - 8 MSGTOSS Version 2.0 CREDITS ------- Credit is due to Tom Mack, Jon Martin and Ken Goosans for creating and maintaining RBBS-PC. RBBS-PC still sets the standard. Credit is also due to Dan Thomson, Andrew Farmer & Jeff Nonken (authors of SPAZ), who granted myself permission to distribute SPAZ (un-altered) within the MSGTOSS ar- chive. Credit is due to Warren Muldrow (co-author of MSGTOSS), who warrants his own paragraph. All of these folks (in their own way), enhanced RBBS- PC in some manner or fashion. ORIGINAL BETA TESTERS --------------------- To those original MSGTOSS beta testers, who blindingly exposed their pre- cious RBBS message bases to the early attempts of MSGTOSS; Greg Popovich, Gray Shockley, Mark Annis, Vaishnava Dasa, Tim Jacobs, Jan Maaskant, Na- than Barber, Richard Couture & Stan Staten ....thank you. In addition, these people spent their own $$$ sending me crashed *.PKT files for me to analyze and create fixes for, calling me voice, and picking up new beta versions. Apologizes to any of those I have left out by mistake. WARREN MULDROW -------------- Although not responsible for the initial design and conception of MSGTOSS, Warren (who is now a co-author of MSGTOSS) has contributed extensively to MSGTOSS as it is today. His coding expertise (20+ years experience) has been proven in many ways by being able to plow through the MSGTOSS source code (Zakharoff style) and make MAJOR modifications and improvements. With his innovative spirit, MSGTOSS will continue to evolve in such a man- ner which will set the standard for not just RBBS-PC systems, but all mail tossers today. Warren is now the primary focalpoint for MSGTOSS. Page - 9 MSGTOSS Version 2.0 REQUIREMENTS ------------ MSGTOSS requires a minimum of around 400K for basic static node operation. For hub work where shelling to a packer is required (along with its shel- ling to an archive utility), around 520K or so is required. MSGTOSS was developed on an 12 mhz 286 AT clone, with 640K of ram. It is written completely in Quickbasic Version 3.0, with ASM routines for se- lected routines. It is in the process of being written in Bascom 7.0 which will allow more capabilities. This document assumes that you have at least the following: 1) An operating RBBS bulletin board 2) Connected to Fidonet or RBBS-NET with a node number 3) Receiving mail packets daily 4) A front end mailer (Binkley, SeaDog, FrontDoor) It is not in the scope of this document to teach you technical details re- garding operation and theory of how Fidonet works. This document should help you get rolling along using the supplied sample files. It is recom- mended that you obtain documentation to help you understand how the exporting/importing of mail works. The CONFMAIL documentation provides an excellent reference on this. A helping hand of another RBBS sysop is the *best* way to get started. This document can be VERY confusing. I suggest the first time user of MSGTOSS skip all the theory and go right to the INSTALLATION Chapter, using the supplied MSGCFG.DOC, MSGBBS.DOC and MSGSWI.DOC constantly during the setup. MSGTOSS has its own dedicated echo called "RBBS_MSGTOSS", available on the Rbbs-Net backbone. Another source could be the "RBBS-PC" echo, available on both the Rbbs-Net and Fidonet backbones. The authors are available for consultation, although we prefer you thoroughly exhaust all sources of in- formation first. The reason for the extensive documentation is to avoid basic questions, easily answered on the first few pages of documentation. Most of the beta testers will be happy to provide assistance, or maybe a call from a local RBBS SYSOP may guide you in the right direction to re- ceiving the right information. Page - 10 MSGTOSS Version 2.0 MSGTOSS THEORY -------------- MSGTOSS is a comprehensive mail processor for RBBS systems. As a conse- quence, there are currently 42 command line switches or options, over 46 MSGTOSS.CFG configuration parameters and 19 MSGTOSS.BBS keywords that all interrelate with one another. To see how this all fits together, you will need to read the corresponding reference manual for each area. MSGSWI.DOC contains reference material for all MSGTOSS command line switches. MSGCFG.DOC contains reference material for MSGTOSS parameters associated with MSGTOSS.CFG (configuration file). And MSGBBS.DOC is a reference manual for all if the MSGTOSS keywords used in the MSGTOSS.BBS file. Each of these aspects should be understood prior to attempting to configure MSGTOSS. This tremendous number of interrelated system configuration items demon- strates the amount of flexibility built into MSGTOSS. I claim MSGTOSS to be the most advanced Fidonet tosser in the world (and most certainly for RBBS). You should be able to utilize its power to fully automate your echomail process. In addition to processing mail, it has other non-tossing utilities built -in. Because of this, there are TEN MAJOR command line switches, which tell MSGTOSS what major operation is being requested. When a major command line switch is issued, any other switches not related to the major opera- tion are simply ignored. You cannot issue TWO major command line switches simultaneously. For explanation and the use of the switches use the reference manual MSGSWI.DOC. SYNTAX: MSGTOSS [/SWITCH] [/OPTIONS...] The TEN major command line switches... 1) Toss RBBS, FIDO & NETMAIL messages -------> /TOSS 2) Scan (export) new locally entered mail ---> /SCAN 3) SIZE message bases to preset RECS:xxx ----> /SIZE 4) Reset users Mailwaiting Bit (all msgs) ---> /MWRST 5) Report on message base statistics --------> /STAT 6) Test MsgToss Setup Configuration ---------> /TEST 7) Wait for users, create MSGWAIT.BAT file --> /WAIT 8) Globally execute xxx for all msg bases ---> /GLOB:xxx 9) Recompile the node list (MSGTOSS.NOD) ----> /NLST 10) Execute MSGEID.EXE - EID Datamase Maint --> /EID 12) MSGTOSS.CMD metacommands - (no slashes) --> xxx 12) MSGTOSS.BBS Tossing Configuring Keywords -> xxx 13) MSGTOSS DOS ErrorLevel Codes -------------> Errorlevels NOTE: Executing MSGTOSS<rtn> at the DOS prompt will produce a similar dis- play. You can then enter the number of the major command line switch, then all related switches are displayed along with a description and purpose. Page - 11 MSGTOSS Version 2.0 TOSS ---- The /TOSS command switch is for tossing Fidonet compatible message packets (*.PKT) into your RBBS message bases (M.DEF) or into a DOS directory (as a FIDO #.MSG). The /TOSS option has 28 switches. TOSS signals MSGTOSS to start a carefully planned sequence, used more often than any other switch. There are 8 phases to the TOSSING of messages: 1) Un-Pack mail packets 2) Identify domain/zone/net/node of *.PKT files 3) Analyze *.PKT files 4) Purge/expand RBBS message bases as required 5) Toss messages (RBBS message bases or Fido) 6) Set the mailwaiting bit for conference users 7) Create a MSGTOSS.LOG file for message base activity 8) Create miscellaneous BAT/CMD/CTL files for other maintenance. PHASES OF TOSSING MAIL ---------------------- UN-ARCH MAIL PACKETS -------------------- Incoming mail packets are received by your respective front-end mailer as either archived (*.MO*, *.TU*, etc.) or as a regular *.PKT file. SPAZ (supplied within the MSGTOSS distribution archive) will detect what type of archive it is and unpack it into one of the directories specified by the multiple FILES-------> entries. You will have to provide the correct SPAZ command (or other unpacker) in your batch file. Its syntax is: SPAZ [In Directory] [Out Directory] NOTE: For optimum capability, it is recommended that the FIRST FILES-----> entry in your MSGTOSS.CFG be the incoming files directory. This is the directory where all files (via your front-end mail) go first. The reason for this is that during FILE ROUTING (explained further) MSGTOSS will assume the first FILES-------> entry as where routed files go. NOTE: It should also be noted that you can substitute SPAZ or any other type of un-packing utility (such as GUS or POLYXARC) if you don't want to use SPAZ. The only critical thing to remember is that MSGTOSS will only look in your FILES--------> directories for *.PKTS, so you have to make sure that after executing the un-packer, the *.PKTS are found my MSGTOSS. You may have several different directories your mail is coming into (Mul- ti-Node Systems). Using the FILES-------> in the MSGTOSS.CFG file, you can specify where these directories are. Page - 12 MSGTOSS Version 2.0 PACKET IDENTIFICATION --------------------- MSGTOSS goes through extensive packet identification routines that reliably identify the source DOMAIN, ZONE, NET & NODE and PACKER of the PKT file. This is accomplished by a proprietary nodelist that MSGTOSS creates during your weekly nodelist processing batch file. Whenever the source of the PKT is unknown or MSGTOSS doesn't have enough information, MSGTOSS will look up the information regarding the PKT in its own nodelist. The name of this nodelist is "MSGTOSS.NOD" and is created automatically when you execute MSGNLST.EXE or MSGTOSS /NLST. For more information, see INSTALLATION section and MSGSWI.DOC. The reason for having a proprietary nodelist is to ensure compatibility be- tween different mailer systems, and to ensure the authors of MSGTOSS have control over the format required. In addition, MSGTOSS looks up the name of the packer (i.e. Qmail, Rbbsmail, Confmail) in accordance with the product code that is present in all legitimate packers. It gets this information in a file called "MSGTOSS.PCD" (Product Code). Using this combination of nodelist and prod- uct code files, MSGTOSS is able to determine many things. Lets take the packet: 50455040.PKT. Msgtoss looks at the header information and sees this. NOTE: Frequently, the Software Distribution System (SDS) distributes a file called "FTSCPROD.xxx", which is an updated list of MSGTOSS.PCD. When you obtain an updated product code listing, rename it, keeping MSGTOSS.PCD up-to-date. 50455040.PKT To:@1:387/255@fidonet Fm:@1:387/5@fidonet 1A D'Bridge 1.0 It includes the original domain & zone, destination domain & zone, as well as the source packer. All of this information is logged in the MSGTOSS.LOG file. If MSGTOSS is truly confused regarding the source/desti- nation of a PKT file, MSGTOSS will default to the FIRST (primary) NODE-------> entry (in the CFG file) regarding DOMAIN & ZONE. ANALYZE PKT FILES ----------------- MSGTOSS will then read the contents of each *.PKT and create a correspond- ing *.IDX file for each packet. If the packet is 11112222.PKT it will create a file called 11112222.IDX which contains information about each message in each of the packets. This occurring should be transpar- ent to the user, as MSGTOSS will create and delete these *.IDX files as required. This analysis phase is critical, as MSGTOSS needs to know ex- actly how much space is required to import new messages. If MSGTOSS finds an existing *.IDX file, it will re-analyze it, vice the *.PKT. NOTE: MSGTOSS will create these *.IDX files in the same directory where its corresponding *.PKT file is located. For those fortunate to have huge RAM disks, make sure the maximum directory entries can han- dle all these *.IDX files being created. For instance, it is not uncommon for a hub to process 150 *.PKT files at a time. MSGTOSS will Page - 13 MSGTOSS Version 2.0 create a *.IDX file for each of these, so 300 files will eventually end up after analysis. If your directory maximum is 256... problems. During the analyzing phase, MSGTOSS also determines what NET/NODES that are listed in your MSGTOSS.BBS file haven't seen the message, and creates a IDX entry so later (during the toss) MSGTOSS already knows who needs to be sent the message, without loading the entire message into memory. Because of this, MSGTOSS has no theoretical limit on message size. This is significant, as most other mail tossers in the Fidonet community have substantial limits (most are around 16K) on the message sizes that it can handle. NULL MESSAGES ------------- If a message is determined to contain only a valid header, and no text within the body of the message, MSGTOSS will selectively kill the message. Messages like this turn out to be a nuisance, as some mailers send null fi- le-attach messages to send regular *.PKT files. MSGTOSS will detect a null message, kill it, and log its occurance into a file called MSGTOSS.NUL. This is selected via the KILLNULL---> parameter. Setting to 'Y' will en- able this feature. PURGE/EXPAND MESSAGE BASES -------------------------- After the analyzing phase, MSGTOSS then knows how much space will be required to successfully import the messages contained in each of the *.PKT files received. It will then either PURGE the message bases or EXPAND (or both) prior to tossing. If you specified the /PREP switch (pre- purge), MSGTOSS will first load all of the USERS in a particular conference in memory (see NOTE:), and will commence to purge non-user messages. This is accomplished via a 'pack-in-place' method, where the messages flagged to keep will be 'shuffled' to the beginning of the RBBS message base, as others are being deleted. This pack-in-place method avoids fragmenta- tion of the message bases. Only if a message base is expanded will frag- mentation occur. NOTE: The BBS keyword "USRH:1" directs MSGTOSS whether to load all of the users into memory prior to purging. For very large message bases with alot of users, the purging speed can be dramatically increased by us- ing the "USR:0" BBS keyword, as hashing users will no take place. However, loading the users have alot of benefits (read on). NOTE: MSGTOSS will purge ONLY ENOUGH messages for successful importation. Therefore, if only 2-3 messages are received in a particular confer- ence, then roughly the same amount will be purged (if there isn't en- ough space to begin with). NOTE: MSGTOSS can handle roughly 1500 users in memory at any one time. If MSGTOSS detects that it is running out of memory as users are being loaded, it will stop loading in memory and page the remaining users to disk. This causes the purging to be slower (but more com- plete). For optimum operation, try to keep the sizes of your conference users under 1500 or use the USRH:0 BBS keyword where Page - 14 MSGTOSS Version 2.0 appropriate. Using the "USRH:1" BBS keyword will prevent messages from being purged before the sysop or conference users have had a chance to read them. MSGTOSS will make sure these messages are not purged, with the following exceptions. NOTE: If using the "HIST:1" BBS keyword, whenever a message is purged, MSGTOSS will export, in text format, the message into a *.HIS file. If the message base being purged is RBBSM.DEF, and HIST:1 is true, MSGTOSS will export all purged messages into a file called RBBSM.HIS. SYSOP MESSAGES -------------- Incomming messages will always be checked to see if they match the multiple SYSNAMES----> entries, regardless if the "USRH:0" BBS keyword (don't hash users) is active (Fidonet is mostly for SYSOPS, right?). For SYSOP messages (messages where to/from = SYSNAMES---->) during a purging operation, the following rules apply: 1) If the message is already killed, purge it. 2) If the message has already been read (and the DELREADSYS is set to 'YES', purge it. 3) If the message is TO the SYSOP, and the message is OLDER than XX days as specified in the DAYSTOSYS parameter, then purge it. 4) If the message is FROM the SYSOP, and the message is OLDER than XX days as specified in the DAYSFRSYS parameter, then purge it. 5) Otherwise leave it alone! USER MESSAGES ------------- Same as above for the SYSOP, except: 1) The BBS keyword "USR:1" must be active (means MSGTOSS will load all conference users into memory). 2) The associated CFG parameters are DELREADUSR, DAYSTOUSR & DAYSFRUSR, respectively. NOTE: If you decide to NOT load the users into memory via BBS keyword "USRH:0", then users messages may be deleted before the user has had a chance to read them. However, if the user is a regular caller, and you keep your message bases large, a newly entered message may take some time to recycle through multiple purging sessions, so the user may have a chance to read them. If you keep small message bases (mine are only 900 records) then definitely use the "USRH:1" BBS key- word. USER/SYSOP SUMMARY Page - 15 MSGTOSS Version 2.0 ------------------ This 'smart purging' is an important concept for MSGTOSS, as messages left TO/FROM the users (and the sysop) of the conference WILL NOT be deleted until they are either killed or their time limit has run out (as specified by the various DAYSTO???/DAYSFR??? parameters). If after the 'pack-in-place' purging there is still not enough space to import all of those messages, MSGTOSS will EXPAND the message base as it sees fit to allow successful importation. MSGTOSS expanding the message base is not a big deal. In fact it sometimes necessary when, for instance, your HUB has been shut down for a couple of days, and you are suddenly flooded with messages. Because MSGTOSS doesn't think twice about expanding when it needs it, built-in 'smart siz- ing' code is built into MSGTOSS to easily maintain tight control on the sizes of the message bases. In fact, these built-in utilities are superior to RBBS-PC CONFIG utility. After MSGTOSS is initially set up properly, adding a simple line to your daily maintenance batch file "MSGTOSS /SIZE" will chop the message bases back down to a predeter- mined level in one swipe. So again, if MSGTOSS expands a message base, that one command will cleanly and easily return it back to its original size, using smart purging techniques. Remember, MSGTOSS will ONLY expand a message base if it absolutely needs to. If after the built-in purging there's STILL not enough messages, then and only then will it expand message bases. If you specified the /PREX (pre-expand) switch, then MSGTOSS will simply EXPAND the message base as it sees fit and continue on. At a later time (say at a night event) to can CHOP the message bases back down to their original size by issuing the /SIZE or /SIZE-UP switches. If you add the switch /FIX to the command line, then MSGTOSS will automatically SHELL to FIXMSG if it detects a corrupt message file while doing the purge. It will execute FIXMSG twice, and if it still fails to correct the problem MSGTOSS will simply abort. If you use the switch /FIXC switch (instead), MSGTOSS will do the same as above, but will copy the BLANK message base (model) as speci- fied by the BLANKMSG---> parameter over the corrupt message base, and rename it to *.BAD. This prevents MSGTOSS from aborting due to a corrupt message base. MESSAGE RENUMBERING ------------------- MSGTOSS will renumber the message bases AS they are being purged. The renumbering will be in accordance with the "RNST:xx" and "RNIF:xx" BBS keywords. The "RNST:xx" tell MSGTOSS what number the newly renumbered messages should start with. IE:You like all message bases to start with 1000+, you enter "RNST:1000" as a BBS keyword. The "RNIF:xx" BBS keyword will tell MSGTOSS to renumber, but ONLY IF the last message (prior to a purge) is greater than/equal to "RNIF:xxx". In addition, MSGTOSS will (upon finishing purging) reset the "last message read" flag (in the associated USER file) to the new/next closest message number, so last-read flags are not lost. PURGING WHILE USERS ARE ON-LINE Page - 16 MSGTOSS Version 2.0 ------------------------------- MSGTOSS adheres to standard file/record locking protocols used by RBBS-PC when tossing/purging/sizing message bases. For a more de- tailed description of this, and its effect on users who happen to be on-line, see section on MULTITASKING/NETWORK SUPPORT. TOSSING INTO RBBS & FIDO FORMAT ------------------------------- After the RBBS message bases were prepared for the new message (purged, expanded, etc.), they are now ready to receive new messages. MSGTOSS will toss each of the messages contained in *.PKT files to either an RBBS mes- sage file, a sub-directory in Fido Message form, a *.OUT file for either PASSTHRU areas for downstream nodes, or all three. FILE & RECORD LOCKING --------------------- MSGTOSS adheres to standard file/record locking protocols used by RBBS-PC when tossing/purging/sizing message bases. To use this fea- ture, use the /LOCK command line switch. For a more detailed de- scription of this feature, see the section in the MSGSWI.DOC. Also see /MUSER:x command line switch, and MULTITASKING/NETWORK SUPPORT. DUPLICATE MESSAGES ------------------ MSGTOSS handles duplicate checking alot different than other mail processors. It creates and maintains a duplicate database file called MSGTOSS.EID. This file is a random access file that contains all of the EID:, MSGID:, and MSGTOSS generated ID codes for the last XXXX messages, as specified by your DUPSIZE parameter, for all of your conferences. The reason for the single database-type format is simple, opening and closing files takes time, and having a sin- gle file that is opened all the time will make it faster. The CDUP:x keyword allows individual conference configuration as to whether you want DUP checking to apply for a particular conferences. NOTE: The supplied MSGTOSS utility (MSGEID.EXE) provides a means of modifying and maintaining the MSGTOSS.EID database. NOTE: When using the work directory switch (/WDIR), MSGTOSS will auto- matically copy the MSGTOSS.EID database file to the RAM disk (as specified by the WORKDIR---> parameter) prior tossing for faster operation. After tossing, MSGTOSS will automatically copy it back to preserve its data. MSGTOSS will check for duplicates during the tossing phase (must specify the CDUP:1 keyword), and if one is encountered, it will simply ignore the message and display an informational line of the duplicate while tossing. If you specified the /DLOG (Maintain Dup Log File) then when a duplicate is encountered MSGTOSS will append the date, pkt, msg number, area, net/node of originating system and the message header into a file called MSGTOSS.DUP. Page - 17 MSGTOSS Version 2.0 NOTE: The areas NETMAIL, UNKNOWN, ROUTETHRU & MSGCAPTURE are exempt from dup checking. OVERSIZED MESSAGES ------------------ There is no SIZE LIMIT of an imported message. MSGTOSS will import without problems an entire BOOK if asked to. During the toss, however, messages that are known to be over-sized (over the limit specified by the KILLOVER parameter) will be simply ignored. This prevents your message bases from being un-duly large due to a few large messages. This applies ONLY to RBBS message areas. If tossing to a Fido area, then the whole message will be tossed. BAD DATE, MESSAGE HEADER ------------------------ Messages that are found to contain bad dates will be logged into the MSGTOSS.ERR file, but will be tossed anyway. MSGTOSS does a good job interpreting the various forms of dates that show up in a *.PKT file, however, some it will not handle (like typos). For these messages, MSGTOSS will convert the date to 'Todays Date/Time' for RBBS message bases. If tossing as a Fido message, it will leave the date intact (as it was). For messages that have flaky message headers (grudged, etc.) MSGTOSS will just ignore the message and log it into the MSGTOSS.ERR file, along with the flaky header. MSGTOSS does not bother tossing 'bad' messages, this just adds more work for the sysop. Instead, MSGTOSS will log the bad message into the MSGTOSS.ERR file, and it will tell you what went wrong. UNKNOWN MESSAGES ---------------- Messages that are found to contain an unknown AREA tag will be tossed into the Fido directory or RBBS message bases that is specified for the UNKNOWN area. The UNKNOWN area is required, but if you specify the '/KUNK' (Kill Unknown) switch they will be ignored (deleted). Messages marked as UNKNOWN that are tossed will be tossed along with their original AREA:xxxx tag and are exempt from dup and size check- ing (even with the CDUP:1 keyword). NOTE: Assuming that a previously UNKNOWN message becomes KNOWN, and the area UNKNOWN is a Fido-Style area, you can toss these mes- sages into RBBS format via the /TUNK (toss unknown) switch. The most likely reason for a message to be unknown is either you forgot to put the new AREA:TAG in the MSGTOSS.BBS file or an im- proper link between node and host. The /TUNK switch is meant to be used only when necessary. Placing it permanently on the /TOSS command line will greatly slow down the toss- ing process. CAPTURING MESSAGES Page - 18 MSGTOSS Version 2.0 ------------------ MSGTOSS provides sysops with the ability to CENSOR messages in an au- tomated fashion. This is accomplished via the BBS keyword CAPT:1 in conjunction with CAPTURE-----> configuration entries. When you enter a 'colorful metaphor' in the CAPTURE CFG entry(s), and you config- ure a conference as a captured conference (via CAPT:1) then MSGTOSS will monitor the messages PRIOR to importing and divert them into a special area called 'MSGCAPTURE'. It is most useful that this area be a Fido Style area. If you specify an RBBS message base as the captured conference, then moving them later is very difficult. Assuming MSGCAPTURE is a Fido area, you can then look at them an after censorship can then toss these messages in their proper conference via the '/TCAP' (toss capture) command line switch. This works in exactly the same way as /TUNK (toss unknown) switch. NOTE: When using the /FEED switch, captured messages will still be exported to downstream nodes. A captured message is strictly LO- CAL in nature. Why have this feature? If you don't want a bunch a swear words on your BBS is one application. Another may be that you belong to 50 echoes, and you want all of YOUR personal messages captured so you can read/respond prior to importing. Is the use of this feature ethical? Its up to you. Obviously abuses can occur via this fea- ture. NOTE: Never CENSOR other peoples mail! If you are a hub and use this feature (inappropriately) you will suffer the consequences. That is NOT ethical. RIGHT MARGIN OF RBBS MESSAGES ----------------------------- RBBS messages are normally formatted to a right margin of 72. If you set your MRGN: keyword in your MSGTOSS.BBS file to say MRGN:77, then the imported messages may look more proper, as most BBS systems allow right margins of 79. Editing of these messages may be more diffi- cult, because RBBS expects messages to be 72. SECURITY LEVEL OF RBBS MESSAGES ------------------------------- RBBS has the capability of setting a security level for the actual CONFERENCE, and for the messages within. The ESEC:xxx BBS keyword configures what the security level of tossed messages are for a par- ticular conference. For instance, setting ESEC:5 as a BBS keyword will set all messages for which the BBS keyword applies to a security level of 5. NOTE: This is a very important BBS keyword! If you set ESEC:100 and all users (and the SYSOP) have security levels below 10 then even the SYSOP won't be able to read messages. PRIVATE RBBS MESSAGES --------------------- Page - 19 MSGTOSS Version 2.0 RBBS-PC allows private messages to be entered in echo areas. This is a good feature, as some echoes are meant for that. However, some sy- sops prefer all incoming echomail to be PUBLIC instead of PRIVATE. The BBS keyword PRIV:x configures whether the private attribute is honored for messages imported/exported. For instance, you set PRIV:1 (private allowed) and a private message arrives for a user; MSGTOSS will set the message to be private ("*" before the message number), otherwise, it will be converted to public. If a private is entered then MSGTOSS will set the private attribute when exporting the message to a *.OUT file. PRIV:1 - Private message arrives, set as PRIVATE Private message entered, exported as PRIVATE PRIV:0 - Private message arrives, set as PUBLIC Private message entered, NOT-exported NOTE: For more information on this See /SCAN section. AUTO-BREAKING RBBS MESSAGES --------------------------- RBBS-PC has a limitation of 150 lines that will be displayed to a us- er, even though the message is much longer. For very large mes- sages, its almost impossible to read the entire message, much less respond to it. The BBS keyword MAXL:xxx allows you to tell MSGTOSS to auto-break a message into multiple messages. For instance, if you set MAXL:100, then whenever MSGTOSS encounters a message that is longer than 100 lines, it will stop importing, create a new message with the same header, and finish the message. As part of this pro- cess, MSGTOSS will append the following to the end and beginning of these messages, respectively: MsgToss (Continued on NEXT message) MsgToss (Continued from LAST message) NOTE: If you decide to use RBBSMAIL (or any other type of RBBS mail processor) vice MSGTOSS to re-scan message bases (for HUB work) then set MAXL: very high (32000), as you don't want MSGTOSS to auto-break messages. If you exclusively use MSGTOSS to scan/re-scan (as you should), then no problem, as MSGTOSS will attempt to re-create the original message during a re-scan. STRIPPING ECHOMAIL CONTROL LINES IN RBBS ---------------------------------------- Echomail contains alot "control lines" which are normally not dis- played to the user. These lines such as "SEEN-BY:", "PATH:" and "EID:" lines can be stripped out of the RBBS messages by using the "SECL:1" BBS keyword in conjunction with the "FMAS:1" keyword. The type of lines to be stripped are configured via the ,"SECL------ -->" parameter entries in the MSGTOSS.CFG file. These entries allow the sysop to decide exactly what lines are to be ignored and up to 20 "SECL-------->" entries are possible. This allows as many messages to be imported into the RBBS message Page - 20 MSGTOSS Version 2.0 base(s) in the allocated space defined. See MSGBBS.DOC and MSGCFG.DOC for more detail. ELASTIC MESSAGE BASES --------------------- MSGTOSS by default is always checking that the "max message" value that is present in the message base, "checkpoint record". This is al- ways in accordance with RBBS-PC standards (can be modified by the MSGMULT parameter). If you elect to use the elastic message bases first introduced in RBBS 17-2 you simply set the "ELASTIC---->" pa- rameter to "YES". Basically all this does is whenever MSGTOSS tries to set the "max messages" value, it will set it to the value of the "RBBS-MAX---->" parameter (currently 999). NOTE: For proper operation of the ELASTIC message bases, the MAINT%LO and MAINT%HI parameters should be set to a value of 100 each. This tells MSGTOSS during purging, sizing and tossing to leave as little amount of slack space at the end of the message bases as possible (100 percent full at all times). RBBS will expand the message bases as users enter new messages. EXTREMELY LARGE MESSAGE BASES ----------------------------- If you keep extremely large message bases (over 4000 records) it is possible for your message bases to exceed the (current) RBBS-PC maxi- mum of 999 messages per message base. Certain precautions are built into the MSGTOSS purging code to prevent this, such as the SLAK:xx keyword and pre-counting (further ex- plained). NOTE: The maximum of 999 may soon be increased, this is why the "RBBSMAX---->" parameter is present in the MSGTOSS.CFG file. The default entry is 999, which reflects the "current" RBBS-PC maxi- mum. In the event the maximum is raised (future releases of RBBS-PC) the MSGTOSS "RBBS-MAX--->" parameter will have to be adjusted. Also, it is possible to modify the RBBS code to in- crease the built-in 999 message limitation. The RBBS-MAX parame- ter allows you to do this safely. The formula used to trigger a pre-count is (RBBS-MAX * 4), where if the number of records exceed this amount, that will cause a pre-count of the messages prior to tossing. Example: RBBS-MAX = 999, "precount" = (999 * 4), Trigger = 3996 recs Therefore MSGTOSS will do a "pre-count" of the messages prior to tossing. This "pre-count" is automatic and is triggered only when MSGTOSS senses a (RBBS-MAX * 4) record (or greater) message base. In the event of an "overflow", MSGTOSS will not allow any more messag- es to be imported into the message base, but will allow other message bases to be processed as normal. After the *.PKT is tossed normally, MSGTOSS will rename the *.PKT to *.OFL (for overflow) and log the occurrence of the overflow into the MSGTOSS.LOG and MSGTOSS.ERR Page - 21 MSGTOSS Version 2.0 files. The sysop can then elect to fix the overflow problem, or sim- ply delete the *.OFL file. Tossing of selected echoes are possible via the /AREA: command line switch(es). NOTE: Again, the possibility of an overflow is unlikely with MSGTOSS 2.0, not so with earlier versions. TOSSING DISPLAY --------------- During the tossing phase, alot of tossing activity is displayed to the user. If you would like to suppress this, simply add the '/DDA' switch to the MSGTOSS command line. This will also result in faster process- ing of messages. However, any informational warning (like duplicate, oversized, bad date, etc.) will still be displayed. ECHOMAIL MESSAGES ADDRESSED TO 'SYSOP' -------------------------------------- Although its irritating, alot of Fidonet mail processors happily allow messages entered TO:SYSOP to be exported into public echomail areas, thus when these messages arrive to your system, RBBS-PC notifies you that YOU have mail-waiting. Whenever MSGTOSS sees an echomail message that addressed to 'SYSOP', MSGTOSS will change the addressee to 'SYS- TEM OPERATOR'. NOTE: During a re-scan of a message base (HUB situation), MSGTOSS will convert these names back to 'SYSOP' to equally irritate those which you are re-scanning to. FEEDING DOWNSTREAM NODES ------------------------ If you are a HUB, or you support POINTS, you can simultaneously create *.OUT files addressed to your nodes/points by using the /FEED switch on your /TOSS command line. Using this switch will automatically feed your nodes & points as MSGTOSS is tossing to your RBBS message bases (M.DEF) or #.MSG format. Note that the use of the switch requires more processing (SEEN-BY lines, etc.), so it will increase process- ing time slightly. For more information, see MSGSWI.DOC reference guide. Also see 'Scanning Philosophy', as it relates to /FEED. PASSTHRU AREAS (For HUBs) -------------- MSGTOSS supports Qmail-Style passthru areas. These are configured as having a "#" (pound sign) as the FIRST character in the MSGTOSS.BBS file, followed by the area name. For instance, a passthru area for the COMM area would be entered as follows: #(Optional Path) COMM 343/300 56 67 89 The optional path is not required by MSGTOSS, but some mail processors (such as Qmail or AreaFix) get upset when a path is not entered there. In order to activate this feature, you must use the /FEED switch. As MSGTOSS is tossing to your RBBS message bases and local Fido style Page - 22 MSGTOSS Version 2.0 areas, it will also toss the same messages to your down-stream nodes. This type of area indicates that you are simply 'passing' the area to other nodes, and are not keeping it locally. It is most likely you will not be doing this unless you are a Hub of some sorts. TOSSING NETMAIL --------------- Netmail messages are usually tossed into a Fido style directory, where either a local editor (such as MSGED) or netmail door (such as ECHODOR or SMLNET) can be used to respond. MSGTOSS provides full point-re- mapping, file/mail forwarding capabilities (with security envelope). KILLING (IGNORING) CLASSES OF MESSAGES -------------------------------------- MSGTOSS provides three specialized command line switches that are de- signed to assist those sysops who which to use MSGTOSS in conjunction with another mail processor (such as Qmail). MSGTOSS allows (via the /KNET, /KUNK & /KRTE comm and line switches) the sysop to determine whether he/she wants MSGTOSS to ignore NETMAIL (/KNET), UNKNOWN (/KUNK) and ROUTETHRU (/KRTE). NOTE: MSGTOSS is capable of tossing all of the above classes of mes- sages, and can provide exceptional mail/file routing capabili- ties. These switches are extremely specialized and should only be used with full understanding of what they do. The KILLNULL parameter determines whether MSGTOSS will kill (ignore) null messages. These messages contain no text body, usually used for sending files or *.PKTs from file-attach type mailers. If KILLNULL is set to 'Y' (yes), MSGTOSS will kill the null message, and log its oc- curance to a file called MSGTOSS.NUL. AFTER TOSSING THE PACKET ------------------------ After tossing the *.PKT, MSGTOSS will automatically delete the respec- tive *.PKT and *.IDX file and continue on to the next *.PKT file. NOTE: If you wish to keep the *.PKT files for further processing, sim- ply use the "/DKP" switch. This will delete the *.IDX file but will leave the *.PKT file available for other processors (like for HUB work). Page - 23 MSGTOSS Version 2.0 SET MAILWAITING BIT ------------------- After successful tossing of the messages, MSGTOSS will then set the 'mail- waiting bit' for all RBBS conferences which are configured to set the mail- waiting bits (via MWST:x keyword) and which received mail. This allows us- ers to be notified when they log-on the system whether they have mail waiting to be read in each of the conferences. During initializing, MSGTOSS remembered what the first message was before it started tossing, therefore if you use the MWST:1 keyword, it will ONLY set the bit for the brand-new messages. If you want to reset all mailwaiting bits for all conferences, you can use the /MWRST (mailwaiting reset) command line switch. See MSGSWI.DOC for more information on this. For messages that are addressed to the SYSOP or the SYSOP's common name (IE:Mike Zakharoff), the TO: field will be changed to 'SYSOP' so when you log-on as the sysop, proper notification will be made. The SYSALIAS parameter (located in MSGTOSS.CFG) tells MSGTOSS which user name is considered the SYSOP. This should be the same name as was entered in CONFIG for the secret remote logon, and for 'LOCAL' logon (ESC switch). Any messages that match those as specified by the various SYSNAME(s) will cause the mailwaiting bit for the SYSALIAS user to be set, and cause the TO: field to be changed to the text 'SYSOP', if 'SYSOP' is not already part of the TO: field. NOTE: MSGTOSS requires that all conferences contain the SYSALIAS user. During the mailwaiting phase, it will check this, and if not present, will annoy you until you add it. It wants to always make sure it knows what mailwaiting bit to set for SYSOP. NOTE: You can obtain faster purging, mailwaiting and sizing by con- figuring MSGTOSS to use a work directory. This is set via the WORK- DIR---> parameter. To initiate the work directory specify /WDIR on the command line while executing MSGTOSS. If a RAM disk, MSGTOSS will first copy the message base to the RAM disk (if en- ough room exists) and will purge the message base as required. After purging, MSGTOSS will then copy it back automatically. In addition, if paging excess users to the disk is required, MSGTOSS will use the work directory for faster operation. If you put ANYTHING in this spot it must at minimum be a valid drive. CREATE LOG FILE --------------- MSGTOSS keeps a useful log of the activity after each mail event. The di- rectory of where this log file is created is specified by the LOGDIR-----> parameter. Here is an example of the log: MsgToss 2.0 01/03/92 - Report Date: 01-01-1992 00:27:06 9BA308A0.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0 9BA61FB7.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0 NET Page - 24 MSGTOSS Version 2.0 9BA80FE1.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0 9BC7D716.PKT To:@1:343/36@fidonet Fm:@1:343/300@fidonet 29 QMail 1.0 PURG&RNUM - GENEALM.DEF Purged: 141 Kept: 0 Users: 5 Set LMR EXPANDED - GENEALM.DEF from 1008 to 1361 PURG&RNUM - COMMM.DEF Purged: 73 Kept: 26 Users: 14 Set LMR PURG&RNUM - CLIPPERM.DEF Purged: 15 Kept: 79 Users: 5 Set LMR PURG&RNUM - CONSULTM.DEF Purged: 4 Kept: 76 Users: 2 Set LMR PURG&RNUM - COOKINGM.DEF Purged: 98 Kept: 0 Users: 3 Set LMR EXPANDED - COOKINGM.DEF from 800 to 850 PURG&RNUM - C_PRGMM.DEF Purged: 40 Kept: 43 Users: 6 Set LMR PURG&RNUM - OS2M.DEF Purged: 25 Kept: 76 Users: 2 Set LMR PURG&RNUM - QUIKBASM.DEF Purged: 10 Kept: 96 Users: 7 Set LMR PURG&RNUM - SCIENCEM.DEF Purged: 19 Kept: 50 Users: 5 Set LMR PURG&RNUM - SPORTSM.DEF Purged: 35 Kept: 54 Users: 6 Set LMR PURG&RNUM - TECHM.DEF Purged: 51 Kept: 53 Users: 6 Set LMR PURG&RNUM - RBBSM.DEF Purged: 4 Kept: 92 Users: 25 Set LMR 9BA308A0.PKT Tot: 110 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0 9BA61FB7.PKT Tot: 87 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0 9BA80FE1.PKT Tot: 15 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0 9BC7D716.PKT Tot: 7 Dup: 0 Skip: 0 1:343/300@fidonet 29 QMail 1.0 /TOSS/PREP/FIXC/NSTOP/DDA/WDIR/LOCK/DLOG/MUSER:3 MailWaiting ------------------- AREA Name Domain Recd Dups Kept Sent UMsgs USet SYSOP ---------------------- -------- ----- ----- ----- ----- ----- ----- ----- COMM fidonet 56 0 56 0 0 0 0 CLIPPER fidonet 14 0 14 0 0 0 0 CONSULTING fidonet 4 0 4 0 0 0 0 QUIK_BAS fidonet 19 0 19 0 0 0 0 SCIENCE fidonet 14 0 14 0 0 0 0 SPORTS fidonet 38 0 38 0 0 0 0 TECH fidonet 51 0 51 0 0 0 0 RBBS-PC fidonet 2 0 2 0 0 0 0 NET343 fidonet 2 0 2 0 Fido NET_DEV fidonet 1 0 1 0 Fido ------------------------------------------------------------------------- Totals -- Skipped: 1 -- 726 0 726 0 0 0 0 Anal: 1.1 Prep: 1.4 Toss: 2.6 Mwait: 0.6 Tot: 5.7 Toss/Min: 278 MSGTOSS 2.0 provides a list of the purging activity, the *.PKTs processed, how many messages were in each *.PKT, how many DUPS, how many messages were skipped due to bad message headers, over sized messages, which mes- sage bases were expanded, etc. In addition, it provides the command line switches that were used when executing MSGTOSS. It provides the sysop with a summary of the mailwaiting status of his system, including himself, and a summary of how many messages were skipped and the time needed to complete the major operations of MSGTOSS, including the tossing through- put. NOTE: The creation of the MSGTOSS.LOG file is automatic. It is up to you to delete it at regular intervals. Its location is determined by the LOGDIR----> parameter. Page - 25 MSGTOSS Version 2.0 CREATE MISC BAT/CMD/CTL FILES ----------------------------- MSGTOSS was designed to be extremely flexible, therefore, various system- related utility batch files can be automatically created. The only message bases reported are only those which have received new messages. These BAT/CMD/CTL files are automatically deleted each time MSGTOSS is executed, therefore the maintenance they call out should be executed immediately af- ter executing of MSGTOSS. This can be used for a variety of tasks, where the replacement parameters available are [MSGFILE], [USRFILE], [WELFILE], and [AREA]. The parameters ONLY apply to RBBS message bases, and not Fido sub-directories. Here is a sample of a UTIL(s) commands being used to create automated batch files for SUBJECT utility: UTIL1------->SUB.BAT UTIL1CMD---->SUBJECT I:[MSGFILE] O:[WELFILE] C:[AREA] F:C Will create a file called SUB.BAT for all those message bases that actually received messages (RBBS only!). Example: You receive echomail in the following message bases: C:\RBBS\RBBSM.DEF, RBBS-PC C:\RBBS\COMMM.DEF, COMM C:\RBBS\COOKM.DEF, COOOKING and you have the above UTIL1 commands, MSGTOSS will create SUB.BAT, that would look like the following: SUBJECT I:C:\RBBS\RBBSM.DEF O:C:\RBBS\RBBSW.DEF C:RBBS-PC F:C SUBJECT I:C:\RBBS\COMMM.DEF O:C:\RBBS\COMMW.DEF C:COMM F:C SUBJECT I:C:\RBBS\COOKM.DEF O:C:\RBBS\COOKW.DEF C:COOKING F:C The templates [MSGFILE], [WELFILE] & [AREA] are dynamically replaced, cre- ating the batch file that can execute SUBJECT.EXE (a very fine utility that automatically creates welcome files for conferences). Immediately after the toss SUB.BAT needs to be executed, as the next time MSGTOSS is executed, it will delete the batch file automatically. NOTE: MSGTOSS will only replace message bases that contain 'M.DEF'. For the main RBBS message base 'MESSAGES', a line would NOT be created. Page - 26 MSGTOSS Version 2.0 SCAN ---- The /SCAN switch is what enables MSGTOSS to send all new messages created on your system to your host or boss node. The messages can be in the form of RBBS message bases (M.DEF) or FIDO messages (#.MSG). MSGTOSS can scan (export) new mail for both formats, either or both simultaneously. In ad- dition, for hub work, it has the capability to rescan a certain area for a particular net/node using the /RSCAN switch. It also does a few other use- ful features. Related MSGTOSS.BBS keywords: PRIV:x, GATE:x, NODE:x, CDUP:x and NBBS: Related command line switches (see MSGSWI.DOC for more info) /SCAN /RBBS /FIDO /LOCK /FIX /FIXC, /DDA (basic) /RSCAN: /HWM /CFG: /BBS /WDIR /AREAF: /AREA: (advanced) PRIVATE MESSAGES ---------------- Configured by the MSGTOSS.BBS keyword PRIV:x, you can tell MSGTOSS what to do in the event of finding a private message while scanning. Here are the basic rules: If COMMENT will not be exported (ever) If PRIVATE and TO:SYSOP will not be exported If PRIVATE and TO:USER and PRIV:1 then export (priv set) If PRIVATE and TO:USER and PRIV:0 then DON'T export The term USER means an active user in the U.DEF for the specified M.DEF. If the message is an authorized private message, MSGTOSS will set the pri- vate bit for the message. For more information, see PRIV:x in MSGBBS.DOC. SCANNING PHILOSOPHY ------------------- Feeding NODES is a function of /FEED, and is --> NOT <-- done from RBBS message bases. Basically this means that the exporting of mail via the /SCAN is ONLY intended for "locally" entered mail, and also for re-scanning to a net/nodes when needed. Reasons (also see EXCEPTION): MSGTOSS does NOT follow the same rule like RBBSMAIL where it builds a new message bases to insert the SEEN-BY and PATH lines. The SEEN-BYs and PATHs are exported, but the message base does NOT physically change. Any exist- ing SEEN-BYs and PATHS in RBBS message bases are simply ignored, and MSGTOSS will export a short SEEN-BY and PATH that only contains your system and the nodes it feeds. The requirement to re-build a message base while scanning is not desirable, (sorry RBBSMAIL) as this prevents the ability to SCAN while users are on -line. The MSGTOSS method allows absolutely safe scanning of mail continu- ously, even if 20 nodes are active. Page - 27 MSGTOSS Version 2.0 This makes it practical to always use the FMAS:1 bbs keyword, because in theory your downstream nodes have ALREADY feed via the /TOSS/FEED. Clear? EXCEPTION: If you are re-scanning from a FIDO area (#.MSG), MSGTOSS will correctly maintain the SEEN-BY: and PATH: lines. The reason is that MSGTOSS tosses SEEN-BY and PATH lines to a FIDO area, but not (usually) to an RBBS message base. MIRROR SCANNING --------------- MSGTOSS 2.0+ provides a notable feature called "mirror-scanning", where if you have a double-tossed area (RBBS + FIDO, for one area), then if a user entered a message in the RBBS conference, when exported, will also create a "carbon copy", complete with Origin: line, in the Fido-Style directory as well. The same applies to when a user (or yourself) enters a message in a Fido-Style conference, when exported, will create a carbon copy in the RBBS message base. There are four phases to a scan operation: 1 Initialization 2 Scan RBBS message bases 3 Scan FIDO message areas 4 Creates Log File INITIALIZATION -------------- During initialization, MSGTOSS will read your MSGTOSS.BBS to see who your host, points, and feeds are. It will also check the nodelist to see if it is current. If your nodelist is not current it will give you a warning and continue processing. If you specified the /LOCK command it will enable the appropriate file locking method in accordance with the LOCKTYPE----> parameter prior to scanning. NOTE: The whole /SCAN operation can be executed safely even though us- ers are on-line, as MSGTOSS will use full multi-tasking/network record locking protocols (using /LOCK, as defined by LOCKTYPE-- --->) during a /SCAN, allowing fully safe scanning. NOTE: MSGTOSS expects all of your RBBS message bases and fido directories to properly exist prior to scanning. You should have run /TEST be- fore this to make sure you are properly setup, as /TEST will also check for these directory conflicts. It will also tell you if you are missing a message or user base. If the bbs keyword CDUP:1 (check for duplicates) is active, MSGTOSS will load all of its keys into memory. MSGTOSS will store all of the MSGID CRC codes into the MSGTOSS.EID file after it exports a message. During a /TOSS operation, if the same message shows up (maybe caused by an improper host link), it will be ignored. For more information, see CDUP:x in the MSGBBS.DOC file. NOTE: To obtain the fastest scanning/tossing throughput, avoid using CDUP:1 (use CDUP:0) unless you have a real problem with duplicates. Page - 28 MSGTOSS Version 2.0 SCAN RBBS MESSAGE BASES ----------------------- To initiate the scanning of RBBS message bases, you need to specify /RBBS on the /SCAN command line. MSGTOSS will first attempt to read the High Wa- ter Mark (HWM) in each of the RBBS message bases. For RBBS message bases, this is located in position 121-122 of the checkpoint record. The HWM is stored as the RECORD number of the HWM message. If the HWM is valid (i.e. the record number is a true header), MSGTOSS will ignore all previous mes- sages prior to this record. See /HWM & /SCAN (in MSGSWI.DOC) for more in- formation. NOTE: During a MSGTOSS purge operation (/SIZE or /PREP), MSGTOSS will reas- sign the HWM to its new value automatically. WARNING: If you decide to use another purging utility (CONFIG, MU-PURGE, HUH, etc.), then the HWM located at position 121-122 will become screwed up! For the most part, MSGTOSS will figure out that the HWM is not proper, and start scanning from the first message. Us- ing another purging utility will cause the MSGTOSS /SCAN operation to be slower. NOTE: The /HWM switch provides a means of forcing MSGTOSS to ignore the HWM, and start scanning from the first message. If you have used an- other purging utility, or you are not sure if a message was exported, try using the /HWM switch. While scanning an RBBS message base, MSGTOSS will look at the second digit of the TIME field (position 64 of the message header) for the presence of a ':' (colon), and if present, will export the message. After exportation, MSGTOSS will change this colon to a '.' (period) to 'MARK' it as being scanned. NOTE: This is the same scheme that RBBSMAIL uses to mark messages as scanned. When MSGTOSS has finished exporting an M.DEF message, it will append a '<XMT>' to the bottom of the message, allowing users or the sysop know that the message has been exported. During a MSGTOSS purge operation (/PREP or /SIZE), MSGTOSS will replace these <XMT> lines with the defined origin line (can be configured via ORGN: keyword(s)). The reason for this odd method is to allow full scanning features while users are on-line. NOTE: MSGTOSS will NOT fragment the RBBS message bases during a /SCAN oper- ation (or /TOSS for that matter!). MSGTOSS will open *.OUT files to their respective net/nodes, as defined by the net/node listing for each area in the MSGTOSS.BBS file. During the scan session, these *.OUT packet(s) are generated on the fly and closed at the end of the scan process. NOTE: MSGTOSS uses the *.OUT format, which is a standard format used for many Fidonet compatible systems. These *.OUT files are normally packed by a program called Ommm (1.5+ recommended) and some other packers. If you are running a file-attach mailer (Frontdoor, Page - 29 MSGTOSS Version 2.0 DBridge, etc.) you will need a special packer that will convert these *.OUT files to support their file-attach method. MAKEARC is a recom- mended packer for these types of systems. During its search of the RBBS messages bases it will give you a display on the screen of what it is doing and what it found in each message base. This is a typical display for a few RBBS message bases. Scanning Message Bases Msg New Num Num Msgs Total Area Name Domain MsgBase Num Msgs Priv Nodes Sent Sent --------------------- -------- ------- ----- ----- ----- ----- ----- ----- MAC fidonet MAC 339 6 0 4 6 24 APPLE fidonet APPLES 529 1 0 1 1 1 ASKACOP2 fidonet POLICE 334 0 0 0 0 0 AMIGA_PROG fidonet AMIGAPR 45 0 0 0 0 0 Because there are 4 nodes that get files from the MAC area the total mes- sage sent out was 24 (4 * 6). Most people will just be sending messages to one place and then the second line would be much more common. The 'Num Priv' column indicates the number of private messages exported. SCAN FIDO MESSAGE AREAS ----------------------- To initiate the scanning of FIDO message areas (#.MSG), you need to specify /FIDO on the /SCAN command line. It will use the MSGTOSS.BBS to find the path to these messages, use its high water mark (1.MSG) and SEEN-BY lines to determine which net/nodes the message needs to be sent to. When ex- porting a FIDO message (#.MSG), MSGTOSS will set the 'sent' bit, preventing re-exportation. The On screen display will look like this. Scanning Message Bases Msg New Num Num Msgs Total Area Name Domain MsgBase Num Msgs Priv Nodes Sent Sent --------------------- -------- ------- ----- ----- ----- ----- ----- ----- NET935 rbbsnet *.MSG 55 2 0 4 4 16 RBBS_MSGTOSS rbbsnet *.MSG 101 1 0 1 1 1 RBBS-ADA rbbsnet *.MSG 98 5 0 2 5 10 After going thorough all the areas it will then close the *.out files and display the time it took to do the scan and provide listing of the ad- dressees the packets are going to and how many messages were sent to each address. Here an example: Scanning took 17.4 seconds. Sent 40 message(s) to 1:271/270@fidonet Sent 2 message(s) to 1:271/260@fidonet Sent 10 message(s) to 1:271/280@fidonet You now have the *.OUT file(s) in your OUTBOUND-----> directory(s) for the domain that it was created for. These *.OUT files will still need to be packed by the appropriate packer (Ommm for Binkley systems, MAKEARC for file-attach systems). Also see OUTBOUND----> in MSGCFG.DOC for more Page - 30 MSGTOSS Version 2.0 information on this. RE-SCANNING TO NET/NODES ------------------------ If you are a hub, you can have MSGTOSS re-scan messages to new net/nodes. For more information, see /RSCAN:xxx,xxx,xxx in MSGSWI.DOC. Also throughly understand the MSGTOSS scanning methodology as discussed in this section. CREATE LOG FILE --------------- MSGTOSS after the completed scan will copy the exact display you saw on the screen to the MSGTOSS.LOG file. If the file doesn't exist it will cre- ate it. So you can delete it any time you want, But not during processing please. Page - 31 MSGTOSS Version 2.0 DOMAIN & ZONE AWARENESS ----------------------- Alot of mail processors CLAIM to be ZONE and/or DOMAIN aware. What does that mean? The authors of MSGTOSS really mean business when we claim MSGTOSS is domain/zone aware, more than any other known mail tosser, and by all means any other RBBS-PC mail processor. DOMAINS & ZONES - DEFINED ------------------------- A domain is defined to mean any combination of ZONES/NETS & NODES within a particular boundary. For instance, Fidonet, Rbbs-Net, Sig- Net, Alternet, Eggnet, etc.. are each a unique domain. Per definition, each domain may have combinations of zones, nets and nodes which may overlap between other domains. For instance: 1:343/300.0@fidonet 2:343/300.0@fidonet 1:343/300.0@Sig-net 1:343/300.0@Zak-net All are perfectly fine, although the same net & node are the same, the zone/domain is different, and they each have unique identifiers. THE BASIC PROBLEM ----------------- Mosts mail processors are not that smart, and only provide the NET and NODE of the PKT. Some mail processors provide the ZONE of the packet. Generally, if identical mail processors pass mail back and forth, and they both support zones then a great deal of accuracy can achieved as far as zone-awareness is concerned. If a message is ad- dressed to 1:343/36@fidonet, and I am that address, no problem. However if mail is being routed THROUGH you, and was packed by a zo- ne-dumb packer, even the so-called zone-aware mail processors would have no idea what zone it is, and will probably toss the message into the default zone directory. MSGTOSS has totally eliminated the basic problem and positively identifies the domain & zone, even though the sender was using a zone-dumb processor. MSGTOSS accomplishes this via its own proprietary nodelist which is updated/created along with the weekly nodelist pro- cessing (this is explained further in the document). Along with some clever programming and logical guessing, MSGTOSS will be able to fig- ure out the correct origination & destination domain/zone/net & node of the PKT, and even provides an assessment as to the reliability of the domain/zone identification procedure. This is further processed by tossing the message into a separate NETMAIL directory for each unique DOMAIN. For instance, if you be- long to both Fidonet and Rbbs-Net, you could have two separate directories, one for each domain. For instance: C:\NMAIL\RBBSNET\ C:\NMAIL\FIDONET\ Page - 32 MSGTOSS Version 2.0 This is configurable via the ZONETYPE----> parameter. For all netmail, you can configure the following: ZONETYPE 1 - Singled directory for all netmail from ALL domains & zones ZONETYPE 2 - Mult directories for each unique domain (as above) ZONETYPE 3 - Mult directories for each unique zone within each domain During system setup or debugging (/TEST switch), MSGTOSS will complain loudly if it finds inconsistencies between ZONETYPE and directory structure. For echomail, you define what domain a particular echomail conference belongs to. The zone is not important, as most conferences are shared via multiple zones per domain. For instance, the Fidonet RBBS- PC echo is echoed throughout Fidonet (a domain) and not just one zone. On the other hand, Rbbs-Net also has an RBBS-PC echo, which is gate routed to them. Any other mailprocessor would get confused, but MSGTOSS is able to keep the two conferences (Fidonet & Rbbs-Net) to- tally separate, even though they have the same name! This is accomplished by the destination address of the PKT. For instance, suppose you received two echoes by the same name, but a different do- main: Your addresses where: 1:343/36.0@fidonet 8:918/10.0@rbbs-net Each having a totally separate conference area called 'RBBS-PC' If a host sends echomail to 8:918/10, then RBBS-PC messages will be tossed into the totally separate RBBS-PC conference/directory as defined for domain rbbs-net, and leave the defined fidonet con- ference alone. No other mail processor in the world provides this amount of domain/zone separation capability. Page - 33 MSGTOSS Version 2.0 NETWORK/MULTI-TASKING SUPPORT ----------------------------- When using the /LOCK command line switch, MSGTOSS will use RBBS NETBIOS, DESQVIEW, PC-NET or 10-NET conventions in accordance with the LOCKTYPE---> parameter. This is used during tossing, scanning, purging, renumbering, & sizing message bases. Because purging can sometimes take long periods of time (especially if executing in a slow background DESQVIEW window), MSGTOSS supports two special CFG parameters, LOCKWAIT---> and LOCKTIME--- >. Both of these CFG parameters affect purging/tossing/resizing opera- tions. MSGTOSS will lock and un-lock the message base using the proper RBBS conventions whenever necessary, but due to MSGTOSS's speed these pa- rameters were required to slow it down in a controlled manner. If LOCKWAIT---> is a value greater then 0, whenever MSGTOSS releases a message base it will WAIT xx seconds prior to continuing. The XX can be as small as ".01" so extremely small amounts of delay are possible. The idea behind the wait is to allow other nodes a chance to lock the message base (while another user is entering a message) and MSGTOSS is forced to wait until the other node is finished. If LOCKTIME---> is a value grater than 0, then whenever MSGTOSS locks a message bases LONGER than XX seconds (5 seconds recommended) it will stop what its doing (purging/tossing/resizing), reset the message base check- point records, wait for LOCKWAIT---> seconds, then continue what it was doing. This allows other nodes a chance to break in while MSGTOSS is doing a long purge or other operation. MSGTOSS will (during /TOSS & /SCAN) flash "status" lights in the lower right-hand corner of the screen indicating if a message/user base is locked. EFFECTS OF PURGING WHILE USERS ARE ON-LINE ------------------------------------------ It should be noted that no ill effects have been noticed during exten- sive beta testing as to the effects of purging messages while users are on-line, however, some anomalies exist that are noteworthy. If a user is active in a conference while MSGTOSS is busy purging messages, the user may become confused as to why messages suddenly disappear. This is normal, as when the user joined the conference, all of the locations of the message headers were written into memory by RBBS-PC, and RBBS-PC doesn't expect these locations to change. This doesn't seem to hurt the message base. When MSGTOSS finally gets around to actually tossing messages, then messages will suddenly re-appear, most likely garbled, as mentioned earlier, RBBS-PC expects the headers to be where they were when the user first joined the conference. The usual response of the user is to: 1) Panic (what did I do!) 2) Hang-up and call again 3) Re-join the main message base and enter a COMMENT to the Page - 34 MSGTOSS Version 2.0 Sysop stating that something is wrong. NOTE: If you find this intolerable, you can elect to simply use the /PREX (pre-expand) switch and the user will never be affected by this. However, remember that pre-expanding the message will re- quire it to be chopped down "SOONER than LATER" (quote from George Bush prior to attacking IRAQ) via the MSGTOSS /SIZE switch. However, an astute user can simply enter the '[P]ersonal Mail' func- tion to re-load all of the message header keys and all will return to normal (assuming MSGTOSS is done). If a user was busy entering a message base during this time peri- od, he/she shouldn't be affected while MSGTOSS was in the back- ground. RBBS-PC will first obtain updated checkpoint information from the message base prior to writing the message information, and MSGTOSS is constantly updating this record during its purging process. MSGTOSS never expects another process to be purging message bases at the same time it is! What this equates to is attempting to run TWO (or more) MSGTOSS processes at the same time is asking for corrupt message bases! However, if you must do this (reasons unknown to my- self) you can avoid problems by having each MSGTOSS process use a different MSGTOSS.BBS file, to make sure they don't collide by purg- ing the same message base. Theoretically, TWO (or more) MSGTOSS pro- cesses can exist during TOSSING, but purging is where problems may arise. For the most part, most users will be unaffected by MSGTOSS purging in the background, other than the speed of the system will show it. NOTE: As of this writing, a rather irritating bug exists in RBBS-PC, where if a NEWUSER is logging on, RBBS-PC will lock the USER base until the user has succesfully (totally finished) logs on. This equates to MSGTOSS waiting (flashing user base flag) until the NEWUSER is fin- ished answering all of the questionnaires, etc. This is the only known cause of MSGTOSS seeming to apparantly LOCK-UP (with locking status lights). If you notice this, its RBBS, not MSGTOSS. MSGTOSS AS A USER ----------------- While MSGTOSS is busy in the background, you can have it constantly update one of the RBBS-PC node-records of the main message base via the /MUSER:x command line switch, where x is the node number MSGTOSS will permanently occupy. A user entering [W]ho else is on can see something similar: Node 1 Online at 9600 BAUD: SYSOP KENT ,WA Node 2 Online at 2400 BAUD: JOHN HENDRICKS SEATTLE,WA Node 3 Online at 9600 BAUD: MsgToss 2.0-Mail System PURGING MSG BASES For more information, see MSGSWI.DOC on this. Page - 35 MSGTOSS Version 2.0 INSTALLATION ------------ MSGTOSS is a very extensive program and covers every aspect required for a ECHOMAIL tosser and scanner. If this is your first time trying to use MSGTOSS, I advise you use all the default examples listed. If you have a problem, use the reference manuals to fine tune that area. This section will try to lead you through the installation process Step by Step. MSGTOSS probably should be in a directory all by itself. This will help you understand what files are for it and what it does. You will need to find a drive that has enough room which is about 600K for a small system and up to about 1.5 meg for systems that have around 120 echomail areas. The MSGTOSS.LOG will increase in size during each action taken. Another variable is the MSGTOSS.EID table. It's size is controlled by the MSGTOSS.CFG file. Other than these concerns nothing should matter where you put it. The echomail packets that you get can go anywhere, as long as you inform MSGTOSS where they are (via FILES-------> parameter(s). We will be using C:\MSGTOSS as the drive for the setup. There are 11 steps to installing MSGTOSS: 1) Create MSGTOSS directory 2) Copy files to MSGTOSS directory 3) Print & read documentation 4) Modify sample MSGTOSS.CFG 5) Modify sample MSGTOSS.BBS 6) Modify default MSGTOSS.BBS Keywords 7) Create MSGTOSS.NOD using MSGNLST.EXE 8) Test system setup 9) Mail tossing test 10) Mail scanning test 11) Batch file modification. CREATE MSGTOSS DIRECTORY ------------------------ Although having its own directory is optional, it may simplify things to begin with. Personally, I placed it in the same directory where the mailer is, like C:\BT\ or C:\FD, or whatever. Or maybe C:\MSGTOSS COPY FILES TO MSGTOSS DIRECTORY ------------------------------- Copy all the files from the registered disk into your directory or all the files from the shareware disk and un-compress them into your selected di- rectory. The following files are required to run MSGTOSS. MSGTOSS.COM (program: Spawns MSGTOSS1.OVR) MSGTOSS1.OVR (program: Main MSGTOSS overlay file) Page - 36 MSGTOSS Version 2.0 MSGNLST.EXE (program: Nodelist compiler, creates MSGTOSS.NOD) MSGHELP.EXE (program: DOS-help for setting up MSGTOSS) MSGEID.EXE (program: EID database maintenance utility) MSGTOSS.BBS * (modify ... to suit your message bases) MSGTOSS.CFG * (modify ... to suit your system configuration) MSGTOSS.CMD * (modify ... MSGTOSS metacommands - advanced) MSGTOSS.PCD (contains product codes for all known mailers) MSGTOSS.EID (created by MSGTOSS - EID database for dup checking) MSGTOSS.NOD (created by MSGNLST from raw nodelist(s)) MSGTOSS.DOC \ (this file) MSGCFG.DOC \ MSGBBS.DOC > Printing (and reading) these are mandatory! MSGSWI.DOC / MSGIDX.DOC / (Integrated INDEX) After you set up Msgtoss it will create a few others that are necessary to run itself. PRINT DOCUMENTATION ------------------- Print out all of the documentation for MSGTOSS, especially the MSGCFG.DOC, MSGSWI.DOC, and MSGBBS.DOC, as you will be referring to them alot during setup. READ DOCUMENTATION ------------------ Yes there is alot of documentation associated with MSGTOSS. Make addition- al copies for your livingroom, bathroom, bedroom, and work areas (just kid- ding). You really need to grasp the total picture of how it all fits to- gether, and the only way to do this is to read it. MSGTOSS is really not one of those programs you can just un-arch, find the BAT or EXE files, and just enter it at the command line. You can, however, just enter: MSGTOSS <rtn> And a summary of the command line switches will appear. You will appreci- ate it later when you try to figure out what command line switches to use. For now, just know that MSGTOSS <rtn> will provide some assistance at a later time, AFTER YOU READ THE DOCS! Quite possibly every question you have is probably answered in the documen- tation. Remember... RTFM (read the *uckin manual). Also, don't overlook the MSGIDX.DOC integrated INDEX. Should point you to all references for a given major subject. Use it to get the most out of the documents. Page - 37 MSGTOSS Version 2.0 MODIFY SAMPLE MSGTOSS.CFG ------------------------- Since you took heart to the last paragraph, you shouldn't have any problems what-so-ever modifying your MSGTOSS.CFG file properly. Most of the parame- ters are already set up for you... Here are the critical ones you MUST mod- ify (and understand) before continuing: CRITICAL MSGTOSS.CFG PARAMETERS ------------------------------- Address related parameters -------------------------- DOMAIN------>fidonet.org 1 C:\MAIL\nodelist NODE-------->1:343/36.0@fidonet POINTNET---->30174 (only if you support points) REMAP------->1 Rich Englich (only if you support points) NOTE: The NODE--------> parameter(s) are extremely critical, as it is tied to the MSGTOSS.BBS keyword 'NODE:x'. You MUST thoroughly understand how these are linked. Read MSGCFG.DOC and MSGBBS.DOC for more information. NOTE: The DOMAIN------> parameter(s) point to where all of your Saint Louis Format nodelist(s) are. These are used by MSGNLST.EXE to create MSGTOSS's proprietary nodelist called MSGTOSS.NOD. NOTE: The POINTNET----> and REMAP-------> parmameters can be blank if you don't support points. Mail and File Forwarding authorizations --------------------------------------- MAILFROM---->1:343/* 8:918/* MAILTO------>1:343/* 8:918/* FILEFROM----> FILETO------>1:343/* 8:918/* NOTE: Only used for mail/file routing. If you are not a hub, set all of these to simply "" (blank), meaning no routing. If you do route, thoroughly understand how you can shoot yourself in your pocketbook by incorrectly setting these <grin>. Sysop key names --------------- SYSALIAS---->SUPER TOSSER SYSNAME----->!MIKE ZAKHAROFF SYSNAME----->=SYSOP NOTE: The FIRST sequential SYSNAME-----> must be your FULL public name, preceded by an "!" (as above). This is the name MSGTOSS will place in outgoing messages from the SYSOP. Miscellaneous directories ------------------------- Page - 38 MSGTOSS Version 2.0 FILES------->C:\MAIL\FILES\ OUTBOUND---->C:\OUTBOUND\ WORKDIR----->L:\ Two important RBBS message bases -------------------------------- MESSAGES---->C:\RBBS\MESSAGES BLANKMSG---->C:\RBBS\BLANKM.DEF NOTE: If you are running MSGTOSS on a non-RBBS system (you are only supporting #.MSG messages), then you MUST set both of these to "" (blank). An entry here tells MSGTOSS that you are running a full-blown RBBS system. Multi-tasking/network support ----------------------------- LOCKTYPE---->NETBIOS RBBS purging related parameters ------------------------------- YEAR-------->1992 Duplicate checking related stuff -------------------------------- MAXAREAS---->100 DUPSIZE----->500 NOTE: The above critical parameters are in the same order as the sample MSGTOSS.CFG. You should attempt to understand all of the other pa- rameters (besides the above) too, as you will want to become familiar with them at a later date. IF YOU ARE NOT RUNNING RBBS-PC ------------------------------ If you wish to use MSGTOSS for just its #.MSG support, and don't need or care to use its exclusive RBBS-PC functions, set the following MSGTOSS.CFG parameters to blank: MESSAGES-----> BLANKMSG-----> This will tell MSGTOSS that you are strictly running a #.MSG system (like Qmail, Confmail, etc.). Don't try using /LOCK. Page - 39 MSGTOSS Version 2.0 MODIFY SAMPLE MSGTOSS.BBS ------------------------- Assuming you have read the MSGBBS.DOC file with great interest, you are now ready to modify the sample MSGTOSS.BBS file to suit your system. You will need to refer to MSGBBS.DOC constantly during modification, especially when configuring the BBS keywords. If you have no idea what an MSGTOSS.BBS "keyword" is, you should STOP here, READ the MSGBBS.DOC, and continue on. Here are some high-level basics, not intended to replace the reference man- ual. MSGBBS.DOC is a pretty good reference, and should answer any ques- tions you have. You MUST understand its concept, as its more complicated than a regular AREAS.BBS file. We will start with the RBBS message bases first. If you are already running RBBSMAIL, CONFMAIL, or QMAIL, simply copy your existing AREAS.BBS file as MSGTOSS.BBS, and make the necessary changes. For an RBBS message-base: C:\RBBS\rbbsm.def RBBS-PC 1:271/245 271/270 271 8:935/1 90:83/0 ^ ^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | | Path to messagebase | | | | | | AREA:TAG_NAME | | | | Who you Receive it from | | Who YOU send it to, but only if you are a HUB! Examples: C:\RBBS\lchatm.def LCHATTER 271/245 271/250 271/300 6666/10 C:\RBBS\lovem.def LOVELINE 271/245 A FIDO-style area (#.MSG): C:\MAIL\LCHATTER\ LCHATTER 271/245 271/250 271/300 6666/10 C:\MAIL\LOVELINE\ LOVELINE 271/245 Notice that the only difference between these two is that the first entry is a true sub-directory, ending with a trailing backslash. Modify MSGTOSS.BBS for all areas you support on your system. MSGTOSS has hard-coded AREAS with special names, these are: NETMAIL - Where non-echomail (Netmail) is tossed UNKNOWN - Where unidentified echomail is tossed ROUTETHRU - Where Netmail (not addressed to your AKAs) are tossed Page - 40 MSGTOSS Version 2.0 MSGCAPTURE - Where "captured" echomail is tossed NOTE: For all of the above special hard-coded areas, separate directo- ries must be defined for each unique Domain/Zone, as indicated by your ZONETYPE----> entry in your MSGTOSS.CFG. Refer to MSGCFG.REF for detailed information. NOTE: The AREAs NETMAIL and UNKNOWN are required for all MSGTOSS installations, where ROUTETHRU and MSGCAPTURE are optional. See MSGBBS.DOC for additional information on these special areas. As detailed in MSGBBS.DOC, it is recommended that NETMAIL be a "double- tossed area" where you have both FIDO area (#.MSG) and an RBBS message base (M.DEF). Here is an example: C:\RBBS\MAINM.DEF NETMAIL (no net/nodes listed!) C:\MAIL\NETMAIL.001 NETMAIL (no net/nodes listed!) The area UNKNOWN should be a FIDO area, as follows: C:\MAIL\UNKNOWN.001 UNKNOWN (no net/nodes listed!) NOTE: All areas except NETMAIL, UNKNOWN, ROUTETHRU & MSGCAPTURE should have at least one address present. MODIFY DEFAULT MSGTOSS.BBS KEYWORDS ----------------------------------- You must understand the concept of "keywords". Read MSGBBS.DOC if you are still confused as to what they are. Setting them incorrect will thoroughly screw things up! The following are the critical MSGTOSS.BBS keywords. All other keywords can be left as-is for now, until you better understand them. NODE:xxxx RECS:xxxx, ESEC:xxxx, GATE:xxxx, FMAS:x, SECL:x, USRH:x NODE: Tied to the MSGTOSS.CFG file. NODE:1 would be the first NODE address in your MSGTOSS.CFG file. NODE:2 means second, etc. NOTE: The keyword is extremely critical if you belong to multi- ple zones/domains (Fidonet & Rbbs-Net), as it is linked to MSGTOSS.CFG NODE--------> entries. Changing one (without changing the other) will probably screw things up. RECS: The number of records your message-base is using. It is listed in CONFIG Parameter # 165. This one can be different for each message area. If so you will need the size difference above each message area. NOTE: This is probably the most important keyword. Setting these wrong may chop your message bases in size. Thoroughly read MSGBBS.DOC on this keyword for sure. Page - 41 MSGTOSS Version 2.0 NOTE: When executing the /TEST function, MSGTOSS will report to you (bright white/red) whether you have any RECS:xxx set improperly. ESEC: The security the messages are set to. This is configurable for each area. If you have an Adult area that needs higher security levels for the messages put a -ESEC:20 in above the message- base line. BUT! Remember to set it back down to the lower lev- el, or else all following areas will have the same higher lev- el. GATE: Use GATE:2 (always!) FMAS: Use FMAS:1 (unless you thoroughly understand it) SECL: Use SECL:1 (unless you thoroughly understand it) USRH: Use USRH:1 (U.DEFs with few (less than 100) users, else 0) NOTE: Additional information on the above keywords exist in MSGBBS.DOC, and should be read (and understood) prior to configuring. Again.... You MUST read the purpose and function of all keywords so you can get the most out of their capabilities. Using the combination of the sample MSGTOSS.BBS file, MSGBBS.DOC, and common sense, you will figure it out. Patience! Page - 42 MSGTOSS Version 2.0 CREATE MSGTOSS.NOD USING MSGNLST.EXE ------------------------------------ MSGTOSS creates its own special nodelist called MSGTOSS.NOD. It will build this table using the nodelists you specify in your MSGTOSS.CFG file after the DOMAIN------>. It will then look at each listing and display information while it is executing. If there is a problem it will tell you at the end. Example: DOMAIN------>fidonet.org 1 C:\MAIL\NODELIST\nodelist DOMAIN------>rbbs-net.org 8 C:\MAIL\NODELIST\rbbslist The above point to two sets of nodelists. MSGNLST will only use the node- lists that have the greatest extentions. So if you have two nodelists (af- ter parsing) as follows: RBBSLIST.007, RBBSLIST.014 MSGNLST will choose the 014 nodelist, and ignore the 007 (older) version. Thoroughly read (and understand) MSGCFG.DOC section on DOMAIN------> and MSGSWI.DOC on /NLST before continuing on. Understand that compiling the MSGTOSS nodelist (MSGTOSS.NOD) should be done as part of your weekly nodel- ist processing (nodediffs, etc.). Somewhere in your batch file you need to change drive/directory back to where MSGTOSS.CFG is, execute MSGNLST.EXE, and then continue. This is the common output (of MSGNLST.EXE) at the beginning. The non-uni- que net/nodes are normal operation. You will see hundreds of them. ------------------------------------------------------------------------- MsgNlst version 2.0+ -- Copyright 1992 Mike Zakharoff, Warren Muldrow Enough memory is available for a maximum of 35606 nodes. Processing domain: fidonet Node list: C:\MAIL\NODELIST\nodelist.354 Non-unique net/node: 1:201/0@fidonet 2:201/0@fidonet Non-unique net/node: 1:203/0@fidonet 2:203/0@fidonet Non-unique net/node: 1:203/101@fidonet 2:203/101@fidonet ------------------------------------------------------------------------- MSGTOSS.NOD is created by running either: MSGTOSS /NLST <rtn> -- or -- MSGNLST <rtn> It will then look for the DOMAIN and files that you have listed in your MSGTOSS.CFG file. If it is all correct it will return you to the DOS prompt with no errors. It does display alot of NON-UNIQUE Node numbers, that is perfectly normal. It uses these to build itself an internal table. If you have errors it will probably be in your MSGTOSS.CFG. Most errors are because it couldn't find the nodelist files. This is corrected by changing the DOMAIN path and filename to the correct one. Page - 43 MSGTOSS Version 2.0 TEST SYSTEM SETUP ----------------- MSGTOSS has a built in test switch that allows you to test your setup. It will show you any problems that you have or any setup parameters that might have been messed up. It will test your files that can be open and all message-bases and give you a summary of all RBBS message bases. If you are getting weird data out of a message base, you should run FIXMSG.EXE on the message base. If it still does not fix it, delete the message base and create a new one. NOTE: See MSGSWI.DOC for more information on /TEST. ENTER the command: MSGTOSS /TEST What you should see.... ------------------------------------------------------- /TEST Initializing - MSGTOSS.CFG Initializing - No File Locking Active Initializing - MSGTOSS.BBS oooooooooooooooooooooooooooo ------------------------------------------------------- If you have a problem in this area it probably be with your MSGTOSS.CFG or you MSGTOSS.BBS files. The errors messages should be good enough for you to understand the problem. If not ... yes ... read some more docs! The next set of display items is be these. ------------------------------------------------------- Unique NET/NODE Index: 1 - 1:271/270@fidonet Unique NET/NODE Index: 2 - 1:271/271@fidonet ..... Unique NET/NODE Index: 37 - 65:511/1@ournet Unique NET/NODE Index: 38 - 65:511/236@ournet Unique Nodes Detected - 38 Minimum FILES=XX is 49 Max nodes for single area is 22 Default Origin line: * Origin: Virginia Data Exchange (804)877-3539 -2-Lines- FREE(Address) Press any key for file handle test -------------------------------------------------------- MSGTOSS is looking at your nodes and feeds to see if everything is correct. You need to look at each UNIQUE NET/NODE and make sure this are valid areas that you have or you send mail to. If there is something wrong with these address, then you probably have something wrong in your MSGTOSS.BBS file. If so, go back and redo steps 3, 4, 5 and 6. This step also gives you an IMPORTANT piece of information. It tells you how many more FILES are going to be needed for your MSGTOSS operation. Above it says Minimum FILES=XX is 49. What this means is to run MSGTOSS on a non multitasking system that is the most files that will be opened at Page - 44 MSGTOSS Version 2.0 once. But if you run other windows you will need to increase your CON- FIG.SYS by this number. THE NEXT SCREEN will be the file handling test. --------------------------------------------------------- Opening test file 1 ... Opening test file 42 Opening test file 43 Opening test file 44 Any key for DUPFILE test May create MSGTOSS.EID during this phase (if CDUP:1 was found) ..... Any key to for statistics ---------------------------------------------------------- This is another potential area for errors. MSGTOSS is making sure it can open all the files it needs for maximum operation. If you multi-task, you will probably need additional file handles, over and above to recommended values shown. All you need to do is increase the size of your CONFIG.SYS. THE NEXT SCREEN. MSGTOSS will give you statistics on each RBBS messagebase. ---------------------------------------------------------- Name Usr N Lvl Recs Used Free Full Msgs Msg Msg Size Cap Msg Msg ------- --- -- --- ---- ----- ---- ---- ---- ---- ---- ---- ---- ---- ----- IBM 486 4 0 2505 1563 942 62 500 1003 472 3.3 757 1003 10-09 MAC 66 4 0 1024 691 333 67 204 404 119 5.8 176 404 11-16 APPLES 13 4 0 2464 2178 286 88 492 259 259 8.4 293 259 12-09 AMIGAEC 16 4 0 6352 4329 2023 68 999 445 445 9.7 653 445 12-11 AMIGAME 12 4 0 1392 946 446 68 278 220 220 4.3 324 220 12-23 ATARI-8 4 4 0 992 670 322 68 198 521 90 7.4 133 521 12-16 ... etc. --------------------------------------------------------------------------- Tot:There are 14106 messages in 73 areas averaging 5.7 records per message. The 14.4 Mb allocated should hold 20474 total messages. There are 37203 unused records out of 118167 allocated. ---------------------------------------------------------- This screen is very useful in determining what the status is on all your RBBS messagebases. If you get weird numbers like -.9854 or any negative or fractions. You probably have a corrupted message base. It might still work, but the header information is bad. Try using FIXMSG.EXE on those messages to fix them. If that doesn't work delete them and rebuild them. During the /TEST display, MSGTOSS will pause every 23 lines allowing you to view the message bases. In addition, if any of your MSGTOSS.BBS REC:xxx keywords don't match the actual size of the message bases, MSGTOSS will re- port to you (white on red) the fact that this error exists. The messages is placed in the right-hand corner of the status line. The error would look similar to this: APPLES 13 4 0 2464 2178 286 88 492 259 259 8.4 293 RECS:500 ^^^^^^^^ White/Red Page - 45 MSGTOSS Version 2.0 In this case, MSGTOSS is complaining that the actual size of the message base is 2464, but your RECS:xxx value is set to 500. If you get this er- ror, fix the appropriate RECS:xxx keyword for these message bases. If the RECS:xxxx value is correct (what you really want it to be), then execute: MSGTOSS /SIZE-UP ...... other switches Then MSGTOSS will size your message bases (using smart-purging) so that your message bases MATCH the value set for RECS:xxx. NOTE: This is how easy it is to control the sizes of your message bases (no more need to use CONFIG!). Simply adjust the appropriate RECS:xxxx keyword(s), and execute the /SIZE-UP command line switch. For more information on sizing your message bases, see MSGSWI.DOC (/SIZE switches) and MSGBBS.DOC (on RECS:xxx). *************************** IMPORTANT **************************** * You should run the /TEST until all errors are gone and your * * FILES=XX in your CONFIG.SYS is corrected and all of your RBBS * * message-bases are corrected. You can also use the stats infor- * * mation to determine -RECS:xxxx is correct in your MSGTOSS.BBS * * file. * ****************************************************************** Page - 46 MSGTOSS Version 2.0 MAIL TOSSING TEST ----------------- Assuming the /TEST preliminary tests went ok, place a small mail packet (*.PKT) into your first FILES-------> directory (As listed in your MSGTOSS.CFG FILE) and test the tossing using.... MSGTOSS /TOSS /PREP <rtn> Did it work? If it didn't work.... try to determine the part that failed and go to that step and redo it. Then try again. A good understanding of how MSGTOSS works should help you understand what may have gone wrong. So if you can't get it to work correctly, consult the MSGTOSS THEORY section, along with MSGCFG.DOC, MSGBBS.DOC and MSGSWI.DOC. MAIL SCANNING TEST ------------------ If everything prior to this has work properly (hallelujah!), then the scanning test should be a piece of cake. Try entering the following com- mand at the DOS prompt.... MSGTOSS /SCAN /RBBS /FIDO <rtn> Did it recognize all of your message bases? It should have, if /TEST passed ok. See MSGSWI.DOC on /SCAN for more information on this. You can experiment by entering test messages into RBBS message bases, and seeing the result. A *.OUT file should have been created in your OUT- BOUND---> directory to your host for the test message. Now you need to pack it up. PACK UP MAIL ------------ For Binkley-type systems, Ommm (version 1.5+ recommended) is normally used to pack up (and archive) the *.OUT files. If using Frontdoor, or other types of file-attach mailers, you need to ob- tain a packer named MAKEARC (other types are available). Its function is to convert the *.OUT files created by programs like MSGTOSS and create a file attached message for these files. See example FRONTD.SET for more in- formation on using Frontdoor and MSGTOSS. The packer is normally executed after a /SCAN operation. Page - 47 MSGTOSS Version 2.0 COMMAND LINE SWITCHES --------------------- MSGTOSS provides alot of command line switches, for each major command line switch. You may want to experiment using the other common command line switches, such as /DDA etc. Read MSGSWI.DOC for the full array of command line switches available. An- other quick source for command line switches is simply entering at your DOS prompt: MSGTOSS <rtn> --or-- MSGHELP <rtn> Provides a summary of all of the command line switches for all major com- mand line switches, along with other references, such as a listing of the MSGTOSS.BBS keywords, errorlevel semaphore files, meta-commands, etc. Use it for a quick reference, but for more information, consult the appropriate reference manuals. 1) Toss RBBS, FIDO & NETMAIL messages -------> /TOSS 2) Scan (export) new locally entered mail ---> /SCAN 3) SIZE message bases to preset RECS:xxx ----> /SIZE 4) Reset users Mailwaiting Bit (all msgs) ---> /MWRST 5) Report on message base statistics --------> /STAT 6) Test MsgToss Setup Configuration ---------> /TEST 7) Wait for users, create MSGWAIT.BAT file --> /WAIT 8) Globally execute xxx for all msg bases ---> /GLOB:xxx 9) Recompile the node list (MSGTOSS.NOD) ----> /NLST 10) Execute MSGEID.EXE - EID Database Maint --> /EID 12) MSGTOSS.CMD metacommands - (no slashes) --> xxx 13) MSGTOSS.BBS Tossing Configuring Keywords -> xxx 14) MSGTOSS DOS ErrorLevel Codes -------------> Errorlevels It is recommended that you re-set all of your mailwaiting bits by issuing the /MWRST major switch at least weekly during MSGTOSS operation. Try it right now, as follows (but first read the /MWRST section in MSGSWI.DOC): MSGTOSS /MWRST <rtn> Great! Maybe now you can adjust all of the sizes of your RBBS message bases by issuing: ****** WAIT! ****** Do you throughly understand the purpose of the /SIZE switch(es)? You MUST make sure all of your RECS:xxxx entries in your MSGTOSS.BBS file correctly match your RBBS message bases (or you have them set to your wishes). Bet- ter re-read the /SIZE section of MSGSWI.DOC before issing the following command. MSGTOSS /SIZE (or /SIZE-UP) After you see their power, you will appreciate how easy it is to maintain tight control of size of your message bases. Page - 48 MSGTOSS Version 2.0 BATCH FILE MODIFICATION ----------------------- This assumes that you have decided that MSGTOSS is the greatest RBBS tossing utility you have ever seen, and are going to commit it to your system for full-time operation. Using the following batch file excerpt as a guide, test MSGTOSS to make sure it works as stated. It is highly recommended that you set up some sort of 'TEST-JIG' batch file to convince yourself that it works. Here is an example. Note that this can take on many different forms and this is just a PORTION of the batch file. WARNING!: Save your old setup, incase you can't seem to get MSGTOSS to work properly, its 2:00 am, and you are expecting a 1 meg packet any minute. In other words, don't shoot yourself in the foot. REM out your existing batch file commands FIRST, then when you are satisfied MSGTOSS is working perfect, then remove the old batch file lines (after a week). PACKET UNARCHIVING ------------------ SPAZ INFO - Command to issue to unarchived mail packets. Recommended to use SPAZ.COM, can handle ZIP, LHARC, ARC etc. SPAZ -F C:\MAIL\FILES C:\MAIL\FILES\ ------------- ---------------------------- Incoming Mail Where PKTS go for processing NOTE!! --> Where trailing back-slashes are! NOTE: MSGTOSS looks in the directory(s) specified by the FI- LES------> parameter(s) for PKTs. Therefore, the C:\MAIL\FILES\ SHOULD match the FILES------> entry. Page - 49 MSGTOSS Version 2.0 BATCH FILE EXAMPLE ------------------ ECHO OFF :START C: CD\MAILER Execute Binkley, Frontdoor, whatever.. If errorlevel XX Goto RECMAIL If errorlevel XX Goto SCAN If errorlevel XX Goto DAILY Goto START :RECMAIL C: CD\MSGTOSS MSGUNPK C:\FILES\ C:\FILES\ (or SPAZ, etc.) MSGTOSS /TOSS /PREP If exist C:\FILES\NODEDIFF.A* Goto NODELIST Goto START :SCAN C: CD\MSGTOSS MSGTOSS /SCAN /RBBS /FIDO ommm, makearc, qmail -pack, etc. REM REM Ommm for Binkley, Makearc for Frontdoor REM Goto START :NODELIST C: CD\NODELIST SYSNL .... whatever CD\MSGTOSS \ MSGTOSS /NLST > Added to nodelist processing! CD\NODELIST / FINISH ... Goto START :DAILY C: CD\MSGTOSS MSGTOSS /SIZE Goto SCAN Page - 50 MSGTOSS Version 2.0 HELP! ----- Help is available in the "RBBS_MSGTOSS" echo (Rbbs-Net) and the "RBBC-PC" echos (Fidonet & Rbbs-Net). In addition, the following beta testers may be able to help you as well. Ruediger Fuchs is of special mention, as he is on the other side of the pond (Europe). MSGTOSS BETA TESTERS +--------------------------------------------------------------+ | Jeff Cameron 1:3802/212 The Beanery BBS | | Jeff Cameron 8:928/105 The Beanery BBS | | Benny Carr 8:952/25 New Woodstk RBBS | | Ruediger Fuchs 2:245/32 E.De.Ka.- PC Mail | | Ruediger Fuchs 8:996/1 E.De.Ka.- PC Mail | | Craig Gagner 1:3626/1 The TACRBBS | | Craig Gagner 8:928/102 TACRBBS-PC | | Bill Hamel 1:273/308 T.T.C RBBS-PC | | Bill Hamel 8:952/5 T.T.C RBBS-PC | | Ken Humrich 8:914/701 Nwonknu Hq | | Tim Jacobs 1:271/271 Virginia Data Exchange 2400 | | Tim Jacobs 8:935/110 Virginia Data Exchange 2400 | | Warren King 1:275/429 HandiNet B B S | | John Kihl 1:129/119 E*COM | | John Kihl 8:928/104 E*COM | | Lawrence Kolada 1:327/452 The Plainfield News | | Lawrence Kolada 8:909/3 The Plainfield News | | Jan Maaskant 1:387/255 NUL | | Jan Maaskant 8:931/1 NUL | | Rick Moen 1:125/27 The Speptic's Board | | Rick Moen 8:914/207 The Speptic's Board | | Bob Moravsik 1:2606/583 Atrium Way | | John Morris 8:919/1 The Abandoned Land I | | Mark Simmons 1:121/16 Romany RBBS-PC | | Mark Simmons 8:972/1 Romany RBBS-PC | | Robert Stahl 1:246/16 Crystal Marine RBBS-PC | | Robert Stahl 8:952/161 Crystal Marine RBBS-PC | | Stan Staten 1:109/418 3 WINKs BBS | | Stan Staten 8:936/105 3 WINKs BBS | | Ray Waechter 1:273/303 KEYSTONE Net Exchange | | Ray Waechter 8:952/22 BusiLink (tm) Main Man | | Michael Walsh 1:273/917 Walsh MicroSystems | | Michael Walsh 8:952/14 Walsh MicroSystems RBBS-PC | | Jim Wargula 1:121/8 JW-PC DataFlex.HST | | Jim Wargula 8:972/2 JW-PC Dataflex | | Dave West 1:129/201 Info Exchange RBBS-PC #1 | | Dave West 8:928/301 Info Exchange RBBS-PC #1 | | Adam Zivitz 1:273/708 Garden of Eden | +--------------------------------------------------------------+ Page - 51 MSGTOSS Version 2.0 MSGTOSS BETA DISTRIBUTION MATRIX -------------------------------- A private echo called "MSGBETA" exists on the RBBS-NET backbone where beta development is discussed and files are distributed. The below represents the distribution system in-place for beta copies of MSGTOSS. Note that not all of these systems utilize MSGTOSS. Mike Zakharoff 1:138/154 (8:918/10) Warren Muldrow 1:3617/1 (8:928/1) Pvt Nodes Craig Gagner 1:3626/1 (8:928/102) +-- Ruediger Fuchs 2:245/32 (8:996/1) +-- Charles Arden 1:343/81 (8:918/11) +-- Tyronne Foy 1:264/152 (8:928/103) +-- Jeff Cameron 1:3802/212 +-- John Kihl 1:129/119 +-- Nathan Barber 1:366/3 (8:925/101) +-- Bob Dunagan 1:3617/5 (8:928/5) +-- Ray Waechter 1:273/302 (8:952/1) +-- Tim Jacobs 8:935/110 (1:271/270) +-- Bob Moravsik 1:269/583 +-- Stan Staten 1:109/418 (8:936/105) +-- Larry Kolada 1:327/452 (8:909/3) +-- Richard Couture 8:914/201 (1:125/41) | +-- Rod Bowman 8:8/0 (1:10/8) | | +-- Mark Simmons 8:972/1 | | +-- Jim Wargula 8:972/2 (1:121/8) | +-- Rick Moen 8:914/207 (1:125/27) +-- Jan Maaskant 8:931/1 (1:387/255) +-- Bob Stahl 8:952/16 +-- Michael Walsh 8:952/14 (1:273/917) +-- Dave West 8:952/12 (1:129/201) +-- Benny Carr 8:952/25 +-- John Bixler 8:952/15 +-- Bill Hamel 8:952/5 +-- John Morris 8:919/1 +-- Rob Keown 8:952/81 (1:273/718) Page - 52 MSGTOSS Version 2.0 ERRORS ------ MSGTOSS will (if it encounters a severe error while processing a *.PKT file) delete the corresponding *.IDX file, and rename the *.PKT to *.BAD to prevent MSGTOSS from processing it again. You may want to test for the condition of *.BAD in you batch file to alert you. In addition, MSGTOSS will (whenever possible) continue on processing even though it came upon a severe error. MSGTOSS creates a MSGTOSS.ERR file that contains things it couldn't handle, but processed anyway (or ig- nored), like trashed message headers, severe errors, etc. Again, you may want to test for the existence of MSGTOSS.ERR as part of your batch file. MSGTOSS.ERR should be reviewed periodically. If you keep extremely large message bases over 4000 (RBBS-MAX * 4) re- cords, it is possible for your message bases to exceed the RBBS-PC maxi- mum of 999 (RBBS-MAX) messages per message base. Therefore MSGTOSS will do a "pre-count" of the messages prior to tossing. This "pre- count" is automatic and is triggered only when MSGTOSS senses the over 4000 record (RBBS-MAX * 4) message base. In the event of an "overflow", MSGTOSS will not allow any more messages to be imported into the message base, but will allow other message bases to be processed as normal. After the *.PKT is tossed normally, MSGTOSS will re-name the *.PKT to *.OFL (for overflow) and log the occurrence of the overflow into the MSGTOSS.LOG and MSGTOSS.ERR files. The sysop can then elect to fix the overflow problem, or simply delete the *.OFL file. Tossing of selected echoes are possible via the /AREA: com- mand line switch(es) (see /AREA: & /AREAF:" switch). NOTE: It should be noted that the possibility of an overflow is less likely in MSGTOSS 2.0 vice earlier versions. See SLAK:xxx bbs keyword. MSGTOSS 2.0 was beta tested to the hilt, almost 2 years! However, there still is a possibility of receiving a *.PKT file that is beyond the capa- bility of MSGTOSS to process. If you are a supporter of MSGTOSS, send the *.PKT to me for analysis and a possible fix. If you are a non-supporter, I may be interested, but don't expect me to bend over backwards to fix your problem. Future upgrades and enhancements DEPEND on the amount of support I receive. Page - 53 MSGTOSS Version 2.0 PERFORMANCE OPTIMIZATION ------------------------ Here are a few tips to make your mail events as fast as possible. 1) Use a disk cache! Even just a 64K cache makes a BIG difference! 3) Use the SECL:1 keyword. Can ONLY be used with the FMAS:1 switch. 4) Use the /NSTOP and /DDA switches, will also speed up MSGTOSS. 5) Consider NOT using the automatic DUP checker (CDUP:1 keyword). If your hub faithfully checks for dups then it may not be necessary. 6) Use a RAM DISK with the /WDIR (work directory) command line switch. The RAM disk is configured by the WORKDIR---> parameter in the MSGTOSS.CFG file. Will speed up purging, mailwaiting, sizing & tossing). 7) The Use of a disk de-fragmentor is NOT CRITICAL, as MSGTOSS does not fragment message bases! Its pack-in-place purging technique pre- vents this from happening. However, it doesn't hurt. 8) Keep your conference USERS file(s) small (mine have ONLY 32 user records!) and purge them after so many months of inactivity. If a user decides to browse the conference but doesn't enter mes- sages; MSGTOSS will slow down because it will be looking for messages to/from that inactive user. You can set up a daily MU-PURGE control file to do this. Here is an example of mine: users /USR:D365 LOG /10 /25 commu.def /USR:D30 LOG /40 /60 consultu.def /USR:D30 LOG /40 /60 c_prgmu.def /USR:D30 LOG /40 /60 Notice that they get BOOTED out of the conference if they haven't en- tered it in over 30 days. In addition, once they are purged then any messages that they left or are waiting will also be purged. All of my 'U.DEF' files are only 4096 bytes, good for only 32 users (I haven't run out of room yet). 9) Avoid the /FEED switch (unless you feed nodes) 10) Use the MSGTOSS.BBS keyword USRH:0 whenever you have large user bases. 11) You can use the /PREX (pre-expand) option, and chop the message bases at night using the /SIZE switches. 12) For multi-tasking/networking, use the smallest value of LOCKWAIT---> you can get away with without affecting your users. 13) Avoid the message "capturing" feature of MSGTOSS 2.0, will slow down the analyzing phase. 14) Avoid the HIST:x keyword. WIll slow down purging Page - 54 MSGTOSS Version 2.0 MODIFY RBBSSUB2.BAS TO SUPPORT /MUSER:X --------------------------------------- The following code provides a means of modifying the WHOSON routine of RBBS-PC allowing a user to see the last MSGTOSS execution status by entering the "[W]ho else is on" function on RBBS's main menu, even though MSGTOSS is actually off-line. During a /TOSS, MSGTOSS will mod- ify its own node record (as defined by /MUSER:x) as it passes through its various tossing phases. A user will be able to see it working by entering [W]ho, but when MSGTOSS goes off-line a user will see "Waiting for next caller". This modification will allow a user to see the other node records, including the MSGTOSS node record. For more informa- tion, see MSGSWI.DOC. Code segment provided by: Michael Walsh (NHUB/NC Philadelphia Metro (FidoNet) Modification for RBBSSUB2.BAS (WHOSON:9801) SUB WhosOn (NumNodes) STATIC WasA1$ = ZActiveMessageFile$ ZActiveMessageFile$ = ZOrigMsgFile$ CALL OpenMsg FIELD 1, 128 AS ZMsgRec$ FOR NodeIndex = 2 TO NumNodes + 1 ........ ........ code shortened ........ IF MID$(ZMsgRec$,40,2) <> "-1" THEN _ WasAX$ = WasAX$ + ZFG4$ + MID$(ZMsgRec$,93,22) IF MID$(ZMsgRec$,57,1) = "A" THEN _ ZOutTxt$ = ZOutTxt$ + " Online at " + _ WasAX$ _ ELSE IF NOT ZSysop THEN _ \ ZOutTxt$ = ZOutTxt$ + _ > Delete these! " Waiting for next caller" _ / ELSE ZOutTxt$ = ZOutTxt$ + _ " Offline at " + _ WasAX$ CALL QuickTPut1 (ZOutTxt$) CALL AskMore ("",ZTrue,ZTrue,ZAnsIndex,ZFalse) IF ZNo THEN _ NodeIndex = NumNodes + 2 NEXT ZActiveMessageFile$ = WasA1$ CALL QuickTPut (ZEmphasizeOff$,0) END SUB What it winds up looking like on a 4 node system running RBBS-PC V17.3C: Node 1 Offline at 2400 BPS: JOSEPH GARECHT NORRISTOWN, PA Node 2 Online at 9600 BPS: SYSOP PHILADELPHIA, PA Node 3 Offline at 300 BPS: MsgToss 2.0 - Mail System Last: 01-18 23:42:31 Node 4 Offline at 300 BPS: Page - 55 MSGTOSS Version 2.0 EPILOG ------ MSGTOSS took 1000's of hours to develop and test and I believe it to be one of the finest mail processors in the Fidonet community, and most cer- tainly for RBBS-PC. If you use this program then please help support it. Show your support by registering this program. Meanwhile, happy BBSing! Mike Page - 56