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.
<menu>.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 <cr> 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> : 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> : 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 <cr> (hex-0d) to its result codes, and uses <cr> 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: <Max>
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.