home *** CD-ROM | disk | FTP | other *** search
- RemoteAccess 2.01 release notes
- ===============================
-
- Welcome to the 2.01 upgrade!
-
- There is no upgrade fee for this shareware version. Your existing RA.KEY will
- continue to work with the 2.01 release. This is a maintenance release only.
-
- 2 Node limitation
- -----------------
- That's right. As of this release, the shareware version will support a
- maximum of 2 normal plus 1 local-only nodes. To run more than this requires
- the /Pro version. Take this into account before proceeding with the upgrade;
- you may want to upgrade to the /Pro version instead.
-
- RemoteAccess 2.01 Professional
- ------------------------------
- The Pro version is released simultaneously with this shareware version, and
- is therefore available immediately. Pro owners who have returned their
- registration cards will be receiving upgrade information shortly. Contact
- information for /Pro distributors is contained in the main documentation.
-
-
- How to upgrade from 2.00
- ------------------------
- Couldn't be simpler. Replace all .EXE and .OVR files with the ones in this
- distribution archive. No further configuration required.
-
-
- How to upgrade from 1.11
- ------------------------
- Due to the significant number of changes, this is not a simple "plug & play"
- upgrade. While not especially complicated, there are a number of steps that
- must be followed to complete the upgrade successfully:
-
- As always, BACK UP YOUR SYSTEM FIRST!
-
- 1. Replace your 1.11 executables with the 2.01 ones.
- (Don't forget your node directories, if applicable).
-
- 2. Run RACONFIG in your system and node directories.
- This will set defaults for the new options.
-
- 3. Run 111TO200.EXE.
- This will prompt you for some information, and will
- then upgrade your configuration, menu and user files.
-
- 4. Delete the USERON.BBS file from the system directory.
-
- 5. Follow the instructions in the file "RA200FDB.TXT" under
- the "Upgrade notes" heading, to install the new file system.
-
- 6. Update the following prompts in your language files:
-
- 46, 56, 57, 103, 199, 408, 524, 571, 572, 573
- 601 to 661
-
- NOTE: Prompts 570 to 600 are reserved for the Professional
- version.
-
- 7. If you have copies of CONFIG.RA in your node directories ONLY
- because of different modem configurations, you may delete
- CONFIG.RA from your node directories. All modem configuration
- information is now stored in MODEM.RA.
-
- 8. Run RAUSER -P to generate the new userfile index.
-
- 9. Finally, don't forget to disable any doors which are not
- compatible with 2.01.
-
- As a final upgrade note, the command-line parameters for RAMSG.EXE have
- changed. The old version of RAMSG has been thrown out and replaced with
- an OEM version of the MBUTIL message database maintenance program. It
- contains extensive help screens to aid you in your installation.
-
- NOTE: If you use RAMSG 1.11 or any other message-base utility which reads
- MESSAGES.RA for purging information, you MUST replace it with the
- new RAMSG provided in this archive!
-
-
- Last-minute additions to the documentation
- ==========================================
-
- There are a number of features/notes which did not make it in time for the
- main documentation:
-
- RIP Support
- -----------
- This version of RemoteAccess has support for the online graphical protocol
- RIP (Remote Imaging Protocol). To give your BBS RIP functionality, simply
- create the appropriate RIP screens in your textfile directory. RemoteAccess
- will auto-detect RIP at the user's end and display the .RIP files (where
- available) in preference to your regular ASC/ANS/AVT textfile.
-
- An indicator on the F1 status bar signals the sysop that RIP is currently
- active. Additionally, a boolean flag has been added to the EXITINFO.BBS
- drop-file so that doors and other external programs can determine whether
- the user's terminal supports RIP.
-
- NOTE that RIP graphics are never displayed locally. Instead, a window will
- pop up during the display of a RIP file to indicate what the user is seeing.
-
-
- RAMSG.EXE
- ---------
- * A number of RAMSG options and command-line parameters do not apply to JAM
- areas, and are therefore ignored. Note that the following options are still
- valid for Hudson areas, as per the documentation:
-
- RAMSG INDEX - The "delete" and "recover" options are ignored for JAM areas.
- RAMSG PACK - The "force", "overwrite", "delete" and "recover" options
- are ignored for JAM areas.
-
- * NOTE that the example in the documentation is incorrect. The example which
- reads "RAMSG INDEX -Delete -Recover -Renumber" should read
- "RAMSG INDEX -Delete -Recover".
-
- * By default, RAMSG processes JAM areas and Hudson areas, in that order. To
- force RAMSG to process either JAM *OR* Hudson (not both), the following
- command-line switches are available:
-
- -JAM - Process JAM areas only.
- -Hudson - Process Hudson areas only.
-
- * It should also be noted that JAM areas will ONLY be linked if the -Link
- option is specified during a PACK operation. This is not true of Hudson
- areas, whose reply links are always updated.
-
- * The -NoLrdPack switch of the Pack command is not documented in the manual.
- This command (example "RAMSG Pack -NoLrdPack") disables packing of the
- lastread pointer files for JAM areas.
-
- * The "RAMSG Purge -Unused" command-line will cause RAMSG to automatically
- delete all messages in any undefined (blank name) Hudson message areas.
-
- * The errorlevels for RAMSG are documented incorrectly. The correct errorlevels
- are:
-
- 251 Configuration file version ID mismatch
- 252 Incorrect DOS version
- 253 Insufficient disk space available
- 254 Insufficient memory available
- 255 Disk error or missing configuration data
- 3 Fatal error detected by Borland C++ Start Up Code
- (Usually this means there is insuffient memory to set up a stack)
- 0 No errors occurred
-
- * While there are no limits per se on the number of messages in a JAM area,
- this version of RAMSG can only handle a maximum of 65,535 messages per JAM
- area. RAMSG will require more or less memory depending on the size of the
- message-base to be packed. Memory required is approximately 64k + 8 bytes
- per message. This means that on a machine with 590k available, RAMSG can
- easily process the maximum number of messages (65,535).
-
-
- Hope you enjoy this upgrade!
- Andrew Milner.
-
- /* End of file "RELEASE.DOC" */
-