ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / DOORS / ECHO310.ZIP / ECHODOR.PRN < prev next >

Wrap

Text File | 1991-10-08 | 215.4 KB | 6,338 lines

****** ****** * * ***** ***** ***** ***** * * * * * * * * * * * * **** * ******* * * * * * * ****** * * * * * * * * * * * * * * * * * * * * * * * * ****** ****** * * ***** ***** ***** * * Echodor version 3.10a Original Program By Scott Baker Modifications by Robert McCullough Documentation by Jonathan Woods If you should happen to find this program useful, Please send a contribution to: Robert McCullough P.O. Box 101095 Nashville, TN 37224 Voice Phone 615 333-0557 For the latest version of EchoDor, you may call The NEW WorkBench BBS (9600/Hst) BBS Phone 615 256-2211 FidoNet Node 1:116/1000.0 RBBS Net 8:967/107.0 File Requestable as ECHODOR 1.0 Introduction EchoDor is a full featured echo mail conference processor that incorporates features found in many door programs, and bulletin board systems. The Echo mail community has for some time been lacking a really good echo mail door. It is due to this lack that EchoDor was created. Echodor may be used on several BBS systems. It is configurable to run under RBBS-PC Ver CPC 15.1 through 17.2, PCBOARD 14.1, and Quickbbs. The difference between these BBS systems is the way they handle passing information to a Door program. RBBS 15.1 puts the information in the first record of the message file. RBBS 16.1+ creates a small text file called DORINFOx.DEF. (the 'x' being the node number that called the door program). PCBOARD creates a random access file called PCBOARD.SYS. Quick BBS passes all the parameters on the command line that calls the door. The information that is passed includes the Users Name, the Communications Port, the baud rate, the graphics type selected, the time remaining, and the sysop name. This information is used by EchoDor to monitor the carrier of the appropriate port, and to control various other functions of EchoDor. If you don't have echo mail currently operating, you probably don't have a need for this program. If you are adding echo mail to your system, and haven't completed installing it yet, STOP. Go back to the echo mail programs, and get that working FIRST! You should set up echo mail to work in a set of subdirectories like FIDO, OPUS, and the rest of the net mail bulletin boards. If you are using RBBS, DO NOT USE RBBSMAIL! RBBSMAIL puts the echo mail messages in your RBBS conference files! EchoDor can't support this feature! If you are using PCBoard or QuickBBS, the installation procedures are the same as for RBBS. Thus far PCBOARD does not support a net mail front end processor due to the fact that it does not allow parameters to be passed on the command line. To support echo mail using PCBOARD, BinkleyTerm has to be run in the "MAIL" mode as an event from PCBOARD each evening. Due to this, PCBOARD sysops cannot support Crash mail. Also, PCBOARD does not provide EchoDor will security levels; therefor, security level access control will not work. EchoDor provides a "default" security for all users of 50 when running with PCBOARD. EchoDor Version 3.10a 2.0 INSTALLATION If you already have net mail running, the installation will be very simple. If you don't run net mail, some explanation is in order. EchoDor uses FIDO type messages. IE: each message is a separate file (1.MSG, 2.MSG etc..). The messages in each area (Conference/Forum) are stored in their own Subdirectory. EG: C:\------ RBBS | +--- MAIL ------- PRIVATE | +--- BAD_MSGS | +--- HUMOR | +--- RBBS-PC | +--- CHATTER | +--- POLITICS You need to get echo mail processor to move all your incoming messages to subdirectories like these. Examples of programs that do this are ConfMail, QM (or QMail), or TossScan. Set up this subdirectory structure BEFORE proceeding to the next section! You must also set up a fossil for EchoDor to use to communicate with the modem. A number of fossil programs are available including X00, BNU, or OPUS!COM. Get one of these if your not already using one and get it installed. Then: 1. Create a directory to hold all the files in the EchoDor archive. 2. Unpack the archive into the directory. 3. Edit the file DoorDriv.Ctl to reflect the information about your system. Follow the comments contained in the file. a. Enter your first name as SYSOPFIRST name. b. Enter your last name as SYSOPLAST name. c. Enter your BBS name as BBSNAME name. d. Select your BBS type as BBSTYPE. If your BBS type is not listed, you may have to run EchoDor with some converter program. e. Place the drive and directory of your BBS into the line marked BBSPATH. This tells EchoDor where to get the door information file. Page 2 f. If you run a "locked baud", uncomment the line BAUD and set your baud rate. This will override the baud specified in the door drop file. We'll leave the rest of the entries as they are for now. See the following sections for a complete list of parameters and their uses. 4. Edit the file "ECHODOR.CTL" to reflect information about the echos you intend to carry. Follow the comments in the file. a. Enter your own zone, net and node numbers. b. Enter your name as SYSOPNAME name. c. Enter your name as COMMENTNAME name. d. Edit the 2 tables, AREATABLE and AREADESC to your own echo mail areas. The comments in the file should explain how to do this. See also the section titled ECHODOR.CTL parameter file. 5. Now run: EchoUtil /USERFILE 6. Echoutil will ask if you want Hot keys on as the default. Answer either Y or N. This will create the user file. 7. Run the CheckOut program. This program checks a lot of the entries and will help you resolve a number of problems. If Checkout generates too much output for your screen, you can redirect the output to your printer by using the command: Checkout > PRN 8. Set up a door batch file to something like the following: rem rem switch to the EchoDor directory and start rem EchoDor rem CD \EchoDor rem rem now run EchoDor and pass it the node number rem in this example the node number is passed as rem the first parameter of the batch file. If you rem only run a single node, change the %1 to 1. rem rem | this is the parameter which is the port rem | number. All other information will come rem | from the bbs door file. rem v ECHODOR %1 %2 rem CD \rbbs rbbs Page 3 (SEE the Example Batch file called ECHODOR.BAT) Note: make sure that your batch file copies dorinfo*.def to the EchoDor directory. This is a very important file. 9. Test the door in local mode with "ECHODOR /L" to make sure it is working. Page 4 3.0 DoorDriv.Ctl parameter file The DoorDriv.Ctl file controls the door's interaction with the communication port and provides information about the BBS type that is calling the door. This file is required and must be in the default directory when the door program is started. The DoorDriv.Ctl example file contains a number of comments which should help you in editing this file. This chapter contains a list of all the parameters for DoorDriv.Ctl and their use. 3.1 Multiple DoorDriv.Ctl files It is sometimes necessary to have multiple DoorDriv.Ctl file when running a multiple line system. One modem might be one speed or different monitors might be used on different nodes. Door Driver now supports multiple control files. The specific file selected depends on the "node" number specified when starting the door. Local operation always uses "node" zero (0). The name of the file comes from replacing the last character of the file name (before the period) with the node number. If that file dose not exist, Door Driver will then look for the base file (DoorDriv.Ctl). The different control files might be named: DoorDriv.Ctl < base file used as default > DoorDri0.Ctl < used for node 0 (local) > DoorDri1.Ctl < used for node 1 > DoorDri2.Ctl < used for node 2 > . . DoorDriX.Ctl < X = node number > Up to nine nodes plus local is supported. Remember that some doors change the name of the Door Driver control file. The naming would be altered to use the new base name. 3.2 Parameters BACKGROUND This parameter specifies the default background color used by the door program. See the list of available colors at the end of this section for the color numbers that can be used. Only the numbers 0-7 can be used here. The format of this command is: BACKGROUND n Where n is the color number desired as the default background color for the door. Note that some doors may not honor this parameter and use other colors. BAUD This parameter is used to set the baud rate of the door if you use a system that runs a locked baud. The format of this parameter is: BAUD xxxxx Page 5 The following fixed BAUD rates are supported: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400 If this parameter is not used the baud rate used will be the baud in the door control file written by the BBS system. BBSNAME This parameter is the name of the BBS that you want to have displayed to the user when the door closes. This parameter is required. The format of this line should be: BBSNAME name of my board DO NOT put quotes around the name of your board or they'll show, just enter the name as you would type it. BBSPATH Most doors require you to copy your door information file (written by your BBS) into the directory where the door resides. By setting BBSPATH, you instruct this door to read the door information file from the specified drive and directory. This avoids you having to copy the file and reduces start up time. This parameter is optional. If it is not specified, the door will look for the door information file in the current directory. BBSTYPE Most doors will only run with a specific type of BBS. This door will run with a number of different types of BBS systems. To tell the door the type of BBS you have you must set the BBS type. This is a required parameter. The format of this parameter is: BBSTYPE type The type should be replaced with one of the following: RBBS - for RBBS-PC 16.1+ (DORINFOx.DEF file) RA - for Remote Access (DORINFOx.DEF file) QUICK - for QuickBBS (DORINFO1.DEF file) PCB12 - for PC-Board 12. PCB14 - for PC-Board 14. WWIV - WWIV BBS (CHAIN.TXT file) PHOENIX - Phoenix BBS (INFO.BBS) WILDCAT - for WildCat! BBS (CALLINFO.BBS file) OPUS - for Opus 1.1x (LASTUS##.DAT file) GT - for GT PowerComm (GTUSER.BBS file) GENESIS - for Genesis Deluxe (CALLINFO.BBS file) WC3.0 - for WildCat! BBS (DOOR.SYS file) GAP - for GAP bbs (DOOR.SYS file) LINE-A - command line parameters (see below) LINE-B - command line parameters (see below) Page 6 COLOR1 Some BBS systems set the color indicator differently than the door expects. If your users do not get color when they should, try including this parameter in the DoorDriv.Ctl file. COMPORT Some BBS systems do not write the communications port number to the door control file. One example of this is PC-Board version 12. If you run a BBS of this type, you must tell the door which communications port to use by using this parameter. The format of this parameter is: COMPORT x Where x is a 1, 2 .... max port. DIRECTVIDEO The door uses BIOS type writes to display information on the local screen. This mode is best for people that run DV. If you want faster screen writes, include the DIRECTVIDEO parameter and the system will use direct screen writes. FOREGROUND This parameter specifies the default foreground color used by the door program. See the list of available colors at the end of this section for the color numbers that can be used. The format of this command is: FOREGROUND nn Where nn is the color number desired as the default foreground color for the door. Note that some doors may not honor this parameter and use other colors. HILIGHTCOLOR This parameter specifies the color to be used for highlight. See the list of available colors at the end of this section for the color numbers that can be used. The format for this command is: HILIGHTCOLOR nn Where nn is the color number desired as the default foreground highlight color for the door. Note that some doors may override this parameter. IDLETIME nn This specified the maximum idle time in seconds between keystrokes. When 2/3rds of the idle time has passed, the program will issue a beep. When the total time Page 7 lapses and no keystroke has been make, the door will exit. This may be disabled by setting IDLETIME 00. MAXTIME nn This parameter is used to sepcify the maximum time the user is allowed in the door. Some BBS systems require this parameter because the time remaining is not passed. GT is an example of this. In boards where the maximum time is passed, if the user has more time available than the value specified here, the users time for the door will be reduced to the specified MAXTIME. Maximum time is specified in minutes. This may be disabled by setting MAXTIME 00. MINTIME nn This parameter allows you to set the minimum amount of time the user must have remaining to be able to use the door. If the total time remaining is less than the time specified, the user will be told that he dosen't have enought time and the door will exit. Minimum time is specified in minutes. This may be disabled by setting MINTIME 00. MONO This parameter if present will disable color on the local display. This is required if you run a monochrome monitor. PROMPTCOLOR c1 c2 c3 This parameter defines the colors used for some requests made by the door. All three items are color numbers from the list below. The first color number (c1) is the foreground color of the input field. The second color number (c2) is the background color of the input field. The third color number (c3) is the foreground color number of the "Prompt Text". QUIET This parameter will prevent ^G (bell) characters from ringing the bell on the local system. STATFORE This parameter is the foreground color of the status line. If the status line is off (see the STATUS parameter) this command has no effect. Refer to the list of colors at the end of this section for the color numbers that can be used. The format of this command is: Page 8 STATFORE nn Where nn is the color number desired for the status line foreground color. STATBACK This parameter is the background color of the status line. If the status line is off (see the STATUS parameter) this command has no effect. Refer to the list of colors at the end of this section for the color numbers that can be used. The format of this command is: STATBACK nn Where nn is the color number desired for the status line background color. STATUS This parameter turns the status line on the local side on and off. I suggest you try it turned on. If the status line causes problems then turn it off. The format of the command is: STATUS ON or STATUS OFF Note: Some doors disable the status line when running in Local Mode. SYSOPFIRST This is the first name of the SYSOP. This parameter is required and should be entered as: SYSOPFIRST Name SYSOPLAST This is the last name of the SYSOP. This parameter is required and should be entered as: SYSOPLAST Name 3.3 Color Table The follow colors may be used for both background colors and foreground colors: 0 - Black 1 - Blue 2 - Green 3 - Cyan 4 - Red 5 - Magenta 6 - Brown 7 - Light Gray Page 9 The following colors may be used only for foreground colors: 8 - Dark Gray 9 - Light Blue 10 - Light Green 11 - Light Cyan 12 - Light Red 13 - Light Magenta 14 - Yellow 15 - White 3.4 PC Board 14 When using this door with PC Board 14 systems, a default security level of 50 is assigned all users. 3.5 PC Board 12 When using this door with PC Board 12 systems, a default security level of 50 is assigned to all users. PC Board 12 also requires that the COMPORT parameter be specified. 3.6 Opus 1.1x When using the door with Opus 1.1x systems, the following security levels will be used: Twit 32 Disgrace 48 Limited 64 Normal 80 Worthy 96 Privel 112 Favored 128 Extra 144 Clerk 160 Asst-Sysop 176 Sysop 208 3.7 GT PowerComm If you use this Door with GT PowerComm, you must set the MAXTIME parameter. The GTUSER.BBS file does not contain the amount of time remaining for the door. 3.8 Genesis Deluxe When using this Door with Genesis Deluxe, you must set the COMPORT parameter. 3.9 LINE-A operation This option is provided to allow doors to be called without door information files. All needed parameters are passed on the command line. The order of the parameters is not important; however, if you wish to use multiple DoorDriv.Ctl files, you must specify a port number (without a leading slash or dash) as the first parameter on the command line. Every other parameter Page 10 begins with either a slash (/) or a dash (-) followed immediately by a single letter parameter type. That type is then followed immediately by the parameter. There should be no spaces between the dash/slash and the parameter type and there should be no spaces between the parameter type and the parameter. For example: -b2400 is valid, -b 2400 is not valid. The following parameters can be specified: -B baud rate. A baud rate of zero is assumed local. -P communication port number, COM1 is -P0. -T time remaining. This is specified in minutes. -N users name. If specifying a users first & last name, use an underscore as a seperator. For example: -NFirst_Last -S numeric security level. For example: -S50 is security level 50. -M sets the maximum time allowed in door. If the time remaining is greater than the maximum time, the maximum time will be used. This is specified in minutes. -G Specifies graphics/ansi. If the -G is followed by 0, graphics will be disabled. If the -G is followed by a non zero value, graphics will be enabled. If you wish to use a "node number" this must be specified as the first parameter without a slash or dash. These parameters should not be used with the /S (sysop log on) or the /L (local log on) options. 3.10 LINE-B operation This parameter is provided to allow doors to be called without door information files. All needed parameters are passed on the command line. Every parameter is order dependent. This style of operation does not allow user names and provides a default security level of 50. The following command line is used: door <port> <baud> <time> <maxtime> <port> this is the communication port to be used. 1 is assumed to be COM1. A port of 0 is assumed local. <baud> this is the baud rate. A baud rate of zero is assumed local. <time> this is the time remaining. It's value is in minutes. <maxtime> this is the maximum time allowed in the door. If the <time> parameter is greater than the <maxtime> parameter, the <maxtime> parameter will be used. This parameter is optional. Page 11 4.0 ECHODOR.CTL parameter file ECHODOR.CTL is EchoDor's master configuration file. All communication between you and EchoDor is through this file. Node Number, Net Number, Sysop name, and many more parameters get their values from this file. An example file is distributed with EchoDor and is well commented. 4.1 Files Some of the parameters in the ECHODOR.CTL file specifies files which can be displayed to the user. Examples of such files are the menu files (as specified by the MENUFILE, PACKMENUFILE, and DOWNLOADTEXT parameter) and the welcome files (as specified by the WELCOME parameter). EchoDor supports 4 types of displays: 1. Basic text display 2. Graphics display 3. ANSI color display When EchoDor displays a file and the specified file has an extension specified, that file will be displayed to the user regardless of the type of display. If the file does not have an extension specified then EchoDor will add an extension to the file depending on display type. The selection will be: file.ANS if the user has ANSI color file.ASC if the user has Graphics No extension will be added if the user has basic text. If the user has ANSI color and EchoDor cannot find the specified file with the extension .ANS, then EchoDor will look for a file with the extension of .ASC. If that file cannot be found then EchoDor will look for the file name without an extension. 4.2 Parameters ADDRESS zone:net/node.point This parameter should be used in place of the old ZONE, NET, NODE, and POINT parameters. This is how you specify your default address. AREATABLE <address> This parameter begins the area of the control file that defines each echo area. Each line after this command and prior to the ENDAREATABLE command consists of 9 space delimited sections. Every section is required. You may enter the areas in any order you wish, when EchoDor checks and displays areas, it will be in the same order as you enter them here. Remember: Do not enter any spaces within the fields, if you do EchoDor will get confused and will not correctly read the table. Page 12 The AREATABLE command can be followed by an address in the form zone:net/node.point. This address will be the address used for all areas in the specified AREATABLE. If you do not specify an address, you MUST have a ZONE, NET, NODE, and optionally a POINT command or an ADDRESS command in the file prior to the AREATABLE line. The sections are: 1. The number. This is the area number the user would type in to get to that area. This number must be from 1-255 inclusive (you can use 1 or 255). You may NOT duplicate this number on ANY other echo area, local area, or net mail area. 2. The area tag. If the area you are defining is an echo, this field must contain the "defined" name of the echo. You can get this name from your Echo Mail Coordinator. If it is a local message area or net mail you may use any name you wish. DO NOT ENTER ANY SPACES in the area tag! 3. The listed tag. This field is shown to the user in the read menu, the scan menu, and the new messages displays. This field may be anything you wish; however, you should keep this field to more more than about 30 characters as it may make the display of certain menus look strange. DO NOT ENTER ANY SPACES in the listed tag! 4. The path. This field tells where the messages for the specific area is located. Each area must be located in a different subdirectory. All areas do not have to be on the same drive. 5. The type echo. This field is the "T" column in the ECHODOR.CTL file. This field tells the kind of message base. The "T" column can have the following values: E - the area is a local echo mail message base. I - the area is national/international echo mail. N - the area is net mail. You should normally have one per zone. B - the area is a local message or auto message area. A - the area is an auto message area (read only). Page 13 6. The Private Flag. This field allows or prevents private messages in an area. It also controls what type of user names are placed in the from field. This field can contain one ore more characters depending on what functions are needed. If this field contains a "Y" or "P", EchoDor will ask if the message should be marked private. Most echo areas, local and national, DO NOT allow private messages, so the flag should be set to "N". The net mail area does allow private messages so the flag can be set as needed. The local message areas may also be set as needed. If this field contains "A", EchoDor will ask if the user wants to use an ALIAS. If the user has not set up an ALIAS, EchoDor will tell them that they don't have an alias and it will tell them how to set it up. If you anable the "A" option on any echo area, EchoDor will allow the user to enter an "A" at the user menu to allow setting the alias; otherwise, EchoDor will not allow the "A" at the user menu. If you enable both alias and private, Echodor will allow a private message sent to a persons alias or real name. If this field contains a "F", EchoDor will ask if the user wants to send the message anonymously. Do not mix the Y/N flag with the F flag. You CAN use the F flag with the A/P flag. Examples: To set an area for ALIAS or anonymous, enter AF or FA in the field (order is not important). Notice that there is no spaces between the letters. To set an area for ALIAS and PRIVATE, enter AP, PA, or AY, or YA (again order is not important). To just allow anonymous only, just use F. 7. File Transfer Flag. File transfer is available in Net Mail areas only. If this flag is set to "Y", EchoDor will ask if you want to perform a File [A]ttach / File [R]equest when entering a message in the net mail area. This should be used only for netmail areas. Putting file requests or file attaches into echo areas is undefined. 8. Security. This field tells EchoDor the minimum security required to read messages in the area. The specific security values are defined by your BBS Page 14 software. EchoDor reads the security value passed in the Door information file (DORINFO.DEF, CALLINFO.DEF, ...etc) and compares the security passed with that in this field. The the security pass is less, access to the area will not be allowed. This field may also contain a 'Y' to indicate that it is a SYSOP only area. If the user is not listed as a SYSOPNAME, the area will be restricted. The field can also contain a 'N' to indicate an open area which is not restricted to anyone. 9. WRACC (Write access). This field tells EchoDor the minimum security required to enter messages in the area. This field works like security described above. CHECKDAYS <xx> This parameter is used to tell EchoDor how often the user must check his/her mail. This parameter is most useful when you use the "/CHECK" or the "/AC" options when starting EchoDor. The day counting may be turned off by specifying a CHECKDAYS 0 parameter. CLOSINGSTRING bye bye This parameter will be displayed to the user when he/she exits EchoDor to return back to the BBS. All the characters following the "CLOSINGSTRING" key word will be displayed. This parameter is optional. COMMANDSTRING <command str> Normally the main menu displayed by EchoDor is followed by "Main Command ? ". This is the default value. You can change this prompt by specifying the COMMANDSTRING parameter. Anything you specify as <command str> up to 40 characters will be displayed to the user in place of "Main Command ? ". A blank character is always appended to the end of the command string. Do not enclose the <command str> in quotes or the quotes will be displayed. COMMENTAREA <xx> This is the message area number as defined in the AREATABLE that will hold all comments to the sysop. This parameter is not required if you do not enable comments. When you select an area for comments, be sure this is a local area (area type B). If you choose a net mail or Page 15 echo area, your mail packer will probably send out your comments into the net. COMMENTNAME Firstname Lastname Enter the one and only name of the person who will receive comments to the sysop. This parameter is not required if you do not enable comments. COMPRESSCHAR <chars> This command specifies the valid characters for the compression method to be used. The characters should be entered one after another. Case is not important. An example of using this command for Arc, Pak, and Zip might be: COMPRESSCHAR APZ This would only allow the characters A, P, or Z to be specified for a compression method. The maximum number of characters that may be entered in <char> is 20. Characters beyond the 20th character will be ignored. COMPRESSDIR <drive:\directory> This command specifies the directory which is used to hold the compressed mail file after compression. A full directory name can be used. Drive is optional. NOTE: Don't specify any directory used by another program. The contents of the directory are erased before each compress operation. The directory name specified can include a single pound sign (#). When EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#) with the node number specified on the command line. This allows multiple directories to be used for multiple nodes. COMPRESSFILE <drive:\path\file> This is the name of the file displayed to users when they select [C]ompress from the Pack Mail menu. This file should list the compression programs that are available for compressing mail files. The file name should not contain an extension. You may create up to three files to display to the user. See the preceding section on naming files. DELETEUSER <xx> This is the number of days that inactive users will remain in the EchoDor user file. DESCTABLE Page 16 This area begins the description table. This area is required only if there is not USERAREALIST and SYSOPAREALIST. I suggest that you use this area only if you do not use the USERAREALIST and SYSOPAREALIST. If you use this table, it must FOLLOW the AREADESCTABLE. After the DESCTABLE parameter the table has one line entries until the ENDDESCTABLE command. Each line must begin with an area number. This number corresponds with the area number in the AREADESCTABLE, order is not important. The number must be followed by a single space. The next 70 characters is the description of the area, you may enter anything you like, I do suggest that you enter the area name somewhere in the line. See the ECHODOR.CTL file for an example. DOWNLOADCHAR <chars> This command specifies the valid characters for download protocol specification. The characters should be entered one after another. Case is not important. The letter "Q" is not available for a protocol. An example of using this command for X-Modem, Y-Modem, and Z-Modem might be: DOWNLOADCHAR XYZ This would only allow the characters X, Y, or Z to be specified for a protocol. The maximum number of characters that can be entered for <char> is 20. Characters beyond 20 will be ignored. DOWNLOADFILE <drive:\path\file> This is the name of the file displayed to users when they select [D]ownload from the Pack Mail menu. This file should list the protocols that are available for downloading mail files. The file name should not contain an extension. You may create up to three files to display to the user. See the preceding section on naming files. ENDAREATABLE This parameter ends the area table descriptions and must be present. See the AREATABLE command for a description of how to create an area table. ENDDESCTABLE This parameter end the description table section and must be present if a DESCTABLE is used. FORUM Normally EchoDor refers to the message areas as conferences. If your system uses the term "forum" you Page 17 may include this word in your configuration file to have EchoDor refer to your areas as forums. HELPFILEPREFIX <Drive:\path\FilePrefix> This is the prefix for all help files. The file name should not contain an extension. The path is optional and if omitted, EchoDor will look for files in the current directory. HOTKEYS When this parameter is included in the EchoDor#.Ctl file, EchoDor will use hot keys for all menu operations. The user will not have to press the enter key. This is included for sysops wish to have EchoDor more closely emulate the operation of their BBS. INCLUDE <drive:\path\fileSpec> The INCLUDE parameter allows the sysop to tell EchoDor to read an additional file during startup. This parameter is most useful for sysops that use multiple EchoDor#.Ctl files. The parameters that are the same for each node can be placed in the "included" file. When EchoDor starts it will read the EchoDor#.Ctl file as normal. When it encounters the INCLUDE parameter, the specified file will be read. EchoDor will then complete reading the EchoDor#.Ctl file. LOGFILE <drive:\Path\FileSpec> This is the name of the file that EchoDor is to use for logging activity. If the LOGFILE parameter is not specified, EchoDor will not do logging. The file name specified can include a single pound sign (#). When EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#) with the node number specified on the command line. This allows multiple log files to be used for multiple nodes. LOGTYPE <chars> This specifies the type of logging information to be recorded. The <chars> parameter contains the letter category(s) to be logged. The following categories are available: : (colon) - general information + (plus) - read/scan information $ (dollar) - write/change/kill information Multiple categories can be specified: LOGTYPE +$ If logging is enabled and the LOGTYPE parameter is not specified, full logging will occur. Page 18 MAILFILE <Drive:\Path\FileSpec> This is the file name (and path) where you wish mail packed for download to be placed. It should be in a directory that the files section of your BBS can access or somewhere where the download functions can find the file. This parameter is not required if you do not enable packed mail. The drive and path are optional and if omitted, EchoDor will create the mail file in the current directory. EchoDor will automatically create and delete this file depending on the user. The file name specified can include a single pound sign (#). When EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#) with the node number specified on the command line. This allows multiple mail files to be used for multiple nodes. MAXLINELENGTH <xx> This parameter allows you to tell EchoDor to shorten lines. Normally EchoDor sets the default line length to 75 characters. This parameter allows you to adjust this max from 40 to 75 characters in length. If a value is specified that is outside that range, 75 will be used. This parameter also effects the length of lines that can be entered on the full screen editor. MAXUSERTIME <xx> This is the maximum session time in minutes. MENU opt seclvl <Drive:\Path\FileSpec> This is an enhancement to the USERAREA and SYSOPAREA files which can be displayed to a user. Normally a user will select an area by specifying either the name or number of the desired area. Some BBS system carry a large number of conferences .. too many to place on a single screen. The "opt" is a single letter. Any letter except Q & L can be used. When that letter is selected the file specified on the MENU statement will be displayed to the user the the security level of the user is equal to or greater than the specified "seclvl". The "seclvl" is the security level the user must have to access the area. The user level must be equal to or greater than the level specified. The "FileSpec" specified should not contain an extension. Up to three files may be created. See the preceding section on file names. Page 19 Using the MENU command, the areas displayed to the user may be divided into sections. The individual sections are selected by a single letter - the "opt". When the letter is selected the file specified will be displayed to the user. A specific area may be selected from ANY menu by specifying the name or number of the area. Also, access to every menu is available from any other menu. MENUFILE <Drive:\Path\FileSpec> This is the name of the main menu file. It should not contain an extension. You should create 3 files for the menu. See the preceding section on naming files. The drive and path are optional and if omitted, EchoDor will look for the menu files in the current directory. MONO Use this option if you are using a monochrome system but still want your users to see color ANSI screens on their side. MSGTEXTCOLOR <xx> This is the color set when displaying or entering message text. See the list of colors below. NET <xxx> This parameter specifies either a Fidonet NET number or a RBBSNET net number. You do not need this line if you use the ADDRESS parameter. This parameter MUST be specified before the first AREATABLE parameter. NEWQUOTE Starting with EchoDor v3.10 we have two methods of doing quotes in full screen mode. The original method is available by default. A faster method of doing quotes which will automatically insert the quote without the second operation is available. To switch to this new method of quoting, insert the NEWQUOTE parameter in the EchoDor.Ctl file. NOCOMMENT This option will disable the comment feature. NODE <xxx> This is your Fidonet or Rbbsnet node number. It usually is between 1 and 4 digits in length, and SHOULD NOT include a point address IE: (100.0) leave off the point information. You do not need this line if you use the ADDRESS parameter. Page 20 EchoDor requires that the node number specified be non-zero. This parameter MUST be specified before the first AREATABLE parameter. NODELISTPATH Type <drive:\path\> This tells EchoDor the subdirectory that contains the nodelist files and the type of nodelist file to use. Starting with EchoDor v3.10a, two types of nodelists can be used. The first is a compiled version 6 nodelist files (NODELIST.DAT & NODELIST.NDX). When using this set the "Type" field in the NODELISTPATH line to V6. The second type of nodelist available is a special nodelist which is a combination of index files and the raw nodelist file. The index files are created by the EchoDor nodelist compiler. When using this type of nodelist specify ED as the "Type" field. Also, starting with EchoDor v3.10a this parameter is optional even if netmail is used; however, omitting this parameter will remove net/node number checking and verification as well as the ORIG/DEST lines while reading netmail. NOIGNORE This will disable the ignore command. The ignore command is used to exclude certain areas from the message check. This is useful if you have a lot of echoes, and checking them all would take a very long time. NOPACKMAIL This disables the pack mail feature. If you do not include this command then the "MAILFILE" command is required. NOSETNATIONAL By default, EchoDor will set everyone's ignore status to ignore national echoes. This option will set All echoes to be checked. NOTAVAIL <drive:\path\filespec> If specified, this file will be displayed to users that try to access an area which they don't have access to because of security. If this parameter is not specified, the system will issue an access not allowed type message. The drive and path are optional. If not specified EchoDor will look in the current directory for the file. NOWRITE <drive:\path\filespec> Page 21 If specified, this file will be displayed to users that try to enter a message into an area for which they do not have write access. If this parameter is not specified, the system will issue an access not allowed type message. The drive and path are optional. If not specified EchoDor will look in the current directory for the file. NUMHELPFILES <x> This is the number of help files (Not including the menu!). ORIGIN your origin line from your areas.BBS file This is the origin line that will be appended to all messages entered with EchoDor. It should look the same as the one in your AREAS.BBS file (part of the echo mail system). Do not include your net/node number in your origin line. Versions of EchoDor later than 3.00 will append your net node number to the end of your origin line. If you want an area to have different origin line from the one specified in the ORIGIN parameter, create a file called ORIGIN in that message area. Put one line in this file, do not include your net/node number on the line. When EchoDor saves your message it will check for this file. If it finds one it will use the first line of the file to replace the ORIGIN line specified here. You do not have to have an ORIGIN file in every area, if the ORIGIN file does not exist in some areas, EchoDor will use the ORIGIN line specified in this parameter. OUTBOUND <drive:\path> This is the full drive and path of your outbound directory. The drive and path are required. This parameter is only used by EchoUtil for tasks such as REQFILE, SENDFILE, ATTLIST .... this is not required for operation of EchoDor. PACKMENUFILE <drive:\path\file> This is the name of the pack menu file. This file is displayed to the user when the [P] command on the main menu is selected. It should not contain an extension. You should create 3 files for the menu. See the preceding section on naming files. The drive and path are optional and if omitted, EchoDor will look for the menu files in the current directory. PACKMAILTEXT <drive:\path\file> The file on this line will be displayed to any user that has caused a pack mail to be generated. This is usually used to tell the user where to find the mail file, for example: Page 22 Your mail is packed ... you may download using [D]. POINT <xx> This parameter specifies the POINT part of your net node number. EchoDor does not currently provide point remaping; however, this value is placed in the ORIGIN line to complete the net node number. This line is not needed if you use the ADDRESS parameter. This parameter if used MUST be specified before the first AREATABLE command. READHELPFILE <drive:\path\file> This specifies the name of the help file which is displayed to the user when a question mark (?) is entered at the read menu. SCANBARCOLOR <xx> This is the color set on the top line of the scan message display. SCANLINECOLOR <xx> This is the color set for each line displayed after the scan bar line during the Scan Messages function. SCANLOGNAME <drive:path\filespec> This tells EchoDor the full path name where the scan log file should be written. This file is used by programs such as QM or CONFMAIL to specify the echo mail areas which contain new messages. This file will only be written when a user enters a message into an echo mail or net mail area. The drive and path are optional and if omitted, EchoDor will create the scan log file in the current directory. Note: After mail is scanned by a mail scanner program (such as QM or CONFMAIL) this file MUST BE DELETED. Because a user may go in and out of EchoDor numerous times during a session, EchoDor will not delete this file but will read it in and append new areas to it. The file name specified can include a single pound sign (#). When EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#) with the node number specified on the command line. This allows multiple scan log files to be used for multiple nodes. SYSOPAREALIST <drive:\path\Filespec> This is the file displayed to the SYSOP when the L)ist areas function is selected. See the above description on naming files. This parameter is required if you do not use the AREADESC. The drive and path are optional. USERAREALIST <drive:\path\filespec> Page 23 This is the file displayed to the user when the L)ist areas function is selected. See the above description on naming files. This parameter is required if you do not use the AREADESC. The drive and path are optional. USERFILE <drive:\path\filespec> This is the name of the user file maintained by EchoDor. If this parameter is not specified the default will be EchoUser.BBS in the current directory. Note: This parameter is required when running a multi-node system. All copies of EchoDor must share the same USERFILE. WELCOME <drive:\path\Filespec> This is the name of the welcome file that is to be displayed each time a user accesses the echo mail door. See the above description on naming files. The drive and path are optional. If you do not wish to have a welcome file displayed to the user then remove this command. ZONE <xx> This parameter specifies you ZONE part of your net node number. For FidoNet boards running in the US, this will be 1, for RBBSNet boards running in the US, this will be 8. You do not need this line if you use the ADDRESS parameter. This parameter MUST be specified before the AREATABLE command in the control file. Page 24 Color Table The follow colors may be used for both background colors and foreground colors: 0 - Black 1 - Blue 2 - Green 3 - Cyan 4 - Red 5 - Magenta 6 - Brown 7 - Light Gray The following colors may be used only for foreground colors: 8 - Dark Gray 9 - Light Blue 10 - Light Green 11 - Light Cyan 12 - Light Red 13 - Light Magenta 14 - Yellow 15 - White Some parameters allow you to specify both a foreground and a background color; however, you must specify it in a single number (the parameter PROMPTCOLOR is an example of this). To figure the number you want: First pick out your background color and multiply that number by 16. Then add your foreground color. For a background of red and a foreground of white. Red = 4. 4 x 16 = 64. White = 15. 64 + 15 = 79. Therefore the number you specify is 79. Page 25 4.3 SYSOP setup Every system has a SYSOP. This is the person that is responsible for the operation of the BBS. Other people may also be required to assist in the SYSOP functions, so a BBS may have multiple people that have SYSOP or assistant SYSOP access. The EchoDor system supports as many SYSOPs as needed. When first setting up EchoDor you must tell EchoDor that you are the SYSOP. First you must log into EchoDor, if you are just setting up EchoDor you should have already logged into the system once to check it. If you have not already done so, start EchoDor and log in locally as the SYSOP: EchoDor /s The '/s' tells EchoDor that you are performing a "fast logon as sysop". Now exit EchoDor. You now need to start EchoUser. Do this as: EchoUser /s Now select yourself as the record to update. Use the [U] function and enter your name as you typed it in the DoorDriv.Ctl file. You should be presented with a list of users (possibly only 1). Enter the number displayed to the left of the name. EchoUser will then display you as the user. Now select [S]ysop flag. If you want the menu back, just press enter. The program will tell you that the flag is either off or on and will ask if you want to change it. If it says OFF, answer Y when it asks if you want to turn the flag on. It will then tell you that the user is now a SYSOP. With some systems (Wildcat! being one of them) it may be necessary to set the SYSOP security level. When you log on the system locally (using /L or /S), EchoDor sets the security level to 1024. This may not be high enough for some systems. If you need to have a higher security level select [L]evel from the menu. EchoUser will probably tell you that the user uses the level from the BBS (you'll want this for most users). For yourself, set the security level that you need as SYSOP. When you set a security level in this way, that will be the security level that you will receive every time you enter EchoDor, either locally or through the BBS. You can repeat this for every user that you want to setup as a sysop. Page 26 4.4 Pack Mail / Compress / Download Setup A user may now pack mail, compress and then download this mail packet with EchoDor. To fully implement these features you must make modifications in the EchoDor batch file as well as changes in the EchoDor.CTL file. All compression is performed by external compression programs. The mail file containing the text is passed as one of the parameters to the compression program. A second parameter specifies the directory which should contain the compressed file. The specific name of the compressed file is not important as EchoDor will transfer any file it finds in that directory to the user (you can even put advertisements into the directory). All downloads are implemented with external protocols. One of the most popular is DSZ. The included batch files give examples using DSZ for X, Y, and Z modem. Note that DSZ is a shareware program. Registering EchoDor does not give you the right to use DSZ. You should register that program also. 4.4.1 Basic Setup To implement Pack Mail you must include the following commands in the EchoDor.Ctl file: PACKMENU This command tells EchoDor where to find the PACKMENU files to be displayed to the user when he/she selects [P]ack Mail from the main menu. PACKMAILTEXT This command tells EchoDor the name of the file to display to the user when he/she has complete packing mail. This file might say something like: Your mail is packed. You may download using [D]. MAILFILE This command tells EchoDor the name to use for the file created that contains the packed mail. Note that if you run multiple nodes, this file must be different for each node. This difference may come by being in different directories or by using a different name in the differnt EchoDor#.Ctl files. If you only run a single node, this file may be anything you want. You must also make sure that the NOPACKMAIL command in the EchoDor.Ctl file is commented out or removed. 4.4.2 Compressing Mail To implement the mail compress feature of EchoDor, you must include the following additional parameters in the EchoDor.Ctl file. Page 27 COMPRESSFILE <filename> This contains the name of the file to display to the user when [C]ompress is selected from the pack mail menu file. The file should contain a list of the available archive programs that can be used to compress the mail file. COMPRESSCHAR <characters> This command lists the characters used to select the compression program. The case the user enters is not important. A descripton of the compression program which is selected for each letter should be listed in the COMPRESSFILE. For example: COMPRESSFILE APZ would allow the user to enter A or P or Z in response to the compress method query. Do not use Q as a COMPRESSFILE value. Q means quit. COMPRESSDIR <drive:\path> This command specifies the directory which will be used by the compress program to hold the compressed mail file. This file is checked by EchoDor during download to figure out of the user wants to download compressed mail or uncompressed mail. NOTE: DO NOT USE THIS DIRECTORY FOR ANYTHING ELSE !!!! This directory is completely erased by EchoDor each time a new user logs into the system. The compress feature also requires you to change the main EchoDor batch file. If you are already using the [D]ownload feature, no further changes will be needed. When the user selects [C]ompress in the pack mail menu, EchoDor will do the following things: First, EchoDor will write a file called EchoEX#.BAT where the # is the node number which is passed as the first parameter on the command line that starts EchoDor (usually a 1). This file will call the batch file EchoCMPS.BAT passing 4 parameters as follows: 1. The letter of the selected compression program. This will always be passed in upper case. Only the letters listed on the COMPRESSCHAR statement will be passed. Use this parameter with "IF %1 == Z compress" type commands to select the correct compression program. See a sample in the ECHOCMPS.BAT file. 2. The node number. This would be used for multi-node operation. This is also passed back to EchoDor.BAT when restarting EchoDor after the download. 3. The mail file name. This is the name of the file that contains the mail to be compressed. The file name Page 28 passed is exactly what is entered on the MAILFILE statement in the control file. 4. The directory that should contain the compressed MAILFILE. The actual name of the file that you create is not important; however, IT MUST BE IN THE DIRECTORY specified as the forth parameter. Then, EchoDor will write a return file. This file is used after EchoDor completes the compress to figure who and how much time the user has. This file is written in the default directory with the name EchoDor#.RET, where # is the node number. Finally, Echodor will exit with an errorlevel of 3. This will signal the main batch file (ECHODOR.BAT) to run EchoEX# to start the compress process. The '#' in 'EchoEX#' would be replaced with the node number. When the compress process is completed, the MAILFILE (parameter 3) file should be erased. Then the main EchoDor batch file should be restarted passing %2 as the node parameter and /R to indicate restart (EchoDor.BAT %2 /R). Example batch files to implement these procedures are included in the archive. 4.4.3 Downloading Mail To implement the downloading feature of Echodor, you must include the following additional parameters in the EchoDor.Ctl file: DOWNLOADFILE <filename> This contains the name of the file to display to the user when [D]ownload is selected from the pack mail menu file. The file should contain a list of the available protocols that can be used to download. DOWNLOADCHAR <characters> This command lists the characters used to select the download protocol. The case the user enters is not important. A descripton of the protocol which is selected for each letter should be listed in the DOWNLOADFILE. For example: DOWNLOADCHAR 12XYZ would allow the user to enter 1 or 2 or X or Y or Z in response to the protocol query. Don't use Q as a protocol. Q means quit. The download feature also requires you to change the main EchoDor batch file. If you are using the [C]ompress feature, no further changes to the EchoDor batch file will be required. When the user selects [D]ownload in the pack mail menu, EchoDor will do the following things: Page 29 First, EchoDor will write a file called EchoEX#.BAT where the # is the node number which is passed as the first parameter on the command line that starts EchoDor. This file will call the file EchoDNLD.BAT passing 5 parameters: 1. The letter of the selected protocol. This will always be passed in upper case. Only the letters listed on the DOWNLOADCHAR statement will be passed. Use this parameter with "IF %1 == Z protocol" type commands to select the correct protocol. See an example of this in the ECHODNLD.BAT file. 2. The node number. This would be used for multi-node operation. This is also passed back to EchoDor.BAT when restarting EchoDor after the download. 3. The com port number. This is in the format of 1, 2, 3, ...etc. If you need the format COMx in your batch file use COM%3. 4. The connected baud rate. Some protocols need it, some don't. If you are using EchoDor in a locked baud environment, this value will be passed at the locked rate. 5. The name of the mail file or the name of the compressed mail file. This parameter is what should be downloaded (sent) to the user. The file will contain a full drive / path / file name. This file may or may not be compressed. If the user starts the download without requesting compression, the file will be the MAILFILE; otherwise, the file will be the compressed file. The download batch file dosen't have to worry about which file is to be downloaded. The correct file will be passed to the batch file. After the download completes successfully, the downloaded file should be erased. Then, EchoDor will write a return file. This file is used after EchoDor completes the download to figure who and how much time the user has. This file is written in the default directory with the name EchoDor#.RET, where # is the node number. Finally, Echodor will exit with an errorlevel of 3. This will signal the main batch file (ECHODOR.BAT) to run EchoEX# to start the download process. The '#' in 'EchoEX#' would be replaced with the node number. When the download process is completed, the downloaded file should be erased. Then the main EchoDor batch file should be restarted passing %2 as the node parameter and /R to indicate restart (EchoDor.BAT %2 /R). Example batch files to implement these procedures are included in the archive. Page 30 The following will graphically represent what what happens when you do a compress or download: +--------------+ The BBS starts EchoDor by shelling | BBS Calls | to a file called EchoDor.BAT with | EchoDor.bat | node number passed as the first | | parameter to the batch file. +--------------+ |<---------------------------------------------<--+ V | +--------------+ ^ | EchoDor.EXE | When the user selects either | | user selects | [C]ompress or [D]ownload from | | [C]ompress | the Pack Mail menu, EchoDor writes | | or | a file called EchoEx#.Bat then Echo- | | [D]ownload | dor exits with an error level 3. | +--------------+ | | The EchoDor.Bat file checks for an | V ERRORLEVEL 3. If present it starts | +--------------+ EchoEX#.BAT, which will start either | | EchoEX#.BAT | EchoCmps.Bat for [C]ompress or | | Starts | EchoDnld.Bat for [D]ownloads. | | Echoxxxx.BAT | ^ +--------------+ | | The batch file then either compresses | V the mail file (if EchoCmps.Bat) or | +--------------+ does a download of the mail file | | Download or | (if EchoDnld.Bat). After completing | | Compress | the task, the batch file restarts | | EchoDor %1 /R| EchoDor with the node number as the | +--------------+ first parameter and /R as the second/ ^ | | V | +---->---------------------------------------->---+ When EchoCmps.Bat finishes the mail file compress, or EchoDnld.BAT finishes with the download, it then restarts EchoDor be calling EchoDor.BAT with the same node number as way originally passed. An additional parameter is passed on the restart line for EchoDor. That is the /R parameter. This parameter tells EchoDor to restart the same user from information saved in the EchoDor#.RET file. Page 31 4.5 Multiple Node Setup Another name for a multiple node setup is a multiple line setup. EchoDor has always supported multiple nodes. However, with the additional options that are available and the somewhat varied systems supported, I thought a separate section explaining methods to be used to setup a multiple node system would be in order. There are two basic ways to set up EchoDor for multiple node operation. The first way is the "common directory" method. Using this method, all the EchoDor files are in a single directory and node numbers are used to differentiae between users on the different nodes. The second way is to use a separate directory for each node you plan to run. This operation uses the "default" directory to keep multiple users separate. Depending on the way you run your board and the BBS software you use will make one of the two methods most effective for your operation. The following sections explain how to set up each of the two methods and suggestions for when to use it. 4.5.1 The Common Directory Method The common directory method places all the EchoDor files into a single directory. EchoDor is then started with a different node number for each node. This method is most effective when using BBS systems that run multiple nodes using node numbers and creates door information files with different names for each node (such as RBBS). How to set up the "common directory" system: 1. Create a directory to hold all the EchoDor files. This is the same way you would set up EchoDor for a single node system. We will call this the EchoDor Main Directory. EchoDor will never change directories during it's operation. You must make sure that the ECHODNLD & ECHOCMPS batch files don't change directories either, watch out for download protocol programs and compress programs that change the directory without you telling them. 2. If you intend to use the COMPRESS feature in EchoDor set up a separate subdirectory within the EchoDor Main Directory for each node. Use names something like this: COMPRES0 - local use COMPRES1 - Node 1 use COMPRES2 - Node 2 use . . COMPRES9 - Node 9 use 3. Make the following changes to your EchoDor.Ctl file: a. If you use the SCANLOGNAME command, change it to something like: SCANLOGNAME EchoDor\Scan#.Log Page 32 Notice the '#' in the name. This will be replaced with the node number you use to start EchoDor. b. If you are using the mail file features of EchoDor (which is always used with COMPRESS & DOWNLOAD) you must change the MAILFILE command to something like this: MAILFILE Mail#.Txt Notice the '#' in the name. This will be replaced with the node number you use to start EchoDor. c. If you are using the mail compress feature of EchoDor you will need to change the COMPRESSDIR command to something like: COMPRESSDIR COMPRES# Notice the '#' in the directory name. This is replaced with the node number you use to start EchoDor. The "COMPRES#" name will be changed to names like "COMPRES0", "COMPRES1", and so on. The names must match the directories you created in the above section. 4. Also, you will have to make your batch files that control scanning the mail after it is entered aware of the log names. In place of making a very complex batch file to decide which log to pass to your mail packer, you can use SCANMRG to combine the various scan logs into a single log, then perform a single scan once a day. To perform this operation you would add a command such as: SCANMRG EchoDor\Scan%1.Log EchoDor\ScanLog.Log This command goes in your EchoDor.Bat file after the IF ERRORLEVEL 3 line. This would combine all the Scanlogs for the various nodes into a single ScanLog. An explination of SCANMRG is in sections that follow. You should not relpace the SCANMRG with a copy/append command as the operation of SCANMRG is different. 5. If the various nodes in your system need other changes in the EchoDor.Ctl file for reasons such as different echos, different privileges or other such reasons, EchoDor allows you to create a separate EchoDor.Ctl file for each node. The specific file used is created by changing the name of the base file: EchoDor.Ctl - this is the default file EchoDor0.Ctl - this would be used for local operation EchoDor1.Ctl - this would be used for node 1 EchoDor2.Ctl - this would be used for node 2 . . EchoDor9.Ctl - this would be used for node 9 You should still make the changes outlined above in the EchoDor.Ctl file before you make copies of it for the Page 33 various nodes. This will help prevent errors when you create the EchoDor#.Ctl files for the various nodes. Also, be sure the EchoDor.Ctl file contains EVERY message are you intend to carry. This is the file used by EchoUtil when performing maintenance. Finally, be aware that should a node look for it's EchoDo#.Ctl file and one is not present, EchoDor will use the default (EchoDor.Ctl) file. 6. If the various nodes in your system require different information in the DoorDriv.Ctl file, such as for different types of modems or different BBS names or different SYSOP names, EchoDor allows multiple DoorDriv.Ctl files to be used for each node. The specific file used is created by changing the name of the base file: DoorDriv.Ctl - this is the default file DoorDri0.Ctl - this is used for local operation DoorDri1.Ctl - this is used for node 1 DoorDri2.Ctl - this is used for node 2 . . DoorDri9.Ctl - this is used for node 9 If EchoDor looks for it's DoorDri#.Ctl file and cannot find it, it will use the default (DoorDriv.Ctl) file. 4.5.2 Multiple Directory Method The multiple directory method sets up a single directory to hold all the "common" EchoDor files and separate directories for the "node specific" files. This method is most effective when used with BBS systems that do not provide "node number" information and always names the door information file the same (such as WildCat!). To set up a "multiple directory" system do the following: 1. Create a "common" directory which will be shared between all the nodes in the system. Put the following files in this directory (check your EchoDor.Ctl file for the exact names): ECHOUSER.BBS - this is the main user file The MENUFILE files (used for the main menu) The PACKMENUFILE files (used for the pack menu) The USERAREALIST files (conference lists) The SYSOPAREALIST files (sysop conference list) The MENU files (conference menu files) The help files The DOWNLOADFILE The COMPRESSFILE The NOTAVAIL file The NOWRITE file The PACKMAILTEXT file The WELCOME files Page 34 Also, put a copy of the DoorDriv.Ctl & EchoDor.Ctl file into this directory. We will use the files in the "common" directory to make a model for all the other directories. 2. Now we will edit the EchoDor.Ctl file that we have placed in the common directory. The following lines should be changed to include a full drive, path, and file name so that the various nodes can find these files: USERFILE <drive:\path\name> This is probally the most important line in the EchoDor.Ctl file when using mutliple node / multiple directory setups. This tells EchoDor where to find the main user file. Be sure to specify a full drive, path, and file name in this line. This will cause EchoDor to share the file between nodes. MENUFILE PACKMENUFILE USERAREALIST SYSOPAREALIST NOWRITE NOTAVAIL HELPFILEPREFIX MENU DOWNLOADFILE COMPRESSFILE PACKMAILTEXT WELCOME Now we are going to edit the lines which are "node" dependent. These lines will NOT include a full path but will only include file names or directory names. DO NOT use the '#' in the file name. This should only be used for "common directory" operation. MAILFILE <filename> Only use a file name. Don't include a drive or path. For example: MAILFILE mailfile.txt COMPRESSDIR <directory name> Only use a single name. Don't include a drive or path. For example: COMPRESSDIR compress SCANLOGNAME <filename> Only use a file name. Don't include a drive or path. For example: SCANLOGNAME scanlog.log Be sure this "default" EchoDor.Ctl file contains ALL the message areas that you intend to carry on your system. We will use this file during maintenance (EchoUtil /M) to tell EchoUtil where ALL the areas are to be processed. Page 35 Save the EchoDor.Ctl file. 3. Now we need to edit the DoorDriv.Ctl file. Make all the changes outlined in the above section. Then: Remove the BBSPATH line. It will be necessary to "pick up" the door information file from the default / current directory. We may have to make other changes in the DoorDriv.Ctl file based on the "node" but we'll save that for a little later. Save the DoorDriv.Ctl file. 4. Create a separate subdirectory for each node that you intend to run. 5. Switch to the subdirectory that you created for one of the nodes. Remember which node this directory is going to be used for. Then do the following: Copy the EchoDor.Ctl file in the "common" directory to this directory. Do not rename the file. It should still be EchoDor.Ctl. Copy the DoorDriv.Ctl file in the "common" directory to this directory. Do not rename the file. It should still be EchoDor.Ctl. Copy the EchoDor.BAT file into the current directory. If you are using the COMPRESSDIR command in your EchoDor.Ctl file, create a directory with the name you specified in the COMPRESSDIR command. The COMPRESSDIR command in your EchoDor.Ctl file should only contain the name of the directory. It should not include any drive or path specifications. 6. Depending on your BBS and system requirements, you may have to edit the DoorDriv.Ctl file. Based on the node you may have to change: The BAUD line. If this node runs a locked baud be sure to include a BAUD line. The COMPORT line. If your BBS does not provide the com port in the door information file, edit this line to tell EchoDor which port to use for this node. Make any other changes that are needed for this specific node. Then save the DoorDriv.Ctl file. 7. Edit the EchoDor.BAT file: Include a line to copy the door information file from THIS NODE's BBS directory to the current directory. Perform the needed operations to get the SCANLOGFILE into where ever it needs to go. This will depend a great deal on how you process the newly entered messages. Page 36 Do what ever is needed to get you back to your bbs directory to restart / reload your BBS program. 8. If you use COMPRESS and/or DOWNLOAD, be sure the ECHOCMPS and the ECHODNLD batch files are placed somewhere on your PATH. This is so the main EchoDor.BAT file can find them. If you don't want to place these batch files in your path, place a copy of them in each node's subdirectory. The following special considerations must be made when performing the mail compress and renumber. 1. Be sure that the EchoDor.Ctl file contained in the "common" directory contains EVERY message area that you are carrying online. 2. When performing purge and renumber, be sure to switch to this directory before you run EchoUtil /M. Page 37 4.6 Multiple Net Setup Starting with version 3.03 of Echodor, multiple net/node numbers may be used. The system will only allow one net/node number per echo area; however, your echo areas may be split up into groups with a different net/node number for each group. When an echo message in entered, the specified net/node number which applies to that area is appended to the origin line and placed in the origin fields in the message. Normally only one net/node number is specified in the ECHODOR.CTL file; however, if you follow the structure of the example below you can have EchoDor place the correct net/node number, in a multi-net setup, in the origin line and message depending on the echo area where the message was entered. To use multiple net/node numbers you must group your echo areas together using AREATABLE / ENDAREATABLE specifications and multiple ZONE, NET, NODE, and POINT commands. Using the following as an example of what might be in a ECHODOR.CTL file: ; ; Specify your default address ; ADDRESS 1:116/1000.0 ; ; Now specify the areas which should use 1:116/1000.0 in ; their origin line. The AREATABLE / ENDAREATABLE should ; be exactly like what would be used for a single net. ; Notice that the AREATABLE line does not have an address ; specified. This will cause the AREATABLE to use the ; address specified on the ADDRESS line above. You could ; also specify 1:116/1000.0 on the AREATABLE line but it ; will produce the exact same effect. See the above ; description for how to specify an AREATABLE. ; AREATABLE 1 echoone echotag path ...........ect 2 echotwo echotag path ...........etc ENDAREATABLE ; ; Now come the areas which should use 8:255/120.0 in their ; origin line. Notice that an address is specified on ; the AREATABLE line. This will override the default ; address specified on the ADDRESS line. ; AREATABLE 8:255/120.0 3 echothree echotag ....... 4 echofour echotag ....... ENDAREATABLE Notice that the AREA NUMBERS in the first AREATABLE and the second AREATABLE were NOT duplicated. An area number may only appear once even when you use multiple AREATABLEs. Also, if you use the AREADESC to specify the descriptions for your areas, all the areas in both nets may be specified in a single AREADESC / ENDAREADESC. Page 38 EchoDor is not limited to only two nets. You may specify as many zone:net/node groups as you require for your setup. The total number of areas (echo, local, and net mail) for all areas added together may not exceed 255. Page 39 5.0 Purging & Renumbering Areas There are now two different methods of purging and renumbering your message areas. One was is to use the three step process of purge, EchoUtil /m, renumber. This method offers some advantages of allowing you to use any purge/renumber program you want. The disadvantage of this method is the time involved. The second way to purge and renumber areas is to use EDorPurg. This program can purge, renumber, and update the user file in a single operation. Both methods are described here. 5.1 The Three Step Method Purging and renumbering your message areas is a three step process. You must not omit any of these steps otherwise the last read pointers will not be correctly set. These steps include: 1. Old messages are deleted. At this time the messages should NOT be renumbered. This is purging. 2. Second, EchoUtil must be run in maintenance mode (EchoUtil /M) to figure out what each users last read pointer should be after the message bases are renumbered (next step). Note: This step must be performed BEFORE the actual renumbering the message areas. 3. Third, the message areas are renumbered. There are a number of utilities which can perform the first (purge) and third (renumber) steps. Starting with EchoDor 3.05, I am providing automated assistance in generating the required files to perform these operations using RASMSM v2.00 or later. RASMAM is a program written by Roger Smith, Jr of 1:366/14. The program is geared for Opus but works great for any other system which uses the #.msg format for messages. Please remember that this program is also a shareware program. Registration of EchoDor does not entitle you to use RASMAM without registration. I currently have a copy of RASMAM available on the WorkBench BBS which can be downloaded using the name OMAM_200.ZIP. RASMAM uses script files to direct it's actions. To use RASMAM for maintance, the following batch file could be used: REM - first purge the message areas REM - "purge.mam" is the file that controls the purging REM RASMAM purge.mam REM REM - then run EchoDor maintanance REM - both EchoDor /M & EchoUtil /M will do it REM EchoUtil /M REM REM - then renumber the message areas REM "renum.mam" is the file that controls renumbering REM RASMAM renum.mam Page 40 In the above sample, two files are required for RASMAM. This is PURGE.MAM which contains information on purging the areas and RENUM.MAM which contains information on renumbering the areas. EchoUtil will assist you in generating these files. Use one of the following commands: ECHOUTIL /RASMAM ECHOUTIL /RASMAM nnn ECHOUTIL /RASMAM ? If you use the first command, ECHOUTIL will generate a PURGE.MAM file and a RENUM.MAM file (both in the current directory). All message areas will be purged to contain 100 messages. If you use the second command, ECHOUTIL will generate the PURGE.MAM and RENUM.MAM files which will will maintain all message areas with "nnn" number of messages. The "nnn" value may be from 1 to 255. Any number outside this range will cause ECHOUTIL to use 100. If you use the third command, ECHOUTIL will generate the PURGE.MAM and RENUM.MAM files for all message areas. It will ask for the number of messages to keep in each area as the files are generated. Any number may be used. These files may be edited after they are created to include any special processing which can be provided by RASMAM. Note: EchoUtil will not check to see if you already have either of these two files in the current directory. It will just overwrite them if they are out there. Also, be sure that the TAG in the AREATABLE is unique for each area. This "TAG" is used when generating the PURGE.MAM and RENUM.MAM files for naming the areas. 5.2 EDorPurg The EDorPurg program can perform the message purge, renumber, relink, and user file updates in a single operation. EDorPurg also compresses your message directories and puts all the messages in numerical order within the directory. Performing this operation has the advantage of keeping EchoDor running fast. 5.2.1 Setup If your using EDorPurg with EchoDor you should setup an EDorPurg.Cfg file. This file contains a list of all the areas and what action should be performed on that area. This parameter file is not required; however, after it is set up, you only need to enter EDorPurg with no parameters and your system will be purged. The EDorPurg.Cfg file is a plain ASCII text file. Each area occupies one line. Parameters are space delimited (one or more spaces between each parameter). The first parameter on the line must be the "TAG" name of the area. This "TAG" name must match the "Area Tag Name" in the Page 41 EchoDor.Ctl file. Optionally the "TAG" name can match the area name that is listed in your AREAS.BBS file. The next parameter tells EDorPurg the type of area. The valid values are: LOCAL NETMAIL ECHO EDorPurg checks to make sure that the type specified matches the type in the EchoDor.Ctl file. If the don't match, a warning is issued and EDorPurg will use the type specified in the EchoDor.Ctl file. All other parameters can be in any order. There should be only one occurrence of each parameter per line. The following are valid parameters: KEEP nnn This indicates the number of messages to keep in the area. This parameter will always take priority over all other parameters. For example, if you specify KEEP 50 and KILLRECEIVED, after processing there will be only 50 messages in the area. EDorPurg will first kill received messages, then it will trim the area to 50 messages. FDAYS nnn This indicates that files that are older than 'nnn' days old should be purged. This parameter is based on the date of the *.msg file. MDAYS nnn This indicates that messages that are older than 'nnn' days old should be purged. This parameter is based on the date of the message. KILLRECEIVED This indicates that messages that have been "received" should be deleted. An example of a purge line might be: NetArea NETMAIL KEEP 75 KILLRECEIVED or EchoArea ECHO KEEP 150 MDAYS 30 After you have set up your EchoDor.Ctl file, you can have EchoUtil build you an initial EDorPurg.Ctl file. To build this file enter: EchoUtil /EDorPurg EchoUtil /EDorPurg 150 EchoUtil /EDorPurg ? The first example will generate an EDorPurg.Ctl file for every area with a KEEP 100 value. Page 42 The second example will generate an EDorPurg.Ctl file for every area with a KEEP 150 value. The last example will generate an EDorPurg.Ctl file for every area and will ask for the KEEP value. After you generate the EDorPurg.Ctl file you can use an editor to make additional changes. Be sure you have a blank line after the last entry in the EDorPurg.Ctl file; otherwise, you'll get strange messages about the last area. Note: EchoUtil will not check to see if you already have an EDorPurg.Ctl file in the current directory. It will just overwrite it if is out there. Also, be sure that the TAG in the AREATABLE is unique for each area. This "TAG" is used when generating the control file for naming the areas. 5.2.2 EDorPurg Parameters EDorPurg has a number of command line parameters to help taylor its operation to your needs. Note: Some of the parameters use the same letter to mean multiple things. If the letter is followed by a parameter then it means one thing, if the letter is used without any parameter it means something else. For example: -e<file> specifies the path and file name of the EchoDor.Ctl file. -e (without the file name) specifies to process only echo areas. The following command line parameters are available: -a specifies that EDorPurg should process all areas except passthru areas. This parameter is most useful when using EDorPurg with an areas.bbs file. -a<file> specifies that EDorPurg should use an AREAS.BBS file in place of an EchoDor.Ctl file. The <file> parameter specifies a full path and file name of the AREAS.BBS file to be used. To specify a local only area using an AREAS.BBS, specify the area tag and path only. Do not specify any nodes. To specify a net mail area, use the tag name NETMAIL. -d<dir> This tells EDorPurg to purge messages in the specified directory. Do not put <> around the directory name. When using the -d<dir> command line parameter, you must also use -e, -n, or -l command to indicate the area being echo, net mail, or local. Page 43 -e This parameter tells EdorPurg to process only echo areas. Netmail and Local areas will not be purged. When used with the -d<dir> command, this parameter tells EDorPurg that the area being processed is an Echo area. -e<file> This parameter tells EDorPurg the path and name of the EchoDor.Ctl file to be used. If the -e<file> parameter is not specified, EDorPurg will look for a control file named EchoDor.Ctl file in the current directory. Do not put <> around the file name. -K<nnn> This parameter tells EDorPurg the number of messages to keep. The 'nnn' should be replaced with a number. Do not put <> around the number. For example: -K150 would tell EDorPurg to keep 150 messages in the area. -KRECV This parameter tells EDorPurg to kill received messages. -l This parameter tells EDorPurg to process only local areas. NetMail and Echo areas will not be purged. When used with the -d<dir> command, this parameter tells EDorPurg that the area being processed is a local area. -l<file> This parameter tells EDorPurg the name of the log file where purging information should be palaced. Do not put <> around the file name. If this parameter is omitted and a LOG filename parameter is in the EchoDor.Ctl file, that log file will be used. -n This parameter tells EDorPurg to process only net mail areas. Local and Echo areas will not be processed. When used with the -d<dir> command, this parameter tells EDorPurg that the area being processed is a net mail area. -p This parameter tells EDorPurg to only purge the areas. No renumbering should be done. -q This enables "QUIET" mode. Very little output will be displayed to the screen. This does not effect output to the log file. -r This parameter tells EDorPurg to renumber only. No purge of the area will be done. -REC Force recovery of areas. If this parameter is specified, EDorPurg will only operate on errors that need to be recovered. No other operation will be performed. This parameter is usually not Page 44 required as EDorPurg can figure out for itself that it should recover. -s<file> This parameter specifies a file that contains tag names of the areas that should be purged. Do not put <> around the file name. -t<tag> This parameter specifies a single area by tag name. Do not put <> around the tag name. 5.2.3 Operation EDorPurg does not operate as most message renumbering / purging utilities run. The following is a summary of the way EDorPurg performs its operation. This information is provided for the curious. 1. EDorPurg first counts the messages in the directory to be purged. It also checks to see if any other indicators (such FDAYS) has been specified and checks all messages to see if it should be kept. 2. If messages are to be purged, a new directory is created. This directory is named the same as the original directory with the exception of an extension of @@@. 3. EDorPurg writes a recovery file to the new directory. This recovery file contains a list of the old message numbers, what the new message numbers will be, and relinking information. 4. The messages that are to be kept are renamed into the new directory. This renaming moves the message from one directory to another (this is not a copy but a move) and sets the name of the message to its new number. 5. All old messages remaining in the original directory are erased. 6. Any file that remains in the old directory (such as ORIGIN or LASTREAD) is moved to the new directory. 7. The old directory is removed. 8. The new directory is renamed so it's name will be the same as the old directory. 9. The next/prior message numbers are then relinked. 10. The EchoDor user file last read pointers are updated. 11. Any 'LASTREA?' files are updated. 12. The recovery file is erased. 5.2.4 Recovery Method EDorPurg contains complete recovery should some problem prevent it from completing its purge / renumber operation. With most purging / renumbering utilities, should some problem strike Page 45 during the purge/renumber operation, your left with a mess in the directory and users last read pointers are left pointing into who knows where. To combat this problem, EDorPurg writes recovery information to a file called EDorPurg.REC. This file contains complete information about the state of the message area before the purge and how the renumbering will effect user last read pointers. Should a problem occur where EDorPurg is not able to complete its operation, just restart EDorPurg. It will automatically recover the area that it was unable to complete. If you only want EDorPurg to recover and not to purge other areas, start EDorPurg with the -REC parameter. Page 46 5.3 FastLink FastLink is a program which relinks the prior message / next message pointers by subject. This allows the reader to use the +, -, and * options on the read command. 5.3.1 Parameters FastLink has a number of command line parameters to help taylor the operation to your needs. Note: Some of the parameters use the same letter to mean multiple things. If the letter is followed by a parameter then it means one thing, if the letter is used without any parameter it means something else. For example: -e<file> specifies the path and file name of the EchoDor.Ctl file. -e (without the file name) specifies to process only echo areas. The following command line parameters are available: -a specifies that FastLink should process all areas except passthru areas. This parameter is most useful when using FastLink with an areas.bbs file. -a<file> specifies that FastLink should use an AREAS.BBS file in place of an EchoDor.Ctl file. The <file> parameter specifies a full path and file name of the AREAS.BBS file to be used. To specify a local only area using an AREAS.BBS, specify the area tag and path only. Do not specify any nodes. To specify a net mail area, use the tag name NETMAIL. -d<dir> This tells FastLink to relink messages in the specified directory. Do not put <> around the directory name. -e This parameter tells FastLink to process only echo areas. Netmail and Local areas will not be purged. -e<file> This parameter tells EDorPurg the path and name of the EchoDor.Ctl file to be used. If the -e<file> parameter is not specified, EDorPurg will look for a control file named EchoDor.Ctl file in the current directory. Do not put <> around the file name. -l This parameter tells FastLink to process only local areas. NetMail and Echo areas will not be purged. Normally this parameter will not be used. EchoDor keeps messages in local areas properly Page 47 linked regardless of the subject. Use this parameter with care. -l<file> This parameter tells FastLink the name of the log file where purging information should be palaced. Do not put <> around the file name. If this parameter is omitted and a LOG filename parameter is in the EchoDor.Ctl file, that log file will be used. -n This parameter tells EDorPurg to process only net mail areas. -q This enables "QUIET" mode. Very little output will be displayed to the screen. This does not effect output to the log file. -s<file> This parameter specifies a file that contains tag names of the areas that should be purged. Do not put <> around the file name. When using FastLink after mail is tossed, this parameter will tell FastLink exactly which mail areas need to be processed. -t<tag> This parameter specifies a single area by tag name. Do not put <> around the tag name. 5.3.2 Operation Normally FastLink is used only on Echo areas. Net mail is usually a number of disjointed messages. Local message bases keep by EchoDor will always be properly linked. 5.3.2.1 After Tossing Mail The best time to run FastLink is immediately after you have completed tossing incomming mail. Most mail tossers will write a file containing the names of the Echos that have been tossed. Use this file with the -s<file> parameter to have FastLink relink only the message bases that have recieved messages. If your tosser cannot write a scan file, just run FastLink with the -e parameter after receiving mail. FastLink will scan each area and relink only areas that have not been processed. Although this operation is not as fast as using the -s<file> parameter, it's still pretty quick. If you run FastLink from a directory other than the EchoDor directory, you will need to specify the location of the EchoDor.Ctl file. Use the -e<file> parameter. When running FastLink without a scan file (as described above) the command line parameter will be: FASTLINK -eC:\Path\EchoDor.Ctl -e There are two -e parameters, one with a file name (indicating the location of EchoDor.Ctl) and another indicating process only echo areas. Page 48 5.3.2.2 After EDorPurg If you do not want to run FastLink after receiving mail, the next best place to run is immediately after purging / renumbering with EDorPurg. Do not confuse the "relinking" phase of EDorPurg with the operation performed by FastLink. EDorPurg updates the prior / next message pointers with the new message numbers (after renumbering). FastLink relinks messages based on subject. It is faster to run FastLink after running EDorPurg than before. This is because: 1. There are less messages that have to be checked. 2. EDorPurg has updated already linked messages so FastLink won't have to rewrite these messages. 3. EDorPurg will have less messages to link because messages not yet linked will not require updating. It is again suggested that only Echo areas be processed by FastLink. The command line to do this is: FastLink -e or if you need to specify the location of the EchoDor.Ctl file: FastLink -eC:\path\EchoDor.Ctl -e Page 49 6.0 EchoDor Operation EchoDor operation is simple. It has been designed to look like part of your BBS. The menu files can be changed to look like the rest of your system as well. The command letters may NOT be changed. 6.1 Menu Commands The valid commands from the main menu are as follows: J - Join Conference A - Area Change When this function is selected, the user is presented with a prompt asking for the echo mail area number, or the name, or 'L' to list the areas. If you have defined a description table in your ECHODOR.CTL file, the description table will be listed. If you are using the USERAREAFILE and the SYSOPAREAFILE parameters, the corresponding file will be displayed. If graphic versions of the file exist, they will be displayed if the user supports ANSI or ASCII graphics. If your BBS system uses the term area instead of conference, modify the menu to say [A]rea Change. EchoDor will except either J or A to change conferences. C - Check Personal Mail When this function is selected, the user is presented with a prompt that asks him/her to verify that mail is to be checked. During the check, only conferences that have been selected in the IGNORE EDITOR will be checked. The user can abort the scan at any time by pressing 'S'. When a message is found, the header information will be displayed. F - Toggle Full Screen Editor This function allows the user to turn the full screen editor on or off regardless of his/her graphics setting. See the FULL SCREEN EDITOR reference section for instructions for its use. H - Invoke the Help System. This displays the help menu to the user. See the HELP SYSTEM reference section for information of the help system. I - Ignore Editor. This editor allows the user to include or exclude any conference from the 'check personal mail', 'check new messages', or 'Pack mail' functions. L - Leave Sysop a Comment. Page 50 This option lets the user enter a message into the comment area. This option is not valid if the NOCOMMENT parameter is specified. If you decide to disable comments, you should edit the echo menus to remove the option. P - Pack Mail section. This function allows the user to enter the Pack Mail section. Within this section the user can pack mail for download. R - Read Messages. This function allows the user to read & reply to the messages in the current echo mail area. The user is presented with a sub-menu of options after each message is displayed. S - Scan Messages. This function allows the user to display a list of message headers. (IE: To....From....Sbj) Etc. E - Enter a Message. EchoDor users may select a line editor much like most BBS's, or a full screen editor. This full screen editor is the same editor found in PRODOOR. (The PCBOARD Door). See the full screen editor section for more information. X - Expert Toggle. This turns on and off the main menu display. Just like most BBS's. Q - Quit EchoDor. In local mode this function will return you to the DOS prompt. In On-line mode, this function will return the caller to the BBS. Z - Sysop commands. This function enters the SYSOP menu. From the SYSOP menu you may Copy or Doctor messages, read the nodelist or check EchoDor users. If you can't get to the sysop menu and you are a sysop, use EchoUser /S and set your SYSOP flag in your user record. Read the section on EchoUser. Page 51 6.2 Reading messages After activating the read message command (R), you will then be shown the message in the area where your last read pointer is set. At the bottom of the screen, a prompt line will be shown which will give you a set of options. Each option is selected by typing the first letter of that option. You may also select a specific message to be displayed by entering the message number of the desired message in place of an option letter. If the message is public or address to you or from you, it will be displayed. [N]ext Attempt to go to the next message in the base. If possible, the message pointer will be moved to the next message in the area until either a public or a private message addressed to you is found. The message will be displayed to you and the prompt line will once again be shown. [P]rev Attempt to go to the previous message in the area. If possible, the message pointer will be moved to the message preceding the one that you just read. Private messages not addressed to you will not be displayed. # Display a specific message. Don't actually type a number sign (#), just type the number of the message you want to see. If the message exists and is public or addressed to you it will be displayed. + If the message you are reading has a reply the plus sign (+) will be displayed. By pressing this you will read the reply. From that point on, pressing <enter> will read each successive reply. This is known as reading a thread. - If the message you are reading is a reply the minus (-) sign will be displayed. By pressing this you will read the original message. From that point on, pressing <enter> will read each original message. This is also known as reading a thread. * The first time you press plus (+) or minus (-) to begin reading a thread, EchoDor remembers where you were in the message base. While reading a thread, you can return to your starting point by pressing the asterisk (*) key. [R]eply This will allow you to enter a reply message to the message that you are currently reading. For more information on entering messages, please see the information on entering a message. [Q]uit Page 52 Quit to the main menu. This will bring you back to the main menu of the message system. The last message you read in each area will be remembered for you. [K]ill If the current message is either to or from you, then you will be presented with the kill option. The kill option will physically erase the message from disk. It will be no longer readable and CANNOT BE RESTORED. [S]ave This will capture the current message to the usermail.txt file. [C]hange If the current message is either to or from you, then you will also be presented with this option. It will allow you to change the content of the current message. Do not remove the Origin or tear lines. [A]ll This option will allow you to display all the messages starting at your current message without stopping. This option is handy if you wish to "capture" the messages in an area using your terminal software. If you enable this option it will stop if you press any key or you reach the end of the current area. [E]nter This option will allow you to enter a message from the read menu. This operates exactly like the [E]nter function on the main menu. [M]ine This is a "toggle" switch. When selected, EchoDor will only display messages addressed to or from the reader. Selecting [M]ine a second time will allow reading all messages. [O]ver When [O]ver is selected, the same message is displayed again. The following sysop functions are available from the read menu: [H]ard Copy This option allows the sysop to request EchoDor to print a hard copy of the message. LPT1 is always used. Make sure that the printer is on line as EchoDor does not have built in recovery from printer errors. [X]erox This is the Xerox message function. It allows you to send a copy of the message to another user. The message to be copied is always the just read message. The copied may be addressed to anyone. It may also be placed into any area. [V]iewall Page 53 This function is not listed but is available on the read menu. This function allows the SYSOP to see all lines in the message. This includes SEEN-BYs, PATH lines, and kludge lines. The message is redisplayed with all lines visible. [F]ile This function allows you to save a message in a separate file. When 'F' is entered, you will be asked for a file name. If the file already exists, EchoDor will ask if you want to [A]ppend or [O]verwrite the file. The message is saved in the same format as the messages saved in the PACKMAIL file. Page 54 6.3 Entering messages There are two ways to enter messages: 1) With the full-screen editor. 2) With the line editor. Each of these methods will be described separately. If you are using IBM ANSI graphics, then the full screen editor will be chosen for you. If not, then the line editor will be chosen. 6.3.1 Line Editor The line editor is the simplest of the two editors. You are initially placed in "entry mode" where you will just have to type your message. The lines will be wrapped automatically for you. You press enter at the beginning of a line to leave "entry mode". After leaving "entry mode", you will be presented with a small menu consisting of these options: [C]ont Continue the current message. This will simply place you back into the line editor's "entry mode" at the end of the last line you entered. [I]nsert This will allow you to insert a line anywhere into the message. When you select this option the line editor will ask you where you want to insert the line. [D]elete This option will let you delete any line in the message. When you select this option you will be asked the starting and ending line(s) you want to delete. [V]isual If you are using ANSI graphics, this will let you re- enter the full screen editor. [Q]uote If you are entering a reply, you may quote lines directly from the original message. When you select this option you will be given another small menu which will allow you to: List the original message. Specify the starting line number to quote. Specify the ending line number to quote. Display the message your current writing. Specify the line where the quoted lines are to be inserted. [A]bort This will throw the message that your are currently entering away and exit the line editor. [S]ave This will save the message you are entering and will exit the line editor. Page 55 6.3.2 Full Screen Editor The EchoDor full screen editor is the same editor that appears in PRODOOR (Thanks Sam!). It provides full-screen editing for on line message entry. Full screen editing requires ANSI terminal emulation. The full screen editing commands are WordStar-Like control characters. If your terminal program provides ANSI keyboard emulation, you will also be able to use the indicated function keys. Here is a summary of the editor commands: << Cursor Motion >> Ctrl-S Move left 1 character (Left arrow key) Ctrl-D Move right 1 character (Right arrow key) Ctrl-E Move up 1 line (Up arrow key) Ctrl-X Move down 1 line (Down arrow key) Ctrl-A Move left 1 word Ctrl-F Move right 1 word Ctrl-I Tab cursor to next tab stop (Tab key) Ctrl-P Move cursor to line end (End key) << Scrolling >> Ctrl-R Move up a page (PgUp key) Ctrl-C Move down a page (PgDn key) << Delete >> Ctrl-G Delete character under cursor Ctrl-H Delete character to the left of the cursor (Backspace) Ctrl-T Delete the word following the cursor Ctrl-Y Delete the current line Ctrl-J Join current line with next line << Miscellaneous commands>> Ctrl-B Reformat paragraph. A paragraph ends with the first line that is blank or that has leading spaces. Ctrl-K Visual quote mode. This allows you to display the original message and copy lines from it to the current message. Ctrl-L Clear screen and redisplay. (Home key) This also scrolls the screen so the cursor line is in the middle of the display. Ctrl-N Insert a RETURN. Splits line at the cursor. Ctrl-O Review the text of the Original message you were reading or replying to. If your not replying to a message this key does nothing. Ctrl-Q Visual quote mode. This allows you to display the original message and copy lines from it to the current message. Page 56 Ctrl-V Toggle insert/overtype mode. (Ins key) Ctrl-W Display message header information (date, to, from, subject, etc). (Note: This option is not currently available.) ESC Exit visual mode and return to the Message Entry Command prompt. 6.3.2.1 Insert Mode versus Overtype Mode In insert mode, all characters typed are INSERTED before the cursor. The ENTER key splits the line and BACKSPACE can re-join lines. In overtype mode, characters "type over" what was on the screen before. Overtype mode also disables the automatic line SPLIT / JOIN available in insert mode. Use ^N(split) and ^J(join) to manually split and join lines while in overtype mode. 6.3.2.2 Keyboard emulation The easiest way to control the cursor in Visual Edit mode is to use your cursor keys. Most popular terminal programs provide some sort of keyboard emulation. Unfortunately, this emulation is either incomplete or requires you to go through an involved configuration process. The WordStar* command set was chosen as a control-character command set because it can function on virtually any keyboard and with any terminal emulation mode. It also has the advantage of letting you keep your fingers on the "home" keys while moving the cursor around. 6.3.2.3 Visual Quote Echodor now has Visual Quote. This allows users of the full screen editor to more easily quote from a message. The use of Visual Quote is intuitive. The first time Ctrl-Q or Ctrl-K is pressed the original message is displayed to the user. The user then uses the up and down arrow keys or the page up and page down keys to move the cursor to the line to be quoted. Then the space bar is pressed. A tag indicator is placed to the left hand side of the line and the cursor is moved to the next line. The user may tag as many lines as desired. When all the desired lines are tagged press Ctrl-Q or ESC to return to the message being written. To insert the lines tagged press Ctrl-Q or Ctrl-K again. A message will appear at the bottom of the screen saying: [I]nsert quote or [T]ag: Page 57 If "I" is pressed the tagged lines will be inserted into the message above the current cursor line. If "T" is pressed the user is returned to the original to allow tagging a new set of lines. If you use the NEWQUOTE option in the EchoDor.Ctl file, after the user tags the lines to be quoted, EchoDor will insert the lines immediately before the cursor. EchoDor pays particular attention to the reformatting of inserted lines. Each inserted line is preceded by "xx>" with "xx" being the initials of the person being quoted. Every line within a paragraph is adjusted to make it correctly fit in the message. Blank lines and paragraph structure will be maintained. Page 58 6.4 Using EchoDor Locally EchoDor also works very well as a local message reader. To use it in this manner, start EchoDor with a batch file something like this: rem rem Set the directory and drive first rem C: cd \EchoDor rem rem Now start EchoDor as the sysop -- this is much like rem local mode but it will log you on with the name you rem specified as the sysop. rem ECHODOR /S rem rem Check for mail to be sent, the name of the SCANLOG.TXT rem file would depend on your configuration. rem rem IF NOT EXIST SCANLOG.TXT GOTO EXIT rem rem Now run the mail packer/scanner (could be CONFMAIL). rem QM SCAN PACK <what ever commands you need> rem rem we're all done rem :EXIT Page 59 6.5 Special local keys While the user is online, EchoDor provides some additional functions to the SYSOP. ALT-I System Information This provides the following information: Baud Rate Local flag Graphics Setting Time Left Com Port User Name Access Level Time credit Time left Node Number ALT-C Forced Chat When ALT-C is pressed, the user is placed into CHAT mode. EchoDor does not provide a split screen chat. To exit chat the SYSOP must press <esc>. ALT-D Drop to DOS This allows the SYSOP to drop to DOS for those Quick checks and fixes. Up Arrow This will add 2 min to the users time. Down Arrow This will subtract 2 min from the users time. Page 60 7.0 Message Header Description Every message in the system contains control information along with the text that is entered by the user. The sysop using EchoDor can modify the information in this header using the Doctor command (Z on the main menu then D). The following fields can be modified: A. From This field contains the name of the person that entered the message. B. To This field contains the name of the person that is to receive the message. C. Subject This field contains the subject of the message. In the case of a file request or file attach type message (see below) this field contains the file name that is being attached or requested. D. Date/Time This is the date and time when the message was entered. The format of this field must be: 16 Jan 90 13:01:05 E. Origin This is the zone:net/node.point number that originated the message. This field is not used with local messages (Type B). F. Destination The is the zone:net/node.point number where the message is going. This field is not relevant in echo message (Type E or I) or in local messages (Type B). G. Cost This is amount of money it costs in cents to send the message. This information is retrieved from the node list. This field is not used for echo messages or local messages. H. Reply When a person enters a reply this is the message number to which he/she is replying. When the message is an initial entry, this field will be zero. I. Next-Reply When a person enters a reply this field is set in the original message to the message number of the reply. When the message is an initial entry, this field will be zero. This field has a special use for echo mail. Message number 1 in an echo area is usually used by the mail processor (CONFMAIL or QM) to point to the highest message that has been scanned. Message number 1 is usually refereed to as the "high water mark". This field contains the message number of the highest message scanned. Page 61 J. Private Messages in all areas may be marked private. If this flag is set to "Yes" then only the sender, the receiver, and the sysop may read the message. Although not allowed in most echoes, EchoDor does support private echo mail messages if present. K. Crash This flag is used to tell the mail processing program to try to get the message sent as soon as possible. Some mailers refer to this type of mail as contentious mail. L. Sent This flag is set by the mail processor to indicate that the message has been bundled to be sent. This flag does not indicate that the message has actually left your system. M. File Attach Some messages are sent with a file. If this flag is set to "Yes" then the subject field will contain the full path name of the file(s) to be sent with the message. N. Kill-Sent After a message is sent, it is usually left in the area from where it came. If this flag is set to "Yes" then the message will be delete after it is bundled by the mail packer. O. Local This flag is set to "Yes" if the message was entered on your system. If the message came from some other system this flag will be set to "No". P. F'req This is a file request flag. If set to "Yes" then the subject line contains the name of a file that you want sent to you from the destination system. Files listed in this type of message should not contain path names. Page 62 8.0 How do file-requests work? When a file request is generated, two files are created and placed in the outbound directory. The first file contains the name of the file(s) that you are requesting from the remote system. The second file specifies how and when the transfer will take place. (i.e. crash-mail, normal, direct, etc.). The stem for each of these files is made up of two four-character hexadecimal numbers specifying the net and node number that the request will be sent to. The first file created is the .REQ file. If this file already exists then it will be appended to. The name of the file being requested is simply placed in the file in plain ASCII. The second file created will have the extension of ".FLO", ".CLO", ".DLO", or ".HLO". This tells the front-end processor how and when the file will be transferred. The various methods are summarized below: Name Ext Description ----------- --- ---------------------------------------------------- Normal FLO Normal transfer. It will occur at the time you specify in your mailer program. Crash-mail CLO The request will be processed at the earliest possible time. Hold HLO Hold-for-pickup. The remote system must poll your system in order to receive the request. Direct DLO This is a direct request. When this file is created no routing will be used, the request will be made directly from the specified BBS. EchoUtil generates file-requests with the "/GET" option. On the command line, you simply need to specify the filename and and the node that you want to request from. Examples: EchoUtil /GET echo308.arc from 300/9 This generates a file request to a system for the file "ECHO308.ARC". It will send this request to node 300/9. Since no other method was specified, it will default to normal and generate a ".FLO" file for the request (as well as a .REQ file). This transfer will take place at national mail hour. EchoUtil /GET echo308.arc from 300/9 C Like the above example, this will request the file "ECHO308.ARC" from 300/9, but it will generate a ".CLO" file instead of a ".FLO" file. Therefore, this transfer will take place at the soonest available time. EchoUtil /GET ECHODOR from 300/9 H Page 63 This example demonstrates a "magic" request. Magic requests are special type of request where you specify a magic file name (in this case, "ECHODOR"). The file must be set up as a magic file on the receivers end as well. The advantage to a magic filename is that the sysop usually has it reference the most recent version of the file you are requesting -- that means you don't have to worry about the exact version number/filename. The "H" on the line specifies that the request will be marked as hold-for-pickup. The request will not be sent out at all and the remote system must call your system for the request to be processed. (This is not usually done). EchoDor can also do file requests with net mail. To enable this feature set the 'F' flag on your net mail description line within the area description table to 'Y'. Each time you enter a message in the net mail area, EchoDor will ask if you want to do a file attach or file request. If you answer "R", meaning request, Echodor will prompt you for a file name. Enter only the file name and extension of the desired file. EchoDor will then precede with the net mail message entry. Page 64 9.0 File-attaches A file attach is a method of sending a file from your system to any remote system. It is very similar to the file-request feature in operation, but no .REQ file is generated. Instead, the filename and path is placed in the FLO/CLO/DLO/HLO file. EchoUtil generates file-requests with the "/SEND" command line option. The syntax is very similar to file-attaching with a few differences shown in the examples below. Examples: EchoUtil /SEND c:\files\echo308.arc to 300/9 This sends the file echo308.arc to node 300/9. The file will be defaulted to normal (.FLO) and sent at national mail hour. The file to be sent (Echo305.arc) is located in the c:\files directory. This an important difference from File-requesting -- With a file-attach, you MUST specify the full path of the file. EchoUtil /SEND c:\files\echo308.arc to 300/9 C This is the same as the above option except the mail will be set to crash-mail (.CLO) and sent at the first available time. EchoDor can also do file attaches with net mail. To enable this feature set the 'F' flag on your net mail description line within the area description table to 'Y'. Each time you enter a message in the net mail area, EchoDor will ask if you want to do a file attach or file request. If you answer "A", meaning attach, EchoDor will prompt you for a file name. Be sure to enter a fully qualified path name (include the drive and directory). EchoDor will check for the existance of the file and if found will continue with the entry of the message. Page 65 10.0 Listing file-requests and file-attaches EchoUtil has the capability to produce a summary of all of your file requests or attaches that are presently in your outbound directory. To produce a list of current outbound file-requests: EchoUtil /REQLIST [INTO <filename>|PRINTER] The INTO parameter is optional and if specified will allow you to send the list to either the printer or a disk-file. To produce a list of all outbound file-attaches: EchoUtil /ATTACHLIST [INTO <filename>|PRINTER] The INTO parameter functions the same as above. upon the execution of this command, EchoUtil will list all of the file-attaches excluding normal arcmail packets (.MOx Files). Page 66 11.0 Auto Messages The "auto message" ability of EchoDor is a very powerful feature that allows you to post news updates about your system in a special area. When a user calls your system, all of the "auto messages" that he has not read will be displayed to him. EchoDor will still honor private messages. If the message is set private then only that user (and any sysop) will see the message. Since the "auto message" area is treated by EchoDor as a normal mail area, it is very simple to enter "auto messages". To set up an auto message area, simply create a directory like you would for any other mail area. Then, add an entry to EchoDor's area table for the auto message area. The entry should be just like a regular message area except set it's type to "A" for auto message. You should also set it to sysop-only to prevent your users from posting in it. You have two ways to use the "auto message" feature. The first and simplest way is to do nothing. When the user enters EchoDor, any auto messages that the user has not seen will be displayed to him/her. The second way requires you to set your BBS to shell out to EchoDor during the users logon process, preferably right after he checks his mail. With RBBS you specify EchoDor as the "Door Program to check users at logon". This is in the "doors setup" section. You need to call EchoDor with either "ECHODOR Node-num /AUTO" or "ECHODOR Node-num /AC" where node-num is the same as the node-number use when you call EchoDor as a door. The "/AUTO" option will simply display all new "auto messages" and the "/AC" option will display all auto messages and then ask the user if he wishes to check for new echo mail messages. This second method allows you to use EchoDor to display messages to all users regardless of them entering EchoDor to read mail. Page 67 12.0 General info 1. Commands can be stacked (r;123 for read msg #123, a;2;r;4;q;a;3 switch to area #2, read message 4, quit to main, and switch to area #3). 2. There are 5 command switches: /L load up the door in local mode. /S run the door locally and log in the sysop. /H get help about the switches. /R return to running EchoDor 3. The system will check for loss of carrier and out of time. If either condition occurs, EchoDor will return back to your BBS. All user information will be saved before exiting. 4. A user will not be kicked off due to time in the middle of a message. 5. You should only log on for a max of 120 minutes at a time. You might be able to log on longer, but the elapsed time functions might have some trouble. 6. You MUST have a fossil driver to run this door, I suggest X00, but OpusCom or BNU should work just as well. 7. If you run net mail you must provide a version 6 nodelist. The nodelist must be compiled with zone information. If you use Parselst be sure to include the "UseZones" command. Starting with v3.10a of EchoDor, registered users can use the new EchoDor format NodeList. This format is most useful for people that run Front Door or D'Bridge. This new format uses index files and the "raw" nodelist files. 8. Messages with more than 512 lines will be truncated by EchoDor. 9. Messages larger than 32K will be truncated by EchoDor. 10. Message areas may not contain more than 5000 messages. Areas with more than 5000 messages will lose their last message pointers when renumbered. Page 68 13.0 EchoUser Program The EchoUser program allows modification of special control information used by EchoDor. The EchoUser program uses the same DoorDriv.Ctl and EchoDor.Ctl file as EchoDor and may be run remote (through the modem). 13.1 User File Records The EchoDor user file contains two different types of records. 13.1.1 Default User & Maintenance Record SECTION The first record in the file is called the Default User & Maintenance record. The record contains information used by EchoDor when setting up new users. Note that changing fields in the Default User & Maintenance record will not alter currently active users. The following fields are important during new user setup: 1. Graphics Mode Some BBS systems do not pass graphics information to EchoDor that works properly. This will cause some users to get garbage on their screens. If the default Graphics mode (Graphics in the Default record) is set to some value other than default, that value will override the value that is passed by the BBS. You can then instruct the users to set their graphics level from the user menu. 2. Default Hot keys Some sysops like hotkeys some do not. The value that is set for hotkeys in the Default record will be the value that every new user receives. This value can be overridden by the user from the user menu. 3. Restrict Message Areas This is one of the most powerful features in the EchoDor / EchoUser system. EchoDor normally controls access to different areas based on the users security level. In many cases this method is adequate. However, some sysops run special areas for their users. Using the Restrict Message Areas, access to specific areas can be "Blocked". Every new user will then be excluded from the "blocked" areas. The "Blocked" will be as if they did not exist. There is no indication given to the user that a blocked area is any different from a non existent area. 4. Sysop Flag The sysop flag cannot be altered in the Default User & Maintenance record. New users will only be set to SYSOP if their name is in the EchoDor.Ctl file. 5. Security Level Some BBS systems do not pass a security level to EchoDor, as an example PC-Board will not pass a security level. By default EchoDor uses the level 50 for these types of systems. In most cases this will work fine; however, cases may arise where it would be better to use a different security when users first use EchoDor. If the Page 69 security level in the Default record is set, that level will be used in place of the BBS passed level. 6. Delete/Undelete The delete/undelete flag cannot be changed in the Default User & Maintenance record. This record can never be deleted. The Default User & Maintenance record also contains a Date Last On. This field is actually the last date when maintenance (EchoUtil /M or EchoUtil /MAINT) was run. 13.1.2 User Records All other records in the User file are regular user records. Using EchoUser you can set specific access rights for individual users. 1. Graphics Mode Normally you will not want to alter the value in this field for specific users. Users can set this from the User Menu within EchoDor. Altering this field will override the graphics information passed in the Door Information file. 2. Default Hot keys Again, this is a user controlled field and you will not normally want to alter this for individual users. 3. Restrict Message Areas Like using this in the Default User & Maintenance record, you can "Block" or "Avail" (available) areas to specific users. If an area is "Block", that user will not have any idea that the area exists. 4. Sysop Flag Sysops can be indicated by having their name in the EchoDor.Ctl file. Adding and deleting sysops in this way can become bothersome. The SYSOP flag in a user record can be set to have EchoDor treat this user like a sysop. 5. Security Level If the Security level for an individual user is set, that security level will be used in place of the security level passed by the BBS. Another user for this, involves SYSOPS. When a sysop logs on locally into EchoDor using the /S option, EchoDor defines a default security level of 1024 for that user. This security level may not be high enough for some setups. To override this 1024 value, enter a security level for the sysop that is adequate. 6. Delete/Undelete The Delete/Undelete section is actually two specific functions. User records in the EchoDor user file can be marked as deleted. When a user is marked as deleted, that user record will NEVER be deleted by EchoUtil. Anytime that user attempts to use EchoDor, he will be denied access to the door. Page 70 The Undelete question will be asked if the user is deleted. If the Undelete questions is answered Y, that user will be returned to a normal user. The NoDelete function is different from the UnDelete question. If a user is marked NoDelete, that user will NEVER be deleted by EchoUtil, and will always have access to the Door. The last selection on the Menu is the User Record Selection section. Before you can change information in a user record or in the Default User & Maintenance record, the record to be changed must be selected. When selecting the record, you first enter a name (or partial name) of the user that you want to change. For the Default User & Maintenance record, enter DEFAULT. EchoUser will then present you with a list of users that match. The names will be preceded by a user number. EchoUser will then ask for the user number to change. Enter the desired number of the user. Then make the needed changes. There is no need to save the changes as this is performed by EchoUser when you either change users or exit the program. 13.2 Remote Operation EchoUser can be run through the modem. The command line to run EchoUser is: EchoUser %1 ^ | + This is replaced with the node number. This is exactly the same way used for EchoDor. 13.3 Local Operation To run EchoUser locally use the command line: EchoUser /S Which will start EchoUser with the SYSOP as fast logon. Page 71 14.0 Using SCANMRG The SCANMRG program is used to combine scan logs generated by EchoDor. A scan log is a list of area names which contain new messages. Normally, EchoDor generates a scan log file. That file is then processed by a mail scanner program and outgoing packets are generated. However, some people only want to run the scanner program once a day. Other people run multiple nodes and only run the scanner from a single node. People that run their boards in this manner need a way to combine scan logs. That is exactly what scanmrg does. The first question you may ask is why not just use copy and append each log to the end of a common file. Ideally if every area was only used once this would work. But, through out the day people will enter multiple messages in the same area. In these cases you want to have that area only listed once. That is the way SCANMRG works. First SCANMRG reads the output scan log into memory. Then it reads each line of the input scan log and compares the just read area name with all the other area names. If the name is new SCANMRG adds it to the list. If it is already in the list, SCANMRG discards the entry. When the last entry from the input file is read, all the entries are written to the output file. The format to use SCANMRG is: SCANMRG infile outfile Where "infile" is the just created input file. And "outfile" is the combined scan logs. If SCANMRG is run and the "outfile" does not exist, one is created. Page 72 15.0 The EchoDor Nodelist compiler Starting with version 3.10a, EchoDor now allows the use of two different types of node lists. The first type of node list is known as a version 6 node list. This node list is most often used with BinkleyTerm mailers. The second type of node list is exclusive to EchoDor. This node list uses the St. Louis node list and three index files to allow rapid access to entries in the node list. This new node list is ideal for people who use Front Door or D'bridge which have proprietary node list structures. During a test the index files for a full FidoNet node list took only 180k plus the size of the "raw" St. Louis node list. This is much smaller than the 1 to 2 megabyte files created when a version 6 node list is used. The node list compiler can not apply node diff files. You must use a separate program to apply the diff's. The node list compiler EchoNLCP is only availble to registered users of EchoDor and is not included in the shareware distribution kit. 15.1 How it works The idea is based on doing a single line compile of the "raw" node list when that line is needed. The only real problem with this is finding the correct line to compile. The correct line is located by EchoDor through the use of three files. The first file is the EchoDIdx.Idx file. The structure of this file is exactly the same as the NodeList.Idx file used in a version 6 node list. This file contains all the net/node numbers that are in all the node lists with special coding for zones and regions. The position of the desired net/node number within this file allows EchoDor to locate the positional information in the next file. The positional information is used to read a specific record from the second index file. This is the EchoDXId.Idx file. This file contains the full zone, net, and node number as well as the node's hub. Also, two other very important pieces of information is contained in the file. They are the file number and the line position. The file number is used to locate the name of the "raw" node list file within the third file called EchoDNLx.Idx. This file is only used when the node list file must be switched. The line position is then used to read a single line of information from the "raw" node list file. The single line of information from the "raw" node list is them compiled by EchoDor "on the fly". Even though the above procedure sounds very slow, EchoDor is able to perform the operations quiet rapidly. You will notice very little difference between the speed of a version 6 node list and the new EchoDor node list indexing system. What you will notice is a lot of disk space available that wasn't there before. Page 73 15.2 The Control file The control file directs EchoNLCP to the node lists that are to be compiled and the directory that is to contain the index files. The following commands are valid in the EchoNLCP.CTL file: DIRECTORY <directory name> This is the diectory where the three index files (ECHODIDX.IDX, ECHODXID.IDX, and ECHODNLX.IDX) are to be placed. This file does not have to be in the EchoDor directory nor does it have to be in the same directory as the St. Louis ("raw") node lists. The <directory name> must match the NODELISTPATH parameter in the EchoDor.Ctl file. There can be only one DIRECTORY parameter. NODELIST <drive:\path\nodelist.fil> This parameter tells EchoNLCP where to find the node list to be compiled. The drive and path are optional; however, you should not use "relative" directories (such as . (dot) and .. (dot, dot)). If the nodelist.file is specified using a wild card, such as NODELIST.*, EchoNLCP will check all occurances and compile the most recent one. Be careful that it dosen't pick up a file that is not a node list file. EchoNLCP will never attempt to compile a file that has an extension of DAT, FDX or IDX. You can specify as many NODELIST lines as needed to compile all the node lists you use. The node list files do not all have to be in the same directory. 15.3 Running EchoNLCP EchoNLCP must be run anytime a change is made to any of the node list files specified in the control file. EchoNLCP cannot apply node diff files. The command line to run EchoNLCP is: ECHONLCP or ECHONLCP cntlfile.ctl The "cntlfile.ctl" file specification is optional. If not specified EchoNLCP will look in the current directory for a file named ECHONLCP.CTL. Operation of the compiler is very fast. 15.4 EchoNLRD node list reader Page 74 I have include a little utility which will allow you to read node list inforation from the node list indexes generated by EchoNLCP. This is a good check to see if all is ok as well as a "quicky" node list look up utility. To run EchoNLRD, go to the directory where the EchoNLCP.CTL file is located and type ECHONLRD. If you are not in the directory where then EchoNLCP.CTL file is located type ECHONLRD drive:\path\EchoNLCP.CTL. This will start the reader and tell it the file to use as a control file. Page 75 16.0 Opus 1.1x Converter (OPUSCNVT) This program is used to convert information in Opus SYSTEM##.DAT files to a format usable by EchoDor. This utility takes two command line parameters. The first is the directory where OPUSCNVT can find the SYSTEM##.DAT files. The second parameter is the file that should be created by OPUSCNVT. For Example: OPUSCNVT C:\OPUS C:\EchoDor\Areatab.Txt In the above example, OPUSCNVT will search the directory "C:\OPUS" for all SYSTEM##.DAT files. After all the information is collected from the files, OPUSCNVT will write a file called Areatab.Txt in the directory C:\EchoDor. This file will only contain AREATABLE & AREADESC entries. The following rules/exceptions are followed by OPUSCNVT: 1. If a SYSTEM00.DAT file exists it will be skipped. 2. All local areas will have a listed tag and an echo name of "Local". 3. All Net Mail aeras will have a listed tag and an echo name of "NetMail". 4. The "No Public" flag is ignored. 5. If there is no separate write priv in the Opus area, Read Priv will be used for WRACC. 6. File request will always be set "N". After running OPUSCNVT you will edit your EchoDor.Ctl file. You would insert a line something like: INCLUDE C:\EchoDor\AreaTab.Txt This would eliminate the need for you to transfer the information from the created file to the EchoDor.Ctl file. Page 76 17.0 Support for EchoDor For support and resistration you can reach me at: Robert McCullough P.O. Box 101095 Nashville, TN 37224 Voice Number 615 256-2444 BBS Support is available from: The WorkBench BBS FidoNet Node 1:116/1000.0 RBBSNet Node 8:967/107.0 Nashville, TN 37210 The BBS Number is 615 256-2211 Available 23 hours a day. 9600 Hst Note: We may be moving soon. We will still be in Nashville. Check the node list for the correct number to use. For registration and support in Europe you can call: Chris Pelling 84 Heathcote Dr East Grinstead West Sussex RH19 1ND ENGLAND BBS support in Europe is available from: SDS Data Design's IBM BBS FidoNet Node 2:254/41.0 Available 8pm-8am GMT 9600 Hst/DS/V42bis 011 +44 342 317 976 Information about EchoDor is also available in the National conference ECHODOR. I understand that the conference is available on the FidoNet backbone and the RBBSNet area. Please check with your net's National Echo Mail Coordinator about the availability of this echo. If you want to register EchoDor, please see the REGISTER.DOC file contained in this archive. Page 77 18.0 Revision History 3.10a revisions (we didn't release a 3.10): 1. When using EchoDor Nodelists, would not show the hub address. 2. Now does times read. This feature is integrated into the renumber/purge utility so that it can tell you if an area has had NO activity. 3. Fixed, INCLUDE/EXCLUDE in EchoNlCp. 4. EchoNLRD can now read V6 node lists. 5. In some cases the NodeList search could go into a loop. Fixed. 6. When sending file attaches, EchoDor would only allow one file to be sent. Now EchoDor will do a file search when using wildcards and will allow multiple files to be specified. The length of the area that allows specification has been increased to the full 72 characters. Also when EchoDor did a file attach, the file name, exactly as entered, was placed in the message. This would sometimes cause the mailer problems if it was in a different directory. EchoDor now puts the file name complete with full path and drive into the message. 7. When doing a message "Copy" EchoDor would say the wrong address, this has been corrected. 8. After issueing a User or Packmail function you couldn't get the menu back except with a question mark (?). This has been corrected so that if a blank or null entry is made the menu will be redisplayed. 9. If the time ran out during a full screen edit, the local screen went strange. This has been corrected. 10. When packing or scanning and the user did not select All and EchoDor found a private message addressed to the user or from the user or the user was a sysop, EchoDor would display/pack the message (whew!) even if it did not fit the requested criteria. Anyway, the scanning and packing is fixed so they will work as expected. 11. Removed the DISPLAY and DISPLAYLN functions from the CONFIG file. These were causing problems with the various programs in EchoDor that have to use this feature. Plus, future versions of EchoDor will not have need of these options. 12. New read/pack/scan option, Mine. Allows reading/packing/scanning only messages addressed to or from the user. 13. The user can now read messages during the scan procedure. All the user has to do is enter the message number he/she wants to read and the message will be displayed. After Page 78 reading the message, the user can enter a new message, reply to the message just read or return to the scan. 14. Once a user started packing mail, there was no way to stop it. Now, if the user presses any key, EchoDor will ask if the user wants to stop. 15. Fixed overwrite problem by more prompt in help system. 16. Removed SYSOP lines from the EchoDor.Ctl file. This feature is now set using the EchoUser program. If the user is logging on as a SYSOP with the /S option, EchoDor will automatically give that person a SYSOP status. 17. Added user alias names. User alias names are automatically activiated when one or more of the message bases allows aliases. 18. Added the ability to send anonymous messages. 19. Added a "MaxLineLength" option in the EchoDor.Ctl file. This option will allow a sysop to force EchoDor to use a shorter line when reading and entering messages. The MaxLineLength range is from 40 - 75. This option is added to compensate for message editors that aren't smart enough to wrap a quote. I sure wish some of the other authors would fix their "brain dead editors"! 20. Visual edit will now show "Private" when entering a private message. 21. Added Read Help file. Enter "?" for help at the read menu. This is currently (or should be if upgrading) set to EchoHLP4. This is the help file that contains the read information. This file is set during startup by a new EchoDor.Ctl command READHELPFILE. 22. When entering a message, EchoDor now allows the message attributes to be altered. These attributes include Private, Crash, Hold, Return Request, and Is Return. The attributes are changed using the Optn function. 23. EchoDor will now generate file update requests. If the netmail area allows file requests, EchoDor will now ask File [R]equest / [A]ttach / [U]pdate. 24. When an update request is entered, EchoDor will change the name so that a fill path name is used. EchoDor will also prevent wildcards from being used with an Update request. 25. If EchoDor timed a user out the user record was not being updated. This caused EchoDor to forget the last read pointers in the current area. This has been corrected. 26. When doing a message copy or a Xerox, EchoDor didn't clear the replyto and next reply numbers. This would produce a strange effect when moved to a different message area. Also, EchoDor didn't set the local flag. This is corrected. Finally, if the message was private, that flag wasn't cleared. Page 79 27. The private flag is now cleared and if the target message area allows private messages, EchoDor will ask if the message should be private. 28. The Visual Editor has an optional modified quote system. The old method required two quote operations for the user to be able to insert quoted lines into the message. If the new method is used (by placing NEWQUOTE in the EchoDor.Ctl file), EchoDor will immediately insert the quoted lines into the message ABOVE the cursor when the user exits quote mode. 29. EchoDor will now confirm when requesting to "kill" a message. An additional Yes/No question is asked. This makes hot keys safer. 30. EchoDor will now confirm when requesting to "abort" a message after entry. An additional Yes/No question is asked. 31. If a user is "deleted" using EchoUser, that user will no longer show up in the "List user" functions. 32. EchoDor has a new read function, this is [F]ile. This allows a sysop to save a message into a named file. When [F]ile is selected from the read menu, EchoDor will request the file name. If the file already exists, EchoDor will ask if you want to overwrite, append, or quit. If overwrite is selected, EchoDor will overwrite the existing contents of the file, if append is selected, the message is appended to the end of the file. 33. EchoDor would remove lines that began with Area: .. these types of lines were generated by RAID. EchoDor is now smarter at removing lines that have "key words" in them such as Area, Path, or SEEN-BY. 34. A problem was found in ECHONLCP which would cause it to put an incorrect net number in node records when the node record immediately followed a ZONE line without a REGION or HOST. This has been corrected. 35. EchoDor now supports Genesis Deluxe, GAP, OPUS 1.7x, and WildCat! version 3.0 bbs's. We no longer support OPUS 1.1x bbs's. 3.09 revisions: 1. EchoDor now has a "DIRECTVIDEO" option in the DoorDriv.Ctl file. This will allow the sysop to configure EchoDor to either use BIOS writes (comment out the DirectVideo line) or direct screen writes (include the DirectVideo line). 2. A new parameter is now available in the EchoDor.Ctl file, this is the "INCLUDE" parameter. This will be most used by sysops that run multiple line systems and want to only maintain one file that contains the AREATABLE and the AREADESC sections. 3. EchoDor will now allow the SYSOP to configure HotKeys. Page 80 4. There was a problem in the origin net/node number when generating Echo mail. This problem would cause UUCP not to function correctly with messages generated by EchoDor. This has been corrected and UUCP should work with EchoDor now. 5. I have included a little utility which will be useful for Opus Sysops that want to use EchoDor. This is the OpusCnvt program. It will read SYSTEM##.DAT files and create a file that contains AREATABLE/ENDAREATABLE & AREADESC/ENDAREADESC sections. If this is used with the INCLUDE option, conversion to EchoDor will be very fast. 6. Four new functions area available when selecting an area. These are the [+]Next Area, [-]Prior area and the [>]Next Area with messages, [<]Prior Area with messages functions. If the user selects "+", EchoDor will move that user to the next area that he/she has set to active. When selecting "-", the user will be moved to the prior area. If the user selects ">", EchoDor will move to the next area that the user has set active which contains unread messages. When selecting "<", EchoDor will move to the prior area that the user has set active which contains unread messages. Also, when changing areas with the plus and minus, EchoDor will tell you if there are new messages in the area. 7. EchoDor now has "Hot Keys". When enabled the menu response is very fast. In places where the user might need to type in multiple characters, the "hot key" feature is disabled. I think you'll like this feature. 8. I have rewritten the Xerox function. The old function would only copy the current message to the current area. The new Xerox function will now allow the sysop to Xerox the current message to any area. 9. I have rewritten the sysop MESSAGE COPY function. The old function would copy a message from any area to the current area. This would confuse some people. The new MESSAGE COPY function will now allow you to copy a message from any area to any area. The default is now from the current area to another area which is the opposite of the old way. 10. There was a problem which would cause EchoDor to tell the user "You Don't have enough time left" when he actually did. This problem was due to an error in the MINTIME function. This has hopefully been corrected. 11. EchoDor will now tell you when you have exited chat mode. Prior to 3.09 you had to guess if you were still in chat after you pressed the ESC key. 12. In versions prior to 3.09 the "AutoMessage" function was only available if you started EchoDor %1 /AUTO. Starting with this version, EchoDor will always execute the "AutoMessage" function when it starts in normal mode. This will allow a sysop to use the "AutoMessage" function without having to run EchoDor twice. Page 81 13. EchoDor now has a [V]iew function available from the read menu. This function is not listed on the read menu but is available to all SYSOPs. The function allows a sysop to see all the ^A kludge lines, the SEEN-BYs, and the PATH lines. This is sometimes useful when trying to track where a message has come from. 14. I have added a new option to the File function when importing files. This function is [F]old lines. This option will retain the line structure, but it will break the lines on word boundaries. This produces a much better appearance than just importing the file. 15. When quoting with the full screen editor, EchoDor now removes all ^A, SEEN-BY, and PATH lines from the message. Old versions prevented the user from quoting the message but the new version removes the lines. This gives the quote a "cleaner" appearance. 16. EchoDor now sets the "received" bit when a message is either read or packed by the receiver. This is also displayed when reading the message and scanning the message. EchoDor also increments the number of "times read" counter in the message. This counter can be used to tell if an area is active. 17. When a user first entered a message base and the first message was not 1 or 2, EchoDor would take a long time to read the first message. EchoDor now keeps both a high message pointer and a low message pointer to an area. This allows EchoDor to go immediately to the first message in an area. Also, the first message number as displayed in the read menu correctly reflects the first real message number. 18. The "Pack All Message Areas" question default has been changed from "Y" to "N". 19. When packing a single area, the starting message number now defaults to the last message read plus 1. 20. A problem was found which could cause Echodor to lock up when packing mail and the user dropped carrier. This problem has been corrected. Now when packing mail, if the user drops carrier, EchoDor will exit normally. 21. EchoDor no longer contains the NODOORMODE parameter. When this parameter was not present, EchoDor displayed it's name and a closing string when exiting. The extra code has been removed along with the parameter. 22. EchoUtil had problems with most of the functions that used the "outbound" area. Hopefully most of these problems have been corrected. 23. EchoUtil no longer contains the /SCAN and /DUMP functions. They have been removed because of their size and because these functions are provided in EchoDor. Page 82 24. EchoUtil can now process message areas that contain 5000 messages. This is 3000 more than prior versions. 25. If EchoUtil /M was run multiple time, it would increment the check messages flag (asking the user to check for private messages) each time it was run. This has been corrected. The counter will only be incremented once per run per day. 26. EchoUtil now has the /RENUM function. This will allow resetting the last read pointers without deleting old users. 27. A problem was found in the EchoNLCP compiler. It would not write the last block to the EchoDXID.IDX file. This would cause EchoDor not to be able to find the last 1000 nodes in the nodelist file. This problem has been corrected. 28. EchoNLCP will now skip files that have an extension of DAT, IDX or FDX. Node list files must never have this extension. 29. EchoNLRD has been enhanced to allow node list searching. This is identical to the operation of the node list option in EchoDor. 30. A new program called EchoUser is now available. This allows you to set individual usre's security and access levels as well as more precisely control new user access. This program will run either remote or local. 3.08 revisions: 1. EchoDor now has new commands in the read menu to allow the user to read a thread. These new commands are plus (+), minus (-), and asterisk (*). 2. Users can now enter messages from the Read menu by pressing the letter "E" for enter. Because this was the old EDIT command, the new command to replace edit is CHANGE which uses the "C" key. 3. The "Doctor" command now understands all the "bits" in a message. This has required some changes in the layout but it should present no problems. 4. EchoDor.Ctl file has been slightly altered. This alteration allows EchoDor to load the file more quickly. See UPDATE.DOC on how to change your file to the new format. 5. Some commands have also been eliminated from the EchoDor.Ctl file. These commands were duplicates of commands already in the DoorDriv.Ctl file. These commands DO effect the display color. Be sure to read UPDATE.DOC on setting new colors. 6. New NodeList format. Starting with 3.08 of EchoDor, a special format Nodelist can be used in place of the Page 83 version 6 nodelist required by prior versions. This new nodelist uses a set of index files to allow use of the RAW nodelist file. This will reduce the amount of disk space required to support EchoDor. (A full nodelist required about 180k plus the raw nodelist file). People running FrontDoor and D'Bridge will gain the most from this feature. Note: Although the unregistered version of EchoDor supports this new nodelist format the compiler which is required to generate these files is included ONLY IN THE REGISTERED VERSION. 7. There are some slight changes in the user interface which should make EchoDor easer to use. 8. The [P]ack Mail feature now allows the user to select the type of compression to use to compress the mail files. 9. There were also problems when returning to EchoDor from [P]acking mail. These problems have been corrected. 10. EchoDor now inserts the new ^AMSGTO: line into outbound messages. 11. The number of lines allowed in a message has been increased from 200 to 512. 12. When displaying a node list entry from the sysop menu, EchoDor now displays the baud rate of the BBS. 13. EchoDor had a problem displaying node list information which contained a password that was 8 characters long. This has been corrected. 14. Long messages would sometime cause EchoDor a run time error. This has been corrected. Now EchoDor will truncate the message to a maximum of 512 lines. 15. EchoDor would always attempt to verify a user when entering into the local message base even if the message wasn't private. This has been corrected so that EchoDor will only verify private messages. 16. EchoDor can now import files when entering messages. This feature is only available when running in local mode. 17. The "read lock" from value could not be set. This has been corrected. 18. The arrow keys on remote systems should now work correctly. Prior to version 3.08, EchoDor would have problems with the special character keys (arrow and such) from slow modems. This has hopefully been corrected. 19. When copying a message EchoDor would not insert the "message copied from" information. This has been corrected. 20. EchoDor had a problem when users returned from a download (using the EchoDor %1 /R line). Sometimes it would reset the time back to when they first entered the door, other Page 84 times it would just forget who was online. This has hopefully been corrected. I have been doing a lot of testing in this area and have not seen the problem with this version. Page 85 19.0 Run Time Errors From time to time EchoDor or one of the support programs may run into problems and generate a "run time" error. The following table lists errors and possible causes: * Error 001 Invalid function number This can occur if your running an older version of DOS. All versions of EchoDor and it's utilities require DOS 3.0 or greater. * Error 002 File not found This is a file not found error. If you get this first try running CheckOut and see if it identifies any missing files. If no errors are reported by CheckOut, look through your EchoDor.Ctl file and check the file names on the parameters that have file names. * Error 003 Path not found This is a path not found error. This is very much like the file not found error above except this error indicates that a directory that you have referenced does not exist. Correct this error like your correcting an 002 error. * Error 004 Too many files open This is the "too many files open" error. This will occur if your FILES=xx in your CONFIG.SYS file isn't big enough. The xx should be at least 20. * Error 005 File access denied This is a file access denied message. If you receive this please try to reproduce it. If you can reproduce it, please notify me so that I can fix the problem. * Error 006 Invalid file handle This is an invalid file handle error. First try to recopy EchoDor.EXE (or whichever program gave you the error) from your original release back to your disk drive. If you receive this error again, please notify me. Have you EchoDor.Ctl file and your DoorDriv.Ctl file available when you call. * Error 012 Invalid file access code This error indicates an access error. First try to recopy EchoDor.EXE (or whichever program gave you the error) from your original release back to your disk drive. If you Page 86 receive this error again, please notify me. Have your EchoDor.Ctl file and your DoorDriv.Ctl file available when you call. * Error 015 Invalid drive number This error is only reported by MkDir or ChDir. There is no MkDir or ChDir in EchoDor. First try to recopy EchoDor.EXE (or whichever program gave you the error) from your original release back to your disk drive. If you receive this error again, please notify me. Have your EchoDor.Ctl file and your DoorDriv.Ctl file available when you call. * Error 016 Cannot remove current directory This error is only reported by RmDir. There is no RmDir in EchoDor. First try to recopy EchoDor.EXE (or whichever program gave you the error) from your original release back to your disk drive. If you receive this error again, please notify me. Have your EchoDor.Ctl file and your DoorDriv.Ctl file available when you call. * Error 017 Cannot rename across drives This error is only reported by Rename. There is no "Rename" in EchoDor. First try to recopy EchoDor.EXE (or whichever program gave you the error) from your original release back to your disk drive. If you receive this error again, please notify me. Have your EchoDor.Ctl file and your DoorDriv.Ctl file available when you call. * Error 100 Disk read error This will generally indicate some sort of disk problem. To quickly check to see if the error is caused by a problem with one of the EchoDor files ... get to dos and switch to the EchoDor directory. Then attempt to copy all the files to the nul device: COPY *.* NUL This will cause DOS to read each of the files but the copy will not put them anywhere. If you get an error during the copy, replace the file that copy indicates is in error and try the copy again. If you don't get an error when you do this, check your message base. Go to the message area that the user was in when the error occured and try the above copy in that directory. If a #.msg file is found to be in error, delete the file. If no errors are still found, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 101 Disk write error Page 87 This indicates some sort of disk problem. First check to make sure your not out of disk space. Check both the drive that the message base is on and the drive that Echodor is on (if different). If you have sufficient space, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 102 File not assigned This error could indicate a program problem. First recopy EchoDor.EXE (or whichever program gave you the error) from your original release. If you still get the error, please notify me. Have your EchoDor.Ctl and your DoorDriv.Ctl files available when you call. * Error 103 File not open This error could indicate a program problem. First recopy EchoDor.EXE (or whichever program gave you the error) from your original release. If you still get the error, please notify me. Have your EchoDor.Ctl and your DoorDriv.Ctl files available when you call. * Error 104 File not open for input This error could indicate a program problem. First recopy EchoDor.EXE (or whichever program gave you the error) from your original release. If you still get the error, please notify me. Have your EchoDor.Ctl and your DoorDriv.Ctl files available when you call. * Error 105 File not open for output This error could indicate a program problem. First recopy EchoDor.EXE (or whichever program gave you the error) from your original release. If you still get the error, please notify me. Have your EchoDor.Ctl and your DoorDriv.Ctl files available when you call. * Error 106 Invalid numeric format This error could indicate a program problem. First recopy EchoDor.EXE (or whichever program gave you the error) from your original release. If you still get the error, please notify me. Have your EchoDor.Ctl and your DoorDriv.Ctl files available when you call. * Error 150 Disk is write protected This indicates a write protected disk. If your running from floppies, check to make sure there is no write protect tab on the disk. If your running from hard disk, first try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the Page 88 error) from your original release. If the problem still occurs, please call me and have a copy of your EchoDor.Ctl and your DoorDriv.Ctl files available. * Error 151 Unknown unit This indicates DOS could not find a specified unit. First try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, please call me and have a copy of your EchoDor.Ctl and your DoorDriv.Ctl files available. * Error 152 Drive not ready This indicates a specified drive was not ready. First try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 153 Unknown command This indicates a drive did not understand what DOS wanted the drive to do. First try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 154 CRC error in data This indicates a problem exists when trying to read data from a file. First try the procedure outlined for Error 100. If that dose not work, try reinstalling EchoDor. * Error 155 Bad drive request structure lenght This is an internal DOS error. First try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 156 Disk Seek error This is a disk problem. First try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). Page 89 * Error 157 Unknown media type This is a disk problem. If your running from diskette, try using another formatted diskette. If your running from a hard disk try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 158 Sector not found This is a disk problem. If your running from diskette, try using another formatted diskette. If your running from a hard disk try a reboot. If the problem occurs again try copying EchoDor.EXE (or whichever program gave you the error) from your original release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 159 Printer out of paper This will only happen if you try to do an HCOPY and your printer is out of paper. Correct the problem and try again. * Error 160 Device write fault An error occurred while trying to write to the disk or printer or screen. First try a reboot. If the problem occurs again try copying a new copy of EchoDor.EXE (or whichever program gave you the error) from your origional release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). * Error 161 Device read fault An error occurred while trying to write to a device. Correct as for Error 160. * Error 162 Hardware failure This is a general hardware failure. If this occurs try First try a reboot. If the problem occurs again try copying a new copy of EchoDor.EXE (or whichever program gave you the error) from your origional release. If the problem still occurs, you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). If it still occurs, you may need service. * Errors 200-214 This error could indicate a program problem. First recopy EchoDor.EXE (or whichever program gave you the error) from Page 90 your original release. If you still get the error, please notify me. Have your EchoDor.Ctl and your DoorDriv.Ctl files available when you call. Page 91 20.0 Plans for next version Further ability in the EchoNLCP compiler. UNIX e-mail and news group support. With this addition EchoDor will understand how to write message to be understood by UUCP. Separate IGNORE system for reading and packing. Time estimates for downloads. Hopefully we will also be able to support off-line readers like XRS and Opus express. If we get this in, there will be a new PACKMAIL command called Export. Ability to upload a message. Page 92 21.0 Registration EchoDor represents MANY hours of work and if you find it useful, I would appreciate your sending in a donation of $25 or more. I will send you back a DSDD 5.25" disk or a 3.5" disk with the latest copy of EchoDor, EchoNLCP, EchoNLRD and perhaps a few other small utilities that will fit on it. My address is: Robert McCullough P.O. Box 101095 Nashville, TN 37224-1095 When you register, please send me you name, address, voice phone, BBS name, BBS type, BBS phone, and where you got EchoDor. I'd like to thank the people that have supported EchoDor through their registration. I will continue to support the users of EchoDor in a professional manor and will hope to receive your support in return. Also, if you use RASMAM be sure to follow the authors registration requirements. Registration of EchoDor does NOT give you a registration to RASMAM. Page 93 22.0 Disclaimer This program is being distributed under the following conditions: 1. This code or any of the files associated with it may not be distributed in modified form in any way. You may archive this program and it's associated files in any manor that is suitable for your BBS. Please do not delete any files from the archive. 2. You may not use any portion of the code distributed with this package in any other program without my written permission. 3. This software and/or code may not be distributed for a profit. This does not exclude the archive from being on a pay for use BBS. 4. I am in no way responsible for any damage that may be caused due to the use or misuse of this software. The user assumes all responsibility for any damages and holds the author harmless. Page 94 23.0 Guarantee There is absolutely no guarantee, warranty or promise of any kind made with regard to the performance or quality of the EchoDor software, utilities, documentation, or any associated files. Any problems, risks, damages, disasters or lack of them are purely you're responsibility. By using this software, documentation, utilities, or any associated materials, you acknowledge this in full. Page 95 Contents Chapter 1 Introduction 1 Chapter 2 INSTALLATION 2 Chapter 3 DoorDriv.Ctl parameter file 5 3.1 Multiple DoorDriv.Ctl files . . . . . . . . 5 3.2 Parameters . . . . . . . . . . . . . . . . . 5 3.3 Color Table . . . . . . . . . . . . . . . . 9 3.4 PC Board 14 . . . . . . . . . . . . . . . . 10 3.5 PC Board 12 . . . . . . . . . . . . . . . . 10 3.6 Opus 1.1x . . . . . . . . . . . . . . . . . 10 3.7 GT PowerComm . . . . . . . . . . . . . . . . 10 3.8 Genesis Deluxe . . . . . . . . . . . . . . . 10 3.9 LINE-A operation . . . . . . . . . . . . . . 10 3.10 LINE-B operation . . . . . . . . . . . . . 11 Chapter 4 ECHODOR.CTL parameter file 12 4.1 Files . . . . . . . . . . . . . . . . . . . 12 4.2 Parameters . . . . . . . . . . . . . . . . . 12 4.3 SYSOP setup . . . . . . . . . . . . . . . . 26 4.4 Pack Mail / Compress / Download Setup . . . 27 4.4.1 Basic Setup . . . . . . . . . . . . . . 27 4.4.2 Compressing Mail . . . . . . . . . . . 27 4.4.3 Downloading Mail . . . . . . . . . . . 29 4.5 Multiple Node Setup . . . . . . . . . . . . 32 4.5.1 The Common Directory Method . . . . . . 32 4.5.2 Multiple Directory Method . . . . . . . 34 4.6 Multiple Net Setup . . . . . . . . . . . . . 38 Chapter 5 Purging & Renumbering Areas 40 5.1 The Three Step Method . . . . . . . . . . . 40 5.2 EDorPurg . . . . . . . . . . . . . . . . . . 41 5.2.1 Setup . . . . . . . . . . . . . . . . . 41 5.2.2 EDorPurg Parameters . . . . . . . . . . 43 5.2.3 Operation . . . . . . . . . . . . . . . 45 5.2.4 Recovery Method . . . . . . . . . . . . 45 5.3 FastLink . . . . . . . . . . . . . . . . . . 47 5.3.1 Parameters . . . . . . . . . . . . . . 47 5.3.2 Operation . . . . . . . . . . . . . . . 48 5.3.2.1 After Tossing Mail . . . . . . . . 48 5.3.2.2 After EDorPurg . . . . . . . . . . 49 Chapter 6 EchoDor Operation 50 6.1 Menu Commands . . . . . . . . . . . . . . . 50 6.2 Reading messages . . . . . . . . . . . . . . 52 6.3 Entering messages . . . . . . . . . . . . . 55 6.3.1 Line Editor . . . . . . . . . . . . . . 55 6.3.2 Full Screen Editor . . . . . . . . . . 56 6.3.2.1 Insert Mode versus Overtype Mode . 57 6.3.2.2 Keyboard emulation . . . . . . . . 57 6.3.2.3 Visual Quote . . . . . . . . . . . 57 6.4 Using EchoDor Locally . . . . . . . . . . . 59 6.5 Special local keys . . . . . . . . . . . . . 60 Chapter 7 Message Header Description 61 Chapter 8 How do file-requests work? 63 i Chapter 9 File-attaches 65 Chapter 10 Listing file-requests and file-attaches 66 Chapter 11 Auto Messages 67 Chapter 12 General info 68 Chapter 13 EchoUser Program 69 13.1 User File Records . . . . . . . . . . . . . 69 13.1.1 Default User & Maintenance Record . . 69 13.1.2 User Records . . . . . . . . . . . . . 70 13.2 Remote Operation . . . . . . . . . . . . . 71 13.3 Local Operation . . . . . . . . . . . . . . 71 Chapter 14 Using SCANMRG 72 Chapter 15 The EchoDor Nodelist compiler 73 15.1 How it works . . . . . . . . . . . . . . . 73 15.2 The Control file . . . . . . . . . . . . . 74 15.3 Running EchoNLCP . . . . . . . . . . . . . 74 15.4 EchoNLRD node list reader . . . . . . . . . 74 Chapter 16 Opus 1.1x Converter (OPUSCNVT) 76 Chapter 17 Support for EchoDor 77 Chapter 18 Revision History 78 Chapter 19 Run Time Errors 86 Chapter 20 Plans for next version 92 Chapter 21 Registration 93 Chapter 22 Disclaimer 94 Chapter 23 Guarantee 95 ii