Hacker Chronicles 2

home *** CD-ROM | disk | FTP | other *** search

/ Hacker Chronicles 2 / HACKER2.BIN / 887.PRMDOC.98T / PRMBS98.DOC < prev next >

Wrap

Text File | 1988-02-12 | 163KB | 3,265 lines

Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 1 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 1 Document Reflects Features through PRMBS version 0.98S Document Reflects Features through PRMBS version 0.98S Document Reflects Features through PRMBS version 0.98S Packet Radio MailBox System (PRMBS) is a program to run on an PRMBS IBM-PC or clone under PC(MS)-DOS 3.xx. It interfaces into the current American/Canadian amateur packet radio networks and may send and receive mail via the W0RLI mail forwarding protocol. PRMBS is written in C and is primarily compiled under the PRMBS MicroSoft C Compiler Version 4.0. The code is the exclusive work of KA2BQE and NN2Z, with some contributions from others as will be noted. The starting point of the code was an early (Sept-Oct '86) pre-release of the W0RLI/VE3GYQ C BBS code. Through pre- release version 0.60 of PRMBS the code in essence followed the PRMBS structure of the C BBS. At that point radical alterations were made to the point that there is little resemblance to its forbears. The current code retains a few routines from the C BBS from W0RLI/VE3GYQ mixed with some MSDOS directory routines from B. Garbee from KA9Q's NET.EXE suite, and a number of adaptations of generic command parsing routines from UNIX and other sources. *** NOTE *** A complete revised up to date doc for release *** NOTE *** *** NOTE *** 1.0 is in the works. It just takes time - please bear with the disorganized nature of what is here. Brian B. Riley , KA2BQE c/o Stormylea Ltd. 86 Burnt House Road Indian Mills, New Jersey 08088 (USA) CIS: 71420,3543 Phone: (609) 268-9497 - voice and tape answering machine (609) 268-9597 - data BBS 300/1200/18n - 24 hours Xmodem, Xmodem batch, Ymodem batch supported for downloads (temporarily unavailable) (609) 859-1910 - W2XQ RBBS system 3/12/2400 baud 1/8/n supports Xmodem, Ymodem, Kermit, MNP will be kept up with latest code Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 2 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 2 ***************************************************************** ***************************************************************** ***************************************************************** PRMBS will not forward any mail off of its system to another PRMBS system unless the message @BBS field has been specified. While this stance has been criticized by some and remains quite controversial, that feature is hard coded and will stay. No Electronic Mail System anywhere permits mail onto network without such addressing and PRMBS is no different. It leaves mail which PRMBS could be a problem on the system where it originated. There, it has the greatest chance of being 'corrected'. Sooner or later this stance will be proven or trashed. I believe I am right, but time will tell. I feel its only correct to bring this point forward now, before you, the prospective SYSOP invest too much time into setting up the system only to discover this and take exception. I have coded a change in REV N that permits NTS traffic to be forwarded by copying a numeric TO field Zipcode, to the @ field to provide at @BBS on which to forward. This temporarily eliminates the problem while the matter continues under discussion. 73 de brian riley ***************************************************************** ***************************************************************** ***************************************************************** *** NOTE *** if you are running any type of TNC other than *** NOTE *** *** NOTE *** a TNC1 (or clone) or KPC1, the question in the CONFIG file concerning TNC2 is to be answered yes. The DCD is to be answered yes. The cable from TNC to computer must have pin 8 wired to pin 8 end-to-end. The TNC must have the internal jumper which determines the action of the RS232 pin 8 set so that DCD as asserted/not_asserted for CONNECTED/DISCONNECTED condition. (ON a TNC2 or clone this is JMP1. On a PK-87 this is JMP6. In a brand new TNC2 or PK-87 these are set so that DCD is asserted always so t must be changed. The symptom of the set wrong is easy to spot, PRMBS falsely decides it has a connectee each time it gets a monitored PRMBS packet.) I cannot say strongly enough that a sound knowledge of MSDOS and packet operations in general is required to begin to undertake the setting up of a PRMBS system. It is a sophisticated piece of software PRMBS that is, to be quite honest, pushing the hell out of MSDOS 3.x and DoubleDOS. There is little margin for error and damned little in the way of safeguards. I made the system with extreme power for the sysop and significantly enhanced powers to the remote users. If you, the sysop, ask the system to do something stupid, by God it will say "yassuh" and merrily shoot itself in the foot. This not to say that the system is unstable or flaky. There are many safeguards against the normal errors, but I did not cripple the sysop from being able to do just about anything he wants from the DOS escape. The SYSOP can schedule any mailbox command from the LOCAL and SYSOP list in the scheduler. It would be stupid to do a 'dir' as it proves nothing, but it would be disastrous to schedule any command Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 3 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 3 which wants interactive input, the system will be hung at 0330 in the morning waiting for you to figure out that you screwed up. BRINGING UP PRMBS BRINGING UP PRMBS BRINGING UP PRMBS The files needed to bring up the version 0.98P of PRMBS are as PRMBS follows: MB.EXE MB.EXE MB.EXE CONFIG.MB - the default config file, for multi-user see CONFIG.MB CONFIG.MB other docs EVENT.MB the event script file EVENT.MB EVENT.MB R_EVENT.MB reverse event script file R_EVENT.MB R_EVENT.MB HELP.MB HELP.MB HELP.MB MENU.MB MENU.MB MENU.MB INFO.MB INFO.MB INFO.MB TRANSLAT.MB - optional @BBS translation tables TRANSLAT.MB TRANSLAT.MB PASSWORD.MB - optional Remote Sysop password file PASSWORD.MB PASSWORD.MB REMOTREQ.MB - optional Remote request permission file REMOTREQ.MB REMOTREQ.MB RMAIL.MB - optional RMAIL permission file RMAIL.MB RMAIL.MB and sub-directories MAIL\ MAIL\ MAIL\ FILES\ FILES\ FILES\ FWD\ FWD\ FWD\ and in the FWD\ sub-directory there will be the .FWD files. These files and directories should be in the default bbs directory. *** If you have been running any version 0.98N or later you need change only the first line of the CONFIG to read: 098s 02/06/88 098s 02/06/88 098s 02/06/88 If you were running prior versions it is suggested that the CONFIG files from the SUPPORT Archive be used and edited to your parameters. The program can executed with a few different options; C:\BBS> MB <cr> C:\BBS> MB <cr> C:\BBS> MB <cr> C:\BBS> MB -M <cr> C:\BBS> MB -M <cr> C:\BBS> MB -M <cr> C:\BBS> MB -C CONFIG.A <cr> C:\BBS> MB -C CONFIG.A <cr> C:\BBS> MB -C CONFIG.A <cr> C:\BBS> MB -M -C CONFIG>B <cr> C:\BBS> MB -M -C CONFIG>B <cr> C:\BBS> MB -M -C CONFIG>B <cr> The first is plain vanilla. CONFIG.MB is looked for in the \BBS directory. The second tells PRMBS that DoubleDOS is present and to use multi-user coding. The program does check for the actual presence of DoubleDOS and its not there it simply ignores the "-M". The third simply directs PRMBS to use an alternate configuration file whose name is given by the next argument. The fourth is simply a combination of the two. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 4 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 4 1. *** NOTE *** as with all prior versions of PRMBS, immediately upon *** NOTE *** PRMBS *** NOTE *** PRMBS bringing up for the first time, the operator should initiate the GM (untangle mail) and GU (untangle user) commands. We use the GM and GU commands to update Mail file and user file structure changes. They are coded, within PRMBS to recognize both 'old' and 'new' file formats and PRMBS convert them. There are indicators in the first record of each file of the revision level of the file and when appropriate conversions are made. 2. This is the multi-user version, tuned for DoubleDOS use, permitting simultaneous copies running on both sides of DoubleDOS with a shared message file and user file. Use of each side is totally independent from the opposite side. The only indication of a user on 'the other side' would be simultaneous disk accessing for large files, there will be an occasional 'pause' that actually would only be seen by the sysop since the 'delays' in RF protocolled transmissions would tend to 'smooth' the anomaly. To bring the system up you would have two BAT files and mods to AUTOEXEC.BAT. I have also included, at the end of this document, a copy of my DDCONFIG.SYS. In the AUTOEXEC.BAT, you would have as the last two lines; .... .... .... .... DOUBLEDO DOUBLEDO DOUBLEDO Then you make up two BAT files called BBSA.BAT and BBSB.BAT BBSA.BAT: com1bios com1bios com1bios mb -m -c config.a mb -m -c config.a mb -m -c config.a BBSB.BAT: com2bios com2bios com2bios mb -m -c config.b mb -m -c config.b mb -m -c config.b In the respective CONFIG files for A and B, be sure to name the FWD and MON and LOG files as LOG.A, FWD.A, MON.A and LOG.B ... etc. If you are running crossed services, i.e. MARS/Ham, be sure to remember which side is which when you want to send out a message. So that the right 'from call' gets placed onto the message. One way to help remember is to alter the LOCAL Console prompt in the CONFIG.??? file from "$Tz, $N msgs>$H" to "$T, $N msgs[A]>$H" or maybe "$T, $N msgs[HAM]>$H" and "$T, $N msgs[MARS]>$H" . 2. DOS Environmental Changes You will need to enter two DOS environment parameters, TZ and Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 5 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 5 EDITOR, into you AUTOEXEC.BAT; SET TZ=EST5 SET TZ=EST5 SET TZ=EST5 SET EDITOR=your_editor SET EDITOR=your_editor SET EDITOR=your_editor ** if you want to run GMT on your RTC, then set TZ=UTC0 The first, TZ, is used to allow you to run your RTC at local time and still have the BBS at Zulu time. The EDT is your time zone. PST, CDT whatever. The number is the offset from your time to Zulu time. The messages entered will be time stamped in the text with local time with an appropriate indicator for time zone, and the message record keeping and forwarding hours etc. will be done in Zulu time. The date is correctly computed if the local time is close to 2400 and the offset puts it over. The EDITOR variable is to tell PRMBS what your editor is, so that PRMBS you can, from within message entry from the console, or from the message sweeper you may drop into your editor to do a clean job on editing. *** Note - since the function in effect does a call EDITOR filename EDITOR filename EDITOR filename If you are using Wordstar as your editor, install it that default mode is 'Non-document' mode, so you don't wind up with high-bit set characters in the file. In so much as Wordstar or any full blown Word Processor is a disk and RAM pig, floppy disk versions should use EDLIN or NED (norton Editor) which is quite adequate and very conservative on disk space. 3. Speaking of headers #1 - the format of the forwarding header has been partially 'fixed' in the format R:870101/1223z 7656@KA2BQE [Indian_Mills,NJ] optional strings R:870101/1223z 7656@KA2BQE [Indian_Mills,NJ] R:870101/1223z 7656@KA2BQE [Indian_Mills,NJ] Jeff Jacobsen (WA7MBL) and I have agreed to fix the format of our headers to what is shown above. the QTH is placed into the square brackets by the program you do not need to enter them yourself. The [optional strings] are configurable in the file in the same spot as the rest of it would have been placed. The time/date string is as before the message ID and qth, uniquely identify the message and source location. Header recognition is done along two requirements - that the line begin with 'R:', 'r:', 'I:', or 'i:' - that the line contain '@', '@ ', or '@:' prefixing the originating BBS. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 6 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 6 ... nothing else matters, the 'R:' et al is recognition and the '@' is for 'finding' the BBS. 4. Speaking of headers, #2 - I no longer place the 'from' call in the header,as with any message originating here it is already in the new RFC 822 style internal header so there is little point in repeating it ad nauseam, this saves about 8 bytes per header. It does run the chance of losing something if the name isn't in other messages coming in, but as the newer systems progress this danger is diminishing. Further, the logging done by PRMBS is sufficient to recover the PRMBS TO/FROM/AT of any message received from elsewhere. 5. Speaking of headers - a reminder - if you get someone using the old W2JUP 'all-slashes' header or some creative soul who gets so carried away he forgets the '@' symbol, the 'is_header' test ends at that header and the 'return address' or non-verbose (R)ead command starts there. So impress on your various connecting BBSes the importance of following the minimal guideline 6. headers makes me think of routing - auto-re-addressing is here Any message entered into the system from console or remotely is subject to scrutiny of the @BBS field. If it matches your BBS call it is left blank - this is not new, but before we save the message we take one look at result, if it is blank we check our user file and if that user has as his home BBS something other than blank or your BBS it will get his home BBS filled in so it will automatically be re- routed to him. The commands for handling HomeBBS are 'H' to see what the BBS thinks is your home BBS and 'H yourcall' to actually place your call into the homeBBS field. In 098L we have added the TRANSLAT.MB file which, if present will allow a greater range of flexibility in call translation. In essence what happens is that just before the 'blank check' and run through the USER.DAT file, the BBS checks to se if the @BBS field is blank and if the TRANSLAT.MB file is present in the default directory. If it is the file is read and a match with the @BBS field is looked for. If match is found and no second call is on that line of the file, the call is blanked. If there is a second call, the second call is substituted for the first. Some examples. Look below at the following sample TRANSLAT.MB. NTSNJ KB1BD NTSNJ KB1BD NTSNJ KB1BD NTSSNJ KB1BD NTSSNJ KB1BD NTSSNJ KB1BD NTSCNJ KB1BD NTSCNJ KB1BD NTSCNJ KB1BD NTSNNJ KD6TH NTSNNJ KD6TH NTSNNJ KD6TH 080* WB2MNF 080* WB2MNF 080* WB2MNF 081* WB2MNF 081* WB2MNF 081* WB2MNF 082* WB2MNF 082* WB2MNF 082* WB2MNF 083* WB2MNF 083* WB2MNF 083* WB2MNF 084* WB2MNF 084* WB2MNF 084* WB2MNF Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 7 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 7 085* N2EVW 085* N2EVW 085* N2EVW If someone wanted to send mail to me, even though they know who I am and am a BBS, many stations along the way may not know who I am or which way to send it. It might be sent to KA2BQE @ 08088 . Now AS it worked its way here using wildcards at most stations that sends 08* and 07* to NJ in general. It will arrive somewhere in NJ from some direction. It will sooner or later get to a station for whom 080 has meaning and sooner or later it will arrive at WB2RVX who will look at 080 and say that's WB2MNF. At WB2MNF it will get the WB2MNF blanked, and it will look up KA2BQE the user and see that HOMEBBS is KA2BQE and re-address it that way and it will make it here. Sometimes it will come straight to me other times it will come back via RVX, a seemingly wasted trip, BUT the point is it is untouched by hands and never stalls awaiting Sysop intervention. 7. File uploads - sysops life made easier When a user uploads a file he is prompted to enter a one line description of the file. Further a message is composed and sent to the sysop describing the file sent and who sent it. Further it is possible to make all uploads invisible to other users until 'checked' by SYSOP. If you create a directory called 'UPLOAD' or whatever you specify in the CONFIG file at that point. Any uploaded file will go there, unavailable to users. If the directory specified doesn't exists it may be uploaded anywhere and be immediately available as before, subject to the same rules as before (i.e. it goes in a directory under 'FILES' as specific by user) In file upload a '/ABORT' will do that , terminate input routine and delete the temporary file., saving the trouble of asking sysop to delete a partial. very handy with unexpected DISCONNECT in middle of upload, and you are not sure what got through, you can /ABORT and start again w/o leaving a file fragment. 8. Increased Remote sysop security - remote sysop password - an 80 char string is coded into the MB.EXE file, it is used to generate 6 2 digit numbers which are displayed back to user. To log in and toggle the remote sysop condition the user must; 1 - have remote sysop privilege bit set 2 - type back the 6 letter from the string whose positions apply to the numbers displayed, counting the first position as zero ( 0 ), programmer style. If the user fails he is simply dumped back into the Mailbox as a plain vanilla user. - remote sysops see nothing special and can do nothing special when they log in initially, but after invoking the '@' and correctly entering the password, they now have all the commands they had in normal REMOTE mode plus several others. They now directly look at Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 8 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 8 the BBS root directory instead of 'files\', and can see and/or erase any message. They still do not have the privilege to view the sysop's private mail. - remote sysop password is contained in a file containing a single line of text. The file is called PASSWORD.MB and must be in the PRMBS default directory. If it is not present, no password is PRMBS assumed and simply having a call with the correct user privilege bits set is all that is needed to get in. The PRMBS code is PRMBS 'doctored' to ignore any attempts by a remote user to access the file PASSWORD.MB . The layout of the file is this <single digit number> <sp> <string> <single digit number> <sp> <string> <single digit number> <sp> <string> For example; 6 ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890!@#$%^&*()_+| 6 ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890!@#$%^&*()_+| 6 ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890!@#$%^&*()_+| If a user logs in and accesses remote sysop with an '@' symbol he will be presented with , in this case, 6 (first char of file is number of digits to be presented) two digit numbers like so; 05 25 12 10 13 07 05 25 12 10 13 07 05 25 12 10 13 07 which he should reply; EYLJMG EYLJMG EYLJMG The password string may be up to 80 characters long and you may select from 0 to 9 digits for response. 6 is a good number, but 4-6 is good. Spaces may be included in the string and must be sent back - the raw input line is read for this so the spaces are preserved. If you edit the file remember to erase the backup file. 9. Scripted forwarding - NETROM, gateways, N2WX switches The system supports scripted connections for NETROM, COSI, FO-12, UNIX systems, whatever your heart desires. The formats are as follows; 1) In the first example login to a BBS via an N2WX switch is achieved as follows. The '@' establishes initial level 2 connection to the first 'node', 'via' strings are supported. The '+' is the 'make string' and all that follows on that line as the string for comparison to check for 'connect achieved'. the '?' is the 'break string' whose receipt means failure. The '!' sets the number of seconds to wait before declaring a TIME-OUT. the '.' is the string to then be sent out, in this case a connect from the switch directly to the BBS. '*** EOF' signifies end of script, if successful to that point then start forwarding from the list below. >1 KB1BD >1 KB1BD >1 KB1BD @KA2VLP-3 v K3DSM @KA2VLP-3 v K3DSM @KA2VLP-3 v K3DSM +reset +reset +reset ?clear ?clear ?clear Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 9 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 9 !180 !180 !180 .C KB1BD-4 .C KB1BD-4 .C KB1BD-4 *** EOF *** EOF *** EOF 2) The second example is the same as the first, but this time through two switches notice that after connecting to the N2DSY-3 switch I changed the time-out to 120 seconds since KD6TH should be solid to DSY switch though DSY to VLP might not be so sure. The '\d's in the '.' string are 'delays' each one is a 2 second wait. These were included to allow certain vagaries of the N@WX switch to 'settle down' before going onto the next step. (also available '\r to send multiple returns) >1 KD6TH >1 KD6TH >1 KD6TH @KA2VLP-3 v K3DSM @KA2VLP-3 v K3DSM @KA2VLP-3 v K3DSM +reset +reset +reset ?clear ?clear ?clear !240 !240 !240 .\d\d\dC N2DSY-3 .\d\d\dC N2DSY-3 .\d\d\dC N2DSY-3 !120 !120 !120 .\dC KD6TH-4 .\dC KD6TH-4 .\dC KD6TH-4 *** EOF *** EOF *** EOF 3) In the next case we have NETROM forwarding, showing multiple connection paths - One could connect directly to the far end, but with the congestion on NETROM 145.01 these days, stepwise progression is advisable, also use calls not 'ID;'s to make sure you can get through just in case they aren't in the table but can hear you. Notice the strings carry through, the 'make', 'fail' and 'time-out's stay what they were unless changed. >1 W3IWI >1 W3IWI >1 W3IWI @WB2DRD-1 @WB2DRD-1 @WB2DRD-1 +to +to +to ?* ?* ?* !150 !150 !150 .C WB4APR-6 .C WB4APR-6 .C WB4APR-6 !200 !200 !200 .C UMD .C UMD .C UMD !120 !120 !120 .C WB6FFV-6 .C WB6FFV-6 .C WB6FFV-6 .C SFO .C SFO .C SFO .C W0RLI .C W0RLI .C W0RLI *** EOF *** EOF *** EOF *** NOTE *** NETROM has one deficiency from an applications *** NOTE *** *** NOTE *** programmers standpoint. It while it has only one way of telling you that it has 'made' its connection, it has multiple ways of telling you it didn't make it ("bsy fm", "failure with", "invalid callsign" (if you use IDs in script and that station isn't in table at moment), and of course it can just disconnect from you also) 4. A simple connect thru a digi or direct connect is down as Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 10 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 10 shown below, also note the alternate selection. The first is selected "FWD B WB2RVX", the second "FWD B2 WB2RVX" >1 WB2RVX >1 WB2RVX >1 WB2RVX @ WB2RVX @ WB2RVX @ WB2RVX *** EOF *** EOF *** EOF >2 WB2RVX >2 WB2RVX >2 WB2RVX @WB2RVX v WB2DRD-1 @WB2RVX v WB2DRD-1 @WB2RVX v WB2DRD-1 *** EOF *** EOF *** EOF '%O filename' - in 'scripted forward' will open a capture file '%C' - will close a file (as will any subsequent open statement) '&###' - will eat ### lines without checking against 'fail' or 'ok' strings The whole script is subject to the following limitations; - 16 lines of script - 512 total bytes of script regardless of number of lines. The script buffer is 'cleaned' at the start of each forwarding unit. 10. Port attributes The CONFIG file port configuration has a line that looks like the following: ATH 6 15 4800 ATH 6 15 4800 ATH 6 15 4800 This line defines the characteristics fo the port. The first letter is the port designation. The letter is not 'optional' it corresponds (in the DOS environment) to the COM port location A = COM1, B=COM2 ..... D=COM4 , etc. Its good up to COM6 (COM3-6 can be accessed with the MS-400 board, COM3 and COM4 can be gotten with simple addon serial cards). 'L' is used for the Local Console port ID. The suggested baudrate is 4800 a rate which is supported quite well by most TNCs. I recommend that the highest baudrate that your TNC reliably works at will allow maximum performance by the PRMBS/COMBIOS combination. The TNC2's generally are not reliable at 9600 due to the slew rates of the LM324 op amps used as RS232 drivers. If you replace hem with TIL084's you may e able to use 9600 on a TNC2. I run my PK- 87's at 9600 and several newer TNCs support 19.2 Kbd. The rational is simple, the less time it takes to send to the TNC and get from the TNC the more time there si for processing! The letters after the first describe the attributes of the port. They decode as follows: /* Port type bits. */ B P_BBS /* BBS only */ C P_CONSOLE /* The local machine console */ Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 11 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 11 E P_ECHO /* Need to echo input */ F P_FILE /* File transfers ok (NOT IMPLEMENTED)*/ H P_ILCAL /* Illegal call allowed */ M P_MDM /* Serial connected thru landline modem */ R P_REG /* Port is for registered users only */ S P_SERIAL /* Is a "raw" serial device */ T P_TNC /* Is a tnc, TAPR commands */ The '6' is the number of minutes of no input before the system 'times out' and puts it self back on line. This number needs to be a 6 or more for NETROM connections. This works even for the Local Console, so no more forgetting to go back on line. The '15' is the number of lines reserved for reporting in the 'heard' list. The '4800' is the baud rate of the port (set by BBS when it starts up. If you have a TNC with AUTO-BAUD (like, PK-232, PK-87, TNC- 220). please be sure you use a terminal program to get it setup BEFORE you bring up the PRMBS. PRMBS Among the 'port descriptors' are two which may need some additional explanation; The 'R' descriptor is 'registered users only' basically it means that any user not already in the USER.DAT file will be rejected. This permits operation of a 'closed' system if such is considered important. It saves the overkill of making the system a BBS only on that port and making all the users BBSes, which poses other problems. While 'H' for ham calls only may seem simple, we do not recognize MARS calls as Ham calls *** NOTE *** - experienced users of other BBS systems may notice *** NOTE *** *** NOTE *** a lack of a 'max digi' parameter for the port descriptors. With the advance of level 3 routing in COSI and NETROM, the use of many digis is minimal and I have discarded the code related to this which amounts oo several hundred bytes of code. 11. Message Editor sweeper operations The message editor sweeper is quite similar to many 'file sweep' type programs that are out in the public domain. It provides all users withthe ability to simply operate on messages. The remote user has less options available to him than the remote sysops and the local console. The local console operates in 'single keystroke' (i.e. no CR required ) mode while the remote user and remote sysop must send the CR. The 'message to file' options will prompt for a file the first time they are invoked and that filename will be retained such that subsequent invocations of the 'F' and 'A' will display the current filename whichcan be accepted by simply hitting a CR, or converselycan be change by simply entering a new file name. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 12 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 12 To print a message you can 'file' the message to a file called "prn" . This is an MSDOS reserved name for the system printer port. And its operation is the same as simple 'file' to an actual disk file. The filename remains in effect til it is changed. If you specify a bad path in the message to file, it no longer kills the message anyway!!! If you do an A or F by error, simply type '/' and you are out, the filename is saved from a prior A or F even if you '/' out! Options are now A,C,E,F,K,Q,R,S,T,V,? A - archive - message to file and kill message C - change direction toggle (toggles reverse or forward) E - header edit F - message to file K - kill message Q - quit loop R - short read (does not show forward headers) S - send reply to message correctly parse return BBS T - edit the message text via EDITOR V - verbose read ? - help [space] and [cr] will advance to next message 12. Hints on USER.DAT - if you set the BBS flag for a user, his HomeBBS automatically gets filled in with his own call, you will need to edit it back if it is different for some reason - the LOCAL flag being set is now independent of a user declaring you as 'Home' . As before the LOCAL flag being set lets a user in on a BBS only port, but this way you can let just certain users in on a BBS only port without making them BBSes and/or remote sysops and not having to let just anyone who declares you as home into the BBS only port. - it was never clear before so I will explain how to 'get rid of' a user. You enter the USER sweeper with EU and you indicate 'K' to kill the users you want removed. Then you execute the untangle user command GU and 'voila' - all the 'deleteds' is gone!! - there is a new program called SORTUSER. It is executed with SORTUSER infile outfile SORTUSER infile outfile SORTUSER infile outfile what this will do is sort your user file so that the most recent user is at the top of the file down to the least recent user. The reason for this is that because of multi-user capabilities, we no longer keep all user names in a memory table, the file is searched Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 13 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 13 brute force each time. This way we have the regular users found more quickly - the user 'high message read' is now exactly that. I place in the user record the highest message number he has read and use it for the 'L' command - I compare the number there with number of the current message he has asked to read and replace it if it is greater. If the user logs in a lot and doesn't read his 'L' list will get huge, so he must occasionally read the highest message number to clear it if thats what he wants. On the flip side, no longer will his 'L' list be lost if he gets timed out, or whatever. 13. The MBFIX program has been enhanced greatly and will recover just about the most trashed of mail files. Invoke MBFIX with no arguments and it will give you a short menu and explanation. 14. More generic compatibility with 'other than TAPR' TNCs - The code has many small mods made to accommodate the PK-87/PK- 232 minor variations in user interface. - changes were made to facilitate the "; v2" message tacked onto the end of the ham call in a "Link state is" message in an AEA PK87/232 when an AX25 Version 2 connection is achieved. There distinct advantages to running in AX25 ON mode but there have also been disadvantages also. - KAM and KPC-4s can be used in single port fashion. It is important to note that KAM users must be sure to reset the STREAMSW parameter the default is 2 chars $40 and $7C. We are quite aware of the problems $7C('|'), but can you imagine the troubles that are caused in forwarding by $40 ('@') !!!!!! Nuff sed!!!!!!!!!!! - Also a kluge not to send '@BBS' when you are forwarding to a system and the TO, @ and the system being connected to all match - this keeps the KANTRONICs TNC-BBS much happier. 15. SYSOP mail. Incoming messages to SYSOP at that BBS will be stored with SYSOP replaced with SYSOP's call. messages to SYSOP @BBS and '@BBS is not that BBS will be stored as received, however any message bearing SYSOP as the receiver will be shown if the SYSOP does a MAIL command. 16. Full wildcard pattern matching - in forward file, along with exception processing. It works (well sorta works, see note below) as follows: !N4HY !N4HY !N4HY !KB1BD !KB1BD !KB1BD !K3GYS !K3GYS !K3GYS !K3DSM !K3DSM !K3DSM ?1* ?1* ?1* Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 14 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 14 ?3* ?3* ?3* ?4* ?4* ?4* ??1* ??1* ??1* .... and so on .... and so on .... and so on You are limited to 32 exceptions and they must be specified before the calls to be in effect. If a 33rd exception is read it is ignored. However, the 32 limit is not really constricting because there is an additional command ' !RESET '. If this is read in the exception buffer is reset to zero and may be re-filled. For example !KB1BD !KB1BD !KB1BD !K3GYS !K3GYS !K3GYS ..... a total of 32 exception calls ..... a total of 32 exception calls ..... a total of 32 exception calls !K3DSM !K3DSM !K3DSM ?1* ?1* ?1* ??1* ??1* ??1* ??6* ??6* ??6* ?16 ?16 ?16 !RESET !RESET !RESET !N4HY !N4HY !N4HY ?4* ?4* ?4* ??4* ??4* ??4* .... and so on .... and so on .... and so on 17. TNC2 support has been enhanced with the addition of TRANSparent mode during user or bbs login. In that fashion the '*** con req' messages will no longer contaminate the input. We are using break to exit TRANSarent mode, so COMBIOS or MBBIOS date version 1.6 or higher, generally bearing a date of 31 Dec 86 or later is required. 18. Speaking of TNC1, we found that the method of 'blasting' command strings at it was occasionally dropping a string. So if the TNC2 flag is NO TNC1 and its ilk are assumed. In such case a 2 second pause to enter CONV mode is observed at login, and during the sending of command strings each command is sent and 'cmd:' is polled for after each command instead of after the whole string. 19. I have removed console support of YAPP. In multi-user mode there is simply no room for it. It saves several hundred object bytes. If you are running single died PRMBS, you can bring up YAPPB in DOS PRMBS escape and it will access the COM ports just fine and not mess any vectors set by PRMBS. PRMBS 20. As in the past parsing of the initial connection line for PRMBS is PRMBS being done - this gives us disk space size and remote version number. I have altered the testing to include 'general recognition of a 'smart bbs system' prompt. I used to look for MBL only but now I do it by checking simply for '[xxxx]' and assume reverse forward capability. Among the systems out there know to have reverse forwarding as of this writing there is, in addition to PRMBS, WA7MBL and N3ET AmigaBBS PRMBS which issue the following; Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 15 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 15 [MBL320] - or other version number [AmigaBBS] 21. Odds and ends - when the sysop makes a boo-boo, i.e. enters a bad command, the system simply just returns to the next prompt, instead of sending him a 'huh', seems a waste of screen space. - DOS escape functions have been modified slightly into one coherent procedure, saving space and providing more multi-user file security. One ramification of this change is that DOS escapes are a little slower, so as to be a little 'safer'. The bottom line is that where before it was not much of a deal if you had two or three lines that looked like this: D 0100 TIMER/S D 0100 TIMER/S D 0100 TIMER/S D 0100 ERASE MAIL\*.BAK D 0100 ERASE MAIL\*.BAK D 0100 ERASE MAIL\*.BAK D 0100 ERASE MAIL\*.~* D 0100 ERASE MAIL\*.~* D 0100 ERASE MAIL\*.~* For 'speed' sake it should be more like: D 0100 FOOBAR D 0100 FOOBAR D 0100 FOOBAR with the file FOOBAR.BAT looking like TIMER/S TIMER/S TIMER/S ERASE MAIL\*.BAK ERASE MAIL\*.BAK ERASE MAIL\*.BAK ERASE MAIL\*.~* ERASE MAIL\*.~* ERASE MAIL\*.~* - local console read messages are done with 'paging', i.e. pause after each 23 lines. - for normal 'REMOTE' users (i.e. non remote-sysops) Messages addressed '@ BBS and not 'forwarding type' messages will not be displayed to the user. This saves him seeing a list of 20 copies of the same messages going 20 places. LOCAL console and remote sysop will see all messages as they are entitled. - all replies to messages and KT's will automatically scan the headers of the replied messages and compose a 'path' to go into the reply in the form "path: call!call!call....." in the header of the message. For now it will aid sysops in routing cranky messages, but within the next couple weeks we will have code that will, when all other efforts fail look to the 'path' to find the 'next step'. - for systems running as personal BBSes, there is a line in the config where they may specify a 'reply-to' address. For example, KB7UV is a personal BBS adjacent to and receiving mail from N2MH, instead of depending on everyone knowing where he is he simply sets his 'reply-to' line to 'kb7uv@n2mh.ny.us.ampr' and the PRMBS code PRMBS used to generate a reply will use the 'reply-to line' as the @BBS in Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 16 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 16 the return addressing. overriding the '@kb7uv.ny.us.ampr'. - the 'edit [msgno]' command is available to REMOTE users to permit any user to edit the header of as message to or from them, so as to re- establish its 'unread', re-direct the message, etc. - 'stream' forwarding made available. there is a CONFIG line which is YES/NO for 'stream forwarding' this is in essence simply not waiting for the two CRs which represent the 'send title' and 'send text' lines from most BBSes and are just two CRs in PRMBS-PRMBS exchanges. The two CRs or CR-terminated lines will still be sent out by the system on the other end, and will still be received, just they will be 'eaten' at the end while looking for the '>' BBS prompt line. This will save as much as 2 minutes per message in forwarding through several NETROMs. - the sysops CALL sign is derived from his domain name. PLEASE place this in in all LOWER CASE, and DO NOT put in SSID's, we are working on a scheme to handle multiple BBSes under same call sign. I am still getting varied reports from sysops about strange happenings when they try to print stuff from the BBS. It seems to vary from BIOS to BIOS. I can say nothing more than I am using MSDOS 3.21 (R) and PCDOS 3.21(r) on 3 different machines with three different BIOSes (Yangtech, ERSO/DTK, and Zenith(Z-183) ) Each of these permits me to hit ctrl-PrtSc and copy all to printer w/o any problem. Yet I know of three different Ops with the same hardware but different BIOS ROMs who get the machine sent on a free trip to Cairo when they try it. All I can say is, please let me know the exact hardware, the exact BIOS(manufacturer, date, and version) as well as the exact DOS type and version. 22. The 'going into terminal mode' string has been added for those running block mode on a TNC2 or equivalent. They return the BBS withoutchnagingthe LINE mode paramters. These changes should be in the 'going back on line' strings. This permits you to leave the TNC in or out of "cmd:" mode and send files to set up thetNC or send a file through the TNC to a friend while connected. The 'coming out of terminal mode ' string is sent at the end of a chat session only. 23. Automated Mail Archiving - "OLDMAIL" archiving. It works like this; - in the config file there is filename that reads like "OLDMAIL.KLD" (the name is meaningless, its your choice, but this is in the sample CONFIG accompanying the system release). - there is a question which asks if you want to archive killed mail (Y/N). If you answer no, no saving of killed messages is done and the following question is ignored. - next there is a question (YES/NO) which asks if you want to archive Traffic only. If you answer YES it means only messages type Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 17 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 17 "T" will be saved when killed, and if you answer NO it means all messages will be saved when killed. If the first question about general archiving is answered NO, this question is meaningless and it matter not what you answer. The OLDMAIL file is one large file and each message is appended into the file with a separator line that looks like this: ----- message #12345 filed by KA2XXX, at 01234z on 871016 ----- That the message was killed is recorded in the LOGfile. Its recorded presence in OLDMAIL also attests to its 'death'. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 18 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 18 A Conceptual Discussion of MAIL TRANSFER / FORWARDING / EVENT SCHEDULING and SMART BBSes MAIL TRANSFER / FORWARDING / EVENT SCHEDULING SMART BBSes MAIL TRANSFER / FORWARDING / EVENT SCHEDULING SMART BBSes (Under PRMBS in 0.98C and Later) PRMBS The term 'smart BBSes' may throw you. But eh PRMBS code pioneered the concept of the system IDing itself at connection time and passing information relative to its status to the connecting system. A protocol has been arrived at and it is as follows. A connecting system upon being greeted by a 'smart system' ID (in the form [......] "..." indicating some variable information plu s the usual BBS prompt, will respond with its corresponding ID string ("[....]"), a system being connected too upon recieving this prompt where it expects a command, will simply 'eat' the ID string, parse its contents and do what it will based on that information, then respond with a BBS prompt. The second prompt IS REQUIRED! PRMBS sends an ID string in the form [PRMBS-1234-098p], the PRMBS [PRMBS-1234-098p] PRMBS [PRMBS-1234-098p] middle number is the amount of disk space in KBytes available for messages, and the 098p is the revision level of the software. The 'final' format of the ID string will be as discussed in Appendix B, a preliminary spec agreed upon by WA7MBL and myself. This form will be used in the 0.99 Beta test release and, of course, 1.00 . The setup and use of the new event structure seems overly complex to many because it is so radically different from what was before. In the past you had to have sometimes three and four copies of the same list of calls in place for each BBS that could take say 'southbound' mail. Then if one of those calls moved from Virginia to Boston, in every place you referred it and change it. Then if all of those stations became unavailable for whatever reason, and you wished to hump the mail up to an alternate, you had to make yet a 5th copy. In the new PRMBS structure it could be done in the following manner; PRMBS Lets look at my position here in Indian Mills, I have the following 'generic directions of mail flow' SOUTH NORTH NWEST WORMHOLE WB2MNF K3DSM WB2DRD SOUTH NORTH NWEST WORMHOLE WB2MNF K3DSM WB2DRD SOUTH NORTH NWEST WORMHOLE WB2MNF K3DSM WB2DRD each of these may translate (I will explain my use of 'may' to qualify this statement in a moment) into a file called xxxxx.FWD. Using those filenames I build my EVENT file; M 0100 FWD B W3IWI SOUTH WORM M 0100 FWD B W3IWI SOUTH WORM M 0100 FWD B W3IWI SOUTH WORM M 0100 FWD B N4QQ SOUTH WORM M 0100 FWD B N4QQ SOUTH WORM M 0100 FWD B N4QQ SOUTH WORM M 0100 FWD B WB3FFV SOUTH WORM M 0100 FWD B WB3FFV SOUTH WORM M 0100 FWD B WB3FFV SOUTH WORM M 0100 FWD B WB2DRD M 0100 FWD B WB2DRD M 0100 FWD B WB2DRD M 0100 FWD B KB3UD NWEST M 0100 FWD B KB3UD NWEST M 0100 FWD B KB3UD NWEST M 0100 FWD B WB2MNF M 0100 FWD B WB2MNF M 0100 FWD B WB2MNF M 0100 FWD B N2EVW NORTH M 0100 FWD B N2EVW NORTH M 0100 FWD B N2EVW NORTH M 0100 FWD B K3DSM M 0100 FWD B K3DSM M 0100 FWD B K3DSM M 0100 FWD B WB2YZS M 0100 FWD B WB2YZS M 0100 FWD B WB2YZS M 0100 FWD B K3GYS M 0100 FWD B K3GYS M 0100 FWD B K3GYS Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 19 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 19 M 0100 FWD B -P WB2RVX NORTH NWEST SOUTH WORM WB2MNF K3DSM M 0100 FWD B -P WB2RVX NORTH NWEST SOUTH WORM WB2MNF K3DSM M 0100 FWD B -P WB2RVX NORTH NWEST SOUTH WORM WB2MNF K3DSM M 0100 FWD B2 -P WB2RVX NORTH NWEST SOUTH WORM WB2MNF K3DSM M 0100 FWD B2 -P WB2RVX NORTH NWEST SOUTH WORM WB2MNF K3DSM M 0100 FWD B2 -P WB2RVX NORTH NWEST SOUTH WORM WB2MNF K3DSM Upon getting a FWD command the system takes the first argument after the port (or optional command arguments '-') as the destination BBS and the @BBS address to be searched. So first it looks through at the name W3IWI and builds a filename "FWD\W3IWI.FWD" and checks for its existence, if it does exists it opens the file and starts reading possible @BBSes and comparing to the MAIL.DAT if a match is found and no RF connection has been started, a Connect sequence is initiated. A failed Connect sequence will cause this FWD to abort and go to next one. If the connect is made, the mail is then forwarded, each entry of the FWD file is read and appropriate mail is forwarded. If the FWD file did not exist, the MAIL.DAT would simply have been checked for @W3IWI. A similar sequence continues for each subsequent argument on the FWD command line. Each subsequent argument is additionally is checked for the presence of a '*' or '?' wildcard, in which case it is assumed not to be a filename. AS with before if no RF connection has been established, once a 'match' is found it will be. The state of the RF connection is checked from the start, so, if you have connected to a station via terminal mode and then decide to move some mail to him you can simply type something like; FWD B W3IWI WB9XXX FWD B W3IWI WB9XXX FWD B W3IWI WB9XXX The system will sense that the connection has been made and will forward the mail as soon as it finds it. Since no file is needed to simply forward mail that is @BBS, I am able to use a mere 5 files (WEST, NWEST, SOUTH, NORTH, WWORM) to serve 13 BBSes. But wait, there's more! Lets say that for whatever reason I am unable to move things the way I want to and need to get the mail out. Like maybe my radio goes down, or the DRD netroms get hosed, these simple files can be used from the console in the following manners: to simply move my mail to a disk file to be imported into and MBL or PRMBS system with the SERVER function; PRMBS EXPORT mail.out NORTH NWEST SOUTH EXPORT mail.out NORTH NWEST SOUTH EXPORT mail.out NORTH NWEST SOUTH the EXPORT function of the SERVER capability works exactly the same as the FWD, only the first argument a file name. The same code is used as in the FWD function, just two internal flags divert output to disk and prevent RF connections from being established. No new files need be created, no files need be edited. If on the other hand you are running OK and you are the recipient of some of this mail, you do the opposite action; Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 20 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 20 IMPORT mail.out IMPORT mail.out IMPORT mail.out all of the messages exported in the action above are now read and placed into your message system. the file is not deleted or altered, so you must be careful about its subsequent disposition, or its DUPE city! Say N4JS' HF transceiver goes down and Jon (WB2MNF) calls Joe(KC2TN) and gets him to put his HF gear back up for a few hours and move some mail for him Jon's normal entry in EVENT.MB was: M 1010 FWD A N4JS HF M 1010 FWD A N4JS HF M 1010 FWD A N4JS HF now he would have Joe come up and need do no more than type FWD A KC2TN HF FWD A KC2TN HF FWD A KC2TN HF or when WA3DSP-5 was down for several days and mail for K3DSM (which includes N3BBF and one other PBBS) got backed up, I was able to do a FWD B WA2VXT K3DSM FWD B WA2VXT K3DSM FWD B WA2VXT K3DSM and move it to Harry who moved it on 145.07 to Gene. The reverse forward file is no big deal, anyone connecting and sending he F> will get mail addressed @BBS for him. Then if there is an entry in R_EVENT file he gets anything specified in there. I can set my R_EVENT file now to handle all sorts of contingencies M 0100 FWD B -r WA2SNA NORTH M 0100 FWD B -r WA2SNA NORTH M 0100 FWD B -r WA2SNA NORTH M 0100 FWD B -r N3ET NWEST M 0100 FWD B -r N3ET NWEST M 0100 FWD B -r N3ET NWEST M 0100 FWD B -r N2EVW NORTH M 0100 FWD B -r N2EVW NORTH M 0100 FWD B -r N2EVW NORTH M 0100 FWD B -r WB2RVX NWEST NORTH SOUTH WORM M 0100 FWD B -r WB2RVX NWEST NORTH SOUTH WORM M 0100 FWD B -r WB2RVX NWEST NORTH SOUTH WORM ..... and so on So now we see that the 5 files I keep for me can actually cover many many functions and forward sequences. It means that a new station showing up in the scheme of things needs very little work to integrate; he must be in one direction or another so you pick one file and place him in and thats the end. When W0RLI moved from Boston to California this would have been done my simply taking his call out of the NORTH file and putting it into the WORM file. Under the old system you might have had to find his call in anywhere from 4 to 20 places and move it to another 4 to 20 places!!!. Beyond the flexibility and what , I at least, see as simplification of the forwarding scheme, the new structure provides more control over the BBS by giving you batch file capabilities; *** NOTE *** One thing to be extremely careful about; in the *** NOTE *** extremely *** NOTE *** extremely xxxx.FWD files that contain your lists of BBSes to be forwarded in the general batch, be careful that you do not have any *** EOF do not *** EOF do not *** EOF Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 21 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 21 strings. These no longer are needed and will be interpretted as a wildcard to forward the world to that connection. It is an easy mistake to make if you are converting from MBL CBBS or an earlier version of PRMBS. Say you have a sort of regular distribution list of guys who you want to send 'mail' type messages to (i.e. messages where all addressees are listed on the TO line. You could place that line in a single line (or multi-line for that matter if there's a bunch of these messages to do at once) alternate event file; SNJLAN1: mail wb2mnf k3gys wb2drd wb2rvx kc2tn n2evw kb1bd wb2ena n4hy@kb1bd mail wb2mnf k3gys wb2drd wb2rvx kc2tn n2evw kb1bd wb2ena n4hy@kb1bd mail wb2mnf k3gys wb2drd wb2rvx kc2tn n2evw kb1bd wb2ena n4hy@kb1bd Then all you need to do to execute this file is: EVENT -f SNJLAN1 EVENT -f SNJLAN1 EVENT -f SNJLAN1 the net effect is to come up and ask for title and text and when done make the messages and return to mailbox prompt. There possibilities are really limitless. Under this system, a section of your EVENT file could have the following; M 0100 EXPORT mail.out KA9Q N4HY WB6RQN WA7MBL M 0100 EXPORT mail.out KA9Q N4HY WB6RQN WA7MBL M 0100 EXPORT mail.out KA9Q N4HY WB6RQN WA7MBL D 0100 TO_SMTP mail.out D 0100 TO_SMTP mail.out D 0100 TO_SMTP mail.out D 0100 ERASE mail.out D 0100 ERASE mail.out D 0100 ERASE mail.out D 0100 FM_SMTP mail.in D 0100 FM_SMTP mail.in D 0100 FM_SMTP mail.in M 0100 IMPORT mail.in M 0100 IMPORT mail.in M 0100 IMPORT mail.in D 0100 ERASE mail.in D 0100 ERASE mail.in D 0100 ERASE mail.in this sequence would take mail from the system addressed at the above calls and transfer them to a disk file for input via some SMTP transfer program, such as the one written (I believe, by WA3PXX) in the Maryland area, then ERASE the file (confusion factor, remember!), Then run the opposite program to get mail for PRMBS and import it to PRMBS the system, followed by an ERASE of the input file. By erasing the files each time, dupes are avoided, if there is no mail, the files are either empty or non-existent and nothing happens. One user has been running PRMBS on a set of networked PCs. He has been using export/import to move mail between systems. I suggest the following scheme to make sure there are no hitches in file/record locking contention. on system A exporting mail to system B, EVENT.A looks like; M 0100 IMPORT mail.ba M 0100 IMPORT mail.ba M 0100 IMPORT mail.ba M 0100 EXPORT mail.abx KA9Q N4HY WB6RQN WA7MBL M 0100 EXPORT mail.abx KA9Q N4HY WB6RQN WA7MBL M 0100 EXPORT mail.abx KA9Q N4HY WB6RQN WA7MBL D 0100 REN mail.abx mail.ab D 0100 REN mail.abx mail.ab D 0100 REN mail.abx mail.ab Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 22 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 22 on system B exporting mail to system A, EVENT.B looks like; M 0100 IMPORT mail.ab M 0100 IMPORT mail.ab M 0100 IMPORT mail.ab M 0100 EXPORT mail.bax N1ABC N2XXX N3* M 0100 EXPORT mail.bax N1ABC N2XXX N3* M 0100 EXPORT mail.bax N1ABC N2XXX N3* D 0100 REN mail.bax mail.ba D 0100 REN mail.bax mail.ba D 0100 REN mail.bax mail.ba Since the EXPORT action is an action of significant duration compared to the DOS Rename function doing the export to a filename other than the desired import keeps the other computer from hanging up or going south over the export output file being open for several minutes. The transfer need not be SMTP. Since an intermediate 'bridge' program is run, it could just as easily be a FIDO, CITADEL, PCBOARD or whatever format, the sky is the limit. NTS and ZIP Routing NTS and ZIP Routing NTS and ZIP Routing There has been some recent scuffling over some NTS, Zip-code based forwarding with no @BBS fields. AS you know this won't fly in PRMBS and so to keep some semblance of continuity. I have added the following 'feature' (editorial comment: read 'feature' as 'kludge' as in 'sloppy patchwork!') IF the message is type 'T' (TRAFFIC) and IF the @BBS field is blanked, and IF the first character in the TO field is a DIGIT or IF the first three characters of the TO field match "NTS" , PRMBS will duplicate the TO field into the @BBS field. This is, to me, a temporary measure while I hope saner heads have a chance to prevail, but meanwhile "the mails must go through!" Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 23 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 23 Message Expiration Dates Message Expiration Dates Message Expiration Dates Starting in an earlier version of PRMBS, a command was entered that permitted the sysop to search messages for a line of code that read "Expires: yymmdd", and compare it to the current date and if it is less, select the message for killing. The facilities now exists to automatically enter the expiration date. There are two configuration parameters that allow the sysop to enter the 'default' expiration period for 'P' messages and non-P messages. It takes the current date and adds the specified number of days and sets it as a default expiration date, that will get written into the text of the message as the first line after the RFC 822 header (one blank line after actually). The ways to override this 'default' are as follows: - on the 'S' line it may be specified as the last parameter, for example SP ALL @ KX1XXX < W3ZZZ X880112 SP ALL @ KX1XXX < W3ZZZ X880112 SP ALL @ KX1XXX < W3ZZZ X880112 - it may be actually present in the text of the message already in which case the value overrides the default. These expiration dates are not absolutes. The sysop is free to 'exploit' them as he sees fit, which is as it should be. There are two commands which aide this 'kx' and 'ex'. They are explained in more detail below in the command summaries, but suffice it to say that the messages are examined strating with the most recent and working back, looking into the text body for the "Expires: yymmdd" and determining whether to display it to the sysop for killing and/or editing. The command 'kx -x #14000' could be scheduled in the event scheduler and it would blanket kill each and every expire message back to # 14000 on every forward pass, or once a day, whatever. IF this is done, I suggest that archiving of killed message be done. ON the other hand most sysops will undoubtedly do it by hand. The "ex" command allows the expired messages to be IDed quickly and the killing can be done manually, or the message reread, filed, replied to, or whatever. The big point is that we now have an automated system of Identifying 'old' messages. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 24 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 24 A QUICK START to Getting PRMBS Up and Running A QUICK START to Getting PRMBS Up and Running A QUICK START to Getting PRMBS Up and Running A quick start to getting PRMBS up to play with it. This will PRMBS bring it up for Port A == COM1 with one port only. All systems: 1 - edit AUTOEXEC.BAT for your TZ and EDITOR Strings SET TZ=EDT4 SET EDITOR=EDLIN (or NED or WS or ...) 2 - check CONFIG.SYS for files at least 25 and buffers at least 35 3 - unless you want UTC time , set your RTC clock to local time and let the TZ conversion bring the BBS to Zulu time. FLOPPY: 1 - copy CONFIG.A to floppy for A drive as CONFIG.MB edit names and calls and TNC2/DCD questions only 2 - copy MBBIOS1.COM and MB.EXE to same floppy 3 - copy HELP, INFO, MENU files to same floppy 4 - copy FWD.MB to floppy as FWD.A and edit appropriately 5 - create subdirectories on that floppy named MAIL and FILES as sub-directories under root A:\> MD MAIL A:\> MD MAIL A:\> MD MAIL A:\> MD FILES A:\> MD FILES A:\> MD FILES A:\> MD FWD A:\> MD FWD A:\> MD FWD 6 - connect TNC to COM1 serial connector via fully wired cable (i.e. pinss 1,2,3,4,5,6,7,8,20 wired straight thru) 7 - bring up some kind of modem program and verify operation. Check baudrates. and alter TNC for the follwing conditions; AUTOLF OFF AUTOLF OFF AUTOLF OFF ECHO OFF ECHO OFF ECHO OFF PARITY 0 PARITY 0 PARITY 0 AWLEN 8 AWLEN 8 AWLEN 8 FLOW ON FLOW ON FLOW ON TXFLOW OFF TXFLOW OFF TXFLOW OFF TRFLOW OFF TRFLOW OFF TRFLOW OFF XFLOW OFF XFLOW OFF XFLOW OFF STREAMSW $00 STREAMSW $00 STREAMSW $00 XON $0 XON $0 XON $0 XOFF $0 XOFF $0 XOFF $0 START $0 START $0 START $0 STOP $0 STOP $0 STOP $0 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 25 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 25 8 - lets run it A:\> MBBIOS1 A:\> MBBIOS1 A:\> MBBIOS1 A:\> MB A:\> MB A:\> MB HARD DISK: (same as above, except) 1 - make a BBS sub-directory C:\> MD BBS C:\> CD BBS C:\BBS> 2 - go to step one above and think HD instead of floppy, using 'C:' instead of 'A:' where appropriate. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 26 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 26 Memory Utilization with DoubleDOS and PRMBS Memory Utilization with DoubleDOS and PRMBS Memory Utilization with DoubleDOS and PRMBS /-------------------------\ /-------------------------\ /-------------------------\ | MSDOS / PCDOS | Operating System from boot-up | | | | |-------------------------| |-------------------------| |-------------------------| | COMMAND.COM | Initial load of command processor | | | | |-------------------------| |-------------------------| |-------------------------| | DOUBLEDOS | Multi-tasking Operating program | | | | |-------------------------| |-------------------------| |-------------------------| | COMMAND.COM| COMMAND.COM| Individual command processor for each | | | | | | |-------------------------| |------------|------------| |-------------------------| | - | | COMM BIOS | COMM BIOS | Communications BIOS programs for each | | | | | | |-------------------------| |------------|------------| |-------------------------| | - | | OPT. TSRs | OPT. TSRs | Optional TSRs (Superkey, SK, etc) | | | | | | |-------------------------| |------------|------------| |-------------------------| | - | | PRMBS | PRMBS | MailBox program | | | | | | |-------------------------| |------------|------------| |-------------------------| | - | | | | Additional copies of COMMAND.COM as | | | | | | | DOS ESCAPE | DOS ESCAPE | required to sub-run programs under | | | | | | | | | PRMBS | | | | | | \-------------------------/ \-------------------------/ \-------------------------/ There are/can be many problems associated with DoubleDOS but the the most important considerations are as follows: 1 - COMBIOS/MBBIOS - these Communications BIOS programs must be run from 'under' DoubleDOS rather than before DoubleDOS. If you are running QuadBIOS and splitting ports to either side of DoubleDOS you have no choice but to run the BIOS before DoubleDOS. The problem here results when a port is undr hardware flowcontrol and stuck within the BIOS porgram and the user tries to switch sides. I will be honest and say I am unsure of the exact mechnaism here but let it suffice to say some pretty 'hard' lockups have occurred or even crashes. 2 - 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 amountas 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 reackoning', that is to say COMMAND.COM keeps track of the number of Kbytes of 'erases' and 'cretaes and using the base number arrives at the number of bytes free. Since the COMMAND.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 of on its own merry way. It takes but a few hours til 'sapce available' on one side will not matc the other. The two numbers often will not have any basis in reality. Recently 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 (here in the NE US the night time is the busiest with NETROM-aided forwarding going full bore til 0500 local at least. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 27 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 27 PROCESS CONTROL Commands PROCESS CONTROL Commands PROCESS CONTROL Commands The following keys allow fine control over various happenings of the BBS. Since there is a constant poll for these keys, during certain processes 9described below) MSDOS type-ahead is effectively defeated. With time you will get the feel for when you can 'type-ahead' and when you cannot. ctrl-D (^D) ctrl-D (^D) ctrl-D (^D) This key is used to interrupt from console to chat with a user, to enter into char when the user has requested it, and to return from terminal mode to mailbox prompt, or from chat mode to back on-line. ctrl-E (^E) ctrl-E (^E) ctrl-E (^E) this command is used to bring the mailbox out of 'waiting for connect' or 'auto-answer' mode to local console command ctrl-F (^F) ctrl-F (^F) ctrl-F (^F) this is the 'twit key' or 'time-out' key. When ever the BBS is in its routine 'getting a line of data from the port' 9which is most of the time!) this key being pressed trips the time-out timer regardless of how long or short it has been since the last valid line of data from the user. In effect then he is twitted by a false induction of the time-out and the BBs code just handles it like he quietly went away. ctrl-K (^K) ctrl-K (^K) ctrl-K (^K) This is the 'text stopper'. All routine which read and list mail headers, files, etc, check for this key being pressed while you are doing your displays and if so stops the display right in its tracks. It does not abort it exactly but rather simply ends it and reports all is done. This allows you to stop a twit incessantly re-reading a long message or getting his jollies do an L 1 on a 400 message system! ctrl-W (^W) ctrl-W (^W) ctrl-W (^W) This is the 'who' key. In the middle of a long download you can strike ctrl-W and it will dump the local console status display line that you normally get before each BBS prompt is sent to the user. It does not interrupt his session, but lets ya know who is there and if you have any mail. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 28 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 28 PRMBS - Packet Radio MailBox System PRMBS - Packet Radio MailBox System PRMBS - Packet Radio MailBox System Preliminary Release Command Summary Preliminary Release Command Summary Preliminary Release Command Summary This is a summary of the commands for the major revision 0.98 of the Packet Radio Mailbox System. It is aimed at the sysops so that they may better understand the general manner in which the MailBox functions internally so that they may best utilize the powers this system gives them. All commands are started with a line beginning ">>", the command itself, as parsed by the command dispatch table is given, followed by the name of the procedure in the C source code that is called, this is given in case you want to follow how the system works. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - USER Commands - available to all users, LOCAL, REMOTE and REMOTE SYSOP USER Commands - available to all users, LOCAL, REMOTE and REMOTE SYSOP USER Commands - available to all users, LOCAL, REMOTE and REMOTE SYSOP >> Menu/Help Request: "?" (do_help) Menu/Help Request Menu/Help Request "h" (do_help) "help" (do_help) X - menu/help summary X ALL - entire menu/help list X xxx - menu/help explanation for 'xxx' * where 'X' is '?', 'h', or 'help' Menu is short one line descriptions, help is length descriptions with syntax explanations. File called MENU.MB or HELP.MB, set up with leading '#' as entry delimiters. Entry requires only minimum letters to get match. Must watch it though '? S' will get SEND every time , though the commands exist as S (send) , and SM (send multiple) >> Go back on-line: "b" (bye_bye) Go back on-line Go back on-line "bye" (bye_bye) Simply place MailBox back on-line awaiting remote or local connections. Mail, user, and Log files are closed, system monitors TNC type ports. >> Remote user request to: "chat" (utalk) Remote user request to Remote user request to User makes request, if local chat flag is disabled he immediately gets a 'Sorry he is not here. please leave a message' type response. If the local flag is enabled, the system gives a sickening set of beeps every 6 seconds for one minute, if the sysop hears them and wants to respond, he simply types a ^D (ctrl-D character) and he is placed on line with the user. The 'going into terminal mode' strings are sent to the TNC and the sysop then has to place himself into CONV. When done the sysop types another ^D and 'coming out of terminal mode' strings are sent, TNC connect status checked and BBS is returned Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 29 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 29 either to REMOTE status or on-line awaiting connect if the user went away during the chat. If the sysop doesn't hear the beeping after one minute it sends the 'sorry, leave message' response and goes back looking for another command. >> List of commands: "cmds" (cmdlist) List of commands List of commands This simply goes through the command dispatch table and dumps the strings containing the commands available on the system, in tabular form 8 to a line. system. If you are at Local console it dumps three lists, LOCAL, SYSOP, REMOTE. If you are a remote SYSOP and in R/Sys mode you get REMOTE and SYSOP, if you are a mere user you get the REMOTE list. >> Download a file: "d" (dnload) Download a file Download a file "d filename ###" "d filename -###" "d filename ###-###" You may simply download a file using the command plus a filename. From the local console this gets the file in 'paged' form. You may also download a file by asking for only the first #### bytes of the file (i.e. D FOOBAR.TXT 400 ) or download asking to skip the first #### bytes of the file (i.e. D FOOBAR.TXT -400), or you may ask for a 'middle piece' of the file (i.e. D FOOBAR.TXT 3000 6000). These extra options allow a file to be 'sampled' , or if a long download got trashed, you may come back and get the tail end of it, or simply read a long file in pieces. Downloads on the air are also subject to a sysop configurable limit in length during some 'window'. For example you might say that from 1800 to 2300 local time no file greater than 6 K bytes may be downloaded. The download limit is computed against what was requested, i.e. for simple download, the entire file size, for the other the arithmetic is done and then permission is determined. The system is 'kludged' to prohibit the accessing of any file or file-path string containing the string "PASSWORD.MB". It refuses to acknowledge the existence of the file. >> Directory Request: "dir" (mbDir) Directory Request Directory Request "dir [path]\[file-spec]" Simple listing in directory order of the files in the "FILES" area or some sub-directory. There is the same 'ignoring' of the existence of the file "PASSWORD.MB" as there is in download. If the user types forward slashes '/' instead of the backslashes '\' required by MSDOS, they are translated to back slashes. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 30 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 30 >> Edit message header: "edit" (e1msg) Edit message header Edit message header "edit msg#" This command allows the header from the MAIL.DAT file to be edited. The fields available are the FROM, TO, @BBS, title, message type, message status, forwarding priority (allows type to be retained in 'forwarding type' messages between PRMBS systems (i.e. SAF DXINFO PRMBS @ WB2MNF )) For remote users w/o SYSOP privileges, they may edit only messages TO/FROM themselves, while R/Sys and Local can edit any message. >> Scan headers for text: "ft" (scan_hdr) Scan headers for text Scan headers for text "ft text_string" "ft text_string msgno" This will do a case-insensitive search of the TO/FROM/@ fields as well as the message subject/title for a text-string. If found the header is listed and the search continues. Upon completion of the listing, the first message is displayed with the query "view message (y/n/x)" and the user can chose to read it. If the message number is included, the search will start at that number. >> Remote file request commands: "get" (make_req) Remote file request commands Remote file request commands "get file host" "getdir" (make_req) "getdir dir host" "getmsg" (make_req) "getmsg ### host" Any user, Local or remote may use these commands to quickly compose a file or directory request to another system. This saves them the often complex setup of the file request message; "SP REQFIL @ WB2MNF \n FOOBAR\SNAFU\ORSNATZ.DOC @ K3PGB" "SP REQFIL @ WB2MNF \n FOOBAR\SNAFU\ORSNATZ.DOC @ K3PGB" "SP REQFIL @ WB2MNF \n FOOBAR\SNAFU\ORSNATZ.DOC @ K3PGB" These messages generated will be sent to another system. Upon arrival at that system, instead of being saved in their form as a normal message, they generate a return message containing the directory, file, or message requested, or an appropriate error message and then are saved. the outgoing message is the only record of the incoming message. Provision has been made to 'control the access to these features. If you do not create an permission file, the features have open access. If the permission file is created (REMOTREQ.MB, and it must be in the default directory) then the originator of the message must meet a wildcard match criterion. here are some examples; Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 31 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 31 file REMOTREQ.MB contains: N1AA N1AA N1AA N2BB N2BB N2BB N3CC N3CC N3CC W4XXX W4XXX W4XXX this means that only those calls listed will be permitted the use of the Remote Request features. Now to make an 'open system' with a few exclusions you would set up the file like; !N3XXX !N3XXX !N3XXX !N4YYY !N4YYY !N4YYY !N5ZZZ !N5ZZZ !N5ZZZ * * * the first calls are specifically denied REQ command permissions, all other calls will drope through them and match the '*' The same mechnaism is used to 'control' RMAIL access. See the entry for RMAIL. >> Monitor list and connect log: "heard" (prthrd) Monitor list and connect log Monitor list and connect log The familiar 'J'-list command from RLI/MBL systems, it lists the most recently heard systems and most recently connected stations. The number of entries is determined n the configuration file. The information is preserved in the MON.MB file between power down and power up of system. >> Query/Enter User's Home BBS: "home" (home) Query/Enter User's Home BBS Query/Enter User's Home BBS "home call" The user may query what the system thinks is his home bbs and may enter that information into the system or alter existing value. this is important because PRMBS makes use of the home bbs field. (i.e. if PRMBS say, on WB2MNF has a user, W1XXX and he lists his home BBS as K2ZZZ. if mail comes in addressed to W1XXX @ WB2MNF, the WB2MNF will be stripped off since it matches the name of the bbs , BUT before saving the message a check is made to see if W1XXX is a user on the system. That being found his HOMEBBS field is checked, it is filled in and the call is NOT WB2MNF, so the @BBS field is readdressed to W1XXX) >> Sysop's "Brag File": "info" (show_info) Sysop's "Brag File" Sysop's "Brag File" Simple call to file download, dumping the file INFO.MB, which contains info about PRMBS and the sysops own station configuration, PRMBS and may also, actually should also contain a brief statement of the policies concerning the operations of that station. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 32 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 32 >> Kill messages: "k" (multi_msg) Kill messages Kill messages "k # # # # # ... #" "k #-# #-# .... #-#" "k # #-# #-# # # ... #-# #" Messages may be killed by number or range of numbers. The individual numbers or ranges may mixed on the same command line. When a range of messages is specified each message in the range has its header line presented and the user is prompted for a "Kill Msg #12345 Y/N". >> Kill my messages: "km" (klmsgm) Kill my messages Kill my messages "km -x" "km filename" "km -x filename" Kills all 'read' (status = 'Y') messages addressed to the user. As with any 'range of messages' kill, the headers are presented and the the user is prompted for a "Y/N". However, if the option "-x" is specified, it simply goes ahead and kills the messages one after another and only tells you it has been killed as it kills it (I call this the "RAMBO" option!) It is a dangerous option in that once it starts its too late for a remote user. The sysop may stop the cycle by hitting a ctrl-K from the local console. The optional 'filename' may be used by Sysop and remote sysop to archive the kills to one file. Each message is appended and it works with or without the 'Rambo' flag. >> Kill traffic: "kt" (kill_trfc) Kill traffic Kill traffic "kt # # # # ... #" This is just another KILL but it also generates a "service message" to the packet originator of the message telling him who,when,where his message was 'taken from' the packet system. The forwarding headers of the incoming message are parsed and a return path is specified as well as the correct return address. There are no ranges permitted here only a 'list of messages' There are two configuration parameters that effect KT. The first is one which you answer YES or NO concerning the service message generation. A YES means that a service message will be generated, a NO that it will not. The other parameter is the default message expiration date for the service message. >> User Mail Service: "mail" (mail) User Mail Service User Mail Service "mail" "mail -n" "mail addr [addr .. addr]" addr = call or call@bbs This is a new feature aimed to take the place of the multiply clumsy R, reply, Kill commands requiring message numbers. Simply typing 'mail' with no arguments presents the user with a list of all messages with his call in the TO field. Also if it is the Sysop Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 33 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 33 himself all messages with "SYSOP" in the TO field. It then presents a limited sweeper that allows the simple REMOTE user to Edit header, Kill, Reply To, Read/View the message. It was chose to default to listing all, read and unread to encourage the user to keep his mailbox clean. Since the old LM and RM didn't show read messages he had no idea of the extent of his 'mailbox'. Now sysops will have lots of read mail, so the '-n' (newonly) flag is there, and will generally to be downplayed to the regular user. Next is 'mail' with multiple arguments. This is the primary message entry vehicle. It supplants the "S" commands which have been kept only for RLI forwarding compatibility. This single command permits the creation of a message text which may be sent to one or more individuals. The "call@bbs" form must be entered on the line with no spaces. The @BBS does not need to be filled in if the person is a no spaces no spaces local user on your system or is a distant user and has his HOMEBBS specified, in which case the @BBS will be automatically filled in. The second prompt from the system will be for the title/subject of the message, and the the text for the message is gathered. The message is simply typed in line by line. The ctrl-Z or "/EX" will end the message as before, but a simple "." on a line by itself will also end the message. there are a new set of commands available to the user they are the "~" (tilde) escapes and are as follows: ~e - active from local console only. this takes the temporary work file you are using and throws it into your favorite editor (specified by a DOS environment variable EDITOR) allows you to do your editing and returns you to message input mode again. ~m #### - will append the entire text of message #### to the message currently being composed. ~p - simply re-display the text of the message so far ~q - quit or abort the message being entered without saving. ~r filename - will append the contents of the file "filename" to the message currently being composed. ~tx - x being a message type, the default type is 'P', but it may be altered The command "/ABORT" works the same as the "~q". The tilde commands are a little controversial because not all systems seem to have the tilde (ASCII 126($7E)) key. On the TRS-80 Model 100 its available using the GRPH key, check the users manual. On the PK-64A you are out of luck, there is supposed to be a Commodore Key sequence to do this but its 'trapped' by the firmware. If you are running the WB4APR C-64 BBS its a simple fix to the translation tables, then use the terminal mode of the BBS to access a PRMBS PRMBS system. It would only be a problem if the user of the PK-64 were a remote sysop, then he would be hampered, but otherwise the PK-64A Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 34 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 34 won't lose anything, he just won't gain any new powers. >> Remote user mail service:"rmail" (mail) Remote user mail service Remote user mail service "rmail @bbs addr ..... addr" This feature allows a user to snd a message to several recipients with only a single copyof the message traveling alongthe route to some point common to all messages, where it is then 'exploded' into the appropriate number of messages to reside there or be forwarded on. It is exactly what its name implies, a 'remote' mail command. RMAIL @KD6TH N2DSY N1CUI@N1CUI KB7UV@N2MH W2VY@KD6TH (here it will be prompted for title) COSI Code design review (here it will prompt for text) The meeting will be ..... ..... ..... /EX One message will be generated, it will be addressed to RMAIL@KD6TH and it will have on the "To: " line in the RFC 822 internal header; To: rmail@kd6th n2dsy n1cui@n1cui kb7uv@n2mh w2vy@kd6th This message will travel through all system (PRMBS 0.98P or not) innocuously as a simple message UNTIL it hits KD6TH where the 'RMAIL' with KD6TH stripped out will be decoded. The message will now 'explode' into 4 copies, individually addressed to N2DSY, N1CUI, KB7UV and W2VY. I should not need to explain the benefits of eliminating 3 of the 4 copies of the message for transmission to the point of divergence on their respective paths. The feature also supports remote alteration of message types in the following manner; RMAIL @KD6TH -TB N2DSY N1CUI@N1CUI KB7UV@N2MH W2VY@KD6TH The "-TB" says make all the messages following type 'B'. Now you can mix types with the 'type change' command being in effect until its is superseded by an additional type chnage command. RMAIL @KD6TH -TB N2DSY N1CUI@N1CUI -TF KB7UV@N2MH W2VY@KD6TH This will make the first two messages as type B and the last two as type F. The use of this feature may be controlled by the sysops who are the recipeinets of the messages to be exploded. They may have a file called RMAIL.MB and it functions in the same manner as the control RMAIL.MB RMAIL.MB file for the REQ commands. (See the explanations under GETDIR etc.) Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 35 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 35 >> Enter the user name: "name" (mkname) Enter the user name Enter the user name "name firstname" "name firstname lastname" The is permitted to query the system as to what it thinks his/her name is and to enter that name into the system. You may enter up to two strings to be printed as a first and last name. The limit is 20 characters. >> Read message(s): "r" (multi_msg) Read message(s) Read message(s) "r # #-# ..... #" "v # #-# ..... #" The same range of variations as the 'K' command. <R>ead will read a message, messages, or range of messages displaying only the message body, including its RFC822 header if present. the <V>erbose read command will display the entire body of the message as received, including the forwarding headers. There <R>ead command may be 'fooled' if someone along the way has a forwarding header that does not conform to the minimum standard of containing an "R:" at the beginning and an '@' sign prefixing its @BBS. >> Reply to a message: "reply" (snd_reply) Reply to a message Reply to a message "reply msg#" This simple command allows the user to reply to a message sent to him or a bulletin. It reads the message being replied to and takes the FROM field and copies as the TO field of the reply. It takes the title of the old message and prefixes it with "Re: " (only if it does not already have such a prefix, as with a repeated exchange of ideas on a subject) and makes it the title/subject. It reads the text of the messages and parses the forwarding headers and determines the source BBS of the message and makes that the @BBS address for the reply. AS mentioned elsewhere, if any header in the string does not conform to the minimum standard, the @BBS field will be in error. If there is any question as to the accuracy of that, user should exercise the "edit" command to correct the addressing. >> Set users highest message read: "setmsg" (setmsg) Set users highest message read Set users highest message read "setmsg [ top | msg#]" User may query or set the highest message the system thinks he has read. The code is set up so that it does not bump the user record for messages read just because he connect s and disconnects. But if a user logs in and lists and the decides not to read anything, it means the next time he logs in all the 'new' messages from his time will be displayed as well as the 'real' (relative to last logon) new messages. So when done he may simply type "setmsg top", or if maybe there is a message he wants to come back to which is, say, message # 1234, he might enter the command as "setmsg 1233", guaranteeing he inclusion of #1234 in his next 'new messages list' Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 36 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 36 >> Upload a file to the system: "u" (upload) Upload a file to the system Upload a file to the system "u filename" User may upload a file to the system. It prompts him for a one line description of the file, which is entered as a message to the sysop, telling him there has been an upload. The file will be uploaded to the "upload directory" specified in the CONFIG file. If that directory is the same as the "files directory" uploads then are immediately visible to subsequent users, if it is not, then they are 'safe' until the sysop has time to review the file and decide where to place it. >> User information retrieval: "user" (chk_usr) User information retrieval User information retrieval "user call" Any user typing simply "user" will get a display of his user statistics about himself, i.e. name, home bbs, high message read, etc. If he enters "user call' he gets the same info for the user with that call, or he gets a message the person is not a registered user on this system. >> What version of the software is this: "ver" (d_vers) What version of the software is this What version of the software is this The displays the version level of the PRMBS software. PRMBS >> Toggle remote sysop mode: "@" (mksys) Toggle remote sysop mode Toggle remote sysop mode "@" (mkrem) This command toggles the system state between REMOTE and SYSOP (implied remote sysop, as opposed to LOCAL which is the sysop at home, which has even more power than remote sysop). If a file called PASSWORD.MB is not present it will simply check the users' user record and see if his call is flagged to remote sysop powers, if it is the system flips over to R/Sys mode and the prompt alters to "next?". The difference between LOCAL and Rsys is dramatic for the user with such power. Before as a simple logged in user, when he did a list he only saw messages to/from him, and non-private and non-traffic message that had no @BBS filled in and all '$' and 'F' messages. Now as an R/Sys he sees EVERYTHING. he may kill anything and he has some new commands open. All commands that were valid from REMOTE are valid in R/Sys, plus he now may delete files make files out of messages, and others. Specified in the R/Sys commands below. If the PASSWORD.MB file is present the user file is checked for the users SYSOP flag is set and then is presented with a password string to which he must reply. The exact mechanism of this is described elsewhere. If it fails the user is returned to normal REMOTE mode. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 37 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 37 REMOTE SYSOP Commands: available to LOCAL Console and R/Sys REMOTE SYSOP Commands: available to LOCAL Console and R/Sys REMOTE SYSOP Commands: available to LOCAL Console and R/Sys >> Delete a file: "del" (delfiles) Delete a file Delete a file "del [path]\filename" Simple delete a file. Unambiguous file name required (i.e. no wildcards!). MUltiple files may be deleted on the same command line, just specify additional file names separated by a space. >> Delete a user from user file: "deluser" (deluser) Delete a user from user file Delete a user from user file "deluser call" When you delete the user, the call stays in the file except the first character of the call is replace with a '*' and the 'delete flag' is set in his record. The call will stay until a 'GU' command (untangle user file) at which point it will not be copied to the new user file. >> Display user(s): "du" (duser) Display user(s) Display user(s) "du usercall" "du [ b | e | l | s]" This command will display a user list (paged on LOCAL console) in its entirety, or by saying "du usercall" it will give just the record for that user. It also allows selected lists by using the options shown above: b - displays only calls flagged as BBSes e - displays only calls flagged as excluded l - displays only calls flagged as local users (this privilege allows user access on a BBS only port. s - displays only users flagged as R/Sys >> Edit a user record: "eu" (eduser) Edit a user record Edit a user record "eu usercall" The "eu usercall" permits editing a user record, Name, Homebbs, local user sysop, bbs, landline modem use permitted, and modem password if the modem use is set. The simple 'EU' command enters into a 'sweeper' which presents all of the calls in the system one by one which may be selected for deletion or editing. If you are ion LOCAL console the command is a 'single-key stroke' entry not requiring a CR to move from call to call. >> File a message: "file" (file) File a message File a message "file msg# file" A quick way to make a file from a message without having to go into the 'message sweeper'. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 38 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 38 >> Message forwarding: "fwd" (dofwd) Message forwarding Message forwarding "fwd portscr [-bnpro] call file ... file" See the earlier discussion for the more conceptual explanation of the forward command. This will just discuss syntax and fine details. The first argument after the Port-ID and the optional parameters must be a valid ham call that exists in your CALLDIR.MB. The remaining arguements may be any up to 8 char filename or ham call. If he argument contains a '*' or '?' or the argument does exist as a file with the name 'argument.FWD', the argument is fed to the forwarding process as a call selected. Thus a whole forward stream could be fabricated without any '.FWD' files at all if the requirements of the station could be met in that fashion. FWD B WB2RVX NTS* NORTH ?6* ?7* ??7* FWD B WB2RVX NTS* NORTH ?6* ?7* ??7* FWD B WB2RVX NTS* NORTH ?6* ?7* ??7* FWD B WA2VXT KE2M FWD B WA2VXT KE2M FWD B WA2VXT KE2M and so on ..... A station completing forwarding will be sending the F> will get mail addressed @BBS for him. Then if there is an entry in R_EVENT file he gets anything specified in there. I can set my R_EVENT file now to handle all sorts of contingencies M 0100 FWD B -r WA2SNA NORTH M 0100 FWD B -r WA2SNA NORTH M 0100 FWD B -r WA2SNA NORTH M 0100 FWD B -r N3ET NWEST M 0100 FWD B -r N3ET NWEST M 0100 FWD B -r N3ET NWEST M 0100 FWD B -r N2EVW NORTH M 0100 FWD B -r N2EVW NORTH M 0100 FWD B -r N2EVW NORTH M 0100 FWD B -r WB2RVX NWEST NORTH SOUTH WORM M 0100 FWD B -r WB2RVX NWEST NORTH SOUTH WORM M 0100 FWD B -r WB2RVX NWEST NORTH SOUTH WORM ..... and so on The 'portscr' designation is the port letter (A,B,C ...) and the 'script number'. There is a file called CALLDIR.MB which contains references to connect scripts for stations. A sample of the file is shown below; >1 K3DSM >1 K3DSM >1 K3DSM @K3DSM @K3DSM @K3DSM *** EOF *** EOF *** EOF >2 K3DSM >2 K3DSM >2 K3DSM @WB2DRD-3 v WB2DRD-1 @WB2DRD-3 v WB2DRD-1 @WB2DRD-3 v WB2DRD-1 +to +to +to ?* ?* ?* !80 !80 !80 .C WA3DSP-5 .C WA3DSP-5 .C WA3DSP-5 !120 !120 !120 .C K3DSM-1 .C K3DSM-1 .C K3DSM-1 *** EOF *** EOF *** EOF >1 WB2RVX >1 WB2RVX >1 WB2RVX @WB2RVX @WB2RVX @WB2RVX *** EOF *** EOF *** EOF >2 WB2RVX >2 WB2RVX >2 WB2RVX @WB2DRD-3 v WB2DRD-1 @WB2DRD-3 v WB2DRD-1 @WB2DRD-3 v WB2DRD-1 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 39 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 39 +to +to +to ?* ?* ?* !90 !90 !90 .C WB2RVX .C WB2RVX .C WB2RVX *** EOF *** EOF *** EOF The number next to the '>' is the 'script number'. This allows you to specify how to get to the BBS. You could have several lines in a row which make several tries to forward to the same BBS by different paths. If no script number is specified, '1' is assumed. The '@' line is the line which gives the call and path (if needed) to establish the initial level 2 RF/TNC connection. This connection is detected by the DCD (Data Carrier Detect line - pin 8 from TNC for those TNCs with that feature to indicate CONN/DISC, generally TNC2s, TNC2 clones and derivations, and modified TNC1s) or *** CONNECTED to messages. *** CONNECTED to *** CONNECTED to If you look above and see the first script for WB2RVX and notice it is only an '@' line you will see how to make simple direct connects or 1 or more digi hops. Beyond this the level 3 connections through NETROMS or COSI swithces are determined by parsing strings. The NETROM has only one way to tell you it is connected and that is a string with the phrase "connected to" in it. So the 'make' string is defined as "+to" (case IS important!). NETROM, unfortunately has a number of ways of saying 'sorry Charlie' so we say, anything BUT the make string is a failure, the 'break' string in this case is "?*" the '*' indicating that 'anything' received that doesn't compare to the 'make' string will be taken as a failure. The timeout period can be set , in seconds, by the "!180", which means if no connect is perceived in 180 seconds at each step, you consider it a failure. Timeout and failure exit identically. The script processor assumes that if no additional "+?!" commands are recived that the strings/valuse remain for the whole script, or as in the case of the second K3DSM script, the timeout is lengthened as we get farther down the script. Speaking of timeouts, once the script is completed with the connect to the final deisred station, the timeout period reverts to the 'port-timout' period specified in the configuration. Concerning the options for the FWD command; the "b" and 'p' options indicate that regardless of outbound mail status that system will be connected to and polled for mail ('p') and bulletins ('b'). The 'n' option overrides the 'b' and 'p' polling options and essentially guarantees that regardless of the mail status, the system being forwarded to, etc, no "F>" mail polling command will be sent. The 'o' option permits sysop to forward to a station and go back online awaiting remote caller without waiting for timeout. The same as the 'o' option in 'event' command. Sysop can start action and walk Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 40 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 40 away. The 'r' option is used only in the r_event file and indictaes that a reverse forward is taking place eliminating certain calls for disconnect. One point, the FWD command, tests to see if it is connected whne it comes in, so if it is, the connect sequence is not issued. This permits you to connect to a station using the (T)erminal or (C)onnect commands and then ater doing whatver, decide to forward mail to that system. You no longer need to DISC and then let the FWD command re- establish the connection. >> Untangle Message file: "gm" (untmsg) Untangle Message file Untangle Message file This takes the MAIL.DAT message header file and copies it over retaining only the active messages sectors. The 'free sector' chain is left off, thereby effectively shrinking the file. After a long heavy forwarding session with lots of messages coming in at once then being forwarded out, the file will expand considerably more than if its a matter of get some, forward some the get more forward more (since 'free sectors' are used before allocating new ones) This can be critical on systems which are major mail forwarders, the larger the mail file is, the longer it takes to process forwarding. It has happened at one Beta site which is a heavy forwarder, that he had a 30K plus MAIL.DAT (@128 bytes per message that's over 240 message sectors) with but 40 active messages. The 'GM' can be run from the event scheduler, since it will exit gracefully if it detects a user on the opposite side in a multi-user configuration. >> Untangle user File: "gu" (untusr) Untangle user File Untangle user File This cleans out deleted users. It too may be run from the event scheduler and will also bow out quietly if a user is on the other side of multi-user configuration. >> Advanced message kill commands: Advanced message kill commands Advanced message kill commands kill by date: "kd" (kdmsg) kill by date kill by date "kd [-x] yymmdd" "kd filename" "kd -x filename" kill expired: "kx" (kdmsg) kill expired kill expired "kx [-x]" "kx filename" "kx -x filename" "kx [-x] [#msgno]" "kx filename [#msgno]" "kx -x filename [#msgno]" Kill by date will kill any message whose date is prior to the Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 41 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 41 date shown. It will present the messages and headers one by one and ask 'Y/N' to kill. Kill forwarded will call all messages marked status 'F' that aren't type 'F', these only occur when you do not set 'kill on forward', but it presents them one by one as above in "kd" Kill expired - reads the text of every message starting at the lowest in the system and searches for the string "Expires: yymmdd" and parses the date out and compares it to the current date, if it is prior to the current date it is presented for killing. The string must be left justified on the line to be valid. Since once you have gone through your 'old messages' it is costly in time to re-examine them over and over. You may optionally specify the message at which to start checking (i.e. you may type kx -x #14000, which says examine messages starting at number 14000 and delete automatically ('-x') any message which has expired. All of these cyclic search kill commands are subject to the ctrl- K console abort. The kill expired then can be started with the '-x' option and then stopped once you get back into areas you have searched before, the '#msgno' option above can be used to cut time when the 'kx' command is used in the event file. All of the above 'kill' commands have the '-x' RAMBO option available in which case it rips through and gives you the body count later. Likewise they all have the 'archive to a file' options using the 'filename' as detailed in the 'km' command above. >> Advanced edit commands: "ed" (kdmsgs) Advanced edit commands Advanced edit commands "ed yymmdd" "ex" (kdmsgs) These commands allows the message base to be masked by the same criteria used above in the 'kill' commands and presented for editing. There is only one direction in this and that is reverse order, so the 'c' key doesn't produce any change in direction. >> Send a file to a port: "port" (port_dump) Send a file to a port Send a file to a port "port ID filename" This command allows a file to be dumped to a port. It is usually used to send a setup file to a TNC when first bringing it back up after a non-BBS use of the TNC. >> Import/eXport messages: "import" (import_msgs) Import/eXport messages Import/eXport messages "import infile" "export" (dofwd) "export opfile ptr [ptr .... ptr]" This allows a disk file to be used as the medium of exchange, the concept was originally built by WA7MBL as a means to go back and forth to the TCP/IP smtp mail system. It was conceived independently on Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 42 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 42 PRMBS as a generalized mail transfer system. The MBL and PRMBS formats PRMBS PRMBS are identical and interchangeable. It might permit a large collection of interesting bulletins to be sent by diskette and US Snail to another part of the country without overly burdening the current system. Or it could be used to easily transplant the entire mail system from one BBS to another, say when one site needed to be shut down. >> Send multiple messages: "sm" (dist_lst) Send multiple messages Send multiple messages "sm distlist textfile" This permits you to send a single message to a predetermined list of recipients. The distfile is in the form: SP W1XXX @ W2YYY SP W1XXX @ W2YYY SP W1XXX @ W2YYY S W3QQQ @ W4ZZZ S W3QQQ @ W4ZZZ S W3QQQ @ W4ZZZ S W4RRR @ W6UUU S W4RRR @ W6UUU S W4RRR @ W6UUU ... and so on This makes individual messages to each and only that person is shown on the TO line. As opposed to the 'mail' command which show all recipients of the message on the TO line. >> Connect out to a station: "c" (lterm) Connect out to a station Connect out to a station "c portscr call [capfile]" "c port call v path [capfile]" This is a console command line connection routine. the 'portscr' is the same script get as for Bulletins and forward, the 'capfile' is an optional capture file name. After the connect is issued the system simply drops to terminal mode. The 'capfile' will be appended to and will be closed each time you exit the terminal mode, so if you exit quickly to check something, when you return you must use the 'T' command with a file specifier to keep it the capture alive. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 43 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 43 LOCAL Commands available only from local console LOCAL Commands available only from local console LOCAL Commands available only from local console >> Sysop enable/disable chat: "chat" (chat) Sysop enable/disable chat Sysop enable/disable chat "chat [ on | off ]" When chat is 'off', the user simply gets the 'leave message' routine immediately as opposed to the sysop being 'beeped' for one when it is 'on' >> Cleanup killed messages: "clean" (cleankilled) Cleanup killed messages Cleanup killed messages Messages are never 'killed' when a user is on the other side in a multi-user configuration. They are simply 'marked for killing'. This routine which can be scheduled in the event scheduler does the killing for those messages that are marked as such. >> Get out of program to DOS: "x" (done) Get out of program to DOS Get out of program to DOS Sayonara, we are done. This command can also be scheduled from the event scheduler. If employed with a BAT file having a 'goto' loop, it may be used to leave the PBBS and do some other things that need more memory than is available in a simple DOS escape, and then return to the PBBS. >> Enter terminal mode: "t" (lterm) Enter terminal mode Enter terminal mode "t port [filename]" Adequately described above in the Connect command, no 'portscr' needed, just a port spec. For remote sysop, if this were a multi-port (not multi-user single port!) configuration, he could 'gateway' out to the other port. >> Event scheduler: "event" (event) Event scheduler Event scheduler "event -i" "event -f eventfile" "event -r call" "event -ifr eventfile call" "event -irf call eventfile" "event -o" This procedure allows execution of a script of commands that may be direct port access commands to the serial lines to the TNCs, modems or other computers, DOS escape commands, and any SYSOP or LOCAL command. The format of the file is shown below; X H1H2C xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx X H1H2C xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx X H1H2C xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx X - is the event type D (DOS command), M (Mailbox commands), P (port commands) H1 - start hour of the permitted period of the event H2 - end hour of the permitted period of the event Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 44 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 44 C - cycle - may be E (even hours only), O (Odd hours only), A or <space> (All hours), 3,4,6,8 (on hours evenly divisible by that number) xxx..xxx - the arguements or commands for the event. I have included below sample of my own event file, below; D 0100 FWD_DOS1 D 0100 FWD_DOS1 D 0100 FWD_DOS1 P 0100 A P 0100 A P 0100 A TXD 26 TXD 26 TXD 26 BT [ BBS Forwarding Mail ] BT [ BBS Forwarding Mail ] BT [ BBS Forwarding Mail ] B E 90 B E 90 B E 90 MAXFRAME 2 MAXFRAME 2 MAXFRAME 2 RETRY 12 RETRY 12 RETRY 12 *** EOF *** EOF *** EOF M 0100 clean M 0100 clean M 0100 clean M 0100 fwd A2 K3DSM M 0100 fwd A2 K3DSM M 0100 fwd A2 K3DSM M 0100 fwd A N2EVW NORTH M 0100 fwd A N2EVW NORTH M 0100 fwd A N2EVW NORTH M 0100 fwd A2 N2EVW NORTH M 0100 fwd A2 N2EVW NORTH M 0100 fwd A2 N2EVW NORTH M 0100 fwd A N3ET M 0100 fwd A N3ET M 0100 fwd A N3ET M 0100 fwd A W3IWI SOUTH WORM M 0100 fwd A W3IWI SOUTH WORM M 0100 fwd A W3IWI SOUTH WORM M 0100 fwd A N4QQ SOUTH WORM M 0100 fwd A N4QQ SOUTH WORM M 0100 fwd A N4QQ SOUTH WORM M 0100 fwd A WB3FFV SOUTH WORM M 0100 fwd A WB3FFV SOUTH WORM M 0100 fwd A WB3FFV SOUTH WORM M 0100 fwd A WB2MNF M 0100 fwd A WB2MNF M 0100 fwd A WB2MNF M 0707 fwd A KB3UD NWEST M 0707 fwd A KB3UD NWEST M 0707 fwd A KB3UD NWEST M 0100 fwd A WB2YZS M 0100 fwd A WB2YZS M 0100 fwd A WB2YZS M 0100 fwd A -P WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 fwd A -P WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 fwd A -P WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 fwd A2 -P WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 fwd A2 -P WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 fwd A2 -P WB2RVX WEST NWEST SOUTH WORM NORTH *** EOF *** EOF *** EOF M 2306 chat on M 2306 chat on M 2306 chat on M 0722 chat off M 0722 chat off M 0722 chat off M 0100 clean M 0100 clean M 0100 clean P 0100 A P 0100 A P 0100 A D D D D D D TXDELAY 26 TXDELAY 26 TXDELAY 26 *** EOF *** EOF *** EOF D 0202 COPY MAIL.DAT MAIL02.DAT D 0202 COPY MAIL.DAT MAIL02.DAT D 0202 COPY MAIL.DAT MAIL02.DAT D 1010 COPY MAIL.DAT MAIL10.DAT D 1010 COPY MAIL.DAT MAIL10.DAT D 1010 COPY MAIL.DAT MAIL10.DAT D 1818 COPY MAIL.DAT MAIL18.DAT D 1818 COPY MAIL.DAT MAIL18.DAT D 1818 COPY MAIL.DAT MAIL18.DAT D 0202 COPY USER.DAT USER02.DAT D 0202 COPY USER.DAT USER02.DAT D 0202 COPY USER.DAT USER02.DAT D 1010 COPY USER.DAT USER10.DAT D 1010 COPY USER.DAT USER10.DAT D 1010 COPY USER.DAT USER10.DAT D 1818 COPY USER.DAT USER18.DAT D 1818 COPY USER.DAT USER18.DAT D 1818 COPY USER.DAT USER18.DAT The FWD_DOS1 is a .BAT file which reads my RTC and erase stray editor backup files that can accumulate whilst editing messages. "Event" is also 'scheduled'; itself. In the configuration file you specify the length of the event cycle, i.e. How often you wish to run the cycle. Traditionally it is 60 minutes, but now maybe anything from 1 to 1440 minutes. 60 minutes is normal and should generally be used. As this will dovetail best with non-PRMBS systems. But where PRMBS arrangements have been made and you are a dedicated mail system skeds of 20 and 30 minutes can be done, or if its a portable station using a Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 45 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 45 laptop MSDOS machine in an emergency environment you could go to either 1440 (in essence no cycle) and be polled from a central station), or to 5 or 10 minutes to be forwarding nearly constantly (probably entering messages from the other side of doubleDOS in a multi-user-user config). A personal BBS or a multi-user configuration on the user LAN side might only wish to sked once every 2 hours so 120 or even 180 minutes would suffice. You are asked for the minute to forward on, this is relative to 0 minutes of the start of the cycle. You are also asked an 'offset'. This is the 'grace period' allowed to start the cycle. lets say that you have a start of the 3rd minute of a 60 minute cycle, and that 03 has come and a user is on. For an offset of 5, If he logs off before 08 the event sked will still go off. For shorter than 60 minute cycles, a shorter offset should be used. If you miss it this time, the next time will be around soon. Likewise if you only kick off every 2-3 hours, you want to make sure you get it done so you might use an offset of 15-30 minutes. The timing computation is done with an absolute calculation of the number of minutes since midnight. This number is divided by the cycle length and the remainder tells us the time relative to this cycle. I must caution to take real care in selection of non 60 minute cycle time, care must be given to consider all of the stations forwarding characteristics on that same channel. The time window may be ignored by the option 'i'. The event file may be altered by specifying and 'f' option, with the next argument being the filename. Reverse forward events are scheduled by an 'r' option with the next available argument being the call. When 'f' and 'r' are both specified, the followon strings are in order the flags are set (see last two examples above) The reverse events scans the 'call' position of a forward string and looks for the call, that way any fwd event line containing that call as the destination will be executed. The 'o' option is the 'on-line' option. By specifying this option, the flag that gets set falsifies a 'time-out' immediately upon completion of the event script and returns the system online awaiting caller. This saves waiting around to put it back online after kicking off the forwarding and saves waiting for the console time-out to do it. The reverse event file is the same as an event file except that the FWD command should all have the 'r' option set. Having this file means that you can restrict what hours these reverse forward polls will work. If you do not use the 'i' ignore time option the time windows will return an immediate 'DONE' if they come in off time. We have a command and function called CLEAN. Its function and CLEAN CLEAN purpose are discussed elsewhere under its own command explanation. It Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 46 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 46 should be included as a 'scheduled' Mailbox command at the end of your forwarding commands in the event file. It can be scheduled several times in the event file, there is no reason why not, but likewise it does not gain you much. I might suggest that it be placed in at the front and he back of the mail file to 'clean' house in advance if possible. You may also want to schedule the 'exit to DOS' command X in the X X event file. IT may be used to exit out of PRMBS and do something else PRMBS PRMBS in DOS that requires more memory than can be shared with PRMBS. To do PRMBS PRMBS this you would have a line that read; M 01008 X M 01008 X M 01008 X This command say that over the expanse of the entire 24 hour day, ( i.e. 01 - 00) on the hours divisible by 8 (0,8,16), execute the command to exit to DOS. The companion piece to this would be to alter the BATch file you use to bring up the BBS to have a loop; :LOOP :LOOP :LOOP COMBxBIOS COMBxBIOS COMBxBIOS MB ( or MB -M -C CONFIG.A) MB ( or MB -M -C CONFIG.A) MB ( or MB -M -C CONFIG.A) SOM_PROG SOM_PROG SOM_PROG GOTO LOOP GOTO LOOP GOTO LOOP What happens is that when the MB program is exited the BAT file excutes SOM_PROG and then loops back and starts by trying reload COMxBIOS (which automatically senses if it has been loaded before and exits early ) and brings up MB again. Think of 'EVENT' as a BATch processor. You can have 'scripts' (think BAT file) of mailbox commands which can be executed from the command line by using the '-f filename' option. Say you are K2ADJ. Now Rod has taken the task for himself of distributing the ARRL Bulletins. he could make the process easier by creating a file called ARRLBULS. In this file he would have the following: sm arrl.dst DX sm arrl.dst DX sm arrl.dst DX sm arrl.dst PROPO sm arrl.dst PROPO sm arrl.dst PROPO sm arrl.dst QST sm arrl.dst QST sm arrl.dst QST fwd B WB2MNF fwd B WB2MNF fwd B WB2MNF Assumption here is that he got the latest bulletins from his source and placed them, into files with the generic names DX, PROPO and QST for the DX Info, Propagatiom, and general bulletins. Then he would type; EVENT -OF ARRLBULS EVENT -OF ARRLBULS EVENT -OF ARRLBULS and the system would ask him for the title for each group of messages and would create all three groups of messages. Then drop into forwarding. The -O option says he can go to to bed then, cause when EVENT is done running the forwarding, it will set itself back online. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 47 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 47 The only limit to what this can do for you is your imagination. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 48 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 48 AUXILIARY PROGRAMS for PRMBS AUXILIARY PROGRAMS for PRMBS AUXILIARY PROGRAMS for PRMBS A number of prgrams may be used with and/or have been created for use with the PRMBS programs. PRMBS DoubleDOS (c) (Soft Logic) - a multi-tasking executive for the IBM- DoubleDOS (c) (Soft Logic) DoubleDOS (c) (Soft Logic) PC and its clones which permits running two separate copies of DOS simultaneously in the RAM space. PRMBS has specificially been coded PRMBS to permit two entirely separate copies of the BBS to run simultaneously sharing one mail file and one user file. The multi- user flags internally yeild the CPU during 'waste-time loops' and help optimize the performance. True multi-user capacbility is achieved for up to one user on each of two ports. SWATCH.BAT (WB2DRD, later mods by WB2YZS) - a simple BAT file which SWATCH.BAT (WB2DRD, later mods by WB2YZS) SWATCH.BAT (WB2DRD, later mods by WB2YZS) displays color 'swatches' along with the appropriate ANSI sequences to reproduce it, so a SYSOP can select his color sequences for the BBS. MBFIX.EXE (NN2Z and a little KA2BQE) - a program to read a MBFIX.EXE (NN2Z and a little KA2BQE) MBFIX.EXE (NN2Z and a little KA2BQE) destroyed MAIL>DAT file and attempt to recover it. In the current state of the BBS it is rarely needed, but if a power outgae were to occur in the middle of a kill message sequence a forward or backward link can be broken. MBFIX will repair it. MBFIX can also be used to renumber your mail file and its associated message text files starting at 00001 . This is suggested for those systems that are not happy with 5 digit message numbers or even 4 digit message numbers and can logically be done at the first of any given year which should generally keep the message numbers down to 4 digigts for most of the year, with a few very busy systems going into 5 digits towards the latter part of the year. I also suggest year start for this renumbering for accountability reasons the message ID 1234@KA2BQE in 1988 explicitly defines the message to which you refer. It is extremely unlikely that any system would exceed the 65535 message number limit (at that point, the number 'rolls over to 0, i.e. 65536 == 0 , and on up again) SORTUSER.EXE (NN2Z) - takes the USER.DAT and will sort it into SORTUSER.EXE (NN2Z) SORTUSER.EXE (NN2Z) descending order by the most recent login date, or alphabetically by call. Since to provide USER.DAT file security that file is searched brute force from front to back, by sorting it into descending login date order you place the calls that login most recently to the front and therefore most likely to login again. If someone hasn't logged in for 2 months he doesn't need prompt service.(though the difference is but 20 seconds even for 400 users) LFAP-02A.EXE (WB2ENA) - A modification to the WA7DCH LFA (Log File LFAP-02A.EXE (WB2ENA) LFAP-02A.EXE (WB2ENA) Analyzer) specifically for PRMBS. Prints monthly summaries to disk. PRMBS TRANSLOG.COM (WB2ENA)P - program created by WB2ENA to take a large TRANSLOG.COM (WB2ENA)P TRANSLOG.COM (WB2ENA)P PRMBS log file and separate it into monthly files. Can be run from PRMBS DOS Escape in PRMBS Event scheduler and will clean out the log file PRMBS up to the current day. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 49 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 49 MBBIOS/COMBIOS (AA4RE) - a COMmunications BIOS replacement, which MBBIOS/COMBIOS (AA4RE) MBBIOS/COMBIOS (AA4RE) installs in memory prior to executing the PRMBS program. It is in PRMBS various forms and versions as eithe COMBIOS or MBBIOS. The only requirement is that the version of MUST support the BREAK command being sent for TRANSparent mode. The current version is MBBIOS version 2.6, which supports all the requriements of the current PRMBS. Generally versions of COMBIOS/MBBIOS 1.6 and later will work PRMBS with PRMBS. PRMBS ATOB-PC.EXE/BTOA-PC.EXE (KA2BQE) - a suite of programs and BAT ATOB-PC.EXE/BTOA-PC.EXE (KA2BQE) ATOB-PC.EXE/BTOA-PC.EXE (KA2BQE) files based on the Unix AtoB algorith and adapted by me to packet Radio use. Te BAT files conveniently allow you to specify an ARChive file name and a collection of files and will invoke ARC (c) or PKARC (c) to compress the files into a single ARC file and then pass it through the BTOA process producing an all ASCII file for transmission. Checksums are included so that validity can be checked at re-assembly time, plus the checksumming done in the ARC processes. MBPWD.EXE (KA2BQE) - simple program that reads the PASSWORD.MB file MBPWD.EXE (KA2BQE) MBPWD.EXE (KA2BQE) if the SYSOP choses to have one and displays the string with positions numbers in tabular form for easy use by Remote Sysops when responding to R/Sys password prompts. MBGETQTH.EXE (KA2BQE) - this program will read the text of all the MBGETQTH.EXE (KA2BQE) MBGETQTH.EXE (KA2BQE) messages and extracts the call and QTH of each BBS that forwarded mail into a file in the form of: "call","qth of bbs" Output will need be processed as it will contain many dupes of nearby BBSes that forward to you. MBGETFWD.EXE (KA2BQE) - this program also will read the text of the MBGETFWD.EXE (KA2BQE) MBGETFWD.EXE (KA2BQE) message files and produce a file with call pairs in it that take the station that forwarded the message to you and make its call he first of the pair and then write one pair for each BBS that handled the message on its way to you. These pairs indicate who you forward to to send mail to the second call in the pair. This also needs subsequent processing as dupes will be heavy. The result can be used to update the forwarding files. Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 50 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 50 APPENDIX A PRMBS Config Token Reference Table PRMBS Config Token Reference Table PRMBS Config Token Reference Table This is a list of the definitions of the '$' tokens used in the config file to reference system variables when doing sysop defined output strings: $A : Message - @BBS field $B : Message - type $C : Message header - next available number $D : System - Current date $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 (zero filled 5 digits) $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 $S : Message - forwarding priority $T : System - current time $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 - ouput a '$' Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 51 Preliminary - 02/04/88 - PRMBS Documentation - Beta ver 0.98 Page - 51 APPENDIX B Preliminary Spec for Standard Smart BBS ID String Preliminary Spec for Standard Smart BBS ID String Preliminary Spec for Standard Smart BBS ID String From: WA7MBL To: KA2BQE cc: W0RLI We have agreed on using characters to indicate features rather than a numeric value. I understand that W0RLI and supposedly some of the other West Coast coders support the idea, and thought we had the following proposed ground rules: 1 - The BBSid will be contained in brackets followed by a <C/R>. 2 - The initial field(s) may be used to identify the coder, the version, and any other information the coder desires to add. These fields should be kept brief, and are optional. 3 - The final field following the last '-' and preceeding the ']' is used to indicate available features. A character (or character followed by a numeric value) is used indicate features as follows: '$' - BID (OK/NO) forwardin available 'W' - WP Server 'Y' - (WA7MBL requests this letter be reserved for YAPPmail) The final field is the only required field. If NO features are available, the field may contain a single "0", thus [0] would be a valid BBSid (and is equivalent to sending no BBSid at all). 4 - An optional (but encouraged) field may preceed the final field. If used it will indicate the amount of message space (in K) that is available. The presence of this field is indicated by use of a final 'K'. Some examples: [XXX-1.3-10K-$] Version 1.3 of the XXX BBS. 10K available for messages. BIDs supported. [MBL-$] WA7MBL BBS BID supported. [C64-8K-0] A C64 BBS. 8K. No features.