Renegade-1.19/SOURCE/UNUSED/CHANGES4.TXT

Renegade BBS Enhancements/Bug Fix's:

  1.  Before the posting of a message or uploading of a file
      (Batch/Single), the available drive space was checked to
      ensure adequate space exists according to the system setup.
      This section of the code was duplicated in 3 places.  I converted
      this section to a function reducing numerous lines of code and
      extra variabes whenever it was utilized in the code.

  2.  The copy/move procedures are now combined into one function.
      Variables for failure, no space and success were required
      external to the procedures everytime they were called. Various
      messages to the user/sysop.log were also reported external
      to these procedures.  I also noticed that the move procedure
      called the copy procedure if renaming a file was not successfull.
      Now, no variables are required externally for the function and
      messages to the user/sysop.log are handled internally within
      the copy/move function.

  3.  I noticed that a section of the code for executing file
      transfer's was duplicated in 4 places.  This has been moved to
      a single procedure reducing numerous lines of code and
      variables.

  4.  I noticed that a section of the code for checking the return
      code on file transfer's was duplicated in 3 places.  This has
      been moved to a single procedure reducing numerous lines of code
      and variables.

  5.  The FILES.BBS selected for download during a batch transfer by
      the user now contains this starting entry:

       "(BBS Name) Batch Download File Listing"

      Previously, unlisted files were not written to the above list.
      Now, they are with "[No Description Available]" as the description.
      Also, files in the batch download queue with a bad path download
      path will have "[Bad Download Path]" as the description. These
      additions help account for files selected for Batch DL by the
      user.

  6.  The max dos character field in the protocol editor has now been
      limited to 127 characters (Was 255).  I always thought it was 128,
      however I couldn't type in any more then 127 characters on the
      command line in DOS. Please feel free to check this out for
      yoursele and change you editor accordingly.

  7.  Removed spaces from the file name written to the protocol file
      list for batch downloads.

  8.  The procedure that reads the success/failure codes and file name
      from the protocol temp log has been modified.  The starting
      position of the code and file name is specified in the protocol
      editor.  Assumming you set this up correctly, the success/failure
      code and the filename are copied to temporary strings. The success
      code is compared against the returncode from dos for single
      download/upload protocols or the DLCode specified in the protocol
      editor for batch downloads and the temp log.  This code is not
      utilized for batch uploads, the file is simply checked for existance.
      The temporary file name is compared against the batch queue for
      existance.  Since different protocol programs like dsz, etc utilize
      different log formats, it's impossible to tell the actual length of
      the success code or filename read from the temp log.  RG would simply
      read each string from the starting position and then chop off any
      trailing spaces and compared them as per above.  However, with ZM
      protocol, the file name ends with ",".  Therefore, I changed the
      comparison to look for the success code/filename to a String POS
      procedure rather then String = String.  In local tests (Both Single
      and Batch) it seemed to work without issue, we will see? The way it
      was handled before did not work with ZM protocol.  Hopefully, this
      solves it for all others (assuming you set things up correctly in the
      protocol editor.

      Here's a few things I learned about protocols while editing the
      RG code:

        1.  If you set the option "Codes mean" in the protocol editor
            to "Transfer Successfull", you must specify a return dlcode
            and or ulcode for single protocols of zero.  Zero is hard
            coded into the procedure that executes the protocol.  A
            return code of zero from DOS indicates a successfull result.
            Of course, you could also reverse the above and specify
            "Codes mean" as "Transfer Failed" and specify all possible
            DLCodes/ULCodes as something other then zero.

        2.  If you do not specify a temp log for batch downloads, no
            error checking occurs within RG.  RG assumes the files were
            downloaded and increments statistics, etc.  RG does not create
            the temp log, you must add it to the DL/UL command line. You
            must also specify the proper file name and status starting
            positions within the log for RG to locate them.  Please
            read the protocol document for a description of the log
            entries and then count out the status & filename positions
            for the protocol editor.

            Here's what you need for the ZM protocol:

              1. Specify a Temp Log.
              2. Add -lz%L to the DL/UL Command Line to create a ZM
                 style log.
              3. Set "Codes mean" to "Transfer Successfull".
              4. Set DL/UL Code 1 as Z, Set DL/UL Code 2 as z.
              5. Set "File name" to 22.
              6. Set "Status" to 1.

              OR

              1. Specify a Temp Log.
              2. Add -ld%L to the DL/UL Command Line to create a DSZ
                 style log.
              3. Set "Codes mean" to "Transfer Successfull".
              4. Set DL/UL Code 1 as Z, Set DL/UL Code 2 as z.
              5. Set "File name" to 51.
              6. Set "Status" to 1.

        3.  The temp log is deleted by RG automatically, if you need
            or want a permanent log please specify a UL or DL Log.

            NOTE:  I realize some of you may know all there is to know
            about protocols and how they are handled by RG.  However,
            some do not.  Remember, if you do not specify all the above,
            your files will be transferred without error checking and
            statistics will not be updated.  Of course, you could forgo
            the above setup and RG will assume all files tranferred
            successfully.

        4.  Using the above setup may or may not work with currently
            released versions of RG or all external protocol programs.

Please feel free to drop me an email if you require any further
explanation of the above!

Enjoy!!!