Media Share 9

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