Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / VD170R1.ZIP / VD.DOC < prev next >

Wrap

Text File | 1993-03-06 | 30.6 KB | 985 lines

PRELIMINARY DOCUMENTATION PRELIMINARY DOCUMENTATION PRELIMINARY DOCUMENTATION THIS DOCUMENTATION IS NOT FINISHED BUT WAS INCLUDED ANYWAY IN ORDER TO GET THE NEW RELEASE OUT A.S.A.P. PLEASE REFER TO THE ENCLOSED VD.CFG FILE FOR INFO ON SETTING UP VALIDOOR. V V A L III DDDD OOOOO OOOOO RRRR V V A A L I D D O O O O R R V V AAAAA L I D D O O O O RRRR V V A A L I D D O O O O R R V A A LLLLL III DDDD OOOOO OOOOO R R Documentation Version 2.00 Copyright (c)1989-93, Cabell B. Clarke Jr. ALL RIGHTS RESERVED. The Boot Factory BBS -------------------- FidoNET 1:264/19 3/12/24/96/144 v32bis (804) 262-9289 Disclaimer This software is sold "AS IS". It is not guaranteed to work at all. If it trashes your system or ruins your life, you have been warned. I am not responsible for any damages incurred from the use or misuse of this software. ValidOOR is a User Validation Door written for the RemoteAccess Bulletin Board System. ValidOOR allows Sysops to have their systems call users back in order to verify that they have left a valid phone number for the sysop's records. Validoor then updates the user's BBS record so he can call right back and have access to the BBS. This saves the sysops time and trouble of manually validating users. Be forewarned *** ValidOOR is NOT designed to keep unwanted users off of your BBS. It will not keep a determined person off.*** It will validate your users so you don't have to manually do that. ValidOOR is being released as Shareware. This means you are free to evaluate the program for 30 days. If it meets your needs, you are then expected to register your copy by sending me a registration fee. Registering ValidOOR entitles you to all minor releases of Version 1 of ValidOOR (1.00-1.99). It also grants you access to the ValidOOR Support Forum on my BBS which contains ValidOOR utilities. Users who register Version 1 of ValidOOR are entitled to Version 2 free of charge. There will possibly be an upgrade fee to version 3 but remember I originally said the same thing about version 2. Unregistered versions of ValidOOR will have a 30 second delay built-in to the program. The KEY file will eliminate this delay and inform the rest of the world that you have registered your copy. Please register ValidOOR. This program has been in development since December of 1988, and has cost me a lot in the process. Support the Shareware concept. Registration of ValidOOR allows you to run ValidOOR on one computer system ONLY. In order to register ValidOOR, see the LICENSE.DOC file for an order entry blank. Fill out the form and send with the registration fee to: Cabell Clarke 5513 Cottage St. Richmond, VA 23228 Your KEY file will be sent to you via FidoNet mail, or US Mail... whichever is convenient. Allow 2 weeks for processing. A Note about multi-line systems At this time, VD does not support file/record locking so it cannot be reliably used on a multi-node bbs on more than one node. It should work fine on one node however. I would like to add file/record locking to VD in the future. Send Code<tm>. Getting Started In order to get going with VD, first you need to unzip all of the files into your BBS or ValidOOR directory. See the file PACKING.LST which accompanied the VD ZIPchive to make sure you have all of the necessary files. I recommend printing this documentation. I also recommend printing the VD.CFG file as it contains helpful hints for setting up the configuration file in it's comments. Modify (or create) the .MNU .ASC .BAT files included to suit your needs. The enclosed are samples only which I run on my system. You are welcome to modify my files for your own use keeping in mind that my setup may be somewhat different from yours. Rename the vd###.exe to VD.EXE Environment Variable You can run ValidOOR in its own sub-directory by setting the ValidOOR environment variable to that sub-dir. Two valid examples are: set validoor=d:\validoor\ set validoor=c:\bbs\vd VD will find its sub-dir with or without the trailing backslash. You should place your vd.cfg and vd.key (registered users) in this sub-dir. If you want to place your executable files in this directory you should also include it in your path like this: path=c:\bbs\vd Setting Up vd.cfg The VD.CFG file contains all of the important parameters necessary to run VD. Please remember that any line which begins with a per-cent (%) is a comment and may be removed, however, if you remove comments, you are on your own. VD.CFG is well-commented and should be self explanatory in setting it up. Just load it into your text editor. Make sure that there are no comments on the lines which contain parameters. Also make sure that you only have one (1) space between the Variable Descriptor and the variable itself like this: ModemSuffix &M4 ^ one space here NOTE: In the many versions of ValidOOR there have been several vd.cfg file formats. In this version, there are some new descriptors so it is suggested that you modify the configuration file included in this archive to suit your setup. Make sure the vd.cfg file you are using is compatible with your version of VD. Variable descriptors in vd.cfg --- % - the percent sign is a comment and must be placed in the first column of the line that you wish VD to ignore. Do not place a '%' on the same line after a variable descriptor or the program will not operate correctly. --- SysopName - Your name should go here. This is required. Example: SysopName Cabell Clarke --- YourCitySt - Tells VD what city and state your BBS resides in to notify the user where the call will be originating so the user can tell VD if VD needs to dial a 1 to reach the User. --- Port - Port tells VD which communications port you are using. Valid ports are 0-3 where port 0 = COM1 etc. If you are using COM1 for your modem you would need: Port 0 --- DialPrefix - This is the prefix that tells your modem how to dial out. Mine looks like this: DialPrefix ATDT --- AreaCode - This Variable is used to tell VD which area code(s)you can place a local call to. You may have up to 5 local area codes in VD.CFG... for instance someone who lives in Washington DC might have a VD.CFG which looks like this: AreaCode 202 <-- your area code first AreaCode 301 AreaCode 703 This is because he does not need to use an area code to dial any of these three areas. Maximum of 5 local area codes supported at this time. Make sure that your own area code is listed in the file first. --- InvalidExchange - This descriptor tells ValidOOR about 3 digit exchanges which are invalid like 911 in some areas. ValidOOR treats these exchanges very harshly so use them with care. If a user attempts to get ValidOOR to dial a number with one of these exchanges, ValidOOR will disconnect them from the system. You may use a maximum of 10 of these. Examples: InvalidExchange 911 InvalidExchange 411 --- PreDialLDCode - This descriptor is the prefix used by your phone system for dialing a long distance call. The default value is 1. PreDialLDCode 1 --- NotFirstDigit - This descriptor tells ValidOOR about invalid first digits in phone number exchanges. ValidOOR will refuse to dial numbers with these digits first. I use the two below. NotFirstDigit 0 NotFirstDigit 1 --- Phone - This variable is used to tell VD how your BBS saves the user's phone number. When a new user logs on if you ask for both Home Phone Number and Data/Business Phone number then your VD.CFG file would need the following: Phone HomePhone Phone DataPhone If you only ask them for their Home Phone Number then your VD.CFG file would only need this: Phone HomePhone --- YourCodeLD - This one will allow you to tell VD not to strip your area code from long distance numbers in your area code - I call this Ed Marquis mode <grin> since it was his requirement which prompted the addition of it. YourCodeLD NoStrip If you don't use this VD will default to stripping them anyway. --- LongDistance - The LongDistance descriptor enables/disables Long Distance calling. If you do not want VD to make a long distance call you would have the following in your VD.CFG file: LongDistance NoLDCall If you want VD to make a Long Distance call (whether using slots or not), you would use: LongDistance LDCall This one would make long distance calls at any time or allow you to use the slots below if you want to. --- LDSlotDefault - This variable tells VD the default slot of time for making long Distance calls. This slot is always in effect unless commented out or overridden by a daily slot. The correct usage is: LDSlotDefault <starttime> <stoptime> Example: LDSlotDefault 2200 0700 The above would allow your system to make long distance calls between 10pm and 7am on all days providing the LongDistance variable is enabled as shown above. --- LDSlotSun LDSlotMon LDSlotTue LDSlotWed LDSlotThu LDSlotFri LDSlotSat - These are the daily slots which will override the default slot above. The syntax for these is the same as above: LDSlotSat 0000 2359 LDSlotSun 0000 1659 The two examples above would allow your system to call long distance all day Saturday and all day before 5pm on Sunday. The rest of the days would use the default slot above. --- MaxAttempts - This variable tells VD how many times to attempt to call a user with NO CONNECT! If you only wanted to try twice you'd have: MaxAttempts 2 VD will only call once if a connection is made. This is hard-coded into the program and cannot be modified. --- ModemTimeOut - This is the number of seconds you want VD to wait for a carrier before recycling. NOTE: For maximum efficiency You should also set this value in register S7 of your modem in your modem initialization string. (S7=45). See ModemInit below. ModemTimeOut 45 --- UserTimeOut - This is the number of seconds to wait for input from the user before timing out due to INACTIVITY. UserTimeOut 40 --- ModemInit - This is the string that you want VD to use to initialize your modem. I use this for my HST: ModemInit AT S0=0 E0 X6 S7=45| Note the s7=45 which is the same as the 45 in the ModemTimeOut variable above. If you want VD to ignore result codes use an X0 in this string but remember if you use an X0, all Bad Number/VOICE connect processing will be eliminated. The "|" character adds a carriage return to your string. --- ModemReset - This variable tells VD whether you want to reset your modem before you initialize it. If you want to reset it enter the string you want to send to it like this: ModemReset ATZ| Note the '|' sends a carriage return. --- LogPath - This is the path to your VD Log File where a log of VD's activities are kept. I use: LogPath d:\qbbs\validoor.log --- LogStyle - this allows you to make your log look like an Opus/Binkley or FrontDoor style log. Valid descriptors are: LogStyle BINK LogStyle FD --- ExitInfoPath - another optional descriptor which tells VD where it can find your EXITINFO.BBS file. Requires full path and filename. Default is current directory. ExitInfoPath c:\bbs\exitinfo.bbs --- UserPath - this descriptor is here for VD_Pack to use to find the Users.BBS file. ValidOOR will ignore it. Again a full path and filename is required. UserPath c:\bbs\users.bbs --- UserDir - This is the Path and filename of your User Directory where the names and phone numbers of validated users are stored. This is to make sure that users cannot be validated twice at the same phone number. I use: UserDir c:\bbs\validoor.dir This is an optional feature and may be disabled by commenting it out. --- BadNumber - This is the full Path and filename to your Bad Phone Number Control file. This file is where any phone numbers that ValidOOR senses to be VOICE connects will be written and therefore prevented from ever being dialed by ValidOOR again. If you wish you may use your BBS PHONENUM.CTL file for this, remembering that any numbers that end up in PHONENUM.CTL will never be dialed by ValidOOR. Usage as follows: BadNumber d:\qbbs\badnumbr.ctl BadNumber d:\qbbs\phonenum.ctl If you do not wish to use this feature, simply comment it out. It is optional. --- EditPhone - This allows a user to edit his phone number from within ValidOOR. It has three parameters which do the following: EditPhone 0 Do not allow user to edit phone number EditPhone 1 Allow user to edit phone number EditPhone 2 Allow user to edit phone number & update Users.BBS --- ModemSuffix - This is for modems like the HST which can use a suffix after the phone number to cause a certain type of connection to be made. Comment it out if you don't need it. With my HST I use: ModemSuffix &M4 --- WaitTime - This is the number of seconds to wait before the first attempted call and between each attempted call. I suggest using 10 seconds: WaitTime 10 --- OffHook - This is the string you wish to use to take your modem offhook during the above WaitTime to keep an incoming call from messing up VD's validation attempt. I use this for my HST: OffHook ATH1| --- OnHook - This string puts the modem back on hook after WaitTime before a call is made. I use: OnHook ATH0| --- ValidGoodbye - This is the full path and filename to a text file that you wish to be displayed to the user who has been validated successfully. I use: ValidGoodbye c:\bbs\text\validgb.asc --- InValidGoodBye - This is the path to a text file to be displayed to a user that is not validated successfully. Mine is: InValidGoodbye c:\bbs\text\invaldgb.asc --- LDGoodbye - This file will be displayed to a user when Long Distance calls have been disabled. I use: LDGoodbye c:\bbs\text\ldgoodby.asc --- HitAnyKey - This is for High-Speed modem users who run with the port locked. It places a "Hit ANY Key" at the end of each 'goodbye' file above, so that the user will see all of the file before the modem disconnects. If your port is not locked use: HitAnyKey No If your port is locked use: HitAnyKey Yes --- SlowModem - This descriptor enables commands sent to the modem slowly for modems that cannot respond to an initialization string sent at full blast! Usage: SlowModem On SlowModem Off --- ForeGround BackGround - Color Attributes for Normal Activity Window --- MessageForeGround MessageBackGround - Color Attributes for Message Bar --- StatusForeground StatusBackground - Color Attributes for Status Info --- WindowForeGround WindowBackGround - Color Attributes for Status Window I use these: ForeGround 7 BackGround 0 MessageForeGround 4 MessageBackGround 7 StatusForeground 15 StatusBackground 3 WindowForeGround 0 WindowBackGround 3 --- SecLevel - This is the security level you want to set validated users to: SecLevel 5 If you do not want Validoor to set any levels, then comment out this line. --- AFlag BFlag CFlag DFlag - These descriptors define the bit masks for the user flags. You set them just like you would in your user editor. If you don't want VD to mess with user flags, just comment them out. Using the letter 'n' in place of any bit will cause VD to leave that bit untouched. AFlag XXXX---n % BFlag -------- CFlag X-X-X-Xn % DFlag -------- Above the AFlag and CFlag would be set like above for a user who passes validation successfully. The BFlag and DFlag would not be touched. Bit 8 on both AFlag and CFlag would be untouched by ValidOOR. --- TimeLimit - Use this to set the new time limit for the user after he is validated. TimeLimit 60 would give a newly validated user 60 minutes. This is useful if you let newly validated users back into your system after you call them (on your nickel). Comment this out to disable this feature. --- TwitLine - This can be a line of text displayed to a user you have just 'Twitted' with the <F10> Twit key. TwitLine Please Call some other BBS The default twitline if you don't use this descriptor is: "System Error - Disconnecting..." --- ValidShell - This is used to get your system to run external programs after validating Users. You may have up to 10 ValidShells which are executed in the order they are listed in VD.Cfg. Example below would run the program Postit.Exe ValidShell Postit.Exe -t@UserName -f"Sysop" -mtext.txt NOTE the use of the VDVariable @UserName. ValidOOR will replace this variable with the user's name. See VDVariables section for details: --- UserComment - This will put a comment in the Usersxi.bbs file. It also understands VDVariables. UserComment ValidOOR v@Version at @VD_Time on @VD_Date --- Language - The name of your ValidOOR language file. Use a full path if you are not using the environment variable. The ASC/ANS extension is added so do not put an extendion on it. If not used, ValidOOR will default to VD-LANG. Example: Language VooDoo %%% End of VD.CFG %%% In ALL of the above descriptors the CASE is not significant but it may be in your modem commands depending on your modem. The default filename for your configuration file is VD.CFG. You may also tell Validoor the name of your configuration file on the command line when you run it like this: vd myvd.cfg or vd yourvd.cfg You should NOT include a Path to your vd.cfg on the command line unless you are not using the ValidOOR environment variable. VD_Variables ------------ VD_Variables are output variables that you can use in interfacing VD with the caller as well as the outside world. Generally they work like this. When VD encounters a vd_var it will replace that vd_var with a corresponding piece of data from within ValidOOR. These work in several places in ValidOOR such as in the User Comment field, as well as the ValidShell execution. Some of them are also VERY useful in the language file as you will see when you examine the enclosed language file. There are a total of fourteen vd_vars. They and their functions are listed below: @UserName User's First & Last name Format: Ken Givens @User_Name Same as @UserName except Format: Ken_Givens @Version ValidOOR Current Version @VD_Date Current Date @VD_Time Current Time @LDCode PreDialLDCode from vd.cfg @Sysop SysopName from vd.cfg @VD_EOL inserts CR/LF characters (careful with this) @Home Key for selecting HomePhone from menu @Data Key for selecting DataPhone from menu @Abort Key for selecting Abort ValidOOR from menu @Edit Key for selecting to edit phone number from menu @Yes Key for selecting Yes response @No Key for selecting No response The last few which are selection keys from the menu, etc. are particularly useful in the language file. If you use them there, anytime you change the key definitions in vd.cfg, the new definitions will automatically be plugged into the language file at runtime. This results in less work for you. Interfacing ValidOOR There are several ways you can run ValidOOR on your system. I use a type 40 command in my TOP.MNU with flag D1 set ON (X) to force all new users into the validation menu. After successful validation I set the D1 flag back off (-) and then when they hit TOP.MNU the 1st type 40 command will be ignored due to the flag not being ON and the TOP.MNU will execute normally. I have included my menus in this archive to give you an idea as to how I do it. You can also just use a Type 2 command to let your users access VD that way... it is up to your personal preference as to how you get your users into ValidOOR. Be creative :-). That is why the system has been designed to be so open-ended. Once the user selects ValidOOR, the BBS should exit via type 15 or type 7 EXIT to run ValidOOR. See your BBS documentation for an explanation of Type 7 and 15 Exits. I use a type 15 EXIT to my RunRa.Bat file which then calls my Validate.Bat which I have included here. When the Validate.Bat file runs it loads ValidOOR which then initializes the FOSSIL driver, and does some setup things - reads VD.CFG which you the sysop must set up, and then it looks for EXITINFO.BBS. At this point, if you have opted to use a User Directory File to prevent duplicate phone numbers, VD will check for the existence of this file which it creates if not found. If you comment out the UserDir descriptor in VD.Cfg, no dupe checking will be performed. ValidOOR also creates a log file and appends info to it so you can keep track of it's activities. ValidOOR can be set up to use either the business/data phone number, the home/voice phone number or both phone numbers that the user entered during his initial login depending on how you choose to set up your BBS. You can also optionally allow the user to edit his phone number in two different ways - 1) temporary edit for calling which is not saved, or 2) edit which is saved into the DATAPHONE field in the users.bbs file. If you are going to allow your users to edit their number from within ValidOOR it is highly recommended that you use option 2 and save the edits. This is more secure. ValidOOR will prompt the user to select which of the two numbers his modem is currently connected to and give him an option to abort the process should he so desire. After this selection is made, ValidOOR will ask him if a 1- should be placed in front of the number for a long distance call. If you choose not to let VD make long distance calls, the user will not be called and a file explaining the situation can be displayed (See VD.CFG descriptor LDGoodbye. If Long distance calling is enabled, VD will place the 1- in front of his number and continue with the process. If all files are present and everything went properly, ValidOOR will inform the user that he is about to be validated and display the following line: "Prepare for an incoming call. If your modem will not auto answer, when you see the RING on screen type ATA and hit <Enter>." Then ValidOOR prompts him to hit <ENTER> when he is ready to begin. When the user hits <ENTER> ValidOOR will disconnect him, take the phone off the hook, and wait a pre-defined number of seconds (WaitTime in VD.CFG). The ValidOOR will put the modem back on the hook and call the user at the same baud rate that he used to log into the BBS. The number of "Non-Connect" attempts can be set up in VD.CFG but the system, after one connection is made, will not make another attempt to call. If your modem is capable of sensing a VOICE connect, and your modem initialization string has the proper value sent to it to enable this feature, then when ValidOOR senses a VOICE connection and you have a path in the 'BadNumber' descriptor uncommented, ValidOOR will abort and write this phone number to a BadNumber Control file. Then VD will never attempt to call this number again. You may use your PHONENUM.CTL file in your BBS for this if you fully understand that no one ever be able to use this number to log in to your BBS as a new user again. Using X0 in your Modem Initialization string will totally disable modem result codes and then ValidOOR will ignore all of this entirely. When the connection is successful, ValidOOR will display a brief message something like this: ValidOOR v1.60 and then display the SysName1 and SysName2 messages that you set up in VD.CFG. Next VD prompts the user to enter his password. He gets three tries before ValidOOR gives up and disconnects. An Inactivity timer which is configurable in VD.CFG will disconnect him if he falls asleep. If he fails to enter the proper password (from EXITINFO.BBS) for whatever reason, the system will disconnect him and exit with an errorlevel 2. Your batch file can then process the errorlevel accordingly. An appropriate entry will be written to the log. If he is successful, then ValidOOR will exit with an errorlevel 0. Your batch file can process accordingly. Also an entry will be written into the log file to let you know what happened. If you have selected to do so in VD.CFG, and are running from a type 15 exit, ValidOOR will update the user's security and user flags in the EXITINFO.BBS. NOTE: It is necessary to reload your BBS after VD exits using the command: RA -R in order for the changes in security level and user flags to take place. If you do not reload your BBS the updates will NOT be written to the USERS.BBS file. See my SPAWNBBS.BAT file for an exact example as to how this should be done. Function Keys Some function keys are available to the sysop while a user is online. <F1> - Chat - Pressing this key will put you in Chat Mode with the caller. Hitting <ESC> will exit the chat mode. <F2> - DOS - This key will allow you to shell to DOS via your Comspec variable. Be sure you have set comspec in your environment. <F3> - Twit - This Key will set the callers access level to Zero (0) thus banning him from entering you system forever. VD exits with errorlevel 18. Use this with caution and prudence. <F4> - Abort - This key simply aborts VD and exits with a DOS errorlevel 15. <F5> - HangUp - This key disconnects the user and exits with a DOS errorlevel 16. <F10> - Advertisement - This key interrupts ValidOOR processing with an advertisement. Local Mode ValidOOR has a Local Mode that a sysop can use for testing purposes. You must exit (type 15 or 7) from the BBS (in local) for it to work. VD can tell from Exitinfo.Bbs that you are in LOCAL mode and will react accordingly. While in Local mode, VD will not check to see if the phone number exists in the User Directory file. This will allow you to test as many times as you like without having to delete yourself from the User Directory every time. In local mode, VD will skip the dialing and jump straight to Connection and attempt to validate you. Your phone number will be written into the User Directory if you pass the validation. ERRORLEVELS Several cases will cause ValidOOR to abort with an errorlevel: * absence of any of these files: errorlevel=1 EXITINFO.BBS VD.CFG * User Not Validated errorlevel=2 * SysopName missing in VD.CFG errorlevel=3 * Duplicate Phone Number (in directory file) errorlevel=4 * User Abort at Menu errorlevel=5 * Absence of FOSSIL Comm Driver errorlevel=6 * Long Distance attempt (if enabled) errorlevel=7 * Inactivity errorlevel=8 * Carrier Loss errorlevel=9 * VOICE connect detection errorlevel=10 * Bad Number detected (BadNumber Control File) errorlevel=11 * Bad KEY file errorlevel=12 * Invalid # of Command Line Args errorlevel=13 * User Edited invalid number errorlevel=14 * F4 Abort key errorlevel=15 * F5 Hangup key errorlevel=16 * Beta Copy expired (betas ONLY) errorlevel=17 * Twitted the current user errorlevel=18 * FATAL System ERROR errorlevel=19 * Non-registered User running BETA version errorlevel=20 * If the user is validated successfully, ValidOOR will exit with an errorlevel of 0. These errorlevels are enabled in this release. They are not guaranteed to remain the same in future versions. You can take advantage of these errorlevels by trapping them all in your batch file and using the traps to generate entries in your log to give you a more verbose explanation of what went on.... be creative. You can use them any way you like. Your KEY file The ValidOOR Key file eliminates the 30 second delay at the beginning of the program. You must register ValidOOR in order to get a key from me. I can send the key via FidoNet mail or US Mail (Snail Mail). Please specify which method you prefer when registering ValidOOR. Reporting Bugs If you have a problem with ValiDOOR you should report it immediately to me. When making a bug report, please include the following info in a ZIPPED file: A detailed description of the problem A copy of your VD.CFG file A copy of your log showing the problem if applicable A copy of your UserDir if applicable A copy of your badnumbr.ctl file if applicable Without this info, it will be nearly impossible for me to find the problem. Help me to help you. The best place to report a problem in on my support system listed here: ValidOOR Support The Boot Factory BBS FidoNet 1:264/19 804-262-9289 I also try to read the RA_UTIL echo regularly but that is not guaranteed to be true at any given time. File Requests Magic Filenames for File Requests from 1:264/19 FILES : master download file list F264-019.ZIP NEWFILES : Files less than 30 days old ABOUT : General Info File VDR : latest version of ValidOOR - for RA VDQ : " " " " " QuickBBS VDU : VD_Util for vd.cfg, language and Userdir files The following utils will ONLY work with a key. VDP : VD_Pack - userdir packer for registered users VDC : VD_Create - userdir creator for registered users Credits Thanks to the following individuals: Continental Software - The RemoteAccess folks. Robert Rosanio - who gave me the original idea. Greg Dawson - for teaching me how to access FOSSIL. Mike Janke - for his wonderful Exit code. Jim Whitby - for Documentation and other Help. Ed Greene - for his debugging help and reports. Richard Alfoni - for his debugging help and reports. Tom Meehan - Chief code basher/tester. Ken Givens - Invaluable Suggestions and Help Net 264 - for tolerance. Also Thanks to the Beta Testers.... All of you. Report ALL to: Cabell Clarke 804-262-9289 DATA FidoNet 1:264/19