home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / RA / BW302_RA.ZIP / WHATSNEW.302 < prev   
Text File  |  1994-01-21  |  22KB  |  483 lines
  1.  
  2.               The Blue Wave Offline Mail Door for RemoteAccess
  3.                                    v3.02
  4.  
  5.                    Upgrade and New Feature Documentation
  6.                 Copyright (C) 1993 by Cutting Edge Computing
  7.                             All Rights Reserved.
  8.  
  9.  
  10.  
  11.  
  12.   This information is provided for those people who are familiar with
  13.   previous versions of the mail door, and who do not care to comb the full
  14.   documentation to find what has been added or changed since the last
  15.   release.
  16.  
  17.   However, if you are unsure of how to use a feature that is described
  18.   here, consulting the appropriate section in the full documentation
  19.   (BWMAIL.DOC) will be necessary.
  20.  
  21.  
  22.  
  23.   INSTALLATION
  24.   ------------
  25.   Please read the file INSTALL.302, which was enclosed in the original
  26.   distribution archive (BW302_RA.ZIP).
  27.  
  28.  
  29.   This version of The Blue Wave Mail Door is being distributed with a file
  30.   called BWDOOR.USE.  This is an ASCII file that explains the use of The
  31.   Blue Wave Mail Door, what each item on the configuration menu does, how
  32.   to use The Blue Wave Bundling Commands, and more.  This is an excellent
  33.   tutorial for new users to the mail system.  It is suggested that this
  34.   file be placed online for your users to download.
  35.  
  36.  
  37.   FIXES SINCE v3.01
  38.   -----------------
  39. * The mail door would not properly locate all new messages in Hudson
  40.   message areas if the message base was not sequentially numbered.  (A
  41.   -renumber parameter was not given to RAMSG after messages had been
  42.   deleted).
  43.  
  44.  
  45. * If a user somehow managed to change the PRIVATE status bit in an upload
  46.   packet, the door was not forcing the correct status on the message.  For
  47.   example, if area #1 was configured for Private Messages Only, and the
  48.   user uploaded a message to area #1 without the private flag set, the
  49.   message would have been flagged as public.  The door now forces the
  50.   correct status bit on the message.
  51.  
  52.  
  53.  
  54.  
  55.   WHATS NEW SINCE v3.00
  56.   ---------------------
  57. * Added a check to see if v3.x of the mail door was installed on a version
  58.   of RemoteAccess not compatible with this mail door.  Many people have
  59.   tried installing this mail door on RA v1.x systems.
  60.  
  61.   If the size of the MESSAGES.RA file is not evenly divisible by the size
  62.   of the v2.x MESSAGES.RA file structure, a message is sent to the screen
  63.   informing the sysop that it is either not a RemoteAccess v2.xx compatible
  64.   MESSAGES.RA file, or the file has somehow been corrupted.
  65.  
  66.  
  67. * Added a new command line parameter to the door:  /L<locked_bps_rate>.
  68.   When using the /FAST or /DIRECT command line parameters for the mail
  69.   door, the internal protocol driver needs to know the locked port speed of
  70.   the current communications port.  Without this information, the internal
  71.   protocol driver will not function correctly.
  72.  
  73.   If it has been necessary for you to use the /FAST or /DIRECT command line
  74.   parameters for the internal protocol driver (most of the time necessary
  75.   when running the software in a VDM under OS/2), passing the locked port
  76.   speed to the mail door with /L38400 (or your port speed) will solve
  77.   troubles you may have had.
  78.  
  79. * When "Extended Information" is turned ON from the door's configuration
  80.   menu, ^a Fidonet Kludge Lines will now be passed to the reader when
  81.   downloading from a JAMmed message area.
  82.  
  83.  
  84. * Added a bps rate of 21600 to the available Limits and Maximums editor
  85.   in the BWUTILS program and the mail door.
  86.  
  87.  
  88. * In the BWUTILS program's User Area Editor, you can now explicitly set
  89.   the download status of the listed message areas to "Personal Only" and
  90.   "Personal + "All"" status.  v3.00 did not support this feature, and could
  91.   sometimes mess up these settings when editing a user's active message
  92.   areas.
  93.  
  94.  
  95. * Added OS/2 DOS-box detection to the internal protocol driver, making the
  96.   driver less CPU intensive when running the BBS and mail door in an OS/2
  97.   DOS Session.
  98.  
  99.  
  100.  
  101.  
  102.   FIXES SINCE v3.00
  103.   -----------------
  104. * The "Do Not Bundle Messages Written by Me" option did not always work
  105.   correctly.
  106.  
  107. * Lastread pointers were not always read/updated correctly when working
  108.   with the Hudson Message Base.
  109.  
  110. * A pointer (memory) problem with the NEWFILES scan was fixed.
  111.   Additionally, file description limits have now been increased to 50 lines
  112.   per file, since people have complained that 20 was not enough (!?!).
  113.  
  114. * Worked on improving the speed of the NEWFILES scan.  Sorry folks, but
  115.   I can't make it any faster than it is in this new version.  It should be
  116.   somewhat faster than the v3.00 release code, but not a whole lot.
  117.  
  118. * Netmail destination addresses that contained the same ZONE and NET number
  119.   (ie: 1:1/31 or 2:2/17) were not being found properly during nodelist
  120.   lookups.
  121.  
  122. * Point entries in NODECOST.CTL (RemoteAccess's nodelist costing control
  123.   file) were not being found properly, resulting in netmail to a point of a
  124.   certain node being charged the same number of credits as mail to the BOSS
  125.   of that point.
  126.  
  127. * Garbage in the string "Area #nn is forced, and cannot be modified" when
  128.   a user tries to modify a forced message area with bundling commands has
  129.   been fixed.
  130.  
  131. * If a bidirectional protocol was used to upload a reply packet in
  132.   conjunction with the "/d /logoff=c" command line parameters, the door
  133.   would perform a countdown or instant logoff without first checking to see
  134.   if any replies were uploaded during the mail download.
  135.  
  136. * Maximum uncompressed packet sizes (when set from the CONFIGURATION MENU
  137.   of the door) did not work properly in local mode.  Additionally, BWUTILS
  138.   was displaying an incorrect value for the max packet size (it was
  139.   multiplying the number by 1000, when it should not have been).
  140.  
  141. * Setting DEFAULT NETMAIL BITS in the BWUTILS->Security/Netmail manager
  142.   didn't work on all systems properly.
  143.  
  144. * Apparently, non-US keyboards had trouble with the '@' keypress needed to
  145.   toggle upload information logging in the BWUTILS->Options and Toggles
  146.   editor.  The keypress has been changed to a 'U'.
  147.  
  148. * The BWUTILS PURGE command was broken in the v3.00 release.
  149.  
  150. * The internal protocol driver in the door will no longer create/append to
  151.   a DSZ-style log file so that uploads through RemoteAccess work properly
  152.   when using external protocols.
  153.  
  154.  
  155.  
  156.  
  157.  
  158.   CHANGES MADE IN VERSION 3.00
  159.   ----------------------------
  160. * The mail door is now fully JAM compatible.
  161.  
  162.  
  163. * Messages downloaded from Hudson Message bases will now appear in the
  164.   reader with a date format of "DD Mmm YY  HH:MM", as in "01 Nov 93  12:01"
  165.   in order to be more friendly to non-American date style users.
  166.  
  167.  
  168. * All of the security levels that were defined in BWUTILS (Sec/Flags to
  169.   send CRASH mail, etc.) can now have RA-style "NOT" flags.  In BWUTILS, a
  170.   "-" in a flag field means the flag is disabled.  An "X" in the field
  171.   means the user must have the flag, and an "O" means that the user must
  172.   NOT have the flag.  In addition, the mail door uses RA's "NOT" flags when
  173.   determining user access to message/file areas.
  174.  
  175.  
  176.  
  177. * Before giving a user access to any message/file area, the mail door will
  178.   check the Minimum Age required for access, and deny anyone that is either
  179.   not old enough or who does not have a birth-date entered in the user
  180.   record.
  181.  
  182.  
  183. * Due to popular demand, you may now give a more complete description of
  184.   each archiver that you have configured in the door.  Many people needed a
  185.   way to distinguish between PKZIP v2.04 and v1.10.  You can now enter a
  186.   long description for each archiver through the BWUTILS->Archiver
  187.   Configuration Editor.  This long description will be displayed when users
  188.   choose/change archivers within the door.
  189.  
  190.  
  191. * A new option on the door's configuration menu:  N)ew File Listings in
  192.   Packets.  Users have the option of setting this option to YES, NO, or
  193.   COLOR.  If the user chooses NO, no new file listing will be sent in the
  194.   download packet.  If the user chooses YES or COLOR, the door will scan
  195.   for new files since their successful mail download.  The door will
  196.   include ANSI sequences if COLOR is turned on.
  197.  
  198.   Some things to keep in mind about the new file list scanner:
  199.  
  200.   a)  RemoteAccess stores an "Upload" date with the file.  Therefore when
  201.       users receive a new file listing from the door, the file date
  202.       displayed may be "old" in comparison with their last mail download
  203.       date.  This is NORMAL behavior.  In actuality the file is a new
  204.       UPLOAD since their last login.
  205.  
  206.   b)  Areas defined in your FILES.RA file with the "New" flag set to OFF
  207.       will NOT be scanned for new files, in the same way that RemoteAccess
  208.       will not scan the file area.
  209.  
  210.   c)  All of RA's SECURITY, FLAGS, "NOT" FLAGS, and AGE are supported in
  211.       the file areas.  If a user does not have access to a file area within
  212.       RA, the door will not even bother to scan the area for files.
  213.  
  214.   e)  The door creates the new files list in a file called NEWFILES.BW.
  215.       You do *not* need to put NEWFILES.BW as one of the "reader files" in
  216.       the BWUTILS->General Information Editor.
  217.  
  218.   f)  All file listings generated by the door include the file name, file
  219.       size, file date, and the full description.  The door will "wrap" long
  220.       file descriptions, up to 20 lines.
  221.  
  222.  
  223. * The entire "message upload" portion of the mail door has been rewritten.
  224.   You will probably notice a big increase in speed.  The display while
  225.   tossing uploaded messages has also been changed to be more informative.
  226.  
  227.  
  228.  
  229. * Duplicate message detection has also been overhauled.  The door will now
  230.   use a file called BWDUPES.IDX to store duplicate message information.
  231.   You can safely delete the old duplicate detection file (BWDUPES.DAT)
  232.   after installing the new version.
  233.  
  234.  
  235.  
  236. * In the BWUTILS->General Information Editor, you will notice that each
  237.   of the 5 "reader files" are now configurable by Sec. Level and flags.  If
  238.   a user does not have sufficient access to a reader file, the door will not
  239.   send it.  This will allow "custom" welcome screens by security level to
  240.   be passed to the reader.  By default, each of the reader files have been
  241.   assigned "0" security level access with no flags required.
  242.  
  243.   In order for you to edit the Sec/Flags on the reader file, you need to
  244.   first edit the name of the file (type any character in the field).
  245.  
  246.  
  247.  
  248. * BWUTILS now has a new menu item - The "Limits and Maximums" editor.  For
  249.   each BPS rate that your system supports, you can now define 2 limits on
  250.   the amount of mail that is packed by the door.  It is important to
  251.   understand how each limit works:
  252.  
  253.   MAXIMUM UNCOMPRESSED PACKET SIZE is the largest mail packet size
  254.   (uncompressed, obviously!) that a user at a certain BPS rate may
  255.   download.  Some may find this useful if they bundle messages (have their
  256.   WORK directory pointed) to a RAMdrive.  For example, I have a 2 meg
  257.   RAMdrive configured as the door's WORK directory on my system.
  258.   Therefore, I have all of the BPS rates configured for 1800K uncompressed
  259.   packet size to ensure there is always enough room to complete a
  260.   successful packing session.  If you do not care how large the
  261.   uncompressed packets are for any particular BPS rate listed, simply set
  262.   the field to -1.  This will cause the door to have no set limit (other
  263.   than disk space).
  264.  
  265.   MAXIMUM NUMBER OF MESSAGES obsoletes the old "overall Maximum Messages"
  266.   setting the door had.  The door enforces the maximum number of messages
  267.   per BPS rate, just as with the MAXIMUM UNCOMPRESSED PACKET SIZE.  If you
  268.   wish to set no limit for the maximum number of messages, simply enter
  269.   "-1" in the field.  The door will not enforce a limit for that particular
  270.   BPS rate.
  271.  
  272.   There is an important difference in the way these two limits work.  "MAX
  273.   MSGS" limits are enforced BEFORE any bundling of the messages takes
  274.   place.  The user must use the bundling commands to trim the size of their
  275.   mail packet before proceeding with a mail bundling session.  "MAX PKT
  276.   SIZE" is enforced DURING bundling.  If at any time during bundling the
  277.   door reaches the maximum packet size limits, it immediately halts the
  278.   bundling process and compresses the mail packet for the user to download.
  279.  
  280.  
  281. * In the LIMITS AND MAXIMUMS editor, you can tell the door whether or not
  282.   you will allow NEW FILE scans to take place.  If this is set to "NO",
  283.   users will not be given the option on the door's CONFIGURATION menu to
  284.   create newfiles lists.
  285.  
  286.  
  287. * In the LIMITS AND MAXIMUMS editor, you can define the maximum number of
  288.   days to "look backwards" to find new files.  If a user has not logged
  289.   into your system for 6 months, you (most likely) do not want them
  290.   receiving a NEWFILES listing containing the last 6 months worth of new
  291.   files.  You can control the maximum number of days to include in the file
  292.   list by editing this field.  A good number to use here is probably
  293.   somewhere between 10 and 30 days.
  294.  
  295.  
  296. * Previous versions expanded "%T" in pathnames to the hexadecimal task
  297.   number that was passed to the door.  This is still true, but you can now
  298.   use a "%N", which will expand to the DECIMAL task number passed to the
  299.   door.
  300.  
  301.   Assuming you have a download directory defined as "C:\MAX\BW\DOWN%T"
  302.   Example of door running as task 10, expands to "C:\MAX\BW\DOWN0C".
  303.   Example of door running as task 1, expands to  "C:\MAX\BW\DOWN01".
  304.  
  305.   Assuming you have a download directory defined as "C:\MAX\BW\DOWN%N"
  306.   Example of door running as task 10, expands to "C:\MAX\BW\DOWN10".
  307.   Example of door running as task 1, expands to  "C:\MAX\BW\DOWN1".
  308.  
  309.  
  310. * The door now detects when it is being run under one of the following
  311.   multi-taskers, and frees time slices accordingly:
  312.  
  313.   MS-Windows Enhanced Mode
  314.   OS/2 Virtual DOS Machine
  315.   DESQview
  316.  
  317.   If time slicing is occuring for one of the above multi-taskers, a line
  318.   will be logged to the designated log file indicating which type of
  319.   slicing it has detected it should use.
  320.  
  321.  
  322. * For sysops packing mail for users in nightly events using the /K<user#>
  323.   command line parameter in conjunction with the /D (autodownload)
  324.   parameter, there is a new and preferred way to load the door in local
  325.   mode.
  326.  
  327.   bwmail /Kgeorge_hatchew /d
  328.  
  329.   will load the door in local mode, search USER.BBS for "George Hatchew",
  330.   and then perform an auto-download.  You can do the same thing with *any*
  331.   name in your user file.  Simply remember to use UNDERSCORES instead of
  332.   spaces when using this method of local login.  "Jason St. Martin" would
  333.   look like this:  /Kjason_st._martin.  The names entered on the command
  334.   line are case insensitive.
  335.  
  336.  
  337. * The BWUTILS->Protocol Editor has been rewritten to support the new
  338.   INTERNAL protocols.
  339.  
  340.  
  341. * The door now supports 8 internal protocols which can be activated and
  342.   deactivated through the BWUTILS->Protocol editor.  There is absolutely
  343.   nothing to configure for the internal protocols as far as command lines
  344.   go.  The Blue Wave Mail Door now has support for the following built-in
  345.   protocols:
  346.  
  347.   Zmodem          (Both 16 and 32 bit CRC mode)
  348.   ZedZap          (Zmodem with up to 8k subpackets, depending on BPS rate)
  349.   Ymodem          (Standard 128 byte block Ymodem-Batch)
  350.   Ymodem-G        (1024 byte blocks, no error recovery)
  351.   Ymodem-1k       (1024 byte blocks with error recovery)
  352.   Xmodem-1k       (1024 byte Xmodem blocks)
  353.   Xmodem-CRC      (Standard 128 byte block Xmodem with CRC error checking)
  354.   Xmodem-Checksum (Standard 128 byte block Xmodem with Checksum)
  355.  
  356.  
  357. * All reported problems with the CEXYZ/internal protocol driver have been
  358.   addressed.  Some complaints included failed Xmodem sessions (Xmodem-CRC,
  359.   Xmodem-CheckSum, Xmodem-1K) and the inability to sync properly when the
  360.   remote user was using the "Communique" terminal package with Zmodem.
  361.   System hangs with the protocol driver have been eliminated.  The CEXYZ
  362.   that was distributed with the last public beta version of the door
  363.   (BWRA199A.ZIP) has been extensively worked on.  If you previously had
  364.   problems with CEXYZ, please give the internal protocols another try.
  365.  
  366. * When using the internal protocol driver under OS/2 (from a DOS session)
  367.   you may need to add the undocumented /FAST (now documented!) command line
  368.   parameter to the door's (BWMAIL.EXE) command line. This command line
  369.   parameter uses "Direct" communications with the com port instead of
  370.   working through the FOSSIL.  Quite a few people have reported that this
  371.   will cure the "Unable to synchronize with remote system" errors from
  372.   Zmodem.  You may want to try this switch even if you are not running
  373.   OS/2, but are having trouble with the internal protocol driver.
  374.  
  375.  
  376. * Support for external BIDIRECTIONAL protocols has been added (such as
  377.   Hydra and Bimodem).  Users can now upload their reply packets while
  378.   downloading their messages.  After the door has completed a mail
  379.   download, it will scan the defined UPLOAD directory to see if anything
  380.   has been transferred.  If there was a *.NEW file uploaded, the door will
  381.   process it immediately.
  382.  
  383.  
  384. * To aid in executing external bidirectional protocols, the protocol
  385.   command lines can now contain a "%U" parameter, which will pass the
  386.   UPLOAD DIRECTORY ONLY to the protocol.  All bidirectional protocols need
  387.   to know the upload (receive) directory when executed.
  388.  
  389.  
  390. * After the door has completed mashing a mail packet, the user now has the
  391.   following choices:
  392.  
  393.   A)bort download
  394.   C)ountdown logoff
  395.   I)mmediate logoff
  396.   P)rotocol Change (Current Protocol)  <=== New!
  397.   [ENTER] for normal download
  398.  
  399.  
  400. * "Chat Mode" has been added to the door.  To chat with an online user,
  401.   type <Alt-C> from the local keyboard.  To exit chat mode, simply press
  402.   ESCape.
  403.  
  404.  
  405. * When uploading messages, the door now places a ^aMSGID: line into the
  406.   message.
  407.  
  408.  
  409. * NEW on the door's CONFIGURATION menu -- User now has the option of
  410.   toggling the status of "U)se Numerical Packet Extensions".  If this
  411.   option is ON, packets will be named as BBSID.001 through BBSID.999.
  412.   After .999 is reached, the door recycles back to .001.  If this option is
  413.   left OFF, the original BW packet extensions are used (.SU1 - .SA9).
  414.  
  415.  
  416. * When selecting message areas for download, users now have the choice of a
  417.   default bundling action for the area:
  418.  
  419.   Personal Messages Only
  420.   Personal Messages, plus those messages addressed to "All"
  421.   Default action of all new messages.
  422.  
  423.  
  424. * The mail scan screen has been changed.  Hopefully it is a bit more
  425.   readable and informative than before.  In the right-most column of the
  426.   scan screen there is a new column called "# DL'ing".  This column
  427.   indicates the number of messages that are going to be packed for
  428.   download.  You'll notice that as you enter bundling commands and select
  429.   "R" to relist the scan screen, the numbers will change depending on the
  430.   effects of the bundling command.
  431.  
  432.   Directly after the area name in the scan screen is a short phrase that
  433.   indicates the type of bundling action that will be performed on the area:
  434.  
  435.   New     -- Indicates that all messages since the last msg download will
  436.              be packed.
  437.   Pers    -- Only personal messages since the last msg download will be
  438.              packed.
  439.   P+All   -- Only personal messages, and messages addressed to "All" will
  440.              be packed.
  441.   Kwds    -- Only messages containing user keywords will be packed.
  442.   Filt    -- Messages that contain any of the filters will be skipped
  443.              during packing.
  444.   L  20   -- User issued an <area#>L20 command for this area; only the last
  445.              20 messages in the area will be packed for download.
  446.   B 100   -- User issued an <area#>B100 command for this area; only the
  447.              first 100 messages in the area will be packed for download.
  448.   Force   -- The area is being forced for download by the sysop.  No
  449.              bundling commands can be issued for this area.
  450.   None    -- User issued a -<area#> for this area, and no messages will be
  451.              packed.
  452.  
  453.  
  454. * A *NEW* Bundling command to go along with the "Personal+All" options for
  455.   downloading...  "A200" would force the door to only bundle messages in
  456.   area #200 that were PERSONAL MESSAGES, or were addressed to "ALL".  As
  457.   with all of the other bundling commands, "A*" would perform the same
  458.   action on all areas.
  459.  
  460.  
  461. * When 0 messages are found during the initial mail scan, the line:
  462.   There are 0 messages prepared for download.
  463.   is sent to the screen so that creative people using script files can have
  464.   their script skip the mail download.
  465.  
  466.  
  467. * A new command line parameter -- /NORECV -- will force the door to NOT
  468.   mark messages as "Received" when they are downloaded.  Good for sysops
  469.   who can't answer their mail right away and want to trick users into
  470.   thinking their mail hasn't been read yet :-).  This probably shouldn't be
  471.   used for normal BBS-user use.
  472.  
  473.  
  474. * When "/d" or "/u" is used with a remote user online, the following
  475.   command lines are available:
  476.  
  477.   /INSTANT     --- Causes an instant logoff after a successful auto
  478.                    download or auto upload session.
  479.   /COUNT       --- Causes a countdown logoff after a successful auto
  480.                    download or auto upload session.
  481.  
  482.  
  483.