The N2gte packet Message Switch (gtepms) 2 Documentation. Legal stuff: gtepms 2 is copyrighted by Doug Miller, N2gte. Pc-node v3
Download 75.12 Kb.
|
| The N2GTE Packet Message Switch (GTEPMS) v1.2 Documentation. ***************************************************************** Legal stuff: GTEPMS v1.2 is copyrighted by Doug Miller, N2GTE. PC-Node v3.59 is copyrighted by John Miller, G8BPQ. NET v890421.1 is copyrighted by Phil Karn, KA9Q. Enhancements to NET is copyrighted by Doug Miller, N2GTE. DESQview is copyrighted by Quarterdeck Office Systems. More Legal stuff: The suite of executables and support files are free to Amatuer Radio operations and is NOT authorized for commercial or military uses. A list of executables and support files that comprise the GTEPMS are listed in Appendix A. The GTEPMS must be copied and distributed to Amatuer Radio operators free of charge, except for reimbursement of out of pocket expenses. Plus, all files listed in Appendix A must be included and unaltered. N2GTE does not accept any liability for any loss; data, hardware, time or monies, through the use of the GTEPMS. ***************************************************************** Preface about these docs from the Author: The N2GTE Packet Message Switch is NOT for everyone, especially the beginner packeteer. The program and documentation herein and elsewhere assumes you already have a working understanding of DESQview, the G8BPQ Node software, TCP/IP, DOS and BBS operations in general. This documentation is not, nor does it claim to be, a tutorial on how to be a BBS SysOp using the GTEPMS. What IS covered in these docs is data needed to setup/operate the GTEPMS and included are items about other support programs (DESQview, BPQ and NET) that need either special configuation or have been modified to enhance the GTEPMS. You should already own docs for DESQview (they came with the program you bought) (what? you didn't buy it? Shame on you!!!) I recommend you read them carefully and keep them handy until you really get the feel for DESQview. There are extensive docs supplied with G8BPQ's node software and KA9Q's NET. These are not included in this documentation, but are supplied on disk for you. I also recommend you read those docs completely. I don't think I can over stress the importance of reading and comprehending all documentation supplied either with the commercial software you bought or what is supplied in this package. Many people have spend many hours writing and revising the words in these files to help make using the GTEPMS easier and fun to operate. You owe it to yourself and your BBS Users to understand what is contained here. There are places in these docs where certain items and procedures are "recommended". I define that word as meaning, "unless you have a VERY good reason to do otherwise, do it this way." ***************************************************************** Preface about the software from the Author: As can be seen by the hardware requirements, it takes a fairly capable computer to execute the programs efficiently. The software is not complicated, but is very complex. Several DESQview windows are working together to act as one complete system. Rather than running dupicate copies of the same BBS code in constantly open, static windows, the GTEPMS opens and closes parts of itself as needed, freeing system memory and clock time-slices. I have taken the major functional parts of a BBS system and divided them into logical groups of tasks, each being performed in its own DESQview window. This approach to the system has greatly increased its apparant speed to the User and other BBSs, and made the most effective use of your computer resources (memory, cpu time, etc). As you get comfortable with this system, you will get to know LISTER, RESOLVER and PORTER on a first-name basis. These are the only three GTEPMS windows which stay open all the time. The USER, FWD and MODEM windows are only opened when needed and closed immediately afterwards. (Exception, the NET window stays open all the time too, and although not specifically part of the GTEPMS, it is an important player if/when you have the GTEPMS cross between AX.25 and the TCP/IP worlds.) There are some files for you to edit and maintain thoughout the life-cycle of the GTEPMS. I recommend you use an ASCII Text editor that does not alter the structure of the file, nor insert special formating characters and spaces. ***************************************************************** Thanks from the Author: I wish to express my deepest thanks to the beta-testers who put up with the gliches, downtime, constant flow of upgrades and bug fixes. To those who help with the docs, and to those which said, "Gee, that's neat! But can you make it do this too?"; I thank you. WB3V Bill Howard KA3DXX George Stickler WA7NTF Gary Kohtala N3ETI Dick Wolters KA3RFE Ben "Pete" Hopping N3GIY Steve Moore WB3FFV Howard Leadmon WA3MEJ Jim Sears Also, thanks to Tom Clark, W3IWI, and Jim DeArras, WA4ONG, for moral support and suggestions. ***************************************************************** 1. Software Requirements: Two software packages are required to operate the N2GTE DESQview-Specific Multitasking Packet Message Switch (GTEPMS) software package; a third software package is recommended for those wishing to run TCP/IP concurrently with their N2GTE Packet Message Switch System. a. DESQview 2.01 or higher or DESQview 386 (which includes the QEMM 386 Extended Memory Manager for the 80386 Machines) is required. This is a commercial software package and must be bought by the SysOp/Owner of the system. Copywrites on DESQview and QEMM 386 are held by Quarterdeck Office Systems. b. The G8BPQ AX.25 Networking Software, version 3.57 (or v3.59), is free to duly licensed Amateur Radio Operators and is provided along with the N2GTE Packet Message Switch Software Package (on the same or separate diskettes). Note: G8BPQ v4.x and higher will NOT work due to major changes in BPQ interfacing. Thus the only versions to use are v3.57 and v3.59. c. (optional) The N2GTE version of NET v890421.1.5N2GTE TCP/IP and interfaces with G8BPQ's AX.25 Networking Software is recommended if you plan to run your TCP/IP system concurrently with the GTEPMS and use the same radios and TNC's. The TCP/IP files necessary to run N2GTE's modified version of NET and documentation are provided with N2GTE's Packet Message Switch; however, for documentation on TCP/IP in general, you should get one of the later versions of KA9Q's Internet Protocol Software package with documentation (available from many sources). Strongly recommend 128K of ramdrive. You may use VDISK or any other ramdisk utility you wish. If you choose not to use a ram drive, you still must supply a valid drive letter in the file \CONFIG.GTE (see later about this file). The PMS uses the ram drive to spool temporary files during inter-window communications. ***************************************************************** 2. GTEPMS Hardware Requirements: Minimum Equipment for Full Operations (with full BBS, Node, and TCP/IP Operations) to run then N2GTE Packet Message Switch code is as follows: - An 80286-class IBM-Compatible Machine with at least two megabytes of EEMS or LIM 4.0) RAM is required; or a 80386 with two to four megabytes of RAM (4Mb would be best.) - One or more KISS-Mode TNC-2 TNC's (or an internal HDLC card with onboard TNC's) that will run with the G8BPQ AX.25 Net- working Software. ***************************************************************** 3. Set up your directories and files on your hard drive: The GTEPMS expects to find all its file in the root directory of its default disk drive. For those which not NOT wish to actually use a "real" root, you can place all GTE files in a subdirectory and use the DOS SUBST command to substitute the subdirectory with a drive letter. See your DOS manuals on how to do this. The author has used a substituted drive letter T: for his system; so for here on after the default root drive:\path will be refered to as T:\ (which is actually C:\GTE). The following example can be placed in your \AUTOEXEC.BAT file: SUBST T: C:\GTE (or whatever you call the directory) This will create a T:\ drive for the N2GTE Program files to operate from. Of course, you may use a "real" root drive. Note: You may have to place "LASTDRIVE=Z" statement in your \CONFIG.SYS file to allow DOS to use drive letters that high. Whichever method you use, you should set up the following subdirectories on your "root GTEPMS Drive": \HELP \LOG \MSG \PATHS \QUEUE \RSR \USER (there is a small batch file packaged along with the system which can make these directories for you. It is called MAKEDIR.BAT) If you plan to run the TCP/IP package, you must also create these directories: \SPOOL \SPOOL\MAIL \SPOOL\MQUEUE \SPOOL\RQUEUE (there is a small batch file packaged along with the NET code which can make these directories for you. It is called MAKEDIR.BAT) Copy all the main N2GTE Packet Message Switch System and associated executable and command files to your GTEPMS root directory (whatever drive designator you give it). Copy all the G?-PIF.DVP files to your DESQview directory and use the DESQview "Add Program" menu selection to add them to DESQview's main menu. a. Bring up DESQview. b. Select Open a Window and the Add a Program option. c. Select Other Programs from the Add a Program Menu and mark all of the G?-PIF.DVP files to be added to the Open options. d. Hit return to install them. The PIF files come made to use substituded drive T:\. If you have chosen not to use the letter T, you must then edit all the PIF files for the GTEPMS to state the drive you wish to use. Thus to keep things simple, and standardize from system to system, the author recommends you follow his advice and use substituded drive T:\. Edit the ASCII files according to the detailed information following: \CONFIG.GTE File - This file sets several functions and variables within the GTEPMS environment. sample \CONFIG.GTE file: BBSCALL=N2GTE BBSADDR=MD.USA.NOAM BBSQTH=Ft Meade BBSZIP=20755 RAMDRIVE=F TCPIP=YES BBSALIAS=FMBBS DVPATH=C:\DV BPQPATH=C:\BPQ359 QUIET=23-03 ENFORCEQUIET=YES PASSME=YES BIDCHECK=YES note: if you do NOT run the TCP/IP package, mark the TCPIP variable as NO. With TCPIP=YES, then re-queued mail from NET (in the \spool\rqueue) will be picked up by FWD.EXE. Mail can also be converted back to SMTP. With TCPIP=NO, the BBS will ignore anything to do with IP. Notes: With QUIET hours set, this means that your GTEPMS BBS will NOT forward bulletins during this time frame (SB type bulletins will NOT be forwarded during these times; however, Bulletins sent to SP SYSOP are "personal" mail and WILL be for- warded). SP and ST type mail will FWD during QUIET hours. With ENFORCEQUIET set to Y or y your BBS will "enforce" the quiet hours by disconnecting ANY BBS that "attempts" to forward a bulletin to you during your established "quiet" hours. As soon as the GTEPMS station senses the SB command, it will disconnect the station attempting to forward the bulletin. In setting the ENFORCEQUIET, you may enter YES or Yes or Y or y; or NO or No or N or n, but the code only reads the first character, so it doesn't really matter. ----------------------------------------------------------------- \FWD. - you will have to edit this file to conform to your forwarding needs. Here are some notes on the Forwarding File: The \FWD. file entries consist of at least two fields. The first is the ultimate destination (be it callsign, partial callsigns, or H-addr entries). Separated from the first field by any type of whitespace (spaces or tabs) is the second field. This consists of the callsign of the bbs you will send the mail to get it on its way to the final destination. If you wish to export the mail to a file, simply place the filename in the second field. (filenames must have full drive:\path\filename.ext designators because GTEPMS uses the second character being a ":" to detect it is to go to a file instead of a bbs. Hopefully the FCC will never issue a callsign with a ":" in it.) Sample lines from a \FWD. File: K3AKK N4QQ -- this forwards all mail for K3AKK to N4QQ; this type of entry may be an individual user call or a PBBS station call or may be a TNC MBOX call. GB7* N4QQ -- this forwards all GB7xxx mail to N4QQ. HB9* W3IWI -- this forwards all HB9xxx mail to W3IWI. 0* W3IWI -- this type entry sends NTS TFC to a specified BBS call by ZIP (wildcards are allowed) (in this case the BBS station is W3IWI). NTSCA KD3O -- this type entry sends NTS traffic to a specified BBS call by STATE ZIP DIGRAPH (in this case the BBS is KD3O). .AZ KD3O -- this type entry sends Packet Mail for stations in Arizona to KD3O for further forwarding. .AUS W3IWI -- The GTEPMS code can also key on these type designators and route the mail for them to a specific long-haul forwarding BBS's. KA3DXX C:\NODE\DXXMAIL.TXT -- this entry exports the mail to a file. N2GTE (SMTP) -- this entry converts and queues the mail to be sent SMTP over your TCP/IP links if you are running the IP package. If the entry is for your own call, your mail will be sent directly to you BM mailbox file. .CA N4QQ W3IWI WA7NTF -- this entry will queue up anything for California for those three BBSs. Whichever BBS successfully gets the mail first will kill it so the others will not get it. note: The \FWD. file is for SP and ST type mail ONLY. Bulletins are handled completely separate from mail. Also note, the H-addr routings must begin with a "." to denote they belong to the H-addr and is not the bbs callsign. Note: RESOLVER uses a "first hit - bailout" search algorythm. W3IWI will get 209xx zips, but W3KDC will get all other 20xxx zips in the example below. 209* W3IWI 20* W3KDC Another example: WA4ONG will get the Zips while W3IWI will get the stuff for overseas. 4X* W3IWI 4Z* W3IWI 4* WA4ONG ----------------------------------------------------------------- \CHORE.xx Files - these files will have to be edited to suit your forwarding needs. To import files, list them in the CHORE files so that the FWD window picks them up. Filenames are recognized by having a ":" in the second character place. The following are examples of a \CHORE.xx file: D:\SPREAD.OUT D:\REQDIR.OUT D:\REQMUF.OUT WB3V KA3DXX KD3O KB8AOB N3DMC The *.OUT files could be output files created by a server. You may have as many chore files as you need. The author names his chores by the minute he FWDs. example: CHORE.10, CHORE.40 and CHORE.55 Each chore file can be different, thus you would FWD to a different group of BBSs during that particular FWDing cycle. ----------------------------------------------------------------- \PORTER.CNF - this is the file that sets up the forwarding times that PORTER will open a FWD window. The SysOp can also use it to have PORTER open other windows at certain times during the hour. These other windows could be batch files to run servers or other things. The file consists of four fields; Normally there is only one type; "T" (for Timed function). All other type are reserved for future enhancements. The second field is the minute after the hour you wish this window to open. The third is the filename of the DESQview PIF file which opens the window. The last field is any parameters you may wish to pass to the window when it opens. Sample PORTER.CNF File: T 05 C:\DV\SB-PIF.DVP T 10 C:\DV\GF-PIF.DVP CHORE.10 T 40 C:\DV\GF-PIF.DVP CHORE.40 T 55 C:\DV\GF-PIF.DVP CHORE.55 Note: In this example the line beginning with T are "timed" chores for the BBS. T, of course, denotes "Timed function". The 05, 10, 40, and 55 are the times in minutes past the hour for the chores to take place. The SB-PIF.DVP file is for a server. The GF-PIF.DVP (called at :10,:40,:55 minutes past the hour) are forwarding chores for the FWDing window. Note: Try to avoid assigning chores for timed functions at :00, :15, :30, or :45 minutes past the hour, since these times are the times RESOLVER will task PORTER to beacon the "unresolved" mail, thus at these exact moments, the BBS is fairly busy building the mail beacon. Note: Remember, PORTER has a max limit of 16 timed chores, so watch how many things you task PORTER to do. ----------------------------------------------------------------- \DV-MAIL.DAT File - This file is the message database and should not be tampered. Repeat -- Leave it alone! ----------------------------------------------------------------- \BIDOK. - this file should be okay as is, but you may need to add any local area distribution lists that may have NON-STANDARD BID's. (BID is Bulletin ID [that funny $ thing on the end]) When the BBS receives a bulletin, it checks its BID against one it formulates itself from the last header line. Normal BIDs are of msg#_callsign type format. If the BID that came along with the bulletin fails this check, it is placed on hold until it either grows stale and expires or the sysop manually goes in and release/kills it. But many bulletins do not follow the msg#_callsign format on purpose. Examples are ARRL and AMSAT buls. These have special BID formats that always begin with certain letters. The BBS has a feature that if a bulletin fails the BID check, the BBS checks the BIDOK file before placing the bul on hold. This BIDOK file consists of the @BBS designated followed by at least one whitespace (tab or space), then the beginnings of the odd BID to try to match. If the odd BID is only 3 characters long, then only the first three characters of the bulletin BID is checked for a match. If the odd BID is four characters long, then four characters of the bul BID is checked, etc, etc.. Stars and questions marks CANNOT be used as wildcards. If the first characters of the bul BID matches the odd BID, then the BBS releases the bulletin normally (if it is not already stale). The SysOp may edit the BIDOK file to add new NON-STANDARD BID forms to the file. The following example is a good start for the BIDOK file: AMSAT ANS AMSAT ORB ARRL ARL USA RACESBUL USA RTDX USA SPC SKYWRN NWS Note: The GTEPMS will automatically accept BIDs with the following formats: msg#_callsign callsign_msg# msg#callsign and the Europe style of BIDs which encodes in the Date. ----------------------------------------------------------------- \HADDR. - this is a file the GTEPMS will create from message headers. The HADDR file is updated by the HEADX.EXE program as it extracts header information from incoming messages. The file has entries like the following: KA5EJX.#WTX.TX.USA.NA [Lubbock] Z:79413 WG5F.#WTX.TX.USA.NA [Midland] AE5I.#WTX.TX.USA.NA AA5KG.#WTX.TX.USA.NA [San Angelo] Z:76901 WA6RDH.#NOCAL.CA.USA.NA [Dixon] Z:95620 This is one of the files the BBS checks for Hierarchical information when it resolves a message for forwarding. Note: you must run HEADX.EXE yourself from a DOS window. I recommend running it about once every two days, or so, depending on how many new message your system receives per day. HEADX.EXE must be ran from the BBS-root directory and perferablly while all activity is quiet (ie no new messages in the process of coming in). ----------------------------------------------------------------- \LINKS. - this file will describe the Area names of the files directories and the paths to them as shown in the following example ASCII G: TCPIP Y:\TCPIP NETDOCS C:\DOCS NOSDOCS C:\DOCS\NOS GTEDOCS C:\DOCS\GTE SERVERDOCS G:\REQDOCS HELPFILES T:\HELP BBS-BY-STATE E:\HADDR To use the LINKS file, create a file in the "root" directory of the PMS called \LINKS. Enter the contents in two columns -- the first column is the alias you want for the direc- tory AREA; the second column is the drive:\path(s) for the real directory. Do NOT include a trailing backslash. What this file does is "link" these drive:\paths into a psuedo directory for your users to upload and download ascii file to/from. The user will only be able to use directories that you have linked into your system. They cannot use sub-directories of the links unless you have also linked them in with separate link names. (See the above example in lines NETDOCS, NOSDOCS and GTEDOCS.) ----------------------------------------------------------------- \MOD. - this file contains the Message of the Day and you should edit it to suit your needs or desires. You should keep it kind of short for the most part, but on certain occasions you might have reason to include a short announcement of some specific event or suggestion to read a given message. The SysOp can enter something like "Read Message #12450 for Important Notice" or something along those lines. Edits to the \MOD. file take effect immediately and the changes will be seen the next time a user (or bbs) connects. ----------------------------------------------------------------- \MOUNT. - you will use this file to enter the BPQ-Node Station Calls-SSID's to tell PORTER which other GTEPMS stations it can inter-link with for Remote Service Requests (RSR). An example of a \MOUNT. file: N2GTE-6 WA7NTF-7 N3ETI-5 WB3V-2 Remember, this is the callsign of the BPQ node, not the BBS itself. Remote Service Requests (RSR) is what make GTEPMS systems unique. If your system cannot resolve a certain piece of mail, it can, thru the RSR, task other GTEPMS system to assist. You virtually have access and use of their \FWD., \HADDR., \USER\*. files to help your system resolve mail. Once you ask (and get an answer) your system "learns" and can resolve this mail again in the future without help. Thus, a new GTEPMS can start with a very minimal \FWD. file and actually learn and grow if there are other GTEPMS within netrom range. ----------------------------------------------------------------- \SEQUENCE.SEQ -- this is the file that maintains your one-up message numbering for your BBS. On bootup the BBS reads the file, but then never reads it again; only writes to it. The only purpose of the \SEQUENCE.SEQ file is for message number recovery during re-start of the BBS. The BBS keeps track of sequence numbers, but continually updates that file so the data in the file stays in sync with the count inside the BBS. The only way to "force" a warp jump to another number would be to close the BBS (using the shutdown procedures listed in the setup section); change the number in the \SEQUENCE.SEQ; then start the BBS back up. ----------------------------------------------------------------- \SPAWN. - you may create this to suit your needs to spawn other non-BBS windows upon boot-up. If you want to open another DESQview window as soon as the BBS System is booted up, you need to put the xx-PIF.DVP files in the SPAWN file. CAUTION: DO NOT UNDER ANY CIRCUMSTANCES PUT PORTER (GP- PIF.DVP) OR RESOLVER (GR-PIF.DVP) IN SPAWN -- THESE TWO FILES ARE OPENED BY LISTER (GL-PIF.DVP) WHEN IT COMES ON LINE. Here's an example SPAWN file: C:\DV\IP-PIF.DVP C:\DV\BD-PIF.DVP where IP-PIF.DVP and BD-PIF.DVP are the DESQview PIF files that will open the windows for N2GTE's version of NET TCP/IP window and a "Big DOS" Window. ----------------------------------------------------------------- \SWAP. - This file swaps out the BBS call or alias and in the process strips off the state/province digraph, coun- try, and continent codes, as well as the @BBS call for all mail destined for the BBS. Example SWAP File: KA3DXX SEVBBS WA7SSO W3YA <-- this is handy if someone has changed calls K1LNJ WB3V.MD.USA <-- or upgraded like Bill did. NTSMDC NTSMD <-- to correct misconceptions ARL ARRL <-- to standardize incoming ARRL bulletins. ARLB ARRL ARLP ARRL ARLS ARRL USABBS USA <-- to standardize incoming USA bulletins. ALLBBS USA ALLUS USA ALLUSA USA WA7NTF.WA.USA WA7NTF.MD.USA <- he moved. You may place H-addr info in the second field of the swap. ----------------------------------------------------------------- \BULLETIN. File: Each bulletin distribution list must have its own line within this file (such as, ARRL, AMSAT, BSA, CBBS, EU, MBLBBS, MDCBBS, REBBS, RLIBBS, SKYWRN, USA, etc.). Each of these lines would contain the station calls that are to receive the bulletins. Exporting bulletins to files is supported, enter the full drive:\path\filename.ext in the file. Its format is: Download 75.12 Kb. Share with your friends:
|