C-BBS V7.20m (Multi-Port) for the AMIGA (Kickstart V1.3 and V2.0) Multi-Port Documentation (DRAFT) Copyright VE5VA 17-May-1994 BEFORE you try to run multiple ports make a BACKUP of EVERYTHING. I will not be held responsible for the loss of any data. Use this version at your own risk! I have finally solved the problem of mediating between multiple processes all trying to read or write the mail.dat, user.dat and bid.mb files. I have added code that uses semaphores to control access to each file. When running multiple copies of 'mb' you still only need ONE copy of the following files: mail.dat user.dat config.mb bid.mb help.mb info.mb states.mb reject.btn Other files require a separate copy for each port, but in order to allow a single-port system to be run without any changes, the names of the files for port A do not change from what is specified in the config.mb file. For example, the log.mb file is still called log.mb on port A, but on all other ports the system changes the name so that the suffix is the port letter. Therefore, the 'mb' that runs on port D will create and maintain a log file called log.d. Most of the files such as the log file and calls.mb are created by the system with correct names if they are not present when the program starts. There are only a few that the user must create. All the following files require multiple copies and will be created in the same way as shown in the table below. Port -> A B C ....... log.mb log.b log.c etc. mon.mb mon.b mon.c calls.mb calls.b calls.c tnc.on tnc.on.b tnc.on.c tnc.off tnc.off.b tnc.off.c talk.on talk.on.b talk.on.c talk.off talk.off.b talk.off.c The first three in the list are created automatically by the system. The remaining files must be created by the user if the files are needed (e.g. you probably won't have talk.on or talk.off files for all the ports). The bulletin.a, bulletin.b etc. files are unchanged and are created as needed by the sysop. When you start up each copy of 'mb' it must have the -pP argument on it to specify which port (P) the program is to use. If it is not specified then the port letter P defaults to port A (see the example startup script below). The config.mb file does not change and all ports are specified in the one copy of config.mb. You tell a specific copy of 'mb' which port it is to use by specifying the port letter as an argument when 'mb' is started. It then reads only that port and port 'Z' from the port description list. To simplify the startup procedure, I have modified the code so that you can specify the device unit number and name, in that order, at the end of the port specification line. The unit number defaults to zero and the name defaults to "serial.device". You can still use the -u and -n arguments if you wish. The content of the config.mb file will override the arguments if they are both given. Here is an example of the beginning of a config.mb file describing two ports: A123UDRT 600 20 600 100 20 4 5 8 15 0 serial.device -> 145.01 Mhz. B123UDRT 600 20 600 100 20 4 15 8 15 1 serial.device -> 443.71 Mhz ZCE#D 300 10 600 100 10 0 27 8 0 -> Stations Connected *** EOF Note that in V7.2, the console port is now port Z (not port L). When each copy starts up, it creates a public port which contains the name of the port so that you can start up your system in an orderly fashion. For example, port B will create the port name "CBBS-B" and your startup script can use waitport to wait until this name is created before it starts up the next port. E.g. ; This script is used with the multi-port version of 'mb'. ; An example of starting up a 3 port system. I have omitted details like ; specifying the window position and size using the -w argument. ; This example assumes that the port unit and device names are specified ; in config.mb ; ; Always delete T:mbuser.index at startup if it exists. if exists T:mbuser.index delete T:mbuser.index endif ; ; Change to the directory containing C-BBS ; cd work:cbbs ; ; Start locker run locker waitport VE5VA-LOCK 20 ; ; I don't need the -z argument when running mb because it is set with the ; setenv command in my s:startup-sequence. ; Default to port A on startup ; run mb waitport CBBS-A 20 ; Specify port B run mb -pB waitport CBBS-B 20 ; and port C run mb -pC waitport CBBS-C 20 ; and just as an example lets get sysop going too run sysop waitport CBBS-1 20 Note that at the beginning, the script looks for the file T:mbuser.index and if it exists it is deleted. In order to handle multiple accesses to the user file, I had to change the way in which it checks to see if it knows a specific user callsign. In the original C-BBS, each copy of 'mb' kept its own list of callsigns in a table. This causes a problem because if the user file changes size then every process must recreate their internal table. To simplify things, I changed the code so that the table is stored in the file T:mbuser.index which is accessible to all processes. The first process to start up (usually port A, but it doesn't have to be) will find that the index is not in ram so it will get a lock on the user file, create the index and then release the lock. The other processes will find that the index is already there and won't try to recreate it. The file is only modified if a user is added to, or deleted from, the user.dat file. In this case, the process making the change will also change the index. The other processes will find out that the file has changed when they try to access the lock on the file and this causes them to close the file and reopen it so that they see the changes that have been made. This is essentially how the locking is handled with the mail.dat too except that it doesn't need an index file - it is the index. The only other file that required locking was the bid.mb file. The forwarding process has been modified slightly to prevent multiple copies of 'mb' trying to do a forward on the console port 'Z' at the same time. Only the port A process will do forwarding for the console and therefore there MUST be a port A process if you want forwarding for port Z to be done. The locking which prevents 'GM', 'GU' and 'GR' from being executed while any other process is active is still incorporated in the program. If you set a forwarding script so that a 'GM' is done automatically at 3am it will only succeed if nobody else is logged in at the time AND THIS INCLUDES THE SYSOP PROCESS which must be idle when the 'GM' is attempted.