CBBS V6.1c for the AMIGA (Kickstart V1.2 and V1.3) 17-Jul-1989 This program is basically a CBBS 6.1 version of the W0RLI BBS. It was originally put together for the IBM-XT by K3RLI, AG3F and others. It is written in the 'C' programming language which made it fairly easy for me to port to the AMIGA because I have been using C since 1974. However, it has had to be modified somewhat to make it work on the AMIGA. It has been used extensively on an AMIGA with the V1.2 Kickstart. It starts up and appears to work OK with Kickstart V1.3 but has not been tested extensively. It will work on a system with 512K of memory. I have run it on a single floppy drive, although that required limiting the number of files on the BBS. With such limited disk space you will only be able to handle transfer of mail rather than running as a full-blown BBS. But if you have a hard drive you can run a full-blast BBS with this program. If you are already familiar with the CBBS or W0RLI (or even MBL) systems you should have little trouble getting this thing to go. You MUST be able to use the CLI and an editor in order to set the BBS up properly. I have only used the BBS with a KAM and an old TAPR TNC1 with the upgrade to TNC2 V1.1.6, but there should be no problem running this BBS with others such as GLB, PK232, PACCOMM etc. provided that they are TNC-2 compatible (if you are running one of these, read the info below about the problems with the TAPR V1.1.6 just in case they apply to you). The program will permit KAM users to run one HF and one VHF port. It will only allow connects from one side at a time but forwarding and logins to HF and VHF can be accomplished. For other TNCs you are stuck with running either VHF or HF at any one time. I have done very little to customize the program for the amiga ... no menus etc. There are two reasons for this. First, it's a lot of work and I don't feel like doing it. The source is here and compiles with MANX 3.6a, help yourself! Second, there are other CBBS and W0RLI systems around which run on IBM and other disgusting machines. They all use the same command structure so if you can run the amiga BBS, you can run IBM etc.. But if the commands are all buried in menus you won't be able to switch to other machines. Not a big deal but another justification for me to leave well alone. The only concession to the amiga environment was to provide a window title when the BBS comes up. Clicking on the top-left 'close' gadget will make the BBS shut itself down in the same way as the 'Q' command except that it does not ask you if you are sure you want to terminate the program. The two numbers in the title separated by a slash are the highest message number and the number of active messages. In earlier versions the number of active messages was exactly that, the number of messages you would see if you asked the BBS to list every mail message it had. But in V6 this number also includes the number of messages created and deleted since the last 'GM' command. So if the number of messages listed is way less than the number in the title bar, it's time to do a 'GM' command to clean up. I have not explicitly modified the program to take advantage of available ram:. But look at the tnc.on file. When the program starts it dumps the tnc.on file into your TNC to initialize its parameters. It also allows you to put CLI commands in that same file and you can, for example, set up your config.mb file so that help.mb, info.mb, user.dat, mail.dat and other files are specified as being in a ram: directory. CLI commands are then put into 'tnc.on' to actually copy the files into ram: as the program starts up. Thus, you don't need to load the files into ram: as a separate operation before the BBS starts up. Your forwarding files can also be modified so that after a regular forwarding operation or after the regular console 'forward', the system copies mail.dat and user.dat back to disk. (help.mb and info.mb are not modified by CBBS so they do not have to be saved back to disk). If you do this, you will also have to modify tnc.off so that it saves the files when the bbs is shutdown and you should also be cautious that shutting the bbs down before the ram: files are saved could leave the bbs files in an indeterminate state. Putting the files in ram: really speeds up the operation of the bbs especially if you are only using floppy drives. It also significantly speeds up other operations such as untangling the mail file and user files (GM and GU commands). It is safest to specify that the backup files mail.bak and user.bak are still on disk. Just in case. BEFORE YOU START UP THE PROGRAM READ THIS PROCEDURE. ** Make a few backups of this disk!!!!! ** Print out this readme file, the manual.bbs file and the config.mb file which is in the 'cbbs' directory. If you aren't familiar with BBS systems at all then read manual.bbs first very carefully. As you read through it, it will help to have the copy of the config.mb file with you. But remember as you read it that it was intended for users of IBM machines so some references to things like DESQVIEW and windows etc. are irrelevant to you. (The IBM concept of window mentioned in the manual is not the same as an AMIGA window and should be ignored). You should then read through the rest of this file. ** If you are going to use just this disk as the BBS then you will have to clean up the space on it. Further, if you have only one disk drive then you are going to have to change this disk so that it can be booted. I haven't tried that at all but it can be done. Make a few backups, and then you can delete vt100.doc, manual.bbs, the readme files, all the C source if you don't want it online, and if there are commands in the c directory you won't use then remove them too. ** The TNC MUST be wired up for HARDWARE HANDSHAKING. If your TNC is not currently wired for hardware handshaking then do it NOW. My KAM is wired as follows: KAM Pin AMIGA 2 2 3 3 4 4 5 5 7 7 6-8-20 (all jumpered AMIGA side only) ** Before you start up the BBS the TNC PARITY MUST be set to NONE (or SPACE). On my KAM no parity is "PAR 4" (and space is "PAR 3"). Any other parity setting will not work. You can use the vt100 program on this disk to talk to the TNC to set the parity before you start up the BBS. (Thanks are due to Frank, DF3UM, who suffered through this problem and brought it to light for me). There is a nasty problem with TNC1s that have the TAPR V1.1.5/6 upgrade. The manual states that setting PAR to 0 or 2 means parity is set to none, but it actually forces the parity to a one all the time. The BBS expects parity to be forced to zero. To get around this you can specify the '-t' flag when you start up the BBS and the BBS software will strip the high order bit off every character that it receives from the TNC. This means you cannot use transparent mode even if I get it working in a future release. ** Your TNC must have the commands: streamdb on users 1 (and on the KAM users 1/1) so that the BBS software will process stream switch characters properly and will only permit one user at a time to connect to the BBS. The BBS does a 'conok off' whenever someone connects but it is safest to make sure that nobody else can get in. Your TNC can also have the command: autolf off This command is not essential but it does make the screen output clearer. All of these commands can be put into the tnc.on file. ** The manual refers to use of transparent mode. I haven't implemented the necessary stuff yet. DON'T USE IT. ** You MUST edit the configuration file config.mb. There are two places in it (obviously marked) where you must put your callsign and one where you must put your QTH. NOTE also that there is one place where a line generates the time in a message that is being forwarded. Currently the timezone printed out is CST. If you are not using CST on your amiga you'll have to find the line and change CST to your timezone (or Z if you run your beast on UTC). The line looks like this: R:$J/$KCST $M@$O [$Q] ^^^ Change this if necessary. The structure of this disk corresponds to the config.mb file but you can change it if you wish. If you have a hard drive you will certainly want to have CBBS use that instead of a floppy. You can also set the config file up so that it will use two (or three) floppies instead of one (i.e. you can spread the BBS directories across two or more drives to spread out the load). I have changed the remote sysop password scheme in the amiga version. It is described later, but you should change the existing example password, which is at the end of the config.mb file, or replace it with one line containing a single zero if you don't want to permit remote sysop. ** DON'T change the port designators for the TNC and console terminal in the config.mb file. They MUST be 'A' (the TNC) and 'L' (console) respectively. Any other port designators are ignored and so are a waste of space. ** When the program starts up it looks for the file fwd.mb to define what it does for forwarding files. This file will have to be edited. I have left parts of my forwarding files here for you to look at as examples. As distributed, fwd.mb contains just enough to forward to VE5OP which is our local BBS on vhf. NOTE that there is a |a as part of the connection string. This is only required if you have a KAM to force the forwarding onto VHF. Similarly, there are a few files (20m.fwd etc.) that do forwarding on HF and have a ~a in them. If you aren't running a KAM you must edit these out of the files as you'll only have one port to use anyway, in which case delete the two characters |a or ~a as appropriate. Notice also that some of the TNC commands have a '/' in them. These are specific to the KAM since many of its commands apply to the HF and VHF ports. Such commands are specified as, for example, 'retry 10/5', which sets the retry parameter to 10 for HF and to 5 for VHF. Similarly, the command 'retry 10/' sets the HF retry to 10 but leaves the VHF retry as it is. You can make CBBS use a forwarding file other than fwd.mb after the BBS comes up by using the 'YF filename' command. I often use 'YF 20m.fwd' to change from VHF-only forwarding to HF and VHF forwarding. The HF forwarding is here as an example ONLY. It won't work on the air for you unless KC0TA has entered you in his user file as a BBS. Note that the 20m.fwd file refers to several other files, and these sometimes refer onwards to yet others. The reason for this is to keep the forwarding info easy to manage (really!). Also, the file ve5op.via contains an example of passing traffic by connecting to an intermediate KA-NODE. Near the end of this file I have added a couple of examples of how to work out what should be in a forwarding file. ** When the program starts up it looks for the file 'tnc.on' which need not exist but if it doesn't your TNC had better be configured properly. You MUST edit this file to make it conform to your configuration or delete it if necessary. The tnc.on file can contain comment lines (lines beginning with #) which are ignored, and CLI commands (lines beginning with !). All other lines are assumed to be commands to the TNC and are sent out the serial port. The tnc.on file contained on this disk contains a lot of comments about what it can do. Some commands that could be in here are those to force on hardware handshaking and any other TNC parameters useful to the BBS. Even if you only use the TNC with the BBS (and therefore you never change the parameters) it can help to have them 'softwired' into this file 'just in case'. You could, for example, put EVERY command your TNC understands in here so that if the TNC ever gets scrambled, just restarting the BBS will restore it's sanity. I have commented out those commands specific to the KAM. If you have a KAM, edit them back in by removing the comment symbol at the beginning of each TNC command line. For TAPR upgraded TNC1s you MUST have the two commands: newmode off nomode off in the tnc.on file because this is the ONLY combination of these two commands that will work properly. This is not exactly what the BBS needs but is as close as the TNC can get. It works fine for the BBS. The only place it might cause you problems is if you use the 'TA' command and connect to a station. On the disconnect the TNC stays in convers mode so you MUST remember to type '^C' (CTRL-C) to force the TNC back into command mode before you type '^E' to get back to the SYSOP prompt. In the KAM these commands are set to: newmode on nomode off For other TNCs these commands should be set to whatever will cause the TNC to return to command mode on a disconnect and to go to convers mode when a connection has been established. If your TNC won't do this then it is almost certain that the BBS won't work properly. ** For TAPR TNC1s and upgrades it is best to be sure of forcing the TNC into hardware handshake mode by specifying all of the following commands in the tnc.on file: start 0 stop 0 trflow off txflow off ** When you terminate CBBS, the last thing it does just before it closes the serial port and the window is to send the content of the file 'tnc.off' to the TNC if the file exists. The structure of this file is the same as for tnc.on and may also contain comments, CLI commands and/or TNC commands. You MUST edit this file to make it conform to your configuration or delete it if you don't want anything done at shutdown. If, for example, you have set up the bbs to keep user.dat and mail.dat in ram:, then this file should contain the commands necessary to write them back to disk before the program exits. You can also add TNC commands such as the 'btext' command with a text saying that the BBS is off the air. ** The AMIGA has only one serial port (or at least my A-1000 does) and so the gateway commands have been removed from the program. They are only useful if you have multiple serial ports, each with a TNC. If you have a KAM, it'll gateway for you anyway! ** The A, AH, AI and user C commands have all been removed from the amiga version. ** The 'J' commands have been modified to print out the date that each call was seen as well as the time. ** I have made a change to the way that this BBS handles bulletins which is NOT in the standard CBBS. In order for this BBS to ACCEPT a bulletin from another system there MUST first exist a file in the msgs directory (Note that the name 'msgs' is specified in the config.mb file and can be changed if you wish). If for example you want to receive ALLUS bulletins then there MUST be an ALLUS.dis file in the msgs directory. If no such file exists then the program doesn't even check the BID, it just says "NO - Don't want it". This can save you from being inundated with bulletins you don't want from another BBS. This has happened to me, and with my limited disk space it doesn't take too many ALLUS bulletins before all my disk space is gone! The content of the .dis file is a list of the callsigns (one per line) of those systems that you will forward that type of bulletin to. It does not have to contain the name of the system you receive the bulletin from. If you only receive bulletins and don't forward them, just put the name 'hold' in the file, as is shown in the example .dis files on this disk. ** Another change I have made is that if there are messages to ALL on your BBS and they are addressed TO your BBS (i.e. either the @BBS field is empty or it contains the callsign of your BBS), the beacon does not just say ALL as most other systems do. It also includes the highest message number addressed to ALL, e.g. ALL(489) to show that the highest message for all is numbered 489. This allows users to see when a new message to ALL has arrived at the BBS without them having to log in, they just monitor the beacon. ** There is also a change to the way the BBS handles mail. If the BBS receives mail addressed to someone who is in the USER.DAT file then the BBS OVERRIDES the @BBS field in the message with the @BBS field from the user file. This will occur whether the message is one you typed in yourself or from a logged in user, or even in mail forwarded from another system. The assumption here is that if the user is in your user list then the @BBS field is more likely to be correct than any mail from outside. If the mail is addressed to a user who is not in the user file then the @BBS is not changed. ** There are a few messages already in this BBS as distributed. They are a few AMSAT bulletins which will be out of date by the time you get this disk. You can delete them when the BBS first starts up. Do a 'll 10' command first to list them and then use the 'K' command to kill them e.g. K 1 will kill message number 1 and so on. Then do a 'GM' command to clean out the files. You must periodically execute the 'GM' command anyway to clean out old files. This can be done automatically or manually as described in the manual. It cleans up the space used by the mail files and deletes old ones. In CBBS V6 a new feature has been added such that deleted files can, if you wish, be archived instead of being deleted. If, for example, you want to archive AMSAT bulletins, then you must create a directory called AMSAT immediately under the CBBS directory. Then instead of deleting amsat bulletins when they get old, the program will store them in the amsat directory. NOTE, I think it is dangerous to have a bulletin board directory name the same as a bulletin name. For example, if you store files about satellites in a directory called AMSAT, then the 'GM' command will archive AMSAT bulletins in there as well. I have not had much experience with V6.1 yet but I suspect that this would be a bad thing because the structure of a mail file is NOT plain text. It has a header containing arbitrary binary rubbish in it and if a user tries to download it strange things may happen. So, when you pick names for the bulletin board directories, DON'T make them the same as the names that occur in the @BBS field of incoming bulletins. ** This distributed version also has a few BBS file areas. You can add more or remove some as you wish. But remember to create corresponding directories for the new ones. The reason I have a specific 'upload' directory that is write-only and all others are read-only is that a user might upload a file containing arbitrary binary characters and then download this same file to themselves. It is possible that the bad characters in the file will mangle your TNC. Alternatively, a user might upload a file that contains obscenity or is commercial in nature and you would not want to be held responsible for distributing it any further. So to avoid this, users can upload a file into the specific area and then send you mail telling you that it is there. You can then move the file to its intended area after you are sure it is safe to do so. Thus, users can't write into the normal file areas and can't read from the upload area. ** The content of the file 'files/info.mb' is sent to any user who issues the 'I' command. It currently has two lines in it briefly describing that this is the CBBS program. If you want to, you can edit the file and add to it your name, qth and the type of TNC, Rig etc. that you are using. ** The ! SYSOP command that allows you to execute CLI commands works except that the output of a CLI command goes to the window in which the CBBS was started, NOT to the CBBS window itself. This is annoying but I can't find a way around it yet. On the other hand, this is a multitasking machine and you can always have a separate CLI window open to execute CLI commands anyway. So I'm not gonna bust a gut to sort it out. ** In my version of CBBS the remote sysop password does NOT work as described in manual.bbs. I felt that the password mechanism used there is very weak and it wouldn't take a determined snooper very long to be able to break into your system remotely if remote sysops use it very often (NOTE that in order for someone to successfully be a remote sysop, you must first set that privilege for them in the user file AND set the 'R' privilege for port 'A' in the config.mb file AND set up a proper password as described below). Instead of using a line containing 64 characters, the password scheme now uses a line (or lines) containing up to 64 positive non-zero numbers. If a remote user tries to get in, the system still sends them four numbers as a challenge but instead of sending the corresponding letters of the password, the remote sysop must send the SUM of the corresponding NUMBERS. Since you can't easily fit 64 numbers on a line, you can put the numbers on several lines with all but the last line terminated with a backslash character. For example: 17 42 93 81 90 3 27 82 103 35 72 64 13\ 76 7 25\ 23 47 56 62 18 11 95 79 126 Using this example password, if a user tries to be a remote sysop and receives the challenge 10 21 7 16 then they must answer with 105 (the sum of the 10th, 21st, 7th, and 16th numbers in the list). There MUST be at least 20 numbers and no more than 64 in the list AND they must all be positive and non-zero or the remote sysop function will be disabled. Thus, if you don't want to permit the remote sysop function at all just put a single zero on this line. The numbers should all be different and in random order to strengthen the password scheme. ***###*** OK .. Let's try it ***###*** You MUST first be connected to the directory that contains the mb program and the config.mb file, which on this disk is the 'cbbs' directory. This is because the config.mb file in this distributed version has all the directories specified as being relative to the 'cbbs' directory. You can change this as you see fit. Then execute a command of the form: mb [-bN] [-t] [[config-file] debug] The default baudrate between the TNC and AMIGA is 9600 baud. If you use any other speed then you MUST specify the -bN switch to tell the program what baudrate to use .. e.g. -b1200 (NOTE that there's no space between the b and the number!) The '-t' option (which can be specified before or after the '-bN' if it is also present) specifies that the BBS software must strip off the high order bit of every character received from the TNC. This allows the BBS to be used with TNCs that set the parity bit to a one when in 'no parity' mode, such as the TNC1 with the TAPR upgrade to TNC2 V1.1.5. The program can be told to use a different config file than the default name of config.mb by specifying the name as the config-file argument. If another argument is specified after the config-file name (e.g. debug ... but the program doesn't really care what it is as long as it is there) it turns on debugging. This won't be much use to you unless you have read the source code. It takes a few seconds of disk churning to load the program but then the first thing that should happen is that it opens a new window for the BBS and the title should appear. It then prints a line containing the words Window and Port .. ignore this. Now it tries to send three commands to the TNC: 'm off', 'cono off' and 'echo off'. If you have forgotten to connect the TNC to the amiga serial port or have set it to the wrong baud rate or wrong parity, then after about 30 seconds the program will timeout and exit because it can't get a reasonable response from the TNC. Connect it up properly and start again. It then sends out 'TXD' and looks for the 'TXD' reply from the TNC. The program then sends a PASS command to the TNC to find out what the pass character is. If it finds one it also sends a STREAMSW command to the TNC to find out what the stream switch character(s) is(are). On the KAM there are two, one for VHF and one for HF. The program then prints the results of what it found. If you have included CLI commands at the front of the tnc.on file then the process may pause a bit here. Then the program should show some data from the TNC as it dumps the tnc.on file into the TNC. It then prints out how many calls are in the calls.mb file (initially zero) and don't worry when it reports that the file is full. It then should print a line saying how many users are in the USERS file. First time through it should say zero AND you had better have set your call in config.mb already because the program automatically adds you to the user file as a sysop (of course). It then prints out how much free chip and fast memory it can find and it always says it will use 16K. It then prints: BT mail for: and after a couple more lines it should just go quiet. It is now waiting for someone to call into it on the TNC or for you to wake it up as SYSOP from the keyboard. As SYSOP you type a Control-E character (default in config.mb and can be changed) at which point it should send the commands 'm off' and 'conok off' to the TNC. It then grinds the disk a second or so and then it should print the sysop prompt which the distributed config.mb file has set to 'SYSOP>' (you can change it). From there on you can issue the commands described in manual.bbs. As an example, just type the command DU at the prompt. It should display just your callsign first time through because you are the only user it has seen so far. A useful exercise at this point is to use the 'EU' command to edit your entry to add your name. As users log in and give the BBS their name and zipcode, the file will begin to grow. You can add new users yourself if you wish by using the EU command with their callsign. E.g. to add me: eu ve5va and then set the other parameters (such as name, zipcode etc.) as shown in the manual. Another command to try is: LL 10 which asks the BBS to list the 10 most recent messages in the mail file. One thing you must keep an eye on, especially if you are only using floppy disks, is that if you have allowed logging of events (in config.mb) the log file, log.mb, will grow without bound as the BBS is used. So you must occasionally delete this file. If you are required by law to keep a record, print the file out or archive it on another disk and then delete it from the bbs disk. Try out the 'PRTLOG' program which prints a summary of the file. To exit from sysop mode just type the 'B' command. It will then wait for a user to call in. The safest way to terminate the program is by clicking the close program gadget in the window title bar or use the Q command on the keyboard. This is so that the program will update the user and possibly the mail files properly. Just removing the disks might leave them in an indeterminate state whether or not you have stored them in ram:. Also, if you have CLI commands in the tnc.off file to do some tidying up, the only way they can be executed is to quit properly. Here are a few pointers, based on experience. ** If the BBS opens the window but then closes it and generates the "Timeout - .." message it can be for one of the three reasons listed or others I haven't though of or run into yet. Make sure that the TNC is plugged into the serial port. Also make sure that the cable is wired up properly. If neither of those help then try running the BBS with "run mb -t" to tell it to ignore parity. ** If you call another BBS but it won't accept mail from you, or it won't send you the [BBS-TYPE-CODES$] message, then you must log into that BBS as a normal user and send mail to the SYSOP asking him/her to set you up as a BBS in his/her user file. It also helps to have them also set you up as an expert user (although you can do that yourself) because this usually reduces the size of the login message. ** If you want to send bulletins, you and your users must use the 'SB' command. If they use an 'S' command such as 'S ALL @ AMSAT' then it generates Private mail, NOT a bulletin. So no matter how your bulletin distribution files are set up, it won't forward them. If you already have some mail like this on your system then you can change it from type 'P' or ' ' to type 'B' by using the 'E msg#' command and changing the message tYpe. (i.e. type the command 'y b' when you are in the 'E' command). ** If your BBS still won't forward bulletins make sure that you have a proper .dis file for the bulletin in the msgs directory. ** If your BBS won't accept bulletins from another BBS (i.e. your BBS says 'No - Don't want it') then you do not have a proper .dis file. There must be a .dis file for that bulletin type even if you don't forward the bulletins to anyone else. ** If your BBS won't forward mail for a user then either they are not listed in your forwarding file for their BBS or their user record does not specify the correct Home bbs. Some Forwarding Examples The best way to work out a forwarding file is to log in manually to the system that you are trying to forward to and record everything that occurs. Then work out the forward file from that. First, a simple example. I wish to forward to VE5OP who is here in Saskatoon. If I connect to VE5OP manually I see this (with my comments added on the right): c ve5op [ I type this command cmd:*** CONNECTED to VE5OP [ and the TNC says I'm connected [CBBS-6.0-H$] [ Here's the BBS login message EU> [ from VE5OP and its prompt. Now let's add the corresponding forwarding commands on the right hand side. c ve5op [ CC VE5OP cmd:*** CONNECTED to VE5OP [ [ The 'CC' command not only sends the first connect message, but it also looks for the '*** CONNECTED' message from the TNC. So you must NOT use the 'R' command to read the '*** CONN' message. Remember that once you get to the [BBS-TYPE-CODES$] message you are in to the BBS and now you just use an 'F', 'H' or whatever list and you simply add in the list of calls whose mail is forwarded to VE5OP. So the complete script could look like this: CC VE5OP HA0023C VE5OP ve5op [ you can put lots more calls in ve5pf [ here as well as ntssk [ nts codes 97* [ or wildcards *** EOF KAM users should remember to add the streamswitch characters into the initial connect command (e.g. 'C|aC ve5op' for VHF). If I had to go through the VE5USR digipeater to get to VE5OP, the only change in the script would be: CC ve5op via ve5usr because the digipeater would not generate any more text during the connection. A more complex example is if I want to connect to the VE5AGA BBS in Regina, which is 165 miles from Saskatoon. I have to go through two KA-NODES (VE5BAR and VE5ABO) and one digipeater (VE5GF) to get to VE5AGA. The path is in this order: VE5VA <-> VE5BAR-3 <-> VE5ABO-3 <-> VE5GF <-> VE5AGA bbs ka-node ka-node digi bbs Here's what I would see if I logged in manually with my comments on the right hand side: cmd:c ve5bar-3 [ I send the connect cmd:*** CONNECTED to VE5BAR-3 [ and my TNC responds. ###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A [ Now KA-NODE responds WELCOME TO SASKATOON...VE5OP LOCAL BBS... [ with its own messages ENTER COMMAND: B,C,J,N,X, or Help [ until it prints the ?c ve5abo-3 [ prompt without a CR. ###LINK MADE [ Connected to ABO ###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A [ and ABO now prints Welcome to the Ituna Node [ its own messages ENTER COMMAND: B,C,J,N, or Help [ up to the prompt ?c ve5aga v ve5gf [ now connect via digi ###LINK MADE [ The KA-NODE says OK [MBL-5.12-C$] [ Now the BBS responds Welcome to the Regina BBS [ with all its own de Perry VE5AGA [ login messages [ which can be anything for latest information 'D INFO.TXT' [ up to the prompt VE5AGA> [ with the '>' And here's the script with the corresponding forwarding commands. cmd:c ve5bar-3 [ CC VE5BAR-3 cmd:*** CONNECTED to VE5BAR-3 ###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A [ R###CONN WELCOME TO SASKATOON...VE5OP LOCAL BBS... [ R! ENTER COMMAND: B,C,J,N,X, or Help [ R! ?c ve5abo-3 [ SC VE5ABO-3 ###LINK MADE [ R###LINK ###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A [ R###CONN Welcome to the Ituna Node [ R! ENTER COMMAND: B,C,J,N, or Help [ R! ?c ve5aga v ve5gf [ SC VE5AGA VIA VE5GF ###LINK MADE [ R###LINK [MBL-5.12-C$] [ HA0023C VE5AGA Welcome to the Regina BBS de Perry VE5AGA for latest information 'D INFO.TXT' VE5AGA> Note that the '?' prompt from the KA-NODEs does not have a carriage return after it and so there is just a corresponding 'S' command here. The 'R' command must not be used here because it is looking for a line ending with a carriage return and the BBS will just hang and eventually timeout here if you use 'R'. IF the KA-NODE sent a prompt with a carriage return after it (i.e. '?' instead of just '?') then you would need a 'R' command to read the '?' and then an 'S' command to send the next command to the KA-NODE. You can easily tell the difference because if there's no then you will see: ?c ve5abo-3 [ only requires SC ve5abo-3 such that both the prompt and your next command are on the same line, whereas if there were also a CR there you would see: ? [ would require R! (or R?) c ve5abo-3 [ SC ve5abo-3 When you use the 'R' command you can specify some context expected on the line such as the 'R###LINK' I have used here. It is useful to do this rather than 'R!' for the 'LINK' or 'CONNECTED' messages because if the link fails then the ka-node will send a message such as '###RETRIED OUT AT NODE VE5ABO-3'. This does not match the specified '###LINK' and so the 'R' command will fail and your BBS will disconnect the forward attempt. If you had specified 'R!' instead of 'R###LINK' then 'R!' will also accept '###RETRIED OUT' and then your script will hang until the process times out. However, you don't need to specify a context for all the lines so that some of them are just read with 'R!'. The 'R' command will search for its given string anywhere on the line so that you could check for '###LINK MADE' by specifying 'RMADE' as well as 'R###LINK' or even 'R###LINK MADE'. Just how much context you give is up to you as long as it is sufficient to correctly distinguish the line from any other expected response. Note also that VE5AGA has a much longer login message than does VE5OP, but that doesn't matter. Once your BBS sees [BBS-TYPE-CODES$] it will look for the prompt with the '>' symbol in it and then start forwarding. If the VE5GF digipeater were between the ka-nodes rather than at the end, then the script would not be any more difficult. For example, if the order of the connections were: VE5VA <-> VE5BAR-3 <-> VE5GF <-> VE5ABO-3 <-> VE5AGA bbs ka-node digi ka-node bbs The connection process would then be: c ve5bar-3 c ve5abo-3 via ve5gf c ve5aga so the basic script would look like this (with some of the extraneous stuff removed): CC ve5bar-3 R###LINK etc. SC ve5abo-3 via ve5gf R###LINK etc SC ve5aga R###LINK HA0023..... etc. This procedure for working out a script can also be used for working through NET/ROM nodes and other types of networking or gatewaying nodes. The BBS commands The BBS commands (as opposed to commands used for storing and forwarding mail) are fairly easy to use. The primary use of these commands is to store information of local interest that you would not want to mail to everyone. Rather, you can store the information in a file area and let users read the information if they are interested. For example, on this BBS I have put a file area for QRP related information. Other file areas could be for AMSAT information, and another for a swap'n shop file. If someone is interested in QRP stuff but not in AMSAT info then they can look through the QRP area and not have to read a lot of mail or bulletins that don't interest them. I'm going to use my local BBS VE5OP as an example here to show how the commands work. The first command to give to the BBS is the 'w' command which asks what are the major areas in the BBS. If I type 'w' on the VE5OP BBS I receive this info: Use W and directory ID: WA --> Amsat / Oscar WB --> General information WC ---> ARRL/ Newsletters WD --> Hamfests and Related EVENTS WE --> Packet Meetings-Minutes,ect. WF --> Packet LISTS WG --> Swap 'n Shop WH --> Local Users - Equipment WI --> NEW Uploads To Here Please If I want to see what is in the 'General information' area then I type the 'WB' command as shown beside the name of the area. The 'WB' command will print out: AA4RE 4k | Q.BAS 3k | README.R95 16k CONFIG.MB 4k | README.DOC 12k | WOOD1.INF 2k 41k of 31834k used, 27348k free. Now let's look at the AMSAT area by typing the 'WA' command: AO-13.SKD 2k | MIR.QSL 1k | O13.OCT 3k MIR.BCN 1k | MIR89.FEB 4k | O13.SEP 5k MIR.MAR 8k | MISC.021 2k | WEATHER.021 5k MIR.OPR 4k | O13-1.OCT 4k | WOOD1.INF 2k 41k of 31834k used, 27348k free. And also let's see what's in the swap'n shop area with the 'WG' command: 890416.SWP 7k | SWAP04.DEC 7k | SWAP20.FEB 7k 890523.SWP 7k | SWAP12.MAR 8k | SWAP29.JAN 6k SWAP0122.89 6k | SWAP2.NOV 8k | VE5BBL.SEL 1k 57k of 31834k used, 27348k free. Now, I decide that I want to look at what is in the file mir.qsl in the amsat area. To do this I must Download the file and tell the BBS which area it is in ('a') and it's name. So I type the command: da mir.qsl and receive the following info: ARRL BULLETIN 140 ARLB140 MIR SPACE STATION COSMONAUTS U1MIR AND U2MIR ARE NOW REPORTED TO BE OPERATING ON 145.400 MHZ. QSL CARDS SHOULD BE SENT VIA USSR, MOSCOW, 107207, P.O. BOX 679, B. STEPANOV. WA2ILB @ NN2Z> In this case the file contains an ARRL bulletin but it could be anything. If a user wants to send a file to the BBS then the file must be Uploaded into the 'I' area and a filename must be specified for it. For example: ui qrp.info The BBS will respond by telling the user to upload the file and then terminate it either with '^Z' or with '/ex'. The user should also send mail to the SYSOP to tell them that the file has been uploaded and what is in it. The 'W' commands can also by used by the sysop so you can try them on the distribution disk. But the SYSOP cannot use the upload and download commands. They mean something different when the SYSOP uses them. Good Luck. If you have problems getting CBBS to work either because my instructions aren't clear or I've left out something important, please let me know. If you want help or have questions I'll be glad to help IF I can but you must take note of two things. - I will not answer mailed queries unless you also send me a proper SASE. U.S. hams PLEASE note that putting a U.S. stamp on your envelope won't do me any good. Canada Post expects me to use Canadian stamps. However, I will take a LOOSE U.S. stamp (30 cents) in exchange (NO IRCs please - I have plenty right now). If you send me a disk and expect it back, that will require correspondingly more stamps or a money order. - I have been ill since Sept 1984 with Chronic Fatigue Syndrome (Myalgic Encephalomyelitis to you Brits ... I'm one myself) and am always tired. I put this BBS together over many months (it took me six months to find a simple bug in my amiga code!) . So if I'm having a bad spell I may not get around to answering for a while. Be patient. Just to save you sending "I wish that ..." letters, here are a few things I'd like to do for the next release if I get the time. ** Allow the sysop to specify TNC type in the config.mb port description. Mainly so a sysop can specify that a KAM is being used but also useful for other quirky TNCs as well. ** perhaps add code to take mail out of your TNC if it has a mailbox in it. When my CBBS is down, people sometimes leave mail for me or others in my KAM mailbox and if I don't explicitly look for it and manually forward it into CBBS, it's stuck there forever. This is why there's a 'PBL' command in my tnc.on file, to remind me if there's stuff there. But it doesn't actually transfer the mail into CBBS. For your info, a KAM mailbox can accept mail FROM a CBBS (I believe that some other TNCs can too). It accepts mail just like a regular BBS. But a KAM can't SEND mail to a CBBS. So if you have 'clients' out there who use a KAM, you can set up a forward file which automatically sends their mail into their KAM. The only thing that you can't control is the amount of mail. If it overruns the available ram in the KAM (or other TNC) then they could lose some of their mail. Let them decide if they want to risk it. ** add some menus? Don't count on it. ** Allow sysop to choose which of my non-standard modifications should be active. Pete Hardie VE5VA 338 113th St. SASKATOON SASK S7N 2L2 CANADA or packet @KC0TA, @VE3IWJ or @VE2ED (all on 14.107 Mhz) or BITNET hardie@dvinci.usask.ca