ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / RBBSDOCS.ZIP / RBBSDOCS.17 < prev next >

Wrap

Text File | 1990-11-05 | 18.4 KB | 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.