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"
Documentation
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”