Amiga ISO Collection

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

/ Amiga ISO Collection / AmigaUtilCD2.iso / Misc / JM941031.LHA / jammail.doc < prev next >

Wrap

Text File | 1994-10-21 | 59.4 KB | 1,373 lines

Notice: The JAMMAIL support echo, is now available through the FidoNet Zone 1 (North American) Backbone. Simply request the echo from your hub and you should be able to connect. Systems from other zones, or in some other situation, can contact me directly for a feed if you wish. -------------------------------------------------------------------------- April 15, 1994 JamMail 0.98.250 Documentation By James McOrmond Fidonet#1:163/139.0 ZyXELNET#18:18/0.0 AmigaNet#40:553/139.0 ab207@freenet.carleton.ca Data: (613)521-0455 19.2k Data: (613)521-5680 28.8k Note: This documentation is not complete. If you have a specific question about setting something up, please do not hesitate to contact me. There is also a .FAQ (Frequently Asked Questions) file included in the archive that may answer some of your questions. Table of Contents ================= 1. Some questions about JamMail, what it does, and its history. 2. Installing JamMail. * 3. Instructions on the use of the Menu system. a. Setting up Fidonet. * b. Setting up UUCP. * c. Setting up Atomic Clock configs. * d. Setting up the Other call types. * e. Phone line/modem configs. - f. Login Menu options * g. Bulletin Board Launching configs. + h. Server text files. + i. Using XferqSH or other File request servers. j. Logs & Windows options. + k. Configuring the internal Scheduler. + l. Using the Long distance Calling options. * m. Use of JTPhone for setting up a phone book. * 4. What's necessary for a Point/End User to configure? - 5. What's necessary for a full Node to configure. - 6. Using a Cron with JamMail. * 7. Distribution. * 8. Disclaimer & License. + 9. Registration. + 10. Special Thanks. + * Added to since origional manual + Added since origional manual - Not written yet. 1. What is JamMail? JamMail is the first WPL.library mailer generator. What this means is through the use of the JamMail program, you will be generating a custom Front end for your system. No extra code should be in the .wpl file that isn't required for your system. If you are running as an end user and don't answer the phone at all, not a line of code that is for answering the phone will be created. Once you have generated your S:JamMail.Wpl file, you will not need to run the JamMail program again unless you need to change something. The S:Setup script launches WPL and loads and runs the S:JamMail.wpl script that you generated. What features can a WPL program written by JamMail have? JamMail was primarily written to make it easier for me to add things to my system, so the first thing the JamMail binary was required to do, was to be able to generate a program that had the same features as the file I had written by hand. Some of these features were: Fidonet support, UUCP support (launching UUCICO on inbound and outbound calls), Atomic clock setting (it dials up an atomic clock system, and accuratly sets your system clock). It also had to be able to easily launch whatever BBS software I happened to be running at the time. A simple scheduler was also required, so I put one in. The BBS program I've been running during most of the time i've been writing the JamMail binary, is VBBS. VBBS is a multi-tasking Graphical User interface BBS system. A requirement of using VBBS, was that you had to be using the VBBS terminal program, so I made it possible for users to download files right from my JamMail/Login prompt. At this point, I also set things up so people could do standard Fidonet File requests right from the login prompt, and they can be connected to my system with their favourite Terminal program (that supports Batch Zmodem transfers). Now that JamMail was able to generate and easily configure all of these options, I started into the "new" options that are only available through the generator. I started by making the system Multi-line capable with one script. Currently, i've limited the number of lines to 9. This is purely a cosmetic limitation. If someone requires a frontend on more than 9 lines, they can contact me, and i'll compile a version for them. Now that JamMail is multi-line, a much improved Scheduler was required, so I enhanced the scheduler significantly. I also wanted a way to specify which lines were used to dial specific sites based on what type of modem they had, what their address was or simply on their phone number. Now that there is a nice window there showing what the scheduler is doing, I figured it would be good for the user to be able to use that window for something, so i've set it up, that you can press CTRL-C in that window, and have the scheduler close down. You can also configure the scheduler to close all of the JamMail lines when it exists as well. Pressing CTRL-D in the Scheduler window, causes the scheduler to start its WaitLoop over again, and pressing CTRL-F in the window causes the scheduler to timeout whatever it is currently doing (Unless it is in the middle of making a call). On or about this time, I picked up a Unitel account. Unitel is an "alternative" long distance phone company. Fax routers are available, which is a little black box they'll stick between your Fax/Modem and the phone line, but I figured i'd not get one of those and simply build the feature into JamMail. If the phone number your dialing matches a pattern (the default is "(1-|011-)#?") it will pre-pend a dialing code onto any phone number correctly configured as Long distance from a North American site. I also wanted to be able to list all of the LD calls I made with JamMail, so any number that matches the above pattern will be sent to a special LogProc message port to be logged in a seperate file as well. (see section on Logproc for more information on the logging functions of JamMail). Because I own a ZyXEL modem, some ZyXEL features are supported. The system can be programed to support CallerID in a couple different ways. The first thing it does is log the CallerID messages in your main log, so you can always see where that caller had been calling from. It also puts this CallerID string in an ENV: variable called $(line).CID so your BBS program can make use of it, if it can. Also I personally find it a bit annoying if someone blocks the CallerID from showing where they are calling from, so JamMail has a few options here. The first thing it can do, is display a text file right before the main prompt saying that it has identified that they have blocked the CallerID. Also, you can configure the system to not allow them to log into one of your Bulletin boards, and if you wish, it will hangup as soon as it displays the warning text file. The same options exist for the User file requesting functions. JamMail has the option to launch Fax software, but since I do not have any, this function has not fully been tested. Also, if some usefull VoiceMail software becomes available, I will support it if possible. VoiceMail will likely be supported by using the distinctive ring feature of the modem. I do not trust the concept of attempting a Voice session when you also support Data on the same line, but distinctive ring will allow you to know what type of call it is before you answer the phone. The other option, is to support VoiceMail on a line that you don't receive Data calls (ie, an end user, just running the system as an answering machine, that you can call out from). 2. Installing JamMail. The files in the libs/ directory from this archive should all be moved to your libs: directory. The files in the s/ directory, should be moved to your s: directory. The files in the bin/ directory should be placed somewhere on your path: There are two versions of JamTool included in the archive. JamTool_T uses the Traplist.library to access a nodelist, and JamTool_I uses Nodelist.library to access a nodelist (Igen style currently exists). You should select which format you will be using, and you should rename the appropriate version to "JamTool", and place it in the same directory as the other binaries. If you will not be using a Fidonet style nodelist, pick either one, and rename it to JamTool and place it in your Path. If you do not have either a Traplist or an Igen nodelist compiled and running on your system, archives for both nodelist formats are on my system that you can Freq. Traplist.lha gives you the needed Traplist.library library and nodelist compiler. Igen1a34.lzh gives you the Igen/ Nodelist.library archive. If you are at all speed conscious, you will likely want to make JamTool resident, as that will speed things up during Fidonet handshaking. The file s:setup will likely need to be modified to setup your main log file and log window, and the long distance phone log. Currently, the main log file is logs:jammail.log, and the current long distance phone log is logs:Phone.log. The main log window is also specified in this file. Currently it is "RAW:717/13/708/206/JamMail Log Window/inactive'". This window likely will not fit on your screen. You will want to adjust its location on your screen. If you wish to put this log on a public screen, just specify the /SCREEN option in the window name. This file will eventually be generated by JamMail as well, so you will not need to configure it manually. The S:Setup file should have its execute bit set so you can launch JamMail simply by typing "SETUP" from any CLI/Shell on your system. The S:Setup script aborts JamMail if it is already running, and launches it again. It will also setup LogProc if it isn't already running on your system. If you make changes with the JamMail program, and generate a new JamMail.wpl file, simply type "Setup" and it will launch the new one. You should also set the execute bit on the CALL script, as you can use it to manually dial a system. It sends call commands to the scheduler, so the multi-line features of the system will be used as well. Both s/call and s/setup have their script bits set in the archive, so if you unarchive the files telling lha/lz to keep the bits, this will be done. Jammail also sets the script execute bit when it generates a new s/setup script. In your outbound directory, you will want to make a sub-directory called "Xferq", and you must make an assign to this directory in your Startup-sequence or User-startup file. Xferq.Library will store its outbound queue files in this directory. You should not touch any of the files that will be in this directory yourself. If you do not already have one, you will likely want to assign LOGS: to a directory where you store all your logs. This isn't a requirement but the defaults all use Logs: and I find it handy to have a single location. 3. The JamMail Menu System. From the Main JamMail menu, you will notice a few bits of information. The Menu shows you if you have some of the more normal config options turned on or not: Fidonet, UUCP, Atomic Clock or the Scheduler. It also shows approximately what versions of WPL.library and JamTool should be used with this version of the JamMail binary. a. Configuring the FidoNet options. 1. Primary Address: This is your primary system address that will show up in Fidonet Sessions. 2. Inbound Name: This is the system name that will show up on the remote systems end when they call you. 3. Outbound Name: This is the system name that will show up on the remote systems end when you call out. 4. Sysop: This is your name. It will show up in the remote systems logs. 5. Inbound Directory: This is the directory that files received during a Fidonet session will go to. 6. Outbound Directory: This is the directory that outbound FileRequest files will be searched for. Typically, outbound mail will also be in this directory, but that is not required. System AKA's and changes. Because of the growing number of Alternate Fidonet networks, and the use of Multiple addresses, a number of options can be changed based on who the remote system is. A standard **AmigaDos pattern** match is done on the **remote systems** address. Address: Your new system address Inbound name: Your new system's name on inbound calls Outbound Name: Your new system's name on outbound calls Inbound directory: The new inbound directory. Outbound directory: The Directory that .REQ files are searched for. Pre Session: A custom command run before each outbound session Post Session: A command run after each session. Handshakes: You can specify which handshakes are available with this system, or group of systems. A blank entry means that you do not wish to change it from the default configured in the "FidoNet Options menu". Note: The # symbol is part of the AmigaDos pattern match system, so you can not match an address such as "Fidonet#1:163/139.0". You need to replace the # symbol with a ? such as "Fidonet?1:163/139.0". Other Options. 1. Handshakes: Fidonet offers a couple methods of saying "Hello" with the other end to find out who each other is, and what file transfer protocols you support. To be a node in FidoNet, you must have FTS1 enabled. Points do not have any requirements put on them, other than the fact you must be able to connect to your host. 2. Outbound Pickup: This says whether or not you're willing to pickup any files during an outbound session. Make sure this option is always set to true if you call someone to pickup your mail. 3. File Requests: This says whether you will accept inbound file requests. If you set this to true, you must configure a file request server in the XferqSH menus. 4. Post Session: This command is run at the end of every Fidonet session. 5. Pre Session: This command is run before every outbound Fidonet Session. 6. Protocols: This option configures which protocols you wish to support. Some of these protocols are only available while using specific handshakes, but JamMail will automatically enable the protocols for each handshake they are supported with when you enable the protocol. Each Handshake supports the following protocols: EMSI: DirectZap, ZedZap, YModem, ZedZip, SeaLink, TeLink YooHoo: ZedZap, ZedZip, SeaLink/DietIFNA. FTS1: SeaLink/DietIFNA/TeLink b. Configure UUCP options. 1. UUCICO: This is the full path name to the UUCICO binary. (this is part of the UUCP package). 2. UUCICO Opts: These are command line options that will be used when UUCICO is launched for inbound and outbound UUCP sessions. 1. UUCICO2: This is the full path name to the UUCICO binary. (this is part of the UUCP package). 2. UUCICO2 Opts: These are command line options that will be used when UUCICO is launched for inbound and outbound UUCP sessions. 3. Post Session: This command will be run after each UUCP session 4. Pre Session: This command will be run before each outbound UUCP session. To support UUCP/UseNet, you must setup a uucp package seperately of JamMail. JamMail will only take care of the mail transfers by launching UUCICO. Mail must be handled by other packages. I am now using the UUCICO binary that was sent out in the AmigaUUCP 1.16a distribution. Any relatively new version of UUCICO should work as long as it fully supports the -Getty option for inbound *AND* outbound sessions. c. Configure Atomic Clock settings. Through the use of the XprClock.library file, your system clock can be set by calling one of the Atomic clock systems. 1. Post NRC: This command will be run after a successfull session. 2. GMT offset: This is the time difference between your time zone and GMT. The Default is -4 which is for EST. 3. Current Year: This is the number used when calculating the correct date. You will want to change this each January 1st. Most Atomic clock systems are using a 300bps carrier, so you have to connect to the system at 300bps. BELL103 is the mode that I use when connecting with my ZyXEL. To configure your system to be able to call an Atomic clock system, you must add an entry to your phonebook (using JTPhone), using the type NRC. This allows you to list different Atomic clock systems if you ever want to dial more than one. The phone number for the Atomic Clock system in Ottawa, On, Canada is: 1-613-952-7729 There likely is one closer to you, but since this is a minimum connect, it will not cost much if you are not in the Ottawa area. Atomic clocks are typically operated at Military stations, and other Government installations. d. Other Configs. In this menu, you can configure the system for two more session types. TERM and FAX. TERM calls are only available for outbound calls. This allows you to launch a terminal program once it connects to that system. This function is here so you can auto dial a busy BBS, but still have your own system up and running between dials. Outbound FAX support has not really been worked on, but inbound FAX's should work. 1. TERM launching: This enables or disables TERM sessions. 2. Term Command: This is the command that will be run when connected. 3. Post Term: This is the command that will be run after a TERM call. 4. Fax Launching: This enables or disables FAX sessions. 5. Inbound Fax: This is the command that will be run when a FAX response is received (see modem response configs section for more info). 6. Outbound Fax: This is the command that will be run when a connect is received on an outbound FAX call (not supported currently). 7. Post Fax: This is the command that will be run after each FAX session. Note: The Terminal program that you launch, must not seperate itself from the task that launched it, any support of OwnDevUnit.library must be disabled and it must run in shared mode. Old versions of NComm removed itself from the CLI, which caused problems with launching it this way. The new NComm 3.0 (and up) launch perfectly fine from here, but since you can't specify command line arguments with the port information, you will want to make sure you only do term type dials on the modem/serial port that you have NComm configured for. The new Terminus is also supposed to be launchable at this point but I have not tried this. I am currently running VLT as my terminal program. If you also wish to run VLT, you must go to the "Change Misc Options menu", and click on "Do Not use OwnDevUnit", and "Open Device in Shared Mode". One configuration file can/should be saved for each line that you may be making term calls from if you are running more than one phone line/modem on your system. e. Configure Lines/Modems Section. - rather big section, will get to it once others are finished. Most options are self-explanitory. If you need help, please do not hesitate to send me a message. f. Login Menu These options all deal with the "menu" system that will be provided to a user that calls into your system. If you have disabled the answer code (ie, you will not be receiving any inbound calls), this section will be completely disabled. 1. Prompt Timeout: This is the user inactivity timeout. After an inbound caller has been sitting at the prompt for this number of seconds, JamMail will attempt to Hangup. 2. User Prompt: This is the main prompt that will be displayed on inbound calls. If you support UUCP logins, the last word should end with ogin: as that is most commonly the pattern searched for in Dial-expect strings for UUCICO. 3. Privacy Checks: For systems supporting CallerID (Ident-a-call), this option configures what JamMail will do if a caller has blocked their number when they called you. A ZyXEL modem returns the message "Reason for no caller number: Privacy", so I scan for the pattern "#?privacy#?", and if this is found, you can do a number of things: a) Nothing b) Display a message to the user saying that they have been identified as a CID blocked user. The system will also display files before the user attemps to do file requests, or launching a BBS, and JamMail will not allow them to do either, but it will return them to the main login menu. c) Send the warning messages, but hangup after the warning message sent when the user tries to log into your BBS. d) Send the warning messages, but hangup after the warning message sent when the user tries to do a file request. e) Send the warning messages, but hangup after the user tries to do either a file request, or to launch a BBS. 4. User Freqs: You can allow users to do file requests from your front end. The user enters each file they want one per line, and enters a blank line when they are done. What is actually being done, is a .REQ file is being created in the T: directory, and once the user is done entering filenames, your "User Freq server" is launched, using this file as the request list. A Batch Zmodem transfer is then started. This feature is quite usefull if you wish to allow Long distance users to get files from your system without having to log into a BBS (or maybe you aren't running a BBS at all), but it does also allow people to be file leeches. 5. User Address: This is the address that will show up in the UserFreq Log when users are doing file requests from your system. This address doesn't really mean anything but someone may wish to use it somehow. Most File request servers do need a Fidonet address as the source of the Request list, so an address should be put here if you intend to support User File requests. 6. Menu Files: As an addition to User Freq's, up to 9 files can be downloaded directly from this menu. For each entry, a pattern can be entered, that is matched against what the user types to see if they want this file (so don't use "#?" as a pattern for one of the files, as everything a user enters will match, and they'll constantly be sent this file). The full filename of the file to be sent, and a short message to be transfered to the user before sending this file are to be configured as well. g. Bulletin Board Launching. Not only does JamMail have the ability to launch a Bulletin board from the login menu as other mailers do, but JamMail has the ability to launch nine different BBS's. The user just needs to type in the command that you configure to select which BBS to log into. You configure the launching of BBS's, with the following options: User Command: What the user needs to type to launch this BBS. This string is a full AmigaDos Pattern, so you can match multiple strings incase the user types more than is required (like IceBBS instead of just Ice). Launch Command: This is where you configure the command string that JamMail will use to launch the bbs the user selects. JamMail has built in defaults for the following BBS systems: VBBS/IceBBS, and DLG Pro BBS/OS JamMail has suggested command strings for the following BBS systems: Cnet 2.x, 4dBBS, and MebbsNet. There is no reason any other BBS can't be launched from JamMail, but these are just possible suggestions. To create your own launch string for another BBS, or to modify one of the suggested strings above, the following JamMail variables will be of help: $(baud) - connect baud rate $(baudlocked) - the rate your serial port is locked at $(line) - which line this is $(device) - the serial device for this line $(unit) - the unit number for this serial device $(serflags) - the serial port flags $(lastresponse) - Connect string When a user presses Escape Twice, this results in the same thing as if the user had typed "BBS". You can use this feature, by configuring one of your BBS's to also launch by the string "BBS" if you wish, or you can have the "BBS" string changed to the command string for one of the BBS's, by setting that BBS as the default. I have been contacted by a few people about using JamMail with Xenolink. Xenolink can be launched perfectly fine from JamMail, but Xenolink requires some special configuration options, and this is why I haven't included any built in configs. ------ Xenolink BBS Remote Session Spawn Utility, Version 1.90a Copyright © 1994, Xenomiga Technology. All rights reserved. Usage: XSPAWN <options> Options : NODE=n Xenolink Node number [required] BAUD=n Open serial device at this speed [required] CONNECTBAUD=n Set connect at this rate CONNECTSTRING=n Set connect string for this connection CPS=n Effective CPS for file transfers RES=x,y Screen resolution [required] LACE Set interlace PLANES=n Number of bitplanes on screen [required] FONT=f:s Screen font and point size [required] ------ Due to the last 4 possible options (3 of them being required), any built in default launching string is going to be wrong for most people. A possible launch string might be as follows: Xspawn Node=$(line) Baud=$(baudlocked) connectbaud=$(baud) connectstring=$(lastresponse) res=640,200 planes=3 font=ibm.font:8 For multi-line systems, this also causes a bit of a problem in that all lines will have the same settings, which may not be desireable. h. Server Text Files. When someone has called into your system, a variety of different text files may be displayed to the user depending on what they are doing. These files are configured here: Login Banner: This is the name of the text file that contains your login message or banner. This will be displayed to the user immediately after the connect message, and before the login prompt is displayed. This file should not be very long, possibly no more than 10 lines or so. Freq Banner: When the user goes into Freq/Grab menu to download files from your system, this text file will be displayed to the user. This file should contain possibly some instructions or other such information so the user knows whats going on. Freq Help: If the user types "Help" at the file prompt in the Grab/Freq menu, this file will be presented to them. BBS Privacy: If the user attempts to log into your BBS, and they have been identified as a CallerID Blocked user (see the Login Menu Privacy Checks screen), this file will be displayed to the user. Freq Privacy: If the user attempts to move into the Freq/Grab menu of JamMail, and they have been identified as a CallerID Blocked user (see the Login Menu Privacy Checks screen), this file will be displayed to the user. BBS Error Msg: After a BBS command has returned (presumably after the user logs off), if an error response is returned, this text file will be displayed to the user. This option was added since some BBS's could possibly fail the launch command, and this allows the user to possibly find out what happened, and to try again, or possibly use another BBS. This option can also be disabled in the "BBS launch menu" if the BBS normally returns a bad result. Magic Files List: If the user type "Magic" in the Grab/Freq menu, this file will be presented to them. This is usually a list of magic filenames that your file request server supports. Default Text Dir: When a user types something at the login prompt that JamMail does not understand, it will search this directory for a file of that name. This allows you to display information files and such to the user. There is one special case here. When the user presses "?" the ? will be changed to "HELP", and the HELP file will be searched for. i. XferqSH and other File request servers. File requests can be handled primarily through two different methods. i) a Non-Xferq aware file request handler through XferqSH. ii) an Xferq aware file request handler. Most file request servers are going to fall under category i). To use one of these file request servers, Russell McOrmond has written a program called XferqSH which makes this procedure much easier. The default command lines in menu A) all use XferqSH to do the dirty work. To use XferqSH for handing file requests the following variables must be configured: XferqSH: This is the full path name to where you have placed the XferqSH program. FreqCfg: This is the full path name to the XferqSH config file you are using for file requests. LogCfg: This is the log file which will display everything that happened while executing the FreqCfg file. If you have setup the User Freq option in Menu 6) and you are using XferqSH to handle your file requests, you also need to setup the following two variables: UserFreqCfg: This is the full path name to the XferqSH config file that you are using for User File requests. UserFreqLog: This is the log file which will display everything that happened while executing the UserFreqCfg file. Note: The UserFreqCfg and FreqCfg files can be the same config file if you wish to support them the same way. A third option also exists in that you can have XferqSH do some funky things with files that come in through a regular Fidonet session. You can move specific files to other directorys (eg. Compile your nodediff before your tic processor moves it to your file area). To support this option, the following two variables must be setup and configured correctly: InboundCfg: This is the full path name to the XferqSH config file that you are using for Inbound files. InboundLog: This is the log file which will display everything that happened while executing the InboundCfg file. The Format of an XferqSH config file to support file requests or User file file requests using the internal Freq Server. ---- ; Pattern Command #? #fido:freqlist.lst fido:badfile.txt ---- A config such as this one listed, could be used for either/both of the file request configs. This specific config uses the XferqSH internal file request server. It is not particularly usefull, but if you are really lazy and don't want to setup a better file request server, this will work. The fido:freqlist.lst file is simply a text file formatted: ---- ; Name FullPath Files files:jamfiles.lha AllFiles files:jamfiles.lha ---- This possible XferqSH.cfg file would send the user my files list if they did a file request of either "Files" or "Allfiles". Everything in this file is case insensative, so it does not matter if they requested "FILES" or "FiLeS" they would still get it. If you wish the person to get two files, then you may list both files with the same name in the first column. ---- files files:jamfiles.lha files files:jamfiles.lha.readme ---- This would send both my files list, and a .readme file (if it exists). If you require the use of a Password, putting the ! and a password at the end of the entry is how you would do it. ---- files files:jamfiles.lha ! secret newfiles files:jamnewfiles.lha ! boogie ---- Using XferqSH to launch other File Request Servers & other programs. All current file request servers should work fine with JamMail. Some of them will also be able to be run asynchronously with your mailer, allowing you to do other things while it searches for the files requested (like receive more files, or start sending files already found). The following variables can be used in any of the XferqSH.cfg files: %r - This is the filename of the file that just came in. %R - This is the full path filename of the file that just came in. %a - A full 5-d address of the remote system (eg. Fidonet#1:163/109.0) %z - Zone number of remote system. %N - Net number of remote system. %n - Node number of remote system. %p - Point number of remote system. %s - The string that was in the 5th argument of the XferqSH command line. %o - Asynchronous outbound ".rlo" file. If the file request server that you wish to run is able to be launched asynchronously, you should use this for the output file, and you should run the command. %O - Temporary ".rlo" file. If the file request server you wish to run is not able to be run asynchronously, you should use this for the output filename, and should not "run" the command. The XferqSh.cfg file that you use for file requests should only have one line in it (unless you are using the same XferqSH.cfg file for one or both of the other XferqSH command lines). This line, should be in the form "Pattern Command". The pattern that you want to use for your file request handler, is "#?.req", which means this line will be executed on any file that ends in .req. This allows you to support multiple .req files sent to you in the same session, as well as non-standard filenames like "1.163.139.0.req" if someone doesn't translate a 4d filename before sending it to you. If your request server requires something like. freq infile outfile 4d-address sysop baud Then your XferqSH.cfg line would be. #?.req run freq %R %o %z:%N/%n.%p %s And in the command line where XferqSH is run (menu A), you would replace the last option on the command line (the text string), with: "$(remote.sysop) $(baud)". The 5th option (the last option), is always sent when a %s is used in an XferqSH command line. This command line above assumes that the program "Freq" can handle being run asynchronously. If it can't, the command line must change to: #?.req freq %R %O %z:%N/%n.%p %s The difference is that the command is not "RUN", and that the output filename is the capital %O instead of the little %o. It is possible, that your File request server will require a really strange group of options, and that you will need to have all of the command line options created in that last text string on the XferqSH command line, and your XferqSH.cfg file looks like this: #?.req run freq %s which would take all of the options from the 5th string that was sent on the command line when you ran XferqSH. For the Inbound.cfg XferqSH.cfg file, you can use this pattern match feature, and move specific files to other directories, or whatever you can think of. j. Logs & Window options. JamMail uses an advanced logfile system. It uses a program called LogProc to handle all of the logging facilities (the screens, and the logfiles on disk). LogProc is configured primarily in this section. LogProc is launched in the s/setup script if it is not running. If LogProc is running because another program uses it, you may need to copy some sections out of the s/setup file to configure the logs correctly. LogPort: This is the message port where logproc will receive its commands. LogProc Group: This is the group of logs where the JamMail log messages will be sent. Multiple groups can be configured in LogProc so single logging messages can be sent to multiple places (like windows and disk files). Passwords: This option enables/disables whether you wish to see passwords from network sessions in your logs. Command Lines: This option enables/disables whether you wish to see executed command lines in your logs. Temporary Names: This option enables/disables whether you wish to see temporary inbound filenames in your logs. Use Color: This option enables/disables the use of color in your logs. If you are using a two color (one bit plane screen) to see your logs, you will want color disabled or else you will not be able to see some thins. Log File: This is the main logfile that LogProc will store JamMail's logging messages in. Log Window Size: This is the size settings for the main window Jammail will store your logging messages in. Public Screen: This will enable/disable the use of a public screen (other than workbench) to put the Log Window on. JamMail does not currently open its own screen. You must open up the public screen with a seperate utility such as ScreenManager and JamMail will use it. Screen Name: This is the name of the screen the Log Window, and the modem log windows will be placed on. Backdrop: This enables Backdrop mode for all windows JamMail opens. Window Drag: This enables the Drag Bar on top of all JamMail windows. Window Sizing: This enables the sizing gadgets for all windows JamMail opens. k. Configuring the internal scheduler. Currently, the internal scheduler in JamMail is relatively powerfull. In a future version, the abilities of the scheduler will be greatly enhanced, but for now, this scheduler is quite good. The scheduler does primarily four things. 1) It scans the outbound directory (and uuspool: if you have UUCP sessions configured), to decided what systems to call. 2) Accepts manual *SINGLE* calls from its AREXX port (the s/call script uses this). 3) It takes this list of systems to call, and decides which line to make each call from. 4) It will close the JamMail system down if told to. Section 3 isn't all that relevent to a user running a single line, but it is a usefull feature for others. The following configuration options setup functions 1 & 4. Dial UUCP Sites: This option tells the scheduler whether it should scan UUSPOOL: for UUCP type mail to send out. Abort on Ctrl-C: This tells the scheduler whether it should close down when a Ctrl-C is received in the scheduler window. Abort on Line Ctrl-C: This tells the scheduler whether it should abort down when a Ctrl-C is received in a modem/line window. Note: When this option is enabled, JamMail will be a little slower, opening and closing each lines window. Close Down on Abort: This tells the scheduler whether it should close JamMail down when it receives an Abort message to its AREXX port. Close LogProc on Abort: This tells the scheduler whether it should close LogProc when JamMail is being shut down. If LogProc is being used for any other program, or if you wish the logs to stay on your screen, then this option should be set to false. Dial Delay: This option sets the amount of time between each dial command sent out by the Scheduler. The minimum value here is 5 seconds. This is to allow the line some time to reset the modem after a call. Wait Delay: This option sets the amount of time between each scan of the scheduler. The minimum value here is 10 seconds. Scheduler Window: This is the size settings for the window the scheduler will be displayed in. Both the Dial Delay and the Wait delay can be skipped by pressing CTRL-F (Timeout) in the scheduler window. Pressing Ctrl-D will cause the scheduler to start its Wait Delay over again. To setup option 3, where the scheduler decides which line to make a specific call with is a little harder. Single line users should have a "1" in the "Default Line Scan Order" and not have any custom dial sets configured. Multiline users, should list all of the lines they wish to be used for outbound calls in the "Default Line Scan Order" list. The scheduler will start at the first line in the list, scanning for a free line, and make the call on the first line available. Custom scan sets is where things start to get fun. The scheduler can be configured to use a different scan set based on the remote systems address, the remote systems phone number, or on a special modem flag. This allows you to make calls for specific systems only on specific lines, or to only make calls to specific modem types only on specific lines (quite usefull if you have different kinds of modems yourself). The following configuration options exist in this menu: Pattern Type: This is where you set what type of criteria you are going to set for this Scan List. Pattern String: This is the string that will be matched against the remote systems information (the type you selected above) to see if this scan set should be used. This is a full AmigaDOS pattern match string. Dial Scan Order: This is the new "Line Scan Order" for any system that matches the above pattern. Only the numbers of lines that actually exist can be entered here. They will not be removed if a line is deleted however. l. Long Distance Phone Call options. Due to the special nature of long distance calls (ie, the extra charging of money by your phone company), a couple options have been added specifically to handle this. In this menu, two different things can be configured. 1) Pre-phone number string 2) LD Phone log. Option 1) is quite usefull in Canada to be used with alternative phone companies such as Unitel. This option should also be usefull if you wish to use a calling card or other such code. Option 2) allows JamMail to produce a log of long distance phone calls. This log can be used to match against your phone bill. The following configuration options setup these functions: Phone Number Pattern: This is the pattern which any long distance phone call will match. The default is something like "(1-|011-)#?" which is appropriate for any North American Site calling another North American site, or calling an International site. Calling Code: This option enables or disables the use of a pre-phone number string. PreNumber Code: This option configures the string that will be inserted between the dial command, and the phone number of systems that are long distance. LD Call Phone Log: This enables the creation of the Long Distance Phone Bill Log. LogProc Group: This is the LogProc group to send the logging messages to. See the section on configuring LogProc to setup the LogGroup. LogFile: This disables/enables the LDPhone Log being sent to a disk file. LogFile Name: This is the name of the disk file for the LDPhone Log. LogWindow: This disables/enables the LDPhone Log being sent to a window. LogWindow Size: This is the dimensions of the LDPhone Log Window. This window will have the same window flags and will appear on the same screen as the Main Log window. m. Using JTPhone for setting up and using a phone book. JTPhone (JamTool Phone) is a little program I wrote to easily edit the phone book used by JamTool. Entries should be added to this list for any systems you wish to regularly dial. Any system you have a session password with (of any call type, Fido, UUCP, UUCP2) needs to be listed here. For speed purposes, the Nodelist will not be scanned during a session, only the phonebook and the cache. The file JamTool.Doc has more documentation on JamTool and JTPhone if you wish to know more. The phone book format is documented in that file if you feel the need to edit it manually. If you wish to "blank" out a field in the phonebook (line a password, or some other field you are not using), put a single - character and JamTool will know what to do. 4. What's necessary for a Point/End User to configure? As far as any piece of softwares concerned, the only difference between a "NODE" and a "POINT", really, is whether your system answers the phone. Even if you do have a point address, if you answer the phone, you should be configured as a full node. The first thing A point/End user should select, is the disabling of the answer code. This means your system will not answer the phone at all. This allows you to safely run your system at any time, on a voice line, and it will not answer human callers. The next thing the user should do, is configure the line/modem. JamMail requires at least one one configured at all times, so if the default modem configured is not close to your modem, you should add a new modem to the system, pick the closest choice, and then delete the default modem. You may need to change the device/unit settings if the values given are not appropriate for your system. The next thing you'll need to setup, is the values for the location of the modem log window. The settings in the Modem settings menu will likely be close enough for general use, but if you need to change anything, this is where it will need to be adjusted. You can also put the name of your modem in here if it is not correct. If your modem returns response strings other than what are configured for the modem type you selected, they should be changed now. Most points will not need any custom dial strings, but if you wish to set them up, you should follow the instructions in chapter 2 in the Line Configuration Menu -> Custom Dial Strings section. The "Other Modem Options" aren't really important configurations so don't really matter. Your system will operate perfectly fine without touching them, but likely, you will want to change the information listed there just so FidoNet EMSI sessions will "look" better. If you are not going to support UUCP sessions at all, you should disable them in the UUCP menu from Main. If you are going to support UUCP sessions, you should configure the UUCICO and UUCICO options correctly. The UUCP software should be setup seperately, and is not in the scope of this manual. If you do not have an Atomic clock system near you, and you do not want to phone long distance to get the absolute correct time for your computer, you should disable Atomic clock sessions. If you do wish to support them, you should fill in the correct year and offset value for your timezone. If you wish to support outbound TERM sessions, this is where you want to configure it. To setup the launch string for your terminal program, you should refer to the Other Dial types configuration instructions in Chapter 2. Most likely, you will not want to support FAX sessions, so this should be disabled. Currently, JamMail doesn't really have the ability to completely disable FidoNet operation. Some of the FidoNet code is still written in the s:JamMail.wpl file although this will be cut down in future versions. To configure the FidoNet options, you simply need to fill in all of the fields that you see in the FidoNet options screen. If you belong to multiple FTN Networks, and connect to systems that do not support EMSI, you will want to configure some AKA's in the System AKA's & Changes menu. For a full explaination of all of the options in this menu, see the appropriate section in Chapter 2. In the "Other Options Menu", you should configure your full EMSI addresses string, as well as some other configuration options. You should only change the HandShake and Protocols configuration options if you know exactly what you are doing. 5. What's necessary for a full Node to configure? As far as any piece of software is concerned, the only difference between a "NODE" and a "POINT", really, is whether your system answers the phone. Even if you have a full "Node" address in some network, if you do not answer the phone, please see the Point/End users chapter of this manual. ................... obviously this section is not done yet. basically, depending on what features you want, you'll be wanting to go through all of the options provided. Start with setting up the system as a point, then turn on the answering code, and look into the answering features, like BBS's, the login menu stuff, and inbound FAX support. 6. Using a Cron with JamMail. There are many Cron programs available for the Amiga. A very powerful Cron is called "CyberCron". It has many features, and it also uses LogProc for its logfiles. I myself use TPTCron because I have very simple needs, and I already had it setup on my system, as I was previously running a DLG BBS system. There is one specific thing related to JamMail, that does require a Cron program. This is only relevent to Nodes, so a simple point system doesn't need to run a Cron, unless they wish to automate calls to their boss/host or something like that. There is an ENV: variable that Jammail uses called "ZMH". If it is set to "TRUE" or "1", Zone Mail Hour mode will be in effect. This will dissallow any users to log into your BBS, download files from your main menu, and it will disable File requests from users, or from other Fidonet systems. If this variable is "False" or 0 (or really, anything thats not true) the system will function normally, as if the variable wasn't even there. Two other varialbles are used by JamTool, specifically relating to the scheduler: MINPRI and MAXPRI. These variables contain the minimum and maximum priorities that the scheduler should be dialing for. Normally, MinPri would be 50, and MaxPri would be 120. The Minimum priority of 50 means any system with something attached with a "Crash" priority will be called. If you wish to call systems with a "Direct" priority, (like during Zone Mail Hour), this should be set to 30. The Highest MaxPri value allowed is 120, but this can be lowered for specific situations. During Zone Mail hour, when you would be dialing systems with a Direct Priority, if you did *NOT* also want to dial systems with a Crash priority, you could set the MaxPri to 49 and the scheduler would ignore those systems. These variables can be set by the following CRON command lines. 50 03 * * * setenv ZMH TRUE 05 04 * * * setenv MINPRI 30 10 05 * * * setenv MINPRI 50 10 05 * * * setenv ZMH FALSE Using these configs, my system stops allowing BBS sessions and file requests at 3:50am, starts doing outbound Direct polling at 4:05am and turns things back to normal at 5:10am. The reason I do not set them right on the hour, is to let people connect in that may have their clocks a few minutes off. 7. Distribution. There are a number of ways to get updates to JamMail. The absolute easiest way to do it, is to dial my system up directly and to do a file request (either using a terminal program, or a Mailer such as JamMail itself). Roger Clark @ Fidonet#1:382/105 in Austin, TX has agreed to post JamMail into the ADSFIDO file echo area in the Amiga Distribution System network. We haven't discussed how often this will be done, but this is being worked on. JamMail should not be sent into the SAN (Sky Amiga Net) distribution system since there is alot of duplication of systems, and there is no reason for it to be in both. The official hatch site is Roger's system. WPL support FTP directory on ccs.carleton.ca. There is a public WPL directory on this system, but as of yet, I have not had the chance to send any versions of JamMail to this system. I do not have direct access to it myself, and haven't sent a version to anyone that does. Due to permission problems with the ftp directory on Carleton, updated versions of JamMail are being sent to AmiNet in the /comm/fido directory. This is not an ideal location since they are not designed for receiving updated versions often. If anyone has a better location where "versions of the day" could be sent, please let us know. 8. Disclaimer & License. JamMail is software. Software is written by Humans. Humans make mistakes. I do not guarantee that there are no errors or bugs in this software. I can only guarantee that it works on my system as my system is currenly configured. JamMail, jammail.library, JamScan, JamTool and wplemsi.library are copyright 1994 by James McOrmond. These programs are not to be distributed in any form other than in this archive. This archive also contains a custom version of WPL.Library. This library is only to be used by users of the JamMail mailer. Distribution of any of these programs for use in any other package is strictly forbidden without permission from their author James McOrmond. The JamMail archive may be distributed anywhere. This archive may be uploaded to any BBS and should be distributed in its unmodified form. Anyone pressing JamMail, or any of the related utilities onto a CD-Rom, please let me know beforehand. 9. Registration. JamMail is not FreeWare, CrippleWare, ShareWare or Commercial. It is DonationWare. I do not require you to send me anything at all! I will of course not refuse anything you wish to send as a registration, and in fact I do ask for something. As a Minimum, I would ask you to send a message to me telling me that you are running the software, and what your feelings are about JamMail. Tell me what you like, and what you dislike about it. If you are so inclined to send me money, go for it. A money order, for $20cdn (for Canadians) or $20us (for everyone else) would be great. (MORE or less is fine :-) If you do not have any money to spare (students are like that, aren't we :-), possibly you can find something else to send me. Here's a few suggestions: 1) Software! Hey. If you'd like me to support a specific piece if software (like a Fax package like GPFax), send me an *ORIGIONAL* package, and i'll likely support it. 2) Documentation: I'm very short on Amiga programming manuals. I've just recently forced myself to pickup the RKM: Libraries manual from CBM since it was a real requirement if i'm going to get the GUI done). Stuff like the Style guide, The Arexx programmers manual from CBM, or one of the other RKM manuals would help a lot. 3) Hardware: No, I don't mean you should give me your computer, but if you have something that you don't need anymore, and I may be interested in it, let me know. (but hey, a second Amiga, would go far for testing purposes!) In most of these cases, I would actually suggest that a couple people get together and sent me something as a group. This would be great, and it saves you guys money/etc.. 10. Special Thanks. The following people have been of great help with testing different features of JamMail and for supporting JamMail. Alan Kelm 1:163/139.38@Fidonet Derek Clark 1:244/200@Fidonet Sean Clark 6:700/267@Fidonet Shane Gouseman 1:237/528@Fidonet Robert Lehman Ron Goddard 1:163/578@FidoNet A special thanks to Donald Knott for sending in a complete GPFax package for JamMail development. Also, special thanks to the following people, even though they are themselves not running JamMail Russell McOrmond aa302@freenet.carleton.ca Dave McDonald 1:163/547@Fidonet Denis Turcott 1:167/151@Fidonet Robert Williamson 1:167/104@Fidonet