     Running Multiple Machines/Nodes of RBBS with LANtastic
                          By Gary Huff
                     SysOp, Capitol City BBS


I started my BBS several years ago with a single node and one 40
Megabyte hard drive.  However, after several years of operation,
the BBS became very popular and accumulated an ever larger
collection of files.  40 Megs became 130 Megs, then 150, and then
300 Megs.  Finally, even running a machine with 300 megs began to
strain the resources of the board, and I was constantly involved
in cleaning old, unpopular files from the drive to make room for
new ones.  After awhile, I hated to throw away much of the older
software because frequently an older version had some feature or
quality that was missing in the newer version, and discarding any
files became ever more difficult.  Also, the larger file
collection (plus the addition of doors, sub-boards, etc.) made
the board more popular for callers, and soon the board began to
reach "saturation."  That is, it was busy just about non-stop
around the clock, and even routine maintenance was becoming a
problem just to catch the machine in an idle moment.  Clearly,
expansion of both storage capacity and caller nodes was becoming
mandatory.

There are several ways to expand a board.  One is to go to a
larger (and faster) machine.  A 386 machine with a very large
disk drive running under DesqView would have allowed me to run 2
nodes, but looking ahead, I could see that even 2 nodes would not
be enough in time.  Also, I hated to invest in a larger drive
when I already had 300 megs of perfectly good storage in the old
machine, already filled with a nice file collection that would
have to be transferred over to a new machine.  I wanted to expand
what I already had, not replace hardware.

It became more and more apparent that, for virtually unlimited
future expansion, only a network of multiple machines would fill
the bill.  By adding on more machines, each node could have its
own CPU, making 19,200 baud operations very efficient with no
degradation of speed as would be suffered on a single 386 running
several nodes.  Also, existing hardware would not go to waste. 
Current file collections on perfectly good hard drives could
continue to serve indefinitely, supplemented by more "parallel"
drives on other machines.

After reading many magazine articles about Local Area Networks,
it was decided to go with LANtastic.  This decision was based on
economy (LANtastic is one of the lower priced networks), and also
on speed of the network (comparable to networks costing twice as
much), and the ease of adding more nodes at any time in the
future.

A LANtastic 2-node starter kit was purchased, and the fun began. 
It was discovered that the LANtastic documentation does not even
touch on BBS operation, and there was very little in-depth
literature "out there" on operating RBBS in multiple nodes under
a LAN, particularly LANtastic.  The RBBS docs don't even mention
LANtastic.  This document hopes to fill that void for others.

GETTING STARTED:

You will need at least 2 machines.  LANtastic will install in any
types of MS-DOS machine:  8088, 80286, 80386, or any mix of them. 
These machines should be well outfitted with memory, if possible. 
While the LAN software itself only occupies about 40K of memory,
there will be other TSR programs and utilities, plus the actual
RBBS and its associated applications to contend with.  Therefore,
at least 640K of memory is desirable.  The machines do not have
to be high-speed machines.  I am running an 8 MHz 8088 turbo-
clone, and a 12 MHz 80286 AT-class machine.  You can combine the
disk drives on the multiple machines as one large drive.  For
example, if you have a 150 meg drive on each machine, you can
combine their storage for a total of 300 megs of BBS storage. 
You can run up to 4 machines with the software in the starter
kit, which comes with sufficient hardware and cables for 2
machines.  Additional nodes (up to 4) require only an additional
adapter card and additional cable per each machine.  Beyond 4
machines, you will require different NOS (Network Operating
System) software, and more adapter cards and cables, available
from your dealer or Artisoft.  For now, we will worry about
getting 2 nodes set up.

Purchase the LANtastic starter kit.  Prices will vary; while no
recommendation of one dealer over another is made in this
document, I did find a starter kit for $409 from Compuclassics in
California.  You may be able to find it cheaper from another
dealer.  The kit arrives in in a shrink-wrapped box, so it
shouldn't make any difference from where you purchase it.

The kit contains 2 adapter cards, 1 cable, and 2 terminator
plugs, plus instructions.  The small instruction book pertains
mainly to hardware, and the larger book addresses software.  The
adapter cards have a row of dip switches, but you will
undoubtedly not need to change anything on the cards unless you
are running another device in the machine that conflicts with the
address of the LAN card.  The default port address (280-28F) is
normally not assigned in an XT-class machine, and is probably not
used in an average AT-class machine.

Open both machines (slide off the covers), and (with all power
off), locate an empty slot in each machine to hold the adapter
card.  Plug one of the terminating plugs into the back of one
card, and the other plug in the back of the other card  (in any
order).  Then, hook the cable that comes with the kit to the
backs of the adapter cards using the open sockets.  The cable is
polarized, so you can't possibly make a mistake on this
operation.  Slide the cover back on each machine and you are done
with the hardware part of the installation.

SETTING UP:

Each machine will require that you re-write your CONFIG.SYS and
AUTOEXEC.BAT files to install the NOS (Network Operating System). 
Let's discuss each of these files:

CONFIG.SYS:  Here's the CONFIG.SYS file I run:

FILES=50
BUFFERS=30
STACKS=8,256
DEVICE=C:\DOS\ANSI.SYS
BREAK=OFF
FCBS=32,8
LASTDRIVE=Z
SHELL=C:\COMMAND.COM /E:2048 /P

Discussion: I have experimented with Files set between 50 and
100, but 50 seems to be enough.  FILES=100 does not seem to cause
any problems either, and may be needed someday if a situation is
encountered where lots and lots of files are open at once.
BUFFERS=30 has proved to be more than enough, and is probably too
high a number.  BUFFERS=20 has also worked just fine. 
STACKS=8,256 is for DOS 3.3 and above; it increases available
stack space.  (I got a stack error once, and I try to prevent a
second occurrance.)  ANSI.SYS is needed to allow color codes in
RBBS to work, and since I like to look at the pretty screens, it
must be loaded.  BREAK=OFF prevents accidents at 3 AM when I
might forget that I'm on the board and try to break the program. 
LASTDRIVE=Z lets you use any letter to designate any drive in the
machine, and you'll see later why you want to be able to use all
of them.  The SHELL=C:\COMMAND.COM lets programs that shell to
DOS know where to find the DOS command interpreter.  If you get
an "out of environment message, you may need to increase your
environment with the /E switch (DOS's default is 256).  I have
had no problems with 2048, although 1024 is probably more than
large enough.  Like so many things, you add these little files
and switches in response to error messages.  If you never
encounter the error (and you very well may not), then you may not
need them.

Now, you will want to pick unique "names" for each machine in the
network.  Since I started my board on an XT-class 8088, and since
the majority of my file collection was on that machine, I
arbitrarily named that machine "HOST."  And since I added a
second machine that was an AT-class 80286 machine, I arbitrarily
named that machine "286."  Name each machine in your network in
any manner that lets you keep track of which machine is which.

Here's the AUTOEXEC.BAT file I wrote for my HOST (8088) machine:

PATH=C:\;C:\DOS\;C:\LANTASTI\;C:\RBBS\
SET COMSPEC=C:\COMMAND.COM
FATAL /I
LANBIOS2 IRQ=3 NODE=1 SESSIONS=20 NCBS=20 BUFFERS=14 TIMEOUT=40 VERBOSE
REDIR HOST BUFFERS=8 SIZE=1024 LOGINS=2
SERVER
C:\DOS\SHARE /F:2048 /L:100
WAIT4LAN 286
NET LOGIN \\HOST MANAGER MANAGER NODE1
NET LOGIN \\286 MANAGER MANAGER NODE1
NET CLOCK \\286
NET LPT TIMEOUT 10
NET USE P: \\286\D286
NET USE Q: \\286\E286
:: (...all the NET USE drives for other machine are assigned here...)
NET USE LPT1 \\HOST\@PRINTER
CD\RBBS
RBBS1.BAT

Discussion:  This AUTOEXEC.BAT file is lengthy, but you will
want to understand what is happening each step of the way so
you can change it if necessary.  Let's discuss each line:

PATH:  You will want to include every directory that your board
will need to access for various .COM and .EXE files.  DOS, the
LAN software itself, the RBBS files, all are listed in this
PATH statement.  If you have any special utilities or other
routines that you call while operating the board, their
directory will have to be listed in this path statement as
well.

FATAL:  This is a wonderful program that intercepts any "Abort,
Retry, Fail" messages and prevents the board from being hung or
(worse!) crashing if encountered.  Unfortunately, when
operating a LAN, you will occasionally encounter a SHARE
violation (discussed later) that will generate the "Abort..."
message!  FATAL is a LAN operator's best friend.  FATAL14.ZIP
is included in this archive, and its documentation (and
registration) information is included in that archive.  You're
going to need it.  FATAL /I installs FATAL as a TSR before the
LAN software (important!).

The LANBIOS2 command calls up the LAN operating system that we
will be installing shortly in the LANTASTI directory.  IRQ=3
needs some explanation.  The IRQ (interrupt request) that you
want to operate your LAN under must be assigned to an open IRQ
line.  On a well stocked XT-class machine, you will normally
only have 2 interrupts to choose from: IRQ2, which is normally
unused, and IRQ3, which is the second serial port (COM2) on an
XT.  My particular machine only uses COM1, so IRQ3 was open. 
If you have an XT with 2 COM ports, then you will have to set
IRQ=2.  AT-Class machines have different IRQ's open, and those
will be discussed in a few moments.  Node=1 is reminding me
(and the machine) that this machine will be Node 1 of the BBS. 
The rest of the command line can actually be left out and the
defaults of the LANBIOS accepted as-is.  I decided to play with
some of these settings in the AUTOEXEC.BAT file, but I have
also tried leaving the rest of the line off, and it works. 
Read the LANtastic documentation for a full explanation of the
rest of the LANBIOS2 command line.

Now it's time to tell the machine that it's going to become a
LAN workstation (a terminal on the LAN), and this is done with
the REDIR ( redirector) command.  The REDIR line instructs the
machine that it will be known on the LAN as "HOST," and that it
will set aside some space in the operating system for network
operations.  BUFFERS and SIZE can be adjusted upward, but be
careful to read the LANtastic docs about how to calculate these
numbers if you decide to change them.  LOGINS=2 lets me log
into the host both locally and from another machine (the other
node).

We also want to be able to extract files from the machine, so
we want it to serve not only as a workstation but also as a
SERVER (a machine that provides services to the LAN rather than
just drawing from the LAN).  The SERVER command tells the
machine it is going to do this job as well.   (Important: you
must call up these commands in the order in which I have given
them, or you will get error messages and incorrect LAN
operation.

DOS was never written to enable multiple access to files.  If
two machines attempt to access a single file, DOS gets
flustered and thinks that both users are going to try to change
a file simultaneously and might scramble something.  Therefore,
it will not allow more than one file access at a time.  This is
not acceptable to a multi-node BBS, which is accessing the same
file at the same time on frequent occasions.  DOS therefore
provides a file called SHARE.EXE, and it must be loaded to
stand guard over multiple file accesses.  See your favorite DOS
manual for more details about this command.

Now we're ready to get down to business, but since this machine
is both a server and a workstation, it needs to access certain
information from the other node as well.  A very nice program
called WAIT4LAN checks to see if the other node is booted up
yet (one machine is always a little faster or slower than the
other), and if it doesn't find the other node booted yet, it
waits 10 seconds and looks again.  It repeats this for 180
seconds, or until it finds the other node active, at which
point it can proceed with the rest of the setup.

OK, WAIT4LAN found the other node active, and dropped through
to the next command.  We must log on to the LAN, both for our
own machine (HOST), and also for the other node (286). 
Remember, we're going to use files and facilities of both
machines, back and forth, so we have to log on to each of the
other machines.  We log onto our own machine with the NET LOGIN
command, telling the machine which machine we wish to log into,
giving our user's name and password (I have named myself
MANAGER and assigned myself a password of MANAGER.  You can
call yourself anything you like, or not have a password at all
if you like.  Since this is a closed LAN, it doesn't matter.) 
And we want to use this machine on NODE1, so we specify that.

We also want to log onto the other machine (286), and so we use
the same login procedure.  For uniformity (and to keep me from
forgetting), I've assigned my user name as MANAGER and password
as MANAGER on all the nodes, so I only have to remember one
word.

Every PC has a built-in (or added) clock.  Some machines have
clocks which are a little more accurate than others.  Since my
XT machine gains about a minute a month, I have elected to use
the clock in the 286 machine, which is a little more accurate. 
The command NET CLOCK can be set for whichever machine you have
that is most accurate.

The LPT timeout command gives the network time to handle
printing commands in due time, should the machine be busy with
something else at the exact minute you command the printer to
be used.  I have selected 10 seconds as appropriate.

Now let's define which drives on the other machine we're going
to want to read for files.  A little later, I'll show you how
to set these drives up on the other machine, but for now, let's
choose letters higher than any you have on your current
machine.  My XT has two floppies (A and B), 10 logical DOS
drives (C,D,E,F,G,H,I,J,K and L), and I have a device driver to
let me use my 3.5" floppy on my old XT, so letter M is taken up
by the device driver.  For reasons that will become clear
later, I'm going to start naming with the letter P because O
will be used by the other machine to refer to a drive on the
first machine.  See explanation later.  Later, I'll set drive D
in the other machine as drive P on the host, and drive E will
become Q, F will become R, etc. etc.  RBBS lets me have up to
15 drives for files, incidentally.  If I wanted to go beyond 15
files, I'd have to start using disk manager software to
increase the size of my DOS partitions and therefore cut down
on the number of logical drives.  For now, assign a letter for
each drive you want to use on the other machine.  You can even
use the other machine's floppies if you want to.  I have
arbitrarily started with drive D on the 286.

I have a printer hooked up to the XT machine, and I'd like to
be able to use it to print out jobs from either machine, so I
assign the printer (LPT1) for network use.  If I had, say, a
dot matrix printer on one machine and a letter quality printer
on the other machine, I could assign both printers for network
use.  In this case, though, I'm going to share one printer with
2 machines.

OK, the network has all been called up, and I'm ready to switch
to RBBS.  I keep my node 1 in a directory called RBBS, and I
call up node 1 with RBBS1.BAT.  I'll show you how to set up
RBBS later.  For now, let's get the LAN working, then we'll go
on.

NODE 2:

The second machine will need its own AUTOEXEC.BAT and
CONFIG.SYS files.  The two CONFIG.SYS files can be identical,
or you may require different driver software on the second
machine.  For example, you might be using Disk Manager on one
machine but not the other.  If you do need any different device
drivers, insert them into the appropriate machine's CONFIG.SYS
file.

AUTOEXEC.BAT for the second node is called up in a similar
manner to Node 1, only this time we're going to want to tap the
resources of the first machine.  Let's see how we do that:

PATH=C:\;C:\DOS\;C:\LANTASTI\;C:\RBBS2\      'note different directory
FATAL /I
LANBIOS2 IRQ=5 NODE=2                        '286 uses different IRQ now
REDIR 286 BUFFERS=8 SIZE=1024 LOGINS=2
SERVER
SHARE /F:2048 /L:100
WAIT4LAN HOST                                'wait for other node (HOST)
NET LOGIN \\HOST MANAGER MANAGER NODE2       'call HOST into second node
NET LOGIN \\286 MANAGER MANAGER NODE2        'bring up this machine, too
NET LPT TIMEOUT 10
NET USE F: \\HOST\ROOT                       'see explanation below
NET USE G: \\HOST\DRIVED
NET USE H: \\HOST\DRIVEE
NET USE I: \\HOST\DRIVEF
NET USE J: \\HOST\DRIVEG
NET USE K: \\HOST\DRIVEH
NET USE L: \\HOST\DRIVEI
NET USE M: \\HOST\DRIVEJ
NET USE N: \\HOST\DRIVEK
NET USE O: \\HOST\DRIVEL
NET USE LPLT1 \\HOST\@PRINTER
CD\RBBS2                                   'Node 2's directory
RBBS2.BAT                                  'Node 2's bat file

Now you see why I couldn't use drive O on the other machine:
because I'm going to reassign drive L from the other machine to
be referred to in node 2 as drive O.

You will have to adjust the drive letters to suit your
particular installation.  Remember, I said I had 10 logical
drives on the old XT machine, but I am using Seagate's Disk
Manager on the newer machine, and I can get by with using only
3 logical drives (C,D and E) to manage the entire disk on the
second machine.  If I want to expand down the road, I'll
probably have to go in and re-format the XT's drives with Disk
Manager to cut the number of logical drives down and allow for
larger drives on other machines.

An AT-Class machine has more interrupts available for possible
assignment to the LAN.  Since I did have a second COM port
(COM2) on the AT, I chose IRQ5 (a second parallel port) because
I had no second parallel port in use.  I could also have used
IRQ 2, 10 or 15 on this machine.

INSTALLING THE LAN:

We've got the boot-up files ready to be used with our LAN. 
Now, let's install the LAN itself.  Fortunately, LANtastic's
documentation is good on how to install the LAN.  Follow the
books' instructions (just in case they've changed it since I
wrote this).  Basically, you're going to create a directory on
each machine's C: drive called LANTASTI and copy all the
LANtastic files into this directory on each machine.  For some
reason, I found that it was better to run the LANBIOS program
from the floppy rather than the hard drive.  When run from the
hard drive, some files were getting scrambled, and it took me a
few tries to figure out what was happening.  So, you will want
to make a backup of the LANtastic disk and run LANBIOS2 from
the floppy. (Older LANtastics called for a program called
LANBIOS, but the version I have calls for LANBIOS2.  Read your
docs to see which version you have and call it up accordingly.)

The machine will give you a Netbios message, pause a few
moments, and finally inform you that the NETBIOS software has
been installed.  You are now ready to set up your network
software for your particular installation.

Discussion:  You are going to have to define several things
here:  You're going to need to tell the network who you are,
who other users are (other machines), and the drive
configuration for each machine.  We will do this via the
NET_MGR program.  Calling up NET_MGR, you will be presented
with a colorful menu.  Select the first choice, USER ACCOUNT
INFORMATION, by pressing Enter.  Now, you will want to enter
yourself as user on the first line.  I call myself MANAGER, so
hit the Ins key (the number 0 on your 10-key pad) and type
MANAGER (or whatever name you pick for yourself... DICTATOR
might appeal to you more).  Now, cursor down to this newly
created line and press Enter again so you can define who
MANAGER is.  In the window that pops up, defind your password
(I'm lazy, so I picked MANAGER for my password), skip the
description line, and go to the Privileges line.  Assign
yourself AQMU (but NOT P... trust me for now).  Number of
concurrent logins for your 2-node installation will be 2.  Now,
hit the Escape key and press Ins again and enter NODE1 for the
next line.  Cursor down, and select NODE1 to modify.  Assign
NODE1 exactly the same privileges and definition as you did
MANAGER.  Escape back to the first menu and define NODE2 in
exactly the same way as you did MANAGER and NODE1.  (I use
MANAGER for the password for all of them.  You don't have to
have a password at all, but I did it before I discovered that.) 

Now hit Escape again, and you are back at the original Net
Manager screen.  Let's now go to work and hit Network Access
Information.  If you're on the first (node 1) machine, let's
define your disk drives on that machine.  I have arbitrarily
called each drive as DRIVEx, where x is the actual drive letter
for that node.  the D: drive is called DRIVED, so hit the Ins
key and type DRIVED for the D: drive.  Then, assign the path
for that drive, and call it D: and repeat for every drive you
want to put on the LAN.  Drive E: becomes DRIVEE and is pathed
to E:, drive F: becomes DRIVEF, etc.  Do this for each drive. 
In my example, I have defined through DRIVEL.  I also want to
be able to get to the C: drive, so I call that drive ROOT and
the path as C:.  I also define two more links:  @MAIL is pathed
to MAIL, and @PRINTER is pathed to LPT1.  (Remember, I have a
printer on this machine, and I want to use it in the LAN.)

After defining every drive on the LAN for the machine, hit
escape a couple of time and you should be back to your DOS
prompt.  Look on your root directory and you should have a new
directory called LANTASTI.NET.  If you CD\ to this directory,
you will see sub-directories with each name of each drive as
you have defined them... so you'll have a directory with
entries like this:  C:\LANTASTI.NET\DRIVED,
C:\LANTASTI.NET\DRIVEE and so on.  The sub-directories will be
empty, so don't worry about there being nothing in them.

Now, let's go over to the second node and run NET_MGR on that
machine.  We will set up our User's Information exactly as we
did on the first machine.  Our network access information for
the second machine is going to assign what devices from the
second machine are to be available to the network.  To
eliminate confusion, I have arbitrarily named these second
drives with the drive letter and the machine identification,
i.e., drive D on the 286 is called D286, E is called E286 and
so on.  That way, if I talk about DRIVED, I know I'm talking
about the D: drive on the XT, not the D: drive on the 286.

A hint here:  You can have some continuity in your network by
using the DOS SUBST command to assign letters higher than those
on the other machine to the second machine's drives. 
Therefore, in my situation, since I call Drive D: on the 286 as
Drive P from the XT, I could add SUBST P: \D:, Q: \E:, etc. to
the AUTOEXEC.BAT file on the 286 machine right after the PATH
statemnt.  Then, when I call up P: from either machine, I'd get
D: on the 286 and wouldn't have to try to remember which
machine I was on to call which drive what.  Do it whichever way
is easiest for you.  (I'll probably change my setup at a later
date to do it this way, but for now, everything is working and
I'm not changing anything.)

After defining your drives on the second node, exit back out of
NET_MGR and check the LANTASTI.NET directory to see if the
drives have been defined the way you named them.  If they have,
you're ready to start up your network and get to work on RBBS.
By the way, for simplicity's sake, REM out the lines calling up
the CD\ to the RBBS directories and the RBBS1.BAT and RBBS2.BAT
files, since we're not yet ready to run our RBBS software. 
We'll pull out the REM statements later.  Right now, we just
want to get the network up and running, and land at a DOS
prompt.

Cold-boot both machines simultaneously.  Both should come up,
and one will load a little faster than the other.  The one that
loads first will give a message that it is checking the other
node, and finds it not active.  It will pause while the other
node boots up its server.  When it does, the faster machine
will find the other LAN station active, and both machines will
continue on and if all goes well, you should find both machines
sitting at the C: prompt.

Now, when you go to either machine, you should be able to call
up directories in either machine.  In my example above, when I
am on the XT, I can call up all the XT's drives as usual, but I
find I have a couple of new ones up at P: and Q:... those
should be the D: and E: drives on the other machine.  I can
list directories, use the TYPE statement to look at text files,
I can delete files, just about anything that I could do if I
were sitting in front of the other machine.  (There are about
12 DOS commands I CAN'T use... see any good DOS manual for a
discussion of which DOS commands can't be used... CHKDSK, for
example.)

Check both machines out.  Go to the second machine (in my case,
the 286), and call up the directory letters above where my disk
normally leaves off.  In my example, I stop at E: on the 286,
so when I call up F:, I get the C: drive in the XT machine.  G:
gives me the D: drive in the XT, and so on.  Neat, eh?  

(If yours isn't working at this point, stop and go back and
check all your work thus far...  make sure your AUTOEXEC.BAT
files don't have spaces where there shouldn't be any, or that
you left out a space where one was needed.  When both machines
boot with no error messages, you've got it right.)

SETTING UP RBBS (Finally!):

Well, you made it this far.  You've got the LAN working on 2
machines.  Now you're ready to set up your RBBS software for 2
nodes.

IMPORTANT NOTE:  I am presuming that you already have RBBS
working well on 1 node.  If you don't have your board running
smoothly with NO crashes, STOP right here and get the board you
now have working right.  Please, DON'T call me for help on
setting up RBBS from scratch... READ THE RBBS DOCUMENTATION and
get it working on one node FIRST.  After you've been running a
few months with no crashes, you're ready for Node 2.

1. Create a directory on the second machine called C:\RBBS2

2. Copy all the .EXE, .COM, .BAT and .DEF files from node 1
over to node 2.  (You can now do this through the LAN,
remember?)

3. Copy RBBS-PC.DEF to a file in the first node's directory.   
Make the copied file as: RBBS1PC.DEF.  Now, copy RBBS-PC.DEF   
to the second node's directory, and name it RBBS2PC.DEF.

4. With both nodes off-line (neither one waiting for a call on
the modem, or you will not be able to modify an RBBSxPC.DEF
file), first go to CONFIG.EXE on node 1.  When it asks if you
will be running multiple nodes, answer YES.  When asked to
which node you want these changes to be made, answer 1.

The numbers in the left-hand column below now refer to the
CONFIG.EXE questions:

161 - Maximum number of concurrent RBBS-PC's.  Set this to the 
      maximum number of nodes you will ever run.  Even if      
      you'll only be running 2 nodes, go ahead and set this up 
      for 4 nodes (the maximum # of nodes that the LANtastic   
      starter kit can handle).

162 - Environment running multiple copies: Select NETBIOS (DOS 
      SHARE).  When it asks if you are running Multilink, tell 
      it NO.  (LANs run better under NETBIOS than they do DOS.)

88  - System file for recording comments: set this for the node
      you will be running.  Set COMMENT1 for node 1, COMMENT2  
      for node 2, etc.  You can still specify that comments be
      recorded as private messages if you wish.

90  - System file for callers:  You must assign a unique name  
      for each node's callers file.  Assign CALLERS1, CALLERS2, 
      etc. as appropriate for the node.

93  - File controlling scan for mail waiting:  If you will be  
      running sub-boards, you will want to set this to a unique 
      name for each node.  CONFM1.DEF, CONFM2.DEF, etc.  (More 
      details about sub-boards follows below...)

100 - file built dynamically to open a door: RBBS creates an   
      RCTTY1.BAT, RCTTY2.BAT, etc. for each node when dooring. 
      Name RCTTYx.BAT for the node you are configuring.

104 - When a door closes, re-invoke RBBS-PC via...   You will  
      have to have a unique .BAT file for each node of RBBS.   
      Call Node 1's file RBBS1.BAT, node 2's RBBS2.BAT, etc.

204 - Drives available for downloading:  You will have new     
      drives to add to your list.  List the letters of the     
      first machine (CDEFGH...) and the letters assigned to    
      the second machine's drives (PQR...).  Remember, you     
      can have up to 15 letters, no more.

208 - Upload and download sub-directories:  It is dangerous to 
      try to upload to the same directory on the same drive    
      from more than one node.  Assign each node its own upload 
      directory.  For example, node 1 might upload to D:\FILES, 
      and node 2 might also upload to D:\FILES, but make       
      certain that you are referring to the individual D: drive 
      on EACH machine, not to the same D: drive on one machine. 
      Specify all your download directories for the first      
      machine:  D:\FILES, E:\FILES, etc.  and add the other    
      machine's drives as you named them.  P:\FILES, Q:\FILES, 
      etc.  Now, when a file search is called for, node 1 will 
      search all of machine 1's drives, and if the file is not 
      found, it will search machine 2's drives as well.

Now, save out these CONFIG specifications, and you should have
a file RBBS1PC.DEF in your directory.  Peek at it with a file
viewing program such as DR.COM and see if the paths and changes
you made are there.

Next, keeping all nodes offline, go over to node 2's machine
and run CONFIG.EXE on the second node.  With a few exceptions,
you can share all of node 1's text files with node 2. 
Remember, your path statements from the second node are now
going to be different.  What was drive C:\RBBS on the first
node's CONFIG will become, say, F:\RBBS on the second node.  Go
through carefully and look at each question that calls for a
path.  Path your help files, text files, MESSAGES, USERS, etc.
to the first node's directory.  Do NOT path to CALLERS1...
remember, you will be setting up a new callers file called
CALLERS2.  Go through the CONFIG questions in the same order as
was called for above for node 1, but change the answers for the
node you are now setting up... for example, RCTTY1.BAT becomes
RCTTY2.BAT, etc.  Be sure to carefully set the path statements
for your files to reflect the directories as seen by the second
node:  what was drive D: on my XT machine becomes drive G: on
my 286, etc.  Go through and check all your path statements
carefully to make sure they point back to the RBBS1 directory. 
However, I keep my CALLERS2 file on my 286 C: drive, also my
COMMENT2, etc.  If you use different brands of modems on the
two nodes, you will need to set up your modem initialization
strings to correspond to the modems in use.  I use a US
Robotics HST 14.4 on my node 1, and an older 2400 baud Hayes
compatible modem on node 2, so I must initialize each
individually.  So will you.

After checking node 2's answers, save them out and you should
now find a RBBS2PC.DEF file containing your answers on your
second node's directory.

NODE 1 RBBS1.BAT file:

WATCHDG1 OFF                           'was monitoring COM1
IF EXIST RBBS1F1.DEF DEL RBBS1F1.DEF   'correct return from a node1 shell
IF EXIST RCTTY1.BAT DEL RCTTY1.BAT     'return from a node1 door
IF EXIST RBBS1TM.DEF DEL RBBS1TM.DEF   'return from a node1 timed event
SET DSZLOG=XFER-1.DEF                  'set for COM1
RBBS-PC 1 RBBS1PC.DEF                  'Important - all this must be here!
IF EXIST RBBS1F1.DEF GOTO EXIT         'normal exit from RBBS
IF EXIST RCTTY1.BAT GOTO DOOR          'exit to a node1 door
IF EXIST RBBS1TM.DEF GOTO EVENT        'node1 timed event
GOTO EXIT
:DOOR
IF EXIST RCTTY1.BAT RCTTY1.BAT         'go to a node1 door
:EVENT
IF EXIST RBBS1TM.DEF EVENT1.BAT        'execute an event for node1
:EXIT

and here's the same file, only written for node 2:

WATCHDOG OFF                           'note syntax for COM2
IF EXIST RBBS2F1.DEF DEL RBBS2F1.DEF   'return from exit from node2
IF EXIST RCTTY2.BAT DEL RCTTY2.BAT     'node2 door RCTTY file
IF EXIST RBBS2TM.DEF DEL RBBS2TM.DEF   'node2 timed event
SET DSZLOG=XFER-2.DEF                  'we're using COM2 on this node
RBBS-PC 2 RBBS2PC.DEF                  'tells RBBS which node to run
echo off
IF EXIST RBBS2F1.DEF GOTO EXIT         'exit from node2
IF EXIST RCTTY2.BAT GOTO DOOR          'node2's door file
IF EXIST RBBS2TM.DEF GOTO EVENT2       'node 2 has a timed event
GOTO EXIT
:DOOR
IF EXIST RCTTY2.BAT RCTTY2.BAT         'go to node 2's door
:EVENT
IF EXIST RBBS2TM.DEF EVENT.BAT         'execute node 2 timed event
:EXIT

Of course, if you were running node2 on COM1 of the second
machine, you would adjust your files accordingly.  These .BAT
files are intended for demonstration purposes only, although
they are complete enough that they could run 2 nodes of RBBS
as-is.  Each node's .BAT files and .DEF files should be in the
directory for that particular node.  You wouldn't want, say, a
door that was entered from node 2 to try to "return" to node 1!

PROTO.DEF

The PROTO.DEF file itself should need no modification for
multiple nodes.  The node and COM port is passed on to the
protocol in each PROTO.DEF command line.  However, certain
protocols will have to be adjusted for multiple nodes,
especially if you are running from a different COM port.

DSZ:  Most DSZ protocols will run fine as-is.  However, don't
forget to modify the DSZLOG=XFER-x.DEF file in each RBBS .BAT
file.  If you are running node 1 on COM 1, then the correct
setting is DSZ=XFER-1.DEF.  However, if you are running node 2
on COM2, then you will have to set DSZ=XFER-2.DEF in that .BAT
file.

PUMA:  Go into PUMASET and check all your settings for each
node.  If you are running different COM ports, then be sure to
define them in PUMASET.  Also, if you are running different
types of modems (i.e., USR HST 14.4 on node 1, Hayes 2400 on
node 2, etc.), you will want to set PUMA for the proper speed
at which to open the modem.

RBBS INTERNAL:  No changes needed here; they should all work
just fine on multiple nodes as-is.

SUB-BOARDS:

If you have sub-boards set up, you are going to have to set up
your sub-board CONFIG files for each node.  However, the
configuration files will not have a node number in their title. 
Each node's directory will have a separate sub-board
configuration file containing setup information for that node,
but the files will each be named the same.  For example, I have
a SYSOPS sub-board containing files of interest to SysOps.  My
definition file is called SYSOPSC.DEF, my sub-board messages
file is called SYSOPSM.DEF, and my sub-board user's file is
called SYSOPSU.DEF.  I can use the same SYSOPSM.DEF and
SYSOPSU.DEF files for all nodes.  However, I cannot use the
same SYSOPSC.DEF file.  Here's the trick to get the sub-boards
to function on multiple nodes:  When CONFIG asks you if you
want to have a callers file, tell it NO.  That way, the sub-
board will be forced to use the callers file as named in the
main board's CALLERS1 or CALLERS2 file.  Go through the sub-
board configuration file in exactly the same order as you did
above for the other nodes.  Copy the resultant xxxxC.DEF file
over to Node 2, and run CONFIG on the configuration file for
the second node in exactly the same order and way that you did
the other node 2 configuration file.

DOORS:

Many doors 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.  You
will probably end up as I did: ruthlessly dump any that
outright crash in a LAN environment, and reconfigure those that
don't.  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.  These doors are very difficult to get running. 
And still others force you to have, say, DORINFO1.DEF in a
directory called C:\RBBS and will refuse to look anywhere else
for the possibility of a second node's files.  On my board,
doors that crashed outright were set aside for later analysis,
and if they were insignificant older doors with few checkins,
they were unceremoniously dumped.  If a door is a very nice
door, but refuses to run on more than 1 node, a judgement call
must be made whether to run the door on node 1 but not on node
2.  The decision is yours.

Examine each door on an individual basis.  If it is a nice door
that you want to keep, see if it can be set up in a second
directory configured for the second node.  It may be
salvageable by setting up two directories for the door, one for
node 1 and 1 for node 2, each with its separate .CNF or .CFG
file.  If the door keeps scores, such as a game door, you may
elect to keep separate games with separate scores for each
node.  Or, you might take a chance and write into your .BAT
file a little copy routine to store the scoreboard for the door
in a common directory and call it out for each time the door is
run, then save it back to the common directory.  That way, it
will always be up to date for each node.  Of course, you run
the risk that one day two players will be playing the exact
same door, and the scores will get messed up.

At any rate, you will have to modify your .BAT files for each
door and each node.  Each .BAT file will call the door from
that particular node, and return the caller to the directory of
the node in use.  Here's some generic samples:

Node 1:                       Node 2:
WATCHDG1 ON                   WATCHDOG ON
D:                            G:
CD\DOORNAME                   CD\DOORNAME
DOOR 1                        DOOR 2
  (or DOOR %1)                  (or DOOR %1)
CD\                           CD\
C:                            C:
CD\RBBS1                      CD\RBBS2

Note that this is a very generalized door .BAT file.  Please
just study them as examples only.  Notice that the command for
WATCHDOG (if used) is different for different nodes of COM
ports.  For COM1, the command is WATCHDG1 ON, and for COM2, the
command is WATCHDOG on.  If you use Watchcat or Watchkit, the
node may be specified by the monitor's filename; i.e. 
WATCHKIT 1 or WATCHKIT 2 for COM1 or COM2 respectively.  For
other monitors, study the docs to see how to call it up.

Also notice that the door may be in directory D: on the first
machine, but this may be directory G: on the second machine. 
This sinks some doors, which cannot handle having their
directories renamed.  For example, some doors may have
configuration files coded so that their scoreboard is kept in
their own directory, which is referred to as D:\DOOR.  If you
run it from node 2, it becomes G:\DOOR, and the configuration
file is wrong.  Study the possibility of renaming your drives
with the SUBST command so that a particular directory is always
referred to by the same letter from either node.

Read the door's docs and see if it must be called with a switch
on the command line.  As in the above examples, you may have to
specify the COM port as 1 or 2.  Or, you may be able to call it
with DOS's generic %1 - or, you may not!

If you run PCBoard doors via DOR-PCB by B.F. Forbes, you will
find things go a little smoother.  DOR-PCB can be set up on
each node's drive and can usually be called from different
nodes, causing many PCBoard doors to run nicely.  Also, DOORWAY
controlled programs seem to run well on a LAN.  As I said, each
door is an individual excercise, and you are left to your own
devices to get them running on multiple nodes.  Have fun!

MISCELLANEOUS TRICKS:

RBBS is written to share resources with no conflict between
nodes.  For example, I can be sitting on one node, reading
exactly the same messages as a user on the other node, and the
other user doesn't even know I'm there.  Under ordinary DOS
circumstances, this would cause a SHARING VIOLATION error.  And
it is still possible to get an occasional such error when
accessing files outside of RBBS.  While the program FATAL will
handle these errors with minimal delay, the SHARE VIOLATION
errors can be eliminated by making all your .COM, .EXE, .BAT,
.DEF, etc. files as read-only files.  The only files that
cannot be made read-only are your dynamic files, such as
CALLERS, MESSAGES, or USERS.  And, you will never have a share
violation problem with these files because RBBS has already
taken care of that for you.  Therefore, you can set all the
files in a particular directory for read-only attribute with
DOS's ATTRIB command.  Just enter: ATTRIB +R *.* and all the
files in a directory will be set to read-only, making a share
violation impossible.  Then, set your dynamic files back to be
NOT read-only by specifying them in the ATTRIB command like
this:  ATTRIB -R MESSAGES
       ATTRIB -R CALLERS
       ATTRIB -R USERS
       ... etc
I have also set all my downloadable files in all my disk
directories for ATTRIB +R.  This means that two or three users
can be viewing or downloading exactly the same file at exactly
the same moment with no share violation errors.  Of course, the
attribute is flicked to OFF when the file reaches the callers'
disk drive, so he never knows it was read-only on my drive. 
This MAY also help you get doors working on multiple nodes, but
be careful not to set scoreboards, etc. to ATTRIB +R, or the
door cannot update a caller's game score, etc.

THE RESULTS:

How does the conglomeration run?  Well, after getting all the
little bugs ironed out of .BAT files pointing to wrong
directories, etc., I have found that LANtastic is a dream come
true for the RBBS sysop.  I am using the 2 Mbps version of
LANtastic, and I was a little worried at first that there might
be some deterioration of performance, particularly at 9600 or
19,200 baud.  This has not been the case.  A user on, say, node
2 does not even know that a user on node 1 is downloading at
19,200 baud - even if the file he is downloading is on node 2's
machine.  There are a couple of isolated situations that can
cause a little slowdown.  Any activity that is very disk-
intensive does cause a momentary slowdown; for example, if two
people are both searching the FMS file directory at the same
moment, the search goes a little slower for each.  Or, if node
1 has called for a download while node 2 is reading the mail,
node 2 might notice a little slowing while node 1's disk drives
are thrashing through the files, searching for the file to be
downloaded.  A disk cache would undoubtedly eliminate some of
this delay, and I plan to investigate installing one soon.  But
99% of the time, for most BBS activity, callers on other nodes
are not even aware that someone else is accessing the board on
another node.

The convenience for me is also wonderful.  I can now read and
answer mail while others are on other nodes and not pull the
board down for 20-30 minutes per day while I perform routine
maintenance.

I hope some of this is useful to you.  When I first went to set
up RBBS under LANtastic, I found no one, single source for all
the information I needed, and I had to piece it together to
make it all work.  If you find errors in my documentation, or
find a better or easier way to do something, please feel free
to pass your knowledge along to others.  I suggest you at least
upload your experiences to Ken Goosen's board, Your Place BBS,
703-978-6360 as he maintains the best centralized collection of
help files for RBBS sysops in the country.  He is also the
major author and driving force behind the past half-dozen
releases of RBBS.

EXPANDING BEYOND 2 NODES:

The older LANtastic starter kits came with software limited to
4 nodes maximum.  The new 2 Mbps kits are being shipped with a
NOS (Network Operating System) capable of handling up to 120
nodes (although the LANtastic documentation has not caught up
with the software... the docs still talk about needing special
software to go beyond 3 nodes).  To add more nodes, all that is
needed is to add the extra machines with adapter cards and
cable them in series.  RBBS is capable of running up to 36
nodes maximum (0-9, A-Z).  Configure each node in a manner
similar to above.  Remember, if you go beyond the number of
nodes you set in CONFIG parameter 122, you will have to re-set
parameter 122 for all nodes and all sub-boards to reflect the
new maximum.  That's why it's easier to specify the largest
number you ever foresee yourself setting up before you start,
even if you are only configuring 2 nodes for now.   

Remember, also, the 15 download directory limitation, and plan
your file storage accordingly.  If you want to run very large
drives, you will need some sort of disk management system such
as Seagate's Disk Manager to allow the use of DOS partitions
larger than 32 Megabytes.  That way, you can run gigabytes of
storage and not exceed the 15-directory limit.  Additionally,
DOS 4.01 has built in hard drive management capability to
format huge drives beyond 32 Megabytes.  

Some older machines (older BIOS chips) balk at running DOS
4.01; most newer machines thrive under it.  If your older
machine will not run DOS 4.01, you may be able to upgrade to a
newer BIOS chip.  My XT-clone was a 1985 machine, and I had to
try 3 or 4 BIOS chips before I found one that would run
smoothly under 4.01.  I also had a very old NEC V-20 chip that
caused lots of problems.  Changing to an 8088-2 smoothed out
many problems.  (Not all problems are software in origin.)

KUDOS:

I could never have gotten this project to work without the
following people's invaluable help:

Dave Pointer, Sysop, PC Connection BBS, Springfield, IL
  Got me running as servers/workstations on all nodes.
  (LANtastic's docs won't get you there!)

Chip Morrow, Sysop, Newark Connection BBS, Newark, OH
  Helped get me through the CONFIG.EXE file.

Ken Goosens, Sysop, Your Place BBS, Fairfax, VA
  Couldn't have set up the sub-boards without you, Ken!

George Lollar, Sysop, BEC-BBS, Springfield, IL
  Thanks for scouring the country for LANtastic help files.

Also, thanks to Jim Patterson, who patiently called and tested
over and over in the wee hours of the morning to help me find
all the bugs.      

