FrontDoor – Frequently Asked Questions (FDFAQ)

File: FDFAQ103.TXT
Date: 15-May-2001
Desc: FrontDoor - Frequently Asked Questions (FDFAQ)
From: Definite Solutions

Note: Each item has a header (***) followed by the revision (of the FAQ) to
      which the item was added and/or updated. E.g. "*** 103".

      For notes that are relevant to a specific version or operating system,
      the version number and/or operating systems is listed to the right of
      the revision number; e.g. 103 (OS/2).

      Each note also has a unique number attached to it. This is to aid in
      finding a specific reference given to the "FDFAQ" document. The
      unique numbers are indicated following a '$' character; e.g. $0042.
      The highest used reference number is currently $0051.

      Some notes that require a somewhat detailed explanation have been
      placed at the end of the document, below the more common issues. These
      notes are for all intents and purposes considered to be a part of this
      document and have thus received a unique number as outlined above.

      ---------------------------------------------------------------
      Copyright 1998-2001 Definite Solutions HB; All rights reserved.
      ---------------------------------------------------------------

============================================================================
GENERAL
============================================================================

*** 100 (DOS) $0001

Q: The system locks up as soon as I start any of the FrontDoor programs.

A: This is often an indication that FrontDoor is configured to use extended
   keyboard calls on machines without support for the extended keyboard
   calls. Try running the program with the /NOEKBD command-line parameter.

   If this cures the problem, the "Global.General.Extended keyboard" setting
   should be configured as NO.

*** 100 (DOS) $0002

Q: I am experiencing horribly slow screen updates in all or some of the
   FrontDoor programs.

A: One possible cause, specially under Windows NT, can be incorrect usage of
   the GLOBAL.GENERAL.SCREEN FLICKERS setting. It should only be configured
   as YES if the screen is flickering when the FrontDoor programs are
   writing to the screen; screen flicker typically only occurs on systems
   equipped with older CGA cards.

*** 100 $0003

Q: When FM, FD, and FDNC is started and terminated, there is a delay even
   though the programs do not appear to be doing anything. 

A: One possible cause is that the programs are detecting the presence of a
   mouse driver. When a mouse driver is detected, the programs will execute
   the mouse initialization code on startup and the mouse deinitialization
   code on termination; this will cause some delays. If mouse support is
   not a requirement in the programs, it can be disabled. To disable the
   mouse support of a specific program, it should be loaded with the
   /NOMOUSE command-line parameter. To disable the mouse support for all
   FrontDoor programs, add "NOMOUSE" to the FDOPT environment variable
   setting.

*** 100 (DOS) $0004

Q: X00 (FOSSIL driver) cannot be unloaded. It is being used as a TSR and
   when asked to unload, it complains about "Not safe to uninstall".

A: This is usually a conflict between X00 and a mouse driver when X00 is
   used as a TSR. To fix this, either load X00 as a device driver, or
   disable mouse support in FD (by using the NOMOUSE command-line parameter
   or FDOPT setting).

*** 101 $0005

Q: When FM or FD is running, there seems to be minor but periodic disk
   activity taking place; what can I do to prevent this?

A: The disk activity is due to the various programs checking for certain
   files in the SYSTEM and SEMAPHORE directory. For the [ML] version, you
   can decrease the amount of disk activity by placing the SEMAPHORE
   directory on a RAM disk.

   A small disk cache (HYPERDISK, SMARTDRV - for DOS - etc) will further
   improve this; the size of the cache need not be greater than 512 Kb.

   FD also writes to its activity monitor database on a frequent basis. If
   you do not want this interface to be available (for example, if you are
   not using an activity monitor such as FDAMON), the interface can be
   disabled by specifying /NOACTMON on the FD command-line or add NOACTMON
   to your FDOPT setting.

*** 102 $0006

Q: I am concerned about Y2K (Year-2000) compliance, what gives?

A: FrontDoor versions 2.25 and above are Y2K-compliant.

*** 102 $0007

Q: Is there an OS/2 version of FrontDoor?

A: Yes; as of version 2.32.mL and 2.26.SW, there is a native 32-bit version
   of FrontDoor (FD, FM, FDNC, and FDSETUP) available for the OS/2
   operating system. See also notes 0042, 0043, and 0044.

*** 102 $0008

Q: Is the source code for FrontDoor available?

A: Not in the general sense, contact Definite Solutions if you have
   specific questions about this.

*** 102 $0009

Q: Is this the last release of FrontDoor?

A: No.

*** 102 $0010

Q: Has development of FrontDoor stopped?

A: No.

*** 102 $0042

Q: I have purchased or registered the DOS version, but the OS/2 version does
   not seem to accept my licensing information as entered into FDSETUP.

A: To run the OS/2 version, you need different licensing information.
   Contact your nearest registration site or Definite Solutions retailer;
   alternatively, you can contact Definite Solutions directly.

*** 102 $0043

Q: Can I run both the DOS version and the OS/2 version with the same basic
   configuration?

A: Yes, you can share SETUP.FD between different platform-specific versions
   of FrontDoor. Some notes regarding this:

   (1) You need licensing information that indicates multi-platform support.
       (See also note 0042)

   (2) Some platform-specific features can only be modified by the native
       configuration program; e.g. some DOS-only features can only be
       modified using the DOS version of FDSETUP.

*** 102 $0044

Q: I want to upgrade my current DOS version to the OS/2 version, what does
   it involve?

A: Very little of your configuration needs to be changed. The two biggest
   differences as far as your configuration is concerned are:

   (1) The OS/2 version does not exit with errorlevels, instead it executes
       certain batch files (.CMD) to launch external programs such as BBS
       software, fax receiver, etc. This is outlined in the documentation.

   (2) No FOSSIL driver is used/required by the OS/2 version.

   See also notes 0042 and 0043.

*** 102 $0049

Q: FD and FDNC both claim that I am running Windows 98, but I know for a
   fact that I am running Windows 95, what gives?

A: There are a number of versions of Windows 95 and they all exhibit
   different behavior as far as OS-version detection goes. The various
   FrontDoor programs may get the version mixed up and display "Windows 98"
   although they are not running under W98. Either way, if the programs
   display "Windows 95" or "Windows 98", the correct time-slicing code will
   be invoked.

============================================================================
FD (mailer)
============================================================================

*** 100 $0011

Q: The MODEM.HARDWARE.LOCKED.PORT setting is configured as YES, and the
   FOSSIL driver is locked at 115200 BPS; and the modem always reports that
   calls are connected at 115200 BPS.

A: Check to ensure that the modem is configured to return the DCE (modem-
   to-modem) speed as opposed to the DTE (modem-to-computer) speed.

*** 100 $0012

Q: I am using a modem that requires the DTE (computer-to-modem) speed to be
   locked at 57600 or 115200 BPS to achieve maximum throughput and transfer
   efficiency, but FDSETUP only allows the baudrate to be set to 38400 BPS.

A: Set the baudrate in FDSETUP to 38400 BPS and configure the
   "Modem.Hardware.Locked port" setting as YES. Then configure the FOSSIL
   driver to lock the port at the required speed.

*** 100 $0013

Q: FD sometimes displays the message "xxxxxxxx.PKT contains conference mail,
   ignored" and refuses to unpack the messages in the mail packet file.

A: When FD scans received mail packets (.PKT files), it looks for the string
   "AREA:" in the body of the messages contained in the mail packet. This
   string indicates that the message is a conference mail message. FD only
   handles NetMail-type messages internally; an external Conference Mail
   application must be used to unpack mail packets containing Conference
   Mail.

*** 100 $0014

Q: The phone rings, but FD does not display "RING" in the modem messages
   section of its main screen; if the Terminal is loaded, the "RING" message
   is displayed when the phone rings.

A: Some modems with NVRAM (non-volatile storage space for settings, etc)
   seem to have a peculiar behavior when they are used at a speed different
   than the speed the NVRAM was last configured with. Go to the Terminal and
   issue the command used to update the NVRAM (this is usually AT&W).

*** 101 $0015

Q: When FD answers the phone to process an incoming call and when it places
   an outbound call to deliver mail, the text "ERROR" is sometimes displayed
   in the log file and/or screen.

A: This is a message returned by your modem. FD does not issue this message.
   It is typically an indication of an incorrectly specified modem
   configuration option in FDSETUP or your modem's NVRAM configuration.

*** 100 $0016

Q: When using the RCVFAX program with FD and the ZyXEL modem attached to the
   system, it does not seem possible to receive fax transmissions. As soon
   as FD hands over control to RCVFAX, the program reports an error and the
   call is terminated.

A: Add a one or two second delay in the batchfile before RCVFAX is invoked.
   [ML] The RCVFAX program can be replaced by using the internal fax
   reception capabilities if a ZyXEL modem is attached to the system.

*** 100 $0017

Q: The system successfully negotiates several EMSI sessions each day, but
   it seems that EMSI/MD5 session negotiation is never used.

A: There are three possible causes for this:

   1. FD requires that it is running on a system equipped with a
      386-compatible (or better) CPU. If it is not, it will automatically
      disable EMSI/MD5 session negotiation.

   2. If the remote system does not support EMSI/MD5 sessions, the programs
      will attempt to negotiate a standard EMSI session.

   3. If the command-line parameter or FDOPT setting NOEMSIMD5 is used, FD
      will disable EMSI/MD5 session negotiation.

*** 100 $0018

Q: A NetMail tracker/manager program keeps complaining about a mismatch in
   the INTL/MSGID information for messages that FD has created when
   unpacking messages with file attachments?

A: When FD unpacks messages with file attachments, it inserts the path to
   which the attachments were received into the messages' subject (Re:)
   field. The problem is that the subject field can only hold 71 characters
   of data. FD solves this by creating empty attachment messages for those
   attachments that cannot fit into the subject field of the first message.
   When it creates these messages, it copies the addressing information
   from the original message, including the INTL information. The MSGID
   information is, however, not copied; instead, new MSGID information is
   created by FD. The NetMail tracker/manager program should be configured
   not to check for this.

*** 100 $0019

Q: After entering a file request from the console, FD does not seem to
   process it nor does it start dialing the system to which the request
   was entered.

A: FD will deliberately wait a short period of time after a file request
   has been entered from the console to allow for further console
   activities (such as additional file requests).

*** 100 $0020

Q: When the local system connects to a remote system to request a file,
   the message "Remote refused file requests" is displayed and/or logged,
   and after successfully completing the session, the remote system is
   called again, and again.. ?

A: The reason for the repeated calls is that FD cannot deliver the file
   request(s) to the remote system since it has indicated that it does
   not want them. Remove the file request(s), or delay the call manually
   until the remote system supports file requests.

   Note that this should only occur with file request entries in the STQ.
   Messages with file request status are simply flagged as "Sent" by FD
   when the remote system does not indicate support for file requests
   when the session is negotiated.

*** 101 $0021

Q: When FD starts, it displays its main window and says that it is
   processing the NetMail folder and then it appears to lock up.

A: The reason for the lock-up is probably an event configured with no
   active days. This causes FD 2.30.mL to enter an endless loop when it
   is attempting to retrieve the currently active event. The solution is
   to upgrade to a newer version of FD or to configure the event as
   inactive; you can also configure the event with at least one active
   "Days" setting.

*** 101 $0022

Q: I am using FastEcho 1.46 or later together with FrontDoor and want to
   use the new STQ (Static Queue) feature of FD, does FastEcho support it?   

A: Yes. You should specify the FrontDoor SYSTEM path in the FESETUP field
   SYSTEM.PATHNAMES.STATIC QUEUE. When doing this, you must ensure that
   all "ARCmail" .MSG attaches have been sent, otherwise FastEcho will
   truncate active ARCmail files. It is not possible to mix .MSG-style
   ARCmail attaches and use of the STQ by FastEcho.

   It is possible to automatically convert remaining .MSG-style ARCmail
   attaches to the STQ by using the MSG2QUEUE program (available from the
   Definite Solutions website). When using MSG2QUEUE, you *must* use the
   /IsArcMail switch.

*** 101 $0023

Q: My telephone network operator offers something called "Distinctive Ring"
   whereby different audible ring signals are generated based on which
   number the caller used when calling me. How do I configure FD to only
   answer on a specific number/ring signal?

A: For the "Distinctive Ring" feature to be used with FD, your modem must be
   able to distinguish between the different types of ring signals and issue
   different RING messages; e.g. RING1, RING2, RING3, ..

   Once you have configured your modem to issue the appropriate RING message
   for your modem/BBS number, you must change the MODEM.STATUS MESSAGES.RING
   setting to the appropriate message; e.g. RING1

*** 101 $0024

Q: I want to prevent FD from making ANY outbound calls, even if there is
   mail that is qualified by means of special status settings (such as
   IMMediate, etc), but I cannot find any setting to achieve this. I have
   configured the event to INBOUND ONLY, but FD insists on making outbound
   calls as soon as there are IMMediate messages or STQ entries.

A: Simply create the semaphore FDNOCALL. in the SEMAPHORE directory.
   When FD detects this semaphore, it will not make ANY outbound calls.

*** 102 $0025

Q: FD does not appear to be detecting that new mail has been added to the
   System NetMail Folder and/or the static queue (STQ). If I force a rescan,
   FD does detect the new mail and starts placing outbound calls, etc. Why
   doesn't it detect the new mail automatically?

A: FD needs to be notified of updates to the System NetMail Folder and/or
   the static queue (STQ) by means of the FDRESCAN.NOW semaphore in the
   semaphore directory (system directory for the Shareware version). If
   this semaphore is not updated, FD will not detect the changes until it
   resets at the start of a new event, etc. Make sure that the application
   you are using is "FrontDoor semaphore aware" and that it knows where it
   should create/update the FDRESCAN.NOW semaphore.

*** 102 $0026

Q: FD seems to be very slow in detecting that the FDRESCAN.NOW semaphore has
   been updated. Sometimes two lines call the same system in succession.

A: This is typically an indication that the GLOBAL.GENERAL.SEMAPHORE TIMER
   setting is too high. This setting specifies how frequently FD should
   check for an update to various semaphores and some other important
   system files.

   It should be noted that on a multi-line system and/or systems where
   programs are used to process mail in the background, the importance of
   this setting increases. Unless there is a very good reason for it, a
   multi-line system should use a setting of somewhere between 5 and 10
   (seconds). This does, of course, increase the system load somewhat, but
   on a system properly configured as far as disk caching is concerned, the
   added overhead is usually not noticeable.

============================================================================
FM (editor)
============================================================================

*** 102 $0037

Q: Why does the "Change AKA" () feature no longer work? I want to
   change the originating network address before I write my message.

A: This function is still available, but it is only available in edit mode.
   Start writing your message as usual and then press  when the cursor
   is in the text/message body section of the screen; when you have selected
   the desired address, FM will update the originating address of the
   message. It should be noted that this technique does not work for CC
   (carbon copy) messages; only the first (original) message will be
   affected. If all else fails, you can edit an unsent message by pressing
    and then using the  function.

*** 102 $0038

Q: I want FM to use a different/random origin line each time I write a
   message in conference-type folders, but I cannot find a reference to
   random origin lines. How do I accomplish this?

A: Refer to the section describing the "Editor menu" options of FDSETUP in
   the Administrator Guide (FDADMIN). The section contains a description on
   how to add random origin line capabilities to FM for a specific folder/
   origin line slot.

============================================================================
Nodelist
============================================================================

*** 100 $0027

Q: What are the various nodelist group tags, and what do they represent?

A: There are four pre-defined group tags: 1, 2, 3, and 4. In order of
   appearance, they represent the source for the nodelist entry:

     1 - Raw nodelist      (typically, NODELIST.nnn)
     2 - Private nodelist  (FDNET.PVT)
     3 - Private pointlist (FDPOINT.PVT)
     4 - An entry copied by means of the PHONE statement in FDNODE.CTL.

   Group tags A through Z are user-defined groups.

*** 100 $0028

Q: [ML] When using the "Edit nodelist" function of FDNC, some automatically
   processed/compiled entries seem to belong to two groups, one of them is
   group four (4).

A: When using the PHONE command in FDNODE.CTL, FDNC copies the specified
   entry from its source to the internal nodelist database. Such entries
   are given an additional group tag (4). These can be separately exported
   by specifying four (4) in the groups to include option.

*** 101 $0029

Q: I've heard that the Nodelist Indices produced with the new version of FD
   are different to those of previous versions. Can I still use my existing
   software to process the nodelist?

A: There are essentially two types of program for processing nodelists. One
   type is used to merge NODEDIFF (Difference file) with existing Nodelist
   file to produce the new updated Nodelist. These programs are unaffected
   as they have nothing to do with the creation of the Nodelist indices.

   (For example, Nodelist Updater, XlaxDiff, EDITNL etc.)

   The other class consists of programs which actually create the nodelist
   index files (the .FDX files). Such programs may produce indices which
   FD 2.25 and above cannot use, and FDNC should be used instead.

   (For example, XlaxNode)

*** 101 $0030

Q: After removing all PVTLIST and POINTLIST statements from FDNODE.CTL and
   re-compiling the nodelist, some entries that were previously included
   with these statements are still present in the nodelist database, why?

A: When FDNC is processing PVTLIST and POINTLIST statements, it consolidates
   (combines) the contents of the various files into FDNET.PVT and
   FDPOINT.PVT respectively. When you remove the PVTLIST and POINTLIST
   statements from FDNODE.CTL, it is possible that these two files remain in
   the NODELIST directory; the solution is to remove these two files and re-
   compile the nodelist.

   These two files can also be used to incorporate additional entries into
   the nodelist database without using the PVTLIST and POINTLIST statements.

*** 102 $0045

Q: When FD places an outbound call, it attempts to dial the telephone number
   exactly as it is entered in the nodelist, without translation, why?

A: This is most likely due to an empty or corrupt telephone number
   translation database. Check the Administrator Guide for how to create a
   translation table (in FDNODE.CTL).

   If you already have a proper translation table configured in FDNODE.CTL,
   it is possible that FDNC has not compiled it properly. Run FDNC with the
   /P parameter (and no other parameters); this will force FDNC to re-create
    the translation database.

*** 102 $0046

Q: Is it possible to dynamically change the telephone number of a given
   system without having to recompile the nodelist?

A: Yes, this can be accomplished by using $[]-style macros.

   (1) Override the telephone number of the remote system by using the
       PHONE keyword in FDNODE.CTL: PHONE z:n/n.p $[SYSTEMNUM]

   (2) Run FDNC /P

   (3) Set the environment variable SYSTEMNUM to the desired telephone
       number (raw format).

   For example:

       [FDNODE.CTL]  PHONE 2:201/330 $[DEFSOLTWO]
       FDNC /P
       SET DEFSOLTWO=46-8-999888777

============================================================================
Terminal
============================================================================

*** 100 $0031

Q: The Terminal seems to be ignoring all input, not even  works.

A: This is typically an indication that the "raw" keyboard mode has been
   enabled in the Terminal. Make sure that the  LED is not
   active and then try again. If the keyboard does not have a
   LED, try pressing the  button once and then . See also
   note 0032.

*** 102 $0032

Q: Sometimes when using a service in the Terminal, I find I cannot access
   the menu system using  or any other key shortcut.

A: The Terminal may have entered "raw" mode, possibly because the terminal
   is configured to automatically do so and the remote has requested this.
   See also note 0031.

*** 100 $0033

Q: The Terminal seems to be displaying all characters twice, specifically
   those typed from the keyboard; e.g. "AATTII55" instead of "ATI5".

A: This is typically the result of the communications device "echoing"
   characters typed from the keyboard and the LOCAL ECHO Terminal setting
   (in the LINE menu) being set to YES. To solve this, simply change the
   LOCAL ECHO setting to NO.

*** 100 $0034

Q: When using the  (Nodelist dial) function, the Terminal does not
   prompt for the use of script files, but there are several script files
   (*.SCR) present in the system directory.

A: The TERMINAL.MISCELLANEOUS.SCRIPTS IN NODELIST DIAL setting controls
   whether or not the Terminal should honor the presence of script files and
   prompt for one to be used when the nodelist dial function is invoked.

*** 102 $0035   

Q: When I return from the DOS/OS shell, I sometimes find my connection has
   closed. Why?

A: Some services you may use have idle timers which will automatically
   disconnect you after a period of no activity across the communications
   link. Ensure that you complete your tasks in the DOS/OS shell as soon as
   possible to avoid this.

============================================================================
BBS
============================================================================

*** 100 (DOS) $0036

Q: When the BBS is used locally (local logon), the BBS software reports a
   very low amount of time remaining, or no time at all. due to a system
   event; yet, no event is pending or due.

A: It is possible that the BBS software is reading the contents of an old
   DOBBS*.BAT file, generated by FD for the last remote caller. Try
   removing the applicable DOBBS*.BAT file and attempt to logon locally to
   the BBS again.

============================================================================
Creating a "maintenance" or "mail" task
============================================================================

*** 102 $0039

Q: I want to set-up a line/task that is only used to execute external events
   at specific times and to handle the processing of mail (tossing,
   scanning, and packing) as well as other general maintenance tasks. I do
   not want this task to place any outbound calls nor to require a modem, is
   this possible?

A: Yes, it is possible; and quite simple. Create/update the necessary
   configuration files as if you were to add a "normal" task. You will need
   to use a unique task number and create a new event and modem
   configuration database by using FDSETUP (with the new, unique task
   number).

   Use FDSETUP to modify the modem configuration for the new task and
   remove the configuration data for the following modem command strings:
     On-hook, Off-hook, Dial, Prefix, Suffix, Init-1 .. Init-3, TermInit,
     Down, and Attention.
   Configure "Manual answer" to "NO". Remove the configuration data for the
   Ok status message. Set the "Lower DTR when busy" and "Lower DTR to
   terminate call" settings to "YES".

   For the DOS version, you will need to have a FOSSIL driver loaded since
   FD checks for a FOSSIL driver when starting.
   For the OS/2 version, you will need a COM port available. If you are
   using the SIO driver package by Ray Gwinn, you can create "virtual COM
   ports" (please refere to the SIO/VMODEM documentation for instructions on
   doing this).

============================================================================
Adding "drag and drop" functionality for sending files
============================================================================

*** 102 $0040

Q: Can I send files using "Drag and drop" functionality (Windows, OS/2, etc)
   so I can drag files from my desktop onto an icon or folder?

A: This can be accomplished by utilizing what is referred to as a "spool
   entry" or "spool directory" which is a feature of the static queue (STQ)
   introduced in 2.30/2.25.

   (1) Create a spool directory. This directory can be located anywhere as
       long as FD can access it.

   (2) FD must be told to treat the directory as a spool directory. This is
       done by using XRobot (available from the Definite Solutions web
       site); use the QSPOOLMAKE command and ensure that you specify a
       filemask that includes all files in the directory (*.*).

   (3) Create a "shadow" or "shortcut" folder on your desktop that refers to
       the directory created in (1).

   (4) When you drag a file to the newly created folder, it will be moved or
       copied to that folder by the operating system. It is then available
       for delivery and/or pick-up.

   It should be noted that:

   (A) FD will not detect that files have been added to the spool directory
       until it rescans. For a spool directory with "Hold" status, this is
       not a problem since such entries are always scanned when the remote
       (destination) system calls to pick-up mail, but for spool directories
       with "Normal", "Crash", and/or "Immediate" status, this may cause a
       delay in the delivery of the files.

       A possible solution is to create another desktop icon which refers to
       XRobot using the TOUCH command to update the FDRESCAN.NOW semaphore.

   (B) A spool directory reference in the static queue (STQ) can only have
       one destination system. It is thus necessary to repeat the above
       procedure (1-4) for each system you wish to have "drag and drop"
       capabilities for.

============================================================================
Utilizing SIO/VMODEM for local access under OS/2
============================================================================

*** 102 $0041

Q: I want to access my mail system and/or BBS just like a remote system or
   caller would access it, but calling myself with a modem tends to be a bit
   expensive; is there a way I can accomplish this without handing over more
   of my hard earned money to the telecom company?

A: This can be done under OS/2 by using the SIO/VMODEM package written by
   Ray Gwinn. The SIO package is a set of replacement communications drivers
   for the OS/2 operating system; generally recommended as very good drop-in
   replacements for the standard OS/2 COM.SYS driver.

   The SIO package also includes a FOSSIL driver (VX00) which is recommended
   over using a standard FOSSIL driver if you are running the DOS version of
   FrontDoor.

   Finally, the SIO package includes something referred to as "VMODEM" which
   basically allows FrontDoor to communicate over a TCP/IP network. It can
   be used to communicate between two sessions ("windows") on the local
   machine, as well as other machines; next to each other or anywhere else
   you may want to go using the Internet.

   You need to install and configure SIO/VMODEM; as well as TCP/IP. Then you
   use either an existing TCP/IP loopback address, or create a new (using
   "ifconfig lo "). This address is then used to call from, for
   example, the FrontDoor terminal in one session ("window") to your system
   running in another session. You must, of course, configure a line/task to
   handle inbound calls that are received through the TCP/IP  (VMODEM)
   interface.

   The above procedure can also be used to make your system available for
   telnet and VMODEM sessions over the Internet.

============================================================================
Interfacing a DOS BBS application with the OS/2 version of FrontDoor
============================================================================

*** 102 $0047

Q: I want to use the OS/2 version of FrontDoor, but I need to interface with
   a DOS BBS package, is this possible?

A: Yes, it is possible; although perhaps not entirely obvious. The below
   example was submitted by Mark Lewis and illustrates how the OS/2 version
   of FrontDoor can be interfaced with the RemoteAccess DOS BBS package. It
   should be noted for the data below that Mark is using the SIO package by
   Ray Gwinn and the HSTART package by Henk Kelder.

   It should also be pointed out that the below data is meant as an example.

   The first thing to do is to ensure that you are using Ray Gwinn's SIO
   package. Configure SIO with the trailing '-' parameter as detailed in the
   SIO docs and as shown in Fig 1.

   DEVICE=C:\SIO\SIO.SYS (COM1,3F8,4,-) (COM2:115200,2F8,3,-)
   DEVICE=C:\SIO\VSIO.SYS
   (Fig 1.)

   You need a CMD file to run FD/2 from. Fig 2 is a sample.

   @echo off
   echo.
   set task=1
   set fd=c:\fd
   echo.
   echo MyOnlineService/2 Node %task% initiating...
   :start
    c:
    cd %fd%
    %fd%\fd2
    if errorlevel  33 goto end
    if errorlevel  32 goto midnight
    if errorlevel  31 goto inbound
    if errorlevel   1 goto end
    goto end
   :midnight
    hstart "Maint on %task%" /DOS /S:%fd%\HS-BBS_2.CFG /C /WIN /B /MAX /WAIT
    (cont. of prev. line)%fd%\midnite.bat %task%
    goto start
   :inbound
    hstart "MailRUN on %task%" /DOS /S:%fd%\HS-BBS_2.CFG /C /WIN /B /MAX
    (cont. of prev. line)/WAIT %fd%\tossmail.bat %task%
    goto start
   :end
    echo.
    echo MyOnlineService/2 Node %task% terminating...
    pause
    exit
   (Fig 2.)

   The CMD file shown in Fig 2 demonstrates the ability to start a DOS task
   from an OS/2 task using a third party util called HSTART. We are using
   HSTART in this example because it is able to start OS/2 tasks from the
   DOS side if/when needed.

   FD/2 executes EXEBBS.CMD directly so we need to create one. Fig 3 is
   another example.

   @echo off
   echo.
   echo Entering EXEBBS.CMD...
   rem 

   rem   %1      %2        %3       %4       %5           %6          %7
   echo Creating DOBBS%4.BAT for RemoteAccess to use...
   echo EXEBBS %1 %2 %3 %4 %5 %6 %7 > c:\ra\dobbs%4.bat
   echo Starting RemoteAccess BBS...
   echo hstart "WPUSA %4" /DOS /S:c:\ra\HS-BBS_2.CFG /WIN /B /MAX /C /WAIT
   (cont. of prev. line) c:\ra\EXEBBS.BAT %1 %2 %3 %4 %5 %6 %7
   hstart "WPUSA %4" /DOS /S:c:\ra\HS-BBS_2.CFG /WIN /B /MAX /C /WAIT
   (cont. of prev. line) c:\ra\EXEBBS.BAT %1 %2 %3 %4 %5 %6 %7
   (Fig 3.)

   This EXEBBS.CMD shows how to create a DOBBS.BAT for those BBS packages
   that can use it. Then we use HSTART to start the DOS BBS via a .BAT file
   like normally used. In this example, we have chosen to use the DOS name
   EXEBBS.BAT. An example is found in Fig 4.

   @echo off
   rem 

   rem   %1      %2        %3       %4       %5           %6          %7
   echo Starting EXEBBS.BAT...
   echo.
   echo Passed Parameters are :
   echo -----------------------
   echo                 Speed : %1
   echo                  Port : %2
   echo Minutes till NoHumans : %3
   echo                  Task : %4
   echo    Connection Message : %5
   echo  CallerID Information : %6
   echo    Passed Port Handle : %7
  :start
   set RA=c:\ra
   cd %ra%
   if '%2' == '0' goto local
  :bbscaller
   %ra%\ra.exe -E10 -N%4 -B%1%5 -C%2 -T%3
  :afterra
   if errorlevel  3 goto aftercaller
   if errorlevel  2 goto local
   if errorlevel  0 goto aftercaller
  :local
   %ra%\ra.exe -E10 -L -D -N%4
   goto afterra
  :aftercaller
   topstat
  :end
  exit
  (Fig 4.)

  That's pretty much it except for the HS-BBS_2.CFG file. It is only used by
  HSTART to set the necessary parameters for the DOS box. You only need it
  to change the settings from the defaults. There are a lot of settings that
  can go in that file. It's main use in this setup is to allow or deny
  access to the comm port. In a multinode environment, we don't want to
  allow access from other tasks. Its bad enough that we have to use the '-'
  on the SIO line. Fig 5 contains all the known settings that can be in a
  HSTART config file. Those that start with a '*' are commented out but left
  for the curious. The ones that are not commented out are the ones that are
  necessary for this site to operate. I can't guarantee that all settings
  are followed by the correct options. Only the numerical ones are known.
  You'll need to refer to the HSTART package for more information on the use
  of the config file with HSTART. This writer is using HSTART04.ZIP dated 11
  December 1993 by Henk Kelder, 2:280/801.339@fidonet.org. according to the
  documentation.

  *SET AUDIO_ADAPTER_SHARING=1;
  *SET DOS_AUTOEXEC=C:\AUTOEXEC.BAT;
  *SET DOS_BACKGROUND_EXECUTION=1;
  *SET DOS_BREAK=0;
  SET DOS_DEVICE=SIZE=0 C:\TCPIP\BIN\VDOSTCP.SYS,SIZE=0
  (cont. from prev. line) C:\OS2\MDOS\ANSI.SYS,SIZE=0 C:\SIO\VX00.SYS;
  SET DOS_FCBS=16; SET DOS_FCBS_KEEP=8;
  SET DOS_FILES=100;
  SET DOS_HIGH=1;
  SET DOS_LASTDRIVE=Z;
  SET DOS_RMSIZE=640;
  *SET DOS_SHELL=C:\4DOS\4DOS.COM C:\4DOS;
  SET DOS_UMB=1;
  SET DPMI_DOS_API=AUTO;
  SET DPMI_MEMORY_LIMIT=4;
  SET DPMI_NETWORK_BUFF_SIZE=8;
  SET EMS_FRAME_LOCATION=AUTO;
  SET EMS_HIGH_OS_MAP_REGION=0;
  SET EMS_LOW_OS_MAP_REGION=384;
  SET EMS_MEMORY_LIMIT=2048;
  *SET HW_NOSOUND=0;
  *SET HW_ROM_TO_RAM=0;
  *SET HW_TIMER=1;
  *SET IDLE_SECONDS=0;
  *SET IDLE_SENSITIVITY=75;
  *SET INT_DURING_IO=0;
  *SET KBD_ALTHOME_BYPASS=0;
  *SET KBD_BUFFER_EXTEND=1;
  *SET KBD_CTRL_BYPASS=NONE;
  *SET KBD_RATE_LOCK=0;
  *SET SESSION_PRIORITY=1;
  SET SIO_Allow_Access_COM1=0;
  SET SIO_Allow_Access_COM2=1;
  SET SIO_Allow_Access_COM3=0;
  SET SIO_Allow_Access_COM4=0;
  SET SIO_Idle_Sensitivity=100;
  *SET SIO_Mode_DTR=No Change at OPEN or CLOSE;
  *SET SIO_Mode_FIFO_Load_Count=16;
  *SET SIO_Mode_IDSR=Ignore DSR During Receive;
  *SET SIO_Mode_OCTS=HandShake Signal, as in RTS/CTS;
  *SET SIO_Mode_ODSR=Ignore DSR During Transmit;
  *SET SIO_Mode_RTS=HandShake Signal, as in RTS/CTS;
  *SET SIO_Mode_XON/XOFF=No XON/XOFF flow control by SIO;
  SET SIO_Screen_Sync_Kludge=0;
  SET SIO_Share_Access_With_OS/2=1;
  SET SIO_Virtualize_16550A=1;
  SET SIO_Virtualize_COM_Ports=1;
  *SET VIDEO_8514A_XGA_IOTRAP=1;
  *SET VIDEO_FASTPASTE=1;
  *SET VIDEO_MODE_RESTRICTION=NONE;
  *SET VIDEO_ONDEMAND_MEMORY=1;
  *SET VIDEO_RETRACE_EMULATION=0;
  *SET VIDEO_ROM_EMULATION=1;
  *SET VIDEO_SWITCH_NOTIFICATION=0;
  *SET VIDEO_WINDOW_REFRESH=1;
  SET XMS_HANDLES=32;
  SET XMS_MEMORY_LIMIT=2048;
  SET XMS_MINIMUM_HMA=0;
  (Fig 5.)

  Some settings in the HSTART config file are not needed for normal use. Of
  note is the TCPIP entry which is needed on this system for DOS tasks to
  access TCPIP network protocol stack.

============================================================================
Running the DOS version of FrontDoor under Linux
============================================================================

*** 102 $0048

Q: I want to use the DOS version of FrontDoor under Linux, is this possible?

A: Yes, it is possible to run the DOS version of FrontDoor on the iNTEL
   platform version of Linux. The below example was submitted by Francois
   Thunus and illustrates how the DOS version of FrontDoor can be used under
   Linux.

   It should also be pointed out that the below data is meant as an example.

   Setting up DosEMU
   -----------------
   Please report to DosEMU configuration manual for precise details.

   The general idea is this:

   Create a bootable dos floppy with whatever dos version you want. Set up
   CONFIG.SYS and AUTOEXEC.BAT files to run whatever you would in dos like
   BNU (FOSSIL driver). Set your paths to reflect paths on the C: drive
   (assuming that's where your FrontDoor is). Try booting it in DOS to make
   sure everything runs OK. Then in linux, make a disk image using this
   floppy using: dd if=/dev/fd0 of=/var/lib/dosemu/adrive bs=16k where
   "if"=location of linux floppy drive, "of"=path/name of disk image (in my
   case "adrive" in the /var/lib/dosemu dir).

   Now modify /etc/dosemu.conf to use this file to boot from. There is a
   line in it that is probably commented out. If not, add it in floppy disk
   section:

   floppy {heads 2 sectors 18 tracks 80 threeinch file /var/lib/dosemu/adrive}

   (of course change any path to your setup and comment out any other
   "floppy" lines, for now)

   In the dosemu boot section, setup a line to boot from the floppy image:
   bootdisk {heads 2 sectors 18 tracks 80 threeinch file/var/lib/dosemu/adrive}
   Now dosemu should boot from that disk image file.

   Now running xdos should boot from your disk image and your /dev/hda
   should give you read/write access to your C: drive.

   Linux configuration
   -------------------
   in /etc/rc.d/rc.local:
     setserial /dev/ttyS1 spd_vhi

   in /etc/dosemu.conf:
     serial { com 2 device /dev/ttyS1 }
     ttylocks { directory /var/lock namestub LCK.. }

   FrontDoor configuration
   -----------------------
   in mailer.bat (on dosemu):
   LH BNU /R=4096 /T=8192 /P1 /L1:115200,8N1
   You have to make sure that you lock the port for reliable transfers.
   (BNU is a FOSSIL driver written by David Nugent)

   Miscellaneous
   -------------
   FD (mailer) is reported to work with:
     Slackware 3.4 (Kr 2.0.30) / DosEmu 0.66.7 / DOS 6.22

   For FM (editor), it may be necessary to use the FDOPT=NORES environment
   variable

   Try to avoid forward slashes in names and paths.

============================================================================
Utilizing the internet to exchange FidoNet mail
============================================================================

*** 103 $0050

Q: I want to utilize my Internet connection to exchange FidoNet mail, can I
   do this with FrontDoor?

A: Yes; by using a TCP/IP-aware FOSSIL driver such as COM/IP from Tactical
   Software or SIO/VMODEM by Ray Gwinn, you can make FrontDoor use a TCP/IP
   session to exchange mail with other FidoNet systems.

   Very few settings need to be changed for using COM/IP; the recommended
   init string for COM/IP is:

     ATS0=0S1008=23S1002=1S1003=6S1001=0S1004=1S1005=0W1

   COM/IP is developed by Tactical Software (www.tacticalsoftware.com); SIO/
   VMODEM is developed by Ray Gwinn (www.gwinn.com). There is some more
   information about SIO/VMODEM in this document, see note $0041.

*** 103 $0051

Q: I am having problems with Windows 2000 and COM/IP, are there any common
   problems with this combination?

A: Make sure that you are using COM/IP version 2.27 or above as previous
   versions of COM/IP have known problems in the W2K environment.

// end of file "fdfaq103.txt"

PIDLIST (FSC-0046)

Document: PIDLIST.TXT (FSC-0046)
Date:     11-Sep-96

                     A list of used product idenfifiers

                    Joaquim Homrighausen, joho@defsol.se

Product identifiers

Product                Version ID        Author
----------------------------------------------------------------------------
!!MessageBase           1.6    !!MB      Holger Lembke          2:240/500.20
Alert                   2.1    Alert     Richard Kail           2:310/25.2
ANet                    921213 ANet      Thomas Ekstroem        2:201/411
Announcer               1.0+   Announcer Peter Karlsson         2:206/221
ArcMail RISC OS         1.04   AM        Philip Blundell        2:440/34.4
Artmail Mailer System   1.00   ART       Klaus Landefeld        2:247/402
Auto Message Taker      1.00   AMT       Patrik Torstensson     n/a
AVALON                  3.73+  AVALON    Stephan Slabihoud      2:2446/110.6
BeroPoint               1.0+   BeroPoint Bernhard Rosenkraenzer 2:2452/307.46
Blender                 1.01   Blender   Serge Vikulov          2:5080/5
The Brake! Mailer       1.0+   The-Brake! John Gladkih          2:5051/16
CMBBS                   3.26   CMBBS     Christof Engel         2:2490/5110
CE-Point                3.26   CE-Point  Christof Engel         2:2490/5110
CrossEd                 1.00+  CROSSED   Mathias Kowalkowski    2:2454/207.1
CrossPoint              2.10   XP        Peter Mandrella        2:243/97.80
Dazzle Wizard           4.00   DazzleWiz Jan H. Andersen        2:238/51
EchoList Expert         .99    ELX       George Hannah          1:255/7
EchoSprint              1.02   ES        Ben Elliston           3:620/262
Enhanced Mail MAnager   .01    EMMA      Johan Zwiekhorst       2:292/118
Enhanced Message EDitor .02    EMED      Johan Zwiekhorst       2:292/118
Eternity BBS            1.00   Eternity  Isaac Oates            1:107/445
EZMail                  .67    EZMail    Torben Paving          2:234/41
FastEcho                1.21+  FastEcho  Tobias Burchhardt      2:2448/400
FDREQ                   1.12   FDREQ     Manfred Schramm        2:2446/502
FDWorks                 1.2    FDWorks   Tilli Weissenberger    2:310/29.5
FileScan                1.5    FileScan  Matthias Duesterhoeft  2:241/4513
FMail                   1.02+  FMail     Folkert Wijnstra       2:283/619
Freqit (MS-DOS)         1.0    FID       Marvin Hart            1:106/462
Freqit (Windows)        1.0    FIW       Marvin Hart            1:106/462
FrontDoor (Editor)      2.00+  FM        Joaquim Homrighausen   2:270/17
FrontDoor (Mailer)      2.00+  FD        Joaquim Homrighausen   2:270/17
FrontDoor APX           1.00+  FDAPX     Joaquim Homrighausen   2:270/17
FrontDoor APX/w         1.00+  FDAPX/w   Mats Wallin            2:270/19
FrontDoor Manager       1.00   FDMGR     Thomas Raehalme        2:220/412
FrontDoor RP for RA     1.21+  FDRPR     Mats Wallin            2:270/19
FrontEnd FX             1.00   FEFX      Eric Theriault         1:132/220
FrontEndTime            1.00   FETime    Eric Theriault         1:132/220
FX Editor               1.00   FXE       Eric Theriault         1:132/220
F_POINT                 1.1    F_POINT   Florian Rupp           2:248/107.2
GEcho                   1.00   GE        Gerard van der Land    2:2802/110
GeeMail                 2.00   GeeMail   Lech Szychowski        2:480/4.7
HbToSca                 1.00   HTS       Jani Laatikainen       2:220/150
HyperBBS                2.00   HyperBBS  Jani Laatikainen       2:220/150
JetMail                 1.00   JetMail   Daniel Roesen          2:243/93.8
JosEcho                  .53g  JosEcho   Jose Rodriguez         2:340/15.20
Juggernaut              1.00+  JDR_BBS   John Rohner            n/a
LA                      1.51+  LA        Erik Groten Steenwelle 2:283/412.1
LapMail                 1.00+  LapMail   Svetoslav Alexandrov   2:350/66
LazyBBS                 .5     LazyBBS   Franck Arnaud          2:320/100
LED                     1.25+  LED       Stephan Slabihoud      2:2446/110.6
M-POINT                 1.74   M-POINT   Manfred Schramm        2:2446/502
Mail FX                 1.00   MFX       Eric Theriault         1:132/220
McMail                  1.0    McMail    Gordian Schuermann     2:2426/2001
MsgTrack                3.20   MT        Andrew Farmer          1:243/1
NewsAgent               .01    NAgent    Steven Bagley          2:2501/101.12
NewsFlash               1.01   NwF       Chris Lueders          2:2402/330
NewsPost                1.6    NewsPost  Andreas Otto           2:2452/307
NodeList Expert         .90    NLX       George Hannah          1:255/7
Notify                  2.1    Notify    Frank Schuhardt        2:247/160
Now Playing             1.01+  NP        Sam Wormleighton       2:250/109.25
O/T-Track               2.60   O/T       Peter Hampf            2:241/1090
OFFFax                  3.03   OFFFax    Frank Schuhardt        2:247/160
PktMake                 1.5    PktMake   Dmitry Morozovsky      2:5020/268
PmFido                  .50+   PmFido    Jiri Kuchta            2:421/13.7
Pobble                  .15    Pobble    Josh Parsons           3:771/340
Post 'em All!           1.10+  PEA       Basil Vorontsov        2:5020/487
QBBed                   2.64   qbbed     Werner Berghofer       2:310/90.100
RASS                    1.00   RASS      Yossi Gottlieb         2:403/139.75
RemoteAccess            1.10   RA        Andrew Milner          2:270/18
SendFile                1.00   SendFile  Mike Shoyher           2:5020/17.3
SING Application        2.16   SING App  Eric Theriault         1:132/220
SpeedMail               1.01   SpeedMail Tilli Weissenberger    2:310/29.5
SuperFX BBS             1.00   SFXBBS    Eric Theriault         1:132/220
Synchronet              1.00   SYNC      Rob Swindell           1:103/705
Synthesis BBS (BBS)     1.00   SynBBS    Eric Theriault         1:132/220
Synthesis BBS (Mailer)  1.00   SynMail   Eric Theriault         1:132/220
TB-Edit                 1.10   TB-Edit   Arjen Lentz            2:283/512
TB-Mailer               1.97   TB-Mailer Arjen Lentz            2:283/512
TB-Point                .10    TB-Point  Arjen Lentz            2:283/512
TechBBS                 1.00   TECHBBS   Marcel Tegelaar        2:281/409
TechMail                1.00   TECHMAIL  Raymond van der Holst  2:281/409.2
TeleMail                1.10   TeleMail  Juergen Weigelt        2:2453/900                  (eMail address)
Terminate/TerMail       1.51+  TerMail   Bo Bendtsen            2:254/261
TosScan                 1.10   TosScan   Joaquim Homrighausen   2:270/17
TPCS                    .89b   TPCS      Krister Hansson-Renaud 2:201/201.7
                                         Mikael Kjellstrom      2:201/201.10
TrapToss                1.20   TrapToss  Rene Hexel             2:310/6
UU2 FIDO/Internet gate  1.92   UU2       Dmitry Zavalishin      2:5020/32
XCOM                    1.00   XCOM      Uwe Kornnagel          2:2464/333
XRobot                  3.00   XRobot    Joaquim Homrighausen   2:270/17
Xrs Alternative Packer  1.04   XAP       Jeroen Smulders        2:512/1.8
Zack! BBS               1.00+  Zack!     Magnus Titho           2:2449/730.8
ZeroToss                1.00   ZeroToss  Jeff Masud             1:103/115
ZNotify                 .65    ZNotify   Boris Huertgen         n/a
-----------------------------------------------------------------------------

Product identifier registration

Simply fill in the required information and send this form to the author of
this document via private netmail.

 Product: _________________________________________

 Version: __________

PID info: _________________________________________

  Author: _________________________________________

 Address: ___________________________ (eMail address)

--- end of file "pidlist.txt" ---

A Product Idenfifier for FidoNet Message Handlers (FSC-0046)

Document: FSC-0046
Version:  005
Date:     30-Aug-94



            A Product Idenfifier for FidoNet Message Handlers

                    Joaquim Homrighausen, joho@defsol.se

                              August 30, 1994

         Copyright 1994 Joaquim Homrighausen; All rights reserved.



Status of this document:

     This FSC suggests a proposed protocol for the FidoNet(r) community,
     and requests discussion and suggestions for improvements.
     Distribution of this document is unlimited.

     Fido and FidoNet are registered marks of Tom Jennings and Fido
     Software.


Purpose

    This document should serve as a guide for the product identfier, PID
    hereafter, format for FidoNet message handlers. The purpose behind PIDs
    is related to my attempt to remove the requirement of Origin lines in
    conference mail messages.

    While I fully understand that this won't happen in all conferences, I
    would like to provide the facility to those who can use it (i.e. for
    conferences where all the participants are using software that supports
    messages without origin lines).

    Another use for PIDs is to minimize the excessive amount of information
    some programs put on the tear lines which increases overall
    transportation cost and time of conference mail.


PID

    A PID replaces the program identifier often seen on the tear line of
    conference mail messages and is hidden behind a ^A (ASCII SOH, 01h).
    This also allows for better tracking of software causing problems in
    conferences.

:   Only one PID per message is allowed and should only be added by the
:   program that creates the message. I.e. programs passing the message on
:   to someone else may not add additional PIDs. If a PID is added, no
:   program information may be present after the tear line.

    A PID also offers the ability to add serial numbers to identify a
    specific copy of a program as being the source of a message with little
    or no effort.


Format

      ^APID:  [ ]


Sample

      ^APID: FM 2.11.b

      Would identify FrontDoor's editor, beta version 2.11 and replace:

       --- FM 2.11 (beta)


Fields

    pID         The ID of the product responsible for creating the message.
                This should be kept as short as possible. The maximum
                length for this field is 10 characters.

    version     The version of the product including any alpha, beta, or
                gamma status. Only the relevant part of the version should
                be included. I.e. 1.00 should be expressed as 1, 1.10 as
                1.1 and 1.01 as 1.01. Alpha, beta, or gamma status should
                be expressed by appending a / or . followed by a, b, or g
                and optionally a revision indicator, such as a1, b2, etc.
                The maximum length for this field is 10 characters.

    serial#     The serial number of the product, omitted if irrelevant
                or zero. The maximum length for this field is ten (10)
                characters.


TID

    TIDs or "Tosser IDs" started to appear shortly after the first
    revision of this document was released. They are added by Conference
    Mail ("EchoMail") processors when a message is exported from the
    local message base and injected into the network distribution scope
    for a conference.

    When a Conference Mail processor adds a TID to a message, it may not
    add a PID. An existing TID should, however, be replaced. TIDs follow
    the same format used for PIDs, as explained above.


List of products

    The accompanying file, PIDLIST.TXT, is a list of products known to
    support the PID proposal. Software authors are encouraged to inform
    the author of this document of changes and additions to this list.

     --- end of file "fsc-0046.005" ---

JAM(mbp) – The Joaquim-Andrew-Mats Message Base Proposal

Filename....: JAM-001
Rev.........: 001
Dated.......: 93-07-01
Status .....: Released
Subject.....: JAM message base proposal
Author......: Joaquim Homrighausen
Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin

    ---------------------------------------------------------------------
                                  JAM(mbp)
                The Joaquim-Andrew-Mats Message Base Proposal
    ---------------------------------------------------------------------
            Copyright 1993 Joaquim Homrighausen, Andrew Milner,
                           Mats Birch, Mats Wallin.
                             ALL RIGHTS RESERVED.
    ---------------------------------------------------------------------

    =====================================================================
    Restrictions
    ---------------------------------------------------------------------
    JAM may be used by any developer as long as these specifications are
    followed exactly. JAM may be used free-of-charge by any developer
    for any purpose, commercially or otherwise.

    This document may be freely copied and distributed, but must NEVER be
    distributed in a modified form. If you have an enhancement request,
    please contact the author of this document; do not change it
    yourself.

    All applications that support JAM must include one of the following
    notices in their documentation and somewhere in the product's credit
    section:

    "JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner,
                               Mats Birch, Mats Wallin.
                               ALL RIGHTS RESERVED."

    or

    "This product uses the JAM(mbp) API -
     Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch,
                    Mats Wallin. ALL RIGHTS RESERVED."

    No organization, company, person, entity, or other being may impose
    any fees for any reason for providing this document or the
    accompanying API. This document and the accompanying API may not be
    sold or otherwise transferred for personal or company gain under any
    circumstances.

    =====================================================================
    Definitions and general notes
    ---------------------------------------------------------------------
    CURRENTREV                1

    JAM                       The JAM message base format.

    CRC                       Cyclic Redundancy Check. All CRC values
                              calculated on strings must assume that the
                              data within the string has been converted
                              to lowercase (A-Z = a-z).

    CRC-32                    32-bit CRC (as used in the Zmodem file
                              transfer protocol) value. The polynom for
                              a CRC-32 is edb88320H and the CRC-32 seed
                              is -1L (ffffffffH).

    uchar                     Unsigned 8-bit value

    ushort                    Unsigned 16-bit value

    ulong                     Unsigned 32-bit value

    UNIX date                 An ulong representing the number of seconds
                              since midnight, January 1, 1970. UNIX-style
                              dates is the only form of time stamps used
                              in JAM (1).

    Message #                 The physical record number within the index
                              file is used as a message number. The
                              lowest message number is one (1) and the
                              highest message number is 4294967295
                              (ffffffffH).

    FTN                       FidoNet Technology Network

    FTS                       FidoNet Technical Standard

    (1) All timestamps created locally (i.e. those not imported from
        other systems) are stored in local time.

    =====================================================================
    Files
    ---------------------------------------------------------------------
    Each conference is made up from four files. How and where these files
    are stored and named is implementation dependant. The only file with
    a fixed minimum size is the .JHR (header data) file. It has a 1024-
    byte block used to hold information about a specific message area as
    described later.

    filename.JHR - Message header data
    filename.JDT - Message text data
    filename.JDX - Message index
    filename.JLR - Lastread information

    A future revision of JAM may also include a file that holds the
    following three items:

      - The highest assigned user number
      - The last generated message ID
      - A global conference list with the conference name, description,
        and physical location of the message base.

    =====================================================================
    .JHR file header
    ---------------------------------------------------------------------
    Below is the format of the 1024-byte record at the beginning of all
    .JHR files. The first actual message header starts at offset 1024 in
    the .JHR file.

    FixedHeaderInfoStruct:
        ulong   Signature;       // <J><A><M> followed by <NUL>
        ulong   datecreated;     // Creation date
        ulong   modcounter;      // Update counter
        ulong   activemsgs;      // Number of active (not deleted) msgs
        ulong   passwordcrc;     // CRC-32 of password to access
        ulong   basemsgnum;      // Lowest message number in index file
        uchar   RESERVED[1000];  // Reserved space
    end;

    MODCOUNTER must be incremented and updated on disk each time an
    application modifies the contents of the message base. When it
    reaches ffffffffH, it wraps to zero.

    ---------------------------------------------------------------------
    BaseMsgNum                        Lowest message number in index file
    ---------------------------------------------------------------------
    This field determines the lowest message number in the index file.
    The value for this field is one (1) when a message area is first
    created. By using this field, a message area can be packed (deleted
    messages are removed) without renumbering it. If BaseMsgNum contains
    500, the first index record points to message number 500.

    BaseMsgNum has to be taken into account when an application
    calculates the next available message number (for creating new
    messages) as well as the highest and lowest message number in a
    message area.

    ---------------------------------------------------------------------
    ????????.JHR                                          Message headers
    ---------------------------------------------------------------------
    The .JHR file contains none or more Header records. Each record
    define one message and contains information about the message and its
    text (if any). The Header record is of variable length. The layout of
    the Header record follows.

    MessageHeader:
        MessageFixedHeader:
            ulong  Signature;    // <J><A><M> followed by <NUL>
            ushort Revision;     // Revision level of header          (1)
            ushort ReservedWord; // Reserved for future use
            ulong  SubfieldLen;  // Length of subfields               (2)
            ulong  TimesRead;    // Number of times message read
            ulong  MSGIDcrc;     // CRC-32 of MSGID line              (3)
            ulong  REPLYcrc;     // CRC-32 of REPLY line              (3)
            ulong  ReplyTo;      // This msg is a reply to..
            ulong  Reply1st;     // First reply to this msg
            ulong  Replynext;    // Next msg in reply chain
            ulong  DateWritten;  // When msg was written
            ulong  DateReceived; // When msg was read by recipient
            ulong  DateProcessed;// When msg was processed by tosser/
                                 // scanner
            ulong  MessageNumber;// Message number (1-based)
            ulong  Attribute;    // Msg attribute, see "Msg Attributes"
            ulong  Attribute2;   // Reserved for future use
            ulong  Offset;       // Offset of text in ????????.JDT file
            ulong  TxtLen;       // Length of message text
            ulong  PasswordCRC;  // CRC-32 of password to access message
            ulong  Cost;         // Cost of message
        end;
        SubField1                // Extra fields as defined below
        .
        .
        SubFieldXX
    end;

    (1) This field is intended for future revisions of the specifications
        to allow the use of a different fixed-length binary message
        header. The current revision level is one (1).

    (2) The SubfieldLen field is set to zero (0) if the header does not
        have any subfield data. I.e. the length of the binary header is
        not included in this field.

    (3) When calculating the CRC-32 of the MSGID and REPLY lines, the
        text ^aMSGID: and ^aREPLY: should be removed as well as all
        leading and trailing white space characters.

    The SubField structure is made up of an ID, a length specifier, and
    a block of data. Zero or more subfields may follow the fixed-length
    binary header. SubFields are not stored in any specific order and
    are not terminated by any specific character unless otherwise
    specified.

    SubField:
        ushort  LoID;            // Field ID, 0-65535
        ushort  HiID;            // Reserved for future use
        ulong   datlen;          // Length of buffer that follows
        uchar   Buffer[datlen];  // DATLEN bytes of data
    end;

    ---------------------------------------------------------------------
    Defined LoID codes
    ---------------------------------------------------------------------

    ID=0, Name=OADDRESS

    A network address. This is used to specify the originating address.
    More than one OADDRESS field may exist. DATLEN must not exceed 100
    characters. For a FidoNet-style address, this field must follow the
    ZONE:NET/NODE.POINT@DOMAIN format where .POINT is excluded if zero
    and @DOMAIN is excluded if unknown.

    ID=1, Name=DADDRESS

    A network address. This is used to specify the destination address.
    More than one DADDRESS field may exist (e.g. carbon copies). DATLEN
    must not exceed 100 characters. For a FidoNet-style address, this
    field must follow the ZONE:NET/NODE.POINT@DOMAIN format where .POINT
    is excluded if zero and @DOMAIN is excluded if unknown.

    ID=2, Name=SENDERNAME

    The sender (author) of the message. DATLEN must not exceed 100
    characters.

    ID=3, Name=RECEIVERNAME

    The recipient of the message. DATLEN must not exceed 100 characters.

    ID=4, Name=MSGID

    Used to store the message identification data. All data not relevant
    to the actual ID string, including leading and trailing white space
    characters should be removed. DATLEN must not exceed 100 characters.

    ID=5, Name=REPLYID

    Used to store the message reply data. All data not relevant to the
    actual reply string, including leading and trailing white space
    characters should be removed. DATLEN must not exceed 100 characters.

    ID=6, Name=SUBJECT

    The subject of the message. DATLEN must not exceed 100 characters.
    Note that this field may not be used for FidoNet-style file attaches
    or file requests.

    ID=7, Name=PID

    Used to store the FTN PID kludge line. Only the actual PID data is
    stored and ^aPID: is stripped along with any leading and trailing
    white space characters. DATLEN must not exceed 40 characters.

    ID=8, Name=TRACE

    This is also referred to as ^aVia information in FTNs. It contains
    information about a system which the message has travelled through.
    The format of the field is  where:

       YYYY is the year (1992-9999)
         MM is the month (01-12)
         DD is the day (01-31)
         HH is the hour (00-23)
         MM is the minute (00-59)
         SS is the second (00-59)

    The timestamp is stored in ASCII (0-9) characters. The network
    address is the address of the system. It is expressed in ASCII
    notation in the native format of the forwarding system.

    ID=9, Name=ENCLOSEDFILE

    A file attached to the message. Only one filename may be specified
    per subfield. No wildcard characters are allowed. If this subfield
    is present in a message header, the ATTRIBUTE must include the
    MSG_FILEATTACH bit.

    ID=10, Name=ENCLOSEDFILEWALIAS

    Identical to ENCLOSEDFILE with the exception that the filename is
    followed by a  (00H) and an alias filename to be transmited to
    the remote system in place of the local name of the file.

    ID=11, Name=ENCLOSEDFREQ

    A request for one or more files. Only one filemask may be specified
    per subfield. If the filemask contains a complete path, it is to be
    regarded as an update file request. If this subfield is present in a
    message header, the ATTRIBUTE must include the MSG_FILEREQUEST bit.
    To indicate that a password is to be transmitted along with the
    request, a  (00H) character followed by the password is
    appended. E.g. SECRET*.*MYPASSWORD.

    ID=12, Name=ENCLOSEDFILEWCARD

    One or more files attached to the message. Only one filename may be
    specified per subfield. Wildcard characters are allowed. If this
    subfield is present in a message header, the ATTRIBUTE must include
    the MSG_FILEATTACH bit.

    ID=13, Name=ENCLOSEDINDIRECTFILE

    One or more files attached to the message. The filename points to an
    ASCII file with one filename entry per line. If alias filenames are
    to be used, they are specified after the actual filename and
    separated by a  (00H) character, e.g. C:\MYFILE.LZHNEWS.
    Wildcard characters are not allowed.

    ID=1000, Name=EMBINDAT

    Reserved for future use.

    ID=2000, Name=FTSKLUDGE

    An FTS-compliant "kludge" line not otherwise represented here. All
    data not relevant to the actual kludge line, including leading and
    trailing white space and ^A (01H) characters should be removed.
    DATLEN must not exceed 255 characters. The FTS kludges INTL, TOPT,
    and FMPT must never be stored as separate SubFields. Their data must
    be extracted and used for the address SubFields.

    ID=2001, Name=SEENBY2D

    Used to store two-dimensional (net/node) SEEN-BY information often
    used in FTN conference environments. Only the actual SEEN-BY data is
    stored and ^aSEEN-BY: or SEEN-BY: is stripped along with any leading
    and trailing white space characters.

    ID=2002, Name=PATH2D

    Used to store two-dimensional (net/node) PATH information often used
    in FTN conference environments. Only the actual PATH data is stored
    and ^aPATH: is stripped along with any leading and trailing white
    space characters.

    ID=2003, Name=FLAGS

    Used to store the FTN FLAGS kludge information. Note that all FLAG
    options that have binary representation in the JAM message header
    must be removed from the FLAGS string prior to storing it. Only
    the actual flags option string is stored and ^aFLAGS is stripped
    along with any leading and trailing white space characters.

    ID=2004, Name=TZUTCINFO

    Time zone information. This subfield consists of four mandatory
    bytes and one optional. The first character may be a plus (+) or a
    minus (-) character to indicate a location east (plus) or west
    (minus) of UTC 0000. The plus character is implied unless the first
    character is a minus character. The following four bytes must be
    digits in the range zero through nine and indicates the offset in
    hours and minutes. E.g. 0100 indicates an offset of one hour east of
    UTC.

    ---------------------------------------------------------------------
    Message attributes
    ---------------------------------------------------------------------
    MSG_LOCAL       (0x00000001L)   // Msg created locally
    MSG_INTRANSIT   (0x00000002L)   // Msg is in-transit
    MSG_PRIVATE     (0x00000004L)   // Private
    MSG_READ        (0x00000008L)   // Read by addressee
    MSG_SENT        (0x00000010L)   // Sent to remote
    MSG_KILLSENT    (0x00000020L)   // Kill when sent
    MSG_ARCHIVESENT (0x00000040L)   // Archive when sent
    MSG_HOLD        (0x00000080L)   // Hold for pick-up
    MSG_CRASH       (0x00000100L)   // Crash
    MSG_IMMEDIATE   (0x00000200L)   // Send Msg now, ignore restrictions
    MSG_DIRECT      (0x00000400L)   // Send directly to destination
    MSG_GATE        (0x00000800L)   // Send via gateway
    MSG_FILEREQUEST (0x00001000L)   // File request
    MSG_FILEATTACH  (0x00002000L)   // File(s) attached to Msg
    MSG_TRUNCFILE   (0x00004000L)   // Truncate file(s) when sent
    MSG_KILLFILE    (0x00008000L)   // Delete file(s) when sent
    MSG_RECEIPTREQ  (0x00010000L)   // Return receipt requested
    MSG_CONFIRMREQ  (0x00020000L)   // Confirmation receipt requested
    MSG_ORPHAN      (0x00040000L)   // Unknown destination
    MSG_ENCRYPT     (0x00080000L)   // Msg text is encrypted          (1)
    MSG_COMPRESS    (0x00100000L)   // Msg text is compressed         (1)
    MSG_ESCAPED     (0x00200000L)   // Msg text is seven bit ASCII    (1)
    MSG_FPU         (0x00400000L)   // Force pickup
    MSG_TYPELOCAL   (0x00800000L)   // Msg is for local use only
    MSG_TYPEECHO    (0x01000000L)   // Msg is for conference distribution
    MSG_TYPENET     (0x02000000L)   // Msg is direct network mail
    MSG_NODISP      (0x20000000L)   // Msg may not be displayed to user
    MSG_LOCKED      (0x40000000L)   // Msg is locked, no editing possible
    MSG_DELETED     (0x80000000L)   // Msg is deleted

    (1) This revision of JAM does not include compression, encryption, or
        escaping. The bits are reserved for future use.

    =====================================================================
    ????????.JDT                                             Message text
    ---------------------------------------------------------------------
    The .JDT file contains the text of messages. The text is stored as an
    stream of seven or eight bit ASCII data. Allowed characters in the
    text are 00H through ffH unless the header ATTRIBUTE field has the
    MSG_ESCAPED bit enabled, in which case the legal range of data is 20H
    through 7eH.

    An escaped character is stored as \ where  is the two digit
    hexadecimal ASCII value of the character. A single \ is stored as \\
    or \5C. The case of the hexadecimal ASCII value is irrelevant, i.e.
    5c is treated as 5C.

    =====================================================================
    ????????.JDX                                            Message index
    ---------------------------------------------------------------------
    The .JDX file is used to quickly locate messages for any given user
    name or to locate a message with a specific number. Each record in
    the file consists of two ulongs. The first ulong holds the CRC-32 of
    the recipient's name (lowercase), the second ulong holds the
    physical offset of the message header in the .JHR (header) file.

    The record number (+BaseMsgNum) within the .JDX file determines a
    message's number.

    If both ulongs are -1 (ffffffffH), there is no corresponding message
    header.

    =====================================================================
    ????????.JLR                                         Lastread storage
    ---------------------------------------------------------------------
    The .JLR file is used to maintain a user's position within a message
    area. The layout of the "lastread" record follows. One record per
    user is required.

    LastRead:
        ulong   UserCRC;         // CRC-32 of user name (lowercase)   (1)
        ulong   UserID;          // Unique UserID
        ulong   LastReadMsg;     // Last read message number
        ulong   HighReadMsg;     // Highest read message number
    end;

    (1) The functions to convert a string to lowercase characters that
        are provided in the API will only convert characters A-Z (into
        a-z). It is required that this convention is followed by all
        applications.

    The UserID field is a unique number for each user. If the "lastread"
    record is deleted, UserCRC and UserID are both set to -1
    (ffffffffH). An application may not depend on any specific order in
    the .JLR file. A user's "lastread" record may appear anywhere in the
    file and must be searched for when retrieving it and when storing an
    updated record.

    =====================================================================
    Updating message headers
    ---------------------------------------------------------------------
    If a header record grows after is has been retrieved from the .JHR
    file, it must be appended to the end of the .JHR file since it would
    overwrite the following header otherwise. The .JDX file must be
    properly updated to indicate the new location of the header record.
    The old header record must be changed to indicate that it has been
    deleted by setting the MSG_DELETED bit in the Attribute field and the
    TextLen field to zero (to prevent a maintenance program from removing
    the message text that is now pointed to by another header).

    =====================================================================
    Message base sharing and locking
    ---------------------------------------------------------------------
    To allow several programs to access the message base at any given
    time, region locking is used to protect the message base from being
    corrupted during updates.

    When an application needs to write to any of the message base files,
    it must first attempt to lock the first byte of the .JHR (header)
    file. If the lock call fails, the application must either fail or
    attempt to lock the file again. The message base files may under no
    circumstances be updated if the application cannot successfully lock
    the .JHR file.

    Note that data acquired (read) from the message base may not be used
    when writing data to the message base, unless the application has
    maintained a lock of the message base from the time the data was
    acquired or the MODCOUNTER field is the same as when the data was
    acquired.

    The application must open the files in shareable (DENYNONE) read/
    write or readonly mode. The only exception to this is an application
    that requires exclusive access to the message base, such as a message
    base maintenance utility, it should open the files in non-shareable
    (DENYALL) read/write mode.

    =====================================================================
    Reply threads and linking
    ---------------------------------------------------------------------
    JAM introduces a new reply link pointer, not commonly used today.
    This section is an attempt to describe how reply threads, reply
    linking, and this new reply link pointer is implemented in JAM.

    One of the major differences is that reply threads in JAM are not
    based on similar or identical subjects of messages since this method
    does not allow for proper reply threads.

    The method used in JAM is based on the immediate relation between any
    given message and direct replies to it. This is supported by many
    message editors by using the MSGID and REPLY FTS kludge fields. These
    are common, although expressed differently, in messages not based on
    FidoNet technology, such as RFC-822. The obvious advantages include
    allowing a program to easily find the original message to a reply,
    and to find all replies to any given message.

    The reply thread information consists of three fields: ReplyTo,
    Reply1st, and ReplyNext. The reason for three fields, as opposed to
    just two, is that with two fields, it is only possible to keep track
    of the original message of a reply (which is sufficient) and one
    reply to any given message (which is not sufficient). With three
    fields, it is possible to maintain a thread of any number of replies
    to any given message.

    In the description of the different fields below, the following
    messages and message numbers will be referred to:

      1 -> 2 -> 4 -> 5
      :    :
      :    +--> 8
      :
      +--> 3 -> 7
      :
      +--> 6

    Message number two, three, and six are replies to message number one.
    Message number four and eight are replies to message number two.
    Message number seven is a reply to message number three.
    Message number five is a reply to message number four.

    ---------------------------------------------------------------------
    ReplyTo
    ---------------------------------------------------------------------
    This field holds the number of the message that this message is a
    reply to. In the example above, the ReplyTo field would contain the
    following values:

    Message number one would contain zero; message number two, three, and
    six, would contain one; message number four and eight would contain
    two; message number seven would contain three, and message number
    five would contain four.

    ---------------------------------------------------------------------
    Reply1st
    ---------------------------------------------------------------------
    This field holds the number of the first message that is a reply to
    this message. In the example above, the Reply1st field would contain
    the following values:

    Message number one would contain two, message number three would
    contain seven, and message number four would contain five. All other
    messages would contain zero.

    ---------------------------------------------------------------------
    ReplyNext
    ---------------------------------------------------------------------
    This field is used to create the actual message thread or chain. In
    the event that there is more than one reply to any given message, it
    is necessary to maintain a thread of all the replies; this is due to
    the fact that the original message can only hold information about
    the first reply (the Reply1st field) to it.

    The first reply (which the original message's Reply1st field holds),
    has its ReplyNext field pointing to the second reply, the second
    reply's ReplyNext field poinst to the third reply, and so on.

    In the example above, the ReplyNext field would contain the following
    values:

    Message number two would contain three, message number three would
    contain six, and message number four would contain eight. All other
    messages would contain zero.

    =====================================================================
    Contacts
    ---------------------------------------------------------------------
    Joaquim Homrighausen

    Andrew Milner

    Mats Wallin

    // end of file "jam.doc"

EMSI goes ISO, sort of

This document may be distributed freely provided no charge of any kind occurs and all accompanying files (XLAT.CPP, ISOXLAT.PAS, ISOTEST.PAS, and ISOEMSI.DOC) is left unmodified.

This is to document what has been suggested as an upcoming addendum to the EMSI specifications. The next version of FrontDoor (higher than 2.10) and, I believe TrapDoor, will (or does) use this scheme when creating the EMSI_DAT packet.

The reason for this is to allow high-bit ASCII (or “international characters”) and national codepages to be used transparently. The new encoding scheme does not break anything in existing implementations unless high-bit ASCII is used, in which case it may affect (cosmetic or otherwise) the operation of a mailer that doesn’t support the new scheme.

Basics

All data that is placed in the EMSI_DAT packet is translated to ISO 8859-1 and then processed as usual. Any escaping as per the EMSI specification, is done after the translation to ISO 8859-1. On the receiving side, the data is first unescaped and then translated from ISO 8859-1 to the local codepage. Data that is strictly seven bit ASCII is not translated by the code accompanying this document.

There is no flag or other indicator to show that the EMSI_DAT packet has been encoded using ISO 8859-1. The IEMSI portion of the EMSI specification is not affected at this time.

Notes

One rather serious drawback is that you will see password failures between mailers that use high-bit ASCII in the password between two systems where one is using a mailer that uses the ISO 8859-1 scheme and the other isn’t. The recommended cure is to either remove the high-bit ASCII, or to have the mailer replaced/updated.

Code

The accompanying code, XLAT.CPP (by Alexander Holy, 2:310/90) and ISOXLAT.PAS and ISOTEST.PAS may be used free of charge, no warranties or guarantees, etc. If you find reason to make changes, we would appreciate hearing about it.

That’s about it..

Joaquim Homrighausen
joho@defsol.se

// end of file “isoemsi.doc”