ROSErver/PRMBS 
Ver 1.76 01/31/93

- For now we will be switching back to continent designators in the
  H_LIST (aaaarrrggghhhhh - sound of teeth knashing!!!!!!!!!!!) Please
  make sure you have all your users do a  HOME {yourcall w/o h-addr}
  and let the new H_LIST do the addressing. Also make sure your OCALL
  in the CONFIG file matches exactly - once this is done by you and your
  regular users the superfluous occurrences of the "Reply-to:" line in
  the 822 headers will disappear.

- some timing improvements, slight but noticeable. 

- had a couple of sysops with some complex connect scripts so I elarged the
script buffer from 512 bytes to 640 bytes and from 16 lines max entries to
24 lines max entries - remember the 24 lines is still subject to 640 bytes
max - the line end in each case takes up a byte (so the line ".C KD1R" is 7
bytes plus 1 for line end - 8 bytes!)

- in the REQVER reply the version was sloppy "ver175" changed to "ver 175"

- In all of the CONFIG and TRANSLATE files now a TAB is accepted as a SPACE.

- HELP now has normal paging line counts like READ and LIST. 

  ***** Make Sure that the NEWUSER entry has less than 23 lines!!! *****

- SYSOP must now type his call for login. CR at "login:" will get 
a re-display of request. 

- When logging in on a closed system (modem/console with OPENLOGIN OFF) or 
REGISTERED USERS ONLY port get message "restricted access port". For
BBS ONLY you get that message unless your are BBS, LOCALUSER or SYSOP.

- When SYSOP Logs in from modem he gets Remote SYSOP status, not LOCAL.

- Old Bug, when a newuser logs in on BBS-only he gets the HELP NEWUSER
and then gets booted.  he now just gest booted - dats da breaks!

- When EXPORTing Mail - a ~GET would only work if its was  "~GET xxxxx"
it is now corrected to take "~GETxxxxx" OR "~GET xxxxx"

- When logged into the system as Remote Sysop or Superuser, regardless of
access means, i.e. modem, tnc, console, the "Flood pointers to" messages
will now go to you, if as Remote User (peon or forwarding BBS) it will
display only to local console.

- TRANSLAT.RS may now have a message title string search qualifier.  It
works like this, the first field is the translate search field following
all the rules of the past, the second field is the translate to field also
following all rules of the past. Up to 8 additional fields may be
OPTIONALLY appended. If one or more fields after the first two are present
they is used to make a CASE-INSENSITIVE search of the message title. If any
of the strings of the subsequent fields are found in the title the
translation is made, if it is not found NO translation is made.  FOR
EXAMPLE;

         *@* WANTED@* want "looking for" need "trying to find"

  *** NOTE - the quotes may be used to set a search for mutliple word
      strings with white space included.

  This example will translate any bulletin coming in regardless of inbound
TO field to WANTED, IF the title contains the words WANT or NEED or the
phrases "looking for" or "trying to find" (remember CASE doesn't matter here)

   This will work only in the TRANSLAT.RS files. The manner in which I
coded it I have locked the feature out from the USER translate files and
the ZIP Code files.

   The feature works on all incoming messages, either forwarded, locally
orginated, make message command, translate command, and X command from
message sweeper on already made messages.

**** I have included a copy of my actual on the air TRANSLAT.RS file in the
update package for a sample. This one worls great ... my time editing
headers is minimal.

Comments:
   I believe this new translate function will singled handedly triple the
usefulness of the RN, READNEWS command by helping automate a lot of the
handwork the sysops have had to do in the past. Other systems have
functions something like this though many of them are offline features
and/or changes made to the translate tables require dropping the BBS and
restarting to make active.

   While all of this translation takes time, it occurrs during all that disk
chugging after the title is accepted but before the body of the message
appears to someone observing the console - seemingly it slows message
reception way down - in reality it doesn't. You should also have noticed
that the first 6-12 headers to appear come out lickety-split ... thgats
because either MBBIOS or BPQ has been receiving and buffering them the whole
time so no time is lost. Even on my slow XT class operational BBS I have never
seen an entire message pop out after the translation time there is always
some more to wait for!

- system no longer checks for too many digipeaters, the field is still in
the port descriptors but is not acted upon. Will remove altogether in the
final release which I expect will be v1.80.

 *** WARNING *** a little known feature of RMAIL but used often by those
who know is that you may embed a BID in an RMAIL message in order to move a
bulletin in such a way to bypass a potentially troublesome intermediate
sysop or for some other reasons. there are some quirks in the current
implementation that I discovered and will work on next. For now be advised
of the following;

If you type ===>  RMAIL @KB7UV$PRMBS1234  PRMBS@WW

    - the system will properly expand  KB7UV from H_LIST but will LOSE 
      the BID; it will not show on the RFC_822 line

If you type ===>   RMAIL @KB7UV.#NLI.NY.USA.NA$PRMBS1234 PRMBS@WW

    - the system will include the BID where it should be!


 73 de brian