home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware 1 2 the Maxx
/
sw_1.zip
/
sw_1
/
BBS
/
TPB71DOC.ZIP
/
INSTALL.DOC
next >
Wrap
Text File
|
1992-04-03
|
249KB
|
6,459 lines
Sysop Manual
for
TPBoard Version 7.1
Copyright (c) 1991 by:
Jim McDaniel-Webb
2452 Milburnie Road
Raleigh NC 27610
(919) 831-0674
Fidonet 1:151/112
Distributed by:
Online Communications, Inc
22 State Street
Bangor, Maine, U.S.A. 04401
(207) 941-1110
Fidonet 1:132/300
Copyright (c) 1987-90 by
Jon Schneider & Rick Petersen
======================== N O T I C E =======================
TPBoard and it's associated support files are Copyright (c)
1987 thru 1990 by Jon Schneider & Rick Petersen. Current
copyright is held jointly by Jon Schneider & Rick Petersen
and by Jim McDaniel-Webb. Non-commercial use and/or public
distribution of this system is permitted pusuant to the
conditions listed below. ALL commercial rights are reserved.
-------------------------
TPBoard is based on the Pascal Integrated Communications
System (PICS), Copyright 1986, 1987 by Les Archambault, and
the Remote Operating System (ROS), Copyright 1985, 1986 by
Steve Fox.
All programs mentioned are copyright by their respective
authors.
======================= REGISTRATION =======================
If you haven't read the file named REGISTER.FRM, do so now
before proceeding. That file contains important information
about registering TPBoard as well as terms and agreements
you will want to read before installing this software.
The TPBoard Bulletin Board system is distributed as shareware
for home/hobbyiest use, but must be licensed for use within
a business, corporation, or organization. This includes
educational institutions, government agencies, and public
agencies without exception. In addition, business and
commercial as defined is extended to include the running of
TPBoard within such confines for ANY purpose.
If you are a shareware distributor, you may distribute all
software listed below in the registration form as long as you
contact Online Communications for permission first. You
must distribute all the files intact and in unmodified form
and may not charge more than a reasonable disk copying fee.
If you are a System Operator and run any version of TPBoard,
you may make the TPBoard distributed acrhives available for
download providing they are distributed AS-IS and they have
not been modified in any way. You may NOT add comments or
remarks of ANY kind to the distribution archives!
============================================================
Table of contents
1. Introduction
What is TPBoard?
Before you begin
System requirements
Hacker Instructions (Fast installation)
Registration and TPBoard+
Converting to 7.0
2. INSTALLATION
STEP 1 -- Installing and preparing the files
STEP 2 -- Editing the system text files
SYSMSG and SYSMSGg
Language Support
BADNAMES.LST
BADNUMS.LST
TPBPATHS.1
ECHORULE.TXT
ORIGIN
RO
CONF1.TXT .. CONF31.TXT
VALIDATE.TXT
QUOTES.TXT
STEP 3 -- Establishing the system organization
Editing Message areas
Editing Files areas
Editing Articles
Editing Database areas
Editing Doors
STEP 4 -- Establish the system security
Editing Validation levels
STEP 5 -- Edit TPBoard settings
STEP 6 -- RUN TPB to initialize system data files
3. Advanced Features
Menu Help screens
Editing Sysmsg files/Using MakeSysm
Setting up for XRS
Setting up for Ascii Mailbags
The Database Feature
Extended file info
Private file transfers Using Config.VAL
Enabling the remote shell to DOS
IEMSI
REMOTED.BAT - a remote editor
Setting up Doors
4. CONS features
Ascii Export & Merge Export
Newin processing
Rebuild
View headers
List Update
Mailer count
Node flags
View msg hdr
Impmgs
Sort AREAS
Editing TPBmenus
5. Mailers
TPBoard and Some Mailers
Speeding up TPBoard under a Mailer
BinkleyTerm Specific Installation
FrontDoor Specific Installation
Running Impmsgs
6. System Settings
Board/Fido
Restrictions/Purge
General
Features
Modem Strings
Validation
Hardware/Communications
7. The Network version
8. Utility Programs
LISTUPDT.EXE
REBUILD.EXE
MAKESYSM.EXE
DESCCOMP.EXE
SETSHARE.EXE
62TO64.EXE
IMPMSGS.EXE
RENUM.EXE
PAKMESGS.EXE
TPBEDIT.EXE
TPBNEDIT.EXE
NEWNCNVT.EXE
USRCNVT.EXE
TPBDEV70.EXE
PJASCII.EXE
VALIDATE.EXE
MAILERS.EXE
NED.EXE
REVAL.EXE
Appendices
General Notes
Modems
Using external programs for "Typing" files
TPBoard and Expanded Memory
Q&A
Local Sysop Use
Windows 3.0
Future Plans
Credits
1. Introduction
A brief note on the language of this document. Throughout this
manual, callers and/or sysops are referred to as "he." This is
not meant to infer anything and is nothing more than cowtowing
to convenience on our part. No intent to offend is intended.
What is TPBoard?
================
TPBoard is a full featured bulletin board system for PC-DOS
and MS-DOS computers. TPBoard is in its seventh year and,
with the release of version 7.1, remains at the forefront of
computer bulletin board systems.
The primary purposes of TPBoard, as with any bulletin board
software, is:
- to provide news and bulletins
- provide a means of exchanging programs or files
- exchange electronic mail between callers
- entertainment for the caller and enjoyment for the sysop
Some of the key features of TPBoard v7 are:
o The industry's most compact message base format.
For a message oriented bbs, nothing can come close to
the disk efficiency of TPBoard.
o ALL internal protocols. While many bulletin board systems
still rely on external programs for advanced protocols such
as Zmodem, TPBoard has had complete internal protocols for
YEARS. And others are using a recently released and
relatively untested comm library.
o Advanced file handling:
- download across file areas
- download using wildcard characters
- file tagging (up to 20 files) and downloading
- automatic releasing of files
- 'Type' files on-line, including: Squeezed, and individual
LBR, ARC, PAK, ZIP, and LZH member files.
- download individual files from within ARC, PAK, ZIP, and
LZH files without shelling to a batch file!
- extended file info of *ANY* length
- automatic support for SDN areas
o NO limit of 200 files per area!
o Split screen chat with callers.
o Internal support for fast IEMSI logins.
o Internal support for the XRS off-line reader program.
o Up to 255 message areas and 255 files areas. Many boards
still only support only 200 message areas.
o Renumbers thousands of messages in minutes.
o Internal support for accessing dBaseIII files. Callers can
search and filter dBase files, create and download reports,
browse to the screen, etc.
o System generated menus based on caller privilege settings.
o Active, on-going development with regular releases and
updates.
o TPBoard is the only board that allows callers to sort
file listings by Name, Size, Ext, and Date!
o Multi Language support
o Network compatible inbound message processing
o Dump TPBoard's database files to any ascii format you want
for reporting, importing to dBase or Paradox, etc. Even
a mail-merge function is included.
o FidoNet utilities for NodeList updates, message importing,
etc. is provided. ALL other boards charge for such
utilities or require that your purchase third-party
programs.
The essential philosophy of TPBoard is minimum maintenance.
By that we mean that the sysop should be able to get TPBoard
up and running, and remain running, with a minimum of effort,
configuration, and around-the-elbows back scratching. It is
not unusual to have a TPBoard system running in less than an
hour! The amount of time required for you to maintain your
system will directly affect how much enjoyment you can get
out of your system. If you want to "play" with your board,
TPBoard probably isn't for you; if you want to RUN a board,
nothing will get you there faster and keep you there easier
than TPBoard.
A quote from another bbs package states "XXX is a powerful
application that may take months to master fully." Well,
TPBoard is also a powerful package and compares feature for
feature with any bbs package available. Still, we sincerely
hope it doesn't take MONTHS for you to begin to enjoy running
your first TPBoard system!
It is important to note that while most bulletin boards
appear to be the same when viewed from a caller's perspective,
most differ widely in how they achieve the very similar
features. For example, many bbs packages store file
descriptions in simple ascii text files. While such files
can speed up global searches slightly, they make management
of your Files areas a virtual nightmare. Just try to allow
callers to sort listings from ascii files!
All of TPBoard's important databases -- the Files, Messages,
and Users files -- are multi-keyed btree indexed for super
fast access. You won't sit for minutes waiting for a new mail
check as you would with some 'PC' Boards. Nor will you spend
weeks setting up TPBoard.
Another factor is cost. If you are setting up a multi-node
board or have any plans to grow to a multi-line bbs, TPBoard
will save you time and -- most important -- money. TPBoard+
comes with support for a 99 line multi-node system included;
WildCat charges $499.00, PCBoard is $970.00, and Remote
Access is $249! There are other cost factors to consider
such as yearly support fees or costs for for utilitites that
are common with other boards.
TPBoard _comes_ with complete support for use under any
network that provided MicroSoft compatible locking calls.
TPBoard can also be run in local mode where the caller logs
in from the DOS prompt; not from a modem.
Before you begin
================
Since you are attempting to set up a bulletin board system,
we will assume that you understand the essential workings of
a bbs. If you are currently running an older version of
TPBoard, consult the doc file provided for upgrading from a
particular version of TPBoard, for example: 64270.DOC.
This document contains NO information for updating from
previous versions.
System requirements
===================
In order to run TPBoard, you must have an IBM compatible
computer. It must be equipped with at least 384k, at least
one serial port, and be capable of running MS-DOS 2.0 or
later. If you want to run TPBoard under a FidoNet mailer
and/or a multitasker, then you should have at least 384k
free. Features of TPBoard+, such as the compressed message
base may require additional memory. Although TPBoard will
"run" in 250k, 512k of available memory is strongly
recommended.
In addition, expanded memory will greatly speed up features
such as running doors, shelling to DOS, and loading under
a mailer.
You also must have a Hayes compatible modem, or at least one
that is 100% Hayes command set and result code compatible.
The following modem switch settings (or equivalent command
states) are assumed:
1 = up DTR supported, do not force to always logic true.
2 = down Send result codes as digits.
3 = down Send result codes to the host. 4 = up Echo characters when in command state (off line).
5 = down Do not answer the telephone.
6 = up DCD supported, do not force to always logic true.
7 = up Single line RJ11 telephone connection to modem.
8 = down Enables command recognition when in command state.
A hard disk is necessary as TPBoard requires more disk
space than is available on a 2 floppy system, and makes
heavy use of overlay files. The typical TPBoard system
directory consumes 2mg of disk space with a minimum
message base.
TPBoard requires no external program for it's operation, but
will utilize one if found: if you want to utilize the remote
"Shell to DOS" function, then you will want to use some sort of
CTTY type device. We would suggest DoorWay from Marshall
Dudley. ALso, there is an extended Newin processing command,
'Z', that only works if the program SHEZ is found in your
path.
If you want to utilize TPBoard's support for FidoNet, then
you must also obtain a mailer program. Note, if you are new
to Fidonet, FrontDoor is much easier for the novice to install.
BinkleyTerm is a more complex program, and requires quite a few
external support programs of it's own. TPBoard has been run
under each of the following: SEAdog, FrontDoor, BinkleyTerm,
Dutchie, and D'Bridge. For more information on mailers,
consult the section on Mailers.
Hacker Instructions (Fast installation)
=======================================
We recommend that you read the following section on Installation
as well as the Q&A appendix before setting up TPBoard. But, if
you're the impatient type and want to learn as you go, you're
on your own (except for the following):
1) Create a TPBoard directory directly off the root directory
2) Copy *ALL* distribution files to this directory.
3) Extract the distribution self-extracting archives. (ALL
executables on the distribution disks are archives.)
4) Delete the *original* .EXE archives unless you want them
taking up space on your disk.
5) Run CONS and select the Configs menus. Edit ALL settings
that are specific to YOUR installation such as modem
strings, hardware settings, the sysop name, selected
features, etc... This won't take very long. DO NOT
ENABLE FAST LOCAL LOGINS UNTIL THERE IS A SYSOP RECORD
IN PLACE!!!
6) Run TPB as: TPB 99 (this is a sysop's LOCAL login)
When prompted for name, enter: SYSOP
Next, enter a password you can remember and complete your
login.
7) Exit the system by selecting G)oodbye
That's it. The system is setup and you're established as the
SYSOP. Now that you've had the experience of seeing TPBoard
running, read the following fully so that you understand all
of the features and how to use them. You may also now enable
fast local logins (now that you have a sysop record).
Registration and TPBoard+
-------------------------
TPBoard is distributed in one version that contains three forms.
In other words, there is only one physical version of the
executable program called TPB.EXE, but that version will run in
three different ways depending on your registration level.
The basic version is the executable run without a key file. In
this form, TPBoard will come up with the line:
TPBoard v7.1 03-01-92
This is an UN-Registered copy of TPBoard
The next version is called Level1 Registration. This version requires
a key file that contains the name of the person who has registered
that copy of TPBoard. In this form, TPBoard will come up with the
line:
TPBoard v7.1 03-01-92
<serial number> Registered to <your name>
The final form is called Level2 Registration and is currently the
highest level of registration. At this level, TPBoard will come up
with the line:
TPBoard+ v7.1 03-01-92
<serial number> Registered to <your name>
Note the + after TPBoard. This version is called TPBoard+ because
many of the more advanced features of TPBoard v7 are only available
to users when they have registered at Level 2. These features are:
1) dBaseIII functions and menus.
2) Message compression.
3) Unlimited extended file descriptions.
4) Network functionality. Non-registered and Level1 allow
only single-node access.
5) The NED and SED full screen database editors
Currently, these features are available only if you have
registered your copy of TPBoard at Level 2. More features may
be added in future versions of TPBoard that are also only
available to Level 2 registrants.
TPBoard comes with a demonstration key file that enables all
of TPBoard's features for TWO users for unlimited use. With the
sysop being the first user (if setup correctly), this limit allows
only one other user. Thus, if you are setting up TPBoard for
evaluation, do so exactly as described below for the initial
sysop login and you will have a fully functional TPBoard system.
Converting to 7.1
=================
There is no conversion process required from 7.0 to 7.1.
If you are running 6.4, you will need to perform the
following steps to install 7.1:
1) backup everything
2) run USRCNVT -S to convert your USER files. You can
also optionally run USRCNVT as
-P to set privilege codes to all access (but sysop
menu and Database menu)
-B to clear birthdays to 00/00/00
-R to set auto clear screens ON
All of the above are recommended! Better results are
achieved if your run -S first followed by each in turn.
3) run Nwncnvt to convert your Newin file
4) edit config.val OR use CONS to configure all the new
settings
5) edit the sysmsg files to reflect the new menus. A new
utility called MakeSysm will make editing sysmsg files
much easier and much faster. (Or select system created
menus.)
6) optionally, add the help screens for EVERY command in
TPBoard.
If you don't know what some of the above means, read the
rest of this document before installing 7.1.
If you are running any version earlier than 6.4 (why?), you
will need to convert to 6.4 first. A utility called 62TO64
is available on The Board Room but is not distributed with
TPBoard v7. No instruction will be provided in 7.1 to bring
users of 6.2 or 5.X up to date.
=======================================
2. INSTALLATION OF A NEW TPBOARD SYSTEM
=======================================
STEP 1 -- Installing and preparing the files **************
First, we will assume that you have read the README file
and are aware of any last minute changes or corrections to
this manual and this version. Also, the README file contains
instructions on extracting the program files from the
distribution archives. No install program as such is included
with TPBoard because self-extracting archives are provided and
anything more would really be superfluous.
Before you try installing TPBoard, you should sit down and
decide how you want the system organized. A little planning
now will save a lot of time later.
TPBoard, its data files, and external support programs must
be located in one directory. If you are limited to one hard
disk, then it's best to create a subdirectory called TPBoard
directly below the root directory. Hereafter, this directory
will be known as the "system" directory.
The files that need to reside in the system directory are:
*TPB.EXE
QUOTES.TXT
*SYSMSG.TXT
*SYSMSGG.TXT
OTHERSYS.LST
BADNUMS.LST
BADNAMES.LST
*CONS.EXE
Only those files marked with '*' are actually required to run
TPBoard; CONS will be used to setup TPBoard initially and
should probably be left available in the system directory.
All the other files are optional but should be in the system
directory if you're going to use them.
If you are using fido mail and want to use the message importer
distributed with TPBoard, you will also need the following:
IMPMSGS.EXE
The following files are needed only if you shell to DOS during
a remote login:
REMOTE.BAT
DOORWAY.EXE (or similar)
The following file MUST be located somewhere in your PATH:
COMMAND.COM
The following file will be used IF located in your PATH:
SHEZ.EXE
TPBoard will create quite a few new files on it's first run.
They will all have the extension BB#, and must stay in the
system directory. The exceptions being the files that
comprise the message base. These files may be placed anywhere
you specify in the CONS program. The message base files
are:
SUMMARY.DAT SUMMARY.IX MESSAGES.BB#
If you install TPBoard in the system directory and later
decide to move the message base you can do so without harm.
Some of the external support programs also create their own
files, but there is no harm done if they get lost or deleted.
Once you've decided which directory you will use for the
TPBoard system directory, copy the files shown above to that
directory. Try to avoid having any other files in that directory. It makes system backups and maintenance much
easier if only TPBoard files are located there. Personally,
I only backup the .DAT and .IX files.
Ok, to restate all of the above in terms of DOS commands:
C:
CD C:\
MD TPBOARD
CD TPBOARD
COPY A:*.* ; do this for EACH TPBoard disk
TPB7TEXT ; extract system text
TPB7EXE ; extract system executable
TPB7CONS ; extract the CONS setup program
TPB7UTIL ; extract the Utilities programs
TPB7NED ; extract the Ned/Sed editors
TPB7DOCS ; extract the docs if you want a disk copy
DEL TPB7TEXT ; delete the original archives
DEL TPB7EXE ; delete the original archives
DEL TPB7CONS ; delete the original archives
DEL TPB7UTIL ; delete the original archives
DEL TPB7NED ; delete the original archives
DEL TPB7DOCS ; delete the original archives
CONS ; run CONS to configure TPBoard
TPB 99 ; run TPB a first time
That's essentially it. By running CONS the first time, you
will have default Message and Files areas established. Assuming
you answered the hardware questions correctly and that you have
logged in at least once locally as SYSOP, you have a running
bulletin board! Now you can take the time to edit and configure
your system more carefully.
The CONFIG.SYS file
--------------------
TPBoard keeps quite a few files open at one time so you will
need to adjust the DOS setting that limits the number of
files in use. To do that, just add the following line to
your CONFIG.SYS file;
FILES=50
TPBoard can be aborted on some machines by a ^C on the local
console. Although the code should not allow that, If you
are experiencing problems with this on your system, just add
the following line to your CONFIG.SYS file.
BREAK=OFF
STEP 2 -- Editing the system text files ********************
All text displayed by the system -- menus, new user info, the
welcome screen, etc. -- is contained in two files called
SYSMSG.txt and SYSMSGg.txt. SYSMSG.txt contains the screens
for callers who do not select ANSI mode and SYSMSGg.txt is
for those who DO select ANSI. This saves enormous disk space
over bulletin boards that store every screen as a separate
little text file!
The SYSMSG and SYSMSGg files come prepared with a generic
"look" and you will need to edit them to suit your tastes
and your system. When a caller first enters TPBoard,
TPBoard detects whether they are capable of ANSI and will
ask them if they wish to use ansi (YOU edit this question in
the CONS program). Whenever the caller answers YES to this
question (regardless of how you've phrased the question) the
text will come from SYSMSGg.Txt.
The non-ansi SYSMSG.txt can be edited using any ascii editor
and should NOT contain any ansi commands. NOTE that the
ansi SYSMSGG.txt file does not have to contain ansi screens:
it is treated by TPBoard exactly as the ascii version. Thus,
it can be a duplicate of the ascii version, or it can be an
ansi version, or it could even be in a different language.
The structure of the SYSMSG files is simple: screen text
separated by screen delimiters. Screen delimiters are lines
within the SYSMSG file that begin with a colon. For example:
:N - System menu header
-={ The Board Room TPBoard Support BBS }=-
:W - Welcome message
"T h e B o a r d R o o m"
Welcome to the Origin of
...and so on...
The text beginning on the line following the :N (and any text
until the next delimiter is found), will be displayed as a
header before system generated menus. The :N marks the
beginning of the welcome screen. The :W marks the beginning
of the WELCOME screen.
If you choose to use the SYSMSGg.txt file as ansi, you will
need to edit the screens as individual ansi files using
any of the popular ansi editors. ANSIPAINT and TheDraw are
two examples of such programs. To facilitate editing ansi
screens, CONS contains menu options that will write SYSMSG
files as individual .ANS files. There are also options for
reading .ANS files back into a complete SYSMSG files. A
separate utility called Makesysm will also help in creating
these sysmsg files.
In case you don't know what ANSI screens are, ANSI screens
contain special characters such as the box drawing characters
available on IBM compatible machines as well as colorized
text. Non-ANSI screens contain only text and should NEVER
contain characters from the extended IBM character set.
LANGUAGE SUPPORT
----------------
You have the option of creating 10 sets of Sysmsg files by
telling TPBoard where to find each set (the files must still
have the predefined names). Use CONS to establish these
language sets. A "language set" is merely a name for each
set and a path to a Sysmsg.txt, SysmsgG.txt, and a TPBmenus
file. If you do set up multiple language sets, callers will
be asked which they wish to use. The sysop (during local
logins only) is ALWAYS logged in under the first language set.
CONS will create a file for you called TPBLANG.BB# (the "1"
is the node number for multi-node use). You can also edit this
file with an ascii editor. If you are running miltiple nodes,
you will have to make a copy TPBLANG1.BB# for each node and
edit the paths withing the file(s) to work on your system.
So, if you have 3 nodes and wish to make GERMAN, ENGLISH, and
FRENCH versions of your board available on each node, you will
need to create a TPBLANG1.BB# in CONS and copy this file
as TPBLANG2.BB# and TPBLANG3.BB#. You will then edit these
files to reflect the correct paths as seen by those nodes.
You will also place a the language versions of your system text
files in the respectve directories.
As an example, if C:\TPB is your system directory, you could
create subdirs named:
C:\TPB\GERM
C:\TPB\ENGL
C:\TPB\FRCH
Into EACH subdir, copy a Sysmsg.txt, SysmsgG.txt, and a
TPBMENUS.BB# file.
When a caller logs in, TPBoard will display a list of these
sets by the names you have given to them and will ask the caller
which language they wish to use.
A twist used by one sysop is to make a novice set of system text
files and a pro set of text files.
BADNAMES.LST
------------
This file is created as a plain ASCII text file, and contains a
list of names (one per line) that are not allowed to be used
*anywhere* in a users full name. If a user enters a name that
is contained in the list, a log entry will be made with
'TWIT New User <acutal name used>'.
Example format of BADNAMES.LST:
JOHN ANDERSON!SHIT
MIKE
Using the above list, no one name JOHN ANDERSON would be allowed
to login to the system. No name containing SHIT anywhere in the
first OR last name would be allowed to login. And no one with a
complete first or last name of MIKE would be allowed to login.
A full name search requires a first and last name, a single name
will match EITHER the first or last, and an embedded search starts
with an exclamation point.
Make absolutely sure that there are no blank lines in the
file, as if there is, NO ONE will be able to log on.
BADNUMS.LST
-----------
This file contains a list of phone numbers in the format
xxx-xxx-xxxx. Any phone number that a user enters that is
contained in this list will not be allowed. If a user enters
a number that is in this list, a log entry will be made showing
'TWIT New User Phone'.
There is also a series of numbers that aren't allowed by
TPBoard itself. Any number with an area code of 800, a prefix
of 555, or a number that contains all the same numbers.
The processing described here will only be performed if the
'Force American format' option is turned ON.
TPBPATHS.1
------------
Once an optional configuration file, this file is NOW required
to tell TPBoard where your file areas are located. TPBPATHS
assigns FULL DOS paths as the locations of file area you've
set up for TPBoard. You must also have one TPBPaths file for
EACH node you are running: the first node (and non-network
version of TPBoard) uses TPBPATHS.1, the second node uses
TPBPATHS.2, etc.
The format of TPBPaths is: areaname=path.
Or, for example:
TPBOARD=D:\TPBOARD
In the above example, the location of the file area TPBOARD is
the path D:\TPBOARD. Up to 28 letters is recognized so file
areas can be nested directories:
TPBOARD=E:\DOS\TPBOARD
CONS will create the file for your first node after you have
entered the paths in File area editing and you must copy this
file for each node you are running and edit those files to
reflect the paths as seen by those nodes.
ECHORULE.TXT
------------
If this text file exists in an EchoMail directory, then the first
time that a user enters a message in that area (during EACH
login), he will be asked if he wants to read the rules for that
conference. This question will NOT be asked if the user has an
access level of > 250.
ORIGINS.BB#
-----------
All messages that are entered in an EchoMail area must have
an origin line appended to them. If you are using TPBoard to
export echomail and you want TPBoard to add an origin line to
your outgoing echomail messages, you must create a file called
Origins.BB#. The alternative is to allow your tosser to append
these origin lines.
An origin line should be similar to the line shown below. Be
sure that it will all fit on one line. TPBoard will automatically
add your Node and Net number to the end of the line.
Example origin line from ORIGINS.BB#:
The Board Room -- TPBoard Support
The line shown above would show up in the message as follows;
* Origin: The Board Room -- TPBoard Support (1:151/112)
For every echomail area, place an origin line in the ORIGINS.BB#
file in a foramt identical to the AKAS or TPBPaths file:
TPBOARD=Home of TPBoard 7.0
SYSOP18=The Board Room
Above, the areas are TPBOARD and SYSP18. The Origin lines for each
area follows the '=' character.
RO
--
If this file exists in an EchoMail area, then TPBoard will
treat the message area as Read Only for anyone below the Sysop
access level. This file can be 0 length or contain anything.
All TPBoard cares about is whether it exists or not.
CONF1.TXT .. CONF31.TXT
-----------------------
When a caller changes to an area designated as a conference,
TPBoard checks to see if THAT conference has a rules file in theSYSTEM directory. If the file exists, it will be displayed to
the caller the FIRST time the caller access ANY type of area
with that conference number. The file can contain any sort
of info.
VALIDUSR.TXT
------------
This is an optional file that will be made into a message
to a newly validated user IF the file exists in the TPBoard
system directory at the time the user is validated. This is
useful when you want all callers to see the same message upon
validation on your system. You can save space in your message
file if the text in Validusr.txt is a single line instructing
TPBoard's message reader to display a file. Confused? Look at
the following:
//SYSTEM/VALIDAT.FIL/
Any message that contains a line beginning with "//" is
considered to be a command to list the contents of a text
file. The text file must be in one of the File areas. The
file area is specified between the "//" and the first "/"
and the filename is between the "/" and the end "/".
So, if Validusr.txt contains a command to list another text file,
the resulting message would be only a single line added to the
message base. Yet, when the user reads that message, the contents
of the text file (VALIDAT.FIL in the example) will be displayed as
if part of the message itself.
QUOTES.TXT
----------
If you have created a file called Quotes.Txt, TPBoard will display
a random quote from this file to every caller at login.
STEP 3 -- Establishing the system organization ****************
By system organizaion, we mean setting up your Message, File,
Database, and Article areas. A program named CONS.EXE has been
included in the TPBoard distribution package. It will create the
system organization file named SECTION.BB#. In this new file
will be the minimum required message areas and file sections.
Later, the same program can be used to edit and add entries
as desired. Initially there are no conferences or Articles
provided, nor are they needed to get the system running. I
recommend that you use the minimum organization provided by
the setup program until the system is up and running and then
add to it as you grow.
To create the files necessary for the first run of TPBoard,
run CONS from your TPBoard directory. CONS will create several
configuration files used by TPBoard including the SECTION.BB#
file. Assuming you exit CONS by selecting SAVE/EXIT, the
new Section.BB# record will contain:
POST This is the MESSAGE AREA every user 'sees' initially.
The access level of this area will be set to zero
and should remain below any access level that your
assign to ANY callers. POST acts as the general or
public message area for a TPBoard system.
COMBINED This MESSAGE AREA is a special case. A user can set up
to 10 different message areas as "belonging" tothe
COMBINED area. After he's set up his areas, he can read
all messages entered in any of the selected areas at the
same time by selecting the area COMBINED.
BULLETINS This MESSAGE area is where the Sysop enters any
bulletins that he wants the users to see. It isn't
available for the users as a message area. They will
only see the text of the message when they read the
bulletins.
NETMAIL This is the Fidonet MESSAGE AREA for Netmail.
The FILES sub-system is a group of named 'FILE SECTIONS'
where files available for distribution (download) and receipt
(upload) are kept. Access to these Sections is controlled by the
minimum user access level set by the sysop. The Drive location
for each Section is sysop definable.
SYSTEM This FILE SECTION is the location for all of the
TPBoard system and data files.
LOGIN This is the FILE SECTION that, if it exists, a new
user will be placed on his initial LOGIN. The access
level of this area MUST be set to 20, the default
access level for unvalidated users.
NEWIN This is the FILE SECTION into which uploads will be
placed until approved for release by the sysop. The
access level of this section will be set to 20, the
default access level for unvalidated users. If you
do NOT have a LOGIN file section, then it MUST be
set to 20, as this is the area where new unvalidated
users will be placed on their initial login.
In addition to Message and Files areas, you can use CONS to
add/edit Articles, Doors, and Database entries.
Editing system areas in CONS
============================
Message areas
-------------
The four Message areas created by CONS (POST, COMBINED, BULLETINS,
and NETMAIL) are required by all TPBoard systems and can not be
removed. You can edit them, however, and you can add or delete
other Message areas to the overall limit of 255 Message areas.
The edit screen below displays Message area editing in CONS:
Edit Message Sections
────────────────────────────────────────────────────────────────────────
9 areas would require 945 bytes in TPBoard
Area name ARLOCAL·····
Area number 7··
Conf number 0··
Access level 50·
Purge level 200·
Description Local message area for Animal Rights.·············
Aka address 0····:0···· /0····.0····
Alt-I Insert new record Alt-D Delete this record
────────────────────────────────────────────────────────────────────────
Enter the name for this area.
────────────────────────────────────────────────────────────────────────
Area name This is the name of this message area up to 12 letters.
Area number The message area number is assigned by CONS and can not
be edited.
Conf number A conference number from 0 to 31. If assigned a conf
number, no caller can access this Message area unless
they have specific access to this conference NUMBER
assigned in their user record.
Access level This sets the minimum access level required to access
this Message area. Conference settings have priority
over access level requirements.
Purge level *IF* this is a FidoNet area, set this number to the
number of messages you want to allow to remain in this
area following a purge. Set this to 0 if this is NOT
a FidoNet echo area. DO NOT SET THIS TO ANYTHING
other than 0 unless this is an FidoNet ECHOMAIL area!
Description The description is shown to callers when selecting
message areas.
Aka address If this is an echo area and you are using an AKA, enter
it here.
When you assign conference numbers or high access levels to a
message area, you must consider who will be allowed to access
those areas. If you set an access level to 240, only a very
few will ever be allowed to access that area. Remember that 250
to 255 is considered a Sysop!
Also, don't set the access levels for all Message areas so high
that new callers can't get to at least one area of the board.
You can control the ability to enter messages in ANY areas by
setting various system settings.
Files areas
-----------
As mentioned, CONS establishes three FILES areas when first run:
SYSTEM, LOGIN, and NEWIN. You can edit or add additional areas
using the edit screen for Files Areas:
Edit Files Sections
─────────────────────────────────────────────────────────────────────
18 areas would require 1890 bytes in TPBoard
Area name ARLOCAL·····
Conf number 0·· Drive letter D
Access level 30·
Free downloads 255·
Description Files area for Animal Rights.····················
Full area path ······························
Alt-I Insert new record Alt-D Delete this record
─────────────────────────────────────────────────────────────────────
Enter the name of this file area
─────────────────────────────────────────────────────────────────────
Area name This is the name of this message area up to 12 letters.
Conf number A conference number from 0 to 31. If assigned a
conf number, no caller can access this Message area
unless they have specific access to this conference
NUMBER assigned in their user record.
Drive letter This is the drive where the file area is located. If
the drive letter is the same as the TPBoard system
drive, the file area will be created beneath the
TPBoard directory.
Access level This sets the minimum access level required to access
this Message area. Conference settings have priority
over access level requirements.
Free downloads If this entry is left at 0, callers WILL be charged for
downloads according to your selected charging/crediting
method. If this entry is anything other than 0,
callers will NOT be charged for downloads.
Description The description is shown to callers when selecting
message areas.
Full area path An optional setting, the contents of which come from
the file called TPBpaths.TXT. If this entry is NOT
blank, this must be the full path including the
directory name that is associated with this file
area. If this area IS blank, the file are will be
created as: Drive letter + :\ + Area Name
Database areas
--------------
If you are using TPBoard+, you can set up database areas for access
by your callers (see the section on FEATURES). A database area is
edited in CONS exactly like a file area:
Edit Database Sections
───────────────────────────────────────────────────────────────────
1 areas would require 105 bytes in TPBoard
Database name LIFELIST
Conf number 0··
Drive letter D
Access level 20·
Description Birds list·····································
Alt-I Insert new record Alt-D Delete this record
────────────────────────────────────────────────────────────────────
Enter the name of this Database (same as the .DBF filename)
────────────────────────────────────────────────────────────────────
All of these settings are the same as the equivalent settings for
Files areas with the exception of the AREA NAME. The name of a
Database area must be the same as the name of the database file
(the .DBF file) without the .DBF extension.
Articles
--------
Articles are NOT areas. Articles are actually text files that
the caller can display from the MAIN menu in TPBoard. Articles
are generally files containing special instructions for using your
board, rules for validation, lists of bulletin boards, the TPBoard
User Manual, etc. TPBoard handles Articles by expecting the
Article to be in a directory named ARTICLES on the drive designated
for that Article record.
A twist on Articles is the ability to have a parallel directory
for ANSI versions of the articles. When a caller selects an article
for viewing, if that caller has also selected ANSI screens, TPBoard
will look first in a directory named ARTICLEG (on the designated
drive) for a file having the article name before looking in ARTICLES
on that drive. Note that the ANSI version must have the same name
as specified in the Article record.
Edit Articles Sections
────────────────────────────────────────────────────────────────────
4 areas would require 420 bytes in TPBoard
Article name BBS0191B.TXT
Conf number 0··
Drive letter D
Access level 20·
Description Listing of local bulletin boards.··············
Alt-I Insert new record Alt-D Delete this record
────────────────────────────────────────────────────────────────────
Enter the name of this Article (the actual filename) ────────────────────────────────────────────────────────────────────
Doors
-----
Door records are created and edited nearly exactly as are Files
and Articles. The settings of a Doors record that correspond
to similar settings in a Files record won't be re-discussed here.
Note that the Door Name is the actual name of the file that
will be executed by TPBoard. This can be the .EXE for the door
itself or a DOS batch file.
Edit Doors Sections
────────────────────────────────────────────────────────────────────
2 areas would require 210 bytes in TPBoard
Door name BBSVIEW.BAT·
Conf number 0··
Drive letter D
Access level 20·
Door type 1
Description none··········································
Alt-I Insert new record Alt-D Delete this record
────────────────────────────────────────────────────────────────────
Enter the name of this Door.
────────────────────────────────────────────────────────────────────
The one setting to note is the Door Type setting. This tells
TPBoard what type of file TPBoard will write before calling the
door. A "0" means write the same DORINFO1.DEF file that
TPBoard 5.x wrote. A "1" means write a DORINFO1.DEF file that
is more compatible with RBBS. A "2" means to write a DOOR.SYS
file like the 'GAP" BBS writes (this one is becoming somewhat of
a standard). Check the documentation for the door you are setting
up for the type of DEF record it expects to find.
When you set up a DOOR, you are asked for a drive letter. The
batch file that you list must be located in a sub-directory
called 'DOORS' on that drive. If the TPBoard system is itself
located in a subdirectory, then the 'DOORS' sub-directory for
that drive will be below the TPBoard system directory.
Also, there are numerous utilities available that will take one of
the files that TPBoard creates, and convert it to another style
of text file. This will allow you to run many doors that are
written for other BBS systems.
When TPBoard shells out to the specified DOOR's batch file,
it does two things. It writes the file that you specified in
the DOORS subdirectory, and it passes a series of parameters
to the called program.
The command line parameters that TPBoard passes are as
follows;
1 Baud Rate
2 Comm Port
3 User First Name
4 User Last Name
5 Time Left
6 MNP Connect (0 for false, 1 for true)
7 ANSI Graphics (0 for false, 1 for true)
8 User Record number
VALIDATE.EXE is an example of a program that uses the above
parameters. VALIDATE is intended to be called from a batch
file to validate a caller following successful completion of
any of the available call-back validation door programs.
Written specifically for TPBoard, VALIDATE uses the User Record
Number to retrieve and update the user's record before returning
to the board from the door's batch file.
STEP 4 -- Establish the system security **************************
This step will depend on the version of TPBoard you are running.
Previous versions of TPBoard used the simple but effect method of
assigning access levels of 0 through 255 to each user in the
system.
System security using TPBoard+ is more flexible yet simpler from
the sysop's perspective. TPBoard+ uses 10 levels of validation
where every caller gets validated at one of these levels. Each
level is assigned it's own:
a validation level name
set of conference access bits
set of privilege flags
access level (0..255)
time on system (0..255)
While validation at one of the 9 levels (the 10th is the
unvalidated level) assigns the above to a user, the sysop
can edit the user's individual record and customize any of these
settings per user.
Privilege bits are the core of system security in TPBoard+.
Using privilege bit settings, every critical feature/command
of TPBoard+ can be enabled or disabled at the user level. Thus
you can turn off Chat (or any other feature) for all users
validated at XX level. In addition, if you select System menus
in CONS, TPBoard will display generated menus based on the
caller's privilege bits and the caller wouldn't even see commands
they don't have access to use!
In addition, areas can be assigned a conference number. A user
attempting to access any area that has a conference number must
have access to THAT conference specifically enabled by the sysop.
Validation levels are edited in CONS from the Setup70 menu:
Setup70 Utilities Database Fido/Nodelist Exit
─┌──────────────┐──────────────────────────────────────────────────
▒│ Configs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Areas │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Validation │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Setup utils │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ cOnsole cfgs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒└──────────────┘▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
After selecting VALIDATION, select the validation level you wish to
edit:
Setup70 Utilities Database Fido/Nodelist Exit
─┌──────────────┐───────────────────────────────────────────────────
▒│ Configs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Areas │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Validation │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Setup┌─────────────┐▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ cOnso│ Val level 1 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒└──────│ Val level 2 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Val level 3 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Val level 4 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Val level 5 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Val level 6 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Val level 7 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Val level 8 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ Val level 9 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Unvalidated │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒└─────────────┘▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
This above is the edit screen for editing a Validation Level.
Once in a validation level edit screen, you can transfer to the
previous and next validation levels by pressing [PgUp] and [PgDn].
Edit Validation Levels
────────────────────────────────────────────────────────────────────
Level name Val level 1·
Access level 0··
Access time 0··
Conferences 1234567890123456789012345678901
Privileges 1234567890123456789012345678901
────────────────────────────────────────────────────────────────────
Level Name - is any name you wish to assign to that validation
level.
Access level - is the access level (0..255) associated with this
Validation level.
Access time - is the number of minutes a person with this
Validation Level can spend on the system per day.
Conferences - the conferences to which a user will have access.
the conference "string" of numbers represents the
conferences 1 through 31; if a "+" is in a position
rather than a number, the user has access to that
conference. For a list of conferences, press Alt-L.
Privileges - working the same as the conference "strings," any
position that has a "+" instead of a number is a
privilege to which the user has access. For a list
of Privilege bits, press Alt-L.
When selecting conferences for a Validation level using the popup
list, any FILES area assigned conference numbers will be listed on
the left of the conference number and the MESSAGE areas will display
to the right. Those marked with arrows are those to which this
Validation level assigns access.
Edit Validation Levels
─────────────────────────────────────────────────────────────────────
╒═════════════ Confs ═════════════╕
│TPB 1 Unused │
│ Unused 2 Unused │
│ ARNEWS 3 Unused │
Level name Val level 1· │ ARTALK 4 Unused │
Access level 0·· │ Unused 5 Unused │
Access time 0·· │ Unused 6 Unused │
Conferences 12345678901234567│ Unused 7 Unused │
Privileges 12345678901234567│ Unused 8 Unused │
│ Unused 9 Unused │ │ Unused 10 Unused │
│ Unused 11 Unused │
│ Unused 12 Unused │
│ Unused 13 Unused │
│ Unused 14 Unused │
──────────────────────────────────╘═════════════════════════════════╛
ESC to quit list, to move the bar
ENTER, SPACE toggles functions
Marked functions are those which the user can access at this val
level
─────────────────────────────────────────────────────────────────────
When selecting privilege bits for a Validation level using the popup
list, those marked with arrows are those to which this Validation
level assigns access.
Edit Validation Levels
───────────────────────────────────────────────────────────────────
╒═══ Privilege Flags ════╕
│Message menu │
│Files menu │
│Doors menu │
Level name Val level 1· │ User/Utils menu │
Access level 0·· │ News bulletins │
Access time 0·· │Call the sysop │
Conferences 12345678901234567890│ dataBase menu │
Privileges 12345678901234567890│Sysop Menu │
│Toggle graphics │
│ Edit User data │
│List users │
│Read messages │
│Enter message │
│ Unused flags │
────────────────────────────────────────│ Make msg from upload │─
ESC to quit list, to move the bar ╘════════════════════════╛
ENTER, SPACE toggles functions
Marked functions are those which the user can access at this val
level
───────────────────────────────────────────────────────────────────
A sysop can validate callers in several ways. If you're running
TPBoard+, ALT-V will validate the current caller. You can also
validate when reading a message from a New CAller, or from the
Sysop's menu.
Additional system security takes the form of individual caller
flags or settings to enable downloads, disable chat, etc..
STEP 5 -- Edit TPBoard settings
Next, edit the various settings tha⌠ configure TPBoard to YOURsystem, hardware, and tastes. CONS is the recommended means
of editing these system settings. Run CONS and select SETUP70
followed by CONFIGS. You now see menu options for:
Setup70 Utilities Database Fido/Nodelist Exit
─┌──────────────┐────────────────────────────────────────────────
▒│ Configs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Areas┌──────────────┐▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Valid│ Board/Fido │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Setup│ Restrictions │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ cOnso│ General │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒└──────│ Features │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Modem │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Validation │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Hardware │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒└──────────────┘▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Select Board/Fido. These are the settings that specify the
name of your bbs, the name of the sysop, your Fidonet address,
and other settings. You'll need to edit each of these but first
press the [PgDn] key. Now you're at the edit screen for what
was the second option in the Configs Menu -- Restrictions. If
you press [PgDn] again you'll see that you can access ALL of the
configuration edit screens.
These 7 screens allow editing ALL
of the settings necessary to customize TPBoard. Some may not
require editing (the Comm port addresses, for example) but you
should at least go through these screens and read the
distribution settings. As you go from one setting to another
on any screen (press [ENTER]), the help lines at the bottom
of the screen will change to describe the current setting
begin edited.
Looking further at the CONS program, select the AREAS option
from the Setup70 menu. As mentioned above, this is where
you would add Message, Files, or any other areas.
The Validation menu option is where you edit the validation
levels for TPBoard+. CONS doesn't care which version of
TPBoard you're running so you'll be allowed to edit validation
levels even if your version of TPBoard doesn't recognize them.
See the section on System Settings for more info on editing
system settings.
STEP 6 -- RUN TPB to initialize system data files
The first time TPBoard is run, it will automatically create
all the data files that it needs in the system directory.
and will announce that it is doing so. If successful, the screen will clear and start randomly moving the
cursor around. This is the normal idle state for TPBoard. At this
time, TPBoard is waiting for:
1) A signal from the modem indicating a remote user call.
2) a command from the console indicating a local user. (^L)
3) a command from the console to show system status. (CR)
4) a command from the console to toggle Chat Enabled state
which overrides the current state. (F5)
Enter a CONTROL L (telling TPBoard that
you want to use the system locally). At the "Enter FULL name:"
prompt, enter the name "SYSOP." Do NOT use your first and last
name. Not finding SYSOP, the system will prompt for a password -
enter one of your choice. You are now logged into the system as
the Sysop with an access level of 255 (the max). If you want to
be on the system with your name, re-sign in after login as Sysop.
C A U T I O N !!!
-----------------
It is VERY IMPORTANT that you log in as sysop before putting
the system up for others to use. There are folks out there who
will try to log in as sysop. If you have not set your password,
they will set it for you and will consequently have full sysop
level access. THE FIRST USER LOGGING IN MUST BE THE SYSOP!
If TPBoard tells you that it is experiencing trouble initializing
the modem, wait for the screen to clear and press ^C to exit;
then check your modem settings and comm port assignment using
CONS.
Files that TPBoard has created and will use in the future:
MESSAGE.BB# The text of messages in the message file.
SUMMARY.DAT Message headers and pointers to the text in
the MESSAGE.BB# file.
SUMMARY.IX The B-Tree Filer index to SUMMARY.DAT.
USER.DAT The user file random record data file.
USER.IX The B-Tree Filer index to USER.DAT.
SECTION.BB# The system organization random record file.
LOG1.BB# ASCII log of system use.
STATS1.BB# Coded record of system usage by time & date.
NEWIN.DAT Records of Uploads & info about them.
NEWN.IX The B-Tree Filer index to NEWIN.DAT.
QUOTEIDX.BB# Index to QUOTES.BB# file.
CONFIG.BB# Sysops system specific configuration info.
LUSER1 ASCII file with name of last caller
LCALR# ASCII file with number of last caller
Other than SYSMSG.TXT, LCALR#, and LOG1.BB# file, these
files are not meant to be edited by the sysop with a text editor.
TPBoard has routines built in that will handle these files.
The LUSER1 text file is not used by TPBoard, but some
external programs such as mailers may utilize it.
In addition, TPBoard can create text files from the Message
file when the Audit feature is used by the Sysop. This will be
discussed in detail in the Theory of Operation Section of this
manual. In this way, you have the ability to generate a text file
from the random files shown above.
Be sure to test the system from a remote computer using a
modem, as this is the only way to be sure that the modem
dependent routines are working properly.
STEP 7 -- You're Done.
That's essentially all there is to setting up a TPBoard bulletin
board. Technically, you are up and running and waiting for
callers. You can now begin setting up the advanced features
such as XRS or Extended file info or you can take it easy and set
them up as you go along.
=======================================
3. TPBoard 7 -- Advanced Features
=======================================
Most of the features of TPBoard don't require additional
setup, the compressed message base for example, however,
some of them do. This section describes the necessary steps
to setting up and using the advanced features.
Menu Help screens
=================
TPBoard introduces help screens on every menu. The help screen
for each menu is handled via the Sysmmsg file as a normal TPBoard
screen with the following delimiters:
:3 Database menu help screen
:5 Main menu help screen
:6 Message menu help screen
:7 Files menu help screen
:8 Utilities menu help
Notice that every menu has a H)elp command available. This help
brings up a screen from sysmsg.txt specific to that menu. For
example, the H)elp command in MESSAGES brings up a help screen
for *ALL* Message commands or a generic help screen on using
messages. The user activates this by entering H and pressing CR.
However, should the user enter H followed
by any valid command from the current menu, TPBoard will display
a help screen specific to that command. So, each menu can have
a unique help screen and each command can have a unique help
screen.
Help screens for individual commands are delimited by appending
the command letter to the delimiter of that menus's main help
screen. For example, to figure out the delimiter for [E]nter
_Message on the Message menu, take the delimiter for the Message
menu main help screen ":6" and add the "E" for [E]nter_Message.
Thus, the delimiter for the [E] command would be :6E
Other than the unique delimiters, help screens are like all other
Sysmsg screens.
Editing Sysmsg files
====================
CONS contains a feature in the Utilities menu called Make_Screens.
This submenu provides four options:
Ansi in
Ansi out
Ascii in
Ascii out
The "out" menu options will take your complete Sysmsg files and
write each screen out to a separate file. Normally, you'd use
this feature more for editing ANSI screens than ascii ones. The
individual screen files are written to the screens directory you
specified in Setup70/Console_Configs.
The "in" options read ALL screen files from the screens directory
and create a NEW Sysmsg file from them. If you select Ansi_In
and there are only 2 .ANS files in the screens directory, your
new Sysmsg file will contain only those 2 screens!
Setting up for XRS
==================
TPBoard 7.1 has internal support for Mike Ratledge's XRS off-line
reader. M.R. has offered to provide a free registration key to
any sysop requesting one (see the form distributed with TPBoard).
If you aren't aware of just what XRS does, XRS allows users to
download bundles of messages in a fraction of the time
required to scroll them for capture. In addition, callers can
reply to messages on their OWN computers and upload the replies
to your system for processing by your own tosser.
Very little is required of you to enable XRS on your system. If
you have enabled ANY of the four compression methods for XRS (in
Setup70/Configs/Features), XRS is enabled on your system. Using
XRS begins when a caller selects D)ownload_XRS_Mailbag from the
Message menu. The following then occurs:
1) confirmation that the user really wants an XRS mailbag
2) selection of compression method desired
3) selection of message area or Combined 4) selection of protocol
5) TPBoard creates the mailbag
6) the mailbag is compressed
7) the mailbag is downloaded
Another option on the Messages menu is Upload_Mailbag. Uploaded
mailbags are identical to incoming FidoNet mail packets and are
handled just the same. The are uploaded by TPBoard to the incoming
mail directories for processing by your tosser and importer. You
will need to tell TPBoard where to place incoming
mailbags in the CONS program.
XRS mailbag compression is performed by batch files located in the
XRS mail directories. Wherever your message base is located,
create a subdirectory beneath that directory named for each node of
TPBoard you are running. For a single node system with the message
base in C:\TPBOARD, the XRS mail directory would be C:\TPBOARD\1.
This is the directory used by TPBoard to create the temporary files
that comprise a mailbag until the mailbags are compressed using
batch files created by CONS.
To create the directories and the necessary batch files (after
enabling all compression methods you will be using), select Setup70/
Setup_utils/XRS)_batch_files and CONS will do everything for you.
Note that one of the files required by an XRS mailbag is a file whose
NAME (the contents of the file are NOT used) represents your bbs in a
unique manner. I use a file called TPBOARD.XRS but you might want
MYBBS.XRS or whatever. Just so there's a file in the directory with
an extension of XRS that is unique in some way.
You can also edit the batch files to add a line that renames the
TPBOARD.?RS to a name more representative of your system. For
example:
REN TPBOARD.ARS 1-151-112.ARS
In this way, the caller will know your mailbag by the name just
by looking in his directory.
Setting up for Ascii Mailbags
=============================
Ascii mailbag downloads use all of the facilities of XRS mailbags
(the directories, the batch files for compression, etc) except that
the caller only gets one of the files that make up an XRS mailbag.
To prevent accidentally sending a caller any of the other components
of an XRS mailbag, we suggest that you add lines to the batch files
to DELETE all of the XRS created files other than Bat1Mail.XRS *or*
do the same following the compression line:
either: DEL SUMMARY1.XRS
DEL AREAS1.XRS
DEL ACCESS1.XRS
DEL USER1.XRS DEL MAIL1IDX.XRS
DEL MYBOARD.XRS
DEL MYBOARD.AXR
PKARC -A MYBOARD.AXR BAT%1MAIL.XRS SUMMARY%1.XRS
AREAS%1.XRS ACCESS%1.XRS USER%1.XRS MAIL%1IDX.XRS
MYBOARD.XRS
or: PKARC -A MYBOARD.AXR BAT%1MAIL.XRS SUMMARY%1.XRS AREAS%1.XRS
ACCESS%1.XRS USER%1.XRS MAIL%1IDX.XRS MYBOARD.XRS
DEL SUMMARY1.XRS AREAS1.XRS
DEL AREAS1.XRS
DEL ACCESS1.XRS
DEL USER1.XRS
DEL MAIL1IDX.XRS
DEL MYBOARD.XRS
The Database Feature
====================
The database function of TPBoard+ allows the callers to access
dBaseIII compatible files. Callers may create, view, and
download reports from dBaseIII compatible database files. A caller
may also ADD records to a TPBoard database.
Setting up a database means adding a Database area in CONS (just like
a Files or Message area). The area should have the same name of the
database file without the DBF extension. You must also create a
directory of the same name on the drive designated in CONS for this
database. Into this directory, copy the dBaseIII database file (the
.dbf file).
To access to database, the caller creates reports that must come from
a list of acceptable report formats created by the sysop. A report
format is a file with the extension SPC. Another file lists the
available .SPC files and provides a description for each of them;
this listing file ends with the extension .RPT.
To repeat, databases require the following:
A directory on the designated drive (just like FILES areas).
A database (.DBF) file with the SAME NAME as the directory
and the database area (without the DBF extension!)
A report format file (.RPT) containing the names of .SPC files
and descriptions. The .RPT file should also have the name
of the database but with an extension of RPT.
At least one .SPC file specifying a report layout.
So, the DBF file is the database itself. The .RPT file lists all
available SPC files, and the SPC files actually tell TPBoard the
structure of the reports. What do the RPT and SPC files look like?
The structure of the .RPT file is one line per item where each line
lists the name of an available .SPC file and a description of the
.SPC file. For example:
LABELS.SPC|Address label style list of Tpb users.
CITIES.SPC|Board Name, City, and State of Tpb users.
BBSNAMES.SPC|Board Name and phone ## of board
This .RPT file is used to provide a list to the caller of available
SPC files (formats for reports). The display looks just like a
Message_area_change listing. The text following the | letter is
the description.
SPC files are more complicated to create. The SPC file lays
out the report by specifying which fields (from the database) go on
which lines, starting in which column, and for what length, how many
lines to print out per record, etc.
For example, a sample section of a simple report might appear as:
LINESPERRECORD=1
HEADER=D:\TPBOARD\CITIES.HDR
9=1,1,30
4=1,35,30
5=1,65,7
According to this .spc file, this report would contain one line PER
record. The first XXX number of lines of the report would be a header
copied in from the file D:\TPBOARD\CITIES.HDR, and 3 fields should be
written out for each record written out. These field are positioned
within the single output line as follows:
9=1,1,30 means...
9 field number , 9 in the example
1 starting line, line 1 of this record (of the
LINESPERRECORD you specified!)
1 starting column for this field's output
30 length to print this field; if longer, no harm is
done,if shorter than the actual field, will cut it
off
Or, in other words: The first number is the field number of the
database field to write out, the rest of the command tells TPBoard
_where_ to write this field out. The "where" needs to contain
the line number (in the range of 1 to LinesPerRecord), the length
or columns to write out (this number doesn't need to the actual
length of the field as set up in the database), and the starting
column of where to write the field.
Actual data from this report might appear as follows when written
to the report file:
James Smith 22 State Street ME
9=1,1,30 produced the "James Smith" in column 1
4=1,35,30 produced the "22 State Street" in column 35, and
5=1,65,7 produced the "ME" in column 65, and
Two lines from the same report could appear as:
James Smith 22 State Street ME
James McDaniel 2452 Milburnie Rd NC
So you see, the SPC is an ascii file containing commands that
format the data from a dBaseIII compatible database. The above
database could also have been written out with one field per line
as (notice that we increase the number of lines per record to
three and use each line for a field):
LINESPERRECORD=3
HEADER=D:\TPBOARD\CITIES.HDR
9=1,1,30
4=2,1,30
5=3,1,7
which would produce:
James Smith
22 State Street
ME
James McDaniel
2452 Milburnie Rd
NC
Blank lines could be added between records by increasing the
LINESPERRECORD without placing any fields on the additional lines:
LINESPERRECORD=4
HEADER=D:\TPBOARD\CITIES.HDR
9=1,1,30
4=2,1,30
5=3,1,7
James Smith
22 State Street
ME
James McDaniel
2452 Milburnie Rd
NC
Available formatting commands are:
LINESPERRECORD=## where ## can be any number and is the number
of lines of output written out for EACH record of the database. A report with one line per record would
naturally be 1. Or, if I wanted one line per record
but with a line between each record, put 2 here.
HEADER=D:\TPBOARD\CITIES.HDR
Without the HEADER command, TPBoard will write out
the report starting at line 1 of the output file
begin created. Using HEADER, you can have the
contents of another text file written to the report
file before any records are written out.
LAYOUT commands take the form of:
field ## = line ##, column start, length
MERGE FILES
-----------
Other than the initial header file, the above .SPC files examples
only display information from the database. An additional command
in the .SPC file can instruct TPBoard to perform a sort of mail merge
using a text file containing embedded commands to print fields.
Where a standard .spc file lays out the data and this data forms the
report, a merge file report is a text file that YOU edit and the
contents of that file are reproduced for EACH record in the report.
Example, a .SPC file called LETTERS.SPC could contain one line:
MERGE=LETTERS.TXT
TPBOARD would read in and write out the contents of LETTERS.TXT
for every selected record in the database. TPBoard would scan
each line of LETTERS.TXT for imbedded field commands.
For example, instead of specifying fields as:
5=1,65,7
you would use commands embedded within the text:
User Name : ^[%1~
Address : ^[%2~
City : ^[%4~ Zip : ^[%3~
The line " User Name : ^[%1~ " is treated as actual text to
output to the report EXCEPT for the ^[%1~ which is a command to
output field #1 at the starting position of the leading ^ letter.
Additional commands available within a merge file are:
^[%DATE~ inserts the current system date at the specified
position. The format is MM/DD/YY
^[%TIME~ inserts the current system time at the specified
position. The format is HH:MM in military time.
^[%PGFD~ inserts a page feed character at the specified
position. Useful when printing letters.
^[%0~ Null string field. On a blank line, this will
create a CR/LF (a blank line);
Variations on individual field commands:
^[%4~ = print field 4 at the position of the ^ letter
^[%4:R2~ = print field 4 but right justify to a field
width of 2 letters.
^[%4:L7~ = print field 4 but left justify to a field
width of 7 letters.
^[%4:P30~ = print field 4 but pad to a field width of 30
letters.
Note: .hdr files used in standard .spc reports are treated
as merge files and can have the time and date fields imbedded in the
output.
ListUpdt NODELIST.DBF
---------------------
ListUpdt, described fully elsewhere, has an optional command /D to
create a .dbf of your nodelist file. You can then place a nodelist
database online for your callers. The following is a sample of a
printout from the NodeList database:
This was created by the internal database utilities of TPBoard
The Board Room Jim McDaniel 1:151/112 919/831-0674
BBS Name Sysop Phone Speed
====================== ===================== ============== =====
Horizon BBS Jason Balboa 1-919-555-3705 2400
Bert's Place Bert T. Muppett 1-919-555-4156 9600
David's BBS David Sysop 1-919-555-1205 2400
Mike's BBS Michael Sysop 1-919-555-5198 2400
The Board Room Jim McDaniel 1-919-831-0674 9600
If you have a Fidonet nodelist, you can create a nodelist database
and place a usable database online using ListUpdt. The above was
created using a .spc file similar to the following:
LINESPERRECORD=1
HEADER=D:\NodeLIST\Namelist.HDR
1=1,1,30
2=1,32,25
5=1,59,15
6=1,75,4
Note that we've deleted some of the blank columns from the report
to fit all the info within the margins of this page.
Database INFO files
-------------------
In addition to the Database menu Help screens that are available
for callers, you might want to place additional instructions about
a particular database online for your callers. The [I] command
on the database menu is for database Info. When a caller selects
the I)nfo command, TPBoard will display a file with the same
filename as the database with an extension of .INF. You can
use this file to display anything you want about the current
database.
Database EDT files
------------------
As of v7.1, callers can now A)dd records to a database. The
potential uses for this are numerous: extended login
questionaires, product ordering databases, bird sightings
for ornithologists, and much more. In order for TPBoard to
allow editing of a database, you must set up an .EDT file
similar to the .SPC files used to display data. Just as
you need to instruct TPBoard on HOW to display data, you
must tell TPBoard HOW to prompt for data.
In addition, the EDT file sets up security for database
access whether editing OR displaying data. Think about a
database that may contain sensitive data, such as a caller
database with phone numbers and ages. You might want this
information on hand for your own use but may not want other
callers to have access to one another's ages. You can avoid
displaying the information by not including the age field in
any spc files. Even if the data doesn't show up in any of
your report formats, *ALL* fields show up in the list of fields
when Filtering. Tricky callers would soon learn to F)ilter
on the age field by data range to narrow down ages of other
callers.
EDT files correct this problem by assigning access levels
to the individual fields of a database. You assign both
a Viewing access level and an Edit access level. Thus,
if a caller doesn't have access to View a field, that
caller will never see that field in Field lists, Filtering
commands, or even in report outputs regardless of spc file
formatting commands. You can effectively restrict selected
fields from caller access.
The Edit access level determines which fields callers can
edit during an A)dd. If no fields have Edit access, the caller
will not be allowed to edit any fields (they won't be allowed
to add records). In this way, an EDT file can be used to
add security to databases even without allowing callers to
add to a database. You might want a sysop level (>250) for
each field's Edit access for read-only databases. But note!
If a database has no fields that are to be restricted for
viewing and you aren't going to allow adding records to that
database, you don't need an EDT file for that database.
The format of an EDT file is LINE position specific. In other
words, once TPBoard had begun reading an EDT file and encounters
the first line of a definition for field XX, the other commands
must follow in specific sequence. This sequence is:
:FIELD ## where ## is the dBase field number
VACC ## min. access to view this field
EACC ## min. access to edit this field
MIN ## min. no. of chars, 0 for NO entry required
AUTO ## blank for none else ## of TPB field
RANGE1 ########### range start for range checking
RANGE2 ########### range end for range checking
PROMPT CCCCCCCCC prompt to ask for field entry
CCCCCCCCC pre-prompt text, line 2
CCCCCCCCC pre-prompt text, line 2
CCCCCCCCC pre-prompt text, line 3 and so on...
:FIELD ##
This label begins a definition for the specified dBase field by
the field number in ##. (The field numbers can be displayed using
TPBoard.) Any field(s) NOT set up in the .EDT file will be unaffected
by an edit; they will not be blanked, they will not be cleared out,
they will not be touched when TPBoard saves that record at ALL. If
you do not create a definition for a particular field, callers will
not be allowed to edit that field but WILL not be restricted from
viewing that field.
Thus, if you are setting up an EDT file to restrict access to certain
fields but aren't going to allow editing of ANY fields, just edit
definitions for those fields you want to affect.
NOTE!!!! Once TPBoard sees the label ":FIELD" in the first position
of a line, the other lines MUST follow in a specific order! If this
rule is not followed, your EDT file will be useless!
MIN ##
This label sets the minimum editing length for character fields such
as a name or city; the maximum is the dBase maximum for this field.
See range for numeric fields. IF Min is non-blank or greater than
zero, the user will not be allowed beyond that field without filling
in that field. If the user should be allowed to skip a question,
leave MIN as blank or set to zero.
AUTO ##
Some fields should not be edited by the user but should get data
directly from TPBoard. The label AUTO tells TPBoard _NOT_ to
prompt for this field but to fill the field with the value of ##
where ## is a numbered TPBoard value. Some of these values are:
1 Current Date as a character field in your selected date format
2 Current Time as a character field
3 Current Date as a dBase date field
5 Caller number
6 Caller's user record name
7 Caller's user record address
8 Caller's user record city
9 Caller's user record state
10 Caller's user record birthdate
.... and more as folks suggest them. The AUTO label should be used
whereever TPBoard can reliably enter data into a field to eliminate
possible user error.
RANGE1 ##
RANGE2 ##
Some fields should be checked according to a valid data range. For
example, a user's age should be between 1 and 99 (or maybe 12 to
99). Using RANGE1 and RANGE2, you can force user entry between
range1 and range2 where these values can be for any type of field.
LEAVE THESE labels blank for fields without data range checking!
A blank means NOT to validate data at THAT end of the range. This
label is intended primarily for numeric fields but will work using
the ascii sequence for character fields.
IF a range is in force, the appropriate entry depends on the field
type. For numeric fields, the entry could be:
RANGE1 1
RANGE2 9999
Which means that ONLY entries between 1 and 9999 will be allowed.
Logical fields can be Y,N,T,F (Yes = True and No = False).
UnInitialized logical fields are set to: ?
PROMPT CCCCCCCCC
This is the text that TPBoard should display when prompting
for data entry. CCCCC is any sequence of text up to 30 characters
and the field will be prompted (edited) 1 space after the end of
this text. For example,
PROMPT Enter your name> _
The cursor for user entry would be placed one space after the
last letter in the prompt string. If the edit length of a field
plus the length of the prompt is longer than the screen width,
data entry will begin on the next line.
CCCCCCCCC
CCCCCCCCC
CCCCCCCCC
You can have text displayed prior to prompting for the current
field by placing this text following the PROMPT label. Text begins
on the line following the PROMPT label and continues until the end
of the file OR the next :FIELD label begins a new field definition.
You can think of many times you've been asked for information where
the actual prompt was prefaced by warnings or instructions. You
do not have to enter this text, or you can enter as much as you wish.
SPECIFIC EXAMPLES:
:FIELD 1
VACC 250
EACC 0
MIN 2
AUTO
RANGE1 12
RANGE2 99
PROMPT Enter your real age >
We do not use your age for granting access to the bulletin board
however some areas of the bbs DO require that you be at least 18
years old. Your age will not be displayed to any other callers
and we will not make this information available to anyone else.
:FIELD 2
VACC 0
EACC 0
MIN 5
AUTO
RANGE1
RANGE2
PROMPT Enter your street address >
Your street address will not be disclosed but will be used to
verify your registration for validation.
:FIELD 3
VACC 0
EACC 0
MIN
AUTO 1
RANGE1
RANGE2
PROMPT
This would process as:
We do not use your age for granting access to the bulletin board
however some areas of the bbs DO require that you be at least 18
years old. Your age will not be displayed to any other callers
and we will not make this information available to anyone else.
Enter your real age > _
Your street address will not be disclosed but will be used to
verify your registration for validation.
Enter your street address > _
Explanation of Fields from above:
1) A numeric dBase field being used for age. Entry will be forced
between 12 and 99. The MIN is set to 2 so the user MUST enter
valid data into this field. The View ACCess for this field
means that only callers with access at sysop level will be
allowed to see data from this field.
2) A character dBase field being used for a street address. Users
will have to enter at least 5 letters. There is no data range
verification.
3) Field 3 is a character dBase field being stuffed automatically
by TPBoard with the current date.
Note in all examples that unused labels are still in their correct
position in the definition for each field. This is most important.
Also note that the text and prompt for fields 1 and 2 have a blank
line between text and prompt:
Your street address will not be disclosed but will be used to
verify your registration for validation.
Enter your street address >
Extended file info
==================
Initially, 7.1 was to include an increase in the size of the
description field for files. Rather than increase every Newin
record by one, two, or more lines for additional lines of file
descriptions, TPBoard now supports extended descriptions of
any length WITHOUT adding greatly to the Newin records. The
caller views this info from the F)ile_List command.
Using a utility named DESCCOMP (for Description Compiler),
or the Utilities/Desccomp selection from the CONS menu,
flat ascii files containing extended descriptions are linked
to the Newin records.
To use extended descriptions, each file area MUST have its own
description file all of which are located in the descriptions
directory specified in CONS. Then, for each file
area, create a ascii file with the name of the file area plus
the extension .BB# Example, in a directory named E:\FILEDESC
I place the following ascii files:
TPBOARD.BB# PJSTUFF.BB# PROGRAMS.BB# GRAPHICS.BB#
for the file areas:
TPBOARD PJSTUFF PROGRAMS GRAPHICS
You need only create these extended description files for
any areas you wish to add extended descriptions. If the
caller changes to a file area that doesn't have an extended
info file available, the caller is told that no extended
information is available. Further, not all files in a given
area need have an extended description in the descriptions
file.
Once the files are created, you begin adding extended descriptions
using a text editor. The format of an extended description file
is:
:TPBMSGS.PAK
line 1 describing tpbmsgs
line 2 describing tpbmsgs
line 3 describing tpbmsgs
etc.... up to any number of lines -- NO limits
:PJMSG.PAK
line 1 describing pjmsg.pak
line 2 describing pjmsg.pak
In other words, a colon followed by the filename followed by
any number of lines of text describing the file. Running
DescComp updates the Newin record for each file listed by
noting the position within the description file where the
extended info begins. ANY TIME you edit or alter the
extended description file, you must also run DescComp for
that file area.
If you have files that are permanently in the NEWIN file
area, the extended info file should be called NEWIN.BB#. If
you wish to add extended info for files still in Newin are but
destined for other areas, place the extended info in the info
file for the destination area.
A twist to this was added to support SDN files which are distributed
with text files called abstracts (files with the extension .SDA). The
abstract files act as extended descriptions and people familiar
with .SDN files are accustomed to "typing" the .SDA files for more
information on an SDN file. So, to automate handling of .SDN files,
DescComp (and CONS) can link the entire .SDA file as the extended
info for the accompanying .SDN file. Using this method, where an entire
file is the extended file description, the file MUST reside in the
file area along with the file being described.
The same ability applies to ANY file in ANY file area. Using
CONS/Newin_Processing, you can assign a text file as the extended info
for another file in the same area. If you wanted to assign the .DOC
that came in an archive as the extended info for that archive, select
Database/Newin, select the area, select the archive from the list,
and press F6.
An additional note on SDN processing. When processing an area
designated as an SDN area, any SDA files found that describe SDN
files that aren't yet in the NEWIN database, those files will be
automatically added to the NEWIN files database.
Private file transfers
======================
Simply by creating a file area called PRIVATE, you have enabled
the user-to-user file transfer feature. When a caller changes
to the PRIVATE file area, the only files that can be listed or
downloaded are any waiting specifically for that caller. The
caller can also upload files to any other caller.
This area acts in all other respects like any file area; access
is governed by the access level and any conference setting. A
conference setting is suggested as that will allow display of a
rules file when the caller first goes to that area just as any
other conference area. Note that a caller MUST BE IN THE PRIVATE
AREA either to upload or download from Private!
Any files uploaded to PRIVATE will wait for the addressee to
download them for the number of days specified by the Sysop
in CONS. If the addressee hasn't come for the files within
the maximum number of days, the files will be deleted.
The addressee is notified by a message in POST that files are
waiting. The sender is notified of the result of the transfer
(pickup or purge).
In local mode, the Sysop can place files _already_ in the
Private directory on hold for a particular caller(s) by
typeing the command HOLD at the Files menu. The sysop must
also be in the Private area to use this function.
Using Config.VAL
================
Many of the settings in the configuration record (Config.BB#)
that are set in the CONS program can also be set using a new
ascii configuration file. TPBoard scans the date of this file
on loadup, if Config.Val is newer than Config.bb#, Config.Val
is read and any settings NOT commented out with semicolons are
read in. Following a read of Config.Val, the Config.BB# file
is updated.
The Config.val takes the following form:
XRSPATH=C:\FD\FILES
In this example, XRSPATH is the name of the field which must
match what TPBoard expects exactly; the '=' separates the field
name from the value you are assigning to the field, and
"C:\FD\FILES" is the new value. MANY of the settings of TPBoard
can be set using this ascii file if you prefer dealing with an
ascii file.
Also, Config.val may configure some settings that are not yet
in the CONS program. These settings are generally discussed
in the README file. For a sample of a config.VAL, see the
distribution file named config.spl.
Setting up DOORS
================
Please note that TPBoard's authors cannot support software that
is written by other authors. We will NOT assist anyone in setting
up doors. If you need help in getting a door program running,
contact the author of the door. You are welcome to ask about a
specific Door program in the national TPBoard echo, just don't
call the support lines looking for help in setting up Doors.
If you have no clue what a Door is, a Door is nothing more than
another program run by TPBoard. That's really all there is. Let's
say that you want to run a Trekkie board and want to place the
Zrokon game online for your callers to play. Well, TPBoard doesn't
know anything about Zrokon so you'll have to tell TPBoard how to
run this program and you'll also need to create a means of making
Zrokon visible to callers from the TPBoard menu. This is called
a "door" from the BBS to another program -- your programs. Callers
select a door just as they would select a Message area.
There are many caveats in running Doors. The primary problem is a
matter of control; while TPBoard has been tested for years and
is a very stable communications program, we cannot vouch for the
behavior of anyone else's programs. TPBoard has to run this other
program with the expectation that everything will be returned
to TPBoard exactly as it was passed to the Door program. This is
not always the case and callers can get dropped, systems can get
locked up, etc.
Another problem with many "door" programs is that they aren't really
doors at all but regular programs being run as doors. These
programs don't handle carrier loss correctly and may sit and wait
for a caller's next command indefinitely. If a caller drops carrier
in the middle of running such a door, your system will be effectively
be locked up because the door doesn't know the caller isn't there!
You can gaurd against this sort of problem by running the public
domain program WatchDog. WatchDog constantly monitors the comm port
and reboots the computer if the carrier is dropped. You don't need
to run WatchDog all the time; just activate WatchDog in the first
line of your Door's batch file and turn it off at the end of the
batch file (so it isn't active when TPBoard comes back up). Advanced
fossil drivers also can be toggled to monitor the comm port.
Doors also create a security risk for bulletin board sysops. You
do not have control over system access while a caller is in a door
program as you do when the caller is in TPBoard. Many doors are
regular DOS programs that give the user FULL access to the system
and all system resources. Be VERY sure before your place a door
online that you are aware of what the door will allow the caller to
do.
ENABLING THE REMOTE SHELL TO DOS
================================
The Sysop's menu has a command "Shell to DOS" that will drop to
the DOS prompt when TPBoard is being run in local mode to allow
the sysop access to DOS commands. When the sysop calls in via
remote, this command is inoperable UNLESS you have enabled a
remote shell by creating a file called Remote.Bat. Within thisbatch file you must turn the system over to a CTTY device
such as Doorway.
If the file REMOTE.BAT does not exist in the system directory,
then the 'Shell to DOS' is only available while logged onto the
local console. If TPBoard is being run remotely, and the 'X'
command is given from the SysOp's menu, nothing will happen.
Here is a sample of a REMOTE.BAT file for someone that is
using the program DoorWay as their CTTY device.
@echo off
doorway com1 /a:on /b:x /c:dos /g:on /k /m:100 /o /s:*
/v:d /m:255 /p:
Remember, you are risking major problems if you implement
this feature. We STRONGLY suggest that you don't use it. If you
insist on utilizing it, you do so at your own risk.
IEMSI
=====
Interactive EMSI is a handshaking and data exchange protocol
desgined by Joaquim Homrighausen. IEMSI allows for the
background exchange of login data between a caller's terminal
package and TPBoard. TPBoard checks every remote login for
IEMSI capabilities.
When a caller logs in, he sees "Attempting IEMSI session, ESC
to abort..." At this time, he can press ESC and drop to the
login prompts. If he does not press ESC, and does not have
an IEMSI comm program, the cycle will take about 60 seconds.
Following a successful Iemsi session,
a caller eliminates all keystrokes and prompts before the
initial MAIN menu prompt. If the Iemsi session is successful
and the caller is NOT user in your User.dat file, TPBoard
will advance to the "Are you a new user" question.
TPBoard interprets the following IEMSI flags to mean:
NEWS - when enabled, this means that the caller wants to
check for bulletins. Along with this, TPBoard will
display the :B screen as well. If this is not
enabled, the caller sees neither.
MAIL - when enabled, TPBoard performs the new mail check.
ANSI,
AVT0 - when either of these is enabled, TPBoard uses the
ansi sysmsg file and colorized prompts.
CLR - sets the state of the callers clear screen between
menus flag.
FILE - will be recognized in v7.1 as requesting NEW files
during login.
REMOTED.BAT
===========
TPBoard supports the use of a full-screen ansi editor for remote
callers via a batch file called Remoted.bat. The mere presence
of this batch file in the system directory is all that is required
to enable this feature. Callers that select ANSI during login
will be asked if they wish to use the full-screen editor.
It is up to you to select and setup the ansi editor you wish to
use. Greg Ament (at 1:308/30) has written a program called ANSIEDIT
which works well with TPBoard and accepts ALL of the needed parameters
on the command line.
TPBoard will pass seven parameters to the remoted batch file for
those programs that can make use of them. These parameters are:
com port
work station number
time left (in minutes)
maximum message size
restricted
connect rate
color Y/N
To use AnsiEdit as my remote fullscreen editor, I call it in my
Remoted batch file by passing all the parameters:
ANSIEDIT %1 %2 %3 %4 %5 19200 %7 N
Note that I have permenantly eneterd the baud rate and color
select parameters because I have a mono monitor and am using a
locked rate of 19200.
In addition, TPBoard also writes a DorInfoX.Def file for remote
editors that are setup to run like door programs (such as TopEd).
==============================
4. Other CONS features
==============================
CONS is a sort of all-in-one utility for TPBoard sysops. As
discussed in earlier sections of this manual, CONS is the program
used to edit system settings, create XRS batch files, etc. But
CONS contains many more features to help the sysop manage
and maintain TPBoard. Some of these features are described
in this section.
Ascii Export
============
The Ascii Export is a feature of CONS that writes out the TPBoard
data files in an ascii format designated by you in a .SPC file.
While the basic structure of the SPC files ia the same as those for
database functions, the commands vary somewhat so read this section.
Also note that the ascii functions of the CONS program are identical
to those in the separate utility by Plain Jayne called PJASCII.
The difference between the two consists of PJASCII's ability to
be called from a batch file which allows manipulation of header
files, appending output files, etc. For complete documentation of
the PJASCII program, see PJASCII.DOC.
Ascii export creates a text file consisting of data from the selected
TPBoard data file. The information written to this file is selected
and formatted by the sysop in a file of instructions called a .SPC
(pronounced SPEC). This is handled by assigning every field in the
User and Newin records a unique field number. In the User record,
for example, the first field is the user's full name. PjAscii calls
the user_name field #1. Field 2 is the address (computer type), 3 is
the city, etc. Lists of these assignments follow below.
Taking these numerical assignments, you tell PjAscii where in the ascii file each field of each record is stored. The one restraint
is that the ascii file MUST have a set number of lines per record
and that each record MUST be laid out in the same manner. Two
examples of an ascii data file for the User file follow (using
only three fields):
Ex. 1 with 1 line per record
Jim McDaniel Raleigh NC
James Smith Bangor ME
Jon Bell SomeWherein OH
Jon Schneider El Paso TX
Ex. 1 with one field per line, 3 lines per record
Jim McDaniel
Raleigh
NC
James Smith
Bangor
ME
Jon Bell
SomeWherein
OH
Jon Schneider
El Paso
TX
The same four record were used to create the two formats of exported
data in the above examples. CONS knows where to write each field
in the output file by a series of commands, one command per line,
in the .SPC file. The .SPC files used to create the above output
from the USER file would be:
Ex. 1 with 1 line per record
LINESPERRECORD=1
1=1,1,25
3=1,36,20
4=1,55,2
Ex. 1 with one field per line, 3 lines per record
LINESPERRECORD=3
1=1,1,35
3=2,1,20
4=3,1,2
For a full explanation of these commands, see the section on
using the database functions above.
So long as each record is formatted the same, the records
can be in nearly any format, another example:
Jim McDaniel
Raleigh NC
James Smith
Bangor ME
Jon Bell
SomeWherein OH
Jon Schneider
El Paso TX
You probably noticed that these records don't have all of
the fields of a User record. CONS ignores (stuffs to
blanks) any field not specifically mentioned in the spec file.
Only those three fields would have any values.
Further, all of the fields of a user record are not assigned
numbers and therefore can't be written to an ascii file.
This is because some of the fields don't lend themselves to
ascii representation, such as the user flags. This may be
changed at a later date.
Note that ALL field specs MUST contain three parts
following the "=" character (even Constants). If CONS
encounters a bad spec line, it will halt.
The spec file can also contain a few commands in addition
to the field specifications. One of these, LINESPERRECORD
was used above. Each command and its use is outlined below:
LINESPERRECORD=?? Req.
?? Tells CONS how many lines to write for each record.
A user record can potentially fit on one line (if
you have an editor that handle it) as CONS allows
for lines up to 1024 characters long. You MUST
have LINESPERRECORD set as there is NO default number
of lines per record.
PADRIGHTBLANKS Opt.
By default, CONS trims all trailing blanks from
each field before writing out the record. You can
use PADRIGHTBLANKS to pad out to the designated
length of each field. This would only affect
records with one field per line and only when
exporting to ascii.
CONSTANT=#,?? Opt.
This command allows you to plug in a static (or constant)
value into each record written out. You may define up to 20constants. The # represents the number of this constant
within the range of 1..20 and the ?? represents the data
value of the constant.
CONSTANT=1,'No Description available'
CONSTANT=2,'Sysop'
On export, constant values can be used to place text within
the output as the output really doesn't overwrite TpBoard values;
i.e., constant #4 and field #4 can both be used in the same spec
file. In exporting, CONSTANT=3,'Name:' translates into:
3 = the constant number
Name: = the text that will be inserted wherever @3 is used
throughout the spec file.
Sample SPC file using CONSTANT values:
LINESPERRECORD=4
CONSTANT=1,'FROM:'
CONSTANT=2,'TO:'
CONSTANT=3,'AREA:'
CONSTANT=4,'DATE:'
CONSTANT=5,'RE:'
@1=1,1,5
3=1,7,25
@2=1,42,3
4=1,46,20
@3=2,1,5
2=2,7,20
@4=2,40,5
5=2,46,10
@5=3,1,3
6=3,5,66
Produces ....
FROM: Uucp TO: Jim McDaniel
AREA: Arnews DATE: 08-13-90
RE: The continuing dolphin wars
FROM: Uucp TO: Jim McDaniel
AREA: Arnews DATE: 08-17-90
RE: SPORT HUNTING: A Contradiction in terms
Note that @5=3,1,3 is valid while @5=3,1 is not even though
the length specifier has no purpose in a constant field.
Or, the above output could have been produced via a merge
file (see below), however, merge files must be read in for
each record of output.
Using a merge file
------------------
CONS can export data using a merge file rather than a
spec file for format instructions. The difference being
the spec file dictates straight data dumps, albeit, in a
user defined format, whereas a merge file is similar to a
mail merge function in a word processor. Confused? When
performing a straight data export via a spec file, only data
is written to the text file; when using a merge file, the
field position instructions are mixed into a file of text
which is also written out. Look at this example:
^[%DATE~
Hello ^[%1~,
Thanks for calling The Board Room. I see you haven't
been on since ^[%6~ and have only have an account
balance of ^[%9~.
System Operator
Jim McDaniel-Webb
The syntax for merged commands is:
^[%3:p17~ where
^[% denotes the starting column for a field
3 is the field number
: denotes a formatting command for this field
p is the formatting command to PAD
17 is the number of characters I want to pad Field #3
~ signals the end of the field command string
Available formatting commands are:
P : Pads field to number of spaces specified but leaves
field alone if longer than number of spaces.
L : Left justify, similar to pad but chops also chops
the field off at the specified number of spaces;
padding does not.
R : Right justify pads on the left side of the field
to the number of spaces specified and chops the
field off if longer than the number specified.
Special fields:
^[%DATE~ inserts the current system date at the specified
position. The format is MM/DD/YY
^[%TIME~ inserts the current system time at the specified
position. The format is HH:MM in military time.
^[%PGFD~ inserts a page feed character at the specified
position.
^[%0~ Null string field. On a blank line, this will
create a CR/LF (a blank line);
One word of caution when positioning fields: the ^[%
characters are not counted as spaces. I.E., CONS
looks for the starting position of the ^ character and
proceeds to delete the ^[% and all formatting commands
from the output string. The VALUE of the field is then
inserted. Any fields positioned after that will have
to take this shuffling into account. This only becomes
a problem if you're trying to line up columns as in the
file list example used above.
For example: ^[%3:p17~^[%1:L11~^[%8:p5~^[%6 tells CONS
to print 4 fields. You would expect field #3 to print in
column 1, but where do the rest print? Well, #3 is padded
to 17 characters. This gives us something like:
TPBEDNOD.PAS
Then, field#1 comes immediately after without any spaces;
however, the field is right justified to eleven spaces.
Now we have:
TPBEDNOD.PAS 5-16-90
^the end of line is here
Next is field#8 padded to 5 characters:
TPBEDNOD.PAS 5-16-90 5
Followed by #6 without formatting:
TPBEDNOD.PAS 5-16-90 5 No description available.
This merge file for a Summary file output...
FROM: ^[%3:l35~ TO: ^[%3~
AREA: ^[%2:l35~ DATE: ^[%5~
RE: ^[%6~
^[%0~
Creates this output PER record...
FROM: Uucp TO: Uucp
AREA: Arnews DATE: 08-13-90
RE: The continuing dolphin wars
Some of the examples above showed that you can achieve thesame output in different ways. This is not meant to be
confusing nor is it redundant. The Summary file export in
the explanation of Constants, for example, could have been
produced using a merge file. BUT, most merge file output
can not be produced using Constants! Moreover, if a merge
file were used in this case, the export would be slower.
Learning to align output, particuarly in merge files,
will take experimentation. Just work with it.
Field numbers Assignments
-------------------------
User File:
1 = user's full_name
2 = computer type
3 = city
4 = state
5 = phone
6 = date last on
7 = time on today)
8 = time on total)
9 = account balance in integer format
10 = pw
11 = last mesgarea
12 = last filearea
13 = access level
14 = access limit
15 = conf_flags
16 = uploads
17 = downloads
18 = protocol
19 = ratio
Newin File:
1 = date uploaded
2 = status
3 = name
4 = uploader
5 = section
6 = description;
7 = point value
8 = number of downloads
9 = date last downloaded
Summary File:
1 = area as a number
2 = area name
3 = from name
4 = to name 5 = date
6 = subject
7 = original zone
8 = original node
9 = original net
10 = original point
11 = destination zone
12 = destination node
13 = destination net
14 = destination point
15 = prev msg number of thread
16 = next msg number of thread
Newin processing
================
This feature of CONS is a powerful yet simple point-and-shoot
means of editing and manipulating the NEWIN files database.
Using CONS, you can move files into NEWIN, hide files, release
files, etc. Once you begin to use the Newin Processing, you
will realize how simple it is to maintain your files database.
When you first select Newin Processing from the Database menu
of CONS, you are given a list of all the file areas you have
created. Using the cursor keys (arrow keys), move the highlight
bar to the area you want to work in. Now press the [ENTER] key.
The screen will pause as CONS reads a list of all files in the
selected area (if there are any).
After the files are read in, the list you now see is a list of
all files in the selected area. The filenames are displayed
in three columns with additional information about the file area
displayed to the right of the list box. As you move the highlight
bar, the FILE information lines to the right of the list box will
change to display the file size, time, and date for the currently
highlighted file.
Press Alt-W now. The list box will change to use the full width of
the screen and the number of columns increases to 5 across. Press
Alt-W again to change the screen back.
The available commands are shown at the bottom of the screen in the
help box. Those commands are:
F1 - Sort Files
The list of files can be sorted by Name, Date, Size, Extension,
and Time. After pressing F1, you will select the sort method
from a list.
F2 - Show descrips
The listing of files does NOT access the Newin database;
rather, the list represents what is actually sitting in the
file area you selected. F2 will access the Newin database file as you move the highlight bar and will show the description
for that file near the bottom of the screen. F2 also will
display the file area listing in the Newin record for the
highlighted file. This last information is useful as files
aren't always in their proper directories, OR you may have
more than one copy of the file on you system!
F4 - Edit record
This selection lets you edit the Newin database record for the
highlighted file IF that file is in the newin database.
F5 - Shez on file
Although called the SHEZ command, this selection will process
whatever external DOS program you have set up in the Setup70/
cOnsole_cfgs screen. The program you have setup in Console
_Cfgs will be called with the highlighted filename as a
parameter.
F6 - Descrip File
If you don't understand what extended descriptions are, read
that part of this manual now. F6 instructs CONS that you want
to select an extended description file for the currently
highlighted file. You will then see a list box of the same
file area with all known non-ascii files disabled from
selection. Select the file that you want to use as an
extended description file.
F7 - Toggle Tags
Many of the commands available in Newin Processing can be
performed on more than one file at once by "tagging" files
as part of a group. Press the [ENTER] key and the current
file will be tagged. Tagged files are marked as tagged with
a triangle character next to the filename in the list box.
F7 will mark all files as tagged or all files as NOT tagged
depending on how many times you've pressed F7. F7 alone
does nothing other than mark files for group processing
using another command.
F8 - Unremark file
Similar to the SHEZ command, F8 runs an external program
passing the name of the currently highlighted file. The
program run using the F8 is setup in the Setup70/Console
menu.
F9 - Process files
This is the menu that provides options for processing the
tagged files. The processes you can run on tagged files are:
Move tagged files into database
All tagged files will be added to the Newin files database.
Any that area already in the Newin file aren't affected.
Unhide tagged files and make public
The HIDDEN attribute for the disk files is turned off (if
on) making the files visible during a RAW or VERBOSE Files
menu command. The Newin record status for the file is
changed from private to public (if it was private) allowed
the file to be downloaded.
Hide tagged files and make private
The opposite of the last option, this option hides the disk
files and marks them as undownloadable.
Remove tagged files from files database
The tagged files will be removed entirely from the Newin
files database. The disk file isn't affected.
Release tagged files
The same as unhiding and releasing except that the uploader
is also credited with the upload.
Delete tagged disk files entirely
This option deletes the tagged disk files without updating
any related Newin records.
Move tagged files to another area
Physically copies the disk files to another area and updates
the Newin records to reflect the area change.
IF the current file area is the NEWIN area, you can also YANK
all tagged files. This option performs a release, credits the
uploader, and copies the disk file to the destination file are.
F10 - Mark files
This option allows group tagging according to the Newin record
status of the disk files. You can tag all files that:
- are already in the Newin database file
- are in the database but aren't yet released
- are not in the Newin database at all
Alt-E - Ascii Editor
The editor program you have setup in the Setup70/Console menu
is called with the name of the current highlighted file passed as a command line parameter. CONS does not check to see if
the current file is editable as you may have an editor capable
of editing binary files.
Alt-I - Info toggle
This changes the files display from filenames only (in column
mode) to a full DOS DIR type of display. For example:
TPBBETA.PAK 10-31-91 06:11 275,546
CHAT1.PAS 08-27-91 14:55 11,490
You can change back to column mode by pressing Alt-I again.
Rebuild
=======
This option rebuilds the btree files used by TPBoard: the USER
file, the NEWIN file, and the SUMMARY file. This is not a necessary
routine to run with any regularity!
The data files used by TPBoard
are indexed using a method called a btree (it isn't important that
you understand what that means) that give TPBoard quicker access
into the data files (.DAT files) than a sequential search would
normally permit. After adding and deleting many records, it is
possible for a data file to develop "holes" that slow down access
and searching. For example, after deleting a user record, that
record creates a hole one record wide in the USER file. Over time,
these holes can amount to substantial disk space. Rebuilding data
files physically removes these deleted records from the data file.
The index files that accompany the data files also require rebuilding
from time to time. If your computer goes down when an index file is
opened, TPBoard may have to rebuild the indexes.
View headers
============
A simple routine to display the number of records in each of TPBoard's
data files.
Mailer count & Node flags
=========================
Only useful if you are a member of FidoNet, these two options scan a
selected NodeList file and report on findings according to the
option you selected. Mailer Count will list all the Fido nodes by
Mailer type while the Node Flags report lists ALL major flags by
the number of nodes capable of each flag.
Mailers Count creates a disk file called MAILER.### and Node Flags
creates a file called FLAGS.### where the ### is the same as the
extension of the nodelist file being processed.
View msg hdr
============
Only useful if you are a member of FidoNet, this option displays the
header information of a FidoNet format .MSG file. You will be given
a list of .MSG files from your NetMail directory.
Impmsgs
=======
Not intended to replace the stand-alone version of Impmsgs, this
option provides access to those Impmsgs features that a sysop
might desire to run on a selected basis (as opposed to a command
line basis in batch file processing.) The Impmsgs features
currently implemented in CONS are Renumbering, Exporting an area,
Deleting an area, and relinking the message base. For a description
of each, see the section on Running Impmsgs.
Sort AREAS
==========
Actually, all areas (Files, Messages, Artcles, etc) are sorted
alphabetically while in CONS anyhow. What this menu selection
does is sort the Message areas such that they will be sorted
alphabeticaly inside TPBOARD as well.
Normally, TPBoard sorts message areas by message area number --
that's a field that you can view inside CONS but aren't allowed
to edit. For example, if you added a new message area called
TPB_DEV, CONS would assign the next available (unused) message
area number to that message area. Thus, if number 14 is the next
available number, TPBoard will display TPB_DEV as the 14th message
area in message area change listings.
To alphabetize message areas inside TPBoard then, the areas must
themselves be numbered while alphabetized. Thus, if TPB_DEV
falls as the 40th message area while alphabetized, it will get
renumbered from 14 to 40. This process also requires updating the
Summary file for the new area number assignments.
One note, TPBoard requires that all systems have the minimum
four message areas: POST, BULLETINS, NETMAIL, and COMBINED.
This enforcement is by message area number -- you cant delete
a message area with a area number assignment below 4. The
Sort_AREAS option will not sort these 4 areas and they will
not display alphabetically!
Editing TPBmenus
================
One of the nicest yet simplest features of TPBoard is the ability
to use system generated menus. Although some sysops prefer to
draw fancy bordered screens; as a sysop, I really like seeing
crisp menus customized for each individual user.
TPBoard gets the display text for each menu item from the TPBMENUS
file(s) which the sysop can edit in CONS. Not only will CONS
allow you to edit the menu text, but you can edit the command
letters for every command as well. So, if you change the command
for "DOORS menu" to "PROGRAMS Menu," you might also change
the command letter from 'D' to 'P.'
BUT USE CAUTION! If you create a menu where the same command
letter is used more than once, only the first one will be
recognized! You can actually create menus with options that
users can't get to. If that command happens to be GOOBYE, your
callers will have no way to log off.
In addition, when updates of TPBoard come out, new commands
may have been added to the TPBoard menus. The TPBmenus file
that is distributed will contain these new commands but you
will probably not want to use the new file if you've already
taken the time to edit your existing menu files. If that is
the case, you only need to ADD the new commands in the
required position.
===================================
5. Running TPBoard 7 under a Mailer
===================================
If you don't understand EchoMail or Netmail, I'll attempt a quick
explanation. If you're familiar with mailers, you can skip
these first few paragraphs.
Without a mailer, your bulletin board is a closed system; all
messages originate and remain on your system. If your board is
files oriented, a closed system may be fine. But if you
want active message areas, the number of calls you can anticipate
even when very busy won't create busy message areas. By sharing
message areas with other systems, you can build your message base
by sharing the callers of other systems.
Imagine that you have a message area for Politics. Three of your
callers frequent the Politics area but the number of messages that
three folks can produce is minimal. So you decide to "share" your
message base with other systems. They will send you all new
messages in their Politics area and you'll also send them yours.
Along the way, you also need to ensure that you don't send to system
XX any messages that XX has already seen.
This is where a mailer and tosser come in. Every time a caller
exits your system after entering messages in an EchoMail area,
TPBoard writes those messages out in FidoNet format. These "new"
messages accumulate until you run your tosser. The tosser's job is
to create bundles out of the separate FidoNet messages to EACH
person with whom you are sharing message areas. Under normal
FidoNet operation, you'd forward all messages to your "hub" (like
the hub of a wheel) and he'd then forward them to all persons who
also want to receive them.
The mailer's job is to call each person with whom you're sharing
mail and to send any bundles waiting for them. When the mailer
sends outgoing mail, it also checks to see if any new mail is waiting
to come to your system. When new mail arrives, the tosser handles
the unbundling.
Finally, because TPBoard uses its own message base format, the
FidoNet messages must be imported into the board using IMPMSGS.
Impmsgs reads the FidoNet messages and ads them to the TPBoard
message base.
TPBoard is designed to handle messages that are in the
FidoNet standard format. It's own message base is NOT FidoNet
compatible, so it must be told if a message area is for use in
FidoNet when the area is created using CONS. This section covers
the necessary procedures for setting up FidoNet compatible message
areas and interfacing TPBoard with the utilities that handle
FidoNet mail.
TPBoard does NOT handle the creation of mail packets, routing,
or sending of mail to other systems. This is handled by an
external mailer program, which is run as a frontend to TPBoard.
The two that we am familiar with, and will cover here, are
FrontDoor and BinkleyTerm.
FrontDoor is available in both shareware and commercial versions.
It can be operated as a stand alone electronic mail package, or
can be used as the frontend to a bulletin board system. Information
on FrontDoor is available from: OCI, Inc. 22 State Street,
Bangor, ME 04401 201/941-1110
BinkleyTerm is a public domain mailer written by Bob Hartman
and Vince Perriello. It is available on most FidoNet capable
bulletin boards, and comes with complete source code in 'C'. It
requires several support programs in addition to itself, mainly
ConfMail and OMMM (both public domain and written by Bob Hartman).
If you want to participate in FidoNet, you must have a copy
of the mailer of your choice, and it must already be installed on
your system according to the instructions supplied with it. It is
up to YOU to obtain a network address from your network or
regional FidoNet coordinator.
I am going to make the following assumptions about your
mailer's installation. You have all of the mailer's command files
in a directory called 'C:\MAIL', and you have three directories
under it, 'MESSAGES', 'FILES', and 'OUTBOUND'.
I am also going to assume that you have TPBoard installed in
a directory called 'C:\TPBOARD', that COMMAND.COM resides in the
root directory on C: drive, and that your DOS path includes both
the root directory of drive C: and the MAIL directory.
Here is an example of the typical directory structure. It
contains three EchoMail areas in addition to the normal mailer
directories.
C:\
|__TPBoard
|
|__Mail
|__Files
|__Help ( NOT needed for Binkley )
|__Messages
| |
| |__Tandy ( one directory for each EchoMail area )
| |__Sysops ( one directory for each EchoMail area )
| |__Net_Dev ( one directory for each EchoMail area )
| |__TPBoard ( one directory for each EchoMail area )
|
|__Outbound
If your installation's directory structure is not the same
as that shown above, you will need to change the batch files that
I use in the following examples. The changes will be very minor.
The directories that you have set up only serve as temporary
holding areas for messages between the time that they are
exported from TPBoard and are packed by whatever echomail
processor you use, or are tossed by your processor and are
imported to TPBoard's message base. The NETMAIL directory is
where all outgoing mail is stored for delivery by your mailer.
TPBoard does not write messages in the FidoNet format. Any
message entered in TPBoard must be "Exported" before it can be
handled by any of the FidoNet utilities, or you need to run a
utility that knows about TPBoard's message structure. The same
applies to the "Importing" of FidoNet messages to TPBoard.
TPBoard itself handles the exporting is you set it up to do so
and IMPMSGS is supplied with TPBoard for the purpose of
importing messages. It is covered in detail later in this
document.
FrontDoor TossScan from Joaquim Homrighausen should be able
to directly import and export from TPBoard's internal message
base in the near future.
After adding EchoMail message areas, a separate subdirectory must
be created for each EchoMail area. These subdirectories must be
directly under the directory that was chosen as the location for
the NETMAIL area (usually the MAIL area). This directory is where
the tosser will "toss" the FidoNet format messages for importation
by Impmsgs. This is also where TPBoard will export outgoing
messages.
For example, if your mailers's message directory path was
'C:\MAIL\MESSAGES', then you would set up the NETMAIL area's
path as 'C\:MAIL\MESSAGES'. Then the path to an EchoMail
conference called 'TANDY' would be 'C:\MAIL\MESSAGES\TANDY'.
Once you have set up the necessary directories, run CONS,
and select the SETUP70/CONFIGS/FIDO sub menu. Then set the
paths listed to reflect your current set-up. The path to the
NETMAIL message area would in this case would be 'C:\MAIL\MESSAGES'.
The second path (The Network Lists) is the path to the two
files that are created when the ListUpdt utility is run
IF you run it with the option to create the TPBoard nodelist
files.
Whenever a user is logged into an EchoMail area, he will be
advised of the fact by the word 'ECHO' appearing in the message
prompt line.
TPBoard will exit with an error level of 2 if the user
entered an EchoMail message while logged on, a 1 if he entered a
NetMail message, and a 3 if he entered both. If no FidoNet
messages were entered, TPBoard will exit with an error level of
zero.
TPBoard and Some Mailers
------------------------
TPBoard expects two parameters passed to it by the mailer
that it is running under. It wants both the Baud Rate and the
Time to Next Event. Some mailers only pass one parameter, the
baud rate.
This presents a problem where you want to have the users
time limit adjusted for an upcoming event. If you just
arbitrarily passed TPBoard a large 'Time to Next Event' parameter
in the batch file, you have no way to make sure that there isn't
a caller on the board during National Mail Hour.
There's a fix that will work for most systems. Since the
starting time for macro execution has no purpose when you are
running under a mailer, you can set this value to be the starting
time of the National Mail Hour. Then in your BBS.BAT file, pass
TPBoard a 'Time to Next Event' value of 0.
When TPBoard sees a value of 0, it assumes that you have set
up your National Mail Hour Time in the Macro Start time, and will
adjust a callers time allowed on system to force them of at the
beginning of that time.
Speeding up TPBoard under a Mailer
----------------------------------
If you have a RAMDISK installed on your system, you can speed up
the loading of TPBoard when it's invoked from a mailer by a
substantial margin. Just do the following;
Modify your autoexec.bat file to copy TPB.EXE to the
RAMDISK.
Everywhere that you use the line TPB in your batch files to
invoke TPBoard, change it to (assuming your RAMDISK is G:)
CD\C:\TPB ; go to your TPB dir
G:TPB ; run tpb from the ram disk
Please note that this will work best if you are running DOS
version 3.1 or higher. If you are running an older version of
DOS, the overlays will still get loaded from the system
directory's copy of TPB.EXE.
If you are loading TPBoard from a RAMDISK, you can also turn
OFF TPBoard's use of EMS for its overlay files. This will actually
speed up TPBoard's performance while saving some EMS for other uses.
If you are running under a mailer and are loading overlays to EMS,
TPBoard must copy the entire 360k overlay file to EMS every time the
mailer drops to the board. When overlays to EMS is disabled,
TPBoard must load its overlay routines from the "disk file" on an
as-needed basis yet that loading is taking place from a RAMDISK! Thus, the actual "loading" of the bbs will occur much faster.
To disable loading overlays to EMS, run TPB as
TPB /toggleems
You can run this as often as you like and TPBoard will toggle this
setting with each run.
A disk caching program will also speed up TPBoards operation
considerably. I use a 1 megabyte disk cache and a 512k RAMDISK,
and the improvement in performance is noticeable.
BinkleyTerm Specific Installation
---------------------------------
In order to have TPBoard operate properly under Binkley,
everything must be run from a batch file. This allows Binkley to
call TPBoard once it determines that it has a human caller, and
it allows control to return to Binkley once the caller logs off.
The batch files also allow Binkley to pass control to other
external programs at pre-determined times. The files can get
quite complex, especially if EchoMail is going to be processed.
The first example used here is fairly simple.
Create a batch file called BBS.BAT, and place it in a directory
that is included in your DOS Path. I have mine placed in the root
directory of the C: drive. Once you have created the batch file,
you will always invoke TPBoard using the command BBS. Here is an
example BBS.BAT file.
SAMPLE BBS.BAT FILE
@echo off
:loop ; Keep coming here
c:
cd \mail ; Change to Bink's dir
cls
bt ; Invoke BinkleyTerm
if errorlevel 100 goto tpblocal ; F10 will log you on locally
if errorlevel 30 goto incoming ; Process any mail that arrived
if errorlevel 20 goto loop
if errorlevel 10 goto exit ; F1 will exit
if errorlevel 5 goto tpbmacro ; External Binkley event
goto exit
:tpbmacro ; Called as an external event
c:
cd \tpboard ; Change to TPBoard's dir
tpb 98 ; Invoke TPBoard, execute macro, and log-off
goto loop ; Rerun BinkleyTerm
:incoming
tosscan toss ; Unarc any arcmail
impmsgs -i -k -l ; Toss it into TPBoard's message base
goto loop
:tpblocal ; To log on to TPBoard locally
c:
cd \tpboard ; Change to TPBoard's dir
tpb 99 ; Tell it you want to logon locally
goto loop ; Return to Binkley
:exit ; Quit, and return to DOS
You also must create a batch file called SPAWNBBS.BAT. This
file will be placed in the 'MAIL' directory, and is what Binkley
will call to invoke TPBoard. Here is a sample SPAWNBBS.BAT file.
SAMPLE SPAWNBBS.BAT FILE
@echo off
cls
c:
cd \tpboard ; Make sure we're in the right dir
tpb %1 %3 ; Invoke TPBoard with rate and time to event
cls
cd \mail ; Switch back to Binkley's dir
; ; Now process outgoing mail with OMMM (all 1 line)
ommm -n -mc:\mail\messages -hc:\mail\outbound
-ic:\mail\binkley.prm -cc:\mail\ommm.ctl
For OMMM (Opus Matrix Mail Masher) to operate properly, you
must have created a file called 'OMMM.CTL', and let OMMM know
where it is located. It is the routing file used by OMMM, and is
covered in detail in the OMMM documentation. The following sample
is the bare minimum OMMM.CTL file that is needed.
SAMPLE OMMM.CTL FILE
Route
; Daytime schedule
Sched A
OMMM must also know where it's PRM file is located, and what
it is called. In this case, we use BINKLEY.PRM, and how it is
created will be covered in the section on Binkley's CFG file.
It is absolutely necessary to have OMMM, as without it, youroutgoing mail will never be processed for sending by Binkley. It
can be found on most any board that carries Opus. To process your
incoming mail, you will need CONFMAIL, and it can almost always
be found where you found OMMM.
It is also necessary to configure BinkleyTerm by using the
BINKLEY.CFG file. I have included a sample CFG file on this page.
It can be much more complex than the example, but I'm trying to
keep it as simple as possible for first time users.
SAMPLE BINKLEY.CFG FILE
; Binkley.CFG -- configuration file for BinkleyTerm 1.16 and above.
;
Port 1
Baud 2400
Carrier 80
;
Init |ATZ|~ATV1Q0X1E0F1S0=1|
Prefix |ATDT,
Autobaud
Busy |ATM0H1|
;
Zone 1
Boss 1/302
Bossphone 1-915-592-4976
Point 1/302
Nodelist C:\Mail\
Hold C:\Mail\Outbound\
Netmail C:\Mail\Matrix\
Netfile C:\Mail\Files\
System Rio Grande ROS-Net
Sysop Jon Schneider
;
Statuslog C:\Mail\Binkley.Log
LogLevel 5
Unattended
Reader Mail
Unattended
MaxReq 40
Banner Rio Grande ROS-Net #49
;
BBS Spawn
Timeout 20
Event All 00:01 02:00 L B E1=20 E2=30 ; Local Mail
Event All 02:00 03:00 N E1=2 E2=30 ; No reqs/BBS during NMH
Event All 03:00 23:59 C B E1=20 E2=30 ; Crash Mail
;
After configuring Binkley, run the program BTCTL, and it
will create the BINKLEY.PRM file that OMMM needs.
The setup shown here is a minimal FidoNet setup. It doesn't
include any EchoMail conferences or automated processing. We would
recommend it as the setup to be run when fist attempting to run
your system in the Net. Once you are sure that everything is
running properly, you will more than likely want to expand the
setup.
FrontDoor Specific Installation
-------------------------------
In order to have TPBoard operate properly under FrontDoor,
everything must be run from a batch file. This allows FrontDoor
to call TPBoard once it determines that it has a human caller,
and it allows control to return to FrontDoor once the caller logs
off.
The batch files also allow FrontDoor to pass control to
other external programs at predetermined times. The files can
get quite complex, especially if EchoMail is going to be
processed. The first example used here is fairly simple.
Create a batch file called BBS.BAT, and place it in a
directory that is included in your DOS Path. I have mine placed
in the root directory of the C: drive. Once you have created the
batch file, you will always invoke TPBoard using the command BBS.
Here is an example BBS.BAT file.
SAMPLE BBS.BAT FILE
@echo off
:loop ; Keep coming here
c:
cd \mail ; Change to FrontDoor's dir
cls
fd ; Invoke FrontDoor
if errorlevel 39 goto tpblocal ; ALT F1 will log you on locally
if errorlevel 35 goto tpbmacro ; External FrontDoor event
if errorlevel 34 goto bbs ; 2400 baud caller
if errorlevel 33 goto bbs ; 1200 baud caller
if errorlevel 32 goto bbs ; 300 baud caller
goto exit
:tpblocal ; To log on to TPBoard locally
c:
cd \tpboard ; Change to TPBoard's dir
tpb 99 ; Tell it you want to logon locally
goto loop ; Return to FrontDoor
:tpbmacro ; Called as an external event
c:cd \tpboard ; Change to TPBoard's dir
tpb 98 ; Invoke TPBoard, execute macro, and log-off
impmsgs -i -k -l ; Import messages and relink
goto loop ; Rerun FrontDoor
:bbs
dobbs
goto loop
:exit ; Quit, and return to DOS
You should also create a batch file called EXEBBS.BAT. This
file will be placed in FrontDoor's 'MAIL' directory, and is what
FrontDoor will call to invoke TPBoard. Here is a sample EXEBBS.BAT
file. REMEMBER, you must let FrontDoor know that you want it to
invoke the BBS in batch mode by setting the 'create batchfile'
option to 'Yes'.
SAMPLE EXEBBS.BAT FILE
echo off
cls
c:
cd \tpboard ; Make sure we're in the right dir
tpb %1 %3 mnp %4 ; Invoke TPBoard with baud rate and time to event
cls
cd \mail ; Switch back to FrontDoor's dir
bbs ; Return to main batch file
The setup shown here is a minimal FidoNet setup. It doesn't
include any EchoMail conferences or automated processing. We would
recommend it as the setup to be run when fist attempting to run
your system in the Net. Once you are sure that everything is
running properly, you will more than likely want to expand the
setup.
In the examples shown on the previous pages, TPBoard was
called with parameters. What the parameters are will determine
what TPBoard does upon being invoked. If it is invoked with two
parameters, and the first parameter is a valid baud rate, then it
assumes that carrier has already been established, and that the
first parameter was the baud rate, and the second parameter is
the time in minutes until the next MAIL event.
TPBoard will examine the 'Time Till Next Event' parameter,
and if it is less than the callers allotted time, it will adjust
their time downwards, and let them know that an adjustment to
their time allotment was made.
If the first parameter is a 99, then TPBoard will assume
that you want to log on locally, and will exit to DOS when you
log off. If the first parameter is a 98, then TPBoard will logon
as SYSOP, execute the pre-configured macro, and then exit back to
DOS. This is the ONLY way to get the macro to execute
automatically if you are running TPBoard under a mailer.
TPBoard also supports cost accounting. When the Nodelist is
compiled using XLATLIST or PARSELST, and the CTL file is set up
properly, each node entry in the nodelist will have a cost per
message field. This figure is used by TPBoard everytime a user
enters or replies to a message. ListUpdt (the separate utility)
will also add a cost field to nodes when compiling the TPBoard
nodelist files.
The user is allowed to enter messages to any node that is
set up as being free, but unless the user has a positive account
balance greater than the cost of the message, he cannot enter a
message to a node that requires a toll call.
The SysOp can change the users account balance from the
<E>dit users menu, and the user will be shown his current balance
whenever he logs in. This allows the SysOp to allow selected
users to send mail to any node, and still allows all other users
access to any of the local nodes. You also have the option of
not charging users for Netmail at all.
IMPMSGS.EXE
===========
Impmsgs is the message import and maintenance utility provided
with TPBoard. Impmsgs is a command line utility that expects
all options to be specified at the DOS prompt when Impmsgs is
executed. The available options are:
-i Import messages. This option searches through all external
message areas importing new messages into the internal
TPBoard message base. Depending on the -k switch (discussed
later) the original FidoNet messages are either deleted as
they are imported, or simply marked as having been imported.
Impmsgs does NOT check for 'garbaged' messages.
-f For FAST indexing during importing. Normally, each message
is fully indexed as it is added. The -F forces IMPMSGS to
add ALL new messages and to do the indexing following the
import. This will speed up the import process but is
more dangerous as you could potentially get messages
imported that have incomplete indexes for access should
your machine go down during an import.
-co For COMPRESSed message bases. TPBoard+ has the feature of
compressing the message base. If you ARE using a compressed
message base, as selected in CONS, you must import messages
with this option.
-ri Used along with -I, -RI forces ALL FidoNet messages found
in the message directories to be imported regardless of
whether they're marked as having been previously imported.
-x Used with the -I option to import, -X signals that messages
tossed from an XRS mailbag are being processed. Callers
can respond to messages in non-EchoMail message areas using
XRS and the -X option forces IMPMSGS to extend its search to ALL areas. Naturally, you would have had to establish
directories for these areas as well.
-k Kill messages. This switch works in conjunction with the
import option. If this flag is present, each message
imported is deleted from the directory area. Unless you need
to keep the messages in the external area for some reason,
this switch should always be used with the -i switch.
-n Used with the -K option to prevent killing of imported netmail
messages.
-l Link reply threads. This switch causes IMPMSGS to re-link
the reply threads in the message base. The TPBoard internal
areas are not changed, but the netmail and echo area
messages are linked to each other based on subject.
Ideally this switch is included with the -i switch so
messages are linked as soon as they are imported, but this
option may be run at any time you want to insure the
message base is reply-linked. Because of the way the
linking is done, this option is relatively fast, and may
be used with every import.
-fl Forced re-link. This option will completely re-link your
message base and should be used when you suspect a problem
with message threads.
-rn Renumber message base. TPBoard can support message numbers
up to 65,535. As your message base grows, messages will be
deleted and purged, creating 'holes' in the message base.
This option basically packs the message base, so the message
numbers are sequential again. Your message base activity
will determine how often you will need to use this option.
ALL bulletin board systems requiring renumbering, TPBoard
excels in this area.
-q Perform a reindex of the message base data files.
-da Used to delete all messages in a given message area. For
example, -DApolitics would delete all messages in the area
POLITICS.
-ea Used to export all messages from a given message area. For
example, -EApolitics would export all messages in the area
POLITICS. You would use this option to archive an entire
area. You would NOT use this option to perform a normal
export of new messages.
-de Used with -EA to DECOMPRESS as exporting. Otherwise, IMPMSGS
will assume a non-compressed message base.
-mp Used as -MPpolitics, Impmsgs would go through the Politics
area marking all messages as private.
-up The opposite of -MP, -UPpolitics would go through the Politics
area marking all messages as public.
-a ONLY used if you are importing with another Importer which can
not perform indexing in the btree files. NO NOT RUN this
option if you are importing with IMPMSGS.
-net##
where ## is the node number for Impmsgs to use. Impmsgs will
import newly tossed mail without taking down your other nodes
if you use this NET option. Note that ONLY importing (-i) will
work in network mode.
Running Impmsgs -
Impmsgs should be run after any new net or echo mail is.
Since most mailers allow an exit upon receipt of
incoming mail, this should not be a problem. Typically,
you would setup your batch files to both toss and import
mail on receipt.
To import incoming mail to the TPBoard message base,
the recommended command line is:
Impmsgs -i -k -l
This line tells Impmsgs to import new messages, kill the
messages after they are imported, and re-link the message base.
If you need to retain the messages in the .MSG format for any
reason, remove the '-k' from the command line. If you do not
have Impmsgs automatically kill the .MSG file, you will need to
manually erase the messages in each area.
Your message base should be renumbered anytime your highest
message number starts approaching 60,000. It can be renumbered
sooner than this, but unless you have a very active message base,
there isn't much reason to do this. The command line to perform
renumbering is:
Impmsgs -rn
Renumbering makes the message numbers sequential again. For
example, following a purge of old messages, the first message
in the message base might be message #2050. After renumbering,
the first message would be message #1, the second will be
#2, etc.
All reply-threads are maintained after renumbering, so there
is no need to explicitly perform re-linking after a renumber.
As messages are entered on your system, they are exported to
the respective message directories to be processed by your
message packer. Netmail messages should not accumulate, as they
are flagged as 'kill-sent' at export. Exported echo messages
will remain in the directory until you remove them.
Origin Lines
------------
See the section above on the file called ORIGINS.BB#.
Impmsgs on a network
--------------------
Impmsgs may be run on a network while all nodes remain up and
active. This is a distinct and important feature of TPBoard;
with many other boards, you must wait until all nodes are
idle to process incoming echomail.
To run Impmsgs on a network, simply run Impmsgs with the
additional argument -NET## where the ## is the node number of
the current workstation. Impmsgs will the read your TPBoard
NodeCfg file for that node to make necessary adjustments to
message area paths. Note that the only Impmsgs command you
may perform with -NET specified is importing; any other
options will cause Impmsgs to exit without processing!
If mail is received while a node is active, that node will
be aware that new mail has been procesed and will inform the
current caller of this fact. TPBoard will then ask if the caller
wishes to scan for new mail (just like the login scan).
=======================================
6. SYSTEM SETTINGS
=======================================
Once you are sure that the system is working properly, it is
necessary to set up all of your system specific defaults. You
will do that by using the CONS program. You will want to at
least read every setting to ensure that you don't want to
change it or that the default value is something you can live with.
You can read this section or enter the CONS program and read the help
lines provided for each setting.
Upon entering the CONS program, select the first menu option
called SETUP70.
Setup70 Utilities Database Fido/Nodelist Exit
─┌──────────────┐───────────────────────────────────────────────────
▒│ Configs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Areas │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Validation │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Setup utils │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ cOnsole cfgs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒└──────────────┘▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Now, select the first option on the Setup70 submenu called Configs.
The Configs submenu has the following options:
Setup70 Utilities Database Fido/Nodelist Exit
─┌──────────────┐───────────────────────────────────────────────
▒│ Configs │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ Areas┌──────────────┐▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Valid│ Board/Fido │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ Setup│ Restrictions │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒│ cOnso│ General │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒└──────│ Features │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Modem │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Validation │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒│ Hardware │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒└──────────────┘▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Once you select any of the above, you can access the others by
pressing PgDn or PgUp. Or, you can ESCape from that edit screen
and select the other one you wish to access.
The following describes each setting on each screen in the format:
Edit_screen_prompt
------------------
Descriptions and caveats on usage.
Default value
Now we'll begin a discussion of every setting under Configs going
screen by screen and setting by setting.
Board/Fido Settings
===================
Board and Fido settings
────────────────────────────────────────────────────────────────────
Board's Name.... The Board Room·····················
Sysop's Name.... Jim McDaniel·······················
Sysop Password.. ········
Fido address.... 1···:381·/23··.0···
Node List path.. C:\MAIL··········································
Fido Mail path.. C:\MAIL\MESSAGES·································
Message path.... ·················································
Macro string.... X;P;A;S;NEWIN;G··································
────────────────────────────────────────────────────────────────────
Name of Your BBS
----------------
Enter the name of your Bulletin Board system here. It is
used for the 'Doors' function and is written at the top of the
System.DIR file.
Def: The Board Room
Sysop's Name
------------
This is the name to be used in place of SYSOP in all message
areas. If a message is entered in a TPBoard message area to the
person who's name is listed here, it will be readdressed to them
as 'SYSOP'.
It's also used to remap YOU to the user record for 'SYSOP'
when you log in using the name entered here. This field MUST be
set up correctly, or many TPBoard functions will not work
correctly.
Def: Jim McDaniel
Sysop Password
--------------
This will normally be left blank. If you allow other people
access to your local console, but you don't want them to have
Sysop privileges when they are logged on locally, then set up a
password here. No one will be allowed entry to the Sysop menu or
Setup program unless they enter the password that you set here.
Def: blank
Fido address
------------
Only important if you are using the FidoNet functions. This
is your full fido address including zone:net/node.point.
Def: 1:151/112.0
Node List Path
--------------
Only important if you are using the FidoNet functions. This
is the complete path to the directory where you store the
TPBNCOMP compiled node lists, including the drive, and WITHOUT a
trailing '\'.
Def: C:\FD\NODELIST
Fido Mail path
--------------
Only important if you are using the FidoNet functions. This
is the complete path to the network message area, including the
drive, and WITHOUT a trailing '\'.
Def: C:\MAIL
Message Path
------------
The message files are perhaps the most dynamic data files used
by TpBoard. Because the size of your message base is
unpredictable when you first set up TpBoard, you can relocate the
message files to another disk\directory via this setting. The
initial setting is blank, which will place the message files in
the same directory as TPB.EXE. If you use many of the available
utilities written for TpBoard, you should include the full path
here (TpBoard knows in which directory it is being run--utilities
can be informed of TpBoard's path via this setting.)
Def: blank
Macro string
------------
This is the macro command that TPBoard will execute unless
you have a separate MACRO.LST file whenever a timed macro is
executed.
Def: X;P;A;S;NEWIN;G
ANSI Question
-------------
The first prompt asked of callers is whether they wish to use the
alternate SysmsgG file. Ordinarily, this question would prompt
for whether the user desires ANSI screens but TPBoard has no way
of knowing what you are using the SysmsgG file for. A "yes" to
the question you enter here will cause TPBoard to display screens
from the Sysmsg file.
Def: Do you want ANSI color graphics?
Restrictions
============
These are various and non-related settings that establish purge
limits, disk protections, operational hours, etc.
Restrictions/Limits
────────────────────────────────────────────────────────────────────────
Allow chat requests? ....(Y/N) Y Restrict 300bd callers (Y/N) Y
Chat start time (hour) ....... 0··· Start 300 restrict (hour) .. 17··
Chat end time (hour) ......... 24·· End 300 restrict (hour) .... 24··
Extra mins at slow hrs? .(Y/N) Y Max password attempts ...... 4·
Extra time start (hour) ...... 2··· Keyboard input timeout ..... 300·
Extra time end (hour) ........ 6··· Hour to begin auto macro ... 4···
Extra time to add (mins) ..... 20··
Min space to allow uploads ... 50·· Min space to allow new users . 25·
Space to restrict msg size ... 20·· No. Lines for restricted msgs. 10·
Min space for all operations . 5··· Max message lines usually .... 100
Hide files as uploaded ..(Y/N) Y
────────────────────────────────────────────────────────────────────────
Allow chat requests
-------------------
A toggle that when OFF prevents all attempts for callers to
chat with the Sysop. The caller is told that the Chat function is
not active. When the toggle is ON, the Chat function responds to
the limits set in the following values.
Def: True (ON)
Chat start time (hour) & Chat end time (hour)
---------------------- --------------------
The hours during which the Sysop will be paged on the local
system console. Outside of these hours the caller will be told
what the Chatting hours are, but no paging of the Sysop will be
done. These settings are in whole hours only, no minutes. All
values for hours use a 24 hour notation (0-24).
Def: 0,24
Restrict 300bd callers (Y/N)
----------------------------
This toggle when ON will not accept callers at 300 baud
between the preset hours. After connecting with the system they
will be notified of the hours when 300 baud calling is
restricted, then TPBoard will hang up. When OFF no restrictions
will be applied to 300 baud callers.
Def: False (ON)
Start 300 restrict (hour) & End 300 restrict (hour)
------------------------- -----------------------
The hours (0-24) during which restriction of 300 baud callers occurs.
Def: 17,24
Extra min at slow hrs (Y/N)
----------------------------
This toggle when ON and a call is received within the hours
set, adds extra time (in minutes) to the caller's time allowed on
the system (per day). This is done at the beginning of the
session. When OFF, nothing happens.
Def: True (ON)
Extra time start (hour) & Extra time end (hour)
----------------------- ---------------------
Between these hours, if the function is enabled, the users
time limit will be increased by the number of minutes set below.
Def: 2,6
Extra time to add (mins)
------------------------
This is how much time (in minutes) will be added to the
users daily time limit during the above times.
Def: 20
Max password attempts
---------------------
The number of times TPBoard will allow a user to attempt
password or name entry. If this number is exceeded, the system
will disconnect with a message.
Def: 4
Keyboard input timeout
----------------------
This value sets the time (number of seconds) that the system
will wait for input from the modem (usually at prompts). After
this number of seconds with no input (typed by the caller) TP-
Board will print the message ++ Input Timed Out ++, log off the
caller and wait for the next call. This doesn't affect the local
console that the Sysop uses.
Def: 300 (seconds)
Hour to being auto macro
------------------------
The hour (0-24) to start executing the macro string. Since
this feature finishes when the last command is processed, there
is no STOP setting.
Def: 4 (4 a.m.)
TPBoard has built in routines for guarding against your
disks becoming full and causing a crash. As the disks become
full, a controlled shutdown of functions takes place. The next
five settings control when this takes place. PLEASE note that
these checks do NOT apply to EchoMail.
When any of the limits are reached, TPBoard will display a
message to the Sysop on the local console during the 'bouncing
cursor' routine while it is waiting for the next caller. This
occurs about every fifth 'bounce' of the cursor.
Min disk space to allow uploads
-------------------------------Files that are uploaded to TPBoard are written to the NEWIN
section in the files sub-system. When there is less than this
value (in K bytes) of free space left on the disk, callers are
not permitted to send files to TPBoard. This test operates on the
drive set (with the Setup program) for the NEWIN section. The
checking is NOT performed when using batch protocols.
In the case of conferences the uploads will go directly to
the drive that you have set with the Setup program. Unless this
is the same drive as the NEWIN section, no checking for a full
disk will be done.
Def: 50(K)
Space to restrict msg size
--------------------------
When there is less than this amount of free space available
on the system drive, TPBoard will limit the number of lines that
can be entered in a message to a value discussed below.
There is a separate setting (discussed later) for manually
limiting the number of message lines all the time.
Def: 20 (K)
Min space for all operations
----------------------------
If there is less than this amount of free space on the
system disk all message entry is prohibited. Callers trying to
enter messages are informed that there isn't enough disk space
for messages. This value should be less than any of the values
above.
If there is less than the this amount amount of free disk
space on the system drive, only callers already known to the
system will be allowed in, and they will be able to do everything
but upload and enter messages.
Def: 5(k)
Min space to allow new users
----------------------------
This value represents the minimum disk space on the system
disk (where the .COM file and overlays reside) to continue to
allow new callers to register on the system. If less than this
amount of space is left, the caller will be told that new logins
can't be accepted and asked to call in later.
Def: 25 (K)
No. Lines for restricted msgs
-----------------------------This is the number of lines that messages are limited to
when there is not at least the amount of free disk space set in
the value above.
Def: 10 (lines)
Max message lines usually
-------------------------
The number of lines that messages will be limited to when
NO space restrictions apply but when message lines are limited
according to a setting below. During message entry, callers
will be warned 2 lines before the end of the message is reached.
Def: 100
GENERAL SETTINGS
================
General settings
────────────────────────────────────────────────────────────────────────
Can new users download? ..(Y/N) N Using ConfMail? .........(Y/N) N
Run a timed macro? .......(Y/N) Y Users delete echo mail? .(Y/N) N
Limit typing files? ......(Y/N) N Allow new users to chat? (Y/N) Y
Restrict public messages?.(Y/N) N Force TPB to mono video? (Y/N) N
Auto display file dirs? ..(Y/N) Y Ask callers for nulls? ..(Y/N) N
Force Am. phone format? ..(Y/N) Y Ask callers for b-day? ..(Y/N) N
Credit files by......... Files···· Upload/Download ratio... 20···
Max lines user can type. 250·· New user upload credit.. 0····
Birth date format....... mm-dd-yy·· Calls between b-days ... 3··
Hours to allow novices . 3···· Time to add per Alt-T .. 20···
New user Fido credit ... 100··
Address field name ...... Address
Address field prompt .... Enter your address··············
─────────────────────────────────────────────────────────────────────────
Can new users download
----------------------
This toggle when ON will allow all new users, whether
validated or not, to download files. If OFF, then a user will
have to be validated before he can download files.
Def: N (OFF)
Run a timed macro?
------------------
TPBoard has the ability to execute commands automatically
and unattended, just as if the sysop were sitting at the localconsole. This feature is called Macro Processing. (A macro is a
string of characters and delimiters which represent commands.)
If the Auto Macro processing is ON and the current hour is
greater than the hour set for auto operation, TPBoard will wait
for the current caller to hang up (if there is a caller) then it
will make the modem busy to prevent more calls. Then it will log
the sysop into the system automatically and pass the current
Macro string to the multiple command buffer for execution.
After completion of the commands, TPBoard will log off the
system (this must be the final command in the Macro string) and
put the phone back on the hook. The maximum length of the Macro
string is 80 characters, including delimiters (spaces, commas,
semi-colons).
Care must be taken to make sure all required key strokes are
included in the Macro string, especially the final command to log
the Sysop off the system. Carriage returns can be put into the
string by using an up arrow and M (^M). It is the Sysop's
responsibility to make sure of this, or the system will sit and
wait for further input from the local keyboard! We recommend that
before making the Macro automatic it be tested by the Sysop.
Def: Y
Limit typing files? (Y/N)
--------------------------
If Yes, users will only be allowed to type files (list files to
the screen) for a designated number lines. If No (off), callers
will not be limited to the number of lines they can type.
Def: N
Restrict public messages
------------------------
This toggle when ON will automatically flag all messages
entered as Public by the sender. They will not be available for
viewing until released by the Sysop. Only messages entered after
the toggle has been turned on are affected. When OFF, messages
marked Public will be immediately available for viewing.
Def: False (OFF)
Auto display file dirs
----------------------
This determines if the directory will be displayed automatically
every time a user changes file sections. For small file areas,
this doesn't take very much time; for larger areas, it can become
a nuisance.
Def: ON
Force Am. phone format
----------------------
This determines if the phone number that a new user enters
will be automatically forced into the U.S. format, and will have
validity checking performed on it.
If set to OFF, then the user can enter any sequence of up to
12 numbers.
Def: ON
Credit files by
---------------
This setting determines how uploads and downloads will be
charged to the user. You can set it to 'Files', and the user is
credited and charged per file. 'Kilobytes' is based on the file
size, and 'Points' are set individually for each file by the
Sysop.
Def: Files
Once you have chosen a particular method, it is not
recommended that it be changed after the system has been in
operation for any length of time.
The NEWIN file record is not set up with a sysop assigned
point value unless the 'Point' method is implemented. If a large
number of files have been uploaded without 'Points' being imple-
mented, you would have to manually edit each entry to assign it a
point value.
It's also difficult for your users to keep proper credit for
their uploads if you switch from one method to another. If you
want to switch crediting methods, be sure to warn your users of
the impending change.
Max lines user can type
-----------------------
This setting determines how many lines of a file can be
'Typed' before the function will be terminated. If set to 0, then
no checking will be performed. This setting does NOT apply if you
are logged on as the SysOp.
Def: 250
Birth date format
-----------------
This specifies the format that must be used when callers are
prompted for a birthdate (if you are prompting for birthdate).The options are:
mm-dd-yy MM-DD-YY mm-dd-yyyy dd-mm-yy
dd-mm-yyyy DD-MM-YYYY MM-DD-YYYY DD-MM-YY
This setting affects the display as well as the method TPBoard
expects for entry of the birthdate. The difference between the
upper and lower case letters is that the lower case letters
cause numbers to be padded with '0' whereas the upper case letters
do not. Example: MM/dd/yyyy would be 1/01/1991 where mm/dd/yyyy
would be 01/01/1991.
Hours to allow novices
----------------------
Novice mode forces menus to automatically display for any
caller that has novice mode turned on. Each user record contains
a flag that indicates whether novice mode is on or off. If
novice mode is enabled on your system, new users will operate in
novice mode by default. In addition, users may toggle
mode for themselves in the Edit User Menu PROVIDING this value
is non-zero.
By default, novice mode is disabled; however, if you change
this setting to any non-zero value, the value you enter here is
the number of hours a caller my utilize novice mode. In other
words, a caller may only accumulate this many hours of
your board before novice mode is no longer available.
Def: 3
Address field name
------------------
There is a field in the user record that was once used to store
the user's computer type. Lately, few sysops wanted this
information and preferred to ask for the street address of the
users. After deciding what YOU want to store in this field,
what is this field to be named/labeled when printed out?
Def: Address
Address field prompt
--------------------
Where the previous setting provides a name for the display of
data from the address field, this setting is the question that
will be asked of users when initially prompted to enter the
field.
Def: Enter your address
Using Confmail
--------------Only important if you use the FidoNet functions. This flag
determines whether or not TPBoard enters a Net/Node to the SeenBy
line on messages it creates in EchoMail areas. If set to OFF,
then it does NOT add them. If you are using FDTS, then set this
to OFF.
Def: OFF
Users delete echo mail?
-----------------------
Only important if you use the FidoNet functions. This flag
determines whether or not you allow a user to delete messages in
the EchoMail areas. If set to OFF, then he can't delete his
messages.
Def: OFF
Allow new users to chat?
------------------------
Should new callers be allowed to ring for the sysop? If yes, the chat
request will be restricted to the chat hours setup earlier.
Def: YES
Force TPB to mono video?
------------------------
Normally, TPBoard can detect the monitor type installed on your
system. If you are having problems with a mono monitor on a color
card, set this to YES.
Def: NO
Ask callers for Nulls?
----------------------
Should new callers be asked for the number of NULLS the need
sent?
Def: NO
Ask callers for b-days?
-----------------------
Do you want to prompt new callers for their birthdays? If
Yes, you can also enable the security feature of confirming
birthdays every XX many calls.
Def: NO
Upload/Download ratio---------------------
The value entered here is the ratio that is set for all
users on their FIRST login. You can set their ratio after that to
anything you want, and this value will not affect that setting.
If you are using the Point system, you'll probably want to
set this to 1 (a 1 to 1 ratio). The purpose of the ratio is to force
a minimum number fo uploads for every XXX downloads. A ratio of 20
means 20 downloads for every upload allowed.
Def: 20
New caller upload credit
------------------------
Used in conjunction with the ratio, this sets the number of
files a new caller can download.
Def: 0
Calls between b-days
--------------------
IF you are prompting for caller birthdays, how often (how many
logins) should TPBoard prompt for confirmation of the birthdate
on file for that caller? 0 means no prompting, 1 means prompt
every time, etc...
Def: 8
Time to add per Alt-T (F8)
--------------------------
You can give the current caller more time by pressing the F8
key. This amount of time, as specified in this setting, will be
added for the current call only. You can repeat the F8 key per
caller as many times as you like. The caller will receive a
notification of the added time.
Def: 20
New user Fido credit
--------------------
IF you are charging for netmail, you may want new callers to
have access to Netmail to try it out for the first time. This
settings allows an initial credit for use in sending Netmail.
Def: 100
FEATURES SETTINGS
=================
This edit screen controls or enables some of the features of
TPBoard. Many are specific to TPBoard+.
Features settings
───────────────────────────────────────────────────────────────────────
Use message compression? (Y/N) N Hide files on uploads? (Y/N) Y
Use sys generated menus? (Y/N) Y Use extended file info? (Y/N) N
File info directory ... ·······························
XRS Upload path ....... ·······························
State field minimum ..... 2· Menu left bracket ....... [
State field maximim ..... 2· Menu right bracket ...... ]
Private area purge days . 14· Vertical snaking (Y/N) .. Y
XRS error level ......... 0·· Charge for Netmail (Y/N) N
XRS Point number ........ 0···· Check ansi screens (Y/N) N
XRS ARC? (Y/N) N ZIP? N LZH? N ZOO? N
Export on exit (Y/N) .... Y
Max message size ........ 32000
───────────────────────────────────────────────────────────────────────
Use message compression?
------------------------
TPBoard already has the most compact message format of any
bbs available. TPBoard+ does itself one step better by allowing
compression of the message base on a message by message basis
using PAK routines by NoGate Consulting. This option does not
add greatly to accessing messages but does mean you must also
set up any utilities to recognize the compressed message base.
Def: NO
Use sys generated menus?
------------------------
TPBoard+ will create menus based on a caller's privilege bits
if you enable this feature. The benefit is that callers can't
see (won't be shown) options they don't have access to.
Def: N
File info directory
-------------------
TPBoard+ has a feature of extended file descriptions. This means
that you can set up a file of descriptions for EACH file area
and the caller can list a description from this description
file. This setting determines the path where ALL of your
extended description files are located.
Def: blank
XRS upload path
---------------
This is where uploaded XRS mailbags will be places for tossing
by your echomail tosser. It should be the same as the directoryfor incoming mail packets.
Def: blank
State field minimum & State field maximum
------------------- -------------------
For our European sysops, the state field was lengthened to 12
letters and the sysop sets the minimum and maximum length
for the state field entry.
Def: 2,2
Private are purge days
----------------------
A TPBoard+ feature, callers can upload files to the board to be
placed on hold for another caller. This settings sets the number
of days that files in Private are to be kept around waiting for
download.
Def: 14
XRS errorlevel
--------------
Do you want TPBoard to exit with a special errorlevel on receipt
of XRS mailbags? Set the error level here from 0 to 255.
Def: 0
XRS Point number
----------------
XRS mailbags will be returned having the same address as your bbs.
This can cause problems for some tossers which will NOT see this
mail as incoming. Setting up a special point number for XRS will
ensure that incoming mailbags do not have the same address as
you system.
Def: 0
XRS ARC? ZIP? LZH? ZOO?
-----------------------------
Before downloading an XRS mailbag, the caller must select a
compression method from those you've enabled here. If you answer
NO to all of the methods, XRS Download will be disabled totally.
Def: N,N,N,N
Export mail on exit?
--------------------
Answer yes if you are running in FidoNet and want TPBoard to handleexporting new mail as it is entered.
Def: Y
Max message size
----------------
TPBoard allocates a message buffer large enough to hold the largest
possible message that TPBoard will allow (32000 bytes) when TPBoard
first comes up. If you use compressed messages, two such buffers
are required. By setting this figure to a lower number, you can
reduce the amount of memory required by TPBoard. But you will also
be reducing the maximum size of messages that can be entered on your
system. The minimum figure is 8000; the maximum is 32000. If a
larger message is imported using IMPMSGS, IMPMSGS will chop it off
without warning. Other importers should be equally well behaved.
Def: 32000
Hide files as uploaded
----------------------
This setting tells TPBoard to NOT mark newly uploaded files
as hidden. Normally, all new files are hidden until approved
by the sysop or until "aged" for a number of days.
Def: Y
Use extended file info?
-----------------------
Used with the file info directory above, this enables use
of the extended file descriptions feature of TPBoard+.
Def: N
Menu left bracket & Menu right bracket
----------------- ------------------
Used by TPBoard+ when creating system generated menus, these are
the characters that will wrap the command letter for a menu option.
For example: [M] Message Menu Option
Some countries can not display the [] characters and would rather
use the (), {}, or <> pairs.
Def: [,]
Vertical snaking
----------------
When performing a RAW directory listing in the Files menu, the files
are typically displayed in columns from top to bottom with a bar
drawn between the columns:
A.DOC | F.PAK | MAN.ZIP
AB.DOC | FF.PAK | MAP.ZIP
ABC.DOC | FG.PAK | MAT.ZIP etc....
This is called vertical snaking. If you answer NO, the snaking will
be horizontal:
A.DOC AB.DOC ABC.DOC F.PAK
F.PAK FG.PAK MAN.ZIP MAP.ZIP
MAT.ZIP etc....
Def: YES
Charge for NetMail?
-------------------
Only applicable if you are using the FidoNet features of TPBoard
and are allowing callers access to the Netmail area. This setting
determines whether caller's must have an account balance sufficient
to "pay" for NetMail messages they send.
Def: N
Check ansi screens?
-------------------
If set to YES, when the caller selects ansi screens, TPBoard will
PAUSE any screen when it reaches 23 lines of display (or the user's
number of lines per screen setting). Often ansi screens require
many times this number of lines to produce a total real display
output of 20 lines. If you answer NO, TPBoard won't check the number
of lines in an ansi screen.
Def: NO
MODEM STRINGS
=============
Modem strings
────────────────────────────────────────────────────────────────────
OKAY string.... 0················································
RING string.... 2················································
Connect 300.... 1················································
Connect 1200... 5················································
Connect 2400... 10···············································
Connect 9600... 13···············································
Connect 1200mnp 15···············································
Connect 2400mnp 16···············································
Connect 9600mnp 17···············································
Error string... 4················································
ARQ string..... /Arq·············································
Init strin..... ATX4Q0H0M0V0E1S2=255|····························
Off Hook string ATH1|········· Hang Up string. ATH0|······
────────────────────────────────────────────────────────────────────
OKAY..Error string
------------------
These are the result codes returned by you modem for the
listed result. They MUST be numeric. TPBoard will not work with
modems that only return verbose result codes.
A little further explanation is required for the MNP result
codes. Some modems will return different result codes for a
connect depending on whether it's a normal or MNP connect. Some
of TPBoard's transfer protocols require an MNP connection to work
properly (Ymodem-G modes).
If you don't have an MNP modem, and you don't want the
Ymodem-G protocols available, then enter a null string for the
MNP result codes. If you don't have an MNP modem, but for some
reason want Ymodem-G enabled, then place your normal connect
codes where the MNP connect codes should be.
Otherwise, when you are NOT running TPBoard under a mailer
and are using an MNP modem, Ymodem-G will only be allowed for
callers that connected with another MNP modem.
If you are running under a mailer, then MNP connects are
assumed for all callers unless the MNP connect result codes are
set to null strings. This is done because the mailer cannot pass
the MNP information to TPBoard.
Def values: US Robotics Courier HST result set
ARQ String (Mailer MNP Connect String)
--------------------------------------
Only important if you are running under a mailer. This is
the text string that is passed by your modem when in verbose
mode, and denotes an MNP connection. For example, the USR Courier
HST would pass a result of CONNECT 9600/ARQ if an MNP connection
was made. FrontDoor and Binkley would both pass /Arq as one of
their parameters, and TPBoard would look for /Arq as it's fourth
parameter to see if the current connection was an MNP connection.
Def: /Arq
Init string
-----------
This is the command string that is sent to the modem when
TPBoard is first brought up, and after all calls are completed.
The ~ means delay for 1 second, and the | means CR.
Def: |ATZ|~~ATX4Q0H0M0V0E1S2=255|
Off Hook String
---------------This is the command to send your modem to place the modem
off-hook. If you do not want the phone line to be busied when you
log on locally, then just place the CR character here (|).
Def: ATH1|
Hang Up String
--------------
This is the command to send your modem to place the modem on-hook.
Def: ATH0|
Answer String
-------------
This is the command to send your modem to have it answer the
phone. It is only sent if the 'Let Modem Answer Phone' toggle is
set to OFF.
Def: ATA|
VALIDATION PURGE
================
Validation/Purge settings
──────────────────────────────────────────────────────────────────────
Validated system time .... 50··· Unvalidated system time .. 20···
Validated access level ... 50··· Unvalidated access level . 20···
Validated purge days ..... 180·· Unvalidated purge days ... 61···
Message retention in days 60··· Days to age files in Newin 30···
Days for read messages ... 30···
──────────────────────────────────────────────────────────────────────
Validated system time & Validated system time
--------------------- ---------------------
The values set here are the defaults that TPBoard uses for
'Time Allowed on System'. Whenever a new user logs on, he is only
allowed to be online for the amount of time that you set as the
time limit for un-validated users.
Def: validated = 50 un-validated = 20
(Note that there are 9 levels of validation using TPBoard+)
Validated Access Level & Validated Access Level
---------------------- ----------------------
The values set here are the defaults that TPBoard uses for
the user's access levels. Whenever a new user logs on, he is
automatically set to the access level defined here for
unvalidated users.
Def: validated = 50 un-validated = 20
NOTE: If you set access level of un_validated users the same or
greater value than the setting for validated users you are
creating an OPEN system where callers DO NOT require verification
by the Sysop before obtaining the same status as validated users.
(Note that there are 9 levels of validation using TPBoard+)
Validated purge days & UnValidated purge days
-------------------- ----------------------
The number of days allowed to elapse between calls before
the inactive user is purged from the system. For example, 180 and
61 will allow unvalidated users to remain on the system for 61
days between calls and validated users 180 days between calls
before being deleted from the user file during a purge operation.
Def: validated = 180 un-validated = 61
Message retention in days & Days for read messages
------------------------- ----------------------
The number of days allowed to elapse before unread and read
messages, respectively, are automatically deleted from the
message file during a purge operation. Public messages are never
marked as read and thus will be available until explicitly
deleted or until they "expire" as determined by 'un-read days.'
All messages are subject to these time limits unless they
have been marked as <P>rotected by the Sysop. Any messages marked
as deleted remain in the message file until the next purge
operation, but are automatically purged even though the number of
days is less than the values above.
Def: read = 30 un-read = 60
Days to age files in NEWIN
--------------------------
The number of days allowed for a file to reside in the NEWIN
file section before it will be copied to it's destination when
the 'Y'ank command is used. This uses the date of release of the
file as recorded in the NEWIN description file for the starting
date. If you include "Y" in your macro string, this setting will
move files to their destination areas after XX number of days in
the Newin area.
Def: 30
HARDWARE
========
Communications settings
─────────────────────────────────────────────────────────────────────
Offhook in local mode? (Y/N) N Delay from RING to Answer .. 500·
Allow modem to answer? (Y/N) N Decimal value of escape code 255
Com port number (1..4) ...... 1 Default modem baud rate ..... 300·
Use a locked rate? (Y/N)..... N LogOff delay factor ......... 0···
Comm port addresses: 1) 1016 2) 760· 3) 1000 4) 744·
Comm port interrupt: 1) 4·· 2) 3·· 3) 4·· 4) 3··
─────────────────────────────────────────────────────────────────────
Offhook in local mode?
----------------------
When TPBoard goes into local mode, you can have the phone go
offhook (which will give callers a busy signal). Normally,
you would answer YES; however, some phone companies will disconnect
any "dead lines" after a matter of minutes. This is true using
Southern Bell in North Carolina. I've had my phone line turned
OFF because the modem was offhook during message reading in local
mode!
Def: NO
Allow Modem to answer
---------------------
If for some reason your modem refuses to work properly with
it's auto-answer turned off, then enable it with either S0=1 or
the dip switch, and enable this feature. This will allow the
modem to answer incoming calls instead of TPBoard sending the
answer command to the modem.
Def: OFF
Comm port number
----------------
This one is pretty obvious.
Def: 1
Use a locked rate?
------------------
If you are running your modem at a locked rate, set this to
TRUE. If you set "Using Locked Speed" to true, you must also
enter the Default Modem Rate at the same rate to which you are
locking the comm port.
Def: NO
Delay between ring and answer-----------------------------
This is the time in milliseconds to delay between receiving
the RING result code and sending the Answer String. It has no
significance if the 'Let Modem Answer Phone' toggle is ON.
Def: 500
Decimal value of Escape code
----------------------------
This is the decimal value of the character that you modem
will recognize as it's attention character. Set it to the
same value that you have the S2 register set to.
Def: 255
Default modem baud rate
-----------------------
This is the baud rate that TPBoard will use to communicate
with your modem. It will usually be the highest rate that your
modem is capable of. If you set "Using locked speed" to true,
then this becomes the speed at which to lock the com port.
Def: 2400
LogOff delay factor
-------------------
Buffered modems can contain data for transmission that will be
lost once a drop carrier is processed. If you have a logoff
screen in your sysmsg files, enter a delay factor sufficient to
allow full display of that screen with all callers and modem types.
Def: 0
=======================================
7. The Network version
=======================================
To date, TPBoard has only been run on a Lantastic LAN, 10Net,
and under DV. Lantastic is fully NETBIOS compatible, so TPBoard
should also run under PCLAN and MSNET. It should also run under
Novell with the NETBIOS driver loaded. It will also run under
DesqView 386 if SHARE has been loaded. TPBoard requires a
network with Microsoft compatible locking!
This version should be capable of supporting 99 lines on a
LAN. It may support three lines under DesqView 386 and has
been tested sucessfully under those conditions. If you are
running it on a LAN, you should use at least an 8 mhz 286 for
the server, and have a server hard drive with a minimum
average access time of 40ms. If you can supply a dedicatedServer, that is even better, but it will run OK if you don't.
You can run it from a diskless workstation, but operations
are much faster if the workstation has a hard drive. It also
helps if you have at least 1mg of expanded memory on the
workstations. Please note that you CAN run it on a 4.77 mhz XT
workstation with no drives and only 512k of memory, especially if
you are running Novell.
In order to run this version, you MUST be using DOS 3.3 or
later. We make use of some calls that are only supported in
those versions of DOS.
NOTE!! ALL executable files must be set to read-only or you
will get a share violation on attempting to run the second node.
Additional files
----------------
The following files are used by the network version in addition to
the normal files that TPBoard uses.
LOGx.BB# X is the node number assigned to each workstation
or node. The server is always node 1.
LUSRx same as above.
TPBUPx.BB# same as above
NODEx.CFG Node specific configuration file.
NEWIN.DIA Dialog file for NEWIN.DAT.
SUMMARY.DIA Dialog file for SUMMARY.DAT.
USER.DIA Dialog file for USER.DAT.
SETSHARE.EXE Used to set DOS retries.
TPBPATHS.x Assigns full paths to Files areas.
Additional command line parameters
----------------------------------
TPBoard MUST be called using one additional parameter, the
node number of the system logging in. Just add NODE X to any
command line, i.e,
TPB 99 Node 2
TPB Node 5
TPB %1 %3 mnp %4 Node 3
If you forget the node number, TPBoard will abort and let
you know that you forgot it (or used the same number for two
different nodes). You are allowed to use any number between 1
and 99. Node 1 HAS to be used for the server. If you are running
under DesqView 386, Node 1 is the controlling node.
Whenever you invoke TPBoard, whether it's from the server or
it's from a workstation, you MUST be logged into the TPBoard
system drive on the server. For example, if the servers system
drive is E:, and that drive is mapped to drive H: on the
workstation, then to invoke TPBoard from the workstation, youmust be logged into drive H:. To invoke it from the server, you
MUST be logged into drive E:.
You CAN actually load TPB from a different drive, as long as
you are logged into the servers SYSTEM drive. For example, if the
workstation has a RAM drive (G:), you could log into the servers
SYSTEM drive and invoke TPBoard with the following command;
G:TPB Node 2
That will actually speed up the loading of TPBoard by a
large margin, and put less of a load on the LAN. It will also
speed up TPBoard's operations substantially, as it's overylays
will now be loaded from the RAM drive instead of through the net.
If you don't have a RAM drive on the workstation, but do
have a hard disk, then do the same as shown for the RAM drive,
but use the hard drive's drive letter instead. It will still
speed up operations over what you would obtain by loading TPB
from the server.
Node configuration file
-----------------------
The node configuration files MUST reside in the system
directory of the server. The next page contains a sample of the
config file that I am using for my second node. It's named
NODE2.CFG.
If you are using a different com port for the node than on
the server, you MUST set the PORT, BASE, and IRQ values for that
port. The BASE value MUST be in decimal, not hexadecimal. Below
are listed the normal values for 4 comm ports.
PORT IRQ BASE (in decimal)
1 4 1016
2 3 760
3 4 1000
4 3 744
; This is a sample node configuration file. Any line that starts
; with a ; is ignored. Case is not important, and there must be
; at least one space or a tab between the item and it's setting.
; If you don't need to change a field from what it shows for
; the server in Setup, then just comment the field out.
;OK 0
;RING 2
;CONNECT_300 1;CONNECT_1200 5
;CONNECT_2400 10
CONNECT_9600
CONNECT_1200_MNP
CONNECT_2400_MNP
CONNECT_9600_MNP
;ERROR 4
OFF_HOOK
;ANSWER ATA|
HANGUP ATH0|
;DELAY 500
;INIT |~ATZ|~~ATX4Q0H0M0V0E1S2=255|
;ESCAPE 255
;PORT 1
;BASE 1016
;IRQ 4
RATE 2400
MODEM_ANSWER NO
;MNP /ARQ
LOCKED NO
; The following sets the path to the SYSMSG files. If no
; entry, the ones on the Server are used. It's faster to
; have another set on the workstation.
SYSMSG_PATH D:\
; The following sets the path to the drive for swapping to disk
; with TPBoard's memory image. If no entry, the SYSTEM drive on
; the Server are used. It's MUCH faster to use the workstation's
; drive instead of the servers's drive.
SWAP_PATH D:\
; The following info is a drive map table.
; You only need to enter the drives that you have
; mapped on the workstation.
; The first letter is the workstation drive, and the
; second letter is what the drive really is on the server.
MAP F C
MAP G D
MAP H E
MAP I F
MAP J G
Mapping is not as efficient as assigning full DOS paths to file
sections. There is a TPBPaths.X file for each node. In the near
future, drive mapping will be replaced entirely and every node
will have its own Section.BB# file complete with full paths for
every area, article, etc.
Macro processing
----------------
The processing of macros in the network version is
considerably different than in the stand alone version. The macro
(and the purge commands) can only be executed from the server.
This is due to the fact that almost all macros contain purge
commands, and a purge HAS to be done when all workstations are
down.
Any user on any node will will have his time limit adjusted
at login so as to not be logged on at the macro execution time.
If the server or any workstation is running under a mailer, then
an event needs to be setup that will not allow any users or mail
traffic at that time. If the server is running user a mailer,
then a forced event (no callers allowed) needs to be set up that
will execute the "TPB 98 Node 1" command.
The sequence of events is as follows;
If the server or workstation is running standalone, any
users currently logged on will be forced off. If the user is
in the middle of a file transfer or message entry, he will
be allowed to finish.
The workstations will all remove their TPBUPx.BB# files, and
wait for up to 20 minutes for a file called PURGING.BB# to
appear.
The server will go into a loop, waiting for up to 20 minutes
for all of the TPBUPx.BB# files to disappear. Once they have
all disappeared, it will write a file called PURGING.BB# to
the system directory. It will then start it's macro
execution.
If the workstation saw the PURGING.BB# file appear within
the alloted 20 minutes, it will then wait indefinitely for
it to be erased. If the file never appeared, it will return
to normal after the 20 minute period has elapsed.
If the server's TPB was invoked with a 98 command (meaning
it was running under a mailer), it will exit when the macro
is completed. If it was running standalone, it will erase
the PURGING.BB# file, and return to normal operation. If it
was invoked with the 98 command, it left the PURGING.BB#
file because there you may want to run some other utilities
in your batch file that need the nodes to remain down. That
is when you would run Impmsgs and do all of your message
processing. It's up to your batch file to erase the
PURGING.BB# file when it's through.
Once the workstations see the PURGING.BB# file disappear,
they will rewrite their TPBUPx.BB# file, and return to
normal operation.
As you can see, it is very important that all of your DOS
clocks are close. It is highly recommended that you have all of
the workstations set their clocks from the server at boot time.
This assures that everybody is in sync at macro time.
If you are running a mailer on the server, and all
workstations are running standalone, a small problem may occur.
Let's say that you only execute your macro event on the server
twice per week. If that is the case, then all of the workstations
will end up going down 20 minutes per night on the other 5 days
without any good reason. To avoid that, set up an event on the
server that calls a batch file like the following on those 5
nights.
@echo off
e:
cd \ ; change to TPB dir
:loop
if exist TPBUP?.BB# goto loop ; loop till nodes all down
copy c:\config.sys purging.bb# ; create a dummy PURGING.BB#
task 10 ; delay 10 seconds
erase purging.bb# ; erase the dummy file
What this batch file will do is fool the workstations into
thinking that the server has completed it's macro processing, and
allow them to return to normal in less than the 20 minutes that
they would normally wait.
The only problem with the above batch file is that if a
workstation crashed, it's TPBUP file will never go away, and the
batch file will never exit. If you have some extended batch
language tools, you could add some time checking, and exit the
loop after a set length of time has passed.
It is not a wise practice to execute the macro from the
server at any time other than the preset macro time unless you
know that all other nodes are down and will stay down during the
processing time.
If you are running a workstation under a mailer, you can
have the mailer invoke TPBoard in it's macro mode at the same
time as the server, and it will do nothing more than go into a
delay mode just as if it was running standalone. The same thing
will happen if you invoke the workstation's TPBoard in macro mode
at any other time. If you do, then the workstation will end up
idling for 20 minutes, or until it sees PURGING.BB# file come up and
subsequently disappear.
Programs that must be run with all nodes down---------------------------------------------
The following programs MUST only be run when ALL of the
nodes are down. If you run them when any node is running, or if
there is a chance that a node could come up while they are
running, problems will occur. If you run them during automatic
processing from a batch file, then make sure it's done from the
servers batch file, right after the macro executes and before you
erase the PURGING.BB# file.
TPBFILE.EXE
IMPMSGS.EXE except for importing
REN-SECT.EXE
REN-TYPE.EXE
SetShare program
----------------
The SETSHARE program that comes with the network package is
only used if the server is running under a mailer. It is very
important that the time that DOS takes retrying to access a
locked file is set properly, and this program tries to insure
that it remains set to what TPBoard expects.
If TPBoard runs standalone on the server, then it is always
set properly. If a mailer is running though, there is a good
chance that some other "network smart" program will have set the
retries too low, and since TPBoard doesn't run till the mailer
passes a caller to it, it will remain to low for some time. If
you always run SETSHARE at boot time, and after you've run ANY
other program on the server, then you've insured that the sharing
retry value is always what the other nodes expect it to be.
This procedure is necessary, as the retry count can only be
set from the server. A workstation application cannot set the
retry delays on the server.
Severed connections
-------------------
If you have troubles losing the connection between a
workstation and the server, and want to have the connection
automatically re-established, there is a TSR from Samual Smith
called FATAL that does a very good job of it. There is no code in
TPBoard that will re-establish the connection for you. FATAL is
available on Rio Grande BBS and The Pass.
Running TPBoard NOT on the server
---------------------------------
If for some reason (testing), you want to run the network
version of TPBoard while logged into the workstations drive, youneed to make sure that you have SHARE installed on that system.
If you don't, TPBoard will get confused, and think that all of
the system indexed files are damaged, and recreate all of the
indexes. No damage is done if this happens, but it can be real
annoying.
The DIA files
-------------
If the server crashes, a non-network version of a TPBoard
utility is run, or if a workstation crashes during a critical
operation, you may start experiencing strange problems. The first
thing for you to try is to delete all of the files with a DIA
extension in the TPBoard system directory.
If that does not fix your problems, delete all of the files
with a IX extension. These files will be created automatically by
TPBoard if they are not found.
It's a good idea to have the following line in the
AUTOEXEC.BAT file on your server;
ERASE C:\TPBOARD\*.DIA
That will insure that if there is a crash on the server, and
you had to reboot, that the files will be re-created.
=======================================
8. Utility Programs
=======================================
Many of the following utility programs perform functions
that exist in CONS as well. The reason for the distribution
of the separate programs is to allow batch file operations
for specific features. The ListUpdt program, for example,
is ideally suited for batch mode operations.
LISTUPDT.EXE
============
ListUpdt is a Nodelist update utility designed to update your
nodelist file from the current Nodediff file. ListEdit must
be run in the same directory as your nodelist file and the
current nodediff file. The nodediff files MUST be decompressed before running ListUpdt. ListUpdt will optionally create the
compiled nodelist files required by TPBoard for sending NetMail.
Listupdt expects at least one command line argument to select
which form of nodelist you are using. A few optional arguments
arer recognized as well.
/F required if you are using the standard St Louis format
nodelist as used by FrontDoor
/T tells ListUpdt to ALSO create the TPBoard nodelist files
/S tells ListUpdt to save a copy of your old nodelist
/D tells ListUpdt to create a .dbf file from your nodelist
Listupdt requires a file named ListUpdt.CTL if you use the /T or /D
options. This file instructs Listupdt on how to build the TPBoard
nodelist files; which zones to use, what the local versus
international costs are, etc. Listupdt uses a different method
to establish costs than you're probably used to. The following
is a sample control file for ListUpdt.
; COUNTRY sets YOUR international country code
;
COUNTRY 1
;
; The ZONE statement determines which Zones will be included
; in the .TPB files produced. You must include every zone
; number you wish to access in TPBoard. Use a separate
; line for each zone statement. Zone numbers must be between
; 1 and 255
;
;ZONE 2
;ZONE 3
;ZONE 4
ZONE 1
;
; The REGIONS statement tells ListUpdt which regions are NOT
; international calls for your country. For example: REGIONS 10
; 11 12 13 14 would instruct ListUpdt NOT to charge international
; rates for nodes within regions 10-14; all nodes in any other
; regions are considered international calls. Region numbers
; must be between 1 and 255
;
REGIONS 10 11 12 13 14 15 16 17 18 19
;
; According to the regions specified in the REGIONS statement,
; COST establishes the cost assigned nodes by region. The first
; number is the cost for all "local" calls; the secod is the cost
; for international nodes (nodes NOT in your REGIONS statement)
;
COST 25 200
As you can see, this method of costing is far less complex than
entering every local phone exchange. Of course, the assumption
with this method is that you are NOT sending netmail from your
callers as CRASH mail (a very costly thing to do).
As of TPBoard 7.1, ListUpdt will also create a dbaseIII compatible
.dbf file from your nodelist using the parameters in the .ctl file.
This database can then be placed online for your callers (or just
you) to search the nodelist by bbs name, sysop name, city, state,
etc. ListUpdt is accompanied by a doc file that describes how
to create a dbf file and the options available.
REBUILD.EXE
===========
Rebuild is a rebuilding/reindexing utility that will reindex
any of the 3 btree indexed data files used by TPBoard. TPBoard
contains code internal perform this indexing; however, there are
times when you'll need to reindex without entering TPBoard itself.
Also, unlike TPBoard, which always performs a purge rebuild,
Rebuild will first attempt a fast reindex only to reconstruct
the database which does not require purging (removal of deleted)
records.
Several of the new utilities for TPBoard 7.1 may require the use of
Rebuild.
Rebuild expects at least ONE argument to tell it which TPBoard
file you wish to rebuild.
/S = Rebuild the Message files
/U = Rebuild the User file
/N = Rebuild the Newin file
/A = Rebuild ALL TPBoard files
/RN = Rebuild the Message file following a renumber using the
RENUM program
MAKESYSM.EXE
============
MakeSysm is a Sysmsg utility designed to make maintenance of
TPBoard Sysmsg files easier than batch file methods. MakeSysm
will break down a sysmsg file into individual .ASC or .ANS
files (depending on command line options). MakeSysm will also
construct a full (and new) Sysmsg file from all .ASC or .ANS
files in the current directory. This is NOT a 7.1 specific
utility.
For example, when you want to edit the SYSMSGg.TXT file (the one
containing the ANSI screens), you'd place the SysmsgG.txt file
and MakeSysm.exe in a directory and run MakeSysm as:
MAKESYSM -O -G
The -O mean create OUPUT and the -G means use the sysmsgG file.
This command would break you sysmsgG file down into separate
.ANS screens (files) with each screen producing one file. WHen
you have finished editing and want to produce a new sysmsgG file,
you'd run MakeSysm as:
MAKESYSM -I -G
Again, the -G means to work with the sysmsgG file. The -I means
the .ANS files are INCOMING. ALL .ANS files in the current
directory will be read in to the sysmsgG file. A totally new
sysmsgG file is created! If only one .ANS file is found in the
current directory, your sysmsgG file will only contain the one
screen!
Run MakeSysm without arguments for a help screen.
DESCCOMP.EXE
============
See the earlier section pertaining to extended file
descriptions.
The utility DescComp performs the linking between the extended
info files and the individual Newin records. You can run
DescComp for a single file area, all areas, or selected areas.
In addition, to automate support for SDN areas, DescComp can
link the SDA file as extended info to the Newin entry for the
SDN files. DescComp will also add Newin recs for any new SDN
files you've received that haven't been added to Newin thus
totally automating your SDN areas.
DescComp expects several arguments.
/? displays a list of options
/A tells DescComp to check the description files for ALL
files areas.
/S assume and process SDN areas only
/T import a TICK file into Newin
/N performs record locking when used as the VERY last
argument
Examples:
Desccomp TPBOARD PASCAL COOKING
would update the extended descriptions for the three areas
named on the commandline
Desccomp TPBOARD
would update the extended descriptions for the one area
named on the commandline
Desccomp /S PASCAL
would update the SDN area named on the commandline
Desccomp /T PASCAL PASCAL.TIC
would update the PASCAL area from a TICK file named
PASCAL.TIC
SETSHARE.EXE
============
Sets the number of Share retries for the network version.
When running TPBoard as a stand alone, this is generally
not necessary. If you are running under a mailer, however,
other programs can leave the retires too low for TPBoard.
This is not a 7.1 specific utility.
62TO64.EXE
==========
The program to convert your data files from v6.2 to v6.4 of
TPBoard. If you're updating to 7.1 from 6.0 or 6.2, you'll
need to run this followed by the individual conversion routines
for converting to 7.1.
IMPMSGS.EXE
===========
The only message importer that fully supports v7.1. Imports
from the fido .msg file format (as tossed by Tosscan, ConfMail,
Qmail, etc.) into either the standard or compressed TPBoard
format. Impmsgs contains other utilities as well, including:
Delete all messages from an area
Privatize all messages in an area
Reindex the message data files
Relink the message base
Export ALL messages from an area
Renumber the message base (VERY fast!)
Import from non-echo areas (for XRS mailbags)
See the section on Mailers and Impmsgs for more information on
Impmsgs options.
RENUM.EXE
=========
Renumbers the message base and updates User records. This is the
same code as in Impmsgs so it's very fast. If you renumber with
RENUM, you'll have to also reindex with REBUILD using the /RN
option.
PAKMESGS.EXE
============
PAKMESGS will convert your existing message base to the new
compression format. Be warned that PAKMESGS does NOT overwrite your existing message files; you will have to delete the old ones
and rename the new one as Message.BB#. In rough numbers, a 4mg
Message.bb# file will get converted to about 2.3mg.
ONE of the following options is required:
-CO tells Pakmesgs to compress the message base
-DE tells Pakmesgs to DEcompress the message base
TPBEDIT.EXE
TPBNEDIT.EXE
============
The sysop's local full-screen editor for 7.1. TPBNEDIT is the
networt version. Supports the compressed message format.
NEWNCNVT.EXE
USRCNVT.EXE
===========
The 6.4 to 7.1 conversion programs to convert the Newin file and
user file to 7.1 format. See the previous section on converting
to version 7.
TPBDEV70.EXE
------------
The file structures for TPBoard 7.1 as well as assorted code
fragments for accessing structures peculiar to TPBoard. This
file is updated regularly. Also, if you wish to write utilities
for TPBoard, you can get help from the support bbs, routines
added to TPBDEV70 on request, or even help in debugging.
======================================
======================================
The following are utilities or doors that have been updated to
the 7.1 format and are available from the support boards. These
are NOT distributed with TPBoard.
PJASCII.EXE
-----------
PjAscii was written to provide an easier means to export
data from TpBoard's system files than is currently available.
For example, to create a user list or a listings of files.
Unlike some other utilities, PjAscii was not written with
a specific file format in mind. Previously, if you
wanted that user listing, you ran one utility and a
different one to produce that files listing. PjAscii
doesn't recognize pre-existing ascii file formats, so you
can export to nearly any type or layout of ascii file
and you no longer need to use a separate utility for every
data export purpose.
VALIDATE.EXE
------------
VALIDATE is designed to allow validation of TPBoard users by
other software -- particularly door programs. Note that
VALIDATE will validate the designated user at the validation
level specified on the command line
MAILERS.EXE
-----------
Simple utility to create reports based on the Nodelist.
Mailers list created by Mailer 1.2
Type Mailers included Number
==== ================= ======
XA Frontdoor <1.99b 1741
D'Bridge <1.3
Binkleyterm >2.1
Dutchie 2.90c
XX Frontdoor >1.99b 2337
D'Bridge 1.30
XB Binkleyterm 2.0 144
Dutchie 2.90b
XW Fido >12M 161
Tabby
XR Opus 1.03 193
XC Opus 1.1 95
XP Seadog 170
QMM 1637
Node flag list created by Mailer 1.2
Number Flags Description
====== ===== ==============================
244 V21 CCITT V21 300 full duplex
544 V22 CCITT V22 1200 full duplex
1 V29 CCITT V29 9600 half duplex
2376 V32 CCITT V32 9600 full duplex
498 V32b CCITT V32bis 14400 fl dplx
0 V33 CCITT V33
0 V34 CCITT V34
1101 V42 LAP-M err correction w/ MNP
1380 V42b CCITT V42bis
870 MNP Microcom Networking Protocol
47 H96 Hayes V9600
4411 HST USR Courier HST
2 MAX Microcom AX/96xx series
161 PEP Packet Ensemble Protocol
11 CSP Compucom Speedmodem
4276 CM Accepts mail 24 hs 777 MO Does not accept human callers
8 LO Accepts NodeList calls Only
NED.EXE
-------
This archive actually contains two utilities, NED and SED
(Newin EDitor and Summary EDitor). These are full screen,
point-and-shoot type editors for the Newin and Summary files.
You work from a list of all the records in a particular
file and select individual records to edit, delete, or
perform some manipulation upon. They also contain powerfull
template features for filtering the view of the database as
well as for forcing data upon selected records.
NED and SED only work with Level2 registered versions of
TPBoard. Ned includes a full doc file in the archive.
REVAL.EXE
---------
If you are using validation levels and are NOT editing user
records individually, you may want to make changes to a
validation level that would affect all users already currently
validated at that level. REVAL will reassign all the settings
associated with a validation level to all callers who were
originally validated at that level.
APPENDICES -----------------------------------------------------------
Modems
======
TPBoard and High Speed Modems
-----------------------------
TPBoard is ideally suited to running at fixed rates with
high speed modems. Many BBS packages run on 4.77 mhz XT class
machines cannot receive files without multiple errors when the
rate is fixed at 19,200 or higher. TPBoard is capable of
receiving files on some of these machines without any errors at
rates as high as 38,400 bps.
All that is needed to gain the ability to run at the high
rates on slow machines is the installation of a new UART on your
serial card. Simply remove the old 8250 or 16450, and replace it
with a NS16550a. TPBoard will automatically detect its presence,
and utilize its advanced features.
If you are going to be running TPBoard with a USR HST modem,
(ROM 9.64 or later) the following setup is suggested;
Read in the factory defaults using AT&F
Send the following command -- ATX4&B1&R2&H1&S1S15=8S19=5
Then write the settings to NRAM using AT&W
Use '|~ATZ|~~ATM0V0S0=0|' as your initialization string
Use the numeric result codes as listed in the manual
The setup above assumes that you will be setting your Fossil
with a locked rate. The locked rate you specify for your fossil
and mailer is the same rate you must set up as the "default"
modem rate in CONS.
Most mailers now support an additional parameter where they
pass extended connect information (i.e., /ARQ). TPBoard will now
allow passing that info when it's invoked.
To have TPBoard use this information when it determines
whether or not to allow MNP protocols, change your invocation
line in your batch file to the following:
TPB %1 %3 MNP %4
The MNP parameter tells TPBoard that unless it sees the user
defined MNP connect string passed as the 4th parameter, do NOT
allow any file transfers using an MNP only protocol. Don't forget
to set your &A value to 1 (&A1) so that the HST knows to send theadditional information.
The alignment of these parameters may differ according to the
mailer and the version of the mailer you are running. I understand
that Binkley 2.51 (or thereabouts) CHANGED the command line
parameters being passed the the exebbs.bat file, so check your
batch files to ensure that TPBoard is getting the information it
needs in the positions it expects.
Modem Initialization
--------------------
TPBoard will initialize the modem whenever it is first
invoked, and whenever a caller logs off. Version 4.0 added the
feature of reinitializing the modem in between callers whenever a
period of 4 minutes elapses without any calls. This helps correct
any problems that may have been caused by power dips causing the
modem to lose it's configuration.
TPBoard and Other Modems
------------------------
We can't possibly know what settings all of the different
modems require for proper operation with TPBoard, and can't help
anyone if we don't have the modem in our possession. What we can
do is give a listing of what settings have worked for other sysops
that run TPBoard under different modems. Here are the ones that
have been submitted.
HAYES 2400
----------
Off Hook string ATH1|
Answer string ATA|
Hang Up string ATH0|
Delay before answer 500
Initialization string |~~ATZ|~~ATX1Q0H0M2V0E1&C1&D2&S1|
Decimal value of Escape Code 43 {default} {No S0=x!!!}
Com Port [1 thru 4] 2 { 1, 2, 3, or 4)
Rate to initialize modem at 2400
Let modem answer phone OFF { Must be OFF }
Mailer MNP connect string /Arq
Using locked fossil FALSE
Prometheus 2400G
----------------
All 10 Dip switches OFF
The default Modem strings
Microcom AX\9624c
-----------------
Set the dip switches as follows:
Front switches Rear switches
1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10
-------------------- --------------------
UP o o o o o UP o o o
DOWN o o o o o DOWN o o o o o o o
Initialization string ATM0Q1S2=255S10=45E0S0=254&D2|
USRobotics Sportster 2400
-------------------------
Initialization string |~ATZ|~~ATX4Q0M0S2=43H0|
Decimal value of Escape Code 43
Let modem answer phone OFF
Novation Professional 2400 (w/std feature module)
-------------------------------------------------
NRAM settings AT&C1&D1V0S9-70S0=0
Initialization string ATZ|~~AT>A0|~~AT>T1|
Let Modem Answer Phone OFF
Delay before answer 500
Rate to lock com port at 2400
Using locked speed TRUE
Avatex 2400 External
--------------------
Using your Terminal emulator program type:
AT&F modem will respond with either 0 or OK
ATX4Q0V0 modem will respond with 0
AT&C1&D2 modem will respond with 0
ATS0=0 modem will respond with 0
AT&W modem will respond with 0
Initialization string |~~ATZ|~~ATM0H0V0|
TPBoard and the Hayes V-Series 9600B
------------------------------------
This modem is so non-standard that code had to be added to
TPBoard to handle it's peculiar methods. Most of its result
codes are hard-coded into TPBoard, and it will work well when
TPBoard is not running under a mailer.
Here are the settings for TPBoard when NOT running
under a mailer.
Result code for OK 0
Result code for RING 2
Result code for CONNECT 300 40
Result code for CONNECT 1200 46
Result code for CONNECT 2400 47
Result code for CONNECT 9600 50
Result code for CONNECT 1200 MNP 99
Result code for CONNECT 2400 MNP
Result code for CONNECT 9600 MNP
Result code for ERROR 2
Off Hook string ATH1|
Answer string ATA|
Hang Up string ATH0|
Delay before answer 500
Initialization string AT&C1&D2H0V0E1Q0M0W1S0=0S2=255|Decimal value of Escape Code 255
Com Port [1 thru 4] 1 { 1, 2, 3, or 4 )
Rate to initialize modem at 19200
Let modem answer phone OFF
Mailer MNP connect string V-Series
Using locked fossil FALSE { Even though you are }
The Hayes 9600B uses a locked rate or a floating rate
depending on whether or not the connection is error correcting or
not.
If for example, you init the modem at 19200, and a call
comes in from another error correcting modem at 2400 baud, the
rate between your computer and the modem will remain fixed at
19200, and the following result codes will be returned;
47 (CARRIER 2400)
80 (PROTOCOL: ALT or another)
14 (CONNECT 19200)
If you had the negotiation progress result codes disabled,
all you would have received was the 14 (CONNECT 19200), which
would not have let TPBoard have the correct connect rate.
If you init the modem at 19200, and a call comes in from
another non-error correcting modem at 2400 baud, the rate between
your computer and the modem will drop to 2400, and the following
result codes will be returned;
47 (CARRIER 2400)
70 (PROTOCOL: None)
10 (CONNECT 2400)
As you can see, sometimes the baud rate is locked, sometimes
it isn't. The only way to really determine what you need to do
is to handle all three connect messages. We know of no Mailers
that will properly handle three connect messages.
Due to this, if you are running under a mailer, you will
still have some problems unless you have one of the newer ROM's
that allows setting S36=7, which causes the baud rate to remain
locked no matter what type of modem you connected with. Since the
first connect string is the actual carrier rate, it will be
passed in the batch file correctly. The last two will be lost,
but it's no big deal.
If you run under FrontDoor, the following settings will
work;
Maximum baud rate 19200
Lock port Yes
300 CARRIER 300
1200 CARRIER 1200
2400 CARRIER 2400 9600 CARRIER 9600
Init-1 AT&C1&D2H0V1E1Q0M0W1S0=0S36=7|
And change one item in TPBoard's hardware configuration as
shown for running without a mailer.
Using locked fossil True
TPBoard and Expanded Memory
===========================
TPBoard will automatically detect the presence of LIM expanded
memory, and if enough is available, it will utilize it for storing
and accessing it's overlay file, and for storing it's memory image
when shelling to DOS. If it finds approximately 360k of expanded
memory free, it will load its overlay in it. If there is still
approximately 170k free, it will use it when you shell to DOS.
If you have more than 170k free, but less than 250k free, then it
will use it only when shelling to DOS.
This will greatly speed up TPBoard's operation, as it will
no longer have to access the disk whenever it needs to load a
unit from it's overlay file, and it won't have to write it's
image out to disk when shelling to DOS.
Using external programs for "Typing" files
==========================================
Due to the continual developments in the file compression
field, there is a good possibility that the internal "Type"
routines will quit working when a new version of one of the
compression programs is released.
To assure that TPBoard's "Type" function will work, there is
a method to force the over-riding of it's internal de-compression
routines. If PKUNZIP.EXE, PAK.EXE, LHARC.EXE, or ARC.EXE exists
in the TPBoard system directory, they will be called to
uncompress their respective format files.
Q&A
===
This section is a grabbag of miscellaneous notes, observations,
and answers to common questions about TPBoard that don't fit in
anywhere else in the Install manual. A file called TPBNOTES.DOC is
available from many TPBoard boards that is updated and shared
between sysops on an irregular basis.
1. What exactly happens during purging?
Loosely, TPBoard is getting rid of old messages, inactive users,
and deleted Newin records. Technically, the following criteria
are used to determine which records get purged.
The Newin file - only records actually marked as deleted
by the sysop get purged by TPBoard or CONS. There is
no age setting for purging NEWIN records.
The Summary file (the Message base) - this is more
complicated processing. Basically, it goes something
like this:
1. Purge by number of messages in echomail areas.
All messages over the purge limit for THAT area
are marked as deleted (starting with the oldest
first).
2. Next, actually delete the database records based
on the deleted flag (just set for echomail areas)
or the purge settings:
= if the message is older than the UNread_
purge_days setting, or
= if the message has been read and is older
than the Read_Mesg_purge setting, or
= if the message has been deleted, AND
= the NoPurge bit is NOT set for this message
3. Finally, pack the message.bb# file without the
message blocks for deleted records(messages).
The User file - Users are purged based on the number of days
since their last login. The number of inactive days
tolerated depends on the user's validation status.
Unvalidated users are generally removed after 30 days.
(If they haven't called back within 30 days to see if
they got validated, they must not want it bad enough!).
Users with the NOPURGE bit set are never purged.
2. Callers answer NO to the "Check for new mail" question yet
TPBoard seems to be doing something. What gives?
When a caller logs in to TPBoard, the system must set up
the last Message and File areas that the caller was in during
the previous call. Part of this is checking for new mail; if
the caller doesn't want to check for new mail, we move on to
the File area setup. This is mostly reading in the directory
of that file area. If it was a large area, reading the
directory can take some time.
3. I am running the network version and every time I try to bring
up a node, TPBoard says "Message files not found, Creating."
Check to ensure SHARE is installed, that is the usual problem.
4. I am running EchoMail and can't get TPBoard to export mail.
I've tried IMPMSGS -EA and everything. What do I do?
Set the DOEXPORT option in CONS to instruct TPBoard to export mail
following each caller session. If you are using IMPMSGS as your
importer, this is the required method for exporting. We hope to
see a version of TosScan that will work fully with TPBoard's
message base in the near future.
5. I received a really large message that TPBoard seemed to chop off,
is that possible?
When TPBoard first loads, the buffers for message entering and
message compression are created. These buffers are 32k each.
Thus, the largest message can only be 32k. In addition, the
sysop can reduce these buffers down to 8k. If you are running
Impmsgs and the imported messages have no text, check this
setting.
6. When TPBoard loads, it tells me I have an unregistered version,
what does that mean?
1) You're running the unregistered version. If you haven't
registered TPBoard by sending in a registration form, then
you are unregistered. There's a file called REGISTER.FRM
that you should read.
2) You have registered but haven't installed your key file. You
should have a file called TPBOARD.KEY (it may not arrive with
that name) in the system directory.
3) You are running the registered network version and have set
the READ-ONLY attribute on the TPBOARD.KEY file. This file
needs to be READ-WRITE in order for TPBoard to access it.
7. I want to use privilege bits and system created menus but want
to display them in a customized format. What do I need to do?
Nothing. TPBoard's system generated menus are formatted by
TPBoard when they are displayed. The only dressing up you can
do to system generated menus is the :N screen in the Sysmsg
file. This screen is displayed just before the current menu as
a sort of header. The very idea of customized yet system
generated menus is contradictory.
8. My users are annoyed that they keep seeing "Press any key"
prompts following every command. Can I turn this off?
Either instruct your users to turn off Auto-Menus in User_Edit
or turn them off for all users by setting Number_of_novice_hours
to 0 in CONS.
9. I don't really understand validation, what does it do?
When a new caller logs in to your system, they are allowed a set
length of time on your system and are assigned an access level
both of which come from the UNvalidated settings in CONS. The
caller remains at this level until the sysop decides to "validate"
them. Historically, the term comes from "validating" the caller's
information such as address, name, and phone number to ensure the
caller is who he says he is.
Once validated, the caller generally gets more time on the system
and is allowed to access more areas of the Board. Under TPBoard+,
you can even allow access to more functions based on the "level"
of validation.
10. I'm using the network version but can't seem to get a second
node up. Either node loads fine by itself, but when I try to
bring up a second node, I get a share violation. Huh?
a) Check to see that Share is begin installed.
b) Check to see that your TPB executable(s) is set to
Read-Only.
Local Sysop Use
===============
This section describes the features of TPBoard that are unique to
the Sysop from the sysop's console
Bringing up TPBoard in local mode.
----------------------------------
Bringing up TPBoard in local mode means that a) TPBoard is not
loaded and waiting for a call, b) that you want TPBoard to load
but go directly to Local mode and c) TPBoard will exit to DOS
following your logoff.
If you are running a stand alone bbs, you probably run TPB
without any command line options and can enter local mode
simply by pressing ^L. You can also bring TPBoard down by
entering ^C.
If you are running under a mailer, you should have the request
to bring TPBoard up in local mode assigned to a hot-key for
your mailer. For example, under FrontDoor, I press F10 to
drop to TPBoard in local mode.
The command line string to bring up TPBoard in local mode
depends on the version you are running. For the single-user
version, the command is:
TPB 99
For network versions, it is:
TPB 99 NODE ## (where XX is the node number for that
workstation)
It is very important that you load TPBoard in any mode very
carefully. If you mistype and enter a 98 instead of a 99,
TPBoard will begin its macro processing. Or, if you just type
TPB with no arguments, TPBoard will load, init the modem, and
wait for a call. You should perhaps create batch files with
unique names to bring TPBoard up in different manners and thus
avoid any potential problems.
Once TPBoard is up, you will notice that you don't see all the
same things during logging in under local mode. You won't see
bulletins, or the welcome screen for example. Further, if
you have fast local logins enabled, you won't even need to
enter a password or name.
The most notable features unique to local mode are the
Shell to DOS in the Sysop menu (described elsewhere) and the
automatic full screen editor when entering messages.
Sysop use during a caller login
-------------------------------
While a caller is on-line, the sysop has the following commands
available (note that many options have alternate keystrokes):
Alt-H - displays a help screen of Sysop options
F1,
^W - Requests an immediate Chat with the caller
F2,
^E - Turns off Remote Copy. While remote copy is turned off,
the caller will see nothing from TPBoard. You'd
typically do this to edit the current caller, to drop to
DOS in local mode (same as remote copy off) to perform
some function, etc.
F3,
^R - Delayed Down mode. This means that
Alt-V - Validate the current caller. If you are running TPBoard+,
you will select from the validation levels you have setup.
If you are not running TPBoard+, the caller will be
validated with the validation settings setup in CONS.
F8 - Add XX number of minutes to current caller. A setting in
CONS determines the value of XX. The current caller is
given more time on for THIS call only and is notified of
the added time.
^T,
F10 - The TWIT key for "twitting" twits who call you system.
F10 will knock the current caller off without warning. I
use it when I see folks logging in with handles despite
my intro screen that specifically instructs them not to.
Windows 3.0
===========
A TPBoard sysop has reported running TPBoard (and FrontDoor)
successfully as background tasks under Windows 3.0. He also
reported no noticeable degradation in performance at 9600
connect speeds.
He set up in enhanced mode with 256k allocated from the base
with an adjustable heap allocation. The com port being used
in TPBoard should be disabled in the Windows Enhanced menu.
Build a Pif file with the above memory requirements. Make
sure you call TPBoard from the system directory.
He also recommends using windowed screens rather than full
screen processing.
Future Plans
============
You might also be interested in knowing where TPBoard is headed,
both in the long term and the short term. The following is a idea
only and isn't meant to be a promise of anything. I'm sure many
people will contribute ideas that aren't on this list which will
change the priorities as listed.
* Internal support for the ARJ archive format.
- Node-to-node split screen chat.
* Avatar level 1 support.
* Extension of drive letters in the section.bb# file to
full DOS paths for databases, files areas, and articles.
- Internal virus detection in addition to the current Shez/Scan
feature.
* Privilege bit control over sysop commands.
- Additional log levels.
* 3-ply message thread linking using message ids.
- Additional validation levels.
* Added system stats for complete on-hand statistics over
all bbs functions and inventories.
* Multi-node on-line conferences.
* Greater flexibility in controlling systems areas, message and
files.
- Internal support for sending FAXMAIL. FAXMAIL will be treated
in all respects like Netmail but messages will be queued for
fax transmission.
* changing the current message reading counters to use dates
rather than individual message numbers. Purging will be much
faster and Reading S)ince will all be easier. All space
currently given to maintaining last read pointers will be freed.
* Increasing the maximum number of message areas to 1024 (or
unlimited)
* Eliminating the need for Remoted by incorporating an internal
ANSI full screen editor OR support for a remoted editor of your
choice.
* Incorporation of all relevant information into the Section.BB#
file such as: origin lines, aka info, full paths, etc...
* An area for personal bulletins.
* denotes features slated for ALL versions
- denotes features slated for the plus version ONLY
Credits
=======
Many people have contributed to TPBoard's development overthe past several years. The following list is by no means
inclusive and we apologize to any who aren't mentioned here
yet who have contributed to TPBoard's development.
Jon Schneider &
Rick Petersen - For their previous hard work on TPBoard.
James Smith - for being the very first supporting user.
Greg Ament,
Gordon Malone - for many hours of work on the network version.
John Nicholson - for his many hours of thorough testing of the
beta version.
Bob Pilsucki - for significant work on the database functions
And the entire beta team of:
Greg Ament John Nicholson Ken Donnell
Chuck Haynes Rick Petersen Jim Heath
Thomas Kaderud James Smith Christian Kaderud
Gerd Qualmann Bob Pilsucki
Numerous others have contributed to TPBoard by making suggestions
for improvements or by reporting problems. It would be impossible
to list every individual who recommended every feature or every
change to every feature. They can be content in the knowledge
that they are using a better board for their efforts.
THE END