home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Black Box 4
/
BlackBox.cdr
/
bbs_ra
/
xrdor206.arj
/
XRDOR200.DOC
< prev
next >
Wrap
Text File
|
1992-04-10
|
47KB
|
898 lines
XXX XXX RRRRRRRR SSSSS <tm>
XXX XXX RRR RRR SSS SS
XXXXXX RRR RRR SSS
XXXX RRRRRRRR SSS DDDD OOO OOO RRRR
XXXXXX RRR RRR SSS D D O O O O R R
XXX XXX RRR RRR SS SSS D D O O O O RRRR
XXX XXX RRR RRR SSSSS DDDD OOO OOO R R
RemoteAccess/QuickBBS/SuperBBS eXpress Door
Version 2.00
Program CopyRight (C) 1989, 1990, 1991 by Mike Ratledge
Documentation written and all rights reserved by Ed Meloan of 360/1
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 1 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Table of Contents ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │
└─────────────────────────────────────────────────────┘
What is XRSDoor ............................. 2
Getting Started ............................. 3
Setting Up XRSDoor for QuickBBS/SuperBBS..... 4
Setting Up XRSDoor for RemoteAccess ......... 5
Processing INBOUND Mail ..................... 7
Setting Up The QMXSETUP.CFG File ............ 8
A Few Hints ................................. 12
A Short Check List .......................... 13
Using XRSDoor on Your BBS ................... 13
XRSDoor User Requests ....................... 15
Odds & Ends ................................. 17
Credits ..................................... 19
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 2 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────┐
│ ▒▒▒ What is XRSDoor ▒▒▒ │
└─────────────────────────┘
XRSDoor is An exciting way for your callers to get all the messages they are
interested in and =READ THEM AFTER THEY LOG OFF=. The XRSDoor system allows
your users to do the following:
1. Custom select the Message Areas =THEY= want to read
2. Collect the new messages from these areas =AND= ALL
messages addressed to them even in areas they don't select.
3. Pack them in an archive and send them to their computer
4. Lets your user read them while off-line, freeing your board
for the next caller!!
5. The companion XRS Response system gives your caller an
EXCELLENT full-screen editor that allows them to read,
reply and edit all their messages WHILE OFF-LINE!
6. Pack their replies and send them back to this BBS where
XRSDoor will automatically place them in the correct message
areas just as if the user had written them there.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 3 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Getting Started ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │
└─────────────────────────────────────────────────────┘
Read the following information and you'll be on your way to providing your
RemoteAccess/QuickBBS/SuperBBS users with this exciting new feature!
If you're already running ECHOMAIL - then you are well on your way already!
Since XRSDoor depends on an AREAS.BBS file to know where to place incoming
messages, you'll need to have that file set up. One point here is that you
=MUST= setup names for EVERY message area... Even ones which normally do not
handle ECHOMAIL. This allows your present echomail processing to properly toss
LOCAL as well as ECHO messages into the correct message areas.
[A note here that while XRSDoor can handle AREAS.BBS area names in lower case,
some mail tossers can not! All area names should be in UPPER CASE.]
The XRS program requires group zero to be a local message area, and therefore
XRS always shows "00 LOCAL" as the first available group. This 00 area is
inherited from the TCOMM program, for which XRS was originally written, and
really has no function in the R/Q/SBBS environment. You should setup the main
general local area of your BBS with the area name "LOCAL", so that the mail
tosser will place the inbound traffic into the correct area. This can be ANY
message area number as long as it is named LOCAL in AREAS.BBS. Since there is
no 00 area, as there is in TCOMM, you will want to use one of your regular
area numbers. This feature is required because all your users may not have
access to NetMail - they cannot send private message back to your BBS (XRS
will =ONLY= allow private status on NetMail, Local or in response to a private
message)! XRS version 4.0 and later =DO= recognize areas which have either
private or "both" access, so those areas can have private messages, too.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 4 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────┐
│ ▒▒▒ Setting Up XRSDoor for QuickBBS/SuperBBS ▒▒▒ │
└────────────────────────────────────────────────────┘
XRSDoor is compiled in TWO versions. Select XRSDoor.EXE for use on XT (8088)
systems and XRSDoor!.EXE for V20/80286/80386 systems and place the correct
version in your QuickBBS/SuperBBS system directory.
XRSDoor must be set up as a Type 15 external program. It will NOT work as a
type 7 option. Here are the steps to set XRSDoor up as a type 15 menu option:
Decide on an error level and add the following lines to your QuickBBS or
Mailer BAT file. Let's assume we decide to use 98 as our level. We would set
up a type 15 menu option with 98 as the optional data. Do not type the
comments that are in brackets. For SuperBBS "SET SUPER=Y" in the environment.
:After_Quick
If errorlevel 98 goto XRSDoor (ADD this line)
If errorlevel 5 goto Both (You probably already have this line)
If errorlevel 4 goto NewEcho ( " " " " " " )
If errorlevel 3 goto NewNet ( " " " " " " )
Goto Loop (or whatever you call your starting section of BAT file)
Since XRSDoor has its own internal FOSSIL handling and carrier detection, you
will not need nor should you use redirection devices such as CTTY or GATEWAY
or carrier monitors such as WATCHCD. Please =DO NOT= use them. All you will
need in your BAT file will be something like this:
:XRSDoor
XRSDoor!.EXE (or XRSDoor.EXE)
QuickBBS -R -E0
Goto After_Quick
┌─────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ TWO IMPORTANT NOTES !! ▒▒▒▒▒▒▒▒▒ │
└─────────────────────────────────────────────────────────────┘
You =MUST= have the popular archiving programs PKARC, PKZIP, and LHA as well
as a recent version of ZMODEM (DSZ.COM) AVAILABLE FROM YOUR PATH!! We cannot
emphasize this too strongly. Having them in the QuickBBS sub-directory is
not necessarily enough if you don't have that sub-dir in the path statement!
XRSDoor uses DSZ.COM to provide external protocol support. It does not select
the COM: port for DSZ! If you use COM2: (or anything other than the default
COM1: address) you must place the following command immediately before XRSDoor
in your batch file: SET DSZPORT=2. "SET SUPER=Y" selects SuperBBS support.
SET DSZPORT=2 would tell DSZ to use COM2:, for example. You should also place
a similar command after XRSDoor without the '2' (but no spaces after the '='
either!), and you will free up the environment string space it uses.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 5 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ Setting Up XRSDoor for RemoteAccess ▒▒▒▒▒▒▒▒▒ │
└─────────────────────────────────────────────────────────────┘
XRSDoor is compiled in TWO versions. Select XRSDoor.EXE for use on XT (8088)
systems and XRSDoor!.EXE for V20/80286/80386 systems and place the correct
version in your RA system directory.
Complete file sharing and record-locking for updates is enabled *if* DOS
"Share" is detected. Assuming Share is detected, XRSDoor looks for "TCNODE"
in the DOS environment to determine the node number the user is on (i.e.
"SET TCNODE=2" for node 2, etc), and then uses BAT2MAIL.XRS, MAIL2IDX.XRS,
SUMMARY2.XRS, USER2.XRS & AREAS2.XRS, all of which get archived into the
file BAT2MAIL.* unless it's a local SysOp logon and 'SysOpOut' is in affect.
If you run multi-line RemoteAccess, you *must* start the program from the
proper \RA\LINEx (or whatever you call them) sub-directory. It is NOT
necessary to duplicate the files used by XRSDoor in each line's directory.
Here's why...
XRSDoor checks for the "RA" set in the DOS environment, and if found, looks in
that subdirectory for the CONFIG.RA file. Assuming "RA" is set, XRSDoor uses
that file plus the MESSAGES.RA. It then uses the path found in CONFIG.RA to
find the message databases.
The following files are looked for in the current sub-dir, then in the System
Path and finally in the Messages Path.
QMXSETUP.CFG, USERS.BBS, EXPRESS.BBS, FLSEARCH.QMX and DOWNLOAD.QMX
You can have specialized nodes or let a single set of control files be used.
The "QMX_CONF.SYS" file (user defaults) is first looked for in the current
sub-directory, then in the System (*not* messages!) sub-directory for RA.
This way you can have separate paremeters/configuations and users on each
node if you wish, or one configuration stored in the System directory.
XRSDoor will look for DORINFO1.DEF and EXITINFO.BBS in the sub-directory where
XRSDoor is located and =ASSUMES NODE 1= so single-line systems with Share
enabled are not treated like networks and the use of the TCNODE environment
variable is only required for true multi-line systems.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 6 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
Using file sharing and record-locking, multiple users can all access the
databases =AND= XRSDoor at the same time. Full support for the "RemoteAccess
BBS" software is included. XRSDoor looks to see if RA has been set in the
environment and if found, uses the RA Configuration files for information
about message area security and access. It also notifies XRS 3.12 and later to
tag the tear and origin lines with the proper RAX identity. Please NOTE that
although XRSDoor uses the MESSAGE.RA file, it will still need an AREAS.BBS file
since the MESSAGE.RA file does =NOT= contain the exact ECHOMAIL AREA NAMES!
You do not need a copy of AREAS.BBS in each line's sub-directory since XRSDoor
will look in the system and message directories if it doesn't find the file in
the current directory.
XRSDoor is remarkably simple to setup on the RemoteAccess system. A menu type
7 (shell) works VERY well! Add the *M and you can swap RA out of memory if
you are multitasking and memory space is limited.
Since XRSDoor has its own internal FOSSIL handling and carrier detection, you
will not need nor should you use redirection devices such as CTTY or GATEWAY
or carrier monitors such as WATCHCD. Please =DO NOT= use them. All you will
need in your menu type 7 OPTIONAL DATA is the following line:
C:\RA\XRSDoor!.EXE *M (or XRSDoor.EXE *M)
That's it! No elaborate BAT files are needed! Including the C:\RA\ path
will allow you to use a single copy of the XRSDoor program, regardless of the
number of lines you may be running. If you do NOT put XRSDOOR?.EXE on your
PATH, you will need a copy of XRSDoor in the directory for EACH line.
┌─────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ TWO IMPORTANT NOTES !! ▒▒▒▒▒▒▒▒▒ │
└─────────────────────────────────────────────────────────────┘
You =MUST= have the popular archiving programs PKARC, PKZIP, and LHA as well
as a recent version of ZMODEM (DSZ.COM) AVAILABLE FROM YOUR PATH!! We cannot
emphasize this too strongly. Having them in the sub-directory with XRSDoor is
not necessarily enough if you don't have that sub-dir in the path statement!
XRSDoor uses DSZ.COM to provide external protocol support. It does not select
the COM: port for DSZ! If you use COM2: (or anything other than the default
COM1: address) you must place the following command immediately before XRSDoor
in your batch file: SET DSZPORT=2
SET DSZPORT=2 would tell DSZ to use COM2:, for example. You should also place
a similar command after XRSDoor without the '2' (but no spaces after the '='
either!), and you will free up the environment string space it uses.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 7 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ Processing INBOUND Mail ▒▒▒▒▒▒▒▒▒ │
└─────────────────────────────────────────────────────────────┘
XRSDoor will attempt TO PUT UPLOADED FILES INTO A NEW SUB-DIRECTORY NAMED \QMX
ON THE CURRENT DRIVE. You will need to MAKE A DIRECTORY, off the root, called
QMX. You must move the incoming message files, from your users, into your
normal inbound net files area for processing by your echomail software
=UNLESS= you use MkXRS!. If you choose to use the Mark May utility MkXRS, you
will NOT need to move incoming mail from \QMX\ since MkXRS will toss DIRECT
from \QMX\. Please see the MkXRS entry in the QMXSETUP section for details on
how to set it up. (Using MkXRS offers the additional advantage of allowing you
to support RIME and other network software other than FidoNet, too.)
XRS now leaves behind only *.PKT files when it is through. If you do NOT use
MkXRS you'll need to add the following lines to your BAT file to handle the
incoming mail. Place this line so that it is read either before or after
every call!
If exist \QMX\*.PKT goto XRSMail
:XRSMail
COPY \QMX\*.PKT \FD\FILES (Replace \FD\Files with YOUR incoming
DEL \QMX\*.PKT mail directory)
:Toss_Echo (Start of your regular ECHO tossing section)
CD\RA (or QuickBBS or FD)
Qecho -A -P -T -U (or EchoGen, TosScan or Zmail...)
Goto Loop
This will copy the new incoming messages into the correct area and then drop
through to your regular tossing program. D'Bridge users see page 12.
XRSDoor exits with different errorlevels to tell you whether an upload was
received and/or mail was downloaded. ErrorLevel = 0 means no errors and
neither u/l or d/l was used. ErrorLevel 1 means mail was downloaded, a 2
means mail was uploaded and a 3 means both upload and download of mail.
An option is available which allows the user to get their mail, automatically
update their "last read" pointer and automatically LOG OFF! Three additional
error levels handle this "auto-logoff" function for those who wish to control
mail handling through error codes. 4 indicates automatic logoff with no
transfer, 5 indicates auto-logoff with a mailbag downloaded and 6 means auto-
logoff with both upload and download of mail. (All higher exit codes indicate
other program failure of some type!) These error levels can be used to direct
specific BATCH file activities if desired. Please note! It is NOT necessary
to use these codes unless you wish to do so. RemoteAccess or QuickBBS will
recover from the AUTO-LOGOFF without their use and mail will be tossed
normally.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 8 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ Setting Up The QMXSETUP.CFG File ▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────┘
XRSDoor allows the SysOp to control certain functions by editing a
"configuration" file. This file is named: QMXSETUP.CFG. Here are the
options in QMXSETUP.CFG along with brief descriptions of the options
function.
BBSID xxxxxxx - The "BBSID" parameter is =REQUIRED=! If not found, XRSDoor
will still run, but it will beep and display a warning message and use the
name "UNKNOWN1" for the BBS name if "Named Mailbags" are turned on by the
user. You should set the BBSID parameter to something that will uniquely
identify your BBS. For example, Augusta Forum is AGFORUM. XRSDoor will use
ONLY the first seven characters and will add the correct extension. If you
are running RemoteAccess and using multiple lines, the eighth character
will indicate the line the caller was using. Note that this feature is
only available to users of XRS 3.21 and later, and it must be turned on in
the new "Option Toggle" section by any user that wants the "Named Mailbag"
feature. Named Mailbags =ARE= the default for =NEW USERS=.
NetMail xxx - !!REQUIRED!! for RemoteAccess systems. Where 'xxx' is the
area number of the netmail board (your main netmail board if you have more
than one). Failure to set this parameter for RA dystems causes RA/QMX to
beep and use area # 201 as the netmail area (which doesn't exist), therefore
any netmail will be treated as echomail! Not needed for QuickBBS/SuperBBS.
InDir xxxxx - Allows you to give a different path for incoming mailbags
(default is "\QMX"). This is mostly to allow you to accept mail for multiple
nodes into separate areas if you also have the "Point xxx" parameter (which
causes everyone to have similar filenames). NOTE! Multi-node user =MUST=
have a different inbound directory for =EACH= Node! (\QMX1, \QMX2, etc.),
and these subdirectories =MUST= be exclusively for use by XRSDoor (empty).
To do this, you will need a copy of QMXSETUP.CFG in each line's directory.
PointNet xxxxx - Allows you to select the point number used by XRS. By
default, XRS uses pointnet number 30027, which was assigned to the program
by the ZC/IC.
ShowBar - Forces the status bar to be shown even if Desqview is detected.
NoBeep - Turns off beeps on SysOp side.
OutPath x:\path - Allows you to have XRSDoor automatically place the resulting
BAT1MAIL.xxx archive file into a different subdirectory. The "X:\PATH" portion
*MUST* point to a directory name! (you can't change the final filename,
anyway). You should DELETE this file automatically at logoff time to prevent
users from reading someone else's mail.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 9 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ Continuing the Setup of QMXSETUP.CFG ▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────┘
SysopOut x:\path - Allows THE SYSOP (User 0) to have XRSDoor automatically
place an UNARCHIVED MAILBAG into a different subdirectory. The "X:\PATH"
portion *MUST* point to a directory name!
NoBuff - Disable file buffering on MSGHDR.BBS and MSGTXT.BBS - on some
systems it may be faster to *not* buffer these files!
LockBaud - Force Hardware Flow Control on DSZ - required for HST's, etc!
ShowFiles - Show New Uploads ON SCREEN during FileScan. Files will ALWAYS be
included in the XRS <F6> pop-up Summary if FLEARCH.QMX is present. More on
FLSEARCH.QMX later.
NoBreak - To disable <CTRL-BREAK/C/K> exits from external batch files, you
may use the this parameter. NOTE: The user cannot interrupt the program
except by hanging up if this is turned on! Under normal conditions, this
option should be left turned OFF! (When left off, the user is sent back to
the BBS when he hits <CTRL-BREAK/C/K>...)
Point 666 - In order to run in "No Points" mode, or to assign a specific
point number to all XRSDoor/XRS users, place a number from 0 up to 32767.
For NO points, use 0. If you want XRSDoor to assign the point numbers in
consectutive order do NOT use this option at all.
Limit 500 - To use a different maximum limit of messages for one mailbag,
assign any number less up to 5000. Normally, XRSDoor will only pack up to
995 messages for each user, anyway - they must set the "<O>ption toggle"
to allow them to select mailbag size if they want more.
Include - Accepts a filename (*with* pathname!) and inserts that file into
the mailbags. You can use "wildcards" to insert multiple files if you wish.
Show PIDs - Makes the ^aPID: lines show up in the XRS mailbags. [These show
up in XRS with XRS version 4.00 and later only!]
MkXRS - Causes XRSDoor to IMMEDIATELY call MkXRS after an incoming mail bag is
uploaded by the user. Mark May's "MkXrs" program can be used to completely
automate all inbound mail processing including netmail accounting and tossing
mail directly into the BBS message databases without using your normal echo
mailmangler. MKXRS103.ZIP is the current released version - it works equally
well on any single or multi-line system, but if you have two or more nodes,
you should have separate "inbound" XRS-mail areas. You can call MKXRS
automatically after each incoming mailbag is inspected for UserRequests by
placing "MKXRS" into your QMXSETUP.CFG file.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 10 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ Continuing the Setup of QMXSETUP.CFG ▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────┘
New Only - Makes the file search show =ONLY= new files - never the five
"most recent" which are the LAST five found in each FILES.BBS listing.
Defer - Disable the internal DSZ downloads (so user can d/l from normal
files area) [NOT NEEDED if OUTPATH is used]
NoLogOff - Disables the logoff by carrier drop for systems running XRSDoor
under Wildcat.
FreeTime xx - Since XRS Door supports file-requests, it is unlikely that most
SysOps will want to continue "*!" free time. A new QMXSETUP.CFG parameter
allows you to give users 'x' minutes of free time - "FreeTime 20" will add 20
minutes to the available time in the door. NOTE HOWEVER, that you most likely
still need to add "*!" to the command-line on the menu, or the BBS software is
liable to terminate the door when time would have normally run out! That way,
the BBS thinks the user has unlimited time, but actually, they get no more
than the remaining time (plus "Freetime" extra minutes if you specify any).
XRSDoor =ALWAYS= calculates the maximum number of messages which a user at any
specific baud rate can get in the remaining time and adjusts the maximum count
down if they would exceed the time limit!
Force xxx - You can force users to read a certain area on your board by
placing a new parameter "FORCE xxx" where 'xxx' = the area *number* you want
to be required reading. Note that XRSDoor doesn't tell the user it is forced
nor display it as part of his list (unless he already selected it), nor will
turning the area off (as many times as he wants <grin>...) work. There can be
up to ten of these in your config file. IMPORTANT NOTE: IF YOU TURN ON A
CONFERENCE WITH "FORCE" ALL READ SECURITY IS IGNORED! (but if the user doesn't
qualify for write access, they cannot reply). Remember - this takes an area
*number* as the argument - not a name.
Lockout xxx - The same way you can "Force xxx" (where 'xxx' = area number)
areas on, you can "Lockout xxx" up to ten areas.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 11 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒ Continuing the Setup of QMXSETUP.CFG ▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────┘
Swap - Swaps to LIM or Disk (current drive and sub-directory using the
filename "SWAP$RQS.!!!") if "SWAP" is in your QMXSETUP.CFG file. XRS swaps
the (less than) 116K memory it uses minus a 4K reloader 'stub' on disk if 112K
of LIM/EMS memory is not found. Swapping is used for all external program
calls including DSZ.COM, MKXRS.EXE and archival programs. Swapping to LIM/EMS
is instantaneous, disk swapping is relative to disk performance but hardly
noticable even on the slowest hard drive, since XRSDoor doesn't have a large
'footprint'. Allowing "Swap" is definitely most useful for multi-node setups
running under DesqView, for example.
No EMS - If you do not want XRSDoor to swap to LIM/EMS (use disk only), put
the "No EMS" parameter into QMXSETUP.CFG to avoid LIM/EMS swapping. This is
useful only in combination with "Swap". (note: if you do not have any EMS
memory, this parameter is not needed - XRSDoor will not try LIM/EMS...) The
only reason I can think of that you might need this is if your LIM/EMS is not
working properly, or you are running a multi-tasker and don't want XRSDoor to
tie up that memory even temporarilly. If you have LIM/EMS but do not have
enough free, XRSDoor will swap to disk instead automatically.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 12 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ A Few Hints ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────────┘
XRSDoor looks for FLSEARCH.QMX - if not found *NO* "New File Search" is done at
all! This way you can just search one or two if that is what you want, or you
can turn it off altogether. If you want it to search all areas, just "COPY
FLSEARCH.CTL FLSEARCH.QMX". (the format of the file is *exactly* like
FLSEARCH.CTL!) If you do not want to search ALL areas, simply copy
FLSEARCH.CTL to FLSEARCH.QMX and then edit out the lists you do not want
included in the search.
You can also automatically restrict the user-side program (XRS) from sending
any mailbags in formats you can't process by placing a file named ARC_ONLY.XRS
(or ZIP_ONLY.XRS, but not both!) into the system subdirectory. When XRS sees
this file it will only use the desired method to pack the mail.
You may "Force" your users to use YOUR origin line if you like. To do this
just create a file called XORIGIN.XRS which contains the desired line in plain
ASCII. If XORIGIN is present, XRSDoor will place a CRC value in the users
file which can be read by XRS version 3.12 or later. This CRC check will not
allow the user to replace YOUR line with one of his own. A CRC check is also
performed on the users name. If either are incorrect XRS will terminate
immediately, assuming that you must have a problem user hacking the files!
XRSDoor recognises the person named in DORINFO?.DEF as the SysOp and always
allows *CRASH* netmail for THAT person. The XRUSERED User Editor will also
allow the SysOp to designate users who may send crash mail by setting the
crash option, for designated users, with the User Editor.
If you are a D'BRIDGE user:
XRSDoor normally puts all files in a directory named \QMX. Assuming that
your inbound mail goes to a directory named \QUICK\MAIL, add the following
to your BBS.BAT file. You may put it after an exit from the BBS or at the
beginning of the batch file if you restart it after each user.
if exist \qmx\*.PKT goto qmxmail
:qmxmail
copy \qmx\*.PKT \quick\mail
echo y | del \qmx\*.*
cd \dbridge
db unpack
At this point, you need to return to the beginning of the batch
file, or wherever else you run DB as your mailer.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 13 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ A Short Check List ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────────┘
Here's a short check list of what we have done.
1. Make sure ALL message areas are listed in AREAS.BBS
2. Create at least one "inbound" directory called \QMX OFF THE ROOT, NOT OFF
the QuickBBS or RA subdirectory! ^^^^^^^^^^^^
3. Add a Menu option to allow your users to access XRSDoor
4. If QuickBBS, add the necessary lines to your BAT file to handle a Type
15 menu option exit. If RemoteAccess, add a type 7 menu option as shown
in the RA section.
5. Add the necessary lines to MOVE incoming XRSDoor mail to your ECHO tossing
directory or setup MkXRS to handle mail tossing (MkXRS recommended!!).
6. Edit QMXSETUP.CFG and place it and XRSDoor.EXE in the system directory.
If running multiline, place a copy of QMXSETUP.CFG in each line's sub-
directory and use a DIFFERENT inbound (\QMX1, \QMX2, etc) command for
each line.
7. Make a copy of FLSEARCH.CTL and name it FLSEARCH.QMX =IF= you want new
files listed. Place it in the system directory.
┌────────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Using XRSDoor on YOUR BBS ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────────┘
Important! Your caller MUST have a CONFIG.SYS file setup on their system
with a FILES equal AT LEAST 20! Failure to do this will cause the XRS
program to be unable to unpack mail. If a user complains about this problem,
that should be the first thing you ask about. They should also download a
small mailbag BEFORE running XRS the first time. XRS will look for mail and
complain if it can't locate any! (this also can cause the program not to
"see" other files that *are* there...)
Your callers will find running XRSDoor basically intuitive. The first time
your user goes into XRSDoor they will be asked to select their default message
areas to read, the message packing method and transfer protocol to be used.
Message area selection must be done before the caller can "Pack for Download".
Unconfigured (new) users are not given the option to download messages UNTIL
they have completed their configuration.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 14 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
When selecting message areas the first time, your users should select from
"All" groups instead of only those which have new messages! This will allow
them to select from all available groups and save these defaults for use every
time until they change them (and not miss any areas that do not have "new"
messages available at the current time).
The users SECURITY level and AUTHORIZATION flags determine the areas from
which users can read or write. If a message area has a higher security level
in READ the user will be unable to select that area to be included in their
mailbag. If the area's security allows the user to read but not to write
in an area, XRSDoor will allow the reader to read but will not allow a reply
to a message or a new message to be written in the area.
The number of messages XRS can handle in one "MailBag" is unlimited, but 5000
is the maximum number of messages XRSDoor will extract before beginning the
archiving process - normally, a caller will probably get much less mail than
that! XRSDoor will normally default to a number that gives the LAST 20%
of the messages FOR A FIRST TIME USER. This prevents a first time caller from
accidentally downloading a packet of ALL the messages! As Sysop, you can set
the maximum limit higher or lower than 995 by using the LIMIT option in your
QMXSETUP.CFG file. (XRS 4.11 or higher is required for > 995 messages)
Note that XRSDoor (and the XRS reader/editor) do not do "exact" matching as far
as upper/lower case letters go! You will always get all messages addressed
to you no matter how the names are capitalized by the sending system!
Unless instructed not to, XRSDoor will ALWAYS automatically extract =ALL= mail
addressed to the caller whether or not they have the message's group selected.
That way, the caller can be assured that they won't miss any mail even if they
don't regularly read certain conferences. This function can be defeated by
selecting an option in the XRSDoor configuration section. The user may elect
to tell XRSDoor =NOT= to scan for messages OUTSIDE the selected areas. This
change is useful if the user calls several boards and doesn't want to receive
duplicates of the same messages from each board.
XRSDoor will NOT extract messages FROM the caller since it assumes they have
seen them before! Your user CAN include their own messages by selecting that
option in the CONFIGURATION OPTIONS menu.
XRSDoor allows a caller to select message areas that have PRIVATE messages.
When scanning these areas, it will =ONLY= pack mail addressed TO THE CALLER
OR MARKED "Public". Private mail to other individuals is NOT included in the
mailbag.
XRSDoor will normally ask if you wish to update the HighMsgRead and/or
LASTREAD.BBS fields, assuming you read new message (you can select "Pack" from
the main menu and "backtrack" to old messages!). You should, in general,
always answer "Yes"! If your user selects the <Q>Uick logoff option, when
packing mail, then the High Message Read fields are updated automatically.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 15 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────┐
│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ XRSDoor User Requests ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │
└────────────────────────────────────────────────────────────────┘
XRS Door supports "UserRequests" which include both an AreaFix-like capability
and the ability to "psuedo-FileRequest" from the BBS (i.e. automate the
download of files by sending a message).
WARNING! IN ORDER TO SUPPORT THIS, XRS MUST HAVE A "PRIVATE" SUBDIRECTORY FOR
EACH NODE YOU HAVE, TO PROCESS INBOUND MAIL AND "CLEANSE" THE MAIL OF MESSAGES
ADDRESSED TO 'XRS' (the UserRequests). FAILURE TO HAVE AN EMPTY SUB-DIRECTORY
AT THE STARTUP OF UPLOADS TO XRS DOOR COULD POTENTIALLY GO INTO A LOOP TRYING
TO PROCESS SOMETHING THAT IT THINKS IS MAIL. XRS DOOR ONLY EXTRACTS *.PKT
FILES FROM USER-UPLOADED MAILBAGS (OR WILL USE "NAKED" *.PKT FILES FROM NON-
MSDOS USERS), AND NUKES THE REST, SO THERE IS NO WAY FOR A "MAIL BOMB" TO GET
BY! (this is the same \QMX - or "InDir xxx" subdirectory you already setup!)
SysOps have total control over User File Requests - a new file "DOWNLOAD.QMX"
which uses the same format as "FLSEARCH.QMX" allows for greater flexibility by
bypassing the normal methods, which would allow SysOps to define only certain
areas as being requestable via XRSDoor. This way you can allows downloads
from areas which are not normally scanned for "new uploads", too. If the
"DOWNLOAD.QMX" file is not found, "FLSEARCH.QMX" is used instead.
To create User Requests, XRS users simply address a message to "XRS" with
requests in the text portion of the message. All forms of requests can be
mixed and matched in a single message, and multiple messages per session are
allowed as well (for now the subject is ignored). Each request must be placed
on a separate line! Each line is checked and interpreted as follows: If a
'.' character is found, the line is always interpreted as a User File Request,
the areas in DOWNLOAD.QMX (or FLSEARCH.QMX if no DOWNLOAD.QMX file exists) for
which the user is eligible are each searched serially until a matching file is
found, then the file is sent using the selected file transfer protocol (with
Z-Modem auto-download, all of this could be easily automated!); otherwise, a
User Message Request is assumed and the program looks through the tables
trying to match either the AREA: tag _or_ the SysOp-defined 'topic' of the
area or if the request is numeric, turns on that area number. Using the area
number is the easiest method. A request to turn an area off is preceeded with
a minus sign. Wildcards and paths are not allowed! If any user requests are
found, a new *.PKT file is built without those messages. Note that the
"LOCAL" (area 0) should be used for User Requests, but XRSDoor intercepts,
interprets and removes them from any message area.
Version 2.00 of "XRSDoor" recognizes the "`" as an "escape" character for
area requests, to force XRSDoor to process it even with a period in the echo
area name (like "comp.pc.prog.c" or whatever) - see examples on next page.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 16 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
Some examples of User Request lines in an XRS message:
-Dr_Debug
C Programming Echo
SOMEFILE.ZIP
*.ZIP
C:\RA\USERS.BBS
XRS450AT.ZIP
78
NEW_ECHO
`comp.pc.biz
The first one would turn off "DR_DEBUG" echo (note - upper/lower/mixed cases
are equivalent, and leading spaces are ignored). The second one (assuming the
SysOp named C_ECHO "C Programming Echo") would turn on an area, the third line
would search DOWNLOAD.QMX for available areas, and attempt to find a matching
file to send in them - it would send it with the user-selected protocol
automatically if found. Both the fourth and fifth requests are invalid - if
any of these characters ('?', '*', ':', '\') are found a file request is
ignored. The next request would send the file XRS450AT.ZIP if it is found in
an eligible area. Next, there is an example of a numeric message area request
- assuming area # 78 is available to you, it would be turned on. The next to
the last one would turn on an area named "NEW_ECHO" assuming it was found and
the level and access flags check out, and the last one uses the "`" override
to turn on an area with a period in the AREA: name (typical in uucp
conferences).
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 17 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
You will want to make the XRS eXpress Response Reader available to your
callers. The Reader comes with it's own documentation included in the
package. Again, there are two versions. One for XT type machines and
one for AT systems. Current versions are XRS413XT.ZIP (generic 8088/8086)
and XRS413AT.ZIP - the V20/30/80286/386 edition, although version 4.50 is
scheduled for release within two weeks of this writing. Overlay versions
are also available. Overlay versions require less memory but will not
run as quickly on slower machines unless they have LIM/EMS or XMS 2.0 RAM.
XRS4CORE.ZIP provides other files needed for ALL versions and =IS REQUIRED=
to use XRS. XRS4xDOC.ZIP contains the documentation and several XRS4KIT?.ZIP
"ToolKit" files provide sample scripts for various communications programs
plus foreign language support overlays and are optional. XCSxxx.ZIP contains
Rudi Kusters' "eXpress Conversion System" which allows greater flexibility!
┌───────────────────────┐
│ ▒▒▒ Odds & Ends ▒▒▒ │
└───────────────────────┘
XRSDoor operates as a pseudo-point system. The callers "point" number is
determined by XRSDoor the first time the user selects any options in the
configuration menu of XRSDoor. The user will be assigned the next consecutive
number above the last assigned XRSDoor user. The information that XRSDoor
needs for each user is kept in a small file named QMX_CONF.SYS. Since XRSDoor
maintains its own data file, you can sort and pack your userlog at any time
without any effect on XRSDoor.
A XRSDoor User editor program is included. (XRUSERED.EXE) This program will
allow you to list your point users and their assigned numbers, and make
changes in their configurations. XRSDoor also places information about how
many messages are downloaded, mailbags received, groups selected and other
information in your LOG file.
As a point of information, XRS uses 30027/xxx as the "From" address in the
outbound message bundles. This has NO effect on your systems actual node
number and can be ignored! ('xxx' always = 0 if running "No Point" mode)
Be sure to add "PointNet 30027" to your echomail processor's configuration
file if you run in 'secure' mode! This pseudo "PointNet" number was (and
other pointnet numbers are) assigned by the Zone Coordinator.
XRSDoor watches the users input and features an automatic user entry timeout
set at three minutes. This is integrated in the FOSSIL input routines. After
two minutes with no activity, the program will beep three times signaling that
it is waiting for input. If another full minute elapses without any response,
the program is terminated.
XRSDoor looks for the file named "EXPRESS.BBS" and copies it into the top of
SUMMARY1.XRS each time the program is run. This allows you to have a custom
BBS "banner" of special message that will pop up in the users' editor <F6>
summary window every time! You should not use color graphics in this file,
since the summary routine pokes characters into memory for speed and therefore
does not allow for ANSI interpretation... This allows you to have a special
announcement capability for XRSDoor/XRS users. You could place notices of new
versions being available in there, as well.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 18 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
The file CURR_VER.XRS (which accepts up to 64 characters) is displayed for all
users so they know what the latest version is (of XRS). (sample CURR_VER.XRS
included) For RA systems, a single copy of this file should be kept in your
"System" subdirectory.
A short 'PROMO' file is included, for your use, to announce the addition of
RemoteAccess/QuickBBS Message eXpress to your system. You'll find it included
as BULLETIN.ASC, should you want to use it in your 'NEWS.ASC' or
'BULLETIN.ASC' files.
We think you going to like this new way for your callers to communicate with
your system! It allows your best and most active users to get on, get their
mail and get off in much less time.
If you have questions, suggestions or problems, we'll be happy to help!
A FidoNet "EchoMail" conference with AREA: tag "QMX_XRS" is available from
the echomail "backbone" system. You'll find lots of friendly help and lively
discussion of topics of interest to XRSDoor SysOps in this conference. You
should be able to get connected easily via your local Network Echo
Coordinator!
Note: native Dutch message & help overlays for XRS (Peter Janssen and friends)
and Dutch language documentation by Rudi Kusters is available, making XRS
truly multi-lingual. French, German and Swedish are also available. If you
need one of these for XRS, Contact Mike Ratledge for further details. Using
a "Foreign Native Language Support" binary overlay simply involves replacing
the standard (English) XRS$ALL.DTA file with another one (written in your own
native language), and then XRS will be completely converted to your language.
┌─────────────────────────────────────────────────────────────────────────────┐
│ ▒▒▒ XRSDoor ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ PAGE 19 ▒▒▒ │
└─────────────────────────────────────────────────────────────────────────────┘
┌───────────────────┐
│ ▒▒▒ Credits ▒▒▒ │
└───────────────────┘
Documentation for RemoteAccess/QuickBBS Mail/SuperBBS eXpress module
written by: Ed Meloan, Sysop of The Augusta Forum RemoteAccess system
(1:360/0, 1:360/1) and Michael Y. Ratledge, dated May 5, 1991.
(C) CopyRight 1989, 1990, 1991 by Michael Y. Ratledge, CDP, CSP, SysOp
of East Bay X-Change Multi-Node RemoteAccess BBS in Charleston, SC, USA
FidoNet addresses: 1/112, 372/666, 372/888, 372/6666 or via Compuserve
at Compuserve Information System ID: 76666/1512.