General overview

This is where the flexibility of ProBoard can be somewhat confusing. Don't fret, just follow those guidelines and you will be all set. A 'message base' in the sections that follows is assumed to be the collection of all 'message areas', which are simply where all related messages from an echo or conference will go. For example, all mail from the PROBOARD FidoNet echo will go to its own area, regardless of the message base type.

Important note: ProBoard will let you mix different base formats! Use it to your advantage.

*.MSG (Fido/Opus)

The original FidoNet format. Very easy to use, very wasteful, inefficient and limited. Each message area requires it own sub-directory and each message is kept in a separate file. While easy to program, this is a nightmare to use. Because of the HDD cluster size, you end up with a lot of wasted space, and the numbering scheme makes it really awful to do anything in a reasonable amount of time. This format is really only useful for netmail areas.

Pros - Virtually non-existent. Only used by mailers and because of standards.

Cons - You name it, it's there. Slow, inefficient, and all.

Sug - Your netmail areas only.

Setup notes - In ProCFG, you need to define the directory where the messages will go. Set the flags to 'Private Only'. This format does not really have anything resembling maintenance. Some programs will let you purge messages and renumber them. I usually do it by hand when need arises.

Tip - Don't use it (apart from netmail, that is).

Programming - C/C++ interface is included with the Squish SDK. For Pascal programmers, use Mark May's excellent kit.

Hudson

Developed by Adam Hudson when he was still a teenager, this was one the first successful attempt to cope with the disadvantages of the *.MSG system. It offers speed that is still unmatched by the other advanced formats. All message areas will be stored in only 6 files: MSGTXT.BBS, MSGTOIDX.BBS, MSGINFO.BBS, MSGIDX.BBS, MSGHDR.BBS and LASTREAD.BBS thus offering incredible processing speeds. However, this comes at a cost: you are limited to only 200 message areas for the whole BBS (of this type), the area numbers cannot exceed 200, the maximum storage capacity is around 16Mb and it is vulnerable to corruption as if one record in the main file goes bad, you may kiss the whole base goodbye. A lot of programs support this format, though.

Pros - Compact, efficient, fast, and widely supported.

Cons - Limits to number of areas and total size the whole base, very vulnerable to corruption.

Sug - Local areas that don't have much traffic.

Setup notes - When you specify an area as type Hudson in ProCFG, you don't have to worry about the location, just the area number, which cannot exceed 200. ProBoard will automatically use the path you specified in the 'Msgbase Path' under Options~Paths. I wish that was not the case because we could have had multiple Hudson areas, but, alas, it is. This format also requires maintenance with PBUTIL to renumber, reindex and purge messages.

Programming - There are no readily available routines for Hudson for C/C++ apart from shareware libraries. Mark May's (Mythical Kingdom) free MSGBASE source is very good for Pascal users.

Squish

Squish was developed by Scott Dudley while he was a teenager too. It was designed primarily to be a native format for his BBS software Maximus. While Maximus itself wasn't that impressive, the message format was and it gained popularity. The mail tosser and scanner (Squish) is free too. This format uses advanced access methods and is self-maintaining too. Each message area is stored in its own three files, which makes it very difficult to lose data (even with a corrupted area, Squish is often able to reconstruct most of the messages).

Pros - Flexible, fast, free, stable. Somewhat supported.

Cons - Can become a little clumsy with a lot of messages.

Sug - Echomail areas with average traffic

Setup notes - In ProCFG, you need to define the path and the root file name (i.e. a name without an extension) for each area. Squish will create its files there. You don't have to do any special maintenance because it is done on the fly. You may want to use QQLink which is a faster reply linker after tossing and you may want to use SQPack weekly to get rid of some holes in the message area that may have developed during the maintenance.

Tip - Use the '-f' option to specify the path to the ECHOTOSS.LOG file that ProBoard creates when scanning. This will improve the speed considerably as only the areas with new mail in them will be processed. Same goes for QQLink after tossing.

Programming - A complete C/C++ SDK is available from the author (which also has *.MSG support). It is also free and comes with source code. Has support for MS-DOS and OS/2. For Pascal programmers, Mark May's kit has Squish support too.

JAM

This format was developed by the authors of FrontDoor and RemoteAceess (and other two guys). It is probably one of the best around as far as speed and extendibility go. Each area is kept in its own separate files (like Squish) and thus possibility of corruption is minimal and always localized. There are a lot of programs out there that work with this format. It's fast (faster than Squish, IMHO) too.

Pros - Very fast, popular, limited by disk size, stable.

Cons - ProBoard seems to have a problem with the last read pointers (I have not been able to verify it) and does not create the ECHOMAIL.JAM that is the JAM equivalent for ECHOTOSS.LOG (there is a program that will convert the latter, though).

Sug - Echomail areas with heavy traffic.

Setup notes - In ProCFG, you need to define the root filename only (like with Squish). You will need to run daily maintenance for JAM for renumbering, re-indexing and purging. PBUTIL does it all.

Tip - If your tosser does not create missing (new) areas, like InterEcho, for example, load ProBoard and simply select 'Change to area' for that area. This will create the base files. Also, use the JAMMIT PEX or PBJAM program to convert the ECHOTOSS.LOG file for use with your scanner.

Programming - JAM C/C++ SDK is available free from the authors, for Pascal, use the ever-present Mark May's kit.

In ProCFG, define the message area as 'To-All'. Then, when you write the message, address it to 'All'. That's it.

Make the default reply area something else so users don't clutter this one as they try to reply to the announcements. Also, make sure you set the Sysop level high enough so they don't delete the messages.

The simplist way is to edit the menu option that goes to your Message Menu and put the following on the data line :

/MG=<msg group number> /M=<msg area number>

For example :

HotKey : M
Function : 60 - Run ProBoard PEX File
Data : MESS /MG=1 /M=3

This will put the User into message group 1 and message area 3 when they enter the Message Menu. You can expand on this idea to create a Conference type menu system or to control new users.

ProBoard sets all Areas to be scanned for New Mail when a New User is created. This means scanning the whole message base for a User's New Personal Mail even though that User cannot have mail waiting for them.

SetArea by Sarah & Faye Pearson at Fe-line Software allows the User or SysOp to select which message boards they would like to scan for their Personal Mail Scan and/or the QWK download boards quickly, turn OFF and ON all areas and also define forced areas.

Freeware