home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Media Share 9
/
MEDIASHARE_09.ISO
/
pcboard
/
pcbmult.zip
/
PCBMULT.TXT
< prev
Wrap
Text File
|
1992-09-11
|
152KB
|
3,099 lines
PCBoard And Multiple Nodes
A guide to setting up PCBoard in a multinode environment
The entire contents of this document are Copyright (C) 1992 by
Clark Development Company, Inc.
DISCLAIMER
The information provided in this document is provided as is
without any warranty of any type or guarantee of fitness of use.
The configurations detailed in this document have been tested,
however results may vary from system to system and you assume
full responsibility for trying any of the above suggestions on
your system. It is suggested that before you attempt any of the
suggestions listed that you completely back-up your system.
PCBoard is a registered trademark of Clark Development Company,
Inc.
386MAX is a registered trademark of Qualitas
Lantastic is a registered trademark of Artisoft, Inc.
Microsoft Windows is a registered trademark of Microsoft
Corporation.
NetWare is a registered trademark of Novell, Inc.
QEMM and DESQview are trademarks of Quarterdeck Office Systems.
Table of Contents
=================
Overview
What Is Needed to Run More Than One Node?
What is Multitasking
Multiple Nodes Using Multitasking Software
Topics covered in this section:
Getting Started
Recommended Hardware:
Necessary Software:
Modifying System Files
CONFIG.SYS
AUTOEXEC.BAT
Installing Additional Nodes
Creating the NODE Subdirectories
Setting Up PCBoard
PCBSetup
Modifying BOARD.BAT
Setting Up Your Nodes Under a Specific Multitasker
DESQview
Microsoft Windows v3.1
Automatically Loading The Nodes at Bootup
DESQview
Windows v3
Setting Up PCboard v14.5a And Local Area Netwoks
Topics covered in this section
Getting Started
Required Hardware
Required Software
Types of Networks Supported
Testing Network Compatibility
Planning Your Network Setup and File Locations
What Type of Computers Should I Use On My Network?
Where Should I Store The PCBoard Files?
Configuring The Network Drives
Modifying Your System Files
CONFIG.SYS
AUTOEXEC.BAT
Installing Your Other Nodes
Dial-In Nodes
Local/In-House Nodes
Optimizing A Network Setup
Special Considerations For Novell Networks
Possible IRQ Conflicts
Multitasking
Networking
Modifying DOOR Batch Files for a Multinode Setup
Setting Up Events
Third Party Software Setup Recommendations
DSZ (ZMODEM TRANSFER PROTOCOL)
DOORWAY
Answers to Common Multinode Questions
Overview
--------
PCBoard was designed with multiple user access to a system in
mind. Each user that accesses the system must log in through a
node. A node refers to a copy of PCBoard that is running on a
network, multitasker, or some other system that has the ability
to share resources through shared file access. Users may access
the system remotely through a modem or locally through a network
or local node.
What Is Needed to Run More Than One Node?
There are two different ways to run multiple nodes with PCBoard -
multitasking and networking. Each method has various advantages
and disadvantages but they all have one thing in common - the
ability to share files.
What is Multitasking
Multitasking is a method of running more than one task at a time
on a single machine. When multitasking you are not actually
running all of the tasks at the same time as the CPU is not
capable of doing so. Instead, the multitasking software manages
the resources of the CPU and switches VERY QUICKLY between each
task. Of course, since you are switching back and forth between
each task having a faster CPU will make each task run more
smoothly. To really be effective in running multiple nodes you
will need to use an 80386 based machine or higher. The internal
capabilities of the 80386 and higher class CPU were better
designed for multitasking than any of the previous processors
(80286, 8086, 8088) and are therefore strongly recommended for
multitasking.
What is a Network?
A network allows several different computers to share resources
(hard drives, printers, etc.) among one another. In order for a
resource to be considered "sharable" it must be stored on a
computer that is referred to as a server. The workstations
(other computers in the network) can then use the resources
located on the server just as if they had been installed on the
workstation computer.
The most popular network is called a Local Area Network (LAN).
All communications in a LAN is done between cabling which is
hooked into each machine. Another network is also called a Wide
Area Network (WAN). The machines in these networks are so far
apart that you could not use cabling to connect them. Instead,
alternate methods like dedicated phone lines are used to send
data across the network.
As an example of shared resources, if you had a 1.2 gigabyte
drive on one machine and you hooked up a LAN then the server is
the computer with the large hard drive and the workstation is the
computer that will access that drive via the network. The drive
can then be accessed from the workstation just as if it was
installed on the workstation itself.
Should I Use a Network or a MULTITASKER?
There are a few questions you need to ask yourself when you are
considering your multinode setup. These questions will help you
get a better feel if you should use a network, a multitasker, or
a combination of both.
How many nodes do I plan to run?
There is a limit on how many COM ports you can put in a single
machine that uses unique base addresses and unique IRQs for each
port. Because of this limitation you are limited on how many
nodes you can run on one single machine using a multitasker. If
you want to remain compat ble with the majority of third party
software then you cannot run more than 4 nodes on a single
machine. Sure, you can run more than four nodes on a multitasker
but it requires that you use the upper IRQs (8-15) which very few
third party programs support. If you need more than four nodes
you should invest in a network.
A network allows expandability beyond four nodes because you can
keep adding workstations to your network to add more nodes. Of
course a drawback to a network that runs one node per workstation
is that it requires quite a bit of space for all of the computers
on the network.
How important is performance?
In order to multitask four nodes on a single machine you do pay a
price -- performance. Because you are running four copies of
PCBoard, it is almost like running four computers off of one
processor. Of course you can get a faster processor so that the
speed seems about the same as a stand alone machine. If
performance is very important to you then a network is probably
what you should choose with one node per machine. A network
would be pointless though from the performance angle if you were
to use slow machines like XTs as your workstations. Using XTs
for your workstations would defeat the purpose and it would be
better if you used a fast 386/486 for a multitasking machine
instead.
How much money is in the budget?
How much money you have to spend is usually a direct reflection
on the speed of the machine(s) you can afford. Of course if you
need to run more than four nodes then a network will be involved
but the faster the machines are that you use for your server(s)
and for your workstation(s) the better the overall network
performance will be.
As an example let's say that you need to run five nodes and
performance is rather important to you. What you could do is
setup a three machine network with one server and two
workstations. On each of the workstations you could multitask
two nodes using a 386/486. Running two nodes on a workstation
means less computers in your network and it also means lower
overall cost.
How much room is available for computer equipment?
Another valid concern about your multinode setup is how much
physical room it is going to take. This is especially true of a
setup which uses a network because there are multiple machines in
the network. If space is very tight and you are using a network
then perhaps you will want to multitask on your workstations to
reduce the number of machines that are required on your network.
Can I fit all of the storage space on one machine?
Another item you will need to plan for is how much file storage
space will you have online and will it all fit on one machine.
For example if you wanted to put 8 gigabytes online then it would
be very difficult to do so inside of one machine. In a situation
like that you would have to go to a network setup with multiple
servers to accomodate all of the storage space.
In summary, here is a short list of the advantages and
disadvantages of multitasking, networking, and running a
multitasker on the workstations of a network:
Multitasking:
Advantages:
You can run more than one node on a single computer
Less hardware cost per node (hard drives, monitors, etc.)
Multiple nodes are a keyboard away
Disadvantages:
System is harder to tune; lockups may occur
A system which uses more serial ports other than COM1 or
COM2 may find that not all third party program that access the
COM ports will work on 'non-standard' COM ports.
Networking:
Advantages
Each node uses a dedicated CPU instead of sharing the CPU by
multitastking. This can dramatically increase performance
especially if you are using high-speed modems.
You can run more than four nodes. A network allows you to
share resources (drives, printers, etc.) with all connection
machines. Therefore it is possible to run several hundred
nodes in a network configuration.
In a multitasking system if the computer goes down so do all
of the nodes on the computer. However, in a networking
configuration chances are that if a node goes down the others
will remain active.
You are not hampered by memory shortages that are experienced
when using multitasking software and trying to squeeze several
programs into memory at the same time.
Disadvantages
Cost. A LAN configuration requires both hardware and software.
You must have a network card and proper cabling in addition to
the network software for each machine on the network. Most
"starter kits" for LANs cost a few hundred dollars. These kits
contain everything you need to start a LAN and connect two
machines together.
Networking With Multitasking Workstations
Advantages:
More than one node can be run from one computer while still
retaining all of the advantages of a network.
More economical than running one node per workstation
Saves space because you do not use a workstation for each node
Disadvantages:
Requires that both your multitasking setup and network setup
are well tuned because you are running a multitasker on top of
a network configuration
The remaining sections of this document will cover in detail
setup for a multiple nodes using either a multitasker or a
network. The remaining sections will also cover topics common to
any multiple node setup such as DOORs and events. Please refer
to the appropriate section for the method you have choosen to
implement your multiple node setup.
Multiple Nodes Using Multitasking Software
------------------------------------------
Topics covered in this section:
Getting Started: Details what type of hardware and software you
will need to run multiple nodes on a single computer. Everything
from the type of CPU and serial port board you should use to the
type of multiasking software and BBS software you will need is
discussed.
Modifying your System Files: Two of the most important system
files on your system are AUTOEXEC.BAT and CONFIG.SYS. It is
quite likely that you will need to modify either or both of these
files to operate properly under a multitasking environment.
Setting Up PCBoard: In your setup of PCBoard you will need to
modify a few things. For example you will need to specify how
each copy of PCBoard will know what node number it is. You will
also need to modify your batch file to run PCBoard.
Setting Up Your Nodes Under A Specific Multitasker: This section
details how to setup multiple nodes under a specific multitasker.
For example, specific instructions are included for DESQview and
Windows.
Getting Started
---------------
Using a multitasker and a fast 386 (25 mhz or higher) you can run
a recommended maximum of 4 nodes nodes on as on a single machine.
This type of setup may seem complicated at first, but after
reading this explanation the majority of your questions about
setting up a multinode system should be answered.
Recommended Hardware:
80386/486 based computer with 2 megabytes plus 512k of RAM for
each node.
I/O card using NS16550AFN UARTs. If you plan to run more than
two nodes you may wish to look into an I/O card or a special 3
or 4 port serial card that will let you use configurable IRQ
settings (preferably one that uses IRQs 2-7)
Floppy drive (5 1/4" or 3 1/2")
Hard drive
Monitor and video card
Modem for each phone line (external preferable)
If you cannot find a 4 port serial card you can use an existing
COM port and plug in a 3 port serial card. This will give you up
to 4 COM ports. One other option to get four COM ports is to use
two serial boards then have two COM ports on each. Look for COM
ports that either come with 16550 UARTs already installed or have
socketed UART chips so you can replace the existing UART with a
16550 UART.
When you are searching for a serial card keep in mind that
PCBoard requires that each COM port have a unique base address
and IRQ setting. "Intelligent" serial boards that allow several
COM ports to communicate through one IRQ, or that require
drivers, will not work since PCBoard talks directly to the
hardware.
Necessary Software:
MS-DOS (V3.3 or higher)
Multitasking Software (e.g. DESQview or Windows v3.1)
PCBoard V14.5a (/E3 or higher)
Disk caching software
NOTE: If the amount of memory you will have available is a
concern you may wish to look into using the VROOM overlay
version of PCBoard which uses less memory. The overlay
version uses less memory by storing part of the program on
disk. By using the overlay version of PCBoard there is a
slight performance penalty because some of the code is
loaded from disk rather than stored in memory.
Modifying System Files
----------------------
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 on your system so this
section details what you must have in these files in order to run
a multiple node setup using a multitasking software properly. If
you have other items in these files do not worry as they may be
necessary for your setup.
CONFIG.SYS
At this point, you should make sure you have the following items
in your CONFIG.SYS:
DEVICE=[memory manager] [optional parameters]
DEVICE=[disk cache program]
FILES=nn
BUFFERS=nn
STACKS=0,0
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:512 /P
FCBS=n,n (This line is optional)
DEVICE=[memory manager]: On this line you should load your
memory manager (e.g. QEMM, 386MAX, etc.) Your installation
program for your memory manager should place this already here
for you. If not, please consult the instructions for your memory
manager for proper installation instructions. Almost every
memory manager has parameters that you can use to customize what
memory will be used. Unless you have a good reason to specify
different parameters, leave them as is. If you do have to make
changes, be sure to consult your manual.
DEVICE=[disk cache program]: A good disk cache will do wonders
for your system performance. A disk cache is like a dynamic ram
disk. The most frequently accessed files are stored in memory so
that if they are accessed again they can be pulled from memory
instead of the hard disk. If your system does not already have a
disk cache installed you should check your DOS manual to see if
one was included with your package.
Some disk caches load through AUTOEXEC.BAT rather than
CONFIG.SYS. You should check the manual for your disk cache to
see if you should load it through AUTOEXEC.BAT or CONFIG.SYS.
Some people may ask why not use a ram disk instead of a disk
cache. If you use a ram disk instead of a disk cache you are
more likely to loose data if the power goes down and you may not
really be putting the files in the ram disk that will give the
biggest performance boost to your system. A ram disk does have
one major advantage. If you use a program that creates numerous
temporary files then a ramdisk might be beneficial. The best bet
is to use a disk cache instead of a ram disk.
FILES=nn: On this line you need to replace 'nn' with 20
multiplied by the number of nodes you are planning to run. For
example if you are planning on running 3 nodes you would set this
value to 60 (20*3).
BUFFERS=nn: For optimum performance, this value should be set to
equal the size of your hard disk clusters. The easiest way to
determine what your hard disk cluster is to run CHKDSK. You will
see a line that says nnnn bytes in each allocation unit The
number at the beginning of that line is how big your cluster size
is for the drive you ran CHKDSK on. To determine how many
kilobytes that is just divide the number of bytes by 1024. For
example, if your hard disk cluster size is 2048 bytes then use
BUFFERS=4. Since each buffer is 512 bytes - four buffers would
equal 2048 bytes which is your desired setting.
All of the buffer recommendations assume that you are using a
disk cache. If you are not using a disk cache you can increase
the number of buffers to help make up for the lack of a disk
cache.
STACKS=0,0: This is necessary when running multitasking
software. By doing this you will also free up additional memory.
On some systems, using no interrupt stacks may cause lockups or
other unexplained problems. If you are experiencing any strange
problems or your system becomes unstable you may want to try
setting your STACKS= statement to 9,128.
FCBS=n,n: FCBs were only used in older DOS programs so if you are
not running old programs that use FCBs then you may be able to
omit this line. The first parameter is the number of FCBs you
want, and the second number is the number to lock. If you do not
need FCBs then you can set this to 1,0 and free up even more
memory for your multitasker.
SHELL=C:\DOS\COMMAND.COM: Increases the available environment
space to 512 bytes. This should be plenty of room for the
environment variables that PCBoard V14.5a will create along with
any other variables that you or any other programs you run may
create.
AUTOEXEC.BAT
1. The path to locate your PCBoard V14.5 executable and
utilities must be in your PATH= statement. (Example:
PATH=C:\PCB)
2. Make sure that SHARE.EXE is being loaded inside your
AUTOEXEC.BAT. Reports have indicated that loading SHARE in high
memory can slow system performance. It is up to you whether you
load it in high memory or in conventional memory. The actual
difference in system performance may be minute.
3. Add a line at the end of your AUTOEXEC.BAT that will load
your multitasker. Whatever multitasker you choose it should be
able to automatically bring up your nodes when you load your
multitasker. If your multitasker does not have this ability then
your system will not be able to load up the nodes again if the
power goes out. Examples on how to load your nodes automatically
are provided for DESQview and Microsoft Windows in Automatically
Loading Your Nodes at Bootup later in this section.
An example AUTOEXEC.BAT might look like this:
@ECHO OFF
C:\DOS\SHARE.EXE
PATH=C:\PCB;C:\DOS;C:\UTILITY
PROMPT=$P$G
If you are using DESQview you would add the following lines to
your AUTOEXEC.BAT:
CD\DV
DV
If you are using Windows you would add
CD\WINDOWS
WIN
Now that you have modified AUTOEXEC.BAT and CONFIG.SYS you are
ready to install additional PCBoard nodes.
Installing Additional Nodes
---------------------------
NOTE: If you have not already installed PCBoard you should do
that first. Next, get all of your files created and make sure
that the single node is running properly. It will make a
multiple node setup MUCH easier.
Creating the NODE Subdirectories
You need to create a SEPARATE subdirectory for each PCBoard node
you plan to run.
For node 1 create a subdirectory off of your C:\PCB subdirectory
and call it NODE1. To do this, just change to the C:\PCB
subdirectory and type MD NODE1. Do this for each node you want
to add (e.g. for node 3's subdirectory you would type MD NODE3).
From here on, these directories will be referred to as NODE
subdirectories.
Now you should have a directory structure that looks like figure
1.
╔══════════════════════╗
║ ║
║ C:\ ║
║ │ ║
║ └───PCB ║
║ │ ║
║ ├────NODE1 ║
║ │ ║
║ ├────NODE2 ║
║ │ ║
║ ├────NODE3 ║
║ │ ║
║ └────NODE4 ║
║ ║
╚══════════════════════╝
Figure 1: An example directory tree for
a multinode system.
Now, copy the following files from the C:\PCB subdirectory into
each NODE directory:
BOARD.BAT
EVENT.SYS
PCBERR.OLD
PCBOARD.DAT
REMOTE.SYS
For example: COPY C:\PCB\BOARD.BAT C:\PCB\NODE1. Repeat this
step for each file and each node.
Once you have copied the above list of files to each of the NODE
directories, delete the files listed above from the C:\PCB
directory. If you do not delete these files then there is the
chance that you could load a node using the wrong setup files.
Setting Up PCBoard
------------------
In your PCBoard setup you will have to modify a few items for
proper operation. This section details some changes you will
want to your configuration using PCBSetup and also how you should
modify your BOARD.BAT files for each node you plan on running.
PCBSetup
(For this example, we will assume that PCBoard is installed in
C:\PCB.)
There are a few setup items which you may wish to change if you
are running under a multitasking-tasking environment. In each
node's directory do the following:
1. After installing PCBoard run PCBSetup, select NODE /
EVENT / SUBSCRIPTION and modify the following fields on the
screen:
Answer Y to Running under a Network / Multitasker System.
Replace the value in Node Number to reflect the node
number you have assigned to this node. No two nodes
should share the same number so make sure that what you
enter here is unique.
2. Whenever possible, specify a path to a file. This is
inclusive of batch files and your setup of PCBoard in general.
This can enhance the speed of your system, especially if you are
running EXE files from drives or directories located in your DOS
search PATH.
3. In File Locations 2 make sure PCBPROT.DAT contains the path
to locate the file. For example: C:\PCB\PCBPROT.DAT. In a
default PCBoard setup only PCBPROT.DAT is entered on the line.
This will cause problems in your multiple node setup if you do
not change this field to point to the full drive and pathname of
where to find it. Since you are pointing to the one PCBPROT.DAT
you will find adding, changing, or deleting protocols a lot
easier because there is only one file to update.
4. Also in File Locations 2 make sure that there is a path is
specified for PCBFILER.DEF. For example: C:\PCB\PCBFILER.DEF.
This way, your file directories will be colorized "on-the-fly"
with the colors you have defined in PCBFiler. If you finish
setting up all of your nodes and one or more of your nodes do not
display your file directories in color then you need to run
PCBSETUP from that node directory and verify that this field
points to a valid PCBFILER.DEF file.
NOTE: Since you are only going to running PCBoard from one
machine, most of your configuration files will not need to be
changed from your single node setup because they are all stored
on the same hard drive.
Modifying BOARD.BAT
The default BOARD.BAT in each node's directory looks like this:
@echo off
c:
cd\pcb
set DSZLOG=PCBDSZ.LOG
if exist REMOTE.BAT rename REMOTE.BAT REMOTE.SYS
if exist EVENT.BAT rename EVENT.BAT EVENT.SYS
if exist DOOR.BAT del DOOR.BAT
if exist ENDPCB del ENDPCB
PCB145
if exist REMOTE.BAT REMOTE
if exist DOOR.BAT DOOR
if exist EVENT.BAT EVENT
if exist ENDPCB goto end
board
:end
You will need to modify each node's BOARD.BAT file so that the
batch file changes to the directory where the node resides. For
example node 1's new batch file would look like this:
@echo off
C:
cd\PCB\NODE1
C:\DV\DVANSI
set COMBASE=bbb
set COMIRQ=i
set COMPORT=c
set DSZPORT=%COMBASE%,%COMIRQ%
set DSZLOG=PCBDSZ.LOG
if exist REMOTE.BAT rename REMOTE.BAT REMOTE.SYS
if exist EVENT.BAT rename EVENT.BAT EVENT.SYS
if exist DOOR.BAT del DOOR.BAT
if exist ENDPCB del ENDPCB
PCB145
if exist REMOTE.BAT REMOTE
if exist DOOR.BAT DOOR
if exist EVENT.BAT EVENT
if exist ENDPCB goto end
board
:end
exit
The line cd\PCB\NODE1 some explanation. In the example we told
you that this line would be used for for node 1 which is the
reason that you change to the subdirectory to C:\PCB\NODE1. As
you are setting up the rest of the nodes you will want to change
this line in the batch file so that it points to the appropriate
node subdirectory. For example if you were setting up the batch
file for node 2 then you would change the line to read
cd\PCB\NODE2.
The new lines in the batch file are described below:
C:\DV\DVANSI: This line is only necessary if you are using
DESQview. The DVANSI program is an ANSI driver that is more
friendly to DESQview.
set COMBASE: This command sets an environment variable that you
can use in your batch files to reference the base address for the
COM port. The value bbb is the three digit hexadecimal base
address for the COM port (e.g. 3f8, 2f8, 3e8, 2e8). This
variable will prove VERY useful when you start installing
external programs (DOORs, protocols, etc.) and if you use non-
standard COM ports.
set COMIRQ: This line creates an environment variable called
COMIRQ which will store the IRQ that the node will use. The
value i is the IRQ number for the COM port. Like the COMBASE
environment variable this environment variable will be
indispensable when you start configuring third-party programs.
set COMPORT: This line will create a variable called COMPORT
which will hold the number of the COM port you are using for the
node. The value c is the COM port number that you defined in
PCBSetup, Modem Information. You can use this variable from any
batch file and is especially useful when configuring third-party
programs.
set DSZPORT: By placing this in each node's BOARD.BAT file you
can use just one PCBRZ.BAT and one PCBSZ.BAT which can save you a
lot of time when/if you need to change either of those batch
files. You will notice that in this line we reference the
COMBASE and COMIRQ environment variables that were created
previously. If you are at a DOS prompt and type SET you will see
that the DSZPORT variable will reflect the proper base address
and IRQ for the COM port you are using if you defined the COMBASE
and COMIRQ variables correctly.
exit: Adding this line will assure that when you exit to DOS
through the call-waiting screen that the window on your
multitasker will close. If you wish for it to stay open then you
should make sure that you do not add this line and that you also
make sure that you setup your multitasker so that it does not
close the window upon completion of the program.
Setting Up Your Nodes Under a Specific Multitasker
--------------------------------------------------
The instructions that follow detail what steps you need to take
in order to add your nodes to DESQview and Windows 3.x. This
first section details how to setup the PIF files for both
DESQview and Windows 3.x. The next section details how to have
you automatically load each time you load your multitasker. Each
section also lists any special considerations you should be aware
of with each multitasker. The other information provided
throughout this section except where appropriately titled is
independent of the multitasker you are using.
Once you have followed the instructions detailed in the specific
section for the multitasker you are using you should proceed to
the section entitled Automatically Loading Your Nodes at Bootup.
DESQview
Before proceeding with a setup under DESQview you should first
become fimiliar with how to add programs in your DESQview
environment if you are not already famaliar with that topic.
To configure your nodes to run under DESQview you will first have
to load the setup program for DESQview. To do this, change to
your DESQview directory, at the DOS prompt type SETUP and then
press Enter.
Next, select "Performance".
Your screen should resemble figure 2.
╔1══Advanced═Setup:═Performance══════════╗
║ ║
║ Task Processing Time (in Clock Ticks) ║
║ Foreground: 2 ║
║ Background: 2 ║
║ ║
║ Memory Usage (in K) ║
║ Common Memory: 17 ║
║ DOS Buffer for EMS: 4 ║
║ ║
║ Optimize communications? (Y/N): N ║
║ Allow swapping of programs? (Y/N): N ║
║ Manage printer contention? (Y/N): N ║
║ ║
║ Next field Tab ║
║ Backup menu Esc ║
║ DONE <-┘ ║
║ ║
╚════════════════════════════════════════╝
Figure 2: The Performance section of the
Advanced Setup in DESQview.
Foreground and Background Processing Time: It is very important
that you set the foreground and background ticks to an equal
value. Otherwise, your system will likely suffer a performance
degradation which callers may perceive as an intermittent,
jerking display. The exact value for these two settings varies,
depending on how many nodes you are running and the processing
speed of your computer. Avoid setting these values to 1, which
may result in sluggish system performance. You can experiment
with this value to see which works best on your machine, though
using 2 or 3 usually seems to be a good choice.
Two of the most important settings you will change are Optimize
Communications and Manage printer contention. Set both of these
to N to help avoid possible system lockups.
Now you need to add each of the nodes to your DESQview menu so
you can bring up a node with just a couple of keystrokes. To add
each node to the DESQview menu select Open Window from the
DESQview main menu. Then select Add Program and then Other (Add
program not found in list). You will then be asked to specify a
path to the program. Supply a node directory for each program
you add. For example, enter C:\PCB\NODE1, C:\PCB\NODE2, etc.
Once you have typed in a path you will then be taken to the Add a
Program screen where you will edit the PIF file for this program.
You will need to go through this procedure for each node you plan
to run.
You now should setup the PIF files for each node. When you are
finished entering the required information on this screen it
should resemble figure 3 as it contains the recommended defaults
for most of the fields.
╔Add═a═Program═══════════════════════════════════════════════════════════╗
║ Specify Program Information ║
║ ║
║ Program Name............: Node 1 ║
║ ║
║ Keys to Use on Open Menu: N1 Memory Size (in K): 450 ║
║────────────────────────────────────────────────────────────────────────║
║ Program...: C:\PCB\NODE1\BOARD.BAT ║
║ ║
║ Parameters: ║
║ ║
║ Directory.: C:\PCB\NODE1 ║
║────────────────────────────────────────────────────────────────────────║
║ Options: ║
║ Writes text directly to screen.......: [N] ║
║ Displays graphics information........: [N] ║
║ Virtualize text/graphics (Y,N,T).....: [T] ║
║ Uses serial ports (Y,N,1,2)..........: [Y] ║
║ Requires floppy diskette.............: [N] ║
║ ║
║ Press F1 for advanced options Press <-┘ when you are DONE ║
╚════════════════════════════════════════════════════════════════════════╝
Figure 3: The first screen of the PIF editor in DESQview.
There are two fields that you should pay special attention to in
this setup screen.
Program: This is the program you wish to run. You should always
call BOARD.BAT when loading PCBoard and since each node has a
different BOARD.BAT you must change what you enter here for each
of your nodes (e.g., C:\PCB\NODE1\BOARD.BAT,
C:\PCB\NODE2\BOARD.BAT, etc.).
Directory: This field should point to the home directory for the
node. For example, in node 2's PIF file you would enter
C:\PCB\NODE2 in this field. For node 3's PIF file you would
enter C:\PCB\NODE3.
When you are finished editing the first screen, select F1 for
advanced options. You will be presented with another screen.
When you are finished filling in the values for this screen it
should resemble figure 4.
╔Add═a═Program════════════════════════════════════════════════════════════════╗
║ Specify Program Information Advanced Options ║
║ ║
║ System Memory (in K).......: 0 Maximum Program Memory Size (in K)..: ║
║ ║
║ Script Buffer Size.......: 0 Maximum Expanded Memory Size (in K): ║
║ ║
║ Text Pages: 1 Graphics Pages: 0 Initial Mode: Interrupts: 00 to FF ║
║─────────────────────────────────────────────────────────────────────────────║
║ Window Position: ║
║ Maximum Height: 25 Starting Height: Starting Row...: ║
║ Maximum Width.: 80 Starting Width.: Starting Column: ║
║─────────────────────────────────────────────────────────────────────────────║
║ Shared Program ║
║ Pathname..: ║
║ Data......: ║
║─────────────────────────────────────────────────────────────────────────────║
║ Close on exit (Y,N,blank)......: [N] Uses its own colors..............: [Y] ║
║ Allow Close Window command.....: [N] Runs in background (Y,N,blank)...: [Y] ║
║ Uses math coprocessor..........: [N] Keyboard conflict (0-F)..........: [0] ║
║ Share CPU when foreground......: [Y] Share EGA when foreground/zoomed.: [N] ║
║ Can be swapped out (Y,N,blank).: [N] Protection level (0-3)...........: [0] ║
║ ║
║ Press F1 for standard options Press <-┘ when you are DONE ║
╚═════════════════════════════════════════════════════════════════════════════╝
Figure 4: The second screen of the PIF editor in DESQview.
Program Name: You can enter anything you wish here as it is the
title that will be displayed on your window. You may want to
just enter something like NODE 1, NODE 2, etc. It does not
matter what name you wish to have displayed as your window title.
However, make sure it is unique so that you can easily identify
your windows when they are displayed on the screen or when you
wish to switch to them. If they all said Alphabet BBS then you
would have a hard time discerning which node was which on your
screen.
Keys to Open: Whichever two keys you choose they will have to be
unique. You may want to name then something like N1, N2, N3,
etc.
System Memory: This should remain 0 unless you are running a
program written expressly for DESQview.
Script Buffer: You will not be using scripts inside of PCBoard so
set this to 0.
Close on Exit: If you elected to add the exit line at the end of
your BOARD.BAT files then no matter what you select here the
window will always close when you select DOS - Busy or DOS - Not
Busy from the call-waiting screen. If you did not add the exit
statement then if you set this to Y the window will close when
you select DOS - Busy or DOS - Not Busy, otherwise it will remain
open at a DOS prompt.
Uses own colors: Set this to Y so you can see PCBoard in all its
glory.
Allow Close: By setting this to N you do not allow a Close
Window command to be executed from the DESQview menu. Remember,
it is always best to properly exit a program whenever possible.
Runs in background: Set this to Y on all dial-in nodes and set
this to N on any local maintenance nodes you may have. By
setting any local nodes to not be active in the background you
can save precious processor time should you accidently leave your
maintenance node running in the background.
Uses Math Coprocessor: This field should be set to N. You will
save precious memory and may even slightly improve performance.
Can be swapped: This should be set to N on any communications
program you run. If you set this field to Y you will cause a
hard system lock.
Microsoft Windows v3.1
In order to run multiple nodes under Windows you will need to
create a PIF file for each node. It is assumed that you have
some knowledge on how to create a PIF file under Windows. If
this area is new to you then it is suggested that you first read
the section in your manual detailing how to create a PIF file
before continuing on with your configuration.
While you are in the Windows environment, load the PIF editor.
This program will be used to create the PIF files for each node.
Create a new PIF file. When you have finished filling in the
required information on the first screen of your PIF file it
should resemble figure 5.
┌─┬──────────────────────────────────────────────────────────┐
│─│ │
├─┴──────────────────────────────────────────────────────────┤
│ File Mode Help │
├────────────────────────────────────────────────────────────┤
│ Program Filename: C:\PCB\NODE1\BOARD.BAT │
│ │
│ Window Title: NODE1 │
│ │
│ Optional Parameters: │
│ │
│ Start-up Directory: C:\PCB\NODE1 │
│ │
│ Video Memory: ■ Text O Low Graphics O High Graphics│
│ Memory Requirements: KB Require 450 KB Desired 640 │
│ │
│ EMS Memory: KB Required 0 KB Limit 400 │
│ XMS Memory: KB Required 0 KB Limit 400 │
│ │
│ Display Usage: ■ Full Screen Execution: ■ Background │
│ O Windowed O Exclusive │
│ │
│ ■ Close Window on Exit Advanced │
├────────────────────────────────────────────────────────────┤
│ Press F1 for help on Program Filename │
└────────────────────────────────────────────────────────────┘
Figure 5: The first screen of the PIF editor in Windows.
Program Filename: This is the program that you wish to run. You
should also load a node using
BOARD.BAT. If you do not, your DOOR programs, events, and remote
drops to DOS will not run. This should change for each node PIF
files and point to the correct location. For example, node 2's
PIF file would have a C:\PCB\NODE2\BOARD.BAT entered here.
Window Title: You can enter anything you wish here as it is the
title that will be displayed on your window. You may want to
just enter something like NODE 1, NODE 2, etc. It does not
matter what name you wish to have displayed as your window title.
However, make sure it is unique so that you can easilly identify
your windows when they are displayed on the screen or when you
wish to switch to them. If they all said Alphabet BBS then you
would have a hard time discerning which node was which on your
screen.
Start-up Directory: This field should point to the home
directory for the node. For example, in node 2's PIF file you
would enter C:\PCB\NODE2 in this field. For node 3's PIF file
you would enter C:\PCB\NODE3.
Display Usage -Full Screen: This is marked as full-screen to give
better performance. When a non-Windows application is running
full-screen the overhead of virtualizing the screen in a
graphical window is eliminated. This will give you better
system performance.
Close Window on Exit: If you elected to add the exit line at the
end of your BOARD.BAT files then no matter what you select here
the window will always close when you select DOS - Busy or DOS -
Not Busy from the call-waiting screen. If you did not add the
exit statement then if you set this to Y the window will close
when you select DOS - Busy or DOS - Not Busy, otherwise it will
remain open at a DOS prompt.
You should now click the Advanced button to get to the second
screen for your PIF file. When you have finished filling in the
requested information your screen should resemble figure 6.
┌─┬──────────────────────────────────────────────────────────┐
│─│ │
├─┴──────────────────────────────────────────────────────────┤
│ File Mode Help │
├────────────────────────────────────────────────────────────┤
│ Program Filename: C:\PCB\NODE1\BOARD.BAT │
│ │
│ Window Title: NODE1 │
│ │
│ Optional Parameters: │
│ │
│ Start-up Directory: C:\PCB\NODE1 │
│ │
│ Video Memory: ■ Text O Low Graphics O High Graphics│
│ Memory Requirements: KB Require 450 KB Desired 640 │
│ │
│ EMS Memory: KB Required 0 KB Limit 400 │
│ XMS Memory: KB Required 0 KB Limit 400 │
│ │
│ Display Usage: ■ Full Screen Execution: ■ Background │
│ O Windowed O Exclusive │
│ │
│ ■ Close Window on Exit Advanced │
├────────────────────────────────────────────────────────────┤
│ Press F1 for help on Program Filename │
└────────────────────────────────────────────────────────────┘
Figure 6: The second screen of the PIF editor in Windows.
Background Priority: Make sure that this value is equal to the
Foreground Priority. If it does not then the nodes that are
running in the background would run slower than the node in the
foreground.
Lock Application Memory: This is marked because you never want
to have a communications application swap out of memory while
running.
Once you have PIF files defined you will probably want to add
each node as an icon to Program Manager. Consult your Windows
manual for further information on adding programs to Program
Manager.
Automatically Loading The Nodes at Bootup
-----------------------------------------
Since for the most part your bulletin board will be unattended
you will want your nodes to automatically load when you boot your
machine. This will prevent events like power outages from
bringing down your system until you can manually bring up your
bulletin board system. This section gives you detailed
instructions for automatically bringing up your system under
DESQview and Windows.
DESQview
In order to have all of your nodes load up every time you start
DESQview you will need to use a script. The following key
sequence will create a script for starting up to 4 nodes on one
machine.
Initiate DESQview's script learning mode by pressing Shift-Alt.
Select Start Script, and when prompted for a key to define, hold
down Alt while pressing 255 on the numeric keypad. By assigning it
to an obscure key you lower the chances of accidently activating
the script.
Now you must give your script a name. Make sure it starts with
an ! (exclamation point) or it will not be executed when you
start up DESQview. Now just open up all of your nodes manually.
When you are finished, hit Shift-Alt to tell DESQview to Finish script.
Upon doing this, the windows will close; you will need to reopen
the script learning window, select Save scripts, and then save
the script you created. It is recommended that you save this
script under the name DESQVIEW.DVS.
Windows v3
To automatically load your nodes under Windows you need to modify
the LOAD= statement in your WIN.INI file. Since your WIN.INI
file is a text file you can edit it with any text editor.
Consult your Windows documentation if you have questions on
editing your WIN.INI file.
When you edit your WIN.INI file you will see a line towards the
top of the file that says LOAD=. Simply add all of you batch
files necessary to run your nodes on this line. For example if
the line said LOAD=, you would modify it so that it reads
LOAD=C:\PCB\NODE1\BOARD.BAT C:\PCB\NODE2\BOARD.BAT
C:\PCB\NODE3\BOARD.BAT C:\PCB\NODE4\BOARD.BAT.
This will bring all four nodes under Windows and all of your
windows will be initially iconized.
If you are running Windows 3.1 or later then you could put your
PCBoard icons that call the appropriate PIF files into your
StartUp folder in Program Manager. This will make the nodes come
up each time you load Windows.
Setting Up PCboard v14.5a And Local Area Netwoks
------------------------------------------------
Topics covered in this section
Getting Started: Lists what type of hardware and software you
will need to run multiple nodes on a local area network. The
overall specifications are very vague because network setups can
different vastly from installation to installation. This section
also details what PCBoard requires for network software to be
compatible and how you can test your network software to see if
it is compatible.
Planning Your Network Setup And File Locations: If you are
constructing your network for the operation of your bulletin
board then this section will help you plan what type of computers
you may need to purchase for your desired setup. In addition,
this section details what files need to be shared across the
network.
Configuring Network Drives: In a network setup you can share
disk drives between computers which means you have to assign
drive letters on all of your machines. This section shows you
how you can arrange those drive letters so that your PCBoard
setup and any other programs that you intend to run across the
network will be easier to maintain.
Modifying your System Files: Two of the most important system
files on your system are AUTOEXEC.BAT and CONFIG.SYS. It is
quite likely that you will need to modify either or both of these
files to operate properly under a networking environment.
Installing Your Other Nodes: Your PCBoard setup may require that
you have dial-in nodes, local nodes, or a combination of both.
This section details how to install additional dial-in and local
nodes.
Optimizing a Network Setup: This section details how you can
optimize your system to improve network performance and the
amount of conventional memory that you will have available.
Novell Considerations: There are a few items about Novell's
NetWare that you may want to take into consideration. There are
certain characteristics that you can change about the way NetWare
operates so that it behaves more like DOS which will make your
PCBoard setup easier.
Possible IRQ Conflicts: As is always true whenever you are
adding hardware to your system (e.g., network card) there is
always a chance that you may have two devices trying to use the
same IRQ. This section mentions a few things to look for to help
prevent this from happening on your system.
Getting Started
---------------
A local area network will allow you to expand your system to run
more than four nodes and also allow 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 but reading it will help give
you a better overview of how PCBoard works in conjunction with
networks.
Required Hardware
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.
Network card for each machine
16550 UART for each COM port (prevents COM over-runs): These
chips are direct replacements for 16450 UARTs that are
installed on most COM ports.
Required Software
PCBoard v14.5a multi-user version (/E3, /E6, /E9, etc.)
Network software
Types of Networks Supported
PCBoard works with virtually all of the DOS based LAN products
including Banyan, 3COM, LANtastic, and Novell Netware. PCBoard
requires that the network supports DOS 3.1 and higher file/record
locking procedures. Almost any NETBIOS compatible network will
probably work since that type of network usually supports the
proper file/record locking procedures.
Testing Network Compatibility
If you are unsure if your network software will meet PCBoard's
requirements listed in the Types of Networks Supported section
then 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 that PCBoard will work correct.
It is assumed that by now you have at least installed PCBoard.
If you have not yet installed PCBoard then refer to the manual
for further instructions. You must have an installed copy of
PCBoard before you test your network for compatiblity.
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
then you can run PCBDIAG.EXE which is in the directory where you
installed PCBoard. When you run PCBIAG you will see the screen
pictured in figure 1.
╔══════════════════════════════════════════════════════════════════════╗
║ Diagnostic Utility for PCBoard v14.5a ║
║ Copyright (C) 1988-1991 Clark Development Company, Inc ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ Print ALL configuration files : Y ║
║ Perform the Analysis Section : Y ║
║ Analyze USERS and INDEX files : Y ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ Please note: To prepare an upload file answer 'Y' to all of the ║
║ above then press the PGDN key and enter 'DIAG.TXT' as the output ║
║ filename. ║
║ ║
║ press PGDN to begin analysis or ESC to exit ║
║ ║
║ ║
╚═ 11:22:36 ══ 09-11-92 ══ F1 ═ help ══ caps: OFF num: OFF ins: OFF ═╝
Figure 1: PCBDiag's opening screen. This screen has three
menu options which you want to answer with a Y
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 help you include certain section of the
diagnostics in your report. The analysis section of the report
is that part that will contain the information on whether your
existing network will work with PCBoard. 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 instead send the report to disk you can type in a
filename like DIAG.TXT. After you have printed or saved your
report to disk look at it and 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 rerun the above test. If some of the
tests still fail then you do not have a compatible network.
Planning Your Network Setup and File Locations
----------------------------------------------
What Type of Computers Should I Use On My Network?
A common question that 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. Answers vary on how you want your
system setup.
For example, you may have a network setup with one server using a
80486/33 processor and then have one node per workstation with
each workstation being something a like an 80386SX/20. Of course
the ideal situation is to have the absolute fastest computers
possible on 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 steup.
When you are planning what type of machines to use for your
network keep the following in mind:
Server: Your server machine needs to be powerful enough to
support the number of nodes in your network. For a 2-3 node
setup you could most likely get by with a low end 80386.
However, as you add more nodes you will want a more powerful
machine like an 80486 so the server can keep up with all of the
workstation requests.
Workstations: This is where the majority of your processing will
go on. Since this is where the programs will actually be running
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 a blazingly fast server and
then put on XTs on the network as your workstations. Weigh your
needs and remember that a fast workstation will make your system
look like it is running even faster.
One solution that is getting quite popular is to use a 80486/33
for the server, and then for the workstations get 80386/33
computers and multitask up to four nodes on each workstation.
This type of setup does require that you properly setup your
multitasker to run up to four nodes. This can be done by reading
the preceeding section on setting up PCBoard on a multitasking
system. In addition, you must also setup the workstation
properly as far as the network is concerned. This would include
assigning network drives, etc.
Where Should I Store The PCBoard Files?
Once you have your network set up and working correctly then
setting up PCBoard for multiple nodes is really no more difficult
than setting up a single node. This is because the flexibility
of PCBoard allows you to specify where just about any file can be
found. You can specify a network drive or a local drive.
PCBoard will not care as long as it can access that file in the
location you specify.
There are only a handful of files that must be located on a
shared drive (server drive). You need to make sure that the
following files are all located on the same drive because they
are automatically updated as people call into the system.
Therefore if you stored them on your workstations you would have
no way to update the other workstations when a new user logged in
or as the files listed below changed.
Location of Node CHAT Files
Location of USERS File Index Files
Name/Loc of Users File
Name/Loc of Users Info File
Name/Loc of Callers File
Name/Loc of USERNET.DAT File
Name/Loc of MSGS File (All conferences)
Public Upld - Name/Loc Upload DIR File, Location of Uploads (all
conferences)
Private Upld - Name/Loc Upload DIR File, Locationa of Uploads
(all conferences)
There are more files that are recommended that 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 you must decide if you wish to put them
on the server, on the workstation, or put some on the server and
some on the workstations. Below are 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 could not handle all of the nodes requests if
the files were stored on the server.
Below are a few reasons why you may wish to store a majority of
files on the server
You do not wish to manually update the workstations every time
a file gets 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.
The best rule of thumb in regards to the decision of storing a
file on the server or a workstation is that if a file changes
often then store the file on the server. Otherwise, store the
file on the workstation to keep network traffic down.
If you want more speed this means putting more files on the
workstations which ultimately mean more work if you ever make a
change to a file. If you desire the easiest setup instead of
speed then you will want to store most of your files on the
server. That way when you make changes to the files on the
server all of the nodes reflect the change. The best way to
determine what files to put on the workstation and which ones to
put on the server is to sit back analyze what you need/desire and
go from there.
For now you should just use the above information to help you
consider where files will be stored on your network. Later on in
the section titled Installing Your Other Nodes you will actual
make the changes to your system.
Configuring The Network Drives
------------------------------
If you want to save yourself a lot of confusion in your network
setup you will want to configure your network setup so that 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, and your third
party utilities. If you did not make it so that the drives were
the same it would be confusing if the drive with the message
bases was drive H, drive J or some other drive. With the drive
letters the same for each node you eliminate one more possibility
for error which as your system grows you will really appreciate.
Let's consider the following example 4 node - 2 server system:
Node 1 - Server (Network name: NODE1)
System Drive Network Resource Name
C: DRIVE-C
D: DRIVE-D
E: DRIVE-E
F: DRIVE-F
G: DRIVE-G
Node 2 - Server (Network name: NODE2)
System Drive Network Resource Name
C: DRIVE-C
D: DRIVE-D
Node 3 - Workstation
System Drive Network Resource Name
Drive C N/A
Node 4 - Workstation
System Drive Network Resource Name
Drive C N/A
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 by the above setup that we have a little bit of a
dilemma. Not only do all of the computers in this example have
C: drives but the 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 so that processing is faster. What
you need to 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 node 1. 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 drives on the various machines on the network you
will use two different methods. If the drive is a physical drive
in the machine then you can use the SUBST command provided by
DOS. Otherwise you will need to use the command that your
network provides for assigning drives. Some examples are
included for the various nodes. The network commands are in
Lantastic format so if you use a different network then will need
to 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. Here are the solutions for our
example setup:
NODE1
SUBST H: C:\
SUBST I: D:\
SUBST J: E:\
SUBST K: F:\
SUBST L: G:\
NET USE M: \\NODE2\C-DRIVE
NET USE N: \\NODE2\D-DRIVE
NODE2
NET USE H: \\NODE1\C-DRIVE
NET USE I: \\NODE1\D-DRIVE
NET USE J: \\NODE1\E-DRIVE
NET USE K: \\NODE1\F-DRIVE
NET USE L: \\NODE1\G-DRIVE
SUBST M: C:\
SUBST N: D:\
NODE3
NET USE H: \\NODE1\C-DRIVE
NET USE I: \\NODE1\D-DRIVE
NET USE J: \\NODE1\E-DRIVE
NET USE K: \\NODE1\F-DRIVE
NET USE L: \\NODE1\G-DRIVE
NET USE M: \\NODE2\C-DRIVE
NET USE N: \\NODE2\D-DRIVE
NODE4
NET USE H: \\NODE1\C-DRIVE
NET USE I: \\NODE1\D-DRIVE
NET USE J: \\NODE1\E-DRIVE
NET USE K: \\NODE1\F-DRIVE
NET USE L: \\NODE1\G-DRIVE
NET USE M: \\NODE2\C-DRIVE
NET USE N: \\NODE2\D-DRIVE
If you look at each node you will see that drive H is the exact
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 what does matter is that you use the same drive
letters across the entire network.
Modifying Your System Files
---------------------------
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 on your system so this
section details what you must have in these files in order to run
a multiple node setup using a network properly. If you have
other items in these files do not worry as they may be necessary
for your particular setup.
CONFIG.SYS
The server and workstations will have different settings. Your
server should have the number of files equal to twenty times the
number of nodes that the server will manage plus twenty for
itself. In other words if you have a 7 node network (including
the server) then you would add FILES=140 to your CONFIG.SYS.
Your workstations only need twenty for each DOS process that is
running. Unless you are running a multitasker and running more
nodes on a single machine then you need to set your files equal
to twenty times the number of nodes the workstation will run.
Otherwise you should add the line FILES=20 to the workstation.
Since DOS is limited to how many FILES you can specify in
CONFIG.SYS most networks provide alternative methods for
providing additional files for your server. Consult your network
documenation if you need more files than DOS is normally able to
provide. You will know if you have exceeded the limit that DOS
provides if it errors when it runs into that line when booting
your computer.
Because you are using network drives you need to increase the
drive letters that DOS sees as valid drives. You can do this by
using the LASTDRIVE= statement in your CONFIG.SYS. In our
examples our last drive was N:. Therefore, if you were to modify
your CONFIG.SYS for that example you would add a line to your
CONFIG.SYS that said LASTDRIVE=N.
AUTOEXEC.BAT
For a multinode setup you must ensure that SHARE is either loaded
or built-in to your network. By now you should have already at
least completed the network compatibility test described earlier.
If you had to load SHARE.EXE before it would load then you will
want to modify AUTOEXEC.BAT so that it loads SHARE.EXE for you.
Installing Your Other Nodes
---------------------------
There are basically two types of nodes in a network setup -- dial-
in and local. Dial in nodes are those that are expecting calls
to come from a modem or serial port. A local login is where the
user actually runs PCBoard over the network and logs into the BBS
as if they were calling in via modem. Instructions on how to
install dial-in and local nodes are detailed below.
Dial-In Nodes
Once you have installed PCBoard on your server there are numerous
ways you can go about adding nodes. You could add one node per
workstation on the network or you could setup a multitasker on
your workstations and run more than one node on each workstation.
Whichever method you choose each of your workstation machines
should have a hard drive and each of them should also have a \PCB
directory. The following files should be copied from the \PCB
directory on the server to the \PCB directory on the workstation.
*.EXE
*.COM
*.BAT
REMOTE.SYS
EVENT.SYS
PCBOARD.DAT
PCBFILER.DEF
PCBSM.HLP
You now have two things left to do. First on each node go into
PCBSetup, Node / Event / Subscription and make sure that you have
answered Y to the Running a Network / Multitasker System and that
you have defined the proper node number on each node you have
defined. Next go into PCBSetup, File Locations 1, File Locations
2, Main Board Configuration, and Conferences and make sure that
all drive and path references are correct.
If you plan on setting your dial-in nodes up on a multitasking
workstation then you should also reference the multitasking
section earlier in this document. About the only difference is
that you must realize that some of the files in your
configuration will be read from the server rather than from the
local C: drive. All you have to do is change the drive letters
where appropriate. There are a few considerations you should be
aware of when multitasking on a network workstation.
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 then you should
increase the number of tasks. To do this add tasks=nn (where nn
is the number of tasks to allocate) to your QEMM.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. Since serial
communications use interrupts quite frequently by increasing your
tasks you can make the system breathe a little easier. Other
memory managers most likely have similar settings and you should
consult the manual for the software you are using to find out.
If you have conventional memory to burn and you would to gain a
small increase in speed of your network you may want to load all
of your network drivers in conventional memory. The overall
performance gain would be very, very small but for some people
even a very small gain is important.
Local/In-House Nodes
PCBoard works equally well across a network as it does when
accessed through external connections. When a user logs in
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 this method would compromise security of the
system because normally PCBoard allows the sysop to do certain
sysop functions from the keyboard. That is one of the reasons
why there is the /LOCALON command line switch for PCB145.EXE.
The /LOCALON switch causes PCBoard to bypass the call-waiting
screen and goes directly to the "Do you want graphics?" prompt.
When /LOCALON is used 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 could make a seperate
directory for those files and move them to that directory and
protect them via network security. Be careful about what you do
with network security however as all of the PCBoard files must
have full read/write/delete network rights to function properly.
Setting up local login nodes are for the most part easier than
setting up dial-in nodes because of the new /FLOAT command line
switch in v14.5a. This command line switch allows PCBoard to
pick a node that is not busy and automatically assign the user
that node number. This avoids the need to assign everyone a
unique node number and also makes your batch files and general
setup much easier. Using the /FLOAT switch you could have 1000
or more users vying for access to a 99 node system. If PCBoard
was unable to find a free node (i.e. all nodes were busy) then
the user would receive an "ALL NODES ARE BUSY" message.
Prior to the /FLOAT command, you had to assign each particular
person to a node number so you would not "stomp" on another node
or you had to come up with some elaborate scheme involving
numerous batch files to prevent conflicts. Of course doing
either of the above would take quite a bit of time to setup and
it also would be difficult to maintain. Now imagine trying to
coordinate all of this with dial in nodes. This is where the
/FLOAT option really shines through.
What makes the /FLOAT parameter so outstanding is that you can
have one batch file, and one setup file for all of your local
nodes. Not only that but you can start your local logins at any
number and automatically have them float all the way until you
run out of the concurrent logins that you software license
allows. This means less maintenance for you in the long run.
However, because you will only have one batch file for all of
your logins it means that for the most part you will not be able
to hard code drives and subdirectories in your batch files.
In a /FLOAT setup you must also guarantee that all of the local
users will run BOARD.BAT from a drive and subsubdirectory that is
unique to them. This could be a subdirectory on the server set
aside for just a particular user, it could be a subdirectory set
aside on the local hard drive of every workstation. In this
subdirectory PCBOARD.SYS will be created. PCBOARD.SYS is the
file that is created for every user and contains information like
the last time they logged on, user name, city, etc. This is the
only file that will remain in this unique subdirectory. Now
that you know a little bit more about /FLOAT lets proceed with a
sample setup using /FLOAT.
The first thing you will want to do 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 something like LOCAL and
create it under your PCB subdirectory. For example if your
server drive is F: you could create a subdirectory F:\PCB\LOCAL\
which would 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 over 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 that batch file that
for local logins are not necessary and also some information that
you you will need to add. For this example that BOARD.BAT that
is 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.
For this example the BOARD.BAT looks like this:
ECHO OFF
C:
CD \PCB
SET PCB=
SET DSZLOG=PCBDSZ.LOG
IF EXIST REMOTE.BAT RENAME REMOTE.BAT REMOTE.SYS
IF EXIST EVENT.BAT RENAME EVENT.BAT EVENT.SYS
IF EXIST DOOR.BAT DEL DOOR.BAT
IF EXIST ENDPCB DEL ENDPCB
PCB145
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 down your BOARD.BAT so that only these lines are
remaining:
ECHO OFF
SET PCB=
IF EXIST DOOR.BAT DEL DOOR.BAT
IF EXIST ENDPCB DEL ENDPCB
PCB145
IF EXIST DOOR.BAT DOOR
IF EXIST ENDPCB GOTO END
At this point you are probably wondering why the new BOARD.BAT is
so small. The next few paragraphs discuss what lines were taken
out as well as why they were taken out.
The first two lines that were taken out were C:, and CD\PCB.
These two lines together would change to a specific drive and
directory. While this works great for a dial in line it just
will not work with the /FLOAT switch. Since everyone will be
using one BOARD.BAT some serious problems would arise if you left
those lines in the batch file. If two users tried to login
simultaneously then they would stomp on one anothers PCBOARD.SYS
file and cause other problems with board operations. By
elminating these two lines though you can help guarantee that the
user is in a unique directory before they load PCBoard.
The only exception to this rule is when you can specify a drive
and directory in BOARD.BAT that really is unique to each
individual. As an example let's say all of the users that will
be logging in locally all have hard drives in their system that
are referred to as C:. You could make a subdirectory on all of
their C: drives called PCBLOCAL and use the BOARD.BAT to change
them to their C:\PCBLOCAL\ subdirectory. As another example
let's say that your users all have directories on the server that
only their user accounts can access. For the sake of simplicity
let's even say that this is referred to as drive F for your
users. In that case you could have board bat change to the root
subdirectory of the F: drive and then continue on.
The next line to be removed is SET DSZLOG=PCBDSZ.LOG. Since this
is for the external Zmodem protocol (DSZ) it will not be needed
for local logins. Instead, your local users should use PCBoard's
internal protocols for transferring files.
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 two statements
below PCB145 in the BOARD.BAT that start out the same way (IF
EXIST) and these should be removed as well.
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-up lines
though.
When our final batch file is done we will never make reference to
the END batch label so we also should remove the :END from the
batch file as well. There is no sense in leaving it around if
you do not need it.
This now gives you the trimmed down copy of BOARD.BAT. You now
need to change a few of the lines to accomodate local logins.
The statement SET PCB= should be changed to SET PCB=/FLOAT. This
means we will eat up six bytes from the master environment so
make sure that you have enough space. If you do not have
enough environment space then you will receive an out of
environment space error from DOS. In most cases this means
increasing your environment size by using the SHELL= statement in
your CONFIG.SYS. Refer to your DOS manual for more information
on the SHELL= line in CONFIG.SYS.
PCB145 should be changed to
PCB145 /FILE:<local subdirectory>\PCBOARD.DAT /LOCALON
The /FILE parameter tells PCBoard where it can find the
PCBOARD.DAT file. It normally looks in the current subdirectory
but if all of your local users are starting from different
subdirectories then realistically PCBOARD.DAT could not exist in
all of those directories. Of course <local subdirectory> should
be replaced with the drive and subdirectory of the local
subdirectory that you created previously. If this subdirectory
happened to be H:\PCB\LOCAL\ then your new PCB145 line would be
PCB145 /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
there the user can choose if they want to use graphics or not,
type in their username and password and then continue on. When
the /LOCALON switch is used almost all of the sysop functions are
disabled except the following:
ALT-F File Out. This can be used to output the text that
PCBoard displays to a text file
ALT-I File In. Used to import text from an ASCII file. Very
useful for importing prepared ASCII messages into the
message editor.
ALT-P Printer. PCBoard will echo text that it displays on the
screen to the printer port defined in PCBOARD.DAT that
your node uses. In this example it would look in
H:\PCB\LOCAL\PCBOARD.DAT to find the printer port.
ALT-T Top of Form. Sends a form feed to the printer defined in
PCBOARD.DAT.
F5 Shell. Allows the person at the computer to shell to
DOS. You can disable this option in PCBSetup, Options #1
by setting Allow Local SHELL to DOS to N.
If you wished you could have your BOARD.BAT also stuff the
keyboard so that your users that are logging in locally would not
have to always answer the Do you want graphics prompt. For more
information on how to do this refer to the /KEY command line
parameter in your PCBoard manual.
If PCB145.EXE is not located in the current directory or in a
directory that is listed in your PATH= statement in AUTOEXEC.BAT
then you will receive a bad command or filename message from DOS.
If you do, then tell your batch file where to find it. For
example if your PCB145.EXE file is located in Q:\PCB\ which is
not in your path then you could type Q:\PCB\PCB145.EXE to load
the PCBoard executable. You would do the same thing to the batch
file -- add Q:\PCB\ in front of PCB145.EXE.
The final line in our batch file - IF EXIST ENDPCB GOTO END
should be changed to IF EXIST ENDPCB DEL ENDPCB. PCBoard still
creates the ENDPCB file when it exits but since your batch file
does not need to check for its existence there is no sense in
leaving a file around in your local subdirectory. Why clutter up
a directory when you do not have to?
You final BOARD.BAT would look like this if your local
subdirectory is setup as H:\PCB\LOCAL\
ECHO OFF
SET PCB=/FLOAT
IF EXIST DOOR.BAT DEL DOOR.BAT
IF EXIST ENDPCB DEL ENDPCB
PCB145 /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 then PCBoard will exit with a DOS errorlevel of 99.
Therefore you could use an if errorlevel statement to check for
errorlevel 99 and do something else in the batch file as your
needs dictate.
When you are using /FLOAT it will begin filling up the nodes at
the node number specified in PCBSetup. Since PCBSetup gets most
of its information from PCBOARD.DAT that file had to be copied
into your local subdirectory so we could make changes to it.
Another advantage to having this PCBOARD.DAT just for your local
nodes is that you can disable certain features that would not be
necessary for local logins.
Because every setup is different this example setup will only
talk about how to change the node number in PCBSetup. If you
need to make other changes you may do so as your setup requires.
NOTE: If you are running on a Novell NetWare network please make
sure that you looked at the Novell NetWare Considerations
section. It contains information and guidelines you will want to
follow in your PCBoard setup.
To change the node number in the PCBOARD.DAT located in you local
subdirectory you will need to change to that subdirectory and
load PCBSETUP.EXE. When PCBSetup is loaded it will pull the
information from the PCBOARD.DAT in the current directory. After
PCBSetup is loaded select Node/Event/Subscription from the menu.
The second item from the top of the screen is Node Number on the
Network. You should set this value to the beginning node number
that you want your local users to begin logging into. If you
have dial-in lines they should be the first few nodes and your
local users should begin logging in at the node number after your
last dial-in node. Once you have done this, exit PCBSetup and
tell it to save the changes you have made.
At this point your setup using the /FLOAT option should be more
or less complete. To test your setup you can follow these steps:
1)Find two stations on the network that you can use for
testing.
2)Change to the unique drive and directory on both
workstations. This should be a drive and directory that
nobody else on the network can/would use.
3)Run BOARD.BAT on each workstation.
The machine that 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 then the first machine should come up
as node 4 and the second machine should have come up as node 5.
If it did then everything as far as PCBoard is concerned is
working correctly. If it did not then your configuration is not
correct. You should double check your setup and make sure that
you followed all of the previous instructions.
If your nodes do not return to the same directory after loading a
third party program that they left from then there is a chance
that 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 that happens when they try to login
under the same name they will be told that their name is already
in use on another node. If this occurs then you will probably
want to download a utility from Salt Air called USERNET.ZIP.
Now that PCBoard is working correctly you should verify all third
party programs to make sure they are setup correctly. It is
strongly recommended that you read the Modifying DOOR Batch Files
for a Multinode Setup.
The most important thing to remember is that the doors on all of
your nodes must return to the subdirectory where BOARD.BAT was
originally run from. Because this has to be unique on all
systems you will not be able to hardcode this into the batch
files. You will want to use the environment variables described
in the section mentioned above to help you out.
If two or more users try to login using the same directory what
will happen is that PCBoard will go directly to the command
prompt rather than to the familiar Do you want graphics? prompt.
In addition it 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 sytem like this you are likely to have file access errors and
other unforseen problems. If a user ever reports that they went
immediately to the PCBoard command prompt on their first login
make sure that they immediately logoff and check your
configuration to make sure two nodes do not conflict.
In your setup you will also find it useful if you know how
PCBoard determines if a node is busy so that it floats to the
next node. PCBoard first scans the PCBOARD.DAT you pointed to
with the /FILE parameter to find out what the beginning node
number it can start floating from. Once PCBoard finds that
number it scans USERNET.DAT beginning at that node number up to
the number of nodes that your software license allows. If a free
node is found then the user will be logged in. If it does not
find a free node then 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.).
Optimizing A Network Setup
--------------------------
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 (SMARTDRV and
Super PCKwik respectively). Consult your DOS manual for more
information on how to install a disk cache.
In PCBSetup, Node / Event / Subscription there is a field labeled
Node Chat Frequency. This field is used to determine how often a
node scans USERNET.DAT (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 you may wish to increase the value of this field so that
the network is hit less often. Do not make this value too large
though as node chats will be slowed among other things.
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 that you should use. You should 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 you should set your BUFFERS= statement to the
cluster size (in kilobytes) of the largest disk partition on each
of your computers multiplied by 2. You multiple by 2 because
each DOS buffer is 512 bytes. For example, if your largest
partition uses a 4096 byte cluster size then you would divide
4096 by 1024 to get your cluster size in kilobytes then multiple
that value by 2. In this example you would set BUFFERS=8.
If you do not know your cluster size you can 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 then you will probably
receive a message which says Cannot CHKDSK a network drive. If
that is the case then 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 it's 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.
Special Considerations For Novell Networks
------------------------------------------
If you are running Novell NetWare as your network then there are
a few items of information that you need to be aware of if you
plan on running PCBoard.
When you installed PCBoard the install program asked you if you
were running on a Novell network. If you installed the software
when you already had NetWare and answered Y to the question then
everything should be set properly. However, if you first
installed the software and then later moved up to NetWare then
you should add the /NMT switch to your SET PCB= line in
BOARD.BAT. This switch tells PCBoard not to check for
multitasking programs.
Usually PCBoard will check to see if a multitasker is running so
that it can perform more efficiently. However, in a Novell
environment when PCBoard checks for a multitasker Novell acts
like it is a Multitasker. Because PCBoard thought it found a
multitasker it is going to try and give back CPU time, etc. Most
of the time this will cause your computers to lockup and hence
the /NMT switch. It is also important that your SET PCB=
statement be active and that it have the /NMT switch whenever you
run any of the utilities that come with PCBoard. This is
necessary even with the utilities because they use the same
routines to check for multitaskers.
The other special feature that you should be aware of with
NetWare is the path. Novell, unlike DOS, searches the path not
only for executable files but for data files. This can cause
problems for PCBoard. Therefore it is recommended that you run
SMODE *.EXE 2 on all of your PCBoard executable files
(PCB145.EXE, PCBSETUP.EXE, etc.). By doing this you tell NetWare
to not search the path for datafiles when you run those programs.
In all actuallity you have made Netware behave more like DOS in
regards to the search path.
Possible IRQ Conflicts
----------------------
Whenever you are adding hardware to a system whether it be more
COM ports or a network card you need to be concerned about IRQ
line conflicts. IRQ lines are used to pass hardware interrupts
which are used to notify the CPU that the device has some
input/output that needs to be taken care of. If two devices use
the same IRQ line then you will run into some real problems.
Multitasking and networking setups will have different 'likely
case' scenarios which are described next.
Multitasking
If you are running three or more COM ports in a single machine
then it is very likely you have already experienced a COM port
conflict. Below is a table which lists typical defaults for four
COM ports:
Base
COM Address IRQ
1 03F8 4
2 02F8 3
3 03E8 4
4 02E8 3
Right away you should notice a problem. COM1 and COM3 is
supposed to share IRQ 4. Likewise COM2 and COM4 share the same
IRQ. This will DEFINATELY not work. So what you need to do is
to find two different IRQs to use for COM3 and COM4. At this
point you are probably asking yourself what IRQs can I use? IRQs
2 and 5 are usually available in a system and a wide variety of
serial port boards support IRQs 2-5. Below is a table listing
base addresses and IRQs that might be used in a computer with
four serial ports:
Base
COM Address IRQ
1 03F8 4
2 02F8 3
3 03E8 5
4 02E8 2
If you decide to use IRQ 2 you do need to realize that that it is
a little special. IRQ 2 is used to cascade the interrupts from
the upper IRQs (8-15). Therefore if you have any devices using
IRQs 8-15 make sure that by using IRQ 2 you will not cause
problems for other devices because their interrupts cannot be
properly cascaded through IRQ 2. If you do run into a problem
you may want to try using IRQ 7. This IRQ is used for LPT1 but
it is usually safe to use.
Note: If you use IRQ 2 and you have an autoswitch EGA/VGA card,
disable the autoswitch IRQ on the video card.
If you have two COM ports or a COM port and another device that
conflict with one another then you could get modem reset errors
when you load PCBoard. This is because two or more devices are
trying to get exclusive use of one IRQ. Another thing that could
happen is that the second device that was contending for the IRQ
will get it and the first device will appear to be locked up.
The solution to these symptoms is to resolve the IRQ conflict.
Double check your configuration and make sure that no two devices
conflict.
One of the reasons that external modems are recommended instead
of internal modems is because internal modems rearely let you
select a large range of IRQs for the COM ports. Then by using
external modems if you run into an IRQ conflict you can change
the settings on the serial port card. If your serial port card
does not allow you to select a wide range of IRQs then you can
buy a new serial port card that will allow you to select a wide
range of IRQs.
Networking
Like COM ports, LAN cards must communicate with the computer
through using an IRQ. Therefore you need to make sure that the
IRQ settings that you use for your COM port(s) and your network
card do not conflict with one another. If they do conflict then
you could experience lockups, excessive network timeouts, or
while PCBoard is running you may see constant Network Delay...
messages.
Modifying DOOR Batch Files for a Multinode Setup
------------------------------------------------
Somtimes setting up DOOR programs can be the most time-consuming
task in setting up a BBS. This section discusses various
techniques for installing DOOR programs on a multi-node setup.
All of the techniques in this section are designed to help save
you time both in the present setup and in the futu re when you
add more nodes. You may use these instructions for setting up
DOOR programs in a multitasking or network environment.
It is assumed that you already know how to setup a DOOR under
PCBoard. If you do not yet know how to setup a DOOR please
consult the PCBoard manual for more information. It is also
assmued that you have a good grasp on how to create batch files
and pass parameters inside of batch files.
You do not have to be a batch file wizard but you should be
familiar with the following topics:
What a batch file is
How to create and edit a batch file
Batch file commands (IF, GOTO, etc.)
Using replaceable parameters in batch files (environment
variables in particular)
If you are not familiar with batch files or any of the above
topics then please consult your DOS manual's batch file section
for more information.
Because DOOR programs are written by different authors and the
fact that there are so many DOOR programs available you will find
that the methods required to setup a particular DOOR program
differ greatly. Some DOOR authors may require that you pass
specific information on the command line of the executable file
while other DOOR authors may store all of that information in a
configuration file. Still other DOOR programs may use a
combination of configuration files and command line paramaters.
Because setting up DOOR programs requires a comprehensive
knowledge of creating batch files, setting up DOOR programs in a
multinode environment may prove tricky at first. However, your
efforts will pay off in the long run especially if you plan on
adding more nodes in the future. By using the methods discussed
in this section you will learn how you will be able to use one
batch file for each door on all of your nodes.
You can set up your system so that each node has a different
DOORS.LST. However, this would mean that you would have to add
your DOOR configuration to each node rather than making the
change on one node and spreading the change automatically through
the entire system. It is strongly recommended that you stay with
one single DOORS.LST for your entire system.
The first step in setting up a DOOR is to browse the documenation
included with the DOOR package. Look to see if the DOOR requires
any special hardware or software. If you are using a COM port
other than COM1 or COM2 then you should also check to see if the
DOOR will support non-standard COM port definitions. Otherwise
you would be unable to run that DOOR on nodes that use non-
standard COM ports.
The next step is to install the DOOR on your system as per the
instructions provided by the author. If you have questions on
the installation of the DOOR you should contact the author for
further assistance.
Test the DOOR program and make sure that it works on at least one
node. Do not proceed until you have confirmed that the DOOR
operates properly. If the DOOR does not work correctly your best
chance of getting the DOOR program to operate correctly is to
contact the author of the program directly since they know how
their program functions. If the author of the program is no
longer available try contacting other sysops to see if they might
already have it up and running. The PCBoard technical support
staff is very familiar with the PCBoard program but are not very
familiar with the thousands of third party programs that are
available for PCBoard.
Now that you know that the DOOR works you should examine the
batch file that you use to run the DOOR. When looking at this
batch file you should search for anything in there that is
specific to a particular node. Example:
C:
CD\DOORS\ABCGAME
ABCGAME C:\PCB\NODE2\ (emphasize C:\PCB\NODE2\)
C:
CD\PCB
BOARD
Notice how this patch file explicitly uses C:\PCB\NODE2\. This
means that if you ran this DOOR batch file on node 3 that it
would not work because the C:\PCB\NODE2\ is hard-coded into that
batch file.
Not all of the node specific information is so easy to spot.
Let's take a look at another example:
C:
CD\DOORS\NEATDOOR
NEATDOOR ND.CFG
C:
CD\PCB
BOARD
On the outside it appears that this DOOR does not reference any
node-specific information. However, if you look in the
configuration file for this DOOR (ND.CFG) you will most likely
find that it contains some node specific information. This node
specific information might be where to find PCBOARD.SYS,
DOOR.SYS, or even what COM port to use.
Once you have determined where the node specific information is,
you now have to find a way around this so you can still use one
batch file for all of your nodes. This is where the environment
variables that PCBoard creates and the ones you created in each
BOARD.BAT come into the picture. Now is also the time that if
you did not heed the previous warning regarding environment
variables and how to use them in batch files to consult your DOS
manual for that information.
Recalling that PCBoard will set a few environment variables
(PCBNODE, PCBDRIVE, PCBDIR, etc.) relevant to your setup and that
you created a few yourself in your BOARD.BAT you should be able
to see how these can aid you in your setup. A batch file that
did not use environment variables might look like this:
C:
CD\DOORS\ABCGAME
ABCGAME C:\PCB\NODE2\
C:
CD\PCB
BOARD
The same batch file using environment variables would look like
this:
C:
CD\DOORS\ABCGAME
ABCGAME %PCBDRIVE%%PCBDIR%\
%PCBDRIVE%
CD %PCBDIR%
BOARD
Here is a description of each line above:
C: Change to the C: drive because that is where the DOOR
is installed
CD\DOORS... Change to the \DOORS\NEATDOOR subdirectory (where
the DOOR is installed)
ABCGAME... Execute the DOOR program. Uses the PCBDRIVE and
PCBDIR environment variables to tell the DOOR where
it can find specific files (e.g. PCBOARD.SYS) for the
node running the program.
%PCBDRIVE% Change to the PCBoard drive (where the node
subdirectory is located)
CD %PCBDIR% Change to the PCBoard directory (the node
subdirectory)
BOARD Reloads your BBS batch file
The variables (surrounded by % signs) will be replaced by the
appropriate values as they are set for each node. At this point
you are probably asking yourself, if these environment variables
are so great then why did my batch file grow in size? When using
batch files it is quite likely that your batch files will grow.
The advantage you gain is that you can use this batch file for
EVERY node in your system. This helps you keep your system
maintenance down and definately makes installation easier.
Consider the following two examples to really appreciate how
using environment variables in your DOOR batch files can help you
out. 1) You add more nodes to your system. 2) You change the
location or delete the DOOR from your system.
In the first example you do not really have to do anything to
activate your new nodes on the system. If your DOOR is defined
in DOORS.LST and you have copied the DOOR to the C: drive of the
new system then you are all set.
In the second example, if you move the location of the DOOR then
you only need to change the one batch file to reflect the new
location (The first CD command in the batch file). Can you
imagine running 19 nodes and having to change 19 different batch
files. Having numerous batch files for one DOOR also increases
your chance of making a configuration mistake.
Some DOOR programs use a configuration (config) file for normal
operation. Some of these programs store node-specific
information in these files. Remember that environment variables
can only be used in the batch files themselves (i.e., not in
config files). This may lead you to wonder how you can still use
environment variables and create just one batch file for all of
your nodes. The answer is quite simple. Create multiple config
files and then use the PCBNODE environment variable to load the
proper one.
As an example lets say you have the following batch file:
C:
CD\DOORS\NEATDOOR
NEATDOOR ND.CFG
C:
CD\PCB
BOARD
Now, lets say in the ND.CFG file is the following:
C:\PCB\NODE3\PCBOARD.SYS ;location of PCBOARD.SYS
5 ;number of times game can be played per
day
400 ;points per win
If you could use environment variables in other files then the
solution would be easy enough, you would just replace the
C:\PCB\NODE3\PCBOARD.SYS in the ND.CFG file to say
%PCBDRIVE%%PCBDIR%\PCBOARD.SYS. However, you cannot do that
because environment variables cannot be read in from
configuration files. Therefore you need another alternative.
At this point you need to create a configuration file for each
node. You will want to come up with some sort of naming
convention. For this example since the original config file was
called ND.CFG you may want to simply tack on the node number to
each config file (e.g. ND1.CFG, ND2.CFG, ND3.CFG). By naming
them with the node numbers in the filename we will be able to use
the PCBNODE environment variable. The most important thing to
remember is that you should remain consistent in your naming
conventions. If you differ then you will not be able to use
environment variables.
Once you have created (or copied) a config file for each node you
need to change the first line to reflect the location of the
PCBOARD.SYS for each node. Once you have made the modification
to the config file you now need to make the modification to the
batch file. Once you have added the environment variables your
batch file would look like this:
C:
CD\DOORS\NEATDOOR
NEATDOOR ND%PCBNODE%.CFG
%PCBDRIVE%
CD %PCBDIR%
BOARD
Here is a description of each line in the batch file:
C: Change to the C: drive because that is where the
DOOR is installed
CD\DOORS... Change to the \DOORS\NEATDOOR subdirectory (where
the DOOR is installed)
NEATDOOR... Execute the DOOR program using a config file.
Because of the PCBNODE environment variable a
different file will be loaded for each node.
%PCBDRIVE% Change to the PCBoard drive (where the node
subdirectory is located)
CD %PCBDIR% Change to the PCBoard directory (the node
subdirectory)
And finally, a more complex batch file might look something like
this:
C:
CD\DOORS\PCBMAIL
PCBMAIL PCBM.CFG C:\PCB\NODE3\ /PORT:3E8:5
C:
CD \PCB\NODE2
BOARD
This DOOR represents a DOOR which points to a single config file
which does not contain information specific to any node (maximum
plays per day, points rewarded, etc.). Also passed on the
command line is the location of this node and the final parameter
passed on the command line is the base address and IRQ for the
COM port (/PORT parameter).
Do not let the additional parameters worry you. Your goal should
still be the same. Replace the node specific information with
environment variables. What makes this problem just a little
different is that PCBoard does not create environment variables
for the base address and IRQ for COM port. That is the reason
that we created the COMBASE and COMIRQ environment variables
earlier in BOARD.BAT if you were setting up for a multitasker.
We have now assured ourselves that we have environment variables
that we can use to replace all of the node specific information
in the previous batch file we are ready to change the batch file.
Your final batch file should resemble this:
C:
CD\DOORS\PCBMAIL
PCBMAIL PCBM.CFG %PCBDRIVE%%PCBDIR%\ /PORT:%COMBASE%:%COMIRQ%
%PCBDRIVE%
CD %PCBDIR%
BOARD
One thing that you should note about the above batch file is that
the DOOR that was used for this example does use a configuration
file called PCBM.CFG. However, this configuration file does not
contain any node specific information and that is why we did not
have to make any changes. All of the node specific information
was passed on the command line therefore it would be pointless to
create multiple configuration files. This batch is a little more
difficult because it contains more node specific information on
the commandline. In reality however, the technique is the same
as in the previous examples.
By now you should have noticed that for all intents and purposes
most of the batch file looks the same, the only line that has
changed is the line that calls the program. For the most part
this is the way most of your DOOR batch files will look. You
will change to the directory where the DOOR is located, run the
actual DOOR program, change back to the PCBoard drive and
directory, and finally you will reload the BBS.
Once you have replaced the node specific information with
environment variables you are now ready to test the DOOR to make
sure that with the changes you have made that the DOOR still
works as it did when you originally set it up. If it works on
one node then try it on another node and make sure that
everything still works correctly. As an extra precaution you
should try it out on every node (especially when a DOOR uses
config files) to make sure that all nodes work correctly. If
the DOOR works correctly on all nodes then you have done a good
job and everything should work correctly. However, if you have
any problems with any nodes then it is time to do a little "DOOR
debugging".
Debugging a DOOR is an easy process. There are a two commands
designed for batch files that you may want to keep in mind --
PAUSE, and ECHO ON. The PAUSE command can be used to delay
further execution of the batch file. This is useful when trying
to catch errors that might be displayed as your batch file is
running. The pause command will ask you to strike a key when it
runs. Therefore you could put a PAUSE command after every
command if you wish until you find the offending line in the
batch file.
In conjunction with the PAUSE command you can put a line that
says ECHO ON at the beginning of the batch file. This will let
you see each command of the batch file run. This method is
useful for checking to see if your environment variables are
being correctly substituted, changing to the wrong directory, and
for tracking other obvious errors.
Using these two commands together can really help you track down
some of the problems you will incur as you are creating your DOOR
batch files. If you have used these techniques and you still are
unable to track down the problem then perhaps you should consider
contacting the author of the DOOR for further instructions.
There are about as many ways to configure a DOOR as there are
DOOR programs out there. The previous examples should be used to
aid you in several of the more popular types of DOOR
configurations. Not all of the configurations could be covered
in this section so remember that you may run into configurations
that you may not recognize. If you do run into such a
configuration identify the node specific information and use
environment variables to create one batch file for all of your
nodes
In DOORS.LST if you have told PCBoard that it should swap memory
to load the DOOR (placed an S in the Shell column) then you
should not rely on the environment variables being in place.
Therefore, you should place the following statements beginning at
the second line of each node's BOARD.BAT file. For example, node
1's configuration in a multitasking environment
(C:\PCB\NODE1\BOARD.BAT) would have these lines added:
set PCBDRIVE=C:
set PCBDIR=\PCB\NODE1
set PCBNODE=1
As an additional example, node 1 on a network where each machine
runs one node you would add the following to C:\PCB\BOARD.BAT.
set PCBDRIVE=C:
set PCBDIR=\PCB
set PCBNODE=1
Make these modifications to each node's batch file.
It is absolutely critical that you do not rely on 14.5a's new
environment variables being in the environment space if you have
set PCBOARD to swap to load the DOOR (placed an "S" in the Shell
column in DOORS.LST).
Setting Up Events
-----------------
Events operate the same way if you have one node or a hundred
nodes. At a specified time a node will drop to DOS and run
EVENT.SYS (which gets renamed to EVENT.BAT by PCBoard). There
are a few new elements in regards to event batch files when you
run multiple nodes:
1. Some programs requires that all nodes be down when they run.
If that is the case then you must make sure that all nodes are
down (i.e. PCBoard is not running). In a case like that you can
have the nodes that do not have any tasks to do in the event
simply run a program that counts down x amount of minutes. Then
after sufficient time has passed the nodes can reload BOARD.BAT
and be ready to take more calls. There are some utilties on Salt
Air that do nothing more than count down x amount of seconds or x
minutes and then continue. Most of these utilities can be found
by using the (L)ocate command and searching for WAIT*.* in (A)ll
directories.
2. Because you have multiple nodes you could elect to disperse
the programs that run in your event to each of your nodes.
However, if you do there is more of a possibility that you could
run into conflicts. For example if one node was accessing the
USERS file at the same time as another utility you could run into
a sharing violation which would hang your event with a sharing
error. There are several utilities on Salt Air that can help you
prevent conflicts like the one described previously. To locate
some of these files you could do a (Z)ippy scan for EVENT MANAGER
in (A)ll directories.
Third Party Software Setup Recommendations
------------------------------------------
DSZ (ZMODEM TRANSFER PROTOCOL)
Your PCBRZ & PCBSZ batch files should resemble the following
examples:
PCBRZ.BAT
echo off
if exist PCBERR.FIL del PCBERR.FIL
if exist %DSZLOG% del %DSZLOG%
DSZ F pY129 handshake both estimate 0 %5 pB4096 pd0 z pr1 rz -p
%3
PCBSZ.BAT
echo off
if exist PCBERR.FIL del PCBERR.FIL
if exist %DSZLOG% del %DSZLOG%
DSZ F pY129 handshake both pB4096 estimate 0 %5 z sz %3
Earlier we modified BOARD.BAT so that an environment variable
called DSZPORT was created. This environment variable contains
the information regarding the COM port configuration for each
node that is why nothing regarding which COM port to use is
included in either PCBRZ.BAT or the PCBSZ.BAT.
The F and pY129 parameters are new to the DSZ command line.
These parameters will help improve performance and will cause DSZ
to use less CPU cycles during DSZ transfers which will speed up
the other PCBoard nodes. If you are not using 16550A UARTs then
remove this parameters from the above batch files as these
parameters only work with 16550A UARTs.
If you get error messages that look like the example below then
you are experiencing COM over-runs and need to replace your
existing UART with a 16550A UART.
Byte 119296 attempt 1: Bad CRC ( or Garbled data subpacket).
127232 ZMODEM CRC-32
Serial input ERROR : Line Status Register 02
All DSZ commands are case sensitive and should be entered just as
you find them in this example.
DOORWAY
The shareware version of DOORWAY is included with v14.5a so that
you can do remote drops to DOS via REMOTE.SYS. If you look at
REMOTE.SYS you will find that it looks like this:
set box=no
doorway com1 /v:d^O /m:600 /g:on /o: /k:v0 /c:dos
set box=
c:
cd \pcb
board
If you are using a COM port other than COM1 then you will need to
change this value to whatever COM port you are using. If you are
using a COM port other than COM1 or COM2 then instead of com1 or
com2 you should use the port command line parameter. The syntax
for this parameter is as follows:
PORT:bbb,i (where bbb is the COM port base address with
a zero in front and i is the IRQ).
If you set the COMBASE and COMIRQ variables that were discussed
earlier then you could also make use of them here as well. Here
is an exmaple REMOTE.SYS using the COMBASE and COMIRQ environment
variables:
set box=no
doorway port:0%COMBASE%:%COMIRQ% /v:d^O /m:600 /g:on /o: /k:v0
/c:dos
set box=
c:
cd \pcb
board
NOTE: The 0 in front of the three digit hexadecimal base address
is necessary on the DOORWAY command line because that is the
syntax that it expects. If you do not, then you will receive an
error message telling you that the syntax for the PORT parameter
is incorrect.
Answers to Common Multinode Questions
-------------------------------------
When I make a change to one of the conferences (including the
Main Board) the change shows up on all of the nodes. Why?
This is because all of your nodes point to the same CNAMES file
(located in PCBSetup, File Locations #1). The CNAMES file
contains all conference information and since you are using one
CNAMES file you see the changes reflected on all nodes.
The obvious solution would be to specify different CNAMES files
on each node. This is not recommended though because any time
you made a change to any conference you would have to make that
same change on each node. For example if you were to setup a new
conference you would have to set it up on each node and hope that
you have set it up exactly the same on all nodes. By specifying
a different CNAMES file for each node you open up the door for
more mistakes. Instead use relative addressing.
Relative addressing depends on the current subdirectory to
determine where it looks for files. In your file locations if
you give only the filename (no drive or directory locations) then
the PCBoard will look for the file in the current or default
directory. Because each of your nodes should be using a
different directory this means that you can still keep one copy
of CNAMES but you can have unique conference files for each node
as your needs dictate.
Relative addressing looks like this:
1. DOORS.LST
2. GEN\BLT
3. \PCB\MAIN\SCRIPT.LST
1. 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\ then the
program is going to try and open C:\PCB\DOORS.LST. On another
machine your current subdirectory may be D:\PCB\. If so, then
the program will look for D:\PCB\DOORS.LST instead.
2. 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 subdfirectory called
GEN underneath the current subdirectory. For example, if your
current subdirectory is C:\PCB\ then the GEN\BLT would be added
on to create C:\PCB\GEN\BLT.
3. If all that is different is the drive letters that you use
between machines then 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.
When using relative addressing because if you are not careful you
could 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
did then you would not get the errors saying that you could not
find the file but you would end up creating two seperate files
with each copy specific to a particular node. This means that a
message that is left on one node would never show up on another
node because they are using seperate files.
Absolute addressing, on the other hand, looks like this:
1. C:\PCB\GEN\DOORS.LST
2. D:\PCB\GEN\BLT
3. E:\PCB\MAIN\SCRIPTS\SCRIPT.LST
4. 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 ringdown 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
someone or some other node has started from. Recall that PCBoard
requires that it be loaded from a unique drive and subdirectory
because it will write PCBOARD.SYS, DOOR.SYS, USERS.SYS, and
ENDPCB to the directory you actually load PCBoard from. If two
nodes try to load from the same directory then they will of
course conflict and because PCBoard recognizes that someone is
already online their session is continued.
Will PCBoard use a modem on another computer via a network?
No. PCBoard talks directly to the COM port therefore it would
not be possible.
Every once in a while I will see a message that says SHARING
VIOLATION. What exactly is a sharing violation?
A sharing violation is when two programs try to access the same
file when one of the programs has the file "locked". In normal
multinode 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 or write from that
file. These errors can be reported by the programs themselves or
by DOS. To resolve the conflict check and see what programs
could be accessing the same files and try to work around them
trying to access the file at the same time.
In my network startup batch file I tell it to redirect the local
C: drive to the C: drive on the server. Just after this line
executes in my batch file the batch files stops running. Why?
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: when it tries to execute the next
line in the batch file it stops cold because that batch file that
it was running can no longer be found on newly redirected C:
drive.
Whenever I open up a node's window it loads the wrong node and
sometimes gives a modem reset error. Why does it do this?
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 COM port. Make sure you change to the correct
node directory before you execute PCBoard so that the correct
PCBOARD.DAT (setup) file is read.
If that setup checks out okay then also make sure that you have
resolved all IRQ conflicts between the COM ports and all other
devices in your computer. The most common conflict is that you
have used IRQ4 on both COM1 and COM3.
Sometimes when loading PCBoard it just hangs. What is causing
it?
Try disabling your cache for test purposes. Some shareware
caches have been known to cause problems. Also, if this appears
to be happening with a particular door make a note of it and
leave a message on Salt Air detailing what you are seeing.
When a DOOR runs it will display the opening screen okay but when
a user types something it does not show up on the screen.
This problem occurs more often on a multitasking setup because
you are more likely to be using non-standard COM ports. What is
happening is the DOOR programs you are running are not currently
setup to use non standard COM ports. In other words the IRQ that
the DOOR thinks you are using and the one that 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 that 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 utility available on Salt
Air under the filename of WAIT4.ZIP. Your EVENT.SYS files may
look like this:
Node 1's EVENT.SYS
@ECHO OFF
PCBPACK /AREA:0
PCBPACK /USERS
BOARD
Node 2's EVENT.SYS
@ECHO OFF
WAIT4 360
BOARD
Node 3's EVENT.SYS
@ECHO OFF
WAIT4 360
BOARD
Using these example EVENT.SYS files, node 1 will pack both the
message base and the users file and then return upon completion.
In the meantime, nodes 2 and 3 will be on hold for 360 seconds (6
minutes). After the 6 minutes are completed, the EVENT.SYS file
reloads the BBS by executing the BOARD batch file.
Everyone seems to recommend 16550 UARTs for my COM ports. What
are they, how do I find out what type of UART I have, and why do
I need them?
A UART is the chip on serial port boards that handles the input
and output through the COM port. What makes the 16550 UART
important to multiple node setups is that they can buffer more
data than other UARTs. The 16550 will buffer up to 16 bytes of
data as opposed to the one byte that most other UART chips
handle. In order to maintain error-free connections with high
speed modems, multitaskers, or networks a 16550 is for the most
part mandatory.
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) and logging in as the sysop. Once you are in the
BBS you can press Alt-H four times. You will notice that after
pressing Alt-H four times your status line will change each time
and will look like the example below:
Notice how on the bottom line towards the right hand side is the
text 8250A/16450. If you had a 16550 UART either 16550 or 16550A
would be displayed. Of the two, 16550A is the one you want as it
is the newer UART chip and does not have the serious flaw that
the original 16550 UART had.
If you do not have 16550 UARTs on all of your serial ports then
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 then you could run down to the local electronics
warehouse and ask for part number PC16550CN or NS16550AFN. Once
you have the new UART and if your existing UART chip is socketed,
then 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 then it is
advised that you contact a computer technician who will do it for
you.
I seem to see a message that always says out of environment space
while my BBS is running. What does that mean and how do I fix
it?
When you receive an out of environment space message from DOS
that means that you did not have enough room in your environment
to store the environment variable. 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. Most have found that setting
their environment for 512 bytes allows plenty of space.
If you are using Windows v3.0 then you may have to make a change
in your AUTOEXEC.BAT and BOARD.BAT files due to the way that v3.0
handled environment space. In your AUTOEXEC.BAT you could add
the following line:
SET
PTEMP=********************************************************
Then in BOARD.BAT add the following line:
SET PTEMP=
What you just did is reserve space in your environment. After
windows loads and executes your BOARD.BAT, your batch file de-
allocates that environment variable making that room available
for PCBoard.
If you have Windows 3.1 then your setup will be easier. This
version of Windows made some changes in the way the environment
is handled. 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 will noted that the default value is 512 bytes which should
be just 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 manual for further instructions.
Ever since I started using the VROOMM overlay version of PCBoard
I seem to be experiencing sharing violations when PCBoard is
loading or returning from DOOR applications. What is causing
this?
Because the overlay version of PCBoard stores some of the code on
disk there is a chance that two nodes could conflict while
loading. To help prevent this you can make your PCB145.EXE or
VRM145.EXE file read only. To make either of these files read
only you can use the ATTRIB command provided by DOS like in the
example below:
ATTRIB +R PCB145.EXE