--- /dev/null
+<!doctype linuxdoc system>\r
+\r
+<article>\r
+\r
+<!-- Title information -->\r
+\r
+<title>The DXSpider Administration Manual v1.50</title> \r
+<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net), and\r
+Charlie Carroll, K1XX, (k1xx@ptcnh.net)</author>\r
+<date>March 2003 revision 0.5</date>\r
+\r
+<abstract>\r
+A reference for SysOps of the DXSpider DXCluster program.\r
+</abstract>\r
+\r
+<!-- Table of contents -->\r
+<toc>\r
+\r
+<!-- Begin the document -->\r
+\r
+<sect>Routing and Filtering\r
+\r
+<sect1>Introduction\r
+\r
+<P>\r
+From DXSpider version 1.48, major changes were introduced to the way \r
+node connections are treated. This is part of an ongoing process to\r
+remove problems with loops and to enable talk and other functions to\r
+propagate across the whole of the worldwide cluster network. In fact,\r
+in a Spider network, it would be useful, perhaps even necessary to\r
+have loops. This would give real resilience to the network, meaning\r
+that if a link dropped, the information flow would simply come in and\r
+go out via a different route. Of course, we do not have a complete\r
+network of Spider nodes, there are other programs out there. Some of\r
+these do not have any protection from loops. Certainly AK1A does not \r
+handle loops well at all. It is therefore necessary to have some form \r
+of protection for these nodes.\r
+\r
+<P>\r
+In fact DXSpider has had a simple system for some time which is called\r
+<it>isolation</it>. This is similar to what in other systems such as \r
+<bf>clx</bf>, is called <it>passive mode</it>. A more detailed explanation\r
+of <it>isolation</it> is given further below. This system is still available\r
+and, for simple networks, is probably all that you need.\r
+\r
+<P>\r
+The new functionality introduced in version 1.48 allows filtering the node\r
+and user protocol frames on a "per interface" basis. We call this\r
+<it>route filtering</it>. This is used <bf>instead of</bf>\r
+<it>isolation</it>. \r
+\r
+<p>\r
+What this really means is that you can control more or less completely\r
+which user and node management PC protocol frames pass to each of your \r
+partner nodes. You can also limit what comes into your node from your \r
+partners. It is even possible to control the settings that your partner \r
+node has for the routing information that it sends to you \r
+(using the <it>rcmd</it> command).\r
+\r
+<sect1>Route Filters\r
+\r
+<p>\r
+Initially when route filters were being tested we generated a\r
+"default" filter. Unfortunately it quickly became apparent that this\r
+might suit the UK cluster network but didn't really fit anybody else.\r
+However using a default filter is an appropriate thing to do. How, is\r
+explained further on.\r
+\r
+<p>\r
+The first thing that you must do is determine whether you need to use \r
+route filtering <bf>at all</bf>. If you are a "normal" node with two or \r
+three partners and you arranged in an "official" non-looping tree type \r
+network, then <bf>you do not need to do route filtering</bf> and you will \r
+feel a lot better for not getting involved. If you are successfully using \r
+<it>isolation</it> then you also probably don't need to use route filtering.\r
+\r
+<p>\r
+To put it simply, you should not mix Isolation and Route Filtering. It \r
+will work, of sorts, but you will not get the expected results. If you \r
+are using Isolation sucessfully at the moment, do not get involved in \r
+Route Filtering unless you have a good supply of aspirin! Once you have \r
+started down the road of Route Filtering, do not use Isolation either.\r
+Use one or the other, not both.\r
+\r
+<p>\r
+You will only require this functionality if you are "well-connected". What \r
+that means is that you are connected to several different parts of (say) \r
+the EU cluster and, at the same time, also connected to two or three places \r
+in the US which, in turn are connected back to the EU. This is called a \r
+"loop" and if you are seriously looped then you need filtering.\r
+\r
+<P>\r
+I should at this stage give a little bit of background on filters. All\r
+the filters in Spider work in basically the same way. You can either\r
+accept or reject various options in order to create the filter rules\r
+you wish to achieve. Some filters are user settable, others can only\r
+be altered by the sysop. Route filtering can only be done by the sysop.\r
+\r
+<P> \r
+Anyway, without further discouragement, let me start the process\r
+of explanation.\r
+\r
+<sect1>The node_default filter\r
+\r
+<P>\r
+All normal systems should have a default routing filter and it should\r
+usually be set to send only the normal, unlooped, view of your\r
+"national" network. Here in the UK that means nodes from the UK and\r
+Eire, in EU it is more complex as the networks there grew up in a more\r
+intertwined way.\r
+\r
+<p> \r
+The generic commands are:-\r
+\r
+<tscreen><verb>\r
+reject/route node_default <filter_option>\r
+\r
+or\r
+\r
+accept/route node_default <filter_option>\r
+</verb></tscreen>\r
+\r
+where filter_option is one of the following ...\r
+\r
+<tscreen><verb>\r
+call <prefixes>\r
+call_dxcc <numbers>\r
+call_itu <numbers>\r
+call_zone <numbers>\r
+channel <prefixes>\r
+channel_dxcc <numbers>\r
+channel_itu <numbers>\r
+channel_zone <numbers>\r
+</verb></tscreen>\r
+\r
+Please be careful if you alter this setting, it will affect \r
+<bf><it>ALL</it></bf> your links! Remember, this is a <it>default</it>\r
+filter for node connections, not a <it>per link</it> default.\r
+\r
+<p>\r
+For the default routing filter then you have two real choices: either\r
+a "national" view or the "safe" option of only your own\r
+callsign. Examples of each (for my node: GB7DJK) are:-\r
+\r
+<tscreen><verb>\r
+acc/route node_default call_dxcc 61,38\r
+acc/route node_default call gb7djk\r
+</verb></tscreen>\r
+\r
+GB7DJK uses the first of these. The DXCC countries can be obtained from the \r
+<it>show/prefix</it> command.\r
+\r
+<p>\r
+The example filters shown control <it>output</it> <bf>TO</bf> all your\r
+partner nodes unless they have a specific filter applied to them (see\r
+next section).\r
+\r
+<p>\r
+It is also possible to control the <it>incoming</it> routing\r
+information that you are prepared to accept <bf>FROM</bf> your partner\r
+nodes. The reason this is necessary is to make sure that stuff like\r
+mail, pings and similar commands a) go down the correct links and b)\r
+don't loop around excessively. Again using GB7DJK as an example a typical\r
+default input filter would be something like:\r
+\r
+<tscreen><verb>\r
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38\r
+</verb></tscreen>\r
+\r
+What this does is accept node and user information for our national\r
+network from nodes that are in our national network, but rejects such\r
+information from anyone else. Although it doesn't explicitly say so,\r
+by implication, any other node information (not from the UK and Eire)\r
+is accepted.\r
+\r
+<p>\r
+As I imagine it will take a little while to get one's head around all of \r
+this you can study the effect of any rules that you try by watching the \r
+debug output after having done:-\r
+\r
+<tscreen><verb>\r
+set/debug filter\r
+</verb></tscreen>\r
+\r
+After you have got tired of that, to put it back the way it was:-\r
+\r
+<tscreen><verb>\r
+unset/debug filter\r
+</verb></tscreen>\r
+\r
+<sect1>General route filtering\r
+\r
+<P>\r
+Exactly the same rules apply for general route filtering. You would\r
+use either an accept filter or a reject filter like this ...\r
+\r
+<tscreen><verb>\r
+reject/route <node_call> <filter_option>\r
+\r
+or\r
+\r
+accept/route <node_call> <filter_option> \r
+</verb></tscreen>\r
+\r
+<P>\r
+Here are some examples of route filters ...\r
+\r
+<tscreen><verb>\r
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)\r
+rej/route all (equiv to [very] restricted mode)\r
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)\r
+acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)\r
+</verb></tscreen>\r
+\r
+In practice you will either be opening the default filter out for a\r
+partner by defining a specific filter for that callsign:-\r
+ \r
+<tscreen><verb>\r
+acc/route gb7baa all\r
+acc/route gb7baa input all\r
+</verb></tscreen>\r
+\r
+or restricting it quite a lot, in fact making it very nearly like an \r
+<it>isolated</it> node, like this:-\r
+\r
+<tscreen><verb>\r
+acc/route pi4ehv-8 call gb7djk\r
+rej/route pi4ehv-8 input call_dxcc 61,38 \r
+</verb></tscreen>\r
+\r
+This last example takes everything except UK and Eire from PI4EHV-8\r
+but only sends him my local configuration (just a PC19 for GB7DJK and\r
+PC16s for my local users).\r
+\r
+<p>\r
+It is possible to write <bf>much</bf> more complex rules, there are up \r
+to 10 accept/reject pairs per callsign per filter. For more information \r
+see the next section. \r
+\r
+\r
+<sect1>General filter rules\r
+\r
+<P>\r
+Upto v1.44 it was not possible for the user to set their own filters. From \r
+v1.45 though that has all changed. It is now possible to set filters for just \r
+about anything you wish. If you have just updated from an older version of \r
+DXSpider you will need to update your new filters. You do not need to do \r
+anything with your old filters, they will be renamed as you update.\r
+\r
+<P>\r
+There are 3 basic commands involved in setting and manipulating filters. These \r
+are <em>accept</em>, <em>reject</em> and <em>clear</em>. First we will look\r
+generally at filtering. There are a number of things you can filter in the \r
+DXSpider system. They all use the same general mechanism.\r
+\r
+<P>\r
+In general terms you can create a "reject" or an "accept" filter which can have \r
+up to 10 lines in it. You do this using, for example ... \r
+\r
+<tscreen><verb> \r
+accept/spots .....\r
+reject/spots .....\r
+</verb></tscreen>\r
+\r
+where ..... are the specific commands for that type of filter. There are filters \r
+for spots, wwv, announce, wcy and (for sysops) connects. See each different \r
+accept or reject command reference for more details.\r
+\r
+There is also a command to clear out one or more lines in a filter. They are ...\r
+\r
+<tscreen><verb>\r
+clear/spots 1\r
+clear/spots all\r
+</verb></tscreen>\r
+\r
+There is clear/xxxx command for each type of filter.\r
+\r
+<P>\r
+and you can check that your filters have worked by the command ... \r
+\r
+<tscreen><verb> \r
+show/filter\r
+</verb></tscreen>\r
+\r
+<P>\r
+For now we are going to use spots for the examples, but you can apply the same\r
+principles to all types of filter.\r
+\r
+<sect1>Types of filter\r
+\r
+<P>\r
+There are two main types of filter, <em>accept</em> or <em>reject</em>. You \r
+can use either to achieve the result you want dependent on your own preference \r
+and which is more simple to do. It is pointless writing 8 lines of reject \r
+filters when 1 accept filter would do the same thing! Each filter has 10 \r
+lines (of any length) which are tried in order. If a line matches then the \r
+action you have specified is taken (ie reject means ignore it and accept \r
+means take it)\r
+\r
+<P>\r
+If you specify reject filters, then any lines that arrive that match the filter \r
+will be dumped but all else will be accepted. If you use an accept filter, \r
+then ONLY the lines in the filter will be accepted and all else will be dumped.\r
+For example if you have a single line <em>accept</em> filter ...\r
+\r
+<tscreen><verb>\r
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+then you will <em>ONLY</em> get VHF spots <em>from</em> or <em>to</em> CQ zones \r
+14, 15 and 16.\r
+\r
+<P>\r
+If you set a reject filter like this ...\r
+\r
+<tscreen><verb>\r
+reject/spots on hf/cw\r
+</verb></tscreen>\r
+\r
+Then you will get everything <em>EXCEPT</em> HF CW spots. You could make this \r
+single filter even more flexible. For example, if you are interested in IOTA \r
+and will work it even on CW even though normally you are not interested in \r
+CW, then you could say ...\r
+\r
+<tscreen><verb>\r
+reject/spots on hf/cw and not info iota\r
+</verb></tscreen>\r
+\r
+But in that case you might only be interested in iota and say:-\r
+\r
+<tscreen><verb>\r
+accept/spots not on hf/cw or info iota\r
+</verb></tscreen>\r
+\r
+which achieves exactly the same thing. You should choose one or the other \r
+until you are comfortable with the way it works. You can mix them if you \r
+wish (actually you can have an accept AND a reject on the same line) but \r
+don't attempt this until you are sure you know what you are doing!\r
+\r
+<P>\r
+You can arrange your filter lines into logical units, either for your own\r
+understanding or simply convenience. Here is an example ...\r
+\r
+<tscreen><verb>\r
+reject/spots 1 on hf/cw\r
+reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16) \r
+</verb></tscreen>\r
+\r
+What this does is to ignore all HF CW spots and also rejects any spots on VHF \r
+which don't either originate or spot someone in Europe. \r
+\r
+<P>\r
+This is an example where you would use a line number (1 and 2 in this case), if \r
+you leave the digit out, the system assumes '1'. Digits '0'-'9' are available. \r
+This make it easier to see just what filters you have set. It also makes it \r
+more simple to remove individual filters, during a contest for example.\r
+\r
+<P>\r
+You will notice in the above example that the second line has brackets. Look \r
+at the line logically. You can see there are 2 separate sections to it. We \r
+are saying reject spots that are VHF or above <em>APART</em> from those in \r
+zones 14, 15 and 16 (either spotted there or originated there). If you did \r
+not have the brackets to separate the 2 sections, then Spider would read it \r
+logically from the front and see a different expression entirely ...\r
+\r
+<tscreen><verb>\r
+(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 \r
+</verb></tscreen>\r
+\r
+The simple way to remember this is, if you use OR - use brackets. Whilst we are \r
+here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.\r
+\r
+As mentioned earlier, setting several filters can be more flexible than \r
+simply setting one complex one. Doing it in this way means that if you want \r
+to alter your filter you can just redefine or remove one or more lines of it or \r
+one line. For example ...\r
+\r
+<tscreen><verb>\r
+reject/spots 1 on hf/ssb\r
+</verb></tscreen>\r
+\r
+would redefine our earlier example, or \r
+\r
+<tscreen><verb>\r
+clear/spots 1\r
+</verb></tscreen>\r
+\r
+To remove all the filter lines in the spot filter ...\r
+\r
+<tscreen><verb>\r
+clear/spots all\r
+</verb></tscreen>\r
+\r
+<sect1>Filter options\r
+\r
+<P>\r
+You can filter in several different ways. The options are listed in the\r
+various helpfiles for accept, reject and filter.\r
+\r
+<sect1>Default filters\r
+\r
+<P>\r
+Sometimes all that is needed is a general rule for node connects. This can\r
+be done with a node_default filter. This rule will always be followed, even\r
+if the link is isolated, unless another filter is set specifically. Default\r
+rules can be set for nodes and users. They can be set for spots, announces,\r
+WWV and WCY. They can also be used for hops. An example might look like \r
+this ...\r
+\r
+<tscreen><verb>\r
+accept/spot node_default by_zone 14,15,16,20,33\r
+set/hops node_default spot 50\r
+</verb></tscreen>\r
+\r
+This filter is for spots only, you could set others for announce, WWV and WCY.\r
+This filter would work for ALL nodes unless a specific filter is written to \r
+override it for a particular node. You can also set a user_default should\r
+you require. It is important to note that default filters should be\r
+considered to be "connected". By this I mean that should you override the\r
+default filter for spots, you need to add a rule for the hops for spots also.\r
+\r
+<sect1>Advanced filtering\r
+\r
+<P>\r
+Once you are happy with the results you get, you may like to experiment. \r
+\r
+<P>\r
+The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU \r
+can be written with a mixed filter, for example ... \r
+\r
+<tscreen><verb>\r
+rej/spot on hf/cw\r
+acc/spot on 0/30000\r
+acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)\r
+</verb></tscreen>\r
+\r
+Note that the first filter has not been specified with a number. This will \r
+automatically be assumed to be number 1. In this case, we have said <em>reject all\r
+HF spots in the CW section of the bands but accept all others at HF. Also\r
+accept anything in VHF and above spotted in or by operators in the zones\r
+14, 15 and 16</em>. Each filter slot actually has a 'reject' slot and \r
+an 'accept' slot. The reject slot is executed BEFORE the accept slot.\r
+\r
+<P>\r
+It was mentioned earlier that after a reject test that doesn't match, the default \r
+for following tests is 'accept', the reverse is true for 'accept'. In the example \r
+what happens is that the reject is executed first, any non hf/cw spot is passed \r
+to the accept line, which lets through everything else on HF. The next filter line \r
+lets through just VHF/UHF spots from EU.\r
+\r
+<sect1>Basic hop control\r
+\r
+<P>\r
+In /spider/data you will find a file called hop_table.pl. This is the file \r
+that controls your hop count settings. It has a set of default hops on the \r
+various PC frames and also a set for each node you want to alter the hops for. \r
+You may be happy with the default settings of course, but this powerful tool \r
+can help to protect and improve the network. The file will look something \r
+like this ...\r
+\r
+<tscreen><verb>\r
+# \r
+# hop table construction\r
+# \r
+\r
+package DXProt;\r
+\r
+# default hopcount to use\r
+$def_hopcount = 5;\r
+\r
+# some variable hop counts based on message type\r
+%hopcount = \r
+(\r
+ 11 => 10,\r
+ 16 => 10,\r
+ 17 => 10,\r
+ 19 => 10,\r
+ 21 => 10,\r
+);\r
+\r
+\r
+# the per node hop control thingy\r
+\r
+\r
+%nodehops = \r
+(\r
+ GB7ADX => { 11 => 8,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+\r
+ GB7UDX => { 11 => 8,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+ GB7BAA => {\r
+ 11 => 5,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+);\r
+</verb></tscreen>\r
+\r
+<P>\r
+Each set of hops is contained within a pair of curly braces and contains a \r
+series of PC frame types. PC11 for example is a DX spot. The figures here \r
+are not exhaustive but should give you a good idea of how the file works.\r
+\r
+<P>\r
+SHould any of the nodecalls include an ssid, it is important to wrap the\r
+whole call in single quotes, like this ...\r
+\r
+<tscreen><verb>\r
+ 'DB0FHF-15' => {\r
+ 11 => 5,\r
+ 12 => 8,\r
+ 16 => 8,\r
+ 17 => 8,\r
+ 19 => 8,\r
+ 21 => 8,\r
+ },\r
+</verb></tscreen>\r
+\r
+If you do not do this, you will get errors and the file will not work as\r
+expected.\r
+\r
+<P>\r
+You can alter this file at any time, including whilst the cluster is running. \r
+If you alter the file during runtime, the command <em>load/hops</em> will \r
+bring your changes into effect.\r
+\r
+<sect1>Hop Control on Specific Nodes\r
+\r
+<p>You can set a callsign specific hop count for any of the standard filter\r
+options so:-\r
+\r
+<tscreen><verb>\r
+set/hops gb7djk spot 4\r
+set/hops node_default route 10\r
+set/hops gb7baa wcy 5\r
+</verb></tscreen>\r
+ \r
+all work on their specific area of the protocol.\r
+\r
+<p>\r
+The <em>set/hops</em> command overrides any hops that you have set otherwise.\r
+\r
+<p>\r
+You can show what hops have been set using the <em>show/hops</em> command.\r
+\r
+<sect1>Isolating networks\r
+\r
+<P>\r
+It is possible to isolate networks from each other on a "gateway" node using the\r
+ <em>set/isolate <node_call></em> command.\r
+ \r
+<P>\r
+The effect of this is to partition an isolated network completely from another \r
+node connected to your node. Your node will appear on and otherwise behave \r
+normally on every network to which you are connected, but data from an isolated \r
+network will not cross onto any other network or vice versa. However all the \r
+spot, announce and WWV traffic and personal messages will still be handled \r
+locally (because you are a real node on all connected networks), that is locally\r
+connected users will appear on all networks and will be able to access and \r
+receive information from all networks transparently. All routed messages will \r
+be sent as normal, so if a user on one network knows that you are a gateway for \r
+another network, he can still still send a talk/announce etc message via your \r
+node and it will be routed across.\r
+\r
+<P>\r
+If you use isolate on a node connection you will continue to receive\r
+all information from the isolated partner, however you will not pass\r
+any information back to the isolated node. There are times when you\r
+would like to forward only spots across a link (maybe during a contest\r
+for example). To do this, isolate the node in the normal way and use\r
+an <em>acc/spot >call< all</em> filter to override the isolate. \r
+\r
+<sect>Other filters\r
+\r
+<sect1>Filtering Mail\r
+\r
+<P>\r
+In the /spider/msg directory you will find a file called badmsg.pl.issue. Rename\r
+this to badmsg.pl and edit the file. The original looks something like this ....\r
+\r
+<tscreen><verb>\r
+\r
+# the list of regexes for messages that we won't store having\r
+# received them (bear in mind that we must receive them fully before\r
+# we can bin them)\r
+\r
+\r
+# The format of each line is as follows\r
+\r
+# type source pattern \r
+# P/B/F T/F/O/S regex \r
+\r
+# type: P - private, B - bulletin (msg), F - file (ak1a bull)\r
+# source: T - to field, F - from field, O - origin, S - subject \r
+# pattern: a perl regex on the field requested\r
+\r
+# Currently only type B and P msgs are affected by this code.\r
+# \r
+# The list is read from the top down, the first pattern that matches\r
+# causes the action to be taken.\r
+\r
+# The pattern can be undef or 0 in which case it will always be selected\r
+# for the action specified\r
+\r
+\r
+\r
+package DXMsg;\r
+\r
+@badmsg = (\r
+'B', 'T', 'SALE', \r
+'B', 'T', 'WANTED',\r
+'B', 'S', 'WANTED',\r
+'B', 'S', 'SALE', \r
+'B', 'S', 'WTB',\r
+'B', 'S', 'WTS',\r
+'B', 'T', 'FS',\r
+);\r
+</verb></tscreen>\r
+\r
+<P>\r
+I think this is fairly self explanatory. It is simply a list of subject \r
+headers that we do not want to pass on to either the users of the cluster or \r
+the other cluster nodes that we are linked to. This is usually because of \r
+rules and regulations pertaining to items for sale etc in a particular country.\r
+\r
+\r
+<sect1>Filtering words from text fields in Announce, Talk and DX spots\r
+\r
+<p>\r
+From version 1.48 onwards the interface to this has changed. You can now\r
+use the commands <em>set/badword</em> to add words that you are not prepared\r
+to see on the cluster, <em>unset/badword</em> to allow that word again and \r
+<em>show/badword</em> to list the words that you have set.\r
+\r
+<p>\r
+If you have a previous <em>/spider/data/badwords</em>, the first time you start\r
+the node, it will read and convert this file to the new commands. The old style\r
+file will then be removed.\r
+\r
+<sect1>Stopping (possibly bad) DX Spots from Nodes or Spotters\r
+\r
+<p> \r
+There are a number of commands that control whether a spot progresses\r
+any further by regarding it as "bad" in some way.\r
+\r
+<p>\r
+A DX Spot has a number of fields which can be checked to see whether they\r
+contain "bad" values, they are: the DX callsign itself, the Spotter and\r
+the Originating Node.\r
+\r
+<p>\r
+There are a set of commands which allow the sysop to control whether a\r
+spot continues:-\r
+\r
+<tscreen><verb>\r
+set/baddx\r
+set/badspotter\r
+set/badnode\r
+</verb></tscreen>\r
+\r
+These work in the same as the <em>set/badword</em> command, you can add\r
+any words or callsigns or whatever to the appropriate database. For\r
+example, to stop a spot from a particular node you do:\r
+\r
+<tscreen><verb>\r
+set/badnode gb7djk gb7dxc\r
+</verb></tscreen>\r
+\r
+a bad spotter:\r
+\r
+<tscreen><verb>\r
+set/badspotter b0mb p1rat nocall\r
+</verb></tscreen>\r
+\r
+and some bad dx:\r
+\r
+<tscreen><verb>\r
+set/baddx video wsjt\r
+</verb></tscreen>\r
+\r
+You can remove a word using the appropriate unset command\r
+(<em>unset/baddx, unset/badspotter, unset/badnode</em>) or list them\r
+using one of <em>show/baddx, show/badspotter</em> and\r
+<em>show/badnode</em>.\r
+\r
+<sect>Mail\r
+\r
+<P>\r
+DXSpider deals seamlessly with standard AK1A type mail. It supports both\r
+personal and bulletin mail and the sysop has additional commands to ensure\r
+that mail gets to where it is meant. DXSpider will send mail almost\r
+immediately, assuming that the target is on line. However, only one\r
+mail message is dealt with at any one time. If a mail message is already\r
+being sent or recieved, then the new message will be queued until it has\r
+finished.\r
+\r
+The cluster mail is automatically deleted after 30 days unless the sysop\r
+sets the "keep" flag using the <em>msg</em> command.\r
+\r
+<sect1>Personal mail\r
+\r
+<P>\r
+Personal mail is sent using the <em>sp</em> command. This is actually the\r
+default method of sending mail and so a simple <em>s</em> for send will do.\r
+A full list of the send commands and options is in the <em>command set</em>\r
+section, so I will not duplicate them here.\r
+\r
+<sect1>Bulletin mail\r
+\r
+<P>\r
+Bulletin mail is sent by using the <em>sb</em> command. This is one of the\r
+most common mistakes users make when sending mail. They send a bulletin\r
+mail with <em>s</em> or <em>sp</em> instead of <em>sb</em> and of course\r
+the message never leaves the cluster. This can be rectified by the sysop\r
+by using the <em>msg</em> command.\r
+\r
+<P>Bulletin addresses can be set using the Forward.pl file.\r
+\r
+<sect1>Forward.pl\r
+\r
+<P>\r
+DXSpider receives all and any mail sent to it without any alterations needed\r
+in files. Because personal and bulletin mail are treated differently, there\r
+is no need for a list of accepted bulletin addresses. It is necessary, however,\r
+to tell the program which links accept which bulletins. For example, it is\r
+pointless sending bulletins addresses to "UK" to any links other than UK\r
+ones. The file that does this is called forward.pl and lives in /spider/msg.\r
+At default, like other spider files it is named forward.pl.issue. Rename it\r
+to forward.pl and edit the file to match your requirements.\r
+The format is below ...\r
+\r
+<tscreen><verb>\r
+#\r
+# this is an example message forwarding file for the system\r
+#\r
+# The format of each line is as follows\r
+#\r
+# type to/from/at pattern action destinations\r
+# P/B/F T/F/A regex I/F [ call [, call ...] ]\r
+#\r
+# type: P - private, B - bulletin (msg), F - file (ak1a bull)\r
+# to/from/at: T - to field, F - from field, A - home bbs, O - origin \r
+# pattern: a perl regex on the field requested\r
+# action: I - ignore, F - forward\r
+# destinations: a reference to an array containing node callsigns\r
+#\r
+# if it is non-private and isn't in here then it won't get forwarded \r
+#\r
+# Currently only type B msgs are affected by this code.\r
+# \r
+# The list is read from the top down, the first pattern that matches\r
+# causes the action to be taken.\r
+#\r
+# The pattern can be undef or 0 in which case it will always be selected\r
+# for the action specified\r
+#\r
+# If the BBS list is undef or 0 and the action is 'F' (and it matches the\r
+# pattern) then it will always be forwarded to every node that doesn't have \r
+# it (I strongly recommend you don't use this unless you REALLY mean it, if\r
+# you allow a new link with this on EVERY bull will be forwarded immediately\r
+# on first connection)\r
+#\r
+\r
+package DXMsg;\r
+\r
+@forward = (\r
+'B', 'T', 'LOCAL', 'F', [ qw(GB7MBC) ],\r
+'B', 'T', 'ALL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'UK', 'F', [ qw(GB7BAA GB7ADX) ],\r
+'B', 'T', 'QSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'QSLINF', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DX', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DXINFO', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DXNEWS', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'DXQSL', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+'B', 'T', 'SYSOP', 'F', [ qw(GB7BAA GB7ADX) ],\r
+'B', 'T', '50MHZ', 'F', [ qw(GB7BAA GB7ADX PA4AB-14) ],\r
+);\r
+</verb></tscreen>\r
+\r
+Simply insert a bulletin address and state in the brackets where you wish\r
+that mail to go. For example, you can see here that mail sent to "UK" will\r
+only be sent to the UK links and not to PA4AB-14.\r
+\r
+<P>\r
+To force the cluster to reread the file use load/forward\r
+\r
+<P>\r
+NB: If a user tries to send mail to a bulletin address that does not exist\r
+in this file, they will get an error.\r
+\r
+<sect1>The msg command\r
+\r
+<P>\r
+The <em>msg</em> command is a very powerful and flexible tool for the\r
+sysop. It allows the sysop to alter to and from fields and make other\r
+changes to manage the cluster mail.\r
+\r
+Here is a full list of the various options ...\r
+\r
+<tscreen><verb>\r
+ MSG TO <msgno> <call> - change TO callsign to <call>\r
+ MSG FRom <msgno> <call> - change FROM callsign to <call>\r
+ MSG PRrivate <msgno> - set private flag\r
+ MSG NOPRrivate <msgno> - unset private flag\r
+ MSG RR <msgno> - set RR flag\r
+ MSG NORR <msgno> - unset RR flag\r
+ MSG KEep <msgno> - set the keep flag (message won't be deleted ever)\r
+ MSG NOKEep <msgno> - unset the keep flag\r
+ MSG SUbject <msgno> <new> - change the subject to <new>\r
+ MSG WAittime <msgno> - remove any waiting time for this message\r
+ MSG NOREad <msgno> - mark message as unread\r
+ MSG REad <msgno> - mark message as read\r
+ MSG QUeue - queue any outstanding bulletins\r
+ MSG QUeue 1 - queue any outstanding private messages\r
+</verb></tscreen>\r
+\r
+These commands are simply typed from within the cluster as the sysop user.\r
+\r
+<sect1>Message status\r
+\r
+<P>\r
+You can check on a message from within the cluster by using the command\r
+<em>stat/msg</em>. This will give you additional information on the\r
+message number including which nodes have received it, which node it\r
+was received from and when etc. Here is an example of the output of\r
+the command ...\r
+\r
+<tscreen><verb>\r
+G0VGS de GB7MBC 28-Jan-2001 1308Z >\r
+stat/msg 6869\r
+ From: GB7DJK\r
+ Msg Time: 26-Jan-2001 1302Z\r
+ Msgno: 6869\r
+ Origin: GB7DJK\r
+ Size: 8012\r
+ Subject: AMSAT 2line KEPS 01025.AMSAT\r
+ To: UK\r
+Got it Nodes: GB7BAA, GB7ADX\r
+ Private: 0\r
+Read Confirm: 0\r
+ Times read: 0\r
+G0VGS de GB7MBC 28-Jan-2001 1308Z >\r
+</verb></tscreen>\r
+\r
+<sect1>Filtering mail\r
+\r
+<P>\r
+This is described in the section on <em>Other filters</em> so I will not\r
+duplicate it here.\r
+\r
+<sect1>Distribution lists\r
+\r
+<P>\r
+Distribution lists are simply a list of users to send certain types of\r
+mail to. An example of this is mail you only wish to send to other\r
+sysops. In /spider/msg there is a directory called <em>distro</em>. You\r
+put any distibution lists in here. For example, here is a file called\r
+SYSOP.pl that caters for the UK sysops.\r
+\r
+<tscreen><verb>\r
+qw(GB7TLH GB7DJK GB7DXM GB7CDX GB7BPQ GB7DXN GB7MBC GB7MBC-6 GB7MDX\r
+ GB7NDX GB7SDX GB7TDX GB7UDX GB7YDX GB7ADX GB7BAA GB7DXA GB7DXH \r
+ GB7DXK GB7DXI GB7DXS)\r
+</verb></tscreen>\r
+\r
+Any mail sent to "sysop" would only be sent to the callsigns in this list.\r
+\r
+<sect1>BBS interface\r
+\r
+<P>\r
+Spider provides a simple BBS interface. No input is required from the sysop\r
+of the cluster at all. The BBS simply sets the cluster as a BBS and pushes\r
+any required mail to the cluster. No mail can flow from Spider to the BBS,\r
+the interface is one-way.\r
+\r
+<P>\r
+Please be careful not to flood the cluster network with unnecessary mail.\r
+Make sure you only send mail to the clusters that want it by using the\r
+Forward.pl file very carefully.\r
+\r
+<sect>Scripts\r
+\r
+<p>\r
+From 1.48 onwards it will become increasingly possible to control DXSpider's\r
+operation with scripts of various kinds.\r
+\r
+<P>\r
+The directory /spider/scripts is where it all happens and is used for several \r
+things. Firstly it contains a file called startup that can be used to call \r
+in any changes to the cluster from the default settings on startup. This\r
+script is executed immediately after all initialisation of the node is done\r
+but before any connections are possible. Examples of this include how many \r
+spots it is possible to get with the sh/dx command, whether you want \r
+registration/passwords to be permanently on etc. An example file is shown \r
+below and is included in the distribution as startup.issue.\r
+\r
+<tscreen><verb>\r
+#\r
+# startup script example\r
+#\r
+# set maximum no of spots allowed to 100\r
+# set/var $Spot::maxspots = 100\r
+#\r
+# Set registration on\r
+# set/var $main::reqreg = 1\r
+#\r
+# Set passwords on\r
+# set/var $main::passwdreq = 1\r
+#\r
+</verb></tscreen>\r
+\r
+<P>\r
+As usual, any text behind a # is treated as a comment and not read. To use\r
+this file, simply rename it from startup.issue to startup. In our example\r
+above there are three options. The first option is the amount of spots that\r
+a user can request with the <em>sh/dx</em> command. Normally the default is\r
+to give 10 spots unless the user specifies more. Without this line enabled,\r
+the maximum a user can request is 100 spots. Depending on your link quality\r
+you may wish to enable more or less by specifying the number.\r
+\r
+<P>\r
+The other 2 options are dealt with more fully in the security section.\r
+\r
+<P>\r
+Secondly, it is used to store the login scripts for users and nodes. Currently\r
+this can only be done by the sysop but it is envisaged that eventually users will \r
+be able to set their own. An example is included in the distibution but here is \r
+a further example.\r
+\r
+<tscreen><verb>\r
+#\r
+# G0FYD\r
+#\r
+blank +\r
+sh/wwv 3\r
+blank +\r
+sh/dx \r
+blank +\r
+t g0jhc You abt?\r
+blank +\r
+</verb></tscreen>\r
+\r
+The lines in between commands can simply insert a blank line or a character\r
+such as a + sign to make the output easier to read. Simply create this script\r
+with your favourite editor and save it with the callsign of the user as the\r
+filename. Filenames should always be in lower case.\r
+\r
+<P>\r
+Commands can be inserted in the same way for nodes. A node may wish a series\r
+of commands to be issued on login, such as a merge command for example.\r
+\r
+<P>\r
+Thirdly, there are 2 default scripts for users and nodes who do not have a\r
+specifically defined script. These are <em>user_default</em> and\r
+<em>node_default</em>\r
+\r
+<sect>Databases\r
+\r
+<P>\r
+Spider allows the creation of local or remote databases. It supports\r
+chained databases, allowing several different databases to be scanned\r
+with one simple command. Importing of databases is limited at present\r
+to the standard AK1A databases such as OBLAST and the DB0SDX QSL \r
+database but will expand with time.\r
+\r
+<sect1>Creating databases\r
+\r
+<P>\r
+Creating a database could not be more simple. All the commands are\r
+sent from the cluster prompt as the <em>sysop</em> user.\r
+\r
+To create a database you use the command <em>dbcreate</em>. It can\r
+be used in 3 different ways like so ..\r
+\r
+<tscreen><verb>\r
+dbcreate <name>\r
+</verb></tscreen>\r
+\r
+To simply create a database locally, you just tell the command the\r
+name of the database. This does not create the actual database, it\r
+simply defines it to say that it exists.\r
+\r
+<tscreen><verb>\r
+dbcreate <name> chain <name> [<name>...]\r
+</verb></tscreen>\r
+\r
+This creates a chained database entry. The first database will be\r
+scanned, then the second, the third etc...\r
+\r
+<tscreen><verb>\r
+dbcreate <name> remote <name>\r
+</verb></tscreen>\r
+\r
+This creates a remote entry. the first name field is the database\r
+name at the remote node, then the remote switch, then the actual\r
+node_call of the remote node, for example...\r
+\r
+<tscreen><verb>\r
+dbcreate buckmaster remote gb7dxc\r
+</verb></tscreen>\r
+\r
+Remote databases cannot be chained, however, the last database in a\r
+chain can be a remote database.\r
+\r
+<sect1>Importing databases\r
+\r
+<P>\r
+The only databases that Spider can currently import are the standard\r
+AK1A databases such as OBLAST or the DB0SDX qsl and address database.\r
+This will be added to with time.\r
+\r
+To import such a database, first put the file somewhere useful like /tmp\r
+and then issue the following command ...\r
+\r
+<tscreen><verb>\r
+dbimport oblast /tmp/OBLAST.FUL\r
+</verb></tscreen>\r
+\r
+This will update the existing local oblast database or create it if\r
+it does not exist.\r
+\r
+<sect1>Checking available databases\r
+\r
+<P>\r
+Once a database is created, you will want to check that it has been\r
+added. To do this use the <em>dbavail</em> command. This will\r
+output the available databases. For example ...\r
+\r
+<tscreen><verb>\r
+dbavail\r
+DB Name Location Chain\r
+qsl Local\r
+buck GB7ADX\r
+hftest GB7DXM\r
+G0VGS de GB7MBC 3-Feb-2001 1925Z >\r
+</verb></tscreen>\r
+\r
+<sect1>Looking up databases\r
+\r
+<P>\r
+To look for information in a defined database, simply use the <em>dbshow</em>\r
+command, for example ...\r
+\r
+<tscreen><verb>\r
+dbshow buckmaster G0YLM\r
+</verb></tscreen>\r
+\r
+will show the information for the callsign G0YLM from the buckmaster\r
+database if it exists. To make things more standard for the users\r
+you can add an entry in the Aliases file so that it looks like a standard \r
+<em>show</em> command like this ...\r
+\r
+<tscreen><verb>\r
+'^sh\w*/buc', 'dbshow buckmaster', 'dbshow',\r
+</verb></tscreen>\r
+\r
+Now you can simply use show/buckmaster or an abreviation.\r
+\r
+<sect1>Removing databases\r
+\r
+<P>\r
+To delete an existing database you use the <em>dbremove</em> command.\r
+For example ...\r
+\r
+<tscreen><verb>\r
+dbremove oblast\r
+</verb></tscreen>\r
+\r
+would remove the oblast database and its associated datafile from the\r
+system. There are no warnings or recovery possible from this command.\r
+If you remove a database it ceases to exist and would have to be created\r
+from scratch if you still required it.\r
+\r
+<sect>Information, files and useful programs\r
+\r
+<sect1>MOTD\r
+\r
+<P>\r
+One of the more important things a cluster sysop needs to do is to get \r
+information to his users. The simplest way to do this is to have a banner \r
+that is sent to the user on login. This is know as a "message of the day" \r
+or "motd". To set this up, simply create a file in /spider/data called motd \r
+and edit it to say whatever you want. It is purely a text file and will be \r
+sent automatically to anyone logging in to the cluster.\r
+\r
+<sect1>MOTD_NOR\r
+\r
+<P>\r
+This message of the day file lives in the same directory as the standard\r
+motd file but is only sent to non-registered users. Once registered they\r
+will receive the same message as any other user.\r
+\r
+<sect1>Downtime message\r
+\r
+<P>\r
+If for any reason the cluster is down, maybe for upgrade or maintenance but \r
+the machine is still running, a message can be sent to the user advising them \r
+of the fact. This message lives in the /spider/data directory and is called\r
+"offline". Simply create the file and edit it to say whatever you wish. \r
+This file will be sent to a user attempting to log into the cluster when\r
+DXSpider is not actually running.\r
+\r
+<sect1>Other text messages\r
+\r
+<P>\r
+You can set other text messages to be read by the user if they input the file \r
+name. This could be for news items or maybe information for new users. \r
+To set this up, make a directory under /spider called <em>packclus</em>. \r
+Under this directory you can create files called <em>news</em> or <em>newuser</em>\r
+for example. In fact you can create files with any names you like. These can \r
+be listed by the user with the command ....\r
+\r
+<tscreen><verb>\r
+show/files\r
+</verb></tscreen>\r
+\r
+They can be read by the user by typing the command ....\r
+\r
+<tscreen><verb>\r
+type news\r
+</verb></tscreen>\r
+\r
+If the file they want to read is called <em>news</em>. You could also set \r
+an alias for this in the Alias file to allow them just to type <em>news</em>\r
+\r
+<P>\r
+You can also store other information in this directory, either directly or \r
+nested under directories. One use for this would be to store DX bulletins \r
+such as the OPDX bulletins. These can be listed and read by the user. \r
+To keep things tidy, make a directory under /spider/packclus called\r
+<em>bulletin</em>. Now copy any OPDX or similar bulletins into it. These \r
+can be listed by the user in the same way as above using the <em>show/files</em>\r
+command with an extension for the bulletin directory you have just created, \r
+like this ....\r
+\r
+<tscreen><verb>\r
+show/files bulletin\r
+</verb></tscreen>\r
+\r
+<P>\r
+An example would look like this ....\r
+\r
+<tscreen><verb>\r
+sh/files\r
+bulletin DIR 20-Dec-1999 1715Z news 1602 14-Dec-1999 1330Z\r
+</verb></tscreen>\r
+\r
+You can see that in the files area (basically the packclus directory) there is a \r
+file called <em>news</em> and a directory called <em>bulletin</em>. You can \r
+also see that dates they were created. In the case of the file <em>news</em>, \r
+you can also see the time it was last modified, a good clue as to whether the \r
+file has been updated since you last read it. To read the file called \r
+<em>news</em> you would simply issue the command ....\r
+\r
+<tscreen><verb>\r
+type news\r
+</verb></tscreen>\r
+\r
+To look what is in the bulletin directory you issue the command ....\r
+\r
+<tscreen><verb>\r
+show/files bulletin\r
+opdx390 21381 29-Nov-1999 1621Z opdx390.1 1670 29-Nov-1999 1621Z\r
+opdx390.2 2193 29-Nov-1999 1621Z opdx391 25045 29-Nov-1999 1621Z \r
+opdx392 35969 29-Nov-1999 1621Z opdx393 15023 29-Nov-1999 1621Z \r
+opdx394 33429 29-Nov-1999 1621Z opdx394.1 3116 29-Nov-1999 1621Z \r
+opdx395 24319 29-Nov-1999 1621Z opdx396 32647 29-Nov-1999 1621Z\r
+opdx396.1 5537 29-Nov-1999 1621Z opdx396.2 6242 29-Nov-1999 1621Z\r
+opdx397 18433 29-Nov-1999 1621Z opdx398 19961 29-Nov-1999 1621Z \r
+opdx399 17719 29-Nov-1999 1621Z opdx400 19600 29-Nov-1999 1621Z\r
+opdx401 27738 29-Nov-1999 1621Z opdx402 18698 29-Nov-1999 1621Z\r
+opdx403 24994 29-Nov-1999 1621Z opdx404 15685 29-Nov-1999 1621Z\r
+opdx405 13984 29-Nov-1999 1621Z opdx405.1 4166 29-Nov-1999 1621Z\r
+opdx406 28934 29-Nov-1999 1621Z opdx407 24153 29-Nov-1999 1621Z\r
+opdx408 15081 29-Nov-1999 1621Z opdx409 23234 29-Nov-1999 1621Z\r
+Press Enter to continue, A to abort (16 lines) >\r
+</verb></tscreen>\r
+\r
+You can now read any file in this directory using the type command, like this ....\r
+\r
+<tscreen><verb>\r
+type bulletin/opdx391\r
+Ohio/Penn DX Bulletin No. 391\r
+The Ohio/Penn Dx PacketCluster\r
+DX Bulletin No. 391\r
+BID: $OPDX.391\r
+January 11, 1999\r
+Editor Tedd Mirgliotta, KB8NW\r
+Provided by BARF-80 BBS Cleveland, Ohio\r
+Online at 440-237-8208 28.8k-1200 Baud 8/N/1 (New Area Code!)\r
+Thanks to the Northern Ohio Amateur Radio Society, Northern Ohio DX\r
+Association, Ohio/Penn PacketCluster Network, K1XN & Golist, WB2RAJ/WB2YQH\r
+& The 59(9) DXReport, W3UR & The Daily DX, K3TEJ, KN4UG, W4DC, NC6J, N6HR,\r
+Press Enter to continue, A to abort (508 lines) >\r
+</verb></tscreen>\r
+\r
+The page length will of course depend on what you have it set to!\r
+\r
+<sect1>The Aliases file\r
+\r
+<P>\r
+You will find a file in /spider/cmd/ called Aliases. This is the file that\r
+controls what a user gets when issuing a command. It is also possible to\r
+create your own aliases for databases and files you create locally.\r
+\r
+<P>\r
+You should not alter the original file in /spider/cmd/ but create a new file\r
+with the same name in /spider/local_cmd. This means that any new Aliases files\r
+that is downloaded will not overwrite your self created Aliases and also that\r
+you do not override any new Aliases with your copy in /spider/local_cmd/. You\r
+must remember that any files you store in /spider/local/ or /spider/local_cmd\r
+override the originals if the same lines are used in both files.\r
+\r
+<P>\r
+The best way of dealing with all this then is to only put your own locally\r
+created Aliases in the copy in /spider/local_cmd. The example below is\r
+currently in use at GB7MBC.\r
+\r
+<tscreen><verb>\r
+\r
+#\r
+# Local Aliases File\r
+#\r
+\r
+package CmdAlias;\r
+\r
+%alias = (\r
+ 'n' => [\r
+ '^news$', 'type news', 'type',\r
+ ],\r
+ 's' => [\r
+ '^sh\w*/buck$', 'show/qrz', 'show',\r
+ '^sh\w*/hftest$', 'dbshow hftest', 'dbshow',\r
+ '^sh\w*/qsl$', 'dbshow qsl', 'dbshow',\r
+ '^sh\w*/vhf$', 'dbshow vhf', 'dbshow',\r
+ '^sh\w*/vhftest$', 'dbshow vhftest', 'dbshow',\r
+ ],\r
+)\r
+\r
+</verb></tscreen>\r
+\r
+<P>\r
+Each alphabetical section should be preceded by the initial letter and the section\r
+should be wrapped in square brackets as you can see. The syntax is straightforward.\r
+The first section on each line is the new command that will be allowed once the\r
+alias is included. The second section is the command it is replacing and the last\r
+section is the actual command that is being used.\r
+\r
+<P>\r
+The eagle-eyed amongst you will have noticed that in the first section, the new\r
+alias command has a '^' at the start and a '$' at the end. Basically these force\r
+a perfect match on the alias. The '^' says match the beginning exactly and the\r
+'$' says match the end exactly. This prevents unwanted and unintentional matches\r
+with similar commands.\r
+\r
+<P>\r
+I have 3 different types of alias in this file. At the top is an alias for 'news'. \r
+This is a file I have created in the /spider/packclus/ directory where I can inform \r
+users of new developments or points of interest. In it's initial form a user would \r
+have to use the command <em>type news</em>. The alias allows them to simply type \r
+<em>news</em> to get the info. Second is an alias for the <em>show/qrz</em>\r
+command so that those users used to the original <em>show/buck</em> command in\r
+AK1A will not get an error, and the rest of the lines are for locally created\r
+databases so that a user can type <em>show/hftest</em> instead of having to use\r
+the command <em>dbshow hftest</em> which is not as intuitive.\r
+\r
+<P>\r
+This file is just an example and you should edit it to your own requirements.\r
+Once created, simply issue the command <em>load/alias</em> at the cluster\r
+prompt as the sysop user and the aliases should be available.\r
+\r
+\r
+<sect1>Console.pl\r
+\r
+<P>\r
+In later versions of Spider a simple console program is provided for the sysop. \r
+This has a type ahead buffer with line editing facilities and colour for spots,\r
+announces etc. To use this program, simply use console.pl instead of client.\r
+\r
+<P>\r
+To edit the colours, copy /spider/perl/Console.pl to /spider/local and edit the \r
+file with your favourite editor.\r
+\r
+<sect1>Updating kepler data\r
+\r
+<P>\r
+Spider has a powerful and flexible show/satellite command. In order for\r
+this to be accurate, the kepler data has to be updated regularly. In\r
+general, this data is available as an email or via cluster mail.\r
+Updating it is simple. First you need to export the mail message as a\r
+file. You do this with the <em>export</em> command from the cluster prompt\r
+as the sysop. For example ...\r
+\r
+<tscreen><verb>\r
+export 5467 /spider/perl/keps.in\r
+</verb></tscreen>\r
+\r
+<P>\r
+would export message number 5467 as a file called keps.in in the\r
+/spider/perl directory.\r
+\r
+<P>\r
+Now login to a VT as sysop and cd /spider/perl. There is a command in\r
+the perl directory called <em>convkeps.pl</em>. All we need to do now is\r
+convert the file like so ...\r
+\r
+<tscreen><verb>\r
+./convkeps.pl keps.in\r
+</verb></tscreen>\r
+\r
+<P>\r
+Now go back to the cluster and issue the command ...\r
+\r
+<tscreen><verb>\r
+load/keps\r
+</verb></tscreen>\r
+\r
+<P>\r
+That is it! the kepler data has been updated.\r
+\r
+<sect1>The QRZ callbook\r
+\r
+<P>\r
+The command <em>sh/qrz</em> will only work once you have followed a few\r
+simple steps. First you need to get a user ID and password from qrz.com.\r
+Simply go to the site and create one. Secondly you need to copy the file\r
+/spider/perl/Internet.pm to /spider/local and alter it to match your user\r
+ID and password. You also at this point need to set $allow=1 to complete\r
+the setup. Many thanks to Fred Lloyd, the proprieter of\r
+<htmlurl url="http://www.qrz.com" name="qrz.com"> for allowing this access.\r
+\r
+<sect1>Connecting logging programs\r
+\r
+<P>\r
+There appear to be very few logging programs out there that support telnet\r
+especially the popular ones like LogEQF, Turbolog etc. This can make it\r
+difficult to connect to your own cluster!\r
+The way to do it is to make the logging program think it has a TNC attached\r
+to a com port on the logging PC and 'push' a linux login out to it.\r
+This is achieved very simply by the use of <em>agetty</em>.\r
+\r
+<P>\r
+All that is required is to add a line in /etc/inittab to have the client\r
+ready for a connection on the com port of your choice. Remember that in\r
+Linux, the com ports start at ttyS0 for com1, ttyS1 for com2 etc.\r
+\r
+<tscreen><verb>\r
+c4:2345:respawn:/sbin/agetty -L 9600 ttyS1\r
+</verb></tscreen>\r
+\r
+<P>\r
+Add this after the standard runlevel lines in /etc/inittab. The above\r
+line works on ttyS1 (com2). Now as root, issue the command <em>telinit q</em>\r
+and it should be ready for connection. All that is required is a 3 wire\r
+serial lead (tx, rx and signal ground). Tell you logging program to use\r
+8n1 at 9600 baud and you should see a Linux login prompt. Login as normal\r
+and then telnet from there to the cluster.\r
+\r
+<sect>Java Web applet\r
+\r
+<P>\r
+In the spider tree will be a directory <em>spider-web</em>. This is a\r
+neat little java web applet that can be run from a website. The applet\r
+must run on the same machine as the cluster. The included README file is\r
+shown below.\r
+\r
+<P>\r
+I should comment here that the applet is precompiled, that is, ready to go.\r
+It was compiled using JDK1.3.1. If your version is earlier than this then it\r
+may not work. Should that be the case you need to recompile or update your\r
+JDK. To recompile do the following ...\r
+\r
+<tscreen><verb>\r
+cd /spider/spider-web\r
+rm *.class\r
+/usr/bin/javac spiderclient.java\r
+</verb></tscreen>\r
+\r
+<P>\r
+I have used /usr/bin/javac as an example, your path to javac may be different.\r
+\r
+<verb>\r
+Spider-WEB v0.6b\r
+\r
+Completely based on a clx web client written in Java by dl6dbh\r
+(ftp://clx.muc.de/pub/clx/clx-java_10130001.tgz)\r
+\r
+The webserver has to run on the same machine as your DxSpider software!\r
+\r
+It is assumed that you have Java installed. You need JDK1.3.1 at least.\r
+\r
+Installation instructions (Performed as root):\r
+\r
+Put all the files in the spider-web directory into a newly created directory\r
+under the DocumentRoot of your websever for instance 'client'. In my case\r
+this is: /home/httpd/html/client/ although ymmv. For Suse the correct\r
+path should be /usr/local/httpd/htdocs/client/ for example.\r
+\r
+Move spider.cgi to the cgi-bin directory of your webserver, in my case that is\r
+/home/httpd/cgi-bin/ although ymmv. For Suse the correct path should be\r
+/usr/local/httpd/cgi-bin/ for example.\r
+\r
+Change the permissions of the files to ensure they are correct, obviously you\r
+will need to use the correct path the the files according to your system:\r
+\r
+chmod 755 /home/httpd/html/cgi-bin/spider.cgi\r
+chmod -R 755 /home/httpd/html/client/\r
+\r
+By default the spider.cgi script should pick up your hostname (As long as this\r
+is set correctly). If it does not or your hostname differs from the name that\r
+you attach to the public address that you are using, then edit spider.cgi :\r
+\r
+# Uncomment and set the hostname manually here if the above fails.\r
+# $HOSTNAME = "gb7mbc.spoo.org" ;\r
+$PORT = "8000" ;\r
+\r
+'HOSTNAME' is the hostname of your cluster.\r
+\r
+'PORT' is the portnumber that you use to connect to your DxSpider via\r
+telnet (see Listeners.pm)\r
+\r
+NOTE: If you can start the console but cannot connect to the cluster from it,\r
+then it is possible that the machine you are on cannot resolve the hostname of \r
+your cluster machine. If this is the case, you need to set your hostname \r
+manually as above.\r
+\r
+You also need to set the $NODECALL variable. This prints the name of your\r
+choosing (probably your cluster callsign) on the html page.\r
+\r
+You now can connect to Spider-Web via http://yourserver/cgi-bin/spider.cgi\r
+</verb>\r
+\r
+<sect>Web based statistics\r
+\r
+<P>\r
+From version 1.50, you can use the freeware software MRTG to produce\r
+really nice graphical statistics on your web site. For an example\r
+try <htmlurl url="http://www.gb7mbc.net/mrtg/stats.html" name="http://www.gb7mbc.net/mrtg/stats.html">.\r
+\r
+<P>\r
+The following should help you get it all working.\r
+\r
+<P>\r
+First you need to download the latest version of MRTG from <htmlurl url="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/" name="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/">.\r
+You will also need the following files..\r
+\r
+<tscreen><verb>\r
+libpng-1.0.14.tar.gz\r
+zlib-1.1.4.tar.gz\r
+gd-1.8.3.tar.gz\r
+</verb></tscreen>\r
+\r
+Login to your machine as the root user, put all the downloaded files \r
+in /usr/local/src/ (or wherever you prefer) and untar and compile them. \r
+All the information to compile and install these sources come with them.\r
+After compilation and installation, you will find MRTG in /usr/local/mrtg-2.\r
+\r
+<P>\r
+Now copy all the files in /usr/local/src/mrtg-2.9.22/images/ to \r
+/spider/html/mrtg/\r
+\r
+<P>\r
+You now need to make 2 symbolic links like below...\r
+\r
+<tscreen><verb>\r
+ln -s /usr/local/mrtg-2/bin/mrtg /usr/bin/mrtg\r
+ln -s /usr/local/mrtg-2/lib/mrtg2 /usr/lib/mrtg2\r
+</verb></tscreen>\r
+\r
+<P>\r
+Now login to the cluster with your sysop callsign and run the command \r
+"mrtg all".\r
+\r
+<P>Now you are nearly there! Login as the sysop user and change to the\r
+/spider/html/mrtg/ directory. Now run the command <em>indexmaker</em> as\r
+shown below...\r
+\r
+<tscreen><verb>\r
+indexmaker --output stats.html --columns=1 --title "MRTG statistics for GB7DJK" ../../mrtg/mrtg.cfg\r
+</verb></tscreen>\r
+\r
+Changing the callsign for your own cluster callsign of course!\r
+\r
+<P>\r
+And finally you need to login as the root user and create one last\r
+symbolic link. Where this points will depend on where your html\r
+documents are kept. For RedHat systems you use...\r
+\r
+<tscreen><verb>\r
+ln -s /home/sysop/spider/html/mrtg /home/httpd/html/mrtg\r
+</verb></tscreen>\r
+\r
+and for SuSE systems...\r
+\r
+<tscreen><verb>\r
+ln -s /home/sysop/spider/html/mrtg /usr/local/httpd/htdocs/mrtg\r
+</verb></tscreen>\r
+\r
+If you now point your browser to your website as below it should all\r
+be happening!\r
+\r
+<tscreen><verb>\r
+http://www.xxx.xxx/mrtg/stats.html\r
+</verb></tscreen>\r
+\r
+Of course, to get the stats to update, you need to add some information\r
+in the spider crontab file as below...\r
+\r
+<tscreen><verb>\r
+# Update stats for mrtg on website\r
+00,05,10,15,20,25,30,35,40,45,50,55 * * * * run_cmd('mrtg all')\r
+</verb></tscreen>\r
+\r
+This will update the site every 5 minutes.\r
+\r
+<sect>Security\r
+\r
+<P>\r
+From version 1.49 DXSpider has some additional security features. These\r
+are not by any means meant to be exhaustive, however they do afford some\r
+security against piracy. These two new features can be used independently \r
+of each other or in concert to tighten the security.\r
+\r
+<sect1>Registration\r
+\r
+<P>\r
+The basic principle of registration is simple. If a user is not registered\r
+by the sysop, then they have read-only access to the cluster. The only\r
+thing they can actually send is a talk or a message to the sysop. In\r
+order for them to be able to spot, send announces or talks etc the sysop\r
+must register them with the <em>set/register</em> command, like this ...\r
+\r
+<tscreen><verb>\r
+set/register g0vgs\r
+</verb></tscreen>\r
+\r
+The user g0vgs can now fully use the cluster. In order to enable \r
+registration, you can issue the command ...\r
+\r
+<tscreen><verb>\r
+set/var $main::reqreg = 1\r
+</verb></tscreen>\r
+\r
+Any users that are not registered will now see the motd_nor file rather\r
+than the motd file as discussed in the Information, files and useful \r
+programs section.\r
+\r
+<P>\r
+Entering this line at the prompt will only last for the time the cluster\r
+is running of course and would not be present on a restart. To make the\r
+change permanent, add the above line to /spider/scripts/startup. To\r
+read more on the startup file, see the section on Information, files \r
+and useful programs.\r
+\r
+<P>\r
+To unregister a user use <em>unset/register</em> and to show the list\r
+of registered users, use the command <em>show/register</em>.\r
+\r
+<sect1>Passwords\r
+\r
+<P>\r
+At the moment, passwords only affect users who login to a DXSpider\r
+cluster node via telnet. If a user requires a password, they can\r
+either set it themselves or have the sysop enter it for them by using\r
+the <em>set/password</em> command. Any users who already have passwords, \r
+such as remote sysops, will be asked for their passwords automatically \r
+by the cluster. Using passwords in this way means that the user has a\r
+choice on whether to have a password or not. To force the use of\r
+passwords at login, issue the command ...\r
+\r
+<tscreen><verb>\r
+set/var $main::passwdreq = 1\r
+</verb></tscreen>\r
+\r
+at the cluster prompt. This can also be added to the /spider/scripts/startup\r
+file as above to make the change permanent.\r
+\r
+<P>\r
+Of course, if you do this you will have to assign a password for each of \r
+your users. If you were asking them to register, it is anticipated that\r
+you would ask them to send you a message both to ask to be registered and\r
+to give you the password they wish to use.\r
+\r
+<P>\r
+Should a user forget their password, it can be reset by the sysop by\r
+first removing the existing password and then setting a new one like so ...\r
+\r
+<tscreen><verb>\r
+unset/password g0vgs\r
+set/password g0vgs new_password\r
+</verb></tscreen>\r
+\r
+<sect>CVS\r
+\r
+<sect1>CVS from a Linux platform\r
+\r
+<P>\r
+CVS stands for "Concurrent Versions System" and the CVS for DXSpider is held\r
+at <htmlurl url="http://www.sourceforge.net" name="Sourceforge">. This means\r
+that it is possible to update your DXSpider installation to the latest\r
+sources by using a few simple commands. A graphical interface to CVS for\r
+Windows is explained in the next section.\r
+\r
+<P>\r
+Please be aware that if you update your system using CVS, it is possible that\r
+you could be running code that is very beta and not fully tested. There is\r
+a possibility that it could be unstable.\r
+\r
+<P>\r
+I am of course assuming that you have a machine with both DXSpider and\r
+Internet access running.\r
+\r
+<P>\r
+BEFORE YOU EVEN CONSIDER STARTING WITH THIS MAKE A BACKUP OF YOUR\r
+ENTIRE SPIDER TREE!!\r
+\r
+<P>\r
+Assuming you are connected to the Internet, you need to login to the\r
+CVS repository and then update your Spider source. There are several\r
+steps which are listed below ...\r
+\r
+<P>\r
+First login as the user <em>sysop</em>. Next you need to connect to the CVS\r
+repository. You do this with the command below ...\r
+\r
+<verb>\r
+cvs -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login\r
+</verb>\r
+\r
+You will get a password prompt. Simply hit return here and your machine should\r
+return to a normal linux prompt.\r
+\r
+<P>\r
+What happens next depends on whether you have an existing installation that\r
+you want to update with the latest and greatest or whether you just want\r
+to see what is there and/or run it on a new machine for testing.\r
+\r
+If you are installing Spider from CVS then change directory to /home/sysop\r
+\r
+If you are wanting to update Spider then cd to /tmp\r
+\r
+<P>\r
+The next step will create a brand new 'spider' directory in your current\r
+directory.\r
+\r
+<verb>\r
+cvs -z3 -d:pserver:anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider co spider\r
+</verb>\r
+\r
+This command is all on one line.\r
+\r
+<P>\r
+Hopefully your screen should show you downloading files. The -z3 simply compresses\r
+the download to improve speed.\r
+When this has finished, you will have exactly the same as if you had untarred a full\r
+tarball PLUS some extra directories and files that CVS needs to do the magic that\r
+it does.\r
+\r
+<P>\r
+Now if you are doing a new installation, that's it. Carry on as if you have\r
+just downloaded and untarred the lastest tarball.\r
+\r
+<P>\r
+If you want to upgrade your current installation then do this ...\r
+\r
+<tscreen><verb>\r
+tar cvfz /tmp/s.tgz spider\r
+cd /\r
+tar xvfzp /tmp/s.tgz\r
+</verb></tscreen>\r
+\r
+This is assuming you downloaded to the /tmp directory of course.\r
+\r
+<P>\r
+NOTE: the 'p' on the end of the 'xvfz' is IMPORTANT! It keeps the permissions\r
+correct. YOU WERE LOGGED IN AS THE USER SYSOP WEREN'T YOU?????\r
+\r
+Remember to recompile the C client (cd /spider/src; make)\r
+\r
+<P>\r
+At this point the files have been upgraded. You can (usually) restart the cluster\r
+in your own time. However, if you attempt to use any new commands or features\r
+expect it to be fatal! At least your cluster will have been restarted then so it\r
+will be too late to worry about it!\r
+\r
+<P>\r
+Now the magic part! From now on when you want to update, simply connect to the\r
+Internet and then, as the user <em>sysop</em> ...\r
+\r
+<tscreen><verb>\r
+cd /spider\r
+cvs -z3 update -d\r
+</verb></tscreen>\r
+\r
+and your files will be updated. As above, remember to recompile the "C" client\r
+if it has been updated (CVS will tell you) and restart if any of the perl scripts\r
+have been altered or added, again, CVS will tell you.\r
+\r
+<P>\r
+You will find any changes documented in the /spider/Changes file.\r
+\r
+<sect1>CVS from a Windows platform\r
+\r
+<P>\r
+After the initial setup, an update to your DXSpider software is no more than a couple\r
+of clicks away. This section is intended to explain and illustrate the use of the\r
+WinCVS application to update your DXSpider software. The current stable version of\r
+WinCVS is Ver. 1.2. You can get this software at:\r
+\r
+<htmlurl url="http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip" name="http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip">\r
+\r
+Pick your download mirror and then install WinCVS after the download is complete.\r
+\r
+In this next section I have included a series of links to .jpg files to take advantage of the\r
+picture and 1000 words equivalency. The .jpg files are in the C:\spider\html directory. If\r
+someone using a Linux system is reading this section from boredom, the files are in\r
+/home/sysop/spider/html. One aside, a Linux user can also get a copy of gcvs and do your updates\r
+graphically as opposed to from the command line. The following descriptions are almost identical\r
+between WinCvs and gcvs. The following screen shots have duplicate links, depending upon whether\r
+you are viewing this information under the Windows or Linux operating system.\r
+\r
+When WinCVS is installed, running, and you are connected to the internet, the initial screen looks like:\r
+\r
+<htmlurl url="initial.jpg" name="initial.jpg">\r
+\r
+If you want, you can also look at these .jpg files with another viewer that might provide some\r
+better clarity to the image. On the left is the directory tree for your hard disk. Notice that\r
+the spider directory has a gray highlight.\r
+\r
+To start configuring WinCVS, click on Admin at the top of the screen and then Preferences. This \r
+should get you:\r
+\r
+<htmlurl url="pref-gen.jpg" name="pref-gen.jpg">\r
+\r
+In the top line for CVSROOT, enter:\r
+<tscreen><verb>\r
+anonymous@cvs.DXSpider.sourceforge.net:/cvsroot/dxspider login\r
+</verb></tscreen>\r
+\r
+and select\r
+<tscreen><verb>\r
+"passwd" file on the cvs server\r
+</verb></tscreen>\r
+\r
+for Authentication on the General tab.\r
+\r
+Next, move to the right to the Ports tab.\r
+\r
+<htmlurl url="pref-ports.jpg" name="pref-ports.jpg">\r
+\r
+In here, check the box on the second line down for the "pserver" port. Enter a port number of 2401.\r
+\r
+Finally, go to the WinCvs tab all the way to the right.\r
+\r
+<htmlurl url="pref-wincvs.jpg" name="pref-wincvs.jpg">\r
+\r
+Enter Notepad as the viewer to open files. For the HOME folder, put "C:\spider" and click OK\r
+because the configuration is now complete.\r
+\r
+You are now ready to upgrade your copy of DXSpider. Click on the greyed Spider folder\r
+shown in the directory tree on the left of the WinCVS display. Two things should happen. The Spider\r
+folder will be selected and the greyed-out arrow located just below the word Query in the top line will\r
+turn to solid green.\r
+\r
+For anyone using gcvs under Linux, the green arrow is located on the extreme left of the display,\r
+under the word File. A gcvs screen looks like:\r
+\r
+<htmlurl url="gcvs.jpg" name="gcvs.jpg">\r
+\r
+Click on the now green arrow to start the download process. An Update Settings box will be displayed\r
+to which you can simply say OK.\r
+\r
+<htmlurl url="update-OK.jpg" name="update-OK.jpg">\r
+\r
+For future reference, the Update Settings box is the place where you can enter information to revert\r
+to a prior version of DXSpider. Information on reverting to a Before Date is contained in the WinCVS\r
+manual.\r
+\r
+After a short period of time, a series of file names will scroll by in the lower pane of the WinCVS\r
+window. Eventually you should see\r
+<tscreen><verb>\r
+*****CVS exited normally with code 0*****\r
+\r
+</verb></tscreen>\r
+appear in the lower pane. You're done. The updated files are in place ready for you to stop and then\r
+restart your DXSpider. After the restart, you're running with the latest version of DXSpider.\r
+\r
+<htmlurl url="completed.jpg" name="completed.jpg">\r
+\r
+To paraphrase from the CVS section... Now the magic part! From now on when you want to update, simply\r
+connect to the Internet and start WinCVS.\r
+<tscreen><verb>\r
+Click on the greyed-out Spider directory in the left screen\r
+Click on the green down arrow\r
+Click OK on the Update Settings dialog box\r
+Restart your Spider software\r
+</verb></tscreen>\r
+\r
--- /dev/null
+<!doctype linuxdoc system>
+
+<article>
+
+<!-- Title information -->
+
+<title>The DXSpider User Manual v1.50</title>
+<author>Ian Maude, G0VGS, (g0vgs@gb7mbc.net)</author>
+<date>March 2003 revision 0.3</date>
+
+<abstract>
+A complete reference for users of the DXSpider DXCluster program.
+</abstract>
+
+<!-- Table of contents -->
+<toc>
+
+<!-- Begin the document -->
+
+<sect>Introduction
+
+<sect1>What is a DX Cluster?
+
+<p>
+A DX Cluster is a packet node where DX chasers on any band or mode can
+post rare or interesting stations that they have worked or heard. Of
+course other people are doing the same thing too, so you can find new
+DX as well as telling others about the stations you have worked.
+Clusters tend to be linked to each other so that the amount of people
+using them is increased, thereby increasing the amount of posted DX.
+Other information can be found on clusters such as on-line call books,
+mail etc. You can talk to other stations connected to the cluster
+network too, in real time, whether at the node you are logged into or
+on another node connected to the network. You can also use converse
+mode, where several stations can talk to each other in the same way.
+Of course, the DX is still posted to you all the while!
+
+<sect1>So what is DXSpider?
+
+<p>
+PacketCluster nodes have been around since roughly 1985. The original
+PacketCluster idea came from Dick Newell, AK1A, and ran under DOS.
+In about 1992 Dick stopped the development of the PacketCluster
+software for amateur radio. Many systems are still using this
+relatively old DOS software today.
+
+There are several new compatible cluster programs around now,
+including DXSpider. DXSpider is a clone of PacketCluster software that runs
+under several operating systems including Linux and Windows. Linux is fast
+becoming the choice for amateur radio stations because of it's flexibility,
+reliability and the lack of the memory limitations of DOS. Linux supports
+multitasking and is also multiuser. It has support for AX25, ROSE,
+NetROM and TCPIP built in, making it the ideal choice for amateur
+radio. It is also totally free!
+
+DXSpider was conceived and begun in 1998 by Dirk Koopman, G1TLH as an
+exercise in perl programming. It has developed rapidly and today is a
+very powerful cluster program. It was designed to be totally compatible
+with the AK1A program, although several commands have been extended to
+improve functionality.
+
+This manual is designed to help you become familiar with the commands
+that DXSpider supports and to help you get the best from the program so
+you can enjoy working that rare DX! As DXSpider is being improved all the
+time, commands will be added as time goes by, so make sure you have
+the most upto date version of this manual. The latest version will
+always be included with the cluster program so if you are unsure, simply
+ask your sysop. The manual will also be available on the wesite.
+
+
+<sect>Logins and logouts.
+
+<p>
+You might not think that there is a lot of point of including a
+section on how to log in and out of DXSpider. However, you would be
+suprised at the difficulties some people have in simply getting in
+and out of the cluster!
+
+There are several ways a login might be achieved, dependant on how
+the sysop has DXSpider configured. It is impossible for me to cover all
+variations but here are the basic ones.
+
+<sect1>AX25 logins.
+
+<p>
+Simplicity itself. The usual <bf>CONNECT</bf> command will log you straight
+into the cluster and you will not have to do anything else.
+Obviously, you will have to connect to the correct callsign. Some
+nodes use an SSID with their call so you would have to add that.
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+connect GB7MBC
+connect GB7MBC-1
+</verb></tscreen>
+
+<sect1>Netrom logins.
+
+<p>
+There are several possibilities here, dependant on how the sysop has
+configured his system. If you are connecting via netrom then you are
+most probably connecting from another station. Listing the nodes in
+that station with the <bf>NODES</bf> command will tell you what callsign
+or netrom alias to connect to. Then just issue the connect command
+from there. It is possible that the netrom alias may connect you to
+a node with an alias for the cluster, such as DXC. Just type this
+and you will be connected.
+
+<bf>Example:</bf>
+<tscreen><verb>
+connect MBCDX
+</verb></tscreen>
+
+<sect1>Telnet logins.
+
+<p>
+With telnet connections, the source callsign is not seen by DXSpider, so
+you will be asked to login with your callsign.
+To telnet to DXSpider, you would connect to a specific port. There is no
+standard at the moment for a cluster telnet port but ask the sysop if
+you are unsure.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+telnet gb7mbc 8000
+</verb></tscreen>
+
+All the above are possible ways of connecting to a DXSpider cluster. You
+may have some or all of these available to you. There may be one or
+two additional ways to connect dependant on the network local to you.
+However I am sure you get the idea.
+
+<sect1>Logouts.
+
+<p>
+Logging out can be done by simply issuing the standard <bf>BYE</bf>
+command.
+
+You could also send a disconnect if you are using AX25, or a <bf>CLOSE</bf>
+command if you are connected via telnet.
+If you do not log out gracefully using one of the above commands,
+you may find you are unable to get a full connect next time. This
+may also happen if a netrom connection drops. You may get connected,
+but nothing else will happen because the program thinks you are still
+connected and will not let you connect twice under the same call.
+However you could reconnect by adding a number to the end of your call,
+for example G0YLM-2.
+This can be done by either altering your MYCALL setting in the TNC or
+by altering your program configuration.
+
+
+<sect>Setting your personal details.
+
+<p>
+Once logged in to the cluster, you should set your details so that
+anybody who wishes to contact you can find out who and where you are.
+There are four items to set, your name, qth, location and home node.
+Setting these details also allows the use of the SHOW/HEADING and
+SHOW/SUN commands from within the cluster. Unless you set your QTH
+and location, these commands cannot function.
+Once you have set your name, DXSpider will greet you with it next time
+you login. Your QTH setting is where you live and it is a good idea
+to add your locator to this as the location setting is converted to
+latitude and longitude once inputted. You can actually set your location
+in latitude/longitude or as a locator. Setting your home node will
+tell the program where you wish mail to be sent to you.
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+set/name Ian
+set/qth Morecambe, Lancashire IO84NB
+set/location 48 34 n 12 12 e
+set/qra IO84NB
+set/home gb7mbc
+</verb></tscreen>
+
+<sect>Getting and posting DX.
+
+<p>
+When all is said and done, this is the main function of a DX cluster.
+In its simplest form you can just connect to the node and you will
+start to receive DX spots almost immediately! You can check on
+recent postings in either a general manner or on a particular band or
+mode. You can even check DX by callsign or a fragment of a callsign.
+Of course, once you get the hang of things, it is expected that you
+start posting some yourself! After all, there would be no clusters
+if people did not post DX and you get the added thrill of the hunt!
+
+<sect1>Receiving DX.
+
+<p>
+As we have already said, it is possible just to connect to the
+cluster and you will receive spots automatically. However, you may
+wish to check on spots just posted. Maybe you wish to see if a
+particular band is open or if a certain callsign is active, perhaps a
+DXpedition. The command to do this is <bf>SHOW/DX</bf>. Without any
+other arguments, this command will output the last 10 spots
+posted. It is possible to look at more than this, for example the
+last 20 or 50 spots, by adding the number to the command. You can
+make it even more specific by adding a band in either wavelength or
+frequency, and/or any additional information such as QSL details.
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+show/dx
+show/dx 5
+show/dx 20
+</verb></tscreen>
+
+will show the last 10, 5 and 20 spots received by the cluster
+respectively.
+
+<bf>Examples</bf>
+
+<tscreen><verb>
+show/dx on 20m
+show/dx 10 on 20m
+show/dx 20 on 20m
+</verb></tscreen>
+
+will show the last 5, 10 or 20 spots on 20 metres only.
+
+It is also possible to check for certain callsigns, or fragments of
+callsigns in the same way.
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+show/dx g0vgs
+show/dx 10 g0vgs
+</verb></tscreen>
+
+would show the last 5 or 10 dx spots containing the callsign g0vgs.
+
+<p>
+You can check for DX by offset and also by specifying a comment to
+search for.
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+show/dx 30-40
+show/dx 14000-14033
+show/dx iota
+</verb></tscreen>
+
+would show the spots that arrived between 30 and 40 spots ago and any
+spots with the word <em>iota</em> in the comment field. The case of
+the comment is not important.
+
+Checking DX posted on a certain day is possible too. All you have
+to do here is to specify how many days ago it was like this ...
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/dx day 30
+</verb></tscreen>
+
+It is of course possible to specify multiple arguments.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/dx 20 prefix 9a on vhf day 30
+</verb></tscreen>
+
+This would show the last 20 spots posted by or about calls with the prefix
+9a on vhf 30 days ago.
+
+As you can see the <bf>SHOW/DX</bf> command is very flexible, so if you are
+not sure whether something will work or not, try it and see! More
+information can be found in the Command Set section.
+
+<sect1>Posting DX.
+
+<p>
+To post DX you use the <bf>DX</bf> command. The syntax is shown below.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+dx (frequency) (callsign) (remarks)
+</verb></tscreen>
+
+Where frequency is in kilohertz and the callsign is the callsign of
+the station you have worked or heard, (ie not your own callsign!).
+The remarks section allows you to add information like the operators
+name or perhaps a location. Actually DXSpider will allow the frequency
+and callsign fields to be entered in any order.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+dx 14004 pa3ezl OP Aurelio 599
+</verb></tscreen>
+
+In fact, all the following will give the same result...
+
+<tscreen><verb>
+dx 14004 pa3ezl OP Aurelio 599
+dx pa3ezl 14004 OP Aurelio 599
+dx pa3ezl 14.004 OP Aurelio 599
+</verb></tscreen>
+
+This posting, or callout as it is known, will be forwarded to all
+other connected stations both at the cluster you are connected to and
+other active clusters in the network. The callout will also be sent
+to you as proof of receipt.
+
+<sect>Headings and propagation
+
+<p>
+There are three commands in DXSpider to help you get the best DX possible.
+These are <bf>SHOW/SUN</bf>, <bf>SHOW/MOON</bf> and
+<bf>SHOW/HEADING</bf>. These commands will only work for you if you
+have entered your personal details. They use your entered location as
+a reference, so if you have not entered it or have entered it incorrectly
+they will not return the correct information.
+
+<sect1>Sun
+
+<p>
+The <bf>SHOW/SUN</bf> command can be used in three different ways. It
+can be used to show sunrise and sunset times for your own station, a
+particular callsign or a prefix.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/sun
+</verb></tscreen>
+
+The output from this would look something like this ..
+
+<tscreen><verb>
+sh/sun
+Location Rise Set Azim Elev
+G0VGS Morecambe, Lancashire 07:08Z 17:39Z 205.3 24.1
+</verb></tscreen>
+
+<tscreen><verb>
+sh/sun 5b4
+</verb></tscreen>
+
+would look like this ...
+
+<tscreen><verb>
+sh/sun 5b4
+Location Rise Set Azim Elev
+5B Cyprus-5B 04:23Z 15:40Z 244.0 18.8
+</verb></tscreen>
+
+You can also specify multiple arguments like this ...
+
+<tscreen><verb>
+sh/sun gw4veq 5b4ab zs
+</verb></tscreen>
+
+and then the output would look like this ...
+
+<tscreen><verb>
+sh/sun gw4veq 5b4ab zs
+Location Rise Set Azim Elev
+GW4VEQ Brungwran, Isle of Anglesey IO 07:14Z 17:48Z 204.9 24.9
+5B Cyprus-5B 04:23Z 15:40Z 244.5 18.3
+ZS So-Africa-ZS1-ZS 04:31Z 17:28Z 289.9 41.3
+ZS So-Africa-ZS5-ZS 03:44Z 16:34Z 278.5 32.0
+ZS So-Africa-ZS6-ZS 03:59Z 16:42Z 277.6 35.0
+</verb></tscreen>
+
+<sect1>Moon
+
+<p>
+The <bf>SHOW/MOON</bf> command works in the same way as the
+<bf>SHOW/SUN</bf> command. This program however, calculates the
+rise and set times of the moon for a prefix or callsign, together
+with the current azimuth and elevation of the sun at these
+locations.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/moon ea
+</verb></tscreen>
+
+The output from this command would look like this ..
+
+<tscreen><verb>
+sh/moon ea
+Location Rise Set Azim Elev RGain dB
+EA Spain-EA 08:15Z 20:09Z 257.2 9.5 -0.6
+</verb></tscreen>
+
+You can see that the output is similar to the <bf>SHOW/SUN</bf>
+command, with slightly different fields.
+
+<sect1>Heading
+
+<p>
+The <bf>SHOW/HEADING</bf> command works in the same way as the
+<bf>SHOW/SUN</bf> and <bf>SHOW/MOON</bf> commands but outputs beam
+headings for a specified callsign or prefix. Reciprocal beam headings
+are also calculated.
+
+<bf>Example</bf>
+
+<tscreen><verb>
+show/heading zl
+</verb></tscreen>
+
+The output from this command would look like this ..
+
+<tscreen><verb>
+sh/heading zl
+ZL New-Zealand-ZL1-ZL: 7 degs - dist: 11238 mi, 18087 km Reciprocal heading: 355 degs
+ZL New-Zealand-ZL2-ZL: 9 degs - dist: 11540 mi, 18574 km Reciprocal heading: 353 degs
+ZL New-Zealand-ZL3-ZL: 19 degs - dist: 11634 mi, 18724 km Reciprocal heading: 345 degs
+ZL New-Zealand-ZL4-ZL: 34 degs - dist: 11783 mi, 18963 km Reciprocal heading: 332 degs
+</verb></tscreen>
+
+<sect>Announcements.
+
+<sect1>Making announcements.
+
+<p>
+Occasionally, you may wish to post something that does not fall into
+the normal parameters for a DX callout. You may wish to tell
+everybody connected that 10 FM is open for example, or ask if anyone
+knows the QSL manager for a certain callsign etc. You can do this
+using the <bf>ANNOUNCE</bf> command.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+announce 10 FM is open in IO84NB to europe.
+</verb></tscreen>
+
+That would let everyone know locally that this was the case, however
+it would not be forwarded to other nodes connected. To send
+announcements to other connected nodes as well, you would use the
+<bf>FULL</bf> extension.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+announce full Anyone seen EA7WA today?
+</verb></tscreen>
+
+Be cautious in your use of announce full. There are many other tools
+available to get the information you require and the judicious use of
+this command is frowned upon as it creates a great deal of traffic
+across the network.
+
+<sect1>Listing announcements.
+
+<p>
+You can list previous announcements in the standard format with the
+<bf>SHOW</bf> command. As before you can list just the last 5 or as
+many as you wish.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/announcements
+show/announcements 10
+</verb></tscreen>
+
+<sect>Nodes and users.
+
+<p>
+You can check which nodes are connected in the network, who is
+logged on locally, who is logged on at all the nodes or even
+just one node in particular. This is handy if you wish to see whether
+a friend is connected at the node they use. To see who is connected
+to the nodes, the <bf>SHOW/CONFIGURATION</bf> command is used.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/configuration
+show/configuration/nodes
+show/configuration (node_call)
+show/configuration (prefix)
+</verb></tscreen>
+
+The first of our three examples would output something like this,
+
+<tscreen><verb>
+sh/c
+Node Callsigns
+EI5TCR (7 users)
+GB7ADX
+GB7BAA G4FPV G8TIC
+GB7BIG (GD0TEP) GD3UMW
+GB7BPQ (G0INA) G0RCI G3AKU G3OCA
+(GB7CDX) G3JNB G4ALR
+GB7DJK G0FYD G0REK G1TLH G4PEL G4SOZ
+ G4TVR G7SQW K8AZ M0CTQ-1 MM1CXE-10
+ ON7WP
+GB7DXA G0RDI G8SJP
+GB7DXC (G0HDB) G0WFK (G1FYC) G3KWK G3LME
+ G3OIL G4BGW G4FUJ (G4PDQ) GW7SMV
+GB7DXE G1NNB
+(GB7DXG) GU6EFB GU7DHI
+GB7DXK G1NTW G3IBI G3NSM G3XAQ G4CUS
+ G4XQY G7GAN
+GB7DXM G1EUC G3GAF G3LAS G4ZTR G8WXU
+ M0BCT M1EMF
+</verb></tscreen>
+
+You will notice that EI5TCR is showing only that it has 7 users and not
+giving the actual callsigns. This means that this node is on a limited
+protocol of some kind, probably because of a contest situation where
+slow radio links can block up and fail if too much information is sent
+between nodes.
+
+The second example would just show the nodes connected in the
+network, like this,
+
+<tscreen><verb>
+sh/c/n
+Node Callsigns
+GB7BAA GB7BAA GB7BPQ (GB7CDX) GB7DJK GB7DXA
+ GB7DXC GB7DXE (GB7DXG) GB7DXK GB7DXL
+ GB7DXM GB7DXS GB7IPT GB7MRS GB7UJS
+ GB7YDX KL7G N2TLY (ON0DXK)
+GB7BIG EI5TCR GB7ADX GB7BIG GB7UDX
+GB7MBC
+PA4AB-14 PA4AB-14
+PI4TUE-8 PI4TUE-8
+</verb></tscreen>
+
+If we insert the node_call pi4tue-8 into the third example, then
+this would be the output,
+
+<tscreen><verb>
+Node Callsigns
+PI4TUE-8 9A1CMA-6 DF6PW DL4FAY DL4KAK DL4WF-2
+ F5NOD-2 F5PAC IZ0CSR N6CR OH2BLD
+ ON1LVL-13 ON4CBT ON4CJP ON5DXL-14 ON7NQ
+ PA0RCT PA3DYS PA3FDO PA5KW-4 PI4TUE-9
+ YT1XX
+</verb></tscreen>
+
+As you can see, only the users of the requested node are shown.
+
+You can also use a prefix to show only a group of nodes. For example
+you may only wish to see who is connected to the nodes in the UK. To
+do this simply use a prefix like this ...
+
+<verb>
+show/configuration gb7
+</verb>
+
+To show the locally connected users, the <bf>SHOW/USERS</bf> command is
+used
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+show/users
+</verb></tscreen>
+
+The output of this command would look like this,
+
+<tscreen><verb>
+Callsigns connected to GB7MBC
+G0JHC G0NEI G0VGS G0VGS-2 G0YLM
+G3JAG G3OWO G3UEU
+</verb></tscreen>
+
+<sect>Talk mode.
+
+<p>
+You can send a single comment or start a dedicated talk session to
+another user by using the <bf>TALK</bf> command.
+
+<p>
+Talk mode is used to send a one line comment or greeting to a
+specific user connected either at your node or another in the
+network. You can also enter into a dedicated talk session with
+another user. Talks will be automatically forwarded to other nodes
+if the station you are talking to is not connected locally.
+You can find out who is connected by using the
+<bf>SHOW/CONFIGURATION</bf> command, (described earlier).
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+talk g0rdi Having a good day Iain?
+</verb></tscreen>
+
+This example would send the line "Having a good day Iain?" to the
+user g0rdi but would leave you in normal mode.
+
+<tscreen><verb>
+talk g0rdi
+Entering Talkmode, /EX to end, /<cmd> to run a command
+Talk (G0RDI)>
+</verb></tscreen>
+
+As you can see, you can still run commands whilst in talk mode.
+Simply prefix the command with a / like /sh/dx and you will get
+the expected output.
+If the user is connected to another node, you may have to use a
+slightly extended version of the <bf>TALK</bf> command.
+
+<tscreen><verb>
+talk g0rdi > gb7djk
+</verb></tscreen>
+
+To exit talk mode, you issue the command <bf>/ex</bf>.
+
+Whilst in talk mode you will still receive DX spots. This means that
+you can chat to a friend whilst working DX.
+
+<sect>Mail.
+
+<p>
+You can send and receive both personal mail and bulletins with DXSpider
+quite easily.
+
+<sect1>The "directory" command.
+
+<p>
+To list mail you would use the <bf>DIRECTORY</bf> command. On its
+own, this command will output the last ten messages received by the
+node, either to or from yourself or bulletins such as "DX" and "ALL".
+As with other commands you can display more by specifying a number
+with the command. You should be aware that Spider will accept
+these commands by separating with either a slash or a space, so
+<em>dir new</em> and <em>dir/new</em> work in the same way.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+directory
+directory/20
+directory 20
+</verb></tscreen>
+
+Of course most of the time you will only want to list new mail sent
+to you personally since your last login. However you might also like
+to check for general mail received by the node. In fact if there is
+new mail for you, the cluster will tell you when you login. You will
+also be informed if new mail arrives for you during the time you are
+logged in.
+Mail is not only sent to callsigns though. Mail can also be sent to
+subjects like "all" or "local" or "dx" etc. You can treat these
+bulletins in the same way as personal mail with the directory
+command.
+
+<bf>Examples:</bf>
+
+<tscreen><verb>
+directory/new
+directory/own
+directory/own/10
+directory/all
+directory/from <call>
+</verb></tscreen>
+
+The last option will only show mail from a callsign if it was sent to
+you personally or was sent as a bulletin. There are some additional
+commands and these can be found in the DXSpider Command Reference section.
+
+<sect1>Reading mail.
+
+<p>
+The output of the <bf>DIRECTORY</bf> command could be something like
+this.
+
+<tscreen><verb>
+dir
+ 20735 2 ALL GW7SMV 21-Feb 1204Z REC 9E1S QSL TDY 50Mhz....
+ 20823 308 UK G0HDB 22-Feb 2334Z Help - which district code?
+ 20824 105 ALL W9AE 23-Feb 0349Z S0NY QSL address?
+ 20825 2 UK G0LRJ 23-Feb 0806Z QSL REC LZ2CJ/1.CARD NO-750.
+ 20858 2 ALL GW7SMV 24-Feb 0905Z REC S92DX QSL CARD TDY 50Mhz
+ 20921 200 ALL GM4FDM 27-Feb 2203Z Trip to VP8
+ 20949 375 ALL K0MN 27-Feb 0428Z ST0P cards are gd @ ARRL
+ 20950 2 UK G0LRJ 28-Feb 0835Z QSL REC SV9/IZ0CKJ/P EU-187.
+ 20987 569 ALL GD0TEP 1-Mar 1733Z Portable contests
+ 21076 2 ALL G4AFJ 3-Mar 1743Z kh6nd/kh5 qsl received
+ 21184-p 599 GW4HAT G0VGS 4-Mar 1518Z Re: Time
+</verb></tscreen>
+
+The first column is the actual message number. If the message is a
+personal one to you, you will see a letter 'p' after this number. If
+the message has been read, there will be a '-' between the message
+number and the 'p'. This only works for personal messages. The next
+column shows the file size of the message. The third column shows the
+address the message was sent to and the next column shows who sent it.
+The rest is fairly self-explanatory.
+
+Reading a message is as simple as typing read, followed by the
+message number that you wish to read.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+read 25
+</verb></tscreen>
+
+will read message number 25. However the mail will be displayed in it's
+entirety unless you specify a page length. You can set your page length
+to any number you like and when the message reaches that number of lines
+you will get a prompt giving you options.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+set/page 20
+</verb></tscreen>
+
+
+<sect1>Sending mail.
+
+<p>
+Sending mail is done in the time honoured way. First you specify
+a recipient for the message, then you will be prompted for a subject.
+Once you have done this you will be asked to type your message.
+Please remember that there is no automatic word wrap, so unless you
+are using a client that wraps lines automatically, remember to hit
+return at the end of each line.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+send m0azm
+Enter Subject (30 characters):
+See you Thursday
+Enter Message /EX to send or /ABORT to exit
+Hi Ian,
+Just a quick note to say that I can make Thursday after all. The
+appointment I had has cancelled so we are go!
+Cheers
+Ian
+</verb></tscreen>
+
+At this point you can either hit return and enter /ex to send the
+message or use /abort at any time to abort it. You can now display
+the message in the normal way. There are several send options and
+these are listed in the Command Set section. These include sending
+mail to several recipients and asking for a return receipt.
+
+
+<sect1>Replying to mail.
+
+<p>
+If mail is addressed to you or to a bulletin address, you can use the
+<bf>REPLY</bf> command to reply to it. Using this command, the
+subject will be automatically set for you as "Re: subject", whatever
+the subject was.
+
+<bf>Example:</bf>
+
+<tscreen><verb>
+reply 2500
+</verb></tscreen>
+
+<sect1>Deleting mail
+
+<P>
+To delete a message, you use the <em>delete</em> command.
+You can only delete messages sent to or received by yourself.
+Bulletins are dealt with automatically or by the sysop.
+
+<sect>Filtering (From version 1.45)
+
+<sect1>General filter rules
+
+<P>
+Upto v1.44 it was not possible for the user to set their own filters. From
+v1.45 though that has all changed. It is now possible to set filters for just
+about anything you wish. If you have just updated from an older version of
+DXSpider you will need to update your new filters. You do not need to do
+anything with your old filters, they will be renamed as you update.
+
+<P>
+There are 3 basic commands involved in setting and manipulating filters. These
+are <em>accept</em>, <em>reject</em> and <em>clear</em>. First we will look
+generally at filtering. There are a number of things you can filter in the
+DXSpider system. They all use the same general mechanism.
+
+<P>
+In general terms you can create a 'reject' or an 'accept' filter which can have
+up to 10 lines in it. You do this using, for example ...
+
+<tscreen><verb>
+accept/spots .....
+reject/spots .....
+</verb></tscreen>
+
+where ..... are the specific commands for that type of filter. There are
+filters for spots, wwv, announce, wcy and (for sysops) connects. See each
+different accept or reject command reference for more details.
+
+There is also a command to clear out one or more lines in a filter. They are ...
+
+<tscreen><verb>
+clear/spots 1
+clear/spots all
+</verb></tscreen>
+
+There is clear/xxxx command for each type of filter.
+
+<P>
+and you can check that your filters have worked by the command ...
+
+<tscreen><verb>
+show/filter
+</verb></tscreen>
+
+<P>
+For now we are going to use spots for the examples, but you can apply the same
+principles to all types of filter.
+
+<sect1>Types of filter
+
+<P>
+There are two main types of filter, <em>accept</em> or <em>reject</em>. You
+can use either to achieve the result you want dependent on your own preference
+and which is more simple to do. It is pointless writing 8 lines of reject
+filters when 1 accept filter would do the same thing! Each filter has 10
+lines (of any length) which are tried in order. If a line matches then the
+action you have specified is taken (ie reject means ignore it and accept
+means take it)
+
+<P>
+If you specify reject filters, then any lines that arrive that match the filter
+will be dumped but all else will be accepted. If you use an accept filter,
+then ONLY the lines in the filter will be accepted and all else will be dumped.
+For example if you have a single line <em>accept</em> filter ...
+
+<tscreen><verb>
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
+</verb></tscreen>
+
+then you will <em>ONLY</em> get VHF spots <em>from</em> or <em>to</em> CQ zones
+14, 15 and 16.
+
+<P>
+If you set a reject filter like this ...
+
+<tscreen><verb>
+reject/spots on hf/cw
+</verb></tscreen>
+
+Then you will get everything <em>EXCEPT</em> HF CW spots. You could make this
+single filter even more flexible. For example, if you are interested in IOTA
+and will work it even on CW even though normally you are not interested in
+CW, then you could say ...
+
+<tscreen><verb>
+reject/spots on hf/cw and not info iota
+</verb></tscreen>
+
+But in that case you might only be interested in iota and say:-
+
+<tscreen><verb>
+accept/spots not on hf/cw or info iota
+</verb></tscreen>
+
+which achieves exactly the same thing. You should choose one or the other
+until you are comfortable with the way it works. You can mix them if you
+wish (actually you can have an accept AND a reject on the same line) but
+don't attempt this until you are sure you know what you are doing!
+
+<P>
+You can arrange your filter lines into logical units, either for your own
+understanding or simply convenience. Here is an example ...
+
+<tscreen><verb>
+reject/spots 1 on hf/cw
+reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
+</verb></tscreen>
+
+What this does is to ignore all HF CW spots and also rejects any spots on VHF
+which don't either originate or spot someone in Europe.
+
+<P>
+This is an example where you would use a line number (1 and 2 in this case), if
+you leave the digit out, the system assumes '1'. Digits '0'-'9' are available.
+This make it easier to see just what filters you have set. It also makes it
+more simple to remove individual filters, during a contest for example.
+
+<P>
+You will notice in the above example that the second line has brackets. Look
+at the line logically. You can see there are 2 separate sections to it. We
+are saying reject spots that are VHF or above <em>APART</em> from those in
+zones 14, 15 and 16 (either spotted there or originated there). If you did
+not have the brackets to separate the 2 sections, then Spider would read it
+logically from the front and see a different expression entirely ...
+
+<tscreen><verb>
+(on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
+</verb></tscreen>
+
+The simple way to remember this is, if you use OR - use brackets. Whilst we are
+here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.
+
+As mentioned earlier, setting several filters can be more flexible than
+simply setting one complex one. Doing it in this way means that if you want
+to alter your filter you can just redefine or remove one or more lines of it or
+one line. For example ...
+
+<tscreen><verb>
+reject/spots 1 on hf/ssb
+</verb></tscreen>
+
+would redefine our earlier example, or
+
+<tscreen><verb>
+clear/spots 1
+</verb></tscreen>
+
+To remove all the filter lines in the spot filter ...
+
+<tscreen><verb>
+clear/spots all
+</verb></tscreen>
+
+<sect1>Filter options
+
+<P>
+You can filter in several different ways. The options are listed in the
+various helpfiles for accept, reject and filter.
+
+<sect1>Advanced filtering
+
+<P>
+Once you are happy with the results you get, you may like to experiment.
+
+<P>
+The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU
+can be written with a mixed filter, for example ...
+
+<tscreen><verb>
+rej/spot on hf/cw
+acc/spot on 0/30000
+acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
+</verb></tscreen>
+
+Note that the first filter has not been specified with a number. This
+will automatically be assumed to be number 1. In this case, we have
+said <em>reject all HF spots in the CW section of the bands but accept
+all others at HF. Also accept anything in VHF and above spotted in or
+by operators in the zones 14, 15 and 16</em>. Each filter slot actually
+has a 'reject' slot and an 'accept' slot. The reject slot is executed
+BEFORE the accept slot.
+
+<P>
+It was mentioned earlier that after a reject test that doesn't match, the
+default for following tests is 'accept', the reverse is true for 'accept'.
+In the example what happens is that the reject is executed first, any non
+hf/cw spot is passed to the accept line, which lets through everything
+else on HF. The next filter line lets through just VHF/UHF spots from EU.
+
+
+<sect>Hints, tips and common questions.
+
+<p>
+<bf/Q./These commands seem very long! Can I shorten them?
+
+<bf/A./Of course you can and the usual abbreviations work. If you
+are unsure, try it.
+
+<bf/Q./I am not sure if this command is correct. Can I cause any
+harm if I try it?
+
+<bf/A./Do not be afraid to try a command to see if it will work,
+at the worst you will get an error message. If you require any
+help on a command, just type help followed by the command you
+want help on. Look at the "DXSpider Command Reference" section to see
+what help can be found.
+
+<bf/Q./How should I use the announce command?
+
+<bf/A./With respect. Use the command by all means, but please
+only use the "full" extension if absolutely necessary. It can
+create a LOT of messages passing between clusters.
+
+<bf/Q./I like to be working in the shack while logged into the
+cluster but I can't be looking at the screen all the time. How
+can I be alerted when anything happens?
+
+<bf/A./Use the <bf>SET/BEEP</bf> command. You can find information
+on this in the "DXSpider Command Reference" section.
+
+<bf/Q./I got disconnected from the cluster and now I can't log
+back in again. What is wrong?
+
+<bf/A./Probably the cluster thinks you are still logged on and
+will not let you reconnect using the same call to prevent loops.
+Try logging on again adding an ssid to your callsign as DXSpider
+treats G0YLM and G0YLM-1 as different users.
+
+<bf/Q./How do I know if I have got the latest version of this
+user manual?
+
+<bf/A./The latest and greatest will always be on the Website. It will
+also be included with every release of DXSpider. As always, if unsure,
+ask your sysop what version number is the latest.
+
+
projects / spider.git / commitdiff