Both the Squish base and the JAM base can be considered successors to the Hudson Message Base. The HMB was a replacement for the Fido *.MSG base, but its limit of 200 message areas and maximum size of 16Mb makes it somewhat outdated compared to the huge message traffic produced by the various networks today. The Hudson Message Base is not supported by WaterGate.
This type of base is compatible with almost any piece of software written for Fido. So you probably want to use it for your netmail directory, to allow other programs to easily insert messages.
If you create a Fido *.MSG area, make sure you enter a valid directory name in the "Area path" field, with a terminating backslash.
Examples:
C:\WSD\NETMAIL\ C:\WSD\NETMAIL\HISTORY\
A Squish base can contain up to 2^32 (2 to the 32nd power) messages, which should be enough for anybody. (Don't quote me on this one, please.) If it isn't, you probably have more serious problems.
A Squish base can re-use space occupied by deleted messages without needing repacking, so you don't need to pack a Squish base as often as other types.
If you set a maximum number of messages for a Squish area, WaterGate will automatically delete the oldest message. So, the area never contains more than the set number of messages. Don't set this number too low, because if WaterGate has to delete large numbers of messages in each run, performance will suffer. If you want maximum performance and don't care about disk space, just set the limit to 0 messages.
If you use the Squish base for an area, the "Area Path" should contain a valid directory plus an 8 character area name. Don't use any extensions (.???) in the path and don't put a backslash at the end!
Examples:
C:\BBS\SQUISH\ALTBBS for the area ALT.BBS C:\BBS\SQUISH\ALTBMISC for the area ALT.BBS.MISC etc.
It uses a <name>.JHR file to store header information; each header consists of a fixed part and a flexible part, depending on the message. Storing only a small part in the fixed header makes it relatively easy to add future enhancements to the message base. Each header contains a pointer into the <name>.JDT file, which contains the actual message. The areabase is indexed in the <name>.JDX file and lastread information is stored into the <name>.JLR file.
JAM has a (for Fido systems) new way of linking messages: instead of simply linking messages with the same subject, each message can have an unlimited number of replies to it, so that each reply is a reply to the original message. This way you can always see to which message a new message is a reply.
Example:
1 --- 2 --- 4 --- 5 | | | +---- 8 | +---- 3 --- 7 | +---- 6Messages 2, 3, and 6 are a reply to message 1. Message 4 and 8 are a reply to message 2. Message 5 is a reply to message 4. Message 7 is a reply to message 3.
If you use the JAM base for an area, the "Area Path" should contain a valid directory plus an 8 character area name. Don't use any extensions (.xxx) in the path and don't use a terminating backslash!
Examples:
C:\BBS\JAM\ALTBBS for the area ALT.BBS C:\BBS\JAM\ALTBMISC for the area ALT.BBS.MISC etc.
This should help you understand the error message better.
Code Description 2 File not found 3 Path not found 4 Too many open files 5 File access denied 100 Disk read error 101 Disk write error 150 Disk is write-protected 158 Sector not found 200 Division by zero 202 Stack overflow error 216 General Protection fault
ARC,ZIP PkWare, Inc ARJ Robert K. Jung Binkley Bit Bucket Software Co. Fido Tom Jennings FrontDoor Joaquim Homrighausen, Absolute Solutions GEcho Gerard J. van der Land JAM (mbp) Joaquim Homrighausen, Andrew Milner, Mats Birch, Mats Wallin LHA Haruyasu Yoshizaka MS-DOS Microsoft Corporation PAK NoGate Consulting PC-DOS,OS/2 IBM Pentium Intel Squish,Maximus Scott J. Dudley TimEd Gerard van Essen Waffle DarkSide International MailTunnel Waterline Software Development
Comments or questions? Send an e-mail to editor@wsd.wline.se.
Last updated 13 October 1996