home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / BBS_UTIL / BM0406_A.ZIP / DOCS.ZIP / BTCH174.DOC < prev    next >
Text File  |  1993-03-30  |  19KB  |  378 lines
  1.  
  2.                                  BU174v54.ZIP
  3.  
  4.                       (c) 1992,1993 by Richie Molinell
  5.  
  6. Date: 05/15/92 -      - for RBBS v17.3c - BTCH173C
  7. Date: 06/27/92 - v1.0 - for RBBS v17.4
  8. Date: 07/27/92 - v2.0 - for RBBS v17.4 - complete revamp - see notes *
  9. Date: 07/31/92 - v3.0 - not released to public - "/HS" switch for bidirectional
  10.                         transfer installed
  11. Date: 08/02/92 - v3.1 - not released to public
  12. Date: 08/04/92 - v3.2 - not released to public
  13. Date: 08/28/92 - v3.3 - had bug with dropped carriers
  14. Date: 08/29/92 - v3.4 - All commands from command line - BiDirectional Transfer
  15.                         determined by protocol selected!
  16. Date: 08/30/92 - v3.5 - fix for DSZ and lower case file names
  17. Date: 10/15/92 - v3.6 - fix for AutoLogoff with BiDirectional Transfer
  18. Date: 10/24/92 - v3.7 - fix for local upload/abort,categorizing and ext desc
  19. Date: 10/28/92 - v4.0 - fix for v3.7 & DIZ support
  20. Date: 11/08/92 - v4.1 - fix for Personal files stacked for download
  21. Date: 11/15/92 - v5.0 - added ability to reject duplicate additional files
  22. Date: 12/10/92 - v5.1 - fixed local upload oops and VCHKx file bug in RBBS
  23. Date: 02/23/93 - v5.2 - automagically removes high/low ASCII from FILE_ID.DIZ
  24. Date: 03/29/93 - v5.3 - not released to public
  25. Date: 03/30/93 - v5.4 - minor bug fix and upgrade for RBBS v17.4a/031293
  26.  
  27. One great drawback to the files system in RBBS is it's inability to allow true
  28. batch uploads.  It's system of taking one file at a time and then asking for
  29. the description only saves the user the keystokes of entering the file name
  30. just before each upload.  This tends to discourage users from uploading since
  31. they can not set up a batch upload, set to auto logoff and leave their machine
  32. unattended during the transfer.
  33.  
  34. Hence, this merge.  This merge installs true batch uploading with RBBS.  It has
  35. been tested using DSZ and ZSX and is known to work with both of these.
  36.  
  37.  
  38.                               July 27, 1992
  39.  
  40. The Batch Upload mod now takes all parameters from the command line.  Users can
  41. enter all files to upload, the transfer protocol (if desired) and the "/G" if
  42. they wish to Auto-Logoff on the same command line.  RBBS will check to see if
  43. the file already exists, prompt for descriptions, complete the transfer and
  44. update the directories.  The user will be logged off after 30 seconds if they
  45. select the Auto-Logoff feature.
  46.  
  47.  
  48.                               Sept. 1st, 1992
  49.  
  50. This is the version everyone is waiting for!  This version allows batch
  51. uploading with any protocol which permits it.....EVEN BiDirectional TRANSFERS!!
  52. A Sample PROTO.DEF file is included for reference.  The user is able to select
  53. a "High Speed" protocol, tell the system which files he/she wants to download,
  54. tell the system the files he/she wants to upload, give descriptions and
  55. transfer files to and from the system at the same time.  As long as you tell
  56. the protocol to create a DSZ log, the system will check for files that the
  57. user may have uploaded, without telling the system.  If any files are found
  58. that the system was not informed about before hand, the user will be prompted
  59. for the descriptions and, optionally, if the user security level permits, the
  60. category for the files.
  61.  
  62. Setup is pretty straightforward.  You must place an "H" in the 5th position in
  63. your PROTO.DEF file when installing the protocol.  Yes, this is the same
  64. position that you would place an "R" if the protocol were to require a reliable
  65. connection.  Next, there is a new parameter that RBBS is able to pass to
  66. protocols...that being UPDIR.  This new parameter is the location of the upload
  67. directory for the conference.  This parameter is passed to the protocol just
  68. like any other (BAUD, CBAUD, FILE, PORT#, etc.).  A sample line for HSLink
  69. would be:
  70.  
  71. "H)SLink (BiDirectional)
  72. ",5,S,8,H,B,1024,,0.95,,1=E,"C:\RBBS\XFER\HSLINK.EXE -P[PORT#] -E[CBAUD]
  73. -U[UPDIR] [FILE]","C:\RBBS\XFER\HSLINK.EXE -P[PORT#] -E[CBAUD] [FILE]
  74.  
  75. You must have either the enviroment variable "SET DSZLOG=XFER%node%.DEF" set
  76. or tell the protocol to create a DSZ type log named XFER%node%.DEF (%node% is
  77. the number of the node) located in the same directory as the RBBS-PC.EXE file.
  78. This log is necessary to check if any additional files have been uploaded
  79. besides the files that the user told the system.
  80.  
  81. PLEASE BE ADVISED:  You are passing the upload directory to the sending
  82. protocol...the user can upload many files without telling you before hand!
  83. Without the DSZ log, there would be no way of telling.  The system will
  84. prompt the user for the information...and if the user drops carrier, it will
  85. write out >>> Description Unavailable <<< to let you know that there was no
  86. prior notification!
  87.  
  88. This safety feature will work with all protocols which permit batch uploading
  89. (DSZ, ZSX, etc) and create a DSZ type log.
  90.  
  91. With this version of batch uploading, all commands are taken from the command
  92. line as with stock RBBS.  The user can stack the files to upload along with
  93. the protocol and the "/G" for auto logoff.  The user can even set the
  94. bidirectional protocol as his/her default protocol.  The internal protocols
  95. (Xmodem, Ymodem and ASCII) function properly as well.
  96.  
  97. When using a bidirectional protocol, the user is credited with the upload
  98. time at the rate the SysOp has preset in CONFIG param 10.  Naturally, this
  99. time will be credited against the download time if it is longer than the
  100. upload time.  If the Sysop has CONFIG param 10 set to 0 then no credit will be
  101. given.  If 1, the user time stands still ONLY for the upload, 2, the user will
  102. get credit for extra time equal to the upload, etc.
  103.  
  104. All statistics concerning number of files transferred will be updated.  The
  105. user will get credit for uploaded files and downloaded files.  The same holds
  106. true for byte counts.
  107.  
  108. This mod has been tested with HS-Link.  It should work with any bidirectional
  109. protocol requiring the upload directory be passed, the file names to be
  110. downloaded passed and the DSZ log file to be checked for any additional files.
  111.  
  112. Files created by this modification are:
  113.  
  114. NODE%node%FDN       -  List of files for downloading by the user.
  115. NODE%node%FUP       -  List of files for uploading by the user.
  116. NODE%node%FUP.LST   -  List of files, descriptions, and categories for files
  117.                        to be uploaded.
  118.  
  119. * %node% is the node number
  120.  
  121. These files will reside in your node work directory.
  122.  
  123. If a malfucntion of your system should cause the system to crash, these
  124. files may still exist.  These files should be erased automatically on the next
  125. transfer.
  126.  
  127.  
  128.                               Oct. 15th, 1992
  129.  
  130. There was a bug with the BiDirectional transfer and the auto logoff when
  131. initiated from an Download.  This was pointed out by Geoffrey Nolasco of the
  132. MegaMixers BBS in Wheaton, MD. (301-949-0183).  While searching for the
  133. cause, I found some redundant code which is now removed.  The Auto Logoff
  134. now works properly with all batch uploads, downloads, and bidirectional
  135. transfers.  The new code is more efficient with the removal of the "extra"
  136. code.  Once again, thanks Geoffrey.
  137.  
  138.  
  139.                               Oct. 24rd, 1992
  140.  
  141. Found a minor bug when doing local upload and describing an existing file.
  142. If you entered "ABORT" to abort the description, the system would crash with
  143. an error in RBBSSUB5.BAS.  This is now fixed.
  144.  
  145. Decided to clean up the sequencing a bit.  If security permits, you will no
  146. longer be asked to categorize and upload if it is a personal upload.
  147.  
  148. If security permits, you will no longer be asked if you wish to leave an
  149. extended description on a personal upload.
  150.  
  151. Minor bug with an occasional file being written to the wrong directory
  152. when doing a personal upload is now fixed.
  153.  
  154.  
  155.                               Oct. 28th, 1992
  156.  
  157. Introduced major bug in v3.7 due to the different ways RBBS handles uploads
  158. from local to remote.  I only tested locally (oops!) and missed the fact that
  159. remotely the system would crash on uploads due to the fact that the user
  160. wasn't asked who the file was to before asking to categorize or leave an
  161. extended description.  This only occurred if you had the security
  162. level set to permit users to make personal uploads and categorize uploads.
  163. I moved the SetWhoTo call into the UpdtUpload routine so both local and remote
  164. uploads follow the same sequencing.  This fixed the major bug introduced and
  165. permitted the elimination of asking the user to categorize a personal upload
  166. and leave an extended description on personal uploads (if security level
  167. permits).
  168.  
  169. With this version, support for FILE_ID.DIZ and DESC.SDI files is introduced.
  170. The RBBS software, in conjunction with the archive test file (ie: TZIP.BAT,
  171. TARJ.ZIP, etc.), will now replace the users description of a file with the
  172. description written by the author.  This is accomplished by copying the
  173. description file to the node work directory as a file named NODExDIZ (where
  174. x = node number) during execution of the test file.  You will need to add
  175. 2 lines to your test file similiar to:
  176.  
  177. ...
  178. IF EXIST <path1>\FILE_ID.DIZ COPY <path1>\FILE_ID.DIZ <path2>\NODE%node%DIZ
  179. IF EXIST <path1>\DESC.SDI COPY <path1>\DESC.SDI <path2>\NODE%node%DIZ
  180. ...
  181.  
  182. with <path1> being the path of your testing directory and <path2> being the
  183. path to your node work directory.  I have included a sample of my TZIP.BAT
  184. file which I use for testing xxx.ZIP files.  On completion of a successful
  185. upload RBBS will look to the node work directory for the NODExDIZ file, and
  186. if found, import the text contained within as the file description.  You will
  187. have to modify all your test files to copy the description files to the node
  188. work directory.
  189.  
  190. Another file will now be found in your Node Work Directory.  The name of this
  191. file is:
  192.  
  193. NODE%node%DIZ       -  Description of file copied from FILE_ID.DIZ or
  194.                        DESC.SDI
  195.  
  196. This file will be erased on the next upload if it remains for any reason.
  197.  
  198.  
  199.                               Nov. 8th, 1992
  200.  
  201. Found another bug.......hopefully the last!  If you entered "P" from the files
  202. menu and stacked personal files for download, when prompted for a protocol the
  203. system would go into a loop if you selected "N" to abort.  If you then
  204. selected a protocol (to exit the loop), the system would create, and send a
  205. bogus 0 byte file.  This is now fixed.
  206.  
  207.                              Nov. 24th, 1992
  208.  
  209. Additonal files are those files uploaded during a batch upload which the user
  210. did not tell the system were coming.  The system will automatically detect
  211. these files through the DSZ log.  Prior to this version, the additional files
  212. were not checked to see if they duplicated files on the system.  The system
  213. just prompted the user for the description and treated the files like any other
  214. uploaded file.  Now these additional files will be checked just like the check
  215. prior to uploading, and, if found to be duplicates, they will be erased and
  216. all credit removed.  This was added for protocols like DSZ and ZSX which, while
  217. allowing batch transfers, do not check for a list of directories to search for
  218. duplicates like HS-Link or BiModem will.  You should make sure that the
  219. protocol will not allow overwrites so if a file exists in the upload directory
  220. they will be refused.  The combination of the two, will insure any files
  221. uploaded, will not be duplicates.
  222.  
  223. The batch upload mod now has additional files which pass the screening
  224. become personal uploads to the SysOp if the user should drop carrier right
  225. after the upload process.  This allows the SysOp to check these files before
  226. posting to the general users of the board since the carrier drop might be
  227. intentional (for whatever reason).
  228.  
  229. RBBS now uses only one archive test file named TEST.BAT.  RBBS will pass the
  230. file extension to this test file as %6.  You no longer need those half dozen
  231. test files hanging around in your root directory.  RBBS now passes the
  232. communication port (as COMx) to this TEST.BAT file for processing.  This makes
  233. it fairly simple to use ECHO statements to the user since you only need one
  234. statement on multinode systems.  Look at the enclosed TEST.BAT file for
  235. reference.  I run a two node system, so I don't need to check which node is
  236. testing to determine which port to send my messages out.  This new parameter is
  237. passed as %3 to the batch file.
  238.  
  239. RBBS will also pass the users first name (%4) and last name (%5) to your
  240. archive test file.  This means you can display messages that appear to be
  241. custom by incorporating the users name into the message.
  242.  
  243. Summary of parameters that RBBS will pass to the archive test file:
  244.  
  245.    %1 - The name of the file to be tested - stock in RBBS
  246.    %2 - The file to which you write out a failure string - stock in RBBS
  247.    %3 - The communications port in use - new
  248.    %4 - users first name - new
  249.    %5 - users last name - new
  250.    %6 - file extension - new
  251.  
  252. Please be advised that with the passing of these additional parameters, you
  253. may have to increase your enviroment size to accomodate the added length.
  254.  
  255. This version of BTCH174 also contains the NE174V10 (NEXT174) mod.  If you wish
  256. to disable this feature, you can either remove the lines commented with
  257. ' NEXT174 or do nothing.  The modification will be ignored if the NOEXT.DEF
  258. file does not exist.  See the NEXT174.DOC for information about this mod.
  259.  
  260.                              Dec. 10th, 1992
  261.  
  262. I had built upon existing merge files and when typing in the changes from
  263. the previous version, typed in a line in RBBSSUB5.BAS which caused local
  264. uploads to crash with a Divide by Zero error.  Sorry!  Fixed in this version.
  265. (Was hoping not to have a 5.x version).  Anyways, while I was at it, I decided
  266. to fix a bug in RBBS whereby the node VCHKx file isn't erased and can cause
  267. subsequent uploads after a bad upload to be considered bad and removed by the
  268. system if they are untested (by SysOp choice).  The "old" VCHKx message is
  269. read and the system determines that the upload was bad.  The system will now
  270. erase the VCHKx file if it indicates that an upload is unacceptable thereby
  271. eliminating subsequent files from being removed.
  272.  
  273.                              Feb. 23rd, 1993
  274.  
  275. Now automagically removes high/low ASCII from FILE_ID.DIZ and DESC.SDI files
  276. for importing into your RBBS files directory.  Plug and play with prior
  277. version.
  278.  
  279. *****************************************************************************
  280.                               Mar. 30th, 1993
  281.  
  282. Minor bug fix for single file bidirectional transfer abort and asking for
  283. extended description if allowed.
  284. Also, upgraded for RBBS v17.4a/031293 mods with installation of RFIX0312
  285. from Ken Goosens.
  286.  
  287. *****************************************************************************
  288.  
  289.  
  290. As with all my merges, my recommendation is to istall this modification by hand
  291. if you have installed any other merge(s) which may have accessed any of the
  292. lines used by this merge.  If you so decide, you may install this merge using
  293. Ken Goosens BLED v2.2.  A batch file is included to assist you with BLED.
  294. Simply copy the files in this archive to a directory, copy your RBBS v17.4
  295. source code to the same directoy, copy BLED v2.2 to this directory and run
  296. the enclosed batch file.  The old .BAS files will be renamed to .OLD and the
  297. new files will be renamed to .BAS.  You can then replace your RBBS-VAR.BAS file
  298. with the one enclosed in this archive, and using the new source files,
  299. recompile.
  300.  
  301. Files included in this archive are:
  302.  
  303.                         R-PCBTCH.MRG - Mod for RBBS-PC.BAS
  304.                         RSB1BTCH.MRG - Mod for RBBSSUB1.BAS
  305.                         RSB3BTCH.MRG - Mod for RBBSSUB3.BAS
  306.                         RSB4BTCH.MRG - Mod for RBBSSUB4.BAS
  307.                         RSB5BTCH.MRG - Mod for RBBSSUB5.BAS
  308.                         RBBS-VAR.NEW - Replacement RBBS-VAR.BAS file
  309.                         BTCH174.BAT  - batch file for BLED v2.2
  310.                         BTCH174.DOC  - this document file
  311.                         PROTO.REF    - PROTO.DEF file for reference
  312.                         TEST.BAT     - sample archive test file
  313.                         FD.HLP       - Download Help file
  314.                         FU.HLP       - Upload Help file
  315.                         FILE_ID.DIZ  - Description of this ZIP archive
  316.                         NEXT174.DOC  - document file for NEXT174
  317.                         NOEXT.DEF    - sample file for NEXT174
  318.  
  319.  
  320. Have fun and let me know how things work out.
  321.  
  322.    Richie Molinelli
  323.   The Small Time BBS
  324. Runnin RBBS v17.4a/STUNY
  325.  1200 thru 14400 bps
  326.     516-579-7929
  327.  
  328.  1:107/272@fidonet
  329.  8:954/272@rbbsnet
  330. 10:110/3@busilink
  331.  
  332. LEGALITIES:
  333.  
  334. RBBS is Copyright (c) 1986,1992 by D. Thomas Mack
  335.  
  336. BTCH174 and BU174Vxx merge is Copyright (c) 1992,1993 by Richard Molinelli.
  337.  
  338. This mod is for personal use by the SysOp.  This merge can not be used in part
  339. or in whole in any package without prior written permission from the author.
  340. To do so would be in violation of the copyright laws of the United States.  This
  341. merge can only be included in stock "RBBS" as released by the RBBS development
  342. team, the HSLink package as distributed by Samuel Smith, the STUNY mods released
  343. by Richie Molinelli and Gary Glueckert, and it's own package labeled BU174Vxx
  344. (the xx being the version number).
  345.  
  346. This merge is to be distributed in it's own, freestanding file.  It is
  347. forbidden to distribute this merge in any modified form.  It is forbidden to
  348. distribute this merge bundled with any merge package other than the
  349. aforementioned packages.
  350.  
  351.  
  352. WARRANTY AND DISCLAIMER:
  353.  
  354.           Simple.  None.  Narda. Zip. Nothing.  I am not responsible for any
  355. damage that occurs by using this merge nor am I responsible for any good that
  356. occurs from using this merge.  I'm just plain not responsible.  My mother has
  357. been telling me that since I was a kid.
  358.  
  359.  
  360. REGISTRATION:
  361.  
  362. None required!
  363.  
  364. If you are the author of a program, please consider u/l a registered copy of
  365. your program to my BBS.
  366.  
  367. If you are the author of a merge, please consider u/l a copy of your merge to
  368. my BBS.
  369.  
  370. If you are neither of the above, please consider sending me a postcard to the
  371. address listed below telling me how you love/hate/don't care about the merge.
  372. I happen to like postcards.
  373.  
  374. Richie Molinelli
  375. P.O. Box 961
  376. Levittown, NY  11756
  377.  
  378.