==========================================================================
The FLAME! Disk
Documentation for FLAME v1.1
Copyright 1994, Chris Anderson
==========================================================================
Note that various products referenced herein may be trademarked by their
respective authors. These include numerous products from eSoft. FLAME
v1.1 is an eSoft product, distributed with its own documentation. It is
the purpose of this series of disk files to augment that documentation
in order to make the use and installation of FLAME and associated
software easier for the user.
Certain assumptions will be made about your understanding of basic
FidoNet technology. All such information can be found in the "FidoNet
Primer" file on this disk.
As some of you know, I've been writing documentation of various sorts
for eSoft products for quite a number of years. You may be familiar
with such files as 101WAYS and BASICS as have circulated around FidoNet
and have been supplied on the eSoft support board over the years. I've
also written various utilities (including rewrites of the old ARCMail
mail packer and unpacker, and a FLAME log analyzer that accompanies the
other files on this disk) that have proven useful to TBBS sysops.
Please note that unlike some previous distributions, I am making clear
claim to copyright for the works on this disk, and no unauthorized
duplication of the text files on this disk is permitted.
Future versions may well be undertaken as changes are made to the FLAME
utility or as changes are made as we move from TBBS version 2.2 to 2.3
and beyond. If you'll send me your FidoNet or Internet address, I will
keep you updated on any significant changes that occur.
As with all the similar work I've done, it is my hope that this will
ease your installation process, and save you a few gray hairs. If the
job could have been done better, I welcome your input and suggestions
for improving the content of these files.
Chris Anderson
FidoNet 1:104/114
==========================================================================
Contents of This Disk:
1. THEDOCS! - This file. Contains background information
and tips regarding the use of FLAME.
2. FIDONET.PRI - FidoNet Primer, an explanation of various
terms and techniques used in the operation
of FidoNet technology mailers and networks.
3. FLAMESMP.CFG - Contains all of the FLAME.CFG options with
documentation on the use of each.
4. ROUTESMP.CFG - Contains all of the ROUTE.CFG options with
documentation on the use of each.
5. AREASAMP.BBS - Contains all of the AREAS.BBS type file
options with documentation on the use of each.
6. FLR1001.EXE - The FLAME Reporter, version 1.001. This
program will extract information from your
FLAME log file and produce statistical reports
from this information.
7. FLR1001.DOC - Documentation for FLR1001.EXE.
==========================================================================
In the TBBS, Tips, Traps & Techniques "connectivity chapter" that covers
mail processing utilities, duplication of existing manual material was
almost entirely avoided, and the material presented was to be used to
augment the existing eSoft documentation. The FLAME mail processing
utility, however, is sufficiently complex as to make this approach
impractical for the reader. All of the FLAME configuration and
operating options covered here will be covered fully. It is hoped that
by placing all of the available information on each facet of FLAME in
one place, that you will come to a quicker understanding of how to best
use this utility in your own operating environment. As presently
documented, you may often be able to puzzle out the "what" of a specific
configuration item, but not the "why". The intent of this section is to
clarify all such issues.
In addition to this change in format, very little will be assumed about
prior experience with mail processing utilities. Even if you have such
experience, the manner in which FLAME approaches the issue is likely a
good bit different than what you have used in the past. However, it
*is* assumed that you are already familiar with the basics of FidoNet
technology, or have read and understood the FidoNet primer that
accompanies this file.
This THEDOCS! file contains background material and suggestions for the
use of FLAME. However, the majority of the information is contained
within the configuration file samples themselves. You may wish to begin
with the FidoNet primer or the configuration files, depending upon your
level of expertise.
-1-
==========================================================================
==========================================================================
FLAME. Long awaited, and long on features. FLAME replaces as many as ten
of your existing utilties with one executable file. As you can imagine,
anything with this much functionality must also have a lengthy collection
of configuration options. But once you've got it right, your FidoNet
technology mail requirements can be handled most satisfactorily by this
single program.
--------------------------------------------------------------------------
As noted, FLAME replaces a great many utilities previously used to handle
FidoNet technology mail processing. Each function of FLAME will be
described, and the "old" utility mentioned.
First, FLAME is able to scan your message base for NetMail messages to
other nodes. This function was once performed by the eSoft PREMAIL
utility. In addition, FLAME will scan your EchoMail areas for new mail,
as was once performed by ECHOSCAN.
If you are a mail hub, FLAME will create copies of EchoMail messages
for your downstream nodes, once performed by the eSoft ECHOFWD
program, and will forward NetMail messages.
Tossing mail to your BBS is handled (replaces POSTMAIL), and the
messages within a conversation in EchoMail are linked so that they can
be read as message threads with TBBS (replaces ECHOLINK).
During handling of inbound mail, FLAME checks the integrity of the
messages. Some systems will occassionally totally corrupt a message,
and it would be dangerous to attempt to toss it to your message base.
Moreover, you would not wish to pass such "grunged" messages along to
anyone for whom you are hubbing. FLAME includes detection for many
faults within a message, and replaces that function of the GMD
(Grunged Message Detector) program and others.
Since mail often comes in archives, it is necessary for FLAME to
extract the mail from these archives (replaces ARCmail, Qmail), and
FLAME is able to automatically recognize the archive type as ARC,
ZIP, LZH or whatever others you may define (replaces SPAZ, POLYXARC).
FLAME also handles "point" network responsibilities, replacing such
programs as AUTOROOT and REMAPPER, and can handle requests to
automatically add and delete EchoMail areas from your downstream
nodes, and place such requests with your own hub as needed (replacing
AREAFIX).
FLAME can create file requests and can send files for you, replacing
such utilities as PLEASE, and the SEA (System Enhancement Utilities)
utilities GET, and SEND. It will also create messages from ASCII
text files, replacing the SEA TELL program.
-2-
If you were previously running a "nanny" machine, you will
undoubtedly know about a program called COPYMAIL that takes care of
moving new mail from a second machine to the BBS, and FLAME handles
those tasks for you, too.
--------------------------------------------------------------------------
By now, you should be familiar with the operation of TIMS, or at least
familiar with the function of a "mailer" program. Such software sends and
receives files between systems on an automated basis. Often, the files
sent between these systems are or contain messages of one sort or another.
As is clear from the functions described above, FLAME's purpose is to
act as the interface between your eSoft TBBS software and the your
mailer (your link to the outside world), typically using TIMS, but also
capable of using other mailers.
Please note that at the time of writing, the documentation for TIMS had not
yet been updated to reflect the availability of FLAME. As a result, you
should disregard references to the old NetMail utilities in your reading
of the TIMS manual.
The FLAME utility has not been written to avoid "breaking" your existing
configuration if you are using the old utilities or TMail, and no
conversion utilities are supplied that ease the transition. However,
the only large project may be the manual conversion of any existing
AREAS files to the format required by FLAME, and quite possibly the
massive reduction in your RUNBBS.BAT file to a very few FLAME commands.
In addition to the mail interface functions, FLAME is able to perform
several other tasks that were once performed by other, third party
utilities, or are performed in some less adept fashion by another eSoft
utility -- such as MFSQZ or KILLMAIL and their methods for marking
messages for rolloff deletion during a message base squeeze.
--------------------------------------------------------------------------
As was the case with the older utilities, whether or not you will be
"hubbing" mail for one or more systems will dictate a great deal of your
configuration choices. In fact, many of the FLAME options are not
necessary unless you are serving in this capacity. Those options that are
used only in a hubbing environment will be noted and may be ignored in
end-node configurations.
-3-
--------------------------------------------------------------------------
It would be best to begin with a summary of the various files involved in
the use of the FLAME utility:
FLAME.EXE
This file is the core of FLAME. It is designed to replace the mail
processing functions that were once performed by the old eSoft NetMail
utilities and the third party utility called TMail as noted above. It
also enhances your ability to control the roll-off of old messages in
your message base. As such, it replaces the MSFQZ roll-off marking, or
that done by the old KILLMAIL utility.
It seems that one of the few functions in any sort of common use (and
then, only by file distribution hubs) that was not incorporated
directly into FLAME is the TICK (or RAID) style automatic file
distribution facilities. If you have need of the ability to act as an
automatic distribution point for a wide variety of files, you may need
to make use of such utilities in addition to FLAME. Note that a bit of
batch file gimmickry and the FLAME ATTACH option can handle the more
mundane tasks of NODEDIFF and FNEWS distribution since the filenames
that are expected are very predicatable.
As you can see, FLAME is capable of replacing a very great number of
previous utilities in a single executable file. For this reason,
however, it is a bit of a memory hog, and you may have to exercise some
care about leaving enough conventional memory available in order for
FLAME to perform its various tasks. Just how *much* memory will vary
with your configuration. Typically, you'll find that 530K (type MEM
from the DOS prompt to see) or so of conventional memory is necessary.
--------------------------------------------------------------------------
Other than FLAME.EXE itself, the following executable files are provided
with the FLAME package:
SCANSET.EXE
When you first configure a FLAME system for TBBS, this utility is
used to set a special bit in the message headers of your TBBS
messages that identify them as "already processed" by FLAME. This
prevents the undesirable possibility of having FLAME reprocess
every EchoMail message in your message base and send copies of
them to all of the systems listed in your AREAS file. This is
required due to the absence of any SEEN-BY tracking once messages
are tossed to your TBBS message base by FLAME. FLAME strips all
SEEN-BY information before tossing mail to the TBBS message base
and does not create MSGHIST.BBS or an equivalent file as did TMail
or TIMS TOSS /H. This feature, and its consequences for mail
processing and mail tossing by TIMS will be covered later. Note
that in comparison to previous methods, your MSG.BBS file will be
considerably smaller, or no history file (the large MSGHIST.BBS
file) will be required. Individual messages or ranges of messages
can be "set" so that they are not scanned. Type SCANSET ? for
details.
-4-
SCANCLR.EXE
In the event that you wish to scan old mail for a new node, this
utility makes it possible to cause FLAME to re-export mail that was
already scanned by FLAME. Exercise care in the use of this command
to avoid exporting duplicate messages into your network.
Individual messages or ranges of messages can be "cleared" so
that they are scanned. Type SCANCLR ? for details. SCANSET and
SCANCLR operate on MSGHDR.BBS, offset 74h, bit 1. Note that this
bit is not changed if a message is moved between message boards,
so moving or forwarding a message within TBBS will not cause FLAME
to rescan and export the message.
FLAMEDIT.EXE
This file is used primarily to turn your human-readable ASCII
configuration files into the binary files that FLAME uses in order to
understand your configuration requests. This includes any of the
following should they be found in your TBBSPATH or the current
working directory:
TIMS.CTL, files INCLUDEd by TIMS.CTL, AREAS.BBS, FLAME.CFG,
files INCLUDEd by FLAME.CFG, and AREAFIX.CTL.
FLAMEDIT may be called manually, but will also be called
automatically by FLAME should it discover that a new FLAME.CFG file
has been created such that the DOS date/time stamp on this
human-readable file is newer than that of the previously compiled
binary version of these files (FLAME.PRM).
Remember, FLAME works from compiled binary files, not from the
configuration files you can easily create and read with your
favorite word processor. FLAME compiles your files into its own
format as required.
--------------------------------------------------------------------------
Configuration Files
--------------------------------------------------------------------------
FLAME uses several configuration files if found:
A) TIMS.CTL
FLAME will use any information that it can locate within your
TIMS.CTL file that is relevant to FLAME operation. Should
conflicting information be found in subsequently parsed files
(specifically, the FLAME.CFG file or files INCLUDEd in the
FLAME.CFG file), that subsequent information will either be
added to that already found, or will replace what has been
found in the TIMS configuration. Which action is taken depends
on the specific configuration verb that is found in multiple
files. As a general rule, if it is possible for any FLAME
configuration to have multiple values, they will be added. If,
on the other hand, it is only possible to supply FLAME with a
single value (for example, your primary node address), then
replacement will occur, and the FLAME.CFG information will take
precedence over information found in TIMS.CTL.
-5-
B) AREAS.BBS
As mentioned before, you will find it necessary to manually
convert your existing AREAS file(s) to the format required by
FLAME. In addition, new command options are available to
modify the operation of FLAME and these may be added to this
file. This human-readable file (or several files) is converted
into a binary file that FLAME can use. This binary file is by
default called AREAS.DAT. Several such human-readable ASCII
files can be created for conversion by FLAME. Often, one is
created for each network in which you operate.
Note that many new features have been added to the AREAS.BBS
files that FLAME uses that will help you to better control your
mail processing.
C) FLAME.CFG
This file contains the vast majority of your configuration for the
FLAME utility. As noted earlier, it is the last file to be
inspected for configuration data, and data found here that is
different from similar data in the TIMS.CTL file may override or
augment the TIMS.CTL data.
Note that as delivered in the sample files in the FLAME package,
FLAME.CFG is broken up into SAMPLE.CFG and ADVANCED.CFG. After
the functions of these two pieces are explained, you may decide
whether or not you should in fact combine these files into a
single FLAME.CFG file for your convenience, or whether none of the
advanced features need to be changed from their defaults.
This human-readable file is by default converted into the binary
file FLAME.PRM for use by FLAME.
D) ROUTE.CFG
In conjunction with FLAME.CFG, this file works with information
you provide about the systems for whom you wish to create archived
or simple packet mail files, defines any routing of mail destined
for one system through another, and determines the "flavor" of the
mail that is created.
One commonly made mistake is to assume that the list of the
archive method(s) you wish to use for a node or nodes as
defined in FLAME.CFG is sufficient to cause archives to be
built. This it not the case. Without the instructions of
ROUTE.CFG, no archives will be built, regardless of the content
of FLAME.CFG.
This file is not compiled into FLAME.PRM along with the data found
in TIMS.CTL and FLAME.CFG. The ROUTE.CFG information is instead
read by FLAME when it FLAME run (as is the AREAS.DAT file).
-6-
E) AREAFIX.CTL
In the event that you were already running AREAFIX at version
1.30, the contents of this file will be useful to FLAME for
AREAFIX functions, and will be read by FLAME. The FLAME.CFG
statements regarding AREAFIX functions are very similar to
those documented in the FLAME.CFG file. However, the normal
"default keys" from AREAFIX are *not* able to be used with FLAME.
It is probably better to extract the relevant portions of any
existing AREAFIX.CTL file and place it within your FLAME.CFG.
As is the case with TIMS.CTL, various portions of the FLAME.CFG file
may instead be "INCLUDE"d, and the files that you INCLUDE may be of
any name you wish so long as they do not conflict with any of the
standard filenames used by any of the eSoft utilities.
--------------------------------------------------------------------------
Doing it right with <Z>ones:
--------------------------------------------------------------------------
Please note that one of the most confusing aspects of setting up this or
any other similar package can be correctly identifying the parameters
that need to be properly adjusted for multiple zone / multiple network
operation. If you will search each of the configuration files looking
for the three character string "<Z>" you will discover those items of
particular importance to this mode of operation.
==========================================================================
==========================================================================
--------------------------------------------------------------------------
Getting Mail and Files to the Right Places
--------------------------------------------------------------------------
Before installing FLAME (or TIMS, for that matter), you should become
familiar with the way this software creates and manipulates outbound
mail. Without this information, debugging your installation may be very
difficult.
The industry is divided in its approach to the problem of outbound mail
handling, and usually uses one of two very different methods. The File
Attach Message described earlier in the FidoNet technology primer causes
the file named in the subject field of the message header to be sent to
the system found in the destination field of the message header. This
is the technique that the old eSoft mail utilities expected, and that
Front Door and the SEAdog mailer (sold by eSoft before TIMS was written)
require. TIMS will also handle such messages if found in the "Mail"
directory defined in the TIMS.CTL file, as will FLAME. This may be
important if you are using any 3rd party utilities that create such
messages. The second method uses files that are themselves lists of
files, and is the "native" method for such products as Binkley, TIMS and
FLAME.
-7-
--------------------------------------------------------------------------
The File Attach Method
This first method was a bit messy because SEA, eSoft and other vendors
were unwilling to include necessary zone information in their message
and packet headers at that time. As a result, there was often ambiguity
as to which zone the file was destined, making multi-zone operation
difficult.
This File Attach Message method was the first of the FidoNet
technologies to perform the function. In many cases, the message itself
had no content or "body" - just the message header indicating the
origin, destination and file to be sent, although files could be
attached to messages with normal content as well.
In the case of a mail archive, it was critical that the mail archive
file be deleted once successfully sent else the same mail be delivered
over and over to the destination system. TIMS only knows to delete such
"File Attached" files because the ARCMAIL statement in the TIMS.CTL file
can be used to point to a directory containing archive files that must
be deleted after they are sent. In fact, TIMS required no attach
message at all under such circumstances, and used the filename to
determine the net and node number of destination address (this was also
true for SEAdog for versions starting at 4.5). Using the old eSoft
NetMail utilities, the third party program one selected to pack and
archive mail determined whether or not a File Attach Message was
created. Programs such as ARCmail (from whence the name of the
statement in TIMS.CTL got its name) used this method for creating
outbound archives. Some versions of ARCmail created file attach
messages and others did not, but all depended upon the mailer to delete
the file once successfully sent.
--------------------------------------------------------------------------
Another Method
TIMS and FLAME were designed to handle file attach messages if
necessary, but their "native" mode of operation uses the *.OUT and *.FLO
file methods of keeping track of outbound mail packets and files.
The TIMS.CTL (and FLAME.CFG) "Outbound" statements control the location
of outbound packets and file lists, and one directory is created for
each zone for which you ever have outbound mail, avoiding any ambiguity
about the destination zone number. Several kinds of files can be found
in these directories, and each will be described momentarily.
-8-
--------------------------------------------------------------------------
Beware the ARCMAIL Statement!
This second method for controlling outbound mail brings us to a very
SPECIAL note about FLAME configuration. You should begin by removing
ANY "ARCMAIL" statement in your TIMS.CTL file, *especially* if it points
to the same directory as does your "OUTBOUND" statement. The
undesirable interaction between these two features can cause some
unfortunate effects, including having TIMS ignore the flavor of all of
your mail, treating it all as "Normal", and having FLAME create archives
with the same file extension during the course of a day. This is
because TIMS will *first* deal with mail archives in the "old way" if it
sees them in a directory pointed to by an ARCMAIL statement in TIMS.CTL,
even if an OUTBOUND statement points to the same directory and would
otherwise indicate the "new" way of handling outbound mail.
--------------------------------------------------------------------------
The *.OUT / *.FLO Method
Two outbound file types can be found in the "Outbound" directories. By
now, you are familar with packets, and know that when they are stored in
archives, always end with a *.PKT extension, and their names are some
magic sequential number derived from the milliseconds since Christmas or
other equally unusual means. Each mail packer uses a different
algorithm for creating these sequential names. You should also remember
that packets are the most basic form of message transfer between two
mailers. When not archived, however, these packets are named using the
net and node number of the destination system, and the file extension
identifies the "flavor" of each packet. *.OUT is a "normal flavor"
packet. *.CUT indicates a "crash flavor" packet, and *.HUT identifies a
"hold flavor" packet. In addition to these more common extensions,
FLAME also makes use of the *.DUT "direct flavor" packet extension.
Note that while these packets are being manipulated by FLAME, they are
temporarily named as *.O$T, *.C$T, *.H$T and $.D$T. This prevents TIMS
or any other program from recognizing them as packet files while they
are still being created or appended to by FLAME. Once FLAME is finished
fiddling with the packet, the middle character of the filename extension
is replaced with a "U", and can be "discovered" by other software.
What each of these four possible flavors causes TIMS to do is completely
dependent upon how you configure your TIMS.CTL file. Unlike other
mailers, TIMS has no preconceived ideas about what to do with "crash"
mail as compared to "normal" mail, although it does recognize "hold" and
refuses to dial a system to send mail flavored "hold". Your TIMS.CTL
file must be configured with RESTRICT blocks to determine the days,
times and modems that will be used to send "normal" v.s. "crash" flavor
mail. "Direct" flavored mail is treated the same as "normal" by TIMS.
Each of the *.?UT packet names begin with eight hexidecimal digits. The
first four represent the net number of the destination node, and the
second four represent the node number of that system. The zone number
of the destination system is implied by the directory in which the
packet resides. If it sits in OUTBOUND.003, then it is assumed that the
packet is destined for a Zone 3 system.
-9-
In addition to packets of messages, files must also be handled
differently.
Rather than using File Attach Messages to send files to other nodes,
FLAME and TIMS prefer to use Outbound File Lists. Like packets, these
have their own "flavors", and the effect of those flavors upon the
operation of TIMS is the same as for packets, and is largely up to you
to determine in your TIMS.CTL file configuration.
*.FLO, *.CLO, *.HLO and *.DLO are the file extensions for "normal",
"crash", "hold" and "direct" Outbound File Lists. The first eight
characters of the filename are formed just as they are for packets,
indicating the net and node of the intended destination, and the zone
information is again implied from the directory in which the File List
resides.
Each of these Outbound File List files contains nothing more than a line
by line list of files (and paths, if not the same as the outbound
directory where the File List resides), and if appropriate, a character
at the start of each line explaining to the mailer program what is to be
done with the file once it has been successfully sent to its
destination. Options for these characters include
nothing : do nothing with the file after sending
# : truncate the file to zero byte length after sending
^ : delete file after sending
For example, a mail archive whose name is 0000FFFF.FR1 and needs to be
sent to system 104/115 would cause the file 00680073.?LO to be created.
In addition, let us assume that a nodediff file needs to be sent as
well. The File List file might contain a line as follows:
#0000FFFF.FR1 (truncate after sending)
C:\TBBS\DIFFS\NODEDIFF.A71 (don't touch after sending)
Note that if another utility is used that creates a *.MSG File Attach
Message, FLAME will process this by placing the File Attach Message into
a packet for the destination node, and will create (or append to) an
Outbound File List for that node the name of the file that needs to be
sent.
When TIMS makes contact with a node for whom packets or File Lists
exist, and successfully sends them, any file list and sent packets are
deleted, and the files in the Outbound File List for that node are each
treated according to any special prefix character. In the case of mail
archives, FLAME instructs TIMS to retain the filename in the outbound
directory, but to remove its contents and leave it as a 0 byte file
(truncation). This is due to the "#" that FLAME places in front of the
filename in the File List file. When FLAME is later run to create new
outbound mail, it sees these 0 byte files as reminders of the last
archive filename that it created for each node, and bumps the last digit
of the next archive filename if another is to be created on the same
day. Having done so, FLAME then deletes the 0 byte file. This allows
FLAME to try to create different names for each archive for any one node
during the course of a day. Since some mailers will allow a newly
received archive to overwrite an older, unprocessed one of the same name
(still a bad habit with TIMS as of the time of writing, by the way),
this is a very valuable feature. -10-
Packets and File Lists should never be modified while a mail session is
taking place with the node to whom these files belong. This is critical
in a "nanny machine" environment where FLAME is processing mail on a
machine separate from the BBS and is sharing outbound directories with
TIMS. As you can imagine, FLAME mustn't be changing things while TIMS
is trying to transmit them.
To cope with this contention over files, when TIMS begins a session, it
creates a *.BSY (busy) flag file in the outbound directory, using the
net and node number of the destination system to form the eight hex
digits of the root of the filename (same as for packets and File Lists).
When FLAME sees such a *.BSY file, it will avoid any attempt to add to
or create packets or File List files for the "busy" node. In turn,
FLAME creates *.BSY files as well to let TIMS know to avoid attempting a
session with the node belonging to the *.BSY flag. Remember that FLAME
also uses the $ replacement (*.O$T for *.OUT, for example) in packets to
make sure that TIMS or another mail processing utility (or a copy of
TIMS running on the BBS machine) doesn't take an interest in them.
TIMS is supposed to delete its own *.BSY flags when the mail session
with the "busy" node is ended, but should you take a power hit in mid
transfer, TIMS is obliged to clean up (delete) ALL *.BSY files when it
is reloaded on power-up.
Note that any malfunction that causes *.BSY files to be left by accident
is not only likely to keep FLAME from creating new outbound mail for
TIMS to send, but will keep TIMS from sending it as well. If such
unusual situations seem to be occuring on your system, look for *.BSY
flag files in your outbound directory(ies) that cannot be explained due
to current FLAME activity or an active session with the node to whom the
*.BSY files belong. Delete them manually if necessary.
==========================================================================
==========================================================================
--------------------------------------------------------------------------
Command Line Options
--------------------------------------------------------------------------
FLAME has many options that you may find useful, but will miss unless
you carefully review the FLAME help (by typing FLAME topic ?) and the
information for each topic shown. Here are a few of the more
interesting or important features of the FLAME command line.
--------------------------------------------------------------------------
First, as explained in the FLAME.CFG file, many features depend upon
either the presence of the TBBS statement in that file, or on the FLAME
command line. Without the TBBS statement, no messages will be scanned
or tossed from/to the TBBS message base.
-11-
--------------------------------------------------------------------------
As shown in the ROUTE.CFG file, there are a variety of options that you
can invoke from the command line that are also possible from within
ROUTE.CFG or TIMS.CTL. Which of the three methods you use to force a
POLL, for example, depends entirely upon your own situation. You can
force a POLL from the FLAME command line during the execution of a batch
file, or perform it within a Schedule from within the ROUTE.CFG file, or
within your TIMS.CTL file as a DOTBBS POLL statement, or as from a TBBS
event or even as a menu item as a call to TIMS.
To keep things simple, it is probably best to consolidate such things
into just one of these areas where possible. For example, you may wish
to do a weekly GET of a NODEDIFF.* file, poll your hub daily, etc., all
from within RESTRICT blocks of TIMS.CTL. Scattering similar commands
around within ROUTE.CFG or the FLAME command line can make it
unnecessarily difficult for you to keep track of what you've done.
However, such commands as FLAME ATTACH can be more conveniently handled
during batch file execution where you can test for the presence of a
file with the DOS "IF EXIST" feature of batch language programming.
The duplication these functions by FLAME is in part due to the fact that
it began life as another program that was able to provide such functions
for mailers other than TIMS that didn't offer these features themselves.
--------------------------------------------------------------------------
The most simple possible use of the FLAME command line is simply 'FLAME'
itself with no parameters. This causes FLAME to perform the whole gamut
of functions, including TOSSing mail to your message base, SCANning new
mail from your message base, PACKing mail for delivery to other nodes,
including archiving and routing that mail if you like, LINKing of your
message areas into message threads, and AREAFIX functions.
In order to accomplish this, FLAME will require a great deal of
conventional memory. You may discover that the last process to be
executed, LINKing, cannot be accomplished with available memory. If
your installation causes FLAME to report that you have inadequate memory
during LINK, one option is to use
FLAME
FLAME LINK ALL
This causes FLAME to perform a separate LINK step and gives FLAME much
more memory in which to accomplish this task.
Which message areas are to be linked depends upon several factors.
You can specify NOLINK in your AREAS file(s) for individual message
areas. When executing FLAME LINK or FLAME LINK ALL, those areas are
ignored for linking purposes. You can also specify a file that contains
the areas you wish to link using the -f switch
FLAME LINK -flinklist.txt
-12-
The file should contain a list of the echo areas you wish to link. Note
that if you have specified NOLINK in your AREAS file(s), some of your
link requests may be ignored. This is also true when using the form
FLAME LINK areaname
--------------------------------------------------------------------------
Note that if you wish FLAME to mark your old messages for deletion, the
ROLLOFF command must be specifically spelled out on a FLAME command
line. Is it not a default function of FLAME at any time. Age and count
for such marking is handled in your AREAS.BBS file(s). See AREASAMP.BBS
for details.
--------------------------------------------------------------------------
In addition to being available from a command line call, FLAME's SEND,
ROUTE, CHANGE, POLL, LEAVE, UNLEAVE, ATTACH, GET, UPDATE, HOSTROUTE,
NETMAIL_SCAN and TBBS_IMPORT_FILE commands may also be executed during
schedules as set up in your ROUTE.CFG file.
Each of these commands is documented in the ROUTE.CFG example file.
Note that the availability of certain DOS batch file commands may well
make it easier for you to use these options in batch files as opposed to
a ROUTE.CFG schedule. For example, here is a simple replacement for a
TICK function. As each week's nodediff appears, it is stored in the
directory called c:\nodediff for future reference and is sent to two
different nodes using FLAME ATTACH. The original is then deleted from
the inbound file area so that this process is not repeated unless a new
copy of a file called "nodediff.*" arrives. Assuming you have created a
separate inbound files area called c:\inbound\files for files received
under session password, and assuming the nodes you wish to send the
files to have done the same, the session password replaces the need for
other security measures:
:Movefile
IF EXIST c:\inbound\files\nodediff.* GOTO Diffsend
.
.
:Diffsend
CD \inbound\files
COPY nodediff.* c:\nodediff
FOR %%F in nodediff.* FLAME ATTACH DIRECT c:\nodediff\%%F 104/118 104/131
DEL nodediff.*
CD \whereveryouwere
-13-
Similar things can be done to create messages from newly received files.
Note that the one command line is so long that we have broken it in half
for display here, but that it must be on a single line to keep DOS
happy. This example sends the contents of the file called SOMEFILE to
another sysop using NetMail, and to the sysop of the present BBS. The
file is then deleted so as not to repeat the same process each time the
batch file is run unless a new copy of SOMEFILE has arrived.
:Makemsg
IF EXIST c:\inbound\files\somefile GOTO Msgsend
.
.
:Msgsend
CD \inbound\files
FLAME TBBS_IMPORT_FILE somefile "NET MAIL" FROM="Chris Anderson"
TO="Bob Hartman" NODE=1:104/501
FLAME TBBS_IMPORT_FILE somefile "MSG TO SYSOP" TO="Chris Anderson"
DEL somefile
CD \whereveryouwere
==========================================================================
==========================================================================
--------------------------------------------------------------------------
FLAMEDIT Options
--------------------------------------------------------------------------
For the most part, you will probably execute FLAMEDIT without any command
line options. However, please note the /C:<filename> option may be very
important in certain environments. As you have read in the information
above, FLAME will attempt to read your TIMS.CTL file for relevant
commands if it can find this file.
There are times when you may wish to have *only* the information from
your FLAME.CFG file used to configure FLAME. One example of this might
be when running FLAME on the BBS machine while a "nanny" machine is also
running. Not only might you wish to have separate copies of FLAME.CFG
(as opposed to statements to the contrary in the FLAME docs), but you
may also wish to avoid having your TIMS.CTL file compiled into your
FLAME.PRM file. Why? To "hide" your inbound area from the BBS FLAME.
If you are a mail hub, and since you most likely don't wish to have the
copy of FLAME that handles mail on the BBS machine start trying to
unpack and forward copies of all of the echomail to everyone for whom
you hub, you need to make the TIMS inbound FILES area invisible to that
copy of FLAME. Only the "nanny" machine should see the TIMS inbound
files area. You will likely wish to have the BBS machine looking ONLY
in the subdirectory where the "nanny" machine has placed packets for the
BBS machine to toss to its own message base. Since TIMS *must* know
where the inbound files area is, it is clear that the TIMS.CTL file must
not be compiled into the BBS copy of FLAME.PRM. As a result, you would
need to specify
FLAMEDIT COMPILE /C:FLAME.CFG
==========================================================================
==========================================================================
--------------------------------------------------------------------------
The "Alternate" (aka "PC-Board") Style Storage Method
--------------------------------------------------------------------------
A major source of confusion has been the undocumented "alternate" or
"PC-Board" style message areas. This concept was first introduced to eSoft
software with QSO (the eSoft QWK option module), but was inadequately
documented. The pro's and con's of using this method of message storage
are clearly outlined in the AREASAMP.BBS file on this disk. Please read
this information for additional insights.
MSG.BBS + MSGHDR.BBS = TBBS message base
Messages that are to be read by users logged onto your BBS must be stored
in the MSG.BBS (message body) and MSGHDR.BBS (to, from, subject, board
number, index, etc.) files. In addition, the QSO module can retrieve and
store messages within the TBBS message base using these two files.
Messages stored by this method are *not* accessible to users logged onto
the BBS, but QSO can retrieve and store messages from such alternate
storage areas.
Such messages cannot be created directly by FLAME. Utilities such as
FIDO2PCB and the like are often used to take packets and drive them to
the message and index files in the PCBoard format.
Generally speaking, the ONLY REASON to put yourself through the additional
brain damage (and wasted disk space, as explained in AREASAMP.BBS) of this
storage method is because you are unable to live with the 65,534 limit on
the message count in the TBBS 2.2 message base, and you have QSO users who
wish to have access to a greater number of messages.
Typical installations will use a single directory for all echo
subdirectories, and might look like this:
C:\QSOECHOS\AARDVARK - "aardvark" echo
C:\QSOECHOS\ABLED - "abled" echo
C:\QSOECHOS\ADVENTUR - "adventure_games" echo
C:\QSOECHOS\ASK_ED - "ask_ed" echo
C:\QSOECHOS\AVIATION - "aviation" echo
Note that although echo tags are being used by FLAME to create the names
for subdirectories, the root portion of all DOS names are limited to eight
characters. As a result, echo tag names must often be truncated in order
to fit within eight characters. FLAME will be sure to create unique names
in the event that two echos start with the same eight characters.
--------------------------------------------------------------------------
In the event that you are acting as a mail hub for other points or
nodes, you must *not* toss mail to the TBBS message base with TIMS
before running FLAME on the inbound mail. Once TIMS has tossed such
mail to the BBS (using the DOTBBS TOSS command), FLAME will not "see"
that mail, and will not export copies to your downstream nodes.
If you are a mail hub, you should therefore avoid receiving and tossing
unarchived packet echomail with TIMS. If you wish to use on-line
tossing to minimize down time on the BBS, let FLAME prepare the packets
for TIMS to toss while the BBS is on-line.
==========================================================================
==========================================================================
--------------------------------------------------------------------------
Additional TIMS and FLAME Tips
--------------------------------------------------------------------------
I'll be adding a few tips here from time to time that were not included
in the book "Tips, Traps and Techniques for TBBS".
--------------------------------------------------------------------------
You can eliminate the "waiting seconds" for any node you see when viewing
the outbound activity from the scheduler work list of the TIMS control
panel by simply forcing the "<D>ialable" for that node. However, if you
get yet another busy, the waiting seconds count appears again, and you must
again force the <D>ialable to get rid of them again.
--------------------------------------------------------------------------
It's possible to get TIMS running under a new configuration without fully
bringing the system down and up again. Edit the file(s) you need (e.g.,
the TIMS.CTL file), and hit the F3 key, and quickly hit it again before
TBBS itself actually goes down. The TIMS Scheduler will go down, and then
will come back up. When it does so, it re-reads the TIMS.CTL and other
file(s), causing the new configuration to take effect.
--------------------------------------------------------------------------
When you see "No SENDs Available" in the TIMS Scheduler Work List, this
means that the SEND commands currently active in your TIMS.CTL file (most
likely within a RESTRICT block) do not include the node in question. This
could be for any number of reasons (including an intentional condition),
but is always tracable to that cause.
--------------------------------------------------------------------------
There are several flags that are displayed in the TIMS Scheduler Work List
menu under "Work Type". These include
C = Crash H = Hold
N = Normal A = Attach R = Request