ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / MISC / TPB71DOC.ZIP / INSTALL.DOC next >

Wrap

Text File | 1992-04-03 | 243.5 KB | 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 the SYSTEM 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 YOUR system, 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 this batch 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 20 constants. 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 the same 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, your outgoing 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 local console. 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 directory for 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 handle exporting 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 dedicated Server, 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, you must 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, you need 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 the additional 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 over the 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