home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
BBS
/
CEL202R.ZIP
/
CEL202-3.ZIP
/
CELERITY.DOC
next >
Wrap
Text File
|
1994-08-29
|
360KB
|
10,123 lines
C E L E R I T Y B B S
Version 2.02
Copyright 1990, 1992, 1993, 1994
All rights reserved worldwide
Written by Brendon Woirhaye and Dave Hicks
Legal "Stuff"
=============
CELERITY SHAREWARE SOFTWARE LICENSE
-----------------------------------
***** This version of CELERITY is neither public domain *****
***** nor is it free software, but is being distributed *****
***** as "shareware" for EVALUATION PURPOSES ONLY. *****
Copyright, Proprietary Rights
-----------------------------
The CELERITY software and documentation is owned by Brendon
Woirhaye and Dave Hicks. It is protected by United States copyright
laws and international treaty provisions. You may not reverse
engineer, decompile, disassemble, or create derivative works based
on the software for any purpose. This software embodies valuable
trade secrets proprietary to the authors; you may not disclose any
information regarding the internal operations of this software to
others.
Usage Restrictions
------------------
The Authors grant a limited license to individuals to use this
shareware software for a 30-day evaluation period for the express
purpose of determining whether Celerity is suitable for their
needs. At the end of this 30-day evaluation period, the individual
must either purchase a license and receive a validation key for
continued use of the program, or discontinue using Celerity.
Archival copies of the Celerity validation key may be made by the
owner of a Celerity license for his personal use and protection
only. In no circumstances is a sysop to give his Validation key to
someone else. If the sysop does release his validation key, he will
lose all rights to support and future updates of Celerity.
What does this mean? If you use this program on a continued basis,
you must purchase a license for its use. Celerity is NOT free, and
we are not giving away free copies. We are giving you the
opportunity to try it before paying for a license for continued
use. It is that simple. Try it. Then either pay for it, or quit
using it.
Paying for a license to continue using the software product is not
only required, but also allows the authors to provide support and
updates, and stay in business. Licensed users receive technical
support (by a support BBS), and makes them eligible for substantial
discounts on future versions.
Purchasing a license for Celerity entitles you to use the program
on only one computer system. (Multiple computers, networked to
support multi-node operation are considered as one computer
system). If you would like a site license, please contact the
authors for details.
Distribution, Copying Restrictions
----------------------------------
Individuals are granted a limited license to copy the shareware version
of Celerity only for the trial use of other individuals and subject to
the above limitations. This license DOES NOT include distribution or
copying of this software package:
1: In connection with any other product or service;
2: For general use within a company, institution, or agency;
3: For any consideration or 'disk fee'; or
4: In modified form (i.e., any distribution that does not include
ALL FILES supplied with the shareware version WITHOUT ALTERATION.
This also prohibits distribution of all or portions of the
documentation in printed form.)
Operators of electronic bulletin board systems (Sysops) are permitted
and encouraged to support the ShareWare concept and post the shareware
version of Celerity for downloading by their users, as long as the
above conditions are met. Though a fee may be charged for BBS access,
NO FEE may be charged to specifically access or download the Celerity
shareware files.
Non-profit computer-related User Groups may distribute the
shareware version of Celerity provided the above conditions are
met. However, such User Groups MAY charge a NOMINAL fee (not to
exceed $5.00 US) to cover the cost of the disk and copying of the
software.
Disk vendors MUST obtain written permission from the authors before
distributing the shareware version of Celerity. Certain
restrictions apply.
Warranty Disclaimer
-------------------
THE AUTHORS PROVIDE THE SHAREWARE VERSION OF CELERITY "AS IS" AND
WITHOUT ANY WARRANTY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW,
THE AUTHORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO, ANY IMPLIED WARRANTY OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. SPECIFICALLY, THE AUTHORS MAKE NO
REPRESENTATION OR WARRANTY THAT THE SOFTWARE IS FIT FOR ANY
PARTICULAR PURPOSE.
THE AUTHORS SHALL NOT BE LIABLE FOR ANY DAMAGES RESULTING FROM THE
USE OF THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO, LOSS OF PROFIT,
DATA OR USE OF THE SOFTWARE, OR SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES OR OTHER SIMILAR CLAIMS, EVEN IF THE AUTHORS
HAVE BEEN SPECIFICALLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
SOME STATES DO NOT ALLOW THE EXCLUSION OF INCIDENTAL OR
CONSEQUENTIAL DAMAGES, SO THE FOREGOING LIMITATION MAY NOT APPLY.
US GOVERNMENT RESTRICTED RIGHTS
-------------------------------
This software and documentation are provided with RESTRICTED
RIGHTS. Use, duplication or disclosure by the U.S. Government is
subject to restrictions as set forth in subparagraph (c)(1)(ii) of
the Rights in Technical Data and Computer Software clause at
252.227-7013. Ordering Information
Purchasing a license for Celerity allows you to use the product on
a regular and/or continuing basis. Registration of your licensed
copy of Celerity entitles you to technical support from the authors
BBS, discounts on updates, and access to the Registered Sysop area
of our support BBSes
With your purchase, you will receive your Validation key, tailored
for your particular BBS.
Ordering Information
--------------------
For further information and current pricing, please see
REGISTER.DOC.
We offer discounts to educational institutions, US government
agencies, and various approved computer-related User Groups.
Contact us for details.
Site Licenses and Quantity Purchases:
-------------------------------------
All corporate, business, government or other commercial, public, or
private users of Celerity must be licensed. We offer quantity
discounts as well as site licensing. Please call or write for more
information. Please see SITELICN.DOC for details
Orders Outside the U.S./Canada/Mexico:
--------------------------------------
Please send a check drawn on a US bank payable in US dollars.
Please add $10 for each copy to cover overseas shipping.
Table of Contents:
------------------
Legal "Stuff" . . . . . . . . . . . . . . . . . . . . . 2
CELERITY SHAREWARE SOFTWARE LICENSE . . . . . . . . . . . . 2
Copyright, Proprietary Rights . . . . . . . . . . . . . . 2
Usage Restrictions . . . . . . . . . . . . . . . . . . 2
Distribution, Copying Restrictions. . . . . . . . . . . . . 4
Warranty Disclaimer. . . . . . . . . . . . . . . . . . 4
US GOVERNMENT RESTRICTED RIGHTS. . . . . . . . . . . . . . 5
Ordering Information . . . . . . . . . . . . . . . . . 5
Site Licenses and Quantity Purchases: . . . . . . . . . . 5
Orders Outside the U.S./Canada/Mexico:. . . . . . . . . . 5
Section 1: What Is Celerity? . . . . . . . . . . . . . . . . 1
General Description. . . . . . . . . . . . . . . . . . 1
List of features: . . . . . . . . . . . . . . . . . . 1
Hardware Requirements . . . . . . . . . . . . . . . . . 6
Required Extras . . . . . . . . . . . . . . . . . . . 6
Section 2: Setting Up Celerity. . . . . . . . . . . . . . . . 7
Initial Setup. . . . . . . . . . . . . . . . . . . . 7
Preparation . . . . . . . . . . . . . . . . . . . . 8
Demo Installation . . . . . . . . . . . . . . . . . . 8
Registering Celerity . . . . . . . . . . . . . . . . . 9
New System Installation . . . . . . . . . . . . . . . . 9
Upgrading . . . . . . . . . . . . . . . . . . . . 11
Upgrading from Celerity BBS v1.42 or Alacrity v1.42: . . . . 11
Upgrading from Celerity BBS v2.00 or 2.01. . . . . . . . 12
Running CELSETUP.EXE . . . . . . . . . . . . . . . . 13
System Info. . . . . . . . . . . . . . . . . . 14
System Options. . . . . . . . . . . . . . . . . 14
Look and Feel Settings . . . . . . . . . . . . . . 17
Serial Port Setup. . . . . . . . . . . . . . . . 19
Modem Setup. . . . . . . . . . . . . . . . . . 20
Custom Modem Strings . . . . . . . . . . . . . 23
Video Options . . . . . . . . . . . . . . . . . 24
Login Sequence. . . . . . . . . . . . . . . . . 25
Transfer Options . . . . . . . . . . . . . . . . 27
Color Settings. . . . . . . . . . . . . . . . . 31
Pathnames . . . . . . . . . . . . . . . . . . 32
Multinode Options. . . . . . . . . . . . . . . . 35
Chat Options . . . . . . . . . . . . . . . . . 36
System Passwords . . . . . . . . . . . . . . . . 37
Timed Events . . . . . . . . . . . . . . . . . 38
Access Levels . . . . . . . . . . . . . . . . . 39
Login Shell. . . . . . . . . . . . . . . . . . 41
Login Commands. . . . . . . . . . . . . . . . . 43
Information Scripts . . . . . . . . . . . . . . . 44
New User Options . . . . . . . . . . . . . . . . 45
User Ratios. . . . . . . . . . . . . . . . . . 50
Access Templates . . . . . . . . . . . . . . . . 51
Quick Validation Templates. . . . . . . . . . . . . 52
Running Multiple Bulletin Board Systems . . . . . . . . . . 54
Multi-node Operation . . . . . . . . . . . . . . . . 56
Celerity Under DesqView. . . . . . . . . . . . . . 59
Standard Options . . . . . . . . . . . . . . 59
Advanced Options . . . . . . . . . . . . . . 60
Celerity under Windows . . . . . . . . . . . . . . 62
Celerity under Windows 4.0 "Chicago" . . . . . . . . . 65
Celerity under OS/2 . . . . . . . . . . . . . . . 66
Setting up your Celerity DOS Session under OS/2 . . . . 67
Setting up your Celerity OS/2 Session under OS/2. . . . 68
Setting up your OS/2 CONFIG.SYS for running Celerity . . 69
Celerity under a Local Area Network. . . . . . . . . . 71
Running Celerity from a RAMdisk. . . . . . . . . . . . . 72
Modes of Operation . . . . . . . . . . . . . . . . . 74
CAE Mode. . . . . . . . . . . . . . . . . . . 74
CAE/TAC Mode . . . . . . . . . . . . . . . . . 75
MAIN.BAT Operational Details. . . . . . . . . . . . . . 77
Command Line Parameters. . . . . . . . . . . . . . 77
Running MAIN.BAT For The First Time. . . . . . . . . . 77
Celerity Access Conditions . . . . . . . . . . . . . . 79
Celerity Conference System . . . . . . . . . . . . . . 81
Conference Structure. . . . . . . . . . . . . . . 81
Creating Conference Trees . . . . . . . . . . . . . 85
Creating Message Sub-Boards . . . . . . . . . . . . . . 87
FidoNet Conferencing. . . . . . . . . . . . . . . 89
Using QWK Offline Readers . . . . . . . . . . . . . 89
Setting Up A Transfer Section . . . . . . . . . . . . . 90
Creating Transfer File Areas . . . . . . . . . . . . 90
Setting Up Doors. . . . . . . . . . . . . . . . . . 92
Door Example . . . . . . . . . . . . . . . . . 93
Section 3: BBS Operations . . . . . . . . . . . . . . . . 94
Wait For Calls Screen . . . . . . . . . . . . . . . . 94
Online Commands . . . . . . . . . . . . . . . . . . 97
Inside the BBS . . . . . . . . . . . . . . . . . . 98
Section 4: Customizing Celerity . . . . . . . . . . . . . . 99
Introduction . . . . . . . . . . . . . . . . . . . 99
Color Codes . . . . . . . . . . . . . . . . . . . 99
The CelerityText Display System. . . . . . . . . . . . . 101
What is CelerityText? . . . . . . . . . . . . . . 101
Editing CelerityText files. . . . . . . . . . . . . 102
Command Directives . . . . . . . . . . . . . . . 103
Information Scripts. . . . . . . . . . . . . . . . . 108
The Infoscript Display File . . . . . . . . . . . . 108
The Infoscript Answer File. . . . . . . . . . . . . 109
Infoscript Command File. . . . . . . . . . . . . . 109
Customizing Text Files. . . . . . . . . . . . . . . . 118
Customizing Console Commands. . . . . . . . . . . . . . 119
How to Customize the Keyboard. . . . . . . . . . . . 119
Internally Supported Commands. . . . . . . . . . . . 120
Online Tools . . . . . . . . . . . . . . . . . . . 123
Section 5: Strategies for Running a Good Board . . . . . . . . . 125
Introduction . . . . . . . . . . . . . . . . . . . 125
Policies . . . . . . . . . . . . . . . . . . . . 125
Local callers . . . . . . . . . . . . . . . . . 125
Slow Callers . . . . . . . . . . . . . . . . . 126
Access requirements . . . . . . . . . . . . . . . 127
Rules of Conduct . . . . . . . . . . . . . . . . 127
Voice Validation . . . . . . . . . . . . . . . . 127
Access Levels . . . . . . . . . . . . . . . . . 128
Advertising. . . . . . . . . . . . . . . . . . 128
Appendices . . . . . . . . . . . . . . . . . . . . . 130
Appendix A, Serial I/O Chips. . . . . . . . . . . . . . 130
Appendix B: An Introductory Lesson in High-Speed Modems. . . . . 133
A Modem Story . . . . . . . . . . . . . . . . . 133
What makes two modems compatible? . . . . . . . . . . 133
CCITT and ITU: International Standards . . . . . . . 134
Baud and bps: Are they the same? . . . . . . . . . 134
Data Transmission Protocols ("Speed") . . . . . . . . . 135
Error Correction and Data Compression Protocols. . . . . . 141
Other error correction and data compression protocols. . . . 143
Summing Up Modems. . . . . . . . . . . . . . . . 145
Appendix C: Index Of Files Used By Celerity BBS . . . . . . . 146
Conference Directory: . . . . . . . . . . . . . . 146
Multinode Directory:. . . . . . . . . . . . . . . 148
Electronic Mail Directory:. . . . . . . . . . . . . 149
Language Directory: . . . . . . . . . . . . . . . 150
Data Directory: . . . . . . . . . . . . . . . . 151
Node Directory: . . . . . . . . . . . . . . . . 153
Main BBS Directory: . . . . . . . . . . . . . . . 155
Display Directory: . . . . . . . . . . . . . . . 156
Appendix D: References. . . . . . . . . . . . . . . . 159
Trademark Information. . . . . . . . . . . . . . . . . . 162
Credits and Acknowledgements . . . . . . . . . . . . . . . 163
AFTERWORD: The Tao of BBSing . . . . . . . . . . . . . . . 165
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Section 1: What Is Celerity?
============================
General Description
-------------------
Celerity is a BBS which attempts to combine:
1. The best features of other BBS software.
2. The newest innovations in BBS technology.
3. New and original concepts.
4. Seamless integration of highly configurable options.
Various utilities exist for celerity, and more are released every day by both
members of the celerity project and 3rd party programmers. As they are finished
and declared bug "Free" they are distributed on the Celerity Support BBS and
other sites around the world.
List of features:
-----------------
(> Celerity is capable of hosting a wide array of message and transfer areas.
(> Celerity supports unlimited message conferences.
(> Celerity supports unlimited transfer conferences, with up to 999 sub-areas in
each conference.
(> In conjunction with CelToScn (freeware utility) and a front-end mailer,
Celerity can participate in any Fido technology network.
(> Celerity is optimized for speed.
(> It takes advantage of 286 / 386 / 486 / Pentium(586) processors (if present)
for quick memory access.
(> It fully supports the 1655x class of buffered UARTs (SIO chips) for greater
efficiency.
(> Celerity is designed with high speed modems in mind. Particular support has
been given to 9600, 14,400, 16,800, and 19,200, 21,600, 24,000, and 28,800 bps
modems.
(> True high-speed DTE rates from 19200 to 115200 bps. Get the maximum
performance your modem and serial card can handle.
(> Complete support for v.42, v.42bis, v.32, v.32bis, v.32Ter, v.Fast, v.FC,
v.34, HST, PEP, TPEP, and MNP Modems.
-----------------------------------------------------------------
Celerity v2.0 Page 1
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
(> FAT file move for incredible file management speed.
(> ANSI/Avatar/VT100 display enhancement.
(> Internal ANSI driver to end reliance on slow DOS ANSI drivers which other
many other BBS programs use. - Full support of Avatar/0+ specification,
including character repetition, cursor positioning, and color support.
(> Scrollback for the local console which saves the entire session.
(> Translation of ANSI display screens to Avatar for improved speed. Ability to
disable color for even greater speed.
(> Communications support for the North American Presentation Level Protocol
Syntax (NAPLPS) graphics standard (ANSI X3.110-1983) for menus and displays.
(> Communications support for the Remote Imaging Protocol (RIP) graphics
standard designed by TeleGraphix Communications, Inc.
(> Users can be given or denied access to any of the transfer or message
conferences. Access rights can be granted to any area based on Sysop selected
attributes (Such as transfer level, age, sex, bps rate, node, etc..(32 sysop
flags and 32 user flags in all!) Access can be given to all new users, as users
are quick-validated, or manually at any time thereafter.
(> User template system allowing the sysop to set up a template to control
specific access level ranges.
(> Quick validation templates allow a sysop to give a user any set of access
details at the press of one or two keys, rather than setting each option
individually.
(> With menu scripting, access can be further distinguished on the basis of age,
bps rate, transfer/message conference flags, sysop access flags, security level,
transfer level, and more.
(> New users can be "Quick Validated" with one keystroke. No need to edit each
access flag unless you desire to.
(> Fully automated new user voting (NUV) section, to allow your
users to decide who gets access and who doesn't. The sysop has veto power, of
course.
(> New user voting section can be completely automated, at the sysop's
discretion.
-----------------------------------------------------------------
Celerity v2.0 Page 2
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
(> New users can be required to upload an example of their newest software, for
examination by sysop and new user voting committee. Complete user editing
available while the user is online.
(> "Suggested Point Value" to make file validation easy.
(> Automatic Archive commenting if desired.
(> An internal upload processor which can:
1: Comment archives
2: Clean archives (Delete ads)
3: Verify archives
4: Scan for viruses
5: Import file_id.diz and desc.sdi descriptions
(> An optional freeware Upload Spooler (UPSPOOL) which can perform all the
functions of the upload processor in the background or after a caller hangs up,
so the user does not have to wait for his upload to be processed before
continuing BBS use.
(> An optional freeware remote access utility (REMOTE.EXE) which allows a remote
sysop to drop to DOS and run nearly any character-based application as if
he was at the BBS console.
(> Auto-Validate allows the sysop to have all uploads either automatically
cleared for downloading as soon as they are uploaded or held for manual release
by the SYSOP.
(> Easy-to-use setup program.
(> A multitude of sysop-configurable options.
(> Celerity is one of the most fully configurable BBS programs available on the
market today, despite its low cost.
(> Fully configurable logon shell. Shell commands can be added and removed as
the sysop desires, and each command is fully configurable. The shell can exist
as either a conventional menu-type shell, a DOS simulator shell, a UNIX
simulator, VMS simulator, an interactive lightbar shell, or even an external
sysop-developed shell. The shells are optional, of course, and can be disabled.
(> CelerityText files. Virtually all of the text in Celerity v2.0 is contained
in external CelerityText language files which can be easily edited by the sysop
to tailor the text to his or her BBS. Anything from simple text changes to a
completely new motif can be designed. Multiple CelerityText files can be used
at once on a BBS, allowing users to choose a motif or language of their
preference, and multiple CelerityText files will be available on the support
BBSes. CelerityText language files support an extensive list of command
-----------------------------------------------------------------
Celerity v2.0 Page 3
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
directives allowing the language artist to insert information about the user,
about the board, or context-sensitive details. Celerity's CelerityText files
are dynamic, and therefore the entries are not restricted to fixed-length data
strings as most other software (PCBoard, Searchlight, WWIV, Remote Access,
Telegard). If you have need for it, a text entry can be many megabytes in
length (for animated or graphical displays, perhaps).
(> Foreign Languages are fully supportable through the CelerityText files,
translations are lined up for German, Spanish, Norwegian, Swedish, and Russian.
(> Fully configurable file listings. Each user can choose what file list
information he or she desires.
(> Configurable menu scripting. Celerity allows the sysop to redefine which keys
do what on any particular menu. Sysops can also change the command descriptions,
access requirements (including access discrimination based on access levels,
sysop access flags, age, bps rate, and more). Sysops can even delete commands to
tailor the BBS to their own particular needs.
(> Configurable login sequence. The sysop can choose which events will be
engaged for the user, and in which order they will occur. Celerity's login
is not limited to internal static events. The login sequence can display
external files and even run external doors.
(> Celerity will support COM 1-4 with its standard internal drivers and
selections, COM 0-8 as "configurable" ports with fully configurable addresses,
interrupts, and IRQ's(Com Port 0 allows the BBS to be run in "Local only mode"),
or COM 0-36 as DigiBoard ports. With any of the internal COM port selections,
the board will co-exist with a FOSSIL driver.
(> File commission system. If the sysop desires, users will get file points
every time their upload is downloaded. You can even have it set up so a user
gets NO points for uploading, and only gets points when people download his
file. This way, users are not rewarded for uploading files that nobody wants,
and users who upload good ones are well rewarded for their efforts.
(> CAE mode. Celerity once again brings a new revolution (or a very old one, if
you were familiar with the old AE's and Catfurs in the Apple community years
ago) to the PC modem world.
(> Celerity is compatible with Fido EchoMail and QWK-compatible networks.
(> Celerity supports Multi-node operation.
(> Using network cards or a multitasking operating system, Celerity can support
up to 250 sperate nodes.
-----------------------------------------------------------------
Celerity v2.0 Page 4
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
(> Celerity has been tested extensively under DesqView, DesqView/X, Windows 3.x,
Windows 4.x (Chicago), and OS/2 for multiple nodes on a single machine. In
addition, enhanced multitasking abilities including intelligent time slice
management have been tested under DesqView, Windows, and OS/2.
(> Celerity works like a charm under Novell Netware, Netware Lite, and PowerLAN.
Even under the fickle LanTastic, Celerity can run multiple nodes.
(> Fully functional multinode chat to allow users to talk to each other directly
or split-screen chat supporting up to 8 simultaneous users with a self-
adjusting display: 25 line users get 25 lines, 43 line users get 43, and 50 line
users get 50.
(> EGA/VGA card support. Celerity has full support for a 43 line (EGA) or 50
line (VGA) screen for the local display.
(> Sound Card Support. Celerity can use sound cards to use much more extensive
chat calls. Celerity will even support a unique chat for each and every
individual user.
-----------------------------------------------------------------
Celerity v2.0 Page 5
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Hardware Requirements
---------------------
Celerity requires the following for operation:
(> IBM AT compatible computer (286 through Pentium)
(> Non-IBM compatible computer with MS-DOS emulation (NeXT/Macintosh/Windows
NT/UNIX system with SoftPC) *no guaranty about functionality - try it*
(> XT support with the 8088/8086 supplement.
(> Hard disk drive with at least 5 megs free, 10+ recommended. A large BBS
should have hundreds of megabytes at its disposal.
(> Although some systems may run with as little as 320K, 640k RAM is recommended
with AT LEAST 1024k EMS. The more memory Celerity has available, the greater
its performance will be.
Required Extras
---------------
Celerity requires the use of a few other Shareware programs, or
their equivalent. These are listed below:
(> An archive utility. Celerity will allow the use of any of the standard
Archive programs such as PKZIP, LHA, ARJ, PAK, DDD, ZOO, ARC, and Teledisk.
These files can be obtained on most BBSes.
(> DSZ.COM (or a DSZ-compatible protocol) is required for basic upload/download
transfers. HS/Link is required for bidirectional transfers.
(> Q-Edit is the external editor of choice for Celerity, although any external
text editor may be used with equal compatibility, such as DOS 6's EDIT, or even
(GASP!) EDLIN.
(> For the ANSI editor, We recommend TheDraw, which is an excellent tool for the
creation and editing of nice single page ANSI screens. For Multi-page designs,
you might try "The Laughing Dog" utilities.
-----------------------------------------------------------------
Celerity v2.0 Page 6
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Section 2: Setting Up Celerity
==============================
Sysops setting up Celerity for the first time should read this file IN ITS
ENTIRETY, as they will find it answers a lot of their questions. The
documentation file(s) give you all the needed information.
If you have run a BBS before, you will find that Celerity has it's own unique
feel, but you should pick up the commands and structure quite easily.
If you have never run a BBS, I would recommend that you start out slowly.
Celerity is highly automated and easy for an experienced sysop to run, but it is
NOT a simple piece of software, and can cause great frustration to inexperienced
sysops if they set up too much too soon.
Initial Setup
-------------
Celerity version 2.02 may be found in two distribution formats. The first is the
preferred format called CEL202R.ZIP, and is designed for high speed electronic
transfer or 1440k diskette distribution. The second distribution format consists
of the five sub-archives included in CEL202R.ZIP, which are more appropriately
sized for low-speed electronic transmission or 360k diskette distribution. The
first format is simply a re-packaging of the second format archives. The main
distribution archive consists of the following files:
CEL202-1.ZIP : Main Celerity BBS v2.00 Program Files.
CEL202-2.ZIP : Support files including CELSETUP.EXE and
CelerityText files.
CEL202-3.ZIP : Celerity BBS v2.00 Documentation.
CEL202-4.ZIP : Selected third-party utilities for Celerity v2.00.
CEL202-5.ZIP : Additional files needed for Celerity BBS
demonstration.
INSTALL .EXE : Menu-driven installation program for Celerity
BBS v2.02.
File_ID .DIZ : Description for BBS importation.
REGISTER.DOC : Celerity BBS Registration information.
READ .ME : Installation and distribution notes.
Celerity BBS releases, updates, utilities, CelerityText, etc. may be obtained
from the Celerity BBS support system:
United States:
Terrapin Station
310-693-9405
2400-21,600 bps HST/v.32b/v.32ter
-----------------------------------------------------------------
Celerity v2.0 Page 7
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Preparation
-----------
Before you begin, you should locate the following programs and utilities (all
are recommended but not essential):
PKZIP.EXE, PKUNZIP.EXE, ARJ.EXE, LHA.EXE, DSZ.COM/DSZ.EXE/GSZ.EXE, and HSlink.
Place these files in your BBS directory (as specified in the celsetup program).
If you do not have registered copies of these programs, please acquire copies
from most any BBS and register them.
Demo Installation
-----------------
Release versions of Celerity BBS are always packaged with a demonstration
version so that perspective sysops can set up the software and get a feel for it
before they buy. The only differences between a registered and a non-registered
version are that a non-registered system has a nasty Nag screen system (The
USERS see the Nag Screen!)
To install the demo, run INSTALL.EXE and select "Demo Install" from the menu.
Installation of the demonstration version requires approximately two megabytes
of free space. Select one of the menu sets from the list when prompted. At the
current time, the demo can only be installed correctly to the C:\CELERITY path.
If you install the demo to a path other than c:\celerity, you will have to
change the pathnames in CELSETUP.EXE for the demo to function properly.
Once you have completed the installation, you should exit and switch to the demo
directory. There, type "MAIN" to run the BBS. In a moment you should be
presented with the wait for call (or WFC) screen. Pressing F10 will initiate a
local log on. The demo initially has the lightbar logon shell selected, so you
should now look through the available options (the arrow keys may be used to
move from option to option, and [ENTER] to select) and choose the "Logon to
Celerity Demo".
After the introduction screen, type "Sysop" as the user name. After a moment, a
prompt for your password will come up. Also appearing on the local screen will
be a blow up box telling who the user is and what their password is - so you can
tell easily what password to use. Type it in, and you are on the system!
The first time you logon with the new account, you will be prompted for your
real name, birth date, age, sex, and phone number. You will then get to fill out
an information script, and also asked for a permanent password. It is vital
that you select a password which nobody else knows (ie: do not use one you use
on other bulletin boards) or one which is easy to guess (such as your phone
number, any personal names, or any computer-related terms). The best password
would be a meaningless collection of letters, numbers, and punctuation.
Remember that your password will be displayed to you at the local console, so
-----------------------------------------------------------------
Celerity v2.0 Page 8
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
you are in no danger of being locked out of your system by losing your password.
Anyone who can log into the BBS with sysop access has the potential to cause
great harm to your system, and there are people out there who thrive on such
challenges, so don't tempt them with an easy-to-hack password.
Now you will be in the system proper. Feel free to move around and experiment.
You will find some email waiting to be read, a few messages in the message
section, some artwork and some files in the transfer area. Press Alt-H to get a
list of local console commands (see the section below on "Customizing Console
Commands). Any of these can be used while you or a user is online. The demo BBS
is rather sparse, of course, because it lacks the activity and fullness of a
completely set up system.
Once you become somewhat familiar with the options and various sections of the
system, exit the software and run the CELSETUP.EXE utility, and begin modifying
some of the options. Don't change too many things without first viewing their
effects. Set up your serial and modem information in CELSETUP.EXE, and have a
friend or two call your system to check it out. If you like what you see, re-run
CELSETUP.EXE and fill out the registration form.
If you would like to see a high volume system running Celerity, feel free to
call the Celerity support BBS at 310-693-9405 (2400 v.22, 9600-14.4kbps v.32,
9600-16.8kbps HST, 16.8k-21.6k v.32ter). First-time users can access most of the
features which are enabled on this BBS.
Registering Celerity
--------------------
To run a registered copy of Celerity, you must obtain a Celerity registration
key. Read the REGISTER.DOC file packaged in the Celerity distribution archive
for details on pricing and where to obtain this key from.
Once you obtain your CELERITY.KEY file, you should copy it to the Celerity BBS
"node" directory. You must have a copy of the key in the home directory for
each node of the BBS. Do not edit your CELERITY.KEY file, or it may not
function properly. Please make a safe backup of your registration key.
New System Installation
-----------------------
Once you have looked the demo over, you will probably want to start customizing
the system to reflect your vision of what a bulletin board would be. We
recommend you start with a previously installed demo version, and work from
there.
Run the CELSETUP.EXE utility, and set up all the options you desire to change.
Start with a few items, and work up to more complex settings. Please refer to
-----------------------------------------------------------------
Celerity v2.0 Page 9
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
this document if you have questions about what specific options do. Exit
CELSETUP.EXE and run MAIN.BAT to start the BBS.
When you run MAIN.BAT the first time, Celerity will probably create a few
directories which did not exist. If you run into problems here, enter
CELSETUP.EXE again and verify all directory locations.
When the "wait for call" (WFC) screen appears, type F10 to log on locally. A
default sysop account will be created for you, but it probably will not be set
up with the access and preferences you desire. Once you log on, you will be
prompted for your real name, sex, phone number, age, birthdate, and a password.
You will also be asked to fill out any information scripts you have defined.
Once these tasks have been completed, log into the BBS and get to the main
menu/main level prompt. Select the command to give yourself temporary sysop
access (Alt-S with the basic keyboard setup), and enter the sysop section (the
"%" command). "U" enters the user editor, and "E" will edit your account. Set
your access level to 100, and turn on all sysop access flags, and quit the user
editor.
The next step is to enter the user configuration section (Normally "K" from the
main menu). Select your display preferences, option toggles, and the like. Once
you complete this, you should set up your sub boards and transfer sections so
your system has something for users to do.
-----------------------------------------------------------------
Celerity v2.0 Page 10
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Upgrading
---------
Celerity BBS is designed to be easily upgradable from version to version, but
there are sometimes some extra procedures which must be performed for a clean
upgrade. Please refer to the UPGRADE.DOC file (in the Celerity documentation
directory if you installed via INSTALL.EXE, in CEL20?-3.ZIP if you install
manually) for detailed instructions for the particular version you are using.
Upgrading from Celerity BBS v1.42 or Alacrity v1.42:
----------------------------------------------------
Because Celerity v2.0 is a major departure from versions 1.4x in many ways, the
upgrade path is not so simple as is usually the case. It is recommended that
you set up a demonstration v2.0 system and get it running, then import your data
files one by one to keep the upgrade as simple as possible.
By all means MAKE A BACKUP of all your BBS program and data files before you
upgrade!
Once you get your demonstration system running, you can copy your USERS file
from your old BBS directory to the new BBS directory, and run the board again.
Celerity v2.00 will automatically convert the user list to the new format.
You can copy your old SETUP.DAT from your old NODE directories to your new NODE
directories, but if you do this make sure you go through and check each and
every option to make sure it is correct, as there have been a number of setup
changes.
All message areas and structure will be lost. You will need to create new
message bases and conferences with version 2.00.
File transfer areas can be converted from v1.42 to v2.0, as can file areas, but
it is not a simple task. Your first step should be to run the v2.0 system and
create a transfer conference. Create as many file sections (the equivalent of
an old file conference) as you had old conferences, and write down the data
names assigned to each one (the extension will be .XFR). Exit the BBS, and
locate your old AREADIR.x files in your v1.42 DATA directory (the x being
a number from 1 to 5, for conferences #1 through #5). Copy these files to your
new v2.0 CONFERENCE directory, and copy them over the newly created *.XFR files.
Run the v2.0 BBS again and make sure that the area attributes for all of your
imported file areas are accurate. You can use the FIXFILE.EXE utility to help
facilitate this task. You may want to change the data pathnames of each area to
correspond to your new directory structure and manually move the *.DIR files
from your old DATA directory to the new v2.0 DATA directory.
The next step is to convert all of your file data. You may have noticed that
you can list files, but there are no descriptions and they may have funny
-----------------------------------------------------------------
Celerity v2.0 Page 11
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
attributes on them. To fix this, you need to go to the directory where your
file area .DIR files are and run the CONVFILE.EXE program. CONVFILE.EXE will
convert your old v1.42 .DIR files to the new v2.0 .DIR/.DES files.
Your BBS List may be preserved if you use the BBS conversion utility written by
Steve Rosin. It is available on the support BBS.
Your Art Gallery may be preserved by copying the GALLERY.DAT file from your
v1.42 BBS directory to GALLERY.ART in your v2.0 CONFERENCE directory. The
converted file may show some quirks (in the # of times viewed and the art type)
as it is not fully compatible with v2.0.
Your Doors section will be lost. Copy down the pertinent information from your
v1.42 Doors section and re-enter it in v2.0.
Celerity v1.42 infoforms are incompatible with v2.0 information scripts, and
will have to be replaced. See the section on "Information Scripts" for details.
Your electronic mail will be lost when you convert to v2.0. Your oneliners,
history, and top ten status can be preserved by copying the following files from
your old BBS directory to the new DATA directory: HISTORY.DAT, ONELINER.DAT,
TOPTEN.DAT
***** By all means MAKE A BACKUP of all your BBS *****
***** program and data files before you upgrade! *****
Upgrading from Celerity BBS v2.00 or 2.01
-----------------------------------------
Upgrading from version 2.00 or v2.01 to 2.02 is quite easy, as most data files
are compatible with the previous versions. You WILL have to delete all *.QS?
files from your CONFERENCE directory, and your users will have to reconfigure
their newscans the first time they log onto the new system. Please see
UPGRADE.DOC for full details on upgrading.
Please keep in mind that you may need to upgrade your language and menu files
for full 2.02 compatibility. If you have your own files to maintain, see the
TEXTCODE.NFO file in the CEL202LD.ZIP (Celerity v2.02 Language Development Kit)
supplement. There will be v2.02- compliant language and menu files available on
the support BBS as well.
-----------------------------------------------------------------
Celerity v2.0 Page 12
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Running CELSETUP.EXE
--------------------
The CELSETUP.EXE program is used to set up all the information about your
system and BBS that Celerity needs. It will allow you to enable and disable
eatures, adjust parameters, define your hardware, and more. This section covers
the basic set up and configuration of the Celerity BBS package. Later sections
will cover other items of consideration when setting up a BBS, including
multinode operation, networking, message area creation, and transfer section
options.
When running the demonstration from C:\celerity, you should not need to run
Celsetup at all to run the demo. After looking around in the demo, however, you
may want to look Celsetup over to get an idea of the flexibility you have with
Celerity. If you install the demo in a directory other than c:\celerity, you
will have to edit pathnames in CELSETUP and in the BBS itself.
When CELSETUP is run, you will be presented with a desktop containing a menu bar
with two menus and a window containing a slew of buttons.
The first menu on the menu bar contains an "About" display. The second menu
allows you to bring up the "Celerity Setup Topics" (the buttons).
The dialogs in CELSETUP.EXE mimic those found in most graphical user interfaces
(GUI) in that they use pulldown menus, windows, buttons, radio buttons, and
more. If you have a mouse, the setup will be much easier and quicker to use,
but you may still use the keyboard. If you use the keyboard, use arrow keys or
tab/shift-tab to move from field to field, and return to select a field.
Check boxes are boxes which appear as "[ ]". If you wish to enable that option,
select the box with the mouse or keyboard, and click (or press space) on it.
The selected box will now appear as "[X]", meaning that option has been
selected.
Radio buttons are a series of buttons which appear as "( )". With radio
buttons, only one option out of the cluster can be selected, and selecting a new
button will disable the others. The button with your current configuration
choice will appear as "(*)".
Data Fields are boxes with an inverse background that allow you to enter text.
Sometimes text may be longer than what is displayed on the screen, indicated by
a small arrow pointing to the left or right at the end of the field. Home, End,
Insert, Delete, and arrow keys all function within text data fields.
-----------------------------------------------------------------
Celerity v2.0 Page 13
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
System Info
-----------
This data screen has fields requesting general information about your BBS.
- Sysop: Your Name or Handle (as requested on your Registration form)
- Full: This is the complete name of your BBS (ie: Terrapin Station). Consider
a limit of thirty characters or so.
- Short: Enter the name of your BBS again, in a shorter version if the real
name is excessively long (ie: Terrapin). If the name is short and simple, it is
fine to enter the same name in both fields. The limit should be about fifteen
characters.
- Acronym: This is a three character field that should be used to identify
your BBS in assorted downloadable files (such as a BBS policy file, master
lists, off-line reader data packets, and the like). Examples include CEL, BME,
and ARC for The Celerity Support Board, Bald Mountain Enterprises, and The
Archives, respectively.
- City: The city where the BBS is located. This information is only to
satisfy user interest, and does not affect the operation of the BBS in any way.
- State: Like the city above, this information is inert.
- BBS Phone Number: Enter the number in the format: 310-693-9405 or
+61-554-2321. This information will be used to determine the locality of
potential users for the Local User Lockout and for generating statistics.
- System Two Name: If you wish to use a second "system" accessible when a
caller first connects, you can enter the name shown on the menu here. For more
information about additional systems, see the section on "Login Commands".
- System Three Name: See "System 2 Name" above.
System Options
--------------
The System Options menu contains vital information regarding certain functions,
type of BBS you run, type of machine it is running on, multinode information,
and more.
-----------------------------------------------------------------
Celerity v2.0 Page 14
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
System Toggles: This section contains a set of check boxes relating to various
features and functions. Placing a dot in the box will enable that option,
placing a space in it will disable it. These options are as follows:
- Allow Doors: Will your system allow the use of external programs (doors)
such as on-line games? See the section on "Doors" below.
- Allow FAT Move: This toggle will allow Celerity to move files around on your
hard drive by directly reading and writing to the disk's directory structure.
This results in a much quicker move of the file when compared with the non-FAT
move, which involves copying. Consider reading/editing/writing about 512 bytes
as opposed to reading/writing over a million bytes (for a 1 meg file). If you
have a very delicate file system (ie: not standard MS-DOS), use various device
drivers, or networking, you may need to disable this function.
- Strict Phone: Forces users to enter their phone numbers in the proper format
(i.e. for US Callers :xxx-xxx-xxxx or, for international users: +xx-xxx-xxxx).
- External Chat Call: Celerity will execute a file in the AUDIO directory
called CHAT.BAT. It will first check to see if there is a .VUS file (a
digitized file for an individual user - his user ID with a .VUS extension..
234.VUS, for example) for the user currently logged on. If so, this file will be
passed as a parameter. If there is no .VUS for the particular user, a .VOC
file will be chosen at random from the AUDIO directory.
The sysop should set up the CHAT.BAT file in his AUDIO directory to call a
utility which will play the digitized sound on his hardware, or REPLAY.EXE for a
system with only a PC speaker. Alternatively, a sysop can do anything he wants
in that CHAT.BAT file, such as starting a MIDI player, using some PC-speaker
music (examples are available on Terrapin Station), and so forth.
- Hang Up on exit: Will allow the system to NOT hang up when the user logs
off. This is handy if you run Celerity as a door from another BBS, or if you
have multiple BBSes available from one login shell and wish for users to be able
to return to an alternate process upon exiting Celerity.
- SysOp Auto Login: If selected, the Sysop will be automatically logged in
when F10 is pressed from the WFC Screen. Alt-F10 overrides this Toggle, always
"auto logging" the sysop in. F4 will take the Sysop Directly to the main menu
without any of the normal Login processing (Mail check, NUV processing, etc...).
- Secure Console: The secure console option will disable all keyboard-based
sysop functions so that the BBS can be used by multiple local users without
(much) fear of an integrity breach.
- System Type: This box contains a set of radio buttons to indicate which type
of on-line system you are running. You may select only one of the four types,
-----------------------------------------------------------------
Celerity v2.0 Page 15
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
and it must be an option your registration utility supports. The various
options are as follows:
- Celerity BBS :The standard full-fledged Celerity BBS
- CAE :A no-user-record transfer system
- CAE/TAC :A transfer-only system with accounts
- Alacrity BBS :This option superseded by the Alacrity structure
- CPU Type: More radio buttons. Indicate the type of system that you have.
If you have a system based on (or emulating) an Intel (or other) 8088, 8086, or
NEC V-20 processor, select 8088. If you have a 286 machine, indicate 80286. If
you use a 386sx, 386sl, 386dx or compatible, indicate 80386. If you have an
i486sx, or i486dx, or compatible, indicate 80486. If you have a Pentium class
processor (Pentium, Pentium 54C, Cyrix M1, AMD K5, Nexgen NX586), select the
Pentium option. Note that the system WILL function under the incorrect
processor setting, but Celerity will not be able to optimize its performance for
your processor.
- Hangup Timeout: You can determine how many minutes Celerity will allow a
user to sit at a prompt without doing anything. Once this time is passed,
Celerity will hang up on the user to allow someone else to call.
- Print Log: This option will echo system log activity to a printer attached to
PRN. Do NOT enable it if you have no printer on your system or if you do not
intend to leave the printer on for continuous logging. The print option has 4
settings:
Off: Disable Printer Logging.
Brief: Will only show basic events, such as log in and log out.
Normal: Will show more details than brief mode, including log in, log
out, E-Mail activity, message base activity, and transfer activity.
Verbose: Print everything that appears in the System Log.
-----------------------------------------------------------------
Celerity v2.0 Page 16
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Look and Feel Settings
----------------------
The Look and Feel Toggles control some display options within Celerity.
- User Disable Top 5: Allow the user to set a toggle in his configuration files
to bypass the Top 5 Poster, Uploader, and Downloader lists.
- Use Top 5 User List: Allows the Sysop to turn off the Top 5 Poster, Uploader,
and Downloader lists.
- Use One-Liners: Allow the users to enter "one Liner Comments" that are
displayed on the bottom of the screen during BBS operations
- Use Key Flash Monitor: The Key Flash Monitor will cycle the NumLock,
ScrollLock, and CapsLock keys when the system is in the WFC (Wait for Call)
mode. This can be used as an indicator that the system is active when a user is
not on-line and your Screen is off. Do not use this if you are under a
multitasking system or sharing a keyboard with multiple computers.
- Enable "Leech Week": When on, the File-Point System is disabled. This can be
used to "Reward" your users once in a while.
- Use Alacrity Structure: This is an alternate menu structure. The major
change in this over regular Celerity is the division of the main menu into a
main level menu and a miscellaneous menu. The Alacrity structure was designed to
be more intuitive and logical while the older structure has been retained for
those who are slow to adapt.
- Allow Masterfiles: Allow the users to generate a comprehensive list of all
files on the BBS (That the user has access to)
- Use Sound: Celerity will make sounds every once in a while.
- User Edit Usernote: Allow the User to change his own User Note
- Allow User Handles: Should Handles be allowed on the System, or just real
names.
- Use NUA/VMB in BBS List: VMB=Voice Mailboxes, NUA= Network Address.
- Recycle BBS on Exit: (Not used, set to OFF)
- Allow Mail Attachments: Allow Files to be "Attached" to email messages.
- User Wait Text: Text displayed when the sysop does a local drop-to-dos or
other local console commands.
-----------------------------------------------------------------
Celerity v2.0 Page 17
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- Anonymous String: The "Name" to use when someone posts "anonymously"
- Pause String: Text displayed to the user to hit return to continue.
- Mask Input Character: The character echoed when the user is typing a password
or other sensitive data which should not be displayed.
- Default Help Level: The help level to set for all new users(1-4). These are:
1: Expert: users who are intimately familiar with Celerity BBS
2: Intermediate: most users who are familiar with BBSes in general.
3: Novice: novice users who need a list of valid keys at every prompt.
4: Beginner: absolute beginners who need full menus to be displayed
automatically at every prompt.
We recommend a setting of 2 for most systems as the default. Individual users
can select their own setting, of course.
-----------------------------------------------------------------
Celerity v2.0 Page 18
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Serial Port Setup
-----------------
It is imperative that this section is set correctly, or Celerity will not
function (or not function completely) with your modem. It should be noted that
the COM2 handling on some machines is not fully standard, and thus some people
have problems using COM2 with Celerity.
- COM Port: This box contains five radio buttons. The first two correspond to
the IBM standard IRQ, Address, and interrupt values for COM1 and COM2. The
second two correspond to the industry standard values (note that these industry
standards are NOT supported by IBM PS/2 machines) for COM3 and COM4. The fifth
button will allow you to use the Custom COM Port settings (see below) so that
you can set Celerity up to a specific format.
- Custom COM Port: Allows you to specify the IRQ, interrupt, base address, and
COM port to use for Celerity. Use this if you have a non-standard setup. The
interrupt is usually the IRQ plus 8.
- Enable UART Buffering: If you have a high speed serial UART, let Celerity
enable its buffering! A 16550AFN UART provides a buffer so that data can be
moved quicker, and is very helpful when running on a system with a lot of
overhead (excessive use of interrupts by some programs, or multitasking). See
Appendix A for more info on SIO Chips.
- Input Buffer: Allows you to specify the size of Celerity's internal input
buffer. The minimum recommended value here is 128 bytes.
- Output Buffer: Allows you to specify the size of the output buffer. The
minimum value here is 32 bytes, but 512 or 1024 is recommended) It can be
increased as circumstances warrant (ie: users complain of garbled ANSI
displays).
- Serial Type: If you set it to DigiBoard, only the DigiBoard main program
files will work. If you set it to FOSSIL, only the FOSSIL version will work.
This switch is a configuration precaution only - you still must obtain the
Digiboard or FOSSIL supplement for these modes of operation.
-----------------------------------------------------------------
Celerity v2.0 Page 19
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Modem Setup
-----------
The Modem Setup dialog is where you tell Celerity all about your modem. Celerity
ships with a number of setup objects for common modems.
- Modem Type: This is a list box containing a database of modem types which
have been tested with Celerity. To load the settings for a particular modem,
you must select it in this box then click on the "Apply Modem Settings" button.
Selecting the modem alone is not sufficient to load the modem's default
settings.
- Offhook During Local: This is a check box which will make Celerity take the
phone off the hook when someone logs onto the system locally. The value of this
is that users will get a busy signal instead of a ring when they call while a
user is on the system locally.
- Answer on Ring: This tells Celerity how many rings to wait for before it
answers the line. If you specify 0, Celerity will read your serial port
directly waiting for a ring, and is the strongly recommended setting. If you
specify a value other than 1, Celerity will add "ATS0=n", where n is your
specified value. In this case, Celerity will wait until the serial port
reports the existence of a carrier, requiring the modem to initiate the answer
process. (Under some hardware and software configurations, the ring 0 may not
function correctly. The virutalized UART in OS/2, for example, precludes the
use of this option and sysops running under OS/2 must select a ring # of 1 or
more). Some modems, serial hardware, or serial cables do not support the ring
detect line correctly and may continuously tell Celerity that the phone is
ringing. In this case, select a ring # greater than 0.
- Hangup String: This is the AT command which should hang up your modem if the
preferred method of dropping the DTR line does not succeed. Note that a pipe (|)
character indicates a carriage return and a tilde (~) indicates a 1-second
delay.
- Dial Prefix: The command needed to force the modem to dial should be entered
here. Generally, it would be "ATDT". Some phone systems require adding
additional digits.
- Dial Suffix: The suffix of the dial command is usually just a carriage
return (|), but some phone systems may require other digits for full
functionality.
- Apply Settings: Loads the defaults for the currently selected modem type.
See the "Modem Type" above.
- Supported BPS rates: Many sysops will want to limit access to the board to
certain connection rates. The Supported BPS rates is a sub-dialog of the modem
-----------------------------------------------------------------
Celerity v2.0 Page 20
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
setup options which will let the sysop enable or disable any single connect
rate, from 300bps up to connection rates of v.32ter, v.34/v.fast, or even ISDN
connections.
Note that if a "Low Speed Lockout" password is defined (see "System Passwords"
below), a user at an unsupported rate will be given the opportunity to enter
this password and log on despite this restriction.
- Add Modem: If you develop a reliable setup string for a Modem that is not
listed, you can name the Data strings and add them to the MODEMLST.DAT file. If
the Setup works well, pass on the information to the Celerity support BBS for
inclusion in future versions of Celerity. Note that after you add a modem
object to the list, you will need to exit CelSetup and re-run it for it to be
visible in the listing.
- Connect Strings: This will bring up a dialog enabling you to tailor the
strings which Celerity expects from your modem. By default, it expects CONNECT
followed by the speed of the connection, such as "CONNECT 14400" for a 14.4kbps
connection. Most modems follow this pattern, but if yours does not, Celerity can
be modified to support what your modem does use. Celerity will use the highest
rate matched, so if you have "CONNECT ISDN" for both a 57600 and a 64000 ISDN
rate, Celerity will interpret the call as being at 64000.
- Edit Settings: Pressing this button will bring up another window. This
window will allow you to alter the standard settings for your selected modem
type as follows:
- DTE Rate: Radio buttons specify at what speed data should be sent to the
modem. Most high speed modems allow a DTE rate of 19200, 38400, 57,600 or even
115,200 bps. A fixed speed modem (normal non-V.42, non-MNP 2400, 1200, 300)
should use its maximum rated speed.
Note: You can easily set this rate higher than your computer and/or serial
hardware will support reliably. If your users lose characters or get download
errors, try a reduced DTE rate. 38400 is sufficient for maximum speed transfers
of archived files up to 28.8kbps (although non-compressed data will go faster at
a higher DTE rate). In general, if your users do a lot of transferring of
uncompressed files (text files, program listings), set your DTE rate to twice
your top connect rate (38400 for up to 19200bps, 57600 or 115200 for 28.8k).
- Lock DTE: High speed modems can lock their operating speed at a higher DTE
rate than the connect rate is. If this check box is NOT checked, Celerity will
begin communicating at the established speed upon connection (ie: Celerity will
talk to the modem at 2400bps if a 2400bps call is detected). If your modem will
support a locked DTE rate, it will give better performance than a modem which
does not.
-----------------------------------------------------------------
Celerity v2.0 Page 21
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- Connect Delay: After the command to answer is given, Celerity will wait this
length of time (in 1/10th seconds) until it attempts to determine the connection
information. If the modem responds to a carrier very quickly, this can be
short. If the modem takes a long time to determine the connection results, such
as many V.32 modems, this should be longer. If you get calls coming in which
Celerity cannot identify, this value should be increased.
- Modem String: This is the actual command string sent to the modem to prepare
for a call. Under most circumstances, you should use the recommended string, or
some modification of it. If you have an unsupported modem, you can custom
tailor it here.
-----------------------------------------------------------------
Celerity v2.0 Page 22
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Custom Modem Strings
--------------------
If you have a modem which is NOT listed in the list box, you should try the
following steps:
1: Select a different modem by the same manufacturer and see if the setup for
this alternate modem works.
2: Call the Celerity support BBS and see if a modem object has been created by
another sysop for your modem.
3: Try a "generic" modem setup (ie: "Generic 2400" for a 2400bps modem,
"Generic 9600" or "Generic 14400" for a v.32 or v.32bis modem).
4: Try setups for similar modems from different manufacturers.
5: With the assistance of your manual or technical support of your modem
manufacturer, create your own setup object. This option will provide the best
performance from your modem, but requires that you are somewhat knowledgeable
about modem operation, or have a technician's assistance.
Important information you will need to know to proceed:
a: Celerity expects verbal result codes in the following format:
"CONNECT <bpsrate>[/protocol]"
It does not read a DTE rate value. If a protocol is specified, it should be on
the same connect line. Example:
"CONNECT 14400/V32BIS/LAPM" is acceptible.
"CONNECT 38400
CARRIER 14400
PROTOCOL: LAPM" is not.
b: Celerity uses RTS/CTS handshaking. The modem can be set up to respond
to BOTH hardware and software handshaking for compatibility with some transfer
protocols and doors.
c: High speed modems should use a locked DTE rate, which should match that
in the Celerity setup.
d: Celerity uses the DCD line (carrier detect) to tell if a caller is
connected or has hung up. The modem should NOT force this line true. Usually,
"&C1&D2" in the modem setup should ensure correct DCD operation.
e: Celerity (when set to answer on ring 0) monitors the RI (ring detect)
line to tell if the phone is ringing, and then sends an "ATA" to the modem to
tell it to answer. The RI line should not be left on after a ring comes in.
Some modems may have a problem with this, and may keep the RI line high, causing
Celerity to continually report that the phone is ringing in the wait for call
screen. In a cases like this, set the modem to answer on ring #1.
-----------------------------------------------------------------
Celerity v2.0 Page 23
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Video Options
-------------
The Video Options dialog contains five check boxes for various aspects affecting
the actual video display.
- Monochrome: If you are running on a greyscale VGA or monochrome system,
checking this option will emphasize all low intensity characters on the local
end, making text easier to read.
- 43/50 Lines: If you have an EGA or VGA display, Celerity can operate in a
high resolution text mode. EGA will provide an 80x43 display, and VGA will give
you 80x50.
- Celerity ANSI: This enables the internal ANSI interpreter, which is about
65% faster than the fastest DOS-based driver we could find. In addition, use of
the Celerity ANSI filter will convert all ANSI codes to Avatar codes for users
who select Avatar terminal emulation, resulting in a considerable on-line speed
increase as well. The ONLY reason you would have for disabling CelerityANSI
would be in the case where you required all text to pass through DOS interrupts
for devices such as Braille terminals etc.
- Wait-Call Screen Saver: This toggle will allow Celerity to blank the screen
while it is waiting for a call. It is an old throwback to the Days of the
Monochrome monitors, which experienced "Burn-in" problems. Nowadays, It's just
"Pretty"
- Auto-size Display: This option will automatically adjust the local display
mode to mimic the user's display mode. If the user uses 25 lines, the local
display will be 25 lines. If the user uses 43/50 lines, the local display will
be 43/50 lines.
-----------------------------------------------------------------
Celerity v2.0 Page 24
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Login Sequence
--------------
With a simple change in the setup program, the SysOp can change the sequence of
events a user performs when he enters the system. Not only can events be
arranged in new and unique sequences, but they can also have certain attributes
set on them.
The SysOp can decide if an event should always be viewed, or if it should be
abortable via a quick-login, if the screen should be cleared before the event,
if the system should pause for user input afterwards, or even if it should be
executed at all. The P)ause, C)LS, and S)kip boxes control these options.
Also, up to three additional events can be defined which display external text
or ANSI files containing any image or information the SysOp wishes to include.
These events can also be inserted anywhere in the login sequence, and have the
three attributes (skip w/quick login, clear screen, pause) adjusted. These
files should reside in your DISPLAY directory.
Celerity's configurable login sequence also allows a SysOp to define two
EXTERNAL PROGRAMS to be run as the user logs in (such as Caller ID info, an
online game contest, or writing your own BBS modules). Any program which can be
run as a door (or DOS program w/Doorway) can be executed as a login sequence
door, and the user won't be able to tell that he's not in Celerity. These
external programs must be in your main BBS directory.
The login sequence can contain as many or as few events as you desire. You have
a wide range to choose from, including:
- Welcome Message: This event displays one of several welcome screens at
random, depending on the user's terminal emulation.
*.WEL : These are ANSI welcome screens.
*.WAS : These are ASCII welcome screens (no color, cursor
positioning).
*.WTX : These are 7-bit text welcome screens for users who do not
have IBM-compatible displays.
*.WNA : These are NAPLPS graphics frames.
*.WNR : These screens are for those with RIP graphic terminals.
- Account Status: The user's account status screen is displayed with this
event. An external configurable status screen LOGNSTAT may be used here
- Account Verification: This event checks the user's account to see if he has
been deleted or if his account has expired. This should be included in all
login sequence setups, and NOT be skippable.
- System News: If there are new news bulletins which have not been read, they
will be displayed by this dialog.
-----------------------------------------------------------------
Celerity v2.0 Page 25
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- Network News: This function is no longer used.
- Auto-Message: If an auto-message exists, it will be displayed by this event.
- Display Art: This event will choose a random work of ANSI art from the Art
Gallery and display it to the user.
- Voting: If you wish your users to be forced into the voting section of your
BBS, this event will do so. Users will be prompted to vote on topics they have
not yet voted on.
- New User Voting: If you use the New User Voting (NUV) section, users with
sufficient access will be asked to vote on pending new users.
- Electronic Mail: When this event is active, users with new mail waiting to
be read will be sent into the Electronic Mail section to read it.
- Multi-Node Status: If you run a multinode BBS and select this event, users
will be shown a list of other users on other nodes.
- Door 1 & 2: There are two door events. When one of these events is called,
Celerity will execute the specified filename residing in the BBS directory, just
like a door. These events can be Caller ID programs, special message mailers,
doors, or other types of modem-aware (or Doorway-style redirected) programs.
- Display 1, 2, & 3: These events also require a filename, like the shell
commands. They may be special notices, disclaimers, system policy notices,
additional ANSI files, or whatever the SysOp so chooses. They must be in the
display directory.
Through the use of the configurable Login Sequence commands, a SysOp can make
his system appear considerably differently from other Celerity systems. The
capability to shell to doors when users log in allow SysOps to add additional
features or utilities to provide even greater flexibility for system
configuration and system motif.
-----------------------------------------------------------------
Celerity v2.0 Page 26
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Transfer Options
----------------
These options alter the way your transfer section looks and behaves. Note that
for the Use File Point System, Upload Factor, Point Value, and Commission
options, the transfer policy is explained to users whenever they enter the
transfer section.
Upload Descriptions: Celerity allows for much more complete information to be
stored regarding an upload than most bulletin board programs. Users can select
which information they wish to view, as only so much can be displayed on an
80-character screen.
- Allow Extended Descriptions: Although unused with version 2.00, Extended
Descriptions will ultimately allow users to enter a full-page description about
an upload which may be viewed with the I)nformation command from within the BBS.
This toggle will enable you to turn it on or off.
- Picky Descriptions: Unused with v2.02.
- Use Disk Numbers: Unused with v2.02.
Transfer Toggles:
- User Defined Point Modifier: User-defined point values allow the uploading
user, in a file point system, to determine to an extent how valuable a certain
file is, and thus how much it costs. The user can specify if the file should be
free, one point, quarter, half, normal, or double the standard cost for a file
of its size. Note that for this option to have any meaning, the "Auto-Validate"
and "Use FPS" toggles must be checked as well.
- Use File Point System: This toggles the use of a file point system for your
transfer sections. If you use a file point system, users must "pay" for their
downloads with transfer credits. Transfer credits may be earned by uploading
files, having their uploads downloaded by other users (see "Commission"), or
granted by the SysOp.
- Auto-Validate Uploads: If this option is checked, new uploads will
immediately be posted for general download. If this box is not checked, the
SysOp or coSysOp must manually validate each file and determine its point cost
(if a file point system is used).
- Auto-Comment Uploads: This box dictates whether Celerity should execute a
file called COMMENT.BAT from your BBS directory. This COMMENT.BAT file is
normally used for running CelTest, ZipLab+, TranScan or some other third party
program. COMMENT.BAT will be passed the filename and path as %1 and the
-----------------------------------------------------------------
Celerity v2.0 Page 27
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
extension as %2, and the path to a .DIR file with the current record of the file
being tested as %3.
- Use Backup Directories: This option allows the sysop to bulk move lots of
old file entries to a .BCK directory for archival purposes.
- Allow User File Requests: When a user attempts to download a file entry
which is not found on your hard drive, they will be told "that file isn't here".
If you turn this switch on, the user will be asked if he or she wishes to leave
feedback to the SysOp requesting the file. (This way, you can store mass
quantities of files "Off-line" (on a tape backup or CD-ROM) and move files
online only if they are requested)
- User File Passwords: If you enable this option, users will be allowed to
attach passwords to their uploads. Other users must then enter this password
before they can download the file.
- Allow Private Files: If you allow this, Users will be able to "Reserve" an
upload for a particular User. Only that User could Download it.
- Spool Uploads: If this is selected, an external upload spooler will be called
to process files uploaded. Please refer to the Documentation for UpSpool for
details on it's operation.
There are also several Values that need to be set to determine the transfer
systems attributes. they are:
- Upload Factor: If your system uses a file point system, and you wish to give
users download credit for their uploads, you may enter a multiplier in this box.
The user will be granted (value_of_upload * Upload_Factor) points. For example,
a user uploads a file which the BBS determines is worth four points. With an
upload factor of 3, the user is granted twelve points. An upload factor of 1
provides four points, and 0 provides nothing. The value of the upload is
determined by the SysOp if the system does not automatically validate uploads,
or by the "Point Value" below if uploads are immediately posted. Note that if
you enable the "User Defined Point Value" (see above), the upload restitution
is granted before the user chooses the new value. (This prevents a user from
giving himself "Mega-points")
- Point Value: This variable determines the standard number of kilobytes that
1 point can download in a system using the File Point System, rounded down. For
example, a 118k file would be worth 2 points if the point value was 50 (118 / 50
rounds down to 2). The same file would be worth 1 point if the point value was
1, or 11 points if the point value was 10. This value is used to determine the
cost if the file is auto-validated (see above), or used as the default
suggestion when a SysOp manually validates the file.
-----------------------------------------------------------------
Celerity v2.0 Page 28
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- Maximum File Point Loan: Celerity allows users of a certain level to take
out a file point loan, allowing them to download something they do not have
enough points for, in faith that they will repay the loan in the future. Alas,
some users would abuse this feature if there was no limit to the credit
extended, thus the necessity for this option exists. The recommended loan limit
is 500 divided by the point value (ie: enough to download about 500k), but
any value (including 0 to disable all file point loans) is acceptable.
- Commission Credit: One of the revolutionary concepts introduced by Celerity
is the system of file point commissions. This system rewards users who upload
quality data and describe their uploads well, and provides unequal treatment for
those who upload junk. The commission system works as follows:
User #A uploads a file and establishes its value as 22 points. When user #B
downloads the file, user #A is credited with a commission. If a dozen users
download a popular program, user #A gets rich in return for his or her effort.
If nobody downloads the program, user #A is not rewarded as much. The commission
value determines what percentage of the file's cost is given to user #A.
With a 0% commission, user #A gets nothing when his files are downloaded (and
thus must rely on the points granted by the upload factor above).
With a 50% commission, user #A gets half of the points successive users spend
downloading (with our example, user #A would get 11 points when #B downloads the
file, and 11 points when #C downloads, etc.).
With a 100% commission, the uploader gets all of the points spent by users
downloading. This high percentage works particularly well when the upload factor
is 0, so the user gets points only when his uploads are downloaded, and thus
people are encouraged to upload only useful data which other people will want,
and users waste their time when they upload junk.
- Upload Time Returned: When a user spends time uploading, some amount of that
time can be given back to the user so he has more time on your system that day.
The upload time box contains a percentage value for this awarded time. With an
upload time factor of 200%, a user who spends 5 minutes uploading will receive
10 more minutes of on-line time. A 100% upload time factor would return 5
minutes, and a 50% factor would return about 2 and a half minutes. The download
k limit for the current call is also increased by this same ratio. If the user
uploads a 100k file, and there is a 200% upload time factor, the user's daily
download limit will be extended by 200k (for the current call only)
- Space to U/L: The minimum space on the upload drive required to allow an
upload. If free space falls below this value, users will not be able to upload.
- Transfer Processing: The transfer processing section has 5 options:
Verify U/L - integrity verification of a ZIP, ARJ, or LHA/LHZ Archive.
-----------------------------------------------------------------
Celerity v2.0 Page 29
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Virus Scan - Will Use the path specified in "Tool Paths" to Scan Uploads for
Nasty Bugs.
Comment U/L - add a ZIP, ARJ, or LHA comment to the file from COMMENT.ASC in
the BBS Directory. Note that ARJ comments can only be 25 lines long.
Clean U/L - Delete all ads from the U/L by removing any files that match ones
listed in DELETE.ADS in the Main BBS Directory.
- Download Rates: SysOps do not like slower users spending an inordinate
amount of time downloading from their transfer sections, but may recognize their
value in the message bases. Celerity allows a SysOp to determine which bps
rates may download from the BBS and which may not This way, a slow user could be
allowed to log onto your system, but only to use the non-transfer sections of
the BBS.
-----------------------------------------------------------------
Celerity v2.0 Page 30
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Color Settings
--------------
Color Setup: This section has an impact on the appearance of your system,
particularly the default user colors. Although users can and do change their
colors, many people get a first impression from the look of the default color
set. Note that language files (See "The CelerityText Display System" in Section
4 below) may have default colors with them which will be loaded when a user
selects it.
The color setup dialog in CELSETUP.EXE is a bit different from other menus. It
contains two scroll boxes, two color boxes, a window with an example, and the
normal OK and CANCEL buttons. To operate the color selector, select the general
color set in the left box. The color sets include "BBS Colors", "SysOp Tools",
and "Status Line". Moving over to the middle box, you can select which specific
color within the set you wish to edit. The two boxes to the far right specify
the foreground and background choices for that particular color.
- BBS Colors: These are the eight colors for the BBS that new users will be
set up with when they apply. These colors can be changed to suit the user's
particular tastes. Note that when you define color #8, it must have a
background that is different from the others.
- SysOp Tools: These two colors are used to determine the color format of the
on-line SysOp Tool kit.
- Status Line: This defines the color of the status bar at the bottom of the
SysOp's screen.
- Wait For Call: This is a set of about six foreground colors and one
background color for the wait for call screen.
- Error Warnings: When certain errors occur, Celerity will show a box warning
the SysOp about it. You can determine the color of that box here.
- Lightbar Shell: If you use the Lightbar shell, you can determine the color
of the bar here.
-----------------------------------------------------------------
Celerity v2.0 Page 31
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Pathnames
---------
The pathnames dialog contains information regarding the location of various data
files for Celerity's use. The default directories are recommended, but they can
be custom tailored, of course.
- BBS Directory: This is the main directory where assorted data files are
kept, including user lists, comment batch files, and the majority of other
files. Note that in a multinode system, this directory should be the same for
all nodes.
- Temp Directory: This is a directory for temporary file creation. It should
have no subdirectories, nor should it contain anything you wish to keep. This
directory should be independent for each node.
- Node Directory: The directory where node-specific files are stored. The
main.bat, celerity.*, and setup.* files should be here, and other files may be
created and stored here by Celerity. On a single node system, this may be the
same as the BBS directory. On a multinode system, this must be separate for each
node. If you have a registered system, your CELERITY.KEY file should be here
too.
- MultiNode Directory: If you have a multinode BBS, this directory will be
used for multinode chat and line status information. It is recommended that
this be located in a RAMdisk if you use one.
- Conference Directory: When Celerity creates message storage files, they will
be kept here. Note that these files can become quite large.
- Data files: Information regarding your transfer section configuration will
be stored here. Directory files (*.DIR) containing the file records for your
transfer section are also stored in this directory. Moving this to a large
RAMdisk can increase the speed of the system substantially, but be sure to
update the files on the hard drive after each call (see "Running Celerity with a
RAMdisk" below).
- Display Files: SysOp-defined display files (see "Customizing Celerity"
below) and information script files are stored here.
- Network Files: If you use CelerityNet, HermesNet, or FidoNet, this directory
will be used for networking files.
- Door Files: Door.Bat data files may be stored here. See the section on
"Setting up Doors."
- Sound Files: If you use the digitized chat call, place all of your .VOC
files in this directory.
-----------------------------------------------------------------
Celerity v2.0 Page 32
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- New User Uploads: If you use a validation upload system (see "New User
Options"), this directory will be used to store the archive listing of the
user's upload, as well as the uploaded file.
- ANSI Art Files: The art files for the Art Gallery are stored here. They can
be ASCII, ANSI, RIP, or NAPLPS format.
- Language (CelerityText) files: They have extensions of .LNI and .LNG, and
contain sets of text for the BBS use. There is a single .LNI and .LNG file for
each language profile. The extensions will be .DSI and .DSP (for display menu
index, and display menu data). Users will select different menu sets based on
their term emulation (TTY, VT100, ANSI, Avatar, NAPLPS, RIP, etc.) These files
are also kept in the Language File Directory. See the section on "The
CelerityText Display System" in section 4 for full details.
- Email Uploads: Electronic mail data, files attached to electronic mail, and
user notes will be stored here.
- Swap Files: Where data will be swapped to when celerity needs to shell out.
A RAMdisk with about 600k in it is best for this.
- Directory for Archive: Temporary directory to be used by the archive
processor. Do not store anything in this directory, or make subdirectories off
this directory, as they will be deleted.
- Directory for Slow Files: If a user downloads from a transfer area marked as
a "slow volume", such as near-line storage (tape on a network), CD-ROM, optical
storage, jukebox, floppy, etc., files will be copied to this temporary directory
before the user downloads them. This directory should be on a hard drive with
sufficient space for the largest possible download from the slow volume.
If you have the storage space, it is recommended that you reserve a dedicated
partition for Celerity temporary use. Put all of your TEMP, ARCHIVE, SLOW, and
NETWORK directories here (for all nodes). This way, if the drive where the BBS'
main files are fills up, users will still be able to download slow files, your
network can continue to function, and so forth. A 40 megabyte partition is
probably the largest this partition would ever need to be even on a large
multi-line board. It should be big enough to store all network data at its
largest, plus big enough to store the biggest upload a user might make, plus an
extra 1.5 megabytes or so.
- WFC scan Drives: This allows you to specify up to 4 drives which will be
shown in the WFC storage statistics. Example: CDFG will display the Storage
statistics for Drives C, D, F, and G (This prevents "virtual drives" like
stacker drives from being counted twice).
A detailed list of all files which should appear in these paths, and what data
they contain, can be found in Appendix C.
-----------------------------------------------------------------
Celerity v2.0 Page 33
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Tool Paths
----------
The tool pathnames subdialog contains information regarding the location of
various utilities for Celerity's use. If you have any of these utilities, enter
the full path to them. (Just the Path, not the actual filename!)
If you do not have a utility, leave the entry blank.
The first 8 paths are for archive manipulations.
The GIF Viewer path is for a General Picture Viewer (VuImage Pro or Vpic are
recommended).
The Virus Scan Path is used by the internal Upload processor to assist in
examining uploads.
The Virus Scan Command consists of both the program you wish to use (SCAN, NCAV,
etc) and the Flags you wish added to the commandline.
-----------------------------------------------------------------
Celerity v2.0 Page 34
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Multinode Options
-----------------
This dialog is used to set up an individual node on a BBS running multiple
nodes. (For details on multinode operations, please see the chapter on
Multi-Node Operation below)
- Allow Multiple Logins: Should a user be allowed to log-in to multiple nodes
simultaneously? Some users who have more than one phone line and multiple
modems may wish to use multiple lines of your BBS simultaneously, but you may
not wish for one user to tie up so many resources at once.
- Use Direct Chat: Celerity BBS supports a full-screen character- by-character
chat mode featuring a seperate dynamically-sized window for each node of the
BBS. It works quite well under a well-behaved environment, but can be draining
on resources, and may not function well under some multitasking environments or
network setups. If it does not work well on your system, or you do not want to
use it, do not select this box.
- Node Name: This node "identifier" may be shown in the node list to identify
the this node by name. Commonly the phone number would be used on a system
which does not have number hunting.
- BBS Node Number: Each node must have a separate BBS node number, starting at
1 and working upwards.
- Maximum Users In Chat: If you want to limit the multinode chat to a certain
number of users, you can limit it here. Setting it to 0 will effectively
disable multinode chat.
-----------------------------------------------------------------
Celerity v2.0 Page 35
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Chat Options
------------
Various text messages will be displayed regarding the availability of the SysOp
to chat and upon initiation and ending of a chatting session.
- SysOp Available: When the user logs on, if the SysOp is available to chat,
this message will be displayed.
- SysOp Not Available: If the SysOp is not available, this message will be
displayed.
- Chat Welcome: When the SysOps enters chat, this line is displayed.
- Chat Goodbye: When the SysOp exits chat, this is displayed.
- Obnoxious Chat: This check box will make the chat call loud and obnoxious,
ensuring that the SysOp hears it.
-----------------------------------------------------------------
Celerity v2.0 Page 36
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
System Passwords
----------------
Various access aspects of Celerity are password protected. If you wish
passwords to be required, define them here.
- Security Password: When a user with SysOp access logs on, he or she will be
required to enter the security password to access SysOp options.
- System 1 Password: If you use a login shell, you can define passwords a user
will be required to enter before accessing the system. System 1 password is for
the main BBS.
- System 2 Password: See System 1 Password above. For external system #2.
- System 3 Password: See System 1 Password above. For external system #3.
- Emergency Chat: Users who know the emergency chat password can force the
system to make a cacophony of obnoxious sound, guaranteed to get your attention
if you are within a square mile of the BBS computer. This command is accessed by
typing "/page" at any BBS prompt.
- Low Speed Lockout: If you define a password here, a user calling at an
unsupported bps rate(see Modem setup, above) can enter it to bypass the low
speed restriction.
- New User Password: If a password is defined in this field, new users will be
required to enter it before applying for access.
- Shell CAE Password: If you setup a CAE from your login shell (ie: a
generally-accessible transfer section which does not require a user account),
you can protect it with the CAE password.
-----------------------------------------------------------------
Celerity v2.0 Page 37
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Timed Events
------------
Celerity can be configured to perform certain functions at specific times of the
day. To disable an event, clear out the start and end times.
- Restricted Hours: A system may be set up to allow only users of a certain
level on during a period of time. The "begin" and "end" fields here allow you
to specify the period. See "Required Access Levels" below to determine the
access level required to access the system during this time. Please use 24-hour
format.
- SysOp Available: If you set the SysOp availability flag to "By Time" at the
WFC Screen, the SysOp chat availability will be determined by the time specified
here. Please use 24-hour format.
- Batch Event: Celerity can have one external batch file executed at a certain
time. Define that time and batch file name here. This file can be used to run
door maintenance files and the like. Please use 24-hour format.
- Time to Backup: At this time, a file called "BACKUP.BAT" will be executed.
This file should be used to make a daily backup of important information such as
user lists, file directories, and possibly message bases. Note that this file
can copy files to a floppy, to another hard drive, or even execute a tape backup
program. Please use 24-hour format.
-----------------------------------------------------------------
Celerity v2.0 Page 38
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Access Levels
-------------
A user's access level can determine which BBS functions he or she may or may not
perform. These functions are determined below.
- Access BBS: Users at and above this level will be permitted to log onto the
system. Users below this level will get a "You are not yet validated" message.
This value Must be set higher then the new user access level set above if you
want them to receive an approval status display.
- CoSysOp Activities: Users of this level and above may access SysOp menus.
- Post Anonymous: If a sub-board supports anonymous posting, a user of this
level may make a post anonymously.
- Post a Message: This level is required to write or upload a message to a
message base.
- Leave Automessage: This level is required for a user to leave an automessage
for future callers to read.
- Login During Restricted Hours: This is the access level required for the
restricted hours. See "Timed Events" for more details.
- Show Anonymous Name: Users of this level and above may see who really posted
a message anonymously.
- List Users: A user with this level can see the userlist from the main menu.
- List Recent Callers: A user with this level can show a list of recent
callers.
- List Xfer Activity: Users with this level may list recent upload and
download activity.
- Show System Status: To see the storage statistics, a user must have this
level.
- Show System History: Users who have this level may view the system history
records.
- Top Ten Exemption: Users with this level and above will not be counted in
the calculation of the top ten posters, leeches, and uploaders. Useful if you
do not wish sysops or cosysops to appear on these lists.
- File Point Loan: Users must have this level to take out a file point loan.
-----------------------------------------------------------------
Celerity v2.0 Page 39
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- Upload to Art Gallery: Need this level to upload to the Art Gallery.
- Make a QWK Pack: Need this level to make a QWK pack.
- Expired Security Level: Unused with v2.02 (superceded by access templates).
- Expired Transfer Level: Unused with v2.02.
- User Time Per Day: This array of fields defines the amount of time per day
users will get on your system as a default. If there is an access template for
a user's access level, the template's time will be used. If the user has a time
set individually, that time will take precedence.
-----------------------------------------------------------------
Celerity v2.0 Page 40
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Login Shell
-----------
When a caller first connects to Celerity, the system can display a connection
header, and detect terminal emulation. The user may then be presented with a
logon shell or command menu, if you choose to use one as many boards do these
days. Usage of a logon shell allows you to insolate the new user process from
the main board itself, and to protect the system from unwanted callers. A user
who enters the shell will be presented with a menu of choices, which
have static operations but can have their command keywords customized (see
"Login Commands" below).
- Connect Header: When the user first connects, they will be presented with a
connection status message (eg: CONNECT 14400/ARQ/HST) unless there is a message
in this field, in which case that message will be displayed.
- Terminal Detection: If you mark this check box, Celerity will attempt to
determine the user's terminal emulation. It can differentiate between TTY,
VT-100, ANSI, and Avatar. Note that Celerity cannot detect Avatar emulation
from the DOS Telix program because of the incomplete Avatar support in Telix. If
this box is not checked, Celerity will assume VT100/ANSI emulation for all
users. Note that if you have this box checked and users do not get thier
emulation detected, you may need to increase the "Connect Delay" in the modem
setup dialog.
- Login Shell Type: Celerity supports five separate shell types:
No Shell: The user will be dropped directly into the BBS (username prompt).
Menu Shell: The menu shell gives the configurable command line. Hitting a '?'
or typing 'help' provides the user with a list of supported commands. If you
wish to have a custom shell menu, you can make a file called SHELL.1 in your
menu directory that will be displayed when the '?' is hit. Be sure that it has
all the commands the user may select. (See the "Login Commands" section
below).
DOS Emulator: The DOS simulator shell will place the caller into a DOS
simulator, where they will run separate "programs" corresponding to the shell
commands. The shell commands (see "Login Commands" below for definition) will
be converted to DOS filenames in the form of .EXE, .COM, or .BAT files (ie: if
you choose "Login" as the command to enter the main BBS, the DOS name will be
"LOGIN.EXE"). If the user types DIR, they will be presented with a "directory"
listing of the commands, or else the optional SHELL.2 file from the DISPLAY
directory.
VMS Shell: The VMS simulator simulates a Digital Equipment Corp machine running
VMS. While this shell is functional, few sysops will have use of it as most
-----------------------------------------------------------------
Celerity v2.0 Page 41
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
users are not familiar with VMS. UNIX Shell: The UNIX shell provides a login
shell for those who are familiar with the UNIX operating system.
Lightbar: A list of the available options is presented on a lightbar menu.
Users may select which option they wish by typing the corresponding number, or
by selecting the option with the bar and pressing enter. The user must have
ANSI, VT100, or Avatar emulation to use this. If the caller does not have one
of these terminal emulations, s/he will get the menu shell.
CelerityText Shell: This shell operates similar to the LightBar shell, except
all entries are defined as CelerityText. This enables the sysop to create his
own interactive shell. As the shell is fully configurable, you can make
Celerity look like some other type of system. Have it mimic a mainframe or mini
if you want to conceal the fact that it is a private bulletin board system.
Using the connect string, the SHELL.1 help screen, and the definable shell
commands, you can make the shell look like anything you like. The CelerityText
shell can also support full screen animated login shells.
External Shell: If you are a programmer and wish to write your own shell
routines called EXTERN.EXE, select this option and Celerity will call it.
-----------------------------------------------------------------
Celerity v2.0 Page 42
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Login Commands
--------------
To make each system's login shell a little more unique, Celerity allows sysops
to define the commands used to perform various shell functions. Users will be
required to enter these command words in the Menu, DOS, and VMS shells. An
option menu will be displayed on the menu when users type '?', 'dir', or 'ls'
for the Menu, DOS, and VMS shells respectively unless the SHELL.1, SHELL.2,
SHELL.3 SHELL.4, or SHELL.5 files exist in the menu directory, in which case
they will be displayed instead. Note that the lightbar shell does not require
users to enter keywords. To disable an option, simply clear its respective
command field, and that option will not be offered to the user.
Login Shell Commands: There are three login shell commands, one for each
virtual system. The first is for your main BBS, while #2 and #3 are for
external BBS programs.
Apply For Access: This command is what a new user must enter to apply for
access to the main system. A user must give a new user pass if it is required
(see "System Passwords"), and fill out any information forms the SysOp has
defined. See "The New User Process" for more.
Check: This command allows a new user to check on the status of his or her
application in the main system. If the user has been validated, he or she will
be given the password to system 1, and be allowed to enter. If the new user
voting system is enabled, the user will be informed as to the up-to-the-minute
results of the voting.
Feedback: This option allows users to leave feedback to the SysOp from the
shell.
Chat: If a user enters this keyword, and the SysOp is available, the SysOp will
be paged for a chat.
Log Off: This command will log the user off the system, hanging up the modem
and returning to the Wait for Call screen or DOS.
CAE: If you set up a CAE section from your login shell, users can access it
with this command. See the "Modes of Operation - CAE Mode" section below for
more details.
Command Prompt: The prompt line for the logon shell (for the Menu shell only)
may be defined to add an additional flair of originality to the BBS. Common
prompt lines include "[Command/?]" and "Login:".
-----------------------------------------------------------------
Celerity v2.0 Page 43
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Information Scripts
-------------------
The Information Script Section is used to define which Pre-defined Infoforms
will be used by your system. (For directions on creating information scripts,
see section 4 below for detailed directions)
- Form Title: The name of the information script. There are a couple of
"Special" information script locations that you need to be aware of:
Script #1: This is traditionally defined as the Sysop's Information Form. The
filled out form is displayed to the Sysop when in the New User Voting (NUV)
Section.
Script #5: This is coded as the New User Application. This form, when filled
out, will be displayed to all the users who are members of the New User Voting
Committee if you use the NUV system.
- Force Use: When checked, all users MUST fill this form out before they can
gain access to the BBS.
- Min Level: Users must have a level >= to this before they are allowed to fill
out the form.
- Max Level: Users must have a level <= to this before they are allowed to fill
out the form.
-----------------------------------------------------------------
Celerity v2.0 Page 44
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
New User Options
----------------
The following options all relate to how new users are handled by your system.
New users will normally be asked to fill out information scripts, and on some
systems will be subjected to the New User Voting section. Other functions
related to the new user process include the new user password, Local User
Lockout, and Quick Validate.
- New User Toggles: This cluster contains check boxes to enable or disable
various features of the new user section.
- Refuse New Users: If this box is marked, someone who applies as a new user
will have the PRIVATE.BBS file (from the display directory) displayed, and will
not be permitted to apply.
- Hang Up after application: Checking this box will make Celerity hang up on
new users after they finish their application.
- Require New User Upload: Checking this box will enable a unique Celerity
feature: the validation upload. New users who call will be asked to upload a
new file for examination by the SysOp and the new user voting panel. The text
the user is presented with may be tailored to your system by creating a file
called VALIDUD.BBS in your menu directory. Note that the upload must be in the
ZIP format.
- Save New User Uploads: If the SysOp wishes to keep the uploaded file, he
must check this box. If this box is not checked, only a record of the upload (a
zip listing) will be saved. These files will be stored in the new user upload
directory.
- Require Feedback: If this box is checked, new users will be asked to leave a
letter requesting access to the system staff.
- Ask for User Address: Checking this box will ask new users for their
complete mailing address.
- New User Note: Every user has a special user note which can tell the name of
his or her bbs, an organization he or she belongs to, or a comment about the
user's access level. There is a toggle in the look at feel section which will
allow users to define their own note. For new users, you can determine the
default note that they will be given here.
- Send New User Feedback To: This field allows you to specify the name of the
cosysop who should receive new user feedback (Useful if you have a high volume
system, requiring a person (a cosysop) who is dedicated to the task of
validating new users)
-----------------------------------------------------------------
Celerity v2.0 Page 45
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- New User Access Level: New users will be granted this access level. Note
that if this level is under the level required to access the BBS, the user will
not be permitted to access the system until validated.
- New User Xfer Points: If you use a file point system, this field can be used
to give new users a few points to get started with.
-----------------------------------------------------------------
Celerity v2.0 Page 46
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
New User Voting
---------------
The purpose of the New User Voting (abbreviated NUV) system is to allow the
users of a system have a say in who gets access and who doesn't to the system.
There are five data options in the setup relating to the New User Voting.
- Enable New User Voting: This turns the section on and off. If it is off, no
other NUV options will be used.
- Automatically Validate and Delete: If this check box is marked, a new user
will be validated or deleted when they gain the required number of votes for
either category. If this is turned off, a user with NUV SysOp access must
manually P)rocess those applicants who are pending validation or denial.
- Yes Votes: This is the number of yea votes a new user will be required to
get before being validated.
- No Votes: This is the number of nay votes a user can garner before being
denied access to the system.
- Level to Use NUV: Users must have this level to enter the new user voting
section from the main menu. Set this higher then the New user security level to
prevent a user from voting on himself!
- Level to Force NUV: If a user has this level, he or she will automatically
be dropped into the NUV system when they log onto the system if there are new
users to vote on. This is a handy way of making your high access users do
something with their access.
The process works like this. When a new user logs on, the applicant will enter
all their normal information, plus Information Script #5, which is reserved for
the New User Voting section. The applicant will be given 0 Yes and 0 No votes.
When other users call, they may enter the New User Voting section and view the
existing applicants awaiting a decision. They may scan for applicants they
have not voted on, and be given the option to view the special fifth Information
Script,(Sysops can also View Information Script #1, the Sysop Application
Information Script) and make a judgement (yes, no, or abstain) on the applicant.
Users may change their vote at any time before the Yea or Nay threshold has been
reached. Voting users may enter a 50-character comment regarding the user.
Sysops have 2 additional Choices: Veto Validate and Veto Delete which overrides
the voting statistics for the Applicant. When the new user attempts to log on
again, he or she will be given an up-to-date status report on how the voting is
going.
If enough YES votes are cast, the new user will be auto-validated (as per the
quick validate parameters set by the SysOp - create a template with the name
-----------------------------------------------------------------
Celerity v2.0 Page 47
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
"New User Voting") if the auto-validate option above is set. Otherwise, the new
user votes must be P)rocessed by the Sysop to finally validate or delete the
users.
If enough NO votes are cast, the user will be given an access level of -5, which
will give the user a message saying "Your application has been denied by the
user voting panel", and the users record will be deleted when he/she logs on
again. The text file "DENIED.BBS" will be displayed to users who have been
turned down. If the automated NUV option is turned off, the SysOp must manually
decide on each of the users before this action is taken.
Some new users will never call back, and in this case, the SysOp can simply scan
for users with -5 access who have not called in a week or so and delete them.
-----------------------------------------------------------------
Celerity v2.0 Page 48
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Local User Options
------------------
To many sysops, local users can be valued members of their system. To others,
however, they can be the bane of quality. The assumption that "good users will
call long distance to find good boards" is often found to be true. If your
objective is to have the largest base of users as possible, you would not want
to restrict local users. If, however, you want an intimate system specializing
in users from locations from all over the world, you would want to consider
limiting local access. Thus, Celerity offers the Local User Lockout
(abbreviated as LUL) system to limit the number of locals permitted on the
system. A local user is considered by Celerity to be one calling from the same
area code or set of local area codes as that of the BBS.
- Use Local User Lockout: This simply enables the LUL system.
- Local User Percentage: This is the percentage of local users allowed on the
system. Thus, as the system gets larger, the ratio of locals to non-locals
remains consistent. Some boards set this value as low as 5 or 10%. Note that
if additional local users are added manually by the SysOp, or if non-local users
are deleted from the system, or if this number is lowered, the actual percentage
of local users may be higher than this value. Until the percentage falls below
this defined value, no additional local users will be accepted.
- Lockout Message: This is a single-line message which will be displayed to a
user who has been locked out by the LUL.
- Local Area Codes: The Area Codes entered here will be considered as "Local"
when implementing the Local User System (Useful for Large Metropolitan areas
that have several area codes). To use, simply enter the Area Codes, Separated by
Semi-colons. Example: The Los Angeles/Orange/San Bernardino/Riverside
quad-county area in Southern California would have a Local Area Codes listing
like this: 213;310;818;714;909
-----------------------------------------------------------------
Celerity v2.0 Page 49
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
User Ratios
-----------
User ratios are an effective means of measuring performance by users, and can be
used with the same degree of fairness for both new users and veterans of your
system. Celerity has three different ratios which can be used to restrict a
user from downloading. These are outlined below. In each case, there are two
values to be set in CELSETUP. The first is the ratio you wish to require, and
the second is an access level a user may have to be exempt from that ratio.
Also note that the user exemption flags can exempt a user from ratios as well,
despite his or her access level.
Please see the "Access Templates" section below for details on how multiple
ratio setups can be established for different access levels.
- Post/Call Ratio: Also known as a PCR, this is a number which considers the
number of posts a user has made against the number of calls made. If a user has
made 75 posts and 100 calls, his ratio would be (75 / 100) .75, or 75%.
Although quality users find it easy to maintain ratios of 200% or 300%, many
users will find the ratio excessively binding if it is over 50% (one post per
two calls).
- Upload/Download Ratio: Known as a UDR, this ratio calculates the number of
uploaded files divided by the number of downloads (a separate kbytes uploaded vs
kbytes downloaded ratio is also maintained). If the user downloads excessively,
this ratio can be used to cajole him or her into uploading occasionally to
maintain his or her ratio.
- General Ratio: This ratio is a composite of the PCR and UDR. If you choose
to make this the main restriction, users can specialize in either subs or
transfers and not be penalized for it. Users who have an extremely good UDR but
don't post often won't find themselves restricted, and vice versa. This can be
a happy medium for SysOps who wish their users to contribute to the subs,
but don't want to exclude users who are poor posters yet good uploaders.
-----------------------------------------------------------------
Celerity v2.0 Page 50
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Access Templates
----------------
The access template system allows the sysop to set up a number of ratio, daily
time, and daily download limits which are indexed by the user's access level
without setting each user's options individually.
When you select the Access Template dialog, you will see a list box containing a
list of all defined access templates. This list will contain a brief
description, and the level range the template will affect. Five buttons at the
bottom of the dialog allow you to A)dd a new template, E)dit an existing
template, R)emove an existing template, S)ave the template list, or C)ancel all
your changes.
If you A)dd a new template (or edit an existing template), you will be presented
with a detailed dialog which will prompt you for the following:
Template Description: This describes the access template. You might name it
"New Users" or "Basic Access" or "Valued Users" or "The BBS Staff".
Access Range: The access range specifies what the lowest level of user affected
by the template is, and what the highest level should be. Make sure that the low
level is less than the high level, and do not let levels overlap: two access
templates should not overlap the same level (ie: do not have one template for
access levels 10 to 20, and another one for 20 to 30 - the second one should be
21 - 30).
Required Ratios: This allows you to set the default ratios that a user of the
specified access level will get. You can set the Post/Call ratio,
Upload/Download ratio, and General Ratio independently. Please see the section
on "User Ratios" above for details.
Daily Limits: These fields allow you to specify the number of minutes a user
will receive every day on your BBS, and the daily download limit (in kilobytes)
that they can download. Note that if you have the system set to credit upload
time (see "Transfer Options" above), these limits can be extended during a call.
Expired Level: If the user's account expiration date passes, the user would be
lowered to the access level specified here. The "expired extension" is the
number of days that his new expiration date will be extended, so you can set up
a system where a user with "premium" access could be set to "favored" access for
30 days before lowering him further.
Note that if a user has a daily download limit, daily time limit, or ratio
defined in his or her user account OTHER THAN 0, the user's setting will
OVERRIDE any settings from the access template. If you wish to set everyone to
template standards, look for the "RESET.EXE" utility which can reset this data
for you.
-----------------------------------------------------------------
Celerity v2.0 Page 51
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Quick Validation Templates
--------------------------
The Quick-Validation templates use a setup similar to that of the access
templates, and are designed to compliment the access templates. The
Quick-Validation templates will allow a sysop to validate a new user with a
simple keypress, and be able to select from a list of different access
conditions to set with that one keypress rather than editing the user's access
details individually (use of the Quick Validation templates do NOT preclude
individual access tailoring, of course).
The initial dialog in Quick Validate Template displays a list box of all
previously defined quick validation templates. There are five buttons at the
bottom, which allow you to A)dd a new template, E)dit an existing template,
R)emove an existing template, S)ave the set of templates, or C)ancel your
changes and exit.
If you A)dd a new template or E)dit an existing template, you will be presented
with a detailed dialog which allows you to define the details of the template
with the following options:
Template Name: This is a name which you can give to the template for easy
recognition of the access conditions the template describes. Names could be
"Basic Access", "Preferred Access", "Premium Access", and "Celerity Developer
Access".
Access Levels: The template allows you to define the security level and the
transfer access level (usually unused). This level can correspond to an Access
Template defined elsewhere (see "Access Templates" above).
Exemption Flags: This allows you to set individual access exemption flags #1
through #5. Flag #1 will exempt the user from any post/call ratio, #2 exempts
the user from an upload/download ratio, #3 specifies exemption from any General
ratio, and #5 will make the user exempt from file points (ie: free transfers).
Flag #4 is not used.
User Access Flags: This allows you to set any of the 32 user access flags which
Celerity uses. See the section on "Celerity Access Conditions" below.
User Note: Every user has a user "note" which can describe his or her access
level to other users. It will appear in the user listing and may appear in the
message header the user posted. Optionally, users may be able to define thier
own user notes (see "System Options" and "New User Options" above).
To use the quick validation templates, an entry must be made in the console
keyboard definition (see "Customizing Console Commands" below) for the quick
validate. By default, this is Alt-V. When you activate this command, a list of
-----------------------------------------------------------------
Celerity v2.0 Page 52
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
the currently defined quick validate templates will be brought up and you may
select any one of them.
You should also define a special template called "New User Voting" which will be
used to validate users who were validated through the New User Voting section.
If you do not have this template, users validated in the new user voting section
will keep the access defined for new users in CELSETUP, which is usually not
sufficient.
-----------------------------------------------------------------
Celerity v2.0 Page 53
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Running Multiple Bulletin Board Systems
---------------------------------------
Through the logon shell, Celerity can be configured to give users a selection of
up to three different BBS' to enter when they connect. These separate BBS' can
be entirely independent, run different software, have different file and message
areas, and even have radically different purposes. Some systems have used the
second or third system slots for another BBS program (particularly to give
users a period of transition where they can call either), run a company support
board or shareware support board in addition to their hobby system, run an
online game environment (such as The Time of Chaos), or run a Remote Access /
Carbon Copy / PC Anywhere link to enable the sysop to take remote control of the
BBS computer.
To set up such an additional system, you should install the BBS/gaming
environment/door/remote link/whatever, in the normal manner. Then check your
MAIN.BAT file in your node directory, and ensure that there are errorlevel hooks
for 122 or 123. These hooks should call a batch file (the default is sys2.bat
for the 122 error and sys3.bat for the 123 error) which will change to the other
program's directory, run the program, switch back to the node directory, and run
main.bat again.
The other software should be set to connect when it detects a carrier and NOT
wait for an incoming call (because a user will already be online when it is
run), and to exit back to dos when the session ends. If you use a high speed
modem with a locked DTE rate, you should set the other software up to expect a
connection AT THAT DTE rate.
If you run Celerity as a second or third system, an example sys2.bat batch file
would look like:
c:
cd \system2
celerity.exe EXIT
cd \celerity\node1
main
The "EXIT" command line parameter for Celerity.exe instructs the program to exit
back to dos if there is no carrier present when it starts, thus if a user drops
carrier while the second system is loading, it won't sit in the WFC screen
waiting for callers there.
The last step is to run CELSETUP.EXE, and define a description for the second
and third systems in the system options and then go to the login commands
section to enter the Logon commands for the additional systems. Note that if you
do not use the lightbar logon shell, you can "hide" the commands for the
additional systems by writing alternate shell menu files "Shell.?" The most
common problem people have is that the second system does not identify the
-----------------------------------------------------------------
Celerity v2.0 Page 54
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
incoming call correctly. Usually this is because the DTE rate is not matched by
the second system. For example, Celerity is set up to use a modem with a DTE
rate of 38400 bps. The second system, however, is configured to expect a DTE
rate of 19200 Kbps, and thus gives the user garbage.
-----------------------------------------------------------------
Celerity v2.0 Page 55
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Multi-node Operation
--------------------
Celerity includes provisions for running a multiple node BBS. Each node runs as
a separate task under a multitasking operating environment such as DesqView,
Windows, PC-MOS, VM/386, Chicago, or OS/2 2.0's DOS compatibility box. You may
also use a local area network (LAN) and use a separate computer for each node.
Hybrid setups using multiple computers on a network running multiple nodes under
a multitasking environment are quite practical.
There are some concerns which must be addressed when using multiple nodes on a
single CPU under Windows, DesqView, or OS/2. Simply put, interrupt-driven I/O
(a normal serial card) is very time consuming for a computer, and if you have
more than two or three nodes using standard serial connections, the system can
bog down considerably. This isn't to say that it cannot be done, and you should
be able to run up to 8 low-speed modems on a fast CPU. If you have high speed
(9600+) connections, interrupt-driven I/O (serial cards) are not recommended,
but can be used. There are Celerity systems running four 28.8k nodes on single
50 or 66MHz 486 systems with a 115200bps DTE rates and 3500+ cps transfer rates
under DesqView and OS/2. In all cases, you should ensure that you have buffered
serial controller chips (UART) such as an a 16550AFN (See Appendix A for details
on SIO/UART chips).
Please also note that on ISA and VL-BUS machines, each serial port must have its
own independent IRQ. COM1 and COM2 are usually standardized as using IRQ 4 and
3 respectively, but in general practice, COM3 and COM4 will also use IRQs 4 and
3. Therefore, you will have a conflict. Acquire a serial card which will allow
you to set the IRQ independently for each COM port. Some companies such as GTek
and Boca make multi-UART serial cards with this kind of flexibility. Note that
you CAN share IRQs on an IBM PS/2 machine with Microchannel (MCA), or on an EISA
machine running OS/2. Also note that if you create a local-only node, you can
set it to COM0 which does not require an IRQ.
If you wish to run multiple nodes on one machine, but wish to minimize the
performance drop, you should consider the purchase of an intelligent serial I/O
card. DigiBoard intelligent boards are directly supported by Celerity BBS (with
the DigiBoard supplement), and other boards (such as the GTek intelligent
boards) may be used with the FOSSIL supplement if they support a FOSSIL driver.
Using intelligent boards, up to 16 (possibly even more) high speed nodes
can be run off one CPU.
To add an additional node to a system set up for one node, you must make as many
additional node directories as you require, one for each additional node. In
this directory, you must copy the following files:
CELERITY.EXE
CELERITY.OVR
CELSETUP.EXE
-----------------------------------------------------------------
Celerity v2.0 Page 56
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
SETUP.DAT
MODEMLST.DAT
MAIN.BAT
Go into the NODE1 directory, and run CELSETUP. Change the "Specific Node
Directory" to your new NODE1 directory. Be sure you have a "Common Node
Directory" set correctly. Celerity will use this to keep track of what is going
on with the other node, and for multinode chat. Be sure all the COM port
parameters are set correctly for your COM1 port. Go to BBS Node number and
change it to 1, for node 1. Now save and exit. Change to your NODE2 directory,
and run the CELSETUP there. Change the Specific Node Directory to the NODE2
path. Change the COM port settings to your COM2 port. Change the BBS node
number to 2 for node 2.
Now create two batch files in place of your old Celerity startup batch (commonly
MAIN.BAT) file. Copy your old startup Batch file to a file called NODE1.BAT and
also to NODE2.BAT. Go into each batch file and have it change the directory to
your NODE1 directory and your NODE2 directory, respectively. Change any other
applicable directory settings. Also add a line to the beginning of the batch
files that changes the DSZ log to a node specific file. SET DSZLOG=DSZNODE1.LOG
is an easy way. That way both nodes have their own log file so when two
transfers are in progress one log won't be overwritten by the other node.
When you put the system up, switch to the node directory and run the NODE1.BAT
file (which may need some modification if you are using pathnames in it).
Run each node as a single task to verify that it is set up correctly and
communicating with your modem.
Alter your CONFIG.SYS and make sure you have plenty of FILES available, by
adding or modifying the line "FILES=xx" line in your config sys. A general
suggestion would be to set 20 files, plus 6 additional files for each additional
node.
It is advisable that you use a disk cache, such as NCache or SpeedCache (from
Symantec), PCKwik, PC Tools' cache, or even (as a last measure) Microsoft's
SmartDrive. Use of a disk cache will improve performance considerably.
You should also consider loading SHARE.EXE before running the BBS. Under certain
networking configurations, however, SHARE.EXE may not be compatible. Some
third-party doors and utilities may not like the presence of SHARE either. If
you have problems where only one user can enter a transfer section at one time,
try removing (or adding) SHARE.EXE.
When you have all of your nodes set up, load up your multitasking environment or
LAN. Start a separate task (or separate machine on a LAN) for each node on the
BBS, switch to its NODE directory, and run the MAIN.BAT. The system should now
be up and running in a multi-nodal format.
-----------------------------------------------------------------
Celerity v2.0 Page 57
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
On a multi-node system, users can enter the multinode chat and talk to other
users who may be on other nodes at the time. Up to 8 users may use the chat at
a time.
-----------------------------------------------------------------
Celerity v2.0 Page 58
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity Under DesqView
-----------------------
Celerity is designed to run with optimum performance under the DesqView or
DesqView/X multitasking environments from Quarterdeck Office Systems.
To set up your BBS under DesqView, please follow the initial steps above to
install the different nodes of your BBS. Once you set all nodes up, ensure that
they are communicating with their modems correctly and have accurate pathnames
and access to third-party utilities (DSZ, PKZIP, etc.), load up DesqView or
DesqView-X.
With DesqView (DesqView-X uses similar procedures), you may set up a separate
menu item for each node of the BBS. Add a new entry for your first node by
selecting O)pen Window from the main menu, then AP (for A)dd P)rogram).
DesqView will give you a list of applications it has information on. Choose the
O)ther option, because Celerity is not in its list of recognized programs. Fill
out the DesqView information boxes as per the instructions included in your
DesqView manual. See the example below:
+---Change-a-Program--------------------------------------------------------+
| Standard Options |
| |
| Program Name..........: Celerity Node #1 |
| |
| Keys to Use on Open Menu: C1 Memory Size (in K): 320 |
|---------------------------------------------------------------------------|
| Program...: c:\celerity\node1\MAIN.BAT |
| |
| Parameters: |
| |
| Directory.: c:\celerity\node1 |
|---------------------------------------------------------------------------|
| Options: |
| Writes text directly to screen.......: [N] |
| Displays graphics information........: [N] |
| Virtualize text/graphics (Y,N,T).....: [N] |
| Uses serial ports (Y,N,1,2)..........: [N] |
| Requires floppy diskette.............: [N] |
| |
| F1 for Help F10 for Advanced Options -+ when Done |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------
Celerity v2.0 Page 59
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Next, enter the Advanced Options by hitting F10.
+---Change-a-Program--------------------------------------------------------+
| Advanced Options |
| |
| System Memory (in K)......: 0 Maximum Program Memory Size (in K): |
| |
| Script Buffer Size......: 1000 Maximum EMS/XMS/VCPI/DPMI (in K): 1024 |
| |
| Text Pages: 1 Graphics Pages: 0 Initial Video Mode: |
|---------------------------------------------------------------------------|
| Window Position: |
| Maximum Height: 25 Starting Height: 25 Starting Row...: 1 |
| Maximum Width.: 80 Starting Width.: 25 Starting Column: 1 |
|---------------------------------------------------------------------------|
| Shared Program |
| Pathname..: |
| Data......: |
|---------------------------------------------------------------------------|
| Close on exit (Y,N,blank)...: [Y] Uses its own colors..............: [Y] |
| Allow Close Window command..: [Y] Runs in background (Y,N,blank)...: [Y] |
| Uses math coprocessor.......: [N] Keyboard conflict (0-F)..........: [0] |
| Share CPU when foreground...: [Y] Share EGA when foreground/zoomed.: [Y] |
| Can be swapped out (Y,N,blk): [N] Protection level (0-3)...........: [0] |
| |
| F1 for Help F10 for Standard Options -+ when Done |
+---------------------------------------------------------------------------+
This must be done separately for each and every node you wish to run under
DesqView. You may make deviations from the above recommendations based on your
system requirements.
Please allocate as much conventional memory to Celerity as possible on the first
screen. 320k is the absolute minimum that Celerity requires, and every extra
bit of available conventional memory will enhance Celerity's speed and
effectiveness.
You can have Desqview load the BBS nodes automatically upon startup by creating
a script macro as per the instructions in your DesqView manual. Provide the
script with a name beginning with an !, and the script will be executed every
time DesqView is started.
You will probably want to tune DesqView's performance options to ensure that
maximum performance is achieved. The optimum settings will vary between
different hardware platforms, so the best rule is to "experiment", and check
your DesqView manual for details. When adjusting time slice allocations, it is
generally found that the lower the time slice (ie: 1 foreground/1 background,
-----------------------------------------------------------------
Celerity v2.0 Page 60
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
2/2, 3/3) often creates a smoother BBS, while larger time slices (9/9, 12/12)
create a faster but jerkier BBS.
When running under DesqView, Celerity will operate somewhat differently than
when under a single-task DOS environment. Most obviously, the Wait for Call
screen will not be animated in the same way, and will seem to run much slower.
Additionally, other functions of the BBS may run slower than they do under a DOS
environment. The reason for this is Celerity's intelligent time slice control,
which will "release" CPU cycles to other tasks when the BBS is performing a
non-speed-dependent task (such as the wait for call screen or waiting for user
input), so other background tasks will run quicker. On CPU-intensive tasks,
Celerity will not release the cycles.
In a few places, certain local displays may "bleed" through other windows
(specifically, the password box when a user logs in, the F5 menu, and the Alt-H
sysop help menus and background editor). Under most circumstances, these should
not present much of a problem, but if it really bugs you (enough to take a
performance hit), you may enter a "T" in the "Virtualize Text/Graphics" box.
When setting up under DesqView-X, the setup will be similar to that of regular
DesqView, although the commands may be somewhat different (ie: Customize Menu /
Add instead of Add Program, etc.). Most operational details will be the same.
-----------------------------------------------------------------
Celerity v2.0 Page 61
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity under Windows
----------------------
Celerity BBS is also enhanced when running under the Windows 3.x environment,
although Windows is not known for its communications efficiency. To set up a
multi-node BBS under Windows, you should follow the initial steps above and
ensure all of your BBS nodes are running correctly under DOS. Make sure Windows
is installed correctly with the 386 enhanced options enabled.
The next step will be to open Windows' PIF editor and create an entry for
Celerity BBS. A Windows 3.1 example follows:
+---------------------------------------------------------------------+
| |
| Program Filename: c:\celerity\node1\main.bat |
| Window Title: Celerity BBS Node 1 |
| Optional Parameters: |
| Start-Up Directory: c:\celerity\node1 |
| Video Memory: [X] Text [] Low Graphics [] Hi Graphics |
| Memory Requirements: KB Required: 550 KB Desired: 640 |
| EMS Memory KB Required: 0 KB Limit : 1280 |
| XMS Memory KB Required: 0 KB Limit : 0 |
| Display Usage: [ ] Full Screen Execution: [X] Background |
| [X] Windowed [ ] Exclusive |
| [X] Close Window on Exit |
+---------------------------------------------------------------------+
And the advanced options..
+---------------------------------------------------------------------+
| |
| Background Priority: 50 Foreground Priority: 100 |
| [X] Detect Idle Time |
| |
| Memory Options: |
| [ ] EMS Memory Locked [ ] XMS Memory Locked |
| [X] Uses High Memory Area [ ] Lock Application Memory |
| |
| Display Options: |
| Monitor Ports: [ ] Text [ ] Low Graphics [ ] High Graphics |
| [X] Emulate Text Mode [ ] Retain Video Memory |
| |
| Other Options |
| [X] Allow Fast Paste [X] Allow Close When Active |
| |
+---------------------------------------------------------------------+
-----------------------------------------------------------------
Celerity v2.0 Page 62
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
If you are familiar with customizing Windows, these details may be adjusted to
your particular preferences. Please see your Windows operations manual for
details.
Once you have created a PIF for each node (the same one can be edited and
re-saved for subsequent nodes), create a new program group for your bulletin
board. Then, within that group create a new program item. Have this item point
to the first PIF file.
+-----------------------------------------------------------------+
| |
| Description: Celerity Node 1 [OK] |
| Command Line: c:\celerity\node1\cel1.pif [Cancel] |
| Working Directory: c:\celerity\node1 [Browse] |
| [X] Run Minimized [Change Icon] |
| [Help] |
| |
+-----------------------------------------------------------------+
You may select an alternate icon for Celerity if you wish. The "run minimized"
box should be checked if you do not want your BBS nodes to be visible on the
desktop, but be iconified in the corner. The BBS will run slightly faster if
iconified.
Once you have created the new program item, and Windows has checked the paths
for accuracy, click on the icon to test it to make sure the BBS will come up
under Windows. Once this is successfully attained, go back and create
additional program items for each additional BBS node.
** Note ** Ensure that each window is set up for background operation and not
for exclusive operation. If you do not, only one node will function at a time.
You may adjust the window font sizes, windowed/full screen operation, and time
slice settings to tailor your performance under Windows. You may also wish to
check the 386 Enhanced options in the Windows control panel when tailoring
performance.
-----------------------------------------------------------------
Celerity v2.0 Page 63
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
When communicating under Windows, you should also make some changes to the
SYSTEM.INI file to ensure that Windows does as little to hinder communications
as possible. Under the [386Enh] heading, you should set:
Com1AutoAssign=0
Com1Base=3f8h
ComIrqSharing=1
ComBoostTime=10
Com1Buffer=1024
etc.. for each COM port which will be used by a Celerity node under Windows.
Alter the above command accordingly depending on what your serial settings are.
You need include entries only for those COM ports being used by Celerity BBS
under Windows. Read your Windows documentation for additional details relating
to Windows communication.
-----------------------------------------------------------------
Celerity v2.0 Page 64
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity under Windows 4.0 "Chicago"
------------------------------------
Celerity has been tested under a beta version of Microsoft's "Chicago" (or
Windows 4.0 / DOS 7.0). Chicago is a considerably more robust multitasking
environment than Windows 3.1x, and provides performance similar to that of OS/2
2.0.
Setup under Chicago will be similar to that of Windows 3.1x, but we cannot
provide exact details until Windows 4.0 has been released.
-----------------------------------------------------------------
Celerity v2.0 Page 65
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity under OS/2
-------------------
OS/2 v2.x is probably the optimum multitasking environment for Celerity BBS, if
your machine has the resources to run it (those with lesser setups should
probably go with DesqView or Windows). Celerity has been optimized for
efficiency under OS/2 2.x, and works quite well in this environment. There are
a few details you should pay attention to to ensure smooth operation:
Under OS/2 MDVM's (Multiple Dos Virtual Machines) some communications programs
have trouble detecting the serial port's RING INDICATOR. This is the default
method that Celerity uses to detect and answer an incoming call. The
alternative to answering on Ring Detect is to answer on carrier Detect (see
"Modem Setup" above).
Normally Celerity does not enable the AUTO ANSWER mode of your modem. The
primary advantage to this method (and the reason it is the default) is that the
modem never answers the call unless the BBS program is up and running. Once the
modem's Auto Answer mode is turned on, your modem will automatically send an
answer carrier when the modem detects a ring. Once a carrier is established,
Celerity will detect that the modem has connected, and bring up the login
screen.
Turning on the Auto Answer is very simple. Follow these four steps:
1) Run Setup.
2) Select "Modem Setup"
3) Change the "Answer on Ring #" field from 0 (Zero) to
1 (one).
4) Save the new settings.
Celerity will automatically send an inititialization string to put the modem in
Auto Answer mode. If you have an external modem, you will see that the Auto
Answer indicator is ON.
Ray Gwinn produces a replacement set of serial drivers for OS/2 2.x and markets
them via shareware. Current versions of Gwinn's SIO drivers can be found on the
Celerity technical support board, and will provide better performance under
OS/2.
-----------------------------------------------------------------
Celerity v2.0 Page 66
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Setting up your Celerity DOS Session under OS/2
-----------------------------------------------
It is recommended that you create a new icon for the DOS session that will run
Celerity. It is suggested that you use the following settings:
Path and file name: * - Run the default command
interpreter.
Optional Parameters: /K
MAIN.BAT - Start the MAIN batch file.
Optional Working Dir C:\CELERITY - Or whatever path you use.
Using these settings OS/2 will start Command.Com and then run the Celerity
MAIN.BAT file. Be sure to provide the path to the Celerity directory in the
Working Directory field.
OS/2 gives the user a lot of options for customizing the way a DOS program runs.
The Dos Settings option for each DOS session has long list of these options.
For better results, consider the suggested changes to the settings listed below.
Please note that these are only suggestions, and can changed to suit your needs
and preferences.
COM_DIRECT_ACCESS OFF
COM_HOLD On. This setting will protect the serial port.
COM_SELECT 1 Or whatever com port you're using.
DOS_HIGH ON
DOS_UMB ON
EMS_MEMORY_LIMIT 1024K Celerity can use some EMS memory.
IDLE_SECONDS Zero
IDLE_SENSITIVITY 100
HW_ROM_TO_RAM ON
HW_TIMER ON
INT_DURING_IO ON
XMS_MEMORY_LIMIT 64
Also keep in mind that a "Windowed" DOS session does not perform as well as a
full screen session. It is best that you configure each Celerity session to run
in full screen mode, or minimize them on the desktop when you aren't watching
them if you prefer windows.
It has been recommended that Celerity be installed on an HPFS volume for optimum
performance.
System Example: On one installation, four nodes of Celerity BBS were running
with little performance degradation on a 16mb EISA 50MHz 486. Three high speed
nodes could transfer at full speed with a fourth local node. This was under
OS/2 version 2.0.
-----------------------------------------------------------------
Celerity v2.0 Page 67
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Setting up your Celerity OS/2 Session under OS/2
------------------------------------------------
Celerity can also be run from an OS/2 native OS/2 session. The advantages of
running Celerity in this manner is that you can run OS/2 programs from the
MAIN.BAT, or create a REXX script to replace your MAIN.BAT.
To do this, it is recommended that you create a new icon for the OS/2 session
that will run Celerity. It is suggested that you use the following settings:
Path and file name: * - Run the default command
interpreter.
Optional Parameters: /K
MAIN.BAT - Start the MAIN batch file.
Optional Working Dir C:\CELERITY - Or whatever path you are
using.
Using these settings OS/2 will start Command.Com and then run the Celerity
MAIN.BAT file. Be sure to provide the path to the Celerity directory in the
Working Directory field.
Now in the Sessions select "OS/2 FULL SCREEN" and Celerity will run in a OS/2
full screen session. No settings needed. I have found this to be the best way
to run Celerity in OS/2.
-----------------------------------------------------------------
Celerity v2.0 Page 68
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Setting up your OS/2 CONFIG.SYS for running Celerity
----------------------------------------------------
The OS/2 CONFIG.SYS is very complex, and you should know what you are doing
before modifying this file. Below is a sample CONFIG.SYS which may give you
some hints, but DO NOT COPY THIS CONFIG.SYS directly to your OS/2 setup or you
will most likely have problems.
IFS=C:\OS2\HPFS.IFS /CACHE:64 /CRECL:4
PROTSHELL=C:\OS2\PMSHELL.EXE
* SET RESTARTOBJECTS=STARTUPFOLDERSONLY
SET USER_INI=C:\OS2\OS2.INI
SET SYSTEM_INI=C:\OS2\OS2SYS.INI
SET OS2_SHELL=C:\OS2\CMD.EXE
SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS
SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE
SET COMSPEC=C:\OS2\CMD.EXE
LIBPATH=.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\EZTAPE; SET
PATH=D:\GAMMA32;C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INST
ALL;C:\OS2\MDOS;C:\OS2\APPS;C:\; SET
DPATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:
\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS; SET
PROMPT=$p$_$t$h$h$h$h$h$h$g
SET HELP=C:\OS2\HELP;C:\OS2\HELP\TUTORIAL;
SET GLOSSARY=C:\OS2\HELP\GLOSS;
* PRIORITY_DISK_IO=NO
* AUTOFAIL=YES
DEVICE=C:\OS2\TESTCFG.SYS
DEVICE=C:\OS2\DOS.SYS
DEVICE=C:\OS2\PMDD.SYS
DEVICE=C:\OS2\VDISK.SYS 4096 128 64
* BUFFERS=30
IOPL=YES
* DISKCACHE=1024,32,LW,AC:CDE
* MAXWAIT=1
MEMMAN=SWAP,PROTECT
SWAPPATH=C:\OS2\SYSTEM 1024 1024
BREAK=OFF
* THREADS=512
PRINTMONBUFSIZE=134,134,134
COUNTRY=001,C:\OS2\SYSTEM\COUNTRY.SYS
SET KEYS=ON
REM SET DELDIR=C:\DELETE,512;D:\DELETE,512;E:\DELETE,512;
BASEDEV=PRINT01.SYS
BASEDEV=IBM1FLPY.ADD
BASEDEV=IBMINT13.I13
BASEDEV=OS2DASD.DMD
SET BOOKSHELF=D:\GAMMA32;C:\GAMMA32;C:\OS2\BOOK
-----------------------------------------------------------------
Celerity v2.0 Page 69
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
SET EPATH=C:\OS2\APPS
PROTECTONLY=NO
* SHELL=C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /E:1024 /P
FCBS=16,8
RMSIZE=640
DEVICE=C:\OS2\MDOS\VEMM.SYS
* DOS=HIGH,UMB
DEVICE=C:\OS2\MDOS\VDPX.SYS
DEVICE=C:\OS2\MDOS\VXMS.SYS /UMB
DEVICE=C:\OS2\MDOS\VDPMI.SYS
DEVICE=C:\OS2\MDOS\VCDROM.SYS
* DEVICE=C:\OS2\MDOS\ANSI.SYS
SET VIDEO_DEVICES=VIO_SVGA
SET VIO_VGA=DEVICE(BVHVGA,BVHSVGA)
DEVICE=C:\OS2\MDOS\VSVGA.SYS
CODEPAGE=437,850
DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP
SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA)
DEVICE=C:\OS2\MDOS\VMOUSE.SYS
DEVICE=C:\OS2\POINTDD.SYS
DEVICE=C:\OS2\MOUSE.SYS
* rem DEVICE=C:\OS2\COM.SYS
* rem DEVICE=C:\OS2\MDOS\VCOM.SYS
* DEVICE=C:\SIO.SYS
* DEVICE=C:\VSIO.SYS
Change or add the ones marked with a "*".
The final two lines refer to Ray Gwinn's shareware SIO serial drivers (which are
available on the technical support board). These drivers are far superior to the
IBM serial drivers.
One final note: Get a 16550 UART (or other buffering UART) Multitasking
operating systems such as OS/2 can really benefit from a buffered UART. OS/2
will detect and make full use of your 16550. (See Appendix Afor a complete
discussion of SIO Cards)
-----------------------------------------------------------------
Celerity v2.0 Page 70
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity under a Local Area Network
-----------------------------------
The most effective multi-node installations of Celerity BBS are run on local
area networks, such as Novell Netware 3.1x and Netware 4.0 (requiring a
dedicated network server), Netware Lite v1.0, Artisoft LANTastic, and PowerLAN
(peer-to-peer).
** SET UP YOUR NETWORK AND ENSURE THAT IT OPERATES CORRECTLY BEFORE SETTING UP
CELERITY ON THE NETWORK!
It is best if all systems on the network map their drives consistently (ie:
drive F: is the same on all systems, drive G: is the same on all systems, and so
forth). Any decent network will let you establish these drive mappings so that
you do not have to refer to a drive as C: on one machine and Q: on another.
Ensure that your network hardware does not use an IRQ or port address being used
by your communication hardware, or you may find your network suddenly crashing
when Celerity tries to open the serial port.
Set up all BBS nodes as per the instructions at the beginning of this section.
Ensure that each node will work independently before attempting to run all nodes
simultaneously. Refer to your network documentation for details on how the
network handles file sharing, and make sure you take the appropriate steps to
ensure that files can be opened by multiple tasks. With Novell Netware, you
should flag all Celerity data files as sharable. Under 3.1x, you should
type the command "flag *.* +s" in each Celerity directory. Under Netware v4.xx,
you should use "flag *.* +sh".
After flagging all files as sharable, bring up each node on the network and
verify its functionality.
With some networks, you may need to load SHARE.EXE. With others, you should NOT
load SHARE.EXE. With some versions of LanTastic, for example, SHARE.EXE will
cause problems. Disable all internal file sharing support that LanTastic
provides to preserve your sanity.
-----------------------------------------------------------------
Celerity v2.0 Page 71
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Running Celerity from a RAMdisk
-------------------------------
Celerity is quick, but can be made even quicker if parts of it are contained on
a RAMdisk. Observe the following list of Celerity directories which can be run
from a RAMdisk, and the APPROXIMATE requirements for each directory. Note that
some directories will grow in size over time, so keep an eye on how much free
space you have:
- Node Directory: (Requires 800-1000k) Having a node directory on a RAMdisk
makes the loading of the board and it's segments (which are loaded from the
overlay file) much quicker. This will permit maximum speed when switching from
section to section. The size can be reduced by not copying the celsetup.exe or
documentation files.
- BBS Directory: (Requires 2000-4000k) This directory will greatly increase the
speed at which users are looked up when sending email, logging on, or when
awarding download commissions. Post-downloading accounting is also sped up.
- Language Directory: (Requires 500k to 1500k) Placing the files from this
directory in a RAMdisk results in quicker menu display and text lookup speed.
Therefore, this will result in the biggest single speed increase of all!
- Data Directory: (Requires 500k to 3 megs) The requirements of the data
directory will vary depending on the number of transfer areas you have, the
number of files in each area, and the number of subs you have. Buffering this
directory from a RAMdisk will provide the most noticeable speed increase when
people list files, read posts, upload or download, read or send mail.
- Display Directory: (Requires 10k to 50k+) This will slightly increase the
speed at which canned text files (new user messages, info-scripts, etc.)
display.
- Conference Directory: (Requires 5 to 15 megs) Putting this directory on a
RAMdisk will result in great performance increases in the message bases,
newscanning, and conference navigation. Only the greatest RAMdisks can handle
this directory!
- Temporary Directory: (Do Not Buffer) The temporary directory must have
enough room to store the largest batch upload a user will ever make - plus
additional space as large as the largest file uploaded. If the largest batch
upload were ten 100k files, an 1100k directory would be sufficient, but that is
unrealistic. When a user attempts to upload six 1 meg files to a 1100k RAMdisk,
he is bound to be angry. (Of course, if you own a Pentium and have 4 Terabytes
of RAM, be my guest!)
When using a RAMdisk, particularly for directories which will be updated from
time to time, it is imperative to have the files automatically backed up to a
-----------------------------------------------------------------
Celerity v2.0 Page 72
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
hard drive between calls. An easy way to do this is to add a line in your
main.bat file:
xcopy f:\celerity\*.* c:\celerity /s /m
Assuming your BBS is in the c:\celerity directory, and your ramdrive is drive
F:, this will copy all files from a RAMdisk (f:) to a hard drive (c:) in the
"celerity" directory. The /s parameter tells Xcopy to copy all subdirectories
(celerity\data, celerity\menus, etc.), and /m checks for archive bits to be set.
If you xcopy all the files you wish to buffer to the RAMdisk, the archive bits
will be cleared, and thus all the files would be automatically copied back to
the hard drive when main.bat is first run. On subsequent runs, such as when the
board is put back up after a user has logged off, only the files which have been
changed will be copied. Do not trust a RAMdisk to hold data for weeks at a
time, backing up after every call is generally a safe bet. Lastly, keep an eye
on the space free on your RAMdisk (Put it in your WFC Drive Scan String). Any of
the directories above shouldn't change size rapidly, but may eventually get
larger and cause problems if they fill up the RAMdisk.
System Example: There is one 4-node Celerity BBS running on DesqView on a 66MHz
machine with 32 megs of RAM. 25 megabytes were reserved for a RAMdisk, which
was stacked with Stacker, providing a RAMdisk of about 50 megabytes of storage.
Needless to say, the BBS was quite quick!
-----------------------------------------------------------------
Celerity v2.0 Page 73
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Modes of Operation
------------------
Celerity BBS has three basic modes of operation:
1: Celerity BBS - The full featured bulletin board system.
2: CAE - A transfer-only system (like a term program host
mode).
3: CAE/TAC - The CAE transfer-only system, but with user
accounts.
4: Alacrity BBS - Alacrity BBS was a special version of Celerity with
an alternative menu structure. With version 2.00,
Alacrity modes were integrated into the mainstream
BBS and Alacrity mode was discontinued.
The CAE and CAE/TAC modes will be discussed below.
CAE Mode
--------
The CAE (Celerity "ASCII Express") was inspired by an old terminal program for
the Apple ][ called ASCII Express. ASCII Express had a special host mode where
any user could call in (some systems required a password) and transfer files.
There were no message bases, no user accounts, no email, no file ratios, or
other conventional bulletin board features. All callers were given the same
access and the same amount of time online.
The CAE is basically like a terminal program's host mode, except it affords the
full power and flexibility of the Celerity file system.
The CAE will ask for a user's handle and area code upon login, but this
information is kept only in the system logs, and no user account information is
saved. Once this information is established, the user is given complete
homogenous access to the transfer areas, being able to download whatever he or
she pleases, with no obligation to upload.
What's the purpose? There could be several reasons for running a CAE. File
distribution is one. Users uploading to a CAE system may get the file
downloaded freely by callers and spread across the nation in a few days,
spreading it much more quickly than via conventional channels. Or, if you run a
BBS for your business or wish to distribute files free of charge, the CAE mode
would be ideal.
The CAE is an open access system, meaning anyone can get on at any time. One way
to limit access from anyone with your number is to enable the System 1 password
(or the CAE password if you do not want to run a full CAE system) in CELSETUP.
After connection, the user will first be prompted for the password, then normal
-----------------------------------------------------------------
Celerity v2.0 Page 74
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
logon procedures occur, thereby limiting access to the specific users who you
wish to have access to your system.
The transfer area structure is the same as in normal Celerity operation, except
that users cannot send mail or have access to non-conference items.
A CAE would traditionally only contain transfer areas, but with the Celerity
v2.0 CAE, you can place any conference item in the CAE tree.
Use the CAEINTRO.ANS file to pass information along to users after login.
CAE/TAC Mode
------------
The CAE/TAC (Total Access Control) mode is related to the CAE mode but with one
major difference - it has individual user accounts. This allows more control by
the SysOp over who gets access (and what type of access) to the system.
The CAE/TAC system looks like a CAE system from the users' point of view, and a
normal BBS from the SysOp's, since the SysOp must have access to the SysOp menu
in order to edit user accounts. All functions are similar to the CAE mode, with
the following exceptions:
Since user accounts exist, the Top Ten function can be enabled in CELSETUP.
Users must login in as new on the first call, so information scripts may be
present, and the new user feedback option can also be enabled. The system can
have a co-SysOp, since a specific user's access can be adjusted. Any user with
co-SysOp level privileges logs onto the normal main board like the SysOp (as
opposed to the transfer area restriction placed on all other users).
The CAE/TAC system utilizes the message bases and email as well. Email to users
is allowed in this mode - if mail exists for the user, the user is first placed
into the email section, and then, upon exit, the user enters into the CAE
system's transfer area.
Since you control access levels, you control what the user can do. The amount of
online time each user has per day is controlled via the general access level,
while the specific file areas each user has access to is controlled via the xfer
access level. This is helpful to separate the major contributors from the
average users, or to limit access to certain file areas.
Because a new user must apply for access, it is a good idea to activate a login
shell, such as the lightbar menu shell. This way, a new user can find he or her
way easily enough. You can also enable other login shell functions, such as
feedback and chat, so users can contact you.
-----------------------------------------------------------------
Celerity v2.0 Page 75
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Since the whole board is actually utilized, install any of the wide variety of
menus available for Celerity, then install the CAE/TAC menus over them. This
way, you have your menus, and the users have theirs.
With TAC mode, you completely control what users can access the system. Use the
information scripts and new user feedback to gather complete information on an
applicant if this precaution is warranted.
It is recommended you create your own statistics files because Celerity's
internal displays contain information that the user doesn't need, such as new
posts. Since the system is still basically a CAE, this information is
meaningless and can only confuse new users. Note, however, that file points,
commissions, and ratios CAN be enabled for a CAE/TAC.
See "customizing your BBS" for more details.
The WELCOME.1 file is an excellent way to communicate policies and to pass on
information to your users. PRELOGIN.BBS is also helpful (when the login shell
is enabled), but can be viewed by anyone calling in, not just validated users.
Automessages and news bulletins are not viewed by the users.
-----------------------------------------------------------------
Celerity v2.0 Page 76
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
MAIN.BAT Operational Details
----------------------------
Celerity is run from a batch file. This batch file should loop on itself to
keep the system running if it is the only system. See the example "main.bat"
file for an example. Celerity will return with the following errorlevels for
certain conditions:
127: FAX connect detected - run FAX software
125: Run terminal program
124: Run SysOp-defined event (Sysop hit F6 from WFC)
123: Run system 3
122: Run system 2
100: Exit bbs (don't re-run batch file)
67: Run the CELSETUP.EXE program
50: Exit BBS
3: Used to operate nightly events
Command Line Parameters
-----------------------
A number of Celerity functions can be called from the DOS command line, to
facilitate using its features from another program which calls Celerity. The
commands refer to the first parameter, although some may take additional
parameters.
Celerity exit : This command will cause Celerity to exit if there is no carrier
present, rather than go to the WFC. This option would be used if you use a
front-end program.
Celerity link d b : Load up Celerity at DTE rate d and bps rate b
Celerity load d u : Load up Celerity at DTE rate d and load user #u
Celerity noverify : Load Celerity, but skip some on-load error checks
Celerity speed : Do a simple benchmark on your system
Running MAIN.BAT For The First Time
-----------------------------------
When you run MAIN.BAT the first time, Celerity will probably create a few
directories which didn't exist. If you run into problems here, enter
CELSETUP.EXE again and verify your directory locations. If you are running under
certain operating system conditions, you may have to create the directories
manually.
When the WFC (wait for call) screen appears, type F10 to log on locally. apply
as new, then log in with this new account. Make sure that you set up the "new
user level" to be higher than the "login level" in your celsetup, or you will be
-----------------------------------------------------------------
Celerity v2.0 Page 77
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
unable to get into the system with your newly created account. Once you are in,
Type Alt-S (or whatever you have the sysop access key defined to in your
keyboard definition file - see "Customizing the Keyboard" below) to give
yourself sysop access, and go into the user custodian and set all the sysop
flags on the account, change your access level, etc.
The next step is to enter the user configuration section normally "K" from the
main menu. Select your display preferences, option toggles, and the like. Be
sure you also change your password to something that you don't use elsewhere, as
it is imperative that you do not allow anyone else to enter the BBS using your
SysOp account.
After you've finished playing with the defaults and password, you'll need to set
up the file areas, and message bases. The following sections will explain how.
-----------------------------------------------------------------
Celerity v2.0 Page 78
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity Access Conditions
--------------------------
With version 2.x, Celerity supports an extensive system of access control for
message bases, file areas, menu commands, and more. There are a number of access
conditions which can be checked, and a user must pass all of them to gain access
to the particular area or command. The conditions are not case-sensitive, and
must be followed by an equals (=) sign and the value to compare. The following
conditions are currently supported:
SF= Sysop flag number.
UF= User flag number.
SL= User's security level.
XL= User's xfer level.
AGE= User's age.
BAUD= User's connect rate.
TL= Time left online today.
AC= User's area code.
NODE= BBS node.
For example,
SF=11 UF=4 SL=50 AGE=30 NODE=2
Will only allow a user who meets the following conditions:
1: Has sysop flag #11 set (SF=11)
2: Has user access flag #4 set (UF=4)
3: Has a security level of 50 (SL=50) or more
4: Is at least 30 years old (AGE=30)
5: Is logged onto node #2 of the BBS (NODE=2)
Note that very few commands would have such an extensive list of qualifiers, but
we wish to give our sysops as much flexibility as possible.
Each user has 32 User Access Flags which may be defined by the sysop. Usually a
system may use separate flags to grant access to different sections of the BBS,
such as tagging access flag #1 for access to an Adult section, access flag #2
for a subscriber section, access flag #3 for a software developers conference,
and so forth. User access flags have no inherent definition, and can therefore
be used with impunity by a sysop. Consider that each user will have to be
edited and have a certain flag turned on, as all users are initially created
with no access flags set.
Each user also has 32 Sysop Access Flags. Unlike the user access flags
discussed above, Sysop Access Flags DO have inherent definitions which
correspond to various forms of sysop access around the system. With this
system, a Celerity sysop can give specific privileges to cosysops without giving
them total control over the system or unrelated sections.
-----------------------------------------------------------------
Celerity v2.0 Page 79
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
The definitions of the Sysop Access Flags are as follows:
1 : Unlimited time
2 : Can transfer to other users
3 : Get extended information
4 : Allow system parameter manipulation
5 : View anonymous mail
6 : Sensitive transfer activity
7 : Exempt from Auto-Timeout
8 : Appears In Feedback Listing
9 : Excluded from caller Log
10 : Art gallery sysop
11 : BBS list sysop
12 : New User Voting sysop
13 : Oneliner section sysop
14 : Sysop menu access
15 : User custodian
16 : Door section sysop
17 : Electronic Mail sysop
18 : Voting Section sysop
19 : May download private files
20 : System Configuration (conference editing)
21 : Message Sysop
22 : Transfer Sysop
23 : News / Bulletin Sysop
24 : Can use Remote DOS Session
25 : Can override multiple login restriction
26 : In Quick Local Login list
27 : (unused)
28 : (unused)
29 : (unused)
30 : (unused)
Note that "local" sysop access (for a subconference) can be set with the
"administration" access code in the conference system. This enables a sysop to
give cosysops control over a single message area or subconference without giving
them the global powers associated with Flag 21 or Flag 22.
-----------------------------------------------------------------
Celerity v2.0 Page 80
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity Conference System
--------------------------
Celerity 2.0 introduces an entirely new conferencing system to bulletin boards.
To use a metaphor, Celerity BBS is like a "grove" with a number of trees growing
in it. One of them is the message tree, one of them is the transfer tree, and
there are a few other trees as well. Each tree can have an unlimited number of
branches, and each branch can have an unlimited number of branches as well. On
the trunk or on branches there can be an unlimited number of pieces of "fruit".
With Celerity v2.0, the "fruit" can be a message base, a set of transfer areas,
an online doors section, an art gallery, a BBS list, a bulletin section, and
more. It is up to you as a sysop to design your trees and decide where to put
branches and where to put fruit. Unlike real trees, branches, and fruit,
Celerity's conferencing system will allow a single branch to be accessible from
multiple trees, a piece of fruit accessible from multiple branches, and even
make entire trees into branches of another tree.
Celerity achieves this through its new conferencing system which is made up of
.CNF files for trees and branches, and through .BSE, .XFR, .DOR, .LST, .ART,
.BUL, etc. files which represent different types of fruit. All of these files
are created when you create conferences and areas, so you need not concern
yourself with file extensions much.
Conference Structure
--------------------
The main tree trunks in a Celerity 2.0 system are the Message Tree (MAIN.CNF),
the Transfer Tree (XFER.CNF), the General interest Tree (GFILE.CNF) and the
Private Tree (PRIVATE.CNF). These trunks are accessed via commands at the
Celerity main menu (B/M, T/X, P, and Z). Although these trees have nominal
names, they can be used for any conference makeup you like, and do not have to
be messages, transfers, etc. The Global Newscan will scan MAIN.CNF, XFER.CNF,
GFILE.CNF and PRIVATE.CNF in that order. If you have a CAE available from the
login shell, it will use CAE.CNF as its root conference.
Users can navigate up and down the conference tree from the various conference
menus, or jump all the way back to the start with the "^" command. Access
restrictions can be placed on individual conference items, or on entire
subconferences to provide security for whole sections of the BBS in a simple
manner.
This structure provides an incredible amount of flexibility and potential for
large systems, but also retains a simple hierarchal interface. Small systems
will probably opt for a conventional SIG model, such as figure A. A larger
medium-sized system may prefer the conventional conference model shown in figure
B, while a large system may opt for a more diverse pattern such as figure C.
-----------------------------------------------------------------
Celerity v2.0 Page 81
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Please note that these are simply suggestions - it is entirely up to the sysop
to design exactly how he or she wants the system laid out.
Figure A: Simple Model
!---- SUBA.BSE (message base)
!
!---- SUBB.BSE (message base)
!
MAIN.CNF-----!---- SUBC.BSE (message base)
!
!---- SUBD.BSE (message base)
!
!---- SUBE.BSE (message base)
In figure A, we see a conference which has five message bases attached. This is
quite straightforward, and resembles a bulletin board selection system similar
to many other BBS programs like WildCat! or PCBoard.
-----------------------------------------------------------------
Celerity v2.0 Page 82
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Figure B: Conference Model
!---- CONFA.CNF (conference)----!---- SUBA.BSE
! !
!---- CONFB.CNF (conference) !---- SUBB.BSE
! !
MAIN.CNF ------!---- CONFC.CNF (conference) !---- SUBC.BSE
!
!---- CONFD.CNF (conference)
!
!---- CONFE.CNF (conference)
In figure B, we see that the message tree contains five branches, each of which
contain multiple message bases (detail is only shown on the first one). This
system resembles a conference-oriented BBS like Celerity 1.xx.
Both Model A and Model B demonstrate fairly simple conference setups, but
Celerity BBS is by no means limited to such simple configurations. Gigantic
interlocking trees can be created, providing elaborate access setups and special
interest areas.
-----------------------------------------------------------------
Celerity v2.0 Page 83
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Figure C: Complex Model
!---- CONFA.CNF (conference) ----!---- SUBA.BSE
! !
!---- CONFB.CNF (conference) !---- SUBB.BSE
! !
MAIN.CNF -----!---- CONFC.CNF (conference) --! !---- CONFD.CNF
! !
!---- DOORA.DOR (door section) !-!---- XFERA.XFR
! ! (xfer)
!---- CONFE.CNF (conference) --! !---- XFERB.XFR
! ! (xfer)
! !---- XFER.CNF
! (conf)
!-!---- ART1.ART
! (art)
!---- ART2.ART
! (art)
!---- SUBC.BSE
(message)
Figure C demonstrates a much more complex system, showing the main conference
which contains four sub-conferences (branches) and a doors section. The first
branch contains two message bases and another conference. The third conference
contains two transfer sections and a link to the XFER tree (XFER.CNF). The
fourth conference (CONFE.CNF) contains a pair of art galleries and a message
base (presumably for discussion of art). Figure C represents the flexibility
and power of Celerity 2.0's conferencing system, which can approach the
complexity and expendability of large information services like Prodigy and
Compuserve.
With all conference systems, users can easily scan all areas they wish to scan
via the Global Newscan command, which will save up to ten seperate newscan
configurations. With such ease of use, you could carry thousands of networked
special interest groups and users could scan only those which interested them on
a particular call.
-----------------------------------------------------------------
Celerity v2.0 Page 84
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Creating Conference Trees
-------------------------
When a sysop account cleared for system modification (sysop flag #20 set) enters
a .CNF for the first time (ie: goes into the message bases, transfer section,
gfile section, or enters a sub-conference set up in one of the previously listed
main trees), Celerity will prompt the sysop to create a conference item. If you
say yes, you will go into to conference item creation menu. This full screen
display will appear as follows:
[A] Name :
[B] Access Code : 2
[C] Read Access :
[D] Post Access :
[E] Admin Access : SF=100
[F] Password :
[G] Menu Path : c:\celerity\menu\
[H] Item Type : Message Base
[I] Data Pathname :
[S] Save Item
[Q] Quit without saving
The name will be displayed to users when they get a list of items in the
conference.
A numerical access code will be automatically assigned to the new conference
item, but you may easily change this to an alphanumeric access code if you like.
This is the code the user must type in to enter the particular section. Often
sysops will configure their systems to use numeric access codes for most areas
(ie: choose conference #1-5, choose sub #1-24), but others may opt for a more
unique format (ie: type IBM for the IBM conference, Amiga for the Amiga
conference, Paperweight for the Macintosh conference).
Read access is the access code needed for a user to enter the section in
question, or to even see it on a list. If they do not meet the access
requirements of the item, they will have no idea it exists. See the appendix on
access conditions.
Post access is similar to read access, but allows users to write to that
conference (ie: write messages).
Admin access allows you to determine who can have sysop powers within that
conference. Define this carefully, as a user who has Admin access can cause a
lot of headaches for you if they don't know what they are doing.
The password field allows you to define a special password required to enter the
conference item.
-----------------------------------------------------------------
Celerity v2.0 Page 85
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
The menu path is the path to a text file which will be displayed when the user
enters the section.
Item type: Pressing H will cycle through the various data types supported in
the Celerity v2.0 conferencing system. These include conferences, xfer sections,
message bases, online doors sections, art galleries, bulletin sections, bbs
listings, and more. If you wish to create a subconference of message bases or
xfer sections or whatever, select "subconference" (.CNF). Make sure you set
this correctly.
Data pathname: specifies the data file associated with this object. The filename
will automatically be generated when you enter the area name, but you can edit
it here if you like. You should edit it here if you want a single conference
item to be accessible from multiple conferences.
Save and quit: Both self explanatory.
After you create a conference item, you will need to enter the conference item
to actually set up certain parameters for the area. If you enter a .BSE (message
base) item, it will ask for parameters for that message base. If you enter an
.XFR (xfer section) item, you will be asked to define the first area in the xfer
section. If you created a .CNF (subconference) item, you will be prompted for
the first item within this new subconference. If you are setting up a new BBS
from scratch, it is suggested that you set up all of your conference items and
then do a global newscan to fill in all the data. If you do not define the
individual areas, users will not be able to access them until you do.
-----------------------------------------------------------------
Celerity v2.0 Page 86
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Creating Message Sub-Boards
---------------------------
Message bases are the heart of the message system of Celerity BBS. After
creating a message base conference item, you will need to enter the message area
to actually build the message base. The first time the sysop account enters the
message base, you will be presented with the following menu options:
[A] Name : ABase
[B] QWK Name : NewBase
[C] Data Pathname : c:\celerity\conf\abas.dat
[D] QWK Conf # : 12
[E] Networks :
[F] Options :
[G] Base News :
[H] Origin Line : A new sub-board!
[S] Save and Quit
[Q] Quit and abort
Name is the name which will appear at the top of every message as the user reads
the base. It is almost always the same as the conference item name, although it
can differ if you need it to.
QWK Name is the name of the base which will be passed in QWK packets. There is a
separate entry for this because Celerity allows longer area names than QWK
readers will allow. You may have a message base named "Celerity Computer
Communication" which would appear to a QWK reader as "Celerity Compu", which
obviously is not very enlightening. Thus, you could set the QWK name to
"Celerity Comms". Data pathname and Index pathname point to the index and data
files for the message base. Usually you will not need to mess with these.
Data Pathname: This is the path of where the data for the message base will be
kept. Four files will ultimately be created for each base, the .DAT file you
specify on this line, plus an index (.IDX), a base detail file (.BSE), and a
quickscan data file (.QSN).
QWK Conference # specifies where this message base will be placed in a QWK
packet. This _MUST_ be unique for every base on the system, or replies may get
sent to the wrong bases.
Options: The options selection contains various parameters for the specific
base:
- Full board limit: specifies how many posts Celerity will allow to remain in
this message base. If you set it to the default(100), Celerity will delete
messages when 100 messages exist on the board. If you set it to 20, only 20
messages will remain active at any time. If you set it to 20000, a whole lot of
-----------------------------------------------------------------
Celerity v2.0 Page 87
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
messages will remain active. When the limit is reached, Celerity will delete
the first message on the base to make room for new messages.
- allow anonymous posts: If set, users who have a SL equal to or above the
level set in CELSETUP (see "Access Levels" above) have the ability to make
anonymous posts.
- allow uploading: This option allows users to upload messages via a transfer
protocol. It is recommended for ease of use.
- allow post downloads: If set, users will be able to download a single message
as a text, ANSI, NAPLPS, or RIP file.
- allow file attachments: If set, Users can attach a file to a message (you
could post an ad for a FIDO Network, and attach the application form). The
attach path is where these special files will be stored.
- allow ANSI messages: If this is set, all ANSI color and cursor commands will
be stripped from the message. Some networks do not allow ANSI codes in thier
messages.
- allow NAPLPS messages: This setting will allow NAPLPS graphic messages to be
uploaded.
- allow Personal messages: This setting will set the base to support personal
messages only, as required by some networks.
Networks: This provides information on setting up Fido Echomail networks and
QWK-based networks, which include the network type, the address of the system in
that particular network, the network echo name for the current base, and the
network identifier.
- Base news: is the path to a text file which will be displayed when the
message base is entered.
- Origin line: is a line of text which will appear at the bottom of all network
posts which originated on this particular message base.
- Quit and Save are self-explanatory.
When you've finished with the sub, post the first message there. This message
should introduce the message base and indicate what it is to be used for.
-----------------------------------------------------------------
Celerity v2.0 Page 88
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
FidoNet Conferencing
--------------------
Please see the documentation with the CelToScn utility developed by Ted
Spaulding.
Using QWK Offline Readers
-------------------------
Celerity has the ability to create packets of messages which can be read with
any QWK-compatible offline reader. This allows users to quickly log on, create
and download a packet containing all their new messages, log off, and then read
the messages at their leisure without incurring phone costs. When the user
responds to messages, a REP response packet is created, and the user can upload
it to a Celerity board for processing.
Before the user can generate a QWK packet, he or she must define the bases he or
she wants to scan. This is done via the normal configuration process of the
global quickscan.
When the SysOp sets up his system, there are a couple files that should be
created for the QWK function to work correctly. These files include the
following (all are stored in the main BBS directory):
- WELCOME.OFF - Displayed when a user enters the offline reader.
- NEWS.OFF - Displayed in the "News" option for most readers.
- BYE.OFF - Displayed when a user leaves the offline reader.
- BLT-0.? - Bulletin files. First is BLT-0.1, second is
BLT-0.2, etc.
*-*-*-* Warning, PKZip 2.04c is not Compatible with the *-*-*-*
*-*-*-* QWK Sub-system. Use 2.04g or later! *-*-*-*
Some recommended offline readers include Offline Express (OLX), Qmail Deluxe,
KingQWK, Silly Little Mail Reader, and Session Manager.
-----------------------------------------------------------------
Celerity v2.0 Page 89
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Setting Up A Transfer Section
-----------------------------
Transfer area setup involves three stages. The first was configuring your
transfer section options in CELSETUP.EXE to define the operation of the transfer
section as a whole, which was described previously (see "Transfer Options"
above). The second stage is creating a transfer area conference item (see
"Creating Conference Trees" above). The final step is to create the individual
file areas within the transfer section itself.
Creating Transfer File Areas
----------------------------
After creating a transfer section conference item, you will need to enter the
section to actually build the first xfer area. The first time the sysop account
enters the section, you will be presented with the following menu options:
[A] Area Name : Newarea
[B] Storage Path : c:\
[C] Data Pathname : c:\celerity\data\newarea.dir
[D] Access Code :
[E] Options :
[S] Save and Quit
[Q] Quit and abort
Name is the name of the file area you are creating (the first area of the entire
section when you first enter the section and create the first one).
Storage path points to a directory where uploads to this area will be stored.
It is recommended that a separate DOS directory be specified for every transfer
area, but this is not essential.
Data pathname points to the .DIR and .DES files for this xfer area. This should
be unique for every area. If it is not unique (ie: two areas point to the same
data path), the area will be "shared", and accessible in both areas. It is
common for sysops to set up a sysop-only area named "Shared" or "Elevator" in
each transfer section with identical storage and data paths. With this, a sysop
can move files into this area in one transfer section, then move them out in
another transfer section (thus the "elevator" metaphor).
Access code allows you to discriminate against users based on access (ie: you
would not want users under the age of 21 entering an adult area, for example).
See the section on "Celerity Access Conditions" above for full details on
setting up access conditions.
The Options option contains various transfer area options which can
be modified on a base-by-base basis. These include:
-----------------------------------------------------------------
Celerity v2.0 Page 90
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Slow Drive - if data is stored on an optical drive, WORM, CD-ROM, tape drive
(with a DOS driver which allows instant access from DOS, such as TapeDisk), slow
network, or floppy, this option will speed up access. Files will NOT be checked
for their existence when listing files, and they will be copied to a "fast"
drive (see "Directory for Slow Files" in the "Pathnames" setup above) before a
user downloads them.
Allow Uploads - allow uploading to this area.
Allow Downloads- allow downloading from this area.
Ratio Exempt - the area will ignore all ratio restrictions.
Free Area - the area will not charge any file points for downloads.
Scan Area - the area will be scanned for repeats when someone tries to upload.
Scan All Areas- if someone tries to upload to this area, should it scan all the
other areas with the Scan Area option set.
Import FILE_ID.DIZ- if this option is set, Celerity will inspect an upload for a
FILE_ID.DIZ (or FILE_ID.CLR, or DESC.SDI) description and import it if it
exists.
Allow FILE_ID.DIZ Override - when this option is set, the user will be asked if
he or she wishes the FILE_ID.DIZ description to override his or her own.
Quit exits the area setup without saving changes.
Save exits the area and saves all changes to it.
-----------------------------------------------------------------
Celerity v2.0 Page 91
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Setting Up Doors
----------------
Celerity can support a wide array of "doors" such as online games, tape
retrieval systems, another BBS, online product ordering, and much more. Doors
may be entire programs or simple utilities.
The BBS industry has a number of standard formats with which a BBS can transfer
information to a door which requires BBS information. The new standard which
most BBS programs now support is the DOOR.SYS standard. Other standards include
the RBBS/QBBS/Remote Access DORINFO.DEF format, and the WWIV-based CHAIN.TXT.
Celerity supports all three of these formats, and when a door is run, DOOR.SYS,
DORINFO.DEF, and CHAIN.TXT are all created in the node directory. It should be
noted that there are other formats (PCBOARD.SYS, CALLINFO.DAT, etc.) supported
by many doors which are not directly compatible with Celerity. (To use these
doors, use a door conversion program such as DOORWAY (shareware program
available on most BBS') to convert from one of the three supported formats to
the desired format. Nevertheless, over 95% of the BBS-supported doors can use
one of the Celerity supported formats.)
*Note that Celerity does NOT Re-read these files upon returning to celerity at
this time. Therefore, Time banks, Callback verification programs and the like
will not work.
To set up a BBS-supporting door (such as an online game - Global War and
Tradewars are two extremely popular examples), you should first unpack the game
and read all of its enclosed documentation. Look for sections supporting
DOOR.SYS, DORINFO.DEF, and CHAIN.TXT, and follow the instructions for setting up
with that configuration. If the door has configurable options for modem control,
make sure it reflects Celerity's modem settings. If Celerity locks the COM
port at a specific DTE rate (as is the case with high speed modems), make sure
the door will do so as well. Most doors will allow you to run in a local mode,
so you should try running it a few times locally to make sure everything is
working before you hook it up to Celerity.
Once the door is installed and configured, you can add access to it from
Celerity by entering a Door section (D from the main menu or as defined by you
in a conference tree). use the C)reate command to make a new door. A display
will pop up, requesting the name / description of the door, required security
level to access it, the door type, and the file name to execute. If the file to
be executed is a batch file in the Doors Subdirectory, Set the Batch flag to
"YES"
-----------------------------------------------------------------
Celerity v2.0 Page 92
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Door Example
------------
An example batch file, "TRADEWAR", which I use for TradeWars is as follows:
copy \celerity\node1\door.sys \doors\tradewar
cd \doors\tradewar
tw2002 -door
The first line copies my DOOR.SYS to the door directory.
The second line switches to the Tradewar directory
The third line executes the door with the "-door" parameter - meaning "use
DOOR.SYS" to Tradewars.
Try running the door and see if the link works correctly. If it does not, go
over all your filenames and make sure they are entered correctly. Once it is
working locally (note that some doors cannot be run from within the BBS for
local callers, and will exit immediately if they do not find a carrier), have a
user call and try to use it.
Remember, if you like a door and decide to use it, you should support the
Shareware concept by registering it (given that it is a Shareware product, of
course).
Other doors can be created which do not support BBS' directly, although they
should have some kind of modem support if the calling user is expected to see
any displays or enter any input. When running another BBS or remote control
program (Remote Access, Carbon Copy, PC Anywhere, and so on), communications
support is a given. When running some other utility, however, it might not be
so easy. Some programs such as DOORWAY or DOS's CTTY can re-map all screen
output and console input over the modem, which may be necessary. When running
extensive applications or utilities, however, it is recommended that one of the
above remote control programs be used.
There is a freeware utility called REMOTE.EXE which comes with Celerity which
can be used to redirect input and output for many DOS programs. You may run
this utility in your Door batch file to provide users with access to these
non-modem-aware doors.
-----------------------------------------------------------------
Celerity v2.0 Page 93
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Section 3: BBS Operations
=========================
Wait For Calls Screen
When the BBS is waiting for a call, you will get a complete display of various
statistics and the like. At the top left you will see the version number of
Celerity, followed by your board's name, followed by your personal serial
number.
Immediately below this is a glowing "thermometer" bar, which is an indication of
space used on the drive. If it is small, your drive(s) are nearly empty. If it
has grown large, then you may want to clean out some older files. This permits
the sysop to determine how much space is free at a glace, which can be quite
helpful for sysops who don't log onto their board every day, or those with
small hard drives. The box below that holds various system statistics, which are
pretty self-explanatory, so I won't insult your intelligence and describe them.
Every few seconds, the information box will scroll to display additional info.
On the left below the statistics box is a box which shows the last caller to the
BBS.
At the lower right side of the screen is a statistic box showing the status of
timed events (CelerityNet call(Currently inactive), auto backup, and batch
event), the amount of free storage space, the time and date, chat status (This
can be toggled by ALT-A), and modem status.
At the Lower Left is the System Status Box. It contains information on the SIO
Chip in use, the Modem Driver in use (Internal, Fossil, or Digiboard) The
Operating Environment, The Name of the Registered Sysop, and any special
Warnings that the Sysop may not be aware of (Like a DANGEROUSLY small amount of
Free Space)
If you press Alt-H, this box will be replaced with the main command help screen.
If you press it again, the display will change to the multinode status screen
(on multinode systems) showing the current status of nodes 1 through 8.
The commands that can be used from the WFC screen are as follows:
- F2 exits from the BBS.
- F3 will force the modem to send a carrier. It is suggested that you let
people connect by calling in, but if you need to send a carrier, this is how you
can do it.
- F4 performs an "instant login" for the sysop. The sysop is immediately
deposited at the main command prompt without having to enter passwords, read
mail, and other time-consuming options. Each sysop who appears in this list
must have the appropriate sysop flag set (see "Access Conditions" above).
-----------------------------------------------------------------
Celerity v2.0 Page 94
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
- F5 will enter the Online Tools menu. A collection of Sysop- Definable
external utilities which will be discussed in the section on "External
Utilities" below.
- F8 will take the phone off hook so users calling will get a busy signal. This
resets after a few minutes.
- F9 brings you into the Wait For Call options menu. This allows a sysop to
read mail, edit users, view lists of recent calls, recent uploads, and recent
downloads, view the sysop and error logs, and more.
- F10 logs on locally. If you've got the "Auto-login" option set in CONFIG,
then account #1 will automatically log on. If not, you will be thrown into the
shell or main menu, depending on whether or not you have a shell set up.
Not shown on the menu:
- F6 will run a user-defined external program. This program is set up as a
batch file called DEFINE.BAT, although you can change this to anything you want.
Look in the MAIN.BAT file which manages the BBS under the label :userdefine for
the text to change. Put your word processor, virus scanner, or whatever you want
here.
- F7 will run the user-defined terminal program. Similar to F6 above, this must
be set up in the MAIN.BAT file under the label :terminal.
- Alt-F10 will automatically log the sysop in, regardless of the "Auto-login"
option setting.
- Alt-D will drop into DOS. Typing EXIT returns to the WFC. (Note: If you load
a TSR While in the shell, you may lose the "hooks" into the Celerity session.
the only way to recover from this is by rebooting the system!)
Note that if the "Secure Console" option in "System Options" above is set, none
of these keyboard commands (other than F10) will function.
When the BBS is at the wait for calls screen, it will wait for various events
during the day. The following events may be performed:
WFC Status Panel Cycle: Approximately every 10 seconds, the WFC display panel
will cycle.
Multinode Status Refresh: Every 3 seconds, the multinode status updates.
System Status: The system status data is updated every 10 seconds.
Modem Initialize: Every four minutes, the modem will be reinitialized.
End of Day: At the end of the day, a brief history reconciliation will be
performed.
End of Month: At the end of the month, Celerity will update the top ten files.
-----------------------------------------------------------------
Celerity v2.0 Page 95
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Auto-Backup: If you have it defined, the Auto-backup will be performed at the
specified time. See "Timed Events" above.
Batch Event: If you have it defined, the Batch Event will be performed at the
specified time. See "Timed Events" above.
-----------------------------------------------------------------
Celerity v2.0 Page 96
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Online Commands
---------------
There are a number of keys which can be used at the local console when a user is
online. Note that if the "Secure Console" option in "System Options" above is
set, these keyboard commands will not function.
With version 2.02, all of these keys are definable by the system operator
through the use of the SYSTEM.KBD file. Please see the section on "Customizing
Console Commands" below for a full description of how to define these commands
and what their initial definition is with the SYSTEM.KBD which ships with
Celerity BBS.
-----------------------------------------------------------------
Celerity v2.0 Page 97
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Inside the BBS
--------------
Once you log into the BBS, you can navigate throughout it and use commands like
any remote caller would. Using a "?" at nearly any prompt will provide a menu
for that prompt. Detailed explanations of every command in the BBS are not
documented in this file as of this writing, but should be with version 2.10.
Generally, feel free to experiment with commands around the BBS.
At nearly every prompt of the BBS, there are additional "slash" commands which a
sysop or user may use. Each of these special commands begins with a "/"
(slash). They are as follows:
/HELP : Present a list of supported slash commands.
/PAGE : Perform an emergency chat page to the sysop. Requires a password
previously defined (see "System Passwords" above). The emergency chat will be
called whatever the state of the "sysop availability" status (see "Customizing
Console Commands" below, and "Waiting for Call Screen" above).
/CHAT : Request a normal chat. This will be denied if the sysop is not
available (see "Customizing Console Commands" below, and "Waiting for Call
Screen" above).
/CACHE: Displays text cache statistics (see "What is CelerityText" below).
/LANG : Display details of the currently select language file, and flush the
text cache.
/MENU : Display the details of the current menu file and flush the text
cache.
: Display a RIP graphics test screen./RIP
/NAPLPS:Display a NAPLPS graphics test screen.
/SETUP: If the user is a sysop, this command will re-load the Celerity setup
from disk. This is handy if you drop to dos and run CelSetup and want to see
the differences immediately.
/VER : Display Celerity BBS version information.
/OFF : Log off the BBS instantly.
/O : Same as /OFF.
/Mx : Send an inter-node message to node #x.
: List users on other nodes of the BBS./L
/ORIG : Load in the user who originally logged onto the BBS. This is useful for
sysops who enter the user custodian and switch to another user to use the BBS.
Other commands may be added in the future.
-----------------------------------------------------------------
Celerity v2.0 Page 98
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Section 4: Customizing Celerity
-------------------------------
Introduction
------------
One of the specialties of Celerity is its ability to allow SysOps to change the
way it looks and feels. A number of display screens and display features may be
altered or radically changed to suit the SysOp's desires.
Some of the factors affecting a user's display are changed in CelSetup, but will
be outlined here for your convenience.
Color Setup: This section also has an impact on the appearance of your system,
particularly the default user colors. Although users can and do change their
colors, many people get a first impression from the look of the default color
set.
CelerityText files: With version 2.0, Celerity now supports external
CelerityText files used to tailor each and every bit of textual data within the
BBS. Although a few other BBS programs support external language files, none of
them have developed a system so flexible, comprehensive, or efficient as
Celerity has. See the section on "CelerityText" below for full details.
Color Codes
-----------
Celerity BBS allows sysops and users easy access to colors within the BBS. You
need not learn arcane ANSI command sequences like Escape[42m; to define a color,
you can use simple two-character "pipe codes". Pipe codes are always preceded
by a pipe character (|) and consist of a single digit.
Celerity pipe codes may be used in any user-viewable text within the BBS,
including setup-configured text, message titles, tag lines, file descriptions,
and more. Note that if you are viewing this documentation file from within
Celerity, the pipe code examples in this file will be executed and your display
may look strange. The following pipe commands are currently supported:
|1 - User defined color #1
|2 - User defined color #2
|3 - User defined color #3
|4 - User defined color #4
|5 - User defined color #5
|6 - User defined color #6
|7 - User defined color #7
|8 - User defined color #8
|9 - Carriage return
-----------------------------------------------------------------
Celerity v2.0 Page 99
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
|k = Low intensity black
|b - Low intensity blue
|g - Low intensity green
|c - Low intensity cyan
|r - Low intensity red
|m - Low intensity magenta
|y - Low intensity yellow (brown)
|w - Low intensity white
|d - High intensity black (dark gray)
|B - High intensity blue
|G - High intensity green
|C - High intensity cyan
|R - High intensity red
|M - High intensity magenta
|Y - High intensity yellow (yellow)
|W - High intensity white
|S - Swap foreground and background colors (to change background)
|P - Pause (ask user to hit enter)
|D - Display current date
|T - Display current time
|H - Home (clear screen)
|X - Blinking attribute on
|x - Blinking attribute off
|O - Cursor on
|o - Cursor off
For example, |W would set the text color to bright white. |g sets the text to
low-intensity green. |b|S|W would set the color to blue, switch the blue to the
background, and set the foreground color to white, this giving you white on
blue. |1|S|1 would take the user's defined color #1 and reverse it.
Celerity pipe codes are the recommended method of changing colors within
CelerityText files (see "CelerityText" below).
-----------------------------------------------------------------
Celerity v2.0 Page 100
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
The CelerityText Display System
-------------------------------
What is CelerityText?
---------------------
CelerityText is a set of command codes which can be imbedded in normal text to
allow Celerity to perform special operations when displaying files. The
CelerityText system is also used to define nearly all displays in the BBS,
allowing the creative sysop to change the way his or her BBS appears and
operates.
CelerityText files consist of a pair of data files, and are used for BBS text
(as "language files") or BBS menus and prompts (as "menu files"). These are NOT
text-based files, and you should not edit them with a text editor or word
processor.
Implementation of the CelerityText files has freed up a considerable amount of
the conventional memory requirements of Celerity, which can now be used for the
overlay buffer with an overall result of INCREASING the speed of the software,
despite the necessity to load the language data from diskette as needed. The
files are supported by a multi-level intelligent cache to speed up performance.
CelerityText files will allow sysops to customize their BBS' much more than they
could in the past, and enable them to design a system with any motif they like.
CelerityText files include full support of pipe color commands, plus a powerful
and expansive list of command directives (see below) similar to those used by
PC-Board and WildCat! to allow the sysop much more flexibility in design.
The language editor will also allow you to import external files into your
CelerityText files, so you may design bits of text or entire screens with your
favorite text or ANSI editor (yes, ANSI is fully supported in CelerityText
files). Even NAPLPS and RIP graphics are supported, allowing a sysop to design a
completely graphical system around Celerity. Want to build a full-screen ANSI
page to ask a user the name of a post? No problem. Best of all, entries in
Celerity's CelerityText files have NO LIMIT ON SIZE - if you wanted to have a
massive 500k ANSI animation depicting a postman delivering a letter (to tell a
user that an email message has been delivered), Celerity will have no problem
with it. The possibilities are endless. Celerity already has plans for
translation into foreign languages, another important benefit of CelerityText
files, particularly for our systems in Europe and Asia.
Nearly every display in Celerity has a corresponding language entry, many of
them will pass special parameters. The best way to learn how to modify the
language files is to modify a currently existing one.
-----------------------------------------------------------------
Celerity v2.0 Page 101
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Editing CelerityText files
--------------------------
CelerityText files may be edited with the EDITLANG language editor, or other
third-party language file editors which are forthcoming.
Please refer to the Doc file that came with your Editor for details on usage.
If you wish to edit CelerityText language and menu files with any enthusiasm
greater than browsing the file and changing a few entries, please obtain the LDK
(Language Development Kit, such as CEL202LD.ZIP) from a Celerity support BBS for
complete details on what every entry is used for.
Please note that language entries should be edited with consideration for their
context within the BBS. Some entries are very length-dependent, and your
displays may look a bit skewed if the original length is not preserved and/or
you do not update other entries accordingly. Some entries should have carriage
returns on the end, some should not. Some entries require command parameters,
some do not. We recommend that you test your entries as you make them within
your BBS itself. This can easily be done while on-line, dropping to DOS to edit
an entry, exiting back to the BBS, and viewing the text.
Typing Alt-L (default definition - may be changed in the SYSTEM.KBD file) from
the local end will force Celerity to display the entry identification numbers
before each entry, which can be invaluable when debugging language entries.
-----------------------------------------------------------------
Celerity v2.0 Page 102
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Command Directives
------------------
In addition to the Celerity pipe codes which can be used in any user-viewable
text within Celerity, the CelerityText files support a number of special command
directives. Command directives are commands enclosed in a pair of "@"
characters. These will function ONLY for CelerityText files, and not within
posts.
At the request of a couple sysops, I have chosen to follow the general standard
(@ as the command identifier) set by PC-Board, Wildcat!, etc. and have adopted
some of their commands. Note that Celerity supports a much broader array of
command directives than other packages. Note that the color codes follow the
PCB @Xbf@ rather than the WildCat @bf@ convention.
A complete and up-to-date listing of Command Directives can be found in the
Language Development Kit (LDK) documentation, but some of the more common ones
are listed here.
For an easy way to test a new command directive, make a file called "TEST.TXT"
in the main BBS directory. From the main menu, pressing "=" will display this
file, decoding any CelerityText command directives it finds. This can be used
as a quick and effective way of playing with new directives and learning how
they work.
Text Formatting
---------------
Use of the CelerityText files allow a sysop or artist to design the system's
text in whichever way he or she desires, and with this comes the need for format
the text displays, particularly in the case of listings. In addition to regular
ANSI codes for cursor positioning, Celerity provides a few simple yet very
powerful text formatting tools in the command directives which no other BBS can
match.
@CEOL@ will clear everything right of the cursor on the current line.
@CLS@ will clear the screen.
@NAPON@ will put Celerity into NAPLPS graphics mode
and send "graphics on"
@NAPOFF@ will send the NAPLPS "graphics off" command
@POS=xx,yy@ will move the cursor to location xx,yy. Both XX and YY
must be two-digit codes.
@REOL=x@ repeats character x to the end of the line (position 79)
-----------------------------------------------------------------
Celerity v2.0 Page 103
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
@Xbf@ will set the color to hex value bf. 'b' represents background value in
hex, 'f' represents the foreground. A 'b' value greater than 7h will set the
"blink" bit.
@XPOS=xx@ will move the cursor to the x position, keeping current line
@YPOS=yy@ will move the cursor to the y position, retaining the column
Celerity will also let you format blocks of text displayed with the command
parameters. The syntax of this is a colon (:) followed by the justification key
(R, L, or C) followed by a two-digit field size, an optional spacing character,
and finally null entries. This is best explained by example:
@PARAM=1:L20@ will display the Param1 text, left justified in a 20-character
field.
@SYSOP:R50@ will display the sysop's name, right justified in a 50-character
field.
@BBS:C79.@ will display the BBS name, centered in an 80-character field. Note
the dot following the :C80 - this indicates that Celerity should use a '.' for
the spacing, so this command directive would appear as:
- ........................Terrapin Station........................
If no spacing character is given, a space ' ' is assumed.
@NAME:L13. @ In this case, there are trailing spaces following the formatting
code and spacing character. These spaces are ignored, and can be used to help
lay out the fields in your CelerityText files (ie: expand the command directive
@xzxzxx@ to fill as many spaces as it will take when displayed on the BBS).
These formatting tools have been designed to be as flexible as possible, given
the need to keep them simple, efficient, and speedy. Experiment to learn the
nuances of them. Remember that the values must be two digits!
Other Command Directives
------------------------
Below is a partial list of additional command directives. New directives are
added with every version, so always check with the latest Language Development
Kit (LDK) for any changes.
As with the text formatting above, the best way to learn the details of these
entries is to look at examples in current language files, and to experiment with
them.
@@ will display a "@".
@ABORTOFF@ will disable the ability for a user to abort the text
@ABORTON@ will re-enable the keypress abort
@ACCESSLEVEL@ displays the user's access level.
@BBS@ shows the long BBS name
@BBSSHORT@ shows the short BBS name
@BBSACRO@ Shows the BBS' acronym
-----------------------------------------------------------------
Celerity v2.0 Page 104
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
@BBS2@ shows the name of the system 2
@BBS3@ shows the name of the system 3
@BOTTOMLINE@ will move the cursor to the bottom display line of the user's
screen.
@BOTTOMLINE2@ moves the cursor to the line second from the bottom.
@BOTTOMLINE3@ moves the cursor to the line third from the bottom.
@BOTTOMLINE4@ moves the cursor to the line fourth from the bottom,
@BYTESDN@ shows the number of bytes the user has downloaded.
@BYTESLEFT@ will display the user's remaining download Kbytes available
(Note: This displays KBYTES, not BYTES as PCBoard does)
@BYTESUP@ shows the number of bytes the user has uploaded.
@COMMPOINTS@ displays how many points the user has gained from commissions.
@CPSRATE@ indicates the user's average cps download rate.
@CURCONF@ shows the name of the current conference.
@CURAREA@ shows the name of the current message/xfer area.
@DATAPHONE@ shows the user's modem number
@DATE@ will show the current date, like Pipe-D
@DELAY=xx@ will pause for xx tenths of a second (ie: delay=10 will delay
for one second). This must be a two-digit code.
@DISP=xxxx@ Displays a different language file entry
@EXEC=<pathname>@ will execute a batch, .exe, or .com file specified by pathname
as a door.
@FAXPHONE@ shows the user's FAX number
@FILEPOINTS@ shows the user's file point balance.
@FIRST@ will display the user's handle (see @USER@, @NAME@)
@GENR@ displays the user's current general ratio
@HACKS@ shows the number of hack attempts since the user's last call.
@HANGUP@ will hang up on the user.
Integer variables I0 to I9 are supported, with values of -32768 to 32767. @Ix@
Operations on them can include +, -, /, and * operations. They can be referred
to with the @POS=Ix,Ix@, @XPOS=Ix@, and @YPOS=Ix@ commands.
@Ix=n@ Sets integer variable x to value n
@Ix=++@ Increments variable x by 1
@Ix=--@ Decrements variable x by 1
@Ix=Iy+n@ Sets variable x to variable y + n.
@Ix=Iy+Iz@ Sets variable x to variable y + variable z.
@Ix=WHEREX@ Sets variable x to the current cursor X position.
@Ix=WHEREY@ Sets variable x to the current cursor Y position.
@KBYTESDN@ shows how many Kbytes the user has downloaded.
@KBYTESUP@ shows how many Kbytes the user has uploaded.
@KTODAY@ shows how many kbytes the user has downloaded today
@KPERDAY@ shows how many kbytes the user may download daily
@LASTCALLER@ displays the name/handle of the last caller.
@LASTOND@ Displays the date (Thus the trailing D) the user last called
@LASTONT@ displays the time of the user's last call.
@LASTONAD@ Displays the absolute date a user last called. Good for editing
other users. This will display the date the current user called last as well AS
SAVED IN THE USER RECORD, meaning the current date.
-----------------------------------------------------------------
Celerity v2.0 Page 105
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
@LASTONAT@ displays the time of the absolute last call.
@MAILCOUNT@ shows how much new mail is waiting for the user
@MONTHDNS@ shows the number of downloads made this month.
@MONTHKDN@ shows how many kbytes downloaded this month.
@MONTHKUP@ shows how many kbytes uploaded this month.
@MONTHPOSTS@ shows how many posts the user made this month.
@MONTHUPS@ shows the number of uploads made this month.
@NAME@ will display the user's handle (see @USER@, @FIRST@)
@NODE@ shows the node the user is currently on
@NOTE@ displays the user's public note
@NEWMESSAGES@ shows the number of new unread messages since last call
@NEWUPLOADS@ shows how many new uploads there were since last call
@NEWUSERS@ shows the number of new users pending in the new user voting
@NUMCALLS@ Displays the number of times this user has called the system.
@NUMDNS@ shows the total # of downloads the user has made.
@NUMPOSTS@ shows how many posts the user has made.
@NUMUPS@ will display the total # of uploads the user has made.
@PARAM=x@ will display system parameter #x. These are defined on a case-by-case
basis by various functions throughout the BBS. Uncertain results may occur if
you add parameters which have not been declared by the particular function - see
the definition list for parameter definitions.
@P=x@ is the functional equivilent of @PARAM=x@ above, but in shorthand.
@PASSWORD@ shows the user's password (use this with caution - some users call
from public places and don't want people peering over thier shoulder to see
this)
@PAUSE@ will wait for a user's keypress.
@PCR@ shows the user's post/call ratio.
@PHONENUM@ displays the user's voice phone #
@REALNAME@ displays the user's real name
@REQPCR@ shows the user's required PCR
@REQUDR@ shows the user's required UDR
@REQGENR@ shows the user's required general ratio
@SHOWFILE=pppp@ will recursively display a text file, with command directive
support. "pppp" is the full path and filename of the text file to display, and
may be up to 71 characters long. Be careful with these! It is possible for a
file to display itself, resulting in a loop only breakable by hanging up.
@SOFTWARE@ displays the software name (Celerity, CAE, CAE/TAC, Alacrity)
@SPACE=xx@ inserts xx number of spaces
@SYSOP@ will display the sysop name.
@SYSAVAIL@ will display the current "Chat Availability" string from setup
@SYSOPNOTE@ displays the user's sysop note (note: This is intended to be
private, although it can be used however you deem appropriate)
@TIME@ will show the current time, like Pipe-T
@TIMELEFT@ will show how many minutes the user has remaining.
@TIMEONLINE@ will display the number of minutes spent on this call
@TOTALTIME@ shows the total number of minutes the user has ever been on your
BBS.
@UDKRATIO@ shows the user's upload/downloaded kbyte ratio.
-----------------------------------------------------------------
Celerity v2.0 Page 106
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
@UDR@ shows the user's upload/download ratio.
@USER@ will display the user's handle (see @FIRST@, @NAME@)
@USERNOTE@ will display the user's public "note"
@VALPOINTS@ shows how many points the user has gained from file validations.
@VERSION@ displays the Celerity version number.
@XFERLEVEL@ shows the user's transfer access level.
Again, serious users of CelerityText should download the LDK for more details on
how to best use these directives. Please refer to the documentation with the
Language Editor as well.
-----------------------------------------------------------------
Celerity v2.0 Page 107
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Information Scripts
-------------------
Celerity Information Scripts are designed to allow a sysop to create
informational questionnaires for users to fill out to request access to the BBS
or specific sections, or to gather general data about the users. They are
powerful, and therefore can be very complex. You may wish to look at some
example scripts before attempting to create your own.
File Formats
There are three primary files used: *.INF, *.ANW, and *.IDF. The INF contains
both questions and commands for how to process them. The ANW file contains
answers to the questions for filled-out scripts, and the IDF file (InfoScript
Display File) is an optional file used to display the answer data when the
script answers are viewed. INF and ANW files are straight text, where an IDF
file may contain ANSI. All three file types reside in the DISPLAY directory.
Celerity BBS supports up to five main scripts, as defined in the "Information
Scripts" setup above. The data files should reside in your DISPLAY directory,
and be named INFOx.IDF, INFOx.ANW, and INFOx.INF, where x is a number from 1 to
5. The .ANW file will be automatically created when the script is filled out,
so you need not be concerned about creating this file.
The Infoscript Display File
---------------------------
The display file (INFOx.IDF) will display anything you want except a backward
quote (`). When this character is first encountered, Celerity will grab the
first line of data from the associated .ANW file and display it on the screen,
similar to how the asterisk (*) functioned in the 1.42 infoforms, and so on
until all of the display file has been shown. Thus, you can create pretty ANSI
files and simply place a ` character wherever you want infoscript answer data to
be displayed. Note that if the display file contains MORE ` characters than
there are data entries, it will NOT wrap to the next user, but will simply start
displaying the ` characters. Because Celerity will display the whole line from
the answer file, you should probably set up your script to write the data to the
answer file without a label.
eg: `IN=2<>`
Otherwise, you may get fields in your answer file with "Answer:32" in them.
Please examine some of the examples on the Celerity support board for ideas on
making information script display files.
-----------------------------------------------------------------
Celerity v2.0 Page 108
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
The Infoscript Answer File
--------------------------
The infoscript answer file (INFOx.ANW) contains all of the answers for all users
who have filled out the script. It is in standard ASCII text format, so feel
free to browse it with a text editor if you like. The entry for each user will
look like the following:
<*USERNAME=Extreme A.I.*>
Your Name : Blah
Your Voice # : Blah
<*EOF*>
The <*USERNAME=*> entry specifies the beginning of a script record, and the
<*EOF*> entry specifies the end.
Infoscript Command File
-----------------------
The infoscript command files (INFOx.INF) contain the commands to be executed and
questions to ask of the users. There are four types of commands which can be
used: Input commands, file handling commands, if..then loop commands, and
general purpose commands.
What is a Command: A Command is an instruction or set of instructions that
tell the script processor how to behave. They govern inputing, outputing,
displaying textfiles, beeping at the user, etc.
How to Use a Command: To tell the script processor that a group of characters
is a command, it must be placed within backquotes ("`") on most keyboards this
character is to the left of your "1" key. Simply begin the command with a ` and
end it with a `. There can be NO spaces within commands EXCEPT within text
strings. (Such as answer labels, or strings to write to the answer file.)
When Should I Use a Command: Whenever you wish to get input from the user,
process this input, or do any of the other functions a command can do. Remember
that there are commands to make your script respond to the answers of users in
different ways so you may make your scripts seem intelligent.
-----------------------------------------------------------------
Celerity v2.0 Page 109
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Input Commands
--------------
How to Use Input Commands: Simply place the input command wherever you wish
to have the user answer a question. There are several formatters that will
increase the power of the commands. To use these simple place them next to the
input command within the required backquotes (for ease of reading they have been
excluded from the command list. REMEMBER to add these!) Remember that there
can be no spaces. These formatters are listed following the commands.
The Input Commands:
IA ; Input Any - Any character that can be sent over the modem will work.
IAC ; Input Any Caps - same as above, but all text will be capitalized.
IAP ; Input Any Proper - Same As above but the first letter of every word will
be caped, the rest lowercase.
IT ; Input Text - Only letters will accepted.
INT ; Input Numeric/Text - Numbers or letters ONLY.
IN ; Input Numerical - only numbers will be accepted.
IYN ; Input Yes/No. Gives a nifty celerity yn prompt. YES default.
IYNN ; Input Yes/No, default to NO.
Input Formatters: Remember that to use these just tack them on to the end of
your input command.
Length Limiter: By appending an "=XX" after a command, where XX equals the
maximum length of the input, you can restrict the length of the input. Once the
maximum length is reached, only a Return, or a backspace will be excepted.
Example: To Limit an age query to 2 digits change `IN` to `IN=2`.
Answer File Labels: If you do not use an answer label the answers from user
input written to the answer file will be listed as "ANSWER : Input". By using an
answer label you can tell the script processor to instead write the text you
specify before the answer. To do this Simply add set of <>'s to your command,
and specify what you want written between them (Spaces are acceptable.).
Example: To further expand on the age input command above we can change the
command to `IN=2<Users Age>`. Now when the answer is placed in the answer file,
it will appear as
Users Age : 22
instead of
ANSWER : 22.
Preventing an Answer From Being Written: Why would we want to do this? Well
for instance if you placed a question at the beginning of the script asking the
user if he wants to answer this script or not. Another use would be in making
-----------------------------------------------------------------
Celerity v2.0 Page 110
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
scripts that aren't questionnaires, but instead menus and help files. You don't
want to have an answer file for this do you? To supress the answer, simply
append a "!" as the LAST character of your command.
-----------------------------------------------------------------
Celerity v2.0 Page 111
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
File Handling Commands
----------------------
How To Use File Handling Commands: To use these insert them in your script
file just like any other command. Certain commands MUST be paired though to they
will not work. For example a Goto or Gosub MUST have a label to goto!
The File Handling Commands:
FQUIT ; This tells the script processor the session is over. This isn't
required if the script ends at the end of the file, but if you wish to end it
before then, use this.
FWA="XX" ; Write the comment XX to the answer file. Spaces are allowed.
LABEL<XXX> ; One of the most important commands. This works in conjunction with
the GO commands. Using these you can have the script processor jump around the
script answering questions depending on the answers of other questions. MAKE
SURE that the string in the <>'s CONTAIN NO SPACES! And make sure it matches the
string used in the GO command!
GOTO=xxxx ; This causes the script processor to stop what its doing, go to the
label xxxx (defined as above) and start processing again. You cannot return to
where you left the main stream with a goto.
GOSUB=xxx ; This causes the script processor the save the current position of
the script on the stack and jump to a label defined as xxx. When you are done
you simply call the return command and it continues as if nothing ever happened.
The stack will hold up to 20 GOSUB commands.
RETURN ; This causes the Script processor to return to the position
immediately following the LAST gosub command it encountered. Each consecutive
RETURN jumps back one more gosub. (Be careful not to have more returns than you
have GOSUBS'!)
-----------------------------------------------------------------
Celerity v2.0 Page 112
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
"If...Then" Answer Handling Commands
------------------------------------
What is the Purpose of the Answer Handling Commands: The purpose of these
commands is to allow you to do various things in RESPONSE to the answers given
by the user. Perhaps display a text file, perhaps activate a gosub to another
group of questions. Its all up to you.
How to Use the Answer Handling Commands: These are used like the other commands
with one exception. They hold one (or more) other commands with the same set of
backquotes. The first command is the answer handler. If the users last answer
equals the value specified then it will process the second command, which may be
another answer handler (for example : if more than 15 then if less than 20) or
or another command (gosub, input, etc). Remember that the first backquote must
be before the answer handler and the last one must follow the final command
(which cannot be an answer handler.
The Answer Handling Commands:
IFY->xxx ; If last answer was "yes" then do xxx
IFN->xxx ; if last answer as "no" then do xxx
IFGT(xx)-> ; if last answer was numerical and greater than xx then do command
IFLT(xx)-> ; If last answer was numerical and less than xx then do command
IFNS(xx)-> ; Compare the string xx to the last answer. Not Case Sensitive.(i.e.
"hi" is the same this as "hI")
IFCS(xx)-> ; Compare the string xx to the last answer, but this time is IS case
sensitive. hi IS NOT the same thing as hI!!
Example: Lets continue our Age example. We wanted to ask the user for his
age, and if he's 21 or older ask him if he wishes access to our adult areas. So
now lets write out our question so far.
What is your age? `IN=2!`
Now using all the commands we have covered so far, we can expand our example to
compare the users age to our restriction of 21 and older, and if so go ask him
if he wants access.
What is your age? `IN=2!` `IFGT(20)->GOSUB=ISADULT`
Thank you for answering this script.
`FQUIT`
`LABEL<ISADULT>`Do you want access to our adult areas of the bbs?
`IYN<User Wants Adult Access>`
`RETURN`
-----------------------------------------------------------------
Celerity v2.0 Page 113
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
What it will do now is if the users age (answers in IN=2!) is over 20 (our
requirement of 21 and up) then Gosub to the label IsAdult. If not we print a
little string saying thanks and quit this script file. If he is, we go to the
label ISADULT. Here we ask him if he wants access, and write his answer using
the answer label "User Wants Adult Access". Once he's answered, we return to
were we left off, which will display the little thank you note, and then quit
this script.
-----------------------------------------------------------------
Celerity v2.0 Page 114
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
General Purpose Commands
------------------------
What are General Purpose Commands Used For:
These are used for various things such as beeping the user or sysop, or pausing
the display
The General Purpose Commands:
CR ; Prompt for a return before continuing.
DISPLAY=XX ; display the textfile xx. All celerity @ and |
commands can be used in this file for formatting.
BEEP ; beep on the users side.
SYSBEEP ; beep on the sysops side..
DOWNLOAD<filename> ; sends the file filename to user.
UPLOAD<filename> ; the user uploads filename.
EXECUTE<filename+params> ; Full path and filename to a EXE, Com or BAT to
execute. EVERYTHING included within the <>'s is used so include parameters
there.
POS=XX,YY ; Position the cursor at XX,YY
XPOS=XX ; Position the cursor at XX
YPOS=YY ; Position the cursor at YY
CLS ; Clear the screen
Example: We will now finish up our example. We will cause the system to beep
at the user, display our rules about adult materials and wait for a return
before asking the user if he wants he wants access to our adult sections.
What is your age? `IN=2!`
`IFGT(20)->GOSUB=ISADULT`
Thank you for answering this script.
`FQUIT`
`LABEL<ISADULT>` `BEEP` `BEEP` `BEEP`
`DISPLAY=C:\BBS\ADLTRULE.TXT` `CR`
Do you want access to our adult areas of the bbs?
`IYN<User Wants Access>`
`RETURN`
The three beep commands cause three ^G's to be sent to the user, then
C:\BBS\ADLTRULE.TXT will be shown to him and then it will wait for a return
before continuing.
-----------------------------------------------------------------
Celerity v2.0 Page 115
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Example Infoscript
------------------
ABOUT OUR EXAMPLE INFOSCRIPT:
This script asks the user for some general information, if he is a sysop,
prompts for his bbs name, and if 21 or over, asks him for access to the adult
sections of the bbs.
THE EXAMPLE INFOSCRIPT:
-------------------------------------------------------------------
Welcome to our BBS newuser! We will need to find out some information about you
for determination of your access level. You are free to abstain from answering
any of the following questions, but remember we can only grant access upon what
we know of you. (We can't give you access to the adult sections if we don't know
if your 21 or not!)
What is your age? `IN=2<Users Age>`
`IFGT(20)->GOSUB=ISADULT`
Are You A BBS Sysop?
`IYN<Is A SysOp>`
`IFY->GOSUB=ISSYSOP`
What is your Reason for calling This BBS? (5 Lines)
`FWA="Reason for Calling This BBS Is"`
#1> `IA<#1>`
#2> `IA<#2>`
#3> `IA<#3>`
#4> `IA<#4>`
#5> `IA<#5>`
Thank you for filling out this questionnaire.
`FQUIT`
`LABEL<ISSYSOP>`
Do you want us to know your BBS information? `IYN!`
`IFN->RETURN`
What is your BBS Name? `IA<BBS Name>`
What is your BBS Number `IA=<BBS Phone Number>`
`RETURN`
`LABEL<ISADULT>` `BEEP` `BEEP` `BEEP` `DISPLAY=C:\BBS\ADLTRULE.TXT`
`CR` Do you want access to our adult areas of the bbs? `IYN<User
Wants 21+ Access>`
`RETURN`
-------------------------------------------------------------------
-----------------------------------------------------------------
Celerity v2.0 Page 116
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Additional example information scripts can be downloaded from the Celerity
Support BBS at 310-693-9405. Many of these include full support for .IDF
display files as well.
-----------------------------------------------------------------
Celerity v2.0 Page 117
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Customizing Text Files
----------------------
Celerity includes opportunities for the SysOp to individualize his system by
writing his own messages, creating his own status screens, etc., that will be
displayed to users at various points in the program. These can be created with
an ANSI editor like TheDraw to use color and ANSI graphics, or done with a
standard text editor with support for CelerityText pipe codes and command
directives. See Appendix C for a complete list of the files used by Celerity,
and what each one is used for.
-----------------------------------------------------------------
Celerity v2.0 Page 118
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Customizing Console Commands
----------------------------
How to Customize the Keyboard
-----------------------------
One of the new features which came with Celerity v2.02 was the ability to define
console keyboard commands externally, through the editing of a file called
SYSTEM.KBD which resides in the main BBS directory.
It is recommended that you use the SYSTEM.KBD which ships with Celerity BBS, and
modify it to your liking rather than build a new one from scratch. The default
file contains some brief details on modifying the file.
A console key can be defined for any key which is NOT normally transmitted over
the modem without special terminal support. This includes all Alt keys,
function keys, cursor control keys, and control or shift combinations for
function keys. Valid keys follow:
F1,F2..F12: Function keys F1 through F12 (F11,F12 may not function)
A..Z = Letters A to Z (Alt only)
Equ = = (equals) (Alt only)
Min = - (Minus) (Alt only)
0..9 = Numbers 0 to 9 (Alt only)
Ins = Insert (Ins only)
Del = Delete (Del only)
Home = Home (Home, ^Home only)
End = End (End, ^End only)
PgUp = Page Up (PgUp, ^PgUp only)
PgDn = Page Down (PgDn, ^PgDn only)
Pscr = Print Screen (^Pscr only)
<- = Right Arrow (<-, ^<- only)
-> = Left Arrow (->, ^-> only)
Up = Up Arrow (Up only)
Dn = Down Arrow (Dn only)
Brk = Break (^Brk only)
In the SYSTEM.KBD, you can define four types of commands:
1: Command keys. These correspond to one of the 40+ console commands which are
internally supported by Celerity. A detailed list follows.
2: Execution keys. These will allow you to execute a DOS shell or DOS program.
3: Macro keys. You can create macros to sign your name, navigate through menus,
delete a file, and more.
4: Translation key. You may use the translation key to assign a standard
keypress to a special 8-bit ASCII character which may not be easily typable.
-----------------------------------------------------------------
Celerity v2.0 Page 119
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Full details on defining keys for the SYSTEM.KBD file are included in
the SYSTEM.KBD file itself.
Internally Supported Commands
-----------------------------
There are over 40 internally supported commands which you can define via the
SYSTEM.KBD file (see above). Few systems will have the need to define them all.
Included is the default key (if any) used in the standard SYSTEM.KBD file.
Please note that if the "Secure Console" toggle is selected (see "System
Options" above), these local commands will not function.
#1 : Enter split screen chat. This chat mode places two boxes on the screen,
one for the local user and one for the remote user. Users can type
simultaneously, with thier keypresses appearing in thier respective boxes. The
main drawbacks of the split screen chat is that it can be slow for low-speed
users, and it does not function with most scrollback functions in terminal
programs. In the standard setup, F1 will enter split screen chat.
#2 : This enters the Alacrity smart chat. It is undocumented.
#3 : Enter line chat. The line chat is a much more conventional chat mode,
where local and remote user take turns typing to one another. The line chat
works well with scrollback. Local keypresses and remote keypresses will appear
in different colors. Alt-F1 will enter line chat in a standard setup.
#4 : Beep at the remote user for attention.
#5 : Toggle sysop chat availability status. Normally Alt-A.
#6 : Restrict all input from modem (user can't type anything). Alt-I.
#7 : Restrict all output to modem (user can't see anything). Alt-O.
#8 : Echo output to printer, if it is connected. ^Pscr normally.
#9 : Echo all output to text file (node#.cap in shared dir). Alt-E.
#10: Turn snoop buffer on (secondary text capture). Alt-F.
#11: Lock user's time at current value for this call. F8.
#12: Set user's time to 0. Alt-F8 or Alt-K in the standard setup.
#13: Add 1 minute of user time. F10 in the standard setup.
#14: Subtract 1 minute of user time, usually F9.
-----------------------------------------------------------------
Celerity v2.0 Page 120
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
#15: Add 10 minutes of user time. Alt-F10 normally.
#16: Subtract 10 minutes of user time. Alt-F9.
#17: Cycle bottom status bar. Alt-B in standard setup.
#18: Show users statistics / Background editor.
#19: Give user 1 xfer point. Good if you use file points.
#20: Subtract 1 xfer point from the online user.
#21: Give 10 xfer points.
#22: Subtract 10 xfer points.
#23: Raise access level by 1
#24: Subtract access level by one
#25: Raise access level by 10
#26: Lower access level by 10
#27: Raise xfer access level (unused) by 1
#28: Lower xfer access level (unused) by 1
#29: Raise xfer access level by 10
#30: Lower xfer access level by 10
#31: Toggle display of Fido kludge lines in messages. Useful if you are setting
up a fido network, but usually not needed. Alt-J.
#32: Toggle display of language entry #'s. Very handy if you are working on
your language file. Alt-L.
#33: Toggle Geek Speak feature. This option is used for comic relief. If
you've been up for hours & an annoying user is in a message section, hit this &
watch the fun. Alt-G normally turns the Geek Speak on and off.
#34: Kick the user off the system (hang up on them - does not delete the user
permanently). Usually F3.
#35: Enter the online tools, See the section on "Online Tools" below. Def. F5.
-----------------------------------------------------------------
Celerity v2.0 Page 121
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
#36: Grant temporary sysop access. This is useful when a user is online and you
want to quickly make a change to a conference setup or file section or add a
file to a transfer section for the user to download, but don't want to wait for
the user to log off. His or her normal access will be restored when he or she
logs off or begins a transfer. This is normally achieved with the Alt-S key.
#37: Reserve system for sysop. When you hit this, the system will not reset
when the user logs off, but will halt operation and exit to DOS. Using this
command, a patient sysop can reserve the system without kicking a user off.
Celerity will make some noise when the system is free. Normally Alt-R.
#38: This option will display one, two, or three help screens which show the
definitions of all defined local console commands. If a remote user is using
the board, he or she can continue BBS usage while the help screen is being
viewed, but if a door is run, a transfer started, or the user logs off, the
screen will reset. It is normally Alt-H.
#39: Drop to DOS. This command can be used at almost any time to give you a DOS
prompt. A user can NOT continue to use the system while you are in DOS. Alt-D
is the standard command key.
#40: Break out from Celerity and exit to DOS. There is rarely a need to do
this, but if you wish to exit the BBS without the user logging off, you may
select this option. In the default SYSTEM.KBD, ^Brk is used.
#41: Toggle screen output on/off. This is handy if you are running the BBS in a
multitasking environment and wish to improve performance. Users may notice some
minor display glitches when the screen output is off.
#42: Scroll backwards in the local screen scrollback. Normally Up.
#43: Scroll forwards in the local screen scrollback. Normally Dn.
#44: Exit or enter the scrollback. Normally -> and <-.
New commands may be added in future versions of Celerity. You may define
multiple command keys for a single function (ie: -> and <- for the Scrollback
enter/exit).
-----------------------------------------------------------------
Celerity v2.0 Page 122
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Online Tools
------------
Celerity allows a sysop to define a menu of online tools which can be accessed
at the press of a (local) keypress (refer to SYSTEM.KBD key #35 above). This
menu is completely sysop definable through modification of the EXTERN.KBD file
which resides in the main BBS directory.
The EXTERN.KBD (or EXTERN.DAT in some versions) is defined in the following
manner:
Menu Title,Command Line,Parameters
The menu title is what appears on the Online Tools menu. At your discretion, it
may contain a tilde (~) character preceding a letter you wish to define as a hot
key for that item. If no tilde is defined, there will be no hot key defined for
that item.
The command line should specify the path/name of the program to run when
selected. If the commandline is followed by an asterisk (*), Celerity will
change to the directory specified by Commandline before executing. Otherwise, it
will be executed from the BBS Node Directory. Some programs require that the
current directory be selected before running.
The parameters entry may be excluded if there are no command-line parameters,
or you may enter a '?' to have Celerity ask for the parameters when it is run.
There are also some special characters which can tell Celerity to pass certain
bits of data:
A parameter of '%S' will pass the path and filename of the setup.dat
A parameter of '%N' will pass the current BBS node #
A parameter of '%U' will pass the current user's UserID
Lines beginning with a semicolon are ignored, as are blank lines.
Some examples, as can be found in the EXTERN.KBD file which ships with Celerity,
are as follows:
; This calls Sicko's Edituser user editor, passing the user's ID.
Edit User Online,c:\celerity\util\uedit\edituser.exe,%S %U
; This shells to DOS.
~DOS Shell,c:\command.com
; This also loads Sicko's Edituser editor, but for general editing.
Edit ~Users,c:\celerity\util\uedit\edituser.exe,%S
-----------------------------------------------------------------
Celerity v2.0 Page 123
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
; Loads your favorite text editor
~Qedit,c:\com\q.exe,?
; The following will load up Sicko's CMT file management tools
File Management ~Tools,c:\celerity\util\cmt\cmt.exe,c:\celerity\util\cmt
; This line will run DOS' edit program
DOS ~Edit,c:\dos\edit.com
; This will execute PKZIP.EXE, and ask for parameters.
PkZip,c:\com\pkzip.exe,?
; Use this to unzip a file, and ask for parameters
PkUnzip,c:\com\pkunzip.exe,?
; Load the CelerityText editor
CelText Editor,c:\celerity\util\ledit\editlang.exe,c:\celerity\util\ledit
; Run Celerity's system editor
Celerity ~Setup,celsetup.exe
EXTERN.KBD will support up to 29 external utilities. Please note that the
default EXTERN.KBD may need some modification of pathnames to fully work with
your system, depending on where you have the various utilities installed.
-----------------------------------------------------------------
Celerity v2.0 Page 124
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Section 5: Strategies for Running a Good Board
==============================================
Introduction
------------
Running a BBS is not an easy job, no matter how self-sufficient and capable the
BBS software is. Running a high quality board which commands respect is
downright difficult. Here are a couple of suggestions to help you run a quality
system.
Policies
--------
Sit down and determine the policies your board will have. If you have concrete
policies that the users can be aware of, they will be much more cooperative and
your system will appear to be much more stable and well run. Some policies
which you should consider:
Local callers
-------------
Local callers have often been called the bane of a quality BBS because of the
assumption that "good users will call long distance for good boards. Local
callers will take whatever they can find". In many cases, this has been proven
to be true. In general, users who call long distance are of a higher quality
than those who only call local systems. However, there may be high quality local
users you will miss out on if you flat out refuse all locals.
Different policies you may take would be:
a. Acceptance of all users, local or not.
b. Acceptance of local users providing they call out-of-state boards
c. Acceptance of only a few local users. Use of the LUL (Local User Lockout)
feature of Celerity will allow you to set a percentage of local users who are
allowed on the system.
d. Flat out refusal of all locals.
e. Acceptance of local users if they have a password found only on out-of-state
systems.
Decide what your policy is going to be, and stick to it. Do not change it every
day, and let your users know when you are changing it.
-----------------------------------------------------------------
Celerity v2.0 Page 125
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Slow Callers
------------
Nobody can argue that 300 bps users should be permitted to have full access to
any bulletin board system, but in recent years, with the advent of high speed
modems, these restrictions have been extended to 1200, 2400, and even 9600bps
users as well. In general, a slow user can contribute just as much to sub-board
activity as a high speed user can, but will not be able to transfer nearly as
much data in the transfer sections without taking up much larger amounts of
time.
High Speed/9600+ Only systems: In late 1989, I put up a bulletin board and
restricted it to 9600/14400bps connections only, and ran the first BBS in the
United States with this restriction as far as I know. Many users said I was
crazy to exclude the slower users, but the BBS became quite popular with plenty
of high speed users. Today, with v.32bis modems available at rock-bottom prices,
and 28.8k modems becoming widespread, more and more systems are adopting this
policy with considerable success.
Some policies you might consider would include:
a. Accepting all 1200/2400 users.
b. Accepting only the highest quality slow users.
c. Accepting slow users for only a certain period of time, such as when the
board first opens.
d. Accepting only out-of-state slow users.
e. Accepting only a small percentage of slow users.
f. Accepting slow users if they give a donation.
g. Accepting slow users, but deny transfer privileges.
h. Turning down all slow users, regardless of qualifications.
Selecting your low speed policy can be difficult. If it is too restrictive if
can hinder early development of the system. If it is too liberal, it can make
your system far too busy to get the attention of high speed users and reduce the
amount of new programs uploaded.
-----------------------------------------------------------------
Celerity v2.0 Page 126
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Access requirements
-------------------
Many boards will accept anyone who calls. Others are more selective as to whom
they validate. This policy can be a key factor in determining the quality of
your system. Some factors many systems consider when deciding to accept or deny
a user include the following:
a. Speed and location factors, as determined by the above policies.
b. How soon does the user get new programs. You may make a distinction between
games and utilities/applications users.
c. Is the user willing to donate funds/hardware for the upkeep and the
improvement of the BBS?
d. Will the user bring a certain amount of respect to the system (ie: is the
user a major figure in the BBS community? A shareware author who will upload
new releases?)
e. Is the user on other quality systems around the nation?
f. Does the user have good references?
g. Is the user mature, or will he/she engage in unwanted flame wars?
One highly effective way of keeping poor users off your system is to get a group
of highly selective individuals as your new user voting panel (ie: users with a
high enough level to vote), and have them determine whether or not to accept a
user. When you have a number of users voting, the chances of some of them
knowing a user you may not know are improved greatly.
Rules of Conduct
----------------
Rules of conduct are usually very important in determining the quality of a BBS.
Do you want to allow "rag wars" on your system? They will appeal to a younger
audience, but will turn off your more mature users. Do you care if users post on
the wrong subs? How old can a program be and still be a wanted upload? Do you
have certain restrictions for upload content?
There are a number of small aspects you will want to define and usually post so
users are aware of them. If you enforce them, your good users will abide by
them and help enforce them themselves.
Voice Validation
----------------
If you are going to voice validate users, you should let them know that you may
do so. Many SysOps will ask, in an information script, whether a user will
accept a collect phone call, and the best time to call. Voice-validating is a
-----------------------------------------------------------------
Celerity v2.0 Page 127
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
good way to know that you have SOME accurate information about a user, and
he/she can be contacted if necessary.
Access Levels
-------------
Be consistent with your access granting. Grant new users a certain level, and
upgrade their access when they prove to be good users. Be very careful when
making a coSysOp, and be sure you know that user well. Many boards have gone
down because of sabotage done by a coSysOp, and many MANY boards have had their
security compromised when a coSysOp downloaded the userlist and passwords.
Do not give ridiculous access levels. Celerity supports access levels of -5 to
100. A negative access level will delete the user the next time they call.
-1 Deletes the user.
-2 Gives the user the system 2 password and deletes him.
-3 Gives the user the system 3 password and deletes him.
-4 Tells the user he was deleted under "special circumstances"
-5 Tells the user what the results of the new user voting on him were, and
deletes the user.
Level 100 is the SysOp level. Do not make levels over 100.
Advertising
-----------
Advertising is a sticky subject. A couple points to remember are:
1: Advertise to your proposed audience. If you don't want any locals, don't
post ads on local boards, and advertise only on out of state systems. The
locals who may be quality users will eventually find out by calling those other
systems. If you don't want slow users, don't post on boards which cater to
them. Posting only on "High Speed Only" boards is quite feasible in this day
and age. Post only on boards which have users of the quality you would like.
2: Do not over-advertise. Nobody will call a board which makes them sick with
too many ads. Don't always use the same ad either, but vary the ads and use new
ones from time to time. Users will abort any ad they recognize.
3: Never, NEVER, send mass-mail advertising your system. Doing so will most
likely piss off the SysOp of the board you are on, and in addition, no decent
user will call a board he has gotten a mass mail invitation to. If there are a
few users you would like, you can try sending them each a piece of individual
mail, but mass mail is sure trouble.
-----------------------------------------------------------------
Celerity v2.0 Page 128
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
4: Make a nice looking ANSI ad. There are a few ANSI specialist groups, such as
ACiD and A.A.A. who will design ads for people (like myself) who have absolutely
no ANSI talent. Some bulletin boards require that ANSI screens be saved in a
79-column mode rather than "unlimited length".
5: Archive commenting. Archive COMMENTING is generally acceptible advertising,
and most boards do it. ADDING an ad file to an archive, on the other hand, is
generally considered to be very boorish and immature. Nobody will call a board
who litters thier transfers with stupid ads imbedded in the archives.
-----------------------------------------------------------------
Celerity v2.0 Page 129
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Appendices
==========
Appendix A, Serial I/O Chips
----------------------------
A very good reference book that I use is available from National Semiconductor
Corporation. It covers most of the SIO devices (also called UARTs) that you
will find in all PCs and clones. The title of the book is Microcommunications
Elements Databook. The publication number (manual number) is 400066. I am not
sure that the book can be ordered directly from National semi-conductor. They
may require that you get it from a distributor. In any case, the address on the
back of the manual is:
National Semiconductor Corporation
2900 Semiconductor Drive
P.O. Box 58090
Santa Clara, CA 95052-8090
Tel:(408)721-5000
TWX:(910)339-9240
8250
As best that I know, the 8250 was the first SIO chip (integrated circuit) that
was used by the IBM PC and many clones. In my opinion, it was a poor choice on
the part of IBM. I feel many superior devices, at comparable prices, were
readily available. At that time, I feel the 8251A or the 8530 would have been
better choices. I feel IBM used the 8250 to insure the PC would not have
synchronous communications capability in a standard configuration.
From a hardware standpoint the 8250 is a relatively slow device. It is advisable
that programmers not perform successive inputs or outputs to this device. It
seems that software programs can load the various registers of the 8250 faster
than it can process the information. The 8250 had a total of 7 registers. The
specifications state that 56kb is the maximum baud rate.
8250A
I believe the 8250A is the 8250 with some bug fixes. I have no idea what the
bugs may have been. A quick glance at the specifications shows the speed of the
8250 and 8250A to be much the same. The 8250A added an 8th register. This
additional register enables software to detect if an 8250 is installed. The
specifications state that 56kb is the maximum baud rate.
16450
-----------------------------------------------------------------
Celerity v2.0 Page 130
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
The 16450 seems to be a sped up version of the 8250A. There is no direct way
(that I know of) for software to detect the difference between an 8250A and a
16450. I believe the 16450 was developed to eliminate the need for software to
insert delays between successive accesses to the device. The specifications
indicate the 16450 is a much faster device than its predecessors. The additional
speed is only the speed at which the processor can access the device. The
maximum baud rate for the 16450 is still stated at 56kb. However, I have been
told by some people that they have run the 16450 successfully at much higher
speeds. I do not believe there was ever a 16450A.
16C451
The 16C451 is a CMOS version of the 16450. CMOS is a term for the material and
manufacturing process used to make the part. CMOS typically uses less power than
other technologies. If you are not designing hardware, you should view the
16C451 as a 16450.
16550 Non A
It is hard to find a 16550 (Non A). I was told by National Semiconductor that
they did everything they could to get all 16550s back. X00 (and XU) will detect
a 16550 and tell you if you have one. I am told that the 16550 was installed in
early PS/2 systems.
The 16550 was the first shot at a FIFOed version of the 8250 family from
National semiconductor. However, I was told by National Semiconductor that the
FIFOs of the 16550 are not reliable and they should not be enabled. X00 will
treat a 16550 like a 16450. In this mode, they are reliable. National
Semiconductor would not provide me with a specification for the 16550. However,
I suspect its maximum baud rate is the same as the 16550A which is 256kb.
16550A, 16550AF and 16550AFN
In the manuals that I have, National Semiconductor does not explain the
differences between the 16550A and the 16550AF. I suspect the AF part may have a
few bug fixes. I believe the N in AFN describes packaging, ceramic versus
plastic, DIP versus surface mount etc.
In the opinion of the author, there is no substitute for the 16550A (and its
successors) in the 8250 type series. The 16550A is compatible with software
written for the entire family of 8250 type devices. Programs that are 16550A
aware can provide much improved performance over previous devices.
The maximum baud rate for the 16550A is specified at 256kb. However, due to the
hardware design of the PC et al, 115kb is the maximum baud rate that can be
programmed.
The 16550A can be plugged into the same socket that contains an
-----------------------------------------------------------------
Celerity v2.0 Page 131
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
8250, 8250A or 16450. If your SIO expansion board has the SIO chips in sockets,
you can upgrade to the 16550A by simply removing the old chips and replacing
them with 16550As.
The key to the performance increase of the 16550A is its FIFO buffers (first-in
first-out). It has 16 byte FIFOs for both transmit and receive data.
16550s Made by Western Digital
I have been told, but I have not verified for myself, that 16550s made by
Western Digital have a problem with their FIFOs when working at 2400 baud or
below.
16C551
The 16C551 is a CMOS version of the 16550AF. See the above description of the
16C451 for a discussion of CMOS. Do not feel you need to upgrade from a 16550A
or AF to a 16C551. There is no gain from an existing users point of view.
16C552
The 16C552 is two 16C551s on a single chip. These devices will start showing up
on multi-port serial I/O cards.
16C552CJ
Another variant of the 16C552.
82510
I believe Intel is the only company that manufactures the 82510. The 82510 is
feature rich with several modes of operation. Its default mode is to operate as
a 16450. The 82510 has a 4 byte FIFO for both transmit and receive data. A 4
byte FIFO is sufficient to provide significant performance over a basic 16450.
The 82510 is small in size. Therefore, it is found in many lap tops.
The 82510 is somewhat of a sleeper. I believe it would be much more widely used
if Intel had promoted it more. However, given a choice between the 82510 and the
16550A, I would select the 16550A.
-----------------------------------------------------------------
Celerity v2.0 Page 132
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Appendix B: An Introductory Lesson in High-Speed Modems
A Modem Story
-------------
Jim, an avid bulletin board caller, wanted to upgrade from his 2400 baud modem
to a high-speed modem. He went to his computer dealer and asked for the best
9600 baud modem, and purchased a Hayes V-series Ultra Smartmodem 96, which is
indeed one of the best on the market. Jim felt that getting the best justified
spending $800 on the modem. However, when Jim got his new modem home and set it
up, he found that all of his connections were still at 2400 baud. Many of the
sysops who ran the bulletin boards Jim called were as confused as he, but one of
them targeted the problem. While Jim's modem was an excellent V.32 modem, the
bulletin boards were using HST modems. Jim wasn't quite sure what this meant,
but returned to his computer dealer and explained the problem. His vendor made
him a fair compromise offer: for returning the Hayes and $100, he sold Jim a
U.S. Robotics Dual Standard, which, although more expensive than the Hayes
Ultra, can connect to both V.32 and HST modems at high speed. Jim was very happy
with his new modem. However, he was not so happy when he saw a V.42bis modem
priced at $49, much less than he had paid for his V.32. Jim called the sysop who
had understood his first problem and was told that this time he had no problem,
because a V.42bis modem with no other designation was a 2400 baud modem, no
faster than Jim's older 2400 baud.
Although the name was changed, Jim's story is true, and illustrates one of the
most common areas of confusion in today's telecommunication field. Jim faced
several sources of confusion. The designations V.32, V.42bis and HST indicate
the modem's abilities, but do not describe them to the uninitiated. Jim was also
using the word "baud" imprecisely without knowing it. If a modem buyer doesn't
understand the jargon of modem descriptions, it is easy to spend a large amount
of money and purchase a modem that doesn't function with any more efficiency
than a $79 modem from a warehouse store.
What makes two modems compatible?
---------------------------------
Modems speak to other modems. In order to do so, the two modems in question must
speak the same "language", otherwise they cannot communicate. In the early days
of modems, the "language" used by the Hayes Microcomputer Products company was
taken as a standard by most modem manufacturers. For medium speed modems (1200
and 2400 bits per second, or bps), this is still the case. Most of these modems
use the Hayes "AT" command set and speak freely to one another.
When manufacturers first began making high speed modems (9600 bps and above), no
clear standard evolved. Several manufacturers developed proprietary protocols
such as HST and PEP (see below).
-----------------------------------------------------------------
Celerity v2.0 Page 133
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Proprietary protocols are owned by the company which developed them, and thus
none of these modems could communicate with any of the other types at 9600 bps,
because none of them spoke the same "language."
CCITT and ITU: International Standards
--------------------------------------
The United Nations, through the Comite Consultatif International de Telegraphie
et Telephonie (originally known as the CCITT but recently changed to ITU-T), is
charged with establishing a recognized standard for high speed
telecommunication. The ITU-T, based in Geneva, has defined many
telecommunication standards, some relating to modems, others to facsimile
transmission, and still others to packet-switching and other telecommunications.
All of the ITU-T standards pertinent to modems are recognizable by their "V.nn"
designation. One thing to keep in mind as you are reading is that the "V-dot"
protocols such as V.32, V.42, and V.42bis are totally different standards,
although they are commonly confused. Additionally, there are some industry
standards (v.32ter, v.FC) which are _NOT_ ITU-T standards, yet use the v.nn
designation.
The -bis or -ter suffix can also cause confusion. It is easiest to think of
-bis as meaning "second implementation" and -ter as being the "third
implementation".
Baud and bps: Are they the same?
--------------------------------
Before beginning, you should know that "baud" does not technically refer to the
speed of a modem, but to an aspect of how the transmission occurs (more
precisely, the number of changes of state in the communication line per second).
The smallest unit of binary data (0 or 1) is called a "bit", short for BInary
digiT. A 300 baud modem utilizing a method known as frequency shift keying sends
one bit per baud and is therefore also a 300 bps modem. A 1200 bps modem is
usually a 300 baud modem using a different method in order to transmit four bits
per baud. Confused? Just forget you ever heard the word "baud" and use the
initials "bps". Another term used in modem descriptions is "duplex". This term,
when used in reference to a modem, indicates whether or not data is transmitted
out and received in simultaneously at the designated speed. Modems using full
duplex protocols can transfer data both directions simultaneously at their rated
speed. Half duplex protocols allow data to be sent in only one direction at a
time. A signal on the end of the information tells the receiving modem that it
is now free to transmit. "Asymmetrical" duplex indicates that information flows
in both directions simultaneously, but at different speeds. "Adaptive" duplex
means that the modems may transmit anything from full to half duplex, depending
on the situation.
-----------------------------------------------------------------
Celerity v2.0 Page 134
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Data Transmission Protocols ("Speed")
-------------------------------------
A data transmission protocol specifies the "modulation technique", or method
used to transfer the data. It therefore dictates the fastest speed at which
information can be transferred. Thus, data transmission protocols are often
called "speed" protocols. In addition to the rate of the character stream, data
transmission protocols define such things as methods used to limit the effect of
telephone line noise, so they are not technically just "speed" protocols.
The ITU-T standards are, by definition, world-wide and non-proprietary. Bell
standard are usually only applicable in North America. There are additional
data transmission protocols which may be either proprietary (HST, DIS, PEP, etc)
or interim (v.32 Turbo, v.32ter (v.32terbo), V.FC) which are not official
standards.
Proprietary high speed data transmission protocols are owned by the companies
which developed them and cannot be used by anyone else without a license. The
cardinal rule to remember about data transmission protocols is that two modems
with different high speed protocols will not be able to communicate with each
other at high speed. However, since all these modems have a standard 2400 bps
protocol as a "fall-back" protocol, these modems will be able to connect in most
cases and communicate at 2400 bps.
Bell 103
Old 110 and 300 baud modems manufactured in North America used the Bell 103
protocol for communications. It uses Frequency Shift Keying (FSK) which varies
of the tone frequency to communicate data, and is the most primitive form of
communication. It is rare to find a bulletin board using a Bell 103 modem
anymore.
Bell 202
The Bell 202 protocol was a format for half-duplex, 1200bps communication. It
was used in the popular "AppleCat" modem for Apple II computers in the early
80's.
Bell 212A
The Bell 212A protocol specifies full-duplex 1200bps communication. These were
the luxury-speed $600 modems of the early 80's. It uses a method called
Differential Phase Shift Keying (DPSK) for data transmission.
-----------------------------------------------------------------
Celerity v2.0 Page 135
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
V.21
This is an ITU-T FSK standard for 300bps data and FAX communications. Most North
American (United States and Canada) modems do not use V.21, but rather follow
the Bell 103 standard.
V.22
You may rarely see a reference to the ITU-T V.22 protocol. Modems using V.22 are
almost universally called "1200 baud" modems rather than V.22 modems. This is a
1200 bps data transmission protocol, which is compatible with the North American
Bell 212A standard (but not Bell 202).
V.22bis
V.22bis is the data transmission protocol recommended by the ITU-T for 2400 bps
modems. The modulation technique used by V.22bis modems is called Quadrature
Amplitude Modulation (or QAM) which transmits four bits per baud, and these
modems typically are 600 baud modems. Four bits per baud at 600 baud is the same
as 2400 bps. These modems are usually called 2400 baud modems, which is
technically incorrect. From the consumer's standpoint, it doesn't matter if your
modem is a 600 baud modem transmitting four bits per baud, or a 2400 baud modem
transmitting one bit per baud. Both have a "speed" of 2400 bps. V.22bis is a
full duplex protocol.
V.23
This ITU-T FSK format is used in the United Kingdom for 1200bps communications
with a 75bps back channel.
V.32
ITU-T V.32 is also a data transmission protocol. It was adopted by the CCITT
(now ITU-T) in 1988. It is a 4800 bps and 9600 bps standard employing a method
called trellis coded modulation (TCM) at 2400 baud. TCM encodes 2 or 4 bits per
baud and is a full duplex protocol. Until the advent of V.32bis, V.32 was
considered to be the standard for high-speed modems. However, it was introduced
only after certain proprietary transmission protocols had become well
established, and thus has shared, but not dominated the high speed data
transmission market.
V.32 Turbo
V.32 Turbo (with a "u") was an interim protocol adopted by a few companies in
1990/1991. This protocol extended V.32 to a connect rate of 12000bps.
-----------------------------------------------------------------
Celerity v2.0 Page 136
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
V.32bis
V.32bis is the current high speed data transmission protocol from the
ITU-T/CCITT, approved in 1991. V.32bis extends the connection range of v.32 to
include 12000 and 14400bps in a full duplex TCM protocol, encoding 6 bits per
baud at 2400 baud. At 4800bps, V.32bis uses QAM.
V.32Ter
V.32ter (or V.32Terbo with an "e") is an interim industry standard developed by
AT&T being advanced by USRobotics, DigiCom, ATI, and other major manufacturers.
V.32terbo boasts a 19200kbps data transmission rate, and should be able to reach
a theoretical maximum of 2400cps. Technically, it is a version of V.32bis which
encodes 8 bits of data per baud. It is NOT an ITU-T-recognized standard.
USRobotics extended the V.32ter in thier modems to reach a data transmission
speed of 21.6kbps.
V.FC
V.FC stands for "V.Fast Class", which is another interim industry standard
developed by Rockwell International, and being promoted by Hayes, Zoom
Technology, MicroCom, and other major manufacturers. V.FC uses line probing
techniques to optimize the configuration of the modem to achieve maximum
throughput on the particular connection. V.FC implementations support 14.4,
16.8, 19.2, 21.6, 24.0, 26.6, and 28.8 kbps data transfer rates, offering
theoretical maximum throughput of 3600cps. V.FC modems are based on technology
similar to that which was be adopted by ITU-T for V.34, but V.FC is not
officially recognized by the ITU-T.
V.Fast
V.Fast is the working name for V.34.
V.34
V.34 is the latest standard approved by the ITU-T, ratified in July 1994. V.34
supports line probing and a 28.8kbps data transfer rate, and is very similar
(but not compatible with) V.FC. Supposedly, V.34 modems based on the Rockwell
V.34 chipset will be backwards compatible with V.FC modems. There are already
rumors of a V.34bis which will raise the stakes to 31.2kbps.
HST
The HST (High Speed Transmission) modulation was introduced by USRobotics in
early 1987 as one of the first high speed (9600bps) modems for dial-up lines.
Their aggressive sysop program quicky made the HST the de-facto "standard" among
bulletin boards. At this time, there was no industry standard to contend with.
-----------------------------------------------------------------
Celerity v2.0 Page 137
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
In 1988, USRobotics extended the HST protocol to support 12000/14400bps
connection rates, then in 1992 it was extended again to support 16800bps. The
HST protocol is similar to V.32 in the fact it uses a trellis coded quadrature
amplitude modulation (TCQAM) technique. It is an "asymmetrical duplex" protocol,
meaning that does not send data at the same speed in both directions, but does
have a continuous connection both ways. The main data channel runs at high
speed (9600bps originally, but extended to 14.4k and 16.8k later) in one
direction, and 300 bps (450bps later) in the other, somewhat similar to the
ITU-T V.23 protocol. The main TCQAM channel encodes up to 5 (7 or 8 later) bits
per baud, at 2400 baud, with one bit used as parity, for the theoretical maximum
of 9600 (later 14400, 16800) bps in one direction. The HST protocol monitors
the data flow, and will switch the direction of the channels to allow the side
sending the most data access to the high speed channel, making it just as quick
as full duplex protocols for file transfers.
The HST protocol is proprietary to U.S. Robotics (USR). The meanings of the
initials USR and HST are often confused. All HST modems are made by USR, but USR
makes other modems which do not use the company's proprietary protocol. For
instance, USR makes a modem which uses only their proprietary HST protocol, the
USR Courier HST. However, they also make a high speed modem that conforms to
the ITU-T standard only, the USR Courier V.32 (later v.32bis).
A third, and very popular, modem marketed by USR includes both the ITU-T V.32
(later v.32bis) protocol and the proprietary HST protocol. This modem, the USR
HST Dual Standard HST V.32, will connect at high speed to an HST only modem or
to a modem that has V.32/V.32bis only, thus the name Dual Standard. The logic
for both protocols actually exists side-by-side in the Dual Standard modems.
In 1992, USRobotics upgraded its HST and Dual Standard lines to include a
16800bps HST mode capable of a theoretical 2100cps transmission rate. The new
modems were 60% of the size of the older modems, and dubbed "v.small". These
modems featured a field-upgradable architecture for future enhancements,
including v.32ter, v.FC, and V.34.
In late 1993, USRobotics upgraded their Courier V.32 and Courier HST Dual
Standard lines to support V.32Terbo, capable of a 19200bps transmission rate.
These modems also include ASL to boost the USR-to-USR connection rate to
21600bps. As with the 16800 HST dual standards, these modems may be upgraded to
with future daughterboards (v.34 and V.FC).
In June, 1994, USRobotics expanded thier line with a dual standard modem dubbed
"v.Everything", which is compatible with all v.32, v.32bis, v.32ter, HST, and
lower speeds, plus the V.FC industry standard. Additionally, these modems were
designed with flash RAM so that they could be upgraded to new standards via
software. In August, 1994, USR released a preliminary upgrade to support V.34.
-----------------------------------------------------------------
Celerity v2.0 Page 138
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
ASL
The ASL (Adaptive Speed Leveling) protocol is also a USRobotics proprietary
protocol which allows USRobotics modems to dynamically adjust the data transfer
rate. In conjunction with v.32Terbo, the USRobotics ASL technology increases
data throughput to 21600bps.
HST Cellular
The HST Cellular protocol is a proprietary USRobotics protocol designed for
cellular data transmission. It is quicker and more stable than MNP 10.
DIS
The DIS protocol, like the V.32, V.32bis and HST protocols, uses quadrature
amplitude modulation to achieve a data transmission rate of 9600 bps. The major
difference between DIS modems and others, however, is the method used to control
"noise", or unwanted signals on the telephone line. A "noisy" telephone line can
cause errors in data transmission or even cause loss of carrier before the
transmission is finished. The ITU-T standards call for use of echo cancellation
to filter out unwanted line noise. Echo cancellation requires a digital signal
processor, which greatly increases the cost of the modem. DIS uses a method of
improving the signal-to-noise ratio which does not require the processor. Thus,
modems using the DIS protocol are significantly less expensive than V.32,
V.32bis, or HST modems. DIS is a proprietary product of CompuCom Corporation.
PEP
The PEP (Packetized Ensemble Protocol) modulation technique, which is a
proprietary product of the Telebit Corporation, is totally dissimilar to the
protocols described above. It uses a method called dynamic adaptive quadrature
amplitude modulation (DAQAM). Effectively, it splits the phone line into 511
sections and puts a 34 baud carrier on each section. By encoding up to 4
bits per baud, PEP achieves maximum speeds of 18000 bps (uncompressed). Each
channel can be going only one direction, so full duplex operation can be had at
9000 bps. PEP also utilizes adaptive duplex, which means that the speed over the
various channels will be determined by the data being sent. If data is being
sent in only one direction, it will transmit at 18000 bps in that direction.
However, if full duplex is needed, data will be sent at 9000 bps in both
directions. If traffic is heavier in one direction than the other, the PEP
protocol adjusts to ensure a maximum data transmission rate. Modems using the
PEP protocol are common in systems using the UNIX operating system. PEP was
recently extended to include TPEP (turbo-PEP) which was a bit faster.
-----------------------------------------------------------------
Celerity v2.0 Page 139
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
ZYX
Zyxel corporation has added extended capabilities to their modems permitting
proprietary 16.8kbps and 19.2kbps connections when connected to other Zyxel
modems.
The following ITU-T protocols are for FAX data transmission. They are only
included here because some modems are advertised as being compatible with these
protocols, and some confusion may exist.
V.17
V.17 is a 14.4kbps/12.0kbps FAX standard used by many FAX modems.
V.27ter
This is an ITU-T standard for 4800/2400bps FAX transmission.
V.29
V.29 is the ITU-T FAX standard for 9600/7200bps FAX.
Some newer modems support 19.2kbps FAX transmissions as well, and 28.8k FAX
transmissions are ultimately expected with V.34 modems.
-----------------------------------------------------------------
Celerity v2.0 Page 140
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Error Correction and Data Compression Protocols
-----------------------------------------------
With high speed communications, connections can be much more susceptible to line
noise than older low-speed connections. In the old days, line noise was
corrected by transfer protocols (such as Xmodem / the Christensen protocol,
etc.) during file transfers, but was ignored during all other activity, so you
would often see extraneous characters appear in messages and other parts of the
BBS. With newer modems, various error correction protocols have been designed
which work internally with the modem, so the two modems in a connection isolate
all errors to ensure error-free data transmission. As with data transmission
protocols, there are a number of competing error control protocols as well.
MNP
MNP stands for "Microcom Networking Protocol", which was the first widely
accepted standard for error control after it was donated to the public domain by
Microcom, Inc. MNP is divided into a number of "levels", which are basically
like separate standards.
MNP error correction divides transmitted data into blocks and uses cyclic
redundancy checking (CRC) to detect garbled data, and re-transmits data blocks
which were not received correctly. By dividing data up into blocks, a drop in
throughput may be observed due to the block overhead.
Level 1
This is a half-duplex block mode used by terminals, and is rarely used anymore.
Level 2
This is a full-duplex "stream mode" error correction protocol. Level 2
throughput is approximately 84% of a no-error-control connection.
Level 3
Level three improves on level 2 by stripping the start and stop bits from the
data before they are sent, and re-adds them when a character has been received.
This process increases the throughput, and offsets the penalty of level 2's
block mode. The performance averages about 108% of that of a no-error-control
connection.
Level 4
Level 4 streamlines the block headers and makes the data blocks larger.
Depending on how bad (or how long-distance) the connection is, a performance
gain of 5 to 50% over that of level 3 (usually about 5%).
Level 5
Level 5 is not an error correction protocol, but rather a compression protocol.
As the data is already being divided up into blocks, MNP level 5 compresses data
-----------------------------------------------------------------
Celerity v2.0 Page 141
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
as it packs them into blocks, and decompresses them after transmission, thereby
allowing more data to be transmitted. This sounds like a great boon for
communications, but there are some problems with it. In file transfers, most
files have already been compressed before they are transmitted, usually so that
they can be stored in less space on a hard disk or floppy disk. This process,
commonly called "archiving", uses one of a variety of proprietary or public
domain compression techniques. DOS files that have been compressed usually have
extensions such as .ZIP, .LZH, .ARC, .ARJ, .ZOO, or .GIF which identify the
compression technique used. If a modem tries to further compress a file with MNP
that has already been compressed by another method, it actually increases the
time needed for transmission. For this reason, MNP level 5 should not be used
if you are going to transmit archived files.
V.42
V.42 is an ITU-T error correction protocol. V.42 incorporates MNP levels 2
through 4. V.42 uses a method known as link access protocol for modems, or
LAP-M. It helps to ensure that transmission of data is done without error.
Unlike the data transmission protocols discussed above, V.42 does not relate to
the speed of data transmission, only to its correctness. V.42 can decrease the
actual time for transmission at a given transmission speed.
This requires a little more explanation. One way of measuring the speed of data
transmission is by characters per second, or cps. Each character consists of 10
bits, thus a 2400 bps modem has a theoretical character rate of 240 cps (the
number of bits per second divided by the number of bits in a character). In
reality, this figure is closer to 235 cps, because no transmission is totally
efficient. This rate is commonly referred to as the "throughput" because it
indicates how many characters the modem can "put through" in a given time. The
10 bits in each character include 8 bits of data plus a "start" bit and a "stop"
bit. The V.42 error correction protocol strips off the excess start and stop
bits and thus reduces the data load by 20%. The actual throughput increase is
less, due to protocol overhead, but is about 15% (270 cps at 2400 bps with
excess bits stripped off compared to 235 cps at 2400 bps without).
V.42bis
V.42bis is a data compression standard. Data compression is commonly used to
reduce the size of a file for storage or transmission. Smaller files naturally
take less time to transmit. V.42bis uses a method of compression called
Limpel-Ziv encoding, which typically can achieve as much as a 4:1 compression
ratio on an uncompressed ASCII text file, meaning four times as much data can be
sent in a given time at a given transmission rate. With V.42bis compression, a
V.32 (9600 bps) modem can achieve an effective transfer rate of 19200 bps on
compressable data. Unlike MNP 5, the V.42bis standard includes the ability to
"sense" pre-compressed files and disable the V.42bis compression for such files.
V.42 and V.42bis are commonly confused with the other V-dot protocols. Unlike
V.22, V.22bis, V.32 and V.32bis, all of which define a data transmission speed,
V.42 and V.42bis have no effect on speed, but are, respectively, error
-----------------------------------------------------------------
Celerity v2.0 Page 142
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
correction and data compression protocols. The modem Jim saw advertised for $29
was a 2400 bps modem with V.42bis data compression ability.
Other error correction and data compression protocols
-----------------------------------------------------
The most common non-ITU-T error correction and data compression protocols are
those developed by Microcom, Inc. These are all indicated by the letters MNP
(Microcom Network Protocol) and a number which differentiates between the
various MNP protocols.
MNP levels 2-4 (error correction) and MNP level 5 (data compression) are in
widespread use and are found on most high speed modems, including those that
meet ITU-T standards.
The reason for this is that both the V.42 standard and the V.42bis standard
include an annex which requires that MNP levels 2-4 (for V.42) or MNP level 5
(for V.42bis) be available as "fall-back" protocols. In the case of error
correction, this ensures that if both modems are not V.42 compliant, at least
MNP level 4 error correction will be used. MNP level 4 is similar to V.42 in
that it strips the start and stop bits from each 10-bit character, thus
increasing throughput by about 15%. The MNP level 4 protocol includes MNP levels
2 and 3, which are also error correction protocols.
Note that some 2400 bps modems do not have any error correction or data
compression ability. These are often referred to as "non-MNP" or "non-error
correcting" modems. When such modems are used for data transmission, software
(such as the Zmodem file transfer protocol) is used to provide error correction.
Modems which have at least MNP level 4 error correction or V.42 error correction
(which includes MNP level 4 as a fall-back protocol) can instead use a file
transfer protocol such as Ymodem-G, which is faster because it sends the data in
a stream with no software-controlled error correction.
MNP level 5 is the most commonly seen non-ITU-T data compression protocol, and
is included in the ITU-T V.42bis standard as a fall-back protocol. MNP level 5
differs from V.42bis in two important ways. First, while V.42bis uses a 4:1 data
compression protocol, MNP level 5 uses a method called run length encoding,
which is only a 2:1 data compression protocol. Microcom did develop a 4:1
compression protocol (MNP level 9) but that did not provide much of a challenge
to V.42bis.The second difference between V.42bis and MNP level 5 is that, while
V.42bis can "sense" previously compressed files and disable V.42bis compression,
MNP level 5 does not have this capability. Attempting to further compress an
already compressed file slows transmission.
Therefore, if a modem with MNP level 5 (but not V.42bis) capabilities is used
mostly for previously compressed files, as is the case with most bulletin board
file transfers, MNP level 5 should be disabled on that modem, usually by
-----------------------------------------------------------------
Celerity v2.0 Page 143
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
toggling a DIP switch or changing a software setting. If the modem is used for
uncompressed text file transfers, MNP level 5 should remain enabled.
MNP level 5 is often erroneously referred to as an error correction protocol.
This is partially because modems tend to be referred to by their most
sophisticated feature. Thus, an "MNP 5 modem" is considered better than an "MNP
4 modem". In fact, this is true, because the MNP level 5 modems always include
MNP levels 2-4. However, it is imprecise to refer to a modem as an "MNP 5 error
correcting modem". In such a modem, only MNP levels 2-4 have anything to do with
error correction, while MNP level 5 is strictly a data compression protocol. It
is more precise to describe such a modem as an "error correcting modem with MNP
level 5 compression".
CSP
A non ITU-T, non-Microcom error correction and data compression protocol called
CSP (Compucom Speed Protocol) is used with modems employing the DIS data
transmission protocol. These same modems offer MNP levels 2-5 as fall-back
routines for times when the DIS modem connects to a non-DIS modem (at 2400 bps,
as DIS is a proprietary protocol). CSP offers compression of up to 4:1 on
noncompressed files without apparent degradation of file transfers on
precompressed files. It is a proprietary technology of CompuCom Corporation.
V.25
V.25 is a standard not for transmission, but for an answer tone. Many North
American modems use the Bell answer tones.
V.25bis
V.25 is not a connect protocol, but rather a protocol for synchronous dialing.
Proprietary error correction and data compression protocols in use today include
MNP level 6 and higher and CSP.
-----------------------------------------------------------------
Celerity v2.0 Page 144
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Summing Up Modems
-----------------
Modem protocols can dictate the data transmission characteristics such as speed
and telephone line noise reduction. Examples of this type of protocol include
V.22, V.22bis, V.32, V.32bis, HST, DIS and PEP.
Modem protocols can also provide error correction, at the same time increasing
throughput by about 15%. Examples of this type of protocol include V.42 and MNP
levels 2-4.
Finally, modem protocols can compress data that has not been previously
compressed, which shortens transmission time by decreasing file size. Examples
of this type of protocol are V.42bis and MNP level 5. The CSP protocol handles
both error correction and data compression for modems using the DIS data
transfer protocol.
-----------------------------------------------------------------
Celerity v2.0 Page 145
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Appendix C: Index Of Files Used By Celerity BBS
===============================================
The following appendix is a comprehensive list of all Celerity-related files by
directory. There is some technical information included with some files,
including the type format for programmers. See the SDK (Software Developers
Kit) for details on these.
Conference Directory:
BSE: Message base file - contains configuration for an individual message base.
Type: MsgBaseRec.
XFR: Transfer Conference file - contains information area configurations for an
entire transfer section.
Type: AreaRec.
CNF: Conference file - contains information on the conference tree structure.
Type: ConferenceRec.
DOR: Door area file - contains a list of doors.
Type: DoorRec.
BUL: Bulletin section - contains news/bulletins.
Type: NewsRecord.
ART: Art Gallery - contains lists of art files.
Type: ArtRecord.
LST: BBS Listing - contains a full BBS listing.
Type: NewBBSRec.
VOT: Voting booth - contains voting ballot information.
Type: VoteRec.
UNU: Unused. No type.
IDX: Message index file used by message base, associated with a .BSE of the
same prefix.
Type: MsgIndexRec.
DAT: Message raw data used by message base, associated with a .BSE of the same
prefix.
Untyped.
QSN: Message quickscan data, associated with a .BSE of the same prefix.
Type: QscanRec.
-----------------------------------------------------------------
Celerity v2.0 Page 146
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
QSX: Xfer area quickscan data, associated with an .XFR of the same prefix.
Type: QscanRec.
QSC: Conference quickscan data, associated with a .CNF of the same prefix.
Type: QscanRec.
NOTE: The QscanRec format used by QSN, QSX, and QSC files changed with the
release with v2.02. Version 2.00/2.01 QS? files should be deleted upon
upgrading.
CAL: Conference Area List, associated with a .CNF of the same prefix. This file
will be displayed rather than an internal listing of the conference items if it
exits.
Type: Text.
XAL: Xfer area list, associated with an .XFR of the same prefix. This will be
displayed as an area listing for the corresponding XFR file to override the
created area listing.
Type: Text.
XAU: Like the XAL area list above, but for upload-only areas.
Type: ASCII/ANSI
-----------------------------------------------------------------
Celerity v2.0 Page 147
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Multinode Directory:
NODELIST.NOD: A continually updated list of all nodes on the BBS. Contains
information about where in the BBS a user is, what he is doing, and so forth.
Type: NodeIDRec.
SPOOL .UP : A LIFO buffer of spooled uploads waiting for UpSpool to process
them.
Type: UploadSpoolREc.
CHATROOM.? : An information file about a multinode chat session.
DCHT? .? : Direct chat data for multinode chat.
SCROLL .? : Scrollback data for individual nodes.
CAPTURE .? : Text capture data for individual nodes.
-----------------------------------------------------------------
Celerity v2.0 Page 148
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Electronic Mail Directory:
MAIL.DAT: E-Mail raw data.
Untyped.
MAIL.IDX: E-Mail index file. Same format as all message base .IDX files.
Type: MsgIndexRec.
* .NOT: User Notes. These files are named based on the UserID of the user
they are intended for in the prefix. They are text-based, but some important
actions may be taken by them by defining the first character in the line.
The FIRST character of each line of the .NOT file contains the command code for
the entry. The ordinal values of valid commands are as follows:
#01: Add uploaded bytes to account
#02: Subtract uploaded bytes from account
#03: Add file points to account
#04: Subtract file points from account
#05: Add commission points to account
#06: Provide "Someone downloaded your upload" information
#07: Receipt of a received no-carrier upload
#08: Receipt of a file having been validated
#09: Receipt of a file which was deleted
#10: Receipt of a file processed by the upload spooler
Data for these entries is text-oriented, beginning on the second character of
each line. Using this format, we will be able to not only allow sysops language
file flexibility with these entries, but we will also be able to give users a
more detailed description of where they are getting points (ie: validation
points) and where they are losing them (when a bad upload is deleted, etc.).
This will also provide an easy way for third party utilities to add entries to
an offline user which will be addressed when the user logs on. If you are
working on a utility and see the need for another entry, let me know and I will
add it. Another advantage of this is improved online speed when doing certain
tasks (such as upload processing (see below for something exciting), deleting
files, doing commissions etc.) as they are now done when the user logs on. Note
that validation credit and commission credit are no longer useful. If the first
character is NOT in the above list, the whole line will be displayed.
Any other files in the Electronic Mail directory are probably file attachments.
-----------------------------------------------------------------
Celerity v2.0 Page 149
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Language Directory:
LANGFILE.DAT: This file contains the information on all of your language and
menu files. A file must have an entry in here for Celerity to recognize it.
This file may be edited with the EdLang.exe utility or with Greg DeCicco's
Language Editor.
Type: LangRec.
LANGUAGE.BBS: If this file exists, it will be displayed to users instead of the
internally generated list of language files.
MENUS.BBS: If this file exists, it will be displayed to users instead of the
internally generated list of menu files.
LNG: Language file data
LNI: Language file index
DSP: Display file data
DSI: Display file index
-----------------------------------------------------------------
Celerity v2.0 Page 150
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Data Directory:
SYSLOG .? : These are the system log files for each node of your BBS.
Type: LogRec.
PROTOCOL.DAT: This file contains information on file download protocols. It may
be edited with Steffan Surdek's PROTEDIT.EXE utility. When new transfer
protocols are added to your BBS, you need to add them here.
Type: ProtoRec.
ONELINER.DAT: This file contains all of your BBS OneLiners, as defined by the
OneLiners section within Celerity. It may be edited with Steve Rosin's
OLEDIT.EXE utility.
Type: OneLinerRec.
TOPTEN .DAT: This file contains a collection of the top ten uploaders,
downloaders, posters, callers, etc. It is used by Celerity to create the top
user lists.
Type: TopTenRec.
HISTORY .DAT: This is the Celerity history file. It keeps track of the BBS'
activity over the course of weeks, months, and years. It can be viewed from
within the Celerity statistics area.
Type: HistoryRec.
XFERLIST.* : The XFERLIST.UPL and XFERLIST.DNL are files which contain a log of
the most recent 500 uploads or downloads from the system. These may be viewed
from the Statistics area within Celerity.
Type: XferListRec.
CALLER .LOG: This file contains a list of the most recent 500 callers to the
BBS. It can be viewed from the Statistics area within Celerity.
Type: CallerLogRec.
MODEM .LOG: This file (disabled in release versions) contains copies of the
answer string detected from the modem. It is used for debugging, and should be
deleted if you have one.
Type: Text.
ERROR .LOG: This file contains a list of errors that the BBS has encountered.
It will be viewed when a sysop logs in. It may be deleted without any
repercussions on system operation.
Type: Text.
AUTO .MSG: This file can be created or uploaded by a user in the Auto Message
section of the BBS. It will be automatically displayed to all users when they
log in (provided that Auto Message is included in your login sequence). It may
be edited outside the BBS. Type: Text.
-----------------------------------------------------------------
Celerity v2.0 Page 151
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
DELETE .ADS: This file can contain a list of BBS ads you wish to remove from
uploads via the "clean upload" option in Celsetup.
Type: Text.
SECURITY.DAT: If this file exists, it should contain directories which the sysop
wishes to prevent cosysops from accessing. For example, if the sysop wishes to
keep cosysops from accessing files in his source code programming directory, he
could add the line:
c:\bp\celerity\20src\
to the SECURITY.DAT file and the cosysop would not be able to access files in
it. Adding a "+" (plus) as the last character will include all subdirectories
in the restriction (ie: c:\bp\+ would keep cosysops out of C:\bp and all of its
subdirectories).
SECURITY.DAT should be used on systems with cosysops where parts of the
accessible drive space are not related to the BBS.
DIR: Transfer area file information. .DIR files contain nearly all of the
pertinent information about files available in your transfer sections. Each
individual transfer area has its own .DIR file.
Type: FileRec;
DES: Transfer area descriptions, associated with a .DIR of the same name.
Type: Untyped.
BCK: A file with a .BCK extension is a file area "backup" file. Old offline
files may be moved to backup directories to retain the information on them, but
not have them listed in your file areas.
Type: FileRec.
BDS: Description file associated with .BCK files.
Type: Untyped.
-----------------------------------------------------------------
Celerity v2.0 Page 152
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Node Directory:
SETUPCOL.CFG: This file contains the color choice preferences for the Celsetup
utility. If you wish to return to the default color choices, you may delete
this file.
MODEMLST.DAT: This contains a list of all the modems directly supported by
Celerity BBS and listed in CELSETUP. Additional modems may be added through
CELSETUP or by directly modifying this file.
Type: Text.
SETUP .DAT: The Celerity setup data as defined by CELSETUP.EXE.
Type: SetupRec.
KAU .DAT: This is a special memory dump of Celerity variables which is made
when a door is opened, and re-read back into memory when the door closes.
DORINFO1.DEF: This is an RBBS-type door drop file. It is created whenever a
door is opened.
Type: Text.
DOOR .SYS: This is an industry standard door drop file. It is created
whenever a door is opened.
CHAIN .TXT: This is a WWIV-type door drop file. It is created whenever a door
is opened.
Type: Text.
MSGTMP . : This file is an editor drop file. It is temporarily used by
Celerity when users write messages.
Type: Text.
FILE .LST: This file is a file listing drop file. It is temporarily used
when used do an archive listing of a file.
Type: Text.
CALLER .LST: This file contains information about the last caller to connect to
the BBS. It is text-based, with every entry being on a separate line. The
format follows:
User Name
User ID
BBS Node
Connect Rate
Date of call
Time of call
Connect Result
-----------------------------------------------------------------
Celerity v2.0 Page 153
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
The connect result is the true connect string from the modem. This can be used
by caller id utilities or something or for generating statistics or whatever.
Type: Text.
CELERITY.EXE: This is the main executable for Celerity BBS.
CELERITY.OVR: This is a required overlay file for Celerity BBS. The use of an
overlay permits Celerity to run in less conventional memory than would otherwise
be required.
CELERITY.KEY: This is your registration key for Celerity BBS.
MAIN .BAT: This is the main batch file used to operate Celerity BBS.
-----------------------------------------------------------------
Celerity v2.0 Page 154
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Main BBS Directory:
STATUS .DAT: This file contains information about how long the BBS has been
running, how many calls it has received, and so forth.
Type: SystemCallsRec.
SYSTEM .KBD: This file defines which keys do what on the system console. It
was introduced with version 2.02, and is discussed in detail in the section
above on "Customizing Console Commands" above.
COMMENT .ASC: When using the internal upload processor, the contents of this
file can be added as a ZIP/ARJ/LHA archive comment.
Type: Text.
USERS . : This file contains all the information about your BBS' user base.
It should be backed up often to ensure that you do not lose this data.
Type: UserRec.
EXTERN .KBD: (or EXTERN.DAT in versions prior to v2.02) This file defines the
external utilities accessible from the Online Tools menu from within Celerity
BBS. See the EXTERN.DAT included with the demo for details on its
configuration, as well as the section on "Online Tools" above.
Type: Text.
COMMENT .BAT: This batch file can be executed on an upload if the "process
uploads" check box is marked in CelSetup. It is usually used in cases where
sysops wish to use TranScan or ZipLab instead of the internal archive
processing.
DIZCLEAN.EXE: This is a Celerity utility which will attempt to "clean" a file
description (file_id.diz, file_id.clr, desc.sdi) of extraneous fluff. See the
separate documentation supplied with this utility for details.
LOGSHELL.EXE: This file is an external shell for Celerity BBS. No external
shells currently exist, but if they did, this would be their name.
REMOTE .EXE: This is a utility included with Celerity BBS which will allow a
remote sysop to "drop to DOS" on the BBS. See the separate documentation for
this utility for details.
???_DOCS.ZIP: This file is named with the first three letters of the BBS'
acronym, as defined in CelSetup. If this file exists, new users will be asked
if they wish to download it when they apply for access. It may contain
important access information, registration forms, and so forth.
-----------------------------------------------------------------
Celerity v2.0 Page 155
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Display Directory:
INF: INF files are information script scripts. See the section on information
scripts for full details.
Type: Text.
IDF: Information script display files. These are used to format information
script data when a user views it. See the information script section.
Type: Text/ANSI.
ANW: Information script answer file. This contains the actual answers given by
users in their information scripts. See the information script section for full
details.
Type: Text.
QUOTE .FMT: This file allows you to customize the text inserted into a message
around a quote. It consists of three lines, a header, line, and a trailer.
The header line will be inserted into the quoted text at the beginning. The
"line" line will be inserted at the beginning of each line of quoted text. The
trailer line will be inserted at the end of the block of text. With version
2.01+, a "%1" may be placed in the first line to refer to the poster's name, and
a "%2" may be placed in the second line for his initials.
Example QUOTE.FMT:
|1Quote from a previous message by %1
|2>%2>|3
|1That's it!|4
This would make a quote of the above:
|1Quote from a previous message by Bob Brown
|2>BB>|3The header line will be inserted...
|2>BB>|3The "line" line will be inserted...
|2>BB>|3quoted text. The trailer line...
|1That's it!|4
Type: Text.
RIPINTRO.RIP: This file will be displayed upon verification of a RIP terminal
being used by the caller.
Type: RIP.
PAUSE .NAP: This file can be used to pause at the end of a NAPLPS graphic
page.
Type: NAPLPS.
NODESC .BBS: When using Celerity's internal upload processing, if
-----------------------------------------------------------------
Celerity v2.0 Page 156
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
a file is found which does not have a file_id.diz description, or a description
is not entered by the user, this alternate description will be imported. It
should say "No Description" or "Uploader Please Describe" or something to that
effect.
SYSOP .LST: This is an optional list of feedback recipients displayed when a
user attempts to send feedback. It can be used to direct users to send their
feedback to certain sysops.
Type: Text.
PROT? .BBS: These are alternate protocol display files, the ? being replaced
with the protocol class #. They will be displayed instead of the conventional
protocol list if the file exists.
Type: Text.
DONATION. : No extension. This file is displayed when the user types the "$"
command from the main menu. Usually contains the BBS' donation policy.
GOODBYE . : No extension. This is displayed to all users upon logging off the
system. Often contains a list of other BBS' supported by your system.
NEWUSER . : When new users log on, this file will be displayed. It usually
will tell a bit about the system and access requirements.
NEWUSER .BYE: If the system is set up to hang up on new users (see the option in
new user options of Celsetup), this file will be displayed before the system
hangs up.
NICETRY . : A message displayed to users who fail to enter their password an
three times. It usually contains a message to the effect of "If you were a new
user, you aren't wanted here. If you're a hacker, get lost." Not that a nasty
message will stop a hacker.
SUMMON . : No extension. This text is displayed to the SysOp when the chat
call is activated. Something short is sufficient. PRESHELL.BBS: A file which is
displayed before the shell is entered.
CAEINTRO.BBS: Text to be displayed when a caller connects to a CAE.
FEEDBACK.BBS: Message a new user gets indicating them to leave feedback to the
SysOp after applying for access.
PRELOGON.BBS : A "system identification" message displayed before a caller
enters his or her user name and password. This is displayed after the first
system is entered from the shell if a shell is used, or immediately if a shell
is not used.
CHANGES .BBS : Quick "news brief" displayed AFTER PRELOGON.BBS, and
-----------------------------------------------------------------
Celerity v2.0 Page 157
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
before the user enters his/her handle/password etc. This should not be more
than one line, and may be omitted altogether if there is no special news
(appropriate news would be "Please fill out the first infoform. Skip the rest.".
Inappropriate news would be "Hard disk crash. Userlist lost. Log on new."
(Because of Celerity's Auto-backup feature (see "Auto-Backup" above), there is
NEVER any excuse for loosing a userlist.))
AD .BBS : Displayed when a user hits "&" from the main menu. It can be an
ad for the software, or changed to something more appropriate for your system.
BLACKLST.BBS : Displayed to a user who attempts to apply and has his name in the
blacklist file.
Blacklst. : This file has no extension. It contains a list of handles which
you do not want admitted to your system. If a user is listed here, they will be
displayed the Blacklst.BBS (see above) file when they log on new.
SYSOP .LST: Displayed to a user leaving feedback. This should list the
various SysOps and who is responsible for what. If this file does not exist, a
list of all users with SysOp flag #8 set is printed.
Shell .? : These are alternate "menus" displayed in the logon shell when
users request help. Shell.1 replaces the menu shell's help, Shell.2 is
displayed when a user types "dir" in the DOS shell, Shell.3 is displayed in the
VMS shell, and so on.
*All news and bulletin files should also be in this directory.
-----------------------------------------------------------------
Celerity v2.0 Page 158
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Appendix D: References
----------------------
The following references may be valuable in your efforts to set up and run a
successful BBS:
Artisoft (LanTastic local area network software)
602-293-6363 Voice
602-293-0065 BBS
ATI Technologies (internal and external modems)
416-756-0718 Voice
416-756-0711 Technical Support
416-756-4591 BBS
Boca Research (internal and external modems, intelligent and non-intelligent i/o
boards)
407-997-6227 Voice
407-241-8088 Technical Support
407-241-1601 BBS
Digiboard (intelligent and non-intelligent i/o solutions)
612-943-9020 Voice
800-344-4273 Voice
612-943-0812 BBS
DigiCom Systems (internal and external DSP-based modems)
408-262-1277 Voice
800-833-8900 Voice
800-833-8900 Technical Support
Hayes Microcomputer Products (internal and external modems, ISDN adapters)
404-840-9200 Voice
404-441-1617 Technical Support
800-874-2937 BBS
IBM Corporation (OS/2 Operating System, PC-DOS Operating System)
Intel (internal and external modems)
503-629-7354 Voice
800-538-3373 Voice
503-629-7000 Technical Support
503-645-6275 BBS
-----------------------------------------------------------------
Celerity v2.0 Page 159
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Microcom (internal and external modems)
617-551-1000 Voice
800-822-8224 Voice
617-762-5134 BBS
Microsoft Corp. (Windows, Windows for Workgroups operating environments, Windows
NT, Windows 4.0 "Chicago" operating systems)
206-882-8080 Voice
800-227-4679 Voice
206-454-2030 Technical Support
206-936-6735 BBS
Novell Inc. (Netware 3.1x, Netware 4.x, Netware Lite, Personal Netware local
area networking software, UNIXWare operating system)
801-429-7000 Voice
800-453-1267 Voice
800-221-6402 Technical Support
801-429-3030 BBS
Practical Peripherals (internal and external modems)
805-497-4774 Voice
800-442-4774 Voice
805-496-7707 Technical Support
805-496-4445 BBS
Quarterdeck Office Systems (QEMM memory management software, DesqView,
DesqView/X multitasking environments)
310-392-9851 Voice
310-392-9701 Technical Support
310-341-3227 BBS
Supra Corp (internal and external modems)
503-967-2410 Voice
800-727-8772 Voice
503-967-2440 Technical Support
503-967-2444 BBS
Telebit (internal and external modems)
408-734-4333 Voice
800-835-3248 Voice
800-835-3248 Technical Support
408-745-3803 BBS
U.S. Robotics Inc. (internal and external modems)
708-982-5001 Voice
800-342-5877 Voice
800-982-5151 Technical Support
708-982-5274 BBS
-----------------------------------------------------------------
Celerity v2.0 Page 160
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Zoom Telephonics (internal and external modems)
617-423-1072 Voice
800-666-6191 Voice
617-423-1076 Technical Support
617-451-5284 BBS
Zyxel USA (internal and external modems)
714-693-0808 Voice
800-255-4101 Voice
714-693-0762 BBS
-----------------------------------------------------------------
Celerity v2.0 Page 161
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Trademark Information
=====================
"DesqView" and "DesqView-X" are trademarks of Quarterdeck Office Systems.
"OS/2", "IBM PC", "IBM XT", "IBM AT" are trademarks of IBM Corp.
"Pentium" is a trademark of Intel corp.
"Dynamic Impedance Stabilization", "DIS", "CompuCom Speed Protocol", and "CSP"
are trademarks of CompuCom Corporation.
"Hayes V-series" is a registered trademark of Hayes Microcomputer Products, Inc.
"ULTRA Smartmodem 9600", "Ultra" and "Smartmodem" are trademarks of Hayes
Microcomputer Products, Inc.
"Microcom Networking Protocol" and "MNP" are registered trademarks of Microcom,
Inc.
"Netware", "Netware Lite", and "Personal Netware" are trademarks of Novell Inc.
"UNIX" is a registered trademark of American Telephone & Telegraph and/or Novell
Inc.
"MS-DOS" is a registered trademark of Microsoft Corporation. "PEP" and
"Packetized Ensemble Protocol" are trademarks of Telebit Corporation.
"USRobotics" is a registered trademark of U.S. Robotics, Inc.
"Courier", "HST", and "Dual Standard" are trademarks of U.S. Robotics, Inc.
There are probably a number of other trademarks used in this documentation as
well.
-----------------------------------------------------------------
Celerity v2.0 Page 162
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Credits and Acknowledgements
============================
Celerity v2.02 manual written, adapted, and edited by Brendon Woirhaye.
Celerity v2.00 manual edited and written by Brendon Woirhaye and Pat "The
Silicon Sailor" McCarthy (Sysop of The Haltsys BBS and The Next Generation BBS).
Celerity 1.42 documentation (source for 2.00 documentation) revised, edited and
rewritten by "Wizard" and Kathy "Rogue" W., SysOps of The Underdark BBS.
CAE and CAE/TAC Mode: Written by Matthew "Holy Ward" E., SysOp of MidPoint Void
CAE/TAC.
An Introductory Lesson in High-Speed Modems: written by Nancy Hattaway, Sysop of
Sempervirens BBS.
The Infoscript processor and documentation was written by Robert Enquist
(Adapted to Celerity by Brendon Woirhaye).
Special thanks and recognition is given to the following developers of
third-party utilities for Celerity v2.0:
Greg Decicco: Celerity Management Tools (Xtree for Celerity), Celerity Language
Editor (for editing CelerityText files), Celerity User Editor, Celerity Mail
Reader, various statistical utilities.
Steve Rosin: Total Packer (Celerity data optimized), various editors, various
conversion utilities, last callers utility.
Robert Enquist: CFiler, recent callers list utility, top downloads list utility,
information scripting system.
Adrian Kwong: Celerity<-->TICK processor (file transfers over a fido network),
Canadian Celerity Support, Guest Account Maintenance utility.
David Hicks: CELSETUP Celerity Setup utility.
Ted Spaulding: CelToscn: Celerity<-->FIDO Bridge.
Steffan Surdek: FAE (file management utility), Celerity Protocol Editor.
Robert Carrico: Celerity Multinode Chat.
InterMail Sales Inc: InterToss FIDO Tosser/Scanner with Celerity BBS support.
Additional thanks to Deanna Pugeot of Practical Peripherals for her
extensive work in developing optimum communications setups for
-----------------------------------------------------------------
Celerity v2.0 Page 163
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
Celerity BBS for the Practical Peripherals line of modems. Exceptional thanks
for their help and forbearance must be extended to all of the Celerity v2.0 Beta
Testing Team.
Alter Ego
Baby Bear
Blackjack
Byteman
Holy Ward
Jack Flash
Lenon
Sicko
The Silicon Sailor
Sledge Hammer
The Byter
Wacky Wabbit
Warlord
Wooly
Zygote
and all the others...
Additional Thanks to All of those who have created (Or are creating)
Celeritytext Menu Files, Celeritytext Language files, and Infoforms for
Celerity.
-----------------------------------------------------------------
Celerity v2.0 Page 164
-= Celerity v2.0 Operations Manual =-
-----------------------------------------------------------------
AFTERWORD: The Tao of BBSing
============================
There once was a Sysop who was attached to the court of the Warlord of Wu. The
warlord asked the Sysop, "Which is easier to maintain: a BBS package or an
operating system?"
"An operating system," replied the Sysop promptly.
The warlord uttered an exclamation of disbelief. "Surely a BBS package is
trivial next to the complexity of an operating system," he said.
"Not so," said the Sysop, "when maintaining a BBS package, the Sysop operates as
a mediator between people having different ideas: how it must operate, how its
Menus must appear, and how it must conform to the laws set down by DOS and the
Phone Company. By contrast, an operating system is not limited by outside
appearances. When designing an operating system the programmer seeks the
simplest harmony between machine and ideas. This is why an operating system is
easier to design."
The Warlord of Wu nodded and smiled. "That is all well and good, but which is
easier to debug?"
The Sysop made no reply.
:)
-----------------------------------------------------------------
Celerity v2.0 Page 165