This satisfies the requirements of programs written by other
coders which extract information from these headers as well as
the general sysop and who gains insight into the network by
examining headers. It tells when the message went through/was
created on the system. It gives full H-route information for
the system, it gives detailes local information (city, state,
zip) and network location nearest network node.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 10
My recent experiences exploring the network shows that for
the most part if you can get into a node in the state (or sub-
region if state has that much packet activity) shown in the H-
route address you will find the node shown in the header on its
tables.
The city show in the header will be the QTH from the sysop's
user log entry truncated at first encountered comma from the
front. The H-route address will show the state and country.
FLOOD Messages and DISTRIBution FLOOD Messages and DISTRIBution FLOOD Messages and DISTRIBution _____ ________ ___ ____________ _____ ________ ___ ____________ _____ ________ ___ ____________
FLOOD messages are handled by pointer files (.FLD) Quite
simply the incoming message or the message object of a FLOOD
command from console or event process has its @BBS filed checked
against the directory containing the pointers; if a match is
found the file is opened and each call listed gets a pointer
entry in MAIL.DAT for each BBS in the file. The "R:" headers of
the inbound messages are checked against these calls so that no
pointers are setup for any system that has already seen the
message. The 'pointer' consists of a new message number entry,
with the identical TO@BBS and the route name is the BBS that is
to receive the bulletin. The message text file contains a "~GET
mail\msg#####.mai" pointing at the text of the original message.
There is an F-status field which gets marked with a '$' to signi-
fy the 'flood' status of the message pointer. When you connect to
a system the F-status being '$' prevents any pointer being sent
unless the route explicitly matches the system connected to.
There is no point in setting pointers to stations three BBSes
away, let the others along the way do the flooding!!
The FLOOD command takes arguments like READ and KILL, i.e.
it accepts single numbers a specific messages to flood, and
ranges of numbers. The FLOOD command can be used to do your
flooding as part of the EVENT file. You would set the FLOOD
option in CONFIG to NO for no automatic generation of flood
pointers then set a sequence in the EVENT file that might look
like;
M 0100 DISTRIB ROUTE1 ROUTE2
M 0100 EXPORT TFILE ROUTE3 ROUTE4
D 0100 SOMEPROG TFILE OFILE
M 0100 IMPORT OFILE
M 0100 DEL TFILE OFILE
M 0100 FLOOD -N ALL
The "ALL' is a special case that substitutes the entire range of
numbers ad the "-N" says only operate on unprocessed messages
(status = N), The FLOOD process changes the status to "F" so
there's no worries about 'perpetual motion' in message genera-
tion. The idea is to run DISTRIB and / or some program you wrote
(first exporting selected messages to a file then importing the
results) against various routes and when is all done, then proc-
essing the results and remains for flooding.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 11
Speaking of DISTRIB, there may be some confusion over the
difference between DISTRIB and the FLOOD process. DISTRIB is used
when a message is needed to be sent to several recipients or
groups of recipients. It is a process whereby one message is
entered and a control file (.DST) specifies the messages to be
created. The details are covered in the reference manual, but the
concepts I will discuss below.
The Distribution files are 6 character file names with
extension .DST, so the file below which is for PHOTOG would be
named PHOTOG.DST (these files will be found in the SYS
directory).
w2xxx
w3yyy
w4rrr
w1aar@wb2mic
rmail@kb1bd
aa4re
n2evw
alldx@wb2qja
*** EOF
rmail@wb2mnf
alldx@ka2bqe
k2adj
*** EOF
alldx@w1aw
Basically a message or series of messages are exported from
ROSERVER via the export command. They will come out with TO,
FROM, AT, and MSGID.
The messages will be 'imported' into ROSEDIST where the SEND
line will be parsed. The @BBS field will be used to make a file
name by appending ".DST" to it. If ROSEDIST cannot find that
file, the message is simply 'passed through' untouched, from the
input file to the output file.
Assuming now that we find the file, we will then take the
message and read down to the "To:" line in the internal headers,
or the end of headers if there is none. We will store all that
material in a the first of two temporary files. WE then will read
from that point to the line with "/EX" and store that in a second
temporary file. The "To:" line, if it was present, is lost at
this point.
We read the DST file and take it in line by line. The DST
file can have the following kinds of record entries:
- BBSCALL this simply created as a message with TO
filled in from the TO of the source message.
- CALL@BBSCALL created with the CALL and BBS specified.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 12
- CALL@ - will place message in with this as the TO
and no @BBS
- RMAIL@BBSCALL makes an RMAIL message with next sequential
ID from local system. Reads subsequent lines to a "*** EOF"
to pick up target addressees;
- BBSCALL - takes the TO of source message
- CALL@BBSCALL - takes this explicitly
- CALL@ - this call with no @BBS
** '$' used inside 'rmail' specs will be ignored) **
- $RMAIL@BBSCALL - identical to the the above, except the
BID from the source message is added to the "To:" line
(i.e.;
To: rmail@bbscall$XXX_000, call@bbscall, .....
After everything is ready, the message type character, if it
is not a 'T' will be defaulted to 'B' and then the TO field will
be tested against "SYSOP", RMAIL", "REQxxx", "WP", and for valid
ham / mars / cap / C.G. Aux call format and the message type will
be made into a 'P' if it passes.
A typical execution of DISTRIB might go like:
distrib ALLUSA MDCBBS MBLBBS RATS HARC
The 'distrib' command does, in effect, an EXPORT, dirstrib
processing, an import and an erase of the temporary work files.
The DISTRIB command from the mailbox does a lot in one command
line, and you do not have to remember options and erase file
names, etc.
** NOTE ** there is currently (as of 7/1/90) a conflict with the
AA4RE REBBS code and DISTRIB. I will explain.
The power of a DISTRIB comes mostly from the idea that a
cnetral mail server running PRMBS can receive single messages
from an outlying mailbox and then the distrib process geneates
the multiple messages as appropriate. Strictly speaking what
happens is accountability correct. A message is created by K2UK
in Haddonfield, NJ addressed MARCO@WA2VXT. The message receives
an "R:" header containing a message ID that matches its orginal
MID. The message is forwarded to WB2MNF in Medford where it
recieves am "R:" header with its local ID on MNF. Then to WA2VXT
where it gest its local ID. All the while it is passing through
IDentified by its original MID since its addressing has not
changed. Now after it arrives at WA2VXT it gets selected by for
DISTRIBution processing and the MARCO.DS file is consulted and
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 13
several individual messages, plus several RMAIL messages are
generated. The adressing has chnaged and now there are several
actual messages. Each messages has an "R:" headr with a different
ID which is proper. Viewing the "R:" headers of any of the mes-
sages at anypoint from now will show exactly where/when/how the
message has been handled. The accountability is preserved.
Now the trouble begins. Regardless if the messages as they
progress down the way pass through MID capable system and the MID
assigned and sent on the SEND lines is preserved, if two or more
of these messages go through a REBBS system eveything after the
first will be flagged as a dupe based on the first "R:" header
ID. This happens regardless of the re-assigned MIDs on the send
lines. The message doesn't die, but it will be held for manual
intervention by sysop.
For now then you will need to be cognizant of what kind of
BBses will have this mail passed through until Roy (AA4RE) can
resolve the matter. His concept, which I feel is flawed, is a
genuine attempt to cut down on duped messages with inadvertently
When a message is 'killed' its status is merely changed from
whatever it was to 'K'. The message remains, it may be listed,
edited, read, etc by using a "-k" option. To remove the message
from the system, irrevocably you must invoke the COMPRESS com-
mand.
The COMPRESS command will actually compress the mail file
rewriting only message records whose status is not 'K'.
Archiving messages is done using the FILE command to do a
message to file appending to an ASCII text file. Two forms gener-
ally may be done;
FILE -K -T ALL
FILE -K -T -F TRAFFIC.KLD ALL
FILE -K ALL
FILE -K -F OLDMAIL.KLD ALL
The '-t' indicates traffic only, and '-k' means killed mes-
sages only when both used it takes killed traffic or without the
'-t' it gets the all killed messages.
Additonally the '-s' search option could be used if you
wished to archive certain topics
FILE -B -S MODS -F FILES\MODS\MODS.TXT ALL
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 20
K> -B -Z MODS 1
COMPRESS
After you are done doing any archiving, particularly if you are
doing this in an EVENT process you will want to run the COMPRESS
command to remove the killed messages so they will not be ar-
chived redundantly on another event cycle.
Concepts of Mail Forwarding in PRMBS Concepts of Mail Forwarding in PRMBS Concepts of Mail Forwarding in PRMBS ________ __ ____ __________ __ _____ ________ __ ____ __________ __ _____ ________ __ ____ __________ __ _____
The PRMBS system will accept mail addressed in almost any
fashion and will do its best to send it to where it belongs. A
few rules are used.
When the messages is entered it will be checked, if local,
against the orginator's personal translate files for more com-
plete address. It will then be checked against the system trans-
late file and last if its all numbers (i.e. US type Zipcodes) it
will be checked against a ZIP to H-route location file. If it is
not numbers and if no @ address is present the recipient will be
checked against the active user file and his proper home BBS if
other than your system, will be inserted.
Message IDs are used to eliminate duplication. On flooded
bulletins we call them 'BID's - bulletin IDs, on other than flood
messages we call them 'MID's - message IDs; generally, the rules
for assigning IDs are as follows;
** general rule ** - use em if ya have em, don't go looking!
a - all messages orginating on the system
b - all REQxxx responses (technically same as 'a' above)
c - any RMAIL generated message
d - any message incoming which gets 'translated' in the to/at
fields upon arrival
e - any message addressed to that system which re-addressed
via USER.DAT entry
f - any message in which translation occurrs when manually
re-transalted and/or re-routed via the 'X' option in
sweeper or 'translat' command.
- no message IDs will be 'parsed' out of "R:" headers
- MIDS sent only to stations with 'M" in the [SID].
- in receiving, floods BIDs/MIDS differentiated by the @BBS
field matching an existing flood route. This determines if
the ID gets re-assigned if translation occurs (MIDs) or not
(BIDs)
- outbound messages that are flood pointers (F stat field is
'$') will get 'K'illed if NO interpretted as dupe recieved,
if not flood pointers it gets a status of 'D'upe.
This gone into in more detail several paragrpahs down from
here concerning simple and improved response to IDed messages.
After all this is done, if there is an @ address it will be
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 21
parsed against the HROUTES list to obtain a route name. In doing
this we establish 'vectors' for the mail based upon geography
that we call ROUTEs.
When we connect to, or are connected to by another system
and we forward mail to that system the following mail will be
sent;
- any messages whose route is the same as that system's call
- any flood message (F status field is '$') whose route is
the same as the call of the connected station.
- any non-flood messages whose route name is contained in a
file CALL.FWD (CALL being that stations call), if it exists.
*** the above imply a ROUTE field filled in and matched ***
- any message whose ADDRESSEE (i.e. contents of the TO
field) is the same as the station connected to, regardless
of the @BBS address contents.
Reading between the lines above, we will not forward any
mail without an @BBS filed filled in, and by implication no route
gets entered when no @BBS is filled in.
To acheive the actual export of messages from your system to
another there are several mechanisms;
EXPORT - forwards mail into an ASCII text file in EXPORT format
FWD - forwards mail via COM port to another system
SWAP - the same as FWD only afterwards it POLLs for mail from
POLL - the same as SWAP except it connects and POLL regard
less of outbound mail status, then acts like a SWAP.
POLLF - POLL FOR - polls for the mail for other systems, as if
they were these other systems actually connecting
PUSH - essentially a SWAP command that always connects, if
no outbound mail, it does a POLL. (useful for
non-PRMBS systemsthat DISConnect as soon as a POLL is
done)
When an export cycle starts, all of the applicable routes
are read into a memory table. The mail file is then accessed ONCE
starting from oldest to newest messages and as soon as an unread
message (status is 'N') is found who matches one of the above
criteria, the system will make a connection, if one has not yet
been established and begin to forward that message. After that
message is done, it will go on until all messages that meet the
criteria have been sent or until a disconnect is detected. Then
it will poll for mail from the other system and make an attempt
to see if the mail received in polling generated any messages to
go back, it will make one more attempt to send and one more poll.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 22
Advancing in this sequence to each stage is dependent upon the
prior step having actually moved one or more messages or else
there's no reason to go on. In addition if you are in a multi-
user (DDOS or DesqView) environment, another task may have creat-
ed more mail to be moved.
The above assumes tha you are simply forwarding mail regard-
less of type. If you chose to use the "-t" option which will
specify what specific and in what order the types of mail will be
forwarded. In this case you will then make one pass through the
mail file for each type specified.
Export to a file works the same, except it one pass only, no
polling of course.
One benefit of this scheme which can be a real problem in
other codes is that old messages do not get 'shut out' if they
didn't move and then a lot of mail comes in since many of the
other systems examine the mail file last first! PRMBS will always
move oldest mail first. If you have some concern about old bulle-
tins timing out and elaying private messages you can use "-t tpb"
option to specify private and traffic to be sent before bulle-
tins.
A mail forwarding cycle begins with a connection and an
exchange of the [SID]s (smart system identifiers). The standards
for this are:
[sysId-disk space-version-params]
For example:
[4RE-ver-HMR$] AA4RE Multi-user BBS
[AmigaBBS-$] N3ET - Amiga BBS
[MBL-$] WA7MBL BBS
[NET-$] RLI MailBox for KA9Q's TCP/IP
[PRMBS-space-ver-HMR$] KA2BQE PRMBS/ROSERVER
[RLI-ver-HC$] W0RLI
[CBBS-ver-C$] CBBS - k3rli
disk space - optional - amount of space available on system
in Kbytes for messages.
version - optional field - version of code
params - last field, parsed as last field,
0 - I am smart enough only to recognize that you are
smart, but I am dumb on all other counts and can do
nothing.
$ - general smart system ID , supports F>, and OK/NO
for message send, and accepts $BIDs.
C - remote time setting capability
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 23
H - accepts hierarchical routing
M - message ID's exchanged via OK/NO handshake.
R - 'improved' response - handles OK/NO/LATER/REJECT
instead of just OK/NO.
W - white pages serve code active, generates data and
fields request for home addressing of messages passing
through.
Y - (WA7MBL requests this letter be reserved for YAPP-
mail)
The smart-system ID shall contain no white space and shall
be set off by square brackets. Any prompts, CTEXT, BTEXT
concocted by a sysop should not contain a string set off by
square brackets.
Unlike some other systems, PRMBS only accepts a [SID] one
time during the session and then on the first or second (on
the second command line, only if the first was a '*** LINKED
to W1XXX' type line) code line received. Additional [SID]s
received will be treated as bad commands.
After the SIDs are accepted/exchanged a BBS prompt ('>') is
tendered and the sending station issues the "Sx ............."
line. The receieving station then replies with an OK/NO and the
sending station acts upon it.
The '$' in the [SID] denotes acceptance of the simple re-
sponse capability of OK/NO. However, PRMBS has implemented the
'improved response' mode ( [SID] identifier 'R') . That is that
when a message is offered to or from it the range of response
generated/perceived is now OK/NO/LATER/REJECT, each entailing
different actions. Simple response and improved response each act
on OK/NO the same, the improved response adds LATER and REJECT;
OK - send the message I will accept it
NO - do not send the message I already have it. If this was
a flood bulletin, the message will be disposed of, if
it was non-flood, the message will be marked with a
status of 'D' for dupe so the sysop may examine it
before killing it. Marked 'D' PRMBS will not try to
send it again.
LATER - used by some systems indicating it may already have
the message but not sure (i.e. on multi-user systems
the BID may have been tendered on another channel but
bulletin hasn't been fully recieved. I this case the
system will try again 'later' and send it, probably to
be greeted with a NO but just maybe the other guy timed
out and you are now the real thing. Message status
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 24
remains unchanged.
REJECT - I cannot accept this message for some other reason.
Message status is marked as 'R' but it will still
be attempted to be forwarded. The 'R' marking brings it
to SYSOP attention.
PRMBS handles one more case that has no definition for now.
In reality, the situtaion is a violation of protocol, but we
handle it. The W0RLI-compatible BBS built into the KA9Q TCP/IP
suite (NET.EXE), with a [SID] of "[NET-$]", coded by KA1SYF
checks the @BBS field of incoming message and if that system is
not in HOSTS.NET will issue a NO even to a non-MID/non-BID mes-
sage. If PRMBS connects to any system without MID identifier
('M') and send a message without a MID and gets a no, it marks it
as rejected as above in improved response.
System Supervisory Messages System Supervisory Messages System Supervisory Messages ______ ___________ ________ ______ ___________ ________ ______ ___________ ________
The system has a file containing the text of all the super-
visory and error messages (SYS\MESSAGES.RS). As delivered it is
in English. It may be copied to another file, say,
SYDS\MESSAGES.F and translated to French, or german (SYS\MES-
SAGES.G). Conversely it may be renamed to SYS\MESSAGES.E and a
French Translation be copied into SYS\MESSAGES.RS. The user
command LANGUAGE followed by a letter (F,G,E, ect) will select
what file the system uses to speak with him and is selected at
Login time. Within the MESSAGES file is an message in which you
will want to list the files you have available on your systems
and what letter to use to select it.
The message in the file contain tokens "$x' x being a letter
number or symbol. The following table details the information
that each symbol will cause to be printed;
$A : Message - @BBS field
$B : Message - type
$C : Message header - next available number
$D : System - Current date - YYMMDD format
$E : System - Name for that port (i.e. 145.07 MHz)
$F : System - sysop QTH
$G : Message - TO field
$H : skips CR/LF - so input type on line with prompt
$I : User - name
$J : Message - date entered this system
$K : Message - time entered this system
$L : Message header - highest numbered message on this system
$M : Message - number this message (5 digits unsigned integer)
$N : Message header - number messages active on this system
$O : System - sysop call sign
$P : Message - FROM field
$Q : System - disk space available
$R : System - version number
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 25
$S : System output general token variable (set internally)
$T : System - current time - HHMM 24 hour format
$U : User - call sign
$V : System - string ' *** '
$W : System - sysop's name
$X : User - most recent date of connect
$Y : User - most recent time of connect
$Z : User - highest message read
$$ : System - output a '$'
$1 : User - home QTH
$2 : User - home Zip code
$3 : System - date/time in long ARPA format
$4 : System - mailbox version date
$5 : System - full host system H- address
$6 : User - highest message read this session
$7 : System - port ID letter
$8 : System - Message ID
$9 : Message - route
$# : System - name of temp message file - variable named 'msgtemp'
$! : System - name of temp message file - variable named 'msgtmp2'
$> : System - name of user file directory - variable named 'usrdir'
$< : System - name of system file directory - variable named 'sysdir'
$[ : System - current active port timeout value
$] : Message - size
$* : Message - type
$% : Format - output an extra CR/LF sequence
$@ : User - home bbs
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 26
System EVENT Cycle System EVENT Cycle System EVENT Cycle ______ _____ _____ ______ _____ _____ ______ _____ _____
Another core process to the system is the EVENT process.
Unlike other systems, PRMBS provides what amounts to being a
complete batch processor. ANY mailbox command can be executed in
the cycle. Technically the EVENT processor can call itself and
process yet anothe batch file from within itself, and that second
file could call yet another event file and so on .... however,
lets be reasonable ... sooner or later the system STACK is gonna
barf all over your birthday cake if you get carried away here!
The EVENT processor is scheduled by invoking in your AUTOE-
VENT section of your configuration file the command:
EVENT -S {cycle length} {start minute} {offset}
cycle length - length of cycle in mnutes
start minute - relative to start of cycle in minutes
offset - if start delayed, how long beyond 'start
minute' and still ok to execute.
Cycle lengths are base on 0000 hours. And the cycle takes
time now, coverts it to minutes, does modulus arithmatic on it
using the cycle length and whats left is the relative minute of
the cycle the time now represents; for example it is 1609 local
now, thats 2009z. Which is 60*20+9 or 1209 minutes. If we had a
120 minute cycle we would be 9 minutes into the 11th cycle. If we
had set up "EVENT -S 120 1 10" we could kick off the event
cycle. As a rule of thumb the longer the cycle (i.e. the less
often it runs) the longer the offset may be.
EVENT file entries have a time range associated with them,
so if you wish to execute your event cycle and ignore the time
ranges shown you type "EVENT -I".
The EVENT cycle uses a configuration file specified file. If
you want to execute a different file you may type "EVENT file-
name". This does not change the file automatically executed by
timer, just the one done immediately. The system will expect to
find the file in he system directory. However, when the "-f"
option is used by the event command to specify an alternate file
it may be from any drive or directory. The sample EVENT process
format is:
M 0100 command arg1 .... argn
D 0100 dos_command arg1 ... argn
P 0100 port_letter
device_command
device_command
.......
device_command
device_command
*** EOF
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 27
An "M" command is any mailbox command, "D" is a DOS command, and
"P" are commands to the device on the port. The time specs have
the following form:
X sseem
| | | +----- modifier, may be E, O, 3,4,6,8
| | +------- end hour
| +--------- start hour
+----------- command type may be M, D, P
The start hour, end hours are two digits (zero padded) that
indicate the start and end hours inclusive; 0100 is 24 hours from
01 around to 00 (24). 2205 would be from 22 through 00 to 05
inclusive.
The 'modifier' is used to select hours in the range., E and
O are for even and odd hours only. The 3,4,6,8 mean only hours
evenly divisible by that number; For example, 01224 will happen
at 04, 08, 12, 16, 20 hours.
Event command types are D, M, P - the 'D' is DOS commands,
which will be sub-run as a child process, arguments are placed
upon the line with it. If the process requires being in a differ-
ent directory etc, then use the 'D' command to invoke a BAT file.
'P' are port commands. They are sent as series of commands con-
tained in the EVENT file and terminated by a line with "*** EOF".
The last is 'M' and these are mailbox commands. Quite simply
anything you can type in on the BBS command line can be run here.
SYSOP Intervention and CONTROL SYSOP Intervention and CONTROL SYSOP Intervention and CONTROL _____ ____________ ___ _______ _____ ____________ ___ _______ _____ ____________ ___ _______
One of the things which sets ROSERVER apart from all the
other systems is the degree of control programmed into it. The
sysop should not be a second class citizen to the user or to the
computer. In almost all the other systems once some action has
started the only control exerted by the sysop is at the bbs
prompt after it is completed. (this may have changed in some of
the others by now, but I am not holding my breath!)
I have provided the SYSOP with two function keys by which he
can bring any action to a halt. (That is save for pulling the
plug, shutting the switch off, or ctl-alt-del !)
'F' - this is the 'TWIT'-key, properly called the 'forced
timeout' key. It is checked in the 'get line of data' rou-
tine constantly. Basically, what it does is when depressed
it sets a flag indicating that the timeout for data has oc
curred regardless of how much or little time as actually
left. Then the system does its thing normally.
ESC - is also the 'text killer' key. This key will stop any
text output to console or to the com port, files, messages,
message lists, etc. It will also stop reading an event
script.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 28
A combination of these two keys can stop any action. ESC to
kill the text going out, then a quick 'F' to kill the connection,
the disconnect usually kills, the connection before the CTL-Z
gets to the nearest NETROM (remember NETROM sends all packets
onward BEFORE it dumps the connection when it detects your dis-
connect.
Additionally there are a few more keys that are handy:
'X' - this key when struck in the online-waiting mode will
effectivly generate an exit with ERRORLEVEL 100 command, as
if the sysop had hit ESCape, logged in and type "X 100". If
the PBBS.BAT file is set up as the sample was, the BBS will
not cycle, but will exit out to DOS. THIS IS THE SIMPLEST,
SAFEST, MOST EFFECTIVE WAY TO BRING DOWN THE BBS. It makes
sure all the ports are closed and set to CONOK OFF, MON OFF
(important - overflowing data from TNC on back channel can
crash many TNC's) and DTR is dropped to any landline modems.
CTRL-W - during any text download, which may scroll the
status bar off the screen, this key will display the status
bar telling you who is on, the time now and if you have nay
new mail to you or new messages in general.
'!' - this will 'shell' the sysop (local user) to DOS from
within the mail box. It is the functional equivalent of
doing an ESC up to local console mode and then an '!' to
shell to DOS. type 'EXIT' from DOS to return to the mailbox,
disk space is recomputed and "mail for: " banner is re-
created.
'Q' - forces event cycle to happen at that instant. If any
event is not an every hour occurrence the hour references
will be observed. When completed, it goes back on line. This
is an exact functional equivalent to doing an ESC to local
console and an "event". For time overrides you will need to
do an ESC and an "event -i" (see command explanations for
"event").
ESC - is also used to break on a user and chat with him/her.
Now chat is really no different than terminal mode, they
both use the same routine. The ESC is also used to come up
from the terminal emulator. If you were in terminal mode and
it was you logged onto the console ESC simply returns you to
console BBS prompt, closing any terminal output file you may
have opened. If you were chatting with user, it comes back
up checking for connect status, if disconnected it logs user
out, puts BBS back online. If not, it returns a BBS prompt
to user.
'L' - this will allow the sysop to make a quick query of the
system while its online waiting without the need to take the
system off-line. In effect it will do a "LL 20" and list the
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 29
last 20 messages in normal short list format. It will not
shut down the ports or anything else, so a connect that
should come in during the 2-4 seconds this takes will not be
lost.
'H' - this will do 'heard' list (or J-list in W0RLI par-
lance) and like the 'L' it saves the trouble of going off-
line, login, heard, back on line. all the considerations
mentioned in the 'L' apply here.
'M' - will do a LIST MINE of unread mail for the sysop.
'T' - timeout reset key - this will at any point the system
is waiting for some input from non-local user, will reset
the timeout counter to strat again, This is handy when you
have been receiving or sending a message over a congetsed
channel and that inner sixth sense a sysop gets about im-
pending doom (i.e. about to get axed due to timeout) come
upon you, just whack the T and the count will start again
from the top.
<SPACE BAR>
<ctrl-S/ctrl-Q> - these two sets of keys may be used by the
sysop to throttle displays. The ctrl-S/ctrl-Q are standard
XOFF/XON, and are coded 'correctly' , that is to say, a
ctrl-S to throttle output MUST be followed by a ctrl-Q, NOT
just any character. The <SPACE BAR> functions by itself like
the ctrl-S/ctrl-Q, once hit and output throttled the <SPACE
BAR> must be hit again to restart output.
'A' - these two letter commands will cause the command "dir
a:" to be sub-run to DOS to give q uicky dir of a diskette
in those drives.
*** NOTE *** for the 'A', 'H', 'L', and 'M' commands the
ports are NOT shut down, etc. So monitored packets may build
up. These are just quick and dirty accesses to mailBox and
DOS to save the sysop the trouble of having to take down the
BBS for a simple query or housekeeping chore.
'!' - closes the ports and drops to DOS. To return to the
BBS simply type EXIT from DOS and the BBS will be back
online. The BBS is in RAM the whole time so you will have
2-300K less RAM space to work with.
'?' - generates a menu of these commands.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 30
System Parameter Summary System Parameter Summary System Parameter Summary ______ _________ _______ ______ _________ _______ ______ _________ _______
Most all of the systems operational parameters are set by
the command line using the SETPARM command.
AUTOFLOOD ON/OFF if set ON, flood bulletin pointer will
be generated immediately and automatic-
ly.
BELL ON/OFF determines if bell character will ring at
local console, saves sysops sanity and
marriage. (does not effect CHAT bell if
that feature is turned ON)
BULLEXPIRE ### if non zero it will determine max age, in
days relative to current date for a
bulletin. if it has expired, it is marked
as status'h' - held.
CHAT ON/OFF determines whether sysop will be paged or
user is told to send message immediately.
FORCETYPE ON/OFF If ON it will not allow un-typed message.
all messages not entered as ST SB or SP
will be forced to be either a P or B.
Useful for system where they want inter-
personal mail (i.e. from hamcall to ham-
call to be 'public'.
FORWARDKILL ON/OFF when ON the Textfile of message forwarded
out and marked for killing is erased im-
mediately, not waiting for COMPRESS to
be run. ** WARNING ** this is an irevoca-
ble action, unless caught immediately,
even an UN-ERASE is not likely to salvage
a forwarded text.
HOLDMAIL ON/OFF when ON a series of files HOLDTO.RS,
HOLDFROM.RS and HOLDAT.RS are checked
against the TO/FROM/AT of incoming mes-
sage. If a match (wildcards permitted)
messageis marked status 'H' - held.
HOLDSYSOPMAIL ON/OFF If ON inbound mail for the SYSOP will be
held regardless of @address and no re-
addressing done.
LOGGING ON/OFF If ON logging is activated
LOGMSGSONLY ON/OFF If ON messageactions onl are logged
LOGLOCAL ON/OFF If ON local console actions are logged
LONGIHEADER ON/OFF If ON full RFC-822 header is implemented on
locally generated messages. If OFF, an
abbreviated form is used.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 31
LONGRHEADER ON/OFF If ON full "R:" header is used. If OFF, the
abbreviated form with date, msg# and host
address is used.
MAXERROR ### set maximum number of consecutive errors
before disconnect. While it does serve as
a TWIT filter its primary purpose is to
prevent system, lockup due to 'deadly
embrace' with another computer/node that
is out of synch.
MAXLIST ### If non zero it limits the number of Messages
displayed by one list command.
MINDISKSIZE ### This number (in kilobytes) is subtracted
from actual disk space available to de-
termine space available for messages.
NOBIDFLOOD ON/OFF This flag ON permits messages whose AT
field matches a FLOOD route but has no
BID to have one locally assigned.
OPENLOGIN ON/OFF For modem and console opertaiosn if this flag
is set ON, new logins can be created by
user without sysop intervention.
PONGMAX ### This flag set maximum times this stations'
"R:" header appears. Catches 'ping-pong'
messages.
REPLYTO ON/OFF If set ON the "Reply-To:" field is entered into
the rfc-822 messages, its value is the
home bbs in the sysop's user record.
REQFILMAX ### if non zero this limitsthe size of a file
that may be sent out by in inbound
REQFIL.
Simply typing SETPARM will get a list of all of the parame-
ters and their values. Typing SETPARM and a parameter name will
get the value of that parameter. Typing SETPARM plus parameter
REM - you may want to make this "goto END" so an X command from LOCAL CONSOLE
REM will take you out to DOS
goto MAINLOOP
:REBOOT
boot
REM - this has no exit, system will re-boot
:BACKUP
erase mailbak5.dat
erase userbak5.dat
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 40
ren ????bak4.dat ????bak5.dat
ren ????bak3.dat ????bak4.dat
ren ????bak2.dat ????bak3.dat
ren ????bak1.dat ????bak2.dat
ren ????bak0.dat ????bak1.dat
copy mail.dat mailbak0.dat
copy user.dat userbak0.dat
goto MAINLOOP
:PRMBERR
echo MAJOR SYSTEM ERROR
:END
*** WARNING *** to put this code on the air you will need a *** WARNING *** *** WARNING ***
copy of MBBIOS v3.2 or later or a copy of G8BPQ code. ROSERVER,
like almost all other codes doesn INT 14 calls to do its I/O and
depends on the extended services provided by either of these
programs. It will check for their presence and terminate abnom-
rally if they are not found resident in memory. the above bat
file will loop for ever trying to load MBBIOS, so you will need
to CTRL-BRK outof it if MBBIOS is not present. The copy of
MBBIOS included with the RUNtime package is configured to stand-
ard COM1. you will need to run MBBCONFG.EXE to alter it for COM2,
multiple ports, a custom COMport, or Quad Card. Yoy will need to
set hardware handshaking ON as well. You must use a fully wired
cable (8 wires minimum) from computer to TNC (all 9 wires for
DB-9 or 1-8, and 20 on DB-25)
Speaking of ERRORs. If the mailbox comes up and in the
course of events it detects something it does not like and makes
one of those ERRORLEVEL 6 exits, it does so via a routine called
fatal(). This routine has been modified so that in addition to
displaying its displeasure with some aspect of the system integ-
rity to the screen, it will also append the message to the log-
file.
A word here to those running on floppy systems. ROSERVER is
rapidly outgrowing a 2-360 Kbyte floppy setup. The system will
run and what should be done here is to remove the DOOR directory
and all its files. And to set all of the appropriate executables
and unchanging files like MENUs, HELPs, config files, setup
files, etc to a directory on A-drive and build the mailbox struc-
ture on B-drive. Do not create any sub-directories in files and
keep programs like ROSEFIX, USERWORK SORTUSER, ROSEPWD on yet a
separate disk, while having MAILWORK, ROSEDIST, and ROSERVER on
one of the working disks. For use when needed. A 2-720 Kbyte 3.5
inch system can comfortable run a system with some moderate
downloads. At this point I would say that a single 360K floppy
system is almost out of the question. It might be done with
partitioning a RAM disk and using a tricky boot-up procedure, but
it would not be capable of crash-self-recovery.
Please see the later, more detailed entries about various
config file and TNC setup file parameters.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 41
Setting up to run under DoubleDos can be difficult. There
will be detailed text on the matter presented later, but I will
take the time now to discuss the considerations as applied to the
general DOS environment.
DISK SPACE. The first time you do a DIR when you boot up or
any program does a DIR or Diskspace DOS call, the real amount as
is computed by an actual check of space available. From that
point on, unless a CHKDSK is done diskspace determination is done
in COMMAND.COM by 'dead reckoning', i.e. COMMAND.COM keeps track
of the number of Kbytes of 'erases' and 'creates and using the
base number arrives at the number of bytes free. Since the COM-
MAND.COM of the root process (initial process) creates two 'sons'
when the partitions are spawned, each side is given the number
from 'daddy' and each goes off on its own. It takes but a few
hours til 'space available' on one side will not match the other.
The two numbers often will not have any basis in reality. Recent-
ly KD6TH found his system 'crashed', out of disk space after
about a month of unattended but very heavy operation. Yet when
the system was rebooted it had 1.6 megabytes of free space. There
is no solution except possibly running a software REBOOT program
in your event file, scheduled to kick off at say 1000 local time
which is traditionally a 'slack' period.
TEXT FILES Which Control the Operation of PRMBS TEXT FILES Which Control the Operation of PRMBS TEXT FILES Which Control the Operation of PRMBS ____ _____ _____ _______ ___ _________ __ _____ ____ _____ _____ _______ ___ _________ __ _____ ____ _____ _____ _______ ___ _________ __ _____
There are a number of TEXT files which control operations of
the PRMBS / ROSERVER suite of programs. In ALL of these files a
line with a '#' as the first character is treated as a comment
and ignored. To place a line of data into the system that in-
cludes a "#" as the first character, prefix the line with a '\'
character . For example to place the line :
#NNY.NY DEFLT
into you HROUTES.RS file youwould enter it as
\#NNY.NY
A series of lines followed by a line with a "*** EOF" are
multiple line inputs to some data request.
I chose to have text files control as much of the operation
of PRMBS as possible so tha the sysop could easily alter and
modify the operation of the system and troubleshoot failures
without having to have a detailed hackers knowledge of the system
or resort to fancy Norton Disk editor programs to clear and set
flag bits. All permissions and routings are done in ASCII text.
Admittedly it slows things down a bit but the system runs much
The system operates in BLOCK mode most of the time, that is
to say that it send out frames with full data packets as opposed
to a line oriented system of the early mailbox codes. This is
achieved in the Port Configurations by the commands;
SENDPAC $7F
CR OFF
CP ON
PACTIME AFTER 14
When the sysop enter into terminal mode - the system sends
strings from the port configuration labeled "GOING INTO TERMINAL
MODE, which are generally;
SENDPAC $0D
CR ON
CP OFF
These return the system to a line oriented mode, that is
each time you hit a CR(ENTER) a packet will be sent, this is
easier for KB to KB or KB to BBS work, though far less efficient.
Now -the system is returned to block mode from terminal
operations LATER, when the system goes BACK ONLINE. The strings
for "COMING OUT OF TERMINAL MODE" are only sent when the terminal
mode session was initiated by the SYSOP breaking in on another
user or answering a CHAT request. The reason for them not being
sent merely upon exit from terminal mode, is to allow the sysop
the ability to set up a configuration in terminal mode and then
jump up to BBS command and dump a file to the TNC or the connect-
ed circuit or exchange mail or whatever without being thwarted by
an automatic function. The system stays in line mode the rest of
the session at the console til it goes back online which does not
really matter, and then is returned to BLOCK MODE by the BACK
ONLINE strings.
general Comments on how PRMBS Does Things general Comments on how PRMBS Does Things general Comments on how PRMBS Does Things _______ ________ __ ___ _____ ____ ______ _______ ________ __ ___ _____ ____ ______ _______ ________ __ ___ _____ ____ ______
On busy system with many messages and multiple DDOS/DV Win-
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 56
dows the disk churning can get pretty hot and heavy. PRMBS's cur-
rent multi-user concept of doing it via a DOS Multi-tasker pre-
cludes RAM based index files, so a brute force search has been
used in the past. Currently a modified binary search pattern has
been implemented whereby the program, after testing for the
desired number being above or below the high and low messages on
the system, starts searching from the low numbered end, up,
dividing the sum of the current position and the highest message
by 8 each time and adding it to the current position (with checks
against running over the top) and testing for the message number
found being higher than the searched for number. The search then
goes backwards message by message til the desired number is found
or a the highest message number less than the searched for number
is found.
Since this routine must search out general locations as well
as specific message numbers. It has been coded to return the
record number of the desired record when an exact match is found
and zero if non match is found, but leaving the records posi-
tioned at the highest message number less than the one desired.
This is then used as needed by calling routines. READ, KILL,
FILE, ARCHIVE, REPLY, etc all need exact numbers, LIST, EDIT etc
can take relative placements.
DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.45 03/01/91 pg 57
