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 / RBBS_PC / 173_DOC.ZIP / RBBSDOC2.ASC < prev

Wrap

Text File | 1990-02-11 | 396.8 KB | 7,279 lines

RBBS-PC CPC17.3 Page 136 10. THE HAYES MODEM SWITCH SETTING AND CONSIDERATIONS ----------------------------------------------------- 10.1 Hayes Smartmodem 1200 Switch Considerations ------------------------------------------------ The proper switch settings for an EXTERNAL Hayes 1200 modem are: switch -- 12345678 setting - UUDDDUUD Recognizing that there are many "Hayes-compatible" (and not so compatible) modems in use, this section is intended to assist those adventurous souls who use such modems and need some guidance on what the otherwise mystical Hayes switch settings mean. The following table may be of some help: Setting Function to RBBS-PC Hayes | Factory | RBBS-PC | Switch |---------|---------| (NOTE "Up" means enabled or "on") 1 Down Up Allows RBBS-PC to control the modem using the RS-232 DTR lead (pin 20). 2 Up Up Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be English words or single digits. RBBS-PC sets this with the Hayes "V" command. 3 Down Down Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be sent to RBBS-PC. RBBS-PC sets this with the Hayes "Q" command. 4 Up Down The modem does not echo characters unless half-duplex is selected and the modem is on-line. 5 Down Down Modem is NOT to answer incoming calls. RBBS- PC monitors the ring indicator (pin 22) to determine if the phone is ringing. If it is, RBBS-PC will issue the necessary commands to the modem. 6 Down Up RBBS-PC checks for the carrier signal using the RS-232 Carrier Detect lead (pin 8). If carrier is lost, RBBS-PC hangs up the phone and re-cycles to await the next call. 7 Up Up Not really required by RBBS-PC. However in the "down" position, the telephone extension light will illuminate on a multi-line installation when the modem answers a call. 8 Down Down Enables the Smartmodem 1200 to recognize the Hayes commands issued by RBBS-PC. The most common problem, "RBBS-PC continually recycles," occurs when switch six is left in the factory position. RBBS-PC CPC17.3 Page 137 These switch settings do not have to be changed for most other communications software packages. However, Your communications software should issue a modem reset (command ATZ) before using the modem. RBBS-PC should be used only with versions 123 and above of the Hayes Smartmodem 1200 and with version 247 and above of the Hayes Smartmodem 2400. Earlier versions do not answer the telephone properly. The ATI command will cause the Smartmodem to tell you its version. Hayes also shipped an external modem called the Hayes 1200FE that had 10 switch settings. To run RBBS-PC switches 9 and 10 of the 1200FE must be left up (the factory setting). Hayes also ships an internal modem called the Hayes 1200BFE that has 6 switch settings. To run RBBS-PC switches 4, 5, and 6 must be left up (the factory setting). If you can't figure out what the switching settings on these new modems should be based on the switch settings given for the "original" Hayes 1200, CALL HAYES TECHNICAL SUPPORT! RBBS-PC CPC17.3 Page 138 10.2 Hayes Command's Considerations ----------------------------------- The commands used to control the modem may be modified using CONFIG parameter 225. The commands, and their meanings, are as follows: 10.2.1 Command to Reset the Modem --------------------------------- The modem reset command is the first option in CONFIG parameter 225 and it's default value is the Hayes command string: Command Meaning AT Signifies the following characters are Hayes commands. Z Causes a software reset and applies all default values. This command is ALWAYS issued and is the first command issued to the modem every time RBBS-PC gets ready for calls. 10.2.2 Command to Initialize the Modem -------------------------------------- The modem initialization command is ALWAYS issued and is the second command issued to the modem every time RBBS-PC gets ready for calls. The modem initialization command is the second option in CONFIG parameter 225 and it's default value is one of the following Hayes command strings. If CONFIG has been used to set RBBS-PC to answer on a ring greater than zero, the command string is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q1 Do not return result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more than seconds (you may want to set this to 15) E0 Do not echo characters back to the PC when receiving Hayes commands. Q0 Send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. S0=x "x" is set as follows: S0=254 to answer on a specific number of rings > 0 S0=255 to enable "ring-back" RBBS-PC CPC17.3 Page 139 If CONFIG sets RBBS-PC to answer on zero rings, the command string is: Command Meaning AT Signifies the following characters are Hayes commands. M0 Turn the monitor speaker on the modem off permanently. Q1 Send result codes to the PC. S2=255 Disable escape code detection. S10=30 Do not drop disconnect user unless carrier drops for more than seconds. Some of the Hayes ROM's have a bug in them that causes the modem to only answer at 1200 baud if anything other than the factory default is used for S10. If you have such a problem, simply set S10 equal to 7. E0 Do not echo characters back to the PC when receiving Hayes commands. Q0 Send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. S0=1 Answer the phone on the first ring. Q0 Send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. 10.2.3 Command to Count The Number of Rings ------------------------------------------- The modem command that counts the number of rings is the third option in CONFIG parameter 225 and it's default value is the following Hayes command string : Command Meaning AT Signifies the following characters are Hayes commands. S1? Requests the modem to return the number of times that the phone has rung. This command string is only issued when CONFIG has been used to tell RBBS- PC to answer on a specific number of rings other than 0. Some modems have trouble with the S1? command because they do not recognize the ? part of the command. Again, verify what your modem is capable of handling. 10.2.4 Command to Answer the Phone ---------------------------------- The modem command to answer the phone is the fourth option in CONFIG parameter 225 and it's default value is one of the following Hayes command string : Command Meaning AT Signifies the following characters are Hayes commands. Q0 Tells the modem to send result codes to the PC. X1 Tells the modem to send "extended" result codes to the PC. V1 "Extended" result codes are to be transmitted as words. A Tells the modem to answer the phone immediately. This is only issued if the number of rings to answer on is greater than 0. RBBS-PC CPC17.3 Page 140 RBBS-PC utilizes the extended verbal results code (CONNECT, CONNECT 300, CONNECT 1200, and CONNECT 2400) to determine the callers baud rate. Some Hayes 300 modems don't function with RBBS-PC because they do not recognize the "X1" command. If you have a modem like this, simply remove the X1 command from the command strings in the .DEF file. 10.2.5 Command to Take the Phone Off the Hook --------------------------------------------- The modem command to take the phone off the hook is the fifth option in CONFIG parameter 225 and it's default value is the following Hayes command string : Command Meaning AT Signifies the following characters are Hayes commands. Q1 Do not return result codes to the PC. E1 Echo characters back to the PC when handling Hayes commands. H1 Take the modem off the hook (i.e. busy out the line). M0 Turn the monitor speaker on the modem off permanently. This command is ALWAYS issued whenever the SYSOP is doing local maintenance (i.e. hits ESC) or a user hangs up. 10.2.6 Firmware Initialization ------------------------------ The commands to initialize the modem firmware are not contained in the .DEF file, but rather are dynamically set (or reset) each time that CONFIG is invoked. There are essentially three commands: 1. A command to clear the modem's firmware. 2. A command to initialize the modem's firmware. 3. The command to write the initialized firmware to the modem's non-volatile memory is "&W". The modem command to clear the modem's firmware is the sixth option in CONFIG parameter 225 and it's default value is the following Hayes command string: Command Meaning AT Signifies the following characters are Hayes commands. &F Load the modem active configuration area with the factory profile contained in the Hayes ROM. RBBS-PC CPC17.3 Page 141 The modem command to initialize the modem's firmware is the seventh option in CONFIG parameter 225 and it's default value is the following Hayes command string: Command Meaning AT Signifies the following characters are Hayes commands. &C1 Data carrier detect tracks the state of the data carrier from the remote modem. &D3 Modem is to assume the initialization state if it detects ON- to-OFF transition of DTR. The newer versions of the Hayes 2400 baud modem (ROM 249 or greater) and some clones do not allow RBBS-PC to recycle properly when the &D switch is set to 3. If you are having a problem, set the it to &D2. B1 Set the modem to Bell 212A mode when the 1200 BPS data transfer rate is selected. E0 Do not echo characters of the modem commands issued by RBBS-PC back to the PC running RBBS-PC. V1 Select long-form result codes. M0 Disable the modem's speaker when carrier is detected. S0=0 Disable "auto-answer" mode. &T5 Disallow a request from the remote modem for a remote digital loopback test. The modem command to write the initialized firmware to the modem's non- volatile memory is the sixth option in CONFIG parameter 225 and it's default value is the following Hayes command string: Command Meaning &W Write the firmware settings to non-volatile memory These three commands are ALWAYS issued in CONFIG when parameter 231 is selected. These commands can be temporarily altered by changing them via parameter 225 of CONFIG prior to invoking parameter 231. RBBS-PC CPC17.3 Page 142 10.2.7 Smartmodem 9600 Firmware Initialization ---------------------------------------------- The Hayes V-series Smartmodem 9600's active configuration should be: B1 -- Factory setting E1 -- Factory setting L1 -- Low speaker volume (unless you like noise). M1 -- Factory setting N1 -- Factory setting Q0 -- Factory setting T -- touch tone (could be "P" for pulse dial). V1 -- Factory setting W1 -- Modem reports error-control call (i.e. LAP-B/HDX). X1 -- Send result basic result codes plus CONNECT 1200, 2400, etc. Y0 -- Factory setting &C1 -- Factory setting &D2 -- Disable auto-answer when carrier drops. &G0 -- Factory setting &J0 -- Factory setting &K3 -- Factory setting &L0 -- Factory setting &P0 -- Factory setting &Q5 -- Factory setting &R0 -- Factory setting &S1 -- Data Set Ready operates according to RS-232C standards. &T5 -- Deny requests for remote loop back tests from calling modem. &X0 -- Factory setting &Y0 -- Factory setting S00:254 -- Let phone ring 254 times before automatically answering it. S01:000 -- Factory setting S02:043 -- Factory setting S03:013 -- Factory setting S04:010 -- Factory setting S05:008 -- Factory setting S06:002 -- Factory setting S07:054 -- Assume no carrier is detected within 54 seconds of answering. S08:002 -- Factory setting S09:006 -- Factory setting S10:030 -- Let carrier drop for up to 30 seconds before disconnecting. S11:095 -- Factory setting S12:050 -- Factory setting S18:000 -- Factory setting S25:005 -- Factory setting S26:001 -- Factory setting S36:001 -- Factory setting S37:000 -- Factory setting S38:020 -- Factory setting The Hayes V-series Smartmodem 9600's have non-volatile memory that contains three different possible configurations -- 1. the active configuration, 2. the profile 0 configuration, and 3. the profile 1 configuration. To utilize the Hayes V-series 9600 modems with RBBS-PC, it is necessary that the SYSOP RBBS-PC CPC17.3 Page 143 1. set the active configuration as shown on the previous pages, and 2. write this active configuration to profile 0 with the &W0 command. This can be done by temporarily re-CONFIGuring the default modem firmware initialization commands via parameter 225 (items 6, 7, and 8) before initializing the Hayes Smartmodem 9600's firmware via parameter 231. RBBS-PC is able to interface with the Hayes V-series Smartmodem 9600 at 300, 1200, 2400, 4800, and 9600 baud. When operating at the two highest baud rates, the Hayes V-series Smartmodem 9600 is limited to connecting with only other Hayes V-series Smartmodem 9600's. RBBS-PC recognizes whenever the Hayes version of error-correction protocol, "LAP-B", is enabled between the caller and RBBS-PC. RBBS-PC has been tested with the above active configuration and no problems have been encountered using the "internal" protocols supplied with RBBS-PC. Questions regarding the Hayes V-series 9600 modems and any of the "external" protocols which a SysOp may choose to make available should be addressed to the authors of such protocols. RBBS-PC CPC17.3 Page 144 11. RBBS-PC's FILE MANAGEMENT SUBSYSTEM ---------------------------------------- The File Subsystem allows RBBS-PC to maintain a list of files available for downloading. Users can list files by date, category, or by using a search argument. RBBS-PC refers to a file that contains a list of files available for downloading as a "directory" (i.e. a .DIR file). There are two ways to configure the File System. One is to have multiple separate "directory" files. The other is to have a single master "directory" file (i.e. a single FMS file) that contains the names, sizes, dates, and description of all the files available for downloading. You may use both ideas at once if you wish. It is perfectly allowable to use the master FMS directory as well as the smaller ones. CONFIG parameter 215 controls whether RBBS-PC looks beyond the FMS directory. If you have any separate directories, set 215 to NO. If you have only a single FMS directory, set parameter 215 to YES. If directory searches are not limited to the FMS directories and RBBS-PC does not find the category in the FMS listing, it will look for the old-style DIR files. RBBS-PC CPC17.3 Page 145 11.1 Multiple Directory Format ------------------------------ The multiple directories, also referred to as the old-style directories, are simply text files. These files are indentified by their file extension, specified in CONFIG, common to all the directories. The default extension is .DIR, but it can be changed via parameter 209. There is a directory which lists the directory names and their descriptions whose name is specified via parameter 211 of CONFIG. Each directory is simply a text file. It may have anything in it, including ANSI codes. The only restriction is that in order for the N)ew command to work properly, the date must be somewhere in the first 31 characters. A file is classified in a directory simply by being put into the file. The SysOp can allow the caller to classify uploads (by setting the minimum security for classifying to a low enough value). All uploads must go into a single directory, called the upload directory, specified in parameter 202, and it will be in the drive\path specified in parameter 203. All other directories must be in the drive\path specified in parameter 220. This includes the FMS directory (MASTER.DIR) and the list of DIR files, (DIR.DIR). There are, therefore, four logical areas into which the file subsystem is divided. Each one may reside in a separate DOS directory, or all of them may be lumped together into one main directory. Logical Area CONFIG 1. The files for DOWNLOAD parameter 204, parameter 205, and parameter 207 2. The files that have been uploaded parameter 201 and parameter 206 3. The upload directory file listing. parameter 202 and parameter 203 4. The download directory files. parameter 220 The files in the download directory are the only files that may be downloaded. The SysOp may elect to have the upload directory also a download subdirectory. This can be done by specifying it in the download "PATH". One interesting feature of the File Subsystem is that you can build a "chain" of drives and subdirectories to search for a given file. The SYSOP, via parameter 204, can list the order of the drives to be searched when RBBS-PC is looking for the file to be downloaded. The parameter is specified with simply the letters, together. For example: BAC would search Drive B, then Drive A, then Drive C. Use this parameter if you want to search more than one drive. If the files are not in the default directory then you need to use the CONFIG parameter 205 and parameter 207. Parameter 205 specifies that you want to sue DOS sub-directories and parameter 207 allows you to list them. Use drive:\path format. Multiple directory .DIR files and the single FMS directory entry formats are the same (see section 11.4) except that the old style separate directories need not be fixed length and don't include the category code. Any directory can be in the Single FMS format. This allows special purpose directories to be put into FMS format so they can take advantage of such RBBS-PC CPC17.3 Page 146 features as resumable listings normally associated just with the Single FMS environment. An unlimited number of lines of text can be added to any description (see CONFIG parameter 40, parameter 148, and parameter 153). The file directories have absolutely no bearing on what is in the subdirectory. A file can be listed but not exist, and a file, such as one uploaded with the / for SYSOP option, may exist but not be entered. The file directories are simply methods to get the caller a listing of the files available. RBBS-PC CPC17.3 Page 147 11.2 The Single and Chained FMS Directory Format ------------------------------------------------ FMS logically just lumps all the old style separate directories into one directory file, called the MASTER or FMS directory, and assigning each file a CATEGORY CODE, which may correspond to the directory it was in the original directories. A utility program called CNVDIR.EXE will do exactly this: combine the separate directories and add the category code at the end. If you do not already have separate directories, simply set it up with a text editor using the columns indicated. Beginning with CPC17-2A FMS directories can be "chained". This means that physically separate files can be logically combined to form a single FMS directory. This is accomplished by putting the following in the header record (a header record in an FMS directory is the first record and must begin with "\FMS "): CH(<chain to>) where <chain to> is the name of the file to chain to. As an example \FMS CH(C:\DIRS\CHTO.DIR) would chain to the file "C:\DIRS\CHTO.DIR". Names of files not in the default directory must have a drive and/or path specified. The directory chained to can in turn have a chain, and there is no limit to the number that can be chained together. Note that this "header" record must have the same length as the rest of the lines in the directory, and will usually have to be padded out with blanks. The directory chained to is an independent FMS directory and can be anywhere and have any extension. A given directory can have at most one directory to chain to. Chained directories can be used to keep the upload directory small for easier editing, or to better fit the latest directories on a fast RAM disk while keeping older directories on a slower hard disk (e.g. a SYSOP divides the directories into UPLOADS.DIR, 87.DIR, 86.DIR, 85.DIR, and 84.DIR to reflect the year in which the file was created/uploaded). RBBS-PC CPC17.3 Page 148 11.3 Advantages/Disadvantages of FMS Directory ----------------------------------------------- Having a FMS directory has the following advantages: 1. Callers get the newest files listed first. The directory can be displayed EITHER from top to bottom or bottom to top. Reading from bottom up is appropriate when files are in date order and new files are appended to the bottom. When files are alphabetized or grouped some other way, it is more appropriate to read them from the top down. 2. The directory is listed with MORE ([Y],N) or files to download prompts throughout the listing, so at any time the caller may begin downloading, and pick up where they left off in the listing after the download is completed. 3. Wildcard searches on filenames are supported as well as exact matches on strings in the file S)earch command. Whenever a wild card character (* and ?) is specified in the search string, RBBS-PC will automatically shift to matching just the file name. Exact string matches search the full entry rather than just the file name. String searches include extended descriptions for FMS directories, but in non-FMS directories only the first line of the file description is searched. 4. Classification of files is easy. All that is necessary is an editor that produces ASCII files, and a file is classified by a category code of up to 3 characters. To change a file from directory to directory, all that is necessary is to change the category code. No more "erase it here and add it there." 5. No SYSOP maintenance is necessary for new uploads. The caller can classify the upload with a category code, and the SYSOP can specify that the new uploads become instantly available. 6. Complex classifications can be made very simply. A category code is not necessarily the category the caller must type in. The SYSOP can elect to have a classification system where one code that the caller types in will list several different category codes. You can include the file in two directories without having two separate entries. 7. FMS directories can have "headers" (i.e. free text lines not associated with any particular file). This allows things like column headers or help to be included, as well as section headers. A SYSOP may wish to separate a "communications directory" into different sections such as one for QMODEM and one for RBBS-PC. A free text line begins with "*" and is universally displayed if the category code is "***" otherwise it is only displayed when the category associated with the line is selected. 8. Multi-line descriptions (i.e. "extended" descriptions) are supported in both FMS and "old-style" directories. All columns except the first one are available for the description. For FMS directories extended descriptions have the same characteristics as the file that they are associated with. 9. The ability to enter "extended" descriptions for uploaded files is based on the caller's security level (see CONFIG parameter 127). 10. Caller's can list the RBBS-PC file directories with or without extended description. As an example, a caller would enter the command "L - UPLOADS" RBBS-PC CPC17.3 Page 149 to list the files in the directory UPLOADS with only one line descriptions. The command "L + UPLOADS" would list the same file with extended descriptions. 11. Archived files can be viewed with the V)iew command when listing FMS directories and the listing will resume where it left off prior to issuing the V)iew command. 12. Individual entries within a FMS directory can be restricted to specific security levels. 13. Comment lines can be included in FMS directories which are never shown to a caller. Often such comments are useful reminders to the SYSOP who is maintaining the FMS directories. 14. Callers can add upload descriptions without actually uploading a file (see CONFIG parameter 153). This is typically useful to the SYSOP. It makes it easy to start an FMS upload directory without having to know anything about its internals or how to use an editor. With the exception of a CORVUS network environment, FMS directories can be updated without taking the system down first. All the caller does is issue the normal upload command. If RBBS-PC finds that the file already exists and that the caller has the necessary security level, RBBS-PC will get the file size and proceed exactly as if the file had just been uploaded. 15. Searches for new files is EXTREMELY fast because RBBS-PC does not have to search all directories if the single FMS directory is in date order (most recent date last) 16. Latest uploads are always shown first, if the SYSOP has elected to make them viewable and the master FMS is in date order. 17. Searches for text will scan the text in the extended multi-line descriptions. 18. Composite categories can be logically constructed out of other categories (see section 11.5). 19. Entries do not have to be physically moved to other .DIR files to be classified as belonging to it. 20. FMS directories can be "chained" to accommodate those multi-user environments, such as Corvus's OMNINET, which will not allow files that change in length to be shared. In such an environment FMS can be used, but the FMS directory must "chain" to the upload directory and their must be a separate upload directory for each node. RBBS-PC CPC17.3 Page 150 Regrettably, the FMS directory also has ONE remaining limitations which may make it unsuitable for all SYSOPs needs. 1. The date must be in MM-DD-YY format. Any single digit number must have a leading zero. If FMS does not totally satisfy your needs, you can use both. RBBS-PC can be configured to look for an old style directory if it does not find a directory in the FMS. If it finds one it will display it. If it does not, it displays the familiar "Directory XXX not found!" message. RBBS-PC CPC17.3 Page 151 11.4 Creating FMS Directories ------------------------------ If you already have separate directories, it would be a good idea to copy all of them into a single one called MASTER.DIR. Detailed directions are given in the documentation for CNVDIR. In DOS this can be done like this: COPY xxx.DIR+xxx.DIR+xxx.DIR... MASTER.DIR where xxx is the name of the old style directories. The 3 dots mean to continue until you have all of the directories you wish to include in the FMS directory. In addition to the "old style" file directories described in section 11.1, RBBS-PC supports two types of FMS "directories" -- multiple, single-subject FMS directories or a single multiple-subject master FMS directory. If there are going to be multiple, single-subject FMS directories, there must also be a "directory of directories" (i.e. a master directory) whose name is specified in CONFIG parameter 211 and there can not be more than 99 of these single-subject FMS directories. If there is going to be a single FMS directory, it's name is specified in CONFIG parameter 214 and it's qualifier is specified in CONFIG parameter 209. An example of multiple FMS directories that assumes the following: CONFIG parameter 220 is "C:\FMS", CONFIG parameter 209 is "DIR", CONFIG parameter 211 is "DIR", and the following files existed: C:\FMS\DIR.DIR C:\FMS\ALPHA.DIR C:\FMS\BEST.DIR The file ALPHA.DIR can be a FMS directory with an alphabetical list of all files and BEST.DIR can be a FMS directory with a date-ordered (latest date last) list of the "best" files. An FMS directory can have an optional "header" line that describes the structure of the directory. RBBS-PC searches FMS directories from bottom to top by default (i.e. the assumption is that they are sorted by date with the newest entry at the bottom). To make an FMS directory read from top to bottom, the directory must have the optional "header" line as the first line. For FMS to read a FMS directory from top to bottom the first four characters in the first line must be "\FMS" and the line must contained the three characters "TOP" (i.e. the whole fixed-length line would read "\FMS TOP"). For FMS directories not sorted by date, the word "NOSORT" must be present in the first line (i.e. the whole line would read "\FMS TOP NOSORT"). The file ALPHA.DIR would have the first line in the file read "\FMS TOP NOSORT". The file BEST.DIR would have the first line in the file read "\FMS TOP" if all searches of the file were to start with the oldest (i.e. first) entry. It is important to realize that FMS directories must have a fixed length in every line. RBBS-PC CPC17.3 Page 152 The columns of all FMS directories are set up as: Column Purpose 1-13 Filename 14-22 File size 24-31 Date in MM-DD-YY format 34- Description + category code To add comments to an FMS directory and not have them shown to the caller, simply begin the comment line with a slash, "\". To force a line to be displayed that is not associated with an FMS directory entry, begin the line with an asterisk and, if it is displayed for only specific categories, the appropriate category restriction. To make an FMS entry visible only to callers with a specific security level or higher, the first character of the file name must be an equal sign, "=". For this entry, the file name is in columns 2 through 13. The minimum security to view this entry goes in column 34 and is followed by a blank and then the description and category code within the columns appropriate for them (based on CONFIG parameter 219). CONFIG parameter 219 specifies the length of the "description" field (40 to 46). The column containing the "category" codes can be variable as follows: Length Columns for description Category code column 40 34-73 74-76 41 34-74 75-77 42 34-75 76-78 43 34-76 77-79 44 34-77 78-80 45 34-78 79-81 46 34-79 80-82 However, some text editors may have a problem with lines 80 or more columns. The fussiest areas for use with FMS are the DATE and CATEGORY CODE fields. These two must be absolutely perfect for FMS to function properly. The others may be slightly more lenient. In order to get the directory in the correct format, insert and delete spaces before and after the column. The file name should not have interior or leading blanks. You must also add a category code to each listing. This is often the most difficult and time consuming part of setting up FMS. A good idea is to format the rest of the directory before you add the codes. CONFIG has a utility, parameter 187, that will check your FMS directory structure for you. If a caller uploads with a "/" for SYSOP, a *** is placed for the category code and only those with a SYSOP security level may view the listing (see CONFIG parameter 125). RBBS-PC CPC17.3 Page 153 11.5 Defining the FMS Category Codes ------------------------------------ In order for FMS to work correctly, the category codes must be defined. This is done in a file specified in parameter 217 of CONFIG. This file is rather interesting in the way it is set up and the possibilities it brings up. The format of this file is, with each line being a separate entry: "<Category name>","<Category codes>","<Category description>" The category name is what the caller types in L;xxxxxxxxxx. The category codes are a list of the character codes in the FMS directory that we want to be under this category name. Category codes can be 1 to 3 characters long, though the simplest and most foolproof method is to make them all exactly 3 characters long. The category description is a short messages that we want displayed when the category is searched for. If the category codes are less than 3 characters in length, blanks must be added to the right to fill out the length to exactly 3 when putting the category codes on the end of file entry. A listing can contain several category codes. This means that a category name of BASIC could have the category codes BSU,BSG,BSS in it. The category codes may be overlapped in several different directories. For example, the BASIC directory used as an example could also have each code included in another directory. UTILS could contain DSU,PRU (Dos utils, Printer utils). GAMES could contain CGG,BSG,TXG (Color Graphics Games, Basic Games, Text games). BASIC could contain BSG,BSS ( Basic Games, Basic Source). SOURCE could contain ACS,BSS (Assembly code source, Basic Source) Such a setup would look like this: "BASICG","BSG","Basic Games" "TEXTG","TXG","Text Games" "COLORG","CGG","Color Graphics Games" "PRINT","PRU","Printer Utilities" "DOS","DSU","Dos Utilities" "ASSEM","ACS","Assembler source code" "BSOURCE","BSS","Basic Source Code" "UTILS","DSU,PRU","Utilities for IBM" "GAMES","CGG,BSG,TXG","Games for IBM" "BASIC","BSG,BSS","BASIC programs" "SOURCE","ACS,BSS","Source code for different languages" The directory might look like: FFIND.ARC 13463 05-24-87 DOS Util look all over disk for file DSU QUEST.ARC 17325 06-02-87 C/G Game D&D style CGG RBBS-SRC.ARC 202562 06-05-87 Source code for RBBS-PC BSS QMODEMSC.ARC 106735 06-07-87 Source code for QMODEM SST PSS BALLOON.ARC 5634 06-08-87 BASIC Balloon game- GREAT BSG STARTREK.ARC 76434 06-10-87 A great game- TEXT TXG When someone lists out GAMES, they get QUEST, BALLOON, and STARTREK. You can also have simply a one to one correspondence, rather than cross referencing by just having one category code for each category. A utility that will help you in setting up your FMS directory is a SYSOP RBBS-PC CPC17.3 Page 154 function built into CONFIG. Parameter 187 will test the structure of your FMS directory and diagnose any problems. Be sure to run this utility after you have tried to set up FMS, or whenever you edit the FMS directory file. RBBS-PC CPC17.3 Page 155 11.6 The "Library" Subsystem, CD-ROM, and FMS --------------------------------------------- The RBBS-PC "library" sub-system is highly flexible subsystem that utilizes DOS 'disk subdirectories. The "library" subsystem is not limited to any particular medium. Basically, it relies on three files: DIR.CDR - This is the Directory of Directories just like DIR.DIR is the Directory of Directories for the normal download area. This file is located on the drive and path designated in CONFIG parameter 302, has a file name equal to the extension designated in parameter 303 , and the extension designated in parameter 303. MASTER.CDR - This is an FMS style directory. Highly recommended to have a size of 46 to allow for placing the DISK/AREA number in the last four positions of description. This file is located on the drive and path designated in CONFIG parameter 302. The following is an example of a master directory file, C:MASTER.CDR, that might be used for the "library" subsystem. DEMO.DTA 9841 01-01-80 PRACTICE FORM 680126 READ.ME 256 01-01-80 INTRODUCTORY TEXT FILE 673102 READ.ME 109 01-01-80 INTRODUCTORY TEXT FILE 671102 DK0680 ARC 10-23-87 FORGE VERSION 2.0 200 DK0673 ARC 10-23-87 FREEWAY ...(Disk 3 of 3) 200 DK0671 ARC 10-23-87 FREEWAY ... (Disk 1 of 3) 200 | | | | | | +- 1->13 | | | | | File Name +- 14->22 | | | | File Size | | | | +- 24->31| | | File Date| | | +- 33->76 | | File Description | | 77->79 -+ | DOS | Directory | Number | | 80->82 -+ Category Code The last four characters of the 46-character file description field are used to indicate the "library" pseudo-disk that the file is in. In this way, when a caller lists files, it is self-evident in the description which DOS subdirectory the caller must change to within the "library" subsystem in order to download the file. RBBS-PC CPC17.3 Page 156 RBBS-CDR.DEF - This is the key file to the successful operation of the LIBRARY section. It consists of three fields on each line. "AAAA","BBBBBBBBBBBBBBBBBBBBBB","CCCCCCCCCCCCCCCCCC"cr/lf A - A four position field numbered from 0001 to 9999. This is the DISK/AREA number assigned to a specific group of files. B - This field has no size limit and is a full path to the area excluding the drive: designation. As an example: \1_100\DISK0001 \GAMES\ADVENTUR\DISK1 \A_F\ALPHABET\DISK01\AREA36 C - This field has no length limit but should be kept at around 56 characters to keep from line wrap on the display. It should contain the TITLE of the disk/area. A file containing a description of the library subsystem's category codes must have the name RBBS-CDR.DEF, be in the same DOS subdirectory as the other RBBS-PC ".DEF" files, and look similar: "0671","\601-700\DISK671","FREEWAY Payroll system (Disk 1 of 3)" "0673","\601-700\DISK673","FREEWAY Payroll system (Disk 3 of 3)" "0680","\601-700\DISK680","FORGE VERSION 2.0" The "library" subsystem can be supported without using the FMS. To do this each "directory" would have ".CDR" as it's extension (i.e. GAMES.CDR) -- or whatever extension was designated in CONFIG parameter 303. Typically, the "library" subsystem is used with FMS. When using FMS with the "library" subsystem it is necessary to add categories to the DIR.CAT file. One approach that works well is utilizing categories 1-99 for the normal (i.e. non-library area) downloads and categories 100-200 for the "library" downloads. The basic assumption of RBBS-PC's "library" sub-system is that files are stored in DOS subdirectories on the DOS disk drive specified in CONFIG parameter 301. RBBS-PC CPC17.3 Page 157 11.6.1 How the "Library" Subsystem Works ---------------------------------------- Before it is possible to download from the LIBRARY area it is mandatory that the caller C)hange to the desired library disk. This is accomplished by using the C)hange command from the library menu. RBBS-PC will accept any 1 to 4 digit number (padding the front with zeros to make it a four digit number). RBBS-PC will then search the RBBS-CDR.DEF file (position AAAA only) for an exact match. If no match is found then RBBS-PC indicates that no Library disk has been selected. If a match is found then RBBS-PC will issue a CHDIR command to the drive specified in CONFIG parameter 301 and the path BBBBBBBB that it constructs from the RBBS-CDR.DEF file. RBBS- PC then informs the caller that Disk AAAA CCCCCCCCCCCC has been selected (i.e. "Disk 0680 FORGE VERSION 2.0"). The caller can download individual files from the area selected or A)rchive all the files in the selected area. If the caller decides to A)rchive all the files in the selected area, RBBS-PC will SHELL to the Archive program designated in CONFIG parameter 313 and located in the drive and path designated by parameter 312. RBBS-PC creates an archived file with the name DKAAAA.ZZZ, where AAAA is the disk/area number on the drive and path indicated by CONFIG parameter 304, and ZZZ is the extension, which depends on what archiving program is used. RBBS-PC will then check to see if there are any subdirectories within the selected area. If any exist then RBBS-PC will again Archive the subdirectories and will create ZZZ files with the name DKAAAAa.ZZZ where AAAA is the disk/area number. The designator, "a", is an arbitrary id to differentiate it from the original ZZZ name. If there are more than one subdirectories then the "a" would be replaced by "b", "c", "d", etc. When this is complete the caller is told what files are ready for download. E.g. DKAAAA.ZIP is ready for download. DKAAAAa.ZIP is ready for download. DKAAAAb.ZIP is read for download. As each file is downloaded successfully it is removed from the list and is no longer displayed to the user as ready for download. RBBS-PC CPC17.3 Page 158 11.6.2 The "Library" Subsystem and PC-SIG's CD-ROM -------------------------------------------------- The CD-ROM published by PC-SIG consists of a DOS subdirectory for each 360K diskette in the PC-SIG library. Sometimes the disk contains all the files already in the ARC format other times they just contain a group of files. The key here is the A)rchive function. The resulting file to be made available for download will NEVER be greater than 360k. This is important since a caller may only have a floppy based system and could not capture a file any larger than a 360k floppy can contain. The PC-SIG's CD-ROM creates the problem of listing both the individual files contained on each diskette as well as a summary description of the individual disks. This can be solved by listing each of the 18,000+ files in the MASTER.CDR using positions 43-76 for the description, positions 77- 79 for the disk drive, and positions 80-82 for the valid categories for downloading. These are contained in the file specified by CONFIG parameter 217. MASTER.CDR might also contain a list of names of the files that would be created by the A)rchive function. This allows the caller to scan a category (i.e. category 200) for disk titles only. Note that the files do not exist until the user uses the A)rchive function. A SYSOP who did not wish to allow individual file downloads might only include these entries in the MASTER.CDR rather than the other 18,000 entries. The directory for the PC-SIG CD-ROM is over 1.5 megabytes in length and can take up to 10 minutes to search completely (when using a PC at 4.77mhz). If the SYSOP is using FMS, it is recommended that the category file for the normal FMS directory and the category file for the Library FMS directory be the same (PC-SIG has 27 different categories for its files). RBBS-PC CPC17.3 Page 159 11.7 Creating the Personal Files Directory ------------------------------------------ RBBS-PC's "personal" file support is analogous to RBBS-PC's support of "personal" messages in that these files are specially addressed to a specific caller or group of callers based on security. Personal file downloads differ from the general download in three major ways: 1. the time limit check is bypassed in personal downloads, meaning that a qualifying caller can download a file regardless of time left. 2. only files explicitly listed in the personal directory can be downloaded. Normally files to be downloaded will be looked for on the disk(s) where files are available for downloading whether they are listed in a directory or not. 3. only callers with matching user record or sufficient security can download a file. Normally any caller with security enough to issue the download command can download a file. Personal files provide a way that files can be delivered to specific individuals. As an example, a vendor's support bulletin board for a software product might make the upgrade downloadable only by paying customers. A credit reporting corporation can make credit reports electronically available only to the people who order them. Or, a SYSOP can make a file privately available to only one caller. One of the most useful applications for personal downloads is to make certain files available regardless of time remaining. Previously, SYSOPs had to increase the security of callers or set artificially high session limits just to make certain large files available. By putting these file names in the personal directory and limited by security level, these files can be made available regardless of how little time is left. For example, the large files comprising RBBS-PC can be made downloadable to all callers even though they are limited to 30 minutes. Access to personal files can be limited in two ways. First, the files can be downloaded only by callers which have a matching value in their user record. For example, files can be limited by name (any field in the user record can be selected). Alternatively files can be limited by security level, meaning that a file can be downloaded by any person with that security level or higher. File access based on security level can also be accomplished using the standard RBBS-PC file security mechanism, but to do so places the caller's under the standard RBBS-PC constraints of maximum time per session/day. Using the "P)ersonal files" command in the files section, a caller is asked what files the caller wants to download. The only files available to the caller for downloading are those explicitly listed as belonging to the caller, unlike the general download command which will look for any named file on the disk. The caller can ask to List the files available. Callers will see only those belonging to them. There is a special option to download all and only the "new" files specifically addressed to the user by matching a field in the caller's user record. RBBS-PC keeps track of whether the caller has ever downloaded the personal file. When listing, new personal files are marked with an "*" in front of their names (they are "tagged"). Selecting the new files starts a RBBS-PC CPC17.3 Page 160 multi-file download for all and only the personal files the caller has never successfully downloaded. Files you want downloaded ONLY through the personal file features of RBBS-PC should be put in their own subdirectory as specified in CONFIG parameter 142. If you put the personal files in a download subdirectory they would be available then to anyone who could name them. RBBS-PC will search the download areas for a personal file if it is not found in the subdirectory specified in parameter 142. Second, in the same place as the personal files themselves, put in a special personal directory with name specified in CONFIG parameter 143. This directory is the same format as the general file directories of RBBS- PC. The format is as follows: Default Field Positions Length Description of Field 1 - 12 12 The first 12 characters of an entry have the file name, with no internal spaces. 13 - 73 Variable The next group of characters can have anything in them. This will be displayed to the caller who asks for a listing, along with the file name in the first 12 columns. The length of this group is 21 characters plus the length of the upload description specified in CONFIG (40-46, defaults to 40). The default length of this field is 61 characters. 74 -104 Variable The next group of characters are what is used to identify the file as "belonging" to the caller and must match a field in the user record. In CONFIG parameter 43 and parameter 44, the SYSOP specifies the position in the user record to use and how many characters. The default is to begin in column 1 and use 31 characters for the caller's name, but any field in the user record can be used. Optionally, a security can be entered in this last field to limit the file based on the security level of the caller. To use security rather than a match on the user record, simply put a blank as the first character in the field, followed by the security level. 1051 The last character must be an "*" to signify that the file has never been downloaded or an exclamation point if ever downloaded. This personal directory works very much like the File Management System shared directory, using a field in the user record as the category and limiting callers to their one category, or limiting the file to the group of caller's with the minimum required security. The personal directory is fixed length and read in reverse from bottom to top. After setting up or modifying the personal directory, you use the CONFIG utility parameter 187 to check whether the personal directory has the proper format. The personal directory can be created by a text editor (i.e. EDLIN) but be RBBS-PC CPC17.3 Page 161 sure to put in the "*" in the last column when creating a new entry so that the file will be tagged as new. Also be sure to make each entry fixed length. If the user's identity does not fill out the length of the last field, be sure to pad the record with blanks out to the full length. When setting up a personal file directory there are seven configuration options peculiar to personal files: CONFIG Description parameter 43 what part of the user record used to identify files as parameter 44 belonging to the user (beginning column and length), parameter 143 the name of the personal directory, parameter 142 the drive and path where the personal files and personal directory are stored, parameter 144 the protocol that must be used downloading, parameter 147 whether the files downloaded are to be concatenated, and parameter 188 the CONFIG utility to check the structure of the personal directory to make sure it is in the properly format. Parameter 147 and parameter 187 require some explanation of how they might be used. Limiting the caller to a required protocol to use is not something one would generally do. But, for special purpose downloads, like downloading to a printer, one might want to require ASCII, for example. Or, if all callers are to use the same communications package or only a particular protocol is efficient, you can specify what callers must use. Concatenating files means that when multiple files are specified for downloading, the files are sent continuously in one stream of data rather than individually as separate files. In effect, the files are physically combined at the time of downloading. All messages between files are suppressed - the only messages that appear to the caller are those that normally occur when the first file transfer starts and when the last file transfer ends. Concatenation is currently supported only for ASCII downloads. An example of a situation that might use this feature of RBBS-PC is a business that generates short reports for clients. Their clients want to call in remotely to get time-critical reports and print them right in their office on pre-formatted paper. Each report is a separate file on RBBS-PC with all the necessary printer commands already included in each file. A SYSOP might set up RBBS-PC such that the main menu was restructured to make the P)ersonal files function be P)rint reports to reflect the more specialized nature of the board. Callers to this board would call in, identify themselves, and select P)rint reports from the main menu. Callers could use L)ist to see what is available if they are looking for some report in particular; just select all new reports; or ask for a particular report if they must have it immediately. In the last two cases, RBBS-PC would notify the caller to set up to receive and press [ENTER] when ready. The pre-formatted reports with embedded printer control sequences would stream out onto the paper (including formatting like bold or underline) positioning the text to fit in boxes. The paper is automatically advanced as needed. When done, RBBS-PC beeps the user, who then turns the "save to printer" feature off of whatever communications package is being used. RBBS-PC CPC17.3 Page 162 To set up this application, the personal file options would be configured to use the caller's id (e.g. account number). The files and directory would be put in a special subdirectory not shared with anything else. The CONFIG parameters would be set to specify that caller's must use ASCII ("A") as their protocol and that multi-file downloads will be concatenated. Another example is that of an electronic job placement service that wanted to limit non-subscribers to a security level 5 with 10 minutes. However, they also want non-subscribes to be able to download a file of potential employment opportunities that may take more than 10 minutes. The following entries would be put into PRIV.DIR: JOBSFORU.ARC 282888 07-14-87 List of job opportunities you might want 5 /|\ /|\ 12 74 Each record is padded with blanks so that 29 blank characters follow the security level, followed by an '*'. The '*' is not shown in this documentation since it is in a column too far to the right. RBBS-PC CPC17.3 Page 163 11.8 Automatically Checking & Converting Uploaded Files -------------------------------------------------------- Verifying the Integrity of a File --------------------------------- RBBS-PC's on-going commitment to providing SysOps with the ability to protect themselves and their callers is reflected in precisely this kind of feature. When a file is uploaded, RBBS-PC will look for a file called T<ext>.BAT (where <ext> is the characters that make up the extension of the uploaded file). RBBS-PC looks for this file on the drive and path specified in CONFIG parameter 105. If this file exits, RBBS-PC will SHELL to either: a.) the program specified in the file (if it only has one line) or b.) to the .BAT file itself. In this way a SYSOP may install whatever processing is desired after a file has been uploaded. If the BAT file contains exactly 1 line, RBBS-PC will shell to the contents of the bat file, passing on the command line the two parameters: a.) the name of the file upload (first) and b.) the name of the file to write the results to (second) If the BAT file contains more than one line, RBBS-PC will SHELL to the BAT file itself, passing a.) the name of the file upload for "[1]" and b.) the name of the file to write the results to for "[2]" as the first and second parameters, respectively. RBBS-PC will consider the upload to have failed and delete the uploaded file, if the file to which the results are to be written has a length greater than 2 bytes. The BAT file should either a.) not write a result file or b.) leave an empty one if the upload is okay. If the file that was uploaded is not okay, the external application should write out some error message more than 2 bytes long. A typical use for this feature of RBBS-PC is to test the compression of the uploaded file and pipe the results to a text scanner that looks for an error string and redirects the output to a file if an error is found. For example if files that are uploaded with the extension .ZIP were to be tested, a SYSOP might create the file TZIP.BAT PKUNZIP -T [1] | FGREP "error in a" > [2] An alternative implementation is: PKUNZIP -T %1 IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2 SETERROR 0 RBBS-PC CPC17.3 Page 164 Under versions of QuickBASIC prior to 4.5, programs that reset the error level cause illegal function call 5 upon return from the SHELL. Therefore it is necessary to run a utility to reset the error level back to 0 before going back to RBBS-PC. This is what the SETERROR.EXE file does. The recommended procedure is to use PKUNZIP, check errorlevel, and reset error level to 0. PKUNZIP outs somewhat variable strings when different errors occur, making a filter based on text more difficult to implement. Converting Uploads ------------------ RBBS-PC can be configured by the SYSOP to cause uploads with extension <u- ext> to be converted to the default extension <d-ext>. To do this, the SYSOP must put a file named C<u-ext><d-ext>.BAT on the drive and path specified in CONFIG parameter 105. If the file exists, RBBS will SHELL to it. If the SysOp wants all .ARC files uploaded converted to a .ZIP file, create a file CARCZIP.BAT in the subdirectory specified in CONFIG parameter 105. To convert .PAK files to .ZIP, create the file CPAKZIP.BAT. Sample conversion batch files are included on the RBBS-PC distribution diskettes. RBBS-PC CPC17.3 Page 165 11.9 Fast File Search --------------------- RBBS 17.3 includes an enhanced file-search capability for uploads and downloads. This enhancement has two advantages: (a) File searches are much faster. In the case of very slow devices like a CD-ROM, this can be the difference between sub-second response and a 45 second response. File searches are now virtually instantaneous. (b) Files not stored on this system can trigger macros. This allows requests for files stored elsewhere, either off line on backups, or on other cooperating systems, to trigger later processing. The basis for the fast file search is a file, configuration parameter 267, which is a sorted list of file names available for downloading. The default name is FIDX.DEF. The format of this file is: columns 1-12: file name columns 13-16: location index (1, 2, 3, ...) columns 17-18: carriage return line feed. All data is stored as character data and the file is editable. The file names must be stored with no internal spaces and a period separating the prefix from the extension. The list of file names MUST BE SORTED BY FILE NAME in order for the fast file search to work. The location index is the record number (line number) of the locator file, whose default name is LIDX.DEF, and has the following layout: columns 1-63: location of file column 64: any character. MAKEFIDX puts in a period. columns 65-66: carriage return line feed. This file is all character data and is editable. Essentially, the location index points to a record in the location file. E.g. if FIDX.DEF has RBBS-BAS.ZIP 2 HARPIE.ARC 3 and LIDX.DEF has C:\DOWN1\ C:\DOWN2\ C:\UP\ Then RBBS-BAS.ZIP is located in directory C:\DOWN2 (2nd record) and HARPIE.ARC is located in C:\UP (3rd record). The location field should be a drive/path terminating with a "\" if any path is given, and file must be filled with blanks through column 63 if the path is shorter. You must put some character in column 64. Many editors delete trailing blanks, so you should probably put in a non-blank. A period is a suitable choice. RBBS-PC CPC17.3 Page 166 RBBS will use a binary search on the first 12 characters in FIDX.DEF. This binary search can be significantly speeded by provided "tabs" for this file, indicating the record at which the first file is that begins with the symbols "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". This is like the "tabs" you see on dictionaries, so you can directly turn to the B's, for example. A tab file has the same prefix as the file name file, except that it adds a "T". For "FIDX.DEF", the tab file would be "FIDXT.DEF". RBBS will automatically detect and use a tab file if available. The tab has 72 characters in it. Each 2 bytes represents a binary integer whose value is the record number in FIDX.DEF where the first file occurs that begins with the respective symbols above. Thus bytes 3-4 show where files begin with "1" and bytes 69-70 where files begin with "Y". Two utilities with source code are provided for setting up the fast file searches. The source, for compiling under QB 4.5, is included. MAKEFIDX will create both the file name list (FIDX.DEF) and the location file (LIDX.DEF), from a list of directories (see MAKEFIDX.CFG) or a list of file names, or both. You must next sort FIDX.DEF by file name. A good shareware utility for this is QSORT (QSORT FIDX.DEF /1:12). MAKETABS will create a tab file (FIDXT.DEF) from the sorted file list FIDX.DEF. A sample batch file for recreating a fast file system is MAKEFFS.BAT. It uses MAKEFIDX.EXE, QSORT.EXE, MAKETABS.EXE, and configuration file MAKEFIDX.KG. You need only edit MAKEFIDX.KG to change the filespecs (/FileSpec=) to match where your files are, and where to write the index files. Reconfiguring to Take Maximal Advantage of Fast File Searches The fast file search is virtually instantaneous on an 8088 with a tab file for 5000 file entries. The savings on wear and tear on the hard disk can be very significant as well. And the time it takes to set up the fast file search is only a few minutes. Most sysops, therefore, will want to implement fast file searching, whether or not they have a slow device like a CD-ROM. RBBS will first search through the drive/paths specified in config to be available for downloading, as it always did. Files not found there will then be searched using the fast file search system. The way the fast file search works is that a file found in its list is looked for only in the designated location. Nothing else is searched. The optimal way to implement fast file searching is to reconfigure the drive/paths available for downloading down to at most the upload directory, and let the fast file search handle everything else. That way, files will be searched first in the upload area, and those not found at first will then be searched using the fast file search system. Note that every file in the fast file search list is considered to be available for downloading whether or not its drive/path is listed in the configuration program as a downloadable area. Note that you can have separate fast file search systems available for each subboard, if desired. You can also use the fast file search for common files and have a separate download area for the RBBS-PC CPC17.3 Page 167 subboards. Note: whenever you relocate files, you must re-create the fast file search system. This is not hard since it takes little time and can be automated. RBBS-PC CPC17.3 Page 168 12. SETTING UP ".BAT" FILES FOR RBBS-PC ---------------------------------------- Many SYSOPs have set up batch files to invoke RBBS-PC automatically and to re-invoke RBBS-PC should there be a power outage. These files range from the simple to the sublime in terms of complexity. If you are going to exit RBBS-PC and transfer control to DOS remotely (either via the SYSOP function 7 or via "doors"), it is necessary that: 1. RBBS-PC be executed from a batch file. 2. The batch file which is executing RBBS-PC contain an "IF" statement that checks for the existence of the batch file which RBBS-PC dynamically builds when either "doors" or SYSOP function 7 is invoked. 3. Within the "IF" statement, the logic exists such that the batch file dynamically built by RBBS-PC for the "doors" functions or SYSOP function 7 will be invoked if it exists. As a very simple example, let us assume that: 1. the batch file that invokes RBBS-PC is named A:RBBS.BAT, and that is what was entered for parameter 104 of CONFIG, 2. the name of the batch file that RBBS-PC will build dynamically for either "doors" or SYSOP function 7 is A:RCTTY.BAT, and that is what was entered for parameter 103 and 3. the compiled version of RBBS-PC is being executed and is named RBBS-PC.EXE and is on the default disk drive. 4. you have elected to use the watchdog utility program. 5. COM1 was designated as the communication port to be used by RBBS-PC. 6. the CALLERS file is on drive A. Then A:RBBS.BAT (in a non-MultiLink environment) would contain the following: IF EXIST A:RBBSxF1.DEF DEL A:RBBSxF1.DEF IF EXIST A:RCTTY.BAT DEL A:RCTTY.BAT RBBS-PC x filename (see note of values available for "x" and "filename") IF EXIST A:RBBSxF1.DEF GOTO EXIT IF EXIST A:RCTTY.BAT A:RCTTY.BAT A:RBBS.BAT :EXIT NOTE: When running RBBS-PC.EXE, RBBS-PC will check for the "x" in the command line that invoked RBBS-PC. The "x" on the execute line is extremely important to the correct operation of RBBS-PC. If you are running in a local area network environment then the "x" should be a number between "1" and "0" or a letter between "A" and "Z". If "x" is omitted from the command line, RBBS-PC will look for a file named RBBS- PC.DEF. RBBS-PC uses the parameter in the command line to determine the correct RBBSxPC.DEF file to use for its configuration parameters if the second parameter is not present. If the second parameter is present, then RBBS-PC assumes this is the fully qualified file name for the .DEF file that this node should use. RBBS-PC CPC17.3 Page 169 13. THE USE OF RBBS-PC "DOORS" ------------------------------ The RBBS-PC "door" concept is that of allowing a SYSOP to set up a "door" through which users can exit from RBBS-PC and enter other applications. In previous versions of RBBS-PC (i.e. prior to CPC12-3A) this had been called "windows" but because of the confusion this created with the WINDOWing concepts of other software, it has been re-labeled "doors". 13.1 "DOORS" Are Nothing More Than .BAT Files --------------------------------------------- RBBS-PC's "doors" are nothing more than .BAT files that the SYSOP has created to allow users to exit from RBBS-PC and enter other applications (i.e. databases, etc.). The SYSOP is responsible for writing the .BAT files that users will be allowed to invoke. Assuming that RBBS- PC is brought up by DOS via an AUTOEXEC file that invokes RBBS.BAT, a door called EDIT exists that consists of a .BAT file (EDIT.BAT) which contains the commands CTTY, EDLIN, and RBBS.BAT. In order to exit RBBS-PC (either for a "door" or for the remote SYSOP function 7) without the code that the BASIC compiler generates for you dropping the remote user, it is necessary for the compiler that RBBS-PC is compiled under be "patched" as described in Appendix T otherwise the user will be disconnected upon returning to RBBS-PC. Here is pictorially what happens: DOS | RBBS.BAT <---------------------------------+ | | \|/ | +--------->RBBS-PC.EXE | | | \|/ | "RUN" | | | +<-------------ends | | | RBBS.BAT | | | \|/ | RCTTY.BAT (invokes door called "EDIT") | | | \|/ | EDIT.BAT | | | +--------->EDLIN.COM | | | EDIT.BAT <--------ends | | | \|/ | RBBS.BAT | | | \|/ | +--------->RBBS-PC.EXE | | | welcome back from door | and RBBS-PC continues-------->| RBBS-PC CPC17.3 Page 170 13.2 A Sample .BAT File for a "DOOR" ------------------------------------ A sample .BAT file for a program called TEST.EXE that assumes: 1. That you are going to be using COM1. 2. That the program "TEST.EXE" is on the default drive. 3. That the batch file to invoke RBBS-PC is called "RBBS.BAT." 4. The batch file "RBBS.BAT" is on the default drive. 13.2.1 Redirect I/O Using the CTTY Method ------------------------------------ Would look like this using the CTTY METHOD: CTTY COM1 TEST.EXE CTTY CON RBBS.BAT The first command, "CTTY COM1", assigns most standard input and output to the communications port number 1. The second command, "TEST.EXE", invokes some test program that you write that reads from and writes to the standard input and output devices (i.e. the keyboard and the screen). The third command, "CTTY CON", reassigns the standard input and output back to the local PC's keyboard and screen whenever TEST.EXE ends. The fourth command simply invokes another batch file named RBBS.BAT (which presumably invokes RBBS-PC). 13.2.2 Redirect I/O Using the CTTY Method ------------------------------------ Would look like this using the REDIRECT I/O METHOD: COMMAND /C TEST.EXE <COM1 >COM1 RBBS.BAT The first command, "COMMAND /C TEST.EXE <COM1 >COM1", starts a secondary command processor, loads TEST.EXE and assigns most standard input and output to the communications port number 1. "Most" is the key word here since PC-DOS does not have a way of redirecting "STANDARD ERROR" like it does for "STANDARD IN and STANDARD OUT". To solve this problem STDERR.COM is included as part of the basic RBBS-PC system. This program was provided by Quarterdeck Systems. Run "STDERR.COM" one time only before you start RBBS-PC. I suggest that you include it in your AUTOEXEC.BAT file. This program works with all versions of PC-DOS 2.0 through 3.2. A sample "DOOR" might look like this using the DEVICE DRIVER METHOD: CTTY GATE1 TEST.EXE RBBS.BAT The first command, "CTTY GATE1", assigns most standard input and output to the device drive named "gateway". Since it is a device driver it must exist in your CONFIG.SYS. The second command, "TEST.EXE", invokes some test program that you write that reads from and writes to the standard input and output devices (i.e. the keyboard and the screen). The third command, "CTTY CON", reassigns the standard input and output back to the local PC's keyboard and screen whenever TEST.EXE ends. The fourth command simply invokes another batch file named RBBS.BAT (which presumably invokes RBBS-PC). RBBS-PC CPC17.3 Page 171 13.3 Setting Up and Testing a "DOOR" ------------------------------------ To first set up and test a door, DO NOT USE RBBS-PC. Rather set up with 1. your modem on auto-answer (i.e. it answers the phone) 2. a .BAT file that redirects all input and output to the communications port that you are going to use using the IBM DOS CTTY command. 3. make sure the .BAT file invokes the program that you want to use as a "door." 4. invoke the .BAT file that you set up in steps 2 and 3. 5. dial up the modem that you set in auto-answer mode in step 1. 6. get your "door" to work in this environment. If you have problems with steps 1 through 6, call your friendly IBM support or the vendor of the software that you want to use as a door and ask them to teach you about either their software or the CTTY command and their software's compatibility with the CTTY command. AFTER YOU HAVE YOUR DOOR WORKING, to set up a "door" for RBBS-PC, you must 1. list the name of the door (i.e. the .BAT file which you already got working and debugged and are responsible for setting up) in MENU5 (or whatever name specified in CONFIG parameter 102 for the text file containing the menu of available "DOOR"s). 2. indicate that doors are available (via CONFIG's parameter 101). When a user invokes the D>oor command, RBBS-PC will: 1. List MENU5, 2. Check that the door that the user selects was specified in MENU5, 3. Check that the .BAT file exists (on the default drive), 4. Dynamically create a .BAT file with the name specified by the SYSOP in parameter 103 of CONFIG that: a. invokes the .BAT file of the window specified,and b. re-invokes RBBS-PC after the user EXITS from the "door" by invoking the .BAT file that the SYSOP specified in parameter 104 of CONFIG. The purpose of "doors" is to allow for the "horizontal" growth of RBBS-PC. In order to not limit the application of RBBS-PC either to BASIC or the current compiler, "doors" was chosen as a mechanism to allow SYSOPs to make available other features (i.e. databases, games, etc.). Hopefully with RBBS-PC as a base, the limitations on doors will only be the SYSOP's resourcefulness AND IBM'S DISK OPERATING SYSTEM (see Appendix W)! The design of the .BAT file that is to be used as a "door" is critical and is the responsibility of the SYSOP. At the very minimum it should handle the communication port I/O. This can be done in a very primitive way using the DOS CTTY command as described in section 13. When the file RCTTY.BAT is executed, it executes another batch file with the name of that particular door. DOS does not return to the RCTTY.BAT. So, at the end of your doors batch file, you must reinvoke RBBS.BAT. RBBS-PC CPC17.3 Page 172 The way that "doors" works is to check to see if the door name specified is in MENU5. If it is in all capital letters in the RBBS-PC file MENU5, it runs the batch file of that name with the extension ".BAT". In general, the program invoked as a "door" has to do is print everything to the communications port and if you wish, echo it to the screen. The initial part of any "door" should read in the parameters passed to the "door" in the "node" record and establish the communications parameter appropriately. Alternatively, "DOORS" can be invoked via a control file, see CONFIG parameter 109. RBBS-PC CPC17.3 Page 173 13.4 Invoking "DOOR"s Via The External Control File --------------------------------------------------- In addition to simply invoking "DOOR"s using the standard approach outlined above, RBBS-PC allows a multiplicity of "DOOR"s which may require different methods and parameters to be used when invoking them. CONFIG parameter 109 allows the SYSOP to specify the name of this control file. This approach allows different "DOOR"s to be invoked in different ways. Specifically, the SYSOP can tailor the way each "DOOR" is invoked as follows: 1. The minimum security level to invoke each "DOOR" may be different. 2. The caller may be required to answer a questionnaire before the "DOOR" is invoked. This is extremely useful if the "DOOR" is a database search program and the questionnaire gathers the necessary search criteria from the caller prior to invoking the "DOOR". 3. The "DOOR" may be either SHELLed to (i.e. where RBBS-PC remains in memory and the "DOOR" is simply loaded in with RBBS-PC) or EXITed to (i.e. where RBBS-PC terminates itself and releases the memory it uses for the "DOOR" to be loaded into). 4. The "DOOR" may be invoked via a "template" (see section 21.2) and information passed to the "DOOR". "Templates" are useful when passing information from a questionnaire to a database search program. RBBS-PC normally passes the node ID as the first parameter to a "DOOR". When using a "template" to invoke a "DOOR" the "template" must include the parameter "[NODE]", if the node ID is to be passed to the "DOOR". 5. A file may be specified for RBBS-PC to display to the caller upon returning from a "DOOR". This file may be created by the "DOOR" that was invoked (i.e. the output of the database search and retrieval) or simply a text file that the SYSOP created. 6. Additionally, when returning from each "DOOR" the SYSOP can elect to ask the caller to re-enter their password as an added security verification. 7. Finally, the control file approach to invoking "DOOR"s allows the SYSOP to specify the maximum amount of elapsed time that a caller can spend in each "DOOR". If amount of time remaining that the user has on the system is greater than the amount of time allowed in the "DOOR", the smaller of the two times is used. As with all features, the control file approach to invoking a "DOOR" is optional. However, even if it is used a "DOOR" can only be invoked by a caller if a .BAT file exists (see section 13.3). RBBS-PC CPC17.3 Page 174 13.5 EXITing or SHELLing to "DOOR"s ----------------------------------- There are two ways to execute other programs from RBBS-PC: 1. EXITing RBBS-PC and invoking the other program via a .BAT file that RBBS-PC builds dynamically, or 2. SHELLing to the other program while RBBS-PC remains in memory. EXITing RBBS-PC allows other BASIC programs to be run as external programs to RBBS-PC, conserves memory, and allows all of RBBS-PC's features to be active in computers with only 320K of memory. The "price" that is paid is that upon returning from the externally called program RBBS-PC's .EXE file must be reloaded into memory. Unless a control file is used to invoke "DOOR"s, RBBS-PC always EXITs to "DOOR"s. SHELLing prohibits other BASIC programs to be run as external programs to RBBS-PC, consumes memory because RBBS-PC remains in memory when the other program is running, and requires 386K of memory (under DOS 3.2) to activate all of RBBS-PC's features. However, SHELLing does eliminate the need to reload the RBBS-PC.EXE file each time. RBBS-PC CPC17.3 Page 175 13.6 Resetting The User's Record Via a "DOOR" ---------------------------------------------- WARNING -- this is an extremely powerful feature! It opens up everything in the user record to modification by the "DOOR". The "door" must also have knowledge of where fields are in the user record and may cease to work properly when the user record changes its format. The main application for this is feature within RBBS-PC if for "DOOR"s that maintain certain SYSOP- defined fields. For a "DOOR" to reset any part of the user record all a door has to do is include in DOUTx.DEF file, where x is node number, a line in the format UR(<start>:<end>),<value> where: <start> is the beginning byte in user record, <end> is the number of bytes to revise, and <value> is what goes into the specified position in the user's record. For example, UR(63:24),"City,State" would update the city/state field with the value "City,State", setting 24 bytes in user record to that value (blank fill to right), beginning with character position 63. The "UR" request only works for data stored in character format in the user record. RBBS-PC supports a second request in the form SL,<sign><value> where "SL" stands for security level. <sign> can be nothing, plus, or minus, and means respectively to set the security level to the following value, or to raise or lower the security by the amount specified. For example, "SL,6" requests that the security be set to 6 whereas "SL,-2" means to lower the security by 2. RBBS-PC CPC17.3 Page 176 13.7 A Summary of "DOOR"s ------------------------- Finally, if the preceding discussion of "doors" is a complete mystery to you, contact a SYSOP of an RBBS-PC that is using "doors" and ask for help. However, if you call a Sysop to learn about "doors" for personal gain (i.e. you are a consultant or some company's employee being paid to write a "door") have the courtesy to tell him. The "user helping user" concept does NOT imply that anyone should be taken advantage. Anyone who has acquired specialized knowledge has the right to be remunerated for their efforts if their knowledge is being used to further commercial purposes and they request it. The "door" concept stretches IBM's DOS' capabilities and requires an knowledge of how both DOS, the DOS CTTY command, and .BAT files work. RBBS-PC CPC17.3 Page 177 14. THE SECURITY FEATURES OF RBBS-PC ------------------------------------- RBBS-PC has always been an open system designed for public use. A SYSOP should always ASSUME that EVERY FILE ON THE PC running RBBS-PC CAN BE DOWNLOADED AND/OR DESTROYED. However, RBBS-PC has extensive safeguards that systematically enhance security and privacy. For example, RBBS-PC has the logic within it's code to prohibit anyone (including the SYSOP) from downloading the RBBS-PC "system" files described in section 5.1. RBBS-PC can still be run as a wide-open system, but the SYSOP has many additional options to restrain access. These security options make RBBS-PC much more suitable for private and business use. RBBS-PC's security is controlled by three things: 1. the system configuration file (RBBS-PC.DEF), 2. the two external security files for a. passwords (PASSWRDS), and b. file downloads (FILESEC), and 3. the users file (USERS) in which each user has an assigned security level. The users file is controlled by the SYSOP user maintenance function 5 as described in section 17. To change a specific users security level you select the M>odify option and then the S>ecurity option. This allows you to set the security level for a user. Users cannot set their own security levels. Section 14.3 describes how to implement special passwords that provide special privileges to the groups that issue them. Section 14.4 describes how specific files, groups of files, or even whole disk volumes can have download security levels associated with them. RBBS-PC CPC17.3 Page 178 14.1 RBBS-PC's Security Features -------------------------------- Each user has an assigned security level, permitting 65,536 possible security levels. Each command in RBBS-PC also has a security level assigned to it. Security assignments are controlled by the SYSOP. To use a command, the caller's security level must be at least as high as the command's security level. The SYSOP can assign a file or group of files both a security level and a password. To download a file, a caller must have a security level at least as high as the file's and be able to give the file's password (if one is present). All users must pass these security tests, including anyone with SYSOP privileges. Messages can be assigned a password by their creator. Then only persons who are able to give that password can read or kill the message. Messages with password protection will show <PROTECTED> when scanned. Callers have no way of distinguishing messages to private individuals and to groups except by how they are addressed. Persons with SYSOP privileges can read all messages. Section 14.2's description of sending a message to an AUTHORS SIG as an addressee with the password of AUTHORONLY shows how to send a message to a special group. Security violations are logged to the CALLERS file. These include attempting to use functions without sufficient security clearance and failure to give required passwords. RBBS-PC's default configuration is that of an "open" system. RBBS-PC's security system provides the SYSOP with several choices on how to run RBBS-PC. The chief ones are as follows: 1. Change the bulletin board from an open system available to all callers, to a pre-registered system available only to specified users. To support this option, there is a function in the SYSOPs user maintenance option 5 to ADD users. 2. A SYSOP can set up different "classes" of users by assigning different security levels to different users. Concurrently the SYSOP would have to assign different security levels to different commands. For example, new callers might be permitted only to leave a comment, read bulletins, and list files that can be downloaded. Or there might be a group of files assigned a security level that only members of a special interest group can download. 3. The SYSOP can segregate the functions of the bulletin board into different groups based on a password. A specific file or group of files can be downloadable only to those who know the password. Similarly, messages can be made open to everyone knowing the password but closed to everyone else. This way there can be semi-private portions of the bulletin board. RBBS-PC CPC17.3 Page 179 14.2 Examples of Uses for RBBS-PC's Security System --------------------------------------------------- Some examples of how a SYSOP can tailor RBBS-PC using RBBS-PC's extensive security features follow. SPECIAL INTEREST GROUPS -- A special interest group (SIG) in a users group wishes to run a RBBS-PC for both the general public and its own use. An example would be an authors SIG for persons interested in publishing books and articles or developing commercial software. A definite need would exist to be able to address messages to everyone in the SIG without making them open to every caller. The SIG would establish the convention to password protect general SIG messages with the password AUTHORONLY, and to address them to AUTHORS SIG. Another example would be a bulletin board devoted to the exchange of software. Allowing persons to use the message subsystem would only interfere with the primary purpose of the bulletin board. Therefore the SYSOP removes from the menu the functions for leaving and reading messages. To prevent a person from using the functions to leave or read a message (even though they are not displayed), the SYSOP assigns these functions a security level higher than a person who logs on normally would be assigned. Another example of using RBBS-PC's security system would be to set up an agreed upon temporary password such that when a user logs onto the system they can issue the password and get longer than normally allowed. If the time for normal users is 30 minutes, the SYSOP can set up the special password SOFTEXCHANGE, with a maximum time on of 150 minutes instead of the normal 30. By shifting over to this special password after logging in, members can get extra time if they need it. SOFTWARE SUPPORT -- An author of a freeware program offers RBBS-PC support to all persons who register their copies and send a contribution of, say, $35 per copy. The registered user can get answers for problems and download free updates and sample applications. The author wants anyone to be able to call just to find out about the service. New callers get a security level of 2 automatically assigned to them. This allows them to use only the message subsystem. The file subsystem is assigned a security level of 7. Contributors are added by the SYSOP with a security level of 7 and a pre-assigned password. Except for SYSOP functions, registered users have free reign in the RBBS-PC. CLIENT SUPPORT -- A SYSOP on a public RBBS-PC also works as a management consultant. She has several associates who work with her on projects. She needs to be able to send and receive messages from her associates which the general public should not see. So they agree on a message password NOTPUBLIC. To support her different clients she also needs to leave private files for downloading. To each client she assigns a special downloading password. To restrict downloading to just that client, file names are put in the file security file with the appropriate password. Only persons with the password can then download them. RBBS-PC CPC17.3 Page 180 PRIVILEGED ELECTRONIC MAIL -- A company uses RBBS-PC to help support its regional offices. Only regional vice-presidents should be able to download certain management reports. In file security these reports are assigned a high security level of 9, which only managers get. RBBS-PC CPC17.3 Page 181 14.3 How to Implement the Password File --------------------------------------- CONFIG allows the SYSOP to designate the name of the file containing the privileged group passwords to RBBS-PC. Since this file is a normal ASCII file, the SYSOP can use any text editor to create and update the file. Put the information for each password on a single line and separate the fields with commas. It is important to note that EACH record of the password must contain ELEVEN parameters (i.e. TEN commas). For the password file, the format is: parm1,parm2,parm3,parm4,parm5,parm6,parm7,parm8,parm9,parm10,parm11 where: parm1 -- password that this line applies to parm2 -- security level for password. If no password was specified, this is the user security level this line applies to parm3 -- maximum time in minutes for a single session parm4 -- maximum time in minutes per day parm5 -- number of days in the subscription period parm6 -- start time, in format HHMM 24 hour style, this line applies to parm7 -- end time, in format HHMM 24 hour style, this line applies to The start/end time are limits on all other parameters: meaning that they apply only during the specified times. Specifying 0 for start/end times means that this line applies all day. parm8 -- the type of ratio method to use. This should be one of the following: '0' - meaning use the files uploaded to files downloaded ratio '1' - meaning use the bytes uploaded to bytes downloaded ratio '2' - meaning use the files per day restriction '3' - meaning use the bytes per day restriction NOTE: FIRST TIME CALLERS MUST UPLOAD AT LEAST ONE FILE (BYTE) BEFORE DOWNLOADING UNLESS THEY ARE: EXEMPT FROM THE RATIO REQUIREMENTS, ARE USING THE DAILY RATIO METHOD, OR AN INITIAL UPLOAD CREDIT HAS BEEN GRANTED. THE INITIAL CREDIT FIELD IS IGNORED FOR METHODS 2 AND 3. parm9 -- the ratio field. A positive integer, such as 15, placed in this parameter requires that the caller maintain a ratio of a least 1 file (or byte) uploaded for every 15 files (or bytes) downloaded. The ratio of uploads to downloads can be cumulative over multiple days or it can be limited to the current day's activities of the caller. A 0 tells RBBS-PC to record uploads, but it will not record downloads, nor will it enforce ratios. This allows the SysOp to have a "free" download period. A -1 tells RBBS-PC to record uploads and downloads, but not to enforce ratios. This allows the SysOp to keep records of each user's transfers, but it will not stop a user from downloading as much as time allows. parm10 - the initial credit field. This can be any positive integer including zero. The use of ratio methods 2 and 3 in conjunction with this RBBS-PC CPC17.3 Page 182 field can restrict the number of files (or bytes) that can be downloaded by an individual or group of callers per day. parm11 - the elapsed time (in seconds) that a caller must wait after logging on before "Time Locked" features will become available. See the description of CONFIG parameter 155 in section 11.8 for a full description of how "Time Lock" works. Here are some examples of how the PASSWRDS file might be used: ,5,50,,,0001,0600,,,, Security level 5 gets 50 session minutes ,5,25,,,,,,,, between 00:01 AM and 6 AM, and 25 minutes otherwise. ,7,50,70,730,,,,,, Security level 7 has a subscription period of 2 years and a session limit of 50 minutes, and a daily limit of 70 minutes. BIGTIME,6,52,,,,,,,, Temporary password BIGTIME gets 52 minutes per session and a security of 6. EXTEND,5,120,,9999,,,,,, Temporary password EXTEND gets 120 minutes for the current session (the user's elapsed time per day would still remain whatever was set in CONFIG parameter 8), a temporary security level of 5, and a subscription period of 9,999 days. ,7,128,256,,,,,,,120 Users who log on with a security level of 7 are automatically granted 128 minutes on the system for each session, 256 minutes total for each day (independent of what was set in parameter 8 of CONFIG), and their subscription period remains unchanged from whatever it was before, but they must wait 120 seconds before being able to exit to a "door" or download a file. SKIPRATIO,170,120,200,90,0600,1200,0,0,, Temporary password 'SKIPRATIO' grants the caller a security level of 170, a session limit of 120 minutes, a daily time limit of 200 minutes, a 90 day subscription period, during the hours of 6AM until noon with no ratio limits. No downloads are added to the counts for the user. Changing the last "0" to "-1" would cause the counts to be added but not acted on to limit downloads. ,140,60,60,365,0001,2400,1,10,, Users with a security level 140, have a session limit of 60 minutes, a daily limit of 60 minutes, a one-year subscription, but during any hour of the day they must maintain a ratio of 1 byte uploaded for every 10 bytes downloaded. There is no initial upload credit. Therefore, an upload must take place before a download. ,150,70,,90,,,0,15,2,600 RBBS-PC CPC17.3 Page 183 Users with a security level of 150, have a session limit of 70 minutes, a 90 day subscription, must maintain a ratio of 1 file uploaded for every 15 downloaded. An initial credit of 2 files are granted to all new/existing users. However, they can not exit to a "door" or download a file for the first 10 minutes (600 seconds) of their session. ,165,90,,120,,,0,30,, Users with a security level of 165, have a session limit of 90 minutes, a 120 day subscription, must maintain a ratio of 1 file uploaded for every 30 downloaded. No initial upload credit is granted. ,170,120,,365,,,2,10,, Users with a security level of 170 have a session limit of 120 minutes, a one-year subscription limitations, but can only download 10 files per day. ,200,360,,730,,,3,250000,, Users with a security level of 200 have a session limit of 360 minutes, a two-year subscription, but can only download 250000 bytes per day. If you are using COPY CON to create this file you "MUST" press F6 followed by a Ctrl/Z at the end of the last entry prior to pressing carriage return. RBBS-PC CPC17.3 Page 184 14.4 Implementing Security for Download Files ---------------------------------------------- CONFIG allows the SYSOP to designate the name of the file containing the passwords and security levels that can be used to restrict downloads of specific files, volumes, or files names meeting certain "wildcard" criteria. This file contains file names with download restrictions in the format: <filename>, <security level>,<password> Note: Each line is a record and ends with carriage-return line-feed. The only optional field is the password field for a filename. By leaving the password field empty, no password is assigned to a file. The commas between the fields are necessary. YOU MUST HAVE TWO COMMAS ON EACH LINE even if you do not have a password associated with the file. Some examples would be: COMMAND.COM, 10,DOS PAYROLL.DAT, 99,BANKRUPT CALLGIRL.SEX,,ILLEGAL \FINANCE\STOCKS,100, The file COMMAND.COM could not be downloaded unless a user had a security level equal to or greater than 10 AND could supply the password "DOS". The file PAYROLL.DAT could not be downloaded unless a user had a security level equal to or greater than 99 AND could supply the password "BANKRUPT". Any user could download the file CALLGIRL.SEX if they could supply the password "ILLEGAL". Any user with a security level of 100 or higher could download the file STOCKS in the DOS subdirectory FINANCE without supplying any password. Additionally "wild-card" characters and drive designators can be used to protect or restrict certain classes of files (by extension, by drive, etc.) from being downloaded. Some examples would be: A:*.*,8, E:*.SEC,2,PW1 A*.M*,0,GX3 XY?X.*,9,3XG All files on drive A would require the users to have a security level of 8 in order for a user to download them. Any user who wanted to download a file whose extension was ".SEC" and was found to be on drive E would have to not only have a security level of at least 2 but to also give the password PW1. The third entry above would require a user who wanted to download any file on any drive with a prefix that began with "A" and an extension that began with "M" to have a security level of at least 0 and to enter the password GX3. Finally, the last entry above would require any user who wanted to download any file on any drive whose four-letter name began with "XY" and whose last letter was "X" with any extension to have a security level of at least 9 and enter the password 3XG. The wildcards "*" and "?" operate just like they do in DOS with two exceptions. The "?" requires a character. In DOS the name "HAPPY" satisfies the file specification "HAPPY?" but it does not in RBBS-PC. RBBS-PC CPC17.3 Page 185 Also, in RBBS-PC, a wildcard applies to an extension only if it occurs after a period. Thus "xyz*" in DOS finds "xyz.a" but not in RBBS-PC ("xyz*.*" will find it). To get exceptions to the general rule, just put the exceptions first. RBBS-PC's file security search stops with the first applicable entry that it encounters. For example, 1. if you want all files on the B drive to require the user to have a security level of at least 3, 2. except that files on the B drive with the extension ".SEC" would require the user to have a security level of at least 6, and, 3. regardless of the disk drive that they were on, any file beginning with "MES" with an extension of ".SEC" would require the user to have a security level of at least 12 you would enter the following into the file security file MES*.SEC,12, B:*.SEC,6, B:*.*,3 Special Note:RBBS-PC is hard coded so that there are some files that nobody can download -- not even the SYSOP. These are RBBS-PC.DEF, users, messages, callers, group password, comments, the file security, and backup files. Similarly the batch files that control RBBS-PC and let the caller exit to DOS 2 can not be downloaded. The default security file provided with RBBS-PC is empty. RBBS-PC CPC17.3 Page 186 14.5 Implementing Security for RBBS-PC Commands ------------------------------------------------ RBBS-PC allows each command to be assigned it's own security level. A user who wishes to invoke an RBBS-PC command must have at least the same security level as the command. Let's assume that a SYSOP wants to set up the following classes of users: Classification of Users Security Level "Locked Out" Users 0 New Users (first time) 1 Normal Users 2 Users who can "view" a Conference 3 Users who can enter Messages 4 Users who can download files 5 Users who can upload files 6 Users who can Join a Conference 7 Users who can do some SYSOP commands (Jr. SYSOP's) 8 Users who can enter a "door" 9 Users who can enter all SYSOP commands (Co-SYSOP's) 10 The following table illustrates one method of assigning each RBBS-PC command it's own security level: Security Level Subsystem/Command Assigned to Command Messages Subsystem A>nswer questionnaire............... 4 B>ulletins.......................... 1 C>omments........................... 1 D>oor subsystem..................... 9 E>enter message..................... 4 F>iles system....................... 1 I>nitial welcome.................... 1 J>oin a conference.................. 7 K>ill messages...................... 4 O>perator page...................... 1 P>ersonal mail...................... 2 R>ead messages...................... 2 S>can messages...................... 1 T>opic of messages.................. 1 U>tilities (more)................... 1 V>iew conference mail............... 3 W>ho's on other nodes................3 @>Library Sub-System.................1 Files Subsystem D>ownload........................... 5 G>oodbye............................ 0 L>ist file directories.............. 4 N>ew files.......................... 5 P>ersonal downloads................. 5 S>earch directories for string ..... 1 U>pload a file...................... 1 V>erbose listing of ARC file........ 1 Utilities Subsystem B>aud rate.......................... 1 C>lock (time of day)................ 1 RBBS-PC CPC17.3 Page 187 E>cho selection..................... 1 F>ile transfer protocol............. 1 G>raphics........................... 1 L>ength of page..................... 1 M>essage Margin..................... 1 P>assword change.................... 1 R>eview preferences................. 0 S>tatistics of system............... 1 T>oggle (line feeds, etc.).......... 1 U>serlog............................ 2 Library Subsystem A>rchive a Library disk..............5 C>hange a Library disk...............5 D>ownload........................... 5 G>oodbye............................ 0 L>ist file directories.............. 4 S>earch directories for string ..... 1 V>erbose listing of ARC file........ 1 GLOBAL commands ?>What can be done.................. 1 H>elp with a command................ 1 Q>uit to another subsystem or exit.. 1 X>Expert/novice toggle.............. 1 SYSOP Subsystem 1>List comments..................... 8 2>List callers log..................10 3>Recover a Message................. 8 4>Erase comments.................... 9 5>USERS maintenance.................10 6>Toggle page bell.................. 8 7>Exit to DOS 2.x or above.......... 9 RBBS-PC CPC17.3 Page 188 14.6 Beware of the "Trojan Horse!" ----------------------------------- Despite RBBS-PC's security always remember that you should always assume: "EVERY FILE ON THE PC RUNNING RBBS-PC CAN BE DOWNLOADED, MODIFIED, AND/OR DESTROYED!" RBBS-PC's security system appears to be so fool-proof that some individuals have resorted to uploading programs that appear to do one thing, but actually do something else. These "trojan horse" programs search all the disks that are connected to the PC that the program is running on for such RBBS-PC files as RBBS-PC.DEF or USERS. The program then copies these files to an innocuously named file that can be downloaded later when the person who uploaded it logs onto the system again. Since RBBS-PC.DEF contains the pseudonym that the SYSOP can use to logon on remotely as the SYSOP, once the user downloads a copy of it the user can then log on as the SYSOP and do just about anything including exiting to DOS and formatting all the disks on the system. Similarly, the USERS file contains passwords and the security levels of everyone on your RBBS-PC -- some of whom may have SYSOP privileges. You can protect yourself against anyone logging on as you, the SYSOP, by not allowing anyone to logon as the SYSOP remotely. To do this read section 11 regarding parameter 121. You can protect yourself against unauthorized access of the USERS file by simply not allowing any user to have SYSOP privileges. Of course there is the "trojan horse" program that doesn't even bother with the above, but simply destroys all the disk files on all the disks that are connected to the PC that is running the program. See the rest of section 22 to see how you can protect yourself against such programs. RBBS-PC CPC17.3 Page 189 15. SYSOP FUNCTIONS ------------------- The SYSOP functions allow a SysOp, or other user with sufficient security level, to perform simple system maintenance functions without leaving RBBS- PC. 15.1 SYSOP Commands Within RBBS-PC ---------------------------------- The following operations can be performed by entering a number only at the command prompt: 1 - Type COMMENTS file. The contents of the COMMENTS file is displayed. This file can also be inspected using a TYPE command from DOS. It is a text file. 2 - Type CALLERS file. A log is maintained of all persons who have called the system. This function will list the file showing the users name and the date and time signed on as well as the names of the files they upload/downloads along with any security violation or errors encountered. This is a random access file of 64-byte records. 3 - Resurrect a message. This function will restore a message that has been killed. If the message file has been "packed", the killed messages are no longer recoverable. The function will ask for the message number of the message to be recovered. 4 - Erase the COMMENTS file. This function will erase the comments. A new comments file will be created the next time a user leaves a comment. 5 - USERS file maintenance. The users file contains entries for each user registered with the system. This function permits the SYSOP to A)dd -- add a user to the USERS file. L)st -- list the USERS file. P)rt -- print the USERS file on the printer. M)od -- modify a record in the USERS file. S)can - scan each record in the USERS file for a particular string. In <M>odify mode, limited editing of the users record in the USERS file can be done. The following subfunctions are available: D - Delete the user. F - Find another user in the USERS file. M - Return to the option 5 function prompt. N - Give the user a new password. P - Toggle the printer flag to print entries on the printer. Q - Quit and return to the main message prompt. R - Reset the user's graphic mode. S - Set the security level of the user. This can be used to lockout or grant special privileges to the user. X - Modify user's upload/download counts. # - locate any record number within the USERS file. $ - Change the user's Registration date. In <M>odify mode a record will be displayed followed by a subfunction prompt for action. To get to a specific record the record number can be entered at the prompt and if valid that record will be displayed. If the RBBS-PC CPC17.3 Page 190 record number is invalid or an empty c/r is entered then the next record in the file will be displayed. 6 - Toggles the operator page bell on/off. This overrides the "office hours" specified in the RBBS-PC.DEF file. 7-SYSOP drop to DOS as a remote user. If the SYSOP has logged on remotely and is running RBBS-PC under DOS 2.0 or greater, this function will dynamically setup a batch file to assign the SYSOP terminal as the main console. It then returns to DOS and if a. RBBS-PC was invoked via a batch file, and if b. that batch file checks for the batch file which RBBS-PC dynamically builds for SYSOP function 7, and if c. the batch file that invokes RBBS-PC executes the batch file that RBBS-PC dynamically builds for SYSOP function 7, the SYSOP will then see the DOS prompt at the remote terminal and can execute whatever DOS commands or programs the CTTY command support. DOS will look for COMMAND.COM to be present on the disk drive you specified in parameter 105. SYSOP function 7, unlike "doors," loads in a copy of COMMAND.COM to run under the copy that was running RBBS-PC. Also be sure to read Appendix W and make sure that you THOROUGHLY understands the limitations that DOS places on you when this option is invoked. Two areas of caution are advised when using SYSOP function 7 under DOS 2.0 or above. First, each SYSOP should test what can be done remotely. Software that reads and writes directly to the video BIOS and does other things that bypass the standard input and output of DOS simply won't function correctly. Second, you should be aware that you are in DOS and can return to RBBS-PC only by issuing the EXIT command. This will return to the batch file that was built dynamically by RBBS-PC. This file will then continue executing and is designed to reassign the keyboard as the console and then re-invoke RBBS-PC. If you get disconnected while in DOS, your system will be locked up. The console will be assigned to your communication port and your modem will have dropped the line and will have been set not to auto-answer. The only way to restore the system is a manual power off/on sequence. RBBS-PC CPC17.3 Page 191 15.2 SYSOP Use of Function Keys and Numeric Pad ----------------------------------------------- The following function keys are designed to give the SYSOP special local controls that can be actuated while RBBS-PC is waiting for calls, or while a caller is online. F1 - Return to DOS. This is only active when RBBS-PC is waiting for a call. When the SysOp presses F1, RBBS-PC takes the modem "off hook", so incoming calls will get a busy signal. It then creates a file in the same directory as the CALLERS file named RBBSxF1.DEF ("x" is the node ID). RBBS-PC then returns to DOS. The invoking batch file should check for the presence of the RBBSxF1.DEF file and halt if it is present after running RBBS-PC. F2 - SHELL to DOS. RBBS-PC remains resident but suspended in memory, the user (if any) remains on-line and the local SYSOP is in DOS until the EXIT command is issued (returning to within RBBS-PC just prior to having pressed the F2 key). The users session is not terminated -- only suspended. F3 - Printer toggle on/off. This changes the printer on-line status. When on-line, the printer will print each caller's name and the filenames uploaded/downloaded. It will also print all unexpected error messages. This function should only be turned ON when a printer is attached to the RBBS-PC computer and is ready to print. When the printer toggle is on, "LPT" will be displayed in positions 8-11 of line 25. F4 - Operator page toggle. This changes the status of "operator annoy" (i.e. allows the SYSOP to be pageable). Operator page time limits are set by CONFIG parameter 7. This toggle will override the SysOp's "office hours." When the "operator annoy" toggle is on, "ANY" will be displayed in positions 5-7 of line 25. F5 - Forces RBBS-PC to tell the modem to answer the phone. F6- SYSOP available. This changes the status of operator available setting. This is useful if during your "office hours" you temporarily don't wish to be disturbed. When the SYSOP available toggle is on, "AVL" will be displayed in positions 1-3 of line 25. F7- SYSOP gets control of the system after current user logs off. When this toggle is on, "SYS" will be displayed in positions 13-15 of line 25. F8 - Allows the SYSOP to grant an on-line user temporary SYSOP privileges. This is a toggle on/off switch. F9 - SNOOP toggle. This key switches SysOp SNOOP on/off. When SNOOP is OFF, the local screen will clear. When SNOOP is ON, the local screen will be updated to reflect what the RBBS-PC user is seeing. F10- This is the forced chat switch. It announces your presence to the caller and then allows both you and the caller to type and see each other's words. The ESC key is used to exit Forced chat mode or to answer an "O>perator page" request. The F10 key will not function until a user logging on has reached the Main Menu. END - Informs the current caller that the SysOp needs the system, then updates his user record and politely logs him off. RBBS-PC CPC17.3 Page 192 CTRL-END- Logs off and locks out the current user that is on and informs the user that their presence is unacceptable. PgUp - Displays information about the current user. This information is only displayed on the local screen. The user's screen is unaffected. PgDn - Clear the local screen (used to remove information displayed via the PgUp key). LEFT ARROW - Subtracts one minute from the user's current session time. Ctrl/Left Arrow subtracts five minutes from the user's current session time. RIGHT ARROW-Adds one minute to the user's current session time. Ctrl/Right Arrow adds five minutes to the user's current session time. UP ARROW-) allows the local SYSOP to increment an on-line users security level by one. CTRL-up-arrow will increase the security by 5. DOWN ARROW -) allows the local SYSOP to decrement an on-line users security level by one. CTRL-down-arrow will decrease the security by 5. Some keyboards do not recognize the CTRL-Up or CTRL-Down. To accommodate this, the CTRL-PgUP and CTRL-PgDn can be used instead. The SYSOP can also enter commands on the command prompt line while a caller is on-line. The command entered will cause the system to respond just as it would if the caller had entered the command. This should be used with caution because it could confuse a new system user -- users are often timid enough without knowing that big brother is actually watching them! Let callers page you and then tell them that you can assist with commands if they get into trouble. RBBS-PC CPC17.3 Page 193 16. MESSAGE AREAS WITHIN RBBS-PC --------------------------------- RBBS-PC is intended to be an open system. As such it can have an unlimited number of message areas and messages. At the very minimum, RBBS-PC has a single 1.) message area, a file named MESSAGES, 2.) user file, a file named USERS, and 3.) definition file, a file named RBBS-PC.DEF In addition to this, additional messages areas can be created as either "conferences" (i.e. areas that use the same RBBS-PC.DEF file as the main RBBS-PC message area) or "sub-boards" (i.e. areas that have their own .DEF file). 16.1 "Conferences" and "Sub-boards" -- the Differences ------------------------------------------------------ A "conference" or "sub-board" can be: 1. "public" -- any caller can join. 2. "public with a separate user file" -- any caller can join and RBBS-PC remembers the last message read by each caller and will notify a caller on logon that new mail is waiting. 3. "semi-public" -- only callers with security levels equal to or greater than that specified for the conference can join. 4. "semi-public with a separate user file" -- only callers with security levels equal to or greater than that specified for the conference can join and RBBS-PC remembers the last message read by each caller and mail waiting. 5. "private with a separate user file" -- only callers who have been pre-registered in the separate user file for the conference can join and RBBS-PC remembers the last message read and mail waiting. A "sub-board" is just a conference that also has a configuration definition file (.DEF). Sub-boards can be public, private, or semi-private. Access to a sub-board is controlled by the configuration parameter 123 which sets the minimum security level required to enter the "sub-board." A "sub-board" configuration file has the same format as the RBBS-PC main configuration file, and is created and edited using CONFIG.EXE. This allows a "sub-board" to have its own unique welcome file, commands, security levels, menus, help, bulletins, directories, and up and download areas. "Sub-boards" can share as much or as little as desired with other conferences or other "sub-boards" within the same RBBS-PC system. The only things a "sub-board" cannot change are the primary MESSAGES file and the communications parameters used by the RBBS-PC it is running under. RBBS-PC CPC17.3 Page 194 To the caller, a "sub-board" appears just like another bulletin board, accessed from a bulletin board rather than through a telephone number. Public sub-boards, just like public boards, are those whose minimum security to join is not higher than the default security for new users. "Sub-boards" basically allow a single telephone number to offer very different types and levels of services. Independent "sub-boards" run under the same RBBS-PC service radically different types of terminals/PC's. Within the same RBBS-PC, one "sub-board" may have 80 column menus for IBM and compatible PC callers, another may have 40 column menus for Atari and Commodore PC users, and still another may have 20 column menus for those using telecommunications devices for the deaf (TDD's). No longer is it necessary to provide three independent telephone numbers for three such different services. All callers can dial the same number and simply switch over to the appropriate board. Extra lines can be added to a roll-over and service all the boards. "Sub-boards" make it much easier and feasible for a SYSOP to market bulletin board services by allowing hardware to resources to be pooled under one software "umbrella" such as RBBS-PC and yet service a very diverse set of requirements -- much the same way that Compuserve does. One of the best hardware configurations for running a multi-board service like this is PC-Slaves, because adding additional boards are extremely easy, with virtually no system degradation. "Sub-boards" greatly benefit "umbrella" organizations. For example, a computer club that covers IBM computers, Apple, Atari, and Commodore. No longer does software intended for one type of computer have to get mixed in with listings for another computer. Each computer can have not only separate messages, but bulletins and directories as well. "Sub-boards" make it easy to have different "levels" of service based on security level. Many SYSOPs run both a "free" and a "subscription" board. The most typical arrangement for this is to have the free board be on the bottom of a telephone roll-over and the pay board be on the top, and for the top board to require a higher security level. Non-subscribers who call the pay board number get "kicked" off the board. "Sub-boards" on the same telephone line would give both paying and non-paying callers equal access, if desired. Another example is that callers with enhanced security can join a sub-board to get access to even more downloads. Or, executive officers for an organization can have access to a "sub-board" that has not only special messages but special bulletins and files. The naming conventions of the files associated with a "conference" or "sub- board", for example called CLONES, would be: CLONESM.DEF --- the message file CLONESU.DEF --- the user file CLONESW.DEF --- the "welcome" file (for conferences only) CLONESC.DEF --- the configuration file (for "sub-boards" only) Using the configuration .DEF file associated with a "sub-board" allows each SYSOP to make the "sub-boards" as unique or similar as desired. Two security levels are very important. The minimum security to log on to the board determines who can join the "sub-board". And the default security level is what newly added callers are assigned. A "sub-board", like any conference (public, semi-private, or private) is closed to all who have insufficient security. To make a "sub-board" RBBS-PC CPC17.3 Page 195 completely private, simply set the minimum CONFIG parameter 123 (the minimum security level a new user needs to logon) to be higher than any normal caller would have. The only way for callers to be able to join a completely private "sub-board", like a private conference is for the SYSOP to have added them previously to the users file associated with that "sub- board". The security level a caller gets when auto-added is the default security level for the "sub-board" and not the current security level of the caller. This is to prevent special privileges that a caller has in one "sub-board" from automatically propagating into other "sub-boards". For example, a caller with SYSOP privileges in one "sub-board" who joins another does not become receive SYSOP privileges in the other. The security level used to determine what "sub-boards" a caller can join is not the current security level but the original security level the caller had on the main board. RBBS-PC detects if the bulletins in the "sub-board" are the same as in the main RBBS-PC system and does not re-display them when a "sub-board" is joined. "Sub-boards", public conferences, semi-private conferences, and private conferences can all co-exist within the same RBBS-PC system. Sub-boards in turn can have sub-boards in them, as well as public, semi-private, and private conferences. The primary disadvantage of "conferences" or "sub-boards" that have separate user files associated with them is the additional disk space that is required for the users file. RBBS-PC's CONFIG parameter 290 allows the SYSOP to let a user on as a "guest" if there is no more room left in the users file for the "sub-board", semi-private conference, or private conference. Not having a user record defeats one of the main mechanisms for remembering a user's preferences, of course, but the SYSOP can start with a smaller users file and expand later without the risk of denying callers access. Obviously, "sub-boards" take more time to set up and maintain. While it is nice to be able to have parts of RBBS-PC vary radically from one another, every one that does vary is another item to create and maintain. "Sub- boards" can multiply the work necessary, for example, to maintain bulletins. There are more users and message files to oversee. However, Kim Wells MU-EDIT is an invaluable tool for managing multiple message and user files. Give Kim's RBBS-PC call at (301) 599-7651/7652 and get a copy of MU-EDIT. RBBS-PC CPC17.3 Page 196 16.2 Making a "Conference" or "Sub-board" Successful ------------------------------------------------------ To make a "conference" or "sub-board" successful several guidelines should be followed rather rigorously: 1. Establish a "conference" or "sub-board" chairman (i.e. a SYSOP) to manage the conference. The SYSOP's job is to add new users, delete old ones, make sure that the subject and/or the agenda of the conference is adhered to by killing messages that are inappropriate. This is best accomplished by having a separate user file for each "conference" or "sub-board" in which the caller only has SYSOP privileges when in the specific "conference" or "sub-board." 2. Establish an "agenda" or list of subject areas for the "conference" or "sub-board." One of these should be about new subject areas. These areas should be VERY narrow in scope. The essence of any good conference is keeping it focused. Everyone has been in at least one meeting/conference that was a waste of time because whoever was running the meeting/conference did not keep the dialogue centered on the subject or agenda. 3. If a continuity of dialogue is to be achieved, it is advisable to keep the conference "focused" -- either by keeping the number of conference members limited, or by keeping the subject matter very narrow. Another interesting thing about "private" conferences and sub-boards as implemented within RBBS-PC is that they are not "public" and, therefore, are even more protected by the first, fourth, and fifth amendments. RBBS-PC CPC17.3 Page 197 16.3 Setting Up a "Conference" or "Sub-board" --------------------------------------------- The SYSOP sets up a "conference" using the CONFIG utility parameter 167 to pre-format up to two files -- one for the messages to be associated with the conference and one for the users to be associated with a conference. The file name for a "conference" can be any seven characters that are valid for a file name. The eighth character must be a "M" (for the messages file associated the conference) or a "U" (for the users file associated with the conference). The SYSOP can then enter the conference member's names in the conference USERS file by using the SYSOP function 5. The SYSOP can "join" any conference and need not be in any particular conference's USERS file. Like "conferences", RBBS-PC supports an unlimited number of "sub-boards". "Sub-boards" are equally easy to create. If CLONES were the name of a public conference (the CLONES message file CLONESM.DEF exists), all that would have to be done to make CLONES a "sub-board" would be to run CONFIG to 1.) create a separate user's file, CLONESU.DEF, for this formerly public conference (if didn't already have a users file), 2.) create a "sub-board" configuration file for the CLONES "sub-board" (a file whose name would be ATARIC.DEF). The easiest way to make a "sub-board" configuration file is to use the DOS copy command, starting with another configuration file as a model (e.g. the one for the main board). To continue with the CLONES example you would issue the DOS command: COPY RBBS-PC.DEF CLONESC.DEF Then invoke CONFIG.EXE to edit that file, using the form CONFIG CLONESC.DEF WARNING!! When you create a .DEF file by copying another one as a model, be sure to run CONFIG against this new file and change the message and user file names! Otherwise your sub-board will share the user file with another message base. Here change the message file name to CLONESM.DEF and the user file name to CLONESU.DEF. The users file name can be anything for a "sub-board" but the extension .DEF is a good idea because RBBS-PC's security system will not let any file with that extension be downloaded. Remember, you do not want to allow callers to download any users file! You get an extra layer of protection if you put the message, user, and configuration files in an area not available for downloading. RBBS-PC CPC17.3 Page 198 16.4 Establishing a "Conference" or "Sub-board" SYSOP ----------------------------------------------------- RBBS-PC has one of the more flexible and powerful systems for supporting "assistant sysops" or "conference moderators". A moderator need not be made a full sysop, and whatever security a moderator has, does not transfer to the rest of the board. Moderators need two basic functions: 1. read and kill all messages, 2. add and modify users, and 3. forward mail to a better person to answer it. The ability to do user edits is controlled by the security specified by sysop function 5. Incidentally, moderators cannot edit user records with security higher than theirs. The ability to read and kill all messages is controlled by a security level specified in CONFIG. RBBS-PC supports having separate user files for every message area, so that moderator privileges in one area do not necessarily transfer to others. To set up a conference or sub-board moderator, the SYSOP need only 1. "Join" the conference or sub-board. 2. Use SYSOP function 5 to enter the name of the user who is to be the conference chairperson into the conference's USERS file. 3. Set that users security level in the conference's USERS file to a security level that can issue the SYSOP function 5. This will allow the conference chairman to add users. 4. Set the minimum security to read and kill all messages to the level of the moderator. 5. Set the minimum security to change the minimum security to read a message to the security level of the moderator. This will allow the moderator to forward everyone's mail. Any registered user can join a "public" conference or sub-board. When someone issues the J)oin command to join a conference or sub-board, their standard security level is temporarily superseded by the security level associated with their user name within that conference's or sub-board's USERS file if it is a "private" conference. For example, a normal user might be given the security required to add users to a particular conference or sub-board USERS file since they are the SYSOP of that message area. When a user joins the conference or sub-board of which they are chairman, their normal security is bumped up so that they can add users to the USERS file of that particular message area. When the same user exits that message area, their security level is returned to normal. If they should subsequently join another message area where they are not chairman, they would be unable to add users to that message area's USERS file. Other than a message area's SYSOP, none of the message area members should be given any higher security than they otherwise enjoy as a regular RBBS-PC user. RBBS-PC CPC17.3 Page 199 17. CALLERS AUTOMATIC NOTIFICATIONS OF MAIL WAITING --------------------------------------------------- RBBS-PC has the ability to notify callers about mail waiting for them when they log on. Callers can be notified for any pair of user/message files (a) how many new messages were left, and (b) whether any new messages are to them personally. RBBS-PC can be configured such that the messages individually reported by number to the caller when the caller logs on are all messages (i.e. both old and new, or just new messages since the caller last logged on, or no messages at all via CONFIG parameter 19. Of course, RBBS-PC allows the SYSOP to determine if callers are reminded of the mail they have left. In a file specified in CONFIG parameter 93 (the default is CONFMAIL.DEF), the SYSOP can list the message/user file combinations to check for mail waiting in the format <user file>,<message file> where these are related conference file names. If it is assumed that RBBS- PC is running in a DOS subdirectory off of the main root directory of the "C:" drive and that there are two conferences, RBBS-PC and BETA, then an example of the contents of the CONFMAIL.DEF file is: C:\RBBS\BETAU.DEF,C:\RBBS\BETAM.DEF C:\RBBS\RBBS-PCU.DEF,C:\RBBS\RBBS-PCM.DEF The names are processed exactly as typed, so inclusion of the drive/path is necessary. The SYSOP controls what conferences get checked for mail by listing these file pairs. Conferences not listed will not be checked. Callers will get a report only for conferences that they are a member of. Two items of information are reported: number of new messages since last in the conference, and whether any new messages are address to the caller. The name used in RBBS-PC for the main message base is taken from the file name for the message base. As with conferences - if the prefix of the user file ends with "M", the name will be the composed of all but the last character. If the name is "MESSAGES", it will be called "MAIN". Otherwise the main message base will be called the full prefix. The main message base and users file can be included in the list to scan. You may want to coordinate the USERS and MESSAGES file names in the same fashion that conference user files and message file names are coordinated. If the main message base is to be known as TOP then call it TOPM.DEF and call the users TOPU.DEF. RBBS-PC will just as well with the default names USERS and MESSAGES and call the main message base MAIN. There are 3 philosophies that can be implemented on message reporting using the CONFIG parameter 19: 1. Report everything. 2. Make a fast minimal report. RBBS-PC CPC17.3 Page 200 3. Make an optimum intermediate report. Reporting everything means reminding callers of messages they left, and give the messages numbers of old and new mail. To do this it is necessary to set configuration parameters to remind callers of old mail and to report ALL messages to caller. Also place "sub-boards" and private conferences in the mail scan list of CONFMAIL.DEF. Making a fast minimal report means that callers will not be reminded of old messages, specific message numbers will not be list, only the number of new messages and whether any are personal will be reported. This option is for when you want people to get the caller to the command level as fast as possible. For example, the main message base is not even used. To do this set configuration parameters to NOT remind callers of old mail and to report NO messages to caller. Put the main message base as well as "sub- boards" and private conferences in the mail scan list of CONFMAIL.DEF. Providing an optimum intermediate report means reporting individual message numbers only for the new mail as well as # of new messages (and whether any personal). The best way to implement this is to set the level of reporting messages to the caller to New Only and to put all "sub-boards" and private conferences in the mail scan list of CONFMAIL.DEF. Set CONFIG parameter 21 to NOT remind callers of old mail. RBBS-PC CPC17.3 Page 201 18. RBBS-PC QUESTIONNAIRE FACILITIES ------------------------------------- RBBS-PC provides a script-driven questionnaire facility. RBBS-PC will process a questionnaire when a NEW caller logs in, before any caller logs off, or the user can select a questionnaire from a menu. To ask new users questions the file named in CONFIG parameter 84 must exist. To ask questions of users when they say G>oodbye the file named in CONFIG parameter 85 must exist. Questionnaires can also raise or lower the user's security level based on his/her responses. Answers to the questionnaire are appended to a file specified in each questionnaire script. RBBS-PC will only activate the corresponding script files if they exist, otherwise the functions are bypassed. The questionnaire script processor supports: o Branch to labels (forward and back branching) o Display lines o Display line and get response o Response validation (Multiple choice) o Numeric validation o Raising and lowering user security level o Aborting the questionnaire o Chaining to another questionnaire o Invoke a macro from within a questionnaire o "Turbo" key can be turned on from within a questionnaire The first line in every script file must contain the file name where the responses to the script will be appended, and the maximum security level a user can be raised to. The rest of each script file contains script commands. Script commands are 1 character in length and must be in column 1 of each script line. Following is a list and description of valid script commands: : A colon indicates a label command * An asterisk indicates a display data command ? A question mark indicates a display and wait for response command = An equal sign indicates a multiple choice branch command > A greater than symbol indicates a goto command + A plus sign indicates a raise security level command - A minus sign indicates a lower security level command @ An "at" sign means to abort questionnaire and do not write results & An ampersand means to establish a questionnaire chain T The letter "T" turns on the "turbo" key mode M The letter "M" executes a "macro" > Assigns a value to a work variable CONFIG parameter 94 controls the maximum number of work variables that can be handled by questionnaires. RBBS-PC questionnaires even support "graphics" versions of the questionnaires. Graphics versions use the standard convention of ending the filename with "C" for color graphics and "G" for ansi graphics. E.g. HLPRBBSC.DEF and HLPRBBSG.DEF are graphics versions of HLPRBBS.DEF. RBBS-PC CPC17.3 Page 202 18.1 Branching to Labels ------------------------ : Colon (Label command) This command is used to provide labels that can be branched to from = and > commands. :QUESTION1 Numeric labels are not recommended because they are easy to confuse with work variables. SmartText variables will be interpreted as such, eg. ":-{FN" will substitute the user's first name. SmartText and Work Variables are dynamically substituted into all questionnaire lines. For example, >-.[8].- will substitute the value of work variable 8 for "[8]", so that if 8 has "edit" as its value, it will go to the label "-.edit.-". The ability to get and substitute values, and to have graphics versions, means that questionnaires can support many of the features of full screen editing, including transmitting a template, then overlaying values into the template. An example that shows the power of questionnaires is ?29Change what field (1,2,...20) ?[29]Change field [29]. from [[29]] to This asks which field to change and stores answer in work variable 29 (i.e. value of work variable 29 is "7"). The second question then stores the answer in the value of work variable 29, displays the name of the work field being changed, and then displays the old value of the work variable. Suppose that the value of work variable 7 is "Yes". Then the series of substitutions RBBS-PC makes into the second line before executing it are: ?7Change field [29]. from [[29]] to ?7Change field 7. from [[29]] to ?7Change field 7. from [7] to ?7Change field 7. from Yes to RBBS-PC CPC17.3 Page 203 18.2 Display Data Command ------------------------- * Asterisk (Display data command) This command is used to send data to the user. Smart Text and Macro commands are interpreted before display (see section 8.8 for marcro command reference). "*/FL" will not display the "/FL" because it is interpreted as a macro command. If you want to work variables to overlay a display template, keeping it's length (e.g. for columnar display), put "/FL" after the "*". E.g. if variable 1 has value "12345" and 2 has "abcdef", then */FL.[1]....[2]...... will display ".12345..abcdef...", whereas *.[1]....[2]...... will display ".12345....abcdef......". One of the more useful capabilities of macros that questionnaires can make use of is the ability to append data to any work file, where work variables are merged into a form. This allows the questionnaire data to be saved in virtually any format desired. The other extremely useful macro capability that questionnaires can utilize is the ability to retrieve data from a file into a form, in effect adding a data based file retrieval capability. 18.3 Display Data And Get Response ---------------------------------- ? Question mark (Display data and get response) This command is used to send data to the user and wait for a response. The user will be required to input a response. The ENTER key alone is an invalid response. No other checks are made. ?DO YOU OWN YOUR OWN PC? (Y/N) The prompt command accepts an optional number which is interpreted as the number of the Work Variable to store the answer in. For example, " ?8Enter Dept will store the answer not only in the regular way for a questionnaire but also in work variable 8. RBBS-PC CPC17.3 Page 204 18.4 Multiple Choice Response ----------------------------- = Equal sign (Response validation - Multiple choice) This command is used in conjunction with the ? command and must immediately follow the ? command for which it applies. This command allows for checking/editing of single character responses to the preceding ? command and allows branch logic to be exercised based on the response given. Multiple = commands must be coded on the same line. The format follows: =AXXXXXXXXX=BYYYYYYYYY= ZZZZZZZZZZ = Indicates that a single character comparison value follows A Is the comparison value X Is the label to branch to if the response is "A" = Indicates that a single character comparison value follows B Is the comparison value Y Is the label to branch to if the response is "B" = Indicates that a single character comparison value follows (SPACE) This is a special comparison value that is always used as the last comparison value and means "INVALID" response given Z Is the label to branch to if an invalid response is given Maximum line length is 255 characters and the last = on the line "MUST" have a comparison value of " " (SPACE). :QUESTION1 ?Do you run a BBS system. (Y/N) =YQUESTION2=NQUESTION2= QUESTION1E :QUESTION1E *Please respond Y or N >QUESTION1 :QUESTION2 There is an additional format for the = command, where the comparison value of # (Pound sign) is used. This is used as a numeric check and encompasses 0-9, (), - and space. This format requires two entries. The first is to test for numerics and the second is the invalid response branch label (e.g. "=#QUESTION3= QUESTION2E"). 18.5 Forward And Backward Branching ----------------------------------- > Greater than sign (Forward and backward branching) This command is used to branch to specific labels within the script file. >QUESTION4 RBBS-PC CPC17.3 Page 205 18.6 Raise/Lower User's Security Level -------------------------------- + Plus sign (Raise user security level) This command will add the value in columns 2-6 to the default security level given new users or the current security level of old users. +5 - Minus sign (Lower user security level) This command will subtract the value in columns 2-6 to the default security given new users or the current security level of old users. -1 18.7 Abort Questionnaire ------------------------ @ At sign (Abort questionnaire) This command will terminate the questionnaire and NOT write the response to the output file as in the following example. :QUESTION1 ?Have you answered the questionnaire before. (Y/N) =YQUESTION2=NQUESTION3= QUESTION1E :QUESTION1E *Please respond Y or N >QUESTION1 :QUESTION2 @ :QUESTION3 18.8 Chain Questionnaire ------------------------ & Ampersand (Chain questionnaire) This command will establish the next questionnaire in the chain. The file named in columns 2-80 will be used as a continuation to the current questionnaire when the current questionnaire reaches its last line. i.e. &L:\RBBS\QUESCONT.DEF 18.9 Turbo Keys --------------- T Turbo Key This is used to turn on Turbo Key for a prompt where a single keystroke is expected. TurboKey causes the next keystroke to be taken as the answer immediately without having to press Enter, if the caller has TurboKey on. 18.10 Macro Execute -------------------- M Macro Execute This command is used to execute a specified macro named after the command, e.g. "M C:\RBBS\FIZ.IMC". Control returns to the questionnaire after a macro is executed. One of the most important capabilities macros add to RBBS-PC CPC17.3 Page 206 questionnaires is the ability to append data to any file in any format desired. Hence the data in questionnaires can be saved where ever desired in whatever format desired. If a macro saves the data and you do not want the normal output on completion of the questionnaire, just abort the questionnaire at the end. Macros also have the ability to retrieve data from files and then display on the screen. 18.11 Assign Value ------------------- < Macro Assign This command assigns a value to a work variable. For example, "<2 XT" assigns value "XT" to work variable 2. RBBS-PC CPC17.3 Page 207 19. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS ----------------------------------------------------- RBBS-PC includes a flexible interface for implementing file-transfer protocols. A "protocol" for the exchange of files is just a set of cooperative conventions that allow two different computer's software to transfer files between themselves. RBBS-PC supports four "protocols" within its own BASIC source code -- ASCII, Xmodem (checksum), Xmodem (CRC), and 1K-Xmodem. These are totally configurable by the SYSOP when setting up RBBS-PC. In addition to these four "protocols" and in order to provide advocates of specific protocols a means of adding their particular flavor of communications protocol to RBBS-PC, a standard interface has been created so that "external" protocols can be installed in RBBS-PC. "External" protocols are simply defined as programs outside of RBBS-PC which perform the file transfer. Before calling "external" protocol drivers, RBBS-PC will do the following: 1. verify that the file exists if the file is to be downloaded. 2. for uploads, verify that the file name requested is valid. 3. pass control of the communications port to the external protocol. RBBS-PC will call the external protocol drivers either via the SHELL command in BASIC or via a .BAT file. RBBS-PC CPC17.3 Page 208 19.1 Parameters passed to a protocol driver -------------------------------------------- RBBS-PC detects the installation of external file transfer protocols via an optional RBBS-PC system file whose default name is PROTO.DEF. If no such file exists, only internal protocols will be available -- Ascii, Xmodem, XmodemCRC, 1K-Xmodem. This file may be used to rename or delete some or all of RBBS-PC's internal protocols. If a PROTO.DEF file exists, all of RBBS-PC's internal protocols must be specified in it as well. Internal protocols are NOT automatically included when a PROTO.DEF file exists! The protocol definition file has thirteen (13) parameters passed for each external protocols defined for RBBS-PC. Each parameter can be on a separate line of its own or all parameters can be on a single line (separated by commas). The parameters passed for each protocol specified are: Parameter Description 1 Protocol Name 2 Security Level required to use protocol 3 Method to invoke protocol 4 Whether 8 bit connection required 5 Whether "reliable" connection required 6 Whether "batch" mode supported 7 Number of bytes in a block transferred 8 Indicate transfer always successful 9 Factor to estimate file transfer time 10 RBBS-PC "macro" to invoke before protocol 11 Method for checking transfer's success 12 Template to use for downloading 13 Template to use for uploading Protocol Name -- The FIRST CHARACTER is the letter by which a caller selects the protocol. The prompt for the selection of protocol includes the protocol name. It is recommended that the second character be ")" to resemble the rest of the prompts in RBBS-PC, e.g. "Z)modem". RBBS-PC will normally put each protocol on the same line, separated by a comma, until the line gets too long. The SYSOP can control the placement of the line by putting a carriage return line feed at the end of the protocol name. If this is done, the entire protocol name must be in parentheses. For example, instead of the prompt A)scii,X)modem,C)rcXmodem,Y)modem,N)one a SYSOP may want the prompt to be A)scii (text files only) X)modem checksum C)rc Xmodem Y)modem (1K Xmodem) N - None (cancel) RBBS-PC CPC17.3 Page 209 Then the protocol definition file , PROTO.DEF, should be constructed using quotes (to include the carriage return/line feed in the first parameter) as follows: "A)scii (text files only) ",... "X)modem checksum ",... "C)rc Xmodem ",... "Y)modem (1K Xmodem) ",... "N - None (cancel) ",... with the remaining 12 parameters put where "..." occurs. Security Level -- This is the minimum security to be able to use the protocol being described. Method to Invoke Protocol -- A protocol can be invoked by one of three methods: shell, door, or internal (S, D, or I). If "I" is specified, it must be immediately followed by a letter specifying what internal protocol to use, where the choices are A, X, C, Y, or N respectively for Ascii, Xmodem, Xmodem CRC, 1K-X(Y)modem, or None (cancel transfer). "IC" would mean to use RBBS-PC's internal Xmodem CRC. If no protocol is specified equivalent to the internal "None", RBBS-PC will add it. If the letter N is used for a transfer protocol, another protocol must be specified that is equivalent to "None". Whether to Require 8 Bit -- By putting "8" in this parameter, the SYSOP is specifying that the protocol requires the caller to be able to send or receive 8 data bits. If 8 data bits is required and the caller is not at 8 bit, RBBS-PC will prompt the caller to change to 8 bit in order to use the protocol. Whether A Reliable Connection Is Required -- By putting "R" in this parameter, the SYSOP is specifying that the protocol will not be shown or made available to the caller unless the connections is reliable (i.e. such as Microcom's MNP protocol that is built into many modems). Whether Batch is supported -- By putting "B" in this parameter, the SYSOP is indicating that "batch" file transfers are allowed with the protocol. "Batch" means a multi-file download request will be processed together. RBBS-PC enters an external protocol only once to do multiple file downloads. RBBS-PC has been tested with such "batch" protocols as Zmodem's DSZ, Megalink, and Sealink. Blocksize -- This parameter indicates the number of bytes in each block transferred. This is only used to inform the caller the number of blocks to expect when downloading. A zero in this parameters will cause RBBS-PC to report only the number of bytes to expect. For Xmodem or XmodemCRC this value would be 128. For Ymodem this value would be 1024. RBBS-PC CPC17.3 Page 210 Indicate Transfers Always Successful -- If there is no way for the protocol to inform RBBS-PC if a transfer was successful, put a "F" in this parameter, which stands for "Fake" a success report. This means that all transfers will be regarded as successful. Zmodem (DSZ) used in a multi-tasking DOS environment (where the DOS environment variables are shared) and CLINK are examples of protocols that require this to be set. Factor to Estimate File Transfer Time -- This is the decimal number used by RBBS-PC to estimate the elapse time to download a file. The higher the number, the faster the protocol and the lower the time estimate. Standard equivalents in RBBS-PC are: Ascii ......... 0.92 Xmodem ........ 0.78 XmodemCRC ..... 0.78 Kermit ........ 0.78 Ymodem ........ 0.87 Imodem ........ 0.90 YmodemG ....... 0.95 Windowed xmodem 0.78 If no value is specified, a default of 0.87 will be used. RBBS-PC "Macro" to Invoke Before Protocol -- This is the RBBS-PC "macro" (i.e. a series of standard RBBS-PC commands) to invoke before invoking the protocol. It can be used to display special messages, to delay the start of the protocol, or to prompt for special information passed to the protocol. Method for Checking Transfer's Success -- This is required only for external protocols. This parameter indicates how RBBS-PC is to detect a file transfer's failure. The format is "x=y=z" where: x is which parameter tells whether the transfer was successful, y is the string which indicates failure, and z is an optional parameter telling RBBS-PC whether to write out information needed when DOORing to a protocol in advance of the file exchange. For QMXFER.EXE from John Friel and the Forbin Project, this would be "4=F" - meaning the 4th parameter indicates failure if it begins with "F". For Zmodem as implemented in DSZ from Omen Technologies, the proper choice depends on whether SHELLing or DOORing is used. For SHELLing, put in "1=E" to indicate that the first parameter uses "E" to indicate an error has occurred. For DOORing, put in "4=E=A" to indicate that the fourth parameter uses "E" when an error has occurred. The "=A" means that RBBS-PC is to do an advance write of the filename and protocol used. DSZ then appends its error report to the log file. To the file "XFER-" plus node # plus ".DEF" RBBS-PC will write out a line containing "<filename>,,<protocol letter>". Omitting an "=" causes a default to "4=F". The file checked is "XFER-" plus the node number plus the extension "DEF". On node 1 the file checked is "XFER-1.DEF". Template to Use for Downloading -- This is required only for external protocols. It tells RBBS-PC how to invoke a download. See the following RBBS-PC CPC17.3 Page 211 section on discussion of "templates". Template to Use for Uploading -- This is required only for external protocols. It tells RBBS-PC how to invoke an upload. RBBS-PC CPC17.3 Page 212 19.2 Calling external protocols using "templates" -------------------------------------------------- A "template" is used to inform RBBS-PC how to invoke an external protocol. The first word of the template must be the file name (including file extension) of the program to invoke. RBBS-PC will check to make sure that the file exists. If the file does not exist, the protocol will not be made available to the caller. RBBS-PC will dynamically substitute values for pre-defined strings inside a "template". Each supported string is enclosed in square brackets. The strings supported include: [n] where n is a positive integer. Substitutes value in a work array Macros can store the prompted values in specific elements in the array. [FILE] Name of the file (FILE.NAME$) to be transferred. [BAUD] Baud rate. Speed at which the caller dialed RBBS-PC. [PARITY] Parity used by the caller. [PORT] DOS device name for the communications port to be used for the file transfer (COM1,COM2, etc.). [PORT#] Number of the communications port to be used for the file transfer (1,2,3, etc.). [NODE] Number of the RBBS-PC node invoking the file transfer (1,2,3, etc.). [PROTO] Letter of the protocol for the file transfer. Everything else in a template will be passed intact. If the external file transfer is to be invoked via a SHELL, it is recommended that the external file transfer program be SHELLed to directly. If the external file transfer is to be invoked via a DOOR, it can be either 1. DOORed to directly using the same template as for SHELLing, or 2. DOORed to indirectly via a .BAT file with the command parameters passed to it by RBBS-PC. For example, a "door" for QMXFER might have a download template of: "RBBSQM.BAT [FILE] [PORT] [BAUD] [PROTO]" and the file RBBSQM.BAT have the following in it: C:QMXFER.COM -s -f %1 -l %2 -c -b %3 -p %4 DOS substitutes the passed parameters for the variables beginning with the percent sign. .BAT files are needed if additional programs to run before or after the actual file transfer. The following examples should provide some help in understanding how to invoke external protocols: RBBS-PC CPC17.3 Page 213 Example #1: Z)ippy,5,S,8,,,,,0.98,,,"c:\utl\zippy -s [FILE]","c:\utl\zippy -r [FILE]" Can be interpreted to be: used "Z" as invoking letter, put "Z)ippy" in the prompt, the minimum security to use this protocol is 5, the protocol will be invoked via a SHELL command, an 8-bit connection is required, estimate the download time as 0.98 times as fast as normal, use normal RBBS-PC type of report to check for a successful transfer, invoke the protocol for downloads using the following string: "c:\utl\zippy -s [FILE]" and invoke the protocol for uploads using the following string: "c:\utl\zmodem -r [FILE]" where the file name is substituted for "[FILE]" in either case. Example #2: X)modem,5,IX,8,,,128,,0.8,,,, Can be interpreted to be: used "X" as invoking letter, put "X)modem" in the prompt, the minimum security to use this protocol is 5, the protocol is an internal RBBS-PC protocol, an 8-bit connection is required, and estimate the download time as 0.8 times as fast as normal. RBBS-PC CPC17.3 Page 214 19.3 Parameters Returned by a Protocol Driver ---------------------------------------------- All protocol drivers are expected to return information about the file transfer in a file named XFER-xx.DEF where the value for xx is the node ID (1 to 36). If the protocol cannot accommodate this minimal requirement, it can still be used by telling RBBS-PC to indicate file transfers are always successful -- section 19.1, parameter 9. The one item of information RBBS-PC requires to be returned from an external protocol drive is whether or not the file transfer was successful. The failure indicator MUST BE the first character of any specified parameter in the file XFER-xx.DEF. To show that file transfer failures are indicated by the first parameter and the letter "E" in the file XFER-xx.DEF, parameter 11 (as described in section 19.1) would be written as "1=E". To show that file transfer failures are indicated by the fourth parameter and the letter "F", parameter 11 (as described in section 19.1) would be written as "4=F". No other information is required when SHELLing to external file transfer protocols. However, when DOORing to external file transfer protocols the log file for the transfer MUST HAVE the file name as the first parameter. Protocol drivers that do not have the file name as the first parameter can still be used by telling RBBS-PC to write out three parameters (file name, an empty parameter, and the letter of the file transfer protocol) before invoking the external file protocol. This is done by using parameter 11 (as described in section 19.1). As an example, to DOOR to an external file transfer protocol that indicates a file transfer failure by using the letter "F" in the fourth parameter, but which does not return the file name used, parameter 11 (as described in section 19.1) would be written as "4=F=A". The external protocol would then append its own information to the log file. RBBS-PC CPC17.3 Page 215 19.4 The Protocol Drivers Tested With RBBS-PC ---------------------------------------------- RBBS-PC has been tested with the following protocol drivers: CLINK -- From System Enhancement Associates. Supports batch file transfers but requires that transfers always be assumed successful. DSZ -- From Omen Technologies. Supports Ymodem, Ymodem Batch, YmodemG, and Zmodem. YmodemG requires a "reliable" connection. DSZ logs the results of the file transfers to a file specified in the environment variable DSZLOG. Therefore, the AUTOEXEC.BAT file for an RBBS-PC that uses DSZ should specify "SET DSZLOG=XFER-x.DEF" where x is the node number. DSZ seems unable to create a log file whenever a drive or path is specified. If invoking ZMODEM via the DOOR mechanism, use the "=A" option at the end of the success method check so that RBBS-PC will append the information to the DSZ log it needs and DSZ will then append the success report. In a multi-user environment where a different environment variable for each node can not be specified (i.e. all nodes must share the same DSZ log file), specify that a all transfers are always successful for protocols handled via DSZ. MLINK -- MEGALINK protocol supports batch file transfers but requires that transfers always be assumed successful. PC-KERMIT -- from Columbia University. PCKERMIT.EXE is supplied by The Source as a public service and consists of sliding window KERMIT protocol. The development of "windowing" within the KERMIT architecture (i.e. Super KERMIT) was funded by The Source and implemented by Larry Jordan and Jan van der Eijk. Columbia University holds the copyright and maintains the Kermit protocol. Like RBBS-PC, Columbia University allows KERMIT to be passed along to others and "ask only that profit not be your goal, credit be given where it is due, and that new material be sent back to us so that we can maintain a definitive and comprehensive set of KERMIT implementations". PCKERMIT.EXE is not a terminal program. It simply implements the Kermit protocol, including the sliding window extension. It will work with older "Kermit Classic" implementations as well, via automatic negotiation between the two Kermit programs. PCKERMIT.EXE runs as a "one-shot" execution then returns to RBBS-PC. PCKERMIT does not establish a carrier with a remote system. The connection is established by RBBS-PC. File transfers must always be assumed successful. QMXFER -- is supplied by The Forbin Project as a public service and supports five different protocols -- XMODEM (checksum), XMODEM (cyclical redundancy check), YMODEM, YMODEMG, and IMODEM. QMXFER was implemented by John Friel III, author of QMODEM. YMODEM and YMODEMG are protocols designed by Chuck Frosberg. IMODEM is a protocol designed by John Friel. The later two are designed to work when the link between the two modems is "error free" (i.e. both modems have the MNP protocol RBBS-PC CPC17.3 Page 216 built in)> QMXFER.COM runs as a "one-shot" execution then returns to RBBS-PC. QMXFER does not establish a carrier with a remote system. The connection is established by RBBS-PC. File transfer failures are indicated by an "F" in the fourth parameter of the log file returned to RBBS-PC. WXMODEM -- is supplied by The Forbin Project as a public service and supports the window XMODEM protocol designed by Pete Boswell. Like all of RBBS-PC's protocol drivers, WXMODEM.COM runs as a "one-shot" execution then returns to RBBS-PC. WXMODEM does not establish a carrier with a remote system. The connection is established by RBBS- PC. File transfer failures are indicated by an "F" in the fourth parameter of the log file returned to RBBS-PC. Other protocols tested with RBBS-PC include SuperK, Jmodem and Puma. RBBS-PC CPC17.3 Page 217 20. UPLOADED FILE TIPS ---------------------- Every SYSOP should assume that any uploaded file him that can be executed (i.e. .BAS, .COM, .EXE) has the capability of destroying all the files available to the PC it is executed on. This may be because the documentation is in error, the program was executed incorrectly, or the program was designed to be malicious. It behooves every SYSOP to know what every uploaded file does in order to protect not only the RBBS-PC system, but its users. RBBS-PC CPC17.3 Page 218 21. DUE WARNING AND SYSOP'S LEGAL LIABILITY ------------------------------------------- While no definitive case-law or legislation exists defining the liabilities of System Operators, every SYSOP should assume that they are as responsible for their own actions when running an electronic bulletin board system as they would be for any other action as a citizen of the United States who chooses to exercise their right to freedom of speech. One of the unique features of RBBS-PC is that users have to OVERTLY register themselves -- even when the RBBS-PC is "open" to the general public. This gives each SYSOP the opportunity to give every user "due notice" and require each user to actively acknowledge such notice. Every SysOp should consider the legal issues, and provide proper notice to all callers. RBBS-PC CPC17.3 Page 219 22. COMPILING AND LINKING RBBS-PC --------------------------------- RBBS-PC source code is distributed along with the executable program RBBS- PC.EXE. It is NOT necessary to recompile or re-link RBBS-PC in order to utilize RBBS-PC. However, some users may wish to modify the source and recompile it. This section is intended for those hardy few who choose to do so. Remember only what is distributed is supported -- anything else is strictly yours to debug! RBBS-PC's source code is compilable by the Microsoft QuickBASIC Compiler, version 2.01 and higher. However Microsoft's QuickBASIC Compiler version 3.0 is the compiler used to generate the .EXE files distributed with RBBS-PC because it appears to be the most reliable. Versions too buggy to use at all include 1.0, 2.0, and 4.0. 22.1 Compiling CONFIG and RBBS-PC --------------------------------- The batch files MAKERBBS.BAT and MAKECNFG.BAT are included with the source to recompile RBBS-PC and CONFIG respectively. The are designed for use with QuickBasic 3.0 but instructions for editin for other versions are in them. RBBS-PC's .EXE files are distributed after having been compiled with QuickBASIC Version 3.00 compiler that had the DTR patch described in Appendix T applied to it. CONFIG.EXE is generated from compiling with multiple BASIC source files -- CNFG-VAR.BAS, CONFIG.BAS, CNFG-SUB.BAS. The output of the multiple compiles (CONFIG.OBJ and CNFG-SUB.OBJ) generate multiple .OBJ input files to the LINK step that create CONFIG.EXE. The QuickBASIC version 3.0 compiler command should be: QB CONFIG.BAS,/E/O/C:2048/S; QB CNFG-SUB.BAS,/O; Compiling CONFIG requires that CNFG-VAR.BAS be in the sub-directory from which they are being compiled. RBBS-PC.EXE is generated from compiling with multiple BASIC source files -- RBBS-VAR.BAS, RBBS-PC.BAS, RBBSSUB1.BAS, RBBSSUB2.BAS, RBBSSUB3.BAS, RBBSSUB4.BAS, and RBBSSUB5.BAS. The output of the multiple compiles (RBBS-PC.OBJ, RBBSSUB1.OBJ, RBBSSUB2.OBJ, RBBSSUB3.OBJ, RBBSSUB4.OBJ, and RBBSSUB5.OBJ) generate multiple .OBJ input files to the LINK step that, along with some other .OBJ files, create RBBS-PC.EXE. The command for QuickBASIC version 3.00 should be: QB RBBS-PC.BAS,/C:4096/O; QB RBBSSUB1.BAS,/X/O; QB RBBSSUB2.BAS,/O; QB RBBSSUB3.BAS,/O; QB RBBSSUB4.BAS,/O; QB RBBSSUB5.BAS,/O; QB 4.5 can be used to compile RBBS-PC as follows: BC RBBS-PC.BAS,/C:4096/O/MBF; BC RBBSSUB1.BAS,/X/O/MBF; RBBS-PC CPC17.3 Page 220 BC RBBSSUB2.BAS,/O/MBF; BC RBBSSUB3.BAS,/O/MBF; BC RBBSSUB4.BAS,/O/MBF; BC RBBSSUB5.BAS,/O/MBF; Compiling RBBS-PC requires that RBBS-VAR.BAS be in the sub-directory from which they are being compiled. For debugging purposes, RBBS-PC.BAS and RBBSSUB2.BAS through RBBSSUB5.BAS can be compiled with the /E option in addition to those shown. NOTE: A bug in the QuickBASIC compiler library routines must be fixed in order to prevent a loss of DTR (thereby losing the caller) when exiting to a door. Appendix T contains information regarding patches for this bug. 22.2 LINKing CONFIG ------------------- CONFIG.OBJ can be LINKed to produce CONFIG.EXE with the command LINK CONFIG+CNFG-SUB+RBBSUTIL+FOSSCOMM+GWCOM,CONFIG.EXE,,; assuming that all the required files are on the default drive. 22.3 LINKing RBBS-PC -------------------- RBBS-PC.OBJ can be LINKed to produce RBBS-PC.EXE with the LINKer command (all on one line) -- LINK @LINKLST3.DAT, where the file LINKLST3.DAT contains the following: RBBS-PC+ RBBSSUB1+ RBBSSUB2+ RBBSSUB3+ RBBSSUB4+ RBBSSUB5+ GWCOM+ QBARCV6+ ANSI17+ XMODEM+ RBBSML+ BDRIVEC2+ PC-NET+ 10-NET+ RBBSUTIL+ RBBSDV+ GIVEBK31+ FOSSCOMM+ BASNOV+ RBBSHS, , , BCOM30.LIB /STACK:2048 NOTE: New with 17.3 is QBARCV6.OBJ. For QB4.5, there is no GWCOM.OBJ and the LIB used in BCOM45. The above LINK command assumes that all the necessary .OBJ and .LIB files are on the default drive. RBBS-PC CPC17.3 Page 221 23. LIMITED LICENSE ------------------- The RBBS-PC software is copyrighted but A LIMITED LICENSE IS GRANTED and each user is free to use and share it under the following conditions: 1. You may NOT distribute RBBS-PC in modified form. 2. You may NOT charge a fee for RBBS-PC itself, and 3. You MUST retain all references to the copyright and authors. Please distribute the original version (or update thereof) of the program. If you have changes please distribute them using the conventions described in section 0.4. This is necessary so that future revisions can be easily added to the system without requiring the entire program. Please do NOT resequence the program. All revisions will be as files that replace the base program or update thereof and the existing line numbers will be referenced when describing new fixes and enhancements. RBBS-PC CPC17.3 Page 222 24. LIMITED WARRANTY -------------------- The RBBS-PC program is provided "as is" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with the user, and should the program prove defective, the user and not the authors will assume the entire cost of all necessary remedies. None of the authors warrant that the functions contained in the program will meet any users' requirements or that the operation of the program will be uninterrupted or error-free. In any case, each author's entire liability will be limited to the total amount of money the individual user paid directly and explicitly to each author for the use of RBBS-PC. RBBS-PC CPC17.3 Page 223 25. THE HISTORY BEHIND RBBS-PC ------------------------------- Electronic bulletin board systems have been around ever since personal computers existed. The first ones were very primitive and usually consisted of some posted notices and maybe allowed for on-line messages. It must be remembered that the IBM PC was only announced in August of 1981 and first became available in October of 1981. Therefore it is not surprising that the early history of BBS' is associated with non-IBM personal computers. The "early history" of bulletin board systems began around 1978 in Chicago with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was created by Ward Christensen and Randy Suess -- members of the Chicago Area Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080 Assembler language (11,000 lines of it) and, like the early versions of RBBS-PC (i.e. prior to CPC12-5A), detects the baud rate and the parity of the user when he first signs on from the three carriage returns that the user must enter. About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80 Models I and II called Forum-80. The earliest BBS was written for the Apple (who else had personal computers in those days?) called the "Apple Bulletin Board System" (ABBS). It was written by Craig Vaughn and Bill Blue. They later created another bulletin board system for the Apple II called the People's Message System (PMS). Another Apple bulletin board system that came into being was for the Apple II, II+, and IIE as well as the Franklin Ace and it was called the CommuniTree. It was written in the FORTH language by Dean Gengle and several others. When IBM announced its first personal computer, the IBM PC, in August of 1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a prototype version written by Russ Lane in IBM's BASIC on David Crane's Dallas RCP/M\CBBS system. Brad added many fixes and modifications. In the first half of 1983, many members of the Capital PC Users Group's Communication Special Interest Group (SIG) such as Larry Jordan, Rich Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further enhanced it and added XMODEM file transfer capability until it became known as RBBS-PC CPC09 in May of 1983. At that time each feature or modification was identified by a new version number; it still ran only under the BASIC interpreter; and was both relatively slow (because of the interpreter) and somewhat unstable (it would normally "crash" at least once each day). Late in May of 1983, Tom Mack asked Rich Schinnell if there was any "bulletin board" software available for the IBM PC written in BASIC. Rich told him to give Larry Jordan a call. Larry said that he was just getting CPC09 ready to send to Rich Schinnell who at that time was Director of the Capital PC User Group's Public Domain Software Library and that he could get it from Rich. He did, and still has the diskette just as Rich sent it to him -- dated June 22, 1983. Bulletin board systems, historically were the result of a single person or small group of persons' efforts and tended to serve a very narrow interest group -- typically those interested in the medium itself (i.e. PCs, programming, communications, etc.). This was true up to and including RBBS-PC CPC17.3 Page 224 RBBS-PC CPC09. In fact, most of the incentive to get the public domain versions of RBBS-PC (CPC09 and earlier) functioning was to introduce the XMODEM protocol to the IBM PC-based community. In this CPC09 was successful and may have been the primary incentive for XMODEM to be included in PC-TALK at all. Since June of 1983 THIRTY-SIX versions of RBBS-PC have been released and distributed exclusively through the Capital PC User Group under the limited license described in section 25 of this documentation, becoming an "industry standard" for IBM-type personal computer bulletin board systems. However, even from the very beginning BBSs have excelled whenever: a.) there was a geographically dispersed audience, b.) with a need to exchange highly complex/technical information, c.) in a timely and accurate manner. RBBS-PC's impact has been to open an entirely new medium of communications between people. Rather than as an end in and of itself, RBBS-PC has come to serve as a means to an end -- the free exchange of ideas. On a technical level it is certainly an example that shows "real programmers can/do program in BASIC." We would like to think that RBBS-PC had something to do with IBM and Microsoft coming out with new versions of the BASIC compiler that support communications, sub-routines, local and global variables, file-locking in a networking environment, etc. RBBS-PC represents a fundamental cornerstone, not just a phase, in what can be viewed as a "social renaissance." The three areas mentioned earlier in which bulletin boards excel seem to ebb and flow within communities and organizations. RBBS-PC provides an almost instantaneous mechanism by which these needs can be met. Many of the Big 8 accounting firms bring up RBBS-PC's just to fulfill one contract so that the various geographically disbursed members on the contract can communicate across time zones and continents. Unlike radio, newspapers, and television -- RBBS-PC provides a vehicle within which information can be EXCHANGED! That is what makes RBBS-PC so unique. Because the exchange is written, it is structured. Because it is structured, it can be thoughtful. The "social renaissance" that RBBS-PC represents is the electronic elimination of those barriers that had previously inhibited the "exchange" of information within our society. RBBS-PC provides every personal computer owner with his own "soap-box" in a national Hyde Park. Previously the channels of communication had built-in barriers to "exchange"; with RBBS-PC those barriers begin to cease to exist. While only the most fanatical RBBS-PC trivia experts may be interested, here is the chronology: RBBS-PC CPC17.3 Page 225 RBBS-PC Initial Major Enhancements Version Release Number Date CPC10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC compiler, version 1.0 CPC11.0 08/10/83 RBBS-PC restructured so that all parameters were external (i.e. in the RBBS-PC.DEF) allowing SYSOPs who didn't want to spend the $300 for the BASIC compiler to tailor RBBS-PC to their taste. CONFIG.BAS was first written to generate RBBS-PC.DEF. CPC11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub-routine that allowed the compiled version of RBBS-PC to determine the amount of free space available for uploading. CPC11.2 10/01/83 The error trapping within RBBS-PC was completely re- written to be more comprehensive. CPC12.0 10/28/83 Tree-structured file directories and the ability to detect that RBBS-PC was in a "MultiLink" environment were incorporated. "MultiLink" is a product of the Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, 3.0 and 3.1 to be "multi-tasking." CPC12.1 12/18/83 The ability for a SYSOP who signed on remotely to drop (Versions into DOS was added. Also the "New" command was added "A" to "F")that allowed users to determine what new files had been made available since the last time they were on. CPC12.2 04/08/84 The security system designed by Ken Goosens was incorporated. RBBS-PC's security system has an elegance "A" to "D")unmatched even by the largest mainframe. Essentially the security system designed by Ken is "self-locking lock" and, even though RBBS-PC's source code is distributed, it's security system has remained unbroken. Of course, SYSOPs who didn't adhere to RBBS- PC's security structure have had their system "crashed" and every SYSOP should operate as if the very next caller could crash his system. CPC12.3 11/11/84 This was almost as complete and as major a re-write of RBBS-PC as CPC10.0 had been. Beginning with CPC12.3 up "A" to "B")to nine RBBS-PCs can share the same files in either a multi-tasking DOS environment (i.e. MultiLink from the Software Link, Inc.) or in a local area network environment (i.e. Corvus or Orchid). CPC12.4 03/10/85 (Version A, A1, B) RBBS-PC'stature in the industry became recognized when, as author of RBBS-PC, I was granted a license by Microcom to incorporate their proprietary MNP protocol and "B")into RBBS-PC. Almost at the same time many manufactures recognized the institution that RBBS-PC had become in our industry and elected to include "RBBS-PC RBBS-PC CPC17.3 Page 226 compatibility" in their minimum criteria for the introduction of their new products. RBBS-PC's Vendor Support Program is more fully explained in the RBBS-PC documentation but one direct result of this was the introduction of 300/1200/2400 BAUD support in CPC12.4A before most such modems were generally available. CPC12.5 07/14/85 (Versions A and B). RBBS-PC was enhanced to allow 36 copies of RBBS-PC to share the same files in a network environment. RBBS-PC automatically answers the phone and no longer requires each caller to enter up to 3 carriage returns in order for RBBS-PC to detect the users baud rate and parity. Logon to RBBS-PC has been made much more efficient with the USERS file no longer being searched sequentially and the MESSAGES file no longer being read three times. Version CPC12-5B, released August 25, 1985, WAS THE LAST VERSION COMPILABLE BY VERSION 1.0 OF THE IBM BASIC COMPILER! CPC13.1 12/01/85 RBBS-PC was completely rewritten for both the IBM BASIC compiler ($495 list price) and Microsoft's QuickBASIC Version 1.0($99 list price). XMODEM with CRC was added as a file-transfer protocol as well as the ability to display on the color monitor of the PC running RBBS-PC the color/graphics that the remote user sees exactly as he sees them. CPC14.1 03/16/86 (Versions A, B, C, and D) RBBS-PC's internal structure was split into two parts - RBBS-BAS for the main-line source code and logic, and a RBBS-SUB.BAS for commonly called subroutines. This allows unlimited growth for RBBS-PC by providing multiple "code segments" within RBBS-PC. Support for on-line questionnaires, auto-downloading, and the Columbia University-sponsored KERMIT RBBS-PC Version protocol were also included as well as the option to utilize assembly language subroutines to increase for better performance over their BASIC counterparts. CPC15.1 03/15/87 RBBS-PC's internal structure continued to become significantly more modularized and structured. Major enhancements included a File Management System for directories, additional file exchange protocols, support for managing subscriptions, the ability to run as a local application on a network, configurable command letters, the ability to use any field or to define a new field to identify callers, the ability to individuate callers having the same ID, multiple uploads on a single command line, new A)nswer and V)erbose ARC list commands, context sensitive help, and a new subsystem for software "libraries". CPC16.1 03/27/88 (Version A) RBBS-PC's internal structure continued to become significantly more modularized and structured. Major enhancements included the addition of "sub-boards" (i.e. conferences with there own bulletins, file areas, menus etc.), a programmable user RBBS-PC CPC17.3 Page 227 interface, the capability to have SYSOP-written "sub-menus" for any command, the ability to hang off of a public data network such as Compuserve's as a "node", the incorporation of "personal downloads" (i.e. files only specific individuals could list/download), the ability to vary the amount of time a user has on the system by the time of day the user logs on, the capability of preventing any message (public or private) from being read until the SYSOP has reviewed it, an enhanced CONFIG utility with many more options, YMODEM protocol built-in to RBBS-PC's main-line source code, the ability to automatically add users to conferences, and support for The Software Link's MultiLink Version 4.0. Despite all these enhancements, the BASIC RBBS-PC code was significantly enhanced such that it only requires 268K to run -- allowing two copies to run in multi-tasking DOS environments that have 640K available. CPC17.1 10/02/88 (Versions A, B, C, and D). RBBS-PC's internal structure continued to become significantly more modularized and structured. Major enhancements were made in the System Support area, and the support for up to eight communications ports;built-in interfaces to external communications drivers based on Vince Perriello's "FOSSIL" driver concepts; automatic notification of the SYSOP when specific users log on; improved automatic invocation of other applications based on time of day; and SYSOP-selectable time delays that users must wait before being able to download or exit to a door. RBBS-PC's unique programmable user interface (PUI) was enhanced to support "macros" (i.e. use a single command to invoke any number of RBBS-PC commands); SYSOP-selectable colors for all prompts and messages (i.e. "colorization"); caller-selectable "colorization" for text (i.e. color, bold or normal, highlighting of text, etc.); and personalized text files (i.e. text files that can dynamically adapt to include information unique to each caller). The messaging within RBBS-PC was enhanced to notify each caller that logs on of the number of new messages and how many are addressed to the caller for the conferences to which the caller belongs. The text editor function for messages was enhanced to allow any character to be edited. RBBS- PC's standard "threaded" message search now also scans the text of the messages for matches. The RBBS-PC file subsystem was also significantly enhanced to include an unlimited number of installable protocols; batch downloading for such protocols that support this (i.e. Zmodem, Megalink, and Sealink); and control of callers ability to download based on either the number of characters or the ratio of the callers downloads to uploads. CPC17.2 05/28/89 (Versions A-B). RBBS-PC's internal structure continued to evolve as an example of a modularized and structured BASIC program (20,000+ lines of source code). Major RBBS-PC CPC17.3 Page 228 enhancements consisted of increased flexibility in invoking external applications (i.e. "DOORS"), on-line questionnaires, RBBS-PC command "macros", the integration (using the enhanced questionnaires and "macros") of on-line data base facilities into RBBS-PC, as well as extended support in RBBS-PC's file system to support ANY file compaction technique (i.e. .ARC, .ZOO, .ZIP, etc.) -- including allowing on-line users to list text files that have been included within a compacted file (thanks to Samuel Smith of The Tool Shop BBS). RBBS-PC's "NETMAIL" interface to store and forward messaging systems (i.e. FIDO MAIL, etc.) was enhanced. Within the messaging subsystem numerous enhancements were added including the ability to quote all or part of a message that the caller was replying to. RBBS- PC's file subsystem was improved to allow the system to be configured such that all uploads were automatically checked/verified (by whatever utility the SYSOP wanted to use). RBBS-PC commitment to the concept of "users helping users" was demonstrated once again with the incorporation of support for the Computalker and HEARSAY 1000 speech boards so that seeing-impaired SYSOPS could hear (in a meaningful way) the activity occurring on their RBBS-PC bulletin boards. CPC17.3 01/14/90 Fast File Search: sub-second file name looks for over 32,000 downloadable files; up to 10,098 downloadable areas. Variable names were changed to MicroSoft standard format using upper and lower case letters only, and no internal dots. Some 50 bugs were fixed. News facility added. Universal command stacking. Default extension on file requests. Enhanced macros and SmartText. Defaults added for multiple modems. Support for 38,400 baud thru Fossil driver. RBBS-PC CPC17.3 Page 229 26. PROPOSED AGENDA FOR A NATIONAL SYSOP CONFERENCE --------------------------------------------------- As PC's (IBM's and others) become more common in homes and offices, their use as vehicles for information exchange continues to grow -- as so eminently attested by the astounding growth of RBBS-PC itself! A national meeting of SYSOPs could foster this growth in information exchange; assist in focusing on the issues (regulatory and otherwise) that foster/inhibit this growth; and act as a forum for new ideas. A national meeting, perhaps sponsored by the Capital PC User Group or even a consortium of other not-for-profit PC user groups could be held . SYSOPs are not only in the big corporations but also in the millions of small businesses, non-profit associations, educational institutions in which the RBBS-PC concept has found a home. They are often the decision influencers in their organizations or area -- as U.S. Robotics discovered when they introduced their Courier 2400 baud modem so successfully. As I expect most who would attend would be paying their own way, the first conference would probably consist of that small "band of brothers" who have set up boards out of the intensity of their own commitment. My own vision of such a conference is sort of a 1980's electronic "Woodstock" -- if for no other reason because of the very "volks" nature of SYSOPs. It has been a long time since there has been a conference "of the people, by the people, and for the people." What follows is a hypothetical agenda of what might be of interest at such a conference. The agenda consists of a "technical" and a "non-technical" (management?) set of sessions as follows: "technical sessions" "non-technical sessions" 8:30 - 10:00 RBBS-PC Record Layouts How to Copyright Software -- (CALLERS, USERS, and its protection and penalties MESSAGES files) for violation of copyrights. 10:30 - 12:00 Multi-Port RBBS-PC 1986 Computer Privacy Act and Systems-- actual "computer trespass" laws at experiences. the State level. 12:00 - 1:30 Luncheon with a nationally known guest speaker (any suggestions?) 1:30 - 3:00 RBBS-PC "doors" and Business Applications of "doorware" explained. Bulletin Board Systems 3:30 - 5:00 Modems -- beyond 2400 The use of RBBS-PC in local, baud. State, and Federal agencies. 5:00 - 6:30 CONNECT TIME! -- Vendor Presentations and Receptions If you are with a manufacturer or organization that might be interested in sponsoring such a meeting, work with your organization to make it happen! If in the normal course of your business contacts you see a potential sponsor of such a conference, persuade them to look into being a sponsor. I would be glad to talk with anyone about going forward with this project. RBBS-PC CPC17.3 Page 230 If you are interested in participating, write me at the following address: Tom Mack National SYSOP Conference 39 Cranbury Drive Trumbull, Connecticut 06611 Please indicate 1. Which four sessions you would attend (in order of preference). 2. Any additional sessions you would be interested in. 3. Who would you want as a guest speaker at the luncheon. 4. Where you would like such a conference held from among the following five locations: a.) Boston, Mass. b.) Chicago, Ill. c.) Houston, Texas d.) San Francisco, Calif. e.) Washington, D.C. 5. Your mailing address. 6. Telephone numbers you can be reached at (both voice and data). 7. And if you would be willing to be a "worker" as well as an attendee -- i.e. stuff envelopes, keep the mailing list, make hotel arrangements, etc. My greatest fear is not that there will be fifty of us -- but that there will be 2,000 of us! Whatever happens, it should be fun. RBBS-PC CPC17.3 Page 231 27. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD -------------------------------------------------------- RBBS-PC'S "Userware" concept is founded on the principle stated in section 0 -- "software which is shared becomes better than it was." Relying on Federal copyright protection, we believe that RBBS-PC's source code can be distributed without the risk of "loss of ownership" (i.e. it becoming "public domain"). In fact, all software (commercial and non-commercial) should be distributed as both compiled/executable files and with their source code. With one exception, RBBS-PC's copyrights have never been violated -- this is due more to the fact that RBBS-PC enthusiasts are ever-vigilant of RBBS-PC's copyrights rather than due to any lack of attempts to "sell" RBBS-PC or RBBS-PC look-alikes to the unsuspecting public. Incorporating these new features and ideas into each new release of RBBS- PC, making sure that upward compatibility with earlier version of RBBS-PC exists, as well as maintaining RBBS-PC's copyright, are all things that I accept the responsibility for. However, it is RBBS-PC's "support staff" (i.e. all those who enhance RBBS-PC and share such enhancements) that continues to make RBBS-PC a unique experiment in PC software. No one should feel that the possibilities for RBBS-PC have even begun to be exhausted. In fact, we are absolutely certain that even as this is written innovative enhancements are being created for RBBS-PC that I haven't even mentioned. It is our sincerest hope that if RBBS-PC continues to succeed within the IBM PC industry in becoming the "bulletin-board standard," software vendors will begin examining the reasons for RBBS-PC's success and come to understand that: 1. The best form of software support is user support; 2. The best source for software enhancements are from it's users; 3. The best software continually adopts itself to users needs; and 4. The best way to minimize software development is to distribute source code; Each RBBS-PC system operator has the opportunity to affect what RBBS-PC becomes in the future. Many already have. RBBS-PC continues to grow and expand because hundreds (and quite possibly thousands) of SYSOPs spend the time and trouble not only to modify RBBS-PC to meet their needs, but also to share these modifications with others. We do not know of any other software for the IBM PC that has such a vast number of programmers supporting it. In section 0.3, we name more than 70 such individuals and acknowledge that there are a lot more! With the structured design RBBS- PC's source code that the new BASIC compilers allowed, even more RBBS-PC system operators are invited to contribute. Take the time! Make the difference! RBBS-PC CPC17.3 Page 232 APPENDIX A -- RBBS-PC Record Formats ------------------------------------ This appendix is intended to document the record formats of some of the more significant records used within RBBS-PC. As such, it is intended more as a "programmers' guide" for those who wish to write RBBS-PC utilities rather than as "user documentation." No record format is "sacrosanct" and any of them may be changed in future releases. However such changes are not made capriciously and, when they are made, are accompanied by some utility program that will allow the old files to be reformatted into the new format. The MESSAGES file contains the messages that have been left on RBBS-PC. It is a random access file with 128-byte records. The first record of the MESSAGES file acts as RBBS-PC's "checkpoint" record. The records immediately following this first record are the RBBS-PC "node" records. Each "node" record represents the activity/options associated with a particular copy of RBBS-PC ("node"). There can be up to thirty-six copies of RBBS-PC running simultaneously sharing the same set of static files. Therefore there can be up to thirty-six "node" records following the "checkpoint" record. The MESSAGES file has the following logical format: +----------------------------------------------+ Record #1 | RBBS-PC "checkpoint" record | +----------------------------------------------+ Record #2 | RBBS-PC "node" record for node # 1 | | | | up to | | | | RBBS-PC "node" record for node # 9 | | RBBS-PC "node" record for node # 0 | | RBBS-PC "node" record for node "A" | | | | up to | | RBBS-PC "node" record for node "Z" | | | +----------------------------------------------+ | First Record in Message portion of file | +----------------------------------------------+ | | \ Message records that have been used \ \ \ | | +----------------------------------------------+ | Record available for next message | +----------------------------------------------+ | Last record available in MESSAGES file | +----------------------------------------------+ RBBS-PC CPC17.3 Page 233 The FIRST RECORD of the "MESSAGES" file acts as a "checkpoint" record for all the multiple RBBS-PC's that may be sharing the MESSAGES and USERS files. It contains information critical to maintaining the integrity of these two files. The layout of RBBS-PC Message File Record Number 1 is as follows: Position Length Description 1 - 8 8 Number assigned to the last message entered 9 - 10 2 Security level required to be auto-added to a conference 11 - 20 10 Current caller number 21 - 56 36 --- RESERVED FOR FUTURE USE ---- 57 - 61 5 Count of the number of USER records used 62 - 67 6 --- RESERVED FOR FUTURE USE ---- 68 - 74 7 Record Number where "messages" portion of the MESSAGES file begins 75 - 81 7 Record Number of the next available record in the MESSAGES file where the next message may be written 82 - 88 7 Record Number of the last record in the MESSAGES file 89 - 95 7 Maximum number of messages allowed in the MESSAGES file 96 -126 31 --- RESERVED FOR FUTURE USE ---- 127 -128 2 Maximum number of RBBS-PC's sharing this MESSAGES file As a programming reference, line numbers 1900 and 23000 of the BASIC source code for RBBS-PC.BAS contains the code for reading this "checkpoint" record. RBBS-PC CPC17.3 Page 234 Following the first record of the MESSAGES file are from one to 36 "node" records. Each "node" record contains information critical to the running of that copy of RBBS-PC associated with that "node". The layout of each RBBS-PC "node" record is as follows: Position Length Description 1 - 31 31 Name of last person on this copy of RBBS-PC 32 - 33 2 SYSOP available indicator (true or false) 34 - 35 2 SYSOP annoy indicator (true or false) 36 - 37 2 SYSOP is to be on next indicator (true or false) 38 - 39 2 Line printer available indicator (true or false) 40 - 41 2 Door's availability indicator (true or false) 42 - 43 2 Eight bit transmission indicator (true or false) 44 - 45 2 Caller's baud rate indicator: -1 = 300 baud -2 = 450 baud -3 = 1200 baud -4 = 2400 baud -5 = 4800 baud -6 = 9600 baud -7 = 19200 baud 46 - 47 2 Upper case only indicator (true or false) 48 - 51 4 Number of bytes transferred (from external protocols) 52 1 Batch transfer indicator (not zero = batch) 53 - 54 2 Graphics indicator (0 = text, 1 = full ASCII, 2 = color) 55 - 56 2 SYSOP indicator (-1 = SYSOP) 57 1 Activity indicator (I=inactive, A=active) 58 - 59 2 SNOOP on indicator (true or false) 60 - 64 5 Baud that RBBS-PC talks to the modem at (single precision) 65 - 67 3 Time user logged onto the system (HH:MM:SS) 68 - 71 4 --- RESERVED FOR FUTURE USE --- 72 - 73 2 Private door indicator (true or false) 74 1 Type of transfer to external program: 0 = none 1 = download a file 2 = upload a file 3 = external registration program 75 1 First letter of file transfer protocol 76 1 --- RESERVED FOR FUTURE USE ---- 77 - 78 2 Last date, MM-DD-YY, that RBBS-PC exited to DOS (packed) 79 - 85 7 --- RESERVED FOR FUTURE USE ---- 86 - 90 5 Last time, HH:MM, that RBBS-PC exited to DOS 91 - 92 2 Reliable mode indicator (true or false) 93 - 116 24 Work area that normally contains caller's City and State, but when temporarily exiting RBBS-PC used as: Position Length Description 93 -100 8 Programmable user interface file name 101 -102 2 Local user indicator (true using local PC) 103 -104 2 Local user mode (true if using COM0) 105 -112 8 Name of current "conference" or "sub-board" 113 -116 4 --- UNUSED ---- 117 -118 2 Subsystem index of last subsystem user was in. 119 -124 6 Month, day, and year, MMDDYY, exited to external protocol 125 -128 4 Hour and minute, HHMM, exited to external protocol As a programming reference and in order to see how these fields are set/used in the node records, review the following line numbers in RBBS- RBBS-PC CPC17.3 Page 235 PC.BAS -- 150, 200, 400, 420, 842, and 13555. In addition, review the following subroutines as well: Source Code Subroutine RBBSSUB2.BAS ---- WHOSON RBBSSUB3.BAS ---- FINDFUNC SAVEPROF READPROF RBBSSUB4.BAS ---- TIMEDOUT A message within the messages file consists of a MESSAGE HEADER followed by the text of the message. The RBBS-PC Message File "message header" record layout is as follows: Position Length Description 1 1 Contains an "*" for read-only messages, blank otherwise 2 - 5 4 Message number of this message 6 - 36 31 The name of the person the message is from 37 - 58 22 The name of the person to whom the message is sent 59 - 66 8 Time of day that the message was sent (HH:MM:SS) 67 - 67 1 ---- RESERVED FOR FUTURE USE ---- 68 - 75 8 Date the message was sent (MM-DD-YY) 76 -100 25 Subject of the message 101 -115 15 Password for the message (if any) 116 -116 1 "Active" message indicator = ASCII 225 "Killed" message indicator = ASCII 226 117 -120 4 Number of 128-byte records for this message -- including the the "message header" record. 121 -122 2 Minimum security level to read message 123 -125 3 Date (packed) the message was last read (MM/DD/YY) 126 -128 3 Time (packed) the message was last read (HH:MM:SS) As a programming reference, review lines 3405, 3460, 3530, and 8076 of the BASIC source code for RBBS-PC.BAS to see how these fields are set. Each record following the MESSAGE HEADER record is a MESSAGE TEXT record and consists of 128 characters. Each of these 128-byte message text" records contains the message text. The end of each line in the message is followed by an RBBS-PC "end-of-line" indicator which is equal to an ASCII 227. This allows RBBS-PC to "pack" multiple message lines in a single 128-byte record. RBBS-PC CPC17.3 Page 236 Information unique to each person who logs on is contained in the USERS file (a random file of 128-byte records). Each records is as follows: Position Length Description 1 - 31 31 Users first and last name (separated by a blank). 32 - 46 15 Users password for logon. 47 - 48 2 Users security level (permanent). 49 - 62 14 Users logon options (see detail breakdown below). 63 - 86 24 City and state from which the user is calling. 87 - 89 3 ---- RESERVED FOR FUTURE USE ---- 90 - 93 4 Number of files downloaded today 94 - 97 4 Number of bytes downloaded today 98 -101 4 Number of bytes downloaded (ever). 102 -105 4 Number of bytes uploaded (ever). 106 -119 14 Date and time the user was last on (MM-DD-YY HH:MM). 120 -122 3 Date the user last listed a directory. 123 -124 2 Number of files downloaded (ever). 125 -126 2 Number of files uploaded (ever). 127 -128 2 Elapsed time the user was on for day of last access. Line 9400 of the BASIC source code for RBBS- PC.BAS contains the code for opening this file. The user's logon options, positions 49 through 62, are utilized as follows: Position Length Description 49 - 50 2 Number of times the user has logged on 51 - 52 2 Last message number read by the user 53 1 Protocol Preference (blank if none, otherwise letter) 54 1 Graphics Preference (see meaning below) 55 - 56 2 Margin length for this users messages 57 - 58 2 Bit Flag -- this 16-bit field is denoted by bit 0 being the least significant (i.e. right-most bit) and bit 15 being the most significant (i.e. left-most bit). These "bit flags" have the following meanings (0=off, 1=on): BIT Definition (what ON means) 0 Bell prompts 1 "Expert" mode 2 Nulls 3 Upper case only 4 Line feeds 5 Skip old bulletins 6 Check new files on logon 7 Use autodownload 8 Required questionnaire answered 9 Mail Waiting 10 Highlighting enabled 11 "TurboKey" enabled 12-15 RESERVED FOR FUTURE USE 59 - 60 2 Date subscription began 61 1 Page length to use for this users terminal 62 1 ------- RESERVED FOR FUTURE USE --------- --- 14 The meaning of the graphics preference byte depends on the numeric value it has. The caller can specify, for text files, no graphics, ascii graphics, RBBS-PC CPC17.3 Page 237 or ansi color graphics; then the color, and then whether normal or bold. For example, if graphics perference for text files is color, and preference for normal text is light yellow, graphics preference stored is 38. Colors are Red, Green, Yellow, Blue, Purple, Cyan, and White. normal bold graphics\color R G Y B P C W R G Y B P C W none ...... 30 33 36 39 42 45 48 | 51 54 57 60 63 66 69 ascii ...... 31 34 37 40 43 46 49 | 52 55 58 61 64 67 70 ansi ...... 32 35 38 41 44 47 50 | 53 56 59 62 65 68 71 RBBS-PC CPC17.3 Page 238 APPENDIX B -- RBBS-PC in a DESQview Environment ----------------------------------------------- By John L. Taylor - Sysop, Indiana On-Line (tm) BBS: (812) 332-RBBS DESQview, from Quarterdeck Office Systems, provides an excellent, low-cost, software platform for RBBS-PC Sysops wanting multiple nodes on a single PC. This appendix has been provided to help both the novice sysop and the more experienced sysop with the implementation of multiple nodes under DESQview. 1. Basic Hardware Considerations --------------------------------- If your computer has only 640k, you will be limited to a single node when using DESQview. If, however, your computer has 1-Megabyte or more of EEMS memory, DESQview is capable of supporting up to 8-nodes on a single computer. Providing two nodes is simple. Going beyond two nodes will require special software and hardware. This appendix describes both approaches. Multiple-node operation will require an EEMS-compatible memory expansion card for your computer. Make certain your memory card is EEMS (not merely EMS, but EEMS) compatible! We've answered a lot of calls from distressed Sysops who purchased an EMS memory card and found it was inadequate for their needs. DESQview has some limitations in a PC or AT, unless you can reduce the motherboard memory to 64k, 128k or 256k. The amount of memory on your motherboard will affect the size of your 2nd, 3rd, etc. windows. This limitation is described in the DESQview documentation. These limitations do not apply if you use an 80386/SX or 80386 based computer. Therefore, we recommend an 80386 as the best choice for a multi-node host computer. If you plan to use an 80386 or 80386/SX computer, we suggest you purchase DESQview/386, which includes the QEMM memory manager. This memory manager allows DESQview to use regular 80386 Extended memory in the same manner as EEMS memory. The QEMM memory manager may be purchased separately if you already have DESQview. Before you continue, make certain you have read and thoroughly understand the instruction manual provided with your copy of DESQview. If you plan to implement some of the more advanced configurations, additional software may be necessary. This software is available on our BBS, Indiana On-Line (tm). Our BBS telephone number is published at the end of this DESQview appendix. 2. Modifications to DOS CONFIG.SYS and RBBS-PC batch files ----------------------------------------------------------- The first step in using DESQview with RBBS-PC is setting up your CONFIG.SYS file. Files=35 is probably the most critical value. This value tells DOS how many files may be open at the same time. This value may need to be increased if you intend to run more than 2 nodes of RBBS-PC. A typical CONFIG.SYS file should include the following: FILES = 35 BUFFERS = 25 If you intend to operate two or more nodes of RBBS-PC, a batch file will be required for each node. We also recommend a separate batch file (that is called from DESQview) to invoke the proper RBBSx.BAT file for each node. In our example, this batch file is named START.BAT. You will note by these RBBS-PC CPC17.3 Page 239 examples that we're passing the node number from DESQview to the batch file START.BAT. The START batch file uses that parameter to call the appropriate RBBSx.BAT batch file. Using separate files will allow you to place programs that should be loaded only once in the START batch file. Programs invoked from the RBBSx.BAT files are invoked each time RBBS exits for a DOOR or external protocol. This may cause certain TSRs to use additional memory if they load a new copy each time they are invoked. Using a separate batch file will ensure TSRs are loaded only once. Contents of C:\RBBS\START.BAT Description of each line's function. ----------------------------- --------------------------------------- DVANSI ...loads DESQview ANSI.SYS driver LDFILTER.COM ...explained later in this appendix SET DSZLOG=XFER-%1.DEF ...set DOS environment variable for DSZ RBBS%1 ...call appropriate node RBBSx.BAT file Contents of C:\RBBS\RBBS1.BAT Contents of C:\RBBS\RBBS2.BAT ---------------------------------- ---------------------------------- IF EXIST RCTTY1.BAT DEL RCTTY1.BAT IF EXIST RCTTY2.BAT DEL RCTTY2.BAT WATCHDG1 OFF WATCHDG2 OFF RBBS-PC.EXE 1 RBBS-PC.EXE 2 WATCHDG1 ON WATCHDG2 ON IF EXIST RCTTY1.BAT RCTTY1.BAT IF EXIST RCTTY2.BAT RCTTY2.BAT RBBS1.BAT RBBS2.BAT In the above examples, the program WATCHDOG is being used to monitor for carrier when the SYSOP has dropped into DOS remotely or a user has opened a Door. For example, WATCHDG1 monitors COM1 and WATCHDG2 monitors COM2. If you aren't using WATCHDOG, leave these commands out of your batch files. 3. What to Tell RBBS-PC's "CONFIG" Utility ------------------------------------------- When using DESQview, you will need to change some parameters with the CONFIG program (supplied with RBBS-PC). The following change is ample if you are planning to run a single node. 162. Environment running concurrent RBBS-PC's ------ DESQview If you intend to use two or more nodes of RBBS-PC, you will need to change a few additional parameters with the RBBS-PC "CONFIG" utility. When using multiple nodes of RBBS-PC you will be using a .DEF file for each node. Each node will have a .DEF file named RBBS?PC.DEF where ? represents the number of the node. These are created by answering YES to the question "Will you be running multiple copies of RBBS-PC (YES or NO)?" when the "CONFIG" utility first loads. If you prefer to use the parameters from your existing single node RBBS-PC.DEF file, you may simply copy that file to the new .DEF files before you run the "CONFIG" utility. After loading the "CONFIG" utility, it will ask you "To which copy of RBBS-PC will these options apply (1 to 36)?" and you should respond with node number (or copy) you want to configure. Here are the parameters that will have to be changed for each node of RBBS-PC you intend to use. This example is for a system with two nodes. RBBS-PC CPC17.3 Page 240 Parameters for Node-1 -- Node DEF file--> RBBS1PC.DEF ---------------------------------------------------------------------- 103. File built dynamically to open a 'door' ------ C:\RBBS\RCTTY1.BAT 104. When a 'door' closes, re-invoke RBBS-PC via -- C:\RBBS\RBBS1.BAT 161. Maximum number of concurrent RBBS-PC's ------- 2 162. Environment running concurrent RBBS-PC's ------ DESQview 221. Communications port to be used by RBBS-PC ---- COM1 Parameters for Node-2 -- Node DEF file--> RBBS2PC.DEF ---------------------------------------------------------------------- 103. File built dynamically to open a 'door' ------ C:\RBBS\RCTTY2.BAT 104. When a 'door' closes, re-invoke RBBS-PC via -- C:\RBBS\RBBS2.BAT 161. Maximum number of concurrent RBBS-PC's ------- 2 162. Environment running concurrent RBBS-PC's ------ DESQview 221. Communications port to be used by RBBS-PC ---- COM2 Please note that the preceding parameters are located on different pages of the "CONFIG" utility. The parameter numbers may also differ slightly, depending on the version of RBBS-PC you are using. 4. DESQview Setup Default Settings ----------------------------------- The first step in configuring DESQview for use with RBBS-PC is specifying the default settings for DESQview. DESQview has a setup program that may be invoked at the DOS prompt. Enter SETUP to run this DESQview setup routine. After the SETUP program loads, press RETURN for the Advanced Setup Procedure followed by a "P" for Performance defaults. Here is an example of the recommended settings: ------------------------------------------ I Task Processing Time (in Clock Ticks) I Optimum Fore/Backgrnd can vary I Foreground: 9 I between 15/14 and 4/3. These I Background: 8 I settings will vary depending on I I CPU speed and number of nodes I Memory Usage (in K) I in operation. Experiment with I Common Memory: 24 I different settings to find the I DOS Buffer for EMS: 2 I best for your system. I I I Optimize communications? (Y/N): N I Select [Y] if you're operating I Allow swapping of programs? (Y/N): Y I only 1-node under DESQview! I Manage printer contention? (Y/N): N I I I I Next field Tab I I Backup menu Esc I I DONE < I I I ------------------------------------------ NEVER indicate more clock ticks for Background processing than you are using for the Foreground processing. DESQview will automatically increase the amount of Background clock ticks whenever there is little demand for Foreground processing. This will be the case when running RBBS-PC in the background and doing word processing or a similar task in the foreground. This feature cannot function properly if the Background clock ticks are set higher than the Foreground clock ticks. Setting the High Speed Comm default to YES will make communications interrupts the highest priority. While this is suggested if you operate a single node, you should specify NO RBBS-PC CPC17.3 Page 241 for optimum performance when operating multiple nodes. 5. Adding RBBS-PC to DESQview's "Open Window" Menu ---------------------------------------------------- Refer to the section "Adding Your Own Program" in the DESQview manual. You will need to "Add a Program" for each node of RBBS-PC you intend to operate on your system. You may name the programs N1, N2, etc. N1 will load the batch file START.BAT with the Parameter "1". N2 will load START.BAT with the Parameter "2" and so on. Use the following settings for each node (or copy) of RBBS-PC you install. Add a Program -------------------------------------------------------------------------- Program Name............: [NODE-1] Keys to Use on Open Menu: N1 Memory Size (in K): 380 Program...: START Please note that Memory Size above may need to be increased if you intend to Parameters: 1 (node number) SHELL (rather than DOOR) to External file transfer protocols. Directory.: C:\RBBS Options: Writes text directly to screen.......: [N] Displays graphics information........: [N] Virtualize text/graphics (Y,N,T).....: [N] Uses serial ports (Y,N,1,2)..........: [Y] <-N if Using a Requires floppy diskette.............: [N] FOSSIL driver --------------------------------------------------------------------------- Next, press F1 for the Advanced Options menu. Change a Program Advanced Options --------------------------------------------------------------------------- System Memory (in K).......: 0 Maximum Program Memory Size (in K)..: Script Buffer Size.......: 1 Maximum Expanded Memory Size (in K): Text Pages: 1 Graphics Pages: 0 Initial Mode: Interrupts: 00 to FF Window Position: Maximum Height: 25 Starting Height: Starting Row...: Maximum Width.: 80 Starting Width.: Starting Column: Shared Program Pathname..: Data......: Close on exit (Y,N,blank)......: [N] Uses its own colors............: [Y] Allow Close Window command.....: [Y] Runs in background (Y,N,blank).: [Y] Uses math coprocessor..........: [N] Keyboard conflict (0-4)........: [0] Share CPU when foreground......: [Y] Share EGA when foregrnd/zoomed.: [Y] Can be swapped out (Y,N,blank).: [N] Protection level (0-3).........: [0] --------------------------------------------------------------------------- 6. Memory Considerations RBBS-PC CPC17.3 Page 242 ------------------------- Please refer to your DESQview documentation for information regarding the use of XDV.COM and optimizing the size for each DESQview window. Current versions of DESQview require a little under 180k of your system's memory, leaving only 430k to operate RBBS-PC on a system with 640k. Specify a minimum window size of 380k for RBBS-PC. If you choose to SHELL (rather than DOOR) to external protocol drivers for file transfers, you will have to increase this window size. It is necessary to use EEMS memory to run two or more concurrent copies of RBBS-PC under DESQview. If available EEMS memory allows, you may wish to add an additional "LOCAL" node for Sysop use. When using an additional node for SYSOP duties, an additional modem and RS-232 interface are not required. Simply use CONFIG to set up the .DEF file for the node you are planning to use for SYSOP duties. You must specify the communications port as COM0. Failure to do so will prevent your local Sysop node from loading properly. 7. Expanded Memory ------------------- If you are using an "Expanded Memory" board that allows more than 640k to be used for programs, the constraints discussed in the previous section may not apply. Specify a window size of 460K for each node of RBBS-PC and invoke the external protocol drivers by SHELLing. For information on running programs in expanded memory, refer to the manuals for DESQview and your particular memory board. 8. How to AUTOEXEC RBBS-PC From DESQview ----------------------------------------- Refer to the section "LEARN: DESQview's Keystroke Macro Feature" in the DESQview manual. A script assigned to the ! key (on the DESQview menu) has a special meaning. It is performed at the time you start up DESQview, immediately after the DESQview menu appears. This is called a STARTUP SCRIPT. You should "Learn" the Startup Script with no windows open and with the DESQview menu displayed to be sure it will play back properly. Use this particular script to load N1, N2, etc. of RBBS-PC. If you load DESQview from your AUTOEXEC.BAT file, RBBS-PC will load from DESQview automatically. This can be handy if there is a power outage while you are away and no one is around to re-load RBBS-PC when the electricity returns. You should open the window(s) for RBBS-PC prior to opening windows for any other application software. 9. Quarterdeck Utilities ------------------------- Two Quarterdeck utilities, STDERR.COM and LDFILTER.COM are distributed with RBBS-PC. LDFILTER.COM should be executed when you open a window in DESQview. If you use the Small & Fast version of RBBS-PC - or - you compile RBBS-PC with QuickBASIC v2.01, you should use LDFILTER.COM. In the above examples, LDFILTER would be placed into the START.BAT batch file. LDFILTER was written by Quarterdeck Office Systems to compensate for the memory mismanagement of the BASIC compilers. If you try to "SHELL" to an external routine the error "not enough memory to SHELL" is issued. LDFILTER.COM prevents this error condition by preventing the code generated by the BASIC compilers from mis-managing memory. STDERR.COM should be executed from your autoexec.bat file, prior to loading DESQview. STDERR was written by Quarterdeck Office Systems to compensate RBBS-PC CPC17.3 Page 243 DOS' inability to redirect the standard error output to the same device that the standard output device had been redirected to. If you are running something remotely and an error occurs, STDERR.COM allows the error to be displayed at the remote user's end and not simply on the PC that is running RBBS-PC under DESQview. 10. Redirecting I/O Considerations (DOS CTTY Command) ----------------------------------------------------- The DOS CTTY command is NOT supported under DESQview. The GATEWAY device driver version 2.0, by Hans D. Kellner, provides an excellent alternative. This device driver is available on many bulletin boards (including our BBS) under the filename GATEWAY2.ZIP or GATEWAY2.ARC. Since the DOS CTTY command is not supported within a DESQview window, you may use GATEWAY2 to allow redirection of I/O. This will allow the Sysop Function 7 (drop to DOS) to function properly! It will also allow RBBS-PC DOORS to function that rely on the CTTY command. Instructions for installing GATEWAY2 with RBBS-PC. 1) Place the file 'GATEWAY2.SYS' in your boot disk root directory. 2) Add the following lines to your 'CONFIG.SYS' file: DEVICE=GATEWAY2.SYS -D -1 <-- for node-1 using COM1 DEVICE=GATEWAY2.SYS -D -2 <-- for node-2 using COM2 (note) You must change the [-d] parameter to [-f] if you are using a FOSSIL driver (described later in this appendix). 3) Run the RBBS CONFIG.EXE program for each node of RBBS-PC you're using. You will need to change parameter #106 as follows: 106. Use the Dos 'CTTY' command to redirect I/O --- NO ---- Redirect I/O via the CTTY command on dropping to DOS? Y)es or N)o N --- Redirect I/O via a device named in CONFIG.SYS? Y)es or N)o Y --- Enter name of the device to use. GATE2 ------- Use the device named GATE2? Y)es or N)o Y --- The use of GATEWAY2 has an added benefit for those Sysops who provide the PC-SIG collection of files on CD-ROM. When a user A)rchives a disk, RBBS-PC will use Gateway to redirect the archive activity (normally seen only on the SysOp's screen) to the remote user. This will allow the caller to see the PC-SIG disk being archived! 11. FOSSIL Drivers - Break the 2-node Barrier under DESQview! ------------------------------------------------------------- The BASIC language can only support COM1 and COM2, and when either of these are selected and you specify that you will not be using a "FOSSIL" driver, RBBS-PC will use the built-in BASIC support for remote access (i.e. via a communications port and a modem). However, RBBS-PC will interface with "FOSSIL" drivers that support not only COM1 and COM2 but also COM3 through RBBS-PC CPC17.3 Page 244 COM8. If you use parameter 221 to indicate that RBBS-PC is to access the communication port via a FOSSIL driver, the FOSSIL interface (FOSSCOMM.OBJ) written by Daan Van der Weide will be used. FOSSCOMM.OBJ provides access to whatever FOSSIL drivers that are installed on the PC running RBBS-PC. In a multi-tasking environment such as DESQview up to 8 copies of RBBS-PC can run simultaneously accessing COM1 to COM8, respectively, using Ray Gwinn's X00.SYS device driver. Ray can be reached via FidoNet (109/639) or the RENEX bulletin board at (703) 494-8331 or (703) 690-7950. X00.SYS is also available from our BBS. Here's an example of how to specify fossil support, using the CONFIG parameter 221: 221. Communications port to be used by RBBS-PC ---- # of communication port to use (1-8, or 0 for LOCAL WORKSTATION)? 2 --- Use FOSSIL driver support Y)es or N)o Y --- Enter port address, i.e. 3F8? 2E8 (using COM4) ----- If you choose to implement a fossil driver, you'll want to change the following parameter for each DESQview window: Options: Uses serial ports (Y,N,1,2)..........: [N] <--Set to NO If the fossil is handling communications, you should tell DESQview that RBBS is NOT using serial ports. That way, only the fossil is handling the communications for each port. In the following text, we will attempt to give you some basic information regarding the use of X00.SYS with RBBS-PC. For additional information, please refer to the documentation provided with the X00.SYS fossil driver. There are several approaches that can be taken to implement serial ports with Ray Gwinn's X00.SYS. THE FIRST APPROACH involves the use of separate base I/O addresses and separate IRQs for each serial port. This is the method we use on our BBS to provide 4-ports on a single 80386-based computer. We use the following configuration: Card #1 COM1 IRQ4 3F8h (standard IRQ, standard base I/O) Card #1 COM2 IRQ3 2F8h (standard IRQ, standard base I/O) Card #2 COM3 IRQ7 3E8h (non-standard IRQ, standard base I/O) Card #2 COM4 IRQ5 2E8h (non-standard IRQ, standard base I/O) We use serial ports with the NS16550AN UART chips. This particular chip is recommended if you intend to use 9600-bps modems with multiple nodes under DESQview. We had difficulties with Zmodem (DSZ) under DESQview until these chips were installed on our serial cards. For reference, here's the line from our CONFIG.SYS to invoke the X00.SYS fossil driver. In addition to specifying the IRQs and base I/O for each port, we lock our ports to 19,200-bps for our Courier HST DS Modems. This is not necessary if you are using a standard Hayes-compatible 2400-bps modem. This entry is on a single line but appears as two lines below. RBBS-PC CPC17.3 Page 245 DEVICE=C:\X00.SYS E T=2048 R=2048 0=3F8,IRQ4 1=2F8,IRQ3 2=3E8,IRQ7 3=2E8, IRQ5 B,0,19200 B,1,19200 B,2,19200 B,3,19200 We have also configured GATEWAY2 (discussed earlier in this text) to make use of the fossil driver. Here's the entry from our CONFIG.SYS as an example. DEVICE=C:\GATEWAY2.SYS -F -1 (gateway for COM1) DEVICE=C:\GATEWAY2.SYS -F -2 (gateway for COM2) DEVICE=C:\GATEWAY2.SYS -F -3 (gateway for COM3) DEVICE=C:\GATEWAY2.SYS -F -4 (gateway for COM4) THE SECOND APPROACH also involves the use of a separate base I/O for each port, but IRQs are "shared". Recent versions of X00.SYS will manage the use of a "Shared" IRQ. For example, COM1 and COM2 on the first serial card share IRQ4. COM3 and COM4 on the second serial card share IRQ3. Under this arrangement each port sharing an IRQ must be located on the SAME CARD. This requirement is not due to X00.SYS but is, instead, a hardware restriction; IRQs cannot be shared between boards. In both the above examples, NON-intelligent serial cards are used. RBBS-PC will NOT support the many "Intelligent" multi-port I/O cards on the market. These "Intelligent" boards are popular in other environments (such as UNIX) but they provide a datastream into the host using a single base I/O address. RBBS must receive its communications at a separate base I/O for each port. Here's a chart of generally accepted IRQs and base I/O addresses for the standard PC/AT and PS/2. Although these are the common settings, they vary (and we stress VARY) according to serial card manufacturer. Standard AT BUS Microchannel (PS/2) BUS --------------------------------------------------------------------------- PORT BASE I/O IRQ PORT BASE I/O IRQ --------------------------------------------------------------------------- COM1 3F8h IRQ4 COM1 3F8h IRQ4 COM2 2F8h IRQ3 COM2 2F8h IRQ3 COM3 3E8h IRQ4 COM3 3220h IRQ3 COM4 2E8h IRQ3 COM4 3228h IRQ3 COM5 3F8h IRQ4 COM5 4220h IRQ3 COM6 2F8h IRQ3 COM6 4228h IRQ3 COM7 3E8h IRQ4 COM7 5220h IRQ3 COM8 2E8h IRQ3 COM8 5228h IRQ3 --------------------------------------------------------------------------- If you intend to duplicate the 4-node configuration we use on our BBS, you will need to find a serial card that will let you choose any IRQ from IRQ3 to IRQ7 for each port (1 through 4). If you have difficulty locating a serial card with this flexibility, you may contact us and we'll provide you with a reliable source. In closing, there are also some important issues to consider when choosing to go beyond two ports on a single computer. These include: 1) EXTERNAL PROTOCOL SUPPORT. The external protocol drivers you choose must let you either define the IRQ for the additional ports, or they just rely on the fossil driver for their communications. In other RBBS-PC CPC17.3 Page 246 words, they must have support for fossil drivers. Some protocols scan a port for I/O without using an IRQ. These will probably work if you use standard base I/O addresses for your additional ports. You may contact our BBS for information regarding what external protocols we have tested on our additional ports (COM3 and above). 2) CPU SPEED LIMITATIONS. Here's a chart indicating my recommendations for each computer type, amount of EEMS memory and number of nodes. --- PERFORMANCE --- HOST 1-Node 2-Nodes 3-Nodes 4-Nodes 5-Nodes 6-Nodes 7-Nodes 8-Nodes COMPUTER 640k 1.4Mb 2.0Mb 2.6Mb 3.2Mb 3.8Mb 4.4Mb 5.0Mb --------------------------------------------------------------------------- PC 4.77-MHz A2 C3 F5 F5 F5 F5 F5 F5 PC 8-12-MHz A1 B2 D5 F5 F5 F5 F5 F5 AT 8-12-MHz A1 B2 C4 D5 F5 F5 F5 F5 AT 16-20-MHz A1 A1 B3 C3 D5 D5 F5 F5 80386/SX A1 A1 A2 B2 C4 C4 D5 D5 80386/16-MHz A1 A1 A2 A2 B3 B3 C4 C4 80386/25-MHz A1 A1 A2 A2 B3 B3 C3 C3 80386/33-MHz A1 A1 A1 A2 B3 B3 B3 B3 --------------------------------------------------------------------------- A=EXCELLENT at 2400-bps 1=EXCELLENT at 9600-bps B=GOOD at 2400-bps 2=GOOD at 9600-bps C=MARGINAL at 2400-bps 3=MARGINAL at 9600-bps D=POOR at 2400-bps 4=POOR at 9600-bps F=Not Recommended 5=Not Recommended at 9600-bps --------------------------------------------------------------------------- Your results may vary due to MIPS rating and bus speed of the computer used. If you plan to support BPS rates of 9600 or above on one or more nodes, we recommend the use of NS16550AN UART chips. These chips are necessary for acceptable Zmodem (DSZ) performance under DESQview. 12. Thanks to those that helped! -------------------------------- I'd like to thank the following people that provided assistance in the preparation of the information contained in this appendix. Jon Martin (who always took time to answer my DESQview questions), Ray Gwinn (for his help regarding X00.SYS and its usage), Dan Fox (who provided helpful insight for sharing IRQs) and Tom Hansen of the Church Chatters BBS (for his many hours of help regarding the areas of RBBS I'm not very knowledgeable about). 13. RBBS-PC Technical Support For DESQview ------------------------------------------ If you follow these instructions and continue to have difficulties, please contact me and I'll do my best to help out. We offer a DESQview/RBBS "DV" Subboard on our BBS that you may call for technical help. I try to answer questions promptly. You may also contact me at the numbers below. In addition to providing DESQview support, I can be of assistance to those operating multi-node bulletin boards on a NOVELL Local Area Network. We use a Novell LAN as the "backbone" for our BBS. It works nicely with RBBS-PC CPC17.3 Page 247 DESQview! I do not receive any financial support from Quarterdeck (or anyone else) for helping other Sysops. Often callers have made the assumption I worked for the folks at Quarterdeck Office Systems; I don't. I have a regular job (in the computer field, of course). I've been using RBBS-PC since July 4, 1984. I enjoy RBBS-PC and believe it's a product, and concept, worth supporting! John L. Taylor BBS: (812) 332-RBBS Sysop, Indiana On-Line (tm) --------------------- President, Indiana Digital Corp. 3/12/24/96/14,400-bps Work: (812) 332-1110, 9am-9pm EST HST & V.32 Compatible Home: (812) 332-0111, weekends 5-nodes 24-hours 1-Gb RBBS-PC CPC17.3 Page 248 APPENDIX C -- RBBS-PC in a MultiLink Environment ------------------------------------------------ RBBS-PC only runs under Multilink versions 4.0, 3.02 and earlier. CONFIG's allows the SYSOP to tell RBBS-PC that it will be running in a MultiLink environment. This is ESSENTIAL when running RBBS-PC under MultiLink. CONFIG allows the SYSOP to specify what MultiLink terminal type code to pass to MultiLink whenever RBBS-PC exits to DOS via a "Door". Page 15 of the MultiLink documentation specifies the various terminal type codes. When a SYSOP indicates that "doors" are available (via parameter 101 of CONFIG) and RBBS-PC is to be run under MultiLink, the SYSOP is asked to select the MultiLink terminal type that RBBS-PC is to inform MultiLink to expect when MultiLink is given control of the "Door." RBBS-PC has been tested running two copies of RBBS-PC under DOS 3.2 and MultiLink Advanced (versions 3.02 and 4.0) on an IBM PC which had a mother- board containing 256K and an AST Comboplus board with 384K (a total of 640K). However, to do this RBBS-PC must be re-compiled (see Appendix Y). The "autoexec" file was named AUTOEXEC.BAT and contained the following parameters MLINK /9,266/9,266 NOTE! ==>RBBS-PC must be recompiled with C:512 in order to run in a 268K partition under MultiLink. As released, RBBS-PC is compiled with the parameter C:4096 which requires a MultiLink partition of 270K. Of course, to SHELL to the external protocols, the partitions must be about 440K. It is important to avoid doing several things when running RBBS-PC under MultiLink. First, NEVER RUN MLSLICE! This is because MLSLICE hangs off the PC's timer chain and the code generated by the BASIC compilers violates all sorts of DOS conventions whenever it is utilizing the PC's speaker (i.e. as when RBBS-PC pages the SYSOP). In so doing, the code generated by the BASIC compilers is incompatible with programs that do follow DOS conventions. Second, NEVER use the DOS "PRINT" command! This is because there is a bug in the code generated by the BASIC compiler that causes the system to hang if a compiled BASIC program is running and DOS is printing something. This bug has been corrected in the BASIC compiler that was used to generate RBBS-PC.EXE that is distributed. However the version of RBBS-PC that you get (if other than from CPCUG) may not have this bug corrected. This is a bug that occurs independent of running MultiLink. Third, check your Intel 8088 chip's copyright date by opening up the cover and locating the 8088 chip. If the copyright date printed on the chip is 1978 (i.e. pre 1981), REPLACE THE INTEL 8088 CHIP!!!!! The 1978 Intel 8088 chip had several design flaws that will cause your system to lock up occasionally. One of these design flaws allowed interrupts to occur while stack switching (something that will happen running multiple partitions doing disk I/O under any multi-tasking DOS add-on such as MultiLink or even IBM's TopView). Don't blame MultiLink for the flawed Intel 8088 chip that IBM put in your PC! It costs about $70 ($35 for the chip and $35 for labor) and takes about 15 minutes to have the 1978 Intel 8088 chip replaced. In fact, if you are going to replace your 1978 Intel 8088 chip, you might consider the newer (and 5% to 10% faster) NEC V20 chip. RBBS-PC CPC17.3 Page 249 Fourth, DON'T USE "BUFFERS=" in the CONFIG.SYS for DOS! This may be an "old wives tale," but I am convinced (but can't prove) that there are incompatibilities between the code the BASIC compiler generates, DOS's use of "BUFFERS=", and MultiLink. Fifth, DON'T ALLOW MNP PROTOCOL for file transfers. An incompatibility exists between the Software Link, Inc.'s Multi-Link and MICROCOM's MNP software. Until the respective vendor's resolve this, don't use both products concurrently! Sixth, RBBS-PC will only run in Background 1 or Background 2. Finally, DON'T RUN PROGRAMS THAT USE THE BASIC "RUN-TIME" LIBRARY, and always invoke the BASIC interpreter with the command BASIC /C:0! Both the BASIC interpreter's handling of communications ports and BASRUN.EXE seem to violate enough DOS conventions to "lock up" MultiLink. When RBBS-PC is told that it is running in a MultiLink environment via CONFIG parameter 162, RBBS-PC will automatically do the following: 1. When re-cycling, it will automatically enque on the correct MultiLink resource ID for the communications port defined in CONFIG for that copy of RBBS-PC to use. 2. When re-cycling, it will automatically tell MultiLink that this is a type "9" partition (i.e. MultiLink is NOT to handle the communications port). 3. When exiting to DOS via a "door", RBBS-PC will automatically tell MultiLink to start handling the communications for this partition (COM1 or COM2) and what type of terminal was defined in CONFIG that would be on the communications port (MultiLink terminal types 1 through 12). Manually, it is possible to bring up and run one copy of RBBS-PC under MultiLink. The only way that I have been able to bring up two copies of RBBS-PC successfully (one copy running in each of two partitions) was to bring them up via AUTOEXE1.BAT and AUTOEXE2.BAT files. It appears that during the MultiLink initialization sequence when the partitions are being established and the "AUTOEXEx.BAT" files are being invoked that MultiLink doesn't get "confused" and lock up with a second copy of RBBS-PC present. If using Multi-Link to run multiple nodes in the same machine under DOS 3.x or above, it is recommended that the SYSOP execute SHARE.COM prior to starting multiple RBBS-PC nodes under Multi-Link and specify FILES=20 in the CONFIG.SYS file. RBBS-PC CPC17.3 Page 250 APPENDIX D -- RBBS-PC in a CORVUS Network ----------------------------------------- RBBS-PC uses the standard Corvus SEMAPHORES when sharing files among multiple copies of RBBS-PC within a Corvus Network. This is accomplished via the MS-DOS utility driver, DRIVEC2, that Corvus supplies with its network. On a multi-server Corvus network (i.e. where there are multiple shared hard disk drives) all PC's that are running RBBS-PC within the Corvus network MUST have their "home volume" on the same server. Corvus maintains each PC's semaphores on that PC's "home volume". In order to "share" files among various PC's in a Corvus network, all the PC's that are "sharing" must also be looking at the same set of semaphores. In a single-server Corvus network this is not a consideration because there is only one "home volume." RBBS-PC has been only tested with the Corvus CONSTELLATION II interface cards and software that Corvus provides for the IBM PC. RBBS-PC should work with both Corvus' older "flat cable" network as well as their newer OMNINET twisted wire pair cable network when running CONSTELLATION II software. It is entirely possible that RBBS-PC would work with some combination of both Corvus network types as long as they were running CONSTELLATION II software. It should be self-evident that every PC within a Corvus network running RBBS-PC must have a Corvus interface card. If multiple copies of RBBS-PC are running in a Corvus network that is using older Corvus software (i.e. NOT running the CONSTELLATION II software), the interface cards must, at least, all have the CONSTELLATION II ROM. RBBS-PC is tested only to run on IBM PC's within a Corvus network. Clearly an IBM "clone" that can run IBM's DOS, RBBS-PC.EXE, and is supported by Corvus' network should also work. However, such configurations (and their many variations) are not part of the environment within which RBBS-PC is tested and supported. RBBS-PC CPC17.3 Page 251 APPENDIX E -- RBBS-PC in ORCHID or AST PCnet NETWORK ---------------------------------------------------- RBBS-PC can be implemented on an Orchid PCnet or AST PCnet Network environment. It is assumed that the necessary network hardware is installed correctly. The following discussion describes a network currently in operation and receiving more than 1000 calls per week on two telephone lines for the Computer Connection of Virginia Beach. The hardware and software was: 1. 80286 based SERVER with 512K running at up to 9 mhz with: Parallel-Serial Board on the AT with a serial port addressed as COM1 AST Rampage memory board configured with 2 megs of expanded memory Monochrome Adapter with parallel printer port PC Net adapter addressed as 0080 with default jumpers Hard disk that can be divided into multiple volumes Single High Density [1.2 meg] floppy disk External modem and cable connected to COM1 2. 8088 based WORKSTATION with 640K running at up to 8 mghz with: multifunction board with COM1, a clock, and parallel port PC Net adapter addressed as 0011 with default jumpers Color Graphics Adapter Two 360K floppy drives External modem and cable connected to COM1 3. Software - Operating System = DOS 3.1 network-wide Network Software = Orchid PC Net 3.0a Disk Caching Software = Orchid CACHE.EXE version 2.2 RAM Disk = AST FASTDISK Installation procedures --- 1. Preliminaries 1. Backup hard disk, system and network disks. 2. If your hardware is different, be sure to resolve INTerrupt conflicts with the PC NET adapters. Disable second serial or parallel ports in all PC's. 2. Using the WORKSTATION, boot with DOS 3.1 then 1. Create the SERVER and WORKSTATION boot disks with SPCGEN and UPCGEN commands, respectively. 2. Copy device drivers for the hard disk, for the RAM disk, and for Expanded and Extended memory (REMM.SYS and REX.SYS) to the SERVER boot disk as well as CACHE.EXE. Place the following CONFIG.SYS file for the SERVER: device=spc.com <-- Network SERVER driver device=REMM.SYS <-- Expanded memory driver device=rex.sys 1024 <-- 1MB Emulated extended memory device=fastdisk.sys 1024 512 128 /e <-- RAM disk in extended memory 3. Place the following commands in the AUTOEXEC.BAT file: disk13 <-- Network for floppy disk use cache [drives] d=128 x=896 /r <-- 128K cache of DOS memory & 896K of EMS memory for SERVER drives to reduce the number of disk accesses spcbio 138023 <-- Tell network of interrupts used 4. Using the SERVER, boot with the newly created SERVER boot disk 1. Run the network program SPCINST. 2. After naming all the available drives on the server, assign all the hard drive volumes to the WORKSTATION # 11 and them all READ/WRITE capable. "Remote Execution" need not be enabled. 3. The SERVER will then reboot and the network will have the final configuration as outlined above. 5. Boot the WORKSTATION with the newly created WORKSTATION boot disk and: 1. Add FILES = 16 to the CONFIG.SYS file for the WORKSTATION. RBBS-PC CPC17.3 Page 252 2. Use the network program UPCINST to communicate with SERVER # 80. 3. "Map" in all the drives that were assigned by the SERVER. 4. The WORKSTATION will reboot so the changes can take effect. 5. After the WORKSTATION reboots, do a DIR C: to see if the directory on the SERVER hard disk can be read. If not, recheck cables, plug-in cards for INTerrupt conflicts, and network adapter cards to verify all jumper settings. If necessary, run the SELFTEST and NETTEST diagnostics for the network adapter cards. Also, demonstrate the ability to copy files across the network to and from the server then verify the transfer using the COMP command. 6. Assuming that you are able to do a DIR across the network and copy files to and from the SERVER, you are then ready to run CONFIG.EXE of RBBS-PC. Run CONFIG and confirm use of RBBS-PC in a multinode environment. Assign the number 1 Node to your SERVER. 1. Assign all welcome, bulletin, help and menu files to the SERVER's RAM drive so the workstation may access them in the fastest way. 2. Store FILESEC, PASSWRDS, MESSAGES, USERS and other sensitive files in a non-downloadable but sharable drive volume on the SERVER so the workstation may have read/write access to them. 3. Select a location for the SERVER's CALLERS file and the WORKSTATION's. 4. Reflect the node numbers in the BATch file names, e.g. RCTTY1.BAT and RCTTY2.BAT, RBBS1.BAT and RBBS2.BAT. 5. Choose PCNET as the environment that you are running RBBS-PC under. Other Considerations-- VDISK or Extended memory, which is not-emulated memory, should not be used on the SERVER but can be used on the Workstation. The network configuration most likely to remain operating with very few problems is DOS 3.1, Orchid 3.0a PC NET software and CACHE.EXE version 2.2 and an Expanded/Extended memory combination using the new Lotus/Intel/Microsoft EMS memory boards. Two nodes can be efficiently set up using the SERVER in non-dedicated mode but the danger is that if the SERVER locks up, the whole system locks up. The sample PC Net system is set up in this fashion but it is an economical approach to a two node system which has been functioning quite well with minimal problems. Do not run software on the SERVER that is known to cause problems especially memory resident utilities. There is a potential for files being CROSS-LINKED in any read/write sharable environment. Frequent backups are to be very strongly recommended. Because of wide variety of hardware combinations and possible network permutations, the above is intended ONLY as general guidelines to be followed when installing RBBS-PC on your Orchid network. Rob Cecchino Sysop, Computer Connection (804) 481-1824 at 1200/2400 for assistance. RBBS-PC CPC17.3 Page 253 APPENDIX F -- RBBS-PC in an Alloy PC-SLAVE/16 Environment --------------------------------------------------------- The PC-Slave is an IBM compatible computer on an expansion card manufactured by Alloy Computer Products, Inc. of Framingham, MA 01701. Their telephone number is (617) 875-6100. Adding PC-Slaves converts the PC from a single CPU to a multiple CPU, all under the control of the main or host PC. Each slave can run RBBS-PC (or other programs). A. THE ADVANTAGES: Compared to other means for running multiple RBBS-PC's, the advantages of slaves are: 1. SPEED -- Each copy of RBBS has a dedicated computer and therefore runs very fast compared to multi-tasking products like Multi-Link, DesqView, or DoubleDOS. 2. SHARED FILES -- Each bulletin board can share files, including the users and messages. The PC Slave system can act like Orchid's PC-Net network, or a NetBIOS LAN for record locking. 3.EXPANDABILITY -- You can have up to 31 slaves. Adding an extra Slave is simple, and does not degrade system performance. The power supply and cooling capacity of a PC-2 or XT limit you to adding only 2 slaves. An AT can have up to four. You can buy PC compatibles that have more expansion slots. You can also get an expansion chassis designed for up to 12 Slaves. 4. COSTS -- It is far cheaper to expand using PC-Slave/16's than a network. The PC-Slave lists for $900 and can be purchased for significantly less. Other networks require not only a separate PC but also a "network" card of some sort which puts the costs of each port well above $2,000. 5. DEDICATED PC IS NOT REQUIRED -- Your PC can remain free for you to use while slaves run the bulletin boards (or run another copy of the bulletin board). You do not degrade performance on the slaves, except for contention for the hard disk and that can be mitigated by using disk caching. 6. EASY SNOOP. Using Alloy utilities GIMME and VIEW, you can view the session on any slave and attach your keyboard to it. You can also install a dumb monitor to any slave. B. THE DISADVANTAGES: The disadvantages of a slave system are: 1. COMPATIBILITY --Not all hard disks are compatible with the slaves. Hard disks known to be compatible include the Seagates, Priam 60 meg, Bernoulli, and Maxtor hard disks, as well as the Alloy line of hard disks. Hard disks definitely not compatible include all models of US Design. C. OVERVIEW OF SETTING UP A PC-SLAVE/16 RBBS-PC: Five easy steps on how to install RBBS-PC in a PC-Slave/16 environment (Note that the PC Slave system requires a special configuration for RBBS-PC): STEP 1 -- If you want to allow simultaneous callers, you will have to purchase multiple telephone lines. They can be made to roll so that only one number is called, and if busy, the call will roll over to the other lines. STEP2 -- Install the slaves. Remember to set switches on the slave boards RBBS-PC CPC17.3 Page 254 that number them consecutively. See the PC-Slave documentation for details. STEP 3 -- Install the software. The Alloy PC-Slave has to have special Alloy software called NTNX to coordinate the slaves and process requests for shared resources. See the NTNX documentation for details. STEP 4 -- Install a modem with no pin 22. Pin 22 used to be required with RBBS-PC in order to answer the phone. On the slaves, pin 22 CANNOT be connected, or else the slave will continuously reboot. However, newer slaves support pin 22. STEP 5 -- Configure RBBS-PC using CONFIG.EXE with the following parameters: (a) use COM2 (parameter 221) (b) Via parameter 29 tell RBBS-PC it is running on an IBM compatible rather than a PC, XT, or AT. (Lie and tell RBBS-PC you have a Compaq Plus.) (c) Use CONFIG parameter 161 to set the maximum number of bulletin boards to as many boards as you intend to install (rather than the number you are currently running. This makes expansion easier.). (d) PC-Net is the multi-user environment you will be running under and should indicate so via CONFIG parameter 162. (e) Set up the RBBS-PC files. An easy way to configure the multiple RBBS-PC's is to put each one in a separate subdirectory, e.g. "RBBS1" for the 1st node, "RBBS2" for the second, etc. Inside each subdirectory will be the callers file for that node and the DEF file (RBBS1PC.DEF, RBBS2PC.DEF, etc.). The DEF files can be the same. Make the default drive on each slave be the right subdirectory. Path over to where the RBBS-PC.EXE is stored. Invoke each RBBS-PC by using its node number, e.g. "RBBS-PC 1", "RBBS-PC 2", etc. You can set up an autoexec for each slave that brings up the boards automatically upon system boot. Please note that the NTNX software is very vulnerable to any RAM resident software. You should install the Slaves with no additional software present and carefully test any resident software you want to run with it. D. A DETAILED DESCRIPTION OF SETTING UP A PC-SLAVE 16 RBBS-PC: Hardware Limitations: 1. Two PC/Slave 16 cards per XT box or four in an AT maximum otherwise you'll be buying power supplies frequently. An expansion chassis for four cards (Alloy Plus4) or expansion chassis for up to twelve cards will be needed for bigger systems. Expansions boxes can be daisy-chained to up to thirty one Nodes or workstations, if needed. 2. PC/Slave 16 cards do not support PIN 22 for Ring Detect. If PIN 22 is connected, your slave will re-boot every time the phone rings! 3. No clock on the PC/Slave 16 card. The Slave gets the Time and date from the main system clock. Each time you update the host clock, all the slaves will update as well. 4. A terminal such as a Kimtron KT-7/PC or Alloy PCST is needed if you want to work on a slave the same as you would on the host computer (but not if RBBS-PC CPC17.3 Page 255 you just want to view activity on slaves occasionally). Other terminals will work but may not support all of the IBM extended graphics codes. For a multi-node RBBS-PC, one terminal can be used with an A-B-C-D switching box to 'dial in' to the node you wish to work with. 5. The Slaves' CPU [NEC V20 @ 8 mhz] shuts down when writing to the hard disk. This creates problems with timeout errors on uploads. Upload problems can be eliminated by using the write buffer option in NTNX 1.64 or higher (/B). The problem can also be alleviated by using a fast hard drive supported by Alloy. Also, the hard drive must be formatted with the most efficient interleave setting and driver. Hard drives that work without significant upload timeout errors have been formatted with either Golden Bow's Vfeature Deluxe or Priam's formatting software; this problem is especially noticeable on AT systems and not too much of a problem on small XT systems. Seagate, Bernoulli Box, Maxtors, and Priam Inner Space drives seem to work fine with the Alloy PC/Slave-16 cards. Software Limitations: 1. ATNX runs Orchid PC Net applications but NTNX is more versatile and will run applications for Novell's Advanced Netware, MS-Net, AND Orchid PC Net with proper file locking. NTNX has had less problems with file corruption and cross-linking than ATNX after polling current sysops using Alloy Slaves. 2. The slaves get the date/time from the host computer. Constant processing can cause the host clock to drift. A utility to periodically update your host computer clock is recommended. Also, WXMODEM does not work in upload mode on Slaves due to a timing problem in the initial handshake. Alloy's solution to this problem is a file called UPTIME.COM, which is run on the HOST, but I have had very poor results with it. The problem seems to be most identifiable on AT class machines. For the optimum system flexibility you may want to buy Alloy PC/Slave-16N cards which have the special PAL chip for NTNX/Novell compatibility and NTNX software. RBBS-PC, however, will run fine without the PAL chip even under NTNX. Some nice additional utilities for the Slaves, including special diagnostics, are found in the separate PC-Plus Advanced User's Kit and are worth having. A single Kimtron KT-7/PC terminal or other smart terminal may be obtained right away but is not necessary for the bulletin-board-only system as one can always sign on from remote for answering mail; pay special attention to the terminal-to-Slave cable as it is non-standard and you'll probably wind up making it yourself for less than $5 in parts -- one end is a male 9-pin D-shell and the other is 25-pin RS232 male connector. For a two to four node system, obtain a switch box to hook the terminal as COMMON and Slave consoles. The computer to house the Slaves, called the HOST, should be the quickest CPU speed that you can obtain. All PC Slaves/16 should be purchased with 1 megabyte of onboard RAM. Installation: 1. Format your hard drive with the DOS supported by the version of NTNX you purchase (currently DOS 3.3). 2. Divide the hard drive into multiple volumes of standard DOS size (less RBBS-PC CPC17.3 Page 256 than 32 megabytes). 3. Install NTNX and the Slaves according to the Alloy manuals. Choose the default settings for everything. Use 512K on the 1 megabyte PC/Slave for caching and the other 512 to run RBBS. Depending on how the board is configured, you may need to set switches so that 512 is used to run applications. Use 4K for the Host PC caching. Allocate 25 files per each Slave + 64 for the maximum number of open files. 4. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the HOST as follows especially if you do not plan to use the HOST as a Node for RBBS-PC: CONFIG.SYS device=NX.SYS - NTNX driver (must be first!!) device=hard_drv.sys - Your hard Disk driver FCBS = 32,32 - File Control Blocks increased buffers = 20 - DOS buffers files = 32 - Number of OPEN files on HOST device = ANSI.sys - Extended graphics driver AUTOEXEC.BAT NTNX - NTNX driver fm 3 - Level of File protection prompt $p$g - customized dos prompt path = ........ - set path to the NTNX files 5. Set up the CONFIG.SYS and AUTOEXEC.BAT files for the Slaves as follows: CONFIG.U0x under DOS 3.3 FCBS = 32,32 buffers = 10 files = 30 device = ansi.sys shell = C:\COMMAND.SLV C:\ /P /E:800 Of special note, the SHELL statement has been used to expand the environment space on the Slaves. This corrects a problem seen with random RBBS lockups or getting Out of Memory errors; external protocols and DOOR programs, given time, stop running due to memory problems if one doesn't use this SHELL statement. Under DOS 3.1, set /E:50 [= 50 paragraphs] and under DOS 3.2 or 3.3, set /E:800 [= 800 bytes]. AUTOEXEC.U0x fm 3 prompt $p$g path = .......Set the path to the NTNX files and to the 'home' directory for this node on the SHARED drives SET NODE=x Tell this slave what node to run. cd\RBBS0%NODE% Change to the RBBS-PC directory for this node RBBS.BAT Invoke RBBS-PC for this node The statement "SET NODE=x" allows you to write batch files that know what node you are dealing with. All slaves can access the same RBBS.BAT file, as long as you invoke RBBS-PC from within that file as: RBBS-PC %NODE% RBBS%NODE%PC.DEF Other node-specific commands should be done this way. 6. CONFIG parameters for the slaves, must be the following parameters: Parameter 29 (Type of computer): Compaq Plus. Parameter 224 (Number of rings to wait before answering): 0. Parameter 162 (Environment): Orchid PC Net. RBBS-PC CPC17.3 Page 257 Parameter 221 (Communications port): 2. Maximum number of users: at least as many slaves as you have, plus one if you plan to run a node on the host. You can specify more (up to 36) if you want to plan for expansion. 7. Set up RBBS-PC as follows: Create subdirectories \RBBS01, \RBBS02, \RBBS0x... on a shared drive. Create other subdirectories according to RBBS-PC documentation. On a cached drive, place all static RBBS-PC files such as MENUs, HELPs, PASSWRDS, TRASHCAN, external file transfer protocols. RBBS-PC.EXE and CONFIG.EXE go here as well. On the second SHARED drive, make a subdirectory \COMMON for MESSAGES, USERS, CONFENCE, and conference message/user files. If you plan to use DOORS, especially Bob Westcott's DOORWARE, create a subdirectory called \DOORS on the SHARED drive. Run CONFIG and create RBBSxPC.DEF files for all your nodes. Remember that you will run multi-user under PC Net. The modem serial port on the Slaves is COM2 and not COM1. Double-check file locations! Put your static text files in the same subdir as MESSAGES and USERS and make it the default subdirectory Copy RBBS1PC.DEF to RBBSxPC.DEF for each node that you hope to have then re-edit each .DEF file to customize Node numbers such as RCTTY1.BAT, etc. Copy the RBBSxPC.DEF file to the matching subdirectory. If you don't wish to edit the .DEF files, place RBBSxPC.DEF on one shared drive and place the dynamic RBBS-PC files on the other shared drive; be sure that you have at least logged into that other SHARED drive's subdirectory, using the AUTOEXEC.U0x before starting RBBS-PC or else RBBS-PC will not find those files. Temporary files used for transfer or Verbose ARC listing are created on the default subdirectory automatically. You must assign a different CALLERS file for each node located in the default directory. To use Sysop Function 7 (Remote Drop to DOS), RBBS-PC must find COMMAND.COM. PC-Slave/16's, however, use COMMAND.SLV as the command processor; copy COMMAND.SLV to COMMAND.COM, place it on a cached drive, and tell CONFIG where to find it. Be careful using this Sysop function with the Slaves as you will lock up the Node if you lose carrier; WATCHDOG is incompatible with the Slaves. Additional tips/hints: 1. Avoid using any memory resident utilities. They may interfere with Slave operation. 2. A program on the Advanced Utilities disk called SEE.COM allows callers on any Node to be viewed from the HOST. 3. Norton's Editor or WordPerfect Corporation's Programmers Editor from the WordPerfect Library is used for editing operations on the system, RBBS-PC CPC17.3 Page 258 especially for maintaining the fixed-length directory of the file management system. Not many other editors, except EDLIN, can be used reliably. 4. Easy to forget but don't as it will be a source of frustration -- plan out your file locations on paper before actually setting up the system. 5. Backup your system frequently! If you have any questions or problems, feel free to leave a message on Ken Goosens system (703) 978-6360. RBBS-PC CPC17.3 Page 259 APPENDIX G -- RBBS-PC and 10 NET Network ---------------------------------------- Starting with RBBS-PC CPC15-1A support for Fox Research's' 10 Net Network is being provided. Since this is the first release with this support we have very little that we can offer in tuning support for 10 NET. We selected to use the Semaphore locking mechanism that we have used in the other networks and therefore you must specify the following parameters on the Superstation in your 10 NET network. LOGINS=x 1 for every node on the system OPENFILE=xxx 10 for every node running RBBS-PC SHAREFIL=16 (This is the default you can add more if you want) LOCKS=x 3 SEMA=xxx 3 for every node running RBBS-PC You will also need to run NETSU and specify option 6 (DOS file sharing). Please note that these values should be in addition to any parameters you may have already specified for other User stations and other uses of your 10 NET network. And you can always make the values larger in attempting to improve performance. RBBS-PC CPC17.3 Page 260 APPENDIX H -- RBBS-PC and the Hearing-Impaired ---------------------------------------------- Telecommunications Devices for the Deaf (TDD's) use the Baudot character set (i.e. 5-bit) and utilize modems that transmit at 45 baud and do not generate a carrier signal. This is because such devices were initially adaptations of surplus Western Union TTY machines for telephone communications. The widespread use of Baudot devices by the hearing- impaired, the previous high cost of computers and modems, and the lack of software designed for electronic communications, has impeded the change to ASCII communications by the hearing-impaired community. Equipment manufacturers have also made it difficult for the deaf to change. When TDD's with ASCII code transmission capability began to be offered, the majority of manufacturers limited them to only 110 baud and put disclaimers in their manuals that said ASCII was available for use but that "computer language" was "less reliable" and hard to use. Their limiting of the TDD's output screen to 12 to 20 characters further compounded the problem because the screen would overwrite several times to display one line of text from a host system. The manufacturers' "solution" to this problem was to recommend printers for communication with such "host" systems as RBBS-PC. Some units now offer both 110 and 300 baud ASCII transmission in addition to the 45 baud Baudot. Unfortunately, these typically have only 20 character screens. In December of 1984, Ted Janossy of Rochester, Minnesota, sent me a three- page letter describing the above situation. Ted's letter motivated me to test and verify the "ring-back" feature of RBBS-PC in CPC12-4A. It had not been tested in earlier versions because I had assumed (presumptuously and insensitively) that "real SYSOP's don't use ring-back RBBS-PC's." Ted's letter awakened me to the potential of RBBS-PC to facilitate communications among the hearing-impaired. In the awakening I also had a chance to look down at my own feet of clay. RBBS-PC can be configured to answer calls only after a specified number of rings (i.e. 15). The telephone companies wire the homes of the hearing- impaired such that when the phone rings, the lights within the house flash on and off. With RBBS-PC a SYSOP can specify the number of rings RBBS-PC is to wait before answering the phone automatically. Setting this number high enough allows someone with a hearing impairment time enough to get to the PC running RBBS-PC. Pressing the PC's function key 5 (F5) causes RBBS-PC to answer the phone immediately. The caller would know that someone was at the keyboard because RBBS-PC answered the phone in less than the agreed- upon number of rings. The caller would log onto RBBS-PC normally and the person at the PC keyboard would be able to see who it was. If the person who was called wanted to "chat" with the caller, all they would have to do would be to press function key 10 (F10). If RBBS-PC didn't answer the telephone within the agreed-upon number of rings, the caller would know that whomever was being called couldn't come to the keyboard. The caller would then log on and leave a message. RBBS-PC CPC17.3 Page 261 APPENDIX I -- RBBS-PC and the IBM PCjr -------------------------------------- RBBS-PC adheres to the Hayes standards for autoanswer applications that are described in Section 9, "Writing Programs for the Smartmodem 1200," of the SMARTMODEM 1200 HARDWARE REFERENCE MANUAL. Under the section entitled "Additional Program Considerations" Hayes recommends that autoanswer applications (like RBBS-PC) "... force the modem to answer the call (ATA) rather than allowing the modem to automatically answer...." Beginning with CPC13-1A, RBBS-PC no longer REQUIRES the Ring Indicator signal from the modem (pin 22) in order to answer the phone (except if parameter 224 of CONFIG is non-zero). Here are some facts about the PCjr: 1.The PCjr's external modem interface does not have a Ring Indicator signal. 2.The PCjr requires that an external modem be opened as COM1 if no internal modem is installed. However, if no internal modem exists the PCjr requires that the COM2 RS-232 registers be used even though the port has been opened as COM1. Technically this is described as using the external RS-232 asynchronous adapter as logical channel 1 (i.e. COM1) but manipulating it as physical channel 2 (i.e. COM2). This occurs on a PCjr only when an internal modem is NOT present and the external RS-232 interface is. 3. The 128K PCjr only provides 90K of usable RAM (the rest is used by DOS, the monitor's buffers, etc.). Fortunately PCjr owners can get up to 512K of RAM with "add-on" equipment (from IBM and others) in order to have enough RAM for RBBS-PC to run in. 4.The standard PCjr supplied by IBM does not have a DMA and hence can't do communications I/O simultaneously while doing disk I/O. RBBS-PC beginning with version CPC13-1A will run an IBM PCjr providing that the PCjr 1. Has at least 320K of memory. 2.Disk I/O does not occur simultaneously with communications I/O (i.e. either you have a second disk drive with a DMA or you set BUFFERS=0). 3. One of the following three modem configurations are used: An internal PCjr modem with an external Hayes modem where the external Hayes modem is used for RBBS-PC. No internal PCjr modem with an external Hayes modem used for RBBS-PC. Only an internal PCjr modem and it is used for RBBS-PC. The following discusses each of these three modem configurations supported by RBBS-PC with the PCjr. Internal PCjr Modem with RBBS-PC Using External Hayes Modem ----------------------------------------------------------- This configuration means that the PCjr has both a COM1 (the internal PCjr modem) and a COM2 (the external Hayes modem). RBBS-PC is set up to use COM2. No changes are required to for RBBS-PC for this type of PCjr configuration. CONFIG parameter 224 should be set to 0. This will cause RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC will wait for carrier detect. This is the way that RBBS-PC overcomes the PCjr's lack of "ring-indicator" signal for the external communications port. RBBS-PC CPC17.3 Page 262 No Internal PCjr Modem With RBBS-PC Using External Hayes Modem -------------------------------------------------------------- This configuration means that the PCjr has only one RS-232 interface -- the external Hayes modem. This must be opened as COM1 but use COM2's registers to control the communications port (believe it or not that's the way IBM designed the PCjr). CONFIG parameter 221 should be used to indicate that COM1 is being used. Unfortunately the current BASIC compilers (both IBM's Version 2 and Microsoft's QuickBASIC) are incapable of handling a communication port as logical device 1 (i.e. COM1) but on physical channel 2 (i.e. the interrupts are for COM2). Should this ever be fixed by either IBM or Microsoft, CONFIG parameter 29 should be used to indicate that no internal PCjr modem is installed. This tells CONFIG to make sure that COM2 registers are used to manipulate the PCjr's external communications port. Until this is fixed by the respective vendors, the PCjr user will have to run a utility like COMSWAP that exchanges the pointers between COM1 and COM2 within DOS. In either case, CONFIG parameter 224 should be set to 0. This will cause RBBS-PC to set the external Hayes modem into "auto-answer" mode and RBBS-PC will wait for carrier detect. This is the way that RBBS-PC overcomes the PCjr's lack of "ring-indicator" signal for the external communications port. Again no changes to RBBS-PC are required for this type of PCjr configuration. Only An Internal PCjr Modem for RBBS and NO External Hayes Modem ---------------------------------------------------------------- For this type of PCjr configuration, you can take the CONFIG default settings for the communications port (COM1) and specify that you are running on a PCjr (parameter 29). However, make sure that CONFIG parameter 228 specifies that the modem is to be opened at 300 baud. Of course, RBBS- PC will be only able to answer the telephone at 300 baud and send and receive data from users who log on with their communications parameters set at N/8/1 (i.e. no parity, eight data bits, and one stop bit) since RBBS-PC is limited by the PCjr's own modem's limitations. RBBS-PC already has the modem commands for the PCjr's very strange internal modem in the logic to answer the phone so no changes to the .DEF file are required. RBBS-PC CPC17.3 Page 263 APPENDIX J -- RBBS-PC Subscription Service ------------------------------------------ It seems that many people absolutely must be on the bleeding edge of RBBS-PC and demand each new version as soon as possible after it is released. For them you can order in advance the next release of RBBS-PC. It will be mailed anywhere by air mail - overnight in the United States, ordinary air mail elsewhere. The charge for this subscription upgrade is $25. Hopefully, this service will only be used by a very, VERY few! Most releases have a few fixes that get published within the first week or two that they are out. Because of this everyone is advised to check back for fixes after each release goes out. To obtain this service for the NEXT release (it does NOT apply to the current or previous releases) fill out the following form and send it along with your check or money order in U.S. funds (no purchase orders are accepted and your canceled check is your only invoice). +------------------------------------------------------------------+ | To: Capital PC Software Exchange RBBS-PC Subscription Service to| | P.O. Box 6128 the NEXT release of RBBS-PC (if| | Silver Spring, Maryland any - and none are implied or | | 20906 promised by this offer) | |------------------------------------------------------------------| |Date Requested: Date Received: | |------------------------------------------------------------------| |To (Recipient's Name): | |------------------------------------------------------------------| |Recipient's Phone Number (required): ( ) - | |------------------------------------------------------------------| |Exact Street Address (no P.O. Box or P.O. Zip Code accepted) | | | | | |------------------------------------------------------------------| | City | State or Country | | | | |------------------------------------------------------------------| | Signature (required) | ZIP Code for Street Address | | | | +------------------------------------------------------------------+ Note: this is not a promise that there will be any new releases. RBBS-PC CPC17.3 Page 264 APPENDIX K -- RBBS-PC Worldwide Listing Service ----------------------------------------------- Frequent inquires are made about a "master" list of RBBS-PC's. In order to help SYSOP's (and potential SYSOP's) everywhere find configurations that most closely match their own, and to help users find more RBBS-PC systems, we will attempt to maintain an "ACCURATE" listing of all publicly available RBBS-PC systems. The success of this endeavor depends on you. If you would like a chance to stand up and be recognized, please complete the BBS info file LG-9999.DEF supplied with this release of RBBS-PC and send it to: RBBS-PC WORLDWIDE REGISTRY P.O. Box 31024 Palm Beach Gardens, FL 33420-1024 U.S.A. You can also call Technology Consultants' RBBS-PC and either upload a copy of the form, or use the online questionnaire. An online database of all respondants will be available on Technology Consultants' RBBS-PC, (407) 627-6969 or 627-6862. If you need a good reason to complete and return the information, read on! As RBBS-PC continues to evolve, we must make decisions that will affect you. If we know who you are, and what your environment is like, we are less likely to introduce a new version of RBBS-PC that will not run in your environment! THE BBS IDENTIFICATION STANDARD ------------------------------- To help BBS list editors, and other users searching for your BBS, we have started what we hope will be an industry standard. Please implement it on your BBS. Here's how: 1) Complete the LG-9999.DEF file and place it with your other LGn.DEF files. 2) Create a user with first name "BBS", Last name "VERIFY", password "CALL". 3) Set this user's SECURITY to -9999. Now, any time a BBS list editor calls for a quick check, he'll use the name BBS VERIFY and a password of CALL. Your BBS will quickly display the information he needs, and then hang up. Any user who is curious about your BBS can do the same. If ALL BBS systems implement this, keeping track of the fast moving BBS community will be much easier. Please, do what you can to convince other SysOps to implement this simple procedure. RBBS-PC CPC17.3 Page 265 APPENDIX L -- The Ark-Paradyne Modem RBBS-PC Switch Settings ------------------------------------------------------------ The ARK Modem is somewhat Hayes compatible, therefore some changes must be made to use this modem. Because of major improvements in RBBS-PC, the modem can now be used in both of its modes, Normal and Hayes. To use the HAYES (tm) mode follow this procedure: A.) Using CONFIG.EXE supplied with RBBS-PC, select and change the following parameters: Parameter 224 Number of rings to wait before answering -------- 1 Do you want ringback? (YES/NO) ----------------- NO Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO 1. Reset the modem ------ : ATZ or ATV0Z 2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=0 (Note the use of "Q0" to initialize the modem) 3,4,5 Use the defaults supplied Parameter 227 Issue modem commands between rings ------------ YES Parameter 228 Baud rate to initially open modem at --------- 2400 Parameter 237 Leave modem at initial baud rate --------------- NO Parameter 244 Modem flow control uses Clear-to-Send (CTS) ---- NO Parameter 245 Modem flow control uses XON/XOFF --------------- NO For the ARK 24K (not 24K PLUS) use the following switch & jumper settings: Switch 1 UUUDDUUD (where U = Up = On and D = Down = Off) Switch 2 UDDDDUDD Switch 3 DUUDUUUU MODEM DTE/CLOCK FLOW BUSY DTR JUMPERS E8-E9 E15-E16 E4-E7 E11-E14 For the ARK 24K PLUS use the following: Switch 1 UUUDDUUD last down = Hayes mode Switch 2 UDDDDUDD first up = auto answer off Switch 3 DUUDUDDD last three down = "auto baud" Modem Jumpers - Use the factory defaults on all B.) You can also use the ARK NORMAL mode with a fixed terminal rate. The modem talks to RBBS at 2400 and talks to your user at 300, 1200, 2400. One problem noted was that upon return from dropping to DOS, the baud rate reverted back to 2400. If you were remote and using a 1200 baud modem, things get very messy. It has been noted with some external protocols that a similar problem exists. I don't recommend this setting unless you are willing to take some risks. You must also use flow control. Make the settings as follows: Parameter 224 Number of rings to wait before answering -------- 1 Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO 1. Reset the modem ------ : ATV0Z 2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=0 3,4,5 Use the defaults supplied Parameter 227 Issue commands between rings ------------------ YES Parameter 228 Baud rate to initially open modem at --------- 2400 Parameter 237 Leave modem at initial baud rate -------------- YES Parameter 244 Modem flow control uses Clear-to-Send (CTS) --- YES Parameter 245 Modem flow control uses XON/XOFF -------------- YES RBBS-PC CPC17.3 Page 266 The following is recommended for the ARK 24K Modem: Switch 1 UUUDDUUU (NOTE 8th position) +++ Switch 2 UDDDDUDD Switch 3 DUUDUUUU MODEM DTE/CLOCK FLOW BUSY DTR JUMPERS E9-E10 E15-E16 E4-E7 E11-E14 The following is recommended for the ARK 24K Plus Modem: Switch 1 UUUDDUUU Switch 2 UDDDDUDD Switch 3 DUUDUUUU C.) You can also use the Hayes mode with rings set to zero but you can't use Doors or Sysop drop to DOS. (This mode has proven to be very reliable) Parameter 224 Number of rings to wait before answering -------- 0 Parameter 225 Use the RBBS-PC default Hayes commands?--------- NO 1. Reset the modem ------ : ATZ 2. Initialize the modem - : ATM0Q0S2=255S10=30E0S0=1 3,4,5 Use the defaults supplied Parameter 227 Issue commands between rings ------------------ YES Parameter 228 Baud rate to initially open modem at --------- 2400 Parameter 237 Leave modem at initial baud rate -------------- NO Parameter 244 Modem flow control uses Clear-to-Send (CTS) ---- NO Parameter 245 Modem flow control uses XON/XOFF --------------- NO The following is recommended for the ARK 24K Modem: Switch 1 UUUDDUUD (note 8th position) Switch 2 DDDDDUDD (note 1st position) Switch 3 DUUDUUUU MODEM DTE/CLOCK FLOW BUSY DTR JUMPERS E8-E9 E15-E16 E4-E7 E11-E14 The following is recommended for the ARK 24K Plus Modem: Switch 1 UUUDDUUD Switch 2 UDDDDUDD Switch 3 DUUDUDDD Technical comments on the Ark Modems for your interest. 1. Ark Modems can't accept any commands if the "AA" (auto answer) light is on and the phone is ringing until the number of rings equals the number set in the S0 register. RBBS-PC expects to issue a "modem answer command" when it detects a ring and is ready. If the Ark modem can't accept this command, it won't answer the phone. You therefore cannot use the ring-back system or answer on a ring greater than 1. 2. Another interesting difference is that when the modem is in the "quiet mode" (Q1) NO results will be sent to the computer. If we inquire as to the number of rings received, it responds with absolutely nothing. 3. In the Ark Normal mode, if you enter a reset command ATZ or Z, it requests a confirmation of "Confirm (Y/N) >" and you must enter a Y or else it does nothing. We can get around this with a ATV0Z which tricks this into an un-conditional reset. 4. If you attempt to operate in the ARK NORMAL mode at 2400 baud and set RBBS-PC CPC17.3 Page 267 the DTE/CLOCK jumper to E8-E9, the modem will "downshift" to a baud rate to match the caller, which is normal. Assuming you downshift to 300 baud you must reset it with a ATZ at 300 Baud. RBBS resets it at the initial rate of 2400 baud and therefore the modem is "hung". Obviously this is not recommended. The following modems were tested: 24K - ROM versions 2.21, 2.23, 2.31 24K PLUS - ROM ver 3.63. If you have questions on this modem contact: Dave Hacquebord, Sunshine Bulletin board, Tampa, Fl. Voice: 1-813-884-4267 Data: 1-813-887-3984 RBBS-PC CPC17.3 Page 268 APPENDIX M -- RBBS-PC And the Anchor Signalman Express (MK12) ------------------------------------------------------------- The following are the switch and jumper settings for the Modem. Switch 1 = Off Switch 2 = Off Switch 3 = On Switch 4 = On Switch 5 = On Switch 6 = On Switch 7 = On Switch 8 = On RBBS-PC CPC17.3 Page 269 APPENDIX N -- The Everex 2400 modem RBBS-PC switch settings ----------------------------------------------------------- The Everex Evercom 24 is an internal 2400 BAUD modem. It has 4 switches on the mounting bracket. If you are using COM1 then all switches should be in the OFF position. If you are using COM2 see the Installation Guide for the correct switch settings. The Evercom does not have non-volatile memory like the Hayes 2400 and the ATZ command will reset the modem to factory defaults. It is therefore not necessary to use CONFIG to set the Hayes 2400 defaults. Because of this major difference you must use CONFIG parameter 225 to change the standard modem defaults. Select parameters 2 and 5 and enter the command just as it is but with the addition of &D2. This will instruct RBBS-PC to add &D2 to the standard modem initialization string each time the system recycles. Please note that although the Evercom 24 manual indicates that &D2 is the default that this is a misprint in their manual and &D0 is the real default for the &D command. Parameter 7 can be ignored since they this is for battery backed up modems only. NOTE: Make sure that &D2 is inserted immediately following the "AT" when modifying parameters 2 and 5 of parameter 225! A special thanks goes to Carl Margolis (Everex) for his help in identifying these restrictions so that Evercom 24 users can now reliably use RBBS-PC. Do not select parameter 225 if you are using an Everex 1200 BAUD modem. RBBS-PC CPC17.3 Page 270 APPENDIX O -- Prometheus 2400G modem RBBS-PC switch settings ---------------------------------------------------------------- Underneath the 2400G is a bank of 10 switches that set certain operating characteristics of the ProModem 2400G. Only 3 (1,2 & 10) of these switches are currently implemented. The others are reserved for future expansion. All three of these switches must be in the off position for the 2400G to function properly with RBBS-PC. RBBS-PC CPC17.3 Page 271 APPENDIX P -- US Robotics Modems' RBBS-PC Switch Settings --------------------------------------------------------- Part 1: Courier 2400 and HST Both the US Robotics COURIER 2400 and COURIER HST modem switch settings should be as follows: 1 2 3 4 5 6 7 8 9 10 gang switch U U U D D U U D D D UUU (Where U = Up = Off and D = Down = On) The Courier 2400 is a high quality, trouble free modem that is highly recommended and which works well with all the RBBS-PC defaults. The USR COURIER HST modem switch setting should be as follows: 1 2 3 4 5 6 7 8 9 10 gang switch U U U D D U U D D U UUU (Where U = Up = Off and D = Down = On) RBBS-PC supports both modes of the USR HST Modems. In CONFIG, specify the number of seconds between modem commands to be 1. MODE 1: ------- In the first mode of operation, CONFIG parameter 228 should be set to the highest speed you intend to support. When the HST modem detects a carrier, it sends (at the baud rate set in parameter 228) an ASCII string to RBBS-PC which contains the new BAUD rate. The modem will change it's baud rate to match that of the caller's and RBBS-PC will correctly adjust to the modem's new baud rate. The following CONFIG parameters should be set: Parameter 222 -- set to 3 to allow the modem enough time to initialize Parameter 223 -- set to 2 Parameter 227 -- set to NO Parameter 228 -- set to 9600 Parameter 237 -- set to NO Parameter 244 -- set to YES Parameter 245 -- set to NO You should also reply "NO" to parameter 225, CONFIG will show you a menu of 8 different modem commands. The ONLY command that needs to be changed is number 7, "Initialize the modem firmware". It should be: AT&A1&B0&H1&I0&M4&N0&R2&S1&Y3 The meaning of this HST-specific initialization string is as follows: &A1 = Display/ARQ result codes &B0 = DTE/DCE rate follows connection rate &H1 = Hardware (Clear To Send, Pin 5) flow control &I0 = Flow control disabled &M4 = Normal if ARQ connection cannot be made &N0 = Negotiate highest possible link rate with remote modem &R2 = Received data output to terminal on Request to Send high (Pin 4) NOTE: If your HST 9600 modem responds 961 or greater to the ATI command, substitute &R1 for &R2. &S1 = Modem controls Data Set Ready &Y3 = Nondestructive, unexpedited break signal The highest effective data transmission rate in this mode is 9600 baud. RBBS-PC CPC17.3 Page 272 MODE 2: ------- In this second mode the USR Modem supports the MNP data compression technique which effectively transmits data over the phone at rates in excess of 17K baud. Setting up your HST to support both the standard 300, 1200, 2400, and the higher 9600 and 17K baud rates requires that the HST modem speed be "fixed" at 19.2K baud. The PC running RBBS-PC will communicate with the HST modem attached to it at a fixed rate of 19.2KB. The actual data link speed will default to the highest rate that the caller's modem will support. Parameter 222 -- set to 3 to allow the modem enough time to initialize Parameter 223 -- set to 2 Parameter 227 -- set to NO Parameter 228 -- set to 19200 Parameter 237 -- set to YES Parameter 244 -- set to YES Parameter 245 -- set to NO You should also reply "NO" to parameter 225, CONFIG will show you a menu of 8 different modem commands. The ONLY command that needs to be changed is number 7, "Initialize the modem firmware". It should be: AT&A1&B1&H1&I0&M4&N0&R2&S1&Y3 The meaning of this HST-specific initialization string is as follows: &A1 = Display/ARQ result codes &B1 = DTE/DCE rate is fixed at allowable rate &H1 = Hardware (Clear To Send, Pin 5) flow control &I0 = Flow control disabled &M4 = Normal if ARQ connection cannot be made &N0 = Negotiate highest possible link rate with remote modem &R2 = Received data output to terminal on Request to Send high (Pin 4) NOTE: If your HST 9600 modem responds 961 or greater to the ATI command, substitute &R1 for &R2. &S1 = Modem controls Data Set Ready &Y3 = Nondestructive, unexpedited break signal This will enable the COURIER HST to use the built-in MNP protocol at the highest possible baud rate that can be negotiated with the calling modem -- providing the calling modem is also a COURIER HST modem. The highest effective data transmission rate in this mode is 17200 baud. After replying NO to CONFIG parameter 225 and changing the initialization modem command as described above for either MODE 1 or MODE 2 for the COURIER HST, CONFIG parameter 231 should be selected in order to initialize the COURIER HST. This places the setting in the HST's non-volatile random access memory (NVRAM) and need only be repeated if the NVRAM is changed (i.e. you use the modem with applications other than RBBS-PC that change the NVRAM). For the COURIER 2400, set CONFIG parameter 228 to 2400. For the COURIER HST, set parameter 228 as specified above for either MODE 1 or MODE 2. Part 2: HST Dual Standard V.32 (By Gary Huff, SYSOP, Capitol City BBS, (217) 529-6452) RBBS-PC CPC17.3 Page 273 The US Robotics Courier HST 14.4 modem has revolutionized computerized tele-communications. This modem is capable of screaming along at 19,200 baud over ordinary voice telephone lines, and doing so extremely reliably. In a properly installed RBBS-PC, and using a properly installed communications program (Telix, QModem, etc.), it is a simple matter to realize data transfer rates in the range of 1550-1650 CPS. This works out to something like a true baud rate of about 15,500-16,500 baud! You can move some very big files, very fast with this modem on both ends! Many RBBS SysOps have apparently never mastered how to make this modem work at optimum speed in their installations. I check into BBS's all over the country running the HST 14.4 where transfer rates are in the 1000-1050 CPS range. This simply indicates that the SysOp has not taken the time to properly install his/her modem and to set up RBBS correctly. This paper is intended to assist the SysOp in that task. Incidentally, I run RBBS 17-1D. These instructions should work just fine with any later of RBBS. But they do NOT work as-is with older versions of RBBS such as 15-1x, which is a shame because there are some nice old 15.1x boards still in operation and 15.1x is lovely software to operate. If you are running RBBS 15.1x, you might be able to get some ideas from this paper but I can't guarantee you're going to get your board up to speed. But if you do, I'd sure like to hear from you to know how you set up 15.1 to work right... I really loved version 15.1C of RBBS! I regard it as the '55 Chevy of BBS's - a real classic! To install the modem, just put it in line where your old modem went. On the back of the HST, you will find one "fat" switch (a wide one), and 8 smaller DIP switches. Configure the "fat" switch (the one just to the left of the DIP switches to be UP. Configure the DIP switches to have switches 4,5,8 and 9 DOWN; all the others should be UP. Next, run RBBS's CONFIG program. You will have to re-set a couple of parameters. Here's how my CONFIG setup looks: 222 - 2 223 - 1 224 - 1 225 - (discussed below) 226 - NO 227 - NO 228 - 19200 230 - NO 232 - 1 237 - YES 244 - YES 245 - NO Parameter 225 is a special situation. First, I'll tell you how each choice in parameter 225 looks on my screen, and then I'll tell you how to make yours match it. Parameter 225: 1: ATZ 2: ATB1M0Q1X7S2=255S10=30S0=254 3: ATS1? RBBS-PC CPC17.3 Page 274 4: ATQ)X1V1A 5: ATQ1E1H1M0 6: AT&F 7: AT&A1&B1&H1&I0&K0&M4&N0&R2&S1&Y3 8: &W Here's the trick part: if you enter the code in line 7, you will discover that CONFIG for versions earlier than 17.2 does NOT save this line out correctly and store the value you have just entered. In fact, in studying the CONFIG.BAS code, I cannot find where this code you have just entered is ever sent to the modem! I may be missing something, but the best I can tell is, CONFIG sends the Hayes default string, no matter what you enter into parameter 7 ! Therefore, the only way you can get this code to go to the modem is if you enter it into the BASIC hard code of CONFIG.BAS. The line you will need to alter is line 15790 to read like this: 15790 FIRMWARE.INITIALIZE.COMMAND$ = "AT&A1&B1&H1&I0&K0&M4&N0&R2&S1&Y3" ' (rest of code is unaltered after this) Next, you will have to recompile CONFIG.EXE. If you have Quick Basic 3.0 use it by following the compilation instructions in the RBBS manual. If you do NOT have a copy of Quick Basic (or you do not have the technical expertise to recompile the altered code yourself), you can call my BBS and download the revised program. I make it available in the SYSOP's sub-board (open to any user, whether SYSOP or not) under the file name CNFG-HST.LZH. This file contains ONLY the revised CONFIG.EXE file and none of the other RBBS code. Naturally, you will want to save your old CONFIG.EXE file onto a disk somewhere, just in case you ever want to go back to running your old Hayes (or compatible) modem. The revised CNFG-HST.LZH program is compatible only with a US Robotics HST 14.4 modem. It will probably work OK with the older HST 9600 and HST Dual Standard modems as well. CONFIG with RBBS 17.2 and up does properly save and use the firmware initialization string. Once you have your CONFIG setup looking like mine, initialize your modem via parameter 241. This writes the code into the non-volatile NRAM memory of the HST so you don't lose your setup when you power down. You are almost ready to fire up RBBS at 19,200 baud! But wait... a couple of changes are necessary before you do to realize the fruits of your work. First, not all protocols work correctly at these high speeds. Some protocols run very slowly, and some will run not at all. For example, Kermit will only give you about 450-500 CPS. Some boards running Kermit cannot even make Kermit start a transfer, but will hang! My advise: don't run Kermit. Similar problems of slow, inefficient transfer rates are suffered by JModem and Lynx. While these protocols work fine at 2400 baud (or slower), they really dog along at 19,200. You can leave them as choices so that your 2400 baud callers can still use them, but you might want to post a bulletin to your HST 14.4 callers to not select JModem or Lynx if they want high speed transfers. Windowed XModem (WXmodem) is a real pain... on most installations, it will also not function efficiently (or at all). I have removed WXmodem from my choice of protocols. Out of over 600 users, I only had one who was using it regularly, and he was happy to switch to something more efficient. Next, QMXFER protocols do not yield RBBS-PC CPC17.3 Page 275 high efficiencies and are mostly duplicates of protocols available either internally or with DSZ. On my board, although I found QMXFER YModem to be the very fastest protocol at 2400 baud, I have reluctantly removed all QMXFER protocols. That leaves RBBS internal protocols and DSZ. DSZ protocols are outstanding examples of what all transfer protocols should be capable of doing. The two fastest protocols at 19,200 are (in order) YModem-G and ZModem. YModem-G is capable of giving you transfers on the order of 1625-1650 CPS, but only on a good, clean phone line. ZModem is only slightly slower (1550-1600 CPS), but is unmatched for its ability to "slam" through noisy phone lines. Personally, I figure I never can predict when a long distance phone line may become noisy in the middle of a transfer, so I use ZModem about 99% of the time. The installation of these DSZ protocols must be "tweaked" for maximum speed. That means you should set up your PROTO.DEF file for optimum operation with DSZ. Also, several DSZ protocols (YModem-G and Overthruster YModem) will only work with a "registered" version of DSZ. If you have not registered DSZ, please do so and run the "registered" version on your board to get the fastest speeds possible. If you do not know how to "tweak" your PROTO.DEF file for maximum speed, you can find my PROTO.DEF file that I run under the filename CC-PROTO.LZH. It includes all the internal RBBS protocols, DSZ XModem, DSZ XModem CRC, DSZ YModem, DSZ ZModem, DSZ YModem-G, Lynx and JModem. Again, I encourage you to encourage your HST users to use ONLY ZModem or YModem-G for maximum speed. The HST 14.4 SysOp must understand that, as with all new technology, some changes in the "old way" of doing things is inevitable. Certain DOOR programs, for example, simply will not work correctly at 19,200 baud. Most of the troublesome DOORS are older versions, written when 2400 baud was considered the fastest a computer could reliably run. Most DOORS written within the past couple of years work just fine at 19,200. However, be sure to run tests with all your DOORS after you get your new modem installed to make sure everything still looks right on the other end. (Don't trust how the DOOR looks on your screen... have a friend call into your board and test each and every DOOR to make sure it is still working right.) Most of the DOOR programs written for PC Board 14.x will run great on RBBS at 19,200, provided they are run through B.H. Forbes' excellent DOR-PCB program. A "trial" version of this program is available on many BBS's (mine included), but you really need to register the program with the author to get all the features activated. For example, the "demo" version only allows a maximum of 10 minutes in a door. The registered version has no such restriction, is very simple to set up (provided you first READ THE INSTRUCTIONS carefully), and opens up all the PCB doors for use on RBBS. Most DOORWAY programs will also work just fine at 19,200. (I run DOORWAY 2.04, the registered version, and can vouch for that version only. I don't know about earlier or unregistered versions.) The only DOORS I had problems with were some of the "Fast Fingers" programs such as POKER, CRAZY8 and BLAKJACK. However, I was running versions that were several years old, and there are possibly newer versions of these programs that will work at 19,200. Some of the better DOORS for 19,200 include MCASINO (Mycroft Casino), MURDER MOTEL, MOTU, and BBSQBASE (formerly USBBS). Also (thankfully), the RBBS-PC CPC17.3 Page 276 SysOps's best friend, PCBVerify works with no problems at all speeds up to 19,200. Some SysOps swear by the 8250 UART chip on their I/O boards, and some swear at them. There are some SysOps who say that the 16550AN UART chip should be installed in place of the 8250 chip to get maximum speed. I have tried both chips, and did get a few CPS faster speed. However, I also developed some "weird" problems with my COM1 port suddenly "disappearing" on me. I am not technically knowledgeable enough about the hardware to be able to tell you why this happened to me, but the bottom line is that I found the 8250 to be 100% reliable and only a few CPS slower. Therefore, I left my 8250 chip in line and shelved the 16550AN. Your experience may very well be different than mine, so you might want to experiment with this chip at 19,200. JDR Microdevices carries them (see Computer Shopper for their ad). Their phone number is: 800-538-5000. Other dealers may have them as well. Oh, by the way, just in case you want to know what hardware I am running to judge whether your installation will match what I am doing, I want you to know that I am not running a fancy 386 machine to get these performance ratings. I am running an older (1985) PC-XT Turbo clone with a NEC V-20 CPU chip at 8 MHz. My BIOS is a Mitsuba Erso/DTK 2.38 (which was not the original BIOS chip that came with this machine. I run a Perstore controller card with two Seagate 4096 hard drives. I also have a permanently installed Colorado Memory Systems Jumbo DC-2000 tape backup unit, running as an external unit with CMS's controller card. All of this conglomeration and mixture of scrap iron works just fine together, so if you hear rumors that this or that piece of hardware won't work at 19,200, call my board and see that it does! Good luck. If you have any questions not covered in this paper, I probably won't be able to answer them, but leave a comment or message on my board and I'll try to help you if I can. (I probably can't, but I'll try!) Open your HST 14.4 at 19,200 with your comm program (Telix works nicely, thank you) and call to see what is possible. Note: RBBS-PC versions 17.3 supports 38,400 baud using the Fossil driver, if you really want to try pushing the dual standard to its limits. RBBS-PC CPC17.3 Page 277 APPENDIX Q -- RBBS-PC and the FASTCOMM 2496 Turbo Modem ------------------------------------------------------- The FASTCOMM 2496 9600 and 19200 baud modems work with RBBS-PC without modifications to RBBS-PC. However some unusual quirks were noted with the FASTCOMM hardware. The modems would NOT follow terminal baud rate in the command mode if the transition was from 300 to 9600 (or 19,200) baud. Therefore, if RBBS-PC were configured to initially operate at 9600 baud, it would not properly reset after a 300 baud call. It would, however, follow all other changes within the range of RBBS-PC. If it was configured to initially answer at both 2400 and 4800 baud and it worked equally well with calls at 300, 1200, 2400, 4800, 9600 and 19200 baud for both cases. Therefore set CONFIG parameter 208 to 2400 baud! It is recommended that CONFIG parameter 224 be set to answer on one ring! Specific instructions for modem set up are as follows: 1. Using the BASIC program SETFC.BAS below, set the default modem settings. This can also be done manually from a communications program. The speed that is used to establish the default modem settings is the speed to which the modem defaults on reset and power on. It is best to do this setup at the same speed that RBBS-PC uses as its default speed, namely 2400 baud. In any case do not do it at 9600 baud. 2. Tell RBBS-PC to open the modem at 2400 baud by setting CONFIG parameter 208 to 2400 baud. 3. Use CONFIG parameter 225 to change the modem reset command from "ATZ" to "AAATZ". This string of A's resets the modem to the terminal baud rate so it can respond to the other commands. If you want to experiment, watch the modem respond to you when you change baud rates in your favorite communications program. This modem function is referred to as "autobaud". You will probably not see the first "A" echo and sometimes not the second. You should always see the third "A". Others have advised that their modems would "autobaud" from 300 to 9600 baud. Mine would not. 4. Use CONFIG parameter 225 to change the modem answer string to include X2 instead of X1 (the CONFIG default). Stan Staten has extensive experience with RBBS-PC and the FASTCOMM 2496 modems. If you have any questions regarding their use with RBBS-PC, give Stan's RBBS-PC system a call at (301) 869-7650. On the next page is STAN's SETFC.BAS program's BASIC source code to set the FASTCOMM modem. It can be run under the BASIC interperter or can be compiled using QuickBASIC from Microsoft. SETFC.EXE and SETFC2.EXE (for COM2:) can be downloaded from Stan's BBS. RBBS-PC CPC17.3 Page 278 10 'title: 'SETFC.BAS, Copyright 1986 by H. Stanley Staten 20 'SYSOP 3 WINKs BBS, 301-670-9621 30 ' 40 DEFINT A-Z 50 CLEAR 60 ' 70 ' ******************************************************************** 80 ' * ROUTINE TO INITIALIZE THE FASTCOMM 2496 MODEM'S FIRMWARE * 90 ' ******************************************************************** 100 ' 110 COM.PORT$ = "COM1" 'Change to "COM2:" for COM2: use 120 PRINT "Setting FASTCOMM 2496 firmware for RBBS-PC on " + COM.PORT$ 130 ' 140 ' ******************************************************************** 150 ' * * 160 ' * INITIALIZE THE FASTCOMM 2496 VOLATILE MEMORY. SET as follows * 170 ' * * 180 ' * AT#F = Set to factory defaults * 190 ' * AT#LCN = Set carrier detect to normal * 200 ' * AT#LDN = Set DTR to normal * 210 ' * AT#LX2 = Set for XON/XOFF flow control * 220 ' * ATS7=30 = Set wait for answer tone to 30 seconds * 230 ' * ATM0 = Turn speaker off * 240 ' * ATV1 = Issue long form of results codes * 250 ' * ATX2 = Full result messages * 260 ' * ATS57=1 = Hang up and reset automatically executed * 270 ' * ATE0 = Do not echo modem commands back to the PC * 280 ' * ATS10=10 = To cause to reset on loss of carrier faster * 290 ' * ATS58=3 = Force a 19200 Baud call to 9600 Baud locally* 300 ' * ATS22=46 = Suggested by the vendor * 310 ' * ATS0=0 = Don't answer until told to. * 320 ' * AT#W = Write settings to non volatile memory * 330 ' * * 340 ' ******************************************************************** 350 ' 360 OPEN COM.PORT$ + ":2400,N,8,1,RS,CD,DS" AS #3 370 PRINT #3,"AAAAAAAT" 380 PRINT #3,"AT#F" 390 PRINT #3,"AT#LCN" 400 PRINT #3,"AT#LDN" 410 PRINT #3,"AT#LX2" 420 PRINT #3,"ATS7=30" 430 PRINT #3,"ATM0" 440 PRINT #3,"ATV1" 450 PRINT #3,"ATX2" 460 PRINT #3,"ATS57=1" 470 PRINT #3,"ATE0" RBBS-PC CPC17.3 Page 279 480 PRINT #3,"ATS10=10" 490 PRINT #3,"ATS58=3" 500 PRINT #3,"ATS22=46" 510 PRINT #3,"ATS0=0" 520 PRINT #3,"AT#W" 530 SYSTEM RBBS-PC CPC17.3 Page 280 APPENDIX R -- RBBS-PC and the ZOOM Modem HC2400 ----------------------------------------------- In order to use the "ZOOM HC2400" modem with RBBS-PC parameter 225 should be changed as shown below. Only #2 and #5 need to be changed. Changes in #2. Add '&D2' just after 'AT'. Change 'S2=255' to 'S2=43'. Change in #5. Add "&D2' just after 'AT'. 1. Reset the modem : ATZ 2. Initialize the modem : AT&D2M0Q1S2=43S10=30E0Q0X1S0=0 Note: End item 2 with: S0=1Q0X1 if answer on 0 rings S0=254 if answer on >0 rings (no ring-back) S0=255 if answer on >0 rings (with ring-back) 3. Count the number of rings : ATS1? 4. Answer the phone : ATQ0X1V1A 5. Take the phone off the hook : AT&D2Q1E1H1M0 6. Clear the modem's firmware : AT&F 7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5 Note: End item 7 with: Q1 if item 2 ends with S0=255 8. Write to modem's firmware : &W For further information contact: Jeff L. Watts STATESVILLERBBS-PC Data # (704) 873-8482 RBBS-PC CPC17.3 Page 281 APPENDIX S -- RBBS-PC And The AT's RS-232 Cable ----------------------------------------------- The RS-232 serial connector is different for the AT than the PC or XT. The AT uses a connector called a DB-9, which is a 9 pin connector. An alternative to buying the AT serial cable from IBM, ($65-$80), is to make your own. A ten-wire cable can be purchased from any local computer store for about $.80 per foot, and the DB-9 and RS-232 connectors with hoods can be purchased from Radio Shack. The total cost should be about $12.00. A modem hooked up to the AT will work fine with the 9 pins connected in all terminal functions, except for auto-answer applications such as RBBS-PC. RBBS-PC requires pin 1 from the modem to be hooked up to the chassis ground on the AT or it can't answer the phone. There are two ways to hook up the ground wire on the computer end. The first way is to use a metal hood to cover the DB-9 connector. Wrap a bare wire that is attached to pin 1 of the RS-232 connector around the cable on the DB-9 end. When the metal hood is screwed down over the cable a connection will be made. When using a plastic DB-9 hood simply solder a wire from pin 1 on the RS-232 end to the metal body of the DB-9 connector. Since documentation is scarce for the AT, following figure lists the necessary pin connections for those wanting to make their own AT RS-232 cable. DB-9 RS-230 (Computer (Modem Description End) End) ========= ======= ================== GROUND -------- 1 -------- Protective Ground 1 -------- 8 -------- Data Carrier Detect 2 -------- 3 -------- Receive Data 3 -------- 2 -------- Transmit Data 4 ------- 20 -------- Data Terminal Ready 5 -------- 7 -------- Signal Ground 6 -------- 6 -------- Data Set Ready 7 -------- 4 -------- Request to Send 8 -------- 5 -------- Clear to Send 9 ------- 22 -------- Ring Indicator RBBS-PC CPC17.3 Page 282 APPENDIX T -- RBBS-PC And BASIC Compiler Patches for "Doors" ------------------------------------------------------------ A bug in Microsoft's BASIC and QuickBASIC compilers requires SysOps who wish to recompile RBBS-PC to apply the following patches. The problem has to do with BASIC's treatment of the communications port when you exit a BASIC program. The Data Terminal Ready (DTR) line MUST be kept on at all times, or the modem will hang up on your caller. If you are recompiling RBBS-PC, and you plan to use Doors or external protocols, you must make the following patches. Any hex editor can be used: DEBUG, which comes with DOS, or the Norton Utilities are just two examples. A tutorial on how to use DEBUG is beyond the scope of this document. There are actually two patches, depending on the version of the compiler you have. The first patch is for QuickBASIC 2, 3 & 4 or BASCOM 6.0. The file you will patch is BCOMx0.LIB (where X is the QB version number). Of course, you will save your original file before applying the patch. To make the fix, you will search for the following string of HEX digits: 83 C2 04 32 C0 EE. The assembly code for this string is: 83 C2 04 ADD DX,4 32 C0 XOR AL,AL EE OUT DX,AL We need to change the XOR AL,AL to MOV AL,1. Change the "32 C0" to "B0 01". Make this change in both places where the string occurs. If you use QB 4.5, or BASCOM 7.0, the patch is different. Look for the string: B0 00 E3 01 40 83 C2 04 EE. In assembly code, it is: B0 00 MOV AL,00 E3 01 JCXZ nnnn 40 INC AX 83 C2 04 ADD DX,4 EE OUT DX,AL Again, we want to put a 1 in AL, so we change the "B0 00" to B0 01". We also need to remove the INC AX, so change the "40" to "90". You may also want to make an additional patch. This patch will prevent QuickBASIC from pausing on a fatal error. Normally, BASIC says "press a key to continue". If RBBS-PC were allowed to recycle, it would do so without trouble, but BASIC will hold up your board until you press a key. If you have QuickBASIC 2.01 or 3.0, search the BCOMx0.LIB for the following string of HEX digits: E2 F8 E8 00 00 E8 00 00 E8 00 00 C3. Change the MIDDLE "E8 00 00" to "C3 90 90". If you have QuickBASIC 4.5, search for the string "B8 07 0C CD 21" and change the "CD 21" to "90 90". Now, whenever BASIC can't handle an error, it will allow RBBS-PC to recycle quickly. If you have BASCOM 7.0, you can apply the patch for QB 4.5, although you will have to patch whichever BC70xxxx.LIB file you use to link. Thanks to Doug Azzarito, Jeff Porter, Rod Bowman, Kenny Gardner and Bob Eyer for information on these patches. RBBS-PC CPC17.3 Page 283 APPENDIX U -- Using RBBS-PC to access ORACLE or dBASE Remotely -------------------------------------------------------------- 1. The Need for Data Base Services A feature that has been long missing from PC based host communication systems is the ability for SYSOPs to install customized data bases and let callers run true interactive data base queries against them. Because data base management is a major programming task, the most promising way to add data base services is to uses RBBS-PC's original and innovative "DOOR" mechanism to exit RBBS-PC and have the remote user enter an existing data base management program. "DOOR"ing to a data base management program, however, is not as easy as one might hope. The major problems stem from the fact that data base management programs are never designed to work in this environment. This is because: 1. Most programs write to the hardware for speed rather than use bios calls, causing the "screen" output to appear on the host terminal rather than on the caller's terminal. 2. Data base programs do not monitor for carrier. If carrier drops they simply sit forever waiting for input rather than terminating. 3. Most use "full screen" rather than "line at a time", which usually does not work properly on a remote terminal. 4. Security. Most data base programs have no way to limit what a user can do. For example, they do not have a read-only mode, or the ability to restrict a user to specific files or fields. Many let the user issue dos commands inside them, which gives to call too much power. 5. Difficulty in learning to use. A caller can hardly be expected to know how to use a data base. Hence it must be possible to simplify and control the user interface inside the data base package. Progress has been made with two of the most popular PC data bases -- ORACLE and dBASE! Using dBASE "DOORS" with RBBS-PC -------------------------------- db/LIB is a relatively new piece of software by AJS Publishing of North Hollywood, CA that makes remote dBASE access possible. db/LIB is a set of two assembled libraries which can be used to create/modify dBASE data structures, create/update dBASE indices, and naturally manipulate the dBASE records. These libraries also have many replacements for dBASE functions/commands not easily replicated (ie. IIF, RECNO(), DATE(), RTRIM(), DELETED(), etc.) outside of the dBASE environment. db/LIB is currently developing a multi-user version that should be released for testing by the end of January 1989. db/LIB was designed to work with Microsoft Quick BASIC 4.0 and BASIC Compiler 6.0 (there is a QB 2/3 version available directly from AJS Publishing after you purchase db/LIB). dBASE Remote Access Advantages/Disadvantages Combine db/LIB with any well written door skeleton (such as the very fine skeleton) and you can have a true shareable remote database system. The following section highlights some advantages and addresses the problems concerning remote dBASE database access. RBBS-PC CPC17.3 Page 284 Advantages of using db/LIB and dBASE data bases: 1. Purchase of dBASE is not required. db/LIB can create modify and maintain any dBASE structure. A program with db/LIB and downloaded by a third party can give these same freedoms to a third party. Sample programs with db/LIB demonstrate that most of dBASE's functions can be replicated or substituted using db/LIB. 2. If dBASE (or any good clone) is owned, then the two work very well in tandem. The programmers at Ashton-Tate didn't gain their reputation for writing junkware. By owning dBASE, the user can download any database structure and perform any data manipulation easily in a familiar environment. 3. Full screen (ANSI) writes, security, carrier monitoring, error trapping, are all handled by the door skeleton. Let database modules run the database, and let the door modules run the door. Disadvantages of using db/LIB and dBASE data bases: 1. Remote dBASE database access is not the same as accessing dBASE III remotely. Creation of these DOORS requires knowledge of Quick BASIC, some knowledge of data communications, and some knowledge of dBASE. All end user requirements have to be anticipated, all cases covered, and created in advance. Once the application is created, then user need no little or nothing about any of the above. 2. Not all users can use ANSI commands for full screen editing. This means that doors need to have a scrolling (terminal) type display capability as a substitute for the normal full screen writes. In some doors this will simply be impossible, preventing all users from database access. For those interested in dBASE-based on-line data base searches with RBBS-PC, you might try writing Steven Kling at 4009 Utah Ave., Brentwood, MD 20722. Steven is the author of BBS_BASE, USER_BASE and DoorBase. BBS_BASE is a non-ANSI dBASE III demonstration DOOR that maintains a database of Bulletin Board names, phone numbers, etc. This database can be queried, added to, edited, and up to the minute reports can be generated. The entire database with indices can be downloaded by the user for personal use. This database is indexed and therefore can be queried either by name or phone number. BBS_BASE was written only as a demonstration of using RBBS-PC to access a data base remotely. USERBASE is a dBASE registration door for RBBS 15.1C and above. It comes in both ANSI and non-ANSI versions and gives an automatic access upgrade capability to the SYSOP at his/her option. Steven Kling and Michael Kelly are collaborating on DoorBase, which has just been released, and this will give a SYSOP the capability to place any dBASE III database on-line, and will allow him/her to set up all the full screen display features to his/her own specification. DoorBase has multiple demonstration databases available including databases of Congressmen, dBASE vendor support companies, and a national BBS listing. RBBS-PC CPC17.3 Page 285 Steven is also the SYSOP of Technopeasants' EAST RBBS at (301)-927-4258 Brentwood, MD (PC Pursuitable) 24 Hours/ 2400 baud. Michael is the SYSOP of Technopeasants' WEST RBBS at (503)-257-7070 Portland, OR (PC Pursuitable) 24 Hours/ 2400 Baud. Using ORACLE with RBBS-PC for On-line Data Base Access ------------------------------------------------------ Another database package that is able to be used as a "door" is ORACLE from Oracle Corporation at One Oracle Parkway in Belmont, California 94002. Their number is (415) 598-8000. ORACLE is a very promising solution to providing remote data base services. Oracle addresses the problems mentioned earlier as follows. 1. Screen writes. ORACLE user bios calls. All output appears perfectly normal on remote terminals through the CTTY interface in RBBS-PC. 2. Monitor for carrier. Run WATCHDOG, which will reboot your system if carrier drops. 3. Full screen mode. ORACLE uses only ANSI commands to control the users screens. Callers whose remote communications package implements ANSI support therefore see full screen writes exactly the same as local users. FULL SCREEN WORKS! 4. Security. ORACLE has all the security you could ever want because it was designed for multi-user systems. 5. Usability. ORACLE implements SQL, which is increasingly becoming an industry standard that all major data base systems are supporting. Of course, there are some problems using ORACLE in a way in which it was never designed: 1. There is a problem getting the function keys to work properly remotely. 2. The ability for a caller to use DOS commands needs to be disabled within ORACLE. 3. Callers who do not know SQL need pre-structured queries and a menu interface to be designed for them. ORACLE supports a full screen interface but the user interface in ORACLE is not as programmable as one would like. For those interested in ORACLE-based on-line data base searches with RBBS-PC, you might try writing John Prior at P.O. Box 2168, Rockville, MD 20852-2168. Steve is the SYSOP of SQLBBS at (301)-881-6588 Rockville, MD (PC Pursuitable) 24 Hours/ 2400 baud. The SQLBBS is a specialized bulletin board system specializing in supporting relational data base managers and making the power of SQL available to callers. SQLBBS uses an RBBS-PC door to get into ORACLE. The RBBS-PC CPC17.3 Page 286 SQLBBS has implemented ORACLE to help manage the data processing for the National Council for Children's Rights (NCCR), and have several major data bases on-line for general interest. People can contact John Prior, the SQLBBS SYSOP, on Compuserve or MCI, by mail, or call SQLBBS if they wish to see how ORACLE is implemented, get the latest progress report, or share experiences implementing data base services. Here are details on the SQLBBS system and how to reach both John and it: Modem: 2400 Baud Hayes BBS Number: 301/881-6588 Hours: 24 hrs/day Address: Prior Computer Service Inc. POB 2168 Rockville MD 20852-2168 Compuserve ID: 76266,1072 MCI MAIL ID: JPRIOR SYSOPS: John F. Prior Steve J. Prior Tony Zelof SQL Tables Roster of the House of Representatives Available Roster of the Senate [both with addresses etc.] Now The States [2 char abbreviation and full name] Call SQLBBS as you would any other RBBS-PC system. Go through the Door. SQLBBS executes a "SELECT * FROM TAB;" for you which shows you the tables and views you can access. At the UFI> prompt execute any SELECT command you want against any table or view. "SELECT * FROM STATES;" returns all rows [records] of the STATES table. "SELECT * FROM STATES WHERE ST = 'MA';" returns all rows about the state whose two-character code is "MA". "SELECT COUNT(*) FROM STATES;" gives you a count of the rows in the STATES table. If you substitute another table or view instead of STATES such as SENATE, you can access other tables/views. "DESC HOUSE" would return the column names of the HOUSE table. "HELP" gets you help. "HELP SELECT" gets you help on the SELECT command. "HELP SET" gets you help on the SET command which can control many options for display "SHOW ALL" shows you everything you can SET. "EXIT" terminates UFI and returns you to RBBS-PC. RBBS-PC CPC17.3 Page 287 APPENDIX V -- Using RBBS-PC with SEAdog to Access FIDO-NET ---------------------------------------------------------- SEAdog is a full-featured electronic mail system based on the personal computer and using standard telephone lines. It is a sophisticated store- and-forward mail system which can be configured in a virtually unlimited number of network topologies (more on this later). Unlike some network systems, the end user need never concern himself with network routing -- it all happens automatically. The user just submits and retrieves messages, the system takes care of the details. The hardware needed to run RBBS-PC is sufficient to run SEADOG. SEAdog uses the FidoNet Electronic Mail Protocol, as defined in the document, A Basic FidoNet Technical Standard, published by the International FidoNet Association (IFNA). The FidoNet Protocol is a public domain electronic mail standard originally developed by Tom Jennings for the Fido bulletin board system. For more information about the FidoNet Protocol, please write to: The International FidoNet Association P.O. Box 41143 St. Louis, Missouri 63141 United States of America There are several advantages to using the FidoNet Protocol, not the least of which is that a great many utilities and programs are available from many different vendors for doing various things with electronic mail. Please contact IFNA at the above address for more information. The heart of SEAdog is the network mail server, MAILER.EXE. This is the program that places and receives phone calls, handles message routing, and so forth. It is left running when you would normally turn your machine off. You can set RBBS-PC to drop to DOS at a time when telephone costs are cheapest (normally 4AM Eastern Standard time and 1AM Pacific time) and invoke the mailer so that it begins placing phone calls to other SEAdog systems to pass them your outgoing mail and receive your incoming mail. SEAdog costs $100.00 and can be ordered from the address or phone number below. Thom Henderson SYSTEM ENCHANCEMENT ASSOCIATES 21 Wayne Street Wayne, New Jersey 07470 V:201-473-5153 This doc file is not intended to replace the SEAdog manual, but rather provide information that an RBBS-PC SYSOPsysop would find useful when configuring RBBS-PC to run with SEAdog. The current status of the RBBS-PC - SEAdog project is at the level in which RBBS-PC has the ability to be front-ended by SEAdog in where SEAdog will turn over to it a live, active modem with a caller waiting. RBBS-PC has been modified to accept two additional command line parameters which can alter the defaults in RBBS-PC.DEF. Currently, that is the extent to which RBBS-PC and SEAdog can be used together. The Fido message base format is RBBS-PC CPC17.3 Page 288 not yet compatible with RBBS-PC. It is assumed that you are reading this because you are familiar with the RBBS-PC and have at least a minimum knowledge of FidoNet and FidoMail. Another assumption is that you have RBBS-PC up and running on your computer. The easiest way to get all two programs working together is to have each running from it's own subdirectory on your hard disk. That'll make maintenance of RBBS-PC and SEAdog specific files much easier. Follow the instructions in the SEAdog manual to install it, if that hasn't been done yet. Once installed all SEAdog files will be in a subdirectory called \MAIL. Make any required modifications to your CONFIG.SYS as suggested in the SEAdog manual. If your using DOS 3.xx, and don't use the DOS SUBST command, you should consider doing so. SUBST is a DOS external command that allows you to SUBSTitute a drive letter for a complete subdirectory name. Using this command will make reprogramming RBBS-PC's configuration file easier. This appendix assumes that all the SEAdog Files are in a subdirectory called C:\MAIL and those for RBBS-PC are in a directory called C:\RBBS. A further assumption that is made is that a new drive "H:" will be SUBSTitued for the C:\RBBS subdirectory. Since SEAdog will be in controls most of the time, the entire operation should use SEAdog's C:\MAIL directory as the default. Now load and run CONFIG.EXE and reprogram it's configuration to reflect that all RBBS's help, menu and system files are located on the "H:" drive. Remember the SUBSTitute command? You can use it to replace those long subdirectory names for download and upload files. SPECIAL ATTENTION must be paid to CONFIG.EXE's parameter 163. This parameter MUST be set to SYSTEM recycle. Not doing so will cause RBBS-PC to reload itself after a caller has hung up or dropped carrier and not pass control back to SEAdog. The SEAdog manual explains various commands that must be placed in it's configuration file called CONFIG.DOG. Among those that are considered a minimum, you should include at least the following.... banner Please stby, 15 secs to load RBBS-PC bbs H:RBBS *T *B event B all 4:30 5:00 ;Local collections event A all 5:00 6:00 ;National FidoMail Window event C all 6:00 7:00 ;Local distributions event S all 7:00 4:00 Crash Dynamic BBS ;CRASH mail if not in RBBS event X10 all 7:00 7:05 ;Reboot Computer The banner statement should be used so that human callers know why there is a delay from the time they connect until the time they see RBBS-PC display it's welcome message. The bbs command tells SEAdog what batch file to run when passing control to RBBS. *T and *B must be in the order presented above in for RBBS-PC to pickup and use them correctly. They pass the time remaining to the next scheduled SEAdog event and the baud rate the caller came on with. Event statements tell SEAdog how to schedule it's time during the day. The above example conforms to the FidoNet national mails hours as of 26 July 1987 and allows crash mail and bbs operation at all others. RBBS-PC CPC17.3 Page 289 Since the SEAdog *P parameter in the bbs command isn't used, you must insure that the comm ports used for RBBS-PC and SEAdog are the same. One of the more confusing decisions will be how to setup the modem switches. Without going into it too deeply, keep in mind that SEAdog will be controlling the modem and passing an active modem on to RBBS-PC. Additionally, you could have your SEAdog upload and download areas overlap those of RBBS-PC. When SEAdog determines that a non SEAdog or Fido system has called, it runs a second copy of DOS, then optionally loads and runs RBBS-PC via direct command or from a batch file, passing the speed that the comm port was opened at, and the time remaining to the next scheduled SEAdog mailer event as in the following example: SEAdog calls RBBS-PC via a batch file called RBBS.BAT C>RBBS-PC 1 H:RBBS-PC.DEF /%1 /%2 | | | | |> Baud Rate | | | | | | | | | | | |> Limits the amount of time the user has | | | this session if and only if the time is | | |less then the time per session specified |||in CONFIG.EXE. | | |> RBBS-PC default file filespec (Optional) | |> Node number that the specified .DEF file applies to. |(Optional) |> The name of the RBBS-PC program. With a properly configured RBBS.BAT batch file, you can retain all the functions of RBBS to include DOORS and dropping to DOS via SysOp function #7. See the sample batch files at the end of this file. Experience has shown that the best way to run RBBS-PC and SEAdog is with a batch file, where SEAdog having determined that a non mailer system is waiting to use the bbs will load and run a batch file that controls RBBS- PC's operation as opposed to SEAdog calling RBBS-PC directly. Two batch files are used, one to control SEAdog and one to control RBBS. A minimum batch file is suggested in the SEAdog manual. In addition to what ever you place in it, add the following statements to it. If Exist H:RCTTY.BAT Del H:RCTTY.BAT This line should be the first. This statement simply helps ensure proper operation of RBBS-PC if you use SYSOP function #7 or DOORS. If Errorlevel 10 Goto REBOOT: This line goes after the line that contains the call to the MAILER program. REBOOT: IPL This line reboots the computer every morning according to event listed above. Due do unexplained loss of memory when running SEAdog and RBBS-PC, is safe to program in a scheduled rebooting of the computer to regain any RBBS-PC CPC17.3 Page 290 loss of memory. This line should be near the last and programmed around for normal operations ** Ex RBBS batch file ** Echo Off :LOOP C: Cd \MAIL If Not Exist H:RCTTY.BAT Goto LOCAL H:WATCHDG1 OFF Del H:RCTTY.BAT H:TESTRBBS 1 H:RBBS-PC.DEF Goto REMOTE :LOCAL H:TESTRBBS 1 H:RBBS-PC.DEF /%1 /%2 :REMOTE If Not Exist H:RCTTY.BAT GOTO EXIT H:WATCHDG1 ON H:RCTTY.BAT :EXIT As mentioned above, this doc file isn't intended to make you completely knowledgeable on how to interface RBBS-PC and SEAdog, only get you started. How you set up your RBBS-PC and SEAdog batch files is limited only by your ability and imagination. After gaining more experience, you'll find that you can automate a lot of the RBBS-PC and SEAdog maintenance. The above reflects the creative things that Kim Wells, Fido Address 109/652, has done with interfacing RBBS-PC with the Fido net-mail system. If you need further help, contact Kim Wells's RBBS-PC via his data line at (301) 599-7651/7652. RBBS-PC CPC17.3 Page 291 APPENDIX W -- DOS Limitation on Running Programs Remotely --------------------------------------------------------- When accessing your PC via a communications port, the carrier detect signal tells the PC that you are on-line. DOS's major limitation is that there is no way to tell DOS to monitor carrier detect automatically when the standard input and output is transferred to a communication port (i.e. via the CTTY command). RBBS-PC makes sure that the carrier is not dropped when a user exits to DOS either via the "DOORS" option or using the remote SYSOP function 7. However, it is the SYSOP's responsibility to insure that whatever programs are invoked after leaving RBBS-PC perform all the necessary functions to maintain the communications session and, when exiting to return to RBBS-PC, that the carrier is "NOT" dropped. Most application programs (i.e. databases, etc.) are not designed to be controlled by users accessing them from a communications port. This problem is solved when a function is invoked that: 1. Checks to see if the standard input and output console have been assigned to an auxiliary console such as a communication port. 2. If condition 1 is true, checks to see if the carrier detect signal is lost by intercepting each interrupt from the communication port the auxiliary console has been assigned to. 3. If BOTH conditions 1 and 2 are true, this function would cause DOS to return to the standard screen and keyboard for its operations AND continue processing whatever batch file that had been executing. Such a function (or device driver) would provide a "fail safe" feature that would allow users to exit RBBS-PC to use whatever other software the SYSOP chose to make available (i.e. relational databases for complex inquiries -- bibliographic, sports, games, etc.). For those anticipating using RBBS-PC's "doors" or exiting to DOS when you are a remote SYSOP, you are strongly encouraged to consider using the "watchdog" utility program available on many bulletin board systems under such file names as WATCHDOG.COM, WATCHDOG.ASM, WATCHDOG.DOC, WATCHDOG.EXE that monitors the communication port for you and reboots your system if carrier drops. If you don't use a program like WATCHDOG and accidentally hang up while in a "door" or in DOS, you system will remain "hung" until you can manually reboot it. Programs that utilize the PC's built in video memory (such as the IBM BASIC interpreter or WordStar when it writes to the 25th line) need to have such I/O redirected in a special way to a remote users terminal. Additionally, if the I/O is redirected to the communications port, the terminal on the other end must have a "cursor" that can be sent the appropriate command sequence to move it around on the remote users terminal as necessary. Without this capability, programs made available through "doors" must be line-at-a-time programs. This of course excludes programs such as WordStar, Lotus/123 etc. If you aren't technically inclined and want to use RBBS-PC "doors", I suggest you consider only using programs that have been explicitly written to overcome the above two DOS limitations. Applications that don't write directly to the video memory of the PC can be used safely as a "door" as long as a "watchdog" type program is also used. RBBS-PC CPC17.3 Page 292 APPENDIX X -- Using RBBS-PC with DoubleDOS ------------------------------------------ Two nodes of RBBS-PC can be operated on one 640K PC/XT/AT under DoubleDOS. First, make sure DoubleDOS and RBBS-PC, individually, operate correctly on your computer. Then, the DDCONFIG.SYS file can be changed to facilitate operation of RBBS. SoftLogic Solutions, the DoubleDOS supplier, operates a customer service BBS at 603-644-5556 and can often help with special problems. (An example: DoubleDos version 4.0 must be modified with their special patch in order to operate on machines using EEMS memory controlled by AST's REMM.SYS driver.) DoubleDOS even has a special interrupt that RBBS-PC calls to "give back" unused time to the foreground job when it really doesn't need the time, so that during periods of low communications activity, the foreground job runs at essentially 100% of the machine's speed. GIVEBACK is incorporated into releases CPC16-1A (and greater) of RBBS-PC. The DOS (3.1 or greater) utility SHARE should be run before starting DoubleDOS to provide for file locking. RBBS-PC, due to the code generated by the BASIC compiler, requires a considerable amount of memory. If insufficient memory is available, RBBS- PC may fail to load, may report a string corrupt error, may hang, or, worst of all, may appear to start and operate normally only to fail later. A (partial) test of whether enough memory is available is to note the DS free space in the SYSOP initial menu when operating under DoubleDOS compared to naked DOS; any reduction in this reported free space may indicate memory shortage. The best approach, unfortunately, is to start with more memory than necessary, get your system going reliably, and then do a crude cut- and-try process of reducing memory until problems first appear; then back off up to an again-reliable memory setting. Terminate-and-stay-resident programs (e.g. ramdisks, print spoolers, Side Kick) will reduce the memory available to RBBS-PC. Buffers specified in the CONFIG.SYS file also reduce available memory. Some versions of DOS are smaller than others; every little bit of memory helps. Large programs may not run in the second DoubleDos memory section after starting RBBS-PC in the first. Because of these memory considerations, SHELLing to DOORS and external file transfer protocols will not be possible. If these features of RBBS-PC are used, they will need to be invoked by EXITing to them. The BASIC compiler version used determines the amount of memory required. Two nodes of RBBS(version 16.1A), have been demonstrated to operate successfully under DoubleDOS when compiled with Quick Basic 1.02 and RBBS- PC's memory requirements reduced (see Appendix Y). When compiled with Quick Basic 2.x, 3.x or 4.x, two nodes will not fit under DoubleDOS. To save memory, expert SYSOPS who are adept at compiling/linking their own custom versions of RBBS-PC, can selectively (and at their own risk) delete from the source code sections that they do not require. Such personal versions should not be circulated to others. If this is done, the more recent compilers may produce code compact enough for 2 nodes. DoubleDOS has several parameters that can improve RBBS-PC operation. RBBS-PC CPC17.3 Page 293 Sample: menu = short ;the long menu requires more memory display = text ;to not reserve graphics buffer print driver = direct ;use direct drive, no buffer reserved bottom size = half ;split memory for two RBBS nodes priority = equal ;both nodes run at same speed The next items may be desirable to provide protection, in case any program in the other memory section should try to use a COM port assigned to RBBS- PC. com1 = top ;obviously these two port assignments com2 = bottom ;could be reversed Possible circumstances that might warrant this protection: 1.SYSOP makes a COM port assignment error in the .DEF file for the other node. 2.one node is temporarily shut down by the SYSOP to run another program. Some programs (e.g. some versions of BASIC) initialize both COM ports (clobbering RBBS-PC) when started. Warning: this protection is known to be unusable on some machines (e.g., works fine on IBM-PC 8088, does not work on AST Premium 286 or TATUNG 4000 AT). It is convenient (and safer, to prevent keystroke errors) to automate your startup. In your AUTOEXEC.BAT file you should initiate DOUBLEDOS as the last item. It will then start, using the DDCONFIG.SYS file for detailed RBBS-PC instructions. Sample DDCONFIG.SYS contents (this will vary according to your exact setup): top program = prompt TOP $p$g top program = go bottom program = prompt BOT $p$g bottom program = go Note that the change in prompt allows a single batch file, GO.BAT, which has the single statement of GO%PROMPT%, to execute the correct node of RBBS-PC in either node. Nothing is more embarrassing than to start a node that is already operating. All that need be typed is GO<RETURN> and either GOTOP or GOBOT will be executed. (Actually the GO batch file execution looks like "TOP C:\DDOS>GOTOP $p$g". The $p$g is ignored.) GOTOP.BAT might then look like this: C: CD\RBBS RBBS1 RBBS1.BAT would then be the first node RBBS.BAT as discussed in this document. Similarly, GOBOT would start RBBS2.BAT for the second node. Stan Staten, RBBS-PC number (301) 670-9621 Kurt Riegel, RBBS-PC number (202) 524-1837) RBBS-PC CPC17.3 Page 294 APPENDIX Y -- Recompiling RBBS-PC to Reduce Memory Required ----------------------------------------------------------- RBBS-PC has always sought to live up to CPCUG's Bill of Rights for Software Users which maintains, among other things, that each software user has a right to "integrate software products into his or her system environment without undue constraints." For this reason, RBBS-PC has chosen to be as configurable as possible through the program CONFIG with over 200 different parameters. Additionally, RBBS-PC has always been distributed with the complete BASIC source code with each new release. It is this kind of leadership (by example) and recognition of software users rights that makes RBBS-PC unique in the personal computer industry. RBBS-PC is continually being enhanced with new features. As new functions and capabilities are added, RBBS-PC's memory requirements grow correspondingly. In order to continue RBBS-PC's growth and still meet the memory constraints imposed on SYSOPs with only 640K of memory who wish to run two copies of RBBS-PC, RBBS-PC source code can be "mite-sized" and recompiled to fit within whatever memory constraints a SYSOP must deal with. SYSOPs can apply .MRG files against the unmodified RBBS-PC source code and elect to eliminate RBBS-PC features not being used and eliminate redundant code (typically the BASIC source code that replicates assembly language routines). RBBS-PC has a companion "mite-size" set of files contained in the file RBBS-LIT.ZIP. In order to recompile and "mite-size" RBBS-PC, within the same environment in which the SYSOP has successfully recompiled the current release of RBBS- PC, the SYSOP must also have the following files: BLED.EXE -- The Batch Line EDitor by Ken Goosens (version 2.2 or greater). MAKELIT.BAT -- The BATch file that invokes BLED.EXE and applies the necessary files to the unmodified source code. This file should be modified by putting in the drive/path for the original code (the first parm to BLED). The lines to be modified all begin with "*$", which is the default for a BLED metacommand. The lines beginning with "* " are BLED comments, which are ignored in a merge. SETLIT.INC -- The file through which the SYSOP selects the RBBS-PC features that are not needed. The directions for doing this are contained within this file. A feature is typically removed by setting a BLED metacommand variable to "OFF", e.g. BAUD450 to "OFF" to save code by excluding the RBBS-PC feature that allows 300 baud uses to increase their baud rate to 450 while on-line. To exclude RBBS-PC LIBRARY subsystem set LIBRARY to "OFF". RBBSLIT.MRG -- The fundamental BLED merge for RBBS-PC.BAS SUBxLIT.MRG -- The fundamental BLED merge for various RBBSSUB's. Each reads in (includes) the file SETLIT.INC to set the metavariables used by BLED. BLED then uses the values RBBS-PC CPC17.3 Page 295 to determines what merges to process. *.LIT -- .MRG files that eliminate RBBS-PC features. The procedure for "mite-size"ing RBBS-PC is as follows: 1. Select the RBBS-PC features not required for your needs and modify the file SETLIT.INC. 2. Change MAKELIT.BAT to reflect your PC's subdirectories. 3. Make sure RBBSSUB1.BAS is in the subdirectory you will run in. 4. Execute the MAKELIT.BAT file. Do not continue if errors are found. 5. Recompile the "mite-sized" RBBS-PC source code. Remember, this "mite- sized" source code and the RBBS-PC.EXE file created from it my only be used by you and not distributed to others. Some comments on the various Microsoft QuickBASIC compilers: QuickBASIC Version 1.02 produces the smallest code. QuickBASIC Version 2.01 produces the next smallest code. QuickBASIC Version 3.00 produces the largest code. QuickBASIC Version 4.5 produces code smaller than 3.00) but is not as reliable Never LINK with the /E option. 6. Re-run CONFIG and disable the RBBS-PC features that were deleted in the "mite-sized" version that was created in steps 1 through 5 (i.e. take out the "A" command if questionnaires were disabled). Please realize that there is no way that the "mite-sized" variations of RBBS-PC can be supported. The many different PC configurations plus the multitude of combinations of RBBS-PC features are what make this impossible. However, we will do our best. Please report any problems with BLED or the *.LIT merges to Ken Goosens via his RBBS-PC data number -- (703) 978-6360. RBBS-PC CPC17.3 Page 296 APPENDIX Z -- The MICROCOM AX\9624c RBBS-PC Switch Settings ----------------------------------------------------------- First set the Microcom AX\9624c switch settings as follows: CONFIGURATION SWITCH SETTINGS FOR THE MICROCOM AX\9624c MODEM ============================================================= 1 2 3 4 5 6 7 8 9 10 -------------------------------------- Front Switch - U D D D D U U D U U Rear Switch - U U D U D D D D - - Change CONFIG parameter 228 to open the modem initially for 9600 baud. Then go to CONFIG parameter 225 and change some of the default Hayes commands. Within parameter 225, you will want to change the second command, "Initialize the modem." If you want RBBS-PC to answer on one ring set it to: ATM0Q1S2=255S10=45E0S0=254&D2 To answer on zero rings, set it to: ATM0Q1S2=255S10=15E0S0=0Q0X1&D3 Please note that these change the default Hayes commands supplied with RBBS-PC for S10. Also note that an &D command was added to the end. If you are set up to answer on ring zero and your modem sometimes stops answering for no reason that you can isolate, alter the S10 value to "45" and &D2. You may also want to activate CONFIG parameter 236 to "wake up" the modem. These configurations will allow RBBS to establish a MNP reliable or non- reliable connection from 300 to 9600 BAUD using the AX\9624c's MNP class 6 Universal Link Negotiation capability. RBBS-PC CPC17.3 Page 297 APPENDIX AA -- The Leading Edge Series L 2400B Modem ---------------------------------------------------- Gregg Snyder, SYSOP of "The Elusive Diamond" - DGS (Alpha) System, and Jim Thompson of "The Break" -DGS (Delta) System (Data: 703-680-9269) are to be credited with documenting how to get the Leading Edge Series L 2400B modem to run with RBBS-PC ("all modems are Hayes-compatable, but some are less Hayes-compatable than others"). First you must set CONFIG parameter 228 to open the modem at 1200 baud. Next go to CONFIG parameter 225 and set the modem commands as follows: 1. Reset the modem : ATB1H0L1M0C1 2. Initialize the modem : ATH0B1L1M0Q1E0S0=254 Note: End item 2 with: S0=1Q0X1 if answer on 0 rings S0=254 if answer on >0 rings (no ring-back) S0=255 if answer on >0 rings (with ring-back) 3. Count the number of rings : ATS1? 4. Answer the phone : ATQ0X1V1A 5. Take the phone off the hook : ATH1L1M0 6. Clear the modem's firmware : AT&F 7. Initialize modem's firmware : AT&C1&D3B1E0V1M0S0=0&T5 Note: End item 7 with: Q1 if item 2 ends with S0=255 8. Write to modem's firmware : &W These settings have been tested for more than a year by Jim Thompson beginning with RBBS-PC CPC15-1C. ================= END OF RBBS-PC CPC17-3 DOCUMENTATION ==================