A local area network will enable you to expand your system to run more than four nodes and also enable you to add even more storage space than you can fit in one machine. The next few sections detail how to configure your network to work with PCBoard. You may not need all of the information provided, but reading it will help give you a better overview of how PCBoard works in conjunction with networks.

Enough computers to handle your desired nodes. You can run one node per machine or you can use a multitasker on a workstation to run up to four nodes on a machine.

If you are running standard serial ports in each machine, they should have 16550 UARTs for each serial port (prevents COM overruns).

If you are using a multi-port card in conjunction with the multiport version of PCBoard, make sure the card you are using is supported by COMM-TSR.EXE.

• PCBoard Bulletin Board Software
• Networking software that compliments the network hardware you have installed.

PCBoard works with virtually all of the DOS based LAN products including 3COM, Banyan, LANtastic, and Novell NetWare. PCBoard requires the network to support DOS 3.1 and higher file/record locking procedures. Almost any NETBIOS compatible network will work since these networks typically support the proper file/record locking procedures.

If you are unsure whether your network software will meet PCBoard's requirements, you will want to test your network for compatibility. The next few steps will show you a short test you can run to make sure PCBoard will work correctly.

NOTE: It is assumed that by now you have at least installed PCBoard. If you have not yet installed PCBoard, refer to the Installation chapter of this manual for further instructions. You must have an installed copy of PCBoard before you test your network for compatibility. Additionally you must either load SHARE.EXE that comes with DOS or check your network software to see if it has the functionality of SHARE built in.

If you are unsure if your existing network will work with PCBoard, run PCBDIAG.EXE which is in the directory where you installed PCBoard. When you run PCBDIAG you will see the this screen:

You will see the following three questions on your screen:

Print ALL configuration files
Perform the Analysis Section
Analyze USERS and INDEX files

These questions will determine how thorough of a diagnostics report you want to run. The analysis section of the report is the part that will contain the information on whether your existing network will work with PCBoard or not.
Therefore, you will want to answer N to all of the questions except to Perform Analysis Section which you will answer with a Y.

When you press PgDn, you will be asked for the printer specification. Type in the device name for your printer (e.g., LPT1). If you wish to send the report to disk instead, you may type in a filename such as DIAG.TXT. After you have printed or saved your report to disk look for the following section towards the top of the report:

Test SHARE functions:

Open DENY ALL  / attempt to share file by second process failed-OKAY
Open DENY NONE / attempt to share file by second process succeeded - OKAY
Attempt to lock record #1 by first  process succeeded - OKAY
Attempt to lock record #1 by second process failed    - OKAY
Attempt to read record #1 by second process failed    - OKAY

These are the results you will see if your network is compatible with PCBoard. All tests should report OKAY. If not, try loading the DOS SHARE command and re-run the test. If some of the tests still fail, you do not have a compatible network.

A common question most people ask if they are setting up a network for the first time is “What type of computers should I get for the servers and the workstations?” There is no definite answer to this question. In fact, the answers you will get depend on how you want your system setup.

For example, you may have a network setup with one server using a 80486 processor and have one node per workstation with each workstation using a low end 386 processor. Of course the ideal situation is to have the absolute fastest computers possible as both the servers and the workstations. In most cases, however, those type of machines would not be economically feasible so you must decide which would be best for your setup.

When you are planning what type of machines to use for your network, keep the following in mind:

Your server needs to be powerful enough to support the number of nodes in your network. For a 2-3 node setup you can most likely get by with a low end 80386. As you add more nodes, however, you will want a more powerful machine like an 80486. The faster machine will give the server the capability to keep up with all of the workstation requests.

This is where the majority of your processing will go on.
Since the programs will be running on these machines, do not hesitate to put a reasonably fast computer on the network as one of your workstations. Most people are under the misconception that you need to have an extremely fast server and put XTs on the network as your workstations. Weigh your needs and remember a fast workstation will make your system look like it is running even faster.

One popular solution is to use a 80486 as your server and then use 80386 or 80486 computers as your workstations. On each workstation multitask several nodes to help keep the overall floor space used to a minimum. This type of setup does require you to properly setup your multitasker using the instructions outlined earlier in this chapter. In addition, you must also setup the workstation properly as far as the network is concerned. This will include such items as assigning network drives and checking for IRQ conflicts.

Once you have your network set up and working correctly, setting up PCBoard for multiple nodes is really not much more difficult than setting up a single node. This is due to the fact that PCBoard enables you to specify where just about any file is located. You need to insure the file is really where you specify – whether it is a network or local drive.

There are only a handful of files that must be located on a shared drive (server drive). You need to make sure the following files are all located on a server drive because they are automatically updated as people call into the system.

• Name/Loc of Users File
• Name/Loc of Users Info File
• Name/Loc of Group CHAT File
• Name/Loc of Caller Log

  • Name/Loc of USERNET.XXX File
  • Location of USERS File Index Files
  • Name/Loc of MSGS File (All conferences)
  • Name/Loc Upload DIR File, Location of Uploads (all conferences)

  The locations for these files are specified in PCBSetup | File Locations | System Files with the exception of those relating to conferences which can be found in each conference's configuration screen. If you store these files on your workstations, you will have no way to update the other workstations when a new user logs in or as the files listed below change. There are more files that are recommended you store on a server drive but are not required to be stored on a server drive:

• Name/Loc of Conference Data
• Doors - Menu Listing, Path/Name List File (all conferences)
• Bulletins - Menu Listing, Path/Name List File (all conferences)
• Scripts - Menu Listing, Path/Name List File (all conferences)
• Directories - Menu Listing, Path/Name List File (all conferences)
• With the remaining files in your PCBoard configuration, you must decide if you wish to put them on the server, the workstation, or put some on the server and some on the workstations.
• The following lists a few reasons you may wish to store a majority of the files on a workstation:
• Running on a slow network (e.g., 2 mpbs)
• You wish to keep network traffic down
• You have a large number of nodes on your network (e.g., 20+) and your server cannot handle all of the nodes requests if the files are stored on the server.
• The following lists a few reasons you may wish to store a majority of files on the server:
• You do not wish to manually update all workstations every time afile on the server is changed
• Your workstations do not have hard-drives in them
• You have a relatively small network and accessing all of the files across the network will not degrade network performance.

When deciding where to store a file on your system it always helps to have a strategy or a plan to help guide you. One that works well for most systems is to store a file on the server if it changes often. Otherwise, store the file on each workstation to help keep network traffic down.

If speed is your primary concern, you will end up putting most of your files on the workstations. This usually means more maintenance for you when updating the files on the workstations because you can have a lot of workstations to update.

If you desire the easiest setup instead of speed, store most of your files on the server. When a file is updated on the server, any nodes or workstations that access that file will automatically see the change in the file because they read from a shared location.

For now, use the above information to help you consider where files will be stored on your network. In the section titled Installing Your Other Nodes, you will actually make the changes to your system configuration.

If you want to save yourself a lot of confusion in your network setup, you will want to configure your network setup so the server drives are the same letters throughout the entire network. Setting up your network to use all of the same drives allows you to specify the same drive throughout PCBSetup on all of your nodes, and your third party utilities.

If you do not make it so that the server drives use the same letter on all workstations, your setup and configuration will be more complex. For example, you may find it confusing and more complex if the drive with the message bases is referred to as drive H on one workstation, and drive J on another workstation. With the server drives using the same letters on all of your workstations, you will make it easier to expand and maintain your system.

To help illustrate how to configure your workstations and servers to refer to the same drive letters for all drives, look at the following example 4 machine - 2 server system:

Machine 1     Server (Network name: SERVER1)
System Drive  Network Resource Name
C:            DRIVE-C
D:            DRIVE-D
E:            DRIVE-E
F:            DRIVE-F
G:            DRIVE-G

Machine 2     Server (Network name: SERVER2)
System Drive  Network Resource Name
C:            DRIVE-C
D:            DRIVE-D

Machine 3     Workstation
System Drive  Network Resource Name
C:            N/A (not a server)

Machine 4     Workstation
System Drive  Network Resource Name
C:            N/A (not a server)

NOTE: All of the examples in this section use Artisoft's LANtastic syntax.
If you are not using LANtastic then please consult the documentation for your network to find out how your network refers to network resources.

You can see we have a little dilemma in this setup. Not only do all of the computers in this example have C: drives, but the two servers both have a drive D as well. To further complicate matters, you will want to let every computer have their own local drive C. What you need to do to rectify this conflict is to begin using all of the network drives at drive H.

You can begin by first assigning drive letters of your network drives on SERVER1. As was mentioned before, you can begin at drive letter H and work your way down to drive Z. You can do this because you do not have any local drives that use the drive letter H. The highest local drive letter is G and that is on the first server.

To assign the drive letters on the various machines of the network, you will use two different methods. If the drive is a physical drive in the server, use the SUBST command provided by DOS to assign the appropriate drive letter.
Otherwise, use the command your network provides for assigning drives. The examples shown in this section use LANtastic format for the network commands. If you use a different network, consult your documentation for further instructions.

Now that you understand why we used SUBST in some cases and the NET USE command in others you should be ready to assign the drives for all four nodes. The following shows you the commands that should be added to AUTOEXEC.BAT or your network startup batch file:

Machine 1 (SERVER1)

  SUBST H: C:\
  SUBST I: D:\
  SUBST J: E:\
  SUBST K: F:\
  SUBST L: G:\
  NET USE M: \\SERVER2\C-DRIVE
  NET USE N: \\SERVER2\D-DRIVE

Machine 2 (SERVER2)

  NET USE H: \\SERVER1\C-DRIVE
  NET USE I: \\SERVER1\D-DRIVE
  NET USE J: \\SERVER1\E-DRIVE
  NET USE K: \\SERVER1\F-DRIVE
  NET USE L: \\SERVER1\G-DRIVE
  SUBST M: C:\
  SUBST N: D:\

Machine 3 (Workstation)

  NET USE H: \\SERVER1\C-DRIVE
  NET USE I: \\SERVER1\D-DRIVE
  NET USE J: \\SERVER1\E-DRIVE
  NET USE K: \\SERVER1\F-DRIVE
  NET USE L: \\SERVER1\G-DRIVE
  NET USE M: \\SERVER2\C-DRIVE
  NET USE N: \\SERVER2\D-DRIVE

Machine 4 (Workstation)

  NET USE H: \\SERVER1\C-DRIVE
  NET USE I: \\SERVER1\D-DRIVE
  NET USE J: \\SERVER1\E-DRIVE
  NET USE K: \\SERVER1\F-DRIVE
  NET USE L: \\SERVER1\G-DRIVE
  NET USE M: \\SERVER2\C-DRIVE
  NET USE N: \\SERVER2\D-DRIVE

If you look at each node, you will see drive H refers to the same drive on all four nodes. Likewise, the rest of the drives (I-N) also reference the same drives on all nodes. This is the setup you want to achieve. It does not matter what drive letters you use, but it does matter that you use the same drive letters across the entire network.

There are a few changes you will likely have to make to your AUTOEXEC.BAT and CONFIG.SYS system files. You should already have an AUTOEXEC.BAT and CONFIG.SYS for your system. This section details what you must have in these files in order to properly run a multinode setup using multitasking software.
If you have other items in these files, do not worry as they may be necessary for your particular system (hardware drivers, etc.)

In you CONFIG.SYS files, modify the number of file handles you define for your system. Your server should have the number of file handles equal to 25 times the number of nodes the server will manage plus 25 for itself. In other words, if you have a 7 nodes running on your network (including the server), add FILES=175 to your CONFIG.SYS..

Your workstations need 25 file handles for each DOS process that is running.
Unless you are using a multitasker to run more than one node per workstation, add FILES=25 to your CONFIG.SYS. If you are running more than one node per workstation, add 25 times the number of nodes you are running on the machine.
For example, if you are running 4 nodes, add FILES=100 to the workstation's CONFIG.SYS.

DOS cannot provide more than 255 file handles in CONFIG.SYS. If you need more than 255 file handles consult your network documentation to see if a method to override the CONFIG.SYS settings is provided.

Normally, DOS will allow you to address up to drive E without having to modify your CONFIG.SYS. In the examples used in this section, you will notice we went past drive E. For DOS to be able to access these drives, add the LASTDRIVE=Z statement to your CONFIG.SYS file. You do not have to specify Z as your last drive letter, but for the small amount of memory it consumes, you may end up saving time.

For a multi-node setup, you must insure SHARE is either loaded or built-in to your network. By now you should have already completed the network compatibility test described earlier. If you had to load SHARE.EXE for the test and you have not added it to your AUTOEXEC.BAT, do that now.

There are basically two types of nodes in a network setup – dial-in and local. Dial-in nodes are those expecting calls to come from a modem or serial port.

Once you have installed PCBoard on your server, there are numerous ways you can go about adding nodes. You can add one node per workstation on the network or you can setup a multitasker on your workstations and run more than one node on each workstation.

There are three primary steps you should follow when adding new nodes to your network configuration. They are:

Whichever method you choose each of your workstation machines should have a hard drive and each of them should also have a \PCB subdirectory. The following files should be copied from the \PCB subdirectory on the server to the \PCB subdirectory on the workstation.

• .EXE
• .COM
• .BAT

REMOTE.SYS

 PCBOARD.DAT
 PCBFILER.DEF
 PCBSM.HLP

In PCBSetup | Node Configuration and make sure you have answered Y to the Running a Network / Multitasker System question and that you have defined the proper node number on each node you have defined.

In menu options A-H from the PCBSetup Main Menu, insure you have properly specified all drive and path references. You should use the information provided in Where Should The PCBoard Files Be Stored to determine where the files pointed to in menu options A-H should be stored.

If you plan on setting up your dial-in nodes on a multitasking workstation, reference the multitasking section earlier in this chapter. About the only difference between multitasking on a stand-alone machine and on a workstation is that you must realize some of the files in your configuration will be read from the server rather than from a local drive. This means you simply change the location of files like your users file and you will be up and running.

If you decide to multitask nodes on a workstation, there are a few considerations you should be aware of:

You should reduce the amount of time that your workstation spends monitoring the network. This will make network transfers a little less snappy, but will allocate more system time to your multi-tasker which means snappier displays for your users. LANtastic uses the run_burst command line switch on the AILANBIO program. If you are using a different network consult your manual.

Most multitasking programs have provisions for networks such as network buffers, etc. Consult the manual for your multitasking manual to see exactly what type of support for networks that it offers.

If you are using QEMM as your memory manager, increase the number of tasks.
To do this add tasks=nn (where nn is the number of tasks to allocate) to your QEMM386.SYS line in CONFIG.SYS. Set this value to 16 times the number of nodes you plan to run. In QEMM, a task is a data structure that is used to handle interrupts out of protected mode. If you are using a different memory manager, consult your manual for further details.

If you have plenty of conventional memory, you can gain a small increase in speed from your network if you load all of your network drivers in conventional memory. The overall performance gain will be very, very small but for some even a very small gain is important.

There are basically two types of nodes in a network setup – dial-in and local. A local login is where the user runs PCBoard directly and interacts using the local keyboard.

PCBoard works equally well across a network as it does when accessed through external connections. When users login across the network, they are simply running a copy of PCBoard which has its own setup (PCBOARD.DAT) file.
Because this method is used, PCBoard does not have to talk directly to the network operating system (NETBIOS, IPX, etc.).

Some may question if allowing users to run PCBOARD across the network will compromise security of the system by allowing users to access SysOp functions. When you use the /LOCALON command line parameter for PCBOARD.EXE, it causes PCBoard to bypass the call waiting screen and go directly to the Do you want graphics? prompt. In addition, the user may not shell out to PCBFiler, PCBSetup, PCBSysMgr, or PCBMoni while logged in.

If you wish to protect your users from accessing some of the setup and configuration utilities, you can make a separate subdirectory for those files and move them to that subdirectory where they can be protected via network security. Be careful about what you do with network security, however, as all of the PCBoard files must have full read, write, and delete network rights to function properly.

Setting up local login nodes are, for the most part, easier than setting up dial-in nodes because you can float the node number. When you float the node number it allows PCBoard to pick a node that is not being used and assign the local user this node number. This method of assigning node numbers avoids the need to assign everyone a unique node number and also makes your batch files and general setup much easier. If you float the node numbers of your local users, you could easily have 1000 or more users vying for access to a 100 node system. If PCBoard is unable to find a free node (all nodes are busy), the user will receive an ALL NODES ARE BUSY message.

What makes the ability to float a node so useful is that you can have one batch file and one setup file for all local nodes. Not only that, but you can start your local logins at any node number and automatically have them float all the way until you run out of the concurrent logins you software license allows. This means less maintenance for you in the long run and you can protect your dial-in nodes (if you have any) from being used by local logins. Having one batch file for all of your logins, however, means you will not be able to hard code drives and subdirectories in your batch files.

Every user must have a home directory to be used by PCBoard. You must guarantee that this home directory is unique to each local user. This subdirectory could be on the server set aside for a particular user, or it could be a subdirectory set aside on the local hard drive of every workstation. In this subdirectory PCBOARD.SYS and ENDPCB will be created for each user.

PCBOARD.SYS is created for every user and contains information like the last time they logged on, user name, city, etc. ENDPCB is created by PCBoard when exiting. These are the only files that will remain in this unique subdirectory.

The first thing you will want to do to float nodes is to create a subdirectory on the file server where you will store the files relating to local logins. You may want to call it LOCAL and create it under your PCB subdirectory. For example, if your server drive is F:, create an F:\PCB\LOCAL\ subdirectory which will hold the local login files. From now on, this will be referred to as your local subdirectory. Once you have created the subdirectory, copy your BOARD.BAT and your PCBOARD.DAT from your PCBoard installation subdirectory to your newly defined local subdirectory.

The first file you need to edit is the BOARD.BAT file in your local subdirectory. There are some lines in the batch file that are not necessary for local logins and also some information you will need to add. For this example, the BOARD.BAT used is the exact same one that is created when you install PCBoard. If you have made changes to your BOARD.BAT, you will need to compensate where necessary.

Your BOARD.BAT may resemble the following:

ECHO OFF
C:
CD \PCB
SET PCB=
SET DSZLOG=PCBDSZ.LOG
IF EXIST REMOTE.BAT RENAME REMOTE.BAT REMOTE.SYS
IF EXIST DOOR.BAT DEL DOOR.BAT
IF EXIST ENDPCB DEL ENDPCB
PCBOARD
IF EXIST REMOTE.BAT REMOTE
IF EXIST DOOR.BAT DOOR
IF EXIST EVENT.BAT EVENT
IF EXIST ENDPCB GOTO END
BOARD
:END

You can trim your BOARD.BAT so these lines remain:

ECHO OFF
SET PCB=
IF EXIST DOOR.BAT DEL DOOR.BAT
IF EXIST ENDPCB DEL ENDPCB
PCBOARD
IF EXIST DOOR.BAT DOOR

At this point you are probably wondering why the new BOARD.BAT is so small.
The next few paragraphs discuss the lines that were removed and why.

The first two lines that were removed are C:, and CD\PCB. These two lines together change to a specific drive and directory. While this works great for a dial in line, it will not work when floating nodes. Remember, you cannot hard code subdirectories or you are going to run into conflicts when floating nodes. If two users attempted to login simultaneously, they would attempt to read the same PCBOARD.SYS file and cause other problems with board operations. By eliminating these two lines, you can help guarantee that the user is in a unique directory before they load PCBoard.

The only time you may want to change to a specific drive and subdirectory would be if the subdirectory is truly unique to each user on the network. As an example, you can use the local drive c available on many or all of your network workstations. On each of the workstation's local drives, make a subdirectory called PCBLOCAL and use the BOARD.BAT to change to that subdirectory before loading PCBoard..

As another example, your users may have unique directories set aside on the network server that only their account can access. You can set this up so that this subdirectory is referred to as drive F (by assigning network drives). In this case, have BOARD.BAT change to the root subdirectory of the F: drive and load PCBoard.

The next line to be removed is SET DSZLOG=PCBDSZ.LOG. Normally, you will want this environment variable defined for transferring files. However, PCBoard provides the capability for local file transfers so this line becomes un-necessary.

IF EXIST REMOTE.BAT… and IF EXIST EVENT.BAT… can also be removed because remote DOS sessions and events will not be a concern when you do a local login. There are also similar statements below PCBOARD in the BOARD.BAT which start out the same way (IF EXIST) – these lines should be removed.

BOARD was removed from your batch file because there is no reason you would need to reload BOARD.BAT from within you local batch file. This line is still necessary in all of your dial-in nodes though.

When your final batch file is done, you will never make reference to the END batch label so remove the :END from the batch file as well. There is no sense in leaving it in BOARD.BAT if you do not use it.

After you have removed these lines, you will have the new stream-lined BOARD.BAT. Next, you must add or change some lines to help accommodate local logins.

PCBOARD should be changed to

PCBOARD /FILE:<local subdirectory>\PCBOARD.DAT /LOCALON

The /FILE parameter tells PCBoard where it can find the PCBOARD.DAT file.
PCBoard normally looks in the current subdirectory. Rather than copying a the DAT file to each local subdirectory, why not tell PCBoard where it should find the file? When you step back and look at it, you will notice the only thing that really changes for your local login users is the node number.
Therefore, it is to your advantage to access one PCBOARD.DAT for all of your local logins.

The <local subdirectory> should be replaced with the drive and subdirectory of the local subdirectory created previously. If this subdirectory happens to be H:\PCB\LOCAL\, your new PCBOARD line will be:

PCBOARD /FILE:H:\PCB\LOCAL\PCBOARD.DAT /LOCALON.

The /LOCALON parameter totally bypasses the call-waiting screen and places the user at the Do you want graphics? prompt. From this prompt, the user can choose if they want to use graphics or not, type in their user name and password and continue on. When the /LOCALON switch is used, almost all of the SysOp functions are disabled except the following:

If you wish, you can have your BOARD.BAT also stuff the keyboard so users logging in locally will not have to answer the Do you want graphics prompt.
For more information on how to do this, refer to the /KEY command line parameter in the PCBoard chapter of this manual.

If PCBOARD.EXE is not located in the current directory or in a directory that is listed in your PATH= statement, you will receive a bad command or filename message from DOS. If you do, tell your batch file where to find your executable file. For example, if your PCBOARD.EXE file is located in Q:\PCB\ (which is not in your path), you can type Q:\PCB\PCBOARD.EXE to load the PCBoard executable. You will do the same thing to the BOARD.BAT file – add Q:\PCB\ in front of PCBOARD.

The final line in your batch file - IF EXIST ENDPCB GOTO END should be changed to IF EXIST ENDPCB DEL ENDPCB. PCBoard will create the ENDPCB when a local user logs off the system. There really is no sense in leaving the file around if it is not going to be used.

You final BOARD.BAT will look like the following if your local subdirectory is setup as H:\PCB\LOCAL\:

ECHO OFF
SET PCB=
IF EXIST DOOR.BAT DEL DOOR.BAT
IF EXIST ENDPCB DEL ENDPCB
PCBOARD /FILE:H:\PCB\LOCAL\PCBOARD.DAT /LOCALON
IF EXIST DOOR.BAT DOOR
IF EXIST ENDPCB DEL ENDPCB

One last thing that should be mentioned is that if all nodes are busy, PCBoard will exit with a DOS errorlevel of 99. Therefore, you can use an IF ERRORLEVEL statement in your BOARD.BAT file to check for errorlevel 99. If you detect an errorlevel of 99, you know there has been an error and that you should perform some other action instead. For additional information on testing errorlevels, refer to your DOS manual.

When you are floating nodes, PCBoard will begin filling up the nodes at the node number specified in PCBSetup. Since PCBSetup gets most of its information from PCBOARD.DAT, the file has to be copied into your local subdirectory so changes can be made to it. An advantage of having this separate DAT file for your local nodes is that you can disable certain features which are not necessary for local logins.

Before you begin testing your floating nodes, insure that the node number in the PCBOARD.DAT you are using is set to the proper value. To change the node number, load PCBSetup from the local subdirectory. After PCBSetup is loaded, select Node Configuration from the menu. The fifth item from the top of the screen is Node Number on the Network. In this field, enter the first node number that will be used by your local login users. Once you have made this change, exit PCBSetup and save the changes you have made.

At this point your floating node setup should be complete. To test your setup you can follow these steps:

Find two stations on the network that you can use for testing.

Change to the unique drive and directory on both workstations. This should be a drive and directory nobody else on the network can/would use.

Run BOARD.BAT on each workstation.

The machine which ran BOARD.BAT first should come up as the node you specified in the PCBOARD.DAT stored in your local subdirectory. You can verify this by completing the login and typing WHO at the command prompt.
The other machine should be listed as the next node. In other words, if you set your beginning node number to 4, the first machine should come up as node 4 and the second machine should come up as node 5.

If the first local node shows node 4 and the second shows node 5, everything (as far as PCBoard is concerned) is working correctly. If it did not, your configuration is not correct. Double check your setup and make sure you followed all of the previous instructions.

If two or more users try to login using the same directory PCBoard will go directly to the command prompt rather than the familiar Do you want graphics? prompt. In addition, PCBoard also thinks this new person is the same name and node number as the other person. In a sense the second person will be invisible. However, with two or more people accessing the system like this, you are likely to have file access errors and other unforeseen problems. If a user ever reports that they went immediately to the PCBoard command prompt on their first login make sure they immediately logoff and check your configuration to make sure two nodes do not and cannot conflict.

If your nodes do not return to the same directory after loading a third party program they left from, there is a chance they could stomp on someone else's session or they could come up under a different node number without being logged off from the previous node. If this happens, the user will be told that their name is already in use on another node when they attempt to login.
If this occurs, you will want to use the USERNET utility provided with your package.

USERNET.EXE (USERNET) is a utility that allows you to manipulate the USERNET.XXX file. This file is used by PCBoard to store who is currently online and what they are doing. You will find instructions for USERNET in the Utilities chapter of this manual.

Once PCBoard is working correctly, verify all third party programs to make sure they are setup properly (if you have any installed). It is strongly recommended that you read the Multiple node section for Doors in the Conference Setup chapter of this manual for additional information on running doors in a multi-node environment.

In your setup you will find it useful if you know how PCBoard determines if a node is busy or not. PCBoard first scans the PCBOARD.DAT you pointed to with the /FILE parameter to determine the beginning node number it can start floating from. Once PCBoard finds this number, it scans USERNET.XXX beginning at that node number up to the number of nodes that your software license allows. If a free node is found, the user will be logged in. If it does not find a free node, PCBoard will print the all nodes are busy message.

If you would like to verify PCBoard's findings you can always log into the system and issue the WHO command to see who is currently online. This command will list all people online, the node number they are using, and what they are currently doing (Entering a Message, Trasferring a File, etc.).

Nothing helps a system out more than a good disk cache. You should use a disk cache both on your server and on your workstations. If you do, you will see a dramatic improvement in your hard disk performance. The most recent versions of both MS-DOS and DR-DOS come with disk caching programs. Consult your DOS manual for more information on how to install the disk cache.

In PCBSetup | Node Configuration there is a field labeled Node Chat Frequency. This field is used to determine how often a node scans USERNET.XXX (to update who is online, etc.) and also how often each node is checked for new lines of text when two users are in node chat. If you find that your system is really strained, increase the value of this field so that the network is strained less often. Do not make this value too large though, as it may end up slowing down some of the functions of your bulletin board system.

When you are determining how big to set your network buffers in your network, consider a buffer size that is in multiples of 2k or 4k. Because PCBoard does so many different tasks and because the type of network and computers you are using vary so much, there is no single buffer value you should use.
Use a trial and error method where you login, perform what you think is a normal call, check your performance time and then change your network buffer size and try the test again.

In your CONFIG.SYS, set your BUFFERS= statement to the cluster size (in kilobytes) of the largest disk partition on each of your computers multiplied by 2. You multiply by 2 because each DOS buffer is 512 bytes. For example, if your largest partition uses a 4096 byte cluster size, you will divide 4096 by 1024 to get your cluster size in kilobytes and then multiple the resulting value by 2. In this example, you would set BUFFERS=8.

If you do not know your cluster size, use CHKDSK to see what value is to the left of bytes in each allocation unit. Of course if you are on a server drive, you will probably receive a message which says Cannot CHKDSK a network drive. If that is the case, you can use a utility called PCBDISK.EXE which is included with your package. PCBDISK will report bytes per cluster in parentheses at the beginning of its screen.

To help conserve a little bit of memory you can also add a statement in your CONFIG.SYS which says FCBS=1,0. DOS usually defaults to a higher number of FCBs (File Control Blocks). Very few programs use FCBs anymore so by setting it to the minimum that DOS allows, 1 FCB, you can save some additional conventional memory.

If you are running Novell NetWare as your network, you may want to modify the way it searches for data files so it behaves more like DOS. This change is recommended at least on the PCBoard executables – it may not be appropriate for all of the files on your system.

Novell, unlike DOS, searches the path not only for executable files but for data files as well. This can cause problems for PCBoard. Therefore, it is recommended that you change to the subdirectory where PCBoard is installed and type:

SMODE *.EXE 2

By doing this, you tell NetWare to not search the path for data files when you run your executable programs. In all actuality, you have made NetWare behave more like DOS in regards to the search path.