HAM Radio 1

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

/ HAM Radio 1 / HamRadio.cdr / packet / mbl514 / notes < prev next >

Wrap

Text File | 1988-08-07 | 22.9 KB | 633 lines

So far no detailed documentation is available for MBL512. What exists are a series of change notes from WA7MBL to W3IWI. These are not intended for the novice or faint at heart! In testing 5.12 we went thru several intermediate releases, so in some cases a change may be rescinded by a later change. This file is an edited version of all change notes combined. If a feature doesn't work as described herein, it may be an old change that survived the editing. This material, plus the NOTES.IWI file provided by Tom Clark is all the written information that exists at this time. Anyway, here goes: ============== There is a new driver to load (JLIST.COM) along with BTRIEVE, DVTIMER, and one of the COMBIOS/DVBIOS series of I/O drivers. Failure to load JLIST may cause the BBS to hang. See the file NOTES.IWI for some setup suggestions. NOTES.IWI also contains a sample configuration file. ------------------ Converting from version 3.31 or 4.31 There are a number of programs included for converting user and mail files from version 331/431. CVTMAIL creates MAILFILE.BTR from BBSMAIL.BTR. It reads the existing message text, and will prompt for the pathname of your present mail directory (\BBS\MAIL\ or whatever). Be sure to add the trailing backslash! CVTUSER creates USERFILE.BTR from BBSUSER.BTR. CVTBULL creates BULLSTNS.BTR from BBSBULL.BTR. MKBFWD creates a blank BULLFWDS.BTR file. ---------------------- If you are starting from scratch (lots of luck!) MKMAIL creates a blank MAILFILE.BTR file. MKUSER creates a blank USERFILE.BTR file. MKBULL creates a blank BULLSTNS.BTR file. MKBFWD creates a blank BULLFWDS.BTR file. ---------------------- BULLSTNS.BTR contains a list of BBS callsigns and their assigned BBS #. BULLFWDS.BTR contains the list of @BBS forwarding designator mnemonics (such as ALLBBS, MBLBBS, NET, ARRL, etc) and the #s of the BBSs which will receive that group. There is a program called CKFWD, which will add information to the BULLFWDS file. It will ask for the name of a Forwarding File. It will read the file looking at BBS callsigns and checking to see if they have a BBS # assigned. If so, it will look for any $ARRL type lines and create or update the record for that forwarding designator to add the indicated BBS. You can run this on a number of forwarding files if desired. The BBS command 'DF' (Display Forwarding lists) will show you which BBSs are on which lists. The DF command has been enhanced so 'DF ARRL' will show which stations are on the $ARRL list. An EF command has been added so 'EF ARRL' can be used to add/delete an entire list, or to edit individual BBS stations. The syntax is sorta kludgey, but it works as follows Local> ef arrl EDIT: Y to delete <cr> to retain: Keep W1XYZ : Keep W3IWI : Add WA7MXZ : Keep W1AW : You will be shown ALL BBS callsigns that have been assigned BBS numbers in your BULLSTNS (as shown by the D$ command). If they are already on the list, the prompt will be "Keep W1XXX" and if not on the list will be "Add W1XXX". To add one, type a Y. To delete one that is already on the list type N. A <cr> will maintain the status quo. You can then do a "df arrl" to be sure everything worked ok. NOTE: Editing this list does NOT change the status of a bulletin (fully forwarded). If a bulletin has been flagged as fully forwarded it will NOT go to an added station. If a bulletin has not been flagged, it will go. If a bulletin came in to a new list which didn't exist, it will have been flagged as not-forwarding (no where to go), but will not be flagged as fully forwarded (cuz you didn't forward it anywhere). If you do want a non-expired bulletin to go to a new BBS (or a new list in the case where you didn't have a list set up), if you EDIT the message using the E nnnnn command and CHANGE the @BBS info (simply type in the same @BBS info), it will then check the BULLFWDS file and if there are stations that have not received the bulletin it will set the internal flags for the bulletin to attempt to forward again (and reset the fully forwarded flag if necessary). The syntax of the forwarding file has been changed. A single '$' will indicate to forward all bulletin groups that go to the particular BBS as assigned in BULLFWDS.BTR. You can remove all of the $THIS, $THAT lines. The JA, JB, etc command may be followed by an optional number of how many calls to list (ie JA 5, etc). Control-C can be used to abort entry of a message locally. It can also be used to abort reading a message, etc. The help command is now driven by one HELP file. I haven't had time to create a decent help file. You can probably figure out the syntax by looking at the sample one I threw together quickly. There are a few new Lx commands. LU is list Unread, LK is list Killed (but not yet deleted). You will find that L@ call, L< call, and L> call will go from oldest to newest. This is because of the way they are indexed. No LOCAL window yet. Configuration file has been changed. You should be able to figure it out. First line is No of TNCs. If you use more than one you need to repeat the next 4 lines for each..... 1 (No of TNCs in use) ABLG <- First char is Port (A-F) Next chars are B=BBS only L=Local G=Guest B means BBS only. L means BBS plus LOCAL only (BBSs are always allowed). G may be added to either B or L to add guest access. Do not use both B and L. 1 4800 14 <- Port#, baudrate, video attribute 145.01 Mhz <- Port info LstMsg# $L Mail: $Q <- Mail beacon if any ------ <- end of beacon text (used instead of ***EOF) [Logan, Utah] ... etc --------------------------------- Message Types There are only 3 messages types. Type B (Bulletins), Type P (Private), and Type T (Traffic). If you enter a message using only S or S followed by a letter other than B, P, or T, the message will default as follows: If the TO address appears to be a valid callsign (at least 4 characters, 1 or 2 numeric characters, doesn't end in a numeric), the message will become SP. If it does not appear to be a callsign, it will become SB. S ALL - same as SB ALL (No numerics, only 3 characters) S W1AW - same as SP W1AW (Valid call) S PK232 - same as SB PK232 (Ends in numeric) S TNC2A - same as SP TNC2A (Looks like a valid call) --------------------------------- $BIDs Some folks seem determined to try to use the $BID feature as an MID (Message ID). This does not follow the intended usage. The $BID is intended to indicate 'flood' or distribution list type forwarding. A BID is *NOT* assigned to all bulletins. If you wish to send a bulletin to all users at only one particular BBS, you should not use a BID: SB ALL @ W3IWI The only case a BID should be assigned to a Private message is for the special case of private mail addressed to SYSOP. To distribute a message to a group of SYSOPs, the proper method is: SP SYSOP @ MBLBBS $ [Note: Please use 'SYSOP' and not 'SYSOPS' !!] A message with a $BID acts like the old 'SF' type forwarding and a copy of the message will be retained subject to the expiration date feature mentioned below. A bulletin without a BID with an @BBS, will be forwarded in the same manner as normal mail and deleted after forwarding (subject to the parms in the CONFIG file). This release has been modified to ignore a BID on Private mail addressed to other than 'SYSOP' and to ignore a BID on Traffic. I hope to get the MID issue settled and implemented in the near future. --------------------------------- Bulletins & 'Killed' Mail There are a number of ways to prevent old bulletins from being resurrected and flooding the system again. First, if a bulletin has been forwarded to all of the systems that you forward to it will be marked as Fully Forwarded (you will see a Status of 'F'), and it will no longer be forwarded even if you add a new BBS to the list. Second, a bulletin has an expiration date. This is set in the configuration file as (nn) days from the date the bulletin is received. After the expiration date, the bulletin will be marked as expired (Status 'X'), and will also no longer be forwarded. To give you flexibility in how long a bulletin will be available for users to see, you can set an additional number of days between the date the bulletin expires and the date that it is "killed." Finally, mail that is "killed" actually remains on the system for an additional number of days before it is physically deleted and optionally saved to an oldmail file. "Killed" mail may be listed with the "LK" command. This extra period helps retain the BID for an extra period so if someone happens to be late in forwarding the bulletin to you, your system will still be able to reject it as a dupe. Code I am currently testing will extend this feature into using a Message ID for ALL mail. I've noticed that mail coming through a long NET/ROM path tends to be duplicated because the sender times out while the message is still in the network. The ability to save messages for a few days before actually deleting them will allow mail that you forward to stick around long enough for dupe checking. For example if your config file was set as follows: 4 (No of days before actual delete/save of 'killed' mail) 7 (Default no of days for bulletin expiration date) 14 (No of days before expired bulletins are 'killed') The bulletin would expire 7 days after receipt. Your system would attempt to forward it for a maximum of 7 days or until all BBSs your forward it to had received it. Users would still be able to read the bulletin for an additional 14 days. It would then be 'killed'. The 'killed' bulletin would be deleted 4 days later, and would be optionally saved into the OLD BULLETIN save file if desired. SAVEBULL.OLD (killed bulletins save file) SAVETFC.OLD (killed traffic) SAVEFWD.OLD (killed fwded mail) SAVELOC.OLD (killed other mail - local originated or local destination) The K! command does the daily housekeeping. (Checking for expired bulletins, deleting, saving, etc.) It can be entered as a local command, or can be placed in the forwarding file as: -------- K! 23 <- the hour to do it -------- If you are running multiple ports sharing one set of data file, be sure to run K! from ONE forwarding file ONLY! ------------------------------------------------------------------------ The new log format: All log lines begin with the Month and Day (no Year), followed by the time (including seconds). MMDDHHMMSS........ Text-To-Mail (T) 0401165034MT 34490B T:ALL@MBBS F:WA7MXZ@W1AW <12345> S:SUBJECT Received (S) 0401165034MS 34491P T:W3IWI@W3IWI F:WA7MXZ@WA7MXZ <34491> S:TESTING Reverse Forwarded (<) 0401165034M< 34492P T:SYSOP@NET F:W1XX@W1AW <2345> V:W0RLI S:TEST Forwarded (F= normal forward $= BID forward) 0401192648MF 34488P V:WB7TRX <12345> 0401192648M$ 34489B V:WB7TRX <12346> Forwarded to File (F= normal forward $= BID forward) (X: instead of V:) 0401192648MF 34488P X:WB7TRX 0401192648M$ 34489B X:WB7TRX Some actual examples: ------ LOG.A ------ 0413144602SI *** BBS Initialize [Bob connects and forwards some NUThole traffic] 0413145618CA WA7MXZ-3 0413145720MS 34638B T:ALL@ARRL F:WB8SCG@WB0TAX <8107> S:ARRL PROPOGATION FORCAST NR 15 0413145752MS 34639B T:ALL@ARRL F:WB8SCG@WB0TAX <8109> S:ARRL SATELLITE BULLETIN NR 102 0413145830MS 34640B T:ALL@ARRL F:KG3M@W3IWI <32508> S:ARRL BULLETIN #35 0413145904MS 34641B T:SYSOP@MBLBBS F:NA2B@W4MWP <4094> S:22:33LFA HELP 0413145934MS 34642B T:ALL@ARRL F:WB8SCG@WB0TAX <8166> S:ARRL SATELLITE BULLETIN NR 103 0413150004MS 34643B T:ALL@NET F:VE3GYQ@VE3GYQ <6768> S:RE CHARTER 0413150034MS 34644B T:ALL@NET F:VE3GYQ@VE3GYQ <6767> S:ATTENTION TO DETAILS 0413150042XD [I forward some of the above to TRX] 0413152852M$ 34638B V:WB7TRX <5601> 0413153008M$ 34639B V:WB7TRX <5602> 0413153156M$ 34640B V:WB7TRX <5603> 0413153342M$ 34641B V:WB7TRX <5604> 0413153458M$ 34642B V:WB7TRX <5605> ------ LOG.B ------ [A message I entered locally] 0413152128MS 34646P T:WA7MXZ F:WA7MBL@WA7MBL <34646> S:5.02 BUG FIXES [RLI connects and forwards traffic] 0413162134CB W0RLI 0413162326MS 34648B T:ALL@NET F:N6MXG@N6YN <667> S:ATTENTION ATARI USERS... 0413162450MS 34649B T:ALL@NET F:N6MXG@N6YN <950> S:SPLIT SCREEN TERM. PROG. FOR ATARI 0413162538MS 34650B T:ALL@NET F:WA6BRI@N6YN <993> S:HELP 0413162742MS 34652B T:ALL@NET F:KF5TL@KD5LF <1929> S:LOGGING PGM. 0413162840XD The letter following the message number is message type (B,P,T) The message number in <brackets> is either the message number at the originating BBS (assuming 'standard' message headers are in use) on messages received or the message number assigned by the BBS the message was forwarded to (assuming MBL BID type forwarding: OK 12345 is being used by the receiving BBS) on forwarded messages. ------------------------------------------------------------------------ I have added forwarding type "R" which is Reverse Forwarding info only, with no forwarding attempt made. R W3IWI 00-23 W3IWI W1AW $ ------------------------------------------------------------------------ Mail addressed to 'SYSOPS' will be changed to 'SYSOP'. ------------------------------------------------------------------------ LX (list expired) command has been added. ------------------------------------------------------------------------ LM, LN, L<, L>, and L@ may have a range of message numbers (LM nnnn nnnn). This group of commands will still list messages from oldest to newest (due to the way they are indexed). ------------------------------------------------------------------------ A message that is killed can be edited back to life. However, you cannot edit a message to Killed status. Editing the status of a hidden message will un-hide it. ----------------------------------------------------------------------- DP command does paged download (local). Mail beacon is now sent in Converse rather than Transparent mode. ------------------------------------------------------------------------ It is now ok to use "24" as a forwarding time for any size mail. This entry will be ignored. The forwarding file may look something like: GA WA7MXZ 00-23<5 <-- fwd < 5K 24 <-- nothing over 5K will forward at any time @ WA7MXZ-2 .... ------------------------------------------------------------------------ Additional commands may be sent to individual TNCs upon BBS startup or shutdown by placing the commands into text files. If the files are found they will be sent to the TNC in command mode. In the case of startup, the commands in the file will be sent before the commands loaded from the configuration file. INIT.A will be sent to TNC A upon startup FINI.A will be sent to TNC A upon shutdown These filenames are hardcoded. ------------------------------------------------------------------------ The F command (Make File from Message) has been removed. There are now 3 flavors of the M command to replace it. M <msgno> <filename> saves the message same format as the R command MV <msgno> <filename> uses a verbose format to include all headers MT <msgno> <filename> is Text only (except for Date and From info) I find MT useful for moving ARRL & AMSAT bulletins into the file area without having all of the 'garbage' included. If the filename specified exists, you will be asked if you wish to Append. If you answer no, the operation will be aborted. (If you wish to overwrite, you must first Zap the old file with the Z command.) Examples follow: ---- this is M format ---- [35004] BF BID: ARRL.046 Path: WA7MXZ!W3IWI!WA4ONG!WB0TAX Date: 18 May 88 18:41:16 Z From: WB8SCG@WB0TAX To: ALL@ARRL Subject: ARRL BULLETIN NR 46 HR ARRL BULLETIN NR 46 FROM ARRL HEADQUARTERS NEWINGTON CT MAY 13, 1988 TO ALL RADIO AMATEURS BT PREREGISTERED CLUBS IN WISCONSIN WILL BE SIGNING THE SPECIAL 200 BICENTENNIAL PREFIX FROM 0001 UTC MAY 14 THROUGH 2359 UTC MAY 20. ... AR ---- this is MV format ---- Msg# TS Size TO @ BBS From Date Subject 35004 BF$ 726 ALL @ARRL WB8SCG 18-May ARRL BULLETIN NR 46 Bulletin ID: ARRL.046 R:880518/1841z 35004@WA7MXZ [Logan, Utah] R:880516/1914z 36216@W3IWI [Balto/Wash] R:880516/1648z 11611@WA4ONG [Richmond, VA] F:145.01 N:RIC,BRDN R:880516/1145r 9705@WB0TAX Tidewater BBS [Hampton, Va. 23666] HR ARRL BULLETIN NR 46 FROM ARRL HEADQUARTERS NEWINGTON CT MAY 13, 1988 TO ALL RADIO AMATEURS BT ... ---- this is MT format ---- Date: 18 May 88 18:41:16 Z From: WB8SCG@WB0TAX HR ARRL BULLETIN NR 46 FROM ARRL HEADQUARTERS NEWINGTON CT MAY 13, 1988 TO ALL RADIO AMATEURS BT ... ------------------------------------------------------------------------ I have made major changes to the operation of the SERVER and REQ??? type stuff. The server processors are now EXTERNAL to the BBS code. This saves some space for folks not wanting to offer REQFIL & REQDIR. It also allows more flexibility to write any type of server code. Changes have been made to the configuration file. The 'SERVER' file line has been removed. A set of Server lines has been added. The programs REQFIL.EXE and SORRY.EXE have been included. Details at the end of this file. ------------------------------------------------------------------------ If a user enters ^Z in the Subject line when entering a message, it will abort message entry. ------------------------------------------------------------------------ The line count for 'PRESS RETURN' should work properly when doing L lists. (however, it still has a problem with reading messages or files which have long lines that wrap around.) ---------------------- DETAILS of the new and improved SERVER feature........ A sample portion of the configuration file: TEST.COM (OS Program) FWD.A (forwarding file) FWD.A (reverse forwarding file) TEXTMAIL.ERR (file to catch Text-to-Mail errors) LOG.A (file for logging) MAILFILE.BTR (mail header file) USERFILE.BTR (user data file) BULLSTNS.BTR (bull data file) BULLFWDS.BTR (bull fwding file) SWAP.BBS (@BBS swap file) INFO.HLP (info file - I command) HELP.HLP (help file - H command) GHELP.HLP (guest help file - H command) \BBS\FILES\ (path/drive for upload/download files - if path, must exist!) \BBS\YFILES\ (path for YAPP files ) \BBS\MAIL\ (path for mail ) SAVEBULL.OLD SAVETFC.OLD SAVEFWD.OLD SAVELOC.OLD ------ Beginning of Servers REQFIL {To address} REQFIL.IN {File to forward message to} REQFIL.OUT {File to grab reply from} REQFIL.EXE {Program to run (parameters on next line)} W3IWI \BBS\FILES\ REQDIR {To address} SORRY.IN {File to forward message to} SORRY.OUT {File to grab reply from} SORRY.EXE {Program to run (parameters on next line)} W3IWI REQDIR REQJNK {To address} REQJNK.IN {File to forward message to} NULL {File to grab reply from} NULL {Program to run (parameters on next line)} NULL COPY {To address} COPY.IN {File to forward message to} COPY.IN {File to grab reply from} NULL {Program to run (parameters on next line)} NULL ------ End of Servers 3 (Days before actual delete of 'killed') 5 (# days for bull exp date) The old "SERVER" type of export is now removed. All export is done using the standard "import/export" type file. A section of the config file can have any number of servers (within reason). Each server has 5 lines associated with it. The first line is the "To address" of the server. The next line is the file that mail addressed to the server will IMMEDIATELY be forwarded to. The next 3 lines are the reply file from the server, the name of the server program to run, and the command line to pass to the server. If the reply file is NULL, it will be ignored. Also, if the Program name is NULL, no program will run. If you are writing your own server that takes more than a few seconds, you may wish to simply use the server for a quick export, and then do the 'real' processing from a DOS call in your forwarding file. So far I have written the REQFIL server and a SORRY server. REQFIL reads REQFIL.IN, processes the request, and creates REQFIL.OUT. SORRY reads SORRY.IN and creates SORRY.OUT. The sample config file above implements four 'servers'..... The first server is REQFIL. The parameter line is the callsign of the BBS (for creating the FROM address) and the path of the \bbs\files\. The second server is SORRY. It is used to give a "SORRY - I dont support the x feature" reply. The parameter line is the callsign of the BBS (for creating the FROM address) and the feature name. The example shows how to give the SORRY reponse to the REQDIR feature. If you don't wish to support REQFIL, you may want to use the SORRY server for it also. The third example demonstrates how to cause immediate forwarding of messages addressed to REQJNK to REQJNK.IN. Because the following lines are NULL, no program is run, and no reply file is processed. The final 'server' is a bit of insanity. It forwards a copy of a messages addressed to 'COPY' to the COPY.IN file. The program line is NULL, so no program is run. It then again uses COPY.IN as the reply file and sucks back the message that it originally forwarded out still addressed to COPY. The net result is that it adds a forwarding header line and wastes a message number. Although it is addressed to COPY, a message coming back from server processing will not trigger additional processing. However, if you use server to forward it out, and use the forwarding file to NUThole it back in, it should continue to be processed over and over again. ------------------------------------------------------------------------ 'User' portion of forwarding append header (QTH and other junk) expanded from 40 to 50 characters so sysops can add more junk. (Just what we need?) ------------------------------------------------------------------------ ^C abort should now work on 'DU' series of commands. ------------------------------------------------------------------------ "L<" and "L>" lists will now include Killed messages (sysop only).