Click above to get retro games delivered to your door ever month!

                          The Message Database Formats


     GoldED  supports  many  different  message  database  formats.  The
     following  is  a  list  of   them  all,  with  notes  about   their
     characteristics and what special quirks  to look out for with  each
     of them.


         Opus/FTS1 (*.MSG)

     These are two  variants of the  same type of  msgbase. It works  by
     using one physical file per message (1.MSG, 2.MSG etc.), collecting
     them in a directory for each area. Depending on the clustersize  on
     the harddisk, this  can be a  very wasteful and  slow way to  store
     messages. With a clustersize of  about 512 bytes, the waste  may be
     acceptable, but the access speed can be dramatically slow if  there
     are  many  *.MSG  files,  due  to  the  DOS file system. Caches and
     BUFFERS adjustments can improve it, but there are limits.

     In  echomail  areas,  this  format  has  a special quirk: The first
     message  (1.MSG)   is  normally   used  to   store  the   so-called
     "highwatermark".  The  highwatermark  tells  the echomail processor
     where it should start scanning  for new messages entered by  users.
     By deleting (Zapping) the highwatermark, you can make the  echomail
     processor re-scan the whole area again. This may cause messages  to
     be  sent  out  as  "dupes",  so  this  should be used sparingly and
     carefully, if at all! The highwatermark can also be "Heated" -which
     means that it is set to the last msg in the area. This prevents the
     echomail processor from finding  newly entered unscanned msgs.  Use
     with care.

     The variants: The "Opus" format originated in the Opus BBS  system.
     It put some Fido undocumented(?) fields to use as date/time stamps.
     The "FTS1" (defined in FTS-0001, revision 12 and later) format uses
     the undocumented fields to  set the zone/point information  for the
     msg. To the  authors knowledge, the  Opus variant is  the dominant,
     and the FTS1 variant  is doomed to oblivion.  If in doubt, use  the
     Opus format.


       Hudson

     This msgbase format was invented by Adam Hudson, and was first used
     in his  QuickBBS package.  Later several  other BBS'es  were cloned
     from QuickBBS (like RemoteAccess and SuperBBS).

     The basic format is built around 7 main files:

         MSGTXT.BBS    This contains the message text of all msgs in all
                       areas.
         MSGHDR.BBS    The headers for all the msgs in MSGTXT.BBS.
         MSGIDX.BBS    Index to MSGHDR.BBS.
         MSGINFO.BBS   Tells how many msgs there are in each area.
         MSGTOIDX.BBS  Index that contains all the TO names.
         LASTREAD.BBS  Lastreads for all areas for each user in USERS.BBS.
         USERS.BBS     Contains a record for each user. Also the index to
                       LASTREAD.BBS.

     The format  limits the  total size  of MSGTXT.BBS  to a  maximum of
     16MB, which  translates to  about 16000  msgs of  "average" length.
     GoldED  automatically  warns  you  if  the  limit is close to being
     reached, and advises you to pack the msgbase.

     The first incarnations of QuickBBS did not support "sharing" of the
     msgbase. This  became more  and more  important in  later years  as
     multitaskers and  networks got  cheaper. RemoteAccess  BBS was  the
     first to implement a useful  method, and later a better  method was
     evolved (known as "RA 1.01 or RA 1.1x"), which is now the  standard
     for all modern software that supports msgbase sharing. GoldED fully
     supports the new standard of course.

     The main virtue of  this format is that  it is very fast  to access
     the msgbase.

     The main  disadvantage is  that it  can be  very sensitive  to disk
     problems, and it is a  common horror story that people  loose their
     entire  msgbase  because  the  disk  developed bad clusters or some
     program went berserk and messed up the msgbase files.


       Goldbase

     This is  an enhanced  version of  the Hudson  format, introduced in
     QuickBBS 2.80 by the QuickBBS group.

     The Goldbase format  removes the 16MB  size limit and  allows up to
     500 message areas instead of  the 200 in Hudson. The  filenames are
     the same, except that the extension is .DAT instead of .BBS.


       Squish

     The Squish format is relatively new. It was invented by Maximus BBS
     author Scott  Dudley in  1991, and  was first  used in Maximus CBCS
     v2.00. Soon after,  GoldED was among  the first message  editors to
     support this new format.

     Squish uses three  files per area:  A header/message text  file (*.
     SQD),  an  index  file  (*.SQI)  and  a  lastread file (*.SQL). The
     SquishMail echomail processor uses a fourth file (*.SQB) to hold  a
     dup-database.

     The use of a database for each area - instead of one file per  msg,
     or all msgs in one big database - makes this format fast, very safe
     and  resistant  to  disk  problems.  Even  if something messed up a
     Squish area, it can almost always be fixed and recovered, using the
     SQFIX  or  SQREIDX  utilities  that  come  with the Squish echomail
     processor.

     A  special  feature   of  Squish  areas   is  that  they   can   be
     self-maintaining. You can setup a  Squish area so that it  may only
     contain  a  maximum  of  so-and-so  many  msgs,  and  then  it will
     automatically re-use the space used  by old msgs when the  limit is
     reached, and  so it  will practically  stop growing.  It will still
     need packing, but not nearly as often as a Hudson msgbase has to.


       Ezycom

         <to be described>


       JAM

     The JAM format was invented by Joaquim Homrighausen, Andrew Milner,
     Mats Birch and Mats Wallin.

     JAM uses four files for each area: A header file (*.JHR), a message
     text file (*.JDT),  an index file  (*.JDX) and a  lastread file (*.
     JLR). Most echomail processors support two additional files to  aid
     scanning  out  messages:  NETMAIL.JAM  and  ECHOMAIL.JAM.  They are
     "global" files, located in the JAMPATH.

     See also the chapter "JAM Implementation Notes".


       PCBoard

         <to be described>

     See also the chapter "PCBoard Implementation Notes".