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.