rOverBoard BBS Software - Version 1.9o (beta) Copyright (C) 1987 - 1990 FreeLance Programming All rights reserved FreeLance Programming / PO Box 726 / Washington DC 20044-0726 The Wizard's Workshop / 301-322-8678 / 300/1200/2400 - 24 hours Table of Contents Page # ----------------- --------- About rOverBoard i Reporting Problems/Making Suggestions i Hardware and software requirements 1 Partial feature summary 1 Command-line switches 2 rOverBoard .SCReen files 5 rOverBoard .ANSi (screen) files 7 Other rOverBoard related/created files 8 "Questionnaire" screens (REGISTER.SCR, SURVEY.SCR) 10 The Bulletin Menu 11 File listings (BBSFILES.DAT) 12 rOver's Main Menu screen 13 Operating the DOS box 14 Multitasking the DOS box 15 Editing users 16 Configuring message areas 18 Configuring file areas 20 User access control ("Access Masks") 22 Using events 25 Upgrading new users 26 The miscellaneous maintenance screen 28 The modem setup screen 30 Modem requirements & initialization 32 The Active Settings screen 34 Installation and setup 35 rOver's keyboard 37 ANSI & ASCII support 38 rOver's credit system; what it is and how it works 39 Function keys while "spying" on users 40 rOver's doorway system 43 rOver's door interface record 45 EMS memory utilizatoin 47 Outgoing calls explained 48* Miscellaneous notes 49 * - Not yet documented. rOverBoard BBS Software Version 1.9 i rOverBoard is a user-supported software product from FreeLance Programming. It is currently in a late beta-test phase; mostly due to a few uncompleted features (like the docs). There are no known bugs outstanding at the time of this release. Of course, this in no way means there aren't any. rOver's earlier beta versions have been running since November, '87, and the code is fairly solid. I am not requesting donations for this version; however, if you wish to send $$$ to encourage me to continue, you will receive a) more rapid help on questions, and b) a discount on the first production version. Suggestions for improvements are ALWAYS welcome. I can be contacted (as sysop) on: The Wizard's Workshop (301)-322-8678 (free; new users ok) (301)-322-2115 ($$$; no new users; MNP!) 3/12/24 24hrs Or by mail at: FreeLance Programming P O Box 726 Washington DC 20044-0726 If you find any bugs, or have suggestions, please contact me either on-line or by mail. Your comments CAN make a difference. The latest version of rOverBoard will, of course, always be available on The Wizard's Workshop. rOverBoard BBS Software Version 1.9 - 1 - rOverBoard requires an IBM PC/compatible with 384k minimum (640k recommended), running DOS 3.1 or higher (3.2x not recommended). The CONFIG.SYS file used to boot the machine should specify a minimum of "FILES=20", and at least 3 more for each modem (after the 1st) you intend to use. Programs run in the DOS box may require additional FILES= to be reserved for their use, as well. Although the software will run on a two-floppy machine, a hard disk is strongly recommended. Modem support is currently limited to Hayes compatibles. Some of rOver's features include: - Support for 4 modems (up to 38.4k baud) plus a "local" BBS window where the sysop can be logged on simultaneously with callers - on ONE machine, with no external multitasking software required. - Complete maintenance capabilities while the board is running, including shell to DOS, change setup/users/events/etc., upgrade new users. - The ability to support remote drop-to-DOS and door programs. - Will run invisibly in the background; all DOS access is multitasked (this feature requires a higher degree of hardware compatibility). - A space conservative design that uses fewer files and less disk space. - Speed! rOver uses in-memory hash tables for superior response times. - Positive verification security; easy to change privileges at the user or at the group level. Almost 300 individual access control switches, with 10 easily assignable pre-defined "masks" to ease global changes. - Multi-layered menus adjustable to the users' experience level. - Many file transfer protocols, including Ascii, X, Y, and Zmodem. - Transparent 'command stacking'; responses to several prompts may be stacked (D;Z;ROVER, MA0RY, etc.). The on-line help has syntax details. - The ability to re-edit previously saved messages. - Automatic msg & user deletions based on configurable time period(s). - "Notify" messages (to ALL or given user) auto-displayed at log-on time. - Intelligent welcome/bulletin screens that are displayed at logon only if they have changed since the user last logged on. - The ability to invisibly prevent unwanted files from being uploaded. - Full path support; files need not be in their 'default' directory. In addition, authorized users can access ANY file on the machine. - Much, much, more... rOverBoard BBS Software Version 1.9 - 2 - Usage: ROVER.EXE /1[p] /2[p] /3[p] /4[p] /B# /D# /U# /A /E /F /H /S /L /M[+/-] /N /P /V /X /Z All command line switches are optional, as is anything in []'s. /1[p] - /4[p] : Activate Nodes 1 - 4 (respectively) 'p' is of the form: [#] [!] [+ | - | *], where: # = Modem init speed (1=300 [default], 2=1200, 3=2400, ..., 7=38400) - = Prevents 300 (300/1200, if '!' used) baud downloads (on that line) + = Prevents 300 (300/1200, if '!' used) baud callers (on that line) * = Indicates a hard-wired (null- or no- modem) connection. This option disables baud-rate checking and prevents DTR from cycling when a user logs off. The specified init speed will be used as the baud rate. /A : Allow Doors This switch causes rOver to be started in so-called "single-image" mode. See the section on the doorway for more information about board modes and doorway use. /B# - /U# - /D# : Line Control Where # specifies a node # (1 - 4). To apply the condition to multiple ports, specify the switch once for each node (ie. /U1 /U3 etc.). /U - Callers must have "Can Use Line #" = Y to logon (to that node) /D - Callers must have "Can Use Line #" = Y to d/l (while on that node) /B - Similar to /U, except that when callers attempt to log onto a node to which they do not have "Can Use Line #" privileges, they are allowed to log on thru the BULLETin menu, which will be displayed regardless of the date(s) involved or the # of BULLETxx.SCR files. The slightly-modified BULLETin menu allows use of the G)oodbye command, but disables Q)uit-this-Menu and M)ain-Menu. Thus, the user must logoff after reading the bulletins (NO MAIL CHECKING!). /F, /S : Flicker Control rOver uses direct screen writes, which can cause "snow" on CGA monitors. These two switches eliminate such snow. Use of either switch will cause screen output to take longer. The switches function as follows: /F - Eradicates snow on _most_ writes. Screen swaps may still snow. /S - Eradicates ALL snow. You need not use /F if using this switch. rOverBoard BBS Software Version 1.9 - 3 - /I : "All IBM" Mode This switch eliminates the display of the "Is '¦' the number one" and "Do you want color" prompts when the user logs on. "Color" is always set to "Y", while ASCII (the 1st prompt) is set to "Y" for callers connected at 8/N/1, and to "N" for callers at 7/E/1. /K : Disable Ansi Color Displays This switch prevents ANSI colors from being displayed on the local monitor, while still allowing the remote user to see them. /L : Log File Control By default, rOver creates/appends BBSLOG.DAT, a file which contains a configurable set of information about system and user activity. Use of the /L switch suppresses this feature. /M[+/-] : Mail Checking By default, rOver gives callers the opportunity to check for their new mail when they log on. This switch functions as follows: /M : Same as the default; the user is prompted for a y/n response /M- : The prompt is not displayed, and the mail check is NEVER done /M+ : The prompt is not displayed, and the mail check is ALWAYS done (When using this option, ^k/^c/^x will NOT interrupt the search.) /N : Upload Log File Control By default, rOver also creates/appends UPLOADS.DAT, a file containing whodunit info for uploaded files. The /N switch suppresses this feature. /P : Private Board When this switch is used, new users are not allowed to log-on. Instead, they are shown the registration questionnaire (REGISTER.SCR), if any, and are then immediately logged off. Be aware that if the user calls back, he/she will no longer be considered new, and WILL be allowed to log on. Be sure that you have set up your access masks as appropriate! To make the board totally private, use /U1 - /U4 (as appropriate). /V : Visual Indicator While in DOS when using the /Z switch, this switch will provide visual confirmation that rOver is still getting time in the background (while in text modes only). rOverBoard BBS Software Version 1.9 - 4 - /E : Extended ASCII in .ANS files Users who request ANSI color/graphics are normally shown the .ANS screens (where present), rather than the .SCR versions. This switch forces users who connect at 7/E/1, or who indicate the inability to display extended ASCII characters to see the .SCR files, even if they have requested ANSI support. Use this switch when your .ANS screens contain a lot of extended ASCII characters, to avoid having them mangled by the extended ASCII translate table. /X : Autoexec the DOS box This switch will cause rOver to shell to DOS and execute AUTO-DOS.BAT immediately after the board starts. This command, (which is mutually exclusive with, and will override, the /A switch), will not be executed if there is < 32k of free memory. AUTO-DOS.BAT must exist in the rOver startup directory. This command should NOT be used unless /Z is also specified, though this requirement is not enforced in code. /Z : Multitasking When this switch is used, rOver will continue to run in the background while DOS is being accessed (F1: Dos Cmds). See the section on multi- tasking for more information on this feature. /H : EMS Using this switch will cause rOver to make use of EMS memory for some of its run-time memory requirements. If no EMS memory is found, use of this switch will generate a warning message. If insufficient EMS memory is found, the available EMS memory will be utilized, and subsequent memory allocation requests will be filled from conventional memory. See the sections on EMS and multitasking for more information and potential conflicts. Note that many switches may alternately be controlled via system events or the "active settings" screen (F10 from the Main Menu). Also, note that the "active settings" are re-computed each time the program starts (from the cmd line switches + any events that were scheduled), NOT saved across each execution. During this re-computation, scheduled events will override any comparable command line switches. This re-computation, which calculates what the board should look like if it had been running continuously for at least a week, is also performed each time the events are modified via F6:Events. The use of a .BAT file to start rOver is _strongly_ recommended, both to avoid having to remember all these switches as well as to trap various return codes. The RUN.BAT file included in ROVER.ZIP is provided as an example of such. rOverBoard BBS Software Version 1.9 - 5 - rOver can display a variety of screens when a user logs on. Each screen is a separate text file, with optional embedded ANSI commands (see the section on ANSI support for more info). ^C, ^X, and ^K are disabled while displaying "required" screens when the user logs on, but function normally should the user re-display a screen. In general, and with the exception of WELCOME1, rOver will not show screens to any user who has already seen them, unless requested via the MAIN Menu. This can be changed by setting the file date of the .SCR file to a far future date, in which case rOver will think it is always new for each user. WELCOME1.SCR - This is the opening banner; displayed just after the ASCII and ANSI support prompts. It, like all .SCR files, is optional. WELCOME2.SCR - This is the 'welcome screen', displayed after the "last called" message, or when selected from the MAIN Menu via the W)elcome command. If this screen is not present at system start-up, the W)elcome command will be disabled. BULLETIN.SCR - This screen functions either as a single bulletin (ala the welcome screen) or as a menu of available bulletins. It is displayed after the W)elcome screen, or when selected via the B)ulletin command (also disabled if no BULLETIN.SCR at startup time). See the section on the BULLETIN Menu for more info. BULLET??.SCR - Where ?? can be 1 - 99. When BULLETIN.SCR is used as a menu of available bulletins, these files make up the individual bullets. See the section on the BULLETIN Menu for more information. HINTS.SCR - This screen is only displayed in response to the H)ints command on the MAIN Menu. If it is not present at system start-up, the H)ints command will be disabled. NEWUSER.SCR - This special screen is only displayed for new callers. It is displayed immediately after the initial user setup prompts, and just prior to REGISTER.SCR (if applicable). LOGOFF.SCR - This optional screen is sent immediately prior to the "Logging xxxxx OFF" message that precedes disconnect. REGISTER.SCR - This is a 'questionnaire' screen which may contain prompts for user input. See the section on questionnaires for information on the contents of this screen. The presence or absence of this screen controls new-user access, as follows: If this screen is is not present, or the user successfully completes it, the user is assigned default access mask #1. If it is present, and the users does NOT complete it, he/she is assigned default access mask #10. rOverBoard BBS Software Version 1.9 - 6 - (rOverBoard's .SCR files, continued) SURVEY.SCR - This is also a 'questionnaire' screen, using the same commands as the above screen. It is displayed only in response to the A)nswer-Survey command on the MAIN Menu, and omission of the screen will disable that command. NOUSEx.SCR - These screens work in combination with the /Ux switch(es). If a new or unauthorized user attempts to log onto a restricted node, the appropriate NOUSEx.SCR will be displayed, and the user will then be logged off. Use NOUSE1.SCR for Node 1, NOUSE2.SCR for Node 2 (etc.), as desired. Note that if the line is not restricted, these screens are not displayed. DOORWAY.SCR - This screen serves to list all the doors that are available (if any). It is displayed in response to the L)ist-Doors command of the DOORs menu. MSGxx.SCR - Each msg area can have a MSGxx.SCR associated with it (where xx is the # of the msg area, 0 - 63). This screen will be displayed the first time a caller enters that msg area. If the caller uses the A;? or A;?? command to get a list of the available areas, this screen will also be displayed for the next area entered (if one exists for that area), regardless of whether or not the user has already seen it during this call. FILExx.SCR - Each file area can have a FILExx.SCR associated with it, just as with the message areas. This screen will be displayed each time the A)rea-Info command is used to get information on a given file area. .SCR - For each menu, a .SCReen file bearing the name of that menu may be created. If a user has help level 4 selected, this screen will be displayed in place of the normal rOver menu. The screen will be followed by the standard help level 0 prompt for that menu. If no screen exists for a given menu, help level 4 is equivalent to help level 3. Valid menu names for .SCR files are: MAIN, CHANGE, MAIL, READ, EDIT, STATS, CONFIG, USERS, ZIP, BULLETS, FILES, and USERLIST. rOverBoard BBS Software Version 1.9 - 7 - Although .SCR files do support some ANSI color/graphic commands, that support is limited. rOver strips all ANSI codes from the outgoing data stream for users who do not want color/graphics, but this would cause the the resulting output to be garbled if the stripped ANSI codes consisted of cursor movement commands (see the section on ANSI support for more info about valid ANSI commands). In order to provide full ANSI support, including the user of cursor movement commands, rOver now supports the concept of .ANS screens. Any .SCR file (except REGISTER.SCR and SURVEY.SCR) may now have a .ANS counterpart. The .ANS screen (if it exists) is displayed for users who select ANSI support, while the .SCR file is displayed for users who do not (or when the .ANS screen does not exist). The .ANS screen files may contain almost all the codes defined by the ANSI standard (see the section on ANSI support for more information). Note that if an .ANS screen is created, the equivalent .SCR file MUST also exist. If this is not true, the .ANS screen will, in most cases, simply be ignored. In order to better understand these capabilities, here are some sample scenarios involving various combinations of WELCOME1.SCR / WELCOME1.ANS: 1) WELCOME1.SCR exists, but has no ANSI codes. WELCOME1.ANS does not exist. In this case, all users will see the same thing, regardless of whether or not they have selected ANSI support. 2) WELCOME1.SCR exists, with ANSI codes. WELCOME1.ANS does not exist. In this instance, callers who have selected ANSI support will see the complete WELCOME1.SCR file. Users who have NOT selected ANSI will see this file sans all ANSI commands. 3) WELCOME1.SCR exists, w/ or w/o ANSI. WELCOME1.ANS exists (w/ ANSI). Users who have selected ANSI support will be shown the WELCOME1.ANS file. Users who have NOT selected ANSI will see the WELCOME1.SCR file, with all ANSI codes (if any) removed. For users who have selected ANSI support, rOver will now clear the screen before starting the display of any .SCR/.ANS file. If any possibly unread text remains on the screen, rOver will first prompt the user to "Press any key to continue", and will wait for a keypress before performing the screen clearing. For users who have not selected ANSI, no such screen clearing is performed, and the "Press any key to continue" prompt will never appear. rOverBoard BBS Software Version 1.9 - 8 - In addition to the .SCR files listed above, rOver uses and/or creates various files, as described below. Except where otherwise noted, all files must be in the default directory when the system is started. SETUP.DAT - This file contains all configuration and statistical info for the entire board. It is REQUIRED for use of rOver OR the maintenance utility. This is NOT a text file. BBSFILES.DAT - This is the text file containing the entries for ALL files in ALL areas. See the section on file listings and the included sample file for more information about this file. BBSFILES.IDX - This is a quick-access index to BBSFILES.DAT that contains name/date/size information for each file. It is automatically rebuilt whenever the BBSFILES.DAT file is edited, or when the /X switch is used. It is NOT a text file. USER.DAT - This is the user file. If it does not exist, it will be created at start-up time. This is NOT a text file. BBSLOG.DAT - This is the system log of all activity (except that suppressed via the log-level feature). It is created/appended to unless the /L log-suppress switch is used. UPLOADS.DAT - This is the system log of all upload activity, separated for convenience. It can be suppressed by using the /N switch. REGISTER.DAT - This file contains user answers in response to REGISTER.SCR. If REGISTER.SCR exists, this file is created/appended to, as well as REGISTER.IDX (which is also rebuilt by the /X switch). APPROVED.DAT - As users are upgraded, their answer sets are 'deleted' from REGISTER.DAT, and transferred to APPROVED.DAT. The maintenance utility will then remove the 'deleted' sets from REGISTER.DAT. SURVEY.DAT - This file contains user answers in response to SURVEY.SCR. It file is created/appended to, if SURVEY.SCR exists. rOverBoard BBS Software Version 1.9 - 9 - rOver also makes use of some .BAT files (not counting the .BAT that can be used to start rOver), as applicable. Those files, and their uses, are: AUTO-DOS.BAT - If the /X command line switch is used, the first thing rOver will do immediately after starting up is shell to DOS and execute this file. If the multitasking switch is being used, all modem lines will continue to run in the background. The .BAT file can EXIT back to rOver or not, as circumstances require. DOORWAY.BAT - When the user executes a drop-to-dos or doorway program from the DOORs menu, rOver responds by shelling that node to DOS and executing this file. Passed to the .BAT file will be several parameters that can be used, such as the # of the door to be executed, the COMx: port to be used, etc. See the section on doors for more information about this file. MSG##.DAT MSG##.IDX - Where ## is a two-digit, zero-filled message area number. One of each of these files is used for each message area, and will be created if necessary. These files must be in the sub-dir specified as the "Mail Path" in the setup options (F8 - Misc. Maint). This sub-directory must be created prior to running rOver. (The default sub-dir in the distributed SETUP.DAT is always the current dir - ie., ".\", which MUST be changed before the DOS box can be safely used, as with the .SCR path.) Note that these are the only rOver-maintained .IDX files that must not be deleted. Unlike all other .IDX files used by the software, these files cannot be reconstructed from the .DAT file(s), and should NEVER be deleted. rOverBoard BBS Software Version 1.9 - 10 - Questionnaire Screens: Questionnaire screens (REGISTER.SCR and SURVEY.SCR) are formatted text files that implement a mini-script language. The 1st char of every line is either a space or the start of a 'command'. The line (minus the 1st char) is always displayed before the action of the command (if any), except in the case of comments. rOver currently accepts the following commands: ? : Prompts the user for [Y,n] input. If the user answers N, the screen is aborted. In the case of REGISTER.SCR, the user is then assigned access mask #10. @ : This character in column 1 causes the user's name to be affixed to the output answer set. If using the built-in upgrade facilities in conjunction with REGISTER.SCR, this command _must_ appear in the questionnaire. ! : Prompts for up to 40 chars of input. If the text following this command exceeds the width of the user's screen - 40, a is generated, and the input prompt moved to the next line. #x : Essentially the same as the ! input prompt, except that input always starts on a new line, and up to x lines of input are allowed. The first blank line ends the prompting. x is required, and must be from 1 to 7. For more information about questionnaire screens, see the sample REGISTER.SCR and/or SURVEY.DAT screens in the distribution package. You may wish to experiment with these screens until you are happy with the results. Note that these are the only two .SCReen files that do not support .ANS counterparts. Also, these two files are loaded into memory when rOver starts, meaning that changes made to them while rOver is running while not take affect until rOver is restarted. All other .SCR / .ANS files may be changed "on the fly" (though callers may be temporarily unable to access them while they are being edited). rOverBoard BBS Software Version 1.9 - 11 - The Bulletin Menu : rOverBoard offers three approaches to bulletins, as follows: - Option #1: No BULLETIN.SCR at system start-up If this file is not found during system start-up, rOver runs sans bulletin. Nothing is displayed in its "place" in the user logon sequence, and the B)ulletin-Menu command (from the MAIN Menu) is disabled. - Option #2: Num bulletins = 0 One of the fields on the F8 Maintenance screen is #-bulletins. If this field is non-zero, rOver uses option #3 (below). Otherwise, rOver treats the bulletin screen exactly like the welcome screen. It is displayed during the logon process, just after the welcome screen (if it has been modified since the user's last call, or this is a new user), and can be re-displayed via the B)ulletin-Menu command. - Option #3 - Num bulletins > 0 When the #-bulletins has been set to a non-zero value, rOver assumes that BULLETIN.SCR is a menu of available bulletins, from 1 - #-bulletins. Each of these "sub-bulletins" is stored in a separate text file named BULLET?.SCR where ?? is the number of the bulletin (ie., BULLET1.SCR, etc.). The max. number of such sub-bulletins that may be specified is 99. After the main BULLETIN.SCR is displayed, rOver displays the BULLETin Menu, rather than continuing, as in option #2 (above). When using sub-bulletins, the date that is checked to determine whether or not to display the bulletin when the user logs on is the MOST RECENT date of any of the BULLET?.SCR or BULLETIN.SCR files. An example of the use of sub-bulletins might be as follows: File: Contents: BULLETIN.SCR: Bulletin Menu: This is the list of available bulletins you can read - #1: How to get access #2: Why use Zmodem BULLET1.SCR: How to get Access Here you could list your access requirements BULLET2.SCR: Zmodem! Zmodem is a better protocol because ... I encourage you to experiment with these screens to gain a better under- standing of how they operate. They are simpler to use than to describe. rOverBoard BBS Software Version 1.9 - 12 - File Listings: All file entries and descriptions are kept in BBSFILES.DAT. Each line in this file must be in one of the following formats. Other lines are ignored. Valid Line Formats: xx Informational Message xx FILENAME MM/DD/YY XXXXX Uploader;Description Where: xx = A valid area # (00 - 63); both digits required FILENAME = The name of the file ([d:][path\]name.ext) MM/DD/YY = The date the file was originally uploaded XXXXX = # of times the file has been d/l'ed (all 5 digits req'd) Uploader = The alias of the person who uploaded the file Description = The description of the file The area # must be followed by a single space for file entries or a double space for info msgs. Info msgs are comments that appear along with the files in the L)ist-Files display; they are otherwise invisible. The file name must be followed by a single space. The Uploader and Descr. fields must be separ- ated by a single semi-colon. Uploader and Description are the only optional fields; if they are missing the semi-colon is still required. The #-times d/l'd field must be a 5-digit number, with leading zeroes. If the actual file date is greater than the upload date, it is used for N)ew-Files checking. U/l dates (which must be MM/DD/YY) of 01/01/80 imply no uploader information. Each file area has a default drive/dir used to locate the files that are in in that area. If the entry in BBSFILES contains drive and/or dir info, this dflt is ignored. Such "extended" entries must be FULLY qualified. This is all transparent to the user, who sees only the base name/extension. See the section on File Areas for more information about the "special" file areas (areas #0 and 63). When adding file areas, note that any files that were already in BBSFILES.DAT for that area will _not_ be "found" until after such time as BBSMAINT is run to rebuild the BBSFILES.IDX file. Files P)ost'ed to new areas, however, will be accessible immediately. A sample BBSFILES.DAT is included in the distribution package. Using this as a model, create a BBSFILES.DAT file of your own, then use rOver to view the results. Or, start with no BBSFILES.DAT, and P)ost a few files to each area for use as a model. As usual, experimentation is encouraged. The index file: BBSFILES.IDX is a static image of the index that rOver uses to speed files searches. Editing BBSFILES.DAT will require that BBSMAINT be used to rebuild this file before re-starting rOver. rOverBoard BBS Software Version 1.9 - 13 - The Main Menu screen: After some startup message (and a brief pause to allow the sysop to read them, rOver displays the Main Menu. This menu has several choices for board and user maintenance and configuration. Pressing an Fkey from F1 - F10 will enter the indicated portion of the software. Each of the ten available sections is documented separately further below. Pressing PgUp or PgDn while viewing this screen will cycle thru the available "views" (the Main Menu, the "local console", and one window for each modem installed). Pressing ESC from this menu will result in the board being shutdown (after verification of your selection). If there are users logged on (other than to the local console), a warning is displayed when this option is selected. The Main Menu screen reserves 4 lines for displaying a brief summary of callers on any (remote) nodes. Lines for uninstalled nodes are simply left blank. On the upper right corner of this screen, rOver will display the current date and time. This clock display is available only on the Main menu, and only if the /F and /S command line switches (flicker control) are not used. This time display is updated once every 11 "cycles" (complete interations thru rOver's master loop), and thus can serve as a rough measure of system performance. If the clock is correctly updated once a second, this means that rOver is performing at least 11 "loops-per-second", which should be sufficient for reasonable user reponse time. If the clock is NOT being updated each second, this is an indication of heavy system load. This can be true especially when users are checking for mail. rOverBoard BBS Software Version 1.9 - 14 - The DOS box: Pressing F1 from the MAIN Menu results in a prompt where DOS commands can be entered. Pressing ENTER executes the command, while ESC returns to the Main Menu. If ENTER is pressed and no command has been entered, rOver will shell to the DOS prompt. Type EXIT at the DOS prompt (and press ENTER) to return to rOver. If a command was entered, rOver will automatically return to rOver when the command is complete. To give you time to see the output of your command (if any), rOver will pause just prior to any such automatic returns, display three asterisks in the lower left corner of the screen, and wait for you to press any key before redrawing the screen. The board resumes "normal" operations when the asterisks appear, NOT when the key is read. Note that the BBS cannot allocate conventional memory while in DOS. If the current 'block' of user or file index pointers is full, and an attempt is made to add another (a new user or an upload/post), the attempt will fail with an appropriate error message (ie., "No space for new users" or "No space for upload. Cannot save your file". In the latter instance, the file _is_ saved on disk and in BBSFILES.DAT, it is simply inaccessible until the next time BBSFILES.IDX is rebuilt. The DOS-box command prompt displays the number of slots available for new users/files before memory allocation will be required. If you have enabled EMS memory, these 'blocks' will attempt to be allocated in EMS, rather than conventional, memory. If the allocation succeeds, the above paragraph does not apply. However, when all available EMS memory has been exhausted, rOver satifies subsequent allocations from conventional memory, so use of EMS may not totally eliminate the possibility. As with using any DOS shell, do not install TSR (Terminate-Stay-Resident, or "pop-up") programs from rOver's DOS box. Programs that search for lost clusters (like CHKDSK), or do other direct disk manipulations should be avoided. Later versions of DOS may restrict your access to files used by rOver while in the DOS shell. In any event, you must NEVER attempt to alter (ie., edit, rename, delete, etc.) any of rOver's files while rOver is running. Viewing these files with a read-only utility such as LIST is ok with rOver, but your version of DOS might object (especially if you are running SHARE). Also, NEVER attempt to run BBSMAINT from the DOS box, as this will adversely affect rOver's data files. rOverBoard BBS Software Version 1.9 - 15 - Multitasking the DOS box: If you are using the /Z command line switch, all DOS activity is done while rOver continues to run silently in the background. If you are NOT using this switch, accessing the DOS box will leave all callers in a state of suspended animation until the DOS box is exited. For this reason, it is not advisable to use the DOS box while callers are on if the multitasking feature is not being used. While in the DOS box and not multitasking, you should also be prepared to return to rOver in the event that a call does come in, as the user would not be able to log in with the board suspended. There are a few caveats associated with multitasking. Programs that trap the disk I/O interrupt vectors (13h, 25h, and 26h) may interfere with the multitasking code. Hopefully this type of behaviour is limited to TSR programs; there should be little reason for trapping these interrupts in most programs. Programs that intercept these interrupts and then perform pass-thru operations to the old handler(s) may work correctly if the new handler is reentrant. Also, programs that trap the timer tic interrupt (8h) in the DOS box will find it ticking considerably faster than the normal 18.2 / second. As long as such programs pass the tics thru to rOver's INT 8h handler, the multi- tasking will be unaffected, although the program itself will likely have problem(s) of some sort. Programs that intercept this vector before rOver is started, or that intercept INT 1Ch (called once / second) instead will function normally. rOver may not live happily with TSR programs that steal "their" interrupts back on whatever sort of basis (usually the timer). This rather rude behaviour is fairly uncommon, since it causes problems with a lot of things, not just rOver. rOver WILL run with most TSRs - provided that they are installed BEFORE rOver is started. In the case of many pop-up TSR programs, (such as calculators and notepads), note that rOver will NOT be running while the TSR is active, even if multitasking is enabled. With multitasking disabled, rOver should have no conficts with any TSRs that does not actively interfere with rOver, and the only restrictions on programs run in the DOS box are those that apply to any DOS shell (see previous page). Multitasking should NOT be used with EMS simulators that map part of your hard disk as EMS memory, as the subsequent thrashing can greatly affect system performance (a simple page re-map becomes up to two 16k disk I/O's with such systems, and rOver can do a LOT of page re-mapping). rOverBoard BBS Software Version 1.9 - 16 - User Editing: Most of the fields in the user record can be changed directly in the user editing process. An explanation of most of those fields appears below. Note: for access mask switch definitions, see the section on access masks. Help level : See the '?' command in the USER.DOC file for more info regarding the function of the help level field. Lines on Screen: # of continuous lines rOver will display before inserting a "More?" prompt. If 0, no "More?" prompting will occur. Screen Width : # of columns on the user's screen. Used to let rOver know when to wrap long lines. Keep days : # of days to keep user between calls. Each time the user calls, their "keep-til date" is reset to the current date plus the # of keep days (unless the keep-til date is already higher than that date would be). # of calls : The # of times the user has called. # lost carriers: # of times the user has dropped carrier w/o logging off. # of timeouts : # of times the user has used up all their daily time limit. Last msg area : The last msg area the user entered. Date of 1st call : The date/time of the user's first call. Date of last call: " " last call. Last N)ew-Files : " " the user last checked for new files. Keep-Til Date : The date upon/after which the user will be deleted (by BBSMAINT). This date is reset each time the user logs on, based on the "keep days" field. Some user fields are shown as one or more of "today", "total", "limit", or "current" categories. In all cases, "current" values represent the amount of activity that has taken place during the current call (ie., the user is on-line at this time). These fields, and the categories they exist in, are: Time : (Today) Amount of time (in mins) the user has been on today. (Limit) Max. amount of time user is allowed to be on in 1 day. The "today" total is reset to 0 at logon time whenever the date of the user's last call and the current date are not the same. Credits : (Today) Credits spent so far today. This is always credits SPENT, not credits gained, which are added directly to (Total). (Total) The total # of credits available to the user. (Limit) The maximum # of credits the user can "spend" today. rOverBoard BBS Software Version 1.9 - 17 - User Editing (cont): K up : (Today) Total size of all files uploaded "today", in Kbytes. (Total) Total size of all files uploaded prior to "today", in K. K down : (Today) Total size of all files downloaded today. (Total) Total size of all files downloaded prior to today. # up : (Today) Total # of files uploaded today. (Total) Total # of files uploaded prior to today. # down : (Today) Total # of files downloaded today. (Total) Total # of files downloaded prior to today. # read : (Today) Total # of msgs read today. (Total) Total # of msgs read prior to today. # entr'd: (Today) Total # of msgs entered today. (Total) Total # of msgs entered prior to today. "Today", and "prior to today" above both reference the date of the user's last call as "today", not necessarily the current date. Then, for each message area (0-63), there is a five-digit number that is immediately followed by a "Y" or a "-". These fields are the # of the last msg the user has read in each area, and a y/n flag indicating whether or not the area is in the user's CONFIG table. rOverBoard BBS Software Version 1.9 - 18 - Message Areas: There are two msg areas used for special purposes, areas 0 and 63. These two areas have the following attributes, in addition to whatever config. options have been chosen for each area. Area #0: All comments left by users as they logoff will go to area 0, and will be private regardless of any area 0 configuration settings. If a user does not have access to msg area 0, they will not be allowed to leave a comment when logging off. Area #63: All msgs entered in area 63 will be sent to the user at logon (just prior to the MAIN Menu appearing), regardless of the state of any mail-checking options. The user does NOT need access to this area in order to receive these messages, but it is useful to have read access here, in order to re-read these msgs (as they are only sent once). This area does make a good way to enter temporary bulletin-like notices (by posting messages to All), but too many such messages soon makes logging on a tedious chore, especially for new users, who have to read a lot of screens in any event. Msg areas can be configured in a variety of different ways. The various configuration options are discussed below: Default recipient : Messages in an area can be forced to default to a given recipient. Valid values are A, S, and blank, meaning that msgs are addressed to All, Sysop, or nobody (respectively) by default. Msg demi-gods can override this restriction. Allow private mail: Indicates whether private msgs will be allowed in this area. Again, demi-gods can do as they please. Force private mail: Indicates whether all msgs (except demi-god's, or those address to "All") will be forced to be private. BBS list area : BBS list areas (which generally should be combined with a default recipient of "All") differ from normal msg areas in only minor ways, though this feature should someday include separate input prompts for applicable fields such as phone # and hours. Exclude from msg ck: The logon mail check (optionally controlled by /M) scans all msg areas by default. This switch can be used to exclude select areas from that scan. This switch affects ONLY the logon mail check, if it has not been disabled via the /M switch, or by the user saying no. rOverBoard BBS Software Version 1.9 - 19 - Message Areas (cont): Credits / msg entered : Each time a user enters a message in this area, they will get this many credits posted to their user record. Can be negative or positive. Max # days to keep msgs : This is the default # of days to keep msgs. When first entered, each msg is given a default date on which it will be deleted; that date is the current date + this # of days. # days to keep RCVD msgs: When the person to whom the msg is addressed reads it for the first time, the keep-til-date is updated to be the current date + THIS # of days. Description: This is the one-line description of the message area. It is used in displaying the list of areas, as well as in the msg area header display(s). Area access code: This field is used ONLY when adding or deleting a msg area. (Areas are deleted by using CTL-END to erase the description field.) It works differently for each action: Deleting areas: A zero in this field when the area is deleted means to delete the area with no access changes. A non-zero will cause all users and all access masks to be changed to reflect NO access for that area. Adding areas: A zero in this field when the area is created means to create the area without any access changes. A value from 1 - 63 means that all users (and all access masks) should be assigned the same access to this new area as they already have to the area # that was specified. Entering a value greater than 63 means that all users (and all access masks) should be assigned ONLY "Access area/msgs" for this area, regardless of their current access. rOverBoard BBS Software Version 1.9 - 20 - File Areas: There are also two file areas reserved for special purposes, and they are again areas 0 and 63. These two file areas function as follows: Area 0: This is the default upload area. If the user does not have access to any upload areas, but has access to the upload command itself, any uploads will go to area 0. Area 63: This is a dummy file area that consists of file entries for files that are unwanted. File entries in this area do NOT correspond to actual files on the disk, they serve only to prevent those file names from being used by uploaders. Users do not need to have access to this file area in order for this blocking action to work. File areas can be configured in a variety of ways, just as with msg areas. An explanation of the various configuration options appears below: Uploads Permitted: If this switch is not set to "Y", no uploads are permitted to this area regardless of the user's access. % U/L Time to return: At the end of an upload, you may choose to give back some or all of the time that the user spent to do the upload. This field specifies the amount of such time as a percentage of the total upload time. % D/L Time to return: As with uploads, you may choose to make areas with reduced or no time restrictions, by returning some or all of the total download time. CRs / K uploaded: For each 1024 bytes of file size uploaded, the user will receive this many credits. This # can be + or -. CRs / K dnloaded: For each 1k of file size downloaded, the user will receive this many credits. This # can also be + or -. Exclude from Top-20s: rOver keeps information about the most and least frequently downloaded files. This switch can be used to restrict which areas are reflected in those stats. (Ie., files in "excluded" areas would not be included in figuring the Top-20's statistics.) Display u/l'er name: rOver displays, as part of the std file description, the date the file was uploaded, and the name of the person who uploaded it. If this switch is not set to "Y", the uploader name is not displayed, making all uploads in that area anonymous, except to users with "ALL U/L aliases" access. rOverBoard BBS Software Version 1.9 - 21 - File Areas (cont): Default path: This is the sub-directory that rOver will look in, by default, to locate files in this file area. If the file entry in the BBSFILES.DAT file contains drive or path information, this default path is ignored, and the name from BBSFILES.DAT is used "as is". This allows you to put any file in any area without needing to physically move it, but retains the convenience of never having to "remind" rOver where the file is. Description: This is the one line description of the file area, displayed when listing available file areas, among other place. Area access code: This field functions exactly as the corresponding field in the message area configuration, with the single exception that values above 63 when creating new areas cause (only) "Access area/files" to be assigned to all users (and access masks). rOverBoard BBS Software Version 1.9 - 22 - User Access Control (Access Masks): rOver allows the definition of up to 10 "masks", or groups of access control switches. These masks allow you to configure all 170+ user access options simply by assigning the appropriate mask. Of the 10 masks that rOver allows, four have special functions, as follows: Mask #1 - Assigned to new users when they first log on Mask #2 - Assigned to upgraded users (users "accepted" via F7) Mask #9 - Assigned to downgraded users (users "rejected" via F7) Mask #10 - Assigned to new users who fail to answer the questionnaire The other masks are available for your use, and may be used to emulate the "access level" approach used by other BBS software. Don't be fooled, though - these masks, while convenient, are only the starting point for access control here. Once an access mask is assigned to a user, ANY of the various options can be enabled/disabled for that user, without affecting the access of any other user. To delete users, you should assign them an access mask which specifies 0 "keep-days" (or manually set their "keep-til-date" to the current date). BBSMAINT will then delete the record the next time that it is run with the /U switch. If you also erase the user's password, they will be treated exactly like new users should they happen to log on again before maintenance is done. Otherwise they will retain their current access (whatever it may be) until maintenance is done. Access mask switches: Can use node # : These switches give the user the ability to logon to node(s) that are restricted via the /U# or /B# cmd-line switches (or equivalent events/F10:Active settings). For unrestricted nodes, these switches are ignored. Can [do action] : These switches determine whether or not the user is authorized to execute the associated command. For example, "Can move files" controls access to the X)move-Files command (on the FILEs menu). See [name] menu : These switches determine whether or not the user is authorized to enter the named menu. Write any file : This switch is currently unused. rOverBoard BBS Software Version 1.9 - 23 - Access masks switches (cont): Read any file : This very powerful switch "extends" a variety of different FILEs menu commands, as follows: D)nload-a-File: Users can download ANY file on the host machine, whether it is in BBSFILES.DAT or not, simply by entering its fully-qualifed name when asked for the file name to download (ie., D:\PATH\NAME.EXT). No credit charges/limits apply to files downloaded in this fashion. F)ind-Files : If the file name to find includes a drive letter or sub-directory name, rOver will ignore BBSFILES.DAT in favor of a DOS 'dir'-style search. The filename to be found may contain wildcards when performing such extended searches. ALL U/L aliases : File areas optionally permit the name of the uploader to be "hidden", to allow anonymous uploads. This switch overrides that restriction, allow the user to view uploader aliases in ALL areas. Is remote sysop : This switch enables the A)ssign-Mask and K)reate-User commands on the USERs menu. Can DOS Shell : Indicates whether or not this user can make use of the D)rop-to-Dos command of the DOORs menu. This command gives remote callers COMPLETE DOS access, and it wouldn't take long for a malicious person to do something nasty, like format your hard disk. Use this switch with caution! rOverBoard BBS Software Version 1.9 - 24 - Access masks switches (cont): Some access switches have action only within a given msg or file area. The Action/by-Area display of the access mask edit screen shows these actions, and their current setting in each area. Note that without the appropriate "access area" switch, other switches for that msg or file area are ignored. The switches are: Access area/msgs : Allows the user to access the msg area and read msgs. Enter/Kill msgs : Allows the user to enter msgs, and to kill mail that is addressed to or from them (public or private). Access ANY msg : Allows the user to read other people's private mail. Message demi-god : Allows the user to edit/kill/etc. other people's public (or private, when combined with Access ANY msg) mail. Also enables restricted commands such as X)tend-a-Msg, in both the MAIL and READ menus. Also allows the user access to the U)pdate-Access command for that area. Access area/files: Allows the user to access the file area and list msgs. Download files : Allows the user to download files from that area. Upload/Post files: Allows user to upload, post, export, and move files to that file area. (Other restrictions may exist.) Kill/Remove files: Allows access to kill and remove commands in that area (only if global kill/remove switch(es) are on). Also allows the user access to the U)pdate-Access command for that file area. rOverBoard BBS Software Version 1.9 - 25 - Events: rOverBoard supports two event types: internal and external. Internal events are performed without shutting the board down. They include actions such as allowing/disallowing sysop paging and various line restriction options. External events (those with event #'s above 74) cause rOver to shutdown, exiting with a return code ("ErrorLevel") of the event # that was scheduled. The .BAT file used to start rOver can then conditionally perform a variety of actions (such as unattended maintenance) by trapping specific return codes. An example of such a file (RUN.BAT) is provided with rOver. Note that rOver uses some codes to indicate error conditions; specifically, 77 = some index file(s) need rebuilding, and 99 = a fatal error (could not find SETUP.DAT, etc.). Events consist of three elements: Event #: This indicates what type of event is scheduled. Multiple events with the same event # can be scheduled, if desired. Events #'s are: 1 - Disable sysop paging 2 - Enable sysop paging 3 - D/L's are globally ok 4 - D/L's globally disallowed 5 - 300 baud calls ok (node 1) 6 - 1200 baud minimum (node 1) 7 - 2400 baud minimum (node 1) 8 - 300 baud d/l's ok (node 1) 9 - 1200 bd min to d/l (node 1) 10 - 2400 bd min to d/l (node 1) 11 - Anyone can use node 1 12 - Must have "can use node 1" 13 - D/L's ok (node 1) 14 - No D/L's (node 1) Use 15-24 for (node 2), 25-34 for (node 3), and 35-44 for (node 4) If no events (or overriding cmd line switches) are present, rOver defaults to events 2, 3, and 5/8/11/13 (all nodes) being active. 50 - Enable doorway system 51 - Disable doorway system See the section on doors for more information about the doorway system and how it functions. 75 - 127 = "External" events; rOver exits with ErrorLevel xx. Event Day: This indicates the day(s) on which this event will be executed. 0 = Sunday, 1 = Monday, ... 6 = Saturday, 7 = Weekdays only Event Time: This is the time, in 24hr format, at which the event will be executed. Note that if an external event is scheduled while the board is down (or shelled to DOS), that event will be ignored. Internal events, however, will be properly handled by the active-settings re-computation routine mentioned earlier. rOverBoard BBS Software Version 1.9 - 26 - User Upgrades: The New User Upgrades option (F7 from the Main Menu) can be used to upgrade new users, provided that you have created a REGISTER.SCR file, and that the first "command" in that file is "@". (See the section on "questionnaire" screens for more information.) If no REGISTER.SCR file is present, this feature is disabled, and attempts to access it result in an error message. When this option is selected, a screen will be presented with the alias of the first user to be upgraded, and that user's replies to the questions in the REGISTER.SCR file. (If there are more than 14 questions in REGISTER.SCR, only the first 14 answers will be displayed.) If you exit this feature and return later (without shutting rOver down), you will always return to the place you left off, rather than the first user. There are several options available while upgrading users, selected by pressing the appropriate F-key. These options are explained below: F1 - Accept This function is used to accept the new user. The user's answers are moved from REGISTER.DAT to APPROVED.DAT, and the user is assigned access mask #2. If you have made any changes to the user's answers, those changes will be reflected in the APPROVED.DAT file. F2 - Reject If you choose not to accept the user, pressing F2 will delete the user's answers from REGISTER.DAT, and will assign the user access mask #9. Nothing will be written to the APPROVED.DAT file. F3 - Accept/No upgrade F4 - Reject/No upgrade These two options are comparable to F1 and F2 (respectively), with the exception that no access mask changes are done. The answer set is deleted from REGISTER.DAT (and written to APPROVED.DAT, if F3 was selected). These options are available for those cases where the user has already been given access that you do not wish to alter (as when a friend calls, and you use the F3:User function to upgrade him/her on the spot). In the case of all four of the above options, the next new user is then displayed on the screen. If that was the last user in the list, and end- of-file message is displayed instead. Note that end-of-file does NOT necessarily mean that there are no users left to be upgraded, if any users have been bypassed earlier (via the F6 key). rOverBoard BBS Software Version 1.9 - 27 - User Upgrades (cont): F5 - Previous F6 - Next Use of either of these keys will ignore the current answer set, and go to the previous/next answer set in the REGISTER.DAT file. If there is no previous answer set (in the case of F5), rOver will beep, and the current answer set will remain on the screen. If there is no next set (in the case of F6), the end-of-file message will be displayed. Note that any time the end-of-file message appears, pressing any key will cause rOver to return to the top of the REGISTER.DAT file, and display the first available answer set. If there are no pending new users, the end-of- file message will immediately reappear. Press ESC to stop upgrading. F7 - Review This feature will bring up the current user's record, in the standard edit format used by F2:Change Users and F3:User. Exiting the user edit screen (either by CTL-ENTER or by ESC) will return to the upgrade screen at the same point. If you wanted to assign a new user a mask other than #2 or #8, you could use this feature to customize the user's access, then use F3:Accept/No Upgrade or F4:Reject/No Upgrade to process the answer set without affecting that user's access. F8 - Search This feature is not currently implemented. F9 - Top of File F10 - End of File These two keys will cause the first or last (respectively) answer sets in REGISTER.DAT to be displayed. WARNING! Be sure and heed the warning about using the "@" command first in the REGISTER.SCR file. Failure to do so will cause rOver to not be able to identify the user that entered the answer set, and thus not be able to make any access mask changes to that user. The first line displayed on the user upgrade screen should be the user alias. If this is not the case, this feature WILL NOT WORK, and MAY CORRUPT YOUR USER FILE. rOverBoard BBS Software Version 1.9 - 28 - Miscellaneous Maintenance Fields: The Misc. Maintenance option from the Main Menu allows the sysop to set a variety of different options. The fields on that(those) screen(s) are explained below: Beep length/time: These two fields control the duration and pitch of all rOver-generated beeps. If either of these values is 0, all "beeps" will be inaudible. New user CRs: This is the # of credits that is automatically given to each new user, the first time they logon. Help Level: This field controls the help level assigned to new users when they first log on. Valid values are 0 - 4. See the USER.DOC file regarding the functioning of help levels for more info. Sysop alias: In all msg area functions that force messages to be addressed to "Sysop", the alias in this field (if any) is used instead of the literal "Sysop". If you use this feature, you should logon as whatever you have specified as the sysop alias in order to read/reply-to mail, NOT as "Sysop". Total calls: The total # of calls processed by the BBS. This total does not includes calls made from the local console. # Bulletins: If this value is 0, the BULLETIN scrren is treated exactly like WELCOME2. Otherwise, BULLETIN.SCR/.ANS is treated as a menu of 1 -> #_bulltins sub-bulletins (BULLETxx.SCR/.ANS). Buy/Sell rates: rOver allows users to exchange credits for additional time, and to trade time for additional credits. The BUY field determines how many credits each additional minute of time costs. The SELL field determines how many credits the user gets back for each minutes returned. If either of these fields is zero, the corresponding command (Buy-Time / Sell-Time) is disabled. # Doors: The file DOORWAY.SCR/.ANS acts as a menu of available doors. As with #_bulletins, this value specifies the highest possible door #. Colors: rOver allows you to select the foreground and background colors associated with 10 different classes of text, as named. A table showing the different possible values along with an example of that color is included for convenience. BBS name text: These two fields are displayed when executing the B)oard-Stats command of the STATs menu. They normally contain the name of, and a short comment about, the BBS. rOverBoard BBS Software Version 1.9 - 29 - Miscellaneous Maintenance Fields (cont): Mail path: This field points to the disk sub-directory where rOver's MSG##.DAT and MSG##.IDX files can be found. These files hold the message data for each message area ##. .SCR path: Points to the disk sub-dir where all .SCR files can be found. Msg Hdr: When sending a msg to an on-line user via the F2:Msg function, this hdr is displayed just before the msg text. Chat Hdr: This text is sent to the user to notify him/her that the sysop has just started Chat mode (via F1:Chat). Chat Tlr: This text is displayed when the user leaves chat with the sysop. Log customization: All log messages are date and time stamped, and include the node # from which the activity took place. In order to determine which user was on at that time, it is necessary to use the "User Activity" log setting. - User Activity : Logs "On" and "Off" entries if true. - Insufficient memory : Logs memory allocation failures, if true. - Transfer failure : Logs failed upload and "removed" file stubs. - X)tended messages : Logs each msg that is extended. - Downloads : Logs each file that is successfully downloaded. - Alias changes : Logs each user alias change, including to/from aliases. - : Reserved for future use. - Every 100th: Logs a special entry after each 100th caller. - I/O errors: Logs an entry for any detected input/output errors. - Event activity: Logs an entry showing what event was processed when. - Kill/Remove/Xmove: Logs entries when files are killed/removed/xmoved. - : Reserved for future use. - Upload/Post: Logs entries when files are uploaded/posted. - Chat start/stop: Logs an entry when (sysop) chat is entered/left. - Security traps: Logs entries for invalid password attempts. - Modem errors: Logs entries for invalid result codes from the modem(s). ASCII translate table: Some terminals cannot display extended ASCII characters, either because they are calling at 7 bits / EVEN parity or because they are not using IBM PC compatibles. For each character above 127, this table allows you to enter a "normal" character that will be sent instead of the extended character, should any appear. This table is bypassed for users who are calling at 8 bits / NO parity and indicate at connect time the ability to display the extended characters. rOverBoard BBS Software Version 1.9 - 30 - The Modem Setup screen allows you to change the way rOver interacts with its modem(s). The primary use of these screens (one per each possible modem, for a total of 4) is to modify the modem initialization string, or to modify the table of possible modem result codes. Although other changes can be made (as with the port address and IRQ line), it is not recommended that the defaults be changed unless you know what you are doing. Note that by default, rOver "mirrors" node 3 -> node1 and node 4 -> node 2, just as DOS does with COM3: -> COM1: and COM4: -> COM2:. This means that you will NOT be able to run more than two nodes simultaneously (as 1/2 or 3/4) UNLESS you modify the port address and IRQ values. Port address : This is the base address (in hexidecimal) of the serial port. The usual defaults for the PC are 03f8 for COM1: and 02f8 for COM2:. Some serial ports allow alternate selections (required to run more than two serial ports in one machine), and this value should be set to match the serial port installation. Port IRQ: rOver uses hardware interrupt-driven communications. To accomplish this, each serial port needs to be able to generate hardware interrupts, using a uniquely assigned IRQ, or Interrupt Request Line. The usual defaults are 4 for COM1: and 3 for COM2:. Other values depend on the hardware involved, and, like the port address, must be set to match the port. Port #: Many door programs communicate with serial ports as COMx: devices, rather than directly like rOver. In order for these door programs to work, you must tell them which COMx: device is to be used if a door is run on a given node. Allowable values are 0 - 9. If 0 is entered, doors will not be permitted on that node. 1 - 4 should be used for COM1: thru COM4:, and 9 should be used to indicate that the serial port uses a non-standard port address and/or IRQ line. Init string for Answer mode: This is the string that will be sent to the modem to initialize it to answer incoming calls. It is sent to the modem when rOver is first started, as well as after each call. See the section below on modem init string requirements. Init string for Originate mode: This string is sent to the modem when switching to originate (dial-out) mode on a given node, and after each carrier loss while there. It can be used to set any modem requirements unique to dialing out, such as S0=0 to prevent the modem from answering the phone unexpectedly. rOverBoard BBS Software Version 1.9 - 31 - The Modem Setup screen (cont): Modem strings: These are the modem result codes that rOver will use to determine what is happening with the modem. Result codes returned by the modem that aren't in this table will cause rOver to reset the modem. For this reason, it is necessary to include result codes that DON'T result in a connection, such as "RING" (or "2"). Otherwise, the modem will reset each time the RING code is detected, meaning no caller would ever get thru! Likewise, the "OK" (or "0") result code must be included. "ERROR" (or "4") need not, since the solution to that condition is to simply reset the modem again anyway. Result codes can be specified in either their numeric or their alphabetic forms (but not both), and the modem init string needs to specify which form is expected (see section below). For each result code, there are three corresponding values, explained below. BAUD: This value is used to determine the speed of the connection (according to the chart shown). If the value is 0, rOver ignores the result code - this must be used for the "RING" and "OK" result codes. Otherwise, when rOver detects this result code, it will init the modem to the indicated baud rate, and display the "Press ENTER to synchronize our modems" msg. UART: In some instances, you may wish to send data to the modem at a faster rate than the modem is sending to the remote user. Modems that use compression techniques for higher throughput (MNP5, V.42, etc) typically want to be fed data as fast as possible so that the compression algorithm doesn't need to wait on characters, thus offseting any potential speed increase. For most modems, this field should have the same value as the BAUD column. For those that require the "lockbaud" feature, it will usually be set to 19.2k or 38.4k baud. MNP: This is a flag that rOver uses to determine whether or not a given call is using error-correcting modems on both ends. Typically, such modems return unique result codes for such connections. Only the result codes that reflect error-correcting links should have this field set to "Y". However, no harm will result from this flag in any event. Its only use at this present time is to display "Error-correcting modem detected" as the caller is logging on when MNP = Y result codes are detected. rOverBoard BBS Software Version 1.9 - 32 - Modem Control: rOver's absolute minimum requirements (for incoming calls) for Hayes and compatible modems are shown below. rOver can support any modem that appends a (hex-0d) to its result codes, and uses to delimit the end of its init strings. Contact FLP directly for help with non-Hayes compatibles. AT S0=1 E0 V0 Q0 M1 X1 Note that those are all zeroes, not O's, and that the modem parm should _not_ contain any spaces, as are shown here. Thus, ATS0=1E0V0M1X1. These commands tell the modem the following: AT - Tells the modem to wake up and pay attention S0=1 - Answer the phone after 1 ring (can be 1-255, _not_ 0) E0 - No local echo (handled by software) V0 - Numeric result codes (default mode). To use alpha results, change the connect code literals on the F9:Modem Setup screen. Q0 - Force result codes to be returned M1 - Turn the speaker on until the connection is established (optional - use M0 to totally disable the speaker) X1 - Enables extended result codes (required for "high speed" calls) ("high speed" = 1200 for 300/1200 modems, 2400 for 3/12/24, etc.) rOver supports up to 38.4k baud rates, with or without hardware error handling such as MNP. If you need support for higher baud rates (!?), contact FLP. Given the above modem init string, the modem still must be told how to handle the Data Terminal Ready (DTR) and Carrier Detect (CD) signals. Almost all modems have some method of forcing these signals to be 'always on' for use with older equipment. rOverBoard requires that both of these signals be 'true', ie. indicate on or off based on reality. Some modems have dip-switches to set the state of these signals, while others (true Hayes') provide software support. If your modem has dip-switches to alter DTR and CD, you should set them to the 'true' position (as opposed to 'always on'). If not, odds are that your modem supports the &Cx and &Dx Hayes commands, and you need to add &C1&D2 to the end of your modem init string (from above). &C1 forces the correct detection of carrier signals, and &D2 forces the modem to hangup and recycle when the DTR signal is dropped by the host computer. See your modem documentation with regard to Data-Terminal-Ready and Carrier-Detect for more information. rOverBoard BBS Software Version 1.9 - 33 - Modem Control (continued): These modem init strings have been proven on a variety of modem/computer combinations, and one of the two should do the trick for your modem too: For modems with dip-switches: For 'true'-Hayes compatibles: ATS0=1E0V0Q0M1X1 ATS0=1E0V0Q0M1X1&C1&D2 You _can_ include other options; these are simply the bare minimums. If your modem requires flow control, always set it to use _hardware_ flow control (RTS/CTS). rOver supports only rudimentary software flow control. Note: Refer to your modem docs for special conditions and/or further info. rOverBoard BBS Software Version 1.9 - 34 - Active Settings Fields: The Active Settings screen keeps track of the state of various switches which can be altered by command line switches or events, and allows these switches to be manipulated directly as well. The settings available on this screen are: Enable the speaker: Set to N to disable the speaker without changing your favorite beep-time/beep-length settings. Enable downloading: If this field is N, no d/l's are permitted by anyone, regardless of any other access settings. Enable ANSI colors: If N, rOver will not display ANSI colors on the "local" user screen(s). If the user has selected ANSI support, they will still see ANSI colors and both screens will display any cursor movement/save/restore commands). Enable sysop paging: If this field is N, the Page-Sysop command is disabled. Enable door system: Enabling the doorway hides the Main Menu and local console screens, so that only remote caller screens are visible, and makes the DOORs menu available to authorized users. See the section on the doorway system for further information. D/ls permitted on node: Used to restrict the use of the download command on the indicated node only. Callers on that node cannot download while this switch is in effect. Anyone can use the node: If this switch is N, callers must have "can use node #" or they will not be allowed to logon to the indicated node. Min. speed to use node: Specifies the minimum speed at which callers can connect on that node. Calls at baud rates slower than the speed indicated are not allowed to logon. Min. speed to d/l files: Specifies the minimum speed at which callers can download files on that node. Callers connected at baud rates slower than the speed indicated are not allowed to download files. Remember that "Active Settings" are NOT retained across program executions, but are re-computed each time rOver is started (based on the command line switches and any scheduled events). rOverBoard BBS Software Version 1.9 - 35 - Installation and setup: The following is a recommended series of steps for becoming familiar with rOverBoard and preparing to start your bulletin board. This is simply a guideline, not a required procedure. 1) UnZip SETUP.ZIP into the rOver directory. 2) Run BBSMAINT /X to rebuild all index files. 3) Start rOver, using only the /f and/or /s switches (if needed) 4) Go to the F8:Misc. Maintenance screen, and set (at minimum) both Mail path and .SCReen path. You MUST change the default of ".\" (= the current dir), or changing dirs while in the DOS box will cause rOver to lose all its mail and .scr's (and to create new msg##.* files all over). 5) After saving the new setup information (using CTL-ENTER), press PgDn to see the "local" BBS line. Follow the prompts, and log on as "Sysop". Go thru all the opening screens briefly, then review the available msg and file areas. Press F3 (User Edit) followed by PgDn for an idea of on what basis you will be able to control user access. Use ESC to exit. 6) PgUp back to the Main Menu, and shutdown rOver (ESC). Using the docs to get the complete list of possible .SCR files, create your own customized screens as desired. Also investigate other command line switches you may wish to use (ignore /1 - /4 for the time being). 7) If you have changed the Mail Path, delete MSG*.DAT and MSG*.IDX in the current directory. If you have changed the .SCReen path, move all your *.SCR files to the correct sub-directory. Then run BBSMAINT /Z, just to be on the safe side. rOverBoard BBS Software Version 1.9 - 36 - Installation and setup (continued): 8) Now start rOver up again, this time using any switches (except /1 - /4) that you want to test, such as /M or /P. Before logging on to the local node, edit the "Sysop" account (using F2:Change Users), and blank out the password field (using CTL-END). This will force rOver to treat the account as a new user when you again log on. 9) Once you are happy with the .SCReens, turn you attention to the msg/file areas. Using the existing areas only as a guide (and keeping in mind the reserved uses of areas 0 and 63 [msgs _and_ files]), decide what areas you want, and create them. You might have to use F3:User to give the Sysop account access to the newly created areas! 11) Once you have your areas set, move on to F5:Access Masks. At a minimum, configure the four reserved access masks (1, 2, 9, and 10); you may also wish to configure some or all of the remaining masks for convenience. 12) When finished changing the access masks, shutdown rOver, and look at BBSFILES.DAT. Using the sample BBSFILES.DAT as an example, create a new file with any filenames / comment entries that you wish rOver to know about. Then run BBSMAINT /Z to rebuild the index and register the changes. Alternately, you can simply delete BBSFILES.DAT, and use the P)ost command to add entries for pre-existing files. 13) Once you have the board tailored, and are happy with its operation as seen by the local line, then call up a patient friend, and work on getting your modem to answer the phone (see the section on modems). Then announce your board to the world! rOverBoard BBS Software Version 1.9 - 37 - rOver's keyboard: rOver uses a number of keys in special ways. In addition to the Fkeys, PgUp/ PgDn and Esc, a number of keys have special functions when working with menus, be they full screen or the one-liners that F4:Time and F5:File call up. A full list of special key uses is shown below: TAB, ^Right : Goto next field (Right/Down) BackTab, ^Left : Goto previous field (Left/Up) Right/Left : Move R/L within field or goto next/prev field Up/Down : Goto "nearest" field "above"/"below" current field Home : Goto start of current field ^Home : Goto 1st field on screen End : Goto end of current field ^End : Erase to end of field Enter : Goto next field (Down/Left) ^Enter : Save current changes and exit Esc : Exit without saving changes Ins : Toggles INS Mode (alpha fields only) Del : Deletes char under cursor (alpha fields only) + / - : Increment/Decrement field (unsigned int fields only) Space : Same as Right Arrow in non-alpha fields PgUp/PgDn : Page thru secondary menu pages (if any) Fkeys : As indicated (if applicable) ALT-c : Clear the screen (of the local monitor only) Does not work from any local menu screen Note that line 0 treats the keyboard exactly as if it were a modem with respect to incoming characters except for PgUp/PgDn and indicated function keys. Also, all selection of menu and hot-key options must be done from the keyboard. Receiving the equivalent character codes from the modem will _not_ be treated as input to menu or hot-key input parsing. rOverBoard BBS Software Version 1.9 - 38 - Ascii translation: rOver maintains a translate table for use in converting extended ASCII characters (those over 127 decimal) into normal ASCII characters, in the event the user has indicated they cannot display extended ASCII. This table is customizable from the F8 maintenance screen (page 2). ANSI support: rOver has two levels of ANSI color/graphics support. Level 1 consists of escape codes that may appear anywhere (ie., in any .SCR file). Level 2 support is confined to .ANS screens. These levels are detailed below (note that ESC means the ESC char (hex 1b), not "E" "S" "C"). Level 1: These codes may appear in any .SCR or .ANS file ESC [ 2 J - Clear the screen. This should _not_ be used in NEWUSER.SCR or BULLETIN.SCR, but is ok in other .SCR files. ESC [ K - Clear to end-of-line ESC [ ?? m - Change current attribute setting ESC [ ?? C - Move the cursor to the right ?? characters (default = 1). For non-ANSI users, this command is replaced by ?? spaces. Level 2: These codes may appear ONLY in .ANS files ESC [ ?? A - Move the cursor up ?? lines ESC [ ?? B - Move the cursor down ?? lines ESC [ ?? D - Move the cursor left ?? lines ESC [ s - Save the current cursor position ESC [ u - Restore the saved cursor position ESC [ #;# f ESC [ #;# H - These two commands are equivalent, and cause the cursor to be moved to the coordinates specified. Coordinates must be specified as row, column (y, x). These codes are TOTALLY UNSUPPORTED, and may not appear anywhere: ESC [ 6 n - Issue a cursor position report ESC [ #;# R - Cursor position report; issued in response to ESC [ 6 n For more information about ANSI commands, refer to the documentation for the ANSI.SYS device driver that comes with DOS. Most DOS manuals should have a complete list of ANSI codes and what they do. Note that 80-column screens may be parsed incorrectly if the .ANS/.SCR file uses long lines. To avoid this, either design 79-column screens, or split any problem lines into shorter segments. Always use rOver to preview your screens to be sure they display as expected! rOverBoard BBS Software Version 1.9 - 39 - The user credit system: rOverBoard controls file downloads using a "credit", or "point" system. Each user is given an arbitrary number of credits when they first log on (as set on the F8:Misc. Maintenance screen). If a user has insufficient credits (as determined by the file size and the credits-per-d/l value for that file area), they cannot download a given file. When a file is downloaded, the user loses the applicable number of credits (ie., credits-per-d/l * file_size_in_k). Credits can be _gained_ either by uploading (at a rate determined by the credits-per-u/l value in the applicable area and the file size), or by entering messages (where the number of credits is determined by the credits-per-message in the applicable message area). rOverBoard BBS Software Version 1.9 - 40 - Function keys while viewing users: While viewing user's screens, the local keyboard is automatically in "simultaneous keyboard" mode with the remote caller. That is, anything typed on the local keyboard is processed as if it came from the remote user. Exceptions to this include ESC, PgUp, PgDn, Home, End, Insert, the arrow keys, and the F-keys. The F-keys are used to perform functions specific to that user / node, as follows: F1 - Chat Pressing F1 will activate the sysop chat mode. Sysop chat works similar to internode chatting, with a few exceptions. The user is not given the opportunity to refuse the chat, and the user's time does not decrement while sysop chatting. If the user is already chatting with another node, only the user being viewed will see what the sysop types; in order for the sysop to participate in multi-user chats, he/she must log on to node 0 and use the internode chat facility. Note that the "chat hdr" and "chat tlr" (from the F8:Misc Maintenance screen) are sent to announce the start and end (respectively) of the sysop chat. The sysop chat may not start immediately, as the "chat hdr" will not be sent until the user next sees a carriage return. F2 - Msg This feature is virtually identical to the internode msg facility that is available while logged on. Messages cannot exceed 3 lines, however, as opposed to 10 lines for internode msgs. The "msg hdr" (F8:Misc Maint) is sent prior to the message text. F3 - User Pressing F3 will bring the current user's record up in edit mode. This edit is identical to the one started by the F2:Change Users option from the Main Menu. See the section on user editing for more information about the various fields. F4 - Time This feature is used to control the amount of on-line time left to the current user. Pressing F4 will bring up a sub-menu, displaying the amount of time the user has left, along with some F-key options. The time left field may be edited, and applied by pressing CTL-ENTER. Alternately, one of the F-keys may be pressed to select that option, as follows: F1: This function resets the user's time left for today to whatever the daily maximum specified in their user record is. Ie., it sets their "time used today" field back to zero. rOverBoard BBS Software Version 1.9 - 41 - Function keys while viewing users (cont): F-keys of the F4:Time sub-menu (cont) F2: <0> This function sets the user's time left for today to zero, meaning that they will immediately be logged off with the message "You have run out of time. Please call back later", and will not be permitted to log back on until the next day. F3: Hangup This function acts as if the user had dropped carrier. No messages are displayed, and the connection is immediately terminated. F5: Timeout This function acts as if the user had not typed anything for over 7 minutes. The user is immediately logged off with the message "Logged off due to inactivity". F5: File This is another sub-menu, allowing the alteration of the user's # and K up/downloaded. Only the up/down stats for the current call are included in this menu. To alter the "today" or "total" up/down stats, use the F3:User feature. This menu has one F-key option, F3, which is used to abort active file transfers. If the user is not currently transferring a file, this key has no affect. F6: Line Yet another sub-menu, this function offers the following choices: F1: Answer Places the current node in "answer" mode (the default). This means that the node will answer and respond to incoming calls. F2: Originate Places the current node in "outgoing" mode. This mode allows the user to call other boards. Anything typed on the keyboard is sent directly to the modem. See the section on outgoing calls for more information. Note that the modem init string for this mode should specify S0=0 in order to prevent the modem from answering the phone. rOverBoard BBS Software Version 1.9 - 42 - Function keys while viewing users (cont): F-keys of the F6:Line sub-menu (cont) F3: Suspend Pressing F3 will suspend all processing on the current node. The DTR signal to the modem will be dropped, and the modem will be ignored altogether. This mode permits neither incoming nor outgoing calls. Also included in the F6:Line sub-menu is the ability to control the "door mode". When doors are enabled, neither the Main Menu nor node 0 is available. Options for controlling the "door mode" are: F7: Open This option prepares the board to operate doors. The Main Menu and node 0 (local console) are both disabled. F8: Closed Disables the "door mode", and enables the Main Menu and node 0. Note that the F7/F8 options can also be controlled from the F10: Active Settings option of the Main Menu, as well as via events. See the section on door support for more information. rOverBoard BBS Software Version 1.9 - 43 - rOver's Doorway system: The DOS box, available from rOver Main Menu, can also be accessed by on-line users. This facility can be used (by both local and remote users) in two ways: shelling to DOS, and as a DOORWAY thru which DOOR programs can be executed. Doors are numbered 1 -> #_doors, as specified on the F8:Maint screen. Instead of being a special case, the D)rop-to-DOS command is handled as door #0. The doorway system is controlled thusly: With doors open (enabled), the Main Menu and local console (node 0) screens are not shown. Authorized users on remote nodes are given access to the DOORs menu ("D" from the MAIN menu). They can then execute doorway programs and/or shell to dos - unless the sysop is doing something with the local keyboard (like chatting with a user on another node), in which case the user will be told to try again later. Only one user can access the doorway at any time. If a second user tries, they will be informed that the doorway is in use, and to try again at a later time. With doors closed (disabled), all screens are selectable. Remote users cannot access the DOORs menu regardless of authorization. Node 0, however, CAN access the DOORs menu (with the same proviso about other local keyboard activity). If the state of the doorway system is changed (by an event) while the user is in the event, nothing will happen at that time. The new state of the doorway system will not be in effect until the user returns to rOver. While doors are in progress, the local screen and keyboard will be tied to the door program. rOver will be completely in the background, exactly as with accessing the DOS box. If you have selected multitasking (via the /Z switch), other incoming lines will continue to run in the background while a user is in a door; otherwise, activity on those lines will be suspended until the user returns from the door. For this reason, allowing doors while running multiple lines without multitasking is NOT recommended. If you have only one modem answering calls, only have one modem line installed, rOver will NOT multitask door accesses from that line. Installed modems that are suspended or setup to originate calls are never multitasked - only lines setup to answer incoming calls. The DOORs menu consists in part of two items. DOORWAY.SCR/.ANS is a screen containing the list of available doors. rOver allows the user to enter a number between 1 and #_doors (defined on the F8:Maint screen) in order to select a door to run. rOver then shells to DOS and executes the DOORWAY.BAT file, passing it certain parameters, like the # of the doorway to execute. If/Goto logic in the DOORWAY.BAT file then determines what program(s) is/are executed for that door. This is similar to having one .BAT file for each door, only without wasting as much disk space. rOverBoard BBS Software Version 1.9 - 44 - rOver's Doorway system: (cont.) Note that it WOULD still be possible to use one .BAT file per door, if you really wanted to. You could use a sample DOORWAY.BAT file like the one shown below: Echo Off DOOR%1 %2 %3 %4 %5 %6 %7 %8 %9 Exit The above .BAT file would re-route each door request into a separate .BAT file (DOOR0.BAT for drop-to-DOS, DOOR1.BAT for door #1, etc.) However, there is really no good reason to do this. See the sample DOORWAY.BAT file for more information. The parameters passed to DOORWAY.BAT (which are subject to possible change with new releases) are as follows: %1 - The door # to be executed (0 = drop-to-DOS) %2 - Com port, as COM1: - COM4: or LOCAL %3 - Com base (in hexidecimal) %4 - Com IRQ line %5 - Com port, as 1-4, or 0 for LOCAL %6 - The # of minutes the user has remaining %7 - A (far) pointer to rOver's door interface record (as "xxxx:yyyy") rOver does not create a xxx.SYS file for use by door programs. Instead, this record is created in-memory, and its address passed as a paramater (#7) to the DOORWAY.BAT file. An external program (MOCKDOOR.EXE) is provided to convert rOver's interface record into the format(s) used by various other BBS software. Currently supported formats include those used by GAP, PCBoard, and DOORWAY. See MOCKDOOR.DOC for more information about the conversion program. Also, note that doorway control programs (such as DOORWAY.EXE) may exhibit weird behaviour due to the increased rate at which rOver tics the timer when multitasking. DOORWAY.EXE in particular will only allow you 1/4 as much time in the doorway as you specify. The only time this would not be an issue is when the remote user is running a door on a system with only one line installed. In this case, no multitasking is taking place, and the timer operates at its normal speed. This is ONLY true of the remote user - accessing the doorway from the local line WILL cause multitasking to occur even in single-modem setups. Programs which change the timer rate (such as BASIC, when playing music) should be avoided, as they will drastically slow down the rate at which the lines running in the background (if any) receive time. rOverBoard BBS Software Version 1.9 - 45 - rOver's Door interface record: A record layout for rOver's door interface record is available in the R-MAP2.H file. rOver passes a 32-bit address to this record (in the form "xxxx:yyyy") to DOORWAY.BAT when a door is opened. rOver-specific doors may use the information in this record directly. Doors written for other BBS systems can utilize MOCKDOOR.EXE to convert the information in this record to other formats. The fields in this record are as follows: Port: This is the COMx: port # the caller is using. 0 = LOCAL, 1-4 = COM1: thru COM4:, and 9 = the port must be addressed directly via the com base/IRQ values. Base: This is the base address of the serial port. Caller Baud: This is the actual connect speed (300 - 38,400). Serial Baud: This is the speed at which the serial port must be opened. IRQ: This is the IRQ line being used by the serial port. Node: This is the # of the active node (0 - 4). Sysop Page: 'Y' if the sysop can be paged, else 'N'. Ascii OK: 'Y' if the caller can display extended ASCII chars, else 'N'. Ansi OK: 'Y' if the caller can display ANSI color/graphics, else 'N'. Parity Flag: Indicates the word length, parity, and stop bits of the current connection. 'Y' = 7/E/1, while 'N' = 8/N/1. Is MNP: 'Y' if the current connection supports hardware error correction. Filler: This byte is reserved, and should not be modified. Busy Flag: Use of this field will be documented in a future release. At present, this field is NULL, and MUST NOT be used. EMS Segment: This is the segment value of the 64k EMS page, or 0000 if EMS is not being used. Setup Page: This is the EMS logical page # into which the SETUP structure (SETUP.DAT) is mapped. When the door program starts, this logical page is mapped into physical page #1 (ie., address EMS_segment:4000h). It will be -1 if the SETUP structure is not in EMS memory. rOverBoard BBS Software Version 1.9 - 46 - rOver's Door interface record (cont): Setup Handle: This is the EMS handle # with which the Setup Page is associated. User Page: User Handle: These two fields are not currently used, as the USER_REC structure is not currently loaded in EMS memory. Time Left: The # of minutes the user has remaining this call. # Uploaded: This is the # of files the user has uploaded this call. # Downloaded: This is the # of files the user has downloaded this call. K Uploaded: The total size (in K) of all files uploaded this call. K Downloaded: The total size (in K) of all files downloaded this call. (These fields are NOT reflected in the user's record until AFTER the user logs off.) Last Call: The date/time of the user's last call. (The date/time of last call in the user's record will always reflect the date/time the user logged on for THIS call.) Last New Files: The date/time the user last did a N)ew-Files check. Buffer: A 32-bit pointer to a 10k buffer accessible by door programs. User Rec: A 32-bit pointer to location in memory where the current user's record is stored. More information will be added to this record in a future release to allow door programs more control of rOver, and access to the files which rOver has open. All additions will be made at the bottom of this record, so as to maintain downward compatibility with existing door programs. rOverBoard BBS Software Version 1.9 - 47 - EMS memory utilization: rOver supports the use of EMS memory for data storage. Use of this option will significantly decrease the amount of "low" memory that rOver occupies. rOver adheres to the LIM/EMS 3.2 standard, meaning that it should work with virtually any EMS driver, including emulators that use exTENded memory or even disk space to simulate exPANded (EMS) memory. The latter class of emulators is NOT recommended, especially when running more than one line, or when multitasking DOS accesses. Also, if your EMS emulator requires that the 64k EMS page be mapped into "low" memory (below the 640k line), you may or may not benefit from using EMS, depending on your particular board setup. The F1:Dos Command prompt from the Main Menu has been enhanced to display the available amount of both regular and EMS memory available. Note than when using EMS memory, the caveats about adding new users and/or new files while in the DOS box (or a door) do not apply; rOver CAN allocate EMS memory, even when running in the background. As an estimate of how much memory you could regain by using EMS, use the following guide: - 16k of screen buffers (12k if running with no modems installed) - 16k used to hold the SETUP.DAT information - ~8k for every 186 users, or fraction thereof (actual EMS usage is 16k for every 372 users, due to the way EMS is allocated) - ~5k for every 200 files, or fraction thereof (actual EMS usage is 16k for every 600 files, due to the way EMS is allocated) For example, on TWW, with ~900 users and ~1600 files, I regained over 100k. rOverBoard BBS Software Version 1.9 - 48 - Outgoing calls: rOverBoard BBS Software Version 1.9 - 49 - Misc. Notes: On-line help is available on TWW (301-322-8678), in message area #20.