Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / WRB100B.ZIP / WRBBS.DOC < prev next >

Wrap

Text File | 1993-01-08 | 178.7 KB | 3,314 lines

=========================================================================== =========================================================================== == == == WR-BBS INSTALLATION AND ADMINISTRATION MANUAL == == == =========================================================================== =========================================================================== ** PRELIMINARY DOCUMENTATION AS OF 01/08/93 ** For WR-BBS versions 1.XX Copyright (C) 1992 by Wilson A. Rogers -------------------------- TABLE OF CONTENTS -------------------------- SECTION 1 PREFACE SECTION 2 IMPORTANT WARRANTY DISCLAIMER - PLEASE READ SECTION 3 WR-BBS LICENSE AGREEMENT SECTION 4 INTRODUCTION TO WR-BBS SECTION 5 THE HOME PATH SECTION 6 INSTALLING WR-BBS FILES SECTION 7 SCREEN FILES SECTION 8 WR.BAT SECTION 9 ... THE FIRST TIME SECTION 10 CONFIGURING WR-BBS SECTION 11 CLASS OF SERVICE (COS) CONFIGURATION SECTION 12 THE SYSOP SECTION 13 SETTING UP DOORS SECTION 14 TROUBLESHOOTING SECTION 15 MIDNIGHT.BAT SECTION 16 HOW THE MESSAGE SYSTEM WORKS SECTION 17 CONFIGURING EVENTS SECTION 18 THE QUESTIONNAIRE SECTION 19 THE ACTIVITY LOG SECTION 20 THE "DOWN" OPTION SECTION 21 WHILE A CALLER IS ON LINE SECTION 22 EXTERNAL FILE TRANSFER PROTOCOLS ** PRELIMINARY DOCUMENTATION AS OF 01/08/93 ** =========================================================================== SECTION 1 PREFACE =========================================================================== WR-BBS is a bulletin board communications program, designed for the small- to-medium single node BBS application. WR-BBS is distributed on an "evaluation-before-registration". This method of distribution is commonly referred to as shareware. Whether you are starting a new BBS, or replacing another BBS application, you are welcome to try WR-BBS on an evaluation basis. If it meets your expectations, register the program with the author. If it does not meet your expectations, simply delete the file named WRBBS.EXE (you can keep the rest of the files if you wish), and there is no further obligation on your part. NOTE TO CURRENT SYSOPS: If you are replacing an existing BBS application with WR-BBS, you are urged to completely back up your existing BBS program's files before implementing WR-BBS. This will minimize the inconvenience to you if you later decide that you do not wish to continue using WR-BBS, as you can restore the previous BBS application quickly. Before installing WR-BBS, you should read the documentation thoroughly, as the WR-BBS implementation of some features differs from the implementation used by other BBS programs. Also, WR-BBS has some features not found in other BBS programs (and does not have some features that other BBS programs have). There are 10 basic steps involved to install WR-BBS. It is suggested that you follow the steps in the order presented to assure a trouble-free installation: A. Read the important warranty disclaimer in section 2. Make sure that you understand that the author is not responsible for any damages before you begin installing WR-BBS on your system. B. Familiarize yourself with the license agreement. There is no point in installing WR-BBS, only to later find out that you can't live with the license agreement. C. Set up the "home path". This is described in detail in section 5. D. Install the WR-BBS files. See section 6 for information on this process. E. Edit the screen files as needed for your board. Section 7 tells how to do this. F. Read section 8, which tells how WR.BAT works, and why its use is strongly recommended. G. Establish an initial database. The command to do this is described in section 9. H. Configure WR-BBS, using WRCONFIG.SYS. See section 10 for details. I. Start WR-BBS, and then log on locally (press ALT-L). J. Test your new WR-BBS installation. The installation, configuration, and testing process should take about 30 to 90 minutes after you read this document. If you are also going to implement (optional) doors, events, and other frills, the total setup time will be longer. HOW TO GET SUPPORT FOR WR-BBS Most questions and operational anomalies can be resolved by reading this document. If you need support for WR-BBS, it is available by logging on to the WR-BBS Headquarters BBS. Call (206) 828-9089, twenty four hours a day. After logging on, leave a (C)moment for SysOp, or (W)rite a message to the SysOp from the message menu. I will endeavor to answer all support requests within twenty four hours. Support is not currently available by telephone or facsimile. Before you decide to use or register WR-BBS, please make sure you are comfortable with this support method. If you cannot get along without live telephone support, WR-BBS is not for you. I WILL respond, via the WR-BBS Headquarters BBS message system, to all support requests. I will not honor messages requesting me to call you (even if you ask me to call collect). Except under the most exceptional circumstances, I will not honor requests to log onto your board to examine problems. I will also not entertain any support calls to my residence telephone number. This policy ensures that support, via the WR-BBS Headquarters BBS, is available to all users on an equitable basis. Some SysOps prefer the "warm body" approach to support situations. Unfortunately, that level of support is not available for WR-BBS. At the risk of sounding negative in this paragraph, I have detailed the support policy here to make sure that there are no misunderstandings. When calling the WR-BBS Headquarters BBS for "generic" support or suggestions, you may also wish to peruse the message system for messages from (and responses to) other SysOps who may have the same question(s). There is no charge for support. Registered WR-BBS SysOps will receive support at no charge as long as they have a current version of WR-BBS installed, or until WR-BBS is discontinued. SysOps who have not yet registered their copy of WR-BBS will also receive support, but support for evaluation copies is discontinued thirty days after the first support request. Thus, each evaluation copy receives free support for at least 30 days. I am currently examining the feasibility of expanding support through facsimile and voice messaging. Such extended support may be available in the future, but is not guaranteed. If you prefer to write for support, the address is: WR-BBS Support P.O. Box 8024 Kirkland, WA 98034-0024 As with any complex software, bugs will be discovered, and fixes implemented for WR-BBS. Maintenance releases will be made available periodically, and can be downloaded (no charge) from the WR-BBS Headquarters BBS. A typical maintenance release contains fixes for minor bugs, and possibly some new minor feature enhancements. If a serious bug is discovered, a "patch" may be created to resolve the problem until the next maintenance release is published. Patches can be downloaded (no charge) from the WR-BBS Headquarters BBS. When major operational changes and feature additions are made to WR-BBS, this is referred to as an upgrade. Upgrades can be downloaded from the WR- BBS Headquarters BBS. There may be a nominal charge for upgrades. An example of a major operation change would be multi-node operation. HOW WR-BBS VERSION NUMBERS WORK All WR-BBS version numbers are expressed as a numeric character followed by a decimal point, followed by two numeric characters, and possibly followed by a letter (from A to Z). 1.00A <-- Update letter | || | || Major version number || || Intermediate version number| | Minor version number The major version number is changed only when an upgrade is released. It represents a significant change in the software from one number to the next. The intermediate version number is incremented when significant changes have been made to the software, but operational characteristics are not substantially changed (not an upgrade). The minor version number is incremented each time a maintenance release is published. The update letter (which may not appear at all) is added or incremented each time a patch is applied to correct a problem between regular maintenance releases. =========================================================================== SECTION 2 IMPORTANT WARRANTY DISCLAIMER - PLEASE READ =========================================================================== This section describes the risk that you or your company takes in using or implementing WR-BBS. In plain English, you are responsible for all damages that WR-BBS may cause if you use it on your system, whether or not the damages are due to a defect in the program. Rather than hide this disclaimer in small type at the end of the documentation, I am putting it up front, and urge you to read it carefully before proceeding. If you feel this is unfair, or you are in any way uncomfortable with the fact that there is no warranty of any kind on the WR-BBS program, please delete the WR-BBS files now. WARRANTY DISCLAIMER IMPORTANT - EVERYONE READ CAREFULLY YOU ARE AT SOLE RISK The following disclaimer of warranty applies to EVERY copy of WR-BBS, whether registered or not, unless specifically indicated otherwise. Please read it carefully. In this and the following paragraphs, "YOU" refers to you, the person or entity who uses (or attempts to use) the WR-BBS SOFTWARE; "AUTHOR" refers to Wilson A. Rogers, or any lawful successor to Wilson A. Rogers, or any lawful owner of the WR-BBS source code, whose ownership of that source code has been authorized in writing by Wilson A. Rogers; and "WR-BBS SOFTWARE" means the executable program file(s), overlays, and proprietary files associated with the single-node WR-BBS Bulletin Board System. WR-BBS SOFTWARE is supplied on an "AS IS" basis. Subject to any contrary provisions of applicable state law, the AUTHOR disclaims any and all implied warranties, including warranties of merchantability and/or fitness for a particular purpose. Except for suggestions to the contrary that may appear in the official documentation that accompanies the WR-BBS SOFTWARE, the AUTHOR does not purport that the WR-BBS SOFTWARE is fit for any purpose whatsoever, nor does the AUTHOR make any claim, implied or otherwise, as to the merchantability of the WR-BBS SOFTWARE. The AUTHOR disclaims any and all responsibility for any damages resulting from the use or attempted use of the WR- BBS SOFTWARE, including, but not limited to consequential damages, indirect damages, coincidental damages, loss of revenue, wages, or income, loss of goodwill, loss of data and/or files, system downtime, and "special damages". YOU assume all risk in attempting to use, or using the WR- BBS SOFTWARE. YOU must independently determine whether the WR-BBS SOFTWARE is suitable for your intended use, and whether or not the WR-BBS SOFTWARE will cause damage to YOU, prior to any use or attempted use of the WR-BBS SOFTWARE. If you cannot make this determination, do not use (or attempt to use) the WR-BBS SOFTWARE. The AUTHOR does not authorize any person or entity to make that determination for you. You must make this determination prior to registering the WR-BBS SOFTWARE with the AUTHOR. If, for any reason, you determine that the WR-BBS SOFTWARE is not suitable for your use within thirty (30) days after registering the WR-BBS SOFTWARE, the AUTHOR, upon written application from YOU, will refund any and all license fees paid by YOU to the AUTHOR. Should this happen, YOU must immediately and permanently discontinue any use or attempted use of the WR-BBS SOFTWARE. Such refund is the sole remedy for any failure of the WR-BBS SOFTWARE. In the event that the WR-BBS SOFTWARE, after proper registration, fails to perform substantially as described in the official WR-BBS documentation, the AUTHOR will, upon written application from YOU, refund any and all license fees previously paid by YOU to the AUTHOR. Such refund is the sole remedy for any failure of the WR-BBS SOFTWARE. Should this happen, YOU must immediately and permanently discontinue any use or attempted use of the WR-BBS SOFTWARE. Support for WR-BBS SOFTWARE is available by modem, through the WR-BBS Headquarters BBS (only). There is no charge for support to registered licensees who have a current version of the WR-BBS SOFTWARE. The AUTHOR will not be responsible for any toll, message unit, or communications charges YOU incur while accessing the WR-BBS Headquarters BBS, or for time expended by YOU in obtaining support. If any provision of this warranty disclaimer is determined, by a court or government agency, to be unlawful, void, or for any reason unenforceable, it shall be deemed separable from, and in no way shall affect the validity of the remaining provisions of this warranty disclaimer. The AUTHOR reserves the right to discontinue development, production, and support of the WR-BBS SOFTWARE at any time. If such discontinuance occurs with thirty (30) days of YOU executing a valid license application, the AUTHOR will, upon written application from YOU, refund any and all license fees paid by YOU to the AUTHOR. If you apply for such a refund, YOU must immediately and permanently discontinue any use or attempted use of the WR-BBS SOFTWARE. Such refund is your sole remedy in the event the WR-BBS SOFTWARE is discontinued by the AUTHOR within thirty (30) days of registration by YOU. =========================================================================== SECTION 3 WR-BBS LICENSE AGREEMENT =========================================================================== Like most software, WR-BBS is not sold. It is licensed, to persons and/or entities who agree to terms of the license. No person or entity has the right to sell WR-BBS software to you, as it is not for sale under any circumstances. If you agree to the terms of the license agreement (which follows), and you submit the proper license fee along with a properly completed registration form, you will receive a license to use the then current major level of WR-BBS software for a period not exceeding fifty (50) years. In the following license agreement, "YOU" means you, the registered licensee who has submitted the proper license fee along with a properly executed license application; and "AUTHOR" means Wilson A. Rogers, or any lawful successor to Wilson A. Rogers, or any lawful owner of the WR-BBS source code, whose ownership of that source code has been authorized in writing by Wilson A. Rogers; and "WR-BBS SOFTWARE" means the executable program file(s), overlays, and proprietary files associated with the single-node WR-BBS Bulletin Board System. YOU agree to use the WR-BBS SOFTWARE on only one computer at one time, and to prevent the use of the registered copy of the WR-BBS SOFTWARE from being used on more than one computer simultaneously. YOU may make as many backup copies of the WR-BBS SOFTWARE as reasonably necessary to allow recovery from system failure. YOU may distribute un-registered copies of WR-BBS freely and without obligation to the AUTHOR, other than to hold the AUTHOR harmless from any damages that may be incurred from such distribution. YOU agree to keep the executable, overlay, and other proprietary files of the WR-BBS SOFTWARE in their original, unaltered format. YOU also agree not to modify, reverse-engineer, or decompile the WR-BBS SOFTWARE at any time during, and subsequent to, the termination of this license. YOU may terminate this agreement, without notice to the AUTHOR, at any time prior to its expiry. The AUTHOR may terminate this agreement at any time, without notice to YOU. YOU agree to destroy all copies of the WR-BBS SOFTWARE when this agreement is terminated for any reason. If this agreement is terminated by the AUTHOR within thirty (30) days of the license being granted, the AUTHOR will refund to YOU all monies paid to the AUTHOR for the license. This will be your sole remedy in this situation. YOU agree and understand that the WR-BBS SOFTWARE is provided on an "AS-IS" basis, and subject to the warranty disclaimer appearing in section two. YOU will independently determine whether or not the WR-BBS SOFTWARE meets your needs and whether or not the WR-BBS SOFTWARE will damage your system or cause other loss to YOU before YOU use or attempt to use the WR-BBS SOFTWARE. YOU agree that if YOU can not adequately make such a determination, YOU will not apply for a license to use, nor will YOU use, or attempt to use the WR-BBS SOFTWARE. =========================================================================== SECTION 4 INTRODUCTION TO WR-BBS =========================================================================== WR-BBS is designed to operate on an IBM PC <tm> or compatible micro- computer. It operates as a single-port system, but its database foundation was designed to allow multi-port operation as a potential future development. WR-BBS utilizes the W-TREE Database Manager to rapidly locate and access database records, minimizing the "dead screen" time that would otherwise occur when a database search occurs. A class-of-service (COS) section in the system configuration allows up to 26 different permission levels to be assigned to callers. The COS settings can be flexibly applied to allow or deny very specific access for each group of users. (COS is synonymous with "access level" in other BBS products). Some specifications: DESIGN PRACTICAL MAXIMUM MAXIMUM ------- --------- User accounts 2,147,483,648 1,000 File descriptions 2,147,483,648 3,500 Messages on file 65,535 2,000 File areas 26 26 Events scheduled 16 16 Access levels (classes of service) 26 26 Port speed (baud) UART dependent 115,200 SYSTEM REQUIREMENTS WR-BBS should install and run on any IBM PC <tm> or 100% compatible micro-computer, including most DOS based systems using 8086, 8088, V20 and 80X86 processors. WR-BBS has been tested with DR-DOS 5, DR-DOS 6.0, MS-DOS 3.3, MS- DOS 4.01, MS-DOS 5.0, PC-DOS 5.0 and in a DOS window of OS/2 2.0. Any level of DR-DOS, MS-DOS, or PC-DOS higher than 2.01 should be sufficient, but DOS 3.3 or higher is recommended. WR-BBS has been tested under DESQview <tm> 2.3, DESQview <tm> 2.4, Microsoft Windows <tm> 3.0, and Microsoft Windows <tm> 3.1, as well as WR- DOS 6.5. WR-BBS will display in color on a color monitor (CGA, MCGA, EGA, VGA, SVGA), but a color monitor is not required. WR-BBS does not use bit-mapped graphics, and is compatible with all display types found on DOS computers. Additional graphics memory pages are not required for use under a multi-tasker. ANSI color screens can be configured for display to remote callers, whether or not a color monitor is used at the local console. WR-BBS does NOT require ANSI.SYS to be loaded in order to display ANSI graphics, as WR-BBS contains a built-in ANSI driver. WR-BBS requires approximately 230 KB of memory during run time. During DOS shells, WR-BBS swaps almost 95% of its image to EMS or disk (configurable), leaving only about 13 KB residing in memory. WR-BBS can be configured to swap its image when calling external protocols and "door" programs, allowing generous memory for the called program. =========================================================================== SECTION 5 THE HOME PATH =========================================================================== Setting the HOME PATH environment variable is one of the easiest aspects of configuring your new WR-BBS system. It is also the most important configuration item. If you read nothing else in this document, please read this section. Throughout this document, you will see mention of the "home path". The home path refers the actual DOS path where WR-BBS can find its program, overlay, and data files. WR-BBS checks the DOS environment for a variable which tells it the location of these files. It is one of the easiest configuration items relative to WR-BBS, but is also the most important. Prior to installing, initializing or starting WR-BBS, the DOS environment variable named "WR-BBS" must be set to the home path. If this is not done, WR-BBS will not start. This is done by issuing the SET command to DOS, as in the following example: SET WR-BBS=[path] Where [path] is the actual path to WR-BBS's files. Unless you have a compelling reason for doing otherwise, it is recommended that you put WR- BBS's files in a sub-directory named WR-BBS, immediately off the root directory of your boot drive. In this case, the home directory would be named C:\WR-BBS, and the SET command to set the home path would look like this: SET WR-BBS=C:\WR-BBS The trailing backslash on the home path is not expected (but does no damage if added). Thus, the command: SET WR-BBS=C:\WR-BBS and SET WR-BBS=C:\WR-BBS\ trailing backslash ^ are identical for purposes of WR-BBS determining the home path. Note that no matter what you use for the home path, when you issue the home path SET command to DOS, the following important syntax rules apply: - There is no space on either side of the equal sign. - The first character after the equal sign must be a valid drive letter. - The command can be issued in upper or lower case. - The portion of the SET after the equal sign must be a valid DOS sub- directory designation. - The entire pathname cannot exceed 64 characters The following home path SET statements are NOT valid: SET WR-BBS=\WR-BBS ^(no drive letter specified) SET WR-BBS= C:\WR-BBS ^(no space allowed on either side of = sign) SET WR-BBS=C:BBSFILE ^(does not point to a directory) While the following home path SET statements are valid: SET WR-BBS=C:\BBSFILES\BIN ^(can point to any valid DOS directory) set WR-BBS=c:\WR-BBS ^(upper/lower case doesn't matter) It is STRONGLY recommended that you insert the SET WR-BBS command in your AUTOEXEC.BAT file. Then, the DOS environment variable for the home path will be properly set each time your computer is booted, and you will never have to worry about it again. To do this, use an ASCII file editor, and edit the file AUTOEXEC.BAT, inserting the appropriate SET command as one of the first few lines in that file. Then save the file as a standard ASCII file, and reboot your system to make it take effect. To test the DOS environment (to make sure that the SET command has taken effect), type just the three-letter word SET at the DOS command line. DOS will then print out several lines, one for each environment variable. One of the lines should read WR-BBS=[path], where path is your actual home path. If you do not get this result, then an error was made when SETting the environment, or there is insufficient environment space available (which can be easily remedied - see section 14). NOTE: Do NOT include the WR-BBS home path in your DOS PATH or APPEND statements. If you ever move your WR-BBS application to another directory (or another system), you will need to make sure that the home path is properly defined before restarting WR-BBS. Some poorly designed programs will butcher your AUTOEXEC.BAT and CONFIG.SYS when they install themselves, so that they can put their own special commands in. The worst of these will delete the changes described above (and other vital lines in AUTOEXEC.BAT and CONFIG.SYS). If you install any applications after installing WR-BBS, you are well advised to first make backup copies of your AUTOEXEC.BAT and CONFIG.SYS files. WR-BBS never modifies AUTOEXEC.BAT or CONFIG.SYS, or any other system file. RECOMMENDATION: You should put the appropriate SET statement in your AUTOEXEC.BAT. This will prevent mysterious problems from surfacing later, such as WR-BBS refusing to restart after a power failure. If the SET statement for WR-BBS is not done automatically each time the system starts, WR-BBS will be unable to restart without human intervention. Naturally, this will happen when you are 3,000 miles away from your system attending the Murphy's Law seminar, and your WR-BBS system will not answer calls until you get back. You can prevent this from happening by inserting the SET statement for the WR-BBS home path in your AUTOEXEC.BAT file before you do anything else. Do it once and forget it. Do it now. =========================================================================== SECTION 6 INSTALLING WR-BBS FILES =========================================================================== First you must choose a directory for the WR-BBS files to reside in. This is the "home" directory as discussed in the preceding section. The directory "\WR-BBS" off the root directory of your boot drive is recommended, but any valid DOS directory can be used. Keep in mind that no files other than those related to WR-BBS should exist in the WR-BBS home directory, so do not use an existing directory that belongs to another application. The use of the root directory as the WR-BBS home path directory is possible, but strongly recommended against. Next, you need to create the home path directory if it does not already exist. Do this by issuing the DOS command: MKDIR [dirname] Where [dirname] is the full directory name of the WR-BBS home path sub- directory. Next, make the home path directory the current directory by issuing this command at the DOS command line: CHDIR [dirname] Where [dirname] is the WR-BBS home path directory. If you receive an error message from DOS, check your typing and try again, or refer to your DOS manual. Now that the home path directory is current, copy all of the files from the WR-BBS archive (or installation diskette) into the homepath directory by issuing one of the following commands: XCOPY [SourcePath]\*.* /V or COPY [SourcePath]\*.* /V Where [SourcePath] is the actual DOS path to the WR-BBS files. For example, if you de-compressed the WR-BBS files into a directory named C:\MODEM\DOWNLOAD, the proper syntax would be XCOPY C:\MODEM\DOWNLOAD\*.* /V or COPY C:\MODEM\DOWNLOAD\*.* /V Alternatively, if you are using a distribution diskette obtained from the author, you would type: XCOPY A:\*.* /V or COPY A:\*.* /V provided that the diskette was in the A: drive. The following files are provided with WR-BBS, and should be copied into the WR-BBS home path directory. They must always reside in the home path for correct operation of WR-BBS. With the exception of the executable, overlay, and database files, all WR-BBS files are in character format and can be readily edited as required: MIDNIGHT.BAT This is a sample batch file, modify to suit your application, or delete if you wish. If MIDNIGHT.BAT is present, WR-BBS will execute it immediately after DOS reports that the date has changed (which is at 00:00 hours). See section 15 for more information on MIDNIGHT.BAT. NOACCESS.TXT This file is checked whenever a new user logs on for the first time. If that caller's name is found in NOACCESS.TXT, they are not allowed to continue, and are forced off. This prevents callers from using cute names like EATME SYSOP or worse. The file by default contains a list of possible bad names. It includes some bad words, so if you are sensitive to such language, don't read the file. You can add or remove "undesirable" names to this file as needed, with one name per line. When NOACCESS.TXT is scanned, each line is compared to the caller's first AND last name. Thus, if "CAPTAIN" appears in NOACCESS.TXT, a caller who claims to be "CAPTAIN KIRK" would be denied access, and so would "BOB CAPTAIN". Thus, you need to be careful to keep potential "valid" names out of NOACCESS.TXT. OSACCESS.BAT This is another sample batch file, which you can edit if desired. It controls access to the operating system when the SysOp requests a shell to DOS. WR.BAT This is the main batch file that controls WR-BBS operation. You should run WR-BBS by typing "WR" and pressing <ENTER>, rather than running WRBBS.EXE directly. This is explained in more detail in section 8. WRBBS.EXE This is the program file for WR-BBS. Never edit this file. WRBBS.OVR This is the overlay file for WR-BBS. To conserve memory, WR-BBS loads overlays into memory as needed and unloads them when no longer required. Never edit this file. WRCONFIG.SYS This is the configuration file for WR-BBS. Almost all configuration and customization is done through this configuration file. You will need to edit this file to set up your WR-BBS system. See section 10 for details on configuring WR-BBS with WRCONFIG.SYS. WRQUOTES.TXT This is an optional file. It is included with the WR-BBS distribution package as a sample file. When caller's log on, a "quotation" from this file will be selected at random and displayed to the caller. You can delete this file if you don't want the "quote of the day" feature. Likewise, you can edit it to add your own quotes. Each quote must be no longer than one line in length. WR_AFTER.BAT This file is optional. A sample file is included with the original WR-BBS distribution package. If WR-AFTER.BAT is found in the home path, it will be executed after each log-off. You could use this batch file to update statistics-sensitive bulletins, or do some other kind of post-call cleanup. If you don't have a use for this feature, delete WR-AFTER.BAT. WFILEXFR.BAT This is a sample batch file, which you can modify to meet the needs of your board. It controls all file transfer activity (downloads and uploads) and external protocol programs. =========================================================================== SECTION 7 SCREEN FILES =========================================================================== For maximum flexibility, WR-BBS has very few "hard coded" display screens. Almost all of the screens that are seen by your callers are external text files which you can edit to suit your board's individual needs. Sample screen files are provided with the WR-BBS distribution package. Many of these screen files can be used "as is" immediately, without editing. Some of the screen files, however, should be edited to include your BBS name and/or other installation-specific information. Each screen that can be displayed to a caller is supported by TWO screen files. One of the screen files has an extension of .ASC (which stands for ASCII) and the other corresponding screen file has an extension of .ANS (which stands for ANSI). ANSI screens are displayed to callers who have ANSI color enabled. ASCII screens are sent to non-ANSI callers. With very few exceptions, ASCII screens on WR-BBS have no color data in them. ANSI screens, on the other hand, typically contain ANSI escape sequences which allow for sophisticated color and cursor-movement control. Creating ASCII screen files is relatively easy. Use any editor that can save files in true ASCII. DOS's EDLIN and EDIT programs do this automatically. Most word processors can create, edit and save "true ASCII" files, but require commands to tell the word processing program not to put formatting symbols in the finished file. Creating ANSI screens is a little more involved. Although it could be done with a basic text editor, this would be a time-consuming and excruciating process. The use of an ANSI-specific screen file editor is strongly recommended. A popular program called TheDraw (by TheSoft) is an ANSI screen editor that is very easy to use. You can download an evaluation copy of TheDraw from the WR-BBS Headquarters BBS and many other BBS's throughout the world. Remember to register your copy of TheDraw with the TheSoft people. When using TheDraw (or another ANSI editor) to create WR-BBS screens, observe the following: - Most screen files should have no more than 21 lines of display information. If you make the display file longer than that, part of the display screen will scroll off the remote caller's screen. - When saving the file, select "NONE" for line length. You want the editor to place a "real" carriage return and line feed after each "real" line. With ANSI escape sequences imbedded, each "line" of text can be a couple of hundred characters long, but should end with a conventional CR/LF sequence. Otherwise, the stream of characters will be transmitted as one gigantic line of text. Most modern communications programs that callers might use to call your board can handle such a long string. If a caller is using a communications package that does not "wrap" lines, sending them a mega-string could make their program misbehave. Using "NONE" for line length assures that each time a new physical line is to be drawn, a carriage return and line feed will precede it. - It is possible to make ultra-sophisticated "animated" screens, but you should avoid animation for the menus. The time it takes to transmit animated screens may be perceived by your callers as "wasted" time. Bulletins and welcome files may benefit from animation, however. - Select "0" for display speed when saving files with TheDraw. You want maximum throughput, since each character is being transmitted via the modem to your caller. Most of WR-BBS's screen files MUST be present for proper operation. If you do not use the originally supplied files, use your own versions of the screen files. Unless indicated as being optional, all screen files must be present in either the home path, or the path you have defined (in WRCONFIG.SYS) for display files (see "SCREENDIR=" in section 10). For each screen file, one with an extension of .ASC and one with and extension of .ANS must be present. If a screen file is missing, an error message is displayed to the caller, and an error is logged in the activity file. The file names for screen files used by WR-BBS are: BADNAME.ASC and BADNAME.ANS: Sent to callers whose name appears in the file NOACCESS.TXT. The caller is then disconnected. BULL????.ASC and BULL????.ANS: These are the actual bulletin screens. WR-BBS supports up to 9,999 bulletins, with file names BULL0001.ASC/ANS through BULL9999.ASC/ANS. The caller selects bulletins by typing in the corresponding number. For example, if the caller enters 34, bulletin file BULL0034.ASC/ANS will be displayed. BULLMENU.ASC and BULLMENU.ANS: Menu screen which lists available bulletins. CALLVIEW.ASC and CALLVIEW.ANS: This screen file describes the options available to a caller when the "(W)ho called recently" command is selected from the main menu. CHATFAIL.ASC and CHATFAIL.ANS: Displayed to caller when the SysOp does not answer a chat page request. DOORMENU.ASC and DOORMENU.ANS: Screen file for "doors" menu. WR-BBS supports up to 26 doors. See also section 13 for detailed information on doors. If you configure any doors, this screen is displayed to the caller when they choose (D)oors from the main menu. This screen describes the doors available, which are identified by letters from "A" to "Z". The caller, upon seeing the selection listed in this screen, then selects the desired door. FILELIST.ASC and FILELIST.ANS: When a caller, in the Files Library, selects "(L)ist" to see a listing of available files, this screen file is transmitted. It explains the choices available to the caller for listing files. FILESLIB.ASC and FILESLIB.ANS: Menu screen for file library (the "files" menu). Displays caller's options for file area, such as downloading, listing, uploading, etc. GOODBYE.ASC and GOODBYE.ASC: Screen file which is sent to callers after they request a logoff. This file should be less than 1/2 of a screen in length. This ensures that the caller can view the whole text of the screen file, even if their communications program does some line feeds after the disconnect is detected. Also, since some callers will drop carrier shortly after selecting (G)oodbye and confirming their logoff, having a short "goodbye" screen eliminates these callers from being logged as "dropped carrier". GREETING.ASC and GREETING.ANS: Screen sent to callers during logon, immediately after they answer the question "Do you wish to have ANSI color?". This screen should be only a few lines long, and should contain the BBS name. HELPFILE.ASC and HELPFILE.ANS: This screen is displayed if a caller selects (H)elp from the Files Library menu. Its context is specific to the Files Library functions available in that menu. HELPMAIN.ASC and HELPMAIN.ANS: This screen is transmitted in response to a user selecting (H)elp from the Main Menu. It describes the functions available from the Main Menu. HELPMSGS.ASC and HELPMSGS.ANS: If a caller requests (H)elp while viewing the Message System Menu, this screen is displayed. It contains instructions on how to use the various features of the WR-BBS message system. HOW2CHAT.ASC and HOW2CHAT.ANS: If a caller presses (S)ignal for chat from the main menu, the SysOp is alerted by a series of beeps, and is told to press ENTER to start the chat with the caller. When the SysOp presses ENTER, this screen is sent, and the chat begins. This screen contains helpful information about how to chat without "stepping" on each other. MAINMENU.ASC and MAINMENU.ANS: This screen file comprises the Main Menu. It is the primary screen file seen by callers when on line. MESSAGES.ASC and MESSAGES.ANS: This is the screen file for the Message System menu. It lists the choices available to a caller after the caller selects (M)essage system from the Main Menu. NEWS.ASC and NEWS.ANS: Newsletter file. Displayed to callers who press (N)ewsletter from main menu. NEWUSER.ASC and NEWUSER.ANS: Screen sent to new users, before the new user induction. Use this to explain your board's scope, policies, or other information that might not be apparent to a new user, as well as a first welcome for new callers. PASSWORD.ASC and PASSWORD.ANS: Screen explaining how to select a password. Displayed to new users during logon, and to established users who want to change their password. SEARCH.ASC and SEARCH.ANS: Screen which explains to callers how to use the various message searching options. SENDMSG.ASC and SENDMSG.ANS: Screen which explains how to send a message, and the addressing options available. SHOWANSI.ASC: Screen which demonstrates ANSI graphics to assist callers in deciding whether or not they want ANSI enabled. Notice that there is no .ANS counterpart for this display file. This is because the ANSI screen (for demonstration to user) is sent to all callers, regardless of current ANSI choice. Otherwise, non-ANSI callers could never see the ANSI demonstration. This is the only WR-BBS screen file with ANSI colors in a .ASC file. SYSOP.ASC and SYSOP.ANS: This is the screen file for the SysOp menu. The SysOp menu is accessed (only by the SysOp) by selecting "Z" from the Main Menu. It lists the administration options available to the SysOp while on line. THANKYOU.ASC and THANKYOU.ANS: This screen is sent after each successful upload. The text thanks the caller for taking the time to upload to the board. UPLDFAIL.ASC and UPLDFAIL.ANS: This screen is displayed if a caller attempts an upload, but for some reason the file is not received (or is incomplete, or aborted by the caller). It describes the problem so that the caller understands the upload was not successful. UPLOAD.ASC and UPLOAD.ANS: After a caller selects (U)pload from the Files Library menu, this screen is displayed. It can be used to give instructions on what types of files are acceptable, or to remind the caller that their time will be compensated, etc. WELCOME?.ASC and WELCOME?.ANS: This optional screen file is sent to callers after they have completed their logon (name, password, and statistics check). There can be up to 26 WELCOME?. files, one for each class of service (COS). The letter following "WELCOME" in the filename designates which COS the screen is sent to. For example, WELCOMEA.ASC and WELCOMEA.ANS will be shown to callers with a class- of-service of "A", while WELCOMEB.ASC and WELCOMEB.ANS would be shown to callers with a class-of-service of "B", and so on. See section 11 for a detailed description of the class-of-service configuration. If there is no welcome file for a particular COS, callers in that COS do not see any welcome file. You do NOT need to have a statement in your CONFIG.SYS to load an ANSI driver for WR-BBS. WR-BBS has its own built-in ANSI interpreter. =========================================================================== SECTION 8 WR.BAT =========================================================================== It is possible to start WR-BBS by simply typing WRBBS at the command line, from the home path directory. This is NOT recommended, however. For maximum flexibility and control, the use of a batch file to control WR-BBS is recommended. A sample batch file, WR.BAT, is included with the original distribution of WR-BBS files. You can use this file without modification, or edit it for your site-specific requirements. Using WR.BAT provides the following advantages: - If WR-BBS operation is disrupted due to an error in the program, the batch file will detect the DOS errorlevel, and automatically restart WR-BBS, without human intervention. (If a batch file is not used, the system would just return to the command line, and not answer any calls until a human restarted WR-BBS). - If you schedule events which require termination (and restart) of WR-BBS, the BBS will not restart properly unless WR-BBS was originally started under the control of a batch file such as WR.BAT. A freeware utility file, WDELAY.EXE, is included with your WR-BBS distribution package. This utility is called by WR.BAT when it starts to load WR-BBS. This utility simply affords the local operator an opportunity to cancel the batch file by pressing ESC within the designated time. Press <ENTER> when prompted to jump past WDELAY. If no key is pressed, WDELAY will start WR-BBS after the delay, which allows unattended restarts. Unlike WR-BBS, the WDELAY utility requires no registration, and can be used indefinitely with no obligation. WR.BAT is based on the fact that WR-BBS sets a different DOS ERRORLEVEL depending on the reason it terminated. Based on that errorlevel, WR.BAT branches to the appropriate label in the batch file, and either re-starts WR-BBS, runs a "terminate event", or simply ends. (See section 17 for information on terminate events). The possible errorlevels returned by WR- BBS are: 0 Normal termination (requested by local console) 1 to 17 Runtime error - operating system or file access error 84 to 99 Scheduled termination for configured external event 100 to 106 Runtime error - file or I/O error 150 to 162 Runtime error - critical file access error 200 to 214 Runtime error - critical program or logic error 254 to 255 Runtime error - internal WR-BBS debug halt WR-BBS does its own error handling, and is able to recover automatically (without terminating) from most minor runtime errors. Any fatal errors are captured by WR-BBS's critical error handler, and logged in the activity log (if possible) prior to WR-BBS terminating with the appropriate errorlevel. A screen is also displayed by WR-BBS when a critical error occurs, showing the error code and process ID. If a caller is connected when a critical error occurs, a message is transmitted to the caller, explaining that the system is going off-line briefly, and requesting that they call back. Critical errors are rare, and are usually due to external influences, such as corrupted memory, or database files being deleted or damaged. But, with WR-BBS's built-in critical error handler, you should never experience an error that simply crashes the program with no clue as to what happened. =========================================================================== SECTION 9 ... THE FIRST TIME =========================================================================== Before you run WR-BBS for the first time, you must create an initialized set of database files for WR-BBS to work with. This is an extremely easy process, and takes less than a minute. Initialized (empty) database files are not provided with the WR-BBS distribution package, since WR-BBS is capable of creating an initialized database on request. To create the initialized database, do the following: 1. Change directories to make the WR-BBS home path the current directory. 2. At the command line, type WRBBS /INIT and then press <ENTER>. 3. Answer the confirmation by typing OKAY and pressing <ENTER>. WR-BBS will then create the following files: WRBBSUSR.DAT This is the database file where user (caller) information is stored. WRBBSMSG.DAT This file contains the message system database (but not actual messages), with pointers to the files that contain the actual message text. WRBBSLIB.DAT The Files Library database is stored in this file. All file descriptions and attributes are written to this file. WRBBSPEG.DAT This file stores statistical (peg count) data about your WR-BBS system, including the number of calls answered, calls answered today, new messages, etc. WRBBSDBF.DAT This file is used to record the status of the WR-BBS database. The W-TREE database manager uses this file to determine if the system was shut down in an orderly manner. If it was not, the indices are rebuilt automatically the next time WR-BBS is restarted. After you have created the initialized database, WR-BBS is ready to configure. IMPORTANT: If you have a working database, and request that the WR-BBS database be initialized, all data in the database will be PERMANENTLY LOST. Do not request initialization unless you are installing WR-BBS for the first time, or you wish to start over again with an empty database. After creating an initialized database, WR-BBS automatically creates the user index file, WRBBSUSR.IDX, and a new activity log file, WRBBSLOG.TXT, when WR-BBS is started up. With an initialized database, your WR-BBS system will have exactly zero users on file, no files or messages in the database, and no statistics. After you finish configuring WR-BBS, start WR-BBS by typing WR, wait for the startup process to complete, and then log on locally by pressing ALT-L from the main screen (or the screen saver screen). The first person to log onto your new WR-BBS system should be the SysOp whose name you have configured in WRCONFIG.SYS (see section 10). =========================================================================== SECTION 10 CONFIGURING WR-BBS =========================================================================== Almost all of the configuration required to make WR-BBS operation is done by editing the text file WRCONFIG.SYS. This file must exist in the home path directory. When you edit this file, use an ASCII-capable editor or a word processor that can save documents in straight ASCII format. If your word processor inserts proprietary control codes, WR-BBS will try to interpret these codes as configuration instructions, and this would cause unpredictable and undesirable results. The copy of WRCONFIG.SYS that came with your new WR-BBS distribution has SAMPLE values for many of the configuration items. You will need to change some of these to match your implementation and your specific system. WR-BBS will attempt to interpret any line that appears in WRCONFIG.SYS, unless that line starts with a single apostrophe (') or the keyword "REM", which is short for remark. Any lines that start with one of those special identifiers is ignored by WR-BBS. This allows you to insert comments and notes as you make changes. It also allows you to remove a complex configuration entry from WR-BBS's view by prefixing a REM in front of the line. This is helpful if you want to experiment with different settings, without worrying about losing complex configuration strings that you may have entered. Each of the entries that can be included in WRCONFIG.SYS is listed in this section. Some of the entries are not required unless you are implementing special optional features. For example, if you do not wish to have "doors" on your WR-BBS system, you can omit (or remark out) all entries in WRCONFIG.SYS that start with "DOOR=". Some entries in WRCONFIG.SYS are required, however, for proper operation. These include the BBSNAME, SYSOP, and other site-specific details. --------------------------------------------------------------------------- ANSWERCOMMAND= DEFAULT=ATA This entry allows you to configure WR-BBS for the command that your modem requires to answer a call. 99% of all modems use the command "ATA". If your modem uses "ATA" for an answer command, you can omit this line, as the default is also "ATA". If your modem requires some other command to answer a ringing call, you must insert the appropriate string in this entry for proper operation. IMPORTANT: This entry is for the command your modem requires to make the modem go off-hook under software (WR-BBS) control in response to ringing. This is not the same as the "auto answer" command. Do NOT insert an automatic answer command string in this entry (such as ATS0=1), or WR-BBS will not answer calls properly. This applies regardless of the RINGDETECT= entry you may be using. --------------------------------------------------------------------------- BADDOOR= DEFAULT=N If you do not plan to have "doors" or you do not have an error-correcting modem, then this entry does not apply, and you can skip it, using the default setting of "N". This configuration item is to correct a deficiency in some door programs that do not properly read the DOOR.SYS file. These incorrectly-written door programs read the caller's connect speed from DOOR.SYS rather than the DTE speed, and then they (incorrectly) adjust their own baud rate to the caller's speed, which is wrong. The caller gets screenfuls of garbage, and has to drop carrier, since they cannot issue a quit command. This phenomena only occurs if you have one of these BAD DOOR programs, and are using an error-correcting modem with the DTE locked at a speed which is different than the caller's. If you make BADDOOR=Y, then WR-BBS fools the bad door by inserting the DTE speed in DOOR.SYS where the caller's speed would normally appear. Setting BADDOOR=Y is a workaround to compensate for sloppy programming that was done by the door program author. Complain to the author of the door program to get the problem fixed. This setting affects ALL doors that are configured on WR-BBS. If you have a bad door among several "good" doors, you really have only three choices: 1. Compromise all doors by setting BADDOOR=Y. Some doors (which WERE written properly) may then malfunction, because DOOR.SYS will then be wrong. 2. Stop using the bad software (the poorly written door program). 3. Modify a batch file and/or use a door manager to fool the bad door into working properly. --------------------------------------------------------------------------- BBSNAME= NO DEFAULT Insert your board's name. Up to 48 characters can be used. The value assigned to BBSNAME appears at various points during a caller's session, and on the default screen while WR-BBS is waiting for calls. If you do not configure this item, WR-BBS will display "BBS NAME NOT CONFIGURED" in lieu of a BBS name. The BBSNAME entry is displayed in the appropriate places whether or not you have registered your copy of WR-BBS. --------------------------------------------------------------------------- BULLETINS= DEFAULT: 32 This must be a number from 0 to 999, indicating the number of bulletins that you expect to have available. WR-BBS will search the home path for this number of bulletin files, so this value should represent the real number of bulletins you have to avoid needless DOS file searching. Although it is possible to have, say BULLETINS=500, and only four actual bulletins, callers will have to endure a delay while WR-BBS searches for the non-existent 496 bulletins. --------------------------------------------------------------------------- BUSYLINE= DEFAULT: N This entry determines whether or not WR-BBS makes the telephone line busy when it cannot process calls. Enter Y for yes, or N for no. If your WR- BBS system has its own exclusive telephone line, you may wish to enter Y so that the line is busy during events, while recycling, during local logons, and when WR-BBS is terminated. If WR-BBS shares a phone line with something (or someone) else, you must enter N to avoid disabling the phone line needlessly for other devices or people. --------------------------------------------------------------------------- CARRIERWAIT= DEFAULT=45 This setting tells WR-BBS how long (in seconds) to wait for carrier after answering an incoming call. Valid values are 15 to 255 seconds. 45 seconds is a good setting for most installations. Carrier usually occurs within 25 seconds of a call ringing - if not, it's usually not a data call, and waiting much longer than 45 seconds will just waste time. If you have an error-correcting modem that goes through lengthy summit negotiations before reporting that carrier is present, you may have to lengthen this value to 60 or more seconds. --------------------------------------------------------------------------- CGA_STOP_SNOW= DEFAULT: N For 99% of all installations, enter N for no on this line. If your computer has an older CGA display, and you see "specks" on the screen when WR-BBS is writing to the display, then entering Y for yes here will stop the "snow", but slow down screen updates. --------------------------------------------------------------------------- CONNECT300= DEFAULT: CONNECT Enter the verbose result code that your modem sends when a 300 baud connection is established. Most modems send "CONNECT". If your modem does not support 300 baud connections, then make CONNECT300=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT1200= DEFAULT: CONNECT 1200 Enter the verbose result code that your modem sends when a 1200 baud connection is established. Most modems send "CONNECT 1200". If your modem does not support 1200 baud connections, then make CONNECT1200=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT2400= DEFAULT: CONNECT 2400 Enter the verbose result code that your modem sends when a 2400 baud connection is established. Most modems send "CONNECT 2400". If your modem does not support 2400 baud connections, then make CONNECT2400=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT4800= DEFAULT: CONNECT 4800 Enter the verbose result code that your modem sends when a 4800 baud connection is established. Most modems send "CONNECT 4800". If your modem does not support 4800 baud connections, then make CONNECT4800=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT9600= DEFAULT: CONNECT 9600 Enter the verbose result code that your modem sends when a 9600 baud connection is established. Most modems send "CONNECT 9600". If your modem does not support 9600 baud connections, then make CONNECT9600=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT12000= DEFAULT: CONNECT 12000 Enter the verbose result code that your modem sends when a 12000 baud connection is established. Most modems send "CONNECT 12000". If your modem does not support 12000 baud connections, then make CONNECT12000=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT14400= DEFAULT: CONNECT 14400 Enter the verbose result code that your modem sends when a 14400 baud connection is established. Most modems send "CONNECT 14400" or "CONNECT 144". If your modem does not support 14400 baud connections, then make CONNECT14400=IMPOSSIBLE to avoid any possibility of line noise being mis- interpreted. --------------------------------------------------------------------------- CONNECT19200= DEFAULT: CONNECT 19200 Enter the verbose result code that your modem sends when a 19200 baud connection is established. Most modems send "CONNECT 19200" or "HICONNECT" If your modem does not support 19200 baud connections, then make CONNECT19200=IMPOSSIBLE to avoid any possibility of line noise being mis- interpreted. --------------------------------------------------------------------------- CONNECT38400= DEFAULT: CONNECT 38400 Enter the verbose result code that your modem sends when a 38400 baud connection is established. Most modems send "CONNECT 38400". If your modem does not support 38400 baud connections, then make CONNECT38400=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CONNECT57600= DEFAULT: CONNECT 57600 Enter the verbose result code that your modem sends when a 57600 baud connection is established. Most modems send "CONNECT 57600". If your modem does not support 57600 baud connections, then make CONNECT57600=IMPOSSIBLE to avoid any possibility of line noise being mis-interpreted. --------------------------------------------------------------------------- CTSFLOW= DEFAULT=N This setting controls whether WR-BBS should pay attention to the CTS (Clear To Send) flow control signal from the modem. If your modem has a maximum speed of 2400 baud or less, it is unlikely that the modem will ever lower its CTS signal (which tells the computer to stop sending data). On the other hand, high-speed modems, especially error-correcting modems, need CTS control because they typically work with a fixed (locked) DTE baud rate, regardless of the caller's connect speed. If a caller is connected at 2400 baud and the DTE speed is locked at 38,400, it doesn't take long to fill the modem's buffer. The modem then drops the CTS line, signalling the computer to stop sending data for a while. When the modem's buffer empties out (as the buffered data is transmitted to the caller), the modem raises the CTS line, signalling the computer that it can again accept data. Without such a signalling means, the modem would overflow, and data would be lost. Why not just set WR-BBS to always observe CTS with CTSFLOW=Y ? There can be some drawbacks to using CTS flow control, so you will probably want to leave CTSFLOW=N unless you really need CTS flow control. The constant interrupt servicing necessary to watch CTS causes slightly reduced throughput. If your DTE is locked at a high speed (such as 14,400 or higher), this reduction in output is negligible. At slower speeds, it may be noticeable. The interrupt overhead may also make some disk caching utilities slow down, especially if they use exTENDed memory instead of exPANDed memory. --------------------------------------------------------------------------- DOOR= NO DEFAULTS See section 13 for complete details on setting up doors. --------------------------------------------------------------------------- ERRORFREE= NO DEFAULT Enter the result code that your modem sends when an error free connection is established. Most error-correcting modems send either "/MNP" or "/REL" to signify such a connection. If you do not have an error correcting modem, then make ERRORFREE=IMPOSSIBLE to avoid false error-free detection if random matching characters should appear. This string is usually a suffix to the regular connect string, such as "CONNECT 2400 /ARQ" or "CONNECT 9600 /REL". --------------------------------------------------------------------------- EVENT= N/A See section 17 for detailed instructions on configuring events. --------------------------------------------------------------------------- FILEAREA= NO DEFAULT There can be up to 26 file areas defined. Each one is identified by a unique letter (from A to Z) and a descriptive name. The file areas comprise your "library" of files available for callers to download. By having (up to 26) distinct file areas, you can group your files by type. For example, area "A" might be files that are of interest to Windows users, while area "B" contains Games, with Recipes in area "C", and so on. Having a well-thought-out file library will make your WR-BBS easy for callers to navigate, and ensure that files get the visibility you wish them to have. It is not mandatory that any file areas be defined, but callers will not be able to upload (or download) files unless at least one file area has been defined. This might be satisfactory if you want to run a "messages only" type of BBS. Otherwise, you will probably want to configure at least two file areas; One area to receive new uploads, and at least one area for callers to download files from. To define a file area, enter a line in WRCONFIG.SYS containing the following, with each item separated by a pipe (|) symbol: 1. The string FILEAREA= 2. The unique letter (A to Z) you wish to assign to that file area. 3. A descriptive name for that file area, such as "Astronomy Files", "Games for Children", or "DOS Utility Files". This descriptive name can be up to 48 characters in length. 4. The full path to that file area. This must be a valid DOS directory. This directory (only) will be searched when a file download is requested by a caller. If the specified directory does not exist, an error will occur when WR-BBS is started. 5. A string of letters (A to Z), representing the class-of-service required for a caller to access the files in that area. To allow all classes-of-service to access this are, the string would be "ABCDEFGHIJKLMNOPQRSTUVWXYZ". See section 11 for detailed information on setting up classes of service. Some examples: FILEAREA=A|Flight Simulator Utilities|C:\WR-BBS\FSUTILS|ABCDE In the above example, a file area designated as "A" references the directory C:\FSUTILS. The name that will be displayed to callers is "Flight Simulator Utilities". Callers have a class-of-service of A, B, C, D, or E can access this file area. Callers with other classes-of-service (such as "Z") will not be able to access this file area. FILEAREA=B|Games|D:\GAMES|ABCDEFGHIJKLMNOPQRSTUVWXYZ In the above example, file area "B" references the directory D:\GAMES. Any caller can access this area, as all 26 class-of-service letters have been included in the COS string. FILEAREA=C|SysOp Only!|C:\FORSYSOP|Q In the above example, file area "C" references a directory named C:\FORSYSOP. This is a private file area. In this example, the SysOp is the only caller with a class-of-service of "Q", therefore, only the SysOp can access this file area. Careful planning of your classes of service will allow you to offer a flexible file library to your callers, restricting unauthorized callers from files that they should not access. Section 11, which describes the class-of-service concept, is recommended reading for new WR-BBS SysOps. The entries that you put in WRCONFIG.SYS to configure your file areas may exceed the normal line size of your editor. The directory path can be up to 64 characters, and the descriptive name can be up to 48 characters. If your entry exceeds 79 characters, it is important that your editor keep the long entry as ONE line, with no imbedded carriage return or linefeed characters. The entire entry cannot exceed 128 characters. --------------------------------------------------------------------------- GOODBYE_DELAY= DEFAULT=1 This parameter controls how long WR-BBS waits, after sending the GOODBYE screen, before actually dropping the call (lowering DTR). If you do not have an error correcting modem, the default setting of 1 second is adequate. If you have an error correcting modem, the caller may not see the entire GOODBYE screen unless you extend the number of seconds that WR- BBS waits before it drops carrier after sending the GOODBYE screen. This is because it only takes a few milliseconds for WR-BBS to transmit the GOODBYE screen (at very high baud rates typical of error-correcting modems) but the remote caller's communications program will usually stop updating the caller's screen as soon as their modem detects that WR-BBS has ended the call. Valid values for this setting are from 1 to 9 seconds. It cannot be set to 0 seconds. --------------------------------------------------------------------------- INBUFFER= DEFAULT=2048 This is an optional entry. It determines the size of the serial I/O buffer that WR-BBS sets up in memory. 2048 is usually a good value to use. This means that WR-BBS's communications port handler will buffer up to 2048 characters until WR-BBS can process them. Usually, no more than a few characters are ever buffered for input. The buffer can be set to any whole number from 128 to 32767. The higher this number, the more memory is needed by WR-BBS (a 32767 character buffer takes 32K of additional ram). If this value is too low, a buffer over-run may occur. An over-run, at best, means that some input characters will be lost. In severe cases, WR- BBS could crash due to heap corruption. If you use a multi-tasking environment, such as DESQview, an OS/2 DOS Window, or Microsoft Windows, it is possible that WR-BBS may not get enough processor cycles to unload the buffer in a timely fashion if another process is bogging the system down. If this is likely, increase the buffer size slightly (try 8000). Unless you run multiple applications under a multi-tasker, or you have problems with buffer over-runs, its best not to change INBUFFER= from the default setting. --------------------------------------------------------------------------- INITBAUD= DEFAULT=2400 This value is the speed (baud rate) at which you modem expects to receive off-line initialization commands. For most (but not all) modems, this is the same as their maximum operating speed. When WR-BBS starts up, and after each call, initialization commands are sent to the modem. The value you define for INITBAUD= determines the speed used by WR-BBS to send those commands. For most error-correcting modems, including those that support v32, v42, MNP, and ARQ transmission, the INITBAUD= setting should be the modem's "link" speed. This is the speed at which the modem normally communicates with the computer (and vice versa). Most error-correcting modems use one speed for all computer-to-modem and modem-to-computer data transmissions, regardless of the actual connect speed. For additional information, see the entry for LOCKDTE=. --------------------------------------------------------------------------- LICENSEE= NO DEFAULT If you have registered your copy of WR-BBS, enter your registered name after the equal sign, exactly as it appears on your registration confirmation. You must also enter the special registration code in conjunction with the REGISTRATION= parameter (described later in this section. Make sure both are entered correctly. Have correct values in the LICENSEE= and REGISTRATION= lines will stop WR-BBS from displaying "EVALUATION ONLY" when callers log on and log off. Your registration name will be displayed instead. --------------------------------------------------------------------------- LOCKDTE= DEFAULT=N This is for error-correcting modems. If you do not have an error- correcting modem, set LOCKDTE=N, or omit this line from WRCONFIG.SYS. Error-correcting modems can be identified by the transmission methods that they support, typically V.32bis, V.42bis, MNP, "reliable", and ARQ. Almost all modems that work at speeds above 4800 baud are of the error-correcting type. Error-correcting modems, with few exceptions, use "locked DTE". This means that the data stream from the computer to the modem, and vice-versa, always occurs at a fixed speed (such as 14,400, 19,200, or 38,400). DTE stands for Data Terminal Equipment, which is what your computer is to the modem. This constant DTE speed is locked at the same value at all times regardless of the caller's actual connect rate. For example, if you are using an error-correcting modem, and have the DTE locked at 14,400, WR-BBS will communicate with the modem at 14,400 regardless of who is on line or at what speed. Even a 300 baud connection will result in computer-to-modem and modem-to-computer communications at 14,400 baud; the modem will automatically adjust its interface with the caller to their connected baud rate. Also, all modem commands (including initialization and recycling commands) are sent at the locked DTE speed. If you are using an error-correcting modem, consult your modem's documentation for the proper locked DTE speed to use, and set INITBAUD= to this value. Also set LOCKDTE=Y. NOTE: If LOCKDTE=Y and your modem is not an error-correcting type (or is not set up properly), callers will receive garbage unless they happen to be calling at the modem's locked DTE speed. --------------------------------------------------------------------------- LOGONALARM= DEFAULT=N Enter Y for yes if you want WR-BBS to alert you to each logon with a one second warble tone. When N is set, no tone is heard when a logon occurs. --------------------------------------------------------------------------- MAXBAUD= DEFAULT=2400 Enter the maximum speed (baud) at which your modem is capable of operating. Depending on your modem's make and model, this may be different from INITBAUD=. For error-correcting modems, enter the modem's DTE or "link" speed. --------------------------------------------------------------------------- MODEM_INIT_ONE= DEFAULT=AT &C1 &D2 S7=45 V1 X4 S0=0 and MODEM_INIT_TWO= NO DEFAULT WR-BBS supports two modem initialization strings. Each one can have up to forty (40) characters after the equal sign. Most modems cannot accept commands with more than 40 characters in the string. Some WR-BBS installations (particularly those with high-speed, highly configurable modems) may require more than forty characters to initialize the modem. An additional line, MODEM_INIT_TWO=, is recognized in WRCONFIG.SYS, and can contain up to forty additional characters of modem initialization data. Thus, WR-BBS can handle up to eighty characters for modem initialization purposes. You do not have to use both strings if your initialization data will fit into one string. If you have no data for the second initialization string, omit the MODEM_INIT_TWO= entry from WRCONFIG.SYS. The modem initialization string is sent to the modem whenever one of the following conditions occur: 1. WR-BBS is first started. 2. A call ends, and WR-BBS recycles to prepare for the next call. For proper operation, some form of initialization data must be sent to the modem in each of the two situations above. Consult your modem's documentation for the appropriate information to include in this string. If you have a Hayes <tm> modem, or a modem that recognizes the Hayes <tm> command set, the initialization string should start with "AT". The commands listed below are for example purposes, and assume the use of a Hayes <tm> modem with no error-correction (such as a SmartModem 2400 <tm>). They apply to most modems that recognize the same commands as Hayes <tm> modems, and are necessary for proper, secure operation of WR-BBS. You may need to add additional commands for your particular installation, so consider these as a bare minimum: Command Meaning ------- ------- E1 Echo commands back to computer M0 Modem's speaker off at all times Q0 Send result codes V1 Result codes are words instead of numbers X4 Detailed result codes, including connect speed &C1 Track the presence or absence of carrier detect &D2 React to loss of DTR by dropping carrier &R0 CTS follows RTS, not assumed to be on S0=0 Disable auto answer (see RINGDETECT=) S2=128 Disable escape sequence The "E1" command is necessary so that WR-BBS will its own input to the modem echoed back. If WR-BBS does not see this echo, the initialization diagnostics will not work. The "M0" command is not essential, but if you omit it, you will hear the progress of incoming calls until the handshake is finished. This can be annoying, especially if your WR-BBS runs twenty four hours a day. The "Q0" command is required, as WR-BBS will not be able to determine a caller's connect speed without result codes. The "V1" command is also required, so that WR-BBS is supplied with verbose result codes instead of numbers. The "X4" command makes the result codes even more verbose, so that WR-BBS can determine the speed at which a caller connects, as well as the modem's reports of any errors during handshaking. The "&C1" command is extremely important and essential. WR-BBS will NOT work without this command in your initialization string. This command makes the modem report the true state of the carrier detect. If omitted, the modem (by default) will usually report that carrier is present all of the time. WR-BBS will never finish the startup sequence if this is the case, as it will assume that a caller is connected, and try (up to 30 times) to drop carrier, when there was no carrier in the first place. The "&D2" command is equally important, as this instructs the modem to drop a call if WR-BBS lowers the DTR (Data Terminal Ready) line. Without this command in the initialization string, WR-BBS will not be able to disconnect calls properly. The "S0=0" command is REQUIRED unless your modem is one of the extremely few modems that do not report ringing. 99.999999% of all internal modems and 99.999998% of all external modems properly report ringing via pin 22. If yours does not, it is either very old, or defective. You can configure WR-BBS to work with the modem in auto-answer mode until you obtain a modem that works properly. See RINGDETECT= for more details. Unless you need to compromise your WR-BBS to adapt to an incompatible modem, do NOT set your modem for auto answer, either via an initialization command or via switches on the modem. The "S2=128" command disables the escape sequence that is used to gain control of your modem when it is on line. This sequence, by default, is "+++". A hacker could arrange his system to send this sequence and take control of your modem. I won't explain how, but it can be done. By setting S2=128, the escape sequence is disabled, so nobody can play games with your modem. --------------------------------------------------------------------------- MODEMDELAY= DEFAULT=55 This setting allows you to compensate for a "slow" or exceptionally fast modem. Allowable values are from 1 to 1024, and represent milliseconds of delay between each command character transmitted to the modem. Note that this character "pacing" has no connection with the modem's behavior when connected to a caller - all MODEMDELAY does is slow down command strings being sent to the modem by WR-BBS. If your modem "misses" the "ATA" command (and ignores ringing calls), try increasing the MODEMDELAY setting a bit at a time. The same is true if the status line shows that your modem is not acknowledging initialization commands (or there are characters missing in the echoed result). You should never have to set MODEMDELAY higher than 250. If your modem is super-efficient, you may be able to trim MODEMDELAY down below 55, reducing the initialization time slightly. If you are running an error correcting modem at very high DTE speeds (57,600 and above), you will probably need to set MODEMDELAY to 100 or more to get reliable command acceptance. --------------------------------------------------------------------------- NEWUSER_ADDRESS1= DEFAULT=Y If Y is specified, then WR-BBS will ask each new user for their address during the new user questionnaire. If set to N, then new callers are not prompted for their address, but can optionally enter it if desired. --------------------------------------------------------------------------- NEWUSER_ADDRESS2= DEFAULT=Y If set to Y, then new callers, while completing the new user questionnaire, will be prompted to (but not required to) enter their "auxiliary" address. An auxiliary address is any part of their street address that does not fit on the first line (NEWUSER_ADDRESS1=), such as their apartment number. If set to N, new callers are not prompted for an auxiliary address, but can enter one if so desired. --------------------------------------------------------------------------- NEWUSER_CITY= DEFAULT=Y During the new user questionnaire, new callers will be required to enter their city if set to Y. If you do not wish to require this response, set this to N. --------------------------------------------------------------------------- NEWUSER_COS= DEFAULT=A This entry defines which class-of-service (COS) is initially assigned to new callers after they complete the new user questionnaire. It can be any letter from A to Z. By convention, "A" is the lowest letter, and thus would have the lowest access privileges, but you don't have to follow this convention, since any COS can be given any privileges you wish to configure. By specifying a "restricted" class-of-service for NEWUSER_COS=, you can ensure that new users do not have excessive access rights until you have verified their questionnaire responses. After verification, you would (as the SysOp) go into the SysOp menu, select (U)ser administration, and assign a "better" class-of-service to the verified caller. See section 11 for a detailed explanation of the WR-BBS flexible class-of-service system. --------------------------------------------------------------------------- NEWUSER_DATAPHONE= DEFAULT=N This item determines whether new callers, while answering the new user questionnaire, are required to enter a "data" or "business" phone number. In some environments, such as a private "hobby" BBS, it is not realistic to expect that every caller would have a data or business phone number to give, so you will probably want to set this item to N. If you are running a more specialized BBS, where, for example, you need the fax number for every caller, you can set this to Y to prompt them for a non-voice telephone number. --------------------------------------------------------------------------- NEWUSER_VOICEPHONE= DEFAULT=Y Setting this item to Y makes WR-BBS ask for a voice telephone number from each new caller who completes the new user questionnaire. Unlike a "data" phone, you can be assured that every caller has at least a voice phone number to supply (how are they calling your board?), and most SysOps demand this information for verification purposes. If NEWUSER_VOICEPHONE=Y and VALIDATEPHONE=Y, the new user will not be allowed to enter a bogus telephone number such as 555-1234 or 800-XXX-XXXX. They can still dream up a fake number which satisfies the VALIDATEPHONE routine, but if they do enter such a fake number, you can lock them out with a clear conscience, knowing that they intentionally entered a bogus number, and then responded that the number was indeed accurate. See the VALIDATEPHONE description for more details. --------------------------------------------------------------------------- NEWUSER_ZIPCODE= DEFAULT=Y If set to Y, new callers who indicate that they live in the United States will be required to enter a Zip code which complies with the USA format. Either a five or nine digit zip code complies. New callers who are not US residents (based on their answer to the "country" question) are not held to this requirement, as their postal codes may have one of many different formats, or be non-existent. If set to N, no prompting for a Zip code is done, but it can be optionally entered by the caller. --------------------------------------------------------------------------- PARITY= DEFAULT=N The default setting of "N" for no parity checking should not be changed except for unusual situations. Other valid settings are "E" for even, "O" for odd, "M" for mark and "S" for space. Note that ANSI graphics, file transfer protocols, and most doors will not work consistently unless parity checking is disabled by setting it to "N". --------------------------------------------------------------------------- PORTNUMBER= DEFAULT=1 Use this setting to tell WR-BBS which communications port your modem is connected to. Standard port configurations for COM1 and COM2 are fully supported by WR-BBS. For COM1, the line would read PORTNUMBER=1, and for COM2, the line would read PORTNUMBER=2. There is only partial support designed into WR-BBS for ports other than COM1 and COM2, and operation on non-standard ports is not assured in this version of WR-BBS. The IBM PC <tm> and AT <tm> in their most generic form do not support communications ports other than COM1 and COM2. If you wish to use a non-standard COM port, it must have an IRQ that respectively matches the supported COM ports. The IRQ mapping is: COM1 IRQ4 COM2 IRQ3 COM3 IRQ4 COM4 IRQ3 --------------------------------------------------------------------------- REGISTRATION= After you register your copy of WR-BBS, you will receive a "license code", which is used in conjunction with the REGISTRATION= entry to tell WR-BBS that you have a registered copy. --------------------------------------------------------------------------- RINGDETECT= DEFAULT=1 WR-BBS supports two kinds of ring detection. In 99.99% of all cases, you should use ring detection type 1, which is the default. Ring detection type 1 uses your modem's hardware ring signal line (pin 22 on the RS-232 cable). This pin goes high when the phone line rings. It is the most reliable method. If you use ring detection type 1 (which you should), make certain that you include S0=0 somewhere in your modem initialization string (see MODEM_INIT_1=). This turns off the auto answer feature on your modem. As with most BBS products, WR-BBS waits for ringing to be reported by the modem, then issues a command to make the modem answer. If your modem is set for auto-answering with ring detection type 1, nobody will be able to establish a connection and weird things will happen. Also, make sure that your modem's DIP switches are set to disable auto-answer. There are a (very) few modems which do not report ringing via pin 22. If you have one of these modems, you will have to set RINGDETECT=2. If RINGDETECT=2, you MUST have auto-answer enabled by including S0=1 in your modem initialization string. Use RINGDETECT=2 only if your modem cannot support the default method of ring detection. If you have any doors configured, be aware that using RINGDETECT=2 allows a small (but real) window of opportunity for a hacker to get into the system. If a caller drops carrier while in a door, and a new call comes in before the door has exited to WR-BBS, the new caller will be able to essentially continue the session of the previous caller. If the previous caller was the SysOp or a user with a liberal class-of-service that allows access to the operating system, a hacker who obtains access this way can do grave damage, including formatting your drives or introducing a virus. This potential security breach is not a flaw in WR- BBS, but a short coming in some door programs that do not immediately react to lost carrier by exiting to the calling program. Although the likelihood of such an occurrence is rare, it is one more reason to use RINGDETECT=1, which all modern modems (that are connected properly) support. If you modem does not support pin 22 ring reporting, and you wish to use doors, you should consider getting a better modem before using RINGDETECT=2. --------------------------------------------------------------------------- SCREENDIR= DEFAULT (SAME AS HOME PATH) This is an optional entry. WR-BBS uses a number of "screen" files, which have extensions of .ASC and .ANS. These files are sent to callers to make the corresponding screens display on the caller's system. Depending on how sophisticated you make your WR-BBS application, you could have anywhere from 50 to a few hundred screen files. To avoid cluttering up the home path directory, you can use SCREENDIR= to specify a separate directory where the screen files are stored. For example, if your home path is: D:\WR-BBS and you want to keep the screen files in D:\WR-BBS\SCREENS Then you would configure WR-BBS by inserting the following line in WRCONFIG.SYS: SCREENDIR=D:\WR-BBS\SCREENS If you do not wish to have a separate screen directory (you don't have to), then omit the SCREENDIR= entry, or REMark it out. If you use this item, it must point to a valid directory where all .ASC and .ANS files for WR-BBS are stored. --------------------------------------------------------------------------- SCREENSAVER= DEFAULT=Y Unless you tell WR-BBS otherwise, its uses a screen-saving display procedure whenever it is idle. Since most WR-BBS boards are operated twenty four hours a day, the screen saver prevents the WR-BBS screen image from becoming burned into the monitor's picture tube. When the screen saver is in effect, a three or four line abbreviated display is located at random places on the screen, using random colors and intensities. If there are messages waiting for the SysOp, the fourth line flashes "New message(s) for SysOp". If the SysOp has no messages waiting, there is no fourth line in the screen saver display. The top line of the screen-saver display shows the current date and time, and the WR-BBS "up" symbol. When the screen saver is in effect, pressing ESCape will return WR-BBS to the full-screen display mode. Whenever any activity occurs (such as an incoming call, event, or local administration), the screen saver reverts to a full screen display automatically. If you set SCREENSAVER=N, WR-BBS will always display in full-screen mode. --------------------------------------------------------------------------- SEEKBAUD= DEFAULT=MAXBAUD This entry is not required unless you have one of the very few modems out there that seeks "up" to negotiate a connect speed. Most modems attempt to seek "down" from their highest possible speed until the remote modem agrees to a connect speed. Thus a 2400 baud modem would answer at 2400 baud, and step down to 1200, and then 300 until the far modem handshakes. A few rare modems start at their lowest speed, and "sweep" all possible connect speeds before completing their negotiation. If you have one of these strange modems, set SEEKBAUD to the speed at which the modem should begin its negotiations. --------------------------------------------------------------------------- SERIALNUMBER= After you register your copy of WR-BBS, you will receive a serial number. Enter it with the SERIALNUMBER keyword in WRCONFIG.SYS. --------------------------------------------------------------------------- SHELLSWAP= DEFAULT=Y When WR-BBS runs some type of external program (door, event, shell to DOS), it can swap out more than 90% of its memory image, leaving less than 18K of itself in memory. This leaves lots of memory for the program that is being run by WR-BBS. If your system has at least 550K free exPANDed memory (not exTENDed memory), then WR-BBS will swap to EMS memory. This swap occurs as quickly as your computer can move the WR-BBS image from one section of memory to another - within milliseconds. If your system has insufficient exPANDed memory to complete the swap, WR-BBS instead swaps to a disk file named WRBBS.$$$ located in the home path. If you have a slow computer with a slow drive, and insufficient exPANDed memory, the time it takes to swap the WR-BBS image to disk can be several seconds. Callers may perceive this delay as your board being sluggish to respond (WR-BBS will not accept caller input while the swapping is happening). In this case, you might wish to set SHELLSWAP=N. WR-BBS will not swap its image when configured that way. The drawback is that WR-BBS will continue to occupy its original memory when the external program is invoked, and the external program may not have sufficient memory available. If there is insufficient exPANDed memory and WR-BBS swaps to disk, it automatically deletes the file WRBBS.$$$ when it swaps back. Do not edit or delete the swap file when shelled out, or WR-BBS will fail to reload, and a system reboot will be required. --------------------------------------------------------------------------- SYSOP= NO DEFAULT You must put a line in WRCONFIG.SYS to indicate who is the SysOp. Use the exact name that you will log onto your WR-BBS with. When the SysOp logs on, special privileges are allowed for that person who is named in this entry. (This person must also log on to the board and establish an account like any other caller - see section 12). Example: SYSOP=WILSON ROGERS --------------------------------------------------------------------------- TIMELIMIT= DEFAULT (60 FOR ALL COS'S) You should have one TIMELIMIT= entry for each class of service that your WR-BBS utilizes. There can be up to twenty six (26) lines in WRCONFIG.SYS which begin with TIMELIMIT=, defining the caller's time limit (in minutes) for each of twenty six possible classes of service. The proper syntax is: TIMELIMIT=?|XXX Where "?" is replaced with a class of service letter (from A to Z), and "XXX" is replaced with the amount of time you wish to allow for callers who have that class of service. For example, if you want to give callers in class of service "A" sixty minutes, and give ninety minutes to callers in class of service "B", the following two lines would correctly accomplish that purpose: TIMELIMIT=A|60 TIMELIMIT=B|90 Valid values for TIMELIMIT are 1 through 999. When assigning time limits, keep in mind the types of users who will be in each class of service. You may want to give a few special users a lot of time, perhaps as much as 180 minutes (three hours). New users would be given significantly less time, perhaps 30 or 45 minutes. A typical "regular" user might be given 60 to 90 minutes. The TIMELIMIT value is a daily limit for each user in the designated class of service. For example, if class of service A allowed sixty minutes, a user with that class of service could use the system for sixty minutes in one session, or two sessions of thirty minutes each, or six sessions of ten minutes, and so on. WR-BBS checks the caller's time remaining at regular intervals, and if the caller exceeds the allotted time, the caller is logged off the system after a seeing a message explaining that their time is used up for the day. Each caller's time limit is reset to the limit (defined in their class of service) on their next logon after midnight passes. Thus, a user who consumes their entire time limit in one day can call back at 12:01 AM on the next day and start with a new daily time allotment. --------------------------------------------------------------------------- UPLOADBONUS= DEFAULT=2 This item tells WR-BBS how much time to give callers as a "bonus" for uploading files. Valid values are from 0 to 255. When a caller completes an upload, WR-BBS checks the file size, and determines the number of kilobytes (KB). That value (KB) is divided by 10 (to determine how many "tens" of kilobytes were received), and then multiplied by the value set in UPLOADBONUS to determine the number of minutes to compensate the caller. For example, if the caller uploads a 100 KB file, then 10 "tens" of kilobytes were received, so if the UPLOADBONUS was set to "2", the caller would receive 20 minutes compensation. If you don't want to give callers any bonus time for uploads, set UPLOADBONUS to "0". WR-BBS will never allow any caller to have more than 999 minutes of time remaining, so if you use a high value for UPLOADBONUS, such as 100, callers who upload large files will have their time increased to 999 minutes, but not beyond. If the caller aborts the upload, or for any reason the upload fails, no compensation is granted to the caller. =========================================================================== SECTION 11 CLASS OF SERVICE (COS) CONFIGURATION =========================================================================== In any good bulletin board application, security and flexibility are afforded by multiple "access levels". WR-BBS is no exception, and up to twenty six access levels can be defined. If you have configured other BBS applications previously, you may be familiar with the term "access level", also referred to as "permission level". TIP: The term "Class of Service" (or "COS") in WR-BBS has virtually the same meaning as "access level" on other BBS products. In WR-BBS, access to various features is controlled by the caller's Class Of Service (abbreviated as COS). You can custom-configure the COS assignments to give the appropriate access to the callers (or caller) in each class of service. With COS definitions, you can control such things as: - Number of minutes permitted per day. - Which file areas can be accessed. - Whether or not downloads are allowed. - Whether or not uploads are allowed. - Which file transfer protocols can be used. - Which doors can be accessed. - Whether or not a caller can page the SysOp. When planning your COS assignments, you should first group callers into specific types of callers. For example, your breakdown of caller types may look something like this: - New users who have not been verified yet. - Regular users who have normal access. - Special users who have more extensive access. - The SysOp. In the above example, you might assign COS "A" to new users, COS "B" to regular users, COS "C" to special users, and COS "D" to the SysOp. You can assign any COS you wish to any caller - the COS letters are not incremental. In other words, COS "X" does not necessarily grant a higher level of access that COS "B" - unless you configure both COS's to make this possible. By convention, however, you may wish to make the COS assignments appear to be incremental - with COS "A" being having the lowest access rights, and COS "Z" having the highest. This makes it easier for you and your callers to relate to the COS letters after they have been assigned. The SysOp should (but is not required to) have an exclusive class of service with no other users in it. This allows you to grant unrestricted access to yourself for administration and testing. Valid class of service letters are "A" to "Z". Permissions, privileges, and access rights are granted by "allowing" various classes of service to access various individual parts of WR-BBS, via entries in WRCONFIG.SYS. In other words, there is no "chart" of which classes of service can do what, but instead, the COS's allowed to use individual features are assigned to those features. This provides the ultimate in flexibility. For example, rather than "allowing" COS "A" to access file area "C", you would do the inverse - configuring file area "C" to be accessed by callers with COS "A". Class of service's are assigned to features in WRCONFIG.SYS. See section 10 for more information on configuring WRCONFIG.SYS. By default, no class of service can access any of the COS-controlled features, until you designate otherwise in WRCONFIG.SYS. Thoughtful planning before implementing the COS permissions will allow for growth and flexibility during the life of your WR-BBS system. Should you wish to make changes to the COS configuration, you can edit WRCONFIG.SYS at any time. =========================================================================== SECTION 12 THE SYSOP =========================================================================== On any BBS or host system, the SysOp is the most significant user, as well as the user with the most access privileges. WR-BBS follows this convention by providing special access for the one user who is designated as the SysOp. A SysOp must be defined from proper operation and administrative access on WR-BBS. The SysOp is quite literally the System Operator. Since you are reading this, you will probably be the SysOp of your WR-BBS system. You will set up the system, maintain its databases and files, and be a point of contact for all other users who want to communicate questions, problems, or comments about your WR-BBS installation. Anyone given SysOp privileges should be a responsible person who is well known to the principal operator of the WR-BBS system. Since the SysOp can be given permission to drop to the operating system, allowing an irresponsible person to be a SysOp means that the irresponsible SysOp could not only destroy your WR-BBS databases and files, but they could even format or un-partition your computer's drives! In order to gain administrative access to the User, File Library, and other WR-BBS databases, the SysOp must log on to the WR-BBS system (locally or remotely), just as any other user would. Then, at the Main Menu, the SysOp presses the "Z" key, (a hidden command available only to the SysOp), which presents the SysOp menu. When configuring your WR-BBS system for the first time, it is very important to designate a SysOp. This is accomplished with an entry in the WR-BBS configuration file, named WRCONFIG.SYS. This configuration file must have an entry that reads: SYSOP=JOHN DOE Where "JOHN DOE" would be replaced by the SysOp's actual name. See section 10 for more information on how to configure the file WRCONFIG.SYS. Only one SysOp is configured in the file WRCONFIG.SYS. LOGGING ON: There are two ways to log on to your WR-BBS system - via the modem and from the local console (your computer's keyboard). Obviously, WR-BBS must be loaded and running before it will accept any calls, whether from remote users (via modem) or from local users (via the console). Also, WR-BBS must be "ready for calls". That is, it can not be executing an event, preparing to execute and event, recycling the modem (just after a previous call), shelled to DOS, or doing anything other than waiting for calls (which is the default condition). To log on via the modem, simply place a modem call from another system to the telephone number which is attached to the modem used by WR-BBS. Your data call will be answered by WR-BBS, and a session will begin. To log on from the local console, press ALT-L while the system is waiting for calls. WR-BBS will then "answer" your logon request, and you will be presented with the same screens and most of the same options that would have been available to a user calling in via the modem. This is a good way to "preview" your WR-BBS application before introducing it to the public. Local logons also permit you to experiment with WR-BBS without having to have an actual modem attached to the computer. (The COM port must be working, however). There are a few differences between a "remote" (via modem) session and a "local" (via console) session. Since there is no carrier present at any time during a local session, WR-BBS is not as quick to detect an "abandoned" local session. In a remote session, WR-BBS can quickly detect loss of carrier (where a user hangs up without a proper logoff) and recycle for the next session. In a local session, the only clue that WR-BBS has to tell it about the session being abandoned is a keyboard timeout. If no keys are pressed for 5 minutes (on a local or remote session), WR-BBS assumes that the user has abandoned, and ends the session, then recycles for the next call. Also, the following WR-BBS features are not available during a local (via console) login: File transfer protocols (uploads and downloads) Chat facility Most doors Most of the sessions processed by WR-BBS are remote sessions, where the user, from virtually anywhere in the world, has called via modem. During a remote session, the console (local keyboard) is still "active", so any keys pressed on the local keyboard will be interpreted by WR-BBS as if the remote caller had pressed them those keys. This allows the SysOp to assist callers by "leading" them to the correct areas of the WR-BBS application by pressing the appropriate local keys for them, while they watch. Remember that both keyboards are active, so if the remote caller is entering a message or responding to a prompt, and both the remote user and the SysOp start typing, WR-BBS will see both inputs (which will effectively be meaningless). *** When logged on remotely (via the modem) as the SysOp, press the "Z" key to get to the SysOp administration menu. This key is not indicated on the main menu screen (and is only available to one caller - the SysOp). =========================================================================== SECTION 13 SETTING UP DOORS =========================================================================== Doors are external programs (not supplied with WR-BBS) which your callers can run via WR-BBS. Many doors are games, but virtually any program can be run as a door with the proper door manager software. There can be up to twenty six (26) entries in WRCONFIG.SYS which begin with the DOOR= keyword. If you are not planning to have any doors on your WR-BBS system, you should have no DOOR= entries in WRCONFIG.SYS (or remark the entries out). Each door that you configure will be referenced by a letter. There are twenty six available letters to use for this purpose (A to Z). You can assign these "reference" letters any way you want, and they do not have to be used in order. For example, you could have four doors, designated "A", "C", "X", and "Z". Reference letters cannot be duplicated, so you cannot have two different doors designated as door "A". For convenience, you may wish to assign the first door the letter "A", give "B" to the second door, use "C" for the third door, and so on. Letters other than "A" through "Z" cannot be used to designate doors, so there is a limit of twenty six doors that can be configured. To configure a door for WR-BBS, you need to do four things: 1. Add an entry to WRCONFIG.SYS which assigns a letter (A to Z) to the door and defines which classes of service may access that door. 2. Create a batch file which will control the operation of the door program (whether or not the door program needs such a batch file with other BBS programs). 3. Configure the door program itself to recognize the DOOR.SYS standard file that WR-BBS creates when a door is selected by a caller. 4. Create or edit the DOORMENU screen files to reflect the letter that you have assigned to the door, and a brief description of the door's purpose. ADDING THE DOOR ENTRY TO WRCONFIG.SYS The entry in WRCONFIG.SYS uses the following syntax: DOOR=A|ABCDEFGHIJKLMNOPQRSTUVWXYZ ^ ^ | Classes of service allowed to access this door | | Letter designation for this door For example, the following line in WRCONFIG.SYS would indicate a door with a letter of "D" which can only be accessed by callers with a class of service from A to H: DOOR=D|ABCDEFGH Notice that there are no spaces in the entry, and a "pipe" symbol separates the door's letter from the class of service information. CREATING THE BATCH FILE FOR THE DOOR Every door on WR-BBS needs to have its own batch file, whether or not the door can run directly from the command line. WR-BBS calls the batch file (not the door program) when a caller selects the door from the Doors Menu. There can be up to twenty six batch files for controlling doors. The name of the batch file determines which door it controls. The batch file named DOORA.BAT is called when door "A" is selected, and DOORB.BAT is run when door "B" is selected, and so on. (The fifth letter in the batch file name corresponds to the door's letter). The batch file can be a simple, one line entry which contains the door program's name, or it can be a complex, branching batch file with many lines, depending on your needs. Any activity necessary to set the door up (such as copying configuration files, etc) should be done by that batch file. Keep these restrictions in mind when designing the batch files for your door programs: - The batch file(s) must be in the home path. - The door program must not modify or delete the batch file. - Do NOT call WR.BAT or WRBBS.EXE from the door's batch file. ABOUT DOOR.SYS Whenever WR-BBS runs a door for a caller, it first creates a file named DOOR.SYS. This is a text file which is created in the home path. It contains information about the board and the caller, which many door programs can use to personalize the caller's visit to the door. I have settled on the DOOR.SYS standard because many of the "big" BBS programs now use this as a standard, and most competent door programs recognize DOOR.SYS when they run. If the door program you want to use does not recognize the DOOR.SYS file, you may need to employ a utility program which converts the DOOR.SYS information to a different format (such as CALLDATA.TXT). Most door programs, however, can be configured to recognize DOOR.SYS. If the door program expects DOOR.SYS to be in a specific directory other than the home path, you can copy the DOOR.SYS file to the desired location with an entry in the door's batch file. Some doors do not correctly recognize the DTE speed defined in DOOR.SYS when an error-correcting modem is used. See the WRCONFIG.SYS keyword BADDOOR= for more details. MODIFYING DOORMENU SCREENS The Door Menu screens (DOORMENU.ASC and DOORMENU.ANS) must be edited or created to reflect the door(s) that you are offering. For each door, you need to list the door's letter (as defined in WRCONFIG.SYS) and a description of the door. There are no sample screens for DOORMENU.* included with the WR-BBS distribution, as this information is highly variable. See section 7 for instructions on modifying the menu screens. USING A DOOR MANAGER The use of a good "door manager" utility is strongly advised. There are many door programs available, and their design quality ranges from "excellent" to "terrible". A door manager can compensate for poorly written door programs and helps to protect your board from damage that could occur when a poorly designed door program is used. Be aware that some door programs do NOT offer the following basic features: - Detection of dropped carrier. - Preventing caller from accessing command line. - Detection of inactivity. - Trapping and handling of errors in door program itself. A door manager will help compensate for such weaknesses by exerting its own control over the door program when an unexpected event occurs. Without a door manager, if the door program does not detect carrier loss, and the caller drops carrier, your WR-BBS system will be "hung" indefinitely. Remember that WR-BBS is not active when a door is running, and therefore has no control of the door). Some door programs require a Basic runtime module to accompany the .EXE file. I have found that this type of door program often has no internal error trapping, and any error in the program's operation results in a message such as "RUNTIME ERROR AT LINE NUMBER NOLINE". The board will then be hung unless a door manager is used to control such a poorly designed door. There are a number of door managers available, including DOORWAY. The DOORWAY program is available from BBS's throughout the country, including the WR-BBS Headquarters BBS. Most of them are shareware offerings - be certain to register them with their respective author. Door manager programs have another useful feature in that they can convert almost any DOS program into a door program - you can use this (with caution) to give your callers access to other applications. If you do this, make sure that your caller's cannot use the other application's DOS shell feature to access the operating system. =========================================================================== SECTION 14 TROUBLESHOOTING =========================================================================== Most WR-BBS problems can be easily corrected by reading this documentation, particularly this section. Support for WR-BBS is available via the WR-BBS Headquarters BBS. Don't hesitate to log on the WR-BBS Headquarters BBS if you cannot get your WR-BBS system working properly. The author will respond to your support request promptly (usually within 24 hours). --------------------------------------------------------------------------- PROBLEMS SETTING HOME PATH ENVIRONMENT VARIABLE If DOS reports "Insufficient Environment Space" when you (or AUTOEXEC.BAT) try to SET the home path, you can increase the environment space available by modifying the CONFIG.SYS file on your system. To enable a larger DOS environment, the following line should be inserted in CONFIG.SYS: SHELL=C:\COMMAND.COM /P /E:1024 If your DOS command interpreter resides somewhere other than the root directory of C:, you would substitute the appropriate directory path, as in: SHELL=C:\DOSFILES\COMMAND.COM /P /E:1024 In the above example, the DOS command interpreter is in the sub-directory named C:\DOSFILES. The "/P" switch tells DOS that this is to be a "permanent" command interpreter (one that the EXIT command cannot release). The "/E" switch tells DOS the desired environment size (from 128 to 32767 - the minimum and maximum vary slightly among DOS versions). It must be followed by a colon and a number within the allowable range. If no SHELL statement is included in your CONFIG.SYS file, the environment is set to a (small) default of 160 or so bytes, depending on DOS version. This is inadequate for systems which use multiple SET statements to modify the environment, including systems running WR-BBS along with other environment-dependent applications. WARNING! Make sure you know the exact location of your actual DOS command interpreter (COMMAND.COM) before modifying CONFIG.SYS with a SHELL statement. If your SHELL statement points to a non- existent path, or a directory not containing the command interpreter, DOS will not boot, and you will be left with a hung system that only says "Bad or missing command interpreter". If this happens, you will need to boot from a system-formatted floppy diskette, and then modify the hard drive's CONFIG.SYS. NOTE: If your are using a DOS enhancer which provides an alternate command interpreter, such as 4DOS, EZSHELL or WR-DOS, check with the documentation that accompanies the DOS enhancer for instructions on increasing the environment if needed. (WR-DOS's environment is 2000 bytes by default, so it should not be necessary to change it). --------------------------------------------------------------------------- MODEM PROBLEMS If your modem does not work properly with WR-BBS, it is likely that one (or more) of the following problems exist: 1. Your modem has hardware DIP switches which allow certain configuration items to be "hard configured" on the modem - and one or more of these switches is set incorrectly. If your modem has hardware switches or jumpers, make sure that they are set as follows: A. Carrier detect (CD) signal not forced on, but tracks actual carrier detection at all times. B. Data Terminal Ready (DTR) signal not forced on, but is controlled by the communications program (WR-BBS). C. Auto answer MUST BE OFF. WR-BBS requires auto-answer to be disabled for correct operation. The only exception to this rule is if you have a defective or incompatible modem - see RINGDETECT= in section 10. 2. Your modem initialization string is not being recognized by the modem. With most modems, any invalid command in any of the initialization strings will cause the modem to ignore the entire initialization string. To check for this, watch the WR-BBS main screen during startup. The status bar shows the response sent by the modem after each command, including the initialization strings. The response you see in the status bar should be an echo of the initialization string itself, followed by "OK". (There may be some arrows in that string as well, representing linefeed and carriage return characters). If you do not see the initialization string(s) echoed back, or see the word "ERROR" on the status bar, then the modem did not recognize the initialization string. 3. You have included S0=1 (or some other value other than zero) in your initialization string. This turns on the modem's auto answer feature, which prevents WR-BBS from working properly. Auto answer MUST BE OFF. WR-BBS requires auto-answer to be disabled for correct operation. The only exception to this rule is if you have a defective or incompatible modem - see RINGDETECT= in section 10. 4. Your modem does not recognize the commands commonly used by Hayes <tm> modems. Some modems claim to be "100% guaranteed Hayes <tm> compatible" when in fact they are not at all. If you have one of these modems, you will have to research and configure the proper command strings and initialization codes. --------------------------------------------------------------------------- MISCELLANEOUS TROUBLESHOOTING PROBLEM: During startup, WR-BBS says "HOLDING DTR DOWN FOR XX SECONDS", and then aborts the startup process. SOLUTION: Your modem is incorrectly set up and is reporting that carrier detect is present at all times. To WR-BBS, the presence of carrier means that a caller is probably connected, and WR-BBS attempts to drop the "caller" by dropping DTR for up to 30 seconds. If carrier is still detected, WR-BBS aborts the modem initialization (and does not start), because it has not established the control it requires from the modem. PROBLEM: A call rings in, and WR-BBS reports that it is answering the call. But instead of the caller establishing a connection, WR-BBS reports a result code error and the caller is dropped. SOLUTION: Your modem is configured incorrectly, and is set to auto- answer. When WR-BBS sends the answer command, the modem aborts the connection, and WR-BBS never sees a valid connect code. Auto-answer should never be enabled, except for a few rare circumstances. See RINGDETECT= in section 10 (configuring with WRCONFIG.SYS). PROBLEM: A caller logs on via the modem, and has no problems during the on-line session. When they say goodbye, however, WR-BBS reports that it cannot disconnect the caller, logs errors, and then WR-BBS re-starts. SOLUTION: An incorrect modem configuration is to blame. Your modem is set to hold DTR "high" at all times, and therefore WR-BBS cannot drop DTR to disconnect the caller. WR-BBS does not use the unreliable method of sending +++ ATH0 to disconnect a caller. Dropping DTR is guaranteed to positively disconnect the caller - provided that WR-BBS is allowed to control the DTR signal. PROBLEM: When a caller selects a file transfer or door, they are disconnected when WR-BBS shells out to run the protocol or door. SOLUTION: WR-BBS does not alter the DTR or any other signals when it shells out. Make sure that you file transfer protocol or door program is configured properly - and check for any error messages those programs generate. The use of DOORWAY to control doors is recommended for trouble free operation. You can download an evaluation copy of DOORWAY from most large BBS systems. PROBLEM: When WR-BBS starts up, it sometimes runs the W-TREE maintenance utility and rebuilds the index files. SOLUTION: The file indices are rebuilt, as part of the startup process, any time that the W-TREE Database Manager cannot verify the indexes as being current. The usual cause is that WR-BBS was not shut down properly. The correct way to shut down WR-BBS is to press ALT-Q from the main screen, confirm the shutdown request, and then wait for all WR-BBS processes to terminate (about 20 seconds). You will know when WR-BBS has stopped because your system prompt will return. If you do not shut WR-BBS down properly, or reboot during the shutdown process, the W-TREE Database Manager will not have an opportunity to detach the files (DOS will force them closed instead), and the W-TREE Database Manager will rebuild the indices on the next startup. The chance of damaging the actual data files due to an improper shutdown is minimal, but that risk is one you should avoid anyway. PROBLEM: During startup, WR-BBS gets to the point where is displays "Database is not on line ... starting W-TREE Database Manager ...", then it aborts, reporting error # W-99000-4. The error text is "INSUFFICIENT DOS FILE HANDLES". SOLUTION: This error happens when the operating system (DOS) refuses to allow enough files to be opened for WR-BBS operation. You can fix this easily by modify your FILES= entry in CONFIG.SYS (not WRCONFIG.SYS). You should have FILES=30 or more to ensure than sufficient file handles are available for WR-BBS. PROBLEM: The WR-BBS activity log has entries that read "ERROR DURING IMAGE SWAP TO EMS - SHELL USED" SOLUTION: This message occurs if WR-BBS tries to swap the program out of regular memory into EMS (exPANDed memory), but cannot complete that operation. It is usually due to the EMS not being compatible with the LIM standard, or due to contention from another program in a multi- tasking environment, or due to a TSR (such as a disk cache) which unexpectedly accesses EMS while WR-BBS is swapping out. WR-BBS swaps out for doors, file transfers, and events. This is not a fatal error, but simply informs you that WR-BBS used a conventional shell (without swapping out). PROBLEM: WR-BBS reports error # W-10XXX-2, W-99000-3 or W-10XXX-15 (where "XXX" is any three digits), and then WR-BBS shuts down and restarts. SOLUTION: These errors indicate path errors. The usual cause is that you have the WR-BBS home directory included in your DOS path statement (it should not be). It can also occur in a networked environment if the server logs the WR-BBS machine out, and remaps the drive letters while doing so. Another possible cause is if one of your events corrupts the DOS environment so that the home path environment string is not longer valid. PROBLEM: WR-BBS starts up normally, but then thinks that there is an incoming call (when there is none). It "answers" the phantom call, but of course, never establishes a connection. SOLUTION: Your modem is set to report that carrier is present at all times - an invalid setting. Make sure that AT&C1 appears in your modem initialization string, and that your modem's DIP switches or jumpers (if any) are set to honor carrier detect and not artificially hold it high. PROBLEM: Callers complain about "missing" characters, skewed screens, and file transfers that fail for no apparent reason. SOLUTION: Dropped characters are almost always due to one of two things: 1. Flow control mismatch: WR-BBS by default does not use flow control. If you are using an error correcting modem with locked DTE, be sure to set CTSFLOW=Y in WRCONFIG.SYS, and configure the modem (via initialization strings) to work with CTS flow control (not XON/XOFF flow control). 2. Interrupt latency: Programs that are running simultaneously on the same machine as WR-BBS can "lock" interrupts for extended periods, causing "drop outs" on the communications port. Some "resident" programs (TSR's) are guilty of this. Such programs include some disk caching programs, especially when the cache is configured to use exTENDed memory. To troubleshoot this problem, temporarily remove all DEVICE statements from CONFIG.SYS (not WRCONFIG.SYS), and rename AUTOEXEC.BAT to something else to hide it from DOS. Then boot the system, manually type a SET statement to set WR-BBS's home path, and then start WR-BBS. If the problem no longer exists, try adding statements back into CONFIG.SYS one at a time, rebooting each time and checking for dropped characters. Then add each line back to AUTOEXEC.BAT, doing the same thing, until the offending program is found. --------------------------------------------------------------------------- NEED SUPPORT? Support for WR-BBS is available exclusively through the WR-BBS Headquarters BBS. Call (206) 828-9089. See section 1 for more detailed information on WR-BBS support. If you have problems with WR-BBS that cannot be resolved by following the instructions in this document, please log on to the WR-BBS Headquarters BBS. =========================================================================== SECTION 15 MIDNIGHT.BAT =========================================================================== One of the features built into WR-BBS is the ability to automatically run a batch file when the computer's clock indicates that the date has changed. If you have a batch file named MIDNIGHT.BAT in the same directory as the WR-BBS program files (the home path), this file will be executed as soon as WR-BBS becomes idle after a date change. If there is no call (or local administration activity) when the date changes, then MIDNIGHT.BAT will execute within sixty seconds of midnight. If there is a call in progress when the date changes, or you are doing some administrative activity on WR- BBS from the local console when midnight rolls around, WR-BBS will execute MIDNIGHT.BAT as soon as the system becomes idle again, ie after the caller logs off, or the administration activity stops. The use of MIDNIGHT.BAT is optional. If the batch file named MIDNIGHT.BAT does not exist in the WR-BBS home directory, nothing will happen when the date changes, and the system will continue to wait for calls just as it does at any other time. A sample MIDNIGHT.BAT file is included with the WR-BBS distribution archive. You can modify this file to suit your needs, or delete it if you do not wish to use this optional feature. Some functions that you could include in MIDNIGHT.BAT might be: 1. To archive the log file. 2. To copy the WR-BBS database files to a backup directory. 3. To update your date-sensitive bulletin files. WR-BBS closes all of its files before executing MIDNIGHT.BAT, so it is safe to copy the database files. WR-BBS shells out to run MIDNIGHT.BAT (as opposed to terminating), so no special considerations in your batch file are needed. Just make sure that whatever programs you launch in your batch file automatically end themselves. Programs that may require human input, or operations that access the floppy drives or printer are not recommended. If one of these operations has an error, the system will remain hung until human intervention occurs. When WR-BBS calls MIDNIGHT.BAT, it adds one parameter to the DOS command line. This parameter is a six digit string representing the current date. For example, when MIDNIGHT.BAT runs on June 14, 1993, WR-BBS invokes the batch file with the following command line: MIDNIGHT.BAT 061493 You can ignore the parameter passed to the batch file if you have no use for it. You can capture that string by reading the DOS command line (using %1) in your MIDNIGHT.BAT batch file. You might want to use it to rename the current activity log (to a filename representing the current date) or some other date-specific DOS operation. The sample copy of MIDNIGHT.BAT shows one example of using the date string that is passed by WR-BBS when MIDNIGHT.BAT is called, to archive the log file. CAUTION: Do NOT call WR.BAT or launch WRBBS.EXE from your MIDNIGHT.BAT file. This will result in two copies of WR-BBS being loaded, with unpredictable (possibly catastrophic) results. Let MIDNIGHT.BAT end normally, and WR-BBS will "un-shell" and resume operation. If you do not wish to use this feature, delete or rename MIDNIGHT.BAT. =========================================================================== SECTION 16 WR_AFTER.BAT =========================================================================== This is an optional feature that WR-BBS offers. You do not have to use WR_AFTER.BAT. If you do not wish to use this feature, delete or rename WR_AFTER.BAT from your WR-BBS home directory. You may have a need to do some kind of "housekeeping" after each call is processed by your WR-BBS system. For example, you may have a third-party utility that scans the user database for new users, or perhaps a utility that collects statistics from the activity log file. Such utilities need to be launched after each call is completed by WR-BBS. The batch file WR_AFTER.BAT will do that for you. After each caller logs off (or otherwise ends their call), WR-BBS checks the home directory for the existence of a file named WR_AFTER.BAT. If this file does not exist, WR-BBS simply continues along and prepares for the next call. If, however, WR_AFTER.BAT is found, WR-BBS suspends operation after recycling the modem (but before opening the modem for the next call), and executes WR_AFTER.BAT. When WR-BBS starts WR_AFTER.BAT, it (WR-BBS) does not completely terminate, but swaps out to disk and then calls WR_AFTER.BAT. Do not run any programs in WR_AFTER.BAT that remain in memory (TSR's), and do not call WR.BAT from WR_AFTER.BAT. Doing either of these no-no's will result in unpredictable problems and mysterious error messages from WR-BBS. =========================================================================== SECTION 16 HOW THE MESSAGE SYSTEM WORKS =========================================================================== The message system uses a database file (WRBBSMSG.DAT) to keep track of messages. Information about who sent a message, the intended recipient, dates and times, receipt, and other details are all stored as records in the message database. The messages themselves are saved as individual text files, in a sub- directory that WR-BBS creates off the home path. Depending on the number of messages on file, there can be more than one message sub-directory. The first message sub-directory is named MSGFILES.000, and additional message sub-directories are named MSGFILES.001, MSGFILES.002 and so on. A new message sub-directory is created when an existing one has more than 254 current messages. WR-BBS, when creating a message file, first checks any and all existing message sub-directories to see if there is room available for another message file. Thus, if the MSGFILES.000 has 255 files in it, but 100 messages are deleted, the next 100 new messages will be put into MSGFILES.000 rather than creating a new sub-directory. There can be up to 1000 message sub-directories, but in order for this to occur, there would have to be more than 254,999 messages on file at one time - an unlikely event on any WR-BBS system. When callers delete messages (or messages are deleted by the SysOp), WR-BBS automatically deletes the corresponding message text file in the appropriate message sub-directory, freeing that space for the next new message. The message text files are given unique random file names, based on a built-in algorithm. Do not rename or delete active message text files. If a caller attempts to read an active message whose corresponding text file is missing, and error message is displayed to the caller, indicating that a system error has occurred. The "system errors" counter is then incremented, and an entry is made in the activity log to record the error. =========================================================================== SECTION 17 CONFIGURING EVENTS =========================================================================== You may wish to set up events on your WR-BBS system. Event configuration is not required for operation of WR-BBS, so if you are setting up your WR- BBS for the first time, you may wish to skip this section, and (optionally) configure some events later on. Events are external programs, utilities, or functions that you can schedule to occur on or after a certain time each day, or only on a certain day(s) of the week. Most BBS's utilize events as part of their normal operation, but this is not mandatory. Some examples of events are: - To automatically back up the BBS data files to diskette or tape drive during a period of low call activity. - To copy or archive the activity log file each night, the delete the original log file, thus preventing the activity log file from becoming large and unmanageable. - To update or create bulletin screen files at a certain interval, thus providing fresh bulletins for subsequent callers. - To run a program which synchronizes the computer's clock with an external source, thus ensuring that the computer always has the right time. Most events are driven by batch files, which then launch the actual utility program. It is possible, however, to launch a program directly. With WR-BBS, there are two types of events that can be configured, a "shell" event, and a "terminate" event. When a "shell" event runs, WR-BBS (or a portion of WR-BBS) remains loaded in memory, and WR-BBS calls the external program, much in the same way that the SysOp can shell to DOS from WR-BBS. The called program executes, and when it is finished, control returns to WR-BBS, which then picks up where it left off. A majority of events can be "shell" events. A "shell" event is the easiest to configure, as you only need to specify the day(s), time, and the name of the batch or program to be executed. With a "terminate" event, WR-BBS shuts completely down, closes all files, and then terminates. It no longer exists in memory, and all interrupts and file handles are released to DOS. It is up to WR.BAT (the batch file that controls WR-BBS, to detect the unique DOS error level when this happens, and launch the event program. WR.BAT or the launched batch file must then restart WR-BBS, as WR-BBS is completely shut down when a "terminate" event is invoked, and cannot restart itself. Why would you use a "terminate" event instead of a "shell" event? Here are some examples: - If the event program needs to open a lot of files. DOS only allows a given number of files to be assigned at a given time. WR-BBS has up to nine files assigned and/or open, even when waiting for a call. During a "shell" event, WR-BBS closes the files, but does not "un-assign" the file handles. As far as DOS is concerned, there are still nine file handles in use. If the event program needs to open a lot of files, DOS may react with "no more file handles". - If you run an event program that changes the FAT (file allocation table), you must run the event as a "terminate event". An example is a disk optimizer program. Most disk optimizers directly modify the FAT, and make low-level calls to DOS to move file sectors around. If WR-BBS did a "shell" event to run a disk optimizer, then the assigned files wouldn't be in the same place after the event runs as they were before the event. WR-BBS (nor any other program) would not be aware of the change, and when it attempts to update files, the results could be disastrous. - Events which use the same communications hardware as WR-BBS require that WR-BBS do a "terminate" event. When WR-BBS terminates, it de-installs all communications interrupts. During a shell, this is not done. If you run a "shell" event which uses the same COM port as WR-BBS, you may find that WR-BBS doesn't recognize the COM port any more. When this happens, WR-BBS may crash when the next call rings in. Some of the better written communications utilities (including WR-BBS) restore the COM port interrupts and vectors to the exact state they were in at startup time, rather than to a default setting. Such programs can probably be safely run in a "shell" event under WR-BBS. If in doubt, do a "terminate" event. All events are configured with an entry in WRCONFIG.SYS. There can be up to 16 "EVENT=" entries. If more than 16 appear in WRCONFIG.SYS, only the first 16 are used, and an error message appears during startup. Each event entry consists of four parts: 1. The "EVENT=" string, which must be the first six characters. 2. A single numeric character, indicating what day(s) of the week the event should occur on. 3. The time the event should occur (24 hour notation). 4. Either a fully pathed file name, if the event is to run a program, or a number (65-80) which is designates the DOS errorlevel that WR-BBS should terminate with when the event is due. Each of the four entries is separated with a "pipe" symbol (|). For item 2, the day(s) designator, use one of the following: 1 = Each Monday 2 = Each Tuesday 3 = Each Wednesday 4 = Each Thursday 5 = Each Friday 6 = Each Saturday 7 = Each Sunday 9 = Every day of the week A value of "8" for the day designator is not meaningful, and the event will never execute if set for day "8". For item # 3, the event's time, you must enter the full 24 hour time, complete with leading zeros. Thus, 13:55, 02:00, and 00:45 are valid times, but 2:00 is not. Midnight is expressed as 00:00. There is minimal error checking on the event configuration, so it is possible to schedule an impossible event, such as at 25:00 Some examples: EVENT=1|02:00|C:\UTILITY\COPYFILE.BAT The above event will run each Monday morning at 2:00 AM. It is a "shell" event, and the batch file named COPYFILE.BAT in the C:\UTILITY directory will be executed when the event runs. EVENT=1|02:00|*66 The above event is a "terminate" event. It will occur each Monday at 2:00 AM. When that time rolls around, WR-BBS will terminate, setting the DOS error level to 66. The batch file that started WR-BBS (such as WR.BAT) will test for this error level, invoke the other program, then restart WR- BBS. See section 8, which details the workings of WR.BAT, for a more detailed explanation of how DOS error levels are detected and branched. If you wish to have multiple events run on exactly the same schedule, just schedule one event in WR-BBS, and have that event run a batch file which launches the multiple programs. If any two (or more) WR-BBS scheduled events are configured to occur at exactly the same time, the order in which the events will be launched is determined by the order in which they were posted to the task queue, which may not be the order you listed them in the configuration file WRCONFIG.SYS. In order for an event to execute, WR-BBS must be loaded, running, and waiting for calls. If WR-BBS is doing something else (such as processing a call, or local SysOp activity), the event will not launch until the system becomes idle again. This version of WR-BBS does not incorporate a facility to force a caller off the system when an event is pending. Keep this in mind for extremely time-critical events. =========================================================================== SECTION 18 THE QUESTIONNAIRE =========================================================================== WR-BBS includes a questionnaire facility. There is only one questionnaire. You can include up to 255 "questions" in the routine, and collect an answer to each question. The responses are stored in a text file, annotated with the caller's name, and the date and time that the caller selected the questionnaire. There is no format-checking done on the responses. Unlike the New User Questionnaire, callers have the opportunity to "skip" answers or abort the questionnaire entirely at any point. NOTE: After the caller has completed the questionnaire (or if they abort the questionnaire at any point), they are returned to the Main Menu. You do not have to have a questionnaire if you have no need for one. If you would prefer not to have a questionnaire available to callers, simply make sure that there is no directory named QUESTION as a sub-directory off the home path. Any callers who press "Q" at the main menu will then be told that no questionnaire has been configured. To reduce caller confusion, you should also edit the MAINMENU.ASC and MAINMENU.ANS screen to remove the (Q)uestionnaire option if it presently appears as a choice. Before you enable the questionnaire, you must first create a few (or more) short "question files". These are essentially the same as the screen files used elsewhere in WR-BBS, except they are typically much smaller, since they usually consist of just one or two sentences. Just as with other WR- BBS screen files, you need to create an ASCII (.ASC) and ANSI (.ANS) version of each file. There can be up to 255 questions. Most callers would not endure even 100 questions, so your questionnaire will probably consist of maybe a dozen questions maximum - but you can go wild and write up to 255 questions if you have a special need. The filenames for the question files follow the WR-BBS convention: Non-ANSI ANSI ------------ ------------ 1st question QUES0001.ASC QUES0001.ANS 2nd question QUES0002.ASC QUES0002.ANS 3rd question QUES0003.ASC QUES0003.ANS and so on ... There is also a "last" display file which can optionally be included in the questionnaire routine. This file is displayed to the caller after the caller successfully answers all of the questions. It might be a brief message saying "thank you for answering the questions" or something along that line. The filenames for this "last" display file are EPILOGUE.ASC and EPILOGUE.ANS. All of the files described above are placed in a special sub-directory, off the home path directory. The name of this special directory is QUESTION. For example, if your home path is C:\WR-BBS, then you would create a sub- directory named C:\WR-BBS\QUESTION. To do this, issue the DOS MKDIR command (substituting your correct home path if different): MKDIR C:\WR-BBS\QUESTION You are then ready to add the question files to the new sub-directory. When a caller selects (Q)uestionnaire from the main menu, WR-BBS checks for the existence of the sub-directory named QUESTION, then for any question files. It then displays the first question file, gets the caller's response, displays the second question file, the caller responds again, and so on. NOTE: For proper operation, use consecutive numbers in your question filenames - don't skip any numbers. Caller options during the questionnaire: The caller can answer the question by typing a one line response. The caller can skip the question by pressing <ENTER> alone. The caller can abort the questionnaire by typing a star (*) and then pressing <ENTER>. The answers left by callers are stored in an ASCII text file named ANSWERS.TXT. This file is located in the QUESTION sub-directory. If the caller skips any questions while proceeding through the questionnaire, ANSWERS.TXT will have an entry "NO RESPONSE FROM [CALLER NAME]". If the caller aborts the questionnaire, it will be recorded in ANSWERS.TXT as "[CALLER NAME] ABORTED QUESTIONNAIRE". If the caller drops carrier during the questionnaire, this will also be recorded in ANSWERS.TXT, if the loss of carrier is detected at any time except when a question file is being transmitted. WRBBSLOG.TXT will also have a record of dropped carriers. As subsequent callers complete the questionnaire, their responses are appended to ANSWERS.TXT - this file grows with each activation of the questionnaire facility. You may wish to include some kind of automatic archiving routine in MIDNIGHT.BAT or an event, which moves ANSWERS.TXT to another location. WR-BBS automatically creates a new ANSWERS.TXT file if none is found. See section 15 for more details on MIDNIGHT.BAT, and section 17 for more details on configuring events. =========================================================================== SECTION 19 THE ACTIVITY LOG =========================================================================== WR-BBS creates and updates a log file named WRBBSLOG.TXT, located in the home path. The following are some examples of types of activity are recorded in WRBBSLOG.TXT: - Callers logging in. - Callers changing their passwords. - Callers requesting various features throughout the WR-BBS menu system. - Callers making mistakes, or selecting unauthorized features. - Callers dropping carrier. - File transfers. - WR-BBS being started or re-started. - WR-BBS being shut down. - Errors that occur during WR-BBS startup or shutdown. - Errors that occur during WR-BBS runtime. - Errors detected by the W-TREE Database Manager. - System status messages. - SysOp administration activity. WR-BBS keeps only one log file - there is no separate file for errors. Since WRBBSLOG.TXT is an ASCII text file, you can use a third party utility (or even something as basic as DOS's FIND) to search for specific strings in the log file. If WRBBSLOG.TXT does not exist, WR-BBS creates a new one when it next needs to record an event. If WRBBSLOG.TXT does exist, WR-BBS appends event information to it. You will probably want to implement some scheme to copy the contents of WRBBSLOG.TXT to an archival location at regular intervals. The sample MIDNIGHT.BAT file gives an example of how to do this. Should WR-BBS experience a "fatal" error during runtime, the details of that error will usually (but not always) be logged to WRBBSLOG.TXT. Some errors are so severe that no file I/O is possible, and therefore they cannot be logged. If a fatal error occurs and is logged, the information in WRBBSLOG.TXT will be helpful in determining exactly what went wrong. Particularly important are the Process ID and System Status, listed as "PID" and "SS" in WRBBSLOG.TXT. If you contact the author for support involving a fatal error, this information will be most helpful in resolving the problem. =========================================================================== SECTION 20 THE "DOWN" OPTION =========================================================================== WR-BBS has a handy feature built-in for "downtime" operation. This allows you to configure WR-BBS to answer calls, but not allow callers to log on. Instead, callers are presented with a message (which you create), and the call is then terminated. Why would you want to run your WR-BBS in "downtime" mode? Perhaps you are in the middle of overhauling all your screens, and you don't want the computer to get tied up with caller sessions. If you plan to have your WR- BBS down for any period of time, this feature will be useful - compared to the alternatives. Callers are much more receptive to a "downtime" message that getting a constant busy signal or ringing. On the other hand, if most of your callers use long distance to call your board, it would probably be more polite to not use the "downtime" option when the board is down - callers are not charged for calls to busy or unanswered lines. How to configure WR-BBS for "downtime" operation. 1. Create a set of screen files explaining that the system is unavailable. See section 7 for instructions on creating screen files. Your announcement should be only a few lines long - never more than 20 lines. Create one for each type of caller with these special names - DOWNTIME.ASC and DOWNTIME.ANS. Put these files in the same directory as all of your other screen files. 2. Stop WR-BBS if it is running, by pressing ALT-Q from the "waiting for calls" screen. 3. Start WR-BBS by typing this special command line: WRBBS /DOWN When WR-BBS is in "downtime" mode, any incoming call is answered as usual, but instead of logging in the caller, WR-BBS displays the special DOWNTIME.ASC or DOWNTIME.ANS screen. The caller is then prompted to press a key to end the call. If the caller does not press a key, the call terminates automatically after 30 seconds. To resume normal WR-BBS operation, stop WR-BBS with ALT-Q from the "waiting for calls" screen, then type WR to start WR-BBS in normal mode. =========================================================================== SECTION 21 WHILE A CALLER IS ON LINE =========================================================================== There are some special keys available to the SysOp while a caller is logged on. If the caller attempts to press these keys - they have no effect - only the local console can activate these features: PGUP - Adds five minutes to the callers time. PGDN - Deducts five minutes from the callers time. ALT-X - Immediately forces the caller off - abruptly! In order to use these keys, the caller must be in one of the menus (Main Menu, Message System, Files Library). To activate one of the special keys, hold it down until the desired effect is observed (it may take a second or two). Remember that when a caller is logged on, the local (console) keyboard is active along with the callers. This allows you to type things for the caller (to show a confused caller how to do something, for example). This also means that you can "coerce" a caller to one of the menus by using the regular command keys (which they could use), and then press one of the special keys described above. =========================================================================== SECTION 22 EXTERNAL FILE TRANSFER PROTOCOLS =========================================================================== WR-BBS does NOT include any file transfer protocols in the program file. All file transfer activity is controlled by an external file transfer utility program(s) that you supply. There are a number of external file transfer protocol programs available from BBS's that specialize in communications and BBS utility files, including the WR-BBS Headquarters BBS. From some BBS's you can download public domain (free) copies of the Xmodem and Ymodem file transfer utilities. Other, more proprietary protocols can be obtained for a modest registration fee on a shareware basis. The WR-BBS Headquarters BBS uses DSZ by Omen Technology, Inc., which is an excellent multi-protocol file transfer utility. It includes an authentic version of Zmodem, true Ymodem, Xmodem, and many variations of those protocols, including streamers such as Ymodem-G for use with error- correcting modems. It is a powerful program with good documentation, and well worth the registration fee. The author is a registered user of DSZ for use in operating the WR-BBS Headquarters BBS, but has no affiliation with Omen Technology, Inc. or the authors of their products. You can obtain more information on DSZ or download an evaluation copy of DSZ from Omen's BBS at (503) 621-3746. Remember to register any shareware programs such as DSZ if you continue to use them after the evaluation period. After obtaining one or more file transfer utilities, it is necessary to understand how WR-BBS invokes file transfers. WR-BBS uses a batch file to control all file transfers. This batch file is named WFILEXFR.BAT. A sample copy of WFILEXFR.BAT is included with the WR-BBS archive. If you use DSZ, you can probably use that batch file as is, or with minimal modification. The batch file WFILEXFR.BAT uses the parameters to branch to defined labels, based on what WR-BBS passes. If you are unfamiliar with the concept of replaceable parameters (command line variables) in batch files, see your DOS manual for more details. WR-BBS passes five parameters to WFILEXFR.BAT when a file transfer is requested: Parameter 1: A single character, which represents the communications port that WR-BBS has active at the time of the file transfer. This is the port that you defined in WRCONFIG.SYS with the "PORTNUMBER=" keyword. Some file transfer programs need to know what port they should use, especially if WR-BBS is not set up to use COM1. Possible values that may be sent by WR- BBS are "1" for COM1, "2", for COM2, "3" for COM3, "4" for COM4, or "N" in the event of a local logon that does not involve the modem (from the local console). Parameter 2: A string that represents the caller's connected baud rate. WR-BBS might send "300", "1200", "2400", "9600", etc. If the caller is "local" (logged in from the local console), then the word "LOCAL" will be sent in lieu of the baud rate. If you have an error-correcting modem, and you have set LOCKDTE=Y in WRCONFIG.SYS, then WR-BBS will pass the locked DTE speed as the second parameter instead of the caller's connect speed. This is because the file transfer utility needs to work at the modem's speed, not the caller's speed (which is usually less). An error-correcting modem compresses data and handles the buffering, so it is okay, for example, to have the file transfer utility cramming data into an error-correcting modem at 38400 baud, while the caller is connected at 2400 baud. Error-correcting modems use flow control to keep the data from overflowing when there is such a speed difference - thus, it is very important to configure your file transfer program for the proper flow control when using an error-correcting modem. (Some file transfer programs, including DSZ, handle the flow control automatically). Parameter 3: Either the string "RECEIVE" or the string "SEND". If a caller has requested an upload to your WR-BBS, then your system will "RECEIVE" the file. If a caller requests a download, then your system will "SEND" the file(s). Parameter 4: A string - the protocol keyword, as defined in WRCONFIG.SYS. This will make more sense when the entries you need to make in WRCONFIG.SYS are explained a few paragraphs later. Parameter 5: The name of the file to be transferred, or the name of a file list (which is a text file containing a list of file names). In the case of a single file transfer, the actual file name will be sent as parameter number five. If there are two or more files involved, WR-BBS will create a text file named DL.LST, in the home path, and pass DL.LST as the fifth parameter. Many file transfer utilities, such as DSZ, expect a "list file" to tell them when multiple files are to be transferred. WR-BBS allows a caller to select up to 99 files for batch download at one time. If the caller selects more than one (and the file transfer protocol allows batch transmission), then WR-BBS puts all of the file names, one per line, in the text file named DL.LST, then invokes WFILEXFR.BAT, using DL.LST as the fifth parameter. Parameter 6: A numeric string ("1" to "99") which represents the number of files being transferred. Although WFILEXFR.BAT does not use this parameter, it is sent by WR-BBS to provide compatibility with file transfer utilities that expect a file count on the command line. Here are some examples of the way that WR-BBS calls WFILEXFR.BAT when a file transfer is requested by a caller. In each of these examples, we will assume that WR-BBS is configured for COM1: Example one - The caller is connected at 1200 baud, and has requested an Xmodem-CRC download of the file HELLO.TXT ... WFILEXFR 1 1200 SEND XMODEMCRC HELLO.TXT 1 Example two - The caller wants to upload NEWFILE.ZIP, and is connected at 2400 baud. The caller has chosen SuperVmodem (a fictitious protocol, for example purposes only) ... WFILEXFR 1 2400 RECEIVE SUPERV NEWFILE.ZIP 1 Example three - the caller is connected at 2400 baud, and has requested a Zmodem download of these three files: ONE.ZIP, TWO.ZIP, and THREE.ZIP ... WFILEXFR 1 2400 SEND ZMODEM DL.LST 3 Example four - the caller has requested an Xmodem-1K download of BIGFILE.ARJ, and is connected at 9600 baud (error-free), with the DTE locked at 38,400 baud ... WFILEXFR 1 38400 SEND XMODEM1K BIGFILE.ARJ 1 Where does WR-BBS get the protocol keywords, such as XMODEMCRC, SUPERV, ZMODEM, and XMODEM1K found in the above examples? Those come from your entries in WRCONFIG.SYS. Remember that WR-BBS does not have any file transfer protocols available, until you define what they are and what they can do - in WRCONFIG.SYS. The proper syntax for file transfer protocols in WRCONFIG.SYS is: 1. The keyword PROTOCOL= 2. The NAME of the protocol, as you wish to have it displayed to callers. The name you enter here will be the name shown in the list of available protocols presented to the caller when they request a file transfer. This information is NOT passed to WFILEXFR.BAT or used for any other reason except to inform the callers that the protocol is available for use. 3. A pipe "|" symbol. 4. The protocol's KEYWORD, which will be passed to WFILEXFR.BAT. This string can be 1 to 16 characters long, and cannot contain spaces or any of the following characters: @ < > , + ; $ % This information is NEVER displayed to the caller, and it is only for use by WFILEXFR.BAT, to differentiate one protocol from another. To make life easier, you should choose a protocol KEYWORD that relates somehow to the name of the protocol. See the examples below. 5. Another pipe "|" symbol. 6. The word "SINGLE" for single-file protocols, or the word "BATCH" for multiple-file protocols. 7. Another pipe "|" symbol. 8. A list of 1 to 26 letters (A to Z), representing the classes of service permitted to use that protocol. (Port # 1 and 2400 baud used for both examples below) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Example one: This (fictitious) protocol is called "SpeedyModem X", and is capable of multiple file transfers. The SysOp wants it to be available to all callers in all classes of service. The SysOp also wants the keyword "SPEED" to be passed to WFILEXFR.BAT when a caller selects this protocol. Here is what the entry in WRCONFIG.SYS would look like: PROTOCOL=SpeedyModem (Real Fast)|SPEED_M|BATCH|ABCDEFGHIJKLMNOPQRSTUVWXYZ (Callers will see this protocol listed as "SpeedyModem"). Here is what WR-BBS would send to WFILEXFR.BAT as command line parameters if a caller chooses to download PICTURE.ZIP ... WFILEXFR 1 2400 SEND SPEED_M PICTURE.ZIP 1 Here is what WR-BBS would send to WFILEXFR.BAT as command line parameters if a caller choose to download ONE.ARJ, TWO.ARJ, and THREE.ARJ ... WFILEXFR 1 2400 SEND SPEED_M DL.LST 3 Here is what WR-BBS would send to WFILEXFR.BAT as command line parameters if a caller told WR-BBS they wanted to upload GOODFILE.ZOO ... WFILEXFR 1 2400 RECEIVE SPEED_M GOODFILE.ZOO 1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Example two: This is for the Xmodem-CRC protocol, one of the most common (but not the most efficient) file transfers available. It is capable of single file (one at a time) transfers only. The SysOp wants it to be available to all classes of service. The SysOp has decided to use the keyword XMC to designate Xmodem-CRC for configuration and control purposes (in WRCONFIG.SYS and WFILEXFR.BAT). Here is what the entry in WRCONFIG.SYS would look like: PROTOCOL=Xmodem-CRC|XMC|SINGLE|ABCDEFGHIJKLMNOPQRSTUVWXYZ (Callers will see this protocol listed as "Xmodem-CRC"). Here is what WR-BBS would send to WFILEXFR.BAT as command line parameters if a caller chooses to download PICTURE.ZIP ... WFILEXFR 1 2400 SEND XMC PICTURE.ZIP 1 Here is what WR-BBS would send to WFILEXFR.BAT as command line parameters if a caller told WR-BBS they wanted to upload GOODFILE.ZOO ... WFILEXFR 1 2400 RECEIVE XMC GOODFILE.ZOO 1 As you can see, WR-BBS knows the external protocols by two identifiers - the first one is the "nice looking" string that is presented to callers, and not used anywhere else by WR-BBS. The second identifier is the protocol keyword which is passed to WFILEXFR.BAT as a parameter. Working with your protocol's documentation and this section, you can customize your file transfer protocol handling. When selecting a file transfer protocol utility, and when designing your WFILEXFR.BAT file (if you choose to modify it), you should keep these things in mind: 1. You should use a file transfer protocol that allows you to restrict incoming files. DSZ does a good job of this. If WFILEXFR.BAT tells DSZ to receive a file named GOOD.ZIP, and the called instead transmits BAD.TXT, DSZ will name the file GOOD.ZIP. The "restrict" option on the DSZ command line also keeps caller from accidently (or intentionally) sending files with pathnames that would locate them in a directory other than the one you want to receive them in. 2. Your file transfer protocol should delete any partial files. This will prevent subsequent callers from downloading aborted upload segments. 3. If you do not want callers to have access to new uploads until you have tested / cataloged them, set the class of service (in WRCONFIG.SYS) for the upload area so that only the SysOp has access to it. Then, after you have checked the new files (as the SysOp), you can edit their descriptions to move them to a different file area that other callers have access to. 4. All incoming files must be written to the "uploads" directory that you specified in WRCONFIG.SYS. After an upload is completed, WR-BBS checks for the existence of the uploaded file in that directory. If the file is not found in the upload directory, the description record is deleted, and the upload is considered as failed. 5. WR-BBS checks for the existence of a file named $FAILURE in the upload directory after an upload occurs. If the file $FAILURE exists, WR-BBS assumes that the upload was unsuccessful. Your WFILEXFR.BAT file should erase any $FAILURE file before invoking the transfer, and create $FAILURE only if there is a problem with the upload. See the sample copy of WFILEXFR.BAT for details.