home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hall of Fame
/
HallofFameCDROM.cdr
/
rbbs
/
rbbsdocs.lzh
/
RBBSDOCS.APH
< prev
next >
Wrap
Text File
|
1990-11-05
|
14KB
|
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".)