FSC-0003

                         FidoNet Route Files Explained
                      Part 1 -- The Many Faces of FidoNet

                           by Ben Baker, Fido 100/76

               There  is  no  aspect  of FidoNet more universally mis-
          understood than routing.  It is the  intent  of  this  foru-
          part series to clear some of the fog.

               The   justification  for  nets  and  routing  has  been
          discussed many times and will NOT be  discussed again  here.
          Given  that  routing  is  good,  how is it done?  What's the
          meaning of the various statements that go into route  files?
          Indeed, what's the meaning of route files?

               Let's first take a look at "the network." But how do we
          do that?  In reality, there is no "the network." FidoNet  is
          a  different  thing when viewed by each different Fido!  The
          only formal definition of FidoNet is the node list,  and  it
          serves  as  an  adaquate  view  of  "the  network"  for most
          independent Fidos but only the members of some nets.

               Consider  the  hypothetical  node,  Fido 21/7.  He's an
          independent member of a "Region." To him, "the network" is a
          couple  of  hundred other independent nodes to whom he sends
          messages directly and another couple of hundred to which  he
          has  access  through  36  defined  "Hosts." If he receives a
          message not addressed to his node, his  Fido  "orphans"  it.
          He has no intention of forwarding someone else's mail.  They
          can pay their own phone bills!  When he sends a  message  to
          18/3,  Fido  knows  (from  the  node  list)  that is another
          independent and sends the message direct.  When he  sends  a
          message to 100/76, Fido knows (from the node list) that is a
          member of net 100 and sends it to 100/0.  Fido 21/7 executes
          only  schedule A during the national mail window.  He has no
          use for ANY route files.

               Another hypothetical node, Fido 201/4 is a member of an
          "inbound  only"  net.   Since  the  sysop  has  used the '4'
          command properly, Fido knows he is a member of net  201  and
          will  treat  other  members  of that net as though they were
          independent nodes.  When he sends a message to  201/5,  Fido
          will  send it direct and not to 201/0.  Messages headed out-
          side net 201 will be handled for 201/4 just as they were for
          21/7.   Fido  201/4  executes  two  schedules,  A during the
          national window followed immediatly by B when he  just  sits
          quietly  and  waits  for  201/0  to  send  him  any  mail he
          received.  He has no use for ANY route files.

               Everyone   else  has  a  view  of  "the  network"  more
          complicated than Fido can discover from just the node  list.
          If  you're a Southern California Hub, or a local node in the
          New York Megalopolis, or maybe the host of a modest  network
          in  Memphis  "the  network"  looks  different to you than to
          other sysops.  It is the function of route files  to  modify
          Fido's view of "the network" to conform to yours.

               If your Fido is executing any mail event and any  other
          Fido calls it up and offers it a mail packet, your Fido will
          graciously receive that packet and at the end  of  the  mail
          event,  he will unpack it into messages.  These actions have
          nothing whatever to do with route files!

               Reread  that last paragraph two or three times until it
          sinks in.  It is a very important, very misunderstood point.
          Route  files  do  not and cannot control the way you receive
          mail.  ROUTE FILES CONTROL ONLY THE  WAY  YOU  SEND  MAIL!!!
          After all, that's when you're paying the phone bill.

               Furthermore,  what  you  say  in ROUTE.B has absolutely
          nothing to do with how Fido behaves in schedule C.   I  will
          come back to this point later.

               Ever since we first began routing FidoNet  messages  to
          places  other than their final destination, route files have
          used three basic commands to mold Fido's view of FidoNet  to
          correspond  with  your  view.   In  part  2  we will look at
          SCHEDULE, ROUTE-TO and ACCEPT-FROM and  see  just  how  they
          influence Fido.

               Part  3  will  examine  a  bevy of new routing commands
          available with Fido V11 and see how they have made automatic
          distribution at last possible.

               LISTGEN  V2  is capable of generating route files auto-
          matically.  Part 4 will discuss how ROUTE.CTL statements map
          to route file commands.

               Stay  with  me  for the next few weeks and maybe we can
          burn off the fog and find a bright sky, a calm sea and clear
          sailing.   (And  don't  throw  away your newsletters, you'll
          want to refer back from time to time.)

          ------------------------------------------------------------



                         FidoNet Route Files Explained
                          Part  2 -- In the Beginning

                           by Ben Baker, Fido 100/76

               From the time he first began "routing"  messages,  Fido
          has  used  "route  files"  to tell him what messages to send
          where when.   Three  basic  route  file  commands  do  this;
          SCHEDULE  aka SEND-TO, ROUTE-TO and ACCEPT-FROM.  This week,
          we'll look at these commands in depth.

               Before  going  farther,  I  need  to define a couple of
          terms.  A "target" is a node to which your Fido will connect
          and directly send a message.  An "addressee" is the ultimate
          destination node  for  a  message.   This  is  an  important
          distinction.   Because  of  routing,  the  addressee and the
          target for a particular message are often different nodes.

               A "packet" is a collection of messages all to  be  sent
          to  a single target (though perhaps several addressees).  At
          the beginning of each schedule Fido builds all  the  packets
          he will be permitted to send during that schedule.

               Now, let's take a look at the three basic commands that
          may  appear  in  a  route file, and see how each of them can
          modify Fido's behavior.

          SCHEDULE <tag> <target list>         or
          SEND-TO <target list>

               These commands are equivalent.  They tell Fido  "During
          this  schedule,  you  may  build  packets  for any target in
          <target list>.  Include all messages to different addressees
          which  may  be routed to these targets.  Do not consider any
          outgoing messages which cannot  be  sent  to  one  of  these
          targets."  Unless  there  is  an  ACCEPT-FROM statement (see
          below) only messages originating on your Fido qualify to  go
          into  packets.   If  <target list> is empty (and this is NOT
          schedule A), Fido will not build any packets.  If he doesn't
          build  any  packets he will not send any mail, even if he is
          POLLed (see next week).

          ROUTE-TO <target> <addressee list>

               This  command  will  override  any  node  list  implied
          routing  affecting  these nodes.  It tells Fido "If <target>
          is in <target list> and there are outgoing messages for  any
          nodes  in  <addressee list>, put them in <target>'s packet."
          If <target> is not in  <target  list>  you  blew  it.   It's
          almost,  but  not quite a "no operation." No packets will be
          built for nodes in <addressee list>, even  if  they  are  in
          <target  list>!   Don't  route messages to a <target> that's
          not in the <target list> for this schedule.

               By  the  way,  a bug in an earlier version of Fido pre-
          vented messages to <target> from being sent  unless  he  was
          also  in  <addressee  list>.   I don't know if that has been
          corrected, but it's  still  good  general  practice  to  put
          <target> in <addressee list>.

          ACCEPT-FROM <originating list>

               Normally, Fido only  sends  mail  originating  on  your
          board.   If  you  receive  a  message  originating  on A and
          addressed to B, without this statement, your Fido  will  not
          attempt  to  send  it  along to B.  Instead, he will mark it
          "orphan" to give you an indication that  he  had  a  problem
          with  it and otherwise ignore it.  This statement in a route
          file tells Fido "When you build packets,  if  you  find  any
          messages from any nodes in <originating list>, treat them as
          if  they  originated  here.   In  other  words  FORWARD  any
          messages  from  the nodes in <originating list> that you can
          get into packets FOR THIS SCHEDULE's <target list>."

               I actually suggested this verb for this action and have
          regretted  it  ever  since!  It's a misnomer.  A better verb
          might be "FORWARD-FOR" but hindsight is  always  20-20.   It
          really  means  "Accept,  for  forwarding, only messages from
          these guys."  It's  designed  to  prevent  you  from  paying
          someone else's phone costs without prior arrangement.

               So  where  do  you  put  this  statement?  Remember two
          important points I've  mentioned  before.   1)  Route  files
          affect  how  you  SEND  mail,  not how you receive it.  2) A
          particular route file affects only  the  schedule  with  the
          matching  <tag>.   Consider  Fido  202/0, a hypothetical bi-
          directional host.  He executes three schedules  each  night.
          During  schedule  B, before the national window, he collects
          outgoing mail from his locals.  During schedule C  he  sends
          mail  from  himself  and  his  locals  to  "the network" and
          receives mail for himself and his locals from it.   Then  in
          schedule  D,  after  the national window, he distributes the
          mail he received for his locals.

               ROUTE.B  needs  neither  a <target list> nor an ACCEPT-
          FROM statement.  Indeed, he doesn't really need any  ROUTE.B
          file  at  all  because  HE  ISN'T  SENDING  ANY  MAIL DURING
          SCHEDULE B.

               ROUTE.C  has  the national net excluding 202/0's locals
          in its <target list>.  It also has  "ACCEPT-FROM  1,  2,  3,
          (all  locals)."  Now let's say that 202/3 received a message
          from 125/1 last night, but it wasn't delivered because 202/3
          was   down.   The  message  is  still  here.   Won't  it  be
          "orphaned" because 125/1 isn't in the ACCEPT-FROM list?  NO!
          Because  202/3 isn't in the <target list>, the message won't
          even be considered DURING THIS SCHEDULE.

               ROUTE.D has all the nodes in net  202  in  the  <target
          list>,  and  an  "ACCEPT-FROM ALL" statement.  Now the fore-
          going message will be processed correctly and  forwarded  to
          202/3.

               Now let's say that 100/76 tries to forward a message to
          Jakarta through 202/0.  202/0 cannot refuse delivery of  the
          offending  message,  so  there  it  sits  in  his mail area.
          During schedule B, he ignores all outgoing mail  because  he
          doesn't  have a <target list>.  During schedule C Jakarta is
          in his <target list>, but 100/76 is not in his  <originating
          list>, so the message is orphaned.  During schedule D 100/76
          IS in the <originating list>, but  Jakarta  is  not  in  the
          <target list> so the message is again ignored.

               Make  no  mistake,  if  Jakarta had been in the <target
          list> in schedule D, the message would have been sent,  even
          though  it  had  been  marked  an  orphan  during schedule C
          (provided, of course that a connection  could  be  made  and
          Jakarta  happened  to  be  in a mail schedule at that time).
          This means that if messages are orphaned because  of  errors
          in  your  routing  files, the routing files can be corrected
          and the messages can still be sent.  The orphan flag is  NOT
          a dead end!

               A  similar kind of bug existed (and may still;  I don't
          know) with ACCEPT-FROM as with ROUTE-TO (above).  If a route
          file  contains  an ACCEPT-FROM statement, make sure your own
          node is in the <originating list>.  (The first time  I  used
          this   statement,   I  forwarded  a  lot  of  messages,  but
          "orphaned" my own messages!)

               Well, that's how routing is  achieved.   Remember,  all
          these  statements  control  out-going mail.  You can receive
          mail even if you don't have any route files!

               A final point on routing.  If a message says it  has  a
          file  attached (even if the file doesn't exist) all bets are
          off.  Routing is suspended and  the  message  will  be  sent
          direct  from  the  originator  to  the  addressee.  Fido has
          several built-in safeguards to prevent you  from  forwarding
          someone  else's  files,  or  forwarding  your  files through
          someone else for that matter.

               Next week we'll take a close look at the goodies TJ has
          provided in version 11 and see how they are making automatic
          node list distribution at long last a reality.

          ------------------------------------------------------------



                         FidoNet Route Files Explained
                    Part 3 -- Keep the Old, Ring In the New

                           by Ben Baker, Fido 100/76

               Last  week  we  looked  at the basic routing statements
          that have been with us since version  7  or  so.  Now  let's
          look at what's been added in version 11.

               Please refer back to last weeks  definitions.   I  con-
          tinue to use them as defined.

          RECV-ONLY

               This tells Fido "Go ahead and  build  packets  for  any
          targets  in  the SCHEDULE command's <target list>, but DON'T
          ATTEMPT TO CALL ANYBODY.  If any targets happen to  call  in
          for  any  reason, try to give them their packets before they
          get away."

               There  MUST  be  a  <target list> for this statement to
          mean anything.  It is not  intended  for  normally  "receive
          only"  schedules  like 202/0's collection schedule (see last
          week).  Instead, it  prevents  you  from  originating  calls
          during  schedules  when you are trying to SEND mail.  (Route
          files control how you send mail, not how  you  receive  it.)
          You  are  really  trying  to  send  mail  on the other guy's
          nickel, but as you will see, he has  to  cooperate  in  that
          venture.

               This  statement  might be used by the locals during the
          collection schedule in a large, busy  net.   Collisions  are
          avoided  because  there's  only one node, the outbound host,
          placing calls.  He POLLs (see below) the  locals  for  their
          outgoing traffic.

          HOLD <hold target list>

               "OK, Fido, build packets for  targets  in  the  <target
          list>,  but  don't  attempt  to actually call any targets in
          <hold target list>." This is a limited "RECV-ONLY"  command.
          Any  packets  for  targets not in <hold target list> will be
          sent normally (if they haven't been picked up), but  packets
          for <hold target list> have to be "picked up."

               There's  a  hidden  gimmick  here  that  bears  further
          exploration.   Ken  Kaplan  (Fido  100/22  AKA  1/0)  is the
          original  source  in  the  national  nodelist   distribution
          system.   Regional  coordinators  call his Fido each week to
          pick up copies of the latest nodelist.  The route  file  for
          his  national  window contains the statement "HOLD <regional
          coordinator list>."  Fido  will  not  attempt  to  send  any
          packets  targetted  for  a  regional coordinator.  Does this
          mean  that  he  can't  send   "normal"   messages   to   the
          coordinators?   Not  at  all.  Because he is a member of net
          100, all his "normal" messages, including those addressed to
          the  coordinators, wind up in a packet targetted for 100/10,
          the outbound host.  Since 100/10 is not in the <hold  target
          list>,  that  packet  is sent and the messages go out.  HOLD
          APPLIES TO THE TARGETS OF PACKETS, NOT TO THE ADDRESSEES  OF
          MESSAGES!   It  is  only  when  Ken  sends  messages  to the
          coordinators with the nodelist (or other files) attached  to
          them  that Fido builds packets targetted for them instead of
          100/10.

               Does that mean that Ken  can't  send  the  coordinators
          other files without waiting for them to pick them up?  Well,
          yes and no.  Because of the HOLD  statement,  he  can't  say
          send  FIDO_IBM.EXE to 14/61 (see PICK-UP below for why 14/61
          and not  14/0).   But  he  can  use  another  gimmick.   The
          coordinators have dual identities (set by the '4' command of
          Fido) and he can certainly send a file  to  14/0.   Fido  is
          smart,  but so smart he'll notice that 14/0 and 14/61 happen
          to have the same phone number.  He'll send  the  packet  for
          14/0 and hold the one for 14/61.  By the same token, if both
          packets are still present when 14/61 calls  in,  he'll  only
          pick up the the nodelist targetted for 14/61 and not the new
          Fido targetted for 14/0.  (You can't have your cake and  eat
          it too.)

          PICKUP <pickup target list>

               Whenever any other Fido calls your Fido for any reason,
          your Fido looks to see if there is a  packet  targetted  for
          him.  If there is, your Fido will try to deliver it then and
          there and avoid making the phone call which you have to  pay
          for.   Without this statement (or the next one) in his route
          file, the other Fido will simply hang up on you, leaving you
          with  a  phone call to make in order to deliver your packet.
          This statement says to Fido  "If  you  happen  to  call  any
          target in <pickup target list>, hang around to see if he has
          mail for me."

               This  is  a  two-edged  sword.   It  can  speed up mail
          exchange, but the Fido that places the call pays for it.  It
          works  best  within a local net where the calls are all toll
          free anyway.  In fact, it won't work at all  between  larger
          nets  supported  by  distinct  inbound  and  outbound hosts.
          Specifying "PICKUP 100/0" in your national  window  schedule
          would  only get you messages originating on 100/0 (or 100/51
          actually) with files attached.  Any other mail for you might
          be in a packet addressed to you, but on 100/10, the outbound
          host, and that's not who you called.

               Even worse, let's say Tom Jennings is sending a file to
          100/10 and wants to pick up any mail from St.  Louis for San
          Francisco while he's at it.  He's the host of net  125,  and
          that's  perfectly  legitimate,  right?   Wrong!  His primary
          identity (the '4' command again) is  125/1  and  100/10  may
          have  a  packet  for  125/0,  but he won't have a packet for
          125/1.  This command deals at the packet/target  level  just
          as  the  HOLD command does.  Furthermore, it deals with real
          identities, not alternate identities.

               As I said, this is most useful within a local net,  and
          that's where it probably should be applied.

          POLL <poll target list>

               This  tells Fido "Even if I don't have any mail for the
          targets  in  <poll  target  list>  generate  empty   packets
          addressed  to them so you have an excuse to call them.  Then
          when you do call them, pick anything they have for me."

               "POLL <poll target list>" implies "PICKUP <poll  target
          list>"  which  need not be specified.  This is the statement
          an outbound host might use to poll his locals  or  hubs  for
          outgoing traffic prior to national mail time.  Together with
          the next statement, this method can be very efficient.

               The regional coordinators run a special  schedule  each
          Saturday morning  during  the  national  mail  window.  It's
          route  file  is  identical to their normal national schedule
          route file except that it contains the statement "POLL 1/0."
          That's how they  get  the  nodelist  for  subsequent  redis-
          tribution.

               As I see it, POLL has a lot more uses than PICKUP.

          SEND-ONLY

               This  one  is  mainly for outbound hosts.  It says "I'm
          not expecting any mail during this schedule, so  don't  wait
          the  normal  one  or  two  minutes for incomming calls after
          making an outgoing call.  As soon as you  finish  one,  dial
          another until all packets have been sent."

               As  I  said  above,  this  can  be  very efficient, but
          there's a problem you need to be aware of.  Fido will make a
          maximum of 30 attempts without connect to send a packet to a
          particular target.  If you have only one packet addressed to
          a busy target, Fido would normally take about an hour to use
          up 30 attempts, but in SEND-ONLY  mode  he  can  attempt  30
          calls  in  about  20 minutes!  If you have a Courier and are
          running it  in  "X4"  response  code  mode,  he'll  make  30
          attempts  in 10 to 15 minutes.  (The Courier doesn't waste a
          lot of time in "fast-dial, busy-detect" mode.)

               If you're an outbound host and want  to  try  SEND-ONLY
          during  the  national  window,  you  risk using up your call
          attempts while  your  target  is  busiest,  then  when  he's
          quieted  down and you could get through, you've given up!  I
          suggest you break your national time into two schedules, and
          only  use  SEND-ONLY during the last 20 minutes or so of the
          national window.

               On  the  other  hand,  polling your locals or hubs is a
          different matter.  They should be in RECV-ONLY mode and  you
          can  expect  every  call to connect the first try.  The call
          attempt limit doesn't apply to this situation and the  SEND-
          ONLY  command  should  be used to shorten the time needed to
          POLL everyone.

          NO-ROUTE <addressee list>

               This command tells Fido "Do not send messages addressed
          to these nodes anywhere but to the addressed  nodes.   Treat
          them  as though they have files attached, whether they do or
          not."

               This lets you say things like Fido 100/76 (in Illinois)
          might:

          SEND-TO 100/10        ; Outbound Host (in Missouri)
          ROUTE-TO 100/10 ALL   ; Send everything to accross the river
          NO-ROUTE 100/482      ; Except other Illinois traffic

               The  only  other  way to achieve this end is to list in
          the ROUTE-TO command all 500 odd nodes whose messages should
          be routed to 100/10, and that list changes every week!

               Now  you  should have a good handle on how the commands
          used in ROUTE.<tag> control  how  Fido  SENDS  files  during
          schedule  <tag>.   But sometimes these commands require very
          long lists of node numbers which change from week to week as
          the  node  list  changes.  LISTGEN 2 will generate the route
          files automatically and  let  you  specify  the  long  lists
          symbolically  in terms of nets, area codes, etc..  Next week
          in  the  last  part  of  this  series,  we'll  see  how  the
          statements  in  LISTGEN's  ROUTE.CTL  file correspond to the
          commands in ROUTE.<tag>.

          ------------------------------------------------------------



                         FidoNet Route Files Explained
                        Part 4 -- LISTGEN and ROUTE.CTL

                           by Ben Baker, Fido 100/76


               LISTGEN  Version  2  will  automatically generate route
          files for you if you desire.  The advantage is that  LISTGEN
          is driven by a control file, ROUTE.CTL, in which you specify
          the statements necessary with symbolic parameters  that  you
          define  in  terms  of  nets,  area  codes, etc..  A properly
          designed ROUTE.CTL need only change when your routing  needs
          change.  LISTGEN will continue to create correct route files
          week after week as the nodelist changes.

               Before I begin, I'd like to do a quick  review  of  the
          route file commands and their effect.

          SCHEDULE <tag> <list> or
          SEND-TO <list>               Determines which nodes may have
                                       packets build to SEND mail to.
          ROUTE-TO <target> <list>     Directs that messages  to  par-
                                       ticular  addressees  be SENT in
                                       packets to another node.
          ACCEPT-FROM <list>           Specifies  which   oritinators'
                                       messages may be SENT.
          RECV-ONLY                    States that packets may only be
                                       SENT by being picked up.
          HOLD <list>                  States that  packets  to  part-
                                       icular  nodes  may only be SENT
                                       by being picked up.
          PICK-UP <list>               States that it is OK to receive
                                       mail from particular nodes when
                                       we originate calls to SEND them
                                       packets.
          POLL <list>                  Directs that packets (empty  if
                                       necessary)   be  generated  and
                                       SENT  to  particular  nodes  in
                                       order to pick up mail.
          SEND-ONLY                    States  that  calls may be made
                                       rapid-fire  to  SEND  as   many
                                       packets as possible.

               Note that each definition above includes the verb  SEND
          or  SENT.   I  did that deliberately to emphasize that these
          commands all control some aspect of sending mail.

               LISTGEN has been adaquately documented  and  I  do  not
          intend  to re-document it here, but I would like to show you
          how ROUTE.CTL  commands  map  to  the  ROUTE.<tag>  commands
          covered above.

          SCHEDULE <tag> <target list>

               When  LISTGEN  encounters  this command in ROUTE.CTL it
          does two things.  First it closes any route file it  may  be
          working  on  and  creates a new ROUTE.<tag> file for the new
          <tag>.  Then it generates  a  SCHEDULE  statement  from  the
          specifications   in   this  one  for  the  new  ROUTE.<tag>,
          expanding any symbolic parameters to lists of nodes from the
          nodelist.  In other words, it begins a new route file as you
          would expect it to by defining the <target list>.

          FROM <accept list>

               This phrase, when encountered, generates an ACCEPT-FROM
          statement.

          TO <addressee list> [ VIA <target> ]

               If  the VIA clause is present, this statement generates
          a  "ROUTE-TO  <target>  <addressee  list>."  Successive   TO
          phrases  without  VIA  clauses  accumulate  to make a larger
          <addressee list> until a VIA  clause  IS  found.   Then  the
          entire  list  is  routed to the <target>.  (I'm not entirely
          happy with this "feature," but that's the way it works.)  If
          no  VIA  clause  is  ever  found, the TO phrase generates no
          output at all!  It  does  serve  as  documentation  in  your
          ROUTE.CTL file, saying "I expect to be sending mail TO these
          nodes in this schedule."

               All of the other route file  commands  discussed  above
          map  one-for-one  in  the  same  format  from  ROUTE.CTL  to
          ROUTE.<tag>.

               The big advantage in using LISTGEN is to be able to use
          simple  symbols  which  it will translate into long lists of
          nodes.  To illustrate, net 100 spans two area codes, 314  in
          Missouri  and  618  in  Illinois.  To minimize the number of
          toll calls placed accross the Mississippi, I serve as "Metro
          East"  hub  to concentrate the Illinois traffic.  I have the
          following statements (among others) in my ROUTE.CTL file:

          define Metro-East as Net-100 except Area-314 ; Area 618
          define Outbound as 100/10
          define World as all except Metro-East
            *  *  *
          FROM Metro-East TO World VIA Outbound

               Nodes may come and go, both in our net and  across  the
          country,  and  these  statements  need  not change.  LISTGEN
          interprets them week after week and builds the  right  route
          files  every  time.   And in several months, if our outbound
          host should change making it necessary to change  ROUTE.CTL,
          I  can  look  at this and not have to say to myself "What on
          earth was I trying to do here?" It's all pretty obvious.

               Before I wrap it up, there are two important exceptions
          to  the things I have said.  First, schedule A is special in
          that the <target list> always is  the  entire  nodelist,  no
          matter  what  ROUTE.A  says.  For that reason, if you do any
          routing not defined by the node list, I recommend  that  you
          DO  NOT  USE SCHEDULE A.  For all other schedules, Fido does
          exactly what ROUTE.<tag> tells it to do  and  nothing  more.
          And  second,  ROUTE.BBS is a special route file that affects
          all schedules for which there are no ROUTE.<tag> files.  For
          that  reason,  I recommend that you FORGET YOU EVER HEARD OF
          ROUTE.BBS.  It'll cause more problems than it'll ever solve!

               So,  routing  can  get  pretty complex (just ask 'em in
          Southern California), but it doesn't need to be  complicated
          once  you  know  what the objective of each schedule is from
          your point of view, and what your Fido needs to do  to  meet
          those objectives.

               In  fact, it's pretty easy if you just remember the two
          points I have been hammering at you since we began:

               1) Route files control the way you send  messages,  not
          the  way you receive them.  Every command we discussed above
          controls some aspect of sending messages.  And.  .  .

               2) A particular route file only  affects  the  schedule
          with  the  matching  <tag>.   What you say in ROUTE.B has no
          bearing whatever on  schedule  C.   Each  schedule  must  be
          separately spelled out.