Keeping in Touch
November 1992
SPITFIRE Monthly Support Newsletter for registered SPITFIRE Sysops
Compliments of Buffalo Creek Software
In this issue
- SPITFIRE'S EVOLUTION TO VERSION 3.3
- THE IRONCLAD BBS
- SYSOP-OF-THE-MONTH
- NEWLY REGISTERED SPITFIRE SYSTEMS
Archival transcript
The text below is a faithful Unicode rendering of the original SF11-92.TXT. Its DOS line wrapping, spacing, capitalization, spelling and CP437 box art have been retained.
╔════════════════════════════════════════════╗
║ ╟─┐
║ K E E P I N G I N T O U C H ║ │
║ ═══════════════════════════════ ║ │
║ SPITFIRE Monthly Support Newsletter ║ │
║ for registered SPITFIRE Sysops! ║ │
║ November 1992 ║ │
║ Compliments of BUFFALO CREEK SOFTWARE ║ │
║ Buffalo Creek's BBS * 515-225-8496 ║ │
║ 38400/19200/9600/2400/1200 Baud ║ │
║ 2 Nodes ║ │
║ ║ │
╚═╤══════════════════════════════════════════╝ │
└────────────────────────────────────────────┘
Edited by Jacque Shipley
The Mother Board BBS - (515) 986-3464 - 19200 Baud
Sysop Of The Month by Walt Crede
Roam This Fertile Land - (515) 288-8755 - 2400 Baud
Newly Registered SPITFIRE BBS List by Ann Woltz
Other Contributions As Noted
╔═════════════════════════════════════════╗
║ Notes from the author of SPITFIRE! ╟─┐
╚═╤═══════════════════════════════════════╝ │
└─────────────────────────────────────────┘
BCSUTI and TNET
---------------
There are a number of SPITFIRE Sysops who are using BCSUTI in
conjunction with a program named TNET (TNET.ZIP on my board) for
the purpose of importing/exporting QWK mail packets into the
SPITFIRE message base. This provides a means of exchanging
messages with boards utilizing BBS software other than SPITFIRE.
I am told that this process works fairly well, however, there
seems to be a common mistake being made when making the setup.
As I understand it, TNET allows the configuration of the UTI
revision which is to be used. Additionally, I understand that
the TNET documentation leads the reader to believe that this
should be configured as revision 1. WRONG! BCSUTI is a
revision 2 UTI. In the event you configure TNET for revision 1
usage, then you will find that the messages exported will have
additional lines and messages imported will be missing message
lines. BE SURE TO CONFIGURE TNET TO UTILIZE UTI REVISION 2.
Thank you!
BCSUTI Configuration
--------------------
I am advised that there is a normal product discussion of
BCSUTI in the RIME SPITFIRE support conference. (I pray that
participants will someday learn how much damage is done to a
person's reputation and a product's reputation by this 'normal
product discussion'. God grant me the serenity to accept the
things I cannot change.)
I am a bit reluctant to discuss this matter since the
information which I have is 2nd and 3rd hand. However, I am
hopefully that I will be able to provide some information which
may alleviate this 'normal product discussion'. For whatever
reason, it appears that there are those who believe that after
adding a Message Conference(s) in SPITFIRE they then must use
BCSUTI to add the new Message Conference(s) to the BCSUTI
configuration. This is correct, however, as I understand it,
this is being done improperly (user error rather than product
error - I wonder why that is not discussed on mail systems).
First, I understand that the Sysop believes the BCSUTI.CFG file
must be erased. I have no idea where in the world this idea
could have EVER come from but it is NOT true. BCSUTI.CFG DOES
NOT NEED TO BE ERASED!!!! Second, I understand that the Sysop
(after BCSUTI is finally booted) then properly selects "Add/Edit
Conf" but then INCORRECTLY selects "Add <A>ll" rather than
CORRECTLY selecting "Add <O>ne". When "Add <A>ll" is selected,
then BCSUTI changes ALL "Short Name Descriptions" to the default
descriptions. I suspect the user incorrectly thinks that "Add
<A>ll" only adds the conferences then not configured. I just
reviewed BCSUTI.DOC and this information is clearly set forth in
the documentation.
We're Still Cleaning Things Up!
-------------------------------
The response to our request for help with cleaning up our
registered SPITFIRE board list has been GREAT and we appreciate
it. There have been a tremendous amount of SPITFIRE Sysops who
have replied to our request for help. We really appreciate all
the information which was furnished.
We recently mailed a final SPITFIRE v3.2 upgrade notice to
eligible SPITFIRE Sysops who have not yet upgraded. They were
given notice that if they did not reply by November 15, 1992,
that we would consider them as inactive and which makes them
ineligible to participate in our SPITFIRE FREE upgrade policy.
Quite a number has upgraded due to such notice. Those who did
not reply will be removed from our various lists and will be
marked as inactive in our database.
SPITFIRE FREE Upgrade Policy
----------------------------
As most of you are aware, SPITFIRE v3.3 is being developed.
This means that we will be mailing the SPITFIRE v3.3 notice and
'upgrade request form'. We want to continue to provide a means
of upgrading at no cost to the Sysop. This is important to us.
We have always been proud of our FREE upgrade policy while other
firms charge more for upgrades than SPITFIRE's original
registration fee. Contrary to what some would have you believe,
one of the main goals of Buffalo Creek Software is to treat
everyone as fairly and honestly as we can.
However, there are problems that we have to deal with. The
problems are with the FREE upgrade download option. First, many
Sysops return their upgrade request form and indicate that they
want to utilize the download option. Their copy of SPITFIRE is
then compiled and made available for download. The problem is
that the Sysop sometimes doesn't make the download for up to 3
to 4 months or some never call to make the download. Believe
me, those Sysops are ruining a good thing that the rest of you
enjoy. Another problem is the download itself. Some Sysops
select YModem-g (the most unreliable protocol to date) to
download their copy. Then when the download fails, we have to
compile the copy again. Still another problem with the download
option is many Sysops apparently do not retain a copy of their
of the software on diskette. I think you would be amazed at
the amount of Sysops who ask for a new copy of SPITFIRE because
they had a disk crash. This would never be necessary if they
would only place a backup copy on diskette. When SPITFIRE v3.2
was released we announced that there would be a $20.00 fee
charge (which has not been enforced) for anyone asking for a 2nd
copy due to a disk crash. This announcement was made in an
effort to 'scare' Sysops into making a backup copy. It didn't
work. We still get (weekly) requests for another copy of
SPITFIRE because of a disk crash (there are other reasons as
well).
All the problems associated with the download option do not
belong to SPITFIRE Sysops. There is also a problem at our end.
We will need to add additional nodes so the SPITFIRE Sysop can
get logged on to make the download. The only problem that we
have with adding additional nodes it the message base. I
continue to reply to 35-40 messages a day (believe me, that
takes me 3-4 hours a day). If we add more nodes, then there
will be more messages. It is humanly impossible for me to
answer more messages each day. In fact, I believe that I am
telling you the truth if I say that SPITFIRE v3.3 would be
already released if I didn't have to answer messages. When I
first started work on SPITFIRE v3.3 I asked (in this newsletter)
for your cooperation in not asking to beta test, in not asking
when the software was finished and in not asking for trivia
additions to SPITFIRE. I should have saved my breath since it
didn't work.
So, as you can see, there are many problems with the download
option of our FREE upgrade policy. We absolutely do not want to
discontinue the download option but it is starting to appear to
be inevitable.
HAPPY THANKSGIVING
------------------
We will soon celebrate Thanksgiving. There is no doubt in my
mind that we all have many, many things to be thankful for. We
seem to live in a world full of hate, destruction and violence.
Let's (as SPITFIRE Sysops) pledge to do our part in making our
world a much better place to live.
Thank you for your continued support and promotion of
SPITFIRE. The SPITFIRE project continues to grow at a very nice
pace. None of this would be possible without the help of many
GREAT SPITFIRE Sysops. It hasn't changed - for the most part,
SPITFIRE Sysops are top shelf folks. Thanks.
Until next time, may God bless you...
Mike, Ann & family
╒═════════════════════════════════════╕
│ SPITFIRE'S EVOLUTION TO VERSION 3.3 │
╘═════════════════════════════════════╛
Many of you may be following the changes in SPITFIRE by reviewing
updates to the WHATSNEW.33 file. However, I thought it might be
appropriate to provide a brief description of some of the new
features you can expect to see when SPITFIRE Version 3.3 is available.
Before you start asking, no release date for V3.3 has been announced
but, as always, it will be well worth the wait.
Main Menu Enhancements
----------------------
Significant changes have been made to the questionnaire files in
SPITFIRE. SPITFIRE can now handle 24 questionnaire files. Previous
versions only allowed 9. The questionnaire files have been renamed.
They are now called SFORDER<x>.QUE and SFORDER<x>.REP. <x> represents
an alpha character from A to Z with the exception of G and Q which
are reserved for Goodbye and Quit.
Examples would be:
SFORDERA.QUE SFORDERA.REP
SFORDERB.QUE SFORDERB.REP
SFORDERC.QUE SFORDERC.REP
SFNEWU.QUE SFNEWU.REP
and so on... As before, the QUE represents the questionnaire file and
the REP is the file where the replies to the questions are stored.
The format of SFORDER.MNU has been modified as well. SFORDER.MNU now
uses the following format:
<Title of the Questionnaire>,SEC>=x,ONETIME,PRINT
The title of the questionnaire can be up to 25 characters and should
appear first on the SFORDER.MNU line. The questionnaire title should
be followed by a comma. This is followed by the security required to
access the questionnaire. The security is defined by SEC<=x or SEC>=x
or SEC=x where x represents a numerical value that should coincide
with the framework of security levels applicable on your BBS. (Any
caller with Sysop security may access a questionnaire regardless of
how SEC is defined.) The ONETIME variable is optional and used to
limit responses to the questionnaire to one time. If ONETIME does
not appear, the questionnaire can be answered multiple times. The
PRINT variable is also optional and if present sends the caller's
questionnaire responses to the printer. If PRINT is not included
on the line, no attempt is made to send the questionnaire answers
to the printer.
An example of the SFORDER.MNU Questionnaire might look like this:
SPITFIRE Orders,SEC>=10,ONETIME
Callers with a security of 10 or greater could respond to the
questionnaire SPITFIRE Orders one time only. Their responses would
not be sent to the printer.
Corresponding to this change, when opting to View Log Files either
from the "Ready..." prompt or from the Sysop Menu, you now have the
option of reading replies to the questionnaire files. The View Log
Files has an option <O>...SFORDER<x>.REP. When this option is selected
SPITFIRE will prompt for the letter to the corresponding questionnaire
file [A..Z]. Next, you are prompted whether to begin reading the file
at Today's Date, Beginning of the File, Specify A Date or Quit. If the
corresponding log file is not found, SPITFIRE will report this and return
to the "Ready..." prompt or to the Sysop Menu.
Message Menu Enhancements
-------------------------
A new option has been added to the Message Conference Record. You
can now toggle a message conference as Read Only. This is done by
pressing the asterisk key "*" which toggles the Read Only option from
Yes to No. If toggled to No, callers can read and enter messages. If
toggled to Yes, messages may be read but no messages can be entered
in this conference.
SPITFIRE's message option to copy a message never included the option
to mark the message as a netmail message when being copied to a netmail
conference area. This has been added. Now if a message is copied
to a conference which has been configured as a netmail conference,
the caller is prompted the same as if the message was being entered
directly into the netmail conference (i.e., whether the message should
be marked as a netmail message and if so, whether the message should
be purged when sent).
SPITFIRE has been changed in regard to the 'Purge message after it
is sent? [y/N] ' question when a message is marked to be sent out on
a mail network. Previously, SPITFIRE asked this question each time
a message was marked to be sent. Now, SPITFIRE will not ask this
question if 'Caller Message Deletion' is not allowed in the Message
Conference. As usual, this does NOT apply to callers with Sysop
Security.
The SPITFIRE Door option has been removed from the Message Menu. It
has been replaced with SPITFIRE Mail System. This option will allow
the caller to extract messages for download and to upload replies. This
feature uses the .QWK mail format. As is customary with Buffalo Creek
Software this feature does not provide a lot of bells and whistles options.
If you do not wish to make this option available to your callers, simply
set the security to access this option high enough so it is not available.
When a caller selects the SPITFIRE Mail System, SPITFIRE will shell to
LAKOTA.COM. LAKOTA.COM must reside in your SPITFIRE home directory. It
is written in assembler and will handle your .QWK mail transfers. The
mail packet, generated when downloading with this option, should work with
any .QWK mail reader.
SPITFIRE's internal message packing routines have been modified. The
Turbo Pascal code that was used to pack the message base has been
removed from SPITFIRE. SPITFIRE now shells to SFPCKMSG.COM when packing
the message base, either as Event M or from the Sysop menu. SFPCKMSG.COM
must reside in the SPITFIRE home directory!
In relation with this change, the option Backup Files has been removed
when configuring SPITFIRE's Message Conference Records. It has been
replaced with Purge Unreceived Messages. If this is set to Yes, when
packing the message base any messages older than that configured via the
Purge Msgs Older Than option will be purged even if they have not yet
been received. If set to No, unreceived messages will not be purged.
Similarly, the <M>...Erase SFMSG*.$?? has been removed from the
File Removal Menu since it is no longer needed. SFPCKMSG does not
make backups of the message conference files.
A new feature has been added to the Message Conference Records. This is
"Allow Message Routing y/N?". This feature is only applicable to message
conferences that have been configured as netmail conferences. When
entering a message in a netmail conference, you are prompted as to
whether to send the message via netmail, whether it should be purged
when sent and now asked "Would you like to route this message? y/N" The
default is No. If you respond with a Y, you are next prompted to enter
the routing number or name. If you are using BCSUTI ßv1.0, revision 2.8 or
greater, the message will automatically be routed for you. If you are
using Bob Browne's UTI or earlier version of the BCSUTI you will need to
route your messages in the normal fashion.
The Routing feature will also work with carbon copy messages making it
possible to send the same message to 10 different people, routing it to
10 different locations.
SPITFIRE's netmail tagline has been shortened.
File Menu Enhancements
----------------------
The option to select SPITFIRE Doors from the File Menu has been removed.
It has been replaced with a new option, Shuffle Files. BE SURE TO SET
THE SECURITY FEATURE OF THIS OPTION HIGH ENOUGH SO THAT IS NOT AVAILABLE
TO YOUR NORMAL CALLERS! What this feature does is allow files to be
moved from one File Area to another. When the file is moved, the
file name, file size, file date and file description from the original
SFFILES.BBS is appended the the SFFILES.BBS of the File Area to which
the file is being moved.
Files can now be tagged when logged on to the BBS locally. Files may
be tagged for erasing or for shuffling from one file area to another.
If no files have been tagged and you select either the erase or shuffle
option, you will be asked to enter the file name. When you are erasing,
you are prompted to verify that you wish to erase the file before it is
erased. If you are moving files you will be asked which area to move the
file to. You are also given the opportunity to list the file areas or to
quit.
If you have tagged files and you select to either erase or shuffle the
files, the file name you have tagged defaults into the prompt requesting
the file name and proceeds the same as if you were entering the file name
manually. In other words, if you are erasing tagged files, first you are
asked if you wish to erase the tagged files. If you reply with a yes,
you are asked to enter the filename but the tagged file name defaults
automatically. You are then asked if you are sure you want to erase this
file. This continues until all tagged files are processed. If you are
shuffling tagged files, when you select S, the 'Enter Name of File' to
move prompt appears but the file name from your tagged files defaults in
automatically. You then are asked to enter the file area you wish to
move the file to. Pressing Enter will list the file areas or you may
quit. This continues until all tagged files are processed.
The Tag Files For Download has been changed to Tag Files For Use.
This clarifies phrasing for local log ons where the files can be
tagged for erasing or moving.
SPITFIRE now supports bi-directional file transfers. When configuring
SPITFIRE to allow bi-directional file transfers, the SFEXTDN.BBS file in
the SPITFIRE display path should be modified to include the name of your
bi-directional transfer protocol. The title of transfer protocol (which
will display to the callers) should be followed by a comma and the term
"bi-directional" (without the quotes). As an example, your SFEXTDN.BBS
might look like this:
<A> Zmodem Single File,UseFile
<B> Zmodem Batch,Batch,UseFile
<C> HS-Link v1.12 Bi-Directional,Bi-Directional
When the ",bi-directional" is found SPITFIRE will automatically
assume a batch mode and a usefile mode. In other words, you are
not required to include a ",batch" or ",usefile" on the menu line.
A new batch file will be called to initiate the bi-directional file
transfer process. SFEXTBI<x>.BAT should exist in your SPITFIRE external
protocol directory. <x> should match the character by which your
caller selects the associated file transfer protocol. In other words,
if the bi-directional transfer protocol is option <A> from the menu
(SFEXTDN.BBS) the batch file would be named SFEXTBIA.BAT, if the
bi-directional transfer protocol is option <E> from the menu
(SFEXTDN.BBS) the batch file would be named SFEXTBIE.BAT, etc. In
our example above, the file would be named SFEXTBIC.BAT. The
contents of our sample SFEXTBIC.BAT file might look like this:
@Echo Off
HSLINK -P%2 @C:\SF\EXT\SFEXTRAN.LST
When a caller selects a bi-directional file transfer, the caller
is first prompted to enter the name of the file(s) they wish to
download. This follows existing download procedure, i.e., use of
file tagging, etc. SF will continue to prompt the caller until
no file name is entered. When no file name is entered, the file
names selected for download will be displayed to the caller. The
caller is next prompted to enter the file name and description of
the file(s) to upload. When prompted for a file to upload and none
is entered, SPITFIRE then shells to the appropriate SFEXTBI<x>.BAT
batch file so that the bi-directional file transfer can begin.
With the addition of bi-direction file transfers, the batch menu
options were changed slightly. The <U>...Upload Batch Queue was
changed to <B>...Begin File Transfer and the <D>...Download Batch
Queue was changed to <B>...Begin File Transfer.
General Configuration Updates
-----------------------------
SPITFIRE will now open the comm port at 115200 or 57600.
There have been reports that some of the newer modems send
different result messages when an error correction connection
occurs. SPITFIRE is now hardcoded to search for ARQ, MNP and
REL result codes to indicate that an error correction connection
has been made. In addition to these, the SPITFIRE will search
for the error correction control message the Sysop has configured
using the ALT+M configuration window.
A new option is available from the ALT+Z configuration window. This
option is Upload Available Disk Space. The Sysop will use this option
to configure how much disk space must be available before a caller will
be allowed to perform an upload. The default is 100k.
When opting to view the caller's records, either from the Sysop
Menu or by pressing ALT+A at the 'Ready...' prompt, the caller's
passwords are no longer visible. Four astericks appear in place
of the caller's password. This is a security feature. By selecting
'P' from the menu, a submenu appears which provides the options
to <V>iew, <C>hange, or <Q>uit. Viewing a password, simply
displays the password, Change provides the opportunity to modify
the password and Quit returns you to the previous menu.
Other Updates
-------------
In previous versions of SPITFIRE, if operating a multi-node system
and one caller on one node was reading a message conference and another
caller on another node was saving a message in that same conference,
there was a 10 second or so delay in the message being saved. This has
been fixed.
The shareware version previously allowed for a 30 day or 500 caller
trial before the unauthorized copy message would appear. This has been
changed to a 30 day trial period only.
A noise filter is included which prevents garbage characters from
being accepted when a caller enters their name during the log on process.
If any of these 'garbage characters' are found in the name, then
SPITFIRE just prompts for the name again. This is designed to prevent
a new caller named
l!Y\&1xzQj2,'54BUP18oT.DYAHYEa/#LR-<.7i~5U3M
from logging on.
A change has been made to JOKER.DAT. If any line in JOKER.DAT is preceded
with '@ ' followed by text, no one with that portion of the text in any part
of their name will be allowed to log on to the BBS. This is primarily
intended for profane words but for example I will use:
@screw
The above would deny access to the BBS by anyone with the name of Screw You,
Screw It, Screw Up, Screw This Board, etc.
This new feature is to be used with caution because it would be extremely
easy to unintentionally deny someone access. For example, the above (@screw)
would deny someone named Ben Thumbscrew access.
Display Files
-------------
A new display file has been added, SFONFAIL.BBS/CLR. This is displayed
when a caller logs on the BBS and fails to enter the correct password.
An example of how this display file might be used would be to inform the
caller that perhaps another caller by the same name is already a user of
the BBS and that they might want to log on using a nickname or using
their middle initial.
╒══════════════════╕
│ THE IRONCLAD BBS │
╘══════════════════╛
Running a BBS can be a lot of work. Keeping it running reliably can
be even more work. Computers are notoriously un-reliable over the long
run. But, there are several things you can do to help keep your system
running with minimum downtime. Being an electronics engineer puts me in
a unique position as a BBS sysop in making my system "iron clad" and able
to "take a licking and keep on ticking". Here are a few things I have
done to customize my system such that it keeps running regardless of
problems. This is often called "Fault tolerance", and can become quite
an art.
1) Buy the best computer you can afford for your BBS.
My system is provided by, and built by my employer. It is a STD Bus
based industrial computer. It is an extremely rugged, reliable system
to start with. At least an order of magnitude more reliable than the
best desktop systems. However, the cost is an order of magnitude more
than the best desktop systems! The CPU card alone costs as much as a
complete mid-range desktop system. Not an alternative for most. The
bottom line is: Obtain the best hardware you can, this includes the
MODEM.
2) Use some kind of watchdog timer.
This is the heart of any really fault tolerant system, regardless of
function. This can keep your system running when all else fails. If
at all possible, use a hardware watchdog. Anyone with a minimum of
electronics knowledge can wire-wrap one on a plug-in board in a couple
of hours. The output is connected to the computer's RESET line. My
setup is such that the hardware timer has a time-out of 18 hours. I
have two events set up at 12 hour intervals (3:00 AM and 3:00 PM) to
re-start the timer. If the system ever crashes, for whatever reason,
the most it will be offline is 18 hours. Then the timer will time-out,
and reset the system. The system WILL come back up, unless it is flat
broken.
The watchdog can serve another purpose. If you have terminated SF
to do some kind of maintenance, and are called away from the system,
and forget about it, the watchdog will eventually time-out and restart
SF for you.
Care should be taken in choosing the watchdog interval. A shorter
interval will result in less downtime if the system crashes, but it also
means that you must restart the timer more often. For example, if you
have a two hour watchdog, you would have to have 12 events configured
to re-start it. And you could still get into trouble. Say your time
limit for users is 1 hour. And let's further say that you re-start
the timer in SFLOGON.BAT, when the user logs on. The user spends an
hour uploading the source code to NETHACK, a 2 megabyte file. This
takes him an hour. The upload compensation on most boards will give
him time out past the reset time. Now this user decides to use all this
time to download the latest version of Spitfire and some utilities.
Somewhere in the middle of this, the timer times out, and the user is
history! Not good. You can get around this by declaring your timer
restart events as on-time events, but this is tacky, to say the least.
I recommend the timer run be 50% longer than the restart interval. 18
hour timer gets restarted every 12, a 12 hour timer gets restarted every
8, etc. I wouldn't recommend anything shorter than 4 hours, and 6 would
be better. Real long timers, such as mine do not require restarting when
the user logs on, but short ones do. Long timers also allow the luxury
of NOT having to declare as many events to restart them, nor do these
events have to be on-time events. Be sure to restart your timer when
terminating Spitfire or shelling to DOS remotely!
Software timers to accomplish the same thing are available. They
are not as reliable as hardware timers, but they are far, far better
than nothing, and are easier to set up.
3) REBOOT!
Once a day, execute a cold boot on your system. I do this
automatically. This reloads everything and helps eliminate problems
caused by power glitches, "cosmic rays", poorly written programs,
Sysop errors, whatever. Buffalo Creek has a simple program that will
do this for you, or you can write one with DEBUG. If you are running
4DOS or NDOS, you can use the REBOOT command. I'm very leery of
programs running out of RAM for long periods of time, especially
dynamic RAM, which 99% of the desktop machines utilize.
4) Use an external MODEM.
Lots of Sysops already believe in this one. The problem with MODEMs,
especially the newer, smarter variety, is that they can get lost just
like the computer can. I have more custom hardware to handle this than
is ordinarily available. I actually have computer control of the AC line
going to the MODEM. I power cycle the MODEM daily at the same time I
do my reboot. I also automatically power down the MODEM when I F10 out
of SF, and automatically power up the MODEM in SF.BAT just before actually
running Spitfire. Mike Woltz, the author of Spitfire, has also included
the ability to correct MODEM problems within Spitfire. Take advantage
of this ability! Use a file called BADINIT.BAT to attempt to do something
about a MODEM that will not respond to Spitfire. In my case, I turn the
power off, delay, and then turn it back on. Has never been known to fail.
Others who don't have the luxury of AC control, may attempt to do this
through software. Internal Modems may have a reset port, or perhaps
automatically resetting the computer via a hardware port may do the trick.
5) Automate, automate, automate!
Over the years, Mike Woltz has made significant improvements to
Spitfire that allows Sysops the ability to considerably automate their
BBS systems. This allows not only a easier to run BBS, but a more
reliable one as well. SF can shell to various batch files at various
times of execution. Take advantage of this to automate, and bulletproof
your systems. I hear tell of systems local to me every day that have
been down for days when the Sysop goes out of town and something bad
happens. Since I have installed the custom hardware and batch files,
etc. my system has had zero downtime, as long as there was power to run
it. My system was one of 2, out of about 15 local boards, that came
right up and ran immediately after power was restored after the October
17, 1989 Loma Prieta (Or San Francisco to you out of staters) Earthquake.
And it hasn't been down since. Since the system is in my office at work,
it runs un-attended most of the time and must be able to take care of
itself.
6) Buy a UPS?
Maybe, if you can afford it. If you do, you must do one of two things:
Either you must be near the system at all times to shut it down if the
power is down for a long time, or you must buy one of the more expensive
units that is capable of communicating with the computer allowing it to
eventually turn itself off, if necessary. If you let an ordinary UPS
run without shutdown in an extended power outage, you WILL kill it.
Frankly, I don't feel it is worth the hassle as most of your local
users will probably be without power as well, and the phone lines
may be out as well.
u]3
Do provide surge protection, etc. if your system doesn't have it
built in already. A constant voltage transformer is a nice toy to
plug your system in, it doesn't buy you anything in a black out
situation, but it regulates the AC going into your system and allows
it to keep going in case of brown outs.
7) Shutdown your hard drive.
This is one even I haven't implemented, yet. I intend to eventually
boot Spitfire off of one of my semiconductor (Flash EEPROM for you
techies) disk drives, and turn on the hard drive power in SFLOGON.BAT,
and off in SFINIT.BAT. This will cut down drastically on Hard drive wear
and tear. This will take considerable planning to ensure that SF has
all the files it needs to execute until it can turn on the hard drive.
A TSR may be needed to monitor carrier status in order to power up the
hard drive sooner. I distrust any mechanical part of a computer system,
and try to use mechanics as little as possible.
In closing, Spitfire has evolved to the point where it has enough
built in capability to both automate, and bullet proof your board. If
you have a little hardware/software knowledge, you can really customize
your board to the point where nothing will stop it. Even if you don't
like to get your hands dirty, you can still do several things to make
your board more crash proof.
If you need tips on building a watchdog timer, feel free to contact
me at Buffalo Creek, or at my board, Hacker Heaven at (408) 375-5455.
Article Contributed by Mark Pickerill
Sysop, Hacker Heaven BBS
╒════════════════════╕
│ SYSOP-OF-THE-MONTH │
╘════════════════════╛
Brian Carlson
The Chicken Coop
Lake in the Hills, Illinois
I remember when I saw my first modem. My neighbor bought a 300
bps modem for his Commodore 64 and insisted that it was something that
I should add to my Commodore. He was right! I used that Commodore for
a year calling various local boards. I was almost immediately inspired
to run my own board. In April 1990, I bought an IBM clone with a 20 meg
hard drive and a month later I was on-line with shareware SPITFIRE.
SPITFIRE was the first and and only BBS software I have ever run. I
never looked at any other BBS software because it was obvious SPITFIRE
was easy to use and could be made to do exactly what I wanted it to do.
The Chicken Coop was born.
When I first started running SPITFIRE in its evaluation mode, I
jokingly named the board "The Chicken Coop." I live inside village
limits and for years I have had a pet chicken. She was the subject of
many jokes and comments with the people I communicated with via my modem.
When I registered SPITFIRE, I decided to get "serious," decided I wanted
to change the board's name to something more sophisticated. Immediately
about 30 callers objected, every one complaining that they liked the old
name. And it's been The Chicken Coop ever since.
The Chicken Coop has come a long way since its beginning. I'm now a
member of RelayNet mail network and this year upgraded to a 14.4K V32bis
modem. The old 286 motherboard was replaced with a 386 and enough memory
for a second node sometime in 1993.
The main theme of my board is RelayNet and on-line games. I run
several monthly contests, having prizes ranging from higher access for
a month to an exclusive private log-on time for the month's number one
winner. I use SPITFIRE's on-time event feature to configure the board
as a private BBS for a 15 minute period allowing the month's winner a
"no-busy-signal" log-on time once a day. This is a prize costing the
sysop nothing but is of great value for the callers due to the busy
nature of my board.
In closing, I want to thank Mike Woltz for writing a great, easy-
to-use software, Richard Johnson of the Byrd's Nest BBS for technical
assistance and making the switch to a high speed modem a breeze, and to
John Krone of ICIX BBS for helping me with Spitfire in the early days.
Also, I would like to thank Spitfire Chicago Area Sysops Association
<SFCASA> for support, friendship and some nice parties! SFCASA can
be reached at The Chicago Megaphile BBS.
╒════════════════════════════════════╕
│ NEWLY REGISTERED SPITFIRE SYSTEMS │
╘════════════════════════════════════╛
A hearty welcome is extended to the following, who have
recently become public registered SPITFIRE Bulletin Board Systems:
The Abacus...................................717-633-7232....2400 Baud
John Pittman, Sysop..............................Hanover, Pennsylvania
The Runesword BBS...........................707-526-4969..Unknown Baud
Lyle Barrow, Sysop..............................Santa Rosa, California
The Toolbox BBS..............................502-942-1111...14400 Baud
Charles Baker, Sysop...............................Fort Knox, Kentucky
Joshua.......................................1-39-534-797...14400 Baud
Ribau Frederic, Sysop...............................Versailles, France
Wolfpack.....................................502-942-8041...14400 Baud
Pablo Quirindongo, Sysop...........................Muldraugh, Kentucky
The Crystal Ball.............................502-271-2500....2400 Baud
Brett Morris, Sysop..................................Herndon, Kentucky
We Be Games..................................206-475-0708....2400 Baud
David Stepp, Sysop..................................Tacoma, Washington
Hog On Ice BBS...............................916-424-8308...14400 Baud
Nick McGee, Sysop..............................Sacramento, California
The Last Chance..............................614-522-2829....2400 Baud
Charles Brand, Sysop.......................................Heath, Ohio
The Home Front BBS...........................502-942-0089....2400 Baud
Michael Harrington, Sysop..........................Fort Knox, Kentucky
Moiraine's Playground.......................817-542-5579....9600 Baud
Dorothea Hoelzl-Eyster, Sysop.....................Copperas Cove, Texas
The Jungle's Vine............................606-441-6998....2400 Baud
Della Halpin, Sysop..............................Fort Thomas, Kentucky
The Scrabbler................................604-360-0261....2400 Baud
Joan Gilkin, Sysop..................Victoria, British Columbia, Canada
Cosmic Room Service...........................902-569-5870...2400 Baud
Richard Lidstone, Sysop............................Keppoch, PEI,Canada
Moonlite.....................................317-966-3933....2400 Baud
David Mull, Sysop....................................Richmond, Indiana
The Cess Pool................................708-352-9231...14400 Baud
Rick Gross, Sysop...................................LaGrange, Illinois
Milo's New Power Generation BBS...............302-328-5557...2400 Baud
Randall Callahan, Jr., Sysop......................New Castle, Delaware
Sky Data.....................................616-684-3688...14400 Baud
Randy Rentz, Sysop.....................................Niles, Michigan
Sawbuck's....................................717-632-2788....9600 Baud
Thomas Miller, Sysop.............................Hanover, Pennsylvania
The Future BBS...............................717-426-3173...14400 Baud
Brian Sracic, Sysop..............................Maytown, Pennsylvania
Deranged BBS.................................305-936-1164....9600 Baud
Jeffrey Snyder, Sysop...............................Adventura, Florida
Clown N' Around..............................405-685-5184....2400 Baud
William Dodson, Sysop..........................Oklahoma City, Oklahoma
The Falls BBS................................714-794-8112....2400 Baud
Robert Wise, Sysop............................Forest Falls, California
Desert Sands.................................915-594-1280....2400 Baud
Steve Simon, Sysop......................................El Paso, Texas
Desert Nights BBS............................602-578-3589....2400 Baud
Mark Slaughter, Sysop..................................Tucson, Arizona
Bytewise.....................................317-996-4065....2400 Baud
John Hobson, Sysop................................Mooresville, Indiana
The Terre Haute Music BBS....................812-235-1692...14400 Baud
Bob Braun, Sysop..................................Terre Haute, Indiana
The Fhunny Pharm.............................713-474-5420...12000 Baud
Rick Bedard, Sysop.....................................Seabrook, Texas
Networkers Box.............................+49-6051-12854...14400 Baud
Thomas Hofmann, Sysop.......................D - 6466 Gruendau, Germany
Two Amigos BBS...............................806-352-7455...14400 Baud
Greg Vincent, Sysop....................................Amarillo, Texas
"FAITH" Full BBS.............................203-747-4813....2400 Baud
Roger Barker, Sysop............................Plainville, Connecticut
The Light House BBS..........................207-499-2696....2400 Baud
Deron Treadwell, Sysop....................................Lyman, Maine
The Computer Clinic..........................401-421-3452...14400 Baud
Dave Manchester, Sysop........................Providence, Rhode Island
Howl!........................................713-862-1415...14400 Baud
Joel Harris, Sysop......................................Houston, Texas
In addition, there were 4 new private SPITFIRE BBS Systems
registered. These private SPITFIRE BBS's included registrations
from: Rialto, California; Sunnyvale, California; Tempe, Arizona;
and Houston, Texas.
There were 25 registrations for whom registration information was
incomplete. These included BBS's in: Fresno, California; Arlington,
Texas; Clinton, Indiana; Providence, Rhode Island; West Monroe,
Louisiana; Palmer, Arkansas; San Antonio, Texas; Chicago, Illinois;
Nikiski, Arkansas; Wallaceburg, Ontario, Canada; Bethany Beach,
Delaware; Asan, Guam; Houston, Texas; Pt. Pleasant, Pennsylvania;
New Orleans, Louisiana; Exeter, Rhode Island; Weehawken, New Jersey;
Garland, Texas; FPO Address; Topeka, Kansas; Forestville, California;
Norristown, Pennsylvania; Houston, Texas; Labrador City, NF, Canada;
and Waterloo, Ontario, Canada.
The increase in registrations where information is incomplete is
largely due to Buffalo Creek's Software's new policy of accepting
on-line Mastercard and Visa credit card registrations.
JUST A REMINDER...the newsletter is always looking for contributions!
Please forward any articles in ASCII text to either Buffalo Creek's BBS
or The Mother Board BBS.Source note
This reading edition was decoded from SF11-92.TXT in the original SF11-92.ZIP package. The page date records the preserved archive timestamp; it is not a newly inferred publication date.