home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hall of Fame
/
HallofFameCDROM.cdr
/
rbbs
/
rbbsdocs.lzh
/
RBBSDOCS.17
< prev
next >
Wrap
Text File
|
1990-11-05
|
19KB
|
335 lines
MESSAGE AREAS WITHIN RBBS-PC 17-1
17. MESSAGE AREAS WITHIN RBBS-PC
--------------------------------
RBBS-PC is intended to be an open system. As such it can have an unlimited
number of message areas and messages. At the very minimum, RBBS-PC has a
single
1) message area, a file named MESSAGES,
2) user file, a file named USERS, and
3) definition file, a file named RBBS-PC.DEF
In addition to this, additional messages areas can be created as either
"conferences" (i.e. areas that use the same RBBS-PC.DEF file as the main
RBBS-PC message area) or "sub-boards" (i.e. areas that have their own .DEF
file).
17.1 "Conferences" and "Sub-boards" -- the Differences
------------------------------------------------------
A "conference" or "sub-board" can be:
1) "public" -- any caller can join.
2) "public with a separate user file" -- any caller can join and RBBS-PC
remembers the last message read by each caller and will notify a
caller on logon that new mail is waiting.
3) "semi-public" -- only callers with security levels equal to or greater
than that specified for the conference can join.
4) "semi-public with a separate user file" -- only callers with security
levels equal to or greater than that specified for the conference can
join and RBBS-PC remembers the last message read by each caller and
mail waiting.
5) "private with a separate user file" -- only callers who have been
pre-registered in the separate user file for the conference can join
and RBBS-PC remembers the last message read and mail waiting.
A "sub-board" is just a conference that also has a configuration definition
file (.DEF). Sub-boards can be public, private, or semi-private. Access
to a sub-board is controlled by the configuration parameter 123 which sets
the minimum security level required to enter the "sub-board." A
"sub-board" configuration file has the same format as the RBBS-PC main
configuration file, and is created and edited using CONFIG.EXE. This
allows a "sub-board" to have its own unique welcome file, commands,
security levels, menus, help, bulletins, directories, and up and download
areas. "Sub-boards" can share as much or as little as desired with other
conferences or other "sub-boards" within the same RBBS-PC system. The only
things a "sub-board" cannot change are the primary MESSAGES file and the
communications parameters used by the RBBS-PC it is running under.
To the caller, a "sub-board" appears just like another bulletin board,
accessed from a bulletin board rather than through a telephone number.
Public sub-boards, just like public boards, are those whose minimum
security to join is not higher than the default security for new users.
"Sub-boards" basically allow a single telephone number to offer very
different types and levels of services. Independent "sub-boards" run under
the same RBBS-PC service radically different types of terminals/PC's.
Within the same RBBS-PC, one "sub-board" may have 80 column menus for IBM
and compatible PC callers, another may have 40 column menus for Atari and
Commodore PC users, and still another may have 20 column menus for those
using telecommunications devices for the deaf (TDD's). No longer is it
necessary to provide three independent telephone numbers for three such
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 17-2
different services. All callers can dial the same number and simply switch
over to the appropriate board. Extra lines can be added to a roll-over and
service all the boards. "Sub-boards" make it much easier and feasible for
a SysOp to market bulletin board services by allowing hardware to resources
to be pooled under one software "umbrella" such as RBBS-PC and yet service
a very diverse set of requirements -- much the same way that Compuserve
does. One of the best hardware configurations for running a multi-board
service like this is PC-Slaves, because adding additional boards are
extremely easy, with virtually no system degradation.
"Sub-boards" greatly benefit "umbrella" organizations. For example, a
computer club that covers IBM computers, Apple, Atari, and Commodore. No
longer does software intended for one type of computer have to get mixed in
with listings for another computer. Each computer can have not only
separate messages, but bulletins and directories as well.
"Sub-boards" make it easy to have different "levels" of service based on
security level. Many SysOps run both a "free" and a "subscription" board.
The most typical arrangement for this is to have the free board be on the
bottom of a telephone roll-over and the pay board be on the top, and for
the top board to require a higher security level. Non-subscribers who call
the pay board number get "kicked" off the board. "Sub-boards" on the same
telephone line would give both paying and non-paying callers equal access,
if desired. Another example is that callers with enhanced security can
join a sub-board to get access to even more downloads. Or, executive
officers for an organization can have access to a "sub-board" that has not
only special messages but special bulletins and files.
The naming conventions of the files associated with a "conference" or "sub-
board", for example called CLONES, would be:
CLONESM.DEF --- the message file
CLONESU.DEF --- the user file
CLONESW.DEF --- the "welcome" file (for conferences only)
CLONESC.DEF --- the configuration file (for "sub-boards" only)
Using the configuration .DEF file associated with a "sub-board" allows each
SysOp to make the "sub-boards" as unique or similar as desired. Two
security levels are very important. The minimum security to log on to the
board determines who can join the "sub-board". And the default security
level is what newly added callers are assigned.
A "sub-board", like any conference (public, semi-private, or private) is
closed to all who have insufficient security. To make a "sub-board"
completely private, simply set the minimum CONFIG parameter 123 (the
minimum security level a new user needs to logon) to be higher than any
normal caller would have. The only way for callers to be able to join a
completely private "sub-board", like a private conference is for the SysOp
to have added them previously to the users file associated with that "sub-
board".
The security level a caller gets when auto-added is the default security
level for the "sub-board" and not the current security level of the caller.
This is to prevent special privileges that a caller has in one "sub-board"
from automatically propagating into other "sub-boards". For example, a
caller with SysOp privileges in one "sub-board" who joins another does not
become receive SysOp privileges in the other.
MESSAGE AREAS WITHIN RBBS-PC 17-3
The security level used to determine what "sub-boards" a caller can join is
not the current security level but the original security level the caller
had on the main board.
RBBS-PC detects if the bulletins in the "sub-board" are the same as in the
main RBBS-PC system and does not re-display them when a "sub-board" is
joined.
"Sub-boards", public conferences, semi-private conferences, and private
conferences can all co-exist within the same RBBS-PC system. Sub-boards in
turn can have sub-boards in them, as well as public, semi-private, and
private conferences.
The primary disadvantage of "conferences" or "sub-boards" that have
separate user files associated with them is the additional disk space that
is required for the users file. RBBS-PC's CONFIG parameter 290 allows the
SysOp to let a user on as a "guest" if there is no more room left in the
users file for the "sub-board", semi-private conference, or private
conference. Not having a user record defeats one of the main mechanisms
for remembering a user's preferences, of course, but the SysOp can start
with a smaller users file and expand later without the risk of denying
callers access.
Obviously, "sub-boards" take more time to set up and maintain. While it is
nice to be able to have parts of RBBS-PC vary radically from one another,
every one that does vary is another item to create and maintain. "Sub-
boards" can multiply the work necessary, for example, to maintain
bulletins. There are more users and message files to oversee. However,
Kim Wells MU-EDIT is an invaluable tool for managing multiple message and
user files. Give Kim's RBBS-PC call at (301) 599-7651/7652 and get a copy
of MU-EDIT.
17.2 Making a "Conference" or "Sub-board" Successful
----------------------------------------------------
To make a "conference" or "sub-board" successful several guidelines should
be followed rather rigorously:
1) Establish a "conference" or "sub-board" chairman (i.e. a SysOp) to
manage the conference. The SysOp's job is to add new users, delete old
ones, make sure that the subject and/or the agenda of the conference
is adhered to by killing messages that are inappropriate. This is
best accomplished by having a separate user file for each "conference"
or "sub-board" in which the caller only has SysOp privileges when in
the specific "conference" or "sub-board."
2) Establish an "agenda" or list of subject areas for the "conference" or
"sub-board." One of these should be about new subject areas. These
areas should be VERY narrow in scope. The essence of any good
conference is keeping it focused. Everyone has been in at least one
meeting/conference that was a waste of time because whoever was
running the meeting/conference did not keep the dialogue centered on
the subject or agenda.
3) If a continuity of dialogue is to be achieved, it is advisable to keep
the conference "focused" -- either by keeping the number of conference
members limited, or by keeping the subject matter very narrow.
Another interesting thing about "private" conferences and sub-boards
as implemented within RBBS-PC is that they are not "public" and,
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 17-4
therefore, are even more protected by the first, fourth, and fifth
amendments.
17.3 Setting Up a "Conference" or "Sub-board"
---------------------------------------------
The SysOp sets up a "conference" using the CONFIG utility parameter 167 to
pre-format up to two files -- one for the messages to be associated with
the conference and one for the users to be associated with a conference.
The name of a "conference" can be from one to seven characters that are
valid for a file name. RBBS-PC will add "M" (for the messages file
associated the conference) or a "U" (for the users file associated with the
conference) to the filename. The SysOp can then enter the conference
member's names in the conference USERS file by using the SysOp function 5.
The SysOp can "join" any conference and need not be in any particular
conference's USERS file.
Like "conferences", RBBS-PC supports an unlimited number of "sub-boards".
"Sub-boards" are equally easy to create. If CLONES were the name of a
public conference (the CLONES message file CLONESM.DEF exists), all that
would have to be done to make CLONES a "sub-board" would be to run CONFIG
to
1) create a separate user's file, CLONESU.DEF, for this formerly public
conference (if didn't already have a users file),
2) create a "sub-board" configuration file for the CLONES "sub-board"
(a file whose name would be ATARIC.DEF).
The easiest way to make a "sub-board" configuration file is to use the DOS
copy command, starting with another configuration file as a model (e.g. the
one for the main board). To continue with the CLONES example you would
issue the DOS command:
COPY RBBS-PC.DEF CLONESC.DEF
Then invoke CONFIG.EXE to edit that file, using the form
CONFIG CLONESC.DEF
WARNING!! When you create a .DEF file by copying another one as a model,
be sure to run CONFIG against this new file and change the message and user
file names! Otherwise your sub-board will share the user file with another
message base. Here change the message file name to CLONESM.DEF and the
user file name to CLONESU.DEF. The users file name can be anything for a
"sub-board" but the extension .DEF is a good idea because RBBS-PC's
security system will not let any file with that extension be downloaded.
Remember, you do not want to allow callers to download any users file! You
get an extra layer of protection if you put the message, user, and
configuration files in an area not available for downloading.
17.4 Conference File Locations
------------------------------
The files that make up a conference or a sub-board can be placed in several
locations. Especially on multi-node BBSs, care must be taken when locating
conference files.
If a sub-board CONFIG files exists, it must either be in the RBBS-PC
default directory, or in the directory where the MAIN message file is
located. NOTE: If a caller joins a sub-board from within another sub-
board, the MAIN message file location would be the location of the first
MESSAGE AREAS WITHIN RBBS-PC 17-5
sub-board. Once a sub-board CONFIG file is found, all other file locations
will be set by the CONFIG file parameters.
If there is no CONFIG file, RBBS-PC will next look for a MESSAGE file.
First, the subdirectory where the current MAIN message file is located will
be searched, and then the directory where the conference description file
is located (see CONFIG parameter 74) will be searched.
To find the USER file, RBBS-PC first looks where the current MAIN user file
is located, and then in the RBBS-PC default directory.
This may seem complex, and for most SysOps, placing all CONFIG, MESSAGE and
USER files in the default subdirectory is adequate. CONFIG will create,
and locate conference and sub-board files properly when parameter 167 is
slected.
17.5 Establishing a "Conference" or "Sub-board" SysOp
-----------------------------------------------------
RBBS-PC has one of the more flexible and powerful systems for supporting
"assistant SysOps" or "conference moderators". A moderator need not be
made a full SysOp, and whatever security a moderator has, does not transfer
to the rest of the board. Moderators need the following basic functions:
1) read and kill all messages,
2) add and modify users, and
3) forward mail to a better person to answer it.
The ability to do user edits is controlled by the security specified by
SysOp function 5. Incidentally, moderators cannot edit user records with
security higher than theirs. The ability to read and kill all messages is
controlled by a security level specified in CONFIG. RBBS-PC supports
having separate user files for every message area, so that moderator
privileges in one area do not necessarily transfer to others.
To set up a conference or sub-board moderator, the SysOp need only
1) "Join" the conference or sub-board.
2) Use SysOp function 5 to enter the name of the user who is to be the
conference chairperson into the conference's USERS file.
3) Set that users security level in the conference's USERS file to a
security level that can issue the SysOp function 5. This will allow
the conference chairman to add users.
4) Set the minimum security to read and kill all messages to the level of
the moderator.
5) Set the minimum security to change the minimum security to read a
message to the security level of the moderator. This will allow the
moderator to forward everyone's mail.
Any registered user can join a "public" conference or sub-board. When
someone issues the J)oin command to join a conference or sub-board, their
standard security level is temporarily superseded by the security level
associated with their user name within that conference's or sub-board's
USERS file if it is a "private" conference.
For example, a normal user might be given the security required to add
users to a particular conference or sub-board USERS file since they are the
SysOp of that message area. When a user joins the conference or sub-board
of which they are chairman, their normal security is bumped up so that they
can add users to the USERS file of that particular message area. When the
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 17-6
same user exits that message area, their security level is returned to
normal. If they should subsequently join another message area where they
are not chairman, they would be unable to add users to that message area's
USERS file. Other than a message area's SysOp, none of the message area
members should be given any higher security than they otherwise enjoy as a
regular RBBS-PC user.