HINTS
                         (Some additional information)


     þ Place the executable and the config file in your path. That will
       insure that you will be able to call FDSecure from any directory
       or sub-directory at any time. This is especially usefull when
       you are using the query mode, such as FDSECURE <FileName>.

     þ FDSecure's internal code for moving a file to another directory
       is very good. I would suggest using it over an external program
       because it uses less memory, and is integrated. You can, however,
       in place of EXTERNMOVE <ProgramName> <DPN> <DPN>, you could put a
       batch file there, and the two parameters would become %1 and %2
       in your batch file. i.e. EXTERNMOVE <Filename.bat> <DPN> <DPN>.
       The first being FROM and the second being the TO fields.

       If you use the internal move code, FDSecure has the ability to
       detect if a file cannot be moved. i.e. an improper directory was
       specified or the directory name has changed. If this should happen,
       FDSecure will rename the file to have the extension of .BAD. It
       will then proceed to write you a message as normal except it will
       tell you that a problem occured in moving a file, and it suspects
       an improper directory or something. Obviously FDSecure cannot
       provide you with this protection when you use an external program
       since it has no way to determine what errorlevels are returned from
       the other program, and what the intention of the sysop is with the
       file(s).

     þ Check your FrontDoor log file. FDSecure will log anything that
       happens in there as well as any errors if it should encounter them.

     þ If you are having problems with FDSecure reading the config file,
       then first make sure the config file is called FDSECURE.CFG. If you
       have it under a different name, then you must use the /C option
       to tell FDSecure you are using a different config file.

     þ Max security feature. If a file appears in your inbound directory
       and is NOT listed in your FrontDoor Log file, and is listed as a
       target file in your FDSecure Config file, FDSecure will move it and
       the netmail message will say the file came from -unknown- origin.
       This gives you a little added security. FrontDoor presently does
       not log partial transfers. Therefore, if you were to start recieving
       your Nodediff from your Hub, and the transfer was interrupted at
       60% transferred, then your batch file would see the nodediff file
       in your inbound directory and attempt to process it. This may or
       may not be a problem for some. FDSecure would see the file, check
       the log, and by not finding the file in the log, would move it to
       your bad directory-- thus avoiding a potential computer hiccough.
       This can be disabled by commenting out the Move_Unlisted feature
       in the config file. Commenting this out will tell FDSecure to
       ignore target files in which FDSecure can't tell where they came
       from.

     þ If Fdsecure appears to not be reading the Log file correctly, be
       sure and check your level of verbosity in the log. FDSecure
       needs the information in lines preceeded by a plus (+). This
       is the minimum level of verbosity required. Additionally, FDSecure
       will use the information provided by the tilde (~) level for extra
       information when reporting findings from the log. Obviously, the more
       files you check for, and the greater the size of your log file, will
       have a proportional effect on FDSecure's speed. But, no matter how
       many entries or filenames you are looking for, FDSecure will only
       have to read your log file one time.