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

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / 173_DOC.ZIP / RBBSDOC1.ASC < prev next >

Wrap

Text File | 1990-02-11 | 338.0 KB | 6,436 lines

REMOTE BULLETIN BOARD SYSTEM for the IBM Personal Computer Version CPC17.3 Technical Reference Guide Technical Support Numbers Voice Mail System (407) 627-9767 Answering Machine (203) 268-9656 (calls returned COLLECT) Copyright 1983-1990 by D. Thomas Mack 39 Cranbury Drive Trumbull, Conneticut 06611 DATA #1 -- (203) 268-5315 #2 -- (203) 268-0129 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 February 11, 1990 RBBS-PC CPC17.3 Page 2 TABLE OF CONTENTS Page Updated ----------------- ---- 0. PREFACE 6 *0.1 Philosophy Behind RBBS-PC 6 *0.2 Distribution of RBBS-PC 6 0.3 The "Contributions" Requested for RBBS-PC 6 0.4 How to Send Improvements 9 1. INSTALLING RBBS-PC *1.1 First Time Installation 11 *1.2 What's New in 17.3? 15 *1.3 Upgrading 18 *1.4 Common Problems 21 2. "BASE-LINE" HARDWARE AND SOFTWARE REQUIREMENTS 23 3. RBBS-PC's SUPPORT POLICIES 25 *3.1 RBBS-PC's User Support Policy 25 3.2 RBBS-PC's Vendor Support Policy 29 *4. HOW TO GET A COPY OF RBBS-PC SENT TO YOU 33 5. FILES RBBS-PC USES 34 5.1 RBBS-PC System Files 35 5.2 RBBS-PC Text Files 39 6. PLANNING YOUR USER INTERFACE 44 6.1 Menus Shown to Callers 44 6.2 Subsystem Prompts Shown to Callers 45 6.3 Commands Available to Callers 46 6.4 RBBS-PC's "Wrap-around" Command Search 47 6.5 How to Have a Single Universal Command Line 48 6.6 RBBS-PC'S Programmable User Interface (PUI) 51 6.6.1 An Example Using PUI 52 6.6.2 How to Implement PUI 53 6.7 RBBS-PC's Support of Sub-menus 56 6.7.1 How to Implement Sub-menus 58 6.7.2 Shared Options Across Sub-menus 58 6.8 RBBS-PC's "Macro" Command Support 59 *6.8.1 How To Set Up "Macros" 61 *6.8.2 Macro Commands 63 6.8.3 A Sample Macro 68 6.8.4 On-line Data Base With Macros & Questionnaires 69 *6.9 RBBS-PC's "Smart" Text Variables 73 6.10 "Colorizing" the RBBS-PC User Interface 76 6.11 RBBS-PC's Automatic Operator Page Option 79 6.12 Enhancing the File Verbose List 81 *6.13 Bulletins and News 83 * New or substantially revised. RBBS-PC CPC17.3 Page 3 TABLE OF CONTENTS Page Updated ----------------- ---- 7. UNIQUELY IDENTIFYING YOUR CALLERS 85 7.1 Setting Up Identifying and Individuation Fields 86 7.2 Preloading Identities For Instant Access 87 8. RBBS-PC's AUTOMATIC SUBSCRIPTION/ TIME MANAGEMENT 88 8.1 Setting It Up 89 9. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 90 9.1 Global RBBS-PC Parameters (Part 1 of 3) 91 9.2 Global RBBS-PC Parameters (Part 2 of 3) 94 9.3 Global RBBS-PC Parameters (Part 3 of 3) 97 9.4 Parameters for RBBS-PC System Files (part 1) 100 9.5 Parameters for RBBS-PC System Files (part 2) 103 9.6 Parameters for RBBS-PC "Doors" 106 9.7 Parameters for RBBS-PC's Security (part 1) 109 9.8 Parameters for RBBS-PC's Security (part 2) 111 9.9 Parameters for Multiple RBBS-PC's/Conferences 115 9.10 RBBS-PC SysOp Utilities 118 9.11 RBBS-PC's File Management System Parameters 120 9.12 Communications Parameters (part 1) 124 9.13 Communications Parameters (part 2) 128 9.14 Parameters for RBBS-PC NET-MAIL 129 9.15 New Users Parameters 131 9.16 Use of the Library Sub-System 132 9.17 RBBS-PC's Parameters for Color 133 10. THE HAYES MODEM SWITCH SETTING AND CONSIDERATIONS 134 10.1 Hayes Smartmodem 1200 Switch Settings 136 10.2 Hayes Command's Considerations 136 10.2.1 Command to Reset the Modem 136 10.2.2 Command to Initialize the Modem 136 10.2.3 Command to Count The Number of Rings 137 10.2.4 Command to Answer the Phone 137 10.2.5 Command to Take the Phone Off the Hook 138 10.2.6 Smartmodem 2400 Firmware Initialization 138 10.2.7 Smartmodem 9600 Firmware Initialization 140 11. RBBS-PC's FILE MANAGEMENT SUBSYSTEM 142 11.1 Multiple Directory Format 143 11.2 The Single and Chained FMS Directory Format 145 11.3 Advantages/Disadvantages of FMS Directory 146 11.4 Creating FMS Directories 149 11.5 Defining the FMS Category Codes 151 11.6 The "Library" Subsystem, CD-ROM, and FMS 153 11.6.1 How the "Library" Subsystem Works 155 11.6.2 The "Library" Subsystem and PC-SIG's CD-ROM 156 11.7 Creating the Personal Files Directory 157 11.8 Automatically Checking & Converting Uploaded Files 161 *11.9 Fast File Search 163 * New or substantially revised RBBS-PC CPC17.3 Page 4 TABLE OF CONTENTS Page Updated ----------------- ---- 12. SETTING UP ".BAT" FILES FOR RBBS-PC 166 13. THE USE OF RBBS-PC "DOORS" 167 13.1 "DOORS" Are Nothing More Than .BAT Files 168 13.2 A Sample .BAT File for a "DOOR" 168 13.2.1 Redirect I/O Using the CTTY Method 168 13.2.2 Redirect I/O Using the CTTY Method 168 13.3 Setting Up and Testing a "DOOR" 169 13.4 Invoking "DOOR"s Via The External Control File 171 13.5 EXITing or SHELLing to "DOOR"s 172 13.6 Resetting The User's Record Via a "DOOR" 173 13.7 A Summary of "DOOR"s 174 14. THE SECURITY FEATURES OF RBBS-PC 175 14.1 RBBS-PC's Security Features 176 14.2 Examples of Uses for RBBS-PC's Security System 177 *14.3 How to Implement the Password File 179 14.4 Implementing Security for Download Files 182 14.5 Implementing Security for RBBS-PC Commands 184 14.6 Beware of the "Trojan Horse!" 186 15. SysOp FUNCTIONS 187 15.1 SysOp Commands Within RBBS-PC 187 15.2 SysOp Use of Function Keys and Numeric Pad 189 16. MESSAGE AREAS WITHIN RBBS-PC 191 16.1 "Conferences" and "Sub-boards" -- the Differences 191 16.2 Making a "Conference" or "Sub-board" Successful 194 16.3 Setting Up a "Conference" or "Sub-board" 195 *16.4 Establishing a "Conference" or "Sub-board" SysOp 196 17. CALLERS AUTOMATIC NOTIFICATION OF MAIL WAITING 197 18. RBBS-PC QUESTIONNAIRE FACILITIES 199 18.1 Branching to Labels 200 18.2 Display Data Command 201 18.3 Display Data And Get Response 202 18.4 Multiple Choice Responses 202 18.5 Forward and Backward Branching 203 18.6 Raise/Lower User's Security Level 203 18.7 Abort Questionnaire 203 18.8 Chain Questionnaire 203 18.9 Turbo Key 203 18.10 Macro Execute 203 18.11 Assign Value 204 19. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS 205 19.1 Parameters passed to a protocol driver 206 19.2 Calling external protocols using "templates" 210 19.3 Parameters Returned by a Protocol Driver 212 19.4 The Protocol Drivers Tested With RBBS-PC 213 * New or substantially revised RBBS-PC CPC17.3 Page 5 TABLE OF CONTENTS Page Updated ----------------- ---- 20. UPLOADED FILE TIPS 215 21. DUE WARNING AND SysOp'S LEGAL LIABILITY 216 22. COMPILING AND LINKING RBBS-PC 217 22.1 Compiling CONFIG and RBBS-PC 217 22.2 LINKing CONFIG 218 22.3 LINKing RBBS-PC 218 23. LIMITED LICENSE 219 24. LIMITED WARRANTY 220 25. THE HISTORY BEHIND RBBS-PC 221 26. PROPOSED AGENDA FOR A NATIONAL SysOp CONFERENCE 224 27. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD 229 APPENDIX A -- RBBS-PC Record Formats 230 APPENDIX B*-- RBBS-PC in a DESQview Environment 236 APPENDIX C -- RBBS-PC in a MultiLink Environment 246 APPENDIX D -- RBBS-PC in a CORVUS Network 248 APPENDIX E -- RBBS-PC in ORCHID or AST PCnet NETWORK 249 APPENDIX F -- RBBS-PC in an Alloy PC-SLAVE/16 Environment 251 APPENDIX G -- RBBS-PC and 10 NET Network 257 APPENDIX H -- RBBS-PC and the Hearing-Impaired 258 APPENDIX I -- RBBS-PC and the IBM PCjr 259 APPENDIX J*-- RBBS-PC Subscription Service 261 APPENDIX K -- RBBS-PC National Listing Service 262 APPENDIX L -- The Ark-Paradyne Modem RBBS-PC Switch Settings 263 APPENDIX M -- RBBS-PC And the Anchor Signalman Express (MK12) 266 APPENDIX N -- The Everex 2400 modem RBBS-PC switch settings 267 APPENDIX O -- Prometheus 2400G modem RBBS-PC switch settings 268 APPENDIX P*-- US Robotics Modems' RBBS-PC Switch Settings 269 APPENDIX Q -- RBBS-PC and the FASTCOMM 2496 Turbo Modem 275 APPENDIX R -- RBBS-PC and the ZOOM Modem HC2400 278 APPENDIX S -- RBBS-PC And The AT's RS-232 Cable 279 APPENDIX T*-- RBBS-PC And BASIC Compiler Patches for "Doors" 280 APPENDIX U*-- Using RBBS-PC to access ORACLE or dBASE Remotely 281 APPENDIX V -- Using RBBS-PC with SEAdog to Access FIDO-NET 285 APPENDIX W -- DOS Limitation on Running Programs Remotely 289 APPENDIX X -- Using RBBS-PC with DoubleDOS 290 APPENDIX Y -- Recompiling RBBS-PC to Reduce Memory Required 292 APPENDIX Z -- The MICROCOM AX9624c RBBS-PC Switch Settings 294 APPENDIX AA-- The Leading Edge Series L 2400B Modem 295 * New or substantially revised. RBBS-PC CPC17.3 Page 6 0. PREFACE ---------- 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 that lets "remote" callers use the host computer for many functions, including the dissemination of news and bulletins, electronic mail between users, and exchange of programs and data, as well as open ended list of types of functions, such as taking surveys and 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 but run as a "local" application in which the "user" does not connect through a telephone line, such as on a local area network. 0.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. 0.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. 0.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 RBBS-PC CPC17.3 Page 7 modified EXE (executable) file without 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 the CPCUG, feel free to do so. If you are so inclined, but before you do so, contact the Capital PC User Group, 51 Monroe Street, Plaza East Two, Rockville, MD 20850. For general information about the appropriateness of the bequest, contact the Capital PC User Group directly at (301) 762-6775. 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." CPCUG is an all volunteer organization and money is seldom plentiful. However the essence of CPCUG is the time, ideas, and effort that each of the volunteers contribute to it. For this reason, while money is always appreciated, 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, o remember those who have, o enjoy what they have nurtured, and o keep the faith with those who have gone before you. RBBS-PC is what it is today only because of the freely donated time and work of many contributors. Contributions have included suggestions, software fixes, significant enhancements, improved documentation, and utilities. Some of the individuals named here have continued their contributions to RBBS-PC even to the current release. Others have gone on to pursue different interests. But whether mentioned below or not, their contributions live on in RBBS-PC. In their contributions to RBBS-PC's on-going growth, each has paused to give of themselves without hope of reward by practicing RBBS-PC's fundamental principle -- "users helping users." While we have met very few of these people personally, those names we remember are: Doug Azzarito John German Blaine Korsel Samuel H. Smith Jeff Batdorf Read Gilgen Matt Malden Gregg Snyder RBBS-PC CPC17.3 Page 8 Rod Bowman Ken Goosens Carl Margolis Robert Snyder Randy Brodersen Ray Gwinn Jon Martin Carl Spencer Mike Brown Dave Hacquebord Robert Mahoney David Staehlin Sam Brown Steve Harrison Sidney Markowitz Stan Staten Mike Button Gary Hoff Louie McCaw Dorn Stickle Vince Castelli Gary Howrith Wes Meier Terry Steichen Rob Cecchino Charlie Innusa John Morris Randy Sun Tom Collins Loren Jones Bill Newkirk Yew Seng Tan Drew Commins Larry Jordan Jeregen Nordhausen Terry Taylor Ezra Conger Robert Jueneman Vince Perriello Jan Terpstra Ed Copley Vern Kallegin Harvey Pierce David Terry Richard Couture Dave Kleinschmidt Danny Plunkette Arnold Thomsen Bob Cramer Steven Kling Lee Pollard Daan van der Weide Dave Crane Ronald Koridon Jeff Porter Rick Wadowski Everett Delano John Krytus James Reinder Clark Walker Peter Eibl Steve Lieber Kurt Riegel Kim Wells Warren Fox Steven Linhart Joel Ricketts Bob Westcott John Friel Joseph Lionelle Jacques Rodrique Robert White Jim Fry Scott Loftesness Dick Rohradnz Carl Slaughter Asa Fulton Harry Logan Rich Schinnell Francis Dorer Kent Galbraith Gene Lowry Mark Seiden Ray Horton Mitch Geier James Ludwick Andrew Silber Blaine Korcel Kevin Lutz Mark Lautenschlager 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 Obstretricans 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 "I am very proud of the company that RBBS-PC keeps." RBBS-PC CPC17.3 Page 9 0.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 xxxxxx.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 QuickScanMessages = ZFalse ' JC011090 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 xxxxxx.DOC. It describes on a line-by-line basis the specific functions added or bug that was fixed. Obviously xxxxxx can be anything you wish to name it. The second type of file is what allows me to integrate several .MRG files and resolve whatever conflicts that may exist. Each incremental release of RBBS-PC beyond CPC17-3 will include updates to the base-line documentation. This documentation update will include a new Table of Contents which not only will be a complete replacement for the base-line Table of Contents but which also will indicate (to the right of the page numbers for each section that has been updated) the date of the latest update (beyond the base-line). The RBBS-PC naming conventions of CPCxx.x are roughly as follows: 1. If a "bug" is being fixed CPCxx.x will be given a .MRG file name such as CPC17-3A.MRG with a corresponding CPC17-3A.DOC file describing the changes. The first maintenance version of CPCxx.x is always "A". When you logon to RBBS-PC the version will be displayed. 2. 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. 3. If a new feature or enhancement is added the last digit in the CPCxx.x will be incremented by one (i.e. CPC17.2B was followed by CPC17.3). 4. If a significant change to source code or logic occurs, the first two digits of the release level will change (i.e. CPC14.1 was followed by CPC15.1) 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. RBBS-PC CPC17.3 Page 10 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. RBBS-PC CPC17.3 Page 11 1. 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 CPC 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 uninitiated 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. 1.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 drive C. "RBBS" is a suggested name but any can be used (e.g. "BBS"). 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:RBBS-EXE.ZIP C:\RBBS". RBBS-PC CPC17.3 Page 12 3. Make the subdirectory you created your current one ("CD \RBBS"). 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. You are now ready to run RBBS! The text comes come ready with a sample configuration file, and small but empty users and messages file. To bring up RBBS-PC, at the DOS prompt simply type RBBS-PC LOCAL[Enter] where "[Enter]" means to press the "Enter" key. The "LOCAL" tells RBBS-PC not to wait for a telephone call to establish communications through a serial port, but just to run as a local application, communicating to the user 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. Put in a dummy name, like "Please Omit" for your first and last name. Just answer the questions 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 hardware switches on the modem properly, but some modems, especially "internal" modems, may have no hardware switches. (2) Set the RBBS-PC modem commands properly for your modem, especially the modem initialization string and firmware initialization string. (3) Initialize the modem's firmware. This makes permanent the settings that RBBS needs. (4) Set the baud rate to open modem at, normally to the highest speed the modem supports. (5) Set the communications port to what the modem is using. 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 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] RBBS-PC CPC17.3 Page 13 You will see a copyright notice, CONFIG will read in the current values, and then you will see a kind of index to the many pages of parameters you can set. There are about 300 parameters you can set in RBBS-PC, which sounds and can be intimidatingly 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. There is a single function for setting all the "key" parameters at once, and there are only a few you need to review in order to ensure that RBBS-PC will answer the telephone properly. You can jump to the screen with communications parameters by holding down the shift key and pressing F2. You should first make sure your communications port number is correct. RBBS-PC defaults to COM1 but you could be using COM2. It is possible to use COM3 or COM4 but there is no accepted standard for these and they are not recommended to beginners. Most internal modems come set up as COM2. Configuration parameter number 221 sets the communications port number. The key to getting your modem to work properly is configuration parameter 225: set modem commands. This will display a screen with the current settings. You should then pick "0" to set to defaults. This in turn will bring up another screen that will list a modem model and it's hardware switch settings. Keep pressing "Enter" to bring up another modem choice. When you see your modem, simply enter "S" for "select". If you do not see your modem, you should probably try using the "Hayes SmartModem 2400" settings because most modems are supposedly "100% Hayes compatible". Set any hardware switches according to the directions. If you do not have an entry fitting your modem, consult your modem manual. The key values to set are: Data Terminal Ready (DTR) to normal versus always on or high, Carrier Detect (CD) to normal versus on or high, and Auto Answer (AA) to off versus on. After setting the modem commands, you will probably want to initialize the modem's firmware using configuration function 231. You must have the port number set right and your modem must be on and connected in order for this function to work. You should see the lights on your modem blink, assuming you have an external modem. Modems have a maximum speed at which they will work, and most should be set at the maximum, whether it is 9600 or 2400 or 1200. The modem will simply not work if you use a speed higher than it supports. Modems will detect the speed of the incoming call and match it, but some will only kick down from the higher speeds, so it is generally best to set the initial speed to the highest supported value. Configuration parameter 228 sets the initial speed that RBBS "opens" the modem at. Now you are ready to make sure that RBBS-PC will answer incoming calls. Be sure you have your modem connected and on. Then simply type RBBS-PC[Enter] You should see a copyright screen. RBBS-PC will put up a screen with boxes. The modem lights should flash, and RBBS-PC should put up "Ready for Calls" in a box. Four lights on an external modem will normally be on: RBBS-PC CPC17.3 Page 14 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, you have 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 "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 have two primary tools: CONFIG.EXE, and a full screen editor. 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 configuration 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. 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 you will want to set up, such as bulletins, news, and conferences. An optional summary of the many features of RBBS is included in the documentation file FEATURES.ASC. RBBS-PC CPC17.3 Page 15 1.2 WHAT'S NEW IN 17.3? ----------------------- The most important changes are: (1) ALL VARIABLES in RBBS-PC source has been changed. This is the first step in an effort to make the RBBS-PC code more programmer friendly and to exploit the growing power of MicroSoft BASIC. A cross reference of old and new names is available in 173-NEW.ZIP. (2) Over 60 bugs/problems have been fixed. The most significant are: (a) RBBS-PC can finally handle the midnight rollover. New functions are available that effortlessly handle any time calculation. (b) User record in memory was sometimes "lost" (c) Restricting session time for an external net mail event was lost after a door (d) Board would sometimes hang when message quoted had to be reformatted to fit the margins (e) Archive view function no longer hangs under QB 4.5. (3) Code was rewritten to be faster and generally smaller (4) Over 20 enhancements were added, of which the most significant are: (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 RBBS-PC CPC17.3 Page 16 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 will inform you of the files omitted but try to download what there is time for instead of cancelling 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. (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 RBBS-PC CPC17.3 Page 17 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 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). RBBS-PC CPC17.3 Page 18 1.3 UPGRADING TO CPC17-3 ------------------------ When upgrading to CPC17-3 from earlier versions of RBBS-PC, follow the following 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 RBBSxPC.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 RBBSxPC.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 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 (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 differently (see configuration parameter 218). (c) If you turned on "enforce ratios", but exempted all security levels (this to get RBBS 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 RBBS-PC CPC17.3 Page 19 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 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. Read the pertinent sections in config on this topics if you are using them. 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. Last, review the documentation on the major areas of enhancements. Chapter 27 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 11.9. (c) You may want to create a new category of system bulletins - a NEWS facility (see section 6.13). The major changes in 17.2A were: (a) use of shelling triggered by the presence of BAT files to test uploads for integrity, convert uploads to a different format, and support viewing of text files inside ZIP files, and verbose list any compressed format, (b) greatly enhanced macros and questionnaires, including new data base functions, (c) enhanced doors interface, including an external control file for doors (DOORS.DEF) as well as the ability of a door to request that RBBS change the user record (DOUTx.DEF), pass any RBBS-PC CPC17.3 Page 20 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 subboards 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!!!!! ---- CPC17-3 does NOT change the structure of the user, message, or DEF files from that in 17.2. RBBS-PC CPC17.3 Page 21 1.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: 1. check what communication port is being used. 2. verify that this communications port exists. 3. verify that your modem is attached to it. 4. verify that your modem is powered up. 5. verify that your modem is configured properly. 6. verify that CONFIG knows what kind of modem you're using. 7. verify that the modem cable supports all ten signals required by RBBS-PC (see Appendix S). 8. verify that DTR (Data Terminal Ready) and CD (Carrier Detect) are set to "normal" rather than always "on" (sometimes called "true" and "forced" instead). 9. verify that each DOS subdirectory referred to in CONFIG exists. 10. 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: 1. Phone line is not plugged into the modem. 2. Modem is not powered on. 3. Modem is not connected to the communications port that RBBS-PC was told to use. 4. Your modem is not "Hayes compatible" enough to handle the modem commands described in section 10. 5. 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 RBBS-PC CPC17.3 Page 22 number you told CONFIG you wanted to answer after, RBBS-PC sends the "ATA" command to tell the the modem to answer the phone (see section 12). If your modem does NOT send the characters "RING" each time the phone rings, THEN 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. Relying on the modem result code, or allowing the modem to auto-answer the phone, are the preferred methods. IT LOCKS UP MY SYSTEM! This may be caused by one of the following things: 1. 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. 2. You indicated in CONFIG that you were running one of the supported networks (i.e. CORVUS, MultiLink, Orchid, etc.), but you aren't. 3. 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. 4. 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. 5. 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). 6. Your system does not support standard DOS system calls for screen writes. Try setting configuration parameter 39 to use BASIC for screen writes. 7. Your system is not as PC compatible as it should be and may use strange interrupts. Try turning assembler routines off (parameter 38). RBBS-PC CPC17.3 Page 23 2. "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 8250 UART chip RS-232 adapter with an Intel 16550AN UART chip Modem Any Hayes Smartmodem 1200, or 100% compatible modem A US Robotics Courier HST dual standard 9600 bps modem Phone line Voice grade telephone connection for modem Voice grade telephone connection for modem Modem cable 25 pin RS-232 shielded cable 25 pin RS-232 shielded cable RAM 512K RAM available for DOS and RBBS-PC 640K RAM available for DOS and RBBS-PC Disk size 20MB hard disk 120MB hard disk DOS version PC-DOS version 2.1 PC-DOS 3.3 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. 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 Y. 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 CPC13-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. RBBS-PC CPC17.3 Page 24 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 vendor and ask him to explain why it doesn't work, if the modem is compatible. RBBS-PC CPC17.3 Page 25 3. RBBS-PC's SUPPORT POLICIES ----------------------------- 3.1 RBBS-PC's User Support Policy --------------------------------- RBBS 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 distributes its help via a network of volunteers. These include: o Written documentation with RBBS, which you are reading. This is more a reference than a guide for novices, however. o 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 remains upward compatible with 15.1C, and virtually everything in the book still applies.) o A commercial product, "RBBS-PC in a Box", a CD-ROM disc which has 7000 shareware and public domain programs stored in compressed format, and has RBBS virtually pre-installed. You can be online only minutes after installing the CD-ROM. For information and ordering, contact Loren Jones (number listed below). o Network mail. Both RBBS-Net and RelayNet have RBBS support conferences. For RBBS-Net, contract Rod Bowman (number listed below). For RelayNet contact Greg Snyder (703-323-1782, data number). o Telephone support. The authors of RBBS do not get paid for their work on the system and typically have other jobs, so the amount of time for direct voice support is limited. But, time permitting, the authors DO accept calls and are willing to help, and can often refer you to others who can help. There are two support numbers you can call with RBBS questions. They are: (407) 627-9767 -- Voice mail system of Doug Azzarito (203) 268-9656 -- Answering machine of Tom Mack o Support Boards. Support boards are BBS's where the SysOp: o commits to running RBBS for the foreseeable future o has an at least one free, public line o is regularly available for helping others o makes the latest version of RBBS available, either electronically or by mail RBBS-PC CPC17.3 Page 26 Please realize that bulletin boards may cease to exist, or change their phone numbers, and that other commitmets can make people unavailable. Bearing that in mind, the list of BBSes knowledgeable about RBBS-PC include: Arizona Tucson: Gene Lowry, Bigfoot RBBS. (602) 886-7943 California Alta Loma: Rod Bowman, The PC Spectrum. (714) 945-2612, 2 lines Connecticut Trumbull: Tom Mack, The Second Ring. (203) 268-5315 Florida Tampa: Dave Hacquebord, The Sunshine Board. (813) 887-3984 and (813) 885-4659 West Palm Beach: Doug Azzarito, Technology Consultants RBBS. (407) 627-6969 and (407) 627-6862 Delray Beach: Mark Lautenschlager, Boca Bytes. (407) 276-6263 Kentucky Lexington: Ronald Nutter, Bluegrass RBBS. (606) 272-0499 (Fill out SysOp questionnaire) Illinois LaGrange: Loren Jones, RBBS-PC of Chicago. (704) 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) Pennsylvania Sharon Hill (Philadelphia): Mark Horninger, Electric Playground. (215) 534-1466 Virgina Arlington: Lee Pollard, Death Star. (301) 839-0705 RBBS-PC CPC17.3 Page 27 Fairfax: Ken Goosens, Your Place. (703) 978-6360, 3 lines o Help by Topic Ken Goosens maintains an interactive, on-line data base of people who volunteer to help with RBBS on particular topics. Again, though, not every volunteer will always be available. The list includes: Topic Data Number Last Name First Name Auto Maintanence 606-272-0499 NUTTER RONALD BASIC 416-783-7094 CASSIDY JOE Batch Files 407-627-6969 AZZARITO DOUG CD-ROM 606-272-0499 NUTTER RONALD Communication 301-839-0705 POLLARD LEE Compiling 703-978-6360 GOOSENS KEN Conferences 417-862-9824 MIDDLETON WILLIAM Conferences 407-627-6969 AZZARITO DOUG Conferences 612-721-1177 LASLEY JOHN Conferences 703-255-1275 DORER FRANCIS Configuration 606-272-0499 NUTTER RONALD Configuration 606-789-3423 BALDRIDGE CHARLES Desktop Publish 313-995-2100 MOORE CORWIN Desqview 202-265-4496 MONDALE ALEX Desqview 606-272-0499 NUTTER RONALD Desqview 703-256-4777 KORCEL BLAINE Desqview 703-756-6109 CROCKFORD MARIANNE Desqview 912-432-2440 MULDROW WARREN Doors 201-580-0486 CONGER EZRA Doors 214-790-0754 COLLINS DARWIN Doors 416-783-7094 CASSIDY JOE Doors 503-664-3756 ANSTINE MITCHELL Doors 606-789-3423 BALDRIDGE CHARLES Doors 612-721-1177 LASLEY JOHN DOUBLEDOS 703-978-6360 BAZERGHI ERIC FMS 201-580-0486 CONGER EZRA FMS 301-384-9302 MCGOLDRICK LARRY FMS 407-627-6969 AZZARITO DOUG FMS 416-783-7094 CASSIDY JOE FMS 606-272-0499 NUTTER RONALD FMS 606-789-3423 BALDRIDGE CHARLES FMS 703-255-1275 DORER FRANCIS FMS 703-978-6360 GOOSENS KEN FMS 912-432-2440 MULDROW WARREN File Maint. 612-721-1177 LASLEY JOHN File Maint. 703-978-6360 BAZERGHI ERIC File maint. 703-256-4777 KORCEL BLAINE HST 912-432-2440 MULDROW WARREN Hardware 606-272-0499 NUTTER RONALD LANTASTIC 606-272-0499 NUTTER RONALD Macros 416-783-7094 CASSIDY JOE Macros 503-664-3756 ANSTINE MITCHELL Macros 703-978-6360 GOOSENS KEN Marcos 202-265-4496 MONDALE ALEX Modems 703-978-6360 GOOSENS KEN Network 301-839-0705 POLLARD LEE RBBS-PC CPC17.3 Page 28 Novell Netware 503-664-3756 ANSTINE MITCHELL Novell Netware 703-256-4777 KORCEL BLAINE PC-Slaves 407-627-6969 AZZARITO DOUG PC-Slaves 703-756-6109 CROCKFORD MARIANNE PC-Slaves 703-978-6360 GOOSENS KEN PUI 416-783-7094 CASSIDY JOE PUI 912-432-2440 MULDROW WARREN Pers downloads 703-255-1275 DORER FRANCIS Personal Radio 313-995-2100 MOORE CORWIN Personal dwld 606-789-3423 BALDRIDGE CHARLES Programming 703-978-6360 BAZERGHI ERIC Protocols 201-580-0486 CONGER EZRA Protocols 301-839-0705 POLLARD LEE Protocols 703-978-6360 BAZERGHI ERIC Protocols 703-978-6360 GOOSENS KEN Protocols 912-432-2440 MULDROW WARREN Questionnaires 703-978-6360 GOOSENS KEN Quick Basic 618-465-0808 SLAUGHTER CARL Setup 301-384-9302 MCGOLDRICK LARRY Setup 301-870-5963 ISAAC MICHAEL Setup 417-862-9824 MIDDLETON WILLIAM Setup 703-255-1275 DORER FRANCIS Setup 703-756-6109 CROCKFORD MARIANNE Smart Text 407-627-6969 AZZARITO DOUG Startup 301-797-7133 SHERMAN WOODY Sub-board 606-272-0499 NUTTER RONALD SubBoards 612-721-1177 LASLEY JOHN Subboard 417-862-9824 MIDDLETON WILLIAM Submenus 703-978-6360 GOOSENS KEN Time Lock 407-627-6969 AZZARITO DOUG Uploads 703-978-6360 BAZERGHI ERIC User Interface 313-995-2100 MOORE CORWIN Utilities 214-790-0754 COLLINS DARWIN 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 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 is to: o fix any problems, on a priority basis o steadily refine and enhance RBBS to better serve the needs of its users o help support and coordinate contributions, testing, and releases RBBS 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. RBBS-PC CPC17.3 Page 29 3.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 purposes of RBBS-PC are outlined in section 0 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 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 he is in complete control and need not make the .MRG "universal" (i.e. it need only support his 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. RBBS-PC CPC17.3 Page 30 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 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) Vendors who have chosen to make this third type of commitment to RBBS-PC and the PC user community deserve the respect and encouragement of every PC RBBS-PC CPC17.3 Page 31 user and are (alphabetically): 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. 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 RBBS-PC CPC17.3 Page 32 (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 benefited 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 Section 21 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. RBBS-PC CPC17.3 Page 33 4. 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 CPC17-3. 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). Version CPC17-3 of 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 T 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 CPC17-3 (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 3.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 J for details. RBBS-PC CPC17.3 Page 34 5. 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 CALLERS ARCWORKx.DEF | USERS COMMENTS NODExWRK System MESSAGES.BAK DOUTx.DEF RBBSxF1.DEF Files USERS.BAK DKxxxx.ARC DORINFOx.DEF | RBBSxPC.DEF DRSTx.DEF \|/ 99.DIR (upload directory) ----- The following "text files" are "static" in length and can be shared safely: ----- NEWUSER RBBS-CDR.DEF /|\ MENU0 --> MENUA LGx.DEF | BULLET, BULLET1 --> BULLETn AUTOPAGE.DEF | DIR.DIR, aa.DIR --> bb.DIR CONFMAIL.DEF | CDR.CDR, aa.CDR --> bb.CDR RBBS-CDR.DEF Text FILESEC PROTO.DEF Files CONFENCE RBBS-REG.DEF | xxxx.PUI PRELOG.DEF | PASSWRDS EPILOG.DEF | xx.HLP PRIV.DEF | HELPxx AUTOPAGE.DEF \|/ TRASHCAN RBBSxTM.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 issues the NAME function of BASIC 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 (RBBSxPC.DEF) for each copy of RBBS-PC. 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. RBBS-PC CPC17.3 Page 35 5.1 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 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-CPC12-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 CwFIG. 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. USERS 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 UwRS file or not. (Note that in a multiple RBBS-PC enviroment, the USERS file should only be "packed" when RBBS-PC CPC17.3 Page 36 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. 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 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. 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.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 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. RBBS-PC CPC17.3 Page 37 LOCKED FILE STATUS DISPLAY RBwBS-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 "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". ARCWORKx.DEF This file is created as output by the file view command and contains the contents of the archived file being inquired against. QMXFER.ERR This file is created as output by QMXFER.COM to notify RBBS-PC of the results of an external file protocol transfer. DKxxxx.ARC This file is created as output by the Library Sub-System archive program. This work file is deleted each time RBBS-PC recycles. DORINFOx.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". It consists of an twelve record file that contains the following information: 1. The name of the RBBS-PC system 2. The SysOp's first name 3. The SysOp's last name 4. The communications port being used 5. The baud rate and parity with which the caller logged on, and the baud rate at which RBBS-PC is connected to the modem 6. The network type (if any) RBBS-PC is running in 7. The caller's first name 8. The caller's last name 9. The city and state the caller is from 10. The caller's graphics preferences 11. The caller's security level 12. The caller's time remaining in the current session RBBS-PC CPC17.3 Page 38 NODExWRK 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. DOUTx.DEF Used by doors to communicate back to RBBS-PC. DRSTx.DEF Internal file used by RBBS-PC to restore itself upon return from doors. RBBS-PC CPC17.3 Page 39 5.2 RBBS-PC Text Files ----------------------- Similarly, the RBBS-PC "text" files are both static and variable in length. The "text" files used by RBBS-PC are: BULLET This is a text menu file that is printed 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. RBBS-PC can display different text files based on a user's current graphics option (which can be changed with the Graphics command on the Utility menu). This will affect such standard RBBS-PC system files as HELPxx, BULLET, MENU's, etc. In order for a user to see either of these two different types of "graphics" files, the following items must have occurred: 1. The caller must have logged on with 8 bit word, no parity, and 1 stop bit. 2. The caller must have selected graphics (either "ASCII" or "Color-IBM"), and the file must exist with a filename ending in either: "G" For files containing the IBM PC "character graphic" set (sometimes called the "line drawing characters"), ASCII characters whose values are in the range 128 to 256. "C" Includes the above, and adds commands compatible with the ANSI specification for controlling screen colors and cursor positioning. (Note that the caller's software MUST be capable of displaying color based on ANSI commands for this to work.) RBBS-PC will check to see if a "graphics" files exists by appending a "G" or "C" to the file name (e.g. WELCOMEC instead of WELCOME). 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. DIR.DIR, aa.DIR --> nn.DIR The DIR.DIR file, which can be renamed using the CONFIG utility, is simply an ASCII text file which contains a listing of all the categories in your FMS.DIR (FMS = File Management System, more on this later). Each of these RBBS-PC CPC17.3 Page 40 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 take the form of xx.DIR, where "xx" 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, aa.CDR --> nn.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, aa.CDR --> nn.CDR, should be meaningful and should be reflected in the DIR.CDR file. FILESEC This file controls which security levels can download from which paths, and it is more fully described in section 14.4 (RBBS-PC security). 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: MAIN.HLP A text file that is printed when <H>elp is requested on the main function prompt. It contains command information. HELP03 A text file that describes the message protection options when <?> is entered after the message <E>nter command is executed at the main message menu. HELP04 A text file that describes the message entry subfunctions when <?> is entered at the subfunction prompt. FILE.HLP A text file that is printed when <H>elp is entered in the files subsystem function prompt. UTIL.HLP A text file printed when <H>elp is requested in the utility subsystem function prompt. HELP09 A text file printed when <H>elp is requested for type of graphics a user wants (none, ASCII, color/music). RBBS-PC CPC17.3 Page 41 LIBR.HLP A text file that is printed when <H>elp is entered within the library subsystem. SMARTTXT.HLP A text file that 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 6.9 for a more complete description of this feature. UPCAT.HLP This is the file that is used to help users categorize their uploads. SECVIO.HLP If this file is present, it is shown to the caller each time a security violation occurs. MENU0 --> A 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 14.3 on security. PRELOG A text file displayed to callers prior to asking for their first/last name and password. 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 11.6. The RBBS-CDR.DEF (and matching FMS directory) file can be downloaded from Jon Martins' system. It is not distributed with RBBS-PC because of it's size (500K). 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). CONFENCE A text file displayed to users who issue the J)oin function from the main menu. It can be created by any text editor that can create an ASCII file and should contain a list of the available conferences. RBBS-PC CPC17.3 Page 42 LGx.DEF This is the file displayed, if present, to users based on security level when the caller logs on. The "x" defines 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 Level File name Sample text for level greeting file 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 (more on this later). RBBS-PC CPC17.3 Page 43 RBBSxF1.DEF This is the file dynamically created when the local SysOp exits to DOS. 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. PRIV.DEF This file contains the information used for "personal downloading", described in section 11.7. 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, and can be as extensive as you may like (or you can have none at all). MAIN.PUI This is the programmable user interface file that allows the SysOp to structure the RBBS-PC commands as desired. 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. 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 14.1 for a more comprehensive description of this feature. 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 6.11 for a more comprehensive description of this feature. RBBS-PC CPC17.3 Page 44 6. PLANNING YOUR USER INTERFACE --------------------------------- RBBS-PC provides each SysOp the maximum control over what is presented to callers. There are three areas of control: 1. The menus presented to novice callers. 2. What is included in the prompt all users get. 3. What symbol invokes a particular function. 6.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. RBBS-PC supports three types of files, which the caller can select using his graphics preference. A file with no graphics has only typeable text. ASCII graphics means that all 255 ASCII values display on the caller's screen using the IBM PC display conventions. This allows support for many symbols, such as straight lines, a heart, and many others. Using these conventions, many fancy graphic displays are possible. Last, a use can request color graphics, which means that the caller's monitor supports not only the IBM display conventions but supports ANSI commands for controlling the monitor, which include such things as color as well as special modes like blinking. Using ANSI commands, it is possible to fully control the caller's monitor. One can go so far as to create animated pictures. Menu files are known by their names. The format is XXXXXXXY, where XXXXXXX is the base file name and Y is a one-character addition. Y is nothing for no graphics, G for ASCII graphics, and C for color graphics. RBBS-PC will look for a file based on the users graphic preference and display the graphics version if it exists. Otherwise, the non-graphics file is used. Graphics files have more characters in them and therefore take longer to transmit. Creating them is not easy. However, there are special ANSI and graphics editors which make creating such files much easier. RBBS-PC CPC17.3 Page 45 6.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: 1. Whether the section name is shown. 2. Whether the letters of the available commands are shown. The commands in RBBS-PC are divided into four sections: MAIN, FILE, UTILITY and LIBRARY. Each has a set of commands in them and there are commands to move between sections. If the SysOp elects for the section name to be shown, the command line will read "<section> command", otherwise "Your command". The default is to show the section. RBBS-PC normally prompts a caller with the commands available in each section that the caller has sufficient security to invoke. Each command is a single letter and is shown separated from the others by a comma. These command letters can either be suppressed or not. By leaving them on a SysOp provides each caller with a terse but helpful reminder of what commands are available to them. RBBS-PC CPC17.3 Page 46 6.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: section|? @ 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 | UTILITY|? B C E F G H L M P Q R S T U X | LIBRARY|? A C D G H L Q S V X | GLOBAL |? H Q X Four commands, ? H Q and X, have the same meaning in every section and are known as "global." The other commands all have unique function specific for the section within which they are invoked. For example, S in the main section stands for S)can messages, but S)ubstring search in files & Library, and S)tatistics on the board and session in utilities. Symbols 1-7 stand 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. RBBS-PC CPC17.3 Page 47 6.4 RBBS-PC's "Wrap-around" Command Search ------------------------------------------ There is a special option available in CONFIG which gives the SysOp unusual flexibility in configuring the user interface. A caller is always "in" a section, that is where RBBS-PC looks for a command that the user requests to see whether it is a valid command. The "wrap around" option controls how RBBS-PC looks 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 6.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 MAIN->FILE->UTILITY->LIBRARY->GLOBAL->SysOp and the search is circular, as depicted below: ,-->- SysOp --> MAIN -->---. | | | | GLOBAL FILE | | | | `-<- LIBRARY -<- UTILITY <-' The current section determines only where the search starts. If roll- around is used, the search will go completely around. The real reason that "global" commands are global is that RBBS-PC always searches after the library section if a command is not in the current section. SysOp commands are therefore global for the same reason. The important feature that roll-around supports is that a command with a unique letter works in all sections. Thus W)ho will work everywhere the same if roll-around is enabled. THIS ALLOWS THE SysOp TO SUPPRESS SECTIONS. In effect, by enabling roll-around and giving each command 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. RBBS-PC CPC17.3 Page 48 6.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. All that is needed to do is to eliminate the overlap in command letters between the two sections. The main section and the file section share the letters D, P, S, and V. V is used to "view" a conference in the main section and "view" what is contained in an archived file. D is difficult because both D)oors and D)ownload are entrenched and natural options. One could leave D for the most frequently used function, say download, then use a special but arbitrary symbol like # for doors. Similarly, V could be left for viewing conference mail in the main section and a special but arbitrary symbol like & for viewing archived files in the file section. S)earch for substrings could be replaced by F)ind since F for going to F)iles is not 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 lease impact on callers. U has to be upload. Note that Quit could still get one to utilities. Using Q;U we can then disable U in the main menu. If three symbols is too much of an exception we could use W for W)rite user preferences and use the special, but arbitrary, symbol % to find who else is on. Then we could revise the main menu to read R B B S M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- MESSAGES -- -- SYSTEM -- - FILES - - UTILITIES - - ELSEWHERE - [E]nter Message [A]nswer survey [D]ownload [H]elp (or ?) [Q]uit [K]ill Message [B]ulletins [L]ist [%]Who's on [F]iles (Q;F) [P]ersonal Mail [C]omment [N]ew [X]pert on/off [G]oodbye (Q;S) [R]ead Messages [#]DOORS [M]y pers. files [W]rite user [S]can Msg header [I]nitial Wel [U]pload preferences [T]opic msg scan [J]oin a conf. [&]View ARC files (Q;U) [V]iew mail wait [O]perator Page [Z]ippy search [@]Library RBBS-PC CPC17.3 Page 49 This menu could be re-written without any apparent sub-sections (by using the letter F to find who else is on) as 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 [P]ersonal mail [&]View ARC files [#]DOORS [K]ill message [Q]uit [W]rite user pref [D]ownload [L]ist files [R]ead messages [X]pert on/off [E]nter msg [N]ew files [S]can messages [Z]ippy search [F]ind who's on [O]perator page [T]opic msg scan [@]Library [G]oodby 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 a.) 26 (letters in the alphabet), or b.) 36 (letters in the alphabet plus the numbers 0 through 9), or c.) 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 wanted 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 pretty terse, but that simply means users would spend more time in novice mode before using expert. Now suppose that only a single command line was desired and that the commands from the "Utilities" menu commands were to be added to the above. The "global" H, ?, Q, and X commands already are in the single command line. M for message margin can remain unchanged since it is unique to the Utilities subsystem. In order to accommodate the redundancy of letters that exist by including the Utilities subsystem's commands, the W command for the main message subsystem can be re-enabled and the remote SysOps commands be eliminated in order to re-use the numbers. The Utilities subsystem commands B, C, F, G, L, R, and S could then be replaced by the numbers 1 through 9. The Utilities subsystem commands T, U, E, and P could be replaced by the commands <, >, \, and /, respectively. RBBS-PC CPC17.3 Page 50 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? RBBS-PC CPC17.3 Page 51 6.6 RBBS-PC'S Programmable User Interface (PUI) ----------------------------------------------- The programmable user interface (PUI, pronounced "pee u eye") lets the SysOp take TOTAL CONTROL over what the caller is presented with, including: o the novice menu o the prompt line o the organization of commands into groups (sections) o the flow between sections o unlimited levels of nested menus. This allows 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 the RBBS-PC BASIC source code. These functions can be assigned any command letter desired in the configuration program. PUI lets the SysOp completely control how these commands are presented to the user - allowing RBBS-PC to "emulate" virtually any other host communications environment that the SysOp's callers may be familiar with. If no PUI is provided, RBBS-PC defaults to dividing the commands into a MAIN, FILES, UTILITIES, and LIBRARY section. RBBS-PC's PUI gives each SysOp the flexibility to tailor RBBS-PC to meet special needs. In effect, RBBS-PC's PUI allows the SysOp to adjust RBBS-PC to what the SysOp wants, rather than forcing the SysOp and his callers to conform to RBBS-PC. However, unlike RBBS-PC, the PUI does not adjust the prompt to show only the commands that the user has sufficient security to do. And, of course, PUI takes much more time to design and implement. When the SysOp takes control of what the user is presented by using the PUI, RBBS-PC does what the SysOp has explicitly set up -- and nothing else! For example, RBBS-PC's "global" commands, like help and the expert toggle, are no longer automatically available everywhere. They are available only where the SysOp has indicated via the PUI. RBBS-PC's default user interface has evolved over the years to represent what the callers found useful (not the SysOps!). A great deal of time and thought went into RBBS-PC's default user interface, and it is easy to overlook important things when a SysOp goes about setting up his or her own. When using the PUI assume that a new user interface will take time to both develop and refine (based on your callers feedback). Designing and implementing a PUI is not a simple undertaking as it is a total replacement for RBBS-PC's standard user interface. RBBS-PC CPC17.3 Page 52 6.6.1 An Example Using PUI -------------------------- The main menu in RBBS-PC can represent a bewildering variety of commands, especially to a new user. Psychologists often say that human beings can effectively deal with only at most 7 choices at one time, whereas RBBS-PC has 10 more than that in its main section. To help people out in this situation, the different choices in RBBS-PC are grouped into related commands, but the choices can still be overwhelming. Some SysOps have therefore wanted 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 in turn puts one in a section where commands pertinent 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. RBBS-PC CPC17.3 Page 53 6.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 the configuration program. 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 1: <name of novice menu> line 2: <prompt to display> line 3: <valid commands>,<corresponding RBBS-PC commands> line 4: <which valid commands are menus> line 5: <names of PUI's that are menus> line 6: <letter of quit command> line 7: <prompt for quit command> line 8: <valid sub-commands of quit command> line 9: <which quit commands are PUI's> line 10: <names of menu PUI's 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 PUI's 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, unless 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 a default section of main, file, library, and utilities). 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 RBBS-PC CPC17.3 Page 54 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 positions. 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. The file name can include trailing spaces, and must if shorter than 7 characters (any blanks in the name will be omitted). Note that all PUI files must be in same drive/path as the novice menu in line 1. The last 5 lines in the PUI file concern how control goes from one PUI to another. The PUI processing supports a "quit to" command in which the caller can jump to other menus - which one is specified in the subcommands to the quit command (just like RBBS-PC's "quit" to command). Line 6 is the symbol (in the valid commands) which is the quit-to command. It must be a single capital letter. Line 7 is the prompt for the quit-to command, to be presented to callers after they select the quit-to command (type ahead is supported). Line 8 is the list of the valid sub-commands of the quit-to command. Each command must be a capital letter. Line 9 tells which of the valid subcommands are PUI commands. If a sub-command is valid but not a PUI command, control will be passed to RBBS-PC to process the quit-to command. For example, Quit-to S)ystem for hanging up would have to be processed this way. Line 10 tells what are the names of the PUI files for each PUI command in line 9. The format of the PUI names is exactly the same as in line 5 -- 7 characters blank filled to the right if shorter. The following file MAIN.PUI installs the example that was discussed in the previous section: MMENU Enter choice: <F,M,U,G> FGMU," G " FMU FMENU MAILM UMENU <blank line> <blank line> <blank line> <blank line> <blank line> 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, RBBS-PC CPC17.3 Page 55 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 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 presuppose that RBBS-PC has been configured with the following symbols for the underlying RBBS-PC commands: MAIN = normal: ABCDEFIJKOPRSTUVW reconfigured: ABC>EFIJKOPRSTU\W FILES = normal: DGLNPSUV reconfigured: DGLNYZ^V UTILITY = normal: BCEFGLMPRSTU reconfigured: !#E$<&M*()-+ GLOBAL = normal: H?QX reconfigured: H?QX SysOp = normal: 1234567 reconfigured: 1234567 LIBRARY = normal: ACDGLSV reconfigured: []{G}:' RBBS-PC CPC17.3 Page 56 6.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, Tokoyo, or Bangkok, soldier! PICKUP - do you have what it takes? Demos - all self running DBIII - Special version of DB3 adopted for remote usage ORACLE - see the power of SQL. Full screen if you emulate ANSI. ADVENT - our own home brewed ... With sub-menus, the user could see a single, 3 item menu Doors are available for: MGAME - multi-user games SGAME - single-user games DEMO - self running demos When the caller picks one of these three, a new menu comes up that lists the particular doors for each category. For example, after picking MGAME the caller sees Multi-User Games available include: TREK - explore the galaxy, compete with 12 other players NAPOLEON - be Russia, Italy, or England and fight the computer 3DCHESS - are you ready, Spock? RBBS-PC's sub-menu capabilities allow SysOps to set up "tree-structured", "key word" paths to options. Bulletins provide an example where this type of structure can be very useful. Bulletins have two main uses: short, system-wide announcements, and a standard stock of text files for policies and procedures for a RBBS-PC. Some SysOps, however, have wanted to put up RBBS-PC CPC17.3 Page 57 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 top 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. Bulletins become a menu-driven way of selecting documents to browse. There are four general changes to the commands when utilizing RBBS-PC's "sub-menu" features. First, to get the menu displayed when in expert mode, the caller selects the L)ist function. Second, the menu processing routine will search for a file associated with the option selected. Bulletins and file directories will be displayed to the user. These are essentially "display" functions. If a conference exist with the name specified, RBBS-PC will attempt to join it. If a door exists AND it is on the menu, RBBS-PC will attempt to invoke it. This means that the option does not have to be listed explicitly in the menu. Options can be hidden from the user and still work (except for doors). A "secret" conference can be available only if the caller already knows the name. Third, the prompt is more standardized. Fourth, the standard way to get out of the menu is just to press [ENTER]. The bulletins function has been generalized so that bulletins can use names and not just numbers. For example, selecting "B" as the bulletin prefix, the above bulletins would be files BNAT, BMIDW, BNUTRI, BFLAN, and BDRUG. However, the search for new bulletins works properly only if numbers are used to name bulletins, and the prompt for bulletins simply asks for the bulletin and does not mention any numbers. RBBS-PC CPC17.3 Page 58 6.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 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. Callers can list any menu at any time as long as the menu they wish to list has the qualifier "MNU". 6.7.2 Shared Options Across Sub-menus ------------------------------------- Each option on a sub-menus used to have to be uniquely named, because they all shared the same prefix. Hence no two submenus could offer the same option -- RBBS-PC couldn't have all menus with 1,2,... or A,B,C,... as options to pick. RBBS-PC supports using same response on different menus. The way that this works is RBBS-PC now 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 N is main bulletin menu A ---- 2 BNA.MNU submenu get with choice A / \ 3 BNB.MNU submenu get with choice B / BNC.MNU submenu get with choice C / / 1 N ---- B ---- 2 BNA1, BNA2, BNA3 bulletins get under NA \ \ 3 BNB1, BNB2, BNB3 bulletins get under NB \ BNC1, BNC2, BNC3 bulletins get under NC \ / 1 C ---- 2 \ 3 RBBS-PC CPC17.3 Page 59 6.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 that pioneered by Prokey, except that in RBBS-PC the SysOp defines the macros and the caller invokes them transparently without knowing. Macros are an extension of the effort in RBBS-PC to give the SysOp control over the user interface. RBBS-PC allows the SysOp to substitute any letter for any command, to group the commands in any way desired, and to have unlimited submenus. Macros give the SysOps the ability to create and mold their RBBS-PC into an unlimited variation of commands. RBBS-PC's "macro" command facilities frees every SysOp from having to impose the rigid and inflexible command structure on their callers that other more limited PC-based bulletin board systems impose. 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 symbols. For example, "DOOR" and "OPEN" can be used to invoke doors. This makes it easy to make all commands available on a single level. For example, the otherwise irreconcilable conflict between "Download" and "Door" can be resolved by using the full word "DOOR" for doors. 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). Since doors are unlimited in nature, RBBS-PC thus can have UNLIMITED commands. A string of RBBS-PC commands can be stored in a macro for many different types of purposes, including (but not limited to) setting up demos, showing a user what to do rather than just explaining it in words, automating testing when doing RBBS-PC development, or automating a check-out of all of the RBBS-PC functions. 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 all can be ordered, and 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. RBBS-PC CPC17.3 Page 60 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 writing to a file. A block of text functions like a template into which data values are substituted. Macros can be used to give "tours" of your RBBS-PC -- to showcase new or special features. Macros have security levels built into them to control access, just like regular commands, and they can be forced to operate only in certain contexts. Macros can be 1.) invoked anywhere within RBBS-PC -- including questionnaires, 2.) unlimited in length, 3.) used even when the caller has "turbo" key feature enabled, 4.) used with "Smart" Text (see section 6.9), 5.) used to store responses that can be manipulated latter, and 6.) 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 prompts for text to search for. 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 CPC17.3 Page 61 6.8.1 How to Set Up "Macros" --------------------------- The first line in a macro simply REPLACES the macro name and therefore operates in its place. If PREVIEW is typed in and the first line is "B" for bulletins, then "B" will replace "PREVIEW" and the command will proceed exactly as if "B" has been typed instead of "PREVIEW". Subsequent lines in a macro are read in a line at a time and processed. Two configuration 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 default names 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, your processing will be speed up if you make the macro extension empty. The first line within a "macro" contains the numeric integer value which represents the minimum security to use the macro, and an optional limitation on the scope of the macro, in which it will be operative, including o anywhere inside a section o anywhere inside a command o only at a section and not inside. The constraint is governed by an extra parameter to the 1st line in a macro file. The new format 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 PCB means that when inside the main J)oin, the macro "PCB" will be substituted for "1". (So "J 1" does the work of "J PCB".) The "{EN" means not to echo what the macro substitutes (user does not see "PCB"). RBBS-PC CPC17.3 Page 62 To make a macro be operative only at a section prompt and not inside, add a " /" to the end of the section constraint. For example, 4/M / means that the macro applies only at the main section prompt. For example, the macro SP.MCR 4/M / {EN J SEMIPRV will substitute "J SEMIPRV" for "SP" when at the main prompt, but NOT for "SP" inside the message read command ("R SP L"). Note: a macro will be ignored if it's name is the same as a command symbol. Hence 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 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. RBBS-PC CPC17.3 Page 63 6.8.2 Macro Commands -------------------- RBBS-PC "Macro" Commands includes 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 macro commands include: o display a line with no carriage return o display a line with carriage return o display a block of lines o display a file o prompt for a response and store answer o pause a specified # of seconds o stack keystrokes o append a block of lines to a file. o control whether the macro text is echoed or not o retrieve values from a file into a form which is the displayed o assign a value to a work variable o edit answers to a macro question 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 - use text that follows as a prompt and store the result. 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 if 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 *0 - display what follows on the line with no carriage return. {*0Press any key to continue *1 - display what follows on the line with a carriage return. {*1{FN, I hope you enjoyed your tour of the board! The caller's first name is substituted for the "Smart" Text variable "{FN". *B - display what follows on subsequent lines, each line with a carriage return, up to the line beginning with "{END". {*B RBBS-PC CPC17.3 Page 64 Macro commands have the 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 resultant answer in an internal working variable numbered nn. nn must be two digits and can be 01, 02, 03, ..., 99. CONFIG parameter 94 controls the maximum # of work variables. {01Please enter the Department you work for: {02Please enter your Office number: This will store the answers in work variable # 1 and 2, which can be subsequently referenced as "[1]" and "[2]". You can have as many work variables as specified in CONFIG parameter 94. Variables that are reused have their values overwritten. WT - pause for the number of seconds specified after "WT". {WT 2 will wait for 2 seconds. >> - append the following block of text to the file specified on this line. {>> C:MACRO.DAT "{FN","{LN","[1]","[2]" {END will append the following line to the file named MACRO.DAT on drive C:, assuming the caller is KEN GOOSENS, and he responded to the above prompts for Department with "Controller" and Office # with "107". Then the line what would be written out is: "KEN","GOOSENS","Controller","107" As many lines can be included as desired. Simply end the block to be written out with "{END" as the beginning of the line. Some data base managers want fixed length files and this is possible in the macro append. Just add "/FL" on the macro command line. Rather than replace, the substitution will overlay the line at the RBBS-PC CPC17.3 Page 65 "[", 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. The executes are like "go to's" in that execution of the current macro ceases and does not return automatically when ORDER is done. The full file name of the macro to "go to" is not here used (i.e. ORDER.MCR), only the file prefix -- ORDER. As is shown in the example of the ON command, the macro name can have a drive/path and/or extension. If only a prefix is put in, RBBS-PC will automatically add the drive/path and extension for macros specified in CONFIG parameter 79 and parameter 80. Putting in a drive/path/extension that is different from CONFIG's assures that no caller can invoke the macro -- it only can be used internally by your application. ON - Case logic for macros. This allows responses to be tested against and branching logic developed within a "macro". An example would be: {ON 1 {==A RBBS-PC CPC17.3 Page 66 {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 Same commands but 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 RBBS-PC CPC17.3 Page 67 Note that spaces occur after the "[4]". If the file RHLP.DAT contains "DOORS","404-981-7781","405-988-7782","Wizard","The" "PROTOCOLS","709-123-4567","0","Horse","Crazy" then the caller would see -TOPIC- - DATA # - - VOICE # - -First Name- -Last Name- DOORS 404-981-7781 405-988-7782 The Wizard PROTOCOLS 709-123-4567 0 Crazy Horse 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: The Wizard DOORS 404-981-7781405-988-7782 Crazy Horse PROTOCOLS 709-123-45670 This would produce the following for the caller: -TOPIC- - DATA # - - VOICE # - - Name - DOORS 404-981-7781 405-988-7782 The Wizard PROTOCOLS 709-123-4567 0 Crazy Horse 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 three had a value "123abc" then "[3](3:3)" would have "3ab" 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 - Questions in macros can now have edits on the answers: the edits can constrain the answer to o one of a list o a numeric value between two values o a character value between two values An editing constraint must be put in front of the actual macro RBBS-PC CPC17.3 Page 68 question it applies to, and a constraint applies only to the next question and does not remain operative. The commands for these are respectively "LV" (List Verify), "NV" (Numeric Verify), and "CV" (Character Verify). The list verify uses the first character after the command as a delimiter between valid responses. E.g. "{LV;R;A;E;" means that only "R", "A", and "E" will be accepted as answers ("{LV/R/A/E/" would have the same effect). Semi-colon is the best delimiter in general because it cannot be entered as a value. Between checks are always inclusive. Thus "{NV 9 11" will accept only 9, 10, or 11. The numeric value must be an integer between -32,768 and 32,767. To accept answers B-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 6.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. RBBS-PC CPC17.3 Page 69 6.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 U). RBBS-PC's internal Remote Data Base feature (RDB) gives the SysOp the ability to: o set up unlimited numbers of named data bases o set up menus to interact with the user o prompt users for data o use Metavariables - both work variables and SmartText variables. o store user's answers in work variables. Any subfield in a work variable can be referenced. o display, or store all metavariables o process commands conditionally o save Metavariables to file thru templates, allowing data to be stored in virtually any format desired o retrieve data into templates for display. o 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. Examples of the kind of applications that would utilize RBBS-PC's remote data base feature are: For Sale - ask user item, price, who to contact, telephone #. Callers can add items, or view list of items. BBS lists -Callers can view data base, or add BBS's where asked for name, numbers, profile of features. No longer do BBS ads have to be left in messages. Can have informative, standardized profile that makes BBS comparison meaningful. BIO - ask users for a profile of themselves so others can know who they are. VOTING - can collect nominations say for best GIF files. No way yet to force a caller to vote only once. 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. RBBS-PC CPC17.3 Page 70 C:DUMMY.DAT,4 * This questionnaire is for finding help with RBBS by topic. * Please register yourself if you * o are willing to help others, and * o 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 Subboards PUI * Questionnaires 10-Net Marcos Uploads * MU-Purge File maint. Personal dwld Caller Analysis * :-[prompt]- T ? V)iew database, E)nter new data, Q)uit (V,A,Q) =V-[view]-=E-[add]-=Q-[quit]-= -[prompt]- :-[view]- M C:\RBBS\VIEWHELP.MCR >-[prompt]- :-[quit]- @ :-[add]- * 703-978-6360 ?1 BBS data number * 703-978-4339 ?2 Voice # (evening, 0 not to give) * You can specify as many topics as desired, one at a time. * :-[topic]- ?3 RBBS 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 RBBS-PC CPC17.3 Page 71 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 a Building Your own Remote Data Base Applications ------------------------------------------------------- Generally you will have o a questionnaire driver that gives caller option to exit, view database, or Enter new data. o a macro to retrieve data from file to a form o a macro to save data in a data base format. o 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 o to paint a template with all everything but the data values, such as row and column labels and titles. o to 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. RBBS-PC CPC17.3 Page 72 [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 reverse the video and change blinking and set color. An easy way consistent with RBBS-PC is to set colors using the "Smart" Text 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" that 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;15fSample Title-{C0 [1] RBBS-PC CPC17.3 Page 73 6.9 RBBS-PC's "Smart" Text Variables ------------------------------------ SmartText allows the SysOp to substitute pre-defined variables in text files as MENUS, Bulletins, Help, and 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 6.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. Realize that it may be important in graphics files not to change the lengths of lines. The SmartText variable "VY" does just that. Also, you may not want trailing spaces in some variables, and "TY" does this. To utilize RBBS-PC's "smart" text 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 "smart" text files. 2. It should not be a character that might be used for any other purpose in the text files. 3. It should not be a character that might be interpreted, when printed, as being a printer command (i.e. start double spacing). Some may like to use characters created by simultaneously pressing two keys such as the "Ctrl" and "N" keys to create a character whose decimal representation is 14. Others may wish to use such seldom used, single keystroke characters as: Character Decimal Value @ 64 ^ 94 ~ 126 { 123 <--- Default used by RBBS-PC } 125 | 124 CONFIG parameter 17 can have any value between 0 and 255. If 0 is selected, RBBS-PC's "smart" text capability will be turned off. A RBBS-PC "smart" text control sequence consists of the control character that was selected in CONFIG parameter 17 followed by a "smart" text double- character command. These "smart" text double-character commands MUST be entered as upper case characters! There are two kinds of "smart" text variables: those that get substituted, and others controlling how RBBS-PC CPC17.3 Page 74 substitution is done. The double-character commands are: COMMAND MEANING BD Displays the bytes downloaded today. CS Overrides RBBS-PC's automatic screen depth management so that the next "Press Enter to Continue" will not come halfway through a page. C0 Resets color to the user's selection for text. C1 Changes color to the user's selection for Foreground Color One. C2 Changes color to the user's selection for Foreground Color Two. C3 Changes color to the user's selection for Foreground Color Three. C4 Changes color to the user's selection for Foreground Color Four. DB Inserts the total number of bytes ever downloaded by the caller. DD Inserts the total number of files downloaded by the caller today. DL Inserts the total number of files ever downloaded by the caller. DT Inserts the current date, MM-DD-YYYY, into the text file. FI Inserts File.Name$ into the text file FN Inserts the user's FIRST NAME (in caps) into the text file. LN Inserts the user's LAST NAME (in caps) into the text file. NS 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 Causes RBBS-PC page break message, "MORE (Y/N/NS/A)" or the "PRESS ENTER.." prompt to appear after the line is printed. RP Inserts the number of days in the registration period. RR Displays the days remaining in the caller's registration period. SL Inserts the user's current security level into the text file. TE Inserts the user's elapsed session time (hh:mm) into the text file. TM 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 Inserts the number of minutes left in the user's session into the text file. UB Displays the total number of bytes ever uploaded by the user. UL 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 "smart" text files, each SysOp should take into account that the some of the "smart" text 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 "smart" text 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 "smart" text delineation character -- {. RBBS-PC CPC17.3 Page 75 INTRODUCING SMART TEXT! RBBS-PC allows the SysOp to customize the text seen by each caller. For instance, if the SysOp wanted to make sure this message didn't scroll off the screen, he could pause the display like this: {PB Or, the SysOp may want to show the caller that today's date is {DT and the time is {TM. The SysOp may even want to include a personal greeting to {FN {LN. The SysOp can tell the caller that their security level is {SL and that they have been on-line for {TE, and have {TR minutes left in this session. This kind of capability illustrates RBBS-PC's on-going commitment to nurturing each SysOp's creativity and avoiding the dogmatic. RBBS-PC CPC17.3 Page 76 6.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 item6). 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 6.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, 1st will use foreground 1 and second foreground 2. RBBS-PC CPC17.3 Page 77 "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 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 boards - transmission of textual information and file exchange - do not essentially involve the use of color. Thus "colorization" is at best dispensable and at worse degrades the performance of these essential functions. 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. Color is largely used to group related information on the screen, where everything has a color. 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. If "colorization" is activated everywhere within RBBS-PC, it is imperative that the PRELOG or WELCOME file inform callers to execute the G)raphics command. RBBS-PC's default is to use "colorization" for internal prompts. The G)raphics command ask users: 1.) If they want graphics versions of text files, 2.) Whether the caller wants prompts colorized, 3.) What color the caller wants for normal text, and 4.) Whether normal text should be bold or normal in intensity. To Implement "colorization" within RBBS-PC, run CONFIG and go to screen 17 of the CONFIG parameters -- "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, parameter 324, parameter 325, and parameter 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, RBBS-PC CPC17.3 Page 78 bright purple, and bright cyan. These colors are all used in the message header and general command prompt. Foreground 4 is used to highlight the commands the caller actually needs to type in to select that option. No colors will be displayed if these parameters are set to empty strings. Callers can turn off the colorization simply by going into Utilities and T)oggle H)ighlite to "off". The default in RBBS-PC is for colorization to be OFF. Colorization is based on the ANSI standard. Special codes are sent by RBBS-PC to the callers system, which must then be interpreted by the caller's communications software. CONFIG lets the SysOp set the strings to turn color emphasis on and off. Inside the PUI and external text files, the SysOp must use an editor to create graphics files. There are special graphics editors, like THEDRAW, or a SysOp who knows the codes to embed can use an ordinary text editor. RBBS-PC CPC17.3 Page 79 6.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 "conference" (i.e. "sub-board"). The selection criteria 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: The SysOp wants to chat with caller or that 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. Automatic paging of the SysOp is controlled by a file whose name is specified in CONFIG parameter 18 (the default name is AUTOPAGE.DEF). This file 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 is to also be notified that the SysOp wants to be automatically paged 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 what is to be played each time the speaker is sounded. 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 means to automatically page the SysOp when a caller named SEXY DEVIL logs on, not to notify the caller, and to page the SysOp one time, RBBS-PC CPC17.3 Page 80 playing "L4EDC". "GREGG SNYDER",N,2, means to automatically page the SysOp when GREGG SNYDER logs on, to notify the caller, and to beep the SysOp twice. "NEWUSER",,1, means to automatically page the SysOp when any new caller logs on, not to notify the caller, and to page the SysOp once. /10/12,N,2, means to automatically page the SysOp when anyone with security 10 through 12, inclusive, logs on, to let them know that the SysOp wants to be notified that they are on, and to beep the SysOp twice. The status line at the bottom of the screen will read "Autopaged!" if RBBS-PC has automatically paged the SysOp. This allows the SysOp to know that the automatic page took place, even if the SysOp was not present at the beginning of the call. The following is a sample AUTOPAGE.DEF: "SEXY DEVIL",,1,L4EDC "GREGG SNYDER",N,2, "NEWUSER",,1, "/10/12",N,3, If more than one condition will trigger the automatic paging of the SysOp, the first condition encountered will be used. Since the AUTOPAGE.DEF file can be different for each "sub-board", the SysOp has the option to be automatically paged based on different criteria for each "sub-board". RBBS-PC CPC17.3 Page 81 6.12 Enhancing the File Verbose List ------------------------------------ Within the File Subsystem of RBBS-PC the V)erbose List, sometimes called View function, allows the caller to get a list of files that are "libraried" inside a single file. RBBS-PC not only supports the commonly used PKWare "zip" format, but also "arc", "pak", and "lzh", and well as ANY library format using SysOp-installed external procedures. RBBS-PC assumes that the file extension will identify the type of compression. Hence, all files with "ARC", "PAK", or "ZOO" have a different but common compression function. RBBS-PC continues its internal support for ARC and ZIP files. However, the SysOp can install a Verbose List 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 file whenever a caller asks for a V>erbose listing of any file with the extension "xyz". SHELLing requires EXTRA memory beyond what RBBS-PC uses. If your system has little or no free memory, you may be limited to using the internal V>erbose list feature of RBBS-PC. RBBS-PC includes the following files for external verbose list: ARCVIEW.COM Compiled C program for verbose list 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 containing the results of the listing for "[2]". The ">" simply redirects the listing that would normally go to the screen to "[2]". RBBS-PC always expects the results of the verbose list to be written to a file named "NODExWRK" when x is the node id (1,2,3,...). How to Implement Your Own Verbose List -------------------------------------- Your verbose list program must have a way to receive from RBBS o the name of the file to list o the name of the file to write the listing to. RBBS 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 will shell to the line in the BAT file and not the BAT file. RBBS will dynamically scan for "[1]" and "[2]" in the line and substitute the names of the file to be listed and the RBBS-PC CPC17.3 Page 82 file to write the results to, respectively. Everything else will be left intact. If the BAT file contains more than one line, RBBS will shell to the BAT file, passing on the command line first the name of the file to list, and second the name of the results file. For example, the following BAT file could be used: ECHO OFF ARCVIEW %1 > %2 ECHO ON Remember, inside a BAT file you can do any processing you want. For example, if you want to keep a log called VIEW.LOG of the names of all files viewed, you could have ECHO %1 >> VIEW.LOG ARCVIEW %1 > %2 The ">>" means to redirect the standard output to file VIEW.LOG but appends rather than replaces. Using ZIPTV ----------- Ziptv is a program distributed by Samuel H. Smith which supports not only verbose list, 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 verbose list. Simply make sure ZIPTV.EXE is either in the current directory or the path, and put VZIP.BAT where config says that COMMAND.COM is, and VZIP.BAT contains del %2 ZIPTV -P%3 %1 RBBS-PC CPC17.3 Page 83 6.13 Bulletins and News ------------------------ RBBS-PC has very powerful and flexible features for broadcasting system wide information to callers. The main options are to send information o every time the caller logs on. The text file PRELOG is displayed before callers are asked their names. This information should be kept very brief. o only to the new user. The text file NEWUSER is to new users only on the first time they log on. o every time, after the caller logs on. The text file WELCOME is displayed after a successful logon. o if the information has been updated since the caller last was on the board The NEWS file is displayed if the date of last log on is the same or earlier than the date of the news file. The news file should be in the same drive/path as the welcome file for the conference. For conference XYZ, the news file name is XYZ.NWS. You can have graphics versions of the news. The name of the news file for the main board is MAIN.NWS, unless you rename your main message and user files to ABCM.DEF and ABCU.DEF, in which case the news file is ABC.NWS. The news file is a special bulletin, and can be read by using the "b n" command (bulletin news). o every time the caller logs off. This type of bulletin is handled with a log off questionnaire, whose default name is EPILOG.DEF. See section 18. o general bulletins. RBBS-PC supports having general system bulletins. One advantage of general bulletins is that RBBS-PC will compare the last date logged on for the user to general bulletins, inform the caller on logon of which bulletins are news, and give the caller the option to read the new bulletins. You can control the bulletins that are scanned for being new by listing them, one on a line, in the file <bulletin prefix>.FCK. Suppose, for example, you have 50 bulletins but only want 1-10 checked, and BULLET is your bulletin prefix. Then file BULLET.FCK should have in it 1 2 3 ... 10 If there is not "FCK" file, then RBBS will search the number of bulletins listed as existing in config (e.g. BULLET1, BULLET2, ...., BULLETn). RBBS-PC CPC17.3 Page 84 RBBS-PC supports having not only numbered, but named bulletins. The word the user types in is just appended to the bulletin prefix and checked. So, if the prefix is BT, the file BTACE would be requested by the user by typing "ACE". Named bulletins must be in the controlling file check file in order to be included in the logon search for new bulletins. Bulletins also fully support sub-menus. See section 6.7 for details. There are some fine SysOp utilities for creating and managing bulletins, especially for news, such as FLASH. These allow full screen editing and automatically generate graphics and non-graphics versions of the files. RBBS-PC CPC17.3 Page 85 7. UNIQUELY IDENTIFYING YOUR CALLERS ------------------------------------- All callers need a way to identify themselves and to re-identify themselves on subsequent calls so that they can, for example, read the mail addressed to them. 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 - which is usually 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 like AVENGER 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 (i.e. in Europe, South America, the Far East) 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. The way this works is that callers will have to specify both the identifying and individuation field and both are used to match 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. RBBS-PC CPC17.3 Page 86 7.1 Setting Up Identifying and Individuation Fields ---------------------------------------------------- The identifying and individuation fields in RBBS-PC are controlled by parameter 41, parameter 42, parameter 43, parameter 44, parameter 45, and parameter 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 the detailed layout of the user file. RBBS-PC's flexibility requires caution to be exercised 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 become a different user. 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 file currently unused provides a potential 11 columns to use for special, SysOp designated fields. However, there is no guarantee that these positions will not be used in later 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. The shorter it is, the more likely there will be room in later releases. For example, 11 columns might be used for telephone number (format 123-1234567). Or 5 columns might be used for account number. When a special field is created, the SysOp must also supply the prompt to be used with the field, since RBBS-PC has no way of knowing how to describe the field to a caller. 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. RBBS-PC CPC17.3 Page 87 7.2 Preloading Identities For Instant Access --------------------------------------------- SysOps that 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 immediately on. 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 (albeit at a security level so low that the caller can do little, if anything) and simply 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 get on. 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 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 and give these out. Callers willing to charge subscription fees on their credit cards over the telephone 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 CPC17.3 Page 88 8. 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 1. to make it very easy to control access based on subscription dates. 2. to give callers a temporary, date limited boost in privileges. 3. to vary the amount of time that a call can have for a session based on the time of day. The subscription management system dramatically reduces the work necessary for 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. In effect, a subscription RBBS-PC can be left on "automatic" pilot and it will operate correctly, without additional effort on the SysOp's part. The SysOp cansend a special message with the warning by creating the file RGXPIRE.HLP in with the other help files. The file RGXPIRD.HLP will be displayed when the subscription expires. 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 that sometimes have a free week of viewing to attract new subscribers by letting them know what they are missing, 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 or checked out. These callers are either asked to fill out a registration form or leave a comment, then sometime later the SysOp 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 and minimize the pressure to check the new caller out as soon as possible. The SysOp need do nothing if a caller cannot be verified. Those that check out get their security raised. This way the many honest new users are not penalized but the prank or dishonest callers can get on only briefly. RBBS-PC CPC17.3 Page 89 8.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 the subscription date began to limit access. This recorded date is the base registration date. The SysOp then needs to specify in CONFIG: 1. A default subscription period (the number of days a new user gets). 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 needed to trigger a warning.) 3. 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 bumped down 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 14.3 for a complete description of the PASSWRDS file. RBBS-PC CPC17.3 Page 90 9. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC --------------------------------------------------- The RBBS-PC.DEF file is created by the CONFIG program and contains the program's default operating parameters and values. When you run the CONFIG program to create RBBS-PC.DEF or to update it, you can change many of these parameters to meet your needs. Certain parameters which control critical operations of the programs are embedded in the RBBS-PC program and should not normally be changed by the system operator. When setting RBBS-PC is set up for the first time, SysOps are urged to take the default values generated by CONFIG except for those parameters that are unique to their configuration (i.e. the communication port, etc.). 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 The user may scroll forward or backward through the 17 screens of parameters in CONFIG using the PgUp and PgDn keys on the keyboard. Additionally users 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, users need only press the "End" key on the keyboard. The compiled version of 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. This assumes that CONFIG.EXE, is on the default disk drive. The CONFIG utility will write the RBBS-PC definition file, RBBSxPC.DEF to the default drive. RBBS-PC CPC17.3 Page 91 9.1 Global RBBS-PC Parameters (Part 1 of 3) -------------------------------------------- Parameters 1 and 2 Parameter 1 and parameter 2 request the RBBS-PC system operator's (SysOp) name. Here is where you store the "public" name of the SysOp. This name is used by RBBS-PC (for instance, when you bring a caller into "chat", it greets him using this name). NO ONE may log in to your RBBS-PC using this name. Even the SysOp must use a "SysOp Pseudonym", specified later. The SysOp's name can be either a real name such as "Tom Mack" or an impersonal identifier such as "Physics Department." Parameter 3 The SysOp's default sign-on mode is set to either EXPERT or NOVICE. Once you're comfortable with the RBBS-PC command structure, you may want to adjust this to EXPERT. Parameter 4 Parameter 4 allows the SysOp to set the "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 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 5 changes this setting. Parameter 6 Parameter 6 gives the SysOp the option of electing to have 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 This controls 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 This parameter is asking for the maximum amount of time each user is to be RBBS-PC CPC17.3 Page 92 allowed on the system per session (the "session" refers to any individual call to the bulletin board). Set the number of minutes to whatever you are comfortable with. You may have to lower this number, once your number of callers increases, in order to keep callers' waiting times reasonable. This can also be made equal to the maximum time on the system each day. As described elsewhere, each security level can have its own maximum time on the system per session specified and it can vary according to the time of day that the user logs on. A SysOp may limit the maximum amount of time any user with the default security level can spend on your system each day via parameter 9 of CONFIG. This is helpful if you have a relatively busy RBBS-PC and want to have as diversified group of callers as possible. Every security level can have a different maximum time on the system per day and it may vary based on the time of day that the user logs on. These are specified in the PASSWRDS file. RBBS-PC keeps track of the total amount of elapsed time a user is on RBBS- PC each day. Each time a caller logs on, the maximum amount of time that they are allowed on the system is checked against this daily cumulative total. The time remaining in each caller's session is the difference. When a caller exceeds this maximum and tries to log on again, they are told that they have exceeded the allocated time for that day and to try again tomorrow. Parameter 10 allows a SysOp to "reward" users who upload files by adding some multiple of the elapsed time it took for the file upload to the current session time. This should be used judiciously as some users may abuse this by repeatedly uploading COMMAND.COM or some other meaningless file. This extends both the users current session and other sessions during the same day, but NOT the time on future days. However when specifying this parameter, the SysOp will be asked if upload time credits are to accumulate indefinitely until they are used. If the SysOp replies "NO", the upload time credits endure only for the day in which the uploads are made. Parameter 11 sets the number of months inactivity that must elapse before a user is deleted from the USERS file when the SysOp "rebuilds" the user file. Parameter 12 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, parameter 14, and parameter 15 allow the SysOp to specify the colors desired for the foreground, background, and border. When specifying these options the BASIC manual's section describing the COLOR command in text mode should be consulted. This is useful when running multiple RBBS-PC's and you want a handy way of determine which RBBS-PC it is that you are viewing on the screen. This option is NOT available if the SysOp has specified a "ring-back" system. Parameter 16 control whether RBBS-PC will use ANSI codes for special effects like blinking on the local PC's screen. RBBS-PC CPC17.3 Page 93 Parameter 17 designates the decimal value ( 0 to 255) of the character to be used for personalizing the text files displayed to the caller. If 0 is selected, no text files will be personalized. See section 6.9 for a more detailed discussion of how to personalize RBBS-PC text files. Parameter 18 allows the SysOp to specify the file name that contains the information to control the "automatic" RBBS-PC paging of the SysOp. See section 6.11 for a detailed description of the file format and a description of RBBS-PC "auto-page" feature. Parameter 19 lets the SysOp determine the level of detail to use when notifying callers of electronic message. See section 19 to get a better understanding of the full flexibility of mail waiting notification that has been built into RBBS-PC. RBBS-PC CPC17.3 Page 94 9.2 Global RBBS-PC Parameters (Part 2 of 3) -------------------------------------------- Parameter 21 allows the SysOp to remind users not only of the messages that might be for them but also messages that they may have left. This should be enough of a nuisance to insure that users do delete some of the messages they have left and help to keep the MESSAGES file to a minimum. Parameter 22 allows the SysOp to elect to remind users of how many files they have downloaded and uploaded. Parameter 23 allows a SysOp to remind users every time they log on of the preferences they have selected for such things as file transfer protocol, graphics, nulls, etc. Parameter 24 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 this file for the latest uploads. When a caller logs on, RBBS-PC will determine how many files are new since the caller last logged on, up to a maximum of 23. By setting parameter 218, the caller is offered the chance to immediately review these new files for downloading, 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 allows the SysOp to establish a default page length for users when they log on. A 23 line page length is the default, but the SysOp can set it to any number between 0 and 255. If set to 0, the user will receive continuously scrolling output. Parameter 26 allows the SysOp to specify (within the range of 1 to 99) the maximum number of lines allowed in each message. Parameter 27 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). Parameter 28 is intended to allow the SysOp to indicate if the system bulletins are to be 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. Parameter 29 is designed to allow RBBS-PC to run on some "IBM-compatible" PC's that make use of unused interrupts or on the IBM PCjr. RBBS-PC checks to see if the unused interrupt X'7F' is non-zero. If it is, RBBS-PC thinks that the software product, MultiLink (from The Software Link, Inc.) is present and issues the appropriate MultiLink calls. Obviously if this RBBS-PC CPC17.3 Page 95 is not the case, strange and unpredictable things happen which result in RBBS-PC not working. The COMPAQ+ is an example of this syndrome. If running RBBS-PC on an IBM PCjr using an external modem but without an internal modem, the communications port must be opened as COM1 even though RBBS-PC must use the COM2 RS-232 registers for controlling the communications port. Parameter 30, parameter 31, parameter 32, parameter 33, and parameter 34 let the SysOp change what symbols are used for each RBBS-PC function by substituting a new letter. Additionally, a space substituted for a command will disable that command, in effect removing it from the system. SysOps with no DOORS may wish to disable D rather than to confuse users by displaying options not available. All commands displayed to callers in the command prompt will be in sorted order. Parameter 35 allows the section name to precede the command prompt that is displayed when a caller is asked to enter a command. The command prompt begins with <section>, where <section> is MAIN, FILE, 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 8 for reasons to suppress the section. Parameter 36 allows the SysOp to not display the commands to the caller when waiting for the user to enter a command. The default in RBBS-PC is to remind the caller what commands are available by giving a sorted list of the letters used for each command at the end of the command prompt. RBBS- PC shows only the commands available in the section that the caller is in. If the SysOp chooses not to display the section a user is in, there are more commands available than will be shown in the prompt. RBBS-PC supports a "wrap-around" search for valid commands. This means that when a command is not found in the current section, other sections are then searched. The order of search is MAIN->FILE->UTIL->LIBR. For example, if L is picked when in the main section, where there is no command, the L)ist command in the file section will be executed. Parameter 37 lets the SysOp turn this wrap-around search and not execute commands in other sections. Wrap-around is required if the SysOp want's to have a single command line (i.e. not have the "Utility" and "File" subsystems). Parameter 38 allows the SysOp to elect to use machine language subroutines (rather than the BASIC routines) for a few of the more commonly used subroutines. These may only be functional within a DOS that is supplied by IBM (rather than Microsoft). Therefore this is optional. If you encounter problems, simply elect to utilize the BASIC routines which are much more likely to be compatible in configurations that have hardware and software operating environments significantly different from the "baseline" configuration in which RBBS-PC is tested. In most cases the assembler routines are much faster than their BASIC counterparts, especially in file searches. Parameter 39 allows the SysOp to elect 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 RBBS-PC CPC17.3 Page 96 the RBBS-PC screen driver ANSI is not viable. Parameter 40 is the maximum number of lines that can be used to describe a file that was uploaded. It is the number of lines (beyond 1) that a caller can enter when describing a file that was uploaded. It applies to both single FMS directories and non-FMS directories. RBBS-PC CPC17.3 Page 97 9.3 Global RBBS-PC Parameters (Part 3 of 3) -------------------------------------------- Parameter 41 and parameter 42 determine how callers are going to be uniquely identified when they log on. The default in RBBS-PC is to concatenate first and last name to form name. Parameter 41 lets SysOps choose another field as user ID. A field is specified by giving its starting position and length in the user file, and a prompt must be supplied which will be used when asking for user ID. BE VERY CAREFUL CHANGING THIS PARAMETER. Parameter 45 and parameter 46 allow the SysOp to specify a name to be used when prompting the user for the field (i.e. ACCOUNT #). See section 9 for additional details. RBBS-PC assumes that name is being used whenever the ID begins in column 1. Parameter 42 lets a field be specified that will be used to distinguish callers with the same ID. Like with ID, the beginning column, length, and prompt must be specified. RBBS-PC defaults to no individuation, which is specified by setting the beginning column to 0. Activating this option forces users to give additional information when they log on, since both ID and individuation value have to be given. See section 9 for details on how to use this option. Parameter 43 and parameter 44 inform RBBS-PC the field and the length of the field in the USERS record to use when determining if a "personal download" exists for this person. Parameter 43 indicates where the field begins in the USERS record -- the default is position 1 (the user's name). Parameter 44 indicates how long the field to match against is -- the default is 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 and parameter 46 allow the SysOp to specify the description of what is asked for that is placed in the first 31 bytes of each user's record. When identifying to whom a message is to/for it is these 31 bytes that are matched against. However, these prompts can be changed from the default "FIRST name" for parameter 45 to "REAL FIRST name" or even "DEALER number". Similarly the default for parameter 46 could be changed from "LAST name" to "ZIP code". Parameter 47 allows the user to enforce upload to download ratios. See section 14 for a discussion of the flexibility each RBBS-PC SysOp has in specifying these ratios. Sections 14.3 and 14.4 describe in more detail the format necessary to use in the password file in order to utilize which users/security levels are to have upload and download ratios applied. Parameter 48, parameter 49, parameter 50, and parameter 51 address access control via the automatic RBBS-PC subscription management facilities. For a detailed discussion of RBBS-PC's automatic subscription management facilities, see section 8. Parameter 48 means that access will be controlled by subscription dates, and persons with expired subscriptions will get reduced privileges. Parameter 49 is the security level callers get after their subscription expires. Typically this security significantly reduces what a caller is allowed to do. Parameter 50 specifies when callers are to be warned in advance that their subscription is about to expire. This warning is based on the number of days before a subscription expires. Parameter 51 specifies the number of days a new user RBBS-PC CPC17.3 Page 98 gets in the subscription period. Parameter 52 determines if RBBS-PC is to avoid writing to the printer. On some networks any attempt to write to a printer can generate a spooler error that hangs the node. Setting this parameter to "YES" guarantees that RBBS-PC doesn't write to the printer. Parameter 53 causes RBBS-PC to play musical themes for auditory feedback on what is happening on a board. 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. The themes are not transmitted to the caller. Parameter 54 is the buffer used internally by RBBS-PC when displaying text files such as menus, directories of files, etc. A SysOp can set parameter 218 to either minimize memory usage or optimize speed. It is the size of the internal buffer that RBBS-PC uses to read in most text files, including menus and can range from 32 bytes to 4096 bytes. 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 allows RBBS-PC to dynamically set the "stack space" used by the code generated by the BASIC compiler. In QuickBASIC 3.0, the compiler used to generate RBBS-PC's .EXE file, and IBM's BASIC Compiler Version 2.0 this is the total stack space. In later releases of QuickBASIC, it is the ADDITIONAL stack space beyond which BASIC normally allocates. The recommended value is 1024, if RBBS-PC is running in a multi-tasking environment under DOS. However, in order to decrease memory demands this can be made smaller. Parameter 56 is not implemented in RBBS-PC. Parameter 57, like parameter 45 and parameter 46, is used when a new user logs on to the system for the first time. Instead of asking a user for their City and State, a SysOp can request such things as their area code and telephone number. Parameter 58 allows the SysOp to configure RBBS-PC such that the file directories are shown in sorted order whenever a caller simply lists the directory of directory. Parameter 59 allows the SysOp to configure RBBS-PC such that the "internal" RBBS-PC protocols use as large (or as small) a buffer size when writing to disks (i.e. for uploads). The allowable range is from 128 characters to 8,192 characters. Parameter 60 indicates that Computalker (B.G. MICRO, P.O. Box 280298, Dallas, Texas 75228) or HEARSAY 1000 (HEARSAY Inc., 1825 74th Street, Brooklyn, N.Y. 11204) speech boards are to be supported. This is in support of the sight impaired SysOpS. These two particular boards were selected since they were available from John Lasley. (John is a SysOp in Minneapolis, MN). RBBS-PC CPC17.3 Page 99 To support as many speech boards as possible in the future, RBBS-PC uses a 64 entry file (RBBSTALK.DEF) to contain SysOp-definable fields. The file is accessed randomly with fixed-length 32 byte records. The last two bytes must contain CR/LF leaving 30 bytes available for the text. The 64 records are predefined and used by RBBS-PC as follows: 1 = LOGON USER MESSAGE 2 = MAIN MENU PROMPT 3 = FILES MENU PROMPT 4 = UTILITY MENU PROMPT 5 = DOOR MENU PROMPT 6 = LIBRARY MENU PROMPT 7 = LOGOFF MESSAGE 8 = DOWNLOAD PROMPT 9 = UPLOAD PROMPT 10 = TIME REMAINING PROMPT 11 = WELCOME BACK PROMPT 12 = CONFERENCE MENU PROMPT 13-64 available for future enhancements Smarttext IS supported in the RBBSTALK.DEF records. The CompuTalker requires the use of one of the COM ports. RBBS-PC will use only COM2 and does not check to see if COM2 was also selected for CONFIG parameter 221. RBBS-PC CPC17.3 Page 100 9.4 Parameters for RBBS-PC System Files (part 1) ------------------------------------------------- Parameter 61 specifies the name of text file that is shown to a user if bulletins are not optional (see parameter 28) or if the user replies "L" when notified of how many bulletins exist. This file should contain a list of the bulletins (i.e. 1-99) and a brief one-line description of the contents of each (e.g. "New Release of RBBS-PC"). Parameter 62 allows a SysOp to have from 0 to 99 "bulletins." If there are 0 bulletins a user is notified that there are no bulletins. Bulletins should be brief, informative, and timely. I personally think that there should be very few bulletins and that they should be changed often if users are to be enticed to look at them. If you make bulletins optional (parameter 28) RBBS-PC will automatically bring new ones to the attention of each caller when they log on. Parameter 63 provides the SysOp with the flexibility to make the prefix of the bulletins anything he wants (i.e. BULLET). To this is added the number (e.g. BULLET7 for bulletin number 7) and the disk drive designated in parameter 61 is searched for the bulletin number requested when some asks to see a bulletin. If the file is not found, the user is so informed. If a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the bulletin is displayed - BULLET7G (i.e. contains characters with values of 0 through 255) or BULLET7C (i.e. contains characters with values of 0 through 128 which, hopefully, are ANSI screen commands). Parameter 64 indicates the disk drive and path on which RBBS-PC is to search for to find RBBS-PC's on-line "help" files whenever a user asks for help within a specific subsystem. This is where the help files should be stored. There are some specific help files used by RBBS-PC whose name is simply a help prefix plus a number. The SysOp may elect to call the prefix something other than the default of "HELP0". Parameter 65 allows the SysOp to pick up to a seven-character prefix to which the numbers will be appended. This file name is what RBBS-PC will look for on the drive specified in parameter 64 when a user asks for help on-line. As with "bulletins", if a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the help file is displayed (i.e. HELP07G). RBBS-PC identifies help for a particular command by the letter of the section and the letter of the command, plus an extension for the help files. The extension "HLP" is the default but parameter 66 lets the SysOp set this to whatever desired. Parameter 67 is the name of the file that is displayed to a caller when the caller is requested to categorize a file that has been uploaded. RBBS-PC' File Management System can be configured to minimize the activities of the SysOp by allowing users to categorize the files that are uploaded. This file should list the names of the categories that an uploader can select. It should be stored on the same drive and path as the other help files. The category selected will be validated to make sure that it is in the list in DIR.CAT or that a valid category file with that name exists. The RBBS-PC CPC17.3 Page 101 appropriate category code will be written out to the shared FMS directory if the FMS system is active. If the FMS system is not being used or a separate .DIR file with the category name exists (e.g. GAMES.DIR), the description of the entry for the upload will be appended to the .DIR file. Parameter 68 allows the SysOp to select any name for the text file that 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. It can contain anything you want it to, but a brief explanation of your Board's purpose, "rules", etc. might be appropriate. Parameter 69 allows the SysOp to select any name for the text file that each user sees EVERY time AFTER they log on. Keep it brief! RBBS-PC will look for a "graphics" equivalent if the user qualifies for graphic displays (i.e. it will display the file HELLOG or HELLOC in lieu of HELLO). The default name for this file is WELCOME. Parameter 70, parameter 71, parameter 72, parameter 73, parameter 74, and parameter 75 focus on the text files that RBBS-PC displays to novices as "menus." Menu files shown to novices tend to be frequently accessed. Systems that do not have disk caching should consider putting menus in a RAM disk in order to cut down on the wear and tear of your disk drives. Parameter 70 allows any valid name to be given to the text file containing the commands allowed those with SysOp privileges. Parameter 71 allows the SysOp to specify the name of the text file containing the menu of commands available to those in the main "messages" subsystem. Parameter 72 allows the name of the text file containing the menu of commands available to those in the "files" subsystem to be any valid name. Parameter 73 allows the name of the text file containing the menu of commands available to those in the "utilities" subsystem to be any valid name. Parameter 74 is the name of the text file listing the names of the conferences that are available. Conference names must be seven-characters or less, in all caps, and cannot have any character to the left or right of the name except possibly a space. The SysOp must already have pre- formatted the messages and users files associated with the conferences (see section 18). Parameter 75 allows the SysOp to name the text file containing the list of the questionnaires, surveys, or forms which callers can fill out and answer on-line. The scripting support built into RBBS-PC allows the SysOp to construct a series of questions to be presented to the caller and save the answers. Questionnaire names must be eight characters or less, in all caps, and cannot have any character to the left or right of the name except possibly a space. Of course, the actual file name for the script has an extension of ".DEF". Thus, a questionnaire called SURVEY would appear in the text file identified in Parameter 75 as SURVEY, preceded and followed by at least one blank character, and exist as a file named SURVEY.DEF. Parameter 76 allows the SysOp to specify the drive and path where the RBBS-PC CPC17.3 Page 102 optional questionnaires will be located. If the file specified in parameter 77 exists, RBBS-PC will assume that the SysOp is using RBBS-PC's "Programmable User Interface" (PUI) -- see section 8 for a fuller description of RBBS-PC's PUI. Parameter 78 allows the SysOp to elect to have RBBS-PC have full page control. By this it is meant that all displays will be interrupted after the number of lines set by the user for his "page length" have been written to the user's screen. This, on occasion, may mean that menus will pause in the middle with a prompt waiting for the user to hit enter. The advantage of allowing this to happens means that no information on the user's screen will "scroll off" the top of the screen. The disadvantage is that menus may not be viewed in their entirety. Replying "NO" to this parameter means that menus will be fully displayed on a single screen, but some information that preceded the menus may scroll off the top of the screen. Parameter 79 and parameter 80 allow the drive, path name, and extension to be used for RBBS-PC "macros". See section 6.8 for a fuller description of RBBS-PC extensive "macro" capabilities. RBBS-PC CPC17.3 Page 103 9.5 Parameters for RBBS-PC System Files (part 2) ------------------------------------------------- Parameter 81 is the name of the text file (TRASHCAN) listing names that the SysOp considers inappropriate. 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 you create the file using IBM's standard DOS text editor, EDLIN, each line may end with either a comma or a carriage return. If you create the file using COPY CON, each line should end with a carriage return (i.e. the "enter" key). The last line (when using COPY CON) should end with a Control Z, F6, and then carriage return. BASIC will treat either a comma or a carriage return as a field delimiter. You need a field delimiter following each of the names. 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 Papa" would be fine. Parameter 82 lets the SysOp force a questionnaire to be answered by all callers, old and new, exactly once. RBBS-PC records in the users record when the required questionnaire is answered so that it will not ask the caller again. Parameter 186 lets the SysOp reset the flag back to off for all users. This should be done when the SysOp wants to install a new required questionnaire to be used to survey all callers. If no questionnaire is required, this parameter can be specified as NONE. Parameter 83 allows the SysOp to specify the name of the file that will be displayed 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 RBBS-PC CPC17.3 Page 104 parameter 12). SysOps should use "PRELOG" to convey such information as whether real names are required, 300 baud users will automatically be denied access, etc. RBBS-PC provides a sophisticated, script-driven capability that allows a SysOp to ask new users questions or questions of all users when they say G)oodbye. Parameter 84 allows the SysOp to specify the file name of the script of questions to ask new users. Parameter 85 allows the SysOp to specify the file name of the script of questions (if any) to ask users when they say G)oodbye. The SysOp can set up the script so as to raise or lower a new users security level based on the answers. Contained within these scripts is the file name to which the answers are to be written. Parameter 86 allows the SysOp to specify the file name for the file used by RBBS-PC to hold the messages on the bulletin board. This file can NOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the messages file. NOTE: Read section 19 if you want to include the main message file in the scan for conference mail waiting. RBBS-PC keeps a profile of each user who logs on in a "user record" (see Appendix A for a layout of this record). Parameter 87 allows the SysOp to specify the file name for this file. This file can NOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the users file. Instead of leaving a "message", a user may leave a comment for the SysOp that is readable only by the SysOp. Parameter 88 allows the SysOp to specify the fully qualified name for the file used by RBBS-PC to store users' comments. Parameter 89 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. RBBS-PC maintains a log of user activity on a "callers" file. It contains information on the date, time, communications parameters of who logged on; what they uploaded or downloaded; and any security violations or errors that were generated. Parameter 90 allows the SysOp to specify the fully qualified name for the file that RBBS-PC uses for this log. If parameter 91 is selected, additional items of information are included in the CALLERS file: 1) "Connect not completed" 9) "Left comment at time" 2) "Sleep disconnect" 10) "Logged off at time" 3) "Caller changed name/address" 11) "Carrier dropped at time" 4) "Newuser" 12) "Message # xxxx left at" 5) "Bulletin x read" 13) "Read Messages ..." 6) "SysOp initiated Chat" 14) "Answered questionnaire xxx" 7) "Entered Conference/Subboard x" 15) "Killed msg # xxxx" 8) "Time limit exceeded" RBBS-PC CPC17.3 Page 105 It should be remembered that for each occurrence of the above, the CALLERS file will increase by 64 bytes. Unless you either have a hard disk or are willing to frequently maintain your system in order to leave enough free space on the disk drives for new files, this option should NOT be activated. Parameter 92 has not been implemented in RBBS-PC. Parameter 93 allows the file name to be specified for the file containing the information on the conferences that are to be scanned for mail waiting when a user logs on. The format of this file and the flexibility it affords the RBBS-PC SysOp is described more fully in section 15. Parameter 94 allows the SysOp to specify the maximum number of "working variables" that RBBS-PC should support in the 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 13.4) or written out to data bases (see section 6.8.4). RBBS-PC CPC17.3 Page 106 9.6 Parameters for RBBS-PC "Doors" ----------------------------------- Parameter 101 allows the SysOp to enable RBBS-PC to exit and return to the system (i.e. DOS). You will also be asked if you will be running "doors" with MultiLink. If you reply yes, you may choose what type of terminal MultiLink is to assume the user is using when MultiLink receives control from RBBS-PC. See the MultiLink manual for the various terminal types. If you choose terminal type zero, MultiLink will not be given control of the communications port when RBBS-PC exits to the "door." Use this if your application is coded to control the communications port. The batch file out of which RBBS-PC is invoked should then check to see if a "door" is to be invoked. A "door" is simply a batch file that the SysOp has created which RBBS-PC users are allowed to exit to and which will then take control of the remote users communication port. Parameter 102 allows the SysOp to specify the fully qualified file name of the menu that lists the names of the "doors" available to users. RBBS-PC checks this file to verify that the name of the door that the user requested is in the doors menu (see section 15). A door name in the menu must have 8 or fewer characters, be in all caps, and the only character that can occur immediately before and after the name is a space. Parameter 103 allows the SysOp to specify the fully qualified file name of the file that RBBS-PC is to use when dynamically building the .BAT file that invokes the "door" selected by the user. The batch file that invokes RBBS-PC must contain an "IF" to check if this file exist whenever RBBS-PC terminates and (if it exists) to execute it (see section 14). This is also the same file name that is used when the SysOp exits to DOS. When a door finishes RBBS-PC is re-invoked. Parameter 104 allows the SysOp to specify the fully qualified file name of the .BAT file that should be used to re-invoke RBBS-PC (see section 14 and section 15). This is also the same file name that is used when the SysOp returns from exiting to DOS. Whenever a remote user exits to a "door" or to DOS (via the remote SysOp function 7), RBBS-PC needs to know where to find COMMAND.COM. In a network environment with several PC's the COMMAND.COM's may be different for each PC. Parameter 105 allows the SysOp to specify for the each copy of RBBS-PC a disk drive and path on which to find the COMMAND.COM appropriate for that copy of RBBS-PC. Parameter 106 allows the SysOp to elect how I/O is redirected to the communications port when dropping to DOS as a remote SysOp (command "7"). When configuring RBBS-PC you may select to have the I/O redirected either via the standard DOS "Change Console Command" (CTTY), or having DOS redirect standard I/O (">" or "<"). This parameter allows you to specify if the redirected output is to be handled by a special device named in CONFIG.SYS. 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, it should also be in the CONFIG.SYS of the system that RBBS-PC is running on. As an example, if you specified a device driver of GATE, RBBS-PC would build the command CTTY GATE. RBBS-PC CPC17.3 Page 107 Parameter 107 specifies the name of a program (i.e. an .EXE or .COM file) that control is to temporarily to be passed through when the caller is determined to be a new user. When this .EXE or .COM file finishes and RBBS-PC is re-invoked, the RBBS-PC logon sequence will continue uninterrupted from the point at which the caller was determined to be a new user. This feature is intended for those who feel the need to perform an extensive verification of new user's that is not met by RBBS-PC's built in scripting capability or automatic subscription functions. This feature allows those SysOps who have the need to reference membership lists, verify political affiliation, interrogate blood type, or "qualify" new users via whatever criteria seems expedient to their needs/purposes in any way they wish simply by writing a program external to RBBS-PC. Parameter 108 allows the external program designated via parameter 107 to be invoked for not only new callers, but also for callers who have a security level equal to or less than the security level specified in parameter 108. Parameter 109 allows the SysOp to invoke "DOORS" via a control file. The control file has 8 parameters that are separated by commas. The format is 1. Name of door - up to 8 characters 2. Minimum security to use door 3. Questionnaire to execute before the door 4. Method to invoke doors - "S" for shelling, else go to .BAT file 5. Template for invoking door - make sure the first word has a file extension - RBBS-PC will check for existence of the first word as file. 6. Whether ask for password on return - Y is yes, anything else bypasses password check 7. File to display after the door 8. Maximum time allowed in doors - time remaining passed to door is reduced if max time is less. Note: RBBS-PC normally passes the node id as the 1st parameter to a door. If a template is used, RBBS-PC will not automatically add this parameter. If you want it, you should include "[NODE]" in the template. Special note: A door must still have a .BAT file in order to be invoked, even if the BAT file is not used in the template! A control file is optional. The default name is DOORS.DEF. Example #1: Given: 1. Name of the "DOOR" is "KEYCHK" 2. Minimum security a caller must have to use the "DOOR" is 4. 3. Questionnaire users must answer prior to entering the "DOOR" is C:\RBBS\GET3RD.DEF 4. The "DOOR" is to be invoked by EXITing. 5. The template to use is designed to invoke a .BAT file and pass two different responses acquired from the questionnaire when the .BAT file is invoked. RBBS-PC CPC17.3 Page 108 6. Returning from the "DOOR" the caller need not reenter their password. 7. The caller is to be shown the file "KEYCHK.FIL" when the "DOOR" ends. The control file would have the following line in it: KEYCHK,4,C:\RBBS\GET3RD.DEF,D,"RUNKEY.BAT [1] [2]",N,KEYCHK.FIL, Example #2: Given: 1. Name of the "DOOR" is "SKYCHK" 2. Minimum security a caller must have to use the "DOOR" is 10. 3. Questionnaire users must answer prior to entering the "DOOR" is C:\RBBS\GET3RD.DEF 4. The "DOOR" is to be invoked by SHELLing. 5. The template to use is designed to invoke a .BAT file and pass two different responses acquired from the questionnaire when the .BAT file is invoked. 6. Returning from the "DOOR" the caller must reenter their password. 7. The caller is to be shown the file "KEYCHK.FIL" when the "DOOR" ends. The control file would have the following line in it: SKYCHK,10,C:\RBBS\GET3RD.DEF,S,"RUNKEY.BAT [1] [2]",Y,KEYCHK.FIL, RBBS-PC CPC17.3 Page 109 9.7 Parameters for RBBS-PC's Security (part 1) ----------------------------------------------- Parameter 121 is the first and last name alias (i.e. pseudonym) that the SysOp will use when logging on remotely. It is this alias 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. If you want to eliminate anyone from logging on as the SysOp, you can simply reply with a "null" (i.e. a carriage return) for the first and last name for parameter 121. The ESC key is used to log on in local SysOp mode. Parameter 122 can be set so that the pseudonym specified for parameter 121 is required to be entered from the local keyboard of the personal computer on which RBBS-PC is running when the escape key (Esc) is pressed. If you enter YES, no password is required. Parameter 123 specifies the minimum security level users need in order to log onto RBBS-PC and parameter 124 specifies the security level assigned to new users. If the security level assigned new users is less than the minimum security level to log on, no new users can logon on. This means that no new users are allowed and access is limited only to pre-registered users. Since one of RBBS-PC's two objectives is to facilitate the exchange of information, every RBBS-PC SysOp is urged to not entirely deny new users access. The chapters on RBBS-PC's extensive security features and subscription and time management system detail the ways in which a SysOp can control access to his RBBS-PC without having to deny access to new users -- chapters 16 and 10, respectively. Parameter 125 specifies the minimum security level a user must have in order to be considered a SysOp. Even if a user has a high enough security level to see the SysOp menu and execute some or all of the SysOp commands, the user will not be treated as a SysOp (i.e. allowed to see the files upload/download when viewing the CALLERS file) unless the users security level is equal to or greater than that specified by this parameter. Parameter 126 prevents the SysOp menu from being displayed (even if the user has a security level of a SysOp as specified in parameter 125) unless the user is also at this security level. Parameter 127 is 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 under the single FMS environment. Parameter 128 allows a maximum number of security violations (i.e. attempts to download protected files) before the user is logged off and locked out. Parameter 129, parameter 130, parameter 131, parameter 132, and parameter 133 allow the SysOp to set up the security levels required to issue the commands in the SysOp, Main Menu, File Subsystem, Utilities Subsystem (respectively), and global commands. All the commands in each area can be given the same security level or, optionally, a specific command can be given a unique security level. RBBS-PC CPC17.3 Page 110 Parameter 134 allows the SysOp to specify the maximum number of times users can change their passwords in a given session. This prevents a caller from "fishing" for special passwords. Parameter 135 is the minimum security level required in order for users to change temporarily their security or time on the system via privileged group passwords. If users do not have the minimum security level to temporarily change their password, 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 of CONFIG! Parameter 136 allows the SysOp to specify a security level that has the privilege of overwriting files (i.e. files that already exist) when uploading. When the SysOp "purges" the USERS file, all users who have not signed on within the number of months specified in parameter 11 are deleted from the file with the exception of those who have been "locked out" and those whose security level is equal to or greater than that specified in parameter 137. Parameter 138 allows the SysOp to specify the security level required to read new PRIVATE messages. Only those with this security level or higher can read new private messages -- even if they have been addressed to them. By setting this value higher than any other user than that of the SysOp, the SysOp can then review all new private messages before allowing them to be seen by the addressee. After reviewing these messages, the SysOp can change the security level so that the message can be seen by the sender and the addressee. Parameter 139 allows the SysOp to specify the security level required to read new PUBLIC messages. Only those with this security level or higher can read new public messages. By setting this value higher than any other user than the SysOp, the SysOp can then review all new public messages before allowing them to be seen. After reviewing these messages, the SysOp can change the security level so that the message can be seen. Parameter 140 specifies the minimum security level that is able to change the security level of a message. RBBS-PC CPC17.3 Page 111 9.8 Parameters for RBBS-PC's Security (part 2) ----------------------------------------------- Parameter 141 is not implemented in RBBS-PC. Parameter 142 allows the SysOp to specify the drive and path where the "personal directory" and files it contains 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 be personally downloadable. However, the download directory must be here. Parameter 142 allows the directory and/or files that are personally downloadable not to be accessible through the normal download, if desired. The "personal directory" is utilized by the P)ersonal download command in the files section of RBBS-PC. It differs from D)ownload in that (a) only files listed in the directory can be downloaded versus any file that exists, (b) the time to download is not checked against the time remaining, so that the file can be downloaded regardless of how little session time remains, (c) the files downloadable can be constrained to match any field in the user's record (e.g. limited by caller's name so that file is addressed specifically to the caller), (d) the download can be constrained by security level. Parameter 143 allows the SysOp to provide the name of the "personal directory" -- the default name is "PRIV". If no extension is specified, ".DEF" will be used. The personal directory has a different format from the other directory files. It has a one-character field after the file description used to mark whether file has been downloaded. This is followed by the field that matches the user record (or has a security level if the first character of the field is blank). Parameter 144 is a way of specifying the default protocol to be used when downloading personal files using the "P" command in the file subsystem. 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;test;y"). Parameter 145 specifies the name of the file that contains a list of file names that CANNOT BE DOWNLOADED (even if they are on the disks that are available for downloading) unless the user supplies a password and/or is at a specific security level. If you want to have no file security at all, just put no file names in this file. If you include a password with a file name all users (including one with SysOp privileges) must be able to give the password in order to download the file. For a more detailed description of this file and how it works, see the section entitled "How to Implement the Security for Download Files." Parameter 146 specifies the file name which contains the privileged group passwords that allow users to change temporarily their security, time on the system, etc. -- if the SysOp has set it up that way. Callers shift to a group password by changing passwords. If the password they select is found in the file containing the privileged passwords, their private logon password is unchanged and they receive the security level and/or time limit associated with the group password. If you have no group RBBS-PC CPC17.3 Page 112 passwords, just put nothing in this file. For a more detailed description of this file and how it works, see the section entitled "How to Implement the Password File." Parameter 147 provides the SysOp with the mechanism to allow users to download multiple files using the ASCII protocol (i.e. no error checking) without any pausing or messages between files. This is particular useful if the SysOp wants users to download to a continuous feed printer. Parameter 148 specifies the minimum security a user must have in order to be able to "categorize" uploads when the SysOp is using the File Management System (FMS). Not all callers who upload files may categorize them in the way that the SysOp wants. Parameter 149 controls who can view new uploads based on security level. If the upload directory is not also the FMS directory, it is only viewable by those who have a sufficient security level. If the upload directory is the FMS directory, the entries with the default categories will be viewable only if a caller has a security level equal to or greater than that specified in parameter 149 (all other categories are viewable). Parameter 150 specifies the security level of those users who will not be shown the "epilogue" questionnaire. Typically the "epilogue" questionnaire asks users questions or invites them to register. Once they have done so, the SysOp can have their security increased to this value either automatically (i.e. via the questionnaire's script) or manually such that the users no longer see the "epilogue" when they sign off. Parameter 151 is the security level required to automatically add a user to a SEMI-PRIVATE "conference". This parameter can only be activated when CONFIG is in "conference maintenance" mode (see parameter 167). Each message file has a security level associated with it which is the MINIMUM SECURITY for a user to join it if the user is not in that conference's USERS file. Callers with the minimum security level specified in parameter 151 are automatically added to the USERS file associated with that conference if they are not there. RBBS-PC's "auto-add" security feature permits SEMI-PRIVATE conferences, that are open to callers with a certain security level. The "auto-add" capabilities of RBBS-PC makes it possible for SysOps to have non-public conferences without having to add each desired caller to the user's file. A public conference is one whose "auto add" security level is no higher than the default security and whose USERS file is the same as the main message base's. This has the advantage of saving disk space (i.e. there is only a single USERS file) but the disadvantage of not remembering the last message read by the user in each conference. A totally PRIVATE conference is one that is limited to persons already in the USERS file associated with that conference and is created by making the "auto add" security level higher than any caller's security. RBBS-PC CPC17.3 Page 113 A SEMI-PRIVATE conference is one that has it's own USERS and welcome file and whose "auto add" security level is set at an intermediate level that some callers have and some do not. As an example, if a conference is to be totally public but the user's last message read, preferences, and security level in the conference are to be remembered, 1. set the security level required to automatically add a user to the conference equal to the CONFIG utility parameter 124 (the default security level for new callers), and 2. create a user's file for the conference. All callers can join, and each user is automatically added to the conference's USER file as they join the conference. If you want a conference to be SEMI-PRIVATE set the security level to be "auto add"ed to the conference higher than the default security level for your system and only those users who have the security level specified in parameter 151 can join the conference. Parameter 152 is the minimum security level for a caller to "turbo logon". It only applies to callers that have called your RBBS-PC system at least once. It can be used to bypass everything when a user logs on (bulletins, welcomes, etc.) and go directly to the either the main RBBS-PC menu or directly to a conference. It only can be utilized when doing a single line log on and by following your password with an exclamation point. The "single line" logon has the format: first name; last name; password;!conference name As an example, a user named "Jon Smith" who called back for the second time and had a password of "swift" who had been assigned a security level that permitted "turbo logon" privileges who wanted to go directly to the conference "RBBS-PC" could log on with the following sequence: jon;smith;swift;!rbbs-pc Parameter 153 is the minimum security required by a caller to add a directory entry for an existing file. Typically this is restricted to the SysOp only. Parameter 154 is the name of the help file that is automatically shown (if the file exists) to a caller whenever the caller incurs a security violation. It is an ideal candidate for using RBBS-PC's personalized "smart" text file capabilities as described in section 6.9. Parameter 155 allows the SysOp to deny callers access to two of RBBS-PC's "premium features -- DOORS and file downloading (either or both), for a specific period of time. One of the two purposes of RBBS-PC is to foster the free exchange of information. Many SysOps would like to encourage new callers to read bulletins and look at messages when they initially logon. One approach is RBBS-PC CPC17.3 Page 114 to simply restrict new users from all of the other RBBS-PC features using RBBS-PC's extensive security system. RBBS-PC provides an intermediate solution by allowing a SysOp to require a user to be on-line for a specific amount of time within a session before DOORS or file DOWNLOADS, premium features are available to a caller. This feature is implemented by both activating CONFIG parameter 155 and setting up the PASSWRDS file appropriately, see section 14.4. For each level in the PASSWRDS file, a parameter specifies how many SECONDS the caller must have used 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. See section 14.4 for a more detailed description of how to implement this feature in the PASSWRDS file. 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." The example TIMELOCK.HLP uses SMART TEXT. If SMART TEXT is not implemented with control code (123), the file TIMELOCK.HLP should be modified as appropriate. Parameter 156 is the security level of a caller in a "sub-board" or "conference" who will have their security level automatically reflect whatever the security level they are assigned in the main USERS file. This means that on large RBBS-PC's with many "sub-boards" and "private conferences" the SysOp does not have to update each caller's USER record in the many different USER's files. The SysOp need only change the caller's USER record in the main USER file and it will be reflected in any "sub- board" or "conference" that the caller joins. Parameter 157 is 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). A SysOp of a "sub-board" no longer need be given full SysOp privileges when the SysOp just needs to be able to review and monitor all mail. If a message record begins with an ASCII value of 1, it will not be displayed to the caller. Parameter 158 allows the SysOp to specify any character string IN ADDITION to this that RBBS-PC is to use as a criteria for not displaying a record in the message file. The default value is "SEEN-BY:". RBBS-PC CPC17.3 Page 115 9.9 Parameters for Multiple RBBS-PC's/Conferences -------------------------------------------------- RBBS-PC allows multiple RBBS-PC's to run in the same environment/network and share many of the same files. If you ever plan to do this or if you are going to do this, set this number to the MAXIMUM number you ever envision running. Up to 36 RBBS-PC's can share the same files. Different environments have different maximum number of nodes that they can effectively support. Parameter 161 allows you to specify the maximum number of RBBS-PC's that the MESSAGES file should be initialized for. Parameter 162 allows the SysOp to designate the type of 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: 1. MultiLink (The Software Link, Inc.) 2. OmniNet (Corvus) 3. PC-Net (Orchid) 4. DESQview (Quarterdeck Office Systems) 5. 10 Net (Fox Research) 6. IBM's NETBIOS 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. Some local area network environments are not designed to have applications constantly branch back to the beginning and re-open already open files. If you are in this environment or simply want to run external programs after a user logs off or RBBS-PC recycles, parameter 163 allows you to elect to do this. If you specify "internal", RBBS-PC will function as it currently does and branch back to its beginning. If you specify "system", RBBS-PC will exit to DOS and (if you are running RBBS-PC out of a .BAT file) you can then automatically invoke any other "housekeeping" programs you want before re-invoking RBBS-PC. It should be noted that this will add a considerably delay to RBBS-PC's recycling time as RBBS-PC will have to reloaded back into memory every time it recycles. Like the MESSAGES file, the USERS file must also be static in length for RBBS-PC. Parameter 164 allows the SysOp to set the size of the USERS file. RBBS-PC automatically keeps track of the records available for use in this file and does the necessary "housekeeping." To do this RBBS-PC requires the USERS file size (i.e. the number of records in it) to be a power of 2. When the USERS file get full (i.e. all its records are used up) and the SysOp neither "packs" it nor increases the size of the file, no new users will be able to be added to the users until one of these two events occurs. Parameter 291 lets new users get on even if the users file is full. RBBS-PC requires that the "Messages" file be static in length. It automatically keeps track of the next record available and does the necessary housekeeping to maintain the integrity of the file. Parameter 165 allows the SysOp to set the size of this file. When the MESSAGES file get RBBS-PC CPC17.3 Page 116 full (i.e. all its records are used up) and the SysOp neither "packs" it nor increases the size of the file, no one will be able to leave a message until one of these two events occurs. 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) Therefore, if parameter 161 of CONFIG where 12 and parameter 165 of CONFIG where 50, the minimum number of records that could be specified for parameter 125 would be 1 (The "checkpoint record) + 12 (The number of "node" records) +250 (50 messages x 5 128-byte records each) ---- 263 records for the MESSAGES file Parameter 166 lets you set the maximum number of messages that the SysOp will allow on the system at any one time. The number will have to be based on the size of the average message on your bulletin board. Most messages require about 600 bytes on the average. 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. Parameter 167 allows "conference" files to be maintained. A "conference" consists of a message file and, if a "private" or "semi-private" conference, a corresponding users file. The name of the conference can be anything that the SysOp selects but can not be longer than 7 characters. The message file's name for a conference consists of the conference name plus the characters "M.DEF". The user file's name associated with "private" conferences consists of the conference name plus the characters "U.DEF". Parameter 167 allows the SysOp to create, expand, or contract either or both of the files associated with a "conference." This occurs ONLY when the SysOp "ENDs" the CONFIG session by pressing the key marked END. Parameter 167 allows the SysOp to perform all the utility functions on page 10 of CONFIG on the conference that was named/selected with parameter 167. To make a "private" conference "semi-private", see the discussion under parameter 151. For a further discussion of "conferences" see sections 18 and 15. Parameter 168 is the file extension to be automatically added to the name of any uploaded file that has no extension specified by the caller. RBBS- PC will not permit a file to be uploaded if the file name being uploaded already exists but has the default extension. As an example if a caller attempted to upload TEST.ARC and 1. the file TEST.ZIP existed and 2. parameter 168 specified ZIP, then the caller would be told that a duplicate file existed. RBBS-PC CPC17.3 Page 117 Parameter 169 lets the SysOp specify 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 counted as already on the board 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 allows the MESSAGE files to "grow." The need for having a pre-allocated MESSAGE file was dictated by the limitations of the Corvus Network software. Since none of the other networks supported by RBBS-PC have this limitation, parameter 169 allows a SysOp to setup a nominal message file (say 500 records) and allow it to grow as user's leave messages. Note: this lets the message file have up to 32,767 records. It does not remove the maximum on the number of messages that RBBS-PC can handle (up to 999). RBBS-PC CPC17.3 Page 118 9.10 RBBS-PC SysOp Utilities ----------------------------- The message file contains all messages for the RBBS-PC system. As messages are killed they are only flagged as inactive. Parameter 181 should be used periodically to recover the space occupied by the killed messages. After completion, only the text of active messages will be present and the old file will remain on the system with the qualifier of ".OLD". Also, you will need enough free disk space for a second copy of the messages file (with a qualifier of ".BAK") when packing a message file or the packing cannot be performed. If enough space is not found the packing will terminate abnormally and the message file will be recovered. Parameter 182 removes deleted users and users who have not been on the system within the number of months specified using parameter 16 in CONFIG. 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). It is important to note that beginning with CPC12-5A, users files are no longer a random file that is accessed sequentially but now is a random file that is accessed directly. When a user logs on to RBBS-PC or joins a "conference", RBBS-PC "hashes" the users name to find the users record directly. That is why every users file's size is a power of 2 (i.e. 256, 1024, etc.). This allows users to log on much more quickly to RBBS-PC's that have a very large number of users. Parameter 183 will display 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 permits messages to be renumbered sequentially starting from a specified message using whatever starting number you wish. Please note that there is not much error checking to be sure that the new numbers do not duplicate those of lower numbered active messages. When complete, the next message to be created will be the next higher number from the resequence. Unpredictable results will occur if a SysOp creates messages with duplicate numbers! Parameter 185 goes through the current message file and reconstructs the chains that link the messages together. Message files that have "blank" messages or abbreviated messages (i.e. some lines of text are missing) can be repaired with this facility. Parameter 186 allows the SysOp to require all users (old and new) to answer the required questionnaire whose name was specified in parameter 82. Parameter 187 allows the SysOp to determine whether the format of the RBBS- PC directory of files being used by the RBBS-PC File Management System (FMS) conform to the exact fixed 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). RBBS-PC CPC17.3 Page 119 Parameter 188 allows the SysOp to determine whether the format of the personal downloads directory is in the proper format for a single FMS. Parameter 189 is a utility that will guide a new SysOp, sequentially, through the parameters that would normally have to be changed when setting up a new RBBS-PC. Parameter 190 is a utility that will guide a SysOp, sequentially, through the parameters that are new and/or changed for the current release of RBBS- PC. Parameter 191 is a utility that will turn the "printer enabled" flag off in all the node records. This is useful if somehow the printer is accidentally enabled when no printer is available because the code generated by the BASIC compiler doesn't recover from this condition. Parameter 192 allows the SysOp to select how "highlighting" of text will be treated. This prevents users who have not elected to have color graphics from seeing meaningless data imbedded in the displayed text. Putting in nothing disables color prompts and highlighting of search strings. For a more complete explanation of RBBS-PC's display of colors to callers in text files see section 6.10. RBBS-PC CPC17.3 Page 120 9.11 RBBS-PC's File Management System Parameters ------------------------------------------------- Parameter 201 specifies the letter of the single drive available to this copy of RBBS-PC to which uploaded files can be written. When a file is uploaded, the file specified by CONFIG parameter 202 will be automatically appended with the file name, file size, date of upload, and short description as specified by the user. Parameter 202 of the CONFIG program asks for the name of the text file to be used as an RBBS-PC "directory" of files into which the file name, file size, and file description of uploaded files can be recorded. The default name is 99.DIR and it must be on the drive/path specified in parameter 203. Parameter 203 specifies the drive/path were the upload directory is to be found. Parameter 204 specifies the letters of the drives from which files can be downloaded. The order in which they are specified is the order in which the drives will be searched. If the order is BAC, then drive B will be searched first for the file, then drive A, and finally drive C. While there can be duplicate files on each of the drives, the first file found will be the one downloaded to the user. Parameter 205 allows the SysOp to indicate that DOS subdirectories are to be used by allowing the number of DOS subdirectories to be used for downloading to be specified (0 to 9999). This number is equal to the number of DOS subdirectories to be used for uploading (0 or 1) plus the number of DOS subdirectories to be used for downloading. Parameter 206 allows the SysOp to indicate the DOS subdirectory to which uploads are to be written. RBBS-PC will prepend the upload disk drive to it (see parameter 201) and append the upload file name after it when uploads are written to disk. Parameter 207 allows the SysOp to indicate that DOS subdirectories are to be used when searching for files on downloading. A valid download drive followed by a colon, a reverse backslash, and the subdirectory name that is to be searched must be entered. If the root directory is also to be searched, just enter a valid download drive followed by a colon. Each download disk drive is searched for only those subdirectories that were specified as existing on that specific drive. If two download DOS subdirectories are specified (A:\TEST1 and B:\TEST2) and two download disk drives for parameter 204 (A and B), the search for a download file will be in the following order: A:\TEST1\filename B:\TEST2\filename It is possible to have the same subdirectory name on different download drives. Each would have to be individually specified (A:\GAMES and B:\GAMES If they where, the search for a download file would be as follows: A:\GAMES\filename RBBS-PC CPC17.3 Page 121 B:\GAMES\filename Parameter 208 is only functional if you have responded "Yes" to either parameter 206 or parameter 207. This parameter allows the SysOp to list, change, add, or delete the DOS subdirectories to be used for either uploading (parameter 206) or downloading (parameter 207). CONFIG does NOT actually create or delete such DOS subdirectories -- that's up to the SysOp to do using the standard DOS commands. Parameter 208 simply allows the SysOp to identify which DOS subdirectories will (or may) exist when RBBS-PC is running. Parameter 209 allows the SysOp to specify the extension that RBBS-PC's "directories" of files are to have. See section 13 for a description of RBBS-PC's "directories" of files.-- they have no relation to DOS 2.x and above subdirectories! Most SysOps categorize the files that are available for downloading into general groups (games, utilities, etc.). The default is "DIR". Parameter 210 specifies the 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. The name of the directory of directories is specified in parameter 211. This allows sub-boards with the same extension to have a different directories of directories. The main RBBS-PC system might have a directory of directories named MAIN.DIR where parameter 211 was "MAIN" and parameter 209 was "DIR". A sub-board might have a directory of directories named BETA.DIR where parameter 211 was "BETA" and parameter 209 was "DIR". Parameter 212 allows the SysOp to exclude the primary directory (DIR.DIR) from the search done by the New command. If you have multiple directories (i.e. RBBS.DIR through BASIC.DIR), any dates in the primary directory would not be of files. The "New" command (as in "What new files have been put on the download directories since I was last on?") search each line of each file whose extension is DIR for a date field. Since the first level directory is normally a listing of the other directories and their general subject areas, it is advisable to omit the first level directory from the "New" command. Descriptions of files uploaded are always appended to the upload directory. Parameter 213 allows the description to be appended to another file. This could be, for example, a list of all files on the system, or the basis for a bulletin reviewing the uploads. Parameter 214 is how the SysOp declares that there is a shared, single FMS directory. Leave it blank if there is none. Section 13 discusses in detail the advantages of using this directory, which has a different structure from other directory files. This file must be in the drive/path for directories. RBBS-PC CPC17.3 Page 122 Users who upload can classify uploads into a category if their security is at least as high as the level specified in parameter 148. This option can save the SysOp considerable time. If the uploader cannot classify the upload, it goes only to the upload directory and uses the default category code if written to the FMS directory. If you do NOT want users to categorize the files that they upload, independent of whether or not you are using FMS, simply set the CONFIG parameter 148 to a security level higher than any user can obtain. If the uploader cannot classify the upload, it goes only to the upload directory and uses the default category code if written to the FMS directory. If you DO want users to categorize the files that they upload you must follow these four steps: 1. Set CONFIG parameter 148 to the security level of the U>pload command. 2. Create a help file to show users when they are asked to categorize an uploaded file that might look something like: Category Category Description Code Name 1 Utilities General Utilities 2 Games Games 3 RBBS-PC RBBS-PC files 4 RBBS-UTIL Utilities for RBBS-PC 3. Set CONFIG parameter 67 to the name of the file that you created for step 2 4. If, and ONLY if, you are using the FMS, create a second file in the format described in section 11.4 for parameter 217 and set parameter 217 to the name of the file created in this format. Set parameter 215 to "YES" if there are no directories other than the FMS directory. That increases the speed of RBBS-PC because it does not look for additional directories. If you do not have a shared directory or have a hybrid system with some physically distinct directory files, set this parameter to "NO". Parameter 216 is the default category code for uploads. This parameter is how uploads get classified in the FMS directory if the uploader cannot provide a classification. To make all new uploads private and viewable only by the SysOp (until the SysOp reviews the files and changes the classification), set the default code to "***". The default is "UNC" for UNClassified. Parameter 217 is the name of the text file which tells RBBS-PC what categories are included in the shared FMS directory. The format of the file is described in section 11.5. Parameter 218 allows the SysOp to specify 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 RBBS-PC CPC17.3 Page 123 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. "BEST" would list directory BEST.DIR, located in the drive/path specified where directory files go. If you want "all" to search nothing, just press Enter in response to this parameter. Parameter 219 sets 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: this option will not change the length of existing directories. Parameter 220 specifies 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). RBBS-PC CPC17.3 Page 124 9.12 Communications Parameters (part 1) ---------------------------------------- Parameter # 221 requests the user to specify the communication port that RBBS-PC will use. If you specify COM0, RBBS-PC will run on a PC without using a communications port or modem and still appear to the PC user as if they were accessing RBBS-PC remotely. This "workstation" feature can allow RBBS-PC to be used in a local area network environment where each of up to 36 PC's can access the central RBBS-PC system (on the LAN server) and use RBBS-PC for electronic mail within the LAN. Alternatively this "workstation" mode can be used to teach users how to access RBBS-PC in a classroom environment without requiring telephone access. The BASIC language can only support COM1 and COM2, and when either of these are selected and you specify that you will not be using a "FOSSIL" driver, RBBS-PC will use the built-in BASIC support for remote access (i.e. via a communications port and a modem). However, RBBS-PC will interface with "FOSSIL" drivers that support not only COM1 and COM2 but also COM3 through COM8. If you use parameter 221 to indicate that RBBS-PC is to access the communication port via a FOSSIL driver, the FOSSIL interface (FOSSCOMM.OBJ) written by Daan Van der Weide will be used. FOSSCOMM.OBJ provides access to whatever FOSSIL drivers that are installed on the PC running RBBS-PC. In a multi-tasking environment such as DESQview up to 8 copies of RBBS-PC can run simultaneously accessing COM1 to COM8, respectively, using Ray Gwinn's X00.SYS device driver. Ray can be reached via FidoNet (109/639) or the RENEX bulletin board at (703) 494-8331 or (703) 690-7950. Parameter 222 allows the SysOp to specify the number of seconds that RBBS- PC should wait after initializing the modem with a "reset" command. Most modems require only 2 seconds, however some may require much (MUCH) longer. If the 2 second default is not sufficient consult with your modem vendor and try different settings. Parameter 223 allows the SysOp to specify how long 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. The default setting is one second. 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 specifies 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. If you specify the number ONE, RBBS-PC will wait for the phone to ring and then instruct the modem to answer the phone. This is the default setting and requires that the modem be capable of indicating to RBBS-PC that the phone is ringing -- either providing the "ring indicator" signal via a modem cable that has PIN 22 connected at both ends OR by sending the characters "RING" each time the phone rings. Specifying a number equal to ZERO (and not specifying "ring-back") means that RBBS-PC will initialize the modem to automatically answer the phone (independent of RBBS-PC) and RBBS-PC will simply wait for carrier detect to RBBS-PC CPC17.3 Page 125 occur. This is NOT RECOMMENDED. However, if your non-Hayes modem simply is incapable of indicating that the phone is ringing or your modem cable does not have PIN 22 connected, this is the option you will have to elect. If this option is selected, you will be reminded that you are shooting yourself in the foot by allowing exiting to DOS remotely (either through a "door" or via the SysOp function 7) when activating "doors" in parameter 101. This is because in this mode (the modem answering the phone and NOT RBBS-PC), if you were inadvertently disconnected while in DOS or in a "door", the next person to dial your system would be connected to wherever you were because the modem (not RBBS-PC) is answering the phone. If you specify a number greater than 2 means that RBBS-PC will either: 1. wait until the specified number of rings to answer the phone, or 2. answer the next call after the current one after the specified number of rings specified provided that the next call comes within 45 seconds after the first call stops ringing the phone. This mode is called RING-BACK. Specifying a number greater than one is useful only when a single phone line can receive both voice (i.e. callers who wish to speak with the SysOp) and data calls (i.e. for RBBS-PC) on an unscheduled basis. In this type of environment (i.e. a random mix of voice and RBBS-PC calls), there are two ways a SysOp can set up RBBS-PC so that RBBS-PC can automatically determine if the call is for the SysOp or for RBBS-PC. First, the SysOp can establish the rule with the callers that if unable to personally answer the phone, then RBBS-PC will answer the phone after it rings the number of times specified in parameter 224. Callers can let the phone ring and (if it is not answered by a person within some agreed upon number rings) know that it will be answered by RBBS-PC. This is useful to those who may have either hearing or speech problems and are unable to use the telephone conveniently for voice communications. A second approach is the more classic, "ring-back" approach. RBBS-PC can be told to NEVER answer the first call (it can ring forever!). However, should the caller WAIT A MINIMUM OF 12 SECONDS (a Hayes restriction) and call back no later than 45 seconds after the last ring of the first call, RBBS-PC will answer the call after the number of rings indicated in parameter 224 provided that the number of rings is set to between one and five. If callers want to make a voice contact, they can simply call and let the phone ring until it is answered. If you have a dedicated line for your RBBS-PC (either full-time or on a scheduled basis), parameter 224 should be set to ZERO. Parameter 225 provides the SysOp with the capability of selecting ANY modem commands appropriate for the modem being used -- not just the default Hayes commands RBBS-PC would normally use. Before the default RBBS-PC standard Hayes commands are changed, you should thoroughly understand the modem that your are using and the modem commands, as used by RBBS-PC, that are described in section 10. Parameter 226 allows the software-based MNP to be optional within RBBS-PC. REGRETTABLY, this option can not be selected with version CPC17-2A. This RBBS-PC CPC17.3 Page 126 is because it was not possible to resolve the linkage incompatibilities between the new compilers and the MNP library and RBBS-PC interface prior to the release of CPC17-2A. Every effort is being made to correct this particular problem. However, RBBS-PC does support MNP protocol that is hardware-based (i.e. built into the calling and answering modems). Some SysOps may not wish to provide their users with the choice of MNP protocol (especially if they are employed by a company that has a competing protocol). RBBS-PC's features and growth are designed to be "additive." This parameter allows each SysOp to decide if MNP protocol is to be available for file transfers. Microcom's error-free protocol, MNP, has been available for file transfer beginning with version CPC12-4A of RBBS- PC. Parameter 227 allows the SysOp to tell RBBS-PC either to wait to issue commands in-between rings or to issue modem commands without waiting. Some modems cannot both handle the telephone ringing and accept modem commands simultaneously. Other modems, like the Hayes, can handle such simultaneous demands. For these later (i.e. Hayes, Prometheus, Multi-Tech, etc.) this option should be set to "NO." Some 2400 baud modems (like the Hayes) MUST be opened initially at 2400 baud because when they automatically answer the phone they can only "bump down" when automatically detecting baud rate (i.e. from 2400 down to 1200 down to 300). Parameter 228 allows the SysOp to select the baud rate at which RBBS-PC is to open the modem at initially. The SysOp can select the number of seconds RBBS-PC will allow a user to be "idle" (i.e. not sending or receiving data) via parameter 229. Before a user is logged off, a warning message is issued. If the caller remains idle for the following 30 seconds the caller is automatically logged off. Parameter 230 allows the SysOp to indicate if a "dumb" modem is being used (i.e. one that will answer the phone and automatically detect the caller's baud rate if it is the modem was opened for). Selecting this means that no modem commands are written to the modem. If the SysOp has a non-Hayes modem (i.e. one that will not recognize Hayes commands and will not return Hayes responses) that will only "auto-answer" the phone, parameter 230 allows the SysOp to so indicate to RBBS-PC by selecting "dumb" modem. Typically this would be some communications network (i.e. TymnNet) or local area network that supplied a simple RS-232 interface. Selecting this option causes RBBS-PC to 1. Issue no Hayes commands, 2. Depend on no Hayes-like responses, 3. Control the interface with the Data Terminal Ready (DTR), 4. Assume somebody has called whenever Carrier Detect (CD) is detected, and 5. Assume that whomever calls is at the baud rate selected in CONFIG parameter 228. The Hayes 2400 baud modem has no hardware switches. It's remembered, permanent settings can be set only through software. Parameter 231 will properly initialize a Hayes 2400 modem for use with RBBS-PC. RBBS-PC CPC17.3 Page 127 Parameter 232 is the time to wait after dropping DTR. This is used in RBBS-PC for dropping the connection after a caller logs off normally. Too short a delay will cause the modem not to re-initialize properly. The default time is 3 seconds. In order to provide the maximum flexibility (and get RBBS-PC out of the protocol writing business), RBBS-PC supports external protocol drivers via a standard interface. The external protocol driver for YMODEM, YMODEMG, IMODEM is the file QMXFER.EXE. The external protocol driver for WINDOWED XMODEM is WXMODEM.EXE. The external protocol driver for KERMIT is PCKERMIT.EXE. These protocols work only if the external drivers are available and defined in the file specified by parameter 233. Also see sections 19.1 and 20.2 on how these drivers are invoked. RBBS-PC can check right after a caller logs on whether the caller's communication program supports autodownload. Turning on parameter 234 means that RBBS-PC will always do this check. However, this check is incompatible with some terminals and communications packages, causing them to stop displaying on the local screen. If the check is passed, RBBS-PC announces that autodownload is available and asks callers if they want to use it. This check is unnecessary for autodownload to work. 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 allows the SysOp to tell RBBS-PC that files ending in binary file extensions (i.e. .ARC, .EXE, .COM, .OBJ, .WKS, .BAS, or whose second letter of the extension is Q) can not be downloaded unless the user selects a non-ASCII protocol. This should eliminate some user problems before they occur. IBM's BASIC interpreter's SAVE command default is to write files in a special binary format (also referred to as 'tokenized') because they require much less disk space. Parameter 236 allows a SysOp to use some of the "less than perfect" modems that have a tendency to "go to sleep" under rigorous usage. Setting this parameter to a non-zero value, means that RBBS-PC will re-cycle if no calls are received after the specified non-zero value number of minutes. When re-cycling RBBS-PC resets the modem -- hence "wakes it up" if it has gone to sleep. A setting of 10 minutes is recommended for busy lines and 60 minutes for less busy lines. Specifying 0 means that RBBS-PC will not re- cycle if no calls are received, but simply wait for the next caller. Parameter 237 allows the SysOp 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 will match the baud rate of the incoming caller and allow the PC to continue communicating with it at the baud rate the modem was opened at (the modem buffers it down to the callers baud). Some 9600 baud modems will allow the PC that they are connected with to transfer data to them at 19,200 baud and the modem will talk to the caller at whatever the baud rate of the incoming callers modem is set at. RBBS-PC CPC17.3 Page 128 9.13 Communications Parameters (part 2) ---------------------------------------- Some of the less sophisticated communications packages automatically switch back to their original communications parameters for parity, data bits, and stop bits if the user manually changes them during the session. Similarly some of the older public data networks can't talk to a terminal that is set at N/8/1. As all error-free protocols typically require the settings for these to be N/8/1 (i.e. no parity, eight data bits, and one stop bit), parameter 241 allows the SysOp to have RBBS-PC accommodate these more primitive environments by automatically switching back to the original parameters after the file transfer is complete. Parameter 242 allows a SysOp to decline calls from new callers based on the baud rate specified. Some SysOps believe that 300 BAUD users have a "pre-puberty" mentality and cause more problems (i.e. infantile messages) for the SysOp than their contributions justify. Another reason for denying access to 300 BAUD users is when RBBS-PC is running in a multi-tasking DOS environment that does not handle 300 BAUD very efficiently (i.e. like MultiLink). While RBBS-PC is intended to be as open a system as possible, each SysOp has the option of electing to accept calls of only a certain baud rate or higher for new callers. Whatever reasons a SysOp has for denying access to 300 BAUD users, this option enables the SysOp to select to do so using CONFIG rather than having to modify the RBBS-PC source code. Parameter 243 allows RBBS-PC to be configured to allow registered users to logon at any baud rate baud even if new users can't. Parameter 244 allows modems that require it, to have "flow control" between the modem and the PC running RBBS-PC using the "clear-to-send" signal, RTS. Some modems with built-in error checking protocols require this to be set on or, should an error-free link become disconnected, the modem will never respond to the PC after RBBS-PC recycles. Parameter 245 allows another method of "flow control" between the modem and the PC running RBBS-PC -- XON/XOFF. Since RBBS-PC attempts to write to the caller as fast as possible, XON/XOFF flow control is normally turned off -- unless parameter 245 has enabled it. When RBBS-PC is attached to a public data network, it can be sometimes necessary to use this method of "flow control" rather than "clear-to-send". Setting this parameter to "yes" means that RBBS-PC will universally support XON/XOFF. However the XON/XOFF check is only made after the buffer is emptied as specified in parameter 54. It is recommended, when XON/XOFF flow control is going to be used, that parameter 54 be set to 32 bytes so RBBS-PC can be as responsive as possible. Parameter 246 specifies the maximum time to wait for carrier after RBBS-PC answers the phone. Some of the "less than perfect" modems disconnect immediately and RBBS-PC would stay "off the hook" long enough to receive the automated voice message requesting the modem to "hang up and please dial again." RBBS-PC CPC17.3 Page 129 9.14 Parameters for RBBS-PC NET-MAIL ------------------------------------- Parameter 261 allows the SysOp to specify the time of day in HHMM format after which RBBS-PC is to exit after creating a dummy file called RBBSxTM.DEF where "x" is the node ID of the node that EXITed to DOS. By adding two "IF" statements to the simple .BAT file described in Section 14, the RBBS-PC-created file RBBSxTM.BAT will be invoked if RBBS-PC is invoked with the following .BAT file (assuming "x" = node id = 1): IF EXIST C:RBBS1F1.DEF DEL C:RBBS1F1.DEF ' Delete SysOp F1 semaphore IF EXIST C:RBBS1TM.DEF DEL C:RBBS1TM.DEF ' Delete Time/drop semaphore IF EXIST C:RCTTY1.BAT DEL C:RCTTY1.BAT ' Delete batch file for DOOR exit RBBS-PC.EXE 1 RBBS1PC.DEF ' Invoke RBBS-PC for node 1 IF EXIST C:RBBS1F1.DEF GOTO EXIT ' Check for SysOp F1 key pressed IF EXIST C:RBBS1TM.DEF C:RBBS1TM.BAT ' Check for Time to go to DOS IF EXIST C:RCTTY1.BAT C:RCTTY.BAT ' Check for exit to a DOOR C:RBBS.BAT ' Re-invoke RBBS-PC again :EXIT The above assumes that RBBS-PC node is "1", the name of the file that invoked RBBS-PC is RBBS.BAT, and everything is in the same DOS subdirectory on the "C" drive. Obviously, this example can be made more generic. The file that RBBS-PC exits to is named RBBS1TM.BAT (but it could be named anything that the SysOp desired). It is the responsibility of the SysOp to name and create the RBBS1TM.BAT file. A simple such file that invoked Kim Wells' utility MU-PURGE and then re-invoked RBBS-PC would contain the following two statements: MU-PURGE PURGE.CTL RBBS.BAT As always, .BAT files are limited only by the creativity of their authors. Parameter 262 allows RBBS-PC to handle "store-and-forward" mail of messages and files. Currently the only such "net mail" that is compatible with the FIDO store-and-forward mail specification is supported such as FIDO, SeaDog (see Appendix V) and BINKLEY TERM. By enabling this option, the SysOp assumes the responsibility of configuring the "net mail" application to 1. answer the phone and determine if the caller is sending "net mail". 2. if the caller is not sending "net mail", the net mail application must invoke RBBS-PC with the following command line: RBBS-PC.EXE nodeid filename /time /baud /reliable where: "nodeid" is the node ID in the range 1-9, 0, or A-Z. "filename" is the fully qualified file name to use as the RBBS-PC ".DEF" file. "/time" is the time of day for RBBS-PC to return to the "net mail" application that called RBBS-PC. "/baud" if the baud rate that the caller dialed in at. "/reliable" tells RBBS-PC whether the connection has error correction built into the connected modems RBBS-PC CPC17.3 Page 130 Parameter 263 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 he/she accesses 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 is obviously dependent on the predilections of the PDN that RBBS-PC is attached to. The string is sent just before a file exchange occurs. 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 is intended for situations where RBBS-PC is a node on a PDN. It is the string that sent following a file exchange that causes the PDN to resume 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 allows the SysOp to specify the default mode of who echoes characters back to the user. Normally RBBS-PC echoes each character that the caller types back to them. An individual caller can set their preference for who is doing the echoing in the Utilities subsystem within RBBS-PC. Callers using telecommunications devices for the deaf (TDD's) or using PDN's that do local echoing can dramatically improve their through put by not having RBBS-PC echo characters back to them. Parameter 266 allows the SysOp to force RBBS-PC to acknowledge each line uploaded via the ASCII file transfer with a character string. 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 and 268 are used by the Fast File Search in RBBS-PC. 267 is name of the sorted list of files with location (FIDX.DEF), and 268 is the file that translates the location number in the first into a drive/path (LIDX.DEF). These files must be created using external utilities. The utility MAKEFIDX.EXE is distributed with RBBS-PC to do this. RBBS-PC CPC17.3 Page 131 9.15 New Users Parameters -------------------------- Parameter 281 allows the SysOp to elect to not ask new users for their default parameters. RBBS-PC typically asks new users whether their terminal supports upper case, whether they want line feeds, what they want for a graphics preference, what they want for a default protocol, and whether they want "turbo-key". Sometimes these questions confuse new users, who lack the knowledge to answer them. To bypass the questions and force new users to get the defaults (upper and lower case, line feeds, no graphics, no protocol, no nulls), specify "NO" this parameter. Parameter 281, parameter 282, parameter 283, parameter 284, parameter 285, parameter 286, parameter 287, parameter 288, and parameter 289 are not implemented in RBBS-PC. Parameter 290 controls whether new users are logged to the USERS file. RBBS-PC normally logs new users in the users file and recognizes them as having previously logged on should they call back. If the SysOp wants new users not to be logged to the users file specify "NO" to parameter 290. Parameter 291 allows the SysOp to permit RBBS-PC to continue operating should the users file run out of room for new users. Until the SysOp rebuilds the users file or expands it, there are then two options: 1. do not let the new user on, or 2. let the new user on but do not try to add him to the user file. Saying "YES" to parameter 291 enable new users to be allowed on when there is no room rather than being told there is no room and then disconnected. RBBS-PC CPC17.3 Page 132 9.16 Use of the Library Sub-System ----------------------------------- Parameter 301 allows the SysOp to designate/activate the Library-Subsystem. The default for this parameter is "<none>". This deactivates the function in its entirety. To activate the Library-Subsystem select this parameter and specify the drive that contains your Library Disks. Note: This drive MUST be a separate drive and not the same drive as any other drive in use by RBBS-PC. If RBBS-PC is going to be run on a single hard disk and the Library-Subsystem activated, PC-DOS 3.1 or greater and the SUBST command must be used to allocate the library disks to a pseudo drive different from the other drive in use by RBBS-PC. Parameter 302 is used to select the drive\path where RBBS-PC should look for the upper level file directory (CDR.CDR is the default name). This should be the same drive selected in parameter 220. Parameter 303 allows the extension to be used to identify the Library upper level directory to be specified. (CDR is the default). Parameter 304 is used to identify the drive\directory the Library subsystem should use for creating archive files for transmission. Since the input to the archive function would be one 360k floppy disk worth of data the space requirements will be less than 360k. A RAM disk for this use should be considered. In every case the fastest disk drive available should be specified in this parameter. Parameter 305 is used to specify the highest disk number available in the Library. This value is used in editing the user request for access to the Library. Parameter 306 is used to specify 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 is the maximum number of subdirectories that each upper level directory can contain. (100 in the above example) Parameter 308 is used to specify the prefix of the lower level directories. (DISK in the above examples). 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 is used to identify the drive\path\name of the Library Sub- system menu. MENU6 is the default. Parameter 310 is a list of the symbols that are available from the Library Sub-System menu. Parameter 311 contains the security values related to the symbols listed in parameter 310. Parameter 312 is used to identify the drive\path where the archive utility program can be found. (Be sure that is where it is!) RBBS-PC CPC17.3 Page 133 Parameter 313 is used to identify the archive utility that you wish to use to do the archiving process 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. Therefore just press enter without entering a CREATE command. 9.17 RBBS-PC's Parameters for Color ------------------------------------ A detailed explanation of the use of colors within RBBS-PC can be found in section 6.10. Parameter 321 is the string that turns ON highlighting or emphasizing of characters in text strings displayed to the caller. The RBBS-PC default is a bright foreground on a red background. Parameter 322 is the string that turns OFF highlighting or emphasizing of characters in text strings displayed to the caller. The RBBS-PC default is amber foreground (normal yellow) and black background. Parameter 323, parameter 324, parameter 325, parameter 326 and parameter 327 are used in conjunction with one another. Parameter 327 is used to offset commands a caller actually needs to type in to select an option.