HAM Radio 1

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

/ HAM Radio 1 / HamRadio.cdr / misc / rs150doc / rose100.ref < prev next >

Wrap

Text File | 1991-03-04 | 88KB | 1,892 lines

Documentation for ROSERVER / PRMBS Documentation for ROSERVER / PRMBS Documentation for ROSERVER / PRMBS Packet Radio MailBox System Packet Radio MailBox System Packet Radio MailBox System Reference Manual Reference Manual Reference Manual Brian B. Riley, KA2BQE Brian B. Riley, KA2BQE Brian B. Riley, KA2BQE ROSERVER / PRMBS Version 1.00 ROSERVER / PRMBS Version 1.00 ROSERVER / PRMBS Version 1.00 The materials distributed can be updated from the following sources by contacting me in the following places: Brian B. Riley , KA2BQE Brian B. Riley , KA2BQE Brian B. Riley , KA2BQE c/o MorningStar Keep, Ltd. Post Office Box 188 Underhill Center, Vermont 05490-0188 (USA) EASTNET: ka2bqe@ka2bqe.#nwvt.vt.usa.na ka2bqe@ka2bqe.#nwvt.vt.usa.na ka2bqe@ka2bqe.#nwvt.vt.usa.na CIS: 71420,3543 71420,3543 71420,3543 USENET: rutgers!hotps!n2dsy-4!ka2bqe rutgers!hotps!n2dsy-4!ka2bqe rutgers!hotps!n2dsy-4!ka2bqe Phone Line Access: (802) 899-9922- voice / voice mailbox (802) 899-9922 (802) 899-9922 (816) 635-5776 - MIDWEST JAMBALLAYAH (W5GTX) - 24 hours, (816) 635-5776 (816) 635-5776 3/12/2400 X,Y,ZModem, login, follow instructions (201) 387-8898 - RATS UNIX system 1200/1E7 - 24 hours, System (201) 387-8898 (201) 387-8898 V/ 3B1. Login: 'rats' (no password) follow instructions. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 ************************************************************************* ROSERVER / PRMBS Blatant Plea for Funds This is a PUBLIC SHAREWARE RELEASE of code. The original founda- tion of the code came from a pre-release of CBBS by W0RLI. From that point Dave Truli (NN2Z) and myself reworked and modified and innovated until what we have here is 95% original work, 3% of the original code and 2% from various other sources. Unlike the code for the other PBBS systems, not only is the run time package is available FREE of charge, BUT the source code is available FREE of charge and the docs (and their are actually real docs) are available FREE of charge. The only monetary remuneration that is REQUIRED is diskettes, mailers, and postage or reimbursement for same. I must, however, add that programming is my business. Any time I spend on this code answering questions, fixing bugs, adding new fea- tures, etc. is time taken from revenue producing efforts. So if you try this program, and like what you see, a donation in the amount of $20 or more would go a long way to seeing that I stay working at it. If you like what you got and want to contribute but cannot afford $20 send what you can spare and still have money for the next electric bill. If you do not contribute that's OK too. The fact that you run a PBBS means you are already contributing to this ham community effort. If you do not contribute, please understand that the supporting stations will get first crack at what time I have to spend on support and guidance. If I have time to answer question reply to messages etc for non-supporters, I will. I usually do find time somewhere, though, but as I said, putting food on the table has to come first. Brian Riley, ka2bqe Underhill Center, VT 28 April 90 ************************************************************************* DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 1 ROSERVER - Packet Radio MailBox System Command Summary ROSERVER - Packet Radio MailBox System Command Summary ROSERVER - Packet Radio MailBox System Command Summary ________ _ ______ _____ _______ ______ _______ _______ ________ _ ______ _____ _______ ______ _______ _______ ________ _ ______ _____ _______ ______ _______ _______ This is a summary of the commands for the Packet Radio Mail- box 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. Optional arguments are in "[ ]" and required arguments plain or in "{ }" with "|" where there are alternate formats of required arguments LOCAL Commands available only to the Super USER (main SYSOP) LOCAL Commands available only to the Super USER (main SYSOP) LOCAL Commands available only to the Super USER (main SYSOP) >> Get out of program to DOS: Get out of program to DOS Get out of program to DOS "x" (done) "x number" 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. You may use it schedule different exits to do different things by setting number to something other than 0. This number will be passed as a DOS ERRLEVEL. In fact you must do it, since a simple X will exit with ERRLEVEL 0 and be treated as a normal, I want to get the heck out of here exit! >> Enter terminal mode: Enter terminal mode Enter terminal mode "terminal" (lterm) "terminal 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 scheduler Event scheduler "event" (event) "event -i" "event eventfile" "event -i eventfile " "event -o eventfile" "event -io eventfile" "event -s cycle min offset" The last option '-s' is used to set the event cycle timing. No other option will be allowed (actually any other options will be ignored). IF this command is not executed via AUTO-EVENT the DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 2 system will never have an off-line event process. The valuse of the cycle duration is pre-set to zero whch means 'no cycle'. Otherwise this command will set the value. IF the value 0 is set in in a subsequent command, then there will be no cycle. The problem with doing this is that once that happens, the event cycle can not occur again to resurrect that value. Since this command is available to REMOTE SYSOP, again we have good reason to make use of the passwords AND to chose these people wisely. Aside from the use of the '-s' option to set the times initially, it also allows you to setup to have off-line process- ing occur at, say, 120 minute intervals during the day from 0700 local to 1800, then go to 180 minute cycle at 1800 and then to 30 minute cycles from 2400 to 0300 and 60 minute cycles from 0300 to 0700, This allows the mode to accommodate users best during the day and evening, and forwarding during the night. 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 REMOTE, SYSOP or LOCAL command. The 'i' option says to ignore any time parameters and execute every line. the 'o' option says to go back on-line-waiting when done the event file. If a filename is specified it may be from any drive or directory. The format of the file is shown below; X H1H2C xxxxxxxxxxxxxxxxxxxxxx X H1H2C xxxxxxxxxxxxxxxxxxxxxx X H1H2C xxxxxxxxxxxxxxxxxxxxxx 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 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 arguments 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 SE $7F SE $7F SE $7F CP ON CP ON CP ON CR OFF CR OFF CR OFF 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 swap A2 K3DSM M 0100 swap A2 K3DSM M 0100 swap A2 K3DSM M 0100 swap A N2EVW NORTH M 0100 swap A N2EVW NORTH M 0100 swap A N2EVW NORTH M 0100 swap A2 N2EVW NORTH M 0100 swap A2 N2EVW NORTH M 0100 swap A2 N2EVW NORTH DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 3 M 0100 swap A N3ET M 0100 swap A N3ET M 0100 swap A N3ET M 0100 swap A W3IWI SOUTH WORM M 0100 swap A W3IWI SOUTH WORM M 0100 swap A W3IWI SOUTH WORM M 0100 swap A N4QQ SOUTH WORM M 0100 swap A N4QQ SOUTH WORM M 0100 swap A N4QQ SOUTH WORM M 0100 swap A WB3FFV SOUTH WORM M 0100 swap A WB3FFV SOUTH WORM M 0100 swap A WB3FFV SOUTH WORM M 0100 swap A WB2MNF M 0100 swap A WB2MNF M 0100 swap A WB2MNF M 0707 swap A KB3UD NWEST M 0707 swap A KB3UD NWEST M 0707 swap A KB3UD NWEST M 0100 swap A WB2YZS M 0100 swap A WB2YZS M 0100 swap A WB2YZS M 0100 swap A WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 swap A WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 swap A WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 swap A2 WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 swap A2 WB2RVX WEST NWEST SOUTH WORM NORTH M 0100 swap A2 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-ROSERVER systems. But where arrangements have been made and ROSERVER you are a dedicated mail system skeds of 20 and 30 minutes can be done, or if its a portable station using a 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 enter- ing 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. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 4 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 the filename. 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 con- sole time-out to do it. We have a command and function called CLEAN. Its function CLEAN CLEAN and purpose are discussed elsewhere under its own command expla- nation. It 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 the back of the event file to 'clean' house before and after mail forwarding. You may also want to schedule the 'exit to DOS' command X in X X the event file. IT may be used to exit out of ROSERVER and do ROSERVER ROSERVER something else in DOS that requires more memory than can be shared with ROSERVER. To do this you would have a line that read; ROSERVER ROSERVER M 01008 X {errlevel number} M 01008 X {errlevel number} M 01008 X {errlevel number} 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), exe- cute the command to exit to DOS. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 5 The companion piece to this would be to alter the BATch file you use to bring up the BBS to have a loop; ROSEBOOT 0T-4800 1M-2400 ROSEBOOT 0T-4800 1M-2400 ROSEBOOT 0T-4800 1M-2400 IF ERRLEVEL 1 GOTO radio IF ERRLEVEL 1 GOTO radio IF ERRLEVEL 1 GOTO radio :LOOP :LOOP :LOOP ROSERVER -c ( or ROSERVER -M -C CONFIG.A) ROSERVER -c ( or ROSERVER -M -C CONFIG.A) ROSERVER -c ( or ROSERVER -M -C CONFIG.A) IF ERRORLEVEL 60 GOTO prog1 IF ERRORLEVEL 60 GOTO prog1 IF ERRORLEVEL 60 GOTO prog1 IF ERRORLEVEL 50 GOTO prog2 IF ERRORLEVEL 50 GOTO prog2 IF ERRORLEVEL 50 GOTO prog2 IF ERRORLEVEL 40 GOTO prog3 IF ERRORLEVEL 40 GOTO prog3 IF ERRORLEVEL 40 GOTO prog3 IF ERRORLEVEL 30 GOTO prog4 IF ERRORLEVEL 30 GOTO prog4 IF ERRORLEVEL 30 GOTO prog4 IF ERRORLEVEL 20 GOTO prog5 IF ERRORLEVEL 20 GOTO prog5 IF ERRORLEVEL 20 GOTO prog5 IF ERRORLEVEL 10 GOTO prog6 IF ERRORLEVEL 10 GOTO prog6 IF ERRORLEVEL 10 GOTO prog6 GOTO LOOP GOTO LOOP GOTO LOOP :prog1 :prog1 :prog1 SOM_PROG1 arg1 arg2 arg3 SOM_PROG1 arg1 arg2 arg3 SOM_PROG1 arg1 arg2 arg3 GOTO loop GOTO loop GOTO loop :prog2 :prog2 :prog2 SOM_PROG2 arg1 arg2 arg3 SOM_PROG2 arg1 arg2 arg3 SOM_PROG2 arg1 arg2 arg3 GOTO loop GOTO loop GOTO loop :prog3 :prog3 :prog3 SOM_PROG3 arg1 arg2 arg3 SOM_PROG3 arg1 arg2 arg3 SOM_PROG3 arg1 arg2 arg3 GOTO loop GOTO loop GOTO loop :prog4 :prog4 :prog4 SOM_PROG4 arg1 arg2 arg3 SOM_PROG4 arg1 arg2 arg3 SOM_PROG4 arg1 arg2 arg3 GOTO loop GOTO loop GOTO loop :prog5 :prog5 :prog5 DOORWAY ....... DOORWAY ....... DOORWAY ....... GOTO loop GOTO loop GOTO loop :prog6 :prog6 :prog6 SOM_PROG6 arg1 arg2 arg3 SOM_PROG6 arg1 arg2 arg3 SOM_PROG6 arg1 arg2 arg3 GOTO loop GOTO loop GOTO loop :end :end :end What happens is that when the ROSERVER program is exited the BAT file executes SOM_PROG and then loops back 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. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 6 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 >> Sysop enable/disable bell: Sysop enable/disable bell Sysop enable/disable bell "bell" (change_prms) "bell [ on | off ]" A CONFIG option, BELL ON/OFF dtermines whether or not the ctrl-G character will be sent to the CONSOLE. The same routine is used for CHAT, which determines if the SYSOP gets binged by a user who wants to talk to him, SERVMSG, which dtermines if a Service message is generated by a KT, and SHOWZIP, whic determnines if ZIP codes of T-messages will be displayed in the "Mail For:" banner. These other variables are queried and set/unset by typing their name and no arguement for query or name and ON/OFF to set/unset. >> Connect out to a station: Connect out to a station Connect out to a station "c" (lterm) "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. >> Untangle Message file: Untangle Message file Untangle Message file "compress" (untmsg) "compress [type strings]" This invokes a standalone program MAILWORK.EXE which com- MAILWORK.EXE MAILWORK.EXE presses the mail file. This takes the MAIL.DAT message header file and copies it over retaining only the active messages sec- tors and erasing the textfiles of the killed messages. The 'type strings' may be P, B, T, $, *. The first three are obvious, the '4' says remove only bulletin pointers, and the '*' says clean everything. This can be critical on systems which are major mail for- warders, 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 'compress' can be run from the event scheduler, or you can invoke MAILWORK directly with additional options. It will DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 7 exit gracefully if it detects a user on the opposite side in a multi- user configuration. >> Delete a file: Delete a file Delete a file "del" (delfiles) "erase" "del [path]\filename ... [path]\filename ... [path]\filename" "erase [path]\filename ... [path]\filename ... [path]\filename" Simple delete file(s). 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: Delete a user from user file Delete a user from user file "deluser" (eduser) "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. >> Distribution to multiple recipients of a single message Distribution to multiple recipients of a single message Distribution to multiple recipients of a single message "distrib" "distrib route_1 route_2 .... route_9" For starters there are two types of messages which are listed as 'B' and called bulletins, one is generally addressed ALL or some special interest 'group' (like AMSAT) at some BBS and is exactly that a message of interest, maybe, to ALL users at that BBS. Then there are messages addressed to ALL at some wide area group like ALLUSA, MDCBBS, MBLBBS, etc. These latter mes- sages are what is truly called a FLOOD bulletin and are handled by the FLOOD command. The Distribution files are 6 character file names with extension .DST, so the file below which is for PHOTOG would be named PHOTOG.DST . w2xxx w3yyy w4rrr w1aar@wb2mic rmail@kb1bd aa4re n2evw alldx@wb2qja *** EOF rmail@wb2mnf alldx@ka2bqe k2adj *** EOF B/alldx@w1aw DST files will be looked for in the SYS directory. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 8 Basically a message or series of messages are exported from ROSERVER via the export command. They will come out with TO, FROM, AT, and MSGID. The messages will be 'imported' into ROSEDIST where the SEND line will be parsed. The @BBS field will be used to make a file name by appending ".DST" to it. If ROSEDIST cannot find that file, the message is simply 'passed through' untouched, from the input file to the output file. Assuming now that we find the file, we will then take the message and read down to the "To:" line in the internal headers, or the end of headers if there is none. We will store all that material in a the first of two temporary files. WE then will read from that point to the line with "/EX" and store that in a second temporary file. The "To:" line, if it was present, is lost at this point. We read the DST file and take it in line by line. The DST file can have the following kinds of record entries: - BBSCALL this simply created as a message with TO filled in from the TO of the source message. - CALL@BBSCALL created with the CALL and BBS specified. - CALL@ - will place message in with this as the TO and no @BBS - RMAIL@BBSCALL makes an RMAIL message with next sequential ID from local system. Reads subsequent lines to a "*** EOF" to pick up target addressees; - BBSCALL - takes the TO of source message - CALL@BBSCALL - takes this explicitly - CALL@ - this call with no @BBS ** '$' used inside 'rmail' specs will be ignored) ** - $RMAIL@BBSCALL - identical to the the above, except the BID from the source message is added to the "To:" line (i.e.; To: rmail@bbscall$XXX_000, call@bbscall, ..... After everything is ready, the message type character from the orginal will be carried over. The follwoing exceptions are to be observed; all RMAILs will be 'P'. and any prefixed by a letter plus a '/' will get that letter as a type 9obsevre the last entry in the example has a "B/". A typical execution of DISTRIB might go like: DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 9 distrib ALLUSA MDCBBS MBLBBS RATS HARC The 'distrib' command does, in effect, an EXPORT, dirstrib processing, an import and an erase of the temporary work files. The DISTRIB command from the mailbox does a lot in one command line, and you do not have to remember options and erase file names, etc. >> Doorway to DOS Application Doorway to DOS Application Doorway to DOS Application "door" (doDoors) "door" This command engages an doorway manager called doorway.exe. It is used to bring up any dos application and redirect it all to the comport. This particular manager was designed for a PCBOARD (tm) system, but is sufficiently generic for our purposes. It monitors DCD (connect status), it can be 'broken' by sysop, and monitors timelimits. (I set it to 30 minutes in version 98Y, hard coded). The program writes a DOOR.SYS file, refer to DOORWAY docs for details about this file. The manner in which it works is to exit the MailBox with a DOS ERRORLEVEL of 100 which is tested and sent by a BATch GOTO to execute the Doorway driver whihc brings a DOS prompt to the Comm port the user is on. When he is done, he types the command "EXIT" returning command to the BATch file which then executes ROSEBOOT with a file RSTNCSET.DSC which contians three "D"s to force disconnect, and if modem ports have been configured, DTR will be raised/lowered , breaking the con- nection, then MBBIOS is Unloaded, then reloaded, restoring the Comm vector and the BBS loops back and comes up. Just about any program that does not write directly to screen RAM can be run. LOTUS, DBASE III Plus, will not run cor- rectly (i.e. some stuff will be show, other will not. Norton Editor (NED) will not. All DOS commands will run, Quiktrak will run. Compiled DBASE Applications will run. In future versions there will be a DOORWAY menu allowing non-remote sysop users access to selected programs. DOS access is to general users is asking for disaster. To that end the DOOR command is REMOTE SYSOP available only covered by the RSysy password AND it also has a privelege file called DOORWAY.RS which acts in excatly the same way as REMOTREQ.RS and RMAIL.RS (see GETxxx command explanations) DOORWAY DOCS DOORWAY DOCS DOORWAY DOCS _______ ____ _______ ____ _______ ____ The DOORWAY driver supplied will permit a sysop to have access to almost any DOS application or a DOS prompt. The program DOORWAY.EXE installs itself in memory and reassigns the standard DOS input and standard DOS output to the selected COMport. It monitors DCD (in this case Connect Status) and from DOS will re- boot the machine if it is lost (so remember to have your BBS come DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 10 back up via AUTOEXEC.BAT. The program use is self explanatory. Please read the DOOR- WAY.DOC from Marshall Dudley, its creator. ROSERVER produces the file DOOR.SYS in accordance with his specs and then 'shells' to the requested BAT file, which calls DOORWAY which in turn calls the application or brings you up in COMMAND.COM with your very own DOS prompt. This program is a SHAREWARE product. It comes in a 'locked' form which will display a lengthy banner and limit use to 10 minutes. If you call via phone or modem marshall Dudley's BBS and give him a MC or VISA credit card number and the name of your BBS he will enter that info into a hashing program and give you a key number to 'unlock' your copy. For now and the foreseeable future any revision to DOORWAY available from most RBBS systems, KA2BQE BBS, and any PCBOARD System can be unlocked by simply entering your BBS name and the hash number. Which now allows you to exer- cise a calling option which suppresses he opening advertisement and to allow up to 32768 minutes of user time! The fee for all this is $15, which is cheap at three time the price! If you do not want to do it - then be my guest not to use it. Just look at my BAT files included and see how to setup other doors. I am working on opening up parts of the doors to normal users and DOS and a few others to remote sysop. For now its limited to remote sysop. Firstrun.bat will setup a directory called DOOR and move the DOORWAY stuff there. Your user needs to run a full ANSI emulation to use doors. It helps even more if they take the DOORANSI.SYS and place it in place of their own ANSI.SYS this thing corrects a problem in line 25 scrolling present in most ANSI.SYS implementations. Generally, a 'busy' application, that is, one that does much with the screen is doomed to either failure or getting you lynched by the other people sharing your channel. You want appli- cations that generate simple terse prompts, and goes about its business and dumpr the desired output information hard and fast. Until we have at least 4800 baud user links we are stuck with this. >> Edit a user record: Edit a user record Edit a user record "eu" (eduser) "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. >> FLOOD distribution of bulletin messages: FLOOD distribution of bulletin messages FLOOD distribution of bulletin messages "flood" "flood # # #-# ... #" When a message comes in whose @BBS matches a designated DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 11 FLOOD route on the system, it is flooded as per its control file, xxxxxxxx.FLD in the FWD directory (xxxxxxxx being the flood rout- ing). If however the message came in and no flood route was present, but is subsequently created, the flood command will re- run through the file checking for un-flooded messages that have flood route files. The FLOOD control file is a simple list of BBSes call only. The generated pointer will be delivered only on direct connect to that station, it will never be delivered to that station via another. the flood command works like the read and kill command, you specify message or range of messages. >> Message forwarding: Message forwarding Message forwarding "fwd" (swap) "fwd portscr [-o] call file ... file" "poll" (swap) "poll portscr [-o][-txxx] destcall file ... file" "pollf" (swap) "pollf portscr [-o][-txxx] destcall file ... file" "push" (swap) "push portscr [-o][-txxx] destcall file ... file" "swap" (swap) "swap portscr [-o][-txxx] destcall file ... file" ** See the earlier discussion for the more conceptual explanation of the forward command. This will just discuss syntax and fine details. The 'fwd' command is simply that. It connects to a system in the manner specified and send him mail as appropriate. It will then disconnect. The 'poll' command does exactly that also. It connects to a system, and issue a request for mail and says goodbye. It would most often be used to an older system, or a Kantronics or Model 100 Mailbox forward with no need for reverse polling. The "pollf" command is a special case command that "polls for" mail for other systems. It connects to a system in the normal manner and sends a line that looks like this : command: pollf a2 n2evw wb2mnf wa2vxt k2adj pollf a2 n2evw wb2mnf wa2vxt k2adj pollf a2 n2evw wb2mnf wa2vxt k2adj sends out: f> wb2mnf wa2vxt k2adj f> wb2mnf wa2vxt k2adj f> wb2mnf wa2vxt k2adj The receiving system will do a reverse forward for your system, then cycle and do a reverse forward for wb2mnf, wa2vxt, and k2adj. In this way a system can collect mail destined for other systems, if one of those systems should go down without having to have the sysops make all sorts of file changes. Recognizing that some sysops may be concerned about abuse (which can be done easily), I have made this feature subject to the 'check for call' routine which governs, RMAIL, DOORWAY and REQxxx functions. Basically, if a file called POLLF.RS is present DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 12 it will be checked for the call of the Connectee. If the file is not present all POLLF's will be permitted, if the file is present and the Connectee call is found it will also permit it, if the the call is not found or a wildcard permission is set with one or two connectees calls 'excluded' then the reverse forward routine will simply revers forward for the connectee and terminate, ignoring the other calls in the polling string. The "poll" and "swap" commands are identical in all aspects except that "poll" will issue a connect even if there is no except except outbound mail. These commands generate a multiple round (up to two complete 'send'/'poll' cycles) to deplete each side of all possible mail to be exchanged. Allowing that return mail can be generated by any outflow of mail (i.e. remote REQ messages) The 'push' command is essentially a 'swap' that always connects regradless of outbound mail status. if nooutbound it immediately goes to 'poll'. This is needed when connecting to non-prmbs systems most of which DISConnect immediately after forwarding, so a poll command would never get to send its mail. The 'cutouts' in the repeated cycle are as follows; a. - any send phase with no outgoing messages terminates the cycle. The only way new mail might be gotten on a subsequent poll would be through a receipt on the other side of doubleDOS. A low probability coincidence. b. - any failure to receive mail after the first cycle terminates the cycle. If you received nothing its not likely there's any- thing new to send, subject to the same low probability coinci- dence of getting mail from the other side of your own DDOS. *** NOTE *** this may seem like a spectrum wasteful thing, re- sulting in real hogging of the channel. My contention is that after a few cycles of this the mail flow will settle down. The basic premise is the old 'make hay while the sun shines' - trans- lated as; when you have a path, clean the mailbox! Get it over with and get off the channel. The points on which all three commands coincide are the invocations which direct the level two/three connection to the targeted system. These are specified by and port and script designator ("portscr" in the syntax above), which consists of a port letter and a single character (usually a number between 1 and 9, or nothing at all which is synonymous with a '1'), as well as the call of the targeted BBS. These are used to index into file CALLDIR.RS, where it will look up the call and the script designator for that call (CALLDIR allows multiple scripts for the same station) and get the proper path and script sequence to make the connection. The remaining arguments 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 DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 13 stream could be fabricated without any '.FWD' files at all if the requirements of the station could be met in that fashion. SWAP B WB2RVX NTS* NORTH ?6* ?7* ??7* SWAP B WB2RVX NTS* NORTH ?6* ?7* ??7* SWAP B WB2RVX NTS* NORTH ?6* ?7* ??7* SWAP B WA2VXT KE2M SWAP B WA2VXT KE2M SWAP B WA2VXT KE2M and so on ..... When the 'F>' prompt is recieved by a PRMBS system, it effectively generates a command; FWD A -ttp KX1XXX FWD A -ttp KX1XXX FWD A -ttp KX1XXX If the recived prompt is a 'poll for', that is other calls are being polled for, the code simply generates repetitive executions of the above command, one for each call polled. Now in the past there was a reverse event file, but it was awkward and several modificatios to the code have made it unfeasible. The 'portscr' designation is the port letter (A,B,C ...) and the 'script number'. There is a file called CALLDIR.RS 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 +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 DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 14 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 Speaking of timeouts, once the script is completed with the connect to the final desired station, the timeout period reverts to the 'port-timout' period specified in the configuration. 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 away. One point, the FWD and SWAP commands, test to see if it is connected when it comes in, so if it is, the connect sequence is not issued. This permits you to connect to a station using the (TE)rminal or (C)onnect commands and then later doing whatever, decide to forward mail to that system. You no longer need to DISC and then let the FWD command re- establish the connection. >> Import/Export messages: Import/Export messages Import/Export messages "import" (import_msgs) "import infile" "export" (export) "export outfile ptr [ptr .... ptr]" "ptr" can be any call or pointer to an FWD file This allows a disk file to be used as the medium of ex- change, the concept was originally built by WA7MBL as a means to go back and forth to the TCP/IP smtp mail system. It was con- ceived independently on ROSERVER as a generalized mail transfer ROSERVER system. The MBL and ROSERVER formats are identical and inter- ROSERVER changeable. 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 a file to another system: Send a file to another system Send a file to another system "putfile" (put_file) "putfile filename call@address" This command allows the sysop or remote sysop to send a file to another user on another system. Without having to go through a complex synthesis of the required inbound REQFIL message to achieve the same thing. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 15 >> Send a file to a port: Send a file to a port Send a file to a port "port" (port_dump) "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. >> Set different baudrate to port: Set different baudrate to port Set different baudrate to port "setbaud" (ch_baud) "setbaud port baudrate" This comand was mostly implemented for modem use, but may be used for anything. Enter the command, port letter and a baudrate (300,600,1200,2400,4800,9600, 19200, 38400) and that baudrate will be set to that port. Upon returning the BBS back on-line, the system will re-set the port to the CONFIG file specified value. he command returns errors messages for 'invalid baudrate' or 'port not found' in either case it exits, doing nothing. If you try to set the console baudrate you get no error message, but likewise nothing happens! >> Translate a range of messages: Translate a range of messages Translate a range of messages "translate" "translate # # #-# ... #" used to re-translate messages, entire file, range, or just a few messages selected by AT or TO fields. This is so that a subsequent address change can be applied to a bunch of messages without the need for hand editing. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 16 :USER Commands - available to all users, LOCAL, REMOTE and REMOTE :USER Commands - available to all users, LOCAL, REMOTE and REMOTE :USER Commands - available to all users, LOCAL, REMOTE and REMOTE SYSOP SYSOP SYSOP >> Menu/Help Request: Menu/Help Request Menu/Help Request "?" (cmdlist) "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' "H" and "HELP" are the same, they give a long, detailed description of the command. The "?" gives a syntax display.. File called HELP.RS, set up with leading '#' as entry delimit- ers. Entry may handle wildcards (*,?) and will present whatever entries match the wildpattern. >> Go back on-line: Go back on-line Go back on-line "b" (logout) "bye" (logout) Log out user, updates his userfile record, then returns to mailbox xyxle which recognizes the change in port status and resumes its on-line-waiting posture. >> Remote user request to: Remote user request to Remote user request to "chat" (utalk) User makes request, if local chat flag is disabled he imme- diately 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 (ESC 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 ESC and 'coming out of terminal mode' strings are sent, TNC connect status checked and BBS is returned 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 look- ing for another command. >> List of commands: List of commands List of commands "cmds" (cmdlist) "cmds xxx" This simply goes through the command dispatch table and dumps the strings containing the commands available on the sys- tem, 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 DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 17 are a mere user you get the REMOTE list. The Sysop may, from LOCAL console type "cmds -u" or "cmds -s" to get the lists with the subset of his commands that the user is permitted or the remote sysop. Like the HELP commands this accepts wildcards and willdis- play all those entries which match. The list of commands is drawn from the programs actual command dispatch table and therefore is always accurate! >> Download a file: Download a file Download a file "d" (dnload) "d filename ###" "d filename -###" "d filename ###-###" "db filename ###" "db filename -###" "db filename ###-###" "dx filename" "dy filename" "dz 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. The DB command is the same as the DB but it will do an on-the-fly conversion of abinary file into B2A compatible format and may be subject to the cut and skip commands of the D. Downloads on the air are also subject to a sysop configura- ble 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. If the PRMBS is configured with a modem port, the commands DX, DY, DZ may be used from the modem port to download using Xmodem, Ymodem Batch, or Zmodem protocol. This is done by sub- running DSZ.COM an external protocol driver written by Chuck Forsberg (a ham) and in common use by many landline BBSes. This driver is something of a RAM-piggy, so in this current version (0.99) it will be necessary to be running ROSERVER in a 300K plus window to have protocoled downloads workable! DSZ will be deliv- ered as an unregistered delvery module and maybe registered for a one time only fee of $20.00 (legitimate full time BBSes may get a DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 18 freebe, contact Omen Technology concerning this), which shorten the on screen garbage and activates some extra features. >> Directory Request: Directory Request Directory Request "dir" (mbDir) "dir [path]\[file-spec]" Simple listing in directory order of the files in the "FILES" area or some sub-directory. If the user types forward slashes '/' instead of the backslashes '\' required by MSDOS, they are translated to back slashes. >> Get file descriptions: Get file descriptions Get file descriptions "fileinfo" (fil_info) "fileinfo" "fileinfo pathname" When a user uploads a file to the system it places the file into a directory and a message is sent to the sysop with a one line file description, this description is also appended to a file called FILEDIR.TXT in the directory it was uploaded. Also included is a program called RSMAKDIR.EXE to be run by MAKEDIR.BAT. This will take the directory you are in, get FILE- DIR.TXT, sort it by filename, and then do a directory list and prompt you for descriptions for any file without a description. This command with no arguments dumps the file FILEDIR.TXT to the user, from the FILES directory. If a path is specified, it goes to that directory and does it. >> Remote file request commands: Remote file request commands Remote file request commands "getbbs" (make_req) "getbbs call host" "getdig" (make_req) "getdig call host" "getdir" (make_req) "getdir dir host" "getfile" (make_req) "getfile file host" "getmsg" (make_req) "getmsg ### host" "getqth" (make_req) "getqth call,call,....,call host" "getusr" (make_req) "getusr call host" "getver" (make_req) DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 19 "getver host" "finger call 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 SP REQFIL @ WB2MNF SP REQFIL @ WB2MNF FOOBAR\SNAFU\ORGSNATZ.DOC @ WA2VXT FOOBAR\SNAFU\ORGSNATZ.DOC @ WA2VXT FOOBAR\SNAFU\ORGSNATZ.DOC @ WA2VXT /EX /EX /EX You would instead simply type; GETFILE FOOBAR\SNAFU\ORGSNATZ.DOC WB2MNF GETFILE FOOBAR\SNAFU\ORGSNATZ.DOC WB2MNF GETFILE FOOBAR\SNAFU\ORGSNATZ.DOC WB2MNF Assuming from the first example that you were on WA2VXT at the time, that info would added automatically. 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. The REQQTH is an outbound service for the Online Buckmaster CD-ROM of the Amateur Radio Callbook currently being provided by the WA4ONG BBS. I did not default the remote host call, as other system might spring up in the near future offering similar serv- ices. K4NGC has a database of BBSes and DIGis/nodes which is accessible via REQBBS/REQDIG. "finger" and "getusr' are synonymous and are supported by all PRMBS v1.10. 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.RS, and it must be in the default directory) then the originator of the message must meet a wildcard match criterion. Here are some examples; DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 20 file REMOTREQ.RS 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 drop through them and match the '*' The same mechanism is used to 'control' RMAIL access. See the entry for RMAIL. Any REQxxx message coming into a PRMBS v1.10 or later BBS will get a return message indicating function not supported if that is the case. In prior times such messages would just sit til noticed by the sysop. >> Monitor list and connect log: Monitor list and connect log Monitor list and connect log "heard" (prthrd) "heard all" "heard x" The familiar 'J'-list command from RLI/MBL systems, it lists the most recently heard systems and most recently connected stations. The simple invocation gives a list of configured ports. The "all" arguement lists all ports, one at a time. The "x" where 'x' is a port letter lsist that port only. >> Query/Enter User's Home BBS: Query/Enter User's Home BBS Query/Enter User's Home BBS "home" (home) "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 ROSERVER makes use of the home ROSERVER bbs field. (i.e. if 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) DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 21 >> Sysop's "Brag File": Sysop's "Brag File" Sysop's "Brag File" "info" (show_info) Simple call to file download, dumping the file INFO.RS, which contains info about ROSERVER and the sysops own station ROSERVER configuration, and may also, actually should also contain a brief statement of the policies concerning the operations of that station. >> Kill messages: Kill messages Kill messages "k" (multi_msg) "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: Kill my messages Kill my messages "km" (klmsgm) "km -x" Kills all 'read' (status = 'Y') messages addressed to the user. As with any 'range of messages' kill, the headers are presented and 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 danger- ous 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. >> Kill traffic: Kill traffic Kill traffic "kt" (kill_trfc) "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. >> List messages: List messages List messages "l" (lstmsg) "lx [-bhklmspx] [optional string] [optional range]" DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 22 The 'E'dit, 'List', and 'K'ill commands all take the same secondary modifiers (optional 'x' field in 'lx' sample above) > messages TO < messages FROM @ messages AT l last (reverse order) r messages by route t traffic messages m my messages Examples L> KA1NNN 2345-2000 will list messages to KA1NNN, in reverse order from the range 2345 back to 2000. E< WA3QQQ -s HAMFEST 1200-3400 will present for editing, messages from WA3QQQ containing 'hamfest' in the title starting at 1200 up to 3400 K -zxb 30 -s SAREX back will kill with no query any bulletin, over 30 days old with 'SAREX' in the title, starting from newest messages working back to oldest. ER MIDLAN all will present for editing all messages routed to WA2SPL starting from oldest forward to newest All of the above commands will take an "optional range" which may consist of a starting number or a range of numbers, or the special words "all", for which means start at lowest and goto highest, or "back" which is start at highest and work back to oldest. ( 'al' and 'ba' are sufficient, full words recognized, but not needed) Notice the <>@R suboptions take their areguements immedi- ately after the command, then the sub-options come, then the number range. +---+----------- expired 30 days | | L< KA2BQE -xbs 30 RATS 1 || | | || | +--- start at message #1 |+----+-------- search for string "RATS" in title +-------------- bulletins only The parsing of the line is now more sophisticated and flexible. thefull list of sub-options is; DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 23 options action ------------------------------------------- -l long list option -m mail list option -h held message only -d non flood messages rejected as dupes only -r non flood messages rejected for some other reason -k killed messages only -b bulletin messages only -t traffic messages only (the above two may seem redundant in view of the LT LB commands - but these allow signifi- cant refinement of other commands) -s xxxxx search title for string xxxxx.(string may be in quotes so white space can be included "RATS Meeting") search is conducted case insensitive. -f xxxxx allows specifying a file name for the ARCHIVE/FILE command (defaults to PRMBS.EXP if '-f' not used - this option will be ac- cepted by the other commands but will be ignored as it has no meaning to them.) -x ## expired option, looks formessges that are ## days old or older >> Set Language: Set Language Set Language language (mk_string) language x language "" This command allows the user to set up for an alternate MESSAGES file which may be in another language. 'x' is a single letter which will designate the file. Inovocation of the language command will display a list of the available files and the single letter designator for the file. To clear the field you invoke the command followed by empty quotes. This field in the user profile may be edited in edit_user as well. >> List users: List users List users "lu" (duser) "lu" "lu call" "finger call" This will list one or all users of the system. It displays call, name, home bbs, date/time last logged, number of times on. For remote or local sysops, the bit masks are decoded into let- ters showing privileges, exclusions, etc. For local console with sysop privileges, passwords are also shown. They are never dis- played over the air. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 24 For remote sysops and local console use, the "lu" command fo a whole list supports a single letter modifier to list the fol- lowing; 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 When there is more than one letter in the argument, it is as- sumed to be a call and the list is scanned for that call. "lu call" and "finger call" are the same command. IF the user has a 'finger' file on the system (WX1XXX.FNG) it will be displayed along with the log information. The user signature file (WX1XXX.SGN) is appended also. This same info that is displayed to the user is also the information appended to a response to a REQUSR for that user. >> User Mail Service: User Mail Service User Mail Service "mail" (mail) "mail" "mail -n" "mail addr [addr .. addr]" addr = call or call@bbs This is a 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 himself all messages with "SYSOP" in the TO field. It then presents a limited sweeper that allows the simple REMOTE user to Kill, Reply To, Read/View, and Unread(set status back to N) 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 no spaces no spaces in if the person is a 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 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 DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 25 commands available to the user they are the "~" (tilde) escapes and are as follows: ~ccall@bbs - the 'copy to' command. During message entry you may add additional recipients, full translate and h-route info is applied to this entry as well. This will work in MAIL, RMAIL, Send and Reply message. ~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 redisplay 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. ~s - will append a file from the FWD directory titled user_call.SGN, a signiture file to the message. At the moment this file must be placed their by hand by the sysop, but it will, 'big system mailer' style, allow a user to have a tsored 'signiture' tha does not have to be transmitted every time. ~? - gives a menu of the commands ~! ~!xxxxxx - these allow executioj of DOS commands or simple drop to DOS. This command valid from machine console only. 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 sup- posed 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 ROSERVER system. It would only be a prob- ROSERVER lem if the user of the PK-64 were a remote sysop, then he would be hampered, but otherwise the PK-64A won't lose anything, he just won't gain any new powers. >> Remote user mail service: Remote user mail service Remote user mail service "rmail" (mail) "rmail @bbs addr ..... addr" "rmail @bbs$bid addr ..... addr" DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 26 This feature allows a user to snd a message to several recipients with only a single copy of the message traveling along the 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 (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 This message will travel through all system 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 diver- gence on their respective paths. The 'type' of the generated message will be the same as the 'type' of the initial RMAIL message. The RMAIL message, like a 'mail' message defaults to 'P'. Use of the '~Tx' in the m text upload can change the type to whatever is desired. The use of this feature may be controlled by the sysops who are the recipients of the messages to be exploded. They may have a file called RMAIL.RS and it functions in the same manner as the RMAIL.RS RMAIL.RS control file for the REQ commands. (See the explanations under GETDIR etc.) the second example show shows a BID appended to the call of the target system. In this fashion we can send a message to a far away PRMBS system as a private message with no wowrry of getting BID-rejected along the way and then have it assume a flodd mes- sage BID at the far end. >> Enter the user name: Enter the user name Enter the user name "name" (mkname) "name firstname" name "firstname lastname" The is permitted to query the system as to what it thinks DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 27 his/her name is and to enter that name into the system. You may enter up to 20 characters in mixed case (upper/lower" with punc- tuation if it is enclosed in quotes. Anything over 20 characters is truncated. >> Read message(s): Read message(s) Read message(s) "r" (multi_msg) "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 mes- sage 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 contain- ing an "R:" at the beginning and an '@' sign prefixing its @BBS. >> View/Set user password: View/Set user password View/Set user password "password" (mkstring) "password" "password xxxxxx" If a password exists for the user and he is logged in on any port BUT a TNC port he may view or change his password. It will be converted to CAPs and chopped at 12 characters. >> Read new bulletins: Read new bulletins Read new bulletins "readnews" (readnews) "rn" "readnews subj1 subj2 ...... subj9" "readnews -s xxxxx subj1 subj2 ...... subj9" "readnews -#1200 subj1 subj2 ...... subj9" This will allow the user to read bulletins in the same fashion as he uses the 'MAIL' subsystem. It will allow him to specify bulletins by the TO address field. It will then list all bulle- tins that have that TO field match (wildcards permitted) SUBJ1 and the present them one by one for read and/or reply. After all bulletins matching that have been processed or the user 'Q'uits out that cycle, it will process SUBJ2 in the same fashion and so on till all topics requested have been processed. The process will begin with the user's 'high message read', unless the user uses the '-#' option to specify an alternate start number. The process basically depend on the orginators of the bulletins using the TO field for meaningful topic names like 4SALE, HELP, HEATH, ATARI, AMSAT, etc. >> Reply to a message: Reply to a message Reply to a message DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 28 "reply" (snd_reply) "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 User Files: Set User Files Set User Files "set finger" "set signiture" "set translate" The user files for each of the above features may be upload- ed with the same conventions as the upload command. The names will be composed by the system as the users call plus an exten- sion of FNG, SGN, or XLT for the appropriate files. Pre-existing files will simply be overwritten. >> Set users highest message read: Set users highest message read Set users highest message read "setmsg" (setmsg) "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 discon- nects. 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' >> Upload a file to the system: Upload a file to the system Upload a file to the system "u" (upload) "u filename" "ux filename" "uxc filename" "uy filename" "uz 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 DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 29 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. The commands with second- ary options x,xc,y,z are for landline modem to download under error checking protocol with DSZ. x = XMODEM, xc = XMODEM(CRC), y = YMODEM-G , z = ZMODEM. >> What version of the software is this: What version of the software is this What version of the software is this "ver" (d_vers) The displays the version level of the ROSERVER software. ROSERVER >> Toggle remote sysop mode: Toggle remote sysop mode Toggle remote sysop mode "@" (mksys) "@" (mkrem) This command toggles the system state between REMOTE and SYSOP (implied remote sysop, as opposed to LOCAL which is the sysop as a 'super-user'. If a file called PASSWORD.RS 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 REMOTE and SYSOP 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 SYSOP he sees EVERYTHING. He may kill anything and he has some new commands open. All commands that were valid from REMOTE are valid in SYSOP, plus he now may delete files make files out of messages, and others. If the PASSWORD file was found. 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. IN a modem or serial port login, the PASSWORD string is not used. The setting of a remote sysop bit is sufficient along with accessing the conventional password set in his user record. DRAFT of Docs for ROSERVER/PRMBS (KA2BQE) - ver 1.50 03/01/91 pg 30