Setting up the system with several nodes

This documentation assumes that you will be running more than one node under the DESQview multitasking software. Other multitasking systems may be used, but in that the author has no particular experience with any of these then the details for other systems will have to be found by trial and error. The basics should on the other hand be quite similar in priciple, so it should not be too difficult.

Software requirements

The multinode environment requires MS-DOS 3.10 or better; because of known errors in DOS 3.10 we recommend that you implement DOS 3.20 or better to save yourself trouble.

The system has been tested with all versions of DESQview from 1.02 to 2.01 and functions equally well on all of them. The following documentation will assume DV 2.01

Requirements for your CONFIG.SYS file

In that you will be running under DESQview which does its own ANSI emulation, the requirement for ANSI.SYS in your CONFIG.SYS no longer applies (although you may wish to keep it there for other reasons). On the other hand, when running several nodes, there is a need for more files to be open concurrently, so I would recommend that you increase the FILES and BUFFERS parameters if you have not already done so. For two nodes, FILES=30 and BUFFERS=30 should be more than enough.

Requirements for your AUTOEXEC.BAT file

VERY IMPORTANT!

You must include the SHARE command in your AUTOEXEC.BAT file; if you don't you risk all kinds of nasty things happening to your disk, crosslinks, lost clusters, and the like. So long as the SHARE is executed before you take up the system it's OK, but putting it in your AUTOEXEC file is the safest way.

The last thing your AUTOEXEC.BAT file should do is to call DESQview (this is assuming that you wish the system to boot itself into the system automatically).

Configuring your BBS system

Using multiple configuration files

Each node must have some files that belong only to the node, and some that it must share with the other nodes. CFGBBS will in general give you hints on which is which; first of all however, the most important thing is that each node has its own configuration file. Both CFGBBS and the BBS program itself accept a single parameter on the command line, to specify the name of the configuration file to be used. If we were to be configuring two nodes, then, what we would do is to decide that the configuration files were to be called C1 and C2 respectively. Then to configure node 1 you would enter

CFGBBS C1

while to configure node 2 you would enter

CFGBBS C2.

In the same way, you will have to have two different GO.BAT files to start up the system. Let's call them GO1.BAT and GO2.BAT respectively. Then the only real difference between these and the standard GO.BAT file is that the line which actually starts up the BBS:

BBS

must be changed to read the correct configuration file, in other words you would have

BBS C1

in the file GO1.BAT

and

BBS C2

in the file GO2.BAT.

So far as the rest of the configuration goes, there are also a couple of inportant points to remember. You MUST configure a different scratchpad name for each node! Otherwise your users are going to get all kinds of strange results.. It is also RECOMMENDED that you use a separate callers file for each node, as this file will otherwise be difficult to examine. Also you MUST configure a different REMOTE.BAT name (and build the file correctly) for each node. Each node of course must have a different number in its configuration.

The best way to start out is to configure one node completely and then copy its configuration file to the name you are going to use for the second, and modify that one, rather than start from scratch for each node, in that there will be a large number of parameters that will be the same for each node.

Once you have got your configuration files working you can use the CFGUPD program included with the software to move common parts of the configuration from one file to the other. For example, if you change the conference configuration for node 1 and now need to do it for node 2 (they ought to be the same!) you just type

CFGUPD C1 C2

which will move all the common information from file to C1 to C2, while preserving things in C2 that are node-specific. Once you have a system set up and running you will probably start adding some things to specific config files that you do not want copied from one configuration to another. In that situation use the following:

CFGUPD * C1 C2

This form of the command will only update information that must be the same from one node to another:

Conference information
Total number of nodes
File system information
Sysop macros

If you are configuring a local node, remember to set the communications port parameter to zero!

Using the command line

Starting with release 10.2, most Sysops will be able to use a single configuration file for several nodes; often it will be enough to configure one file for modem nodes and one for local use. This is possible because those parameters that are most often different from node to node may be specified as command line parameters to the BBS command in the BAT file you use to start the BBS (all parameters specified in this way override the equivalent values in the configuration file):

/NOD n Sets the node number /B Sets the baud rate for the modem /CP p Sets the comms port: 0 = local 1 = COM1 2 = COM2 3 = port specified with /CB and /CI /CB xxxx Sets the comms port base address (hex) /CI n Sets the comms port IRQ /NE Disables all events /NI Disables comms output interrupt /NFI Disables 16550 FIFO /LOC 'Local' (direct system, fast start, no sleep disc) /BU Sets the baud rate to report as the connect rate /MNP Report login as MNP login

For completeness, we document here the other command line parameters that may be specified:

/N first last Specify a user name for immediate login /P pass Specify a user password for immediate login /S script Specify a script name for immediate execute /E Enable extra event logging on callers /F Disables use of Ctrl-K, R+W functions in editor /M nn Maximum minutes allowed online

Additionally of course, for this setup using a common configuration file to work correctly, you will need to have some way of telling the BBS about those files and directories that should be different from node to node. This is done by inserting a '%' sign into the CFGBBS parameter - when the system uses the parameter then the '%' sign will be replaced with the number of the current node. The following parameters support use of '%' as part of their specification:

System name Callers filename Scratchpad filename REMOTE.BAT filename Hold directory Local download directory

Configuring DESQview

Assuming that you have built your GOn.BAT files, then the DESQview configuration is simple. If you want to run in the smallest amount of memory possible you should turn off the ARC scratchpad and Zmodem options, and may configure the system at 160K. If you want to use either of the above, then you should configure the system at at least 256K.

In the advanced setup menus you should also reduce the number of default foreground/background ticks to 'smooth' performance. However don't reduce them below 2 or strange results will probably be seen (and if you are getting strange results increase the number of allocated ticks again).

As the program name you enter the name of your BAT file (e.g. GO1.BAT), there are no parameters, and the directory name is the place where you have the GO, and BBS.* files.

The following options should be used:

Writes directly to screen......: [N]
Displays graphics information..: [N]
Can be swapped out of memory...: [N]
Requires floppy diskette.......: [N]

Close on exit to DOS.........: [N] Uses its own colors.........: [Y] Allow Close Window Command...: [Y] Runs only in foreground.....: [N] Uses math coprocessor........: [N] Keyboard conflict (0-4).....: [0]

The builtin 'learn' feature in DESQview should be used to start the necessary windows automatically when the system is taken up.