ħħħħħħħ MSGBASE.EXE v1.00 by Mark Zec ħħħħħħħ ħħħħħħħ Overview ħħħħħħħ Although PCBoard is, for the most part, Y2K compliant, numerous other BBS apps, such as mail readers and mail doors, aren't. MSGBASE attempts to correct these problems, not by trying to fix the problem (the defective app) but by fixing the result (the PCBoard message bases). MSGBASE scans the PCBoard message base files, checking the date data found for each message for corruption, dates out of range, etc. When a "bad" date is found, it's changed to the current system date. This is important for one rather large reason: If a message is imported into the message base with a date that's 10 years in the future (which is how the original Cam-Mail door imports messages after 2000...a message dated 02/01/00 will be instead dated 02/01/10), that message will be in the message base for 10 years, depending on what options are used with PCBPack. For example, if you tell PCBPack to pack out messages that are more than 60 days old, a message with the date mentioned above won't be packed out until 04/01/2010, 60 days after the message date. The problem isn't just with mail doors either. During my development/testing of this program, I found that corrupt dates, such as 01/15/0, were being imported into the BBS through Fido message packets. With so many abandoned BBS programs, it would be too difficult to try to catch every possible entry point for corrupt dates, so the easiest thing is to correct the message base itself. ħħħħħħħ Syntax ħħħħħħħ MSGBASE [-a/-l] - Can be any valid DOS path and 8.3 file name, such as C:\UTIL\MSGBASE.CFG or P:\APPS\MESSAGES.CFN [-a/-l] - At least one of these parameters is required, but both may not be used on the command line at the same time. -a Tells MSGBASE to process every message in the PCBoard message base. This method is ideal for a daily event to make sure that every message has a correct date. -l Tells MSGBASE to process every new message that gets imported into PCBoard via online entry, internal QWK, and mail door. The caller log(s) are scanned for new message entries, and only those messages are checked for bad dates. This method is ideal if you wish to run MSGBASE every time a caller logs off. An entry is placed into the caller log to let you know that MSGBASE has run, and also serves the function of acting as a "marker" so that the entire caller log isn't scanned for new messages after each caller. ħħħħħħħ Configuration File Format ħħħħħħħ The configuration file (see the sample MSGBASE.CFG file included) must be 5 lines. Anything after the fifth line is discarded, but do NOT delete any of the first five. If you choose not to use any of the optional values, simply blank out the line...don't delete it. Line 1: Full path and file name to your CNAMES.@@@ file. This line is required. Without it, MSGBASE will be unable to determine the locations of your message base files. Line 2: Full path and file name(s) to your callers logs. This line is optional if using the -a parameter, but required if using the -l parameter. Multiple files can be placed on this line, as long as each path/file name is separated by a space. A typical line with multiple caller logs would look like: C:\PCB\MAIN\CALLER1 C:\PCB\MAIN\CALLER2 C:\PCB\MAIN\CALLER3 If the -a is being used, this line is disregarded. When processing only new messages that have been entered, a line will be written to the callers log that looks like: ŝ MSGBase Event Completed ŝ This serves two purposes. First, it will give an indication to you that the event has run. Second, it will be used as a "bookmark", so that MSGBASE doesn't process the entire log every time. MSGBASE will process the callers log, starting at the last line and moving up to the first line, until either this log entry is encountered, or until the beginning of file is reached. Line 3: A number between 1 and 1825 used as date "spread" for determining bad message dates. For example, if 1825 is used, a message date will have to be within roughly 5 years of the current date to be considered valid. If the date falls outside that range, based on the option on Line 6 (both future and past dates, or just future), the message date will be replaced with the current system date. Line 4: Full path/file name to activity log file. This line is optional, but provides a record of every bad message date that was found and corrected. MSGBASE makes no attempt to monitor the size of the log file, however, so it will continue to increase in size unless periodically deleted. It's recommended that the log file is active when first using MSGBASE to monitor its operation. As soon as you're satisfied with the operation, this line can be blanked out (but not deleted). Line 5: Y or N. If set to Y, MSGBASE will create a batch file in the current directory (not the directory where the MSGBASE.EXE is located) called REINDEX.BAT, which invokes the PCBPACK command with the correct parameters for conferences and indexing. It's advised that, especially when using MSGBASE to process the entire message base during an event, that the message base also be reindexed immediately after. If set to N, the batch file will not be created. The PCBPACK command issued in the REINDEX.BAT depends on the type of message checking is being done by MSGBASE. If the program is invoked with the -a option, processing the entire message base, the REINDEX.BAT file will consist of a single line: PCBPACK /AREA:ALL /INDEX If the program is being invoked with the -l option, processing only newly entered messages, the REINDEX.BAT will only contain the conferences that have had messages corrected. For example, if upon scanning the callers log, MSGBASE corrects dates in the Main Board (conference 0) and two others, #50 and #100, the REINDEX.BAT file will look like: PCBPACK /AREA:0;50;100 /INDEX Line 6: Y or N. If Y, MSGBASE will only check future dates for being out of range, based on the spread value entered on line 3 of the configuration file. If N, MSGBASE will check both future and past dates for being out of range. This option is in place for those sysops that keep a large archive of old messages. Without it, MSGBASE would constantly redate old messages. Because MSGBASE uses an external configuration file, it's possible to use multiple configuration files, for example one per node. Although this wouldn't be necessary if MSGBASE is being run once per day as part of an event with the "-a" option, it would be ideal when using the "-l" switch when each caller logs off a node. That way, MSGBASE would only process the messages left by the current caller on a node instead of processing all nodes, whether the caller is still on or not. For example, if you're running a system with two dialup nodes and want them processed identically, the two .CFG files could look something like this: MSGBASE1.CFG C:\PCB\MAIN\CNAMES.@@@ C:\PCB\MAIN\CALLER1 180 C:\PCB\MSGBASE\MSGBASE.LOG Y Y MSGBASE2.CFG C:\PCB\MAIN\CNAMES.@@@ C:\PCB\MAIN\CALLER2 180 C:\PCB\MSGBASE\MSGBASE.LOG Y Y Node 1's BOARD.BAT file would have this command near the end: MSGBASE C:\PCB\MSGBASE\MSGBASE1.CFG -L Node 2's BOARD.BAT file would have this command near the end: MSGBASE C:\PCB\MSGBASE\MSGBASE2.CFG -L This example assumes that your configuration files are stored in the C:\PCB\MSGBASE directory. The MSGBASE.EXE can also be in this directory, as long as it's in your path, or it can be placed in a directory that's already in your path. ħħħħħħħ Installation ħħħħħħħ Because MSGBASE can be run in two different modes, one that scans the caller logs and another mode that processes all messages in all areas, installation can also fall into two categories: Using MSGBASE with the "-l" option: The command invoking MSGBASE would best be placed in each node's BOARD.BAT file (or NODE.BAT, depending on your setup). Every time a caller logs off, MSGBASE will be invoked. The caller log will be scanned for any messages that the previous caller entered, either online, via the internal QWK, or by a mail door. Using MSGBASE with the "-a" option: The command invoking MSGBASE would best be placed in either a nightly event file (typically a midnight event). If you pack the message bases nightly, my suggestion would be to run MSGBASE prior to the packing. Alternatively, if you're transferring mail at various times during the day and want to make sure that any ougoing messages have the date formatted correctly before export, MSGBASE can be the first thing run as part of a mail event. ħħħħħħħ Activity Log ħħħħħħħ If you choose to have MSGBASE maintain an activity log (recommended at least when first using the program), the following information is logged: 1. The date and time MSGBASE began its maintenance. 2. If any date-related errors were detected in the message bases, the message number, conference name and number, bad date, and corrected date are entered into the log. An example would look like this: Correcting message # 8075 in Main Board # 0 Old Date: 01-17-10 New Date: 02-03-00 3. The date and time MSGBASE ended its maintenance. The activity log is NOT monitored for size by MSGBASE...if not deleted, it will continue to grow in size until it encompasses the known universe (well, maybe not quite THAT big, but close ). Although I recommend maintaining the log in the beginning to monitor any corrections that are being performed, the activity log can be disabled as soon as you're satisfied that MSGBASE is correcting the message bases properly. I've included a log file with the distribution archive to show what a full log looks like. Feel free to delete it at your leisure. All of the errors it found on our BBS were from incoming Fido packets. ħħħħħħħ Speed ħħħħħħħ Yes, it's an issue I'm always concerned about. :) Processing speed will obviously vary from machine to machine, OS to OS, and setup to setup. Our BBS is running a 486DX4-100 with 32 MB of RAM, and a *really* slow 8 year old 340 MB hard drive. With this setup, MSGBASE processed our entire message base of approximately 3500 messages in about two minutes. However, when I copied the entire message base from the BBS machine to my development/personal machine (Pentium 233, Win95B, 32 MB of RAM, and a new 6.8 GB hard drive), the processing time for the same message base dropped to four seconds. For those who want a utility that works quickly, you can base the performance on your own system by the two benchmarks above. The sample MSGBASE.LOG includes the two processing runs I did for benchmarking purposes. The first was done by the BBS machine, the second by mine. ħħħħħħħ Registration and Contact Information ħħħħħħħ MSGBASE is yet another PCBoard utility that's being released as freeware. I figured I needed to write it for us since we only have the original Cam-Mail door (and Cam only fixed the Cam Gold, the cheap bastard), so why not make it available to everyone who was equally screwed? Of course, if you find this program to be the best thing since sliced bread, and your future would be doomed without it, I can certainly be coerced into accepting donations. :) Contact information is: Mark Zec mark.zec@haremail.com Mark Zec@1:387/422 Hare Mail BBS 210-949-0338 I'm also co-moderator of the Fidonet PCBoard echo, and can be reached there. ħħħħħħħ Disclaimer, Additional Features ħħħħħħħ Of course, because this is freeware, you get what you paid for. It works here, but I can't guarantee that it'll do anything more than take up some disk space. If you have any questions, comments, or requests for additional features, feel free to contact me. Of course, additional features will be considered, but I can't guarantee that they'll be implemented. This is all being done in my spare time, and without pay, so keep that in mind. Any bug reports will be appreciated. Please provide as much information as possible about the nature of the bug. I've done a fair amount of testing with MSGBASE on the BBS and haven't encountered any problems, but that doesn't mean they don't exist. Of course, bug reports/fixes will be handled before requests for additional features. ħħħħħħħ Special Thanks ħħħħħħħ A number of sysops were kind enough to supply snippets of their callers logs. I needed these so that MSGBASE would be able to recognize and detect as many mail doors as possible when processing the callers logs for new messages (the "-l" option). Because we only have the original Cam Mail door, I would have been unable to code MSGBASE to recognize all of these doors without their help. My thanks goes out to these sysops (in no particular order): Bob Watson - Tao BBS Barry Martin - The Safe BBS Dave Oldridge - Coastal Watch BBS Herbert Bushong - Blackbeard's BBS