TXM Documentation for v1.50. ----------------------------- This release of TXM incorporates many changes from the v1.00 Beta release. The changes are so numerous that I have not made a simple "cook-book" type listing of them. The documentation for v1.50 has been completely re written. Therefore it is strongly suggested that you read this new documentation in its entirety to understand the changes from v1.00. TXM now forwards to as many as 6 other BBSs and has forward file capability to select the type of messages to forward to each BBS. This release of TXM incorporates LZH file compression to speed the transfer of backbone mail between TXM nodes. TXM intelligently recognizes what type of BBS is connected to it and goes into LZH or West Net Mode. Your feed back is encouraged. Let me know what you think! You can write to me at: Dan Hyman or log on to my BBS: PO BOX 367 1-209-661-5355 Madera, CA (USR 14.4 DS) 93639 The latest copy of TXM will always be available there for download, and you can leave me e-mail there if you have support questions. For registered users of TXM you will receive my office phone number for voice technical support. If you have access to a Fido Node you can request the magic filename TXM from Fido node 1:10/45 (USR 14.4Kb Modem) for the latest copy of TXM. PROGRAMMERS NOTE: ----------------- If you are a programmer interested in implementation of BBS or Mailer software that is compatible with the TXM-LZH handshake/session protocol, I would be happy to release the technical specifications for use in the public domain. If interested, contact me at the above. This is NOT FREE SOFTWARE! ------------------------- TXM is distributed as SHAREWARE. This means that you have a fully functioning copy of the software. If you continue to use the software to do a job for you, then you have to remit the nominal fee to the authors. No one will sue you if you don't. No one will write you a nasty letter if you don't. It is up to you to remit the fee for the following simple reasons: 1. It's the right thing to do. 2. You will then be a registered user and get full phone support direct from the authors. You will have direct access to the develop- ers to suggest improvements or new features that YOU want to see in the next release of TXM. 3. You will be on our mailer list and receive information about the latest revisions and uses for TXM. 4. Most important you will keep us motivated to keep expanding and upgrading the software. YOU benefit with a better product to do a better job for YOU! If everyone thinks "the other guy" will send in the fee so I don't have to, then TXM will simply die. 5. Five Dollars of your registration fee will be donated to the Electronic Frontiers Foundation. This organization, started my Mitch Kapor the founder of Lotus Development Corp., is dedicated to protect- ing your civil liberties in electronic media. Your right to free speech and privacy should not be taken away by your government under the thin guise that such rights don't apply just because you are talking on a computer network vs the soapbox at town hall. Times have changed, we are in the computer age now, but the same issues of tyranny remain ages old. To register your copy of TXM send $35 to: Dan Hyman PO Box 367 Madera, CA 93639 Be sure to include a note with your name and address. Disclaimers - Copyrights - and Thank Yous ---------------------------------------- Wherever noted references occur in this documentation to commercial or preexisting software or hardware, those references hereby acknowledge the rightful holders of copyrights concerning the product. This software (TXM.EXE its documentation and related files) are the exclusive property of Dan Hyman and is Copyright 1991 by Dan Hyman. Reproduction in any form is prohibited with the sole exception that the original archived release file (TXM-150.ZIP) may be reproduced without restraint as long as NO changes, additions or deletions are made to that file and the file is distributed undisturbed from its original form as released by Dan Hyman. Placing this file on Public BBS systems for download is permitted. Many Thanks go to the willing helping hands that became entangled with my development of this project. Notably (and not listed in any particular order of precedent) were: Bryan WB6ODZ, Tony KC6QJO, The Madera Amateur Radio Club, Fred K6RAU, Roy AA4RE, Rick N6LDG. Thanks to all of you! TXM is not guaranteed to perform flawlessly forever under any and all circumstances of operation. TXM is designed as an experimental platform to interface Amateur Radio TCN/Packet Stations with Amateur Land Line Operated BBS systems. TXM is not designed for mission critical operations in commercial environments. IMPORTANT! ---------- NO ONE IS PERMITTED TO CHARGE YOU FOR THIS SOFTWARE! DO NOT PAY ANY SERVICE FEE EXCEEDING $1 (ONE DOLLAR) TO COVER DUPLICATION COST FOR A DISK WITH THE v1.50 ARCHIVE! COMPANIES THAT REPACKAGE SHAREWARE AND PUBLIC DOMAIN SOFTWARE AND THEN SELL THAT SOFTWARE TO YOU ARE NOT PERMITTED TO INCLUDE THIS SOFTWARE IN THEIR PRODUCTS! NOTIFY ME IMMEDIATELY IF YOU SEE THIS SOFTWARE BEING REPACKAGED IN THIS MANNER. YOU SHOULD HAVE THE FOLLOWING FILES IN THE ARCHIVE PROGRAM FILES: TXM.EXE 12.01.91 187744 BYTES TXM-CFG 12.01.91 43888 BYTES TXM-LINK 12.01.91 54720 BYTES TXM-TOSS 12.01.91 15888 BYTES BOOT.COM 12.01.91 601 BYTES EXAMPLE FILES: TXM-CFG.CTL 12.01.91 BYTES TXM-FWRD.CTL 12.01.91 BYTES TXM-USER.CTL 12.01.91 BYTES What is TXM ? ------------- First TXM is NOT a BBS program! TXM is designed to serve two functions: Either of these functions can be run alone or TXM can run both functions sequentially. First, TXM interfaces TNC Packet Radio to Land Line BBSs (LLBBS). This is the "TXM BBS Link Function" With TXM BBS Link Function you accept a caller into a packet radio station and dial out on a telco line via a modem running on the TXM machine to a remote LLBBS. The packet user is then transparently talking to the LLBBS via the TXM system. The caller does not know he is on TXM. He sees only the LLBBS system. Additionally TXM manages many features of a packet Station. It sends beacons, keeps track of who calls, allows only approved callers to pass through the system, and much more. Second, TXM serves as a "front end mailer" to interface the world of Fido Standard Messaging System to the world of West Net type message traffic common on many packet bbs software systems such as MSYS and AA4RE. Additionally TXM extends the ASCII transfers now in use on PBBS systems to include an LZH data compression method of transferring the mail between TXM nodes. This is the "TXM Mailer Function" With TXM Mailer Function you can poll a packet gateway or another TXM node station and receive a feed of mail messages. Then TXM will transfer those messages to *.PKT Fido format to the remote LLBBS machine for further processing onto the LLBBS message base by your LLBBS tosser software. Additionally TXM will route this mail as "PASS-THU" mail to any one or all of the NETBBS station known to TXM. In this way TXM acts as a "router". If another station that TXM is routing to is a TXM node running TXM V1.50 or higher then the mail will be sent in LZH com- pressed format. Substantial, and sometimes very dramatic, improvements in thru-put can be gained using TXM-LZH sessions versus MSYS or W0RLI type "OK" NO" ASCII sessions. The discussions in this documentation regards the TXM-LZH protocol should be of interest to those that operate or are responsible for BBS "Backbone" mail systems. Additionally TXM provides the functionality to fully "gateway" Fido <--> WestNet, but this practice is not for use by the general public for obvious reasons. Central to the idea in the design of TXM is the concept that the packet station should be at a physical location remote from the LLBBS. The reasons for this are many, but mainly boil down to two important ones: 1.) LLBBS software should be running on a machine that is readily at hand in the office or home. LLBBS systems require constant maintenance and attention. 2.) the packet TNC/ Radio location needs to be at what is usually a physically isolated location, either on a mountain top, or at a radio tower on desolate property far away from the population center. Therefore an intelligent data link is necessary to connect the two locations. TXM provides that link. It uses the expedient of dial up telco modems and public telephone lines, although it could just as easily use microwave, laser, or VHF/UHF duplex radios. If the location for the TXM remote and the LLBBS are in the same "local calling area" as defined by the phone company the cost of a dedicated phone line for TXM is only a few dollars a month and provides a very cost effective data link solution. Of course the traditional link between the BBS and the remote packet user has been the digipeater. Unfortunately the digi places severe overhead loads on data through put. TXMs design paradigm assumes that you feel as I do; that the day of the digi is dead. Of course you may allow your users to digi to your LLBBS via your TXM link, but doing so looses for the user much of the "live interactive" nature that is so exciting about logging onto a BBS. With a properly set up TXM BBS link and good solid LLBBS software you can very closely emulate the interface and "look and feel" of a LLBBS on a "over the air" packet connect session. Node operation interferes with TXM-LZH mail mode as a result of the severe overhead load imposed by NET ROM type software. It is strongly recommended that you use direct point to point links whenever possible if you are considering setting up a TXM-LZH mail node forwarding system. See the discussion in this documentation regards the TXM-LZH session protocol for a full discussion of this issue. One of the basic ideas for making a program like TXM is that it provides the opportunity to interface packet users with existing LLBBS software and Fido Net type message base systems. Notwithstanding the fact that several excellent PBBS software packages have been written, the plain fact is that the LLBBS world has about a ten year jump on packet BBS systems. This is most evident in the store and forward mail arena. The design and execution of systems like e-softs' TBBS, OPUS, Wildcat, and many others reflect many years of hard won understanding of how networked messaging systems, and BBS user interfaces should be constructed. There is a vast body of existing software and design effort that can essentially be "bolted- -on" to the packet world. Additionally the Fido Net System provides an excellent model of how a well designed distributed store and forward mail system should work. The world of ham packet radio desperately needs to quickly get "up on this learning curve". TXM provides a test bed interface system for those that want to experiment with existing LLBBS technology and packet and data compres- sion techniques to enhance backbone mail transfers. What You Need To Get TXM Up and Running: --------------------------------------- If you are interested in using the BBS Link functions of TXM, we will then assume that you have some background in running a LLBBS. If you are interested in running the TXM Fido-Mailer function we assume that you have substantial experience in running a Fido com- patible BBS system. If you are interesed in running the TXM-LZH Forwarding, an experienced PBBS SYSOP can put to good use the forwarding and LZH mail compression features of TXM. It would be fool hardy for someone not experienced in running a Fido BBS system to attempt to enter into the complexities of setting up TXM in its Fido mailer function mode. We will assume that you are familiar with much standard "Fido" jargon when describing how to set up the mailer. Additionally we will assume that you have a fully functioning Fido system at this time INCLUDING an assigned Fido Net Address in the current Nodelist. If you do not have a Fido Net Address in the Nodelist then you will have to kludge one. This is discussed in detail later in the documentation. Also the TXM Fido Mailer function depends, like all Fido systems do, on many other Fido compatible programs all working in concert to achieve overall system functionality. Fido systems are run on PCs from what become very complex batch processing files that you must write yourself. It is not a job for the faint of heart! Fido systems resemble Unix or mainframe system paradigms. If you are a "Macintosh" or "MS Windows" consumer level software user that assumes that you can press one key the "program will do it all" then TXM Mailer functions are not for you. However, it is certainly feasible for someone not experienced in Fido store and forward messaging systems to use with great success the TXM BBS Link functions to interface a simple LLBBS with packet radio. You just will not be able to gateway messages into and out of the packet backbone system, but otherwise your BBS will have whatever functional- ity you build into the LLBBS system beyond that. Hardware - What You Need ------------------------ TXM BBS Link Functions run on a machine that will be at your radio/TNC site. The Hardware should be an AT class machine with a 20 meg hard drive. It may be possible to run TXM on a fast 8088 but that is unlikely. TXM manages async data in real time using interrupt driven techniques. Data loss will occur with machines that can not keep up with the constant service required on multiple UARTS. It may also be possible to run TXM in the BBSLINK mode only on a machine with only one floppy drive, but it is not recommended. It is NOT possible to run TXM in the MAILER function, especially if you are going to talk to other TXM nodes and use the LZH compression and use only floppy drives. A hard disk is REQUIRED and the faster the better. For reasons of data integrity the LZH compression and mail forwarding deign in TXM is very disk intensive. The TXM remote machine will need at least a 2400 modem capable of being controlled with hardware flow control and using the standard Hayes AT Verbal command set. The modem MUST be on com 1. Additional- ly it will need one com port configured as com 2 for connection to your TNC. TXM was developed and known to work with Kantronics KPC-2 TNCs. - IMPORTANT! - Shield the TXM machine from strong RF fields that may be present at your TXM site. Ground the computer chassis, case, and any hardware that is externally attached to the TXM machine. Strong RF may inter- fere with modems, and in some cases has been known to cause parity errors on memory chips in computers and their attached hardware. Keep all cables as short as possible and use only high quality shielded cables. You may decide to use a third com port for TXM mailer functions. This will allow you to "cross band" to a different radio on a different frequency. TXM will conduct its mailer sessions out of either port 2 or port 3 or both. If you decide to use port 3 then it must be configured as com 3 set to IRQ 5, and you will need a second TNC. Not all com port cards can be configured in this manner. Make sure you have the right hardware! Your choice of LLBBS machines, modems, and software is up to you. Hardware - Setting up your Com Ports ------------------------------------ TWO com ports MUST be on your remote TXM machine: If you are using TXM Dual Port Mailer Function then you need to add also the THIRD listed port on IRQ 5. UART registers must conform to IBM clone standard (will NOT work on PS2 !) as follows: PORT BASE ADDR INTERUPT -----|------------|--------- Com1 $03F8 4 Com2 $02F8 3 Com3 $03E8 5 <-- for TXM 2 port Link function Beware that not all Async Cards will allow you to set up the ports to IRQ 5 on com 3. Make SURE that you have NO OTHER HARDWARE in your system that addres- ses these ports or otherwise sits on the IRQ lines or their associated vectors! Hardware conflicts of this type are the number one reason people call for tech support and they are the hardest problems for the tech support person to help you with over the phone! If you are having hardware conflicts, or think you might be, then use the meat-ax approach: Open the case on your PC and rip out every last card in the machine that isn't required to run TXM. Then go to your Config.Sys file and comment out any reference to device drivers that accessed those cards, then go to your Autoexec.bat files and comment out any Dos Mode commands. Also if you have TSRs that have phone dialers and the like then get rid of them. Hardware - Setting up your Modem -------------------------------- TXM works its attached hardware with a basic design paradigm that effects your set up of that hardware. This design approach is that: as much work should be off loaded to the attached hardware as possible to free up the CPU of the host machine, and that attached hardware should be responsible for its own configuration and settings. This simply means that you will set up your modem with the required settings and then write those settings to the NRAM (non volatile memory in the modem). The modem therefore MUST have NRAM. Most all modems that you find around for a PC now are reasonably standard, or enough so at least, to allow us to suggest some of the required settings. It is your responsibility to look over these suggested settings and find the appropriate like or equivalent setting on your particular modem brand. Consult the documentation that came with your modem. MODEM TYPE REQUIRED: - IMPORTANT - TXM uses a Hayes AT command set modem. TXM will operate the modem at 2400 N, 8, 1, or with other speed as you specify in the TXM-CFG.CTL file. We recommend that you use an internal card type modem. This is because consumer level modems are sensitive to strong RF fields that may be present at your TXM site. Use of internal modems eliminates the RS232 cabling required for an external modem. If you use an external modem take precautions to shield it from RF and ground this shielding as well as the modem and computer case and all attached hardware. WRITING YOUR MODEM CONFIGURATION: - IMPORTANT! - After setting your modem then use the AT&W (or what ever equivalent command applies to your modem) to write the changes to NRAM! If you do not write the settings to NRAM then they will be lost as TXM constantly resets the modem during program operation. CORRECT CABLING OF YOUR MODEM: - IMPORTANT! - Cable your modem with ALL pins supported! TXM uses the all hardware lines to deal with the modem and its operation. You MUST have a cable that supports the CD and CTS lines! TXM will abort during BBS link functions if it can not determine CD on the modem! SUGGESTED MODEM CONFIGURATION: It is recommended that you begin your setup of the modem by doing an AT&F for return to factory defaults. TXM can usually work more or less successfully with modems operating in their factory default setting. After setting to the &F then try the settings listed below. 1. Suggested Setting &D=2or3 TXM attempts to reset the modem with a change in the state of DTR. Some modems require that you enable the modem to respond to this state change by this setting. In any event you want to tell your modem to assume its initialization state on a change of ON to OFF transition of DTR. 2. Suggested Setting S25=1 This is the internal timer associated with the above DTR transition state. 3. Suggested Setting V1 TXM require verbal response codes from the modem. 4. Suggested Setting S0 This turns off the auto answer feature of the modem. TXM handles the incoming answer sequence itself. DO NOT allow the modem to answer the calls on its own. 5. Suggested Setting &R0 CTS follows RTS for hardware flow control. Now make the changes permanent with the AT&W command. Hardware -Setting up TNC #1 for BBS Link Function ------------------------------------------------- TXM works its attached hardware with a basic design paradigm that effects your set up of that hardware. This design approach is that: as much work should be off loaded to the attached hardware as possible to free up the CPU of the host machine, and that attached hardware should be responsible for its own configuration and settings. This simply means that you will set up your TNC with the required settings and then write those settings to the NRAM (non volatile memory in the TNC). TNC TYPE REQUIRED: TXM has been developed and tested and known to work with Kantronics KPC-2 and KPC-4 TNCs. It is very possisble that TXM will function well with other TNC brands, but because of time and financial con- siderations the author of TXM has not been able to verify that. - IMPORTANT - TXM will operate the TNC to computer interface at 2400 N, 8, 1. TXM has no user configurations for changing these parameters. You can not use 1200 baud with TXM. Consult your TNC Docs for setting the TNC to computer speed and protocol. We have found some "flakeyness" of operation of Kantronics KPC-2 and KPC-4 before firmware revision level 3.0. It is very strongly suggested that if you are using a Kantronics with an old ROM in it that you contact Kantronics for a new chip. Particularly we have found that they do not respond very well to hardware control of the DTR lines and Break signals. If you are having reset problems with an older Kantronics then the problem is with the firm ware NOT with TXM. Unfortunately we have had no experience running TXM on other TNC brands. Please contact me with your feedback on what results you obtain when using TXM with other TNC hardware. Thank you. WRITING YOUR TNC CONFIGURATION: - IMPORTANT! - After setting your TNC then use the PERM (or what ever equivalent command applies to your TNC) to write the changes to NRAM! If you do not write the settings to NRAM then they will be lost as TXM resets the TNC constantly during operation. CORRECT CABLING OF YOUR TNC: - IMPORTANT! - Cable your TNC with ALL pins supported EXCEEPT #18 & #25 ON THE KANTRONICS KPC SERIES! TXM uses the all hardware lines to deal with the TNC and its opera- tion. You MUST have a cable that supports the CD and CTS lines! TXM will abort during BBS link functions if it can not determine CD on the TNC! Beware the cables that come from the factory with the Kantronics TNC, they DO NOT support all pins. * NOTE CARFULLY THE INSTRUCTIONS IN THE KANTRONICS MANUAL FOR WRIING * THE RS-232 CABLES. IF YOU USE A FULL 25 WIRE CABLE SET THEN REMOVE * PIN _18_ AND PIN _25_. * SEE THE KANTRAONIC INSTALLATION MANUAL FOR FULL DETAILS. SUGGESTED TNC CONFIGURATION: It is recommended that you begin your setup of the TNC by doing an RESTORE D for return to factory defaults. Unlike the modem, TXM.EXE WILL NOT WORK with TNCs operating only in their factory default setting. After setting to the RESTORE D then use the setting listed below. Additionally consult the appendix of this documentation for example TNC Configuration files showing a typical set. There are comments in the margins of this listing that may be of value to you in understanding how to approach the set up of your TNCs. - IMPORTANT - Considerable "tweaking" is required to get TNCs to function at optimum data thru-put in any given packet radio environ- ment. Many factors affect data thru put on the TNC, some of these factors are beyond your control. If you are allowing digipeating into your TXM system then this will change the way you configure paclen and pactime, and frack. Other stations operating on your frequency will have an effect of how far you can "juice-up" the TX turn- around time using persist and slottime. Part of the "fun" of packet radio will be your experimentation with these settings. DO NOT assume that once you have set your TNC for the first time and you have got your system up and running that you can forget it! Monitor the action of your system and try to determine how you can improve the overall data thru- put. After all maximum thru-put is the name of the game. You can tell a sysop that knows what he is doing by the efficiency of his BBS system. Some setting are required for operation of TXM and can NEVER be changed, and some are for "tweaking": 1. Required Setting ABAUD 2400 2. Required Setting CD Internal 3. Required Setting CONMODE TRANS 4. Required Setting FLOW OFF 5. Required Setting NEWMODE ON 6. Required Setting NOMODE OFF 7. Required Setting STOP $00 8. Required Setting START $00 8. Required Setting XFLOW OFF 9. Required Setting XOFF $00 10. Required Setting XON $00 11. Required Setting ECHO OFF 12. Required Setting MCON OFF 13. Required Setting MCOM OFF 14. NOW ISSUE THE PERM COMMAND ! - IMPORTANT - TXM will not function if the above parameters are not set and "permed" in your TNCs. If you are having trouble with TXM then please do not call for technical support until you have assured that the above settings are permanent in your TNCs. Some suggested "tweaking settings" are listed below. These are primarily intended if you are operating in a mode that does not allow digi access to your system, and you are operating on a frequency that is more or less "quiet" without a lot of other RF present. 1. Optional "Tweak" 8BITCONV ON 2. Optional "Tweak" DWAIT 0 3. Optional "Tweak" DIGIPEAT OFF 4. Optional "Tweak" MAXUSERS 1 5. Optional "Tweak" PACLEN 255 6. Optional "Tweak" PERSIST 255 7. Optional "Tweak" SLOTTIME 1 8. Optional "Tweak" TXDELAY 60 Of course many other parameters may come into play, and much will depend on how your LLBBS is set up. Playing with the TNC parameters on the BBS link TNC will probably be a months long project for you, but it will be very rewarding to have the "fastest Packet BBS on the block". Hardware - Setting up TNC #2 for Mailer function ------------------------------------------------- If you decide to use port 3 then All instructions apply as well to TNC #2 for the TXM BBSLink and Mailer Functions as noted above for TNC #1. Follow the directions above. Other Software - You Will Need ------------------------------ If you are just using the TXM BBS Link functions and/or the Mailer Function to forward to other PBBS stations then all you will need is what is provided in the distribution files (TXM-150.ZIP) plus a suitable text editor to edit the CTL files. If you are going to use the TXM LLBBS Fido Mailer Integration Func- tions then you will need all the normal Fido support programs normally associated with a BBS system running Echo mail. This includes at the very least a message tosser like Qmail that can place *.MSG files into directories and a Fido tosser that can handle *.PKT Fido format packed message files that will be created by TXM-TOSS.EXE. That tosser will be responsible for merging the TXM-MAIL.PKT files created by TXM-TOSS- .EXE into your LLBBS message bases. It is your responsibility to assure that your Fido system is running smoothly BEFORE you attempt to integrate TXM Mailer Functions into the system. Adding TXM mailer functions to a buggy Fido system will result in unrecoverable confusion. Installing TXM -------------- Remember that a common source of problems when installing and con- figuring TXM will be the simple fact that TXM has multiple functional- ity and that different functions may run on separate computers each of which must have the appropriate path and directory structure. For purposes of this documentation any reference to LLBBS is a reference to the computer that is at the base location machine running the LLBBS software and any reference to TXM Remote means the machine running the TXM software at the remote site. Those two machines will ALWAYS be two different pieces of hardware. If you are running TXM BBS Link Functions then the following files must be on the TXM remote machine: Establish a default directory for TXM like C:\TXM and load the following files there: TXM.EXE - REQUIRED! TXM-CFG.EXE - REQUIRED! TXM-CFG.CTL - REQUIRED! TXM_CFG.DAT - REQUIRED!..created by TXM-CFG.EXE TXM-USER.CTL - REQUIRED! TXM-FWRD.CTL - REQUIRED..only if You Are Using Mailer Function BOOT.COM - REQUIRED! BEACON.TXT - OPTIONAL NEWUSER.TXT - OPTIONAL LOGON.TXT - OPTIONAL LOGOFF.TXT - OPTIONAL HOURFILES IN THE FORMAT = 0100.TXT, 0200.TXT, 0300.TXT ETC -OPTIONAL If you are running TXM Fido Mailer Functions then the following files must be on the LLBBS machine: (remember when discussing TXM Mailer functions we will use standard "Fido" jargon and we assume you understand these terms for their common accepted meanings in the Fido world) From the directory where you run your mail tosser or main BBS program : TXM-TOSS.EXE -REQUIRED! TXM-CFG.EXE - REQUIRED! TXM-CFG.CTL - REQUIRED! TXM_CFG.DAT - REQUIRED!..created by TXM-CFG.EXE From the directory where you run your mail tosser or main BBS program: TXM-LINK.EXE -REQUIRED! TXM-CFG.EXE - REQUIRED! TXM-CFG.CTL - REQUIRED! TXM_CFG.DAT - REQUIRED!..created by TXM-CFG.EXE Getting TXM BBS Link Function Running ------------------------------------ First assure that your modems and TNC have been configured as outlined in the previous headings regarding hardware set up. Transfer the all files to their directories. Connect your radios and TNC . Get your text editor running and locate the example TXM-CFG.CTL file. Use a text editor NOT a word processor. Save files in DOS text file format only. See the Appendix of this documentation Titled "TXM-CFG.CTL File Documentation" for detailed information on each command available. To just get started do the following: Go into the TXM-CFG.CTL file and change at the very minimum the following parameters: 1. MYCALL parameter to your call or station aliases. 2. LLPHONE# to reflect the LLBBS phone number. 3. PASSWRD_REMOTE to some password of your choice. VERY IMPORTANT!: All passwords used in TXM MUST be different from each other! DO NOT assign the same password string to two or more password functions. 4. Using a terminal program like Procomm or Telix, log onto your LLBBS via a phone line and note very carefully the exact string that your LLBBS software uses to prompt the caller for his name. Insert this exact string in as the argument to the LL_PROMPT_2 command. Make sure that the LL_PROMPT_1 argument is blank like this " " unless you have a two stage log on sequence required by your LLBBS software. 5. Set up your LLBBS software with the same callsigns that you have put in the TXM-USER.CTL file, and set up your LLBBS software to accept this caller name without a request for a password. The caller should be passed by your LLBBS software directly into the LLBBS WITHOUT further requests for any information after TXM passes the callsign to the LLBBS software. This "passing" occurs immediately after TXM receives the argument you have placed at the LL_PROMPT_2 command. Save the file with your text editor. Now get the file TXM-USER.CTL into your text editor. At the very minimum put in your call sign and maybe a call sign of a friend of yours that will help you debug your TXM system. Save this file and exit your text editor. Next you must run TXM-CFG.EXE to convert your new text files to their binary objects for TXM.EXE. RUNNING TXM-CFG.EXE ------------------- To Run TXM-CFG.EXE just type that name on the command line when you are in the TXM default directory. - IMPORTANT - You must run the program TXM-CFG.EXE ! This converts the text file into a data structure format that TXM can understand. TXM-CFG.EXE does a certain amount of error checking on the data that you entered, and will catch badly out of range paramet- ers and the like. The output of TXM-CFG.EXE is a file called TXM-CFG- .DAT. It will not be possible for you to directly do anything with TXM-CFG.DAT as it is there for the exclusive use of TXM.EXE - IMPORTANT - Any time you make changes in the text file TXM.CFG.CTL you must re-run TXM-CFG.EXE and recompile the text file to create the object file TXM-CFG.DAT ! RUNNING TXM.EXE --------------- TXM is designed to run from the DOS working directory. For example if you have created the directory C:\TXM and that is where all the TXM files are then do this: C:\ cd\txm <---change to working directory here! txm mailer-off and txm should begin to run. TXM uses several command line parameters that let you select modes of program operation. They are: TXM MAILER-OFF -Disables all mailer and forwarding functions. TXM MAILER-ON -Enables mailer functions on ports 2 and port 3. TXM MAILER3-OFF -Enables mailer function on port 2 only. TXM MAILER-ONLY -Disables BBS Link Function TO EXIT TXM FROM THE CONSOLE PRESS THE KEYS ALT X ... and the program will save its TXM.LOG file, reset the attached hardware, free memory in the machine, close the com ports, and return you to the DOS environment. It is poor practice to exit any program, TXM included by doing soft resets, or turning off the machine. In the case of TXM, doing so will result in loss of the data in the TXM.LOG file, and the TXM-HIST.DAT file. While TXM is running the following keyboard commands are available to the SYSOP: 1. ALT X - Quits the program 2. ALT B - Forces a Beacon to be broadcast. 3. ALT L - Toggles disk logging ON/OFF. 4. ALT R - Forces a reset of Modem and TNCs. 5. ALT M - Re intiializes the mailer and forwarding in TXM. 6. + - Adds 10 seconds to the beacon timer interval. 7. - - Subtracts 10 seconds from the beacon timer. A beacon timer of 00:00 stops all beacons from being transmitted. 8. ALT 1..6 - Forces a mailer session the numbered NETBBS. If you press the ESC key during certain event cycles then after the completion of that event TXM will fall back to its Idle State. This is useful for getting out of a gateway mailer connect if you need to direct TXM to another event or leave program operation. Pressing the ESC key with a User On-Line to the LLBBS will kill that Users session and log him off the LLBBS. Features that TXM Handles Automatically --------------------------------------- TXM.EXE has several features that it handles in an automatic fashion. When program operation begins it determines if there is enough space for 1000 lines of log left on your disk. If there is then it turns the disk logging function on automatically. As log space is used up during operations, TXM will turn off the disk logging function as disk space runs low. There is a presentation of the Time Idle and Time busy in window #1. TXM updates this time on a transition from busy to idle state. The relative percentage becomes more accurate the longer TXM is left running, however this time is only an approximation and is intended only as a general guide to system loading. If you operate TXM in Mailer-Only function then the system will not be sending any beacons and it changes the display in window #1 to reflect the fact that Beacons are OFF and the count down timer changes to a real time clock. Day to Day Running of TXM ------------------------- After you have TXM installed for the first time on your system, call into the packet station from a remote radio/TNC test site. If you do not have another radio/TNC yourself to do this testing with then have a friend call in to test the system. You should be in voice contact with the testing station, perhaps by two-meter repeater or over voice telco lines, so that you can coordinate the testing session and discuss any problems or bugs that may appear. It may take some amount of "tweaking" to get TXM to properly log on to your LLBBS software. Assure that you have set the Ham callers in your LLBBS control files to be passed to the system without passwords. There is little point on password protecting ham callers to the system as there is no practical way to "hide" such passwords from going out over the air. The reality is that anyone with a radio/TNC tuned to your user frequency can "listen in" and easily obtain any password used by the system. After you get your TXM system up and running you will want to keep in mind the following regarding the operation of TXM BBS Link Function: 1. Every night at 01:00 TXM will rename the days TXM.LOG file to todays' date and append the extension ".LOG", i.e "09-10-91.LOG", and create a LZH archive file called TXMLOG.LZH. If the archive already exists the date-named log file will be added to the archive. TXM logs can quickly become huge on an active system, so this conserves space, and also keeps every days log organized in a neat and consistent manner. 2. Download the TXMLOG.LZH file from time to time and examine it for any problems that might be recorded in the log. The mechanics of doing this download are explained in detail further along in this documenta- tion under "Running The Remote Terminal". 3. Keep the TXM-USER.CTL file updated. You can get new callsigns to put in the list from information on Guest Ham Log Ons in the TXM.LOG file or obtain these callsigns from friends that have requested that you give them access to the system. We always put the Name of a Contact SYSOP in the LOGOFF.TXT file along with a 2 meter Voice Repeater frequency that a Guest Ham can call to request that he be put on the TXM-USER.CTL as a regular user, or ask any questions abut system operation. You may upload TXM-USER.CTL files using the Remote Terminal described later in the documentation. 4. Keep the LOGON.TXT, LOGOFF.TXT, Hour Files, and BEACON.TXT files updated with timely and current information. 5. The Third Window on TXMs screen called "Data Stream" is intended as an observation window only of ALL data into and out of the system. Therefore the window is a debugging tool, it is not intended as a user-friendly observation screen. With TXM systems that are running TXM Mailer Function as well as TXM BBS Link Function it can be quite a chore to make sense out of what you see there. TXM makes no attempt to format data that appears in this window. 6. Setting up the HOTKEY argument - Some LLBBS software uses so-called HOTKEYS. This means that the user of the LLBBS just has to press a Key in response to a prompt and the action is immediate on the part of the LLBBS. No is necessary to get the action response. This situation creates all sorts of bad side effects in the packet to LLBBS inter- face, because typical TNCs are set up to only send a packet with a terminating which is passed through when the TNC user presses the to force a send on the packet. If the TNC user on your TXM system has his TNC set up to send out any data at a very low pactime threshold like 10 miliseconds or so and he has cpactime ON or what ever other parameters is required to enable packet sends without a terminating then the Hot Key situation is no problem for the TNC user. However, most TNCs are configured to only send a packet if they have some amount of data waiting, typically 128 bytes, OR if the TNC user pressed the terminating character, which is typically the . There are various solutions here. One is to have the TNC user recon- figure his TNC to pactime 1 and enable direct packet sends in what ever mode he attached to your TXM system in. This is not a good solution, because most TNC users are unwilling to reconfigure their TNCs just for one system. The other solution is to have the TNC user reconfigure his TNC to use a character other than to terminate and force a packet send. This solutions has problems as the first one. The only workable solution seems to be to have TXM process the data stream and trap out any s. The only drawback here is that what if the user needs to send a ? If TXM has trapped them all out then one can never get through! Well we have set up TXM to pass one if it is immediately followed by an other . This means if the user wants to send a to the system he just taps the Enter Key Twice in quick succession. Most users of the system seem to be able to deal with this situation. The feature is enabled by using the HOTKEY "YES" statement in the TXM-CFG.CTL file. If you do not want TXM to strip the s then use the HOTKEY "NO" statement. It will be up to you to experiment with these settings and determine which method is best for your particular requirements. Understanding the TXM-USER.CTL file --------------------------------- The TXM-USER.CTL file gives the SYSOP control over who has access to the system. If you want callers unknown to the system to be passed through to your LLBBS as "GUEST HAM" then the argument to GUEST_HAM in the TXM-CFG.CTL file should be "YES". If not then the argument should be "NO". Beyond the "YES" or "NO" of the GUEST_HAM command you have further control options in the TXM-USER.CTL file. You can make these control options active for any specific ham in the file. You can decide if any given call sign should be allowed to access the system. The TXM-USER.CTL file is created by you with a text editor. Each line in the file represents ONE ham callsign and the callsign MUST be the First Word on the line. Callsigns included in the TXM- USER.CTL file will be automatically logged onto the LLBBS system by TXM. Note that TXM.EXE holds the TXM-USER.CTL file in memory, so if you change the content of this file you MUST exit TXM and then restart the system to reload a new copy of the file into memory. With this release of TXM you are limited to 100 each entries in the TXM-USER.CTL file. Anywhere on a give line, following the callsign may be any comments you like concerning that callsign. Additionally and line preceded by a ; is a comment line and will be disregarded by TXM. Also anywhere on a given line may be any combination of active commands that control attributes that will be connected to that call sign. The attribute commands are: DIGI-OK DIGI-NO ------- TXM determines if someone is trying to log onto the system via a digi by the string returned to TXM by the TNC which will say "VIA" if the connect is through a digipeater. TXM uses the fact that node software rotates anyones call sign out of the node by CALLSIGN"N"-15(-1) , meaning that the node attaches a numeric extension to anyone using the node and subtracts the numeric digit ONE (1) from wherever the caller falls in the set [1..15]. TXM looks for this numeric extension and determines from that if the caller is using a node. Operation of a LLBBS via TXM through Nodes or Digis seriously degrades the overall system performance, and it is my opinion that the practice of accessing TXM systems via Digis or Nodes should be discouraged. Therefore TXM defaults to "DIGI-NO".. If you want to allow a caller access to your system via Digi or Node then you must explicitly set "DIGI-OK" somewhere on their line in the CALLER.LST file. The paramenter for "DIGI-OK" in the TXM-CFG.CTL file will globally override the digi toggles in the TXM-USER.CTL file. KILL! ----- TXM will immediately disconnect any callsign that connects to the system if you have instructed it to. This is one way to deal with the rare troublesome caller that is bound to show up on your system sooner or later. The following is an Example TXM-USER.LST file. Note the extensive use comments on each line to hold information about the system user. ; ; MY CALLERS to the SYSTEM last updated 10/01/91 ; ---------------------------------------------- W6PLS ... from Guest Ham 8/4/91 W6IEG Chuck WA6SDR dick Yosemite lakes WA6YAB Lee/FRESNO BEAM FROM SHAW&WEST WJ6ERK KILL! - wow! what an idiot! once on the system was enough! WB7UGZ 8-28-92 ..from guest ham list, this is Rick of 441.350 WD6GFF Richard WU6I DAVE/DOS PALOS WY6B 8-28-91 ..from guest ham list N6LDG Ricard Scott (Madera Rancho's) N6OCX 8-10-91 from guest ham list K6LAC 8-30-91 ..from guest ham list K6RAU Fred KC6MKA John???? KC6QJO DIGI-OK Tony KC6TVK DIGI-OK John ; ;...................end of the TXM-USER.CTL file........... ; Running the Remote Operator Terminal ----------------------------------- TXM provides a remote operator terminal for doing basic maintence on the system from a remote location. If you dial back into the system on TXMs phone modem using a standard terminal program like Telix or Procomm, and enter your password you will be shown the following Menu: TXM does not echo characters back to the screen. Set your terminal program to ECHO ON. ------------------->>>>choose one<<<<<-------------- A- Z-Modem Download a File. B- Z-Modem Upload a File. C- Leave Remote and Re-Boot. D- Leave Remote NO Re-Boot. E- Set Time. F- Set Date. G- Erase TXMLOG.LZH. H- ...reserved............. I- See Current Stats. J- Set Beacon Interval --------------- TxM v1.50, REV:12.01.91 ---------- A - B ------ You may Upload or Download files to the system. This would include the CALLER.LST file as well as all the text files like BEACON.TXT, and the Hour Files. You can even upload a new copy of the TXM.EXE software when there is a new release without going to the remote transmitter site! You will need a terminal program like Telix or Procomm that supports Z-modem to transfer files. C - D ----- After operating the terminal you may leave without rebooting the system or you may have TXM do a soft reset on the system. If you use this option MAKE SURE that you are operating TXM within a Autoexec.Bat file that will reload TXM.EXE. Additionally please note that TXM.EXE holds the CALLER.LST file and the BEACON.TXT file in memory, so if you upload either of those files you MUST reboot the system to reload the new copy of these files into memory. Other text files, like the LOGON.TXT, LOGOFF.TXT, Hour Files, and the like are retrieved off of disk as needed during program operation. E - F ----- These functions allow you to set system time and date. G - H ----- After you download the TXMLOG.LZH file you can choose to erase the file off of disk to conserve space.. At this time H is not used. I - J ----- Pressing I shows you a one page screen with current system status information. J allows you to change the Beacon Interval timer. GETTING TXM FIDO MAILER INTERFACE FUNCTION RUNNING ------------------------------------------- IMPORTANT! The mailer functions are divided into two distinct groups with two distinct types of functionality. One function group is the Fido Mailer Interface. The other is the Forwarding and LZH functions. This part of the documentation will discuss the Fido Interface functions, then the Forwarding and LZH functions will be covered later under a separate heading. Since each of these groups operate independently in TXM it is not necessary to set up both to have the functionality of only one if you require only one. In other words if you do not need or want to be involved with porting the messages from TXM to your LLBBS via the Fido transfer layer protocol, but you DO want the Forwarding then just skip the Fido Mailer set up, and move directly to the forwarding set up documentation. Fido Mailer Functions: ---------------------- If you are not going to use TXM in its Fido Mailer Function you may skip this part of the documentation. However, if you are going to use TXM Mailer Functions then: READ AND UNDERSTAND THIS ENTIRE SECTION OF THE MANUAL FIRST BEFORE YOU BEGIN INSTALLATION ! First assure that your modems and TNC have been configured as outlined in the previous headings regarding hardware set up. Transfer the all files to their directories. Pay particular attention to placing the correct file on the proper machine. For running the Link Functions some of the files for TXM must be on your LLBBS machine! You will need all the normal Fido support programs normally associated with a BBS system running Echo mail. This includes at the very least a message tosser like Qmail that can place *.MSG files into directories and a Fido tosser that can handle *.PKT Fido format packed message files that will be created by TXM-TOSS.EXE. That tosser will be responsible for merging the TXM-MAIL.PKT files created by TXM-TOSS.EXE into your LLBBS message bases. It is your responsibility to assure that your Fido system is running smoothly BEFORE you attempt to integrate TXM Mailer Functions into the system. Adding TXM mailer functions to a buggy Fido system will result in unrecoverable confusion. Connect your radios and TNC . Get your text editor running and locate the example TXM-CFG.CTL file. Use a text editor NOT a word processor. Save file in DOS text file format only. Go into the TXM-CFG.CTL file and change the parameters whose use affect the TXM mailer Function. To understand how to approach these changes carefully read the appendix to this documentation "TXM-CFG.CTL File Documentation" Each command and its argument are described in that document. Again, we are assuming that you already understand the nature of a Fido Store and Forward System and understand the meaning of standard Fido jargon and further that you have some background in writing batch processing files in the DOS environment. Create the file TXM-FWRD.CTL with your test editor. If you are not going to use the TXM Forwarding Function as described in the next section of the documentation, then this file will be empty or all the information in it commented out by using the ";" at the start of each line, HOWEVER TXM will expect to see this file on disk, even though you may not be using it for your Fido Mailer operations. Create THREE separate message bases on your LLBBS. One will hold messages for Packet Bulletin Messages; one will hold messages for Packet Private Messages; one will hold messages for Packet NTS Traffic. Set these message bases up as normal Echo mail Conferences just as if you were getting these areas from your Host, BUT show the Fido HOST system as a kuldge Fido Address (see the discussion further down under SEEN-BY for complete details on this kludge address) A little explanation or system overview is in order here. You must understand this overview, as you will now put on your hat as System Designer and begin the process of getting your two machines working in concert to store and forward mail! Your system will be changed and redesigned by you from the generic description that follows so your system will be different than what I describe based in part on what LLBBS software you have, how much of its Fido message handling functionality is vertically integrated, and a myriad of other factors. It will be up to you to understand all the factors that come into play. This is not a cook-book explanation. Because of the dozens of different Fido software packages out there no cook-book approach is possible. I will try and make this brief, and I understand that the flow may be difficult to follow in your head. I strongly recommend that you chart out your system flow with pencil and paper. This has two important benefits. First you will gain an understanding of how you want to lay out your system much faster, and second, you can save this paper work for later reference. Fido store and forward batch files and message flow quickly become so complex that if you try to go back to the system some months later to repair or add features it is a certainty that you will have forgotten in the interim how the system was constructed. A working layout drawing can be an invaluable aid to you some months down the road. First TXM Fido Mailer Functionality is not the result of one single program, but rather results from several layers of software operating over a shifted time domain. For its part, TXM provides you with three programs that fit into this puzzle. First TXM.EXE provides the data link to the gateway System that feeds West Net for mail into and out of the world of packet radio. TXM.EXE handles the handshaking and protocol expected of an automated BBS connection into the packet system. In order for you to bring an automated BBS Link online you must have the cooperation of the person that handles the backbone packet system in your area. Tell him that you have a PBBS system and you want to establish a feed. TXM.EXE deals with mail in two formats. Messages going into TXM.EXE are in the Fido Standard *.MSG format. DO NOT set your system up to transfer Fido *.PKT format message bundles into the *_OUT_DIRs ! The reason we use *.MSG files here will be explained when we talk about TXM-LINK.EXE and has to do with the FCC rules regarding packet message review by the SYSOP. *.MSG format is a byte length encoded header format with each message content in a separate file. These files are transferred into the directory on the TXM machine pointed to by the TXM_OUT_DIR argument. They remain there until a mailer session is established with your gateway system. At that time TXM.EXE translates them to West Net Packet format, creates the necessary headers for that system and attempts to feed the messages one at a time into the system. Messages successfully accepted and transferred to the gateway are erased from the directory on which they were stored. TXM.EXE accepts messages from the packet gateway station into its directory that is pointed to by the argument of TXM_IN_DIR. It stores each incoming message there in a separate file. The store format is West Net Format as delivered to the TXM system by the gateway. The files are stored there until a transfer session is established over the TXM system modem by the TXM-LINK.EXE program. At that time these files are dumped to the LLBBS Host system and erased from the direc- tory on the TXM machine. - IMPORTANT - TXM.EXE manages its inbound and outbound directories on its own. DO NOT rename files there unless you understand exactly what you are doing! We use file extension names and other "filename notation" to internally manage the flow of files into and out of the system. Renaming files, adding or copying files into and out of these self-managed directories can have disastrous consequences. For the most part when you exit TXM.EXE and look at these directories they should be empty. This is as it should be if TXM.EXE is working properly and cleaning up after itself as it goes along. There are user selectable parameters for establishing a connect to your gateway system. Sometimes you need to go via a digi or two to get to the gateway. TXM.EXE provides the functionality to use two digis and then request connect to the gateway BBS as the third connect name as pointed to by the argument for NETBBS[1..6]_NAME. If you can connect directly to your gateway system or need only one digi connect just leave the first and/or second name arguments blank like this : NETBBS[1..6]_DIGI_1_NAME " " using a space character between the " ". The name of the final gateway BBS system should ALWAYS be the argument to NETBBS[1..6]_NAME !!! Never leave this argument Blank! TXM will support the use of Digipeaters in the NETBBS1..6_DIGI fields. See the Example TXM-CFG.CTL file provided with this archive that gives examples of how to accomplish this. TXM-LINK.EXE ------------ For the second program that TXM brings to the party we have TXM-LINK.- EXE. The purpose of TXM-LINK.EXE is to establish a data path between the remote TXM machine and the LLBBS machine. The functionality of TXM-LINK.EXE as it relates to the TXM remote was discussed above. On the LLBBS end TXM-LINK.EXE works with the directory pointed to by the argument of INBOUND_DIR and the directories pointed to by the argu- ments of P_OUT_DIR B_OUT_DIR T_OUT_DIR. West Net Message format files will be placed onto the LLBBS IN- BOUND_DIR by TXM-LINK.EXE. TXM-LINK will look into the *_OUT_DIRS and if there is any messages waiting there to be delivered to the remote TXM system for subsequent delivery to the gateway TXM-LINK.EXE will handle that transfer and then erase them from the *_OUT_DIR. Note that TXM-LINK.EXE needs to be able find the TXM-CFG.DAT file as created by TXM-CFG.EXE. TXM-LINK.EXE should have its own copy of this file on whatever default directory you are operating it from. TXM-TOSS.EXE ------------ For the third program we have TXM-TOSS.EXE. This is the real work horse that provides the compatibility between the worlds of packet messages and Fido messages. TXM-TOSS.EXE looks into the INBOUND_DIR and if it finds messages there it translates them into a Fido *.PKT format bundle and tosses that bundle (which is always called TXM-MAIL- .PKT) into the directory pointed to by the argument of TOSS_TO_DIR It is your responsibility to run what ever Fido mail processing software you have that further processes the TXM-MAIL.PKT into your message base on your LLBBS after TXM-TOSS.EXE lands the TXM-MAIL.PKT there. This must be done before a new TXM- TOSS cycle begins. See discussion on time Domain a little further along in this documenta- tion. Fido message technical standards require several features that are not a part the packet world. There are several parameters that deal with establishing these features. Lets look at each one in turn: LLORIGIN -------- This is the text that will be on the origin line incoming to the message base. You can call it anything you want, but probably give it the name of the main packet system that you are attached to. SEEN_BY ------- Fido Net Standards require that messages must be delivered to and received from valid Fido Net Addresses. This is the major control feature that Fido uses to drive the intelligence that determines how to route mail through the system. Without it Fido becomes stupid and can not figure out what to do with messages it finds in its system. Incoming messages from your TXM system will be addressed to your Fido Net address, whatever that might, be as listed in the Fido Net Node List. OK so that part is simple: Put Your Fido NET/NODE Address in as one of the arguments to SEEN_BY. Next we have to give your TXM system a Fido Address. Remember we are going to have your normal Fido mail scanner program (what ever that might be) scan the three message bases you are going to create for packet mail and deliver them to the AREAS: directories. In order to do that you have to tell your scanner software (in your AREAS.BBS file or equivalent) what the Fido address is of the remote TXM system. TXM_NET TXM_NODE ---------- Next make up a kludge Fido NET/NODE address for your remote TXM system. Commonly in Fido systems kludge addresses carry the node # 999. As an example I used 121/999 for my TXM address. - IMPORTANT ! - You MUST put that address into your Nodelist compiler if your scanner software requires all Fido addresses it finds to be valid vs a check against the Nodelist! There are many techniques for doing this, some nodelist compiler software such as XLAX allow you to integrate a user file of your creation into a regular weekly run of the NODEDIFF compiler. You are on your own to figure out how to accomplish this task. Put the NET number in as the argument to TXM_NET and the node number in as the arguments to TXM_NODE. YOUR_NET YOUR_NODE ---------- Next make up a kludge Fido NET/NODE address for your LLBBS system, or if you have a current listing in the Fido Network then use your assigned Fido NET/NODE number. If you need to kludge your own LLBBS NET/NODE number then remember that commonly in Fido systems kludge addresses carry the node # 999. As an example I used 121/999 for my TXM address. - IMPORTANT ! - You MUST put that address into your Nodelist compiler if your scanner software requires all Fido addresses it finds to be valid vs a check against the Nodelist! There are many techniques for doing this, some nodelist compiler software such as XLAX allow you to integrate a user file of your creation into a regular weekly run of the NODEDIFF compiler. You are on your own to figure out how to accomplish this task. Put the NET number in as the argument to YOUR_NET and the node number in as the arguments to YOUR_NODE. LLAREA_BLT LLAREA_PVT LLAREA_NTS ---------- These arguments are the names of the AREAS for your packet message bases on your LLBBS system. They MUST BE identical to the message areas as they appear in your AREAS.BBS file! Case sensitivity is a feature of much Fido scanning and tossing software so make sure you have shown the messages base names in your AREAS.BBS file in UPPER CASE because TXM-CFG.EXE will convert these names to upper case. WHY IS SOME OF THE SYSTEM USING *.MSG FILES AND SOME USING *.PKT FILES ? and other Warnings ----------------------------------------------- Some sharp and well experienced Fido operators will have by this time spotted an inconsistency in the design of the TXM Mailer Function. We are using *.MSG files on the outgoing side of the system and *.PKT format bundles on the incoming side. Why is this? Well, the FCC has said that all messages going out of a PBBS must be reviewed by the SYSOP. Since *.MSG files are one file per one message and in more or less ASCII readable format you can easily read the outgoing messages in your *_OUT_DIRs with either a text editor or with a tool like PCTOOLS Edit function. Then if you don't like the looks of it you can just zap it from the system by deleting it! If it had been bundled into a *.PKT bundle then you would have no way to zap it because the format of a *.PKT is too complex to edit. As far as the incoming *.PKT if you don't like any of those messages you can use the normal delete function available in all LLBBS software to deal with offensive messages. While we are on the subject of Warnings and so forth I want to make a statement here regards responsible operation of gateway capable systems in networked mail environments. Obviously, TXM could be used to cross gateway packet nets and Fido nets into and out of each other. In the world of computer networked mail systems such moves have emotionally charged political consequences. Ask anyone who has hung around UseNet for a while and you can hear the horror stories of past fiascoes when certain groups of differing personalities have been mixed via this type of gatewaying. In any event HEED THIS WARNING: NEVER TAKE IT UPON YOURSELF TO CROSS-GATEWAY TWO NETWORK SYSTEMS WITHOUT THE EXPRESS PERMISSION OF THE MODERATORS OF THE TWO CONFEREN- CES! ANYONE CROSS-GATEWAYING BETWEEN SYSTEMS, PARTICULARLY PACKET <-> FIDO LINKS, IS ASKING FOR SEVERE TROUBLE. LEAVE THIS TYPE OF ACTIVITY TO THOSE THAT ARE AT THE VERY HIGHEST LEVEL OF SYSTEM SUPERVISION. NEVER ATTEMPT CROSS-GATEWAYING FROM A PBBS SYSTEM SUCH AS A TXM MAILER OPERATION ! TIME DOMAIN and BATCH FILES FOR TXM MAILER FUNCTIONS ---------------------------------------------------- Proper operation of TXM Fido Mailer Functions require an awareness of the time domain nature of system operations. Although it is conceivable that one could run each program and function of a TXM Mail System in a stand alone manner, the reality is that in order to keep the system running smoothly you need to drive the system from a batch file and then drive the batch file from a time aware program like Binkley Term to force certain features of system operation at pre-arranged times. It is up to you to obtain the necessary software to provide the time driven nature of such a system. In many cases your existing LLBBS software has such timer features built into it. All Fido front end mailers such as Binkley Term, Front Door, and TIMS have a rich set of time drivers available. When constructing the batch files that control the operation of the TXM Mailer Functions keep in mind the following sequence of events that MUST be adhered to. Because TXM assumes that you will be keeping up with the flow of messages into and out of the system it is essen- tial that you have this flow working properly. If not then TXM will "choke" after 100 messages pile up in each of the AREAS.BBS direc- tories. Actually what will happen is simply that TXM will begin to overwrite the earlier files that have not been processed off the system. The batch processing flow for TXM Mailer Function must be as follows: TIME DELAY PROCESS -------------|-------|---------------------------------------- :00 - Run - LLBBS Message Scan Software :01 None Run - QMail, toss *.MSG file to *_OUT_DIRs :02 15 Manual SYSOP review of Outbound *.MSGs :15 None Run - TXM-LINK.EXE :30 15 Run - TXM-TOSS.EXE :31 None Run - LLBBS *.PKT tosser to message base :45 15 Manual - SYSOP review of Incoming messages 03:00 3HRS Run - TXM.EXE Mailer session with Gateway 03:01 None Return to Top - Repeat cycle The above chart suggests example times for each event. There is considerable latitude to change the suggested timing, but the sequence MUST be adhered to. A 3 Hour cycle is suggested over all. Some gateway systems operate on as short as a 1 hour cycle time for pick up and delivery of mail into and out of the net. What is feasible to do in that circumstance is to allow TXM.EXE to poll the net every hour but only run the 3 Hour cycle suggested above as an "overlay process", so that you allow the inbound mail to "pile up" in the TXM holding pen at TXM_INBOUND_DIR. This should pose no problem in a 3 hour period, except in the rare cir- cumstance that your net is usually busy and more than 100 messages are inbound to you within the 3 Hour time period. After you begin on-air net operation take some time to observe the "flow" of messages from your net gateway and adjust your system timing parameters accordingly. Some nets have higher activity at certain times of the day and certain days of the week. You will get a "feel" for this flow and then can optimize your system to it. Considerable "tweaking" can be required to integrate your batch processing into the overall flow of the net. One caveat is in order here: As anyone knows that has observed any type of distributed que-star-backbone operation (whether that be your local telephone company or the interstate free- way that goes through your town, all of which operate with the same basic paradigm) it is a fact that such systems can and do "grid-lock" under unusually high system loading. Be smart about that and plan for it in advance. Don't cut your system optimization too close, or better yet write an alternate batch file that you can load in when system conditions warrant. The following is a shortened and edited example of a typical batch file that drives a TXM mailer cycle. In this example the Exit error levels are provided in the Dos environment by Binkley Term software. Note that the batch at :scanhold (Exit error level 90) is run by Binkley Term every 3 Hours and provides the functionality outlined in the discussion above. Also note that in this example the Fido PKT 007903EF.PKT that is created directly by the Tmail LLBBS scanner software is "picked" from the normal LLBBS outbound directory for regular Fido Mail and placed in the PAKET_IN directory where Qmail further process it into its component *.MSG files for examination by the SYSOP and further processing by TXM-LINK.EXE rem ------------------------------------------------ rem BinkleyTerm 2.40, RUN.bat, rem 205/45 REV09/02/91 ...w/ tmail & TXM rem ------------------------------------------------ echo on c: set tbbspath=c:\tbbs set \binkley=c:\tbbs set tz=pst7pdt path=d:\;d:\tpe :more rem run again, errorlevels cd \tbbs tbbsdvr tbbs /r /m if errorlevel 255 goto end if errorlevel 200 goto inbound if errorlevel 100 goto pickupTNC if errorlevel 90 goto scanhold if errorlevel 80 goto aftermorningrun if errorlevel 70 goto morningrun if errorlevel 60 goto midnightrun if errorlevel 50 goto startNMH if errorlevel 40 goto stopNMH if errorlevel 30 goto inbound if errorlevel 22 goto more if errorlevel 21 goto killmail if errorlevel 20 goto inbound rem if errorlevel 10 goto more if errorlevel 2 goto rebootit if errorlevel 1 goto end :inbound rem sort and process mail (F2) polyxarc -f c:\tbbs\inbound tmail -t -d goto more :local goto more :pickupTNC txm-link cd\paket_in txm-toss cd\tbbs tmail -t -d goto more :morningrun rem (F7) tmail -s copy c:\tbbs\outbound\007903E7.* c:\paket_in\*.pkt del c:\tbbs\outbound\007903E7.* cd\paket_in qm toss cd\tbbs txm-link cd\paket_in txm-toss cd\tbbs tmail -t -d ommm.exe -z1 -cC:\tbbs\ommm.ctl -hC:\tbbs\outbound -iC:\tbbs\binkl- ey.prm -mC:\tbbs\working.tmp -a -sE goto more :aftermorningrun rem (F8) txm-link cd\paket_in txm-toss cd\tbbs tmail -t -d tmlink tick >> c:\tbbs\inbound\binkley.log goto more :killmail killmail mail.ctl >> c:\tbbs\inbound\binkley.log mfsqz < autosqz copy c:\tbbs\*.bak f:\ del c:\tbbs\*.bak goto more (..........batch file continues.. abridged for example here......) Day to Day Running TXM Fido Mailer Function ---------------------------------------- Once you have your batch files set up and debugged the TXM Mailer Function should run in un-attended operation and require little or no maintenance. If you want to force a mailer session from the keyboard use the keys "ALT-1..6" and TXM will begin a gateway connect session. If you press the ESC key during certain event cycles then after the completion of that event TXM will fall back to its Idle State. This is useful for getting out of a gateway mailer connect if you need to direct TXM to another event or leave program operation. You have the capability to select what hours you want TXM to poll the gateway. See the TXM-CFG.CTL Documentation for details. Some gateways require that you poll them at an offset from the start of the hour. If this is the case with your gateway then user the POLL_OFFSET function. If you want TXM to attempt to connect to your gateways whenever it has mail to deliver then user the RANDOM_TRIES function which will cause TXM to be very "insistent" about delivering the mail to its gateways. When TXM.EXE is operated in the Mailer Function mode it listens to the data stream on port 2 and port 3 (if enabled) and waits for a *** CONNECT by your gateway station. If it connects to a gateway initiated session the computer will emit a pleasant series of beeping tones to alert you that your gateway has attached itself to your system. Then TXM will handshake with the gateway and begin a normal or LZH mailer session, passing any outgoing mail to the gateway and receiving inbound mail for your system. TXM.EXE maintains a history stack in memory of the last 1000 messages that passed into the system from the gateway. If the gateway attempts to resend a previous message then TXM will reject the message from the gateway with a NO response to the incoming mail message. There is a quirk of operation of this "history stack". There doesn't seem to be a consensus in the packet world about how the message ID should be handled. Some PBBS software does not put message ID strings on Private and NTS mail messages. All PBBS systems puts it on Bul- letins. Some systems make up there own kludge strings and attach them to Private and NTS messages. So at this time TXM takes the safe route and accepts ALL incoming Private and NTS messages WITHOUT IDs, even if some of those messages may be duplicates. TXM only compares the incoming message to the history stack for messages that have an ID, and it will ONLY reject messages that are duplicates based on that ID supplied by the sending station. TXM will attach kludge ID to any mail that has passed-thru it from another station if TXM received that message without an ID. If everything is working correctly both the inbound and outbound directories on the TXM system should be empty. GETTING TXM FORWARDING RUNNING ------------------------------------- IMPORTANT! The mailer functions are divided into two distinct groups with two distinct types of functionality. One function group is the Fido Mailer Interface. The other is the Forwarding and LZH functions. This part of the documentation will discuss the Mailer/Forwarding and LZH functions, the Fido Mailer Functions were covered previously under a separate heading. Since each of these groups operate independently in TXM it is not necessary to set up both to have the functionality of only one if you require only one. In other words if you do not need or want to be involved with Forwarding but you do want to port the messages from TXM to your LLBBS via the Fido transfer layer protocol, then just skip this Forwarding set up, and go directly back to the Fido Mailer Interface set up documentation. This documentation is not a tutorial on PBBS forwarding techniques. Please refer to your local area PBBS operators for guidance on how to construct the flow of messages in your local PBBS network. To enable forwarding on TXM you must create the file TXM-FWRD.CTL with your text editor. A sample file is enclosed with this archive. Additionally you must create a pass-thru area which is defined on your disk as the argument to TXM_PASS_DIR. The directories which are the arguments to TXM_OUT_DIR and TXM_IN_DIR must also exist on your disk and be defined in the TXM-CFG.CTL file. Those directories and their use are discussed in the section on Fido Function Interface. Besides the uses they serve for the Fido Interface, the Forwarding and LZH Function also needs to use these directories. -IMPORTANT!- TXM does not check that you have the directories in place on your disk. It is your responsibility to assure that the names as used in the arguments to the parameters in the TXM-CFG.CTL file actually exist on your disk. -IMPORTANT!- A Hard Disk is REQUIRED to run the Mail Forwarding and LZH features of TXM. TXM handles the messages in a very disk intensive manner, including making backup copies of all messages before tranfer- ing them to the passthru areas. This takes more time, but with a fast Hard Disk it is worth the benifits. The benifit is that TXM is impervious to system crashes as it effects its message routing. All message traffic and forwarding and routing information can be reconst- ructed by TXM at anytime, even in the event of a full system crash or power outage. All that is necessary to recover is to start TXM running again and it will rebuild its route state from the messages on disk. Although ISAM managers are faster and less disk intensive than the methods used by TXM, it was decided that message integrety was the highest priority in the system design and the slight loss of time during disk operations was worth the benifits. It is suggested that you run CHKDSK /F from time to time on your hard Disk and that you run utilities like PCTOOLS COMPRESS and SPINRITE as part of a responsible regular preventative maintenance program on your Hard Disks. Understanding the TXM-FWRD.CTL File: ------------------------------------ The arguments to the parameter DELIVER_TO is the name of one of the NETBBS[1..6]_NAME that you have specified in the TXM-CFG.CTL file. The argument to DELIVER_TO is the NETBBS[1..6]_NAME stripped of and "CONNECT" or "VIA" characters, i.e if you have in your TXM-CFG.CTL file the following line: NETBBS4_NAME "c KM6HK" then you would use in the TXM-FWRD.CTL file: DELIVER_TO "KM6HK" The line composed of DELIVER_TO "SOMEBBSNAME" must be on a line by itself. All words following after that must be on a subsequent line, NOT ON THE SAME LINE AS THE *DELIVER_TO*, will be become "active words" and will be attached to the last BBS that you have said DELIVER_TO until you state another DELIVER_TO "SOMEOTHERBBS" or end the file. Active words MUST be separated from each other by one or more spaces. The active words following the DELIVER_TO may be in any order on any number of lines, in any quantity, and case is not important. For all practical purposes the amount of active words in the TXM-FWRD.CTL file is unlimited. Actually your computers memory is the limiting factor. TXM handles, stores, and searches the forwarding active words in a very sophisticated manner using hash-tables. It is lightening quick during mail sorts, and you should not be afraid to enter as many active words as your usage requires. System performance will not be degraded by hundreds or thousands of entries in the forwarding control file. IMPORTANT! You must spell the NETBBS[1..6]_NAME the same in the TXM- CFG.CTL file as you do in the TXM-FWRD.CTL file. You can not say, for example, in one file "c KM6HK-2" and use DELIVER_TO "KM6HK-3" on the other. OK would be "c KM6HK" and DELIVER_TO "KM6HK" The active words attached to a specific NETBBS_NAME as specified in the TXM_FWRD.CTL file control what messages TXM will pass to each NETBBS known to it. TXM will compare each of the active words to the header in the packet message. If it gets a "hit" or "match" it will route that message to that NETBBS_NAME. Some examples probably will serve to help you understand how this works: For example say you have the following lines in your TXM-FWRD.CTL file: DELIVER_TO "KM6HK" km6hk WB6ODZ k6rau w6gr N6yNo arrl ncpa amsat allusw allcan allca And a message comes thru your system with the header: "SB ALLUS @ W6GR-6 < K6XYZ $1234_N6XYZ" Will this message route to KM6HK? The answer is no. There is no match to any of the words in the header to the active words in the forward file. If the "-6" was dropped off of the @ callsign then it would be routed to KM6HK. If a "W" was added to the "ALLUS" then it would be routed to KM6HK. If you wanted to route all bulletins to KM6HK you could include the letter group "SB" in KM6HKs active words. Since the entire line is searched it would match the SB. TXM can find and understand words to be delimited by other than blank spaces so you don't have to worry about messages that come through the system like this: "SB ALLUS@W6GR" ..character expected from gateay BBS ; PASSWRD_LINK "84816" ..the password for TXM-LINK.EXE sessions ; INBOUND_DIR "C:\paket_in" LLBBS area to recieve mail from TXM ; TOSSTO_DIR "C:\TBBS" LLBBS area to Fido *.PKT processing ; P_OUT_DIR "C:\PAKET_P" LLBBS area for *.MSG outgoing mail ; B_OUT_DIR "C:\PAKET_B" LLBBS area for *.MSG outgoing mail ; T_OUT_DIR "C:\PAKET_T" LLBBS area for *.MSG outgoing mail ; TXM_OUT_DIR "C:\OUTBOUND" TXM area for mail going to the gateway ; TXM_IN_DIR "C:\INBOUND" TXM area for mail recd from the gateway ; TXM_PASS_DIR "C:\PASSTHRU" TXM Passthru mail Directory ; LLAREA_BLT "PACKET_B" AREAS.BBS dir on LLBBS for bulletins ; LLAREA_PVT "PACKET_P" AREAS.BBS dir on LLBBS for private mail ; LLAREA_NTS "PACKET_T" AREAS.BBS dir on LLBBS for NTS mail ; LLORIGIN "West Net Packet System" ..origin name for packet mail ; YOUR_NET "10" Your Address Net In the Fido System, or kludge ; YOUR_NODE "45" Your Address Node In the Fido System, or kludge ; TXM_NET "121" TXMs' Address Net In the Fido System, or kludge ; TXM_NODE "999" TXMs' Address Node In the Fido System, or kludge ; SEEN_BY "121/999 10/45" Fido systems that have seen the message ; MESSAGE_END "10/45)" ..end of message marker at Origin Line. ; TINY_PATH "YES" ...strip tossed R: headers to just a Callsign ; ; NETBBS1_DIGI1_NAME " " ..first digi/node in gateway NETBBS1_DIGI1_DELAY "0" ..number of seconds to wait for connect NETBBS1_DIGI2_NAME "c K6RAU-3" ..second digi/node in gateway NETBBS1_DIGI2_DELAY "60" ..number of seconds to wait for connect NETBBS1_NAME "c K6RAU" ..third digi/node in gateway NETBBS1_DELAY "60" ..number of seconds to wait for BBS NETBBS1_PORT "PORT_3" ..port to use for polling for Net Mail ; NETBBS2_DIGI1_NAME " " ..first digi/node in gateway NETBBS2_DIGI1_DELAY "0" ..number of seconds to wait for connect NETBBS2_DIGI2_NAME "c TXM" ..second digi/node in gateway NETBBS2_DIGI2_DELAY "60" ..number of seconds to wait for connect NETBBS2_NAME "c KA6BQT" ..third digi/node in gateway NETBBS2_DELAY "60" ..number of seconds to wait for BBS NETBBS2_PORT "PORT_2" ..port to use for polling for Net Mail ; ; NETBBS3_DIGI1_NAME " " ..first digi/node in gateway NETBBS3_DIGI1_DELAY "0" ..number of seconds to wait for connect NETBBS3_DIGI2_NAME "c txm " ..second digi/node in gateway NETBBS3_DIGI2_DELAY "60" ..number of seconds to wait for connect NETBBS3_NAME "c wb6odz " ..third digi/node in gateway NETBBS3_DELAY "60" ..number of seconds to wait for BBS NETBBS3_PORT "PORT_2 " ..port to use for polling for Net Mail ; ;..following is an Example of a VIA Digipeater connect to a gateway ; NETBBS4_DIGI1_NAME " " NETBBS4_DIGI1_DELAY "0" NETBBS4_DIGI2_NAME "c KC6QJO v GARLIC" < from data delivered to LL Modem Example : HOTKEY "YES" Comment : Use either "YES" or "NO" for the argument. Some LLBBS software use hotkeys. TNCs pass a CR in the data stream even though the CR may only be entered on the users terminal to force the TNC to create a packet. This presents a very difficult problem for either the LLBBS or the TXM software to analyze. Which one of the CRs is required vs which ones are just an artifact of TNC operation?Extraneous CRs confuse hotkey software. As a kludge solution if you use HOTKEY "YES" then TXM will strip any CR that is not proceeded by another CR. Therefore for the TNC user to pass an intentional CR he must press CR twice. See the detailed description of this function in the main documentation for further information. LLPHONE# -------------- Use : Required when using TXM Remote BBS Link Function Purpose : Phone number passed to TXM modem on Port 1 Example : LLPHONE# "661-5355" Comment : This is the phone number that TXM will call to put a packet use online with your LLBBS. TIMETO_CARRIER -------------- Use : Required for when using TXM-LINK.EXE and BBS Remote Purpose : Estabishes number of seconds to wait for modem carrier. Example : TIMETO_CARRIER "30" Comment : If TXM-LINK.EXE hangs up before establishing handshake then lengthen this time. Also this functions set the time to carrier wait when TXM dials the LLBBS for a PBBS user pass thru. TXMPHONE# -------------- Use : Required when using TXM Mailer Function Purpose : Phone number passed to TXM-LINK.EXE on LLBBS modem Example : TXMPHONE# "661-7748" Comment : This is the phone number that TXM-LINK will call to contact TXM and transfer mail during an uplink/down link session. PASSWRD_REMOTE -------------- Use : Argument Required for all TXM functions. Purpose : Password to secure TXM on remote operator sessions Example : PASSWRD_REMOTE "321YX" Comment : This is the password that you will give to TXM when calling in from a remote terminal to manage TXM via a telco line.Only the first five characters are significant and you may mix any printing letters, symbols, or numbers. The password must have at least 5 characters and not more than 10, only the first 5 are significant. -IMPORTANT!- All passwords used in TXM MUST be different from each other! Do NOT specify the same password on more than one password type. GUEST_HAM -------------- Use : Argument Required BBS Link function Purpose : Logs Unknown Callsign Connects on as "Guest Ham" Example : GUEST_HAM "YES" Comment : Use either "YES" or "NO" for the argument. If you want Hams that connect to TXMs remote TNC to be passed through to the LLBBS with the name "Guest Ham" then the argument should be "YES", otherwise "NO".If "NO" then they will be shown a "Denied access to the System" message and be disconnected from the TNC. If you allow "Guest Hams" then it is your responsibility to enter a dummy Guest Ham name in your LLBBS user file that is allowed access without a password. RAPID_LOGON -------------- Use : Require when using TXM BBS Link Functions Purpose : For Wildcat and similar type LLBBS software Example : RAPID_LOGON "NO" Comment : Use "YES or "NO". If you have a Wildcat LLBBS or other that allows the use of rapid logons of the form: * FirstName LastName Password then you may choose to use this feature. TXM will issue the string: * HAM TXM where HAM is a constant and is the first name, is the user callsign as logged on to the TXM node and TXM is a constant that you will use as the password in your LLBBS log. LL_PROMPT_1 -------------- Use : Argument Required BBS Link function Purpose : First Prompt issued by LLBBS at logon Example : LL_PROMPT_1 "10 seconds..." Comment : Your LLBBS will issue a prompt at log on when TXM dials its modem. Sometimes there are more than one stage in this log on sequence. The above example is typical if a Binkley front end mailer prompt. TXM will wait 20 seconds for this first prompt. LL_RESPONSE_1 -------------- Use : Argument Required BBS Link function Purpose : TXM response to first Prompt issued by LLBBS at logon Example : LL_RESPONSE_1 " " Comment : Your LLBBS will issue a prompt at log on when TXM dials its modem. Sometimes there are more than one stage in this log on sequence. This is the response to that prompt. In the above example we have left the argument blank. This is because TXM will automatically issue an ESC character after this argument, which is all we require in this case, as the example is a response to a Binkley Mailer where a ESC character response is appropriate. If you need a character response in additions to the ESC character then enter it as the argument. LL_PROMPT_2 -------------- Use : Argument Required BBS Link function Purpose : TXM response to first Prompt issued by LLBBS at logon Example : LL_PROMPT_2 "FULL Name?" Comment : Your LLBBS will issue a prompt at log on when TXM dials its modem. Sometimes there are more than one stage in this log on sequence.The above example is typical of a LLBBS prompt for the user to enter his name. TXM will always pass the users login callsign to the LLBBS AFTER it receives the argument to LL_PROMPT_2 and will follow that argument by a . It is your responsibility to assure that the user can be passed to the LLBBS without any further prompts or requests for passwords, as TXM will not handle any further prompts past the argument for LL_PROMPT_2. LOG_TO_DISK -------------- Use : Argument Required ALL TXM functions Purpose : Establishes disk logging. Example : LOG_TO_DISK "YES" Comment : Use "YES" or "NO" Turns Disk logging on or off globally. If set to YES you may turn disk logging off from the console by issuing a ALT-L keystroke. BEACON_EVERY -------------- Use : Argument Required for TXM BBS Link Function Purpose : Establishes Becon interval delay Example : BEACON_EVERY "00:09:50" Comment : If set to "00:00:00 Beacons are turned off. You may force a Beacon from the console at any time by issuing the ALT-B keystroke. MODEM_BAUD -------------- Use : Argument Required for TXM BBS Link Function Purpose : Establishes Modem Baud Rate for TXM to LLBBS Example : MODEM_BAUD "2400" Comment : Can be either "300" "1200" or "2400" =======================Following Commands are for===================== ======================TXM Mailer and LZH functions==================== YOUR_ADDRESS -------------- Use : Argument Required for all TXM Mailer functions. Purpose : Inserted into outgoing Mail for ID Purposes Example : YOUR_ADDRESS "KC6UEY.#NOCAL.CA.USA.NA" Comment : This is standard packet address for your station. This string is inserted into outbound mail and establishes the origin point for mail and shows in the mail headers so that the past path of messages can be established. Callsigns are required in this string. DO NOT use alias names. STATION_CALL -------------- Use : Argument Required for all TXM Mailer functions. Purpose : Callsign for gateway Mailer Handshakes Example : STATION_CALL "KC6UEY" Comment : This is your FCC callsign for the station. It is used during mailer handshakes with other packet stations to establish your station identity. DO NOT use alias names. POLL_OFFSET -------------- Use : Argument Required for all TXM Mailer functions. Purpose : Establishes offset from hour for Poll of gateway. Example : POLL_OFFSET "10" Comment : Argument in minutes. Range 0..59 RANDOM_TRIES -------------- Use : Argument Required for all TXM Mailer functions. Purpose : Should random retry gateway Connects? Example : RANDOM_TRIES "YES" Comment : Use "YES" or "NO" . If set to YES then if mail is waiting for delivery to a gateway TXM will pick a random number of minutes in ten minutes to retry the gateway connect. This has the result of TXM becoming very "insistent" about delivering the mail. See the documentation discussion about TXM-LZH for more information on the use of this feature. SESSION_TIMEOUT -------------- Use : Argument Required for all TXM Mailer functions. Purpose : Gateway session timeout disconnect Example : SESSION_TIMEOUT "00:50:00" Comment : A problem with some gateway connects is that their systems are overloaded using multitasking systems like MSYS and mail sessions can occur very slowly over protracted periods of time. This can "tie-up" your TXM system and interfere with LZH sessions and other schedules. Set this timer to the maximum time you want to allow a remote gateway to be attached to your system for mail transfers and if timer is exceeded, TXM will disconnect after the current message transfer in progress is completed. PROMPT_CHAR -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes prompt expected from gateway BBS Example : PROMPT_CHAR "=>" Comment : This is the character or character string expected from the gateway BBS. At this time there is only an informal standard in use by PBBS software and some are using ">" and some are using "=>".The only restriction that TXM places on this is that the string must be at least one character and less than two characters.Additionally, TXM assumes that the remote BBS wants this character sent TO it for prompt as well. Therefore PROMPT_CHAR is sent as well as received. PROMPT_DELAY -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Delay in seconds to wait for prompts from BBS Example : PROMPT_DELAY "300" Comment : This is the amount of time in seconds that will be allowed to wait for various prompts during a mailer session with your gateway. These prompts include waits for "SP, SB, ST OK, NO, =>, F>" during mail exchanges. Timeouts waiting for these prompts will result in aborting the current mailer session. SYNC_DELAY -------------- Use : Argument Required for TXM-LZH Mailer function Purpose : Establishes Delay in seconds for LZH Handshake Example : SYNC_DELAY "60" Comment : The use of this parameter is discussed in detail in the main documentation in the LZH Usage Section. Read that section to determine your setting of SYNC_DELAY MAXLZH_MSGS -------------- Use : Argument Required for TXM-LZH Mailer function Purpose : Establishes maximum number of Msgs in LZH Bundle Example : MAXLZH_MSGS "50" Comment : The range is 1..100 and determines the maximum number of message in an LZH mailer Bundle. If more than this number are waiting for delivery then TXM will "catch them on the next session". See the LZH documentation section for more informa- tion on this parameter. PASSWRD_LINK -------------- Use : Argument Required for all TXM functions. Purpose : Password to secure TXM on LINK sessions Example : PASSWRD_LINK "XY123" Comment : This is the password that TXM-LINK will use to gain access to TXM for mail uplink/downlink sessions. Although this argument may be left blank if you are not using TXM-LINK this is not good practice. Only the first five characters are significant and you may mix any printing letters, symbols, or numbers.The password must have at least 5 characters and not more than 10, only the first 5 are significant. -IMPORTANT!- All passwords used in TXM MUST be different from each other! Do NOT specify the same password on more than one password type. INBOUND_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Receiving Mail Area on LLBBS machine. Example : INBOUND_DIR "C:\PACKET\INBOUND" Comment : This is the path and directory on your LLBBS where mail will arrive from the remote system running TXM. It is from this directory that you will run TXM-TOSS.EXE to change packet format mail into Fido compatible *.PKTs'Mail will be placed into this Directory by TXM-LINK.EXE sessions. Mail will be removed from this Directory by TXM-TOSS.EXE which will convert this packet format mail to Fido *.PKT bundles. The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! TOSSTO_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Receiving Directory on LLBBS for Fido *.PKT Bundles Example : TOSSTO_DIR "C:\LLBBS" Comment : This is the path and directory on your LLBBS where TXM-TOSS.EXE will toss the Fido Format *.PKT files it creates for further processing by your LLBBS Fido mailer programs. You will direct your Fido Mail Tosser software to look into this directory for incoming PKTs. The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! P_OUT_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Outbound Mail Directory on LLBBS for *.MSG files Example : P_OUT_DIR "C:\PAKET_P" Comment : This is the path and directory on your LLBBS where your Fido mail processing software, such as Qmail, will place the outgoing *.MSG files that come from the Packet Mail Private Message Base.These are the messages that your message base scanning software will find in the PRIVATE PACKET area. This is one of the Directories that TXM-LINK.EXE will look to find outgoing mail for the Gateway. Files in this directory MUST be in Fido Standard *.MSG Format! The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! B_OUT_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Outbound Mail Directory on LLBBS for *.MSG files Example : B_OUT_DIR "C:\PAKET_B" Comment: This is the path and directory on your LLBBS where your Fido mail processing software, such as Qmail, will place the outgoing *.MSG files that come from the Packet Mail Bulletin Message Base.These are the messages that your message base scanning software will find in the BULLETIN PACKET area.This is one of the Directories that TXM-LINK.EX- Ewill look to find outgoing mail for the Gateway. Files in this directory MUST be in Fido Standard *.MSG Format! The path MUST NOT end in a "\" backslash and the length must be longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! T_OUT_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Outbound Mail Directory on LLBBS for *.MSG files Example : T_OUT_DIR "C:\PAKET_T" Comment: This is the path and directory on your LLBBS where your Fido mail processing software, such as Qmail, will place the outgoing *.MSG files that come from the Packet Mail NTS Message Base. These are the messages that your message base scanning software will find in the NTS PACKET area. This is one of the Directories that TXM-LINK.EXE will look to find outgoing mail for the Gateway. Files in this directory MUST be in Fido Standard *.MSG Format! The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! TXM_OUT_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Outbound Mail Directory on TXM Machine Example : TXM_OUT_DIR "C:\OUTBOUND" Comment : This is the path and directory on your TXM System for your mail received from the LLBBS by the TXM-LINK.EXE program will be stored until sent to the Gateway during a mailer session. The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! TXM_IN_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Inbound Mail Directory on TXM Machine Example : TXM_IN_DIR "C:\INBOUND" Comment : This is the path and directory on your TXM System for your mail received from the Gateway during a mailer session. The mail will remain in this Dir awaiting transfer to the LLBBS system during a call from TXM-LINK.EXE. The messages on this Directory are stored in WEST NET format. The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! TXM_PASS_DIR -------------- Use : Required when using TXM Mailer Functions Purpose : Establishes a Directory for Pass-thru messages Example : TXM_PASS_DIR "C:\PASSTHRU" Comment : This is the path and directory on your TXM System for mail received from a Gateway during a mailer session waiting passthru to another gateway system. The messages on this Directory are stored in WEST NET format. The path MUST NOT end in a "\" backslash and the length mustbe longer than 1 character and less than 50 character. NO checking is done to verify the path. It is YOUR responsibility to assure that the directory and path exist! LLAREA_BLT -------------- Use : Argument Required for TXM-TOSS Mailer function Purpose : Establishes AREA: identity for Bulletin Messages Example : LLAREA_BLT "PACKET_B" Comment : This argument MUST be the same string that you use in your AREAS.BBS file (or Equivalent file structure) for your Fido incoming mailer software. This string will be inserted by TXM-TOSS in the incoming messages that it changes from packet format to Fido *.PKT Bundles. It is this identity string that your Fido tosser will use to place the message into the correct message base area on your LL system. LLAREA_PVT -------------- Use : Argument Required for TXM-TOSS Mailer function Purpose : Establishes AREA: identity for Private Messages Example : LLAREA_PVT "PACKET_P" Comment : This argument MUST be the same string that you use in your AREAS.BBS file (or equivalent file structure) for your Fido incoming mailer software. This string will be inserted by TXM-TOSS in the incoming messages that it changes from packet format to Fido *.PKT Bundles. It is this identity string that your Fido tosser will use to place the message into the correct message base area on your LL system. LLAREA_NTS -------------- Use : Argument Required for TXM-TOSS Mailer function Purpose : Establishes AREA: identity for NTS Messages Example : LLAREA_NTS "PACKET_T" Comment : This argument MUST be the same string that you use in your AREAS.BBS file (or equivalent file structure) for your Fido incoming mailer software. This string will be inserted by TXM-TOSS in the incoming messages that it changes from packet format to Fido *.PKT Bundles. It is this identity string that your Fido tosser will use to place the message into the correct message base area on your LL system. LLORIGIN -------------- Use : Argument Required for TXM-TOSS Mailer function Purpose : Establishes *ORIGIN line text for incoming mail Example : LLORIGIN "West Net Packet System" Comment : Fido message standard require the * ORIGIN line be placed in each message. In order for your Fido mailer software to correctly handle the incoming mail it expects to see this origin line. Since this line is not a feature of packet mail you will have to establish this line. We suggest you give the origin line the name of the gateway system from which you receive you mail feed. YOUR_NET -------------- Use : Argument Required for TXM-TOSS/LINK Mailer function Purpose : Establishes Your Fido NET or kludge Example : YOUR_NET "10" Comment : See main documentation for details on establishing a kludge address if you do not have a Fido address. YOUR_NODE -------------- Use : Argument Required for TXM-TOSS/LINK Mailer function Purpose : Establishes Your Fido NODE or kludge Example : YOUR_NODE "45" Comment : See main documentation for details on establishing a kludge address if you do not have a Fido address. TXM_NET -------------- Use : Argument Required for TXM-TOSS/LINK Mailer function Purpose : Establishes TXM Machine Fido NET or kludge Example : TXM_NET "121" Comment : See main documentation for details on establishing a kludge address for your TXM Machine. TXM_NODE -------------- Use : Argument Required for TXM-TOSS/LINK Mailer function Purpose : Establishes Your Fido NET or kludge Example : TXM_NODE "999" Comment : See main documentation for details on establishing a kludge address for your TXM Machine. SEEN_BY -------------- Use : Argument Required for TXM-TOSS Mailer function Purpose : Establishes Fido nodes that have seen incoming mail Example : SEEN_BY "121/999 10/45" Comment : Fido message standard require the SEEN-BY line be placed in each message. In order for your Fido mailer software to correctly handle the incoming mail it expects to see this SEEN-BY line. Since this line is not a feature of packet mail you will have to establish this line. This line MUST at least specify your Fido Node AND the kludge node that you have given to your TXM remote system. This will prevent your Fido message scanner software from attempting to resend out packet mail via host routing to kludged Fido addresses and prevent TXM-TOSS from attempting to echo incoming mail back out into the packet system. MESSAGE_END -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes end of message marker Example : MESSAGE_END "10/45)" Comment : This should be the last few characters of the string that appears in your *ORIGIN line as created by your Fido Message scanner software. TXM uses this information to end the outgoing message at that point and not send out the SEENBY: and PATH: statements that are part of the Fido Protocol but not part of the West Net messaging system. TINY_PATH -------------- Use : Argument Required for TXM-TOSS function Purpose : Parses R: Headers to just the Callsigns Example : TINY_PATH "YES" Comment : Use "YES" or "NO". If YES then TXM-TOSS strips the R: headers in incoming packet messages to just the callsigns. This parameter has no effect on passthru messages or out bound mail into the Packet system where the R: lines are required. NOTE: ! ******************************************************************* The following parameters are repeated for a total of SIX (6) times to specify the various NETBBS systems that you TXM node will be aware of. The documentation uses the format "[1..6]" to indicate this, HOWEVER when you specify the parameter in your TXM-CFG.CTL file use just the numeral like this NETBBS3_NAME. See the example TXM-CFG.CTL file provided in this archive for details. Also see the Example TXM-CFG.CTL file for information on how to format one or more of the NETBBS areas for Digipeater Connects versus Node Connects. NETBBS[1..6]_DIGI1_NAME -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Connect to First link in gateway chain Example : NETBBS1_DIGI1_NAME "c W6AMT-10" Comment : Many routes to the mail backbone to pick up inbound and deliver your outgoing mail are routed via links to a digipeater, node or several digis or nodes. This is the name of the FIRST digi in such a chain. If there NO FIRST digi, in the chain then make the argument blank with ONE space like this: " " and TXM will not attempt to connect to NETBBS[1..6]_DIGI2_1_NAME. IMPORTANT! - The argument must be the complete connect string instruction to the TNC, including the "c" if necessary. Some node software will not require the "c", so we have therefore not hardwired it into TXM. If your node needs the "c" then you MUST include it in the argument. NETBBS[1..6]_DIGI1_DELAY -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Delay in seconds for Connect to First link Example : NETBBS4_DIGI1_DELAY "60" Comment : This is the amount of time in seconds that will be allowed to establish a link to NETBBS[1..6]_DIGI1_NAME. NETBBS[1..6]_DIGI2_NAME -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Connect to First link in gateway chain Example : NETBBS2_DIGI2_NAME "c GARLIC" Comment : Many routes to the mail backbone to pick up inbound and deliver your outgoing mail are routed via links to a digipeater, node or several digis or nodes. This is the name of the SECOND digi in such a chain. If there NO SECOND digi, in the chain then make the argument blank with ONE space like this: " " and TXM will not attempt to connect to NETBBS[1..6]_DIGI2_2_NAME. IMPORTANT! - The argument must be the complete connect string instruction to the TNC, including the "c" if necessary. Some node software will not require the "c", so we have therefore not hardwired it into TXM. If your node needs the "c" then you MUST include it in the argument. NETBBS[1..6]_DIGI2_DELAY -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Delay in seconds for Connect to Second link Example : NETBBS5_DIGI2_DELAY "180" Comment : This is the amount of time in seconds that will be allowed to establish a link to NETBBS[1..6]_DIGI2_NAME. NETBBS[1..6]_NAME -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Connect to Gateway BBS Example : NETBBS6_NAME "c BBS" Comment : This is the connect string to the gateway BBS. This is also the string that is parsed by TXM to determine the match to DELIVER_TO argument for Passthru Forwarding. See the documenta- tion for further information. IMPORTANT! - The argument must be the complete connect string instruction to the TNC, including the "c" if necessary. Some node software will not require the "c", so we have therefore not hardwired it into TXM. If your node needs the "c" then you MUST include it in the argument. NETBBS[1..6]_DELAY -------------- Use : Argument Required for TXM Mailer function Purpose : Establishes Delay in seconds to wait for "=>" from BBS Example : NETBBS1_DELAY "200" Comment : This is the amount of time in seconds that will be allowed to receive the connect acknowledgement from the gateway BBS. APPENDIX B - EXAMPLE TNC CONFIGURATION SET - KANTRONICS KPC-2 ------------------------------------------------------------------- 8BITCONV ON AX25L2V2 ON ABAUD 2400 ////REQUIRED///// ALIAS OFF AUTOLF OFF AXDELAY 0 AXHANG 0 BEACON EVERY 0 BKONDEL ON BTEXT BUDLIST OFF BUDCALLS NONE CANLINE $18 CANPAC $19 CCITT OFF CD INTERNAL ////REQUIRED///// CHECK 60 /// this to allow for disconnect in reciev mail// CMDTIME 1 CMSG OFF COMMAND $03 CONLIST OFF CONMODE TRANS ///REQUIRED !!!//// CONOK ON CPACTIME OFF CR ON CRLFSUP OFF CSTAMP OFF CTEXT ///// c text is handled by TXM automatically///// CWID EVERY 0 DAYTIME 00/00/00 02:37:57 DAYTWEAK 8 DAYUSA ON DBLDISC OFF DELETE $08 DIGIPEAT OFF DWAIT 0 /// TWEAK - and use slottime=1 and persist=255 frack=4 ECHO OFF //// !!! this is VERY Important !!!/// EQUALIZE ON ESCAPE OFF FLOW OFF ////REQUIRED//// FILTER OFF FRACK 4 FULLDUP OFF HBAUD 1200 HEADERLN OFF HF OFF HFTONES OFF HID ON INTFACE TERMINAL KNTIMER 15 LCOK ON LCSTREAM ON LFADD OFF LLIST OFF MONITOR ON MALL ON MAXFRAME 4 MAXUSERS 1 MBEACON ON MCON OFF ////REQUIRED///// MCOM OFF ////REQUIRED///// MODEMENA OFF MRESP OFF MRPT ON MSTAMP OFF MYCALL KC6UEY MYALIAS KC6UEY MYNODE KC6UEY MYPBBS KC6UEY NDWILD OFF NEWMODE ON //////REQUIRED//// NOMODE OFF ///////REQUIRED///// NTEXT NUCR 0 NULF 0 NUMNODES 0 PACLEN 255 /// This is a TWEAK setting/// PACTIME AFTER 5 PARITY 4 PASS $16 PASSALL OFF PBBS 0 PBPERSON OFF PERSIST 1 PID OFF PTEXT REDISPLA $12 RELINK OFF RESPTIME 5 RETRY 10 RING ON RNRTIME 0 SCREENL 0 SENDPAC $0D SLOTTIME 1 START $11 STATSHRT ON STOP $00 //////REQUIRED///// STREAMSW $7C STREAMCA OFF STREAMEV OFF SUPLIST OFF SUPCALLS NONE SWP 17,17,108 TRACE OFF TRFLOW OFF TRIES 10 TXDELAY 50 TXFLOW OFF UNPROTO BEACON USERS 1 XFLOW OFF ///REQUIRED///////// XMITOK ON ///REQUIRED///////// XOFF $00 ///REQUIRED///////// XON $00 ///REQUIRED///////// cmd: .