Media Share 9

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

/ Media Share 9 / MEDIASHARE_09.ISO / bbsdoor / condr15b.zip / CONNDOOR.DOC < prev next >

Wrap

Text File | 1994-02-13 | 52KB | 1,138 lines

CONNDOOR Version 1.5 BETA, February 13, 1994 - Written by - Garry W. Elmer K-9 BBS FIDONET 1:320/105 1-203-536-1300 *********** If you are already using CONNDOOR, READ the CONNDOOR.FIX and CHANGE.TXT file before attempting to use this revision!!!!! * The "|" at the end of some of the lines of this document indicate text that has been changed or added since the last version of CONNDOOR was released. *********** THIS IS NOT PUBLIC DOMAIN SOFTWARE! WARRANTY Every effort was taken to ensure a quality program. However, because of the there's no way to anticipate all the different ways this program can, or will be used, or on what equipment it may be used, I make no guarantees or warranties of any kind, nor will I hold responsibility for any type of damage caused by this program. As always: BACK UP! * The CONNDOOR program makes no modifications to your BBS related files except the FILES.BBS files. It creates it's own support files where needed and interfaces with the BBS via the EXITINFO.BBS or DORINFO1.DEF file. Removing the program is a simple matter of deleting all the associated files. OVERVIEW It's a file transfer door.... it's a breath mint.... It's a FILE TRANSFER DOOR!!! Unlike earlier versions of CONNDOOR, 1.5 has NO protection| scheme installed and all the features and capabilities are| fully functional. | This door was written to fill the gap left by many other file transfer doors. CONNDOOR has been tested with SUPERBBS and QUICKBBS. It should be compatible with any BBS that uses a QBBS/SBBS style of EXITINFO.BBS or DORINFO1.DEF and a text FILES.BBS text file to keep track of directories. Features: Can be configured to use either EXITINFO.BBS or DORINFO1.DEF files. Can be used from any BBS that uses either one of these files and a FILES.BBS text file. Supports up to 16 protocols including full duplex protocols | such as HSLINK and BIMODEM. | Complete carrier monitoring and "inactivity" monitoring. "Dup" upload detection and prevention. Variable time "payback". (2:1) (QUICKBBS/RA/SUPERBBS only) | "Reward" system awards points to the uploader of a file when it's downloaded by another user. Full log keeping capabilities. Batch up/download capabilities. Built in TAPE DRIVE capability. | CDROM Capability | "DON'T WANT" file to keep unwanted files from being uploaded. Interface with file tagging capability in SUPERBBS | CONNDOOR Files: CONNDOOR.EXE Actual door program. CONNFIG.EXE CONNDOOR configuration program. CTPOINT.EXE Adds [000] to all file area descriptions if that function is desired. CONNMOVE.EXE Utility to keep CONNDOOR support files up to date whenever a change has been made to the file areas. CONNSET.EXE Used to create CONNDOOR file area support files on the initial installation and to "pickup" new files into the system when they have been manually added. CONNUSER.EXE Creates CONNDOOR user data base from USERS.BBS file. CONNEDIT.EXE File listing and User database editor. TEST.EXE Dummy protocol simulator for setup testing. Consult TESTING.DOC for more info. Misc sample configurations ASSUMPTIONS CONNDOOR now accepts "blind" uploads (uploads not identified | prior to the start of the transfer). This is sysop definable.| The door is set up to take uploads in ONE directory per configuration. If your system is set up to allow the user to upload into whatever directory they are in, CONNDOOR may not suit your needs. Multiple configurations can be used to meet| a variety of requirements. | If you use the download counter "[000]" configuration, the counter text must be 3 digits. CONNDOOR will ignore "[0]" or "[00]" type configurations. There is a program included to change and/or add the 3 digit counters to all the file listing lines on your system. This program will also convert the counts from the 1 or 2 digit configurations. CONNDOOR does not care about the "K" totals uploaded or downloaded. Points are awarded per successful upload regardless of file size. For downloads, CONNDOOR only cares whether the user has enough points and has enough time left. The equation I used for determining transfer time is not based on 100% efficiency and usually favors the user. INSTALLATION A test program is included (TEST.EXE) to simulate a | protocol to facilitate testing once the system is set up. | This program will return an Errorlevel 0 telling CONNDOOR | that the transfer was successful. Consult the TESTING.DOC | for more info on it's use. | For the sake of speed, all the examples and samples reference the default or BBS directory as D:\QUICK. That is where all of my BBS files are. In your configurations, just change the D:\QUICK to whatever directory you keep your main BBS files. MUST do/have prior to operation: The following things HAVE TO BE DONE before the door can be properly used. Place all the files from the main compressed file in your main BBS file directory. The protocol programs you are planning to use should also be in the main BBS directory. ***** VERY IMPORTANT ***** Create a text file called "DF.CTL". This is the default CTL| file name and a list of directories that CONNDOOR will be | able to access. | This file is a listing of all of your file directory paths. No tabs or spaces should be left in the beginning of each entry, and even though the door programs will ignore extra entries, it's best not to tempt fate. It should look something like this: C:\TRASH D:\GAMES C:\MODEM C:\WORD and so on, listing all the file areas you want your users to be able to access. MUST HAVE !!! MUST HAVE!!!! MUST HAVE !!!!! The FIRST entry in the DF.CTL file must be a TRASH directory of some kind. If you don't use a trash directory to keep a FILES.BBS listing of files that you DON'T want on your system, you must create one and it MUST be the first directory listed in the DF.CTL. If this is not done, CONNDOOR will make a real mess of it's support files. TRASH DIRECTORY This is the first directory in the DF.CTL. CONNDOOR always looks in this directory first (the first directory in the DF.CTL listing) and assumes that these are the files you DO NOT want uploaded. In this directory, a CONNDOOR support file will be created and checked like all the other directories when a user attempts to upload a file. If the file is found, during an upload sequence, as in any of the directory support files, it will be rejected. If you do not have one with a FILES.BBS file in it, I suggest you create a dummy directory for this purpose and add a FILES.BBS text file to it with a blank line (Carriage Return). Make sure it's the FIRST path listed in the DF.CTL. More on this in the FILE AREA MAINTENANCE paragraph. After the above things have been done, follow the steps listed below to install. STEP 1. ******************CONNDOOR CONFIGURATION********************* (The line editor used in the entry of various things in the CONNFIG and CONNMOVE programs is nothing extravagant. After making changes, re-run the program to make sure the system took what you wanted to write.) Execute the CONNFIG.EXE file within the BBS directory. The utility creates the two CONNDOOR configuration files, CONNDOOR.CFG and CONNDOOR.PRO. The first page of the program is the basic configuration. Most of it is self-explanatory. CONNDOOR.CFG - Created by CONNFIG.EXE and contains CONNDOOR's operating parameters. Multiple CFG files can be used. CONNDOOR.PRO - Created by CONNFIG.EXE and contains the commandlines for the various file transfer protocols used with CONNDOOR. CONFIGURATION PAGE BBS EXIT FILE TYPE - This is an EXTREMELY IMPORTANT function!!! This is the file that CONNDOOR will look for when it starts up. If you are using SUPERBBS, QUICKBBS, RA, or any other clone of these programs, use the EXITINFO.BBS selection!!!!!! This allows the most data to be passed between CONNDOOR and the BBS program. If your BBS program can create a DORINFO1.DEF text file but cannot create an EXITINFO.BBS file, use the DORINFO1.DEF selection. !! WARNING !! The EXITINFO.BBS mode and DORINFO1.DEF mode cause CONNDOOR to use different sizes of records for the USERS.DIL file (user records). If you set your system in one mode, then change it later, your USERS.DIL database will NOT WORK and will be corrupted and unusable. CONNFIG.EXE will prompt you if you try to change it. UPLOAD DIRECTORY - The UPLOAD Directory is the path to where newly uploaded files will go. UPLOAD & DOWNLOAD LOG(s) - The UPLOAD and DOWNLOAD LOG lines are the path and file names where CONNDOOR will report on what files have been successfully uploaded and downloaded. SYSTEM LOG - The SYSTEM Log is usually the path and file name of the BBS system log. DSZ LOG - This is the complete path to where your system has it's DSZ.LOG file. The DSZLOG is created by the DSZ protocol program and several other popular protocols. CONNDOOR can use this file to verify successful downloads and "blind" uploads. | COM PORT - Enter a ,1 2, 3, or 4. MIN "K" - The MIN "K" Entry is the minimum amount of bytes open in the upload partition before CONNDOOR will prohibit uploads. The sample configuration is set to 500K or 1/2 Meg. If there's less than that available, no uploading will be allowed. NEW USER POINTS - The number of points given to a new user. When a new user goes into the CONNDOOR for the first time, the door program will give him this to start. If you use CONNUSER (EXITINFO.BBS style BBSs only) to set up the CONNDOOR user database, it will give everyone 10 points to start and count their uploads and downloads from there to determine how many points they have. New users will automatically be given accounts when they enter the door for the first time. POINTS GIVEN FOR UPLOAD - The points given to a user for each file they successfully upload. UPLOAD POINTS - The points assigned to a file when it is uploaded. This could be considered the "cost" of the program for others to download. PAY POINTS - The points awarded to the uploader of a file every time someone downloads it. EXAMPLE: (Using the sample config) John Doe has 10 points. He uploads ABCD.ZIP to the system. He is awarded 6 points for the upload. 5 users like the ABCD.ZIP file and download it. John Doe is awarded 1 point for each of these downloads and winds up with a total of 21 points. EXEMPT SECURITY LEVEL - This function allows you identify users that have no downloading restrictions. If you set it at 70, everyone with a Security Level of 70 or above is considered "EXEMPT". CONNDOOR will not let their point total go below 10 in effect giving them unlimited download capability except for time. If you do not want this capability enabled, enter 0. ADD COUNTER - This function will include the "[000]" download counter in the file descriptions of uploaded files and update them when the files are downloaded. YES to enable. (Executing CTPOINT.EXE will add these to your file descriptions. (See Step 6 in the SETUP Section) ADD +++++ - This function will put "+++++" in the beginning of the file description. This will be replaced by the files actual date when processed by MidNightMover 2.3D (MNM) and newer versions. The docs for MNM explain how to use the MNM. If in doubt answer NO here. (MNM can be obtained from my BBS) ******** The next two lines have to do with TAPE DRIVE utilization. | (See the Section on TAPE) | ******** ALLOW BLIND UPLOADS - | I define a "blind" uploading as starting the protocol before| the upload has been identified by the user. The file must | be processed after the upload. Some protocols, such as | Z-modem, allow operation in this mode. If you answer"YES", | the user will be able to start the protocol and the file will| be checked against the file libraries and DON'T WANT lists | after the upload. The user will also be prompted for a | description after the upload. Duplicate uploads with be | rejected and deleted. Files not wanted will be retained, | but the user will not get credit for these files. | UPLOAD TIME PAYBACK - This selection allows you to identify how much time, if any,| is given back to the user for the time they spent | successfully uploading a file. The selections: | 0 = User does not get any time added to their session for a | successful upload. | 1 = User will get the time they spent uploading, added to | their online time. | 2 = User will get twice the time they used on a successful | upload. | Once you have completed the first page, press F2 to call the protocol page. PROTOCOL PAGE You will see two columns of selections. | These are the available "slots" for protocols. Select the number of the "slot" that you want to update. The changeable selections will appear below: ENABLE KEY - The key the user will press to select that protocol. Entering a "-" will effectively clear the entry. CONNDOOR will ignore it. LINE NAME - The protocol's name DESCRIPTION - Any amplifying info you want to add. When the user is online, they will see ENABLE KEY. LINE NAME DESCRIPTION for each protocol. Example: "Z. ZMODEM Fast!!!!" UPLOAD COMMANDLINE - The commandline for that protocol for files to be RECEIVED by the BBS. DOWNLOAD COMMANDLINE - The commandline for that protocol to SEND files to the user. (When making changes to the commandlines, CONNFIG will automatically take out extra spaces left from the editing since an insert and delete function are not included in the line editor) PROTOCOL COMMANDLINE VARIABLES %1 BAUD Rate of the Connection %2 COM Port to communicate with %3 STRING, a list of selected uploads or downloads %4 LIST, a file created with a list of download files. (Used with Zmodem like protocols) %5 UPLOAD PATH, Complete path to your upload directory %6 TIME LEFT, How much time the user has left online All of these variables do not have to be used in every commandline. Look at the sample configurations and if in doubt, consult the docs for the protocol you are trying to install. BATCH TOTAL - If the protocol can handle batch transmissions (more than one file in a single session), this is total files that CONNDOOR will let the user select at one time. (10 is the maximum) LOG TYPE - There are 3 selections, DSZLOG, BIMODEM, NONE. - TYPES - BIMODEM - When the user selects this log type, the protocol is executed immediately. This should only be used with BIMODEM. I have not considered any other uses for it. (See the BIMODEM Paragraph for details) DSZLOG - This tells CONNDOOR to check for the DSZLOG after a download. If the downloaded file is listed in the DSZLOG, credit is taken from the user. Only successfully downloaded files will be subtracted from the user's account. Only protocols set up to create a DSZLOG should have this function enabled (Zmodem, PUMA, etc). CONNDOOR will look for the DSZLOG in the path designated in the CONNDOOR Configuration. If you select this log type and CONNDOOR can not find the DSZLOG, CONNDOOR will consider the download successful and points taken from the user for the file whether the transfer was successful or not. FULL DUPLEX - This selection is used for full duplex (upload | and download at the same time) protocols such as HSLINK. The| only thing required is that the user identify downloads prior| to downloading and that the protocol be capable of making | DSZ.LOG style entries. CONNDOOR will determine if files were| uploaded from this log and prompt the user for descriptions | accordingly. DO NOT use this selection with BIMODEM as a | more extensive interface is already built in for BIMODEM. | NONE - CONNDOOR has no way of determining if a requested download was completed. If the download was started, CONNDOOR counts all the downloads against the user's account whether they got the files or not. The "BLIND" upload function | should NOT be enabled with this selection. | F2 will return you to the first page. F1 will cause the configuration to be saved and program terminated, ESC will cause the program to terminate without updating the CONNDOOR configuration files. This configuration can be changed at any time. STEP 2. After DF.CTL has been created and the CONNDOOR configuration created, the file areas have to be "Initialized". Execute "CONNSET /A". This will cause the CONNSET program to read all the FILES.BBS files in all the directories listed in the DF.CTL file creating a "FILES.DIL" file in each directory. This file has the file name, uploader's name, and point cost of each file. When run with the "/A" switch, the point cost is set to 1 and no uploader is listed. NEVER use the "/A" switch again! The "/A" switch causes all the FILES.DIL files (CONNDOOR directory support files) to be created from scratch and all files will have no uploader listed and cost 1 point, basically resetting the entire CONNDOOR file system. STEP 3. Execute CONNMOVE.EXE. A short configuration file will appear. SCAN DIRECTORY is the directory your uploads go into, TRASH directory is just that. (should be the same as the first entry in DF.CTL). FILE LISTING is the DF.CTL file. This will compare the FILES.BBS, FILES.DIL and actual files in the directory. If the file is not found in the directory, CONNMOVE will search all the other directories for the file. If the file is not found, the FILES.DIL entry is moved to the FILES.DIL in the TRASH directory. If the file is found in another directory, the entry is moved to the FILES.DIL file in that directory. This effectively "syncs" the FILES.DIL files, with the FILES.BBS files and actual files in each directory. Step 4. The CONNDOOR in the BBS BATCH FILE CONNDOOR must be activated from your BBS batch file with a Type 15 menu command. The basic commandline "switches" are: CONNDOOR -U (for upload) CONNDOOR -D (for download) **** HINT **** Adding a "-X" to the commandline will enable the DEBUG mode. Whenever a protocol is enabled, the protocol command string will be sent to a file C_D_BUG.LOG in the upload directory. This will help you configure your protocols. This switch will also cause the TAPE COMMANDLINE to be saved when CONNDOOR is in the TAPE mode. EXAMPLE: CONNDOOR -D -X (for download & DEBUG) There are 3 other commandline switches to be discussed later. This is all you need to use CONNDOOR in it's simplest mode. Step 5. When CONNDOOR is executed from the BBS, CONNDOOR will search for EXITINFO.BBS or DORINFO1.DEF, DF.CTL, CONNDOOR.CFG, CONNDOOR.PRO, DONTWANT.DIL and USERS.DIL. All these files are created either by the BBS or by you during the setup except for USERS.DIL. USERS.DIL is the file that keeps track of a user's points for CONNDOOR. USERS.DIL can be created one of two ways. If there is no USERS.DIL, CONNDOOR will create one as if the user is new, give them whatever points you have identified for new users and allow them to go on their merry way. The only users that will be listed in USERS.DIL are the ones that use the door. This is by far the easiest way to start up, but all of your users will be starting "fresh" regardless of their previous file ratios, good or bad. This is the ONLY way you can create a USERS.DIL file when DORINFO1.DEF has been selected in the CONNFIG.EXE program. (QUICKBBS/RA/SUPERBBS systems only) (BBS EXIT FILE TYPE = EXITINFO.BBS) The other way is to execute CONNUSER.EXE. CONNUSER.EXE will take your BBS's USERS.BBS file, read it, compute how many points the users would've earned with their current upload/download count and make a USERS.DIL database from this info. CONNUSER will delete itself after execution since it only needs to be executed once. If a user winds up with a negative point count, CONNUSER will set their point total to zero. CONNUSER can only read and interpret a QUICKBBS/SUPERBBS/RA style of USERS.BBS file. Step 6. (Optional) CTPOINT.EXE is a utility program to modify your existing FILES.BBS text files. CONNDOOR has the ability to update the "[000]" 3 digit style of download counters in the FILES.BBS files. CONNDOOR, however, will NOT update the 2 or 1 digit format, "[00]" or "[0]". Executing CTPOINT.EXE will add or change all of these entries in all of the FILES.BBS files in the directories listed in the DF.CTL. It will keep and/or transpose the counts if they already exist in any format closed by the "[]" brackets. ****************************** DONTWANT.DIL This is an optional ASCII text file containing the names or portions of names of files that you DO NOT want uploaded to your system. One entry per line and no extra spaces or characters should be added. If CONNDOOR finds a match between any line in this file, and ANY portion of an upload file's name, the file will be rejected. If you do not desire to use this function, delete the sample DONTWANT.DIL file included | with the program. Multiple "DONTWANT" type files can be | used with the "-W" commandline switch. (EX. -WREJECT.LST) | EXAMPLE: If you put "GIF" in the DONTWANT.DIL file, CONNDOOR will reject A.GIF, ABCD.GIF, and GIFVUE.ZIP uploads. IF you only wanted to reject attempted upload files with the extension "GIF" you would have to put ".GIF" in the DONTWANT.DIL file. The first two GIF files would be rejected and GIFVUE.ZIP could be uploaded. BIMODEM BIMODEM is a popular "full duplex" protocol allowing files to be uploaded and downloaded at the same time. BIMODEM commandline examples are set in the CONNDOOR.PRO configuration file. CONNDOOR looks for a file BI.DIL to be created by the BIMODEM transfer. The name of this file must be identified in the BIMODEM commandline along with the type of log BIMODEM is to create. The "/I" BIMODEM commandline switch makes sure that the BI.DIL file is created and is in a format that CONNDOOR can read. In the example in the CONNDOOR config, The time variable %6 is used to prevent BIMODEM from running over the user's allotted time. BIMODEM is a difficult protocol to get configured, but worth it when it works! For downloads, BIMODEM will still search the directories pointed to by the file area list identified in it's own configuration. The commandline to use BIMODEM with CONNDOOR is: "BIMODEM /B%1 /L%2 /T%6 /IBI.DIL" FILE AREA MAINTENANCE ADDING & DELETING FILES - ADDING When a file description is added to a FILES.BBS file and the file added to it's associated directory, it is still not accessible to CONNDOOR. CONNDOOR uses the FILES.DIL file as it's index of what is available in a directory. To add a file, it must be added to the FILES.DIL file and the FILES.BBS file. After the file description has been added to the FILES.BBS file, running CONNSET will add the file to the FILES.DIL file making it accessible to CONNDOOR. - DELETING To remove a file from the BBS, delete the description line from the FILES.BBS and delete the file from the directory. When the CONNMOVE.EXE program is executed, it will find the file entry in the FILES.DIL file, but not find the entry in the FILES.BBS or find the file in the directory. CONNMOVE will assume that you moved the file and search all the other directories (listed in the DF.CTL) for the file. If it does not find the file, it assumes you deleted it and places it's FILES.DIL entry in the first directory listed in the DF.CTL, the TRASH directory. Since you deleted the file, CONNDOOR assumes you don't want it uploaded again and it's entry into the TRASH directory's FILES.DIL will prevent that. To remove all reference to the file from the system, the FILES.DIL entry can only be removed with the CONNEDIT program. Moving files: When an upload or download is identified during a file transfer session, CONNDOOR goes out and searches the FILES.DIL in each directory you have listed in the DF.CTL. When you move files and descriptions from one directory to another, the FILES.DIL file still reflects the files that were there before you moved any files. When uploading, if CONNDOOR finds the name in ANY FILES.DIL file, the upload will be rejected. For downloading, the file must be listed in the FILES.DIL ** AND ** be present in the directory. If not, CONNDOOR reports the file as NOT FOUND. The CONNMOVE program will search all the directories in the DF.CTL list and compare the files in the FILES.DIL file with what is actually in the directory. If it finds an entry in the FILES.DIL that is not in the directory, it will search the other directories for it. If it finds it (because you moved it), it will move the FILES.DIL entry to the appropriate directory keeping the file areas in "sync". If it doesn't find the file, it assumes you deleted the file and moves the FILES.DIL entry to the first directory listed in the DF.CTL file (The TRASH directory) to prevent it from being uploaded again. The command to run CONNMOVE.EXE from a batch file (without prompting for setup) is: CONNMOVE -R MANUALLY ENTERED FILES If you manually enter a file and description into a FILES.BBS file, it must also be "picked up" into the FILES.DIL file in the appropriate directory. Just run the CONNSET.EXE program as: CONNSET This will compare all the FILES.BBS files in the DF.CTL directory list, with the FILES.DIL files and add any that are not already there, picking up any new files you have entered into the FILES.DIL file. The file must be in the directory! (Except for TAPE and CDROM directories) CDROM/TAPE - If CONNSET encounters a directory designated as CDROM or TAPE (See TAPE or CDROM), if will update the FILES.DIL file regardless of whether the file is actually in the directory as long as the entry has been added to the FILES.BBS. CONNEDIT CONNEDIT allows the user database, USERS.DIL, and the file area support files, FILES.DIL files, to be edited. This program is fairly self-explanatory. If you set a file's "cost" point to 0, the file will be "FREE" and the downloading of this file will not count against the user except for the time the user took to download it. The PURGE/DUP function will purge the FILES.DIL files of any entries that have been deleted with CONNEDIT, and delete any DUP entries in FILES.DIL file. If the program encounters two entries for the same file and one entry contains the uploader's name and the other does not, the program will keep the entry with the uploader's data. This should be executed periodically to prevent duplicate FILES.DIL entries and purge deleted file entries. "ORPHAN" FILES Orphan files are files that appear in your upload directory without any descriptions or entry into the system. Normally this won't happen with the "blind" upload function enabled. If you are running without this function and the user enters that they are going to upload one thing, then upload a different file, these files will be "orphaned" in your upload directory. A log entry will notify you that this has taken place. If a file is "blind" uploaded and it is a duplicate, it will be automatically deleted. If a file is "blind" uploaded and it is on the "DON'T WANT" list, CONNDOOR will keep it but not credit the user with th upload. In my BBS batch file, during the middle of the night "housekeeping" routines I run the following: -------------- CONNSET ;Picks up any files I've entered manually MNM ;(OPTIONAL) ;The MidNightMover program, unpacks compressed ;files, scans for virus, repacks, logo stamps, ;dates and moves file to user upload directory. CONNMOVE -R ;Moves FILES.DIL entries to keep file areas in ;"sync" after MNM has moved the files from my ;temporary upload directory to my user-available ;upload directory. -------------- Gee, wasn't that EASY???? MULTIPLE CONFIGURATIONS CONNDOOR and CONNFIG have the capability to identify the config (default CONNDOOR.CFG) file and directory listing (default DF.CTL) file in the commandline. This can allow you to run various configurations, access plans, even different point schemes by using different CFG and CTL files. It also increases the confusion factor a BUNCH! The possibilities are endless. To use another CONNDOOR config file, -C is used. To use another CONNDOOR directory listing -F is used. Example: To use a different config file called "ANOTHER.CFG", and a different directory listing called "ANOTHER.CTL", you would use- CONNDOOR -U -FANOTHER.CTL -CANOTHER.CFG (for upload) CONNDOOR -D -FANOTHER.CTL -CANOTHER.CFG (for download) CONNFIG -CANOTHER.CFG (to edit ANOTHER.CFG) **************** TAPE DRIVE UTILIZATION - | On the first page of the CONNFIG display is the TAPE FETCH ENABLE and TAPE COMMANDLINE entries. The TAPE FETCH ENABLE has 3 different selections: NOT USED - Tape Drive not used. ENABLE AFTER EACH REQUEST - After the user has requested a file from the tape, the TAPE COMMANDLINE will be executed to retrieve the file. This is done for each selection. This is by far the easiest method to use. The files can be in different storage areas on the tape also. EXAMPLE: You can use a different volume on the tape for each directory you have stored on the tape since each tape access is separate. ENABLE PRIOR TO TRANSFER - When a file is requested from the tape, it's name is placed in a file called TAPE.DIL (COMMANDLINE Variable %5) and the user is prompted for the next file or action. When the user is done selecting his files and elects to start the transfer, the tape drive COMMANDLINE is executed ONE TIME. The files are restored to the UPLOAD Directory and DOS calls are used to move the files from the UPLOAD directory to their respective download directories then deleted from the UPLOAD directory prior to the transfer commencing. The directory you identify to restore the files into MUST BE the UPLOAD directory. This is sloppy, but was done to keep the code small. Multiple volumes/areas of a tape CAN NOT be addressed with this mode. All the "|" text lines in the DF.CTL must point to the same area on the tape. After each tape retrieval 2 minutes will be added to the users time to compensate them for their patience while the tape is accessing. SETUP Pick the directory you want to carry on tape and backup all the files in the directory to the tape, including the FILES.BBS and FILES.DIL (in case you ever want to restore the directory to the hard drive). After the files have been backed up to tape, delete all the program files, leaving FILES.BBS and FILES.DIL in the directory. Use the info provisions in the tape drive software to find out the volume number of files you just stored. When converting over to tape, take the section of your ALLFILES listing for that directory and copy it over the FILES.BBS file in the directory, AFTER you have copied the files up to tape. CONNDOOR looks for the file size text after the file name in a tape directory. If no FILES.DIL existed before creation of the area, a FILES.BBS text file must be created INCLUDING in the description the size of the files. (See Example). After creating the FILES.BBS and identifying the directory as a TAPE directory, execute CONNSET and a FILES.DIL will be created. This is a normal file listing from the FILES.BBS. K9FILES.ARJ [052] Files listing for the BBS If the file is going to be on tape, the SIZE of the file must be included in the text line after the file's name. (See below) K9FILES.ARJ 41791 [052] Files listing for the BBS * For the sake of ease, we'll assume you are using the C:\MODEM directory and it's Volume 1 on a COLORADO tape system. The DF.CTL now must be modified to tell CONNDOOR to go to the tape drive for the C:\MODEM directory. The "|" symbol followed by a text string, one space after the directory path tells CONNDOOR to go to tape. The text string should be the identifier for the tape. In the case of the COLORADO tape system, it's the volume number. For the IRWIN drives, it might be the backup group's name. (EXAMPLE "BACK_UP.001") This is converted to the commandline variable "%1". ************ The "|" symbol is what enables the TAPE interface in CONNDOOR. ************ EXAMPLE: C:\TRASH D:\GAMES C:\MODEM |1 C:\WORD When files are requested from that directory, CONNDOOR identifies it as a tape directory, goes out to the tape and restores the file to the original directory, then gets the file's info and allows it to be downloaded. When the transfer is complete, deletes the file. If the user ABORTS the CONNDOOR program before the transfer, the file will remain restored in the directory assuming the user will come back to get it. These should occasionally be cleaned out if they become a problem. Since CONNDOOR checks the directory for the file FIRST and only goes to the tape if it can't find the file, you can mix hard drive available and tape available files in the same directory. In the tape mode, CONNDOOR also looks for a commandline switch "-T". Only use this switch if you are using BIMODEM as one of your protocols. The user must identify the files for download before the download takes place. The "-T" switch causes a message to be displayed to the user when they select BIMODEM as a protocol informing them of that and giving them the opportunity to do so instead of going right to BIMODEM. This will allow any files stored on tape, to be retrieved from the tape prior to starting the BIMODEM transfer. The commandline for the COLORADO Tape backup software would be: "C:\TAPE\TAPE RESTORE %4 %2 /V=%1" "C:\TAPE\TAPE" is the path and name of the tape drive software. TAPE DRIVE COMMANDLINE VARIABLES %1 String after the "|" Whatever text is placed after the "|" in the DF.CTL file. This string can be the volume number, name of the storage group identifier like "BACKUP.001" or whatever your tape software requires. %2 File name selected by user. (just the name) %3 Restore path (path to the directory to restore the file into). %4 Filename and path of file selected by user. (Combination of %3 and %2) %5 "TAPE.DIL" A text file list created of all the files requested from the tape drive. (Should only be used with the ENABLE PRIOR TO TRANSFER function). WARNING! When using the TAPE feature and CONNMOVE, the execution time on CONNMOVE is very long! It could take several minutes to run. I am working on it! HINT: I set the CONNMOVE program to point to a CTL file other than DF.CTL. This file only contains the paths to the trash directory, directory where my unscanned uploads go, and the directory where user-available uploads go (NEW UPLOADS) since these are the only directories affected during the normal operation of my system. I use CONNMOVE in the manual mode after I have moved a lot of files around and use the DF.CTL. I have used the TAPE mode extensively with the COLORADO JUMBO tape system. I have also found that some of the tape drive software will not run properly in a multitasking environment. I have yet to find a way around it. CDROM UTILIZATION: The CDROM interface is very similar to the TAPE interface. When a file has been requested from a directory on the Hard Drive that is designated as a CDROM directory, CONNDOOR will first search the Hard Drive directory for the file, and if the file is not found, CONNDOOR will access the designated CDROM partition for the file. When the file is located, it is moved over to the Hard Drive directory and the user will be able to download it. Upon completion of the transfer, CONNDOOR will delete the file. Operation in this manner allows the mixing of Hard Drive available and CDROM available files in one directory. The FILES.BBS and FILES.DIL files reside in the designated directory on the hard drive and are updated like a normal file area. The "down side" of this strategy is that | each file area you want the users to be able to access on the CDROM must have it's own counterpart on your hard drive. | There are many possibilities but I have not explored them | since I do not have a CDROM. | SETUP: A CDROM directory is designated by a "?" after the Hard Drive file directory followed by the path to the CDROM area where the desired files are stored. If the CDROM partition is E:\ and you wanted to list files from the CDROM in the C:\MODEM directory, the example below shows how it should appear in the DF.CTL. EXAMPLE: C:\TRASH D:\GAMES C:\MODEM ?E:\ C:\WORD The FILES.BBS and FILES.DIL files are placed in the C:\MODEM directory. The FILES.BBS and FILES.DIL files are prepared in a similar fashion to the TAPE area FILES.BBS and FILES.DIL. This is a normal file listing from the FILES.BBS. K9FILES.ARJ [052] 12/92 Files listing for the BBS If the file is going to be on CDROM, the SIZE of the file must be included in the text line after the file's name. (See below) K9FILES.ARJ 41791 [052] 12/92 Files listing for the BBS If you are using a CDROM and BIMODEM is offered for your users to use, the "-T" switch should be used in the COMMANDLINE for CONNDOOR so that the user is prompted to identify all of their downloads prior to enabling BIMODEM so that the files may be retrieved prior to the start of the BIMODEM transfer. ONLINE OPERATION When enabled from the BBS, CONNDOOR will display a rather run- of-the-mill display screen with the standard sysop info at the bottom and what the user sees at the top. The user will be able to select their protocol then move on to select files. The sysop can "key in" commands from the keyboard to help the users and entering ESC will terminate CONNDOOR and return the user to the BBS. No other "special" functions are included. FILE SEARCHING I could write several pages on the inner-workings of CONNDOOR and file searching but I will try to touch upon the important. CONNDOOR ignore file extensions TOTALLY. This is one of the ways CONNDOOR avoids duplication of files uploaded with different compression styles. If "ABCD.ZIP" is listed for upload, and "ABCD.ARJ" is already on the system, it will be rejected (BIMODEM will allow it though). If you have already have "dup" files on your system like the above example, CONNDOOR will stop it's search at the first "ABCD" it encounters. DOWNLOADING The prompting for downloading is pretty much self-explanatory. WILDCARDS are a bit different under CONNDOOR. The WILDCARDing methods used are not true WILDCARDs in a DOS sense. The inclusion of a "*" into a file name causes CONNDOOR to find any file with the selected text in the name. Example: Entering "AB*.ZIP" for download will return a "found" for - ABCD.ZIP (Remember, CONNDOOR ignores file EXTENSIONS) ABCD.GIF DABC.ARJ Searching for "*AB.ZIP" will return the same group as "AB*.ZIP". Searching for "AB.*" will only return a "found" for an EXACT match of "AB". ("AB.ZIP" or AB.ARJ") Once again, file EXTENSIONS are ignored. CLOSING Some of the CONNDOOR's features, or lack of features, are radically different than with some other file transfer door programs out there. I attempted to provide a door that would: Require a MINIMUM of maintenance. Take greater steps towards the prevention of the uploading of undesirable or "dup" files or types of files, either by "mystery" batch uploads or different file extensions. Provide a way to use a Tape Drive to supplement online storage Promote the use of BIMODEM Provide more incentive to upload and reward the uploaders of popular software for their efforts. ****** ACKNOWLEDGEMENTS To the authors of the other fine programs mentioned in this documentation, I apologize for not giving you each the recognition you obviously deserve. REGISTERING CONNDOOR To register CONNDOOR, please see the CONNDOOR.REG doc for details. SPECIAL THANKS TO: My wife for putting up with the all the hours of code crunching. (Brave Souls) Dave Hallford of the CASA DE CRICKET BBS in Modesto, CA Bill Winterholer of the GEMSTONE BBS in Groton, CT John Skobrak of the THREE MILE ISLAND BBS in Charleston, SC Mike Myers of the GENESIS BBS in San Jose, CA As with all projects, this one started out small and turned into a monster. The CONNDOOR system is quite complex and with each increase in capability, the complexity and difficulty in debugging goes up tremendously. If you encounter problems with CONNDOOR please feel free to contact my BBS at 203-536- 1300 or NETMAIL 1:320/105. Your efforts will be recognized and GREATLY appreciated. CONNDOOR is FREQable from my BBS, 1:320/105 under "CONNDOOR". --------------------- OTHER Software available (FREQable from 1:320/105): MidNightMover (MNM) - Utility designed to handle compressed files. Virus scanning, moving, converting, dating, logo stamping etc. Designed to move FILES.BBS listings and interface with CONNDOOR. Will also fill dates in for CONNDOOR generated file descriptions. MOVEIT!! (MOVEIT) - File are utility designed to allow batch moving, deletion, and "orphan file pickup" for BBS systems using the FILES.BBS format. Many features. ENFORCER (ENFORC) - Multi-level BBS security level program designed to allow a user to change between up to 5 different security levels based on their file transfer ratio and posting ratio. Fully configurable. CONNSORT (CONNSORT) - Places FILES.BBS text files in alphabetical order. Allows unlimited file directories and FILES.BBS text files up to 1000 lines long with description lines up to 300 characters long.