Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / BW302_RA.ZIP / WHATSNEW.302 < prev

Wrap

Text File | 1994-01-21 | 21.1 KB | 483 lines

The Blue Wave Offline Mail Door for RemoteAccess v3.02 Upgrade and New Feature Documentation Copyright (C) 1993 by Cutting Edge Computing All Rights Reserved. This information is provided for those people who are familiar with previous versions of the mail door, and who do not care to comb the full documentation to find what has been added or changed since the last release. However, if you are unsure of how to use a feature that is described here, consulting the appropriate section in the full documentation (BWMAIL.DOC) will be necessary. INSTALLATION ------------ Please read the file INSTALL.302, which was enclosed in the original distribution archive (BW302_RA.ZIP). This version of The Blue Wave Mail Door is being distributed with a file called BWDOOR.USE. This is an ASCII file that explains the use of The Blue Wave Mail Door, what each item on the configuration menu does, how to use The Blue Wave Bundling Commands, and more. This is an excellent tutorial for new users to the mail system. It is suggested that this file be placed online for your users to download. FIXES SINCE v3.01 ----------------- * The mail door would not properly locate all new messages in Hudson message areas if the message base was not sequentially numbered. (A -renumber parameter was not given to RAMSG after messages had been deleted). * If a user somehow managed to change the PRIVATE status bit in an upload packet, the door was not forcing the correct status on the message. For example, if area #1 was configured for Private Messages Only, and the user uploaded a message to area #1 without the private flag set, the message would have been flagged as public. The door now forces the correct status bit on the message. WHATS NEW SINCE v3.00 --------------------- * Added a check to see if v3.x of the mail door was installed on a version of RemoteAccess not compatible with this mail door. Many people have tried installing this mail door on RA v1.x systems. If the size of the MESSAGES.RA file is not evenly divisible by the size of the v2.x MESSAGES.RA file structure, a message is sent to the screen informing the sysop that it is either not a RemoteAccess v2.xx compatible MESSAGES.RA file, or the file has somehow been corrupted. * Added a new command line parameter to the door: /L<locked_bps_rate>. When using the /FAST or /DIRECT command line parameters for the mail door, the internal protocol driver needs to know the locked port speed of the current communications port. Without this information, the internal protocol driver will not function correctly. If it has been necessary for you to use the /FAST or /DIRECT command line parameters for the internal protocol driver (most of the time necessary when running the software in a VDM under OS/2), passing the locked port speed to the mail door with /L38400 (or your port speed) will solve troubles you may have had. * When "Extended Information" is turned ON from the door's configuration menu, ^a Fidonet Kludge Lines will now be passed to the reader when downloading from a JAMmed message area. * Added a bps rate of 21600 to the available Limits and Maximums editor in the BWUTILS program and the mail door. * In the BWUTILS program's User Area Editor, you can now explicitly set the download status of the listed message areas to "Personal Only" and "Personal + "All"" status. v3.00 did not support this feature, and could sometimes mess up these settings when editing a user's active message areas. * Added OS/2 DOS-box detection to the internal protocol driver, making the driver less CPU intensive when running the BBS and mail door in an OS/2 DOS Session. FIXES SINCE v3.00 ----------------- * The "Do Not Bundle Messages Written by Me" option did not always work correctly. * Lastread pointers were not always read/updated correctly when working with the Hudson Message Base. * A pointer (memory) problem with the NEWFILES scan was fixed. Additionally, file description limits have now been increased to 50 lines per file, since people have complained that 20 was not enough (!?!). * Worked on improving the speed of the NEWFILES scan. Sorry folks, but I can't make it any faster than it is in this new version. It should be somewhat faster than the v3.00 release code, but not a whole lot. * Netmail destination addresses that contained the same ZONE and NET number (ie: 1:1/31 or 2:2/17) were not being found properly during nodelist lookups. * Point entries in NODECOST.CTL (RemoteAccess's nodelist costing control file) were not being found properly, resulting in netmail to a point of a certain node being charged the same number of credits as mail to the BOSS of that point. * Garbage in the string "Area #nn is forced, and cannot be modified" when a user tries to modify a forced message area with bundling commands has been fixed. * If a bidirectional protocol was used to upload a reply packet in conjunction with the "/d /logoff=c" command line parameters, the door would perform a countdown or instant logoff without first checking to see if any replies were uploaded during the mail download. * Maximum uncompressed packet sizes (when set from the CONFIGURATION MENU of the door) did not work properly in local mode. Additionally, BWUTILS was displaying an incorrect value for the max packet size (it was multiplying the number by 1000, when it should not have been). * Setting DEFAULT NETMAIL BITS in the BWUTILS->Security/Netmail manager didn't work on all systems properly. * Apparently, non-US keyboards had trouble with the '@' keypress needed to toggle upload information logging in the BWUTILS->Options and Toggles editor. The keypress has been changed to a 'U'. * The BWUTILS PURGE command was broken in the v3.00 release. * The internal protocol driver in the door will no longer create/append to a DSZ-style log file so that uploads through RemoteAccess work properly when using external protocols. CHANGES MADE IN VERSION 3.00 ---------------------------- * The mail door is now fully JAM compatible. * Messages downloaded from Hudson Message bases will now appear in the reader with a date format of "DD Mmm YY HH:MM", as in "01 Nov 93 12:01" in order to be more friendly to non-American date style users. * All of the security levels that were defined in BWUTILS (Sec/Flags to send CRASH mail, etc.) can now have RA-style "NOT" flags. In BWUTILS, a "-" in a flag field means the flag is disabled. An "X" in the field means the user must have the flag, and an "O" means that the user must NOT have the flag. In addition, the mail door uses RA's "NOT" flags when determining user access to message/file areas. * Before giving a user access to any message/file area, the mail door will check the Minimum Age required for access, and deny anyone that is either not old enough or who does not have a birth-date entered in the user record. * Due to popular demand, you may now give a more complete description of each archiver that you have configured in the door. Many people needed a way to distinguish between PKZIP v2.04 and v1.10. You can now enter a long description for each archiver through the BWUTILS->Archiver Configuration Editor. This long description will be displayed when users choose/change archivers within the door. * A new option on the door's configuration menu: N)ew File Listings in Packets. Users have the option of setting this option to YES, NO, or COLOR. If the user chooses NO, no new file listing will be sent in the download packet. If the user chooses YES or COLOR, the door will scan for new files since their successful mail download. The door will include ANSI sequences if COLOR is turned on. Some things to keep in mind about the new file list scanner: a) RemoteAccess stores an "Upload" date with the file. Therefore when users receive a new file listing from the door, the file date displayed may be "old" in comparison with their last mail download date. This is NORMAL behavior. In actuality the file is a new UPLOAD since their last login. b) Areas defined in your FILES.RA file with the "New" flag set to OFF will NOT be scanned for new files, in the same way that RemoteAccess will not scan the file area. c) All of RA's SECURITY, FLAGS, "NOT" FLAGS, and AGE are supported in the file areas. If a user does not have access to a file area within RA, the door will not even bother to scan the area for files. e) The door creates the new files list in a file called NEWFILES.BW. You do *not* need to put NEWFILES.BW as one of the "reader files" in the BWUTILS->General Information Editor. f) All file listings generated by the door include the file name, file size, file date, and the full description. The door will "wrap" long file descriptions, up to 20 lines. * The entire "message upload" portion of the mail door has been rewritten. You will probably notice a big increase in speed. The display while tossing uploaded messages has also been changed to be more informative. * Duplicate message detection has also been overhauled. The door will now use a file called BWDUPES.IDX to store duplicate message information. You can safely delete the old duplicate detection file (BWDUPES.DAT) after installing the new version. * In the BWUTILS->General Information Editor, you will notice that each of the 5 "reader files" are now configurable by Sec. Level and flags. If a user does not have sufficient access to a reader file, the door will not send it. This will allow "custom" welcome screens by security level to be passed to the reader. By default, each of the reader files have been assigned "0" security level access with no flags required. In order for you to edit the Sec/Flags on the reader file, you need to first edit the name of the file (type any character in the field). * BWUTILS now has a new menu item - The "Limits and Maximums" editor. For each BPS rate that your system supports, you can now define 2 limits on the amount of mail that is packed by the door. It is important to understand how each limit works: MAXIMUM UNCOMPRESSED PACKET SIZE is the largest mail packet size (uncompressed, obviously!) that a user at a certain BPS rate may download. Some may find this useful if they bundle messages (have their WORK directory pointed) to a RAMdrive. For example, I have a 2 meg RAMdrive configured as the door's WORK directory on my system. Therefore, I have all of the BPS rates configured for 1800K uncompressed packet size to ensure there is always enough room to complete a successful packing session. If you do not care how large the uncompressed packets are for any particular BPS rate listed, simply set the field to -1. This will cause the door to have no set limit (other than disk space). MAXIMUM NUMBER OF MESSAGES obsoletes the old "overall Maximum Messages" setting the door had. The door enforces the maximum number of messages per BPS rate, just as with the MAXIMUM UNCOMPRESSED PACKET SIZE. If you wish to set no limit for the maximum number of messages, simply enter "-1" in the field. The door will not enforce a limit for that particular BPS rate. There is an important difference in the way these two limits work. "MAX MSGS" limits are enforced BEFORE any bundling of the messages takes place. The user must use the bundling commands to trim the size of their mail packet before proceeding with a mail bundling session. "MAX PKT SIZE" is enforced DURING bundling. If at any time during bundling the door reaches the maximum packet size limits, it immediately halts the bundling process and compresses the mail packet for the user to download. * In the LIMITS AND MAXIMUMS editor, you can tell the door whether or not you will allow NEW FILE scans to take place. If this is set to "NO", users will not be given the option on the door's CONFIGURATION menu to create newfiles lists. * In the LIMITS AND MAXIMUMS editor, you can define the maximum number of days to "look backwards" to find new files. If a user has not logged into your system for 6 months, you (most likely) do not want them receiving a NEWFILES listing containing the last 6 months worth of new files. You can control the maximum number of days to include in the file list by editing this field. A good number to use here is probably somewhere between 10 and 30 days. * Previous versions expanded "%T" in pathnames to the hexadecimal task number that was passed to the door. This is still true, but you can now use a "%N", which will expand to the DECIMAL task number passed to the door. Assuming you have a download directory defined as "C:\MAX\BW\DOWN%T" Example of door running as task 10, expands to "C:\MAX\BW\DOWN0C". Example of door running as task 1, expands to "C:\MAX\BW\DOWN01". Assuming you have a download directory defined as "C:\MAX\BW\DOWN%N" Example of door running as task 10, expands to "C:\MAX\BW\DOWN10". Example of door running as task 1, expands to "C:\MAX\BW\DOWN1". * The door now detects when it is being run under one of the following multi-taskers, and frees time slices accordingly: MS-Windows Enhanced Mode OS/2 Virtual DOS Machine DESQview If time slicing is occuring for one of the above multi-taskers, a line will be logged to the designated log file indicating which type of slicing it has detected it should use. * For sysops packing mail for users in nightly events using the /K<user#> command line parameter in conjunction with the /D (autodownload) parameter, there is a new and preferred way to load the door in local mode. bwmail /Kgeorge_hatchew /d will load the door in local mode, search USER.BBS for "George Hatchew", and then perform an auto-download. You can do the same thing with *any* name in your user file. Simply remember to use UNDERSCORES instead of spaces when using this method of local login. "Jason St. Martin" would look like this: /Kjason_st._martin. The names entered on the command line are case insensitive. * The BWUTILS->Protocol Editor has been rewritten to support the new INTERNAL protocols. * The door now supports 8 internal protocols which can be activated and deactivated through the BWUTILS->Protocol editor. There is absolutely nothing to configure for the internal protocols as far as command lines go. The Blue Wave Mail Door now has support for the following built-in protocols: Zmodem (Both 16 and 32 bit CRC mode) ZedZap (Zmodem with up to 8k subpackets, depending on BPS rate) Ymodem (Standard 128 byte block Ymodem-Batch) Ymodem-G (1024 byte blocks, no error recovery) Ymodem-1k (1024 byte blocks with error recovery) Xmodem-1k (1024 byte Xmodem blocks) Xmodem-CRC (Standard 128 byte block Xmodem with CRC error checking) Xmodem-Checksum (Standard 128 byte block Xmodem with Checksum) * All reported problems with the CEXYZ/internal protocol driver have been addressed. Some complaints included failed Xmodem sessions (Xmodem-CRC, Xmodem-CheckSum, Xmodem-1K) and the inability to sync properly when the remote user was using the "Communique" terminal package with Zmodem. System hangs with the protocol driver have been eliminated. The CEXYZ that was distributed with the last public beta version of the door (BWRA199A.ZIP) has been extensively worked on. If you previously had problems with CEXYZ, please give the internal protocols another try. * When using the internal protocol driver under OS/2 (from a DOS session) you may need to add the undocumented /FAST (now documented!) command line parameter to the door's (BWMAIL.EXE) command line. This command line parameter uses "Direct" communications with the com port instead of working through the FOSSIL. Quite a few people have reported that this will cure the "Unable to synchronize with remote system" errors from Zmodem. You may want to try this switch even if you are not running OS/2, but are having trouble with the internal protocol driver. * Support for external BIDIRECTIONAL protocols has been added (such as Hydra and Bimodem). Users can now upload their reply packets while downloading their messages. After the door has completed a mail download, it will scan the defined UPLOAD directory to see if anything has been transferred. If there was a *.NEW file uploaded, the door will process it immediately. * To aid in executing external bidirectional protocols, the protocol command lines can now contain a "%U" parameter, which will pass the UPLOAD DIRECTORY ONLY to the protocol. All bidirectional protocols need to know the upload (receive) directory when executed. * After the door has completed mashing a mail packet, the user now has the following choices: A)bort download C)ountdown logoff I)mmediate logoff P)rotocol Change (Current Protocol) <=== New! [ENTER] for normal download * "Chat Mode" has been added to the door. To chat with an online user, type <Alt-C> from the local keyboard. To exit chat mode, simply press ESCape. * When uploading messages, the door now places a ^aMSGID: line into the message. * NEW on the door's CONFIGURATION menu -- User now has the option of toggling the status of "U)se Numerical Packet Extensions". If this option is ON, packets will be named as BBSID.001 through BBSID.999. After .999 is reached, the door recycles back to .001. If this option is left OFF, the original BW packet extensions are used (.SU1 - .SA9). * When selecting message areas for download, users now have the choice of a default bundling action for the area: Personal Messages Only Personal Messages, plus those messages addressed to "All" Default action of all new messages. * The mail scan screen has been changed. Hopefully it is a bit more readable and informative than before. In the right-most column of the scan screen there is a new column called "# DL'ing". This column indicates the number of messages that are going to be packed for download. You'll notice that as you enter bundling commands and select "R" to relist the scan screen, the numbers will change depending on the effects of the bundling command. Directly after the area name in the scan screen is a short phrase that indicates the type of bundling action that will be performed on the area: New -- Indicates that all messages since the last msg download will be packed. Pers -- Only personal messages since the last msg download will be packed. P+All -- Only personal messages, and messages addressed to "All" will be packed. Kwds -- Only messages containing user keywords will be packed. Filt -- Messages that contain any of the filters will be skipped during packing. L 20 -- User issued an <area#>L20 command for this area; only the last 20 messages in the area will be packed for download. B 100 -- User issued an <area#>B100 command for this area; only the first 100 messages in the area will be packed for download. Force -- The area is being forced for download by the sysop. No bundling commands can be issued for this area. None -- User issued a -<area#> for this area, and no messages will be packed. * A *NEW* Bundling command to go along with the "Personal+All" options for downloading... "A200" would force the door to only bundle messages in area #200 that were PERSONAL MESSAGES, or were addressed to "ALL". As with all of the other bundling commands, "A*" would perform the same action on all areas. * When 0 messages are found during the initial mail scan, the line: There are 0 messages prepared for download. is sent to the screen so that creative people using script files can have their script skip the mail download. * A new command line parameter -- /NORECV -- will force the door to NOT mark messages as "Received" when they are downloaded. Good for sysops who can't answer their mail right away and want to trick users into thinking their mail hasn't been read yet :-). This probably shouldn't be used for normal BBS-user use. * When "/d" or "/u" is used with a remote user online, the following command lines are available: /INSTANT --- Causes an instant logoff after a successful auto download or auto upload session. /COUNT --- Causes a countdown logoff after a successful auto download or auto upload session.