home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware 1 2 the Maxx
/
sw_1.zip
/
sw_1
/
BBS
/
RB174DOC.ZIP
/
RBBSDOC.ASC
< prev
Wrap
Text File
|
1992-06-19
|
771KB
|
14,164 lines
REMOTE BULLETIN BOARD SYSTEM
for the
Personal Computer
Version 17.4
(includes all updates to 17.4)
Technical Reference Guide
Technical Support Numbers
(407) 487-3441
(407) 487-3442
Copyright 1983-1992
by
D. Thomas Mack
39 Cranbury Drive
Trumbull, Connecticut 06611
Ken Goosens
5020 Portsmouth Road
Fairfax, Virginia 22032
DATA #1,2,3 -- (703) 978-6360
Doug Azzarito
2399 N.W. 30th Road
Boca Raton, Florida 33431-6212
DATA #1 -- (407) 487-3441
#2 -- (407) 487-3442
Version 17.4 released: June 21, 1992
RBBS-PC 17.4 TABLE OF CONTENTS (* = new or revised) Page i
PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1 The Philosophy Behind RBBS-PC . . . . . . . . . . . . . . . . 1-1
1.2 Distribution of RBBS-PC . . . . . . . . . . . . . . . . . . . 1-1
1.3 The "Contributions" Requested for RBBS-PC . . . . . . . . . . 1-1
1.4 How to Send Improvements . . . . . . . . . . . . . . . . . . . 1-4
2. INSTALLING RBBS-PC . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1 First Time Installation . . . . . . . . . . . . . . . . . . . 2-1
2.2 * What's New In This Release? . . . . . . . . . . . . . . . . 2-4
2.3 * Upgrading To The Newest Release . . . . . . . . . . . . . . 2-7
2.4 * Common Problems Encountered Installing RBBS-PC . . . . . . 2-11
3. "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS . . . . . . . . . . . 3-1
4. RBBS-PC's SUPPORT POLICIES . . . . . . . . . . . . . . . . . . . . . 4-1
4.1 RBBS-PC's User Support Methods . . . . . . . . . . . . . . . . 4-1
Written documentation . . . . . . . . . . . . . . . . . . . . 4-1
"The Complete Electronic Bulletin Board Starter Kit" . . . . 4-1
"RBBS-PC in a Box" . . . . . . . . . . . . . . . . . . . . . 4-1
Network mail . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Technical Support BBS . . . . . . . . . . . . . . . . . . . . 4-1
Telephone support . . . . . . . . . . . . . . . . . . . . . . 4-1
Support Boards . . . . . . . . . . . . . . . . . . . . . . . 4-1
Help by Topic . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Professional Tech Support . . . . . . . . . . . . . . . . . . 4-2
4.2 RBBS-PC's Vendor Support Policy . . . . . . . . . . . . . . . 4-2
5. HOW TO GET A COPY OF RBBS-PC SENT TO YOU . . . . . . . . . . . . . . 5-1
6. FILES RBBS-PC USES . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1 RBBS-PC Directory Structure . . . . . . . . . . . . . . . . . 6-2
6.2 RBBS-PC System Files . . . . . . . . . . . . . . . . . . . . . 6-3
6.3 RBBS-PC's Graphics Support . . . . . . . . . . . . . . . . . . 6-5
6.4 RBBS-PC Text Files . . . . . . . . . . . . . . . . . . . . . . 6-6
7. PLANNING YOUR USER INTERFACE . . . . . . . . . . . . . . . . . . . . 7-1
7.1 * Taking Callers Input: Help, Command Stacking, and Hotkeys . 7-1
7.2 Menus Shown to Callers . . . . . . . . . . . . . . . . . . . . 7-2
7.3 Subsystem Prompts Shown to Callers . . . . . . . . . . . . . . 7-2
7.4 Commands Available to Callers . . . . . . . . . . . . . . . . 7-3
7.5 RBBS-PC's "Wrap-around" Command Search . . . . . . . . . . . . 7-3
7.6 How to Have a Single Universal Command Line . . . . . . . . . 7-4
7.7 RBBS-PC'S Programmable User Interface (PUI) . . . . . . . . . 7-6
7.7.1 An Example Using PUI . . . . . . . . . . . . . . . . . 7-6
7.7.2 How to Implement PUI . . . . . . . . . . . . . . . . . 7-7
7.8 RBBS-PC's Support of Sub-menus . . . . . . . . . . . . . . . . 7-9
7.8.1 How to Implement Sub-menus . . . . . . . . . . . . . 7-11
7.8.2 Shared Options Across Sub-menus . . . . . . . . . . . 7-11
7.9 RBBS-PC's "Macro" Command Support . . . . . . . . . . . . . 7-12
7.9.1 How to Set Up "Macros" . . . . . . . . . . . . . . . 7-13
7.9.2 Macro Commands . . . . . . . . . . . . . . . . . . . 7-15
7.9.3 A Sample Macro . . . . . . . . . . . . . . . . . . . 7-20
7.9.4 On-line Data Base With Macros & Questionnaires . . . 7-20
7.10 RBBS-PC's "SmartText" Variables . . . . . . . . . . . . . . 7-23
7.11 "Colorizing" the RBBS-PC User Interface . . . . . . . . . . 7-25
RBBS-PC 17.4 TABLE OF CONTENTS (* = new or revised) Page ii
7.12 RBBS-PC's Automatic Operator Page Option . . . . . . . . . 7-27
7.13 Enhancing the File View Function . . . . . . . . . . . . . 7-29
7.14 * Bulletins and News . . . . . . . . . . . . . . . . . . . 7-30
8. UNIQUELY IDENTIFYING YOUR CALLERS . . . . . . . . . . . . . . . . . 8-1
8.1 Setting Up Identifying and Individuation Fields . . . . . . . 8-1
8.2 Preloading Identities For Instant Access . . . . . . . . . . . 8-2
9. RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT . . . . . . . . . . 9-1
9.1 Setting It Up . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.2 * Allocating Time in Blocks . . . . . . . . . . . . . . . . . 9-2
9.3 * Banked Time . . . . . . . . . . . . . . . . . . . . . . . . 9-2
10. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC . . . . . . . . . 10-1
10.1 Global RBBS-PC Parameters (Part 1 of 3) . . . . . . . . . . 10-1
10.2 Global RBBS-PC Parameters (Part 2 of 3) . . . . . . . . . . 10-3
10.3 Global RBBS-PC Parameters (Part 3 of 3) . . . . . . . . . . 10-5
10.4 Parameters for RBBS-PC System Files (part 1) . . . . . . . 10-8
10.5 Parameters for RBBS-PC System Files (part 2) . . . . . . . 10-10
10.6 Parameters for RBBS-PC "Doors" . . . . . . . . . . . . . . 10-13
10.7 Parameters for RBBS-PC's Security (part 1) . . . . . . . . 10-14
10.8 Parameters for RBBS-PC's Security (part 2) . . . . . . . . 10-16
10.9 Parameters for Multiple RBBS-PC's/Conferences . . . . . . . 10-18
10.10 RBBS-PC SysOp Utilities . . . . . . . . . . . . . . . . . 10-20
10.11 RBBS-PC's File Management System Parameters . . . . . . . 10-21
10.12 Communications Parameters (part 1) . . . . . . . . . . . . 10-24
10.13 Communications Parameters (part 2) . . . . . . . . . . . . 10-26
10.14 Parameters for RBBS-PC NET-MAIL . . . . . . . . . . . . . 10-26
10.15 New Users Parameters . . . . . . . . . . . . . . . . . . . 10-28
10.16 Use of the Library Sub-System . . . . . . . . . . . . . . 10-29
10.17 RBBS-PC's Parameters for Color . . . . . . . . . . . . . . 10-30
11. MODEM SWITCH SETTING AND CONSIDERATIONS . . . . . . . . . . . . . 11-1
12. RBBS-PC's FILE MANAGEMENT SUBSYSTEM . . . . . . . . . . . . . . . 12-1
12.1 Simple Directory Format . . . . . . . . . . . . . . . . . . 12-1
12.2 * The FMS Header Record . . . . . . . . . . . . . . . . . . 12-2
12.3 Advantages/Disadvantages of FMS Directory . . . . . . . . . 12-3
12.4 Creating FMS Directories . . . . . . . . . . . . . . . . . 12-5
12.5 Defining the FMS Category Codes . . . . . . . . . . . . . . 12-7
12.6 * CD-Rom Support . . . . . . . . . . . . . . . . . . . . . . 12-8
12.7 The "Library" Subsystem, CD-ROM, and FMS . . . . . . . . . 12-9
12.7.1 How the "Library" Subsystem Works . . . . . . . . . 12-10
12.7.2 The "Library" Subsystem and PC-SIG's CD-ROM . . . . 12-11
12.8 * Creating the Personal Files Directory . . . . . . . . . . 12-11
12.9 Automatically Checking & Converting Uploaded Files . . . . 12-15
12.10 Fast File Search . . . . . . . . . . . . . . . . . . . . . 12-16
13. SETTING UP ".BAT" FILES FOR RBBS-PC . . . . . . . . . . . . . . . 13-1
13.1 RBBS-PC's Startup Batch File . . . . . . . . . . . . . . . 13-1
13.2 The Daily Event .BAT file . . . . . . . . . . . . . . . . . 13-2
14. THE USE OF RBBS-PC "DOORS" . . . . . . . . . . . . . . . . . . . 14-1
14.1 A Quick Start to Installing Doors . . . . . . . . . . . . . 14-1
14.2 The Major Problems with DOORS . . . . . . . . . . . . . . . 14-1
14.2.1 Redirecting I/O . . . . . . . . . . . . . . . . . . 14-2
14.2.2 Exchanging Information . . . . . . . . . . . . . . . 14-3
14.2.3 Terminating After Carrier Loss . . . . . . . . . . . 14-3
RBBS-PC 17.4 TABLE OF CONTENTS (* = new or revised) Page iii
14.2.4 Security . . . . . . . . . . . . . . . . . . . . . . 14-4
14.3 Invoking "DOOR"s Via The External Control File . . . . . . 14-4
14.4 EXITing or SHELLing to "DOOR"s . . . . . . . . . . . . . . 14-6
14.5 Resetting The User's Record Via a "DOOR" . . . . . . . . . 14-6
14.6 A Summary of "DOOR"s . . . . . . . . . . . . . . . . . . . 14-7
15. THE SECURITY FEATURES OF RBBS-PC . . . . . . . . . . . . . . . . 15-1
15.1 RBBS-PC's Security Features . . . . . . . . . . . . . . . . 15-1
15.2 Examples of Uses for RBBS-PC's Security System . . . . . . 15-2
15.3 * How to Implement the Password File . . . . . . . . . . . 15-3
15.4 Implementing Security for Download Files . . . . . . . . . 15-5
15.5 Implementing Security for RBBS-PC Commands . . . . . . . . 15-7
15.6 Beware of the "Trojan Horse!" . . . . . . . . . . . . . . . 15-8
16. SYSOP FUNCTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 16-1
16.1 SYSOP Commands Within RBBS-PC . . . . . . . . . . . . . . . 16-1
16.2 SysOp Use of Function Keys and Numeric Pad . . . . . . . . 16-2
16.3 Local Status Display . . . . . . . . . . . . . . . . . . . 16-4
17. MESSAGE AREAS WITHIN RBBS-PC . . . . . . . . . . . . . . . . . . 17-1
17.1 "Conferences" and "Sub-boards" -- the Differences . . . . . 17-1
17.2 Making a "Conference" or "Sub-board" Successful . . . . . . 17-3
17.3 Setting Up a "Conference" or "Sub-board" . . . . . . . . . 17-4
17.4 Conference File Locations . . . . . . . . . . . . . . . . . 17-4
17.5 Establishing a "Conference" or "Sub-board" SysOp . . . . . 17-5
17.6 * Carbon Copy . . . . . . . . . . . . . . . . . . . . . . . 17-6
17.7 * Linked Message Bases . . . . . . . . . . . . . . . . . . 17-7
18. * CALLERS AUTOMATIC NOTIFICATIONS OF MAIL/FILE WAITING . . . . . 18-1
19. RBBS-PC QUESTIONNAIRE FACILITIES . . . . . . . . . . . . . . . . 19-1
19.1 Branching to Labels . . . . . . . . . . . . . . . . . . . 19-2
19.2 Display Data Command . . . . . . . . . . . . . . . . . . . 19-2
19.3 Display Data And Get Response . . . . . . . . . . . . . . . 19-3
19.4 Multiple Choice Response . . . . . . . . . . . . . . . . . 19-3
19.5 Forward And Backward Branching . . . . . . . . . . . . . . 19-4
19.6 Raise/Lower User's Security Level . . . . . . . . . . . . . 19-4
19.7 Abort Questionnaire . . . . . . . . . . . . . . . . . . . . 19-4
19.8 Chain Questionnaire . . . . . . . . . . . . . . . . . . . . 19-4
19.9 Turbo Keys . . . . . . . . . . . . . . . . . . . . . . . . 19-5
19.10 Macro Execute . . . . . . . . . . . . . . . . . . . . . . 19-5
19.11 Assign Value . . . . . . . . . . . . . . . . . . . . . . . 19-5
20. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS . . . . . . . . 20-1
20.1 Parameters passed to a protocol driver . . . . . . . . . . 20-1
20.2 Calling external protocols using "templates" . . . . . . . 20-4
20.3 Parameters Returned by a Protocol Driver . . . . . . . . . 20-6
20.4 The Protocol Drivers Tested With RBBS-PC . . . . . . . . . 20-6
21. GOING MULTI-NODE * . . . . . . . . . . . . . . . . . . . . . . . 21-1
21.1 * The Basic Strategies . . . . . . . . . . . . . . . . . . 21-1
21.2 How to Set up RBBS-PC for Multi-Node Operation . . . . . . 21-2
21.3 * How to Add Multiple Communciations Ports . . . . . . . . 21-5
22. UPLOADED FILE TIPS . . . . . . . . . . . . . . . . . . . . . . . 22-1
23. DUE WARNING AND SYSOP'S LEGAL LIABILITY . . . . . . . . . . . . . 23-1
RBBS-PC 17.4 TABLE OF CONTENTS (* = new or revised) Page iv
24. COMPILING AND LINKING RBBS-PC . . . . . . . . . . . . . . . . . . 24-1
25. LIMITED LICENSE . . . . . . . . . . . . . . . . . . . . . . . . . 25-1
26. LIMITED WARRANTY . . . . . . . . . . . . . . . . . . . . . . . . 26-1
27. THE HISTORY BEHIND RBBS-PC . . . . . . . . . . . . . . . . . . . 27-1
28. PROPOSED RBBS-PC SYSOP CONFERENCE . . . . . . . . . . . . . . . . 28-1
28. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD . . . . . . . . 29-1
APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
APPENDIX A -- * RBBS-PC Record Formats . . . . . . . . . . . . . . A-1
APPENDIX B -- RBBS-PC Software Registration . . . . . . . . . . . B-1
APPENDIX C -- RBBS-PC Subscription Service . . . . . . . . . . . . C-1
APPENDIX D -- Modems with RBBS . . . . . . . . . . . . . . . . . . D-1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . D-1
Anchor Signalman Express (MK12) . . . . . . . . . . . . . . . D-1
Everex Evercom 2400 . . . . . . . . . . . . . . . . . . . . . D-1
FASTCOMM 2496 Turbo Modem . . . . . . . . . . . . . . . . . . D-1
Leading Edge Series L 2400B Modem . . . . . . . . . . . . . . D-3
MICROCOM AX\9624c . . . . . . . . . . . . . . . . . . . . . . D-4
Prometheus 2400G . . . . . . . . . . . . . . . . . . . . . . D-5
USRobotics Courier and HST . . . . . . . . . . . . . . . . . D-5
USRobotics HST Dual Standard . . . . . . . . . . . . . . . . D-7
ZOOM Modem HC2400 . . . . . . . . . . . . . . . . . . . . . . D-7
APPENDIX E -- RBBS-PC and the Hearing-Impaired . . . . . . . . . . E-1
APPENDIX F -- RBBS-PC And The AT's RS-232 Cable . . . . . . . . . F-1
APPENDIX G -- RBBS-PC And BASIC Compiler Patches for "Doors" . . . G-1
APPENDIX H -- RBBS-PC in a DESQview Environment . . . . . . . . . H-1
1. Basic Hardware Considerations . . . . . . . . . . . . . . H-1
2. Modifications to DOS CONFIG.SYS and RBBS-PC batch files . H-1
3. What to Tell RBBS-PC's "CONFIG" Utility . . . . . . . . . H-2
4. DESQview Setup Default Settings . . . . . . . . . . . . . H-2
5. Adding RBBS-PC to DESQview's "Open Window" Menu . . . . . H-3
6. Memory Considerations . . . . . . . . . . . . . . . . . . H-3
7. Expanded Memory . . . . . . . . . . . . . . . . . . . . . H-4
8. How to AUTOEXEC RBBS-PC From DESQview . . . . . . . . . . H-4
9. Quarterdeck Utilities . . . . . . . . . . . . . . . . . . H-4
10. Redirecting I/O Considerations (DOS CTTY Command) . . . . H-5
11. FOSSIL Drivers - Break the 2-node Barrier under
DESQview! . . . . . . . . . . . . . . . . . . . . . . . H-5
12. RBBS-PC Technical Support For DESQview . . . . . . . . . H-8
APPENDIX I -- Using RBBS-PC with DoubleDOS . . . . . . . . . . . . I-1
APPENDIX J -- RBBS-PC in a MultiLink Environment . . . . . . . . . J-1
APPENDIX K -- RBBS-PC in a CORVUS Network . . . . . . . . . . . . K-1
APPENDIX L -- RBBS-PC in ORCHID or AST PCnet NETWORK . . . . . . . L-1
APPENDIX M -- RBBS-PC in an Alloy PC-SLAVE/16 Environment . . . . M-1
APPENDIX N -- RBBS-PC and 10 NET Network . . . . . . . . . . . . N-1
APPENDIX O -- Running RBBS-PC on a NETBIOS network . . . . . . . . O-1
APPENDIX P -- RBBS-PC and the IBM PCjr . . . . . . . . . . . . . . P-1
APPENDIX Q -- Using RBBS-PC to access ORACLE or dBASE Remotely . . Q-1
Using dBASE "DOORS" with RBBS-PC . . . . . . . . . . . . . . Q-1
Using ORACLE with RBBS-PC for On-line Data Base Access . . . Q-3
APPENDIX R -- Using RBBS-PC with SEAdog to Access FIDO-NET . . . . R-1
APPENDIX S -- DOS Limitation on Running Programs Remotely . . . . S-1
APPENDIX T -- Recompiling RBBS-PC to Reduce Memory Required . . . T-1
PREFACE Page v
PREFACE
-------
This document discusses the technical aspects of installing, configuring
and running RBBS-PC. You should already be familiar with the following
subjects in order to fully understand the concepts presented in this
document:
- DOS file organization
- DOS Batch files
Consult your DOS command and technical references for details on these
items.
You may also need to have your modem manual handy, to help with getting
your modem to work properly with RBBS-PC.
Conventions:
------------
This manual makes extensive use of examples. The following conventions are
used:
- Items in CAPS are to be entered as shown.
- Items in lowercase, or surrounded in <.> are "replaceable" parameters.
- Filenames with "wild cards" represent a group of files. The "*" and
"?" wildcards are used as in DOS. "?" represents any single
character, while "*" represents one or more characters.
Tools you will need:
--------------------
To install and configure RBBS-PC, you will need a TEXT editor that can edit
DOS text files. Most word processors embed "control" characters in
documents, but also allow documents to be saved in "ASCII" or "non-
document" mode. RBBS-PC's text files can have no TABS or control
characters (other than ANSI color commands) in them.
You will also find it useful to have a "test" computer available, with a
separate phone line. In this way, you can call your RBBS-PC and see the
connection from both ends. While not essential, a test machine can be
extremely helpful during configuration.
About this Document:
--------------------
This document was created using Word Perfect 5.1. It represents the work
of many contributors. Version 17.4 was edited by Ken Goosens, and 17.3 by
Doug Azzarito. Your comments and suggestions are welcome. If you would
like a copy of this document in Word Perfect format (to format it for a
specific printer), contact the authors on the BBS listed on the title page.
INTRODUCTION Page 1-1
1. INTRODUCTION
---------------
RBBS-PC is a Remote Bulletin Board System for the IBM personal computer,
hence the name RBBS-PC. RBBS-PC's primary application is a "host"
communications package. This allows a System Operator (SysOp) to set up a
computer that lets "remote" callers use it for many functions, including:
- the dissemination of news and bulletins
- electronic mail between users
- exchange of programs and data
- taking surveys and placing on-line purchase orders
- or playing games.
RBBS-PC is a "full featured" bulletin board system that not only supports a
broad range of functions, but runs "multi-user" under networks and
multi-taskers. RBBS-PC can also run as a "local" application in which the
"user" does not connect through a telephone line, such as on a local area
network.
1.1 The Philosophy Behind RBBS-PC
---------------------------------
RBBS-PC is given away freely, with source code. Its authors and
contributors neither ask for nor receive any money for their work. RBBS-PC
is "Userware", meaning that it is supported and enhanced by the community
of people using it, who believe that what is shared becomes better than it
was. It is hoped that RBBS-PC will be used as a catalyst for the free
exchange of information, an educational example of communications
programming, and an irrepressible political force that puts the power of
information in the hands of the many.
1.2 Distribution of RBBS-PC
---------------------------
Each new version of RBBS-PC is initially sent to the CPCUG's Software
Exchange for distribution. CPCUG is a Maryland Corporation whose "legal
name" is the Capital PC User Group, Inc. The CPCUG is an all-volunteer,
non-profit organization according to Section 501C3, Social Welfare, of
federal law. All revenues are re-invested in and applied toward CPCUG's
education programs.
There is no fee at all for using or distributing RBBS-PC. Indeed, no one
can charge for its use or distribution, though user groups and commercial
distributors of software can recover their costs but not charge anything
for RBBS-PC itself.
RBBS-PC can also be downloaded from hundreds of bulletin boards across the
country. If the BBS you are calling is running RBBS-PC, chances are good
they will also have the files in their library.
1.3 The "Contributions" Requested for RBBS-PC
---------------------------------------------
RBBS-PC lives and dies by the unremunerated contributions of it's user
community. Four types of "contributions" are requested for RBBS-PC:
A. Modifications to RBBS-PC, itself, that are documented and
distributed as .MRG files against the "base-line" source code that
other SysOps might elect to incorporate into their version of RBBS-PC.
Remember that RBBS-PC can be distributed in modified form only with
permission. Distributing a modified EXE (executable) file without
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 1-2
permission violates both the RBBS-PC copyright and the limited license
granted with it's use.
B. Publicly distributable software. It can either be "public domain"
(i.e. software which the author has relinquished all rights and which
may be appropriated by anyone for use in any way), or publicly
distributable software (i.e. software in which the author has retained
the rights and which may only be used according to the conditions
under which the author has designated).
C. Equipment or services. If you or your organization can donate
equipment, software, supplies, or services to support the RBBS-PC
development effort, feel free to do so. Contact any of the authors
(listed on the title page of this document) if you wish to discuss
equipment donations.
D. Money - the last level of "contribution". Money is the one
commodity that we are willing to exchange without first having
obtained the respect or consideration of the other party. It is
perhaps the easiest to give as it exonerates us from the other levels
of "contribution." RBBS-PC development is an all volunteer effort, so
money is never plentiful. However, when equipment donation is not
possible, spare cash can often buy a piece of hardware that requires
experimentation before RBBS-PC can support it. Remember, money is not
the best or even the second-best type of "contribution" you could
make.
Independent of any donations of enhancements to RBBS-PC, publicly
distributable software, equipment, services, supplies, or money, please
consider becoming a member of CPCUG. Simply send your name, address, and
phone number along with $35 to CPCUG, 51 Monroe Street, Plaza East Two,
Rockville, MD 20850 or call their membership hot line at (301) 670-1737.
If in the final analysis you feel that you can do none of the above,
- remember those who have,
- enjoy what they have nurtured, and
- keep the faith with those who have gone before you.
RBBS-PC is what it is today only because of the freely donated time and
work of many contributors. Contributions have included suggestions,
software fixes, significant enhancements, improved documentation, and
utilities. Some of the individuals named here have continued their
contributions to RBBS-PC even to the current release. Others have gone on
to pursue different interests. But whether mentioned below or not, their
contributions live on in RBBS-PC. In their contributions to RBBS-PC's
on-going growth, each has paused to give of themselves without hope of
reward by practicing RBBS-PC's fundamental principle -- "users helping
users."
While we have met very few of these people personally, those names we
remember are:
Walter Ames Ray Horton Harvey Pierce
Doug Azzarito Gary Howrith Danny Plunkette
Jeff Batdorf Charlie Innusa Lee Pollard
Rod Bowman Loren Jones Jeff Porter
INTRODUCTION Page 1-3
Matthew Briggs Larry Jordan James Reinder
Randy Brodersen Robert Jueneman Joel Ricketts
Mike Brown Vern Kallegin Kurt Riegel
Sam Brown Dave Kleinschmidt Jacques Rodrique
Mike Button Steven Kling Dick Rohradnz
Vince Castelli Kim Kodde Rich Schinnell
Rob Cecchino Blaine Korcel Mark Seiden
Tom Collins Ronald Koridon Rosemarie Siddiqui
Drew Commins John Krytus Andrew Silber
Ezra Conger Mark Lautenschlager Carl Slaughter
Ed Copley Steve Lieber Samuel H. Smith
Richard Couture Steven Linhart Gregg Snyder
Bob Cramer Joseph Lionelle Robert Snyder
Dave Crane Scott Loftesness Carl Spencer
Darrel Damon Harry Logan David Staehlin
Everett Delano Gene Lowry Stan Staten
Francis Dorer James Ludwick Terry Steichen
Peter Eibl Kevin Lutz Dorn Stickle
Warren Fox D. Thomas Mack Randy Sun
John Friel Robert Mahoney Terry Taylor
Jim Fry Matt Malden Jan Terpstra
Asa Fulton Carl Margolis Arnold Thomsen
Kent Galbraith Sidney Markowitz Daan van der Weide
Mitch Geier Jon Martin Rick Wadowski
John German Louie McCaw Clark Walker
Read Gilgen Wes Meier Kim Wells
Gary Glueckert John Morris Bob Westcott
Ken Goosens Bill Newkirk Robert White
Ray Gwinn Jeregen Nordhausen Yew Seng Tan
Dave Hacquebord Vince Perriello
Tom Hansen
Steve Harrison
Gary Hoff
To those whose names have not been mentioned -- apologies are extended.
Take comfort in knowing that you live on in the work that you have wrought.
Special thanks goes to SysOps who helped sponsor enhancements to RBBS-PC,
including Ken Rogers of the United States Department of Commerce ECONOMIC
BULLETIN BOARD who encouraged configurable identification and
individuation, Loren Jones of The Center for Law and Computers at the
Illinois Institute of Technology's Chicago-Kent College of Law who
contributed to subscription support, John Rittwage of the American College
of Obstetricians and Gynecologists who helped support submenus and the
programmable user interface, and Brian Kelly of National Credit Appraisals
and Reporting, whose special needs prompted the development of personal
downloading.
In an age of cynicism, RBBS-PC and the Userware concept represents an
opportunity for each of us to give back to the world something a little
better than when we found it, and is something that the authors of RBBS-PC
believe in strongly. To each of the contributors to RBBS-PC, we would like
to say personally, "We are very proud of the company that RBBS-PC keeps."
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 1-4
1.4 How to Send Improvements
----------------------------
RBBS-PC continues to evolve and be "debugged." The following coding
conventions have been helpful in the past and you are requested to observe
them in the future:
Updates consist of two types of ASCII files. One called *.MRG which are
the BASIC source statements for the particular base-line source code
component of RBBS-PC to be updated. The lines that have been modified are
indicated as being so modified with a comment beginning in column 70 in the
format as follows:
4330 CALL QuickTPut("This line has been changed!",1) ' DA091402
The comment in column 70 consists of the changer's initials, the month and
day of the change, and a sequence number. Thus, the comment DA091402 means
Doug Azzarito made this change on Sept 14th, and it was the second change
he made that day.
These .MRG files can be applied to the base-line source code via Ken
Goosens' Batch Line EDitor utility program (BLED). The BLED utility can
easily create .MRG files as it has both a file compare and file merge
function that is specifically geared to the new BASIC compiler's
capabilities that allow lines of source to be unnumbered.
The second file type is called *.DOC. It describes on a line-by-line basis
the specific functions added or bug that was fixed. The .DOC file is what
allows us to integrate several .MRG files and resolve whatever conflicts
that may exist.
Each incremental release of RBBS-PC beyond 17.4 will include updates to the
base-line documentation. When possible, these updates will be in the form
of replacement pages to be inserted in the baseline documentation.
The RBBS-PC naming conventions are roughly as follows:
1. If a significant change to source code or logic occurs, the first two
digits of the release level will change (i.e. 14.1 was followed by 15.1).
Such changes usually include system file format changes requiring a
"reconfiguration."
2. If a new feature or enhancement is added the digit following the
decimal point is incremented by one (i.e. 17.2B was followed by 17.3).
These changes usually do NOT require "reconfiguration."
3. If a "bug" is being fixed, the letter at the end of the version number
is incremented (i.e. 17.2A was followed by 17.2B). These "maintenance"
releases contain no new significant features, but often fix troublesome
bugs in the previous version. With each maintenance release, a .MRG file
name such as 17-3A.MRG and a corresponding 17-3A.DOC file will describe the
changes. The first maintenance version is always "A".
4. As bugs are reported and fixes found for the current release of RBBS-
PC, the source code corrections are distributed via an RFIXmmdd.ZIP file.
This contains the necessary files to apply the "temporary fixes" against
the released version of the source code and re-compile the source code.
The recompiled .EXE files are distributed via a file named RFIX-EXE.ZIP.
INTRODUCTION Page 1-5
The purpose of these conventions is to allow everyone to know what RBBS-PC
level they are running under and understand the logic behind the
changes/fixes as they occur so each SysOp can evaluate them for his own
needs. When you logon to RBBS-PC the version will be displayed.
If you have comments or fixes, please let us know so that they can be
reflected in the RBBS-PC program and shared with all other users. You can
do that by sending your changes by mail to:
Ken Goosens
5020 Portsmouth Road
Fairfax, Virginia 22032
or uploading the changes to Ken Goosens' BBS at 703-978-6360.
All comments and suggestions are welcome, but those that are come with
source code changes carry more weight.
INSTALLING RBBS-PC Page 2-1
2. INSTALLING RBBS-PC
---------------------
RBBS-PC is a powerful application that may take months to master fully, but
gives those who stick with it a practically ever expanding power as their
knowledge and needs grow. But it is not necessary to understand everything
or take advantage of all its power, before it can be set up initially.
This section is intended to provide a step-by-step approach to setting up
RBBS-PC. Follow the steps thoughtfully! Do not proceed to subsequent
steps until you understand all the previous steps.
Our goal with persons getting started with RBBS-PC for the first time is to
get them off to a fast start by (a) bringing up the software to see how it
runs, and (b) getting the software to be able to answer an incoming
telephone call. A BBS strongly reflects the interests and personality of
it's SysOp, and RBBS-PC is one of the most flexible and customizable of the
BBS's.
However, for those who are NOT familiar with electronic bulletin board
systems in general, a good introduction to installing RBBS-PC is contained
in the book "Electronic Bulletin Board Starter Kit" by Charles Bowen and
David Peyton, published by Bantam Books. The book does in 436 pages what
the next few pages attempt to do. It is a superb guide for someone who has
never setup a bulletin board system or is not knowledgeable about PC or
asynchronous communications. The book comes complete with an extensive
index as well as a copy of RBBS-PC Version 15.1C and, of course, the
associated source code. Since all versions of RBBS-PC are upward
compatible, this book serves equally well as a guide for the uninitiated to
all subsequent versions of RBBS-PC. This book guides the potential SysOp
in easy stages from unwrapping the two diskettes that are included with the
book to operating the more advance features of RBBS-PC. The book was
published by Bantam Books in August of 1988, ISBN 0-553-34552-4, and can be
found in most technical book and computer stores. It addresses the topic
of installing an electronic bulletin board system in a far better way than
this "Technical Reference Guide" does.
Because RBBS-PC attempts to provide SysOps the maximum flexibility, it is
perfectly possible for those setting RBBS-PC up for the first time to shoot
themselves in the foot. Be patient with yourself. Remember that things
worth achieving usually are not obtainable without effort.
2.1 First Time Installation
---------------------------
Do not try to do everything at once. Keep things simple and proceed
patiently, a step at a time, putting only one thing in place. The files
you need are the executables (RBBS-EXE.ZIP) and system text files
(RBBS-TXT.ZIP). RBBS-PC comes completely set up, ready to run. To take
advantage of this set up, you must do the following:
1. Create a new subdirectory on the hard drive of your computer. "RBBS"
is a suggested name but any can be used. The DOS command to make the
directory is "MD \RBBS".
2. Copy the zipped files into the subdirectory. You must have at least
RBBS-EXE.ZIP and RBBS-TXT.ZIP. The DOS command to copy is "COPY
<from> <to>", e.g. "COPY A:*.ZIP C:\RBBS".
3. Make the subdirectory you created your current one ("CD \RBBS").
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 2-2
4. Unzip the files using the command "PKUNZIP -d *". You need to obtain
a copy of the program "PKUNZIP.EXE" to do this.
Subdirectories will be created off the current directory.
5. Enter the command: INSTALL. This program will check the directory
structure, and inform you if any files are missing or misplaced. It
also makes sure the RBBS-PC configuration matches your system. The
file INSTALL.LOG will contain information about files the install
procedure could not find, or had to move. While many of the files are
OPTIONAL, consult this log if you later encounter problems running
RBBS-PC.
You are now ready to run RBBS-PC! RBBS-PC comes with a sample
configuration file, and small but empty users and messages file. To bring
up RBBS-PC, at the DOS prompt, type
RBBS[Enter]
where "[Enter]" means to press the "Enter" key. RBBS is a batch file that
runs RBBS-PC, and also controls certain RBBS-PC maintenance functions (see
section 13 for details). In this first run, RBBS-PC does not to wait for a
telephone call to establish communications through a serial port, but just
runs as a local application, communicating with you through the screen and
keyboard. You should see a copyright notice first, then a "WELCOME TO
RBBS-PC", a short message about a "prelog", and then be asked "What is your
First Name?" What you see on your screen beginning with the "WELCOME" is
exactly the same as a remote caller on the telephone line would see.
Instead of your real name, enter SECRET NAME[ENTER]. This is the "secret
SysOp name" for the sample system. Next, answer the questions RBBS-PC asks
you and look around. Your only goal at this point is to make sure that the
software runs on your computer.
The next goal is to get RBBS-PC to answer an incoming call. This requires
a functioning communications port, modem, and telephone line, as well as
more configuration information in RBBS-PC. There are five things you must
normally do in preparation:
(1) Set the RBBS-PC modem commands properly for your modem, especially the
modem initialization string and firmware initialization string (See
CONFIG parameter 225).
(2) Set the hardware switches on the modem properly, but some modems,
especially "internal" modems, may have no hardware switches.
(3) Set the communications port to what the modem is using (see CONFIG
parameter 221).
(4) Initialize the modem's firmware. This makes permanent the settings
that RBBS-PC needs (see CONFIG parameter 231).
In the best of all worlds, the factory settings of the modem are what
RBBS-PC wants and RBBS-PC's default settings work, so that nothing at all
must be changed. This is normally the case for the USR Courier 2400 modem.
Your key to setting everything up is the RBBS-PC configuration program
called "CONFIG.EXE". CONFIG is your guide to configuring RBBS-PC for your
preferences and environment, and basically is just a smart editor for
INSTALLING RBBS-PC Page 2-3
setting up RBBS-PC. RBBS-PC stores its configuration parameters in a file
called "RBBS-PC.DEF". To edit configuration file RBBS-PC.DEF, just type
CONFIG RBBS-PC.DEF[Enter]
You will see a copyright notice, CONFIG will read in the current values,
and then you will see a table of contents for the many pages of parameters
you can set. There are over 300 parameters you can set in RBBS-PC, which
can be extremely complex. Most you will never change, but RBBS-PC has
tremendous power and flexibility if and when you do need it. You can just
press the page down key "PgDn" to see the many screens of parameters, if
you want to browse. Do not be intimidated. RBBS-PC, as shipped, has
nearly all of these parameters set for you. For more information, read
section 10.
Once you have set the modem parameters in CONFIG, and saved your changes,
you are ready to make sure that RBBS-PC will answer incoming calls. Be
sure you have your modem connected and on. Then type
RBBS[Enter]
You should see a copyright screen. RBBS-PC will draw a screen with boxes.
The modem lights should flash, and RBBS-PC should display "Ready for Calls"
in a box. Four lights on an external modem will normally be on: High Speed
(HS), Auto Answer (AA), Modem Ready (MR), and Terminal Ready (TR).
Ideally, you have a second computer beside the first with a modem and
telephone line that you can use to call the BBS. Otherwise, have a friend
with a computer call it. You need to call with a modem to make sure that
the two modems will talk. When the call comes in, the Ring Indicator (RI)
should blink. Then the Off Hook (OH) and Carrier Detect (CD) lights should
come on as the modems link. And RBBS-PC should chip in with its opening
"WELCOME TO" line, and the send (SD) and receive (RD) lights should blink
periodically. If the lights blink but you see nothing, you may need to
turn on "snoop" so you can see the session on your local terminal. Press
F9. If that doesn't do anything, press it again. After the caller says
"Goodbye", RBBS-PC should recycle, the CD and OH lights go off, and the box
reappear that finally says it is again ready for calls.
Once you have RBBS-PC answering calls, you are ready to begin customizing
the board, setting it up the way you want, and adding features. You need
two primary tools: CONFIG.EXE (part of the RBBS-PC package), and a full
screen editor (which you must supply). You need what is called a
"programmer's" editor versus a word processor - one that only puts in what
you type and never inserts any hidden or special characters - what is
sometimes called as straight "ASCII" editor.
Here we will walk you through what is behind what the caller sees on logon.
The first message is "WELCOME TO " followed by the name of the board, as
specified in CONFIG parameter 12.
Next the file PRELOG is displayed. This file need not be present, and
generally should be brief, as it is displayed on every call.
Callers are then asked to identify themselves, by answering the question
"What is your FIRST name?" The text after "your" can be set up with CONFIG
parameter 45, though most SysOps do not change it (e.g. "What is your
ACCOUNT ID?"). The next question is "What is your LAST name?", which can
be set in parameter 46.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 2-4
If the caller is not in the user's file, which normally means that this is
a new, first time caller, then RBBS-PC displays the text file called
NEWUSER. Here you should explain the board and the rules you have for
people to follow.
Callers next see a welcome specific to their security level, called a
"logon level greeting file". These files take the form LGnn.DEF, where
"nn" is their security level (e.g. level 10 callers would see the file
LG10.DEF, if it is present in the default directory). Then, a general
"welcome" file is displayed. The general welcome file shown to the caller
can be changed "on the fly" by RBBS-PC, dependent on what sort of Graphics
option the caller has selected. SysOps often use this for an ANSI log-in
screen.
There are many other things in RBBS-PC you will want to set up, such as
bulletins, news, and conferences. Just remember to take your time.
RBBS-PC almost always runs the FIRST time. Make one change at a time and
then test it so you don't break something that once worked.
2.2 What's New In This Release?
-------------------------------
Each new release of RBBS-PC, version 17.4 (17.4A, 17.4B, etc.) contains
fixes and enhancements to RBBS-PC. Releases ending with a letter are
considered "maintenance releases" to RBBS-PC 17.4. With each maintenance
release, you will find text files that describe any new features, and
instructions on how to upgrade from a previous release.
The area of greatest enhancement in 17.4 is the messaging system. The new
changes allow the BBS to be used much more effectively for
o group mail. The same message can be sent to multiple people, and only
one copy is kept. The SysOp can set up distribution lists.
o exchange of personal files as well as mail. Uploads can be addressed
privately to people, with descriptions viewable only by them. People
will get notification of new uploads on logon, and the SysOp can set
up distribution lists.
o large conferencing. Message read operations can operate globally
over linked message bases, with default linking on logon of all
conferences in which the person belongs that have any new mail.
Specifically, the major changes are:
1. The same message can be sent to up to 255 individuals, either by name
or distribution list.
2. Messages based can be linked together so that message read commands
operate globally across linked conferences. Conferences can be
linked individually, or based on new mail, or new personal mail.
3. The utilities B)aud change has been replaced by B)ank time. This
lets the caller deposit time into a bank, to withdraw on later callers
to increase session time.
4. The SysOp can view the caller's file for any node.
INSTALLING RBBS-PC Page 2-5
5. Personal files can be uploaded to an individual, multiple individuals,
or to a distribution list. Caller with personal upload is notified
on logon of files waiting.
6. Any FMS directory can be made to limit downloads to only those listed
in the directory, can be exempted from ratios (free), and give extra
time for downloading, or be made a personal directory where the file
is directed to any individual.
7. The file search, new, and list commands all work for the personal
directory.
8. Files can be Marked for later downloading and viewing as a group.
9. Messages can be Marked for later reading and killing as a group.
10. The config functions to check personal and FMS directories have been
enhanced to detect more problems, including messed up file names and
trash at the end of the file. These checks can also be run on a
NetBios network without bringing down the BBS nodes running.
11. The SysOp can change the # of minutes the caller has used. By
changing it to a negative #, the caller is given bonus minutes over
and above the normal session time, until the bonus is finally used up.
12. Download time estimates are now correct even when modems report the
modem-to-pc speed in the CONNECT message. The carrier or
modem-to-modem speed is detected and can be passed from a front end.
13. The caller and SysOp can now change the city/state.
14. The documentation was enhanced to show how to set up RBBS-PC with 8
com ports on the DigiBoard Digichannel.
15. Download time estimates are now correct even when modems report the
modem-to-pc speed in the CONNECT message. The carrier, to
modem-to-modem speed, is detected and can be passed from a front end.
Lesser enhancements include
1. Logging out for keyboard inactivity now counts down the last 30
seconds.
2. The SysOp can suppress or shorten the display of the copyright when
RBBS-PC first comes up. Config parm 96 lets you set the time for the
screen to be displayed. Set it to 0 to suppress the screen entirely.
3. The entry of integers - including lines to edit/delete/insert, message
margin, lines per page, etc. - now includes in the prompt any range
constraints, reminds the caller of a range constraint when the entry
is not within bounds, and consistently displays the old value if one
is to be changed.
4. Entrances and exits from a conference are now time stamped in the
caller's file.
5. The autologoff option "/g" on the end of any command now gives the
caller 30 seconds to cancel the logoff.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 2-6
6. The config option to pack users will not omit any user who was last on
more than 59 months ago. Figures that clock was wrong.
7. The config option to pack users lets the months since last called be
set up to 59 months rather than 12.
8. The SysOp can edit the time remaining for any user.
9. Local sessions not a SysOp are now logged to the caller's file.
10. Personal directories can have extended descriptions.
11. When there is insufficient time to download all the files requested,
the caller gets an opportunity to edit the list of files rather than
to have to retype the names of the files desired.
12. Confirmation to continue is asked when a search goes 100 messages
without a hit.
13. Config parameter 173 can be used to limit the types of message
security a caller can use for any message base. Can pick any
combination of public, private, and password, as long as at least one
is picked.
14. A separate fallback security level can be specified for each security
level, when the subscription expires.
15. Can back out of a message save and resume editing.
16. When in local mode and shell to a door, can join subboard without
getting an untrapped error.
17. No longer can circumvent ratios by canceling a download after last
block is received.
18. SmartText has a new variable "CN" for name of the current conference.
19. RBBS has ability to detect whether remote caller can support ANSI,
before getting the name. Allows graphics prelogs.
20. Assistant SysOps given access to SysOp function 2 for viewing the
caller's log can now see all information except for what might reveal
the remote sysop name, rather than just the one-line listing who
called when.
21. Config lets the personal directory be put anywhere rather than just
where the personal downloads go.
22. Macros can be restricted to a PUI by using the first letter of the PUI
name as a "section" in the macro restraint.
23. The ability to quote a message can be disabled via option 97 in
config. Default is to allow message quoting.
24. Baud rates of 7200, 12000, and 14400 are now logged as such in the
caller's file.
INSTALLING RBBS-PC Page 2-7
25. Subject of password protected message is now revealed after the
correct password is given.
26. V)iew is now an option when reach end of a directory listing.
27. Support added for "14.4" as meaning "14400" in modem speed.
To implement the new features
(a) If you want people to be able to do personal uploads, you must
set configuration parameter 159. This lets people exchange
private files as well as mail.
(b) If you want to enable carbon copy, you must set configuration
parameter 160. This lets the same message be addressed to
multiple people and makes "group" mail be feasible.
(c) If you want to provide distribution lists, you must set
configuration parameters 171 and 172.
(d) To limit the max time people extra people can have for personal
downloads to something other than 60 minutes, put the TIMEEXTRA
parameter in a header record.
(e) To limit the bankable time, use parameter 292 in config and the
last parameter of PASSWRDS. You can control the bankable time
by security level if desired.
(f) To make multiple caller's files viewable set config parameter 95
and use an editor to create that file.
(g) To set a security level when a subscription expires, put the
value in the 6th position of the PASSWRDS file.
2.3 Upgrading To The Newest Release
-----------------------------------
Warning: 17.4 is NOT "plug" compatible with earlier releases. It is
upward compatible in that it can run with older system files. But third
party software may not yet able to support the new file formats of 17.4.
The major changes are as follows:
o The format of the message file has changed, allowing (but not
requiring) support for multiple headers in a message
This change corresponds to allowing the message to be addressed to more
than one person. This "carbon copy" or "distribution list" feature may
not be supported by external message base utilities and may work improperly
with messages that have more than one header record. If you must have
compatibility with programs that do not yet support multiple headers, set
configuration parameter 160 to NO, not enabling carbon copy. Multiple
headers unfortunately are not supported in current versions of EchoMail or
NetMail.
o A new field has been added to the user's file, for number of
minutes of banked time.
o A new flag is set in the users' records, indicating whether they
have any new personal uploads waiting.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 2-8
External user file utilities may fail to support these fields and work
improperly with the new user file format.
o There are TWO (2) changes to the PASSWRDS file!! (a) A new
parameter on the end: max time to bank, and (b) a new parameter
in the 6th position: expired security level.
These new variables apply to the line in question, which applies to the
temporary password specified in parameter 1, or the security level in
parameter 2, for the time of day indicated on the line.
RBBS-PC strives to remain fully upward compatible, preserving all
capabilities of earlier releases. However, 17.4 drops support for the
following features:
o the Novation modem, originally released with the IBM PCJr
o switching from 300 to 450 baud.
Any upgrade considerations are described in detail in a text file contained
in the release. Generally, you need to
- replace RBBS-PC.EXE and CONFIG.EXE with the new versions
- add/replace any new HELP files
- run CONFIG and set up any new parameters (as described in the release
notes for the specific maintenance release).
When upgrading, follow these general cautions:
1. Do not destroy or overwrite your old files. You may run into
difficulties and have to fall back to the old version. Especially
keep a backup of your current USERS, MESSAGES, configuration "DEF"
files, and your RBBS-PC.EXE and CONFIG.EXE files.
2. Start by trying to get the new version just to run equivalently to the
old without implementing new features. Implement new features one at
a time. Do not try to implement everything new at once.
3. The file that almost always changes between non-maintenance versions
is a configuration "DEF" file. A utility program called RECONFIG.EXE
is provided that converts all versions from 14.1D on to the latest.
This will save you the trouble of manually re-entering the parameters.
If you do not have RECONFIG you should print out all the options you
selected on your current RBBS?PC.DEF file.
4. CONFIG.EXE has an option to review the parameters changed since the
last version. You should always run this to see what is new and
possibly change the values. If you do not have RECONFIG, you
generally need to delete your current RBBS?PC.DEF file and manually
enter the parameters. Sometimes, however, the same parameters will be
in a different place in the new configuration. If you are upgrading
from several versions back, there is no simple way of knowing what all
is new.
5. The MESSAGES and USERS files are the two that are most important to
continue to be able to use. RBBS-PC 17.4 is compatible on both
accounts with files at least back through version 14, in that 17.4 can
read and write the files from earlier versions, with no conversion.
INSTALLING RBBS-PC Page 2-9
However, for versions prior the 17.3, there is a critical parameter to
set in CONFIG: the minimum security to auto-add a user to a
conference. This applies to conferences not sub-boards, i.e. that
have no configuration DEF file. Go into CONFIG, conference mode, and
then check this value. No one will be able to join the conference if
their security is below this number, even the SysOp. Reset this value
so that the desired callers can join the conference.
6. RBBS-PC is written to be upward compatible, preserving all the
functions of earlier versions. However, you may have to make changes
to the new configuration to make it run equivalently. If upgrading
from 17.3x, you need to consider the following:
(a) Run config to set parm 292 if you want people to have any time to
be able to bank.
(b) Add two new parameters to PASSWRDS. There are now 13 parameters
(12 commas). You must add the parameters for the PASSWRDS file
to work. It is recommended that you add ",60" to the end of
each line in PASSWRDS. For the expired security level to work
the same, you must insert what was in config parm 49 to position
6. E.g. if parm 49 had value 5, then change would be
(before)
,8,70,70,365,,,,-1,,
(after)
,8,70,70,365,5,,,,-1,,,60
(c) Replace MENU4, MENU4G, MENU4C, UB.HLP, MR.HLP, FL.HLP.
(d) Run the config option to set new parameters.
17.4 has some incompatibilities and operational differences, including
(a) The first command in a quit in a PUI is now the default when
Enter is pressed. Before, there was no default.
Some operational changes in RBBS that may at first confuse experienced
callers, including
(b) No longer can a 300 baud caller change to 450.
(c) When in TurboKey mode, the caller can no longer just type in
the file names for implied downloading at a prompt in a directory
listing. Callers must now issue the D)ownload command first
(e.g. "D", then "file1 file2 ..." rather than directly "file1
file2 ...". Even though the prompt no longer has the option "or
files to download" lists of files for downloading will be
processed as before when not in TurboKey mode or if TurboKey is
suspended ("/ file1 file2 ...").
(d) When uploading, the caller will be asked a new question of who
the upload is for. Indicating a)ll operates as before. Otherwise
the file will be added as a personal upload to the persons
indicated, and NOT be added to the upload directory, but rather
the personal directory. Note that this changes the meaning of
stacked commands: the old "u file1 file2" now means to upload
file1 to person file2!
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 2-10
(e) "J MAIN" will not longer work (though "J M" will) unless your
main message base is named "MAINU.DEF".
(f) Subscription management now works in Subboards. This means that
a subscription can independently expire in a subboard.
Previously, subscription management worked only on the main logon
board. To get RBBS to work equivalently, you must configure the
subboard to turn OFF subscription management to let the main
board manage subscriptions and set the security level, and have
it follow into conferences. However, now you can set up
subscriptions to subboards.
(g) Pressing Enter during a display of text will no longer terminate
that display, but rather simply stacks the Enter. 17.4 works the
way RBBS-PC did prior to 17.3C.
If upgrading from 17.2x, you need to consider the following:
(a) replace RBBS-PC.EXE and CONFIG.EXE
(b) If you want file a)ll to list multiple physical directory files
(as opposed to say just the FMS master file), then you must set
up RBBS-PC differently (see CONFIG parameter 218).
(c) If you turned on "enforce ratios", but exempted all security
levels (this tells RBBS-PC to track, but not restrict,
downloads), you must change the ratio (parameter 9 in PASSWRDS)
to -1 in order for the code to work equivalently. Similarly, a
ratio of 0 will not even COUNT the downloads. (This allows
"free" periods of downloading to be specified.)
7. If upgrading from 17.1, you need especially to consider:
(a) the minimum security to read and kill all messages. If this is
set to 0, everybody can read everyone else's mail!
(b) RBBS-PC formerly supported the "arc" format exclusively. Now
"zip" is its default, but it can be set up for any. Review the
parameters for default extension and archiving command.
(c) Your personal directory may not work unless you include a
drive/path. Re-enter the parameter value in CONFIG.
6. If you are upgrading from a version prior to 17.1, consider the
possibility that the PASSWRDS file may have a different format, that
external protocols are controlled by an external table (PROTO.DEF),
that the doors interface may be different, and the control for an
timed event may be different. See section 10 for information on these
CONFIG parameters.
9. Use the new text files, especially the menus and help files. If you
have customized versions of these, start with the distributed files
and change them.
10. Review the documentation on the major areas of enhancements. Section
26 on the history of RBBS-PC briefly reviews the enhancements in each
version of RBBS-PC. Some specific things that you want to take
advantage of include:
INSTALLING RBBS-PC Page 2-11
(a) Macros and SmartText have been significantly improved in 17.4.
You no longer need to include a "{ST" at the end of macros and
will probably want to omit it. You may want to enhance your
menus as well. See the revised sections on SmartText and Macros.
(b) You may want to make file searches faster and reduce the wear on
your hard disk by installing the fast file search system. See
section 12.9.
(c) You may want to create a new category of system bulletins - a
NEWS facility (see section 7.13).
The major changes in 17.2A were:
(a) use of shelling triggered by the presence of BAT files to test uploads
for integrity, convert uploads to a different format, and support
viewing of text files inside ZIP files, and verbose list any
compressed format,
(b) greatly enhanced macros and questionnaires, including new data base
functions,
(c) enhanced doors interface, including an external control file for doors
(DOORS.DEF) as well as the ability of a door to request that RBBS-PC
change the user record (DOUTx.DEF), pass any information via command
line or a file to a door, and for a door to return information to be
displayed to the caller
(d) the message files can be configured to have minimum size to hold the
messages and let grow in size as new messages are added,
(e) conferences and sub-boards can be configured to automatically change
the user's security to match the logon security,
(f) message quoting, allowing the option to type in be the same on
different submenus and be a single keystroke, speech synthesizer
support for visually impaired SysOps, making uploads immediately
shareable on Novell networks, an easy way to give a conference
moderator access to all mail without having to make them SysOps,
chained FMS directories, and more.
PLEASE NOTE!!!!! ---- 17.4 does change a field in the user file and the
structure of the message file.
2.4 Common Problems Encountered Installing RBBS-PC
--------------------------------------------------
IT CONTINUALLY RECYCLES! This can have several causes. RBBS-PC requires
that a modem be attached to your communications port. Therefore:
- check what communication port is being used.
- verify that this communications port exists.
- verify that your modem is attached to it.
- verify that your modem is powered up.
- verify that your modem is configured properly.
- verify that CONFIG knows what kind of modem you're using.
- verify that the modem cable supports all ten signals required by
RBBS-PC (see Appendix F).
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 2-12
- verify that DTR (Data Terminal Ready) and CD (Carrier Detect) are set
to "normal" rather than always "on" (sometimes called "true" and
"forced" instead).
- verify that each DOS subdirectory referred to in CONFIG exists.
- verify that RBBS-PC runs properly when set up to use COM0 (i.e. a
local workstation).
Internal modems, which are not recommended for running a BBS, can sometimes
cause a special problem with the communications port. An internal modem
its own communications port. Setting it to the same communications port
as one already installed on your computer can cause unpredictable results.
Realize that many motherboards already have com1 and com2 on them. Make
sure your internal modem is not set up in conflict with another part of
your computer -either trying to use an interrupt already in use or set to
the same com port as one already there. Usually a jumper or switch on the
internal modem lets you select an interrupt and the com port number. If
you use com3 or com4, you must use a Fossil driver with RBBS-PC. In
extreme cases, you may want to disable a com port on your motherboard and
set the internal modem to com1 or com2.
If, after all of the above has been attempted, the problem still persists,
try deleting your MESSAGES and USERS files and re-run CONFIG to create new
ones.
Finally, having exhausted all the above remedies, the system continues to
continually re-cycle, you may have an incompatible "clone" PC, incompatible
DOS, incompatible modem, and/or a bad copy of RBBS-PC.EXE.
IT WON'T ANSWER THE PHONE! This also can be caused by one of the following
things:
- Phone line is not plugged into the modem.
- Modem is not powered on.
- Modem is not connected to the communications port that RBBS-PC was
told to use.
- You have two com ports set to the same number.
- Your com port is using an interrupt (IRQ) being used by another device
on your computer.
- Your modem switches or firmware is not set (see CONFIG parameter 231).
- Your modem is not "Hayes compatible" enough to handle the modem
commands described in section 11.
- Your modem cable does not have Pin 22 connected.
- Your modem requires CTS flow control to be enabled. In CONFIG, set
parmeter 244 to YES.
There are two conditions under which RBBS-PC does not require Pin 22 in the
RS-232 cable to reflect the status of "ring".
RBBS-PC does not require Pin 22 to be hooked up on the RS-232 cable (that's
the cable which runs between the modem and the computer, by the way), if
you specify in CONFIG that RBBS-PC is to answer the phone on zero rings,
and that it is not a "RING-BACK" system. In this setting RBBS-PC will
initialize the modem so that the modem AUTOMATICALLY answers the phone.
RBBS-PC also does not require Pin 22 to reflect the status of ring when
your modem returns the result code "RING" as the phone is ringing. The
default setting for RBBS-PC is that it depends on either Pin 22, or the
modem result code "RING", to know when the phone is ringing. This is
INSTALLING RBBS-PC Page 2-13
because RBBS-PC, and NOT the modem, answers the phone. When RBBS-PC is
informed by the modem that the phone is ringing, it counts the rings by
issuing the "ATS1?" command. When the number of rings has reached the
number you told CONFIG you wanted to answer after, RBBS-PC sends the "ATA"
command to tell the modem to answer the phone (see section 11).
If your modem does NOT send the characters "RING" each time the phone
rings, you will need a cable with Pin 22 connected. Some computers (such
as the PCjr's external RS-232 interface) and some modem cables don't have a
"ring-indicator" signal. Pin 22 is the ring indicator coming from the
modem going to the computer. And just because you bought an RS-232 cable,
don't assume that it has Pin 22 connected. This is often not the case.
IT LOCKS UP MY SYSTEM! This may be caused by one of the following things:
- The .EXE file generated by the BASIC compiler is incompatible with
either the DOS that you are running (i.e. it isn't generic MS-DOS or
IBM's PC-DOS), or other software you load into the system prior to
running RBBS-PC (such as a device driver loaded in CONFIG.SYS, or a
TSR program loaded in your AUTOEXEC.BAT file). Remove all
non-essential memory resident software.
- You indicated in CONFIG that you were running one of the supported
networks (i.e. CORVUS, MultiLink, Orchid, etc.), but you aren't.
- You are running on a COMPAQ DeskPro, or using an add-on board that
uses the unused DOS interrupt 7F hex, and should have used CONFIG
parameter 29 to indicate you are using a COMPAQ PC.
- Your modem isn't set up correctly, probably not supplying us with
"true" carrier detect (i.e. the modem tells us that a caller is
connected when that's not true). Try selecting "Hayes 2400
compatible" as the modem type in CONFIG, and use parameter 231 to
re-program the modem's firmware.
- RBBS-PC is trying to log to a printer that does not exist or is not
turned on, or out of paper, and no error condition is ever being
returned back to RBBS. In CONFIG, tell RBBS-PC to turn the printer
off after each recycle (parameter 52).
- Your system does not support standard DOS system calls for screen
writes. Try setting CONFIG parameter 39 to use BASIC for screen
writes.
- Your system is not as PC compatible as it should be and may use
strange interrupts. Try turning assembler routines off (parameter
38).
"BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS Page 3-1
3. "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS
-------------------------------------------------
RBBS-PC is designed to run on an IBM Personal Computer, or compatible,
running MicroSoft's Disk Operating System (DOS), communicating via an
asynchronous communications adapter (aka a "COM" or "serial" port), and
using a Hayes Smartmodem, or compatible modem. The following equipment and
software is the MINIMUM and the recommended configuration for running
RBBS-PC:
Item Minimum Recommended
System IBM PC or compatible IBM 80386 compatible
Monitor 80 column monochrome 80 column color monitor
COM port RS-232 adapter with an Intel RS-232 adapter with an Intel
8250 UART chip 16550AFN UART chip
Modem Any Hayes Smartmodem 1200, A USR Courier HST dual
or 100% compatible modem standard 9600/v.32bis modem
Phone line Voice grade telephone Voice grade telephone
connection for modem connection for modem
Modem cable 25 pin RS-232 shielded cable 25 pin RS-232 shielded cable
RAM 512K RAM available for DOS 640K RAM available for DOS
and RBBS-PC and RBBS-PC
Disk size 20MB hard disk 120MB hard disk
DOS version MS-DOS version 2.1 MS-DOS 5.0 or higher
The .EXE files are distributed with RBBS-PC as well as the BASIC source
code so it is not necessary to have a BASIC Compiler to run RBBS-PC.
However, for those who would like to compile RBBS-PC from the source code
the recommended compiler is Microsoft's QuickBASIC version 3.0.
The MINIMUM configuration that can run RBBS-PC is an IBM PC that has 360K
of random access memory (RAM), one double-sided disk drive, an RS-232
communications port with a Hayes modem and IBM's PC DOS 2.0 (or higher).
To run in 360K it is necessary to recompile RBBS-PC -- see Appendix U.
Also if you choose to allow external file protocol transfers, an additional
192K of memory is required if you SHELL to them rather than EXIT.
Beginning with RBBS-PC version 13.1A, RBBS-PC requires version 2.0 or above
of IBM's Disk Operating System (DOS). RBBS-PC will not run under the BASIC
interpreter. RBBS-PC runs under MS-DOS to the extent that the executable
code generated by the IBM/Microsoft BASIC compiler is compatible with the
multitude of different MS-DOS's. RBBS-PC is generic, but some versions of
DOS do not work, such as remote drop to DOS under Tandy DOS.
If you have a second telephone installed specifically for RBBS-PC, ask for
a second voice grade telephone line. Data lines are very expensive and are
not necessary. The program requires the use of a Hayes Smartmodem (or one
that is 100% compatible) in order to function properly. If your non-Hayes
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 3-2
modem doesn't work with RBBS-PC, send RBBS-PC (source code and all) to the
vendor and ask him to explain why it doesn't work, if the modem is
compatible.
RBBS-PC's SUPPORT POLICIES Page 4-1
4. RBBS-PC's SUPPORT POLICIES
-----------------------------
4.1 RBBS-PC's User Support Methods
---------------------------------
RBBS-PC is supported as well as any commercial product and even better than
some, albeit in a different way. Rather than a single source for technical
support, RBBS-PC distributes its help via a network of volunteers. This
section outlines the many ways you can find assistance in setting up your
RBBS-PC
Written documentation with RBBS, which you are reading. This is more
a reference than a guide for novices, however.
A book, "The Complete Electronic Bulletin Board Starter Kit",
published by Bantam Books and available at B. Dalton Bookstores. This
book covers installing RBBS-PC in detail, although the version
discussed is 15.1C, so the book is now obsolete.
A commercial product, "RBBS-PC in a Box", a CD-ROM disc which has
thousands of shareware and public domain programs stored in compressed
format, and has RBBS-PC virtually pre-installed. You can be online
only minutes after installing the CD-ROM. For information and
ordering, contact Quanta Press, at (612) 641-0714.
Network mail. Both RBBS-Net and RelayNet have RBBS-PC support
conferences. For RBBS-Net, contract Rod Bowman (number listed below).
For RelayNet contact Greg Snyder (703-323-1782, data number).
Technical Support BBS. News, information, and answers to questions
about RBBS-PC are available at the following numbers:
(407) 487-3441
(407) 487-3442
Telephone support. When all else fails, you can place a voice call to
one of the authors. Since RBBS-PC SysOps should know how to use a
modem, voice calls usually should NOT be needed. The Technical
Support BBS is a much better medium for technical questions. However,
if you MUST make a voice call, dial (407) 852-7790. Usually, the
phone will be answered by a voice mail system. You can record
questions and call back later to hear recorded. Due to financial and
time limitations, we CANNOT return voice calls. Your best chance of
having a human answer the phone are between the hours of 7pm and 10pm
(Eastern U.S.).
Support Boards. Support boards are BBS's where the SysOp:
- commits to running RBBS-PC for the foreseeable future
- has an at least one free, public line
- is regularly available for helping others
- makes the latest version of RBBS-PC available, either
electronically or by mail
A list of support boards is included in the RBBS-PC package. Look at
the file "SUPPORT.BBS" in the default RBBS-PC directory. Please
realize that bulletin boards may cease to exist, or change their phone
numbers, and that other commitments can make people unavailable.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 4-2
Help by Topic: Ken Goosens maintains an interactive, on-line data base
of people who volunteer to help with RBBS-PC on particular topics.
Call Ken's BBS, and use the QUESTIONNAIRE function to search for
someone in your area who can help. Some of the topics listed are:
Auto Maintenance File Mgt System (FMS) Protocols
BASIC File maintenance Questionnaires
Batch Files HST Quick Basic
CD-ROM Hardware Setup
Communication LANTASTIC SmartText
Compiling Modems Startup
Conferences Network Sub-boards
Configuration Novell Netware Submenus
Desktop Publishing PC-Slaves Time Lock
DESQview PUI Uploads
Doors Personal downloads User Interface
DoubleDOS Programming Utilities
Most Bulletin Board Software is dedicated to making money for its authors.
No matter how much the authors love the work, it endures only so long as
the hope of income continues.
RBBS-PC is given away for free, and depends not on the flow of money, but
on the continuing dedication and generosity of people who volunteer to help
support and enhance it as a public service, and share their labor of love
with others for the benefit of all.
The commitment of the coordinating authors of RBBS-PC is to:
- fix any problems, on a priority basis
- steadily refine and enhance RBBS-PC to better serve the needs of its
users
- help support and coordinate contributions, testing, and releases
RBBS-PC should be bug free, period. If there are any problems with it, we
want to know. We want people to use RBBS, not because it is free, but
because it is the best bulletin board available.
Professional Tech Support: While RBBS-PC remains an "all-volunteer"
effort, BBSs run by corporations may find security in "paying" for
support. If your corporation desires 24-hour, quick-response help,
contact Doug Azzarito at (407) 852-7790. You will be referred to
someone who can offer a support plan that will satisfy any corporate
user.
4.2 RBBS-PC's Vendor Support Policy
-----------------------------------
While a great deal of care was taken to make RBBS-PC as flexible as
possible, supporting a wide range of computers and modems, the program was
designed with the IBM PC (or compatible) and Hayes Smartmodem (or
compatible) in mind. Many of RBBS-PC's default values assume this
combination, and it is certainly this combination which requires the least
effort to bring online.
The philosophy of RBBS-PC is outlined in section 1.1 of the RBBS-PC
documentation. Those who contribute to RBBS-PC do so without any hope of
monetary reward. In fact, great lengths are taken to assure that neither
those involved with the development of RBBS-PC, nor anyone who distributes
RBBS-PC's SUPPORT POLICIES Page 4-3
RBBS-PC, does so for personal gain or to promote a specific product at the
expense of other products.
If the hardware you are using is not part of the "base-line" hardware and
RBBS-PC doesn't work, your only recourse is to either modify RBBS-PC to
meet your particular needs (that's why the source code is distributed), or
contact your vendor and ask him to either fix his hardware or modify
RBBS-PC (via .MRG/.DOC files) to support his hardware.
Since 1984, RBBS-PC has become something of an "industry standard." As
such, several manufacturers have requested that support for their
particular hardware and/or software be incorporated into RBBS-PC. These
vendors have had three choices:
1. Obtain a copy of the BASIC source code by sending $8 to the Capital PC
User Group's Software Exchange. The source code allows the vendor to
determine what is required to be "RBBS-PC compatible." Who better knows
the quirks of the manufacturer's product than the manufacturer? RBBS-PC's
limited license specifically permits the distribution of ".MRG" files that
would allow RBBS-PC to run with whatever idiomatic quirks a specific
vendor's product exhibited. The advantage to the manufacturer is that they
are in complete control and need not make the .MRG "universal" (i.e. it
need only support their product). The disadvantage is that new releases of
RBBS-PC come out every six to eight months and the vendor would have to
review each release to make sure the new releases and his .MRG files were
compatible. Of course, as with any other RBBS-PC operator, casual
telephone support is available to these vendors.
2. Supply the necessary equipment or software on a loan or gift basis to
be used in the testing of future releases of RBBS-PC. This approach has
been actively DISCOURAGED for three fundamental reasons.
1. The vendor perceives he has "paid" for on-going support by the loan or
donation of the product. This is not the case because RBBS-PC's
development is an all-volunteer activity. As such, it is possible
that none of those involved with the development of RBBS-PC may have
the time or expertise sufficient to assure compatibility of the
specific vendor's product with future releases of RBBS-PC. About all
that can be done is to give the vendor our "best effort" to assure
compatibility, and advise when it can not be made compatible.
2. The particular product may not have a universal applicability to
RBBS-PC users and/or may not be of interest to those who regularly
contribute to the development of RBBS-PC. Both of these conditions
must exist before any vendor's product is incorporated into the
RBBS-PC development cycle.
3. The price of the loaned or donated products (usually 3 to 5 such
products) in no way can even begin to compensate for the hundreds (if
not thousands) of development hours required to support other than
"base-line" hardware.
3. Establish an on-going institutional commitment to maintain a dialogue
between the vendor's engineering group and the RBBS-PC development team
along with supplying the necessary equipment or software on a loan or gift
basis to be used in the testing of future releases of RBBS-PC. This
approach has been actively ENCOURAGED for three different and fundamental
reasons.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 4-4
1. The vendor overtly makes an institutional commitment to jointly
participate in the development of RBBS-PC. The vendor has the
opportunity to supplement the all-volunteer activity that is the basis
for RBBS-PC development by choosing to either modify their current or
future products to be compatible with RBBS-PC or to supply software
that ensures compatibility with RBBS-PC. This benefits all RBBS-PC
users.
2. The particular products that fall into this category are required to
have a universal applicability to RBBS-PC users (i.e. multi-tasking
DOS, networking, 2400 or greater baud capability, error-free
protocols, etc.). Also, a regular contributor to RBBS-PC's
development must be geographically located close to the vendor's
development engineers to assure a timely dialogue. Further, any
regular contributor to RBBS-PC's development who accepts the
responsibility for assuring RBBS-PC's compatibility with a particular
vendor's product must be willing to do so solely on a volunteer basis
over an extended period of time and in such a way as not to exclude
other vendor's products. Only when all these conditions exist is any
vendor's product a candidate to be incorporated into the RBBS-PC
development cycle. This assures that the RBBS-PC user community has a
feed-back mechanism to the vendor's product development and design
teams and the vendor is assured of a matching long-term commitment
from the RBBS-PC development team.
3. The vendor recognizes that the price of the loaned or donated products
(usually 3 to 5 such products) is minuscule compared with the hundreds
(if not thousands) of man-hours that may be required from both the
RBBS-PC development team as well as the vendor's engineers. This
assures that the vendors who choose this third approach are committed
to the PC user community. It is precisely this type of commitment
that RBBS-PC's USERWARE concept is designed to encourage (from both
users and vendors)
Many vendors have chosen to make this third type of commitment to RBBS-PC.
We hope each of them will continue their support. In turn, we hope RBBS-PC
SysOps and users will show their appreciation of the vendors' support.
Some of these vendors are (alphabetically):
Alloy Computer Products, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 481-7711
Corvus Systems, Inc.
2100 Corvus Drive
San Jose, California 95124
(408) 559-7000
Computer Peripherals, Inc.
667 Rancho Conejo Blvd.
Newbury Park, CA 91320
(805) 499-5751
The Forbin Project
(c/o John Friel III)
4945 Colfax Avenue South
Minneapolis, MN 55409
RBBS-PC's SUPPORT POLICIES Page 4-5
Hayes Microcomputer Products
5923 Peachtree Industrial Blvd.
Norcross, Georgia 30092
(404) 449-8791
IBM Corp
(Internal Zip Code 2900)
P.O. Box 1328
Boca Raton, Florida 33432
(305) 998-2000
Microcom, Inc.
1400A Providence Highway
Norwood, MA 02062
(617) 762-9310
Multi-Tech Systems
82 Second Avenue, S.E.
New Brighton, Minnesota 55112
(612) 631-3550
Orchid Technology
4790 Westinghouse Drive
Fremont, CA 94539
(415) 490-8586
PC-SIG
1030 E. Duane Ave Suite D
Sunnyvale, CA 94086
(408) 730-9291
Prometheus Products Inc.
4545 Cushing Parkway
Fremont, CA 94538
(415) 490-2370
Quarterdeck Office Systems
150 Pico Blvd.
Santa Monica, CA 90405
(213) 392-9701
Racal-Vadic
1525 McCarthy Blvd.
Milpitas, California 95035
(408) 774-0810
The Software Link, Inc.
8601 Dunwoody Place
Suite 336
Atlanta, GA 30338
(404) 998-0700
System Enhancement Associates
21 New Street
Wayne, NJ 07470
(201) 473-5153
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 4-6
U.S. Robotics, Inc.
Skokie, Illinois 60076
(312) 982-5010
Users who feel that they have benefitted or who appreciate such commitment
to the user community should write or call the above vendors and tell them
so, especially if such a commitment influenced the purchase of their
products. Similarly, if any user feels that other vendors should make a
similar commitment to RBBS-PC and the user community, write to that vendor
and send a copy of your letter to the following addresses:
Ken Goosens Doug Azzarito
5020 Portsmouth Road 2399 N.W. 30th Road
Fairfax, VA 22032 Boca Raton, FL 33431
Section 20 describes the RBBS-PC standard interface for protocol drivers.
All vendors of proprietary protocols who would like to have them added to
future releases of RBBS-PC need do is simply conform to this interface.
HOW TO GET A COPY OF RBBS-PC SENT TO YOU Page 5-1
5. HOW TO GET A COPY OF RBBS-PC SENT TO YOU
-------------------------------------------
RBBS-PC can be obtained by sending a check for $8 to the:
Capital PC Software Library
51 Monroe Stree
Plaza East Two
Rockville, MD 20850
RBBS-PC is distributed on 360K diskettes, unless otherwise requested.
Allow 3 to 4 weeks for delivery (remember, this is an all-volunteer
effort). Be sure to specify the version of RBBS-PC you want. If you would
like the RBBS-PC source code and some utilities that other SysOps have
found useful, send a second $8 with your order (a total of $16).
The current version of RBBS-PC can also be obtained by writing to:
Technology Consultants
P.O. Box 811985
Boca Raton, FL 33481-1985.
Please enclose a check for $10. (U.S.), which helps pay for disks and 1st
class postage (non-U.S. addresses, please enclose $25.). You will receive
complete RBBS-PC program, source code, and as many RBBS-PC utilities as
will fit on the media (specify 5.25" or 3.5" disks).
RBBS-PC's .EXE file is distributed after having been compiled with a
QuickBASIC Version 3.00 compiler which has had the DTR patch described in
Appendix G applied to it.
The exigencies of RBBS-PC software releases may mean that the disk you get
contains an earlier version of RBBS-PC (either you bought the diskette
sometime ago or there has been not enough time for it to be updated to this
most current version). Not to fear! Your money has not been wasted. The
support boards listed in section 4.1 should make the latest version
available for downloading.
You can also pre-order the next release of RBBS-PC, to be air mailed to you
immediately upon release, for $25. See Appendix C for details.
FILES RBBS-PC USES Page 6-1
6. FILES RBBS-PC USES
---------------------
There are essentially two types of files that RBBS-PC uses -- "system" and
"text" files. "System" files are defined as random files that RBBS-PC
reads and writes to. "Text" files are defined as files that RBBS-PC
primarily reads from. Text files can be edited externally to RBBS-PC with
almost any text editor. Either type of file can be "static" or "variable"
in length. By "static" it is meant that these files have a pre-defined
length beyond which RBBS-PC does not extend them. Similarly, "variable"
length files are defined as those files whose length is dynamically
increased by RBBS-PC. (In some RBBS-PC environments, only the "static"
length files can be shared SAFELY among multiple nodes.) The following
table summarizes these files, using the default file names:
"Static" Length Files "Variable" Length Files
MESSAGES (can be variable) CALLERS ARCWORK?.DEF
USERS COMMENTS NODE?WRK
MESSAGES.BAK DOUT?.DEF RBBS?F1.DEF
USERS.BAK DK*.ARC DORINFO?.DEF
RBBS?PC.DEF DRST?.DEF
99.DIR (upload directory)
The following "text files" are "static" in length and can be shared safely:
NEWUSER RBBS-CDR.DEF
MENU0 --> MENUA LG*.DEF
BULLET, BULLET1 --> BULLET? AUTOPAGE.DEF
DIR.DIR, aa.DIR --> bb.DIR CONFMAIL.DEF
CDR.CDR, aa.CDR --> bb.CDR RBBS-CDR.DEF
FILESEC PROTO.DEF
CONFENCE RBBS-REG.DEF
*.PUI PRELOG.DEF
PASSWRDS EPILOG.DEF
*.HLP PRIV.DEF
HELP?? AUTOPAGE.DEF
TRASHCAN RBBS?TM.DEF
WELCOME MAIN.NWS
In a CORVUS OmniNet network environment any of the "static" length files
can be shared on a common volume and ALL of the "variable" length files
must be segregated on volumes unique to each copy of RBBS-PC. RBBS-PC uses
a RENAME function in order to determine if a file exists. Because of this,
all the volumes accessed by any RBBS-PC in a CORVUS network must be
designated "read/write." Therefore, you must be very careful when running
CONFIG. CONFIG creates the definition file (RBBS?PC.DEF) for each copy of
RBBS-PC. See Appendix L for information regarding Corvus OmniNet).
The one file that cannot be shared is the Caller's file. RBBS-PC
continually logs to it and the activity of multiple users would get mixed
together.
LOCKED FILE STATUS DISPLAY
RBBS-PC displays the status of those files which must be locked in a
network environment on line 25. The lock status of the message file is
displayed in positions 68 & 69. The lock status of the user file is
displayed in positions 71 & 72. The lock block status is displayed in
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 6-2
positions 74 & 75 and comments/uploads share positions 77 & 78. The letter
"U" in the first position shows that the file is currently "UNLOCKED". The
letter "L" in the first position indicates that the file is "LOCKED".
6.1 RBBS-PC Directory Structure
-------------------------------
The RBBS-PC package contains many files, which can be put nearly anywhere
the SysOp desires. However, to avoid confusion, the default locations for
the RBBS-PC release files are grouped logically into subdirectories. If
the files are not placed in the proper subdirectory, RBBS-PC will behave
erratically until you reconfigure the file locations with CONFIG. The
directory is as follows:
DEFAULT DIRECTORY (usually C:\RBBS)
Contains RBBS-PC program, message and user files, INSTALL files
and operational .BAT files.
BULLETIN DIRECTORY (usually, C:\RBBS\BULLET)
Contains the RBBS-PC bulletins and bulletin menu files.
FILE CATALOG DIRECTORY (usually C:\RBBS\DIR)
Contains the files needed to maintain the list of files available
for download.
DOC DIRECTORY (usually, C:\RBBS\DOC)
Contains the RBBS-PC documentation.
FILE DIRECTORY (usually, C:\RBBS\FILES)
Contains the files available to download. Each SysOp will want
to expand this into a group of directories. Uploads may also be
placed in this directory.
HELP DIRECTORY (usually, C:\RBBS\HELP)
Contains all online HELP files for RBBS-PC, including help files
created by the SysOp.
FEATURE REMOVAL DIRECTORY (usually, C:\RBBS\LIT)
Contains utilities for removing features from RBBS-PC in order to
reduce executable code size.
MACRO DIRECTORY (usually, C:\RBBS\MACROS)
Contains the MACRO files which allow the SysOp to design custom
RBBS-PC commands.
NODE DIRECTORY (usually, C:\RBBS\NODE1)
Contains the files specific to each "node" of RBBS-PC. A multi-
node system will have several "node" subdirectories. Files in
this subdirectory include CALLER log files, RCTTY.BAT door
interface files, and timed-event semaphore files.
PERSONAL DOWNLOAD DIRECTORY (usually, C:\RBBS\PRIVATE)
Contains the directory file for RBBS-PC's personal download
feature.
QUESTIONNAIRE DIRECTORY (usually, C:\RBBS\QUESTION)
Contains the RBBS-PC questionnaire files.
SMALL EXECUTABLE DIRECTORY (usually, C:\RBBS\SMF)
FILES RBBS-PC USES Page 6-3
Contains a substitute RBBS-PC.EXE which has reduced error-
reporting, resulting in a smaller executable file.
SOURCE CODE DIRECTORY (usually, C:\RBBS\SOURCE)
Contains source code and .BAT files for recompiling RBBS-PC.
SYSTEM DIRECTORY (usually, C:\RBBS\SYSTEM)
Contains configuration files used to customize RBBS-PC, such as
the PASSWRDS, FILESEC, CONFMAIL and DOORS.DEF files.
TEXT DIRECTORY (usually, C:\RBBS\TEXT)
Contains text files seen by the callers, including MENU files,
WELCOME, PRELOG and LG*.DEF.
UTILITY DIRECTORY (usually, C:\RBBS\UTIL)
Contains several utilities for maintaining your RBBS-PC.
XFER DIRECTORY (usually, C:\RBBS\XFER)
Contains the files necessary to operate file transfer protocols,
including PROTO.DEF, and various protocol drivers.
Before moving any of these files, be sure you are familiar with the CONFIG
utility. If RBBS-PC cannot find a required file, the results are
UNPREDICTABLE! The default directory structure is only offered as a guide.
Each SysOp is encouraged to arrange files in a way that suits the SysOp's
taste.
6.2 RBBS-PC System Files
------------------------
As shown above, "system" files are both static and variable in length. The
system files used by RBBS-PC are:
MESSAGES Often named MAINM.DEF. This file is a random file that
contains the message text for the RBBS-PC system, and
several special records (e.g. checkpoint and node records).
The first record in the file contains the RBBS-PC
"checkpoint" record. The records immediately following this
first record are the RBBS-PC "node" records. From there,
the rest of the file consists of message header records
which are followed by the actual message text. Appendix A
describes these records, the fields within them, and how
each field is used. RBBS-PC expects the MESSAGES file to
exist, and to be in the proper format (CONFIG should be used
to create this file). When it loads, if CONFIG does not
find the MESSAGES file, or it finds one in pre-12.3A format,
CONFIG will create it and initialize it to the size the
SysOp has specified. Because of the special fixed length
records in this file, it should not be created or edited
outside CONFIG.
When the SysOp "packs" the message file using CONFIG, the current message
file is preserved as MESSAGES.BAK, in case the "pack" is unsuccessful (i.e.
not enough space to duplicate the message file). If the disk fills up
during the pack function, RBBS-PC can recover the message file using
MESSAGES.BAK. When the message file is successfully packed, the original
MESSAGES file is renamed MESSAGES.OLD, and MESSAGES.BAK is renamed
MESSAGES. CONFIG will ask whether you want to delete the old MESSAGES
file. (Note that, in a multiple RBBS-PC environment, the message file
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 6-4
should only be "packed" when none of the nodes are running.) The MESSAGES
file can be shared among multiple RBBS-PCs.
USERS Often named MAINU.DEF. The USERS file is a random access
file that has a record for each user of the system. The
record contains a profile for each user who has logged onto
RBBS-PC. Appendix A describes the format of the records
within the USERS file. These records are 128 bytes in
length and are automatically maintained by RBBS-PC. The
SysOp can do some limited editing using SysOp Function 5.
RBBS-PC expects the USERS file to exist, and to be in the
proper format (as with the MESSAGES file, CONFIG should be
used to create this file). If CONFIG does not find the
USERS file on the system when it loads, it will create it to
the size specified by the SysOp. The USERS file should not
be created or edited outside CONFIG (with the exception of
certain utilities specifically designed for this task --
under NO circumstances use a text editor to edit the USERS
file).
When the SysOp "packs" the user file using CONFIG, the current USERS file
is preserved as USERS.BAK, in case the "pack" is unsuccessful (i.e. not
enough space to duplicate the users file). If the disk fills up during the
pack function RBBS-PC will recover the USERS file from USERS.BAK. When the
users file is successfully packed, the original users file is renamed
USERS.OLD and the temporary file USERS.BAK is renamed USERS. CONFIG will
ask whether you want to delete the old USERS file or not. (Note that in a
multiple RBBS-PC environment, the USERS file should only be "packed" when
none of the nodes are running.) The USERS file can be shared among
multiple RBBS-PC's.
CALLERS This file is a random file that contains a log of all your
caller's activities as they use the system. This is an
ASCII file, but it is formatted as 64 byte fixed length
records with no carriage returns or line feeds between the
records. If you set the "extended logging" feature of
RBBS-PC to be on, then a more detailed record of each
caller's activity will be kept. There are many "statistic"
and "bulletin" generating utilities which have been written
to work with the CALLERS file. If the CALLERS file is not
found, RBBS-PC will create a new one (no need for CONFIG
here). To clear the log, ERASE the file. The CALLERS file
can't be shared among multiple nodes, because activity from
the various nodes would be mingled together in the file,
making it impossible to determine who did what, and when.
ARCWORK?.DEF This file is created as output by the file view command and
contains the contents of the archived file being inquired
against. The node number replaces the wildcard "?".
BULLET.FCK This file is used to find new bulletins when NAMED bulletins
(rather than numbered bulletins) are used. It should
contain a list of NAMED bulletin file names, one per line.
Numbered bulletins are automatically checked by RBBS-PC.
COMMENTS This file is a sequential file that contains any comments
that have been left by users for the SysOp. The file can be
scanned by a SysOp function, or it can be TYPEd or edited
FILES RBBS-PC USES Page 6-5
outside the RBBS-PC system. A SysOp function is available
to delete this file. The file will be created by RBBS-PC if
it is not found. The COMMENTS file cannot be shared among
multiple RBBS-PC's using CORVUS' "OMNINET", but can be
shared using other multi-user systems.
Please note that if you have activated the CONFIG parameter which tells
RBBS-PC to store Comments to the SysOp as privates messages to the SysOp,
then this file will not be used.
DK*.ARC These files are created as output by the Library Sub-System
archive program. These work files are deleted each time
RBBS-PC recycles.
DOORS.DEF This is the "doors control file" used by RBBS-PC to allow
the SysOp more control over access to doors. See section
14.3.
DORINFO?.DEF This file is created by RBBS-PC when a caller exits to a
DOOR. It contains information about the caller needed by a
"DOOR" (see section 14.2.2).
DOUT?.DEF Used by doors to communicate back to RBBS-PC.
DRST?.DEF Internal file used by RBBS-PC to restore itself upon return
from doors.
NODE?WRK This file is created by RBBS-PC when a caller exits to an
external protocol to do "batch" downloads. It contains a
list of fully qualified file names to be downloaded.
QMXFER.ERR This file is created as output by QMXFER.COM to notify
RBBS-PC of the results of an external file protocol
transfer.
RBBS?F1.DEF This is the file dynamically created when the local SysOp
exits to DOS.
RBBS?PC.DEF This is an ASCII text file created as output by the CONFIG
program. It contains the configuration parameters for
RBBS-PC. Each time RBBS-PC is run, it reads from this file.
In a multiple RBBS-PC environment, the node definition file
for each RBBS-PC is named RBBSxPC.DEF (where "x" is a number
1 to 9, 0 meaning the tenth node, and A through Z for the
11th through the 36th node). In a single user RBBS-PC
environment, the name will be RBBS-PC.DEF.
While this file CAN be edited with a text editor, and many experienced
RBBS-PC SysOps do this, you might have difficulty determining which
parameter is which and how the various parameters work together. Unless
you are QUITE SURE of what you are doing, we recommend that you use CONFIG
to alter your RBBS-PC.DEF files.
99.DIR The is the default filename for the file RBBS-PC builds to
hold the name, file size, date, and description appended to
it of files that have been uploaded. The 99.DIR file cannot
be shared among multiple RBBS-PC's using CORVUS's "OMNINET",
but can be shared on other multi-user systems.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 6-6
6.3 RBBS-PC's Graphics Support
------------------------------
RBBS-PC can display three different "flavors" of text files:
- Non-graphic text, consisting of the 128 ASCII characters
- Graphic text, consisting of the 256-character IBM character set
- ANSI color graphics, which include ANSI terminal commands to display
color, position text on the screen, and play music.
The "flavor" seen is based on the user's current graphics option (which can
be changed with the Graphics command on the Utility menu). In order for a
user to see either Graphics or ANSI color, the following items must have
occurred:
- The caller must have logged on with 8 bit word, no parity, and 1 stop
bit.
- The caller must have selected graphics (either "ASCII" or
"Color-IBM"), and the file must exist with a filename ending in
either:
"G" For Graphic files, or
"C" For ANSI Color files
- The caller's hardware and software must support the "flavor" selected.
All IBM PCs and compatibles support Graphics, and most will support
ANSI Color, if the right device driver is loaded on the caller's
system.
RBBS-PC will check to see if a "graphics" file exists by appending a "G" or
"C" to the file name (e.g. MAINC.NWS instead of MAIN.NWS). If such a file
can't be found, RBBS-PC will check to see if a non-graphics file exists
(i.e. one without the "G" or "C"). RBBS-PC will display the first file it
finds.
6.4 RBBS-PC Text Files
----------------------
The RBBS-PC "text" files are both static and variable in length. The
"text" files used by RBBS-PC are:
AUTOPAGE.DEF This is a text file setup by the SysOp that informs RBBS-PC
of which caller, callers, or group of callers that the
system should automatically "page" the SysOp as soon as they
log on. See section 7.11.
BULLET This is a text menu file that describes the BULLETINS
available on RBBS-PC. It is displayed following the WELCOME
file when a user first enters the system. It must be
present if CONFIG parameter 43 is greater than 1. It can
also be called from the main menu with the B)ulletins
command.
BULLET1 --> BULLET99
There can be 1 to 99 numbered "bulletins", and virtually
unlimited named bulletins. RBBS-PC will check for the
existence of a file whose name consists of the prefix given
by parameter 44 of CONFIG appended with the bulletin number
and using parameter 41 of CONFIG to determine the drive to
find the bulletin on.
FILES RBBS-PC USES Page 6-7
CONFENCE Displayed to users who issue the J)oin function from the
main menu. It can be created by any text editor that can
create an ASCII file and should contain a list of the
available conferences.
CONFMAIL.DEF This is a text file setup by the SysOp to notify callers of
the mail they have waiting in specific (or all) conferences.
See section 18.
DIR.DIR, *.DIR
The DIR.DIR file, which can be renamed using the CONFIG
utility, is a text file which contains a listing of all the
categories in your FMS.DIR (FMS = File Management System,
see section 12). Each of these categories has to be linked,
via a code, to the entries in the FMS.DIR file, and this is
done via the DIR.CAT file.
If you are NOT using FMS-style directories, but rather want your file
catalogs to be normal ASCII text files, then you need to create a separate
file for each category listed in DIR.DIR. Each listing will be in a file
*.DIR, where the wildcard "*" is the category code from DIR.DIR.
The DIR.DIR file is not optional, since whether you're using FMS-style
directories or not, you still need to present your list of categories to
the caller. Using FMS-style directories allows you to keep all the
downloadable files listed in one big file (or several smaller ones), and
use category "codes" within that file to group them. Without FMS, each
category code has to be its own "directory".
DIR.CDR, *.CDR
At least one DIR.CDR file has to be present on one of the
drives available for downloading if the Library Sub-System
support has been activated. Alternative directories, *.CDR
should be reflected in the DIR.CDR file.
EPILOG.DEF This is the default name for the questionnaire that is shown
to users as they log off. It can be either an extensive
"poll" (which frequent users would find tedious) or a simple
thank you. Or, you omit this file entirely.
FILESEC This file controls which security levels can download from
which paths, and it is more fully described in section 15.4.
HELP There is a help file for each command which has the format
xy.HLP, where x is the first letter of the section (M,F,U)
and y is the command letter, except for global and SysOp
commands, which have the format y.HLP. There are also the
following special help files:
HELP03 Describes the message protection options when <?> is entered
after the message <E>nter command is executed at the main
message menu.
HELP04 Describes the message entry subfunctions when <?> is entered
at the subfunction prompt.
HELP07 Describes the message read options when <?> is entered while
reading messages.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 6-8
HELP09 Displayed when <H>elp is requested for the type of graphics
a user wants (none, ASCII, color/music).
FILE.HLP Displayed when <H>elp is entered in the files subsystem
function prompt.
LIBR.HLP Displayed when <H>elp is entered within the library
subsystem.
MAIN.HLP Displayed when <H>elp is requested on the main function
prompt. It contains command information.
RGXPIRD.HLP Displayed to users when their registration has expired. See
section 9.
RGXPIRE.HLP Displayed to users when their registration is about to
expire. See section 9.
SECVIO.HLP If this file is present, it is shown to the caller each time
a security violation occurs.
SMARTTXT.HLP Illustrates the use of embedded commands within any text
file displayed by RBBS-PC that causes the text to appear
personalized to the caller. See section 7.9 for a more
complete description of this feature.
UPCAT.HLP Used to help users categorize their uploads.
UTIL.HLP Displayed when <H>elp is requested in the utility subsystem
function prompt.
LG*.DEF This is the file displayed, if present, to users based on
security level when the caller logs on. The wildcard "*" is
the security level of the users who would see this file.
For instance, this allows the SysOp to provide an
explanation for callers whose security level falls below the
minimum to log on, or it can also be used to provide a
"personalized" welcome to users who have a specific security
level. Some examples are:
Security File name Sample text for level greeting file
Level
9 LG9.DEF "Hi, nice to have another SysOp call in."
6 LG6.DEF "Registered users are the most appreciated."
4 LG4.DEF "Too many security violations."
-1 LG-1.DEF "Your behavior has been inappropriate."
-9999 LG-9999.DEF Special "BBS verification" message for the U.S.
BBS listing (Appendix B).
FILES RBBS-PC USES Page 6-9
MAIN.NWS The "news" file for the main message base. If you rename
your users and messages to XYZU.DEF and XYZM.DEF, then
"XYZ.NWS" would be the news file. See section 7.13.
MAIN.PUI This is the programmable user interface file that allows the
SysOp to structure the RBBS-PC commands as desired. See
section 7.6 for a description of the PUI.
MENU* These contain the local SysOp menu and menu of various
commands for the subsystems.
NEWUSER This is a text file that is displayed for new users just
before registration occurs.
PASSWRDS This file controls which security levels get which
privileges, and is more fully described in section 15.3.
PRELOG Displayed to callers prior to asking for their first/last
name and password.
PRIV.DEF This file contains the information used for "personal
downloading", described in section 12.7.
RBBS-CDR.DEF A text file that contains the disk numbers, paths and disk
titles of disks available to the Library subsystem. The
format of the file is described in section 12.6. The
RBBS-CDR.DEF (and matching FMS directory) file can be
downloaded from Doug Azzarito's BBS. It is not distributed
with RBBS-PC because of it's size (500K).
RBBS-REG.DEF This is the default name for the questionnaire that is asked
of all new users who log on. The "new user" questionnaire
is only seen once, by new users. This file is optional.
TRASHCAN A text file that contains names that the SysOp finds
objectionable and does not want used as either a users first
or last name. RBBS-PC uses this file, if it exists, to deny
access to anyone using one of these names for either their
first or last name.
WELCOME A text file that a user first sees upon logging onto the
system. Similarly each "conference" can have a "welcome"
file by having a file whose last character ended in a "w"
(i.e. conference "RBBS" would have a message file named
RBBSM.DEF and a user file named RBBSU.DEF if it where a
"private" conference and a welcome file named RBBSW.DEF).
PLANNING YOUR USER INTERFACE Page 7-1
7. PLANNING YOUR USER INTERFACE
--------------------------------
RBBS-PC provides each SysOp the maximum control over what is presented to
callers. There are three areas of control:
- The menus presented to novice callers.
- What is included in the prompt all users get.
- What symbol invokes a particular function.
7.1 Taking User Input: Help, Command Stacking, and Hotkeys
-----------------------------------------------------------
RBBS-PC tries hard to make the BBS helpful and intuitive to the novice,
without straightjacketing and frustrating the expert BBS user. Callers
can declare themselves to be "experts" or "novices". Novices get
o fuller words displayed in prompts
o menus automatically display that explain choices.
Menus are generally not displayed to experts unless specifically requested
by entering "?", and options are usually reduced to a single letter like
"E" rather than words like "E)nter msg". The general idea is that after
you get familiar with the BBS and learn what the options mean, the more
experienced user can operate faster with less prompting. In most all
contexts, "H" can be entered to ask for extended help - usually, the
display of a special help file for than context.
RBBS-PC also supports having a "default" choice gotten by just pressing
Enter. This will be indicated in the prompt by enclosing it in square
brackets, such as "[Y]es". If you have highlighting on, the default will
also be highlighted in color.
Many options in RBBS-PC require only the selection of a single character.
The caller can elect to have RBBS "run" with any key pressed rather than
wait for Enter to be pressed by electing to use "Turbokeys" as a user
preference. With turbokeys off, the BBS waits for Enter to be pressed
before trying to execute a command. The pause for Enter is an extra
delay, but gives the caller time to reflect on whether the choice is right
and make any needed corrections. The user can elect to go with the
speedier but more error prone hotkeys option. RBBS-PC lets the user with
turbokeys on know that a single keystroke is expected and will run with any
response by making the prompt end in "!". Prompts expecting more than one
keystroke and waiting for Enter to be pressed end with the normal "?".
The fastest and most powerful way for the expert user to respond to RBBS-PC
is to use "command stacking". Here, on the single line the user types in
a response to a prompt even before the prompt is displayed. Experienced
callers know in advance what they will be asked next and can stack their
responses in advance. The advantage of command stacking is that the
prompts and menus will never even be displayed. The first opportunity to
use command stacking is on the logon, where rbbs will typing ask:
What is your FIRST name? John
What is your LAST name? Doe
Enter your password? secret
The answers can be stacked as follows:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-2
What is your FIRST name? John Doe secret
A special feature within command stacking on logon is what is known as
"turbo logon". The "!" as the 4th parameter means to "turbo logon" and
simply blow by all the prompts and reports - welcomes, news, uploads - and
jump immediately to the main command line. Stacking can continue even for
this main command line, as in
What is your FIRST name? John Doe secret ! r m s
to Read My mail Since last on. Notice that this feature makes it very
easy to automate or script interactions with RBBS-PC. For example, if all
you want to do is to download file1 and log off, a single command to do
that would be
What is your FIRST name? John Doe secret ! f d file1 z /g
The "/g" is a command modifier than can be entered at the end of any
command and means to log off if the previous commands execute successfully.
RBBS should support command stacking universally and up to 255 levels deep,
using the general principle that a future prompt can be pre-empted and the
answer given in advance by typing what you would enter to the prompt on the
command line as a word. For example, at the main command line "q u t t"
will Quit to Utilities, and Toggle Turbokeys. If you need to stack a
space as part of the prompt, using ";" as a separator between your
responses. Thus, "e;tom jones" could say to E)nter a message to "Tom
Jones". Whereas "e tom jones" would be interpreted to E)nter a message to
"Tom" with subject "jones", since the prompt for subject occurs right after
who the message is to.
Finally, if you are in turbokey mode and would like to stack, begin your
command with "/". This will temporarily suspend turbokeys for this one
command and wait for Enter.
7.2 Menus Shown to Callers
--------------------------
The menus in RBBS-PC are external text files that are presented to novice
users. RBBS-PC simply displays what is in these files to the callers.
Therefore, SysOps are free to change the text in these files to whatever
they desire. Simply edit the files. However, be sure to use an editor
that produces only ASCII text files with no special embedded characters.
Most word processing editors are not suitable because they insert special
symbols in the file meaningful only to it. Menus can also contain graphics
and color (see section 6.3).
7.3 Subsystem Prompts Shown to Callers
--------------------------------------
RBBS-PC has several configuration options which allow each SysOp to select
the prompts that are presented to callers. They are:
- Whether the section name is displayed.
- Whether the letters of the available commands are shown.
The commands in RBBS-PC are divided into four sections: MAIN, FILE,
UTILITY and LIBRARY. If RBBS-PC is configured to display the section name,
the command prompt will read "<section> command", otherwise "Your command".
The section name is shown by default.
PLANNING YOUR USER INTERFACE Page 7-3
RBBS-PC normally prompts a caller with the commands the caller has
sufficient security to invoke. Each command is a single letter and is
shown separated from the others by a comma. The command letters can be
suppressed in the prompt. By leaving them on, a SysOp provides each caller
with a terse but helpful reminder of what commands are available to them.
7.4 Commands Available to Callers
---------------------------------
All primary commands in RBBS-PC are invoked by single letter commands. An
attempt is made to associate the command with the first letter in a word
which describes the function, so that the command letter appears to be a
short abbreviation for the longer word. The command to invoke reading
messages is R. The default symbols that would be shown in the command line
for each section are:
sect |? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y 1 2 3 4 5 6 7
-----|-------------------------------------------------------------------
MAIN |? @ A B C D E F H I J K O P Q R S T V W X 1 2 3 4 5 6 7
|
FILE |? D G H L N P Q S U V X
|
UTIL |? B C E F G H L M P Q R S T U X
|
LIB |? A C D G H L Q S V X
|
GLBL |? H Q X
Four commands, ? H Q and X, have the same meaning in every section and are
known as "global." The other commands all have unique function specific
for the section within which they are invoked. For example, S stands for
S)can messages in MAIN, S)earch in FILE and LIBRARY, and S)tatistics in
UTIL. Symbols 1-7 are used for SysOp functions.
RBBS-PC allows the SysOp to substitute any symbol for any command. Y)ell
may be substituted for O)perator page, or Y)our mail for P)ersonal mail.
If a blank is substituted, the command is removed from the list and is no
longer available.
7.5 RBBS-PC's "Wrap-around" Command Search
------------------------------------------
There is an option in CONFIG which gives the SysOp unusual flexibility in
configuring the user interface. A caller is always "in" a section.
RBBS-PC considers the user's current section when acting on commands. The
"wrap around" option allows RBBS-PC to look further for a command when it
is not found in the section the caller is in. If a SysOp substitutes a
blank for the V>iew conference command in the main section (as mentioned in
section 7.3) and a user enters the V command from the main section, the
V)iew archive file command would be what the caller would have invoked.
The fundamental idea is to look further in other sections, where the search
order is circular, starting at the current section, and proceeding in the
following order:
-MAIN->FILE->UTIL->LIBRARY->GLOBAL->SYSOP-
| |
-------------------<----------------------
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-4
If wrap-around is used, RBBS-PC will search ALL sections, in order, to find
a valid command that matches the user's input. Even if wrap-around is not
used, GLOBAL and SYSOP commands are processed globally.
The important feature that wrap-around supports is that a command with a
unique letter works in all sections. Thus W)ho will work everywhere if
wrap-around is enabled. If every RBBS-PC command is given a unique symbol,
all commands become global and there is no effective difference between
sections. This allows SysOps to make commands available on a single level
and makes it unnecessary to "go" to a section before using a command in
that section.
7.6 How to Have a Single Universal Command Line
------------------------------------------------
The command structure within RBBS-PC can be made "flatter" without making
it absolutely flat. Suppose, for example, that a SysOp wants callers to be
able to do all file functions without going to a files section. In effect,
the file functions are available in the main section, or the file section
is merged into the main section. To do this, the SysOp must eliminate the
overlap in command letters between the two sections.
The main section and the file section share the letters D, P, S, and V. V
is used to "view" a conference in the main section and "view" what is
contained in an archived file. D is difficult because both D)oors and
D)ownload are entrenched and natural options. One could leave D for the
most frequently used function, say download, then use a special but
arbitrary symbol like # for doors. Similarly, V could be left for viewing
conference mail in the main section and a special but arbitrary symbol like
& for viewing archived files in the file section. S)earch for substrings
could be replaced by F)ind since F for going to F)iles is no longer needed.
This could be accomplished by disabling F)iles and substituting F for S in
the files commands.
P is used for personal mail in the main section as well as personal files
in the file section. Leaving P in the main section for personal mail and
selecting the symbol M for personal mail in the file section would have the
least impact on callers.
U is used for upload. Since Quit may be used to go to UTIL, we can disable
U in the main menu. We can use W for W)rite user preferences and F to find
who else is on (since the F for FILES section is no longer needed). We
could then revise the main menu to read:
R B B S M A I N M E N U
~~~~~~~~~~~~~~~~~~~~~~~~~~~
[A]nswer survey [H]elp (or ?) [P]ersonal mail [U]pload a file
[B]ulletins [I]nitial welcome [$]Personal files [V]iew conference mail
[C]omments [J]oin conference [Q]uit [&]View files
[#]DOORS [K]ill message [R]ead messages [W]rite user pref
[D]ownload [L]ist files [S]can messages [X]pert on/off
[E]nter msg [N]ew files [T]opic msg scan [Z]ippy search
[F]ind who's on [O]perator page [@]Library
[G]oodbye
Obviously the limitations of using a single section (as the more primitive
bulletin board systems do) means that the number of commands must be
restricted to either
PLANNING YOUR USER INTERFACE Page 7-5
- 26 (letters in the alphabet), or
- 36 (letters in the alphabet plus the numbers 0 through 9), or
- full "words".
With this artificial limitation of a single section, commands become
limited in number, cryptic, or both. If the even more clumsy use of full
"words" is chosen, the system must slow down as it can no longer act
immediately upon seeing the first character of a command as RBBS-PC does.
However, assuming that someone would actually want to configure RBBS-PC to
be "flat" (i.e. have a single command line), let us continue. In order not
to confuse the caller by being in a section and seeing only some of the
commands we want him to use, the SysOp could elect not to show the section
in the prompt (CONFIG parameter 37) and not to show the commands (CONFIG
parameter 38). Callers would see simply "Your command?" as the prompt.
This makes the expert mode quite terse, but that simply means users would
spend more time in novice mode before using expert.
Now suppose that only a single command line was desired and that the
commands from the "Utilities" menu commands were to be added to the above.
The "global" H, ?, Q, and X commands already are in the single command
line.
M for message margin can remain unchanged since it is unique to the
Utilities subsystem.
In order to accommodate the redundancy of letters that exist by including
the Utilities subsystem's commands, the W command for the main message
subsystem can be re-enabled and the remote SysOps commands be eliminated in
order to re-use the numbers. The Utilities subsystem commands B, C, F, G,
L, R, and S could then be replaced by the numbers 1 through 9. The
Utilities subsystem commands T, U, E, and P could be replaced by the
commands <, >, \, and !, respectively.
This final menu of all RBBS-PC commands could be re-written without any
apparent sub-sections as follows and the screen that would appear to the
"novice" users as:
R B B S C O M M A N D S
~~~~~~~~~~~~~~~~~~~~~~~~
[A]nswer survey [O]perator page [1] Bank Time
[B]ulletins [$]Personal files [2] Display time of day
[C]omments [P]ersonal mail [3] Set file transfer protocol
[#]DOORS [Q]uit [4] Set type of graphics mode
[D]ownload [R]ead messages [5] Set page length
[E]nter msg [S]can messages [8] Review callers preferences
[G]oodbye [T]opic msg scan [9] Display system statistics
[H]elp (or ?) [U]pload a file [<] Toggle users options on/off
[I]nitial welcome [V]iew conference mail [>] Show the log of callers
[J]oin conference [&]View files [@] Library
[K]ill message [W]ho's on other nodes [\] Change echo selection
[L]ist files [X]pert on/off [!] Change password
[M]argin set [Z]ippy search
[N]ew files
Your command?
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-6
7.7 RBBS-PC'S Programmable User Interface (PUI)
-----------------------------------------------
The programmable user interface (PUI, pronounced "pee you eye") lets the
SysOp take TOTAL CONTROL over what the caller is presented with, including:
- the novice menu
- the prompt line
- the organization of commands into groups (sections)
- the flow between sections
- unlimited levels of nested menus.
This allows the RBBS-PC interface that the caller sees to take on any
appearance desired by the SysOp. In effect, the SysOp is limited only by
the intrinsic functions of RBBS-PC that have been programmed into RBBS-PC
source code. These functions can be assigned any command letter desired in
CONFIG. PUI lets the SysOp completely control how these commands are
presented to the user - allowing RBBS-PC to "emulate" virtually any other
host communications environment that the SysOp's callers may be familiar
with.
If no PUI is provided, RBBS-PC defaults to dividing the commands into a
MAIN, FILES, UTILITIES, and LIBRARY section.
RBBS-PC's PUI gives each SysOp the flexibility to tailor RBBS-PC to meet
special needs. In effect, RBBS-PC's PUI allows the SysOp to adjust RBBS-PC
to what the SysOp wants, rather than forcing the SysOp and his callers to
conform to RBBS-PC.
However, unlike RBBS-PC, the PUI does not adjust the prompt to show only
the commands that the user has sufficient security to do. And, of course,
PUI takes much more time to design and implement.
When the SysOp takes control of what the user is presented by using the
PUI, RBBS-PC does what the SysOp has explicitly set up -- and nothing else!
For example, RBBS-PC's "global" commands, like help and the expert toggle,
are no longer automatically available everywhere. They are available only
where the SysOp has indicated via the PUI.
RBBS-PC's default user interface has evolved over the years to represent
what the callers found useful (not the SysOps!). A great deal of time and
thought went into RBBS-PC's default user interface, and it is easy to
overlook important things when a SysOp goes about setting up his or her
own. When using the PUI assume that a new user interface will take time to
both develop and refine (based on your callers feedback). Designing and
implementing a PUI is not a simple undertaking as it is a total replacement
for RBBS-PC's standard user interface.
7.7.1 An Example Using PUI
--------------------------
The main menu in RBBS-PC can represent a bewildering variety of commands,
especially to a new user. Studies show that human beings can effectively
deal with at most 7 choices at one time, whereas RBBS-PC has 10 more than
that in its main section. To help people in this situation, the different
choices in RBBS-PC are grouped into related commands, but the choices can
still be overwhelming. Some SysOps have tried to simplify the main menu by
breaking it up into more sections. The most tempting group of commands to
spin off are the message commands. Suppose the main menu is to be
simplified to look like:
PLANNING YOUR USER INTERFACE Page 7-7
<F>iles
<M>ail
<U>ser preferences
<G>oodbye
The <M>ail command puts the caller in a section where commands related to
messages become available in yet another menu, such as J)oin and E)nter.
PUI is required because the commands are grouped into different sections.
While the default menu of RBBS-PC could be edited to say this, the
underlying commands would not be grouped as desired.
7.7.2 How to Implement PUI
--------------------------
First, plan carefully on paper exactly what you want the caller to see and
what happens with each command. Consider also, if you have a submenu, how
users are to get out of it.
Each menu or section of PUI is controlled by a file whose extension is
"PUI". The PUI is installed by putting a "main" PUI file whose name is
specified in CONFIG. The default is "MAIN.PUI". Each sub-board in RBBS-PC
can have a different PUI system if desired. A PUI file consists of exactly
10 lines, and the format is:
LINE CONTENTS
1 name of novice menu
2 prompt to display
3 valid commands, corresponding RBBS-PC commands
4 which valid commands are menus
5 names of PUIs that are menus
6 letter of quit command
7 prompt for quit command
8 valid sub-commands of quit command
9 which quit commands are PUIs
10 names of menu PUIs in quit command
The text in the lines should NOT be enclosed in quotes, except possibly the
two parts of line 3.
The novice menu is just a text file displayed to novices, just like the
default menus (MENU1, MENU2, etc.). The name can include a drive or path
as well as an extension. The menu PUIs in lines 5 and 10 must be stored in
the same drive/path as that in line 1.
The prompt to display is what all callers see when asked for a choice,
including experts. Normally this includes a brief listing of the commands
available along with a request for a command. This prompt is NOT
dynamically adjusted to reflect the security level of the caller, unlike
the default prompt in RBBS-PC, which removes commands the caller cannot
execute.
Each PUI defines a "section" of RBBS-PC (just like RBBS-PC has main, file,
library, and utility sections). The valid commands are the symbols for the
acceptable commands in this PUI section. They must be upper case only.
The first part is the names of the commands that the caller must give.
Each symbol must be mapped to a corresponding internal symbol name in
RBBS-PC which is set in CONFIG. This way the same letter in a given menu
can be used for different commands in RBBS-PC, just as "S" stands for S)can
messages in the main section and S)ubstring search in the files section.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-8
Since the default underlying RBBS-PC commands use the same letter in
different menus, you should first reconfigure RBBS-PC to assign each
RBBS-PC command a different underlying symbol. Then in the PUI file map
the letter you want the caller to use to that underlying symbol. Be sure
in configuration NOT to limit commands to the current section -- you must
let RBBS-PC search in other sections for underlying commands when it does
not find it in the current section.
In addition to the normal commands available in RBBS-PC, the SysOp can
include new commands which invoke other menus. These must be symbols in
the list of valid commands.
If a valid menu choice is picked, there must be a PUI file for that choice.
Line 5 tells what prefix the PUI file has. Each PUI name must consist of
exactly 7 characters. The PUI name can be shorter than 7 letters, but in
the list you must blank fill out to 7 positions to the right. The first 7
characters are for the first valid menu command, the second 7 characters
are for the second valid menu command, etc. RBBS-PC will automatically
append the extension "PUI" to this file name. Note that all PUI files must
be in the same drive/path as the novice menu in line 1.
The last 5 lines in the PUI file concern how control goes from one PUI to
another. The PUI processing supports a "quit to" command in which the
caller can jump to other menus - which one is specified in the subcommands
to the quit command (just like RBBS-PC's "quit" to command).
Line 6 is the symbol (in the valid commands) which is the quit-to command.
It must be a single capital letter.
Line 7 is the prompt for the quit-to command, to be presented to callers
after they select the quit-to command (type ahead is supported).
Line 8 is the list of the valid sub-commands of the quit-to command. Each
command must be a capital letter.
Line 9 tells which of the valid subcommands are PUI commands. If a
sub-command is valid but not a PUI command, control will be passed to
RBBS-PC to process the quit-to command. For example, Quit-to S)ystem for
hanging up would have to be processed this way.
Line 10 tells what are the names of the PUI files for each PUI command in
line 9. The format of the PUI names is exactly the same as in line 5 -- 7
characters blank filled to the right if shorter.
The following file MAIN.PUI installs the example that was discussed in the
previous section:
MMENU
Enter choice: <F,M,U,G>
FGMU," G "
FMU
FMENU MAILM UMENU
<5 blank lines follow>
The name of the menu to be displayed initially is MMENU. The prompt users
will see is "Enter choice: <F,M,U,G>?" (RBBS-PC adds the trailing "?" for
prompts). The four valid commands are F, G, M, and U. Three of these
commands invoke other menus (F, M, and U), and G is a non-menu command,
PLANNING YOUR USER INTERFACE Page 7-9
i.e. one of the base RBBS-PC functions. The PUI file name for "F" is
FMENU.PUI, MAILM.PUI for "M", and UMENU.PUI for "U". Each of these PUI
files gives the same type of information as the main PUI. For example,
MAILM.PUI might contain
MAILM.MNU
Enter choice: <E,J,P,Q,R,S,T>
EJPQRST,EJPQRST
Q
MAIN
<5 blank lines follow>
The novice menu for the mail section is in file MAILM.MNU. This file might
contain the following text:
M A I L S U B S Y S T E M
~~~~~~~~~~~~~~~~~~~~~~~~~~~
E)nter a message
J)oin a new message base
P)ersonal mail (review)
Q)uit to main section
R)ead messages
S)can msg headers
T)opic msg scan
The prompt will appear immediately below this line unless an extra blank
line is included in the menu file. There is only one menu command: Q for
getting back to the main menu.
The PUI system can also be used to emulate the default RBBS-PC commands
with 4 sections. Four sample files are provided for accomplishing this:
XMAIN.PUI, XFILE.PUI, XUTIL.PUI, and XLIBR.PUI. For novice menus, each
uses the standard default menu that comes with RBBS-PC. These require
RBBS-PC to be configured with the following symbols for the underlying
RBBS-PC commands:
MAIN = normal: ABCDEFIJKOPRSTUVW
reconfigured: ABC>EFIJKOPRSTU\W
FILES = normal: DGLNPSUV
reconfigured: DGLNYZ^V
UTIL = normal: BCEFGLMPRSTU
reconfigured: !#E$<&M*()-+
GLOBAL = normal: H?QX
reconfigured: H?QX
SysOp = normal: 1234567
reconfigured: 1234567
LIBRARY =normal: ACDGLSV
reconfigured: []{G}:'
7.8 RBBS-PC's Support of Sub-menus
----------------------------------
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-10
Sub-menu support means that an item on a menu can itself be another menu,
so that selecting it results in a new menu being displayed from which the
caller can select yet another option.
The areas in RBBS-PC that can have sub-menu support include: answering
surveys, bulletins, doors, joining a conference, and the file subsystem
command to list directories.
A primary use of sub-menus is to simplify the user interface, chiefly by
allowing sub-categorization of the option. For example, suppose a SysOp
has a complex system of doors, including multi-user games (TREK, NAPOLEON,
3DCHESS), single-user games (D&D, R&R, PICKUP), and demonstrations (DBIII,
ORACLE, ADVENT). These could be presented on a single menu, such as:
The following Doors are available:
Multi-User Games
TREK - explore the galaxy, compete with 12 other players
NAPOLEON - be Russia, Italy, or England and fight the computer
3DCHESS - are you ready, Spock?
Single-User Games
D&D - the Unix dungeons and dragons!
R&R - welcome to Taipei, Tokyo, or Bangkok, soldier!
PICKUP - do you have what it takes?
Demos - all self running
DBIII - Special version of DB3 adopted for remote usage
ORACLE - see the power of SQL. Full screen if you emulate ANSI.
ADVENT - our own home brewed ...
With sub-menus, the user could see a single, 3 item menu
Doors are available for:
MGAME - multi-user games
SGAME - single-user games
DEMO - self running demos
When the caller picks one of these three, a new menu comes up that lists
the particular doors for each category. For example, after picking MGAME
the caller sees
Multi-User Games available include:
TREK - explore the galaxy, compete with 12 other players
NAPOLEON - be Russia, Italy, or England and fight the computer
3DCHESS - are you ready, Spock?
RBBS-PC's sub-menu capabilities allow SysOps to set up "tree-structured",
"key word" paths to options. Bulletins provide an example where this type
of structure can be very useful. Bulletins have two main uses: short,
system-wide announcements, and a standard stock of text files for policies
and procedures for a RBBS-PC. Some SysOps, however, have wanted to put up
an elaborate system of announcements, where in fact these "bulletins" are a
featured way of presenting data to callers. For example, an association
published 300 short pamphlets under a dozen categories, and wants to make
this information available on-line. Sub-menus fit this need very well.
The main bulletin menu could read:
PLANNING YOUR USER INTERFACE Page 7-11
Bulletins are available for:
NURSES - nurses
OB - obstetricians
PED - pediatricians
FAM - family physicians
Please type in the category you want:
OB, instead of being a bulletin, is a sub-menu that displays:
The following bulletins are available for OBSTETRICIANS. Each entry
shows the length and price per glossy copy.
NAT - natural childbirth, 8 pages, $3
MIDW - midwives. 20 p., $5
NUTRI - special nutritional needs of pregnant women, 25p, $6
FPLAN - family planning services, 40 p, $3
DRUG - drugs to beware when pregnant, 50 p., $5
When the caller picks MIDW, the associated document is displayed. In this
example, bulletins become a menu-driven way of selecting documents to
browse.
In order for the previous example to work, RBBS-PC utilizes "named"
bulletins. For example, selecting "B" as the bulletin prefix, the above
bulletins would be files BNAT, BMIDW, BNUTRI, BFLAN, and BDRUG. However,
RBBS-PC's "new bulletin search" function will only search for named
bulletins if they are listed in the file x.FCK (where x is the bulletin
prefix). Also, named bulletins are not listed in the "new" bulletin list
as numbered bulletins are.
7.8.1 How to Implement Sub-menus
--------------------------------
If "XXX" is an option on a menu, simply create a file named "XXX.MNU" that
has in it the text for the menu. Put this file in the same drive/path as
the non-menu options (e.g. where the "BAT" files go for doors, where the
bulletin files to display are put, where the directory files are). For
example, if "B" is the bulletin prefix, the above example would be
implemented by adding the files "BNURSE.MNU", "BOB.MNU", "BPED.MNU", and
"BFAM.MNU". Put these files on the same drive that the bulletins
themselves go.
The .MNU extension alerts RBBS-PC to the fact that the file is a menu.
Thus, RBBS-PC will only LIST the menu file, rather than ACT on it (e.g.
3DCHESS.BAT is a door to be run, while 3DCHESS.MNU is a menu to be listed).
7.8.2 Shared Options Across Sub-menus
-------------------------------------
RBBS-PC supports identical choices from different sub-menus. E.g. the main
menu has sub-menus A and B, and BOTH of these sub-menus could have an
option X on them, which triggered a different action (based on which sub-
menu it X was selected from). The way that this works is RBBS-PC searches
both for the global prefix and the user response as well as looking for the
current prefix and user response. If the bulletin prefix is "B", and the
structure of bulletins is as follows:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-12
/ 1 BM is main bulletin menu, B is the prefix
A ---- 2 BMA.MNU submenu get with choice A
/ \ 3 BMB.MNU submenu get with choice B
/ BMC.MNU submenu get with choice C
/ / 1
BM --- B ---- 2 BMA1, BMA2, BMA3 bulletins active at BA
\ \ 3 BMB1, BMB2, BMB3 bulletins active at BB
\ BMC1, BMC2, BMC3 bulletins active at BC
\ / 1
C ---- 2
\ 3
7.9 RBBS-PC's "Macro" Command Support
-------------------------------------
RBBS-PC's "macro" support expands a single keystroke into multiple
keystrokes. It allows RBBS-PC to be tailored in even a greater variety of
ways than before because a single command can be set up to invoke a
sequence of multiple RBBS-PC commands. The concept is similar to the
keyboard macro function found in many terminal emulators, except that in
RBBS-PC the SysOp defines the macros and the caller invokes them
transparently without knowing.
Macros add a new dimension to RBBS-PC commands -- commands can be a full
word rather than just a single letter. A macro is invoked by a name up to
8 characters. For example, "DOOR" and "OPEN" can be used to invoke doors.
This makes it easy to make all commands available on a single level, since
D could trigger a download, while the word DOOR will trigger the door
function.
Macros can be used to abbreviate a longer series of commands. If the SysOp
wants to use "A)bandon conference", all that need be done is to add a macro
called "A" whose content is "J M" (join main). Or if N)etmail is to be
used to read Fido-net compatible message bases, a macro called "N" could be
set up as "D NETMAIL" (use door called NETMAIL). RBBS-PC thus can have
UNLIMITED commands.
A string of RBBS-PC commands can be stored in a macro for many different
types of purposes, including (but not limited to):
setting up demos,
showing a user what to do rather than just explaining it in words,
automated testing of RBBS-PC features
Macros can also be used to make the same type of function do different
work. For example, the B)ulletin command basically displays a text file.
Suppose an association wants to let persons order pamphlets and preview
them on-line. Rather than bury the ordering function inside A)nswer
questionnaire and the preview function inside B)ulletins, the commands
PREVIEW and ORDER can be added as macros, where ORDER stands for "A
ORDWHAT" AND "ORDWHAT" is a submenu listing what can be ordered. Each
option on the submenu is a questionnaire. PREVIEW similarly is "B PREWHAT"
where "PREWHAT" is a submenu listing the available pamphlets that are
stored as text files.
Macros can be built to provide interactive help to callers. For example,
you can put up a macro called EZDOWN to help people download. It explains
everything, asks for the file name and protocol, and tells the caller what
they should be doing on their end, and then drives the download.
PLANNING YOUR USER INTERFACE Page 7-13
Macros can be used to provide integrated data bases. Unlike
questionnaires, you can totally control how data is written to a file. You
can put in labels, or data only, put the values in quotes, separate the
values by commas, etc. This is done by creating a template into which data
values are written.
Macros can be used to give "tours" of your RBBS-PC -- to showcase new or
special features.
Macros can be controlled via security level access, just like regular
commands, and they can be forced to operate only in certain contexts.
Macros can be
- invoked anywhere within RBBS-PC -- including questionnaires,
- unlimited in length,
- used even when the caller has "turbo" key feature enabled,
- used with SmartText (see section 7.9),
- used to store responses that can be manipulated later, and
- used to support graphics versions of text.
It is important to remember that a macro will be ignored if its name is the
same as any command. To replace a command with a macro, you must insure
that the letter for the command has been reassigned. CONFIG parameters
30-34 allow such reassignments to be easily accomplished.
Some contexts will not accept macros, such as when RBBS-PC prompts for a
search string.
Macro commands with more than one letter override all others. This means
that the macro interpretation will prevail if more than one interpretation
is possible. For example, in the absence of macros the command "door"
would the interpreted as the command "d", so that saying "door" in the
files section would be download. But a "DOOR.MCR" would be executed
instead when it exists. One letter commands, however, will be executed
when they match a command letter, and so any macros will be ignored that
have the same one letter name the same as a command.
7.9.1 How to Set Up "Macros"
----------------------------
To use macros, two CONFIG parameters must be specified: the drive/path
where macro files are stored (CONFIG parameter 79) and the extension the
macro files will have (CONFIG parameter 80). The defaults are "C:" and
"MCR". To create a macro named X, simply create a file with prefix X and
the macro extension and place in it the macro drive/path. If you are not
using any macros, RBBS-PC will run faster if you specify NO macro extension
in CONFIG parameter 80.
The first line within a "macro" controls access to the macro, both by
security level, and a limitation on the scope of the macro, in which it
will be operative, including
- anywhere inside a section
- anywhere inside a command
- only at a section and not inside.
The format of the first line is:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-14
<SecLevel>/<constraint>
where <SecLevel> is the minimum security required to run the macro, and
<constraint> is the section (M for main, F for file, U for utility, or @
for library) and command letter the macro is confined to (use original
command letter, not the reassigned ones). For example
4/M
means that security level 4 is required, and the macro runs only at or
inside the main section prompt.
5/MB
means that security level 5 is required and the macro runs only at or
inside the main section bulletin command. Thus the macro file 1.mcr
2/MJ
{EN
RBBS
means that when inside the main J)oin, the text "RBBS" will be substituted
for "1". (So "J 1" does the work of "J RBBS".) The "{EN" means not to
echo what the macro substitutes (user does not see "RBBS").
To make a macro operative only at a section prompt and not inside, add a "
/" to the end of the section constraint. For example,
4/M /
means that the macro applies only at the main section prompt. For example,
the macro SP.MCR
4/M /
{EN
J SEMIPRV
will substitute "J SEMIPRV" for "SP" when at the main prompt, but NOT for
"SP" inside the message read command ("R SP L").
Note: a macro will be ignored if its name is the same as a command symbol.
To use 1, 2, 3, etc. for macro commands, you must disable or substitute
other symbols for the SysOp commands.
The first line of a macro must be the minimum security level to use the
macro. The macro will simply be ignored if the caller has insufficient
security. The second line will be parsed and replace the macro name. The
remaining lines will be read from disk and processed as required.
Macro commands have the same structure as SmartText variables:
<command prefix><command name>
where <command prefix> is the SmartText command specified in CONFIG. The
symbol "{" (ASCII 123) is the default. The <command name> consists of two
characters. Lines that are not valid macro commands are simply passed to
RBBS-PC as if the user had typed them in. There are three differences
between SmartText variables and macro commands:
PLANNING YOUR USER INTERFACE Page 7-15
(1) Macro commands must be the first three characters on a line, whereas
SmartText variables can occur anywhere on a line.
(2) Macro commands can have an argument after the command name, and(
(3) A macro command can apply to a block of lines following it.
7.9.2 Macro Commands
--------------------
RBBS-PC "Macro" Commands include the capability of having commands executed
within the "macro" rather than simply passing keystrokes to RBBS-PC. In
all prompts and blocks, substitution is supported for both stored answers
SmartText variables. The following is a list and description of valid
"macro" commands:
*0 - display what follows on the line with no carriage return.
*1 - display what follows on the line with a carriage return.
*B - display what follows on subsequent lines.
*F - display the named file that follows.
nn - display a prompt and store result in work variable nn.
WT - pause for the number of seconds specified after "WT".
>> - append the following block of text to the file specified.
ST - Stack the characters immediately following the "ST".
M! - Execute the named macro that follows on the same line.
ON - Case logic for branching within macros based on stored results.
EY - Echo the text passed in macros as keystrokes.
EN - Do not echo the macro keystrokes.
<< - Display fields from a file in a form.
:= - Assign value to a work variable
LV - Verify that answer of one in a list
NV - Verify that answer is between two integers
CV - Verify that answer is between two character values
LO - Set location for Fast File Searches for download, upload, view
The syntax and an example of each command follows:
*0 - display what follows on the line with no carriage return.
{*0Press any key to continue
*1 - display what follows on the line with a carriage return.
{*1{FN, I hope you enjoyed your tour of the board!
The caller's first name is substituted for the SmartText variable
"{FN."
*B - display what follows on subsequent lines, each line with a carriage
return, up to the line beginning with "{END".
{*B
This is an example of a macro's ability to display
multiple lines. The macro command is
{*B
and it will display all lines until it encounters one
beginning with {END. Like it, {FN?
{END
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-16
The caller will seen everything between the first and last lines, with
the first name substituted into the last line displayed.
*F - display the named file that follows.
{*F L:\RBBS\HELP.LST
will display the file HELP.LST.
nn - use the text that follows on the line as a prompt and store the answer
in an internal working variable numbered nn. nn must be two digits
and can be 01, 02, 03, ..., 99. CONFIG parameter 94 controls the
maximum # of work variables.
{01Please enter the Department you work for:
{02Please enter your Office number:
This will store the answers in work variable # 1 and 2, which can be
subsequently referenced as "[1]" and "[2]". You can have as many work
variables as specified in CONFIG parameter 94. Variables that are
reused have their values overwritten.
WT - pause for the number of seconds specified after "WT".
{WT 2
will wait for 2 seconds.
>> - append the following block of text to the file specified on this line.
{>> C:MACRO.DAT
"{FN","{LN","[1]","[2]"
{END
will append the following line to the file named MACRO.DAT on drive
C:, assuming the caller is KEN GOOSENS, and he responded to the above
prompts for Department with "Controller" and Office # with "107".
Then the line what would be written out is:
"KEN","GOOSENS","Controller","107"
As many lines can be included as desired. Simply end the block to be
written out with "{END" as the beginning of the line.
Some data base managers want fixed length files and this is possible
in the macro append. Just add "/FL" on the macro command line.
Rather than replace, the substitution will overlay the line at the
"[", thus keeping the output fixed length. Lets suppose that the
first work variable has "A" as a value, the second work variable has
the value "123456", the third work variable has "Henry" as a value,
and the caller's first name is KEN. Then
{>> C:\RBBS\DAT.FIL /FL
[1][2]....[3]...............{FN........
{END
would add the following line into DAT.FIL
PLANNING YOUR USER INTERFACE Page 7-17
A 123456.Henry.............KEN.........
Normally, blanks would be put where dots are show.
ST - Stack the characters immediately following the "ST".
{ST
will stack a carriage return (no characters). And
{STD [1] [2]
would stack "D RBBS-EXE.ZIP Z" - as if they were typed and ENTER
pressed - if the first work variable had "RBBS-PC.EXE" and the second
work variable held "Z". It is important to note that "macros" are so
transparent to RBBS-PC that if you use macros to display text at an
RBBS-PC prompt like "Enter command? ", RBBS-PC will continue to sit
there waiting for an answer. A stacked carriage return at the end
will cause the prompt to be redisplayed, though the effect of the
stack will vary with the particular prompt.
M! - Execute the named macro that follows on the same line. E.g.
{M! ORDER
will execute the macro called ORDER. RBBS-PC does NOT return to the
invoking macro when the named macro is complete. Also, The full file
name of the macro to execute is not here used (i.e. ORDER.MCR), only
the file prefix -- ORDER.
As is shown in the example of the ON command, the macro name can have
a drive/path and/or extension. If only a prefix is put in, RBBS-PC
will automatically add the drive/path and extension for macros
specified in CONFIG parameter 79 and parameter 80. Putting in a
drive/path/extension that is different from CONFIG's assures that no
caller can invoke the macro -- it only can be used internally by your
application.
ON - Case logic for macros. This allows responses to be tested against and
branching logic developed within a "macro". An example would be:
{ON 1
{==A
{M! D:\HIDDEN\CHOICEA.MCR
{==B
{*1You have selected option B
{02Why did you select B?
{==C
{M! D:\HIDDEN\CHOICEA.MCR
{END ON
EY - Echo the text passed in macros as if keystrokes. The default is to
echo.
EN - Do not echo the macro keystrokes. An example would be:
{EN
{*1 The following commands will be executed but now shown
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-18
{01 Press Enter when ready
R L
A
{EY
{*1 now you will see the responses to the prompts
{01 Press Enter when ready
R L
A
<< - Display fields from a file in a form. This is one of the most
powerful macro commands. It allows data to be stored in compact, data
format but retrieved into a form for display to a caller. There are
5 parameters that can follow the macro command:
<file name> <file format> <data#> <submode> <rec-pause>
where:
"<file name>" is the name of the data file that has records to read,
"<file format>" is "/V" if data is stored in variable length format
and "/F" if fixed length format,
"<data#>" is the number of separate fields in a record for variable
length data and the length of the data if fixed length,
"<submode>" is the mode used to substitute data in the following form
"/FL" if the form is fixed length, meaning that data is overlaid into
the form so as not to change any lengths.
"<rec-pause>" should be "/1" if you want to pause after each record
rather than when the screen fills.
An example of a "macro" that uses this capability is as follows:
{*1 -TOPIC- - DATA # - - VOICE # - -First Name- -Last Name-
{<< C:\RBBS\RHLP.DAT /V 5 /FL
[1] [2] [3] [5] [4]
{END
Note that spaces occur after the "[4]". If the file RHLP.DAT contains
"DOORS","703-978-6360","0","Ken","Goosens"
"PROTOCOLS","407-487-3441","407-852-7790","Doug","Azzarito"
then the caller would see
-TOPIC- - DATA # - - VOICE # - -First Name- -Last Name-
DOORS 703-978-6360 0 Ken Goosens
PROTOCOLS 407-487-3441 407-852-7790 Doug Azzarito
The same example using fixed length data would be
{*1 -TOPIC- - DATA # - - VOICE # - - Name -
{<< C:\RBBS\RFLH.DAT /F 69 /FL
[1](34:12) [1](46:12) [1](58:12) [1](1:33)
{END
PLANNING YOUR USER INTERFACE Page 7-19
where RFLH.DAT contains:
Ken Goosens DOORS 703-978-63600
Doug Azzarito PROTOCOLS 407-487-3441407-852-7790
This would produce the following for the caller:
-TOPIC- - DATA # - - VOICE # - - Name -
DOORS 703-978-6360 0 Ken Goosens
PROTOCOLS 407-487-3441 407-852-7790 Doug Azzarito
Note that work fields support sub-field references in the format:
[n](x:y)
where n is the work field number, "x" is the beginning column, and "y" is
the # of bytes to get. If work field two had a value "123abcde" then
"[2](3:4)" would have "3abc" as its value. Fixed length records are always
referenced as work variable one.
:= - Assign a value to a work variable. Work variables can be assigned a
value inside a macro. The command to do this is ":=". E.g.
{:= 5 OK
assigns string "OK" to work variable 5.
LV, NV, and CV - Macros can edit the responses to questions. Edits can
constrain the answer to
- one of a list
- a numeric value between two values
- a character value between two values
An editing constraint must be put in front of the actual macro
question it applies to, and a constraint applies only to the next
question and does not remain operative.
The commands for these are respectively "LV" (List Verify), "NV"
(Numeric Verify), and "CV" (Character Verify). The list verify uses
the first character after the command as a delimiter between valid
responses. E.g. "{LV;R;A;E;" means that only "R", "A", and "E" will
be accepted as answers ("{LV/R/A/E/" would have the same effect).
Semi-colon is the best delimiter in general because it cannot be
entered as a value.
Numeric and Character verify check inclusive ranges. Thus "{NV 7 11"
will accept 7, 8, 9, 10, or 11. The numeric value must be an integer
between -32,768 and 32,767. To accept answers B through E, the macro
edit command is "{CV B E".
Whenever an answer fails an edit, the message "Invalid answer <...>"
is given with the answer received between brackets, and the question
is asked again. An example of a macro with edits is:
4
{*1 Verification macro
{*1 now checking list...
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-20
{LV;A;F;W;
{01 Enter A, F, or W
{*1 now testing numeric range...
{NV 5 15
{01 Enter a number between 5 and 15
{*1 now testing character range...
{CV D J
{01 Enter a character between D and J
LO - Sets location that a file is to be searched for in an upload,
download, or view request. Followed by a drive path. Useful when
want to have a macro execute in front of a download or upload for a
file which is really available (see section 12.9). Applies only to
Fast File Search. For example,
{LO F:\DF1\
would set the file location to drive F subdirectory DF1.
7.9.3 A Sample Macro
--------------------
Suppose A)bandon conference is to be implemented in RBBS-PC. To do this,
the command A)nswer questionnaires must be assigned a different letter.
Else A will always invoke answer instead. Then the macro file could
contain
5
J M
The command "A" will then be followed by "Rejoining MAIN". Incidentally,
if the macro had been implemented by
5
J
M
The only difference is that the prompt for what conference to join will be
displayed, "M" then would be displayed as if the caller had typed it, and
then main would be rejoined. The difference is caused by the fact that the
first line after the security level is what replaces the macro name, so in
the first case "M" preempts the prompt but not in the second.
7.9.4 On-line Data Base With Macros & Questionnaires
----------------------------------------------------
RBBS-PC provides the SysOp with the ability to offer callers access to an
on-line database both internally (using macros and questionnaires) and
externally to RBBS-PC (see Appendix R).
RBBS-PC's internal Remote Data Base feature gives the SysOp the ability to:
- set up unlimited numbers of named data bases
- set up menus to interact with the user
- prompt users for data
- use Metavariables - both work variables and SmartText variables.
- store user's answers in work variables. Any subfield in a work
variable can be referenced.
- display, or store all metavariables
- process commands conditionally
PLANNING YOUR USER INTERFACE Page 7-21
- save Metavariables to file through templates, allowing data to be
stored in virtually any format desired
- retrieve data into templates for display.
- do full screen data entry
RBBS-PC's support for "full screen" questionnaires and macros takes some
work on the SysOp's part. The SysOp must use ANSI screen commands. The
SysOp must then arrange to transmit the "template" that clears the callers
screen and writes the appropriate static text (lines, labels, etc.) on the
callers screen. Then the data the user is to see is transmitted onto the
caller's screen. The "full screen" support does not allow the caller to
use keys like tab and cursor arrows to move around on the screen. It is
"full screen" in the sense that the caller sees all the data that is to be
entered and the cursor moves from field to field.
On-line Database Example
------------------------
This application manages a data base of callers who are willing to help
with RBBS-PC by topic. It is controlled at a high level by the following
questionnaire.
C:DUMMY.DAT,4
* This questionnaire is for finding help with RBBS-PC by topic.
* Please register yourself if you
* - are willing to help others, and
* - know enough about a topic to help
*
* Examples of topics people need help with:
* Desqview Modem models (HST, Everex, USR Internal, etc.)
* PC-Slaves Protocols Conferences FMS
* Doors DoubleDos Sub-boards PUI
* Questionnaires 10-Net Macros Uploads
* MU-Purge File maint. Personal dnld Caller Analysis
*
:-[prompt]-
T
? V)iew database, E)nter new data, Q)uit (V,A,Q)
=V-[view]-=E-[add]-=Q-[quit]-= -[prompt]-
:-[view]-
M C:\RBBS\VIEWHELP.MCR
>-[prompt]-
:-[quit]-
@
:-[add]-
* 703-978-6360
?1 BBS data number
* 703-978-4339
?2 Voice # (evening, 0 not to give)
* You can specify as many topics as desired, one at a time.
*
:-[topic]-
?3 RBBS-PC topic you will help others with, or Q)uit
=Q-[prompt]-= -[addrec]-
:-[addrec]-
* -Topic- - Data # - - Voice # - Last Name First Name
*/FL[3] [1] [2] {LN {FN
T
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-22
?Really add this record (Y,N)
=Y-[really]-=N-[topic]-= -[addrec]-
:-[really]-
M C:\RBBS\ADDHELP.MCR
>-[topic]-
Two macros are used by this questionnaire:
VIEWHELP.MCR for displaying the data base, and
ADDHELP.MCR for appending new data to the data base.
VIEWHELP.MCR contains
5
{*1 -Topic- - Data # - - Voice # - Last Name First
Name
{*F RBBSHELP.DAT
ADDHELP.MCR contains
5
{>> RBBSHELP.DAT /FL
[3] [1] [2] {LN {FN
{END
Full Screen Example
Full screen is available only in a color graphics version of questionnaires
and macros. A long application for collecting BBS information is given in
these following files:
REGRBBS.DEF - Questionnaire driver, TTY version
REGRBBSC.DEF - Color graphics version of questionnaire driver
VUNRBBS.MCR - View data base macro, TTY version
VUNRBBSC.MCR - View data base macro, Color graphics version
SVRBBS.MCR - Macro to save data to a comma separated data file
These files can generally be download from most bulletin board systems.
However, they are definitely available on Ken Goosens' RBBS-PC system at
(703) 978-6360.
Hints for Building Remote Data Base Applications
------------------------------------------------
Generally you will have:
- a questionnaire driver that gives caller option to exit, view
database, or Enter new data
- a macro to retrieve data from file to a form
- a macro to save data in a data base format
- a data entry routine in the questionnaire.
Creating a "full-screen" application is more complicated that than a line-
at-a-time (i.e. TTY) application. For full-screen applications, you will
want to:
- paint a template with everything but the data values, such as row and
column labels and titles.
- clear out the existing values in a form and then put in the new
values.
PLANNING YOUR USER INTERFACE Page 7-23
Only the changes to the screen are transmitted rather than retransmitting
the entire screen when only a part changes.
ANSI commands are used to control the screen. Where [ESC] stands for the
one-character Escape (ASCII 27), the most useful ANSI commands to know are:
[ESC][2J - clear the screen.
[ESC][K - clear from current cursor position to end of line. Cursor
position after clearing is same as before.
[ESC][X;Yf - position the cursor on row x and column Y. E.g.
"[ESC][5;10f" positions on column 10 of row 5.
Case is significant in ANSI commands, so beware that "[ESC][k" will NOT
clear to end of line, and "[ESC][1;7F" will not position the cursor.
You can use ANSI commands to set color and blink characters. An easy way
consistent with RBBS-PC is to set colors using the SmartText variables C0,
C1, ..., C4, where 1-4 are the colors set in CONFIG parameter 323,
parameter 324, parameter 325, and parameter 326. C0 is "emphasis off," and
restores normal text color preference of the caller. An example that
clears the screen, sets color to 1, positions on line 1, column 15, prints
"-Sample Title-", sets color to caller's text preference, prints 2 spaces,
and then prints value of work variable 1 is as follows:
[ESC][2J{C1[ESC]1;15f-Sample Title-{C0 [1]
7.10 RBBS-PC's "SmartText" Variables
-----------------------------------
SmartText allows the SysOp to substitute pre-defined variables in text
files as menus, bulletins, help, welcome files, as well as macros and
questionnaires. This allows the SysOp to present to each caller an
interface that is not only "programmable", as discussed in section 7.6, but
also tailored to the specific caller.
Some applications for SmartText include: addressing the caller by name, as
well as referring customized variables for the caller, such as city/state.
For example, the welcome file could say, "Hi, <first name>, how's the
weather in <city/state>?". SmartText variables can also be used for status
line reports in menus, showing such things as security, minutes remaining,
and current time.
To utilize RBBS-PC's SmartText files, CONFIG parameter 17 must be set to
the decimal value of a delineation character that the text editor used by
the SysOp can handle. The character you select should have three
characteristics:
1. It should be visible on the screen and when printed. This allows
the SysOp to see where the control sequence is when designing the
text files to be used as SmartText files.
2. It should not be a character that might be used for any other
purpose in the text files. The character can still be used in
text files, but the chances are slight that RBBS-PC will
interpret the character as a SmartText sequence.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-24
3. It should not be a character that might be interpreted, when
printed, as being a printer command (i.e. start double spacing).
IMPORTANT: While RBBS-PC currently allows you to select the SmartText
character, we STRONGLY suggest you use the default character
(the { character, decimal 123). Future versions of RBBS-PC
will no doubt rely heavily on standard SmartText, and as
such will probably NO LONGER allow you to change this
character.
CONFIG parameter 17 can have any value between 0 and 255. If 0 is
selected, RBBS-PC's SmartText capability will be turned off.
A RBBS-PC SmartText control sequence consists of the control character that
was selected in CONFIG parameter 17 followed by a SmartText double-
character command. These SmartText double-character commands MUST be
entered as upper case characters! There are two kinds of SmartText
variables: those which substitute text, and others which control how
substitution is done. The commands are:
COMMAND NAME MEANING
BD "Bytes Downloaded" Displays the bytes downloaded today.
BN "BBS Name" Displays the name of the BBS.
CN "Conference Name" Name of message base/conference currently in
CS "Clear Screen" Overrides RBBS-PC's automatic screen depth
management so that the next "Press Enter to
Continue" will not come halfway through a page.
CT "City/state" Displays the caller's city & state.
C0 "Color 0" Resets color to the user's selection for text.
C1 "Color 1" Changes color to the user's selection for
Foreground Color One.
C2 "Color 2" Changes color to the user's selection for
Foreground Color Two.
C3 "Color 3" Changes color to the user's selection for
Foreground Color Three.
C4 "Color 4" Changes color to the user's selection for
Foreground Color Four.
DB "Dnld (tot) Bytes" Inserts the total number of bytes ever downloaded
by the caller.
DD "Downloads Today" Inserts the total number of files downloaded by
the caller today.
DL "DownLoads" Inserts the total number of files ever downloaded
by the caller.
DT "Date" Inserts the current date, MM-DD-YYYY, into the
text file.
FI "FileName" Inserts current work Filename into the text file
FN "First Name" Inserts the user's FIRST NAME into the text file.
FS "First Name SySop" Inserts the SysOp's FIRST NAME into the text file.
LN "Last Name" Inserts the user's LAST NAME into the text file.
LS "Last Name SysOp" Inserts the SysOp's LAST NAME into the text file.
ND "Node Number" Inserts the RBBS-PC Node Number for this node.
NS "Non Stop" This causes the rest of the current file to be
displayed in RBBS-PC's "none stop" mode. Page
breaks will be ignored following a NS command.
PB "Page Break" Causes RBBS-PC page break message, "MORE
(Y/N/NS/A)" or the "PRESS ENTER.." prompt to
appear after the line is printed.
PLANNING YOUR USER INTERFACE Page 7-25
RP "Reg Period" Inserts the number of days in the registration
period.
RR "Reg Remaining" Displays the days remaining in the caller's
registration period.
SL "Security Level" Inserts the user's current security level into the
text file.
TE "Time Elapsed" Inserts the user's elapsed session time (hh:mm)
into the text file.
TM "Time" Inserts the time (hh:mm AM/PM) into the text file.
TN "Trim NO" Substitute as is (the default)
TY "Trim YES" Remove leading and trailing spaces first
Note: a setting for trimming remains in effect until another trim
command is encountered.
TR "Time Remaining" Inserts the number of minutes left in the user's
session into the text file.
UB "Upload Bytes" Displays the total number of bytes ever uploaded
by the user.
UL "UpLoads" Displays the total number of files ever uploaded
by the user.
VN "Overlay NO" Insert into the text file (the default).
VY "Overlay YES" Overlay into the text file (do not change length)
Note: an overlay setting remains in effect until explicitly replaced.
When designing SmartText files, each SysOp should take into account that
some of the SmartText commands (i.e. the user's name) may significantly
extend the length of a line. It is important that this line elongation be
taken into consideration so that, when the actual text substitution occurs,
the line seen by the caller does not exceed 80 characters.
What follows is an example of a SmartText file that demonstrates how all of
the above commands might be used. The following example assumes that
CONFIG parameter 17 has been set to the decimal value 123 for the SmartText
delineation character -- {.
Introducing...{C1SmartText!{C0
RBBS-PC allows the SysOp to customize the text seen by each caller.
For instance, if the SysOp wanted to make sure this message didn't
scroll off the screen, he could pause the display like this:
{PB
Or, the SysOp may want to show the caller that today's date is {DT and
the time is {TM. The SysOp may even want to include a personal
greeting to {FN {LN.
The SysOp can tell the caller that their security level is {SL and
that they have been on-line for {TE, and have {TR minutes left in this
session.
This kind of capability illustrates RBBS-PC's on-going commitment to
nurturing each SysOp's creativity and avoiding the dogmatic.
7.11 "Colorizing" the RBBS-PC User Interface
--------------------------------------------
"Colorization" refers to the utilization of color within RBBS-PC text files
and prompts. RBBS-PC has long supported graphics versions of external text
files, and is even distributed with graphics menus. RBBS-PC supports
"colorization" as follows:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-26
1) In files shown to the callers including:
the prelog
all menus,
all bulletins,
the Welcome file,
the file for new users,
all on-line help files,
standard file directories, and
FMS file directories (see item 6 below).
2) Via highlighted text
in searches of messages,
in searches of files,
in announcing new personal mail waiting,
for locked out users, and
the SysOp user maintenance (function 5).
Highlighting supports a limited but extremely functional use of
colorization - to make it easy for the caller to spot significant bits of
text on a screen.
3) Within the Programmable user interface (PUI).
The PUI file can have graphics versions just like text files. The file
XMAIN.PUI that was used in the example in section 7.6.2 can have a
graphic's equivalent named XMAING.PUI and a color equivalent named
XMAINC.PUI. Color codes can be embedded in the prompts in the PUI as well
as external text files. Each SysOp has total freedom to colorize prompts
as well as menus.
4) Within text internal to RBBS-PC.
This applies to standard (non-PUI) prompts, such as the main command
prompt, and to formatted reports, like the message scan and message read.
This type of "colorization" is controlled by whether highlighting has been
turned on in CONFIG.
5) Within RBBS-PC's "short" prompts.
Caller foreground color 4 is used to mark the commands the user can type.
Emphasis is used to mark the default selection. This colorization is based
on a scan of the text to be printed:
[...] : will be highlighted (default answer)
(xxx) : will be put in foreground color 4 (text to type in): if xxx
is not longer than 2 characters and is in caps
<...> : will be put in foreground color 4 (collective choices) and
if there are words before this, the first will use
foreground 1 and the second, foreground 2.
"Short" prompts colorization applies to ALL text displayed by RBBS-PC
before an answer is expected. For example, by using the above conventions,
questionnaires can be colorized. This is controlled by whether
highlighting is on.
6) Within FMS file directories.
The "colorization" of the FMS file directories is based on the four colors
specified in CONFIG and is controlled by whether or not the caller has
selected to be in color graphics mode or not.
There are two extremes on the use of color: use none or use it everywhere.
PLANNING YOUR USER INTERFACE Page 7-27
By using no colorization, RBBS-PC's performance is optimized. RBBS-PC does
not have to go through the overhead of transmitting special instructions to
control the caller's screen. The two chief functions of BBSs, transmission
of textual information and file exchange, do not essentially involve the
use of color.
Of course, there are those who want their RBBS-PC's visual displays to
convey as much as the text or the files themselves (i.e. the message is in
the medium). These are the SysOps who elect to use color everywhere. With
the use of color, plain text begins to look drab and uninteresting and
attention tends to focus on the colorized text. For this reason, some
SysOps find it difficult to use color in some places and not in others.
Colorization is implemented in RBBS-PC with ANSI display commands. In
order for a caller to see the colors as RBBS-PC displays them, the terminal
emulator used by the caller MUST be ANSI-compliant. CONFIG allows the
SysOp to activate and customize colorization on screen 17, "RBBS-PC Color
Parameters".
1) Use CONFIG's parameter 321 to put in a string for turning EMPHASIS on.
The recommendation is a bright foreground on red background
("[27][1;41m").
2) Use CONFIG's parameter 322 to set the string for normal text. This is
the general default color and is used to turn off emphasis. The
recommended color is amber (normal yellow) ("[27][0;33m").
3) Use parameter 323, 324, 325 and 326 of CONFIG to set the four caller
foreground colors. CONFIG uses natural language phrases to set these,
so it is very easy. The recommendation, in order, is:
bright green,
bright yellow,
bright purple, and
bright cyan.
These colors are all used in the message header and general command prompt.
Foreground 4 is used to highlight the commands the caller actually needs to
type in to select that option.
No colors will be displayed if these parameters are set to empty strings.
Callers can turn off the colorization simply by going into Utilities and
T)oggle H)ighlite to "off". The default in RBBS-PC is for colorization to
be OFF.
Colorization is based on the ANSI standard. Special codes are sent by
RBBS-PC to the callers system, which must then be interpreted by the
caller's communications software.
7.12 RBBS-PC's Automatic Operator Page Option
---------------------------------------------
RBBS-PC will "automatically page" the SysOp whenever a specified caller or
group of callers logs on to RBBS-PC or joins a specific "sub-board". The
selection criteria can be a specific caller's name, a range of security
levels, or whether the caller is a new user. A SysOp may wish to be
notified for any number of reasons including:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-28
- A caller has been causing trouble on the bulletin board and needs to
be monitored.
- The SysOp wants, for security reasons, to be notified when anybody
logs on with a SysOp security level.
- The SysOp wants to chat with a friend but does not want to continually
monitor RBBS-PC's activity.
AutoPage is controlled by a file whose name is specified in CONFIG
parameter 18 (the default name is AUTOPAGE.DEF). Each line in the file is
a separate AutoPage command. The line contains 4 parameters separated by
commas. The format is
<condition>,<notify caller?>,<# of times>,<music>
<condition> Can be a NAME enclosed in quotes, the string
"NEWUSER", or a security level range specified in
the format
/<min sec>/<max sec>
where:
<min sec> is the minimum security level
<max sec> is the maximum security level
<notify caller?> Is "N" if the caller also is to be notified that
the SysOp has been notified when the caller logs
on. Anything else means the caller will not know
that the SysOp has been paged automatically.
<# of times> Is the number of times that the PC's speaker will
be sounded.
<music> Is a BASIC music command to be used instead of a
beep. If nothing is specified, a beep will be
used.
Warning: on some PC's the playing of music produces "out of string space
errors". Test any music before using. Beeps always work fine.
Examples:
"SEXY DEVIL",,1,L4EDC AutoPage when a caller named SEXY DEVIL logs on,
do not notify the caller, and play "L4EDC".
"GREGG SNYDER",N,2, AutoPage when GREGG SNYDER logs on, notify the
caller, and beep the speaker twice.
"NEWUSER",,1, AutoPage when any new caller logs on, do not
notify the caller, and beep the speaker once.
/10/12,N,2, AutoPage when anyone with security 10 through 12,
inclusive, logs on, let them know that the SysOp
wants to be notified that they are on, and to beep
the Speaker twice.
The status line at the bottom of the RBBS-PC screen will read "AP!" for the
duration of the caller's session if RBBS-PC has automatically paged the
PLANNING YOUR USER INTERFACE Page 7-29
SysOp. This allows the SysOp to know that the AutoPage took place, even if
the SysOp was not present at the beginning of the call.
If the caller triggers more than one AutoPage command, the first condition
encountered will be used.
Since each "sub-board" can have a different AutoPage command file, the
SysOp has the option to be automatically paged based on different criteria
for each "sub-board".
7.13 Enhancing the File View Function
-------------------------------------
Within the File Subsystem of RBBS-PC the V)iew function, allows the caller
to get a list of files that are "archived" inside a single file. RBBS-PC
supports .ARC, .LZH, .PAK, and .ZIP compression formats, as well as ANY
format using SysOp-installed external procedures.
RBBS-PC assumes that the file extension will identify the type of
compression. Hence, the SysOp can install a View function for files with
extension ".XYZ". All the SysOp must do is put a .BAT file with the name
"Vxyz.BAT" on the same disk and path specified for COMMAND.COM via CONFIG
parameter 105. If such a file is present, RBBS-PC will shell to the
command in Vxyz.BAT whenever a caller asks to V)iew any file with the
extension .XYZ. SHELLing requires extra system RAM beyond what RBBS-PC
uses. If your system has little or no free memory, you may be limited to
using the internal V)iew feature of RBBS-PC.
RBBS-PC includes the following files for external View support:
ARCVIEW.COM Compiled C program for view of DWC, PAK, ZOO, and ARC
files. Used in VDWC.BAT, VZOO.BAT.
VDWC.BAT Processor for DWC files
VZOO.BAT Processor for ZOO files
Each BAT file contains in it:
ARCVIEW [1] > [2]
RBBS-PC will SHELL to the above program (not to the BAT file) after first
substituting the name of the file to be listed for "[1]" and the name of
the file to place the results of the listing for "[2]". The ">" is the DOS
"redirect" function, which causes the output to be placed in the file
instead of on the local screen.
The file specified in [2] is named "NODE?WRK" when the wildcard "?" is the
node id (1,2,3,...).
How to Implement Your Own View function
---------------------------------------
Your view program must have a way to receive from RBBS
- the name of the file to list
- the name of the file to write the listing to.
RBBS-PC will interface with your program in two different ways, depending
on how many lines your BAT file contains.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-30
If the BAT file contains exactly 1 line, RBBS-PC will shell to the line in
the BAT file and not to the BAT file itself. RBBS-PC will dynamically scan
for "[1]" and "[2]" in the line and substitute the names of the file to be
listed and the file to write the results to, respectively. Everything else
will be left intact.
If the BAT file contains more than one line, RBBS-PC will shell to the BAT
file, passing as command line parameters the name of the file to list, and
the name of the results file.
For example, the following BAT file could be used:
ECHO OFF
ECHO %1 >> VIEW.LOG
ARCVIEW %1 > %2
ECHO ON
The statement "ECHO %1 >> VIEW.LOG" will create a list of all files
selected for view. ">>" means to append the view file name to a file
called "VIEW.LOG".
Using ZIPTV
-----------
Ziptv is a program distributed by Samuel H. Smith which supports not only
View, but the ability to list any file inside of a ZIP file, thus allowing
users to view documentation before downloading a file. Many SysOps will
want to install ZIPTV to replace the internal RBBS-PC View function. To do
so, create a VZIP.BAT as follows:
DEL %2
<path>ZIPTV -P%3 %1
Where <path> is the drive and subdirectory where you have placed ZIPTV.EXE.
7.14 Bulletins and News
-----------------------
RBBS-PC has very powerful and flexible features for broadcasting system-
wide information to callers. The following table describes the various
NEWS options:
PLANNING YOUR USER INTERFACE Page 7-31
When the caller will see Which file will the caller see
the news
Every time the caller logs The file PRELOG is displayed before callers
on. are asked their names. This information
should be kept very brief.
Only when a NEW USER logs The file NEWUSER is shown to new users only
on. the first time they log on.
On every call, after the The file WELCOME is displayed after a
caller logs on. successful logon. For graphic and color
versions of this file, see section 6.3.
Only when the SysOp has The NEWS file is displayed if the date of
updated information since last log on is the same or earlier than the
the last time the caller date of the news file. The news file also
was on the BBS. can be read by using the "B N" command
(Bulletin News).
Every time the caller logs The logoff questionnaire, EPILOG.DEF is
off. processed at logoff, and can be used to
display news at this time. See section 19.
Available on request by The RBBS-PC general Bulletin files.
the caller.
General Bulletin Files
----------------------
General bulletins are text files prepared by the SysOp that can be viewed
by the callers when they first log on, or at any time during the caller's
session. To configure bulletins, you must first decide if you will used
NUMBERED bulletins, NAMED bulletins, or both. The only difference between
numbered and named bulletins is in how RBBS-PC scans for new bulletins when
a caller logs on. With numbered bulletins ONLY, RBBS-PC uses the number of
bulletins specified in CONFIG parameter 62 to find new bulletins. If the
SysOp uses NAMED bulletins, each bulletin must be identified to RBBS-PC (in
the file BULLET.FCK) in order to scan for new bulletins.
RBBS-PC will list the new bulletins on logon by the name of the bulletin
that the user would type. This lets the SysOp add a description after the
name and better control the form of the output on the caller's screen. The
scan of new bulletins is controlled by the Bulletin Prefix specified in
config, plus the extension "FCK". The default prefix is "BULLET", so
"BULLET.FCK" would be the file that lists the bulletins to be checked.
BULLET.FCK should contain the name of the bulletin, one to a line. To add
a description, simply add the description after the bulletin name. A
space must separate the name from the description. For example,
1 - Board Policies
2 - Best BBS's
would display
2 New bulletin(s) 1 - Board Policies 2 - Best BBS's
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 7-32
instead of
2 New bulletin(s) 1 2
Note: by putting the entry in double quotes, you can embed carriage
returns line feeds in the description to make the display come out one to a
line. For example,
" 1 - Board Policies
"
" 2 - Best BBS's
"
would display as
2 New bulletin(s)
1 - Board Policies
2 - Best BBS's
Note: the first word must be the name of the bulletin. Leading spaces can
be put in to indent the display.
To create a bulletin, use CONFIG parameter 61 to set the location and name
of the bulletin menu, and set parameter 63 to the desired bulletin prefix.
If you are using numbered bulletins, also set parameter 62 to the number of
bulletins.
Ex: Set parameter 61 to: C:\RBBS\BULLETIN\BMAIN.MNU
Set parameter 63 to: B
When RBBS-PC looks for bulletins, it will use parameter 61 for the location
of each bulletin, and parameter 63 to build the file name. If you would
like a bulletin named TEST, RBBS-PC will look for the file
C:\RBBS\BULLETIN\BTEST.
Any TEXT editor can be used to create bulletins. The bulletin can contain
ASCII text, extended ASCII graphics, or ANSI color. By naming the
bulletins properly, RBBS-PC's graphic support will display the proper
bulletin to the caller (e.g. BTESTC. would be the COLOR version of bulletin
TEST). See section 6.3 for details.
The bulletin menu defined in CONFIG parameter 61 should contain a list of
available bulletins. The .MNU extension activates RBBS-PC's sub-menu
feature (see section 7.7).
If only numbered bulletins are used, RBBS-PC will be able to scan for new
bulletins automatically (as long as parameter 62 has the proper setting).
For named bulletins, you must create a list of bulletins for RBBS-PC to
scan. The list should be in the file <prefix>.FCK in the same directory as
all the bulletins. The <prefix> is what is specified in parameter 63. In
our example, this file would be called B.FCK. Each bulletin should be
listed, without the prefix, one per line. Ex:
TEST
1
2
RBBS-PC
PLANNING YOUR USER INTERFACE Page 7-33
would check the date of the files BTEST, B1, B2 and BRBBS-PC. Note that B1
and B2 are considered Numbered bulletins, but if B.FCK is used, ALL
bulletins are considered Named bulletins.
News Bulletin File
------------------
The NEWS file is a special bulletin that is automatically displayed to a
caller at login if it has been updated since his last call. The NEWS
bulletin is NOT located with the general bulletin files. It should be
placed in the same directory as the WELCOME file. The name of the NEWS
file is <conference>.NWS. The <conference> is the name of the RBBS-PC
conference to which the news belongs (each conference can have a separate
news file). The MAIN news file, shown to callers at login, is named
MAIN.NWS. News files can support color and graphics (see section 6.3).
UNIQUELY IDENTIFYING YOUR CALLERS Page 8-1
8. UNIQUELY IDENTIFYING YOUR CALLERS
------------------------------------
All callers need a way to identify themselves to RBBS-PC and to other
callers. RBBS-PC expects each caller to set a password so that other
callers cannot easily pretend to be that caller. Callers are most easily
known on bulletin boards the same way they are known in real life - by
first and last name. This is why the default configuration in RBBS-PC uses
first and last name to IDENTIFY users. The first/last name is the caller's
identity or ID.
RBBS-PC also allows the SysOp to identify callers uniquely by something
other than their first and last names. Perhaps the SysOp wants a one word
alias to be allowed, or perhaps callers must use a preassigned access code
(access code, employee number, account number, etc.). RBBS-PC allows ANY
FIELD inside the users file to be used for identification. Since there are
empty, unused areas in the user file, a SysOp can even create a new field
to be used for caller identification.
When anything other than name is used to identify users, RBBS-PC still
wants callers to specify their names. It just does not use that
information to identify them.
A fairly common problem on bulletin board systems with large user lists is
that two callers can have the same first and last name. A caller discovers
this when they are unexpectedly asked for a password on the first call to a
new system, indicating that another caller has already used that name.
Further, since RBBS-PC is used world-wide many non-English speaking
countries have callers with names that have embedded blanks, etc. RBBS-PC
alleviates this problem by allowing interior blanks in first and last
names. Thus JIM JONES can register as JIM K JONES or JIM JONES SR or JIM
JONES III.
By allowing ANY field inside the user record to be used to uniquely
identify individual callers, RBBS-PC alleviates the basic problem of having
two callers with the same name.
This additional INDIVIDUATION field is used to distinguish callers with the
same ID. When individuation is used, callers will have to specify both the
identifying and individuation field. Both are used to find a record in the
users file. This individuation field can likewise be a new field created
by the SysOp. For example, the SysOp can specify that callers be uniquely
identified by both their name and their CITY/STATE. Alternatively the
SysOp can specify that callers are to be uniquely identified by their
telephone number, which would be a new field for RBBS-PC to store. Note
that when using individuation, ALL callers must use it, not just the ones
with identical names.
8.1 Setting Up Identifying and Individuation Fields
---------------------------------------------------
The identifying and individuation fields in RBBS-PC are controlled by
parameter 41 through 46 in CONFIG. The default is to use the caller's
first and last name to uniquely identify a user.
The fields available to uniquely identify a caller (other than the caller's
first and last name) are designated in CONFIG by the starting position in
the users file and length. It is essential therefore to understand WHERE
FIELDS ARE STORED IN THE USER FILE. Consult Appendix A for a detailed
layout of the user file.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 8-2
RBBS-PC's flexibility requires care when selecting the locations of fields
used to identify and individuate, because options can be selected that make
no sense. For example, it is possible to specify the user preference
field, which means that every time a user changed preferences, such as
default protocol, the user would have a different ID.
There are only two fields in the user file that make sense for identifying
users:
1) first/last name (column positions 1-31), or
2) a field designated by you as the SysOp for your RBBS-PC. For a
SysOp-designated field, only 4 choices make sense:
a) none,
b) name (columns 1-31),
c) city/state (columns 63-86), or
d) positions 87-97 in the user record currently "unused."
Positions 87-97 of the users record (currently unused) provides a potential
11 columns to use for SysOp designated fields. However, there is no
guarantee that these positions will not be used in future releases of
RBBS-PC. Additional fields will be used from the far right. Any SysOp
intending to utilize this area of the users record is safest if the field
selected begins in column 87 and is as short as possible.
When a SysOp-designated field is created, the SysOp must also supply the
prompt to be used with the field. The prompt is what is displayed to the
caller when asking for the value of the field.
RBBS-PC uses the callers first and last name for the "to" and "from" fields
for messages even when the users name is not the field used to uniquely
identify callers.
8.2 Preloading Identities For Instant Access
--------------------------------------------
SysOps who operate bulletin boards that are open to new callers have no
problems giving a new caller instant access -- new callers register, set
their identity and password, and are recorded in the USER file.
SysOps that operate bulletin boards that are only available by
subscription or who delay access operate differently -- a user must
already know and be able to state identity, individuation, and password in
order to get on. To add a new user, the values of these fields must be
communicated back to the caller in order for them to have access. To
overcome this cumbersome approach, some SysOps allow new callers on their
system (at a reduced security level) and then raise the security level of
the caller once the caller has met whatever criteria the SysOp has set for
access to the system.
Typically new callers must call back and continue to check to see if their
security level has been raised. Systems that do not let new callers on
require the SysOp to enter the appropriate information for each new user,
contact the new caller by mail or phone, and let them know how to connect
to the RBBS-PC. Both approaches introduce delays to new callers for
getting on and additional time, expense and overhead for the SysOp.
RBBS-PC provides a systematic solution to the problem of delayed access for
new users. A SysOp can add a user WITH NO VALUE FOR THE INDIVIDUATION
FIELD OR PASSWORD. These fields can be left blank. When a caller logs on
UNIQUELY IDENTIFYING YOUR CALLERS Page 8-3
with a proper ID and RBBS-PC finds an individuation value or password that
is blank, it lets the caller set the value of those fields without
requiring a match. Subsequent calls, but not the first, must match the
value set for individuation and password.
Even though a SysOp can add a user and leave the password and individuation
blank, this still requires that the SysOp add the user only after an ID is
agreed to by both parties. What if this access is still not fast enough?
The solution provided by RBBS-PC is for the SysOp to "pre-load" IDs and
give out a pre-loaded ID to the caller for instant access, so that the
client does not have to wait even for the SysOp to add the ID. Since there
is no way to set in advance how a user wants to be identified, the SysOp
can set up essentially random account IDs which are difficult to guess.
Callers who pre-pay the subscription fees can be given a valid pre-loaded
ID for instant access. The ability of RBBS-PC to use any field for an ID,
and let the first call set individuation and password, means that RBBS-PC
can support boards where instant access is a critical part of their
service.
RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT Page 9-1
9. RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT
---------------------------------------------------
RBBS-PC has support built into it for managing access based on the date of
the call, and the time of day. As with the other RBBS-PC features, this
support is optional. The primary uses of this facility are:
- to make it very easy to control access based on subscription dates.
- to give callers a temporary, date-limited boost in privileges.
- to vary the amount of time that a caller has for a session based on
the time of day.
Once subscription management is configured, RBBS-PC handles all
subscription maintenance. After a user is registered, RBBS-PC will
automatically:
1) warn users before their subscription expires
2) reduce the security of callers whose subscription has expired.
The SysOp can send a message when the subscription is about to expire, by
creating the file RGXPIRE.HLP and placing it in the RBBS-PC help file
directory. The number of days before expiration to warn is set with CONFIG
parameter 50. When a caller's subscription expires, their security will be
updated, and the help file RGXPIRD.HLP (if it exists) will be displayed.
The subscription and time management system can also be used to grant
callers a temporary boost in privileges. For example, giving new callers a
"free" trial period.
Just as cable TV channels sometimes have a free week of viewing to attract
new subscribers, a SysOp of a subscription RBBS-PC can set up limited free
offers. By setting up a default subscription period of say, 5 days, all new
callers can be let onto to see whether they want to subscribe. After 5
days, security drops back down to a more limited level. This "free" period
can be made a standing offer, or turned off after a two week period. Or, a
user who requests a trial period can be individually added with a short
subscription period.
Limited trial subscriptions also are an attractive alternative for those
SysOps that do not give full privileges until after a caller is verified.
These callers are either asked to fill out a registration form or leave a
comment, and the SysOp later decides whether to increase the security
level. By letting new users have a short registration period with higher
privileges, say 3 days, a SysOp may choose to give new callers immediate
access, so the caller is not penalized while waiting for the SysOp's
decision. The SysOp need do nothing if a caller cannot be verified, as
RBBS-PC will automatically reduce their security in a few days. The SysOp
will manually raise the security of callers who are verified.
9.1 Setting It Up
-----------------
The subscription management system is turned on by specifying in CONFIG to
limit callers by subscription date. After access is so limited, RBBS-PC
automatically records the date of the first call. For old users, this will
be the first call made since RBBS-PC began to limit access. This recorded
date is the base registration date. The SysOp then needs to specify in
CONFIG:
- A default subscription period (the number of days a new user gets).
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 9-2
- A warning period (which determines when callers will get an advance
warning that their subscription is about to expire. The warning
period is the number of days left before triggering a warning.)
- The security level expired subscribers get.
In the PASSWRDS file, the SysOp designates different subscription periods
for each security level (other than the default security level). This
needs to be specified only if a subscription period is desired that will
override the default.
RBBS-PC determines when the subscription will expire by adding the
subscription period to the base registration date. Persons calling after
this expiration date are reduced to the expired security level set by the
SysOp in CONFIG.
The time management of RBBS-PC is automatically activated when the presence
of the PASSWRDS file is detected. See section 15.3 for a complete
description of the PASSWRDS file.
9.2 Allocating Time in Blocks
-----------------------------
SysOp function 5 allows the expired time to be set to a negative number.
Since the expired time is subtracted from the session time, a negative in
effect increases the session time. This ability lets the SysOp allocate
the user a "block" of time on the BBS, in addition to any normal session
time. This block can be used in a single session, or over different days.
There is no time limit on the use of the block of time, which never
expires. If desired then, subscription BBS's can sell time on the BBS in
blocks of session time rather than by date. For example, one might offer
o $10 per 5 hours of session time.
Then, upon payment, the SysOp would simply set the expired time to -300,
since the expired time is in units of minutes. This feature could also be
conveniently used to give
o people temporary excess time on the BBS.
If, for example, a caller needed say a hour and a half to get some
unusually large file, the SysOp could change the expired time to -90.
There would be no time limit on when the 90 extra minutes had to be used
and the SysOp doesn't have to make up some special security level. If the
caller used 50 minutes one day, then the expired time would set to -40,
leaving 40 additional minutes of session time to be used.
9.3 Banked Time
---------------
A caller can deposit unused session time in the time bank, to withdraw it
later to increase the session time. This allows callers to cumulate a
large session without requiring any special effort on the part of the
SysOp. The caller would simply go into the utilities section, use "B",
and then "D)eposit". Time deposited in the bank is immediately added to
the expired time of the caller and reduces the current session time.
Banked time is "global" in that, regardless of what subboard the time is
banked, it will be added to the logon user record and carry over to any
subboard when withdrawn from the bank. The banked time in a subboard will
RBBS-PC's AUTOMATIC SUBSCRIPTION/TIME MANAGEMENT Page 9-3
always show 0 even if it is banked while in the subboard. Hence, the user
will typically not be able to withdraw banked time when in a subboard.
The SysOp controls the maximum amount of time that can be deposited, for
any number of minutes from 0 (none allowed) to 255. The default maximum
allowed is specified by parameter 292 in CONFIG. The default amount that
CONFIG sets up for a new DEF file is 60. The default can be overridden for
any security level by specifying the max in the PASSWRDS file in the 13th
(last) position.
The SysOp function 5 allows the SysOp to reset both the banked time as well
as the expired time for a user, making it very easy to give users
additional time on the BBS.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-1
10. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC
---------------------------------------------------
The CONFIG program creates and edits the RBBS?PC.DEF files. These files
contain configuration information for each node of RBBS-PC. CONFIG also
edits the "sub-board" configuration files. Lastly, CONFIG contains
functions for periodic maintenance, such as create and pack MESSAGE and
USER files, renumber messages, and modem firmware initialization.
A sample RBBS-PC.DEF file is supplied with RBBS-PC. New SysOps are urged
to use this sample, as it will avoid many of the "first-time" setup errors.
Once you are comfortable with your RBBS-PC, CONFIG will allow you to shape
your BBS as you desire.
CONFIG is divided into many screens. They are:
Screen Description
1 Global RBBS-PC Parameters (Part 1 of 3)
2 Global RBBS-PC Parameters (Part 2 of 3)
3 Global RBBS-PC Parameters (Part 3 of 3)
4 RBBS-PC System Files (part 1)
5 RBBS-PC System Files (part 2)
6 Parameters for RBBS-PC "doors"
7 Parameters for RBBS-PC Security (part 1)
8 Parameters for RBBS-PC Security (part 2)
9 Parameters for Multiple RBBS-PC's and "conferences"
10 RBBS-PC Utilities
11 Parameters for RBBS-PC's File Management System
12 RBBS-PC Communications Parameters (part 1)
13 RBBS-PC Communications Parameters (part 2)
14 RBBS-PC Net Mail
15 New users parameters
16 Use of the Library Sub-System
17 RBBS-PC Color parameters
18 Reserved for future use
You may scroll forward or backward through the screens by using the PgUp
and PgDn keys on the keyboard. Additionally, you may go directly to a
specific screen by pressing a function key (F1 through F10) or SHIFT and a
function key (shift/F1 through Shift F7) corresponding to the page to be
selected. To terminate CONFIG, press the "End" key on the keyboard.
CONFIG can be invoked with the command:
CONFIG <config file>
The <config file> is an optional name of the configuration file to be
created or edited. If no config file is specified, CONFIG will edit the
file RBBS-PC.DEF in the current subdirectory. Each CONFIG parameter, and
the default values are explained in the following sections.
10.1 Global RBBS-PC Parameters (Part 1 of 3)
--------------------------------------------
Parameters 1 and 2 TOM MACK
The RBBS-PC system operator's (SysOp) first and last name. Enter your
REAL name here (the name you wish your callers to know you by). NO
ONE may log in to your RBBS-PC using this name, NOT EVEN THE SYSOP!
This is a security feature of RBBS-PC. The SysOp logs on with a
"pseudonym" (see parameter 121).
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-2
Parameter 3 EXPERT
Parameter 3 has nothing implemented.
Parameter 4 0800 to 2200
The SysOp's "office hours", or when a user can page the SysOp. If a
caller attempts to page you outside these hours, he will be told you
are not available, and RBBS-PC will suggest that he try a MSG or a
COMMENT. The times are set using a 24-hour military clock (i.e. 10:00
P.M. is 2200 hours). The SysOp can disable a caller's ability to page
him COMPLETELY by pressing the function key F4 while RBBS-PC is
running. F4 toggles the SysOp page status off and on.
Parameter 5 NO
Because the bell on an attached printer is often louder than the one
built into the PC, the SysOp can elect to have the printer's bell
used, rather than "beeping" the PC's speaker.
Parameter 6 YES
Should RBBS-PC automatically take itself off-line if a "disk full"
condition occurs. In some instances, such as having a small disk
volume for uploads, you may want your RBBS-PC system to remain online,
even though it is getting disk space full errors.
Parameter 7 OFF
The default setting for the "prompt bell". The prompt bell refers to
a preference some callers have of getting a short "beep" from the
system, whenever it pauses for input at a prompt. When this is on,
both the remote user and the local SysOp will hear the prompt bell
when input is required from the remote user, unless and until this
option is changed with the Toggle command on the Utility menu.
Parameter 8 72 MINUTES
The maximum amount of time (in minutes) each user is to be allowed on
the system per session (the "session" refers to any individual call to
the bulletin board). This is the default time limit, which only takes
effect if the PASSWRDS file does not override. See section 15.3).
Parameter 9 0 MINUTES
The default total amount of time (in minutes) a caller is allowed on
RBBS-PC per day. This is the default time limit, which only takes
effect if the PASSWRDS file does not override. See section 15.3).
Parameter 10 1
This allows a SysOp to "reward" users who upload files by adding time
to the users session when they upload. This number will be multiplied
by the time spent in upload, and credited to the user. Setting this
parameter to 1 will give back the user as much time as they spent
uploading, so their session time will look "frozen" during upload.
These time credits are normally removed at the end of a day, unless
the ratio you set is greater than 1. If so, CONFIG will ask if you
want to make the time credits "survive." If so, the extra time
granted the user will be available indefinitely, instead of only for
the current day.
Parameter 11 1
The number of months inactivity that must elapse before a user is
considered a candidate for deletion from the USERS file when the SysOp
"rebuilds" it.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-3
Parameter 12 RBBS-PC
Allows the SysOp to specify the name of the RBBS-PC that is to be
displayed when a user first connects with the system and prior to
completing the logon process.
Parameter 13-15 FG=7, BG=0, BORDER=0
Allow the SysOp to specify the colors desired for the console display.
Foreground, Background, and Border may be set. When specifying
colors, use the following:
0 = Black 4 = Red
1 = Blue 5 = Magenta
2 = Green 6 = Brown
3 = Cyan 7 = White
Add 8 to any number to set high intensity. Add 16 to turn blink on.
Parameter 16 NO
If the RBBS-PC computer can support ANSI, RBBS-PC will send ANSI
control sequences to display color and position the cursor. The local
display does NOT have to support ANSI in order for callers to receive
ANSI commands, although it does make the "snoop" function readable.
Parameter 17 123
The decimal value (0 to 255) of the character used to identify
"SmartText" codes. This should ALWAYS be set to 123. See section 7.9
for a detailed discussion of SmartText.
Parameter 18 AUTOPAGE.DEF
The file name that contains the information to control the "automatic"
RBBS-PC paging of the SysOp. See section 7.11 for a detailed
description of the AutoPage feature.
Parameter 19 OLD & NEW
The level of detail to use when notifying callers of electronic
messages. This can be set to (A)ll (old and new mail notifications),
(N)ew mail only, or (S)kip (no notification). See section 18 to get a
better understanding of the full flexibility of mail waiting
notification that has been built into RBBS-PC.
Parameter 20 2
RBBS-PC will try to determine whether the remote caller supports ANSI
screen commands by sending an ansi request and waiting for a reply.
This parameter sets the number of seconds to wait. A value of 0
disables the ANSI detect. The response is used to determine whether
a graphics version of the PRELOG file is displayed.
10.2 Global RBBS-PC Parameters (Part 2 of 3)
--------------------------------------------
Parameter 21 YES
Instructs RBBS-PC to remind users not only of the messages that are
for them, but also messages that they have left. This is to encourage
users to delete their old mail and help to keep the MESSAGES file to a
minimum.
Parameter 22 NO
Instructs RBBS-PC to remind users, when they login, how many files
they have downloaded and uploaded.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-4
Parameter 23 NO
Reminds users every time they log on of the preferences they have
selected for such things as file transfer protocol, graphics, nulls,
etc.
Parameter 24 NO
Allows users to download files immediately upon logging on to RBBS-PC.
Parameter 24 is only meaningful if the RBBS-PC File Management System
(FMS) has been enabled via parameter 214. RBBS-PC will scan FMS for
the newest uploads. When a caller logs on, RBBS-PC will determine how
many files are new since the caller last logged on. If parameter 24
is YES, the caller is offered the chance to immediately review these
new files and download them, if the caller has sufficient security to
download. This happens before the bulletins or messages are reviewed.
RBBS-PC's that emphasize software exchange may want to enable this
option, others may not want to give the caller a chance to download
the new files until after bulletins and messages have been reviewed.
Parameter 25 23
Allows the SysOp to establish a default page length for users when
they log on. The valid range is 0 to 255. If set to 0, the user will
receive continuously scrolling output.
Parameter 26 19
The maximum number (from 1 to 99) of lines allowed in each message.
Parameter 27 YES
Allows the SysOp to make the system "welcome" file interruptible. The
default is that YES it is interruptible. However, if the SysOp feels
too many people are bypassing it and it contains essential
information, the SysOp can set this parameter to NO (i.e. the user can
not suspend or cancel the listing of this file at their terminal with
a CTRL-S or CTRL-K). If the welcome file has intricate graphics,
interrupting it may leave the caller's screen in an odd color.
Parameter 28 YES
Allows the SysOp to indicate if the system bulletins are optional for
users when they log on. If bulletins are optional, callers can elect
to automatically bypass old bulletins and be notified only when there
are new bulletins. RBBS-PC will check the file date of the bulletins
and inform the caller which are new, with the option to read all of
the new bulletins. If none are new when bulletins are optional, the
bulletins will be automatically bypassed. See section 7.13.
Parameter 29 IBM PC
Tells RBBS-PC how to handle non-standard systems. The Compaq/Plus
uses interrupt X'7F', which is also used by MultiLink. RBBS-PC may
incorrectly detect MultiLink on a Compaq/Plus or other system that
makes use of interrupt X'7F', unless you select computer type 1. The
IBM PCjr's non-standard comm port mapping can be overcome if you
select computer type 2. Type 0 (IBM) and 3 (other) are treated the
same.
Parameter 30 - 34 (see CONFIG for defaults)
The symbol used to activate each online command can be changed. This
allows you great flexibility in how RBBS-PC interprets commands. You
can substitute any keyboard character for each command. To disable a
command, enter a single space for the symbol. One reason to change
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-5
commands is for macros. If you want to write an RBBS-PC macro that
acts as a "front end" for the command, you should first change the
symbol of the command to an unused, "hidden" symbol. Next, create the
macro, naming it the same as the original key. In the macro, you can
activate the original function by using the new "hidden" symbol.
Parameter 35 YES
Allows the section name to precede the command prompt. The section is
MAIN, FILE, LIBRARY, or UTIL, if this option is selected. Otherwise,
the prompt will begin with YOUR. Normally the section in the prompt
helps the caller remember where he is, but see section 7.5 for reasons
to suppress the section.
Parameter 36 YES
Suppresses the display of commands in the command prompt. By default,
RBBS-PC reminds the caller what commands are available by giving a
sorted list of the letters used for each command in the command
prompt. RBBS-PC shows only the commands available in the section that
the caller is in.
Parameter 37 NO
RBBS-PC will either restrict commands to those in the current section,
or will look in ALL sections for a valid command that matches the
caller's request. See section 7.4.
Parameter 38 YES
Instructs RBBS-PC to use machine language subroutines (rather than the
BASIC routines) for selected functions. RBBS-PC includes both BASIC
and machine language versions of several functions. The machine
language version is much faster, but may cause problems with some non-
standard systems. Normally, you should activate the machine language
version, but if you encounter erratic behavior, especially in locating
files on a machine that may not be 100% IBM compatible, try using the
BASIC subroutines.
Parameter 39 NO
Instructs RBBS-PC to use the BASIC language's PRINT statement to write
to the screen of the PC that RBBS-PC is being run on. This is
sometimes necessary in "hostile" environments (i.e. multitasking,
special screen drivers, etc.) where the use of RBBS-PC's default call
to the RBBS-PC screen driver ANSI is not viable.
Parameter 40 2
The maximum number of additional lines that a caller can use to
describe a file that was uploaded. It applies to both single FMS
directories and non-FMS directories. NOTE: This number counts the
EXTENDED description lines. RBBS-PC always allows a single-line
description.
10.3 Global RBBS-PC Parameters (Part 3 of 3)
--------------------------------------------
Parameter 41 (NAME)
Determines how callers are to be identified when they log in. By
default, RBBS-PC uses the NAME field in the USER file. You may
specify the starting offset of the field, and its size. WARNING:
misuse of this parameter could DESTROY your USER file!
Parameter 42 <none>
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-6
Allows an additional field to be used to distinguish callers with the
same ID (see section 8). Normally, this item is set to 0, which
instructs RBBS-PC to not allow callers with identical IDs.
Parameter 43 1
The offset into the USER record to be used to identify a user for
PERSONAL downloads. By default, RBBS-PC uses position 1, which is the
start of the caller's name.
Parameter 44 31
The length of the field used to identify a user for PERSONAL
downloads. By default, RBBS-PC uses 31 (the maximum length of a
user's name). The entries in the personal download directory must
have exactly this many bytes at the end -- plus one (for the flag used
to indicate if the file has been downloaded).
Parameter 45 FIRST name
The prompt that RBBS-PC should use when asking the caller for the
first ID field. When prompting for this input, RBBS-PC will prepend
"What is your" to the prompt.
Parameter 46 LAST name
The prompt that should be used for the second ID field.
Parameter 47 NO
Activates upload/download ratios. See section 15.3 for a discussion
of the flexibility of RBBS-PC ratios. NOTE: If you elect to enforce
ratios, fields in the USER record are used to store ratio information.
See Appendix A for details.
Parameter 48 NO
Activates automatic security level reduction via Subscription date.
See section 9 for a complete explanation of subscriptions.
Parameter 49 5
The security level to which callers will be set when their
subscription expires (see section 9). A default value which can
overridden for security levels in the PASSWRDS file.
Parameter 50 60
The number of days that RBBS-PC will send warnings BEFORE a caller's
subscription is to expire. The file RGXPIRE.HLP can be customized to
inform the caller that the subscription is about to expire, and what
to do.
Parameter 51 365
The default number of days in a subscription period. When a caller
logs in this many days after their subscription began, RBBS-PC will
notify them of the expiration, display the file RGXPIRD.HLP, and
reduce their security to the level specified in parameter 49.
Parameter 52 NO
Instructs RBBS-PC to turn off printer logging each time RBBS-PC
"recycles" at the end of a call. Since printer errors will often
"hang" a system (especially if no printer is present), this function
can avoid errors caused by the SysOp accidentally activating RBBS-PC's
printer log function. Of course, if you wish to use the printer
logging feature, you must set this parameter to NO.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-7
Parameter 53 NO
Instructs RBBS-PC to play musical themes for auditory feedback on what
is happening on the BBS. This can be important for SysOps that are
sight impaired. These musical themes are "played" on the speaker of
the PC that is running RBBS-PC, but not transmitted to the caller.
Song played Meaning to SysOp
---------------------------------------------------------
"Consider Yourself" User log-on
"Walk Right In" New User log-on
"Dragnet Theme" Security violation
"Goodbye, Charlie" User log-off
"Taps" Caller denied access
"Oom Pah Pah" User downloading file
"Thanks for the Memories" User uploading file
Parameter 54 128
The buffer size used internally by RBBS-PC when displaying text files
such as menus, directories of files, etc. The size can range from 32
to 4096 characters. The bigger the buffer, the fewer disk accesses
necessary to display the file and the faster the display will be. The
default of 128 is the minimum recommended. Increasing this to 512
will increase the speed of text displays. However in some
environments where it is important to respond quickly to XON/XOFF
control, this should be set to the minimum of 32.
Parameter 55 1024
Sets the size of RBBS-PC's internal "stack." The internal stack is
used by RBBS-PC to keep track of program flow. The recommended value
is 2048. If you must conserve RAM usage, this number can be
decreased, but program errors such as "Stack overflow" and "String
Space Corrupt" could result.
Parameter 56 is not implemented in RBBS-PC.
Parameter 57 CITY and STATE
Specifies the prompt RBBS-PC should use when requesting the caller's
city & state. If you would like to record information other than city
& state in this USER field (telephone number, for example), change
this prompt accordingly.
Parameter 58
No value is specified for this parameter.
Parameter 59 1024
Specifies the buffer size used during INTERNAL protocol transfers.
This is the amount of data stored before it is written to disk on
upload, or the amount read from disk at a time on download. The range
is 128 to 8192 characters (1024 is recommended).
Parameter 60 <none>
Specifies that either a Computalker (B.G. MICRO, P.O. Box 280298,
Dallas, Texas 75228) or HEARSAY 1000 (HEARSAY Inc., 1825 74th Street,
Brooklyn, N.Y. 11204) speech board is being used. This is in support
of the sight impaired SysOps. These voice synthesizers can speak
status messages that are usually either written to the CALLER log or
printed to the printer. With this, a sight-impaired SysOp can hear
what the caller on the BBS is doing.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-8
To support as many speech boards as possible in the future, RBBS-PC uses a
64 entry file (RBBSTALK.DEF) to contain SysOp-definable fields. The file
is accessed randomly with fixed-length 32 byte records. The last two bytes
must contain CR/LF leaving 30 bytes available for the text. The 64 records
are predefined and used by RBBS-PC as follows:
1 = LOGON USER MESSAGE
2 = MAIN MENU PROMPT
3 = FILES MENU PROMPT
4 = UTILITY MENU PROMPT
5 = DOOR MENU PROMPT
6 = LIBRARY MENU PROMPT
7 = LOGOFF MESSAGE
8 = DOWNLOAD PROMPT
9 = UPLOAD PROMPT
10 = TIME REMAINING PROMPT
11 = WELCOME BACK PROMPT
12 = CONFERENCE MENU PROMPT
13-64 available for future enhancements
SmartText IS supported in the RBBSTALK.DEF records.
The CompuTalker requires the use of COM2, so the modem used by RBBS-PC must
NOT be connected to COM2.
10.4 Parameters for RBBS-PC System Files (part 1)
-------------------------------------------------
Parameter 61 \BULLET
The path and name of the text file that describes the BULLETINS.
RBBS-PC uses the path of this file to find ALL bulletin files.
Parameter 62 6
Instructs RBBS-PC to use "numbered" bulletins, and tells RBBS-PC how
many numbered bulletins to look for (see section 7.13).
Parameter 63 BULLET
Specifies the PREFIX of the Bulletin files. Ex: If the prefix is "B",
and a user asks to see bulletin INFO, RBBS-PC will look for the file
"BINFO" in the same directory as the file specified in parameter 61.
Additionally, if the file "BINFO.MNU" is found, RBBS-PC will activate
the Sub-Menu feature (see section 7.7). If the user has specified
graphics or color display, the files, RBBS-PC will also search for the
files "BINFOG" and "BINFOC" (see section 6.3).
Parameter 64 (default drive)
Specifies the disk drive and path on which RBBS-PC will find on-line
"help" files.
Parameter 65 HELP0
Specifies the prefix for the last remaining "old-style" help files.
These files are supplied with RBBS-PC, and the prefix is "HELP."
There is no reason to change this parameter.
Parameter 66 HLP
Specifies the EXTENSION for the "new-style" help files. A full set of
online help is provided with RBBS-PC. There is no reason to change
this parameter, but if you do, all .HLP files must be renamed. Any
additional help files you wish to create should have this extension,
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-9
and be in the directory specified in parameter 64. If so, RBBS-PC
will treat your help files as if they were part of RBBS-PC, displaying
them to callers when they are requested.
Parameter 67 UPCAT
The help file shown to callers when RBBS-PC asks them to categorize an
upload. With FMS directories (see section 12), a caller can specify
the category code for their upload. You need only specify the base
file name in this parameter. RBBS-PC will add the help file PATH (as
specified in parameter 64) and the EXTENSION (as specified in
parameter 66). This file should contain a description of each
category, so the uploaded can properly categorize the upload.
Parameter 68 NEWUSER
The path and filename of the file new users see when they first log on
and before they "register" themselves in RBBS-PC's USERS file. A user
sees it once and only once during his first session.
Parameter 69 WELCOME
The path and filename of the file each user sees EVERY time AFTER they
log on.
Parameter 70 MENU1
The path and filename of the SysOp command menu, shown to callers in
NOVICE mode who have access to SysOp commands.
Parameter 71 MENU2
The path and filename of the MAIN section menu.
Parameter 72 MENU3
The path and filename of the FILE section menu.
Parameter 73 MENU4
The path and filename of the UTIL section menu.
Parameter 74 CONFENCE
The path and filename of the Conference description file. RBBS-PC
uses this file when a caller asks for a list of your conferences, and
also uses the file to validate a JOIN command. In order for the JOIN
to work, the conference name (seven characters or less) must appear IN
CAPS, at the beginning of a line (preceding spaces are allowed). The
SysOp must already have pre-formatted the messages and users files
associated with the conferences (see section 17.3). RBBS-PC will look
for conference MESSAGE files in the path specified in this parameter
after searching where the main MESSAGE file is located.
Parameter 75 MENUA
The path and filename containing the list of the questionnaires
callers can answer on-line (see section 19). Before RBBS-PC will
allow a caller to answer a questionnaire, it will look for the
questionnaire name specified (seven characters or less), IN CAPS, at
the beginning of a line in this file (preceding spaces are allowed).
Parameter 76 (default drive)
The drive and path where the questionnaire files are located.
Parameter 77 MAIN.PUI
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-10
The path and filename of the "Programmable User Interface" to be used.
See section 7.6 for a fuller description of RBBS-PC's PUI. CONFIG
will add the extension ".PUI" to this file. If this file is not
found, RBBS-PC uses the standard interface.
Parameter 78 YES
Specifies whether RBBS-PC should insert page-breaks in menus.
Normally, you will want RBBS-PC to insert page-breaks when needed,
unless you have written "full-screen" menus which do ANSI cursor
positioning. In this case, the lines in the menu files may not
accurately reflect the lines used on the callers screen.
Parameter 79 (default drive)
The drive and path where RBBS-PC macros are stored.
Parameter 80 <none>
The extension for RBBS-PC macro files (usually .MCR). See section 7.8
for a full description of RBBS-PC's macro capabilities.
10.5 Parameters for RBBS-PC System Files (part 2)
-------------------------------------------------
Parameter 81 TRASHCAN
The path and filename of the "illegal name" file. This file is used
when a new user signs on. The new users first and last name are each
individually checked against the names in this file, as well as the
entire name.
The format of this file is as follows:
<name>,
An example of such a file would be:
BITE,
BYTE,
PAPA DOC,
DOCTOR,
DEATH,
GLADIATOR,
KILLER,
MAN,
THE
The comma is optional after each name. However, it does help in
delineating exactly what character strings are being searched for and
compared against (some text editors may add extraneous and non-visible
characters to a line). All names should be UPPER CASE! If the above file
existed, any new user who logged and used the following names would be
denied access:
Byte Killer
Kilo Man
Doctor Death
PC Doctor
Pappa Doctor
but "Hoppa Pappa" would be fine.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-11
Parameter 82 <none>
The path and filename of the "required" questionnaire. RBBS-PC
records in the users record when the required questionnaire is
answered so that it will only ask each caller once. Both first-time
and old callers will be required to answer this questionnaire. When
you install a new required questionnaire, use CONFIG parameter 186 to
mark all user records so they will once again be required to answer
the questionnaire. NOTE: Parameter 82 allows you to specify a path.
RBBS-PC will not automatically look in the path specified in parameter
76.
Parameter 83 PRELOG
The path and filename displayed to callers as soon as carrier is
detected and BEFORE a user can log on. It is displayed immediately
after the name of the RBBS-PC is shown (see parameter 12). SysOps
should use this file to convey such information as whether real names
are required, 300 baud users will automatically be denied access, etc.
Parameter 84 RBBS-REG.DEF
The path and filename of the optional questionnaire RBBS-PC will
require new users to answer on their first call. See section 19 for
details on RBBS-PC questionnaires.
Parameter 85 EPILOG.DEF
The path and filename of the optional questionnaire RBBS-PC will ask
each caller when they log off each time from your RBBS-PC (see section
19).
Parameter 86 MESSAGES
The path and filename of the RBBS-PC message file. This file contains
all messages entered by callers, as well as configuration data. If
this file does not exist when you run CONFIG, CONFIG will ask if it
should create the file.
NOTE: Read section 18 if you want to include the main message file in the
scan for conference mail waiting.
Parameter 87 USERS
The path and filename of the RBBS-PC USER file. This file is where
RBBS-PC keeps track of the name and profile for each caller.
Parameter 88 COMMENTS
The path and filename where RBBS-PC will store comments that callers
leave to the SysOp. Even if comments are recorded as private messages
(see parameter 89), you should specify a COMMENTS file, since RBBS-PC
will place comments here if the MESSAGE file is full. RBBS-PC will
automatically create the COMMENTS file when needed.
Parameter 89 NO
Allows SysOps to have comments recorded as private messages to them in
the main messages file providing there is any room. This allows
replies to comments to be done much more easily.
Parameter 90 CALLERS
The path and filename for RBBS-PC's CALLER log. RBBS-PC will create
this file, and log the date and time of each caller to the BBS.
Information such as uploads and downloads, security violations and
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-12
communications parameters are also logged. SysOp function 2 will
display this information.
Parameter 91 NO
Specifies that RBBS-PC should log the following additional information
in the callers log:
1) Connect not completed 9) Left comment at time
2) Sleep disconnect 10) Logged off at time
3) Caller changed name/address 11) Carrier dropped at time
4) Newuser 12) Message # xxxx left at
5) Bulletin x read 13) Read Messages ...
6) SysOp initiated Chat 14) Answered questionnaire xxx
7) Entered Conference/Sub-board x 15) Killed msg # xxxx
8) Time limit exceeded
NOTE: Each CALLER log entry uses 66 bytes of disk storage. Using parameter
91 can provide useful information, but you should monitor the size of your
CALLER log so it does not consume your entire disk!
Parameter 92 has not been implemented in RBBS-PC.
Parameter 93 CONFMAIL.DEF
The path and filename for the conference mail-scan file. This file
tells RBBS-PC which conferences should be checked when a caller wants
to scan for new mail. The format of this file and the flexibility it
affords the RBBS-PC SysOp is described more fully in section 18.
Parameter 94 30
The maximum number of "working variables" that RBBS-PC allocates for
questionnaires and macros. A "working variable" is simply a place in
which RBBS-PC can store a response or a set of characters. These
"working variables" can then be used to create parameters that can be
passed to "DOOR"s (see section 14.3) or written out to data bases (see
section 7.8.4).
Parameter 95 CALLLST.DEF
List of callers files that can be viewed using SysOp function 2,
recent callers option. On each line, the first word is the
drive/path/name, followed by a description of what they callers file
is for. For example, if there are two nodes, with callers files
CALLERS stored in C:\RBBS\NODE1 and C:\RBBS\NODE2 respectively, then
the file would be
C:\RBBS\NODE1\CALLERS Node 1
C:\RBBS\NODE2\CALLERS Node 2
Parameter 96 8
The copyright notice with RBBS-PC is displayed only on node 1. This
parameter sets the number of seconds to display the notice. A value
of 0 disables the display.
Parameter 97 NO
Disables message "quoting" during reply. When this option is set to
"YES", the caller will not be asked whether to include the original
message when creating a reply.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-13
10.6 Parameters for RBBS-PC "Doors"
-----------------------------------
Parameter 101 NO
Activates the DOOR function. See section 14 for a complete
description of the RBBS-PC door subsystem.
Parameter 102 MENU5
The path and filename of the DOOR menu, which RBBS-PC will show to the
caller when a list of doors is requested. Before RBBS-PC will allow a
caller to open a door, it will look for the door name specified (seven
characters or less), IN CAPS, at the beginning of a line in this file
(preceding spaces are allowed).
Parameter 103 RCTTY.BAT
The path and filename of the .BAT file RBBS-PC should create when
building a "door" exit. The batch file that invokes RBBS-PC must
check if this file exists whenever RBBS-PC terminates and (if it
exists) execute it (see section 13). This is also the same file name
that is used when the SysOp exits to DOS.
Parameter 104 RBBS.BAT
The path and filename of the .BAT file used to start RBBS-PC. This is
used to re-invoke RBBS-PC after a door (see section 13). This is also
the same file name that is used when the SysOp returns from exiting to
DOS.
Parameter 105 C:\
The DOS subdirectory where RBBS-PC can find the DOS command processor
(COMMAND.COM). This is also the location for the .BAT files which
test and convert compressed uploads.
Parameter 106 YES
The method used to redirect I/O when dropping to DOS as a remote SysOp
(command "7"). Answering YES selects the standard DOS "Change Console
Command" (CTTY), NO selects the DOS redirect function (">" or "<").
This parameter allows you to specify if the redirected output is to be
handled by a SysOp-supplied device driver. If you don't elect to use
a special device driver, RBBS-PC will redirect the output directly to
the communications port by building the command "CTTY COMx" or ">COMx
and <COMx" , where "x" is based on the communications port the node
was configured for. If you specify the name of a device driver,
RBBS-PC will build the command CTTY [driver name].
Parameter 107 <none>
The path and filename of a program (i.e. an .EXE or .COM file) that is
to run when a new user logs on. This feature is intended for those
who feel the need to perform an extensive verification of new users
that is not met by RBBS-PC's built in scripting capability or
automatic subscription functions.
Parameter 108 0
Allows the external program designated via parameter 107 to be invoked
for not only new users, but also for callers who have a security level
equal to or less than the security level specified in parameter 108.
Parameter 109 DOORS.DEF
The path and filename of the "DOORS" control file. See section 14.3
for more information.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-14
10.7 Parameters for RBBS-PC's Security (part 1)
-----------------------------------------------
Parameter 121 SECRET NAME
The first and last name of the SysOp pseudonym. It is this name that
causes RBBS-PC to recognize the remote caller as the SysOp and not
simply a user with a security level equal to that of the SysOp. This
should be a first and last name combination that is not likely to be
selected by other callers. The name supplied in parameters 1 and 2
cannot be used by ANYONE to log on. If the SysOp wants to log on
remotely, the name in parameter 121 must be used.
Parameter 122 NO
If YES, specifies that a LOCAL logon (via the ESC key) should logon as
the SysOp automatically. NO will prompt for a name before allowing
anyone to log on locally.
Parameter 123 0
The minimum security level users need in order to log onto RBBS-PC.
Callers with a security level less than this number will be given an
"ACCESS DENIED" message and immediately disconnected.
Parameter 124 5
The security level assigned to new users. If this security level is
less than the minimum security level to log on, no new users can log
on. This means that no new users are allowed and access is limited
only to pre-registered users.
Parameter 125 10
The minimum security level a user must have in order to be considered
a SysOp. Even if a user has a high enough security level to see the
SysOp menu and execute some or all of the SysOp commands, the user
will not be treated as a SysOp (i.e. allowed to see the files
upload/download when viewing the CALLERS file) unless the users
security level is equal to or greater than that specified by this
parameter.
Parameter 126 10
The minimum security level required to see the SysOp menu. This does
not give a user SysOp access, it only allows him to see the menu of
SysOp commands.
Parameter 127 10
The minimum security level a user must have to leave an extended (i.e.
multiple line) description of a file that was uploaded. See parameter
40 for the maximum number of lines that an extended description will
be allowed to have.
Parameter 128 5
The maximum number of security violations (i.e. attempts to download
protected files) before the user is logged off and locked out.
Parameter 129 10
The minimum security level to access each SysOp function. These may
all be set to the same level, or each command can have a different
minimum security level.
Parameter 130 <variable>
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-15
The minimum security level to access the MAIN commands. These may all
be set to the same level, or each command can have a different minimum
security level.
Parameter 131 <variable>
The minimum security level to access the FILE commands. These may all
be set to the same level, or each command can have a different minimum
security level.
Parameter 132 5
The minimum security level to access the UTILITY commands. These may
all be set to the same level, or each command can have a different
minimum security level.
Parameter 133 <variable>
The minimum security level to access the GLOBAL commands. These may
all be set to the same level, or each command can have a different
minimum security level.
Parameter 134 3
The maximum number of times a user can change their password in a
given session. This prevents a caller from "fishing" for special
passwords.
Parameter 135 5
The minimum security level required in order for users to access
privileged group passwords. If the user's security is less than this
level, ALL password changes that they make will be permanent -- even
if the password they select is in the temporary password file named in
parameter 146.
Parameter 136 10
The minimum security level required to overwrite on uploads. Users
with this security level can REPLACE EXISTING FILES by uploading a
file with the same name.
Parameter 137 10
The minimum security level "exempt" from packing. When the SysOp
packs the user file, callers with this security level or greater will
NOT be removed from the user file, even if they have not called in the
number of months specified in parameter 11.
Parameter 138 5
The default security level of new PRIVATE messages. Only those with
this security level or higher can read new private messages -- even if
they have been addressed to them. This allows the SysOp to "preview"
messages, and then lower the security level of each message so that
the addressee can read it.
Parameter 139 5
The default security level of new PUBLIC messages. Only those with
this security level or higher can read new public messages -- even if
they have been addressed to them. This allows the SysOp to "preview"
messages, and then lower the security level of each message so that
every user can read it.
Parameter 140 10
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-16
The minimum security level required to change the security level of a
message.
10.8 Parameters for RBBS-PC's Security (part 2)
-----------------------------------------------
Parameter 141 is not implemented in RBBS-PC.
Parameter 142 <default dir>
The drive and path where the "personal" files are located. If a file
listed in the directory is not found here, the download drives will
then be searched, so it is not necessary to have a copy of a file here
in order to use personal downloads. However, files in this directory
can be protected so that ONLY personal download will access the files.
Parameter 143 PRIV.DEF
The name of the "personal directory." If no extension is specified,
".DEF" will be used. If not path is specified, the path in parameter
142 will be used.
Parameter 144 <none>
The default protocol to be used when downloading personal files. If
no protocol is specified, the "P" command behaves exactly the same as
the D)ownload command. If a protocol is specified, it will be used
unless overridden by the command line (i.e. "P file.ext Z").
Parameter 145 FILESEC
The path and filename of the "file security" list. See section 15.4
for more information.
Parameter 146 PASSWRDS
The path and filename which contains the privileged group passwords
and security-level limits. See section 15.3.
Parameter 147 NO
Specifies that multi-file personal downloads using ASCII should be
done "non-stop." This is useful if the SysOp wants users to download
to a continuous feed printer.
Parameter 148 10
The minimum security a user must have in order to "categorize" uploads
when the SysOp is using the File Management System (FMS). Uploads by
callers with insufficient security to categorize will be placed in the
default "upload" category.
Parameter 149 5
The minimum security to view NEW uploads. RBBS-PC will omit either
ALL files in the "upload" directory, or only those files in the
"upload" category (if the upload directory is the master FMS
directory).
Parameter 150 6
The minimum security to bypass the "epilog" questionnaire, specified
in parameter 85.
Parameter 151 5
The minimum security level required to automatically add a user to a
conference. This parameter is only active when CONFIG is in
"conference maintenance" mode (see parameter 167). If a caller tries
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-17
to join a conference, they will be denied access unless they are
already a member, or their security is at or above this level. Each
conference may have a different setting for this parameter. NOTE:
Sub-boards do NOT use this feature. To restrict access to a
Sub-board, use parameter 123.
Parameter 152 6
The minimum security level for a caller to "turbo logon". This
feature allows a caller to go DIRECTLY to the main menu, bypassing the
welcome, new upload and bulletin displays. To use "Turbo logon", the
user must answer the "What is your FIRST name" prompt with:
firstname lastname password ![conference]
The "!" after the password signals RBBS-PC to use "turbo." If the
conference name is omitted, the caller will be left in the MAIN
conference. If the caller substitutes a "$" for the "!", only the
WELCOME will be bypassed. This is helpful for systems with extensive
ANSI welcome screens that can be tedious for old callers.
Parameter 153 10
The minimum security required by a caller to add a description for an
existing file. Typically this is restricted to the SysOp only. It
can be used by the SysOp to create FMS directories. After placing the
files in the upload subdirectory (or anywhere in the download path)
the SysOp can use RBBS-PC to add descriptions for the files. RBBS-PC
will first ask if you wish to OVERWRITE the file. If you answer NO,
RBBS-PC will then ask if you wish to add a description. In this way,
RBBS-PC will properly build the directory entry.
Parameter 154 SECVIO.HLP
The name of the help file that is shown to a caller whenever the
caller incurs a security violation. RBBS-PC will add the HELP
directory and EXTENSION (from parameters 64 and 66).
Parameter 155 <none>
Denies callers access to one or both of RBBS-PC's "premium features --
DOORS and file downloading, for a specific period of time. This can
be used to direct the callers' attentions to other features of RBBS-PC
(such as message bases). The PASSWRDS file (see section 15.3)
specifies how many SECONDS the caller must be online before the
premium features are available. If a caller tries to use a locked
feature before the time has elapsed, the caller will be given a
message and denied access. This is *NOT* recorded as a security
violation.
The file TIMELOCK.HLP should be placed with the other RBBS-PC HELP files.
This file (if found) will be shown to a user who is locked out of a
command. If the TIMELOCK.HLP file is not available, the caller will be
given a "canned" message: "Sorry, (name), try that function later."
Parameter 156 10
The minimum security to be exempt from automatic security updates. If
the caller's MAIN security level is changed, their security level in
conferences will also be changed if their security in the conference
is less than this setting. This allows the SysOp to adjust their
security in the MAIN conference, and RBBS-PC will make the adjustments
in each conference and sub-board. If the SysOp increases a caller's
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-18
security in a conference (to make them a "SIGOp"), the caller will
maintain this increased security only if it is above this setting.
Parameter 157 10
The minimum security a caller must have to be able to read and kill
all messages (in the message base for which this is a .DEF file).
This allows the SysOp to create an "assistant MESSAGE SysOp", or
"SIGOp" who can police message traffic, without granting that user
full SysOp privileges.
Parameter 158 SEEN-BY:
Specifies a text string that, if found at the start of a message line,
will NOT be shown to the caller. This can be used to hide the
sometimes enormous network routing data found in network mail.
Parameter 159 10
Minimum security to do personal uploads. Personal uploads are the
file equivalent of personal mail, where the upload addresses the file
to a particular person. The personal upload description goes into
the personal directory and is viewable only by the SysOp and the
person the file is addressed to. The uploader has the option to send
the file to multiple people and to use a distribution list installed
by the SysOp.
Parameter 160 NO
Whether to let messages have multiple recipients. NO means that the
message can be addressed only the one person, which is the way all
RBBS-PC message bases were prior to version 17.4. YES means that the
person leaving a message will be asked if the message is to be carbon
copied to another person. Up to 255 names can be specified, and a
distribution list installed by the SysOp can be used as well. One
copy of the message is kept with multiple headers. WARNING: external
utilities that read and write RBBS-PC message bases may be unable to
deal with multiple headers.
10.9 Parameters for Multiple RBBS-PC's/Conferences
--------------------------------------------------
Parameter 161 1
The maximum number of RBBS-PC nodes. Up to 36 RBBS-PC's can share the
same files. Different environments have different maximum number of
nodes that they can effectively support. Setting this parameter
configures the MESSAGE files so they contain the appropriate number of
"node" records.
Parameter 162 DOS
The environment that multiple copies of RBBS-PC will be sharing files
in. This is necessary so that RBBS-PC can use the mechanism that is
appropriate to the specific environment when sharing files. RBBS-PC
currently can handle the following environments for multiple
RBBS-PC's:
0) Single node under DOS
1) MultiLink (The Software Link, Inc.)
2) OmniNet (Corvus)
3) PC-Net (Orchid)
4) DESQview (Quarterdeck Office Systems)
5) 10 Net (Fox Research)
6) IBM's NETBIOS
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-19
NOTE: Many manufacturers utilize Orchid's network conventions. As an
example, AST and Alloy are both vendor's whose "network" is .EXE file-
compatible with Orchid's. If you have a network of PC's, check with
the vendor to see how compatible their network is with those supported
by RBBS-PC.
Parameter 163 INTERNAL
Specifies the method RBBS-PC uses to recycle after a call. INTERNAL
recycling is done within the RBBS-PC.EXE file. SYSTEM recycling exits
RBBS-PC, and expects the invoking .BAT file to recycle. Internal is
faster, but System allows an external event to be processed after each
caller.
Parameter 164 8
The number of records in the USERS file. This number must be an even
power of 2 (256, 512, 1024, 2048, etc.). When the USER file is almost
full, the SysOp will either have to "rebuild" the user file (see
parameter 182) or increase this file size. The SysOp can check on the
freespace in this file with the RBBS-PC "statistics" command (UTIL
section). Parameter 291 lets new users on even if the users file is
full.
Parameter 165 27
Specifies the default number of records in the MESSAGES file. Each
file is 128 bytes. The number of messages that can be stored is a
function of the number of lines allowed per message. The minimum size
of the MESSAGES file is equal to 1 (The "checkpoint" record) plus the
maximum number of concurrent RBBS-PC's ("node" records) plus the
maximum number of messages allowed multiplied by 5 (each messages is
assumed to average five 128-byte records)
Parameter 166 5
The maximum number of messages allowed in the message file at any one
time. The absolute upper limit on the number of messages is 999.
If you specify 250 messages, you can expect that the MESSAGES file
will be formatted to more than 160K in size. If you allow the message
file to grow (parameter 170), only parameter 166 will limit the growth
of the file. If your message file does not grow, both the number of
messages, and the number of records will limit how many messages can
be left.
Parameter 167
Enters "conference maintenance" This allows you to set features or do
maintenance on CONFERENCES (not Sub-boards!). You will be asked for
the conference name, which can be up to 7 characters (CONFIG will add
an "M" to the conference MESSAGE filename, and a "U" to the USER file
name). While in conference maintenance mode, you can create
conference message and user files, perform maintenance on them, or set
conference variables (see parameter 151. To perform maintenance on a
Sub-board, you should start config with the sub-board .DEF file (i.e.
CONFIG MYSUBC.DEF). If you change the size of a conference MESSAGE or
USER file, the change will take place when you press the END key while
in conference maintenance mode.
Parameter 168 ZIP
The default file extension for uploads and downloads. If a file is
UPLOADED, and the user does not specify an extension, this default
will be used. If a file DOWNLOAD request does not specify an
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-20
extension, the default will be used. In order to upload files with NO
extension, a "." must follow the name (i.e. U MYFILE. Z).
Parameter 169 <none>
Additional file extensions in addition to the default, to search when
looking for an uploaded file, to decide if it is already present. A
file will be considered already in the catalog if the prefix matches.
Warning: this search can be time consuming unless you have installed
the Fast File Search. Every extension listed should begin with a
period. E.g. ".ARC.PAK" would count an upload of XYZ.ZIP as a
duplicate if the file XYZ.PAK or XYZ.ARC exists.
Parameter 170 NO
Allows the MESSAGE files to "grow." If the limit on active messages
(parameter 166) has not been exceeded, and the number of records has
been exhausted, RBBS-PC will increase the size of the message file to
accommodate more messages. NOTE: The Corvus Network software does not
allow a message file to grow.
Parameter 171 DISTRI
Name of the file storing a list or menu of distribution lists. A
distribution list can be used as the answer to the question of who the
message is to, if parameter 160 is set to enable carbon copy.
Parameter 172
Drive/path where distribution lists are stored. A distribution list
must have the extension ".LST". For example, the file BOARD.LST
would be invoked by selected D)istribution, then "BOARD". The file
should have each name on a line, as in
SAM SPADE
SMART MONEY
JOHN DOE
Parameter 173 URP
Message protection allowed. Individually specified for each message
base. Can elect to have any combination of public, private, or
password protected, so long as at least one is picked. Default is to
allow all three.
10.10 RBBS-PC SysOp Utilities
-----------------------------
Parameter 181
Packs the message base. When a message is "killed," the space used
by that message is not freed (this allows a message to be
"resurrected). Parameter 181 makes a backup of the message file, then
reclaims the space used by killed messages.
Parameter 182
Removes deleted users and users who have not been on the system within
the number of months specified in parameter 16. You should have
enough free disk space for a second copy of the users file (with a
qualifier of ".BAK") or the rebuilding will terminate abnormally (the
users file will be restored). NOTE: Locked-out users (security less
than 0) will not be removed from the file.
Parameter 183
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-21
Displays the message headers of all messages, active and killed, that
are present in the message file. This is left over from one of the
many "debugging" stages of RBBS-PC prior to CPC09. Following the
policy of making all changes "additive", this function has been
retained. It may help some SysOps recover from disk hardware
failures.
Parameter 184
Renumbers messages. An RBBS-PC message number cannot be higher than
9999. This function will renumber the active messages, utilizing
numbers once used by deleted messages. Also, each caller's high-
message pointer will be updated to reflect the renumbered message.
Parameter 185
Scans the message file and reconstructs the chains that link the
messages together. Message files that have "blank" messages or
abbreviated messages (i.e. some lines of text are missing) can be
repaired with this facility.
Parameter 186
Sets a flag in all USER records that will require the user to answer
the required questionnaire (see parameter 82).
Parameter 187
Scans the FMS directory to be sure each record conforms to the exact
format required by the FMS (in case the text editor used by the SysOp
to edit the file inserted tabs or shorten lines that had trailing
blanks at the end of them).
Parameter 188
Scans the PERSONAL download directory to be sure the format is proper
for a PRIV.DEF file.
Parameter 189
This parameter will guide the SysOp, sequentially, through only those
parameters that would normally have to be changed when setting up a
new RBBS-PC.
Parameter 190
This parameter will guide the SysOp, sequentially, through the
parameters that are new and/or changed for the current release of
RBBS- PC.
Parameter 191
Will turn the "printer enabled" flag off in all the node records.
This is useful if somehow the printer is accidentally enabled, but no
printer exists (a condition which will halt RBBS-PC).
Parameter 192
Scans the USER file and turns the "highlight" feature off for any user
who did not select COLOR. This will rescue confused callers from the
problem of receiving ANSI sequences when their terminal does not
support ANSI.
10.11 RBBS-PC's File Management System Parameters
-------------------------------------------------
Parameter 201 C:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-22
The drive letter where uploads should be placed. Enter only the DRIVE
letter here. The exact subdirectory can be entered in parameter 208.
Parameter 202 99
The name of the directory file where RBBS-PC should place upload
descriptions. This upload directory can be the master FMS directory,
or a separate upload directory.
Parameter 203 C:
The drive/path were the upload directory is to be found.
Parameter 204 C
The letters of the drives from which files can be downloaded. The
order in which they are specified is the order in which the drives
will be searched. If the order is BAC, then drive B will be searched
first for the file, then drive A, and finally drive C. While there
can be duplicate files on each of the drives, the first file found
will be the one downloaded to the user.
Parameter 205 NO
Specifies that DOS subdirectories are used. This is a reflection of
RBBS-PC's early history (before DOS supported subdirectories) and
should always be set to YES.
Parameter 206 NO
Specifies that uploads are to be sent to DOS subdirectories. This is
a reflection of RBBS-PC's early history (before DOS supported
subdirectories) and should always be set to YES.
Parameter 207 NO
Specifies that downloads are separated into DOS subdirectories. This
is a reflection of RBBS-PC's early history (before DOS supported
subdirectories) and should always be set to YES.
Parameter 208
Specifies the DOS subdirectory where UPLOADS are placed, and a list of
subdirectories where DOWNLOADS are searched. This is only functional
if you have responded "Yes" to either parameter 206 or parameter 207.
The FAST FILE SEARCH can be used in conjunction with this directory
list to find downloads (see section 12.9).
Parameter 209 DIR
The file extension for RBBS-PC directory files.
Parameter 210 <none>
An alternative extension to be used for "directory" files. The main
use for an "alternate" extension is to allow "sub-boards" to share
directories using the main extension (parameter 209), but also have
some directories unique to the "sub-board" that are not shared with
others.
Parameter 211 DIR
The name (prefix only) of the directory of directories. This file
lists either the names of other .DIR files, or FMS category codes (see
section 12).
Parameter 212 NO
Allows the SysOp to exclude the directory of directories from the
search done by the New command. If your directory of directories
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-23
does not contain FILE descriptions, but only directory descriptions,
you will probably not want it searched by the "new" command.
Parameter 213 NO
Specifies an additional file to place upload descriptions. This could
be used to maintain a downloadable list of ALL files, or a bulletin of
NEW uploads.
Parameter 214 <none>
The name (without path or extension) of the master FMS directory. See
section 12.3 for a full description of the advantages of using FMS
Parameter 215 NO
Limits the search for directories to the master FMS directory. If you
have multiple .DIR files, set this parameter to NO. If you only use
FMS, set this parameter to YES to increase the speed of directory
searches.
Parameter 216 UNC
The default category code for uploads. This parameter is how uploads
get classified in the FMS directory if the uploader does not have
sufficient security to categorize an upload. If this category is
"***," only the SysOp will see the new upload.
Parameter 217 DIR.CAT
The name of the file which tells RBBS-PC what categories are included
in the FMS directory. The format of the file is described in section
12.5.
Parameter 218 NO
Specifies what directories will be listed in a request for "all"
directories. This parameter is REQUIRED in order for "all" to be
defined as an option. Begin with "@" if you want to specify a list of
directories. For example, "@C:\RBBS\ALLDIR.LST" means that the text
file "ALLDIR.LST" on drive C in subdirectory RBBS contains a list of
directories to search when "all" is specified. The directories in
ALLDIR.LST should use the same names as the caller would type in, one
to a line. E.g. if "all" is the search directories 1,3, and 4,
ALLDIR.LST should contain
1
3
4
You can also specify a specific directory to confine all to by including an
entry not beginning with "@", e.g. "FMS" would list directory FMS.DIR,
located in the drive/path specified where directory files go. If you want
to disable the search for "all", just press Enter in response to this
parameter.
Parameter 219 40
The maximum length of the description that can be given to an uploaded
file. RBBS-PC can be configured so that those who upload files can
provide a description of the file they upload. This description
informs others what the file does and helps them decide whether they
want to download the files. The maximum length of the description can
be set to any value between 40 and 46. WARNING: If you change this
option, you must manually change all existing directories.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-24
Parameter 220 C:
The drive and directory where all directory files must be put, except
possibly for the upload directory. Only in this DOS directory does
RBBS-PC look for RBBS-PC directory files, with the sole exception of
the upload directory when the caller's security level permits the
upload directory to be viewed (see parameter 149).
10.12 Communications Parameters (part 1)
----------------------------------------
Parameter 221 COM1
The communication port that RBBS-PC will use. If you specify COM0,
RBBS-PC will run in "local" mode, allowing you to run RBBS-PC without
a modem. RBBS-PC can support COM1 and COM2 directly, or it can
support a FOSSIL driver, and thereby support any communications port
supported by the FOSSIL.
Parameter 222 3
The number of seconds that RBBS-PC should wait after initializing the
modem with a "reset" command. Many modems require only 1 second to
reset, however some may require much (MUCH) longer.
Parameter 223 1
The number of seconds to wait prior to issuing a modem command. This
is most useful when you have configured RBBS-PC to only issue commands
between rings and want the modem to "settle down" after a ring has
ended. If you find that 2400 baud calls are improperly connected at
1200 baud, increase the wait. Some modems take longer to connect at
2400 than at lower speeds.
Parameter 224 1
The number of rings to wait before answering the phone. Specifying
zero rings means that the modem (not RBBS-PC!) will answer the phone
as soon as it rings. NOTE: RBBS-PC's control of answer mode is an
important part of its security. Setting parameter 224 to ZERO
bypasses this security! If you specify one or more rings, the modem
must be able to tell RBBS-PC when the phone is ringing (via RS-232 pin
22 or the "RING" response string). The modem must also be able to
count rings in its S-registers. You can also specify "Ring-Back."
This instructs RBBS-PC to IGNORE a ringing phone, but if the phone
stops ringing (for more than 10 but less than 45 seconds) and then
starts ringing again, RBBS-PC will answer. This is useful for non-
dedicated phone lines, or hearing-impaired SysOps who want to use both
TDD (telecommunications device for the deaf) and RBBS-PC. A caller
who wants the SysOp to use TDD will call, let the phone ring once then
hang up, and then call BACK to get RBBS-PC to answer the phone.
Parameter 225
Sets the commands RBBS-PC uses to communicate with the modem. A list
of SysOp-supplied settings for various modems is also available (See
section 11).
Parameter 226
Activates software-based MNP support. This option is no longer
available, unless Microcom can supply a library that is compatible
with current Microsoft BASIC compilers. RBBS-PC does support MNP
protocol that is hardware-based (i.e. built into the calling and
answering modems).
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-25
Parameter 227 NO
Restricts RBBS-PC so it will only issue modem commands BETWEEN rings.
Some modems cannot handle the telephone ringing and accept modem
commands simultaneously. Most modems do NOT require this restriction.
Parameter 228 300
The speed RBBS-PC should initialize the modem to. Most modems will
only REDUCE speed when automatically detecting baud rate, so this
value should be set to the maximum speed supported by your modem.
Parameter 229 180 seconds
The number of seconds RBBS-PC will wait before disconnecting an "idle"
caller. If a caller walks away from an RBBS-PC session, RBBS-PC will
first warn the caller, then disconnect the call after the specified
number of seconds.
Parameter 230 NO
Specifies a "dumb" modem is being used. Selecting this means that no
modem commands are sent from RBBS-PC to the modem. This can be used
to connect RBBS-PC to a communications network (i.e. TymNet) or local
area network that supplied a simple RS-232 interface. Selecting this
option causes RBBS-PC to
- Issue no Hayes commands,
- Depend on no Hayes-like responses,
- Control the interface with the Data Terminal Ready (DTR),
- Assume somebody has called whenever Carrier Detect (CD) is
detected, and
- Assume that whomever calls is at the baud rate selected in CONFIG
parameter 228.
Parameter 231
Initializes the modem's firmware for use by RBBS-PC. The commands
used to perform firmware initialization can be modified with parameter
225.
Parameter 232 3
The number of seconds to wait after dropping DTR (Data Terminal
Ready). RBBS-PC drops DTR in order to disconnect a caller. Too short
a delay will cause the modem not to re-initialize properly.
Parameter 233 PROTO.DEF
The path and filename of the external protocol driver file (see
section 20).
Parameter 234 NO
Activates RBBS-PC's check for AutoDownload support (supported by the
PC-TALK terminal emulator) at the start of each call. This check is
incompatible with some terminals and communications packages, causing
them to stop displaying on the local screen. The caller can control
whether autodownload is used with the T)oggle command in utilities.
It is recommended that this option NOT be enabled.
Parameter 235 YES
Instructs RBBS-PC to force downloads with "binary" file extensions
(i.e. .ARC, .ZIP, .EXE, .COM, .OBJ, .WKS, .BAS, or whose second letter
of the extension is Q) to non-ASCII protocols.
Parameter 236 <don't recycle>
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-26
Instructs RBBS-PC to "recycle" after a number of minutes passes
without receiving a call. This may help recover from a modem
malfunction. Set this value to the number of minutes an "idle"
RBBS-PC could mean a modem problem. Specifying 0 means that RBBS-PC
will not re-cycle, no matter how many minutes elapse between calls.
Parameter 237 NO
Forces RBBS-PC to leave the modem at the baud rate it was initially
opened at rather than automatically matching the baud rate of the
caller. RBBS-PC normally changes the baud rate in the RS-232
interface to match that of the callers. Some modems allow RBBS-PC to
transfer at maximum speed on all calls, while the modem handles the
speed conversion. In this case you would set parameter 237 to YES.
10.13 Communications Parameters (part 2)
----------------------------------------
Parameter 241 NO
Instructs RBBS-PC to switch back to the original parity/word length
setting after a binary transfer. If a caller using 7bit, even parity
requests a binary transfer, RBBS-PC will switch to 8bit, no parity.
Parameter 241 controls whether RBBS-PC stays at 8bit or reverts to
7bit after the transfer. Most environments can remain at 8bit after a
transfer.
Parameter 242 0
Specifies the minimum modem speed that new callers can have. If a new
caller connects at a speed less than that specified, RBBS-PC will deny
access to that caller.
Parameter 243 0
Specifies the minimum modem speed for OLD callers. With this
parameter, you can block any NEW callers at 300bps, but allow a pre-
registered caller access at that speed.
Parameter 244 NO
Activates CTS (clear to send) and RTS (request to send) flow control.
This hardware flow control uses RS-232 pins 4 and 5 to control the
flow of data between RBBS-PC and the modem.
Parameter 245 NO
Activates XON/XOFF flow control. This software flow control uses
ASCII codes to control the flow of data between RBBS-PC and the modem.
NOTE: RBBS-PC only supports XON/XOFF at the end of each buffer. If
RBBS-PC is to respond to XON/XOFF quickly, set parameter 54 to a small
number.
Parameter 246 30
The maximum time RBBS-PC should wait for carrier after answering the
phone.
10.14 Parameters for RBBS-PC NET-MAIL
-------------------------------------
Parameter 261 <none>
Specifies the time of day in HHMM format at which RBBS-PC is to
perform a "daily event." At this time, RBBS-PC will create a "daily
event" signal file, and exit to DOS. The signal file is in the form
"RBBS?TM.DEF", where ? is the node number. See section 13 for a
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-27
complete description of the requirements for .BAT files when doing
daily events.
Parameter 262 <none>
Selects a network "front end" for use with RBBS-PC. Currently,
RBBS-PC supports the following front-ends: SeaDog and BinkleyTerm (see
Appendix S). By enabling this option, the SysOp assumes the
responsibility of configuring the "net mail" application to:
1. answer the phone and determine if the caller is sending "net
mail".
2. if the caller is not sending "net mail", the net mail application
must invoke RBBS-PC with the following command line:
RBBS-PC.EXE nodeid filename /time /baud /RELIABLE
where:
- "nodeid" is the node ID in the range 1-9, 0, or A-Z.
- "filename" is the fully qualified file name to use as the
RBBS-PC ".DEF" file.
- "/time" is the time of day for RBBS-PC to return to the "net
mail" application that called RBBS-PC.
- "/baud" if the baud rate that the caller dialed in at.
- "/RELIABLE" tells RBBS-PC whether the connection has error
correction built into the connected modems
Parameter 263 <none>
The command to turn on intermediate host echo. This is intended to be
used when RBBS-PC is connected to a public data network (PDN) as a
"node" -- not all systems that people log into on a PDN need be "main
frame" computers! When RBBS-PC is a node on a public data network,
typically the network will do the echoing -- between the caller and
the port they access on the PDN and between RBBS-PC and the port
RBBS-PC accesses on the PDN. This causes file transfers to be a
problem because the PDN will continue to echo. Therefore it is
necessary to be able to go into an "image" mode where data is passed
through the PDN intact with no echoing. The contents of this string
will be sent AFTER a file transfer so the network will resume echo.
Any character can be included in the string using it's decimal ASCII
equivalent simply by putting a number inside square brackets.
Characters not in square brackets will be transmitted as they were
entered. The string "a[32]" will be interpreted as a lower case
letter "a" followed by a blank.
Parameter 264 <none>
The string that is sent BEFORE a file exchange that causes the PDN to
STOP echoing. As with parameter 263, the contents of this string is
entirely dependent on the predilections of the PDN that RBBS-PC is
attached to.
Parameter 265 RBBS-PC
Specifies who should echo characters sent to RBBS-PC. Normally,
RBBS-PC echoes back to the caller. But, when connected through a PDN,
you may want to change this value to either "intermediate host", or to
"the caller's system".
Parameter 266 <none>
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-28
The string RBBS-PC will use to acknowledge each line in an ASCII
protocol upload. Typically, an ASCII upload is characterized by two
fundamental features -- it contains no unprintable characters and it
does not require any "error checking". Under some circumstances a
callers communications protocol may require a response from RBBS-PC
(i.e. a line feed) before the next line will be transmitted.
Parameters 267 FIDX.DEF
The path and filename of the FFS (Fast File Search) sorted names file
(see section 12.9).
Parameter 268 LIDX.DEF
The path and filename of the FFS (Fast File Search) "tabs" file (see
section 12.9).
10.15 New Users Parameters
--------------------------
Parameter 281 YES
Instructs RBBS-PC to allow new callers to set their default system
values. RBBS-PC typically asks new users their choice of line feeds,
graphics, transfer protocol, and "turbo-key". Sometimes these
questions confuse new users, who lack the knowledge to answer them.
Parameter 281
Not implemented in this release of RBBS-PC.
Parameter 282
Not implemented in this release of RBBS-PC.
Parameter 283
Not implemented in this release of RBBS-PC.
Parameter 284
Not implemented in this release of RBBS-PC.
Parameter 285
Not implemented in this release of RBBS-PC.
Parameter 286
Not implemented in this release of RBBS-PC.
Parameter 287
Not implemented in this release of RBBS-PC.
Parameter 288
Not implemented in this release of RBBS-PC.
Parameter 289
Not implemented in this release of RBBS-PC.
Parameter 290 YES
Specifies new users should be saved in the USER file. If set to NO,
new users may log in, but RBBS-PC will not "remember" them on
subsequent calls.
Parameter 291
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC Page 10-29
Instructs RBBS-PC to allow new users when the USER file is full. In
this case, RBBS-PC will not "remember" new callers on subsequent
calls, until the USER file is expanded to accommodate more records.
Parameter 292 60
Default maximum number of minutes a caller can bank. 0 disables, 255
is the maximum. When banked time is withdraw, it is added to the
session time of the caller, and so gives users the ability to transfer
unused time from one day to another.
10.16 Use of the Library Sub-System
-----------------------------------
Parameter 301 <none>
Activates the Library Sub-System (see section 12.6). Specify a drive,
which must NOT be a drive used by any other RBBS-PC function.
Parameter 302 <default dir>
The drive/path where RBBS-PC will find the upper directory (CDR.CDR is
the default name).
Parameter 303 CDR
The file extension that identifies library directory files.
Parameter 304 <default dir>
The drive/path of the Library "work disk." This is where the Library
sub-system creates archive files for transmission. Normally, 360K of
free space is required, so a RAM disk is suitable.
Parameter 305 705
The number of disks available in the library.
Parameter 306 7
The maximum number of upper level directories that will be found on
the Library disk. The PC-SIG CD-ROM is organized with 10 upper level
directories, 1-100, 101-200, 201-300 etc. and each of these contain
100 directories, DISK001, DISK002 etc.
Parameter 307 100
The maximum number of subdirectories that each upper level directory
can contain.
Parameter 308 DISK
The prefix of the lower level directories. Since the user enters only
the disk number that is desired, RBBS-PC creates the subdirectory name
based on this parameter and the number entered.
Parameter 309 MENU6
The drive\path\name of the Library Sub-system menu.
Parameter 310
The list of command symbols that are available from the Library
Sub-System menu.
Parameter 311 <variable>
The security values related to the symbols listed in parameter 310.
Parameter 312 <default dir>
The drive\path where the archive utility program can be found.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 10-30
Parameter 313 ARCA
The archive utility that will do the archiving on Library disks. When
answering the questions to this parameter you will also be asked what
the CREATE parameter is. For PKARC and ARC the correct response is
"A". If using ARCA there is no CREATE parameter since CREATE is the
only function that it can do.
10.17 RBBS-PC's Parameters for Color
------------------------------------
Parameter 321 [27][1;41;37m
The string that turns ON highlighting or emphasizing of characters in
text strings displayed to the caller (see section 7.10).
Parameter 322 [27][0;40;33m
The string that turns OFF highlighting or emphasizing of characters in
text strings displayed to the caller.
Parameter 323 Bright Green
Foreground color 1. The SysOp can select this color in menus and text
by using the SmartText command C1.
Parameter 324 Bright Yellow
Foreground color 2. The SysOp can select this color in menus and text
by using the SmartText command C2.
Parameter 325 Bright Purple
Foreground color 3. The SysOp can select this color in menus and text
by using the SmartText command C3.
Parameter 326 Bright Cyan
Foreground color 4. The SysOp can select this color in menus and text
by using the SmartText command C4.
Parameter 327 <none>
The background color used against the preceding four foreground
colors.
MODEM SWITCH SETTING AND CONSIDERATIONS Page 11-1
11. MODEM SWITCH SETTING AND CONSIDERATIONS
-------------------------------------------
Recognizing that there are many "Hayes-compatible" (and not so compatible)
modems in use, this section is intended to assist those adventurous souls
who wish to properly configure a modem for use with RBBS-PC. By explaining
what RBBS-PC expects from a modem, we hope you can determine how to set
your modem to provide what RBBS-PC expects.
There are three levels of modem configurations:
1) Hardware switches. These are physical switches that can be turned on
or off to control modem functions. RBBS-PC tries NOT to rely on these
switches, since other software you use may require different settings.
Many modems have software overrides for these switches, and RBBS-PC
will use them when possible. If your modem has hardware switches, you
will want to concentrate on them first. Find out what functions are
selected by switches that CANNOT be overridden by firmware or software
commands.
2) Firmware switches. These are software commands that you can issue to
the modem, and then tell the modem to "remember" these settings, even
after the modem is powered off. RBBS-PC tries NOT to rely on these
switches, for the same reason it avoids hardware switches. However,
there are usually switch settings that must be set for use with
RBBS-PC.
3) Software commands. These are "temporary" commands sent to the modem,
that will be erased when the modem is turned off. RBBS-PC does most
of the configuration via software commands, to allow the most
flexibility in modem operation.
RBBS-PC requires a modem to provide certain functions to ensure proper
operation. By studying these requirements, you should be able to find a
combination of hardware, firmware and software settings to satisfy all
these needs:
- Modem result codes. Most modems offer both verbose and numeric
results to modem commands. RBBS-PC expects VERBOSE codes, as in:
RING When the phone is ringing
CONNECT When carrier is established
CONNECT 2400 MNP When a reliable 2400 bps call is established.
- Carrier Detection. RBBS-PC expects the modem to raise and lower the
CARRIER DETECT signal (RS-232 pin 8) to properly reflect the presence
of a caller.
- Data Terminal Ready. RBBS-PC expects the modem to properly respond to
DTR. When RBBS-PC turns DTR off, any call should be terminated and
the modem should reset.
- Ring counter. RBBS-PC expects the modem to count the number of times
the phone rings, and provide this count when a "count modem rings"
command is sent.
CONFIG parameter 225 allows the SysOp to set modem commands use by RBBS-PC.
The commands that you can set are:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 11-2
1) RESET THE MODEM. This command is sent when RBBS-PC wants the modem
returned to its initial configuration (including any changes saved in
firmware). Normally, the command used is: ATZ
2) INITIALIZE THE MODEM. This is the SOFTWARE initialization, used by
RBBS-PC each time it recycles. Any commands needed to put your modem
into "RBBS-PC mode" should go here. For generic Hayes-compatible
modems, the command would be: ATE0M0Q0V1X1S0=254S2=255S10=20
The sub-command S0=254 is important to this string. RBBS-PC uses this
to control how it answers the phone. Use:
S0=001 to answer on 0 rings
S0=254 to answer on 1 or more rings, no ring-back
S0=255 to answer on 1 or more rings, with ring-back
3) COUNT RINGS. RBBS-PC uses this command to ask the modem how many
times the phone has rung. For Hayes-compatible modems, this command
should be: ATS1?
4) ANSWER PHONE. RBBS-PC uses this command to tell the modem to answer
the phone. This is normally: ATA
5) TAKE PHONE OFF HOOK. RBBS-PC uses this command to "busy the line"
when recycling, or when the SysOp drops to DOS when the node is idle.
This is normally: ATH1M0
6) CLEAR FIRMWARE. This command is used to reset the modem's firmware to
"factory defaults." CONFIG uses it before programming the modem's
firmware. Normally, this is: AT&F
7) INITIALIZE FIRMWARE. This command sets any firmware settings that are
needed to satisfy RBBS-PC's modem requirements. The settings will
vary greatly from modem to modem.
8) WRITE MODEM'S FIRMWARE. This command is used to make the settings in
command 7 permanent. Usually, this is: AT&W
Appendix D contains configuration for several modem brands. This
information may serve as a guide to configuring your modem. If you make
any discoveries about the interaction between your modem and RBBS-PC,
please share them with the RBBS-PC authors, so that the information can be
given to others.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-1
12. RBBS-PC's FILE MANAGEMENT SUBSYSTEM
---------------------------------------
The File Subsystem allows RBBS-PC to maintain a list of files available for
downloading. Users can list files by date, category, file specification,
or substring. RBBS-PC refers to a file that contains a list of files
available for downloading as a "directory" (i.e. a .DIR file). This should
not be confused with DOS "subdirectories."
There are two ways to configure the File System. One is to have simple
"directory" files. The other is to have a FILE MANAGEMENT SYSTEM (FMS)
file that contains the names, sizes, dates, and description of all the
files available for downloading.
You may use both methods at once if you wish. RBBS-PC will support both a
master FMS and separate .DIR files on the same system. CONFIG parameter 215
controls whether RBBS-PC looks beyond the FMS directory. If you have any
separate directories, set 215 to NO. If you have only a single FMS
directory, set parameter 215 to YES. If directory searches are not limited
to the FMS directories and RBBS-PC does not find the category in the FMS
listing, it will look for the old-style DIR files.
12.1 Simple Directory Format
----------------------------
The simple directories, also referred to as the old-style directories, are
simply text files. These files are identified by their file extension,
specified in CONFIG, common to all the directories. The default extension
is .DIR, but it can be changed via parameter 209. There is a directory
which lists the directory names and their descriptions whose name is
specified via parameter 211 of CONFIG.
Each directory may have anything in it, including ANSI codes. The only
restriction is that in order for the N)ew command to work properly, the
date must be somewhere in the first 31 characters.
All uploads are placed into a single directory, called the upload
directory, specified in parameter 202 & 203. All other directories must be
in the drive\path specified in parameter 220. This includes the FMS
directory and the list of DIR files, (DIR.DIR).
There are, therefore, four logical areas into which the file subsystem is
divided. Each one may reside in a separate DOS subdirectory, or all of them
may be lumped together.
Logical Area CONFIG
1. The files for DOWNLOAD parameter 204, parameter 205, and
parameter 207
2. The files that have been uploaded parameter 201 and parameter 206
3. The upload directory file listing. parameter 202 and parameter 203
4. The download directory files. parameter 220
The file management system not only manages these "lists" of files, but it
manages where on your system the files are actually stored. RBBS-PC will
not allow a caller to download a file unless it finds this file where the
SysOp has instructed RBBS-PC to look. There are two ways of doing this: A
download "path," and the Fast File Search.
Config parameter 204 tells RBBS-PC which DRIVES can be checked for
downloads. If you do not use DOS subdirectories, RBBS-PC looks on these
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-2
drives for downloads. The parameter is specified with the drive letters to
search. For example: BAC would search Drive B, then Drive A, then Drive C.
If the files are not in the default directory then you need to use the
CONFIG parameter 205 and parameter 207. Parameter 205 specifies that you
want to use DOS sub-directories and parameter 207 allows you to list them.
Use drive:\path format.
Any directory can be in the Single FMS format. This allows special purpose
directories to be put into FMS format so they can take advantage of such
features as resumable listings normally associated just with the Single FMS
environment. An unlimited number of lines of text can be added to any
description (see CONFIG parameter 40, parameter 148, and parameter 153).
The file directories have absolutely no bearing on what is in the
subdirectory. A file can be listed but not exist, and a file, such as one
uploaded with the / for SysOp option, may exist but not be entered. The
file directories are simply methods to get the caller a listing of the
files available.
12.2 The FMS Header Record
--------------------------
FMS logically just lumps all the old style separate directories into one
directory file, called the MASTER or FMS directory, and assigning each file
a CATEGORY CODE, which may correspond to the directory it was in the
original directories. A utility program called CNVDIR.EXE will do exactly
this: combine the separate directories and add the category code at the
end. If you do not already have separate directories, simply set it up
with a text editor using the columns indicated.
The first record at the top of an FMS directory can be an optional header
record that lets the SysOp pick special options. The header record must
begin with "\FMS" and must have the same length as the other lines. The
format is
\FMS (option1) (option2) ... (optionN) (blank-fill) .
Any character can be put at the last position, but a period is recommended
so that it will be easy to see the end of the line. The options are all
keywords. If no header record is included, the defaults are sorted by
date from oldest to newest, no chaining, file downloads not free, and read
from the bottom up. The options include
NOSORT The file is not sorted by date. Needed if files are in
alphabetic order. The big advantage of date sorted files
are that the newest are shown first.
CH(<fname>) Chain to file <fname> when the end of the directory is
reached. This enables the SysOp to break very large
directories into smaller, more manageable physical files,
which logically behave like one big one. E.g.
"CH(C:\DIRS\UPLOADS.OLD)" means to chain to the file
UPLOADS.OLD in subdirectory C:\DIRS.
FREE FREE means that files listed downloaded while listing the
NOFREE directory are NOT to be counted when limiting downloads by
ratios. If limiting by number of downloads, the file
downloaded will not be counted in the caller's number of
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-3
downloads. If limiting by number of bytes, the size of the
file will not be counted. This lets the SysOp limiting
downloads provide some that are free and unrestricted.
NOFREE means that the files will be counted when applying
downloads.
LISTONLY The files downloadable while listing the directory are only
those explicitly listed in the directory. Normally, a
caller can download any file in the downloadable areas.
TIMEEXTRA N The caller gets an extra N minutes to download files while
listing the directory. This lets the SysOp make files
downloadable that the caller might not otherwise have enough
time to get. For example, with "TIMEEXTRA 80", a caller
with only 5 minutes of session time left could still
download a file requiring 40 minutes to download.
TOP Means to read the file from the top down, rather than the
normal bottom up. Generally needed when files are not
sorted by date from oldest to newest.
PERS Means that the files in the directory are viewable and
downloadable only by those addressed to the caller (or a
security level). By default, PERS sets TIMEEXTRA to 60,
LISTONLY to true, and FREE to true, unless explicitly
overridden by additional parameters. Note: this option
means that the category code field at the end of a line must
be expanded to the size of the hash (normally name) field
used to identify users.
Warning: be careful with the options. For example, if you put TIMEEXTRA
in without LISTONLY, the caller will have extra time to download any file.
12.3 Advantages/Disadvantages of FMS Directory
----------------------------------------------
Having a FMS directory has the following advantages:
1. Callers get the newest files listed first. The directory can be
displayed EITHER from top to bottom or bottom to top. Reading from
bottom up is appropriate when files are in date order and new files
are appended to the bottom. When files are alphabetized or grouped
some other way, it is more appropriate to read them from the top down.
2. The directory is listed with "MORE ([Y],N) or files to download"
prompts throughout the listing, so at any time the caller may begin
downloading, and pick up where they left off in the listing after the
download is completed.
3. Wildcard searches on filenames are supported as well as exact matches
on strings in the file S)earch command. Whenever a wild card
character (* and ?) is specified in the search string, RBBS-PC will
automatically shift to matching just the file name. Exact string
matches search the full entry rather than just the file name. String
searches include extended descriptions for FMS directories, but in
non-FMS directories only the first line of the file description is
searched.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-4
4. Classification of files is easy. All that is necessary is an editor
that produces ASCII files, and a file is classified by a category code
of up to 3 characters. To change a file from directory to directory,
all that is necessary is to change the category code. No more "erase
it here and add it there."
5. No SysOp maintenance is necessary for new uploads. The caller can
classify the upload with a category code, and the SysOp can specify
that the new uploads become instantly available.
6. Complex classifications can be made very simply. A category code is
not necessarily the category the caller must type in. The SysOp can
elect to have a classification system where one code that the caller
types in will list several different category codes. You can include
the file in two directories without having two separate entries.
7. FMS directories can have "headers" (i.e. free text lines not
associated with any particular file). This allows things like column
headers or help to be included, as well as section headers. A SysOp
may wish to separate a "communications directory" into different
sections such as one for QMODEM and one for RBBS-PC. A free text line
begins with "*" and is universally displayed if the category code is
"***" otherwise it is only displayed when the category associated with
the line is selected.
8. Multi-line descriptions (i.e. "extended" descriptions) are supported
in both FMS and "old-style" directories. All columns except the first
one are available for the description. For FMS directories, extended
descriptions have the same characteristics as the file that they are
associated with.
9. The ability to enter "extended" descriptions for uploaded files is
based on the caller's security level (see CONFIG parameter 127).
10. Caller's can list the RBBS-PC file directories with or without
extended description. As an example, a caller would enter the command
"L - UPLOADS" to list the files in the directory UPLOADS with only one
line descriptions. The command "L + UPLOADS" would list the same file
with extended descriptions.
11. Archived files can be viewed with the V)iew command when listing FMS
directories and the listing will resume where it left off prior to
issuing the V)iew command.
12. Individual entries within a FMS directory can be restricted to
specific security levels.
13. Comment lines can be included in FMS directories which are never shown
to a caller. Often such comments are useful reminders to the SysOp
who is maintaining the FMS directories.
14. Callers can add upload descriptions without actually uploading a file
(see CONFIG parameter 153). This is typically useful to the SysOp.
It makes it easy to start an FMS upload directory without having to
know anything about its internals or how to use an editor. With the
exception of a CORVUS network environment, FMS directories can be
updated without taking the system down first. All the caller does is
issue the normal upload command. If RBBS-PC finds that the file
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-5
already exists and that the caller has the necessary security level,
RBBS-PC will get the file size and proceed exactly as if the file had
just been uploaded.
15. Searches for new files is EXTREMELY fast because RBBS-PC does not have
to search all directories if the single FMS directory is in date order
(most recent date last)
16. Latest uploads are always shown first, if the SysOp has elected to
make them viewable and the master FMS is in date order.
17. Searches for text will scan the text in the extended multi-line
descriptions.
18. Composite categories can be logically constructed out of other
categories (see section 12.5).
19. Entries do not have to be physically moved to other .DIR files to be
classified as belonging to it.
20. FMS directories can be "chained" to accommodate those multi-user
environments, such as Corvus's OMNINET, which will not allow files
that change in length to be shared. In such an environment FMS can be
used, but the FMS directory must "chain" to the upload directory and
their must be a separate upload directory for each node.
Regrettably, the FMS directory also has ONE remaining limitation which may
make it unsuitable for all SysOp's needs.
1. The date must be in MM-DD-YY format. Any single digit number must have
a leading zero.
If FMS does not totally satisfy your needs, you can use both. RBBS-PC can
be configured to look for an old style directory if it does not find a
directory in the FMS. If it finds one it will display it. If it does not,
it displays the familiar "Directory XXX not found!" message.
12.4 Creating FMS Directories
-----------------------------
FMS directories are very easy to create, when the upload directory is
identical to the FMS directory. When logged on as SysOp, simply upload a
file already there. RBBS-PC will ask you if you want to overwrite the
file. Say "no"! Else you will delete the file, which you could want to
do in other situations. Then RBBS-PC asks you if you want to add a
description. Say "yes". Say the upload is to all, and when you describe
the file and classify it, the entry goes right into the FMS directory with
the proper category code on the end.
If you already have separate directories and want to convert them to the
FMS format, it would be a good idea to copy all of them into a single one
called MASTER.DIR. Detailed directions are given in the documentation for
CNVDIR. In DOS this can be done like this:
COPY xxx.DIR+xxx.DIR+xxx.DIR... MASTER.DIR
where xxx is the name of the old style directories. The 3 dots mean to
continue until you have all of the directories you wish to include in the
FMS directory.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-6
In addition to the "old style" file directories described in section 12.1,
RBBS-PC supports two types of FMS "directories" -- multiple, single-subject
FMS directories or a single multiple-subject master FMS directory. If
there are going to be multiple, single-subject FMS directories, there must
also be a "directory of directories" (i.e. a master directory) whose name
is specified in CONFIG parameter 211 and there can not be more than 99 of
these single-subject FMS directories. If there is going to be a single FMS
directory, it's name is specified in CONFIG parameter 214 and it's
qualifier is specified in CONFIG parameter 209.
An example of multiple FMS directories that assumes the following:
CONFIG parameter 220 is "C:\FMS",
CONFIG parameter 209 is "DIR",
CONFIG parameter 211 is "DIR", and the following files existed:
C:\FMS\DIR.DIR
C:\FMS\ALPHA.DIR
C:\FMS\BEST.DIR
The file ALPHA.DIR can be a FMS directory with an alphabetical list of all
files and BEST.DIR can be a FMS directory with a date-ordered (latest date
last) list of the "best" files.
An FMS directory can have an optional "header" line that describes the
structure of the directory. RBBS-PC searches FMS directories from bottom
to top by default (i.e. the assumption is that they are sorted by date with
the newest entry at the bottom). To make an FMS directory read from top to
bottom, the directory must have the optional "header" line as the first
line. For FMS to read an FMS directory from top to bottom, the first four
characters in the first line must be "\FMS" and the line must contain the
three characters "TOP" (i.e. the whole fixed-length line would read "\FMS
TOP"). For FMS directories not sorted by date, the word "NOSORT" must be
present in the first line (i.e. the whole line would read "\FMS TOP
NOSORT"). The file ALPHA.DIR would have the first line in the file read
"\FMS TOP NOSORT". The file BEST.DIR would have the first line in the file
read "\FMS TOP" if all searches of the file were to start with the oldest
(i.e. first) entry. It is important to realize that FMS directories must
have a fixed length in every line.
The columns of all FMS directories are set up as:
Column Purpose
1-13 Filename
14-22 File size
24-31 Date in MM-DD-YY format
34+ Description + category code
To add comments to an FMS directory and not have them shown to the caller,
simply begin the comment line with a slash, "/".
To force a line to be displayed that is not associated with an FMS
directory entry, begin the line with an asterisk and, if it is displayed
for only specific categories, the appropriate category restriction.
To make an FMS entry visible only to callers with a specific security level
or higher, the first character of the file name must be an equal sign, "=".
For this entry, the file name is in columns 2 through 13. The minimum
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-7
security to view this entry goes in column 34 and is followed by a blank
and then the description and category code within the columns appropriate
for them (based on CONFIG parameter 219).
CONFIG parameter 219 specifies the length of the "description" field (40 to
46). The column containing the "category" codes can be variable as
follows:
Length Columns for description Category code column
40 34-73 74-76
41 34-74 75-77
42 34-75 76-78
43 34-76 77-79
44 34-77 78-80
45 34-78 79-81
46 34-79 80-82
However, some text editors may have a problem with lines 80 or more
columns.
The fussiest areas for use with FMS are the DATE and CATEGORY CODE fields.
These two must be absolutely perfect for FMS to function properly. The
others may be slightly more lenient. In order to get the directory in the
correct format, insert and delete spaces before and after the column. The
file name should not have interior or leading blanks.
You must also add a category code to each listing. This is often the most
difficult and time consuming part of setting up FMS. A good idea is to
format the rest of the directory before you add the codes.
CONFIG has a utility, parameter 187, that will check your FMS directory
structure for you. If a caller uploads with a "/" for SysOp, a *** is
placed for the category code and only those with a SysOp security level may
view the listing (see CONFIG parameter 125).
12.5 Defining the FMS Category Codes
------------------------------------
In order for FMS to work correctly, the category codes must be defined.
This is done in the file DIR.CAT (see CONFIG parameter 217). This file is
rather interesting in the way it is set up and the possibilities it brings
up. The format of this file is, with each line being a separate entry:
"<Category name>","<Category codes>","<Category description>"
The category name is what the caller will enter to request the category.
The category codes are a list of the character codes in the FMS directory
that we want to be in this category. Category codes can be 1 to 3
characters long, though the simplest and most foolproof method is to make
them all exactly 3 characters long. The category description is a short
message that we want displayed when the category is listed.
If the category codes are less than 3 characters in length, blanks must be
added to the right to fill out the length to exactly 3 when putting the
category codes on the end of file entry.
A listing can contain several category codes. This means that a category
name of BASIC could have the category codes BSU,BSG,BSS in it. The
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-8
category codes may be overlapped in several different directories. For
example, the BASIC directory used as an example could also have each code
included in another directory. UTILS could contain DSU,PRU (Dos utils,
Printer utils). GAMES could contain CGG,BSG,TXG (Color Graphics Games,
Basic Games, Text games). BASIC could contain BSG,BSS ( Basic Games, Basic
Source). SOURCE could contain ACS,BSS (Assembly code source, Basic Source)
Such a setup would look like this:
"BASICG","BSG","Basic Games"
"TEXTG","TXG","Text Games"
"COLORG","CGG","Color Graphics Games"
"PRINT","PRU","Printer Utilities"
"DOS","DSU","Dos Utilities"
"ASSEM","ACS","Assembler source code"
"BSOURCE","BSS","Basic Source Code"
"UTILS","DSU,PRU","Utilities for IBM"
"GAMES","CGG,BSG,TXG","Games for IBM"
"BASIC","BSG,BSS","BASIC programs"
"SOURCE","ACS,BSS","Source code for different languages"
The directory might look like:
FFIND.ZIP 13463 05-24-92 DOS Util look all over disk for file DSU
QUEST.ZIP 17325 06-02-92 C/G Game D&D style CGG
RBBS-SRC.ZIP 202562 06-05-92 Source code for RBBS-PC BSS
QMODEMSC.ZIP 106735 06-07-92 Source code for QMODEM SST PSS
BALLOON.ARC 5634 06-08-92 BASIC Balloon game- GREAT BSG
STARTREK.LZH 76434 06-10-92 A great game- TEXT TXG
When someone lists out GAMES, they get QUEST, BALLOON, and STARTREK.
You can also have simply a one to one correspondence, rather than cross
referencing by just having one category code for each category.
A utility that will help you in setting up your FMS directory is a SysOp
function built into CONFIG. Parameter 187 will test the structure of your
FMS directory and diagnose any problems. Be sure to run this utility after
you have tried to set up FMS, or whenever you edit the FMS directory file.
12.6 CD-Rom Support
-------------------
RBBS-PC has long had one of the best systems for supporting CD-Rom as a
source of downloadable files. CD-Roms present two special challenges to a
BBS: they are very slow devices with hundreds or thousands of
subdirectories. Most BBS's therefore
o require separate access to download from a CD-Rom, such as a door
o do not check uploads for duplicates against the CD-Rom
o give very slow performance when finding a file on the CD-Rom.
RBBS fully overcomes these limitations:
o the files on the CD-Rom can be transparently added to the downloadable
files, with no difference in the way the user accesses them from those
on a fast hard disk
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-9
o RBBS supports over 10,000 areas or subdirectories to download from
o files are found virtually instantaneously and uploads checked for
duplicates with no special delay.
Once you get a CD-Rom installed, there are two things you have to do to
make the files downloadable:
o add the files in the subdirectories on the CD-Rom to the
filespecs in the MAKEFIDX utility that creates a Fast File System
index
o add the descriptions of the files on the CD-Rom to RBBS-PC's text
directory listings.
Both of these can be laborious processes for the SysOp, but the result is a
fast, integrated, one-stop system for the caller.
12.7 The "Library" Subsystem, CD-ROM, and FMS
---------------------------------------------
The RBBS-PC "library" sub-system is highly flexible subsystem that
basically allows files to be downloaded at the level of DOS's disk
subdirectories. The "library" subsystem is not limited to any particular
medium, but its main application is to older generation CD-Roms that put
the files together to be downloaded onto thousands of subdirectories.
Basically, the library subsystem relies on three files:
DIR.CDR - This is the Directory of Directories just like DIR.DIR is the
Directory of Directories for the normal download area. This file is
located on the drive and path designated in CONFIG parameter 302, has a
file name equal to the extension designated in parameter 303 , and the
extension designated in parameter 303.
MASTER.CDR - This is an FMS style directory. Highly recommended to have a
size of 46 to allow for placing the DISK/AREA number in the last four
positions of description. This file is located on the drive and path
designated in CONFIG parameter 302. The following is an example of a
master directory file, C:MASTER.CDR, that might be used for the "library"
subsystem.
DEMO.DTA 9841 01-01-80 PRACTICE FORM 680126
READ.ME 256 01-01-80 INTRODUCTORY TEXT FILE 673102
READ.ME 109 01-01-80 INTRODUCTORY TEXT FILE 671102
DK0680 ARC 10-23-87 FORGE VERSION 2.0 200
DK0673 ARC 10-23-87 FREEWAY ...(Disk 3 of 3) 200
DK0671 ARC 10-23-87 FREEWAY ... (Disk 1 of 3) 200
| | | | | |
+- 1->13 | | | | |
File Name +- 14->22 | | | |
File Size | | | |
+- 24->31| | |
File Date| | |
+- 33->76 | |
File Description | |
77->79 -+ |
DOS |
Directory |
Number |
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-10
|
80->82 -+
Category
Code
The last four characters of the 46-character file description field are
used to indicate the "library" pseudo-disk that the file is in. In this
way, when a caller lists files, it is self-evident in the description which
DOS subdirectory the caller must change to within the "library" subsystem
in order to download the file.
RBBS-CDR.DEF - This is the key file to the successful operation of the
LIBRARY section. It consists of three fields on each line.
"AAAA","BBBBBBBBBBBBBBBBBBBBBB","CCCCCCCCCCCCCCCCCC"cr/lf
A - A four position field numbered from 0001 to 9999.
This is the DISK/AREA number assigned to a specific
group of files.
B - This field has no size limit and is a full path to the
area excluding the drive: designation. As an example:
\1_100\DISK0001
\GAMES\ADVENTUR\DISK1
\A_F\ALPHABET\DISK01\AREA36
C - This field has no length limit but should be kept at
around 56 characters to keep from line wrap on the
display. It should contain the TITLE of the
disk/area.
A file containing a description of the library subsystem's category codes
must have the name RBBS-CDR.DEF, be in the same DOS subdirectory as the
other RBBS-PC ".DEF" files, and look similar:
"0671","\601-700\DISK671","FREEWAY Payroll system (Disk 1 of 3)"
"0673","\601-700\DISK673","FREEWAY Payroll system (Disk 3 of 3)"
"0680","\601-700\DISK680","FORGE VERSION 2.0"
The "library" subsystem can be supported without using the FMS. To do this
each "directory" would have ".CDR" as it's extension (i.e. GAMES.CDR) -- or
whatever extension was designated in CONFIG parameter 303.
Typically, the "library" subsystem is used with FMS. When using FMS with
the "library" subsystem it is necessary to add categories to the DIR.CAT
file. One approach that works well is utilizing categories 1-99 for the
normal (i.e. non-library area) downloads and categories 100-200 for the
"library" downloads.
The basic assumption of RBBS-PC's "library" sub-system is that files are
stored in DOS subdirectories on the DOS disk drive specified in CONFIG
parameter 301.
12.7.1 How the "Library" Subsystem Works
----------------------------------------
Before it is possible to download from the LIBRARY area it is mandatory
that the caller C)hange to the desired library disk. This is accomplished
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-11
by using the C)hange command from the library menu. RBBS-PC will accept
any 1 to 4 digit number (padding the front with zeros to make it a four
digit number). RBBS-PC will then search the RBBS-CDR.DEF file (position
AAAA only) for an exact match. If no match is found then RBBS-PC indicates
that no Library disk has been selected. If a match is found then RBBS-PC
will issue a CHDIR command to the drive specified in CONFIG parameter 301
and the path BBBBBBBB that it constructs from the RBBS-CDR.DEF file. RBBS-
PC then informs the caller that Disk AAAA CCCCCCCCCCCC has been selected
(i.e. "Disk 0680 FORGE VERSION 2.0").
The caller can download individual files from the area selected or A)rchive
all the files in the selected area. If the caller decides to A)rchive all
the files in the selected area, RBBS-PC will SHELL to the Archive program
designated in CONFIG parameter 313 and located in the drive and path
designated by parameter 312. RBBS-PC creates an archived file with the
name DKAAAA.ZZZ, where AAAA is the disk/area number on the drive and path
indicated by CONFIG parameter 304, and ZZZ is the extension, which depends
on what archiving program is used.
RBBS-PC will then check to see if there are any subdirectories within the
selected area. If any exist then RBBS-PC will again Archive the
subdirectories and will create ZZZ files with the name DKAAAAa.ZZZ where
AAAA is the disk/area number. The designator, "a", is an arbitrary id to
differentiate it from the original ZZZ name. If there is more than one
subdirectory, the "a" would be replaced by "b", "c", "d", etc.
When this is complete the caller is told what files are ready for download.
E.g.
DKAAAA.ZIP is ready for download.
DKAAAAa.ZIP is ready for download.
DKAAAAb.ZIP is ready for download.
As each file is downloaded successfully it is removed from the list and is
no longer displayed to the user as ready for download.
12.7.2 The "Library" Subsystem and PC-SIG's CD-ROM
--------------------------------------------------
The CD-ROM published by PC-SIG consists of a DOS subdirectory for each 360K
diskette in the PC-SIG library. Sometimes the disk contains all the files
already in compressed format other times they just contain a group of
files. The key here is the A)rchive function. The resulting file to be
made available for download will NEVER be greater than 360k. This is
important since a caller may only have a floppy based system and could not
capture a file any larger than a 360k floppy can contain.
The PC-SIG's CD-ROM creates the problem of listing both the individual
files contained on each diskette as well as a summary description of the
individual disks. This can be solved by listing each of the 18,000+ files
in the MASTER.CDR using positions 43-76 for the description, positions 77-
79 for the disk drive, and positions 80-82 for the valid categories for
downloading. These are contained in the file specified by CONFIG parameter
217.
MASTER.CDR might also contain a list of names of the files that would be
created by the A)rchive function. This allows the caller to scan a
category (i.e. category 200) for disk titles only. Note that the files do
not exist until the user uses the A)rchive function. A SysOp who did not
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-12
wish to allow individual file downloads might only include these entries in
the MASTER.CDR rather than the other 18,000 entries.
The directory for the PC-SIG CD-ROM is over 1.5 megabytes in length and can
take up to 10 minutes to search completely (when using a PC at 4.77 MHz).
If the SysOp is using FMS, it is recommended that the category file for the
normal FMS directory and the category file for the Library FMS directory be
the same (PC-SIG has 27 different categories for its files).
12.8 Creating the Personal Files Directory
------------------------------------------
RBBS-PC's "personal" file support is analogous to RBBS-PC's support of
"personal" messages in that these files are specially addressed to a
specific caller or group of callers based on security. Through the user of
the FMS header, the rules governing personal downloads can be specified by
the SysOp. But, normally, personal file downloads differ from the general
download in three major ways:
1) the caller is given extra time to do personal downloads, so that the
qualifying caller is not limited to just the session time left. The
default extra time is 60 minutes, but can be set to whatever desired
using the TIMEEXTRA parameter in the header.
2) only files explicitly listed in the personal directory can be
downloaded. Normally files to be downloaded will be looked for on the
disk(s) where files are available for downloading whether they are
listed in a directory or not.
3) only callers with matching user record or sufficient security can
download a file. Normally any caller with security enough to issue
the download command can download a file.
Personal files provide a way that files can be delivered to specific
individuals. As an example, a vendor's support bulletin board for a
software product might make the upgrade downloadable only by paying
customers. A credit reporting corporation can make credit reports
electronically available only to the people who order them. Or, a SysOp
can make a file privately available to only one caller.
One of the most useful applications for personal downloads is to make
certain files available is spite of limited session time. Previously,
SysOps had to increase the security of callers or set artificially high
session limits just to make certain large files available. By putting
these file names in the personal directory and limited by security level,
these files can be made available regardless of how little time is left.
For example, the large files comprising RBBS-PC can be made downloadable to
all callers even though they are limited to 30 minutes.
Access to personal files can be limited in two ways. First, the files can
be downloaded only by callers which have a matching value in their user
record. For example, files can be limited by name (any field in the user
record can be selected). Alternatively files can be limited by security
level, meaning that a file can be downloaded by any person with that
security level or higher. File access based on security level can also be
accomplished using the standard RBBS-PC file security mechanism, but to do
so places the caller's under the standard RBBS-PC constraints of maximum
time per session/day.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-13
Using the "P)ersonal files" command in the files section, a caller is asked
what files the caller wants to download. The only files available to the
caller for downloading are those explicitly listed as belonging to the
caller, unlike the general download command which will look for any named
file on the disk. The caller can ask to List the files available. Callers
will see only those belonging to them.
There is a special option to download all and only the "new" files
specifically addressed to the user by matching a field in the caller's user
record. RBBS-PC keeps track of whether the caller has ever downloaded the
personal file. When listing, new personal files are marked with an "*" in
front of their names (they are "tagged"). Selecting the new files starts a
multi-file download for all and only the personal files the caller has
never successfully downloaded.
Files you want downloaded ONLY through the personal file features of
RBBS-PC should be put in their own subdirectory as specified in CONFIG
parameter 142. If you put the personal files in a download subdirectory
they would be available then to anyone who could name them. RBBS-PC will
search the download areas for a personal file if it is not found in the
subdirectory specified in parameter 142.
Creating a personal directory is easy for the SysOp. Simply upload a file
already there, do not omit it, and add a description. RBBS-PC will ask
you who the file is to. Just enter the name, and the described file will
be written right into the personal directory, using the personal directory
with the name specified in CONFIG parameter 143. This directory is the
same format as the general file directories of RBBS- PC. The format is as
follows:
Default Field
Positions Length Description of Field
1 - 12 12 The first 12 characters of an entry have the file name,
with no internal spaces.
13 - 73 Variable The next group of characters can have anything in them.
This will be displayed to the caller who asks for a
listing, along with the file name in the first 12
columns. The length of this group is 21 characters
plus the length of the upload description specified in
CONFIG (40-46, defaults to 40). The default length of
this field is 61 characters.
74 -104 Variable The next group of characters are what is used to
identify the file as "belonging" to the caller and must
match a field in the user record. In CONFIG parameter
43 and parameter 44, the SysOp specifies the position
in the user record to use and how many characters. The
default is to begin in column 1 and use 31 characters
for the caller's name, but any field in the user record
can be used. Optionally, a security can be entered in
this last field to limit the file based on the security
level of the caller. To use security rather than a
match on the user record, simply put a blank as the
first character in the field, followed by the security
level.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-14
105 1 The last character must be an "*" to signify that the
file has never been downloaded or an exclamation point
if ever downloaded.
This personal directory works very much like the File Management System
shared directory, using a field in the user record as the category and
limiting callers to their one category, or limiting the file to the group
of caller's with the minimum required security. The personal directory is
fixed length and read in reverse from bottom to top.
After setting up or modifying the personal directory, you use the CONFIG
utility parameter 187 to check whether the personal directory has the
proper format.
The personal directory can be created by a text editor (i.e. EDLIN) but be
sure to put in the "*" in the last column when creating a new entry so that
the file will be tagged as new. Also be sure to make each entry fixed
length. If the user's identity does not fill out the length of the last
field, be sure to pad the record with blanks out to the full length.
When setting up a personal file directory there are seven configuration
options peculiar to personal files:
CONFIG Description
parameter 43 what part of the user record used to identify files as
parameter 44 belonging to the user (beginning column and length),
parameter 143 the name of the personal directory,
parameter 142 the drive and path where the personal files and personal
directory are stored,
parameter 144 the protocol that must be used downloading,
parameter 147 whether the files downloaded are to be concatenated, and
parameter 188 the CONFIG utility to check the structure of the personal
directory to make sure it is in the proper format.
Parameter 147 and parameter 187 require some explanation of how they might
be used. Limiting the caller to a required protocol to use is not
something one would generally do. But, for special purpose downloads, like
downloading to a printer, one might want to require ASCII, for example.
Or, if all callers are to use the same communications package or only a
particular protocol is efficient, you can specify what callers must use.
Concatenating files means that when multiple files are specified for
downloading, the files are sent continuously in one stream of data rather
than individually as separate files. In effect, the files are physically
combined at the time of downloading. All messages between files are
suppressed - the only messages that appear to the caller are those that
normally occur when the first file transfer starts and when the last file
transfer ends. Concatenation is currently supported only for ASCII
downloads.
An example of a situation that might use this feature of RBBS-PC is a
business that generates short reports for clients. Their clients want to
call in remotely to get time-critical reports and print them right in their
office on pre-formatted paper. Each report is a separate file on RBBS-PC
with all the necessary printer commands already included in each file.
A SysOp might set up RBBS-PC such that the main menu was restructured to
make the P)ersonal files function be P)rint reports to reflect the more
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-15
specialized nature of the board. Callers to this board would call in,
identify themselves, and select P)rint reports from the main menu. Callers
could use L)ist to see what is available if they are looking for some
report in particular; just select all new reports; or ask for a particular
report if they must have it immediately.
In the last two cases, RBBS-PC would notify the caller to set up to receive
and press [ENTER] when ready. The pre-formatted reports with embedded
printer control sequences would stream out onto the paper (including
formatting like bold or underline) positioning the text to fit in boxes.
The paper is automatically advanced as needed. When done, RBBS-PC beeps
the user, who then turns the "save to printer" feature off of whatever
communications package is being used.
To set up this application, the personal file options would be configured
to use the caller's id (e.g. account number). The files and directory
would be put in a special subdirectory not shared with anything else. The
CONFIG parameters would be set to specify that caller's must use ASCII
("A") as their protocol and that multi-file downloads will be concatenated.
Another example is that of an electronic job placement service that wanted
to limit non-subscribers to a security level 5 with 10 minutes. However,
they also want non-subscribes to be able to download a file of potential
employment opportunities that may take more than 10 minutes. The following
entries would be put into PRIV.DIR:
JOBSFORU.ARC 282888 07-14-87 List of job opportunities you might want 5
/|\ /|\
12 74
Each record is padded with blanks so that 29 blank characters follow the
security level, followed by an '*'. The '*' is not shown in this
documentation since it is in a column too far to the right.
12.9 Automatically Checking & Converting Uploaded Files
-------------------------------------------------------
Verifying the Integrity of a File
---------------------------------
RBBS-PC's on-going commitment to providing SysOps with the ability to
protect themselves and their callers is reflected in precisely this kind of
feature. When a file is uploaded, RBBS-PC will look for a file called
T<ext>.BAT (where <ext> is the file extension of the uploaded file).
RBBS-PC looks for this file on the drive and path specified in CONFIG
parameter 105. If this file exits, RBBS-PC will SHELL to either:
a.) the program specified in the file (if it only has one line) or
b.) to the .BAT file itself.
In this way a SysOp may install whatever processing is desired after a file
has been uploaded.
If the BAT file contains exactly 1 line, RBBS-PC will shell to the contents
of the bat file, passing on the command line the two parameters:
a.) the name of the file upload (first) and
b.) the name of the file to write the results to (second)
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-16
If the BAT file contains more than one line, RBBS-PC will SHELL to the BAT
file itself, passing
a.) the name of the file upload for "[1]" and
b.) the name of the file to write the results to for "[2]"
as the first and second parameters, respectively.
RBBS-PC will consider the upload to have failed and delete the uploaded
file, if the file to which the results are to be written has a length
greater than 2 bytes. The BAT file should either
a.) not write a result file or
b.) leave an empty one if the upload is okay.
If the file that was uploaded is not okay, the external application should
write out some error message more than 2 bytes long.
A typical use for this feature of RBBS-PC is to test the compression of the
uploaded file and pipe the results to a text scanner that looks for an
error string and redirects the output to a file if an error is found. For
example if files that are uploaded with the extension .ZIP were to be
tested, a SysOp might create the file TZIP.BAT
PKUNZIP -T [1] | FGREP "error in a" > [2]
An alternative implementation is:
PKUNZIP -T %1
IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2
SETERROR 0
Under versions of QuickBASIC prior to 4.5, programs that reset the error
level cause illegal function call 5 upon return from the SHELL. Therefore
it is necessary to run a utility to reset the error level back to 0 before
going back to RBBS-PC. This is what the SETERROR.EXE file does.
The recommended procedure is to use PKUNZIP, check errorlevel, and reset
error level to 0. PKUNZIP outs somewhat variable strings when different
errors occur, making a filter based on text more difficult to implement.
Converting Uploads
------------------
RBBS-PC can be configured by the SysOp to cause uploads with extension <u-
ext> to be converted to the default extension <d-ext>. To do this, the
SysOp must put a file named C<u-ext><d-ext>.BAT on the drive and path
specified in CONFIG parameter 105. If the file exists, RBBS-PC will SHELL
to it.
If the SysOp wants all .ARC files uploaded converted to a .ZIP file, create
a file CARCZIP.BAT in the subdirectory specified in CONFIG parameter 105.
To convert .PAK files to .ZIP, create the file CPAKZIP.BAT. Sample
conversion batch files are included on the RBBS-PC distribution diskettes.
12.10 Fast File Search
---------------------
RBBS-PC 17.3 first included an enhanced file-search capability for uploads
and downloads. This enhancement has two advantages:
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-17
(a) File searches are much faster. In the case of very slow devices like
a CD-ROM, this can be the difference between sub-second response and
a 45 second response. File searches are now virtually instantaneous.
(b) Files not stored on this system can trigger macros. This allows
requests for files stored elsewhere, either off line on backups, or on
other cooperating systems, to trigger later processing.
The basis for the fast file search is a file, configuration parameter 267,
which is a sorted list of file names available for downloading. The
default name is FIDX.DEF.
The format of this file is:
columns 1-12: file name
columns 13-16: location index (1, 2, 3, ...)
columns 17-18: carriage return line feed.
All data is stored as character data and the file is editable. The file
names must be stored with no internal spaces and a period separating the
prefix from the extension. The list of file names MUST BE SORTED BY FILE
NAME in order for the fast file search to work.
The location index is the record number (line number) of the locator file,
whose default name is LIDX.DEF, and has the following layout:
columns 1-63: location of file
column 64: any character. MAKEFIDX puts in a period.
columns 65-66: carriage return line feed.
This file is all character data and is editable. Essentially, the
location index points to a record in the location file. E.g. if FIDX.DEF
has
RBBS-BAS.ZIP 2
HARPIE.ARC 3
and LIDX.DEF has
C:\DOWN1\
C:\DOWN2\
C:\UP\
Then RBBS-BAS.ZIP is located in directory C:\DOWN2 (2nd record) and
HARPIE.ARC is located in C:\UP (3rd record).
The location field should be a drive/path terminating with a "\" if any
path is given, and file must be filled with blanks through column 63 if the
path is shorter. You must put some character in column 64. Many editors
delete trailing blanks, so you should probably put in a non-blank. A
period is a suitable choice.
RBBS-PC will use a binary search on the first 12 characters in FIDX.DEF.
This binary search can be significantly speeded by provided "tabs" for this
file, indicating the record at which the first file is that begins with the
symbols "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". This is like the "tabs"
you see on dictionaries, so you can directly turn to the B's, for example.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 12-18
A tab file has the same prefix as the file name file, except that it adds a
"T". For "FIDX.DEF", the tab file would be "FIDXT.DEF". RBBS-PC will
automatically detect and use a tab file if available. The tab has 72
characters in it. Each 2 bytes represents a binary integer whose value is
the record number in FIDX.DEF where the first file occurs that begins with
the respective symbols above. Thus bytes 3-4 show where files begin with
"1" and bytes 69-70 where files begin with "Y".
Two utilities with source code are provided for setting up the fast file
searches. The source, for compiling under QB 4.5, is included.
MAKEFIDX will create both the file name list (FIDX.DEF) and the location
file (LIDX.DEF), from a list of directories (see MAKEFIDX.CFG) or a list of
file names, or both.
You must next sort FIDX.DEF by file name. A good shareware utility for
this is QSORT (QSORT FIDX.DEF /1:12).
MAKETABS will create a tab file (FIDXT.DEF) from the sorted file list
FIDX.DEF.
A sample batch file for recreating a fast file system is MAKEFFS.BAT. It
uses MAKEFIDX.EXE, QSORT.EXE, MAKETABS.EXE, and configuration file
MAKEFIDX.KG. You need only edit MAKEFIDX.KG to change the filespecs
(/FileSpec=) to match where your files are, and where to write the index
files.
Reconfiguring to Take Maximal Advantage of Fast File Searches
-------------------------------------------------------------
The fast file search is virtually instantaneous on an 8088 with a tab file
for 5000 file entries. The savings on wear and tear on the hard disk can
be very significant as well. And the time it takes to set up the fast
file search is only a few minutes. Most SysOps, therefore, will want to
implement fast file searching, whether or not they have a slow device like
a CD-ROM.
RBBS-PC will first search through the drive/paths specified in config to be
available for downloading, as it always did. Files not found there will
then be searched using the fast file search system. The way the fast file
search works is that a file found in its list is looked for only in the
designated location. Nothing else is searched.
The optimal way to implement fast file searching is to reduce the
drive/paths available for downloading to, at most, the upload directory,
and let the fast file search handle everything else. That way, files will
be searched first in the upload area, and those not found will then be
searched using the fast file search system. Note that every file in the
fast file search list is considered to be available for downloading whether
or not its drive/path is listed in the configuration program as a
downloadable area. Note that you can have separate fast file search
systems available for each sub-board. You can also use the fast file
search for common files and have a separate download area for the
sub-boards. Note that whenever you relocate files, you must re-create the
fast file search system. This is not hard since it takes little time and
can be automated.
RBBS-PC's FILE MANAGEMENT SUBSYSTEM Page 12-19
Macros with the Fast File Search
--------------------------------
The location file for the FFS (LIDX.DEF) can have in it "M! <macro file>",
where "<macro file>" is the name of a macro, instead of a drive/path.
RBBS-PC will then execute the macro. Thus, you can have special
processing for classes of files, perhaps to
o advise that the upload is not wanted
o tell the caller on what other BBS the file can be found
RBBS-PC will put a "U", "D", or "V" in work variable 1 depending on whether
the file request is to upload, download, or view, so that you can customize
your macro for the situation. This if you want to display a message only
on an upload, you could have UNWANT.IMC with
0
{ON [1]
{==U
{*B
The file {C1{FI{C0 is {C2NOT WANTED{C0 here.
Please do not upload it.
{END
{END ON
RBBS-PC regards the file as not found when a macro is executed. However,
you can use the macro command "LO" to set a new location that RBBS-PC will
use to look for the file. Thus, you can use macros for files that really
are present. For example, if RBBS-EXE.ZIP is downloaded, the file is
located in D:\D1, and the entry RBBS-EXE.ZIP in FIDX.DEF is mapped to a
record in LIDX.DEF with the entry "M! C:\RBBS\DWNRBBS.IMC", then the
following macro displays a special message but still causes the file to be
found:
0
{ON [1]
{==D
{*B
Congratulations. You are about to download the best BBS!
Call me voice at 703-978-4339 if you need any help.
{END
{LO D:\D1\
{END ON
SETTING UP ".BAT" FILES FOR RBBS-PC Page 13-1
13. SETTING UP ".BAT" FILES FOR RBBS-PC
---------------------------------------
In order for you to take advantage of all RBBS-PC functions, you must run
RBBS-PC via a .BAT file. When processing events such as DOORS, daily
maintenance and Remote DOS access, RBBS-PC exits to DOS, and expects the
.BAT file that invoked it to handle these events.
13.1 RBBS-PC's Startup Batch File
---------------------------------
The batch file (RBBS.BAT) that comes with RBBS-PC is capable of handling
these events, but in order to make full use of it, you must understand the
commands in it. RBBS-PC stores the name of this batch file in CONFIG
parameter 104. This example assumes you have installed RBBS-PC in the
directory C:\RBBS. Each line in the .BAT file is described below:
COMMAND DESCRIPTION
ECHO OFF This tells DOS not to display each command as it executes.
CLS This clears the screen.
C: This makes sure that when you start RBBS-PC, the default
drive is the one where RBBS-PC resides.
IF %node%. == . SET node=1
You should remove this line from RBBS.BAT, and place it in
the AUTOEXEC.BAT for each node. Of course, change the
number to correspond to the node number in each
AUTOEXEC.BAT. This function makes use of the DOS
"environment variable" concept. From now on, when you see
%node%, substitute the node number.
SET DSZLOG=XFER-%node%.DEF
You should remove this line from RBBS.BAT, and place it in
the AUTOEXEC.BAT for each node. This allows external
protocol drivers (such as DSZ) to send information to RBBS-
PC about the success of file transfers.
:START This is a "branch label" which allows RBBS.BAT to recycle
continuously.
CD C:\RBBS This line makes sure that when you start RBBS-PC, the
default subdirectory is the one where RBBS-PC resides.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%TM.DEF ...
DEL C:\RBBS\NODE%node%\RBBS%node%TM.DEF
This command checks for the DAILY EVENT signal file, and
deletes it. This is a "cleanup" command, which makes sure
there are no old signal files on the disk.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%F1.DEF ...
DEL C:\RBBS\NODE%node%\RBBS%node%F1.DEF
This command checks for the SysOp EXIT signal file, and
deletes it. This is a another "cleanup" command.
IF EXIST C:\RBBS\NODE%node%\RCTTY.BAT ...
DEL C:\RBBS\NODE%node%\RCTTY.BAT
This command checks for the DOOR signal file, and deletes
it. This is a another "cleanup" command. The path and
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 13-2
filename of this signal file can be set with CONFIG
parameter 103.
RBBS-PC %1 This command actually runs RBBS-PC. The %1 allows you to
specify options when you use the RBBS.BAT file. For
example, if you enter "RBBS LOCAL", the "LOCAL" is passed to
RBBS-PC, so you can run in local mode.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%F1.DEF GOTO EXIT
This command checks for the SysOp EXIT signal file, and if
found, exits the .BAT file. The SysOp EXIT signal file is
created whenever the SysOp presses F1 at the local console.
IF EXIST C:\RBBS\NODE%node%\RBBS%node%TM.DEF RBBSTIME.BAT
This command checks for the DAILY EVENT signal file, and if
found, runs the .BAT file RBBSTIME.BAT. The daily event can
contain any maintenance you wish to perform on a daily
basis. RBBS-PC will create the DAILY EVENT signal file at a
the time specified in CONFIG parameter 261.
IF EXIST C:\RBBS\NODE%node%\RCTTY.BAT C:\RBBS\NODE%node%\RCTTY.BAT
This command checks for the DOOR signal file, and if found,
executes it. The DOOR signal file is created when a caller
opens a DOOR, or the SysOp requests remote DOS operation.
GOTO START This command restarts RBBS-PC during a "recycle." The only
way to stop RBBS-PC completely is to press F1.
:EXIT This is a "branch label." When RBBS.BAT finds the SysOp
EXIT signal file, it branches here, which ends RBBS-PC and
returns to DOS.
For multi-node use, the command "RBBS-PC %1" must be changed to indicate to
RBBS-PC that you are running multiple nodes. The revised command would be:
RBBS-PC %node% RBBS%node%PC.DEF %1
13.2 The Daily Event .BAT file
------------------------------
CONFIG option 261 allows you to specify a time each day that RBBS-PC will
exit for daily maintenance. The supplied RBBS.BAT file can detect this
event (via the RBBS?TM.DEF signal file) and process a .BAT file. The
contents of the daily event file can contain whatever the SysOp wishes:
Tape backup commands, message packing, file verification or virus checking.
Just make sure that the daily event file re-invokes the RBBS.BAT file when
processing is complete, and RBBS-PC will resume after the maintenance.
THE USE OF RBBS-PC "DOORS" Page 14-1
14. THE USE OF RBBS-PC "DOORS"
------------------------------
A door is a program contained on the RBBS-PC machine which can be run by an
RBBS-PC caller. This allows the BBS user access to functions other than
those provided by RBBS-PC. After the door terminates, control returns to
RBBS-PC.
The concept of doors can be confusing and complicated, but from RBBS-PC's
perspective, it is simple:
When a caller requests a DOOR, RBBS-PC checks to see if the door
exists. If so, RBBS-PC will create a DOOR signal file and exit.
It is the responsibility of the invoking .BAT file (see section
13) to start the door. RBBS-PC will regain control when the
invoking .BAT file ends.
With this simplicity in mind, we will now explain the complex details of
door processing:
As a potential door installer, you should first become familiar with the
door program, WITHOUT RBBS-PC INVOLVEMENT! Most door programs can also be
run directly from DOS. Make sure the program works, and you understand it
before you expect RBBS-PC to run it.
Once you understand the door program, you must set up the interface to
RBBS-PC. A sample door is included with RBBS-PC. The door (DOORTEST) does
nothing, but it does show you how the interface works.
14.1 A Quick Start to Installing Doors
--------------------------------------
To install the door, follow these steps:
- Create the door batch file, and place it in the default RBBS-PC
directory (DOORTEST.BAT is an example). This batch file should
contain the commands needed to run the door, and then return to DOS).
RBBS-PC will automatically restart after the door.
- If you want maximum control over your door, create an entry in the
DOORS.DEF file (see section 14.3). Without this entry, the door will
still work, but you will be able to control more aspects of the door
interface with this control file
- Edit the MENU5 file (including the graphic and color versions) and
enter the name of your door. The door name must be IN CAPS, and the
first word on a line. The sample DOORTEST can be used as a guide. If
the door name is NOT in all MENU5 files, RBBS-PC will allow the SysOp
to exit the door, but your callers will not be able to use it.
RBBS-PC uses the MENU5 as a security measure. If the door name is not
found in this file, callers are denied access to the door.
14.2 The Major Problems with DOORS
----------------------------------
The hard fact about doors is that most DOS application programs that run
perfectly fine locally will not run correctly for a remote caller. The
general reason for this is that, compared the UNIX and even the old CP/M
microcomputer operating system, DOS has very limited support for access to
a computer from a remote site. The primary general problem is getting the
application to take its input from the communications port rather than the
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 14-2
keyboard and getting the application to write its output to the
communications port rather than the local monitor. In addition, even when
input is redirected to the communications port, some remote keystrokes may
not work, such as the function and arrow keys. Also, creating "full
screen" effects on a remote BBS is difficult, because of the wide variety
of monitors and terminal controller cards. Another general problem is how
to pass information between the BBS software and the program doored to,
such as limiting the amount of time a caller can spend in the door. Most
applications also are programmed to wait indefinitely for input and will
not time out. More seriously, if the caller drops carrier, the door should
terminate and send control back to the BBS software, whereas most
applications will totally ignore the fact that carrier drops. Finally,
many applications let the user issue DOS commands from within them or even
to drop to DOS, which would be an intolerable security risk for a BBS.
The upshot of all of these problems is that most, though not all,
applications that run acceptably as doors on BBS's have been especially
designed to run as a door.
14.2.1 Redirecting I/O
----------------------
The main facility DOS provides in its operating system for redirecting I/O
is the CTTY command. Unfortunately, this only works for applications that
use standard DOS bios calls to do I/O rather than "directly write to the
hardware". Unfortunately, the DOS bios for handling I/O is so slow that
most applications directly write to hardware rather than accept a
performance penalty. When SysOp function 7 is used, RBBS-PC will write
out a door that does nothing but redirect I/O and drop to DOS, then
terminate completely. What typically happens after the drop to DOS is
that the output of an invoked program appears on the local monitor rather
than the remote, so that the remote SysOp calling in sees nothing.
While being limited to programs that use standard DOS callers and print a
"line at a time" on the screen, scrolling prior lines up, CTTY has one
major liability. When the output is redirected from the console to the
communications port, nothing appears on the local monitor, so that the
SysOp "snooping" on the BBS is unable to see what the caller does while
dooring. This program is addressed by a device driver called GATEWAY which
adds local echo to remote sending. It is installed in CONFIG.SYS. For
doors, then simply say "CTTY GATE1" rather than "CTTY COM1". For drop to
DOS, simply tell RBBS-PC in configuration parameter 106 what device to use
after specifying you do not want to use CTTY.
CTTY does not work in every environment. For example, it is ignored under
Desqview and does not work properly under TANDY DOS. Also, with DOS it
fails to redirect standard error messages. To solve this problem
STDERR.COM is included as part of the basic RBBS-PC system. This program
was provided by Quarterdeck Systems. If you encounter this problem, run
"STDERR.COM" one time only before you start RBBS-PC, including it in your
AUTOEXEC.BAT file.
An alternative method for redirecting I/O is to use DOS redirection on a
command line. The ">xxx" redirects standard output to device xxx and
"<xxx" redirects standard input to device xxx. So, invoking program
"TEST" as follows
TEST <com1 >com1
THE USE OF RBBS-PC "DOORS" Page 14-3
should send and receive from communications port 1, if the application
supports DOS redirection.
A shareware product called DOORWAY goes a long way toward getting
applications never written to be a door to at least work remotely. You
simply door to DOORWAY and invoke the intended door through DOORWAY rather
than directly. While not every application will run, it does take care of
most I/O problems. See the documentation of DOORWAY on how to install it.
Programs written explicitly as a door will handle these problems
themselves.
14.2.2 Exchanging Information
-----------------------------
Most applications were never designed to take input from another running
program. This creates a problem for BBS's, which almost always limit the
session time a caller can have, so that the time a caller can spend in a
door likewise should have a upper limit, preferably no more that the
session time remaining that the caller has. One of the main advantages of
applications written as Doors is that they are designed to take information
from the BBS. RBBS-PC has for years written out information in a
standardized format, in a text file, for doors to read. This file is
DORINFOn.DEF, where n is the node id (1-9,0,A-Z), written to the same
drive/path as the caller's file, and consists of all text, one piece of
information per line, in the following order:
1. The name of the RBBS-PC system
2. The SysOp's first name
3. The SysOp's last name
4. The communications port being used
5. The baud rate and parity with which the caller logged on, and the
baud rate at which RBBS-PC is connected to the modem
6. The network type (if any) RBBS-PC is running in
7. The caller's first name
8. The caller's last name
9. The city and state the caller is from
10. The caller's graphics preferences (0 = none, 1 = IBM character
set, 2 = color graphics)
11. The caller's security level
12. The caller's max time allowed in the door
13. Whether fossil driver is used (-1 = yes, 0 = no)
RBBS-PC macros allow any information to be written to a file for a door in
nearly any format desired (see 13.4), as well as put different information
on a command line for the door.
RBBS-PC passes the node id as the first command line argument to the
batch file it invokes (or as specified in the door control file) so that
the DOOR knows which DORINFO file to read. There are external utilities
for converting DORINFO interfaces to other formats, for doors that support
different standards.
14.2.3 Terminating After Carrier Loss
-------------------------------------
Applications not written as doors typically will sit and wait forever for
input. They do not "time out", that is, terminate after a limited time in
which no input is received. After if the carrier is dropped, they do not
detect that the remote caller is "gone" and will sit forever waiting for
input. In effect, a dropped carrier "hangs" the BBS and no further calls
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 14-4
will be processed. Programs written as doors will terminate both for
inactivity and when carrier drops. The solution to this problem is to
install a memory resident program that will reboot the PC if carrier drops.
The public domain program WATCHDOG does this. Simply turn WATCHDOG on in
the first statement in the door batch file, and turn it off as the last
statement. WATCHDOG is not needed, and should not be used, for programs
explicitly written to be doors.
14.2.4 Security
---------------
SysOps should realize that doors greatly increase the security risks
associated with running a BBS. One general problem is that most
applications for personal computers assume that the user is the owner and
has access to everything on the PC. As a matter of convenience, they
often give the user access to many functions, such as deleting files, or
even shelling to DOS. This assumption is simply not true when remote
callers door to the application. Very few programs not designed to be a
door let the SysOp disable such dangerous functions.
14.3 Invoking "DOOR"s Via The External Control File
---------------------------------------------------
In addition to simply invoking "DOOR"s using the standard approach outlined
above, RBBS-PC supports a more sophisticated interface to doors. CONFIG
parameter 109 allows the SysOp to specify the name of this control file,
which is usually DOORS.DEF.
This approach allows each DOOR to be invoked in different ways.
Specifically, the SysOp can tailor the way each "DOOR" is invoked as
follows:
- The minimum security level to invoke each "DOOR" may be different.
- The caller may be required to answer a questionnaire before the "DOOR"
is invoked. This is extremely useful if the "DOOR" is a database
search program and the questionnaire gathers the necessary search
criteria from the caller prior to invoking the "DOOR".
- The "DOOR" may be either SHELLed to (RBBS-PC remains in memory and the
"DOOR" is loaded into free RAM) or EXITed to (RBBS-PC terminates
itself and releases the memory for the "DOOR" to use).
- The "DOOR" may be invoked via a "template" (see section 20.2) and
information passed to the "DOOR". "Templates" are useful when passing
information from a questionnaire to a database search program.
RBBS-PC normally passes the node ID as the first parameter to a
"DOOR". When using a "template" to invoke a "DOOR" the "template"
must include the parameter "[NODE]", if the node ID is to be passed to
the "DOOR".
- A file may be specified for RBBS-PC to display to the caller upon
returning from a "DOOR". This file may be created by the "DOOR" that
was invoked (i.e. the output of the database search and retrieval) or
simply a text file that the SysOp created.
- When returning from each "DOOR", the caller can be required to
re-enter their password as an added security verification.
THE USE OF RBBS-PC "DOORS" Page 14-5
- The maximum amount of time a caller can spend in each "DOOR" can be
specified. If the amount of time remaining the user has on the system
is greater than the amount of time allowed in the "DOOR", the smaller
of the two times is used.
The format of the door control file is:
1. Name of door - up to 8 characters
2. Minimum security to use door
3. Questionnaire to execute before the door
4. Method to invoke doors - "S" for shelling, else go to .BAT file
5. Template for invoking door - make sure the first word has a file
extension - RBBS-PC will check for existence of the first word as
file.
6. Whether to ask for password on return - Y is yes, anything else
bypasses password check
7. File to display after the door
8. Maximum time allowed in doors - time remaining passed to door is
reduced if max time is less.
Note: RBBS-PC normally passes the node id as the 1st parameter to a door.
If a template is used, RBBS-PC will not automatically add this parameter.
If you want it, you should include "[NODE]" in the template. Special note:
A door must still have a .BAT file in order to be invoked, even if the BAT
file is not used in the template!
Example #1:
MYDOOR,4,C:\RBBS\QUESTION\DOORQ.DEF,D,"MYDOOR.BAT [1] [2]",N,MYDOOR.TXT,
This line tells RBBS-PC:
- The name of the door is "MYDOOR"
- Users with security 4 and above can run this door
- Before starting the door, users are asked the DOORQ.DEF questionnaire
- RBBS-PC should EXIT and run the door (rather than SHELLING)
- The door is started by running MYDOOR.BAT, and two parameters
(presumably set in the questionnaire) are passed to the .BAT.
- The caller does NOT have to enter a password to return to RBBS-PC
- The file "MYDOOR.TXT" is shown to the caller before returning to
RBBS-PC
- No time limit (other than the caller's session time) is placed on this
door.
Example #2:
MYDOOR,10,,S,"MYDOOR.BAT [NODE]",Y,,10
This line tells RBBS-PC:
- The name of the door is "MYDOOR"
- Users with security 10 and above can run this door
- No questionnaire is asked before starting the door
- RBBS-PC should SHELL to the door (rather than EXITING)
- The door is started by running MYDOOR.BAT, and the RBBS-PC node number
is passed to the .BAT.
- The caller DOES have to enter a password to return to RBBS-PC
- No file is shown to the caller before returning to RBBS-PC
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 14-6
- A 10 minute time limit is placed on this door (unless the caller's
session time is less than this).
As with all features, the control file approach to invoking a "DOOR" is
optional. However, even if a control file is used, a "DOOR" can only be
invoked by a caller if a .BAT file exists.
14.4 EXITing or SHELLing to "DOOR"s
-----------------------------------
There are two ways to execute other programs from RBBS-PC:
1) EXITing RBBS-PC and invoking the other program via a .BAT file that
RBBS-PC builds dynamically, or
2) SHELLing to the other program while RBBS-PC remains in memory.
EXITing RBBS-PC allows other BASIC programs to be run as external programs
to RBBS-PC, and allows all of RBBS-PC's features to be active in computers
with only 320K of memory. The "price" that is paid is that upon returning
from the externally called program, RBBS-PC's .EXE file must be reloaded
into memory. Unless a control file is used to invoke "DOOR"s, RBBS-PC
always EXITs to "DOOR"s.
SHELLing prohibits other BASIC programs to be run as external programs to
RBBS-PC, consumes memory because RBBS-PC remains in memory when the other
program is running, and requires 386K of memory (under DOS 3.2) to activate
all of RBBS-PC's features. However, SHELLing does eliminate the need to
reload the RBBS-PC.EXE file each time.
14.5 Resetting The User's Record Via a "DOOR"
---------------------------------------------
WARNING -- this is an extremely powerful feature! It opens up everything
in the user record to modification by the "DOOR". The "door" must also
have knowledge of where fields are in the user record and may cease to work
properly when the user record changes its format. The main application for
this is feature within RBBS-PC if for "DOOR"s that maintain certain SysOp-
defined fields.
For a "DOOR" to reset any part of the user record all a door has to do is
include in DOUTx.DEF file, where x is node number, a line in the format
UR(<start>:<end>),<value>
where:
<start> is the beginning byte in user record,
<end> is the number of bytes to revise, and
<value> is what goes into the specified position in the user's
record.
For example,
UR(63:24),"City,State"
would update the city/state field with the value "City,State", setting 24
bytes in user record to that value (blank fill to right), beginning with
character position 63. The "UR" request only works for data stored in
character format in the user record. RBBS-PC supports a second request in
the form
THE USE OF RBBS-PC "DOORS" Page 14-7
SL,<sign><value>
where "SL" stands for security level. <sign> can be nothing, plus, or
minus, and means respectively to set the security level to the following
value, or to raise or lower the security by the amount specified. For
example, "SL,6" requests that the security be set to 6 whereas "SL,-2"
means to lower the security by 2.
14.6 A Summary of "DOOR"s
-------------------------
Doors stretch IBM's DOS' capabilities and requires more knowledge than most
other BBS functions. If the preceding discussion of "doors" is a complete
mystery to you, contact a SysOp of an RBBS-PC that is using "doors" and ask
for help. However, if you call a SysOp to learn about "doors" for personal
gain (i.e. you are a consultant or some company's employee being paid to
write a "door") have the courtesy to tell him. Please do not take
advantage of the "user helping user" concept. Anyone who has acquired
specialized knowledge has the right to be remunerated for their efforts if
their knowledge is being used to further commercial purposes and they
request it.
THE SECURITY FEATURES OF RBBS-PC Page 15-1
15. THE SECURITY FEATURES OF RBBS-PC
------------------------------------
RBBS-PC has always been an open system designed for public use. A SysOp
should always ASSUME that EVERY FILE ON THE PC running RBBS-PC CAN BE
DOWNLOADED AND/OR DESTROYED. However, RBBS-PC has extensive
safeguards that systematically enhance security and privacy. For
example, RBBS-PC has the logic within it's code to prohibit anyone
(including the SysOp) from downloading the RBBS-PC "system" files described
in section 6.2. RBBS-PC can still be run as a wide-open system, but
the SysOp has many additional options to restrain access. These
security options make RBBS-PC much more suitable for private and business
use.
RBBS-PC's security is controlled by three things:
1. the system configuration file (RBBS-PC.DEF),
2. the two external security files for
a. passwords (PASSWRDS), and
b. file downloads (FILESEC), and
3. the users file (USERS) in which each user has an assigned
security level.
The users file is controlled by the SysOp user maintenance function 5
as described in section 16. To change a specific users security level you
select the M)odify option and then the S)ecurity option. This allows you
to set the security level for a user. Users cannot set their own security
levels. Section 15.3 describes how to implement special passwords that
provide special privileges to the groups that issue them. Section 15.4
describes how specific files, groups of files, or even whole disk volumes
can have download security levels associated with them.
15.1 RBBS-PC's Security Features
--------------------------------
Each user has an assigned security level, permitting 65,536 possible
security levels. Each command in RBBS-PC also has a security level
assigned to it. Security assignments are controlled by the SysOp. To use
a command, the caller's security level must be at least as high as the
command's security level.
The SysOp can assign a file or group of files both a security level and a
password. To download a file, a caller must have a security level at least
as high as the file's and be able to give the file's password (if one is
present). All users must pass these security tests, including anyone with
SysOp privileges.
Messages can be assigned a password by their creator. Then only persons who
are able to give that password can read or kill the message. Messages with
password protection will show <PROTECTED> when scanned. Callers have no
way of distinguishing messages to private individuals and to groups except
by how they are addressed. Persons with SysOp privileges can read all
messages. See section 15.2 for an example of group passwords.
Security violations are logged to the CALLERS file. These include
attempting to use functions without sufficient security clearance and
failure to give required passwords.
RBBS-PC's default configuration is that of an "open" system.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 15-2
RBBS-PC's security system provides the SysOp with several choices on how to
run RBBS-PC. The chief ones are as follows:
1. Change the bulletin board from an open system available to all callers,
to a pre-registered system available only to specified users. To support
this option, there is a function in the SysOps user maintenance option 5 to
ADD users.
2. A SysOp can set up different "classes" of users by assigning different
security levels to different users. Concurrently the SysOp would have to
assign different security levels to different commands. For example, new
callers might be permitted only to leave a comment, read bulletins, and
list files that can be downloaded. Or there might be a group of files
assigned a security level that only members of a special interest group can
download.
3. The SysOp can segregate the functions of the bulletin board into
different groups based on a password. A specific file or group of files
can be downloadable only to those who know the password. Similarly,
messages can be made open to everyone knowing the password but closed to
everyone else. This way there can be semi-private portions of the bulletin
board.
15.2 Examples of Uses for RBBS-PC's Security System
---------------------------------------------------
Some examples of how a SysOp can tailor RBBS-PC using RBBS-PC's extensive
security features follow.
SPECIAL INTEREST GROUPS -- A special interest group (SIG) in a users group
wishes to run a RBBS-PC for both the general public and its own use.
An example would be an authors SIG for persons interested in publishing
books and articles or developing commercial software. A definite need
would exist to be able to address messages to everyone in the SIG without
making them open to every caller. The SIG would establish the convention
to password protect general SIG messages with the password AUTHORONLY,
and to address them to AUTHORS SIG.
Another example would be a bulletin board devoted to the exchange of
software. Allowing persons to use the message subsystem would only
interfere with the primary purpose of the bulletin board. Therefore the
SysOp removes from the menu the functions for leaving and reading messages.
To prevent a person from using the functions to leave or read a message
(even though they are not displayed), the SysOp assigns these functions a
security level higher than a person who logs on normally would be assigned.
Another example of using RBBS-PC's security system would be to set up an
agreed upon temporary password such that when a user logs onto the system
they can issue the password and get longer than normally allowed. If the
time for normal users is 30 minutes, the SysOp can set up the special
password SOFTEXCHANGE, with a maximum time on of 150 minutes instead of the
normal 30. By shifting over to this special password after logging in,
members can get extra time if they need it.
SOFTWARE SUPPORT -- An author of a freeware program offers RBBS-PC support
to all persons who register their copies and send a contribution of, say,
$35 per copy. The registered user can get answers for problems and
download free updates and sample applications. The author wants anyone to
THE SECURITY FEATURES OF RBBS-PC Page 15-3
be able to call just to find out about the service. New callers get a
security level of 2 automatically assigned to them. This allows them to
use only the message subsystem. The file subsystem is assigned a security
level of 7. Contributors are added by the SysOp with a security level of
7 and a pre-assigned password. Except for SysOp functions, registered
users have free reign in the RBBS-PC.
CLIENT SUPPORT -- A SysOp on a public RBBS-PC also works as a management
consultant. She has several associates who work with her on projects. She
needs to be able to send and receive messages from her associates which the
general public should not see. So they agree on a message password
NOTPUBLIC. To support her different clients she also needs to leave private
files for downloading. To each client she assigns a special downloading
password. To restrict downloading to just that client, file names are put
in the file security file with the appropriate password. Only persons with
the password can then download them.
PRIVILEGED ELECTRONIC MAIL -- A company uses RBBS-PC to help support its
regional offices. Only regional vice-presidents should be able to download
certain management reports. In file security these reports are assigned a
high security level of 9, which only managers get.
15.3 How to Implement the Password File
---------------------------------------
CONFIG allows the SysOp to designate the name of the file containing the
privileged group passwords to RBBS-PC. Since this file is a normal ASCII
file, the SysOp can use any text editor to create and update the file.
Put the information for each password on a single line and separate the
fields with commas. It is important to note that EACH record of the
password must contain THIRTEEN parameters (i.e. 12 commas). For the
password file, the format is:
prm1,prm2,prm3,prm4,prm5,prm6,prm7,prm8,prm9,prm10,prm11,prm12,prm13
where:
prm1 -- password that this line applies to
prm2 -- security level for password. If no password was specified, this
is the user security level this line applies to
prm3 -- maximum time in minutes for a single session
prm4 -- maximum time in minutes per day
prm5 -- number of days in the subscription period
prm6 -- security level to drop to when subscription expires
prm7 -- start time, in format HHMM 24 hour style, this line applies to
prm8 -- end time, in format HHMM 24 hour style, this line applies to
The start/end time are limits on all other parameters: meaning that they
apply only during the specified times. Specifying 0 for start/end times
means that this line applies all day.
prm9 -- the type of ratio method to use. This should be one of the
following:
'0' - meaning use the files uploaded to files downloaded ratio
'1' - meaning use the bytes uploaded to bytes downloaded ratio
'2' - meaning use the files per day restriction
'3' - meaning use the bytes per day restriction
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 15-4
Note: first time callers must upload at least one file (byte) before
downloading unless they are:
exempt from the ratio requirements,
are using the daily ratio method, or
an initial upload credit has been granted.
The initial credit field is ignored for methods 2 and 3.
prm10 -- the ratio field. A positive integer, such as 15, placed in this
parameter requires that the caller maintain a ratio of a least 1 file (or
byte) uploaded for every 15 files (or bytes) downloaded. The ratio of
uploads to downloads can be cumulative over multiple days or it can be
limited to the current day's activities of the caller.
A 0 tells RBBS-PC to record uploads, but it will not record downloads, nor
will it enforce ratios. This allows the SysOp to have a "free" download
period.
A -1 tells RBBS-PC to record uploads and downloads, but not to enforce
ratios. This allows the SysOp to keep records of each user's transfers,
but it will not stop a user from downloading as much as time allows.
prm11 - the initial credit field. This can be any positive integer
including zero. The use of ratio methods 2 and 3 in conjunction with this
field can restrict the number of files (or bytes) that can be downloaded by
an individual or group of callers per day.
prm12 - the elapsed time (in seconds) that a caller must wait after logging
on before "Time Locked" features will become available. See the
description of CONFIG parameter 155 for a full description of how "Time
Lock" works.
prm13 - the maximum number of minutes that can deposited in the time bank.
Here are some examples of how the PASSWRDS file might be used:
,5,50,,,,0001,0600,,,,, Security level 5 gets 50 session minutes
,5,25,,,,,,,,,, between 00:01 AM and 6 AM, and 25 minutes
otherwise.
,7,50,70,730,,,,,,,,
Security level 7 has a subscription period of 2 years and a session limit
of 50 minutes, and a daily limit of 70 minutes.
BIGTIME,6,52,,,,,,,,,,
Temporary password BIGTIME gets 52 minutes per session and a security of 6.
EXTEND,5,120,,9999,,,,,,,,
Temporary password EXTEND gets 120 minutes for the current session (the
user's elapsed time per day would still remain whatever was set in CONFIG
parameter 8), a temporary security level of 5, and a subscription period of
9,999 days.
,7,128,256,,,,,,,,120,15
THE SECURITY FEATURES OF RBBS-PC Page 15-5
Users who log on with a security level of 7 are automatically granted 128
minutes on the system for each session, 256 minutes total for each day
(independent of what was set in parameter 8 of CONFIG), and their
subscription period remains unchanged from whatever it was before, but they
must wait 120 seconds before being able to exit to a "door" or download a
file. They can bank at most 15 minutes.
SKIPRATIO,170,120,200,90,,0600,1200,0,0,,,
Temporary password 'SKIPRATIO' grants the caller a security level of 170, a
session limit of 120 minutes, a daily time limit of 200 minutes, a 90 day
subscription period, during the hours of 6AM until noon with no ratio
limits. No downloads are added to the counts for the user. Changing the
last "0" to "-1" would cause the counts to be added but not acted on to
limit downloads.
,140,60,60,365,,0001,2400,1,10,,,
Users with a security level 140, have a session limit of 60 minutes, a
daily limit of 60 minutes, a one-year subscription, but during any hour of
the day they must maintain a ratio of 1 byte uploaded for every 10 bytes
downloaded. There is no initial upload credit. Therefore, an upload must
take place before a download.
,150,70,,90,,,,0,15,2,600,
Users with a security level of 150, have a session limit of 70 minutes, a
90 day subscription, must maintain a ratio of 1 file uploaded for every 15
downloaded. An initial credit of 2 files are granted to all new/existing
users. However, they can not exit to a "door" or download a file for the
first 10 minutes (600 seconds) of their session.
,165,90,,120,,,,0,30,,90
Users with a security level of 165, have a session limit of 90 minutes, a
120 day subscription, must maintain a ratio of 1 file uploaded for every 30
downloaded. No initial upload credit is granted. They can bank up to 90
minutes.
,170,120,,365,,,,2,10,,,
Users with a security level of 170 have a session limit of 120 minutes, a
one-year subscription limitation, but can only download 10 files per day.
,200,360,,730,,,,3,250000,,,
Users with a security level of 200 have a session limit of 360 minutes, a
two-year subscription, but can only download 250000 bytes per day.
If you are using COPY CON to create this file you "MUST" press F6 followed
by a Ctrl/Z at the end of the last entry prior to pressing carriage return.
15.4 Implementing Security for Download Files
---------------------------------------------
CONFIG allows the SysOp to designate the name of the file containing the
passwords and security levels that can be used to restrict downloads of
specific files, volumes, or file names meeting certain "wildcard" criteria.
This file contains file names with download restrictions in the format:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 15-6
<filename>, <security level>,<password>
Note: Each line is a record and ends with carriage-return line-feed. The
only optional field is the password field for a filename. By leaving the
password field empty, no password is assigned to a file. The commas
between the fields are necessary. YOU MUST HAVE TWO COMMAS ON EACH LINE
even if you do not have a password associated with the file.
Some examples would be:
COMMAND.COM, 10,DOS
PAYROLL.DAT, 99,BANKRUPT
CALLGIRL.SEX,,ILLEGAL
\FINANCE\STOCKS,100,
The file COMMAND.COM could not be downloaded unless a user had a security
level equal to or greater than 10 AND could supply the password "DOS". The
file PAYROLL.DAT could not be downloaded unless a user had a security level
equal to or greater than 99 AND could supply the password "BANKRUPT". Any
user could download the file CALLGIRL.SEX if they could supply the
password "ILLEGAL". Any user with a security level of 100 or higher
could download the file STOCKS in the DOS subdirectory FINANCE without
supplying any password.
Additionally "wild-card" characters and drive designators can be used to
protect or restrict certain classes of files (by extension, by drive, etc.)
from being downloaded.
Some examples would be:
A:*.*,8,
E:*.SEC,2,PW1
A*.M*,0,GX3
XY?X.*,9,3XG
All files on drive A would require the users to have a security level of 8
in order for a user to download them. Any user who wanted to download a
file whose extension was ".SEC" and was found to be on drive E would have
to not only have a security level of at least 2 but to also give the
password PW1. The third entry above would require a user who wanted to
download any file on any drive with a prefix that began with "A" and an
extension that began with "M" to have a security level of at least 0 and to
enter the password GX3. Finally, the last entry above would require any
user who wanted to download any file on any drive whose four-letter name
began with "XY" and whose last letter was "X" with any extension to have a
security level of at least 9 and enter the password 3XG.
The wildcards "*" and "?" operate just like they do in DOS with two
exceptions. The "?" requires a character. In DOS the name "HAPPY"
satisfies the file specification "HAPPY?" but it does not in RBBS-PC.
Also, in RBBS-PC, a wildcard applies to an extension only if it occurs
after a period. Thus "xyz*" in DOS finds "xyz.a" but not in RBBS-PC
("xyz*.*" will find it).
To get exceptions to the general rule, just put the exceptions first.
RBBS-PC's file security search stops with the first applicable entry that
it encounters. For example,
THE SECURITY FEATURES OF RBBS-PC Page 15-7
1. if you want all files on the B drive to require the user to have a
security level of at least 3,
2. except that files on the B drive with the extension ".SEC" would
require the user to have a security level of at least 6, and,
3. regardless of the disk drive that they were on, any file beginning
with "MES" with an extension of ".SEC" would require the user to have
a security level of at least 12
you would enter the following into the file security file
MES*.SEC,12,
B:*.SEC,6,
B:*.*,3
Special Note: RBBS-PC is hard-coded so that there are some files that
nobody can download -- not even the SysOp. These are RBBS-PC.DEF, users,
messages, callers, group password, comments, the file security, and backup
files. Similarly the batch files that control RBBS-PC and let the caller
exit to DOS cannot be downloaded. The default security file provided with
RBBS-PC is empty.
15.5 Implementing Security for RBBS-PC Commands
-----------------------------------------------
RBBS-PC allows each command to be assigned it's own security level. A user
who wishes to invoke an RBBS-PC command must have at least the same
security level as the command. Let's assume that a SysOp wants to set up
the following classes of users:
Classification of Users Security Level
"Locked Out" Users 0
New Users (first time) 1
Normal Users 2
Users who can "view" a Conference 3
Users who can enter Messages 4
Users who can download files 5
Users who can upload files 6
Users who can Join a Conference 7
Users who can do some SysOp commands (Jr. SysOps) 8
Users who can enter a "door" 9
Users who can enter all SysOp commands (Co-SysOps) 10
The following table illustrates one method of assigning each RBBS-PC
command it's own security level:
Security Level
Subsystem/Command Assigned to Command
Messages Subsystem
A>nswer questionnaire............... 4
B>ulletins.......................... 1
C>omments........................... 1
D>oor subsystem..................... 9
E>enter message..................... 4
F>iles system....................... 1
I>nitial welcome.................... 1
J>oin a conference.................. 7
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 15-8
K>ill messages...................... 4
O>perator page...................... 1
P>ersonal mail...................... 2
R>ead messages...................... 2
S>can messages...................... 1
T>opic of messages.................. 1
U>tilities (more)................... 1
V>iew conference mail............... 3
W>ho's on other nodes................3
@>Library Sub-System.................1
Files Subsystem
D>ownload........................... 5
G>oodbye............................ 0
L>ist file directories.............. 4
N>ew files.......................... 5
P>ersonal downloads................. 5
S>earch directories for string ..... 1
U>pload a file...................... 1
V>erbose listing of file............ 1
Utilities Subsystem
B>aud rate.......................... 1
C>lock (time of day)................ 1
E>cho selection..................... 1
F>ile transfer protocol............. 1
G>raphics........................... 1
L>ength of page..................... 1
M>essage Margin..................... 1
P>assword change.................... 1
R>eview preferences................. 0
S>tatistics of system............... 1
T>oggle (line feeds, etc.).......... 1
U>serlog............................ 2
Library Subsystem
A>rchive a Library disk..............5
C>hange a Library disk...............5
D>ownload........................... 5
G>oodbye............................ 0
L>ist file directories.............. 4
S>earch directories for string ..... 1
V>erbose listing of file............ 1
GLOBAL commands
?>What can be done.................. 1
H>elp with a command................ 1
Q>uit to another subsystem or exit.. 1
X>Expert/novice toggle.............. 1
SYSOP Subsystem
1>List comments..................... 8
2>List callers log..................10
3>Recover a Message................. 8
4>Erase comments.................... 9
5>USERS maintenance.................10
6>Toggle page bell.................. 8
7>Exit to DOS 2.x or above.......... 9
15.6 Beware of the "Trojan Horse!"
----------------------------------
Despite RBBS-PC's security always remember that you should always assume:
THE SECURITY FEATURES OF RBBS-PC Page 15-9
"EVERY FILE ON THE PC RUNNING RBBS-PC CAN
BE DOWNLOADED, MODIFIED, AND/OR DESTROYED!"
RBBS-PC's security system appears to be so fool-proof that some individuals
have resorted to uploading programs that appear to do one thing, but
actually do something else. These "trojan horse" programs search all the
disks that are connected to the PC that the program is running on for such
RBBS-PC files as RBBS-PC.DEF or USERS. The program then copies these files
to an innocuously named file that can be downloaded later when the person
who uploaded it logs onto the system again. Since RBBS-PC.DEF contains the
pseudonym that the SysOp can use to logon on remotely as the SysOp, once
the user downloads a copy of it the user can then log on as the SysOp and
do just about anything including exiting to DOS and formatting all the
disks on the system. Similarly, the USERS file contains passwords and the
security levels of everyone on your RBBS-PC -- some of whom may have SysOp
privileges.
You can protect yourself against anyone logging on as you, the SysOp, by
not allowing anyone to logon as the SysOp remotely (see CONFIG parameter
121). You can protect yourself against unauthorized access of the USERS
file by simply not allowing any user to have SysOp privileges.
Of course there is the "trojan horse" program that doesn't even bother with
the above, but simply destroys all the disk files on all the disks that are
connected to the PC that is running the program.
SYSOP FUNCTIONS Page 16-1
16. SYSOP FUNCTIONS
-------------------
The SysOp functions are separated into two groups: Those functions that the
SysOp, or user with sufficient security, can use while logged onto the
RBBS-PC, and those functions that are available from the local console.
16.1 SYSOP Commands Within RBBS-PC
----------------------------------
The following operations can be performed by the SysOp, or any user with
sufficient security, at the main RBBS-PC command prompt:
1 - Type COMMENTS file. The contents of the COMMENTS file is displayed.
If commets are saved as PRIVATE MESSAGES, the only time comments will
appear in this file is when the message file is full.
2 - Type CALLERS file. A log is maintained of all persons who have called
the system. This function will list the file showing the users name
and the date and time signed on as well as a log of their activity.
This function is also available through the UTIL menu (function U).
3 - Resurrect a message. This function will restore a message that has
been killed. If the message file has been "packed", the killed
messages are no longer recoverable. The function will ask for the
message number of the message to be recovered.
4 - Erase the COMMENTS file. This function will erase the comments. A
new comments file will be created the next time a user leaves a
comment.
5 - USERS file maintenance. The users file contains entries for each user
registered with the system. This function permits the SysOp to:
A)dd -- add a user to the USERS file.
L)st -- list the USERS file.
P)rt -- print the USERS file on the printer.
M)od -- modify a record in the USERS file.
S)can - scan each record in the USERS file for a particular string.
In <M>odify mode, limited editing of the users record in the USERS file can
be done. The following subfunctions are available:
D - Delete the user.
F - Find another user in the USERS file.
M - Return to the option 5 function prompt.
N - Give the user a new password.
P - Toggle the printer flag to print entries on the printer.
Q - Quit and return to the main message prompt.
R - Reset the user's graphic mode.
S - Set the security level of the user. This can be used to lockout
or grant special privileges to the user.
X - Modify user's upload/download counts.
# - locate any record number within the USERS file.
$ - Change the user's Registration date.
In <M>odify mode a record will be displayed followed by a subfunction
prompt for action. To get to a specific record the record number can be
entered at the prompt and if valid that record will be displayed. If the
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 16-2
record number is invalid or [ENTER] is pressed, the next record in the file
will be displayed.
6 - Toggles the operator page bell on/off. This overrides the "office
hours" specified in the RBBS-PC.DEF file.
7 - SysOp drop to DOS as a remote user. If the SysOp has logged on
remotely and is running RBBS-PC under DOS 2.0 or greater, this
function will use the door interface to create a "remote DOS shell."
RBBS-PC must be able to process door exit .BAT files in order for this
to work (see section 13). The SysOp will then see the DOS prompt at
the remote terminal and can execute whatever DOS commands or programs
the CTTY command supports. DOS will look for COMMAND.COM to be
present on the disk drive you specified in parameter 105. SysOp
function 7, unlike "doors," loads in a copy of COMMAND.COM to run
under the copy that was running RBBS-PC. Also be sure to read
Appendix T and make sure that you THOROUGHLY understands the
limitations that DOS places on you when this option is invoked.
Two areas of caution are advised when using SysOp function 7 under DOS 2.0
or above. First, each SysOp should test what can be done remotely.
Software that reads and writes directly to the video BIOS and does other
things that bypass the standard input and output of DOS simply won't
function correctly. Second, you should be aware that you are in DOS and
can return to RBBS-PC only by issuing the EXIT command. This will return
to the batch file that was built dynamically by RBBS-PC. This file will
then continue executing and is designed to reassign the keyboard as the
console and then re-invoke RBBS-PC. If you get disconnected while in DOS,
your system will be locked up. The console will be assigned to your
communication port and your modem will have dropped the line and will have
been set not to auto-answer. The only way to restore the system is a
manual power off/on sequence.
16.2 SysOp Use of Function Keys and Numeric Pad
-----------------------------------------------
The following function keys are available at the local console, while
RBBS-PC is waiting for a call, or while a caller is online. If RBBS-PC is
operated in LOCAL mode (COM0), RBBS-PC will not allow a non-SysOp user to
access privileged local commands (i.e. a local user cannot raise his
security level with the + key).
F1 - Return to DOS. This is only active when RBBS-PC is waiting for a
call. When the SysOp presses F1, RBBS-PC takes the modem "off hook",
so incoming calls will get a busy signal. It then creates a file in
the same directory as the CALLERS file named RBBSxF1.DEF ("x" is the
node ID). RBBS-PC then returns to DOS. The invoking batch file
should check for the presence of the RBBSxF1.DEF file and halt if it
is present after running RBBS-PC.
F2 - SHELL to DOS. RBBS-PC remains resident but suspended in memory, the
user (if any) remains on-line and the local SysOp is in DOS until the
EXIT command is issued, which returns control back to RBBS-PC and the
caller.
F3 - Printer toggle on/off. This changes the printer on-line status. When
on-line, the printer will print each caller's name and the filenames
uploaded/downloaded. It will also print all unexpected error
SYSOP FUNCTIONS Page 16-3
messages. This function should only be turned ON when a printer is
attached to the RBBS-PC computer and is ready to print.
F4 - Operator page toggle. This changes the status of "operator annoy"
(i.e. allows the SysOp to be pageable). Operator page time limits are
set by CONFIG parameter 7. This toggle will override the SysOp's
"office hours."
F5 - Tells RBBS-PC to answer the phone and check for an incoming carrier
immediately.
F6- SysOp available. This changes the status of operator available
setting. This is useful if during your "office hours" you temporarily
don't wish to be disturbed.
F7- SysOp NEXT. After the current caller logs off, RBBS-PC will initiate
a local SysOp login.
F8 - Allows the SysOp to grant an on-line user temporary SysOp privileges.
This is a toggle on/off switch.
F9 - SNOOP toggle. This key switches SysOp SNOOP on/off. When SNOOP is
OFF, the local screen will clear. When SNOOP is ON, the local screen
will be updated to reflect what the RBBS-PC user is seeing.
F10- This is the forced chat switch. It announces your presence to the
caller and then allows both you and the caller to type and see each
other's words. The ESC key is used to exit Forced chat mode or to
answer an "O>perator page" request. The F10 key will not function
until a user logging on has reached the Main Menu.
END- Informs the current caller that the SysOp needs the system, then
updates his user record and politely logs him off.
CTRL END
- Logs off and locks out the current user that is on and informs the
user that their presence is unacceptable.
PgUp Displays information about the current user. This information is only
displayed on the local screen. The user's screen is unaffected.
PgDn Clear the local screen (used to remove information displayed via the
PgUp key).
LEFT ARROW
- Subtracts one minute from the user's current session time. Ctrl-Left
Arrow subtracts five minutes from the user's current session time.
RIGHT ARROW
- Adds one minute to the user's current session time. Ctrl-Right Arrow
adds five minutes to the user's current session time.
UP ARROW
- allows the local SysOp to increment an on-line users security level by
one. CTRL-up-arrow or CTRL-PgUp will increase the security by 5.
DOWN ARROW
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 16-4
- allows the local SysOp to decrement an on-line users security level by
one. CTRL-down-arrow or CTRL-PgDn will decrease the security by 5.
The SysOp can also enter commands on the command prompt line while a caller
is on-line. The command entered will cause the system to respond just as
it would if the caller had entered the command. This should be used with
caution because it could confuse a new system user -- users are often timid
enough without knowing that big brother is actually watching them! Let
callers page you and then tell them that you can assist with commands if
they get into trouble.
16.3 Local Status Display
-------------------------
RBBS-PC maintains a status display on the bottom line of the local display.
The items in the display are in the following form:
Node ? AP! PG! AVL ANY LPT SYS 999 NAME CITY, STATE UM UU UB UD
Where:
Node ? is the node number
AP! Indicates this user triggered an AutoPage (see section
7.11).
PG! This caller paged the SysOp.
AVL The SysOp is AVAILABLE
ANY The SysOp ANNOY switch is on
LPT The PRINTER LOG is active
SYS The SysOp wants a LOCAL log-in next
999 The caller's security level
NAME The Caller's name
CITY, STATE The Caller's City and State
UM The MESSAGE file lock (UM=unlocked, LM=locked)
UU The USER file lock (UU=unlocked, LU=locked)
UB The USER BLOCK lock (UB=unlocked, LB=locked)
UD The upload dir/comment lock (UD=unlocked, LD=locked).
MESSAGE AREAS WITHIN RBBS-PC Page 17-1
17. MESSAGE AREAS WITHIN RBBS-PC
--------------------------------
RBBS-PC is intended to be an open system. As such it can have an unlimited
number of message areas and messages. At the very minimum, RBBS-PC has a
single
1) message area, a file named MESSAGES,
2) user file, a file named USERS, and
3) definition file, a file named RBBS-PC.DEF
In addition to this, additional messages areas can be created as either
"conferences" (i.e. areas that use the same RBBS-PC.DEF file as the main
RBBS-PC message area) or "sub-boards" (i.e. areas that have their own .DEF
file).
17.1 "Conferences" and "Sub-boards" -- the Differences
------------------------------------------------------
A "conference" or "sub-board" can be:
1) "public" -- any caller can join.
2) "public with a separate user file" -- any caller can join and RBBS-PC
remembers the last message read by each caller and will notify a
caller on logon that new mail is waiting.
3) "semi-public" -- only callers with security levels equal to or greater
than that specified for the conference can join.
4) "semi-public with a separate user file" -- only callers with security
levels equal to or greater than that specified for the conference can
join and RBBS-PC remembers the last message read by each caller and
mail waiting.
5) "private with a separate user file" -- only callers who have been
pre-registered in the separate user file for the conference can join
and RBBS-PC remembers the last message read and mail waiting.
A "sub-board" is just a conference that also has a configuration definition
file (.DEF). Sub-boards can be public, private, or semi-private. Access
to a sub-board is controlled by the configuration parameter 123 which sets
the minimum security level required to enter the "sub-board." A
"sub-board" configuration file has the same format as the RBBS-PC main
configuration file, and is created and edited using CONFIG.EXE. This
allows a "sub-board" to have its own unique welcome file, commands,
security levels, menus, help, bulletins, directories, and up and download
areas. "Sub-boards" can share as much or as little as desired with other
conferences or other "sub-boards" within the same RBBS-PC system. The only
things a "sub-board" cannot change are the primary MESSAGES file and the
communications parameters used by the RBBS-PC it is running under.
To the caller, a "sub-board" appears just like another bulletin board,
accessed from a bulletin board rather than through a telephone number.
Public sub-boards, just like public boards, are those whose minimum
security to join is not higher than the default security for new users.
"Sub-boards" basically allow a single telephone number to offer very
different types and levels of services. Independent "sub-boards" run under
the same RBBS-PC service radically different types of terminals/PC's.
Within the same RBBS-PC, one "sub-board" may have 80 column menus for IBM
and compatible PC callers, another may have 40 column menus for Atari and
Commodore PC users, and still another may have 20 column menus for those
using telecommunications devices for the deaf (TDD's). No longer is it
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 17-2
necessary to provide three independent telephone numbers for three such
different services. All callers can dial the same number and simply switch
over to the appropriate board. Extra lines can be added to a roll-over and
service all the boards. "Sub-boards" make it much easier and feasible for
a SysOp to market bulletin board services by allowing hardware to resources
to be pooled under one software "umbrella" such as RBBS-PC and yet service
a very diverse set of requirements -- much the same way that Compuserve
does. One of the best hardware configurations for running a multi-board
service like this is PC-Slaves, because adding additional boards are
extremely easy, with virtually no system degradation.
"Sub-boards" greatly benefit "umbrella" organizations. For example, a
computer club that covers IBM computers, Apple, Atari, and Commodore. No
longer does software intended for one type of computer have to get mixed in
with listings for another computer. Each computer can have not only
separate messages, but bulletins and directories as well.
"Sub-boards" make it easy to have different "levels" of service based on
security level. Many SysOps run both a "free" and a "subscription" board.
The most typical arrangement for this is to have the free board be on the
bottom of a telephone roll-over and the pay board be on the top, and for
the top board to require a higher security level. Non-subscribers who call
the pay board number get "kicked" off the board. "Sub-boards" on the same
telephone line would give both paying and non-paying callers equal access,
if desired. Another example is that callers with enhanced security can
join a sub-board to get access to even more downloads. Or, executive
officers for an organization can have access to a "sub-board" that has not
only special messages but special bulletins and files.
The naming conventions of the files associated with a "conference" or "sub-
board", for example called CLONES, would be:
CLONESM.DEF --- the message file
CLONESU.DEF --- the user file
CLONESW.DEF --- the "welcome" file (for conferences only)
CLONESC.DEF --- the configuration file (for "sub-boards" only)
Using the configuration .DEF file associated with a "sub-board" allows each
SysOp to make the "sub-boards" as unique or similar as desired. Two
security levels are very important. The minimum security to log on to the
board determines who can join the "sub-board". And the default security
level is what newly added callers are assigned.
A "sub-board", like any conference (public, semi-private, or private) is
closed to all who have insufficient security. To make a "sub-board"
completely private, simply set the minimum CONFIG parameter 123 (the
minimum security level a new user needs to logon) to be higher than any
normal caller would have. The only way for callers to be able to join a
completely private "sub-board", like a private conference is for the SysOp
to have added them previously to the users file associated with that "sub-
board".
The security level a caller gets when auto-added is the default security
level for the "sub-board" and not the current security level of the caller.
This is to prevent special privileges that a caller has in one "sub-board"
from automatically propagating into other "sub-boards". For example, a
caller with SysOp privileges in one "sub-board" who joins another does not
become receive SysOp privileges in the other.
MESSAGE AREAS WITHIN RBBS-PC Page 17-3
The security level used to determine what "sub-boards" a caller can join is
not the current security level but the original security level the caller
had on the main board.
RBBS-PC detects if the bulletins in the "sub-board" are the same as in the
main RBBS-PC system and does not re-display them when a "sub-board" is
joined.
"Sub-boards", public conferences, semi-private conferences, and private
conferences can all co-exist within the same RBBS-PC system. Sub-boards in
turn can have sub-boards in them, as well as public, semi-private, and
private conferences.
The primary disadvantage of "conferences" or "sub-boards" that have
separate user files associated with them is the additional disk space that
is required for the users file. RBBS-PC's CONFIG parameter 290 allows the
SysOp to let a user on as a "guest" if there is no more room left in the
users file for the "sub-board", semi-private conference, or private
conference. Not having a user record defeats one of the main mechanisms
for remembering a user's preferences, of course, but the SysOp can start
with a smaller users file and expand later without the risk of denying
callers access.
Obviously, "sub-boards" take more time to set up and maintain. While it is
nice to be able to have parts of RBBS-PC vary radically from one another,
every one that does vary is another item to create and maintain. "Sub-
boards" can multiply the work necessary, for example, to maintain
bulletins. There are more users and message files to oversee. However,
Kim Wells MU-EDIT is an invaluable tool for managing multiple message and
user files. Give Kim's RBBS-PC call at (301) 599-7651/7652 and get a copy
of MU-EDIT.
17.2 Making a "Conference" or "Sub-board" Successful
----------------------------------------------------
To make a "conference" or "sub-board" successful several guidelines should
be followed rather rigorously:
1) Establish a "conference" or "sub-board" chairman (i.e. a SysOp) to
manage the conference. The SysOp's job is to add new users, delete old
ones, make sure that the subject and/or the agenda of the conference
is adhered to by killing messages that are inappropriate. This is
best accomplished by having a separate user file for each "conference"
or "sub-board" in which the caller only has SysOp privileges when in
the specific "conference" or "sub-board."
2) Establish an "agenda" or list of subject areas for the "conference" or
"sub-board." One of these should be about new subject areas. These
areas should be VERY narrow in scope. The essence of any good
conference is keeping it focused. Everyone has been in at least one
meeting/conference that was a waste of time because whoever was
running the meeting/conference did not keep the dialogue centered on
the subject or agenda.
3) If a continuity of dialogue is to be achieved, it is advisable to keep
the conference "focused" -- either by keeping the number of conference
members limited, or by keeping the subject matter very narrow.
Another interesting thing about "private" conferences and sub-boards
as implemented within RBBS-PC is that they are not "public" and,
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 17-4
therefore, are even more protected by the first, fourth, and fifth
amendments.
17.3 Setting Up a "Conference" or "Sub-board"
---------------------------------------------
The SysOp sets up a "conference" using the CONFIG utility parameter 167 to
pre-format up to two files -- one for the messages to be associated with
the conference and one for the users to be associated with a conference.
The name of a "conference" can be from one to seven characters that are
valid for a file name. RBBS-PC will add "M" (for the messages file
associated with the conference) or a "U" (for the users file associated
with the conference) to the filename. The SysOp can then enter the
conference member's names in the conference USERS file by using the SysOp
function 5. The SysOp can "join" any conference and need not be in any
particular conference's USERS file.
Like "conferences", RBBS-PC supports an unlimited number of "sub-boards".
"Sub-boards" are equally easy to create. If CLONES were the name of a
public conference (the CLONES message file CLONESM.DEF exists), all that
would have to be done to make CLONES a "sub-board" would be to run CONFIG
to
1) create a separate user's file, CLONESU.DEF, for this formerly public
conference (if didn't already have a users file),
2) create a "sub-board" configuration file for the CLONES "sub-board"
(a file whose name would be ATARIC.DEF).
The easiest way to make a "sub-board" configuration file is to use the DOS
copy command, starting with another configuration file as a model (e.g. the
one for the main board). To continue with the CLONES example you would
issue the DOS command:
COPY RBBS-PC.DEF CLONESC.DEF
Then invoke CONFIG.EXE to edit that file, using the form
CONFIG CLONESC.DEF
WARNING!! When you create a .DEF file by copying another one as a model,
be sure to run CONFIG against this new file and change the message and user
file names! Otherwise your sub-board will share the user file with another
message base. Here change the message file name to CLONESM.DEF and the
user file name to CLONESU.DEF. The users file name can be anything for a
"sub-board" but the extension .DEF is a good idea because RBBS-PC's
security system will not let any file with that extension be downloaded.
Remember, you do not want to allow callers to download any users file! You
get an extra layer of protection if you put the message, user, and
configuration files in an area not available for downloading.
17.4 Conference File Locations
------------------------------
The files that make up a conference or a sub-board can be placed in several
locations. Especially on multi-node BBSs, care must be taken when locating
conference files.
If a sub-board CONFIG files exists, it must either be in the RBBS-PC
default directory, or in the directory where the MAIN message file is
located. NOTE: If a caller joins a sub-board from within another sub-
board, the MAIN message file location would be the location of the first
MESSAGE AREAS WITHIN RBBS-PC Page 17-5
sub-board. Once a sub-board CONFIG file is found, all other file locations
will be set by the CONFIG file parameters.
If there is no CONFIG file, RBBS-PC will next look for a MESSAGE file.
First, the subdirectory where the current MAIN message file is located will
be searched, and then the directory where the conference description file
is located (see CONFIG parameter 74) will be searched.
To find the USER file, RBBS-PC first looks where the current message file
is located, and then where the current user file is located.
This may seem complex, and for most SysOps, placing all CONFIG, MESSAGE and
USER files in the default subdirectory is adequate. CONFIG will create,
and locate conference and sub-board files properly when parameter 167 is
selected.
BBS's that have a large number of conferences can easily find that the
files are collectively too large to put on a single drive. It is possible
to relocate the users and messages files of subboards on other drives.
However, if you simply move the user and message files, RBBS-PC will be
unable to detect that the subboard exists. For a relocated subboard to
be found, you must
put a small, dummy message file in the same drive/path as the main
message file.
E.g. for subboard "DCONF" to be found, put a file "DCONFM.DEF" where the
main message file is. This dummy file can have any size and not need be
in the format of RBBS message files. Then edit the subboard DEF file to
reflect the new location of the user and message files. Do NOT relocate
the DEF file for the subboard.
17.5 Establishing a "Conference" or "Sub-board" SysOp
-----------------------------------------------------
RBBS-PC has one of the more flexible and powerful systems for supporting
"assistant SysOps" or "conference moderators". A moderator need not be
made a full SysOp, and whatever security a moderator has, does not transfer
to the rest of the board. Moderators need the following basic functions:
1) read and kill all messages,
2) add and modify users, and
3) forward mail to a better person to answer it.
The ability to do user edits is controlled by the security specified by
SysOp function 5. Incidentally, moderators cannot edit user records with
security higher than theirs. The ability to read and kill all messages is
controlled by a security level specified in CONFIG. RBBS-PC supports
having separate user files for every message area, so that moderator
privileges in one area do not necessarily transfer to others.
To set up a conference or sub-board moderator, the SysOp need only
1) "Join" the conference or sub-board.
2) Use SysOp function 5 to enter the name of the user who is to be the
conference chairperson into the conference's USERS file.
3) Set that users security level in the conference's USERS file to a
security level that can issue the SysOp function 5. This will allow
the conference chairman to add users.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 17-6
4) Set the minimum security to read and kill all messages to the level of
the moderator.
5) Set CONFIG parameter 140 to the security level of the moderator.
This will allow the moderator to forward everyone's mail.
Any registered user can join a "public" conference or sub-board. When
someone issues the J)oin command to join a conference or sub-board, their
standard security level is temporarily superseded by the security level
associated with their user name within that conference's or sub-board's
USERS file if it is a "private" conference.
For example, a normal user might be given the security required to add
users to a particular conference or sub-board USERS file since they are the
SysOp of that message area. When a user joins the conference or sub-board
of which they are chairman, their normal security is bumped up so that they
can add users to the USERS file of that particular message area. When the
same user exits that message area, their security level is returned to
normal. If they should subsequently join another message area where they
are not chairman, they would be unable to add users to that message area's
USERS file. Other than a message area's SysOp, none of the message area
members should be given any higher security than they otherwise enjoy as a
regular RBBS-PC user.
17.6 Carbon Copy
----------------
RBBS-PC supports a "carbon copy" function for messages and personal uploads
that lets the caller send them to one or more recipients. Messages can be
addressed to multiple recipients. Recipients can be specified in two
ways:
o individually, one at a time, in response to the "Who to" prompt.
o as a group, via a "distribution list".
Distribution lists are stored in a particular drive path specified in
configuration parameter 171. The distribution list to be used is selected
using option "D" in response to who to. Then the caller can name a
particular distribution list by name. The name will have the extension
".LST" added to and be looked for in the distribution drive/path. If the
caller is in novice mode or asks for help, the help file specified by
configuration parameter 170 will be displayed. This help file basically
should be a menu of distribution lists. The names in the distribution
list should be one to a line.
WARNING: multiple recipients change the structure of the message base.
Message utilities may not work properly with this modification. Do not,
for example, use MU-PURGE.
The ability to have multiple recipients in a message is controlled
by parameter 160. The default is not to allow carbon copy. If
you are using NetMail or external message utilities, you should set
the message base to disallow multiple recipients.
Configuration parameter 159 is the minimum security to do a
personal upload. By setting it low or high you can suitably restrict
who can upload files directly for another caller. Calls will be
notified on logon whether they have a personal upload waiting for
them.
MESSAGE AREAS WITHIN RBBS-PC Page 17-7
RBBS-PC works the following way with messages with multiple headers:
o the individual header is removed in a purge when it is marked as
killed and the count of the number of headers is reduced by one.
o the body of a message is not removed in a purge until all headers
are killed.
o if any header is to the person reading, that header controls the
access of the person. If that header is killed, for example, the
person can no longer read the message at all, unless the person has
sufficient security to read/kill all mail. If the killed message is
public, the person can read the message but it will be treated as
someone else's mail.
o when the caller says to kill a message, the caller can kill at most
the controlling header, unless the caller can read/kill all mail, in
which case the caller is individually asked to confirm the killing
of each header after being told the message number and who it is to
(though it would certainly be permissible to give the option to kill
all of them at once).
o "et al." is added to the display of the message header, at the end of
who the message is to, when the message is to more than one person.
The "et al." is NOT stored in the message header. Each person the
message is to sees the "et al." after their own name. "et al." This
Latin for "and others".
17.7 Linked Message Bases
-------------------------
RBBS supports Linked message bases. The concept is what when doing any
kind of message read forward or backwards, RBBS will continue that read to
the linked message base. The gives the caller the ability to group
together message bases so that message operations can be "global". The
chief advantage to the caller is what one read operation can sweep all the
mail in all the conferences, without having to recall where mail is and
join the conferences.
The default in a conference view on logon is to link together all
conferences that the caller belongs to that have any new mail. When doing
an interactive conference view, the caller has the option to L)ink and
D)elink individual conferences. When doing a join, the caller can link
all conferences with any new mail (S)ince last on) or all conferences in
which the caller has new
personal mail (P)ers). Thus "J S" or "J P" are options. The join is
immediately followed by a join to the first linked conference. Join N)ext
also is the option to join to the next linked conference.
When conferences are linked, any kind of a message read that terminates
with a forward or backwards read results in the option to continue to the
linked conference, provided the read "global" option is selected. Thus
when "2" and "sysop" are the linked conferences, an "r s g" in the main
message base will result in the prompt "Continue to linked conference 2
([Y],N)?" "r 30+ g" will also result in the same query, as will "r l g"
or "r 100- g". However, "r s 103 109 g" will not because it does not
terminate with a forward read. The linked conference will be read just
like the original read. Thus a read based on a string will continue, as
will a read of "my" mail. The only difference is that a forward read will
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 17-8
continue as a read "since last message" and a read backwards will continue
as a read from "last message backwards".
The caller can also have RBBS read global without having to do any
confirmation of the automatic join by selecting non-stop in the read
command, such as "r s g c" (read since global continuous).
CALLERS AUTOMATIC NOTIFICATIONS OF MAIL WAITING Page 18-1
18. CALLERS AUTOMATIC NOTIFICATIONS OF MAIL/FILE WAITING
--------------------------------------------------------
RBBS-PC has the ability to notify callers about mail or files waiting for
them when they log on. File notification means that the caller received a
personal upload. Personal uploads are accessed using either the file
L)ist command, P)ersonal option, or the file P)ersonal download, option
list. Callers can be notified for any pair of user/message files
(a) how many new messages were left,
(b) whether any new messages are to them personally, and
(c) whether any new uploads are to them personally.
RBBS-PC can be configured such that the messages individually reported by
number to the caller when the caller logs on are all messages (i.e. both
old and new, or just new messages since the caller last logged on, or
no messages at all via CONFIG parameter 19. Of course, RBBS-PC allows the
SysOp to determine if callers are reminded of the mail they have left.
In a file specified in CONFIG parameter 93 (the default is CONFMAIL.DEF),
the SysOp can list the message/user file combinations to check for
mail/file waiting in the format
<user file>,<message file>
where these are related conference file names. If it is assumed that RBBS-
PC is running in a DOS subdirectory off of the main root directory of the
"C:" drive and that there are two conferences, RBBS-PC and BETA, then an
example of the contents of the CONFMAIL.DEF file is:
C:\RBBS\BETAU.DEF,C:\RBBS\BETAM.DEF
C:\RBBS\RBBS-PCU.DEF,C:\RBBS\RBBS-PCM.DEF
The names are processed exactly as typed, so inclusion of the drive/path is
necessary. The SysOp controls what conferences get checked for mail by
listing these file pairs. Conferences not listed will not be checked.
Callers will get a report only for conferences that they are a member of.
Two items of information are reported:
number of new messages since last in the conference,
whether any new messages are addressed to the caller, and
whether any new uploads are addressed to the caller.
The name used in RBBS-PC for the main message base is taken from the file
name for the message base. As with conferences - if the prefix of the user
file ends with "M", the name will be composed of all but the last
character. If the name is "MESSAGES", it will be called "MAIN". Otherwise
the main message base will be called the full prefix.
The main message base and users file can be included in the list to scan.
You may want to coordinate the USERS and MESSAGES file names in the same
fashion that conference user files and message file names are coordinated.
If the main message base is to be known as TOP then call it TOPM.DEF and
call the users TOPU.DEF. RBBS-PC will work just as well with the default
names USERS and MESSAGES, and will call the main message base MAIN.
There are 3 philosophies that can be implemented on message reporting using
the CONFIG parameter 19:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 18-2
1) Report everything.
2) Make a fast minimal report.
3) Make an optimum intermediate report.
Reporting everything means reminding callers of messages they left, and
give the message numbers of old and new mail. To do this it is necessary
to set configuration parameters to remind callers of old mail and to report
ALL messages to caller. Also place "sub-boards" and private conferences in
the mail scan list of CONFMAIL.DEF.
Making a fast minimal report means that callers will not be reminded of old
messages, specific message numbers will not be listed, only the number of
new messages and whether any are personal will be reported. This option is
for when you want people to get the caller to the command level as fast as
possible. For example, the main message base is not even used. To do this
set configuration parameters to NOT remind callers of old mail and to
report NO messages to caller. Put the main message base as well as "sub-
boards" and private conferences in the mail scan list of CONFMAIL.DEF.
Providing an optimum intermediate report means reporting individual message
numbers only for the new mail as well as # of new messages (and whether any
personal). The best way to implement this is to set the level of reporting
messages to the caller to New Only and to put all "sub-boards" and private
conferences in the mail scan list of CONFMAIL.DEF. Set CONFIG parameter 21
to NOT remind callers of old mail.
RBBS-PC QUESTIONNAIRE FACILITIES Page 19-1
19. RBBS-PC QUESTIONNAIRE FACILITIES
------------------------------------
RBBS-PC provides a script-driven questionnaire facility. RBBS-PC will
process a questionnaire when a NEW caller logs in, before any caller logs
off, or the user can select a questionnaire from a menu. To ask new users
questions the file named in CONFIG parameter 84 must exist. To ask
questions of users when they say G)oodbye the file named in CONFIG
parameter 85 must exist. Questionnaires can also raise or lower the user's
security level based on his/her responses. Answers to the questionnaire
are appended to a file specified in each questionnaire script.
RBBS-PC will only activate the corresponding script files if they exist,
otherwise the functions are bypassed. A questionnaire can theoretically
have up to 256 lines in it, but, depending on the length of the lines
comprising it, the pratical limit is about 240 lines. Longer
questionnaires require the use of "chaining".
The questionnaire script processor supports:
- Branch to labels (forward and back branching)
- Display lines
- Display line and get response
- Response validation (Multiple choice)
- Numeric validation
- Raising and lowering user security level
- Aborting the questionnaire
- Chaining to another questionnaire
- Invoke a macro from within a questionnaire
- "Turbo" key can be turned on from within a questionnaire
The first line in every script file must contain the file name where the
responses to the script will be appended, and the maximum security level a
user can be raised to. The rest of each script file contains script
commands. Script commands are 1 character in length and must be in column
1 of each script line.
Following is a list and description of valid script commands:
: A colon indicates a label command
* An asterisk indicates a display data command
? A question mark indicates a display and wait for response command
= An equal sign indicates a multiple choice branch command
> A greater than symbol indicates a goto command
+ A plus sign indicates a raise security level command
- A minus sign indicates a lower security level command
@ An "at" sign means to abort questionnaire and do not write results
& An ampersand means to establish a questionnaire chain
T The letter "T" turns on the "turbo" key mode
M The letter "M" executes a "macro"
> Assigns a value to a work variable
CONFIG parameter 94 controls the maximum number of work variables that can
be handled by questionnaires.
RBBS-PC questionnaires even support "graphics" versions of the
questionnaires. Graphics versions use the standard convention of ending
the filename with "C" for color graphics and "G" for ansi graphics. E.g.
HLPRBBSC.DEF and HLPRBBSG.DEF are graphics versions of HLPRBBS.DEF.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 19-2
19.1 Branching to Labels
------------------------
: Colon (Label command)
This command is used to provide labels that can be branched to from =
and > commands.
:QUESTION1
Numeric labels are not recommended because they are easy to confuse with
work variables. SmartText variables will be interpreted as such, eg.
":-{FN" will substitute the user's first name. SmartText and Work
Variables are dynamically substituted into all questionnaire lines. For
example,
>-.[8].-
will substitute the value of work variable 8 for "[8]", so that if 8 has
"edit" as its value, it will go to the label "-.edit.-".
The ability to get and substitute values, and to have graphics versions,
means that questionnaires can support many of the features of full screen
editing, including transmitting a template, then overlaying values into the
template. An example that shows the power of questionnaires is
?29Change what field (1,2,...20)
?[29]Change field [29]. from [[29]] to
This asks which field to change and stores answer in work variable 29 (i.e.
value of work variable 29 is "7"). The second question then stores the
answer in the value of work variable 29, displays the name of the work
field being changed, and then displays the old value of the work variable.
Suppose that the value of work variable 7 is "Yes". Then the series of
substitutions RBBS-PC makes into the second line before executing it are:
?7Change field [29]. from [[29]] to
?7Change field 7. from [[29]] to
?7Change field 7. from [7] to
?7Change field 7. from Yes to
19.2 Display Data Command
-------------------------
* Asterisk (Display data command)
This command is used to send data to the user. SmartText and Macro
commands are interpreted before display (see section 7.8). "*/FL" will not
display the "/FL" because it is interpreted as a macro command. If you
want to work variables to overlay a display template, keeping it's length
(e.g. for columnar display), put "/FL" after the "*". E.g. if variable 1
has value "12345" and 2 has "abcdef", then
*/FL.[1]....[2]......
will display ".12345..abcdef...", whereas
*.[1]....[2]......
will display ".12345....abcdef......".
RBBS-PC QUESTIONNAIRE FACILITIES Page 19-3
One of the more useful capabilities of macros that questionnaires can make
use of is the ability to append data to any work file, where work variables
are merged into a form. This allows the questionnaire data to be saved in
virtually any format desired.
The other extremely useful macro capability that questionnaires can utilize
is the ability to retrieve data from a file into a form, in effect adding a
data based file retrieval capability.
19.3 Display Data And Get Response
----------------------------------
? Question mark (Display data and get response)
This command is used to send data to the user and wait for a response.
The user will be required to input a response. The ENTER key alone is an
invalid response. No other checks are made.
?DO YOU OWN YOUR OWN PC? (Y/N)
The prompt command accepts an optional number which is interpreted as the
number of the Work Variable to store the answer in. For example, "
?8Enter Dept
will store the answer not only in the regular way for a questionnaire but
also in work variable 8.
19.4 Multiple Choice Response
-----------------------------
= Equal sign (Response validation - Multiple choice)
This command is used in conjunction with the ? command and must
immediately follow the ? command for which it applies. This command allows
for checking/editing of single character responses to the preceding ?
command and allows branch logic to be exercised based on the response
given. Multiple = commands must be coded on the same line. The format
follows:
=AXXXXXXXXX=BYYYYYYYYY= ZZZZZZZZZZ
= Indicates that a single character comparison value follows
A Is the comparison value
X Is the label to branch to if the response is "A"
= Indicates that a single character comparison value follows
B Is the comparison value
Y Is the label to branch to if the response is "B"
= Indicates that a single character comparison value follows (SPACE)
This is a special comparison value that is always used as the last
comparison value and means "INVALID" response given
Z Is the label to branch to if an invalid response is given
Maximum line length is 255 characters and the last = on the line "MUST"
have a comparison value of " " (SPACE).
:QUESTION1
?Do you run a BBS system. (Y/N)
=YQUESTION2=NQUESTION2= QUESTION1E
:QUESTION1E
*Please respond Y or N
>QUESTION1
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 19-4
:QUESTION2
There is an additional format for the = command, where the comparison
value of # (Pound sign) is used. This is used as a numeric check and
encompasses 0-9, (), - and space. This format requires two entries.
The first is to test for numerics and the second is the invalid response
branch label (e.g. "=#QUESTION3= QUESTION2E").
19.5 Forward And Backward Branching
-----------------------------------
> Greater than sign (Forward and backward branching)
This command is used to branch to specific labels within the script
file.
>QUESTION4
19.6 Raise/Lower User's Security Level
--------------------------------
+ Plus sign (Raise user security level)
This command will add the value in columns 2-6 to the default security
level given new users or the current security level of old users.
+5
- Minus sign (Lower user security level)
This command will subtract the value in columns 2-6 to the default
security given new users or the current security level of old users.
-1
19.7 Abort Questionnaire
------------------------
@ At sign (Abort questionnaire)
This command will terminate the questionnaire and NOT write the response
to the output file as in the following example.
:QUESTION1
?Have you answered the questionnaire before. (Y/N)
=YQUESTION2=NQUESTION3= QUESTION1E
:QUESTION1E
*Please respond Y or N
>QUESTION1
:QUESTION2
@
:QUESTION3
19.8 Chain Questionnaire
------------------------
& Ampersand (Chain questionnaire)
This command will establish the next questionnaire in the chain. The file
named in columns 2-80 will be used as a continuation to the current
questionnaire when the current questionnaire reaches its last line.
i.e. &L:\RBBS\QUESCONT.DEF
RBBS-PC QUESTIONNAIRE FACILITIES Page 19-5
19.9 Turbo Keys
---------------
T Turbo Key
This is used to turn on Turbo Key for a prompt where a single keystroke is
expected. TurboKey causes the next keystroke to be taken as the answer
immediately without having to press Enter, if the caller has TurboKey on.
19.10 Macro Execute
-------------------
M Macro Execute
This command is used to execute a specified macro named after the command,
e.g. "M C:\RBBS\FIZ.IMC". Control returns to the questionnaire after a
macro is executed. One of the most important capabilities macros add to
questionnaires is the ability to append data to any file in any format
desired. Hence the data in questionnaires can be saved where ever desired
in whatever format desired. If a macro saves the data and you do not want
the normal output on completion of the questionnaire, just abort the
questionnaire at the end. Macros also have the ability to retrieve data
from files and then display on the screen.
19.11 Assign Value
------------------
< Macro Assign
This command assigns a value to a work variable. For example, "<2 XT"
assigns value "XT" to work variable 2.
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS Page 20-1
20. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS
-----------------------------------------------------
RBBS-PC includes a flexible interface for implementing file-transfer
protocols. A "protocol" for the exchange of files is just a set of
cooperative conventions that allow two different computer's software to
transfer files between themselves. RBBS-PC supports four "protocols"
within its own BASIC source code -- ASCII, Xmodem (checksum), Xmodem (CRC),
and 1K-Xmodem. These are totally configurable by the SysOp when setting up
RBBS-PC.
In addition to these four "protocols" and in order to provide advocates of
specific protocols a means of adding their particular flavor of
communications protocol to RBBS-PC, a standard interface has been created
so that "external" protocols can be installed in RBBS-PC. "External"
protocols are simply defined as programs outside of RBBS-PC which perform
the file transfer.
Before calling "external" protocol drivers, RBBS-PC will do the following:
1) verify that the file exists if the file is to be downloaded.
2) for uploads, verify that the file name requested is valid.
3) pass control of the communications port to the external protocol.
RBBS-PC will call the external protocol drivers either via the SHELL
command in BASIC or via a .BAT file.
20.1 Parameters passed to a protocol driver
-------------------------------------------
RBBS-PC detects the installation of external file transfer protocols via an
optional RBBS-PC system file whose default name is PROTO.DEF. If no such
file exists, only internal protocols will be available -- Ascii, Xmodem,
XmodemCRC, 1K-Xmodem. This file may be used to rename or delete some or
all of RBBS-PC's internal protocols. If a PROTO.DEF file exists, all of
RBBS-PC's internal protocols must be specified in it as well. Internal
protocols are NOT automatically included when a PROTO.DEF file exists!
The protocol definition file has thirteen (13) parameters passed for each
external protocol defined for RBBS-PC. Each parameter can be on a separate
line of its own or all parameters can be on a single line (separated by
commas). The parameters passed for each protocol specified are:
Parameter Description
1 Protocol Name
2 Security Level required to use protocol
3 Method to invoke protocol
4 Whether 8 bit connection required
5 Whether "reliable" connection required
6 Whether "batch" mode supported
7 Number of bytes in a block transferred
8 Indicate transfer always successful
9 Factor to estimate file transfer time
10 RBBS-PC "macro" to invoke before protocol
11 Method for checking transfer's success
12 Template to use for downloading
13 Template to use for uploading
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 20-2
Protocol Name -- The FIRST CHARACTER is the letter by which a caller
selects the protocol. The prompt for the selection of protocol includes
the protocol name. It is recommended that the second character be ")" to
resemble the rest of the prompts in RBBS-PC, e.g. "Z)modem". RBBS-PC will
normally put each protocol on the same line, separated by a comma, until
the line gets too long. The SysOp can control the placement of the line by
putting a carriage return line feed at the end of the protocol name. If
this is done, the entire protocol name must be in parentheses. For
example, instead of the prompt
A)scii,X)modem,C)rcXmodem,Y)modem,N)one
a SysOp may want the prompt to be
A)scii (text files only)
X)modem checksum
C)rc Xmodem
Y)modem (1K Xmodem)
N - None (cancel)
Then the protocol definition file , PROTO.DEF, should be constructed using
quotes (to include the carriage return/line feed in the first parameter) as
follows:
"A)scii (text files only)
",...
"X)modem checksum
",...
"C)rc Xmodem
",...
"Y)modem (1K Xmodem)
",...
"N - None (cancel)
",...
with the remaining 12 parameters put where "..." occurs.
Security Level -- This is the minimum security to be able to use the
protocol being described.
Method to Invoke Protocol -- A protocol can be invoked by one of three
methods:
shell,
door, or
internal (S, D, or I).
If "I" is specified, it must be immediately followed by a letter specifying
what internal protocol to use, where the choices are A, X, C, Y, or N
respectively for Ascii, Xmodem, Xmodem CRC, 1K-X(Y)modem, or None (cancel
transfer). "IC" would mean to use RBBS-PC's internal Xmodem CRC. If no
protocol is specified equivalent to the internal "None", RBBS-PC will add
it. If the letter N is used for a transfer protocol, another protocol must
be specified that is equivalent to "None".
Whether to Require 8 Bit -- By putting "8" in this parameter, the SysOp is
specifying that the protocol requires the caller to be able to send or
receive 8 data bits. If 8 data bits is required and the caller is not at 8
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS Page 20-3
bit, RBBS-PC will prompt the caller to change to 8 bit in order to use the
protocol.
Whether A Reliable Connection Is Required -- By putting "R" in this
parameter, the SysOp is specifying that the protocol will not be shown or
made available to the caller unless the connection is reliable (i.e. such
as Microcom's MNP protocol that is built into many modems).
Whether Batch is supported -- By putting "B" in this parameter, the SysOp
is indicating that "batch" file transfers are allowed with the protocol.
"Batch" means a multi-file download request will be processed together.
RBBS-PC enters an external protocol only once to do multiple file
downloads. RBBS-PC has been tested with such "batch" protocols as Omen
Technologies' DSZ Zmodem, Megalink, and Sealink.
Blocksize -- This parameter indicates the number of bytes in each block
transferred. This is only used to inform the caller of the number of
blocks to expect when downloading. A zero in this parameters will cause
RBBS-PC to report only the number of bytes to expect. For Xmodem or
XmodemCRC this value would be 128. For Ymodem this value would be 1024.
Indicate Transfers Always Successful -- If there is no way for the protocol
to inform RBBS-PC if a transfer was successful, put a "F" in this
parameter, which stands for "Fake" a success report. This means that all
transfers will be regarded as successful.
Zmodem (DSZ) used in a multi-tasking DOS environment (where the DOS
environment variables are shared) and CLINK are examples of protocols that
require this to be set.
Factor to Estimate File Transfer Time -- This is the decimal number used by
RBBS-PC to estimate the elapse time to download a file. The higher the
number, the faster the protocol and the lower the time estimate. Standard
equivalents in RBBS-PC are:
Ascii ......... 0.92
Xmodem ........ 0.78
XmodemCRC ..... 0.78
Kermit ........ 0.78
Ymodem ........ 0.87
Imodem ........ 0.90
YmodemG ....... 0.95
Windowed xmodem 0.78
If no value is specified, a default of 0.87 will be used.
RBBS-PC "Macro" to Invoke Before Protocol -- This is the RBBS-PC "macro"
(i.e. a series of standard RBBS-PC commands) to invoke before invoking the
protocol. It can be used to display special messages, to delay the start
of the protocol, or to prompt for special information passed to the
protocol.
Method for Checking Transfer's Success -- This is required only for
external protocols. This parameter indicates how RBBS-PC is to detect a
file transfer's failure. The format is "x=y=z" where:
x is which parameter tells whether the transfer was successful,
y is the string which indicates failure, and
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 20-4
z is an optional parameter telling RBBS-PC whether to write out
information needed when DOORing to a protocol in advance of the
file exchange.
For QMXFER.EXE from John Friel and the Forbin Project, this would be "4=F"
- meaning the 4th parameter indicates failure if it begins with "F".
For Zmodem as implemented in DSZ from Omen Technologies, the proper choice
depends on whether SHELLing or DOORing is used. For SHELLing, put in
"1=E" to indicate that the first parameter uses "E" to indicate an error
has occurred. For DOORing, put in "4=E=A" to indicate that the fourth
parameter uses "E" when an error has occurred. The "=A" means that RBBS-PC
is to do an advance write of the filename and protocol used. DSZ then
appends its error report to the log file. To the file "XFER-" plus node #
plus ".DEF" RBBS-PC will write out a line containing "<filename>,,<protocol
letter>". Omitting an "=" causes a default to "4=F". The file checked is
"XFER-" plus the node number plus the extension "DEF". On node 1 the file
checked is "XFER-1.DEF".
Template to Use for Downloading -- This is required only for external
protocols. It tells RBBS-PC how to invoke a download. See section 20.2.
Template to Use for Uploading -- This is required only for external
protocols. It tells RBBS-PC how to invoke an upload.
20.2 Calling external protocols using "templates"
-------------------------------------------------
A "template" is used to inform RBBS-PC how to invoke an external protocol.
The first word of the template must be the file name (including file
extension) of the program to invoke. RBBS-PC will check to make sure that
the file exists. If the file does not exist, the protocol will not be made
available to the caller.
RBBS-PC will dynamically substitute values for pre-defined strings inside a
"template". Each supported string is enclosed in square brackets. The
strings supported include:
[n] where n is a positive integer. Substitutes value in a work array
Macros can store the prompted values in specific elements in the
array.
[FILE] Name of the file (FILE.NAME$) to be transferred.
[BAUD] Speed at which the PC talks to the modem. Can be much higher
than the modem-to-modem speed, but requires proper flow control
so that characters are not lost.
[CBAUD] Speed between the modems. Carrier speed. The limiting factor
on the speed of transmission, so used to estimate download times.
[PARITY] Parity used by the caller.
[PORT] DOS device name for the communications port to be used for the
file transfer (COM1,COM2, etc.).
[PORT#] Number of the communications port to be used for the file
transfer (1,2,3, etc.).
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS Page 20-5
[NODE] Number of the RBBS-PC node invoking the file transfer (1,2,3,
etc.).
[PROTO] Letter of the protocol for the file transfer.
Everything else in a template will be passed intact. If the external file
transfer is to be invoked via a SHELL, it is recommended that the external
file transfer program be SHELLed to directly. If the external file
transfer is to be invoked via a DOOR, it can be either
1) DOORed to directly using the same template as for SHELLing, or
2) DOORed to indirectly via a .BAT file with the command parameters
passed to it by RBBS-PC. For example, a "door" for QMXFER might have
a download template of:
"RBBSQM.BAT [FILE] [PORT] [BAUD] [PROTO]"
and the file RBBSQM.BAT have the following in it:
C:QMXFER.COM -s -f %1 -l %2 -c -b %3 -p %4
DOS substitutes the passed parameters for the variables beginning with the
percent sign. .BAT files are needed if additional programs are to be run
before or after the actual file transfer.
The following examples should provide some help in understanding how to
invoke external protocols:
Example #1:
Z)ippy,5,S,8,,,,,0.98,,,"c:\utl\zippy -s [FILE]","c:\utl\zippy -r [FILE]"
Can be interpreted to be:
used "Z" as invoking letter,
put "Z)ippy" in the prompt,
the minimum security to use this protocol is 5,
the protocol will be invoked via a SHELL command,
an 8-bit connection is required,
estimate the download time as 0.98 times as fast as normal,
use normal RBBS-PC type of report to check for a successful transfer,
invoke the protocol for downloads using the following string:
"c:\utl\zippy -s [FILE]"
and invoke the protocol for uploads using the following string:
"c:\utl\zmodem -r [FILE]"
where the file name is substituted for "[FILE]" in either case.
Example #2:
X)modem,5,IX,8,,,128,,0.8,,,,
Can be interpreted to be:
used "X" as invoking letter,
put "X)modem" in the prompt,
the minimum security to use this protocol is 5,
the protocol is an internal RBBS-PC protocol,
an 8-bit connection is required, and
estimate the download time as 0.8 times as fast as normal.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 20-6
20.3 Parameters Returned by a Protocol Driver
---------------------------------------------
All protocol drivers are expected to return information about the file
transfer in a file named XFER-xx.DEF where the value for xx is the node ID
(1 to 36). If the protocol cannot accommodate this minimal requirement, it
can still be used by telling RBBS-PC to indicate file transfers are always
successful -- section 20.1, parameter 8.
The one item of information RBBS-PC requires to be returned from an
external protocol drive is whether or not the file transfer was successful.
The failure indicator MUST BE the first character of any specified
parameter in the file XFER-xx.DEF. To show that file transfer failures are
indicated by the first parameter and the letter "E" in the file
XFER-xx.DEF, parameter 11 (as described in section 20.1) would be written
as "1=E". To show that file transfer failures are indicated by the fourth
parameter and the letter "F", parameter 11 (as described in section 20.1)
would be written as "4=F".
No other information is required when SHELLing to external file transfer
protocols. However, when DOORing to external file transfer protocols the
log file for the transfer MUST HAVE the file name as the first parameter.
Protocol drivers that do not have the file name as the first parameter can
still be used by telling RBBS-PC to write out three parameters (file name,
an empty parameter, and the letter of the file transfer protocol) before
invoking the external file protocol. This is done by using parameter 11
(as described in section 20.1). As an example, to DOOR to an external file
transfer protocol that indicates a file transfer failure by using the
letter "F" in the fourth parameter, but which does not return the file name
used, parameter 11 (as described in section 20.1) would be written as
"4=F=A". The external protocol would then append its own information to
the log file.
20.4 The Protocol Drivers Tested With RBBS-PC
---------------------------------------------
RBBS-PC has been tested with the following protocol drivers:
CLINK From System Enhancement Associates. Supports batch file
transfers, but requires that transfers always be assumed
successful.
DSZ From Omen Technologies. Supports Ymodem, Ymodem Batch, YmodemG,
and Zmodem. YmodemG requires a "reliable" connection. DSZ logs
the results of the file transfers to a file specified in the
environment variable DSZLOG. Therefore, the AUTOEXEC.BAT file
for an RBBS-PC that uses DSZ should specify
"SET DSZLOG=XFER-x.DEF"
where x is the node number. DSZ seems unable to create a log
file whenever a drive or path is specified. If invoking ZMODEM
via the DOOR mechanism, use the "=A" option at the end of the
success method check so that RBBS-PC will append the information
to the DSZ log it needs and DSZ will then append the success
report. In a multi-user environment where a different
environment variable for each node can not be specified (i.e. all
nodes must share the same DSZ log file), specify that all
transfers are always successful for protocols handled via DSZ.
RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS Page 20-7
MLINK MEGALINK protocol supports batch file transfers but requires that
transfers always be assumed successful.
PC-KERMIT from Columbia University. PCKERMIT.EXE is supplied by The Source
as a public service and consists of sliding window KERMIT
protocol. The development of "windowing" within the KERMIT
architecture (i.e. Super KERMIT) was funded by The Source and
implemented by Larry Jordan and Jan van der Eijk.
Columbia University holds the copyright and maintains the Kermit
protocol. Like RBBS-PC, Columbia University allows KERMIT to be
passed along to others and "ask only that profit not be your
goal, credit be given where it is due, and that new material be
sent back to us so that we can maintain a definitive and
comprehensive set of KERMIT implementations".
PCKERMIT.EXE is not a terminal program. It simply implements the
Kermit protocol, including the sliding window extension. It will
work with older "Kermit Classic" implementations as well, via
automatic negotiation between the two Kermit programs.
PCKERMIT.EXE runs as a "one-shot" execution then returns to
RBBS-PC. PCKERMIT does not establish a carrier with a remote
system. The connection is established by RBBS-PC. File
transfers must always be assumed successful.
QMXFER is supplied by The Forbin Project. It supports XMODEM
(checksum), XMODEM (CRC), YMODEM, YMODEMG, and IMODEM. YMODEMG
and IMODEM are designed to work when the link between the two
modems is "error free" (i.e. both modems have the MNP protocol
built in). QMXFER.COM runs as a "one-shot" execution, then
returns to RBBS-PC. QMXFER does not establish a carrier with a
remote system. The connection is established by RBBS-PC. File
transfer failures are indicated by an "F" in the fourth parameter
of the log file returned to RBBS-PC.
WXMODEM is supplied by The Forbin Project, and supports the window XMODEM
protocol designed by Pete Boswell. Like all of RBBS-PC's
protocol drivers, WXMODEM.COM runs as a "one-shot" execution then
returns to RBBS-PC. WXMODEM does not establish a carrier with a
remote system. The connection is established by RBBS-PC. File
transfer failures are indicated by an "F" in the fourth parameter
of the log file returned to RBBS-PC.
Other protocols tested with RBBS-PC include SuperK, Jmodem and Puma.
GOING MULTI-NODE Page 21-1
21. GOING MULTI-NODE
--------------------
The amount of traffic, or calls, that a BBS can process, are limited by the
number of simultaneous callers that be had. Each caller requires a
dedicated, separate phone line and communications port, and has to run its
own, separate copy of RBBS-PC. SysOps sometimes make the mistake of
investigating considerable money and resources into a multi-node BBS before
they have established a demand for such a service. Rather than install
too many nodes, it is much better to begin slowly and to have an upgrade
strategy for adding more nodes once the BBS gets so busy that many callers
who want to get on encounter a busy signal.
Before you consider running multiple nodes to allow more than one caller on
your BBS at a time, you should already have RBBS-PC working well on one
node. If you don't have your board running smoothly with NO crashes, STOP
right here and concentrate on your single-node system. You will only
compound your errors and frustrate yourself if you try to get RBBS-PC
operating on multiple nodes before you get it operating well on one node.
21.1 The Basic Strategies
-------------------------
There are four basic strategies for providing multi-node operation on a
BBS.
o networking
PC's are connected together using a network card, cabling, and networking
software so that hard disk and files can be "shared" or accessed by all the
PC's on the network. This is called a "local area network" or LAN.
Example: LANTASTIC.
o slave cards
A PC, with communications ports, memory, and a CPU is put on a "card" which
goes into an expansion slot on a "host" computer. The slaves share the
hard disk of the host and each one runs a copy of the BBS software.
Example: Alloy PC-16 slave cards.
o operating system multi-tasking
Software is installed on a single PC that enables it to run, at the same
time, any application that would normally run, only at the same time. The
CPU is rapidly "task switched" between all the applications that are
running. To run multi-node, you just "open" up a new task to run another
copy of the BBS software. Example: Desqview.
o application multi-tasking
Here the BBS software itself manages and runs multiple sessions on multiple
communications ports. Hence the BBS software can never terminate. RBBS-
PC is only "single-threaded" and does not support this option. An example
of good commercial software that does do this is TBBS.
All strategies requires a communications port, modem, and phone line for
each node. Each option has advantages and disadvantages. Fortunately,
the most inexpensive option is also well supported and works well. For
about $100, Desqview can be added on top of DOS. Each task you add under
Desqview requires extra system memory, and the more tasks you run, the more
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 21-2
powerful a processor your need. Figure at least 1 meg of memory for
Desqview, the at least 500K for each application. Then, with a 80286, you
can easily run 2 nodes of RBBS-PC, with an 80386 4 nodes, and with an 80486
8 nodes. For details, see the appendix on Desqview.
Desqview can also be combined with networking, though getting all the
software to work properly together can be a struggle. For example, you
might have two PC's linked together using LANTASTIC, each running 4 nodes
under Desqview.
Slave cards have the advantage that each added node has its dedicated CPU,
and so there is little or no degradation in speed when additional nodes are
added. Also, the software to run slaves is extremely easy to set up
compared to networks. Since each slave takes a slot on the bus, you will
run out of slots, or have to buy an "expansion bus" where each slot costs
about $100. Also, at a cost of about $700 per slave, this option is more
expensive.
If you already own many PC's, especially older "obsolete" ones like an
8088, putting them to use to run BBS's can be both productive and
economical. All you would have to do is to add networking cards and
software. Networks also have the advantage that you can add hard disks
and CD-Roms on different machines, to be shared across the network.
Generally, you would make your fastest machines "servers" for the network.
21.2 How to Set up RBBS-PC for Multi-Node Operation
---------------------------------------------------
When configuring a multi-node RBBS-PC, you may have to make a decision of
SPEED vs. STORAGE. In a LAN environment, accessing data stored on another
machine is slow. Therefore, you may want to keep copies of ALL text files
on each machine, and ONLY share those files that are mandatory (MESSAGE,
USER, UPLOAD dirs). However, to do this you will have to keep nearly ALL
RBBS-PC files updated on EACH RBBS-PC machine. This can waste storage,
increase maintenance hassles, but it does greatly improve performance on a
LAN. Other single-machine environments (such as DESQview, PC-Slaves) do
not require you to make this choice.
To make multi-node operation easier, you may want to put all "node-
specific" files in separate directories (i.e. C:\RBBS\NODE1, C:\RBBS\NODE2,
etc.). This will reduce the chances of having one node overwrite a file
from another node. The following example assumes you have created a NODE
subdirectory for each node on your system.
There are certain parameters in the CONFIG utility which you will want to
consider adjusting in order to facilitate your multi-node RBBS-PC.
To begin with, you will need to make an CONFIG .DEF description file for
each node. Copy the file RBBS-PC.DEF to RBBSnPC.DEF, where "n" is the
number for the node (e.g. RBBS1PC.DEF, RBBS2PC.DEF, etc.). You will need a
configuration description files for each node, even if it is a "local" node
without a modem.
When you start the CONFIG utility, you can either specify the configuration
description file name after the CONFIG program name on the command line
(e.g. CONFIG RBBS1PC.DEF), or you can let CONFIG ask you whether you will
be running multiple RBBS-PCs, answer the question with "Y", and then
specify the number of the node you wish to edit (answering "1" at this
point would then edit RBBS1PC.DEF).
GOING MULTI-NODE Page 21-3
The CONFIG parameters that you will probably want to change in your multi-
node system are as follows:
161 Maximum number of concurrent RBBS-PC's. Set this to the maximum
number of nodes you will ever run. Remember that you need to allocate
space for your local nodes, also. This causes more space to be
allocated in the MESSAGE files. You can change this number at any
time, and CONFIG will create the needed room, however the only harm in
allocating EXTRA nodes is 128 bytes of wasted disk space per node.
162 Environment running multiple copies. Select whichever network type
describes the environment you are running. If you have some doubt as
to which type fits your network, select NETBIOS (DOS SHARE). NETBIOS
is a fairly universal network interface for applications software, and
most LAN products offer support for it.
88 System file for recording comments. You can set a different comments
file for each node you are running (NODE1\COMMENTS and NODE2\COMMENTS,
for example), but RBBS-PC can allow a single, shared comments file in
all but the CORVUS network.
90 Caller log files. RBBS-PC does NOT share log files between nodes.
Each node must have a separate log file (NODE1\CALLERS, etc). If all
nodes write to the same callers file, you will not be able to figure
out which node did what!
93 File controlling scan for mail waiting. If, for some reason, you want
to have some conferences or sub-boards visible on only one of your
nodes, you have the option of creating separate conference mail
control files (e.g. NODE1\CONFMAIL.DEF, NODE2\CONFMAIL.DEF, etc.)
This is certainly not required, however, and most installations will
run with identical conference mail control files.
100 File built dynamically to open a door. RBBS-PC creates an batch file
for each node when dooring. This batch file must be unique for the
node. Name yours NODEn\RCTTY.BAT, where "n" represents the node you
are configuring currently.
104 The .BAT file to re-invoke RBBS-PC. If you do not make your RBBS.BAT
file read-only, you might have problems when several nodes attempt to
access it at the same time. In most cases, this can be avoided by
marking the .BAT file "READ ONLY," but you may have to have a unique
BAT file for each node of RBBS-PC (e.g. RBBS1.BAT, RBBS2.BAT, etc.)
204 Drives available for downloading. Make certain to list not only the
drives from the computer local to the node, but also the network drive
letters. We recommend using the DOS SUBST command to make the
references to local drives match those that the remote machine refers
to them as. For example, if the remote machine refers to your drive
C: as drive W:, then use the DOS SUBST command and refer to it locally
as drive W:, also. It will reduce confusion for you to only refer to
a drive by one name. Remember, you can have up to 15 letters, no
more.
Now save these CONFIG parameters, and you will have a "network ready"
configuration description file. You can copy this .DEF file for the other
nodes, and then change the node-specific parameters for each. Remember,
each node gets its OWN file!
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 21-4
Remember also that each node is likely to have a different modem. Not in
ALL cases, obviously, but it justifies a reminder here. Let's take a
typical example. On one node, you are using a Hayes 2400 compatible modem,
and on the other a US Robotics Courier HST. Obviously, the setup is
greatly different between these two. It's not a problem with RBBS-PC,
however. When you have CONFIG loaded and are editing the node's
configuration description files just remember to put the proper information
FOR THAT NODE into CONFIG parameters 221 (Comm port), 225 (Modem settings)
and 231 (Firmware initialization). Each node can have a different modem,
use a different COM port, run at different speeds, or even use a FOSSIL
driver or not, and RBBS-PC can easily adjust to it.
AUTOEXEC.BAT
In the AUTOEXEC.BAT file for each node, you will want to add the following
environment variables.
SET NODE=n (where "n" is the node number)
SET DSZLOG=XFER-%node%.DEF
There may be other variables also required by your individual setup, but
the RBBS.BAT file expects to find the %node% variable, and some external
file transfer protocol drivers (DSZ, especially) will use the DSZLOG file
to pass success-or-fail back to RBBS-PC. You need a separate one built for
each node, and this will take care of it.
SUB-BOARDS
If you have sub-boards set up, you will create a configuration description
file for each sub-board. However, the configuration description file will
not have a node number in its title. The configuration description file
name will take the form "xxxxxxxC.DEF", where "xxxxxxx" is the 1-7
character sub-board name. For example, a sub-board named GAMES would have
a configuration description file named GAMESC.DEF. This is a major
difference from the configuration description file for the nodes
themselves. Each node has its own file, because each node is completely
different (usually). But with a sub-board, parameters about the modem,
etc., are not needed. Therefore, there is only ONE configuration
description file for each sub-board.
RBBS-PC will search for a conference .DEF file in THREE places (and in the
following order):3
- The default drive/path (when RBBS-PC starts)
- The location of the CURRENT message base (the one active when the JOIN
command is used).
- Where the CONFERENCE menu file is stored (see CONFIG parameter 74).
Here's an important tip to help with sub-boards functioning on multiple
nodes. CONFIG parameter 90 controls the system callers file. Select this
parameter, and when CONFIG asks you if you want to have a callers file,
answer "N". This will cause the sub-board to use the same callers file
that the node is currently using. Since you only have one configuration
description for each sub-board, specifying a callers file in the sub-board
configuration description file would cause information from both nodes to
be written to the same callers file, and this would be mass confusion.
DOORS
GOING MULTI-NODE Page 21-5
Many door programs (especially older ones) are simply not network
compatible. Some of the doors that you have been running for years will
suddenly not work in a network. Each door is an individual case. Some
doors are hard-coded to pick up DORINFO1.DEF and cannot be made to read
DORINFO2.DEF. Others are locked into COM1 and cannot be forced over to
COM2. And still others force you to have DORINFO1.DEF in a directory
called "C:\RBBS" and will refuse to look anywhere else for the possibility
of a second node's files.
When you have a door which is network compatible, usually the documentation
that accompanies the program will explain in detail how to install the door
on your BBS. In general, a door program is installed in one location on
the network, and all nodes will run the door from that subdirectory.
RBBS-PC will create a DORINFOn.DEF, where "n" is the node number, when it
exits to a door. Almost all door programs want to know where this file is,
and a variety of options are available to you. One option often used is to
set an environment variable to the drive letter that will be the default
drive for a specific node.
For example, let's say that our Node 1 system runs from W:\RBBS, and our
Node 2 system runs from Y:\RBBS. If we set an environment variable in each
node's AUTOEXEC.BAT file called RBBS (e.g. SET RBBS=W:), then we can refer
to the location of the DORINFOn.DEF file as:
"%rbbs%\RBBS\DORINFO%node%.DEF".
(Notice the use of the %node% environment variable, also.) In this way,
each node running the door will substitute the proper drive and node number
to the door.
MISCELLANEOUS TRICKS
RBBS-PC is written to share resources with no conflict between nodes. For
example, both nodes will access the same message and user files, and at the
same time. Under ordinary DOS circumstances, this would cause a "sharing
violation" error. RBBS-PC, however, accesses files in "shared mode", which
eliminates this error. There are still times, however, when files are
accessed outside the direct control of RBBS-PC. To eliminate the
possibility of sharing violation errors at these times also, we recommend
marking all your TEXT, .COM, .EXE, and .BAT files "read only". (The read
only attribute lets DOS know that it's okay for more than one process to
access this file at the same time, because NEITHER process will be able to
modify it.)
To change a file's attribute, you will use the DOS utility ATTRIB. The
command syntax is "ATTRIB +R filespec", where filespec can be anything up
to and including "*.*". Conversely, "ATTRIB -R filespec" will remove the
read only attribute so that the file may be changed.
If you are operating your multi-node RBBS-PC with two separate RBBS-PC
subdirectories (i.e. all files duplicated in a second location except those
which MUST be shared), then this precaution is not needed. If, on the
other hand, you are operating your multi-node RBBS-PC with a SINGLE RBBS-PC
subdirectory, then we recommend making all files read-only which will not
be written to by RBBS-PC.
Files which will be written to are the callers files, the user files, the
message files and the upload directory. Since these are only opened from
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 21-6
within the RBBS-PC program, you will not have sharing problems here.
(Note: Some door programs require access to these dynamic files, and do
not support shared access. This can cause the door program to malfunction.
This would be considered a door program which is NOT "network-able".)
21.3 How to Add Multiple Communications Ports
---------------------------------------------
One of the long standing scandals of DOS as an operating system is that it
only supports 2 communications ports, known as COM1 and COM2. These
standardized ports are well supported, but once you want more than two, the
operating system fails to provide the needed standards, and so applications
requiring more do everything their own way and are not interchangeable.
Through its fossil driver, RBBS-PC supports up to 8 com ports, but finding
hardware everything will work with is a greater challenge.
COM3 and COM4 are semi-standardized. What you need is a two port com
board that supports two features:
o each com port can be configured to be com1 thru com4
o the board can be assigned an interrupt, preferably interrupts 4 at
least 11. Ideally, each comm port can be assigned a separate
interrupt.
Configuring a com port generally means setting switches or jumpers on the
board. Also, the comm port should preferably have an advanced UART chip.
The old 8250 is acceptable, but far preferable is the newer 16550 AN or
16650 AFN. Generally, avoid the 16450 UART. The chip should be the big
rectangular one on the board. Suitable 2 port com boards from the Far
East can be purchased for no more than $20.
If you want to go beyond 4 nodes on a single machine, your choices are
narrower and more expensive. RBBS-PC's fossil driver has been
successfully set up with the DigiBoard Digichannel PC/8, under Desqview, as
follows. Information on this setup was provided by Ken Royer.
**** You must have at least 4 meg RAM to use this configuration ****
Software required:
a) Desqview 386
b) Fossil driver X00.SYS version 1.22 or higher
c) RBBS-PC version 17.3a or higher
1. The configuration I use requires the DigiBoard Digichannel PC/8.
Before installing the DigiBoard you must adjust the Dip-Switches (DS) and
Jumpers so you system can locate all ports. On the DigiBoard there are 9
Dip-Switches referred to as DS# (# indicating the Dip-Switch number). Set
your DS's as follows:
Set DS1 to 140h as shown:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 21-2
(2 & 4 off)
Status port 1 2 3 4 5 6 7 8 9 10
address
x x
OFF
Set DS2 to 100h as shown:
(2 off)
Com port 1 1 2 3 4 5 6 7 8
x
OFF
Set DS3 to 108h as shown:
(2 & 7 off)
Com port 2 1 2 3 4 5 6 7 8
x x
OFF
Set DS4 to 110h as shown:
(2 & 6 off)
Com port 3 1 2 3 4 5 6 7 8
x x
OFF
Set DS5 to 118h as shown:
(2,6 & 7 off)
Com port 4 1 2 3 4 5 6 7 8
x x x
OFF
Set DS6 to 120h as shown:
UPLOADED FILE TIPS (2 & 4 off)
Com port 5 1 2 3 4 5 6 7 8
x x
OFF
Set DS7 to 128h as shown:
(2,5 & 7 off)
Com port 6 1 2 3 4 5 6 7 8
x x x
OFF
Set DS8 to 130h as shown:
(2,5 & 6 off)
Com port 7 1 2 3 4 5 6 7 8
x x x
OFF
Set DS9 to 178h as shown:
(2,4,5,6 & 7 off)
Com port 8 1 2 3 4 5 6 7 8
x x x x x
OFF
************ Important **************
Switch 8 is to turn the port on or off so if switch 8 is off then the port
does not work. Also, a lot of problems occurred when using port 8 (DS9)
because of address conflicts. Most of my problems were while using port
address 138h. I have set the address for this setup at 178h so no problems
should occur. If you still have problems bringing up the board, try
shutting down port 8 (DS9) by switching the 8th switch off. This should
work.
You must now set the jumpers J85-J90 to determine the IRQ settings. For
this setting you should have J85 & J90 jumpered for the settings of IRQ 3
and IRQ 2. These jumpers are explained in the DigiBoard manual.
Now select the ODD interrupts by setting jumpers J1-J8 on pins 1 & 2.
Jumper J9 & J10 on pins 2 & 3. It should look like this:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 21-4
J1 J3 J5 J7 J9
I I I I I I I I
. . . . . . . . I I
J2 J4 J6 J8 J10
The DigiBoard is now ready for installation. Place the board into an
available slot on your system and configure your system software (If
necessary). Your system software configuration should reflect IRQ 3 with
the same addresses as shown above.
2. Once you have installed the DigiBoard, you are ready to install
Desqview 386. This software comes with QEMM follow the steps in the
Desqview manuals to install this software.
a) After installation, add 8 windows ( one for each node of RBBS).
The following is how each setting should be to work with this setup:
Add a Program
---------------------------------------------------------------------
Program Name..........: [NODE-1]
Keys to Use on Open Menu: N1 Memory Size (in K): 450
Program...: Start Please note that Memory Size above may
need to be increased if you intend to
Parameters: 1 (node #) SHELL (rather than DOOR) to External
file transfer protocols.
Directory.: C:\RBBS\Node1
Options:
Writes text directly to screen.......: [Y]
Displays graphics information........: [N]
Virtualize text/graphics (Y,N,T).....: [Y]
Uses serial ports (Y,N,1,2)..........: [N]
Requires floppy diskette.............: [N]
---------------------------------------------------------------------
Next, press F1 for the Advanced Options menu.
Change a Program Advanced Options
---------------------------------------------------------------------
System Memory (in K) ......: 0 Maximum Program Memory Size (in K).:__
Script Buffer Size.........: 1 Maximum Expanded Memory Size (in K):__
Text Pages: 1 Graphics Pages: 0 Initial Mode:__ Interrupts: 00 of FF
Window Position:
Maximum Height: 25 Starting Height: __ Starting Row...:__
Maximum Width.: 80 Starting Width.: __ Starting Column:__
Shared Program
Pathname...:________________________________________
Data.......:________________________________________
UPLOADED FILE TIPS Close on exit (Y,N,blank......:[N] Uses its own
colors.............:[Y]
Allow Close Window command....:[Y] Runs in Background
(Y,N,blank)..:[Y]
Uses math coprocessor.........:[Y] Keyboard conflict
(0-F).........:[0]
Share CPU when foreground.....:[Y] Share EGA when
Foreground/Zoomed:[Y]
Can be swapped out (Y,N,blank):[N] Protection level
(0-3)..........:[0]
------------------------------------------------------------------------
****** Note that the Program Name, Parameters and Directory will
change with each node setting.
3. Now create a directory called "driver" and place all X00.sys files into
it.
4. You are almost ready to start RBBS-PC, the following are copies of the
Config.sys and Autoexec.bat files needed to support this configuration.
*********** Config.Sys file ***********
DEVICE=C:\QEMM\QEMM386.SYS MAPS=10 RAM ROM SORT:Y
SHELL = C:\DOS\COMMAND.COM /P/E:241
DEVICE = C:\driver\x00.sys E T=2048 R=2048 0=100,IRQ3 1=108,IRQ3 2=110,IRQ3
3=118,IRQ3 4=120,IRQ3 5=128,IRQ3 6=130,IRQ3 7=178,IRQ3
BUFFERS = 30/X
STACKS = 0,0
BREAK = ON
FILES=20
************ Autoexec.Bat file ************
ECHO OFF
PATH=C:\DOS;C:\DV;C:\QEMM;C:\ZIP
cd\qemm
loadhi buffers +10
loadhi files +20
c:\qemm\loadhi /r:3 dvansi
cd\
IF %NODE%. == . SET NODE=1
SET DSZLOG=XFER-%NODE%.DEF
xu dv
SET PROMPT=$P$G
SET TEMP=C:\DOS
cls
c:\dv\xdv
5. If you have followed the above instructions all that is left to do is
configure RBBS-PC with 8 nodes. Once that is completed your system is
ready to go.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 22-6UPLOADED FILE TIPSPage 22-6
22. UPLOADED FILE TIPS
----------------------
Every SysOp should assume that any file uploaded to him that can be
executed (i.e. .BAS, .COM, .EXE) has the capability of destroying all the
files available to the PC it is executed on. This may be because the
documentation is in error, the program was executed incorrectly, or the
program was designed to be malicious. It behooves every SysOp to know what
every uploaded file does in order to protect not only the RBBS-PC system,
but its users.
DUE WARNING AND SYSOP'S LEGAL LIABILITY Page 23-1
23. DUE WARNING AND SYSOP'S LEGAL LIABILITY
-------------------------------------------
While no definitive case-law or legislation exists defining the liabilities
of System Operators, every SysOp should assume that they are as responsible
for their own actions when running an electronic bulletin board system as
they would be for any other action as a citizen of the United States who
chooses to exercise their right to freedom of speech. One of the unique
features of RBBS-PC is that users have to OVERTLY register themselves --
even when the RBBS-PC is "open" to the general public. This gives each
SysOp the opportunity to give every user "due notice" and require each user
to actively acknowledge such notice. Every SysOp should consider the legal
issues, and provide proper notice to all callers.
COMPILING AND LINKING RBBS-PC Page 24-1
24. COMPILING AND LINKING RBBS-PC
---------------------------------
RBBS-PC source code is distributed along with the executable program RBBS-
PC.EXE. It is NOT necessary to recompile or re-link RBBS-PC in order to
utilize RBBS-PC. This section is intended for those hardy few who choose
to modify the source and recompile it. Remember only what is distributed
is supported -- anything else is strictly yours to debug!
RBBS-PC's source code is compilable by the Microsoft QuickBASIC Compiler,
version 2.01 and higher. However Microsoft's QuickBASIC Compiler version
3.0 is the compiler used to generate the .EXE files distributed with
RBBS-PC because it appears to be the most reliable. Versions too buggy to
use at all include 1.0, 2.0, and 4.0.
The batch files MAKERBBS.BAT and MAKECNFG.BAT are included with the source
to recompile RBBS-PC and CONFIG respectively. They are designed for use
with QuickBasic 3.0 but instructions for other versions of the compiler are
in them. The DTR patch described in Appendix G should be applied before
you compile RBBS-PC.
LIMITED LICENSE Page 25-1
25. LIMITED LICENSE
-------------------
The RBBS-PC software is copyrighted but A LIMITED LICENSE IS GRANTED and
each user is free to use and share it under the following conditions:
1. You may NOT distribute RBBS-PC in modified form.
2. You may NOT charge a fee for RBBS-PC itself, and
3. You MUST retain all references to the copyright and authors.
Please distribute the original version (or update thereof) of the program.
If you have changes please distribute them using the conventions described
in section 1.4. This is necessary so that future revisions can be easily
added to the system without requiring the entire program.
Please do NOT resequence the program. All revisions will be as files that
replace the base program or update thereof and the existing line numbers
will be referenced when describing new fixes and enhancements.
LIMITED WARRANTY Page 26-1
26. LIMITED WARRANTY
--------------------
The RBBS-PC program is provided "as is" without warranty of any kind,
either expressed or implied, including but not limited to the implied
warranties of merchantability and fitness for a particular purpose. The
entire risk as to the quality and performance of the program is with the
user, and should the program prove defective, the user and not the authors
will assume the entire cost of all necessary remedies. None of the authors
warrant that the functions contained in the program will meet any users'
requirements or that the operation of the program will be uninterrupted or
error-free. In any case, each author's entire liability will be limited to
the total amount of money the individual user paid directly and explicitly
to each author for the use of RBBS-PC.
THE HISTORY BEHIND RBBS-PC Page 27-1
27. THE HISTORY BEHIND RBBS-PC
------------------------------
Electronic bulletin board systems have been around ever since personal
computers existed. The first ones were very primitive and usually
consisted of some posted notices and maybe allowed for on-line messages.
It must be remembered that the IBM PC was only announced in August of 1981
and first became available in October of 1981. Therefore it is not
surprising that the early history of BBS' is associated with non-IBM
personal computers.
The "early history" of bulletin board systems began around 1978 in Chicago
with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was
created by Ward Christensen and Randy Suess -- members of the Chicago Area
Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080
Assembler language (11,000 lines of it) and, like the early versions of
RBBS-PC (i.e. prior to 12.5A), detects the baud rate and the parity of the
user when he first signs on from the three carriage returns that the user
must enter.
About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80
Models I and II called Forum-80.
The earliest BBS was written for the Apple (who else had personal computers
in those days?) called the "Apple Bulletin Board System" (ABBS). It was
written by Craig Vaughn and Bill Blue. They later created another bulletin
board system for the Apple II called the People's Message System (PMS).
Another Apple bulletin board system that came into being was for the Apple
II, II+, and IIE as well as the Franklin Ace and it was called the
CommuniTree. It was written in the FORTH language by Dean Gengle and
several others.
When IBM announced its first personal computer, the IBM PC, in August of
1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a
prototype version written by Russ Lane in IBM's BASIC on David Crane's
Dallas RCP/M\CBBS system. Brad added many fixes and modifications. In the
first half of 1983, many members of the Capital PC Users Group's
Communication Special Interest Group (SIG) such as Larry Jordan, Rich
Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further
enhanced it and added XMODEM file transfer capability until it became known
as RBBS-PC CPC09 in May of 1983. At that time each feature or modification
was identified by a new version number; it still ran only under the BASIC
interpreter; and was both relatively slow (because of the interpreter) and
somewhat unstable (it would normally "crash" at least once each day).
In June of 1983, Tom Mack received a copy of RBBS-PC CPC09 from Rich
Schinnell. Tom's efforts were instrumental in making RBBS-PC what it is
today - the industry-standard PC-based BBS software. Other contributors
have come and gone, but Tom's contribution to RBBS-PC can never be matched.
RBBS-PC's impact has been to open an entirely new medium of communications
between people. Rather than as an end in and of itself, RBBS-PC has come
to serve as a means to an end -- the free exchange of ideas. On a
technical level it is certainly an example that shows "real programmers
can/do program in BASIC." We would like to think that RBBS-PC had
something to do with IBM and Microsoft coming out with new versions of the
BASIC compiler that support communications, sub-routines, local and global
variables, file-locking in a networking environment, etc.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 27-2
RBBS-PC represents a fundamental cornerstone, not just a phase, in what can
be viewed as a "social renaissance." RBBS-PC eliminates those barriers
that had previously inhibited the "exchange" of information within our
society. RBBS-PC provides every personal computer owner with his own
"soap-box" in a national Hyde Park. Previously the channels of
communication had built-in barriers to "exchange"; with RBBS-PC those
barriers begin to cease to exist.
While only the most fanatical RBBS-PC trivia experts may be interested,
here is the chronology:
RBBS-PC Initial Major Enhancements
Version Release
Number Date
10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC
compiler, version 1.0
11.0 08/10/83 RBBS-PC restructured so that all parameters were
external (i.e. in the RBBS-PC.DEF) allowing SysOps who
didn't want to spend the $300 for the BASIC compiler to
tailor RBBS-PC to their taste. CONFIG.BAS was first
written to generate RBBS-PC.DEF.
11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub-routine that
allowed the compiled version of RBBS-PC to determine
the amount of free space available for uploading.
11.2 10/01/83 The error trapping within RBBS-PC was completely re-
written to be more comprehensive.
12.0 10/28/83 Tree-structured file directories and the ability to
detect that RBBS-PC was in a "MultiLink" environment
were incorporated. "MultiLink" is a product of the
Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, 3.0
and 3.1 to be "multi-tasking."
12.1 12/18/83 The ability for a SysOp who signed on remotely to drop
(Versions into DOS was added. Also the "New" command
was added "A" to "F")that allowed users to determine
what new files had been made available since the last
time they were on.
12.2 04/08/84 The security system designed by Ken Goosens was
incorporated.
12.3 11/11/84 Up to nine RBBS-PCs can share the same files in either
a multi-tasking DOS environment (i.e. MultiLink from
the Software Link, Inc.) or in a local area network
environment (i.e. Corvus or Orchid).
12.4 03/10/85 (Version A, A1, B) RBBS-PC's stature in the industry
became recognized when, RBBS-PC was granted a license
by Microcom to incorporate their proprietary MNP
protocol. "RBBS-PC compatibility" became a minimum
criteria for the introduction of products by many
companies. RBBS-PC introduces 300/1200/2400 BAUD
THE HISTORY BEHIND RBBS-PC Page 27-3
support in 12.4A before most such modems were generally
available.
12.5 07/14/85 (Versions A and B). 36 copies of RBBS-PC could share
the same files in a network environment. RBBS-PC
automatically answers the phone and no longer requires
each caller to enter up to 3 carriage returns in order
for RBBS-PC to detect the users baud rate and parity.
Logon to RBBS-PC has been made much more efficient with
the USERS file no longer being searched sequentially
and the MESSAGES file no longer being read three times.
Version 12.5B, released August 25, 1985, WAS THE LAST
VERSION COMPILABLE BY VERSION 1.0 OF THE IBM BASIC
COMPILER!
13.1 12/01/85 IBM BASIC compiler and Microsoft's QuickBASIC Version
1.0 supported. XMODEM with CRC was added as a
file-transfer protocol as well as the ability to
display on the color monitor of the PC running RBBS-PC
the color/graphics that the remote user sees exactly as
he sees them.
14.1 03/16/86 (Versions A, B, C, and D) RBBS-PC's internal structure
was split into two parts - RBBS-BAS for the main-line
source code and logic, and a RBBS-SUB.BAS for commonly
called subroutines. Support for on-line
questionnaires, auto-downloading, and the KERMIT
protocol were also included as well as the option to
utilize assembly language subroutines for better
performance over their BASIC counterparts.
15.1 03/15/87 File Management System for directories added. User
subscription management added. The ability to run as a
local application on a network, configurable command
letters, the ability to use any field or to define a
new field to identify callers, the ability to
individuate callers having the same ID, multiple
uploads on a single command line, new A)nswer and
V)erbose ARC list commands, context sensitive help,
and a new subsystem for software "libraries".
16.1 03/27/88 (Version A) Major enhancements included the addition of
"sub-boards" (i.e. conferences with their own
bulletins, file areas, menus etc.), a programmable user
interface, the capability to have SysOp-written
"sub-menus" for any command, the ability to hang off of
a public data network such as Compuserve's as a "node",
the incorporation of "personal downloads" (i.e. files
only specific individuals could list/download), the
ability to vary the amount of time a user has on the
system by the time of day the user logs on, the
capability of preventing any message (public or
private) from being read until the SysOp has reviewed
it, an enhanced CONFIG utility with many more options,
XMODEM/1K protocol built-in to RBBS-PC's main-line
source code, the ability to automatically add users to
conferences, and support for The Software Link's
MultiLink Version 4.0. Despite all these enhancements,
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 27-4
the BASIC RBBS-PC code was significantly enhanced such
that it only requires 268K to run -- allowing two
copies to run in multi-tasking DOS environments that
have 640K available.
17.1 10/02/88 (Versions A, B, C, and D). Major enhancements were made
in the System Support area, and the support for up to
eight communications ports; built-in interfaces to
external communications drivers such as a FOSSIL
driver; automatic notification of the SysOp when
specific users log on; improved automatic invocation of
other applications based on time of day; and
SysOp-selectable time delays that users must wait
before being able to download or exit to a door.
RBBS-PC's unique programmable user interface (PUI) was
enhanced to support "macros" (i.e. use a single command
to invoke any number of RBBS-PC commands);
SysOp-selectable colors for all prompts and messages
(i.e. "colorization"); caller-selectable "colorization"
for text (i.e. color, bold or normal, highlighting of
text, etc.); and personalized text files (i.e. text
files that can dynamically adapt to include information
unique to each caller). The messaging within RBBS-PC
was enhanced to notify each caller that logs on of the
number of new messages and how many are addressed to
the caller for the conferences to which the caller
belongs. The text editor function for messages was
enhanced to allow any character to be edited. RBBS-
PC's standard "threaded" message search now also scans
the text of the messages for matches. The RBBS-PC file
subsystem was also significantly enhanced to include an
unlimited number of installable protocols; batch
downloading for such protocols that support this (i.e.
Zmodem, Megalink, and Sealink); and control of callers
ability to download based on either the number of
characters or the ratio of the callers downloads to
uploads.
17.2 05/28/89 (Versions A-B). Major enhancements consisted of
increased flexibility in invoking external applications
(i.e. "DOORS"), on-line questionnaires, RBBS-PC command
"macros", the integration (using the enhanced
questionnaires and "macros") of on-line data base
facilities into RBBS-PC, as well as extended support in
RBBS-PC's file system to support ANY file compaction
technique (i.e. .ARC, .ZOO, .ZIP, etc.) -- including
allowing on-line users to list text files that have
been included within a compacted file. RBBS-PC's
"NETMAIL" interface to store and forward messaging
systems (i.e. FIDO MAIL, etc.) was enhanced. Within
the messaging subsystem numerous enhancements were
added including the ability to quote all or part of a
message that the caller was replying to. RBBS- PC's
file subsystem was improved to allow the system to be
configured such that all uploads were automatically
checked/verified (by whatever utility the SysOp wanted
to use). RBBS-PC commitment to the concept of "users
helping users" was demonstrated once again with the
THE HISTORY BEHIND RBBS-PC Page 27-5
incorporation of support for the Computalker and
HEARSAY 1000 speech boards so that seeing-impaired
SysOps could hear (in a meaningful way) the activity
occurring on their RBBS-PC bulletin boards.
17.3 02/11/90 (versions original, A, B and C) Fast File Search:
sub-second file name looks for over 32,000 downloadable
files; up to 10,098 downloadable areas. Variable names
were changed to MicroSoft standard format using upper
and lower case letters only, and no internal dots.
Some 50 bugs were fixed. News facility added.
Universal command stacking. Default extension on file
requests. Enhanced macros and SmartText. Defaults
added for multiple modems. Support for 38,400 baud
through Fossil driver.
17.4 03/22/92 (versions original) Carbon copy for mail. Personal
uploads, with notification on logon. Distribution
lists for mail and uploads. Linked conferences, and
global commands across linked conferences. Bank time.
FMS and personal directories have all the capabilities
of each. File and mail marking. Ability to give
access to the BBS is blocks of total session time.
Changeable city/state. Auto-ansi detect. Full support
for 12,000 and 14,400 baud. Support for
distinguishing modem-to-modem and modem-to-pc speeds.
SysOp can view call callers files from any node.
28. PROPOSED RBBS-PC SYSOP CONFERENCE
-------------------------------------
As the modem community continues to evolve, RBBS-PC must change to meet the
needs of all users. For years, RBBS-PC has survived with file structures
that are "adequate." However, each passing year brings new uses for
RBBS-PC that place demands on the internal structure of the system.
It is time to discuss the future of RBBS-PC. We would like to see
RBBS-PC's future written in the same spirit that RBBS-PC is developed, by
involving the users. If possible, a SysOp conference can coincide with the
internal restructuring of RBBS-PC. Topics can be discussed such as
RBBS-PC's support of netmail, enhanced messaging features, and an enhanced
USER record structure. This conference cannot succeed without your
support. The timing, location, and agenda for such a meeting is left up to
the RBBS-PC community, but may we suggest a winter retreat in Florida? Who
wouldn't mind spending a few days in the sun, and discussing the future of
RBBS-PC at the same time?
If you are interested in participating, write me at the following address:
Doug Azzarito
RBBS-PC SysOp Conference
2399 N.W. 30th Road
Boca Raton, FL 33431-6212
Or call my BBS: (407) 487-3441 or 487-3442.
I would especially like to hear from anyone with experience in organizing a
conference. If you have gone through the process of booking hotels and
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page 27-2
meeting space, or other things I probably won't think of, PLEASE let me
know!
RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD Page 29-1
29. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD
----------------------------------------------------
RBBS-PC'S "Userware" concept is founded on the principle stated in section
1.1 -- "software which is shared becomes better than it was." Relying on
Federal copyright protection, we believe that RBBS-PC's source code can be
distributed without the risk of "loss of ownership" (i.e. it becoming
"public domain"). We believe all software (commercial and non-commercial)
should be distributed as both compiled/executable files and with their
source code. With few exceptions, RBBS-PC's copyrights have never been
violated -- this is due more to the fact that RBBS-PC enthusiasts are
ever-vigilant of RBBS-PC's copyrights rather than due to any lack of
attempts to "sell" RBBS-PC or RBBS-PC look-alikes to the unsuspecting
public.
Incorporating these new features and ideas into each new release of
RBBS-PC, making sure that upward compatibility with earlier version of
RBBS-PC exists, as well as maintaining RBBS-PC's copyright, are all things
that the authors accept the responsibility for. However, it is RBBS-PC's
"support staff" (i.e. all those who enhance RBBS-PC and share such
enhancements) that continues to make RBBS-PC a unique experiment in PC
software.
No one should feel that the possibilities for RBBS-PC have even begun to be
exhausted. In fact, we are absolutely certain that even as this is written
innovative enhancements are being created for RBBS-PC. It is our sincerest
hope that if RBBS-PC continues to succeed within the IBM PC industry in
becoming the "bulletin-board standard," software vendors will begin
examining the reasons for RBBS-PC's success and come to understand that:
- The best form of software support is user support
- The best source for software enhancements are from it's users
- The best software continually adopts itself to users needs
- The best way to minimize software development is to distribute source
code.
Each RBBS-PC system operator has the opportunity to affect what RBBS-PC
becomes in the future. Many already have. RBBS-PC continues to grow and
expand because hundreds (and quite possibly thousands) of SysOps spend the
time and trouble not only to modify RBBS-PC to meet their needs, but also
to share these modifications with others. We do not know of any other
software for the IBM PC that has such a vast number of programmers
supporting it. In section 1.3, we name many such individuals and
acknowledge that there are a lot more! With the structured code that the
new BASIC compilers allow, even more RBBS-PC system operators are invited
to contribute. Take the time! Make the difference!
APPENDIX A -- RBBS-PC Record Formats Page A-1
APPENDICES
APPENDIX A -- RBBS-PC Record Formats
------------------------------------
This appendix is intended to document the record formats of some of the
more significant records used within RBBS-PC. As such, it is intended more
as a "programmers' guide" for those who wish to write RBBS-PC utilities
rather than as "user documentation." No record format is "sacrosanct" and
any of them may be changed in future releases. However such changes are
not made capriciously and, when they are made, are accompanied by some
utility program that will allow the old files to be reformatted into the
new format.
The MESSAGES file contains the messages that have been left on RBBS-PC. It
is a random access file with 128-byte records. The first record of the
MESSAGES file acts as RBBS-PC's "checkpoint" record. The records
immediately following this first record are the RBBS-PC "node" records.
Each "node" record represents the activity/options associated with a
particular copy of RBBS-PC ("node"). There can be up to thirty-six copies
of RBBS-PC running simultaneously, therefore there can be up to thirty-six
"node" records following the "checkpoint" record.
The MESSAGES file has the following logical format:
+----------------------------------------------+
Record #1 | RBBS-PC "checkpoint" record |
+----------------------------------------------+
Record #2 | RBBS-PC "node" record for node # 1 |
| |
| up to |
| |
| RBBS-PC "node" record for node # 9 |
| RBBS-PC "node" record for node # 0 |
| RBBS-PC "node" record for node "A" |
| |
| up to |
| RBBS-PC "node" record for node "Z" |
| |
+----------------------------------------------+
| First Record in Message portion of file |
+----------------------------------------------+
| |
\ Message records that have been used \
\ \
| |
+----------------------------------------------+
| Record available for next message |
+----------------------------------------------+
| Last record available in MESSAGES file |
+----------------------------------------------+
The FIRST RECORD of the "MESSAGES" file acts as a "checkpoint" record for
all the multiple RBBS-PC's that may be sharing the MESSAGES and USERS
files. It contains information critical to maintaining the integrity of
these two files. The layout of RBBS-PC Message File Record Number 1 is
as follows:
Position Length Description
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page A-2
1 - 8 8 Number assigned to the last message entered
9 - 10 2 Security level required to be auto-added to a conference
11 - 20 10 Current caller number
21 - 23 3 Type of message security allowed. "/" means prohibited,
byte 21 controls public, 22 private, 23 password.
Anything other than "/" means permitted.
24 56 33 --- RESERVED FOR FUTURE USE ----
57 - 61 5 Count of the number of USER records used
62 - 67 6 --- RESERVED FOR FUTURE USE ----
68 - 74 7 Record Number where "messages" portion of the
MESSAGES file begins
75 - 81 7 Record Number of the next available record in the
MESSAGES file where the next message may be written
82 - 88 7 Record Number of the last record in the MESSAGES file
89 - 95 7 Maximum number of messages allowed in the MESSAGES file
96 -126 31 --- RESERVED FOR FUTURE USE ----
127 -128 2 Maximum number of RBBS-PC's sharing this MESSAGES file
As a programming reference, line numbers 1900 and 23000 of the BASIC source
code for RBBS-PC.BAS contains the code for reading this "checkpoint"
record.
Following the first record of the MESSAGES file are from one to 36 "node"
records. Each "node" record contains information critical to the
running of that copy of RBBS-PC associated with that "node". The layout of
each RBBS-PC "node" record is as follows:
Position Length Description
1 - 31 31 Name of last person on this copy of RBBS-PC
32 - 33 2 SysOp available indicator (true or false)
34 - 35 2 SysOp annoy indicator (true or false)
36 - 37 2 SysOp is to be on next indicator (true or false)
38 - 39 2 Line printer available indicator (true or false)
40 - 41 2 Door's availability indicator (true or false)
42 - 43 2 Eight bit transmission indicator (true or false)
44 - 45 2 Caller's baud rate indicator: 1 = 300 bps
2 = 450 bps
3 = 1200 bps
4 = 2400 bps
5 = 4800 bps
6 = 7200 bps
7 = 9600 bps
8 = 12000 bps
9 = 14400 bps
10= 16800 bps
11= 19200 bps
12= 38400 bps
46 - 47 2 Upper case only indicator (true or false)
48 - 51 4 Number of bytes transferred (from external protocols)
52 1 Batch transfer indicator (not zero = batch)
53 - 54 2 Graphics indicator (0 = text, 1 = full ASCII, 2 = color)
55 - 56 2 SysOp indicator (-1 = SysOp)
57 1 Activity indicator (I=inactive, A=active)
58 - 59 2 SNOOP on indicator (true or false)
60 - 64 5 Baud that RBBS-PC talks to the modem at (single precision)
65 - 67 3 Time user logged onto the system (HH:MM:SS)
68 - 71 4 --- RESERVED FOR FUTURE USE ---
APPENDIX A -- RBBS-PC Record Formats Page A-3
72 - 73 2 Private door indicator (true or false)
74 1 Type of transfer to external program:
0 = none
1 = download a file
2 = upload a file
3 = external registration program
75 1 First letter of file transfer protocol
76 1 --- RESERVED FOR FUTURE USE ----
77 - 78 2 Last date, MM-DD-YY, that RBBS-PC exited to DOS (packed)
79 - 85 7 --- RESERVED FOR FUTURE USE ----
86 - 90 5 Last time, HH:MM, that RBBS-PC exited to DOS
91 - 92 2 Reliable mode indicator (true or false)
93 - 116 24 Work area that normally contains caller's City and State,
but when temporarily exiting RBBS-PC used as:
Position Length Description
93 -100 8 Programmable user interface file name
101 -102 2 Local user indicator (2 hex 0Ds if local)
103 -104 2 Local user mode (true if using COM0)
105 -112 8 Name of current "conference" or "sub-board"
113 -114 2 Time credits (minutes)
115 -116 2 --- UNUSED ----
117 -118 2 Subsystem index of last subsystem user was in.
119 -124 6 Month, day, and year, MMDDYY, exited to external protocol
125 -128 4 Hour and minute, HHMM, exited to external protocol
As a programming reference and in order to see how these fields are
set/used in the node records, review the following line numbers in RBBS-
PC.BAS -- 150, 200, 400, 420, 842, and 13555. In addition, review the
following subroutines as well:
Source Code Subroutine
RBBSSUB2.BAS ---- WhosOn
RBBSSUB3.BAS ---- FindFKey
SaveProf
ReadProf
RBBSSUB4.BAS ---- TimedOut
A message within the messages file consists of 1-255 MESSAGE HEADERS
followed by the text of the message. The RBBS-PC Message File "message
header" record layout is as follows:
Position Length Description
1 1 Contains an "*" for read-only messages, blank otherwise
2 - 5 4 Message number of this message
6 - 36 31 The name of the person the message is from
37 - 58 22 The name of the person to whom the message is sent
59 - 66 8 Time of day that the message was sent (HH:MM:SS)
67 - 67 1 Number of message headers (1-255). Use ASCII value.
68 - 75 8 Date the message was sent (MM-DD-YY)
76 -100 25 Subject of the message
101 -115 15 Password for the message (if any)
116 -116 1 "Active" message indicator = ASCII 225
"Killed" message indicator = ASCII 226
117 -120 4 Number of 128-byte records for this message --
including the "message header" record.
121 -122 2 Minimum security level to read message
123 -125 3 Date (packed) the message was last read (MM/DD/YY)
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page A-4
126 -128 3 Time (packed) the message was last read (HH:MM:SS)
As a programming reference, review lines 3405, 3460, 3530, and 8076 of the
BASIC source code for RBBS-PC.BAS to see how these fields are set. Each
record following the MESSAGE HEADER records is a MESSAGE TEXT record and
consists of 128 characters. Each of these 128-byte message text" records
contains the message text. The end of each line in the message is followed
by an RBBS-PC "end-of-line" indicator which is equal to an ASCII 227. This
allows RBBS-PC to "pack" multiple message lines in a single 128-byte
record.
Information unique to each person who logs on is contained in the USERS
file (a random file of 128-byte records). Each records is as follows:
Position Length Description
1 - 31 31 Users first and last name (separated by a blank).
32 - 46 15 Users password for logon.
47 - 48 2 Users security level (permanent).
49 - 62 14 Users logon options (see detail breakdown below).
63 - 86 24 City and state from which the user is calling.
87 - 88 2 ---- RESERVED FOR FUTURE USE ----
89 - 89 1 Number of minutes banked. 0 to 255. Use ASCII value.
90 - 93 4 Number of files downloaded today
94 - 97 4 Number of bytes downloaded today
98 -101 4 Number of bytes downloaded (ever).
102 -105 4 Number of bytes uploaded (ever).
106 -119 14 Date and time the user was last on (MM-DD-YY HH:MM).
120 -122 3 Date the user last listed a directory.
123 -124 2 Number of files downloaded (ever).
125 -126 2 Number of files uploaded (ever).
127 -128 2 Elapsed time the user was on for day of last access.
Line 9400 of the BASIC source code for RBBS- PC.BAS contains the code for
opening this file. The user's logon options, positions 49 through 62, are
utilized as follows:
Position Length Description
49 - 50 2 Number of times the user has logged on
51 - 52 2 Last message number read by the user
53 1 Protocol Preference (blank if none, otherwise letter)
54 1 Graphics Preference (see meaning below)
55 - 56 2 Margin length for this users messages
57 - 58 2 Bit Flag -- this 16-bit field is denoted by bit 0 being
the least significant (i.e. right-most bit) and bit 15 being the most
significant (i.e. left-most bit). These "bit flags" have the following
meanings (0=off, 1=on):
BIT Definition (what ON means)
0 Bell prompts
1 "Expert" mode
2 Nulls
3 Upper case only
4 Line feeds
5 Skip old bulletins
6 Check new files on logon
7 Use autodownload
8 Required questionnaire answered
9 Mail Waiting
APPENDIX A -- RBBS-PC Record Formats Page A-5
10 Highlighting enabled
11 "TurboKey" enabled
12 Personal uploads waiting
13-15 RESERVED FOR FUTURE USE
59 - 60 2 Date subscription began
61 1 Page length to use for this users terminal
62 1 ------- RESERVED FOR FUTURE USE ---------
---
14
The meaning of the graphics preference byte depends on the numeric value it
has. The caller can specify, for text files, no graphics, ascii graphics,
or ansi color graphics; then the color, and then whether normal or bold.
For example, if graphics preference for text files is color, and preference
for normal text is light yellow, graphics preference stored is 38. Colors
are Red, Green, Yellow, Blue, Purple, Cyan, and White.
normal bold
graphics\color R G Y B P C W R G Y B P C W
none ...... 30 33 36 39 42 45 48 | 51 54 57 60 63 66 69
ascii ...... 31 34 37 40 43 46 49 | 52 55 58 61 64 67 70
ansi ...... 32 35 38 41 44 47 50 | 53 56 59 62 65 68 71
APPENDIX B -- RBBS-PC Software Registration Page B-1
APPENDIX B -- RBBS-PC Software Registration
-------------------------------------------
Frequent inquires are made asking how many RBBS-PC systems are in
operation, or about a "master" list of RBBS-PC's. Since RBBS-PC is freely
distributed, attempts to get SysOps to register the product have been in
vain. However, in an attempt to help SysOps (and potential SysOps)
everywhere find configurations that most closely match their own, and to
help users find more RBBS-PC systems, we ask that you register your copy of
RBBS-PC. The information you supply will be used to maintain an "ACCURATE"
listing of all publicly available RBBS-PC systems. The success of this
endeavor depends on you. Please complete the BBS info file LG-9999.DEF
supplied with this release of RBBS-PC and send it to:
RBBS-PC SOFTWARE REGISTRATION
P.O. Box 31024
Palm Beach Gardens, FL 33420-1024 U.S.A.
To make sure your registration is current, please remember to send a copy
of your registration form at least once each year. You can also call The
RBBS-PC technical support BBS and upload a copy of the form. An online
database of all respondents will be available on the technical support BBS:
(407) 487-3441 or 487-3442.
If you need a good reason to complete and return the information, read on!
As RBBS-PC continues to evolve, we must make decisions that will affect
you. If we know who you are, and what your environment is like, we are
less likely to introduce a new version of RBBS-PC that will not run in your
environment!
THE BBS IDENTIFICATION STANDARD
-------------------------------
To help BBS list editors, and other users searching for your BBS, we have
started what we hope will be an industry standard. Please implement it on
your BBS. Here's how:
1) Complete the LG-9999.DEF file and place it with your other LGn.DEF
files.
2) Create a user with first name "BBS", Last name "VERIFY", password
"CALL".
3) Set this user's SECURITY to -9999.
Now, any time a BBS list editor calls for a quick check, he'll use the name
BBS VERIFY and a password of CALL. Your BBS will quickly display the
information he needs, and then hang up. Any user who is curious about your
BBS can do the same. If ALL BBS systems implement this, keeping track of
the fast moving BBS community will be much easier. Please, do what you can
to convince other SysOps to implement this simple procedure.
APPENDIX C -- RBBS-PC Subscription Service Page C-1
APPENDIX C -- RBBS-PC Subscription Service
------------------------------------------
It seems that many people absolutely must be on the bleeding edge of
RBBS-PC and demand each new version as soon as possible after it is
released. For them you can order in advance the next release of RBBS-PC.
It will be mailed anywhere by air mail - overnight in the United States,
ordinary air mail elsewhere. The charge for this subscription upgrade is
$25.
Hopefully, this service will only be used by a very, VERY few! Most
releases have a few fixes that get published within the first week or two
that they are out. Because of this everyone is advised to check back for
fixes after each release goes out.
To obtain this service for the NEXT release (it does NOT apply to the
current or previous releases) fill out the following form and send it along
with your check or money order in U.S. funds (no purchase orders are
accepted and your canceled check is your only invoice).
+------------------------------------------------------------------+
| To: Capital PC Software Library RBBS-PC Subscription Service to|
| 51 Monroe Street the NEXT release of RBBS-PC (if|
| Plaza East Two any - and none are implied or |
| Rockville, MD 28050 promised by this offer) |
|------------------------------------------------------------------|
|Date Requested: Date Received: |
|------------------------------------------------------------------|
|To (Recipient's Name): |
|------------------------------------------------------------------|
|Recipient's Phone Number (required): ( ) - |
|------------------------------------------------------------------|
|Exact Street Address (no P.O. Box or P.O. Zip Code accepted) |
| |
| |
|------------------------------------------------------------------|
| City | State or Country |
| | |
|------------------------------------------------------------------|
| Signature (required) | ZIP Code for Street Address |
| | |
+------------------------------------------------------------------+
Note: this is not a promise that there will be any new releases.
APPENDIX D -- Modems with RBBS-PC Page D-1
APPENDIX D -- Modems with RBBS-PC
---------------------------------
Introduction
------------
Modems are often frustrating things to get working properly on a BBS.
Some have hardware switches that must be set. When a SysOp finally gets
his own modem to work with RBBS-PC, he will often share his discoveries.
This appendix is a result of such sharing.
Anchor Signalman Express (MK12)
-------------------------------
The following are the switch and jumper settings for the Modem.
Switch 1 = Off
Switch 2 = Off
Switch 3 = On
Switch 4 = On
Switch 5 = On
Switch 6 = On
Switch 7 = On
Switch 8 = On
Everex Evercom 2400
-------------------
The Everex Evercom 24 is an internal 2400 BAUD modem. It has 4 switches on
the mounting bracket. If you are using COM1 then all switches should be in
the OFF position. If you are using COM2 see the Installation Guide for the
correct switch settings.
The Evercom does not have non-volatile memory like the Hayes 2400 and the
ATZ command will reset the modem to factory defaults. It is therefore not
necessary to use CONFIG to set the Hayes 2400 defaults. Because of this
major difference you must use CONFIG parameter 225 to change the standard
modem defaults. Select parameters 2 and 5 and enter the command just as it
is but with the addition of &D2. This will instruct RBBS-PC to add &D2 to
the standard modem initialization string each time the system recycles.
Please note that although the Evercom 24 manual indicates that &D2 is the
default that this is a misprint in their manual and &D0 is the real default
for the &D command. Parameter 7 can be ignored since they this is for
battery backed up modems only.
NOTE: Make sure that &D2 is inserted immediately following the "AT" when
modifying parameters 2 and 5 of parameter 225!
A special thanks goes to Carl Margolis (Everex) for his help in identifying
these restrictions so that Evercom 24 users can now reliably use RBBS-PC.
Do not select parameter 225 if you are using an Everex 1200 BAUD modem.
FASTCOMM 2496 Turbo Modem
-------------------------
The FASTCOMM 2496 9600 and 19200 baud modems work with RBBS-PC without
modifications to RBBS-PC. However some unusual quirks were noted with the
FASTCOMM hardware. The modems would NOT follow terminal baud rate in the
command mode if the transition was from 300 to 9600 (or 19,200) baud.
Therefore, if RBBS-PC were configured to initially operate at 9600 baud, it
would not properly reset after a 300 baud call. It would, however, follow
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page D-2
all other changes within the range of RBBS-PC. If it was configured to
initially answer at both 2400 and 4800 baud and it worked equally well with
calls at 300, 1200, 2400, 4800, 9600 and 19200 baud for both cases.
Therefore set CONFIG parameter 208 to 2400 baud!
It is recommended that CONFIG parameter 224 be set to answer on one ring!
Specific instructions for modem set up are as follows:
1) Using the BASIC program SETFC.BAS below, set the default modem
settings. This can also be done manually from a communications
program. The speed that is used to establish the default modem
settings is the speed to which the modem defaults on reset and power
on. It is best to do this setup at the same speed that RBBS-PC uses
as its default speed, namely 2400 baud. In any case do not do it at
9600 baud.
2) Tell RBBS-PC to open the modem at 2400 baud by setting CONFIG
parameter 208 to 2400 baud.
3) Use CONFIG parameter 225 to change the modem reset command from "ATZ"
to "AAATZ".
This string of A's resets the modem to the terminal baud rate so it can
respond to the other commands. If you want to experiment, watch the modem
respond to you when you change baud rates in your favorite communications
program. This modem function is referred to as "autobaud". You will
probably not see the first "A" echo and sometimes not the second. You
should always see the third "A". Others have advised that their modems
would "autobaud" from 300 to 9600 baud. Mine would not.
4) Use CONFIG parameter 225 to change the modem answer string to include
X2 instead of X1 (the CONFIG default).
Stan Staten has extensive experience with RBBS-PC and the FASTCOMM 2496
modems. If you have any questions regarding their use with RBBS-PC, give
Stan's RBBS-PC system a call at (301) 869-7650.
The following is STAN's SETFC.BAS program's BASIC source code to set the
FASTCOMM modem. It can be run under the BASIC interpreter or can be
compiled using QuickBASIC from Microsoft. SETFC.EXE and SETFC2.EXE (for
COM2:) can be downloaded from Stan's BBS.
10 'title: 'SETFC.BAS, Copyright 1986 by H. Stanley Staten
20 'SysOp 3 WINKs BBS, 301-670-9621
30 '
40 DEFINT A-Z
50 CLEAR
60 '
70 ' ********************************************************************
80 ' * ROUTINE TO INITIALIZE THE FASTCOMM 2496 MODEM'S FIRMWARE *
90 ' ********************************************************************
100 '
110 COM.PORT$ = "COM1" 'Change to "COM2:" for COM2: use
120 PRINT "Setting FASTCOMM 2496 firmware for RBBS-PC on " + COM.PORT$
130 '
APPENDIX D -- Modems with RBBS-PC Page D-3
140 ' ********************************************************************
150 ' * *
160 ' * INITIALIZE THE FASTCOMM 2496 VOLATILE MEMORY. SET as follows *
170 ' * *
180 ' * AT#F = Set to factory defaults *
190 ' * AT#LCN = Set carrier detect to normal *
200 ' * AT#LDN = Set DTR to normal *
210 ' * AT#LX2 = Set for XON/XOFF flow control *
220 ' * ATS7=30 = Set wait for answer tone to 30 seconds *
230 ' * ATM0 = Turn speaker off *
240 ' * ATV1 = Issue long form of results codes *
250 ' * ATX2 = Full result messages *
260 ' * ATS57=1 = Hang up and reset automatically executed *
270 ' * ATE0 = Do not echo modem commands back to the PC *
280 ' * ATS10=10 = To cause to reset on loss of carrier faster *
290 ' * ATS58=3 = Force a 19200 Baud call to 9600 Baud locally*
300 ' * ATS22=46 = Suggested by the vendor *
310 ' * ATS0=0 = Don't answer until told to. *
320 ' * AT#W = Write settings to non volatile memory *
330 ' * *
340 ' ********************************************************************
350 '
360 OPEN COM.PORT$ + ":2400,N,8,1,RS,CD,DS" AS #3
370 PRINT #3,"AAAAAAAT"
380 PRINT #3,"AT#F"
390 PRINT #3,"AT#LCN"
400 PRINT #3,"AT#LDN"
410 PRINT #3,"AT#LX2"
420 PRINT #3,"ATS7=30"
430 PRINT #3,"ATM0"
440 PRINT #3,"ATV1"
450 PRINT #3,"ATX2"
460 PRINT #3,"ATS57=1"
470 PRINT #3,"ATE0"
480 PRINT #3,"ATS10=10"
490 PRINT #3,"ATS58=3"
500 PRINT #3,"ATS22=46"
510 PRINT #3,"ATS0=0"
520 PRINT #3,"AT#W"
530 SYSTEM
Leading Edge Series L 2400B Modem
---------------------------------
Gregg Snyder, SysOp of "The Elusive Diamond" - DGS (Alpha) System, and Jim
Thompson of "The Break" -DGS (Delta) System (Data: 703-680-9269) are to be
credited with documenting how to get the Leading Edge Series L 2400B modem
to run with RBBS-PC ("all modems are Hayes-compatible, but some are less
Hayes-compatible than others").
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page D-4
First, you must set CONFIG parameter 228 to open the modem at 1200 baud.
Next, go to CONFIG parameter 225 and set the modem commands as follows:
1. Reset the modem : ATB1H0L1M0C1
2. Initialize the modem : ATH0B1L1M0Q1E0S0=254
Note: End item 2 with:
S0=1Q0X1 if answer on 0 rings
S0=254 if answer on >0 rings (no ring-back)
S0=255 if answer on >0 rings (with ring-back)
3. Count the number of rings : ATS1?
4. Answer the phone : ATQ0X1V1A
5. Take the phone off the hook : ATH1L1M0
6. Clear the modem's firmware : AT&F
7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5
Note: End item 7 with:
Q1 if item 2 ends with S0=255
8. Write to modem's firmware : &W
These settings have been tested for more than a year by Jim Thompson
beginning with RBBS-PC 15.1C.
MICROCOM AX\9624c
-----------------
First set the Microcom AX\9624c switch settings as follows:
CONFIGURATION SWITCH SETTINGS FOR THE MICROCOM AX\9624c MODEM
=============================================================
1 2 3 4 5 6 7 8 9 10
--------------------------------------
Front Switch - U D D D D U U D U U
Rear Switch - U U D U D D D D - -
Change CONFIG parameter 228 to open the modem initially for 9600 baud.
Then go to CONFIG parameter 225 and change some of the default Hayes
commands.
Within parameter 225, you will want to change the second command,
"Initialize the modem." If you want RBBS-PC to answer on one ring set it
to:
ATM0Q1S2=255S10=45E0S0=254&D2
To answer on zero rings, set it to:
ATM0Q1S2=255S10=15E0S0=0Q0X1&D3
Please note that these change the default Hayes commands supplied with
RBBS-PC for S10. Also note that an &D command was added to the end. If
you are set up to answer on ring zero and your modem sometimes stops
APPENDIX D -- Modems with RBBS-PC Page D-5
answering for no reason that you can isolate, alter the S10 value to "45"
and &D2. You may also want to activate CONFIG parameter 236 to "wake up"
the modem.
These configurations will allow RBBS-PC to establish a MNP reliable or
non-reliable connection from 300 to 9600 BAUD using the AX\9624c's MNP
class 6 Universal Link Negotiation capability.
Prometheus 2400G
----------------
Underneath the 2400G is a bank of 10 switches that set certain operating
characteristics of the ProModem 2400G. Only 3 (1,2 & 10) of these switches
are currently implemented. The others are reserved for future expansion.
All three of these switches must be in the off position for the 2400G to
function properly with RBBS-PC.
USRobotics Courier and HST
--------------------------
Both the US Robotics COURIER 2400 and COURIER HST modem switch settings
should be as follows:
1 2 3 4 5 6 7 8 9 10 gang switch
U U U D D U U D D D UUU (Where U = Up = Off and D = Down = On)
The Courier 2400 is a high quality, trouble free modem that is highly
recommended and which works well with all the RBBS-PC defaults.
The USR COURIER HST modem switch setting should be as follows:
1 2 3 4 5 6 7 8 9 10 gang switch
U U U D D U U D D U UUU (Where U = Up = Off and D = Down = On)
RBBS-PC supports both modes of the USR HST Modems. In CONFIG, specify the
number of seconds between modem commands to be 1.
MODE 1:
-------
In the first mode of operation, CONFIG parameter 228 should be set to the
highest speed you intend to support. When the HST modem detects a carrier,
it sends (at the baud rate set in parameter 228) an ASCII string to RBBS-PC
which contains the new BAUD rate. The modem will change it's baud rate to
match that of the caller's and RBBS-PC will correctly adjust to the modem's
new baud rate. The following CONFIG parameters should be set:
Parameter 222 -- set to 3 to allow the modem enough time to initialize
Parameter 223 -- set to 2
Parameter 227 -- set to NO
Parameter 228 -- set to 9600
Parameter 237 -- set to NO
Parameter 244 -- set to YES
Parameter 245 -- set to NO
You should also reply "NO" to parameter 225, CONFIG will show you a menu of
8 different modem commands. The ONLY command that needs to be changed is
number 7, "Initialize the modem firmware". It should be:
AT&A1&B0&H1&I0&M4&N0&R2&S1&Y3
The meaning of this HST-specific initialization string is as follows:
&A1 = Display/ARQ result codes
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page D-6
&B0 = DTE/DCE rate follows connection rate
&H1 = Hardware (Clear To Send, Pin 5) flow control
&I0 = Flow control disabled
&M4 = Normal if ARQ connection cannot be made
&N0 = Negotiate highest possible link rate with remote modem
&R2 = Received data output to terminal on Request to Send high (Pin 4)
NOTE: If your HST 9600 modem responds 961 or greater to the ATI
command, substitute &R1 for &R2.
&S1 = Modem controls Data Set Ready
&Y3 = Nondestructive, unexpedited break signal
The highest effective data transmission rate in this mode is 9600 baud.
MODE 2:
-------
In this second mode the USR Modem supports the MNP data compression
technique which effectively transmits data over the phone at rates in
excess of 17K baud. Setting up your HST to support both the standard 300,
1200, 2400, and the higher 9600 and 17K baud rates requires that the HST
modem speed be "fixed" at 19.2K baud. The PC running RBBS-PC will
communicate with the HST modem attached to it at a fixed rate of 19.2KB.
The actual data link speed will default to the highest rate that the
caller's modem will support.
Parameter 222 -- set to 3 to allow the modem enough time to initialize
Parameter 223 -- set to 2
Parameter 227 -- set to NO
Parameter 228 -- set to 19200
Parameter 237 -- set to YES
Parameter 244 -- set to YES
Parameter 245 -- set to NO
You should also reply "NO" to parameter 225, CONFIG will show you a menu of
8 different modem commands. The ONLY command that needs to be changed is
number 7, "Initialize the modem firmware". It should be:
AT&A1&B1&H1&I0&M4&N0&R2&S1&Y3
The meaning of this HST-specific initialization string is as follows:
&A1 = Display/ARQ result codes
&B1 = DTE/DCE rate is fixed at allowable rate
&H1 = Hardware (Clear To Send, Pin 5) flow control
&I0 = Flow control disabled
&M4 = Normal if ARQ connection cannot be made
&N0 = Negotiate highest possible link rate with remote modem
&R2 = Received data output to terminal on Request to Send high (Pin 4)
NOTE: If your HST 9600 modem responds 961 or greater to the ATI
command, substitute &R1 for &R2.
&S1 = Modem controls Data Set Ready
&Y3 = Nondestructive, unexpedited break signal
This will enable the COURIER HST to use the built-in MNP protocol at the
highest possible baud rate that can be negotiated with the calling modem --
providing the calling modem is also a COURIER HST modem. The highest
effective data transmission rate in this mode is 17200 baud.
After replying NO to CONFIG parameter 225 and changing the initialization
modem command as described above for either MODE 1 or MODE 2 for the
APPENDIX D -- Modems with RBBS-PC Page D-7
COURIER HST, CONFIG parameter 231 should be selected in order to initialize
the COURIER HST. This places the setting in the HST's non-volatile random
access memory (NVRAM) and need only be repeated if the NVRAM is changed
(i.e. you use the modem with applications other than RBBS-PC that change
the NVRAM).
For the COURIER 2400, set CONFIG parameter 228 to 2400. For the COURIER
HST, set parameter 228 as specified above for either MODE 1 or MODE 2.
USRobotics HST Dual Standard
----------------------------
The USRobotics Dual Standard is an excellent choice for BBS SysOps. It
combines reliability, performance and compatibility. The biggest hurdle is
the price! However, SysOps can contact USRobotics at (800) DIAL-USR for
information about SysOp special prices.
The Dual Standard can support low-speed connections, as well as V.32, V.42,
V.42bis and HST-mode connections. A proper configuration of the BBS modem
will allow a caller with nearly ANY modem to connect with your BBS.
The file MODEMS.SET contains proper switch settings, firmware and
initialization settings, and CONFIG parameter settings for the dual
standard. However, you should consider the following:
1) The dual standard is flexible. The configuration suggested for
RBBS-PC will allow nearly all modems to connect to your BBS, but
perhaps not at the optimum speed. The main consideration for
performance is the use of data compression. RBBS-PC will ENABLE
data compression on your modem. If your callers also enable
compression, V.32 throughput when transferring COMPRESSED files
will suffer. However, throughput when capturing large text files
(such as reading messages non-stop) will be much higher than
normal. You may want to post a bulletin to your users that if
they want FAST FILE TRANSFER, they should DISABLE compression
(&K0 is the modem command for the dual standard). If they do so,
your modem will also disable compression for their call. This
will allow each caller to decide if they want maximum throughput
for compressed files, or for text files.
2) For best results, the baud rate is locked between RBBS-PC and the
modem. This allows the modem to negotiate speed with the caller, but
RBBS-PC can transfer data as fast as possible. This should work under
all instances, but if you have trouble configuring doors or external
protocols, you may wish to turn off this feature. To do this, change
the baud lock command in the FIRMWARE initialize command (CONFIG
parameter 225) to ???, and tell RBBS-PC to NOT remain at the initial
baud rate (CONFIG parameter ???).
ZOOM Modem HC2400
-----------------
In order to use the "ZOOM HC2400" modem with RBBS-PC parameter 225 should
be changed as shown below. Only #2 and #5 need to be changed.
Changes in #2. Add '&D2' just after 'AT'. Change 'S2=255' to 'S2=43'.
Change in #5. Add "&D2' just after 'AT'.
1. Reset the modem : ATZ
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page D-8
2. Initialize the modem : AT&D2M0Q1S2=43S10=30E0Q0X1S0=0
Note: End item 2 with:
S0=1Q0X1 if answer on 0 rings
S0=254 if answer on >0 rings (no ring-back)
S0=255 if answer on >0 rings (with ring-back)
3. Count the number of rings : ATS1?
4. Answer the phone : ATQ0X1V1A
5. Take the phone off the hook : AT&D2Q1E1H1M0
6. Clear the modem's firmware : AT&F
7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5
Note: End item 7 with:
Q1 if item 2 ends with S0=255
8. Write to modem's firmware : &W
For further information contact:
Jeff L. Watts
STATESVILLERBBS-PC Data # (704) 873-8482
APPENDIX E -- RBBS-PC and the Hearing-Impaired Page E-1
APPENDIX E -- RBBS-PC and the Hearing-Impaired
----------------------------------------------
Telecommunications Devices for the Deaf (TDDs) use the Baudot character set
(i.e. 5-bit) and utilize modems that transmit at 45 baud and do not
generate a carrier signal. This is because such devices were initially
adaptations of surplus Western Union TTY machines for telephone
communications. The widespread use of Baudot devices by the hearing-
impaired, the previous high cost of computers and modems, and the lack of
software designed for electronic communications, has impeded the change to
ASCII communications by the hearing-impaired community.
Equipment manufacturers have also made it difficult for the deaf to change.
When TDD's with ASCII code transmission capability began to be offered, the
majority of manufacturers limited them to only 110 baud and put disclaimers
in their manuals that said ASCII was available for use but that "computer
language" was "less reliable" and hard to use. Their limiting of the TDD's
output screen to 12 to 20 characters further compounded the problem because
the screen would overwrite several times to display one line of text from a
host system. The manufacturers' "solution" to this problem was to
recommend printers for communication with such "host" systems as RBBS-PC.
Some units now offer both 110 and 300 baud ASCII transmission in addition
to the 45 baud Baudot. Unfortunately, these typically have only 20
character screens.
In December of 1984, Ted Janossy of Rochester, Minnesota, sent a three-page
letter to Tom Mack describing the above situation. Ted's letter motivated
Tom to test and verify the "ring-back" feature of RBBS-PC in 12.4A. It
had not been tested in earlier versions because Tom assumed (presumptuously
and insensitively) that "real SysOps don't use ring-back RBBS-PC's." Ted's
letter awakened Tom to the potential of RBBS-PC to facilitate
communications among the hearing-impaired. In the awakening, Tom also had
a chance to look down at his own feet of clay.
RBBS-PC can be configured to answer calls only after a specified number of
rings (i.e. 15). The telephone companies wire the homes of the
hearing-impaired such that when the phone rings, the lights within the
house flash on and off.
With RBBS-PC a SysOp can specify the number of rings RBBS-PC is to wait
before answering the phone automatically. Setting this number high enough
allows someone with a hearing impairment time enough to get to the PC
running RBBS-PC. Pressing the PC's function key 5 (F5) causes RBBS-PC to
answer the phone immediately. The caller would know that someone was at
the keyboard because RBBS-PC answered the phone in less than the agreed-
upon number of rings. The caller would log onto RBBS-PC normally and the
person at the PC keyboard would be able to see who it was. If the person
who was called wanted to "chat" with the caller, all they would have to do
would be to press function key 10 (F10).
If RBBS-PC didn't answer the telephone within the agreed-upon number of
rings, the caller would know that whomever was being called couldn't come
to the keyboard. The caller would then log on and leave a message.
APPENDIX F -- RBBS-PC And The AT's RS-232 Cable Page F-1
APPENDIX F -- RBBS-PC And The AT's RS-232 Cable
-----------------------------------------------
The RS-232 serial connector is different for the AT than the PC or XT. The
AT uses a connector called a DB-9, which is a 9 pin connector. An
alternative to buying the AT serial cable from IBM, ($65-$80), is to make
your own. A ten-wire cable can be purchased from any local computer store
for about $.80 per foot, and the DB-9 and RS-232 connectors with hoods can
be purchased from Radio Shack. The total cost should be about $12.00. A
modem hooked up to the AT will work fine with the 9 pins connected in all
terminal functions, except for auto-answer applications such as RBBS-PC.
RBBS-PC requires pin 1 from the modem to be hooked up to the chassis ground
on the AT or it can't answer the phone. There are two ways to hook up the
ground wire on the computer end. The first way is to use a metal hood to
cover the DB-9 connector. Wrap a bare wire that is attached to pin 1 of
the RS-232 connector around the cable on the DB-9 end. When the metal hood
is screwed down over the cable a connection will be made. When using a
plastic DB-9 hood simply solder a wire from pin 1 on the RS-232 end to the
metal body of the DB-9 connector. Since documentation is scarce for the
AT, following figure lists the necessary pin connections for those wanting
to make their own AT RS-232 cable.
DB-9 RS-230
(Computer (Modem Description
End) End)
========= ======= ==================
GROUND -------- 1 -------- Protective Ground
1 -------- 8 -------- Data Carrier Detect
2 -------- 3 -------- Receive Data
3 -------- 2 -------- Transmit Data
4 ------- 20 -------- Data Terminal Ready
5 -------- 7 -------- Signal Ground
6 -------- 6 -------- Data Set Ready
7 -------- 4 -------- Request to Send
8 -------- 5 -------- Clear to Send
9 ------- 22 -------- Ring Indicator
APPENDIX G -- RBBS-PC And BASIC Compiler Patches for "Doors" Page G-1
APPENDIX G -- RBBS-PC And BASIC Compiler Patches for "Doors"
------------------------------------------------------------
A bug in Microsoft's BASIC and QuickBASIC compilers requires SysOps who
wish to recompile RBBS-PC to apply the following patches. The problem has
to do with BASIC's treatment of the communications port when you exit a
BASIC program. The Data Terminal Ready (DTR) line MUST be kept on at all
times, or the modem will hang up on your caller.
If you are recompiling RBBS-PC, and you plan to use Doors or external
protocols, you must make the following patches. Any hex editor can be
used: DEBUG, which comes with DOS, or the Norton Utilities are just two
examples. A tutorial on how to use DEBUG is beyond the scope of this
document.
There are actually two patches, depending on the version of the compiler
you have. The first patch is for QuickBASIC 2, 3 & 4 or BASCOM 6.0.
The file you will patch is BCOMx0.LIB (where X is the QB version number).
Of course, you will save your original file before applying the patch. To
make the fix, you will search for the following string of HEX digits: 83 C2
04 32 C0 EE. The assembly code for this string is:
83 C2 04 ADD DX,4
32 C0 XOR AL,AL
EE OUT DX,AL
We need to change the XOR AL,AL to MOV AL,1. Change the "32 C0" to "B0
01". Make this change in both places where the string occurs.
If you use QB 4.5, or BASCOM 7.0, the patch is different. Look for the
string: B0 00 E3 01 40 83 C2 04 EE. In assembly code, it is:
B0 00 MOV AL,00
E3 01 JCXZ nnnn
40 INC AX
83 C2 04 ADD DX,4
EE OUT DX,AL
Again, we want to put a 1 in AL, so we change the "B0 00" to B0 01". We
also need to remove the INC AX, so change the "40" to "90".
You may also want to make an additional patch. This patch will prevent
QuickBASIC from pausing on a fatal error. Normally, BASIC says "press a
key to continue". If RBBS-PC were allowed to recycle, it would do so
without trouble, but BASIC will hold up your board until you press a key.
If you have QuickBASIC 2.01 or 3.0, search the BCOMx0.LIB for the following
string of HEX digits: E2 F8 E8 00 00 E8 00 00 E8 00 00 C3. Change the
MIDDLE "E8 00 00" to "C3 90 90". If you have QuickBASIC 4.5, search for
the string "B8 07 0C CD 21" and change the "CD 21" to "90 90". Now,
whenever BASIC can't handle an error, it will allow RBBS-PC to recycle
quickly.
If you have BASCOM 7.0, you can apply the patch for QB 4.5, although you
will have to patch whichever BC70xxxx.LIB file you use to link.
Thanks to Doug Azzarito, Jeff Porter, Rod Bowman, Kenny Gardner and Bob
Eyer for information on these patches.
APPENDIX H -- Running in DESQview Page H-1
APPENDIX H -- RBBS-PC in a DESQview Environment
-----------------------------------------------
DESQview, from Quarterdeck Office Systems, provides an excellent, low-cost,
software platform for RBBS-PC SysOps wanting multiple nodes on a single PC.
This appendix has been provided to help both the novice SysOp and the more
experienced SysOp with the implementation of multiple nodes under DESQview.
1. Basic Hardware Considerations
--------------------------------
If your computer has only 640k, you will be limited to a single node when
using DESQview. If, however, your computer has 1-Megabyte or more of EEMS
memory, DESQview is capable of supporting up to 8-nodes on a single
computer. Providing two nodes is simple. Going beyond two nodes will
require special software and hardware. This appendix describes both
approaches.
Multiple-node operation will require an EEMS-compatible memory expansion
card for your computer. Make certain your memory card is EEMS (not merely
EMS, but EEMS) compatible! If you are not using an 80386 computer,
DESQview can ONLY swap EEMS memory, so you will want to replace as much
motherboard memory as possible with EEMS RAM. This limitation is described
in the DESQview documentation. These limitations do not apply if you use
an 80386/SX or 80386 based computer. Therefore, we recommend an 80386 as
the best choice for a multi-node host computer. If you plan to use an
80386 or 80386/SX computer, we suggest you purchase DESQview/386, which
includes the QEMM memory manager. This memory manager allows DESQview to
use regular 80386 Extended memory in the same manner as EEMS memory. The
QEMM memory manager may be purchased separately if you already have
DESQview.
Before you continue, make certain you have read and thoroughly understand
the instruction manual provided with your copy of DESQview.
2. Modifications to DOS CONFIG.SYS and RBBS-PC batch files
-----------------------------------------------------------
The first step in using DESQview with RBBS-PC is setting up your CONFIG.SYS
file. The FILES statement is critical. Allocate at least 16 files for
each copy of RBBS-PC. QEMM/386 will allow you to allocate files without
using base RAM (see the QEMM manual for details). Increasing DOS BUFFERS
will also help, but options such as a disk CACHE will determine the optimum
setting.
A 2-node CONFIG.SYS file should include the following:
FILES=32
BUFFERS=25
You should start RBBS-PC from a two-level batch file. A "startup" batch
file will perform functions required only once, when you open the DV
window. The second file, RBBS.BAT, will start RBBS-PC, and process the
recycling, doors and daily maintenance.
In our example, the "startup" batch file is named START.BAT. The node
number for each RBBS-PC node is passed to START.BAT by DESQview. In so
doing, you only need to provide a .DVP file for each node. All the batch
files are the same, which reduces confusion and maintenance.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page H-2
in C:\RBBS\START.BAT Description of each line's function:
-------------------------- --------------------------------------
DVANSI loads DESQview ANSI.SYS driver
SET NODE=%1 Sets the node number for this RBBS-PC node
SET DSZLOG=XFER-%node%.DEF set DOS environment variable for DSZ
RBBS call RBBS.BAT
The standard RBBS.BAT (explained in section 13) will be adequate for use
with each node of RBBS-PC under DESQview.
3. What to Tell RBBS-PC's "CONFIG" Utility
------------------------------------------
When using DESQview, you will need to change some parameters with the
CONFIG program (supplied with RBBS-PC). If you are running only one node,
the only required change is parameter 162 (network environment). Set this
to DESQview. If you are running multiple nodes, consult appendix G for the
parameters that should be set to properly configure multiple nodes.
4. DESQview Setup Default Settings
-----------------------------------
The next step in configuring DESQview for use with RBBS-PC is specifying
the default settings for DESQview. DESQview has a setup program that may
be invoked at the DOS prompt. Enter SETUP to run this DESQview setup
routine. After the SETUP program loads, press RETURN for the Advanced Setup
Procedure followed by a "P" for Performance defaults. Here is an example
of the recommended settings:
------------------------------------------
I Task Processing Time (in Clock Ticks) I Optimum Fore/Backgrnd can vary
I Foreground: 9 I between 15/14 and 4/3. These
I Background: 8 I settings will vary depending on
I I CPU speed and number of nodes
I Memory Usage (in K) I in operation. Experiment with
I Common Memory: 24 I different settings to find the
I DOS Buffer for EMS: 2 I best for your system.
I I
I Optimize communications? (Y/N): N I Select [Y] if you're operating
I Allow swapping of programs? (Y/N): Y I only 1-node under DESQview!
I Manage printer contention? (Y/N): N I
I I
I Next field Tab I
I Backup menu Esc I
I DONE < I
I I
------------------------------------------
NEVER indicate more clock ticks for Background processing than you are
using for the Foreground processing. DESQview will automatically increase
the amount of Background clock ticks whenever there is little demand for
Foreground processing. This will be the case when running RBBS-PC in the
background and doing word processing or a similar task in the foreground.
This feature cannot function properly if the Background clock ticks are set
higher than the Foreground clock ticks. Setting the High Speed Comm
default to YES will make communications interrupts the highest priority.
While this is suggested if you operate a single node, you should specify NO
for optimum performance when operating multiple nodes.
APPENDIX H -- Running in DESQview Page H-3
5. Adding RBBS-PC to DESQview's "Open Window" Menu
---------------------------------------------------
Refer to the section "Adding Your Own Program" in the DESQview manual. You
will need to "Add a Program" for each node of RBBS-PC you intend to operate
on your system. You may name the programs N1, N2, etc. N1 will load the
batch file START.BAT with the Parameter "1". N2 will load START.BAT with
the Parameter "2" and so on. Use the following settings for each node (or
copy) of RBBS-PC you install.
Add a Program
--------------------------------------------------------------------------
Program Name............: [NODE-1]
Keys to Use on Open Menu: N1 Memory Size (in K): 380
Program...: START Please note that Memory Size above may
need to be increased if you intend to
Parameters: 1 (node number) SHELL (rather than DOOR) to External
file transfer protocols.
Directory.: C:\RBBS
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)..........: [Y] <-N if Using a
Requires floppy diskette.............: [N] FOSSIL driver
--------------------------------------------------------------------------
Next, press F1 for the Advanced Options menu.
Change a Program Advanced Options
--------------------------------------------------------------------------
System Memory (in K).......: 0 Maximum Program Memory Size (in K)..:
Script Buffer Size.......: 1 Maximum Expanded Memory Size (in K):
Text Pages: 1 Graphics Pages: 0 Initial Mode: Interrupts: 00 to FF
Window Position:
Maximum Height: 25 Starting Height: Starting Row...:
Maximum Width.: 80 Starting Width.: Starting Column:
Shared Program
Pathname..:
Data......:
Close on exit (Y,N,blank)......: [N] Uses its own colors............: [Y]
Allow Close Window command.....: [Y] Runs in background (Y,N,blank).: [Y]
Uses math coprocessor..........: [N] Keyboard conflict (0-4)........: [0]
Share CPU when foreground......: [Y] Share EGA when foregrnd/zoomed.: [Y]
Can be swapped out (Y,N,blank).: [N] Protection level (0-3).........: [0]
--------------------------------------------------------------------------
6. Memory Considerations
------------------------
Please refer to your DESQview documentation for information regarding the
use of XDV.COM and optimizing the size for each DESQview window. Current
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page H-4
versions of DESQview require a little under 180k of your system's memory,
leaving only 430k to operate RBBS-PC on a system with 640k. Specify a
minimum window size of 380k for RBBS-PC. If you choose to SHELL (rather
than DOOR) to external protocol drivers for file transfers, you will have
to increase this window size, probably to 500k.
It is necessary to use EEMS memory to run two or more concurrent copies of
RBBS-PC under DESQview. If available EEMS memory allows, you may wish to
add an additional "LOCAL" node for SysOp use. When using an additional
node for SysOp duties, an additional modem and RS-232 interface are not
required. Simply use CONFIG to set up the .DEF file for the node you are
planning to use for SysOp duties. You must specify the communications port
as COM0. Failure to do so will prevent your local SysOp node from loading
properly.
7. Expanded Memory
------------------
If you are using an "Expanded Memory" board that allows more than 640k to
be used for programs, the constraints discussed in the previous section may
not apply. Specify a window size of 460K for each node of RBBS-PC and
invoke the external protocol drivers by SHELLing. For information on
running programs in expanded memory, refer to the manuals for DESQview and
your particular memory board.
8. How to AUTOEXEC RBBS-PC From DESQview
----------------------------------------
Refer to the section "LEARN: DESQview's Keystroke Macro Feature" in the
DESQview manual. A script assigned to the ! key (on the DESQview menu) has
a special meaning. It is performed at the time you start up DESQview,
immediately after the DESQview menu appears. This is called a STARTUP
SCRIPT. You should "Learn" the Startup Script with no windows open and
with the DESQview menu displayed to be sure it will play back properly.
Use this particular script to load N1, N2, etc. of RBBS-PC. If you load
DESQview from your AUTOEXEC.BAT file, RBBS-PC will load from DESQview
automatically. This can be handy if there is a power outage while you are
away and no one is around to re-load RBBS-PC when the electricity returns.
You should open the window(s) for RBBS-PC prior to opening windows for any
other application software.
9. Quarterdeck Utilities
------------------------
Two Quarterdeck utilities, STDERR.COM and LDFILTER.COM are distributed with
RBBS-PC. LDFILTER.COM should be executed when you open a window in
DESQview. If you use the Small & Fast version of RBBS-PC, or you compile
RBBS-PC with QuickBASIC v2.01, you should use LDFILTER.COM, but not
otherwise. In the above examples, LDFILTER would be placed into the
START.BAT batch file. LDFILTER was written by Quarterdeck Office Systems
to compensate for the memory mismanagement of the BASIC compilers. If you
try to "SHELL" to an external routine the error "not enough memory to
SHELL" is issued. LDFILTER.COM prevents this error condition by preventing
the code generated by the BASIC compilers from mis-managing memory.
STDERR.COM should be executed from your autoexec.bat file, prior to loading
DESQview. STDERR was written by Quarterdeck Office Systems to compensate
DOS' inability to redirect the standard error output to the same device
that the standard output device had been redirected to. If you are running
something remotely and an error occurs, STDERR.COM allows the error to be
APPENDIX H -- Running in DESQview Page H-5
displayed at the remote user's end and not simply on the PC that is running
RBBS-PC under DESQview.
10. Redirecting I/O Considerations (DOS CTTY Command)
-----------------------------------------------------
The DOS CTTY command is NOT supported under DESQview. The GATEWAY device
driver version 2.0, by Hans D. Kellner, provides an excellent alternative.
This device driver is available on many bulletin boards under the filename
GATEWAY2.ZIP.
Since the DOS CTTY command is not supported within a DESQview window, you
may use GATEWAY2 to allow redirection of I/O. This will allow the SysOp
Function 7 (drop to DOS) to function properly! It will also allow RBBS-PC
DOORS to function that rely on the CTTY command.
Instructions for installing GATEWAY2 with RBBS-PC.
1) Place the file 'GATEWAY2.SYS' in your boot disk root directory.
2) Add the following lines to your 'CONFIG.SYS' file:
DEVICE=GATEWAY2.SYS -D -1 <-- for node-1 using COM1
DEVICE=GATEWAY2.SYS -D -2 <-- for node-2 using COM2
(note) You must change the [-d] parameter to [-f] if you are using a
FOSSIL driver (described later in this appendix).
3) Run the RBBS-PC CONFIG.EXE program for each node of RBBS-PC you're
using. Select parameter 106, and specify that you do NOT want to
redirect via CTTY. CONFIG will then ask if you wish to redirect via a
device driver. Enter "Y", and then enter GATE2 as the device name.
The use of GATEWAY2 has an added benefit for those SysOps who provide the
PC-SIG collection of files on CD-ROM. When a user A)rchives a disk,
RBBS-PC will use Gateway to redirect the archive activity (normally seen
only on the SysOp's screen) to the remote user. This will allow the caller
to see the PC-SIG disk being archived!
11. FOSSIL Drivers - Break the 2-node Barrier under DESQview!
-------------------------------------------------------------
The BASIC language can only support COM1 and COM2, and when either of these
are selected and you specify that you will not be using a "FOSSIL" driver,
RBBS-PC will use the built-in BASIC support for remote access (i.e. via a
communications port and a modem). However, RBBS-PC will interface with
"FOSSIL" drivers that support not only COM1 and COM2 but also COM3 through
COM8. If you use parameter 221 to indicate that RBBS-PC is to access the
communication port via a FOSSIL driver, the FOSSIL interface (FOSSCOMM.OBJ)
written by Daan Van der Weide will be used. FOSSCOMM is already built into
RBBS-PC, so it will be active as soon as you select it. In a multi-tasking
environment such as DESQview up to 8 copies of RBBS-PC can run
simultaneously accessing COM1 to COM8, respectively, using Ray Gwinn's
X00.SYS device driver. Ray can be reached via FidoNet (109/639) or the
RENEX bulletin board at (703) 494-8331 or (703) 690-7950. X00.SYS is also
available on many BBSs.
When using FOSSIL support, you will select CONFIG parameter 221. After you
specify a communications port, CONFIG will ask if it should use FOSSIL
support. Answer YES, and then enter the base comm port address for the
port. See the chart later in this section for common base port settings.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page H-6
If you choose to implement a fossil driver, you'll want to change the
following parameter for each DESQview window:
Options:
Uses serial ports (Y,N,1,2)..........: [N] <--Set to NO
If the fossil is handling communications, you should tell DESQview that
RBBS-PC is NOT using serial ports. That way, only the fossil is handling
the communications for each port.
In the following text, we will attempt to give you some basic information
regarding the use of X00.SYS with RBBS-PC. For additional information,
please refer to the documentation provided with the X00.SYS fossil driver.
There are several approaches that can be taken to implement serial ports
with Ray Gwinn's X00.SYS. THE FIRST APPROACH involves the use of separate
base I/O addresses and separate IRQs for each serial port. This is the
method we use on our BBS to provide 4-ports on a single 80386-based
computer. We use the following configuration:
Card #1 COM1 IRQ4 3F8h (standard IRQ, standard base I/O)
Card #1 COM2 IRQ3 2F8h (standard IRQ, standard base I/O)
Card #2 COM3 IRQ7 3E8h (non-standard IRQ, standard base I/O)
Card #2 COM4 IRQ5 2E8h (non-standard IRQ, standard base I/O)
We use serial ports with the NS16550AFN UART chips. This particular chip
is recommended if you intend to use 9600-bps modems with multiple nodes
under DESQview.
Here is a sample CONFIG.SYS line that activates X00.SYS. In addition to
specifying the IRQs and base I/O for each port, each port is locked to
19,200 bps. High speed modems, or ones that use data compression will gain
throughput if the port speed is locked. This is not necessary if you are
using a standard Hayes-compatible 2400-bps modem. This entry is on a
single line but appears as two lines below.
DEVICE=C:\X00.SYS E T=2048 R=2048 0=3F8,IRQ4 1=2F8,IRQ3 2=3E8,IRQ7 3=2E8,
IRQ5 B,0,19200 B,1,19200 B,2,19200 B,3,19200
We have also configured GATEWAY2 (discussed earlier in this text) to make
use of the fossil driver. The lines in CONFIG.SYS would be:
DEVICE=C:\GATEWAY2.SYS -F -1 (gateway for COM1)
DEVICE=C:\GATEWAY2.SYS -F -2 (gateway for COM2)
DEVICE=C:\GATEWAY2.SYS -F -3 (gateway for COM3)
DEVICE=C:\GATEWAY2.SYS -F -4 (gateway for COM4)
THE SECOND APPROACH also involves the use of a separate base I/O for each
port, but IRQs are "shared". Recent versions of X00.SYS will manage the
use of a "Shared" IRQ. For example, COM1 and COM2 on the first serial card
share IRQ4. COM3 and COM4 on the second serial card share IRQ3. Under
this arrangement each port sharing an IRQ must be located on the SAME CARD.
This requirement is not due to X00.SYS but is, instead, a hardware
restriction; IRQs cannot be shared between boards.
In both the above examples, NON-intelligent serial cards are used. RBBS-PC
will NOT support the many "Intelligent" multi-port I/O cards on the market.
However, RBBS-PC does work with the DigiChannel Digiboard. See the chapter
APPENDIX H -- Running in DESQview Page H-7
on "GOING MULTI-NODE" for the proper set up. These "Intelligent" boards
are popular in other environments (such as UNIX) but they provide a
datastream into the host using a single base I/O address. RBBS-PC must
receive its communications at a separate base I/O for each port.
Here's a chart of generally accepted IRQs and base I/O addresses for the
standard PC/AT and PS/2. Although these are the common settings, they vary
(and we stress VARY) according to serial card manufacturer.
Standard AT BUS Microchannel (PS/2) BUS
------------------------------------------------------------------------
PORT BASE I/O IRQ PORT BASE I/O IRQ
------------------------------------------------------------------------
COM1 3F8h IRQ4 COM1 3F8h IRQ4
COM2 2F8h IRQ3 COM2 2F8h IRQ3
COM3 3E8h IRQ4 COM3 3220h IRQ3
COM4 2E8h IRQ3 COM4 3228h IRQ3
COM5 3F8h IRQ4 COM5 4220h IRQ3
COM6 2F8h IRQ3 COM6 4228h IRQ3
COM7 3E8h IRQ4 COM7 5220h IRQ3
COM8 2E8h IRQ3 COM8 5228h IRQ3
------------------------------------------------------------------------
If you intend to duplicate the 4-node configuration as in the preceding
example, you will need to find a serial card that will let you choose any
IRQ from IRQ3 to IRQ7 for each port (1 through 4).
In closing, there are also some important issues to consider when choosing
to go beyond two ports on a single computer. These include:
1) EXTERNAL PROTOCOL SUPPORT. The external protocol drivers you choose
must let you either define the IRQ for the additional ports, or they
just rely on the fossil driver for their communications. In other
words, they must have support for fossil drivers. Some protocols scan
a port for I/O without using an IRQ. These will probably work if you
use standard base I/O addresses for your additional ports.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page H-8
2) CPU SPEED LIMITATIONS. Here's a chart indicating recommendations for
each computer type, amount of EEMS memory and number of nodes.
--- PERFORMANCE ---
HOST 1-Node 2-Nodes 3-Nodes 4-Nodes 5-Nodes 6-Nodes 7-Nodes
8-Nodes
COMPUTER 640k 1.4Mb 2.0Mb 2.6Mb 3.2Mb 3.8Mb 4.4Mb 5.0Mb
------------------------------------------------------------------------
PC 4.77-MHz A2 C3 F5 F5 F5 F5 F5 F5
PC 8-12-MHz A1 B2 D5 F5 F5 F5 F5 F5
AT 8-12-MHz A1 B2 C4 D5 F5 F5 F5 F5
AT 16-20-MHz A1 A1 B3 C3 D5 D5 F5 F5
80386/SX A1 A1 A2 B2 C4 C4 D5 D5
80386/16-MHz A1 A1 A2 A2 B3 B3 C4 C4
80386/25-MHz A1 A1 A2 A2 B3 B3 C3 C3
80386/33-MHz A1 A1 A1 A2 B3 B3 B3 B3
--------------------------------------------------------------------------
A=EXCELLENT at 2400-bps 1=EXCELLENT at 9600-bps
B=GOOD at 2400-bps 2=GOOD at 9600-bps
C=MARGINAL at 2400-bps 3=MARGINAL at 9600-bps
D=POOR at 2400-bps 4=POOR at 9600-bps
F=Not Recommended 5=Not Recommended at 9600-bps
--------------------------------------------------------------------------
Your results may vary due to specific hardware differences.
If you plan to support BPS rates of 9600 or above on one or more nodes, we
recommend the use of NS16550AFN UART chips. These chips are necessary for
acceptable Zmodem (DSZ) performance under DESQview.
12. RBBS-PC Technical Support For DESQview
------------------------------------------
If you would like additional information about DESQview and RBBS-PC, you
may contact the following RBBS-PC system:
Indiana On-Line (tm)
John L. Taylor, SysOp
(812) 332-RBBS (3/12/24/96/14.4KBPS)
APPENDIX I -- Using RBBS-PC with DoubleDOS Page I-1
APPENDIX I -- Using RBBS-PC with DoubleDOS
------------------------------------------
Two nodes of RBBS-PC can be operated on one 640K PC/XT/AT under DoubleDOS.
First, make sure DoubleDOS and RBBS-PC, individually, operate correctly on
your computer. Then, the DDCONFIG.SYS file can be changed to facilitate
operation of RBBS. SoftLogic Solutions, the DoubleDOS supplier, operates a
customer service BBS at 603-644-5556 and can often help with special
problems. (An example: DoubleDos version 4.0 must be modified with their
special patch in order to operate on machines using EEMS memory controlled
by AST's REMM.SYS driver.)
DoubleDOS even has a special interrupt that RBBS-PC calls to "give back"
unused time to the foreground job when it really doesn't need the time, so
that during periods of low communications activity, the foreground job runs
at essentially 100% of the machine's speed. GIVEBACK is incorporated into
releases 16.1A (and greater) of RBBS-PC.
The DOS (3.1 or greater) utility SHARE should be run before starting
DoubleDOS to provide for file locking.
RBBS-PC, due to the code generated by the BASIC compiler, requires a
considerable amount of memory. If insufficient memory is available, RBBS-
PC may fail to load, may report a string corrupt error, may hang, or, worst
of all, may appear to start and operate normally only to fail later. A
(partial) test of whether enough memory is available is to note the DS free
space in the SysOp initial menu when operating under DoubleDOS compared to
naked DOS; any reduction in this reported free space may indicate memory
shortage. The best approach, unfortunately, is to start with more memory
than necessary, get your system going reliably, and then do a crude cut-
and-try process of reducing memory until problems first appear; then back
off up to an again-reliable memory setting.
Terminate-and-stay-resident programs (e.g. ramdisks, print spoolers, Side
Kick) will reduce the memory available to RBBS-PC. Buffers specified in
the CONFIG.SYS file also reduce available memory. Some versions of DOS are
smaller than others; every little bit of memory helps. Large programs may
not run in the second DoubleDos memory section after starting RBBS-PC in
the first.
Because of these memory considerations, SHELLing to DOORS and external file
transfer protocols will not be possible. If these features of RBBS-PC are
used, they will need to be invoked by EXITing to them.
The BASIC compiler version used determines the amount of memory required.
Two nodes of RBBS(version 16.1A), have been demonstrated to operate
successfully under DoubleDOS when compiled with Quick Basic 1.02 and RBBS-
PC's memory requirements reduced (see Appendix U). When compiled with
Quick Basic 2.x, 3.x or 4.x, two nodes will not fit under DoubleDOS. To
save memory, expert SysOps who are adept at compiling/linking their own
custom versions of RBBS-PC, can selectively (and at their own risk) delete
from the source code sections that they do not require. Such personal
versions should not be circulated to others. If this is done, the more
recent compilers may produce code compact enough for 2 nodes.
DoubleDOS has several parameters that can improve RBBS-PC operation.
Sample:
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page I-2
menu = short ;the long menu requires more memory
display = text ;to not reserve graphics buffer
print driver = direct ;use direct drive, no buffer reserved
bottom size = half ;split memory for two RBBS-PC nodes
priority = equal ;both nodes run at same speed
The next items may be desirable to provide protection, in case any program
in the other memory section should try to use a COM port assigned to RBBS-
PC.
com1 = top ;obviously these two port
assignments
com2 = bottom ;could be reversed
Possible circumstances that might warrant this protection:
1.SysOp makes a COM port assignment error in the .DEF file for the other
node.
2.one node is temporarily shut down by the SysOp to run another program.
Some programs (e.g. some versions of BASIC) initialize both COM ports
(clobbering RBBS-PC) when started.
Warning: this protection is known to be unusable on some machines (e.g.,
works fine on IBM-PC 8088, does not work on AST Premium 286 or TATUNG 4000
AT).
It is convenient (and safer, to prevent keystroke errors) to automate your
startup. In your AUTOEXEC.BAT file you should initiate DOUBLEDOS as the
last item. It will then start, using the DDCONFIG.SYS file for detailed
RBBS-PC instructions. Sample DDCONFIG.SYS contents (this will vary
according to your exact setup):
top program = prompt TOP $p$g
top program = go
bottom program = prompt BOT $p$g
bottom program = go
Note that the change in prompt allows a single batch file, GO.BAT, which
has the single statement of GO%PROMPT%, to execute the correct node of
RBBS-PC in either node. Nothing is more embarrassing than to start a node
that is already operating. All that need be typed is GO<RETURN> and either
GOTOP or GOBOT will be executed. (Actually the GO batch file execution
looks like "TOP C:\DDOS>GOTOP $p$g". The $p$g is ignored.) GOTOP.BAT
might then look like this:
C:
CD\RBBS
RBBS1
RBBS1.BAT would then be the first node RBBS.BAT as discussed in this
document. Similarly, GOBOT would start RBBS2.BAT for the second node.
Stan Staten, RBBS-PC number (301) 670-9621
Kurt Riegel, RBBS-PC number (202) 524-1837)
APPENDIX J -- RBBS-PC in a MultiLink Environment Page J-1
APPENDIX J -- RBBS-PC in a MultiLink Environment
------------------------------------------------
RBBS-PC only runs under Multilink versions 4.0, 3.02 and earlier.
CONFIG's allows the SysOp to tell RBBS-PC that it will be running in a
MultiLink environment. This is ESSENTIAL when running RBBS-PC under
MultiLink. CONFIG allows the SysOp to specify what MultiLink terminal type
code to pass to MultiLink whenever RBBS-PC exits to DOS via a "Door". The
MultiLink documentation specifies the various terminal type codes. When a
SysOp indicates that "doors" are available (via parameter 101 of CONFIG)
and RBBS-PC is to be run under MultiLink, the SysOp is asked to select the
MultiLink terminal type that RBBS-PC is to inform MultiLink to expect when
MultiLink is given control of the "Door."
RBBS-PC has been tested running two copies of RBBS-PC under DOS 3.2 and
MultiLink Advanced (versions 3.02 and 4.0) on an IBM PC which had a mother-
board containing 256K and an AST Comboplus board with 384K (a total of
640K). However, to do this RBBS-PC must be re-compiled (see Appendix U).
The "autoexec" file was named AUTOEXEC.BAT and contained the following
parameters
MLINK /9,266/9,266
NOTE! ==>RBBS-PC must be recompiled with C:512 in order to run in a 268K
partition under MultiLink. As released, RBBS-PC is compiled with the
parameter C:4096 which requires a MultiLink partition of 270K. Of course,
to SHELL to the external protocols, the partitions must be about 440K.
It is important to avoid doing several things when running RBBS-PC under
MultiLink. First, NEVER RUN MLSLICE! This is because MLSLICE hangs off
the PC's timer chain and the code generated by the BASIC compilers violates
all sorts of DOS conventions whenever it is utilizing the PC's speaker
(i.e. as when RBBS-PC pages the SysOp). In so doing, the code generated by
the BASIC compilers is incompatible with programs that do follow DOS
conventions.
Second, NEVER use the DOS "PRINT" command! This is because there is a bug
in the code generated by the BASIC compiler that causes the system to hang
if a compiled BASIC program is running and DOS is printing something. This
bug has been corrected in the BASIC compiler that was used to generate
RBBS-PC.EXE that is distributed. However the version of RBBS-PC that you
get (if other than from CPCUG) may not have this bug corrected. This is a
bug that occurs independent of running MultiLink.
Third, check your Intel 8088 chip's copyright date by opening up the cover
and locating the 8088 chip. If the copyright date printed on the chip is
1978 (i.e. pre 1981), REPLACE THE INTEL 8088 CHIP!!!!! The 1978 Intel 8088
chip had several design flaws that will cause your system to lock up
occasionally. One of these design flaws allowed interrupts to occur while
stack switching (something that will happen running multiple partitions
doing disk I/O under any multi-tasking DOS add-on such as MultiLink or even
IBM's TopView). Don't blame MultiLink for the flawed Intel 8088 chip that
IBM put in your PC! It costs about $70 ($35 for the chip and $35 for
labor) and takes about 15 minutes to have the 1978 Intel 8088 chip
replaced. In fact, if you are going to replace your 1978 Intel 8088 chip,
you might consider the newer (and 5% to 10% faster) NEC V20 chip.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page J-2
Fourth, DON'T USE "BUFFERS=" in the CONFIG.SYS for DOS! This may be an
"old wives tale," but I am convinced (but can't prove) that there are
incompatibilities between the code the BASIC compiler generates, DOS's use
of "BUFFERS=", and MultiLink.
fifth, RBBS-PC will only run in Background 1 or Background 2.
Finally, DON'T RUN PROGRAMS THAT USE THE BASIC "RUN-TIME" LIBRARY, and
always invoke the BASIC interpreter with the command BASIC /C:0! Both the
BASIC interpreter's handling of communications ports and BASRUN.EXE seem to
violate enough DOS conventions to "lock up" MultiLink.
When RBBS-PC is told that it is running in a MultiLink environment via
CONFIG parameter 162, RBBS-PC will automatically do the following:
1) When re-cycling, it will automatically enqueue on the correct
MultiLink resource ID for the communications port defined in CONFIG
for that copy of RBBS-PC to use.
2) When re-cycling, it will automatically tell MultiLink that this is a
type "9" partition (i.e. MultiLink is NOT to handle the communications
port).
3) When exiting to DOS via a "door", RBBS-PC will automatically
tell MultiLink to start handling the communications for this
partition (COM1 or COM2) and what type of terminal was defined
in CONFIG that would be on the communications port (MultiLink
terminal types 1 through 12).
Manually, it is possible to bring up and run one copy of RBBS-PC under
MultiLink. The only way that I have been able to bring up two copies of
RBBS-PC successfully (one copy running in each of two partitions) was to
bring them up via AUTOEXE1.BAT and AUTOEXE2.BAT files. It appears that
during the MultiLink initialization sequence when the partitions are being
established and the "AUTOEXEx.BAT" files are being invoked that MultiLink
doesn't get "confused" and lock up with a second copy of RBBS-PC present.
If using Multi-Link to run multiple nodes in the same machine under
DOS 3.x or above, it is recommended that the SysOp execute SHARE.COM prior
to starting multiple RBBS-PC nodes under Multi-Link and specify FILES=20 in
the CONFIG.SYS file.
APPENDIX K -- RBBS-PC in a CORVUS Network Page K-1
APPENDIX K -- RBBS-PC in a CORVUS Network
-----------------------------------------
RBBS-PC uses the standard Corvus SEMAPHORES when sharing files among
multiple copies of RBBS-PC within a Corvus Network. This is accomplished
via the MS-DOS utility driver, DRIVEC2, that Corvus supplies with its
network.
On a multi-server Corvus network (i.e. where there are multiple shared hard
disk drives) all PC's that are running RBBS-PC within the Corvus network
MUST have their "home volume" on the same server. Corvus maintains each
PC's semaphores on that PC's "home volume". In order to "share" files
among various PC's in a Corvus network, all the PC's that are "sharing"
must also be looking at the same set of semaphores. In a single-server
Corvus network this is not a consideration because there is only one "home
volume."
RBBS-PC has been only tested with the Corvus CONSTELLATION II interface
cards and software that Corvus provides for the IBM PC. RBBS-PC should
work with both Corvus' older "flat cable" network as well as their newer
OMNINET twisted wire pair cable network when running CONSTELLATION II
software. It is entirely possible that RBBS-PC would work with some
combination of both Corvus network types as long as they were running
CONSTELLATION II software.
It should be self-evident that every PC within a Corvus network running
RBBS-PC must have a Corvus interface card. If multiple copies of RBBS-PC
are running in a Corvus network that is using older Corvus software (i.e.
NOT running the CONSTELLATION II software), the interface cards must, at
least, all have the CONSTELLATION II ROM.
RBBS-PC is tested only to run on IBM PC's within a Corvus network. Clearly
an IBM "clone" that can run IBM's DOS, RBBS-PC.EXE, and is supported by
Corvus' network should also work. However, such configurations (and their
many variations) are not part of the environment within which RBBS-PC is
tested and supported.
APPENDIX L -- RBBS-PC in ORCHID or AST PCnet NETWORK Page L-1
APPENDIX L -- RBBS-PC in ORCHID or AST PCnet NETWORK
----------------------------------------------------
RBBS-PC can be implemented on an Orchid PCnet or AST PCnet Network
environment. It is assumed that the necessary network hardware is
installed correctly. The following discussion describes a network
currently in operation and receiving more than 1000 calls per week on two
telephone lines for the Computer Connection of Virginia Beach. The
hardware and software was:
1. 80286 based SERVER with 512K running at up to 9 MHz with:
Parallel-Serial Board on the AT with a serial port addressed as COM1
AST Rampage memory board configured with 2 megs of expanded memory
Monochrome Adapter with parallel printer port
PC Net adapter addressed as 0080 with default jumpers
Hard disk that can be divided into multiple volumes
Single High Density [1.2 meg] floppy disk
External modem and cable connected to COM1
2. 8088 based WORKSTATION with 640K running at up to 8 MHz with:
multifunction board with COM1, a clock, and parallel port
PC Net adapter addressed as 0011 with default jumpers
Color Graphics Adapter
Two 360K floppy drives
External modem and cable connected to COM1
3. Software -
Operating System = DOS 3.1 network-wide
Network Software = Orchid PC Net 3.0a
Disk Caching Software = Orchid CACHE.EXE version 2.2
RAM Disk = AST FASTDISK
Installation procedures ---
1. Preliminaries
1. Backup hard disk, system and network disks.
2. If your hardware is different, be sure to resolve INTerrupt conflicts
with the PC NET adapters. Disable second serial or parallel ports in all
PC's.
2. Using the WORKSTATION, boot with DOS 3.1 then
1. Create the SERVER and WORKSTATION boot disks with SPCGEN and UPCGEN
commands, respectively.
2. Copy device drivers for the hard disk, for the RAM disk, and for
Expanded and Extended memory (REMM.SYS and REX.SYS) to the SERVER boot disk
as well as CACHE.EXE. Place the following CONFIG.SYS file for the SERVER:
device=spc.com <-- Network SERVER driver
device=REMM.SYS <-- Expanded memory driver
device=rex.sys 1024 <-- 1MB Emulated extended memory
device=fastdisk.sys 1024 512 128 /e <-- RAM disk in extended memory
3. Place the following commands in the AUTOEXEC.BAT file:
disk13 <-- Network for floppy disk use
cache [drives] d=128 x=896 /r <-- 128K cache of DOS memory & 896K of
EMS memory for SERVER drives to reduce the number of disk accesses
spcbio 138023 <-- Tell network of interrupts used
4. Using the SERVER, boot with the newly created SERVER boot disk
1. Run the network program SPCINST.
2. After naming all the available drives on the server, assign all the
hard drive volumes to the WORKSTATION # 11 and them all READ/WRITE capable.
"Remote Execution" need not be enabled.
3. The SERVER will then reboot and the network will have the final
configuration as outlined above.
5. Boot the WORKSTATION with the newly created WORKSTATION boot disk and:
1. Add FILES = 16 to the CONFIG.SYS file for the WORKSTATION.
2. Use the network program UPCINST to communicate with SERVER # 80.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page L-2
3. "Map" in all the drives that were assigned by the SERVER.
4. The WORKSTATION will reboot so the changes can take effect.
5. After the WORKSTATION reboots, do a DIR C: to see if the directory on
the SERVER hard disk can be read. If not, recheck cables, plug-in cards
for INTerrupt conflicts, and network adapter cards to verify all jumper
settings. If necessary, run the SELFTEST and NETTEST diagnostics for the
network adapter cards. Also, demonstrate the ability to copy files across
the network to and from the server then verify the transfer using the COMP
command.
6. Assuming that you are able to do a DIR across the network and copy files
to and from the SERVER, you are then ready to run CONFIG.EXE of RBBS-PC.
Run CONFIG and confirm use of RBBS-PC in a multinode environment. Assign
the number 1 Node to your SERVER.
1. Assign all welcome, bulletin, help and menu files to the SERVER's RAM
drive so the workstation may access them in the fastest way.
2. Store FILESEC, PASSWRDS, MESSAGES, USERS and other sensitive files in a
non-downloadable but sharable drive volume on the SERVER so the workstation
may have read/write access to them.
3. Select a location for the SERVER's CALLERS file and the WORKSTATION's.
4. Reflect the node numbers in the BATch file names, e.g. RCTTY1.BAT and
RCTTY2.BAT, RBBS1.BAT and RBBS2.BAT.
5. Choose PCNET as the environment that you are running RBBS-PC under.
Other Considerations--
VDISK or Extended memory, which is not-emulated memory, should not be used
on the SERVER but can be used on the Workstation. The network
configuration most likely to remain operating with very few problems is DOS
3.1, Orchid 3.0a PC NET software and CACHE.EXE version 2.2 and an
Expanded/Extended memory combination using the new Lotus/Intel/Microsoft
EMS memory boards.
Two nodes can be efficiently set up using the SERVER in non-dedicated mode
but the danger is that if the SERVER locks up, the whole system locks up.
The sample PC Net system is set up in this fashion but it is an economical
approach to a two node system which has been functioning quite well with
minimal problems. Do not run software on the SERVER that is known to cause
problems especially memory resident utilities. There is a potential for
files being CROSS-LINKED in any read/write sharable environment. Frequent
backups are to be very strongly recommended.
Because of wide variety of hardware combinations and possible network
permutations, the above is intended ONLY as general guidelines to be
followed when installing RBBS-PC on your Orchid network.
Rob Cecchino
SysOp, Computer Connection
(804) 481-1824 at 1200/2400 for assistance.
APPENDIX M -- RBBS-PC in an Alloy PC-SLAVE/16 Environment Page M-1
APPENDIX M -- RBBS-PC in an Alloy PC-SLAVE/16 Environment
---------------------------------------------------------
The PC-Slave is an IBM compatible computer on an expansion card
manufactured by Alloy Computer Products, Inc. of Framingham, MA 01701.
Their telephone number is (617) 875-6100. Adding PC-Slaves converts the PC
from a single CPU to a multiple CPU, all under the control of the main or
host PC. Each slave can run RBBS-PC (or other programs).
A. THE ADVANTAGES: Compared to other means for running multiple RBBS-PC's,
the advantages of slaves are:
1. SPEED -- Each copy of RBBS-PC has a dedicated computer and therefore
runs very fast compared to multi-tasking products like Multi-Link,
DesqView, or DoubleDOS.
2. SHARED FILES -- Each bulletin board can share files, including the users
and messages. The PC Slave system can act like Orchid's PC-Net network, or
a NetBIOS LAN for record locking.
3.EXPANDABILITY -- You can have up to 31 slaves. Adding an extra Slave is
simple, and does not degrade system performance. The power supply and
cooling capacity of a PC-2 or XT limit you to adding only 2 slaves. An AT
can have up to four. You can buy PC compatibles that have more expansion
slots. You can also get an expansion chassis designed for up to 12 Slaves.
4. COSTS -- It is far cheaper to expand using PC-Slave/16's than a network.
The PC-Slave lists for $900 and can be purchased for significantly less.
Other networks require not only a separate PC but also a "network" card of
some sort which puts the costs of each port well above $2,000.
5. DEDICATED PC IS NOT REQUIRED -- Your PC can remain free for you to use
while slaves run the bulletin boards (or run another copy of the bulletin
board). You do not degrade performance on the slaves, except for
contention for the hard disk and that can be mitigated by using disk
caching.
6. EASY SNOOP. Using Alloy utilities GIMME and VIEW, you can view the
session on any slave and attach your keyboard to it. You can also install
a dumb monitor to any slave.
B. THE DISADVANTAGES: The disadvantages of a slave system are:
1. COMPATIBILITY --Not all hard disks are compatible with the slaves. Hard
disks known to be compatible include the Seagates, Priam 60 meg, Bernoulli,
and Maxtor hard disks, as well as the Alloy line of hard disks. Hard disks
definitely not compatible include all models of US Design.
C. OVERVIEW OF SETTING UP A PC-SLAVE/16 RBBS-PC: Five easy steps on how to
install RBBS-PC in a PC-Slave/16 environment (Note that the PC Slave system
requires a special configuration for RBBS-PC):
STEP 1 -- If you want to allow simultaneous callers, you will have to
purchase multiple telephone lines. They can be made to roll so that only
one number is called, and if busy, the call will roll over to the other
lines.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page M-2
STEP 2 -- Install the slaves. Remember to set switches on the slave boards
that number them consecutively. See the PC-Slave documentation for
details.
STEP 3 -- Install the software. The Alloy PC-Slave has to have special
Alloy software called NTNX to coordinate the slaves and process requests
for shared resources. See the NTNX documentation for details.
STEP 4 -- Install a modem with no pin 22. Pin 22 used to be required with
RBBS-PC in order to answer the phone. On the slaves, pin 22 CANNOT be
connected, or else the slave will continuously reboot. However, newer
slaves support pin 22.
STEP 5 -- Configure RBBS-PC using CONFIG.EXE with the following parameters:
(a) use COM2 (parameter 221)
(b) Via parameter 29 tell RBBS-PC it is running on an IBM compatible
rather than a PC, XT, or AT. (Lie and tell RBBS-PC you have a Compaq
Plus.)
(c) Use CONFIG parameter 161 to set the maximum number of bulletin
boards to as many boards as you intend to install (rather than the number
you are currently running. This makes expansion easier.).
(d) PC-Net is the multi-user environment you will be running under
and should indicate so via CONFIG parameter 162.
(e) Set up the RBBS-PC files.
Read Appendix G for general considerations on running a multi-node RBBS-PC
system. Since all PC-Slaves have access to all hard drives, configuration
of files is quite simple.
Please note that the NTNX software is very vulnerable to any RAM resident
software. You should install the Slaves with no additional software
present and carefully test any resident software you want to run with it.
D. A DETAILED DESCRIPTION OF SETTING UP A PC-SLAVE 16 RBBS-PC:
Hardware Limitations:
1. Two PC/Slave 16 cards per XT box or four in an AT maximum otherwise
you'll be buying power supplies frequently. An expansion chassis for four
cards (Alloy Plus4) or expansion chassis for up to twelve cards will be
needed for bigger systems. Expansions boxes can be daisy-chained to up to
thirty one Nodes or workstations, if needed.
2. PC/Slave 16 cards do not support PIN 22 for Ring Detect. If PIN 22 is
connected, your slave will re-boot every time the phone rings!
3. No clock on the PC/Slave 16 card. The Slave gets the Time and date from
the main system clock. Each time you update the host clock, all the slaves
will update as well.
4. A terminal such as a Kimtron KT-7/PC or Alloy PCST is needed if you want
to work on a slave the same as you would on the host computer (but not if
you just want to view activity on slaves occasionally). Other terminals
will work but may not support all of the IBM extended graphics codes. For
a multi-node RBBS-PC, one terminal can be used with an A-B-C-D switching
box to 'dial in' to the node you wish to work with.
APPENDIX M -- RBBS-PC in an Alloy PC-SLAVE/16 Environment Page M-3
5. The Slaves' CPU [NEC V20 @ 8 MHz] shuts down when writing to the hard
disk. This creates problems with timeout errors on uploads. Upload
problems can be eliminated by using the write buffer option in NTNX 1.64 or
higher (/B). The problem can also be alleviated by using a fast hard drive
supported by Alloy. Also, the hard drive must be formatted with the most
efficient interleave setting and driver. Hard drives that work without
significant upload timeout errors have been formatted with either Golden
Bow's Vfeature Deluxe or Priam's formatting software; this problem is
especially noticeable on AT systems and not too much of a problem on small
XT systems. Seagate, Bernoulli Box, Maxtor, and Priam Inner Space drives
seem to work fine with the Alloy PC/Slave-16 cards.
Software Limitations:
1. ATNX runs Orchid PC Net applications but NTNX is more versatile and will
run applications for Novell's Advanced Netware, MS-Net, AND Orchid PC Net
with proper file locking. NTNX has had less problems with file corruption
and cross-linking than ATNX, according to SysOps using Alloy Slaves.
2. The slaves get the date/time from the host computer. Constant
processing can cause the host clock to drift. A utility to periodically
update your host computer clock is recommended. Also, WXMODEM does not
work in upload mode on Slaves due to a timing problem in the initial
handshake. Alloy's solution to this problem is a file called UPTIME.COM,
which is run on the HOST, but I have had very poor results with it. The
problem seems to be most identifiable on AT class machines.
For the optimum system flexibility you may want to buy Alloy PC/Slave-16N
cards which have the special PAL chip for NTNX/Novell compatibility and
NTNX software. RBBS-PC, however, will run fine without the PAL chip even
under NTNX.
Some nice additional utilities for the Slaves, including special
diagnostics, are found in the separate PC-Plus Advanced User's Kit and are
worth having. A single Kimtron KT-7/PC terminal or other smart terminal
may be obtained right away but is not necessary for the bulletin-board-only
system as one can always sign on from remote for answering mail; pay
special attention to the terminal-to-Slave cable as it is non-standard and
you'll probably wind up making it yourself for less than $5 in parts -- one
end is a male 9-pin D-shell and the other is 25-pin RS-232 male connector.
For a two to four node system, obtain a switch box to hook the terminal as
COMMON and Slave consoles. The computer to house the Slaves, called the
HOST, should be the quickest CPU speed that you can obtain. All PC
Slaves/16 should be purchased with 1 megabyte of onboard RAM.
Installation:
1. Format your hard drive with the DOS supported by the version of NTNX you
purchase (currently DOS 3.3).
2. Divide the hard drive into multiple volumes of standard DOS size (less
than 32 megabytes).
3. Install NTNX and the Slaves according to the Alloy manuals. Choose the
default settings for everything. Use 512K on the 1 megabyte PC/Slave for
caching and the other 512 to run RBBS. Depending on how the board is
configured, you may need to set switches so that 512 is used to run
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page M-4
applications. Use 4K for the Host PC caching. Allocate 25 files per each
Slave + 64 for the maximum number of open files.
4. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the HOST as follows
especially if you do not plan to use the HOST as a Node for RBBS-PC:
CONFIG.SYS
device=NX.SYS - NTNX driver (must be first!!)
device=hard_drv.sys - Your hard Disk driver
FCBS = 32,32 - File Control Blocks increased
buffers = 20 - DOS buffers
files = 32 - Number of OPEN files on HOST
device = ANSI.sys - Extended graphics driver
AUTOEXEC.BAT
NTNX - NTNX driver
fm 3 - Level of File protection
prompt $p$g - customized dos prompt
path = ........ - set path to the NTNX files
5. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the Slaves as follows:
CONFIG.U0x under DOS 3.3
FCBS = 32,32
buffers = 10
files = 30
device = ansi.sys
shell = C:\COMMAND.SLV C:\ /P /E:800
Of special note, the SHELL statement has been used to expand the
environment space on the Slaves. This corrects a problem seen with random
RBBS-PC lockups or getting Out of Memory errors; external protocols and
DOOR programs, given time, stop running due to memory problems if one
doesn't use this SHELL statement. Under DOS 3.1, set /E:50 [= 50
paragraphs] and under DOS 3.2 or 3.3, set /E:800 [= 800 bytes].
AUTOEXEC.U0x
fm 3
prompt $p$g
path = .......Set the path to the NTNX files and to the 'home'
directory for this node on the SHARED drives
SET NODE=x Tell this slave what node to run.
cd\RBBS0%NODE% Change to the RBBS-PC directory for this node
RBBS.BAT Invoke RBBS-PC for this node
The statement "SET NODE=x" allows you to write batch files that know what
node you are dealing with. All slaves can access the same RBBS.BAT file,
as long as you invoke RBBS-PC from within that file as:
RBBS-PC %NODE% RBBS%NODE%PC.DEF
Other node-specific commands should be done this way.
6. CONFIG parameters for the slaves, must be the following parameters:
Parameter 29 (Type of computer): Compaq Plus.
Parameter 224 (Number of rings to wait before answering): 0.
Parameter 162 (Environment): Orchid PC Net.
Parameter 221 (Communications port): 2.
Maximum number of users: at least as many slaves as you have, plus
one if you plan to run a node on the host. You can specify more (up to 36)
if you want to plan for expansion.
7. Set up RBBS-PC as follows:
Create subdirectories \RBBS01, \RBBS02, \RBBS0x... on a shared drive.
APPENDIX M -- RBBS-PC in an Alloy PC-SLAVE/16 Environment Page M-5
Create other subdirectories according to RBBS-PC documentation.
On a cached drive, place all static RBBS-PC files such as MENUs,
HELPs, PASSWRDS, TRASHCAN, external file transfer protocols. RBBS-PC.EXE
and CONFIG.EXE go here as well.
On the second SHARED drive, make a subdirectory \COMMON for MESSAGES,
USERS, CONFENCE, and conference message/user files.
If you plan to use DOORS, especially Bob Westcott's DOORWARE, create
a subdirectory called \DOORS on the SHARED drive.
Run CONFIG and create RBBSxPC.DEF files for all your nodes. Remember
that you will run multi-user under PC Net. The modem serial port on the
Slaves is COM2 and not COM1. Double-check file locations! Put your static
text files in the same subdir as MESSAGES and USERS and make it the default
subdirectory
Copy RBBS1PC.DEF to RBBSxPC.DEF for each node that you hope to have
then re-edit each .DEF file to customize Node numbers such as RCTTY1.BAT,
etc.
Copy the RBBSxPC.DEF file to the matching subdirectory. If you don't wish
to edit the .DEF files, place RBBSxPC.DEF on one shared drive and place the
dynamic RBBS-PC files on the other shared drive; be sure that you have at
least logged into that other SHARED drive's subdirectory, using the
AUTOEXEC.U0x before starting RBBS-PC or else RBBS-PC will not find those
files.
Temporary files used for transfer or Verbose file listing are created
on the default subdirectory automatically. You must assign a different
CALLERS file for each node located in the default directory.
To use SysOp Function 7 (Remote Drop to DOS), RBBS-PC must find
COMMAND.COM. PC-Slave/16's, however, use COMMAND.SLV as the command
processor; copy COMMAND.SLV to COMMAND.COM, place it on a cached drive, and
tell CONFIG where to find it. Be careful using this SysOp function with
the Slaves as you will lock up the Node if you lose carrier; WATCHDOG is
incompatible with the Slaves.
Additional tips/hints:
1. Avoid using any memory resident utilities. They may interfere with
Slave operation.
2. A program on the Advanced Utilities disk called SEE.COM allows callers
on any Node to be viewed from the HOST.
3. Norton's Editor or WordPerfect Corporation's Programmers Editor from the
WordPerfect Library is used for editing operations on the system,
especially for maintaining the fixed-length directory of the file
management system. Not many other editors, except EDLIN, can be used
reliably.
4. Easy to forget but don't as it will be a source of frustration -- plan
out your file locations on paper before actually setting up the system.
5. Backup your system frequently!
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page M-6
If you have any questions or problems, feel free to leave a message on Ken
Goosens system (703) 978-6360.
APPENDIX N -- RBBS-PC and 10 NET Network Page N-1
APPENDIX N -- RBBS-PC and 10 NET Network
----------------------------------------
Starting with RBBS-PC 15.1A support for Fox Research's' 10 Net Network is
being provided.
Since this is the first release with this support we have very little that
we can offer in tuning support for 10 NET.
We selected to use the Semaphore locking mechanism that we have used in the
other networks and therefore you must specify the following parameters on
the Superstation in your 10 NET network.
LOGINS=x 1 for every node on the system
OPENFILE=xxx 10 for every node running RBBS-PC
SHAREFIL=16 (This is the default you can add more if you want)
LOCKS=x 3
SEMA=xxx 3 for every node running RBBS-PC
You will also need to run NETSU and specify option 6 (DOS file sharing).
Please note that these values should be in addition to any parameters you
may have already specified for other User stations and other uses of your
10 NET network. And you can always make the values larger in attempting to
improve performance.
APPENDIX O -- Running RBBS-PC on a NETBIOS network Page O-1
APPENDIX O -- Running RBBS-PC on a NETBIOS network
--------------------------------------------------
CONFIG parameter 162 allows the SysOp to select an environment for running
multiple copies of RBBS-PC. One of the environments is "DOS SHARE," which
allows a large number of LANs to support RBBS-PC. Any LAN that is
"NetBIOS" compatible should allow RBBS-PC to run multiple nodes, since the
DOS SHARE utility is usually supported with all NetBIOS LANS. Operating
RBBS-PC on a network which supports the NETBIOS interface is therefore very
simple. Outlined step-by-step, the procedure is as follows:
1) Install and load your network software.
2) Configure RBBS-PC for the network environment.
3) Prepare files which are to be shared, but not written to.
Let's discuss these items in detail.
INSTALL AND LOAD YOUR NETWORK SOFTWARE
Obviously, for each different network, this procedure will change.
This manual doesn't attempt to replace or augment the documentation
which accompanied your network software. It only covers how to set up
RBBS-PC to work with a NETBIOS LAN. The assumption is made that you
can, and have, correctly installed your network.
However, so that you understand what we mean by "install and load", we
will present a generic description here. (It should be noted that
there are certain similarities between all NETBIOS LAN products.)
First, the "core" of the network software must be loaded after you
boot the machine (e.g. the NET START command). Next, any of your
computer's resources which others require access to must be "shared"
(e.g. the NET SHARE command). And finally, any resources which your
computer requires access to must be "used" (e.g. the NET USE command).
Please note that NET START, NET SHARE, and NET USE are all examples of
the commands used by the IBM PC LAN Program. Your actual commands
might be different.
CONFIGURE RBBS-PC FOR THE NETWORK ENVIRONMENT
Begin by running the RBBS-PC CONFIG utility. Set parameter 162 to
"6", which tells it that RBBS-PC is running on a NETBIOS LAN. (Please
check parameter 161 while you are there, also, and make sure that it
is correct for the number of nodes you intend to run.)
You will notice, when you select parameter 162, the reference to the
DOS utility SHARE.EXE. This utility must be loaded in order for a
NETBIOS LAN to function properly. The startup command for most
networks will cause SHARE.EXE to be loaded (i.e. when the NET START
command is issued, the network looks in the current path for SHARE.EXE
and loads it).
If, for some odd reason, your network does not automatically load
SHARE.EXE, you will need to perform this task manually in your
AUTOEXEC.BAT file (DOS 4.x users can opt for the "INSTALL=" option in
their CONFIG.SYS files).
PREPARE FILES WHICH ARE TO BE SHARED, BUT NOT WRITTEN TO
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page O-2
Once RBBS-PC is aware of the fact that you're running on a NETBIOS
LAN, it will open all of the files it intends to update in "shared"
mode. However, when RBBS-PC opens a file for READ access only, it
does NOT use DOS SHARE. This will on occasion cause sharing
violations when more than one node tries to read the same file at the
same time. To compensate for the problem, you should set the "read
only" attribute of any file which will NOT be updated during the
course of the call. Files such as WELCOME, PRELOG, all HELP, bulletin
and news files should be "read only."
(You change a file's read only status with the DOS utility ATTRIB.
The syntax is "ATTRIB +R (filename)." Please note that ATTRIB must be
located in the current search path, and the "+R" switch can be
reversed into "-R", when you want to remove a file's read only status
in order to edit it.)
We recommend setting the read only status on any file which you are
certain will not be updated (i.e. written back to).
SUMMARY
The hardest part about setting up RBBS-PC in a network environment is the
actual setup of the program for multi-node operation. But if you follow
certain guidelines (laid out for you in Appendix G), you should be fine.
APPENDIX P -- RBBS-PC and the IBM PCjr Page P-1
APPENDIX P -- RBBS-PC and the IBM PCjr
--------------------------------------
RBBS-PC adheres to the Hayes standards for autoanswer applications that are
described in Section 9, "Writing Programs for the Smartmodem 1200," of the
SMARTMODEM 1200 HARDWARE REFERENCE MANUAL. Under the section entitled
"Additional Program Considerations" Hayes recommends that autoanswer
applications (like RBBS-PC) "... force the modem to answer the call (ATA)
rather than allowing the modem to automatically answer...." Beginning
with 13.1A, RBBS-PC no longer REQUIRES the Ring Indicator signal from the
modem (pin 22) in order to answer the phone (except if parameter 224 of
CONFIG is non-zero).
Here are some facts about the PCjr:
1) The PCjr's external modem interface does not have a Ring Indicator
signal.
2) The PCjr requires that an external modem be opened as COM1 if no
internal modem is installed. However, if no internal modem exists the
PCjr requires that the COM2 RS-232 registers be used even though the
port has been opened as COM1. Technically this is described as using
the external RS-232 asynchronous adapter as logical channel 1 (i.e.
COM1) but manipulating it as physical channel 2 (i.e. COM2). This
occurs on a PCjr only when an internal modem is NOT present and the
external RS-232 interface is.
3) The 128K PCjr only provides 90K of usable RAM (the rest is used by
DOS, the monitor's buffers, etc.). Fortunately PCjr owners can get up
to 512K of RAM with "add-on" equipment (from IBM and others) in order
to have enough RAM for RBBS-PC to run in.
4) The standard PCjr supplied by IBM does not have a DMA and hence can't
do communications I/O simultaneously while doing disk I/O.
RBBS-PC beginning with version 13.1A will run an IBM PCjr providing that
the PCjr
1) Has at least 320K of memory.
2) Disk I/O does not occur simultaneously with communications I/O (i.e.
either you have a second disk drive with a DMA or you set BUFFERS=0).
3) One of the following three modem configurations are used:
- An internal PCjr modem with an external Hayes modem where the external
Hayes modem is used for RBBS-PC.
- No internal PCjr modem with an external Hayes modem used for RBBS-PC.
- Only an internal PCjr modem and it is used for RBBS-PC.
The following discusses each of these three modem configurations supported
by RBBS-PC with the PCjr.
Internal PCjr Modem With RBBS-PC Using External Hayes Modem
-----------------------------------------------------------
This configuration means that the PCjr had both a COM1 (the itnernal PCjr
modem) and a COM2 (the external Hayes modem). RBBS-PC is set to use COM2.
No changes are required to RBBS-PC for this type of configuration. CONFIG
parmameter 224 should be set to 0 to overcome the lack of a ring indicator
signal for the external communications port.
No Internal PCjr Modem with RBBS-PC Using Hayes External Modem
--------------------------------------------------------------
This configuration means that the PCjr has only one RS-232 interface -- the
external Hayes modem. This must be opened as COM1 but use COM2's registers
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page P-2
to control the communications port (believe it or not that's the way IBM
designed the PCjr).
CONFIG parameter 221 should be used to indicate that COM1 is being used.
Unfortunately the current BASIC compilers (both IBM's Version 2 and
Microsoft's QuickBASIC) are incapable of handling a communication port as
logical device 1 (i.e. COM1) but on physical channel 2 (i.e. the interrupts
are for COM2).
Should this ever be fixed by either IBM or Microsoft, CONFIG parameter 29
should be used to indicate that no internal PCjr modem is installed. This
tells CONFIG to make sure that COM2 registers are used to manipulate the
PCjr's external communications port.
Until this is fixed by the respective vendors, the PCjr user will have to
run a utility like COMSWAP that exchanges the pointers between COM1 and
COM2 within DOS.
In either case, CONFIG parameter 224 should be set to 0. This will cause
RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC
will wait for carrier detect. This is the way that RBBS-PC overcomes the
PCjr's lack of "ring-indicator" signal for the external communications
port. Again no changes to RBBS-PC are required for this type of PCjr
configuration.
Only An Internal PCjr Modem for RBBS-PC and NO External Hayes Modem
-------------------------------------------------------------------
RBBS 17.4 no longer supports the Novation, internal PCjr modem.
APPENDIX Q -- Using RBBS-PC to access ORACLE or dBASE Remotely Page Q-1
APPENDIX Q -- Using RBBS-PC to access ORACLE or dBASE Remotely
--------------------------------------------------------------
1. The Need for Data Base Services
A feature that has been long missing from PC based host communication
systems is the ability for SysOps to install customized data bases and let
callers run true interactive data base queries against them. Because data
base management is a major programming task, the most promising way to add
data base services is to use RBBS-PC's original and innovative "DOOR"
mechanism to exit RBBS-PC and have the remote user enter an existing data
base management program.
"DOORing" to a data base management program, however, is not as easy as one
might hope. The major problems stem from the fact that data base
management programs are never designed to work in this environment. This
is because:
1) Most programs write to the hardware for speed rather than use bios
calls, causing the "screen" output to appear on the host terminal
rather than on the caller's terminal.
2) Data base programs do not monitor for carrier. If carrier drops they
simply sit forever waiting for input rather than terminating.
3) Most use "full screen" rather than "line at a time", which usually
does not work properly on a remote terminal.
4) Security. Most data base programs have no way to limit what a user
can do. For example, they do not have a read-only mode, or the
ability to restrict a user to specific files or fields. Many let the
user issue dos commands inside them, which gives to call too much
power.
5) Difficulty in learning to use. A caller can hardly be expected to
know how to use a data base. Hence it must be possible to simplify
and control the user interface inside the data base package.
Progress has been made with two of the most popular PC data bases -- ORACLE
and dBASE.
Using dBASE "DOORS" with RBBS-PC
--------------------------------
db/LIB is a relatively new piece of software by AJS Publishing of North
Hollywood, CA that makes remote dBASE access possible. db/LIB is a set of
two assembled libraries which can be used to create/modify dBASE data
structures, create/update dBASE indices, and naturally manipulate the dBASE
records. These libraries also have many replacements for dBASE
functions/commands not easily replicated (i.e. IIF, RECNO(), DATE(),
RTRIM(), DELETED(), etc.) outside of the dBASE environment. db/LIB is also
available in a multi-user version.
db/LIB was designed to work with Microsoft Quick BASIC 4.0 and BASIC
Compiler 6.0 (there is a QB 2/3 version available directly from AJS
Publishing after you purchase db/LIB).
dBASE Remote Access Advantages/Disadvantages
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page Q-2
Combine db/LIB with any well written door skeleton (such as the very fine
skeleton) and you can have a true shareable remote database system. The
following section highlights some advantages and addresses the problems
concerning remote dBASE database access.
Advantages of using db/LIB and dBASE data bases:
1) Purchase of dBASE is not required. db/LIB can create modify and
maintain any dBASE structure. A program with db/LIB and downloaded by
a third party can give these same freedoms to a third party. Sample
programs with db/LIB demonstrate that most of dBASE's functions can be
replicated or substituted using db/LIB.
2) If dBASE (or any good clone) is owned, then the two work very well in
tandem. The programmers at Ashton-Tate didn't gain their reputation
for writing junkware. By owning dBASE, the user can download any
database structure and perform any data manipulation easily in a
familiar environment.
3) Full screen (ANSI) writes, security, carrier monitoring, error
trapping, are all handled by the door skeleton. Let database modules
run the database, and let the door modules run the door.
Disadvantages of using db/LIB and dBASE data bases:
1) Remote dBASE database access is not the same as accessing dBASE III
remotely. Creation of these DOORS requires knowledge of Quick BASIC,
some knowledge of data communications, and some knowledge of dBASE.
All end user requirements have to be anticipated, all cases covered,
and created in advance. Once the application is created, then user
need no little or nothing about any of the above.
2) Not all users can use ANSI commands for full screen editing. This
means that doors need to have a scrolling (terminal) type display
capability as a substitute for the normal full screen writes. In some
doors this will simply be impossible, preventing all users from
database access.
For those interested in dBASE-based on-line data base searches with
RBBS-PC, you might try writing Steven Kling at 4009 Utah Ave., Brentwood,
MD 20722. Steven is the author of BBS_BASE, USER_BASE and DoorBase.
BBS_BASE is a non-ANSI dBASE III demonstration DOOR that maintains a
database of Bulletin Board names, phone numbers, etc. This database can be
queried, added to, edited, and up to the minute reports can be generated.
The entire database with indices can be downloaded by the user for personal
use. This database is indexed and therefore can be queried either by name
or phone number. BBS_BASE was written only as a demonstration of using
RBBS-PC to access a data base remotely. USERBASE is a dBASE registration
door for RBBS-PC 15.1C and above. It comes in both ANSI and non-ANSI
versions and gives an automatic access upgrade capability to the SysOp at
his/her option.
Steven Kling and Michael Kelly are collaborating on DoorBase, which has
just been released, and this will give a SysOp the capability to place any
dBASE III database on-line, and will allow him/her to set up all the full
screen display features to his/her own specification. DoorBase has
multiple demonstration databases available including databases of
Congressmen, dBASE vendor support companies, and a national BBS listing.
APPENDIX Q -- Using RBBS-PC to access ORACLE or dBASE Remotely Page Q-3
Steven is also the SysOp of Technopeasants' EAST RBBS at (301)-927-4258
Brentwood, MD (PC Pursuitable) 24 Hours/ 2400 baud.
Michael is the SysOp of Technopeasants' WEST RBBS at (503)-257-7070
Portland, OR (PC Pursuitable) 24 Hours/ 2400 Baud.
Using ORACLE with RBBS-PC for On-line Data Base Access
------------------------------------------------------
Another database package that is able to be used as a "door" is ORACLE from
Oracle Corporation at One Oracle Parkway in Belmont, California 94002.
Their number is (800) 345-DBMS. ORACLE is a very promising solution to
providing remote data base services. Oracle addresses the problems
mentioned earlier as follows.
1) Screen writes. ORACLE can use ANSI sequences or bios calls. All
output appears perfectly normal on remote terminals through the CTTY
interface in RBBS-PC.
2) Monitor for carrier. Run WATCHDOG, which will reboot your system if
carrier drops.
3) Full screen mode. ORACLE uses only ANSI commands to control the users
screens. Callers whose remote communications package implements ANSI
support therefore see full screen writes exactly the same as local
users. FULL SCREEN WORKS!
4) Security. ORACLE has all the security you could ever want because it
was designed for multi-user systems.
5) Usability. ORACLE implements SQL, which is increasingly becoming an
industry standard that all major data base systems are supporting.
Of course, there are some problems using ORACLE in a way in which it was
never designed:
1) There is a problem getting the function keys to work properly
remotely.
2) The ability for a caller to use DOS commands needs to be disabled
within ORACLE.
3) Callers who do not know SQL need pre-structured queries and a menu
interface to be designed for them. ORACLE supports a full screen
interface but the user interface in ORACLE is not as programmable as
one would like.
For those interested in ORACLE-based on-line data base searches with
RBBS-PC, you might try writing John Prior at P.O. Box 56589, Harwood
Heights, IL 60656-0589. John is the SysOp of
SQLBBS at (312)-589-0508
Chicago, IL. (PC Pursuitable)
24 Hours/ 9600 baud Microcom MNP Level 6
The SQLBBS is a bulletin board system specializing in supporting relational
data base managers and making the power of SQL available to callers.
SQLBBS uses an RBBS-PC door to get into ORACLE. The SQLBBS has implemented
ORACLE to help manage the data processing for the National Council for
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page Q-4
Children's Rights (NCCR), and has several major data bases on-line of
general interest. People can contact John Prior, the SQLBBS SysOp, on
Compuserve, by mail, or by calling SQLBBS if they wish to see how ORACLE is
implemented, get the latest progress report, or share experiences
implementing relational systems. Here are details on the SQLBBS system and
how to reach it:
Modem: 9600 Baud Microcom MNP Level 6
BBS Number: 312/589-0508
Hours: 24 hrs/day
Address: Prior Computer Service Inc.
POB 56589
Chicago IL 60656-0589
Compuserve ID: 76266,1072
SysOps: John F. Prior
Bernadette Foley
SQL Tables Roster of the House of Representatives
Available Roster of the Senate [both with addresses etc.]
Now The States [2 char abbreviation and full name]
All the 5 digit zip codes in the US
Call SQLBBS as you would any other RBBS-PC system. Go through the Door.
SQLBBS executes a "SELECT * FROM TAB;" for you which shows you the 50+
tables you can access. At the SQL> prompt execute any SELECT command you
want against any one of the tables.
"SELECT * FROM STATES;" returns all rows [records]
of the STATES table.
"SELECT * FROM STATES WHERE ST = 'MA';" returns all rows about the
state whose two-character
code is "MA".
"SELECT COUNT(*) FROM STATES;" gives you a count of the rows
in the STATES table.
If you substitute another table or view instead of STATES such as SENATE,
you can access other tables/views.
"DESC HOUSE" would return the column names of the HOUSE
table.
"HELP" gets you help.
"HELP SELECT" gets you help on the SELECT command.
"HELP SET" gets you help on the SET command
which can control many options for
display
"SHOW ALL" shows you everything you can SET.
"EXIT" terminates UFI and returns you to
RBBS-PC.
APPENDIX R -- Using RBBS-PC with SEAdog to Access FIDO-NET Page R-1
APPENDIX R -- Using RBBS-PC with SEAdog to Access FIDO-NET
----------------------------------------------------------
SEAdog is a full-featured electronic mail system based on the personal
computer and using standard telephone lines. It is a sophisticated store-
and-forward mail system which can be configured in a virtually unlimited
number of network topologies (more on this later). Unlike some network
systems, the end user need never concern himself with network routing -- it
all happens automatically. The user just submits and retrieves messages,
the system takes care of the details. The hardware needed to run RBBS-PC
is sufficient to run SEADOG.
SEAdog uses the FidoNet Electronic Mail Protocol, as defined in the
document, A Basic FidoNet Technical Standard, published by the
International FidoNet Association (IFNA). The FidoNet Protocol is a public
domain electronic mail standard originally developed by Tom Jennings for
the Fido bulletin board system. For more information about the FidoNet
Protocol, please write to:
The International FidoNet Association
P.O. Box 41143
St. Louis, Missouri 63141
United States of America
There are several advantages to using the FidoNet Protocol, not the least
of which is that a great many utilities and programs are available from
many different vendors for doing various things with electronic mail.
Please contact IFNA at the above address for more information.
The heart of SEAdog is the network mail server, MAILER.EXE. This is the
program that places and receives phone calls, handles message routing, and
so forth. It is left running when you would normally turn your machine
off.
You can set RBBS-PC to drop to DOS at a time when telephone costs are
cheapest (normally 4 a.m. Eastern Standard time and 1 a.m. Pacific time)
and invoke the mailer so that it begins placing phone calls to other SEAdog
systems to pass them your outgoing mail and receive your incoming mail.
SEAdog costs $100.00 and can be ordered from the address or phone number
below.
Thom Henderson
SYSTEM ENCHANCEMENT ASSOCIATES
21 Wayne Street
Wayne, New Jersey 07470
V:201-473-5153
This doc file is not intended to replace the SEAdog manual, but rather
provide information that an RBBS-PC SysOp would find useful when
configuring RBBS-PC to run with SEAdog.
The current status of the RBBS-PC - SEAdog project is at the level in which
RBBS-PC has the ability to be front-ended by SEAdog in where SEAdog will
turn over to it a live, active modem with a caller waiting. RBBS-PC has
been modified to accept two additional command line parameters which can
alter the defaults in RBBS-PC.DEF. Currently, that is the extent to which
RBBS-PC and SEAdog can be used together. The Fido message base format is
not yet compatible with RBBS-PC.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page R-2
It is assumed that you are reading this because you are familiar with the
RBBS-PC and have at least a minimum knowledge of FidoNet and FidoMail.
Another assumption is that you have RBBS-PC up and running on your
computer. The easiest way to get all two programs working together is to
have each running from it's own subdirectory on your hard disk. That'll
make maintenance of RBBS-PC and SEAdog specific files much easier. Follow
the instructions in the SEAdog manual to install it, if that hasn't been
done yet. Once installed all SEAdog files will be in a subdirectory called
\MAIL. Make any required modifications to your CONFIG.SYS as suggested in
the SEAdog manual.
If your using DOS 3.xx, and don't use the DOS SUBST command, you should
consider doing so. SUBST is a DOS external command that allows you to
SUBSTitute a drive letter for a complete subdirectory name. Using this
command will make reprogramming RBBS-PC's configuration file easier.
This appendix assumes that all the SEAdog Files are in a subdirectory
called C:\MAIL and those for RBBS-PC are in a directory called C:\RBBS.
A further assumption that is made is that a new drive "H:" will be
SUBSTitued for the C:\RBBS subdirectory.
Since SEAdog will be in controls most of the time, the entire operation
should use SEAdog's C:\MAIL directory as the default.
Now load and run CONFIG.EXE and reprogram it's configuration to reflect
that all RBBS's help, menu and system files are located on the "H:" drive.
Remember the SUBSTitute command? You can use it to replace those long
subdirectory names for download and upload files. SPECIAL ATTENTION must
be paid to CONFIG.EXE's parameter 163. This parameter MUST be set to SYSTEM
recycle. Not doing so will cause RBBS-PC to reload itself after a caller
has hung up or dropped carrier and not pass control back to SEAdog.
The SEAdog manual explains various commands that must be placed in it's
configuration file called CONFIG.DOG. Among those that are considered a
minimum, you should include at least the following....
banner Please stby, 15 secs to load RBBS-PC
bbs H:RBBS *T *B
event B all 4:30 5:00 ;Local collections
event A all 5:00 6:00 ;National FidoMail Window
event C all 6:00 7:00 ;Local distributions
event S all 7:00 4:00 Crash Dynamic BBS ;CRASH mail if not in RBBS
event X10 all 7:00 7:05 ;Reboot Computer
The banner statement should be used so that human callers know why there
is a delay from the time they connect until the time they see RBBS-PC
display it's welcome message. The bbs command tells SEAdog what batch
file to run when passing control to RBBS. *T and *B must be in the order
presented above in for RBBS-PC to pickup and use them correctly. They pass
the time remaining to the next scheduled SEAdog event and the baud rate the
caller came on with. Event statements tell SEAdog how to schedule it's
time during the day. The above example conforms to the FidoNet national
mails hours as of 26 July 1987 and allows crash mail and bbs operation at
all others.
Since the SEAdog *P parameter in the bbs command isn't used, you must
insure that the comm ports used for RBBS-PC and SEAdog are the same.
APPENDIX R -- Using RBBS-PC with SEAdog to Access FIDO-NET Page R-3
One of the more confusing decisions will be how to setup the modem
switches. Without going into it too deeply, keep in mind that SEAdog will
be controlling the modem and passing an active modem on to RBBS-PC.
Additionally, you could have your SEAdog upload and download areas overlap
those of RBBS-PC.
When SEAdog determines that a non SEAdog or Fido system has called, it runs
a second copy of DOS, then optionally loads and runs RBBS-PC via direct
command or from a batch file, passing the speed that the comm port was
opened at, and the time remaining to the next scheduled SEAdog mailer event
as in the following example:
SEAdog calls RBBS-PC via a batch file called RBBS.BAT
C>RBBS-PC 1 H:RBBS-PC.DEF /%1 /%2
| | | | |> Baud Rate
| | | |
| | | |
| | | |> Limits the amount of time the user has
| | | this session if and only if the time is
| | |less then the time per session specified |||in CONFIG.EXE.
| | |> RBBS-PC default file filespec (Optional)
| |> Node number that the specified .DEF file applies to.
| |(Optional)
|> The name of the RBBS-PC program.
With a properly configured RBBS.BAT batch file, you can retain all the
functions of RBBS-PC to include DOORS and dropping to DOS via SysOp
function #7. See the sample batch files at the end of this file.
Experience has shown that the best way to run RBBS-PC and SEAdog is with a
batch file, where SEAdog having determined that a non mailer system is
waiting to use the bbs will load and run a batch file that controls RBBS-
PC's operation as opposed to SEAdog calling RBBS-PC directly. Two batch
files are used, one to control SEAdog and one to control RBBS.
A minimum batch file is suggested in the SEAdog manual. In addition to what
ever you place in it, add the following statements to it.
If Exist H:RCTTY.BAT Del H:RCTTY.BAT
This line should be the first. This statement simply helps ensure proper
operation of RBBS-PC if you use SysOp function #7 or DOORS.
If Errorlevel 10 Goto REBOOT:
This line goes after the line that contains the call to the MAILER program.
REBOOT:
IPL
This line reboots the computer every morning according to event listed
above. Due do unexplained loss of memory when running SEAdog and RBBS-PC,
is safe to program in a scheduled rebooting of the computer to regain any
loss of memory. This line should be near the last and programmed around for
normal operations
** Ex RBBS batch file **
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page R-4
Echo Off
:LOOP
C:
Cd \MAIL
If Not Exist H:RCTTY.BAT Goto LOCAL
H:WATCHDG1 OFF
Del H:RCTTY.BAT
H:TESTRBBS 1 H:RBBS-PC.DEF
Goto REMOTE
:LOCAL
H:TESTRBBS 1 H:RBBS-PC.DEF /%1 /%2
:REMOTE
If Not Exist H:RCTTY.BAT GOTO EXIT
H:WATCHDG1 ON
H:RCTTY.BAT
:EXIT
As mentioned above, this doc file isn't intended to make you completely
knowledgeable on how to interface RBBS-PC and SEAdog, only get you started.
How you set up your RBBS-PC and SEAdog batch files is limited only by your
ability and imagination. After gaining more experience, you'll find that
you can automate a lot of the RBBS-PC and SEAdog maintenance.
The above reflects the creative things that Kim Wells accomplished.
APPENDIX S -- DOS Limitation on Running Programs Remotely Page S-1
APPENDIX S -- DOS Limitation on Running Programs Remotely
---------------------------------------------------------
When accessing your PC via a communications port, the carrier detect signal
tells the PC that you are on-line. DOS's major limitation is that there is
no way to tell DOS to monitor carrier detect automatically when the
standard input and output is transferred to a communication port (i.e. via
the CTTY command). RBBS-PC makes sure that the carrier is not dropped
when a user exits to DOS either via the "DOORS" option or using the remote
SysOp function 7. However, it is the SysOp's responsibility to insure
that whatever programs are invoked after leaving RBBS-PC perform all
the necessary functions to maintain the communications session and, when
exiting to return to RBBS-PC, that the carrier is "NOT" dropped.
Most application programs (i.e. databases, etc.) are not designed to be
controlled by users accessing them from a communications port. This
problem is solved when a function is invoked that:
1. Checks to see if the standard input and output console have been
assigned to an auxiliary console such as a communication port.
2. If condition 1 is true, checks to see if the carrier detect signal is
lost by intercepting each interrupt from the communication port the
auxiliary console has been assigned to.
3. If BOTH conditions 1 and 2 are true, this function would cause DOS to
return to the standard screen and keyboard for its operations AND continue
processing whatever batch file that had been executing.
Such a function (or device driver) would provide a "fail safe" feature that
would allow users to exit RBBS-PC to use whatever other software the
SysOp chose to make available (i.e. relational databases for complex
inquiries -- bibliographic, sports, games, etc.). For those
anticipating using RBBS-PC's "doors" or exiting to DOS when you are a
remote SysOp, you are strongly encouraged to consider using the "watchdog"
utility program available on many bulletin board systems under such file
names as WATCHDOG.COM, WATCHDOG.ASM, WATCHDOG.DOC, WATCHDOG.EXE that
monitors the communication port for you and reboots your system if carrier
drops. If you don't use a program like WATCHDOG and accidentally hang up
while in a "door" or in DOS, you system will remain "hung" until you can
manually reboot it.
Programs that utilize the PC's built in video memory (such as the IBM BASIC
interpreter or WordStar when it writes to the 25th line) need to have such
I/O redirected in a special way to a remote users terminal. Additionally,
if the I/O is redirected to the communications port, the terminal on the
other end must have a "cursor" that can be sent the appropriate command
sequence to move it around on the remote users terminal as necessary.
Without this capability, programs made available through "doors" must be
line-at-a-time programs. This of course excludes programs such as
WordStar, Lotus/123 etc.
If you aren't technically inclined and want to use RBBS-PC "doors", I
suggest you consider only using programs that have been explicitly written
to overcome the above two DOS limitations. Applications that don't write
directly to the video memory of the PC can be used safely as a "door" as
long as a "watchdog" type program is also used.
APPENDIX T -- Recompiling RBBS-PC to Reduce Memory Required Page T-1
APPENDIX T -- Recompiling RBBS-PC to Reduce Memory Required
-----------------------------------------------------------
RBBS-PC is continually being enhanced with new features. As new functions
and capabilities are added, RBBS-PC's memory requirements grow
correspondingly. In order to continue RBBS-PC's growth and still meet the
memory constraints imposed on SysOps with only 640K of memory who wish to
run two copies of RBBS-PC, RBBS-PC source code can be "mite-sized" and
recompiled to fit within whatever memory constraints a SysOp must deal
with.
SysOps can apply .MRG files against the unmodified RBBS-PC source code and
elect to eliminate RBBS-PC features not being used and eliminate redundant
code (typically the BASIC source code that replicates assembly language
routines). RBBS-PC has a companion "mite-size" set of files contained in
the file RBBS-LIT.ZIP.
In order to recompile and "mite-size" RBBS-PC, within the same environment
in which the SysOp has successfully recompiled the current release of RBBS-
PC, the SysOp must also have the following files:
BLED.EXE -- The Batch Line EDitor by Ken Goosens (version 2.2 or
greater).
MAKELIT.BAT -- The BATch file that invokes BLED.EXE and applies the
necessary files to the unmodified source code. This
file should be modified by putting in the drive/path
for the original code (the first parm to BLED). The
lines to be modified all begin with "*$", which is the
default for a BLED metacommand. The lines beginning
with "* " are BLED comments, which are ignored in a
merge.
SETLIT.INC -- The file through which the SysOp selects the RBBS-PC
features that are not needed. The directions for doing
this are contained within this file. A feature is
typically removed by setting a BLED metacommand
variable to "OFF", e.g. to exclude RBBS-PC LIBRARY
subsystem set LIBRARY to "OFF".
RBBSLIT.MRG -- The fundamental BLED merge for RBBS-PC.BAS
SUBxLIT.MRG -- The fundamental BLED merge for various RBBSSUB's. Each
reads in (includes) the file SETLIT.INC to set the
metavariables used by BLED. BLED then uses the values
to determines what merges to process.
*.LIT -- .MRG files that eliminate RBBS-PC features.
The procedure for "mite-size"ing RBBS-PC is as follows:
1. Select the RBBS-PC features not required for your needs and modify the
file SETLIT.INC.
2. Change MAKELIT.BAT to reflect your PC's subdirectories.
3. Make sure RBBSSUB1.BAS is in the subdirectory you will run in.
4. Execute the MAKELIT.BAT file. Do not continue if errors are found.
RBBS-PC 17.4 TECHNICAL REFERENCE MANUAL Page T-2
5. Recompile the "mite-sized" RBBS-PC source code. Remember, this "mite-
sized" source code and the RBBS-PC.EXE file created from it my only be used
by you and not distributed to others.
Some comments on the various Microsoft QuickBASIC compilers:
QuickBASIC Version 1.02 produces the smallest code.
QuickBASIC Version 2.01 produces the next smallest code.
QuickBASIC Version 3.00 produces the largest code.
QuickBASIC Version 4.5 produces code smaller than
3.00) but is not as reliable
Never LINK with the /E option.
6. Re-run CONFIG and disable the RBBS-PC features that were deleted in the
"mite-sized" version that was created in steps 1 through 5 (i.e. take out
the "A" command if questionnaires were disabled).
Please realize that there is no way that the "mite-sized" variations of
RBBS-PC can be supported. The many different PC configurations plus the
multitude of combinations of RBBS-PC features are what make this
impossible. However, we will do our best.
Please report any problems with BLED or the *.LIT merges to Ken Goosens via
his RBBS-PC data number -- (703) 978-6360.
INDEX.MRG 1-4
99.DIR 6-5
ANSI 7-25
ANSI commands 7-21
ARCWORK?.DEF 6-4
ASCII upload 10-26
AUTOEXEC.BAT 13-1
AUTOPAGE.DEF 6-6, 7-26, 10-3
BLED 1-4
BULLET file 6-6
Bulletins
BULLET.FCK 6-4
CALLERS file 6-4, 10-11
Colorization 7-24
COMMENTS file 6-4, 10-11
CONFENCE file 6-6, 10-9
CONFMAIL.DEF 6-7, 10-12
CPCUG 1-1
DIR.CAT 10-22, 12-6
DIR.CDR 6-7
DIR.DIR 6-7
DK*.ARC 6-5
DOORS.DEF 6-5, 10-13, 14-4
DORINFO?.DEF 6-5
DOUT?.DEF 6-5
DRST?.DEF 6-5
DTR 10-24
EPILOG.DEF 6-7, 7-29, 10-11
FFS 10-26
File Locking 6-1
FILESEC file 6-7, 10-15
Flow control
CTS 10-25
RTS 10-25
XON/XOFF 10-25
FMS 10-21
use of color in 7-25
Graphics 6-6
HELP files 6-7
FILE.HLP 6-8
HELP03 6-7
HELP04 6-7
HELP09 6-7
LIBR.HLP 6-8
MAIN.HLP 6-8
RGXPIRD.HLP 6-8, 9-1, 10-6
RGXPIRE.HLP 6-8, 9-1, 10-6
SECVIO.HLP 6-8
SMARTTXT.HLP 6-8
UPCAT.HLP 6-8, 10-9
UTIL.HLP 6-8
LG*.DEF 6-8
Library Sub-System 6-7
MAIN.PUI 6-9, 10-9
MAINM.DEF 6-3
MAINU.DEF 6-4
MENU files 6-9, 7-1, 10-9
MESSAGES file 6-3, 10-11, 10-18
NETBIOS P-1
NEWUSER file 6-9, 10-9
INDEXNODE?WRK 6-5
NODE?WRK file 7-27
PASSWRDS file 6-9, 9-2, 10-16
PRELOG file 6-9, 10-11
PRIV.DEF 6-9, 10-15
PROTO.DEF 6-3, 10-24, 20-1
PUI 7-4
use of color in 7-24
QMXFER.ERR 6-5
Questionnaires 6-2, 10-9, 19-1
RBBS.BAT 10-12, 13-1
RBBS?F1.DEF 6-5
RBBS?PC.DEF 6-5
RBBS-CDR.DEF 6-9
RBBS-Net 4-1
RBBS-PC in a Box 4-1
RBBS-REG.DEF 6-9, 10-11
RECONFIG.EXE 2-4
RelayNet 4-1
Ring-Back 10-23, E-1
SECVIO.HLP 10-17
SHARE.EXE P-1
SIGOp 10-17
SmartText 7-21
Subscriptions 9-1, 10-6
SysOp 1-1
TDD 10-23, 10-26, E-1
templates 20-4
in DOORs 14-4
TRASHCAN file 6-9, 10-10
USERS file 6-4, 10-11, 10-18
Userware 1-1
Version numbers 1-4
WELCOME file 6-9, 10-9
ZIPTV 7-28
================= END OF RBBS-PC 17.4 DOCUMENTATION ==================
INDEX
Editor's notes:
Formatting this document was a chore. Word Perfect is good, but there are
a lot of features either missing or not working in WP 5.1. I have reported
all my findings to WPC, so we can only hope their next release will help us
out. Until then, this document is "fragile" Take a good look at some of
the format codes before you start modifying. These notes should help you.
The Table of Contents is automatic. The chapter numbers all use WP's
"paragraph numbering" system. Top level chapters (section 1, INTRODUCTION,
for example) are level 1 paragraphs, and so on. So, to create a Table of
contents entry, I put the Paragraph number INSIDE the TOC block for each
entry.
Headers are not so automatic. Since we want the chapter number on the page
headers, and headers aren't smart enough to do this, the headers had to be
done by hand. In general, header A is just the title of the document, and
it is printed on even pages. Header B contains the current section, and it
is on odd pages. If you move a chapter, you must remember to re-do the
header for that chapter.
Page numbers cannot appear in headers. That's because WP doesn't honor the
page numbering style in headers (bug!). I just let WP number the pages
outside the header, all we have to do is keep the header off the right
margin.
Page numbering is also not automatic. It would have been great if I could
tell WP to use the current Paragraph major number in the page number (so
the first page of chapter 1 would be 1-1), but WP can't do that. Instead,
I manually inserted page number style codes at the beginning of each
chapter. This is one more thing you have to remember when moving a
chapter.
If you study the codes at the start of each chapter, you'll see what has to
be done. Nothing too tricky, but use care.
The INDEX is another story - everything is automatic, and works just fine.
OK, so I did make a double column index by hand, but I'm sure WP could do
that if I tried. I do NOT want to have an index wordlist - I know WP can
do that automatically, but I want all index entries to be MEANINGFUL! If
anyone wants to mark additional index entries, I'd love it - just make sure
that if you mark something, it's because the term is used in a VERY
MEANINGFUL way on that page. Also remember to look up any previous index
entry - you may find that you will want to put your entry in a subheading
to match what was done before.
I have tried to use WP's XREF capability to the fullest. One feature
missing from WP is the ability to LIST the references already defined. So,
before it gets out of hand, here is a current list:
XREF TAG Page Section
AUTOPAGE 7-26 7.11
BAT 13-1 13
BULLET 7-28 7.13
CD ROM 12-7 12.6
COLORIZING 7-24 7.10
COMMANDS AVAILABLE 7-1 7.3
CONFERERNCE FILES 17-4 17.4
INDEXCONFERENCE SETUP17-417.3
CONFERENCES 17-1 17
CONFIG 10-1 10
CONFMAIL 18-1 18
CONTRIBUTIONS 1-1 1.3
DATA BASE MACROS 7-19 7.8.4
DIR.CAT 12-6 12.5
DIR.DIR 12-1 12.1
DIRECTORY STRUCTURE 6-2 6.1
DOOR SETUP 14-1 14.1
DOORS 14-1 14
DOORS.DEF 14-4 14.3
DORINFO 14-3 14.2.2
FFS 12-15 12.9
FILESEC 15-5 15.4
FMS 12-1 12
FMS ADVANTAGES 12-3 12.3
GRAPHICS 6-6 6.3
HISTORY 26-1 26
IMPLEMENT PUI 7-5 7.6.2
INDIVIDUATION 8-1 8
MACROS 7-10 7.8
MERGES 1-4 1.4
MODEM 11-1 11
PASSWRDS 15-3 15.3
PERSONAL DOWNLOADS 12-10 12.7
PHILOSOPHY 1-1 1.1
PROTO.DEF 20-1 20.1
PROTOCOL DRIVERS 20-1 20
PUI 7-4 7.6
QUESTIONNAIRE 19-1 19
SECURITY EXAMPLE 15-2 15.2
SINGLE COMMAND LINE 7-2 7.5
SMART TEXT 7-21 7.9
SUB MENUS 7-8 7.7
SUBSCRIPTIONS 9-1 9
SYSOP FUNCTIONS 16-1 16
SYSTEM FILES 6-3 6.2
TEMPLATES 20-4 20.2
TEXT FILES 6-6 6.4
USER SUPPORT 4-1 4.1
The Appendix is also cross-referenced, as follows:
XREF TAG PAGE APPENDIX
APPENDIX 10NET O-1 O
APPENDIX 9PIN F-1 F
APPENDIX ALLOY N-1 N
APPENDIX CORVUS L-1 L
APPENDIX DBASE R-1 R
APPENDIX DEAF E-1 E
APPENDIX DESQVIEW I-1 I
APPENDIX DOUBLEDOS J-1 J
APPENDIX FORMATS A-1 A
APPENDIX NETBIOS P-1 O
APPENDIX LIT U-1 U
APPENDIX MODEMS D-1 D
APPENDIX MULTI NODE H-1 G
APPENDIX MULTILINK K-1 K
APPENDIX PCJR Q-1 Q
INDEXAPPENDIX PCNETM-1M
APPENDIX QB PATCH G-1 G
APPENDIX REGISTER B-1 B
APPENDIX REMOTE T-1 T
APPENDIX SEADOG S-1 S
APPENDIX SUBSCRIPTION C-1 C
If you need to reference a section of appendix, use the XREF function
instead of hard-coded numbers.
If you have any questions, PLEASE give me a call!
Doug Azzarito,
Reluctant WP 5.1 expert