home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Beijing Paradise BBS Backup
/
PARADISE.ISO
/
software
/
BBSDOORW
/
RA_202.ARJ
/
RELEASE.DOC
< prev
next >
Wrap
Text File
|
1994-06-23
|
4KB
|
108 lines
RemoteAccess 2.02 release notes
===============================
Welcome to the 2.02 upgrade. With a few exceptions, this is a maintenance
release. Some of the new features include full Internet support, and
major performance enhancements in the JAM message-base handling. Check
the WHATSNEW.202 file in this archive for a comprehensive list of changes
since version 2.01.
There is no upgrade fee for this version.
How to upgrade from 2.00/2.01
-----------------------------
1. Replace your executable files with the ones in this archive.
2. Update language prompts 662, 663 and 664 for all of your installed
languages.
Documentation changes
=====================
There are a number of features/notes which did not make it in time for the
main documentation (unchanged since the 2.01 release). NOTE: The following
changes do NOT include those in WHATSNEW.202:
JAM message-base support
------------------------
In order for JAM support to function correctly, you *MUST* have SHARE
loaded. If you are unsure how to do this, check your DOS manual.
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" */