Fish 'n' More 2

home *** CD-ROM | disk | FTP | other *** search

/ Fish 'n' More 2 / fishmore-publicdomainlibraryvol.ii1991xetec.iso / dirs / cbbs_415.lzh / CBBS / CBBS.lzh / docs / manual.bbs < prev next >

Wrap

File List | 1990-11-19 | 152KB | 3,564 lines

*************************** *** THE C-BBS MAILBOX *** *** Version 6.7 *** *************************** 1. Getting Started, What to look for 2. The Configuration File 2.1 Bulletins 3. The Forward File 3.1 Hierarchical forwarding 3.2 Using STATES.EXE 4. Commands (user and sysop) 5. Prtlog, Printer, and Files used 6. Log, List, and Distributation Files 7. Protocols (bid's, zip's, sid's, sending) 8. Desqview operation 9. Modem usage 10. Restoring mail file, Mail format, Hold and Listing messages 11. Archiving messages 12. Sysop Maintenance Appendix A. Changes.mb Appendix B. Config.mb (c) 1988, 1989, 1990, CBBS Group INTRODUCTION AND PURPOSE This is the documentation for the C-BBS Mailbox system. It is based on code originally written by Hank Oredson. It is being continued by a small group of packet programmers so that sysops will have the source code available. The purpose is simply to allow sysops to use, learn, and understand the "C" programming language and it's use in running the C-BBS Mailbox system. This way the code can be customized to suit sysop needs. Also, as bugs are found, it allows the sysop to search the source code for the necessary corrections. The use of any module or section of code for any distribution beyond the C-BBS mailbox is prohibited. All the modules are copyrighted by the CBBS GROUP. It may be copied for non-commerical use as long as all copyright notices are included. Be forewarned that only the RELEASE versions of this software will be supported. Bug reports and enhancements are appreciated. This is a group effort and as such, more time is available for comments. Chapter 1 ------------------ GETTING STARTED ------------------------- Page 1 ************************************************************ *** C-BBS MailBox and GateWay Version 6.7 - 9/20/90 *** ************************************************************ A: [CBBS-6.71-H$] This code was initially created for packet community by: Hank Oredson, W0RLI Hank, however, no longer supports the CBBS code. He is allowing it to be developed by others interested in furthering this version. He is developing a new code that is not associated with this CBBS program. Dave, VE3GYQ had released version 4.4 of this code and K3RLI and AG3F have released versions 4.6 and beyond. This is the latest version. You may obtain versions of the code in several ways. 1. Download from Compuserve HamNet or 2. Send a diskette mailer to Edward T. Picchetti, K3RLI 355 Ridge Road Wilkes-Barre, Pa. 18702 A special thanks to those who send little chunks of code with bug fixes or new features. WA3TSW, VE5VA Thanks also to VE3GYQ for the GateWay code, AA4RE and WA7MBL for the IBM port drivers. The code will run under DOS for for single user application or under DESQview for multiple user applications. DoubleDos is no longer supported for multiple user setups. Under DESQview 103k window size is required unless the bbs dos command feature is desired then 150k window size is necessary. A 640k pc/xt will support 3 windows without the dos command feature. This version of the code represents a significant change from previous issues. The method of handling the mailfile and individual message files is all new and the communication between copies of the BBS is now done without the need for the "pipe". These changes result in the ability to reconstruct the mailfile from the individual messages thus providing security from crashes and failures. The use of mailfiles and user files common to all copies provides many conveniences. Please read the following documentation to get things set up properly. This code will not run using previously successful file and directories. Appendix A will give more detail as to the revisions from previous versions of the code. Chapter 1 ---------------- GETTING STARTED --------------------------- Page 2 B: CODE DISTRIBUTION The code as distributed is broken down into sections so that you can select the areas that you need for your requirements. For normal operation of the bbs the modules RUNxx.ZIP and IOxx.ZIP are all that are necessary. The other modules provide the source code for those interested in making their own modifications to the code. All modules, both run and source, are provided in ZIP format and must be uncompressed by use of PKUNZIP. C: WORKING WITH THE SOURCE CODE It is expected the those using the provided sources are familiar with "C" language, 8088 assembler notation and the manuipulating of compilers, assemblers and linker. All developement work has been done with the Microsoft C compiler version 4.10. Some Microsoft specific library functions are used, these functions should exist with any C compiler. The names, arguments, and required header files for these functions might be different with other compilers. All of these differences should appear in the module MBIBM.C. The Microsoft C compiler version 5.01 has also been used successfully but the distributed code was produced with version 4.10. Turbo C and Quick C have also been used by others with good success after some syntax modification. File MB.BLD has been provided to utilize the Microsoft MAKE.EXE file maintance utility to compile, assemble and link the various modules that make up the bbs code. It is recommended that this be utilize but CC.BAT has also been supplied to permit compiling of a single module and LINK.MB is provided to work with LINK.EXE to form the entire linked package. Microsoft MASM versions 4.0 and higher have been utilized to assemble the I/O and other modules that require it. D: USING THE RUN CODE The following steps will be required to get the bbs operating using the provided run code. Please notice that you have many options for configuring the hardware and software. The examples shown are only illustrative and are not the only way to do this. 1: Extract the files from the ZIP files if this has not already been done. This is accomplished by using the command PKUNZIP RUN65 for the run files and PKUNZIP IO51 for the I/O routines. This will produce numerous files from which you will select only a few depending upon your desired system configuration. 2: Decide how your system will be configured. How many tncs will you have? Will the tncs be arranged so that each can be connected to independantly of the others or when one is in use will the others be unavailable for a connect or is a combination of both methods desired? As an example we can have 3 tncs, A, B, and C. If we decide that only one tnc at a time is to be connected, then we can configure to run under DOS without multi- tasking enviornment. If we would prefer all tncs to operate independantly then we must configure for DESQview and provide 3 windows, one for each tnc. Chapter 1 ---------------- GETTING STARTED --------------------------- Page 3 We can also decide to have tnc A be independant and B and C work as a pair. This arangement requires 2 DESQview windows with tnc A operating from one and tncs B and C operating out of the other. This setup will permit connects on tnc A and either B or C simultaneously. Many other combinations are possible depending upon the number of tncs, serial ports and system memory. In any case, decide upon this arangement now. 3: Setup a directory structure based upon your system configuration. This is discussed in more detail in another section but essentially you must have the following files included: mb.exe bios.com based upon the number of tncs(eg. br3bios.com for 3 ports) mbmode.exe hand.com share.exe ** config.mb for each window (eg. config.a, config.b, etc) mail.dat & user.dat (Converted files from older version) fwd.mb states.mb info.mb and help.mb mon.mb for each window (Created by the mailbox) log.mb for each window (Created by the mailbox) calls.mb for each window (Created by the mailbox) A typical setup for the example above would be the following directories and their files: \mb \mb\bbs \mb\msgs mb.exe mail.dat mbmode.exe user.dat all br3bios.com info.mb message config.a help.mb text config.bc fwd.mb files hand.com mon.a share.exe mon.bc mbrestm.exe calls.a calls.bc log.a log.bc states.mb ** share.exe is on your dos distribution disk for dos 3.0+ 4: Prepare the configuration or configurations based upon the desired system setup. Detail of how to do this follows in another section but make sure the file specification section of the configurations follows the directory structure decided upon above and the port section also follows the system setup. 5: Setup the directory structure and copy the proper files to these locations. If you are a new user only the files in the \mb directory and info.mb and help.mb in \mb\bbs will be required. The bbs program will create the necessary other files. For those of you with operating older versions of the code, the mail, user, fwd, log, msg, etc files should be copied to the proper directory and renamed if necessary. Even if there are no message files, as in the case of a new user, make sure the \mb\msgs directory has been created. Chapter 1 ----------------- GETTING STARTED -------------------------- Page 4 6: Prepare a suitable batch file to initialze the serial port(s) and bring up the bbs. A single window operation for 3 tncs: TIMER -> Your time and date program. CONFIG.SYS BR3BIOS FILES = 20 MBMODE COM1:4800,N,8,1 BUFFERS = 20 MBMODE COM2:4800,N,8,1 MBMODE COM3:4800,N,8,1 CD \MB MB An example of this file when used with Desqview (Multi-windows): DATETIME -> Your time and date program. CONFIG.SYS BR3BIOS FILES=30 MBMODE COM1:4800,N,8,1 BUFFERS=20 MBMODE COM2:4800,N,8,1 STACKS=9,128 MBMODE COM3:4800,N,8,1 HAND SHARE /F:2048 /L:64 CD \DV DV These batch files can exist independantly and be called by AUTOEXEC.BAT or can be made part of AUTOEXEC.BAT. In either case the bbs will reboot upon power outages. If this is not desired keep this batch file independant of AUTOEXEC.BAT. The cable between the tnc and computer should have pins 2,3,4,5, 6,7,8, and 20 connected. Hardware flow control is used in both directions. Configure the TNC's using the appropriate .SET file, TNC1.SET for a tnc1, TNC2.SET for a tnc2, PK232.SET for a pk232. The parameters differ depending on the type of tnc you are using. 8: If you are not using DESQview and are using only a single window disregard the rest of this section. Add a copy of the mb program for each window used. This is done with the AP selection from the open window menu. Enter the path, program name and parameters, plus set correctly all of the options on both normal and advanced options. See the section on use of DESQview for those details. In addition in the advanced menu set the window heigth, width, row and column to place the bbs copy in the desired place on the screen. For a 1 or 2 window system the defaults are ok (split screen) but for more than 2 copies consideration must be given to this. For the 2 window 3 tnc example of above the main AP entries are: window 1 Program name <A--145.01> Key M1 Memory size 150 Program MB Parameters config.a Directory C:\MB window 2 Program name <BC--145.07, 221.11> Key M2 Memory size 150 Program MB Parameters config.bc Directory C:\MB Chapter 1 ----------------- GETTING STARTED -------------------------- Page 5 Prepare the DESQview startup script file and place it in the \DV directory. This file is desqview.dvs and should contain the proper scripts to open the number of windows used by the configuration. The section describing the use of DESQview covers this technique. In our example above for the 2 windows the script should open M1 pause 30 and then open M2 before finishing. 10: Convert the mailfile and message files if you have an older version running. If you are a 1st time user this section can be bypasssed. This represents the most significant change from version 4.6 of the code and should be followed carefully. If you are now running a version prior to 4.0 you must convert your existing message and user files to version 4 format. First, backup all files in the directory used by the MailBox. In case something goes wrong, you will be able to restore everything to where it was without loss of messages. The conversion from earlier versions to version 4 is done by MBCONV. Set the default directory to the directory containing the MAIL.DAT and USER.DAT files. Then run MBCONV. If you are running a version prior to 3.0 you must first make certain that the message text has been moved to individual files. Do this by executing the GF command. ** FOR VER 4.6 **** and prior converted versions do the following: From the operating bbs DO a GM and then quit the board. Now the final conversion to the new format can be performed. This version of the CBBS code requires that the individual message files be converted to a new format. The program MBCONVM.EXE is provided to do this conversion. The program expects the mailfile, MAIL.DAT to exist in directory \mb\bbs and that the individual message files be in directory \mb\msgs. Copy MBCONVM.EXE into the \mb\msgs directory and then invoke the program by typing MBCONVM <return>. This program will read the MAIL.DAT file and the corresponding message files and produce a converted MAIL.DAT as well as converted message files. When completed the new MAIL.DAT will reside in \mb\bbs directory and the modified message files in \mb\msgs as was the case previously. If MAIL.DAT wasn't found in \mb\bbs the program will ask for the directory containing MAIL.DAT. You can then enter the proper directory name. The program will procede with the conversion if it does find MAIL.DAT. If it does not it will abort the conversion and report that it could not find the file. You should check the directory setup and the location of MAIL.DAT and then start the conversion again using the invocation MBCONVM \xx\sss where \xx\sss is the actual directory location of MAIL.DAT. If the mail file had already been converted the program will abort the conversion and report accordingly. 11: All should be ready now. Either reboot the computer if the startup batch file is associated with autoexec.bat or type the name of the batch file. Chapter 1 ---------------- WHAT TO LOOK FOR -------------------------- Page 6 (BBS LOADING) When you load the bbs program your screen should look something like this: TNC commands on TNC commands off <A> Window 1 portflag 1 <- same C aAbB for two ports Link state is DISCONNECTED cmd: <C> XX calls in \mb\bbs\CALLS.MB <- same <D> XX users in \mb\bbs\USER.DAT <- same <E> [MM] XXXXX free space, XXXXX used. <- same <F> Set for DESQview. <G> m on <G> MONITOR was off ABABAB <G> cmd:cono on <G> CONOK was off <G> cmd: <A> This line is used by the handshaking program to detect ports active, and total ports used by the bbs. If you are using a single bbs, it is not necessary. This takes a tnc state, and insures the tnc is disconnected. A line appears for each port used by the bbs. <C> This line indicates the number of calls in the CALLS.MB file up to the max listed in the config. When you hit the maximum it will also say (file is full). <D> This line indicates the number of users in USER.DAT <E> Tells the amount of free space of memory, and the amount to be used by the mailbox. If you are using DESQview, you might want to adjust the window size to not waste memory space. <F> Only shows up if you are set for DESQview in the config.mb If this line shows up and you are not using DESQview, change the DESQview line in the config to OFF. <G> Shows the monitor and conok being turned on to allow monitor- ing and connects for each port used by the bbs. NOTES: <G> If you have the port configuration line in the config.mb set with a '3' ( don't monitor tnc commands ) in it, these lines will only show as a lower or upper case letter. If you hang at this point, your tnc is not setup right, or your cable is not connected properly. You need at least, ECHO OFF, MONITOR OFF, AUTOLF OFF, AWLEN 8,and PARITY 0 set into the tnc. <E> If you display "Too little memory available." You need more memory. Add in 4k increments to window. [MM] = log month. At this point the bbs is active, and ready for connects or monitoring the frequency. You can now hit a ^E (control E) and log onto the bbs. the bbs will turn off the monitor and turn off conok in the tnc and show you the sysop prompt. 880711/0350, 1011, 100 msgs> You are now ready to enter any commands. The prompt line shows you the DATE/TIME, the highest message number, and the number of messages on the bbs if you use the one in the sample config. Chapter 2 ---------------- CONFIGURATION FILE ------------------------ Page 1 ******************************** *** The Configuration File. *** ******************************** The file CONFIG.MB is a text file that contains all site-specific parameters. Edit it to have the proper parameters for your site. The form $x is a variable text field. The "$x" is replaced by the current value for that text. These variables can be used anywhere in the configuration file. $A - @ BBS of the current message. $B - Type of current message. $C - Next available message number. $D - The current date. $E - The message title (used for RFC822 headers) $F - Name of "other port", as used in the M, U, and C commands. $G - TO of the current message. $H - Hang at end of line (suppress carriage return). Use at end of line only. DO NOT USE on lines that go to tnc. $I - Users name, from user file. $J - Date from current msg header $K - Time from current msg header. $L - Number of the last message. $M - Message number from current msg header. $N - Number of active messages. $O - Sysops callsign. $P - FROM from current msg header. $Q - Sysops QTH $R - Call in a "connect request:" from either TNC. $S - Call of the end node station connected via the slave TNC. Seen initially in "*** CONNECTED to:" when the adjacent node connects, may be seen in "*** LINKED to:" from the adjacent node. $T - The current time. $U - User callsign. $V - Display the software version. $W - Name of the "other user" in GateWay mode. (See $F and $S). $X - Date user last logged in. $Y - Time user last logged in. $Z - Last message number when user last logged in. $a - BBS of origination of message. $j - Date message was entered at originating BBS. $h - Hierarchical forwarding list. $k - Time message was entered at originating BBS. $m - Message number at originating BBS. ************************* *** CONFIG.MB LINES *** ************************* *** LOOK at the sample in Appendix B *** The first section (to the first *** EOF) is the port configuration info. Two lines per port. The first line contains the port definition, the second line the port name. The port definition line is made of several fields, seperated by spaces: Chapter 2 ------------------ CONFIGURATION FILE ---------------------- Page 2 (Continued) Field 1: The first character is the Port ID, the second and following characters give information about the port: B - BBS only may connect. C - This port is the local console. D - File download allowed from this port. E - This port requires echo. (True only for the console.) G - GateWay use is allowed to this port. I - Kick off user that connects using illegal call. L - This port requires LF after CR. M - Monitoring is allowed to this port. R - Remote sysop allowed on this port (if user marked as sysop). S - This is a raw serial port (another system or a terminal). T - This port has a TNC with TAPR commands connected. U - File upload allowed from this port. X - TNC can use transparent mode for connects. 1 - Echo monitored packets to the console. 2 - Echo user data and forwarding to the console. 3 - Echo TNC commands to the console. Field 2: Connect timeout, in seconds. Field 3: Disconnect timeout, in seconds. Field 4: Monitor timeout, in seconds. Field 5: Max lines allowed in monitor. Field 6: Number of entries retained in J list. Field 7: Number of digipeaters allowed on connect. Field 8: Minute of the hour to attempt forwarding. Field 9: Number of command errors allowed before user kicked off. Field10: Seconds to wait in forward when a timeout occurs before continuing. The second section (to the second *** EOF) is directory path definitions. Three lines per path. The first line is a single character path ID, followed by "D" if downloading is allowed, and "U" if uploading is allowed. The second line is the path, with trailing '\'. The third line is the name of the path, as shown to the user. The third section (to the third *** EOF) is the "@ BBS" translation list. Each line has two fields, the first is the @ BBS as received, the second is what to translate it to. Also Bulletin no user read check. For example; to remove your own call from the @ BBS field of all messages, simply include one line with just your call on it. The fourth section (to the fourth *** EOF) is the "hold calls" list. Any message entered TO, FROM, or AT one of these calls will be held (not forwarded) until the status is changed to N by the sysop. The fifth section (to the fifth *** EOF) is the login message. Keep it short. Maximum is 255 characters. The next line is the "bbs and expert user" prompt. Keep it SHORT! The next line is the remote sysop prompt. Keep it SHORT! The next line is the normal MailBox prompt. The next line is your call. The next line is your QTH. The next line is the call of your local WP server. (Place a blank line ( here if you do not wish to generate updates to WP.) Chapter 2 ------------------ CONFIGURATION FILE ---------------------- Page 3 (Continued) The next line is the file name to use for the help (H) text. The next line is the file name to use for the info (I) text. The next line is the file name to use for the auto-forwarding file. The next line is the file name to use for the log file for each window. The next line is the file name to use for the "J" list file for each window. The next line is the file name to use for the mail file. The next line is the file name to use for the mail backup file. The next line is the file name to use for the user file. The next line is the file name to use for the user backup file. The next line is the directory to put the message files in. The next line is the file name to use for the BID file. The next line is the file to put monitored calls into for each window. The next line is the file name to use for states.mb The next line is the maximum number of monitored calls to save. YES xx Where xx is the time to compress the mail file after 0000z. YES Using DesqView. NO to NOT give idle time. The next 3 lines control prompting for user information. YES to prompt user to enter his name. YES to prompt user to enter his home MailBox. YES to prompt user to enter his ZIP or postal code. The next five lines control logging. (what goes into LOG.MB). YES to turn on logging. Only connects/disconnects are logged. YES to turn on GateWay event logging. YES to turn on file transfer logging. YES to turn on message event logging. YES to turn on logging of local commands. The control character to use to kick user off system. The control character to use to return from talk. The control character to use to interrupt and go to talk. The control character to use to take the MailBox off-line. Prompt before continue at end of page of output. The next line is sent to the console each time a prompt is sent to the user. The next line is sent to the user when a connect request occurs. The next line is the message to send when you break into a MailBox session to talk to the user. The next line is the response to the user when he wants to talk to you. The next line is the message to send when you are not available to talk to the user. The next line is the message to the console when the user wants to talk to you. The next section, one line per message, is the GateWay messages: Message when GateWay not available. Message going into unproto mode. Message when attempting a connect. Message when connect fails. Message to master tnc when connect succeeds. Message when connect attempt aborted by user. Message to send to master when entering monitor mode. Chapter 2 ------------------ CONFIGURATION FILE ---------------------- Page 4 (Continued) The next section, one line per message, is the message and file prompts. Prompt for title of message. Prompt for message text. Message to send at login if user has new mail. Message list header. Observe columns if you change. Line to pre-pend to a forwarded message. Message to send to console when untangle and file empty. Message to send to console when starting an untangle. Message to send as each msg deleted with KM. Prompt to edit TO. Prompt to edit AT BBS. Prompt to edit TITLE. Prompt to edit TYPE. "This message is not NTS traffic". Max # of calls in BT "unread mail" list. (Use 1 for no beacon.) Max # of calls in forwarding "unread mail" list. YES to enable auto-kill of normal messages after auto-forward. (NO leaves the message with status set to 'F'). YES to enable auto-kill of "F" & "B" type messages after auto-forward. YES to generate a service message on KT. YES (to enable the ET command.) YES (to put ping-pong messages on hold.)<---- Number of days a bulletin is when it is called old. Follow by YES if auto-kill. ( Days1 Read1 Days2 Read2 Days3 Read3 added to line above) <------ Number of days a NTS message is when it is called old. YES is auto-kill. Number of days a user message is when it is called old. " " " " Prompt for file text. Default user name. Message when compress user file. Header for list of user records. Prompt to delete user record. The next section, one line per message, is the error/status messages: Reminder to user that he has not entered his name. Reminder to user that he has not entered his home MailBox. Reminder to user that he has not entered his ZIP or postal code. Message for I/O error. Message for "can't find it". Message for protection violation (tried to read private msg etc.). Message for "file exists, and you can't erase it". Message for timout. Message for "I didn't understand the command you gave". Message for done (command completed). Message for "There ain't no such port". Message for "There ain't no such directory". Message for "No such file." Message for "No such message." Message for "Port is in use." Password ( 64 characters for remote sysop use ) Chapter 2 ------------------ CONFIGURATION FILE ---------------------- Page 5 NOTES ----- FIRST SECTION -- PORT PARAMETERS - a space defines fields. The console must be the last configuration line. Field 1: Any number of characters can be used. Certain characters are necessary, such as 'T' for tnc ports, 'C' and 'E' for the console port. 'B', 'D', 'U', 'G', 'I', 'L', 'M', and 'R' are optional. The '1,2,3' are used for display purposes, and control what is echo'd to the screen. IF you are using DESQview, TNC commands should be turned off to speed up the display, therefore there should be no '3' in the line. The 'R' must be in the line if the PORT is to used by a remote sysop. Additionally a remote sysop must be designated in the user file. The 'S' is used for a serial port-modem operation. Auto-answer must be set in the modem, and the user signs on by typing '*** Connected to <user call>. (See Chapter 9) Field 2: The timeout for the bbs waiting for a response from a user or another bbs. It should be long enough to handle mail forwarding thru net/rom's to receive the other bbs's prompt after a message is sent. Field 3: The timeout to wait after a disconnect has been issued to the tnc, and the bbs going back on-line. Field 4: The amount of time to spend in the Gateway while monitoring another port. Field 5: The maximum amount of lines monitored while in the Gateway. Field 6: The number of calls shown in the 'J' lists.(Must be at least 1) Field 7: The maximum number of digipeaters that a user can use for connects to the bbs. This only applies for users and not for bbs's & sysop's marked in the user file. Field 8: The minute of the hour to start forwarding. It is also the minute that an auto-compress (GM) will take place. This should be slightly different between windows for smooth DESQview operation. Field 9: The number of errors that a user can make before the bbs disconnects him. (i.e. Number of *** WHATS?) Field 10: The number of seconds for the bbs to wait when forwarding to a bbs and your disconnected, and then start to forward to another bbs. Allows the tnc to dump all of the data that it has loaded into it. Chapter 2 ----------------- CONFIGURATION FILE ----------------------- Page 6 (Continued) ***************************************** *** ALTERNATE DISPLAY OF TNC COMMANDS *** ***************************************** If you leave out the 3 in the port configuration in config.mb, you will not see the tnc commands on the bbs. What you will see is the PORT Configuration LETTER (a,b,c) of where the tnc command is going. If the tnc accepts the command it will be in upper case; if not it will be in lower case. This is useful when running multiple copies of the bbs under desqview, as it speeds up the screen display, and makes things work faster. THE THIRD SECTION -- @BBS TRANSLATION LIST The @ bbs translation list a list of calls to be translated by the bbs whenever a message is entered. This will happen if a user is entering a message or you are being forwarded a message by another bbs. K3RLI ---> K3RLI is changed to spaces. USA CHECK ---> USA is changed to CHECK PAWEST NEPBBS ---> PAWEST is changed to NEPBBS. RT2N NEPBBS ---> RT2N is changed to NEPBBS. ALLPA PANET ---> ALLPA is changed to PANET. 98* AG3F ---> Zip 98xxx is changed to AG3F. *** EOF You can make the list as long as you want, and include wild card matching. What happens is that the @BBS field is changed from whatever is in the first field to whatever is in the second field. This can be helpful in redirecting certain bulletins to a distribution list. In the example above, PAWEST, RT2N, and ALLPA are all changed to NEPBBS when the message is received, and if NEPBBS was a distribution list, then ALL PAWEST, RT2N, and ALLPA would follow that distribution. By having your call changed to spaces will allow the bbs to strip off your call in the @BBS field and then have the message forwarded to the TO field if it is in your forward file. THE FOURTH SECTION -- HOLD CALLS LIST This section is a list of calls or just the word hold. Any message entered on the bbs with one of these calls will be marked with a status of 'H'. Sysop intervention is necessary to clear this message with the edit message command to remove the 'H' status. Chapter 2.1 ------------------ BULLETINS ---------------------------- Page 1 AUTOMATIC BULLETIN PURGING Thanks to WA3TSW for comming up with this method. It allows your users to determine when a bulletin is marked as killed or stale. Let's take a look at the line in the config that will set the guidelines for bulletin purging. 30 YES 4 2 7 4 14 10 <- Line for bulletins 14 NO <- Line for NTS messages 14 NO <- Line for Private messages In the line for Bulletins, We first say that the longest time a bulletin will last before being killed is 30 days. The "30" represents the number of days and the "YES" means mark killed instead of stale. This is the LAST test of a bulletin. Following that, the next two numbers represent 'days' and 'read' of a bulletin. In this case, we are saying that a bulletin MUST be read at least "2" times in the next "4" days. If your users do not read this bulletin at least "2" times after "4" days it will be marked killed. The next set of numbers is another test; In this case we say that after "7" days, this bulletin should be read at least "4" times or it will be killed. And finally the last set of numbers; After 14 days, this bulletin has to read at least "6" times or it will be killed. A sysop can now allow his users to determine how long a bulletin will stay on the system. For a small mailbox with only a few users you might want to make a line like this with some other examples. 30 YES 7 2 14 3 21 4 This will allow your bulletins to last longer on the system with fewer reads. 30 YES 30 1 30 1 30 1 This will allow no purging of bulletins until the whole "30" day period is up. This method will work on all bulletins of type "B". To allow some classes of bulletins NOT to be purged, we allow the sysop to classify some distributions. This is done in the "swap bbs" section of the config.(Third Section - @BBS Translation list) The method used follows. K3RLI KB3UD WB3DTG ARL ARL <- New (No user read check) AMSAT AMSAT <- New (No user read check) *** EOF In this example, K3RLI is swapped to spaces to have the "@bbs" of K3RLI changed to spaces. Anything @KB3UD will be swapped to @ WB3DTG. So far everything is the same as before. Now with ARL swapped to ARL, and AMSAT swapped to AMSAT nothing really changes but ALL ARL and AMSAT bulletins will not be purged, and will be held till only the LAST test. Again, in this example ARL and AMSAT bulletins will be killed after "30" days with no user read check. Also, when listed by the sysop, the status of these bulletins will show up as '$' instead of 'N'or 'F'. Chapter 2.1 ------------------- BULLETINS --------------------------- Page 2 (Continued) This process now gives a sysop a good method of controlling bulletins. By putting bulletin distributions in the "swap bbs" section of the config, he allows those bulletins to last for the maximum number of days he wants. And further, now can have users determine how long a bulletin lasts based on how many times it has been read. A sysop can edit a bulletin to either '$' or 'O' (stale). Making a bulletin 'O' (Stale) will allow the bulletin to stay on the bbs until killed by having the sysop use the "KO" (Kill Stale) or "K Message #". Likewise editing a bulletin to '$' will keep it on the bbs till the last test.(First number of day's on bulletin config line.) In our example that's 30 days. Bulletin purging gets checked during the first auto-forward after 0000z of the new day. So, if the mailbox is busy with users nothing happens till you get the first auto-forward to take place. Bulletins are then marked as stale or killed, but are not deleted until a 'GM' or auto-GM takes place. When bringing up this version (6.71), most of your bulletins should already be marked with a status of '$' from earlier versions used. This is because in earlier versions the '$' status was used a a bulletin forwarding completion flag. Now the '$' status indicates that the bulletin will last for the entire time without any user read checks. So you will have to edit your present bulletins or kill them manually to get them off the bbs sooner. All NEWLY received bulletins will follow the tests of (days)(read) in the config. Make sure you edit your config to include the new values before starting version 6.71. Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 1 (Revision C) Automatic forwarding of messages to other MailBox systems. The file FWD.MB contains information that drives the automatic forwarding of messages. If the file does not exist, no forwarding is done. This file can be changed or checked with the YF command. The file contains several kinds of information: 1) Tnc parameter changes. 2) Command scripts. 3) Routing lines. 4) Message size line. 5) Forward lists. 6) Sublists. 7) Dos Commands. 8) Change Forward file 1) <<<<< TNC PARAMETER CHANGES >>>>> "P" lists are commands to be sent to the TNC. The character after the P is which port ("A" for COM1, "B" for COM2, etc.). The list is terminated with "*** EOF". One of these lists might preceed each "G" list to set the TNC parameters to be used for the forward attempt. There should be a "P" list at the end of the FWD.MB file to reset TNC parameters back to default. "P" lists can also have a time window. Examples follow: TIMED PARAMETERS PA PA0004 <-- Out the A port from 00 to 04 RE 3 RETRY 3 FR 7 FRACK 7 MAX 1 MAXFRAME 1 *** EOF *** EOF Abbreviations can be used for TNC commands as long as they work with the TNC you are using. Using them will speed things up as there would be less characters to send to the tnc. Make sure you change the parameters back to normal at the end of the file. *** TRANSPARENT MODE *** You can now use transparent mode for all connects and for reverse forwarding. This will do two things.First it will stop the inbedded *** CONNECT REQUESTS from appearing in messages on your bbs. Second you will now be able to setup your tnc parameters so that users can get information off the bbs faster. Like setting MAXFRAME = 4, and PACLEN = 128, will allow the tnc to send out 512 bytes at a time when a user is using the bbs. Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 2 Transparent Mode (Continued) Regular forwarding will still take place in converse mode. If you want to block forward, then you can setup 'P' type commands in the forward file. Set things up at the beginning of the forward file. PA Out to the A tnc. MAX 2 Maxframe of 2. FRAC 6 Frack of 6. CP ON { } CR OFF { block forward } SE $10 { } *** EOF Then restore things back to normal at the end of the forward file. PA Out the A tnc. MAX 4 Maxframe back to 4 FRAC 4 Frack back to 4 CP OFF { Back } CR ON { to normal } SE $0D { } *** EOF It is important that you use the BRBIOS with transparent mode. It incorporates the send break command for the tnc. Also important is that you have the DCD line (pin 8 ) connected between the tnc and the comm port. The TNC must change this line when it gets connected. Otherwise, you will lock up the bbs. Note: TNC1's must be modified for the DCD line. MBBIOS should also work. 2) <<<<< COMMAND SCRIPTS >>>>> Command scripts are supported through "C", "S", and "R" items. The command script precedes the F, G, or H routing line that uses it. CC K3QFW-2 SC K3CR-2 RConn A "C" item gives the connect string to send to the local TNC: -------------> CC K3QFW-2 A "S" item is a line to send: ---------> SC K3CR-2 A "R" item is a match for a partial expected response: Whole line ---------> RK3CR-2} Connected to K3CR-2 or Partial response -----------------> RConn For ANY response being valid use: -----> R! Before making up the Command Scripts, you should manually connect to where you want to go, look at the responses, and then make up the "R" lines for a match. Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 3 Command Scripts (Continued) There can only be ONE "C" item in a script, but may be as many "R" and "S" items as are required. As an example, the script for K3RLI using NET/ROM to connect with WA7SSO is: CC K3QFW-2 (This connects me to the local NODE) SC K3CR-2 (Connects to the NODE closest to WA7SSO) RConn (Expected partial NODE response) SC WA7SSO (This connects me to WA7SSO) RConn (Expected partial NODE response) FA0023C WA7SSO (Forward mail to WA7SSO from 00 to 23) WA7SSO (The usual forwarding list) K3AMT KA3NVP *** EOF (End of list marker, MUST be all CAPS) Example of using a KANODE: CC N3ET-1 (This connects me to the N3ET KANODE) R###CONN (Expected partial response) RENTER (Second line of response) SX WB3FYL-1 (Cross connect to WB3FYL-1 NODE) R?###LINK MADE (Response of '?' & ###LINK MADE) SC WB3FYL (Connect to WB3FYL) RConn (Expected partial response) F0024C WB3FYL (Forward to WB3FYL from 00 to 24) Example of using a Net/ROM node to KANODE: CC K3RLI-3 (This connects me to the local node) SC N3ET-1 (Connects me from NET/ROM to KANODE) R###CONN (Expected response from KANODE) RENTER (Second line of response) SC N3ET (Connect to N3ET) R?###LINK MADE (Response from KANODE) F0024C N3ET (Forward to N3ET from 00 to 24) Any connection or combination can be made up using the "S" and "R" lines. Always check and make sure that you have the required response in the "R" line. If it is wrong you will end up sending a disconnect and aborting the connection. Try to use nodes properly so that if a particular node goes down, that the node will look for an alternate route. A "C" item can be used alone to establish the connection using a script. Following this line must be the routing line. CC W3AVK V K3QFW-1 (Connect to W3AVK Via K3QFW-1) FA0024C W3AVK (Forward using port A from 00 to 24) In this case, the script is used for the connection. The W3AVK in the routing line is only there as a reference for any X or XI commands. It can be changed to anything that would provide a reference for that particular route. Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 4 2) <<<<< ROUTING LINE >>>>> E, F, G, and H lines are lists of stations for whom you should forward mail. They are grouped by the call of the MailBox to which the messages will be forwarded. Each list has a routing line, any number of callsigns or sublists, and the list terminator ("*** EOF"). A "G" line is used to do conventional forwarding. All BBS systems will respond correctly if you use a "G" line. A "F" line is used when the system you will connect to supports reverse forwarding. If you do not wish to use reverse forwarding simply always use a "G" line. A "H" line acts the same as an "F" line. except that the connect and probe for reverse forwarding will occur even if you do not have any messages to forward. A "E" line acts like a "G" line, except the forwarding is not done, the line is only used when someone requests reverse forwarding. The Routing line looks like: Columns Data 1 "E", "F", "G", or "H" 2 Port identifier. "A" = COM1, "B" = COM2, etc. 3-4 Hour to activate forwarding to this station. 5-6 Hour to de-activate forwading to this station. 7-end Callsign of the MailBox to forward to. Forwarding will occur at the minute given for the port in CONFIG.MB, on those hours given in FWD.MB. 4) <<<<< MESSAGE SIZE LINE >>>>> CBBS now has message size limiting on forward. Add to the forward file after the "F", "G", or "H" line: <>0123 3000. This line must be after the 'F', etc line and in this example from 01 to 23 will limit the maximum message size to 3000 bytes. The "<>" is followed by the time window with no space inbetween. You can use a different or no message size limit line in each forward to a bbs. Example: FA0024C WB3EAH (Routing line) <>0005 2500 (Limit message size to 2500 bytes from 00 to 05) WB3EAH (Forward lists) N3EPY *** EOF (End of lists marker. Must be Caps) Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 5 5) <<<<< FORWARD LIST >>>>> The forward list is nothing more than the list of calls that you want forwarded onto another mailbox. That calls are listed one per line, You can also use SUBLISTS and wildcards for matches. *** Wildcards *** When the designator in FWD.MB is compared to the TO or @ BBS call, the characters "?", "!", and "*" appearing in the designator act as wildcards. "?" will match any character. "*" causes the remaining characters to match. "!" will match any digit. FOR EXAMPLE: Using ZIP code routing, to route all South Carolina NTS traffic to WB0TAX, you would put "NTS4*" or "4*". Any message sent to a destination starting with "NTS4" or "4" would route to WB0TAX. WB0TAX could then continue the routing breakdown by forwarding "NTS41*" or "41*" to one station, "NTS42*" or "42*" to another, etc. 6) <<<<< SUBLISTS >>>>> At any place in the FWD.MB file you can refer to another file. In effect what happens is that the contents of the sublist are treated exactly as if they were in the FWD.MB file. This feature is very useful when you have several alternate paths to a given location. FWD.MB need only contain the connect information for the different paths. You can refer to a single file that contains the list of calls for forward. A sublist is given by a line starting with "@". The rest of the line is the device, path, and file name of the sublist. Example: GC0023C WB3EAH WB3EAH N3FSP @C:\MB\BBS\HF.FWD (Sublist) @ 0012C:\MB\BBS\WPENNA (Sublist) *** EOF GD0023C KA3NVP KA3NVP @C:\MB\BBS\WPENNA *** EOF Sublists can now use a time window just like a routing line. This is OPTIONAL, but there may be times when you want to forward certain lists to different mailboxes depending upon the time. EXAMPLE: @ 0012C:\MB\BBS\WPENNA The space after the '@' specifys that this is a timed sublist. The 0012 is the start and end of the time window. So WPENNA ( in this example ) will only be checked from 00 to 12 for any calls. At any other time this file will be bypassed. Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 6 7) <<<<< DOS COMMANDS >>>>> A "!" list is a list of DOS commands. It acts very much like a .BAT file. The second character of the list header must be a port that exists or the commands are not executed. This is done so that a single FWD.MB may be used by several copies of the MailBox running under DESQview. The commands will only be executed by the copy that owns the port. The time window is honored. All files used by the MailBox are "cleaned" before the DOS commands are executed. Be very careful what commands you use here; anything that might CHANGE one of the files used by the MailBox will cause TROUBLE! You must also run the MailBox in a partition large enough to allow for COMMAND.COM (25k) plus whatever commands you run. This feature is useful, for example, to backup the MailBox files from RAM disk to hard disk or floppy once each hour. Dos commands are only operational from automatic forwards. To be operational from a manual forward, you must add a field designator like this: !A0023 WB0TAX. So "XI WB0TAX" will do the dos command. EXAMPLE: !A0023 -----------------> Do dos shell command 00-23 COPY \MB\BBS\LOG.MB D: --> Dos Command Line *** EOF -----------------> EOF line Copies LOG.MB to the D drive every autoforward. 8) <<<<< CHANGE FORWARD FILE >>>>> EXAMPLE : YF0020 C:\MB\BBS\TEMP.MB Putting YF< time window > < new forward file > as the last line of your forward file will change from the present forward file to the new one that you designate. The time window is needed and if you want it to change every hour just make it 0024. If you don't want to use this feature just don't put the line in your present forward file. This is a handy feature if you only wanted to forward every second hour. Or if you had a separate forward file that you use on special occasions. You could have your special forward files always return the bbs back to the standard forward file after it's use. Now using two forward files, you can filp-flop them on every forwarding session. FWD.MB TEMP.MB PA PA .... .... *** EOF ***EOF FA0024C K3QFW FA0024C W3AVK K3QFW W3AVK .... .... *** EOF *** EOF PA PA .... .... *** EOF *** EOF YF0024 C:\MB\BBS\TEMP.MB YF0024 C:\MB\BBS\FWD.MB Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 7 *** Bulletin distribution lists *** If a message has a destination MailBox specified, then that designator may also be used as the name of a distribution list. When the message is entered, the messages directory path (normally \mb\msgs\) is checked for a file with the same name as the designator and an extension of .DIS. If the file is found, then the messge will be forwarded too ALL the destinations found in the file. One destination per line. 16 destinations maximum. As an example, for my local sub-net distribution I have a designator PANET (Pennsylvania Net), and a file PANET.DIS containing: WA3TSW KB3UD W3AVK WA7SSO A message sent as: SB ALL @ PANET Will be forwarded to all three of the stations in the PANET.DIS file. The message is not forwarded in any special order, if a station is busy then the MailBox will try again the next hour. See also Chapter 6 for more information on Distribution files. An "L ;" listing of a message with a distribution list shows the status of forwarding to each station on a second "cc:" line. The calls to which the message have been sent have an asterisk before them. The ";" can be used with any list command to show the full title, any "cc:", "EF:", and "BID:" attached to the message. The following is an example of a few lines of the FORWARD file: (Forward to K1BC every hour) GA0023C K1BC VIA KD2S-1 <Function, port ID, Time, MailBox, path> W1XR <Call of station whose mail should be forwarded> N1AWX K1BC @\MB\BBS\NH *** EOF <Marks the end of list> PB1023 <Set TNC params for next connection> FRACK 6 MAXFRAME 2 *** EOF GB0222C K7PYK <Forward to K7PYK only from 0200 to 2259) <>1922 2000 <Limit message size to 2000 bytes from 1900 to 2259> K7PYK W7KB @\MB\BBS\HF *** EOF PB1023 <Set TNC params back to normal> FRACK 4 MAXFRAME 4 *** EOF Chapter 3 ------------------ FORWARD FILE ---------------------------- Page 8 There is no limit to the number of lists or the number of calls in each list. Your MailBox will do the connect and send the messge onward. It will either delete it or mark it with 'F' status depending on the setting of the YES/NO (Kill on forward) flags in CONFIG.MB. Auto forwarding is attempted each hour at the minute specified in CONFIG.MB, or when you use the "X" menu item. The special call "*" (a single *) can be used to force the forwarding of all mail not addressed to the system owner. This could be used by someone who would like to run this software, but would not like to maintain an active MailBox. They would get all their own mail locally, but any mail deposited onto their system would be automatically forwarded. The forwarding of messages counts on the remote MailBox behaving correctly. It must have a menu with '>' at the end of the last line. The command for sending messages must have the form "Sx call". It must prompt for message title, and then prompt for message text. Message text is terminated by ^Z. *** FORWARD FILE *** If using multiple windows, you can use different Forward files with each window, or you can use one master forward file. If you are using different forward files for each window, you must name them differently in each config. (Example - FWD.A, FWD.B, ect) Otherwise FWD.MB can be used for all windows and all config's. The forward minute should also be different between windows for best operation. A one or two minute difference between ports in different windows works out nicely, and allows the display to run smoothly. Chapter 3.1 ----------- HIERARCHICAL FORWARDING ---------------------- Page 1 HIERARCHICAL FOWARDING Version 6.0 of the code now supports hierarchical fowarding. Hierarchical fowarding was introduced to the packet bbs networks in the RLI code and in the recently distributed 4RE program. The method used by the CBBS should be compatable with these programs. Hierarchical fowarding is a method by which the @ bbs field of the message address may contain information beyond the 6 character call sign or route designation that is now commonly used. The @ bbs field may be expanded to 64 characters containing numerous fields separated by periods. A typical field might be AG3F.PA.USA.NA indicating station AG3F is located in state PA, country USA and continent NA (North America). The only limitations to this is that the 64 character total cannot be exceeded and the section of the field prior to the first period must not exceed 6 characters in order to be compatable with existing bbs's. The actual convention for naming the sub fields (hierarchies) in the @ bbs field has not been firmly established but N6VV has proposed a system of hierarchies which has been adopted as a pseudo standard by many stations. This we attach for information. In the method chosen to implement hierarchical fowarding, the CBBS is able to receive extended @ bbs fields from a local user or a fowarding bbs by the addition of the extra information to the S(end) line. A typical line could be SP AG3F @ AG3F.PA.USA.NA < K3RLI $1234_BID which will be recognized as "standard" in all respects except for the field following the @. It should be noted that the normal @ field is still acceptable since it is a subset of the larger field. During the fowarding process the 6.0 bbs will transmit the full @ field only to stations that request it. This request must come in the form of a sid that contains the letter H in the last field. The CBBS requests this by transmitting [CBBS-6.7-H$]. The RLI and 4RE programs do similiar with their sid's. Stations that do not have the H in their sid will receive the truncated form of the @ field containing only the normal 6 character call field. The foward file still retains its original format but now can contain entries that match the various sub fields in the routing lists to fully utilize the hierarchical feature. In the example above if we were to route that message normally, AG3F would have to appear in a routing section. Now AG3F or PA or USA or NA can be inserted in to the lists and the bbs will now match these to those contained in the message and foward accordingly. This permits rather long lists of calls to be replaced with a general hierarchial designator in the foward file. Additionally, a user can assist the bbs sysop by appending the state designator to the bbs field. This would assure fowarding in particular in the case of a new bbs not present in the user file. @ W6XYZ.CA will be fowarded but @ W6XYZ may or may not depending upon if W6XYZ was in the foward file. If multiple matches are possible in the foward file, the first one found is used. This means generally that if the call is found it is used followed by the state, country, etc. Chapter 3.1 ------------ HIERARCHICAL FORWARDING --------------------- Page 2 (Hierarchical Forwarding) An example of a routing list might be: FA0023C K3RLI V K3RLI-2 K3RLI WA3EBG KB3UD AK3P 188* 187* PA <- State Designator - Pennsylvania MD <- " " WV <- " " NJ <- " " CAN <- Country Designator - Canada SA <- Continental Designator - South America NTSDE NTSMD NTSNY NTSVA *** EOF Note sections of the hierarchical list are inserted only, never anything containing a period. PA.USA is not acceptable! This fowarding method will only become a very valuable tool when more stations employ the software that utilizes it and when the system users, the originators of the messages, start to insert the hierarchical information. Now, any bbs not utilizing this system breaks the chain and the hierarchial data is lost. Hopefully all of the software writers will incorporate this into their code in the near future. For now it can assist in the routing of locally originated traffic. = Suggested abbreviations for use with hierarcical routing bbs lists = ** Continental Abreviations ** AF - Africa AS - Asia AU - Australia EU - Europe NA - North America SA - South America ** Country Abreviations ** Argentina ARG Japan JPN Australia AUS Korea,North PRK Austria AUT Korea,South KOR Belgium BEL Liberia LIB Bermuda BMU Liechtenstein LIE Bolivia BOL Luxembourg LUX Chapter 3.1 -------------- HIERARCHICAL FORWARDING ------------------- Page 3 ** Country Abreviations ** (Continued) Brazil BRA Malaysia MYS Brunei BRN Mexico MEX Bulgaria BGR Monaco MCO Canada CAN Morocco MAR Chile CHL Netherlands NLD China CHN New Zealand NZL Colombia COL Nicaragua NIC Costa Rica CRI Norway NOR Cuba CUB Pakistan PAK Denmark DNK Panama PAN Dominican Republic DOM Paraguay PRY Ecuador ECU Peru PER Egypt EGY Phillipines PHL El Salvador SLV Poland POL Finland FIN Portugal PRT France FRA Romania ROM French Polynesia PYF Saudi Arabia SAU German Demo. Rep. DDR Singapore SGP Germany, Federal Rep. DEU South Africa ZAF Greece GRC Spain ESP Greenland GRL Sweden SWE Guatemala GTM Switzerland CHE Haiti HTI Syria SYR Honduras HND Taiwan TWN Hong Kong HKG Thailand THA Hungary HUN Turkey TUR Iceland ISL United Kingdom GBR India IND United States USA Indonesia IDN Uruguay URY Ireland IRL USSR SUN Israel ISR Venezuela VEN Italy ITA Yugoslavia YUG ** State and Canadian province abreviations ** AL - Alabama AK - Alaska AZ - Arizona AR - Arkansas CA - California CO - Colorado CT - Connecticut DE - Delaware DC - District of Columbia FL - Florida GA - Georgia GU - Guam HI - Hawaii ID - Idaho IL - Illinois IN - Indiana IA - Iowa KS - Kansas KY - Kentucky LA - Louisiana ME - Maine MD - Maryland MA - Massachusetts MI - Michigan MN - Minnesota MS - Mississippi MO - Missouri MT - Montana NE - Nebraska NV - Nevada NH - New Hampshire NJ - New Jersey NM - New Mexico NY - New York NC - N. Carolina ND - N. Dakota OH - Ohio OK - Oklahoma OR - Oregon PA - Pennsylvania PR - Puerto Rico RI - Rhode Island SC - S. Carolina SD - S. Dakota TN - Tennessee TX - Texas UT - Utah VT - Vermont VA - Virginia VI - Virgin Island WA - Washington WV - W. Virginia WI - Wisconsin WY - Wyoming AB - Alberta BC - British Col. MB - Manitoba NB - New Brunswick NF - Newfoundland NT - NW Territory NS - Nova Scotia ON - Ontario PE - Prince Edward PQ - Quebec SK - Saskatchewan YT - Yukon Territ. Examples: VE3YZX.ON.CAN.NA AG3F.PA.USA.NA EL8C.LIB.AF Chapter 3.2 ---------------- USING STATES.MB ------------------------- Page 4 (Revision A) *** USING STATES.MB *** STATES.MB is a file with the hierarchical routes for most USA mailboxes. It was made originally from lists that were distributed by W9ZRX. Dave is no longer making this list. You can edit STATES.MB to include any route or information you want to. Remember to keep the hierarchical address separated by periods, then at least one space, and then any information about the station to fill the rest of the line. AD8I.OH.USA.NA Columbus, OH. 43113 - White Pages Server You can also look for @ NEWHDR bulletins to add new mailboxes as they are found. You can also use a program called BBSPARSE by N2MH to parse your message headers and creat new listings for STATES.MB. STATES.MB does not change any received hierarchical route; It only acts on a message that does not contain one and adds it if the route is found. You can edit STATES.MB to include any route you want to. For foreign calls you might add something like this: G3XXX.GBR.EU or I5SGG.ITA.EU You can also edit in local designators to aid in your local forwarding: KB3X.#WPA.PA.USA.NA <-- The #WPA being a special designator Now all you have to do is make up a new forward file with the use of the different designators. No longer will you have to keep callsigns of bbs's in the forward file lists. State codes should handle most of the forward matches, and you can add any new bbs's to STATES.MB as they become known. You can also use Canadian or foreign lists if they are available. *** WILD-CARD USAGE *** Wild cards are allowed in the STATES.MB file. Just be sure that your wild cards match proper routes. The following is an example of wild cards in STATES.MB. 4X4IP.MD.USA.NA 4X!*.ISR.EU A '!' means match any digit. A '*' means match anything that follows. These are the same wild-cards used in the forward file. The 4X4IP is a bbs located in Maryland, but any other 4X call will have the .ISR.EU route attached to it. Just make sure that ALL exceptions are listed first, and the wild card match last. This will work for all KNOWN routes to any bbs's. This should help to keep STATES.MB at a miminum size. Comments can be put in the STATES.MB file after the hierarchical route. Just add a space or two after the route and add any comment on the same line. The "P" Command will search the user file and then STATES.MB for any match and display the line accordingly. Chapter 4 ------------------ COMMANDS -------------------------------- Page 1 ******************************* *** @ REMOTE SYSOP Password *** ******************************* SYSOP only Command: The last line of the config.mb must contain a line of 64 characters. This can be a sentence or just 64 ascii characters. Upper or lower case can be used and is considered as different characters. EXAMPLE: NowisthetimeFORallgoodpacketeerstocometotheaidoftheirparty.T When a remote sysop sends a "@" to the bbs the bbs will prompt the remote sysop with 4 numbers.. The four numbers will correspond to the positions of the characters in the key. The remote sysop will then reply with the 4 characters that correspond to the relative positions in the key. EXAMPLE: BBS --- 4 16 23 64 Remote Sysop enters: iapT and hits <cr>. He will then be allowed entry as a remote sysop.. ********************* *** ! DOS Command *** ********************* SYSOP only Command: This ! command allows the use of the dos shell. You can do almost any dos command, as long as you don't disturb any of the mailbox dat files. SYNTAX - ! COPY A:TEXT.TXT C:\MB\PACKET Copies the file text.txt from the A drive to the C drive in the subdirectory packet. This command can also be used in the FWD file to do Batch files during a forward. ***************** *** A Command *** ***************** SYSOP only Command: A - Does an autoforward on all windows. AI - Does an autoforward on all windows ignoring the time. ***************** *** B Command *** ***************** B <cr> - Logs off the mailbox. For a user, disconnecting does the same thing. Chapter 4 ------------------ COMMANDS -------------------------------- Page 2 ***************** *** C Command *** ***************** C CALL - Connects to user from path and port in the user file. Cp CALL - Connects to call using port p. Digipeater routing may also be given. EXAMPLES: CA K3QFW V AK3P-5 C AG3F SYSOP only Commands: CM CALL #### [@ BBS] [< CALL] - Copies message #### and makes new message addressed to CALL. C YYMMDD HHMM - Sets the clock. ***************** *** D Command *** ***************** USER only Command: Dd Filename - Download a file from the mailbox. 'd' is the directory identifier. SYSOP only Commands: D C:\path\Filename - Downloads filename in drive C, with path to the console with pageing. DA C:\path\Filename - Downloads filename out the A port to the tnc. Continues till eof of file. DU - Lists all users. DM - Lists all users marked as bbs's. DS - Lists all sysops. DL - Lists all local users. DX - Lists all excluded users. For the above commands if a filename is added as an argument the list will be put into a ascii text file. DW Command - creates a WP message if any new users use the bbs. Used by sysop when the bbs does not make up a message. For this command to work, you must have a WP server call in your config. SYNTAX - DW DW A - creats a WP message with all users. *** White Pages *** As users check into your bbs, they will be automatically asked for their name and home bbs. When the user file was updated to the latest version on first starting the bbs, A new field was created to note when a user puts in his name and home bbs. It is this field that will create a white paper message to whatever bbs is keeping track of calls and homebbs's. Here is how it works. First in the config.mb there is a line for the WHITE PAGES SERVER CALL. If you leave this line blank, no white paper message will be generated. This line is located under your QTH in the config.mb. Chapter 4 ------------------- COMMANDS ------------------------------- Page 3 (White Pages Continued) If you put a bbs on this line, he will receive a message every so often addressed to WP, from your bbs, @ WP Server Call, TITLE: "WP Update". In the message text will be a list of the latest users using the bbs for the first time, or updateing their name and homebbs. So a central bbs or user can now keep track of all the users with their home bbs's for a given area. Sort of like keeping a white pages telephone book with calls of packeteers and their home bbs. Zip codes are now added. ***************** *** E Command *** ***************** SYNTAX - ET <message number> - USED by ALL The ET command allows users to edit Traffic messages on the bbs. A Traffic message is defined as having a TYPE of "T" or the letters "NTSxxx" in the TO field of a message. Any user can use the ET command. Probably it would be a good idea to let your NTS users know of this feature, so that they could track your NTS type messages. EXAMPLE: Message 8873 is a Traffic message. ET 8873 <- Entered by user or sysop. BBS response:New TO or (cr) to retain: User responds with a new call or <cr> BBS response:New @ BBS or (cr) to retain: User responds with a new @ BBS or <cr> BBS response:New TITLE or (cr) to retain: User responds with new title or <cr> BBS response:New TYPE or (cr) to retain: User responds with new type or (cr) to retain BBS will now respond with the edited message header. If you enter a message number that wasn't a traffic message the bbs will respond with a message: *** Sorry, this is not an NTS traffic message. If you change the type of message from a "T" to something else, The message header will be changed, and since it will not fit the qualifiers of an NTS message, you won't be able to change it back! SYSOP only Commands: E #### - Edit message ####. This command looks for the message, and then displays the header from that message. Next comes the input prompt: t(Y)pe, (S)tatus, (T)o, (F)rom, (B)bs, t(I)tle, bi(D) To change: The TYPE field ---- Y <type> <cr> The STATUS field -- S <status> <cr> The TO field ------ T <new to call> <cr> The FROM field ---- F <new from call> <cr> The @BBS field ---- B <new bbs call> <cr> The TITLE field --- I <new title> <cr> The BID field ----- D <new bid> <cr> To exit edit message, just hit a <cr> from the prompt. Chapter 4 ------------------- COMMANDS ------------------------------- Page 4 E COMMAND (Continued) EP p - Edit port parameters. is the port to edit. ES - Edit system parameters. EU - Sweep thru all users asking for Delete or Quit, EU CALL - Edit a user's record or create a new user record. This command will find a user's record or create a null user's record, and then display a prompt line: PRIVILEGE: (D)elete, (E)xpert, (B)bbs, (S)ysop, e(X)clude DATA: (C)all, s(I)d, (N)ame, por(T), (H)ome, (Z)ip To delete a user: Type D <cr> To change: Is an EXPERT ---- Type E <cr> Is a BBS? ------- Tyoe B <cr> Can be SYSOP ---- Type S <cr> To EXCLUDE ------ Type X <cr> New CALL -------- Type C <new call> <cr> New SSID -------- Type I <new ssid> <cr> New NAME -------- Type N <new name> <cr> New PORT -------- Type T <new port> <cr> New HOME BBS ---- Type H <home bbs> <cr> New ZIP --------- Type Z <new zip> <cr> To exit edit user, just hit a <cr> from the prompt. ***************** *** F Command *** ***************** SYSOP only Command: Fd ##### Filename [AN] - Make a file from a message. The 'd' determines what subdirectory Filename go to. The A at the end will append this message to the file. The N at the end will NOT put the message header into the file. EXAMPLES: F 12340 A:text.txt - Makes file TEXT.TXT on the A drive from message 12340; Includes header. FD 1200 amsat.010 - Makes file AMSAT.010 in subdirectory D from message 1200. FD 1300 amsat.010 A - Appends message 1300 to file AMSAT.010 in subdirectory D. F 12300 c:Save.txt N - Makes file SAVE.TXT on C drive with no header. Chapter 4 ------------------- COMMANDS ------------------------------- Page 5 ***************** *** G Command *** ***************** SYSOP only Commands: Will LOCK up other windows using DESQview. If other windows are busy, will not allow any operation. GM - Untangles the mail file. GR <number> - Untangles the mail file and renumbers starting at number. GU - Untangles the user file, deleteing marked users. ******************** *** HELP Command *** ******************** H - Gives a summary of the help subsystem. H x - Gives a detailed explanation of command x. H ? - Gives a detailed explanation of all commands. ? - Gaves a list of mailbox commands ? x - Gives a summary of command x. ? ? - Gives a summary of all mailbox commands. ******************** *** INFO Command *** ******************** I - Reads out the INFO.MB file. ***************** *** J Command *** ***************** Jp - Gives a list of stations heard on port 'p'. The special port 'L' shows calls of stations recently connected to the mailbox. ***************** *** K Command *** ***************** K ##### - Kill message number #####. KM - Kill messages addressed to you that have been read. KT #### - Kill traffic message and generate a service message. SYSOP only Commands: K #### #### #### #### - Kill up to 4 messages. KA #### - Kill message #### but don't archive. KF ------ Kill all forwarded messages. KO ------ Kill all stale messages. KY ------ Kills all messages that have been read. KF CALL - Kills all forwarded messages addressed to CALL. KY CALL - Kills all messages addressed to CALL that have been read Chapter 4 ------------------- COMMANDS ------------------------------- Page 6 ******************** *** LIST COMMAND *** ******************** L ------- List all new messages since your last login. L #### -- List messages back to ####. LE ## -- List last ## mail headers in MAIL file. LL ## -- List last ## messages. L> CALL - List all mail TO Call. L< CALL - List all mail FROM Call. L@ CALL - List all mail @BBS Call. LA ------ List all type 'A' messages. LE ------ List all mail headers since your last login. LF ------ List all forwarded messages. LH ------ List all messages that are marked HOLD. LK ------ List all KILLED messages. LM ------ List all messages TO or FROM you. LO ------ List all stale messages. LU ------ List all unforwarded messages. LY ------ List all messages that have been read. If you add a ';' after your normal list command, you will be able to see any cc: line or Hierarchical list and any bid line attached to a header. You will also see to who this message forwarded to. This will work with any command. Example follows: LL 4 Will list the last 4 lines. 9989 PN 1247 KA3DWA WA3DQI 0109/1212 ARC NETWORK 9986 AN 978 ALL W1AW PAWEST 0109/1034 ARRL 54: News 9985 BN 2367 ALL KC3BQ 0109/0956 Hamfest news 9984 PN 1545 K3RLI AG3F KC2AZ * 0109/0945 TNC WORKS LL 4 ; List last 4 lines and cc:, ef:, and bid: lines 9989 PN 1247 KA3DWA WA3DQI 0109/1212 ARC NETWORK 9986 AN 978 ALL W1AW PAWEST 0109/1034 ARRL 54: News cc: *WA3DQI AG3F HOLD BID: ARLP010 9985 BN 2367 ALL KC3BQ 0109/0956 Hamfest news BID: KC3BQ_7789 9984 PK 1545 K3RLI AG3F KC2AZ * 0109/0945 TNC WORKS F->KC2AZ EF: KC2AZ.NY.USA.NA This will work for all list commands. Like LL 10 ; or L ; or LM ; or LA ;. This command is available for sysops and users and allows you to see the messages with the extra lines. Chapter 4 ------------------- COMMANDS ------------------------------- Page 7 ***************** *** M Command *** ***************** Mp - Monitor the packets on port 'p'. You must have the gateway enabled for the port. SYSOP only Command: MM <listfile> <textfile> The MM command does the same thing as the SM command but it uses a text file for the message content. EXAMPLE: MM LIST1 \mb\oscar\amsatnws.140 BBS response: Enter Title for Message: Sysop enters TITLE The bbs will now make messages for each call in the list, but the message content will be from the file AMSATNWS.140. Since the mail file in now in files and not in a database, you could also use a message file instead of a text file for the message content. ( See also Chapter 6 - List file ) Mx <call> <textfile> [<@> <bbscall> <bid>] The 'x' represents the type of message. The 'call' is the TO field of the message. Textfile is the file used; It may include a drive and path information. The 'bbscall' is the BBS field of the message. The 'bid' is the bid attached to the message. EXAMPLE: MP AG3F A:TEXT.TXT @ AG3F The bbs will make a private message to AG3F @ AG3F with the message being from the file TEXT.TXT EXAMPLE: MB ALL A:NEWS.BUL @ PANET $123_NEWS The bbs will make a bulletin to ALL @ PANET with the message being from the file NEWS.BUL with a BID of 123_NEWS. This is handy to make bulletins from a text file to a distribution list. Chapter 4 ------------------- COMMANDS ------------------------------- Page 8 ***************** *** N Command *** ***************** USER only Commands: N NAME -- Enter your name into the user file. NE ------ Makes you an expert user. NH CALL - Enter home bbs into user file. Checks for valid call. NZ ZIP -- Enter zip code into the user file. SYSOP only Commands: N C:\path\FILENAME.OLD FILENAME.NEW Renames filename from old to new. Drive type need not be used unless using other than current drive. Path information is only necessary when going outside current directory. ***************** *** P Command *** ***************** P Call - Lists information about user or bbs. Port connected, name, path, last message number, home bbs. Comments may be added to STATES.MS for reference here. ******************** *** QUIT Command *** ******************** Q - Quits the mailbox. Asks "Are you sure (Y/N)? For local sysop only. ***************** *** R Command *** ***************** R #### - Read message number ####. RH ### - Read message number ###, showing routing headers. RM ----- Read all unread messages addressed to you. ***************** *** S Command *** ***************** Sx CALL @ BBS - Send type 'x' to call @ bbscall. The mailbox will prompt you for title and to enter subject. End message text entry with a <ctrl z>, /ex, or /EX. If type 'x' is not entered, and the TO field is to a valid callsign, the type will become private. If type 'x' is 'A', 'B', 'F' and the TO field is not a valid callsign, (ALL, ect) a BID will be created for the message. SB ALL @ BBS $ARLB010 - Creats a bulletin message to all at bbscall with BID of ARLB010. Chapter 4 ------------------- COMMANDS ------------------------------- Page 9 S! <listfile> - Used by selected users SM <listfile> - Used by SYSOP For Example lets say that all these stations shared the same interests. a message could be made to send to all of them. SM LIST1 <- Entered by sysop BBS response: Enter Title for Message: Sysop enters TITLE BBS response: Enter message, ect... Sysop enters message, ending with a control Z... The bbs now will make the headers for each call in the list. In this Example you would end up with many message headers. Each as defined in the LIST1 file. So many duplicate messages would now be on the bbs. Each will forward out as if they were put on the bbs individually. ( See Chapter 6 - List file ) ***************** *** T Command *** ***************** USER only Commands: T - Chat to the sysop. Any command or return before the request times out will return you to the mailbox. SYSOP only Commands: Tp ---------- Go to terminal mode on port 'p'. Tp Filename - Go to terminal mode on port 'p', and open filename save file. ***************** *** U Command *** ***************** USER only Commands: Ud Filename - Upload filename to subdirectory 'd'. EXAMPLE: UA AMSAT.011 You will be prompted to enter the file <ctrl z> to end. ***************** *** V Command *** ***************** V - Used by ALL Using the "V" command will cause the bbs to print out the current version of the mailbox code. SYSOP only Command: V A:text.txt C:\AMSAT\TEXT.TXT - Copies text.txt from drive A to subdirectory AMSAT on drive C. You can rename ***************** file on copy. *** W Command *** ***************** W -------- Gives a list of subdirectory area's available Wd ------- Gives a list of the files in subdirectory 'd'. Wd *.DOC - Gives a list of *.DOC files in subdirectory 'd'. (For sysop use, drive, path, and filespec can be used.) Chapter 4 ------------------- COMMANDS ------------------------------- Page 10 ***************** *** X Command *** ***************** SYSOP only Commands: X ------- Trigger an auto-forward. XI ------ Auto-forward, ignore time window. X CALL -- Forward only for call. XI CALL - Forward only for call, ignore time window. ***************** *** Y Command *** ***************** SYSOP only Command: YF - Displays present forward file name. YF Filename - Change name of forward file to use. ***************** *** Z Command *** ***************** SYSOP only Commands: Z Filename - Delete the file. Zd Filename - Delete filename in subdirectory 'd'. Z \mb\bbs\TEST.FIL - Deletes TEST.FIL with path \mb\bbs. Chapter 5 ------------------ PRTLOG ---------------------------------- Page 1 ************************ *** PRINTER FUNCTION *** ************************ A print function is now in the software. All you have to do is Hit control P from the bbs menu and everything listed and read will be printed out the parallel port. Use control P to shut the print off when done. Putting the bbs back on-line will also shut the print off. ****************** ***** PRTLOG ***** ****************** PRTLOG -L LOG.MB Will display LOG.MB at the console. PRTLOG LOG.MB > LST: Will put the summery on the printer. --> PRTLOG LOG.MB > LOG.JAN Will output to file LOG.JAN. If you leave out the -L field, only the summary is printed. Note that the BBS will now create a file to hold the BIDs. Each line includes the date that your system received the message with that BID. The proper setup parameters for the tnc are in .SET files, TNC1.SET is for tnc1 or clones - converse mode only, TNC2.SET is for tnc2 or clones, PK232.SET is for the PK-232 and PK-87. The file CONFIG.MB is a text file that contains all site-specific parameters. Edit it to have the proper parameters for your site. The default directory must contain MB.EXE and CONFIG.MB The file CONFIG.MB has sections that specify what ports to use, and where to find various files. Ports are identified by the first letter of the first line of the port information. "A" means COM1, "B" means COM2 etc. "L" means the system console (keyboard and display). Files used by the MailBox. - The Mailbox and Gateway MB.EXE - The program. HELP.MB - The help file. Documents all commands. MBRESTM.EXE - Used to restore the MAIL.DAT file. CONFIG.MB - Configuration data, log-on, error text, ect. INFO.MB - The info file about your system setup. FWD.MB - The routing tables for forwarding messages. STATES.MB - The state hierarchal file. The following files are created and used by the MailBox: MAIL.DAT - The message database. USER.DAT - The user database. MON.MB - The saved "J" lists. LOG.MB - The log file. A text file that contains the user log. Which events are to be logged is specified in CONFIG.MB. CALLS.MB - All calls heard by the MailBox. BID.MB - The file to store the received BIDs in. Chapter 6 -------------- Log, List, & Dis Files ---------------------- Page 1 *** LOG FILE CONTENTS *** Each line in the log file contains an event code, the date and time, followed by further information about the event. 'C' - User connected to system. 'A' -> 'H' - A user connected on that port. 'I' - Program startup. 'L' - User was linked via the station that just connected. 'S' - "connect" from local console (sysop). 'G' - GateWay event. 'A' - Connection attempted and failed. Path shown. 'C' - Connection attempted and obtained. Path shown. 'E' - End of GateWay event, or use. 'M' - Start of monitoring. 'S' - Start of GateWay use. 'U' - Entry to unprotocol mode. 'X' - Exit. 'A' - Owner put MailBox on line. 'B' - User said good bye. 'D' - User disconnected. 'E' - Excluded user attempted connect. 'F' - User forced off by system owner. 'Q' - Owner exited from program. 'T' - Timeout, forced disconnect. 'F' - File event. Command line shown as user entered it. 'M' - Message event. Message number always shown. 'C' - Message copied. 'E' - Message header edited. 'F' - Message forwarded. Connect path shown. 'FE' - End of forwarding session. 'FR' - Start of reverse forwarding within forwarding session. 'FS' - Start of forwarding session. 'K' - Message killed. 'L' - Message headers listed. 'M' - Message created from file. 'R' - Message read. 'S' - Message sent, includes TO, BBS and BID fields *** Distribution File *** The distribution file is a regular ascii file created with a simple editor. It consists of a list of calls, one per line. These calls are the broadcast list of what bbs's you want to get specific messages to. These messages will key the distribution file based on the @ BBB. The name of the distribution file is the same as the @ BBS field used for distribution. All distribution files must end in .DIS and be in the message file directory. EXAMPLE - \mb\msgs\pawest.dis EXAMPLE of a .DIS file: PAWEST.DIS <- Name of file KB3UD W3AVK WA3DQI AG3F Chapter 6 -------------- Log, List, & Dis Files ---------------------- Page 2 Dis File (Continued) When a message is created with a @ BBS of PAWEST, the bbs will create a special second header line. EXAMPLE: Msg# TR Size To From @ BBS Date Title 10651 PN 1949 SYSOP W1AW PAWEST 870511 New News on BBS's cc: KB3UD W3AVK *WA3DQI AG3F Notice that WA3DQI has a "*" before his call. This means that this message has already been forwarded to WA3DQI. As the bbs forwards to the other stations a "*" will appear before each call as the message is forwarded to them. When all the calls have a "*" before them, the message will be killed, if you have a YES in the config file for the line Kill F & B messages after forward. Otherwise, the status of the message will be marked as '$' so that a sysop can see if the message is fully forwarded. Users can not see the '$', only sysops. You are allowed to use a single call in a .Dis file for a single distribution. If a bbs forwards in a message for a distribution which includes his call, a '*' will appear before his call so that the message will not attempt to forward back to him. ***NOTE*** If you receive a distribution which uses a hierarchical routeing designator in the @BBS field, the bbs will forward that message just as it follows your forward file. So a message @CO will for- ward to the bbs that has CO in it's list. This action can be stopped by making a distribution file with it's name.(Like CO.DIS) Include in that file any bbs callsigns for further distribution or the word HOLD to stop any distribution. That way any hierarchical routing will follow your forward lists, and any '@ routing' will take on the calls or hold in your distribution file. *** List file *** A list file is a regular ascii file created with a simple editor. It is used with the MM - Make Multiple Messages from a File, and the SM - Send a message to a distribution list. There are no requirements for the names of these files. They must be in the directory that the mail bbs runs in. EXAMPLE - \mb\list1. EXAMPLE of a list file: LIST1 <- Name of file SP KB3UD @ KB3UD SP AG3F SP AK3P @ AK3P SP N3DQC @ W3AVK A new feature of version 6.2 is that the LOG file is renamed at the end of each month. A new LOG file is then created. The number of month will be appended to the log file name. EXAMPLE: LOG.MB will become LOG3.MB for the month of March. Chapter 7 ------------------- PROTOCOLS ------------------------------ Page 1 "BBS" FORWARDING PROTOCOL NOTES The following is an attempt to put down in detail what the "CBBS" MailBox expects as user input, and the variations that will be accepted by the MailBox code. Forwarding works by the simple means of the forwarding MailBox acting as if it were a user of the target MailBox. Thus, it will use the "S" command to enter the message, in exactly the same way that a user does. The "S" command takes the form: "S"["x"] TO ["@" BBS] ["<" FROM] [$#####_K3KKK] ["@" BBS.ST.USA.NA] <-- Hierarchical route. The "x" is an optional message type character. The fields are delimited by any number of spaces or tabs. Upper case or lower case may be used. TO, BBS, and FROM may be up to six characters. If a trailing "-" and ssid are given, it is thrown away. The "@ BBS" and "< FROM" fields are optional, and may occur in any of the 4 possible combinations. The '$' is not part of the BID, but identifies the field. There is no space between the $ and the BID. After receiving the "S" command, the MailBox prompts for message title. The prompt is on one line, ending with CR. The message title is one line, ending with CR. The title is truncated to 80 characters by the MailBox. After receiving the message title, the MailBox prompts for the message text. The prompt is on one line, ending with CR. Message text is a string of ASCII characters, ending in control-z. The station doing the forwarding simply disconnects once it has passed all of its messages. Note that the MailBox prompt is identified by it's terminating ">". Starting with Version 4.4, the C BBS also supports the use of BIDs (Bulletin Identifiers) and to use them, it will, when it recognizes a similarly programmed BBS, enter into an exchange with said BBS. This is according to the protocol developed by WA7MBL. A BID capable BBS is recognized by its sending a field beginning with a '[' and ending with a ']'. In addition, in the field is at least one '-'. Anything following the LAST '-' is taken to identify features available on that BBS. The exchange from this BBS is: [CBBS-6.71-H$] When the BBS is connected to, it sends [CBBS-$],and if it receives [anything-$], it goes into its MBL-like mode. It then gives you a prompt and waits for your next Send command. If you receive something like S ALL $BID001, it checks to see whether it has received this BID before. If not, it sends OK - 1234: (will be message #1234) To which the sender then sends the title followed immediately by the message text. If it has that BID, it will send: NO- Already have it: And then give a new '>' And the distant BBS will then proceed to the next message. Chapter 7 ------------------- PROTOCOLS ------------------------------ Page 2 BID Protocol (Continued) Whether the connecting station is a BBS or not, if a message comes in addressed to something other than a real callsign, and is of TYPE B it is assigned a BID by a parsing routine. It finds the BBS of origin, and the message number on that BBS, and gives it a BID based on MSG#_BBSCALL ... It will then check the BID file and if the message is present, it will mark it hold pending operator intervention (presumably you already forwarded the message. This works with any system that has the terminal -$ in its [-$] field. The BID.MB file is an ascii text file, with one BID per line. It can be edited to add or delete BID's as the sysop sees fit. It is this BID that determine if a message with a bid is accepted or not. System IDentifiers (SIDs) - W0RLI The initial exchange between "smart" BBS systems uses what is called an "SID", short for System IDentifier. All future work on BBS systems should adopt this standard. It will help to remove a GREAT deal of confusion as to which systems have what features, and how one should interface to them. In the longer future, perhaps all this junk can be done away with, and the computers can talk to each other in a more natural way. The system identifier is structured: "[f1-f2-f3]" The dashes delimit the end of the first field and the start of the last. There might be only one dash, if f2 is void. f2 may contain dashes. f1, f2, and f3 may not contain "[" or "]". f1 is the author identification. It may not contain a dash. Normally it will contain a few characters from the authors callsign. f2 is author specific data. It may contain anything the author wishes, for example software version. It may contain dashes. f3 is the supported feature set. It may not contain a dash. It contains a string of non-numeric characters, one for each negotiable feature supported. Each character may also have trailing digits, giving the revision of that feature. If there is no trailing digit, the feature revision is revision zero. Coding hint: if the first line seen at connect to the bbs starts with [ and ends with ], then it probably is an SID. For example: f1_start = fld + 1; f1_end = strchr(fld, '-') - 1; f2_start = f1end + 2; f2_end = strrchr(fld, '-') + 1; f3_start = f2_end + 2; f3_end = strrchr(fld, ']') - 1; Chapter 7 ------------------- PROTOCOLS ----------------------------- Page 3 Sid's (Continued) Defined features are: C - Supports "forwarding" of date and time. H - Supports Hierarchical forwarding. M - Supports Message Identifiers. W - Is a white pages server. (We were thinking about you, Eric!) Y - Supports YAPP binary protocol. $ - Supports BID. MUST BE LAST CHARACTER IN f3 (downward compatibility). The existance of the system ID also implies that the system supports reverse forwarding and OK/NO message rejection. Some examples of existing standard system identifiers: [RLI-6.08-CM$] - w0rli version 6.08, supports Clock, MID, BID [CBBS-$] - CBBS flavor, supports BID. [CBBS-6.7-H$] - CBBS source versions, supports BID, Hierarchical. [CBBS-4.5-$] - ve3gyq release of the rli/gyq cbbs. [MBL-$] - wa7mbl version unknown, supports BID [PRMBS-.98X-345-$] - ka2bqe rip-off of w0rli cbbs V0.4 [4RE-01-M$] - aa4re V1, supports MID and BID. There is some older code still running that requires special case handling. In these cases there is no f3 or feature letters. Rule: OK/NO message rejection is required, and BID is supported. [MBL320] - "old" wa7mbl systems. [MBL=RLI] - ja0isk port of rli/gyq cbbs for NEC 9800 The connect rules: Send the SID as first line at connect. Answer the SID (when seen as a command) with a short command prompt. The fowarding rules: If you do not see an SID at connect, use the old style fowarding. This handles the case of Xerox 820 systems, for example. If you do see an SID at connect, answer with your SID. Use whatever features are appropriate. Special case: MBL3 or MBL= seen at connect. Reply with [MBL-xxx], where xxx is anything you like. Continue with reverse forwarding and OK/NO message rejection. Zip Code Routing Note 1 - W0RLI - 7 Sept 87 Several people have suggested using zip codes for routing identifiers. There are many possible ways to do this. In this note I outline two suggestions. These two routing schemes are compatible, and can co-exist on the network at the same time. Two features are required in the BBS code to support these routing schemes properly: wildcard capability in the route table destinations and "@ BBS" replacement. Either of these schemes will help users: they no longer need to know the callsigns of all the BBS in the world. Users need only know the state, province, region, or zip code of the message destination. Chapter 7 ------------------- PROTOCOLS ----------------------------- Page 4 Zip Routing (Continued) 1) Zip code routing for NTS traffic. Use the form "ST nnnnn @ NTSxx" where nnnnn is the destination zip code and xx is the state, province, or region identifier. In route tables far from "xx" only the path toward "xx" need be known. Once the message reaches "xx" the receiving BBS should remove the "@ BBS" designator. Routing will then continue using the zip code. 2) Zip code routing to humans. Use the form "SP call @ zip" or "SP call @ xx". These forms are not ideal. What should be used is a form with 3 address fields. None of the BBS codes support this yet. The ideal form for routing of personal messages is "SP call @ zip @ xx". This routing scheme then would follow the NTS routing scheme in 1). Since we do not have a three adress scheme, the first and second forms in 2) would be the best available. Some examples of routings that could work now: ST 95060 @ NTSCA This message would end up at kb6irs or n6iya for delivery by NTS. SP W0RLI @ NTSCA This message would go to any of the eight California HF BBS. At the California HF BBS the "@ NTSCA" would be removed and routing would continue in the normal manner to W0RLI. SP VE3FXB @ NTSON The same idea as the previous message. SP VK2AHX @ VK Again, the same idea. Note that stations that do not have a path to VK need only keep the single identifier "VK" in their route tables. SP W0RLI @ 95060 With schemes like this, and the use of wildcards in the route tables and "@ BBS" replacement tables, only a very few identifiers are required to cover the entire U.S. If this message had originated, for example, in New England, the BBS in New England need only have "9*" in it's route table. Once the message reached, for example, KD6SQ, he would have to have several identifiers. "95*" would send the message from So. Cal. to No. Cal., where the "@ BBS" would be removed. It would then be forwarded directly to W0RLI, since W0RLI is known to all BBS in No. Cal. *** MESSAGES *** There are three types of messages: 1) Personal. If sent with SP, or with S and to a callsign. 2) NTS Traffic If sent with ST. 3) Bulletins If sent with SB, or with S and NOT to a callsign. A BID is included with the message. Chapter 7 ------------------- PROTOCOLS ----------------------------- Page 5 Each type of message gets somewhat different handling: For NTS traffic, the LT, KT, and ET commands are active. For Bulletins, a BID is sent when forwarding to accepted bbs's. For Personal, The message can only be read by the sender, addressee, and sysop. There are several "flags" associated with each message. These are shown in the "message status" position in the "list message" display. Note that each Flag has an associated "L" command and some have associated "K" commands. B - The "Busy" or "Bad" flag: This indicates that a message is busy. Also indicates all duplicate bids and disconnects before message is completed. F - The "Forwarded" flag: This indicates the message has been forwarded to it's destinations, but has not been killed. H - The "Hold" flag: This indicates the message has been held. It will not forward, and can be only killed by the sysop. O - The "Stale" flag: This indicates a message has been around for too long. Time length is determined in the config.mb Y - The "Read" flag: This indicates that the message has been read by the addressee, but has not yet been killed. $ - The "Bulletin" flag: This indicates that the bulletin will be marked stale or killed after the last test. No user read check. Only visible to sysop. Message header formats in use at this time include: R:date/timez @:call qth #:nnn O:call S:date/time Z:zzz R:date/timez @:call qth #:nnn O:call S:date/time R:date/timez @:call qth #:nnn O:call Z:zzz R:date/timez @:call qth #:nnn Z:zzz R:date/timez @:call qth #:nnn O:call R:date/timez @:call qth #nnn O:call R:date/timez nnn@call [qth] Z:zzz <--- Best one to use. 1) calls may have ssid 2) time may have timezone. If so, may be single char or 3 char. May be upper or lower case, or mixed. 3) qth may be enclosed in [] 4) Space between @ call and qth may be missing 5) ":" between field ID and contents may be missing. 6) May be space between ":" and field contents. There are many other forms seen. They may leave out required information. They may have the required information in unexpected format. There is little chance of parsing them all, and no reason to do so. Chapter 8 ------------------- DESQVIEW ------------------------------- Page 1 SETTING UP MULTIPLE BBS'S WITH DESQVIEW - AG3F 1. CONFIG.SYS Create file config.sys in the root (\) directory with an editor. As a minimum it it must contain the files and buffers statements. Other possible additions are a ram disk and the driver for any installed EEMS boards. DESQview will run with the normal 640K system memory but you will be very limited as to the size and number of programs you will be able to use in addition to the BBS copies. The following is the config.sys in use at AG3F where an AST SixPakPremium EEMS multifunction with 1 meg of memory is installed in addition to 256k of motherboard memory. files=30 buffers=20 stacks=9,128 device=remm.sys /x=A000-BFFF device=fastdisk.sys /m=64 /dextm 2. INSTALLING DESQVIEW Install DESQview V2.01 or later on the hard drive by using Quarterdeck's instructions. In general this will involve placing the distribution diskette in floppy drive "A" and typing install. You will be prompted for the desired destination drive and for your system configuration. This process will create a \DV directory on the hard drive that will include all of the necessary DESQviev files. Any commercial programs that are known to DESQview and were residing on your hard drive will also be installed for access from DESQview. At this point install any other programs you desire by using the DESQview instructions. It is suggested that you run these programs from DESQview and become familiar with DESQview operation. 3. DESQVIEW PARAMETERS From the > prompt in subdirectory DV type SETUP. This will bring up the DESQview setup screen. Select the advanced setup and when in that window select performance option. Change the number of clock ticks to 7 for foreground and background programs. Experimentation has shown for a 4mhz xt 7 is suitable. If you utilize other clock speeds you may have to experiment to find the best value but in any case both foreground and background operations must be the same since running multiple copies of the bbs really does not have a background program. The other parameters available for modification were left at their default values. 4. SUBDIRECTORIES Setup the directory/subdirectory system for the mailboxes. The config's must be different for each window used. The files LOG, MON, and CALLS must be different for each window. It is easier to just use the port letter as the .ext of each of these files. The MAIL.DAT and USER.DAT are shared by all the windows. The FWD file can be a common file or you can use different files for each port. Chapter 8 ------------------- DESQVIEW ------------------------------- Page 2 Subdirectories Continued) \mb mb.exe br3bios.com mbmode.exe hand.com config.a ------ config.b ------ config.c \mb\bbs help.mb info.mb user.dat user.bak fwd.mb states.mb mail.dat mail.bak mon.a --------- mon.b --------- mon.c calls.a ------- calls.b ------- calls.c log.a --------- log.b --------- log.c \mb\msgs 6. ADDING THE BBS PROGRAM TO DESQVIEW Add the bbs programs to DESQview by selecting add program from second menu. Following the prompts add the following information: program name bbs1 memory size 103 program mb or 150 if using dos commands parameters config.a <-- config file used. directory c:\mb options: Writes to screen [n] Displays graphics [n] Virualize text [n] Uses serial ports [n] Requires floppy [n] TO SELECT ADVANCED OPTIONS HIT (F1) Close on exit [Y] Own colors [n] Allow close window [Y] Runs in back [Y] Math coprocessor [n] Kbd conflict [1] Share cpu [Y] Share ega [n] Can be swapped [n] Protection [0] All other parameters are as default. Add the second and subsequent copies of the bbs as above using the proper program names and directorys. Chapter 8 ------------------- DESQVIEW ------------------------------- Page 3 7. PORT INITIALIZATION Construct a batch file to execute the necessary port initializations as described previously. The one in use at AG3F resides in the root directory of drive c: and is called startbbs.bat. It is as follows: cd \mb Notes: share /F:2048 /L:64 br3bios 3 ports are used, BR3BIOS is configured mbmode com1:48,n,8,1 for 3 com ports. Hand is required to mbmode com2:48,n,8,1 handshake between DESQview windows. mbmode com3:48,n,8,1 FASTOPEN (Dos v3.3) permits quicker disk hand access. cd \dv fastopen c: dv 8. CONFIGURATIONS Prepare a config.x for each copy of the bbs. 9. STARTING THE BBS MANUALLY From the dos prompt type STARTBBS or what ever you called your port initialization batch file. This will load the bios drivers, run mode on all ports, load pipe, run any other special programs and finally invoke DESQview. You will now be at the open window menu of DESQview. Select open and then the first bbs program. Program #1 will start and occupy the upper 1/2 of the screen. Do the same with copy #2 which will be in the lower 1/2 of the screen. Other copies can be loaded similiarly and will occupy screen locations defined in the DV setup. Now all is running simultaneously. You can switch, zoom, blank or select other windows without interrupting the bbs activity. 10. AUTOMATIC STARTUP If desired you may arrange the system to reboot and restart up the bbs's if the computer is shut off or experiances a power outage. This requires two steps. a. Insert the name of your initialization batch file into your autoexec.bat file. b. Create a DESQview autostart macro. This is done by assigning a series of key strokes to the ! key while in DESQview but without any application program running. Follow the learn instructions in your DESQview manual. The steps for a 2 bbs seup typically would be: Type DV to start DESQview shift-alt (select start learn,indicate the ! key and pick name) open window open bbs#1 shift-alt (select time delay 30 ) open window open bbs#2 shift-alt (select end learn) quit DESQview and say yes to save scripts Chapter 8 ------------------- DESQVIEQ ------------------------------- Page 4 The script file produced by the above is desqview.dvs and will be found in the Dv directory. This file can be made man readable by using the program convscr.com provided with DV. A converted program would look like the following: {Learn ! "boot boards"} om1{Delay 30}{DESQ}om2 {Finish} o means open m1 is my 1st bbs program m2 is my 2nd bbs program Learn and Finish are the start and end of the learn commands. You can if desired, create a text file like the above, and by the use of convscr convert it to desqview.dvs and eliminate the step by step procedure described above. 11. USING DESQVEIW WITH THE BBS When you are not using the console for watching the bbs, you might want to hide the windows before you shut it down. To do this you just hit the 'ALT' key, then 'R' for rearrange, then 'H' for hide. This will blank out the window. Doing this for all windows before shutting off the console will speed DESQview up as no display is taking place. To get things back after turning on the console, just hit the 'ALT" key and then the number key for each window. Chapter 9 -------------------- MODEM USAGE --------------------------- Page 1 ******************* *** MODEM USAGE *** ******************* A modem port can be configured for access to the bbs. It can be configured to a port in a non DESQview system, or it can be configured to a port in a DESQview window that also services one or more TNCs or it can be configured in a DESQview window by itself. The last case is the best choice since it guarantees that the bbs will not be busy when you call. Even though other windows may be in use it is still possible to access the messages because of the common mail file. This same window can also be used from the local keyboard to permit access to the messages without blocking users or forwarding. The modem must be set up for "quiet" automatic answer at the de- sired baud rate before it is connected to the bbs software. Any of the standard terminal programs can be used to perform this set up. It is important that the modem be able to come up in the proper mode following a power failure. Most current Hayes com- patible modems have a non-volatile memory to store their parame- ters. Earlier versions used dip switches. The important parame- ters are: E0 disable echo of commands S0=n n is the number of rings before the modem answers Q1 disable result codes &C1 data carrier detect (DCD) only when carrier present &D2 data terminal ready (DTR) required for modem to answer There is no intelligence in the software to issue commands to the modem. Check your modem manual for instructions on setting the modem to automatic answer "dumb" mode. The DCD line is the most important. If the bbs software detects loss of DCD, it will react the same as for a disconnect from a TNC. The modem port must be initialized by MBMODE the same as for the TNC ports. No provision is made for baud rate switching in the software. The port definition line in config.mb must have E (port requires echo), L (line feed after carriage return), and S (raw serial port) specified. T (TNC with TAPR commands) must NOT be specified. The other codes may be set as desired although the I (kick off user with illegal call) code is strongly recommend to help thwart anyone who might stumble across your auto answer modem. A high ring count is also a good idea. It is not a good idea to let users connect to your system via the modem port. The software for the serial port would have to be made much more "bullet" proof for this to be feasible. Remote control of the bbs is the main use for a modem port. Chapter 9 --------------------- MODEM USAGE ------------------------- Page 2 (Continued) Now for the secret that I had to study the code to determine. You call in to the modem and it answers and absolutely nothing happens. You must type the exact string that a TNC would send when a connection is made including a valid call sign. An SSID different from what you use on the TNC ports makes it easier to keep track of modem connections. The string you must send is: *** CONNECTED to WA3TSW-1 followed by a carriage return. Obviously you use your own call. If the I parameter is set and the call sign is not valid, there will not be any response. At this point you will receive the same introduction and prompts that would occur if you connected via a TNC. Operation of the bbs is identical to connection via a TNC port. When you are done you can simply hang up. The modem will detect loss of carrier and drop the DCD line. The software will react the same as if a TNC user disconnected instead of using the B command. You can use the B command before hanging up but there will be no response to indicate that anything is hap- pening. Thanks to WA3TSW for this info on modem operation. Chapter 10 ------------------ MBRESTM -------------------------------- Page 1 *** USING MBRESTM.EXE *** Restoring a crashed mail.dat file is now easy to do. With version 5.0 and later versions, an invisible header is now put into each message text file. That is, invisible to the bbs. So all that is needed to restore MAIL.DAT is the message text files. Even if some of these files are bad, you can still reconstruct a mail.dat file with the files that you still have. To run the restore program, place MBRESTM.EXE in the same subdirectory as the message files, and then type MBRESTM. It will check for message files, check for the inbedded header information, then sort the message files, and finally creat a new MAIL.DAT in the same directory. You will also be told what the next message number is, and asked if you want to change it. Now all you have to do is place the NEW MAIL.DAT file in the proper subdirectory using copy, and the bbs is now ready to be loaded with a reconstructed mail file. MBRESTM with a single argument (MBRESTM X) will now run automatic- ally with no operator intervention. MAIL.DAT -- mail file header format 1-2 2 NEXT Next record to allocate, binary (LAST+1) 3-4 2 FIRST First msg header record, binary (always 1) 5-6 2 LAST Last msg header record, binary (COUNT) 7-8 2 NEXTM Next msg number, binary 9-10 2 UNTMSG Next msg at last untangle, binary 11 1 VERSION Mail file version, binary 12-13 2 SPARE Unused 14-15 2 COUNT Number of messages, binary 16-21 6 DATE Date of last untangle YYMMDD 22-25 4 TIME Time of last untangle HHMM 26-256 231 unused, filled with nulls MAIL.DAT -- typical message entry format 1 1 EXT Header extension flag or zero 2-3 2 RN Record number 4-5 2 READ Times read in binary 6-7 2 NUMBER Message number in binary 8-9 2 SIZE Message size in binary 10 1 TYPE Message type (Ascii) 11 1 ST Status (01 read, 02 fwded, 04 kill, 08 busy) (10 unused, 20 old, 40 hold, 80 bulletin) 12-17 6 TO To, trailing spaces 18-23 6 FROM From, trailing spaces 26-29 6 BBS BBS, trailing spaces 30-35 6 DATE Date YYMMDD 36-39 4 TIME Time HHMM 40-51 12 BID BID, trailing NULLS 52-131 80 SUBJECT Msg title with trailing NULLS 132-227 96 CALL DIS routing, max 16 calls, 6 chars each 228-243 16 FLAG DIS routing, binary 1 unforwarded, otherwise 0 244 1 COUNT Number of calls in DIS list, binary 245-250 6 FCALL Callsign of bbs message forwarded to Chapter 10 ----------------- MAIL FORMAT ----------------------------- Page 2 INDIVIDUAL MESSAGE FILE HEADER FORMAT All 256 bytes are filled with nulls to start with and then replaced with the appropriate values. Only the area trailing the message title is left as nulls. Everything except those nulls are ascii. Nothing is left as binary data. All fields are completely filled with the contents of the variable assigned to that area. If the contents are not big enough to fill the field the extra area is filled by leading or trailing spaces (hex 20). POSITION SIZE VARIABLE CONTENT 1-5 5 NUMBER Message NUMBER in ascii, leading spaces 6 1 space 7 1 TYPE Message TYPE 8 1 ST STATUS 9 1 space 10-14 5 SIZE Message SIZE in ascii, leading spaces 15 1 space 16-21 6 TO TO, trailing spaces 22 1 space 23-28 6 FROM FROM, trailing spaces 29 1 space 30-35 6 BBS BBS, trailing spaces 36 1 space 37-42 6 DATE DATE YYMMDD 43 1 space 44-47 4 TIME TIME HHMM 48 1 space 49-60 12 BID BID, trailing spaces 61 1 space 62-66 5 READ Times READ in ascii, leading spaces 67 1 CR 68 1 LF 69 1 EXT Extension FLAG, 0 = cc line absent, 1 = cc line exists 2 = Hierarchical list 70 1 space 71-86 16 FLAGS cc line flags each corresponding to a line in the DIS file that matches the @BBS field. 0 = we have fowarded to this station 1 = we have not fowarded. If we don't have a cc line, these are 16 spaces. 71-XX XX HLIST With EXT = 2 This contains the hierarchical list. XX 1 CR XX 1 LF XX-XX 82 SUBJECT Message TITLE (80 max), then CRLF XX-254 84 NULLS 255 1 CR 256 1 LF Thanks to AG3F in helping iron out some of the mysteries of this. Chapter 10 --------------- LISTING MESSAGES -------------------------- Page 3 (Revision A) WORKING WITH THE MAIL FILE There are many ways to list messages in the mail file for the sysop. The common method is to just do a "L" every time you log into the bbs. This will list all messages active on the bbs since your last login. A better method is to use the "LE" command which will list ALL messages (active messages, killed messages, duplicate bid headers, and disconnect-timeout headers). In other words, all message numbers in serial fashion, since your last login. Also available to the sysop is the "LU" command. This will list all messages not yet forwarded, and messages to your local users. It does not list bulletins and gives the sysop an idea as to how the bbs is performing on forwards. You can also get a quick view of messages addressed to bbs's not in your forward file and make the necessary corrections to it. A feature not commonly used is the adding of the ";" as the second or third field of list commands. The example - "LE ;" will list exactly like the "LE" except extra lines will appear containing the BID, if any, and the HIERARCHICAL ROUTE. Not all messages have bids and, right now, few will have any hierarchical route, but the the listing is available to the sysop. Common listings available to users are also usable to the sysop. Examples such as "LA" to list all type A messages, "LB" to list all bulletins, "LM" to list all your own messages, "LY" to list all messages that have been read, "LO" to list messages the are stale, "LK" to list messages that have been killed, "L@ (call), "L> (call), and "L< (call) add more selectivity to the listing. *** HOLD MESSAGES *** The "LH" command lists all messages that are being held. These messages are marked hold so that the sysop can act upon them by using the edit message command. If any call in the hold calls list in the config file matches the TO, FROM, or BBS of a message it will be marked as hold. Another example is if a message is received without a bid, and has a distribution call in the bbs field. You cannot distribute a message without a bid attached to that message. A message is also put on hold if the bbs finds your header with your call in it, meaning that your bbs had the message before. (Ping-Ponging) This is set by a config option. There are many other varations available to the sysop. Most of the two letter commands can also take a number after them. "LE 10" will list the last ten messages. But probably the most useful commands are the "LE" and "LU" which show what messages you have received and what has yet to forward. Additional info may be found by looking at the "L COMMAND" in chapter 4, and MESSAGES in chapter 7. Chapter 11 -------------- ARCHIVE MESSAGES --------------------------- Page 1 ARCHIVING MESSAGES The CBBS code now handles a new method of saving KILLED messages If a sysop wants to save all killed mail, the the only thing he has to do is create a subdirectory called "KILL" in the messages subdirectory. If he wants to save all nts messages, then he makes a subdirectory called "NTS". For saving all mail either to or from the sysop, he then makes a subdirectory with his call. (e.g. K3RLI) You can also make special subdirectories with classifications of any @BBS field, such as, RLIBBS, MBLBBS, ALLPA, ect. You can use as many subdirectories as you want, and related classes of mail will be archived into them. So, if you are a traffic manager, and your only interest is in saving traffic and service messages, then you only need create a subdirectory of "NTS". If you are only interested in saving any dialogue between you and other users, then you create a subdirectory with your call sign. All of these subdirectories are made in the MSGS subdirectory. Another feature is that in each of these subdirectories, a file called INDEX is created. This file will contain the headers of all the message files archived. As you add more message files to the subdirectory, INDEX will have the new headers appended to it in serial fashion. So you will have an INDEX file of all the message files in the corresponding subdirectory. All the archived files, including the INDEX file are text files, and as such, can be edited with any text editor. You can also copy all the files from a subdirectory to a floppy, then delete all the files in that subdirectory and start over. That way the floppy will contain all the archived message files and their corresponding index file. If you create a subdirectory called BUSY, all incomplete messages caused by a timeout or disconnect will be put in it. The index file from this subdirectory might be handy to see how some of the paths reflect the quality of forwarding. Poor paths usually mean more timeouts and disconnects. Be sure you check the archived messages as you can fill up the the disk quite easily on an active bbs. A floppy can hold about 111 - 112 directory entries, and will display an error once that limit is reached. So you might copy the files off the bbs before that limit is reached. Another method is to copy the INDEX to a floppy, and then use PKARC to archive the messages to an archive file. [\PKARC -a A:MESSAGES.ARC \MB\MSGS\K3RLI *.* ] and then delete the the subdirectory files. A new feature has been added to allow you to kill a message and NOT allow it to be archived. You use the KA <message #> to kill the message and it will not be archived during the GM. Chapter 12 -------------------- MAINTENANCE -------------------------- Page 1 SYSOP MAINTENANCE The bbs if setup properly will maintain itself quite nicely with little sysop intervention. With YES in the config line to KILL on forward, all forwarded mail will be killed. With NO in the config line to KILL F & B type messages, bulletins will NOT be killed on forward. The mail will not be deleted from the mail file until a mail file compress is done. This can be done automatically by having YES <hour> in the config on the line for compressing the mail file. The <hour> being what hour of the day for the file compress to take place. Other spots for consideration are the lines in the config controlling stale or old mail. The first concerns Bulletin type mail. You enter the number of days before a Bulletin will be marked as stale "O", or, if YES follows the number of days, the Bulletin will be killed. The second line concerns Traffic mail, and the third, Personal mail. These lines should look something like this: 45 YES <----- Kill Bulletins after 45 days. 7 NO <----- Mark Traffic stale after 7 days. 14 YES <----- Kill Personal mail after 14 days. If you wish to keep a bulletin from being killed automatically after the set number of days, you must, at some time, edit that bulletin and change the status to hold "H". This way the bulletin will never be killed until you change the status back to normal. The Bid file requires maintenance, as Bid's are not deleted from this file. The sysop must delete old bids to keep the file from getting too large, and also at least once a year, so old annual bids are removed. A good time to delete some of the bids is probably quarterly. Version 6.2 of the bbs will now end the log file at the end of each month. The log file will be renamed to include the number of the month in the log file. Version 6.4 of the bbs will now add a hierarchical route to all incoming messages which have the bbs field with a call listed in the STATES.MB file. So all you will need in the forward file is a list of states and local bbs's that you forward to. You can add to the STATES.MB file any routes you think will be necessary. Use STATES.EXE to make STATES.MB from the latest W9ZRX bbs list. You can also add special routes like WA7SSO.#WPA.USA.NA with #WPA in your forward file. Comments can be added to the STATES.MB file so that users can lookup any bbs with the 'P' Command. As time progresses, the disk will become fragamented. This will cause the bbs operations to slow up a bit. A good choice at this time is to backup the entire disk, and run one of the disk optimizers to place the disk file system back in smooth order. After that's done, just reload the bbs. Again, quarterly is the best time. Appendix A ------------------ CHANGES -------------------------------- Page 1 Changes from 4.4 to V4.51 Starting 2/18/88 Removed the pause message whenever the printer is toggled on. Log file now logs @bbs field in message entries. Log file now logs local message entries. Password routine added to insure security of remote sysop. Fixed bug in gate: Allowed users to use gateway when G not in config. Alternate display of tnc cmds when 123 not in config. Shows port letter as upper case if normal, and lower case if timeout on cmd:. Forward timeout field now in port config line. Allows time for tnc to flush out it's buffer on timeout before starting next connect. Single header line when using pipe between multiple bbs's. Changes from V4.51 to V4.52 Starting 3/3/88 Fixed bug in Edit message to add bid to BID file with blank BID. Printer now shut off when sysop goes BYE. Now only messages with no type to a legal callsign become private. Log file now logs Make type messages. ":"'s added after Ok and No responses for uniformity. User record is updated with next message number only if user does 'L'. Added "Are you sure?" to Quit and Untangle commands. Changes from V4.53 to V4.6 10 Starting 6/10/88 Fixed bug with timeout in forwarding. New edit message & edit user format for sysop. Transparent mode now changed from edit port parameter. Message without a bid at a distribution list put on hold. Added Zip to white paper for consistency. Fwdcmd now replies done when done for consistency. Now match Conn or Disc anywhere in received line. Fixed minor bug on DOS operations. Received scripts now can be partially matched. Waitcmd time now set correctly if using DesqView. Check for [...] only for first response on connect. Bulletins now considered like type F messages on forwarding. Fixed minor bug for bid check in SM and MM commands. Fixed generated bid in WP and Service messages. Placed tnc in converse mode when sysop talks to user. Corrected bugs in transparent mode operation. Corrected long standing loging bug. Made message auto-BID's 12345_K3XXX for consistency. Added NEW DESQview and DoubleDOS flags in config. Forwarded traffic not shown to users. Stopped *** Invalid Command from other bbs causing messages to be lost. Clsmon done at forwarding time. Fixed bugs in remote sysop using pipes. Changes to V4.6 to V4.6+ Starting 7/24/1988 [...] in prompt lines does not reset sid options. Added eat in dorev to pick up ending prompt bug. Dos commands not done on force forward. Fixed remote sysop operations to work properly in trans mode & pipes. Changed %d to %u for counting of messages above 32k. Better handling of distribution calls in edmsg. Switching from converse to transparent mode handled better. Misc. small errors corrected. Appendix A ----------------- CHANGES --------------------------------- Page 2 (Continued) Changes from V4.6+ to V5.0 Starting 10/9/1988 Multiuser version using one common mail file between windows Version 9 mail file structure. Added voids to list headers for duplicate bids and disconnects. Added MBIBM functions for handshaking thru HAND. Added A and AI for forwarding on all windows by sysop. Added setbusy and clearbusy and auto GM for mail compress. Changes from V5.0 to 5.1 Starting 11/11/1988 Added LOCK function and deleted pipe functions. No beacon if the calls for BT is set at 1. Deleted p_memory and DoubleDos references. Changes from V5.1 to 5.11 Starting 11/30/1988 Fixed parsehd() for some non-standard headers from other bbs code. Deleted phead and replaced with parsehd. Reverse forward does not need port->id match. Fixed scripts left after Case E forwarding. Disconnect now stops file and message dump to tnc. String defined wrong in puser. Changes from V5.11 to V5.2 Starting 1/05/1989 Added message archiving by subdirectory on GM. Fixed readusr to handle GU's. Filter control characters from title. Fix blank line from BBSMSG ON on retry out exceeded. Removed unnecessary logging in forward. Added LU command for listing of unforwarded mail. @ sub-forward files can now be timed. Speeded up forwarding using @ sub files. Changes from V5.2 to 6.0 Starting 2/05/1989 Added H to sid for hierarchical forwarding. Fixed reversing forwarding of same bulletin back to bbs in .DIS list. Inbedded header now supports hierarchical list. Edit message and edit traffic supports hierarchical list. New MBRESTM code to handle restoring hierarchical list. Added bid to archived messages. Fixed page check for added lines in headers. Fixed bug in forward to PBBX mailboxes. Quit now clears window busy flag. Fixed some serial port bugs. H status mail now listed with higher priority. Actual bid now shown in busy header with sender's call, also in log. Changed format and entry of edit port, edit system. Fixed busy call being added to beacon text. Added YF display of forward file name. Corrected WP file update, and bulletin bid check. Appendix A ----------------- CHANGES --------------------------------- Page 3 (Continued) Changes from 6.0 to 6.2 Starting 4/10/1989 Revised parsing routine for send line xxxxx@yyyyy. Added KA to kill mail but NOT archive. Fixed minor bug on DW and KT generation. Added '$' status for fully forwarded distribution. Now auto-kill of stale messages from config option. Fixed dos command operation on manual forward. Log entry for start and quit of bbs. Log file now changes at end of month, with new log file created. Changes from 6.2 to 6.4 Starting 5/15/1989 Shpaths set up now for 40 or 80 column display. (Commodore users) Automatic hierarchical routing using a modified W9ZRX's state file. Added Read column to message listings. In normal listing of messages a '*' indicates a hierarchical route used. Edit message now uses STATES.MB for hierarchical route. Changes from 6.4 to 6.5 Starting 10/10/1989 Wild-cards now allowed in STATES.MB for hierarchical routes. Small bug fixed using hierarchical server. Fix for WP server to use hierarchical server. Truncated title line for sysop listings. ";" overides. Code now uses about 2k less memory. Local listing now pages. New varable for *vers. Kill multiple messages for sysop. Up to 4 messages. Adjusted parsehd for message numbers. Small revision in puser and shpaths. Allowed revision numbers to be used in SID. Sysop doing RM now sees headers. P command now searches STATES.MB for bbs address and comments. Changes from 6.5 to 6.6 Starting 2/10/1990 Message size can be limited on forwarding "<>0312 XXXX". Unique BID and internal header BID are stored together in BID file. Fixed small bug in MBRESTM for busy's. Added check for graphic character in To field. Small change on parsing of internal headers. Held bulletins not seen by users. Send-multiple (S!) allowed for users Change in the parsing of headers; Now done when message is received. Mail with your header in it now put on hold. (Ping-pong) Forward file used can be changed from forward file. Special wild-card '!' matches any digit only. Changes from 6.6 to 6.7 Starting 8/20/1990 Disconnected busy message text corrected. Disconnect in lstmsg now halts dump of messages. Must use valid callsign for homebbs. RM doesn't show killed messages. Forward bbs now shown in list headers. Fixed small bug in listing of messages by sysop. Hold of ping-pong messages now config param. New method of smart bbs handshaking used. Small bug in MBRESTM corrected for runumbered messages. (1) New Bulletin purging routine. Appendix B ------------------ CONFIG.MB ------------------------------ Page 1 SAMPLE CONFIG.MB for single port: A123UDTIX 360 20 600 100 10 2 53 6 15 -> 145.01 Mhz. LCUDE 300 10 600 100 10 0 53 8 15 -> Stations Connected *** EOF ADU C:\oscar\ --> Amsat / Oscar BDU C:\files\ --> General information CDU C:\cuser\ --> Commadore 64 Users DDU C:\nts\ --> NTS \ ARES / RACES FDU C:\arrl\ --> ARRL / W5YI Material HDU C:\hamfest\ --> Hamfests and Related EVENTS MDU C:\map\ --> Packet MAPS NDU C:\net\ --> Net/Rom Information *** EOF K3RLI ALLBBS DUMP ALLUSA DUMP ARL ARL AMSAT AMSAT *** EOF hold *** EOF Hello $I, Welcome to the $O MailBox from $W in $Q Last logged at $Y on $X. Type H for help, L to list new messages. *** EOF $O> $D/$T, $L, $N msgs>$H $U de $O: at $Tz on $D ?,B,C,D,H,I,J,K,L,M,N,P,R,S,T,U,V,W > K3RLI Wilkes-Barre AD8I \mb\HELP.MB \mb\INFO.MB \mb\bbs\FWD.MB \mb\bbs\LOG.A (For other windows use LOG.B, ect) \mb\bbs\MON.A (For other windows use MON.B, ect) \mb\bbs\MAIL.DAT Appendix B rev 1------------- CONFIG.MB ------------------------------ Page 2 (Continued) \mb\bbs\MAIL.BAK \mb\bbs\USER.DAT \mb\bbs\USER.BAK \mb\msgs\ \mb\BID.MB \mb\bbs\CALLS.A (For other windows use CALLS.B, ect.) \mb\bbs\STATES.MB 10 (Max # of Calls in calls.mb) YES 02 (Autocompress [GM] mail file at XX hour) YES (Using DESQview = YES) YES (Prompt name) YES (Prompt bbs) YES (Prompt zip) YES (Turn on logging) YES (Log GateWay events) YES (Log file transfers) YES (Log message events) NO (Log local events) F (Control char to kick user off system) E (Control char to return from talk mode) E (Control char to interrupt user and talk) E (Control char to interrupt idle MailBox and get local menu) Any key to continue, Q to Quit.$H $S ($W) is using the MailBox. $R tried to connect. Please stand by, $W would like to talk to you. Hang on one minute, I will page $W. $W did not answer, you might leave a message to K3RLI in the MailBox. $S ($W) would like to talk to you. The GateWay is not available. You are linked to the other TNC. ^W returns to menu. Attempting the connection on $F. ^W will abort. Connection not established. Connection established. ^W to disconnect. Connection aborted. You are listening to $F. Type anything to return to menu. Enter TITLE for message: Enter message #$C, ^Z (CTL-Z) to end: You have new mail, $I, Type R <space> Msg# to read it: Msg# TR Size To From @ BBS Read Date/Time Title R:$J/$Kz $M@$O [$Q] Z:18702 Mail file empty. Untangling Mail. *** Killed message $M New TO or <cr> to retain: New @ BBS or <cr> to retain: New TITLE or <cr> to retain: New TYPE or <cr> to retain: *** Sorry, That is not a NTS Traffic Message. 20 (Max calls in BT list, 1 = no beacon ) 99 (Max bbs with msg to fwd to) YES (Kill regular message after forward) NO (Kill type F & B message after forward) NO (Generate svc msg on KT) YES YES [(Enable ET Command) (Enable ping-pong hold)] Appendix B ------------------ CONFIG.MB ----------------------------- Page 3 (Continued) 45 YES 5 2 7 4 21 10 (Bulletin check line) Yes = Kill 10 NO (Age of NTS messages when marked as stale, days. kill?) 30 NO (Age of User Messages when marked as stale, days. kill?) Send the file, ^Z (CTL-Z) to end. N_Name Compressing the user file. --Call Date Time Logd Msg Hm BBS I PLBEDSX Name Zip EDIT: Y to delete, Q to Quit <cr> to retain:$H *** Please Enter N (name) to enter your name. *** Please Enter NH (call) to enter the BBS where you get your mail. *** Please Enter NZ (zip) to enter your ZIP code. *** MailBox can't do it, probably a hardware problem. *** None Found *** Not your message. *** There is alreay a file with that name. *** Sorry - Timeout!!! - *** What? *** Done *** No such Port. *** No such Directory. *** File not found: $H *** Message not found. *** Port is in use. PASSWORD goes here -- 64 characters ----