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.APH < prev next >

Wrap

Text File | 1990-11-05 | 13.5 KB | 244 lines

APPENDIX H -- Running a multiple node RBBS-PC H-1 APPENDIX H -- Running a multiple node RBBS-PC --------------------------------------------- Before you consider running multiple nodes (i.e. allowing more than one caller on your BBS at a time), you should already have RBBS-PC working well on one node. If you don't have your board running smoothly with NO crashes, STOP right here and concentrate on your single-node system. You will only compound your errors and frustrate yourself if you try to get RBBS-PC operating on multiple nodes before you get it operating well on one node. When configuring a multi-node RBBS-PC, you may have to make a decision of SPEED vs. STORAGE. In a LAN environment, accessing data stored on another machine is slow. Therefore, you may want to keep copies of ALL text files on each machine, and ONLY share those files that are mandatory (MESSAGE, USER, UPLOAD dirs). However, to do this you will have to keep nearly ALL RBBS-PC files updated on EACH RBBS-PC machine. This can waste storage, increase maintenance hassles, but it does greatly improve performance on a LAN. Other single-machine environments (such as DESQview, PC-Slaves) do not require you to make this choice. To make multi-node operation easier, you may want to put all "node- specific" files in separate directories (i.e. C:\RBBS\NODE1, C:\RBBS\NODE2, etc.). This will reduce the chances of having one node overwrite a file from another node. The following example assumes you have created a NODE subdirectory for each node on your system. There are certain parameters in the CONFIG utility which you will want to consider adjusting in order to facilitate your multi-node RBBS-PC. To begin with, you will need to make an CONFIG .DEF description file for each node. Copy the file RBBS-PC.DEF to RBBSnPC.DEF, where "n" is the number for the node (e.g. RBBS1PC.DEF, RBBS2PC.DEF, etc.). You will need a configuration description files for each node, even if it is a "local" node without a modem. When you start the CONFIG utility, you can either specify the configuration description file name after the CONFIG program name on the command line (e.g. CONFIG RBBS1PC.DEF), or you can let CONFIG ask you whether you will be running multiple RBBS-PCs, answer the question with "Y", and then specify the number of the node you wish to edit (answering "1" at this point would then edit RBBS1PC.DEF). The CONFIG parameters that you will probably want to change in your multi- node system are as follows: 161 Maximum number of concurrent RBBS-PC's. Set this to the maximum number of nodes you will ever run. Remember that you need to allocate space for your local nodes, also. This causes more space to be allocated in the MESSAGE files. You can change this number at any time, and CONFIG will create the needed room, however the only harm in allocating EXTRA nodes is 128 bytes of wasted disk space per node. 162 Environment running multiple copies. Select whichever network type describes the environment you are running. If you have some doubt as to which type fits your network, select NETBIOS (DOS SHARE). NETBIOS is a fairly universal network interface for applications software, and most LAN products offer support for it. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL H-2 88 System file for recording comments. You can set a different comments file for each node you are running (NODE1\COMMENTS and NODE2\COMMENTS, for example), but RBBS-PC can allow a single, shared comments file in all but the CORVUS network. 90 Caller log files. RBBS-PC does NOT share log files between nodes. Each node must have a separate log file (NODE1\CALLERS, etc). If all nodes write to the same callers file, you will not be able to figure out which node did what! 93 File controlling scan for mail waiting. If, for some reason, you want to have some conferences or sub-boards visible on only one of your nodes, you have the option of creating separate conference mail control files (e.g. NODE1\CONFMAIL.DEF, NODE2\CONFMAIL.DEF, etc.) This is certainly not required, however, and most installations will run with identical conference mail control files. 100 File built dynamically to open a door. RBBS-PC creates an batch file for each node when dooring. This batch file must be unique for the node. Name yours NODEn\RCTTY.BAT, where "n" represents the node you are configuring currently. 104 The .BAT file to re-invoke RBBS-PC. If you do not make your RBBS.BAT file read-only, you might have problems when several nodes attempt to access it at the same time. In most cases, this can be avoided by marking the .BAT file "READ ONLY," but you may have to have a unique BAT file for each node of RBBS-PC (e.g. RBBS1.BAT, RBBS2.BAT, etc.) 204 Drives available for downloading. Make certain to list not only the drives from the computer local to the node, but also the network drive letters. We recommend using the DOS SUBST command to make the references to local drives match those that the remote machine refers to them as. For example, if the remote machine refers to your drive C: as drive W:, then use the DOS SUBST command and refer to it locally as drive W:, also. It will reduce confusion for you to only refer to a drive by one name. Remember, you can have up to 15 letters, no more. Now save these CONFIG parameters, and you will have a "network ready" configuration description file. You can copy this .DEF file for the other nodes, and then change the node-specific parameters for each. Remember, each node gets its OWN file! Remember also that each node is likely to have a different modem. Not in ALL cases, obviously, but it justifies a reminder here. Let's take a typical example. On one node, you are using a Hayes 2400 compatible modem, and on the other a US Robotics Courier HST. Obviously, the setup is greatly different between these two. It's not a problem with RBBS-PC, however. When you have CONFIG loaded and are editing the node's configuration description files just remember to put the proper information FOR THAT NODE into CONFIG parameters 221 (Comm port), 225 (Modem settings) and 231 (Firmware initialization). Each node can have a different modem, use a different COM port, run at different speeds, or even use a FOSSIL driver or not, and RBBS-PC can easily adjust to it. AUTOEXEC.BAT In the AUTOEXEC.BAT file for each node, you will want to add the following environment variables. APPENDIX H -- Running a multiple node RBBS-PC H-3 SET NODE=n (where "n" is the node number) SET DSZLOG=XFER-%node%.DEF There may be other variables also required by your individual setup, but the RBBS.BAT file expects to find the %node% variable, and some external file transfer protocol drivers (DSZ, especially) will use the DSZLOG file to pass success-or-fail back to RBBS-PC. You need a separate one built for each node, and this will take care of it. SUB-BOARDS If you have sub-boards set up, you will create a configuration description file for each sub-board. However, the configuration description file will not have a node number in its title. The configuration description file name will take the form "xxxxxxxC.DEF", where "xxxxxxx" is the 1-7 character sub-board name. For example, a sub-board named GAMES would have a configuration description file named GAMESC.DEF. This is a major difference from the configuration description file for the nodes themselves. Each node has its own file, because each node is completely different (usually). But with a sub-board, parameters about the modem, etc., are not needed. Therefore, there is only ONE configuration description file for each sub-board. RBBS-PC will search for a conference .DEF file in THREE places (and in the following order):3 - The default drive/path (when RBBS-PC starts) - The location of the CURRENT message base (the one active when the JOIN command is used). - Where the CONFERENCE menu file is stored (see CONFIG parameter 74). Here's an important tip to help with sub-boards functioning on multiple nodes. CONFIG parameter 90 controls the system callers file. Select this parameter, and when CONFIG asks you if you want to have a callers file, answer "N". This will cause the sub-board to use the same callers file that the node is currently using. Since you only have one configuration description for each sub-board, specifying a callers file in the sub-board configuration description file would cause information from both nodes to be written to the same callers file, and this would be mass confusion. DOORS Many door programs (especially older ones) are simply not network compatible. Some of the doors that you have been running for years will suddenly not work in a network. Each door is an individual case. Some doors are hard-coded to pick up DORINFO1.DEF and cannot be made to read DORINFO2.DEF. Others are locked into COM1 and cannot be forced over to COM2. And still others force you to have DORINFO1.DEF in a directory called "C:\RBBS" and will refuse to look anywhere else for the possibility of a second node's files. When you have a door which is network compatible, usually the documentation that accompanies the program will explain in detail how to install the door on your BBS. In general, a door program is installed in one location on the network, and all nodes will run the door from that subdirectory. RBBS-PC will create a DORINFOn.DEF, where "n" is the node number, when it exits to a door. Almost all door programs want to know where this file is, and a variety of options are available to you. One option often used is to set an environment variable to the drive letter that will be the default drive for a specific node. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL H-4 For example, let's say that our Node 1 system runs from W:\RBBS, and our Node 2 system runs from Y:\RBBS. If we set an environment variable in each node's AUTOEXEC.BAT file called RBBS (e.g. SET RBBS=W:), then we can refer to the location of the DORINFOn.DEF file as: "%rbbs%\RBBS\DORINFO%node%.DEF". (Notice the use of the %node% environment variable, also.) In this way, each node running the door will substitute the proper drive and node number to the door. MISCELLANEOUS TRICKS RBBS-PC is written to share resources with no conflict between nodes. For example, both nodes will access the same message and user files, and at the same time. Under ordinary DOS circumstances, this would cause a "sharing violation" error. RBBS-PC, however, accesses files in "shared mode", which eliminates this error. There are still times, however, when files are accessed outside the direct control of RBBS-PC. To eliminate the possibility of sharing violation errors at these times also, we recommend marking all your TEXT, .COM, .EXE, and .BAT files "read only". (The read only attribute lets DOS know that it's okay for more than one process to access this file at the same time, because NEITHER process will be able to modify it.) To change a file's attribute, you will use the DOS utility ATTRIB. The command syntax is "ATTRIB +R filespec", where filespec can be anything up to and including "*.*". Conversely, "ATTRIB -R filespec" will remove the read only attribute so that the file may be changed. If you are operating your multi-node RBBS-PC with two separate RBBS-PC subdirectories (i.e. all files duplicated in a second location except those which MUST be shared), then this precaution is not needed. If, on the other hand, you are operating your multi-node RBBS-PC with a SINGLE RBBS-PC subdirectory, then we recommend making all files read-only which will not be written to by RBBS-PC. Files which will be written to are the callers files, the user files, the message files and the upload directory. Since these are only opened from within the RBBS-PC program, you will not have sharing problems here. (Note: Some door programs require access to these dynamic files, and do not support shared access. This can cause the door program to malfunction. This would be considered a door program which is NOT "network-able".)