The reason that this happens is that all of your nodes point to the same Conference Data file (PCBSetup | File Locations | System Files). Since this file contains all of the conference information for your system and since you are using one file, you see the changes reflected on all nodes.

The obvious solution would be to specify different Conference Data files for each node. This solution is not recommended though, because any time you make a change to any conference you will have to make that same change on each node. For example, if you setup a new conference, you will have to set it up on each node and hope you have set it up exactly the same on all nodes. Specifying a different Conference Data file for each node increases your chances of making errors in your system configuration. If you determine that you must have some nodes that do not share the same information as the rest, you can use what is referred to as relative addressing.

Relative addressing depends on the current subdirectory to determine where it looks for files. If you enter the filename (no drive or subdirectory locations) in a field, PCBoard will look for the file in the current or default directory. Because each of your nodes use a different node subdirecotry, you can keep one copy of your Conference Data while still being able to have unique conference files for each node.

Relative addressing looks like the following examples:

DOORS.LST
GEN\BLT
\PCB\MAIN\SCRIPT.LST

Because no directory information is specified you are telling the program to look in the current subdirectory for the filename DOORS.LST. If your current subdirectory is C:\PCB\, the program is going to try and open C:\PCB\DOORS.LST. On another machine your current subdirectory may be D:\PCB. If so, the program will look for D:\PCB\DOORS.LST instead.

This example does have a directory included in the file specification but notice that there is no backslash () at the beginning. This simply means to look for a subdirectory called GEN underneath the current subdirectory.
For example, if your current subdirectory is C:\PCB\, the GEN\BLT will be added on to create C:\PCB\GEN\BLT.

If all that is different is the drive letters that you use between machines, you may want to use the type of relative addressing shown in this example. Notice how this example starts with a backslash. This will cause the program to begin looking for that file from the root subdirectory on the current drive.

Be careful when using relative addressing. If you are not careful, you can create a message base or user file that is specific to one particular node. For example if you have two nodes running and you are having problems with one node not being able to read the MSGS file you may be tempted to use relative addressing. If you do, you will not get the file not found errors, but you will end up creating two separate files with each copy specific to a particular node. This means that a message entered on one node will never show up on another node because each node is using separate message base files.

Absolute addressing, on the other hand, looks like the following:

C:\PCB\GEN\DOORS.LST
D:\PCB\GEN\BLT
E:\PCB\MAIN\SCRIPTS\SCRIPT.LST
F:\PCB\GEN\DIR.LST

You will notice that each of these examples are quite similar. The reason that they are so similar is that absolute addressing requires that you start with the drive letter and give the complete path and filename.

I am planning on running multiple nodes but I only want one phone number to access all of my nodes. How can I do this?

This is something you need to consult your local telephone company about. Your phone company should provide a service called hunt groups or ring-down groups. You still get a phone number for each incoming line, but if the first number is busy it rings down to the second and so on.

When I try to login to a second node, the first node's session is accessed instead of a new session. What am I doing wrong?

You are attempting to start PCBoard from the same directory that another node has started from. Recall that PCBoard requires being loaded from a unique drive and subdirectory because it will write PCBOARD.SYS, DOOR.SYS, USERS.SYS, and ENDPCB to the directory you load PCBoard from. If two nodes try to load from the same directory, they will conflict.

No. PCBoard talks directly to the COM port. Therefore, this type of setup is not possible.

A sharing violation occurs when two programs attempt to access the same file when one of the programs has the file locked. In normal multi-node operations, it is quite common for two or more programs to read/access a file at the same time. Sometimes though, a program needs to update a file and while it writes to the file it will lock the file from all other programs. When a file is locked, it means that no other program can read from or write to the file. These errors can be reported by the programs themselves or by DOS. To resolve the conflict check and see what programs are accessing the same files and try to work around them trying to access the file at the same time.

This is one of the reasons why you should not redirect you local C: drive. Presumably you were redirecting your drives in your AUTOEXEC.BAT file which is loaded from your C: drive at bootup. When you reassigned your local C: to another drive while the batch file is running on C:, DOS can no longer find the same batch file it was executing and consequently stops.

This is most commonly caused by changing to the wrong node directory in your BOARD.BAT which means PCBoard might end up using the wrong serial port. Make sure you change to the correct node directory before you execute PCBoard so the correct PCBOARD.DAT (setup) file is read.

If your setup checks out okay, also make sure you have resolved all IRQ conflicts between the COM ports and all other devices in your computer. The most common conflict is to use IRQ for both COM1 and COM3.

This problem occurs more often on a multitasking setup because you are more likely to be using non-standard COM ports. The door programs you are running are not currently setup to use non standard COM ports. In other words, the IRQ the door thinks you are using and the one you are actually using are different. You should check the documentation for your door program to see if there is a way to specify the IRQ you are using for the COM port on your system.

I have often noticed that some programs that wish to run in the event require that all nodes be down while one node runs the event. How can I make sure that all of the nodes are down?

The most common solution to this dilemma is to have the other nodes run a program which will wait x minutes while the other node does its processing. There is a third-party freeware utility available on Salt Air under the filename of WAIT4.ZIP. If you have an event defined that uses PACKIT for the batch file and has node 1 pack your message bases, your batch files may resemble the following:

PACKIT.001

@ECHO OFF
PCBPACK /AREA:ALL /DAYS:90 /KEEP
BOARD

PACKIT

@ECHO OFF
WAIT4 360
BOARD

Using these example event batch files, node 1 will pack the message bases and then re-load BOARD.BAT upon completion. In the meantime, the rest of your nodes will be on hold for 360 seconds (6 minutes). After the 6 minute countdown has completed, BOARD.BAT will be re-loaded.

A UART is the chip on standard serial port boards which handles the input and output of the serial port. What makes the 16550 UART important to multiple node setups is that it can buffer more data than other UARTs.
The 16550 will buffer up to 16 bytes of data as opposed to the one byte most other UART chips handle. In order to maintain error-free connections with high speed modems, multitaskers, or networks a 16550 is highly recommended.

You can find out what type of UART you have by loading PCBoard (with the COM port you want to check specified in PCBSetup | Modem Information | Modem Setup) and logging in as the SysOp. Once you are in the BBS, press ALT-H four times. You will notice that the status line will change each time and will look like the example below:

Notice that on the bottom line towards the right hand side is the text 16550A FIFO. If you have a different type of UART (e.g., 8250A/16450) you may want to upgrade to the 16550.

If you do not have 16550 UARTs on all of your serial ports, you may be able to replace your existing UARTs. Check your serial board to see if the UARTs are socketed or not. If they are socketed, you can contact your local electronics warehouse and ask for part number PC16550CN or NS16550AFN. Once you have the new UART, you can simply remove the old one and replace it with a 16550. If the UART(s) on your existing card are soldered in place or you do not feel comfortable in replacing them, it is advised that you contact a computer technician who will do it for you.

When you receive an out of environment space message from DOS it means you did not have enough room in your environment to store an environment variable you attempted to create or modify. You can increase the size of your environment by using the SHELL= statement in CONFIG.SYS. It is not recommended that you exceed 1000 bytes for your environment size because some programs have exhibited problems with environments of that size. An environment between 512 and 768 bytes should be more than adequate for most systems.

If you have Windows 3.1, you will need to modify your SYSTEM.INI to increase the size of the environment available in a DOS window. Windows 3.1 allows you to specify the size you want for your DOS windows via your SYSTEM.INI file. In the NonWindowsApp section of your SYSTEM.INI should be a line that says CommandEnvSize=512. This line tells Windows how much environment space to allow to each DOS window that is opened. You should note that the default value is 512 bytes which should be fine for nearly all systems. If you need to change that value (or add the line to your SYSTEM.INI) please refer to your Windows documentation for further instructions.

PCBoard is overlaid which means it stores some of the executable code on disk. There is a chance that two or more nodes can conflict while loading. To help prevent this, make your PCBOARD.EXE file read only. To make this file read only, use the ATTRIB command provided by DOS as in the example below:

ATTRIB +R PCBOARD.EXE