home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
RBBS in a Box Volume 1 #3.1
/
RBBSIABOX31.cdr
/
rbbs
/
doc
/
rbbsdoc1.asc
< prev
next >
Wrap
Text File
|
1990-08-26
|
362KB
|
6,957 lines
REMOTE BULLETIN BOARD SYSTEM
for the
Personal Computer
Version 17.3A
Technical Reference Guide
Technical Support Numbers
(407) 627-6969 (data)
(407) 627-9767 (voice)
(read section 4.1 before calling voice line)
Copyright 1983-1990
by
D. Thomas Mack
39 Cranbury Drive
Trumbull, Connecticut 06611
DATA #1 -- (203) 268-5315
Ken Goosens
5020 Portsmouth Road
Fairfax, Virginia 22032
DATA #1,2,3 -- (703) 978-6360
Doug Azzarito
5480 Eagle Lake Drive
Palm Beach Gardens, Florida 33418
DATA #1 -- (407) 627-6969
#2 -- (407) 627-6862
August 26, 1990
RBBS-PC 17.3A TABLE OF CONTENTS 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 17.3A? . . . . . . . . . . . . . . . . . . . . . 2-4
2.3 Upgrading To 17.3A . . . . . . . . . . . . . . . . . . . . . . 2-7
2.4 Common Problems Encountered Installing RBBS-PC . . . . . . . . 2-9
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-2
Professional Tech Support . . . . . . . . . . . . . . . . . . 4-3
4.2 RBBS-PC's Vendor Support Policy . . . . . . . . . . . . . . . 4-3
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-6
6.4 RBBS-PC Text Files . . . . . . . . . . . . . . . . . . . . . . 6-6
7. PLANNING YOUR USER INTERFACE . . . . . . . . . . . . . . . . . . . . 7-1
7.1 Menus Shown to Callers . . . . . . . . . . . . . . . . . . . . 7-1
7.2 Subsystem Prompts Shown to Callers . . . . . . . . . . . . . . 7-1
7.3 Commands Available to Callers . . . . . . . . . . . . . . . . 7-1
7.4 RBBS-PC's "Wrap-around" Command Search . . . . . . . . . . . . 7-2
7.5 How to Have a Single Universal Command Line . . . . . . . . . 7-2
7.6 RBBS-PC'S Programmable User Interface (PUI) . . . . . . . . . 7-4
7.6.1 An Example Using PUI . . . . . . . . . . . . . . . . . 7-5
7.6.2 How to Implement PUI . . . . . . . . . . . . . . . . . 7-5
7.7 RBBS-PC's Support of Sub-menus . . . . . . . . . . . . . . . . 7-8
7.7.1 How to Implement Sub-menus . . . . . . . . . . . . . . 7-9
7.7.2 Shared Options Across Sub-menus . . . . . . . . . . . 7-10
7.8 RBBS-PC's "Macro" Command Support . . . . . . . . . . . . . 7-10
7.8.1 How to Set Up "Macros" . . . . . . . . . . . . . . . 7-12
7.8.2 Macro Commands . . . . . . . . . . . . . . . . . . . 7-13
7.8.3 A Sample Macro . . . . . . . . . . . . . . . . . . . 7-18
7.8.4 On-line Data Base With Macros & Questionnaires . . . 7-19
7.9 RBBS-PC's "SmartText" Variables . . . . . . . . . . . . . . 7-21
7.10 "Colorizing" the RBBS-PC User Interface . . . . . . . . . . 7-24
7.11 RBBS-PC's Automatic Operator Page Option . . . . . . . . . 7-26
7.12 Enhancing the File View Function . . . . . . . . . . . . . 7-27
RBBS-PC 17.3A TABLE OF CONTENTS ii
7.13 Bulletins and News . . . . . . . . . . . . . . . . . . . . 7-28
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
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-12
10.7 Parameters for RBBS-PC's Security (part 1) . . . . . . . . 10-13
10.8 Parameters for RBBS-PC's Security (part 2) . . . . . . . . 10-15
10.9 Parameters for Multiple RBBS-PC's/Conferences . . . . . . . 10-17
10.10 RBBS-PC SysOp Utilities . . . . . . . . . . . . . . . . . 10-19
10.11 RBBS-PC's File Management System Parameters . . . . . . . 10-20
10.12 Communications Parameters (part 1) . . . . . . . . . . . . 10-22
10.13 Communications Parameters (part 2) . . . . . . . . . . . . 10-25
10.14 Parameters for RBBS-PC NET-MAIL . . . . . . . . . . . . . 10-25
10.15 New Users Parameters . . . . . . . . . . . . . . . . . . . 10-27
10.16 Use of the Library Sub-System . . . . . . . . . . . . . . 10-27
10.17 RBBS-PC's Parameters for Color . . . . . . . . . . . . . . 10-28
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 Single and Chained FMS Directory Format . . . . . . . . 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-6
12.6 The "Library" Subsystem, CD-ROM, and FMS . . . . . . . . . 12-7
12.6.1 How the "Library" Subsystem Works . . . . . . . . . 12-9
12.6.2 The "Library" Subsystem and PC-SIG's CD-ROM . . . . 12-10
12.7 Creating the Personal Files Directory . . . . . . . . . . . 12-10
12.8 Automatically Checking & Converting Uploaded Files . . . . 12-14
12.9 Fast File Search . . . . . . . . . . . . . . . . . . . . . 12-15
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
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
RBBS-PC 17.3A TABLE OF CONTENTS iii
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
18. CALLERS AUTOMATIC NOTIFICATIONS OF MAIL 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-4
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-5
20.4 The Protocol Drivers Tested With RBBS-PC . . . . . . . . . 20-6
21. UPLOADED FILE TIPS . . . . . . . . . . . . . . . . . . . . . . . 21-1
22. DUE WARNING AND SYSOP'S LEGAL LIABILITY . . . . . . . . . . . . . 22-1
23. COMPILING AND LINKING RBBS-PC . . . . . . . . . . . . . . . . . . 23-1
24. LIMITED LICENSE . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
25. LIMITED WARRANTY . . . . . . . . . . . . . . . . . . . . . . . . 25-1
26. THE HISTORY BEHIND RBBS-PC . . . . . . . . . . . . . . . . . . . 26-1
27. PROPOSED RBBS-PC SYSOP CONFERENCE . . . . . . . . . . . . . . . . 27-1
28. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD . . . . . . . . 28-1
APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
APPENDIX A -- RBBS-PC Record Formats . . . . . . . . . . . . . . . A-1
RBBS-PC 17.3A TABLE OF CONTENTS iv
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
Ark-Paradyne . . . . . . . . . . . . . . . . . . . . . . . . D-1
Everex Evercom 2400 . . . . . . . . . . . . . . . . . . . . . D-3
FASTCOMM 2496 Turbo Modem . . . . . . . . . . . . . . . . . . D-4
Leading Edge Series L 2400B Modem . . . . . . . . . . . . . . D-6
MICROCOM AX\9624c . . . . . . . . . . . . . . . . . . . . . . D-6
Prometheus 2400G . . . . . . . . . . . . . . . . . . . . . . D-7
USRobotics Courier and HST . . . . . . . . . . . . . . . . . D-7
USRobotics HST Dual Standard . . . . . . . . . . . . . . . . D-9
ZOOM Modem HC2400 . . . . . . . . . . . . . . . . . . . . . D-10
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 -- Running a multiple node RBBS-PC . . . . . . . . . . H-1
APPENDIX I -- RBBS-PC in a DESQview Environment . . . . . . . . . I-1
1. Basic Hardware Considerations . . . . . . . . . . . . . . I-1
2. Modifications to DOS CONFIG.SYS and RBBS-PC batch files . I-1
3. What to Tell RBBS-PC's "CONFIG" Utility . . . . . . . . . I-2
4. DESQview Setup Default Settings . . . . . . . . . . . . . I-2
5. Adding RBBS-PC to DESQview's "Open Window" Menu . . . . . I-3
6. Memory Considerations . . . . . . . . . . . . . . . . . . I-3
7. Expanded Memory . . . . . . . . . . . . . . . . . . . . . I-4
8. How to AUTOEXEC RBBS-PC From DESQview . . . . . . . . . . I-4
9. Quarterdeck Utilities . . . . . . . . . . . . . . . . . . I-4
10. Redirecting I/O Considerations (DOS CTTY Command) . . . . I-5
11. FOSSIL Drivers - Break the 2-node Barrier under
DESQview! . . . . . . . . . . . . . . . . . . . . . . . I-5
12. RBBS-PC Technical Support For DESQview . . . . . . . . . I-8
APPENDIX J -- Using RBBS-PC with DoubleDOS . . . . . . . . . . . . J-1
APPENDIX K -- RBBS-PC in a MultiLink Environment . . . . . . . . . K-1
APPENDIX L -- RBBS-PC in a CORVUS Network . . . . . . . . . . . . L-1
APPENDIX M -- RBBS-PC in ORCHID or AST PCnet NETWORK . . . . . . . M-1
APPENDIX N -- RBBS-PC in an Alloy PC-SLAVE/16 Environment . . . . N-1
APPENDIX O -- RBBS-PC and 10 NET Network . . . . . . . . . . . . O-1
APPENDIX P -- Running RBBS-PC on a NETBIOS network . . . . . . . . P-1
APPENDIX Q -- RBBS-PC and the IBM PCjr . . . . . . . . . . . . . . Q-1
APPENDIX R -- Using RBBS-PC to access ORACLE or dBASE Remotely . . R-1
Using dBASE "DOORS" with RBBS-PC . . . . . . . . . . . . . . R-1
Using ORACLE with RBBS-PC for On-line Data Base Access . . . R-3
APPENDIX S -- Using RBBS-PC with SEAdog to Access FIDO-NET . . . . S-1
APPENDIX T -- DOS Limitation on Running Programs Remotely . . . . T-1
APPENDIX U -- Recompiling RBBS-PC to Reduce Memory Required . . . U-1
PREFACE 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:
- Modem communications
- DOS file organization
- DOS Batch files
Consult your modem owner's manual, and your DOS command and technical
references for details on these items.
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 imbed "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 dozens of contributors, and was compiled and edited by Doug Azzarito.
Your comments and suggestions are welcome. If you would like a copy of
this document formatted for a specific printer, contact Doug Azzarito on
the BBS listed on the title page.
INTRODUCTION 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 control a
system that lets "remote" callers use the host computer 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.3A TECHNICAL REFERENCE MANUAL 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."
INTRODUCTION 1-3
While we have met very few of these people personally, those names we
remember are:
Doug Azzarito Ray Horton Harvey Pierce
Jeff Batdorf Gary Howrith Danny Plunkette
Rod Bowman Charlie Innusa Lee Pollard
Matthew Briggs Loren Jones Jeff Porter
Randy Brodersen Larry Jordan James Reinder
Mike Brown Robert Jueneman Joel Ricketts
Sam Brown Vern Kallegin Kurt Riegel
Mike Button Dave Kleinschmidt Jacques Rodrique
Vince Castelli Steven Kling Dick Rohradnz
Rob Cecchino Kim Kodde Rich Schinnell
Tom Collins Blaine Korcel Mark Seiden
Drew Commins Ronald Koridon Rosemarie Siddiqui
Ezra Conger John Krytus Andrew Silber
Ed Copley Mark Lautenschlager Carl Slaughter
Richard Couture Steve Lieber Samuel H. Smith
Bob Cramer Steven Linhart Gregg Snyder
Dave Crane Joseph Lionelle Robert Snyder
Daryl Damon Scott Loftesness Carl Spencer
Everett Delano Harry Logan David Staehlin
Francis Dorer Gene Lowry Stan Staten
Peter Eibl James Ludwick Terry Steichen
Warren Fox Kevin Lutz Dorn Stickle
John Friel D. Thomas Mack Randy Sun
Jim Fry Robert Mahoney Terry Taylor
Asa Fulton Matt Malden Jan Terpstra
Kent Galbraith Carl Margolis Arnold Thomsen
Mitch Geier Sidney Markowitz Daan van der Weide
John German Jon Martin Rick Wadowski
Read Gilgen Louie McCaw Clark Walker
Ken Goosens Wes Meier Kim Wells
Ray Gwinn John Morris Bob Westcott
Dave Hacquebord Bill Newkirk Robert White
Steve Harrison Jeregen Nordhausen Yew Seng Tan
Gary Hoff Vince Perriello
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.
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.
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.3A TECHNICAL REFERENCE MANUAL 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.3 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 of 99.9X 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 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 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, or
used. 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.3A TECHNICAL REFERENCE MANUAL 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 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.3A TECHNICAL REFERENCE MANUAL 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 17.3A?
------------------------
17.3A is a maintenance release for 17.3. Over 100 changes were made to
the code. The most significant are:
(a) increased reliability, eliminating the following problems:
- occasional constant recycling with "connect timeout"
- overflow error when modem not working right
- untrapped errors, when FMS directory wrong and when trashcan file not
set up properly
- possible infinite loop in FMS search
- possible incorrect modem initialization in CONFIG
- problems with execution of external events after 9pm.
(b) autodownload now works properly
(c) problems with macros were fixed, including repeat of prompts, double
execution of a macro, assigns sometimes getting wrong values, problem
with block print, problem with PUI's, and macros associated with a
protocol not being executed.
(d) problems fixed with doors include individuation not restored, doors
need not be listed on the menu if in DOORS.DEF, the registration door
will respect DOORS.DEF, and bytes downloaded is now right dooring to
external protocols.
(e) problems fixed with messages/conferences include mail waiting in a
conference view works properly for the conference you are in, message
display can be paused and interrupted, searches on subject work right
if subject not in upper case, TABS works in message entry, person with
SysOp status does have mail to SysOp listed in mail scan, public name
of SysOp recognized as SysOp, no longer says receiver will be notified
of new mail when not in user's file, join to main works in conference
view function, support added to allow names to have a netmail address
("@ <node>" on end), and subject prompted for in message entry after a
canceled comment to SysOp.
INSTALLING RBBS-PC 2-5
(f) problems fixed with the callers log include time logged on is not
right when join conferences, and more information is included for
local users.
(g) Features were added to the Fast File Search to better support macro
processing (see section 12.9).
(h) The documentation was also rewritten in 17.3A. Many new examples and
explanations of features were added.
(i) The conference V)iew command now resumes any listing after the last
conference listed, rather than restarting at the top each time."
Previously, version 17.3 of RBBS-PC added the following enhancements:
(a) Search for a file's existence on upload and download has been vastly
speeded up. Based on an indexed binary search of a sorted list of
file names.
(b) Data base function to forward search (jump to a line containing a
particular string and continue from there) was added for all file and
text displays
(c) NEWS facility that automatically displays news since last on to
callers
(d) Callers can now stack commands to virtually any depth, and stacking is
consistently supported everywhere.
(e) Modem commands can be selected based on modem model.
(f) Users may now FORWARD their mail to another user. SysOps or users
having sufficient security to edit a message can forward it to anyone
as well as change anything in the message header.
(g) The MSG header Security change now allows the SysOp to change ANY
field in the header.
(h) When reading mail, the SysOp can instantly edit the USER record of the
message sender, then return to reading.
The specific enhancements added include:
(1) When you have insufficient time to download all the files requested,
RBBS-PC will inform you of the files omitted but try to download what
there is time for instead of canceling the entire download request.
(2) Timelock message now shows minutes & seconds left in time lock.
(3) Command stacking now supported consistently and to virtually any
depth.
(4) Autopage message less stiff and formal when caller notified that SysOp
wanted to know caller logged on.
(5) Chat time given back when SysOp initiates chat and no longer counts
against session time.
(6) Conference name added to message header.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-6
(7) Support for new ZIP imploded compression.
(8) NEWS facility added. Special bulletin displayed automatically on
logon when updated since user last on.
(9) Message quoting first gives the edit command prompt but tells how to
continue adding to a reply.
(10) Default extension automatically added to uploads and downloads when no
extension is specified
(11) Forward search added to all directory displays and text file displays
(12) Delays and embedded returns can be put into modem control strings.
(13) Caller shown on welcome line if connection is reliable
(14) SmartText can control whether substituted value is inserted or
overlaid
(15) SmartText can control whether substituted value is trimmed of leading
and trailing spaces first
(16) Caller is informed when session time is shortened because of an
external net mail event.
(17) Can use "s" for since last listed on file N)ew command (e.g. "n s u"
for list new files since last on in upload directory).
(18) When replying to a message, will automatically continue if person
sending mail to is not in the user's file, rather than asking the user
whether wants to re-enter name or continue.
(19) Macro questions can have edits forcing answer to be one of a list or
between two values.
(20) Protocols to be used to download and upload can be specified anywhere
in stacked command line rather than just on end.
(21) File searches on up and downloads have been vastly speeded up. Makes
a huge different on slow devices like CD-ROMs. Also, have ability to
trigger OFF LINE processing for files elsewhere.
(22) CONFIG gives option to set modem commands based on modem model. Uses
external file MODEMS.SET in default drive/path. Makes RBBS-PC much
easier to set up.
(23) SysOps can now track UL/DL's and have a "free download" period.
(24) SysOps can now explain exactly what a REGISTRATION EXPIRES means. The
HELP file RGXPIRE.HLP is seen when a user is warned, and RGXPIRD.HLP
is seen when RBBS-PC reduces a caller's access.
(25) Support for 38,400 bps, but only through Fossil drivers.
(26) Can have multiple extensions searched when trying to detect duplicate
on upload (new CONFIG parm 169).
INSTALLING RBBS-PC 2-7
2.3 Upgrading To 17.3A
----------------------
17.3A is virtually "plug compatible" with 17.3. You need only:
- replace RBBS-PC.EXE and CONFIG.EXE with the new versions
- add the new help file "HELP07" to your other help files
- in parameter 225 of CONFIG, add "AT" in front of your firmware write
command
- replace your MODEMS.SET with the new one
- replace MENU5C, for doors, with the new one (edit in your door names),
unless yours is not based on the standard one
When upgrading from a version PRIOR to 17.3, follow these steps:
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.3 is compatible on both
accounts with files at least back through version 14. However, 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.2x, you need to consider the following:
(a) replace RBBS-PC.EXE and CONFIG.EXE
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-8
(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 even 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:
(a) Macros and SmartText have been significantly improved in 17.3.
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,
INSTALLING RBBS-PC 2-9
(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.3 does NOT change the structure of the user,
message, or DEF files from that in 17.2.
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).
- 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).
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 2-10
- Modem is not connected to the communications port that RBBS-PC was
told to use.
- 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.
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
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 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 IBM 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).
INSTALLING RBBS-PC 2-11
- 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 3-1
3. "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS
-------------------------------------------------
RBBS-PC is designed to run on an IBM Personal Computer, or compatible,
running IBM'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 AT or 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 │16550AN UART chip │
├────────────┼─────────────────────────────┼──────────────────────────────┤
│Modem │Any Hayes Smartmodem 1200, │A US Robotics Courier HST │
│ │or 100% compatible modem │dual standard 9600 bps 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 │PC-DOS version 2.1 │PC-DOS 4.01 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 320K
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 320K 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
modem doesn't work with RBBS-PC, send RBBS-PC (source code and all) to the
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 3-2
vendor and ask him to explain why it doesn't work, if the modem is
compatible.
RBBS-PC's SUPPORT POLICIES 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 (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. (Note that RBBS-PC remains upward compatible with
15.1C, and virtually everything in the book still applies.)
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) 627-6969
(407) 627-6862
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 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) 627-9767. Usually, the phone will be
answered by a voice mail system. You can record questions and call
back later to hear answers. If you request that someone return your
call, we will call you COLLECT. Your best chance of having a human
answer the phone are between the hours of 7pm and 11pm (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
Please realize that bulletin boards may cease to exist, or change their
phone numbers, and that other commitments can make people unavailable.
Bearing that in mind, the list of BBSs knowledgeable about RBBS-PC include:
Arizona
Tucson: Gene Lowry, Bigfoot RBBS. (602) 886-7943
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 4-2
California
Colton: Rod Bowman, The PC Spectrum (tm). (714) 381-6013
Concord: Jon Martin, Aircomm. (415) 689-2090
LakePort: Randy Sun, Sigma Industries RBBS. (707) 263-8581
Connecticut
Trumbull: Tom Mack, The Second Ring. (203) 268-5315
Florida
Tampa: Dave Hacquebord, The Sunshine Board. (813) 887-3984 and
(813) 885-4659
Palm Beach Gardens: Doug Azzarito, Technology Consultants RBBS.
(407) 627-6969 and (407) 627-6862
Delray Beach: Mark Lautenschlager, Silicon Beach. (407) 276-6263
Kentucky
Lexington: Ronald Nutter, Bluegrass RBBS. (606) 272-0499 (Fill
out SysOp questionnaire)
Illinois
LaGrange: Loren Jones, RBBS-PC of Chicago. (708) 352-1035
Indiana
Bloomington: John Taylor, Indiana On-Line. (812) 332-RBBS
Maryland
Rockville: Roger Fajman, CPCUG Member's Information Exchange
(Capital PC Users Group). (301) 738-9060, 9 lines (Join
SysOp conference)
Nebraska
Broken Bow: Tom Hansen, Church Chatters. (308) 872-6112 and
872-3394.
Nevada
Reno: John Morris, (702) 746-1364.
Ohio
Tiffin: Don Smith, NorthWest OHIO BBS. (419) 448-1421.
Pennsylvania
Sharon Hill (Philadelphia): Mark Horninger, Electric Playground.
(215) 534-1466
Virginia
Arlington: Lee Pollard, Death Star. (301) 839-0705
Fairfax: Ken Goosens, Your Place. (703) 978-6360, 3 lines
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
RBBS-PC's SUPPORT POLICIES 4-3
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) 627-9767. 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, 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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 4-4
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.
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
RBBS-PC's SUPPORT POLICIES 4-5
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
Ark Electronic Products, Inc.
325 W. Hibiscus Blvd.
Melbourne, Florida 32901
(407) 724-5260
Corvus Systems, Inc.
2100 Corvus Drive
San Jose, California 95124
(408) 559-7000
The Forbin Project (c/o John Friel III)
4945 Colfax Avenue South
Minneapolis, MN 55409
Hayes Microcomputer Products, Inc.
5923 Peachtree Industrial Blvd.
Norcross, Georgia 30092
(404) 449-8791
International Business Machines Corporation
(Internal Zip Code 2900)
P.O. Box 1328
Boca Raton, Florida 33432
(305) 998-2000
Microcom, Inc.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 4-6
1400A Providence Highway
Norwood, MA 02062
(617) 762-9310
Multi-Tech Systems, Inc.
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 Incorporated
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
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 vendor 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 address:
Ken Goosens
5020 Portsmouth Road
Fairfax, VA 22032
RBBS-PC's SUPPORT POLICIES 4-7
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 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 Exchange
P.O. Box 6128
Silver Spring MD 20906.
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 RBBS-PC 17.3A. 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:
RBBS-PC
P.O. Box 31024
Palm Beach Gardens, FL 33420-1024.
Please enclose a check for $10. (U.S.), which helps pay for disks and 1st
class postage (non-U.S. addresses, please enclose $15.). 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 than 17.3A (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 $8 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 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
positions 74 & 75 and comments/uploads share positions 77 & 78. The letter
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-2
"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)
Contains a substitute RBBS-PC.EXE which has reduced error-
reporting, resulting in a smaller executable file.
FILES RBBS-PC USES 6-3
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
should only be "packed" when none of the nodes are running.) The MESSAGES
file can be shared among multiple RBBS-PCs.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-4
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 the with 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
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
FILES RBBS-PC USES 6-5
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 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.3A TECHNICAL REFERENCE MANUAL 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.
CONFENCE Displayed to users who issue the J)oin function from the
main menu. It can be created by any text editor that can
FILES RBBS-PC USES 6-7
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.
HELP09 Displayed when <H>elp is requested for the type of
graphics a user wants (none, ASCII, color/music).
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 6-8
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). │
└─────────┴────────────┴──────────────────────────────────────────────────┘
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.
FILES RBBS-PC USES 6-9
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 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 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.2 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.
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.3 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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-2
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.4 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-
| |
-------------------<----------------------
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.5 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
PLANNING YOUR USER INTERFACE 7-3
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 ARC files
[#]DOORS [K]ill message [R]ead messsages [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
- 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,
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-4
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 the 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] Change Baud Rate 300-->450
[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 ARC 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?
7.6 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.
PLANNING YOUR USER INTERFACE 7-5
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.6.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:
<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.6.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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-6
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.
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).
PLANNING YOUR USER INTERFACE 7-7
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,
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 17.3A TECHNICAL REFERENCE MANUAL 7-8
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.7 RBBS-PC's Support of Sub-menus
----------------------------------
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
PLANNING YOUR USER INTERFACE 7-9
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:
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.7.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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-10
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.7.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:
/ 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.8 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):
PLANNING YOUR USER INTERFACE 7-11
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 insider 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.
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-12
7.8.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:
<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").
PLANNING YOUR USER INTERFACE 7-13
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:
(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.8.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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-14
*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
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"
PLANNING YOUR USER INTERFACE 7-15
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
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.ARC 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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-16
{==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
{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"
PLANNING YOUR USER INTERFACE 7-17
"PROTOCOLS","407-627-6969","407-627-9767","Doug","Azzarito"
then the caller would see
-TOPIC- - DATA # - - VOICE # - -First Name- -Last Name-
DOORS 703-978-6360 0 Ken Goosens
PROTOCOLS 407-627-6969 407-627-9767 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
where RFLH.DAT contains:
Ken Goosens DOORS 703-978-63600
Doug Azzarito PROTOCOLS 407-627-6969407-627-9767
This would produce the following for the caller:
-TOPIC- - DATA # - - VOICE # - - Name -
DOORS 703-978-6360 0 Ken Goosens
PROTOCOLS 407-627-6969 407-627-9767 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).
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-18
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...
{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.8.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.
PLANNING YOUR USER INTERFACE 7-19
7.8.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
- 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]-
@
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-20
:-[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
?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:
PLANNING YOUR USER INTERFACE 7-21
- 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.
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.9 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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-22
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.
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.
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.
PLANNING YOUR USER INTERFACE 7-23
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.
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 file 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
the 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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-24
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.10 "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:
1) In files shown to the callers including:
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.
PLANNING YOUR USER INTERFACE 7-25
"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.
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 would 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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-26
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.11 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:
- 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.
PLANNING YOUR USER INTERFACE 7-27
"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
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.12 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,...).
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-28
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.
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.13 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 7-29
┌───────────────────────────┬─────────────────────────────────────────────┐
│ 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.
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 7-30
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
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 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.3A TECHNICAL REFERENCE MANUAL 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 user. 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 with a
proper ID and RBBS-PC finds an individuation value or password that is
UNIQUELY IDENTIFYING YOUR CALLERS 8-3
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 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.3A TECHNICAL REFERENCE MANUAL 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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 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.3A TECHNICAL REFERENCE MANUAL 10-2
Parameter 3 EXPERT
The mode (EXPERT of NOVICE) for the SysOp. This option is now
obsolete. The SysOp may use the RBBS-PC eXpert command.
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 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
message. 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.
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.
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-4
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
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-5
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>
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-6
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 download).
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).
Parameter 50 60
The number of days BEFORE a caller's subscription is to expire that
RBBS-PC will send warnings. 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.
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-7
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
Specifies how directories are sorted when a caller requests a list of
ALL download directories. You can either specify no sort, or the
directories can be shown in the order they appear in the "directory of
directories."
Parameter 59 1024
Specifies the buffer sized 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.
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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-8
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,
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-9
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 uploade 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 to 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
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-10
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.
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
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-11
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
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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-12
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).
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-13
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 users 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.
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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-14
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>
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-15
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
the every user can read it.
Parameter 140 10
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 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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-16
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 activate when CONFIG is in
"conference maintenance" mode (see parameter 167). If a caller tries
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).
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-17
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
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" 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.
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)
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-18
5) 10 Net (Fox Research)
6) IBM's NETBIOS
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 press the END key while in
conference maintenance mode.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-19
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
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.
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
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-20
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:
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-21
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
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-22
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 ALLDIR 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.
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-23
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 let the phone ring until the TDD
connects, but 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).
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-24
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>
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-25
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 quickly respond to XON/XOFF, set parameter 54 to a small
number.
Parameter 246 30
The maximum time to 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
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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-26
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 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 un a PDN, or callers who use
TDDs may want to change this value to either an intermediate host, or
to the caller's system.
Parameter 266 <none>
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).
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-27
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
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.
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.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 10-28
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.
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.
USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 10-29
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 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.3A TECHNICAL REFERENCE MANUAL 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 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, or by using a search
argument. 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
drives for downloads. The parameter is specified with the drive letters to
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-2
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 sue 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 Single and Chained FMS Directory Format
------------------------------------------------
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.
Beginning with 17.2A FMS directories can be "chained". This means that
physically separate files can be logically combined to form a single FMS
directory. This is accomplished by putting the following in the header
record (a header record in an FMS directory is the first record and must
begin with "\FMS "):
CH(<chain to>)
where <chain to> is the name of the file to chain to. As an example
\FMS CH(C:\DIRS\CHTO.DIR)
would chain to the file "C:\DIRS\CHTO.DIR". Names of files not in the
default directory must have a drive and/or path specified. The directory
chained to can in turn have a chain, and there is no limit to the number
that can be chained together. Note that this "header" record must have the
same length as the rest of the lines in the directory, and will usually
have to be padded out with blanks.
The directory chained to is an independent FMS directory and can be
anywhere and have any extension. A given directory can have at most one
directory to chain to. Chained directories can be used to keep the upload
directory small for easier editing, or to better fit the latest directories
on a fast RAM disk while keeping older directories on a slower hard disk
(e.g. a SysOp divides the directories into UPLOADS.DIR, 87.DIR, 86.DIR,
85.DIR, and 84.DIR to reflect the year in which the file was
created/uploaded).
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-3
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.
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).
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-4
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
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 limitations 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
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-5
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
-----------------------------
If you already have separate directories, 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.
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 a FMS directory from top to bottom the first four
characters in the first line must be "\FMS" and the line must contained 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
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-6
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
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 a file specified in parameter 217 of CONFIG. 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>"
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-7
The category name is what the caller types in L;xxxxxxxxxx. The category
codes are a list of the character codes in the FMS directory that we want
to be under this category name. 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 messages
that we want displayed when the category is searched for.
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
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.ARC 13463 05-24-87 DOS Util look all over disk for file DSU
QUEST.ARC 17325 06-02-87 C/G Game D&D style CGG
RBBS-SRC.ARC 202562 06-05-87 Source code for RBBS-PC BSS
QMODEMSC.ARC 106735 06-07-87 Source code for QMODEM SST PSS
BALLOON.ARC 5634 06-08-87 BASIC Balloon game- GREAT BSG
STARTREK.ARC 76434 06-10-87 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 The "Library" Subsystem, CD-ROM, and FMS
---------------------------------------------
The RBBS-PC "library" sub-system is highly flexible subsystem that utilizes
DOS 'disk subdirectories. The "library" subsystem is not limited to any
particular medium. Basically, it relies on three files:
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-8
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 |
|
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
RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-9
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.6.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
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 are more than one
subdirectories then 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.