Category : BBS Programs+Doors
Archive   : RVR20C-2.ZIP
Filename : ROVER.DOC

 
Output of file : ROVER.DOC contained in archive : RVR20C-2.ZIP









rOverBoard BBS Software - Version 2.0a
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 - 9600 / 24 hours


Table of Contents Page #
----------------- ---------
Warranty and registration information i
About rOverBoard 1
Command-line switches 2
rOverBoard .SCReen files (.SCR / .$CR) 6
rOverBoard .ANSi (screen) files (.ANS / .AN$) 8
Other rOverBoard related/created files 9
"Questionnaire" screens (REGISTER.SCR, SURVEY.SCR) 11
The Bulletin Menu 12
File listings (BBSFILES.DAT) 13
rOver's Main Menu screen 14
The DOS box 15
Multitasking the DOS box 16
Editing users 17
Configuring message areas 19
Configuring file areas 21
User access control ("Access Masks") 23
Events 26
New user upgrades 27
The miscellaneous maintenance screen 29
The modem setup screen 31
Modem requirements & initialization 33
The Active Settings screen 35
Installation and setup 37
rOver's keyboard 39
ANSI & ASCII support 40
rOver's credit system; what it is and how it works 41
Function keys while "spying" on users 42
rOver's doorway system 45
rOver's door interface record 48
EMS memory utilization 50
Outgoing calls explained 51
Miscellaneous notes 52











rOverBoard BBS Software
Version 2.0
i

WARRANTY: This program is provided "as is" without warranty of any kind,
expressed or implied. The entire risk as to the results and performance of
the program is assumed by you. Furthermore, FreeLance Programming does not
warrant, guarantee, or make any representations regarding the use of, or
the results of the program, and you rely on the program and results soley
at your own risk. FreeLance Programming cannot accept responsibility for
any system damage, loss of profit, or any other incidental or consequential
damages resulting from the use or inability to use this product.

You are granted a limited license to copy and distribute unregistered
versions of this software. You may examine and use this software for a
period not to exceed 30 days. At the end of that time, you must either
register the software, or cease using it. Upon registering, you agree to
use reasonable efforts to prevent your registered version from being
distributed. You have the right to make unlimited backup copies of both
unregistered and registered versions; however, only ONE (1) copy of the
registered version may be in use at any given time. All rights not
specifically granted in this license are reserved by FreeLance Programming.

rOverBoard and its associated programs are a copyrighted product, being
distributed as user-supported software. User-supported software is similar
to shareware, however, IT IS NOT SHAREWARE. If you use this product for
more than 30 days, you MUST register it. This is a fully functional
release; no features have been omitted or crippled in any way. You are
encouraged to copy the unregistered version of this software and to
distribute it by whatever means. If a fee is charged for its distribution,
it must be made perfectly clear that the fee is ONLY for the distribution,
and in no way obviates the registration requirement. Support for this
product is available to all users (registered or otherwise) on my BBS (see
below). Users who require additional support, or who desire custom program
changes should contact FreeLance Programming, either on the BBS, or by
mail at the address shown below.


The Wizard's Workshop
(301)-322-8678
300 - 9600 24hrs


FreeLance Programming
P O Box 726
Washington DC 20044-0726



I welcome comments and suggestions about this product; please contact me
either on-line or by mail. Your comments CAN make a difference. The
latest version of rOverBoard (guaranteed virus-free) will, of course,
always be available for download from The Wizard's Workshop.







rOverBoard BBS Software
Version 2.0
- 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 _MUST_ 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. Use
of a hard disk is strongly recommended. Modem support is fairly flexible -
certainly any modem that supports the AT command set should work without any
problem. 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 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 2.0
- 2 -

Command line switches:

ROVER.EXE /1[p] /2[p] /3[p] /4[p] /B# /D# /U# /0 /@ /A /B /D /E /F
/G /H /I /K /L /M[+/-] /N /P /Q /S /T /U /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 node)
+ = Prevents 300 (300/1200, if '!' used) baud callers (on that node)

* = Indicates a hard-wired (no or null-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.

@ = Prevents caller input from being echoed. This can greatly reduce
packet counts for callers on X.25 lines. Callers on such nodes need
their comm program to provide local echo as well as to generate both
a CR and a LF when they press the ENTER key.

Note that characters typed on the rOver keyboard WILL be echoed to
the remote caller. The echo will occur as soon as the key is
pressed, instead of being smoothly inserted into the data stream as
is usually done.

/0 : Disable Node 0

Use of this switch will cause rOver to be started without the local
node (Node 0) being present. This configuration will result in as much
as 25k additional memory being available for the DOS box and doorway
programs. However, the board must be re-started without this switch in
order to allow local logons.

/@ : Two-word aliases

Using this switch will require users to have at least two words in
their user name. Boards that require real names to be used instead of
aliases should use this switch. While it does not guarantee that the
user enter their real name (what does?), it does help eliminate the more
obvious abuses. Note that the single-word alias "Sysop" is explicitly
excluded from this check.

/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.




rOverBoard BBS Software
Version 2.0
- 3 -

Command line switches (continued):

/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!).

/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.

/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.

/G : Glass-TTYs

When this switch is used, rOver assumes that all new users have screens
that are 80x24. New users are not prompted to enter their terminal
length and width when they first log on. These values may still be
altered from the CHANGE menu.

/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.




rOverBoard BBS Software
Version 2.0
- 4 -

Command line switches (continued):

/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).

/Q : Quick Logons

This switch will cause rOver to skip asking users to verify their names
when they first log on ("Sysop? [Y,n] >"), if the name they entered is
already known to the system. Execution proceeds as if the user had
entered a "Y" at the missing prompt. Has no affect on new users.






rOverBoard BBS Software
Version 2.0
- 5 -

Command line switches (continued):

/T : Date Tracking

Normally, when a user logs on, if the current date + the # of keep days
for their user record is greater than the explicit keep-til-date for
that user record, the keep-til-date is updated to be the current date
plus the # of keep days. When the /T switch is used, no such update
is done. Thus, sysops who maintain user subscriptions can set the
keep-til-date when the user subscribes, and use the keep-til-date to
keep track of when their subscription expires. (And to delete their
account [via BBSMAINT] if they have not resubscribed by that time.)
Note that when assigning access masks, the keep-til-date is still
explicitly set as the date the user last logged on plus the number of
keep days shown for the access mask being assigned.

/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).

/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.


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 2.0
- 6 -


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.

HELLOx.SCR - These are node-specific opening banners that may be used in
conjunction with, or in place of, WELCOME1.SCR. "x" is the
number of the node the screen applies to (0 - 4). If present,
the appropriate screen (based on the node the user is calling
on) is displayed immediately prior to the "Enter your name"
prompt.

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.

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.





rOverBoard BBS Software
Version 2.0
- 7 -


rOverBoard .SCR files (continued):


REGISTER.SCR - This is a 'questionnaire' screen which may contain prompts for
user input. See the section on questionnaires for more info.
If present, this screen affects new users' access, as follows:
Users who successfully complete the screen are assigned default
access mask #1. If they do not complete it, they are assigned
default access mask #10.

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.

MSGxx.SCR - Each msg area can have a MSGxx.SCR associated with it (where
xx is the # of the msg area, 0 - 63). This screen will be
displayed the first time a caller enters that msg area. If
the caller uses the A;? or A;?? command to get a list of the
available areas, this screen will also be displayed for the
next area entered (if one exists for that area), regardless of
whether or not the user has already seen it during this call.

FILExx.SCR - Each file area can have a FILExx.SCR associated with it, just
as with the message areas. This screen will be displayed each
time the A)rea-Info command is used to get information on a
given file area.

.SCR - For each menu, a .SCReen file bearing the name of that menu
may be created. If a user has help level 4 selected, this
screen will be displayed in place of the normal rOver menu.
The screen will be followed by the standard help level 0
prompt for that menu. If no screen exists for a given menu,
help level 4 is equivalent to help level 3. Valid menu names
for .SCR files are: MAIN, CHANGE, MAIL, READ, EDIT, STATS,
CONFIG, USERS, ZIP, BULLETS, FILES, and USERLIST.

.$CR - For each menu, a .$CReen file bearing the name of that menu
may also be created. Users with help level 4 will see this
screen if they request help on all commands for a given menu
("??"). Use .AN$ for ANSI versions of these screens.
Valid menu names are the same as for .SCR files.






rOverBoard BBS Software
Version 2.0
- 8 -


Note: Custom help screens (.$CR and .AN$) function identically to their
.SCR and .ANS menu counterparts.

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 2.0
- 9 -


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 (of BBSMAINT) is used. It is NOT a text file.

USER.DAT - This is the user file which contains a record for each user
with all the information for that user. 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).

REGISTER.IDX - This is a quick-access index to the REGISTER.DAT file which
allows rOver to present new answer sets for possible upgrading
in the F7:New User Upgrades process, and to avoid re-displaying
answer sets which have already been processed.

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
(by using the /U switch of BBSMAINT).

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 2.0
- 10 -


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.


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.






















rOverBoard BBS Software
Version 2.0
- 11 -

Questionnaire Screens:


Questionnaire screens (REGISTER.SCR and SURVEY.SCR) are formatted text files
that implement a mini-script language. The 1st char of every line is either a
space or the start of a 'command'. The line (minus the 1st char) is always
displayed before the action of the command (if any), except in the case of
comments. rOver currently accepts the following commands:


? : Prompts the user for [Y,n] input. If the user answers N, the screen is
aborted. In the case of REGISTER.SCR, the user is then assigned access
mask #10.


@ : This character in column 1 causes the user's name to be affixed to the
output answer set. If using the built-in upgrade facilities in conjunction
with REGISTER.SCR, this command _must_ appear in the questionnaire.


! : Prompts for up to 40 chars of input. If the text following this command
exceeds the width of the user's screen - 40, a is generated, and the
input prompt moved to the next line.

M : Similar to "!". Prompts for up to 24 characters of input. The resulting
input is then moved to the "miscellaneous data" field of the user's
record (as well as being included in the registration answer set). This
can be useful for such things as including the user's phone # in their
user record to make re-locating their registration data after they have
changed their alias much easier.

#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 2.0
- 12 -

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 2.0
- 13 -
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 2.0
- 14 -


rOver's 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 2.0
- 15 -


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 also 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 2.0
- 16 -


Multitasking the DOS box:

Note: All references to "the DOS box" also include all door activity,
whether activated by the remote caller or executed from node 0.

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.

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 2.0
- 17 -


Editing Users:

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 2.0
- 18 -


Editing users (continued):

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.

"Bought" Time Limit: This controls the maximum amount of time the user
is allowed to purchase in any 24 hour period. Without this limit,
users with sufficient credits could theoretically stay logged on
all day long.

User Level: rOver does not use this field for anything. Each of the 10
default access masks contains a can contain a value for this
field (0 - 65535) that will be assigned whenever a user is
assigned an access mask. This field is provided for the
convenience of external programs only.

Misc. Data: The 'M' command on the SURVEY or REGISTER screen files can be
used to collect of to 24 characters of input from the user
(on any subject). These characters are then stored in this
field. The user cannot edit this field directly; however, if
this data is collected in the SURVEY screen instead of the
registration questionnaire, the user can always answer the
survey again and provide different data.

CONFIG'ed Area: These switches are used to indicate whether or not each
of the 64 available message areas is included in that user's
list of configured messages areas. New users default to having
all areas configured. For more information on the purpose of
configuring message areas, see the CONFIG menu section in the
user documentation.







rOverBoard BBS Software
Version 2.0
- 19 -


Configuring 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 2.0
- 20 -


Configuring Message Areas (continued):

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 2.0

- 21 -


Configuring 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 1024 bytes of file size downloaded, the user
will lose 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 2.0
- 22 -


Configuring File Areas (continued):

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, as well
as when doing an A)rea-Info command.

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 2.0
- 23 -


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 2.0
- 24 -


Access masks switches (continued):

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, allowing 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!

Internode Chat : This switch allows the user to make use of the C)hat
command (from the USERs menu). If the user does not
have access to this feature, he/she can not originate
OR receive chats, nor make use of the *)Chat-Toggle
command (from the CHANGE menu).

















rOverBoard BBS Software
Version 2.0
- 25 -


Access masks switches (continued):

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.

Finally, access to each door (1-63) can be controlled individually with
the "Open Door #" switches. Note that door #0 is controlled by the
separate "Can DOS Shell" switch, and that door #s above 63 are reserved
for special purposes (see the section on doors for more information).


















rOverBoard BBS Software
Version 2.0
- 26 -


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.), so those codes should not be used to signal events.

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,
where xx corresponds to the event number.

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 2.0
- 27 -


New 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, the date/time that user filled out the
questionnaire, and that users's answers 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 2.0
- 28 -


New User Upgrades (continued):

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 2.0
- 29 -


Miscellaneous Maintenance Fields:

The Misc. Maintenance option from the Main Menu allows the sysop to set a
variety of different options, as 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 include calls made from the local console.

# Bulletins: If this value is 0, the BULLETIN screen is treated exactly
like WELCOME2. Otherwise, BULLETIN.SCR/.ANS is treated as
a menu of 1 -> #_bulletins 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
minute sold. 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 #.

Min. space for u/l's: This field specifies, in k-bytes, the minimum amount
of space that must be on the target disk for a given file area for
users to be able to upload to that file area.

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 2.0
- 30 -


Miscellaneous Maintenance Fields (continued):


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 screen files can be found.
("Screen files" mean all .SCR, .ANS, .$CR, and .AN$ files.)

Msg Hdr: When sending a msg to an on-line user via the F2:Msg function,
this hdr is displayed just before the msg text.

Chat Hdr: This text is sent to the user to notify him/her that the sysop
has just started Chat mode (via F1:Chat).

Chat Tlr: This text is displayed when the user leaves chat with the sysop.


Log customization:

All log messages are date and time stamped, and include the node # from
which the activity took place. In order to determine which user was on
at that time, it is necessary to use the "User Activity" log setting.

- User Activity : Logs "On" and "Off" entries if true.
- Insufficient memory : Logs memory allocation failures, if true.
- Transfer failure : Logs failed upload and "removed" file stubs.
- X)tended messages : Logs each msg that is extended.
- Downloads : Logs each file that is successfully downloaded.
- Alias changes : Logs each user alias change, including to/from aliases.
- : Reserved for future use.
- Every 100th: Logs a special entry after each 100th caller.
- I/O errors: Logs an entry for any detected input/output errors.
- Event activity: Logs an entry showing what event was processed when.
- Kill/Remove/Xmove: Logs entries when files are killed/removed/xmoved.
- Door activity: Logs an entry each time a door is entered/exited.
- 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 2.0
- 31 -


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 hexadecimal) 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.

Logoff Delay:

Using high-speed buffered modems with the DTE interface locked at a
high rate of speed causes problems for users who connect a less than
the modem's maximum effective speed, as when the BBS terminates the call
the modem's buffer may still contain unsent data which is then lost.
This field specifies a fixed # of seconds to delay after the user logs
off to allow such modems to empty their buffers. This field is weighted
depending on the baud rate of the caller. 300 baud callers will get a
delay that is 24x the amount specified; 12x for 1200, 6x for 2400, 3x
for 4800, 2x for 9600, and 1x for 19.2k, and no delay for 38.4k. If the
DTE and DCE baud rates are the same, this field is ignored.





rOverBoard BBS Software
Version 2.0
- 32 -


The Modem Setup screen (continued):


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.

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.





rOverBoard BBS Software
Version 2.0
- 33 -

Modem Requirements and Initialization:

rOver's absolute minimum requirements (for incoming calls) for Hayes and
compatible modems are shown below. rOver can support any modem that appends
a (hex-0d) to its result codes, and uses to delimit the end of its
init strings. Contact FLP directly for help with non-Hayes compatibles.

AT S0=1 E0 V0 Q0 M1 X1

Note that those are all zeroes, not O's, and that the modem parm should _not_
contain any spaces, as are shown here. Thus, ATS0=1E0V0M1X1. These commands
tell the modem the following:

AT - Tells the modem to wake up and pay attention
S0=1 - Answer the phone after 1 ring (can be 1-255, _not_ 0)
E0 - No local echo (handled by software)
V0 - Numeric result codes (default mode). To use alpha results,
change the connect code literals on the F9:Modem Setup screen.
Q0 - Force result codes to be returned
M1 - Turn the speaker on until the connection is established
(optional - use M0 to totally disable the speaker)
X1 - Enables extended result codes (required for "high speed" calls)
("high speed" = 1200 for 300/1200 modems, 2400 for 3/12/24, etc.)

rOver supports up to 38.4k baud rates, with or without hardware error handling
such as MNP. If you need support for higher baud rates (!?), contact FLP.

Given the above modem init string, the modem still must be told how to handle
the Data Terminal Ready (DTR) and Carrier Detect (CD) signals. Almost all
modems have some method of forcing these signals to be 'always on' for use with
older equipment. rOverBoard requires that both of these signals be 'true', ie.
indicate on or off based on reality. Some modems have dip-switches to set the
state of these signals, while others (true Hayes') provide software support.
If your modem has dip-switches to alter DTR and CD, you should set them to the
'true' position (as opposed to 'always on'). If not, odds are that your modem
supports the &Cx and &Dx Hayes commands, and you need to add &C1&D2 to the end
of your modem init string (from above). &C1 forces the correct detection of
carrier signals, and &D2 forces the modem to hangup and recycle when the DTR
signal is dropped by the host computer. See your modem documentation with
regard to Data-Terminal-Ready and Carrier-Detect for more information.
















rOverBoard BBS Software
Version 2.0
- 34 -

Modem Requirements and Initialization (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 2.0
- 35 -

Active Settings Fields:

The Active Settings screen keeps track of the state of various settings,
many of which can be altered by command line switches or by events, and
allows these settings to be manipulated directly. 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.

Note that the settings above 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). This is NOT true of the settings
shown below, which ARE retained across program executions.









rOverBoard BBS Software
Version 2.0
- 36 -

Active Settings Fields (continued):

Enable ZIP Door: This switch controls the state of the V)iew-Members
command in the ZIP menu. If this switch is not set, then that
command is unauthorized for all users. If this switch IS set,
executing the V)iew-Members command causes door #64 to be invoked,
meaning that the setup requirements for that door must be complete
first. See the section on DOORs for more information on the ZIP
doorway.















































rOverBoard BBS Software
Version 2.0
- 37 -

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) Make a sub-directory for rOver. Unzip the rOver distribution file into
this sub-dir. Then unzip any embedded .ZIP files, such as the SETUP.ZIP
file, which contains the setup utility and sample screens and .bat files.

2) Execute the SETUP.EXE program. This program (which has no command line
switches) will ask for several critical pieces of information, and will
then create a SETUP.DAT configuration file for use by rOver.

3) Run BBSMAINT /X to build .IDX files as needed.

4) Start rOver, using only the /f and/or /s switches (if needed)

5) Go to the F9:Modem/Port Setup screen, and configure each node that you
plan to be using. You can start by just configuring one node now, and
save any others until you're more familiar with the program. See the
MODEM.TXT file for some help in filling out the required fields for your
particular modem.

6) After saving the modem information (with CTRL-ENTER), hit PgDn and logon
as Sysop. You will be prompted to create a new account. Note the
screens that are displayed - many of these are the sample .SCR files, and
are fully configurable.

7) Press F3 to bring up the newly created user record. Then hit PgDn to see
the second page, with all the access switches. Set each switch to a "Y"
at this time. Then use CTRL-ENTER to save the changes.

8) Now spend some time exploring the various menus and commands. When you
get ready to decide on what level of user should have access to what
commands, it is useful to know what each one is. Refer to the USER.DOC
file for more information on each command.

9) Also investigate the list of available message and file areas (some basic
areas are created for you, though you do not have to keep them). You
should start thinking about what areas you plan to support (and what
level of user is going to have what access to which areas).

10) Once you are comfortable with using rOver, hit PgUp and return to the
Main Menu. Press F8 for the Misc. Maintenance screen(s), and configure
any fields that you desire (such as colors). Press PgDn to get to the
second screen of fields. Press CTRL-ENTER to save your changes and
return to the Main Menu.









rOverBoard BBS Software
Version 2.0
- 38 -


Installation and setup (continued):

11) Look thru the various .SCR files, and match them up with what you saw
when you logged on. See the section on .SCR files for other possible
screens, as well. Edit these files to create your own personalized
displays. (Note that .ANS screens can be created with a utility such
as TheDraw. Unless you are familiar with ANSI, I do NOT recommend that
you create .SCR files in this manner - just use an ordinary editor, and
save the files in plain text (ASCII) format.

12) 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 CTRL-END). This will force rOver to treat you as a
new user when you log on again.

13) Once you are happy with the .SCR/.ANS files, turn your 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 on
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!

14) Once you have some areas established, move on to the F5:Access masks.
At a minimum, configure the four reserved masks (1, 2, 9, and 10); you
may also wish to configure some or all of the remaining masks for your
convenience. Remember, these are just groups of access switches that
are used to determine what commands a user can access.

15) 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. You can also run AUTOFILE, which
is a 3rd-party product designed to look thru all the sub-directories that
rOver knows about, and create file entries (without descriptions) for
every file found in those sub-directories. This is a quick way to get
started if you have a lot of files to add.

16) Once you have the board tailored, and are happy with its operation as seen
by the local line, start the board with at least one modem active, call
up a patient friend, and work on getting rOver to answer the phone. For
help, refer back to the MODEM.TXT file, as well as to the QUESTION.TXT
file, which contains answers to some common questions, many of which
relate to modem operations.

If you need assistance, contact FreeLance Programming on their BBS, or
by mail at the address shown at the beginning of the docs. Don't be
discouraged if the modem setup takes a bit of work - this is quite
natural, as modem communications are extremely complicated.





rOverBoard BBS Software
Version 2.0
- 39 -

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 2.0
- 40 -


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 page 2 of the F8 maintenance screen.


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 2.0
- 41 -


rOer's 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), or
by selling time for credits (see the section on Miscellaneous Maintenance
fields for more information).








































rOverBoard BBS Software
Version 2.0
- 42 -


Function keys while spying on users:

While viewing user's screens, the local keyboard is automatically in
"simultaneous keyboard" mode with the remote caller. That is, anything
typed on the local keyboard is processed as if it came from the remote user.
Exceptions to this include ESC, PgUp, PgDn, Home, End, Insert, the arrow
keys, and the F-keys. The F-keys are used to perform functions specific to
that user / node, as follows:

F1 - Chat

Pressing F1 will activate the sysop chat mode. Sysop chat works similar
to internode chatting, with a few exceptions. The user is not given the
opportunity to refuse the chat, and the user's time does not decrement
while sysop chatting. If the user is already chatting with another node,
only the user being viewed will see what the sysop types; in order for the
sysop to participate in multi-user chats, he/she must log on to node 0 and
use the internode chat facility. Note that the "chat hdr" and "chat tlr"
(from the F8:Misc Maintenance screen) are sent to announce the start and
end (respectively) of the sysop chat. The sysop chat may not start
immediately, as the "chat hdr" will not be sent until the user next sees
a carriage return.


F2 - Msg

This feature is virtually identical to the internode msg facility that
is available while logged on. Messages cannot exceed 3 lines, however,
as opposed to 10 lines for internode msgs. The "msg hdr" (F8:Misc Maint)
is sent prior to the message text.

F3 - User

Pressing F3 will bring the current user's record up in edit mode. This
edit is identical to the one started by the F2:Change Users option from the
Main Menu. See the section on user editing for more information about the
various fields.

F4 - Time

This feature is used to control the amount of on-line time left to the
current user. Pressing F4 will bring up a sub-menu, displaying the amount
of time the user has left, along with some F-key options. The time left
field may be edited, and applied by pressing CTL-ENTER. Alternately, one
of the F-keys may be pressed to select that option, as follows:

F1:

This function resets the user's time left for today to whatever the
daily maximum specified in their user record is. Ie., it sets their
"time used today" field back to zero.





rOverBoard BBS Software
Version 2.0
- 43 -


Function keys while spying on users (continued):

F-keys of the F4:Time sub-menu (continued)

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 2.0
- 44 -


Function keys while spying on users (continued):

F-keys of the F6:Line sub-menu (continued)

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 2.0
- 45 -


rOver's Doorway system:

The DOS box, available from rOver's Main Menu, can also be accessed by
on-line users. This facility can be used for a variety of different
purposes such as allowing remote users to shell to DOS, to allow external
programs to be integrated into the functionality of the board, and to allow
users to execute door programs. Since control of the screen and the keyboard
are turned over to the door programs while they are running, there are some
controls necessary to support such programs, as described below.

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). In the absence of other restrictions,
they can then execute doorway programs and/or shell to DOS. Access to each
door program (including drop-to-DOS) may be restricted on a per-user basis.
Access to the doors may also be restricted to specific nodes (see the port #
field on the Modem Setup screen for more information). The doorway is
is unavailable while the sysop is chatting with users or making outgoing
calls on another node. Since there is only one doorway which is shared
between nodes, the doorway will also be unavailable if it is currently in
use by a user on another node.

With doors closed (disabled), all screens are selectable. Authorized
(remote) users can still access the DOORs menu; however attempts to actually
open a door will not be successful. Users on the local node (node 0) CAN
open doors in this configuration, subject to the same restrictions on
chatting or making outgoing calls.

If the state of the doorway system is changed (by an event) while the
door is in use, 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 a door is running, 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, exactly as with the DOS box. Note that node 0 is never multitasked
while the door is in use, nor are "suspended" lines.

There are three basic methods of executing door programs. The first is to
select a door # from the DOORs menu. The second is to select the D)rop-to-
Dos function from the same menu. The third is to execute a command that
causes an "invisible" door to activate. (The only such "invisible" door
currently in use is the V)iew-Members command of the ZIP menu, explained
later.) All of these options cause the same action to take place - rOver
executes the DOORWAY.BAT file.






rOverBoard BBS Software
Version 2.0
- 46 -


rOver's Doorway system (continued):

DOORWAY.BAT is the key to all of rOver's doorway activity. Whenever any
door ("normal" / drop-to-DOS / "invisible") is selected, rOver runs the
DOORWAY.BAT file, passing to it various parameters. The first such parm is
the number of the door being executed (where 0 = drop-to-DOS, 64 = the zip
view door, and any other # is the door # the user selected). The .BAT file
must use this parameter to decide what to do. (If you are not familiar with
.BAT files, please consult your DOS documentation for more information.) A
simple .BAT file might look like this:

Echo Off
If "%1" == "0" Goto DOSDROP
If "%1" == "1" Goto DOOR1
If "%1" == "64" Goto ZIPDOOR
Echo I don't know what to do!
Goto ENDIT

:DOSDROP
[commands to run a remote DOS program]
Goto ENDIT

:DOOR1
[commands to run door #1 here]
Goto ENDIT

:ZIPDOOR
[commands to run a zip viewer here]
Goto ENDIT

:ENDIT
Exit

The "Echo Off" is recommended both to speed up processing and to reduce the
possibility of a CTL-BREAK aborting the .BAT file. The lines beginning with
colons are labels for the "Goto" commands. The quotes used in the "If"
statements are not strictly necessary, but will not hurt, and will avoid
potential problems. The command necessary to execute each of the individual
door programs have been omitted. They are inherently specific to whatever
program you choose to install for a given function. The sample DOORWAY.BAT
that comes with rOver is an actual working sample; you are encouraged you
study it and use it as a model for your own DOORWAY.BAT file.

Note that you COULD separate each door into its own .BAT file, simply by
using a DOORWAY.BAT file that looked like this:

Echo Off
DOOR%1 %2 %3 %4 %5 %6 %7 %8 %9
Exit






rOverBoard BBS Software
Version 2.0
- 47 -


rOver's Doorway system: (cont.)

The above .BAT file would re-route each door request into a separate .BAT
file (ie., DOOR0.BAT for drop-to-DOS, DOOR1.BAT for door #1, and DOOR64.BAT
for the zip viewer. This elminates the use of the If/Goto logic, and it
keeps the logic for each door in its own little compartment, but it is also
slower, and not recommended.

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 hexadecimal)
%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")
%8 - The fully-qualified name of the .ZIP file to view (door #64 only)

rOver does not create an xxxx.SYS file for use by door programs, as some BBSs
do. Instead, this file is created in-memory, and its address is passed as
a parameter (%7) to the DOORWAY.BAT file. And external program such as the
provided MOCKDOOR.EXE can be used to convert this interface record into the
format(s) used by various other BBS software, allowing the user of doors
which do not specifically support rOverBoard. See MOCKDOOR.DOC for more
information about this 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.

Note that you MUST supply programs to perform the drop-to-DOS and view zip
functions; these are NOT provided with rOver. The sample DOORWAY.BAT file
shows DOORWAY.EXE used for drop-to-DOS, and ZIPTV.EXE used for viewing .ZIP
files. These programs (while available on TWW) are samples ONLY. I neither
encourage nor discourage their use. There are many programs available that
will perform similar functions; you should choose the one that suits you
best.






rOverBoard BBS Software
Version 2.0
- 48 -


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 2.0
- 49 -


rOver's Door interface record (continued):

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 2.0
- 50 -


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 2.0
- 51 -


Outgoing calls:

rOver supports a rudimentary dumb terminal capability. When a node is put
into outgoing call mode, the "Init string for Originate Mode" is sent to the
modem, and the node is then placed in terminal mode. Anything typed on the
keyboard is sent directly to the modem. No dialing directory or automatic
redial features currently exist. The modem may be dialed by typing ATDT
plus the phone number, followed by the ENTER key. For example, one might
type: ATDT1-800-555-1212. Any valid AT command can be sent to the
modem, making this mode a handy way to make configuration changes to your
modems.

Full ANSI capabilities are built into this mode; however, no file transfer
facilities exist at this time. This feature, as well as a dialing directory,
the ability to chat with users on other local nodes while also chatting with
users on the board that is being called, and lots more is planned for future
releases.

There are few special keys in outgoing mode. F1 will bring up a menu of
baud rate choices, and allow you to change the baud rate setting (auto baud
detection is NOT done when an outgoing call is made). Also, pressing ALT-H
will hang up the modem.

































rOverBoard BBS Software
Version 2.0
- 52 -

Misc. Notes:

On-line help is available on TWW (301-322-8678), in message area #20.


  3 Responses to “Category : BBS Programs+Doors
Archive   : RVR20C-2.ZIP
Filename : ROVER.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/